1. Tokenization 基础概念与核心原理

说到 Tokenization，我刚开始接触的时候也觉得新鲜。

说白了，就是把敏感数据（比如银行卡号、身份证号）替换成一个毫无意义的「令牌」（）。

这个令牌跟原数据长得不一样，但能通过系统里的映射关系找回原数据。

举个例子：你的真实卡号 6222 0200 1234 5678，在系统里存成 TK-9A8B-7C6D。

即使数据库被拖走，黑客拿到也只是一堆无意义的随机字符串。

这里有一个关键区别：加密后的密文仍然保留数学规律，而令牌是完全随机生成的。

我早年做过一个支付项目，当时用 AES 加密卡号，结果泄露后攻击者根据密文长度和模式推断出了部分卡号……从那以后我就认定了：敏感字段必须用 Tokenization，不能只靠加密。

1.1 为什么需要 Tokenization

• 合规驱动：PCI DSS、GDPR、金融监管都要求「存储最小化」。 不是原始数据，可以绕过很多审计。
• 降低风险：数据库泄漏时， 本身没有价值。
• 保持系统兼容： 可以设计成和原始数据相同长度、格式，后端代码改动极小。

我记得有个金融客户，原本在日志里明文打印了交易流水号，里面嵌着身份证号。整改后我们用 替代，日志照样能查，但风险瞬间降为零。

1.2 Tokenization vs 其他方案的对比

方案	是否可逆	密钥管理	适用场景
Tokenization	可逆（需映射表）	无需密钥	数据脱敏、支付卡号
对称加密（AES）	可逆（密钥）	需要	传输加密
哈希（SHA‑256）	不可逆	无需	密码存储
格式保留加密（FPE）	可逆（密钥）	需要	保留格式的加密

你想想看，加密还有个「密钥泄露」的问题，Tokenization 这边根本就没有密钥。映射表放在隔离的 Vault 里，攻击者必须同时攻破业务系统和 Vault 才能拿到原数据。

1.3 核心工作原理

1. 请求到达：业务系统收到原始敏感数据。
2. 调用 服务：将原始数据发给 Vault。
3. 生成 ：Vault 随机生成一个唯一令牌，存入映射关系表。
4. 返回 ：业务系统用 替代原始数据，持久化存储。
5. 后续使用：需要原值时，反向查询 Vault 换回。

这里有一个很容易忽视的细节： 生成必须是不可预测的。我曾经见过一个项目， 直接用自增 ID 加密后截取，结果攻击者根据多个 推算出生成规律……嗯，那是个血泪教训。

1.4 Tokenization 整体逻辑框架

下面这张图帮你理清整体关系——务必理解数据流的方向：

看明白了吗？数据流是单向进入 Vault，然后只有经过授权的业务系统才能发起「反查」请求。

1.5 令牌的类型

• 保留格式 ：长度、字符集与原数据相同，适合旧系统改造。
• 随机 ：完全无意义的长字符串，安全性最高。
• 可逆 vs 不可逆 ：大部分场景需要可逆，但有些流水号场景可以用不可逆（仅用于关联）。

我自己的习惯是：能随机就随机，别贪图保留格式。保留格式意味着信息熵变小——你想想看，卡号前6位是发卡行标识，去掉之后剩下的随机空间本来就小，再格式保留就更容易被穷举。

1.6 适用场景清单

场景	推荐使用 Tokenization？	备注
支付卡号存储	✔ 必须	PCI DSS 强制要求
身份证号/社保号	✔ 强烈推荐	法规要求最少化存储
电话号码	✔ 推荐	防止社工库关联
密码	✘ 不适用	应使用哈希+盐
日志中的敏感字段	✔ 强烈推荐	日志泄漏重灾区

有人会问：那 Tokenization 有没有缺点？当然有。最大的问题是——每次都需要查表，有网络延迟。但现代架构下，Vault 可以做成本地缓存 + 预取，延迟可以降到微秒级。