【Azure AKS】PCI-DSS

语言 Chinese, Simplified

SEO Title

Architecture of an AKS regulated cluster for PCI-DSS 3.2.1 (Part 2 of 9)

组件

以下是此架构中使用的主要组件。如果您不熟悉这些服务，请参阅相关Azure服务以获取产品文档的链接。

Azure防火墙

防火墙实例保护出站网络流量。如果没有这一层安全性，该流可能会与可能泄露敏感公司数据的恶意第三方服务进行通信。

Azure堡垒

基线架构为Azure Bastion提供了一个子网，但没有提供资源。此架构在子网中添加了Azure Bastion，并提供了对跳转框[jump box]的安全访问。

Azure映像生成器

它部署在单独的虚拟网络中，创建具有基本安全性和配置的VM映像。在此架构中，它被定制为使用预装的Azure CLI、kubectl和Flux CLI等管理工具构建安全节点映像。

跳转框实例的Azure虚拟机规模集[Azure Virtual Machine Scale Sets for jump box instances]

轮辐网络为跳跃盒提供了额外的计算。此规模集旨在作为受管的访问点，以便根据需要对AKS集群运行工具，如kubectl。

具有集成Web应用程序防火墙（WAF）的Azure应用程序网关

Azure应用程序网关在第7层的负载平衡。WAF保护传入流量免受常见网络流量攻击。该实例具有接收用户请求的公共前端IP配置。

Azure Kubernetes服务（AKS）

托管基础设施是持卡人数据环境（CDE）的关键部分。AKS集群被部署为私有集群。因此，Kubernetes API服务器不会暴露在公共互联网上，API服务器的流量仅限于您的专用网络。

ACR任务

提供了一种构建和维护容器映像的自动化方法。

Azure密钥库

存储和管理集群操作所需的机密，如证书和加密密钥。

集群配置

以下是与基线架构相比的一些重大变化：

节点池分段

在这种架构中，集群有两个用户节点池和一个系统节点池。节点池的计算选择与基线架构中的相同。与基线架构不同，每个节点池都位于专用子网中，以在计算层之间提供额外的网络隔离边界。

注：

另一种计算保护方法是Azure机密计算。AKS支持机密计算节点，允许您在基于硬件的可信执行环境（TEE）中运行敏感工作负载。有关详细信息，请参阅Azure Kubernetes Service上的机密计算节点。

PCI-DSS 3.2.1要求在操作和连接方面将PCI工作负载与其他工作负载隔离。

范围：PCI工作负载、它所在的环境和操作。
范围外：可能共享服务但与范围内组件隔离的其他工作负载。

关键策略是提供所需的分离水平。首选方法是在单独的集群中部署范围内和范围外组件。使用多个集群的缺点是增加基础设施的成本和维护开销更高。为了简单起见，此实现将所有组件放在共享集群中。如果您选择遵循单集群模型，请使用严格的集群内分割策略。无论您选择如何保持分离，请注意，随着解决方案的发展，一些超出范围的组件可能会进入范围。

在参考实现中，我们通过将微服务应用程序部署到单个集群来演示共享集群方法。范围内和范围外的工作负载被分为两个单独的用户节点池。该应用程序有两组服务；一组有作用域内的pod，另一组不在作用域内。这两个集合分布在两个用户节点池中。通过使用Kubernetes污点，作用域内和作用域外的Pod被部署到单独的节点上，它们从不共享节点VM或网络IP空间。

入口控制器

基线架构使用Traefik进行入口控制。在这个参考架构中，我们使用Nginx。这一变化表明，可以根据工作负载的要求更改此组件。

私有Kubernetes API服务器

基线架构以公共模式部署了AKS集群。这意味着所有与AKS-managed Kubernetes API服务器的通信都是通过公共互联网进行的。这在这种架构中是不可接受的，因为PCI-DSS 3.2.1禁止公众接触任何系统组件。在这种受监管的架构中，集群被部署为私有集群。Kubernetes API服务器的网络流量仅限于您的专用网络。API服务器通过群集网络中的专用端点公开。通过使用网络安全组和其他内置功能，进一步增强了安全性。这些在网络配置中进行了描述。

Pod安全

在描述工作负载的安全需求时，请为容器使用相关的securityContext设置。这包括基本设置，如fsGroup、runAsUser/runAsGroup，以及将allowPrivilegeEscalation设置为false（除非需要）。在seLinuxOptions中明确定义和删除Linux功能以及定义SELinux选项。

