你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

符合 PCI DSS 4.0.1 标准的受管制 AKS 群集网络安全指南

本文介绍了根据支付卡行业数据安全标准 (PCI DSS 4.0.1) 配置的 Azure Kubernetes 服务 (AKS) 群集在网络设置方面的注意事项。

本文是一系列文章的其中一篇。 阅读简介。

PCI DSS 4.0.1 标准的核心是安全性，其中扩展了对网络分段、基于风险的范畴界定及持续监视的要求。 中心辐射型拓扑是设置受管制网络环境的不二选择。 创建允许安全通信的基础结构更容易。 网络控件位于中心辐射型网络中，并遵循 Microsoft 零信任模型。 可以使用最小特权来优化这些控件，以保护流量，从而根据需要了解的内容提供访问权限。 此外，可以通过在每个网络跃点和层级部署控制措施，实施多重纵深防御策略。

在 Kubernetes 中托管工作负载时，仅依赖传统网络构造（如防火墙规则）已不足以满足安全需求。 PCI DSS 4.0.1 强调同时使用云原生和 Kubernetes 原生控制措施，来实现分段隔离与安全通信。 还有 Kubernetes 本机构造，用于控制群集中的流量流，例如 NetworkPolicy 资源。 强烈建议参考 Kubernetes 文档，了解有关隔离 Pod 和入口及出口策略的核心概念。

重要

本指南及随附实施方案基于 AKS 基线体系结构编制，该体系结构采用中心辐射型拓扑。 中心虚拟网络包含用于控制出口流量的防火墙、来自本地网络的网关流量以及用于维护的第三个网络。 辐射型虚拟网络包含 AKS 群集，该群集提供持卡人环境 (CDE)，并托管 PCI DSS 工作负载。

GitHub 徽标 参考实现即将发布：符合 PCI DSS 4.0.1 标准的 Azure Kubernetes 服务 (AKS) 基准群集（受管制工作负载版）参考实现正在更新，即将正式发布。 此参考实现将展示受管制的基础结构示例，演示如何在 CDE 中实施各种网络与安全控制措施。 这包括 Azure 原生的网络控件和 Kubernetes 原生的控件。 还将包括一个应用程序，用以演示环境与示例工作负载之间的交互。 本文将重点介绍此基础结构。 该示例并不代表实际的 PCI-DSS 4.0.1 工作负载。

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

要求 1：安装并维护防火墙配置，以保护持卡人数据

AKS 功能支持

AKS 支持将专用虚拟网络中的群集部署为专用群集。 群集和 AKS 托管的 Kubernetes API 服务器之间的通信是通过受信任的网络进行的。 借助专用群集，可以使用 Azure 虚拟网络、网络安全组 (NSG) 和其他内置网络控件来保护整个持卡人数据环境 (CDE)。 这项配置将禁止 Internet 和环境之间任何未经授权的公共访问。 有关如何预配此类群集的详细信息，请参阅创建专用 Azure Kubernetes 服务群集。

可以将 Azure 防火墙与 AKS 集成，并限制从该群集（CDE 的关键组件）发出的出站流量。 使用 AKS FQDN 标记可简化此配置操作。 使用 Azure 防火墙保护 Azure Kubernetes 服务 (AKS) 部署中提供了推荐的操作流程。

AKS 群集需要一些公共 Internet 访问。 使用群集子网上的 Azure 防火墙 和 NSG 限制到 Internet 的出站流量。 相关信息，请参阅控制 Azure Kubernetes 服务 (AKS) 中群集节点的出口流量。

AKS 中可选择定义 HTTP 代理，该代理可用于群集的其他出站流量控制和监视。 群集节点使用指定的 HTTP 代理配置来路由出站流量。 此外，系统会注册一个 MutatingWebhook，用于在 Pod 创建时自动注入代理信息，因此建议工作负载应能继承相同的代理信息。 Pod 可覆盖代理信息，因此建议除了 Azure 防火墙之外，还可以叠加使用 HTTP 代理。

应使用 NetworkPolicy 插件创建 AKS 群集。 在 AKS 中，有多种网络策略插件选项，包括 Calico、Azure 网络策略管理和 Cilium。 若选用 Calico 网络策略，可搭配 Kubenet 或 Azure CNI 使用。 而 Azure 网络策略管理仅支持 Azure CNI（不支持 Kubenet）。 Azure 和 Calico 网络策略插件都是开源的。 有关 Project Calico 的详细信息，请参阅全面的 PCI 解决方案白皮书，该白皮书解决了 PCI DSS 4.0.1 中列出的多项防火墙要求。

PCI DSS 4.0.1 扩展了对网络分段、基于风险的范畴验证以及防火墙和路由器配置持续审查的要求。 需使用云原生网络安全工具，例如虚拟网络、安全组和微分段技术。 确保容器化工作负载使用适当的命名空间隔离和安全通信协议。 在容器环境中，需使用 Kubernetes 网络策略或类似工具来构建分层防御体系。

