pci-audit

PCI 审计 — 支付卡行业数据安全标准

PCI DSS v4.0.1 是适用于任何存储、处理或传输支付卡数据环境的安全标准。它包含 12 项高级要求和数百项子要求。大多数组织的成败取决于一个决定：范围。

版本说明：v4.0.1（2024 年 6 月）是唯一有效版本。v4.0 已于 2024 年 12 月 31 日停用，v4.0 标记为“未来生效”的要求已于 2025 年 3 月 31 日成为强制要求。评估时应涵盖所有这些要求；不要将任何一项视为仅供参考的最佳实践。

本技能首先强调范围确定，然后介绍与工程相关的要求。最终合规证明（SAQ 自我评估，或由 QSA 审计并出具合规证明）是本技能帮助准备的流程，而非本技能本身提供的合规证明。

交叉参考：crypto-audit 提供 Req 3 / 4 的加密细节；iam-audit 提供 Req 7-8 的细节；siem-detection 提供 Req 10 的日志记录细节；dependency-audit 和 owasp-audit 提供 Req 6（安全 SDLC）的细节；incident-triage 提供 Req 12.10（事件响应）的细节。

授权

仅审计用户组织拥有或委托用户审查的环境。绝不要在对话记录中读取、记录或粘贴真实卡数据（PAN、CVV、磁道数据）；请使用测试卡号，并追踪持卡人数据可能流经的路径。如果发现不应出现真实 PAN 的位置存在真实 PAN，请记录其位置，而非卡号，并将其视为可能的事件（incident-triage）。这是准备情况审查，不是 QSA 评估。

范围问题（首先执行）

PCI DSS 中的“范围”指：存储、处理或传输持卡人数据（CHD）的系统，以及可能影响这些系统安全的系统（与之连接的系统和影响其安全的系统）。范围内的所有内容都必须遵守全部 12 项要求。范围外的内容则不必遵守。

大多数 PCI 不合规问题都源于范围界定不当。 系统意外纳入范围会造成多年的合规负担；通过良好架构将系统排除在范围之外，则能节省大量成本。

确定范围

对环境中的每个系统进行分类：

类型	定义	是否在范围内？
CDE（持卡人数据环境）	存储、处理或传输 PAN、有效期、服务代码、与 PAN 同时出现的姓名或敏感认证数据	是 — 适用全部 PCI DSS 要求
与 CDE 连接	在没有补偿性分段的情况下与 CDE 直接连接	是
影响安全的系统	为 CDE 提供安全服务（认证、日志记录、监控、时间同步、DNS）	是
已分段	无直接连接；每年验证分段有效性	否
仅处理掩码或令牌化后的持卡人数据	系统处理的令牌或掩码 PAN 无法在不通过带外访问的情况下还原	通常否，但请核实令牌类型——商户可还原的替代令牌仍在范围内

审计步骤： 端到端追踪每一条支付流。确定 PAN 在何处进入环境、流向何处以及在哪里终止。PAN 接触到的每个系统都在范围内；未经过分段却与这些系统连接的每个系统也都在范围内。

缩小范围（高杠杆的工程工作）

PCI 工作中投资回报率最高的通常是缩小范围：

• 使用托管支付页面 — 让 Stripe / Adyen / Braintree / Worldpay 托管输入表单。PAN 不会到达你的服务器。浏览器直接与处理方通信。你的范围缩小到“iframe 集成”。
• 使用令牌化 — 支付处理方将 PAN 转换为令牌，由你的系统存储。没有处理方端的访问权限，该令牌毫无意义。你的系统处理的是令牌，而不是 PAN。
• 使用 P2PE（点对点加密）— 对于终端现场交易，在刷卡时进行加密，确保明文不会经过你的网络。
• 网络分段 — 对于保留的 CDE，确保 CDE 与其余部分之间通过防火墙 / VLAN / 命名空间隔离。在 CDE 边界默认拒绝。

