做数据安全方案时最常见的卡点：需求方说「这批数据要处理一下」，你手里只有两个词——脱敏和加密，选错了要么开发白干，要么上线后被审计打回来。这篇不给结论式口号，给的是判断顺序：先看数据要拿去干什么，再倒推该用哪种，顺带把两者混用时的坑列出来。
做数据安全方案时最常见的卡点：需求方甩过来一句「这批数据要处理一下」，你手里只有两个词——脱敏和加密。选错了要么开发白干一轮，要么上线后被审计打回来重做。这篇不给结论式口号，给的是判断顺序：先看数据接下来要拿去干什么，再倒推该用哪种，顺带把两者混用时最容易踩的坑列出来。
先明确一点：脱敏和加密不是同一件事的两个档位，也不是可以互相替代的备选。它们防的对象不一样——一个防的是有权限看数据的人，一个防的是不该拿到数据的人。搞清楚这一点，后面的选型基本就是顺水推舟。如果你还想对照各家模型和 API 在数据安全上的说明，可以到 /models 里翻当时的资料，别凭印象拍板。
两者到底在解决什么问题：一个改内容，一个改形态
脱敏改的是数据本身：让看到的人拿不到真实值，代价是不可逆，或者需要额外维护一张映射表才能还原。加密改的是数据的形态：内容没变，但没钥匙看不懂，拿到钥匙就完全恢复。这个差别决定了它们适用的环节完全不同，别指望用一个顶两个。
| 对比维度 | 脱敏 | 加密 |
|---|---|---|
| 改的是什么 | 数据内容本身 | 数据的存储/传输形态 |
| 谁能看懂 | 拿到结果的人看到的是假值 | 持钥方可完全还原明文 |
| 是否可逆 | 多为不可逆，可逆需映射表 | 本身就可逆 |
| 主要防谁 | 有权限看的内部人 | 不该拿到的人，如拖库、链路窃听 |
| 典型位置 | 测试库、报表、外包交付 | 传输链路、落盘存储、备份 |
| 失败后果 | 映射表泄露等于没做 | 密钥泄露等于没做 |
- 判断口径一句话：脱敏防「有权限看的人」，加密防「不该拿到的人」——前者对应内部使用场景，后者对应传输和存储环节。
- 常见误区是以为做了其中一个就够了：加密后的字段对持钥方仍然是明文，脱敏后的字段一旦映射表泄露也就等于没做。
- 什么情况下不适用：业务方明确要求「随时能还原原值」时，纯单向脱敏就不合适，得考虑可逆方案外加独立的权限管控。
- 两者可以叠加但不能互相顶替：先加密保证链路和落盘安全，再对要给人看的那部分做脱敏，顺序反了通常白忙。
选型判断顺序：先问用途，再问谁能看，最后才挑技术
很多人一上来就纠结用哪种算法、哪个库，其实方向错了。选型应该从业务用途倒推，技术是最后一步。按下面三步走，大部分场景十分钟内就能定下来。
- 第一步：问数据接下来干什么进测试库、进分析报表、给外包看，还是只是存起来防拖库。用途不同，答案基本就定了：给人看的多半脱敏，只给系统读的多半加密。
- 第二步：问谁能看到结果只有系统读，还是有人要肉眼看。有人肉眼看就得脱敏，否则他看到的还是明文；只有系统读、且系统有密钥管理能力，加密更省事。
- 第三步：才落到实现脱敏参考方法对照——掩码、替换、泛化、假名化；加密区分传输加密和存储加密，重点确认密钥放在哪、谁能取。
- 反过来自查也成立上线前先确认加密链路没漏，再确认对外字段真脱敏了，两层各自独立验证，不要互相替代。
判断顺序清楚了，具体选哪种实现、用哪个库，还要看当时的生态和团队能力。站内工具目录里有一些常用方案的对照，具体条目到 /tools/speed-test 看当时的清单，不要照搬别人博客里的老配置。
落地时最容易踩的四个坑
概念清楚不代表落地顺利。下面这四个坑，是数据安全评审里出现频率最高的，踩中了轻则返工重则重做方案，建议在动手前先对着排一遍。
- 脱敏做在查询之后：数据已经完整落到日志、缓存或中间表里了，再脱敏等于没做，要检查的是整条链路的落点，不只是最终接口。
- 加密做在应用层但密钥写在配置里：等于把钥匙和保险箱放一起，密钥管理得单独拎出来，至少不能跟代码同库同权限。
- 脱敏后忘了处理关联字段：手机号掩码了，但订单号、身份证尾号还拼得回原值，这种组合还原是审计常挑的点。
- 以为一次配置永久有效：字段含义变了、新增导出路径、换了合作方，都要重新过一遍，跟着数据流走而不是跟着代码走。
怎么快速发现这些坑
最省事的办法是做一次「模拟泄露」：假设某一层数据被完整拿走——比如日志、比如备份、比如某个外包的导出文件——看能从中还原出多少真实信息。还原得越多，说明那一层的防护越虚。这个动作比逐行读代码快得多，也更容易说服需求方加预算。
一份可以直接照着走的落地清单
把前面的判断落成动作，就是下面这份清单。建议在方案评审前逐条打勾，缺哪条补哪条，比事后补救便宜得多。
- 先列数据流图数据从哪来、经过哪些存储和日志、谁在什么场景能看到。这一步不做，后面全是猜，评审时也说不清风险在哪。
- 按可见性给字段分两组「对外可见」和「仅系统读」分开，分别决定脱敏还是加密，别整库一刀切。一刀切的结果通常是该保护的没保护、不该改的被改坏。
- 两侧各自确认关键点脱敏侧确认不可逆，或者映射表有独立权限；加密侧确认密钥不在代码库、不在日志、有轮换办法。这两条是硬门槛。
- 上线前跑一次模拟泄露假设某一层被拿走，能还原出多少真实信息，用这个结果回头补配置。补完再跑一遍，直到还原不出有效信息为止。
如果你在选具体工具或比对不同服务的实现能力，站内目录里有按场景分类的条目，价格和能力数据到 /price-watch 核对当时的数字，别拿旧截图当依据。中转站相关组件的可信度也可以到 /rankings 看当时的评测结果。
下一步光看原理不够，动手前把数据流图和字段分组列出来，再去站内目录按场景挑实现方案，能省掉一轮返工。→常见问题
脱敏和加密能同时用在同一个字段上吗？
可以，顺序上一般先脱敏再加密，或者按用途分层：内部系统看到的是脱敏值，落盘和传输再套一层加密。但要留意两者叠加会带来还原链路变长，出问题排查更麻烦。如果只是单点需求，通常选一种并把权限管好就够，叠加不是默认选项。
只做加密不做脱敏，合规上够用吗？
看场景。如果数据只在传输和存储环节存在风险、且没有任何人需要看到明文，加密基本够。但只要有测试、分析、外包、客服这类「有人要看」的场景，加密解决不了问题，因为持钥的人看到的还是原值。这类场景该把脱敏补上，具体口径可以到 安全与合规 分区核对。
脱敏之后是不是就不用管权限了？
不是。脱敏降低的是单条记录的可读性，但多条记录的组合、时间序列、关联字段仍可能还原出个体信息。所以脱敏后仍需控制谁能查、能查多少、能导多少。反过来也一样，权限管控不能替代脱敏，两者是叠加关系。
