PCI DSS 渗透测试：范围、方法与服务商选择

设想一个假设场景。一家小型支付服务商为网店处理银行卡支付。今年春天，团队把令牌化服务迁到了新的云网段：安全组换了，管理员用上了新的堡垒机，持卡人数据区与办公网之间的规则也做了调整。距离评估员到场还有一个月，证据文件夹里放着去年的渗透测试报告。安全负责人翻开一看，发现三个问题：测试范围只有对外 IP；完全没有做分段测试；部分内部检查由亲手配置防火墙的那位管理员执行。

这是虚构的例子，并非某家公司的真实经历，但其中每个问题都真实存在。这次迁移算不算需要重新测试的重大变更？持卡人数据环境（CDE）的隔离是否经过测试，服务商又必须多久做一次？测试人员是否足够独立？PCI DSS 渗透测试的价值，恰恰取决于开工前对这些问题回答得有多好。下文介绍现行版本标准的要求、如何从数据流推导范围、如何规划测试才能让报告经得起评估员追问，以及如何依据证据而非日单价选择服务商。

PCI DSS v4.0.1 对渗透测试的要求

PCI DSS 是保护支付账户数据的一套技术与运营基线要求。它适用于存储、处理或传输持卡人数据或敏感认证数据的机构，也适用于可能影响 CDE 安全的机构。现行版本是 4.0.1。PCI 安全标准委员会于 2024 年 6 月 11 日发布该版本，定位为有限修订：与 4.0 相比，没有新增也没有删除任何要求。4.0 版已于 2024 年 12 月 31 日退役。因此，工作说明书应引用 4.0.1，正式文件中的确切措辞应以官方文本核对。

渗透测试由要求 11.4 规定。与许多行业议题不同，这里的频率是明文写出的，值得准确掌握。

内部与外部测试：每 12 个月一次，重大变更后也要做

要求 11.4.2 规定，按照机构自行定义的方法论开展内部渗透测试，至少每 12 个月一次，并在任何重大基础设施或应用升级、变更之后进行。要求 11.4.3 对外部渗透测试设定了相同条件。

有两个细节比表面看起来更重要。第一是"按照机构的方法论"这一表述。方法论文件不是走过场，评估员正是依据它核对做了什么、怎么做的。第二是变更触发。在我们的例子里，把令牌化迁到配有新堡垒机的新云网段，很难不算重大变更，而去年的报告已经无法反映它。什么算"重大"取决于具体环境，但 PCI DSS 给出了至少要考虑的事项：CDE 中新增或大幅升级的硬件与软件；账户数据流或存储、CDE 边界或评估范围的变化；目录、时间、日志和监控等支撑基础设施的变化；以及支持 CDE 或代表机构满足 PCI DSS 要求的第三方及其服务变化。机构应在这一最低范围之上预先记录自己的判定标准，并能解释某次具体变更的结论。如何按事件而不是按日历安排测试，可参阅我们关于变更触发型渗透测试的文章。

分段测试：使用者每 12 个月一次，服务商每六个月一次

如果使用分段将 CDE 与其他网络隔离，要求 11.4.5 适用于每一家这样的机构：所有分段控制和方法至少每 12 个月、并在其发生任何变更后接受渗透测试。测试要确认控制处于运行状态且有效，能把 CDE 与所有范围外系统隔离；若不同安全级别的系统之间也采用隔离，还要验证该隔离。

要求 11.4.6 是仅适用于服务商的附加要求：同类测试至少每六个月一次，并在分段控制或方法发生任何变更后进行。六个月间隔不能套用到所有商户，但只要使用了分段，就不能漏掉 11.4.5 的通用年度义务。在本例中，区域间规则的调整本身就会触发一次计划外测试。另有要求 11.4.7：多租户服务商必须支持客户依据 11.4.3 和 11.4.4 开展外部渗透测试，可以及时开放客户自行测试，也可以提供证据，证明对客户订阅的基础设施做过同等测试。结果可以删减，但剩余信息必须足以证明这些要求的全部要素均已满足。2025 年 3 月 31 日之后，这已是强制要求，而非最佳实践。

谁可以执行测试

标准允许由内部或外部资源执行，前提是具备资质且在组织上独立。渗透测试并不要求必须由 QSA 或 ASV 执行。独立性意味着测试者不评估自己的工作：配置防火墙的管理员即便能力很强，也不适合去测试这些规则。

渗透测试不是什么

定期漏洞扫描由 PCI DSS 中的其他要求单独规定，不能替代 11.4 下的测试，渗透测试同样不能替代扫描。此外，渗透测试报告是供评估员审阅的证据，而不是认证、鉴证或合规意见。好的报告能让评估更顺利，但它本身并不能证明合规。

PCI DSS 渗透测试范围：从卡数据流出发，而不是从 IP 清单出发

