编辑

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

适用于 PCI-DSS 3.2.1 的 AKS 基线集群的监视操作（第 7 部分，共 9 部分）

Azure Kubernetes 服务 (AKS)
Microsoft Defender for Cloud
Azure Monitor

本文介绍了根据支付卡行业数据安全标准 (PCI-DSS 3.2.1) 运行工作负载的 Azure Kubernetes 服务 (AKS) 群集的注意事项。

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

重要

本指南和随附的实现建立在 AKS 基线体系结构之上。 该体系结构基于中心和分支拓扑。 中心虚拟网络包含用于控制出口流量的防火墙、来自本地网络的网关流量以及用于维护的第三个网络。 辐射型虚拟网络包含 AKS 群集，该群集提供持卡人数据环境 (CDE)，并托管 PCI DSS 工作负载。

GitHub logoGitHub：适用于受管制工作负载的 Azure Kubernetes 服务 (AKS) 基线群集展示了受管制的环境。 该实现演示了通过各种 Azure Monitor 功能使用审核线索。 它包含群集和资源中与群集子网交互的网络测试点的示例。

定期监视和测试网络

要求 10 — 跟踪并监视对网络资源和持卡人数据的所有访问

AKS 功能支持

Azure 提供监视容器（包括 AKS 群集）的容器见解功能。 有关详细信息，请参阅容器见解概述。

AKS 在多个级别提供审核日志，这些日志可用于主动保护系统和数据。 活动日志提供有关与帐户和机密管理、诊断设置管理、服务器管理相关的操作以及其他资源访问操作的信息。 所有日志都记录有日期、时间、标识和其他详细信息。 还可以访问对 AKS 群集进行的所有 API 调用的所有时间顺序记录。 日志包括有关调用方、进行调用的时间、发起调用的源等方面的信息。 有关详细信息，请参阅在 Azure Kubernetes 服务 (AKS) 中启用和查看 Kubernetes 控制平面日志。

RBAC（基于角色的访问控制）可用于管理资源访问策略，以此作为 Azure 上的标准做法。

所有日志都应存储在客户拥有的存储帐户或 Azure Monitor 日志中。 这样，便可以从大量数据快速生成见解。 所有日志都会随至少三个副本保留在一个区域中。 可以通过启用跨区域备份或复制来获得更多副本。 所有日志条目都只能通过安全 HTTP(s) 通道使用。

Azure 的警报框架使你可以配置警报以检测可疑访问。 可以设置需要触发的警报和事件。 用户还可以基于活动类型、活动内容或活动的调用方，通过筛选功能使用 Log Analytics 手动检查完整日志。

您的职责

需求 责任方
要求 10.1 实施审核日志措施，将对系统组件的所有访问关联到每个单独的用户。
要求 10.2 对所有系统组件实施自动化审核日志措施，以便重新构造以下事件：
要求 10.3 针对所有系统组件，至少记录每个事件的以下审核日志条目：
要求 10.4 使用时间同步技术，同步所有关键系统时钟和时间，确保通过实施以下措施来获取、分发和存储时间。
要求 10.5 保护审核日志，使之不能被更改。
要求 10.6 审核所有系统组件的日志和安全事件，以识别异常的或可疑的活动。
要求 10.7 保留审核日志历史记录至少一年，至少可将三个月内的数据立即用于分析（例如，可以通过在线获取、存档或从备份还原的方式提供）。
要求 10.8 仅适用于服务提供商的其他要求：及时响应任何关键安全控制的故障。 响应安全控制中的故障时，相关流程必须包括
要求 10.9 确保记录在监视对网络资源和持卡人数据进行的所有访问时使用过哪些安全策略和操作过程，并将其告知受影响的各方。

要求 11 — 定期测试安全系统和进程

AKS 功能支持

AKS 与 Azure 监视服务集成：

  • Microsoft Defender for Containers 提供了许多安全扫描功能。 例如，Defender for Containers 会扫描提取、推送和导入到容器注册表的映像，并提供建议。 有关详细信息，请参阅漏洞评估。

  • Azure Monitor 可用于基于事件类型设置警报，以保护系统完整性和安全性。 当 AKS 节点上出现任何预期的系统故障时，AKS 会及时自动修复资源，而不会中断系统处理。

