PCI DSS 4.0.1 的 AKS 管控群集的恶意软件防护

本文介绍根据支付卡行业数据安全标准（PCI DSS 4.0.1）配置的 Azure Kubernetes 服务（AKS）群集的恶意软件保护注意事项。

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

与任何云解决方案一样，PCI 工作负荷受网络、标识和数据威胁的影响。 PCI DSS 4.0.1 扩展了恶意软件保护和漏洞管理的要求，尤其是在云和容器环境中。 尽早检测威胁，并及时响应缓解措施。 为工作负荷活动生成关键警报，并将这些警报扩展到核心系统进程。 防病毒、反恶意软件和文件完整性监视（FIM）工具 必须 始终运行。 有一个负责任的响应计划和一个团队，用于调查警报并采取措施。

维护漏洞管理计划

要求 5：保护所有系统和网络免受恶意软件的攻击

AKS 功能支持

AKS 的行为不像传统的应用程序主机。 AKS 群集中的节点 VM 具有有限的公开性，旨在不直接访问。 由于节点 VM 不等同于传统 VM，因此不能使用常见 VM 工具，因此本部分中的建议通过本机 Kubernetes 构造应用。 直接在 VM 级别应用这些要求可能会导致群集不受支持。

必须在 DaemonSets 中部署所选的反恶意软件，该软件将在每个节点上的 Pod 中运行。 PCI DSS 4.0.1 需要能够自动更新和实时保护的反恶意软件解决方案，包括容器化工作负载。

你的责任

确保软件专用于 Kubernetes 和容器。 有几个第三方软件选项。 热门选择包括 Prisma Cloud、Aquasec 和开源选项，如 Falco。 你有责任确保第三方软件是最新的，并且监视和警报已到位。 利用专为容器化环境设计的基于主机的恶意软件防护和运行时安全工具。 使用映像扫描工具在部署之前持续监视容器映像是否存在漏洞和恶意软件。

要求 5.1

在所有通常受恶意软件（特别是个人计算机和服务器）影响的系统上部署防病毒软件。

你的责任

你有责任通过选择适当的反恶意软件来保护工作负荷、基础结构和部署管道。

由于对 AKS 节点 VM 的访问受到限制，因此在可以向节点 VM 注入恶意软件的每个层保护系统。 在群集节点、容器映像和与 Kubernetes API 服务器的运行时交互中包括检测和预防。 除了群集，保护与群集交互的组件，还可以采用传统方式（例如跳转盒和生成代理）安装防病毒软件。

将扫描活动与安全开发生命周期（SDL）保持一致。 在 SDL 之后，请确保在开发早期阶段开始扫描体系结构的各个组件，并尽早涵盖安全差距。

要求 5.1.1

确保防病毒程序能够检测、删除和保护所有已知类型的恶意软件。

你的责任

了解每个软件产品/服务的功能集及其扫描深度。 软件应阻止常见威胁并监视新威胁。 确保软件定期更新、测试和替换（如果发现不合适）。 请考虑由信誉良好的供应商开发的软件。

• 检测群集漏洞的监视工具。

  在 AKS 中，不能直接在节点 VM 上运行基于代理的传统 VM 解决方案。 必须在 DaemonSets 中部署反恶意软件，该软件将在每个节点上的 Pod 中运行。

  选择专用于 Kubernetes 和容器化工作负荷的软件。 有几个第三方软件选项。 热门选择包括 Prisma Cloud 和 Aquasec。 还有开源选项，如 Falco。 部署后，它们在扫描所有用户和系统节点池的群集中作为代理运行。 尽管 AKS 对其运行时系统二进制文件使用系统节点池，但基础计算仍由你负责。

  运行代理的目的是检测异常群集活动。 例如，应用程序是否尝试调用 API 服务器？ 某些解决方案生成 Pod 之间的 API 调用日志、生成报告和生成警报。 请确保查看这些日志并执行必要的作。

  在启动群集后立即安装安全代理，以最大程度地减少群集与 AKS 资源部署之间的不受监视的差距。 安全代理以高特权运行，并扫描群集上运行的所有内容，而不仅仅是工作负荷。 它们不得成为数据外泄源。 此外，供应链攻击对于容器很常见。 使用深层防御策略，并确保软件以及所有依赖项都受信任。

  此外，在参与群集作的外部资产上运行防病毒软件。 一些示例包括跳转框、生成代理和与群集交互的容器映像。 代理扫描时，它不应阻止或干扰群集的关键作，例如锁定文件。 配置错误可能会导致稳定性问题，并可能使群集不受支持。

  重要

  参考实现提供占位符 DaemonSet 部署来运行反恶意软件代理。 代理将在群集中的每个节点 VM 上运行。 在此部署中放置你选择的反恶意软件。

