Compartilhar via

使用 Microsoft Entra ID 创建可复原的访问控制管理策略

注释

本文档中包含的信息代表 Microsoft Corporation 在发布之日对所讨论问题的当前观点。 由于 Microsoft 必须响应不断变化的市场条件，因此不应将其解释为 Microsoft 作出的承诺，并且 Microsoft 无法保证在发布日期之后提供的任何信息的准确性。

如果组织依靠单一访问控制（如多重身份验证或单一网络位置）来保护其 IT 系统，那么当该单一访问控制变得不可用或配置错误时，组织很容易因无法访问其应用和资源而受到影响。 例如，自然灾害可能导致大部分电信基础设施或公司网络无法使用。 这种中断可能会导致最终用户和管理员无法登录。

本文档为组织提供了策略方面的指导，组织可采用这些策略来提供复原能力，以降低意外中断期间的锁定风险，具体方案如下：

  • 组织可以通过实施缓解策略或应急计划，在中断之前提高其复原能力，以降低锁定风险。
  • 组织可以通过制定缓解策略和应急计划，在中断期间继续访问他们选择的应用和资源。
  • 组织应确保在中断之后以及在回滚其实施的任何应急计划之前保留日志等信息。
  • 尚未实施预防策略或备选计划的组织可能能够实施紧急选项来应对中断。

重要指导

本文档有四个要点：

  • 使用紧急访问帐户避免管理员锁定。
  • 使用条件访问而不是基于用户的 MFA 来实现 MFA。
  • 通过使用多种条件访问控制来缓解用户锁定风险。
  • 通过为每个用户预配多种身份验证方法或等效项来缓解用户锁定风险。

中断前

缓解实际中断风险必须是组织处理可能出现的访问控制问题的重中之重。 缓解措施包括规划实际事件和实施策略，以确保访问控制和操作在中断期间不受影响。

为什么需要可复原的访问控制？

身份是控制用户访问应用和资源的平面。 标识系统可控制哪些用户以及用户在哪些条件（例如访问控制或身份验证要求）下有权访问应用程序。 如果由于无法预料的情况，无法在一个或多个身份验证或访问控制要求下对用户进行身份验证，则组织可能会遇到以下一个或两个问题：

  • 管理员锁定：管理员无法管理租户或服务。
  • 用户锁定：用户无法访问应用或资源。

管理员锁定应急计划

Microsoft建议组织拥有两个仅限云使用的紧急访问帐户，并将其永久分配为全局管理员角色。 这些帐户具有很高的特权，不会分配给特定个人。 这些帐户仅限于紧急或“破窗式”场景，在这种场景下，普通帐户无法使用，或者所有其他管理员被意外锁定。

缓解用户锁定

若要缓解用户锁定风险，请使用包含多种控制的条件访问策略，以便用户可以选择如何访问应用和资源。 通过为用户提供多种选择，例如，使用 MFA 登录或从受管理设备登录或从公司网络登录，用户可以在其中一种访问控制不可用时，使用其他选项来继续工作。

Microsoft 的建议

在组织的现有条件访问策略中加入以下访问控制机制：

  • 为依赖于不同通信通道的每个用户预配多个身份验证方法，例如，Microsoft Authenticator应用（基于 Internet）、OATH 令牌（在设备上生成）和短信（电话）。
  • 在Windows 10设备上部署Windows Hello for Business，以便直接从设备登录满足 MFA 要求。
  • 通过 Microsoft Entra 混合联接或 Microsoft Intune 使用受信任的设备。 受信任的设备将改善用户体验，因为受信任的设备本身就能满足策略的强身份验证要求，无需向用户发出 MFA 质询。 而在注册新设备以及从不受信任的设备访问应用或资源时，需使用 MFA。
  • 如果要使用Microsoft Entra多重身份验证 NPS 扩展保护 VPN 访问，请考虑将 VPN 解决方案联合为 SAML 应用并确定应用类别，如下所示。

注释

基于风险的策略需要Microsoft Entra ID P2 许可证。

