介绍 Azure 基于角色的访问控制

已完成

当你有多个 IT 和工程团队时,如何控制他们对云环境中资源的访问权限? 根据最小特权原则,应仅授予完成任务所需级别的访问权限。 如果只需要对存储 Blob 的读取访问权限,则应仅被授予对该存储 Blob 的读取访问权限。 不应被授予对该 Blob 的写入访问权限,也不应被授予对其他存储 Blob 的读取访问权限。 这是一个需遵循的良好安全做法。

但是,管理整个团队的权限级别会变得繁琐。 利用 Azure,你可以通过 Azure 基于角色的访问控制 (Azure RBAC) 来控制访问权限,而不是为每个人定义详细的访问要求,然后在创建新资源或新人员加入团队时更新访问要求。

Azure 提供了描述云资源的常见访问规则的内置角色。 你还可以自定义角色。 每个角色都有一组与其关联的访问权限。 将个人或组分配给一个或多个角色时,他们会收到所有关联的访问权限。

因此,如果雇用新工程师并将其添加到面向工程师的 Azure RBAC 组,他们将自动获得与同一 Azure RBAC 组中其他工程师相同的访问权限。 同样,如果添加其他资源并将 Azure RBAC 指向这些资源,则该 Azure RBAC 组中的每个人都将拥有对新资源以及现有资源的这些权限。

如何将基于角色的访问控制应用到资源?

对某个范围应用基于角色的访问控制,该范围包括此访问权限应用到的一个资源或一组资源。

下图显示了角色和范围之间的关系。 可能会为管理组、订阅或资源组提供所有者角色,因此他们增加了控制权和权限。 不应进行任何更新的观察者可能会获得同一范围的读者角色,从而能够查看或观察管理组、订阅或资源组。

A diagram showing scopes and roles. Role and scope combinations map to a specific kind of user or account, such as an observer or an admin.

范围包括:

  • 管理组(多个订阅的集合)。
  • 单个订阅。
  • 资源组。
  • 单个资源。

观察者、管理资源的用户、管理员和自动化进程展示了通常分配给不同角色的用户或帐户类型。

Azure RBAC 是分层的,因为在父范围授予访问权限时,这些权限由所有子范围继承。 例如:

  • 如果在管理组范围向用户分配所有者角色,则该用户可以管理管理组中所有订阅中的所有内容。
  • 如果在订阅范围向组分配读者角色,则该组的成员可以查看订阅中的每个资源组和资源。

如何强制实施 Azure RBAC?

应对通过 Azure 资源管理器传递的 Azure 资源执行的任何操作强制实施 Azure RBAC。 资源管理器是一种管理服务,它提供组织和保护云资源的方法。

通常,可从 Azure 门户、Azure Cloud Shell、Azure PowerShell 和 Azure CLI 访问资源管理器。 Azure RBAC 不会在应用程序或数据级别强制实施访问权限。 应用程序的安全问题必须由应用程序处理。

Azure RBAC 使用允许模型。 你分配有角色后,Azure RBAC 允许你在该角色的范围内执行操作。 如果一个角色分配授予你对某个资源组的读取权限,另一个角色分配授予你对同一资源组的写入权限,你就拥有对该资源组的读写权限。