在 GKE 上确保遵从 PCI DSS 标准

Last reviewed 2023-10-31 UTC

本指南旨在帮助您解决在实施支付卡行业数据安全标准 (PCI DSS) 所要求的客户责任时，特定于 Google Kubernetes Engine (GKE) 应用的问题。

免责声明：本指南仅供参考。Google 在本指南中提供的信息或建议不构成法律或审核建议。每位客户都有责任独立评估其对该服务的具体使用是适当的，以履行法规遵从义务。

PCI DSS 合规性和 GKE 简介

在处理支付卡数据时，无论该数据是位于本地数据库还是云端，您都必须确保数据的安全。PCI DSS 的制定是为了支持和增强持卡人数据的安全性，并促进全球广泛采用一致的数据安全措施。PCI DSS 提供了旨在保护信用卡数据的技术和运营要求基准。PCI DSS 适用于涉及支付卡处理的所有实体，包括商家、处理方、收单机构、发卡机构和服务提供商。此外，PCI DSS 还适用于存储、处理或传输持卡人数据 (CHD) 和/或敏感身份验证数据 (SAD) 的其他所有实体。

近来容器化应用十分普遍，很多旧版工作负载都已从基于虚拟机 (VM) 的架构迁移到容器化架构。Google Kubernetes Engine 是一个可立即投产的托管式环境，用于部署容器化应用。它融合了 Google 在提高开发效率、有效利用资源、自动化运营和开源灵活性等方面的最新创新成果，能够让您更快进入市场。

合规性是云端服务需共同承担的责任。Google Cloud，包括 GKE（Autopilot 和 Standard 操作模式）遵循 PCI DSS 要求。我们在共担责任表中概述了我们的责任。

目标受众

  • 想要将符合 PCI 标准的 GKE 工作负载迁移到 Google Cloud 的客户。
  • 开发者、安全人员、合规专员、IT 管理员以及其他负责实施控制机制并确保遵从 PCI DSS 要求的员工。

准备工作

对于下文中的建议，您可能需要使用以下各项：

  • Google Cloud 组织、文件夹和项目资源
  • Identity and Access Management (IAM)
  • Google Kubernetes Engine
  • Google Cloud VPC
  • Google Cloud Armor
  • Cloud Data Loss Prevention API（属于 Sensitive Data Protection）
  • Identity-Aware Proxy (IAP)
  • Security Command Center

本指南适合熟悉容器和 GKE 的人员。

范围

本指南指出了 PCI DSS 中特别需要 GKE 加以关注的下列要求，并提供了有关如何满足这些要求的指导。本指南是针对 PCI DSS 标准的 4.0 版编写的。并未涵盖 PCI DSS 中的所有要求。 本指南中提供的信息可能有助于组织满足 PCI DSS 合规性要求，但这并不是全面的建议。组织可以聘请 PCI 有资质的安全评估方 (QSA) 进行正式验证。

PCI DSS 目标 PCI DSS 要求
分割您的持卡人数据环境 有时称为要求 0。尽管这并非确保 PCI 合规性的必要条件，但我们建议您遵守这项要求以限制 PCI 适用范围。
构建并维护安全的网络和系统 1. 安装并维护网络安全控制机制

2. 将安全配置应用于所有系统组件
保护账号数据 3. 保护存储的账号数据

4. 在通过开放式公共网络传输时，使用强效加密法保护持卡人数据
维护漏洞管理计划 5. 保护所有系统和网络免受恶意软件的侵害

6. 开发安全的系统和软件并加以维护
实施健全的访问权限控制措施 7. 按业务知情需要限制对系统组件和持卡人数据的访问

8. 识别对系统组件的访问并进行身份验证

9. 限制对持卡人数据的物理访问
定期监控和测试网络 10. 记录和监控对系统组件和持卡人数据的所有访问

11. 定期测试系统和网络的安全性
维护信息安全政策 12. 通过组织政策和计划支持信息安全

术语

本部分定义了本指南中用到的一些术语。如需了解详情，请参阅 PCI DSS 术语库。

CHD

cardholder data（持卡人数据）。至少会包含完整的主账号 (PAN)。持卡人数据的形式也可能是完整的 PAN 加上以下任意信息：

  • 持卡人姓名
  • 到期日期和/或服务代码
  • 敏感身份验证数据 (SAD)
CDE

cardholder data environment（持卡人数据环境）。存储、处理或传输持卡人数据或敏感身份验证数据的人员、流程和技术。

PAN

primary account number（主账号）。为符合 PCI DSS 要求，您有义务保护的关键持卡人数据。PAN 通常为支付卡（信用卡和借记卡）专属的 16 位数字，可用来识别发卡机构和持卡人账号。

PIN 码

personal identification number（个人身份号码）。只有用户和系统知道的数字密码；用于向系统验证用户身份。

QSA

qualified security assessor（合格安全评估者）。经 PCI 安全标准委员会认证，可执行审核与合规性分析的人员。

SAD

sensitive authentication data（敏感身份验证数据）。在 PCI 合规性中，发卡机构用于授权交易的数据。与持卡人数据类似，PCI DSS 也要求保护 SAD。此外，商家及其付款处理方不得保留 SAD。SAD 包括以下内容：

  • 来自磁条的“跟踪”数据
  • 由芯片和感应式卡片产生的“等同跟踪的数据”
  • 用于在线交易和无卡交易的安全验证码（例如，印在卡片上的 3 至 4 位数字）。
  • PIN 码和 PIN 码块
