第06期：B端产品权限设计怎么做

更新于 2026-09-15

权限是保证职责有效履行的关键：本期讲清权限设计的定义、分类、主流模型（RBAC 等）与落地方法。

1 关于B端产品权限设计

1.1 什么是权限设计

权限，百度百科将其定义为：“保证职责的有效履行，任职者必须具备的，对某事项能进行决策的范围和程度。”但笔者理解为：“不同的对象在不同使用场景下，所需要的产品相应的权力和责任的统一，其核心为权责明晰，权责分离，目的是建立分配资源的规则，以便用户能够通过这套规则，获取他们应获得的资源。”权限系统就是：明确操作人员可在平台内能做什么。即什么样的人，可以做什么样的事，这并不难理解，我们的用户是所有可以登录该平台的人员。

1.2 为什么要权限设计

其实用户权限设计对于C端产品也经常遇到，比如普通用户、VIP用户可能看到的功能就不一样，或者同样的页面看到的数据也不一样。不过更广泛的应用还是在B端产品，或者C端产品的管理后台（平台管理端）我们以B端产品为例，平台提供了200个功能菜单，500个功能按钮，但是使用者的身份不同，或使用目的不同，有的人可能只用到其中的一小部分功能。或者对于企业来说，不同人员的分工不同，相同部门但不同级别的人员可操作权限不同、可查看的数据不同等等，这些实际的使用场景都最终指向了产品中灵活的、可自定义配置的权限管理功能。这样说可能比较宽泛，我们代入一个实际的场景（能理解的可以直接跳过看下一小节）。一家两百人的互联网企业，分为研发部、销售部、财务部、人事部，这家企业采购了一个数字化办公软件。

  • 人事部用它对企业的人员信息、招聘信息、员工的入职、转正、调岗、离职等进行管理；
  • 财务部用它制定公司的成本预算、记账报账、核算并发放工资、归档发票等；
  • 而全体员工也都使用平台进行OA办公，线上流程发起及审批；
  • 企业高管则通过平台的各类统计功能监控、查看企业的日常经营数据。

在这个场景中，平台的功能页面可能有几百个，但是针对不同的部门人员，登录之后看到的功能菜单是不尽相同的，或者同一个菜单的操作权限也是有差异的。

  • 比如【入职信息查询】页面，hr和行政都能查看，但是hr有【入职】的按钮，行政却没有；
  • 比如财务部的财务专员A和B，一个负责研发部预算，一个负责销售部预算，虽然他们都能访问预算功能，但看到的数据也是不一样的；
  • 而C作为财务部总监，全公司的预算数据都可以看到。

以上提到的场景都是实际应用中最常见的，我们一起来看看如何进行设计吧

1.3 分类

通常情况下，我们会将权限分成两个维度，分别为功能权限和数据权限。功能权限是指用户能够做什么样的操作，或者访问哪些资源，使用哪些功能；数据权限是指哪些数据属于你，或者属于你可以操作的范围。从颗粒度维度来分，功能权限的颗粒度从粗到细一般分为“模块级”>>“页面级”>>“接口级”，由此引申出了常说的页面权限、模块权限、接口权限。数据权限的颗粒度从粗到细一般分为“对象级”>>”字段级”，由此引申出对象级数据权限（具体到实际用户）、字段级数据权限（具体到表单字段）。从权限操作维度来说，权限操作可以分为授权和鉴权。

  1. 鉴权是指验证用户是否拥有访问系统的权利，一般是指针对具体人的行为，根据权限规则进行合法性鉴别。在逻辑上，鉴权一般先于授权。
  2. 授权一般可理解为是分配给具体的权限给具体的人。它可分为功能授权和数据授权。

功能授权往往是单一维度的，一般会功能列表或者功能树上进行勾选，来确定用户所对应的可操作资源。数据授权和功能授权不同，数据是多维的，是抽象的。因此，在做数据授权之前，往往需要考虑对数据维度进行拆分，而数据是抽象的，我们不能具象地看待单个用户的某一条数据，那没有任何意义，而是要内置抽象的规则，通过抽象的规则，去寻找数据背后的联系。

2 如何做？

2.1 模型

（1）自主访问控制（DAC：Discretionary Access Control）

