本周了解的一个问题是权限系统设计，例如在后台操作时不同用户的权限不同，产品经理和运营能看到的数据可能也会不同。
文章目录如下图：
一、权限系统设计背景
1.1 业务流程复杂化
随着业务越来越复杂，之前一个订单只需要一名销售跟进，现在却需要五个销售协同完成一个订单的流程（每个销售负责其中一个流程）。此时我们就可以通过权限系统，分别赋予五个销售处理各自流程的权限（比如销售 A 只有录入意向订单的权限，销售 B 只有补充客户信息的权限，等等），这样每个销售都只能看到流转至自己手上的信息，将复杂的流程简单化。
1.2 信息敏感
当同级部门不止一个时，便会在同一公司内产生竞争关系。例如，销售 1 组辛苦挖掘的用户数据并不想被销售 2 组看到。权限系统可以设置不同部门的数据彼此独立，即便是各组组长也无法互看对方数据。
1.3 操作安全，权责明确
在一个大型系统中，一个误操作产生的后果可能是非常严重的。权限系统的存在最大程度上避免了这类问题——只要是界面上出现的功能，都是可以操作或不会产生严重后果的。
1.4 页面简洁
如果系统没有进行权限管理，那么每个帐号登录后看到的界面都是一样的，充斥着各种与自己无关的，冗余的信息，甚至还需要专门培训，花费巨大的成本去学习。经过权限系统的管理，每个帐号登陆后只能看到和自己有关的信息，可以更快速地理解自己工作范围内的业务。
1.5 以上还只是针对后台的权限，针对前端也可能会使用到，例如主播、用户看到的不同，普通用户、会员、不同等级的会员、不同等级的用户看到的内容需要不同。
二、权限系统常见设计模型
- 自主访问控制（DAC）
- 强制访问控制（MAC）
- 访问控制列表(ACL)
- 基于任务和工作流的访问控制(TBAC)
- 基于任务和角色的访问控制(T-RBAC)
- 基于对象的访问控制（OBAC）
- 使用控制模型(UCON)
- 基于属性的访问控制（ABAC）
- 基于角色的访问控制(RBAC)，RBAC 模型又可以继续分为 RBAC1、RBAC2、RBAC3
三、RBAC 模型
RBAC 是一套成熟的权限模型，元素包括：用户、角色、权限。在 RBAC 模型中，权限与角色相关联，用户通过成为对应角色的成员，从而得到这些角色的权限。即用户关联角色，角色关联权限，可实现系统权限的灵活配置。并且用户与角色、角色与权限均为多对多的关系。
四、RBAC 模型基本构成
基本构成包括用户、角色、权限，即给谁创建账户，分配什么角色，赋予何种权限。
4.1 用户
用户处于这个模型的最上层，将权限、角色配置好之后，给用户赋予权限也就是水到渠成的事情了。通过给用户选择角色，来给用户赋予角色所集成的权限；在这里，支持给用户同时赋予多个角色。用户的权限是这些角色权限的并集。
因为角色本身的权限就很多，再加上用户可能会同时选择多个角色，因此最好将已经选好的权限列出来了，这样方便当前和以后查看该用户已经选了哪些权限。
4.2 角色
“角色”是 RBAC 模型的独特部分，它是联系用户和权限的纽带。可以理解为“页面权限、”“操作权限”和“数据权限”的一个集合，在这个集合中，可以选择任意的“资源”、“操作”、“数据权限”进行搭配，然后根据需要创建各种各样的角色。打个比方来说，无论你是移动、联通还是电信用户，肯定都办理过套餐。移动有一种自选套餐，这个套餐里面包含通话时长、流量、短信等各种业务，可以任意搭配。“角色”从某种程度上，就可以理解为自选套餐。
因为角色是各种“资源”、“操作”、“数据权限”的集合，其承载的信息可能会很多，所以建议在创建角色时，实时将选择的权限显示出来，这样方便当前和以后查看该角色已经选了哪些权限。
4.3 权限
首先需要知道，一般产品的权限由页面、操作和数据构成。页面与操作相互关联，必须拥有页面权限，才能分配该页面下对应的操作权限。数据可被增删改查。整体关系如下图所示
4.3.1 页面权限
页面权限指的是当前账号可以看到的页面。
4.3.2 操作权限
也叫做功能权限，操作权限是指用户可以进行的操作，例如是否可以增删改等。
4.3.3 数据权限
数据权限指的是可以查看数据的范围。例如 ABC 三人，A无法看到此页面，BC 能看到此页面，但是 C 能看到用户的手机号，B 无法查看用户手机号。
五、RBAC 模型设计原则
5.1 最小特权原则
分配给与某用户对应的角色的权限只要不超过该用户完成其任务的需要。
5.2 责任分离原则
因为在 RBAC 模型中可以通过在完成敏感任务过程中分配两个责任上互相约束的两个角色来实现，例如在清查账目时，只需要设置财务管理员和会计两个角色参加就可以了。
5.3 数据抽象原则
借助于抽象许可权这样的概念实现的，如在账目管理活动中，可以使用信用、借方等抽象许可权，而不是使用操作系统提供的读、写、执行等具体的许可权。但 RBAC 并不强迫实现这些原则，安全管理员可以允许配置 RBAC 模型使它不支持这些原则。因此， RBAC 支持数据抽象的程度与 RBAC 模型的实现细节有关。
六、用户组、权限组
总的来说如下图，用户、角色、权限；分别可有用户组、权限组，没有角色组，如果需要多个角色组成一个角色组的话，就可以创建一个新的权限组了，或者一个新的角色。
在大型平台的应用上，试想如果用户量上万，新增一个角色时，可能需要为大量用户都分配一遍新的角色，工程量仍然巨大，此时即可以引入用户组的概念：如果部分用户的使用场景是相对一致和基础的，我们可以把这些用户打包成一个组，基于这个组的对象进行角色和权限的赋予。
同理如果权限较多时也会存在一样的问题，处理方式是引入权限组的概念，将使用场景相对固定的一组功能或权限打包成组赋予角色。但是一般来讲一个系统中权限功能的体量是相对有限和可控的，所以实际应用中对权限组的使用较少。
七、用户管理
包括模块有：新增账户、编辑账户、删除账户、查看账户、查询账户，以及给账户分配角色。
账号管理是管理员最常用到的功能，相应字段一般是常用字段和特定字段。常用字段比如用户 ID，手机号，姓名，角色，状态和注册时间等，特定字段是公司业务需求，比如分配角色，登录时间，登录次数，访问 IP，访问设备等。
八、角色管理
角色管理的入口在系统管理模块，包括基本的新增角色，编辑角色，删除角色、查看角色、查询角色，以及给角色分配权限。
角色管理是用来管理公司内部用户的角色信息。一个复杂的后台会被分割成很多角色，比如管理员、运营人员、客服人员、财务人员、催收人员等。可把具有共同特征的某一类人群的身份进行归纳，从而为不同的用户赋予对应的角色权限。
管理员会根据公司业务需要，新增对应的角色，并给该角色赋予对应的页面权限和操作权限。角色是关联用户和权限的纽带，可以为用户赋予该角色所集成的相关权限。我们在权限拦截流程设计时，就会限制菜单要根据给用户分配的角色填充，只显示该角色可展示的菜单。
九、权限管理
权限管理更多是从功能菜单、功能操作、数据参数三个不同颗粒度等级来考量的。为了确保将不同的权限不遗不漏的划分到不同的角色，最好是对权限进行划分，划分的维度和粒度由数据权限控制的维度和粒度决定。
9.1 菜单权限
对于后台产品来讲，针对功能菜单来划分用户权限其实是比较粗颗粒度的一种管理方式，这种模式下用户一旦获得授权即可使用该菜单栏下的全部数据查看权限和功能操作权限。
9.2 操作权限
功能操作层级的权限相对于功能菜单会更为深入，这种情况下，不同角色的用户可以进入同一菜单页后台查看相同的数据字段信息，但是他们可执行的功能操作不同。
9.3 数据权限
数据字段层面是较细颗粒度的拆分，他会实现不同角色用户在进入同一菜单页后台时，可见的数据字段都有差异。比如销售人员进入某销售业绩管理后台时，可以看到自己的业绩提升数据，但是财务人员看到的是业务工单的费用字段，这些字段共存在一个菜单页中，只是受限于不同的角色权限而已。
权限管理的入口在系统管理模块，包括基本的新增权限，编辑权限，删除权限、查看权限，以及给权限状态进行开关。
管理员在新增权限时，会限定权限性质为基本权限或操作权限。比如用户没有操作权限时，点击按钮会提示无权限，或者按钮置灰不可点击，或者隐藏该操作按钮。
十、RBAC 模型的三个扩展
RBAC 模型即 RBAC0 模型
10.1 RBAC1
10.1.1 场景
一天老板又把我叫到办公室，语重心长的说，这个小王呀，管理平台设置权限的同事反馈，一个个的角色设置好麻烦啊，能不能上级直接拥有下级的权限啊，比如人事主管直接拥有下属所有员工拥有的权限？
10.1.2 概念
RBAC1 是对 RBAC0 进行了扩展，是 RBAC 的角色分层模型，RBAC1 引入了角色继承概念，有了继承就有了上下级的包含关系，角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。
此时除了对角色进行定义，还需要管理角色间的关系，通过关系来体现角色的层级关系，从而达到继承权限的效果。角色的继承关系主要有两种：树形图和有向无环图：
10.1.3 适用场景
这种模型合适于角色之间的层次明确，包含明确。
10.1.4 实践
第一步，抽取业务角色，确定角色和用户间关系。
因为要求角色间有明显的层级关系，所以在没有其他需求的情况下，此故事背景下根据业务部门和岗位进行角色的抽取。
角色用户对应关系：
角色层级关系：
第二步，确定角色之间的层级关系和继承关系。
我们使用树形和非闭环网图来表示角色之间的层级关系。
一般继承关系：
受限继承关系：
第三步，进行原型草图的设计。
草图包括增加角色、增加人员和角色管理。
添加角色和人员：
10.1.5 说明
一般继承关系和受限继承关系的区别主要在角色间的关系。
上级角色可以继承多个下级角色的权限，上级角色的权限为所有继承角色的权限的叠加。
角色间的继承关系可能会和现实中的有所差异，现实中不会出现运营角色继承人力角色的权限情况。
可能会遇到的问题：由于低级角色的权限全部被高级角色继承，就会导致没有自己角色的私有权限。
10.2 RBAC2
10.2.1 场景
中午吃饭，同事跟我说，由于公司现在组织结构问题，他们组很多人有多个角色，但是由于现在我们只能设置一个角色，所以他们在工作中需要切换多个账号，很不方便。这种场景下，可以使用角色限制模型。
10.2.2 概念
RBAC2 是基于 RBAC0 扩展的，主要引入了 SSD（静态职责分类）和 DSD（动态职责分类）。
SSD 主要运用在用户和角色之间（授权阶段），主要约束：
- 互斥角色，同一个用户不能授予互斥关系的角色，支持责任分离的原则。如：不能同时授予会计和出纳的角色
- 基数约束，一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配。例如公司的领导人有限的
- 先决条件约束，用户想得到高级权限，必须先拥有低级权限，例如，班长只能从副班长中选举，其他例如学习委员没有参选资格
DSD 会话和角色之间的约束，主要动态决定怎样计划角色：
- 运行互斥：例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色
10.2.3 实践
第一步，抽取业务角色，确定角色和用户间关系；
为了表明角色间的互斥，引入全能型员工用户 9，角色为行政主管、人力主管和运营主管，对角色进行抽取，并确定角色间的互斥关系。
角色间关系：
增加角色和人员：
第二步，进行原型草图设计。
包括增加角色、增加人员和角色管理，以及多角色用户登录时，对角色的处理。
角色管理：
用户选择操作角色：
限制还有可能是数量上的，比如一个产品组中必须有且只有一个管理员，不允许删除或再分配管理员角色，仅允许将负责人角色变更。
限制的模型不仅仅对分配过程产生影响，有时即使拥有了多种角色，因为不同的角色对同一个功能的使用方式或数据会产生冲突，所以使用时也需要进行限制。如下图所示为同一时间仅允许以一个身份登录。
10.2.4 说明
当采用静态分离时，互斥的角色不能同时被赋予同一个用户。
动态分离时，则用户登录后需要选择使用的角色，同时要支持根据需要切换角色。
10.3 RBAC3
RBAC3，也就是最全面级的权限管理，它是基于 RBAC0 的基础上，将 RBAC1 和 RBAC2 进行整合了，最全面，也最复杂的，同时包含了 1 和 2 的特性。即既要定义角色间的的继承关系，也要维护好角色间的责任分离关系，使用场景较少。
十一、RBAC 模型的优缺点
11.1 RBAC 模型的优点
- 通过角色来分配权限，具有较强的灵活性；
- 管理（增加、删除、修改）权限比较方便；
- 安全性比较好；
- 权限控制的粒度可大可小；
11.2 RBAC 模型的缺点
RBAC 模型没有提供操作顺序控制机制，这一缺陷使得 RBAC 模型很难应用关于那些要求有严格操作次序的实体系统。例如，在购物控制系统中要求系统对购买步骤的控制，在客户未付款之前不应让他把商品拿走，RBAC 模型要求把这种控制机制放到模型。
十二、注意点
12.1 收集权限需求，根据部门需求列一份权限清单，并做好 CheckList。在模块的功能页面要放置哪些权限，完全可以根据《操作权限申请表》的业务需求，进行灵活的权限配置。
12.2 隐形的 admin
在可自定义角色和权限的系统中，一般需要预留一个 admin 角色来进行系统的初始配置，用于添加首批的业务人员和配置基本的角色。有的系统中允许存在上帝视角的admin角色，则其可以作为“超级管理员”显示在角色配置的列表中；有的系统中不允许这种角色存在，则可将这种角色设置为隐形的状态，仅赋予维护系统的工作人员。
12.3 初始权限的赋予
对于允许用户自行加入的系统，需要设定一至多个默认的角色，有时可以是仅有最基础权限的“游客”角色。初始权限还可以与用户既有的某些数据字段进行关联。如添加用户时获取到用户的岗位为“设计师”，则直接赋予“设计师”角色的权限。
12.4 人员管理中对自己的处理
在人员管理中，管理员角色处理自己时需要额外注意：因为如果修改或删除了自己角色后，可能导致系统没有管理角色，从而无法添加其他成员和正常运行。设计时可添加判断，当自己为唯一管理角色时，禁止编辑和删除。
12.5 无页面权限的提示
虽然可以通过页面权限限制直接隐藏当前用户没有权限的页面，但不能排除用户获取到权限外的url地址。当用户意外访问到没有权限的页面时务必提供“无权限”的提示，避免用户认为系统 bug。
12.6 整个权限系统设计就是定义各个节点和节点间关系的过程。
节点包括：
- 用户
- 用户组
- 角色
- 角色组
- 权限（页面、操作、数据）
- 权限组（页面、操作、数据）
关系包括：
- 是/否关系
- 继承关系
- 限制关系（互斥、范围限制、边界限制、字段限制……）
- ……
12.7 在 RBAC1 模型中，由于高一级的角色继承了低一级角色的所有权限，会导致低一级的角色没有自己的私有权限
在有继承关系的角色权限模型中，如果高一级的角色继承了低一级的所有权限，就会导致低一级的角色没有自己的私有权限，这一点和实际的业务会存在不符合的情况。针对这一点的解决办法有：
引入私有角色，这种办法会导致角色数量变多，提升了角色管理的复杂性
引入私有权限和公有权限，私有权限不允许继承，公有权限允许继承。不同的业务中对公有和私有的定义会有所不同，如传播深度N；公有、私有和特征，权限是否可被继承，根据继承方式确定，继承方式包括一般继承、公有化继承、私有化继承和无特征继承等
12.8 角色数据权限如何控制
作为 ToB 或者平台类产品，除了功能权限，最为头疼的就是数据权限。实际业务中，相同的角色在同一功能下的数据权限是不同的，比如同为代理商角色，代理商A作为华南区的代理商，在客户管理时，只能查看华南区的；同理代理商 B 作为华中区的代理商，在客户管理处，则只能查看华中的。
针对这种情况，需要对数据权限进行控制。针对数据权限的控制，可以在设置角色权限时进行控制，如果没有对数据权限进行控制，则默认为所有的数据。
除了数据和功能权限，我们还会遇到字段权限，比如：代理商 C 和 D 都能看到华南区的客户情况，但是 C 看不到客户联系方式，D 则能看到联系方式。如果有需要对字段权限进行控制，则可以在设置角色的数据权限或者功能权限时，进行控制。
12.9 是否有必要设置默认账号和默认权限
对于 ToB 类或者平台类的产品，正常来讲都会有一个默认的超级管理员的角色以及角色对应的账号，否则系统内第一个角色谁来添加？默认权限的设置则根据需要进行设置，如果是不必要进行控制的权限，当然是可以设置为默认权限的。
12.10 确定是否支持前端配置
如果角色和权限相对固定，则一般将角色与权限的关系可以写在后台，改动时需要后端变更且重新上线；这种情况适用于公司内部系统等只有一个使用主体的系统。如果需要自定义角色、或者每个角色在不同使用者的场景下有不同的权限，则需要将角色的定义、角色与权限之间的配置体现在“前端用户配置页面”；这种情况适用于有频繁变动的自定义角色权限，和有租户体系的系统。
12.11 页面权限优先于操作和数据权限
必须配置了页面模块权限后，才能配置当前页面模块下具体的操作权限，以及页面模块的数据展示权限。
12.12 查看权限优先于增删改权限
正常情况下，一定要先能查看某个模块或操作，其它的增删改操作才有意义。因此在设计时，应在获取查看权限前限制其它权限的配置；或者配置其它权限时默认赋予查看权限。
12.13 角色与权限的设计表达
在传达一个系统的权限设计规则时，设计师常常习惯用主观最直接的方式表达想法，如用“当……时，就……”的句式来表达。但一个平台中涉及的权限规则是非常多的，当通篇以这样的形式描述时，表达对象将很难理解。正确的描述方式：更清晰的是基于开发的语言，和技术模型的结果进行表达：将各角色与权限单元绘制成网格，每个交叉点网格中描述该角色与权限的数据关系和限制。如下图所示：
12.14 权限设计时，在交互层面需要考虑的因素都有哪些
讲到交互层，就不得不讲用户体验，权限设计也是如此。在保证一定扩展性的基础上考虑用户体验。
平台类或者内部产品，虽然设计宗旨不同，但是也得让我们的用户用着爽不是。
在做功能权限时，有时候开发会说，你这个设计方案不存在无限扩展的可能性啊，我们后期可能存在重新做的风险啊。
如果这个方案指的是业务层面，那可能是真的存在问题，这个时候需要和研发好好沟通一番。但如果是指交互方案，那这个时候我们是可以坚持自己的，因为交互方案肯定是结合产品现状、后期的规划发展以及用户的使用习惯，在保证用户体验的基础上输出的。
虽然前端对数据的解读方式一定程度上依赖于交互方案，但是讲到健壮性和扩展性，改动起来的难易程度也是另外一个维度的度量方式。
12.15 其他注意点
权限设计的首要问题是明确需求，权限设计牵涉到后台系统底层架构的业务逻辑，在做后台系统之前，一定要对现有的权限控制和业务情况了解清楚，才能避免在权限设计的问题上踩坑
每个角色至少具备一个权限，每个用户至少扮演一个角色
将用户和权限进行分离，是彼此相互独立，使权限的授权认证更加灵活。
在设计之初我们就需要考虑到未来可能区分角色的地方，尽量解耦、模块化。对于技术来说，每一个页面模块、每一个操作都最好使用独立的接口。对于设计来说，需要保障所有角色因为权限而屏蔽掉部分操作和数据后，页面和流程仍能体验流畅
比方说，用户小明需要拥有的权限和角色1差不多，但是要多出来一个资源的“查看”操作权限。遇到这种情况，应该怎样处理？可能有的同学会说，新建一个角色2不就好了，新角色在角色1的基础上，再加上这个资源的“查看”操作权限。这样做是完全没问题的。
但是，如果又出现了个用户小红，她需要拥有的权限和角色1也差不多，但是要多出来另一个资源的“查看”权限，该怎么办呢？再新建一个角色？针对上面的情景，如果出现了比较多的用户都和某个角色权限差不多，但是又不尽相同的情况，针对每个用户都去新建角色显然不是聪明的做法。在这里，我们可以在给用户通过角色赋予权限的同时，也支持去单独给用户直接选择权限的功能。这样，就可以灵活支持上面所说的这种情况。
这里要注意，单独给用户选择权限时，不能修改已选角色所带来的权限，否则会混乱；但是单独选择的权限，可以进行修改；这种方式虽然会非常灵活，但是只能用来辅助。权限管理人员要尽量保证所有的用户都使用角色来赋予权限
十三、坑
用户的权限归属不明确，导致进件的申请和审核操作为同一个人
敏感数据没有做权限控制和脱敏处理，导致用户隐私数据被泄露
角色的分类不合理，每个用户只能配置一个角色，导致工作组和流程节点比较复杂
对所属团队的客户经理、团队经理和城市经理做了三级维护关系，但人员调动和离职率较大，导致管理成本高
作者：曾俊，微信公众号：Aaron聊产品（ID：Aaron-notes），聊聊关于产品、运营、增长黑客的一些知识。
