如何设计 RBAC（基于角色的访问控制）系统
原文链接：如何设计 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 权限结构如下：
通过这样的结构，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 示例系统中预设了一整套权限配置。
你可以直接体验角色定义、数据权限、页面控制和条件规则的实际效果。
相关阅读：
还未添加个人签名 2018-05-29 加入
极易扩展的开源无代码开发平台
评论