AKS 群集受到具有 Web 应用程序防火墙 (WAF) 的 Azure 应用程序网关的保护，并且可以在检测模式下进行配置，以记录警报和威胁。 更强大的模式是预防性模式，该模式会主动阻止检测到的入侵和攻击。 有关详细信息，请参阅 Azure Kubernetes 服务 (AKS) 中的网络连接和安全的最佳做法。

您的职责

需求 责任方
要求 11.1 通过适当的流程测试是否存在无线接入点 (802.11)，按季检测和确定所有授权的和非授权的无线接入点。
要求 11.2 至少按季运行内部和外部网络漏洞扫描，对网络进行重大更改（例如新系统组件安装、网络拓扑更改、防火墙规则修改、产品升级）后也应进行此类扫描。
要求 11.3 实施适用于渗透测试的方法，其中包括以下内容：
要求 11.4 使用入侵检测和/或入侵预防技术来检测和/或防止对网络的入侵。
要求 11.5 部署更改检测机制（例如，文件完整性监视工具），以便在出现针对关键系统文件、配置文件或内容文件的未授权修改（报告更改、添加和删除）时提醒相关人员，并将软件配置为至少一周执行一次关键文件比较操作。
要求 11.6 确保记录在进行安全监视和测试时使用过哪些安全策略和操作过程，并将其告知受影响的各方。

要求 10.1

实施审核日志措施，将对系统组件的所有访问关联到每个单独的用户。

您的职责

建议利用以下方法使用对每个组件执行的审核操作：

  • Azure Monitor 活动日志。 活动日志提供有关 Azure 资源操作的类型和时间的信息。 它还记录启动操作的标识。 它在默认情况下处于启用状态，会在资源操作完成后立即收集信息。 审核线索是只写的，无法删除。

    数据会保留 90 天。 对于较长的保留选项，请考虑将将活动日志条目发送到 Azure Monitor 日志，并配置保留和存档策略。

    Screenshot that shows the Azure Activity Log.

  • Azure 诊断设置。 提供 Azure 资源和应用设置的平台的诊断和审核信息。 建议为系统中的 AKS 和其他组件（例如 Azure Blob 存储和 Key Vault）启用诊断设置。 基于资源类型，可以选择要发送到目标的日志和指标数据的类型。 诊断目标必须满足所需的保留期。

    • AKS 的诊断设置。 从提供的 AKS 类别中，启用 Kubernetes 审核日志。 诊断设置包括 kube-audit 或 kube-audit-admin，以及 guard。

      启用 kube-audit-admin 以查看基于日志的 API 服务器调用，这些调用可能会修改群集的状态。 如果需要所有 API 服务器交互（包括非修改事件，如读取请求）的审核线索，请改为启用 kube-audit。 这些事件可能会十分丰富，产生干扰，并增加消耗成本。 这些日志包含有关用于发出请求的访问和标识名称的信息。

      启用 guard 日志以跟踪托管 Microsoft Entra ID 和 Azure 基于角色的访问控制 (RBAC) 审核。

    除了基于用户的日志之外，请考虑 Kubernetes 控制平面中的日志，包括 kube-apiserver 和 kube-controller-manager。 这些日志通常不与用户关联，但可以帮助关联用户所进行的系统更改。

    有关详细信息，请参阅查看控制平面组件日志。

    此参考实现支持 cluster-autoscaler、kube-controller-manager、kube-audit-admin 和 guard 日志，并将其转发到 Log Analytics 工作区。 工作区保持期设置为 90 天。

    Screenshot that shows the AKS diagnostic setting.

  • Azure Kubernetes 服务 (AKS) 诊断有助于检测和排查群集问题，如节点故障。 它还包括不产生额外费用的特定于网络的诊断数据。 此数据通常不与用户关联，但可以帮助关联用户所进行的系统更改。 有关信息，请参阅 Azure Kubernetes 服务诊断。

在资源部署时，应实现前面的审核线索机制。 Azure Policy 也应处于活动状态，以确保这些配置不会在 CDE 中被无意或恶意禁用。

