后台权限设计法三位一体

　　如何产出一个相对合理的后台权限设计？本文笔者提出了一个后台权限设计法：三位一体法——也就是＂用户+角色+组织结构=用户权限＂。
　　知乎上有个问题：＂为什么很多产品经理不愿意做后台？＂在各类回复中有一个声音：＂因为后台产品不好抄……＂
　　不可否认，前台产品和功能大都肉眼可见，存在可以借鉴的思路，而后台产品可参考的内容不多，但也正因此，我们才需要更多的后台产品设计资料。
　　最近几年自己主要负责数据平台产品与ERP等业务系统项目，这些都属于后台范畴，所以在后台设计方面，有一些自己的方式方法，本文优先将后台权限设计相关的经验分享给大家，与大家一起探讨。
　　为什么要设计后台权限
　　广义的后台包括业务系统（ERP、CRM、财务与客服系统等）、平台型产品、To B商户端以及各类App的管理后台等。
　　其中不少初创App的管理后台，一个超管账号打天下，等规模提高到需要拆分后台用户权限的时候，再对后台的改造，这几乎算是刮骨疗毒了，需要付出的代价很大。可以说越早进行后台权限设计，后续成本也就越低。
　　首先我们来看，什么是后台权限，后台权限主要由以下三部分组成：
　　页面权限：用户可以看到那些页面；
　　操作权限：用户可以在页面内进行那些操作，增删改查等；
　　数据权限：用户可以页面内看到那些数据或内容，以教培ERP系统学员管理模块为例，学员1为A校区学员，学员2为B学员，A校区相关工作人员登录系统查看学员信息，仅可查看到学员1。
　　以上三种权限组合在一起，决定了当前用户的后台权限与其可以完成那些业务流程。
　　至于为什么需要设计后台权限，或者这么说：为什么要合理的设计后台权限？
　　那是因为后台权限直接影响了系统的拓展性和兼容性，如果用户权限设计不到位，极容易出现部分后台用户权限溢出，或者后台用户出现交叉权限，出现很多人为的操作失误。
　　另外，数据权限控制不到位，容易造成数据泄露，尤其是B端系统，可能造成内部争抢客户资源等＂恶性＂斗争。
　　如何相对合理的设计后台权限
　　关于后台权限设计也有一些现行的方法，比如：RBAC模型，也就是基于角色的权限访问控制，这是一个比较常用的权限设计方法。
　　参考RBAC模型，结合这些年的工作经验，觉得可以通过以下方式实现对页面权限、操作权限与数据权限的管理，我把这种方式称作：＂三位一体法＂。
　　后台用户，承载权限的主体，也影响部分数据权限。
　　用户角色，通过对角色的管理，实现对页面与操作权限的管理。
　　组织结构，部门架构的树形结构，实现对数据权限的管理。
　　换言之，三位一体：用户+角色+组织结构=用户权限
　　1. 角色管理
　　角色是页面操作权限的集合，是一个权限集。通过对角色权限的修改，可以实现对用户权限的批量修改。
　　角色管理需要明确权限粒度（明确哪些操作需要设置权限），对于权限粒度的把控是很关键的，可以避免角色设置过于复杂。
　　对角色的修改和删除，需要考虑到对现有用户的影响，要明确这些操作的后置条件。
　　看图说话：
　　结合上图，我们大致可以明白角色管理的实现方式了。
　　下面给大家说一下这种实现方式的弊端：
　　角色设置要求高，设置角色的相关人员需要对业务足够了解，一旦出现误操作，会直接对线上用户产生影响；
　　新增功能与页面时需要对角色进行重新配置，可以手动完成，也可以自动化实现，但每次功能上线都需要将新增的功能与操作分配给对应的角色，一旦遗忘也会产生影响。
　　当角色过多时，可以准备一个角色说明文档，既可以帮助我们了解现有角色的权限，又可以减少系统管理人员离职等原因造成的工作交接困难。
　　2. 组织结构管理
　　组织结构的管理要从两个方向来实现：
　　一个是对组织结构本身的管理，也就是对部门的增删改等；另一个是需要对后台各个页面中信息进行梳理归纳，确定信息主体中存在组织结构字段。
　　（1）组织结构的实现
　　看图说话：
　　如果短期之内后台涉及部门不多，可以暂时不在后台实现该功能模块，而是通过XML配置文件的方式来实现，这样可以节省开发成本。
　　（2）页面数据的梳理归纳
　　存在了＂部门＂这个信息，怎么运用这些信息，是我们需要实现的。在需求产出期间，我们会完成项目整体的＂数据信息结构＂，可能有不少PM都没做过这个，还是举例说明：
　　用上面提到的教培ERP-学员管理模块，该模块实现的是对学员的管理，信息主体也就是学员，我们可以看一下学员的数据信息结构（部分）：
　　教培ERP里的组织结构是校区及其上级管理部门，如果当前后台用户是组织结构中的校区字段与学员的授课校区字段一致，那对应的授课校区就拥有了查看该学员信息的数据权限。
　　数据权限的管理，需要我们对后台所有模块进行分析。而且在同一个页面，可依据的字段也不单一，就像上图中的校区有签约校区和授课校区两个，实际情况中可能会有更多。
　　也就是说，可以通过多个字段实现对数据权限的管理，因此对数据权限的梳理，一定要对业务十分的熟稔。
　　3. 用户管理
　　之所以最后再写用户，是因为用户是对角色与组织结构的承载，一个图，大家也就都看明白了：
　　上图中部门=组织结构，岗位=角色。
　　如果存在多个部门岗位的权限取并集，通过上述方式实现用户权限管理。
　　一些总结的话
　　后台权限＂三位一体＂设计法适用于普遍场景，因为各种系统的实际业务场景不同，所以还会有很多的特殊场景需要处理。但只要从实际业务场景出发，参考上述权限设计的思路，应该是可以产出一个相对合理的权限设计方案。
　　关于后台权限设计还有不少需要注意的细节和小技巧，这些需要大家在实际操作过程中去发现与挖掘，另外哪怕是To C的产品也应该提高对后台的重视程度，后台产品是前台产品的支撑，在后台产品中后台权限有点像筋骨脉络，只有打通了任督二脉，才能成就绝世武功。