基于角色理论的 RBAC96 模型改进

https://kknews.cc/news/6qmr2m.html
https://patents.google.com/patent/CN107506658A/zh
https://www.coursera.org/lecture/os-virtsecurity/7-11-rbac96mo-xing-shi-ti-yu-xiang-hu-guan-xi-12-09-IRxi4

2016-09-11 电子技术应用
郭冬升,徐建良 (中国海洋大学 信息科学与工程学院,山东 青岛 266100)

摘要:在分析 RBAC96 模型的基础上,从角色概念及角色间关系的角度分析其不明确之处;通过角色理论中的可计算角色模型,改进 RBAC96 模型,使其具有更好的扩展性。

引用格式:郭冬升,徐建良. 基于角色理论的 RBAC96 模型改进[J]. 微型机与应用,2016,35(16)

随着信息管理系统面向多用户、多应用的发展,用户可以访问的数据和功能资源机构日益复杂,规模日益庞大。资源的安全性成为一个重要且亟待解决的问题。基于角色的访问控制方法(RoleBased Access Control,RBAC)是当前较为有效的资源访问控制方法,在各类信息系统中有着广泛的应用。然而传统 RBAC 模型对于角色的概念模型思考过少,不同信息系统对于 RBAC 的实现方案也不尽相同,若将传统 RBAC 模型应用于不同的信息系统中,需要增强传统 RBAC 模型的普适性。

本文首先对访问控制和 RBAC 模型的基本概念和思想进行探讨,之后详细分析 RBAC96 模型[1]中的不明确处;第 2 节介绍角色理论,并基于角色模型改进 RBAC96 模型;第 3 节对上述部分加以总结。

访问控制源于美国国防部资助的研究项目,后演化成为现在的访问控制技术。顾名思义,访问控制技术是实现访问者(主体)与资源(客体)之间存在的访问策略的一项技术,主体只有成功通过访问控制机制设下的关卡,才可获取特定的客体。访问控制策略应该满足下述最基本三个方面的控制:

(1)机密性控制:保证客体资源不被非法的读取。

(2)完整性控制:保证客体资源不被非法地增加、删除、改写,从而保证资源的一致完整性。

(3)有效性控制:保证客体资源不被非法访问主体使用和破坏。

对如今越来越复杂的信息系统而言,很多情况下使用单一的访问控制方法已经无法完全保证信息的安全。因此,实现访问控制方法必须结合其他技术,RBAC 由此而生,它结合数据完整性、数据机密性、身份验证、安全审计等技术,已成为目前广为流行的访问控制方法。

RBAC 模型于 1992 年由美国国家标准与技术研究院(National Institute of Standards and Technology)组织开发,它是一种基于角色的信息访问控制方法[2]。

在使用 RBAC 模型的信息系统中,系统不会直接对主体进行访问控制,而是判别该主体所承担的角色,通过角色的不同权限,最终确定该主体是否可以最终获取客体资源。因此,RBAC 将主体与客体之间的关系通过角色进行了分隔,每个角色在此相当于主体的一个集合,自然,一个主体可以同时对应多个角色,每种角色也可由多个主体进行承担。基于角色的访问控制方法,可以很简便地完成授权管理、赋予最小特权、根据工作进行分级、责任独立、文件分级等工作。在 RBAC 中,角色的灵活变更可以使得原先主体与客体之间的复杂关系变得简便。

RBAC 的本质是在用户与权限之间建立一个灵活的桥梁。通过用户角色分配(UA)及角色权限分配(PA),实现角色桥梁的搭建,如图 1 所示[3]。

在 RBAC 中,主要有四个实体:用户(User)、角色(Role)、权限(Permission)、会话(Session)。

(1)用户:前文中的主体,资源的访问者。一般而言,用户就是人,但是随着计算机的发展,也可以是一些智能程序。

(2)角色:可以执行特定任务或被指定拥有一定工作职能的工作头衔。它代表一种权利和责任,它根据具体的业务场景来进行划分。

(3)权限:表示用户对资源的操作许可,与具体的系统应用有关,每条权限通常代表不同的资源。

(4)会话:即某用户与角色之间的映射关系,一个用户一般情况下拥有一个或多个角色,因此该映射是一对一或一对多的关联关系。用户需要在会话中完成某个角色的激活工作,每一个会话都与某个用户关联,每个用户因其可能同时具有多个角色,因此可同时关联多个会话。

除了给定的四个基本实体,还需要定义以下概念:

(1)权限分配(Permission Assignment,PA):角色与权限之间的多对多关系的映射。

(2)用户分配角色(User Assignment,UA):用户与角色之间的多对多关系的映射。

(3)角色层次(Role Hierarchy,RH):角色与角色之间存在的等级或继承关系体现。

(4)约束条件(Constraints):判别在模型中各个操作是否被允许。

