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

本文是系列文章的一部分。阅读介绍。

PCI-DSS 3.2.1标准的主题是安全性。轮辐拓扑是建立受监管网络环境的自然选择。创建允许安全通信的基础设施更容易。网络控制被放置在两个中心辐射网络中，并遵循微软的零信任模型。这些控件可以以最小权限进行调整，以保护流量，在需要知道的基础上提供访问权限。此外，您可以通过在每个网络跳和层添加控件来应用多种深度防御方法。

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

重要事项

该指南和附带的实现建立在AKS基线架构的基础上。该架构基于中心辐射网络拓扑。集线器虚拟网络包含控制出口流量的防火墙、来自本地网络的网关流量和用于维护的第三个网络。辐条虚拟网络包含提供持卡人环境（CDE）并承载PCI DSS工作负载的AKS集群。

GitHub徽标GitHub：Azure Kubernetes服务（AKS）受监管工作负载的基线集群展示了受监管的基础设施。该实现说明了CDE中各种网络和安全控制的使用。这包括Azure原生的网络控件和Kubernetes原生的控件。它还包括一个应用程序，用于演示环境和示例工作负载之间的交互。本文的重点是基础设施。该示例并不表示实际的PCI-DSS 3.2.1工作负载。

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

要求1--安装和维护防火墙配置以保护持卡人数据

AKS功能支持

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

Azure防火墙可以与AKS集成，并可以限制来自集群的出站流量，这是CDE的关键组件。使用AKS FQDN标签可以轻松配置。建议的流程在使用Azure防火墙保护Azure Kubernetes服务（AKS）部署中提供。

AKS集群需要一些公共互联网接入。使用群集子网上的Azure防火墙和NSG限制到internet的出站流量。有关信息，请参阅Azure Kubernetes Service（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网络策略插件都是开源的。有关Calico项目的更多信息，请参阅全面的PCI解决方案白皮书，该白皮书解决了以下许多防火墙要求。

你的责任

 

Requirement	Responsibility
Requirement 1.1	Establish and implement firewall and router configuration standards.
Requirement 1.2	Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment.
Requirement 1.3	Prohibit direct public access between the Internet and any system component in the cardholder data environment.
Requirement 1.4	Install personal firewall software or equivalent functionality on any portable computing devices (including company and/or employee-owned) that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the CDE.
Requirement 1.5	Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties.

要求1.1

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

要求1.1.1

批准和测试所有网络连接以及防火墙和路由器配置更改的正式流程。

你的责任

不要手动实现配置，例如直接使用Azure门户或Azure CLI。我们建议使用基础设施即代码（IaC）。使用IaC，基础设施通过使用版本控制系统的描述性模型进行管理。IaC模型每次应用时都会生成相同的环境。IaC的常见示例是二头肌、Azure资源管理器模板（ARM模板）或地形。如果IaC不是一种选择，那么就有一个记录良好的流程来跟踪、实施和安全部署防火墙规则更改。更多细节作为要求11.2的一部分提供。

您需要使用各种网络控件的组合，包括Azure防火墙、网络安全组（NSG）和Kubernetes NetworkPolicy资源。

尽量减少可以访问和修改网络控件的人数。为团队定义角色并明确职责。例如，组织的网络团队将根据IT团队制定的治理策略验证更改。有一个封闭的审批流程，涉及人员和流程来批准对任何网络配置的更改。该过程应包括测试所有网络控制的步骤。有描述该过程的详细文件。

要求1.1.2

识别持卡人数据环境和其他网络（包括任何无线网络）之间所有连接的当前网络图

你的责任

作为文档的一部分，维护一个网络流图，显示具有安全控制的传入和传出流量。这包括从其他网络（包括任何无线网络）到CDE的流量。该图还应显示集群内的流。图表有一些具体要求，包括它们应该显示入侵传感器和应用的任何控制。

此图显示了参考实现的网络图。

网络拓扑图。

下载此图表的Visio文件。

图1.1.2-网络流

此流程的描述见以下章节。

如果您有Azure network Watcher，则可以查看Azure虚拟网络的拓扑。您可以查看虚拟网络中的所有资源、与虚拟网络中资源关联的资源以及资源之间的关系。

要求1.1.3

显示系统和网络中所有持卡人数据流的电流图。

你的责任

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

该图应显示数据如何流入和流出工作负载，以及哪些信息从一个资源传递到另一个资源。确保图表保持最新。在变更管理流程中添加一个步骤，以更新数据流图。

因为这种架构侧重于基础设施而不是工作负载，所以我们在这里省略了说明。

要求1.1.4

在每个互联网连接处以及任何非军事区（DMZ）和内部网络区之间设置防火墙的要求。

你的责任

