角色權限管理（Role-Based Access Control，簡稱 RBAC）是按職位角色管理系統權限的方法：先設定「銷售」、「會計」或「系統管理員」等角色，決定每個角色可以查看和操作甚麼，再把員工編入角色，而不是逐個人設定權限。有人入職、調職或離職時，只需更改他的角色，不必由零開始重新設定存取權限。
由網站 CMS、ERP 到度身訂造的管理後台，大部分業務軟件都有某種形式的 RBAC。了解它的運作方式，有助規劃新系統，也方便管好現有系統。
RBAC 如何運作：用戶、角色和權限
RBAC 由三部分組成：
- 權限：針對某類資料的某個操作，例如「查看訂單」、「處理退款」、「修改產品價格」或「匯出客戶名單」。
- 角色：一組有名稱的權限，對應實際職位，例如「客戶服務」或「店舖經理」。
- 用戶：員工的實際帳戶。每個用戶獲編入一個或多個角色，並取得這些角色包含的權限。
以下示例僅供說明：在網店管理後台，「客戶服務」角色可以查看訂單和更新送貨備註；「店舖經理」角色另外可以修改價格和批核退款；只有「系統管理員」角色可以開設新帳戶或更改系統設定。新入職的客戶服務同事只要獲編入這個角色，第一天便有合適的權限。
為甚麼 RBAC 對成長中的企業重要
- 最小權限原則：每人只獲得工作所需的權限，帳戶一旦被濫用或密碼被盜，損害範圍也較有限。
- 入職和離職手續更快：分配或移除一個角色，比逐項剔選數十個設定更快，也較少出錯。
- 減少無心之失：員工無法修改或刪除本來不應接觸的資料。
- 檢查更容易：查看「誰擁有會計角色」，比逐個帳戶檢查簡單得多。
RBAC 的常見錯誤
- 人人都是管理員：小團隊常見的捷徑，RBAC 應有的保護大部分因此失效。
- 角色越開越多：每遇到一個例外就開一個新角色，最後沒有人看得懂角色清單。角色數量宜少，並對應真實職位。
- 共用帳戶：幾個人共用同一個登入帳戶，便無法分辨誰做了甚麼。
- 權限只增不減：員工轉到其他部門後，舊權限仍然保留，再加上新權限。
- 遺忘已離職人員和供應商：前員工、合約人員或以往合作的代理商，帳戶仍然可以登入。
- 只在畫面上限制：介面隱藏了按鈕，但背後的伺服器或 API 沒有檢查權限，有人仍可直接觸發該操作。
為新系統規劃角色
如果你正委託開發網站、App 或內部平台，最好在設計畫面之前先議定角色：
- 列出會使用系統的人員和團隊，包括代理、加盟商或供應商等外部人士。
- 列出敏感操作，例如批核付款、處理退款、匯出個人資料、修改價格和刪除記錄。
- 製作一張簡單表格，角色作行、操作作列，標明誰可以做甚麼。
- 決定由誰分配角色，以及敏感操作是否需要第二人批核。
- 要求系統為重要操作和角色變更保留審計記錄。
- 在用戶驗收測試（UAT）期間逐一測試每個角色，包括確認角色無法執行不應做的操作。
RBAC、SSO、MFA 和零信任
這幾個概念互有關連，但處理的問題不同。單一登入（SSO）和多重身份驗證（MFA）處理的是「你是誰」；RBAC 處理的是登入後「你可以做甚麼」。零信任是較廣泛的保安方針，按每項資源評估存取要求，角色通常是其中一項考慮因素。
RBAC 亦有限制。如果規則要視乎分店、記錄負責人或時段等細節，系統往往會在角色之上加入以屬性為基礎的規則；這些規則同樣需要記錄在案。
持續管好角色
- 按風險定期檢視角色分配，有員工調職時亦應即時檢視。
- 員工或供應商離開後，盡快移除其存取權限。
- 系統管理員帳戶宜少，須記名，並以 MFA 保護。
technine.io 在業務系統及雲端平台項目中會一併規劃權限、身份驗證和審計記錄，亦可透過網絡安全及合規服務檢視存取控制。
常見問題
RBAC 只適合大公司嗎？
不是。即使只有五人的團隊，把負責更新網站內容的人和可以更改付款設定的人分開，也有實際好處。小型系統可能只需要三、四個角色。
一個人可以同時擁有多個角色嗎？
大部分系統都可以。用戶的權限通常是所有角色權限的總和，因此要檢查角色組合有否衝突，例如同一人既可建立又可批核同一筆付款。
現有系統可以加入 RBAC 嗎？
很多時可以，但要視乎系統的開發方式。如果系統從未在伺服器端檢查權限，加入 RBAC 可能需要修改應用程式碼和 API，而不只是新增設定。決定方案前，應先由開發人員評估。
應該多久檢視一次存取權限？
沒有劃一規定。不少企業會定期檢視，並在有人入職、調職或離職時再檢查。存有付款資料或個人資料的系統，通常值得更頻密地檢查。