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

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

请选择专门用于 Kubernetes 和容器的软件。 有多个第三方软件选项。 常见选项包括 Prisma Cloud 和 Aquasec。 还有开源选项，例如 Falco。

部署后，它们会在扫描所有用户和系统节点池的群集中作为代理运行。 尽管 AKS 将系统节点池用于其运行时系统二进制文件，但底层计算仍然是你的职责。

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

在群集启动后立即安装安全代理，以将群集和 AKS 资源部署之间不受监视的差距将至最低。

安全代理以高特权运行，它们扫描群集上运行的所有内容，而不仅仅是工作负载。 它们不得成为数据外泄源。 此外，供应链攻击对于容器很常见。 请使用纵深防御策略，并确保软件和所有依赖项都是可信的。

此外，请对参与群集操作的外部资产运行防病毒软件。 这样的示例包括与群集进行交互的跳转盒、生成代理和容器映像。

代理扫描时，它不应阻止或干扰群集的关键操作，例如，通过锁定文件。 错误配置可能会导致稳定性问题，并可能使群集不受支持。

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

维护容器安全。 在管道中运行容器扫描工具，以检测可能通过容器映像出现的威胁，例如 Microsoft Defender for Containers 中的 CI/CD 漏洞扫描 。 第三方选择包括 Trivy 和 Clair。 在构建映像时，请始终尽力获取“无分发版”映像。 这些映像仅包含基础 Linux 映像中的基本二进制文件，并减小了可被攻击的外围应用。 使用一个持续扫描解决方案（例如 Microsoft Defender for Containers 中的漏洞评估 ），以持续扫描存储库中已处于静态的映像。

要求 5.1.2

对于通常不受恶意软件侵袭的系统，执行定期评估以识别并评估不断发展的恶意软件威胁，以确认它们是否继续不需要安装防病毒软件。

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

例如，Blob 存储应具有恶意软件信誉筛查功能来检测可疑上传。 新功能 Microsoft Defender for Storage 包括恶意软件声誉筛查。 此外，请考虑这样的服务是否需要使用防病毒解决方案。

要求 5.2

确保所有防病毒机制如下所述进行维护：

• 防病毒软件必须跟上最新的功能更新。 一种方法是将更新安排为平台更新的一部分。
• 安全情报更新在可用后必须立即应用，以便检测和识别最新威胁。 请选择自动更新。
• 验证漏洞扫描是否按计划运行。
• 保留由于扫描而生成的日志，这些日志指示正常运行和非正常运行的组件。 “要求 10.7”中给出了建议的保留期，即一年。
• 制定用于对检测到的问题进行会审和修正的流程。

有关如何应用 Microsoft Defender 防病毒更新的信息，请参阅 管理 Microsoft Defender 防病毒更新并应用基线 。

要求 5.3

防病毒功能应处于主动运行状态，用户不能禁用或更改此功能。 除非在有限的时间段内由管理层逐个授权。

你负责设置安全代理的监视和警报。 请针对工作负载和核心系统进程构建关键警报。 代理必须始终一直运行。 响应反恶意软件引发的警报。

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

要求 5.4

验证用于保护系统免受恶意软件危害的安全策略和操作规程已记录并在使用中，且已告知受影响的各方。

维护有关流程和策略的详尽文档至关重要，尤其是用来保护系统的防病毒解决方案的详细信息。 包括诸如在产品周期中在何处维护安全情报更新、扫描频率以及有关实时扫描能力的信息。

制定用于存储日志的保留策略。 出于合规性目的，你可能想要使用长期存储。

请维护有关用于评估和修正问题的标准操作规程的文档。 操作受管制环境的人员必须接受培训、了解情况并受到激励，以支持安全性保证。 从策略角度来看，这对于参与审批过程的人员很重要。

要求 6.1

建立一个流程来确定安全漏洞，使用可信的外部源来获取安全漏洞信息，并为新发现的安全漏洞指定风险等级（例如“高”、“中”或“低”）。

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

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

有关详细信息，请参阅 容器注册表 。

要求 6.2

