數據脫敏是一種廣泛采用的保護敏感數據（如信用卡，社保卡，地址等信息）的方法。脫敏數據不僅僅是為了保護你和客戶的數據安全，在一些情況下，法律也有相應要求，最著名的例子就是 GDPR。 市面上也有各種不同的數據脫敏方法，例如遮擋，替換，洗牌和加密，適用于不同場景。通過對敏感數據進行脫敏處理，組織能夠降低數據泄露和未經授權訪問的風險，同時仍然能夠使用真實數據進行開發、測試和分析等任務。 本文來盤點一下 PostgreSQL 的幾種常用脫敏方式。

PostgreSQL Anonymizer

PostgreSQL Anonymizer 是個社區貢獻的擴展 (https://www.postgresql.org/about/news/postgresql-anonymizer-10-privacy-by-design-for-postgres-2452/)，可以為 PostgreSQL 添加不同的數據脫敏選項和方法。它將脫敏配置存儲在 PostgreSQL 的 SECURITY LABEL（安全標簽）中。

動態脫敏

PostgreSQL Anonymizer 實現動態脫敏的方式是通過將定義某個角色為 "MASKED" 以及脫敏規則。被授予 "MASKED" 角色的用戶將無法訪問原始數據，而其他角色仍然可以訪問。它現已支持多種的脫敏語法，你甚至可以編寫自己的規則。 這種方法有一定的局限性，例如在他們文檔中 (https://postgresql-anonymizer.readthedocs.io/en/latest/dynamic_masking/#limitations) 有提到，如果你同時使用脫敏插件和 GUI 工具如 DBeaver 或 pgAdmin 進行查詢的時候可能會出現問題；對于某些查詢來說，動態脫敏可能非常慢。此外，不同的脫敏變體需要不同的視圖，在角色或底層表發生變化時，這又很快變得難以管理起來。

靜態脫敏

PostgreSQL Anonymizer 還支持靜態脫敏，可以直接轉換原始數據集。比如可以用虛假數據替換原始數據，添加噪音或者混淆數據以隱藏敏感信息。 靜態脫敏的原則是更新包含至少一個被脫敏列的所有表的所有行。基本上意味著 PostgreSQL 將重寫磁盤上的所有數據。所以請注意，這種方法會破壞原始數據，并且是一個比較緩慢的過程。因此，在使用靜態脫敏之前，請三思而后行。

Bytebase 動態數據脫敏

Bytebase 動態數據脫敏 (https://www.bytebase.com/docs/security/data-masking/overview/)不依賴于 PostgreSQL 視圖或其用戶，而是通過 Bytebase 內部管理脫敏策略和授權管理。當用戶通過 SQL 編輯器查詢時，會自動應用動態脫敏策略。 Bytebase 動態數據脫敏包括以下組件：

全局脫敏規則：工作空間的「管理員」和「DBA」可以批量定義全局脫敏規則。例如，可以將所有名為 email 的列脫敏程度設置為「半脫敏」。這樣，修改脫敏策略就無需手動修改數千列了，還節省了維護視圖的麻煩。

列脫敏規則：工作空間的「管理員」和「DBA」可以將列設置為不同的脫敏級別。列脫敏規則優先于全局脫敏規則。

訪問未脫敏數據：對于脫敏數據，工作空間的「管理員」和「DBA」可以授予特定用戶訪問未脫敏數據的權限。

工作空間的「管理員」和「DBA」均為 Bytebase 的角色 (https://www.bytebase.com/docs/concepts/roles-and-permissions/)。

對比

PostgreSQL Anonymizer 的優勢在于它是在數據庫本身中實現的。因此，無論查詢如何發送到數據庫，數據脫敏規則都會被強制執行。對于 Bytebase 動態數據脫敏，查詢必須通過 SQL 編輯器才會強制執行。 Bytebase 動態數據脫敏的優勢在于其與所有 PostgreSQL 發行版都兼容，且支持細粒度的脫敏策略和訪問權限。只要團隊通過 Bytebase SQL 編輯器來查詢數據庫，那么 Bytebase 動態數據脫敏可以保障組織敏感數據的安全。

審核編輯：黃飛