以下示例介绍了在为用户提供可复原的访问控制来访问其应用和资源时所必须创建的策略。 此示例中需要一个安全组 AppUsers（包含要授予其访问权限的目标用户）、一个名为 CoreAdmins 的组（包含核心管理员），以及一个名为 EmergencyAccess 的组（包含紧急访问帐户）。 此示例策略集将在 AppUsers 中的选定用户从受信任的设备进行连接时向其授予对选定应用的访问权限，或提供强身份验证（例如 MFA）。 它将紧急帐户和核心管理员排除在外。

条件访问缓解策略集：

  • 策略 1：阻止目标组外部的人员进行访问
    • 用户和组：包括所有用户。 排除 AppUsers、CoreAdmins 和 EmergencyAccess
    • 云应用：包括所有应用
    • 条件：（无）
    • 授予控制权：阻止
  • 策略 2：向要求执行 MFA 或使用受信任设备的 AppUsers 授予访问权限。
    • 用户和组：包括应用用户。 排除 CoreAdmins 和 EmergencyAccess
    • 云应用：包括所有应用
    • 条件：（无）
    • 授予控制权：授予访问权限，要求执行多重身份验证，要求设备合规。 对于多个控件：需要从已选控件中选择一个。

用户锁定应对措施

或者，组织也可以创建应急策略。 若要创建应急策略，就必须在业务连续性、运营成本、财务成本和安全风险之间定义权衡标准。 例如，可以仅针对一部分用户、一部分应用、一部分客户端或一部分位置激活应急策略。 在未实施缓解方法的中断期间，应急策略将为管理员和最终用户提供对应用和资源的访问权限。 Microsoft 建议在应急策略不使用时启用仅限报告模式，以便管理员可以在策略需要启用时监视其潜在影响。

了解你在中断期间可能面临的风险有助于降低风险，是规划过程中的关键环节。 若要创建应急计划，请首先确定组织的以下业务要求：

  1. 提前确定任务关键应用：即使在风险/安全威胁较低的情况下也必须为其提供访问权限的应用有哪些？ 为这些应用生成一个列表，确保你的其他利益干系人（业务部门、安全部门、法律部门、领导层）都同意：即使所有访问控制都失效，这些应用仍必须继续运行。 你最终可能会对应用进行以下分类：
    • 类别 1 任务关键应用：不可用时间不能超过几分钟，例如直接影响组织收入的应用。
    • 类别 2 重要应用：企业需要这些应用在数小时内可以访问。
    • 类别 3 低优先级应用：可以承受几天的中断。
  2. 对于类别 1 和 2 的应用，Microsoft 建议你预先规划要允许的访问级别类型：
    • 是允许完全访问还是会话受限（例如限制下载）？
    • 是否允许访问应用的一部分，而不是整个应用？
    • 是否允许信息工作者访问而阻止管理员访问，直到访问控制恢复为止？
  3. 对于这些应用，Microsoft 还建议你对慎重开放哪些访问途径以及关闭哪些访问途径做好规划：
    • 您是否希望仅允许通过浏览器访问，并阻止可以保存脱机数据的富客户端访问？
    • 是否仅允许公司网络内部的用户访问，而阻止外部用户访问？
    • 在中断期间，是否仅允许从某些国家或地区进行访问？
    • 如果没有替代访问控制，你希望应急策略（尤其是对于任务关键应用）失败还是成功？

Microsoft 的建议

应变条件访问策略是一个备份策略，它省略Microsoft Entra多重身份验证、第三方 MFA、基于风险或基于设备的控制。 为了最大限度地减少启用应急策略时出现的意外中断，策略在不使用时应始终保持仅限报告模式。 管理员可以使用条件访问见解工作簿来监视其应急策略的潜在影响。 当组织决定激活你的应急计划时，管理员可以启用该策略并禁用基于控制的常规策略。

重要

