數據泄露事件頻發，資料庫敏感欄位如何治理？

近年來，有關數據泄露相關的新聞事件屢見不鮮，不斷地引發大眾的討論和擔憂。各家企業都或多或少在承受相關的數據安全風險，這種可能性會給企業運行帶來額外的風險，包括大眾的質疑以及政府的處罰等。 Facebook超5億用戶個人數據遭到泄露； Elector Software投票應用泄露超650萬以色... ...

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查詢返回空時結束