Microsoft Entra ID 中基于角色的访问控制概述

本文介绍如何了解 Microsoft Entra 基于角色的访问控制。 Microsoft Entra 角色允许你向管理员授予精细权限，并遵守最低特权原则。 Microsoft Entra 内置和自定义角色的运作原理类似于适用于 Azure 资源的基于角色的访问控制系统（Azure 角色）中的原理。 这两个基于角色的访问控制系统 之间的 区别是：

  • Microsoft Entra 角色使用 Microsoft 图形 API 控制对 Microsoft Entra 资源（如用户、组和应用程序）的访问
  • Azure 角色使用 Azure 资源管理控制对 Azure 资源（例如虚拟机或存储）的访问

这两个系统都包含同样使用的角色定义和角色分配。 但是，Microsoft Entra 角色权限不能用于 Azure 自定义角色，反之亦然。

了解 Microsoft Entra 基于角色的访问控制

Microsoft Entra ID 支持两种类型的角色定义：

内置角色是具有固定权限集的开箱即用角色。 无法修改这些角色定义。 Microsoft Entra ID 支持许多内置角色，并且支持的角色还在不断增加。 为了完善功能并满足复杂要求，Microsoft Entra ID 还支持自定义角色。 使用自定义Microsoft Entra 角色授予权限的过程分为两个步骤，涉及创建自定义角色定义，然后使用角色分配来分配它。 自定义角色定义是从预设列表中添加的权限集合。 这些权限与内置角色中使用的权限相同。

创建自定义角色定义（或使用内置角色）后，可以通过创建角色分配将其分配给用户。 角色分配向用户授予指定范围的角色定义中的权限。 通过这两个步骤，可以创建单个角色定义，并在不同的范围内多次分配它。 范围定义角色成员有权访问的 Microsoft Entra 资源集。 最常见的范围是组织范围内。 可以在组织范围内分配自定义角色，这意味着该角色成员对组织中的所有资源具有角色权限。 还可以在对象范围内分配自定义角色。 对象范围的一个示例是单个应用程序。 可以将同一角色分配给组织中所有应用程序中的一个用户，然后分配给只有 Contoso Expense Reports 应用的作用域的另一个用户。

Microsoft Entra ID 如何确定用户是否有权访问资源

以下是Microsoft Entra ID 用于确定是否有权访问管理资源的概要步骤。 使用此信息排查访问问题。

  1. 用户（或服务主体）获取指向 Microsoft Graph 终结点的令牌。
  2. 用户使用颁发的令牌通过 Microsoft Graph 对 Microsoft Entra ID 进行 API 调用。
  3. 根据情况，Microsoft Entra ID 执行以下操作之一：
    • 基于用户访问令牌中的 wids 声明评估用户的角色成员身份。
    • 检索为用户应用于（直接或通过组成员身份）执行操作的资源的所有角色分配。
  4. Microsoft Entra ID 确定 API 调用中的操作是否包含在用户对该资源的角色中。
  5. 如果用户在请求的范围内没有具有该动作的角色，则不会授予访问权限。 否则授予访问权限。

角色分配

角色分配是 Microsoft Entra 资源，它在特定的 作用域 内将 角色定义 附加到 安全主体，以授予对 Microsoft Entra 资源的访问权限。 通过创建角色分配来授予访问权限，通过删除角色分配来撤销访问权限。 其核心是角色分配由三个元素组成：

  • 安全主体 - 被授予权限的身份。 它可以是用户、组或服务主体。
  • 角色定义 - 权限集合。
  • 范围 - 一种限制这些权限适用的方法。

可使用 Microsoft Entra 管理中心、Microsoft Graph PowerShell 或 Microsoft Graph API 创建角色分配并列出角色分配。 Azure CLI 不支持 Microsoft Entra 角色分配。

下图显示了角色分配的示例。 示例中，Chris 被分配为 Contoso Widget Builder 应用注册范围内的应用注册管理员自定义角色。 此分配仅针对这一特定应用注册，授予 Chris 应用注册管理员角色的权限。

由三个部分构成的角色分配示意图。

安全主体

安全主体表示分配了对 Microsoft Entra 资源的访问权限的用户、组或服务主体。 用户是在 Microsoft Entra ID 中具有用户配置文件的个人。 组是已设置为可分配角色的组的新 Microsoft 365 或安全组。 服务主体标识是为应用程序、托管服务和自动化工具创建的标识，用于访问 Microsoft Entra 资源。

角色定义

角色定义，或称为角色，是一组权限的集合。 角色定义列出了可以对 Microsoft Entra 资源执行的操作，例如创建、读取、更新和删除。 Microsoft Entra ID 中有两种类型的角色：

  • Microsoft创建的无法更改的内置角色。
  • 由组织创建和管理的自定义角色。

Scope

范围是一种在角色分配过程中，限制对一组特定资源执行允许的操作的方法。 例如，如果要将自定义角色分配给开发人员，但只能管理特定的应用程序注册，则可以将特定应用程序注册作为角色分配中的作用域包含在其中。

分配角色时，请指定以下类型的范围之一：

如果将Microsoft Entra 资源指定为范围，它可以是下列资源之一：

  • Microsoft Entra 组
  • 企业应用程序
  • 应用程序注册

当在容器范围（如租户或管理单元）内分配角色时，它会授予对其中对象的权限，但不包括对容器本身的权限。 相反，当在资源范围上分配角色时，它会授予对资源本身的权限，但不会扩展到资源范围之外（尤其是不会扩展到 Microsoft Entra 组的成员）。

有关详细信息，请参阅分配 Microsoft Entra 角色。

角色分配选项