自主访问控制是指由用户有权对自身所创建的访问对象（文件、数据表等）进行访问，拥有对象权限的用户。可将对这些对象的访问权授予其他用户和从授予权限的用户收回其访问权限，此类权限模型往往应用于文档系统的权限设计，例如微软的NTFS文件系统。DAC不仅能够分配权限，还能够对权限进行累加，继承，但是其最大的缺点在于，权限过于分散，不方便管理，例如，无法简单地将一组文件设置一个统一的权限开发给制定的一群用户。

（2）强制访问控制（MAC：Mandatory Access Control）

MAC模型往往用于信息敏感行业，该模型将系统中的信息分密级和类进行管理，以保证每个用户只能访问到那些被标明可以由他访问的信息的一种访问约束机制。通俗地来说，在强制访问控制下，用户（或其他主体）与文件（或其他客体）都被标记了固定的安全属性（如安全级、访问权限等），在每次访问发生时，系统检测安全属性以便确定一个用户是否有权访问该文件。例如多级安全（MultiLevel Secure, MLS）就是一种强制访问控制策略。

（3）访问控制列表（ACL：Access Control List）

ACL（Access Control List）主要包含三个关键要素用户（User）、资源（Resource）和操作（Operate）。ACL将每一项资源都分配一个列表，当用户需要访问资源时，都会先去请求列表是否有当前用户的访问权限，从而确定当前用户可否执行相应操作。其优点是，ACL及其简单，不需要任何基础设备就可完成访问控制，但是由于其表单数量过多，导致若系统内部有大量资源，管理访问控制列表就成为了繁琐的工作。

（4）基于角色的访问控制制（RBAC：Role-Based Access Control）

RBAC模型是在实际业务中使用最多的模型，RBAC模型主要由3个基础模块组成，分别为用户、角色、权限。系统通过编辑用户与角色、角色与权限的映射关系，解耦用户与权限的关系，大幅度降低数据冗余，进而降低了系统的复杂度，提高了系统的灵活性。RBAC模型它只是一个大类，它可以细致地划分为：RBAC0、RBAC1、RBAC2、RBAC3。

  1. 基本模型：RBAC0

RBAC0是RBAC的核心，它定义了能构成RBAC控制系统的最小元素的集合（角色）。在此模型中，它指明了角色、用户、访问权限和会话之间的关系。其流程为，通过用户关联角色，定义权限集（角色）的方法间接的赋予用户权限，进而达到用户和权限解耦的目的。在RABC中，用户与角色的关系可以分为为“N：1（多对一）的用户角色关系”和”N:N（多对多）的用户角色关系“。举个N：1的用户角色关系的例子，李三、李四（用户）都是A部门（用户组）的人，岗位都为产品运营（角色），他们都需要文章审核、文章发布功能（权限）。因此，只需要对产品运营（角色）进行分配文章审核、文章发布（权限），将产品运营（角色）分配给李三、李四即可。N：N（多对多）的用户角色关系中，若一个用户被分配了多个角色，那么该用户的权限为所分配角色的并集。再举个例子，李五为B部门的产品经理，权限为文章模板设置。但是因为某次调研，他需要A部门的文章审核、发布权限。当分配给他A部门产品运营角色后，此时，他的权限变成了文章审核、发布权限、文章模板设置。但在实际业务中，对于用户的理解并非如上文中所写的那么浅薄。实际上，对于用户的定义多种多样，就笔者自身对用户的理解而言：“用户本质上为一个个需求的集合体“。从这个角度来讲，在使用场景和需求相对一致的情况下，可以将这部分用户看作一个需求集合体一致的群组，进而形成一个用户组（即为用户的集合体）。拿之前的例子来说，若A部门为产品运营部，那么我们无需对A部门内部的人去分配角色。而是以A部门为对象去分配角色。同时，现实中同样也存在以下使用场景，需要对用户分配居多的权限，若一个个分配将特别繁琐，因而可以选择将相对固定的权限打包成组来赋予给用户。

  1. 角色分层模型：RBAC1

RBAC1在RBAC0的基础上，引入角色间的继承关系，即角色上有了上下级的区别。角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系（有向无环图），可进行多继承。而受限继承关系则进一步要求角色继承关系是一个树结构（二叉树）间的单继承。一般继承的RBAC和受限继承的RBAC两者的区别在于：前者是图，可多继承；而后者可以有多个父节点但只能有一个子节点，是一个反向树结构，只能单继承。RBAC1模型往往使用于角色之间层级明晰的产品中，一般会和组织架构关联起来。例如，李三为产品运营，其上级李四为产品经理。则李四会将其部分权限授权给李三，也可认定为李三继承了李四的部分权限，即子集继承了父级部分权限。

  1. 角色限制模型：RBAC2

RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户——角色——权限关系一起决定了RBAC2模型中用户的访问许可，此约束有多种，主要包括：静态限制（静态责任分离）同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。例如：同一个人不能既是“运动员”又是“裁判员”，即当用户分配给受众运动员的角色后，权限页面无法给于其分配裁判员的权限。动态限制：运行时互斥：例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色。当一个人被授予了运动员和裁判员角色，在一次比赛中，他只能选择以一个身份进行，不能以两种身份同时进行。基数约束：一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限。先决条件角色：可以分配角色给用户仅当该用户已经是另一角色的成员；对应的可以分配访问权限给角色，仅当该角色已经拥有另一种访问权限。要想获得较高的权限，要首先拥有低一级的权限。就像我们生活中，国家主席是从副主席中选举的一样。

  1. 整合统一模型：RBAC3

RBAC3包含了RBAC1和RBAC2，既提供了角色间的继承关系，又提供了责任分离关系。

（5）基于属性的权限验证（ABAC：Attribute-Based Access Control）

ABAC被认为是权限控制的未来，由于其逻辑比较复杂，笔者并未吃透，所以只简单地介绍一下。ABAC可分为访问控制策略、环境条件、主体、客体、主体属性、客体属性。它通过将主体属性、客体属性和环境条件结合起来，按照它们与访问控制策略的匹配情况来确定访问（即对系统客体的操作）。简单而言就是将主体和客体的属性用策略相关联，通过读取策略来确定主体可对客体进行哪些操作。

2.2 方法

权限系统的核心三个功能为：用户、角色和权限，下图为简要的脑图，可辅助理解。

（1）角色管理

  1. 创建角色

角色往往是基于业务管理需求而预先在系统中设定好的固定标签，每个角色对应明确的系统权限，他是一个集合的概念，是众多最小权限颗粒的组成。我们通过把权限给这个角色，再把角色给账号，从而实现账号的权限，因此它承担了一个桥梁的作用。引入角色这个概念，可以帮助我们灵活的扩展，使一个账号可以具备多种角色。

  1. 开启、冻结角色

其所拥有的系统权限一般不会随意更改，并且角色也不会随着用户的被添加和被移除而进行改变，相较于用户管理而言更加稳定。

  1. 编辑角色

由于随着公司扩大角色的增多，而不好进行管理，比如：hr这个角色，如果集团有分公司可以给与分类，比如：上海分公司：人力总监；北京分公司：人力总监。这个角色所赋予的数据权限会不一样，对于中小型公司，可以对角色进行一个精细的分类管理起来比较方便。

  1. 绑定权限
  • 数据权限

数据权限定义：数据权限管理主要控制某条数据记录对用户是否可见，结合功能权限可以更灵活的配置业务过程中每一位员工的功能操作权限及数据可见范围，全面保障企业数据的安全性。类似矩阵列表中，功能权限决定用户可见哪些列，比如客户对象中可见姓名、电话、邮箱等字段。数据权限决定用户可见哪几条数据，比如：“王先生”、“李先生”等。数据权限分两个层次来控制数据：

  1. 基础数据权限：即根据数据的负责人来决定。

私有：对象中所有数据遵循相关团队成员（包括负责人）及其上级对数据可见，且对这条数据具备同样的权限【只读、可编辑】，上级部门的部门负责人可以看到下级部门的所有数据。公开只读：对象中所有数据对全公司公开，单条数据的负责人及其上级、以及相关团队具备编辑权限的成员可以编辑该数据。公开读写：对象中所有数据对全公司公开，全员可编辑。备注：此处的“上级”是指用户的汇报对象，在用户管理界面可进行编辑汇报对象。系统初始化一开始默认设置好（默认设置的应该是根据客户公司实际运营情况），用户再根据公司的发展而进行改变默认设置，也可进行恢复默认设置，因为默认设置是涵盖了客户公司90%的场景。

  1. 数据共享：根据基础数据权限中的数据记录所属将其共享给其它用户查看或编辑。

