为容器和业务流程指定安全要求
本单元总结了适用于 Azure Kubernetes 服务的 Azure 安全基线。 对于具有许多控件的区域，我们仅包含提到的前五个。
有关 Microsoft Cloud 安全基准的更多背景信息，请参阅 Microsoft 网络安全参考体系结构和云安全基准简介。
在下表中，我们包含了完整基线中的控件，其中：
- 安全控件受支持，但默认情况下未启用
- 有明确的指导，其中包含了客户要采取的操作
| 区域 | 控制 | 指南摘要 |
|---|---|---|
| 网络安全 | 1.1：保护虚拟网络中的 Azure 资源 | 默认情况下，随着 Microsoft Azure Kubernetes 服务 (AKS) 群集的创建，会自动创建一个网络安全组和路由表。 使用负载均衡器、端口映射或入口路由创建服务时，AKS 会自动修改网络安全组以便流量流向正确的方向。 |
| 1.2：监视和记录虚拟网络、子网和 NIC 的配置与流量 | 使用 Microsoft Defender for Cloud 并遵循其网络保护建议来保护 Azure Kubernetes 服务 (AKS) 群集正在使用的网络资源。 | |
| 1.3：保护关键 Web 应用程序 | 在 AKS 群集前面使用启用了 Web 应用程序防火墙 (WAF) 的 Azure 应用程序网关，通过筛选到 Web 应用程序的传入流量，来提供额外的安全层。 Azure WAF 使用一组由开放式 Web 应用程序安全项目 (OWASP) 提供的规则来监视攻击，例如针对该流量的跨网站脚本攻击或 cookie 篡改。 | |
| 1.4：拒绝与已知恶意的 IP 地址进行通信 | 在部署了 Azure Kubernetes 服务 (AKS) 组件来防范 DDoS 攻击的虚拟网络上启用 Microsoft 分布式拒绝服务 (DDoS) 标准保护。 | |
| 1.5：记录网络数据包 | 如果需要使用网络观察程序数据包捕获才能调查异常活动，请使用它。 | |
| 日志记录和监视 | 2.1：使用批准的时间同步源 | 除了 UDP 端口 123 和网络时间协议 (NTP)，Azure Kubernetes 服务 (AKS) 节点还使用 ntp.ubuntu.com 进行时间同步。 |
| 2.2：配置中心安全日志管理 | 从 Azure Kubernetes 服务 (AKS) 主组件、kube-apiserver 和 kube-controller-manager 启用审核日志，这些组件作为托管服务提供。 | |
| 2.3：为 Azure 资源启用审核日志记录 | 使用活动日志监视 Azure Kubernetes 服务 (AKS) 资源上的操作，查看所有活动及其状态。 | |
| 2.4：从操作系统收集安全日志 | 启用 Log Analytics 代理的自动安装，以从 AKS 群集节点收集数据。 此外，从 Microsoft Defender for Cloud 启用 Azure Log Analytics 监视代理的自动预配，自动预配默认处于关闭状态。 | |
| 2.5：配置安全日志存储保留期 | 将 Azure Kubernetes 服务 (AKS) 实例载入 Azure Monitor，并根据组织的合规性要求设置相应的 Azure Log Analytics 工作区保持期。 | |
| 标识和访问控制 | 3.1：维护管理帐户的清单 | Azure Kubernetes 服务 (AKS) 本身不提供存储常规用户帐户和密码的标识管理解决方案。 通过 Microsoft Entra 集成，可以授予用户或组对命名空间内或整个群集中的 Kubernetes 资源的访问权限。 |
| 3.2：在适用的情况下更改默认密码 | Azure Kubernetes 服务 (AKS) 没有通用默认密码的概念，也没有提供可以存储常规用户帐户和密码的标识管理解决方案。 通过 Microsoft Entra 集成，可以授予对命名空间内或整个群集中 AKS 资源的基于角色的访问权限。 | |
| 3.3：使用专用管理帐户 | 将 Azure Kubernetes 服务 (AKS) 群集的用户身份验证与 Microsoft Entra ID 集成。 使用 Microsoft Entra 身份验证令牌登录到 AKS 群集。 | |
| 3.4：将单一登录 (SSO) 与 Microsoft Entra ID 配合使用 | 将 Azure Kubernetes 服务 (AKS) 的单一登录与 AKS 群集的 Microsoft Entra 集成身份验证配合使用。 | |
| 3.5：对所有基于 Microsoft Entra ID 的访问使用多重身份验证 | 将 Azure Kubernetes 服务 (AKS) 的身份验证与 Microsoft Entra ID 集成。 | |
| 数据保护 | 4.1：维护敏感信息的清单 | 指导：对与 Azure Kubernetes 服务 (AKS) 部署相关的资源使用标记，以帮助跟踪存储或处理敏感信息的 Azure 资源。 |
| 4.2：隔离存储或处理敏感信息的系统 | 使用 Azure Kubernetes 服务 (AKS) 以逻辑方式隔离同一群集中的团队和工作负载，以提供最少数量的特权，将范围限定为每个团队所需的资源。 | |
| 4.3：监视和阻止未经授权的敏感信息传输 | 使用 Azure 市场中有关网络外围的第三方解决方案，监视并阻止敏感信息的未授权传输，同时提醒信息安全专业人员。 | |
| 4.4：加密传输中的所有敏感信息 | 为 Azure Kubernetes 服务 (AKS) 部署创建 HTTPS 入口控制器并使用自己的 TLS 证书（或可选的 Let's Encrypt）。 | |
| 4.5：使用有效的发现工具识别敏感数据 | 数据标识、分类和丢失防护功能尚不适用于 Azure 存储或计算资源。 如果需要出于合规性目的使用这些功能，请实施第三方解决方案。 Microsoft 管理底层平台，并将所有客户内容视为敏感数据，竭尽全力防止客户数据丢失和泄露。 | |
| 漏洞管理 | 5.1：运行自动漏洞扫描工具 | 使用 Microsoft Defender for Cloud 监视 Azure 容器注册表（包括 Azure Kubernetes 服务 (AKS) 实例）是否存在漏洞。 启用 Microsoft Defender for Cloud 中的容器注册表，以确保 Microsoft Defender for Cloud 已准备好扫描推送到注册表中的映像。 |
| 5.2：部署自动操作系统修补管理解决方案 | 安全更新会自动应用到 Linux 节点，以保护客户的 Azure Kubernetes 服务 (AKS) 群集。 这些更新包括 OS 安全修复项或内核更新。 请注意，使 Windows 服务器节点保持最新状态的过程与运行 Linux 的节点不同，因为 Windows Server 节点不接收每日更新。 | |
| 5.3：为第三方软件部署自动化补丁管理解决方案 | 实现手动过程，确保 Azure Kubernetes 服务 (AKS) 群集节点的第三方应用程序在群集生存期内保持修补状态。 这可能需要启用自动更新、监视节点或定期重新启动。 | |
| 5.4：比较连续进行的漏洞扫描 | 以一致的间隔导出 Microsoft Defender for Cloud 扫描结果，并比较结果以验证漏洞是否已修复。 | |
| 5.5：使用风险评级过程来确定已发现漏洞的修正措施的优先级 | 使用 Microsoft Defender for Cloud 提供的严重性评级来确定漏洞修正的优先级。 | |
| 清单和资产管理 | 6.1：使用自动化资产发现解决方案 | 使用 Azure Resource Graph 查询/发现订阅中的所有资源（例如计算、存储、网络等）。 确保你在租户中拥有适当的（读取）权限，并且可以枚举所有 Azure 订阅以及订阅中的资源。 |
| 6.2：维护资产元数据 | 将标记应用到包含元数据的 Azure 资源，以便有条理地将其组织成某种分类。 | |
| 6.3：删除未经授权的 Azure 资源 | 在适用的情况下，请使用标记、管理组和单独的订阅来组织和跟踪资产。 | |
| 6.4：定义并维护已批准 Azure 资源的清单 | 根据组织的业务需求，为计算资源定义已批准的 Azure 资源和软件的列表。 | |
| 6.5：监视未批准的 Azure 资源 | 在 Azure Policy 中使用以下内置策略定义，对可以在客户订阅中创建的资源类型施加限制：不允许的资源类型、允许的资源类型 | |
| 安全配置 | 7.1：为所有 Azure 资源建立安全配置 | 使用“Microsoft.ContainerService”命名空间中的 Azure Policy 别名创建自定义策略，以审核或强制实施 Azure Kubernetes 服务 (AKS) 实例的配置。 使用内置 Azure Policy 定义。 |
| 7.2：建立安全的操作系统配置 | Azure Kubernetes 服务 (AKS) 群集部署在具有安全优化 OS 的虚拟主机上。 主机 OS 还包含了附加的安全强化步骤，以减少攻击面，并允许以安全的方式部署容器。 | |
| 7.3：维护安全的 Azure 资源配置 | 使用 pod 安全策略保护 Azure Kubernetes 服务 (AKS) 群集。 限制可以计划哪些 pod 来提高群集的安全性。 | |
| 7.4：维护安全的操作系统配置 | Azure Kubernetes 服务 (AKS) 群集部署在具有安全优化 OS 的虚拟主机上。 主机 OS 还包含了附加的安全强化步骤，以减少攻击面，并允许以安全的方式部署容器。 | |
| 7.5：安全存储 Azure 资源的配置 | 如果使用自定义 Azure Policy 定义，请使用 Azure Repos 安全地存储和管理配置。 使用 Azure 资源管理器以 JavaScript 对象表示法 (JSON) 导出 Azure Kubernetes 服务 (AKS) 配置的模板。 | |
| 恶意软件防护 | 8.1：使用集中管理的反恶意软件 | AKS 代表你管理代理节点的生命周期和操作 - 不支持修改与该代理节点关联的 IaaS 资源。 但是，对于 Linux 节点，你可以使用守护程序集来安装自定义软件，例如反恶意软件解决方案。 |
| 8.2：预先扫描要上传到非计算 Azure 资源的文件 | 预先扫描要上传到 AKS 资源的任何文件。 如果使用 Azure 存储帐户作为数据存储或跟踪 AKS 群集的 Terraform 状态，请使用 Microsoft Defender for Cloud 的数据服务威胁检测来检测已上传到存储帐户的恶意软件。 | |
| 步骤 8.3：确保反恶意软件和签名已更新 | AKS 代表你管理代理节点的生命周期和操作 - 不支持修改与该代理节点关联的 IaaS 资源。 但是，对于 Linux 节点，你可以使用守护程序集来安装自定义软件，例如反恶意软件解决方案。 | |
| 数据恢复 | 9.1：确保定期执行自动备份 | 使用适合存储类型的适当工具（如 Velero）备份数据，它可以备份持久卷以及其他群集资源和配置。 定期验证这些备份的完整性和安全性。 |
| 9.2：执行完整系统备份，并备份客户管理的所有密钥 | 使用适合存储类型的适当工具（如 Velero）备份数据，它可以备份持久卷以及其他群集资源和配置。 | |
| 9.3：验证所有备份，包括客户管理的密钥 | 定期在 Velero 备份中执行内容的数据还原。 如果需要，对还原到隔离的虚拟网络进行测试。 | |
| 9.4：确保保护备份和客户管理的密钥 | 使用适合存储类型的适当工具（如 Velero）备份数据，它可以备份持久卷以及其他群集资源和配置。 | |
| 事件响应 | 10.1：创建事件响应指导 | 为组织制定事件响应指南。 确保在书面的事件响应计划中定义人员职责，以及事件处理/管理从检测到事件后审查的各个阶段。 |
| 10.2：创建事件评分和优先级设定过程 | 按 Microsoft Defender for Cloud 分配给警报的严重性确定必须先进行调查的警报的优先顺序。 严重性取决于 Microsoft Defender for Cloud 在发出警报时所依据的检测结果或分析结果的置信度，以及导致发出警报的活动背后的恶意企图的置信度。 | |
| 10.3：测试安全响应过程 | 定期进行练习来测试系统的事件响应功能。 查明弱点和差距，并根据需要修改你的事件响应计划。 | |
| 10.4：提供安全事件联系人详细信息，并针对安全事件配置警报通知 | 如果 Microsoft 安全响应中心 (MSRC) 发现客户数据被某方非法访问或未经授权访问，Microsoft 会使用安全事件联系信息联系用户。 | |
| 10.5：将安全警报整合到事件响应系统中 | 使用连续导出功能导出 Microsoft Defender for Cloud 警报和建议。 使用连续导出可以手动导出或者持续导出警报和建议。 | |
| 渗透测试和红队练习 | 11.1：定期对 Azure 资源执行渗透测试，确保修正所有发现的关键安全问题 | 请遵循 Microsoft 互动规则，确保你的渗透测试不违反 Microsoft 政策。 |