在启用应急计划期间，禁用那些对用户强制执行安全措施的策略，即便是暂时的，也会削弱你的安全防御。

  • 如果一种凭据类型或访问控制机制的中断就会影响对应用的访问，则配置一组回退策略。 配置一个仅报告状态下需要作为控制机制的域加入策略，以作为需要第三方 MFA 提供程序的活动策略的备份。
  • 遵循密码指南白皮书中的做法，降低不良参与者在不需要 MFA 时猜测密码的风险。
  • 部署 Microsoft Entra Self-Service 密码重置 （SSPR） 和 Microsoft Entra 密码保护以确保用户不使用你选择禁止的常见密码和条款。
  • 如果未达到某个身份验证级别，则使用可限制应用内访问权限的策略，而不是简单地回退到完全访问权限。 例如：
    • 配置将受限会话声明发送到 Exchange 和SharePoint的备份策略。
    • 如果你的组织使用Microsoft Defender for Cloud Apps，请考虑回退到一个策略，该策略涉及 Defender for Cloud Apps，然后允许只读访问，但不允许上传。
  • 请将策略命名，以确保在中断期间能够轻松找到它们。 在策略名称中包含以下元素：
    • 策略的标签编号。
    • 要显示的文本：此策略仅用于紧急情况。 例如：在紧急情况下启用
    • 策略应用到的中断。 例如：在 MFA 中断期间
    • 一个序列号，用于显示策略的激活顺序。
    • 策略所适用的应用程序。
    • 将要应用的控制。
    • 策略要求满足的条件。

应变策略的此命名标准如下：

EMnnn - ENABLE IN EMERGENCY: [Disruption][i/n] - [Apps] - [Controls] [Conditions]

以下示例：示例 A - 用于恢复对任务关键协作应用的访问权限的应急条件访问策略是一种典型的公司应急策略。 在此方案中，组织通常需要多因素认证（MFA）来访问所有的 Exchange Online 和 SharePoint Online。在这种情况下，如果客户的 MFA 提供程序发生故障，无论是 Microsoft Entra 多因素认证、本地 MFA 提供程序还是第三方 MFA，都会造成中断。 此策略仅当特定目标用户从受信任的企业网络访问应用时，才允许特定目标用户从受信任的Windows设备访问这些应用，从而缓解此中断。 它还将紧急帐户和核心管理员排除在这些限制之外。 然后，目标用户将获取对 Exchange Online 和 SharePoint Online 的访问权限，而其他用户由于服务中断仍无法访问应用。 此示例需要一个名为 CorpNetwork 的网络位置和一个包含目标用户的安全组 ContingencyAccess、一个包含核心管理员的名为 CoreAdmins 的组，以及一个包含紧急访问帐户的名为 EmergencyAccess 的组。 该应急策略需要四个策略来提供所需的访问权限。

示例 A - 用于恢复对任务关键协作应用的访问权限的应急条件访问策略：

  • 策略 1：要求加入域的设备用于 Exchange 和 SharePoint
    • 名称：EM001 - 紧急启用：MFA 中断[1/4] - Exchange SharePoint - 需要Microsoft Entra混合联接
    • 用户和组：包括 ContingencyAccess。 排除 CoreAdmins 和 EmergencyAccess
    • 云应用：Exchange Online 和 SharePoint Online
    • 条件：任意
    • 授予控制权：要求已加入域
    • 状态：仅限报告
  • 策略 2：阻止除Windows以外的平台
    • 名称：EM002 - 紧急启用：MFA 中断[2/4] - Exchange SharePoint - 阻止访问，除了Windows
    • 用户和组：包括所有用户。 排除 CoreAdmins 和 EmergencyAccess
    • 云应用：Exchange Online和SharePoint Online
    • 条件：设备平台包括所有平台，排除Windows
    • 授予控制权：阻止
    • 状态：仅限报告
  • 策略 3：阻止除 CorpNetwork 以外的网络
    • 名称：EM003 - 紧急启用：MFA 中断[3/4] - Exchange SharePoint - 阻止访问，公司网络除外
    • 用户和组：包括所有用户。 排除 CoreAdmins 和 EmergencyAccess
    • 云应用：Exchange Online 和 SharePoint Online
    • 条件：位置包括任意位置，不包括 CorpNetwork。
    • 授予控制权：阻止
    • 状态：仅限报告
  • 策略 4：显式阻止 EAS
    • 名称：EM004 - 紧急启用：MFA 中断 [4/4] - Exchange - 阻止所有用户的 EAS 访问
    • 用户和组：包括所有用户
    • 云应用：包括Exchange Online
    • 条件：客户端应用：Exchange Active Sync
    • 授予控制权：阻止
    • 状态：仅限报告

