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 和入口和出口策略的核心概念。

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

要求 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 代理配置来路由出站流量。 此外，为在创建时将代理信息注入 Pod 而注册 MutatingWebhook，因此建议工作负荷可以继承相同的代理信息。 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.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 内。

对于 PCI DSS 基础结构，你负责使用网络控制来阻止对包含 CDE 的网络进行未经授权的访问和传出 CDE 来保护 CDE。 必须正确配置网络控制，使其具有强大的安全态势，并且必须应用于：

• 群集中并置组件之间的通信。
• 受信任网络中工作负荷和其他组件之间的通信。
• 工作负荷与公共 Internet 之间的通信。

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

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

• Azure 防火墙保护来自任何网络及其子网的所有出站（出口）流量。

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

  我们建议即使是 Pod 到 Pod 通信也是 TLS 加密的。 使用相互 TLS （mTLS） 身份验证的参考实现中显示了这种做法。

• NSG 保护群集与基础结构中的其他组件之间的流量。 例如，在参考实现中，子网上有 NSG，这些 NSG 包含阻止任何 SSH 访问尝试的节点池。 仅允许来自虚拟网络内的流量。

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

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

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

要求 1.1.5

网络组件管理的组、角色和职责的说明。

你的责任

你需要在网络流和所涉及的组件上提供控制。 生成的基础结构将有多个网段，每个网段具有多个控件，每个网段都有用途。 确保文档涵盖范围广，从网络规划到应用的所有配置。 它还应包括所有权的详细信息，明确责任线和对其负责的角色。

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

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

始终从拒绝策略开始。 仅当有业务需求或角色理由时才授予权限。

要求 1.1.6

允许使用所有服务、协议和端口的业务理由和批准文档，包括为那些被认为不安全的协议实现的安全功能文档。

你的责任

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

下表列出了允许流量的示例：

要求 1.1.7

至少每六个月查看防火墙和路由器规则集的要求。

你的责任

至少每六个月处理一次，以查看网络配置和范围规则。 这可确保安全保证是最新的且有效的。 请确保查看以下配置：

• Azure 防火墙规则。
• NSG 规则。
• Azure 应用程序网关和 WAF 规则。
• 本机 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

限制持卡人数据环境所需的入站和出站流量，并专门拒绝所有其他流量。

你的责任

根据设计，无法直接从公共 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 服务 （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 运算符。 同步群集配置（例如网络策略）时，与 Flux 和 API 日志结合使用的 Git 历史记录可以是配置历史记录源。

要求 1.2.3

在所有无线网络和持卡人数据环境之间安装外围防火墙，并配置这些防火墙以拒绝或仅允许无线环境和持卡人数据环境之间的授权流量（如果出于业务目的需要流量）。

你的责任

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

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

要求 1.3

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

你的责任

AKS 群集节点池在虚拟网络中运行，并独立于 Internet 等公用网络。 通过在群集子网上应用 NSG 规则来确保 Internet 流量被阻止，从而防止公共 IP 与群集节点关联，从而保持隔离。 有关受控访问的信息，请参阅 DMZ 部分。

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

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

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

要求 1.3.1

实现外围网络，将入站流量限制为仅提供经过授权的可公开访问的服务、协议和端口的系统组件。

你的责任

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

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

可以实现外围网络来保护 AKS 群集。

要求 1.3.2

将入站 Internet 流量限制为外围网络内的 IP 地址。

你的责任

在群集网络中，在子网上具有内部负载均衡器的 NSG。 配置规则以仅接受已将 Azure 应用程序网关与 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 部署为代理。
• 除非通过显式授权的子网（例如防火墙子网）阻止向 CDE 中的网络添加公共 IP 地址。
• 除了 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 区域在已将 Azure 应用程序网关与 WAF 集成的子网与具有内部负载均衡器的子网之间进行路由。 确保没有 HTTP 响应在标头或正文中包含任何专用 IP 信息。 确保不包含 IP 和 DNS 记录的任何日志不会在作需求之外公开。

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

要求 1.4

在网络外部以及用于访问 CDE 的任何便携式计算设备上安装个人防火墙软件或等效功能。

你的责任

专用群集由 AKS 控制平面管理。 你无权直接访问节点。 对于管理任务，需要从单独的计算资源使用管理工具，例如 kubectl。 一个选项是使用空隙跳线框，可在其中运行命令。 此外，必须限制和安全的跳线框的入站和出站流量。 如果 VPN 用于访问，请确保客户端计算机由公司策略管理，并且所有条件访问策略都已到位。

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

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

要求 1.5

确保记录了管理防火墙的安全策略和作过程，以供所有受影响的各方了解。

你的责任

维护有关流程和策略的彻底文档至关重要。 在管理细分 AKS 群集的 Azure 防火墙规则时，尤其如此。 必须对运营监管环境的人员进行教育、通知和激励，以支持安全保证。 对于拥有广泛管理权限的帐户的用户来说，这一点尤其重要。

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

你的责任

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

要求 2.1

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

你的责任

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

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

Azure 职责

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

要求 2.1.1

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

你的责任

此体系结构和实现不设计为通过无线连接对云事务执行本地或公司网络。 有关注意事项，请参阅官方 PCI DSS 4.0.1 标准中的指南。

要求 2.2

为所有系统组件开发配置标准。

你的责任

在 Azure 云安全基准中实施建议。 它提供 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 节点、跳转盒、生成代理和其他与群集交互的组件。

Azure 责任

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

要求 2.2.1

为每个服务器仅实现一个主函数，以防止需要不同安全级别的函数在同一服务器上共存。 （例如，应在单独的服务器上实现 Web 服务器、数据库服务器和 DNS。

你的责任

关键策略是提供所需的分段级别。 一种方法是在单独的群集中部署作用域内和范围外组件。 了解这会导致增加的基础结构成本和维护开销。 另一种方法是共同定位共享群集中的所有组件。 使用分段策略来保持分离。 例如，在群集中具有单独的节点池。

在参考实现中，第二种方法演示了部署到单个群集的微服务应用程序。 应用程序有两组服务：一组具有作用域内 Pod，另一组服务范围不足。 这两个集分布在两个用户节点池中。 使用 Kubernetes 污点时，作用域内和作用域外 Pod 将部署到单独的节点池，并且永远不会共享节点 VM。

对于容器技术，默认提供分段，因为只有一个容器实例负责系统中的一个函数。

每个工作负荷 Pod 都应使用自己的标识。 它不得继承任何群集级或节点级标识。

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

要求 2.2.2

仅根据系统函数的需要启用必要的服务、协议、守护程序等。

你的责任

在启用这些功能之前，请查看这些功能和影响。 默认设置可能包括不需要的功能，这些功能可能需要查看工作负荷。 例如，Azure 应用程序网关的默认 SSL 策略中的密码。 检查策略是否过于宽松。 建议仅选择所需的密码来创建自定义策略。

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

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

要求 2.2.3

为被视为不安全的任何必需服务、协议或守护程序实现其他安全功能。

你的责任

应用程序网关具有集成的 WAF，并协商发送到其公共终结点的请求的 TLS 握手，只允许安全密码。 引用实现仅支持 TLS 1.2 和批准的密码。

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

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

如果群集中的工作负荷不能遵循围绕安全符合性配置文件或其他控制（例如限制和配额）的组织策略，请确保记录异常。 必须监视以确保只执行预期的功能。

要求 2.2.4

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

你的责任

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

Open Policy 代理允许控制器与 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 节点直接放置在这些预配的主机中。 此体系结构选择具有显著的成本影响，需要仔细规划容量。 对于大多数方案来说，这并不常见。

后续步骤

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