權限控制模型全解析：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	動態	極高	極高	?	社交型平臺、圖模型系統

---

📌 最佳實踐建議

• 小團隊項目：RBAC 即可，邏輯簡單
• 多組織 / 多資源協作平臺：RBAC + ACL
• 高度定制化權限系統（多維）：RBAC + ABAC + Policy 引擎
• 面向關系的系統：使用 ReBAC 模型（需額外圖計算支持）