本文介绍 Azure Kubernetes 服务 （AKS） 群集的监视和日志记录注意事项，这些群集运行工作负载符合支付卡行业数据安全标准（PCI DSS 4.0.1）。
本文是一系列文章的其中一篇。 阅读 简介。
重要
该指南和随附的实现基于中心辐射型网络拓扑的 AKS 基线体系结构为基础。 中心虚拟网络包含用于控制出口流量的防火墙、来自本地网络的网关流量，以及用于维护的第三个网络。 辐射虚拟网络包含 AKS 群集，该群集提供卡持有者环境（CDE），并托管 PCI DSS 工作负荷。
参考实现：适用于 PCI DSS 4.0.1 的受管制工作负载参考实现的 Azure Kubernetes 服务（AKS）基线群集目前正在更新，即将推出。 此实现将演示一个受监管的环境，该环境演示了通过各种 Azure Monitor 功能使用审核线索。 它还将包括一个应用程序，用于演示环境与示例工作负荷之间的交互。 本文的重点在于基础结构。 该示例不会指示实际 PCI-DSS 4.0.1 工作负荷。
定期监视和测试网络
要求 10：记录和监视对系统组件和持卡人数据的所有访问
AKS 功能支持
Azure 提供用于监视容器（包括 AKS 群集）的容器见解功能。 有关详细信息，请参阅 容器见解概述。
AKS 在多个级别提供审核日志，可用于主动保护系统和数据。 活动日志提供有关与帐户和机密管理、诊断设置管理、服务器管理和其他资源访问作相关的作的信息。 所有日志都记录有日期、时间、标识和其他详细信息。 还可以访问对 AKS 群集进行的所有 API 调用的所有时间顺序记录。 日志包括有关调用方的信息、发出呼叫的时间以及发起呼叫的源。 有关详细信息，请参阅 AKS 控制平面/资源日志。
可以使用基于角色的访问控制（RBAC）将资源访问策略作为 Azure 上的标准做法进行管理。
应将所有日志存储在客户拥有的存储帐户或 Azure Monitor 日志中。 这样，便可以从大量数据快速生成见解。 所有日志都保留一个区域中至少有三个副本。 可以通过启用跨区域备份或复制来获得更多副本。 所有日志条目仅可通过受保护的 HTTP（s） 通道使用。
Azure 的警报框架允许配置警报以检测可疑访问。 可以设置触发的警报和事件。 用户还可以使用 Log Analytics 手动检查完整日志，并基于活动类型、活动内容或活动的调用方进行筛选功能。
PCI DSS 4.0.1 扩展了日志记录和监视的要求，强调集中日志记录、每日日志审查和保护，防止未经授权的修改。 使用云原生日志记录工具（如 Azure Monitor）实时捕获活动，包括容器等临时系统。 监视容器活动，包括微服务与特权提升尝试之间的通信。 确保 Kubernetes 中 Pod 生命周期事件的日志管道帐户。
你的责任
| Requirement | 职责 |
|---|---|
| 要求 10.1 | 实现审核线索，将所有对系统组件的访问权限链接到每个用户。 |
| 要求 10.2 | 为所有系统组件实现自动化审核线索，以重新构造以下事件。 |
| 要求 10.3 | 为每个事件的所有系统组件至少记录以下审核线索条目。 |
| 要求 10.4 | 使用时间同步技术，同步所有关键系统时钟和时间，并确保实现以下内容以获取、分发和存储时间。 |
| 要求 10.5 | 保护审核线索，使其无法更改。 |
| 要求 10.6 | 查看所有系统组件的日志和安全事件，以确定异常或可疑活动。 |
| 要求 10.7 | 将审核线索历史记录保留至少一年，至少三个月可立即进行分析（例如，联机、存档或可从备份还原）。 |
| 要求 10.8 | 仅对服务提供商的其他要求：及时响应任何关键安全控制故障。 用于响应安全控制故障的进程必须包括。 |
| 要求 10.9 | 确保记录所有网络资源和持卡人数据访问的安全策略和作过程，以供所有受影响的方记录、使用和已知。 |
要求 10.1
实现审核线索，将所有对系统组件的访问权限链接到每个用户。
你的责任
建议使用以下方法审核对每个组件执行的作：
Azure Monitor 活动日志：活动日志提供有关 Azure 资源作的类型和时间的信息。 它还会记录启动作的标识。 默认情况下，它处于启用状态，并在资源作完成后立即收集信息。 审核线索是不可变的，无法删除。
数据保留 90 天。 对于更长的保留选项，请考虑 将活动日志条目发送到 Azure Monitor 日志 并配置保留和存档策略。
在资源部署时，应实施上述审核线索机制。 Azure Policy 还应处于活动状态，以确保这些配置不会无意或恶意地在 CDE 中禁用。
要求 10.2
为所有系统组件实现自动审核线索以重新构造以下事件：
| 事件 / 活动 | Description |
|---|---|
| 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 工作区日志记录，确保记录对审核线索的访问权限。
- 包括针对其他计算（例如生成代理和跳转框）的 OS 和使用情况审核日志记录。 直接禁用对系统的访问作为根。 验证是否正在特定标识下执行所有作。
- 记录访问尝试失败。 这包括对 Azure 存储、Azure Key Vault、AKS API 服务器和其他系统上的任何 RDP/SSH 访问等组件的访问请求。
- 利用第三方安全代理提供的功能来帮助分析 AKS 群集中的用户模式。 这些功能对于用户访问审核数据可能很有用。
要求 10.3
为每个事件记录所有系统组件至少以下审核线索条目：
| 事件 / 活动 | Description |
|---|---|
| 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
结果集将信息显示为字段的 log_s 一部分：
| 必需信息 | Schema |
|---|---|
| 用户标识 | SourceIPs |
| 事件类型 | verb |
| 日期和时间 | requestReceivedTimestamp |
| 成功或失败指示 | responseStatus |
| 事件的起源 | user |
| 受影响的数据、系统组件或资源的标识或名称 | objectRef |
有关控制平面日志的信息，请参阅 AKS 控制平面/资源日志。
要求 10.4
使用时间同步技术（如网络时间协议（NTP）来同步所有关键系统时钟和时间，并验证是否已实施以下子要求来获取、分发和存储时间：
| 子要求 | Description |
|---|---|
| 10.4.1 | 关键系统具有正确且一致的时间。 |
| 10.4.2 | 时间数据受到保护。 |
| 10.4.3 | 从行业接受的时间源接收时间设置。 |
你的责任
AKS 使用基础 Azure 主机中的 NTP，不需要任何出站网络流量限额来支持 NTP。 添加到 CDE 的其他 VM 可能会使用外部 NTP 服务器（ ntp.ubuntu.org 及其池）作为其时间同步源。 引入 CDE 的其他计算应显式使用所选的 NTP 源，并应记录这些计算。
要求 10.5
将审核线索的查看限制为仅具有与工作相关的需求的人员，如下所示：
| 子要求 | Description |
|---|---|
| 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
查看所有系统组件的日志和安全事件，以识别异常或可疑活动，如下所示：
| 子要求 | Description |
|---|---|
| 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：定期测试安全系统和进程
AKS 功能支持
AKS 与 Azure 监视服务集成：
- Microsoft Defender for Containers 提供了许多安全扫描功能。 例如，Defender for Containers 会扫描提取、推送和导入到容器注册表的映像，并提供建议。 有关详细信息，请参阅 漏洞评估。
- Azure Monitor 可用于基于事件类型设置警报，以保护系统完整性和安全性。 当 AKS 节点上出现任何预期的系统故障时，AKS 会及时自动处理资源，而不会中断系统处理。
AKS 群集受具有 Web 应用程序防火墙（WAF）的 Azure 应用程序网关保护，并且可以在 检测 模式下配置为记录警报和威胁。 最好使用 防护 模式，从而主动阻止检测到的入侵和攻击。 有关详细信息，请参阅 Azure Kubernetes 服务（AKS）中网络连接和安全性的最佳做法。
PCI DSS 4.0.1 需要定期进行漏洞扫描、渗透测试和使用入侵检测和/或入侵防护技术。 使用自动化工具扫描云和容器环境中的漏洞和配置错误。 定期测试安全系统和进程，包括临时资源和容器业务流程系统。
你的责任
| Requirement | 职责 |
|---|---|
| 要求 11.1 | 实施过程以测试是否存在无线接入点（802.11），并按季度检测和识别所有已授权和未经授权的无线接入点。 |
| 要求 11.2 | 至少每季度运行内部和外部网络漏洞扫描（例如新的系统组件安装、网络拓扑更改、防火墙规则修改、产品升级）后，扫描网络。 |
| 要求 11.3 | 实现渗透测试的方法，其中包括： |
| 要求 11.4 | 使用入侵检测和/或入侵防护技术检测和/或防止入侵网络。 |
| 要求 11.5 | 部署更改检测机制（例如文件完整性监视工具），提醒人员未经授权修改（包括关键系统文件、配置文件或内容文件的更改、添加和删除）;并将软件配置为至少每周执行关键文件比较。 |
| 要求 11.6 | 确保记录安全监视和测试的安全策略和作过程，以供所有受影响的各方了解。 |
要求 11.1
实施过程以测试是否存在无线接入点（802.11），并按季度检测和识别所有已授权和未经授权的无线接入点。
外部网络没有本文档的范围，必须单独评估。
你的责任
此体系结构及其实现不旨在通过无线连接支持本地或企业网络到云事务。 有关注意事项，请参阅官方 PCI DSS 4.0.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
部署更改跟踪解决方案（例如文件完整性监视解决方案），以提醒人员未经授权修改关键系统文件、配置文件或内容文件。 将产品配置为至少每周执行关键文件比较。
你的责任
在群集中，与 Kubernetes 感知的安全代理一起运行文件完整性监视（FIM）解决方案，以检测可能导致节点级更改的文件和系统级访问。 选择 FIM 解决方案时，请清楚地了解其功能和检测深度。 请考虑由信誉良好的供应商开发的软件。
重要
参考实现提供占位符 DaemonSet 部署来运行 FIM 解决方案反恶意软件代理。 代理将在群集中的每个节点 VM 上运行。 在此部署中放置你选择的反恶意软件。
检查 FIM 工具的所有默认设置，以确保这些值检测要涵盖的方案，并相应地调整这些设置。
使解决方案能够将日志发送到监视或 SIEM 解决方案，以便它们可以生成警报。 请注意日志架构更改，或者可能会错过关键警报。
CDE 中的其他任何计算都应启用更改跟踪。
要求 11.6
确保记录安全监视和测试的安全策略和作过程，以供所有受影响的各方了解。
你的责任
维护有关流程和策略的彻底文档至关重要。 维护有关强制策略的文档。 作为测试工作的一部分，包括评审节奏和评审条件。 确保团队了解渗透测试的各个方面。 制定有记录的修正计划，以缓解发现的风险。
对于从策略角度来看属于审批流程的人员来说，这一点很重要。
后续步骤
实现持续安全监视控制，以实现持续合规性和威胁检测。