你的责任

要求 责任
要求 1.1 建立和实施防火墙和路由器配置标准，包括基于风险的范畴验证和定期审查。
要求 1.2 生成防火墙和路由器配置，限制不受信任网络和持卡人数据环境中任何系统组件之间的连接。
要求 1.3 禁止在 Internet 和持卡人数据环境中的任何系统组件之间进行的直接公开访问。
要求 1.4 在任何连接到 Internet 的网络外便携式计算设备（包括公司拥有的和/或个人拥有的设备，例如员工使用的笔记本电脑，也用于访问 CDE）上安装个人防火墙软件或等效的功能。
要求 1.5 确保记录在进行防火墙管理时使用过哪些安全策略和操作过程，并将其告知受影响的各方。

要求 1.1

建立并实施防火墙和路由器配置标准，包括以下内容：

要求 1.1.1

通过正式的流程来审核和测试所有网络连接以及对防火墙和路由器配置进行的更改。

你的责任

请勿手动实现配置，例如直接使用 Azure 门户或 Azure CLI。 建议使用基础结构即代码 (IaC)。 使用 IaC 时，基础结构通过使用版本控制系统的描述性模型进行管理。 每次应用 IaC 模型时都会生成相同的环境。 IaC 的常见示例包括 Bicep、Azure 资源管理器模板（ARM 模板）或 Terraform。 如果无法采用 IaC，应创建一个记录完备的流程来跟踪、实施和安全地部署防火墙规则更改。 要求 11.2 中提供了更多详细信息。

你需要结合使用各种网络控件，包括 Azure 防火墙、网络安全组 (NSG) 和 Kubernetes NetworkPolicy 资源。

尽量减少可以访问和修改网络控件的人数。 定义角色并明确对团队的职责。 例如，组织的网络团队将根据 IT 团队设置的治理策略验证更改。 设立一个门控式审批流程，包括审批任何网络配置更改的人员和流程。 此过程应包含用于测试所有网络控件的步骤。 提供描述该过程的详细文档。

要求 1.1.2

提供最新的网络图，其中标识持卡人数据环境和其他网络（包括任何无线网络）之间的所有连接

你的责任

作为文档的一部分，维护一个网络流程图，其中显示了具有安全控件的传入和传出流量。 这包括从其他网络（包括任何无线网络）流向 CDE 的流量。 此图还应显示群集内的流。 图表有一些特定要求，包括应标示入侵检测传感器及所有已实施的控制措施。

下图显示了参考实现的网络图：

网络拓扑示意图。

下载此图的 Visio 文件。

图 1.1.2 - 网络流

此流的说明位于以下部分中。

如果你有 Azure 网络观察程序，则可以查看 Azure 虚拟网络的拓扑。 可以查看虚拟网络中的所有资源、与虚拟网络中的资源相关联的资源，以及这些资源的相互关系。

要求 1.1.3

提供最新的关系图，显示所有跨系统和网络的持卡人数据流。

你的责任

作为文档的一部分，包括一个数据流关系图，显示数据在静态和传输中是如何受到保护的。

该图应显示数据流向工作负载的方式以及从一个资源传递到另一个资源的信息。 请确保该图保持最新。 在更改管理流程中添加一个步骤，用于更新数据流关系图。

由于此体系结构专注于基础结构而不是工作负载，因此我们在此处省略了插图。

要求 1.1.4

要求在每个 Internet 连接上以及在任何外围网络 (DMZ) 和内部网络区域之间部署防火墙。

你的责任

对定义 DMZ 边界的内容有一个明确的定义。 例如，持卡人数据环境 (CDE) 可能位于受防火墙、网络策略和其他控制措施保护的 DMZ 内。 有关详细信息，请参阅 Cloud DMZ。

对于 PCI DSS 基础结构，你有责任通过实施网络控制措施，阻止未经授权地进入和离开包含 CDE 的网络，以保障 CDE 的安全。 必须正确配置网络控件以实现高度安全态势，并且必须将其应用于：

  • 群集中已分配的组件之间的通信。
  • 受信任网络中工作负载和其他组件之间的通信。
  • 工作负载与公共 Internet 之间的通信。

