提到权限管理，自然离不开RBAC模型。怎么理解RBAC模型呢？这篇文章里，作者结合自己的思考，探讨了RBAC模型的分类，及RBAC模型之外的数据权限。一起来看看本文的阐述。

最近在设计一套面向票据中介的金融SaaS系统，又是一个从0到1的项目。虽然只是完成了第一期的设计，但是在系统设计的过程中有很多思考，权限管理就是其中重大的一环。权限管理作为系统的根基，就如房子的地基一样，是重中之重。如果地基不稳固，那么房子就可能要拆掉重建，而系统就有可能需要重构或者二次开发，非常浪费时间和精力。在系统设计之初，最好就按照未来公司‘做大做强’的规划进行设计，以保证这块功能的长期可用性。

权限管理，一言蔽之就是‘让不同的系统用户有不同的权限去看和操作’。在C端产品中，就如boss直聘，普通会员和付费会员在app中就会有不同的权限，就如之前写的文章《 BOSS直聘买VIP有用吗？》一样，平台会对普通会员和付费会员设置不同权限，以满足运营需求（只是有些甚是鸡肋，摊手）；

而在面向企业经营的B端产品中，对于公司员工而言，就是让不同的部门和员工有不同的权限，就如运营部门和销售部门的权限是会不同的，而一线销售人员和销售总监的权限又是不同的。

说到权限管理，自然离不开RBAC模型。那么，什么是RBAC模型呢？

一、什么是RBAC模型？

RBAC模型（Role-Based Access Control）就是基于角色的访问控制。它基于“角色”这一核心理念，将用户权限的管理和分配与用户的具体身份解耦合，从而简化权限管理，以便维护和扩展。

简单来说，就是我将系统权限赋予‘角色’，用户再继承角色来获取权限。用类图来表示他们之间的关系的话，如下图：

• 一个用户可以有0到多个角色。
• 一个角色可以分配给0到多个用户。
• 一个角色可以有0到多个权限。
• 一个权限可以分配给0到多个用户。

当今的大部分B端系统的权限管理都会涉及到RBAC模型，只是功能的繁简程度不同而已。

二、RBAC模型的分类

RBAC模型分为RBAC0、RBAC1、RBAC2和RBAC3这四种，其中RBAC0为这四种分类中的基础，其他三类均是RBAC0基础上的变形。

1. RBAC0基本模型

我们先来聊聊RBAC模型中的基础，RBAC0模型。

RBAC0是基于角色的访问控制的完美体现，也就是把权限赋予角色，然后再把角色赋予用户，很多B端系统都是基于RBAC0搭建的权限管理。

从系统设计角度来说，角色管理设计也比较简单，如下图：

只需给对应的角色配置系统中的权限（菜单/操作/字段），完成角色创建后，再将角色赋予系统用户即可。这样在用户登录后，就能获取该用户的所属角色，然后通过角色来找到拥有的权限，再加载对应的权限资源。

完成RBAC0基本模型的搭建，基本就能满足当下绝大部分系统的权限管理的需求。

但是，如果一个部门人员很多，就如我前司，一级部门向下还有二级部门，二级部门向下才是员工，这样就导致如果采用RBAC0模型进行权限管理的话，则很有可能错配权限的问题。

那么，有什么方案解决呢？

有！那就是RBAC1角色分层模型。

2. RBAC1角色分层模型

RBAC1模型相较于RBAC0模型增加了角色继承的概念，有了角色继承就有父子的关系，即子角色可拥有父角色的权限。

从系统设计角度来看，如下图：

在配置角色的时候可以增加父角色的选择，可在父角色的基础上进行删减权限，以避免错配权限的问题。

在RBAC1模型中，我认为主要解决的就是同部门不同层级人员权限配置问题，以达到精准和快速配置权限。

就比如金融本部有一级部门负责人、二级部门负责人、小组长和专员，这样就可以在完成一级部门负责人的权限配置之后，再在一级部门负责人的基础上配置其他角色的权限，以实现其他角色的权限均在一级部门负责人的权限之内。

3. RBAC2角色限制模型

RBAC2模型是RBAC0的另一变种，对用户、角色和权限三者之间增加了一些限制。这些限制可以分成两类，即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。

静态职责分离：

• 互斥角色限制：一个用户不能同时分配互斥角色中的多个角色，即只能选择一个。
• 基数限制：一个用户拥有的角色是有限的。
• 先决条件限制：一个用户想获得更高级的角色，首先需先拥有低级角色。

动态职责分离：

动态限制：一个用户可以拥有两个角色，但是运行时只能激活一个角色。

其实RBAC2模型在我历史经历的系统中基本没有应用到了，静态和动态职责分离的限制条件，我感觉只满足了5%或者更少的应用场景。如果读者有设计过包含此模型的系统，也可和我沟通交流，我倒是想知道谁家这么变态。

4. RBAC3统一模型

RBAC3=RBAC1+RBAC2，既包含了角色分层，也包含了角色限制，不赘述。

三、RBAC模型之外的数据权限

就如文中所说，其实RBAC0基础模型已经满足了绝大部分的应用场景，是应该掌握的，其他三个模型了解即可。在RBAC模型之外，我想再聊聊数据权限。

角色管理系统中的资源，资源包括菜单（页面）权限、操作（按钮）权限和字段权限。那么，数据权限要通过什么进行管理？

没错，就是组织架构。通过角色管理用户在系统中能使用的资源，然后通过组织架构管理用户能看到的数据范围，这样就完整的搭建了SaaS系统的权限管理。

为什么通过组织架构能管理数据权限？

一般大型企业都是全国性质的，就如我的前司，作为中国头部的物流公司，产生的物流单是全国范围的，那么不同区域/不同层级对于数据的管理需求也就顺其自然产生了。

那么通过‘订单+门店’和组织架构就能管理数据权限，订单产生于不同的门店，不同的门店又隶属于不同的组织架构之下，不同的用户再在系统中配置对应的部门，即可实现数据权限。

这里为了数据权限控制的灵活度，在角色管理中还可以设置角色的数据权限范围，如下图：

数据权限可以限制为‘本人/本部门/下级部门/本部门和下级部门/自定义部门/全部’等属性，以控制用户对于不同范围的数据查看权限。

思考

以上就是SaaS系统的管理的全部内容，我认为‘RBAC0模型+数据权限’就可满足系统可见发展范围内的权限管理需求了。

当公司发展到一定程度，内部孵化的项目系统也会越来越多，那么将权限管理抽离，抽象成单独的「统一授权平台」也势在必行。

用统一的权限管理平台进行管理不同系统的权限，这部分的轮子抽象后是可以复用的。读者们也可以思考下要实现这部分的功能，要将系统的哪些模块进行抽离才可实现。

本文由@没汤圆啦 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。