ToB产品权限系统设计（一RBAC模型）
Posted QINGYU
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了ToB产品权限系统设计（一RBAC模型）相关的知识，希望对你有一定的参考价值。
用户角色权限管理系统是ToB产品线中必备且非常重要的模块功能，不论是对企业内部系统的运维权限设定，还是对于用户控制台的子母账号权限管理，权限系统的分析和规划都是是一个B端产品经理必备的能力。本篇我们将从RBAC模型的深度解析来进行深入探讨。
一、简述
RBAC（Role-Based Access Control）即：基于角色的权限控制。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。通过角色关联用户，角色关联权限的方式间接赋予用户权限。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。
有人会问为什么不直接给用户分配权限，还多此一举的增加角色这一环节呢？
① 其实是可以直接给用户分配权限，只是直接给用户分配权限，少了一层关系，扩展性弱了许多，适合那些用户数量、角色类型少的平台。
② 对于通常的系统，比如：存在多个用户拥有相同的权限，在分配的时候就要分别为这几个用户指定相同的权限，修改时也要为这几个用户的权限进行一一修改。有了角色后，我们只需要为该角色制定好权限后，将相同权限的用户都指定为同一个角色即可，便于权限管理。
③ 对于批量的用户权限调整，只需调整用户关联的角色权限，无需对每一个用户都进行权限调整，既大幅提升权限调整的效率，又降低了漏调权限的概率。
二、访问权限三元组
RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组,也就是“Who对What(Which)进行How的操作”。
Who：权限的拥用者或主体
What：权限针对的对象或资源
How：具体的权限
Operator：操作。表明对What的How操作。也就是Privilege+Resource
Role：角色，一定数量的权限的集合。权限分配的单位与载体,目的是隔离User与Privilege的逻辑关系.
Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户而给组。组可以包括组(以实现权限的继承)，也可以包含用户，组内用户继承组的权限。用户与用户组是多对多的关系。Group可以层次化，以满足不同层级权限控制的要求。
三、RBAC模型的分类
RBAC模型可以分为：RBAC0、RBAC1、RBAC2、RBAC3 四种。其中RBAC0是基础，也是最简单的，相当于底层逻辑，RBAC1、RBAC2、RBAC3都是以RBAC0为基础的升级。一般情况下，使用RBAC0模型就可以满足常规的权限管理系统设计了。
① —— RBAC0模型
最简单的用户、角色、权限模型。这里面又包含了2种：
a、用户和角色是多对一关系
一个用户只充当一种角色，一种角色可以有多个用户担当。
b、用户和角色是多对多关系
一个用户可同时充当多种角色，一种角色可以有多个用户担当。
那么，什么时候该使用多对一的权限体系，什么时候又该使用多对多的权限体系呢？
如果系统功能比较单一，使用人员较少，岗位权限相对清晰且确保不会出现兼岗的情况，此时可以考虑用多对一的权限体系。其余情况尽量使用多对多的权限体系，保证系统的可扩展性。如：张三既是行政，也负责财务工作，那张三就同时拥有行政和财务两个角色的权限。
② —— RBAC1模型
相对于RBAC0模型，增加了子角色，引入了继承概念，即子角色可以继承父角色的所有权限。
使用场景：如某个业务部门，有经理、主管、专员。主管的权限不能大于经理，专员的权限不能大于主管，如果采用RBAC0模型做权限系统，极可能出现分配权限失误，最终出现主管拥有经理都没有的权限的情况。
而RBAC1模型就很好解决了这个问题，创建完经理角色并配置好权限后，主管角色的权限继承经理角色的权限，并且支持在经理权限上删减主管权限。
③ —— RBAC2模型
基于RBAC0模型，增加了对角色的一些限制：角色互斥、基数约束、先决条件角色等。
a、角色互斥
同一用户不能分配到一组互斥角色集合中的多个角色，互斥角色是指权限互相制约的两个角色。案例：财务系统中一个用户不能同时被指派给会计角色和审计员角色。
b、基数约束
一个角色被分配的用户数量受限，它指的是有多少用户能拥有这个角色。例如：一个角色专门为公司CEO创建的，那这个角色的数量是有限的。
c、先决条件角色
指要想获得较高的权限，要首先拥有低一级的权限。例如：先有副总经理权限，才能有总经理权限。
d、运行时互斥
例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色。
④ —— RBAC3模型
称为统一模型，它包含了RBAC1和RBAC2，利用传递性，也把RBAC0包括在内，综合了RBAC0、RBAC1和RBAC2的所有特点，既提供了角色间的继承关系，又提供了责任分离关系。 建立角色定义表。定出当前系统中角色。 因为有继承的问题，所以角色体现出的是一个树形结构。
但把这两种概念组合在一起也引起一些新问题。限制也可以应用于角色等级本身，由于角色间的等级关系满足偏序关系，这种限制对模型而言是本质性的，可能会影响这种偏序关系。例如，附加的限制可能会限制一个给定角色的应有的下级角色的数量。
因此对于RBAC3模型，不能为了实现而实现，要有具体的使用场景，其中用户的学习成本较高，反而不利于产品的发展。
四、许可配置
在RBAC中，用户就是一个可以独立访问计算机系统中的数据或者用数据表示的其他资源的主体。角色是指一个组织或任务中的工作或者位置，它代表了一种权利、资格和责任。许可（特权）就是允许对一个或多个客体执行的操作。一个用户可经授权而拥有多个角色，一个角色可由多个用户构成；每个角色可拥有多种许可，每个许可也可授权给多个不同的角色。每个操作可施加于多个客体（受控对象），每个客体也可以接受多个操作。
用户表（USERS）
包括用户标识、用户姓名、用户登录密码。用户表是系统中的个体用户集，随用户的添加与删除动态变化。
角色表（ROLES）
包括角色标识、角色名称、角色基数、角色可用标识。角色表是系统角色集，由系统管理员定义角色。
客体表（OBJECTS）
包括对象标识、对象名称。客体表是系统中所有受控对象的集合。
操作算子表（OPERATIONS）
包括操作标识、操作算子名称。系统中所有受控对象的操作算子构成操作算子表。
许可表（PERMISSIONS）
包括许可标识、许可名称、受控对象、操作标识。许可表给出了受控对象与操作算子的对应关系。
角色/许可授权表
包括角色标识、许可标识。系统管理员通过为角色分配或取消许可管理角色/许可授权表。
RBAC的基本思想是：授权给用户的访问权限，通常由用户在一个组织中担当的角色来确定。RBAC中许可被授权给角色，角色被授权给用户，用户不直接与许可关联。RBAC对访问权限的授权由管理员统一管理，RBAC根据用户在组织内所处的角色作出访问授权与控制，授权规定是强加给用户的，用户不能自主地将访问权限传给他人，这是一种非自主型集中式访问控制方式。例如，在医院里，医生这个角色可以开处方，但他无权将开处方的权力传给护士。
在RBAC中，用户标识对于身份认证以及审计记录是十分有用的；但真正决定访问权限的是用户对应的角色标识。用户能够对一客体执行访问操作的必要条件是，该用户被授权了一定的角色，其中有一个在当前时刻处于活跃状态，而且这个角色对客体拥有相应的访问权限。即RBAC以角色作为访问控制的主体，用户以什么样的角色对资源进行访问，决定了用户可执行何种操作。
五、什么是角色
①角色类型
角色从使用的角度划分，一种是管理角色，一种是业务角色。管理角色是针对平台的管理用户，用来划分管理的范围。业务角色是员工在系统中执行各种实际工作流时的角色。从创建方式的角度划分，一种是内置角色，一种是自定义角色。通常管理角色通过自定义的方式创建，业务角色通过内置的方式创建。
至于系统应该选择用什么样的方式定义权限，根据产品的组织架构，和性质来划分：
a、简单类型产品，没有工作流
管理角色和业务角色重合，根据需求做到菜单级别自定义授权，或功能级别自定义授权即可；
b、有工作流，但是组织架构较为简单
管理角色自定义到菜单或功能级别，业务角色根据业务流梳理业务角色内置即可；
c、复杂组织架构，复杂业务流
管理角色做到应用级别授权，管理员由IT运维人员担任，他们通常不了解业务，因此菜单或功能级别的权限划分给业务角色，业务角色根据工作流引擎内置。由于复杂业务流情况下，系统一定会有一套自定义工作流的引擎，用来随时创建和变更工作流程，因此业务角色通常是各个岗位的岗位名称即可。除此之外，可能还要处理上下级权限继承的关系。
②管理角色
a、超级管理员
超级管理员角色是拥有最高权限的角色，通常内置一个admin用户，或者是创建某个管理实体的用户。以钉钉为例，对企业进行注册和创建的用户即为超级管理员。超级管理员对应的用户只有一个，整个系统归属于它，允许变更该用户，不允许删除角色。
b、普通管理员
所有的自定义管理员为普通管理员，其管理权限配置需配置组织部门权限和应用管理权限，组织部门权限是其管理的数据范围，如XX子公司、销售部，应用权限即各个应用。
③业务角色
业务角色的权限体现在工作流中，随着任务在不同岗位之间流转，不同岗位看到的内容完全一样，只是处理的表单不一样。
比如请假审批：一张请假单先通过小组leader到部门leader到人事，数据一致，只是数据的状态在发生改变。根据职位来配置业务角色即可。
一般来说，系统部署好之后，业务角色会完全初始化好，变更的话需要通过工作流引擎中添加，或者通过添加代码的方式增加。通常企业的职位、职级设置都相似，变更的情况较少发生。
六、什么是权限
权限是资源的集合，这里的资源指的是软件中所有的内容，包括模块、菜单、页面、字段、操作功能（增删改查）等等。具体的权限配置上，目前形式多种多样，按照我个人的理解，可以将权限分为：页面权限、操作权限和数据权限等。
①页面权限
所有系统都是由一个个的页面组成，页面再组成模块，用户是否能看到这个页面的菜单、是否能进入这个页面就称为页面权限。如下图：
客户列表、客户黑名单、客户审批页面组成了客户管理这个模块。对于普通用户，不能进行审批操作，即无客户审批页面权限，在他的账号登录后侧边导航栏只显示客户列表、客户黑名单两个菜单。
②操作权限
用户凡是在操作系统中的任何动作、交互都是操作权限，如增删改查等。
③准入权限
准入权限是对用户账号的登录限制，原则上属于用户账号体系，和角色关联不大。通常会有如下功能需求：
a、进入限制
直接限制账号是否拥有登入平台，或登入某个应用的权限，比如普通员工无法进入人事管理应用。
b、二次验证
二次验证是在识别到用户的登录地点、登录设备、登录客户端变更之后的二次验证，做的比较好的如微信的二次登录验证，支持验证码，邀请好友验证等多种方式。
c、时间限制
仅允许在规定时间之前使用账号，通常用于发放试用账号之类的临时账号。
d、设备限制
包括特定设备限制，或者设备数量限制。如果是高级别的安全性需求，登录设备可能需要先进行安全登记，才允许登录。设备数量限制通常是作为付费增值服务，比如印象笔记，免费用户最多只允许在两个设备上同时使用。
e、客户端限制
客户端限制通常使用的较少，BS应用使用任何浏览器都可以登录。笔者仅在企业邮箱中见过类似限制，Google企业邮箱如果需要使用foxmail类的第三方邮件客户端进行收发邮件，仅知道账号密码是不够的，还需要从Google Mail后台，生成一个实时动态密码进行验证才行。
f、地理位置限制
登录的地理位置限制，比如只能在工厂范围内。
g、网络限制
网络限制通常是企业的内网和外网限制，应用和数据只能通过企业内网访问。在一些公安、军工类安全级别高的场景下，设备被人为接入外网后，还会立即发出警报。
④数据权限
一般业务管理系统，都有数据私密性的要求：哪些人可以看到哪些数据，不可以看到哪些数据。
简单举个例子：某系统中有销售部门，销售专员负责推销商品，销售主管负责管理销售专员日常工作，经理负责组织管理销售主管作业。如下图：
按照实际理解，‘销售专员张三’登录时，只能看到自己负责的数据；销售主管2登录时，能看到他所领导的所有业务员负责的数据，但看不到其他团队业务员负责的数据。
换另外一句话就是：我的客户只有我和我的直属上级以及直属上级的领导能看到，这就是我理解的数据权限。
要实现数据权限有多种方式：
1、可以利用RBAC1模型，通过角色分级来实现。
2、在‘用户-角色-权限’的基础上，增加用户与组织的关联关系，用组织决定用户的数据权限。
具体如何做呢？
a、组织层级划分
b、数据可视权限规则制定
上级组织只能看到下级组织员工负责的数据，而不能看到其他平级组织及其下级组织的员工数据等。
通过以上两点，系统就可以在用户登录时，自动判断要给用户展示哪些数据了。
七、用户组的使用
当平台用户基数增大，角色类型增多时，如果直接给用户配角色，管理员的工作量就会很大。这时候我们可以引入一个概念“用户组”，就是将相同属性的用户归类到一起。
例如：加入用户组的概念后，可以将部门看做一个用户组，再给这个部门直接赋予角色（1万员工部门可能就几十个），使部门拥有部门权限，这样这个部门的所有用户都有了部门权限，而不需要为每一个用户再单独指定角色，极大的减少了分配权限的工作量。
同时，也可以为特定的用户指定角色，这样用户除了拥有所属用户组的所有权限外，还拥有自身特定的权限。比如创建一个用户组为运营部，小A和小B都是其中一员，那么我们给用户组设置好部门基本权限即可，把小A和小B添加进来即可获得相关权限，但是小A级别较高，那么我们就可以单独给小A添加权限。
用户组的优点，除了减少工作量，还有更便于理解、增加多级管理关系等。如：我们在进行组织机构配置的时候，除了加入部门，还可以加入科室、岗位等层级，来为用户组内部成员的权限进行等级上的区分。
八、结语
对于RBAC模型，不论再多变，再多的规则和限制，都离不开用户—角色—权限，我们要做的是在我们的应用场景中找到最适合自身产品的最简单权限体系；本篇内容就到这里，下一篇我们将继续探讨如何快速创建用户角色权限体系，让用户的学习成本更低，权限逻辑更简单流畅。
以上是关于ToB产品权限系统设计（一RBAC模型）的主要内容，如果未能解决你的问题，请参考以下文章