要求 10.2

对所有系统组件实施自动化审核日志措施，以便重新构造以下事件：

  • 10.2.1 对持卡人数据进行的所有个人用户访问
  • 10.2.2 具有根目录权限或管理权限的任何个人执行的所有操作
  • 10.2.3 对所有审核日志的访问
  • 10.2.4 无效的逻辑访问尝试
  • 10.2.5 对标识和身份验证机制的使用和更改操作，包括但不限于创建新帐户和特权提升，以及对具有根权限或管理权限的帐户进行的所有更改、添加或删除操作
  • 10.2.6 初始化、停止或暂停审核日志
  • 10.2.7 创建和删除系统级别对象

您的职责

AKS 在多个级别上提供审核日志，如要求 10.1 中所述。 以下是几个要点：

  • 默认情况下，活动日志提供有关关键 Azure 资源操作的信息。 所有日志包括状态、时间以及启动操作的标识。
  • 启用诊断设置以访问对 AKS 群集进行的所有 API 调用的所有记录。 日志提供有关请求者、时间戳、请求源和请求内容的详细信息。 将日志存储在具有适当保留期的 Log Analytics 工作区中。 启用 Log Analytics 工作区日志记录，以确保记录对审核线索的访问。
  • 使用容器见解启用 syslog 收集，以捕获 Log Analytics 工作区中的 AKS 节点级操作系统安全和健康状况事件日志。 还应将这些日志引入到 SIEM 中。
  • 包括对其他计算（例如生成代理和跳转盒）的 OS 与使用情况审核日志记录。 禁止直接以 root 身份访问系统。 验证所有操作都是在特定标识下执行的。
  • 记录不成功的访问尝试。 这包括对 Azure 存储、Azure Key Vault、AKS API 服务器等组件的访问请求，以及在其他系统上的任何 RDP/SSH 访问。
  • 利用第三方安全代理提供的功能来帮助分析 AKS 群集中的用户模式。 这些功能对于用户访问审核数据可能十分有用。

要求 10.3

针对所有系统组件，至少记录每个事件的以下审核日志条目：

  • 10.3.1 用户识别
  • 10.3.2 事件类型
  • 10.3.3 日期和时间
  • 10.3.4 成功或失败指示
  • 10.3.5 事件起源
  • 10.3.6 受影响数据、系统组件或资源的标识或名称。

您的职责

如要求 10.2 中所述，可以通过为 AKS 启用诊断设置从群集获取审核日志。 日志包含有关获取、列出、创建、更新、删除、修补和发布事件的详细信息。 日志包含“要求”下的列表中的信息。 将日志存储在存储帐户中，以便可以查询信息。

例如，你希望通过运行以下查询来查看 kube-audit-admin 事件的上述信息集：

AzureDiagnostics
| where Category == 'kube-audit-admin'
| project TimeGenerated, ResourceId, log_s,  pod_s
| top 200 by TimeGenerated desc

Screenshot that shows a diagnostic example.

结果集将信息显示为 log_s 字段的一部分。

必需的信息 架构
用户标识 SourceIPs
事件类型 谓词
日期和时间 requestReceivedTimestamp
成功或失败指示 responseStatus
事件起源 user
受影响数据、系统组件或资源的标识或名称 objectRef

有关主日志的信息，请参阅查看控制平面组件日志。

要求 10.4

使用时间同步技术同步所有关键系统时钟和时间，并验证是否通过实施以下措施来获取、分发和存储时间。

  • 10.4.1 关键系统具有正确且一致的时间。
  • 10.4.2 时间数据受保护。
  • 10.4.3 时间设置从行业接受的事件源获得。

注意：时间同步技术的一个示例是网络时间协议 (NTP)。

您的职责

AKS 使用来自基础 Azure 主机的 NTP，不需要任何出站网络流量限额来支持 NTP。 添加到 CDE 的其他 VM 可能会使用外部 NTP 服务器，例如 ntp.ubuntu.org（及其池）作为其时间同步源。 引入 CDE 中的其他计算都应显式使用所选的 NTP 源，并且应进行记录。

