第3章 数据脱敏基本原理：分类、方法与策略

数据脱敏，说白了就是给敏感数据"打码"。跟视频里给证人脸部打马赛克一个道理。但我入行头两年，真以为脱敏就是简单地把身份证号中间几位换成星号。直到第一次在生产环境出了事故——测试库里的手机号没脱干净，被开发同学直接打印到了日志里。嗯，从那以后我才老老实实把"分类→方法→策略"这套东西啃透。

这一章我就把数据脱敏的骨架给你捋清楚。你掌握了大框架，后面各章节的工程落地才不会跑偏。

3.1 数据脱敏的核心分类

数据脱敏按"什么时候干这件事"分成两大类。这个分类直接决定了你的技术选型和架构设计。

我在项目中遇到最多的情况是：每周日凌晨2点，从生产库拉一份全量，脱敏完灌到测试集群。这种场景下，你可以放心做复杂的替换逻辑——时间不是瓶颈。

举个例子：客服系统查用户手机号，无权限的客服看到的是 138****5678，有权限的才看到完整号。数据在数据库里存的是明文，脱敏发生在返回结果的那一瞬间。

3.2 五大脱敏方法

方法就这五种，但组合起来能玩出花。我按工程落地频率排个序：

3.3 策略选择四维模型

选哪种方法，光看场景不够。我总结了一个四维策略选择模型，这也是我在多个项目里反复打磨出来的框架：

1. 可逆性需求——是否需要还原原始数据？需要则选加密，不需要则以替换/遮蔽为主。
2. 一致性保持——同一个身份证号在不同表里是否要保持脱敏后一致？需要则用确定性替换/加密。
3. 性能开销——每秒要处理多少行？批量场景可以上复杂规则，实时场景必须轻量。
4. 合规等级——GDPR/等保/金融监管对脱敏强度有硬性要求吗？有则不能只用遮蔽，必须配合加密或截断。

举个例子你就明白了。有一次做银行项目，客户要求"测试环境里的身份证号必须脱敏，但不同系统之间要能关联同一个客户"。这就是典型的高一致性+高可逆性场景。我们最终选了确定性加密——用客户号作为固定因子，保证同一个身份证号在任何表里都加密成同一串密文。

3.4 工程落地三原则

理论说完了，聊点实在的。我参与过6个脱敏平台的设计和重构，总结出三条铁律：

• 先分类，后脱敏——别急着写代码。先把数据资产按敏感等级打标：P0（直接可识别身份）、P1（间接可识别）、P2（业务数据）。不同等级用不同方法组合。
• 元数据驱动——脱敏规则不要硬编码。用配置中心或元数据平台管理，这样字段新增、规则变更都不用改代码。
• 结果可验证——脱敏不是"跑完就算"。必须做逆向校验：原始数据中能定位到个人的信息，在脱敏结果里是否还能定位到？我习惯在每个脱敏任务后自动跑一轮"重识别风险评估"。你想想看，如果脱敏后的数据还能通过多表关联定位到具体个人，那脱敏就等于没做。