1. RBAC 模型概述：从混乱到有序的权限治理

大家好，我是这次课程的主讲。先聊聊我自己的一个经历——刚入行那会儿，我管过一台内部 Wiki 服务器，用户就三十来号人。权限怎么管理的？直接在系统里给每个人配 `sudo`，谁要什么文件我就改一遍 `chmod`。那时候没出事，纯粹是运气好。后来项目大了，用户破千，我对着权限表彻底懵了：谁能改什么、谁不该看什么，完全是一本烂账。这就是没有 RBAC 的后果。

RBAC，全称 Role-Based Access Control，中文叫基于角色的访问控制。说白了，就是不再把人当成权限的基本单位，而是把角色作为管理核心。用户通过角色获得权限，而不是直接跟权限挂钩。这个转变，把权限管理从「点对点」的野蛮模式，拉进了「点对面」的工程化时代。

1.1 核心三要素：用户、角色、权限

RBAC 最核心的概念就三个东西，我习惯叫它「铁三角」：

• 用户 (User)：系统里真实操作的人或服务账号。在审计日志里，用户就是那个留下操作痕迹的主体。
• 角色 (Role)：一个权限的集合，代表一类职责。比如「审计管理员」这个角色，就包含了查看日志、导出日志、配置存储策略等一堆权限。
• 权限 (Permission)：对系统资源的操作许可。比如「读取日志文件」、「写入审计记录」、「删除归档」。在 RBAC 里，权限只跟角色绑定。

我在项目中遇到过一种情况：有两个用户，张三和李四，他们都属于「日志查询员」角色。但张三因为个人能力强，老板额外给了「删除日志」的权限。这就坏了规矩——权限直接绑在了用户身上，脱离了角色控制。后来审计的时候发现，张三删掉了一批关键记录，李四却因为角色相同被误认为是嫌疑人。这个坑，完全是权限设计没遵循 RBAC 造成的。

三者之间的关系，我画了一张图，你看一眼就懂了：

1.2 发展历史：RBAC 是怎么长成今天这样的？

RBAC 不是一天建成的。我把它分成三个阶段，你看完就知道为什么今天必须用它：

阶段	时间	特点	我见过的问题
混沌期	1990 年代前	ACL 直接绑用户 权限表奇大无比	有个系统 500+ 用户，ACL 表 4000 多行，维护人员辞职后谁也看不懂
理论成型期	1992–2000	NIST 发布 RBAC 标准 提出核心三要素	我做第一个 RBAC 系统时，照着抄了一段代码，发现角色继承全是坑
工业成熟期	2000 至今	RBAC0/1/2/3 成体系 融入云服务、审计合规	现在几乎每个云平台（AWS IAM、Azure RBAC）都在用这个模型

为什么要提这段历史？因为很多团队在切换 RBAC 的时候，还停在混沌期的思维里——老板说「给张三开个权限」，意思就是直接改张三的权限位。你想想看，一个系统如果每个用户都直接绑定权限，那跟十年前有什么区别？

1.3 常见 RBAC 变种：四个级别，对应不同规模

NIST 把 RBAC 分成了四个级别，我按复杂度从低到高给你列出来：

1. RBAC0 – 核心模型：只有"用户-角色-权限"三级结构。适合小团队、简单应用。我建议创业期的产品先用这个，够用就行。
2. RBAC1 – 角色继承：角色之间可以形成父子关系，子角色自动继承父角色权限。比如「超级审计员」继承「审计员」的所有权限。这里有个坑——我曾经的团队在角色继承图上搞出了死循环，系统直接崩了。
3. RBAC2 – 约束模型：加入职责分离（SoD）。比如一个人不能同时担任「审计员」和「日志删除员」。这在金融审计场景是硬性要求。我曾经历过一次合规检查，因为没做 SoD，被监管当场要求整改。
4. RBAC3 – 统一模型：等于 RBAC1 + RBAC2，既有继承又有约束。这是目前大型企业用的东西，通常是几百个角色、几千条约束规则的复杂度。

1.4 为什么审计日志需要 RBAC？

这个问题，我换个角度问：如果没有 RBAC，审计日志会变成什么样？

• 每个用户的操作日志，你没法快速判断「这个操作谁批准的」。
• 出一个安全事故，排查下来用户权限改过 50 次，每次都没记录。
• 离职员工的权限回收不干净，留下后门。

RBAC 让审计日志清晰很多。因为你只要记录「用户在什么时间被赋予了哪个角色」，剩下的权限检查全部由角色定义完成。嗯，这就是 RBAC 的核心价值——把权限管理从「打补丁」变成「建框架」。