1. RBAC 模型概述：概念、演变历史与核心价值
到底什么是 RBAC？
我先问你一个问题：你负责的系统里，是不是每次加一个新员工，就得给他在数据库里配一堆权限？删改查、菜单、按钮……搞错一个就出事故。说白了，你缺的是一套“权限模板”。
RBAC（Role-Based Access Control），就是那个模板。它的核心思路很简单：不直接给人授权，而是给“角色”授权，再把角色分配给用户。
- 用户：就是人，或者调用 API 的服务账号。
- 角色：一组权限的集合，比如“管理员”、“编辑”、“仅查看”。
- 权限：能干什么事，比如“创建订单”、“删除用户”、“读取报表”。
我几年前接手一个遗留系统，里面直接给每个用户写了一堆 permission 记录。改一个权限要扫全表，想想就崩溃。后来我重构时第一件事就是引入 RBAC 三层结构，代码量减了一半，维护也轻松多了。
一句话记住 RBAC：用户不直接拥有权限，用户通过角色获得权限。中间加一层“角色”，所有管理都变得可控。
RBAC 的演变：从无到有，从粗到细
权限控制这事，不是一开始就有 RBAC 的。我刚开始做开发时，很多系统直接用硬编码判断 if (user.isAdmin)，后来知道那叫“自主访问控制”（DAC），每个文件所有者自己决定谁能看。再后来出现了“强制访问控制”（MAC），系统统一规定安全级别，比如绝密、机密、公开。
但这两套都有问题：
- DAC 太散，权限管理权下放给用户，容易乱。
- MAC 太死，不够灵活，不适应业务变化。
于是 90 年代，美国国家标准与技术研究院（NIST）提出了 RBAC 模型。它正好解决了灵活性和可控性的矛盾。我印象很深，第一次看到 NIST 的 RBAC 参考模型时，觉得这结构太优雅了——分成了 核心 RBAC、层级 RBAC、约束 RBAC 三部分。
| 发展阶段 | 典型模型 | 特点 | 我的经验感受 |
|---|---|---|---|
| 早期 | DAC / MAC | 要么散，要么硬 | 维护过 DAC 系统，改权限比写代码还累 |
| 1992 | 核心 RBAC（NIST） | 用户-角色-权限三层 | 我第一个 RBAC 项目就是按核心模型做的 |
| 1996 | 层级 RBAC | 角色可以继承 | 比如“高级管理员”继承“普通管理员”的权限 |
| 2001 | 约束 RBAC | 互斥、基数、前提条件 | 处理“一个人不能既是会计又是出纳”的场景 |
一个小坑：级别越高的角色权限越多，但别忘了“最小权限原则”——角色只给够用的权限，别把管理员的所有权限都给一个普通编辑。
RBAC 的核心价值：为什么我现在还在用它？
干过几个大项目后，我越发觉得 RBAC 不是过时货，而是基础架构的“稳基石”。它的核心价值体现在几个方面：
- 简化管理：权限集中到角色上，新增、修改、删除都改角色就行，不用挨个用户操作。我曾经有个 5000 用户的系统，光改一个“上传文件”权限，之前需要写脚本跑全表，改成 RBAC 后一条 SQL 搞定。
- 职责分离：通过互斥角色，防止一个人拥有冲突权限。比如财务系统的“创建付款单”和“审批付款单”不能是同一人。
- 扩展性好：新功能来了，只需要新建角色或给角色加权限，用户那边几乎零改动。我在一个 SaaS 平台上实践过，每两周发一个版本，权限配合角色扩展从来不是瓶颈。
- 审计合规：每个用户有什么角色、每个角色有什么权限，清晰可查。遇到安全审计，拿出 RBAC 模型图就讲明白了。
注意！RBAC 不是万能的。如果角色数量膨胀到成百上千个，或者用户需要“按数据维度”分级授权（比如只能查看自己部门的订单），那就要考虑加入 ABAC（属性基访问控制）补充。但这属于进阶话题，咱们后面会讲到。
我个人习惯在项目初期就定好 RBAC 的数据库结构：用户表、角色表、权限表，再加上用户-角色关系表和角色-权限关系表。代码里弄个 Service 层封装角色分配和检测逻辑。你想想看，这样一来，后来的开发新同学都不用看业务代码，光看角色权限表就知道系统大概怎么运转的了。
一张图看懂 RBAC 核心关系
下面我把用户、角色、权限这三者的关系画成一张结构图。这个图我经常贴在项目 Wiki 首页，新同事看一眼就明白了。
重点回顾：用户 → 角色 → 权限，方向单一，不逆向。角色是中间人，它决定了用户能做什么。
好了，这一章我们聊了 RBAC 是什么、怎么来的、以及为什么值得用。下一段我们不会急着讲配置，先让你脑子里的“RBAC 骨架”搭起来。记住：没有 RBAC 的系统，权限管理就是一团乱麻。从今天开始，让你的系统先长出“角色”这根骨头。