保护持卡人数据：加密标准与存储限制
这章我们聊点硬核的——怎么真正把持卡人数据锁在保险箱里。我见过不少团队，觉得上了 HTTPS 就万事大吉，结果审计时被问得哑口无言。说白了，加密不是买个证书装上就完事，存储限制也不是“尽量少存”这么简单。
为什么加密是必须的
PCI DSS 要求保护持卡人数据的“静止”和“传输”状态。你想想看，数据在数据库里躺着，如果被拖库，没有强加密就等于裸奔。同理，数据在网络里跑着，如果被抓包，没加密就是明牌。
我记得有个项目，客户把信用卡 PAN 明文存进 MySQL 做历史查询。我说：“你这是给黑客送年终奖啊。”后来我们改成了 AES-256 加密存储，才过审。
加密标准详解
传输层加密
PCI DSS 要求所有持卡人数据通过开放网络传输时，必须使用强加密协议。现在主流是 TLS 1.2+，禁用 SSL 和早期 TLS。我在项目中遇到过，某支付网关还在用 TLS 1.0，结果 QSA 直接给了个不符合项。
- 协议： TLS 1.2 / 1.3
- 密码套件： 推荐 ECDHE + AES-GCM
- 证书： 必须来自受信任的 CA，不能自签
静止数据加密
存储的 PAN 必须加密。行业标准是 AES-256，用 CBC 或 GCM 模式。别用 ECB，那只适合教科书。
// 伪代码示例：AES-256-GCM 加密 PAN
Key = generateKey(256);
iv = randomBytes(12);
ciphertext = AES_256_GCM_encrypt(pan, key, iv);
storeInDB: { ciphertext, iv, tag };
密钥管理同样重要。HSM 或 KMS 是标配，别把密钥和密文放一起。我见过直接把密钥写在配置文件里的……嗯，那项目后来重做了。
数据存储限制要求
PCI DSS 要求尽量少存持卡人数据。存得越少，风险越低。具体限制如下：
| 数据项 | 可存储？ | 说明 |
|---|---|---|
| 完整 PAN | ✅ 可以（需加密） | 必须使用强加密，并限制访问 |
| 持卡人姓名 | ✅ 可以 | 可与 PAN 关联，但非必需 |
| 卡有效期 | ✅ 可以 | 可用于过期提醒 |
| 服务代码 | ✅ 可以 | 卡片类型识别 |
| CVV/CVC | ❌ 禁止存储 | 即使加密也不行 |
| 磁条轨道数据 | ❌ 禁止存储 | 完整轨道数据不可存 |
| PIN | ❌ 禁止存储 | 必须使用硬件加密设备处理 |
为什么要限制？因为 CVV 和 PIN 是验证交易的关键，如果被泄露，攻击者可以伪造交易。我有个客户曾经把 CVV 存进历史订单表（为了方便退款），审计时被罚了 3 个月整改。所以记住：不该存的，一秒都不留。
令牌化 vs 加密
很多人搞混这两个概念。我简单说几句：
- 加密： 用算法把 PAN 变成密文，可以用密钥还原回明文。
- 令牌化： 用 代替 PAN， 本身不可逆，原始 PAN 存在安全令牌库中。
令牌化更适合支付场景——你不需要明文 PAN，只需要一个 去做后续交易。我在电商系统里常用令牌化代替加密存储，既缩小了 PCI 范围，又方便了业务。
实战避坑指南
做了这么多年 PCI 合规，我总结几个常见坑：
- 备份文件未加密： 数据库备份是明文？那等于把钥匙放门口。我见过一个公司，生产库加密了，但每晚备份到 NAS 时是明文——结果 QSA 发现了。
- 日志记录 PAN： 开发为了方便调试，把 POST 请求参数全打印到日志里。这些日志一旦泄露，就是灾难。建议在日志输出前做脱敏或使用令牌。
- 加密密钥硬编码： 把 AES 密钥写在代码里？别这样。用 HSM 或云 KMS 管理密钥生命周期。
- 忽略内存中的明文： 即使数据库加密了，如果你的应用在内存中持有明文 PAN 时间过长，也可能违规。处理完后立即调用
Array.Clear()或 GC。
这张图总结了我的思路：持卡人数据从入口开始，要么在传输中加密，要么在静态时加密，要么直接令牌化。最后所有措施都要落到存储限制这个底线。记住，加密是手段，不存储才是终极目标。