PCI DSS 的范围取决于卡数据在哪里存储、处理和传输，以及哪些系统可能影响 CDE 安全，并不自动等于整个企业。因此合理的顺序与常见做法相反：先画数据流图，再列出这些数据流上的系统清单，最后才确定要测试的地址和 URL。

通常纳入范围的内容

一般包括几类资产。面向互联网的支付页面、结账 API 以及支付数据经过的接口。CDE 内部系统：令牌化、存放卡数据的数据库、交易处理。本应把 CDE 与其他网络隔开的机制：防火墙规则、云安全组、路由。管理与远程访问路径：堡垒机、VPN、云控制台，以及能够修改 CDE 配置的部署流水线。还有支付流程中的第三方组件：网关、支付页面上的脚本、收单机构的 webhook。

对管理路径，最好一开始就区分两类凭据。人员登录受多因素认证保护，测试者要寻找绕过方式、薄弱的找回流程以及登录后的过度权限。工作负载凭据——API 密钥、服务账号、流水线令牌——的测试方法不同：存放在哪里、谁能看到、授予哪些权限、拿到一个之后能做什么。如果把两类检查混在报告的一行里，结论就丢了一半。

两个陷阱

第一个陷阱是因为系统脆弱或"政治敏感"而将其排除。一台"最好别碰"的老旧处理服务器仍然属于 CDE；排除它会削弱测试的意义，也几乎必然引来评估员的追问。脆弱性应通过交战规则中的限制来应对，而不是把系统移出范围。

第二个陷阱是"以防万一"把整个企业都纳入。这会推高预算、分散测试人员的时间，却不能增强对支付数据本身受到保护的信心。避开这两个陷阱的办法是一条有文档记录的边界：每一项纳入和排除都写明理由，并在开工前让评估员看过。

下表按攻击边界拆解范围，并说明每条边界回答的问题。

如果你环境中的 CDE 边界还比较模糊，这样一张表很适合作为项目讨论的起点。数据流图和纳入理由可以在渗透测试范围沟通页面上与 Pentest.red 讨论。至于标准在你的情况下具体要求什么，仍由你和评估员决定。

授权与交战规则

书面授权是必须的前提，而不是纸面手续。授权必须来自真正有权处置目标系统的人：业务负责人、基础设施负责人，以及在其条款适用时的托管、云或托管服务提供商。如果支付网关的 API 属于另一家公司，网店老板的同意并不能赋予攻击该 API 的权利。

交战规则把授权变成可执行的工作文件。其中写明时间窗口、允许和禁止的技术（例如高峰时段不得对交易处理做压力攻击）、测试账号和测试卡、立即停止的条件以及紧急联系人。

数据处理另行约定。如果测试者遇到真实卡号，只记录最少必要的证据，对卡号做掩码处理，不把数据复制到自己的系统中，并立即通知负责人。日志和截图要清除密钥和不必要的个人数据。机构按照 11.4.1 至少保留 12 个月的渗透测试结果和修复活动结果，并限制访问；服务商持有的副本则通过合同另行尽量缩短保存时间。

方法论：以 NIST SP 800-115 为框架

要求 11.4.1 不指定某个品牌的方法论，但规定了必须包含的最低内容。机构的方法论必须采用业界认可的方法；覆盖整个 CDE 边界与关键系统、从网络内部和外部开展测试，并测试分段及其他缩小范围的控制；应用层至少覆盖 6.2.4 所列漏洞，网络层覆盖网络功能组件和操作系统；考虑过去 12 个月经历的威胁与漏洞；并记录如何评估和处置可利用发现带来的风险。方法论还必须包含受控利用尝试：自动化可以辅助，但单独使用扫描器，或只利用扫描器发现的问题，不能替代具备能力的测试人员。

NIST SP 800-115 可以作为落实这些最低内容的流程框架。这份信息安全测试与评估技术指南发布于 2008 年 9 月，取代了 SP 800-42，帮助机构规划和实施技术测试、分析结果并制定降低风险的措施。从形式上看，指南描述了三个评估阶段：规划、执行和执行后，最后一个阶段包括分析发现、报告和提出建议。

文件明确表示，它并不打算完整描述一个测试项目，而是概述关键技术及其优点和局限。这恰恰是 PCI 工作所需要的思路：好的报告不仅说明做了什么，还说明为什么选择每种技术、它不可能发现什么。由于指南写于 2008 年，应用层检查的具体内容最好取自下文介绍的更新来源。

在 NIST 三个阶段之上，可以搭建自己的修复循环：责任人、按风险设定的期限、复测。这并非指南原文，而是一种实用的补充，没有它很难满足要求 11.4.4。