数据共享规则是将某个部门/员工（数据来源）的某个对象（比如客户）的全部负责的数据共享给某个部门、人员或者用户组（共享范围）。配置数据共享规则后，被共享方对共享方所负责的所有数据可见，并具备共享权限对应的操作权限。业务配置说明：数据来源于：即需要共享的数据，选择员工即指该员工负责的记录数据，选择部门即指该部门下员工负责的记录数据。共享的数据：选择需共享的对象，比如：将员工A负责的客户数据共享给员工B。数据共享到：被共享方，可选择员工、部门或用户组，被选择的员工、部门或用户组成员将可以看到共享的数据。共享后的权限：配置被共享方可对数据查看或是可编辑的权限，如果配置为“读写”权限后，被共享方对共享数据的权限可类比于负责人的权限。业务场景举例：销售一部想让财务部张三看到该部门的所有销售订单数据，并且让张三可编辑。1）共享规则配置【数据来源】是“销售一部”;【共享数据】是“销售订单”【共享范围】是“张三”;【共享权限】是“读写”。2） 配置完成后配置完成后，张三在【销售订单】对象，【共享给我的】场景下，可以看到销售一部的所有员工负责的销售订。

  • 页面权限

指用户登录系统后可以看到哪些页面的权限，通常情况下通过导航栏的功能模块来控制。以门诊医生和收费员两个角色为例，门诊医生可以进入医生工作站模块不能进入收费站；收费员可以进入收费站但是不能进入医生工作站。

  • 功能权限

功能权限定义：为可见、可以操作的功能范围。例如：某一部分菜单，或者某个页面里的各种操作。

  1. 菜单管理模块

类型分为3种：目录、菜单、按钮。在目录、菜单上加权限控制，有权限的就可以访问对应模块，没有的连菜单名都看不到。在业务模块的功能按钮上加权限控制，最小粒度的控制用户行为，譬如：老板娘有录入商品的权限，就能看到商品录入的按钮，点击录入就可以进行商品的录入操作；反之没有该权限的店员就无法进行商品录入的操作。

  1. 控制功能权限管理

底层菜单管理配置一般为开发人员一早就配置好，现在由用户进行分配使用这些功能权限。功能权限：以角色为基础，通过划分不同角色的不同功能权限，并将员工添加到对应的角色中，实现员工功能权限的区分和隔离，包括：对象级功能：比如功能的入口是否可见，如角色为“蓝鲸观察者”，对象“人员管理”的“查看列表”权限点取消，则此角色下员工不可见人员管理的功能入口。操作点权限：比如新建、编辑等业务操作；字段权限：在展示信息时加权限控制，保证敏感信息的安全性。可为角色配置对象字段的读写、只读或不可见。比如：为角色“服务人员”配置销售订单的【销售订单金额】字段不可见。控制了员工对字段的可见性，可编辑性，比如：不想要电销人员看到客户的电话号码，不需要服务人员看到客户销售订单中销售订单金额，则可以把相应字段隐藏。【读写】权限：员工将具备该字段的最大权限，【新建】【编辑】时可编辑，列表和详情页可见该字段。【只读】权限：员工在【新建】【编辑】时不可编辑，列表和详情页可见该字段。【不可见】权限：员工在【新建】【编辑】【列表】【详情】界面对该字段（或该字段值）不可见。功能权限对于前端界面的影响点：如果员工没有某对象“查看列表”的权限，则该对象的功能入口会被隐藏。如果员工没有某对象的操作点权限，则在对象页面上隐藏相应操作按钮。如果员工没有某对象的指定字段的可见权限，则在对象页面上隐藏相应字段。

  1. 控制字段权限用户操作界面

控制字段权限需要有一个页面配置页面来做支撑，此界面由开发人员进行控制操作。点击某一个页面进行配置，可以进行添加，或从数据库快速生成属于这个页面的字段。在从这个页面的字段中选择哪些字段是提供给用户进行设置字段权限，因此有了上上图。以及字段的显示名称，是否必填字段都是控制提供给用户进行设置字段权限界面。

（2）用户管理

  1. 分配角色

通常企业的后台管理系统，可以同企业内部OA或企业微信等系统间打通，当用新员工入职时，可主动申请后台相应权限，高级管理员（即权限分配者）根据用户的职责，分配具体的角色。若后台系统暂未与系统打通，则需管理员手动创建用户。

  1. 创建用户