此体系结构使用不同的防火墙技术，来检查流入和流出托管 CDE 的群集的流量：

  • 用于容器的 Azure 应用程序网关充当流量路由器，其集成的 Web 应用程序防火墙（WAF）保护到群集的入站（入口）流量。

  • Azure 防火墙可为任何网络及其子网的所有出站（出口）流量提供安全防护。

    在处理事务或管理操作过程中，群集需要与外部终结点进行通信。 例如，群集可能需要与 AKS 控制平面通信、与操作系统和包更新系统通信，并且很多工作负载需要与外部 API 交互。 其中一些交互可能是通过 HTTP 进行的，应被视为攻击途径。 这些途径是中间人攻击的目标，可能导致数据外泄。 向出口流量添加防火墙可以减轻这种威胁。

    建议即使是 Pod 到 Pod 通信也经过 TLS 加密。 这一做法已在参考实现中通过双向 TLS 认证得到完整呈现。

  • NSG 可为群集与基础结构内其他组件间的流量提供保护。 例如，在参考实现中，子网上的 NSG 具有阻止任何 SSH 访问尝试的节点池。 只允许来自虚拟网络的流量通行。

    在向体系结构添加组件时，请考虑添加更多允许或拒绝子网边界处流量类型的 NSG。 由于每个节点池都位于专用子网中，因此请根据工作负载的预期流量模式应用更具体的规则。

  • Kubernetes NetworkPolicy 对象用于控制群集内通信。

    默认情况下，Pod 到 Pod 通信没有限制。 你需要将 NetworkPolicy 应用于群集内通信，从零信任网络开始，并根据需要开放路径。 参考实现演示了 a0005-i 和 a0005-o 命名空间中的零信任网络。 所有命名空间（kube-system、gatekeeper-system 和其他 AKS 提供的命名空间除外）都应用了限制性网络策略。 策略定义取决于在这些命名空间中运行的 Pod。 请确保为就绪情况、实时性和启动探测开放路径。 此外，打开到 oms-agent 的路径，以便可以发送节点级指标。 考虑跨工作负载标准化端口，以便可以为允许的容器端口提供一致的 NetworkPolicy 和 Azure Policy。

要求 1.1.5

描述与管理网络组件相对应的组、角色和责任。

你的责任

你需要对网络流及相关组件实施控制。 生成的基础结构将有几个网段，每个网段都有许多控件，每个控件都有一个目的。 确保文档覆盖范围从网络规划延伸至所有已实施的配置， 同时需包含所有权细节，明确责任边界及对应负责角色。

例如，了解谁负责治理 Azure 和 Internet 之间的网络安全防护。 在企业中，IT 团队通常负责配置和维护 Azure 防火墙规则、Web 应用程序防火墙 (WAF)、NSG 和其他跨网络流量。 它们还可能负责企业范围的虚拟网络和子网分配以及 IP 地址规划。

在工作负载级别，群集操作员负责通过网络策略维护零信任。 此外，职责可能包括与 Azure 控制平面、Kubernetes API 和监视技术的通信。

始终从“拒绝所有”策略入手。 仅当存在业务需求或角色理由时，才授予权限。

要求 1.1.6

记录使用所有允许的服务、协议和端口时的业务理由和审核情况，包括记录为那些被视为不安全的协议实施的安全功能。

你的责任

提供详细文档，描述网络控件中使用的服务、协议和端口。 拒绝除显式允许端口以外的所有端口。 如果无法避免使用不安全协议，请记下业务理由和记录的安全功能。 以下是 Azure 防火墙参考实现中的一些示例。 防火墙规则的范围必须专门限定于其相关资源。 也就是说，仅允许来自特定源的流量流向特定的 FQDN 目标。

下表列出了可能需要允许流量通行的示例：

规则 Protocol:Port 来源 目的地 理由
允许节点与控制平面之间的安全通信。 HTTPS:443 分配给群集节点池的授权 IP 地址范围 AKS 控制平面中的 FQDN 目标列表。 这是使用 AzureKubernetesService FQDN 标记指定的。 节点需要访问控制平面以获取管理工具、状态和配置信息，以及可缩放哪些节点的相关信息。
允许 Flux 与 GitHub 之间的安全通信。 HTTPS:443 AKS 节点池 github.com、api.github.com Flux 是在节点上运行的第三方集成。 它将群集配置与专用 GitHub 存储库同步。

要求 1.1.7

要求至少每六个月审核一次防火墙和路由器规则集。

你的责任

设置至少每六个月审查一次网络配置和已限定范围的规则的流程。 此举可确保安全防护措施持续有效。 请务必核查以下配置：

  • Azure 防火墙规则。
  • NSG 规则。
  • 用于容器和 WAF 规则的 Azure 应用程序网关。
  • Kubernetes 本机网络策略。
  • 对适用的 Azure 资源的防火墙控制。 例如，此体系结构对 Azure 容器注册表使用了一项规则，仅允许来自专用终结点的流量。
  • 已为体系结构实施的其他任何网络控制措施。

若自上一次评审以来已停用任何工作负载或更改了群集的配置，请务必验证对所需防火墙例外规则或 NSG 规则所做的任何假设是否仍然有效。

要求 1.2

生成防火墙和路由器配置，限制不受信任网络和持卡人数据环境中任何系统组件之间的连接。

你的责任

