PAN 保护概述
什么是 PAN？
PAN，全称 Primary Account Number，说白了就是银行卡上那串数字。通常叫「卡号」。但你别小看这串数字——只要泄露了，就能用来做线上支付、伪造卡片，甚至搞出批量欺诈。
我个人习惯把 PAN 分成三部分看：发卡行标识（BIN）、个人账户标识、校验位。你想想，BIN 前六位就能判断是哪家银行、是不是信用卡。所以 PAN 本身就是一把「钥匙」，谁拿到谁就能开门。
我在项目中遇到过一家电商平台，他们把 PAN 直接明文存进数据库。后来 PCI DSS 审计没通过，罚了巨款。我当时就问他们：「你们知道 PAN 是什么吗？是红线！碰都不能碰的。」嗯，从那以后他们才重视起来。
PCI DSS 合规要求
PCI DSS 是支付卡行业数据安全标准。不管你是大平台还是小商户，只要处理、存储、传输 PAN，就得合规。核心要求说白了就几条：
- 不能明文存储 PAN。 存储必须用哈希＋加盐，或者直接令牌化。
- 传输必须加密。 用 TLS 1.2 以上。
- 访问控制。 谁能看到 PAN 必须严格控制。
- 定期审计。 每年要做合规扫描。
我记得有一次帮一个客户做差距分析，发现他们竟然把 PAN 放日志里了。日志是明文啊！PCI DSS 要求日志也不能记录完整 PAN。那真是个大坑。
| PCI DSS 要求 | 对 PAN 的具体约束 |
|---|---|
| 存储 | 禁止明文；必须加密或令牌化 |
| 传输 | 必须使用强加密（TLS 1.2+） |
| 展示 | 只允许显示后4位或掩码形式 |
| 日志 | 禁止记录完整PAN |
令牌化基本概念
令牌化——Tokenization——不是加密。加密还能解密出原值，令牌化则是一个「替代品」。你把 PAN 发给令牌化服务，它返回一个毫无意义的令牌（）。以后你所有业务都用这个 ，PAN 本身根本不在你数据库里。说白了，令牌就是「替身」。
我建议你理解三个角色：
- 令牌化服务：负责生成、映射、存储 PAN ↔ 的关系。
- 令牌库（Vault）：安全存储原始 PAN 的地方，一般用硬件安全模块（HSM）保护。
- 业务应用：只使用 进行交易、查询，不碰 PAN。
我曾经被客户问：「令牌和加密哪个安全？」你看，这就是误区。令牌化不是为了保密性，而是为了「缩小合规范围」。你只要不存 PAN，PCI DSS 的数百条要求就跟你无关了。
下面这张图展示了典型的令牌化流程：
你看，商户拿到 PAN 后立刻发给令牌化服务，服务把 PAN 存在 Vault 里，返回一个 。以后商户只存 ，交易时拿 找支付网关，网关再找令牌化服务验证。原始 PAN 永远不出 Vault。这样 PCI DSS 的存储要求就全落在令牌化服务那边了，你这边只要保护好 就行。