什么是 Azure 基于角色的访问控制 (Azure RBAC)？

对于任何使用云的组织而言，云资源的访问权限管理都是一项重要功能。 Azure 基于角色的访问控制 (Azure RBAC) 可帮助你管理谁有权访问 Azure 资源、他们可以对这些资源执行哪些操作以及他们有权访问哪些区域。

Azure RBAC 是在 Azure 资源管理器基础上构建的授权系统，针对 Azure 资源提供精细的访问权限管理。

Azure RBAC 有什么用途？

下面是 Azure RBAC 用途的一些示例：

• 让一个用户管理订阅中的虚拟机，另一个用户管理虚拟网络
• 让 DBA 组管理订阅中的 SQL 数据库
• 让某个用户管理资源组中的所有资源，例如虚拟机、网站和子网
• 允许某个应用程序访问资源组中的所有资源

Azure RBAC 的工作原理

使用 Azure RBAC 控制资源访问权限的方式是分配 Azure 角色。 这是一个需要理解的重要概念 - 它涉及到如何强制实施权限。 角色分配包含三个要素：安全主体、角色订阅和范围。

安全主体

安全主体是一个对象，表示请求访问 Azure 资源的用户、组、服务主体或托管标识。 可以将角色分配给其中任何一个安全主体。

角色定义

角色定义是权限的集合。 它通常直接称为“角色”。 角色定义列出可执行的操作，例如读取、写入和删除。 角色可以是高级别的（例如所有者），也可以是特定的（例如虚拟机读取者）。

Azure 包含多个可用的内置角色。 例如，虚拟机参与者角色允许用户创建和管理虚拟机。 如果内置角色不能满足组织的特定需求，你可以创建自己的 Azure 自定义角色。

Azure 具有数据操作，使你能够授予对对象内数据的访问权限。 例如，如果某个用户对某个存储帐户拥有读取数据的访问权限，则该用户可以读取该存储帐户中的 Blob 或消息。

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

范围

范围是访问权限适用于的资源集。 分配角色时，可以通过定义范围来进一步限制允许的操作。 若要将某人分配为网站参与者，但只针对一个资源组执行此分配，则可使用范围。

在 Azure 中，可在四个级别指定范围：管理组、订阅、资源组或资源。 范围采用父子关系结构。 可以在其中任何一个范围级别分配角色。

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

角色分配

角色分配是出于授予访问权限的目的，将角色定义附加到特定范围内的用户、组、服务主体或托管标识的过程。 通过创建角色分配来授予访问权限，通过删除角色分配来撤销访问权限。

下图显示了角色分配的示例。 在此示例中，为“营销”组分配了医药销售资源组的参与者角色。 这意味着，“营销”组中的用户可以在医药销售资源组中创建或管理任何 Azure 资源。 “营销”用户无权访问医药销售资源组外部的资源，除非他们属于另一个角色分配。

可使用 Azure 门户、Azure CLI、Azure PowerShell、Azure SDK 或 REST API 分配角色。

有关详细信息，请参阅分配 Azure 角色的步骤。

组

角色分配对组来说是可传递的，这意味着如果某用户是某个组的成员，而该组属于具有角色分配的另一个组，那么该用户将具有该角色分配中的权限。

多角色分配

如果有多个重叠的角色分配，将会发生什么情况？ Azure RBAC 是一个加法模型，因此有效权限是角色分配的总和。 请考虑以下示例，其中在订阅范围内向用户授予了“参与者”角色，并且授予了对资源组的“读者”角色。 “参与者”权限与“读者”权限的总和实际上是订阅的“参与者”角色。 因此，在这种情况下，“读者”角色分配没有任何影响。

Azure RBAC 如何确定用户是否有权访问资源

下面是 Azure RBAC 用于确定你是否可访问资源的概要步骤。 这些步骤适用于与 Azure RBAC 集成的 Azure 资源管理器或数据平面服务。 如果正在尝试对访问问题进行故障排除，这有助于了解问题。

1. 用户（或服务主体）获取 Azure 资源管理器的令牌。

   令牌包含用户的组成员身份（包括可传递的组成员身份）。

2. 用户使用附加的令牌对 Azure 资源管理器发出 REST API 调用。

3. Azure 资源管理器检索适用于对其执行操作的资源的所有角色分配和拒绝分配。

4. 如果拒绝分配适用，则阻止访问。 否则，评估将继续进行。

5. Azure 资源管理器缩小适用于此用户或其组的角色分配范围，并确定用户针对此资源拥有的角色。

6. Azure 资源管理器确定 API 调用中的操作是否包含在用户针对此资源拥有的角色中。 如果角色包含的 Actions 具有通配符 (*)，则通过从允许的 Actions 中减去 NotActions 来计算有效权限。 同样，对任何数据操作执行相同的减法运算。

   Actions - NotActions = Effective management permissions

   DataActions - NotDataActions = Effective data permissions

7. 如果用户在请求的范围内没有包含该操作的角色，则不允许访问。 否则，将评估任何条件。

8. 如果角色分配包含条件，则对这些条件进行评估。 否则将允许访问。

9. 如果满足条件，则允许访问。 否则将不允许访问。

下图是评估逻辑的摘要。

Azure RBAC 数据存储在哪里？

角色定义、角色分配和拒绝分配存储在全局范围内，以确保无论你在哪个区域创建资源，你都可以访问你的资源。

删除角色分配或任何其他 Azure RBAC 数据时，数据将被全局删除。 有权通过 Azure RBAC 数据访问资源的委托人将失去其访问权限。

为什么 Azure RBAC 数据是全局性的？

Azure RBAC 数据是全局性的，这样可确保客户无论从何处访问都可以及时访问资源。 Azure RBAC 由 Azure 资源管理器强制执行，它具有全局终结点并且请求将被路由到最近的区域以实现速度和复原能力。 因此，必须在所有区域强制执行 Azure RBAC，并将数据复制到所有区域。 有关详细信息，请参阅 Azure 资源管理器的复原能力。

请看下面的示例。 Arina 在中国北部创建了一个虚拟机。 Bob 是 Arina 团队的成员，在美国工作。 Bob 需要访问在中国北部创建的虚拟机。 为了授予 Bob 及时访问虚拟机的权限，Azure 需要全局复制授予 Bob 从 Bob 所在的任何位置访问虚拟机的角色分配。

许可要求

此功能免费使用，并且包括在你的 Azure 订阅中。

后续步骤

• 使用 Azure 门户分配 Azure 角色
• 了解不同角色