每年处理 100 万笔交易、通过 Stripe Checkout 交易且服务器上不存储 PAN 的商户，其合规范围远小于将 PAN 接收到自有表单中再转发给 Stripe 的同一商户。同一商户，审计结果却大不相同。

商户级别与评估类型（合规态势，而非工程要求）

简要说明，因为这决定了审计的频率和严格程度：

级别	交易量（Visa）	验证要求
1	每年 > 600 万笔交易，或任何交易量下发生过数据泄露的商户	每年由 QSA 进行现场评估 → AoC
2	每年 100 万至 600 万笔交易	每年填写 SAQ（自行评估）或由 QSA 进行评估（自 2024 年起，Visa 要求由 QSA 评估）
3	每年 2 万至 100 万笔电子商务交易	每年填写 SAQ
4	其他所有情况	每年填写 SAQ

SAQ 类型（自我评估问卷）与商户的 CDE 形态相匹配 — SAQ A（完全外包的电子商务）、SAQ A-EP（进行部分重定向的电子商务）、SAQ B（仅终端，通过拨号 / IP 连接且不进行电子存储）、SAQ C-VT（基于 Web 的虚拟终端）、SAQ D（其他所有情况，篇幅最长）。正确的 SAQ 是其所有条件都与你的环境相符的那一种。

与工程相关的要求（此技能审计的子集）

要求 3 — 保护存储的持卡人数据

默认做法：不要存储 PAN。 如果必须存储，则应在静态存储时加密，并尽量减少保留的数据。

• 静态存储的 PAN 必须不可读：使用强加密（AES-256），按照要求 3.6 进行密钥管理（参见 crypto-audit），轮换密钥，并对密钥保管实行职责分离
• 敏感身份验证数据（CVV / CVV2、完整磁条数据、PIN / PIN 块）在授权后不得存储 — 无论是否加密，一律不得存储
• 默认对显示的 PAN 进行掩码处理 — 通常显示前 6 位 + 后 4 位
• 以任何其他形式（备份、日志、调试输出）呈现的 PAN 都必须不可读

审计时的 grep 模式：

• 数据库架构：名称为 pan、card_number、cc_number、cardnum、account_number 的列
• 写入卡数据的代码路径：pan、cardNumber、正则表达式 ^4[0-9]{12,15}$（Visa）、^5[1-5][0-9]{14}$（Mastercard）、^3[47][0-9]{13}$（Amex）、^6(?:011|5[0-9]{2})[0-9]{12}$（Discover）
• 日志：console\.log.*cardNumber、logger\..*\.pan、log\..*card
• 错误报告：确认 Sentry / Datadog / Bugsnag 的清理规则会对卡号模式进行脱敏（通过 Luhn 校验的 13–19 位数字序列）
• 备份：确认备份保留策略不会包含未加密的 CHD

如果源代码、锁文件或日志中出现任何通过 Luhn 校验的 PAN，即属于发现项，无论其用途如何；但已公开发布的测试卡号除外（4242 4242 4242 4242、4111 1111 1111 1111 以及处理方文档中列出的其他测试 PAN）。

要求 4 — 保护通过开放网络传输的数据

• 使用 TLS 1.2 或更高版本，且仅使用现代密码套件（配置详情参见 crypto-audit）
• 不得通过终端用户消息技术（电子邮件、短信、聊天）传输 PAN — 任何包含此类传输的流程都应拒绝
• 传输 PAN 的内部专用网络仍应进行加密（纵深防御 — 要求 4.2.1 仅规定在开放的公共网络上必须使用强加密）

要求 6 — 开发和维护安全的系统与软件

安全审计系列从这里开始与 PCI 接轨。此要求的大部分内容可通过运行现有技能来满足：

• 6.2 安全地开发定制软件 — 参见 owasp-audit、api-audit
• 6.3 识别并处理漏洞 — 参见 vuln-research、dependency-audit、finding-triage
• 6.4 保护面向公众的 Web 应用免受攻击 — 使用 WAF，或每年进行代码审查，并在发布后进行人工审查
• 6.5 安全地管理所有系统组件的变更 — 变更管理、开发环境与生产环境之间的职责分离，以及在低环境中使用预生产数据前对其进行脱敏

