漫談資料安全-老闆擔心敏感資料洩露，該如何建設安全的資料體系？_王老獅

theme: cyanosis

背景

隨著資料的不斷迭代，資料種類和體量越來越多，那麼資料的保護以及如何防止敏感資料的洩漏是當前面臨比較大的挑戰。

資料安全的痛點

解決資料誤刪除問題；
解決敏感資料洩露問題；
生產環境和測試環境隔離

痛點問題解決方案

如何解決資料誤刪問題

資料的備份與恢復

一、冷備

通過對物理檔案的拷貝也可達到備份的效果，但是需要注意的是通過拷貝物理檔案進行備份期間，要避免資料寫入。一般用於歷史歸檔資料的備份。

二、熱備

文字檔案匯入匯出
ClickHouse通過其 ALTER TABLE…FREEZE 功能提供了對即時時間點備份的本地支援。
Clickhouse-Backup

資料備份解決方案

1、文字匯入匯出

需要額外格式化儲存檔案，並且資料量較大，將資料以結構化檔案匯出方式不限時，並且存在資料洩漏問題。

2、ALTER TABLE…FREEZE 資料影子

Freeze是基於分割槽來進行備份的，通過freeze對指定分割槽進行備份後，CK會將改分割槽的資料儲存在${datadir}/shadow目錄下，shadow目錄下的N是一個自增長的整數，表示freeze執行的次數。

freeze的備份本質上是通過對原始目錄檔案進行硬連結實現的，所以不會導致額外的空間儲存上漲。

3、Clickhouse-Backu

第三方實現的資料備份工具，可以實現將ALTER TABLE…FREEZE手動執行過程改為自動執行

4、其他廠商資料備份方案

網易：網易 HDFS 資料的備份，是基於 HDFS 快照 + DistCp + EC 實現的。

垃圾回收箱機制

資料刪除之後可以保留24-72小時，如果後悔刪除可以及時恢復。HDFS本身支援垃圾回收機制，對於使用Clickhouse如果想要支援只能自己實現。

優點：防止資料被誤刪，增加資料的安全性

缺點：增加運維成本和儲存資料成本。

資料的備份策略應該和資料資產等級打通，對於核心資料資產，資料中臺應該強制進行備份，防止資料丟失。

敏感資料洩露問題

敏感資料解決問題核心要點

解決敏感資料洩漏問題主要從兩個角度來處理

最小化資料許可權，資料操作審計
敏感資料脫敏

操作審計機制以及精細化許可權管理

資料許可權是資料中臺實現資料複用的前提和必要條件。如果剛開始系統沒有開啟許可權，後期接入許可權，任務的改造成本會非常高的，幾乎涉及到所有的任務。所以許可權這個問題，在資料中臺構建之初，必須提前規劃好。

阿里資料開發流程

阿里整個資料安全主要靠流程體系管控，通過使用者提資料需求單後，將資料指標管理起來，根據資料指標研發去申請對應表許可權，進行資料開發

整個開發生命週期涉及到了，指標管理，業務表許可權申請，資料同步數倉資料質量分析，維度建模，BI報表管理，資料的產生到應用的血緣管理，報表使用次數分析等，平臺流程體系搭建以及所使用技術主要為自研。

網易資料安全解決方案

網易是通過OpenLDAP(使用者管理) + Kerberos(非安全網路雙向認證) + Ranger(許可權管理) 實現的一體化使用者、認證、許可權管理體系。

Clickhouse本身支援RBAC許可權控制支援角色，使用者，行級許可權以及整合Kerberos和LDAP。

資料脫敏

資料脫敏，具體指對某些敏感資訊通過脫敏規則進行資料的變形，實現敏感隱私資料的可靠保護。這樣可以使資料本身的安全等級降級，就可以在開發、測試和其它非生產環境以及外包或雲端計算環境中安全地使用脫敏後的真實資料集。藉助資料脫敏技術，遮蔽敏感資訊，並使遮蔽的資訊保留其原始資料格式和屬性，以確保應用程式可在使用脫敏資料的開發與測試過程中正常執行。

脫敏實施步驟

1、敏感資料梳理

在資料脫敏進行之前，我們首先要確定哪些資料要作為脫敏的目標。我們根據業務場景和資料安全級別劃分（絕密、高保密、保密、可公開，四個級別），主要從“高保密”等級的敏感資料，開始進行梳理。

這裡我們把敏感資料分成四個維度進行梳理，使用者、商家、終端、公司。

