RBAC 和 ABAC：你應該知道的訪問控制模型

簡介#

訪問控制 是任何系統安全中的關鍵方面。它確保只有獲授權的用戶才能訪問資源和執行操作。基於角色的訪問控制 (RBAC) 和基於屬性的訪問控制 (ABAC) 是現代系統中使用的兩種最受歡迎的訪問控制模型。兩種模型都被廣泛採用，可以有效地強制執行訪問控制策略。但它們是什麼以及它們有何不同？

基於角色的訪問控制 (RBAC)#

基於角色的訪問控制 (RBAC) 最早於 1990 年代初期引入。該模型的形式化歸功於 David Ferraiolo 和 Rick Kuhn，他們在 1992 年發表的論文。自此以來，RBAC 已成為行業中最廣泛使用的訪問控制模型之一。

在 RBAC 中，訪問控制策略是基於角色的，角色是權限的集合。用戶被分配角色（例如，管理員、編輯者、查看者），其訪問權限由特定資源（例如，文件、數據庫、應用程式）的權限（例如，創建、編輯、刪除）決定。它通過根據角色對用戶進行分組並為角色分配權限來簡化訪問控制策略的管理。添加或刪除用戶到角色非常簡單，並且更改將自動反映在訪問控制策略中。

RBAC 的關鍵組件#

• 資源：資源是用戶可以訪問的實體。資源可以是從文件、數據庫、API，或任何其他需要保護的系統實體。
• 權限：權限是用戶可以對資源執行的特定操作。例如，創建、編輯、刪除、查看。權限的定義可能會根據系統的不同而有所不同。在大多數情況下，權限是在具有最小粒度的資源級別上定義的。
• 角色：角色是定義用戶可以執行的一組操作的權限集合。例如，管理員角色可能具有創建、編輯和刪除資源的權限，而查看者角色可能具有查看資源的權限。
• 用戶：用戶是可以分配一個或多個角色的實體。用戶基於與他們分配的角色相關聯的權限獲得資源訪問權。

RBAC 的變體#

有幾種 RBAC 變體擴展了基本模型以適應更複雜的訪問控制要求：

• RBAC0：基本模型，用戶被分配角色，角色被分配權限。
• RBAC1：添加了角色層次的概念。角色可以從其他角色繼承權限。這也被稱為分層 RBAC。
• RBAC2：為角色添加了約束。約束可用於定義用戶被分配角色必須滿足的其他條件。這也被稱為基於約束的 RBAC。
• RBAC3：結合 RBAC1 和 RBAC2 的功能。它支持角色層次和約束。

關於這些變體的更多信息，請參考 RBAC 模型及其演變。

RBAC 的優點#

• 簡單：RBAC 易於理解和實施。將權限分配給角色和角色分配給用戶是簡單直接的。
• 效率：通過根據角色分組用戶來簡化訪問控制策略的管理。添加或移除角色中的用戶很容易，無需改變訪問控制策略。特別是在具有明確的權限結構的大型組織中，RBAC 非常高效。
• 透明性：RBAC 提供了角色、權限和用戶之間的明確映射。便於審核和審查訪問控制策略。

RBAC 的缺點#

• 僵化性：RBAC 在定義複雜的訪問控制策略方面可能比較僵化。可能不適合需要更動態和上下文感知的訪問控制策略的系統。
• 粒度：RBAC 可能缺乏細粒度訪問控制所需的粒度。訪問控制策略與明確定義的角色緊密相關，可能需要額外的努力來定義更細粒度的權限。
• 角色爆炸：在具有複雜權限結構的大型組織中，角色的數量可能呈指數級增長，導致角色爆炸。管理大量角色可能具有挑戰性。

基於屬性的訪問控制 (ABAC)#

隨著系統變得更加複雜和動態，2000 年代後期越來越多的組織開始採用基於屬性的訪問控制 (ABAC) 作為 RBAC 的替代方案。ABAC 正式化的一個顯著里程碑是 2014 年發佈的 NIST 特別出版物 800-162。

ABAC 與 RBAC 相比是一種更靈活的訪問控制模型。這是一種基於用戶、資源、操作和環境屬性定義訪問控制策略的授權模型。它允許組織定義能夠適應不同上下文和條件的細粒度訪問控制策略。