审计 grep 模式：

• 低环境配置中包含真实 PAN 的情况（常见问题：使用包含卡数据的生产数据库转储来填充预发布环境）
• 绕过安全 SDLC 的代码路径（直接在生产环境进行热修复的模式、对会影响生产环境的分支提交时使用 --no-verify）

要求 7 — 根据业务需要限制对持卡人数据的访问

• 基于角色的访问 — 只有工作需要使用 CHD 的人员才能访问
• 默认拒绝 — 明确授予访问权限，绝不继承权限
• 记录并审查特权用户 ID

完整的身份与访问深入分析请参见 iam-audit。

要求 8 — 识别用户并验证访问身份

• 为每位用户分配唯一 ID（不使用共享账户）——包括服务账户
• 强身份验证 — 密码须符合当前 PCI 复杂度要求；非控制台管理访问、所有远程网络访问，以及（要求 8.4.2，自 2025 年 3 月 31 日起强制要求）所有进入 CDE 的访问，均须使用 MFA
• 对于最敏感的访问路径，MFA 必须具备抗网络钓鱼能力（v4.0.1 中为建议项，非强制要求）
• 按照当前 PCI 参数设置账户锁定、会话超时和密码轮换（v4.0 放宽了部分旧有要求——请核对当前文本）

实现模式和身份提供商集成请参见 iam-audit。

要求 10 — 记录并监控对网络资源和持卡人数据的所有访问

• 记录每次对 CHD 的访问 — 谁、何时、做了什么、来自何处
• 集中存储日志、同步时间（要求 10.6 — NTP），保留至少 12 个月（其中 3 个月须可立即访问）
• 每日审查日志——人工或自动均可。异常情况须触发调查
• 保护日志完整性 — 使用独立系统、仅写入权限和不可变存储

工程实现请参见 siem-detection；审查频率请参见 soc-operations。

要求 11 — 定期测试系统和网络的安全性

• 漏洞扫描 — 每季度进行内部和外部扫描。外部扫描必须由 ASV（批准的扫描供应商）执行
• 渗透测试 — 至少每年一次，发生重大变更后也须进行。涵盖内部和外部、网络层和应用层。由合格的内部资源或第三方执行测试
• 分段测试（适用于依靠分段缩小范围的环境）— 每年进行专门用于验证分段的渗透测试
• 对关键文件 / 配置进行文件完整性监控

请参见 dependency-audit（漏洞扫描）、web-pentest（年度应用渗透测试）和 red-team-engagement（适用于更高等级的年度攻击性测试）。

要求 12 — 维护信息安全策略

计划层面的要求。工程方面的工作包括：

• 12.10 事件响应计划 — 参见 incident-triage。每年至少测试一次
• 12.5 第三方 / 服务提供商管理 — 类似 DPA 的证明材料、每年审查服务提供商的合规情况（你的处理方会向你发送 AoC；你必须留存）
• 12.6 安全意识培训 — 面向处理 CHD 的人员

常见审计发现（现实场景中的初步假设）

• 日志中出现 PAN — 错误日志、调试日志或访问日志包含卡片数据，这些数据被 Sentry / Datadog / Bugsnag 捕获，并在授权期限之外保留
• 持久化存储敏感身份验证数据 — 为了“方便再次扣款”而存储 CVV（这是禁止的），或意外捕获完整磁道数据
• 低环境使用生产数据填充 — 暂存数据库包含未经清理的生产环境转储中的真实 PAN
• 误解令牌化范围 — 存储在你们数据库中的替代令牌如果可由你们的处理器账户还原，仍在范围内；只有单向令牌才能缩小范围
• iframe 与代理 — “托管支付页面”实际实现为代理：你们的服务器在转发 PAN 前短暂处理了它（仍在范围内）；而真正的 iframe 则不会让你们的服务器看到 PAN（不在范围内）
• 依据防火墙规则而非架构进行分段 — 防火墙规则“仅允许”特定流量，但系统仍共用一个 VLAN；有效分段需要架构层面的隔离
• MFA 缺口 — v4.0 扩大了 MFA 要求（自 2025 年 3 月 31 日起强制实施）；符合 v3.2.1 的旧环境可能存在缺口

