保护 Azure 资源免受破坏性网络攻击
本文提供了应用零信任原则以通过以下方式保护 Microsoft Azure 资源免受破坏性网络攻击的步骤：
| 零信任原则 | 定义 |
|---|---|
| 显式验证 | 始终根据所有可用的数据点进行身份验证和授权。 |
| 使用最低权限访问 | 使用实时和恰好足够的访问权限 (JIT/JEA)、基于风险的自适应策略和数据保护，来限制用户访问。 |
| 假定数据泄露 | 最大限度地减少影响范围，并对访问进行分段。 验证端对端加密并使用分析来获取可见性、驱动威胁检测并改进防御。 通过资源锁、虚拟机的备份和灾难恢复、数据保护和数据可用性服务、恢复基础结构防护、基于配置的服务以及平台自动化和 DevOps 工具来增强防御。 对于威胁检测，请使用 Microsoft Sentinel 和高级多阶段检测，并为 Azure 资源准备事件响应计划。 |
本文提供有关如何完成以下操作的指导：
- 保护 Microsoft Azure 资源免受破坏性网络攻击。
- 及时检测出发生的网络攻击。
- 如何应对它们。
本文旨在帮助技术实现人员支持实现安全漏洞预防和恢复基础结构零信任业务场景。
参考体系结构
下图显示了此零信任的参考体系结构指导，其中对每种保护类别进行了分组。
此 Azure 环境包括：
| 组件 | 说明 |
|---|---|
| A | 虚拟机及其文件 |
| B | 数据服务及其数据 |
| C | 恢复基础结构，包括文件、模板和自动化脚本 |
| D | 基于配置的服务 |
| E | 平台自动化和 DevOps 工具（未显示） |
本文的步骤 1 详细介绍了保护每种类型的资产的任务。
本文内容
本文将介绍在参考体系结构中应用零信任原则的步骤。
| 步长 | 任务 |
|---|---|
| 1 | 配置针对网络攻击的保护。 |
| 2 | 配置网络攻击检测。 |
| 3 | 准备事件响应计划。 |
步骤 1：配置针对网络攻击的保护
作为迁移工作的一部分，许多组织都为其 Azure 虚拟机实施了备份和灾难恢复解决方案。 例如，可以使用 Azure 原生解决方案，或者选择为云生态系统使用自己的第三方解决方案。
虽然保护虚拟机及其应用和数据非常重要，但将保护范围扩大到虚拟机之外也至关重要。 本部分详细介绍了有关如何保护 Azure 中不同类型的资源免受破坏性网络攻击的注意事项和建议。
除了特定于服务的注意事项外，还应考虑使用资源锁来保护服务的管理平面，从而防止删除服务。 还可以使用资源锁来以只读形式呈现资源。 配合使用资源锁和受控访问权限，可防止 Azure 资源遭修改或破坏，从而降低其在网络攻击中被销毁的可能性。
为了防止资源锁产生意外结果，应查看应用锁之前的注意事项，以确保在将锁应用于相应的资源后，资源仍可正常运行。 例如，锁定虚拟网络 (VNet) 而不是整个资源组可以防止锁对资源组内的其他资源造成过多限制。 出于这些考虑，应优先锁定那些一旦更改或删除就会造成最大破坏的资源。
锁定可能还需要考虑正在故障转移的工作负载的恢复时间目标。 灾难恢复计划应考虑到锁，并且应该有一个经过测试的过程可用于以可控方式移除锁。 需要培训管理员和 SecOps 员工，使其了解如何在日常操作和紧急情况下管理锁。
有权移除锁的管理员应受到限制，并且应需要 JIT 访问权限，例如 Microsoft Entra Privileged Identity Management 提供的访问权限。 对资源更改锁的访问受 Microsoft.Authorization/locks/* 作用域控制，不应作为长期访问权限的一部分授予。
A. 保护虚拟机
对于基于虚拟机的工作负载（包括规模集和 Kubernetes 群集），除了在管理平面中使用资源锁外，还需要计划两层保护。
首先，需要计划备份虚拟机中的数据，以便在发生攻击时可以还原丢失的数据，其中包括 Azure Kubernetes 服务 (AKS)。 还需要使用软删除控件来保护备份数据本身免受攻击。 有关配置备份的信息，请参阅：
其次，需要计划在所在地区的底层基础结构受到攻击时将服务器还原到新位置的能力。 有关在虚拟机上配置复制的信息，请参阅为 Azure VM 设置灾难恢复。 这包括根据故障转移期间使用的资源配置应用程序和设置。
重要
对虚拟机规模集中包含的虚拟机使用 Azure Site Recovery 时，可以复制虚拟机状态。 但是，复制的设备不支持缩放。
对于某些基于虚拟机的工作负载（例如 Kubernetes 群集），无法通过 Azure Site Recovery 复制服务器的实际状态。 可能需要其他解决方案，例如主动/被动配置。
B. 保护数据服务
数据服务是一个非正式的服务集合，其中包含对操作至关重要的数据，但资源本身并不那么重要。 例如，以相同方式配置并托管相同数据的两个存储帐户之间几乎没有区别。
数据服务不同于虚拟机，后者的操作系统配置可能独立于正在运行的应用程序，也独立于管理平面的配置。 因此，这些服务：
- 通常包含自己的故障转移工具，例如存储帐户作为异地冗余存储 (GRS) 层的一部分复制到另一个区域的能力。
- 对于如何保护数据免受攻击，以及在受到攻击时如何使数据再次可用，有自己的考虑。
下表提供了常用服务的数据保护和可用性参考，但你应研究每个服务的产品文档以了解可用的选项。
| 服务 | 数据保护 | 数据可用性 |
|---|---|---|
| Azure 文件 | 备份 Azure 文件共享 防止意外删除 Azure 文件共享 |
在 Azure 文件共享上启用软删除 |
| Azure Blob 存储 | 对 Blob 数据启用时间点还原 使用不可变的存储来存储业务关键型 Blob 数据 |
Azure Blob 数据保护概述 启用和管理容器的软删除 为 blob 启用软删除 |
| Azure SQL 数据库 | Azure SQL 数据库中的自动备份 | 活动异地复制 Azure SQL 数据库的故障转移组 |
| SQL 托管实例 | Azure SQL 托管实例中的自动备份 | Azure SQL 托管实例的故障转移组 |
| Azure VM 上的 SQL | Azure VM 中 SQL Server 的备份和还原 | Azure 虚拟机中 SQL Server 的故障转移群集实例 |
| Key Vault | Azure 密钥保管库备份和还原 | 为密钥保管库启用软删除和清除保护 Azure Key Vault 可用性和冗余 |
警告
不支持某些存储帐户恢复方案。 有关详细信息，请参阅不支持的存储恢复。
°C 保护恢复基础结构
除了保护工作负载上的资源之外，还需要保护用于在中断后还原功能的资源，例如恢复过程文档、配置脚本和模板。 如果攻击者可以将恢复基础结构作为目标并造成其中断，则整个环境都可能会遭到入侵，导致从攻击中恢复的时间大大延迟，并使组织容易受到勒索软件的攻击。
对于受 Azure 备份保护的数据，使用 Azure 备份的软删除功能可以恢复备份数据，即使是已删除的数据也是如此。 此外，增强型软删除会强制分配软删除，并允许定义保持期。
为了进一步增强安全性，请对关键操作实施多用户授权 (MUA)，这要求在执行关键操作之前先获得两个或更多用户的批准。 这了额外增加了一层安全保障，确保任何单个用户（也就是只有一个用户帐户的攻击者）都无法破坏备份的完整性。 启用并配置 MUA，以保护备份策略免遭未经授权的更改和删除。
可以使用资源锁和 JEA/JIT 访问权限来保护 Azure Site Recovery，以防止未经授权的访问，并及时检测出面临风险的资源。
使用 Azure Site Recovery 复制已使用 Azure 磁盘加密 (ADE) 或客户管理的密钥 (CMK) 加密的虚拟机时，请确保加密密钥存储在目标区域的 Azure Key Vault 中。 将密钥存储在目标区域中有助于在故障转移后无缝访问密钥，并维护数据安全连续性。 为了保护 Azure Key Vault 免受破坏性网络攻击，请启用高级威胁防护功能，例如软删除和清除保护。
有关加密虚拟机的分步复制指南，请参阅以下内容：
D. 保护基于配置的服务
基于配置的 Azure 服务是指除了管理平面中的配置外没有其他数据的 Azure 服务。 这些资源通常基于基础结构，是支持工作负载的基础服务。 示例包括 VNet、负载均衡器、网络网关和应用程序网关。
由于这些服务是无状态的，因此没有要保护的操作数据。 保护这些服务的最佳选择是使用基础结构即代码 (IaC)部署模板（如 Bicep），这些模板可以在发生破坏性攻击后还原这些服务的状态。 也可以使用脚本进行部署，但 IaC 部署更适合在仅有少数服务受到影响的现有环境中还原功能。
只要可以部署以相同方式配置的资源，服务就可以继续运行。 可以使用编程部署来从攻击中恢复，而不是尝试备份和维护这些资源的副本。
有关使用 IaC 的详细信息，请参阅有关使用基础结构即代码的建议。
E. 保护平台自动化和 DevOps 工具
如果使用编程部署或其他类型的自动化，则还需要保护平台自动化和 DevOps 工具资源。 有关保护部署基础结构的示例，请参阅保护 DevOps CI/CD 管道和保护开发生命周期的建议。
但是，还应计划保护代码本身，具体取决于所使用的源代码管理工具。 例如，GitHub 提供了有关针对源代码存储库备份存储库的说明。
还应查看具体的服务，以确定如何最好地保护源代码和管道免受攻击和破坏。
对于托管在虚拟机上的组件（如生成代理），可以使用基于虚拟机的适当保护计划来确保代理在需要时可用。
步骤 2：配置网络攻击检测
要检测针对 Azure 基础结构的攻击，请先使用 Microsoft Defender for Cloud，这是一个云原生应用程序保护平台 (CNAPP)，提供的安全措施和做法旨在保护基于云的应用程序免受各种网络威胁和漏洞的影响。
Defender for Cloud 与用于 Azure 组件的其他计划结合使用，可从 Azure 组件收集信号，并为服务器、容器、存储、数据库和其他工作负载提供特定保护。
下图显示安全事件信息从 Azure 服务流经 Defender for Cloud 和 Microsoft Sentinel 的流程。
在该图中：
- Azure 服务将信号发送到 Microsoft Defender for Cloud。
- Microsoft Defender for Cloud 及附加计划（例如 Defender for Servers）分析信号以增强威胁检测，并将安全信息和事件管理 (SIEM) 数据发送到 Microsoft Sentinel。
- Microsoft Sentinel 使用 SIEM 数据进行网络攻击检测、调查、响应和主动搜寻。
按照本文步骤 1 中的建议更好地保护 Azure 资源后，需要制定一个使用 Microsoft Sentinel 检测破坏性网络攻击的计划。 一开始可以使用 Microsoft Sentinel 中的高级多阶段攻击检测。 使用它可以针对数据销毁、拒绝服务、恶意管理活动等特定场景生成检测。
在准备工作负载进行响应时，需要：
- 确定如何判断资源是否受到攻击。
- 确定如何由此捕获并引发事件。
步骤 3：准备事件响应计划
需要在事件发生之前针对破坏性网络攻击制定明确且可立即实施的事件响应计划。 在事件发生期间，没有时间确定如何阻止正在进行的攻击或还原损坏的数据和服务。
Azure 应用程序和共享服务都应具有响应和恢复计划，其中包括用于还原虚拟机、数据服务、配置服务和自动化/DevOps 服务的 playbook。 每个应用程序或服务领域都应有其自己的定义，以及明确定义的依赖关系。
Playbook 应：
包括以下场景的流程：
包括构成此服务的任何其他资源的还原过程。
作为 SecOps 维护过程的一部分定期进行测试。
建议训练
- 实施 Privileged Identity Management
- 设计用于备份和灾难恢复的解决方案
- 使用 Microsoft Defender for Cloud 改进云安全状况
- 使用 Microsoft Sentinel 创建检测和执行调查
后续步骤
继续实施安全漏洞预防和恢复基础结构。
参考
请参阅以下链接，了解本文所述的各种服务和技术。