分割

在 PCI DSS 中，将 CDE 与实体网络的其余部分相隔离的做法。分割并非 PCI DSS 的要求，但我们仍强烈建议您使用，因为这一做法有以下好处：

  • 降低 PCI DSS 评估的适用范围和成本
  • 降低实施和维护 PCI DSS 控制机制的成本和难度
  • 将持卡人数据整合到更少且更受控制的位置，进而降低组织所面临的风险

分割您的持卡人数据环境

持卡人数据环境 (CDE) 包括存储、处理或传输持卡人数据或敏感身份验证数据的人员、流程及技术。在 GKE 环境中，CDE 还包含以下内容：

  • 提供安全服务的系统（例如，IAM）。
  • 有助于实现分割的系统（例如项目、文件夹、防火墙、Virtual Private Cloud (VPC) 和子网）。
  • 存储、处理或传输持卡人数据的应用 pod 和集群。如果没有进行充分的分割，您的整个云空间可能都会属于 PCI DSS 的适用范围。

为了让某个系统组件不被视为在 PCI DSS 的适用范围内，必须将该系统组件与 CDE 进行适当隔离，这样，即使适用范围外的系统组件遭到破坏，CDE 的安全性也不会受到影响。

如需缩减 CDE 的适用范围，一个重要前提是要先明确了解与持卡人数据的存储、处理和传输相关的业务需求及流程。若要通过消除不必要的数据并整合必要的数据，将持卡人数据限制在尽可能少的位置，您可能需要重新设计长期实施的业务做法。

您可以通过许多方式在 Google Cloud 上对 CDE 进行适当分割。本部分探讨了以下方式：

  • 使用资源层次结构进行逻辑分割
  • 使用 VPC 和子网进行网络分割
  • 使用 VPC 进行服务级层分割
  • 针对适用范围内集群的其他考虑因素

使用资源层次结构进行逻辑分割

您可以通过多种方式，使用 Google Cloud 的资源层次结构在自己的组织结构中实现 CDE 隔离。Google Cloud 资源以分层方式进行组织。组织资源是 Google Cloud 资源层次结构的根节点。文件夹和项目属于组织资源。文件夹可以包含项目和文件夹。文件夹可用于通过文件夹级层 IAM 权限控制对文件夹层次结构中资源的访问权限，还可用于将类似项目进行分组。项目是所有资源和 IAM 强制执行点的信任边界。

您可以将 PCI 适用范围内的所有项目归入一个文件夹中，进而在文件夹级层实现隔离。您也可以为适用范围内的所有 PCI 集群和应用使用一个项目，或者为适用范围内的每个 PCI 应用各创建一个项目和集群，并使用它们来组织您的 Google Cloud 资源。任何情况下，我们都建议您将适用范围内与适用范围外的工作负载布置在不同的项目中。

使用 VPC 网络和子网进行网络分割

您可以使用虚拟私有云 (VPC) 和子网来预配网络以及对 CDE 相关资源进行分组和隔离。VPC 是采用逻辑隔离方式的公有云区段。VPC 网络可为 Compute Engine 虚拟机实例以及利用虚拟机实例的服务（包括 GKE）提供可扩缩的灵活网络。如需了解详情，请参阅 VPC 概览以及最佳做法和参考架构。

使用 VPC Service Controls 和 Google Cloud Armor 进行服务级层分割

VPC 和子网可提供隔离 CDE 所需的分割与边界创建功能，而 VPC Service Controls 则能增强第 7 层的安全边界。您可以使用 VPC Service Controls 为适用范围内的 CDE 项目创建边界。VPC Service Controls 可为您提供以下控制机制：

  • 入站流量控制。只有已获授权的身份和客户端才能进入您的安全边界。
  • 出站流量控制。仅允许您安全边界内的身份和客户端使用已获授权的目的地。

您可以使用 Google Cloud Armor 创建 IP 地址列表，以在 Google Cloud 网络的边缘允许或拒绝 IP 地址对 HTTP(S) 负载均衡器的访问。在尽量靠近用户和恶意流量的位置检查 IP 地址，有助于防止恶意流量消耗资源或进入您的 VPC 网络。

使用 VPC Service Controls 为您的适用范围内项目定义服务边界。此边界可控制虚拟机与服务之间的路径、服务与服务之间的路径以及 VPC 入站和出站流量。

图 1. 使用 VPC Service Controls 实现分割。
图 1：使用 VPC Service Controls 实现分割

构建并维护安全的网络和系统

构建并维护安全网络涉及 PCI DSS 的要求 1 和 2。

要求 1

安装并维护防火墙配置，以保护持卡人数据以及进出 CDE 的流量。

容器和 GKE 的网络概念与传统虚拟机的网络概念不同。Pod 无需 NAT 即可彼此直接连接，甚至可以跨节点连接。因此，您可以创建简单的网络拓扑；如果您熟悉复杂系统的管理过程，可能会对此感到惊讶。GKE 网络安全的第一步是了解这些网络概念。

安全 Kubernetes 集群的逻辑布局。
图 2：安全 Kubernetes 集群的逻辑布局