• 维护容器安全。

  在管道中运行容器扫描工具，检测可能来自容器映像的威胁。 第三方选择包括特里维和克莱尔。 生成映像时，请始终努力减少发行版的图像。 这些映像仅包含基本 Linux 映像中的基本二进制文件，并减少攻击的外围应用。 使用持续扫描解决方案（如 Microsoft Defender for Containers 中的漏洞评估 ），以便持续扫描存储库中已有的映像。

要求 5.1.2

对于通常不是针对或受恶意软件影响的系统，请定期评估以识别和评估不断演变的恶意软件威胁，以确认它们是否继续不需要防病毒软件。

你的责任

常见漏洞可能会影响群集外部的组件。 通过监视来自 Azure 平台的 CVE 和其他安全警报来跟踪安全漏洞。 检查 Azure 更新 是否有新功能，这些功能可以检测漏洞，并在 Azure 托管服务上运行防病毒解决方案。

例如，Blob 存储应具有恶意软件信誉屏蔽来检测可疑上传。 Microsoft Defender for Storage 包括恶意软件信誉筛选。 此外，请考虑此类服务是否需要防病毒解决方案。

要求 5.2

确保保留所有防病毒机制，如下所示：

• 保持最新状态。
• 执行定期扫描。
• 生成审核日志，这些日志根据 PCI DSS 要求 10.7 保留。

你的责任

• 使用最新版本的防病毒软件，确保群集免受新的攻击。 需要考虑两种类型的更新：
  • 防病毒软件必须跟上最新的功能更新。 一种方法是将更新安排为平台更新的一部分。
  • 安全智能更新必须尽快应用，以便检测和识别最新威胁。 选择自动更新。
• 验证漏洞扫描是否按计划运行。
• 保留由于扫描而生成的任何日志，这些日志指示正常和不正常组件。 建议的保留期在要求 10.7 中提供，即一年。
• 制定一个过程，对检测到的问题进行会审并修正。

要求 5.3

防病毒功能应处于主动运行状态，用户无法禁用或更改。 除非在有限的时间段内按案例由管理授权。

你的责任

你负责设置安全代理的监视和警报。 为工作负荷和核心系统进程生成关键警报。 代理 必须 始终运行。 响应反恶意软件引发的警报。

• 保留扫描活动的日志跟踪。 确保扫描过程不会记录从磁盘或内存中擦除的任何持卡人数据。
• 为可能导致合规性意外失误的活动设置警报。 不应无意中关闭警报。
• 限制修改代理部署和其他所有关键安全工具的权限。 将这些权限与工作负荷部署权限分开。
• 如果安全代理未按预期运行，请不要部署工作负荷。

要求 5.4

验证保护系统免受恶意软件攻击的安全策略和作过程是否已记录、使用并传达给所有受影响的方。

你的责任

请务必维护有关过程和策略的彻底文档，尤其是有关用于保护系统的防病毒解决方案的详细信息。 包括诸如在产品周期中维护安全智能更新的位置、扫描频率以及有关实时扫描功能的信息等信息。

具有用于存储日志的保留策略。 出于合规性目的，你可能希望有长期存储。

维护有关标准作过程的文档，以评估和修正问题。 运营受管制环境的人员必须接受教育、告知和激励，以支持安全保证。 对于从策略角度来看属于审批流程的人员来说，这一点很重要。

要求 6：开发和维护安全系统和应用程序

AKS 功能支持

与其他 Azure 服务一样，AKS 遵循Microsoft安全开发生命周期（SDL）流程，以便在开发过程的各个阶段实现安全性。 从开发早期阶段开始扫描各种组件，并尽早涵盖安全漏洞。

AKS 映像遵循 FedRAMP SLA 方法，该方法要求在 30 天内修补映像中的漏洞。 若要强制实施此要求，所有映像都通过 DevSecOps 管道进行清理。

AKS 每周为节点池提供新映像。 你有责任应用它们，以确保修补和更新虚拟机规模集工作器节点。 有关详细信息，请参阅 Azure Kubernetes 服务（AKS）节点映像升级。

对于 AKS 控制平面，AKS 安装或升级安全修补程序。 它们每 24 小时更新一次。

AKS 控制平面和工作器节点是使用 Internet 安全中心（CIS）基准（特别是 AKS CIS、Ubuntu CIS 和 Windows CIS）强化的。

AKS 与 Azure 容器注册表集成。 将 Azure 容器注册表与 Microsoft Defender for Cloud 中的持续扫描功能配合使用，以识别各种风险级别的易受攻击的映像和应用程序。 有关映像扫描和风险控制的信息，请参阅 Microsoft Defender for Containers。

PCI DSS 4.0.1 需要定期识别和缓解系统、应用程序和基础结构中的漏洞。 这包括定期漏洞扫描、渗透测试和安全编码做法。 使用自动化工具在部署之前扫描容器映像，并使用云原生漏洞管理工具评估云环境。 解决基础结构即代码（IaC）和容器业务流程系统中基于配置错误的漏洞。

你的责任

要求 6.1

建立一个过程，以识别安全漏洞，使用信誉良好的外部源来获取安全漏洞信息，并将风险排名（例如 ，高、 中或 低）分配给新发现的安全漏洞。

你的责任

让进程检查检测到的漏洞并相应地进行排名。 Microsoft Defender for Cloud 根据资源类型和其严重性和环境显示建议和警报。 大多数警报都有 MITRE ATT&CK® 策略 ，可帮助你了解终止链意向。 确保你有一个修正计划来调查和缓解问题。

在 AKS 中，可以将 Azure 容器注册表与连续扫描结合使用，以识别各种风险级别的易受攻击的映像和应用程序。 可以在 Microsoft Defender for Cloud 中查看结果。

有关详细信息，请参阅 Defender for Cloud 中的容器保护。

要求 6.2

通过安装适用的供应商提供的安全修补程序，确保所有系统组件和软件都受到已知漏洞的保护。 在发布后的一个月内安装关键安全修补程序。

你的责任

• 若要防止来自第三方供应商的供应链攻击，请确保信任所有依赖项。 请务必选择信誉良好的供应商。

• AKS 每周为节点池提供新映像。 这些图像不会自动应用。 在可用后立即应用它们。 可以通过节点映像升级手动更新或自动更新。 有关详细信息，请参阅 Azure Kubernetes 服务（AKS）节点映像升级。

  对于 AKS 控制平面，AKS 安装或升级安全修补程序。

• AKS 节点每 24 小时自动下载并单独安装作系统和安全修补程序。 如果想要接收这些更新，防火墙不得阻止此流量。

  请考虑在安全代理上启用报告功能，以获取有关已应用更新的信息。 某些安全更新需要重启。 请务必查看警报并采取措施，以确保在重启时至少或零次应用程序停机。 以受控方式执行重启的开源选项是 Kured （Kubernetes 重新启动守护程序）。

• 将修补过程扩展到预配的群集外部的资源，例如跳转框和生成代理。

• 随时了解支持的 AKS 版本。 如果设计使用已结束其生命周期的版本，请升级到当前版本。 有关详细信息，请参阅 支持的 AKS 版本。

要求 6.3

安全地开发内部和外部软件应用程序（包括基于 Web 的管理访问应用程序），如下所示：

• 根据 PCI DSS（例如，安全身份验证和日志记录）。
• 基于行业标准和/或最佳做法。
• 在整个软件开发生命周期中整合信息安全，适用于内部开发的所有软件，包括第三方开发的定制或自定义软件。

你的责任

将安全选择作为工作负荷生命周期和作的一部分进行集成并设置优先级。

多个行业框架映射到生命周期，例如 NIST 框架。 NIST 函数（标识、保护、检测、响应和恢复）为每个阶段的预防控制提供策略。

Microsoft SDL 在整个开发过程的各个阶段提供安全最佳做法、工具和流程。 所有 Azure 服务（包括 AKS）都遵循 Microsoft SDL 做法。 我们还遵循运营云服务的作安全保障（OSA）框架。 确保有类似的过程。 这些做法已发布，有助于保护应用程序的安全。

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

• Microsoft SDL
• Microsoft OSA

要求 6.3.1

在应用程序处于活动状态或发布到客户之前，请删除开发、测试和/或自定义应用程序帐户、用户 ID 和密码。

你的责任

在群集创建过程中，默认情况下会创建多个本地 Kubernetes 用户。 无法审核这些用户，因为它们不表示唯一标识。 其中一些人拥有高特权。 使用 AKS 的 “禁用本地帐户 ”功能禁用这些用户。

有关其他注意事项，请参阅官方 PCI DSS 4.0.1 标准中的指南。