验证后再记录

根据 references/findings-format.md 中的定义，为每个候选项确定一个结论，并在确认任何内容之前，按照 references/verification.md 执行反证核查。

不符合 PCI DSS 要求即构成一项发现。 该要求是预期的控制措施。应依据其对持卡人数据造成的暴露风险，使用 references/severity-calibration.md 评定严重程度，而不是依据审计后果：将 CVV 写入可访问的表属于 High 或 Critical；缺少季度 ASV 扫描报告本身并不构成暴露。没有暴露风险的缺口（缺少政策文件、培训记录逾期、年度审查尚未完成）属于文档缺口：在报告的专属章节中列出，不标注严重程度，也不在 findings.json 中记录。若纵深防御存在缺口，但另一层已阻止暴露，则应作为加固建议。

此处各类结论的示例如下：

• confirmed：代码或导出的配置表明，持卡人数据到达了要求禁止其到达的位置，或进入 CDE 的路径缺少必需的控制措施。
  • 在结账处理程序中，logger.info("charge", req.body) 会将 PAN 明文写入应用程序日志；该处理程序对应的表单会将 cardNumber 提交到服务器（要求 3.5.1）。追踪路径从表单字段到日志调用。
  • CDE 管理控制台的 IdP 策略导出显示，该控制台允许仅使用密码登录（要求 8.4.2）。位置为证据文件和行号（见下文）。
  • 不安全的已发布默认值（例如，除非覆盖，否则设置为 LOG_REQUEST_BODIES=true）属于 confirmed，并带有 system_configuration 条件（“未设置 LOG_REQUEST_BODIES=false 的部署”）和 medium 置信度。无法查看的部署事实会降低置信度，但不会改变判定或严重程度。
• needs_validation：代码支持该主张，但有一个事实无法从代码中确认。指出该事实，并指定负责核查的人员或团队。
  • Sentry 会从支付路由接收请求正文，而数据清理设置在 Sentry 项目中，不在代码仓库里。阻碍因素：该项目的服务器端清理规则是否涵盖信用卡号。核查：在 Sentry 中，前往 Project Settings > Security & Privacy，确认数据清理器已启用，且高级规则涵盖 $creditcard；将设置导出并保存到证据文件夹。
  • Staging 环境由 scripts/seed-from-prod.sh 填充，该脚本会调用清理器。阻碍因素：实际运行该脚本的流水线是否传入了 --sanitize。核查：统计（不要打印）Staging 环境 payments 表中通过 Luhn 校验的 13–19 位数值的数量。
• rejected：位于指定位置的具名控制措施排除了所有路径上的问题。
  • “结账处理 PAN”：卡片字段是 Stripe Elements iframe，服务器处理程序只读取 paymentMethodId。ruled_out_by.location 指向读取请求正文的处理程序行；control 则注明 iframe 集成。
  • test/fixtures/cards.json 中通过 Luhn 校验的 16 位数是 Stripe 发布的测试 PAN。ruled_out_by 指向该 fixture 行，并注明这是有文档记录的测试卡。
  • 只有在补偿性控制措施工作表存在且证据表明该控制正在运行时，才可将由补偿性控制措施覆盖的缺口判为 rejected；ruled_out_by.location 指向该工作表。若工作表没有有效性证据，则判为 needs_validation。
  • 依赖项中的控制措施（例如，在自身日志中屏蔽 PAN 的支付 SDK）可排除某个候选项：ruled_out_by.location 指向锁文件或清单中固定版本的行，control 则注明库函数和版本。
  • 对“永远无法触达”的排除项，ruled_out_by.location 应指向相关证据：唯一的导入或调用位置；如果没有任何代码使用该依赖项，则指向依赖项声明。

