動態數據脱敏（DDM）動態更改返回給應用程序或用户的數據庫記錄，以此來實時保護敏感數據，且不會更改靜態數據。

DDM 與靜態數據脱敏（SDM）不同。SDM 創建原始數據永久更改、不可逆轉的副本，而 DDM 則是在訪問時對數據進行即時修改。這種動態方法可確保敏感數據在查詢執行過程中受到保護，而不會改變靜態的基礎數據。

（一）應用場景

SDM 的主要應用場景是創建安全、經過「消毒」的產品數據，供非生產環境使用。而 DDM 則主要用於生產環境，根據用户角色、許可或其他關聯因素，動態控制對敏感數據的訪問。這樣，企業就可以保護敏感信息，而無需更改底層數據。因此，DDM 是實時數據訪問場景中維護安全性和合規性的有力工具。

（二）數據脱敏複雜度

數據脱敏的複雜度主要源於其動態性質。系統必須根據各種運行環境，實時決定如何以及何時進行數據脱敏。這些環境包括：

用户環境

• 基於角色的訪問： 不同的用户或角色可能有不同程度的數據訪問權限。DDM 必須根據用户的身份動態調整數據的可見性，確保只有經授權的用户才能看到未屏蔽形式的敏感信息。
• 用户位置和設備： 在某些情況下，數據訪問可能會受到用户位置（如企業網絡內外）或所用設備的影響。DDM 必須能夠動態考慮這些變量。

時間環境

• 臨時訪問： 用户可能需要臨時訪問權限來解決緊急情況。
• 日期和時間敏感性： 某些數據可能只在特定時間段內被視為敏感數據，這就要求 DDM 對其行為做出相應調整。

目標數據庫列

• 特定列脱敏： 數據庫中的不同列可能需要不同的脱敏技術或規則。DDM 必須根據訪問的特定列動態應用適當的屏蔽算法。
• 複雜數據類型： 處理複雜數據類型（如列中的 JSON 或 XML）會增加額外的複雜度，因為 DDM 必須解析並選擇性地對這些結構中的內容脱敏。

應用環境

• 特定環境脱敏： 脱敏規則有時需要隨應用程序的運行環境（如開發、測試、UAT、生產）而改變。DDM 必須識別環境並應用適當級別的脱敏。
• 業務項目或用例： 不同的業務項目或用例可能有獨特的數據訪問要求。

脱敏算法

• 算法選擇： DDM 必須根據上下文動態選擇最合適的數據脱敏算法，確保數據仍然有用，同時還能保護敏感信息。算法可能包括隨機、標記、部分脱敏等技術。
• 算法複雜度與性能： 脱敏算法的選擇對性能有直接影響。DDM 需要在算法提供的安全性與儘量減少性能開銷之間取得平衡，確保查詢執行時間保持在可接受的水平。

性能

鑑於 DDM 的動態特性，其中一個關鍵挑戰是如何最大限度地降低與實時脱敏相關的性能開銷。這就需要優化脱敏邏輯，確保其既高效又可擴展，尤其是在高流量環境中。

（三）數據庫支持

主流商業數據庫都支持 DDM。不過，MySQL 和 PostgreSQL 這兩種最流行的開源數據庫都不支持開箱即用的 DDM。對於那些受支持的數據庫，DDM 是通過擴展 SQL 語法實現的。以 Snowflake 為例：

CREATE OR REPLACE MASKING POLICY email_mask AS (val string) RETURNS string ->
  CASE
    WHEN CURRENT_ROLE() IN ('ANALYST') THEN val
    ELSE '*********'
  END;

-- apply masking policy to a table column
ALTER TABLE IF EXISTS user_info MODIFY COLUMN email SET MASKING POLICY email_mask;

數據庫引擎只提供數據脱敏的基礎。為整個組織全面配置脱敏策略仍然是一個巨大的挑戰。

Bytebase 提供 GUI 和 API 來配置動態數據脱敏。

值得一提的是，Bytebase 支持 MySQL 和 PostgreSQL。