在此体系结构中，AKS 群集是持卡人数据环境 (CDE) 的关键组件。 强烈建议将群集部署为专用群集，以增强安全性。 在专用群集中，AKS 托管的 Kubernetes API 服务器与节点池之间的网络流量是专用的。 API 服务器通过群集网络中的专用终结点公开。

也可以选择公共群集，但不建议将此设计用于包含受管制工作负载的群集。 API 服务器将公开给 Internet，且 DNS 记录将始终可发现，因此需要采取控制措施，确保群集 API 免受公共访问。 如果需要使用公共群集，建议的方法是通过 Kubernetes 基于角色的访问控制 (RBAC) 进行严格控制，结合 AKS 授权 IP 范围功能来限制可访问 AKS API 服务器的人员。 但是，对于包含受管制工作负载的群集，不建议使用此解决方案。

在处理持卡人数据 (CHD) 时，群集需要与被认为受信任和不受信任的网络进行交互。 在此体系结构中，PCI DSS 4.0.1 工作负载范围内的两个中心辐射型网络都被视为受信任网络。

超出该边界的网络即为不受信任网络。 不受信任的网络包括：

  • 可能位于同一基础结构、但位于此工作负载范围外的其他中心辐射型网络。
  • 公共 Internet。
  • 企业网络。
  • Azure 或其他云平台中的其他虚拟网络。

在此体系结构中，托管映像生成器的虚拟网络不受信任，因为它没有参与 CHD 处理。 应根据要求保护 CDE 与此类网络的交互。 借助此专用群集，可以使用虚拟网络、NSG 和其他内置功能来保护整个环境。

有关专用群集的信息，请参阅创建专用 Azure Kubernetes 服务 (AKS) 群集。

要求 1.2.1

对入站和出站流量进行限制，只满足持卡人数据环境的需要（具体说来，就是拒绝所有其他流量）。

你的责任

根据设计，Azure 虚拟网络无法通过公共 internet 直接访问。 所有入站（或入口）流量都必须通过中间流量路由器。 然而默认情况下，网络内的所有组件都可访问公共终结点。 可以通过配置专用子网或使用 UDR 将全部出站流量导向防火墙，来禁用此行为。 必须显式保护这类出站（或出口）流量，仅允许使用安全密码和 TLS 1.2 或更高版本。

  • Azure 容器应用程序网关的集成 WAF 拦截所有 HTTP(S) 入站流量，并将经过检查的流量路由到集群。

    此流量可能源自受信任的或不受信任的网络。 适用于容器的应用程序网关在辐射型网络的子网中预配，并由 NSG 进行保护。 当流量流入时，WAF 规则允许或拒绝，容器的应用程序网关会将流量路由到配置的后端。 例如，用于容器的应用程序网关通过拒绝以下类型的流量来保护 CDE：

    • 所有未经过 TLS 加密的流量。
    • 来自 Azure 基础结构的控制平面通信端口范围之外的流量。
    • 由群集中非内部负载均衡器的实体发送的运行状况探测请求。

  • Azure 防火墙可为受信任和不受信任网络的所有出站（出口）流量提供保护。

    Azure 防火墙在中心网络的子网中进行预配。 为了将 Azure 防火墙强制实施为单个出口点，在能够生成出口流量的子网上使用用户定义的路由 (UDR)。 这包括不受信任的网络中（例如映像生成器虚拟网络）中的子网。 流量到达 Azure 防火墙后，将应用多个已限定范围的规则，允许来自特定源的流量流向特定目标。

    有关详细信息，请参阅 使用 Azure 防火墙保护 Azure Kubernetes 服务 （AKS） 部署。

  • （可选）可以使用 HTTP 代理来监视和保护从群集到外部资源的出站（出口）流量。

    除了防火墙之外，一些组织可能希望使用 HTTP 代理来对出口进行额外控制。 建议仍将用户定义的路由指向防火墙，并将出口流量限制为仅转到 HTTP 代理。 通过此设置，如果 Pod 尝试替代代理，则防火墙仍然可以阻止出口流量。

    有关详细信息，请参阅 Azure Kubernetes 服务 (AKS) 中的 HTTP 代理支持。

群集可能需要通过公共 Internet 访问其他服务。 例如，如果使用第三方反恶意软件，则需要通过公共 Internet 从服务器获取病毒定义。

与其他 Azure 服务终结点的交互通过 Azure 主干网进行。 例如，作为常规操作的一部分，群集需要从托管密钥存储获取证书、从容器注册表拉取映像等。 使用 Azure 专用链接 确保这些交互的私密性和安全性。

