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。