基于角色的访问控制 (RBAC) 提供了对用户和 IT 资源进行分类的框架。 此框架可以明确这二者的关系以及就该分类而言适当的访问权限。 例如，通过向用户分配指定用户职务和项目分配的属性，可以向用户授予访问工作所需工具和参与特定项目所需数据的权限。 用户处理不同的作业和不同的项目分配时，更改指定用户职务和项目的属性将自动阻止对仅用户前一职位所需资源的访问。
在 Microsoft Entra ID 中，可以通过多种方式使用角色模型来通过身份治理大规模管理访问。
- 可以使用访问包表示组织中的组织角色，例如“销售代表”。 表示该组织角色的访问包将包括销售代表通常可能需要的跨多个资源的所有访问权限。
- 应用程序可定义其自己的角色。 例如，如果你有一个销售应用程序，并且该应用程序的清单中包含应用角色“销售人员”，则可将应用清单中的该角色包含在访问包中。 应用程序还可以在标识可以同时具有多个特定于应用程序的角色的情况下使用安全组。
- 可以使用角色来委派管理访问权限。 如果你有一个包含所有销售所需访问包的目录，可以通过给某个人分配一个特定于该目录的角色，使他负责管理该目录。
本文讨论如何使用权利管理访问包为组织角色建模，以便将角色定义迁移到 Microsoft Entra ID 以强制实施访问。
迁移组织角色模型
下表说明了你在其他产品中可能熟悉的组织角色定义中的概念如何与权利管理中的功能相对应。
| 组织角色建模中的概念 | 权利管理中的表示形式 |
|---|---|
| 委派的角色管理 | 委托给目录创建者 |
| 跨一个或多个应用程序的权限集合 | 创建包含资源角色的访问包 |
| 限制角色提供的访问权限的持续时间 | 将访问包的策略生命周期设置配置为具有到期日期 |
| 向角色进行单独分配 | 创建对访问包的直接分配 |
| 根据属性（例如部门等）向用户分配角色 | 建立对访问包的自动分配 |
| 用户可以请求角色并获得批准 | 针对可以请求访问包的用户配置策略设置 |
| 角色成员的访问权限再认证 | 在访问包策略中设置定期访问评审设置 |
| 角色之间的职责分离 | 将两个或更多访问包定义为不兼容 |
例如，组织可能有类似于下表的现有组织角色模型。
| 角色名称 | 角色提供的权限 | 自动分配角色 | 基于请求进行角色分配 | 职责分离检查 |
|---|---|---|---|---|
| 售货员 | 销售团队成员 | 是的 | 否 | 没有 |
| 销售解决方案经理 | Sales 应用程序中“销售人员”和“解决方案经理”应用角色的权限 | 没有 | 销售人员可以提出请求，需要经理批准并进行季度评审。 | 请求者不能是销售客户经理 |
| 销售账户经理 | Sales 应用程序中“销售人员”和“客户经理”应用角色的权限 | 没有 | 销售人员可以提出请求，需要经理批准并进行季度评审。 | 请求者不能是销售解决方案经理 |
| 销售支持 | 与销售人员的权限相同 | 没有 | 任何非销售人员均可以提交请求，但需要经理批准并且每季度进行审核。 | 请求者不能是销售人员 |
这可以在 Microsoft Entra ID Governance 中表示为包含四个访问包的访问包目录。
| 访问套件 | 资源角色 | 策略 | 不兼容的访问包 |
|---|---|---|---|
| 售货员 | 销售团队成员 | 自动分配 | |
| 销售解决方案经理 | Sales 应用程序中的“解决方案经理”应用角色 | 基于请求 | 销售账户经理 |
| 销售账户经理 | Sales 应用程序中的“帐户经理”应用角色 | 基于请求 | 销售解决方案经理 |
| 销售支持 | 销售团队成员 | 基于请求 | 售货员 |
下一部分概述了迁移过程，包括创建 Microsoft Entra ID 和 Microsoft Entra ID Governance 项目来实现组织角色模型的等效访问。
将组织角色中引用其权限的应用连接到 Microsoft Entra ID
如果使用组织角色分配权限来控制对非 Microsoft SaaS 应用、本地应用或你自己的云应用的访问，则需要将应用程序连接到 Microsoft Entra ID。
为了使表示组织角色的访问包能够将应用程序的角色引用为要在角色中包含的权限，对于具有多个角色并支持新式标准（如 SCIM）的应用程序，应该将应用程序与 Microsoft Entra ID 集成，并确保应用程序的角色列在应用程序清单中。
如果应用程序只有一个角色，则仍应将该应用程序与 Microsoft Entra ID 集成。 对于不支持 SCIM 的应用程序，Microsoft Entra ID 可以将用户写入应用程序的现有目录或 SQL 数据库，或将 AD 用户添加到 AD 组中。
填充应用使用的以及用于组织角色中的用户范围规则的 Microsoft Entra 架构
如果角色定义包含“具有这些属性值的所有用户自动分配到角色”或“允许具有这些属性值的用户进行请求”形式的语句，则需要确保这些属性存在于 Microsoft Entra ID 中。
可以 扩展 Microsoft Entra 架构 ，然后通过 Microsoft Entra Connect 或 HR 系统从本地 AD 填充这些属性。
创建用于委派的目录
如果委托正在进行的角色维护，则可以通过为要委托到的组织的每个部分创建目录来委托访问包的管理。
如果要创建多个目录，可以使用 PowerShell 脚本创建每个目录。
如果不打算委托访问包的管理，则可以将访问包保留在单个目录中。
将资源添加到目录
现在您已经确定了目录，然后将表示组织角色的访问包中包含的应用程序、组或站点添加到目录中。
如果有多个资源，可以使用 PowerShell 脚本将每个资源添加到目录。 有关详细信息，请参阅 使用 PowerShell 在权利管理中为应用程序中单角色创建访问包。
创建与组织角色定义对应的访问包
每个组织角色定义都可以用该目录中的访问包来表示。
可以使用 PowerShell 脚本在目录中创建访问包。
创建访问包后，将目录中资源的一个或多个角色链接到访问包。 这表示组织角色的权限。
此外，你将 创建用于直接分配的策略，作为该访问包的一部分，该访问包可用于跟踪已具有单个组织角色分配的身份。
为现有的个别组织角色分配创建访问包分配
如果某些标识已有组织角色成员身份，则它们不会通过自动分配接收，则应为这些标识 创建相应的访问包的直接分配 。
如果有许多标识需要分配，可以使用 PowerShell 脚本将 每个用户分配到访问包。 这会将用户链接到直接分配策略。
向这些访问包添加策略以进行自动分配
如果组织角色定义包含基于标识属性的规则，以便根据这些属性自动分配和删除访问权限，则可以使用 自动分配策略来表示此规则。 一个访问包最多可以有一个自动分配策略。
如果有多个角色定义，并且每个角色定义都有一个角色定义，则可以使用 PowerShell 脚本在每个访问包中创建每个自动分配策略。
将访问包设置为不兼容以分离职责
如果由于职责分离的约束，导致一个标识在已有另一个组织中的角色时无法承担新的角色，那么可以通过将这些访问包组合标记为不兼容，以防止该标识在权限管理中请求访问。
对于要标记为与另一个访问包不兼容的每个访问包，可以使用 PowerShell 脚本将访问包配置为不兼容。
添加策略以便允许身份请求访问包
如果允许尚未具有组织角色的标识请求并获准担任某个角色，则还可以配置权利管理以允许标识请求访问包。 可以将 其他策略添加到访问包，并在每个策略中指定可以请求哪些标识以及谁必须批准。
在访问包分配策略中配置访问评审
如果组织角色需要定期评审其成员身份，则可以在基于请求的直接分配策略中配置定期访问评审。