RBAC-基於角色的存取控制權限管理

陳柏仁/

2025-04-19

/
--- views
本文將探討從傳統權限管理過渡到 RBAC 的必要性及其設計與應用

在軟體系統開發中,隨著功能越來越多,如何有效地管理「誰可以做什麼事」成為了一個核心問題。最近在開發使用者管理服務時,接觸到了 RBAC,希望藉由此文章,紀錄一下相關內容,本文將探討從傳統權限管理過渡到 RBAC 的必要性及其設計與應用。

現有痛點:傳統權限管理的瓶頸

在系統初期,我們往往直觀地將「使用者」與「權限」直接綁定。例如,小明可以「編輯文章」,小華可以「刪除留言」。

傳統上,使用者權限劃分綁定在每個使用者 (User) 身上。這種設計在使用者數量少時還能應付。然而,當組織擴張、人員流動變頻繁,或者系統功能變複雜時,就會遇到越來越難以維護的瓶頸,缺點如下:

  • 管理繁瑣:當有新人入職或職位異動時,管理員必須逐一勾選或調整該使用者的每一項細部權限。
  • 容易出錯:若系統有上百個功能點,因為此方式未做分類,漏開或多開權限的風險極高,容易造成資安漏洞。
  • 難以稽核:很難一眼看出「誰擁有系統管理員權限」,必須遍歷所有使用者資料。

RBAC 的核心解方

因此,RBAC 模型引入了一個關鍵的中介層——「角色 (Role)」

RBAC 的核心想法是不再將權限直接授與使用者,而是將權限授與「角色」。使用者透過扮演不同的角色,進而繼承該角色所擁有的所有權限。簡單來說,權限是跟著角色走的,而不是跟著使用者走。

此模式的優勢如下:

  1. 提高便利性 (Efficiency) 當角色與權限的對應關係定義好之後(例如「編輯」角色擁有「新增、修改、發佈」權限),只需將使用者賦予該角色,他便立即享有對應的所有操作權限。大大減少了重複設定的時間成本。
  2. 角色管理分權 (Separation of Duties) RBAC 支援更細緻的管理策略。當管理者新增使用者時,可以限制特定層級的管理者只能分配特定的角色。例如,部門經理只能指派「組員」角色,而不能指派「系統管理員」角色,有效落實權限控管。
  3. 提高安全性 (Security & Compliance)

    • 最小權限原則 (Least Privilege):透過角色定義,我們可以精確控制每個角色僅擁有完成工作所需的最小權限,減少人為錯誤或惡意操作的風險。
    • 易於管理與稽核:當需要調整某個職位的權限時(例如全公司的「會計」都需要新增「匯出報表」功能),只需修改「會計」這個角色的權限設定,所有相關使用者皆會自動生效。

傳統 vs RBAC 關係圖

資料設計 (Database Schema)

在實務的資料庫設計上,RBAC 的設計會有三個主要實體:使用者、角色以及權限,彼此之間會有以下關係:

  • 一個使用者可對應多個角色。(例如: 助教小明同時擁有 「學生」 與 「課程助理」 兩個角色。)
  • 一個角色可對應多個使用者。(例如: 全校數萬名在校生都共同屬於 「學生」 這個角色。)
  • 一個角色可擁有多個權限。(例如: 「教授」 角色擁有「輸入成績」、「審核加簽」與「上傳教材」等多項權限。)
  • 一種權限可被分配給許多個角色。(例如: 「查詢課表」 這個權限,是 「學生」 與 「教授」 都能使用的功能。)

因此,我們通常需要以下五張資料表來實現標準的 RBAC:

  1. Users (使用者表)
  2. Roles (角色表)
  3. Permissions (權限表)
  4. User_Roles (使用者-角色關聯表):紀錄哪個使用者擁有哪些角色。
  5. Role_Permissions (角色-權限關聯表):紀錄哪個角色包含哪些權限。

RBAC ER Diagram

實務應用場景

我以我們公司的 「生產管理系統」 為例,看看如何在真實場景中落地 RBAC。

在工廠的戰情室與產線環境中,我們可以規劃以下幾種標準角色:

1. 系統管理者 (Admin)

  • 職責:負責系統的維運與帳號管理。
  • 權限

    • 擁有系統的全部權限 (ALL_ACCESS)。
    • 可新增/刪除使用者帳號。
    • 可分配使用者角色。

2. 戰情室主管 (Supervisor)

  • 職責:監控生產數據,進行決策分析,但不直接操作機台。
  • 權限

    • 瀏覽資料:查看即時儀表板 (VIEW_DASHBOARD)。
    • 報表功能:匯出歷史生產報表 (EXPORT_REPORT)。
    • 限制:無法修改產線參數或刪除資料。

3. 現場操作工 (Operator)

  • 職責:在產線終端機進行實際作業回報。
  • 權限

    • 操作權限:輸入生產數量、回報良率 (UPDATE_PRODUCTION_DATA)。
    • 設備控制:啟動/暫停工單 (OPERATE_WORK_ORDER)。
    • 限制:無法看到管理層級的戰情總表,亦無法修改歷史數據。

結論

RBAC 透過引入「角色」的概念,成功解耦了使用者與權限之間的複雜度。雖然在系統建置初期需要多設計幾張資料表與關聯邏輯,但對於中大型系統,或是對資安有嚴格要求的應用(如生產管理、金融系統)而言,RBAC 是確保系統可擴充性 (Scalability)安全性 (Security) 的最佳實踐。

透過良好的 RBAC 設計,我們不僅能降低管理成本,更能確保每位員工在適當的權限範圍內高效工作。