4. 令牌化技术分类：格式保留令牌化、随机令牌化、哈希令牌化
做数据安全的同行应该都有体会——选令牌化方案时，最纠结的不是技术会不会，而是"到底该用哪一种"。我个人在项目中被问到最多的问题就是：这三种技术到底该怎么选？别急，这一章咱们就把它们拆开揉碎了讲清楚。
4.1 三种技术的核心差异
令牌化技术说白了就是"把敏感数据替换成一个替代值"。但替代的方式不同，安全性、可用性、合规效果也天差地别。目前业界主流就三类：格式保留令牌化（FPE）、随机令牌化、哈希令牌化。
它们最根本的区别在于：令牌是否保留原始数据的格式，以及映射关系是否可逆。你想想看，这两个维度直接决定了你的改造工作量、安全等级和审计路径。
4.2 格式保留令牌化（FPE）
FPE 的全称是 Format-Preserving Encryption，也叫格式保留加密。它的特点是：令牌和原始数据长得一模一样。比如信用卡号 6222 1234 5678 9012，令牌化之后还是 6222 xxxx xxxx xxxx 这种16位数字格式，连前六位 BIN 码都能保留。
我记得在一个金融项目里，客户要求改造核心交易系统，但明文信用卡号散落在几十张表里，改 Schema 的代价高到离谱。最后我们选了 FPE：数据库字段类型、长度、校验逻辑完全不用动，只把数据加密成格式相同的令牌。嗯，改造周期从预估的6个月压缩到了2个月。
核心价值：FPE 最大的优势就是零 Schema 改造，特别适合存量系统、遗留数据库、或者与第三方接口有严格格式约定的场景。
4.3 随机令牌化
随机令牌化就简单粗暴多了——生成一个随机字符串，扔进映射表，把原始值和令牌值存起来。令牌本身没有格式限制，可以是任意字母数字组合，长度也可以自己定。
为什么还要用它？因为安全性高。令牌和原始数据之间没有任何数学关联，即使攻击者拿到了令牌库，也推不出原始数据。我建议你在高敏感字段上优先考虑随机令牌化，比如身份证号、手机号、银行账号……这些字段不需要保留格式，安全第一。
实践技巧：随机令牌的生成要注意碰撞概率。可以用 UUID + 自增序列 + 随机盐值组合，或者直接用 CSPRNG（密码学安全伪随机数生成器）产出的字节序列。映射表一定要做访问审计，谁查了谁，一查便知。
4.4 哈希令牌化
哈希令牌化用的是单向哈希函数——输入原始数据，输出固定长度的哈希值。和 FPE、随机令牌化最大的不同是：它不需要映射表。令牌是通过算法直接算出来的，没有存储映射关系的成本，也没有映射表被拖库的风险。
但哈希不是万能的。我踩过一个坑：早期项目中用 SHA-256 直接哈希身份证号，结果忘了加盐。上线不到一周，安全团队用彩虹表就把部分哈希值还原了——虽然哈希不可逆，但彩虹表可以穷举常见值做匹配。嗯，那之后我再也不敢不加盐了。
重要提醒：哈希令牌化必须加盐！而且盐值要足够随机、足够长（至少16字节），每个字段最好用不同的盐。另外，哈希算法要选抗碰撞的，SHA-256 或 SHA-3 是底线，不要用 MD5 或 SHA-1。
4.5 三种技术全方位对比
下面这张表是我自己项目里常用的选型对照表，三种技术在每个维度上的表现一目了然。
| 对比维度 | 格式保留令牌化 (FPE) | 随机令牌化 | 哈希令牌化 |
|---|---|---|---|
| 数据格式保持 | 完全保留（长度、字符集、校验位） | 不保留（格式可变） | 不保留（固定长度哈希值） |
| 可逆性 | 可逆（需密钥解密） | 可逆（通过映射表） | 不可逆（单向函数） |
| 映射表依赖 | 不需要（算法直接加解密） | 需要（存储令牌-原文映射） | 不需要（无映射表） |
| 安全性 | 中等（算法公开，依赖密钥管理） | 高（令牌与原文无数学关联） | 高（加盐后抗彩虹表） |
| 存量系统改造成本 | 低（字段类型/长度不变） | 中（需新增令牌列或映射表） | 中（需新增哈希列） |
| 典型适用场景 | 信用卡号、身份证号（需保留格式） | 手机号、邮箱、银行账号 | 密码、密钥校验、数据指纹 |
| 合规支持（GDPR/PCI DSS） | 支持（可审计、可解密） | 支持（映射表可审计） | 支持（不可逆，适合脱敏展示） |
4.6 选型建议与避坑指南
坦白说，没有哪种技术是银弹。选型时我一般会问自己三个问题：
- 存量系统能不能改？如果数据库表已经跑了好几年，改字段长度会引发连锁反应，FPE 是第一选择。
- 还原需求是什么？业务上需要从令牌找回原始数据吗？需要就用 FPE 或随机令牌化；不需要就用哈希，省去映射表管理成本。
- 合规审计怎么过？监管要求追溯原始数据时，FPE 和随机令牌化都能满足；如果只是展示脱敏后的数据，哈希完全够用。
曾经有个教训：某项目组对手机号用了哈希令牌化，结果业务方需要做手机号模糊查询匹配——哈希值根本没法做 LIKE 查询。最后只能重建映射表，数据回填折腾了两周。所以选型前一定先拉上业务方，把查询场景问清楚。
好了，三种技术的分类和对比就聊到这儿。每种技术的内部原理和代码实现，后面章节会逐一展开。你只需要记住一点：选型没有标准答案，搞清楚你的数据特征、业务约束和合规底线，答案自然就出来了。