激活顺序：

  1. 从现有 MFA 策略中排除 ContingencyAccess、CoreAdmins 和 EmergencyAccess。 验证 ContingencyAccess 中的用户是否可以访问 SharePoint Online 和 Exchange Online。
  2. 启用策略 1：验证不在排除组中的用户在已加入域的设备上是否能够访问 Exchange Online 和 SharePoint Online。 验证排除组中的用户是否可以从任何设备访问 SharePoint Online 和 Exchange。
  3. 启用策略 2：验证不在排除组中的用户无法从其移动设备访问 SharePoint 在线和 Exchange Online。 验证排除组中的用户是否可以从任何设备（Windows/iOS/Android）访问SharePoint和 Exchange。
  4. 启用策略 3：验证不在排除组中的用户不能在非企业网络环境下访问 SharePoint 和 Exchange，即使使用已加入域的计算机也是如此。 验证排除组中的用户是否可以从任何网络访问SharePoint和 Exchange。
  5. 启用策略 4：验证所有用户无法从移动设备上的本机邮件应用程序获取Exchange Online。
  6. 禁用 SharePoint Online 和 Exchange Online的现有 MFA 策略。

在下一个示例“示例 B - 允许移动设备访问 Salesforce 的应急条件访问策略”中，将恢复业务应用的访问权限。 在此方案中，客户通常要求其销售员工从移动设备访问 Salesforce（配置为使用 Microsoft Entra ID 进行单一登录），以便仅允许来自合规设备。 此示例中的中断是指评估设备符合性时出现问题，在销售团队需要访问 Salesforce 以完成交易的敏感时间发生中断。 这些应急策略将授权关键用户从移动设备访问 Salesforce，以便他们可以继续完成交易而不会中断业务。 在此示例中，SalesforceContingency 包含需要保留访问权限的所有销售员工，SalesAdmins 包含必要的 Salesforce 管理员。

示例 B - 应急条件访问策略：

  • 策略 1：阻止不属于 SalesContingency 团队的所有人员
    • 名称：EM001 - 紧急启用：设备合规性中断[1/2] - Salesforce - 阻止除 *SalesforceContingency* 以外的所有用户
    • 用户和组：包括所有用户。 排除 SalesAdmins 和 SalesforceContingency
    • 云应用：Salesforce。
    • 条件：无
    • 授予控制权：阻止
    • 状态：仅限报告
  • 策略 2：阻止销售团队从移动设备以外的任何平台进行访问（以缩小受攻击面）
    • 名称：EM002 - 在紧急情况下启用 - 设备合规性中断[2/2] - Salesforce - 阻止除 iOS 和 Android 以外的所有平台
    • 用户和组：包括 SalesforceContingency。 排除销售管理员
    • 云应用：Salesforce
    • 条件：设备平台包括所有平台，不包括 iOS 和 Android
    • 授予控制权：阻止
    • 状态：仅限报告

激活顺序：

  1. 从 Salesforce 的现有设备符合性策略中排除 SalesAdmins 和 SalesforceContingency。 确保 SalesforceContingency 组中的用户能够访问 Salesforce。
  2. 启用策略 1：确保 SalesContingency 外部的用户无法访问 Salesforce。 确保 SalesAdmins 和 SalesforceContingency 中的用户能够访问 Salesforce。
  3. 启用策略 2：验证 SalesContingency 组中的用户无法从其Windows/Mac 笔记本电脑访问 Salesforce，但仍可从其移动设备访问。 确保 SalesAdmin 仍可以从任意设备访问 Salesforce。
  4. 禁用 Salesforce 的现有设备符合性策略。

用户被锁定无法访问本地资源的应急措施（NPS 扩展）

如果要使用Microsoft Entra多重身份验证 NPS 扩展保护 VPN 访问，请考虑将 VPN 解决方案联合为 SAML 应用并确定应用类别，如下所示。

如果您已经部署了 Microsoft Entra 多重身份验证 NPS 扩展来保护本地资源（例如 VPN 和 Remote Desktop 网关），那么您应该提前考虑是否已做好在紧急情况下禁用 MFA 的准备。

在这种情况下，可以禁用 NPS 扩展，这样，NPS 服务器将仅验证主要身份验证，而不会对用户强制执行 MFA。

