資料泄露事件頻發，資料庫敏感欄位如何治理？-有解無憂

1.背景

1.1 資料安全風險

近年來，有關資料泄露相關的新聞事件屢見不鮮，不斷地引發大眾的討論和擔憂，各家企業都或多或少在承受相關的資料安全風險，這種可能性會給企業運行帶來額外的風險，包括大眾的質疑以及政府的處罰等，

Facebook超5億用戶個人資料遭到泄露；
Elector Software投票應用泄露超650萬以色列選民個人資料；
T-Mobile資料失竊，超過1億用戶的個人資訊被泄露售賣；
亞馬遜因違反GDPR被重罰7.46億歐元……

從現有的事件統計來看，資料庫未得到正確配置和黑客攻擊相對來說是比較主要的誘因；在這種嚴峻的個人資訊保護形勢背景下，各國都在強化健全相關的法律合規機制，

1.2 資料安全法律與合規的完善

1.2.1 現行法律與合規

國內：個人資訊保護法、資料安全法、網路安全法
海外：GDPR（EU，一般資料保護條例）, PDPB（India，個人資料保護法），DBNL（US，資料泄漏通知法）

1.2.2 工業和資訊化部關于互聯網行業市場秩序專項整治行動

2021年7月工信部組織的專項整治行動中，威脅資料安全的問題，主要體現在：

用戶資料收集
用戶資料傳輸
用戶資料存盤

未按法律法規要求建立資料安全管理制度和采取必要的安全技術措施，將會遭到包括曝光、約談、下架、停止網路接入、行政處罰等在內的處罰，

1.3 敏感資料治理現狀和難點

對于工信部的整改要求，我們梳理了目前的現狀以及可能遭遇的風險：

整改時間緊張

時間方面緊張，留給內部處置的時間只有兩個半月，而整改本身涉及范圍和難度都很大；

涉及專案模塊廣

包括互聯網團隊的所有部門，相關應用模塊超過300個；

規定本身可能變化、更新

整改的規定或者說要求可能會隨實際情況發生變化、更新，需要及時對變化的要求進行轉化、同步，

問題實際上就是聚焦在這幾個部分，什么是敏感資料，怎么發現它并進行脫敏，以及整體需要怎么去適配，基于這些難點，我們的最終目標就是借此次整治機會，建立一個長期有效的資料安全管理制度和體系，

2.敏感資料欄位發現

2.1 定義

首先需要定義或者說確定哪些資料可以認為是敏感資料：

用戶的個人資訊，在近幾年發生的資料泄漏事件中，大眾也更關注此類資訊的受侵害程度；
對廠商而言，設備以及設備的相關資料，如操作記錄，imei等唯一標識也存在敏感風險，

而且，從上述資料衍生而出的，例如：

內容平臺發表或存盤的資料；
用戶行為和特征衍生而出的用戶畫像；
財務賬務資料，

這些都屬于會顯著引起大眾關注的場景，

2.2 資料分級規范

針對這種復雜的敏感資料態勢，vivo針對《個人資訊保護法》，《資料安全法》中賦予企業的合規責任和義務制定了具體的分級規范；簡而言之，就是會按照影響的強度和范圍對資料欄位進行劃分，這個定級是具體到欄位級別：

對企業運行的影響；
對用戶個人隱私、權益的影響，

其中可能引發負面影響和侵害用戶權益、隱私的風險等級以上的資料都需要進行不同程度的脫敏，

我們希望通過對不同的安全級別采用不同的操作策略，來確保資料安全風險可控，

2.3 現狀與改進措施

在具備標準的規范級別后，我們需要對現存的和新增的資料進行定級分類，但當前存在以下問題：

對新的欄位沒有明確級別，往往需要使用后才進行定級分類；
資料欄位識別引擎待優化，主要支持用戶型別的識別，對非用戶資料支持較差；
存量資料依賴人工判定，作業量大；
缺少衡量評價指標，質量不可控，

