三种主流授权策略

三种主流授权策略的各自特点、优缺点和对比：
基于角色的访问控制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）往往采用 策略+角色 的混合授权模型，兼顾管理效率与灵活性。