PCI DSS 4.0.1 的 AKS 管控群集的风险评估和代码资产

本文介绍 Azure Kubernetes 服务（AKS）群集的风险评估和代码资产注意事项，这些群集运行工作负荷符合支付卡行业数据安全标准（PCI DSS 4.0.1）。

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

建议和示例是从此随附的参考实现中提取的：

下载此体系结构的 Visio 文件 。

下载此体系结构的 Visio 文件 。

Components

在本部分中，我们将重点介绍两种体系结构与 PCI DSS 4.0.1 所需的更新之间的差异，包括增强的分段、持续监视和安全软件开发做法。 如果不熟悉基线组件，请参阅 相关 Azure 服务 以获取产品文档的链接。

群集配置

以下部分重点介绍了基线体系结构的重大更改。

节点池分段

在此体系结构中，群集有两个用户节点池和一个系统节点池。 节点池的计算选择与基线体系结构中的计算选项保持不变。 与基线体系结构不同，每个节点池驻留在专用子网中，以在计算层之间提供添加的网络隔离边界。

PCI DSS 4.0.1 需要在作和连接方面将 PCI 工作负荷与其他工作负荷隔离。

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

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

在参考实现中，我们将微服务应用程序部署到单个群集来演示共享群集方法。 作用域内和范围外工作负荷在两个单独的用户节点池中分段。 应用程序有两组服务：一组具有作用域内 Pod，另一组服务范围不足。 这两个集分布在两个用户节点池中。 通过使用 Kubernetes 污点，范围内和作用域外 Pod 将部署到单独的节点，并且永远不会共享节点 VM 或网络 IP 空间。

入口控制器

基线体系结构使用 Traefik 进行入口控制。 在此参考体系结构中，我们改用 Nginx。 此更改说明可以根据工作负荷要求更改此组件。

专用 Kubernetes API 服务器

基线体系结构以公共模式部署了 AKS 群集。 这意味着与 AKS 托管的 Kubernetes API 服务器的所有通信都通过公共 Internet 进行。 此体系结构无法接受，因为 PCI DSS 4.0.1 禁止公开接触任何系统组件。 在此管控体系结构中，群集部署为专用群集。 到 Kubernetes API 服务器的网络流量仅限于专用网络。 API 服务器通过群集网络中的专用终结点公开。 使用网络安全组和其他内置功能进一步增强安全性。 网络 配置中介绍了这些内容。

Pod 安全性

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

避免通过部署清单中的标记引用映像。 请改用实际的映像 ID。 这样，就可以使用群集中运行的实际内容可靠地映射容器扫描结果。 可以通过 Azure Policy 强制执行映像名称，以在允许的正则表达式中包含映像 ID 模式。 使用 Dockerfile FROM 指令时，请遵循本指南。

网络配置

中心辐射都部署在单独的虚拟网络中，每个虚拟网络都部署在专用地址空间中。 默认情况下，任何两个虚拟网络之间不允许任何流量。 在网络中，通过创建子网来应用分段。

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

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

有多个 NSG 控制群集进出的流。 下面是一些示例：

• 群集节点池放置在专用子网中。 对于每个子网，都有 NSG 阻止对节点 VM 的任何 SSH 访问，并允许来自虚拟网络的流量。 来自节点池的流量仅限于虚拟网络。
• 来自 Internet 的所有入站流量都被 Azure 应用程序网关截获。 例如，NSG 规则确保：
  • 仅允许使用 HTTPS 流量。
  • 使用服务标记允许来自 Azure 控制平面的流量。 有关详细信息，请参阅 “允许访问几个源 IP”。
• 在具有 Azure 容器注册表代理的子网上，NSG 仅允许必要的出站流量。 例如，允许流量流向 Azure Key Vault、Microsoft Entra ID、Azure Monitor 和其他容器注册表需要通信的服务。
• 包含跳转框的子网适用于管理作。 跳转盒子网上的 NSG 规则仅允许从中心内的 Azure Bastion 进行 SSH 访问，以及有限的出站连接。 跳线框没有通用 Internet 访问权限，在子网 NSG 和 Azure 防火墙中均受控制。

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

使用网络策略的 Pod 到 Pod 安全性

此体系结构尝试尽可能多地实现Microsoft的“零信任”原则。