1. 绘制数据流卡数据从哪里进入、如何流转、存放在哪里，以及哪些系统可能影响 CDE。
2. 授权与规则有权限的所有者和服务提供商签字，时间窗口、禁止事项、数据处理与停止条件。
3. 外部、内部与分段测试按 11.4.2 和 11.4.3 测试；按 11.4.5 测试分段，服务商再执行 11.4.6 的附加频率。
4. 按风险修复依据 11.4.4，为每个可利用漏洞指定责任人和期限。
5. 复测与记录在约定环境中验证修复，并记录复查了哪些攻击变体。

支付页面与结账 API

对支付页面、结账 API 和管理控制台中适用的 Web 检查，Web 测试标准很有帮助。OWASP Web 安全测试指南（WSTG）提供了一套测试用例；报告应注明所用版本，例如 4.2。OWASP ASVS 规定了可验证的 Web 控制要求。在 5.0.0 版中，项目建议引用要求时附带版本号，格式类似 v5.0.0-1.2.5，因为不同版本之间编号会变化。这样的引用让范围可以核查，但并不能证明应用整体符合该标准。

OWASP Top 10 2025 版是一份提高对 Web 应用关键风险认识的文件，而不是测试计划。止步于这十个类别的范围，比 WSTG 和 ASVS 所能覆盖的要窄。

会话、脚本与跨域请求

在支付页面上，有三种机制尤为重要。第一是会话。HTTP 本身不把请求相互关联，因此应用通常在服务器端保存会话状态，并通过 cookie 向浏览器下发标识符。测试者检查标识符如何签发、登录后是否更新、受哪些属性和有效期保护。

第二是脚本加载。内容安全策略（CSP）可以限制页面允许从哪些来源加载资源，有助于缓解跨站脚本和数据注入。在支付页面上下文中执行的第三方脚本可能接触用户输入，因此需要单独检查其必要性、来源和限制。

第三是 CORS。该策略决定哪些外部来源可以读取 API 响应。如果服务器动态允许攻击者控制的 Origin，同时又允许携带凭据，那么在 cookie 规则和具体端点行为确实允许发送这些凭据时，受害者的浏览器可能把已认证响应暴露给该网站。

支付业务逻辑

另一个领域是扫描器几乎看不到的逻辑。一个假设例子：结账 API 直接采用客户端请求中的金额，而不是在服务器端重新计算。另一个：收单 webhook 处理程序不校验通知签名就把订单状态改为"已支付"。这些分别涉及业务逻辑和消息真实性校验；如果相应场景可达，就可能造成财务损失。如何规划这类检查，可参阅我们关于业务逻辑安全测试的文章；API 本身的测试方法见REST API 安全评估一文。

权衡：扫描器还是人工测试，生产环境还是预发环境

NIST SP 800-115 把漏洞扫描和渗透测试视为不同的技术，各有长处和短处。扫描器能快速、可重复地覆盖大量资产，适合高频检查。人工测试速度较慢，却能发现逻辑缺陷、弱点链和授权漏洞，这些是扫描器无法串联起来的。有说服力的渗透测试用工具保证广度，用人保证深度。报告若主要由扫描器输出构成，就应当引起怀疑。

环境的选择同样是权衡。在生产环境测试能得到最真实的情况，但会给交易处理带来运营风险。预发环境更安全，但在配置、网络规则和数据上可能与生产不同，因此其结果不能不加说明地直接套用到生产环境。如果测试的是副本，报告必须列出已知差异，并指出哪些结论需要在生产环境中确认。分段尤其如此：预发环境中的规则只能证明预发环境本身的特性。

测试人员掌握的信息量影响能检查多少内容。黑盒测试模拟一无所知的外部攻击者。灰盒或白盒测试配有测试账号和架构文档，通常能在相同时间内覆盖明显更多的应用部分。这是实践经验而非统计数据，但道理很简单：测试者没有接触到的控制，就无法验证。

最后是预算。与其购买固定的人天数，不如用上表中的边界、适用且带版本号的 ASVS/WSTG Web 检查，以及面向基础设施和其他技术的独立标准来描述范围，再请服务商针对这一范围报价。这样，不透明的工作量估算就变成了可比较的规格说明。

如何为发现排序：风险、CWE 与被利用迹象

要求 11.4.4 要求按风险修复可利用的漏洞和安全弱点，因此报告需要清晰的优先级。CWE 分类对此有帮助。2025 版 CWE Top 25 最危险软件弱点列出了一些弱点类别，MITRE 称其往往容易发现和利用，可能导致系统被接管、数据被窃或应用中断。配套的 2025 CWE Top 10 KEV 弱点清单则依据 CISA 已知被利用漏洞目录对弱点类别排序。

这些信号不宜高估。某个发现属于 KEV 清单中的类别，是更仔细审视它的理由，但 CWE 分类本身并不能证明这个具体漏洞可以被利用或已经被利用过。起决定作用的是在你的环境中的确认：可达性、前提条件、攻击者能得到什么，以及离卡数据有多近。如何综合这些因素，可参阅我们关于基于风险的漏洞优先级排序的文章。

