什麼是 RBAC,什麼時候應該使用它?

什麼是 RBAC,什麼時候應該使用它?

基於角色的訪問控制 (RBAC) 描述了一種系統安全方法,其中為用戶分配了一個或多個不同的角色。分配的角色決定了用戶可用的應用程序功能。

RBAC 是一種實施用戶訪問限制的流行方式,因為它允許您授予與每個人的職責相匹配的細粒度權限。許多系統要求某些用戶可以創建數據,其他用戶可以查看數據,並且管理員具有不受限制的訪問權限。RBAC 可以滿足所有這些要求。

什麼是 RBAC 角色?

RABC 角色是一組權限。權限是用戶可以在您的系統上執行的獨特操作。它們可以根據您的需要具體化。您的代碼庫應該通過權限檢查來阻止安全端點。

角色組合了權限,以便更輕鬆地將它們分配給用戶。以下是角色和權限之間區別的簡短示例:

權限

  1. 創建一篇新文章。
  2. 發表一篇文章。
  3. 刪除文章。

角色

  • 作者:決議 1。
  • 編輯:決議 1 和決議 2。
  • 管理員:所有權利。

用戶

  • 用戶A:作者的角色。
  • 用戶 B:編輯角色。

該模型意味著用戶 A 只能創建文章,而用戶 B 可以創建和發布。

在實際應用程序中,您可能擁有更多權限。將它們直接分配給用戶會很乏味。角色概念巧妙地將精確的權限檢查與用戶職責的明確定義聯繫起來。

大多數 RBAC 實現允許用戶擁有任意數量的角色。必要時角色可以重疊。如果兩個用戶角色中存在相同的權限,他們的帳戶仍然會滿足代碼中的訪問控制檢查。

RBAC 實施

RBAC 在系統中實施可能相對複雜。您需要評估需要多少權限、如何應用這些權限以及如何在用戶之間創建和分配角色。您可能可以從固定數量的角色開始,但許多大型應用程序將允許用戶為特定用例創建自己的角色。

在開始集成 RBAC 之前,最好仔細規劃您的需求。盡可能縮小實施範圍有助於降低複雜性。從應用程序無法運行的最低限度開始,然後逐漸添加更多角色和控件。

RBAC 的另一面是將角色應用於特定資源。例如,可能允許用戶向博客類別提交新文章,但不能向案例類別提交新文章。您的權限檢查現在需要考慮用戶正在與之交互的類別。您可以通過為每個類別動態創建新權限並為其分配可預測的 ID 來控制此流程。

您可以通過使用外部系統來管理身份和授權來簡化權限檢查。支持 RBAC 的基於策略的訪問控制系統,例如Auth0Cerbos,可以幫助您設置複雜的授權邏輯,而無需太多自定義代碼更改。這些平台還可以提供一種更簡單的方法來檢查與資源相關的權限。

對於使用有限數量的角色和權限的小型項目來說,外部系統通常是多餘的。在這些情況下,您可以從多個數據庫表創建 RBAC 實現:一個將權限與角色相關聯,一個將角色與用戶相關聯。要檢查用戶是否可以執行操作,請查看他們的角色並查看是否有任何角色包含所需的權限。

RBAC 的缺點

正確實施時,RBAC 可提供更高的安全性和更靈活的權限。但是,它也有一些缺點,您應該在使用它來保護您的系統之前認識到這些缺點。

其中最重要的可能是基於 RBAC 的應用程序很容易被未使用的角色和重複權限弄得一團糟。僅當角色滿足新要求或反映特定用戶職責時才應創建角色。擁有太多角色將使您的系統更難維護,並降低每個用戶所需的授權的可見性。

定期檢查用戶之間的角色分配也很重要。角色應該是精確的,以便用戶可以獲得他們工作所需的最少角色集。在每個角色中分配太多角色或分配太多權限可能會導致帳戶變得過度特權。如果帳戶被盜,這會增加您的應用程序的風險。

RBAC 還需要事先了解您的系統將如何運行以及職責之間的界限在哪裡。在沒有這種理解的情況下嘗試實施 RBAC 通常是次優的,因為您的權限和角色要么過於寬泛,要么過於精確。您的 RBAC 解決方案的大小和形狀通常應該反映您的內部操作是如何工作的。

概括

基於角色的訪問控制是在軟件應用程序中限制用戶訪問的最常見形式之一。它允許您配置細粒度的權限,然後將其聚合為要分配給用戶的角色。這種方法允許高度的靈活性和自定義,但如果您不主動檢查正在使用的角色,也會導致臃腫。

RBAC 的替代方案包括訪問控制列表,它充當基於條件授予或拒絕訪問的規則,以及基於屬性的訪問控制 (ABAC),它根據請求用戶的屬性保護訪問。當用戶具有多個角色時,ABAC 可以提供更大的靈活性,但是如果您希望您的訪問控制系統準確地代表您的組織結構,RBAC 是最佳選擇。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *