1.背景

1.1 數(shù)據(jù)安全風(fēng)險

近年來，有關(guān)數(shù)據(jù)泄露相關(guān)的新聞事件屢見不鮮，不斷地引發(fā)大眾的討論和擔(dān)憂。各家企業(yè)都或多或少在承受相關(guān)的數(shù)據(jù)安全風(fēng)險，這種可能性會給企業(yè)運行帶來額外的風(fēng)險，包括大眾的質(zhì)疑以及政府的處罰等。

• Facebook超5億用戶個人數(shù)據(jù)遭到泄露；
• Elector Software投票應(yīng)用泄露超650萬以色列選民個人數(shù)據(jù)；
• T-Mobile數(shù)據(jù)失竊，超過1億用戶的個人信息被泄露售賣；
• 亞馬遜因違反GDPR被重罰7.46億歐元……

從現(xiàn)有的事件統(tǒng)計來看， 數(shù)據(jù)庫未得到正確配置和黑客攻擊相對來說是比較主要的誘因；在這種嚴(yán)峻的個人信息保護形勢背景下，各國都在強化健全相關(guān)的法律合規(guī)機制。

1.2 數(shù)據(jù)安全法律與合規(guī)的完善

1.2.1 現(xiàn)行法律與合規(guī)

• 國內(nèi)：個人信息保護法、數(shù)據(jù)安全法、網(wǎng)絡(luò)安全法
• 海外：GDPR（EU，一般數(shù)據(jù)保護條例）, PDPB（India，個人數(shù)據(jù)保護法），DBNL（US，數(shù)據(jù)泄漏通知法）

1.2.2 工業(yè)和信息化部關(guān)于互聯(lián)網(wǎng)行業(yè)市場秩序?qū)ｍ椪涡袆?/strong>

2021年7月工信部組織的專項整治行動中，威脅數(shù)據(jù)安全的問題，主要體現(xiàn)在：

• 用戶數(shù)據(jù)收集
• 用戶數(shù)據(jù)傳輸
• 用戶數(shù)據(jù)存儲

未按法律法規(guī)要求建立數(shù)據(jù)安全管理制度和采取必要的安全技術(shù)措施，將會遭到包括曝光、約談、下架、停止網(wǎng)絡(luò)接入、行政處罰等在內(nèi)的處罰。

1.3 敏感數(shù)據(jù)治理現(xiàn)狀和難點

對于工信部的整改要求，我們梳理了目前的現(xiàn)狀以及可能遭遇的風(fēng)險： 

• 整改時間緊張

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

• 涉及項目模塊廣

包括互聯(lián)網(wǎng)團隊的所有部門，相關(guān)應(yīng)用模塊超過300個；

• 規(guī)定本身可能變化、更新

整改的規(guī)定或者說要求可能會隨實際情況發(fā)生變化、更新，需要及時對變化的要求進行轉(zhuǎn)化、同步。

問題實際上就是聚焦在這幾個部分，什么是敏感數(shù)據(jù)，怎么發(fā)現(xiàn)它并進行脫敏，以及整體需要怎么去適配?；谶@些難點，我們的最終目標(biāo)就是借此次整治機會，建立一個長期有效的數(shù)據(jù)安全管理制度和體系。

2.敏感數(shù)據(jù)字段發(fā)現(xiàn)

2.1 定義

首先需要定義或者說確定哪些數(shù)據(jù)可以認(rèn)為是敏感數(shù)據(jù)：

• 用戶的個人信息，在近幾年發(fā)生的數(shù)據(jù)泄漏事件中，大眾也更關(guān)注此類信息的受侵害程度；
• 對廠商而言，設(shè)備以及設(shè)備的相關(guān)數(shù)據(jù)，如操作記錄，imei等唯一標(biāo)識也存在敏感風(fēng)險。

而且，從上述數(shù)據(jù)衍生而出的，例如： 

• 內(nèi)容平臺發(fā)表或存儲的數(shù)據(jù)；
• 用戶行為和特征衍生而出的用戶畫像；
• 財務(wù)賬務(wù)數(shù)據(jù)。

