【B端产品知识总结】角色权限管理设计思想

前言

一、简单的用户权限

二、基于角色的权限访问模型（RBAC）

三、RBAC模型的其他权限方案

1、用户组权限设计

2、继承角色权限设计

3、基于角色设计的约束

四、权限控制的设计

1.页面权限

2.操作权限

3.业务权限

4.数据权限

五、对于B端系统权限设计补充

1、B端系统中初次权限的赋予

2、B端系统中初次配置用户

3、B端系统禁止删除同级角色

4、商业领域下权限的版本分割

前言

做过了大量B端产品后，就会发现B端产品有很多类似的功能模块，比如系统设置里的用户角色权限和基础信息维护，虽然说B端产品的业务可能不相同、服务的客户群体也不一样，但是对于管理端的用户管理体系是必不可少的。基于B端业务的不同复杂度和相关B端数据的敏感度，产品经理在拿到任何一个B端系统的需求时，就需要了解业务方对权限的需求后第一时间就要考虑基于用户角色的控制访问，以便于后期功能更新迭代不至于再大动干戈的处理系统用户相关的信息。

作为B端产品中的后台管理功能，角色权限管理的设计非常考验产品经理的基本功，这个功能即使做好了不能代表产品能有多优秀，但是一旦没有做好就会导致系统各种流程的错乱和用户数据展示的有问题进而导致产品崩溃，所以产品经理往往对B端产品的系统权限架构设计有着一定的畏惧心理。接下来我们从简到易剖析角色权限，让我们在面对不同业务时，能够更加游刃有余的面对。

一、简单的用户权限

当一个B端系统因为需要用户进行登录，进入系统后会展示B端系统的所有的功能模块和系统数据并且能进行操作，这乍一看好像没有什么问题，但是例如系统的用户管理任何一个用户都可以操作并且对其他用户进行修改，这是不是就不大合理了，所以这也引申出了不同用户需要有不同的用户管理权限。

当一个系统用户数量较少时又有权限的需求，可以在创建用户时直接开放权限管理，管理员在创建该用户就清楚用户可以看到那些页面和操作那些数据，这样就可以做到一个简单的用户用户权限分配

这种方法对研发人员实现起来也是比较容易，对于小型的功能型系统用户数偏少的系统或者权限系统体量小可以采用这种解决方案可以节省一定的开发成本。但是对于中大型系统的用户往往是比较多的，例如一个系统中正常使用用户有100个，我们也可以用创建用户关联权限的这种方式，如果是1000个呢是不是就比较繁琐，而且如果有很多用户需要更改权限是不是也比较麻烦，此时我们可以用一种通用的技术模型来解决这个问题-- RBAC模型。

二、基于角色的权限访问模型（RBAC）

RBAC通常用于配置角色拥有权限（页面权限、操作权限、业务权限、数据权限），实现每一种角色可以对应一组相应的权限，然后角色和用户进行关联。实现原理：创建的用户按角色进行归类，通过用户的角色来确定用户能否针对系统资源进行相对权限功能的操作。 RBAC模型的三要素为：用户、角色、权限。

当有了角色的概念后，我们可以给角色设置相关的权限，再创建用户时只需要绑定一个相应的角色，当权限有变动我们只需要改变角色就可以改变这个角色关联的所有用户对应的权限，这样无需对每一个用户都进行权限调整，大幅度提升权限调整的效率，这样看是不是就简单多了。

RBAC模型的两种基本对应关系：

用户和角色为多对一的关系（用户只能关联一种角色）

用户和角色为多对多的关系（用户可以关联多种角色，用户关联的角色权限取并集）

这两种对应关系可以参考具体业务需求去决定使用哪种设计方案。RBAC的这种基于角色的权限控制方案适用于90%的B端产品。当对于一个系统对权限控制需求有更高的控制需求时，例如SAAS等大型系统又牵扯不同展示数据和不同的控制权限基础的RABC模型往往不适合，我们则需要考虑其他的用户权限方案。

三、RBAC模型的其他权限方案

RABC基础模型通过将一类用户绑定角色，然后让角色赋予权限的方式一定减轻了管理的负担。