在深入了解“要求 1”中的各项要求之前，您可能需要查看以下与 GKE 相关的网络概念：

  • 防火墙规则。防火墙规则用于限制传入您的节点的流量。GKE 节点已预配为 Compute Engine 实例，并使用与其他实例相同的防火墙机制。您可以在网络中使用标记将这些防火墙规则应用于每个实例。每个节点池都会收到一组可在规则中使用的标记。默认情况下，节点池中的每个实例都会收到一个标记，该标记标识此节点池所属的特定 GKE 集群，且适用于 GKE 自动为您创建的防火墙规则。您可以使用 Google Cloud CLI 中的 --tags 标志在创建集群或节点池时添加自定义标记。

  • 网络政策。网络政策可让您限制 Pod 之间的网络连接，以便防止集群在 Pod 出现安全问题时发生网络跳板攻击和横向移动。如要使用网络政策，您必须在创建 GKE 集群时明确启用该功能。您可以对现有集群启用该功能，但这会导致您的集群节点重启。默认情况下，所有 Pod 间通信都是开放的。因此，如果您想要对网络进行分割，则需要执行 pod 级层网络政策。在 GKE 中，您可以使用 Kubernetes Network Policy API 或使用 kubectl 工具来定义网络政策。这些 pod 级层流量政策规则决定了集群内的哪些 pod 和服务可以相互访问。

  • 命名空间。命名空间支持在 Kubernetes 集群内进行资源分割。Kubernetes 具有开箱即用的默认命名空间，但您可以在集群内创建多个命名空间。各命名空间在逻辑上彼此隔离，分别用于为集群中的 pod、服务和部署限定特定范围，因此与某一命名空间进行互动的用户将看不到其他命名空间中的内容。不过，若命名空间位于同一集群，命名空间之间的通信将不受限制；这时网络政策就可以派上用场。如需详细了解如何配置命名空间，请参阅命名空间最佳做法博文。

下图说明了前述概念彼此之间的关系，以及它们与其他 GKE 组件（如集群、节点和 pod）之间的关系。

控制集群内部流量的 Kubernetes 网络政策。
图 3：控制集群内部流量的 Kubernetes 网络政策

要求 1.1

我们已定义并理解安装和维护网络安全控制的流程和机制。

要求 1.1.2

说明网络组件管理群组、角色与责任。

首先，就像 Google Cloud 上的大多数服务一样，您需要配置 IAM 角色才能在 GKE 上设置授权。设置 IAM 角色后，您需要在 Kubernetes 授权策略中添加 Kubernetes 基于角色的访问控制 (RBAC) 配置。

所有 IAM 配置基本都适用于项目中的所有 Google Cloud 资源和所有集群。Kubernetes RBAC 配置适用于每个 Kubernetes 集群中的资源，并在命名空间级层提供精细的授权机制。在 GKE 中，这些授权方式可以并行运作，且用户的权限可有效表示分配给他们的 IAM 和 RBAC 角色的集合：

  • 使用 IAM 控制群组、角色和责任，以对 GKE 中的网络组件进行逻辑管理。
  • 使用 Kubernetes RBAC 对 Kubernetes 集群中的网络政策授予精细权限，以控制 Pod 之间的流量，并防止非 CDE 用户进行未经授权或意外的变更。
  • 能够为所有 IAM 和 RBAC 用户及权限提供正当理由。通常情况下，当 QSA 测试控制机制时，他们会选择部分 IAM 和 RBAC 用户作为样本，然后查看这些样本是否有正当的业务理由。

要求 1.2

配置和维护网络安全控制 (NSC)。

首先，在运行 GKE 节点的 Compute Engine 实例上配置防火墙规则。防火墙规则可为这些集群节点提供保护。

接下来，您需要配置网络政策，以限制流量并保护集群中的 Pod。网络政策指定 Pod 群组可以如何与彼此及其他网络端点进行通信。您可以使用 GKE 的网络政策实施功能来控制集群的 pod 和服务之间的通信。如需进一步分割您的集群，请在其中创建多个命名空间。各命名空间在逻辑上彼此隔离，分别用于为集群中的 pod、服务和部署限定特定范围，因此与某一命名空间进行互动的用户将看不到其他命名空间中的内容。不过，若命名空间位于同一集群，命名空间之间的通信将不受限制；这时网络政策就可以派上用场。命名空间支持在 Kubernetes 集群内进行资源分割。如需详细了解如何配置命名空间，请参阅命名空间最佳做法博文。

默认情况下，如果命名空间中不存在任何政策，系统就会允许进出该命名空间中 pod 的所有入站和出站流量。例如，您可以通过创建一项选择所有 pod 但不允许这些 pod 的入站流量的网络政策，为命名空间创建默认隔离政策。

要求 1.2.2

对网络连接和 NSC 配置的所有更改均根据要求 6.5.1 中定义的变更控制流程获得批准和管理。

若要以代码的形式处理网络配置和基础架构，您需要建立持续集成和持续交付 (CI/CD) 流水线，并将其作为变更管理和变更控制流程的一部分。

您可以在 CI/CD 流水线中使用 Cloud Deployment Manager 或 Terraform 模板，以便在集群上创建网络政策。借助 Deployment Manager 或 Terraform，您可以代码形式处理配置和基础架构，进而生成与当前生产环境或其他环境一致的副本。之后，您可以编写单元测试和其他测试，确保您的网络变更发挥预期的效果。控制变更的流程若包含审批环节，可以通过存储在版本存储库中的配置文件进行管理。

您可以使用 Terraform Config Validator 来定义强制执行安全和管理政策的限制条件。在 CI/CD 流水线中添加 Config Validator 后，您便可为任意工作流添加一个步骤，此步骤用于验证 Terraform 方案，并在发现违规情况时加以拒绝。

要求 1.2.5

