數據脫敏

背景與目標

在數據倉庫建設過程當中，數據安全扮演着重要角色，由於隱私或敏感數據的泄露，會對數據主體（客戶，員工和公司）的財產、名譽、人身安全、以及合法利益形成嚴重損害。所以咱們須要嚴格控制對倉庫中的數據訪問，即什麼樣的人員或者需求才能夠訪問到相關的數據。這就要求對數據自己的敏感程度進行安全級別劃分。數據有了安全等級的劃分，才能更好管理對數據訪問控制，以此來保護好數據安全。

舉個例子簡單的說明下，例如咱們倉庫中有一張關於註冊用戶的基本信息表User，其中有手機號mobile，暱稱username兩個字段。咱們在劃分數據安全層級的時，將用戶mobile的安全等級劃分爲L2要高於username的等級L1，並規定只有訪問權限達到L2的運營部門才能訪問mobile字段。這樣在公司各個部門須要訪問註冊用戶基本信息表User時，咱們只需檢查訪問者是否來自運營部門，若是是運營部能夠訪問mobile，若是不是隻能訪問username信息了。這樣就有效的防止用戶手機號被不相關工做人員泄露出去，同時也不影響查詢用戶username的需求。

可是每每在實際生產過程當中，應用場景會更加複雜，僅靠相似這樣的訪問控制，知足不了生產的須要，還須要結合其它的途徑，而數據脫敏就是一種有效的方式，既能知足平常生產的須要，又能保護數據安全。

數據脫敏，具體指對某些敏感信息經過脫敏規則進行數據的變形，實現敏感隱私數據的可靠保護。這樣可使數據自己的安全等級降級，就能夠在開發、測試和其它非生產環境以及外包或雲計算環境中安全地使用脫敏後的真實數據集。藉助數據脫敏技術，屏蔽敏感信息，並使屏蔽的信息保留其原始數據格式和屬性，以確保應用程序可在使用脫敏數據的開發與測試過程當中正常運行。

敏感數據梳理

在數據脫敏進行以前，咱們首先要肯定哪些數據要做爲脫敏的目標。咱們根據美團特有的業務場景和數據安全級別劃分（絕密、高保密、保密、可公開，四個級別）， 主要從「高保密」等級的敏感數據，開始進行梳理。

這裏咱們把敏感數據分紅四個維度進行梳理，用戶、商家、終端、公司。

1. 從用戶維度進行梳理可能有這些敏感字段以下：手機號碼、郵件地址、帳號、地址、固定電話號碼等信息（此外我的隱私數據相關還有如：種族、政治觀點、宗教信仰、基因等）
2. 從商家維度進行梳理：合同簽定人，合同簽定人電話等（不排除全局敏感數據：如商家團購品類等）
3. 從用戶終端維度進行梳理：可以可能標識終端的惟一性字段，如設備id。
4. 從公司角度進行梳理：交易金額、代金卷密碼、充值碼等

肯定脫敏處理方法

梳理出了敏感數據字段，咱們接下來的工做就是如何根據特定的應用場景對敏感字段實施具體的脫敏處理方法。

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

1. 替換：如統一將女性用戶名替換爲F，這種方法更像「障眼法」，對內部人員能夠徹底保持信息完整性，但易破解。
2. 重排：序號12345重排爲54321，按照必定的順序進行打亂，很像「替換」， 能夠在須要時方便還原信息，但一樣易破解。
3. 加密：編號12345加密爲23456，安全程度取決於採用哪一種加密算法，通常根據實際狀況而定。
4. 截斷：13811001111截斷爲138，捨棄必要信息來保證數據的模糊性，是比較經常使用的脫敏方法，但每每對生產不夠友好。
5. 掩碼: 123456 -> 1xxxx6，保留了部分信息，而且保證了信息的長度不變性，對信息持有者更易辨別， 如火車票上得身份信息。
6. 日期偏移取整：20130520 12:30:45 -> 20130520 12:00:00，捨棄精度來保證原始數據的安全性，通常此種方法能夠保護數據的時間分佈密度。

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

1．remain meaningful for application logic(儘量的爲脫敏後的應用,保留脫敏前的有意義信息) 2．sufficiently treated to avoid reverse engineer(最大程度上防止黑客進行破解)

以此次脫敏一個需求爲例：

美團通常的業務場景是這樣的，用戶在網站上付款一筆團購單以後，咱們會將團購密碼，發到用戶對應的手機號上。這個過程當中，從用戶的角度來看團購密碼在未被用戶消費以前，對用戶來講是要保密的，不能被公開的，其次美團用戶的手機號也是要保密的，由於公開以後可能被推送一些垃圾信息，或者更嚴重的危害。從公司內部數據分析人員來看，他們有時雖然沒有權限知道用戶團購密碼，可是他們想分析公司發送的團購密碼數量狀況，這是安全容許；再有數據分析人員雖然沒有權限知道用戶具體的手機號碼，可是他們須要統計美團用戶手機的地區分佈狀況，或者運營商分佈差別，進而爲更上層的決策提供支持。

根據這樣的需求，咱們能夠對團購密碼作加密處理保證其惟一性，也保留其原有的數據格式，在保密的同時不影響數據分析的需求。一樣，咱們將用戶的手機號碼的前7位，關於運營商和地區位置信息保留，後四位進行模糊化處理。這樣一樣也達到了保護和不影響統計的需求。

所以從實際出發遵循上面的兩個處理原則，第一階段咱們在脫敏工具集中，肯定了以下4種基本類型的脫敏方案（對應4個udf）：

字段名稱	方案	舉例	原則
電話號碼（moblie）	掩碼	13812345678-> 13812340000	防止號碼泄露，但保留運營商和地區信息 (惟一性，由前端綁定或者註冊時約束)
郵件（email）	截斷+ 加密	hxs@163.com -> 6225888e3a1d4a139f5f5db98d846102b2cd0d@163.com	保留郵件域信息
團購密碼（code）	加密	4023926843399219 -> 1298078978	加密後在必定精度上保持惟一性，並與數據類型一致
設備號（deviceid）	加密	ffbacff42826302d9e832b7e907a212a -> b9c2a61972a19bf21b06b0ddb8ba642d	加密後保持惟一性

肯定實施範圍與步驟

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

確認處理的表和字段後，咱們還要確保相關上下游流程的正常運行, 以及未脫敏的敏感信息的正常產出與存儲（經過更嚴格的安全審覈來進行訪問）。

以用戶信息表user爲例，脫敏步驟以下：

1．首先生產一份ndm_user未脫敏數據，用於未脫敏數據的正常產出。 2．對下游涉及的全部依賴user生產流程進行修改，來確保脫敏後的正常運行，這裏主要是確認數據格式，以及數據源的工做。 3．根據對應的脫敏方法對user表中對應的字段進行脫敏處理。

總結

經過上面的幾個步驟的實施，咱們完成了第一階段的數據脫敏工做。在數據脫敏方案設計與實施過程當中， 咱們以爲更重要的仍是從特定的應用場景出發進行總體設計，兼顧了數據倉庫建設這一重要考量維度。數據脫敏實施爲公司數據安全的推動，提供了有力支持。固然，咱們第一階段脫敏的工具集還相對較少，須要補充。 脫敏的技術架構還有待完善和更加自動化。

本文關於數據安全和數據訪問隔離的控制闡述較少，但願經過之後的生產實踐，繼續爲你們介紹。