除了防火墙规则和专用网络之外，流量传输还通过 NSG 规则进行保护。 以下示例展示了通过拒绝流量来防护 CDE 的体系结构：

  • 为节点池所在的子网配置 NSG，以拒绝所有对其节点的 SSH 访问。 确保建立即时应急访问流程，同时严格遵守“全部拒绝”原则。
  • 为用于运行管理工具的跳转盒所在的子网配置 NSG，以拒绝除中心网络 Azure Bastion 以外的所有流量。
  • 为 Azure Key Vault 和 Azure 容器注册表专用终结点所在的子网配置 NSG，以拒绝除内部负载均衡器之外的所有流量以及通过 Azure 专用链接传输的流量。

要求 1.2.2

保护并同步路由器配置文件。

你的责任

设立一种机制来检测实际部署状态和期望状态之间的差异。 基础结构即代码 (IaC) 是一个不错的选择。 例如，Bicep 文件或 Azure 资源管理器模板（ARM 模板）会保留所需状态的记录。

部署资产（如 Bicep 文件）必须进行源代码版本控制，以便留存完整的更改历史记录。 从 Azure 活动日志、部署管道日志和 Azure 部署日志中收集信息。 这些源将帮助你跟踪已部署资产。

在群集中，Kubernetes 网络策略等网络控件也应该遵循受源代码管理的流。 在此实现中，Flux 用作 GitOps 运算符。 同步群集配置（如网络策略）时，结合 Git 历史记录、Flux 和 API 日志，就能构成完整的配置历史记录源。

要求 1.2.3

在所有无线网络和持卡人数据环境之间安装外围防火墙，并将这些防火墙配置为拒绝所有流量。即使流量是业务需要的，也只允许无线环境和持卡人数据环境之间的授权流量。

你的责任

不能从无线网络访问 AKS 节点和节点池。 此外，必须拒绝对 Kubernetes API 服务器的请求。 对这些组件的访问仅限于经过授权和受保护的子网。

一般情况下，限制从本地流量访问辐射型网络。

要求 1.3

禁止在 Internet 和持卡人数据环境中的任何系统组件之间进行的直接公开访问。

你的责任

AKS 群集节点池在虚拟网络中运行，并独立于公用网络，例如 Internet。 通过禁止为群集节点分配公共 IP，并在群集子网实施 NSG 规则以阻断 Internet 流量，从而维持隔离状态。 有关受控访问的信息，请参阅 DMZ 部分。

AKS 群集具有托管关键系统 Pod 的系统节点池。 即使在用户节点池上，也有一些 Pod 运行其他参与群集操作的服务。 例如，Pod 可能会运行 Flux 以将群集配置同步到 GitHub 存储库，或者运行入口控制器以将流量路由到工作负载 Pod。 无论节点池的类型如何，都必须保护所有节点。

另一个关键系统组件是 API 服务器，其用于执行本机 Kubernetes 任务，例如维护群集与配置状态。 使用专用群集的优点是，默认情况下不会公开 API 服务器终结点。 有关专用群集的信息，请参阅创建专用 Azure Kubernetes 服务 (AKS) 群集。

还必须保护与其他终结点的交互。 一种方法是限制专用网络上的通信。 例如，让群集通过专用链接从 Azure 容器注册表拉取映像。

要求 1.3.1

实施外围网络，只允许入站流量流向相应的系统组件，这些组件提供授权的可公开访问的服务、协议和端口。

你的责任

查看以下实现 DMZ 的最佳做法：

  • 不要在节点池节点上配置公共 IP 地址。
  • 使用 Azure Policy 确保 Kubernetes 不会公开公共负载均衡器。 群集中的流量必须通过内部负载均衡器进行路由。
  • 仅向与 WAF 集成的容器的 Azure 应用程序网关公开内部负载均衡器。
  • 所有网络控件都应指定源、目标、端口和协议限制（如果适用）。
  • 不要向 Internet 公开 API 服务器。 在专用模式下运行群集时，不会公开终结点，节点池与 API 服务器之间的通信通过专用网络进行。

可以实现外围网络来保护 AKS 群集。 有关详细信息，请参阅 Cloud DMZ。

要求 1.3.2

只允许入站 Internet 流量流向外围网络中的 IP 地址。

你的责任

在群集网络中，在子网中配置 NSG，并配置内部负载均衡器。 将规则配置为仅接受来自以下子网的流量：包含适用于容器的应用程序网关且该网关已与 WAF 集成。 在 AKS 群集中，使用 Kubernetes NetworkPolicies 限制 Pod 的入口流量。

要求 1.3.3

实施反欺骗措施，检测伪造的源 IP 地址并阻止其进入网络。

Azure 责任

Azure 实施网络筛选是为了防止欺骗流量，将传入和传出流量限制为可信平台组件。

要求 1.3.4

不允许从持卡人数据环境流向 Internet 的未授权出站流量。

你的责任