從使用者維度進行梳理可能有這些敏感欄位如下：手機號碼、郵件地址、賬號、地址、固定電話號碼等資訊（此外個人隱私資料相關還有如：種族、政治觀點、宗教信仰、基因等） 2.從商家維度進行梳理：合同簽訂人，合同簽訂人電話等（不排除全域性敏感資料：如商家團購品類等）
從使用者終端維度進行梳理：能夠可能標識終端的唯一性欄位，如裝置id。
從公司角度進行梳理：交易金額、代金卷密碼、充值碼等

2、確定脫敏處理方法

梳理出了敏感資料欄位，我們接下來的工作就是如何根據特定的應用場景對敏感欄位實施具體的脫敏處理方法。

常見的處理方法如下幾種有：

替換：如統一將女性使用者名稱替換為F，這種方法更像“障眼法”，對內部人員可以完全保持資訊完整性，但易破解。
重排：序號12345重排為54321，按照一定的順序進行打亂，很像“替換”，可以在需要時方便還原資訊，但同樣易破解。
加密：編號12345加密為23456，安全程度取決於採用哪種加密演算法，一般根據實際情況而定。
截斷：13811001111截斷為138，捨棄必要資訊來保證資料的模糊性，是比較常用的脫敏方法，但往往對生產不夠友好。
掩碼: 123456 -> 1xxxx6，保留了部分資訊，並且保證了資訊的長度不變性，對資訊持有者更易辨別，如火車票上得身份資訊。
日期偏移取整：20130520 12:30:45 -> 20130520 12:00:00，捨棄精度來保證原始資料的安全性，一般此種方法可以保護資料的時間分佈密度。

但不管哪種手段都要基於不同的應用場景，遵循下面兩個原則：

1．remain meaningful for application logic(儘可能的為脫敏後的應用,保留脫敏前的有意義資訊)

2．sufficiently treated to avoid reverse engineer(最大程度上防止黑客進行破解)

| 欄位名稱 | 方案 | 舉例 | 原則 | | ------------- | ------ | -------------------------------------------------------------------- | ------------------------------------- | | 電話號碼（moblie） | 掩碼 | 13812345678-> 13812340000 | 防止號碼洩露，但保留運營商和地區資訊 (唯一性，由前端繫結或者註冊時約束) | | 郵件（email） | 截斷+ 加密 | [email protected] -> [email protected] | 保留郵件域資訊 | | 團購密碼（code） | 加密 | 4023926843399219 -> 1298078978 | 加密後在一定精度上保持唯一性，並與資料型別一致 | | 裝置號（deviceid） | 加密 | ffbacff42826302d9e832b7e907a212a -> b9c2a61972a19bf21b06b0ddb8ba642d | 加密後保持唯一性 |

3、確定實施範圍與步驟

通過上面欄位的梳理和脫敏方案的制定，資料倉庫中涉及到得敏感欄位的表進行脫敏處理。在資料倉庫分層理論中，資料脫敏往往發生在上層，最直接的是在對外開放這一層面上。在實際應用中，我們既要參考分層理論，又要從現有資料倉庫生產環境的體系出發，主要在資料維度層（dim），以及基礎服務資料層（fact）上實施脫敏。這樣，我們可以在下游相關資料報表以及衍生資料層的開發過程中使用脫敏後的資料，從而避免出現數據安全問題。

確認處理的表和欄位後，我們還要確保相關上下游流程的正常執行, 以及未脫敏的敏感資訊的正常產出與儲存（通過更嚴格的安全稽核來進行訪問）。

以使用者資訊表user為例，脫敏步驟如下：

1．首先生產一份ndm_user未脫敏資料，用於未脫敏資料的正常產出。

2．對下游涉及的所有依賴user生產流程進行修改，來確保脫敏後的正常執行，這裡主要是確認資料格式，以及資料來源的工作。

3．根據對應的脫敏方法對user表中對應的欄位進行脫敏處理。

開發與生產物理環境隔離

通用資料開發方案

共享元資料

測試和線上環境共享一套線上元資料
資料儲存和資源管理
在同一套元資料中，測試環境的資料儲存在func庫中，生產則儲存在online庫中，保證測試開發不影響到生產
任務執行和配置依賴根據環境自動選擇庫。實現不需要修改程式碼一鍵釋出。
優點：

直接使用生產環境進行測試，效率高
缺點：

存在生產資料洩漏風險

適用於效率優先的場景。

金融級別的資料安全方案

完全隔離

資料開發環境與生產環境完全隔離
大資料操作平臺和資料儲存完全部署兩套
資料開發需要對資料進行開發和測試是需要同步生產環境部分資料到測試環境，資料需要脫敏。
任務在測試環境開發，配置任務依賴，設定稽核規則和報警，通過運維審批之後釋出一鍵釋出到生產環境

優點:

資料安全實現最高級別的保護。開發人員不需要指導資料細節和具體的資料內容

缺點：

兩套環境，每次資料開發需要從線上同步資料到測試環境，資料開發效率影響比較大
需要建立完整的流程體系。包括資料許可權審批，資料同步流程。開發完成後資料的釋出流程
資料準確性難以保障，測試環境測完很可能存在一些未發現的問題

各廠商資料安全對比

| 公司 | 資料備份 | 許可權控制 | 資料脫敏 | 環境隔離 | | ------ | ------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ | -------------------------------------------------------- | | 阿里 | 歷史歸檔資料冷備定期資料進行熱備有垃圾回收箱機制 | 標準化資料開發流程業務資料許可權審批使用者許可權精確到數倉列級；資料血緣支援資料到報表級; 資料流出以及流轉都有系統支援，使用審計資料訪問痕跡自研技術 | 內部開發主要對使用者的敏感資訊進行脫敏，資料落盤和傳輸一般不會對資料脫敏。支援資料傳輸脫敏支援資料落盤脫敏 | 使用同一套生產環境元資料，根據執行的不同環境將計算結果儲存不同環境的數倉中。 | | 網易 | 歷史歸檔資料冷備對資料進行分級，每24小時對重點資料進行快照備份。有垃圾回收箱機制是基於 HDFS 快照 + DistCp + EC 實現的 | 標準化資料開發流程業務資料許可權審批使用者許可權精確到數倉列級；資料血緣支援資料到報表級， OpenLDAP(使用者管理) + Kerberos(非安全網路雙向認證) + Ranger(許可權管理) 實現的一體化使用者、認證、許可權管理體系。 | 資料敏感度分級支援資料傳輸脫敏支援資料落盤脫敏支援應用層脫敏脫敏後的資料不參與維度計算 | 使用同一套生產環境元資料，根據執行的不同環境將計算結果儲存不同環境的數倉中。 | | 恆生 | 定期根據資料重要級別做一些備份 | 資料開發許可權管控沒有具體流程 | 部分資料本地分析，客戶資訊脫敏後上雲。具體客戶賬戶金額相關資料不會做分析。主要對使用者隱私資訊進行脫敏 | 分為本地環境和雲端資料。敏感資料會經過本地處理之後上雲，供雲端的資料運營平臺使用。主要還是和線上共用一套資料。 |

根據調研，當前網際網路大廠主要還是使用生產環境進行資料開發，極少數金融級別可能會做生產環境的和測試環境的完全隔離。主要控制敏感資料洩漏還是依賴流程許可權控制，保證每個職責和崗位的人員能看到的資料最小化原則。對於使用者敏資料進行脫敏處理，保證相關人員拿不到使用者詳細資料。

主要還是秉承著幾個原則，保證資料許可權最小化粒度

健全的資料開發流程體系，許可權申請策略。
資料流轉生命週期全鏈路可見，可分析
資料細節可見不可得
誰申請的資料許可權誰負責，誰是資料woner誰對資料質量負責。

資料安全體系建設資料

安全體系建設架構圖

安全體系建設建設實施步驟

資料資產梳理

梳理當前有的資料資產，當前有哪些資料，按照主題域進行分類歸檔
定義敏感資料的範疇，文件化輸出敏感資料的定義範圍
發現敏感資料，制定敏感資料管理辦法。根據資料資產分級進行不同的許可權管控辦法。比如L4級別資料直接業務woner進行審批即可，L0級別資料需要部門領導審批。需要授權才能使用和檢視

資料許可權控制

明確資料需求匯入方式，以流程工單方式進行提交資料報表的申請，統一資料指標管理入口，控制資料需求匯入，統一管理資料需求

定義資料開發流程，建立業務資料責任制度，誰產生的資料誰對資料質量負責

定義資料開發業務庫許可權申請流程，需要使用那幾張表申請那幾張表許可權，記錄表許可權所有者，最小化粒度管理資料許可權。誰申請誰對資料負則。

資料報表的開發與測試，保證資料報表釋出之後提供給業務方有許可權申請記錄，並且資料報表使用次數以及歷史檢視記錄有機可尋，也可以分析報表使用頻率，對於不頻繁使用的報表可以下架節省對應的資料資源

保證資料可見但不可得，保證只能看到單條資料細節不支援批量檢視敏感資料細節。

資料脫敏

制定資料脫敏策略，什麼樣資料型別使用什麼的脫敏策略
支援資料生命週期過程中進行脫敏，如從資料採集落到ODS層就進行脫敏，還是在數倉提供給上層應用時進行脫敏要支援策略性的配置。
脫敏後的資料是不支援維度分析。