帳號權限管理一定需要的 RBAC 模型｜EP63
帳號權限管理一直是產品系統的重要議題，近期規劃權限功能時發現 RBAC 這套模型，才開始了解為什麼要有 User-Role-Permission 的架構，隨著系統規模的擴大和複雜度的增加，傳統的權限管理模式已經無法滿足需求，而基於角色的訪問控制（Role-Based Access Control，簡稱 RBAC）模型就為系統提供更加靈活的權限管理方式。
一、RBAC 模型的概念
在傳統的權限模型，我們直接將權限賦予用戶（信箱），這種方式在小型系統中可能還能應付，但在大型複雜系統中很快就會變得難以管理，不太可能讓每個信箱都有不同權限，在管理上太麻煩。
因此 RBAC 模型的核心思想是引入「角色」的概念，將權限賦予在角色身上，再將角色綁定在用戶（信箱）。
RBAC 模型的主要元素包括：
- 用戶（User）：系統的使用者。
- 角色（Role）：一組權限的集合，代表了特定的職責或工作功能。
- 權限（Permission）：對特定資源執行特定操作的能力。
⠀⠀
RBAC 模型的工作流程如下：
- 定義角色：系統管理員根據業務需求定義不同的角色，例如提報人員、審核人員。
- 分配權限：為每個角色分配相應的權限，例如提報人員負責上架商品、審核人員可以審商品。
- 用戶分配：將用戶分配到適當的角色，例如 a@gmail 是管理員、b@gmail 是上架人員。
⠀⠀
二、RBAC 模型的優勢和案例
⠀⠀
比對了 RBAC 這種 User-Role-Permission 架構和傳統的 User-Permission 架構，差異是：
- 簡化權限管理：通過角色這個中間層，減少權限分配的控管成本，若要增加操作權限，只要針對指定的「角色」調整，調整後該角色的「用戶」都會一起有這個權限。。
- 提高安全性：可以更精確地控制用戶的權限，降低權限濫用的風險，比較不會出現某些「用戶」的信箱會有非預期的權限。
- 調整靈活性：可以快速調整用戶的權限，只需更改用戶對應的「角色」就能套用。
⠀⠀
以下是常見的 RBAC 案例：
⠀⠀
案例一：倉庫管理系統
在一個大型倉庫管理系統中，可能會有以下角色：
- 最高管理員：擁有系統的所有權限，包含新增成員。
- 倉庫經理：可以查看所有庫存資料，包含上架、出貨、報表。
- 上架人員：僅負責商品的入庫和上架，包含上架商品和修改庫存。
- 出貨人員：僅負責商品的出庫，包含配號、出貨、退貨。
- 財務人員：僅負責下載報表，包含業績報表、庫存報表。
在這個系統中，如果有一個新員工要成為上架人員，我們只需要將他的信箱指定到「上架人員」這個角色，他就會獲得上架人員的所有權限。
若上架人員要新增一個權限，我們只需要針對「上架人員」這個角色增加設定，裡面的所有「用戶」的帳號就會被套用。
若某個用戶要改成管理員，也只需調整該帳號對應的「角色」即可。從上架人員改成管理員。
⠀⠀
案例二：電子商務平台
在電商平台中，可能會有以下角色：
- 平台系統管理員：擁有平台的最高權限。
- 供應商管理員：可以管理自己的商店，上傳商品，處理訂單。
- 客服人員：僅可以查看訂單、處理退款、回覆消費者訊息。
- 財務人員：僅可以查看商店銷售報表。
- 一般消費者：可以購買一般商品。
- VIP 消費者：除了一般商品，還可以購買指定會員的商品。
通過這種角色劃分，平台可以精確控制每種用戶的權限，確保每個人只能訪問與其職責相關的功能。
⠀⠀
⠀⠀
三、RBAC 模型的導入步驟
⠀⠀
要在一個系統中搭出 RBAC 模型，前期需要建立幾個機制：
- 角色分析：仔細蒐集組織業務流程和職責劃分，確定需要哪些角色。
- 權限定義：為每個角色定義所需的具體權限。
- 角色分配：將用戶分配到適當的角色。
⠀⠀
在開發過程，則需要確認：
- 架構設計：包括資料庫設計、頁面權限檢查機制。
- 測試驗證：全面測試系統，確保每個角色只會看到指定權限。
⠀⠀
實務上，以業務場景還需要確認：
- 角色控管：隨著系統複雜度或客戶數增加，難免會不斷增加角色，這時就需要一個大表清楚知道各角色會有什麼權限。
- 客製權限：若 A 和 B 客戶都有相同角色，當 A 客戶提出角色希望增加一個權限，則要考慮會不會影響到 B 客戶。
⠀⠀
⠀⠀
四、結論
⠀⠀
RBAC 模型幾乎是現在大型系統的權限管理方式，從倉庫管理系統、銀行系統、電商系統，都有滿好的適應。
但 RBAC 模型也不是萬能的，實際操作場景可能還需要搭配其他控制模型來滿足複雜的業務需求。
如對這系列文章有興趣可以再觀看：
你可能也想看