用户界面原型图如上所示，该原型内为尚未连接企业OA，需手动创建用户，所有可登录后台的用户都将在表中展示。添加用户的界面如下图所示：在创建用户时，需输入用户的基本信息，并直接为用户绑定角色，那么如何设定角色呢？这是我们下一步需要说明的问题。细心的同学不难发现，上图页面中存在“修改权限”的按钮，该功能的存在是为了避免角色与权限的绑定过于僵化，可针对同一角色在不同用户使用时，进行微调，避免每次都产生新的角色。

2.3 注意事项

（1）熟悉业务流程，盘点角色

设计初期，应该重新梳理系统中不同模块的业务流程，通过业务流程图，来盘点各个节点的角色，在这一环节中，需要对角色进行穷举，保证系统在运行过程中达到闭环。一般情况下：

  • 角色通过岗位去划分，例如在禅道中，通过不同的岗位来划分不同的角色。
  • 角色通过任务流划分，根据业务流程中的不同节点功能，可将定义角色，例如，在某审批系统，可将角色划分为录入人员、审核人员。

（2）盘点权限，使用正确的描述方式

将系统中的所有功能模块进行归纳整理，并根据自身系统所需要的颗粒度，来选择权限的颗粒度。同时，在PRD中传达一个系统的权限设计规则时，不应该采用“当…时，就….“的语句去表达规则，而是要将角色和单元绘制成网格，每一个交叉节点为描述该角色与权限的数据关系和限制。特别要注意的是，在设计数据权限时，其查看权限往往应设计在“增、删、改、查”之前。

（3）做好无页面权限的提示

在正常情况下，当用户无对应权限时，该页面会直接隐藏，但也不排除用户可以获取到权限外的URL地址，因为当用户访问到没有权限的页面时，需提示该用户无对应权限。

（4）创建默认角色

默认角色一般为系统中自带的角色，其往往包括超级管理员，管理员、业务员等等。一般情况下，超级管理员为隐形角色，为领导高层掌握，拥有整个系统的所有权限，管理员继承超级管理员所分配的权限，若管理员唯一的情况下，自身不可编辑，不可删除，防止用户删除管理员角色，导致系统无法正常运行。其余角色为管理员创建，可编辑，可删除。

（5）对系统的长期规划需明确

在搭建权限系统时，应该详细地了解系统的业务范围和长期规划，梳理角色，并尽可能多地获取用户信息。例如，在数据权限配置过程种，我们通过数据打标来划分数据权限，但是随着数据的标识增加，权限判断条件增多，就会出现大量用户信息需要判断的问题。

（6）用户的长期维护需及时处理

当系统长时间运转时，在权限上，可能会因为用户离职，权限系统未及时更新，而导致内部数据泄露的问题发生。针对这种情况，产品可采用权限系统与OA系统互通或者系统设置数据自动清洗的规则来解决。

（7）公司内部的权限规则需统一

当一个系统非常庞大时，由多名产品经理负责时，可能会出现由于没有制定统一的权限规范，导致在提需求时，忘记说明而导致新功能没有去实现权限控制。因此，在一个相对较大的项目中，产品经理们可以针对权限、UI做一个统一的标准。

3 举例1、系统权限设计：以SAAS为例

根据业务情况选择通过RBAC模型与系统的组织架构进行权限设计。

3.1 角色关系梳理

权限设计的前提是合理的角色设计，由于考虑到部分数据权限需要通过组织结构来进行控制，所以在梳理角色时也分为了组织架构角色梳理和诊所内部角色梳理两个阶段。

（1）组织架构角色梳理

组织架构：组织架构解释说明：整个架构通过账号、员工、组织部门来完成搭建。客户指的是SAAS系统的租户；图中每一层都设有一个账号，该账号可以管理同层的组织；账号0是SAAS系统根账号即平台管理员账号；账号1是客户1的根账号，是公司负责人拥有，具有新增诊所等功能；账号2代表诊所的根账号，一般被诊所负责人拥有；账号3则是部门科室的负责人账号；账号4则是部门其他员工拥有。角色梳理：组织架构通常在产品初期就已被确定，权限设计阶段只需要抽象角色即可。通过组织架构梳理出的角色大都具有向下管理的权限，即管理员属性。角色与现实中的职位以及业务有紧密的关系，可以将角色与职位进行关联，然后通过某个职位的工作职责进而确定对应角色在系统中的核心动作有哪些，最后将信息进行整理。如下：（表中信息仅用来举例）

（2）诊所内部角色梳理

诊所内部的角色即组织架构中的员工层，通常在项目前期中的业务调研阶段就已经被确定好，在权限设计阶段同样可以直接使用。相较于组织架构中的角色，诊所内部角色和患者业务的关系更加紧密。如下：（表中信息仅用来举例）