這些都屬于會顯著引起大眾關(guān)注的場景。

2.2 數(shù)據(jù)分級規(guī)范

針對這種復(fù)雜的敏感數(shù)據(jù)態(tài)勢，vivo針對《個人信息保護法》，《數(shù)據(jù)安全法》中賦予企業(yè)的合規(guī)責(zé)任和義務(wù)制定了具體的分級規(guī)范；簡而言之，就是會按照影響的強度和范圍對數(shù)據(jù)字段進行劃分，這個定級是具體到字段級別：

• 對企業(yè)運行的影響；
• 對用戶個人隱私、權(quán)益的影響。

其中可能引發(fā)負(fù)面影響和侵害用戶權(quán)益、隱私的風(fēng)險等級以上的數(shù)據(jù)都需要進行不同程度的脫敏。

我們希望通過對不同的安全級別采用不同的操作策略，來確保數(shù)據(jù)安全風(fēng)險可控。

2.3 現(xiàn)狀與改進措施

在具備標(biāo)準(zhǔn)的規(guī)范級別后，我們需要對現(xiàn)存的和新增的數(shù)據(jù)進行定級分類，但當(dāng)前存在以下問題：

• 對新的字段沒有明確級別，往往需要使用后才進行定級分類；
• 數(shù)據(jù)字段識別引擎待優(yōu)化，主要支持用戶類型的識別，對非用戶數(shù)據(jù)支持較差；
• 存量數(shù)據(jù)依賴人工判定，工作量大；
• 缺少衡量評價指標(biāo)，質(zhì)量不可控。

針對這些現(xiàn)狀問題，在各個環(huán)節(jié)進行了優(yōu)化改進，形成了完整的敏感數(shù)據(jù)字段自動發(fā)現(xiàn)的方案：

2.4 系統(tǒng)自動定級與訂正

通過敏感數(shù)據(jù)識別引擎，對結(jié)構(gòu)化數(shù)據(jù)進行整體掃描，自動識別出敏感數(shù)據(jù)，支撐其進行數(shù)據(jù)分類分級及數(shù)據(jù)治理，以便根據(jù)結(jié)果對敏感數(shù)據(jù)做進一步的安全防護和后續(xù)的精細(xì)化管理。

具體的環(huán)節(jié)中，我們通過系統(tǒng)定期掃描業(yè)務(wù)集群的庫、表、集合、字段，對其中的字段進行分類分級，并根據(jù)已有的數(shù)據(jù)進行打分（準(zhǔn)確率），再通過人工訂正糾偏對評分系統(tǒng)進行反饋調(diào)整，達(dá)成一個長期的正向提升循環(huán)。

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

• 覆蓋率：有分類分級的數(shù)據(jù)量/全部數(shù)據(jù)量；
• 準(zhǔn)確率：用戶數(shù)據(jù)分類分級正確的量*0.1/（抽檢用戶數(shù)據(jù)量*0.1+抽檢非用戶類別中用戶類別的數(shù)據(jù)量*0.9）。

計算公式中的1:9關(guān)系，是由我們現(xiàn)存數(shù)據(jù)分類中用戶數(shù)據(jù)和非用戶數(shù)據(jù)占比核算得到，實際上是用于均衡計算實際的用戶分類分級準(zhǔn)確率，而這樣設(shè)計的初衷，即盡可能減少誤判用戶數(shù)據(jù)為非用戶數(shù)據(jù)的情況。

2.5 小結(jié)

最終，基于當(dāng)前的能力現(xiàn)狀，我們實現(xiàn)了：

• 對MySQL/TIDB/ElasticSearch/MongoDB在內(nèi)的四種數(shù)據(jù)庫的敏感字段識別；
• 支持全自動的實時敏感數(shù)據(jù)字段識別，包括對業(yè)務(wù)新建表、集合的掃描；
• 支持總共超過100類用戶或非用戶數(shù)據(jù)的分級分類，最終實踐的定級準(zhǔn)確率不低于85%；
• 基于這樣建成的能力，我們可以達(dá)成敏感數(shù)據(jù)分類分級，以及即席查詢這類場景下對敏感數(shù)據(jù)的保護能力。

