1. RBAC 概述：从理论到落地的第一块基石
RBAC（Role-Based Access Control，基于角色的访问控制）是当今企业级系统中应用最广泛的权限管理模型。它通过引入“角色”这一中间层，将用户与权限解耦，从而大幅降低权限管理的复杂度。本章将从定义、发展历程、对比优势以及核心要素四个维度，为你建立对 RBAC 的完整认知。
1.1 什么是 RBAC
RBAC 的核心思想是：权限不直接授予用户，而是授予角色；用户通过扮演角色获得相应权限。这种间接映射关系使得权限管理从“用户-权限”的 N×N 网状关系，简化为“用户-角色-权限”的线性关系。
一句话定义：RBAC 是一种通过角色将用户与权限解耦的访问控制模型，角色是权限的集合，用户是角色的集合。
1.2 RBAC 的发展历史
| 阶段 | 时间 | 关键事件 |
|---|---|---|
| 萌芽期 | 1970s | 多用户操作系统开始引入“用户组”概念，但权限粒度粗、管理僵化 |
| 理论奠基 | 1992 | David Ferraiolo 和 Richard Kuhn 提出 RBAC 正式模型（NIST 标准前身） |
| 标准确立 | 2001 | NIST 发布 INCITS 359-2004 标准，定义 RBAC 的四个核心层级 |
| 企业普及 | 2005-2015 | ERP、CRM、OA 等企业软件全面采用 RBAC，成为行业默认方案 |
| 云原生演进 | 2016-至今 | Kubernetes RBAC、AWS IAM 等云原生系统将 RBAC 推向细粒度、动态化 |
1.3 RBAC 相比 ACL / DAC 的优势
在 RBAC 成为主流之前，ACL（访问控制列表）和 DAC（自主访问控制）是更早期的权限方案。下表从五个关键维度进行对比：
| 对比维度 | ACL | DAC | RBAC |
|---|---|---|---|
| 管理粒度 | 每个资源独立配置权限列表 | 资源所有者自主决定权限 | 通过角色批量管理权限集合 |
| 扩展性 | 用户数增长时 ACL 条目爆炸 | 依赖所有者管理，缺乏全局视图 | 角色数量远少于用户，扩展性好 |
| 审计追溯 | 权限归属不清晰 | 权限变更记录分散 | 角色-权限映射清晰，审计友好 |
| 最小权限原则 | 难以保证一致性 | 所有者可能过度授权 | 角色设计天然支持最小权限 |
| 变更影响 | 修改权限需逐条更新 ACL | 需通知所有资源所有者 | 仅需修改角色定义，批量生效 |
实践建议：如果你的系统用户数超过 50 人，或存在 3 种以上不同的职能岗位，请直接选择 RBAC。ACL 和 DAC 更适合个人工具或极小型团队。
1.4 RBAC 的三大核心要素
RBAC 模型由三个基本实体构成，它们之间的关系构成了整个权限体系的基础：
- 用户（User）：系统的操作主体，可以是人、服务账号或设备。用户是权限的最终受益者。
- 角色（Role）：权限的逻辑集合，代表一类职能或岗位。例如“管理员”、“审计员”、“普通员工”。
- 权限（Permission）：对某个资源执行特定操作的许可。通常表示为“资源 + 操作”的组合，例如“订单-查询”、“订单-修改”。
三者之间的核心关系可以概括为：
用户 —— 关联 ——> 角色 —— 关联 ——> 权限
多对多 多对多这种结构带来的直接好处是：当某个岗位的职责发生变化时，只需调整角色对应的权限集合，所有关联该角色的用户自动获得更新后的权限，无需逐个修改用户。
1.5 核心要素的落地映射
在实际企业系统中，三大核心要素需要映射到具体的业务对象：
| RBAC 要素 | 数据库表 | 业务示例 | 关键字段 |
|---|---|---|---|
| 用户 | sys_user |
张三（工号 1001） | user_id, username, status |
| 角色 | sys_role |
订单管理员 | role_id, role_name, role_key |
| 权限 | sys_permission |
订单-查询、订单-修改 | perm_id, perm_code, resource |
| 用户-角色关联 | sys_user_role |
张三 → 订单管理员 | user_id, role_id |
| 角色-权限关联 | sys_role_perm |
订单管理员 → 订单-查询 | role_id, perm_id |
常见误区：很多初学者将“角色”等同于“用户组”。严格来说，用户组是用户的集合，而角色是权限的集合。RBAC 中的角色更强调“能做什么”，而非“属于哪个组”。在设计初期就区分清楚，可以避免后续的权限混乱。