允许的所有服务、协议和端口均已确定且获得批准，并且具有确定的业务需求。

为了对 GKE 集群执行强有力的入站流量控制机制，您可以使用授权网络来限制能够连接到您集群控制平面的某些 IP 地址范围。GKE 使用传输层安全协议 (TLS) 和身份验证机制来提供从公共互联网对集群主实例端点的安全访问。此访问方式可让您灵活选择从哪个位置来管理集群。您可以通过授权网络进一步将访问限制到一组指定 IP 地址。

您可以使用 Google Cloud Armor 为 GKE 托管的应用创建 IP 地址拒绝列表和允许列表以及安全政策。在 GKE 集群中，传入流量由 HTTP(S) 负载均衡服务处理，该服务是 Cloud Load Balancing 的一个组件。通常 HTTP(S) 负载均衡器由 GKE 入站流量控制器配置，该控制器从 Kubernetes Ingress 对象获取配置信息。如需了解详情，请参阅如何使用 GKE 配置 Google Cloud Armor 政策。

要求 1.3

进出持卡人数据环境的网络访问受到限制。

为了使敏感数据保持私密状态，您可以使用 VPC Service Controls 和专用 Google 访问通道，在 VPC 网络中的 GKE 集群与本地混合部署之间配置专用通信。

要求 1.3.1

流向 CDE 的入站流量的限制如下：

  • 仅访问必要的流量。
  • 所有其他流量都会被明确拒绝。

请考虑使用 GKE 实施 Cloud NAT 设置，以仅向该集群发送入站互联网流量。您可以为 CDE 中的非公开集群设置专用集群。在专用集群中，节点仅具有内部 RFC 1918 IP 地址，这可确保节点的工作负载与公共互联网隔离开来。

要求 1.4

受信任和不受信任的网络之间的网络连接是受控的。

您可以使用要求 1.3 中列出的相同方法来满足此要求。

要求 1.4.3

实施了反欺骗措施，以检测假冒来源 IP 地址并阻止其进入可信网络。

您可以在 GKE pod 和集群上使用别名 IP 地址来实施反欺骗措施，以检测假冒来源 IP 地址并阻止其进入网络。使用别名 IP 地址范围的集群称为“VPC 原生集群”。

要求 1.4.5

只有获得授权的各方才能披露内部 IP 地址和路由信息。

您可以使用 GKE IP 伪装代理进行网络地址转换 (NAT)，以对集群进行多对一 IP 地址转换。伪装功能可将多个来源 IP 地址隐藏在单个地址后方。

要求 2

将安全配置应用于所有系统组件。

要求 2 指定了如何通过移除默认设置和供应商提供的凭据来强化安全参数。强化集群的安全是客户的责任。

要求 2.2

系统组件可以安全配置和管理。

确保这些标准可解决所有已知的安全漏洞，并与行业认可的系统安全强化标准一致。行业认可的系统安全强化标准来源包括但不限于：

要求 2.2.4

仅启用必要的服务、协议、守护进程和函数，并且移除或停用所有不必要的功能。

要求 2.2.5

如果存在任何不安全的服务、协议或守护程序：
  • 已记录业务理由。
  • 系统会记录并实现其他安全功能，以降低使用不安全服务、协议或守护程序的风险。

要求 2.2.6

系统安全参数配置为防止滥用。

预部署工作

在将容器迁移至 GKE 之前，我们建议您采取下列做法：

  • 从容器托管的基础映像入手，该映像需由受信任来源构建、维护及进行安全漏洞检查。建议创建一组“已知良好”或“最佳”基础映像供开发者使用。如需选择限制性更强的方式，可以使用 distroless 映像或暂存基础映像。
  • 使用 Artifact Analysis 扫描容器映像是否存在漏洞。
  • 建立内部 DevOps/SecOps 政策，仅将已获批准的可信任库和二进制文件纳入容器中。

设置工作

在设置过程中，我们建议您采取下列做法：

  • 使用默认的 Container-Optimized OS 作为 GKE 的节点映像。Container-Optimized OS 是以 Chromium OS 为基础，且已针对节点安全性进行了优化。
  • 为运行应用的集群启用自动升级节点功能。此功能会自动将节点升级为在托管控制平面中运行的 Kubernetes 版本，进而提高稳定性和安全性。
  • 启用自动修复节点功能。启用此功能后，GKE 会定期检查节点的运行状况并使用此信息来确定节点是否需要进行修复。如果某个节点需要进行修复，系统会将该节点排空，然后再创建新的节点并将该新节点添加到集群中。
  • 启用 Cloud Monitoring 和 Cloud Logging 功能以查看所有事件，包括安全事件和节点运行状况。创建 Cloud Monitoring 提醒政策，以便在出现安全突发事件时获取通知。
  • 为 GKE 节点应用最小权限服务账号
  • 查看 Google Cloud CIS 基准指南中的 GKE 部分，并视情况应用。默认情况下，Kubernetes 审核日志记录功能会启用，且向 kubectl 和 GKE API 发出的请求的相关日志均会写入 Cloud Audit Logs。
  • 配置审核日志记录功能。

保护账号数据

保护持卡人数据涉及 PCI DSS 的要求 3 和 4。

要求 3

保护存储的账号数据。

PCI DSS 的要求 3 规定，保护技术（例如加密、截断、遮盖和哈希）是持卡人数据保护机制的关键组成部分。如果入侵者绕过其他安全控制机制并取得加密数据的访问权限，那么在没有适当加密密钥的情况下，入侵者将无法读取和使用该数据。

