iT邦幫忙

2026 iThome 鐵人賽

DAY 23
0
Software Development

從登入到授權-現代軟體的身分架構指南系列 第 23 篇

Day 23|ACL 與 ReBAC:清單式與關係型授權

  • 分享至 

  • xImage
  •  

前言

前兩篇分別介紹了 RBAC(用角色管理權限)與 ABAC(用屬性動態判斷權限),兩者都是從「人」出發來思考權限。今天要介紹的兩種模型,則是從另外兩個角度出發:ACL(Access Control List,存取控制清單) 從「資源」出發,直接在每個資源上記錄誰能做什麼;ReBAC(Relationship-Based Access Control,關係型存取控制) 則從「關係」出發,依據 Subject 與 Resource 之間的關係來決定權限。

ACL 歷史悠久,ReBAC 則相對較新。前者適合直接、逐件設定資源權限,後者則更適合處理資料夾、團隊、共享這類層次化、關係密集的授權需求。

今天內容涵蓋:

  1. ACL:以資源為中心的存取清單
  2. ACL vs RBAC
  3. ReBAC 如何用關係判斷權限
  4. ReBAC 的核心概念與權限推導
  5. RBAC vs ReBAC
  6. ReBAC 的挑戰

一、ACL:以資源為中心的存取清單

ACL(Access Control List,存取控制清單)是一份附加在資源上的權限清單,用來記錄哪些 Subject 可以對這個資源執行哪些操作。每一筆記錄稱為 Access Control Entry(ACE),通常包含使用者或群組,以及允許或拒絕的操作。

例如,一個檔案的 ACL 寫著 (Gloria: read, write; Joanne: read),就代表 Gloria 可以讀寫這個檔案,Joanne 只能讀取。它與 RBAC 最大的差異在於:權限直接記錄在資源上,而不是先透過 Role 統一分配。

ACL 早在 1965 年便出現在 Multics 檔案系統中。直到今天,檔案系統、雲端儲存與網路設備仍廣泛使用相同概念。

常見實作

系統/服務 ACL 類型 主要用途
Unix、Linux、macOS、Solaris POSIX ACL 設定使用者與群組對檔案的讀取、寫入與執行權限
macOS、Solaris ZFS、FreeBSD NFSv4 ACL 提供比 POSIX ACL 更細緻的檔案權限設定
Windows、Active Directory DACL/SACL 分別控制資源存取與記錄存取事件
路由器、交換器 Network ACL 依 IP、Port 等條件控制進出流量

其中兩個常見案例是:

  • AWS S3 ACL: 每個 Bucket 與 Object 都可以設定自己的 ACL,指定哪些 AWS Account 或預定義群組能夠讀取或寫入。AWS 目前建議大多數情境改用 Bucket Policy 統一管理,只在需要逐一控制資源時使用 ACL。
  • Windows ACL: Security Descriptor 中的 DACL 決定誰可以存取資源,SACL 則記錄指定的存取事件,用於安全稽核。

二、ACL vs RBAC

ACL 與 RBAC 都是在回答「誰可以做什麼」,主要差別在於權限如何管理:ACL 將權限直接記錄在每個資源上;RBAC 則先將權限整理成 Role,再把 Role 指派給 User。兩者能處理的情境可能重疊,但適合的管理方式與規模不同。

比較項目 ACL RBAC
存取控制依據 資源本身的權限清單 使用者被指派的 Role
管理單位 逐個資源設定 逐個角色設定
優點 精細,可逐件控制 易於管理大量使用者
缺點 難以擴展(Hard to scale),資源多時維護成本高 細粒度不足時容易 Role Explosion
適合情境 資源數量有限、需要逐件自訂權限(如檔案共享) 使用者量大、職務結構清楚

Granular control(精細控制) 是 ACL 的強項,但 Hard to scale(難以擴展) 也是它最常被批評的地方。當系統有數百萬個檔案,而且每個檔案都有自己的權限清單時,維護成本會非常高。這也是接下來 ReBAC 想要改善的問題。


三、ReBAC 如何用關係判斷權限

ReBAC(Relationship-Based Access Control,關係型存取控制) 是一種授權(Authorization)模式。它不只檢查 User 擁有什麼 Role 或屬性,而是改問:這個 User 與目標資源之間存在什麼關係?

例如,Gloria 想編輯「人事資料夾」中的薪資文件,系統可以依照下列關係判斷:

  1. Gloria 是 HR Team 的 Member。
  2. HR Team 是人事資料夾的 Editor。
  3. 薪資文件位於人事資料夾內。
  4. Policy 規定:資料夾的 Editor 可以編輯其中的文件。

因此,Gloria 不必直接出現在薪資文件的權限清單中。系統只要沿著「Gloria → HR Team → 人事資料夾 → 薪資文件」這條關係,就能推導出 Gloria 可以編輯該文件。

ReBAC 會把 User、Team 與 Resource 視為節點,再以 Member、Editor、Parent 等關係將它們連接起來。系統收到請求時,會檢查是否存在符合 Policy 的關係路徑;找不到符合條件的路徑,就拒絕存取。