当系统用户逐渐增多，用户之间出现了细分角色，这样就需要将把很多用户的角色进行变更，这样的工作量仍然很大；当一个角色的因为职级的问题需要再增加一个角色而且这两个角色只是增加了一部分审批的业务权限，这导致角色量也会越来越多，这样管理员也会需要不断增加角色并且更改用户的角色，这样工作量也不小；当用户成员之间角色牵扯一定的互斥关系，例如采购角色和财务角色是不能分配到同一个用户的，要不然采购的信息提交财务审核通过，这些角色是需要进行隔离的，要不然当一个用户既是‘运动员’又是‘裁判员’ ，那么就会出现问题；

这些需求的出现我们就需要设计更加符合业务角色权限控制，分别有用户组权限设计、继承角色权限设计、约束角色设计。

1、用户组权限设计

当角色类型类型逐渐增多，管理员去维护角色种类也会越来越麻烦，我们可以在相同使用场景内的用户创建一个用户组的方式对用户组进行角色和权限的赋予。比如采购人员可以创建一个采购组，采购组关联采购审批角色和采购运营角色，当采购组的审批角色被取消时只需要取消该采购组的采购审批角色即可，不需要再对所有采购人员进行取消采购审批角色。这样当角色类型增多但是将场景使用人进行分组就可有效的减少对用户和角色的变更。

其实细想这种设计我们可以将用户组抽象为职能（岗位），当一个系统用户数很多但是职能（岗位）明确的情况下我们可以使用用户组权限设计，来将用户组（抽象为企业的某一具体职能岗位）进行关联角色权限，这样就不需要对每个用户进行角色的配置，还可以减少管理员的权限分配工作量。而且用用户组的方式可以将初级岗位划分一定的菜单页面数据的角色权限和基础的业务数据权限。事实上一个用户在企业中往往都会有直属部门和岗位的划分，当我们将部门和岗位职能都抽象为两个用户组，我们可以根据这个纬度来设计更加复杂的角色权限，这样的组合方式也会解决用户对应系统权限配置的灵活性。

当然如果在设计这种权限方式时可以保留基础的RABC的设计，让用户可以直接关联角色，使方案进行融合使用。

2、继承角色权限设计

当一个大型企业的部门和相关岗位类型很多但是权职相对规范时，我们在可以考虑用用户组权限设计方案来规划，但是由于角色都是固定规范的权限匹配，对于配置较多角色配置时会出现遗漏错误并且也会出现权限分配错误的情况，例如一个标准化部门中含有产品总监、产品经理、产品专员、产品助理，产品总监的权限肯定是要大于产品助理的，但当多个角色配置不当就会出现一定权限问题。此时我们可以考虑在角色配置时增加继承角色权限的配置。

继承角色配置的优势是可以将角色设计为角色树，层级越高权限越大且层级低的权限不能对其层级高的进行权限编辑，但是层级高的可以配置自己子层级的权限，层级高的角色也可以给层级低的进行角色变更。这样管理员在划分角色时可以只划分主管一级的角色，主管在拿到他账号权限时，可以自主分配创建自己部门的角色及相应的权限。例如产品总监可以在自己的账号角色权限下创建编辑产品经理、产品专员的角色权限。这样对系统管理员由于只分配主管的角色可减少工作量的同时也会减少角色配置的错误。

3、基于角色设计的约束

当产品经理在设计基于角色权限控制时，需要考虑是否对角色做约束控制，无论是基础的RBAC设计还是用户组权限设计和继承角色设计。在角色的创建之前我们需要根据一定业务范围和相关需求要去考虑是否去做。其设计思想是对于敏感性或者高权限的角色是否设置数量、互斥、

a.角色用户数量约束：一个角色所关联用户数量的限制，比如系统高级管理员admin，可以设置为只允许存在一个

b.角色身份互斥约束：一个用户不能分配到两个互斥的角色上，例如采购和财务，球员和裁判，这就需要创建角色后进行互斥的配置。//当一个用户可以关联互斥角色的前提下，如果再做用户角色的互斥就需要用户登录时需要进行选择进入系统的身份这种方式来实现。

c.多角色权限取并集/交集：在设计一个用户关联角色也可提前设置是取并集或者是交集，这样可以对权限做一定性质的规范，使系统用户的权限即可灵活又可限制。

四、权限控制的设计

