权限设计模式

ACL（Access Control List）：访问控制列表 用户 -> 权限

RBAC介绍 （Role-Based Access Control，基于角色的访问控制）-实现用户和角色的解耦

一、四大权限模型对比

模型	核心思想	关系结构	适用场景	复杂度
ACL	直接给用户分配权限	用户 ↔ 权限（直接）	用户少、权限简单的系统	⭐ 低
RBAC	通过角色间接分配权限	用户 ↔ 角色 ↔ 权限	用户多、角色分明的企业系统	⭐⭐ 中
ABAC	基于属性动态判断权限	用户属性 + 资源属性 + 环境属性 → 决策	复杂动态场景（如数据隔离、时间限制）	⭐⭐⭐ 高
PBAC	基于策略组合权限规则	策略集 → 规则引擎 → 权限决策	超大规模、多租户、合规要求高的系统	⭐⭐⭐⭐ 很高

---

二、详细解析

1. ACL（Access Control List）访问控制列表

用户A ──→ [权限1, 权限2, 权限3] 用户B ──→ [权限2, 权限4]

特点：直接、简单、无中间层
缺点：用户量上千时，授权管理噩梦
典型应用：Linux文件权限、早期小型后台系统

---

2. RBAC（Role-Based Access Control）基于角色的访问控制

用户A ──→ 角色"财务经理" ──→ [审批报销, 查看报表, 导出数据] 用户B ──→ 角色"普通会计" ──→ [录入凭证, 查看报表]

演进版本：

版本	新增能力	说明
RBAC0	基础模型	用户-角色-权限三要素
RBAC1	角色继承	角色可继承（如"技术总监"继承"开发工程师"权限）
RBAC2	角色约束	互斥角色（如"会计"与"审计"不能兼任）
RBAC3	统一模型	RBAC1 + RBAC2 的完整版

典型应用：绝大多数企业管理系统（ERP、OA、CRM）

3. ABAC（Attribute-Based Access Control）基于属性的访问控制

规则示例： IF

        用户.部门 == "销售部" AND 资源.创建时间 > 2024-01-01 AND 环境.当前时间 < 18:00   

      THEN

        允许访问

三类属性：

• 主体属性：用户部门、职级、入职时间等
• 资源属性：数据所属区域、密级、创建时间等
• 环境属性：访问时间、IP地址、设备类型等

典型应用：云资源权限（AWS IAM）、数据行级权限、动态数据脱敏

---

4. PBAC（Policy-Based Access Control）基于策略的访问控制

策略集示例：

策略1：GDPR合规策略 → 欧盟用户数据禁止出境

策略2：SOX合规策略 → 财务数据修改需双人审批

策略3：内部策略 → 离职员工自动回收权限

特点：策略可组合、可版本化、支持合规审计
典型应用：金融、医疗、政务等强合规行业

---

三、选型决策树

开始 │ ▼ 用户数量 < 50？ ──是──→ ACL（快速上线） │否 ▼ 权限规则是否经常变化？ ──是──→ ABAC（灵活应对） │否 ▼ 是否需要复杂合规审计？ ──是──→ PBAC（策略驱动） │否 ▼ 角色职责是否清晰稳定？ ──是──→ RBAC（业界标准） │否 ▼ 混合方案：RBAC + ABAC（角色打底，属性细化）

---

四、实际组合应用

场景	推荐方案	说明
通用后台管理系统	RBAC	成熟、开发成本低
SaaS多租户平台	RBAC + 数据行级权限（ABAC思想）	租户数据隔离
金融核心系统	RBAC + PBAC合规策略	满足审计要求
大数据平台	ABAC 为主	字段级、行级动态脱敏
超大规模互联网应用	RBAC + ABAC + PBAC 分层	不同场景用不同模型

---

五、关键结论

对比维度	最佳实践
开发成本	ACL < RBAC < ABAC < PBAC
灵活性	ACL < RBAC < ABAC < PBAC
可维护性	ACL < ABAC < RBAC < PBAC（RBAC平衡最优）
扩展性	RBAC可通过"角色组"、"权限集"适度扩展，避免过早ABAC

80%的业务系统用RBAC足够，遇到数据隔离、动态规则时再引入ABAC属性，合规强需求才上PBAC。