已部署资源的证据。 许多 PCI 发现涉及的并非文件：IdP 和 MFA 策略、防火墙规则和安全组、日志保留设置、处理方的 AoC、书面政策。将只读命令输出或导出内容脱敏后，保存到 <audit dir>/evidence/<name>.json 或 .txt（例如 audit/pci/evidence/okta-cde-policies.json、audit/pci/evidence/sg-cde-ingress.txt），并将 location 和 evidence[] 指向该文件及相关行。流程和政策证据（事件响应计划、补偿性控制措施工作表、访问审查记录）也应放在同一文件夹中。切勿将 PAN、CVV、磁道数据、PIN 块或凭据值保存到证据、findings.json 或报告中；记录该值所在的位置，最多只记录末 4 位。只有在获得授权且只读的情况下才能执行实时检查；仅描述但未实际运行的检查属于 needs_validation。 指纹采用 pci-audit/<class>/<file or resource>/<symbol or name> 格式，以斜杠分隔，不含行号。验证器会拒绝 :<digits> 片段，因此 ARN 和 host:port 要用斜杠表示。使用简短的类别，例如 pan-at-rest、sad-stored、pan-in-logs、pan-unmasked、pan-in-lower-env、weak-transmission、pan-in-messaging、shared-account、mfa-gap、access-not-restricted、audit-log-gap、segmentation-gap、scope-misclassified：

pci-audit/pan-in-logs/src/routes/checkout.ts/createCharge
pci-audit/sad-stored/db/schema.sql/payments.cvv
pci-audit/mfa-gap/okta/acme/cde-admin-console
pci-audit/segmentation-gap/aws/123456789012/us-east-1/sg-0abc/ingress-0.0.0.0-0

对于已部署的资源，指纹应根据资源（提供商、账户或租户、名称）生成，而不是根据证据文件名生成，这样重新采集证据后指纹仍保持不变。

ext 字段（任意记录上的可选对象；不要重复已有字段的内容，例如 cwe 或 location）：

键	值	示例
requirement	存在差距所违反的 PCI DSS v4.0.1 要求	"8.4.2"、"3.3.1"
scope	受影响系统的范围类别	"cde"、"connected-to"、"security-impacting"
data_element	暴露的持卡人数据元素（如有）	"PAN"、"SAD-CVV"、"SAD-track"、"PIN-block"

然后：

1. 按 fingerprint 排序，编写 findings.json，并设置 skill: "pci-audit"。验证并修复所有错误：node references/validate-findings.mjs findings.json（references/validate-findings.mjs）。
2. 可选导出 SARIF：node references/to-sarif.mjs findings.json -o findings.sarif（references/to-sarif.mjs）。
3. 将文档缺口和加固说明整理成简短列表，与 JSON 文件放在一起（例如 notes.md）。它们不是记录。

处置状态（稍后设置，通常由 finding-triage 设置）：Fixed / Deferred / Accepted Risk / Mitigated (platform/config) / Requires major migration。PCI 不鼓励接受风险：大多数“接受的风险”都应采用补偿性控制，并提供有效性的书面证据。误报应标记为 rejected 记录，而不是处置状态。

输出格式

先编写 findings.json。根据它生成报告；正文不得更改 JSON 中尚未注明的判定、严重程度或阻断项。

# PCI DSS v4.0.1 Readiness Review
## Merchant: [name]   ## Merchant level: [1/2/3/4]   ## SAQ type: [A / A-EP / B / C-VT / D / n/a, Level 1 QSA]
## Date: [date]   ## Reviewer: [name]   ## Scope: [full | partial, what was left out]
## findings.json: [path], validated: [yes]   ## Evidence folder: [path]

### Summary
- Confirmed: [N] (Critical [n] | High [n] | Medium [n] | Low [n])   Needs validation: [N]   Rejected: [N]
- Documentation gaps: [N]   Hardening notes: [N]

