为适用于 PCI-DSS 3.2.1 的 AKS 受管制群集配置网络（第 3 部分，共 9 部分）

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

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

PCI-DSS 3.2.1 标准的主题是安全性。 中心辐射型拓扑是设置受管制网络环境的自然选择。 创建允许安全通信的基础结构更容易。 网络控件位于中心辐射型网络中，并遵循 Microsoft 零信任模型。 可以使用最小特权来优化这些控件，以保护流量，从而根据需要了解的内容提供访问权限。 此外，可以通过在每个网络跃点和层处添加控件来应用多个深度防御方法。

在 Kubernetes 中托管工作负载时，仅依赖传统网络构造（如防火墙规则）是不够的。 还有 Kubernetes 本机构造，用于控制群集中的流量流，例如 NetworkPolicy 资源。 强烈建议参考 Kubernetes 文档，了解有关隔离 Pod 和入口及出口策略的核心概念。

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

要求 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 解决方案白皮书，该白皮书解决了以下许多防火墙要求。

您的职责

需求	责任方
要求 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 (mTLS) 身份验证时，参考实现中显示了这种做法。

• 将添加 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 目标。

下面是一些可能允许流量的示例：

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

要求 1.1.7

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

您的职责

设置至少每六个月审查一次网络配置和已限定范围的规则的流程。 这将确保安全保证是最新和有效的。 请确保查看以下配置：

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

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

要求 1.2

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

您的职责

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

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

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

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

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

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

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

要求 1.2.1

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

您的职责

无法从公共 Internet 直接访问 Azure 虚拟网络，这是设计使然。 所有入站（或入口）流量都必须通过中间流量路由器。 但是，默认情况上，网络中的所有组件都可以访问公共终结点。 可以通过配置专用子网或使用 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 服务中的 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。 无论节点池的类型如何，都必须保护所有节点。

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

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

要求 1.3.1

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

您的职责

下面是一些最佳做法：

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

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

要求 1.3.2

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

您的职责

在群集网络中，在子网中配置 NSG，并配置内部负载均衡器。 将规则配置为仅接受来自具有与 WAF 集成的 Azure 应用程序网关的子网的流量。 在 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 的影响。

有关详细信息，请参阅控制 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 管理平面管理的终结点。 必须保护出站流量。 与分支网络中的其他组件类似，通过使用强制 HTTPS 流量通过 Azure 防火墙的 UDR 来限制来自跳转盒的出站流量。

要求 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 3.2.1 标准中的指南。

要求 2.2

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

您的职责

实施 Microsoft 云安全基准中的建议。 它提供 Azure 安全建议的单一整合视图，涵盖行业框架，如 CIS、NIST、PCI-DSS 3.2.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 应用程序网关的默认 SSL 策略中的密码就是这方面的一个示例。 检查策略是否过于宽松。 建议通过仅选择所需的密码来创建自定义策略。

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

对于只对其有可见性的组件（例如 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 节点直接放入这些预配的主机中。 此体系结构选择具有显著的成本影响，需要仔细规划容量。 对于大多数方案来说，这并不常见。

后续步骤

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

相关资源

• Azure Kubernetes 服务 (AKS) 体系结构设计
• 适用于 PCI-DSS 3.2.1 的 AKS 受管制群集简介（第 1 部分，共 9 部分）
• 适用于 PCI-DSS 3.2.1 的 AKS 受管制群集体系结构（第 2 部分，共 9 部分）
• Azure Kubernetes 服务 (AKS) 群集的基线体系结构
• 多区域群集的 AKS 基线