通过安装供应商提供的相应安全修补程序，确保所有系统组件和软件不受已知漏洞的危害。 安装关键安全修补程序的时间在发布后的一个月内。

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

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

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

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

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

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

• 始终使用最新的受支持 AKS 版本。 如果你的设计使用已达到生命周期结束的版本，请升级到当前版本。 有关详细信息，请参阅 受支持的 AKS 版本 。

  要求 6.3

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

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

在工作负载生命周期和操作中，集成安全选项并确定其优先级。

有多个行业框架映射到生命周期，例如 NIST 框架。 NIST 功能 - 识别、保护、检测、响应和恢复 - 为每个阶段的预防性控制提供策略。

Microsoft SDL（Security Development Lifecycle，安全开发生命周期）针对开发过程的各个阶段都提供了用于确保安全性的最佳做法、工具和流程。 所有 Azure 服务（包括 AKS）都遵循 Microsoft SDL 做法。 我们还遵循用于操作云服务的操作安全保障 (OSA) 框架。 请确保制定一个类似的流程。 已发布这些做法来帮助你保护应用程序。

• Microsoft SDL
• Microsoft OSA

要求 6.3.1

在激活应用程序或将其发布给客户之前，删除开发、测试和/或自定义应用程序帐户、用户 ID 和密码。

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

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

要求 6.3.2

在发布到生产部门或客户之前，对自定义代码进行审核，以便确定所有潜在的编码漏洞（使用手动或自动过程），确保包括以下措施：

• 由原始代码作者之外的人员以及熟悉代码评审技巧和安全编码做法的人员对代码更改进行评审。
• 代码评审可确保代码是根据安全编码准则开发的。
• 在发布之前进行了适当的更正。
• 代码评审结果在产品发布之前由管理人员进行审核。

群集中安装的所有软件都源自容器注册表。 与应用程序代码类似，请制定相应流程并安排人员来仔细检查 Azure 和第三方映像（DockerFile 和 OCI）。 此外：

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

  务必对部署管道进行把关，确保群集启动映像和工作负载都通过了审查和/或隔离关卡。 维护有关在群集中引入流程之前使用了哪些流程及其使用方式的历史记录。

• 减小映像大小。 通常，映像包含的二进制文件多于所需。 减小映像大小不仅对性能有益，而且还限制了攻击面。 例如，使用“无分发版”可以最小化基本 Linux 映像。

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

• 仅使用已签名映像。

• 了解（并接受）Azure 提供的基本映像以及它对 CIS 基准的符合情况。 有关详细信息，请参阅 Internet 安全中心 (CIS) 基准 。

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

  要求 6.4

  不管对系统组件进行何种更改，都应遵循更改控制流程和过程。

  确保编写变更控制流程文档，并根据这些流程设计部署管道。 包括其他用于检测流程与实际管道不符的情况的流程。

  要求 6.4.1、6.4.2

• 将开发/测试环境与生产环境分开，通过访问控制强制分开。
• 将开发/测试环境和生产环境的职责分开。

维护单独的生产环境和生产前环境以及在这些环境中进行操作的角色。

• 切勿使用生产群集进行开发/测试。 例如，不要在生产群集中安装“bridge to Kubernetes”。 请为非生产工作负载使用专用群集。

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

• 不要在生产前环境和生产环境中重用系统标识。

  对于群集管理员或管道负责人之类的组，请使用 Azure AD 组。 不要将笼统的或通用的组用作访问控制措施。 不要在生产前群集和生产群集之间重用这些组。 一种方法是在组名称中使用群集名称（或其他不透明标识符），以明确成员身份。

  在环境之间恰当地使用 Azure 基于角色的访问控制 (RBAC) 角色。 通常情况下，在生产前环境中分配更多的角色和权限。

  对于仅在生成前环境中使用的标识（授予给管道或软件工程团队），不应为其授予对生产环境的访问权限。 反过来，对于仅在生成环境中使用的标识（例如管道），不应为其授予对生产前群集的访问权限。

  不要为生产前环境和生产环境中的任何资源使用相同的用户托管标识。 此建议适用于支持用户托管标识的所有资源，而不仅仅是部署在群集中的资源。 一项规则是，需要使用标识的 Azure 资源应该具有自己的独有标识，而不是与其他资源共享标识。

