# 第二章：PCI DSS适用范围与参与角色

PCI DSS合规审计教程 - 第2节

2.1 谁需要关注PCI DSS？

我做PCI审计这些年，经常有人问我：到底哪些公司需要做这个合规？

说实话，这个问题的答案比大多数人想的要宽。不是只有电商平台才需要管。你想想看，只要你的业务里碰了银行卡信息，不管是存储、处理还是传输，都会被纳入PCI DSS的管辖范围。

2.1.1 适用范围的三要素

判断一家公司是否在PCI DSS范围内，主要看三样东西：

• 持卡人数据（Cardholder Data, CHD） – 卡号、有效期、持卡人姓名、服务代码
• 敏感认证数据（Sensitive Authentication Data, SAD） – 磁条数据、CVV2/CVC2、PIN码
• 系统组件（System Components） – 存储、处理、传输以上数据的任何IT资产

2.1.2 哪些组织必须合规？

组织类型	典型场景	合规要求
商户（Merchant）	线上商店、实体POS收银	按交易量分4级，SAQ或ROC
服务提供商（Service Provider）	支付网关、托管平台、云服务	必须通过ROC，年度审计
金融机构	发卡行、收单行	通常要求Level 1级别
第三方处理商	数据录入、客服外包	视合同定义，可能需附加审计

嗯，这里要注意。很多人以为“我只做一个小程序收款，不用太操心”。错。我记得有一次，一个创业团队用第三方支付，但他们自己把卡号缓存到了服务器日志里……这就踩红线了。

2.2 参与角色与责任划分

搞清楚了范围，接下来得知道是谁在干活。PCI DSS不是一个人能搞定的。它需要一个分工明确的团队。

2.2.1 核心角色一览

• 组织管理层 – 最终责任方，负责签署合规声明
• 安全团队 – 负责防火墙、IDS/IPS、日志审计等技术落地
• 开发团队 – 负责安全编码、加密实现、API安全
• 业务团队 – 负责流程合规、员工培训
• 内部审计 – 负责自评、差距分析、整改跟踪
• 外部QSA – 负责正式审计与颁发AOC

2.2.2 角色责任矩阵

角色	主要责任	常见误区
CISO/安全负责人	制定安全策略、组织培训、上报风险	认为合规=全由安全部门负责
开发工程师	实现加密、输入验证、日志脱敏	只管功能，不管数据传输安全
运维人员	配置防火墙、系统补丁、访问控制	默认配置不改，留下大量漏洞
法务/合规	合同审核、第三方尽职调查	忽略合同中的安全条款
外部QSA	现场审计、出具合规报告	被审计方隐瞒问题，导致后续处罚

2.3 CDE边界：红线在哪里？

这是审计中最容易扯皮的地方。为什么会这样？因为很多公司根本不知道自己有没有越界。

2.3.1 什么是CDE？

CDE（Cardholder Data Environment）是持卡人数据环境的简称。它包括：

• 存储、处理、传输CHD/SAD的所有系统组件
• 所有直接连接到上述组件的网络设备
• 管理以上组件的安全控制设备（如跳板机、日志服务器）

我曾遇到过一个案例：客户把支付服务器放在生产网段，但生产网段跟办公网没有隔离。结果，办公网的企业微信通知服务器也被划入CDE了。你想想看，本来只需要管几台服务器，最后变成要管几百台。

2.3.2 范围缩减的正确做法

说白了，合理的架构设计可以大幅缩小合规范围。我建议按这四步走：

1. 网络隔离 – 把CDE单独放一个VLAN或物理网段
2. 访问控制 – 只有少数授权人员能跳进CDE
3. 数据最小化 – 只保留必要的卡号信息，不存SAD
4. 系统分段 – 用防火墙策略把CDE和外围系统隔开

2.4 知识体系总览

下面这张图把本章的核心逻辑串起来了。你可以看到，实体（Entity）通过数据流向（Data Flow）和角色（Role）共同构成了PCI DSS的审计全景。

2.5 避坑指南

讲几个常见的坑，都是我在现场见过的：

• 坑一： 以为只有生产系统需要合规。错！测试环境、备份系统、日志服务器如果碰了真实卡号，同样要纳入CDE。
• 坑二： 让开发人员随便访问CDE。我曾经遇到一家公司，所有开发都能ssh到支付服务器，结果一个测试脚本把信用卡信息打到了公网Git仓库。
• 坑三： 忽略员工培训。PCI DSS第12条要求全员安全意识培训，很多人觉得走个形式就行。实际上，培训不到位是QSA开出整改项最多的领域之一。