可以使用以下最佳做法阻止未经授权的出站流量：

  • 通过在所有群集子网上使用用户定义的路由 (UDR)，强制来自 AKS 群集的所有出站（出口）流量通过 Azure 防火墙。 这包括具有系统和用户节点池的子网。
  • 通过在具有节点池的子网上添加 NSG 来限制出站流量。
  • 使用 Kubernetes NetworkPolicies 限制来自 Pod 的出口流量。
  • 使用服务网格来处理其他策略。 例如，如果只允许 Pod 之间的 TLS 加密流量，则服务网格代理可以处理 TLS 验证。 该示例在此实现中进行了演示。 Envoy 部署为代理。
  • 除非通过显式授权的子网（例如防火墙子网），否则阻止将公共 IP 地址添加到 CDE 内的网络。
  • 除 Azure 防火墙外，还使用 HTTP 代理来限制从 AKS 群集到 Internet 的出站（出口）流量。
  • 使用 Azure Monitor 专用链接服务 (AMPLS) 将来自容器见解的日志通过安全的专用连接发送到 Azure Monitor。 了解启用 AMPLS 的影响。

注释

可以使用 Kubernetes NetworkPolicies 来限制进出 Pod 的入口流量和出口流量。

有关详细信息，请参阅控制 Azure Kubernetes 服务 (AKS) 中群集节点的出口流量。

要求 1.3.5

只允许“已建立的”连接连接到网络中。

Azure 责任

Azure 实施网络筛选是为了防止欺骗流量，将传入和传出流量限制为可信平台组件。 隔离 Azure 网络，以便将客户流量与管理人员流量分开。

要求 1.3.6

将存储持卡人数据的系统组件（例如数据库）置于内部网络区域，与外围网络和其他不受信任网络分开。

你的责任

仅通过专用网络公开存储系统，例如，使用专用链接。 此外，限制来自需要它的节点池子网的访问。 将状态隔离在群集之外，并置于群集自己的专用安全区域。

要求 1.3.7

不向未授权方披露专用 IP 地址和路由信息。

你的责任

若要满足这一要求，公共 AKS 群集并不可行。 专用群集通过使用专用 DNS 区域将 DNS 记录保留在公共 Internet 之外。 但是，仍然可以使用公共 DNS 地址创建专用 AKS 群集。 建议通过将 enablePrivateClusterPublicFQDN 设置为 false 来显式禁用此功能，以防止泄露控制平面的专用 IP 地址。 考虑使用 Azure Policy 以强制使用没有公共 DNS 记录的专用群集。

此外，使用专用 DNS 区域在子网之间路由，该子网具有与 WAF 集成的用于容器的 Azure 应用程序网关，以及具有内部负载均衡器的子网。 确保 HTTP 响应在标头或正文中不包含任何专用 IP 信息。 确保任何可能包含 IP 和 DNS 记录的日志不会在操作需求之外公开。

通过专用链接连接的 Azure 服务没有公开专用 IP 地址的公共 DNS 记录。 基础结构应充分利用专用链接。

要求 1.4

在任何连接到 Internet 的网络外便携式计算设备（也用于访问 CDE）上安装个人防火墙软件或等效的功能。

你的责任

专用群集由 AKS 控制平面管理。 你不能直接访问节点。 若要执行管理任务，需要使用来自单独计算资源的 kubectl 等管理工具。 一种选择是使用一个可在其中运行命令的气隙跳转盒。 此外，还必须限制和保护来自跳转盒的入站和出站流量。 如果使用 VPN 进行访问，请确保客户端计算机由公司策略管理，并且所有条件访问策略均已就绪。

在此体系结构中，该跳转盒位于辐射型网络中的一个单独的子网中。 使用仅允许基于 SSH 通过 Azure Bastion 访问的 NSG 来限制对跳转盒的入站访问。

若要在跳转盒中运行某些命令，需要访问公共终结点。 例如，由 Azure 管理平面管理的终结点。 必须保护出站流量。 与分支网络中的其他组件类似，通过使用 UDR 强制 HTTPS 流量通过 Azure 防火墙，限制来自跳转盒的出站流量。

要求 1.5

确保记录在进行防火墙管理时使用过哪些安全策略和操作过程，并将其告知受影响的各方。

你的责任

维护关于流程和策略的完整文档至关重要。 在管理分段 AKS 群集的 Azure 防火墙规则时，尤其如此。 操作受管制环境的人员必须接受培训、了解情况并受到激励，以支持安全性保证。 对于帐户被授予广泛管理权限的用户来说，这一点尤其重要。

要求 2：不要将供应商提供的默认值用作系统密码和其他安全参数

你的责任