明确非军事区边界的定义。例如，持卡人数据环境（CDE）可能位于由防火墙、网络策略和其他控制措施保护的DMZ内。有关更多信息，请参阅Cloud DMZ。

对于PCI DSS基础架构，您有责任通过使用网络控制来阻止未经授权访问包含CDE的网络，从而保护CDE的安全。网络控制必须正确配置，以实现强大的安全态势，并且必须应用于：

• 集群内托管组件之间的通信。
• 工作负载和可信网络中的其他组件之间的通信。
• 工作负载和公共互联网之间的通信。

此架构使用不同的防火墙技术来检查流向和来自承载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、网守系统和其他由AKS提供的命名空间除外）都应用了限制性网络策略。策略定义取决于在这些命名空间中运行的Pod。确保你为准备、活力和启动探索开辟了道路。此外，打开oms代理的路径，以便可以发送节点级指标。考虑跨工作负载标准化端口，以便为允许的容器端口提供一致的NetworkPolicy和Azure Policy。

要求1.1.5

网络组件管理的组、角色和职责的描述。

你的责任

您需要提供对网络流和相关组件的控制。由此产生的基础设施将有几个网段，每个网段都有许多控件，每个控件都有一个目的。确保您的文档覆盖范围广泛，从网络规划到应用的所有配置。它还应包括所有权的详细信息，明确责任线和负责责任的角色。

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

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

总是从否认所有策略开始。仅在有业务需求或角色正当性时才授予权限。

要求1.1.6

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

你的责任

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

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

Rule	Protocol:Port	Source	Destination	Justification
Allow secure communication between the nodes and the control plane.	HTTPS:443	Authorized IP address ranges assigned to the cluster node pools	List of FQDN targets in the AKS control plane. This is specified with the AzureKubernetesService FQDN tag.	The nodes need access to the control plane for management tools, state and configuration information, and information about which nodes can be scaled.
Allow secure communication between Flux and GitHub.	HTTPS:443	AKS node pools	github.com, api.github.com	Flux is a third-party integration that runs on the nodes. It synchronizes cluster configuration with a private GitHub repository.

要求1.1.7

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

你的责任

至少每六个月进行一次流程，以审查网络配置和范围规则。这将确保安全保证是最新和有效的。请确保您查看了这些配置：

• Azure防火墙规则。
• NSG规则。
• Azure应用程序网关和WAF规则。
• 原生Kubernetes网络策略。
• 适用Azure资源上的防火墙控制。例如，此架构使用Azure容器注册表上的一条规则，该规则只允许来自私有端点的流量。
• 您添加到架构中的任何其他网络控件。

如果自上次审查以来，您已经停用了任何工作负载或更改了集群的配置，那么验证您对所需防火墙例外或NSG规则的任何假设仍然有效非常重要。

要求1.2

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

你的责任

在这种架构中，AKS集群是持卡人数据环境（CDE）的关键组件。我们强烈建议将该集群部署为私有集群，以增强安全性。在私有集群中，AKS-managed Kubernetes API服务器和节点池之间的网络流量是私有的。API服务器通过群集网络中的专用端点公开。

您也可以选择公共集群，但不建议将此设计用于包含受监管工作负载的集群。API服务器将暴露在互联网上。DNS记录始终是可发现的。因此，您需要有控件来保护集群API免受公共访问。如果需要使用公共集群，那么推荐的方法是通过Kubernetes基于角色的访问控制（RBAC）进行严格控制，并结合AKS授权IP范围功能来限制谁可以访问AKS API服务器。但是，不建议将此解决方案用于包含受监管工作负载的集群。

在处理持卡人数据（CHD）时，集群需要与被认为是可信和不可信的网络进行交互。在这种架构中，PCI-DSS 3.2.1工作负载范围内的中心辐射网络都被认为是可信网络。

不受信任的网络是指该边界之外的网络。不受信任的网络包括：

• 其他集线器和辐条可能位于同一基础设施上，但不在工作负载范围内。
• 公共互联网。
• 企业网络。
• Azure或其他云平台中的其他虚拟网络。

在这种架构中，承载映像构建器的虚拟网络是不可信的，因为它在CHD处理中没有任何作用。CDE与此类网络的交互应按照要求进行保护。有了这个私有集群，您可以使用虚拟网络、NSG和其他内置功能来保护整个环境。

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

要求1.2.1

将入站和出站流量限制在持卡人数据环境所需的范围内，并特别拒绝所有其他流量。

你的责任

根据设计，Azure虚拟网络不能直接从公共互联网访问。所有入站（或入口）流量必须通过中间流量路由器。但是，默认情况下，网络中的所有组件都可以到达公共端点。您可以通过配置专用子网或使用UDR通过防火墙发送所有出站流量来禁用该行为。必须明确保护出站（或出口）流量，只允许使用安全密码和TLS 1.2或更高版本。