您还可以考虑采用其他方法来保护存储的数据，以缓解潜在的风险。举例来说，将风险降至最低的方法包括：除非绝对必要，否则不存储持卡人数据；如果不需要完整的 PAN，则截断持卡人数据；不使用最终用户消息传递技术（例如电子邮件和即时消息）发送不受保护的 PAN。

在 GCP 上运行时，CHD 可能会因为是付款处理流程的一部分而持续存在于系统中，这些系统包括：

  • Cloud Storage 存储桶
  • BigQuery 实例
  • Datastore
  • Cloud SQL

请注意，CHD 可能会意外存储在电子邮件或客户服务通信日志中。明智的做法是使用 Sensitive Data Protection 来过滤这些数据流，以便将范围内的环境限制为付款处理系统。

请注意，在 Google Cloud 上，数据默认在存储时进行静态加密，并默认在经过物理边界时进行传输加密。您无需进行额外的配置即可启用这些保护措施。

要求 3.5

无论在何处存储，主账号 (PAN) 都安全无虞。

如需使 PAN 数据不可读，一种机制是令牌化。如需详细了解令牌化，请参阅限制 Google Cloud 中 PCI 环境的合规性范围。

您可以使用 DLP API 扫描、发现和报告持卡人数据。Sensitive Data Protection 原生支持对 Cloud Storage、BigQuery 和 Datastore 中的 12 至 19 位数的 PAN 数据进行扫描与分类，还提供了一个数据流内容 API，以便为额外的数据源、自定义工作负载和应用提供支持。您还可以使用 DLP API 对数据进行截断（遮盖）或哈希处理。

要求 3.6

用于保护存储的账号数据的加密密钥受到保护。

Cloud Key Management Service (KMS) 是托管式加密密钥存储系统。此系统可以生成、使用、轮替和销毁加密密钥。虽然 Cloud KMS 不会直接存储 Secret（例如持卡人数据），但它可用于加密此类数据。

Kubernetes 环境中的 Secret 对象可让您存储和管理敏感信息（如密码、令牌和密钥）。

默认情况下，Google Cloud 会对以静态方式存储的客户内容进行加密。GKE 为您处理和管理此默认加密，您无需执行任何额外的操作。应用层 Secret 加密为敏感数据（如 Secret）提供了额外一层安全防护。通过此功能，您可以提供您在 Cloud KMS 中管理的密钥来加密应用层数据，借此防范攻击者对您集群的 Kubernetes 配置存储实例副本进行访问。

GKE 应用层 Secret。
图 4：GKE 应用层 Secret

要求 4

在通过开放式公共网络传输时，使用强效加密法保护持卡人数据。

适用范围内的数据在通过容易遭恶意个人访问的网络（例如公共网络）进行传输时必须加密。

Istio 是一种开源服务网格，可透明地部署到现有的分布式应用中。Istio 以可扩缩的方式管理微服务间流量的身份验证、授权和加密。该平台包含的 API 可让您将数据整合到任何日志记录平台、遥测或政策系统中。Istio 的功能组合可让您高效地运行分布式微服务架构，并提供统一的方式来保护、连接和监控微服务。

要求 4.1

我们定义并记录了在通过开放式公共网络传输期间使用强效加密法保护持卡人数据的流程和机制。

您可以使用 Istio 来为部署的服务创建网络，其中包括负载均衡、服务到服务身份验证以及监控。您还可以使用 Istio 在集群中提供安全的服务间通信，并在该通信中使用以双向 TLS 为基础的高强度身份验证及授权机制。双向 TLS (mTLS) 会执行两次 TLS 握手，以双向建立相同的信任级层（与客户端和服务器之间的单向信任不同）。

使用 Istio 和 mTLS 保护服务间通信。
图 5：使用 Istio 和 mTLS 保护服务间通信

通过 Istio，您可以将 TLS 证书部署到应用内的每个 GKE pod。在 pod 上运行的服务可以使用 mTLS 明显地识别其对等身份。服务间通信是通过客户端和服务器端的 Envoy 代理建立传送隧道的。Envoy 使用 SPIFFE ID 在服务之间建立 mTLS 连接。如需了解如何在 GKE 上部署 Istio，请参阅 GKE 文档。如需了解支持的 TLS 版本，请参阅 Istio 流量管理参考文档。使用 TLS 1.2 及更高版本。

如果您的应用已在互联网上公开，请使用 GKE HTTP(S) 负载均衡，并将入站流量路由设为使用 HTTP(S)。由 Ingress 对象配置的 HTTP(S) 负载均衡具有以下特性：

  • 灵活的服务配置。Ingress 对象定义了流量如何到达您的服务，以及流量如何路由到您的应用。此外，Ingress 对象还可为集群中的多项服务提供单个 IP 地址。
  • 与 Google Cloud 网络服务集成。Ingress 对象可以配置 Google Cloud 功能，例如 Google 管理的 SSL 证书（Beta 版）、Google Cloud Armor、Cloud CDN、Identity-Aware Proxy。
  • 支持多个 TLS 证书。Ingress 对象可以指定使用多个 TLS 证书来终止请求。

当您创建 Ingress 对象时，GKE 入站流量控制器会根据 Ingress 中的信息及其关联的 Service 创建 Cloud HTTP(S) 负载均衡器并对其进行配置。

维护漏洞管理计划

维护漏洞管理计划涉及 PCI DSS 的要求 5 和 6。

