后端权限模型通常分为下面几类，实际系统往往是组合使用。
| 模型 | 核心判断 | 适用场景 | 示例 |
|---|---|---|---|
| RBAC（角色权限） | 用户是否拥有某角色，角色是否拥有权限 | 管理后台、企业系统 | 管理员可删用户；开发者可发布应用 |
| ACL（访问控制列表） | 某个资源允许哪些具体用户/主体访问 | 文件、文档、项目等资源级授权 | 文档 A 允许张三读写、李四只读 |
| ABAC（属性权限） | 根据用户、资源、环境属性动态决策 | 多租户、复杂数据权限 | 仅允许“所属部门=当前用户部门”的数据 |
| PBAC（策略权限） | 使用可配置策略引擎判定 | 规则复杂、需运营配置 | 工作日、内网且风险等级低时允许导出 |
| ReBAC（关系权限） | 根据主体和资源之间的关系判断 | 协作平台、社交、知识库 | 项目成员、文档协作者可访问 |
| MAC（强制访问控制） | 按安全等级与密级强制控制 | 政务、军工、高安全系统 | 机密级用户不能读绝密文档 |
| DAC（自主访问控制） | 资源拥有者自行授予/回收权限 | 文件系统、个人资源 | 文件创建者分享给指定同事 |
最常见：RBAC
用户 → 用户角色关系 → 角色 → 角色权限关系 → 权限用户：zhangsan
角色：应用管理员
权限：app:create、app:publish、app:delete优点是易理解、易管理；缺点是资源范围复杂时，角色会膨胀。你当前工程基本是这个模式，并通过 moduleKey + moduleType 给角色增加资源作用域。
RBAC 的常见扩展
- RBAC0：用户、角色、权限三者基础关系。
- RBAC1：支持角色继承，例如“超级管理员”继承“管理员”。
- RBAC2：支持约束，例如职责分离、互斥角色、角色人数上限。
- RBAC3：RBAC1 + RBAC2。
ACL：资源直接授权
project:1001
zhangsan: READ, WRITE
lisi: READ适合每份资源的授权都不同的场景。缺点是数据量与管理复杂度会随资源数量快速增长。
ABAC：属性驱动
allow if:
user.tenantId == resource.tenantId
&& user.departmentId == resource.departmentId
&& request.time within workHours属性可来自：
- 主体：用户、角色、部门、岗位、租户；
- 资源：所属组织、创建人、密级、状态；
- 环境：IP、时间、设备、地域、风险等级；
- 操作：查看、编辑、导出、删除。
它比 RBAC 灵活，但规则调试、审计与可解释性更难。
ReBAC：关系驱动
viewer(document) = owner
or editor
or member_of(document.project)适合“项目成员可看项目资料”“上级可查看下属数据”“好友可查看动态”等关系网密集的产品。常见实现思路参考 Google Zanzibar 类模型。
工程上常用的组合
认证（SSO / JWT / Session）
→ 功能权限：RBAC
→ 数据范围：RBAC Scope / ABAC
→ 单资源共享：ACL 或 ReBAC
→ 高风险动作：PBAC（附加时间、IP、审批等策略）例如：
- “能否进入应用管理页”：RBAC。
- “能看哪些应用”：按租户、项目、部门做 ABAC 或带资源范围的 RBAC。
- “能否查看某个被分享的文档”：ACL/ReBAC。
- “能否导出全量数据”：RBAC 基础权限 + PBAC 风险策略。
实践中，不建议一开始就上纯 ABAC 或复杂策略引擎。多数企业后台先采用 RBAC + 资源作用域，当出现文档分享、跨组织协作、细粒度资源授权时，再补充 ACL 或 ReBAC。