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

3.4.2 gh-ost工具加密（在線DDL變更工具+數據加密算法）

我們對MySQL表的在線變更是依賴gh-ost工具來實現的，它的機制上就是在原集群上創建一個影子表，通過select和Binlog row 復制，將原表的數據灌入到影子表中，最后通過一次鎖切換，實現訪問目標變更。

那么這個環節實際上可以和我們的對敏感數據治理的工作結合起來，因為實現上會要求建立密文字段（或者不建立亦可），所以可以將加密歷史數據的環節直接放在新增密文字段操作發生時。

4.數據鏈路的上下游適配

4.1 業務接入改造

對于存在敏感數據治理的數據庫的上游，顯而易見就是涉及敏感數據的業務系統，我們做的一切工作就是為了幫助解決原本沒有脫敏或不符合規范的數據落地；

那么對于常規業務接入，我們通過利用已經集成在MySQL架構內的代理，只需要在使用層增加 脫敏規則，就可以無縫將傳輸的流量進行加解密

計算層無損變更

確定并配置脫敏規則

開啟用戶級別的開關

自動透明加解密實現

4.2 實時采集

在實時采集任務原本的邏輯中，會從源取得實時數據變化對應的Binlog，解析成相對于的下游格式，放到es/Kafka或其它下游中。

因為加密使得數據庫中實際存儲密文，那么Binlog內的數據也會是密文數據，這一過程中就需要在采集層實現類似Proxy的解密能力，通過獲取脫敏規則來改寫密文字段的行數據，再向下游執行。

5.總結與展望

5.1 總結

從發現、處理敏感數據以及適配敏感數據治理的解決方案：

5.2 展望

5.2.1挑戰

通用的脫敏方案僅針對支持MySQL協議的數據庫；

無法支持列的計算和比較操作，SQL兼容性受限；

目前主要聚焦在存儲層進行加密。

5.2.2優化規劃

針對這些，主要在兩方面規劃：

提升SQL的兼容性，適配復雜的查詢或寫入場景；

強化目前局限于數據存儲層的加密方案，擴展多源數據場景的治理方案，完成整個生態的統一加解密方案。