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 允許讀取存取
  • subject: 使用者角色為 doctor, nurse, admin
  • resource: 資源名稱為 patient-record
  • action: read
  • effect: allow
  • rationale: "允許所有角色讀取病歷"
• 政策 2: 為醫生和管理者提供編輯存取權
  • subject: 使用者角色為 doctor, admin
  • resource: 資源名稱為 patient-record
  • action: write
  • effect: allow
  • rationale: "允許醫生和管理者寫入病歷"
• 政策 3: 刪除存取權給管理者
  • subject: 使用者角色為 admin
  • resource: 資源名稱為 patient-record
  • action: delete
  • effect: allow
  • rationale: "允許管理員刪除病歷"

對於每個讀/寫/刪除請求，政策引擎根據屬性評估所有相關政策並做出存取控制決策。

比較#

在這種情況下，存取控制政策是簡單且結構良好的。只需要進行單一層的權限檢查來確定使用者是否有權存取資源。想像一下，這個醫院系統有一個更複雜的結構，擁有多個部門、角色和權限：

• 在 RBAC 模型中，病歷資源的存取控制評估過程仍將保持簡單，無論使用者是否擁有 read, write 或 delete 權限；
• 而 ABAC 模型則需要考慮更多額外的屬性，如 department-id 和 doctor-id。如果一個物聯網設備需要存取患者記錄呢？那將需要在政策評估中引入新的屬性 device-id。如何暫時授予實習醫生讀取權限呢？

總之，RBAC 是更適合的選擇。在擁有明確定義的權限結構且存取控制政策靜態的系統中，RBAC 簡單且高效。

案例 2#

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

存取控制政策為：

1. 醫生可以讀取和寫入病歷。
2. 護士可以讀取病歷。
3. 管理員可以讀取、寫入和刪除病歷。
4. 患者可以讀取他們自己的病歷。

RBAC 模型#

在這種情況下，除了舊的 read 權限，我們還需要引入一個新權限 read-own。我們可以為醫生、護士、管理員和患者定義角色，並為每個角色指派相應的權限。

現在針對讀取病歷的操作，存取控制評估稍微更為複雜：

• 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: 允許存取所有病歷
  • subject: 使用者角色為 doctor, nurse, admin
  • resource: 資源名稱為 patient-record
  • action: read
  • effect: allow
  • rationale: "允許所有工作人員和患者本人讀取病歷"
• 政策 2: 允許醫生和管理者對所有病歷具有寫入存取權
  • subject: 使用者角色為 doctor, admin
  • resource: 資源名稱為 patient-record
  • action: write
  • effect: allow
  • rationale: "允許醫生和管理者寫入病歷"
• 政策 3: 允許管理員刪除所有病歷
  • subject: 使用者角色為 admin
  • resource: 資源名稱為 patient-record
  • action: delete
  • effect: allow
  • rationale: "允許管理者刪除病歷"
• 政策 4: 允許患者存取自己的病歷
  • subject: 使用者角色為 patient
  • resource: 資源名稱為 patient-record
  • action: read
  • condition: user.id === resource.patient-id
  • effect: allow
  • rationale: "允許患者讀取自己的病歷"

比較#

在這種情況下，存取控制政策更加複雜且上下文感知。病歷資源的存取控制評估過程將需要多層權限檢查以確定使用者是否有權存取資源。

• 在 RBAC 模型中，病歷資源的存取控制評估過程將需要多層權限檢查以確定使用者是否有權存取資源。例如，要確定患者是否可以存取自己的病歷，系統需要檢查使用者是否有 read-own 權限以及使用者 ID 是否與患者 ID 匹配。
• 在 ABAC 模型中，存取控制評估過程可以更為直接。政策可以基於使用者、資源和行動的屬性來定義。例如，要確定患者是否可以存取自己的病歷，政策引擎可以基於使用者 ID 和患者 ID 評估政策。

在這種情況下，ABAC 可能更為合適。ABAC 更適合存取控制政策需要動態、上下文感知及細粒度的系統。

結論#

選擇使用 RBAC 還是 ABAC 取決於系統的具體需求。RBAC 最適合擁有明確定義的權限結構且存取控制政策靜態的系統。ABAC 更適合需要動態、上下文感知及細粒度的存取控制的系統。在實際應用中，組織可以選擇使用兩者的結合來達到期望的存取控制等級。