要求 6.3.2

在发布到生产环境或客户之前查看自定义代码，以确定任何潜在的编码漏洞（使用手动或自动化过程）包括以下内容：

• 代码更改由原始代码作者以外的个人以及了解代码评审技术和安全编码实践的个人审查。
• 代码评审确保根据安全编码准则开发代码。
• 在发布之前实施适当的更正。
• 代码评审结果在发布前由管理评审和批准。

你的责任

• 群集中安装的所有软件都源自容器注册表。 类似于应用程序代码，让流程和人员仔细审查 Azure 和第三方映像（Dockerfile 和 OCI）。

• 开始从创建群集时的初始阶段扫描容器映像。 使扫描过程成为持续集成/持续部署管道的一部分。

  确保部署管道通过评审和/或隔离门，从而阻止群集启动映像和工作负荷。 在将进程拉取到群集之前，请保留有关进程的使用方式和用途的历史记录。

• 减小图像大小。 通常，映像包含的二进制文件数比它们需要的要多。 减少图像大小不仅具有性能优势，而且还会限制攻击面。 例如，使用无发行版映像将最大程度地减少基本 Linux 映像的攻击面。

• 使用静态分析工具来验证 Dockerfile 和清单的完整性。 第三方选项包括 Dockle 和 Trivy。

• 仅使用已签名的映像。

• 了解（并接受）Azure 提供的基本映像以及它如何符合 CIS 基准。

在 Microsoft Defender for Cloud 中持续扫描的 Azure 容器注册表将有助于识别易受攻击的映像及其对工作负荷构成的各种风险。 有关映像扫描和风险控制的详细信息，请参阅 容器安全性。

要求 6.4

遵循对系统组件所做的所有更改的更改控制过程和过程。

你的责任

请确保记录更改控制过程，并根据这些流程设计部署管道。 包括用于检测进程和实际管道不一致的情况的其他进程。

要求 6.4.1 和 6.4.2

• 将开发/测试环境与生产环境分开，并使用访问控制强制隔离。
• 在开发/测试和生产环境之间分离职责。

你的责任

维护在这些环境中运行的单独生产和预生产环境和角色。

• 不要将生产群集用于开发/测试目的。 例如，不要在生产群集中安装 Bridge to Kubernetes 。 将专用群集用于非生产工作负荷。

• 确保生产环境不允许网络访问预生产环境，反之亦然。

• 请勿在预生产和生产环境中重复使用系统标识。

  对群集管理员或管道主体等组使用Microsoft Entra 组。 不要将通用组或通用组用作访问控制。 不要在预生产群集和生产群集之间重复使用这些组。 一种方法是使用组名称中的群集名称（或另一个不透明标识符），以在成员身份上显式显示。

  在环境之间适当地使用 Azure 基于角色的访问控制（RBAC）角色。 通常，在预生产环境中分配更多角色和权限。

  仅预生产中的标识（授予管道或软件工程团队）不应在生产环境中授予访问权限。 相反，任何仅生产标识（例如管道）不应在预生产群集中授予访问权限。

  不要将同一用户分配的托管标识用于预生产中和生产中的任何资源。 此建议适用于支持用户分配的托管标识的所有资源，而不仅仅是部署在群集中的资源。 根据规则，需要标识的 Azure 资源应具有自己的不同标识，而不是与其他资源共享。

• 使用实时 （JIT） 访问进行高特权访问，包括可能的情况下在预生产群集上使用。 在预生产群集和生产群集上使用条件访问策略。

要求 6.4.3

生产数据（实时 PAN）不用于测试或开发。

你的责任

确保 CHD 数据不会流入开发/测试环境。 有明确的文档，提供将数据从生产环境移动到开发/测试的过程。 删除真实数据必须包含在该过程中，并由责任方批准。

要求 6.4.4

在系统处于活动状态或投入生产之前，从系统组件中删除测试数据和帐户。

你的责任

在部署到生产环境之前，在系统中删除默认配置数据、示例数据和已知测试数据。 请勿将持卡人数据用于测试目的。

要求 6.4.5

实现安全修补程序和软件修改的更改控制过程必须包括以下内容：

• 6.4.5.1：影响文档。
• 6.4.5.2：经授权方记录的变更审批。
• 6.4.5.3：用于验证更改是否不会对系统的安全性产生负面影响的功能测试。
• 6.4.5.4：退出过程。

你的责任

这些指导点映射到上述要求：

