后台产品基本功：RBAC权限后台角色与权限设计

Posted 2021-05-01 Kevin改变世界的点滴

后台产品经理在设计系统中，随着业务与用户量起来后。都会考虑系统的角色与权限设计。借此经典的角色 与权限设计：RBAC，基于角色的权限访问控制（Role-Based Access Control）分享近期落地的系统设计案例。

基于这套角色与权限设计会分有：RBAC 0\RBAC 1\RBAC 2这样的角色与权限设计分类。虽然会有1、2、3的系数区分，但还是会围绕基本的理论模型落地，基本上RBAC 0模型就足够使用，只是相对1、2的效率会低一些。

什么是RBAC模型

前面有说过，RBAC模型的全名称。其实核心就是将账号、角色、权限链接起来的设计方式。

基于上诉，我们可以很快的将用户访问B/S结构的后台系统通过不同的账号判断出背后的角色，到底这个角色包含那些权限去访问模块1、资源2.....

在该账户所在的角色下，如果没有该模块的权限，用户将无法使用。相反，即可使用。上诉的流程就保证了用户操作权限。

这也是基于角色与权限的rbac模型。但要提的是操作权限不同外，权限与角色设计还需要考虑数据权限，至于数据权限我们需要定义清楚它到底是什么？

是基于数据库的增删改查？还是数据的拥有权？比如销售管理平台的客户，销售专员的客户是可以被部门销售经理查看的。但其他部门的销售经理是不能查看的。但添加用户的权限是销售专员和销售经理都可以的。

多角色与多用户

上诉解释了RBAC模型后，相信大家对角色的定义是非常清楚的。那多角色对多用户是什么场景？

简单来说，一个用户使用系统要基于一个账号，用户以用账号来登录使用系统。RBAC模型中，正是基于多账户与多角色来建立权限管理。

比如在门店系统中，系统中可能涵盖的角色有多少呢？我们简单举例下

上诉不同的角色就导致了他们在工作中所需要的权限和功能模块是不同的，为此我们角色的映射是需要生活中确实存在的职位或角色，在系统中是可以被创建的。

但也有这样的情况，比如我们的超级管理员、管理员，这样的角色其实是没有实际的职位映射的，为此我们需要给予设置系统中默认的“超级账户”。他们是拥有这样的权限与角色，不需要添加或创建。

数据权限

上面说了RBAC的模型设计后，我们如何考虑数据权限？是否有一个账户可以在超级管理员下，有默认的最大数据权限？

答案是肯定的，针对最高阶的角色，系统应该给予一个默认的全局权限与数据。虽然不同的权限创建了角色，但在系统全局中的超级管理员是不应该被创建的。

试想，除了系统开发者外，谁能创建超级管理员？

为此，站在数据权限顶部的“超级用户”是我们在系统搭建的时候需要给予的默认。其他角色就可用通过配置创建，当然你也可以给予他最高的操作权限。

将所有页面与button，都归属于某一个角色，其实这个角色也是超级管理员。但他的数据权限却不是，数据权限却只会跟着系统默认的超级管理员走。在系统中所创建的角色还是会依照角色创建的数据逻辑。（这个逻辑需要产品经理给予设计）

这个角色归属于那个账户，这个账户有多少数据只有在这个账户中可查。

好，今天的分享就在这里，我会坚持每周更新两篇～

-End-

近期专题

另外我个人发起的第二期《Kevin带新人|产品经理30天训练营》正式上线这本我归纳社区产品、后台产品、产品经理基本功，目前报名限制30人。如果你扫码报名后参加。我会在28号拉你入群，开启训练营。如果你需要参加，请报名前填写一份简单问卷。问卷链接下方

2018年，让我们继续前进！

---