Azure应用程序网关的集成WAF拦截所有HTTP（s）入口流量，并将检查到的流量路由到集群。

此流量可能来自受信任或不受信任的网络。应用网关在辐射网络的子网中配置，并由NSG保护。随着流量的流入，WAF规则允许或拒绝，Application Gateway将流量路由到配置的后端。例如，Application Gateway通过拒绝此类流量来保护CDE：

• 所有未经TLS加密的流量。
• 来自Azure基础架构的控制平面通信端口范围之外的流量。
• 由群集中内部负载平衡器以外的实体发送的健康探测请求。
• Azure防火墙用于保护来自可信和不可信网络的所有出站（出口）流量。

Azure防火墙是在集线器网络的子网中配置的。为了将Azure防火墙强制作为单个出口点，在能够生成出口流量的子网上使用用户定义的路由（UDR）。这包括不受信任的网络中的子网，如映像生成器虚拟网络。流量到达Azure防火墙后，将应用多个作用域规则，允许来自特定源的流量流向特定目标。

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

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

除了防火墙，一些组织可能希望使用HTTP代理对出口进行额外控制。我们建议您仍然将用户定义的路由转到防火墙，并将出口流量限制为只转到HTTP代理。通过此设置，如果pod试图覆盖代理，那么防火墙仍然可以阻止出口流量。

有关更多信息，请参阅Azure Kubernetes Service中的HTTP代理支持。

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

与其他Azure服务端点的交互是通过Azure骨干网进行的。例如，作为常规操作的一部分，集群需要从托管密钥存储中获取证书，从容器注册表中提取映像等。使用Azure private Link确保这些交互是私有和安全的。

除了防火墙规则和专用网络外，流量也通过NSG规则得到保护。这里有一些来自这种架构的例子，其中CDE通过拒绝流量来保护：

• 具有节点池的子网上的NSG拒绝对节点的任何SSH访问。确保您有一个及时紧急访问的流程，同时仍然保持拒绝所有原则。
• 子网上具有用于运行管理工具的跳转框的NSG会拒绝集线器网络中除Azure Bastion之外的所有流量。
• 拥有Azure密钥库和Azure容器注册表专用终结点的子网上的NSG拒绝所有流量，但内部负载平衡器和Azure专用链接上的流量除外。
   

要求1.2.2

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

你的责任

有一个机制来检测实际部署状态和所需状态之间的差异。基础设施即代码（IaC）是实现这一目的的绝佳选择。例如，二头肌文件或Azure资源管理器模板（ARM模板）维护所需状态的记录。

部署资源（如二头肌文件）必须受到源代码控制，以便您拥有所有更改的历史记录。从Azure活动日志、部署管道日志和Azure部署日志中收集信息。这些来源将帮助您跟踪部署的资产。

在集群中，Kubernetes网络策略等网络控制也应遵循源代码控制流。在这个实现中，Flux被用作GitOps操作符。当您同步集群配置（如网络策略）时，您的Git历史记录与Flux和API日志相结合可以成为配置历史记录源。

要求1.2.3

在所有无线网络和持卡人数据环境之间安装外围防火墙，并将这些防火墙配置为拒绝，或者如果业务目的需要流量，则只允许无线环境和持卡人信息环境之间的授权流量。

你的责任

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

一般来说，限制从本地流量到辐射网络的访问。

要求1.3

禁止互联网和持卡人数据环境中的任何系统组件之间的直接公共访问。

你的责任

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

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

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

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

要求1.3.1

实施DMZ以将入站流量限制为仅提供授权的公共访问服务、协议和端口的系统组件。

你的责任

以下是一些最佳实践：

不要在节点池节点上配置公共IP地址。
使用Azure策略确保Kubernetes不公开公共负载平衡器。集群内的流量必须通过内部负载均衡器路由。
仅将内部负载平衡器暴露给与WAF集成的Azure应用程序网关。
所有网络控制应指定源、目标、端口和协议限制（如适用）。
请勿将API服务器暴露于互联网。当您在专用模式下运行集群时，端点不会暴露，节点池和API服务器之间的通信通过专用网络进行。
用户可以实施外围网络来保护AKS集群。有关信息，请参阅Cloud DMZ。

要求1.3.2

将入站互联网流量限制在DMZ内的IP地址。

你的责任

在集群网络中，在子网上有一个带有内部负载均衡器的NSG。将规则配置为仅接受来自已将Azure应用程序网关与WAF集成的子网的流量。在AKS集群中，使用Kubernetes NetworkPolicies来限制Pod的入口流量。

要求1.3.3

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

Azure职责

Azure实施了网络过滤，以防止欺骗流量，并将传入和传出流量限制在受信任的平台组件上。

要求1.3.4

不允许从持卡人数据环境到互联网的未经授权的出站流量。