要求 5

保护所有系统和网络免受恶意软件的侵害。

PCI DSS 的要求 5 规定，必须在所有经常受恶意软件影响的系统上使用杀毒软件，以保护系统免受现有及不断演变的恶意软件威胁（容器也必须照此要求处理）。

要求 5.2

系统会阻止或检测并解决恶意软件。

您必须为容器映像实施漏洞管理计划。

我们建议您执行以下操作：

  • 定期检查容器并对其应用最新的安全补丁程序。
  • 定期对容器化应用和二进制文件/库执行漏洞扫描。
  • 在构建流水线中扫描映像。
  • 订阅漏洞情报服务，以接收与容器中使用的环境和库相关的最新漏洞信息。

Google Cloud 与各种容器安全解决方案提供商携手合作，改善客户 Google Cloud 部署中的安全状况。我们建议您利用经验证的安全解决方案和技术来提高 GKE 环境中的防御深度。如需了解通过 Google Cloud 验证的最新安全合作伙伴列表，请参阅安全合作伙伴。

要求 5.2.2

已部署的反恶意软件解决方案：

  • 检测所有已知类型的恶意软件。
  • 移除、阻止或包含所有已知类型的恶意软件。

要求 5.2.3

系统会定期评估任何没有受到恶意软件风险的系统组件，以包括以下各项：

  • 不存在受恶意软件风险的所有系统组件的记录列表。
  • 识别和评估这些系统组件不断演变的恶意软件威胁。
  • 确认此类系统组件是否继续不需要反恶意软件保护。

有许多可用于执行恶意软件扫描的解决方案，但 PCI DSS 了解并非所有系统都同样容易受到攻击。商家通常会宣称自己的 Linux 服务器、大型机和类似机器并非“经常受恶意软件影响”，因此不受 5.2.2 要求的约束。在这种情况下，要求 5.2.3 即适用，您需要实施一个定期评估威胁的系统。

请注意，这些规则对于 GKE 集群内的节点和 pod 都适用。

要求 5.3

反恶意软件机制和进程处于活跃、维护和监控状态。

要求 5.2、5.3 和 11.5 规定，适用范围内的主机都需进行防病毒扫描和文件完整性监控 (FIM)。我们建议实施扫描解决方案，确保所有节点均可由集群内受信任的代理进行扫描，或每个节点都有可报告至单一管理端点的扫描程序。

如需了解详情，请参阅 GKE 的安全概览和 Container-Optimized OS 的安全概览。

针对防病毒和 FIM 要求的常见解决方案是将您的容器锁定，以便仅允许特定文件夹具有写入权限。为此，您需要以非根用户身份运行容器，并使用文件系统权限来阻止对容器文件系统中工作目录以外的所有项进行的写入。禁止提升权限，以免规避文件系统规则。

要求 6

开发安全的系统和软件并加以维护。

PCI DSS 的要求 6 规定，须建立健全的软件开发生命周期，并在软件开发的每一环节中构建安全机制。

要求 6.2

定制软件和自定义软件是安全开发的。

要求 6.2.1

定制软件和自定义软件是安全开发的，如下所示：

  • 基于安全开发的业界标准和/或最佳做法。
  • 遵循 PCI DSS（例如安全身份验证和日志记录）。
  • 在软件开发生命周期的每个阶段考虑信息安全问题。

您可以借助 Binary Authorization 来确保只有受信任的容器会部署到 GKE。如果您只想启用由一个或多个特定证明者授权的映像，可以配置 Binary Authorization 以强制执行政策，并制定根据漏洞扫描结果进行证明的规则。您还可以编写政策，要求映像必须在获得一个或多个可信任方（称为“证明者”）的批准后才能进行部署。对于多阶段部署流水线（其中映像会经历开发、测试和生产集群等阶段），您可以使用证明者来确保软件在进入下一阶段之前已完成所有必需的流程。

在部署时，Binary Authorization 会检查容器映像是否已通过所有必需的限制，借此实施您的政策；这些限制包括所有必要的证明者均已验证映像可进行部署。如果映像通过检查，则该服务会允许其部署作业。否则，部署作业会遭到阻止，且映像必须在达到合规状态之后才能进行部署。

使用 Binary Authorization 实施仅允许将受信任映像应用于 GKE 集群的政策。
图 6：使用 Binary Authorization 实施仅允许将受信任映像应用于 GKE 集群的政策

如需详细了解 Binary Authorization，请参阅为 GKE 设置。

在紧急情况下，您可以使用 Breakglass 工作流绕过 Binary Authorization 政策。所有 Breakglass 事件都将记录在 Cloud Audit Logs 中。

GKE Sandbox 可降低容器与主机直接交互的需求，缩减主机被侵时的攻击面，并能限制恶意操作者的行动。

要求 6.3

发现并解决安全漏洞。

要求 6.3.1

安全漏洞的识别和管理如下所示：

  • 我们使用业界认可的安全漏洞信息来源（包括来自国际和国家计算机应急响应团队 [CERT] 的提醒）来识别新的安全漏洞。
  • 根据行业最佳做法以及对潜在影响的考虑，为漏洞分配风险等级。
  • 风险排名至少识别所有被认为对环境具有高风险或关键风险的漏洞。
  • 专门介绍了定制软件和自定义软件以及第三方软件（例如操作系统和数据库）的漏洞。

云端安全性是云服务商与客户共担的责任。

