1. PCI DSS 概述与密钥管理要求

各位做安全运维的同行们，咱们今天聊聊PCI DSS。

说实话，我第一次接触这个标准时，感觉就像在看天书。满篇的"应当"、"必须"，看得人头皮发麻。但干这行久了，慢慢就摸到了门道。说白了，PCI DSS 就是一张信用卡支付安全的"体检表"。

你想想看，每天全球有多少笔信用卡交易在跑？每一笔都涉及卡号、有效期、CVV这些敏感数据。如果没有统一的安全标准，那简直就是给黑客们敞开了大门。PCI DSS 就是专门用来堵这扇门的。

1.1 PCI DSS 标准简介

PCI DSS 全称是 Payment Card Industry Data Security Standard，翻译过来就是"支付卡行业数据安全标准"。它是由 American Express、Discover、JCB、MasterCard 和 Visa 这五大卡组织联合制定的。

我个人习惯把它分成三个层次来理解：

• 第一层：保护持卡人数据 —— 这是最核心的目标
• 第二层：维护安络和系统 —— 这是基础保障
• 第三层：持续监控和管理 —— 这是长效机制

标准本身有12大要求，分为6大控制目标。我把它整理成了下面这个表格：

控制目标	编号	具体要求	我常被问到的点
构建和维护安络	1	安装和维护防火墙配置	到底哪些设备要进DMZ？
	2	不使用厂商默认密码和参数	路由器的默认密码改过没？
保护持卡人数据	3	保护存储的持卡人数据	怎么安全地用加密？
	4	加密传输中的持卡人数据	内部网络也要加密吗？
维护漏洞管理程序	5	使用并更新防病毒软件	Linux服务器呢？
	6	开发并维护安全系统和应用	第三方组件怎么管？
实施强访问控制	7	限制按需知悉原则的访问	DBA能看明文卡号吗？
	8	为每个用户分配唯一ID	共享账号怎么处理？
	9	限制对物理卡数据的访问	机房监控要存多久？
定期监控和测试网络	10	跟踪并监控所有对网络和卡数据的访问	审计日志要保留多久？
	11	定期测试安全系统和流程	渗透测试多久做一次？
维护信息安全管理策略	12	维护针对信息安全的策略	安全策略要每年更新吗？

这里面，第3条和第4条直接关系到密钥管理。我记得有一次审计，对方说他们的加密算法用的是DES，我当时就愣住了。DES？那可是20世纪80年代的东西啊。果不其然，审计结果挂了一堆Finding。

1.2 密钥管理核心原则

密钥管理，说白了就是管好你手里这把"锁的钥匙"。但很多公司往往把密钥当成了"存了就行"的玩意儿。嗯，这里要注意，密钥的生命周期管理，是PCI DSS审计的重灾区。

我总结了密钥管理的四大原则：

1. 密钥最小化原则 —— 只生成和存储必要的密钥
2. 密钥隔离原则 —— 不同用途的密钥必须分开管理
3. 密钥轮换原则 —— 密钥必须定期更换
4. 密钥销毁原则 —— 不再使用的密钥必须安全销毁

我曾经遇到过一家电商公司，他们把、数据库加密密钥、TLS证书私钥全部放在同一个Keystore里。更离谱的是，这个Keystore的密码就写在运维文档里，文档还没设权限。这才是真·犯罪现场。

PCI DSS对密钥管理有非常具体的要求，我列了几个重点：

• 密钥生成：必须使用FIPS 140-2或更高标准认证的HSM生成
• 密钥存储：严禁明文存储，必须加密存储或放在HSM里
• 密钥分发：必须使用安全的带外通道或加密传输
• 密钥备份：备份必须与原始密钥分开存储，且同样加密
• 密钥归档：作废的密钥必须归档保留，不能直接物理销毁

为什么会这样严格？因为一旦密钥泄露，所有用这把密钥加密的数据都会暴露。你想想看，一个信用卡号被解密了，影响的不只是持卡人，还有发卡行、收单行、商户，整个支付链条都会受牵连。

1.3 合规边界定义

合规边界，就是PCI DSS审计的范围。很多公司一上来就想把整个公司网络都纳入审计范围，其实没必要。

我个人建议按以下方法确定边界：

• 数据流追溯法：画清楚持卡人数据从哪儿来、到哪儿去、在哪儿停
• 系统关联分析法：所有能接触到持卡人数据的系统都算
• 网络分段验证法：通过防火墙规则验证是否真实隔离
• 第三方依赖梳理法：外包、云服务商、托管机房都算

下面这张图展示了我常用的密钥分类及其关联关系：

再说说"范围界定"这件事。很多公司喜欢把整个IT系统都划进来，结果审计范围大得吓人，自己吓自己。正确做法是：只把那些真正处理、存储、传输持卡人数据的系统划入CDE（持卡人数据环境）。

边界定义还有一个关键点：第三方服务商。你的云服务商、支付网关、托管机房，只要他们能接触到你的持卡人数据，就得纳入范围。我建议在合同层面就要求服务商提供PCI ROC或AOC，别等审计了才去要。