使用角色控制资源访问

Azure 资源的内置角色（使用 PowerShell）

Azure 提供了若干内置角色，以涵盖最常见的安全性方案。 为了了解角色的工作原理，让我们来研究一下适用于所有资源类型的三种角色：

• 所有者：具有对所有资源的完全访问权限，包括委派对其他人的访问权限的权限。
• 参与者：可以创建和管理所有类型的 Azure 资源，但不能向其他人授予访问权限。
• 读者：可以查看现有的 Azure 资源。

角色定义

每个角色都是在 JavaScript 对象表示法 (JSON) 文件中定义的一组属性。 此角色定义包括“名称”、“ID”和“说明”。 其中还包括角色的可用权限 (Actions)、拒绝权限 (NotActions) 和范围（例如，读取访问）。

对于所有者角色，即表示所有操作（用星号 (*) 表示）；没有拒绝的操作；以及所有范围（以正斜杠 (/) 表示）。

可使用 PowerShell Get-AzRoleDefinition Owner cmdlet 获取此信息。

Get-AzRoleDefinition Owner

此代码应生成以下输出：

Name             : Owner
Id               : 8e3af657-a8ff-443c-a75c-2fe8c4bcb635
IsCustom         : False
Description      : Lets you manage everything, including access to resources.
Actions          : {*}
NotActions       : {}
DataActions      : {}
NotDataActions   : {}
AssignableScopes : {/}

尝试对“参与者”和“读者”角色执行相同的操作，以查看允许和拒绝的操作。

内置角色

有关 Microsoft Entra ID 中 RBAC 和用户角色的深入检查，请参阅 在 Microsoft Entra ID 中检查 RBAC 和用户角色。

什么是角色定义？

角色定义是权限的集合。 角色定义列出了角色可以执行的作，例如 读取、写入和删除。 它还可以列出不能执行的操作或与基础数据相关的操作。

如前所述，角色定义具有以下结构：

在基于角色的访问控制 (RBAC) 或基础 API 中使用时，此结构表示为 JSON。 例如，下面是 JSON 格式的参与者角色定义。

{
  "Name": "Contributor",
  "Id": "b24988ac-6180-42a0-ab88-20f7382dd24c",
  "IsCustom": false,
  "Description": "Lets you manage everything except access to resources.",
  "Actions": [
    "*"
  ],
  "NotActions": [
    "Microsoft.Authorization/*/Delete",
    "Microsoft.Authorization/*/Write",
    "Microsoft.Authorization/elevateAccess/Action"
  ],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/"
  ]
}

Actions 和 NotActions

可以定制 Actions 和 NotActions 属性，以授予和拒绝所需的确切权限。 这些属性的格式始终为 {Company}.{ProviderName}/{resourceType}/{action}。

例如，下面是前面介绍的三个角色的操作：

Actions 下的通配符 (*) 操作表示分配给此角色的主体可以执行所有操作，换句话说，此角色可以管理所有内容，其中包括将来在将新资源类型添加到 Azure 时定义的操作。 使用“读者”角色，仅允许 read 操作。

NotActions 下的操作会从 Actions 中去除。 使用“参与者”角色，NotActions 可删除此角色管理资源访问权限以及分配资源访问权限的功能。

DataActions 和 NotDataActions

数据操作在 DataActions 和 NotDataActions 属性中指定。 可以指定独立于管理操作的数据操作。 这可防止包含通配符 (*) 的当前角色分配突然访问数据。 下面是一些可在 DataActions 和 NotDataActions 中指定的数据操作：

• 读取容器中的 blob 列表
• 在容器中写入存储 blob
• 删除队列中的消息

只能向 DataActions 和 NotDataActions 属性添加数据操作。 资源提供程序通过将 isDataAction 属性设置为 true 来识别哪些操作是数据操作。 没有数据操作的角色可以忽略角色定义中的这些属性。

这些操作的处理方式与其管理方式完全相同。 可指定要允许的操作（* 表示全部操作），然后提供要从 NotDataActions 集合中删除的特定操作的列表。 下面是一些示例，可以在 资源提供文档中找到操作和数据操作的完整列表：

可分配范围

定义 Actions 和 NotActions 属性不足以完全实现角色。 还需要适当地确定角色的范围。

角色的 AssignableScopes 属性指定角色可供分配的范围（订阅、资源组或资源）。 可以使自定义角色仅在需要它的订阅或资源组中可供分配，从而避免影响其他订阅或资源组的用户体验。

下面是一些示例：

创建角色

Microsoft Entra ID 附带有内置角色，可能涵盖了想要执行的 99% 的操作。 如果可能，请首选使用内置角色。 但是，如有必要，可以创建自定义角色。

可以通过多种机制创建新角色：

• Microsoft Entra 管理中心：可以在左侧菜单中“角色和管理员”下选择“角色和管理员”，然后选择“新的自定义角色”，以使用 Microsoft Entra 管理中心创建自定义角色。

• Azure 门户：可以通过选择 Microsoft Entra ID>角色和管理员>新建自定义角色，使用 Azure 门户创建自定义角色。

• Azure PowerShell：可以使用 New-AzRoleDefinition cmdlet 定义新角色。

• Azure Graph API：可以使用对图形 API 的 REST 调用以编程方式创建新角色。

本模块的“摘要”部分包含这些方法的文档链接。