ABAC 的關鍵組件#

• 主體：主體是請求訪問資源的實體。可以是用戶、設備、應用程式或需要訪問資源的任何其他實體。
• 資源：如同在 RBAC 中，資源是主體可以訪問的實體。資源可以是文件、數據庫、API 或任何其他系統實體。
• 操作：操作是主體可以對資源進行的特定操作。可以是創建、讀取、更新、刪除或需要控制的任何其他操作。
• 環境：環境是訪問請求發出的上下文。可能包括時間、地點、網絡、設備等屬性。
• 屬性：屬性是主體、資源、操作或環境的特徵。屬性可以是用戶角色、部門、位置、IP 地址、設備類型等。
• 策略：策略是定義授予或拒絕訪問的條件的規則。策略是基於屬性定義的。

ABAC 的優點#

• 靈活性：ABAC 可適應基於多個屬性的複雜訪問控制策略。它允許組織定義能夠適應不同上下文和條件的細粒度策略。
• 動態性：ABAC 策略可以是動態的和上下文感知的。訪問控制決策可以基於實時屬性如位置、時間和設備類型等做出。
• 粒度：通過允許組織基於多個屬性定義策略，ABAC 提供了細粒度的訪問控制。不像定義角色和權限，基於屬性的策略可以更加細緻。

ABAC 的缺點#

• 複雜性：與 RBAC 相比，ABAC 的實施和管理可能更為複雜。定義屬性和策略可能需要更多的工作和專業知識。不同於角色和權限結構良好的 RBAC，屬性可以更具動態性，因此策略也可能是如此。管理複雜系統中的大量屬性和策略可能具挑戰性。通常需要一個集中化的策略評估引擎來評估策略。
• 性能：屬性評估可能影響性能，特別是在實時環境中。基於多個屬性和實時條件的策略可能會在訪問控制決策中引入延遲。

比較表#

從比較表可以清楚地看到，RBAC 最適合那些權限結構定義良好且訪問控制策略相對穩定的系統。而 ABAC 更適合需要動態、上下文感知和細粒度訪問控制的系統。

示例#

情境：一個需要管理不同員工具有不同訪問權限的醫院系統。

• 員工：醫生，護士，管理員
• 資源：病人記錄
• 權限：讀取，寫入，刪除

案例 1#

訪問控制策略相對簡單：

1. 醫生可以讀取和寫入病人記錄。
2. 護士可以讀取病人記錄。
3. 管理員可以讀取、寫入和刪除病人記錄。

RBAC 模型#

在這種情況下，RBAC 簡單且有效。我們可以為醫生、護士和管理員定義角色，並為每個角色分配適當的權限。

訪問控制評估非常簡單：

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')

ABAC 模型#

在這種情況下，ABAC 可能有點過於複雜，但仍可用於根據屬性如部門、角色等定義細粒度政策。

屬性：

• user.role: doctor, nurse, admin
• resource.name: patient-record
• action: read, write, delete

政策：

• 政策 1：根據 user.role 和 resource.name 允許讀取訪問
  • 主體：角色為 doctor, nurse, admin 的用戶
  • 資源：名稱為 patient-record 的資源
  • 操作：read
  • 效力：允許
  • 理由："允許所有角色讀取病人記錄"
• 政策 2：允許醫生和管理員進行編輯訪問
  • 主體：角色為 doctor, admin 的用戶
  • 資源：名稱為 patient-record 的資源
  • 操作：write
  • 效力：允許
  • 理由："允許醫生和管理員對病人記錄進行寫入訪問"
• 政策 3：允許管理員進行刪除訪問
  • 主體：角色為 admin 的用戶
  • 資源：名稱為 patient-record 的資源
  • 操作：delete
  • 效力：允許
  • 理由："允許管理員刪除病人記錄"

每次讀取/寫入/刪除請求，策略引擎會根據屬性評估所有相關策略並做出訪問控制決策。

比較#

在這種情況下，訪問控制策略是簡單和結構良好的。它只需單級权限檢查即可確定用戶是否有權訪問資源。想像一下，醫院系統有一個更複雜的結構，具有多個部門、角色和權限：

