Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    86385497

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

背景雖然整體上大家做分類分級的背景以及目標基本一致:滿足監管要求;為數據合規和安全體系建設打好基礎。但是實施落地的過程不盡相同,每個客戶所處的行業不同,所要遵循的分類分級標準不同,同時每個客戶的數據也是截然不同,定制化需求是普遍存在。

當前一些業務模式相對簡單的公司,使用excel的方式人工進行數據分類分級;規模更大業務更複雜的公司自研或採購第三方數據分類分級產品或服務。市場上大部分供應商採取產品+服務的方式服務客戶,其中產品敏感識別能力較弱更多以運營功能為主,敏感數據識別更多的以人力服務的方式幫助客戶進行梳理,雖然能滿足監管要求,但是存在以下公認的問題:

马云惹不起马云無法做到持續運營,交付的產物是基於當時的數據情況,後續新增數據要么需要人介入重新進行梳理,要么無法保證能夠持續準確識別

马云惹不起马云準確率低或不穩定,特別是在數據元信息質量較低的情況

马云惹不起马云人力投入成本高

僅滿足監管要求不是我們的終極目標,我們希望用九智匯分類分級產品在滿足監管的前提下,為數據合規和數據安全打下堅實的基礎,所以我們:

马云惹不起马云採集樣本數據,走樣本數據為主、元數據為輔的技術路線,一方面可以保證已建設的識別能力可持續識別,另一方面準確率穩定性不受元數據質量影響

马云惹不起马云提供智能化、 無侵人、開箱即用的同時,打造易用、靈活、強大的自定義功能,滿足客戶的定制化需求,一方面降低交付成本,另一方面降低門檻讓客戶可以自助使用產品進行敏感數據識別。

實踐方案如果沒有系統或產品,純人工來做數據分類分級,基本上大家完成這件事情的步驟都是:找數據在哪裡-梳理數據有哪些-找敏感數據-歸類-分級。同理,我們的產品也遵循這個思路,設計了一套標準的敏感數據識別流程,如下圖:

图片9.png

在這個流程中,每個節點我們代碼層面的設計和實現都遵循可配置的原則,可以根據客戶環境、現狀和需求等情況調整配置進行適配。另外,盡可能的支持客戶自定義,比如在“敏感數據識別”、“自動分類”、“自動審核”等節點我們都添加了易用的自定義功能,方便滿足客戶的定制化需求。

數據源掃描負責數據分類分級落地,碰到的首要問題肯定是:我們有哪些數據,這些數據在哪裡,是否有遺漏的數據未找到?為此我們研發了數據源掃描器來幫助發現數據源,盡可能的幫助客戶自動發現數據源,盡可能的不遺漏數據源,該掃描器目前具備以下兩種能力:

马云惹不起马云部署到指定網絡環境內,掃描和探測網絡環境內可能是數據存儲的目標,比如可以通過掃描一些常用端口來發現關係數據庫

马云惹不起马云按照要求給雲賬號的AK配置權限後,可以通過該AK拉取雲賬號的所有數據存儲資源列表

數據源集成當然除了上面提到的自動掃描,也可以通過輸入endpoint手動添加數據源。自動掃描發現或手動添加的數據源,一般情況下是需要鑑權才能訪問,這就需要我們找到對應負責人提供賬號密碼連接到數據源。產品特別提供了一個密鑰對管理功能來來解決安全問題:

马云惹不起马云加密存儲鑑權信息(如賬號密碼),提升安全性;

马云惹不起马云連接數據源無需直接輸入鑑權信息,選擇已經維護好的密鑰對即可,有效減少接觸到明文鑑權信息的人員,降低洩漏風險。

另外產品交付過程中,實際上每個客戶的數據源類型不一樣,同種類型的數據源也會有不同版本,為此我們在數據源集成這裡採用插件的設計,插件之間、插件和應用之間隔離運行,以幫助我們解決以下問題:

马云惹不起马云同種類型的數據源,支持不同版本,避免不同版本連接驅動之間依賴衝突問題

马云惹不起马云應用無需直接依賴數據源驅動,避免大量數據源驅動依賴帶來的各種衝突問題

马云惹不起马云滿足客戶數據源集成的定制化需求,不侵入應用代碼

目前我們已經支持以下類型數據源:

马云惹不起马云關係數據庫:MySQL、ORACLE、SQLServer、達夢數據庫、IBM DB2、MariaDB、PostgreSQL等

马云惹不起马云大數據平台:Hive、Maxcompute、ClickHouse、Hbase

马云惹不起马云文件存儲:阿里雲OSS、騰訊雲COS、華為雲OBS、AWS S3、Ceph、Minio

马云惹不起马云文檔平台:語雀