針對這些現狀問題，在各個環節進行了優化改進，形成了完整的敏感資料欄位自動發現的方案：

2.4 系統自動定級與訂正

通過敏感資料識別引擎，對結構化資料進行整體掃描，自動識別出敏感資料，支撐其進行資料分類分級及資料治理，以便根據結果對敏感資料做進一步的安全防護和后續的精細化管理，

具體的環節中，我們通過系統定期掃描業務集群的庫、表、集合、欄位，對其中的欄位進行分類分級，并根據已有的資料進行打分（準確率），再通過人工訂正糾偏對評分系統進行反饋調整，達成一個長期的正向提升回圈，

我們定義了兩個指標用來支持評分機制的改進：

覆寫率：有分類分級的資料量/全部資料量；
準確率：用戶資料分類分級正確的量*0.1/（抽檢用戶資料量*0.1+抽檢非用戶類別中用戶類別的資料量*0.9），

計算公式中的1:9關系，是由我們現存資料分類中用戶資料和非用戶資料占比核算得到，實際上是用于均衡計算實際的用戶分類分級準確率，而這樣設計的初衷，即盡可能減少誤判用戶資料為非用戶資料的情況，

2.5 小結

最終，基于當前的能力現狀，我們實作了：

對MySQL/TIDB/ElasticSearch/MongoDB在內的四種資料庫的敏感欄位識別；
支持全自動的實時敏感資料欄位識別，包括對業務新建表、集合的掃描；
支持總共超過100類用戶或非用戶資料的分級分類，最終實踐的定級準確率不低于85%；
基于這樣建成的能力，我們可以達成敏感資料分類分級，以及即席查詢這類場景下對敏感資料的保護能力，

那么，在我們解決了如何發現敏感欄位的問題后，就需要對這些敏感資料進行處置，這也是本次專項治理的核心環節，

3.資料加解密

3.1 方案選型

針對具體的處置環節，需要考慮的要求相對就更多了，而且在不同的層面上，相關方關注的要點可能也不太一致，需要在這些要點間進行取舍，

對開發和運維而言，是希望接入簡單，一次整改解決所有問題，基本保持現狀一致，同時兼具穩定，有可用性保障，能支持更多型別資料庫形成統一方案等，

對安全而言，是關注符合合規要求，規避可能的風險，

這里主要介紹MySQL方面的作業，我們內部的團隊分別從多個方向入手，提供了對應的解決方案：

基于MyBatis插件的實作形式，業務可以使用定制的加解密方法在應用內部自行實作加解密；
基于shardingsphere實作的應用層加解密，業務通過改變接入層使用特殊的配置資料源；
基于使用的MySQL架構中存在的代理來實作通用的資料加解密，對應用層完全透明，同時限定訪問解密資料的權限必須要通過代理，

3.2 方案對比

要求	SDK加解密（定制MyBatis插件）	ShardingSphere中間件（vivo-JDBC）	資料庫透明加解密（Proxy）
接入成本	高，需修改應用程式	高，需修改應用程式	低，無需修改代碼，只需配置脫敏規則
維護成本	業務自維護代碼	中間件團隊維護	資料庫團隊維護
推廣成本	高，只支持java語言	高，只支持java語言	低，屬于MySQL架構一部分
高可用	應用服務本身決定	應用服務本身決定	MySQL高可用托管
客戶端軟體解密	不支持	不支持	支持
下游使用	不支持	不支持	支持，需接入Proxy

從一些常規的角度，通過調研實際實作和業務反饋，我們對比了三種方案的成效，從成本以及上下游兼容性來看，Proxy具有相當的優勢，綜合起來我們內部是推薦使用使用Proxy做加解密，當然另外的方案也是具有可行性的，他們本質上都是同一種加解密演算法的實作，可以在各個方案間無縫切換，