避免在部署清单中通过图像标签引用图像。相反，使用实际的图像ID。这样，您就可以将容器扫描结果与集群中运行的实际内容可靠地映射。您可以通过Azure策略强制映像名称在允许的正则表达式中包含映像ID模式。当您使用Dockerfile FROM指令时，也请遵循此指南。

网络配置

集线器辐条[hub-spokes ]都部署在单独的虚拟网络中，每个虚拟网络都位于其专用地址空间中。默认情况下，任何两个虚拟网络之间都不允许通信。在网络中，通过创建子网来应用分段。

各种Azure服务和功能以及本机Kubernetes构造的组合提供了所需的控制级别。以下是此架构中使用的一些选项。

网络配置图。

通过网络安全组（NSG）实现子网安全

有几个核供应国集团控制着集群的流入和流出。以下是一些示例：

群集节点池放置在专用子网中。对于每个子网，都有NSG阻止对节点VM的任何SSH访问，并允许来自虚拟网络的流量。来自节点池的流量仅限于虚拟网络。
来自互联网的所有入站流量都会被Azure应用程序网关拦截。例如，NSG规则确保：
- 只允许HTTPS流量进入。
- 使用服务标签允许来自Azure控制平面的流量。有关更多信息，请参阅允许访问几个源IP。
在具有Azure容器注册表代理的子网上，NSG只允许必要的出站流量。例如，允许访问Azure密钥库、Microsoft Entra ID、Azure Monitor和容器注册表需要与之通信的其他服务。
带有跳转框的子网用于管理操作。跳转箱子网上的NSG规则仅允许从集线器中的Azure Bastion进行SSH访问，并限制出站连接。跳转框没有通用的互联网接入，并且由子网NSG和Azure防火墙控制。

随着工作负载、系统安全代理和其他组件的部署，添加更多NSG规则来帮助定义应允许的流量类型。流量不应穿越这些子网边界。因为每个节点池都位于自己的子网中，所以要观察流量模式，然后应用更具体的规则。

具有网络策略的Pod到Pod安全

这种架构试图尽可能多地实现微软的“零信任”原则。

在a0005-i和a0005-o用户提供的命名空间中，零信任网络作为一个概念的示例在实现中得到了演示。每个工作负载命名空间都应该应用一个限制性的NetworkPolicy。策略定义将取决于在这些命名空间中运行的Pod。确保你考虑了准备就绪、活跃度和启动探测，并考虑到日志分析代理收集的指标。考虑跨工作负载对端口进行标准化，以便为允许的容器端口提供一致的NetworkPolicy和Azure Policy。

在某些情况下，这对于集群内的通信是不切实际的。并非所有用户提供的命名空间都可以使用零信任网络（例如，集群基线设置不能使用）。

TLS加密

基线架构提供TLS加密的流量，直到集群中的入口控制器，但pod到pod的通信是畅通的。在这种架构中，TLS扩展到pod到pod流量，并进行证书颁发机构（CA）验证。TLS由服务网格提供，该网格在允许通信之前强制执行mTLS连接和验证。

网络配置图。

该实现使用mTLS。mTLS支持可以在有或没有服务网格的情况下实现。如果使用网格，请确保它与您选择的证书颁发者兼容。此实现使用开放服务网格。

当入口资源不包含特定证书时，此实现中的入口控制器使用通配符证书来处理默认流量。这可能是可以接受的，但如果您的组织策略不允许使用通配符证书，您可能需要调整您的入口控制器，使其不使用通配符证书。

重要事项

任何解密持卡人数据的组件都被认为在PCI-DSS 3.2.1的范围内，并且与持卡人数据环境中的其他组件受到相同级别的审查。在此架构中，Azure应用程序网关处于作用域内，因为它将有效负载作为其WAF功能的一部分进行检查。另一种架构选项是使用Azure Firewall Premium作为入口组件，而不是WAF，以利用Azure防火墙基于签名的IDPS功能。这将允许第一个TLS终止位于集群中。但是，如果没有专用的WAF，您必须使用额外的补偿控制来满足要求6.6。

Azure密钥库网络限制

所有秘密、密钥和证书都存储在Azure密钥库中。密钥库处理证书管理任务，如轮换。与密钥库的通信是通过Azure专用链接进行的。与密钥库关联的DNS记录位于专用DNS区域中，因此无法从internet解析。虽然这增强了安全性，但也有一些限制。