• 在 RBAC 模型中，病人記錄資源的訪問控制評估過程仍然簡單直接，無論用戶是否擁有讀取、寫入或刪除权限；
• 另一方面，ABAC 需要涉及額外的屬性，如部門-id和醫生-id。如果物聯網設備需要訪問病人記錄怎麼辦？這將需要在策略評估中引入新的屬性 device-id。如何暫時授予實習醫生讀取權限？

總結而言，RBAC 是更好的選擇。RBAC 對於權限結構定義良好且訪問控制策略是靜態的系統而言既簡單又高效。

案例 2#

同一醫院系統，現在讓我們引入一個新角色 patient 和一個新屬性 patient-id。

訪問控制策略是：

1. 醫生可以讀取和寫入病人記錄。
2. 護士可以讀取病人記錄。
3. 管理員可以讀取、寫入和刪除病人記錄。
4. 病人可以讀取自己的記錄。

RBAC 模型#

在這種情況下，除了舊的讀取權限，我們需要引入一個新的權限讀取自己的。我們可以為醫生、護士、管理員和病人定義角色，並為每個角色分配適當的權限。

現在，訪問控制評估變得更加複雜，特別是在讀取病人記錄的操作中：

• GET /patient-records: user.permission.includes('read')
• POST /patient-records: user.permission.includes('write')
• DELETE /patient-records: user.permission.includes('delete')
• GET /patient-records/:patient-id: user.permission.includes('read-own') && user.id === patient-id || user.permission.includes('read')

ABAC 模型#

現在讓我們更新 ABAC 模型中的屬性和策略以滿足新的要求。

屬性：

• user.role: doctor, nurse, admin, patient
• user.id: patient-id
• resource.name: patient-record
• resource.patient-id: patient-id
• action: read, write, delete

政策：

• 政策 1：允許讀取所有病人記錄
  • 主體：角色為 doctor, nurse, admin 的用戶
  • 資源：名稱為 patient-record 的資源
  • 操作：read
  • 效力：允許
  • 理由："允許所有員工和病人本人讀取病人記錄"
• 政策 2：允許醫生和管理員寫入所有病人記錄
  • 主體：角色為 doctor, admin 的用戶
  • 資源：名稱為 patient-record 的資源
  • 操作：write
  • 效力：允許
  • 理由："允許醫生和管理員寫入病人記錄"
• 政策 3：允許管理員刪除所有病人記錄
  • 主體：角色為 admin 的用戶
  • 資源：名稱為 patient-record 的資源
  • 操作：delete
  • 效力：允許
  • 理由："允許管理員刪除病人記錄"
• 政策 4：允許病人讀取自己的記錄
  • 主體：角色為 patient 的用戶
  • 資源：名稱為 patient-record 的資源
  • 操作：read
  • 條件：user.id === resource.patient-id
  • 效力：允許
  • 理由："允許病人讀取自己的記錄"

比較#

在這種情況下，訪問控制策略更為複雜和上下文感知。病人記錄資源的訪問控制評估過程可能需要多個級別的權限檢查來確定用戶是否對資源擁有訪問權。

• 在 RBAC 模型中，病人記錄資源的訪問控制評估過程需要進行多個級別的權限檢查來確定用戶是否對資源擁有訪問權。例如，要確定病人是否可以訪問他們自己的記錄，系統需要檢查用戶是否具有讀取自己的權限，並且用戶 id 是否與病人 id 相匹配。
• 在 ABAC 模型中，訪問控制評估過程可能比較直接。策略可以基於用戶、資源和操作的屬性定義。例如，要確定病人是否可以訪問他們自己的記錄，策略引擎可以基於用戶 id 和病人 id 評估策略。

在這種情況下，ABAC 可能是更好的選擇。ABAC 對於需要動態、上下文感知和細粒度訪問控制的系統而言更為合適。

結論#

在 RBAC 和 ABAC 之間作出選擇取決於系統的具體要求。RBAC 最適合那些權限結構定義良好且訪問控制策略是靜態的系統。ABAC 更適合需要動態、上下文感知和細粒度訪問控制的系統。實際上，組織可能會選擇結合使用兩種模型來達到理想的訪問控制級別。