一種海量資料安全分類分級架構的實現！

語言: CN / TW / HK

時間 2022-09-20 18:36:07 騰訊雲開發者

導語 | 本文推選自騰訊雲開發者社群-【技思廣益 · 騰訊技術人原創集】專欄。該專欄是騰訊雲開發者社群為騰訊技術人與廣泛開發者打造的分享交流視窗。欄目邀約騰訊技術人分享原創的技術積澱，與廣泛開發者互啟迪共成長。本文作者是騰訊高階開發工程師楊波。

本文主要總結個人在資料安全分類落地過程遇到問題的經驗，希望本文能對此方面感興趣的開發者們提供一些經驗和幫助。

背景

隨著《資料安全法》、《個人資訊保護法》等相繼出臺，資料安全上升到國家安全層面和國家戰略層面，資料分類分級已經成為了企業資料安全治理的必選題。然而資料分類分級的實現在行業內有很多痛點，主要體現在如下幾點：

規則制定複雜：資料進行分類有多種維度，不同維度各有價值。在不同行業及領域，甚至具體到每個企業和部門，針對不同級別資料也各有定義。維度、級別的不清晰會導致後續基於分類分級的很多合規管控存在問題。

協調溝通成本高：企業規模不斷龐大，組織架構也隨之變得複雜臃腫。資料的掃描上報關聯到多個部門和事業群，甚至子公司。這涉及到多人之間的協調溝通，還需考慮網路隔離，訪問許可權和審批等諸多問題。

資料容量大：網際網路時代到來，企業資訊化建設一直高速發展中，業務系統也越來越複雜。隨之產生的海量資料，給企業帶來巨大的價值。相應一旦海量資料洩漏，也會給企業造成嚴重的後果。如何實時，高效，全面覆蓋海量資料分類分級，這對技術架構是一種考驗。

儲存元件多：網際網路尤其是雲端計算時代，企業為了應對大流量高併發業務場景，誕生關係型，非關係型，物件儲存等多種儲存元件。這既有開源實現，也有企業內部自研。不同的實現，有著不同的傳輸協議和資料結構。要覆蓋多種儲存元件資料分類分級，需要大量的工作量。

然而查閱公司內外很多資料，往往只著重講解資料分類分級概念與標準。目前並未有可借鑑，可落地的分類分級技術實現參考。因此本文重點不在於討論資料分類分級的標準制定，而是從技術層面來講述一種通用能力抽象封裝，海量資料識別，跨部門和平臺數據接入的分類分級架構實現。將資料分類分級技術進行賦能，避免重複造輪子。並以此為基礎來從實際角度滿足資料安全合規工作的落地和推展。

注：資料分類分級介紹參考資料安全治理：資料分類分級指南。

資料安全業務流程

（一）業務層面

從業務層面看，以資料分類分級作為資料安全的基石，來對資料進行安全管控，比如資料加密，資料脫敏，資料水印，許可權管理，安全審計等。可見資料分類分級對資料安全的重要性。

（二）技術層面

從技術層面看，將資料掃描上報，通過資料識別引擎進行識別。然而在實際落地過程中，卻發現很多問題。比如儲存元件種類多，上報資料流量大，以及時效性，準確率，覆蓋率等等問題。

整體架構

通過不斷對資料分類分級業務分析，設計如上資料分類分級架構。架構核心由五大塊組成：

多種儲存元件資料掃描上報工具。

資料識別服務叢集，統一接收上報資料，並進行資料識別。

識別規則引擎，統一維護識別規則的管理，線上熱更新等功能。

資料中臺，依託分類分級結果，進行資料安全管控。

依託公司的基礎框架能力，保障引擎服務的高可用，比如監控，告警，日誌，彈性擴縮容等。

其中重點要處理前三點。

海量資料實時識別

企業規模不斷龐大，海量使用者，必然產生海量資料。如何滿足高效能，時效性同時，又能達到高正確率和覆蓋率要求，對於系統架構是一個巨大考驗。

（一）資料儲存

PCG目前覆蓋近二十種儲存元件型別和平臺，三千萬張表，以mdb，cdb，tredis，天穹為例：

儲存選型

從表格可見，僅mdb已超過五百萬張MySQL表，而cdb甚至超過一千萬張MySQL表。而一張MySQL表即對應要儲存一條分類分級識別結果。MySQL單表資料建議在五百萬左右，超過這個資料量建議通過分庫或分表處理，這在電商專案一些場景是可行，比如交易訂單資料。但這也會帶來經典的分散式事務等問題。

因此需要選擇一種滿足大容量，高併發，高可用和事務acid的資料庫。

大資料hadoop

hadoop作為經典大資料儲存架構，可儲存pb級別以上資料，但時效性不高，通常用作T+1離線任務olap場景。且hadoop對事務acid支援有限，無法滿oltp場景。

tidb

tidb是一款分散式海量容量雲原生newsql。tidb底層使用raft演算法，實現資料分散式儲存和保證資料一致性。同時相容MySQL協議，支援事務。因此tidb滿足要求，然而公司目前沒有專門團隊維護tidb。

雲原生tdsql-c

tdsql-c是TEG自研的一款的資料庫。tdsql-c對MySQL架構做了改進，將計算和儲存分離，從而實現儲存和計算資源的快速擴容。因此tdsql-c支援MySQL協議和事務，同時具備高效能等特性。且公司目前有專門團隊維護tdsql-c。

儲存對比

從表格可見tidb和tdsql-c滿足需求，但tdsql-c有公司內部專人維護。因此選擇tdsql-c來儲存資料分類分級識別結果。

