为什么需要权限管理

日常工作中权限的问题时时刻刻伴随着我们，程序员新入职一家公司需要找人开通各种权限，比如网络连接权限、代码下载提交权限、监控平台登录权限、运营平台查数据的权限等等。在很多时候我们会觉得这么多繁杂的申请给工作带来不便，并且如果突然想要查一些数据，发现没有申请过权限，需要走审批流程，时间会拉得很长。那为什么还需要这么严格的权限管理呢？

举个例子，在一家支付公司有运营后台，运营后台可以查到所有的商户信息，法人代表信息，交易信息以及费率配置信息，如果我们把这些信息不加筛选的给到公司的每一个小伙伴，那么跑市场的都可以操作商家的费率信息，如果一个不小心把费率改了会造成巨大的损失。又比如商户的信息都是非常隐秘的。有些居心不良的小伙伴吧这些信息拿出来卖给商家的竞争对手，会给商家造成严重的不良后果。虽然这么做都是个别人的人为过错，但是制度上如果可以保障这些信息不随便公开，就能在很大程度上避免违法乱纪的事情发生了。

总的来讲权限管理是公司数据安全的重要保证，针对不同的岗位，不同的级别看到的数据是不一样的，操作数据的限制也是不一样的。比如涉及到资金的信息之开放给财务相关岗位，涉及到配置的信息只开放给运营相关岗位，这样各司其职能避免很多不必要的安全问题。如何让各个岗位上的人在系统上各司其职，就是权限管理需要解决的问题。

 

权限模型

• 权限设计

从业务分类上来讲权限可以分为数据查看权限，数据修改权限等，对应到系统设计中有页面权限、菜单权限、按钮权限等。菜单也分一级菜单、二级菜单甚至三级菜单，以 **** 文章编辑页面左侧菜单栏为例是分了两级菜单。菜单对应的页面里又有很多按钮，我们在设计的时候最好把权限设计成树形结构，这样在申请权限的时候就可以一目了然的看到菜单的结构，需要哪些权限就非常的明了了。如下图所示：

按照这个架构，按钮的父级是二级菜单，二级菜单的父级是一级菜单，这样用户申请权限的时候非常清晰的看到自己需要哪些权限。

 

• 为什么需要角色

权限结构梳理清晰之后，需要思考怎么把权限分配给用户，用户少的情况下，可以直接分配，一个用户可以有多个权限，同一个权限可以被多个用户拥有，用户-权限的模型结构如下所示：

 

这种模型能够满足权限的基本分配能力，但是随着用户数量的增长，这种模型的弊端就凸显出来了，每一个用户都需要去分配权限，非常的浪费管理员的时间和精力，并且用户和权限杂乱的对应关系会给后期带来巨大的维护成本。用户-权限对应关系图：

 

 

这种对应关系在用户多的情况下基本无法维护了。其实很多用户负责同一个业务模块所需要的权限是一样的，这样的话我们是不是可以借助第三个媒介，把需要相同的权限都分配给这个媒介，然后用户和媒介关联起来，用户就拥有了媒介的权限了。这就是经典的RBAC模型，其中媒介就是我们通常所说的角色。

 

• 权限模型的演进

RBAC 模型

有了角色之后可以把权限分配给角色，需要相同权限的用户和角色对应起来就可以了，一个权限可以分配给多个角色，一个角色可以拥有多个权限，同样一个用户可以分配多个角色，一个角色也可以对应多个用户，对应模型如下所示：

 

 

这就是经典的RBAC模型了（role-based-access-control），在这里面角色起到了桥梁左右，连接了用户和权限的关系，每个角色可以拥有多个权限，每个用户可以分配多个角色，这样用户就拥有了多个角色的多个权限。同时因为有角色作为媒介，大大降低了错综复杂的交互关系，比如一家有上万人的公司，角色可能只需要几百个就搞定了，因为很多用户需要的权限是一样的，分配一样的角色就可以了。这种模型的对应关系图如下所示：

 

 

用户和角色，角色和权限都是多对多的关系，这种模型是最通用的权限管理模型，节省了很大的权限维护成本， 但是实际的业务千变万化，权限管理的模型也需要根据不同的业务模型适当的调整，比如一个公司内部的组织架构是分层级的，层级越高权限越大，因为层级高的人不仅要拥有自己下属拥有的权限，二期还要有一些额外的权限。RBAC模型可以给不同层级的人分配不同的角色，层级高的对应角色的权限就多，这样的处理方式可以解决问题，但是有没有更好的解决办法呢，答案肯定是有的，这就引出角色继承的RBAC模型。

 

角色继承的 RBAC 模型（RBAC1）

角色继承的RBAC模型又称RBAC1模型。每个公司都有自己的组织架构，比如公司里管理财务的人员有财务总监、财务主管、出纳员等，财务主管需要拥有但不限于出纳员的权限，财务总监需要拥有但不限于财务主管的权限，像这种管理关系向下兼容的模式就需要用到角色继承的RBAC模型。角色继承的RBAC模型的思路是上层角色继承下层角色的所有权限，并且可以额外拥有其他权限。模型如下所示：

 

 

从模型图中可以看出下级角色拥有的权限，上级角色都拥有，并且上级角色可以拥有其他的权限。

 

带约束的 RBAC 模型（RBAC2）

 

带约束的 RBAC 模型又成 RBAC2 模型。在实际工作中，为了安全的考虑会有很多约束条件，比如财务部里同一个人不能即是会计又是审核员，跟一个人同一时间不能即是运动员又是裁判员是一个道理的，又比如财务部的审核员不能超过2个，不能1个也没有。因为角色和权限是关联的，所以我们做好角色的约束就可以了，常见的约束条件有：角色互斥、基数约束、先决条件约束等。

角色互斥：如果角色A和角色B是互斥关系的话，那么一个用户同一时间不能即拥有角色A，又拥有角色B，只能拥有其中的一个角色。比如我们给一个用户赋予了会计的角色就不能同时再赋予审核员的角色，如果想拥有审核员的角色就必须先去掉会计的角色。假设提交角色和审核角色是互质的，我们可以用图形表示：

 

基数约束： 同一个角色被分配的用户数量可以被限制，比如规定拥有超级管理员角色的用户有且只有1个；用户被分配的角色数量也需要被限制，角色被分配的权限数量也可以被限制。

先决条件约束：用户想被赋予上级角色，首先需要拥有下级角色，比如技术负责人的角色和普通技术员工角色是上下级关系，那么用户想要用户技术负责人的角色就要先拥有普通技术员工的角色。