RBAC密钥权限设计实战教程 - 第1节
什么是RBAC？从一次权限事故说起
我记得刚带团队那会儿，接手过一个老项目。权限系统用的是ACL（访问控制列表），每个用户都配一堆权限点。结果新员工入职，光配权限就要花半个小时——还得小心翼翼别给多了。后来出了个乌龙：有人离职，权限没清干净，数据被误删了。
那次之后我彻底倒向了RBAC。说白了，RBAC就是用户→角色→权限这三层关系。你把权限赋予角色，再把角色分配给用户。用户通过角色获得权限，而不是直接绑定权限。
三个核心要素
- 用户 (User)：系统操作者，可以是人、服务账号或者设备。
- 角色 (Role)：权限的集合，代表一种职责。比如“审计员”、“运维工程师”。
- 权限 (Permission)：对某个资源的操作许可，比如“读取订单表”、“删除日志文件”。
关键逻辑：用户与会话关联，会话激活角色，角色授予权限。
我曾经犯过一个错：把角色设计成“管理员”“超级管理员”“系统管理员”三个，结果权限重叠得乱七八糟。后来我建议只保留两层——运维角色和审计角色，中间用角色继承搞定。代码量砍了一半，事故率也下来了。
为什么需要RBAC？——ACL的痛点
传统ACL（访问控制列表）长什么样？每个用户挂一张权限表，张三能读文件A，李四能写文件B。这种模式在小团队还行，人一上百就崩溃了。
ACL vs RBAC 对比
| 维度 | ACL | RBAC |
|---|---|---|
| 管理粒度 | 用户 → 权限（1:1） | 用户 → 角色 → 权限（N:1:N） |
| 变更成本 | 改一个权限需遍历所有用户 | 改角色定义，所有用户自动生效 |
| 可审计性 | 权限散落在用户上，难统计 | 角色聚合权限，一目了然 |
| 职责分离 | 需人工约束，容易绕过 | 内置互斥角色、基数约束 |
你想想看，如果公司突然要求所有数据管理员不能同时拥有审批权限——在ACL里你得查一遍所有用户，再手动剔除。RBAC里只需要定义两个互斥角色，然后重新分配就行了。
注意：RBAC不是银弹。如果你的系统只有3个用户，权限也简单，ACL反而更直接。别为了用RBAC而引入角色。
RBAC核心模型速览
NIST（美国国家标准与技术研究院）给出了RBAC参考模型，分四个层面。我不打算把搬过来，但下面这张图能帮你快速建立印象。
这张图你可以保存下来，之后每一章都会用到。实际项目中，角色继承和约束是最容易被忽略的。我见过有团队把所有角色都设成“管理员”，然后通过“角色名包含admin”来鉴权——这不叫RBAC，这叫换个名字的ACL。
四种RBAC层级的应用场景
- 扁平RBAC（Core RBAC）：用户↔角色↔权限，无继承。适合小团队，权限不超过20个。
- 层次RBAC（Hierarchical RBAC）：角色可继承。比如“高级工程师”继承“初级工程师”的全部权限。我在电商项目里常用这种，运维分三级，每级权限自动叠加。
- 约束RBAC（Constrained RBAC）：增加互斥角色、基数限制。金融系统必须用这个——同一个用户不能既是出纳又是复核。
- 对称RBAC（Symmetric RBAC）：允许用户和角色之间多对多，且角色和权限也多对多。现实中很少用全，因为管理成本太高。
记住一句话：RBAC的价值不在技术，而在管理。你只要设计好角色树，后面所有权限变更都变成角色配置的单点操作。这才是它被各大系统（AWS IAM、Kubernetes RBAC、Spring Security）广泛采用的原因。
我建议这样入门RBAC
如果你要在一个新项目里落地RBAC，别急着写代码。先做三件事：
- 梳理所有业务资源，定出权限点（比如“创建工单”、“删除日志”）
- 画角色树，每个角色对应一组权限集合
- 定约束规则：哪些角色不能同时分配给一个用户