PCI DSS 数据流图：梳理持卡人数据并缩小范围

PCI DSS 评估通常从同一个要求开始：向我们展示卡数据流向了哪里。你们 wiki 里的图画着服务和箭头，却看不出哪些箭头携带卡号、哪些只携带令牌，也看不出分析数据仓库为什么在范围之外。没有这些，每个系统都会变成一场范围之争。

本文涵盖 PCI DSS v4.0.1 的要求、范围类别、一个使用托管支付字段的结账完整示例、令牌、分段、SAQ 类型和日常维护。这不是法律或合规建议：哪些要求适用由你的收单机构或评估机构决定，官方文本见 PCI SSC Document Library。

PCI DSS v4.0.1 的要求

PCI DSS v4.0.1 发布于 2024 年 6 月，是撰写本文时（2026 年 11 月）的现行版本。其中带未来生效日期的要求已于 2025 年 3 月 31 日起强制执行。有三项要求决定了你的图该怎么画：

账户数据包括持卡人数据（PAN、持卡人姓名、有效期、服务代码）和敏感认证数据（完整磁道数据、卡验证码、PIN 和 PIN 块）。PAN 是决定性要素：只要你存储、处理或传输它，就有了持卡人数据环境（CDE）。

SAQ A 既不包含要求 1，也不包含 12.5.2；SAQ A-EP 包含 1.2.3 和 1.2.4；SAQ D 和完整评估三项都包含。即使适用 SAQ A，这张图仍是证明你符合资格的最清晰的证据。

三类系统

第 4 节把这些要求适用于 CDE，以及任何“可能影响持卡人数据和/或敏感认证数据安全”的系统，这一措辞是 v4.0.1 用来取代“CDE 的安全”的。标准自己的例子是“控制支付表单或页面生成的 Web 服务器”。PCI SSC 的范围界定指南把系统分为三类，从上往下逐项判断：

一个系统属于它符合的最高类别。分段是可选的，但没有分段，整个“扁平网络”都在范围内，而且仅靠加密通常不能让卡数据脱离范围。

示例：使用托管支付字段的结账

商城 Web 应用提供结账页面；其中的卡字段是来自支付服务商的 iframe，通常称为托管字段（hosted fields）。订单服务负责扣款，Postgres 存储订单，夜间任务向数据仓库供数，CI/CD 部署商城：

1. 浏览器加载结账页面；服务商的脚本在它自己的 iframe 中渲染卡字段。
2. 客户输入 PAN、有效期和 CVC，浏览器通过 TLS 把它们直接发送给服务商。同源策略使商户页面的脚本无法进入 iframe。
3. 服务商把 PAN 存入自己的 vault，并返回一个令牌。
4. 页面把订单和令牌发送给订单服务。
5. 订单服务使用密钥通过服务商的 API 对令牌扣款，服务商再通过卡组织网络请求授权。
6. Webhook 确认结果。订单服务存储令牌 ID、卡品牌和后四位数字。

商户的任何系统都不存储、处理或传输 PAN，因此商户没有 CDE；你按要求 12.8 管理服务商，服务商有自己的评估。支付网关集成图用时序图展示了同一个结账流程，电商平台架构图则把它放在商品目录、购物车和订单服务之中。

Web 应用仍在范围内：攻击者只要修改了它，或修改了它加载的脚本，就能用假表单替换 iframe。这种攻击叫 e-skimming，正是 v4.0 新增 6.4.3（对支付页面脚本进行授权、完整性校验和清点）和 11.6.1（检测支付页面的变更）的原因。CI/CD 也在范围内，因为标准把部署工具算作系统组件。

令牌以及它们留在范围内的部分

PCI SSC 的令牌化指南把令牌化系统（包括去令牌化和 PAN 存储）归入 CDE。只持有令牌的系统可能在范围之外，前提是无法从令牌还原出 PAN、它们不能请求去令牌化或访问 vault，并且已与 CDE 分段。

vault 归服务商所有，所以订单服务和数据库可以符合条件，但有一个陷阱：可重复使用的令牌加上 API 密钥就能发起扣款。指南指出，能够发起交易的令牌“可能在 PCI DSS 范围内”，并建议商户询问收单机构。要像对待任何生产环境密钥一样保护这个密钥。

分段以及如何测试

分段通常指防火墙规则、安全组或独立的云账号。如果它隔离了 CDE，要求 11.4.5 规定，这些控制措施至少每 12 个月以及变更之后（服务提供商为每六个月）要由合格的独立测试人员进行渗透测试。在 1.2.3 要求的网络图中，像逻辑网络拓扑那样画出每个分段以及它们之间的控制措施。

这里商户没有 CDE，所以关键的边界要围住一切能修改结账页面的东西：订单服务、数据仓库及其凭据不得有权限部署到商城。

架构选择与 SAQ 类型

