PCI DSS 标准精讲：12项核心要求与评估实战
各位同学好，今天我们来啃一块硬骨头——PCI DSS标准。说实话，我刚入行时看到这12项要求，头都大了。但后来我发现，只要理解了它的设计逻辑，这东西其实挺清晰的。
PCI DSS全称是支付卡行业数据安全标准。说白了，就是Visa、MasterCard这些卡组织联合制定的安全规范。你不遵守？那对不起，不能处理卡交易。
一、PCI DSS 12项核心要求：一张图看懂
我个人习惯把这12项要求分成六大类，每类对应一个安全目标。你看下面这张图就明白了：
嗯，这张图我花了不少心思。你看，12项要求不是孤立的，它们围绕着一个核心——持卡人数据。你想想看，所有安全措施最终都是为了保护那串16位数字（PAN）。
二、持卡人数据保护范围：到底要保护什么？
我在项目中遇到过很多次，开发人员问：「到底哪些数据算持卡人数据？」这个问题问得好。PCI DSS明确划定了范围：
| 数据元素 | 是否可存储 | 存储要求 |
|---|---|---|
| 主账号（PAN） | ✅ 可存储 | 必须加密、截断或哈希 |
| 持卡人姓名 | ✅ 可存储 | 需与PAN关联保护 |
| 有效期 | ✅ 可存储 | 需与PAN关联保护 |
| 服务代码 | ✅ 可存储 | 需与PAN关联保护 |
| CVV/CVC | ❌ 禁止存储 | 交易后立即销毁 |
| 磁条/芯片完整数据 | ❌ 禁止存储 | 交易后立即销毁 |
⚠ 避坑指南：我曾经见过一家公司，把CVV和PAN一起存到了数据库里。理由是「方便退款时验证」。结果呢？QSA（合规评估员）来审计时直接给了个不符合项。记住，CVV是绝对不能存的，这是红线。
二、SAQ与ROC评估流程：你适合哪种？
PCI DSS评估不是一刀切的。它根据商户的交易量、处理方式，分成了不同的评估路径。说白了，小商户做SAQ自评，大商户做ROC现场审计。
1. SAQ（自评问卷）
SAQ有多个版本，我整理了一下：
- SAQ A：纯外包，不接触卡数据。比如你用Stripe收款，卡数据直接到Stripe。
- SAQ A-EP：部分外包，但你的网站处理了卡数据。
- SAQ B：使用刷卡终端，不存储电子数据。
- SAQ C-VT：通过虚拟终端手动输入卡号。
- SAQ D：最全面，适用于所有其他情况。说白了，如果你不确定选哪个，大概率就是D。
💡 我的建议：选SAQ版本时，别贪图省事选低版本。我见过有公司明明自己存了PAN，却选了SAQ A，结果审计时被查出，罚款加整改，损失惨重。诚实评估，安全第一。
2. ROC（合规报告）
ROC适用于年交易量超过600万笔的商户，或者被卡组织要求做现场审计的。流程是这样的：
- 确定范围：划定CDE（持卡人数据环境）边界
- 差距分析：对照12项要求，找出差距
- 整改：修复发现的问题
- 现场审计：QSA上门检查
- 出具ROC：通过后获得合规报告
我个人习惯在差距分析阶段，先做一次内部渗透测试。为什么呢？因为很多问题QSA会查，比如默认密码、未加密的传输、日志缺失。提前发现，提前修复，省得现场审计时尴尬。
三、合规自检清单：照着做就行
下面这份清单，是我多年项目经验的总结。你每次做合规检查时，对着它过一遍，基本不会漏：
| 检查项 | 具体要求 | 常见问题 |
|---|---|---|
| 防火墙配置 | DMZ隔离、限制入站/出站 | 开发环境与生产环境未隔离 |
| 默认密码 | 所有系统、设备修改默认密码 | 路由器、数据库默认密码未改 |
| 数据加密 | PAN存储加密，传输用TLS 1.2+ | 内部网络传输未加密 |
| 访问控制 | 最小权限原则，唯一用户ID | 共享账号、权限过大 |
| 日志审计 | 记录所有访问，保留12个月 | 日志未集中管理，时间不同步 |
| 安全测试 | 每季度漏洞扫描，每年渗透测试 | 扫描范围未覆盖全部CDE |
🔑 核心要点：PCI DSS不是一次性工程。你通过了今年的审计，不代表明年也能过。我见过太多公司，审计前突击整改，审计后放松管理，结果第二年QSA一来，发现一堆新问题。合规是持续的过程，不是终点。
好了，关于PCI DSS的核心内容就讲到这里。记住，12项要求不是束缚你的枷锁，而是保护你业务的铠甲。下次我们聊具体的技术实现时，你会发现，很多安全措施其实都是在帮你省钱——避免数据泄露带来的巨额罚款和声誉损失。