要求 10.5

仅限有工作需要的人员查看审核线索。

  • 10.5.1 仅限有工作需要的人员查看审核线索。
  • 10.5.2 防止未经授权修改审核日志文件。
  • 10.5.3 快速将审核日志文件备份到难以更改的中心日志服务器或介质。
  • 10.5.4 将面向外部的技术的日志写入到安全的中心内部日志服务器或介质设备。
  • 10.5.5 对日志使用文件完整性监视或更改检测软件，确保现有日志数据不能在没有生成警报的情况下进行更改（不过，添加新数据不应引发警报）。

您的职责

采用多个日志记录同步会增加保护、查看、分析和查询审核线索数据的开销。 规划审核线索拓扑，以平衡完整的审核线索隔离与管理问题之间的权衡。

尽可能集成日志。 优点是能够高效地查看、分析和查询数据。 Azure 提供了几个拓扑选项。 可以使用 Azure Monitor 容器见解将日志写入 Log Analytics 工作区中。 另一个选项是将数据集成到安全信息和事件管理 (SIEM) 解决方案（例如 Microsoft Sentinel）中。 其他常用的第三方选项有 Splunk、QRadar 和 ArcSight。 Microsoft Defender for Cloud 和 Azure Monitor 支持所有这些解决方案。 这些解决方案是仅追加数据接收器，可确保无法更改线索。

Defender for Cloud 可以按配置的间隔导出结果。 有关详细信息，请参阅连续导出。

所有日志都会随至少三个副本保留在一个区域中。 作为备份策略，可以通过启用跨区域备份或复制来获得更多副本。 所有日志条目都只能通过安全 HTTP/S 通道使用。

Log Analytics 和 Microsoft Sentinel 支持各种基于角色的访问控制来管理审核线索访问。 确保角色映射到组织的角色和职责。

确保 Log Analytics 工作区支持操作和合规性需求。 请考虑将专用工作区用于范围内的群集，该工作区会转发到 SIEM 解决方案。

AKS 中的大多数日志记录来自 stdout/stderr，由 Azure Monitor 容器见解进行收集。 如果具有其他手动创建的日志，请考虑以发送到受信任转发流且不会受到篡改的方式发出数据。

要求 10.6

审核所有系统组件的日志和安全事件，以识别异常的或可疑的活动。

  • 10.6.1 至少每天审核一次以下内容：
    • 所有安全事件
    • 用于存储、处理或传输 CHD 和/或 SAD 的所有系统组件的日志
    • 所有关键系统组件的日志
    • 所有执行安全功能（例如，防火墙、入侵检测系统/入侵防护系统 (IDS/IPS)、身份验证服务器、电子商务重定向服务器等）的服务器和系统组件的日志。
  • 10.6.2 定期根据组织的政策和风险管理策略（取决于组织的年度风险评估）审核所有其他系统组件的日志。
  • 10.6.3 跟进在审核过程中发现的例外和异常。

您的职责

Azure 监视服务、Azure Monitor 和 Microsoft Defender for Cloud 可以在检测到异常活动时生成通知或警报。 这些警报包含上下文信息，如严重性、状态和活动时间。

生成警报时，制定修正策略并查看进度。 一种方法是在 Microsoft Defender for Cloud 中跟踪安全分数，并将其与历史结果进行比较。

使用 SIEM 解决方案（如 Microsoft Sentinel）在单个视图中集中数据。 集成数据可以提供丰富的警报上下文。

或者，手动检查存储中的完整日志。 例如在 Azure Monitor 日志中，可以基于活动类型、活动内容或活动的调用方使用筛选功能。

制定组织策略以定期查看警报和事件，并规划具有特定改进目标的计划。 在 Log Analytics 中使用保存的自定义查询来记录预期日志查询并简化查询。 这可确保团队知道要查看的与 10.6 相关的重要内容，并且此过程所涉及的所有手动工作都遵循一致的工作流。

要求 10.7

保留审核日志历史记录至少一年，至少可将三个月内的数据立即用于分析（例如，可以通过在线获取、存档或从备份还原的方式提供）。

您的职责

