數據脫敏
背景與目標
在數據倉庫建設過程中，數據安全扮演著重要角色，因為隱私或敏感數據的泄露，會對數據主體（客戶，員工和公司）的財產、名譽、人身安全、以及合法利益造成嚴重損害。因此我們需要嚴格控制對倉庫中的數據訪問，即什麽樣的人員或者需求才可以訪問到相關的數據。這就要求對數據本身的敏感程度進行安全級別劃分。數據有了安全等級的劃分，才能更好管理對數據訪問控制，以此來保護好數據安全。
舉個例子簡單的說明下，例如我們倉庫中有一張關於註冊用戶的基本信息表User，其中有手機號mobile，昵稱username兩個字段。我們在劃分數據安全層級的時，將用戶mobile的安全等級劃分為L2要高於username的等級L1，並規定只有訪問權限達到L2的運營部門才能訪問mobile字段。這樣在公司各個部門需要訪問註冊用戶基本信息表User時，我們只需檢查訪問者是否來自運營部門，如果是運營部可以訪問mobile，如果不是只能訪問username信息了。這樣就有效的防止用戶手機號被不相關工作人員泄露出去，同時也不影響查詢用戶username的需求。
但是往往在實際生產過程中，應用場景會更加復雜，僅靠類似這樣的訪問控制，滿足不了生產的需要，還需要結合其它的途徑，而數據脫敏就是一種有效的方式，既能滿足日常生產的需要，又能保護數據安全。
數據脫敏，具體指對某些敏感信息通過脫敏規則進行數據的變形，實現敏感隱私數據的可靠保護。這樣可以使數據本身的安全等級降級，就可以在開發、測試和其它非生產環境以及外包或雲計算環境中安全地使用脫敏後的真實數據集。借助數據脫敏技術，屏蔽敏感信息，並使屏蔽的信息保留其原始數據格式和屬性，以確保應用程序可在使用脫敏數據的開發與測試過程中正常運行。
敏感數據梳理
在數據脫敏進行之前，我們首先要確定哪些數據要作為脫敏的目標。我們根據美團特有的業務場景和數據安全級別劃分（絕密、高保密、保密、可公開，四個級別）， 主要從“高保密”等級的敏感數據，開始進行梳理。
這裏我們把敏感數據分成四個維度進行梳理，用戶、商家、終端、公司。
- 從用戶維度進行梳理可能有這些敏感字段如下：手機號碼、郵件地址、賬號、地址、固定電話號碼等信息（此外個人隱私數據相關還有如：種族、政治觀點、宗教信仰、基因等）
- 從商家維度進行梳理：合同簽訂人，合同簽訂人電話等（不排除全局敏感數據：如商家團購品類等）
- 從用戶終端維度進行梳理：能夠可能標識終端的唯一性字段，如設備id。
- 從公司角度進行梳理：交易金額、代金卷密碼、充值碼等
確定脫敏處理方法
梳理出了敏感數據字段，我們接下來的工作就是如何根據特定的應用場景對敏感字段實施具體的脫敏處理方法。
常見的處理方法如下幾種有：
- 替換：如統一將女性用戶名替換為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(最大程度上防止黑客進行破解)
以這次脫敏一個需求為例：
美團一般的業務場景是這樣的，用戶在網站上付款一筆團購單之後，我們會將團購密碼，發到用戶對應的手機號上。這個過程中，從用戶的角度來看團購密碼在未被用戶消費之前，對用戶來說是要保密的，不能被公開的，其次美團用戶的手機號也是要保密的，因為公開之後可能被推送一些垃圾信息，或者更嚴重的危害。從公司內部數據分析人員來看，他們有時雖然沒有權限知道用戶團購密碼，但是他們想分析公司發送的團購密碼數量情況，這是安全允許；再有數據分析人員雖然沒有權限知道用戶具體的手機號碼，但是他們需要統計美團用戶手機的地區分布情況，或者運營商分布差異，進而為更上層的決策提供支持。
根據這樣的需求，我們可以對團購密碼做加密處理保證其唯一性，也保留其原有的數據格式，在保密的同時不影響數據分析的需求。同樣，我們將用戶的手機號碼的前7位，關於運營商和地區位置信息保留，後四位進行模糊化處理。這樣同樣也達到了保護和不影響統計的需求。
因此從實際出發遵循上面的兩個處理原則，第一階段我們在脫敏工具集中，確定了如下4種基本類型的脫敏方案（對應4個udf）：
| 字段名稱 | 方案 | 舉例 | 原則 |
|---|---|---|---|
| 電話號碼（moblie） | 掩碼 | 13812345678-> 13812340000 | 防止號碼泄露，但保留運營商和地區信息 (唯一性，由前端綁定或者註冊時約束) |
| 郵件（email） | 截斷+ 加密 | [email protected] -> [email protected] | 保留郵件域信息 |
| 團購密碼（code） | 加密 | 4023926843399219 -> 1298078978 | 加密後在一定精度上保持唯一性，並與數據類型一致 |
| 設備號（deviceid） | 加密 | ffbacff42826302d9e832b7e907a212a -> b9c2a61972a19bf21b06b0ddb8ba642d | 加密後保持唯一性 |
確定實施範圍與步驟
通過上面字段的梳理和脫敏方案的制定，我們對美團數據倉庫中涉及到得敏感字段的表進行脫敏處理。在數據倉庫分層理論中，數據脫敏往往發生在上層，最直接的是在對外開放這一層面上。在實際應用中，我們既要參考分層理論，又要從美團現有數據倉庫生產環境的體系出發，主要在數據維度層（dim），以及基礎服務數據層（fact）上實施脫敏。這樣，我們可以在下遊相關數據報表以及衍生數據層的開發過程中使用脫敏後的數據，從而避免出現數據安全問題。
確認處理的表和字段後，我們還要確保相關上下遊流程的正常運行, 以及未脫敏的敏感信息的正常產出與存儲（通過更嚴格的安全審核來進行訪問）。
以用戶信息表user為例，脫敏步驟如下：
1．首先生產一份ndm_user未脫敏數據，用於未脫敏數據的正常產出。 2．對下遊涉及的所有依賴user生產流程進行修改，來確保脫敏後的正常運行，這裏主要是確認數據格式，以及數據源的工作。 3．根據對應的脫敏方法對user表中對應的字段進行脫敏處理。
總結
通過上面的幾個步驟的實施，我們完成了第一階段的數據脫敏工作。在數據脫敏方案設計與實施過程中， 我們覺得更重要的還是從特定的應用場景出發進行整體設計，兼顧了數據倉庫建設這一重要考量維度。數據脫敏實施為公司數據安全的推進，提供了有力支持。當然，我們第一階段脫敏的工具集還相對較少，需要補充。 脫敏的技術架構還有待完善和更加自動化。
本文關於數據安全和數據訪問隔離的控制闡述較少，希望通過以後的生產實踐，繼續為大家介紹。
數據脫敏