要求 责任
要求 2.1 在网络上安装系统之前，始终更改供应商提供的默认设置，删除或禁用不必要的默认帐户。
要求 2.2 为所有系统组件制定配置标准。 确保这些标准解决了所有已知的安全漏洞，并且符合行业接受的系统强化标准。
要求 2.3 使用增强加密技术加密所有非控制台管理访问。
要求 2.4 维护处于 PCI DSS 范围内的系统组件清单。
要求 2.5 确保管理供应商默认值和其他安全参数的安全策略和操作程序已记录在案、正受使用并为所有受影响方所知。
要求 2.6 共享宿主提供程序必须保护每个实体的托管环境和持卡人数据。

不要将供应商提供的默认值用作系统密码和其他安全参数

要求 2.1

在网络上安装系统之前，始终更改供应商提供的默认设置，删除或禁用不必要的默认帐户。

你的责任

必须更改供应商提供的默认设置。 默认设置是常见的攻击途径，使系统容易受到攻击。 请考虑采用以下最佳做法：

  • 禁用容器注册表上的管理员访问权限。
  • 确保跳转盒和生成代理遵循用户管理过程，删除不需要的系统用户。
  • 不要生成或向管理员用户提供节点的 SSH 密钥访问权限。 如果需要紧急访问，请使用 Azure 恢复过程获取实时访问权限。

Azure 责任

Microsoft Entra ID 具有对用户提供的新密码强制实施的密码策略。 如果更改密码，则需要验证旧密码。 当用户下次登录时，需要更改由管理员重置的密码。

要求 2.1.1

对于连接到持卡人数据环境或传输持卡人数据的无线环境，请在安装时更改所有无线供应商默认设置，包括但不限于默认的无线加密密钥、密码和 SNMP 社区字符串。

你的责任

此体系结构和实施并非旨在通过无线连接进行本地或公司网络到云的交易。 有关注意事项，请参阅官方 PCI DSS 4.0.1 标准中的指南。

要求 2.2

为所有系统组件制定配置标准。

你的责任

实施 Microsoft 云安全基准中的各项建议。 它提供统一整合的 Azure 安全建议视图，涵盖 CIS、NIST、PCI DSS 4.0.1 等行业标准框架。 使用 Microsoft Defender for Cloud 功能和 Azure Policy 来帮助跟踪标准。 Azure 安全基准是 Microsoft Defender for Cloud 的默认计划。 请考虑在 Azure Policy 和 Azure 租户安全解决方案 (AzTS) 中构建额外的自动检查。

记录 CDE 中所有组件的所需配置状态，尤其是 AKS 节点、跳转盒、生成代理以及与群集交互的其他组件。

有关详细信息，请参阅 Microsoft 云安全基准。

Azure 责任

Azure 提供与行业接受的强化标准一致的安全配置标准。 这些标准至少每年进行一次评审。

要求 2.2.1

每个服务器只实现一个主功能，防止需要不同安全级别的功能共存于同一服务器上。 （例如，Web 服务器、数据库服务器和 DNS 应在不同服务器上实现。）

你的责任

关键策略是提供所需的分段级别。 一种方法是在单独的群集中部署范围内和超出范围的组件。 要知道，这将导致基础结构的成本和维护开销增加。 另一种方法是并置共享群集中的所有组件。 使用分段策略来保持分离。 例如，在群集中设置单独的节点池。

在参考实现中，通过部署到单个群集的微服务应用程序演示了第二种方法。 该应用程序有两组服务：一组具有范围内 Pod，另一组超出范围。 这两组分布在两个用户节点池中。 通过使用 Kubernetes 排斥，范围内和超出范围的 Pod 将部署到单独的节点池中，并且它们从不共享节点 VM。

对于容器技术，默认情况下会提供分段，因为只有一个容器实例负责系统中的一项功能。

每个工作负载 Pod 都应使用专属标识。 它不得继承任何群集级或节点级标识。

尽可能使用外部存储而不是节点上（群集内）存储。 保留群集 Pod，专门用于必须作为持卡人数据处理操作的一部分执行的工作。 将超出范围的操作移出群集。 本指南适用于生成代理、不相关的工作负载或在群集内设置跳转盒之类的活动。

要求 2.2.2

只启用必需的服务、协议、守护程序等，这些都是系统运行所必需的。

你的责任

在启用这些功能之前，请查看功能及其含义。 默认设置可能包括你不需要的功能，而这些功能可能需要了解工作负载的情况。 例如，适用于容器的 Azure 应用程序网关的默认 TLS 策略中的密码。 检查策略是否过于宽松。 建议通过仅选择所需的密码来创建自定义策略。

对于可以完全控制的组件，请从映像中删除所有不必要的系统服务。 例如，查看跳转盒和生成代理的映像，并删除所有不需要的组件。

对于只对其有可见性的组件（例如 AKS 节点），请记录 Azure 在节点上安装的内容。 考虑使用 DaemonSets 为这些云控制的组件提供任何必要的额外审核。

要求 2.2.3

对于任何被视为不安全的必需服务、协议或守护程序，实施更多的安全功能。

你的责任

