编辑导语：B端产品数据复杂、业务流程繁琐、用户角色众多，要保证使用中的安全，就需要一个合理的权限设计。在这篇文章中，作者以SAAS为例，分享了一些权限设计的经验，一起看看吧。
B端产品具有数据复杂、业务流程繁琐、用户角色众多的特点，为了保障企业使用过程中系统数据的安全性，一个合理的权限设计是非常重要的，尤其B端SAAS产品具有多租户的概念，一个产品需要供众多客户使用，其对权限控制的要求会更高。
权限一词在词典的解释是行驶权利的界限与范围。软件系统中的权限通常指的是对用户在系统中可查看什么数据、页面、可进行什么操作的限定。
从上述权限的定义中可以看出，权限主要可以分为数据权限、页面权限、操作权限三类。
（1）数据权限
数据权限是指用户能否查看某些数据的权限，用户能查看的数据范围，就是该用户的数据权限。在系统中不同的用户在同一个页面通常查看的数据范围是不同的，比如诊所负责人和诊所医生都具有查看患者信息的权利，但是通常情况下诊所医生只能查看其号源下的患者数据，诊所负责人可以查看诊所下所有的患者数据。
实现数据权限隔离的方案有如下几种：
通过组织机构树控制：该方案根据账号所在组织机构树中的节点位置，来判断能够查询的数据范围。这种方式相对比较复杂，但是最灵活，能够支持各种复杂的业务数据权限诉求。
通过客户地区控制：该方案根据账号所在区域来判断允许查看的数据范围。这种方式简单、容易实现，但是灵活性差，只能满足非常初级的数据权限管理诉求。
通过将数据权限转化为页面权限：该方案是通过将用户能查看哪些数据通过页面的方式进行隔离，赋予用户对应的页面权限就可以查看相应的数据。这方案下同样的功能界面会被分割成很多个功能相同数据不同的页面。
（2）页面权限
页面权限指的是用户登录系统后可以看到哪些页面的权限，通常情况下通过导航栏的功能模块来控制。以门诊医生和收费员两个角色为例，门诊医生可以进入医生工作站模块不能进入收费站；收费员可以进入收费站但是不能进入医生工作站。
（3）操作权限
操作权限指的是用户对页面内功能按钮的具体操作权限，如：新增,修改,删除,审核等。这里的功能按钮指的是该页面最大的功能按钮集合，因为现在的设计通常是所见既能操作，如果用户不具备某个功能的权限，页面内不会显示该功能按钮，以免造成额外的体验负担。从大的方面来说页面权限和操作权限可以统称为功能权限。
在网上查看大量文章后发现，权限设计主要有角色梳理、权限点梳理、权限模型设计、相关原型设计等几个步骤。
元素名次解释：
（1）ACL访问控制列表
通过将用户与权限（资源）直接进行关联绑定进而实现权限配置。以实现患者列表页中删除功能的权限配置为例，将删除功能的权限直接赋予用户，被赋予权限的用户可执行删除操作。
这种权限模型的优点是可以为用户提供个性化的权限配置，缺点是这种方式对权限的管理比较分散，同一个权限无法快捷的同时指定给一群用户，如果需配置的权限很多，或者用户基数很大的时候会非常的费时费力，人工成本极大。
还是以上诉【删除】功能为例，只有一个人需要【删除】权限和有100人需要【删除】权限，配置的难度是完全不同的。
（2）DAC自主访问控制
DAC与ACL的权限配置方法是相同的，区别是拥有权限的用户可以自主地将权限赋予给未拥有权限的用户。
（3）MAC强制访问控制
在MAC模型中，用户与权限（资源）都具有权限标识，用户是否能访问或执行权限对象取决于双方关系的对照。以患者列表页中【删除】为例，用户被规定可以执行删除操作，但是【删除】的权限设置中不具有该用户，则用户无法执行删除，只有当【删除】的权限下同样具备该用户时才能执行删除。通常机密强度较高的会采取这种方法。
（4）RBAC基于角色的访问控制
RBAC认为权限授权实际上是 Who What How 的问题, 即 “Who 对 What 进行 How 的操作”。是”用户”对”资源”的操作, 其中Who是权限的拥有者 (用户) , What 是资源（权限）。
RBAC可以细分为下面四种类型：
RBAC0：
RBAC0是RBAC模型的核心，是支持RBAC模式的任何产品的最低需求，RBAC1、RBAC2、RBAC3都是在其基础上扩展后得到的。
其主要由用户、角色、权限三个元素构成，通过将具有权限集合的角色赋予给用户，从而使用户获得该角色下的权限。一个用户可以关联多个角色，每个角色可以关联多个用户，同时一个角色也可以关联多个权限，角色通常可以视为一组职能相似的用户的集合，同时也是一组权限的集合。
RBAC1：
RBAC1是在RBAC0的基础上引入了角色继承的概念，通过继承使角色之间具有了上下级关系。比如一个父级角色下包括多个子级角色，子级角色的权限来自于父级角色的一部份。以诊所系统医师为例，假设将医师设定为一个父级角色，普通医师、副高级医师作为其子级角色，则普通医师与副高级医师的权限集合包含于医师的权限集合。
RBAC2：
RBAC2是在RBAC0的基础上引入角色约束控制（职责分离）。职责分离指的是用户之间的责任和权限相互分离，通俗一点说就是同一用户不能拥有两种特定的权限，比如运动员不能是裁判一样。
系统中职责分离主要有静态职责分离和动态职责分离两种。
静态职责分离：
静态职责分离是在用户和角色的指派阶段加入的，主要的约束形式有以下几种：
动态职责分离：
动态职责分离的表现是一个用户可以拥有两个角色，但是运行时只能激活一个角色。
RBAC3：
RBAC3是RBAC1与RBAC2的合集，所以其是既具有角色分层又有约束的模型。
（5）ABAC基于属性的访问控制
不同于上面几种用户通过某种方式关联到权限的方式，ABAC是通过动态计算一个或一组属性是否满足某种条件而进行授权判断。（该模型相对比较复杂，相较于RBAC目前的运用也不广泛，所以这里就不详细介绍了，不过有的人称ABAC是权限的未来，因为它能够适应更加复杂的权限分配场景）
根据业务情况选择通过RBAC模型与系统的组织架构进行权限设计。
权限设计的前提是合理的角色设计，由于考虑到部分数据权限需要通过组织结构来进行控制，所以在梳理角色时也分为了组织架构角色梳理和诊所内部角色梳理两个阶段。
（1）组织架构角色梳理
组织架构：
组织架构解释说明：
整个架构通过账号、员工、组织部门来完成搭建。客户指的是SAAS系统的租户；图中每一层都设有一个账号，该账号可以管理同层的组织；账号0是SAAS系统根账号即平台管理员账号；账号1是客户1的根账号，是公司负责人拥有，具有新增诊所等功能；账号2代表诊所的根账号，一般被诊所负责人拥有；账号3则是部门科室的负责人账号；账号4则是部门其他员工拥有。
角色梳理：
组织架构通常在产品初期就已被确定，权限设计阶段只需要抽象角色即可。通过组织架构梳理出的角色大都具有向下管理的权限，即管理员属性。角色与现实中的职位以及业务有紧密的关系，可以将角色与职位进行关联，然后通过某个职位的工作职责进而确定对应角色在系统中的核心动作有哪些，最后将信息进行整理。
如下：（表中信息仅用来举例）
（2）诊所内部角色梳理
诊所内部的角色即组织架构中的员工层，通常在项目前期中的业务调研阶段就已经被确定好，在权限设计阶段同样可以直接使用。相较于组织架构中的角色，诊所内部角色和患者业务的关系更加紧密。如下：（表中信息仅用来举例）
系统权限点梳理主要针对页面权限和操作权限。页面权限可以通过导航菜单进行梳理，将所有的菜单都列举出来（包括一级菜单和二级菜单）；操作权限则是需要梳理出页面下的所有可操作点，这里要注意有的操作点会应状态改变发生变化，在列举时也要加上。这一步会得到初步的权限列表，如下：
由于不同企业、不同诊所中对员工职位内容的界定不一样，因此在系统中我们需要提供用户自定义权限配置的功能，并将该功能的权限默认开通给租户对应的根账号，通过这个功能用户可以自定义角色，自定义角色拥有的权限。大多数SAAS产品都提供权限自定义配置的功能。
这里有个问题，既然用户可以自己进行权限配置，为什么我们还要花大量时间整理角色和权限呢？
这是因为用户并不像我们对权限非常了解，权限配置相对用户来说是一个比价复杂的工作，配置成本高，通常情况下SAAS产品提供者需要对用户进行这方面的培训，所以为了减轻权限配置负担，我们可以将一部分通用的角色抽象出来，比如租户根账号负责人、诊所负责人、医师、理疗师等，为这些角色配置默认权限供用户直接使用。
组织架构角色通常情况下都可以定义为通用角色。（模型图省略）
（1）页面、操作权限
用户的页面权限和操作权限通常在权限配置界面进行勾选即可。
数据权限：
通过系统的组织架构我们可以看出不同租户之间的数据需要进行隔离；同一个租户下不同诊所的数据也需要进行隔离，但是需要满足租户查看所有诊所的数据的需求。
诊所内部的数据权限主要集中在患者病历信息，患者病历的权限需要根据病历的流转发生变化。比如一个患者挂号后，患者信息流转至挂号医生处，该医生获得查看该患者所有病历的权限，医生开具收费处方后，患者信息流转至收费处，收费员即获得查看该患者本次病历信息的权限。
根据用户对数据权限的需求，可以从以下几个方面进行实现：
方案一：自定义配置
可以将数据权限同页面权限一样放入自定义权限配置中，比如查看患者病历信息用户通过选择本公司、本诊所、本科室、本人几个选项去进行数据控制。
方案二：借助页面（功能）隔离数据
通过控制角色对页面的访问实现患者病历数据的隔离。比如将患者病历数据设计成不同的页面，如：我的患者、科室患者、诊所患者、公司患者，具有“我的患者”页面权限的即可查看本人下的患者，具有“科室患者”页面权限的即可查看科室下的患者。
方案三：组织架构
通过角色将账号与系统组织架构进行关联，组织架构图中上级账号可以查看下级账号的所有数据。
最终的的方案需要结合实际业务选择，在这个案例中选择通过组织架构进行数据权限的控制会更加合适。具体的方案可抽象为：用户在系统增加一个诊所，增加诊所的同时系统生成一个诊所负责人角色，且该角色不支持修改、删除，被授予该角色的账号可以查看诊所所有数据；用户在系统增加一个科室，系统默认生成一个该科室管理员角色，且该角色不支持修改、删除，被授予该角色的账号即是该部门中的上级账号，可以查看该部门中的所有数据。例如用户在系统中增加了新的科室–“中医科”，在科室生成的同时系统生成该科室的默认管理员角色–“中医科主任”。
最后提一点通常平台管理员账号的权限仅限于控制客户的账号和相关信息，不能够控制客户内部的业务。
用户获取权限主要包括以下场景：
场景一：新员工加入系统配置权限
为新员工配置权限的常规流程是：在员工管理模块添加员工，填写基础信息，选择部门，然后赋予角色，最后完成权限配置。由于流程较为简单这里就略过流程图了。
场景二：老员工需要更改权限
老员工更改权限流程是：在员工管理模块找到目标员工，更改其系统角色，完成权限更新。
由于页面原型较为简单这里仅展示角色与权限配置界面。
（本案例中的组织架构角色与诊所内角色唯一的差别在于数据权限的不同，其他相关的功能权限两者都可以通过自定义权限配置进行编辑）
B端产品的权限设计主要包括数据权限与功能权限（页面权限与操作权限）两个方面，通常情况下采用RBAC模型实现权限设计，整体步骤包括角色梳理、权限点梳理、实际方案设计、原型设计几个步骤。
B端SAAS产品通常会提供自定义权限配置功能，以满足各租户之间的差异化需求，自定义配置可以很灵活的解决功能权限的配置，在这方面不需要我们费太多精力。在设计过程中，我们的重心应该放在角色的抽象和数据权限的实现方案两方面。
本文由 @医疗PM-大明 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。