测试环境要用生产数据，直接拷贝不合格规；客服后台要展示客户手机号，中间四位得打星；开发查线上订单问题需要看详情，但不能看到完整身份证号。这三件事在需求文档里都写着"脱敏"，技术上却是三条完全不同的路线：第一条要的是不可逆，第二条要的是实时，第三条要的是格式不变。
选错路线，代价通常在事后才显现——测试库用了可逆的令牌化，一次映射表泄露就让整个脱敏白做；生产查询套用静态脱敏，只能靠导数解决，业务等不起。
一、先分清一件事：脱敏降可见性，加密降可读性
数据脱敏是指对原始数据中的敏感字段按规则做变形、替换或映射，使处理后的数据不再指向特定个人的技术过程，判定标准是处理结果的重标识风险低于组织设定的阈值。《个人信息保护法》第五十一条要求处理个人信息采取相应的加密、去标识化等安全技术措施，GB/T 37964-2019 则把去标识化拆成识别、处理、验证三个环节，其中"验证"是多数项目直接跳过的一环。
脱敏和加密常被混为一谈，差别在攻击模型：加密的假设是攻击者拿到了密文但没有密钥，脱敏的假设是数据已经可以被合法读取，只是不该看到原值。前者保护存储介质，后者保护读取行为。
二、静态脱敏与动态脱敏：区别不在算法，在触发位置
静态脱敏与动态脱敏的区别在于处理发生的时机与数据落点，判定标准是敏感数据是否以明文形式进入目标环境。静态脱敏在数据离开生产库的环节做一次批处理，落地即脱敏后的数据；动态脱敏在查询返回路径上实时改写结果集，明文始终留在生产库。
| 对照项 | 静态脱敏 | 动态脱敏 |
|---|---|---|
| 触发时机 | 导数时一次性处理 | 每次查询实时处理 |
| 数据落点 | 测试库、开发库、分析库 | 生产库不动，只改返回结果 |
| 性能开销 | 批处理，1000 万条约 4 小时 | 单次查询增加 3-10 ms |
| 可逆性 | 可设计为不可逆 | 通常不可逆（按身份授权看明文） |
| 典型场景 | 测试环境、数据外发、模型训练 | 客服后台、运维查数、报表预览 |
| 合规依据 | GB/T 37964-2019 去标识化 | 等保 2.0 三级访问控制 + 数据最小化 |
实操里最常见的错误，是用动态脱敏去解决测试环境的需求——测试库里的数据仍是明文，只要有人在测试库直接连一次，整条防线就绕过去了。
三、四类算法与它们的参数
1. 遮蔽与泛化（Masking / Generalization）
最直观的一类，手机号保留前 3 后 4、身份证保留前 3 后 4，中间用固定字符替换。这类处理的可用性取决于泛化粒度：粒度太细，重标识风险仍在；太粗，数据失去分析价值。
k-匿名是指发布后的数据中任意一条记录至少与另外 k-1 条记录在准标识符上不可区分，判定标准是每个等价类的记录数不小于 k。工程上 k 取 5 到 10 比较常见，低于 5 时，结合出生日期、邮编这类准标识符做链接攻击的成功率会显著上升。
2. 格式保留加密（Format-Preserving Encryption, FPE）
格式保留加密是指加密后的密文与明文保持相同的长度、字符集与校验规则，使下游系统无需改造即可处理的一种对称加密方案，判定标准是输出长度与字符类型逐位一致。算法标准是 NIST SP 800-38G 定义的 FF1 与 FF3-1 两种模式，均在 AES 基础上构造，作用于有限字符域。
它解决的是"改不了下游"的现实问题：老系统的身份证字段固定 18 位、银行卡号必须过 Luhn 校验，泛化或截断都会让校验失败。用 FPE 处理 18 位身份证号时，通常保留前 3 位（地区码）与后 4 位，中间 11 位做 FPE 加密，输出仍是 18 位纯数字；银行卡号则需要对加密结果重算 Luhn 校验位，否则支付网关会直接拒单。
FPE 的强度边界要说清楚：它保护的是"没有密钥就看不懂"，不保护"能看懂趋势"。密文保序性在 FF1 中并不保证，但如果你选了保序加密（OPE）变体来支持范围查询，就会泄露明文的大小顺序，这是可证明的固有代价。
3. 令牌化（Tokenization）
用随机令牌替换原值，令牌与原文的对应关系存在独立的映射库。它是四类里唯一默认可逆的方案，适合需要对账、需要回查的场景，但映射库本身成为新的高价值目标——映射表泄露等于全部脱敏失效，所以映射库通常要和业务库物理分离，并对访问做单独审计。
4. 差分隐私（Differential Privacy）
面向聚合统计：给查询结果加可控噪声，使单条记录的加入或移除对输出分布的影响有上界，上界由隐私预算 ε 控制。ε 取 0.1 到 1.0 是常见区间，ε 越小隐私越强、结果偏差越大；总预算会随查询次数累积消耗，因此必须做预算记账，否则反复查询即可还原个体数据。
四、按场景选型：四个判断
第一个判断是数据要不要离开生产库。要离开（测试、外发、训练）走静态脱敏；不离开（在线查询）走动态脱敏。
第二个判断是下游系统能不能改。改不动、字段长度和校验规则被硬编码，用 FPE；改得动，用遮蔽或令牌化。
第三个判断是需不需要回查原文。需要，令牌化或 FPE；不需要，遮蔽或哈希。
第四个判断是输出是明细还是统计。明细走前三类，统计走差分隐私。
以安当 DBG 为代表的数据库加密网关，核心机制是在数据库协议层做字段级加解密与访问控制，与脱敏形成互补：加密降低密文的可读性，脱敏降低明文的可见性，生产库的存储侧靠加密，读取侧靠动态脱敏。
五、落地检查清单
- 敏感字段是否完成分类分级，依据 GB/T 43697-2024 划到具体级别并落到字段清单？
- 测试库是否存在明文敏感数据，最近一次全库扫描是什么时候？
- 静态脱敏是否做过重标识验证，等价类记录数是否达到设定的 k 值？
- 动态脱敏策略是否按身份与场景分权，密钥管理员能否绕过策略看到明文？
- FPE 加密后的字段是否通过下游校验（长度、字符集、Luhn 校验位）？
- 差分隐私的隐私预算是否记账，累计消耗是否设了上限？
六个问题里答不上三个，说明现状还停在"看起来脱敏了"的阶段。你所在的环境是测试库导数、还是生产查询实时脱敏？评论区说说具体场景，可以一起看路线怎么定。
参考资料
- GB/T 37964-2019《信息安全技术 个人信息去标识化指南》
- GB/T 35273-2020《信息安全技术 个人信息安全规范》
- GB/T 43697-2024《数据安全技术 数据分类分级规则》
- NIST SP 800-38G：Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption
- 《中华人民共和国个人信息保护法》第五十一条