元數據同步在數據源連接成功之後,如果要搞清楚到底哪些數據,我們就需要讀取數據源內部的結構比如表、字段、文件夾、文件的元信息,這些元信息主要有以下作用:

马云惹不起马云為抽樣提供參考依據,比如可以根據表的數據量採取不同的抽樣方法,保證樣本的隨機性,以及降低對數據源的性能和穩定性影響

马云惹不起马云為敏感數據識別提供上下文,幫助進一步確定敏感數據類型,比如根據抽樣數據我能確定該字段是姓名,但是如果有字段備註、字段名稱、表名、表備註信息以及同表其他字段信息,就有可能進一步確定該字段是否是法人姓名

另外,稍微量級大一點的業務就會涉及分庫分錶,這也是在元數據同步要解決的問題,需要將分庫分錶的庫、表進行合併,抽樣的時候也需要考慮去不同的庫、不同的的表進行抽樣。

數據抽樣數據抽樣是一個體力活,也是一個技術活。說是體力活是因為每一種數據源類型甚至每一個類型的數據源版本可能抽樣方法都不一樣,需要單獨做技術實現。說是技術活是因為無論是哪一種數據源類型,不僅要考慮能否抽到數據,還要保證:

马云惹不起马云抽樣數據的隨機性和數量,只有這樣才能保證識別準確率

马云惹不起马云抽樣對數據源的性能和穩定性影響必須要做到最小,即使連接的備庫,每個客戶都非常在意這一點,如果在這一點無法取得客戶信任,項目就非常難往前推進

即使解決了上面兩個最重要的問題,還有保證抽樣性能和穩定性,你可能會遇到以下問題:

马云惹不起马云大數據平台(如Hive)抽樣如果在保證樣本隨機性的情況下,不觸發MR任務

马云惹不起马云上百億的大表,如何進行抽樣才能保證樣本隨機性、性能

马云惹不起马云大字段,單次抽太多肯定會引發IO問題,如何進行分批抽樣

马云惹不起马云同步抽樣肯定會存在超時問題,異步化或回調,哪種方式更好

識別敏感數據敏感數據識別是整個流程中最核心的一個環節,也是算法同學發揮的舞台,首先是要把算法能力集成好,算法需要使用的能力涉及到:

马云惹不起马云正則,由於會有大量的正則匹配,Java自帶的正則能力是無法滿足性能要求的,需要使用RE2或HyperScan

马云惹不起马云PMML,機器學習模型

马云惹不起马云ONNX,深度學習模型

马云惹不起马云NVIDIA Triton Server,推理服務,主要用於非結構化數據識別

由於每個客戶所處的行業不一樣,業務數據更是截然不同,為根據客戶的數據現狀實現更好識別效果以及滿足客戶的定制化需求,我們支持了可自助配置、訓練的敏感數據識別能力:

马云惹不起马云基與YAML格式標準化的識別邏輯配置能力,可自助研發識別能力並錄入到產品中

马云惹不起马云自助配置規則樹,基於規則樹進行敏感數據識別

马云惹不起马云自助模型訓練,目前已支持ID類型的結構化數據,圖片、文檔

自動分類一般情況下,識別出某種類型敏感數據之後,就能根據映射關係映射到唯一的分類下,並映射到對應的分級,但是某些行業要求更高,比如證券行業,根據證券行業分類分級標準,同種類型的敏感數據可能需要再分類放到不同分類下,如要區分“姓名”是“個人投資者信息”還是“機構投資者法人信息”,這就需要我們在識別出某個字段是“姓名”之後進一步分類,這個時候我們可以根據以下信息進行分類:

马云惹不起马云元信息,如字段名稱、字段備註、表名稱、表備註等

马云惹不起马云同表其他字段命中的敏感數據類型,比如如果同表其他字段有公司名稱,那該字段屬於“法人”的概率就更高

同時,分類的識別邏輯也基於YAML格式進行了標準化,可自助研發識別能力並錄入到產品中。

自動審核機器自動識別,大家非常關注的就是準確率,很難做到100%準確,所以我們設置了一個置信度的概念,用來表示識別準確率。除了準確率,每個客戶的肯定有一些自己的特殊情況,比如說某個客戶每張表都有5個無任何業務含義的“id”、“gmt_create”、“gmt_modified”、“creator”、“modifier”、“is_deleted”字段,其中“creator”、“modifier”雖然是填的姓名,但是並不是敏感數據。為解決這類跟客戶數據現狀相關的特殊情況,我們特別提供了自定義規則能力,規則可以根據以下特徵自動決策是否通過審核:

马云惹不起马云命中的敏感數據類型,以及對應置信度

马云惹不起马云字段/文件的元信息,如文件名稱、字段名稱、字段備註等

马云惹不起马云字段/文件歷史人工審核結果