禁用 NPS 扩展：

  • 将 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters 注册表项作为备份导出。
  • 删除“AuthorizationDLLs”和“ExtensionDLLs”的注册表值，而不是参数键。
  • 重启网络策略服务 (IAS) 以使更改生效
  • 确定 VPN 的主要身份验证是否成功。

一旦服务恢复并已准备好再次对用户强制执行 MFA，便可启用 NPS 扩展：

  • 从备份 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters 导入注册表项
  • 重启网络策略服务 (IAS) 以使更改生效
  • 确定 VPN 的主要身份验证和辅助身份验证是否成功。
  • 查看 NPS 服务器和 VPN 日志，确定在紧急时段内登录的用户。

即使已联合，也部署密码哈希同步

如果满足以下条件，也可能发生用户锁定：

  • 你的组织使用联合身份验证的混合标识解决方案。
  • 本地标识系统（如 Active Directory、AD FS 或依赖组件）不可用。

为了更具弹性，组织应启用密码哈希同步，因为它使你能够在本地标识系统关闭时 切换到使用密码哈希同步 。

Microsoft 的建议

使用 Microsoft Entra Connect 向导启用密码哈希同步，无论组织是否使用联合身份验证。

重要

无需将用户从联合身份验证转换为托管身份验证，也能使用密码哈希同步。

中断期间

如果选择实施缓解计划，你将能够自动解决单一访问控制中断问题。 但是，如果选择创建应急计划，则可以在访问控制中断期间激活应急策略：

  1. 启用应急策略，授权目标用户从特定网络访问特定应用。
  2. 禁用基于控制的常规策略。

Microsoft 的建议

根据中断期间所使用的缓解计划或应急计划，组织可以只通过密码就授予访问权限。 没有保护措施是一个相当大的安全风险，必须进行仔细权衡。 组织必须：

  1. 作为变更控制策略的一部分，记录每项变更和之前的状态，以便在访问控制完全正常运行后立即回滚你实施的所有应急计划。
  2. 假设恶意参与者在你禁用 MFA 时试图通过密码喷射或网络钓鱼攻击来获取密码。 此外，不良参与者可能已经拥有的密码，此前虽然无法访问任何资源，但可以在此时段尝试使用这些密码进行访问。 对于高级管理人员等关键用户，可以在为其禁用 MFA 之前重置密码，从而在一定程度上缓解此风险。
  3. 存档所有登录活动，以确定在 MFA 被禁用期间，哪些人访问了哪些内容。
  4. 对此时段内报告的所有风险检测进行审查。

中断后

还原导致中断的服务后，请撤消作为已激活的应变计划的一部分所做的更改。

  1. 启用常规策略
  2. 禁用应急策略，使其恢复“仅限报告”模式。
  3. 回滚您在中断期间所做并记录的任何其他更改。
  4. 如果使用了紧急访问帐户，请记住重新生成凭据并以物理方式保护新凭据的详细信息，以作为紧急访问帐户过程的一部分。
  5. 继续在中断后对报告的所有风险检测进行分类以便查找可疑活动。
  6. 撤销针对一组用户颁发的所有刷新令牌。 撤销所有刷新令牌对于在中断期间使用的特权帐户非常重要，这样做将迫使它们重新进行身份验证并满足已还原策略的控制要求。

紧急选项

在出现紧急情况时，如果组织以前未实施任何缓解或应急计划，但已经使用条件访问策略来强制执行 MFA，则按照用户锁定应急计划部分中的建议操作。 如果你的组织使用的是每用户 MFA 旧策略，则可以考虑以下替代方法：

  • 如果有公司网络出站 IP 地址，则可以将它们添加为受信任的 IP，以便仅对公司网络启用身份验证。
  • 如果没有出站 IP 地址清单，或需要在公司网络内外均启用访问，则可通过指定 0.0.0.0/1 和 128.0.0.0/1 将整个 IPv4 地址空间添加为可信 IP。

重要

如果扩大受信任 IP 地址的范围以解除访问阻止，则不会生成与 IP 地址相关的风险检测（例如，不可能的行程或不熟悉的位置）。

注释

仅当拥有 Microsoft Entra ID P1 或 P2 许可证 时，才可以为 Microsoft Entra 多重身份验证配置 受信任的 IP。

了解详细信息

  • Last updated on