通过

了解 Azure 角色分配

  • 项目

通过角色分配，可以授予主体（例如用户、组、托管标识或服务主体）对特定 Azure 资源的访问权限。 本文介绍角色分配的详细信息。

角色分配

对 Azure 资源的访问权限是通过创建角色分配来授予的，并且这些访问权限是通过删除角色分配来撤销的。

角色分配有多个组成部分，包括：

  • 分配有角色的“主体”或“人员”。
  • 分配给他们的“角色”。
  • 分配角色的“范围”。
  • 角色分配的“名称”，以及帮助你解释分配角色的原因的“说明”。

例如，可以使用 Azure RBAC 分配角色，例如：

  • 用户 Sally 对资源组“ContosoStorage”中的存储帐户“contoso123”拥有所有者访问权限。
  • Microsoft Entra ID 的“云管理员”组中的每个人都对资源组“ContosoStorage”中的所有资源拥有读取者访问权限。
  • 允许与应用程序关联的托管标识在 Contoso 的订阅内重新启动虚拟机。

以下示例展示了在 Azure PowerShell 中显示的角色分配属性：

{
  "RoleAssignmentName": "00000000-0000-0000-0000-000000000000",
  "RoleAssignmentId": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleAssignments/00000000-0000-0000-0000-000000000000",
  "Scope": "/subscriptions/11111111-1111-1111-1111-111111111111",
  "DisplayName": "User Name",
  "SignInName": "user@contoso.com",
  "RoleDefinitionName": "Contributor",
  "RoleDefinitionId": "b24988ac-6180-42a0-ab88-20f7382dd24c",
  "ObjectId": "22222222-2222-2222-2222-222222222222",
  "ObjectType": "User",
  "CanDelegate": false,
  "Description": null,
  "ConditionVersion": null,
  "Condition": null
}

以下示例展示了在 Azure CLI 或 REST API 中显示的角色分配属性：

{
  "canDelegate": null,
  "condition": null,
  "conditionVersion": null,
  "description": null,
  "id": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleAssignments/00000000-0000-0000-0000-000000000000",
  "name": "00000000-0000-0000-0000-000000000000",
  "principalId": "22222222-2222-2222-2222-222222222222",
  "principalName": "user@contoso.com",
  "principalType": "User",
  "roleDefinitionId": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c",
  "roleDefinitionName": "Contributor",
  "scope": "/subscriptions/11111111-1111-1111-1111-111111111111",
  "type": "Microsoft.Authorization/roleAssignments"
}

下表说明了角色分配属性的含义。

属性 说明
RoleAssignmentName
name		 角色分配的名称，它是全局唯一标识符 (GUID)。
RoleAssignmentId
id		 角色分配的唯一 ID，其中包括名称。
Scope
scope		 角色分配的范围限定到的 Azure 资源标识符。
RoleDefinitionId
roleDefinitionId		 角色的唯一 ID。
RoleDefinitionName
roleDefinitionName		 角色的名称。
ObjectId
principalId		 分配到角色的主体的 Microsoft Entra 对象标识符。
ObjectType
principalType		 主体表示的 Microsoft Entra 对象的类型。 有效值包括 User、Group 和 ServicePrincipal。
DisplayName 对于用户的角色分配，则是用户的显示名称。
SignInName
principalName		 用户的唯一主体名称 (UPN)，或者与服务主体关联的应用程序的名称。
Description
description		 角色分配的说明。
Condition
condition		 使用角色定义和属性中的一个或多个操作生成的条件语句。
ConditionVersion
conditionVersion		 条件版本号。 默认为 2.0，这是唯一受支持的版本。
CanDelegate
canDelegate		 未实现。

作用域

当创建角色分配时，需要指定它的应用范围。 范围代表主体可以访问的资源或资源集。 可以将角色分配的范围限定为单个资源、资源组、订阅或管理组。

提示

使用满足要求所需的最小范围。

例如，如果需要向单个存储帐户授予托管标识访问权限，好的安全的做法是在存储帐户范围内创建角色分配，而不是在资源组或订阅范围内创建角色分配。

有关范围的详细信息，请参阅了解范围。

要分配的角色

角色分配与角色定义相关联。 角色定义指定了主体在角色分配范围内应该拥有的权限。

可以分配内置角色定义或自定义角色定义。 创建角色分配时，一些工具会要求你使用角色定义 ID，而其他工具允许你提供角色的名称。

有关角色定义的详细信息，请参阅了解角色定义。

主体

主体包括用户、安全组、托管标识、工作负载标识和服务主体。 主体是在 Microsoft Entra 租户中创建和管理的。 你可以向任一主体分配角色。 使用 Microsoft Entra ID“对象 ID”识别要向其分配角色的主体。

使用 Azure PowerShell、Azure CLI、Bicep 或其他基础结构即代码 (IaC) 技术创建角色分配时，需指定“主体类型”。 主体类型包括“User”、“Group”和“ServicePrincipal”。 请务必指定正确的主体类型。 否则，可能会遇到间歇性部署错误，尤其是在使用服务主体和托管标识时。

名称

角色分配的资源名称必须是全局唯一标识符 (GUID)。

角色分配资源名称在 Microsoft Entra 租户中必须是唯一的，即使角色分配的范围较窄，也是如此。

提示

