原文链接：如何设计 RBAC（基于角色的访问控制）系统 - NocoBase。
一、为什么 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 示例系统中预设了一整套权限配置。
你可以直接体验角色定义、数据权限、页面控制和条件规则的实际效果。
相关阅读：