权限控制模型全解析：RBAC、ACL、ABAC 与现代混合方案

在企业信息系统、SaaS 应用、安全平台中，权限控制模型是确保用户访问安全和功能隔离的基础架构设计之一。本文将系统性梳理常见的权限控制模型，包括 RBAC、ACL、ABAC、DAC、MAC、ReBAC 等，分析它们的原理、优劣与应用场景，帮助开发者和架构师选择合适的权限设计方案。

1️⃣ DAC（Discretionary Access Control，自主访问控制）

核心思想：资源的所有者决定谁可以访问。

用户对自己创建的资源拥有完全控制权，可以授予他人访问权限。
类似于 Linux 的文件系统权限模型。

适用场景：

文件系统
单机应用

缺点：

缺乏集中策略，权限可能被随意扩散。

2️⃣ MAC（Mandatory Access Control，强制访问控制）

核心思想：系统基于安全等级进行集中控制，用户无权更改。

用户、资源都被打上安全标签（如：Top Secret, Confidential）。
系统根据标签定义访问矩阵。

适用场景：

政府、军队、金融等高度安全场景

缺点：

灵活性差，不适合业务型应用系统。

3️⃣ RBAC（Role-Based Access Control，基于角色的访问控制）

核心思想：用户拥有角色，角色拥有权限。

用户（user）→ 角色（role）→ 权限（permission）

优点：

易于集中管理权限
支持组织结构映射（如管理员、编辑、访客）

缺点：

资源级别控制能力弱
灵活性不够，无法表达条件化控制（如“仅可访问自己创建的项目”）

适用场景：

企业后台系统
CMS / HR / ERP 等模块清晰系统

4️⃣ ACL（Access Control List，访问控制列表）

核心思想：每个资源定义它的访问者清单。

资源（resource）→ [允许访问的用户或用户组列表]

优点：

资源级权限控制精细化
灵活直观，适合按文档、项目、任务等单位划分权限

缺点：

控制难以集中管理
难以表达组织结构逻辑

适用场景：

文档系统（如 Google Docs）
项目协作工具（如 Trello）

5️⃣ ABAC（Attribute-Based Access Control，基于属性的访问控制）

核心思想：权限判断基于用户、资源、环境的属性组合。

规则示例：user.department == "finance" && resource.type == "report" && time < 18:00

优点：

动态、细粒度控制
灵活支持多维策略（部门、区域、时间、设备类型等）

缺点：

策略管理复杂
逻辑表达需要策略引擎（如 Casbin, OPA）支持

适用场景：

多租户 SaaS 系统
精细化权限系统

6️⃣ ReBAC（Relationship-Based Access Control，基于关系的访问控制）

核心思想：权限由用户与资源之间的关系图定义。

用户 --[owner]--> 项目
用户 --[shared_with]--> 报告

优点：

可表达复杂层级关系与继承
动态权限表达能力强

缺点：

实现复杂，需关系图引擎支持

适用场景：

社交网络
多级组织平台（如 Notion、GitHub）

🔁 现代混合权限系统架构

实际系统往往不是单一模型，而是融合设计，例如：

RBAC + ACL：角色管理基础权限，ACL 管控资源级访问
RBAC + ABAC：角色定义主权，属性控制动态决策（SaaS 多租户常见）
RBAC + ReBAC：角色控制操作，关系决定资源可见性（如 GitHub 团队+仓库）

✅ 总结对比表

模型	粒度	灵活性	管理成本	是否常用	推荐用途
DAC	粗	中	低	❌	单机权限、低安全要求
MAC	中	低	高	⚠️	高安全领域（军事、金融）
RBAC	中	中	低	✅	企业后台、常规系统
ACL	细	中	高	✅	文档权限、项目级协作
ABAC	非常细	高	高	⏳	多租户、动态策略系统
ReBAC	动态	极高	极高	⏳	社交型平台、图模型系统