在用户提供的命名空间的a0005-ia0005-o实现中演示了零信任网络作为概念的示例。 每个工作负荷命名空间都应应用限制性 NetworkPolicy 。 策略定义将取决于在这些命名空间中运行的 Pod。 请确保考虑就绪情况、实时线和启动探测，并允许 Log Analytics 代理收集的指标。 考虑在工作负载中的端口上进行标准化，以便为允许的容器端口提供一致 NetworkPolicy 和 Azure Policy。

在某些情况下，群集中的通信并不可行。 并非所有用户提供的命名空间都可以使用零信任网络（例如， cluster-baseline-settings 不能使用一个）。

TLS 加密

基线体系结构提供 TLS 加密的流量，直到群集中的入口控制器，但 Pod 到 Pod 通信处于明确状态。 在此体系结构中，TLS 通过证书颁发机构（CA）验证扩展到 Pod 到 Pod 流量。 此 TLS 由服务网格提供，该服务网格在允许通信之前强制实施 mTLS 连接和验证。

实现使用 mTLS。 可以使用或不使用服务网格实现 mTLS 支持。 如果使用网格，请确保它与所选证书颁发者兼容。 此实现使用 Open Service Mesh。

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

Azure Key Vault 网络限制

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

Azure 应用程序网关不支持从使用专用链接公开的 Key Vault 实例中为 HTTP 侦听器采购 TLS 证书，因此实现在混合模型中部署 Key Vault。 它仍然使用专用链接进行支持的连接，但也允许对应用程序网关集成进行公共访问。 如果此混合方法不适合部署，请将证书管理过程移动到应用程序网关。 这将增加管理开销，但密钥保管库实例将完全隔离。

有关详细信息，请参阅以下资源：

• Azure 应用程序网关和 Key Vault 集成
• 使用 Azure CLI 创建具有 TLS 终止的应用程序网关

DDoS 防护

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

Azure DDoS 网络保护可保护基础结构和工作负载免受大规模欺诈性请求。 此类请求可能会导致服务中断或屏蔽另一个并发攻击。 Azure DDoS 网络保护的成本很高，通常在跨多个 IP 地址的多个工作负荷之间摊销。 与网络团队协作，协调工作负荷的覆盖范围。

标识和访问管理

根据角色的要求定义角色并设置访问控制。 将角色映射到范围尽可能窄的 Kubernetes作。 避免跨多个函数的角色。 如果由一个人填充多个角色，请为该人员分配与等效的作业功能相关的所有角色。 即使有一个人直接负责群集和工作负荷，也可以创建 Kubernetes ClusterRole，就像有单独的个人一样，然后分配单个个人所有相关角色。

最大程度地减少长期访问，尤其是对于与群集进行 SRE/Ops 交互等高影响帐户。 AKS 控制平面同时支持 Microsoft Entra ID Privileged Access Management （PAM） 实时 （JIT） 和 条件访问策略，该策略基于所构建的规则为特权访问提供额外的所需身份验证验证层。

有关使用 PowerShell 配置条件访问的更多详细信息，请参阅New-MgIdentityConditionalAccessPolicy和Get-MgIdentityConditionalAccessPolicyRemove-MgIdentityConditionalAccessPolicy。

磁盘加密

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

存储磁盘

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

请考虑将 BYOK 用于可能与群集交互的任何其他磁盘，例如 Azure Bastion 前端跳转框。 如果选择 BYOK，则 VM 和区域可用性的 SKU 选项将受到限制，因为所有 SKU 或区域都不支持此功能。

VM 主机

建议启用主机加密功能。 这将加密 VM 主机和任何临时作系统，或 VM 主机上缓存的数据磁盘。 有关详细信息，请参阅 VM 对基于主机的加密的支持。

此功能通过 Host-Based 加密 功能扩展到 AKS 代理节点的 VM 主机上存储的数据。 与 BYOK 类似，此功能可能会限制 VM SKU 和区域选择。

可以通过 Azure Policy 强制实施这些功能。

群集备份（状态和资源）

如果工作负荷需要群集内存储，则有一个可靠且安全的备份和恢复过程。 考虑 Azure 备份（对于 Azure 磁盘和 Azure 文件存储）等服务，以便备份和恢复任何服务 PersistentVolumeClaim。 如果备份系统支持本机 Kubernetes 资源，则存在一些优势。 可以将群集与已知状态相协调的主要方法补充为关键系统恢复技术的备份系统。 例如，它可以帮助在 Kubernetes 资源级别随时间推移检测和编录系统状态更改。

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