我们讲述了在各种B端应用场景下来设计符合业务的基于角色的权限设计方案，在传统的B端业务下我们可以使用RABC模型来设计；在用户数量多但是业务场景（岗位职能）较少时，我们可以使用用户组权限来设计；当业务场景（部门岗位职权规范）多的情况下，我们可以使用继承角色权限来设计；当业务场景有各种规则约束时，我们可以对角色上进行一定的约束来实现系统规范和灵活性；当B端系统有其他更加复杂的业务权限需求时，我们可以将几种方案进行组合设计。当需求的增加一定会导致开发资源的增加，这就需要产品经理在设计功能时需要评估尽可能在开发资源有限的情况下设计出符合业务的功能设计。

我们讲了这么多角色权限控制的应用场景，那么对于B端系统来讲角色控制的权限到底是什么，遇到不同类型的权限怎样评估怎样规划权限的划分合理呢？

其实权限就是指在一个人在企业中由于不同部门划分、不同职责划分后，由于在实际企业负责具体业务的不同，然后B端系统根据其抽象出来的在系统中实行其规定权力的身份。让其管理者基于系统的安全规则与策略，控制不同用户合理访问对应资源。权限管理的优势就是让企业工作中群组内不同人员、不同组织的分工，让不同角色专注于自己的工作范围，也可以降低操作风险发生概率，也便于管理。

在B端系统的场景下我们一般分为四种权限：页面权限、操作权限、业务权限、数据权限

1.页面权限

系统的可视化都是由一个个页面组成的，页面权限就是指一级页面到N级页面是否设置为可见，使用户进入系统中可以看到页面菜单权限

2.操作权限

用户在拥有页面及数据可视化的权限后，对页面进行数据的增删改差操作可定义为操作权限，操作权限往往是跟着页面权限下的

3.业务权限

业务权限其实也属于操作权限，但是往往业务权限需要有明确的业务角色进行划分，也是系统最重要的权限逻辑。例如重要表单的申请、业务数据的审批、用户变更等

4.数据权限

数据权限包含数据范围、数据字段，比如一个标准的系统中含有的规范性的字段往往可以跟随页面权限进行展示，但是一些业务数据往往都有保密性的要求，比如电商的进货价、虚拟机的密码等，这些数据也需要做成是否可见的字段数据权限进行配置。

在角色中上下级，同级有竞争中，在系统中也需要对用户数据做数据权限的划分，比如字段数据权限都配置为可见，但是用户A的客户数据不能展示到用户B的客户数据中，这种往往是在配置权限时进行数据权限的隔离使上级对下级的数据进行可见，同级中只能自己看到自己负责的数据。也适用于SAAS中不同企业数据隔离和团队数据隔离等。

注意事项：产品经理在做数据权限的设计时，需要与开发进行相关设计细节的沟通，以便达到页面模块、操作接口和业务接口都能进行根据业务需求进行分离和组合，并且在数据隔离后任何的角色用户在操作上，不会产生任何影响系统体验的功能。

补充：基础的数据权限可以根据部门唯独范围来进行划分，分为可见所有部门数据，可见本部门数据（是否包含子部门数据），可见本人数据，跨部门数据的标识来区分数据权限，每一个数据权限划分好后往往需要匹配一个角色/角色组。

五、对于B端系统权限设计补充

1、B端系统中初次权限的赋予

在B端系统中基本的操作逻辑是在系统中管理员去手动添加系统用户，在添加系统用户时就配置该用户的权限。但是往往在B端系统中我们会允许用户自行加入系统或者是对接其他系统进行用户数据的同步，这样会导致无法配置用户的权限。所以我们在B端系统中尽量默认创建一个最小权限角色，赋予这个角色用户最基础的权限，类似“游客”角色。也可以根据根据用户的某些特定信息，如部门岗位（用户组权限设计）等，为其自动赋予相应的角色权限。这样做既简化了用户的操作流程，又提高了系统的智能化水平。

2、B端系统中初次配置用户

在B端系统建立之初我们会设置一个最高权限的用户的角色（例如admin），这个角色帮助系统完成首次的角色与权限设置，为后续的业务人员添加和角色配置奠定基础。当这个角色拥有系统中的所有的操作和管理权限，此账户最好设置为一个规则复杂的密码来保障系统的安全性，并且需要将此账号进行隐藏，不在普通用户视图中进行展示，并且配置一定的登录和访问控制，例如admin账号的登录时间和地点进行设置，防止未经授权的访问，也可以配置多种身份校验，提高账号的安全性等。