在B端和后台系统中，经常会用到权限设计。这篇文章，作者帮我们梳理了权限系统的类型、模型，希望能帮到大家。
这段时间在梳理公司的角色权限关系，为了设计更加合理，我对角色权限系统进行系统化的学习和整理，以下将我的整理结果，和大家分享一下。
权限管理是所有后台系统的都会涉及的一个重要组成部分，主要目的是对不同的人访问资源进行权限的控制，避免因权限控制缺失或操作不当引发的风险问题，如操作错误，隐私数据泄露等问题。
在企业的权限管理中，通常有两类权限，一类是页面/应用的访问权限，一类是数据权限
产品的权限由页面、操作和数据构成，页面与操作相互关联，必须拥有页面权限，才能分配该页面下对应的操作权限。
其中：
对象指赋予权限的人、角色、用户组、组织、岗位
1）人
某个人拥有某个权限，在公司规模比较小的时候，可以简单设置哪些人可以看到哪些权限，维护成本不高；若只绑定人而不绑定角色的弊端：
2）角色
当公司规模较多时，有可能一些人控制某个模块的权限，这时候就需要引入角色的功能，把这些人绑定到一个角色里，再把角色赋予权限，这样就可以清晰的看见模块权限对应哪些角色，解决用户数量大的情况下，用户分配权限繁琐以及用户—权限关系维护成本高的问题，节省了大量的资源。
3）用户组
用户组是将具有相同属性的用户组合在一起，用户组是一群用户的组合，而角色是用户和权限之间的桥梁。
如果一批用户需要相同的角色，我们也需要逐个为用户分配角色。
例如，一个公司的客服部门有500多名员工。某一天，研发部门开发了一套后台数据查询产品，所有客服人员都需要使用。然而，由于之前并未统一为所有客服人员分配一个角色，现在需要新增一个角色，将权限分配给该角色，然后再逐个将角色分配给客服人员。发现为500名用户逐个添加角色非常繁琐。然而，客服人员具有共同属性，因此我们可以创建一个用户组，所有客服人员都属于该客服用户组，将角色分配给客服用户组，这样该用户组下的所有用户便拥有了所需权限。
用户可以进行分组，这有助于简化用户与角色之间的对应关系；用户可以分组，权限也可以分组。
在权限特别繁多的情况下，可以将一个模块的权限组合成一个权限组，这有助于简化权限和角色之间的对应关系。
4）组织
每个公司内部均构建有其独特的组织架构，而在实践中，权限分配常常会依据这一架构进行细化划分。
其原因在于，同一组织单元内的成员通常需要执行相似的工作职能，因而对权限的需求大体一致。
遵循公司的组织架构，同一组织内成员所配备的基础权限往往具有较高的一致性。
按照组织架构来设定角色并分配权限的做法，实际上包括以下两个优势：
① 实现权限分配的自动化
实现组织关系与权限系统的深度融合后，对于新入职员工，只需将其归入相应的组织单元，其角色权限便会自动继承该组织下的所有权限设定，无需逐一进行人工分配。
同样，当员工发生岗位调动时，仅需对其组织关系作出相应调整，权限配置将随之联动更新，全程无须人工介入。
此方案的实施首要前提是实现权限体系与组织结构间的有效对接。
② 控制数据权限
通过将角色与特定组织紧密关联，确保该组织成员仅能访问其所属组织层级内的数据，各部门成员仅能查看与自身组织直接相关的数据，实现了跨部门数据的隔离与保护。
5）岗位
一个组织下面会有很多职位，比如财务管理会有财务总监、财务主管、会计、出纳员等职位，每个职位需要的权限是不一样的，可以像组织那样根据职位来分配不同的角色
级别也称账号安全级别，一般通过0-100的数字控制用户账号的功能权限，通常设置的数值越大，权限范围越大。
适用场景：比如创建的正式员工默认安全级别为10，外包员工默认为0，则当某个功能开放给所有人，并且这个功能仅限正式员工可操作时，可通过限制此功能的安全级别（调整为10）控制只能正式员工查看。
功能组合：安全级别还可与对象（组织、角色、岗位、人、用户组）组合，达到更精细化控制权限的目的，比如安全级别与部门相搭配，可控制此部门下特定的安全范围的人可以操作功能。
权限中的时间是指数据到达某个时间节点后，是否要继续给用户查看，应用场景：比如外部人员需要查看某一年度的数据时，只需开放对应时间的数据给他们，这么做就可以保证数据的安全，不会遭到泄露。
权限中的区域也可以理解为范围，是指某一区间的值，可以对区域范围内的数据进行查看，应用场景：比如共享单车的运维人员只需查看他所负责的区域的车辆数据即可
菜单权限一般分为前端菜单权限和后端菜单权限。前端菜单权限是指用户层面操作的菜单页面，后端菜单权限是指系统管理员、系统运维人员层面操作的菜单页面。
对于员工从原部门调走，离职等情况的发生，当有新员工接手他的工作时，则需要权限转移的功能。
转移的内容一般为角色、菜单，更精细化的内容还可以分为下属、待办、已办、文档等，如果是CRM系统，还可以转移他的客户等。
–简单清晰但无法承载复杂的需求
基础权限系统的设计，一般都是从「用户-权限」这两个纬度开始的，管理员需要为每一个用户单独定义权限。
如果系统中用户数在几十个上下，权限变动也不太多时，这种「用户-权限」的权限管理逻辑简单清晰，很好用。
但当系统中用户开始增多，到达上千、上万时，此种管理方法的局限性就暴露出来了：
1）RBAC0
RBAC0是基于角色的访问控制的完美体现，也就是把权限赋予角色，然后再把角色赋予用户，在这个模型中，角色起到了连接用户和权限关系的桥梁作用。
每个角色可以拥有多个权限，每个用户可以被分配多个角色，从而使用户具备多个角色的多个权限。
在对角色权限系统进行设计时，只需给对应的角色配置系统中的权限（菜单/操作/字段），完成角色创建后，再将角色赋予系统用户即可。
这样在用户登录后，就能获取该用户的所属角色，然后通过角色来找到拥有的权限，再加载对应的权限资源。
一般来说包含菜单管理、用户管理、角色管理等功能页面
菜单管理：对页面进行配置，与访问路径映射，填写菜单路径，设置页面顺序，方便访问
用户管理：对用户进行管理，给用户赋予角色
角色管理：对角色进行管理，给角色分配权限
2）RBAC1–引入继承的概念
如果一个部门人员很多，如一级部门向下还有二级部门，二级部门向下才是员工，这样就导致如果采用RBAC0模型进行权限管理的话，则很有可能错配权限的问题。
角色继承的RBAC模型又称RBAC1模型，在角色继承的RBAC模型中，上层角色会继承下层角色的所有权限，并且可以额外拥有其他权限。下级角色的权限上级角色都具备，并且上级角色可以拥有其他权限
RBAC1模型相较于RBAC0模型增加了角色继承的概念，有了角色继承就有父子的关系，即子角色可拥有父角色的权限。
在配置角色的时候可以增加父角色的选择，可在父角色的基础上进行删减权限，以避免错配权限的问题。
3）RBAC2–添加责任分离关系
RBAC2模型是RBAC0的另一变种，对用户、角色和权限三者之间增加了一些限制。这些限制可以分成两类，即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。
① 静态职责分离
② 动态职责分离
4）RBAC3–基于RBAC0、RBAC1和RBAC2进行整合
为了数据权限控制的灵活度，在角色管理中还可以设置角色的数据权限范围
作者：诺儿笔记本，公众号：诺儿笔记本
本文由 @诺儿笔记本 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。