轉載請註明出處:http://blog.csdn.net/dongdong9223/article/details/81032427
本文出自【我是幹勾魚的博客】
1 數據脫敏的定義
常用的安全防護技術包括:數據庫漏掃、數據庫加密、數據庫防火牆、數據脫敏、數據庫安全審計系統。這其中,數據脫敏是數據安全防護的重要技術手段,在現代社會的信息安全防控體系中扮演着重要的角色。
具體來說,數據脫敏是指:
對某些敏感信息通過脫敏規則進行數據的變形,實現敏感隱私數據的可靠保護。在涉及客戶安全數據或者一些商業性敏感數據的情況下,在不違反系統規則條件下,對真實數據進行改造並提供測試使用,如身份證號、手機號、卡號、客戶號等個人信息都需要進行數據脫敏。
貴州省推出的地方標準政府數據數據脫敏工作指南,也就是DB 52/T 1126—2016也曾對數據脫敏進行了定義:
從原始環境向目標環境進行敏感數據交換的過程中,通過一定方法消除原始環境數據中的敏感信 息,並保留目標環境業務所需的數據特徵或內容的數據處理過程。
簡單來講,可以理解爲某些敏感數據不想直白的完全展示出來,而進行部分處理再進行展示的過程。數據脫敏技術作爲安全防護技術手段之一,在信息技術的安全生產、使用中都起着重要的作用。
2 數據脫敏的原則
2.1 技術原則
在技術層面上,數據脫敏須遵循包括有效性,真實性,高效性,穩定性,可配置性等五個原則,如下圖所示:
具體內容如下:
-
有效性:有效的移除敏感信息。
-
真實性:爲保證脫敏後數據的正常使用,應儘可能真實的保留脫敏後數據的有意義信息,以保證對業務特徵的支持。
-
高效性:在保證安全的前提下,儘可能減少脫敏代價。
-
穩定性:在輸入條件一致的前提下,對相同的脫敏數據,經過多次脫敏仍然獲得相同的穩定結果。
-
可配置性:可以配置處理結果和處理字段,以根據應用場景獲得相應的脫敏結果。
2.2 管理原則
在管理層面上,數據脫敏須遵循包括敏感信息識別,安全可控,安全審計,代碼安全等四個原則,如下圖所示:
具體內容如下:
-
敏感信息識別:應根據數據的信息分類,明確敏感信息的範疇;對於有些信息,本身不直接是敏感信息,但與其它信息結合後會被推斷出敏感信息,這樣的信息也應被納入數據脫敏的範疇。
-
安全可控:對於脫敏後仍保留了部分信息特徵而存在泄露風險的信息,要採用合適的安全管理手段防止數據泄露。
-
安全審計:在數據脫敏環節中應加入安全審計機制,用於數據追蹤和問題溯源。
-
代碼安全:對執行數據脫敏的程序應做好代碼審查,以及上線時的安全掃描,保證數據脫敏過程的安全可靠。
3 保存方式
信息領域的業務是不斷變化的,信息的保存方式也隨之改變。數據脫敏過程中,數據信息的保存方式與具體的業務場景有關,要視具體的業務需求而定。
3.1保留明文+密文
數據既可以展示密文,也可以展示明文;底層數據庫既保留明文,也保留密文。
這種方式相對靈活,脫敏操作可以從保存的脫敏數據中直接取出,也可以根據脫敏策略對明文數據加密後再顯示。
3.2 只保留密文
數據展示密文,底層數據庫只保留密文。
某些有審計要求的環境是不允許保留明文數據的,這種情況下數據信息只保留脫密後的密文信息。而數據分析、查詢等與明文數據相關的操作,要根據密文信息與加密邏輯統一處理。
3.3 只保留明文
數據層展示密文;底層數據庫只保留明文。這種方式密文數據實時處理,沒有持久化。
數據信息也可以只在展示的時候以密文的形式展示,而數據存儲以明文的形式保存。這種情況下,數據分析、查詢等日常的業務操作較爲簡單,但每次數據展示要根據脫密邏輯進行實時數據脫密,比較消耗系統資源。
4 處理對象
對數據源的支持。最好能支持多種異構類型的數據源,或者區分形態進行支持。
4.1 關係型數據庫
針對關係型數據庫的數據脫密,如MySQL、Oracle、PostgreSQL、SQLServer等。
4.2 非關係型數據庫(大數據)
針對非關係型數據庫如大數據生態系統的數據脫密,如Hive、Hbase等。
5 脫敏邏輯
脫敏邏輯是數據脫敏功能的核心,具體的脫敏邏輯要根據數據特點並結合具體的業務場景進行設計和分析。常用的有以下幾種形式。
5.1 數據替換
將原有數據信息進行數值替換,例如將身份證號碼全部替換成簡單的無差別號碼,如圖:
5.2 無效化
例如講過地址信息部分或全部隱藏使其無效,如圖:
5.3 隨機化
例如將個人姓名採用其它隨機文字替換,如圖:
5.4 數據偏移與數據取整
數據偏移與數據取整主要用在時間數據的脫密處理上,將原時間信息通過偏移的手段得到取整的數據,原有數據如圖:
處理後的數據:
5.5 掩碼屏蔽
例如,對身份證號的信息遮掩掉其中的一部分數據,原有數據如圖:
處理後的數據如圖:
6 方案類型
6.1 新上線業務
新上線業務在數據脫敏上的處理相對簡單。由於從業務之初就會爲數據脫敏環節做準備,新業務在設計階段即開始考慮數據脫敏的處理過程。值得注意的是,從無到有的信息脫敏過程,既要滿足數據脫敏的技術原則,又要滿足數據脫敏的管理原則。
6.2 已上線業務
已有業務實施數據脫敏要考慮的事情比較多,需要根據業務場景具體問題具體分析。
6.2.1 停工法
某些情況下,生產環境的系統已經非常成熟,數據脫敏的邏輯也很明確,而且生產環節並不緊迫。這種情況下,可以考慮先將數據脫敏的設計工作做完善,然後將生產環境短暫停止,將數據脫敏模塊加入後,再將生產環節重新啓動。停工法的思路同新上線業務是類似的。
6.2.2 複製法
大多數生產環境都比較緊迫,因爲加入數據脫敏而停工的成本消耗代價太大了,或者無法實現。這種情況下,一種比較穩妥的解決方案是:
準備一個與生產環境一樣的預發佈環境,或者稱爲預發環境,
使用遷移洗數工具將生產環境原有存量明文數據進行脫密處理後,保存到預發環境中;而生產環境的新增數據則可以使用例如MySQL的主從複製功能,並結合業務方自己開發的清洗工具進行數據脫敏後,保存到預發環境的數據庫中。
通過這種方式同時保存了兩套處於實時同步中的運行環境:生產環境保存的是明文數據,以明文數據進行查詢修改;預發環境保存的則是脫敏數據,以脫敏數據進行查詢修改。兩套環境同步運行一段時間穩定後,就可以在合適的時候將新增的生產流量數據切換到預發環境中,形成數據依賴的無縫遷移。