原文鏈接：https://www.nocobase.com/cn/blog/how-to-design-rbac-role-base...。
一、為什麼 RBAC 很重要？
在現代企業應用中，控制“誰可以訪問什麼數據、可以做哪些操作”是一項基礎但至關重要的能力。隨着企業組織的擴張，系統功能越來越複雜，涉及的用户角色也越來越多，數據安全、權限管理和合規要求變得愈發嚴苛。這時候，就需要一套清晰、可維護、可擴展的訪問控制體系。
其中，最常見也最實用的一種模型就是 RBAC（Role-Based Access Control，基於角色的訪問控制）。
RBAC 的核心理念是：權限賦予角色，用户通過角色獲取權限。也就是説，我們不直接給每個用户配置權限，而是先定義好“角色”及其權限，再將用户分配到相應角色。
這種設計方式非常適合企業中多角色、多權限、多系統協作的場景。
💡 閲讀更多：如何構建高效的 CRUD 應用程序？
二、RBAC 的核心概念
RBAC 模型的本質，其實就是回答一個問題：
誰（User）可以對什麼（Resource）做什麼（Permission）？
為了實現這一點，RBAC 將權限控制抽象為以下四個關鍵元素：
1. 用户（User）
使用系統的人。可以是公司員工、外部合作方、系統賬號等。每個用户可以擁有一個或多個角色。
2. 角色（Role）
角色代表一種身份或職責，比如銷售人員（Sales）、銷售經理（Manager）、管理員（Admin）等。角色不是用户本人，而是某種“權限集合”的抽象。
例如，一個銷售經理可能擁有：
- 查看所有客户信息的權限
- 修改銷售狀態的權限
- 分配線索給其他銷售的權限
而普通銷售只擁有：
- 查看自己客户的權限
- 添加跟進記錄的權限
3. 權限（Permission）
權限定義了“對資源可以執行什麼操作”，常見操作包括：
- 查看（Read）
- 創建（Create）
- 編輯（Edit / Update）
- 刪除（Delete）
- 審批、導出、打印等系統自定義操作
4. 資源（Resource）
被控制訪問的對象，比如：
- 客户表
- 合同表
- 財務數據報表
- 文件、記錄、頁面模塊等
每個權限都必須綁定在某個具體資源上才有意義。
一個經典的 RBAC 權限結構如下：
| 用户 | 角色 | 權限 | 資源 |
|---|---|---|---|
| Alice | Sales | 查看、創建 | 客户信息表 |
| Bob | Manager | 查看、編輯、審批 | 客户信息表 |
| Charlie | HR Admin | 查看、編輯 | 員工檔案表 |
| David | Finance Team | 查看、導出 | 財務報表 |
通過這樣的結構，RBAC 將權限與具體用户解耦，只需維護好角色與權限的關係，就可以實現清晰、可控、易維護的訪問控制體系。
三、RBAC 的常見設計模式
雖然 RBAC 的概念本身很清晰，但在實際系統中，權限設計往往容易混亂，甚至成為後期維護成本最高的部分之一。
為了避免後期混亂，建議遵循以下 4 個步驟，構建出一套既清晰又可擴展的 RBAC 體系。
1. 定義角色
角色是權限系統的核心。一個角色代表一組具有相同職責或操作權限的用户。
常見的角色定義方法：
- 基於組織結構劃分（如銷售部、財務部、HR）
- 基於工作職責劃分（如數據錄入員、審核員、管理員）
示例角色：
- 銷售人員
- 團隊負責人
- 人力資源負責人
- 財務人員
- 系統管理員
建議：
保持角色數量精簡，避免一人一角色。每一個角色都應該可以解釋為“XX 類用户的一般權限”。
2. 定義資源和操作
接下來要明確，系統中有哪些資源需要控制訪問，每個資源支持哪些操作。
資源示例：
- 客户數據
- 合同管理
- 審批流程
- 財務報表
操作示例：
- 查看（Read）
- 創建（Create）
- 編輯（Edit）
- 刪除（Delete）
- 審批（Approve）
- 導出（Export）
資源和操作的定義，構成了權限規則的“橫軸”。
3. 將權限映射到角色
在資源和角色都定義清楚之後，就可以建立角色與權限之間的映射關係。
核心要點：
- 某角色能訪問哪些資源？
- 對這些資源可以執行哪些操作？
- 是否支持“多角色疊加”？（一個用户同時擁有多個角色）
- 是否支持“角色繼承”？（例如高級銷售角色繼承普通銷售角色的權限）
示例：
- 銷售人員：可查看和創建自己的客户
- 團隊負責人：可查看所有客户，並進行分配和審批
- 系統管理員：可操作所有資源，無限制權限
這個階段的輸出，通常是一張“角色-資源-操作”的權限矩陣表，方便配置和審計。
示例：
| 角色 / 資源 | 客户數據 | 合同管理 | 審批流程 | 財務報表 |
|---|---|---|---|---|
| 銷售人員 | 查看（僅自己） / 創建 / 編輯（僅自己） | 查看（僅自己） / 創建 / 編輯（僅自己） | 無權限 | 無權限 |
| 團隊負責人 | 查看（所有） / 創建 / 編輯（所有）/ 導出 | 查看 / 編輯 | 提交審批 | 無權限 |
| 人力資源負責人 | 無權限 | 無權限 | 審批人角色 | 查看 / 編輯（員工數據） |
| 財務人員 | 無權限 | 查看 | 無權限 | 查看 / 導出 |
| 系統管理員 | 全權限 | 全權限 | 全權限 | 全權限 |
4. 實現字段級權限或條件權限
基礎 RBAC 模型通常只能控制“是否可以訪問某個資源”，但在實際項目中，常常需要更細粒度的權限控制，比如：
✅ 字段級權限
- HR 可以查看所有員工信息，但只有自己部門的員工可以修改薪資字段
- 財務人員只能導出發票號字段，不能查看內部備註字段
✅ 條件權限
- 銷售人員只能查看和編輯自己創建的客户記錄
- 審批流程中，只有狀態為“待審批”的記錄才能被編輯
這些細粒度的控制能力，往往是判斷一款工具是否真正專業支持 RBAC 的重要標準。
四、如何在實際項目中實現 RBAC：以 NocoBase 為例
假設你正在構建一個 CRM 系統，需要為不同的團隊成員分配合適的數據訪問和操作權限。以下是一個典型的 RBAC 實施流程，我們將基於 NocoBase 的 CRM 系統來一步步演示如何落地權限配置。
1. 確定誰在用系統？
首先，在 NocoBase 的「用户和權限」模塊中，我們集中管理所有用户，並建立清晰的組織結構。例如，銷售團隊被劃分到 Sales 部門，支持後續基於部門實現數據隔離或審批路徑設定。
2. 用户在系統中的職責是什麼？
接着，在「角色和權限」中為每類用户設置角色。例如：
- Sales：普通銷售，處理自己負責的客户
- Sales Manager：管理整個銷售團隊，有查看與審批權限
- Admin：系統維護者，擁有所有權限
每個角色都可以綁定用户，也可以多人共用。
3. 他們可以操作哪些數據？
基於不同角色，設置其對數據集合（如客户、線索、商機）的訪問和操作權限。你可以定義他們能否添加、查看、編輯、刪除、導入、導出，並限定數據範圍，如“只能查看自己創建的客户”。
4. 他們能看到哪些模塊？
並不是所有人都需要訪問 CRM 的所有模塊。你可以控制每個角色在桌面端和移動端能看到哪些頁面模塊。例如，銷售只看到客户管理與跟進記錄，而銷售經理可以訪問數據儀表盤和審批中心。
5. 讓權限隨組織結構生效
有了角色和部門的配合，你可以進一步通過條件權限控制更精細的訪問規則，比如：
- 只能查看本部門的數據；
- 只能審批自己下屬的線索；
- 審批通過後，記錄自動歸屬上級負責人。
通過以上 5 個步驟，你就可以在 NocoBase 中快速實現一套適用於實際業務的 RBAC 權限體系。從用户身份 → 頁面入口 → 數據操作 → 動態權限控制，每一步都可視化配置，無需寫代碼，適用於從簡單場景到複雜業務流程的構建。
總結
在現代業務系統中，RBAC 是確保數據安全、有序協作和權限清晰的基本機制。
一個好的權限系統應具備：
- 清晰的結構：誰能訪問什麼、能做什麼，一目瞭然；
- 靈活的配置能力：適應組織結構與業務變化；
- 易於維護：非開發人員也能參與配置與管理。
通過合適的工具，權限不再依賴硬編碼，而可以被清晰建模、集中管理、持續演進。這不僅提升了系統安全性，也讓協作更順暢、開發更高效。
📌 如果你希望更直觀地理解 RBAC 的實際應用，我們已經在 NocoBase 的 CRM 示例系統中預設了一整套權限配置。
你可以直接體驗角色定義、數據權限、頁面控制和條件規則的實際效果。
👉 點擊這裏，立即體驗 NocoBase 的權限系統配置
相關閲讀：
- 2025 年 6 個最佳開源工單系統推薦
- 8 大最佳開源工具助力 Web 應用開發
- 2025年企業必備的 6 款員工管理工具推薦
- 2025年5個最佳 All-in-One 一體化商業軟件
- 2025年8款頂級的開源IT資產管理軟件
- 國內外十大開源快速開發平台推薦