Gerorge Mason 教授 SANDHU R S 于 1996 年对基本 RBAC 模型进行改进,提出了 RBAC96 模型,并在之后的时间里很快成为了使用最为广泛的访问控制模型。

RBAC0、RBAC1、RBAC2 和 RBAC3 四个模型共同组成 RBAC96 模型族。其中 RBAC0 是其他模型的基础模型,其核心即是前文中介绍的角色作为用户与权限的关联桥梁。RBAC1 在 RBAC0 的基础上,引入了角色与角色之间的关系,根据现实人类社会的组织构造,其将角色之间的关系以角色的层级来表示,不同层级的角色通过权限继承的关系描述,即上层角色拥有其父角色的所有权限。RBAC2 即角色限制模型,其在 RBAC0 的基础上,在会话、角色分配、权限分配等各个过程中,根据实际业务需求,添加各种限制。

图 2RBAC96 内各子模型关系可以看出,RBAC1 与 RBAC2 是相互独立的模型,其在 RBAC0 模型的基础上,从不同方面对基础模型进行了扩展。结合 RBAC1 与 RBAC2 构成一个新的统一模型 RBAC3,自然统一模型也具有 RBAC0 的所有特点。这几个模型共同组成了 RBAC96 模型族,如图 2 所示。

... ...

图 3 为 RBAC3 概念示意图,该模型聚合了 RBAC0、RBAC1 与 RBAC2 三个模型。

2 角色理论与 RBAC96 改进模型

2.1 角色理论

2.1.1 角色的概念

角色的概念无处不在,它常常被认为是一种类型或是属性,角色与一般的自然类型概念不同[4]。

角色具有非常强的上下文依赖性。比如某个人在学校内担任教师的角色,而在家中担任丈夫的角色,因此对于同一人来讲,在不同上下文环境中,可能扮演不同的角色,上下文在角色的描述中占据非常重要的位置。

在这里给出角色的一个非正规定义:角色是在某个上下文环境中被某个实体扮演的实体。

角色具有以下特点[5]:

(1)角色可以被扮演和停止扮演,是动态的概念;

(2)角色的定义必须依靠外部的一些其他概念;

(3)角色依赖于定义它的上下文环境;

(4)一个实体可以扮演多个角色;

(5)一个实体可以多次扮演一个角色类型,如一个人多次扮演学生角色;

(6)一个角色可以扮演另一种角色,如美国公民角色可以扮演美国总统的角色;

(7)一个角色可以同时被多个实体所扮演;

(8)角色与所依赖的上下文的关系可能稳定也可能不稳定,如教师在睡觉时仍然是教师,而行人在睡觉时即不再是行人。

2.1.2 角色模型简述

举一个教师角色的例子来说明此模式:“在 X 高中,张三扮演了 A 教师角色,因此成为了 A 教师”,在类的层次上,可以泛化为 “在学校里,某人可以扮演教师,因此成为教师”。图 4 所示为这种关系的描述。

...

从图 4 和举例描述中,可以发现几个重要的元素:

(1)上下文:包含一系列的事物,但可以看为整体的类。

(2)角色概念:其实例可以被别的实体在某个上下文中扮演。

(3)角色拥有者:是一种依赖实体的类,角色扮演者和角色概念实例组合的抽象。它是整个角色模型的核心。

(4)潜在扮演者:指可以扮演角色概念实例的一类事物。

(5)角色扮演事物:在实例层扮演角色的实体

上面的例子进一步可泛化为 “在上下文中,潜在扮演者可以扮演角色概念,因此成为角色拥有者”。在此模型中,传统的角色扮演者被分为二部分:一是概念层的潜在扮演者,一是实例层的被扮演事物。传统的角色扮演关系被分为两种:一个是概念的可扮演,另一个是实例层的已扮演。传统的角色被分为两种:角色概念和角色拥有者,传统的角色概念隐藏了这两者的区别,正是产生概念混乱的原因。角色拥有者不允许直接实例化,因为它依赖于实体,角色拥有者的类和实例之间是用虚线箭头连接的,表示继承关系,而不是实线箭头的实例化。此模型中,一个角色概念即使不被扮演,也可以存在实例层,因为它只依赖于它的上下文,而不是扮演者。

2.1.3 角色分类

按照依赖的上下文不同,可将角色分为多个类别,最主要的有三个:关系角色、组织角色和过程角色。关系角色依赖于关系,如丈夫和妻子;组织角色依赖于某社会组织,如信息学院院长;过程角色依赖于某个过程,如项目审核人。在信息系统中,管理的角色主要包括组织角色和过程角色两类[6]。

2.2 基于角色理论的 RBAC96 模型改进

2.2.1 引入上下文环境