3.2 系统权限点梳理

系统权限点梳理主要针对页面权限和操作权限。页面权限可以通过导航菜单进行梳理，将所有的菜单都列举出来（包括一级菜单和二级菜单）；操作权限则是需要梳理出页面下的所有可操作点，这里要注意有的操作点会应状态改变发生变化，在列举时也要加上。这一步会得到初步的权限列表，如下：

3.3 权限方案设计

由于不同企业、不同诊所中对员工职位内容的界定不一样，因此在系统中我们需要提供用户自定义权限配置的功能，并将该功能的权限默认开通给租户对应的根账号，通过这个功能用户可以自定义角色，自定义角色拥有的权限。大多数SAAS产品都提供权限自定义配置的功能。这里有个问题，既然用户可以自己进行权限配置，为什么我们还要花大量时间整理角色和权限呢？这是因为用户并不像我们对权限非常了解，权限配置相对用户来说是一个比价复杂的工作，配置成本高，通常情况下SAAS产品提供者需要对用户进行这方面的培训，所以为了减轻权限配置负担，我们可以将一部分通用的角色抽象出来，比如租户根账号负责人、诊所负责人、医师、理疗师等，为这些角色配置默认权限供用户直接使用。组织架构角色通常情况下都可以定义为通用角色。（模型图省略）

  1. 页面、操作权限

用户的页面权限和操作权限通常在权限配置界面进行勾选即可。数据权限：通过系统的组织架构我们可以看出不同租户之间的数据需要进行隔离；同一个租户下不同诊所的数据也需要进行隔离，但是需要满足租户查看所有诊所的数据的需求。诊所内部的数据权限主要集中在患者病历信息，患者病历的权限需要根据病历的流转发生变化。比如一个患者挂号后，患者信息流转至挂号医生处，该医生获得查看该患者所有病历的权限，医生开具收费处方后，患者信息流转至收费处，收费员即获得查看该患者本次病历信息的权限。根据用户对数据权限的需求，可以从以下几个方面进行实现：方案一：自定义配置可以将数据权限同页面权限一样放入自定义权限配置中，比如查看患者病历信息用户通过选择本公司、本诊所、本科室、本人几个选项去进行数据控制。方案二：借助页面（功能）隔离数据通过控制角色对页面的访问实现患者病历数据的隔离。比如将患者病历数据设计成不同的页面，如：我的患者、科室患者、诊所患者、公司患者，具有“我的患者”页面权限的即可查看本人下的患者，具有“科室患者”页面权限的即可查看科室下的患者。方案三：组织架构通过角色将账号与系统组织架构进行关联，组织架构图中上级账号可以查看下级账号的所有数据。最终的的方案需要结合实际业务选择，在这个案例中选择通过组织架构进行数据权限的控制会更加合适。具体的方案可抽象为：用户在系统增加一个诊所，增加诊所的同时系统生成一个诊所负责人角色，且该角色不支持修改、删除，被授予该角色的账号可以查看诊所所有数据；用户在系统增加一个科室，系统默认生成一个该科室管理员角色，且该角色不支持修改、删除，被授予该角色的账号即是该部门中的上级账号，可以查看该部门中的所有数据。例如用户在系统中增加了新的科室–“中医科”，在科室生成的同时系统生成该科室的默认管理员角色–“中医科主任”。最后提一点通常平台管理员账号的权限仅限于控制客户的账号和相关信息，不能够控制客户内部的业务。

3.4 梳理用户获取权限流程

用户获取权限主要包括以下场景：场景一：新员工加入系统配置权限为新员工配置权限的常规流程是：在员工管理模块添加员工，填写基础信息，选择部门，然后赋予角色，最后完成权限配置。由于流程较为简单这里就略过流程图了。场景二：老员工需要更改权限老员工更改权限流程是：在员工管理模块找到目标员工，更改其系统角色，完成权限更新。

3.5 页面原型设计

由于页面原型较为简单这里仅展示角色与权限配置界面。（本案例中的组织架构角色与诊所内角色唯一的差别在于数据权限的不同，其他相关的功能权限两者都可以通过自定义权限配置进行编辑）

3.6 总结