CWE 标注还有第二个用途。CISA 的"设计即安全"（Secure by Design）警示针对的是整类缺陷：跨站脚本、操作系统命令注入、目录遍历、缓冲区溢出。发现一旦完成标注，就可以把反复出现的类别反馈到开发规范中，系统地加以消除，而不是逐个修补。

依据要求 11.4.4 的修复与复测

如果渗透测试发现了可利用漏洞或安全弱点，工作不能止于报告。要求 11.4.4 规定，应按照 6.3.1 所定义的风险评估修复这些问题，并重复测试以验证修复。因此，复测应在原始合同中估算和安排，而不是拿到报告后再商量：团队有多少时间修复、由谁复查、在什么环境中复查。

复测结论仅限于实际检查过的内容。"已修复"的含义是：在约定环境中、针对所列攻击变体、截至注明日期，原有攻击链已不再奏效。在约定的复测范围内，检查相近变体很有价值：如果只修好了一个 API 参数，而相邻参数仍然接受客户端传来的金额，就不能把一次点状验证表述成整个缺陷类别已经消除。如何建立这样的复查，可参阅渗透测试修复验证一文。

第二张表是验收成果时应当索要内容的实用清单。

经得起评估员追问的报告

报告的价值在于能否据此采取行动。每个发现都应包含受影响资产、确认条件、足以支持授权复核的证据、适用时的 CWE 类别、仅针对合适 Web 检查的带版本号 ASVS 要求或 WSTG 领域引用，或者其他技术标准，以及结合支付环境的风险依据。缺乏可复现证据的发现既难修复，也难在评估员面前站得住脚。报告还应单设一节说明局限：哪些内容没有测试及原因，环境在哪些方面不同于生产环境。

把结果与更广泛的风险管理联系起来也很有益。NIST 网络安全框架 2.0 帮助机构理解和改进网络安全风险管理，其配置文件（Profiles）可以向管理层表明，支付环境测试是整体计划的一部分，而不是一次性的审计任务。采购软件中反复出现的发现类别应反馈给供应商。CISA 的"设计即安全"理念主张制造商承担更大份额的安全责任，而"按需安全"（Secure by Demand）指南正是为进行采购谈判的客户编写的。渗透测试得出的证据是这类谈判中的有力论据。

如何选择 PCI DSS 渗透测试服务商

在范围、方法论和报告期望确定之后再选择服务商才有意义，只有这样才能公平比较各家方案。请每位候选者说明其流程如何对应 NIST SP 800-115 的各阶段、适用的 Web 测试使用哪个版本的 WSTG 和 ASVS、其他技术采用什么标准、如何测试分段、自动化在哪里止步。索取一份匿名化的样例报告，并按上面的验收表评估。如果样例只是罗列扫描器输出并附上通用建议，那么无论价格如何，服务的深度都一目了然。

资质要落实到人：具体测试人员在支付应用和基础设施方面有哪些经验，谁负责把控报告质量，如何保证组织独立性。推荐人要自己去核实。11.4 下的渗透测试并不要求 QSA 或 ASV 身份；这一身份本身也不能证明渗透测试的质量。

商务条款应涵盖复测、遇到卡数据时的处理、与每个所有者办理授权、工作期间对严重发现的即时通报，以及报告的安全传输与保存。比较方案时不要只看每个 IP 或每天的价格，而要看各方承诺交付的范围和证据。如果你想针对自己的支付环境讨论这样的范围和证据形式，可以先看看我们的渗透测试服务介绍，带着现成的数据流图来沟通。如何确认合规取决于机构适用的评估路径，例如 SAQ，或形成 ROC 的评估。渗透测试报告可以为该流程提供技术证据，但不能替代所需的自我评估、评估员审查或 PCI DSS 验证文件。

结论

当合规被视为底线、降低风险被视为目标时，PCI DSS 渗透测试才能真正发挥作用。4.0.1 版要求 11.4 划定了框架：方法论包含 11.4.1 的最低内容并至少保存 12 个月的结果；内部和外部测试分别至少每 12 个月一次并在重大变更后进行；按 11.4.5 每年并在任何分段变更后测试分段，服务商还要满足至少每六个月一次的附加频率；按风险修复并复测。在这一框架内，质量取决于：从数据流推导出的范围、由有权者给出的授权、阶段清晰的方法论、依据带版本号要求的应用层检查，以及可以复现的报告。

回到开头那家假设的服务商。它需要的不是"再做一次渗透测试"，而是迁移后的计划外测试、频率正确的分段测试，以及一位不检查自己所配规则的测试人员。这样界定任务，就能为降低风险和理解证据边界提供可复核的依据，而不只是把文档文件夹整理得更整齐。