你的责任

以下是阻止未经授权的出站流量的方法：

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

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

有关详细信息，请参阅Azure Kubernetes Service（AKS）中群集节点的控制出口流量。

要求1.3.5

只允许“已建立”的连接进入网络。

Azure职责

Azure实施了网络过滤，以防止欺骗流量，并将传入和传出流量限制在受信任的平台组件上。Azure网络是隔离的，将客户流量与管理流量分开。

要求1.3.6

将存储持卡人数据的系统组件（如数据库）放置在与DMZ和其他不受信任的网络隔离的内部网络区域中。

你的责任

仅通过专用网络（例如使用private Link）公开存储系统。此外，限制需要它的节点池子网的访问。将状态排除在群集中，并保留在其自己的专用安全区域中。

要求1.3.7

不要将私有IP地址和路由信息泄露给未经授权的方。

你的责任

为了满足这一要求，公共AKS集群不是一种选择。私有集群通过使用私有DNS区域将DNS记录与公共互联网隔离开来。但是，仍然可以使用公共DNS地址创建私有的AKS集群。因此，建议通过将enablePrivateClusterPublicFQDN设置为false来显式禁用此功能，以防止控制平面的私有IP地址泄露。考虑使用Azure策略强制使用没有公共DNS记录的私有集群。

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

通过Private Link连接的Azure服务没有公开您的私有IP地址的公共DNS记录。您的基础设施应充分利用Private Link。

要求1.4

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

你的责任

私有集群由AKS控制平面管理。您无法直接访问节点。为了执行管理任务，您需要从单独的计算资源中使用kubectl等管理工具。一种选择是使用气隙跳跃框，您可以在其中运行命令。此外，必须限制和保护来自跳转框的入站和出站流量。如果使用VPN进行访问，请确保客户端计算机由公司策略管理，并且所有条件访问策略都已到位。

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

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

要求1.5

确保管理防火墙的安全策略和操作程序被记录、使用，并为所有受影响的各方所知。

你的责任

对流程和政策进行全面的文档记录至关重要。当您管理分割AKS集群的Azure防火墙规则时，尤其如此。操作受监管环境的人员必须接受教育、了解情况并受到激励，以支持安全保证。对于拥有被授予广泛管理权限的帐户的人来说，这一点尤为重要。

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

你的责任

 

Requirement	Responsibility
Requirement 2.1	Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.
Requirement 2.2	Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
Requirement 2.3	Encrypt all non-console administrative access using strong cryptography.
Requirement 2.4	Maintain an inventory of system components that are in scope for PCI DSS.
Requirement 2.5	Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties.
Requirement 2.6	Shared hosting providers must protect each entity's hosted environment and cardholder data.

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

要求2.1

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

你的责任

必须更改供应商提供的默认设置。默认设置是常见的攻击媒介，使系统容易受到攻击。以下是一些考虑因素：

禁用容器注册表上的管理员访问权限。
确保跳转框和构建代理遵循用户管理程序，删除不需要的系统用户。
不要为管理员用户生成或提供对节点的SSH密钥访问。如果需要紧急访问，请使用Azure恢复过程获得即时访问。
Azure职责
Microsoft Entra ID具有对用户提供的新密码强制执行的密码策略。如果更改密码，则需要验证旧密码。用户下次登录时，需要更改管理员重置的密码。

要求2.1.1

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

你的责任

这种架构和实现不是为了通过无线连接进行本地或企业网络到云的交易而设计的。有关注意事项，请参阅官方PCI-DSS 3.2.1标准中的指导。

要求2.2

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

你的责任

实施微软云安全基准中的建议。它提供了一个单一的、整合的Azure安全建议视图，涵盖了CIS、NIST、PCI-DSS 3.2.1等行业框架。使用Microsoft Defender for Cloud功能和Azure策略来帮助跟踪标准。Azure安全基准测试是Microsoft Defender for Cloud的默认举措。考虑在Azure策略和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

为任何被认为不安全的所需服务、协议或守护进程实施额外的安全功能。

你的责任

Application Gateway具有集成的WAF，并为发送到其公共端点的请求协商TLS握手，只允许使用安全密码。参考实现仅支持TLS 1.2和批准的密码。

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

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

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

要求2.2.4

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

你的责任

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

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

在基础架构级别，您可以对Azure资源的类型和配置应用限制。使用Azure策略防止配置错误。在这个参考实现中，有一个策略拒绝创建非私有的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 Service (AKS) architecture design
• Introduction of an AKS regulated cluster for PCI-DSS 3.2.1 (Part 1 of 9)
• Architecture of an AKS regulated cluster for PCI-DSS 3.2.1 (Part 2 of 9)
• Baseline architecture for an Azure Kubernetes Service (AKS) cluster
• AKS baseline for multiregion clusters