本文档介绍了根据支付卡行业 (PCI) 安全标准委员会架构设计云环境的最佳做法。这些最佳做法适合在云端迁移或设计受 PCI 合规性要求的组织。 本文档参考了 PCI DSS 4.0 要求（如适用）。
了解 PCI DSS 评估范围
如果您的组织通过互联网开展商务，您需要支持并保持 PCI 合规性。您设计和管理云环境的方式会影响 PCI 数据安全标准 (DSS) 评估所针对的系统范围。范围界定了 IT 资产的安全性以及您支持和维护 PCI 合规性的能力。为了确保 PCI 环境的范围正确，您需要了解业务流程和设计决策如何影响范围。
范围是什么？
存储、处理或传输持卡人数据 (CHD) 的所有系统都在 PCI DSS 评估的范围内。安全性对于您的整个云环境至关重要，但范围内的系统遭到入侵可能会导致数据泄露和 CHD 泄露。
在图 1 中，持卡人数据环境 (CDE)、连接的系统和影响安全的系统位于评估范围边界内，而不受信任的系统和范围外的系统则在评估范围边界之外。
根据 PCI DSS，范围内的系统是可信的。范围内的系统包括 CDE 以及涉及或可能影响 CDE 安全的任何系统。
如果某个系统在同一网络上、共享数据库或文件存储空间，或者以其他方式访问或连接到 CDE 内部的任何系统或进程，但并不直接访问 CHD，则该系统是“连接的系统”。
如果某个系统能够或者在遭到入侵后允许攻击者访问 CDE，则该系统是“安全受到影响的系统”。security-impacting所有连接的系统和安全受到影响的系统都始终在范围之内。
范围外的系统在 PCI DSS 中的定义是不可信的系统，对于想要访问 CHD 或敏感身份验证数据 (SAD) 的攻击者来说没有价值。如果某个系统对范围内的系统安全没有影响，则该系统不在范围之内，即使范围外的系统遭到入侵也是如此。虽然范围外的系统不会直接予以评估，但有资质的 PCI 安全评估方 (QSA) 会验证您的范围划定是否准确以及是否能够根据 PCI DSS 保护 CHD。因此，请确保您的范围边界受到严格保护，并且进行了持续而全面的监控，作了清晰的记录。
PCI 环境中的连接
多个 PCI DSS 要求引用了连接，但 PCI DSS 未明确定义连接。通过理解 PCI DSS 范围划定和网络分段的 PCI SSC 指南 (PDF) 中的范围划定决策树，您可以解释此上下文中“连接”的含义。
为评估 PCI 范围，“连接”的定义如下：
- 连接两台计算机或系统的活跃信息传输
- 两方中的哪一方发起调用
记录环境时，最好清楚地说明哪一方有权发起连接。配置为仅允许单一方向流量的防火墙可以强制执行单向连接。例如，如果满足以下所有条件，则适用范围内的付款处理应用可向范围外的数据库服务器发出查询请求：
- 连接和范围外的数据库不会存储、处理或传输 CHD 或 SAD。
- 数据库位于单独的网络中，或者以其他方式与 CDE 分开。
- 数据库无法直接或间接启动 CDE 的任何调用。
- 数据库不会向 CDE 提供安全服务。
- 数据库不会影响 CDE 的配置或安全性。
- 数据库支持 PCI DSS 要求。
下图显示了决定系统范围的因素：
在图 2 中，系统范围按以下方式确定：
属于 PCI DSS 范围的系统组件：
- 位于 CDE 中且符合以下情况之一的系统：
- 系统组件可存储、处理或传输 CHD 或 SAD。
- 系统组件与存储、处理或传输 CHD 的系统位于同一网络段中（例如位于同一子网或 VLAN 中）。
- 符合以下情况之一的连接的系统或安全受到影响的系统：
- 系统组件直接连接到 CDE。
- 系统组件会影响 CDE 的配置或安全性。
- 系统组件从范围外的系统和网络中细分 CDE 系统。
- 系统组件会间接连接到 CDE。
- 系统组件会向 CDE 提供安全服务。
- 系统组件支持 PCI DSS 要求。
- 位于 CDE 中且符合以下情况之一的系统：
如果符合以下所有情况，则系统组件可视为不可信的组件并且不在 PCI DSS 范围之内：
- 系统组件不会存储、处理或传输 CHD 或 SAD。
- 系统组件与存储、处理或传输 CHD 或 SAD 的系统不在同一网络段中（例如不在同一子网或 VLAN 中）。
- 系统组件无法连接到 CDE 中的任何系统。
- 系统组件不符合适用于连接的系统或安全受到影响的系统的任何条件。
范围外的系统可能包括连接到“连接的系统组件”或安全受到影响的系统组件的系统，这些系统组件采取了控制措施，以阻止范围外的系统使用范围内的系统组件访问 CDE。
实际上，系统范围的 PCI DSS 定义可能意味着，如果已正确实现和记录细分，则 Web 应用的会话存储区和电子商务数据库可能在范围之外。下图展示了读取和写入连接在范围内的系统和范围外的系统之间的工作方式：
图 3 显示了以下连接：
- 只读：
- 范围内的付款处理应用从范围外的购物车数据库中读取购物车 ID，并从 DNS 和 NTP 读取数据。
- 只写：
- 范围内的付款处理应用向范围外的应用主数据库和 Cloud Logging 写入数据。
- 超出范围的主 Web 应用会将数据写入日志记录服务。此数据不包含 CHD 或 SAD。
- 读取和写入：
- 公共 Web 上的用户按如下方式读取和写入请求元数据：
- 用户执行范围内的操作处理应用读写操作。此请求元数据是包含 CHD 和 SAD 的购物车 ID 和购物车身份验证密钥。
- 用户向范围外的主 Web 应用读写数据。此请求元数据是不包含 CHD 或 SAD 的会话 ID。
- 范围外的主 Web 应用读取数据并将数据写入范围外的购物车数据库、会话存储区和应用主数据库。此数据不包含 CHD 或 SAD。
- 范围内的付款处理应用对范围内的卡片令牌化服务以及公共 Web 上的信用卡处理器执行数据读写操作。此数据包括 CHD 和 SAD。
- 公共 Web 上的用户按如下方式读取和写入请求元数据：
图 3 中的架构描述了两个独立的 Web 应用：主 Web 应用（主应用），该应用超出了 PCI 的适用范围，而付款处理应用（结账应用）在范围内。在此架构中，只能在前面列表中描述的两个实体之间发起连接。从调用方的角度，实体之间的连接可以是只读、读写或只写。任何未明确说明的路径或请求方向都会被细分阻止。例如，付款处理应用可以从购物车数据库读取数据，以及向日志记录服务写入数据，这包括发起与这些实体的连接。
范围内的系统通常调用范围外的系统和服务。这些连接保持安全状态，因为细分会阻止任何远程调用方（持卡人除外）直接或间接发起与 CDE 的连接。图 3 显示了结算应用的唯一入站路径来自用户。
在图 3 中，范围外的服务或应用不会向付款处理应用提供任何配置或安全数据。数据按以下方式流经架构：
- 主应用将用户转到结算应用，并使用 HTTP
POST来传输CartID和名为CartAuthKey的验证器。CartAuthKey是CartID的哈希以及仅对主应用和结算应用公开的预共享 Secret。 - 结算应用通过以下方式验证用户：对
CartID连同 Secret 进行哈希处理，并将该值与CartAuthKey进行比较。 - 验证用户数据身份后，
CartID用于从购物车数据库读取购物车内容。所有持卡人数据都会从用户直接发送到结算应用。 - 如果使用了付款资料，则持卡人数据将存储在令牌化服务中。
- 付款处理完成后，结果会通过一个只写数据库服务账号插入主应用的数据库。
界定范围的注意事项
在 PCI DSS 范围划定和网络分段指南中，PCI 安全标准委员会 (SSC) 建议您假定所有系统都在范围内，除非系统已通过其他的方式予以验证。此 SSC 建议并不表示您应尽可能扩大范围。这意味着 QSA 会将所有系统评估为可信系统，除非您可以表明系统没有与之建立连接或影响 CDE 的安全影响。为了满足合规性要求并保证 IT 资源的安全，您应该根据尽可能少的信任系统，将您的环境范围限定为最小权限原则可能。
在评估范围之前，请评估您的环境，了解并记录范围内的系统和范围外的系统之间的边界。QSA 的第一项任务是确认您记录的范围合理包含了 CDE 和连接的系统。作为整体评估的一部分，QSA 会验证范围外的系统不会对任何范围内的系统造成负面影响。
确保您了解特定于您环境的任何特殊情况，例如：
- 如果您通过电话或 VOIP 系统收集持卡人数据，请考虑保护基于电话的支付卡数据 (PDF) 中介绍的额外范围划定问题。
- 如果您的服务提供商需要访问 CDE (PDF) 才能运行销售终端系统，则您的服务提供商使用的系统可能被视为连接的系统。这可能需要注意额外的范围划定和尽职调查事项。
Google 的安全最佳做法可帮您在范围内的系统与不受信任的系统之间建立和演示清晰且可防御的边界，这将有助于您进行评估。通过遵循最小权限原则来管理访问权限和安全性，有助于最大限度地减少持卡人数据的泄露几率，最大限度地减少 CDE 的攻击面，从而缩小范围。减少范围内的系统的涉及面有助于减少系统复杂性并简化 PCI DSS 评估。
不正确界定范围的风险
如果范围过于宽泛，则会导致评估成本高昂，并增加合规性风险。为帮助缩小范围，请尽可能少地信任系统，并且仅向少数指定用户授予访问权限。通过尽职调查评估和自我评估，您可以确定不应在 PCI DSS 范围内的系统，验证它们是否符合范围外的系统的指导方针，并相应地缩小范围。这种缩小范围的过程是发现哪些系统不受信任的最安全方式，有助于确保这些系统不会影响范围内的系统。
如果您需要较大的基础架构来满足 PCI DSS 要求，可能会导致无关范围包含在您的评估范围内。如果您向范围中添加额外的系统，则会导致您合规的风险。它还可以通过扩大受信任范围内环境的攻击面来降低整体安全状况。
网络安全和 PCI DSS 的核心原则是假定您的部分或全部网络已遭到入侵。Google 的零信任安全模型对此进行了介绍，后者拒绝仅限边界保护的安全，取而代之的是每个系统负责保护自己的安全模型。Google 的安全模型与 PCI DSS 是一致的，因此建议将 CDE 及其连接的系统部署在更小的可信空间中，该空间从更广泛的 IT 环境细分，并且不与其交互。
在作用域内的 PCI 环境中，不要将 CDE 放在包含较大边界的大型可信空间中。这样做可能会导致错误的安全感，并破坏整体深度防御策略。如果攻击者破坏了边界安全，那么他们就可以在受信任的私有内网中轻松运行。您可以考虑采用哪种方法收缩可信空间，使其仅包含操作和保护其自身的需要，并避免仅依赖边界安全。通过了解并遵循这些原则，您可以设计云环境，以帮助保护关键系统并降低遭到入侵的系统受到污染的风险。
一个值得信赖的大型环境需要类似的大型管理应用，才能维持这些系统的持续监控、维护、审核和库存。系统架构、变更管理流程和访问权限控制政策的复杂性可能会带来安全和合规风险。如果难以维护这些监控流程，可能会导致很难满足 PCI DSS 10 和 11 中的要求。请务必了解这些风险，并实施相应策略以限制您评估的环境的范围。如需了解详情，请参阅本文档后文的支持持续合规性部分。
适用 PCI DSS 范围的 Google Cloud 服务
在开始缩小 PCI 环境的范围之前，请先了解 Google Cloud 服务的适用 PCI DSS 范围。这些服务提供了基础架构，供您用来构建存储、处理或传输持卡人数据的服务或应用。
缩小范围的策略
本部分介绍了减少评估范围的以下策略：资源层次结构控制、VPC Service Controls 细分和令牌化。您应考虑采用所有这些策略，而不是选择一种方法，这样可最大限度缩小潜在的范围。
没有针对 PCI 作用域的通用解决方案。您的本地网络中可能已经存在现有细分，或者卡片处理解决方案可能导致基础架构设计看起来与此处介绍的稍有不同。您可以运用这些策略作为自己的原则，应用到自己的环境中。
建立资源层次结构控制
Google Cloud 资源分层组织如下：
- 组织资源是 Google Cloud 资源层次结构的根节点。组织资源包含文件夹和项目资源。应用于组织资源的 Identity and Access Management (IAM) 访问权限控制政策适用于组织整个层次结构的所有资源。
- 文件夹可以包含项目和其他文件夹，并使用文件夹级层 IAM 权限控制对其资源的访问。文件夹通常用于对类似项目进行分组。
- 项目是所有资源的信任边界，也是 IAM 强制执行点。
为帮助减少评估范围，请遵循 Google 关于定义资源层次结构的最佳实践。下图显示了 PCI 合规性的示例资源层次结构：
在图 4 中，PCI 范围中的所有项目都分组到一个文件夹中，以便在文件夹级层实现隔离。PCI 作用域文件夹包含 CDE，以及另一个包含共享服务的项目。当您实现类似的资源层次结构时，PCI 分区文件夹构成 PCI 合规性范围的逻辑根。通过确保只有指定用户有权访问此文件夹及其项目，您可以从评估范围中排除层次结构中其他文件夹、项目和资源。
如果仅授予用户根据需要访问其文件夹和项目的权限，那么可确保只有指定用户才能访问范围内的组件。这支持 PCI DSS 要求 7.2 和 7.3 (PDF) 等。要确保正确设置父级组织和文件夹的权限，请参阅政策继承的影响。如需支持 PCI DSS 要求 8.4.1，请务必为指定用户强制执行多重身份验证 (MFA)，并参阅有关多重身份验证指导的 PCI DSS 补充 (PDF)。为了在资源层次结构中强制执行合规性，请确保您了解如何设置组织政策限制条件。这些限制条件支持持续合规性，有助于保护受信任的环境免受提权影响。
与所有 PCI 合规性一样，您需要对自己的环境及其范围内的组件进行充分的日志记录和监控，以建立明确的范围边界。资源层次结构与身份和访问权限管理密切关联，必须对用户操作进行有效的日志记录、审核和监控，以强制执行和维护两者之间的分离。
实现网络分段
如网络分段 (PDF) 的 PCI SSC 补充指南中所述，网络分段是重要的架构模式，可帮助保护您的 CDE 及所连接的系统。如果实现得当，网络分段会移除不受信任的系统可能用来访问 CDE 或其关联组成部分的网络路由，从而缩小评估范围。请仅定义可信组件之间进行通信所需的路由。当不可信系统没有路由（可从可信系统发送或接收数据包）时，不可信系统不在测试范围内，不会影响该范围内的安全性组件。
如要实现网络分段，请将 CDE 置于启用了 VPC Service Controls 的专用 Virtual Private Cloud (VPC) 中。请在自定义模式中创建此 VPC，以确保不会创建任何可能会导致默认允许访问可信网络的无关子网或路由。实现组织政策限制条件，确保此 VPC 不能与其他项目共享，并且只能与其他可信网络进行对等互连。
下图显示了网络分段策略与资源层次结构之间的密切关系。此图假设的资源层次结构包含单个文件夹，用于范围内的 PCI 环境，该文件夹中有两个项目（CDE 和共享服务）。
在图 5 中，共享服务项目不是 CDE 的一部分，但它属于连接到系统，因此它属于 PCI 适用范围。负载均衡器和防火墙规则或防火墙政策在网络级层限制对 CDE 的访问，以保护这些网络并满足 PCI DSS 要求 1.2 和 1.3。令牌化系统和付款系统置于不同的子网中，并且其通信受每个子网之间的防火墙规则的约束，从而仅允许进行必要的通信。满足 PCI DSS 要求 10.2、10.4 和 10.5 的必要日志记录、监控和提醒功能存在于一个单独的项目中。共享服务和 CDE 位于 VPC Service Controls 安全边界内，以防止意外配置错误或 IAM 访问权限控制被破解。
如果您的部署在 Google Kubernetes Engine (GKE) 上，则以下是您可以用来细分 CDE 以及保护持卡人数据免受不可信系统影响的更多方式：
- 命名空间提供了额外的访问权限控制隔离层，因此用户只能访问 Kubernetes 集群中的特定 Pod、服务和部署。这对于向指定用户提供更精细的访问权限非常有用。
- 网络政策可以将 Pod 和服务彼此隔离，以限制数据流，并且可以在集群中提供额外的网络分段层。
- PodSecurity 是一个 Kubernetes 准入控制器，可让您向 GKE 集群上运行的 Pod 应用 Pod 安全标准。
每一层都是深度防御安全机制的重要组成部分，并通过进一步隔离和保护可信组件与周围环境来帮助缩小范围。如果您要使用 Kubernetes 部署全部或部分 CDE，请详细了解如何在 GKE 上运行符合 PCI 标准的环境。
实现令牌化
令牌化是不可逆转隐藏主账号 (PAN) 的过程。令牌化的 PAN 或令牌不能通过数学方法兑换 PAN。PCI SSC 在令牌化准则补充指南 (PDF) 的第 3 章中提供了有关令牌化范围影响的指导。PCI DSS 的范围在很大程度上取决于存储和传输持卡人数据的组件。正确实现后，令牌化可以帮助最大限度地减少主账号的出现和传输，帮助您缩小评估范围。
令牌化也是按数据流细分的一种形式，因为它会将存储和传输持卡人数据的系统与仅使用令牌即可执行操作的系统隔离开来。例如，分析消费者欺诈活动的系统可能不需要 PAN，但可以使用令牌化数据来执行这些分析。令牌化还增加了存储和传输 PAN 的系统与电子商务 Web 应用之间的分离层。如果您的 Web 应用仅与使用令牌的系统进行交互，则系统可能会从一组连接的系统中移除 Web 应用，从而缩小范围。
下图显示了在典型的令牌化系统中如何处理 CHD、PAN 和令牌化数据：
在图 6 中，先收到来自用户的 PAN 和其他持卡人数据，然后立即将数据发送到令牌化服务。令牌化服务会加密 PAN，生成令牌，然后将其存储在安全的令牌保险柜中。只有指定的服务（如结算服务）才能访问网络上的保险柜，并且有权使用生成的令牌兑换 PAN。结算服务仅使用 PAN 将其发送到付款处理方。在此严格流的数据流之外，PAN 和其他任何持卡人数据都不存在。作为纵深防御策略的一部分，该架构还使用 Sensitive Data Protection 作为另一层防御，防止 PAN 或其他持卡人数据意外泄露。
在图 6 中，标记化系统使用严格定义的密文存储区 Hashicorp Vault 管理 PAN 到令牌的映射。只有获得授权的用户和服务才能使用查找过程从令牌中兑换 PAN。可以向授予令牌保险柜授权的组件授予有时间限制的访问权限，以便组件仅在其执行其需要的特定时间范围内兑换 PAN。其他数据存储区也可能适合，具体取决于您的业务需求。
示例架构
下图展示了使用 Pub/Sub 和 Dataflow 处理令牌化事务以及在 Spanner 中存储令牌化事务记录的示例架构。
在图 7 中，事务处理项目是一个连接的系统，在 PCI 范围内。它不是安全受到影响的系统security-impacting，因为攻击者入侵事务处理项目中的任何组件后无法访问 CHD。webapp 项目在范围之外，因为它未连接到 CDE，并且仅与清理后的数据进行交互。
令牌化的数据会从 CDE 发送到 Pub/Sub。在将令牌化数据发布到其他订阅方之前，Sensitive Data Protection 会确认该数据不包含 CHD。令牌化的数据由 Dataflow 处理并存储在 Spanner 事务数据库中。无需访问 PAN，令牌便可通过令牌与特定用户相关联。Spanner 事务数据库还可用于商业智能 (BI) 工具（如 Looker）进行报告和分析。
支持持续的法规遵从性
安全性与合规性不仅仅在于正确的架构和良好的工程。正确的架构可以表明，您的环境在理论上安全地进行了设计。您还需要有效的审核、日志记录、监控和修复流程，以帮助确保您的环境始终处于安全状态。
为了支持遵守 12 个 PCI DSS 要求类别中的每一个要求，您必须持续监控相应要求的实现情况。您必须向自己和评估人员证明，范围内的任何组件在将来（完成 PCI DSS 评估后很长一段时间）仍保持安全状态。与快速修复操作配对的适当监控措施称为“持续合规性”。持续合规性是一项 PCI DSS 的要求，在正确实施的情况下，它有助于最大限度地提高其他缩小范围策略的效果。
借助 Google Cloud，您可以使用防火墙规则日志记录、VPC 流日志、VPC Service Controls 日志和 Cloud Load Balancing 日志来记录网络中发生的所有情况。您可以使用 Cloud Audit Logs 监控系统和用户的活动。定期监控这些日志可帮助您遵守 PCI DSS 要求 10.4，并可让您快速应对和解决潜在的安全威胁。如需了解详情，请参阅关于有效的每日日志监控的 PCI DSS 补充指南 (PDF)。
Security Command Center 提供资产清点、发现、搜索和管理功能，可帮助您了解您的安全状况和数据攻击面。Security Command Center 可以分析 Sensitive Data Protection 扫描结果，以帮助您发现泄露的持卡人数据，以及确认您的令牌化系统未被滥用于恶意兑换 PAN。使用 Event Threat Detection、Security Command Center 帮助您主动检测网络和虚拟机中的威胁和异常活动，这可能表明攻击者可能正在探测您的系统来识别防御能力。Security Command Center 还允许您创建特定于您环境的自定义安全来源。
Google Cloud Armor 可以为面向公共的 Google Cloud Web 应用提供额外的保护，并帮助您遵守 PCI DSS 要求 6.4。Google Cloud Armor 可评估各种常见 Web 攻击的传入请求，并可帮助您避免要求 6.4 中指定的耗费大量精力的人工代码审核。采用 WAF 可帮助您保持持续的合规性，同时降低持续的合规性费用和风险。
后续步骤
- 查看管理合规性义务的最佳实践。
- 阅读 Google Cloud 上的 PCI 数据安全标准合规性。
- PCI DSS 范围划分和网络分段的 PCI 委员会指导方针。
- 试用 GKE 蓝图上的 PCI。
- 保护 PCI DSS 的 Kubernetes 工作负载。
- 部署 PCI 入门版 Terraform 项目。
- 探索有关 Google Cloud 的参考架构、图表和最佳做法。查看我们的 Cloud 架构中心。