当使用 Azure 门户、Azure PowerShell 或 Azure CLI 创建角色分配时，创建过程会自动为角色分配指定唯一的名称。

如果通过使用 Bicep 或其他基础结构即代码 (IaC) 技术来创建角色分配，则需要对角色分配的命名方式进行仔细的规划。 有关详细信息，请参阅使用 Bicep 创建 Azure RBAC 资源。

资源删除行为

从 Microsoft Entra ID 中删除用户、组、服务主体或托管标识时，最好删除所有角色分配。 不会自动删除它们。 引用已删除主体 ID 的任何角色分配都会变得无效。

如果尝试对另一个角色分配重复使用角色分配的名称，则部署会失败。 当使用 Bicep 或 Azure 资源管理器模板（ARM 模板）来部署角色分配时，此问题更有可能发生，因为当使用这些工具时，你必须显式设置角色分配名称。 若要解决此问题，应在重新创建旧角色分配之前删除旧角色分配，或者确保在部署新角色分配时使用唯一名称。

说明

可以向角色分配添加文本说明。 虽然说明是可选的，但是最好将它们添加到角色分配中。 提供简短的理由解释主体为何需要分配的角色。 当相关人员审核角色分配时，这些说明可以帮助其了解为何创建这些角色以及这些角色是否仍然适用。

条件

一些角色支持“角色分配条件”，这些条件基于特定操作的上下文中的属性。 角色分配条件是一项额外检查，你可选择将其添加到角色分配中，来提供更精细的访问控制。

例如，你可以添加一个条件，要求某一对象具有特定的标记，以便用户读取该对象。

我们通常使用可视化对象条件编辑器来生成条件，不过下面的示例展示的是代码中的条件：

((!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'} AND NOT SubOperationMatches{'Blob.List'})) OR (@resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags:Project<$key_case_sensitive$>] StringEqualsIgnoreCase 'Cascade'))

上述条件允许用户读取 Blob 索引标记键为“Project”且值为“Cascade”的 Blob。

有关条件的详细信息，请参阅什么是 Azure 基于属性的访问控制 (Azure ABAC)？

与 Privileged Identity Management 集成（预览版）

重要

Azure 角色分配与 Privileged Identity Management 的集成目前为预览版。 有关 beta 版本、预览版或尚未正式发布的版本的 Azure 功能所适用的法律条款，请参阅 Azure 预览版的补充使用条款。

如果你有 Microsoft Entra ID P2 或 Microsoft Entra ID Governance 许可证，Microsoft Entra Privileged Identity Management (PIM) 会集成到角色分配步骤中。 例如，可以在有限的时间段内向用户分配角色。 还可以设置用户的角色分配资格，并让他们必须在通过请求批准等方式激活后才能使用该角色。 符合条件的角色分配在有限时间段内提供对角色的实时访问权限。 无法为应用程序、服务主体或托管标识创建符合条件的角色分配，因为它们无法执行激活步骤。 可以在管理组、订阅和资源组范围内创建符合条件的角色分配，但不能在资源范围内创建。 此功能正在分阶段部署，因此它可能在租户中尚不可用，或者你的界面可能看起来有所不同。

可用的分配类型选项可能会因 PIM 策略而异。 例如，PIM 策略定义是否可以创建永久分配、限时分配的最大持续时间、角色激活要求（审批、多重身份验证或条件访问身份验证上下文）和其他设置。 有关详细信息，请参阅在 Privileged Identity Management 中配置 Azure 资源角色设置。

如果不想使用 PIM 功能，请选择“活动”分配类型和“永久”分配持续时间选项。 这些设置创建一个角色分配，其中主体在角色中始终具有权限。

显示“分配类型”选项的“添加角色分配”的屏幕截图。

为了更好地了解 PIM，应查看以下术语。

术语或概念 角色分配类别 说明
符合条件 类型 要求用户在使用角色之前执行一项或多项操作的角色分配。 如果用户符合某个角色的条件，则意味着他们在需要执行特权任务时可以激活该角色。 用户无论具有永久角色分配还是合格角色分配，获得的访问权限并无差异。 唯一的差异在于，有些用户并不是一直需要该访问权限。
活动 类型 不要求用户在使用角色之前执行任何操作的角色分配。 分配为“活动”的用户拥有分配给该角色的特权。
激活 合格用户在使用角色之前执行一项或多项操作的过程。 操作可能包括执行多重身份验证 (MFA) 检查、提供业务理由或请求获得指定审批者的批准。
永久符合条件 Duration 使用户始终有资格激活该角色的角色分配。
永久活动 Duration 使用户无需执行任何操作，始终可以使用该角色的角色分配。
限时符合条件 持续时间 通过这种角色分配方式，用户只有在开始和结束日期范围内才有资格激活角色。
限时处于活动状态 持续时间 通过这种角色分配方式，用户只能在开始和结束日期范围内使用角色。
实时 (JIT) 访问 一种访问模式。在此模式下，用户会收到执行特权任务的临时权限，防止恶意用户或未授权用户在权限过期后获得访问权限。 只有在用户需要的情况下，才会授予访问权限。
最低访问权限原则 一种建议的安全做法，仅为每个用户提供所需的最低权限，以便完成有权执行的任务。 此做法会尽量减少全局管理员的数目，并使用适合特定方案的特定管理员角色。

有关详细信息，请参阅什么是 Microsoft Entra Privileged Identity Management？。

后续步骤