第二章 RBAC 模型核心概念：角色、权限、用户、会话

RBAC 听着玄乎，其实拆开看就四个东西——用户、角色、权限、会话。我当年第一次接触 RBAC，看文档看得头大，后来发现核心就是一句话：用户通过角色获得权限，会话控制激活范围。咱们这一章就把这四个概念掰开揉碎，再画一张关系图，让你一次性吃透。

2.1 四大核心元素

2.1.1 用户（User）

用户就是系统中的操作主体，可以是一个人、一个服务账号、甚至一个外部系统。说白了，谁在干活，谁就是用户。

2.1.2 角色（Role）

角色是 RBAC 的精髓。你想想看，如果我们给每个用户单独分配权限，1000 个用户就得管 1000 份权限表，谁受得了？角色就是「权限的集合体」，比如「管理员」「审计员」「操作员」。我们把权限绑定到角色上，再把角色分配给用户。

我早期犯过一个错：把角色设计成岗位名称，比如「运维总监」「值班工程师」。后来发现一个人调岗就得重建角色。正确的做法是——角色对应权限粒度，不对应职位。「日志查看员」「配置修改员」这种才是好角色。

2.1.3 权限（Permission）

权限就是「能不能做某件事」。标准 RBAC 里，权限通常拆成两部分：资源 + 操作。

• 资源：你要碰的东西，比如「订单表」「用户列表」「配置文件」
• 操作：你对它干什么，比如「增、删、改、查、导出」

举个例子，「删除订单」这条权限 = 资源「订单」 + 操作「删除」。我在项目里喜欢把权限写成 resource:action 的格式，比如 order:delete，清晰又方便做自动化校验。

2.1.4 会话（Session）

会话是很多人忽略的点。用户登录系统后，会创建一个会话。在 RBAC 里，会话的作用是限制角色在本次登录中是否生效。一个用户可能有「管理员」和「普通用户」两个角色，但他登录时可以选择只激活「普通用户」角色，这就是最小权限原则的具体落地。

2.2 核心关系图

下面这张图，把这四个元素串起来了。我建议你多看两遍，理解箭头的方向——它代表了 RBAC 的约束流向。

2.3 基本关系与约束

上面的图里，你能看到三条主要关系线：

1. 用户 ↔ 角色：多对多。一个用户可以有多个角色，一个角色也可以赋予多个用户。
2. 角色 ↔ 权限：也是多对多。一个角色包含多个权限，一个权限可以出现在多个角色里。
3. 会话 ↔ 角色：一对多。一个会话可以激活多个角色，但只能从用户已有的角色集合里选。

2.4 实践中的角色设计误区

我见过太多团队把 RBAC 做成了「用户权限管理工具」，完全丢了角色这个抽象层。这里列几个常见坑：

2.5 会话管理的一个真实教训

讲个真事。我之前负责一个后台管理系统，上线半年一直没问题。直到有一次安全扫描发现：一个普通运维用他的账号登录后，竟然能通过切换角色拿到管理员权限。

查了一周，原因出在会话层——我们的 RBAC 实现里，用户登录后把所有角色都塞进了会话，前端页面只是把高权限按钮隐藏了，但后端接口没做二次校验。攻击者直接调 API，角色就生效了。

2.6 核心元素速查表

最后，我给你一张速查表，方便以后复习或者做方案时快速翻阅：