Azure权限管理深度解析：从基础角色到自定义权限设计-CSDN博客

本文链接：https://blog.csdn.net/gitblog_00138/article/details/148992976

Azure权限管理深度解析：从基础角色到自定义权限设计

一、Azure角色分配机制解析

在Azure云环境中，角色分配是实现资源访问控制的核心机制。通过角色分配，管理员可以精确控制谁能够访问哪些资源以及执行哪些操作。

1.1 角色分配的基本特性

Azure的角色系统采用委托资源管理模式，这意味着权限可以逐级向下委托。角色本质上是一组相关权限的集合，这些权限会根据资源类型的不同而有所差异。例如，针对虚拟机的权限集与针对存储账户的权限集是完全不同的。

1.2 作用域(Scope)的层级结构

Azure采用四级作用域层级，权限会按照以下顺序自动继承：

管理组(Management groups) - 最高层级，可跨多个订阅
订阅(Subscription) - 基础计费单位
资源组(Resource groups) - 逻辑资源容器
单个资源(Individual resources) - 最细粒度

这种层级设计使得权限管理既灵活又高效，管理员可以根据实际需求选择最适合的授权层级。

1.3 可分配对象类型

角色可以分配给以下三种主要类型的对象：

用户：组织内的个体成员
组：用户集合，简化批量管理
服务主体：
- 应用程序身份
- 系统分配的托管身份（适用于应用服务、函数应用、虚拟机等）
- 用户分配的托管身份

二、Azure角色类型详解

2.1 内置角色

Azure提供了60多种内置角色，覆盖了大多数常见场景。以下是几个最常用的内置角色：

所有者(Owner)：拥有完全控制权，包括管理资源和分配权限
参与者(Contributor)：可以管理资源，但不能管理访问权限
读取者(Reader)：仅查看权限，无法做任何修改
存储Blob数据读取者(Storage Blob Data Reader)：专门针对存储账户的读取权限
SQL DB参与者(SQL DB Contributor)：管理SQL数据库但不包括访问控制
VM参与者(VM Contributor)：管理虚拟机但不包括访问控制

2.2 自定义角色

当内置角色无法满足特定需求时，可以创建自定义角色。值得注意的是，自定义角色目前只能通过PowerShell、CLI或REST API创建。

一个典型的自定义角色JSON定义如下：

{
  "Name": "网络资源查看者",
  "IsCustom": true,
  "Description": "允许读取Azure网络资源",
  "Actions": [ "Microsoft.Network/*/read" ],
  "NotActions": [ ],
  "AssignableScopes": [ "/subscriptions/048.." ]
}

关键字段说明：

Actions：定义允许的操作
NotActions：定义排除的操作
AssignableScopes：指定可分配的作用域

三、经典管理员角色与现代RBAC对比

3.1 经典管理员角色体系

Azure早期采用了一套经典管理员角色系统，主要包括：

账户管理员(Account Administrator)
- 每个Azure账户唯一
- 主要负责计费相关功能
- 无Azure门户访问权限
服务管理员(Service Administrator)
- 每个订阅唯一
- 默认与账户管理员相同
- 拥有订阅范围内的所有者权限
- 拥有完整的Azure门户访问权限
共同管理员(Co-Administrator)
- 每个订阅最多200个
- 同样拥有订阅范围内的所有者权限