漫談數據安全

|0x00 數據安全體系全貌

|0x01 一般意義上的數據安全流程

數據安全流程包括以下幾個步驟:

  1. 數據的產生:通過數據分級體系對敏感字段打標籤;

  2. 數據的存儲:需要通過加密的方式存儲相關數據,避免直接存儲Text格式的數據;

  3. 數據的使用:包括了一個獨立的權限控制系統;

  4. 數據的傳輸:相關的申請與查詢操作需要通過專門的API接口進行,並且有高安全等級的加密措施

  5. 數據的展示:在申請通過後,根據申請人的安全等級,展示對應等級的數據;

  6. 數據的銷燬:敏感數據僅在HDFS上做邏輯刪除是不夠的,需要配合物理刪除同步清理敏感數據。

|0x02 數據表分級標準

數據表分級的目標,在於通過設置合理的等級,加強對數據倉庫平臺下數據表的安全管理,確保敏感數據的增刪改查操作都能夠經過適合的授權。由於開發人員爲使用便捷,數據表的安全等級通常存在安全等級設置偏低的情況,因而需要根據數據表中安全等級最高的字段進行表安全等級的設定

以前文提到的數據使用的安全標準爲例,包括業務重要程度及計算關聯範圍兩個象限,簡略的將數據表安全設置爲四個等級:

S4:非業務核心表,刪除對於其他計算任務無影響;

S3:非業務核心表,但刪除對於其他計算任務有一定的影響;

S2:業務核心表,僅限本部門使用,刪除對於其他部門使用無影響;

S1:業務核心表,刪除對於其他部門使用有影響。

實際上,可以根據自身公司的業務情況,設置更多的安全等級,以標示不同業務場景下的數據安全情況,本文僅提出一個可參考的案例。

但很多情況下,大量的敏感數據是混雜在普通表中的,例如針對搜索廣告系統,核心指標有三個:展現量、點擊量及消費量,幾乎所有不同維度的統計都需要涉及到這三個指標,因此只針對數據表的分級可能不夠用,需要針對字段加入安全標準評分

例如以用戶統計的中間表爲例,常見的統計指標除了上述提到的三個敏感字段之外,還包括了用戶量、訪問ip數、創意數量、單元數量等指標,這些非核心的字段安全等級爲S2,但三個敏感字段的安全等級爲S1,因此整張表從全局上看,應該設置爲字段安全等級最高的級別,也就是S1

不論是數據表,還是數據字段,通常都需要開發人員、產品人員甚至是運營人員介入進行人工的制定,但爲了簡化打標籤的流程,通常是開發人員進行初步設定,指派一名數據安全接口人進行二次審覈,並將字段的涵義明確的填入元數據平臺之中。

同時,如果元數據平臺包括了訂閱接口人等功能,在有修改數據安全等級等操作後,還需要郵件通知相關訂閱人,防止下游任務不知情導致的數據計算錯誤。

|0x03 自動標籤機制

很多時候,數據表並不只是由數據開發人員創建,產品、數據分析、運營等人員操作數據表,自行建立中間查詢過程,也是需要被允許的,因而有必要設定一套自動數據標籤的體系,來對初始創建的數據表進行自動的安全等級檢定。

但該步驟極度依賴規範化的數據規則,例如同一種統計指標,只對應一種英文涵義。例如在搜索廣告中,每次搜索的結果爲搜索量,每次搜索中帶有的廣告展示稱之爲展現量,在英文名的設定上,show對應搜索量,ad_show對應廣告展現量。這種規範化的體系應該貫穿在元數據平臺及數據開發平臺的建設上,例如在開發平臺上使用Select *應該是被禁止的,需要準確寫出Select show纔可以展示對應數據。

自動標籤機制能夠根據預設的安全等級規則,例如show對應S2級別,ad_show對應S1級別,既可以準確標註其字段等級。其餘字段,只要是常用的業務字段,也應該有明確的英文名稱。最典型的是經緯度,字段統一命名爲:longitude / latitude,系統可自動設定安全等級爲S4。

當自動標籤機制設定完成後,整理的授權流程如下所示:

  1. 使用人員新建任務

  2. 系統掃描表字段,基於規則自動建立標籤;

  3. 開發 / 安全人員根據規則升級 / 降級對應表等級

  4. 通知相關人員權限變更。

|0x04 權限申請

權限申請類似於財務報銷一樣,需要經過層級審批纔可以使用。通常來說S2及以下字段可以直接由數據安全接口人審批,S1需要數據安全接口人、使用人的直屬上級領導兩層審批。

數據權限的審批應遵循如下幾個原則:

  1. 權限只根據需求進行授予,不能授予超過需求使用的字段及等級;

  2. 不允許直接查詢底層表,只能查詢中間表以上的數據表;

  3. 不允許查詢全量數據,只可以根據字段進行查詢,並且必須要有where條件;

  4. S2及以上數據,不允許直接下載,僅可以在雲端查看;

  5. 只能夠以單張表爲單位,逐個申請,不允許一次性申請大範圍的表權限。

|0xFF 風險管理

  1. 由於權限問題設計人員比較廣,因此離職員工需要及時收回權限

  2. 權限申請時,應該設定權限申請的時間,例如一天/一週/長期;非開發人員,如果權限申請時間過長,應該及時收回;

  3. 如果申請了權限而長期不使用,出於安全性考慮,也應該定期掃描並收回

  4. 申請權限時,如有必要,應填寫數據披露申請單,詳細說明申請的原因,用於後續問題的排查。

熱門文章

直戳淚點!數據從業者權威嘲諷指南!

數據分析師做成了提數工程師,該如何破局?

全棧型VS專精型,團隊到底需要什麼樣的人?

數據驅動業務,比技術更重要的是思維的轉變

最近面了十多個數據分析師,聊一聊我發現的一些問題

【您的在看,我的莫大鼓勵】

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章