En 400-6655-581
5
返回列表
> 资源中心 > 技术干货 | 企业信息系统统一权限管理2:基于角色的权限实践

技术干货 | 企业信息系统统一权限管理2:基于角色的权限实践

2020-04-10浏览次数:897

上一篇文章技术干货 | 企业信息系统统一权限管理,我们对企业信息系统统一权限及基于角色的权限模型(RBAC)进行了探讨,而这一篇文章,我们将继续沿着这条思路,给大家进一步的分享企业如何基于角色的权限访问控制模型(RBAC)来做统一权限管理


基于角色的权限访问控制


上一篇文章,我们提到企业为了解决权限管理复杂,以及系统权限设计的异构性等问题,通过在用户和权限之间设计了角色,构建起“用户-角色-权限”的授权模型,来增加权限管理的灵活度,实现用户的角色的身份可以随着场所的不同而发生改变的难题。



上次我们只是对基于角色的权限访问控制中的RBAC 0进行了探讨,在RBAC家族里还有RBAC 1、RBAC 2、RBAC 3其余三种控制模型。


RBAC 1


相对于RBAC 0模型,RBAC 1引入了角色分层的模型,增加了???,引?了继承概念,即???可以继承???的所有权限。



例如:企业里的销售部?,有销售总监、销售经理、销售专员,销售专员可以查看自己的商机和客户;销售经理可以看自己的商机和客户,并可以看下辖销售专员的商机和客户;销售总监可以查看所有的商机和客户。简单点理解就是,销售经理的权限不能?于销售总监,销售专员的权限不能?于销售经理,这种情况,如果采?RBAC 0权限模型,极可能出现分配权限失误,最终出现经理拥有总监都没有的权限的情况。 


?RBAC 1模型就很好解决了这个问题,创建完总监??并配置好权限后,经理??的权限继承总监??的权限,并且?持在总监权限上删减经理权限。 


RBAC 2


相对于RBAC 0模型,RBAC 2增加了对角色的限制条件,引入了SSD(静态职责分离)和DSD(动态职责分离)的概念。



静态职责分离(SSD)主要是应用于用户和角色之间的,主要是影响授权阶段对用户可授权的角色进行约束:


1.??互斥:同??户不能被授予互斥关系的??,这里的互斥??是指权限互相制约的两个??。例如:一个信息系统的管理员角色、安全员角色、审计员角色要相互独立,不能兼任;一个企业财务系统中,?个?户不能同时被指派给会计??和审计员??。


2.基数约束:一个用户拥有的角色是有限的,一个角色拥有的许可是有限的,它指的是有多少?户能拥有这个??。例如:一个企业往往只会有一个董事长,而系统中董事长这个角色就需要被基数约束,它的基数值为1,只能有1个用户被授予为董事长角色。


3.先决条件约束:一个角色想要分配高级权限,那它必须要先得到低级权限。例如:一个用户要先有副总经理的权限,才能被授予总经理的权限。


动态职责分离(DSD)主要是应用于会话和角色之间的,主要是影响使用阶段对用户进行约束,对用户所授权的角色进行限制。例如某个用户被授予集团副总经理和分公司总经理两个角色,我们在运行时只能激活一个角色,不能同时激活。


RBAC 3


RBAC 3被称为统?模型,它包含了RBAC 1和RBAC 2,利?传递性,也把RBAC 0包括在内,综合RBAC 0、RBAC 1和RBAC 2的所有特点。




基于角色的统一权限实践


当企业在进行基于角色的权限管理的时候,我们应该以哪种方式进行推进,应该按照哪种步骤进行呢?


在经过了大量的基于角色的统一权限项目实践,我们在做基于角色的统一权限时,可以简单理解其本质是对企业整个信息化系统角色的统一,通过统一角色来实现统一权限管理。我们往往会按照以下步骤进行:



① 业务组织架构梳理:对企业业务组织架构进行梳理,并在应用系统中进行还原,在应用系统中建立起对应的组织架构,最终实现应用系统的业务场景还原,建立起“岗位-角色”的对应关系。


② 角色运营体系建立:我们在对业务组织架构梳理的同时,还需要建立起角色的运营体系,我们需要明确的是角色的梳理、角色的确立不是一蹴而就的,而应该是循序渐进逐步完善的。企业在建立角色运营体系时,需要从整体上考虑,把信息部门、人事部门、业务部门等都纳入运营体系中,各司其职。


③ 标准角色梳理:对企业现有岗位职能进行抽象和拆分形成一套职能角色,职能范围颗粒度细于人事岗位,通过一人多角色解决岗位职责大于角色,用户兼职等问题。


④ 标准角色运营:当企业初步完成标准角色的梳理后,我们需要对标准角色进行持续的运营。在运营过程中,我们首先要明确工作职能场景所对应的角色修订规则,例如什么场景进行角色新增、什么场景进行角色修订等等;其次还要明确标准角色的运营流程,例如以周为单位,周一下发最新版角色信息,周一到周四收集角色修订意见并审核下发至各业务系统,周四到周日在业务系统中进行配置调整,周一又下发新一版角色信息,以此循环。


⑤ 员工角色信息自我完善:我们在进行标准角色的确立、修订过程中,员工的参与是不可缺失的,一方面员工可以通过自身的使用对标准角色信息提出修订意见;另一方面员工也可以根据自身的工作职责新增角色。后续,这里我们往往会和流程系统对接,员工自助提出角色新增申请,通过业务部门、信息部门审批完成后自动添加。


⑥ 角色系统权限表:当我们建立标准角色与岗位的对应关系后,我们会根据岗位在系统中的权限梳理出一张,“角色-系统权限”对应表,实现角色权限标准化梳理。


⑦ 业务系统改造:当我们前面的梳理工作完成,建立起角色系统权限表以后,我们就需要对业务系统进行改造以实现角色的统一,最终系统相关权限设置在“系统角色”上,“系统角色”直接关联“标准角色”,“标准角色”再关联到用户组、部门、岗位、人员,以实现企业基于角色的统一权限管理。


总的来说,企业在构建统一权限管理时,难免会在系统业务上做一些差异化的业务考量,所以完全遵循RBAC模型是很难的。而RBAC对企业来说,是一种权限管理的模型,更多的是一种权限管理的思想,就思想而言,不是要你完全遵照,而是你在这个基础之上,融入企业的自身特点,赋予企业的业务之上,适用于企业业务即可。


同时,从我们以往的实践经验来看,如果企业能够通过IAM平台进行统一权限管理,是一种比较容易落地的方式。整个企业通过IAM进行人员、标准角色的管理,并对下游应用系统进行统一供给,而下游应用系统只需要梳理系统角色与标准角色的对应关系即可,最终通过IAM平台和业务系统之间标准角色的传递实现企业全局化的统一权限管理