RBAC概述：我的权限管理入门课
今天我们来聊聊RBAC。
RBAC 的全称是 基于角色的访问控制。说实话，这东西在权限管理领域，就跟数据库里的 SQL 一样基础且重要。我刚开始做安全审计那几年，见过太多“人肉维护权限”的项目，那叫一个乱。后来接触了 RBAC 模型，才意识到——原来权限管理也能有清晰的套路。
核心三要素：用户、角色、权限
RBAC 的底层逻辑其实很简单。三个核心东西：用户、角色、权限。
- 用户（User）：就是操作系统的“人”。可能是真实员工，也可能是自动化程序。谁在访问？
- 角色（Role）：一个抽象的身份标签。比如“财务经理”、“系统管理员”。角色代表了一组权限的集合。
- 权限（Permission）：具体能做什么事。比如“查看财务报表”、“删除用户记录”。说白了就是“能不能干”的问题。
核心逻辑：用户不直接跟权限挂钩。用户先挂到一个角色上，角色再绑定一堆权限。用户通过角色间接获得权限。就是这个“间接”，让权限管理有了伸缩性。
我在项目中遇到过有人想走捷径：直接把权限赋予每个用户。你看，那不就是回到“人肉维护”老路上了？不出半年权限表就会爆炸。
权限赋予逻辑：一句话能讲明白
为什么我说RBAC的关键是“间接”？我们来走一遍实际流程。
- 定义权限：先搞清楚系统里有哪些操作需要控制。比如“创建订单”、“导出报表”…
- 创建角色：把同类型权限打包成一个角色。比如“仓库管理员”角色包含“查看库存”、“入库操作”、“出库操作”…
- 分配角色给用户：新员工来了，直接给他挂一个“仓库管理员”角色。所有权限一次性到位。
我建议你在设计阶段就把角色定义清楚。别想着“以后再加”，那会让权限审计变得非常痛苦。我见过有些项目角色数量膨胀到几百个，审计报表打出来能当枕头用。
应用场景举例：哪些地方必须用RBAC？
说实话，现在稍微有点规模的系统，基本都跑不了RBAC。我挑几个典型的说说。
| 场景 | 为什么用RBAC |
|---|---|
| 企业ERP系统 | 部门多、人员变动频繁。角色能让新员工入职当天就有正确权限。 |
| 银行核心系统 | 合规审计要求高。通过角色控制“不相容职责分离”，比如一个人不能同时拥有“做账”和“审核”权限。 |
| 医院HIS系统 | 医生、护士、药剂师权限完全不同。角色能确保病人数据不被随意查看。 |
| SaaS平台 | 多租户场景。RBAC能轻松实现“不同公司管理员管理各自公司人员”的隔离。 |
注意：RBAC不是万能的。如果你系统里的权限颗粒度到了“某个人能看到某个订单的某一行数据”这种级别，RBAC会变得异常复杂。我曾经在审计时碰到过这种情况——用户有几百个角色，权限审计报表翻半小时都看不完。这时候你可能需要考虑ABAC（基于属性的访问控制）来补充。
嗯，这一章先把RBAC打个底。说白了就是三个词：用户、角色、权限。加上“间接授权”这个关键思路。等你把这三个东西理清楚，后续的审计和权限梳理就能站稳脚跟。