1、Tokenization与字段级加密的概念对比
做数据安全选型的时候，我经常被问到：“到底用 Tokenization 还是字段级加密？”这两个东西长得有点像，但其实骨子里完全是两套思路。我刚开始搞支付合规那会儿也混淆过，后来在几个项目里被现实教育了一顿，才算真正分清。
Tokenization：用替身代替真身
Tokenization 说白了就是拿一个无意义的令牌（）去替换敏感数据。原始数据被送到一个叫 vault 的安全仓库里，业务系统只存那个令牌。令牌本身没有数学关系，没法反推出原文，除非你去 vault 里查。
实战场景：信用卡号转 后，前端展示就是末四位 + 一个 ，后端存储也全是 。即使 DB 被拖走，攻击者拿到的只是一堆随机字符串。
我参与过一个电商平台的项目，当时 PCI DSS 合规要求不许明文存卡号。我们直接上了 Tokenization——调用支付网关的 服务，拿到 就存本地，卡号根本不落地。嗯，省心很多。
字段级加密：加把锁，钥匙自己管
字段级加密（有时也叫列级加密）是用对称或非对称算法直接加密敏感字段。密文存在库里，密钥单独管理。加密后的数据还是同一个字段，解密需要密钥。
和 Tokenization 最大的不同是：密文保留了原始数据长度格式？不一定。比如 AES 加密后往往变成 base64 串，长度会变，而且你没法对它做 SQL 模糊查询。我曾经在一个医疗项目里用字段级加密存身份证号，结果业务方抱怨没法按身份证前六位做地区统计……确实，这就是代价。
核心差异对比表
| 维度 | Tokenization | 字段级加密 |
|---|---|---|
| 本质 | 映射替换，令牌无数学关联 | 加密运算，密文可逆（有密钥） |
| 存储 | 需要 vault 存映射关系 | 只需要存密文字段和密钥 |
| 是否可逆 | 只能通过 vault 查回原文 | 有密钥即可解密 |
| 格式保留 | 可以保留格式（如 FF1 算法） | 大部分加密会改变格式长度 |
| 可搜索性 | 支持精确匹配（ 本身是索引） | 不支持模糊搜索，精确匹配需特殊处理 |
| 性能开销 | 一次映射查询，非常快 | 加解密计算，有一定延迟 |
| 合规场景 | PCI DSS、PII 脱敏首选 | GDPR、数据所有权要求高的场景 |
工作流程对比
让你直观感受一下两者在实际调用链路上的差别。下面这张图是我自己画的，左边是 Tokenization 的典型流程，右边是字段级加密的典型流程。
选型时的直觉判断
- 如果要过 PCI DSS、存卡号、存身份证号——Tokenization 更省心，不用操心密钥旋转和算法合规。
- 如果业务需要频繁解密原文做统计/分析——字段级加密更灵活，只要密钥保管好，随时解密。
- 如果对查询性能敏感——Tokenization 默认支持精确匹配，字段级加密要做特殊索引或者用确定性加密，代价不小。
- 如果数据必须保留格式——Tokenization 可以用 FF1 格式保留加密，字段级加密通常做不到格式不变。
一个现实中的坑
我曾经在一个 SaaS 项目里试图“两头讨好”——对同一批敏感数据同时用 Tokenization 做脱敏展示、用字段级加密做后台统计。结果 vault 和密钥管理系统互相打架，数据同步出现缝隙，最后不得不重构。我的建议是：先选一个主方案，非必要不混用。
小结
Tokenization 和字段级加密不是谁替代谁的关系，它们解决的场景有重叠但也有明显边界。你的业务是偏合规脱敏，还是偏数据价值挖掘？想清楚这个，选型方向就清晰了。