权限模型剖析优化实例1

权限管理，从IT层面来讲，便是在用户和权限（点）之间建立联系。在业界接受度较高的功能权限模型是——RBAC（Role-Based Access Control）模型，其基本理念是将「角色」这个概念赋予用户，在系统中用户与权限之间通过角色进行关联，以这样的方法来实现灵活配置。

但在更复杂的业务系统中，仅仅引入“角色”,还无法完全满足权限控制的需求。下面，我将在基础RABC模型的基础上，谈谈我所接触到的某IT系统中的业务变种。

---

一、IT系统权限模型概览

这是加入“群组（用户组）”和“数据范围”两个对象之后的权限模型。

用户除了与角色建立关联，还同时与数据范围建立关联。数据范围内包含产品组织等维度，以此来约束某个业务对象操作的数据。

群组也可以与角色和数据范围建立关联，然后再将用户与群组关联。多一层关联关系。

那么，为什么需要额外引入这两个对象呢？其对应的业务需求又是如何？最终在该套权限模型下，解决了哪些问题？又带来了哪些坑呢？下面一一道来。

二、基本的RBAC模型的优劣

这是一个很简洁明了的模型，以角色为中介，由运维人员一次性配置角色，经业务人员多次使用。角色在这里是赋予了业务含义的权限集，将权限按业务属性分门别类梳理好。只需给用户关联少量角色即可。业务人员管理方便直接。

但是，当这个IT系统的业务规则异常复杂，用户群体因其业务属性，只需使用IT系统中的一小份功能时，这套模型就无法支撑了。

当IT系统中的功能不断增长，各子模块下权限点不断暴增，运维人员也hold不住了。试想一下，整个系统中，存在上千个业务对象，上万个权限点信息，运维人员还能够准确地配置出业务人员想要的角色吗？

三、为什么引入群组对象

面对浩如烟海的权限点，（各个子模块）运维人员也只能做到IT层面的权限梳理，将权限点根据业务对象或模块进行局部梳理。因此，往往上线一个新的页面或功能，便会相应产生几个角色。到了这里，角色仅仅是权限集的含义了。

因此，我们需要重新定义业务层面的角色了，我们使用群组来履行这个功能。我们的业务人员（产品经理）根据调研实际用户场景，规划出几十上百个标准的业务角色。群组便是业务角色的载体。

然而这并没有结束。现实中需求实在有些个性——这些角色是在项目下使用，不同项目下涉及的业务也有所不同。于是乎，项目下的角色并不完全相同，相同的角色其权限也有所不同。因此，我们的群组，同时由业务角色和项目做卷积而生成。

四、群组的产生

群组，在这里，已经不再是IT系统类的基础数据了，它是业务角色在项目层面上的实例化。

那么，如何做到自动生成群组呢？这里便有了业务角色模板。

针对不同的项目属性，规划出合适的业务角色模板。每当产生一个新的项目空间时，根据自己的项目属性去匹配满足条件的业务角色模板，以“多继承”的方式从业务角色模板中实例化项目下的业务角色。

五、数据范围的产生

数据范围作为数据权限的一种存在，用于过滤数据。项目之外，还有部分子模块不是在项目维度下运作的，而是有他们自己的维度，组织产品等。这部分子模块所需要的角色不用那么复杂，但他们的数据维度却更加自定义。于是同样出现了可动态新增的数据范围。

六、现有权限模型分析

现有权限模型解决了哪些问题？引入了哪些坑？

现在的权限模型同时支持两种模式。一种是采用的系统角色+群组的方式以应对繁多的功能权限；一种是采用系统角色+数据范围的方式以应对多样化的数据权限。前者的权限由业务角色和项目确定；后者的权限由系统角色和数据维度决定。前者会因为项目的新增而不断增加群组对象；后者会因为数据维度的添加而按需生成的数据范围对象。前者将项目放在群组里是因为项目是业务主体；后者将其他业务维度放在数据范围是为了满足维度可按需可选新增。

这样来看，现有的权限模型达到了想要的业务需求。

但其背后的问题却也是不可忽视的。

角色的自定义在业务角色模板配置时体现，前台用户无法自定义角色。而业务角色模板太复杂，为不同场景手工配置多套业务角色模板。在后台维护方面，太厚重。

新增了一个功能模块，需要新增系统角色或修改系统角色，新增系统角色时，往往需要对所有业务角色模板进行修改。一段时间后回过头来看业务角色模板，会发现规则异常繁琐，动则数千条关联规则。易新增，难梳理。

平台规划的业务角色为何都做不到统一？真正有定制角色需求的用户却不能做角色定制！

七、为啥需要多个业务角色模板呢？

其业务需求是希望平台可以定制不同场景下的项目中业务角色。往后再倒退一步，为什么需要定制不同场景下的项目的业务角色呢？

举个例子：某个功能是为PM（项目经理）开发的，但其使用范围只在中国片区，我们便限制只在中国区的项目下的PM角色拥有这个权限。

然而，我从这个例子中看到了一点功能权限和数据权限杂糅的影子。为何我们不只把这个功能权限绑在角色上呢，这个功能页面的入口（呈现方式如菜单、按钮）再通过数据维度控制，或者根本不用控制。

用户通过非正常途径使用了该功能：如直接通过url访问功能页面，或用接口直接访问。我们也能用数据范围来保护数据。（非指定场景的项目下的指定角色进行访问时，因为该功能本身便不是为其开发的，对应的数据理应是不存在的（在我们的例子中是这样的）。如果存在，那说明本身也不应该做场景上的限制。）

通过上文的辩证分析，我们尝试着将业务角色模板化为一套固定的。在所有项目下，同一个业务角色都是一样的权限点。对于场景限制的业务需求，我们通过其他的IT方案如“数据范围”实现。

在数据维度的限制上。对于菜单的呈现，我们可以通过菜单项里配置各个项目属性维度以过滤显示；对于按钮的呈现，属于具体页面的开发，在开发过程中就应按需呈现，（情况极少）；对于直接url进入，页面内请求后台数据时自行做数据过滤。（以上限制，在存量的方案中，实际本就并没有考虑相应的措施）

八、前台用户的角色自定义

在之前多业务模板的模式下，其实并没有很好的满足一线用户对业务角色的定制要求。相比较与其他to C的IT系统，这里的角色更个性化。其角色的定义并不是至上而下的，而是通过用户需求产生的。业务人员也早有将角色定制由后台的业务角色模板改到前台项目PM做角色定制的打算。

延续前面的分析。我们在一套标准的业务角色模板下，卷积各个项目做群组实例。然后以标准业务角色的权限为基础由前台用户进行自定义裁剪。即权限最大的业务角色对其他角色进行权限裁剪。

九、总结

1、该IT系统的两套权限管理模式：用户——群组（项目X业务角色）——系统角色；用户——（系统角色X数据范围）

2、现有模型问题：IT框架问题：多套业务角色模板很鸡肋且不可靠；运维问题：系统角色混乱不清。

3、现有管理问题：从权限点到用户，中间经历了权限点到系统角色（关联1），系统角色到群组（关联2），群组到用户（关联3）三层关联。关联1由开发人员完成，关联2由运维人员维护N套模板，关联3由业务人员配置使用。层级复杂，三方人员各自为政。

4、IT优化：统一业务角色模板，项目属性维度的权限控制，以数据权限的思路控制；支持一线用户对业务角色的定制需求。

---

//ps.公众号内观看，效果更佳哟。

“HappyYoung_wx”