第2章 Tokenization 生命周期模型
做 Tokenization 审计，第一件事就是搞清楚这系统从生到死都经历了哪些阶段。你想想看，一个令牌从诞生到废弃，中间任何环节出纰漏，敏感数据就可能裸奔。
我最早接触 Tokenization 时，看到一张映射表就以为完事了。后来出了一次事故——因为没定义过期策略，几年前的令牌还能解码明文。嗯，从那以后我才老老实实把生命周期画出来。
为什么需要生命周期模型？
说白了，审计不能只盯着“令牌生成”那一刻。整个生命周期涉及密钥、策略、存储、传输、监控、销毁。你漏掉一个阶段，就可能漏掉一条关键控制。
我个人的习惯是：先把阶段画成流程图，再挨个阶段定义控制点。这样审计时就知道在哪看，看什么。
核心思路：每个阶段都有“人、流程、技术”三类控制点。审计不是走马观花，而是验证这些控制是否真正落地。
生命周期的六个阶段
下面这张图是我常用的模型，分为六个阶段。每个阶段我都标注了关键控制点，你可以直接用这个框架去做审计清单。
阶段一：数据采集与分类
这个阶段说白了就是“哪些字段要令牌化”。我见过有人把整个表都加密了，性能直接崩掉。正确做法是先做数据分类。
- 关键控制点：敏感字段识别是否覆盖所有合规要求（PCI DSS、GDPR等）？
- 避坑：我曾经在审计中发现，开发为了省事，把非敏感字段也令牌化了，导致下游统计报表全乱掉。所以分类必须精确。
- 输出：一份经过审批的敏感数据字段清单。
阶段二：策略配置与密钥生成
这个阶段决定了令牌的“基因”。密钥长度够不够？轮转策略有没有？我个人的经验是：很多公司密钥轮转形同虚设，配了策略但从不执行。
| 控制点 | 审查内容 | 常见问题 |
|---|---|---|
| 密钥长度 | 是否≥128位？（AES） | 用了DES或3DES的老系统 |
| 密钥轮转 | 是否有自动轮转？周期多久？ | 从未触发轮转，或轮转后旧密钥未删除 |
| 密钥存储 | 是否使用HSM或密钥管理服务？ | 密钥硬编码在配置文件里 |
注意：密钥生成过程必须记录审计日志。谁、何时、生成了什么密钥，都要有迹可循。否则出事后无法追溯。
阶段三：令牌化处理
这是核心算法环节。你是用随机令牌？还是格式保留（FPE）？你的算法通过碰撞测试了吗？我以前碰到过一个项目，用哈希加盐当令牌，结果重复率让数据库直接报主键冲突。
- 关键控制点：算法验证报告、碰撞概率测试、逆向攻防测试。
- 提示：如果你用FPE，请确认它真的“不可逆”——不是简单的替换算法。
阶段四：令牌映射存储
映射表就是Tokenization的“核弹头”。谁拿到映射表，谁就能还原明文。所以存储必须做到：加密存储、访问隔离、最小权限。
- 控制点：映射表是否加密？加密密钥是否独立？数据库访问是否经过审计？
- 避坑：我曾经审计过一家公司，映射表和明文数据存放在同一个库的不同表里。DBA一个人就能全看光——这跟没令牌化一样。
阶段五：令牌使用与传输
令牌生成出来不是放着看的，是要被应用调用的。这个阶段最容易出纰漏的反而是接口本身。比如API没有鉴权，任何人都可以传令牌反向查询。
实战技巧：检查令牌使用场景的日志，看有没有非授权IP调用了映射接口。在传输时一定要强制TLS 1.2以上，且双向证书验证。
- 控制点：API鉴权、传输加密、令牌有效期检查。
阶段六：监控与销毁
令牌不能永生。过期策略定了没？销毁流程有没有验证？我见过最离谱的是系统里还有5年前的测试令牌，映射表就能读出当年的测试信用卡号。
| 控制点 | 检查方法 |
|---|---|
| 令牌过期标记 | 数据库中是否有expire字段，且定期清理任务生效 |
| 销毁验证 | 销毁后是否执行了“不存在查询”？残留碎片是否覆盖？ |
| 审计日志 | 是否有销毁操作的时间、操作人、受影响令牌范围 |
一句话总结：生命周期审计不是看一个点，而是看一条链。你从头到尾把六个阶段跑一遍，自然知道问题在哪。