• 记录因安全修补程序和软件修改而预期的基础结构更改。 使用基础结构即代码 （IaC） 方法，此过程更容易。 例如，使用 Bicep 文件或 Azure 资源管理器模板（ARM 模板），可以使用 what-if作预览部署的更改。 有关详细信息，请参阅 Bicep 部署基础结构更改的作。

• 在部署管道中实现入口，以验证对常规部署的更改的批准。 记录可能绕过入口的紧急部署的理由。

  定义更改的级别和深度。 确保团队就重大更改的定义达成一致，而不是轻微更改。 如果可行，请自动发现其中一些更改。 工作负荷、基础结构和管道的审阅者必须清楚地了解级别，并针对这些条件进行验证。

• 测试安全保障。 确保综合事务正在测试安全性（允许和拒绝）问题。 此外，请确保这些综合测试在预生产环境中运行。

• 如果安全修补程序出现意外结果，请执行退退过程。 一种常见策略是使用蓝绿部署在维护以前的状态时进行部署。 对于工作负荷（包括数据库）具有适用于特定拓扑的策略，其范围限定为部署单元。

要求 6.5

解决软件开发过程中常见的编码漏洞，如下所示：

• 至少每年培训开发人员 up-to日期安全编码技术，包括如何避免常见的编码漏洞。
• 根据安全编码准则开发应用程序。

你的责任

应用程序团队和运营团队必须接受教育、知情和激励，以支持工作负荷和基础结构的扫描活动。 有关详细信息，请参阅以下资源：

• 安全编码准则
• 保护 DevOps
• 安全开发生命周期资源

要求 6.6

对于面向公众的 Web 应用程序，请持续解决新的威胁和漏洞。 确保以下任一方法保护这些应用程序免受已知攻击：

• 使用手动或自动化应用程序漏洞安全评估工具或方法查看面向公众的 Web 应用程序。 至少每年和任何更改后执行漏洞评估。

  注释

  此评估与作为要求 11.2 一部分执行的漏洞扫描不同。

• 安装可检测和防止基于 Web 的攻击的自动化解决方案。 例如，Web 应用程序防火墙。 在面向公众的 Web 应用程序前面部署，并主动评估所有流量。

你的责任

通过检查来检测来自公共 Internet 的流量，方法是使用 Web 应用程序防火墙（WAF）。 在此体系结构中，Azure 应用程序网关使用集成 WAF 检查所有传入流量。 WAF 基于开放 Web 应用程序安全项目（OWASP）的核心规则集（CRS）。 如果技术控件未到位，请进行补偿控制。 一种方法是通过手动代码检查。

请确保使用最新版本的规则集，并应用与工作负荷相关的规则。 规则应在 “防护 ”模式下运行。 可以通过添加一个 Azure Policy 实例来强制实施该要求，该实例检查 WAF 是否已启用且处于该模式。

保留应用程序网关 WAF 生成的日志，以获取有关检测到的威胁的详细信息。 根据需要微调规则。

执行侧重于应用程序代码的渗透测试。 这样，不属于应用程序团队的从业者将通过收集信息、分析漏洞和报告来发现安全漏洞（如 SQL 注入和目录遍历）。 在本练习中，从业者可能需要访问敏感数据。 若要确保意向不会被滥用，请按照 渗透测试参与规则中提供的指导进行作。

要求 6.7

确保记录安全策略和维护安全系统和应用程序的安全策略和作过程，以供所有受影响的各方了解。

你的责任

维护有关流程和策略的彻底文档至关重要。 团队应接受培训，以在工作负荷生命周期和作过程中确定安全选择的优先级。

Microsoft SDL 在整个开发过程的各个阶段提供安全最佳做法、工具和流程。 当我们在 Microsoft 生成软件时，严格遵循 Microsoft SDL 做法。 我们还遵循运营云服务的作安全保障（OSA）框架。 这些做法已发布，有助于保护应用程序的安全。

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

• Microsoft SDL
• Microsoft OSA

保留透彻的文档，了解测试的范围、会审过程和检测到的问题的修正策略。 如果发生事件，请将要求 6 的评估纳入根本原因分析的一部分。 如果检测到间隙（例如检测到 OWASP 规则冲突），请关闭这些差距。

在文档中，有关于预期的 WAF 保护状态的明确准则。

运营受监管环境的人员必须接受教育、通知和激励，以支持安全保证。 从政策角度来说，属于审批流程的人员很重要。

后续步骤

跟踪和监视对网络资源和持卡人数据的所有访问。 定期测试安全系统和进程。