你的结账设计在很大程度上决定了自我评估问卷（SAQ）的类型，最终由你的收单机构确认：

2025 年 1 月的 SAQ A 修订从问卷中删除了 6.4.3 和 11.6.1，并新增了一项资格标准：商户确认“其网站不易受到可能影响商户电子商务系统的脚本攻击”。FAQ 1588 允许两种方式：用类似 6.4.3 和 11.6.1 的技术保护你的页面，或取得服务商的确认，证明其方案在按说明实施时能做到这一点。该标准适用于嵌入式 iframe，不适用于重定向，而且两者都仍需 Approved Scanning Vendor 每季度扫描一次（FAQ 1604）。只要有一个卡字段由你自己的页面渲染，就不能使用 SAQ A。

让图保持最新

标准把“账户数据流动或存储方式的任何变化”都视为可能的重大变更。每当你新增支付方式、服务商或渠道、结账脚本，或者新增接触支付数据的导出、日志管道或支持工具时，都要更新这张图。

留意支持工单和聊天中的卡号：对于这种非预期的渠道，v4.0.1 要求把它纳入 CDE，或安全删除数据并阻止该渠道再被用于此。在图上写明日期、作者和审批人；活文档工作流介绍了负责人和更新触发条件。

持卡人数据流图

这张图的读法如下：

• 三个区域。 红色是服务商的 CDE，琥珀色是能修改结账页面的商户系统，青绿色是只处理令牌的系统。
• 颜色跟随数据：红色表示卡数据，青绿色表示令牌，灰色表示两者都不是；虚线表示异步。
• 编号对应一次购买。 红色路径从不进入商户的框。
• 两条注释标出剩余的风险：页面脚本和可重复使用的令牌。
• 图例汇总了数据类别和范围。

把 PCI DSS 数据流图画清楚

为每条数据流和每个存储打上标签：

• 用框表示范围，并像 1.2.3 的指南建议的那样，为范围外的区域加上底纹。
• 每个渠道画一张图：电商、电话和终端各不相同。
• 包含不起眼的路径：退款、拒付、备份、日志和支持工具。
• 与网络图保持一致，数据流图应当是对网络图的补充。
• 省略不含账户数据或令牌的调用。

一个常见的错误是让 PAN 的线穿过只处理令牌的系统，这会在纸面上把它们拉进范围。符号约定见数据流图示例，信任边界见威胁建模指南，类似的清单见 GDPR 数据地图。

在 Archboard 中构建

1. 用 Google 或 GitHub 登录并创建一张图。
2. 为客户的浏览器，从 C4 模型包中添加一个人员。
3. 从基础包中添加三个框架节点，分别代表服务商（红色）、范围内的商户（琥珀色）和范围外的商户（青绿色）。
4. 在服务商框内，从 C4 模型包中添加两个外部系统节点，分别代表托管字段和支付 API，再从安全包中添加一个密钥保管库。在框下方放一个代表卡组织网络的外部系统。
5. 在琥珀色框内，从 C4 模型包中添加一个代表 Web 应用的容器，从 DevOps 包中添加一个流水线。
6. 在青绿色框内，为订单服务添加一个容器，并从数据包中添加 Postgres 和数据仓库节点。
7. 绘制带标签的连线：卡数据用红色，令牌用青绿色，其余用灰色，Webhook 和导出用虚线。
8. 从基础包中添加一个 Markdown 图例，再添加两个基础包的文本注释。

对于 1.2.3 要求的网络图，Terraform 转换器可以根据你的 .tf 文件生成初稿；支付流程图页面展示了时序视图。

这个示例共用 14 个图表节点，在 Free 套餐的限制之内。

常见问题

PCI DSS 要求提供数据流图吗？ 要求。v4.0.1 的要求 1.2.4 需要一份准确的、涵盖所有账户数据流且保持最新的数据流图。SAQ A 不包含此项；SAQ A-EP、SAQ D 和完整评估都包含。

PCI 网络图和数据流图有什么区别？ 网络图（1.2.3）显示 CDE 与其他网络之间的连接。数据流图（1.2.4）显示账户数据流向哪里、存储在哪里。两者应当一致。

使用 iframe 或托管支付页面，我的网站就不在 PCI 范围内了吗？ 不是。它能让卡数据远离你的系统，但嵌入 iframe 的页面仍可能遭到攻击，所以 SAQ A 要求每季度进行 ASV 扫描，对于 iframe 还要求防范脚本攻击。

只存储令牌的系统是否在 PCI DSS 范围之外？ 可以在范围之外，前提是无法从令牌还原出 PAN，并且这些系统已与令牌化系统分段。能够发起交易的令牌仍可能在范围内。

PCI 范围和图表应多久复查一次？ 账户数据流发生变化时就更新数据流图，并至少每 12 个月以及发生重大变更后（12.5.2）确认一次范围，服务提供商则为每六个月一次。

免费开始 — 1 个席位，无需信用卡。