分配 Azure 角色的步骤
Azure 基于角色的访问控制 (Azure RBAC) 是用于管理 Azure 资源访问权限的授权系统。 若要授予访问权限，请将角色分配给特定范围内的用户、组、服务主体或托管标识。 本文介绍使用 Azure 门户、Azure PowerShell、Azure CLI 或 REST API 分配 Azure 角色的概略性步骤。
步骤 1：确定哪一用户需要访问权限
首先需要确定哪一用户需要访问权限。 可将角色分配到用户、组、服务主体或托管标识。 这也称为“安全主体”。
- 用户 - 在 Microsoft Entra ID 中具有配置文件的个人。 也可以将角色分配到其他租户中的用户。 有关其他组织中的用户的信息，请参阅 Microsoft Entra B2B。
- 组 - 在 Microsoft Entra ID 中创建的一组用户。 将某个角色分配到某个组时，该组中的所有用户都拥有该角色。
- 服务主体 - 应用程序或服务用来访问特定 Azure 资源的安全标识。 可将服务主体视为应用程序的用户标识（用户名和密码或证书）。
- 托管标识 - Microsoft Entra ID 中由 Azure 自动托管的标识。 在开发云应用程序时，通常使用托管标识来管理用于向 Azure 服务进行身份验证的凭据。
步骤 3：选择合适的角色
权限将组合到角色定义中。 它通常直接称为“角色”。 可以从多个内置角色的列表中选择。 如果内置角色不能满足组织的特定需求，则可自行创建自定义角色。
角色会组织为工作职能角色和特权管理员角色。
工作职能角色
工作职能角色允许对特定的 Azure 资源进行管理。 例如，虚拟机参与者角色允许用户创建和管理虚拟机。 若要选择适当的工作职能角色，请执行以下步骤：
请从综合性文章 Azure 内置角色开始。 本文顶部的表是对本文后面的详细信息的索引。
在该文中，导航到要向其授予权限的资源的服务类别（例如，计算、存储和数据库）。 查找所需内容的最简单方法通常是在页面上搜索相关的关键字，如“blob”、“虚拟机”等。
查看服务类别列出的角色，并确定所需的特定操作。 同样，始终以最严格的角色开始。
例如，如果安全主体需要读取 Azure 存储帐户中的 blob，但不需要写入访问权限，请选择存储 Blob 数据读取者而不是存储 Blob 数据参与者（绝对不是管理员级别的存储 Blob 数据所有者角色）。 稍后，你可以根据需要随时更新角色分配。
如果找不到合适的角色，可以创建自定义角色。
特权管理员角色
特权管理员角色是授予特权管理员访问权限（例如管理 Azure 资源或将角色分配给其他用户的权限）的角色。 以下角色被视为特权角色，适用于所有资源类型。
| Azure 角色 | 权限 |
|---|---|
| 所有者 |
|
| 参与者 |
|
| 预留管理员 |
|
| 基于角色的访问控制管理员 |
|
| 用户访问管理员 |
|
有关使用特权管理员角色分配时的最佳做法，请参阅 Azure RBAC 最佳做法。 有关详细信息，请参阅特权管理员角色定义。
步骤 3：识别所需的范围
范围是访问权限适用于的资源集。 在 Azure 中，可以在以下四个级别指定范围：管理组、订阅、资源组和资源。 范围采用父子关系结构。 层次结构的每个级别都会使范围更具针对性。 可以在其中任何一个范围级别分配角色。 所选级别决定了角色的应用广泛程度。 较低级别继承较高级别的角色权限。
在父范围分配角色时，这些权限会继承到子范围。 例如： 。
- 如果将读取者角色分配给管理组范围内的用户，则该用户可以读取管理组的所有订阅中的所有内容。
- 如果在订阅范围向某个组分配了账单读取者角色，则该组的成员可以读取订阅中每个资源组和资源的账单数据。
- 如果在资源组范围向某个应用程序分配了参与者角色，则该应用程序可以管理该资源组中所有类型的资源，但不能管理订阅中其他资源组的资源。
最佳做法是向安全主体授予执行作业所需的最少特权。 即使最初看起来更方便，也应避免在更广泛的范围内分配更广泛的角色。 通过限制角色和范围，可以对在安全主体受到入侵的情况下会面临风险的具体资源进行限制。 有关详细信息，请参阅了解范围。
步骤 4：检查先决条件
若要分配角色，必须使用已分配了角色且该角色具有角色分配写入权限的用户登录（例如你试图分配角色的作用域中基于角色的访问控制管理员）。 同样，若要删除角色分配，你必须具有角色分配删除权限。
Microsoft.Authorization/roleAssignments/writeMicrosoft.Authorization/roleAssignments/delete
如果用户帐户无权在订阅内分配角色，则将显示错误消息“你的帐户无权执行操作 'Microsoft.Authorization/roleAssignments/write'”。在这种情况下，请与你的订阅管理员联系，因为他们可以代表你分配权限。
如果使用服务主体来分配角色，可能会收到错误信息：“权限不足，无法完成操作”。此错误很可能是因为 Azure 尝试在 Microsoft Entra ID 中查找被分派人标识，但服务主体在默认情况下无法读取 Microsoft Entra ID。 在这种情况下，你需要授予服务主体读取目录中数据的权限。 或者，如果使用的是 Azure CLI，则可通过使用被分派人对象 ID 创建角色分配，以便跳过 Microsoft Entra 查找。 有关详细信息，请参阅 Azure RBAC 疑难解答。
步骤 5：分配角色
了解安全主体、角色和范围后，便可以分配角色了。 可使用 Azure 门户、Azure PowerShell、Azure CLI、Azure SDK 或 REST API 来分配角色。
每个订阅中最多可以有 4000 个角色分配。 此限制包括订阅、资源组和资源范围内的角色分配。 合格角色分配和计划的将来角色分配不计入此限制。 每个管理组中最多可以有 500 个角色分配。 有关详细信息，请参阅 Azure RBAC 限制疑难解答。
请查看以下文章，了解有关如何分配角色的详细步骤。
- 使用 Azure 门户分配 Azure 角色
- 使用 Azure PowerShell 分配 Azure 角色
- 使用 Azure CLI 分配 Azure 角色
- 使用 REST API 分配 Azure 角色