原文地址 https://www.bytebase.com/blog/what-is-dynamic-data-masking/
动态数据脱敏（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。
💡 更多资讯，请关注 Bytebase 公号：Bytebase