日志并非无限期提供。 确保保留并可以查询 Azure 活动日志和诊断设置。 在为资源启用诊断设置时指定三个月保留期。 Azure Monitor 日志支持长期存档，以便它们可用于审核或脱机分析。 实现长期存档解决方案，以符合一次写入多次读取的原则。

要求 10.8

  • 10.8.1 仅适用于服务提供商的其他要求：及时响应任何关键安全控制的故障。 响应安全控制中的故障时，相关流程必须包括：

  • 还原安全功能

  • 确定并记录安全故障的时长（从开始到结束的日期和时间）

  • 确定并记录故障原因，包括根本原因，并记录解决根本原因需要采取的修正措施

  • 确定并解决在故障过程中引发的任何安全问题

  • 执行风险评估，确定是否需要采取更多措施来解决安全故障

  • 通过实施控制来防止故障原因再次出现 - 恢复对安全控件的监视

您的职责

在可行时发出警报，表明存在关键安全控制。 否则，请确保审核过程可以及时检测缺少预期的安全控制。 请考虑在 AKS 群集中运行的安全代理和 Azure 资源上的访问控制（IAM 和网络）等控制措施。 包括检查 AKS 群集是否为专用群集、通过网络安全组 (NSG) 规则检查网络暴露点或是检查意外公共 IP 等设置。 还包括 DNS、网络路由、防火墙和 Microsoft Entra ID 中的意外更改。

要求 10.9

确保记录在监视对网络资源和持卡人数据进行的所有访问时使用过哪些安全策略和操作过程，并将其告知受影响的各方。

您的职责

维护关于流程和策略的完整文档至关重要。 维护有关强制实施的策略的文档。 作为监视工作的一部分，必须在启用和查看审核日志以及识别和修正常见风险方面对人员进行培训。 从策略角度来看，这对于参与审批过程的人员很重要。

要求 11.1

通过适当的流程测试是否存在无线接入点 (802.11)，按季检测和确定所有授权的和非授权的无线接入点。

外部网络不在本文档的讨论范围内，必须单独评估。

您的职责

此体系结构及其实现并非旨在通过无线连接支持本地或公司网络到云的事务。 有关注意事项，请参阅官方 PCI-DSS 3.2.1 标准中的指南。

要求 11.2

至少每季度和在任何重大网络更改后运行内部和外部网络漏洞扫描，例如：

  • 新系统组件安装
  • 网络拓扑中的更改
  • 防火墙规则修改
  • 产品升级

有关详细信息，请参阅支付卡行业 (PCI) 数据安全标准已批准扫描供应商。

您的职责

采用一个过程来检查 AKS 群集、网络配置、容器注册表和其他体系结构组件中的更改。

如果网络中存在更改，则该过程应评估是否需要扫描。 例如，群集现在是否向公共 Internet 公开？ 新防火墙规则是否过于宽松？ 在群集中，Pod 之间的流中是否存在任何安全漏洞？

对基础结构方面的重大更改具有明确且一致的定义。 一些示例如下：

  • 配置 NSG 或 Azure 防火墙规则
  • 虚拟网络对等互连
  • DNS 设置
  • Azure 专用链接配置
  • 其他网络组件

适用于 11.2.1

必须由对 Azure 网络和 Kubernetes 网络概念有深入了解的熟练人员运行季度漏洞扫描。 借助严重性级别将结果映射到要求 6.1，解决高优先级项。 如果存在重大更改，请在计划季度扫描之前运行扫描。 这可帮助检测新漏洞，以便可以主动修复问题。

此扫描还必须包括群集内（Pod 到 Pod）网络。

适用于 11.2.2 选择在 Azure 网络和 Kubernetes 方面具有丰富经验的已批准扫描供应商 (ASV)。 这可在建议修正中提供深度和特异性。

要求 11.3

实施适用于渗透测试的方法，其中包括以下内容：

  • 基于行业接受的渗透测试方法（例如，NIST SP800-115）
  • 包括对整个 CDE 外围和关键系统的覆盖
  • 包括从网络内部和外部进行的测试
  • 包括用于验证任何分段和范围缩减控件的测试
  • 定义应用程序层渗透测试，使之至少包括“要求 6.5”中列出的漏洞
  • 定义网络层渗透测试，使之包括支持网络功能和操作系统的组件
  • 包括对过去 12 个月中遇到的威胁和漏洞的审核和考虑
  • 指定渗透测试结果和修正活动结果的保留期。