### Confirmed findings
#### [SEVERITY] [Title]  `fingerprint`
**Requirement:** [ext.requirement]   **Scope:** [ext.scope]   **Data element:** [ext.data_element]
**Location:** `path:line` (source or evidence file)   **Confidence:** [medium | high (reproduced)]
**What and why it matters:** [the trace or the config evidence, in a few lines; the exposure to CHD]
**Fix:** [concrete change]
**Verify the fix:** [the check that proves it]

### Needs validation
| Finding | Requirement | Blocker | Check for the owner to run |
|---|---|---|---|

### Hardening notes (not findings)
- [gap] — [why it isn't a finding] — [effort]

### Documentation gaps (not findings)
| Requirement | What's missing | Owner | Evidence expected |
|---|---|---|---|

### Rejected (do not re-raise)
| Fingerprint | Ruled out by | Location |
|---|---|---|

### Scope determination
- [ ] Payment data flow diagrammed end-to-end
- [ ] CDE explicitly bounded
- [ ] Connected-to systems enumerated
- [ ] Segmentation evidence documented
- [ ] Scope-reduction opportunities identified

| System | Scope category | Why | Evidence |
|---|---|---|---|

### Per-requirement status
| Req | Confirmed | Needs validation | Documentation gaps |
|-----|-----------|------------------|--------------------|
| 3 — Stored CHD | | | |
| 4 — Transmission | | | |
| 6 — Secure SDLC | | | |
| 7 — Access restriction | | | |
| 8 — Authentication | | | |
| 10 — Logging | | | |
| 11 — Testing | | | |
| 12 — Program | | | |

### Recommended scope reductions (if applicable)
[Hosted payment page, tokenization, network segmentation improvements with effort estimates]

### Compensating controls (if used)
[Each compensating control: control description, what it compensates for, evidence of effectiveness, review cadence, worksheet path]

### Prioritized remediation plan
1. [highest first: SAD storage, PAN in clear, missing CDE MFA]

按要求统计的表格应根据 findings.json 中的记录（按 ext.requirement 统计）以及文档缺口列表中的条目生成。它不代表单独的判定。

边界

• 此技能用于工程侧审计和准备工作。最终合规证明（自行评估商户签署的 SAQ，以及由 QSA 为较高等级商户出具的 AoC）属于单独流程。
• 对于由 QSA 主导的 Level 1 评估，此技能用于为 QSA 提供输入，不能取代 QSA 的独立评估。
• 拒绝协助构建违反 PCI DSS 的流程，例如存储 CVV、通过电子邮件传输 PAN、绕过令牌化以采集原始银行卡数据。
• 如果审计发现存在正在发生的入侵（PAN 已泄露或疑似发生数据泄露），应转交给 incident-triage；PCI 数据泄露响应有特定的时限和通知要求（通常须在 24 小时内通知收单机构）。
• 品牌特定规则（Visa、Mastercard、Amex、Discover、JCB）是在 PCI DSS 之上叠加的要求。对于有品牌特定义务的商户（例如须遵守 Visa 的 Cardholder Information Security Program），请查阅相应银行卡品牌的计划文档。

参考资料

• PCI DSS v4.0.1 — pcisecuritystandards.org/document_library
• PCI DSS v4.x 快速参考指南 — 面向从业者的摘要
• SAQ 说明和指南 — 供自行评估的商户使用
• PCI SSC 常见问题数据库 — 官方解释指南
• QIR / QSA / PFI / ASV 名录 — 用于选择获批的评估人员 / 供应商
• Visa 持卡人信息安全计划（CISP） — Visa 特定的分层要求
• Mastercard 网站数据保护（SDP）计划 — Mastercard 层级要求
• 开放式 Web 应用程序安全项目（OWASP） — 要求 6 的实质性内容
• NIST SP 800-53 — 可与许多 PCI 要求直接对应的控制目录
• 《PCI 合规》 — Branden Williams、Anton Chuvakin 著 — 面向从业者的书籍，更新至 v4.0
• 共享参考资料（构建时复制到 references/）：references/findings-format.md、references/verification.md、references/severity-calibration.md、references/findings.schema.json