4、保护机制概述：常见PAN保护方法总览
聊到银行卡号（PAN）的保护，很多团队一上来就问「用什么算法」。其实我做了这么多年支付安全，先选对方法是关键。方法不对，算法再强也白搭。
今天我把主流的保护手段过一遍。加密、掩码、令牌化……每种我都会说清楚：什么时候用、有什么坑、以及我自己的真实体会。
核心观点：没有银弹。你需要根据使用场景，把不同方法组合成纵深防御。
4.1 加密（Encryption）
加密是最直接的保护手段。把明文PAN变成密文，只有持有密钥的人能还原。
- 对称加密（如AES）：速度快，适合大量数据。但密钥分发是个麻烦事。我记得有次客户把密钥硬编码在配置文件里，上线第二天就被扫出来了……
- 非对称加密（如RSA）：密钥管理更灵活，但性能差。一般只在传输阶段或小数据量场景用。
我个人习惯：存储层用对称加密 + 定期轮换密钥。传输层用TLS，这就够了。
技巧：加密不是万能的。如果你的应用有权限漏洞，攻击者拿到密钥就能解密。所以加密必须和访问控制配合。
4.2 掩码（Masking）
掩码就是把PAN显示给用户或客服时，只保留前后几位，中间用星号代替。例如 411111******1111。
这招儿很常见。但你想想看：掩码后的数据还能还原吗？ 不能。所以它适合展示场景，不适合做分析或交易。
我曾经踩过一个坑：让前端直接做掩码，以为用户看不到就安全了。结果别人一抓包，明文全暴露了。记住：掩码一定要在服务端做，然后把处理后的数据发给客户端。
4.3 令牌化（Tokenization）
令牌化是我最喜欢的方式。它把PAN替换成一个无意义的令牌（），令牌本身没有数学关系，不能逆向推导出原PAN。
| 特性 | 令牌化 | 加密 |
|---|---|---|
| 逆向还原 | 需要查令牌表 | 解密即可 |
| 格式保留 | 可以保留PAN格式（如16位数字） | 密文通常是二进制或base64 |
| 合规成本 | PCI DSS范围大幅缩小（不用管令牌） | 密钥管理仍在审计范围内 |
| 使用场景 | 应用层、数据库、API交互 | 存储、传输 |
说白了，令牌化就是把敏感数据从你的系统里「扔」出去。我在做电商项目时，支付环节全走令牌化，后续订单查询、退款都用令牌，数据库根本不留PAN。PCI审计直接过了。
4.4 截断（Truncation）
截断就是只保留PAN的前几位或后几位，其余丢弃。和掩码不同——掩码中间是星号，截断是真删除。比如只存后4位，前面的全部扔掉。
这个做法对追踪刷卡记录很有用，但没法做完整交易。所以截断一般用于日志、报表、风控分析（只看尾号判断卡组织）。
注意：仅靠截断是不够的。如果你存了后4位 + 持卡人姓名 + 有效期，攻击者依然可以组合出有效信息。PCI DSS要求截断且不能存在其他可关联的敏感字段。
4.5 哈希（Hashing）
哈希通常和加盐一起用。把PAN做哈希，存哈希值。但注意：PAN的熵很低（16位数字，其实只有10^16种可能），攻击者可以穷举所有卡号并计算哈希，然后对照。所以必须加长随机盐，而且盐值要保密。
我记得有个银行把SHA-256直接用在PAN上，没加盐。后果是什么？攻击者拿一个彩虹表就全对出来了。嗯，别省这一步。
保护方法总览图
4.6 如何选择？
我一般会按照数据生命周期来分配方法：
- 收单/发卡阶段：传输中全程TLS，接收后立即令牌化。
- 存储阶段：令牌表单独加密存储，令牌本身不需加密（因为它无意义）。
- 分析/展示阶段：给客服看用掩码，给风控计算用截断后4位。
- 审计/日志：截断后4位 + 哈希（加盐），就算日志泄露，攻击者也拼不出完整PAN。
你想想看，如果每个环节都用了对的保护方法，就算某个环节被攻破，攻击者也只能拿到无用的碎片。这才是纵深防御。
避坑总结：
- 加密 ≠ 安全：密钥管理不善＝白干。
- 掩码要在服务端做，前端只负责显示。
- 令牌化时别把PAN留在应用日志里，很多人忘了这步。
- 哈希必须加盐，而且盐要足够长、随机。