B端产品的权限设计主要包括数据权限与功能权限（页面权限与操作权限）两个方面，通常情况下采用RBAC模型实现权限设计，整体步骤包括角色梳理、权限点梳理、实际方案设计、原型设计几个步骤。B端SAAS产品通常会提供自定义权限配置功能，以满足各租户之间的差异化需求，自定义配置可以很灵活的解决功能权限的配置，在这方面不需要我们费太多精力。在设计过程中，我们的重心应该放在角色的抽象和数据权限的实现方案两方面。

4 举例2、实战篇：B端权限管理

4.1 项目背景

本次项目是为某研究院搭建一套信息化系统，包括统一用户管理平台、CSS系统、CRM系统、两套LIMS系统。其中统一用户管理平台由客户IT部门管理，决定哪个用户能够登录哪个系统。CRM系统由内部管理人员、商务、内勤、办公室、财务等人员使用，用于客户管理和内部管理，需要实现很多跨部门协同的功能，而且是以上各系统中使用人员和范围最广的一个系统。以下分析均以CRM系统为例：

  1. 信息化基础：该研究院IT基础薄弱，目前只有GLP实验室管理系统。
  2. 组织架构：该研究院组织架构较为复杂，包括总部和子公司。部分人员交织在一起，而且组织机构还在不断调整中。

4.2 限管理实战

在具体项目中，我们按照【梳理组织架构 – 确定权限管理设计框架 – 开展具体的产品设计 – 梳理角色权限和数据权限 – 初始化配置 – 根据客户需要进行调整】的顺序，去实现合适的权限管理。

（1）梳理组织架构

对客户实际组织架构和业务情况进行了解梳理，总结如下：

  • 其中财务部归总部管理，财务部管理所有下属子公司和业务部门的费用、风险控制。子公司一为独立法人公司，但部分员工、资产和资质仍归属总部。
  • 子公司一签署的合同主体既有独立法人公司的，又有总部的。但子公司一的员工、资产和资质将逐渐从总部剥离。
  • 子公司二为独立法人公司，签署的合同主体、授信均为本公司。
  • 业务一部归总部管理，签署的合同主体、授信均为总部。
  • 子公司一、子公司二、业务一部的业务数据要进行隔离。

（2）确定权限管理设计框架

通过对组织机构的梳理，并通过用户访谈对业务进行了深入的理解，我们总结出：

  • 该系统需要对各子公司和业务部门的客户数据和业务数据进行隔离；
  • 各子公司和业务部门均有销售经理、办公室经理、商务、内勤、办公室几个角色，而且通过了解，同角色的人员所负责的事项都是相同的；
  • 有一些特殊的权限管理需求：例如商务、内勤只具有本人的业务单据权限，但可以查看操作所属法人公司的到账、授信、客户余额等数据。

可以看出，传统的权限管理模型显然不能满足该系统的权限管理需要。如果使用传统的RBAC模型，也存在多个角色重复创建、无法管理数据权限的问题。因此，我们确定在CRM系统上，应该使用基于RBAC的扩展模型。通过岗位管理用户在系统中的功能权限和数据权限，以满足客户需求。

（3）开展具体的产品设计

  1. 用户管理
  2. 用户列表、查询

用户列表页展示用户名（即用户在系统中的账号名）、姓名（用户实际姓名）、电话、邮箱、状态、部门、岗位等有价值的信息。同时具备编辑、启用、分配岗位功能。

  1. 用户新增、编辑、删除

本项目中，用户的新增、删除均通过统一用户管理平台进行，并分配系统级权限。各系统中自行编辑、分配权限。用户的字段包括登录邮箱、手机号码、姓名、用户名、部门、性别等字段，其中姓名和部门为必填项。

  1. 禁用

如果出现用户离职的情况，可以将用户禁用，不可登录系统，防止业务数据流失。

  1. 分配岗位

可以为用户分配相应的岗位，用户与岗位的关系是一对多。

  1. 组织机构管理
  2. 组织机构列表、查询

左侧为组织机构，可以编辑组织的层级关系。右侧为该组织机构下的岗位列表，可以对岗位进行查看、编辑、删除、分配角色和数据权限、分配用户的操作。

  1. 新增、编辑部门

点击组织机构右侧的“+”按钮，可新增子部门。填写部门编码、部门名称、部门类型、公司类型。默认新增部门为所选部门的子部门。其中，公司类型是这个项目的特殊需求，与客户业务相关，正常权限管理一般不需要这个字段。

  1. 删除部门

