可恢复性最佳做法

您的租户可能会发生意外删除和配置错误。 若要最大程度地减少这些意外事件的影响，必须针对这些事件的出现做好准备。

可恢复性是准备过程和功能，使你能够在意外更改后将服务返回到以前的运行状态。 意外的更改包括Microsoft Entra租户中应用程序、组、用户、策略和其他对象的软删除或硬删除或错误配置。

可恢复性有助于组织提高复原能力。 复原能力虽然与它相关，但有所不同。 复原能力指能经受系统组件中断并在对业务、用户、客户和操作影响最小的情况下恢复的能力。 有关如何使系统更具弹性的详细信息，请参阅 使用 Microsoft Entra ID 构建标识和访问管理弹性。

本文介绍如何最好地针对删除和错误配置做好准备，以最大程度地减少对组织业务造成的意外后果。

删除和配置错误

删除和配置错误对租户的影响不同。

删除

删除的影响取决于对象类型。

可以软删除对象类型，包括用户、Microsoft 365 组、云安全组和应用程序。 软删除的项将移至 Microsoft Entra ID 回收站。 位于回收站中时，这些项目无法使用，但仍会保留其所有属性。 可以使用Microsoft 图形 API调用或从Microsoft Entra 管理中心还原它们。 如果不在 30 天内还原处于软删除状态的项目，Microsoft Entra ID永久地硬删除它们。 从Microsoft Entra ID中删除进行恢复提供了支持软删除的对象表。

错误配置

错误配置是资源或策略的配置，它与组织策略或计划不同，并且会导致意外或不必要的后果。 租户范围设置或条件访问策略配置不当可能会严重影响组织的安全和公共形象。 配置不当可能会导致：

• 更改管理员、租户用户和外部用户与租户中资源交互的方式。
• 更改用户与其他租户交互的能力，以及外部用户与租户交互的能力。
• 导致拒绝服务。
• 中断数据、系统和应用程序之间的依赖关系。

有关错误配置以及如何从中恢复的详细信息，请参阅从错误配置中恢复。

与删除不同，错误配置会就地修改对象，而不是将它们移动到回收站。

共担责任

微软作为您的云服务提供商，与您的组织共同承担可恢复性的责任。

可以使用 Microsoft 提供的工具和服务来防范删除和错误配置问题。

业务连续性和灾难恢复计划

还原硬删除或配置错误的项是一个资源密集型过程。 可以通过提前规划来最大程度地减少所需的资源。 请考虑让特定的管理员团队负责还原。

测试恢复过程

为不同对象类别演练你的还原过程，并准备相应的通信内容。 请务必对测试对象进行测试，最好是在测试租户中。

测试您的计划可以帮助您确定：

• 对象状态文档的有效性和完整性。
• 解决问题的平均时间。
• 适当的通信及其受众。
• 预期的成功和潜在的挑战。

创建通信过程

创建预定义通信过程，让其他人了解问题以及还原时间线。 在还原通信计划中包括以下几个要点：

• 要发出的通信类型。请考虑创建预定义的模板。

• 要接收通信的利益干系人。 包括以下组（如适用）：

  • 受影响的业务所有者。
  • 负责执行恢复操作的管理员。
  • 业务和技术审批者。
  • 受影响的用户。

• 定义触发通信的事件，例如：

  • 初始删除。
  • 影响评估。
  • 解决问题的时间。
  • 还原。

记录已知的良好状态

定期将租户及其对象的状态记录并维护在外部版本控制存储库中。 如果发生硬删除或配置错误，文档将充当恢复路线图。

根据已部署的资源选择所需的 API 和导出技术。 尽管可以直接调用特定于资源的Microsoft Graph API，但其他Microsoft和非Microsoft选项可以抽象化和简化配置导出和下载过程。

• 配置快照——Microsoft Graph 中统一的快照 API（位于租户配置管理 (TCM) API 中）简化了提取租户内多个工作负载（如 Microsoft Entra、Microsoft Intune 和 Exchange Online）的当前配置这一过程。 租户将快照存储 7 天，以便下载快照以供外部保留。 TCM 架构支持Microsoft Entra资源和属性的子集。 查看子集列表以确定 TCM 是否提供足够的覆盖范围，而不是直接调用Microsoft Graph API。
• * Microsoft Graph API — 使用 Microsoft Graph API 定期导出 TCM 尚不支持的所有关键目录对象的配置。 若要导出配置设置，请使用开源工具Microsoft Entra导出程序。
• 第三方解决方案 - 若要以声明性格式导出、规范化和存储Microsoft Entra配置，请评估非Microsoft配置管理和基础结构即代码工具。 这些解决方案可能抽象化基础 API，简化大规模配置捕获，并支持作为恢复工作流的一部分重复的比较和设置应用。