ReBAC 一詞於 2006 年提出;2019 年 Google 發表 Zanzibar 論文後,這種模型開始被廣泛用於文件共享、團隊協作與多租戶系統。

💡Relationship 只負責記錄關係,例如「HR Team 是人事資料夾的 Editor」。至於 Editor 可以讀取、修改或刪除哪些文件,則由 Policy 另外規定。


四、ReBAC 的核心概念與權限推導

ReBAC 主要由三個概念組成:

  • Subject: 提出存取請求的使用者、群組或服務,例如 Gloria 或 Joanne。
  • Object: 被存取的資源,例如 Folder、File 或 Repository。
  • Relationship: Subject 與 Object 之間的關係,例如 Owner、Viewer、Member 或 Parent。

最常見的 ReBAC 情境,就是像 Google Drive 一樣具有多層資料夾的共享檔案系統。

https://ithelp.ithome.com.tw/upload/images/20260915/20181928cOak6QOvLu.png

圖中包含兩種關係:

  • 直接關係: Gloria 與 Gloria's Files 之間明確記錄了 Owner 關係。
  • 間接關係: Photos、Documents 及其中的檔案,透過 Parent-Child(父子)關係與 Gloria's Files 相連。

如果 Policy 規定「資料夾的 Owner 可以管理其下所有內容」,系統便能沿著資料夾階層推導出:Gloria 不只可以管理 Gloria's Files,也可以管理 1.jpg、2.jpg、CV.pdf 與 Data.xml。她不需要在每一個檔案上分別設定 ACL。

這些關係通常會以 Relationship Tuple(關係元組) 記錄。以下再加入 Joanne 作為 Documents 的 Viewer:

[
  { "subject": "user:gloria", "relation": "owner", "object": "folder:glorias-files" },
  { "subject": "user:joanne", "relation": "viewer", "object": "folder:documents" },
  { "subject": "folder:glorias-files", "relation": "parent", "object": "folder:documents" },
  { "subject": "folder:documents", "relation": "parent", "object": "file:cv.pdf" }
]

依照相同的繼承規則,Joanne 可以檢視 Documents 及其中的 CV.pdf、Data.xml,但不能存取 Photos 裡的圖片。這就是 ReBAC 的核心:先記錄人與資源之間的關係,再由 Policy 沿著關係推導權限。


五、RBAC vs ReBAC

比較方式 RBAC ReBAC
主要判斷 Gloria 擁有什麼 Role? Gloria 與這個資源有什麼關係?
判斷範例 Gloria 是 Editor,因此可以使用編輯功能 Gloria 是資料夾的 Owner,因此可以管理其中的檔案
權限範圍 通常控制一類功能或資源 通常控制某個特定檔案、資料夾或專案
適合情境 職務與權限相對固定的系統 文件共享、團隊協作與多層資料夾
調整方式 指派或移除 Role 新增或移除 Owner、Viewer、Member 等關係

RBAC 和 ReBAC 不需要二選一。以文件系統為例,可以分成兩次判斷:

  1. RBAC: 先檢查 Gloria 是否擁有 Editor Role,決定她能不能使用系統的編輯功能。
  2. ReBAC: 再檢查 Gloria 是否為這份文件的 Owner 或 Editor,決定她能不能編輯這一份文件。

因此,RBAC 可以先管「能不能使用這類功能」,ReBAC 再管「能不能存取這個特定資源」。如果還要限制存取時間或公司網路,才另外加入 ABAC。


六、ReBAC 的挑戰

ReBAC 的主要挑戰可以整理成三點:

  • 查詢效能: 權限可能需要沿著多層關係判斷,關係越深,查詢速度越容易受到影響。
  • 設計與追查: 關係模型若設計得太複雜,日後會很難確認某位使用者為什麼擁有權限。
  • 資料一致性: 使用者與資源的關係若沒有即時更新,可能出現權限已被移除,系統卻仍允許存取的情況。

也就是說,ReBAC 適合處理複雜共享關係,但需要特別注意模型設計與查詢成本。


小結

本篇的重點可以整理為:

  • ACL 將權限直接記錄在每個資源上,適合逐件控制,但資源越多越難維護。
  • ReBAC 先記錄 User、Team 與 Resource 之間的關係,再由 Policy 推導權限,適合文件共享、團隊協作與資料夾階層。
  • RBAC 與 ReBAC 可以搭配使用: RBAC 決定使用者能否使用某類功能,ReBAC 再判斷其能否存取某個特定資源。
  • ReBAC 雖然彈性較高,但仍要注意查詢效能、關係模型設計與資料是否即時同步。

下一篇將進入 Microsoft 的身分驗證平台,介紹 Azure AD B2C 與 Entra External ID 的關係,以及 Microsoft 外部使用者登入架構的演進。


參考資源


上一篇
Day 22|ABAC:屬性型存取控制
系列文
從登入到授權-現代軟體的身分架構指南 共 23 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言