Azure应用程序网关不支持从通过Private Link公开的密钥库实例中为HTTP侦听器获取TLS证书。因此，该实现在混合模型中部署了密钥库。它仍然使用Private Link进行支持它的连接，但也允许对Application Gateway集成进行公共访问。如果这种混合方法不适合您的部署，请将证书管理过程移动到Application Gateway。这将增加管理开销，但密钥库实例将被完全隔离。有关信息，请参阅：

DDoS防护

如果您有任何具有公共IP地址的虚拟网络，请启用Azure DDoS网络保护。在此参考架构中，包含应用程序网关的子网附加了一个公共IP地址，因此它在DDoS保护范围内。

Azure DDoS网络保护可保护基础架构和工作负载免受大规模欺诈请求的影响。此类请求可能会导致服务中断或掩盖另一次并发攻击。Azure DDoS网络保护的成本很高，通常在跨越许多IP地址的许多工作负载中摊销。与您的网络团队合作，协调工作负载的覆盖范围。

身份和访问管理

根据角色的要求定义角色并设置访问控制。将角色映射到Kubernetes操作，范围尽可能窄。避免跨多个功能的角色。如果一个人担任多个角色，请为该人分配与同等工作职能相关的所有角色。因此，即使一个人直接负责集群和工作负载，也要像有单独的个人一样创建Kubernetes ClusterRoles。然后为该个体分配所有相关角色。

尽量减少长期访问，特别是对于高影响的客户，例如与集群的SRE/Ops交互。AKS控制平面支持Microsoft Entra ID特权访问管理（PAM）即时（JIT）和条件访问策略，后者根据您构建的规则为特权访问提供了额外的身份验证层。

有关使用PowerShell配置条件访问的更多详细信息，请参阅新建MgIdentityConditionalAccessPolicy、获取MgIdentityConditionalAccessPolicy和删除MgIdentityConditionalAccessPolicy。

磁盘加密

当您为静态数据设计加密时，请考虑存储磁盘、AKS代理节点VM、其他VM以及任何临时和操作系统磁盘。

存储磁盘

默认情况下，Azure存储磁盘在静止时使用Microsoft管理的密钥进行加密。如果您使用非临时操作系统磁盘或添加数据磁盘，我们建议您使用客户管理的密钥来控制加密密钥。在存储层外加密，只将加密数据写入存储介质。此外，请确保密钥永远不会与存储层相邻。有关更多信息，请参阅使用Azure磁盘自带密钥（BYOK）。

考虑对可能与集群交互的任何其他磁盘使用BYOK，例如您的Azure Bastion前置跳转框。如果选择“确定”，则VM的SKU选择和区域可用性将受到限制，因为并非所有SKU或区域都支持此功能。

VM主机

我们建议您启用主机加密功能。这将加密VM主机和任何临时操作系统，或缓存在VM主机上的数据磁盘。阅读更多关于VM支持基于主机的加密的信息。

该功能通过基于主机的加密功能扩展到存储在AKS代理节点的VM主机上的数据。与BYOK类似，此功能可能会限制您的VM SKU和地区选择。

您可以通过Azure策略强制执行这些功能。

群集备份（状态和资源）

如果您的工作负载需要集群内存储，请拥有一个强大而安全的备份和恢复过程。考虑Azure Backup（用于Azure磁盘和Azure文件）等服务，用于备份和恢复任何PersistentVolumeClaim。如果备份系统支持本机Kubernetes资源，则会有优势。您可以使用关键系统恢复技术的备份系统来补充将集群协调到已知状态的主要方法。例如，它可以帮助在Kubernetes资源级别进行漂移检测和编目系统状态随时间的变化。

备份过程需要对备份中的数据进行分类，无论这些数据是来自集群还是来自集群外部。如果数据在PCI DSS 3.2.1的范围内，请扩展您的合规性边界，以包括备份的生命周期和目标，这将在集群之外。备份可能是攻击向量。在设计备份时，请考虑地理限制、静态加密、访问控制、角色和职责、审计、生存时间和防篡改。

群集中备份系统在运行过程中应以高权限运行。评估将备份代理引入集群的风险和收益。代理功能是否与集群中的另一个管理解决方案重叠？在不扩大攻击面的情况下，完成这项任务所需的最小工具集是什么？

Azure策略注意事项

通常，应用的Azure策略没有工作负载调优设置。在实施过程中，我们正在为基于Linux的工作负载计划应用Kubernetes集群pod安全限制标准，这是内置的策略计划之一。此计划不允许调整设置。考虑导出此计划并为您的特定工作负载自定义其值。您可以将所有Gatekeeper拒绝Azure策略包含在一个自定义计划下，并将所有审核Azure策略包含到另一个计划下。这样做会将阻止操作从仅限信息的策略中分类。