将配置基线存储在版本控制的存储库（如具有足够保留期的Azure DevOps或GitHub）中。 将通过不同捕获机制获取的配置摘录在逻辑上分开，并分别进行管理。 例如，虽然 TCM 快照和直接导出的 Microsoft 图形 API 数据都有助于构成总体的已知良好状态，但不要将它们组合使用，即使它们具有相同的格式（例如 JSON）。 原因是，TCM 快照的范围将其限定在受支持的资源和属性内，而你不能依靠这些资源和属性在该受支持范围之外重新创建或应用配置。

常用Microsoft Graph API

可以使用Microsoft Graph API 导出许多Microsoft Entra配置的当前状态。 API 涵盖以下许多场景：关于以前状态的参考资料或从导出副本应用该状态的功能可能对于保持业务运行至关重要。

Microsoft Graph API 可以根据组织需求高度自定义。 若要实现备份或参考材料的解决方案，开发人员需要设计代码来查询、存储和显示数据。 许多实现使用联机代码存储库作为此功能的一部分。

用于恢复的有用 APIS

*通过提供给有限数量的管理员的访问权限安全地存储这些配置导出。

Microsoft Entra导出程序可以提供所需的大部分文档：

• 验证是否已实现所需的配置。
• 使用导出程序捕获当前配置。
• 查看导出内容，了解未导出的租户设置，并手动记录这些设置。
• 使用有限的访问权限将输出存储在安全位置。

使用条件访问图形 API 来管理代码等策略。

映射对象之间的依赖关系

删除某些对象可能会导致因依赖关系而产生的连锁反应。 例如，删除用于应用程序分配的云安全组将导致该组成员的用户无法访问该组分配到的应用程序。

通用依赖项

监视和数据保留

Microsoft Entra审核日志包含有关租户中执行的所有删除和配置操作的信息。 建议将这些日志导出到安全信息和事件管理工具，例如 Microsoft Sentinel。 还可以使用Microsoft Graph来审核更改并生成自定义解决方案，以监视一段时间内的差异。 有关使用 Microsoft Graph 查找已删除项的详细信息，请参阅 List 已删除的项目 - Microsoft Graph v1.0。

审核日志

当租户中的对象从活动状态被删除（无论是从活动到软删除还是从活动到硬删除）时，审核日志始终会记录“删除 <object>”事件。

对于支持软删除的对象类型，删除事件（例如应用程序、服务主体、用户、Microsoft 365 组和云安全组）表示发生了软删除。 对于其他对象类型，Delete 事件是硬删除。

有关监视配置更改的信息，请参阅从错误配置恢复。

使用工作簿跟踪配置更改

Azure Monitor工作簿可帮助监视配置更改。

敏感操作报告工作簿可以帮助识别可能指示盗用的可疑应用程序和服务主体活动，包括：

• 修改后的应用程序或服务主体凭据或身份验证方法。
• 向服务主体授予的新权限。
• 服务主体的目录角色和组成员身份更新。
• 修改后的联合设置。

跨租户访问活动工作簿可帮助你监视用户正在访问外部租户中的哪些应用程序，以及外部用户正在访问你的租户中的哪些应用程序。 使用此工作簿可帮助您识别租户之间入站或出站应用程序访问中的异常更改。

运营安全

防止不需要的更改比重新创建和重新配置对象要容易得多。 在更改管理过程中包括以下任务，以最大程度地减少事故：

• 使用最低特权模型。 确保团队中的每个成员都拥有完成日常任务所需的最低权限。 需要制定一个过程来提升不常见任务的权限。
• 对象的管理控制支持配置和删除。 对于不需要创建、更新或删除 (CRUD) 操作的任务，请使用权限较低的角色（例如安全读取者角色）。 如果需要 CRUD 操作，请尽可能使用特定于对象的角色。 例如，用户管理员只能删除用户，应用程序管理员只能删除应用程序。 尽可能使用这些受到更多限制的角色。
• 使用Privileged Identity Management（PIM）。 PIM 支持实时提升特权来执行硬删除等任务。 可以将 PIM 配置为对特权提升进行通知或审批。
• 在 Microsoft Entra ID 中使用 受保护的操作 可以强制实施额外的条件访问策略保护层，无论使用何种角色或用户如何获得权限。 受保护的操作应应用于敏感操作，例如硬删除、身份验证上下文更改和条件访问更改。

后续步骤

• 从删除中恢复
• 从错误配置中恢复