• 对于高特权访问，请尽可能使用即时 (JIT) 访问权限，即使在生产前群集上也是如此。 在生产前群集和生产群集上都要使用条件访问策略。

  要求 6.4.3

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

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

  要求 6.4.4

  在系统激活/投入生产之前，从系统组件中删除测试数据和帐户。

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

  要求 6.4.5

  用于实施安全修补程序和软件修改的变更控制规程必须包括以下内容：

• 6.4.5.1 有关影响的文档。
• 6.4.5.2 经授权方提供的记录在案的变更批准。
• 6.5.4.3 进行功能测试，验证所做的更改是否不会对系统安全性造成负面影响。
• 6.4.5.4 回退规程。

以下指导要点对应于上述要求：

• 记录由于安全修补程序和软件修改而预期发生的基础结构更改。 如果使用基础结构即代码 (IaC) 方法，则此过程更为容易。 例如，使用 Azure 资源管理器模板（ARM 模板）进行部署时，你可以通过 What-if 操作来预览更改。 有关详细信息，请参阅适用于你的基础结构变更的 ARM 模板部署 What-if 操作 。

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

  定义更改的级别和深度。 确保团队就重大更改（与微小更改相对）的定义达成一致。 如果可行，请将其中某些更改的发现自动化。 工作负载、基础结构和管道的审阅者必须清楚了解各个级别并针对这些条件进行验证。

• 测试安全性负担能力。 确保通过综合事务来测试安全性（包括允许和拒绝）关注事项。 此外，请确保在生产前环境中运行这些综合测试。

• 请制定回退流程，以防安全修补程序出现意外结果。 常用策略是使用蓝绿部署来部署先前的某个状态。 对于工作负载（包括数据库），请制定适合你的特定拓扑的策略，并将范围限定为你的部署单元。

  要求 6.5

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

• 至少每年对开发人员培训一次最新的安全编码技术，包括如何避免常见的编码漏洞。
• 根据安全编码准则开发应用程序。

应用程序团队和操作团队必须接受培训、了解情况并受到激励，以支持工作负载和基础结构的扫描活动。 下面是一些资源：

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

要求 6.6

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

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

  此评估与要求 11.2 中执行的漏洞扫描不同。

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

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

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

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

  执行侧重于应用程序代码的渗透测试。 这样，不属于应用程序团队的专业人员将通过收集信息、分析漏洞以及生成报告来发现安全漏洞（例如 SQL 注入和目录遍历）。 在此活动中，专业人员可能需要访问敏感数据。 为确保意图不被滥用，请遵循 参与的渗透测试规则 中提供的指导。

  要求 6.7

  确保在开发和维护安全系统和应用程序时使用的安全策略和操作规程已记录并在使用中，且已告知受影响的各方。

  维护关于流程和策略的完整文档至关重要。 应当对你的团队进行培训，以便他们在工作负载生命周期和操作中确定安全选项优先级。

  Microsoft SDL 针对开发过程的各个阶段都提供了用于确保安全性的最佳做法、工具和流程。 Microsoft SDL 做法在内部严格遵循我们 Microsoft 构建软件的方式。 我们还遵循用于操作云服务的操作安全保障 (OSA) 框架。 已发布这些做法来帮助你保护应用程序。

• Microsoft SDL
• Microsoft OSA

维护用于渗透测试的详尽文档，该文档描述测试范围、会审过程和针对所检测到问题的修正策略。 如果发生事件，请在根本原因分析过程中纳入要求 6 的评估。 如果检测到漏洞（例如，检测到 OWASP 规则冲突），请弥补这些漏洞。

在文件中，制定有关预期 WAF 保护状态的明确指南。

操作受管制环境的人员必须接受培训、了解情况并受到激励，以支持安全性保证。 从策略角度来看，这对于参与审批过程的人员很重要。

按需要知道的业务限制对持卡人数据的访问。 识别对系统组件的访问并对其进行身份验证。 限制对持卡人数据的物理访问。

实施强访问控制措施