📚 课程目录第3章令牌化基础

令牌化基础：定义、类型与生命周期

各位好，咱们今天聊聊令牌化最核心的东西。你可能会问，令牌到底是什么？说白了，它就是一段替身数据。把敏感信息（比如银行卡号、身份证号）换成一段无意义的字符串，业务系统拿着这段字符串去交易，原始数据根本不出你的安全域。这个思路我在做支付系统时用过很多次，效果确实不错。

先看一张总览图，帮你建立整体印象。

1. 令牌的本质定义

令牌（）是一串随机或经过加密算法生成的字符串，用来替代真实数据在系统间传递。它的核心价值就两个字：隔离。真实数据只存在于你严格控制的令牌服务器或安全域内，外部系统拿到的永远是替身。

我在一个银行项目中遇到过这样的场景：合作商户需要查询用户的信用卡最后四位做展示，但商户系统明文存储了完整的PAN（主账号）。他们觉得“反正数据库加了密”。我当时就问一句：密钥在哪儿？同一台机器上。后来我们上了令牌化，商户只存一个令牌，查最后四位时调我们的令牌服务，原始数据从不落地第三方。嗯，这才是正确的做法。

2. 令牌的三种类型

根据应用场景和生命周期，令牌可以分成三类。你想想看，不同类型的令牌安全性要求差异很大，别搞混了。

类型	用途	生命周期	可逆性
持卡人令牌	替换完整的卡号（PAN），用于交易授权	长期有效，与卡号绑定	仅令牌服务可反向解析
设备令牌	绑定特定用户设备，用于支付验证	单次或短时间有效	不可逆，仅做比对
协议令牌	用于API认证、会话标识等非支付场景	可配置（分钟~天）	通常不可逆（签名验证）

我曾经犯过的错： 在一期项目里，我把设备令牌设计成了持卡人令牌的简单哈希，结果设备令牌泄露后，攻击者通过彩虹表倒推出了原始PAN。切记，不同类型的令牌必须采用不同的生成策略，不能复用。

2.1 持卡人令牌

这是最常见的一种，也是PCI DSS合规中最关键的。它的格式通常模仿原始卡号，比如16位数字，前6位是发卡行识别码（BIN），后面10位随机生成。为什么要模仿格式？因为下游系统（比如支付网关）可能只接受特定长度的字段，你硬塞一个32位UUID进去，对方会报错。

持卡人令牌的生成必须保证：相同卡号每次生成的令牌唯一（避免频率分析），且不同卡号生成的令牌不会冲突。我在实现时用的是AES-256加密+定长截断，加密密钥定期轮换。

2.2 设备令牌

设备令牌绑定的是“设备指纹”，包括IMEI、MAC地址、系统版本等。它的生命周期很短，通常只用于一次支付验证。比如你手机上Apple Pay生成的动态安全码，每次交易都不同。设备令牌的生成算法要包含时间戳，防止重放攻击。

我记得有一次做移动支付SDK，测试环境的设备令牌居然固定不变。开发说“这样方便调试”。我当时就急了：这玩意儿如果固定，攻击者截获一次就能无限使用。最后强制加了防重放检测，每个令牌有效窗口控制在5分钟。

2.3 协议令牌

协议令牌不直接替换金融数据，而是替换用户的身份凭证或会话。比如OAuth 2.0的access 、JWT。它的价值在于解耦：认证系统发一个令牌，资源服务器只认令牌，不需要知道用户密码。协议令牌通常包含声明（claims），比如用户ID、角色、过期时间，用JSON Web签名（JWS）或加密（JWE）保护。

协议令牌的验证不能假设信任网络。我见过有人直接把JWT的签名算法设为"none"，然后放在公网上——后果可想而知。务必强制校验算法白名单。

3. 令牌的生成机制

生成算法是令牌安全的第一道防线。我用一个简化的伪代码来说明标准流程：

// 伪代码：持卡人令牌生成
function generateCardToken(rawPAN, masterKey, domain):
    // 1. 校验原始数据格式
    if !validatePAN(rawPAN) return error
    
    // 2. 生成随机nonce（防重复）
    nonce = secureRandom(16 bytes)
    
    // 3. 计算HMAC-SHA256( masterKey, rawPAN || nonce || domain )
    hmac = HMAC_SHA256(masterKey, rawPAN + nonce + domain)
    
    // 4. 截断前12位（或保留BIN）
     = rawPAN[0:6] + hex(hmac[0:5])  // 10位随机部分
    
    // 5. 存储映射： -> {rawPAN, nonce, domain, 过期时间}
    storeMapping(, rawPAN, nonce, domain, expire)
    
    return

要点： HMAC具有单向性，即使泄露了masterKey的哈希输出，也无法反推出原始PAN。不过masterKey本身必须硬件安全模块（HSM）保护，不能明文写在代码里。我建议把密钥管理做成独立的微服务，不要和令牌生成逻辑耦合。

4. 令牌的验证机制

验证的核心是回答三个问题：令牌存在吗？令牌有效吗？令牌属于当前操作吗？

存在性验证： 查映射表，看令牌是否已注册。如果查找失败，直接拒绝。
有效性验证： 检查过期时间、状态（是否已撤销）、使用次数限制等。
域绑定验证： 令牌与请求的域名、应用ID、设备指纹是否匹配。这一步容易被忽略，但很重要。举个例子：持卡人令牌在A商户生成，B商户拿着它来请求原始数据，应该拒绝。

验证时还需要考虑性能。令牌服务是线上高频调用，把映射表放在Redis里加速，但要注意：Redis挂了怎么办？我通常用本地缓存+写入持久化数据库，服务端再做集群。

  一个关键指标： 令牌验证的P99延迟应在10ms以内。有一次我把验证逻辑写了三个外部RPC调用，结果生产上P99飙到200ms，直接导致支付超时。后来改成批量预加载+本地缓存验证，才降到3ms。

5. 生命周期管理

令牌不是永生的。从生成、使用、刷新到撤销，每个阶段都要有明确的策略：

生成： 记录时间、调用方、令牌类型。
使用： 每次验证更新最后使用时间，做异常检测（比如短时间内来自不同IP的查询）。
刷新： 协议令牌需要定期刷新（例如每30分钟）。刷新时发一个新令牌，旧令牌必须立即失效。
撤销： 用户挂失卡片、设备丢失时，手动或自动撤销相关令牌。撤销列表（黑名单）要同步到所有缓存节点。

我曾经处理过一个线上事故：有用户手机丢了，只撤销了设备令牌，但持卡人令牌还在有效期。结果捡到手机的人用APP残留的持卡人令牌去其他商户消费了。事后我们补了一个规则：撤销设备令牌时，级联撤销该设备关联的所有持卡人令牌。嗯，教训就是——令牌之间也要有关联生命周期。