您的职责

执行渗透测试，以通过收集信息、分析漏洞和报告来找出安全漏洞。 建议遵循渗透测试执行标准 (PTES) 中提供的行业准则，以解决常见方案以及建立基线所需的活动。

渗透测试执行者应深入了解本地和 Azure 网络，以确保广泛涵盖每年的分段测试。 将测试方法扩展到群集内网络。 此人员需要具有 Kubernetes 网络概念方面的丰富经验。

测试必须涵盖 CDE 中运行的应用程序和数据层。

在渗透测试练习中，执行者可能需要访问整个组织的敏感数据。 遵循参与规则，确保不会滥用访问权限和意图。 有关规划和执行模拟攻击的指导，请参阅《渗透测试参与规则》。

要求 11.4

使用入侵检测和/或入侵预防技术来检测和/或防止对网络的入侵。 监视持卡人数据环境外围和持卡人数据环境中关键点的所有流量， 提醒相关人员可能存在入侵。

您的职责

通过使用 Web 应用程序防火墙 (WAF) 检查入站流量来保护 AKS 群集。 在此体系结构中，集成了 WAF 的 Azure 应用程序网关可防止入侵。 使用预防模式可主动阻止检测到的入侵和攻击。 请勿仅使用检测模式。 有关详细信息，请参阅 Azure Kubernetes 服务 (AKS) 中的网络连接和安全的最佳做法。

备选选项是在 Azure 防火墙高级版中使用入侵检测和/或入侵防护功能。 有关详细信息，请参阅 IDPS。

另一个选项是启用 Azure Monitor 网络见解，它提供了对网络监视功能的访问，如连接监视器、网络安全组 (NSG) 的流日志记录和流量分析。

启用 Microsoft Defender 计划，因为它们会应用于 CDE 的各个组件。 例如，如果使用 Azure SQL 存储 CHD，则 Microsoft Defender for SQL 可确保检测到数据层入侵。

此外，可通过将 NSG 流日志连接到集中式 SIEM 解决方案（如 Microsoft Sentinel）来检测流量模式中的异常。 在此参考实现中，日志处于仅追加模式，可最大程度地减少审核日志上的更改跟踪。 但是，不得修改发送到外部接收器进行长期存储的所有日志。 它们必须遵循一次写入/多次读取方法。 确保文件完整性监视 (FIM) 解决方案涵盖这些外部实体以检测更改。

要求 11.5

部署更改跟踪解决方案（例如文件完整性监视解决方案），以提醒相关人员对关键系统文件、配置文件或内容文件进行未经授权的修改。 将产品配置为至少每周执行关键文件比较。

您的职责

在群集中，将文件完整性监视 (FIM) 解决方案与 Kubernetes 感知的安全代理一起运行，以检测可能导致节点级更改的文件和系统级访问。 选择 FIM 解决方案时，清楚地了解其功能和检测深度。 考虑由信誉良好的供应商开发的软件。

重要

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

检查 FIM 工具的所有默认设置，以确保这些值可检测要涵盖的方案，并相应地调整这些设置。

使解决方案可以将日志发送到监视或 SIEM 解决方案，以便它们可以生成警报。 请注意日志架构更改，否则可能会错过关键警报。

CDE 中的其他任何其他计算都应启用更改跟踪。

要求 11.6

确保记录在进行安全监视和测试时使用过哪些安全策略和操作过程，并将其告知受影响的各方。

您的职责

维护关于流程和策略的完整文档至关重要。 维护有关强制实施的策略的文档。 作为测试工作的一部分，包括评审频率和评审条件。 确保团队了解渗透测试的各个方面。 制定进行了记录的修正计划，以缓解发现的风险。

从策略角度来看，这对于参与审批过程的人员很重要。

后续步骤

维护用于解决所有人员的信息安全性问题的策略。

维护信息安全策略