





一文读懂用户权限设计

硬核刘大

2024-03-11

3081

【建站扶持计划】

免订阅费，免费SEO与代建站，16大主流媒体免费开户

立即查看>>

导读：我们应根据公司的实际需要，设计最适合的用户权限体系，不应过分的追求功能的大而全，最适合的才是最好的。

一文读懂用户权限设计

为什么要进行用户权限设计？

用户权限设计的目的是对不同的人访问资源进行权限的控制，避免因权限控制缺失或操作不当引发的风险问题，如操作错误，隐私数据泄露等问题。

在B端系统中，不同角色的用户对于系统功能和数据的需求是不同的，因此需要对用户进行分类，并为每个分类分配相应的角色和权限。

这里我们以OA系统为例，系统提供了100多个菜单页面，但是有多种不同身份的使用者，这时，我们就需要对不同的员工，相同部门级别不同的员工分配权限，这就要求我们必须在后台系统中引入用户权限设计。

例如：

HR和行政人员可以看到【员工信息页面】，但HR的页面有【入职】按钮，而行政却没有；

再比如：

财务部有2名员工，员工A负责研发部的财务预算支出，员工B负责销售部的预算支出，虽然他们俩都能访问【预算支出页面】，但却只能看到自己管辖的部门的，不能看到其他人的。而财务总监，可以看到全公司的预算数据。

系统权限

在讲完了为什么需要进行用户权限设计之后，我们再来讲下常见的权限。

1. 菜单权限

菜单权限是指用户登录系统后可以访问的菜单项，我们可以将菜单授权给用户，拥有该授权的用户则可以使用该菜单下相关功能。菜单权限相较于其他权限而言，是最基础的权限，其他权限基于菜单权限展开拓展。

常见的功能菜单以一级菜单 → 二级菜单 → 三级菜单依次排列，勾选上对应的菜单，即拥有该菜单的访问权限。

2. 按钮权限

按钮权限一般也可理解为操作权限，是指用户登录系统后可以进行的操作，例如查看、编辑、删除等。我们一般将操作权限赋予到按钮上，当需要给某类用户某种特定的按钮权限时，将按钮权限赋予用户，那么用户即拥有操作权限。例如销售部门可以查看、编辑客户信息、订单信息，而运营部门只能查看。

以下是我们公司的一些常见的按钮权限的配置样式，我们一般喜欢将按钮权限配置在某个菜单之下，当勾选中该按钮时，则表示对应的角色有该按钮权限。

3. 数据权限

数据展示权限是指用户登录系统后可以查看的数据范围，即能查看多少数据，什么类型的数据。例如，管理员能查看所有坐席人员的质检记录，而坐席人员只能查看自己的质检记录。

最常见的数据权限一般是基于“组织架构树”展开的，即可以设置该数据可以给组织结构中的哪些人员可见，或者指定给某个组织可见。

数据权限的设置一般会根据公司规模，事业线的多少做区分，当公司规模比较小，没有复杂的多事业线时，一般采用以下方式，决定用户能看到是本人，还是本部门，还是本公司的数据。

当公司规模较大，且公司下有多个子事业部时，这时可以将数据权限按组织架构进行指定，指定xx事业部下xx部门可进行查看该数据权限。

上述说的2种数据权限，一般更多指的是数据的查看权限，那如果想控制某些部门不仅可以查看，还可以拥有编辑的权限。除了可以通过按钮权限实现以外，还可以将数据权限的增删改权限赋予给某个某部门，那拥有该权限的部门则可进行编辑等权限。

参考以下示例（一般不建议这种数据权限控制）。

那除了对某个页面进行整体的数据权限控制以外，我们还可以针对某一列某一行进行权限控制。例如【员工信息页面】，人事可以身份证号列，而行政却看不到。

4. 应用权限

应用权限是功能组的衍生，可以把应用权限理解功能模块的集合，一般更多的用于saas产品上。例如，我们可以把功能合并一下：包含战略管理、财务管理、人事管理、订单管理几个模块整合成几个大的应用，然后根据企业的需求，直接将该应用的权限分配到用户上。

三、角色

讲完了系统的角色，接下来需要解决用户的问题。系统有很多用户，那如何给每一个用户分配合适的权限？一般有2种方式。

1. 直接分配

直接分配就是直接将权限分配给具体的某一个用户。这种方式就是比较灵活，能最大化的满足每个用户的个性化需求。但这种方式的缺点也比较明显，一旦用户量多起来，这种工作量就很大，不适合于大规模的公司。

举个简单的例子：当公司入职了10名销售部的新员工，需要给他们分配销售专员的角色，那这时如果用直接分配的方式，那么就得重复操作10次，这种方式工作量太大，相信到时候分配权限的员工，肯定会吐槽你。

