最近在做一个业务管理系统CRM，期间也是激发了不少思考和沉淀。B端系统的底层基础模块之一是权限管理，而RBAC作为目前使用最为广泛的权限模型，我认为有必要单独研究整理一番。本文将从RBAC的定义、RBAC组成、3个安全原则、4种模型和RBAC基础产品功能模块进行介绍。
一、什么是RBAC
RBAC，基于角色的权限访问控制（Role-Based Access Control）。RBAC通过定义角色的权限，并对用户授予某个角色从而来控制用户的权限，实现了用户和权限的逻辑分离。通过对用户设置角色，对角色设置权限范围从而使得不同用户拥有不同角色对应的权限。这样的权限设置十分清楚，也极大地简化了权限的管理，管理起来十分方便。
二、RBAC组成
在RBAC模型里面，有3个基础组成部分，分别是：用户、角色和权限。本质上是用户与角色的映射、角色与权限的映射。
名词解释：
User（用户）：每个用户都有唯一的UID识别，并被授予不同的角色
Role（角色）：不同角色具有不同的权限范围
Permission（权限）：访问权限
用户-角色映射：用户和角色之间的映射关系
角色-权限映射：角色和权限之间的映射
三、RBAC的3个安全原则
RBAC三个安全原则：最小权限原则、责任分离原则和数据抽象原则
最小权限原则：将角色配置成该角色完成某项任务所需要的最小权限集合。比如客服人员，所设置角色拥有的权限仅限于其能够完成客服相关任务的权限范围。
责任分离原则：通过设置相互独立互斥的角色来共同完成敏感的任务。
数据抽象原则：通过权限的抽象来体现数据的抽象。比如财务人员操作借款、存款等抽象权限，而不是使用操作系统提供的读、写、执行等具体的许可权。但RBAC不强制要求这原则，安全管理配置RBAC模型时可以允许不遵循该项原则。因此，支持数据抽象原则的程度与实现细节相关。
四、RBAC的4种模型
（1）RBAC0
最基本的RBAC模型，也是BRAC的核心思想。即用户和角色是多对多的关系。一个用户可有多个角色，对应多种权限。一个用户至少有一个角色。一个角色至少有一个权限。
例子：部门经理可以同时是项目经理和架构师。
（2）RBAC1
在RBAC0的基础上进行了角色分层，一个角色可以从另一个角色继承许可权。
例子：在一个公司销售部门中，分有区域经理、城市经理、销售人员。此时，我们可以运用RBAC1的分级模型，将销售这个角色分为多个等级，赋予不同等级的不同权限。
（3）RBAC2
增加了约束模型，添加了部分限制。强调在RBAC的不同组件中在配置方面的一些限制。一般设置的限制我们有以下种类：
1、互斥角色限制：即字面意思，同一个用户在不同互斥角色中，只能选择其中一个；
2、基数限制：一个用户拥有的角色是有限制的，一个角色拥有的权限也是有限的。
3、前置条件限制：一个用户需要获取更高一级的角色，前提是已经拥有低级角色。
4、动态限制用户与角色：即一个 用户可以拥有多个角色，但账号运营时只能激活使用一个角色。
例子：一个公司的销售经理可以分配其销售经理的角色，但不能再分配合同审核的角色。否则将会出现一种场景为销售经理创建合同，同时又自己审批了合同，这是不允许的。
例子：在销售人员-城市经理-区域经理的晋升路径上，一个公司的销售人员，要晋升为区域经理，首先要先成为城市经理。
（4）RBAC3
我们可以这么理解，RBAC3是基于RBAC0的基础上，RBAC1与RBAC2的集合统一，即RBAC3=RBAC2 + RBAC1，称为统一模型。
五、RBAC基础产品模块
在实际需求的产品功能设计中，涉及的功能很多也很多样，概括出来几个模块一定包括用户管理、角色管理、权限管理三个模块。每个模块也包括增删改查几个部分。业务主流为：
1.创建权限
2.创建角色，并关联权限
3.添加用户，并为用户设置角色
六、后记
文章的内容主要从工作中实际遇到的场景中进行总结概括，更多的是提炼其方法论精髓。后续有机会将结合理论与详实的案例来和大家做更多的分享与交流。
AI-product，产品人的聚集地 回复“区块链”，获取整理好的区块链资料汇总。
回复“思维导图”，获取100本书思维导图。
