SAAS类产品的用户权限管理方法

作者: leo 分类: 精彩设计 发布时间: 2019-01-09 13:51 ė118次查看 6没有评论

说道智能化系统,目前最火的应该是saas系统了,因为具有诸多的有点而成为目前系统的主流存在方式。

针对SaaS系统,医微达认为用户在实际使用过程中往往十分关注系统数据的安全性,而要实现数据安全性, 产品需要从平台管理员,租户等系统使用角色中实现权限及数据的隔离。因此医微达认为平台管理员只能管理租户的账号和相关信息,不能操作租户的内部业务。租户拥有自己的角色和权限,相互不能影响。不同租户的数据、服务在物理上共享,而在逻辑上完全隔离,对于每个租户来说这个系统好像只为自己服务。

解决方案

实现数据,服务隔离的核心在于实现系统的访问控制,在企业环境中维护访问控制可采用多种模型,医微达认为被广泛认可的就是RBAC模型:基于角色的访问控制。

RBAC模型认为权限控制的过程可以抽象概括为:判断【Who是否可以对What进行How的访问操作(Operator)】,即将权限问题转换为Who、What、How的问题。who、what、how构成了访问权限三元组,Who,What,How分别对应着用户,资源,操作,RBAC的核心在于通过为用户分配对应的角色进而将用户与对应的操作联系起来,已实现用户对资源的操作。

RBAC支持公认的安全原则:最小特权原则、责任分离原则和数据抽象原则。

  1. 最小特权原则得到支持,是因为在RBAC模型中可以通过限制分配给角色权限的多少和大小来实现,分配给与某用户对应的角色的权限只要不超过该用户完成其任务的需要就可以了。
  2. 责任分离原则的实现,是因为在RBAC模型中可以通过在完成敏感任务过程中分配两个责任上互相约束的两个角色来实现,例如在清查账目时,只需要设置财务管理员和会计两个角色参加就可以了。
  3. 数据抽象是借助于抽象许可权这样的概念实现的,如在账目管理活动中,可以使用信用、借方等抽象许可权,而不是使用操作系统提供的读、写、执行等具体的许可权。但RBAC并不强迫实现这些原则,安全管理员可以允许配置RBAC模型使它不支持这些原则。因此,RBAC支持数据抽象的程度与RBAC模型的实现细节有关。

RBAC是一个模型组,医微达发现其中包括RBAC0~RBAC3四个概念性模型。

基本模型RBAC0定义了完全支持RBAC概念的任何系统的最低需求。

RBAC1和RBAC2两者都包含RBAC0,但各自都增加了独立的特点,它们被称为高级模型。

RBAC1中增加了角色分级的概念,一个角色可以从另一个角色继承许可权。

RBAC2中增加了一些限制,强调在RBAC的不同组件中在配置方面的一些限制。

RBAC3称为统一模型,它包含了RBAC1和RBAC2,利用传递性,也把RBAC0包括在内。这些模型构成了RBAC模型族。

RBAC0的模型中包括用户(U)、角色(R)和许可权(P)等3类实体集合。

RABC0权限管理的核心部分,医微达发现其他的版本都是建立在0的基础上的,看一下

1.png2.png

RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。

在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素,医微达发现此模型指明用户、角色、访问权限和会话之间的关系。

每个角色至少具备一个权限,每个用户至少扮演一个角色;医微达发现可以对两个完全不同的角色分配完全相同的访问权限;会话由用户控制,一个用户可以创建会话并激活多个用户角色,从而获取相应的访问权限,用户可以在会话中更改激活角色,并且用户可以主动结束一个会话。

用户和角色是多对多的关系,医微达发现一个用户在不同的场景下可以拥有不同的角色。

例如产品经理也可以是项目项目经理等;当然了一个角色可以给多个用户,例如一个项目中有多个组长,多个组员等。

医微达在这里需要提出的是,将用户和许可进行分离,是彼此相互独立,使权限的授权认证更加灵活。

角色和许可(权限)是多对多的关系,表示角色可以拥有多份权利,同一个权利可以授给多个角色,医微达发现在现实生活中,当官的级别不同的权限的情景,其实这个模型就是对权限这方面的一个抽象,联系生活理解就非常容易了。

RBAC1,基于RBAC0模型,引入角色间的继承关系,即角色上有了上下级的区别,角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系,允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构,实现角色间的单继承。

医微达认为这种模型合适于角色之间的层次明确,包含明确。

3.png

RBAC2,基于RBAC0模型的基础上,进行了角色的访问控制。

RBAC2模型中添加了责任分离关系。医微达发现RBAC2的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可,此约束有多种。

  • 互斥角色 :同一用户只能分配到一组互斥角色集合中至多一个角色,支持责任分离的原则。互斥角色是指各自权限互相制约的两个角色。对于这类角色一个用户在某一次活动中只能被分配其中的一个角色,不能同时获得两个角色的使用权。医微达举例:在审计活动中,一个角色不能同时被指派给会计角色和审计员角色。
  • 基数约束 :一个角色被分配的用户数量受限;一个用户可拥有的角色数目受限;同样一个角色对应的访问权限数目也应受限,以控制高级权限在系统中的分配。例如公司的领导人有限的;
  • 先决条件角色 :可以分配角色给用户仅当该用户已经是另一角色的成员;对应的可以分配访问权限给角色,仅当该角色已经拥有另一种访问权限。指要想获得较高的权限,要首先拥有低一级的权限。就像我们生活中,国家主席是从副主席中选举的一样。
  • 运行时互斥 :医微达举例,允许一个用户具有两个角色的成员资格,但在运行中不可同时激活这两个角色。

4.png

RBAC3,也就是最全面级的权限管理,它是基于RBAC0的基础上,将RBAC1和RBAC2进行整合了,最前面,也最复杂的:

5.png

综上为权限管理模型的相关介绍,其实在任何系统中都会涉及到权限管理的模块,无论复杂简单,我们都可以通过以RBAC模型为基础,进行相关灵活运用来解决我们的问题。

0

本文永久链接: http://www.e-weida.com/17429.html

发表评论

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

微信二维码
全国分支机构
  • 电话:400-888-9746
  • 邮箱:医微达邮箱地址
  • 网址:www.e-wangbao.com
  • QQ:2021627922
  • 青岛总部地址:青岛市北区开封路88号百洋科技园6楼
  • 上海地址:上海长宁区长宁路1027号3308室
  • 北京地址:北京市东城区东长安街1号东方广场E1-21层

医微达攻略 |  微营销分享 |  案例分享 |  服务资费 |  了解医微达 |  友情链接