三种主流授权策略的各自特点、优缺点和对比：
基于角色的访问控制Role-Based Access Control (RBAC)
基于属性访问控制Attribute-Based Access Control (ABAC)
访问控制列表Access Control List (ACL)
1. Access Control List (ACL) – 访问控制列表
概述
ACL 是一种以资源为中心的访问控制机制。每个受保护资源（如文件、数据库记录）都附带一个列表，明确列出哪些主体（用户、组）可以执行哪些操作（读、写、删除等）。
特点
- 细粒度：可针对每个资源单独设置权限。
- 直观：与 Unix/Linux 文件权限模型类似（如
chmod）。
- 主体通常是用户或用户组。
优点
- 实现简单，概念清晰。
- 适合静态、资源数量有限的场景（如文件系统、小型应用）。
缺点
- 不易扩展：当用户或资源数量庞大时，管理开销剧增。
- 缺乏上下文：无法基于环境、时间、设备等动态条件做判断。
- 权限分散：权限分散在各个资源上，难以全局审计或批量修改。
2. Role-Based Access Control (RBAC) – 基于角色的访问控制
概述
RBAC 是以角色为中心的模型。权限分配给角色，用户通过被赋予一个或多个角色间接获得权限。
特点
- 三层结构：用户 ↔ 角色 ↔ 权限。
- 支持角色继承、角色互斥（如“会计”和“审计”不能由同一人担任）。
- NIST 标准（如 RBAC0–RBAC3）定义了不同复杂度等级。
优点
- 管理高效：通过角色批量分配权限，降低管理成本。
- 符合组织结构：天然映射企业中的岗位职责（如“管理员”、“编辑”）。
- 易于审计和合规（如 GDPR、HIPAA）。
缺点
- 灵活性不足：难以处理临时权限、跨角色组合或细粒度上下文条件（如“仅在工作时间访问”）。
- 角色爆炸问题：为满足特殊需求不断创建新角色，导致角色数量失控。
3. Attribute-Based Access Control (ABAC) – 基于属性的访问控制
概述
ABAC 是一种策略驱动的动态授权模型。访问决策基于主体、资源、环境、操作等多维属性的逻辑规则（通常用策略语言如 XACML 表达）。
特点
- 四类属性：
- 主体属性（如部门、安全等级）
- 资源属性（如文档密级、所属项目）
- 环境属性（如时间、IP 地址、设备类型）
- 操作属性（如读、写）
- 决策由策略引擎实时计算。
优点
- 高度灵活与动态：支持复杂、上下文感知的授权逻辑。
- 细粒度控制：可实现“某部门员工只能在工作时间访问本部门的非机密文档”这类规则。
- 适合云原生、多租户、零信任架构等现代场景。
缺点
- 复杂度高：策略编写、调试、测试成本高。
- 性能开销：每次请求需实时评估策略，可能影响延迟。
- 工具链不成熟：相比 RBAC，ABAC 的标准化和工具支持仍在发展中。
对比总结
| 维度 |
ACL |
RBAC |
ABAC |
| 控制粒度 |
资源级（较细） |
角色级（较粗） |
属性级（非常细） |
| 管理复杂度 |
低（小规模）→ 高（大规模） |
中（角色管理） |
高（策略编写） |
| 动态性 |
静态 |
静态（角色固定） |
动态（实时决策） |
| 上下文感知 |
否 |
有限 |
是 |
| 适用场景 |
文件系统、嵌入式系统 |
企业应用、SaaS 后台 |
云平台、政府、金融、零信任 |
| 标准化 |
广泛支持（如 POSIX） |
NIST 标准成熟 |
XACML、ALFA 等，但生态较新 |
实际建议
- 小型系统或资源导向型应用（如 CMS、文档库）→ ACL
- 中大型企业系统，角色清晰（如 ERP、HR 系统）→ RBAC
- 需要动态、上下文敏感策略的系统（如多租户 SaaS、微服务 API 网关）→ ABAC，或 RBAC + ABAC 混合模型（如用 RBAC 管理基础权限，ABAC 处理例外规则）
现代系统（如 AWS IAM、Azure AD）往往采用 策略+角色 的混合授权模型，兼顾管理效率与灵活性。
