1. RBAC 概述：角色就是权限的门闩
权限管理这件事，说大不大，说小不小。我刚入行那会儿，在一个创业公司写后台，权限全靠 if-else 硬编码——用户 ID 在名单里就放行，不在就拦着。结果呢？每次新功能上线都要改代码，改完还要提心吊胆地测一遍。后来接触了 RBAC，才意识到：把权限挂在角色上，而不是人身上，才是最靠谱的设计。这一章我就把 RBAC 的来龙去脉拆开讲讲，用我踩过的坑给你铺路。
1.1 什么是 RBAC？
RBAC，全称 Role-Based Access Control，基于角色的访问控制。说白了，就是把“谁可以做什么”这个问题，拆成“用户属于哪个角色”和“角色拥有哪些权限”。你想想看，现实世界里也是这样——公司里有“管理员”“编辑”“普通员工”这些角色，每个角色干不同的事。系统里也一样。
我最早误解过：以为 RBAC 就是给每个人打一堆标签。后来才发现，核心在于角色是权限与用户之间的中间层。用户不直接拥有权限，权限只分配给角色。用户通过被赋予角色，间接获得权限。这样一来，新增员工、调岗、离职，我只是改一下角色关系，不用碰权限本身。
核心公式：用户 ↔ 角色 ↔ 权限 —— 三层分离，职责清晰。
1.2 发展历史：从 ACL 到 RBAC 的演进
RBAC 不是凭空冒出来的。在它之前，最流行的叫 ACL（访问控制列表）。ACL 的思路是每个资源上挂一个列表，写清楚哪些用户能访问。比如一个文档，列表里写上“张三可读、李四可写、王五不可”。在只有十几个用户的系统里还能凑合用，但一旦用户量上千，每个资源维护一个列表，简直就是噩梦。
我记得有一次做内部 CMS，项目组有 60 多人，每个文档都得手动配 ACL。结果某天一个新来的同事没配好，把未发布的稿件全暴露给了所有人……从那以后，团队再也没敢用 ACL 做细粒度控制。
RBAC 的概念最早在 1992 年由 Ferraiolo 和 Kuhn 提出，后来美国国家标准技术研究院（NIST）在 2001 年发布了 RBAC 标准模型（ANSI INCITS 359-2004）。这个模型定义了四个等级：
| 等级 | 说明 | 典型特征 |
|---|---|---|
| Flat RBAC | 用户-角色多对多，没有角色层次 | 每个角色完全独立 |
| Hierarchical RBAC | 角色可以继承，上级角色拥有下级的所有权限 | 比如“经理”继承“员工”的权限 |
| Constrained RBAC | 引入职责分离（SoD），角色互斥 | 不能同时担任“审批人”和“申请人” |
| Symmetric RBAC | 权限和角色可以双向审查 | 支持权限回收、角色审计 |
我的建议：大多数互联网产品做到 Hierarchical RBAC 就够了。先别急着上 Constrained，容易把自己绕晕。
1.3 核心概念：角色、权限、用户、会话
好，咱们拆开看这几个关键元素：
- 用户（User）：系统操作的主体，可以是一个人、一个服务账号或一个设备。
- 角色（Role）：一组权限的集合，比如“订单管理员”“内容审核员”。
- 权限（Permission）：对一个或多个资源的操作许可，比如“读取订单列表”“编辑文章”。
- 会话（Session）：用户激活角色的过程。一个用户一次登录可以激活多个角色，但也可以不激活所有可用角色。
这里有一个容易忽略的点：角色本身也可以有层次关系。有一次我在一个项目中设计“超级管理员”和“普通管理员”，超级管理员的权限是普通管理员的超集。我当时直接用数据库存了所有权限——每条角色都独立存一份权限列表。结果超级管理员有 400 条权限记录，普通管理员有 300 条。后来改成角色继承，超级管理员只要说“继承普通管理员 + 额外 100 条”就完了，数据量直接砍半。嗯，这里要注意，角色层次不是必需，但能省事。
1.4 常见应用场景
RBAC 适用面很广，我挑几个典型场景说说：
- 企业后台管理系统（如 OA、ERP、CRM）——用户量大，岗位变动频繁，角色天然对应部门职能。
- SaaS 多租户平台——每个租户内部有独立角色体系，但平台有个全局超管角色。
- API 网关/微服务权限——服务调用者扮演“app 角色”，通过角色控制接口访问范围。
- 内部运维平台（CMDB、堡垒机）——严格职责分离，比如“运维人员”不能同时拥有“审计”角色。
举个我实际遇到的例子：一个做电商 SaaS 的朋友，他们的平台允许每个商家自定义“店长”“客服”“财务”角色。但平台方需要留一个“超级管理员”角色能跨店查看运营数据。他们用了两层 RBAC——平台层和租户层。平台层角色面向平台运营人员，租户层角色面向商家的员工。两个体系互不影响。一开始他们想把所有角色揉在一起，后来发现权限会互相覆盖，出过几次数据泄露预警……真的是教训。
1.5 RBAC 的优势
相比传统的 ACL 或直接给用户授权，RBAC 的好处很明显：
| 优势 | 解释 |
|---|---|
| 简化管理 | 新增员工只要分配角色，不用一条条配置权限 |
| 支持最小权限原则 | 角色只包含完成工作所需的最少权限 |
| 职责分离（SoD） | 通过角色互斥防止利益冲突 |
| 审计友好 | 通过角色审查谁有什么权限，远比直接查用户列表清晰 |
| 可扩展性 | 增加新功能只要创建新角色，旧角色不受影响 |
注意：RBAC 不是万能药。如果系统内角色爆炸（比如某公司有 2000 个角色），那就说明设计出了问题。我曾经见过一个团队给每个岗位都创建了专属角色——结果新员工入职第一周资源组管理员要花半天建角色……这已经背离 RBAC 的初衷了。
1.6 一张图看懂 RBAC 核心关系
下面我用一张 SVG 把用户、角色、权限、会话以及角色层次的关系画出来。看一遍就清楚了：
看到这张图你就明白了：用户不直接碰到权限，中间隔着角色层。会话就像一次“开关”，决定用户这次登录时激活哪些角色。角色之间还能形成继承树——比如“高级角色”自动获得“基础角色”的所有权限。这就是 RBAC 的骨架。