建站
咨詢
售后
建站咨詢
新聞中心
?1.背景
專業(yè)成都網站建設公司，做排名好的好網站，排在同行前面，為您帶來客戶和效益!創(chuàng)新互聯建站為您提供成都網站建設，五站合一網站設計制作，服務好的網站設計公司，成都網站設計、成都網站建設負責任的成都網站制作公司!
1.1 數據安全風險
近年來，有關數據泄露相關的新聞事件屢見不鮮，不斷地引發(fā)大眾的討論和擔憂。各家企業(yè)都或多或少在承受相關的數據安全風險，這種可能性會給企業(yè)運行帶來額外的風險，包括大眾的質疑以及政府的處罰等。
- Facebook超5億用戶個人數據遭到泄露；
- Elector Software投票應用泄露超650萬以色列選民個人數據；
- T-Mobile數據失竊，超過1億用戶的個人信息被泄露售賣；
- 亞馬遜因違反GDPR被重罰7.46億歐元……
從現有的事件統(tǒng)計來看， 數據庫未得到正確配置和黑客攻擊相對來說是比較主要的誘因；在這種嚴峻的個人信息保護形勢背景下，各國都在強化健全相關的法律合規(guī)機制。
1.2 數據安全法律與合規(guī)的完善
1.2.1 現行法律與合規(guī)
國內：個人信息保護法、數據安全法、網絡安全法
海外：GDPR（EU，一般數據保護條例）, PDPB（India，個人數據保護法），DBNL（US，數據泄漏通知法）
1.2.2 工業(yè)和信息化部關于互聯網行業(yè)市場秩序專項整治行動
2021年7月工信部組織的專項整治行動中，威脅數據安全的問題，主要體現在：
- 用戶數據收集
- 用戶數據傳輸
- 用戶數據存儲
未按法律法規(guī)要求建立數據安全管理制度和采取必要的安全技術措施，將會遭到包括曝光、約談、下架、停止網絡接入、行政處罰等在內的處罰。
1.3 敏感數據治理現狀和難點
對于工信部的整改要求，我們梳理了目前的現狀以及可能遭遇的風險：
- 整改時間緊張
時間方面緊張，留給內部處置的時間只有兩個半月，而整改本身涉及范圍和難度都很大；
- 涉及項目模塊廣
包括互聯網團隊的所有部門，相關應用模塊超過300個；
- 規(guī)定本身可能變化、更新
整改的規(guī)定或者說要求可能會隨實際情況發(fā)生變化、更新，需要及時對變化的要求進行轉化、同步。
問題實際上就是聚焦在這幾個部分，什么是敏感數據，怎么發(fā)現它并進行脫敏，以及整體需要怎么去適配?；谶@些難點，我們的最終目標就是借此次整治機會，建立一個長期有效的數據安全管理制度和體系。
2.敏感數據字段發(fā)現
2.1 定義
首先需要定義或者說確定哪些數據可以認為是敏感數據：
- 用戶的個人信息，在近幾年發(fā)生的數據泄漏事件中，大眾也更關注此類信息的受侵害程度；
- 對廠商而言，設備以及設備的相關數據，如操作記錄，imei等唯一標識也存在敏感風險。
而且，從上述數據衍生而出的，例如：
- 內容平臺發(fā)表或存儲的數據；
- 用戶行為和特征衍生而出的用戶畫像；
- 財務賬務數據。
這些都屬于會顯著引起大眾關注的場景。
2.2 數據分級規(guī)范
針對這種復雜的敏感數據態(tài)勢，vivo針對《個人信息保護法》，《數據安全法》中賦予企業(yè)的合規(guī)責任和義務制定了具體的分級規(guī)范；簡而言之，就是會按照影響的強度和范圍對數據字段進行劃分，這個定級是具體到字段級別：
- 對企業(yè)運行的影響；
- 對用戶個人隱私、權益的影響。
其中可能引發(fā)負面影響和侵害用戶權益、隱私的風險等級以上的數據都需要進行不同程度的脫敏。
我們希望通過對不同的安全級別采用不同的操作策略，來確保數據安全風險可控。
2.3 現狀與改進措施
在具備標準的規(guī)范級別后，我們需要對現存的和新增的數據進行定級分類，但當前存在以下問題：
對新的字段沒有明確級別，往往需要使用后才進行定級分類；
- 數據字段識別引擎待優(yōu)化，主要支持用戶類型的識別，對非用戶數據支持較差；
- 存量數據依賴人工判定，工作量大；
- 缺少衡量評價指標，質量不可控。
- 針對這些現狀問題，在各個環(huán)節(jié)進行了優(yōu)化改進，形成了完整的敏感數據字段自動發(fā)現的方案：
2.4 系統(tǒng)自動定級與訂正
通過敏感數據識別引擎，對結構化數據進行整體掃描，自動識別出敏感數據，支撐其進行數據分類分級及數據治理，以便根據結果對敏感數據做進一步的安全防護和后續(xù)的精細化管理。
具體的環(huán)節(jié)中，我們通過系統(tǒng)定期掃描業(yè)務集群的庫、表、集合、字段，對其中的字段進行分類分級，并根據已有的數據進行打分（準確率），再通過人工訂正糾偏對評分系統(tǒng)進行反饋調整，達成一個長期的正向提升循環(huán)。
我們定義了兩個指標用來支持評分機制的改進：
- 覆蓋率：有分類分級的數據量/全部數據量；
- 準確率：用戶數據分類分級正確的量*0.1/（抽檢用戶數據量*0.1+抽檢非用戶類別中用戶類別的數據量*0.9）。
計算公式中的1:9關系，是由我們現存數據分類中用戶數據和非用戶數據占比核算得到，實際上是用于均衡計算實際的用戶分類分級準確率，而這樣設計的初衷，即盡可能減少誤判用戶數據為非用戶數據的情況。
2.5 小結
最終，基于當前的能力現狀，我們實現了：
- 對MySQL/TIDB/ElasticSearch/MongoDB在內的四種數據庫的敏感字段識別；
- 支持全自動的實時敏感數據字段識別，包括對業(yè)務新建表、集合的掃描；
- 支持總共超過100類用戶或非用戶數據的分級分類，最終實踐的定級準確率不低于85%；
- 基于這樣建成的能力，我們可以達成敏感數據分類分級，以及即席查詢這類場景下對敏感數據的保護能力。
那么，在我們解決了如何發(fā)現敏感字段的問題后，就需要對這些敏感數據進行處置，這也是本次專項治理的核心環(huán)節(jié)。
3.數據加解密
3.1 方案選型
針對具體的處置環(huán)節(jié)，需要考慮的要求相對就更多了，而且在不同的層面上，相關方關注的要點可能也不太一致，需要在這些要點間進行取舍。
對開發(fā)和運維而言，是希望接入簡單，一次整改解決所有問題，基本保持現狀一致，同時兼具穩(wěn)定，有可用性保障，能支持更多類型數據庫形成統(tǒng)一方案等。
對安全而言，是關注符合合規(guī)要求，規(guī)避可能的風險。
這里主要介紹MySQL方面的工作，我們內部的團隊分別從多個方向入手，提供了對應的解決方案：
- 基于MyBatis插件的實現形式，業(yè)務可以使用定制的加解密方法在應用內部自行實現加解密；
- 基于shardingsphere實現的應用層加解密，業(yè)務通過改變接入層使用特殊的配置數據源；
- 基于使用的MySQL架構中存在的代理來實現通用的數據加解密，對應用層完全透明，同時限定訪問解密數據的權限必須要通過代理。
3.2 方案對比
|
要求 |
SDK加解密（定制MyBatis插件） |
ShardingSphere中間件（vivo-JDBC） |
數據庫透明加解密（Proxy） |
|
接入成本 |
高，需修改應用程序 |
高，需修改應用程序 |
低，無需修改代碼，只需配置脫敏規(guī)則 |
|
維護成本 |
業(yè)務自維護代碼 |
中間件團隊維護 |
數據庫團隊維護 |
|
推廣成本 |
高，只支持java語言 |
高，只支持java語言 |
低，屬于MySQL架構一部分 |
|
高可用 |
應用服務本身決定 |
應用服務本身決定 |
MySQL高可用托管 |
|
客戶端軟件解密 |
不支持 |
不支持 |
支持 |
|
下游使用 |
不支持 |
不支持 |
支持，需接入Proxy |
從一些常規(guī)的角度，通過調研實際實現和業(yè)務反饋，我們對比了三種方案的成效，從成本以及上下游兼容性來看，Proxy具有相當的優(yōu)勢，綜合起來我們內部是推薦使用使用Proxy做加解密，當然另外的方案也是具有可行性的，他們本質上都是同一種加解密算法的實現，可以在各個方案間無縫切換。
總的來說，這幾種方案中，加解密發(fā)生的鏈路都位于發(fā)起服務端和數據庫層之間；為了提高效率，中間執(zhí)行具體轉發(fā)請求的服務端或代理Proxy都會緩存對應的密文秘鑰，所有的密文秘鑰都托管于KMS服務平臺，在無法查到或啟動時進行請求，原則上不能中途修改密鑰，這會導致歷史數據被破壞。
3.3 Proxy加解密
3.3.1 原理
實現加解密的核心是在數據傳輸的過程中進行攔截，對SQL和結果集進行對應的改寫；而這一操作是基于預設的脫敏規(guī)則：
- 邏輯字段：用戶認識中的字段名稱
- 明文字段：存儲原始數據的字段
- 密文字段：存儲加密密文數據的字段
設計上，明文字段和密文字段會在一定時間內共存，用來支持任意的明文密文切換，確保線上運行時的穩(wěn)定和可回滾能力；
業(yè)務查詢或寫入是依賴邏輯字段，對應的規(guī)則會在傳輸中進行改寫，包括將明文/密文字段改寫為邏輯字段以及反向操作，分別對應讀取包和寫sql的兩個階段；
這里展示一個比較常規(guī)的數據寫入模型，包含明文字段和密文字段password和password_cipher。脫敏規(guī)則中包含一個password和password_cipher字段， 那么Proxy在讀取SQL時，就會將對應的字段和數據列進行改寫，包含名稱重新映射和數據加密處理改寫。
3.3.2 優(yōu)勢與不足
Proxy本身是基于MySQL協議實現的代理層，相對于直接使用SDK或shardingsphere這樣的偏向語言的方案，具有以下的優(yōu)勢：
- 它是MySQL架構中的一部分，這樣可以使得加解密操作限定在“數據庫架構”的范圍內，對外部系統(tǒng)透明；
- 兼容所有使用MySQL協議的數據庫，更容易應用在相關的場景中，沒有接入阻礙；
- 支持各種語言，不存在限制。
- 但它本質上還是依賴加密列的實現，因為對原始語義的破壞和算法的局限，無法支持比較和計算操作。
總的來說，我們基于Proxy實現了通用的加解密方案，可以完成對敏感數據的處置，基于目前可行的發(fā)現和處置措施，就可以對目前的敏感數據進行整治。
3.4 存量數據處理
我們可以把現行的業(yè)務數據分為兩大類：
歸檔或備份類型的冷數據，這類直接進行整個文件的加密，存儲到oss系統(tǒng)即可符合要求；
在線數據，即業(yè)務會進行讀寫的數據，這類需要控制對業(yè)務的影響。
3.4.1 客戶端加密存量數據
這個模式是典型的源寫入加密，在新增密文字段后，可以反復地在表中使用條件匹配查找未寫入密文的行，對找到的行加鎖后可以查詢對應行明文字段的數據，改寫成一條寫入的sql向具備加解密能力的SDK或Proxy執(zhí)行，這樣可以通過循環(huán)操作將缺失的密文數據進行補全；
這種方式，可以由業(yè)務自己執(zhí)行，相對來說風險可控，雖然會明顯地產生鎖開銷和額外的寫入壓力；
- 讀取配置并獲取需要清洗的數據表字段
- 查詢加密列為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';）
提交清洗事務，循環(huán)執(zhí)行2，3，4過程達到清洗全表數據，當步驟2查詢返回空時結束
3.4.2 gh-ost工具加密（在線DDL變更工具+數據加密算法）
我們對MySQL表的在線變更是依賴gh-ost工具來實現的，它的機制上就是在原集群上創(chuàng)建一個影子表，通過select和Binlog row 復制，將原表的數據灌入到影子表中，最后通過一次鎖切換，實現訪問目標變更。
那么這個環(huán)節(jié)實際上可以和我們的對敏感數據治理的工作結合起來，因為實現上會要求建立密文字段（或者不建立亦可），所以可以將加密歷史數據的環(huán)節(jié)直接放在新增密文字段操作發(fā)生時。
4.數據鏈路的上下游適配
4.1 業(yè)務接入改造
對于存在敏感數據治理的數據庫的上游，顯而易見就是涉及敏感數據的業(yè)務系統(tǒng)，我們做的一切工作就是為了幫助解決原本沒有脫敏或不符合規(guī)范的數據落地；
那么對于常規(guī)業(yè)務接入，我們通過利用已經集成在MySQL架構內的代理，只需要在使用層增加 脫敏規(guī)則，就可以無縫將傳輸的流量進行加解密
- 計算層無損變更
- 確定并配置脫敏規(guī)則
- 開啟用戶級別的開關
- 自動透明加解密實現
4.2 實時采集
在實時采集任務原本的邏輯中，會從源取得實時數據變化對應的Binlog，解析成相對于的下游格式，放到es/Kafka或其它下游中。
因為加密使得數據庫中實際存儲密文，那么Binlog內的數據也會是密文數據，這一過程中就需要在采集層實現類似Proxy的解密能力，通過獲取脫敏規(guī)則來改寫密文字段的行數據，再向下游執(zhí)行。
5.總結與展望
5.1 總結
從發(fā)現、處理敏感數據以及適配敏感數據治理的解決方案：
5.2 展望
5.2.1挑戰(zhàn)
- 通用的脫敏方案僅針對支持MySQL協議的數據庫；
- 無法支持列的計算和比較操作，SQL兼容性受限；
- 目前主要聚焦在存儲層進行加密。
5.2.2優(yōu)化規(guī)劃
- 針對這些，主要在兩方面規(guī)劃：
- 提升SQL的兼容性，適配復雜的查詢或寫入場景；
- 強化目前局限于數據存儲層的加密方案，擴展多源數據場景的治理方案，完成整個生態(tài)的統(tǒng)一加解密方案。?
?作者介紹
商永星，vivo互聯網高級數據庫研發(fā)工程師。
文章標題：數據泄露事件頻發(fā)，數據庫敏感字段如何治理？
分享地址：http://m.5511xx.com/article/djccpgh.html