那么，在我們解決了如何發(fā)現(xiàn)敏感字段的問題后，就需要對這些敏感數(shù)據(jù)進行處置，這也是本次專項治理的核心環(huán)節(jié)。

3.數(shù)據(jù)加解密

3.1 方案選型

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

對開發(fā)和運維而言，是希望接入簡單，一次整改解決所有問題，基本保持現(xiàn)狀一致，同時兼具穩(wěn)定，有可用性保障，能支持更多類型數(shù)據(jù)庫形成統(tǒng)一方案等。

對安全而言，是關(guān)注符合合規(guī)要求，規(guī)避可能的風(fēng)險。

這里主要介紹MySQL方面的工作，我們內(nèi)部的團隊分別從多個方向入手，提供了對應(yīng)的解決方案：

• 基于MyBatis插件的實現(xiàn)形式，業(yè)務(wù)可以使用定制的加解密方法在應(yīng)用內(nèi)部自行實現(xiàn)加解密；
• 基于shardingsphere實現(xiàn)的應(yīng)用層加解密，業(yè)務(wù)通過改變接入層使用特殊的配置數(shù)據(jù)源；
• 基于使用的MySQL架構(gòu)中存在的代理來實現(xiàn)通用的數(shù)據(jù)加解密，對應(yīng)用層完全透明，同時限定訪問解密數(shù)據(jù)的權(quán)限必須要通過代理。

3.2 方案對比

從一些常規(guī)的角度，通過調(diào)研實際實現(xiàn)和業(yè)務(wù)反饋，我們對比了三種方案的成效，從成本以及上下游兼容性來看，Proxy具有相當(dāng)?shù)膬?yōu)勢，綜合起來我們內(nèi)部是推薦使用使用Proxy做加解密，當(dāng)然另外的方案也是具有可行性的，他們本質(zhì)上都是同一種加解密算法的實現(xiàn)，可以在各個方案間無縫切換。

總的來說，這幾種方案中，加解密發(fā)生的鏈路都位于發(fā)起服務(wù)端和數(shù)據(jù)庫層之間；為了提高效率，中間執(zhí)行具體轉(zhuǎn)發(fā)請求的服務(wù)端或代理Proxy都會緩存對應(yīng)的密文秘鑰，所有的密文秘鑰都托管于KMS服務(wù)平臺，在無法查到或啟動時進行請求，原則上不能中途修改密鑰，這會導(dǎo)致歷史數(shù)據(jù)被破壞。

3.3 Proxy加解密

3.3.1 原理

實現(xiàn)加解密的核心是在數(shù)據(jù)傳輸?shù)倪^程中進行攔截，對SQL和結(jié)果集進行對應(yīng)的改寫；而這一操作是基于預(yù)設(shè)的脫敏規(guī)則：

• 邏輯字段：用戶認(rèn)識中的字段名稱
• 明文字段：存儲原始數(shù)據(jù)的字段
• 密文字段：存儲加密密文數(shù)據(jù)的字段

設(shè)計上，明文字段和密文字段會在一定時間內(nèi)共存，用來支持任意的明文密文切換，確保線上運行時的穩(wěn)定和可回滾能力；

業(yè)務(wù)查詢或?qū)懭胧且蕾囘壿嬜侄?，對?yīng)的規(guī)則會在傳輸中進行改寫，包括將明文/密文字段改寫為邏輯字段以及反向操作，分別對應(yīng)讀取包和寫sql的兩個階段；

這里展示一個比較常規(guī)的數(shù)據(jù)寫入模型，包含明文字段和密文字段password和password_cipher。脫敏規(guī)則中包含一個password和password_cipher字段， 那么Proxy在讀取SQL時，就會將對應(yīng)的字段和數(shù)據(jù)列進行改寫，包含名稱重新映射和數(shù)據(jù)加密處理改寫。

3.3.2 優(yōu)勢與不足

Proxy本身是基于MySQL協(xié)議實現(xiàn)的代理層，相對于直接使用SDK或shardingsphere這樣的偏向語言的方案，具有以下的優(yōu)勢：

