RBAC（Role-Based Access Control）是通过角色把用户和权限间接关联起来的访问控制模型，常用于后台、企业系统和多团队平台。
核心问题
如果直接给每个用户绑定一组权限，用户数量和权限数量增长后会很难维护。RBAC 增加“角色”这一层，让权限按岗位或职责组合，用户只需要被分配到合适角色。
核心机制
RBAC 的最小集合模型可以写成：
Users -> Roles -> Permissions
Permission = Action + Resource| 对象 | 例子 |
|---|---|
| User | alice@example.com |
| Role | admin、operator、viewer |
| Permission | device:read、user:approve、audit:export |
| Resource | 某个设备、租户、项目或后台模块 |
一次权限判断通常是：
roles = roles_of(user)
permissions = union(permissions_of(role) for role in roles)
allow if requested_permission in permissions and resource_scope_matches这里 resource_scope_matches 很重要。只检查动作不检查资源范围，会把“能看自己租户设备”错误扩大成“能看所有设备”。
工程用途
- 管理后台的管理员、运维、只读审计员分权。
- SaaS 租户内的 owner、member、viewer。
- 将企业 IdP 的 group 映射到平台角色。
- 审计“谁被赋予了什么角色”和“某角色包含哪些权限”。
边界与常见坑
- RBAC 不是认证：它假设主体已经通过认证。
- 角色爆炸：每个临时需求都新建角色，会导致角色难以理解。
- 缺少资源范围：只建全局角色会破坏租户隔离或项目隔离。
- 默认权限要保守：首次 JIT 创建用户时不应自动给高权限角色。
- 角色变更要有审计：权限事故常来自角色误配，而不是登录漏洞。