写在前面：最近在整理工作中的文档，梳理了之前踩的一些坑，觉得有必要把RBAC模型这部分的内容梳理出来，参考了很多前辈的分享，加上了自己的理解成文，在此致谢。

B端产品为了满足用户之间更高效率的工作协作和管理，不可避免的都要引入权限管理，权限管理系统作为B端产品的核心模块之一，贯穿整个产品的生命周期，从简单的只有admin的系统到能够覆盖几万人十几万人的大型系统，处处都可见权限管理的踪迹。

在传统的权限模型中，将权限直接分配给用户，适用于用户和角色非常少的产品。但是当产品一旦迭代到一定的规模，一旦用户数量上升，其中管理维护的成本非常的高，用户的权限有任何变更都需要单独修改每个用户的权限内容。以此而诞生了RBAC的权限管理模型。

RBAC模型的核心思想就是为权限体系赋予了角色（Role）概念，用户直接与角色进行关联，同一个角色下的用户共享同一套权限体系。RBAC的核心为用户、角色、权限三位一体。

权限

权限是用户能够在系统里能使用的资源范围和程度，这里的资源范围和程度根据不同的性质可分为页面、模块、操作、按钮、菜单、文件、功能、字段等元素类型，具体如何组合与细分根据实际业务的需要确定即可。一旦引入了权限体系，在新增功能时，对权限的定义工作需要在功能开发之前就完成，在开发之前需要明确功能点的权限类型和性质，避免在开发之后的返工。

用户

用户之间是独立存在的，每个用户可以被赋予不同的角色。但是当用户量非常大时，我们需要逐一对用户进行授权，十分的繁琐，所以此处我们可以引入用户组的概念，每个用户组内有多个属性相同的用户，我们可以把角色赋权给用户组，用户组内的用户享有这个用户组的全部权限。常见的用户组的描述有：部门、团队、项目组等。用户组与用户、角色之间也存在多对多的映射关系。

角色

角色是每个权限的合集，在定义角色之前我们需要定义角色的权限边界，即这个角色需要包含哪些权限，然后将多个具体权限赋予角色，再将角色赋予用户/用户组。一个用户可以拥有多个角色，一个角色可以包含多个权限。这样对于赋权的工作就会变得灵活很多，在实际的工作中，每个用户的角色都是不唯一的。

如图：A是行政人员，但是在实际中行政需要帮助B兼顾一部分人事工作，这时候我们就需要把行政和人事的权限赋予小A，这样一来就能够满足实际业务环境。

随着产品迭代的日益庞大，角色日益增多的情况，为了方便管理，我们可逐渐引入角色组，角色组对角色进行分类管理，跟用户组不同，角色组不参与授权，仅限于对角色进行管理。

上文讲述了RBAC模型的基本思想即RBAC0模型，在此基础之上又有三种衍生模型，更加具有实用性：RBAC1、RBAC2、RBAC3。

RBAC1模型

在RBAC0基础之上增加了子角色的概念，引入了继承的概念，在RBAC1模型中子角色可以继承父角色的所有权限。在一个机构中不同的职务或角色不但具有不同的的权限，并且这些权限之间存在包含关系，职务越高，权限越高。RBAC1

中高级别的角色包含低级别角色的权限。利用角色等级的概念，可以实现多级安全中的访问控制。RBAC1

中的权限大小是线性排列的，如总监>主管>经理>专员这样的权限结构。

RBAC2模型

RBAC2模型是在RBAC0模型增加限制后形成的，它与RBAC1并不兼容。RBAC2主要在RBAC0模型的基础之上增加了角色的约束条件：

1、互斥约束

当系统中存在两个互斥的角色时，用户只能关联其中的一个角色。比如角色A的文件需要角色B的人员审批，那么在设置角色时一定不会让某一个人担任角色A又担任角色B，这势必会导致欺诈的发生

2、附加数量约束

系统中某个角色存在数量限制，超过数量便无法将用户与该角色关联。如公司的财务岗位只允许有3个人，这样管理员在设置财务人员时就会被限制。

3、前提约束

即用户想要获得更高一级的角色，必须先拥有低一级的角色权限。要获得A角色的权限，必须要获得B角色的权限

RBAC3模型

RBAC3又被称为统一模型，它结合了RBAC1和RBAC2的角色等级和约束条件的特点，具体内容不再赘述，但是在某些情形下实际业务与模型会存在冲突的情况，这时候就需要我们自己根据系统的实际需求制定合理安全的策略了。

此次介绍了目前应用最广泛的RBAC权限模型，尽管有几种类型，但是核心思想还是通过引入角色的概念将用户与权限解耦，权限管理作为B端产品最常见的坑，理解RBAC模型的核心思想能够让我们洞察业务中权限管理的本质，从而制定出最佳的产品策略。

微信公众号：李李先森的康，本号全部文章非本人授权，禁止转载