• 它是MySQL架構(gòu)中的一部分，這樣可以使得加解密操作限定在“數(shù)據(jù)庫架構(gòu)”的范圍內(nèi)，對外部系統(tǒng)透明；
• 兼容所有使用MySQL協(xié)議的數(shù)據(jù)庫，更容易應(yīng)用在相關(guān)的場景中，沒有接入阻礙；
• 支持各種語言，不存在限制。

但它本質(zhì)上還是依賴加密列的實現(xiàn)，因為對原始語義的破壞和算法的局限，無法支持比較和計算操作。

總的來說，我們基于Proxy實現(xiàn)了通用的加解密方案，可以完成對敏感數(shù)據(jù)的處置，基于目前可行的發(fā)現(xiàn)和處置措施，就可以對目前的敏感數(shù)據(jù)進行整治。

3.4 存量數(shù)據(jù)處理

我們可以把現(xiàn)行的業(yè)務(wù)數(shù)據(jù)分為兩大類：

• 歸檔或備份類型的冷數(shù)據(jù)，這類直接進行整個文件的加密，存儲到oss系統(tǒng)即可符合要求；
• 在線數(shù)據(jù)，即業(yè)務(wù)會進行讀寫的數(shù)據(jù)，這類需要控制對業(yè)務(wù)的影響。
  ?

3.4.1 客戶端加密存量數(shù)據(jù)

這個模式是典型的源寫入加密，在新增密文字段后，可以反復(fù)地在表中使用條件匹配查找未寫入密文的行，對找到的行加鎖后可以查詢對應(yīng)行明文字段的數(shù)據(jù)，改寫成一條寫入的sql向具備加解密能力的SDK或Proxy執(zhí)行，這樣可以通過循環(huán)操作將缺失的密文數(shù)據(jù)進行補全；

這種方式，可以由業(yè)務(wù)自己執(zhí)行，相對來說風(fēng)險可控，雖然會明顯地產(chǎn)生鎖開銷和額外的寫入壓力；

• 讀取配置并獲取需要清洗的數(shù)據(jù)表字段
• 查詢加密列為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;）
• 獲取到明文數(shù)據(jù)后，通過Proxy更新明文列，達(dá)到清洗數(shù)據(jù)目的，比如：（UPDATE `test`.`shop` SET `article` = 1,`dealer` = 'A',`price` = 3.530000 WHERE `article` = 1 AND `dealer` = 'A';）
• 提交清洗事務(wù)，循環(huán)執(zhí)行2，3，4過程達(dá)到清洗全表數(shù)據(jù)，當(dāng)步驟2查詢返回空時結(jié)束

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

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

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

4.數(shù)據(jù)鏈路的上下游適配

4.1 業(yè)務(wù)接入改造

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

那么對于常規(guī)業(yè)務(wù)接入，我們通過利用已經(jīng)集成在MySQL架構(gòu)內(nèi)的代理，只需要在使用層增加 脫敏規(guī)則，就可以無縫將傳輸?shù)牧髁窟M行加解密

• 計算層無損變更
• 確定并配置脫敏規(guī)則
• 開啟用戶級別的開關(guān)
• 自動透明加解密實現(xiàn)

4.2 實時采集

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

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

5.總結(jié)與展望

5.1 總結(jié)

從發(fā)現(xiàn)、處理敏感數(shù)據(jù)以及適配敏感數(shù)據(jù)治理的解決方案：

5.2 展望

5.2.1挑戰(zhàn)

• 通用的脫敏方案僅針對支持MySQL協(xié)議的數(shù)據(jù)庫；
• 無法支持列的計算和比較操作，SQL兼容性受限；
• 目前主要聚焦在存儲層進行加密。

5.2.2優(yōu)化規(guī)劃

針對這些，主要在兩方面規(guī)劃：

• 提升SQL的兼容性，適配復(fù)雜的查詢或?qū)懭雸鼍埃?/span>
• 強化目前局限于數(shù)據(jù)存儲層的加密方案，擴展多源數(shù)據(jù)場景的治理方案，完成整個生態(tài)的統(tǒng)一加解密方案。