2. 基于角色RBAC模型进行分配

RBAC（Role-BasedAccess Control）基于角色的访问控制方式：该模型首先定义一些组织内的角色，如局长、科长、职员；再根据管理规定给这些角色分配相应的权限，最后对组织内的每个人根据具体业务和职位分配一个或多个角色。

基于角色RBAC模型的分配方式，就是间接分配方式，这是将用户跟权限之间建立一个集合，然后将用户通过角色与权限进行管理，这就是我们传说的用户角色权限模型。

这种方式就只需要将用户跟角色建立关联，在给用户分配权限时，只需要给用户关联角色即可。当角色权限需要变更时，直接调整角色权限即可，拥有该角色的用户权限也会同步进行动态调整。

RBAC模型可以分为：RBAC0、RBAC1、RBAC2、RBAC3 四种。

RBAC0：最基本模型，它包括用户、角色和权限三个基础组成部分，其中用户和角色之间的关系是多对一的关系，而角色和权限之间的关系是多对多的关系（大部分后台系统都采用了RBAC0这种方式），

多对一：即一个角色被多个用户充当；
多对多：即一个角色可以拥有多种权限。

那么，什么时候该使用多对一的权限体系，什么时候又该使用多对多的权限体系呢？

如果系统功能比较单一，使用人员较少，岗位权限相对清晰且确保不会出现兼岗的情况，此时可以考虑用多对一的权限体系。其余情况尽量使用多对多的权限体系，保证系统的可扩展性。如：张三既是行政，也负责财务工作，那张三就同时拥有行政和财务两个角色的权限。

RBAC1:角色分层模型，RBAC1是在RBAC0的基础上增加了角色分层的概念，引入继承概念，即高层级高的角色可以继承低等级的角色的所有权限。

例如针对销售部门，不同的区域销售经拥有不同的角色，显然全国区经理的权限是不能大于华南区经理的，如果这时候采用RBAC0的方式的话，就有可能出现配置出错的问题，会导致华南区经理拥有了全股区经理都没有的权限。

那如果这时引入RBAC1角色分层，配置好广东区经理的角色外，华南区经理的角色就自动继承了广东区经理的角色，这时候再给华南区经理分配该角色特有的权限就可。

RBAC2：角色限制模型，RBAC2是在RBAC0的基础上增加了对角色的限制，包含基数约束、角色互斥、先决条件、运行互斥等。

基数约束：基数约束是指给一个角色被分配给多少个用户是有上限的，不能无限制的添加，即如果创建了总经理的角色，那这个角色被赋予的用户数是有限的，当超过时，该角色将不能再分配给用户。
角色互斥：角色互斥是指一个用户不可能同时拥有多个互斥的角色，就像财务系统种，一个用户不能同时拥有财务和会计的角色。
先决条件：先决条件是指用户要想获得高层级的权限，必须先拥有低层级的权限，好比如必须先拥有财务助理的权限，才能拥有财务经理的权限。
运行互斥：运行互斥是指使用时只能选择一个角色进行使用，好比如老师和家长，一个用户即可能家长也可能是老师，那在使用时，只能选择使用家长的角色或者时老师的角色，不能2个角色同时使用。

RBAC3:统一模型，基于RBAC0进行设计，同时包含了RBAC1和RBAC2模型的特点。但一般后台系统中，使用RBAC3的情况很少，大部分公司都是采用了RBAC0。

四、用户、角色、权限之间的关系

在讲完了RBAC模型之后，再跟大家分享一下用户、角色、权限以及他们对应的组别。

用户：即系统访问的操作者，可以理解为登录系统的用户；
权限：即被允许访问或某种操作的授权资格，一般可以理解为对系统的增删改查权限；
角色：即具有同类相同操作权限的用户。

例如：用户张三，他在OA系统中被赋予了HR的角色，那他则可以操作【员工入职】的权限。

在某些用户数量或者系统功能复杂的后台系统中，为了方便统一管理，还会引入组的概念，即用户组，权限组，角色组。

用户组：用户的集合。当用户数量较多时，可以给用户进行分组。当公司有新员工入职或者需要给员工分配其他角色时，只需要将用户加入用户组，那么该用户就自动拥有了该用户组的权限，无需再一一设置了。
角色组：角色的集合，当多个角色均需拥有相同的权限时，可以采用角色组，例如行政人员，HR均需看到公司的员工信息，那么此时可以将HR、行政建立一个角色组，再将查看员工信息的权限赋予该用户组，那么用户组内的角色就自动拥有了这些权限。
权限组：权限的集合，可以给权限设置一个权限组，例如可以将查看查看员工业绩、查看客户信息关联成一个权限组，当下次需要给用户赋予权限时，直接选择该权限组即可，就不需要一一去设置多个权限了。