点击部门右侧的“删除”图标，可以删除该组织节点。

  1. 角色管理
  2. 角色列表

左侧为角色列表，右侧为角色对应的功能权限。功能权限可以根据客户需求，可以细致到按钮级，也可以只管理到页面级别。

  1. 角色新建

点击“新建角色”按钮，输入角色编码、名称和备注。其中，如果有特殊的权限需求，一般要与角色编码挂钩，这种情况下角色编码需要与技术团队约定规则，不可随意变更。

  1. 分配功能权限

点击左侧的角色名称，可以在右侧列出的功能列表中，对该角色分配相应的功能权限。

  1. 岗位管理
  2. 岗位列表

在岗位列表页可查看岗位名称、岗位编码和部门。并可对岗位进行查看、删除、编辑、分配角色和数据权限、分配用户的操作。

  1. 新建岗位

点击左侧的组织机构，即可创建该组织节点下的岗位，部门默认为左侧所选的组织节点。填写岗位名称、岗位编码、选择部门。岗位编码同角色编码，若有特殊权限需求，要与开发制定相应的规则，不可随意变更。

  1. 岗位详情

点击“查看”按钮，可以查看岗位详细信息和具有该岗位的人员列表。

  1. 分配角色和数据权限

为岗位分配其角色和数据权限。岗位和角色之间是多对多的关系，一个岗位可以具有多种角色，一种角色也可被赋予多个岗位。数据权限本次项目上做的非常冗余、用户体验极差，给每个角色又配置了相同的名称和数据权限，即“职能”，系统管理员还不能编辑岗位职能。（我也不知道当时产品和开发咋想的哈哈哈）通常来说，应当直接分配数据权限：本人、本部门、本部门及下级部门，简单明了。另外，若组织机构比较复杂，可以加上“法人公司”的数据权限，往上追溯离用户最近的法人公司。用户即具备法人公司下的业务数据权限。

  1. 分配用户

点击“分配用户”按钮，可将岗位分配给用户。用户与岗位是多对多的关系。

  1. 梳理角色权限表单

通过组织机构分析和产品设计，我们已经抽象出可以使用CRM系统的角色。这时就需要产品经理梳理角色权限表单，目的有二：

  • 测试阶段需要初步验证业务流程是否可以正常进行；
  • B端客户对系统一般不太熟悉和了解，让用户梳理角色权限是不太可能的。因此在上线前我们往往会初始化角色权限，用户只需要在后续使用中进行调整即可。

角色权限表单可参考下图：

  1. 梳理数据权限

对各岗位的数据权限进行梳理，若存在无法通过系统配置的特殊权限需求，需要与开发沟通，通过代码写死或者约定一定的规则，用角色编码或岗位编码实现。例如：本项目上，商务人员、内勤人员的客户和委托单数据权限为本人，但是对于循环授信、到账公告和客户余额

  1. 系统上线、试运行

系统上线时，需要对角色权限进行初始化配置，并通过用户培训和配置文档将配置规则教给客户。上线试运行期间，可以由运维人员协助客户对实际业务的新情况调整权限配置，在过程中让客户IT人员逐渐熟悉权限配置规则。在使用过程中，客户也必然会提出一些新的特殊权限的需求，这时候需要产品进行评估，根据对现有权限框架的影响决定是否变更。最后，权限管理体系下的用户登录有两种方式：

  • 用户登录时，仅能选择一个岗位，其在系统中可查看和操作的功能和数据均为该岗位的功能权限和数据权限；
  • 用户使用一个账号登录，登录后具有其所有岗位的全集功能和数据权限。这种情况下，在权限配置时，一定要特别注意角色的静态互斥和动态互斥。

参考文献：

  1. B端后台“权限设计”的99种解法与反思https://www.woshipm.com/pd/5314723.html
  2. 产品设计 | 浅谈B端产品用户权限https://www.woshipm.com/pd/5643118.html
  3. 权限系统的设计——由浅至深https://www.woshipm.com/pd/4766925.html
  4. 4个步骤教你：如何建立后台通用权限管理系统？https://www.woshipm.com/pd/1353559.html
  5. 后台设计之权限管理https://www.woshipm.com/pd/2852504.html
  6. 统权限设计：以SAAS为例https://www.woshipm.com/pd/5472275.html
  7. 实战篇：B端权限管理https://www.woshipm.com/pd/3771277.html
→ 产品兵器库 · 第06期（原始飞书文档）