總的來說，這幾種方案中，加解密發生的鏈路都位于發起服務端和資料庫層之間；為了提高效率，中間執行具體轉發請求的服務端或代理Proxy都會快取對應的密文秘鑰，所有的密文秘鑰都托管于KMS服務平臺，在無法查到或啟動時進行請求，原則上不能中途修改密鑰，這會導致歷史資料被破壞，

3.3 Proxy加解密

3.3.1 原理

實作加解密的核心是在資料傳輸的程序中進行攔截，對SQL和結果集進行對應的改寫；而這一操作是基于預設的脫敏規則：

邏輯欄位：用戶認識中的欄位名稱
明文欄位：存盤原始資料的欄位
密文欄位：存盤加密密文資料的欄位

設計上，明文欄位和密文欄位會在一定時間內共存，用來支持任意的明文密文切換，確保線上運行時的穩定和可回滾能力；

業務查詢或寫入是依賴邏輯欄位，對應的規則會在傳輸中進行改寫，包括將明文/密文欄位改寫為邏輯欄位以及反向操作，分別對應讀取包和寫sql的兩個階段；

這里展示一個比較常規的資料寫入模型，包含明文欄位和密文欄位password和password_cipher，脫敏規則中包含一個password和password_cipher欄位，那么Proxy在讀取SQL時，就會將對應的欄位和資料列進行改寫，包含名稱重新映射和資料加密處理改寫，

3.3.2 優勢與不足

Proxy本身是基于MySQL協議實作的代理層，相對于直接使用SDK或shardingsphere這樣的偏向語言的方案，具有以下的優勢：

它是MySQL架構中的一部分，這樣可以使得加解密操作限定在“資料庫架構”的范圍內，對外部系統透明；
兼容所有使用MySQL協議的資料庫，更容易應用在相關的場景中，沒有接入阻礙；
支持各種語言，不存在限制，

但它本質上還是依賴加密列的實作，因為對原始語意的破壞和演算法的局限，無法支持比較和計算操作，

總的來說，我們基于Proxy實作了通用的加解密方案，可以完成對敏感資料的處置，基于目前可行的發現和處置措施，就可以對目前的敏感資料進行整治，

3.4 存量資料處理

我們可以把現行的業務資料分為兩大類：

歸檔或備份型別的冷資料，這類直接進行整個檔案的加密，存盤到oss系統即可符合要求；
在線資料，即業務會進行讀寫的資料，這類需要控制對業務的影響，

3.4.1 客戶端加密存量資料

這個模式是典型的源寫入加密，在新增密文欄位后，可以反復地在表中使用條件匹配查找未寫入密文的行，對找到的行加鎖后可以查詢對應行明文欄位的資料，改寫成一條寫入的sql向具備加解密能力的SDK或Proxy執行，這樣可以通過回圈操作將缺失的密文資料進行補全；

這種方式，可以由業務自己執行，相對來說風險可控，雖然會明顯地產生鎖開銷和額外的寫入壓力；

讀取配置并獲取需要清洗的資料表欄位
查詢加密列為NULL的行的主鍵值，比如（SELECT article,dealer FROM `test`.`shop` FORCE INDEX(`PRIMARY`) WHERE `article_cipher` IS NULL OR `dealer_cipher` IS NULL OR `price_cipher` IS NULL ORDER BY article,dealer ASC LIMIT 10;）
通過獲取到的主鍵值，查詢加密列的明文值，并對查詢行加鎖，比如：（SELECT article,dealer,price FROM `test`.`shop` FORCE INDEX (`PRIMARY`) WHERE `article` = 1 AND `dealer` = 'A' LIMIT 1 FOR UPDATE;）
獲取到明文資料后，通過Proxy更新明文列，達到清洗資料目的，比如：（UPDATE `test`.`shop` SET `article` = 1,`dealer` = 'A',`price` = 3.530000 WHERE `article` = 1 AND `dealer` = 'A';）
提交清洗事務，回圈執行2，3，4程序達到清洗全表資料，當步驟2查詢回傳空時結束