适用于容器的应用程序网关应集成 WAF 防护，并为发送至其公共终结点的请求协商 TLS 握手，以仅允许使用安全密码。 引用实现仅支持 TLS 1.2 和批准的密码。

假设你有一个需要通过 Azure 应用程序网关与 CDE 交互的旧设备。 为了满足此要求，应用程序网关必须启用不安全的协议。 记录该异常并监视该协议是否在旧设备之外使用。 在旧交互中断后立即禁用该协议。

应用程序网关不得响应端口 80 上的请求。 不要在应用程序级别执行重定向。 此参考实现有一个阻止端口 80 流量的 NSG 规则。 该规则位于具有应用程序网关的子网上。

如果群集中的工作负载无法遵守有关安全合规性配置文件或其他控制措施（例如限制和配额）的组织策略，请确保记录异常。 必须进行监视，以确保仅执行预期的功能。

要求 2.2.4

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

你的责任

体系结构中使用的所有 Azure 服务都必须遵循 Microsoft 云安全基准提供的建议做法。 这些建议为你提供了选择特定安全配置设置的起点。 此外，请将配置与该服务的基线实现进行比较。 有关安全基线的详细信息，请参阅 Azure 安全基线。

Open Policy Agent 许可控制器与 Azure Policy 协同工作，以检测和防止群集上的错误配置。 假设有一个组织策略不允许在节点上分配公共 IP。 检测到此类分配时，会根据策略定义中指定的操作将其标记为审核或拒绝。

在基础结构级别，可以对 Azure 资源的类型和配置应用限制。 使用 Azure Policy 来避免错误配置。 在此参考实现中，有一个策略拒绝创建非专用的 AKS 群集。

确保记录所有例外情况，并定期审查。

Azure 责任

Azure 使用多重访问控制和记录业务需求的方式，确保只有经授权的人员能够配置 Azure 平台安全控件。

要求 2.2.5

删除所有不需要的功能，例如脚本、驱动程序、功能、子系统、文件系统，以及不需要的 Web 服务器。

你的责任

不要在跳转盒上安装软件，也不要生成不参与事务处理或为合规性要求提供可观测性的代理，例如安全代理。 此建议也适用于群集实体，例如 DaemonSet 和 Pod。 确保检测并记录所有安装。

要求 2.3

使用增强加密技术加密所有非控制台管理访问。

你的责任

应使用控制台完成对群集的所有管理访问。 不要公开群集的控制平面。

Azure 责任

Azure 确保在访问虚拟机监控程序基础结构时强制使用强加密。 它可确保使用 Azure 门户的客户能够使用强加密来访问自己的服务和主机控制台。

要求 2.4

维护处于 PCI DSS 范围内的系统组件清单。

你的责任

体系结构中使用的所有 Azure 资源都必须正确标记。 标记有助于数据分类，并指示服务是范围内还是超出范围。 通过细致的标记，可以查询资源、保留库存、帮助跟踪成本并设置警报。 此外，还要定期维护该文档的快照。

避免在粒度级别标记范围内或超出范围的资源。 随着解决方案的发展，超出范围的资源可能会转变为范围内资源，即使它们间接交互或与持卡人数据相邻。 这些资源都要接受审核，在审核时可以作为具有代表性的样本的一部分。 考虑在更高的级别上进行标记，即订阅和群集级别。

有关标记注意事项的信息，请参阅资源命名和标记决策指南。

通过应用 Kubernetes 标签来标记群集内对象。 这样就可以组织对象、选择对象集合和报告清单。

要求 2.5

确保管理供应商默认值和其他安全参数的安全策略和操作程序已记录在案、正受使用并为所有受影响方所知。

你的责任

维护关于流程和策略的完整文档至关重要。 人员应接受有关每个 Azure 资源的安全功能和配置设置的培训。 操作受管制环境的人员必须接受培训、了解情况并受到激励，以支持安全性保证。 对于任何被授予广泛管理权限的人来说，这些步骤尤为重要。

要求 2.6

共享宿主提供程序必须保护每个实体的托管环境和持卡人数据。

你的责任

Azure 为共享的托管环境组件提供安全保证。 强烈建议将 AKS 节点视为此工作负载的专用主机。 也就是说，所有计算都应位于单个租户模型中，而不是与可能操作的其他工作负载共享。

如果想要在 Azure 基础结构级别实现完全的计算隔离，则可以将 Azure 专用主机添加到 Azure Kubernetes 服务 (AKS) 群集。 此产品/服务提供专用于工作负载的物理服务器，使你能够将 AKS 节点直接放入这些预配的主机中。 此体系结构选择将显著影响成本结构，需要仔细规划容量。 该方案并非多数场景的典型选择。

后续步骤

保护存储的持卡人数据。 跨开放的公用网络加密传输持卡人数据。

保护持卡人数据

  • Last updated on