在 GKE 中，Google 负责管理控制平面，其中包括主虚拟机、API 服务器、在这些虚拟机上运行的其他组件，以及 etcd 数据库。Google 会对它们进行升级、修补、扩缩和修复，一切均由服务等级目标 (SLO) 提供支持。对于节点的操作系统（例如 Container-Optimized OS 或 Ubuntu），GKE 会及时为这些映像提供补丁程序。如果您启用了自动升级功能，系统会自动部署这些补丁程序（此为容器的基础层，与容器中运行的操作系统不同）。

如需详细了解 GKE 的共担责任模型，请参阅探索容器安全：GKE 中的共担责任模型。

Google 提供了多项安全服务，可帮助您在 CI/CD 流水线中构建安全机制。您可以使用 Google Artifact Analysis 漏洞扫描功能识别容器映像中的漏洞。将容器映像推送到 Google Container Registry (GCR) 时，漏洞扫描功能会自动扫描映像，由此发现来自已知 CVE 来源的已知漏洞和威胁。系统会根据 CVSS 分数，为漏洞指定严重级别（严重、高、中、低和极小）。

要求 6.4

面向公众的 Web 应用可以抵御攻击。

对于公开的 App Engine、Compute Engine 和 GKE Web 应用，您可以使用 Web Security Scanner 扫描发现从跨站脚本攻击和错误配置到易受攻击的资源等常见漏洞。您可以按需执行扫描，并且可以通过 Google Cloud 控制台安排扫描。借助 Security Scanner API，您可以在应用构建流水线中将扫描自动化，使其成为安全测试套件的一部分。

实施健全的访问权限控制措施

实施健全的访问权限控制措施涉及 PCI DSS 的要求 7、8 和 9。

要求 7

按业务知情需要限制对系统组件和持卡人数据的访问。

要求 7 侧重于“最小权限”或“知情需要”的部分。PCI DSS 将这些部分定义为授予最少数据的访问权限，并提供执行作业所需的最小权限。

要求 7.2

适当地定义和分配对系统组件和数据的访问权限。

使用 IAM 和 RBAC 提供多层安全防护。
图 7：使用 IAM 和 RBAC 提供多层安全防护

IAM 与 Kubernetes 基于角色的访问控制 (RBAC) 可以协同运作，为您的 GKE 环境提供精细的访问权限控制机制。IAM 用于管理 CDE 项目中的用户访问权限和 Google Cloud 资源权限。在 GKE 中，您还可以使用 IAM 管理用户和服务账号在您集群中的访问权限，以及可以执行的操作（例如创建和删除集群）。

借助 Kubernetes RBAC，您可以配置细化的权限组，以定义指定 Google Cloud 用户、Google Cloud 服务账号或用户群组（Google 群组）如何与集群或集群特定命名空间中的任何 Kubernetes 对象进行互动。RBAC 权限的示例包括修改部署或 ConfigMap、删除 pod 或查看 pod 的日志。您可以向用户或服务授予有限的 IAM 权限（例如 Google Kubernetes Engine Cluster Viewer 或自定义角色），然后视情况应用 Kubernetes RBAC RoleBinding。

在 GKE 上，Cloud Identity Aware Proxy (IAP) 通过 Ingress 集成，可让您控制员工或需要访问您 PCI 应用的人员的应用级访问权限。

此外，您还可以使用组织政策来限制项目中可用的 API 和服务。

要求 7.2.2

系统会基于以下因素向用户（包括特权用户）分配访问权限：

  • 作业分类和功能。
  • 执行作业职责所需的最小权限。

除了确保用户和服务账号遵守最小权限原则外，容器也应照此处理。运行容器的最佳做法是使用非根用户身份运行进程。您可以通过使用 PodSecurity 准入控制器来实现并强制实施这一实践。

PodSecurity 是一个 Kubernetes 准入控制器，允许您向 GKE 集群上运行的 Pod 应用 Pod 安全标准。Pod 安全标准是预定义的安全政策，涵盖 Kubernetes 中 Pod 安全性的高层次需求。这些政策的范围各有不同，从高度宽松到高度严格。PodSecurity 取代了 Kubernetes v1.25 中已移除的旧 PodSecurityPolicy 准入控制器。相关说明适用于从 PodSecurityPolicy 迁移到 PodSecurity 准入控制器。

要求 8

识别用户的身份并对系统组件的访问权限进行身份验证

要求 8 规定，必须为有权访问适用范围内 PCI 系统的每个用户分配唯一 ID，以确保每个人独立负责自己的操作。

要求 8.2

用户和管理员的用户识别及相关账号在账号的整个生命周期内受到严格管理。

要求 8.2.1

在允许访问系统组件或持卡人数据之前，系统会为所有用户分配唯一 ID。

要求 8.2.5

已终止用户的访问权限会立即撤消。

IAM 和 Kubernetes RBAC 均可用于控制对 GKE 集群的访问权限；您也可以使用这两种方式为用户授予权限。我们建议将用户绑定至您现有的身份系统，以便在同一个位置管理用户账号和政策。

要求 8.3

可为用户和管理员建立和管理强大的身份验证机制。

要求 8.3.1

对用户和管理员的系统组件的所有用户访问都至少通过以下身份验证因素之一进行身份验证：
  • 用户所知，如密码或口令。
  • 用户所有，如令牌设备或智能卡。
  • 个人特征，如生物元素。

