在當前國內信息安全熱潮中，數據脫敏作為數據安全的重要一環得到了業界的認可與重視。早在2012年，數據脫敏首次作為一個單獨的魔力象限由Gartner發布，Gartner在2014年又提出了：按照數據使用場景，將數據脫敏分為靜態數據脫敏(Static data masking-SDM )與動態數據脫敏(Dynamic data masking-DDM )。

可能有人望文生義，認為動態數據脫敏一定比靜態數據脫敏高級。非也非也，靜態or動態，取決于脫敏的使用場景，主要是以使用場景為由來選擇合適的數據脫敏的模式。

今天咱們就來理一理動態數據脫敏和靜態數據脫敏之間的區別，著重和大家分析下動態數據脫敏的原理、使用場景、部署方式等，一窺動態數據脫敏如何在隱私數據安全保護中發揮至關重要的左右。

一、動靜態數據脫敏“半斤八兩”

前面提到了，靜態數據脫敏與動態數據脫敏是按脫敏數據的使用場景來區分的。所謂的數據使用環境，主要是指業務系統脫敏之后的數據在哪些環境中使用，一般可分為生產環境和非生產環境(開發、測試、外包、數據分析等)。

• 靜態數據脫敏(SDM)：一般用在非生產環境，將敏感數據從生產環境抽取并脫敏后給到非生產環境使用，常用于培訓、分析、測試、開發等非生產系統的數據庫;
• 動態數據脫敏(DDM)：常用在生產環境，在訪問敏感數據即時進行脫敏，一般用來解決在生產環境需要根據不同情況對同一敏感數據讀取時進行不同級別脫敏的場景。

二、動態數據脫敏實現原理

動態數據脫敏是在用戶層對數據進行獨特屏蔽、加密、隱藏、審計或封鎖訪問途徑的流程，當應用程序、維護、開發工具請求通過動態數據脫敏(DDM) 時，實時篩選請求的SQL語句，依據用戶角色、權限和其他脫敏規則屏蔽敏感數據，并且能運用橫向或縱向的安全等級，同時限制響應一個查詢所返回的行數。

動態數據脫敏(DDM)以這種方式確保業務人員、運維人員以及外包開發人員嚴格根據其工作所需和安全等級訪問敏感數據。

三、動態脫敏系統的使用場景

本文選取業務脫敏、運維脫敏、數據交換脫敏三個使用場景分別展開介紹。

1. 業務脫敏

動態脫敏系統首先要解決的問題是，業務系統的普通用戶訪問應用系統時對數據權限的控制。正常情況下，業務系統開發時會依據用戶身份標識進行身份驗證后，不同的用戶進行限制數據的訪問。

如業務用戶在訪問某行數據時，只需要查看客戶個人信息的姓名、電話等信息，而不需要查看身份證號或家庭住址，故對身份證或家庭住址的顯示信息實行*號或其他方式進行脫敏處理。

對于遺留系統(舊系統無法再作升級改造)以及開發時未考慮《網絡安全法》中要求的個人隱私保護問題，如若重新更改代碼過于復雜，只能依賴于外部技術實現數據的隱私保護，這個時候也需要使用動態脫敏技術。

2. 運維脫敏

在信息安全的職責分離中，針對數據有三類人員：數據所有者、數據管理員、系統管理員。數據所有者是業務人員，而數據管理員(DBA)與系統管理員是運維人員.。

動態脫敏需求最為迫切需要的一個場景，就是針對數據庫的運維人員。運維人員擁有的是管理員帳號DBA賬號，但業務系統的數據是屬于業務單位而不是運維部門。從職責分離的原則上，如何實現既允許運維人員訪問業務生產數據庫又不能讓他們看到敏感數據?

以員工的工資表為例，當數據庫的運維人員使用高權限賬號查詢這類敏感表時，動態脫敏系統將自動將此敏感表(如工資表)的關鍵信息(工資)全部進行脫敏處理后再進行顯示，防止敏感信息泄露。

之前的技術手段是DAM技術方案，針對數據庫作訪問審計管理，針對DBA登陸后的一切操作進行記錄作為事后追溯。但這是一種被動的(事后)檢測性能力，對于隱私保護同時還需要有預防性(事前)的技術能力。這種針對DBA維護時數據脫敏就是動態脫敏中的運維脫敏。

3. 數據交換脫敏

動態脫敏還有一種不常見的使用場景：業務系統與業務系統之間的數據訪問(稱作數據交換更合適)。在滿足隱私保護時需要對交換的數據進行脫敏處理，但又不像傳統的靜態脫敏一樣需導出數據脫敏后再移交，而是通過業務系統之間的接口直接調用。這就屬于應用系統之間不落地的數據交換，針對這種交換的數據需要作脫敏處理。

四、動態脫敏系統的部署方式

1. 代理網關式

動態脫敏系統常見的一種部署模式,邏輯上是旁路,物理上是串行的方式。原本應用系統與數據庫建立連接,為了實現數據脫敏處理，應用系統的SQL數據連接請求轉發到脫敏代理系統,由動態脫敏系統解析請求后,再將SQL語句轉發到數據庫服務器，數據庫服務器返回的數據同樣經過動態脫敏系統后由脫敏系統返回給應用服務器。

這種部署方式可以實現，不在數據庫服務器與應用務器上安裝軟件就能進行脫敏處理,但這也需要更改應用務器對數據庫的調用地址，也就是說原來是由應用務器連接數據庫,現在改成應用服務器連接動態脫敏的代理網關。這種部署模式能針對應用用戶實現粗粒度的脫敏,也可實現針對運維脫敏的處理。存在的問題是，針對應用用戶無法實現用戶級的不同脫敏算法與效果，同時運維脫敏也存在被繞過的危險,DBA可能會繞過動態脫敏系統直接訪問數據庫地址。(國外Informatica 的產品就是常以這種方式部署)。

2. 透明網關式

這種部署模式是將動態脫敏系統串接在應用服務器與數據庫之間，由于動態脫敏系統能在OSI二層上工作，不需要IP地址，對應用服務器與數據庫服務器來說，都像原來一樣訪問各自的真實IP地址，動態脫敏系統通過協議解析分析出流量中的SQL語句來實現脫敏。這種部署方式不需要更改應用服務器與數據庫服務器的連接設置，但在網絡中會形成單點故障，雖然常常有BYPASS技術作為支撐，但所有流量都會經過網關，會造成網關性能瓶頸問題。(國外做數據庫防火墻的Imperva 等會采用這種方式，但動態脫敏只是其中小的功能，也只是針對少量的敏感數據采用這種脫敏方式。)

3. 軟件Agent代理方式

這種方式在數據庫服務器上安裝Agent, 監控對數據的訪問請求。當請求的數據是敏感數據時，Agent 會利用脫敏算法來對數據進行脫敏處理。這種部署方式需要在數據庫服務器上安裝軟件，帶來了好處是運維人員無法繞過。

五、動態脫敏在隱私保護與數據安全方案中作用

數據脫敏不只是一種新穎的數據操作，它已成為軟件生命周期和數據管理的核心內容。其中，靜態數據脫敏技術已被納入集成到軟件生命周期(SLC)，動態數據脫敏技術則成為數據管理過程中不可缺少的組成部分。