Access Control Model 比較
在系統設計中，權限控制（Access Control）是確保資料安全與功能正確授權的關鍵機制。根據系統的複雜度、用戶角色的多樣性，以及資源管理的彈性需求，常見的權限模型主要可分為三種：ACL（Access Control List）、RBAC（Role-Based Access Control）、ABAC（Attribute-Based Access Control）。以下針對這三種模型的設計邏輯、特性與應用情境進行簡要比較，協助釐清選型方向與實作考量。
ACL
直接授權，粒度細，管理困難
- 設計邏輯： 使用者 → 資源 + 操作
若使用者有研發部檔案清單的讀取與更新權限，則可以看到研發部底下所有的資料並對其進行變更。
RBAC
管理簡化，結構清晰，但靈活度有限
- 設計邏輯 角色 → 資源 + 操作；使用者綁定角色
若使用者的角色為部門管理者，則可以對這個部門的所有資源進行 CRUD 操作
ABAC
彈性最高，可做動態條件判斷，根據使用者、資源、環境等的「屬性（attribute）」來決定是否授權。 其中有些變體如 ReBAC（基於關係）, LBAC（基於標籤）
- 設計邏輯 根據「屬性」評估是否可存取資源
若使用者的部門屬性為「人資部門」，且資源屬性為「人事資料」，且當前時間在上班時間內，則允許存取。
比較表
| 項目 | ACL（基於清單） | RBAC（基於角色） | ABAC（基於屬性） |
|---|---|---|---|
| 📘 授權對象 | 使用者 → 資源 | 角色 → 資源 | 使用者屬性、資源屬性、環境屬性 |
| 👤 使用者綁定方式 | 使用者直接被授權 | 使用者被指派角色 | 使用者的屬性參與授權判斷 |
| 🔄 授權方式 | 靜態（每筆明確綁定） | 靜態（角色為主） | 動態條件判斷（基於多個屬性） |
| 🧱 資料表規劃簡單性 | 簡單（但隨規模成長會爆炸） | 中等 | 複雜，需要額外處理屬性、規則邏輯 |
| ⚙️ 彈性/細節控制 | 高（逐筆資源、使用者） | 中（角色級別） | 非常高（可根據任意屬性條件判斷） |
| 📈 維護成本（大型系統） | 高（使用者多時權限難管理） | 低～中（角色合理設計可共用） | 高（規則與屬性組合複雜，需引擎支援） |
| 🔐 權限繼承/共用性 | 低（使用者個別綁定） | 高（角色共用，角色層級） | 高（屬性可泛用） |
| 🛡️ 適合資源數量 | 小型（資源/人數少） | 中～大（適合有穩定角色結構的系統） | 大型、複雜（規則/條件變化多，多租戶） |
| 🧠 理解與落地門檻 | 低 | 低～中 | 高（需抽象思考、規則語言如 XACML、策略引擎如 OPA） |
| 🧭 適用場景 | 個人化小系統、資料敏感需細控的場景 | 企業後台系統、SaaS、多人共用平台 | 銀行/政府/保險系統、動態風控、複雜規則控制、零信任架構 |
| 🧩 典型用例 | Dropbox、Google Drive「分享給某人」 | 公司內部系統（如：Admin、Manager） | 資料等級分類存取、政策驅動 API Gateway |
| 👮🏻♂️ 安全性 | 高（精確控制），但易因人為錯誤導致漏洞 | 中等，依賴角色設計的嚴謹性 | 高（細粒度控制），但需確保屬性和規則無誤 |
| 🏎️ 性能 | 隨規模下降（逐一匹配） | 高，查詢簡單（角色映射） | 低（需計算多個屬性和規則） |
| 🎲 標準化支援 | 無 | NIST RBAC 模型 | XACML |
發佈時間
2025-5-6