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