RBAC权限模型与多租户授权架构设计 - 第1节
1.1 传统 ACL 的困境与权限爆炸
在引入 RBAC 之前，绝大多数系统（特别是文件系统与早期企业应用）都采用 访问控制列表（ACL） 作为权限管理手段。ACL 的核心思路是：“直接记录每个用户对每个资源的操作权限”。当用户规模增长至上百人、资源类型超过数十种时，ACL 会迅速暴露出结构性问题。
⚠ 风险点：ACL 的“权限爆炸”
在一个仅有 100 名员工、50 个资源对象的系统中，理论上需要维护 100 × 50 = 5000 条访问控制条目。如果资源增加或人员变动，管理员必须逐条修改，极易遗漏或误配，导致权限泄露或业务阻塞。
在一个仅有 100 名员工、50 个资源对象的系统中，理论上需要维护 100 × 50 = 5000 条访问控制条目。如果资源增加或人员变动，管理员必须逐条修改，极易遗漏或误配，导致权限泄露或业务阻塞。
| 对比维度 | 传统 ACL | RBAC（角色驱动） |
|---|---|---|
| 管理粒度 | 用户 ↔ 资源（N×M 关系） | 用户 ↔ 角色 ↔ 权限（N×R + R×M） |
| 变更成本 | 更换用户职责时需重配所有资源 | 只需调整用户拥有的角色 |
| 审计可追溯性 | 条目扁平，难以分组审计 | 角色作为审计单元，可批量审查 |
| 系统耦合 | 权限逻辑散落在业务代码中 | 权限判断集中在授权服务或中间件 |
1.2 RBAC 的核心思想：引入“角色”中间层
RBAC（Role-Based Access Control）革命性的一点是：在“用户”与“权限”之间增加“角色”这一逻辑抽象层。权限不再直接分配给具体的自然人，而是附着在具备明确定义的“角色”上；用户通过被授予一个或多个角色来获得权限。
这一设计的收益在于：
• 少即是多：角色数量远小于用户数量，权限配置从 N×M 缩减为 N×R + R×M。
• 职责分离：业务人员（如 HR、财务）只需维护用户-角色映射，无需关心资源 ACL。
• 复用与标准化：同一部门或相同岗位的员工共享同一套角色权限，变更仅影响角色定义。
💡 宏观定位：RBAC 是一种授权模型，而非认证协议或委托框架。
它与 OAuth（授权委托协议）和 ABAC（基于属性策略评估）并不在同一抽象层次。RBAC 解决的是“谁可以操作什么对象”，而 ABAC 解决的是“在什么环境条件下可以操作”，OAuth 解决的是“第三方应用如何获得令牌代表用户请求”。三者可以垂直叠加：RBAC 做核心角色授权，ABAC 做动态策略增强，OAuth 做跨域令牌分发。
它与 OAuth（授权委托协议）和 ABAC（基于属性策略评估）并不在同一抽象层次。RBAC 解决的是“谁可以操作什么对象”，而 ABAC 解决的是“在什么环境条件下可以操作”，OAuth 解决的是“第三方应用如何获得令牌代表用户请求”。三者可以垂直叠加：RBAC 做核心角色授权，ABAC 做动态策略增强，OAuth 做跨域令牌分发。
1.3 RBAC vs ABAC vs OAuth 的宏观定位
为避免混淆，下表划清三种技术方案的系统边界与信任链路：
| 模型/协议 | 核心抽象 | 主要解决的问题 | 典型系统边界 |
|---|---|---|---|
| RBAC | 角色 (Role) | 用户分角色授权，降低管理复杂度 | 企业内部应用、管理系统、后台接口 |
| ABAC | 属性 (Attribute) + 策略 | 基于用户、资源、环境属性的动态策略裁决 | 微服务网关、零信任架构、合规敏感场景 |
| OAuth 2.0 | 访问令牌 (Access Token) | 第三方应用获得限定范围令牌 | 开放 API、SSO、跨域授权 |
📌 选型权衡：
1. 如果系统角色固定（<10 种）、用户量小于 10 万，纯 RBAC 是性价比最高的方案。
2. 当需要根据时间、地理位置、设备状态做条件授权时，需在 RBAC 基础上引入 ABAC 策略引擎。
3. 如果涉及第三方应用代理访问用户资源（如支付宝授权登录 xxx），必须用 OAuth 2.0 处理令牌颁发与撤销，而不能用 RBAC 直接替代。
1. 如果系统角色固定（<10 种）、用户量小于 10 万，纯 RBAC 是性价比最高的方案。
2. 当需要根据时间、地理位置、设备状态做条件授权时，需在 RBAC 基础上引入 ABAC 策略引擎。
3. 如果涉及第三方应用代理访问用户资源（如支付宝授权登录 xxx），必须用 OAuth 2.0 处理令牌颁发与撤销，而不能用 RBAC 直接替代。
1.4 信任链路与核心数据流
下图展示了 RBAC 在典型 Web 应用中的身份验证→角色加载→权限判决→资源访问的完整控制流与数据流：
1.5 落地步骤与验收标准（第1章）
| 落地步骤 | 关键活动 | 验收标准 |
|---|---|---|
| 步骤 1 | 梳理现有 ACL 或直配权限清单，识别重复/冗余条目 | 形成至少 1 份权限矩阵（资源 × 用户） |
| 步骤 2 | 抽象业务角色（如“普通员工”、“部门经理”、“系统管理员”） | 角色数小于用户数的 10%，且职责互斥 |
| 步骤 3 | 建立用户-角色、角色-权限两张独立映射表 | 通过 3 个典型场景（新增用户、岗位变更、资源回收）验证映射变更不影响其他权限 |
| 步骤 4 | 明确 RBAC 与公司 SSO/OAuth 系统的边界：认证走 SSO，授权走 RBAC | 设计文档中画出信任链路图，包含身份提供者、授权服务、资源服务器三者关系 |
🏁 第1章验收检查清单：
- [ ] 团队已就“为什么要废除 ACL 直配模式”达成共识
- [ ] 现有系统已统计出角色-权限冗余度（可合并条目数 / 总条目数）
- [ ] 已产出 RBAC、ABAC、OAuth 三者的架构定位图（SVG 或白板图，不低于5个节点）
- [ ] 初步确定第1个试点业务模块（用户<50，角色<5）
- [ ] 团队已就“为什么要废除 ACL 直配模式”达成共识
- [ ] 现有系统已统计出角色-权限冗余度（可合并条目数 / 总条目数）
- [ ] 已产出 RBAC、ABAC、OAuth 三者的架构定位图（SVG 或白板图，不低于5个节点）
- [ ] 初步确定第1个试点业务模块（用户<50，角色<5）
一旦上述步骤完成，就可以向第2章“RBAC 模型的标准定义与分层（Core RBAC / Hierarchical RBAC / Constrained RBAC）”推进。当前章节的核心交付物是：一份基于角色抽象替换 ACL 的迁移方案 + 一张清晰的信任链路图，这为整个课程后续的模型分层、动态约束、混合架构打下了知识基础。