对于同一个角色,不同扮演者扮演时其权限往往是不同的。譬如张三和李四都扮演 “项目负责人” 角色,维护自己负责的项目,显然他们所能获取的数据权限局限于自己的项目;再譬如 “部门负责人” 角色,不同部门的负责人显然权限有所区别。因此对角色来讲,其依赖的上下文具有非常重要的意义,角色概念与其上下文环境的组合更加适合承担用户与权限之间的桥梁。新角色包括两部分,角色概念和上下文。譬如 “信息学院院长” 角色,其包括角色概念 “院长” 和上下文环境 “信息学院” 两部分,二者组合到一起可更加清晰地表现用户承担的角色。

2.2.2 权限的分析

RBAC 模型只涉及用户、角色与权限,没有对权限作进一步的思考,其实权限如何定位往往决定着整个系统在访问控制上所能做到的程度。本小节主要讨论权限粒度问题以及角色权限分配过程(PA)。权限的描述可以分为两个组成部分:资源与操作,每一条权限即是两者的组合。如 “项目” 为某一资源,“添加”为某一操作,则二者的组合即为 “添加项目” 这一权限。

信息系统中的权限可分为三个部分:界面、功能、数据,三者相辅相成。例如 “某项目负责人登录科技处管理系统查看项目信息” 这一事件,便涉及界面、功能及数据三个部分。首先,界面为该专家提供操作接口,其次该专家可以通过系统执行 “查看项目” 功能,最后获取项目数据。如何使用权限记录来描述这三者是一个亟待解决的问题。按照权限为资源与操作的组成模式,上文 “某项目负责人登录科技处管理系统查看项目信息” 的情况,可简单描述为权限 “查看项目”,其中“查看” 为操作,“项目”为资源。可见,这类简单的权限可以与数据库中的数据操作相一致,操作对应数据库的增删改查操作,数据对应数据库表,如此可以在系统中将权限关联至数据库操作,非常方便地实现访问控制,这种方案便是将权限粒度定位到数据库表的操作级别。然而对于某些权限,这种做法却是不合适的,如 “信息学院院长审核某项目立项” 这种情况,院长的审核操作可能改动项目信息、添加审核记录等,如果沿用数据库操作粒度的权限,描述这类权限显然很不方便。

由此可以考虑另一种权限粒度划分方案:根据系统业务划分。如 “信息学院院长审核某项目立项” 简单描述为“审核立项”,然而在实现这种粗粒度的权限描述中,因为其与实际业务的紧耦合性,需要将访问控制方法在业务层做处理,这对于系统的维护、扩展都是一个不小的负担。

对于信息系统而言,权限的粒度直接决定着访问控制复杂度。对于网络信息系统,比较适中的方案是将访问控制方法置于通信层,这便需要对系统权限做详细的分析,在粗粒度和细粒度的权限描述中寻求一个权限描述的合适位置。

角色权限分配过程分为静态与动态两个过程,静态过程为提前完成的角色概念与权限之间的关联,动态过程将上下文引入至权限中,以确定权限操作的对象。图 5 所示为角色权限分配过程。

...

RBAC1 角色分级模型本质上是角色之间普遍存在的继承关系的体现;RBAC2 限制模型对于角色的限制也体现了角色之间的关系,如互斥,对于不同复杂度的信息系统,所需要的限制也有所不同。改进模型将 RBAC1 与 RBAC2 融合在一体,体现了角色之间的继承与互斥关系。

2.2.4 改进的 RBAC 模型

图 6 所示为改进的 RBAC 模型。在改进模型中引入上下文环境,作为角色的一个重要组成部分;将权限分

...

配过程分为静态和动态两类;将角色分级泛化为角色关系,简化 RBAC3 中的约束模型,仅在角色关系中体现。事实上每个信息系统都有独自的约束要求,本文的改进模型没有将其在模型中表示。基于角色理论的 RBAC 改进模型去掉描述不详的 RBAC2 限制模型,在角色的概念上做了一定的补充。这样,既简化了 RBAC96 模型,又提高了其普适性。

3 结束语

本文在角色理论的基础上,对 RBAC96 模型中的角色和权限部分进行了扩展,并简化了 RBAC3 模型中的约束部分,使其具有良好的可扩展性。

参考文献

[1] SANDHU R S, COYNE E J, FEINSTEIN H L, et al. Rolebased access control models[J]. Computer, 1996, 29(2):3847.

[2] 贾晓辉, 韩玉民. 基于任务的 RBAC 模型设计与应用[J]. 微型机与应用, 2014,33(2):7881.

[3] 杨静, 季新生, 刘彩霞. 基于角色访问控制的 HSS 数据库越权访问防护[J]. 电子技术应用, 2011, 37(4):145148.

[4] MIZOGUCHI R, SUNAGAWA E, KOZAKI K, et al. The model of roles within an ontology development tool: Hozo[J]. Applied Ontology, 2007, 2(2):159179.

[5] 熊晶. 海洋生态本体的建模方法研究及应用[D]. 青岛:中国海洋大学, 2010.

[6] 江利萍, 张再跃. 社会群体角色本体建模及其公理获取[J]. 计算机工程, 2012, 38(10):4144.

2018/7/17 posted in  Authn&Authz