群集内备份系统在作期间应以高特权运行。 评估将备份代理引入群集的风险和好处。 代理功能是否与群集中的另一个管理解决方案重叠？ 无需扩展攻击面即可完成此任务所需的最小工具集是什么？

Azure Policy 注意事项

应用的 Azure 策略通常没有工作负载优化设置。 在实现中，我们将 Kubernetes 群集 Pod 安全限制标准应用于基于 Linux 的工作负载 计划，这是 内置策略计划之一。 此计划不允许优化设置。 请考虑导出此计划并为特定工作负荷自定义其值。 可以在一个自定义计划下包括所有 Gatekeeper deny Azure 策略，以及另一个计划下的所有 audit Azure 策略。 这样做会将阻止作从仅信息策略中分类。

请考虑在kube-system审核策略中包含策略和gatekeeper-system命名空间，以提高可见性。 在 拒绝 策略中包含这些命名空间可能会导致群集失败，因为配置不受支持。

可以通过设置一些 Azure Policy 警报来强制实施数据加密。 例如，可以使用警报强制实施 BYOK，以检测群集资源上没有 diskEncryptionSetID 的群集。 另一个策略可以检测是否启用了 agentPoolProfilesHost-Based 加密。 引用实现不使用群集中的任何磁盘，并且作系统磁盘是临时磁盘。 这两个示例策略都作为安全功能的提醒。 策略设置为 audit，而不是 block。

管理图像

对工作负荷使用无分发基础映像。 使用这些图像时，安全外围应用会最小化，因为删除补充图像（如 shell 和包管理器）。 一个好处是降低 CVE 命中率。

Azure 容器注册表支持满足 开放容器计划（OCI）映像格式规范的映像。 这与支持验证签名的允许控制器结合使用，可以确保仅运行使用私钥签名的映像。 有一些开源解决方案，例如 SSE Connaisseur 或 IBM Portieris，用于集成这些进程。

保护容器映像和其他 OCI 项目，因为它们包含组织的知识产权。 使用客户管理的密钥并加密注册表的内容。 默认情况下，数据使用服务管理的密钥进行静态加密，但有时需要客户管理的密钥来满足法规合规性标准。 将密钥存储在托管密钥存储（例如 Azure Key Vault）中。 由于你创建并拥有密钥，因此你负责与密钥生命周期相关的作，包括轮换和管理。 有关详细信息，请参阅 使用客户管理的密钥加密注册表。

Kubernetes API 服务器作访问

可以限制针对群集执行的命令，而无需基于跳转框生成作过程。 如果你有一个 IAM 封闭的 IT 自动化平台，请使用预定义的作来控制和审核作的类型。

生成代理

管道代理应与受监管的群集不一致，因为生成进程可以是威胁向量。 例如，生成过程通常适用于未经测试和不受信任的组件。

虽然通常使用 Kubernetes 作为弹性生成代理基础结构，但不要在受管制工作负荷运行时的边界内运行该进程。 生成代理不应直接访问群集。 例如，仅向生成代理提供对 Azure 容器注册表的网络访问权限，以推送容器映像、Helm 图表等。 然后，通过 GitOps 进行部署。 作为一种常见做法，生成和发布工作流不应直接访问 Kubernetes 群集 API（或其节点）。

监视作

群集内活动

正在运行kube-system的群集omsagent内 Pod 是 Log Analytics 收集代理。 它们收集遥测、擦除容器 stdout 和 stderr 日志，并收集 Prometheus 指标。 可以通过更新 container-azm-ms-agentconfig.yaml ConfigMap 文件来优化其集合设置。 在此参考实现中，会跨 kube-system 所有工作负荷启用日志记录。 默认情况下， kube-system 从日志记录中排除。 确保调整日志收集过程以实现平衡成本目标、查看日志时 SRE 效率以及合规性需求。

安全监视

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

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

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

有关完整观点，请参阅 Microsoft Defender for Cloud Enterprise 载入指南。 本指南介绍注册、数据导出到 SIEM 解决方案、响应警报和生成工作流自动化。

相关 Azure 服务

下面是此体系结构的一些关键组件的功能文档的链接：

• Azure Kubernetes 服务 (AKS)
• Azure 防火墙
• Azure Bastion
• Azure 映像生成器
• Azure 虚拟机规模集
• 具有集成 Web 应用程序防火墙的 Azure 应用程序网关（WAF）
• Azure 容器注册表任务
• Azure Key Vault

后续步骤

安装和维护防火墙配置以保护持卡人数据。 不要将供应商提供的默认值用于系统密码和其他安全参数。