Microsoft Entra ID 提供了多个用于分配角色的选项：

  • 可以直接向用户分配角色，这是分配角色的默认方式。 可以根据访问要求将内置角色和自定义Microsoft Entra 角色分配给用户。 有关详细信息，请参阅分配 Microsoft Entra 角色。
  • 使用 Microsoft Entra ID P1，可以创建可分配角色的组，并将角色分配给这些组。 将角色分配给组而不是个人允许从角色中轻松添加或删除用户，并为组的所有成员创建一致的权限。 有关详细信息，请参阅分配 Microsoft Entra 角色。
  • 使用 Microsoft Entra ID P2，可以使用 Microsoft Entra Privileged Identity Management (Microsoft Entra PIM) 提供对角色的实时访问。 此功能允许你向需要角色的用户授予对角色的有限访问权限，而不是授予永久访问权限。 它还提供详细的报告和审核功能。 有关详细信息，请参阅在 Privileged Identity Management 中分配 Microsoft Entra 角色。

了解谁有权访问哪些内容

列出角色分配是回答更广泛的问题之一：“谁有权访问组织中的哪些内容？” Microsoft Entra ID提供了多种工具，在一起使用时，可让你了解整个租户的访问权限。

  • 角色分配。 使用 列出 Microsoft Entra 角色分配中的步骤，列出租户、应用程序或管理单元范围内持有 Microsoft Entra 角色的人员。 可以下载角色分配作为 CSV 进行脱机分析，或者使用 List unifiedRoleAssignments Microsoft 图形 API 以编程方式查询它们。
  • 应用角色分配和许可授予。 使用 向应用程序分配用户和组 以查看哪些用户和组可以访问给定的企业应用程序。 使用 授予应用程序的评审权限 来检查用户或管理员已同意的委派权限和应用程序权限。
  • 自定义安全属性。 使用 自定义安全属性 通过为租户定义的特定于业务的属性标记用户和服务主体。 然后，可以按属性筛选和查询目录，以生成可补充基于角色的查询的访问的业务属性视图。
  • 访问审核 使用 访问评审 定期验证用户是否仍需要其当前组成员身份和对企业应用程序的分配。 使用 Privileged Identity Management（PIM）访问权限评审 来审查已分配到 Microsoft Entra 或 Azure 资源角色的用户和服务主体。 审阅者批准或拒绝每个用户的持续访问。 访问评审需要 Microsoft Entra ID 治理 或 Microsoft Entra 套件；某些功能可通过 Microsoft Entra ID P2 运行。 有关详细信息，请参阅 许可证要求。 通过 PIM 查看服务主体还需要Microsoft Entra Workload ID Premium。
  • 权利管理。 使用 权利管理 查看哪些用户已通过访问包授予访问权限。 访问包组织到目录中，这些包是相关资源的容器，以及可用于委托和管理访问权限的访问包。 权利管理需要Microsoft Entra ID 治理或Microsoft Entra 套件;某些功能使用 Microsoft Entra ID P2 运行。 有关详细信息，请参阅 许可证要求。
  • 登录和审计日志。 使用 登录日志 查看谁在哪些情况下主动访问了资源。 使用 审核日志 跟踪一段时间内角色分配、组成员身份和其他目录对象的更改。 审核日志记录配置更改，而登录日志记录登录事件——二者结合可帮助你区分已授予的访问权限和实际使用的访问权限。 有关Microsoft Graph API 调用的更丰富跟踪，请参阅 Microsoft Graph 活动日志。

Tip

对于大型租户，将日志流式传输到 Log Analytics 工作区以便可以跨数千个用户和角色查询和分析访问模式。

控制工作负荷标识的访问

完整的大规模授权策略必须涵盖工作负荷标识（应用程序、服务主体和托管标识），而不仅仅是用户。 Microsoft Entra支持多种用于建立计算机标识的方法，每个方法都适合不同的方案：

  • 应用注册。 注册 应用程序对象 以创建使用客户端机密、证书或联合凭据进行身份验证的服务主体。 用于传统应用程序和平台集成。
  • Managed identities。 对于在Azure中运行的工作负荷，请使用系统分配的或用户分配的托管标识。 Azure 会为你管理凭据，因此无需在代码或配置中存储机密信息。
  • 工作负荷标识联合。 在Microsoft Entra与外部标识提供者之间配置信任，以便Azure外部的工作负荷（或作为应用注册进行身份验证的Azure中的工作负荷）无需存储机密即可访问Microsoft Entra受保护的资源。
  • 灵活的联合标识凭据（预览版）。 将应用注册的无机密模式扩展到需要与 GitHub、GitLab 或 Terraform Cloud 颁发的令牌进行基于通配符或基于声明的匹配的方案。

使用应用于用户的相同分层控件大规模治理这些标识：

  • 执行组和应用程序的访问审查，以确认分配给这些资源的用户仍然需要这些访问权限，并使用PIM 访问审查来审查被分配到 Microsoft Entra 角色和 Azure 资源角色的服务主体。 组和应用程序的审阅需要 Microsoft Entra ID 治理 或 Microsoft Entra 套件（某些功能可通过 Microsoft Entra ID P2 使用）；有关详细信息，请参阅 许可证要求。 对服务主体的评审还需要Microsoft Entra Workload ID Premium。
  • 为已注册应用程序的服务主体添加 自定义安全属性 标记，以便构建可筛选的清单，并根据业务属性驱动 Azure ABAC 决策。
  • 在多租户应用上启用 应用实例属性锁 ，以防止在另一租户中预配应用后对服务主体上的敏感属性进行未经授权的修改。

许可要求

在 Microsoft Entra ID 中使用内置角色是免费的。 使用自定义角色要求每个分配有自定义角色的用户都具有 Microsoft Entra ID P1 许可证。 若要根据需要查找合适的许可证，请参阅比较免费版和高级版中普遍可用的功能。

后续步骤

  • Last updated on