（二）資料接入

服務端需要對接多種儲存元件平臺的資料上報，不用平臺對資源，效能，時效性有不同要求。因此實現http，trpc，kafka多種接入方式，以滿足不同場景。

kafka傳輸大資料

kafka可以實現消費端失敗重試，且可以對流量進行削峰，推薦使用kafka進行資料上報。

為了保證識別結果正確，對關係型資料庫單表取200條資料上傳。大資料存在一些寬表或者大欄位，導致上傳的資料超過1M，這超過了kafka預設配置。除了限制上傳資料包大小以外，也需要對kafka配置進行優化。

kafka producer

max.request.size=1048576 （1M）

batch.size=262144 （0.25M）

linger.ms=0

request.timeout.ms=30000

由於訊息資料包比較大，因此不希望訊息常駐producer記憶體，造成producer記憶體壓力，因此讓訊息儘可能快速傳送到broker端。

kafka consumer

fetch.max.bytes=1048576（1M）

fetch.max.wait.ms=1000

max.partition.fetch.bytes=262144（0.25M）

max.poll.records=5

topic partion>=20

retention.ms=2

由於訊息資料包比較大，且consumer消費訊息需要幾百秒延遲，減少批量拉取訊息數量同時提高拉取訊息等待時間，避免consumer頻繁去broker端拉取訊息，導致consumer cpu被打爆。

優化效果

資料識別

在解決資料上報，資料儲存，資料接入以後，便是資料識別。這是整個資料分類分級架構最核心也是最複雜部分。對資料識別過程主要分為資料對映，規則管理，權重計算，資料校驗四大塊。

資料對映

服務端對單表取200條資料進行識別，按每張表20個欄位，每個欄位需進行20種正則識別。每天假設跑1千萬張表，一共大概要跑8千億次正則計算。如此巨大的計算量，在流量衝擊下，立馬將服務端的cpu飆升到100%，從而導致服務不可用！！！

相對於io密集型，cpu密集型無法簡單使用常見的快取，非同步等方式去減輕服務端壓力。因此需要考慮點如下：

通過雲上k8s彈性擴縮容，將流量分散到多個容器節點，降低單節點負載壓力。

單節點利用多核並行，將計算壓力分擔到多個cpu核處理器上。並且使用訊號量限流，避免cpu一直處於100%。

正則表示式優化。藏在正則表示式裡的陷阱，竟讓CPU飆升到100%！

多核並行

多核並行借鑑MapReduce程式設計模型，本質是一種“分而治之”的思想。

優化效果

規則管理

資料的分類分級，需更精細化的規則管理，才能對後續資料安全做到更合理的管控。規則包括不限於正則，nlp，機器學習，演算法，全文匹配，模糊匹配，黑名單等。對應每種具體分類分級定義，又包括多個規則的組合使用。通過實際的運營和梳理以後，目前有近四百種分類分級定義和八百種識別規則。

因此需考慮合理的方式，將規則管理和識別邏輯解耦，以便後續的維護和升級。同時需考慮規則熱更新和關閉，做到對線上服務無感知。

權重計算

資料分類分級，在不同行業和業務有不同的維度和定義。且源資料由於開發和運維人員定義不清晰，導致最終識別結果存在模糊的邊界。在實際運營過程中，常會因為識別結果不準確，被業務方反饋。

假設有欄位叫xid，有可能是qqid，也可能是wechatid，而qdid和wechatid對應不同的分類分級，這會影響後續的合規流程。在實際場景，xid有可能同時被qqid和wechatid識別規則命中，那麼該取哪個呢？

因此引入權重的概念，權重不在於將識別結果做簡單的0和1取捨，而是通過多個組合規則識別後，計算出一個權重值，並對多個識別結果的權重值進行排序，取權重最大的識別結果作為當前欄位的分類分級。

資料校驗

資料安全合規管控，最重要一項是資料加密。為了方便運營後續進行合規追溯，需要在服務端對當前上報資料是否加密進行校驗，並將校驗結果儲存下來。

資料是否加密需綜合判斷庫表狀態等資訊，其中包括資料是否加密，表是否刪除，庫是否刪除，例項是否下線等。狀態的轉換，通過以下決策樹表示：

跨部門和平臺接入

在重點解決資料上報和資料識別等難點以後，資料分類分級框架已可以滿足大部分業務場景。因此也希望框架能服務更多的部門需求，減少大量繁瑣重複的工作量。

由於資料分類分級結果屬於敏感資料，對於跨部門和平臺接入，需考慮將資料根據不同部門和平臺進行物理隔離儲存。

總結

資料分類分級很複雜，這種複雜性有業務層面，也有架構層面。本文重點在於述說架構層面的問題。這些問題有些可以提前規劃設計，比如儲存選型、通用掃描能力等。也有些需要在落地過程中持續優化，比如海量資料識別，除了對服務本身效能優化，也要對資源成本綜合考慮。

架構沒有好壞之分，只有合適一說。本文所講述是基於個人在落地過程遇到問題的經驗總結。因此反覆斟酌，認真梳理寫下本文，也是對本人工作的一個階段總結。同時也希望框架能得到更多人認可，並達到資料分類分級能力複用，為公司資料安全合規工作盡到一點小小貢獻。

作者簡介

楊波

騰訊雲開發者社群【技思廣益·騰訊技術人原創集】作者

騰訊高階開發工程師，熟悉分散式，微服務，RPC等領域知識。目前負責PCG資料中臺，資料安全治理等相關研發工作，有豐富後端的開發經驗。