考虑将kube-system和gatekeeper系统命名空间包含在审计策略中的策略中，以增加可见性。由于配置不受支持，在拒绝策略中包含这些命名空间可能会导致群集失败。

您可以通过设置一些Azure策略警报来强制数据加密。例如，您可以通过检测群集资源上没有diskEncryptionSetID的群集的警报来强制执行BYOK。另一个策略可以检测agentPoolProfiles上是否启用了基于主机的加密。参考实现不使用群集中的任何磁盘，操作系统磁盘是临时的。这两个示例策略都是为了提醒安全功能而制定的。这些策略设置为审核，而不是阻止。

管理图像

为您的工作负载使用无分发基础映像。通过这些图像，安全表面积被最小化，因为补充图像（如外壳和包管理器）被删除了。一个好处是降低CVE命中率。

Azure容器注册表支持符合开放容器计划（OCI）映像格式规范的映像。再加上支持验证签名的准入控制器，可以确保您只运行用私钥签名的映像。有开源解决方案，如SSE Connaisseur或IBM Portieris，可以集成这些流程。

保护容器映像和其他OCI工件，因为它们包含组织的知识产权。使用客户管理的密钥并加密注册表的内容。默认情况下，数据在静态时使用服务管理的密钥进行加密，但有时需要客户管理的密钥来满足监管合规标准。将密钥存储在托管密钥存储中，如Azure密钥库。因为您创建并拥有密钥，所以您负责与密钥生命周期相关的操作，包括轮换和管理。有关更多信息，请参阅使用客户管理的密钥加密注册表。

Kubernetes API服务器操作访问

带有跳转框的Kubernetes API服务器操作访问图。

您可以限制对集群执行的命令，而不必围绕跳转框构建操作流程。如果您有IAM门控的IT自动化平台，请使用预定义的操作来控制和审核操作类型。

构建代理

管道代理应该不在受监管集群的范围内，因为构建过程可能是威胁媒介。例如，构建过程通常使用未经测试和不受信任的组件。

虽然使用Kubernetes作为弹性构建代理基础设施很常见，但不要在受监管的工作负载运行时的边界内运行该过程。您的构建代理不应该直接访问集群。例如，只授予构建代理对Azure容器注册表的网络访问权限，以推送容器映像、舵图等。然后，通过GitOps进行部署。作为一种常见的做法，构建和发布工作流不应该直接访问您的Kubernetes Cluster API（或其节点）。

监控操作

集群内活动

在kube系统中运行的集群内omsagent Pod是日志分析收集代理。他们收集遥测数据，抓取容器stdout和stderr日志，并收集Prometheus指标。您可以通过更新container-azm-ms-agentconfig.yaml ConfigMap文件来调整其收集设置。在这个参考实现中，跨kube系统和所有工作负载启用了日志记录。默认情况下，kube-system被排除在日志记录之外。确保您正在调整日志收集流程，以实现平衡成本目标、审查日志时的SRE效率以及合规需求。

安全监控

使用Microsoft Defender for Cloud中的Defender for Containers查看和修正安全建议，并查看容器资源上的安全警报。启用Microsoft Defender计划，因为它们适用于持卡人数据环境的各个组件。

集成日志，以便您能够高效地查看、分析和查询数据。Azure提供了多种选项。您可以打开AKS诊断日志并将其发送到Azure Monitor中的日志分析工作区。另一种选择是将数据集成到安全信息和事件管理（SIEM）解决方案中，如Microsoft Sentinel。

根据标准要求，所有日志分析工作区都设置为90天的保留期。考虑建立长期存储的连续出口。不要将敏感信息存储在日志数据中，并确保对存档日志数据的访问受到与最近日志数据相同级别的访问控制。

有关完整的观点，请参阅《Microsoft Defender For Cloud Enterprise入门指南》。本指南涉及注册、数据导出到您的SIEM解决方案、响应警报和构建工作流自动化。

Next steps

Install and maintain a firewall configuration to protect cardholder data. Do not use vendor-supplied defaults for system passwords and other security parameters.

Build and maintain a secure network and systems

本文地址

https://architect.pub/architecture-aks-regulated-cluster-pci-dss-321-part-2-9

登录发表评论
2 次浏览

发布日期

星期六, 九月 21, 2024 - 11:21

最后修改

星期六, 九月 21, 2024 - 11:39

热门内容

今日:

总体:

最近浏览：