令牌化 vs 加密 vs 掩码：三者的区别、适用场景与安全性对比
我做了这么多年的数据安全工程，有一个问题被问得最多：「令牌化、加密、掩码，到底该选哪个？」说实话，很多同行把这三个东西混为一谈。更糟的是，选错了方案，项目上线后被审计追着打。今天我就把它们的本质掰开来讲清楚。
别以为名字有点像就能互相替代。它们的数学原理、可逆性、格式保持能力、合规要求，差得远了去了。我当年第一次做支付系统时，就踩过「用加密代替令牌化」的坑。嗯，我们先从最基础的定义说起。
1. 三种技术，各是什么？
令牌化（Tokenization）：用一段无意义的代币（）替换敏感数据。代币本身没有数学还原能力，还原必须靠安全的映射表（ Vault）。
加密（Encryption）：通过算法和密钥将明文变成密文。只要你有密钥，就能解密回去。对称加密（如 AES）和非对称加密（如 RSA）都是可逆的。
掩码（Masking）：对数据的一部分进行遮盖或替换，比如信用卡号显示为 4000-xxxx-xxxx-xxxx。掩码通常是不可逆的，但有些动态掩码会在授权后临时显示完整数据。
一句话总结：令牌化是「换掉」，加密是「变乱」，掩码是「遮住」。三者最核心的差异在于可逆性和映射关系。
2. 核心区别一览表
我把三者在工程实践中最重要的几个维度整理成了一张表。你拿去可以直接贴到技术方案里。
| 维度 | 令牌化 (Tokenization) | 加密 (Encryption) | 掩码 (Masking) |
|---|---|---|---|
| 可逆性 | 需查 Vault（不可计算还原） | 有密钥即可还原 | 通常不可逆（静态掩码） |
| 格式保持 | 可以（如 PAN 保留长度） | 通常不保持（除非 FPE） | 完全保持原始格式 |
| 密钥管理 | 无需管理密钥（管 Vault 就行） | 必须管理密钥生命周期 | 无需密钥 |
| 计算开销 | 低（查表 / 生成随机值） | 中高（算法运算） | 极低 |
| 合规认可度 | PCI DSS 首选 | PCI DSS 可接受（但范围大） | 仅用于展示，不能替代存储 |
| 适用存储场景 | 生产 DB、数据湖 | 传输、静态存储 | 日志、测试、报表 |
你看，令牌化在合规和开销上有天然优势，但代价是你得维护一个 Vault。加密需要密钥管理，一旦密钥泄露，所有数据就全完了。掩码最轻量，但千万别用它来「保护」原始数据——掩码后的数据仍然容易被逆向，尤其当掩码规则太简单时。
有一次我给客户做 PCI DSS 合规方案，对方说「我们把信用卡号加密存就行了，不用令牌化」。我说：「你加密后的字段依然属于 PAN 范围，审计会要求你保护整个数据库。而令牌化之后， 本身不被认为是敏感数据，审计范围大幅缩小。」最后他们接受了令牌化方案。
3. 各自适用的场景
我习惯用一个简单的决策模型来选型：先看数据的使用方式，再看合规要求，最后考虑成本。
3.1 什么时候用令牌化？
- PCI DSS 合规：信用卡主账号（PAN）必须令牌化。这是标准答案。
- 需要保留数据格式的跨系统传输：比如支付网关后端的订单系统，必须用一个 16 位的 替代原卡号去执行授权。
- 高频访问但不需要原值：数据仓库里做用户分析，用 代替身份证号，既合规又简单。
3.2 什么时候用加密？
- 数据需要在系统中被解密使用：比如业务系统需要根据用户手机号查找订单，但手机号在存储时必须加密。
- 传输链路保护：端到端加密，比如 API 请求中的敏感字段。
- 对称加密用于跨组织数据共享：双方约定密钥，你加密我解密。
3.3 什么时候用掩码？
- 生产数据的测试/开发环境：把真实手机号、身份证号掩码后再给开发人员用。
- UI 展示：客服界面只显示卡号后四位，原始数据留存在后台。
- 日志脱敏：避免把明文 PII 写入日志文件。
千万不要做的事情：用掩码替代令牌化或加密。我曾经见过一个项目，用简单掩码规则（比如把数字替换为 'X'）存储卡号，结果攻击者通过频率分析还原出了部分卡号。掩码只适合「展示时模糊化」，不适合「存储时保护」。
4. 安全性对比：谁最安全？
这个问题不能一刀切。安全性的强弱取决于攻击模型。
| 攻击场景 | 令牌化 | 加密 | 掩码 |
|---|---|---|---|
| 数据库被拖库 | 安全（ 无意义） | 取决于密钥是否同库被拿 | 极危险（掩码模式可逆向） |
| 内部人员越权访问 | 需攻破 Vault 权限 | 需拿到密钥 | 几乎无保护 |
| 量子计算攻击 | 不受影响（无算法依赖） | 对称加密受影响小，非对称受影响大 | 不受影响 |
| 合规审计风险 | 低（缩小范围） | 中（密钥管理审计） | 高（掩码数据仍属敏感数据） |
从纯密码学角度，加密的数学强度是最高的，但工程上加密方案往往因为密钥管理不善而变成纸老虎。令牌化则把风险集中在 Vault 上——你只要把 Vault 保护好了，整个系统的安全性就稳了一大半。掩码在安全性上根本排不上号，它只是「视觉遮挡」。
5. 一张图看懂三者的关系和选型路径
下面这张 SVG 图总结了三个技术的核心特征，以及它们在工程中的定位。你可以把它画在白板上，或者放进技术文档里。
6. 工程中的避坑指南
我踩过的坑，你最好别再踩一次。
- 别把 AES 加密和令牌化混用：有些团队把加密后的密文当成 用，结果密文长度变长，格式保持不了，下游系统全崩了。我当初就是这样的受害者，后来老老实实改成了 Vault 方案。
- 掩码规则不要太简单：如果你只把数字换成 'X'，攻击者可以通过已知格式推导出完整数据。我建议用「部分保留 + 随机字符」的方式，比如身份证号只保留前三位和后四位，中间用随机大写字母填充。
- 令牌化 Vault 的可用性：Vault 一旦挂了，所有需要还原 的服务都会停。记得做多活部署。我见过一个银行项目，Vault 单点故障让支付网关停了 40 分钟。
- 加密的密钥轮换：不要嫌麻烦。很多公司在密钥没过期之前就泄露了。我习惯每年最少轮换一次，并且用 HSM 存储密钥。
最后说一句实在的：选型没有银弹。如果你问我在一个高合规的金融场景里我会怎么选？我个人习惯是：存储用令牌化，传输用加密，展示用掩码。三管齐下，但各司其职。