在用户向 kubectl 进行身份验证时，证书就会绑定到用户的身份。通过验证凭据并检索与 Google Cloud 用户或服务账号身份关联的电子邮件地址，所有 GKE 集群都配置为接受该用户或服务账号身份。因此，这些账号的凭据必须包含 userinfo.email OAuth 范围才能成功进行身份验证。

要求 9

限制对持卡人数据的物理访问。

Google 负责 Google Cloud 的所有底层 Google 数据中心的物理安全控制机制。

定期监控和测试网络

定期监控和测试网络涉及 PCI DSS 的要求 10 和 11。

要求 10

记录和监控对系统组件和持卡人数据的所有访问。

要求 10.2

审核日志是为了支持检测异常情况和可疑活动以及对事件进行取证分析。

默认情况下，Kubernetes 集群会启用 Kubernetes 审核日志记录功能，并按时间顺序记录已对 Kubernetes API 服务器进行的调用。Kubernetes 审核日志条目适合用于调查可疑 API 请求、收集统计信息，或针对不当 API 调用创建监控提醒。

GKE 集群整合了 GKE 审核日志记录功能的默认配置以及 Cloud Audit Logs 和 Logging 功能。您可以在自己的 Google Cloud 项目中查看 Kubernetes 审核日志条目。

项目的审核日志不止包含 Kubernetes 写入的条目，还包含 GKE 写入的条目。

为了区分您的 CDE 工作负载和非 CDE 工作负载，我们建议您在 GKE pod 中添加标签，以便对这些工作负载所产生的指标和日志进行过滤。

要求 10.2.2

审核日志会记录每个可审核事件的以下详细信息：
  • 用户识别
  • 事件类型
  • 日期和时间
  • 成功或失败指标
  • 事件的起因
  • 受影响数据、系统组件、资源或服务的身份或名称（例如名称和协议）

Logging 中的每个审核日志条目都是 LogEntry 类型的对象，其中包含以下字段：

  • protoPayload 类型的载荷。每个审核日志条目的载荷都是 AuditLog 类型的对象。您可以在 AuditLog 对象的 AuthenticationInfo 字段中找到用户身份。
  • 特定事件，可在 AuditLog 的 methodName 字段中找到。
  • 时间戳。
  • 事件状态，可在 AuditLog 对象的 response 对象中找到。
  • 操作请求，可在 AuditLog 对象的 request 和 requestMetadata 对象中找到。
  • 要执行的服务，可在 serviceData 的 AuditData 对象中找到。

要求 11

定期测试系统和网络的安全性。

要求 11.3

外部和内部漏洞会定期识别、确定优先级并加以解决。

要求 11.3.1

内部漏洞扫描的执行方式如下：
  • 每三个月至少一次。
  • 高风险和严重漏洞（根据要求 6.3.1 中定义的实体漏洞风险等级）已解决。
  • 执行重新扫描以确认所有高风险和严重漏洞（如上文所述）均已解决。
  • 扫描工具会及时了解最新的漏洞信息。
  • 扫描由合格人员执行，并且组织独立于测试人员。

Artifact Analysis 漏洞扫描功能会针对 Container Registry 中的映像执行以下类型的漏洞扫描：

  • 初始扫描。当您首次激活 Artifact Analysis API 时，该 API 会扫描 Container Registry 中的映像，并提取软件包管理系统、映像基础和映像的漏洞发生实例。

  • 增量扫描。Artifact Analysis 会在新映像上传到 Container Registry 时扫描这些映像。

  • 持续分析：当 Artifact Analysis 从漏洞来源收到新的和更新后的漏洞信息时，它会重新运行容器分析，以确保已扫描映像的漏洞发生实例列表处于最新状态。

要求 11.5

检测到网络入侵和意外的文件更改，并做出响应。

要求 11.5.1

入侵检测和/或入侵防御技术用于检测和/或防止网络入侵，如下所示：
  • 所有流量都在 CDE 边界上受监控。
  • 所有流量都在 CDE 的关键点进行监控。
  • 我们会向员工发出可疑的入侵提醒。
  • 所有入侵检测和防御引擎、基准和签名都会保持最新。

您可以将 Google Cloud 数据包镜像与 Cloud IDS 搭配使用来检测网络入侵。Google Cloud 数据包镜像会将来自 Compute Engine 虚拟机或 Google Cloud 集群的所有网络流量转发到指定地址。Cloud IDS 可以使用此镜像流量检测各种威胁，包括攻击尝试、端口扫描、缓冲区溢出、协议分片、命令和控制 (C2) 流量以及恶意软件。

Security Command Center 可让您集中了解整个组织中各 Google Cloud 服务（包括 GKE）和资产的安全状态，从而更轻松地防御、检测和应对威胁。使用 Security Command Center，您可以根据 Cloud Logging 日志了解何时检测到恶意软件、加密货币挖矿、未经授权的 Google Cloud 资源访问、传出 DDoS 攻击、端口扫描和暴力破解 SSH 等高风险威胁。

维护信息安全政策

强有力的安全政策不仅奠定了安全基调，而且可让相关人员了解自己应尽的责任。在这种情况下，“人员”是指有权使用您的 CDE 的全职和兼职员工、临时雇员、承包商和顾问。

要求 12

通过组织政策和计划支持信息安全。

如需了解要求 12，请参阅 Google Cloud PCI 共担责任表。

清理

如果您在按照本文操作时使用了任何资源（例如，启动了新的虚拟机或使用了 Terraform 脚本），可以删除使用这些资源的项目以避免您的 Google Cloud 账号产生费用。

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

后续步骤