分享到: 分享到QQ  分享到Twitter

作者: BigLoser    访问次数: 186 创建时间: 2022-12-07 16:08:39 更新时间: 2024-03-29 04:18:53

三分钟了解RBAC模型

 

RBAC 是 Role-Based Access Control 的缩写,含义为基于角色的访问控制模型,此模型是 20 世纪 90 年代在美国第十五届全国计算机安全大会上提出的,后逐步被业界广泛使用,至 2004 年形成了 ANSI/INCITS 标准。时至今日,RBAC 访问控制模型已经渗入 IT 领域的多个方面,有传统技术方面的操作系统、数据库、中间件 Web 服务器,有新兴技术方面的 Kubernetes、Puppet、OpenStack 等。RBAC 访问控制模型能得到如此丰富而广泛的使用,得益于它基于用户与角色关系分配权限进行访问控制的核心理念。

 

1、RBAC 模型相关概念

 

一家企业或组织中存在着多个不同的角色,不同的角色做着不同的事情。RBAC 模型的核心理念是,为企业或组织创建多个角色,每一个角色分配特定的权限,再给企业中的成员分配特定的角色。通过管理成员角色的方式来管理权限,大大简化了操作的难度。

 

在 RBAC 模型中,定义了三条主要规则,其基本含义如下。

 

  • 角色分配:是指只有为某个用户(用户是指真实自然人或应用程序)分配了该角色后,才具有该角色对应的权限。

  • 角色授权:对应于安全设计原则中的最小特权原则,即用户被授予某个角色之后,仅能完成所授予权限内的活动。

  • 权限授权:是指仅当某个角色被授予权限后,该角色被分配的用户才具有此角色所授予的权限。

 

这三条规则之间,构成了一个用户→角色→权限的关系链,这个链上的任何一个环节出了问题,均无法完成正确的授权访问,这是 RBAC 模型的核心授权思路。用户、角色、权限这三者的关系用 E-R 图表示。

 

 

在这三者关系中,一个用户对应多个角色,同样,一个角色也可以分配给多个用户;一个角色可以分配多个权限,同样一个权限可以分配给多个角色。它们之间,都是多对多的关系。

 

为了满足业务发展的需求,RBAC 模型在上述核心授权思路上做了相应的拓展,被称为 RBAC1、RBAC2、RBAC3。

 

  • RBAC1 模型主要增加了角色继承的概念,很多业务场景中,角色存在上下级关系。比如银行业务中省行的行长和地市分行的行长之间的关系、大型集团公司业务中大区经理和片区经理之间的关系;

  • RBAC2 模型主要增加了责任分离关系,面向授权访问添加了诸多约束,这也是为了满足业务的需要。比如在企业内部,出纳和会计是两个不同的角色,这两个角色如果由一个人来担任,则可能会出现资金流失而无人知晓的情况,所以在 RBAC 模型实现时,通过授权约束,限制同一个人被授予出纳和会计这两个角色,以规避风险;

  • RBAC3 模型是 RBAC1 和 RBAC2 的组合,既添加了角色继承,又有访问控制约束,以满足更加复杂的业务需求。

 

在实际的互联网应用中,大多数场景下 RBAC3 能满足业务需求,但随着近些年数据安全监管和业务风控的需要,很多企业在 RBAC3 的基础上做了进一步的延伸。

 
2、RBAC3 模型技术实现

 

在调用 API 的可视化组件中,最常见的是前端 Web 页面。通常来说,一个前端 Web 页面包含以下元素。

 

  • 模块:是指多个业务功能相近的功能组合,比如用户管理模块中有用户注册、用户信息修改、用户注销、用户锁定等。

  • 菜单:通常对应某个具体的业务功能页面,有上级菜单和子菜单的区别。

  • 按钮:是指页面上的操作按钮,比如新增按钮、修改按钮、删除按钮等。

  • 链接:页面主体部分显示的除按钮外需要进行访问控制的超链接。

  • 数据:页面显示的业务数据、资源、文件等。

 

Web 应用程序通过以上元素的不同组合,融合不同的业务流程,完成所支撑的业务功能,这里离不开授权与访问控制。一个模块,可能员工 A 具有操作权限,而员工 B 不具有操作权限;一个菜单,员工 A 具有部分上级菜单的操作权限,而员工 B 可能具有所有子菜单的权限;一个页面上的多个按钮,可能员工 A 具有新增权限,而员工 B 具有审计和查询权限;同一个页面上的链接,当员工 A 和员工 B 打开时,显示的数据是完全不一样的,比如员工 A 显示的是北京地区的数据,而员工 B 显示的却是上海地区的数据。这些场景的授权与访问控制过程在 RBAC3 模型都有着对应的解决方案。

 

RBAC3 模型的拓展主要是在原 RBAC3 模型的基础上增加了数据维度的授权与访问控制,结合这套模型的概念模型,下面来看看它的具体实现。

 

 

RBAC3 核心模型

 

其主要的区别在于权限以下的建模,将所授予的权限按照功能权限和数据权限进行拆分。

 

RBAC3 拓展模型

 

功能权限主要对应于功能菜单,通过分配功能菜单,再由菜单去关联其中的按钮和链接;而数据权限是通过数据维度去控制,先分配数据维度,再关联数据维度所分配的数据范围。在实际业务中,经常会遇到这样的场景,比如某个银行柜员角色只能看到它所在地区的、部分渠道的信息,假设地区是北京,渠道是电话客服和在线客服,那么此处的数据权限包含两个维度,一个是地区,一个是渠道;地区的数据范围是北京市所有网点,渠道的范围是电话客服和在线客服接入的业务。这就是数据维度和数据范围对于访问控制的作用。对于非用户参与的 API 接口的访问也是如此,通过功能级权限可以限制 API 的调用和访问,通过数据级权限控制可以防止过度的接口数据响应。

 

当然在实际的业务中,数据库建模往往更为复杂。比如通过角色对象中父子 ID 的关联,构建上下级角色关系;通过权限组,构建组内多个权限之间的互斥、依赖、包含等关系;定义按钮实体为枚举类型,减少冗余的关联关系数据等,这都是要系统设计人员根据实际业务情况去考量的。

季度最有价值文章

月度最有价值文章

投票统计

是否原创: 0 %

0 % Complete (success)

是否有价值: 0 %

0% Complete

是否有素质: 0 %

0% Complete (warning)

是否合法: 0 %

0% Complete

   群组工具

   外部链接