RBAC模型论文

2024-10-15

RBAC模型论文(精选7篇)

RBAC模型论文 篇1

随着网络技术的发现,各种计算机犯罪事件不断的增加,网络安全的形势也变得日益严峻。因此,在我们进行信息共享和资源访问的同时,必须兼顾到系统的安全性,而访问控制正是一种通过约束用户访问行为而达到对敏感信息进行隔离目的的安全服务和机制。

访问控制对于主机系统和设计与开发安全操作系统的重要性已勿庸置疑,而在网络这样一种分布式环境下如何对资源进行保护,对用户行为进行约束,同样是一个值得研究的重要课题。在基于角色的访问控制模型(role—based access control,RBAC)出现之前,自主式访问控制策略(Discretionary Access Control,DAC)[1]和强制式访问控制策略(Mandatory Access Control,MAC)[2]是两种比较常用模型。并且它们在现实中都有具体的应用,然而随着计算机网络的快速发展和应用系统规模的不断扩大,这两种传统的访问控制模型已经无法适应新的应用环境,它们都无法提供一种策略中立、具有强扩展性的访问控制框架。

RBAC模型就是在此种情况下被提出来的。它其实是一种强制访问控制模型,通过引入了一种抽象的中介元素--角色,来传递授权信息,从而提供了足够的灵活性和扩展性[3]。它克服了上述两种策略的一些缺点,在解决大型企业的统一资源访问控制的问题上得到了较为灵活的体现。

1 基于角色的访问控制RBAC96模型

由NIST定义的标准RBAC模型,即RBAC96模型由4个部件模型组成:基本模型RBAC0(Core RBAC)、角色分级模型RBAC1(Hierarchy RBAC)、角色限制模型RBAC2(Constraint RBAC)和统一模型RBAC3(Combines RBAC)。RBAC96模型间的层次关系如图1所示。

RBACO定义了构成RBAC系统的最小元素集合。如图2。

在RBAC0中,包含用户users、角色roles、对象objects、操作operations、许可权permissions五个基本数据元素,权限被赋予角色,而不是用户,当一个角色被指定给一个用户时,此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。

RBAC0与传统访问控制的主要差别是在用户与权限之间增加了一层,间接的带来了灵活性,RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。

RBAC1加入了对角色层次关系的描述,适用于角色需要从另外的角色继承权限的情况;角色层次RH(Role Hierarchy)可以反映这种责权关系,原则上RH体现了上级权限高于下级权限的关系。

RBAC2模型是在RBAC0的基础上增加了约束机制。约束是在RBAC0基础上,在RBAC2模型上增加的一组约束关系,用来判定RBAC0模型的各个组成部分的值是否是可接受的,只有可接受的值才被许可[4]。最基本的约束包括用户约束、角色约束、授权约束、会话约束、用户授权约束和角色授权约束。

RBAC3是RBAC1和RBAC2的综合,自然地包含了RBACO。是增加了角色层次结构和约束机制的RBACO模型。

RBAC96模型系统而全面地反映了RBAC多方面的含义,将RBAC的几个主要方面全部涵盖其中。同时,RBAC96模型包含了四个相互关联的子模型,具有较强的层次感,并以此很好地表现出了RBAC本身的多层次性。

2 RBAC管理模型定义

RBAC管理模型定义为(S,P0,PA0)。其中,S为所有子系统的集合(S1,S2…Sn)。有可能在组织中只包含一个子系统,即S=S1。Si=(Ui Ri,Pi,覫i),其中Ui,Ri和Pi表示本子系统中的用户集、角色集和权限集。覫i表示子系统i的RBAC策略,即由(UA,RH,PA)组成的一个或多个有向无环图。P°表示组织或者说整个系统中的管理权限集合。

在图3中,我们给出加入了管理权限的RBAC模型图。在这个模型中,具有多个子系统,如S1、S2和Sn。在每个子系统中都有各自的用户、角色和权限以及它们之间的分配关系。所有子系统中的角色与管理权限是一个多对多的关系。

3 RBAC管理系统的设计

3.1 系统总体设计

RBAC管理系统的主要工作是根据现实变化的需要对RBAC访问策略进行维护和管理。让基于RBAC为访问控制模型的系统更加安全,具有一定的灵活性。

此系统可采用三层架构模式进行设计,让系统逻辑更加清晰,更便于维护。让表现层不直接接触数据层,通过中间的逻辑层预留各类接口以便将来应用程序的扩展。系统结构如图4所示。

3.1.1 表现层

通俗讲就是展现给用户的界面,即用户在使用一个系统的时候他的所见所得。表现层位于最外层(最上层),离用户最近,用于显示数据和接收用户输入的数据,为用户提供一种交互式操作的界面。在RBAC管理系统中,表现层为用户进行的一切RBAC的管理提供了完善的操作界面。

3.1.2 管理权限认证层

这一层应该说是RBAC管理系统的访问控制层,只有通过了这里的权限认证才能进行一定的操作。当然,它与应用系统中的一般权限不一样,这里的权限指的都是管理RBAC的权限,如增加用户,把某个角色分配给某个用户等等。

RBAC管理系统在定义好管理权限,以及管理权限与角色的分配关系后,就可以对管理请求进行控制了。它根据传递的参数(用户、操作、对象)进行判断该用户是否具有发起的这项管理指令的管理权限,并把判定结果反馈给应用层。

3.1.3 业务逻辑层

业务逻辑层由结点处理控制逻辑和邻边处理控制逻辑两块组成。结点处理控制逻辑块与邻边处理控制逻辑块分别对应RBAC管理所涉及到的两个方面,一个是RBAC模型中的三元素,一个是RBAC模型中的元素之间的关系。

3.1.4 抽象数据存储层

这一层为上层提供了一致的数据存储接口,隐藏了不同数据和不同存储模式下的不同类型接口,它使得系统结构清晰,降低上层的实现复杂度且不易出错,很好的体现了面向对象的设计思想。

3.1.5 数据存储实现层

这一层完成实际的数据存储功能,在系统中存在不同的数据,如角色及其关系,用户信息,资源和授权信息,这些数据类型并不相同,而且数据量也差异很大,需要分别实现。此外,数据存储方式也可以根据需要选用。

3.2 数据库设计

对RBAC管理系统而言,一般需要存储的有以下数据:角色信息表、角色继承关系表、用户信息表、用户角色分配情况表、一般权限表、一般权限与角色分配情况表、管理权限表和管理权限与角色分配情况表。

3.2.1 结点处理控制逻辑

结点处理控制逻辑是本系统的核心模块之一。它负责解决访问决策图中与结点有关的问题。当然,决策图中的结点就是访问控制模型中的元素,对于RBAC模型来说,就是用户、角色和权限。

在基于RBAC为访问控制模型的系统中,已经存在用户、角色和权限这些实体类,必定也存在对这些元素进行操作的接口。所以,将基于RBAC模型的系统扩展成具有自管理性的访问控制系统是一件并不困难的工作。在这一模块的工作,只需要加入一个新的元素-管理权限,以及对它的操作接口即可。

在这里对管理权限的封装与一般权限有所不同。一般来说,系统权限都对应一段真正执行的程序代码,当用户进行操作的时候,会执行相应的权限代码。而管理权限则不同,因为管理权限的类型和变化相对一般权限而言都要简单很多,也是有规律可寻的。我只是封装了管理权限的执行类型,以及涉及到的结点编号。这样做的好处就是,不管是怎样的管理权限,都只需要一段或几段代码将它们兼容起来,使程序设计变的简单了许多。

3.2.2 邻边处理控制逻辑

邻边处理控制逻辑也是本系统的核心模块之一。它负责对访问策略图中的边进行管理,也就是RBAC中用户与角色的分配关系、角色之间的继承关系和角色与权限的分配关系的管理。它们的管理主要涉及到增加和删除。

这里首先定义了一个抽象类叫做Manager,在这个类中又定义了几个必要的纯虚函数。因为无论是给用户和角色进行分配和删除,还是在角色间改变继承关系,包括在角色与权限间的操作,抽象到事物本质都是在对图中的两个结点进行操作。所以定义了增加纯虚函数(Add)和删除纯虚函数(Remove),然后定义了三个不同类去继承这个抽象类,分别实现了各自的函数。

3.2.3 抽象数据存储层

抽象数据存储层主要功能是让上层逻辑通过它来与数据库中存储数据打交道。现在已经有许多好的对象关系映射框架,在开发中也是基于这些框架来实现抽象数据存储层的。

4 结束语

通过对标准RBAC模型研究出发,分别从它的四个子模型进行研究说明,深入理解RBAC的原理。在此基础上,大量分析现有的基于RBAC设计的系统,讲述了它的具体实现。总结出系统在访问控制方面经常发生的改变,寻找一个适合的管理模型。

在理论上,本文通过对RBAC管理系统总体的设计,分别对管理层,管理权限认证层,业务逻辑层等各层次都作了介绍,使人们对这个系统有个初步的了解。然后具体对数据库进行了详细的说明,尤其在RBAC模型的系统中加入了管理权限,增强了系统的安全性和可用性。

参考文献

[1]Lampson B.Protection[C]//Proc the5th Annual Princeton Conf on Information Sciences and Systems.Princetion,New Jersey,Princeton University Press,1974:437-443.

[2]Sandhu R S.Lattice-based access control models[J].IEEE Computer,1993,26(11):9-19.

[3]周宏仁.电子政务全球透视与我国电子政务的发展[J].电子科技大学学报,2002.2(21):108-119.

[4]Sandhu R S,Coyne E J,Feinstein H L.Role-based access control models[J].IEEE Computer,1996,29(2):38-47.

基于RBAC的灵活集团委托模型 篇2

关键词:基于角色的访问控制,集团委托,委托授权,委托撤销

1 概述

基于RBAC的委托[1]允许将集中式授权工作分散给普通用户去实施,极大地减轻了安全管理员的工作负担,使得用户与角色的管理能够轻易地实现,为实现大规模信息系统授权工作提供了一种有效的手段,已成为访问控制领域的研究热点之一。现有基于RBAC的委托模型RBDM0[2]、RBDM1[3]、RDM2000[4]、PBDM[5]等能够表现委托的时限性、传播性、撤销性等基本特征,均是用户-用户的委托,然而它们并不支持集团委托形式。因此,在协同工作环境下当某个用户临时出差(或休假)而需要将其角色同时委托给多个用户(称为集团用户)时,如何设计灵活的集团委托机制亟需研究和解决。

结合RBAC模型,提出一种基于角色的灵活集团委托模型(Role-Based Flexible Group Delegation Model,RBFGDM)。给出委托关系、委托授权、委托撤销的形式化描述及委托实施的步骤。

2 基于角色的灵活集团委托模型

2.1 基本元素及委托关系

定义1 基本元素集。U、R、P、UA、PA、RH为RBAC中的元素集,分别表示用户集、角色集、权限集、用户-角色分配关系、权限-角色分配关系和角色层次关系;UAO、UAD为RBDM中的元素集,分别表示原始用户-角色分配关系和受托用户-角色分配关系。

委托关系用DR表示,包含原始用户分配关系UAO,受托用户分配关系UAD以及约束条件DC。这三个部分之间的相互关系在用户-用户委托中体现在以下五个方面:委托用户、委托角色、受托用户、受托角色以及委托约束。图1给出了某项目工程在设计中涉及到的角色层次关系,用户-角色分配关系如表1所示。((A,DIR),(D,DIR),Friday)说明A将角色DIR在星期五委托给比其更低级角色PC1的用户D。

DR包括原始用户-受托用户的委托关系ODR和受托用户-受托用户的委托关系DDR。

定义2 用户-用户委托关系:

DR⊆UA×UA×DC,表示一个多对多用户分配与约束条件的映射关系。委托关系((u,r),(u',r'),dc)∈DR表明用户u在满足约束条件dc的情况下,将其角色r委托给用户u'。

ODR⊆UAO×UAD×DC,表示一个多对多的原始用户分配、受托用户分配以及约束条件三者之间的映射关系。

DDR⊆UAD×UAD×DC,表示一个多对多的受托用户分配、受托用户分配以及约束条件三者之间的映射关系。

由定义2可知,DR=ODR∪DDR。

在用户-用户委托关系的基础上,扩展单个用户-集团用户的委托关系,称为集团委托关系。集团委托关系用DGR表示,包含:原始用户分配关系UAO,受托用户分配关系UAD,受托集团用户分配关系GAD以及约束条件DC。这四个部分之间的相互关系在集团委托中体现在以下五个方面:委托用户、委托角色、受托集团用户、受托角色以及委托约束。((A,DIR),(PH1,DIR),1:00-3:00 PM Monday)说明A将角色DIR在1:00-3:00PM Monday这段时间内委托给工程PH1中的所有成员用户。

DGR包括原始用户-集团用户的委托关系ODGR和受托用户-集团用户的委托关系DDGR。

定义3 单个用户-集团用户委托关系:

GAD⊆G×R,其中G是多个用户的集合,GAD表示一个多对多的受托集团与角色集的映射关系。

DGR⊆UA×GAD×DC,表示一个多对多的用户分配、集团用户分配以及以及约束条件三者之间的映射关系。委托关系((u,r),(g,r),dc)∈DGR表明用户u在满足约束条件dc的情况下,能够将其角色r委托给集团g(即该集团中的所有用户)。

ODGR⊆UAO×GAD×DC,表示一个多对多的原始用户分配,受托集团用户分配以及约束条件三者之间的映射关系。

DDGR⊆UAD×GAD×DC,表示一个多对多的受托用户分配,受托集团用户分配以及约束条件三者之间的映射关系。

由定义3可知,DGR=ODGR∪DDGR。

2.2 委托授权及撤销

委托授权的目标是通过施加约束将委托角色委托给受托集团,先决条件是非常重要的一方面,

定义4 先决条件。用CR表示所有先决条件的集合,一个先决条件cr∈CR是一个使用“∧”和“∨”连接形如的布尔表达式。

如果集团中的所有成员满足先决条件,那么称该集团满足先决条件。给定角色集R,假定CR是用R表示成的形如的先决条件的集合,如,其中cr∈CR。以下给出RBFGDM的委托授权判定。

定义5 委托授权判定。用can_delegate(r,cr,n)表示委托授权判定,can_delegate(r,cr,n)⊆R×CR×N,其中R为角色集,CR为先决条件,N为自然数集。can_delegate(r,cr,n)表明角色r的用户在集团用户满足先决条件cr、允许多步委托且委托的最大深度不超过n的情况下,能够将其角色r(或比r低级的角色)灵活地委托给集团中的所有用户。

委托撤销可分为强撤销和弱撤销,也可以分为层叠撤销和非层叠撤销,还可分为依赖于授权的撤销和非依赖于授权的撤销。对于弱撤销仅仅撤销关联集团直接成员的角色,不撤销关联集团间接成员的角色,然而强撤销不仅撤销关联集团直接成员的角色,还撤销关联集团间接成员的角色。对RBFGDM的委托撤销判定作如下定义。

定义6 委托撤销判定。用can_delegate(r,cr,n)表示撤销判定,can_revoke(x,Y)⊆R×2R,其中R为角色集。can_revoke(x,Y)表明角色x的用户能够撤销对受托集团在角色撤销范围Y上的委托。

2.3 委托授权(撤销)过程及模型结构

根据模型的委托关系、委托授权及委托撤销判定,给出集团委托(或撤销)的具体步骤如下:

步骤1 选择需要委托(或撤销)的角色;

步骤2 选择将要委托(或撤销)的受托集团;

步骤3 检查受托集团是否满足委托授权判定(或撤销)中的先决条件等;

步骤4 设置约束条件(如委托期限、委托深度等);

步骤5 更新委托关系列表DGR。

结合模型的基本元素、委托关系,给出RBFGDM结构如图2所示。

3 结束语

针对现委托模型不支持集团委托机制,提出了一种基于角色的灵活集团委托模型,实现了在分布式协同工作环境下从单个用户到集团用户的统一委托,保证了委托过程的灵活性,避免了引入较高的管理代价。如何进一步提高模型的安全性及其在实际环境中的应用实现是下一步需要研究的问题。

参考文献

[1]Barka E,Sandhu R.Framework for role-based delegation models[C]//Proceedings of the 16th Annual Computer Security ApplicationsConference,New Orleans:IEEE Press,2000:168-176.

[2]Barka E,Sandhu R.A role-based delegation model and some extensions[C]//Proceedings of 23rd National Information Systems SecurityConference,Baltimore:NIST,2000:101-114.

[3]Barka E,Sandhu R.Role-based delegation model/hierarchical roles(RBDM1)[C]//Proceedings of the 20th Annual Computer Security Ap-plication Conference,Washington.DC:IEEE Press,2004:396-404.

[4]Zhang L H,Ahn G J,Chu B T.A rule-based framework for role-based delegation[J].ACM Transactions Information and System Security,2003,6(3):404-441.

RBAC模型论文 篇3

信息技术的深入与广泛应用,使得企业信息系统的安全问题日益突出,访问控制技术由于能够有效地管理系统访问请求、控制用户对系统资源的操作权限,是信息系统安全的重要内容。基于角色的访问控制RBAC[1] 在用户和权限之间引入角色的概念,使得它们不直接关联,而是通过角色来实现用户和权限的多对多的对应关系,实现了用户与访问权限的逻辑分离,极大地方便了权限管理和访问控制,成为应用最为广泛的访问控制模型。

经典的RBAC模型[1]支持角色层次关系,通过设立私有角色还可以支持角色权限的部分继承,但它应用在有复杂人员组织机构的大规模复杂企业级信息系统中,仍面临一定的问题:

(1) 在此类系统中,用户角色权限繁多,而且很多权限跟组织结构本身相关。集中式的角色权限分配会大大加重安全管理员的负担,授权机制的灵活性也难以满足需求。

(2) RBAC中的角色继承是向上继承,即上级角色继承下级角色的权限。但实际应用中有很多权限向下继承的情况(如研发总部有使用打印机的权限,那么其下的研发一部和研发二部也继承了该权限)。

(3) 此类系统组织结构庞大且复杂,通过RBAC模型的角色层次关系来模拟应用系统中组织结构和其中的权限管理有很大的局限性,会导致组织结构与角色层次不吻合,无法借助角色解决组织结构的统一权限;而且角色层次关系变得复杂,会导致访问控制性能下降,权限冲突概率增加。比如:某些资源对同一部门的所有工作人员都是开放的,但对于企业其它部门是屏蔽的。如果抛开组织结构,用角色来解决这个权限问题,只需要为相关角色同时分配这一资源就可以了。但这样,一方面会增加很多工作(例如部门经理、销售员、发货员等不同的角色,都要得到这个权限),另一方面淡化了原本清晰的组织结构概念[4]。

针对上述问题,国内外学者也进行了相关的研究,并提出各自的解决方案。文献[5]提出一种复合的RBAC模型,把组织角色和系统角色分离,并提供它们之间的映射。模型能较好地支持大型复杂的组织结构。不过角色间的映射在实现上复杂度较高,而且作者没有给出模型的算法实现。文献[2]提出的ORBAC模型,通过定义组织结构及其权限,减少了角色的数量,降低了系统访问控制的复杂度。但其给出的模型不能解决权限向下继承的问题。此外,在ORBAC模型中,没有对权限的表示和约束作讨论。

本文我们提出一种支持角色双向继承的约束RBAC模型BI-RBAC(Bidirectional Inheritance-RBAC)。该模型对经典的RBAC模型进行扩展,增加虚拟角色及其层次结构的概念,并把权限表示为资源的操作,同时定义了相关的约束集。基于支持双向继承的角色层次关系,本模型可以有效提高访问控制的灵活性,解决角色向下继承的问题,同时通过灵活配置能够较好地适用于拥有复杂人员组织机构的大型应用系统。

1模型介绍

1.1模型定义

如图1所示,为解决经典RBAC模型和其它模型在复杂应用系统中的不足,我们对经典的RBAC0[1] 模型进行扩展,提出支持双向继承的虚拟角色(VR)的概念,把RBAC0模型中的角色更名为通用角色(GR),VRGR构成了扩展角色集。我们把权限定义为资源上的操作许可。这样,访问控制可以通过把资源的操作分配给扩展角色,再把扩展角色分配给用户来实现,同时要遵循模型中定义的操作约束和角色约束。

下面详细定义这一模型及其包含的各个部分。

定义1BI-RBAC模型={U,UA,P,PA,S,Res,OP,EC,ER,VR,VRH,GR,RC,OPC,user,roles},其中{U,UA,S,user,roles, PA }的定义参见文献[1]。

GR(通用角色) 等同于RBAC0中的角色定义,即不支持层次结构的普通角色。

VR(虚拟角色)= VDRVPRVDR表示虚拟部门角色,VPR表示虚拟岗位角色。

VRH(虚拟角色层次关系)=VRVRVR上的一种自反、传递、反对称的偏序关系(记为≥)。对任意的vr1,vr2∈VR,如果∃vr1≥vr2,则我们称vr1继承自vr2,记为 (vr1,vr2,VRH)。在VRH中支持角色双向继承——正向继承和逆向继承。其中VRP支持正向继承,即在VRH中高级岗位角色会自动继承低级岗位角色的权限;而VDR支持逆向继承,即低级部门角色会自动继承高级部门角色的权限。

如图2a所示的VRH构造的角色继承关系树中,VDR5和VDR6都继承自VDR3,则它们会自动继承所有授权给VDR3的权限,而VPR1继承自VPR2,VPR2继承自VPR3和VPR4,则VPR1会自动继承VPR2拥有的权限,VPR2会自动继承VPR3和VPR4的权限。图2(b)是实际应用系统中创建的VRH结构图,其中项目经理岗位角色继承自测试工程师和研发工程师,它也自动继承了后两者所拥有的权限,而研发经理角色继承自项目经理角色,它是项目经理的上级岗位,因此拥有项目经理的所有权限,而给研发经理授权则不会继承给项目经理,比如研发经理拥有项目结题的权限,而项目经理没有。

VRH满足最小权限原则和权限隔离原则[3]。例如,如图2(b)所示,我们希望某项权限对市场部门及其下属部门开放,而对其他部门是屏蔽的,那么只需要给市场部授权,其下的客服部和销售部会自动获取权限,而行政部和研发部则没有权限;如果只希望客服部有查看客户资料的权限,而销售没有权限,那么只需要单独给客服部授权即可。

VRVRH概念的引入,既可解决复杂组织机构的上下级权限继承问题,同时也大大简化了权限管理。同时VRH能够有效解决传统RBAC模型在复杂组织结构中的问题。因为VRH比角色层次关系更符合组织层次结构,体现了组织内部的权利和责任关系。而且VRH简化了RBAC模型,提高了权限管理的灵活性。

ER(扩展角色集)=VRGR 对RBAC中角色的扩展。

Res(资源) 系统访问控制的对象。如文档,菜单等。

OP(操作集) 资源上运行执行的动作序列。如文档的增加、删除、修改操作。

P(权限集)⊆Res×OP 权限是对某一客体资源的操作许可。如果用户u拥有某项权限p=(res,op),则表示u拥有资源resop操作许可。

OPC(操作约束集)=OP×OP×OPCT 定义了同种资源类型下的操作间的相互关系。OPCT指操作约束类型,将在后面介绍。

RC(角色约束集)=VR×VR×VRCTSGR×GR×GRCTS VRCTS指虚拟角色约束类型集,GRCTS指通用角色约束类型集。

EC(扩展约束集) 定义在本模型上的约束的集合,包括OPC,RC,权限分配约束,角色分配约束,会话约束等,可根据实际应用灵活设置约束。

1.2扩展约束集(EC)

定义2 通用角色约束类型集(GRCTS)表示通用角色之间及自身的约束关系。

(1) 互斥(RE)

即一个用户最多只能分配互斥角色集中的一个角色:

a) 静态互斥(SRE) ∀r1,r2∈VR,uU,如果(u×r1)⇒⇁(u×r2),则称r1和r2静态互斥,记为(r1,r2,SRE)。

b) 动态互斥(DRE) ∀r1,r2∈VR,sS,如果r1∈roles(s)⇒∀siS:r2∉roles(si),则称r1和r2动态互斥,记为(r1,r2,DRE)。动态互斥跟特定会话相关。

(2) 势(Ca)

即最大数。分为用户势(UCa)和虚拟拟角色势(VRCa)。UCa表示可分配给用户的最大角色数。例如,在系统中要限定一个用户最多能属于几个部门或岗位。VRCa表示可被分配给角色的最大用户数,比如总经理角色只能有分配给一个人,而开发工程师角色可分配给多人。

(3) 前置角色(PreR)

r1,r2∈VR,如果r1被分配给用户u的前提条件是r2被分配给u,则称r2是r1的前置角色,记为(r1,r2,PreR)。比如用户被分配项目经理角色前,属于测试工程师或者开发工程师。实际系统中,前置角色间的不兼容(比如互斥)的情况不太可能发生。

定义3RP(角色权限集) ER→2p:RP(ri)={p|(p,ri)∈PA}

定义4 虚拟角色约束类型集(VRCTS) 虚拟角色约束类型集也包括互斥,势,前置角色等约束。因为虚拟角色支持层次结构,具有双向继承的特性,这里定义了其特有的约束规则。

约束规则1VR层次规则

vr1,vr2,vr3∈VDR,∃(vr1≥vr3∩vr2≥vr3)⇒vr1=vr2

vr1,vr2,vr3∈VPR,∃(vr3≥vr1∩vr2≥vr1)⇒vdr1=vdr2

约束规则2VR传递规则

vr1,vr2,vr3∈VR,∃(vr1≥vr2∩vr2≥vr3)⇒vr1≥vr3

约束规则3VDR层次规则

vdr1,vdr2∈VDR,∃vdr1≥vdr2⇒RP(vdr1)⊆RP(vdr2)

约束规则4VPR层次规则

vpr1,vpr2∈VPR,∃vpr1≥vpr2⇒RP(vpr2)⊆RP(vpr1)

约束规则5VDR-VPR层次规则

vdrVDR,vprVPR⇒∃(vdrvpr∩⇁(vprvdr))

约束规则1保证了VRH构造的层次模型中不会出现回环,避免一个部门直接继承自多个上级部门或者多个上级岗位直接继承一个下级岗位的情况,以避免权限继承混乱,增加访问控制的复杂度;约束规则2定义了继承的传递关系;约束规则3和约束规则4分别定义VR的双向继承关系,分别是VDR权限的向下继承关系和VPR权限的向上继承关系;约束规则5限定了VPR能够继承自VDR,反之则不行。

根据上面的规则,我们可以得出VRH结构模型的推导公式:

定义6 操作约束集(OPC) 角色约束很多情况下需要通过操作约束来进行增强,以保证模型的一致性,它们之间也具有一定的传递规则。本文中,操作约束是针对同种资源的。

操作互斥(OPE) ∀op1,op2∈OP,res∈Res,vrVR,如果(res×opvr)⇒⇁(res×opvr)。则称op1和op2互斥,记为(op1,op2,OPE)。操作互斥可以增强角色互斥约束。比如可以定义文档资源的只读操作和写操作为操作互斥关系,那么这两个操作不能同时赋予一个角色。

操作包容(OPI) ∀op1,op2∈OP,res∈Res,vrVR,如果(res×opvr)⇒(res×opvr),则称op1包容op2,记为(op1,op2,OPI)。比如文档资源的写操作和读操作,具有包容关系,拥有写操作权限则包容了读操作权限。

2模型关键算法的实现

在安全访问控制模型中,权限分配、访问控制和角色分配是最关键的几个算法。下面简要描述在本模型中这几个算法的实现。

(1)访问控制算法(check Permission)

(2)权限分配算法(grant Permission To Role)

(3)角色分配算法

3应用

在实际应用中,本模型在保证系统的安全基础上,大大简化了安全管理员的工作复杂性,提高了系统的访问控制效率和安全性。下面结合我们开发的面向企业级的钱塘权限管理服务中间件系统为例,说明本模型的应用。

钱塘权限管理服务中间件是一个大型、通用的中间件平台,主要应用在权限管理、访问控制领域,可为进行权限管理的二次开发人员提供了一个方便、安全、高效的支持平台,提供认证、访问控制、责任认定、域内授权,单点登录、跨域认证授权等服务,如图3所示。其核心模块授权和访问控制就是基于本文提出的模型实现的。

该中间件平台面向金融、证券、交通、基金、航天等领域,提供认证与授权的行业解决方案。对于不同行业中的具体应用系统,其组织结构、角色管理、权限管理等都是极其复杂和多元化的,而钱塘中间件平台通过实现本模型则可有效解决这些问题,利用VRH推导公式和相关约束集可以构造出系统的组织架构模型。同时在该平台中,将权限定义为资源的操作,可以满足不同应用的权限管理。比如菜单资源的激活、非激活操作,文档资源的读、写、删除、共享等操作。不同类型的资源上可以定义操作约束,以增强安全访问控制。

钱塘权限管理服务中间件在恒生证券交易系统上得到了较好的应用。恒生证券系统(如图4所示)是一个大型的金融交易系统,其组织结构、角色设置以及权限定义非常复杂及繁多。应用传统的RBAC进行访问控制,则角色管理、授权管理的工作量会非常繁重,而且系统复杂度增加,安全性也得不到保证。基于钱塘权限管理服务中间件平台,我们对证券系统的组织结构进行合理设置,其中岗位支持正向权限继承,组织支持逆向权限继承;定义菜单、文档、按钮等资源和它们的相关操作及其约束,来有效管理权限;授权和访问控制过程则根据本文提出的算法来实现。系统上线后,在保证安全运行的基础上,稳定性和性能得到了比较大的提升,同时也大大简化了系统管理员的负担。

4结语

本文针对典型的RBAC模型在复杂应用系统中的局限性,提出了一种新的支持角色双向继承的访问控制模型。该模型对RBAC模型进行了扩展,增加了虚拟角色极其层次结构,同时对权限的定义给出了新的阐述,并定义了相关约束。该模型具有简单、灵活、表达力强和与现实系统更接近等特点,能够有效保证系统的安全访问,同时大大降低了安全管理员的工作负荷。本文提出的模型适用于各种复杂的企业级应用系统。不过本模型尚有一些亟待改进和解决的地方,如对VRH进行改进以支持权限部分继承等。

摘要:针对经典RBAC(Role Based Access Control)模型在复杂应用系统中操作繁琐以及难以映射组织结构等不足之处,提出了一种支持角色双向继承的约束RBAC模型BI-RBAC。该模型对经典的RBAC模型进行扩展,增加虚拟角色及其层次结构以支持角色的双向继承,并定义资源操作的概念。给出模型的形式化定义的同时,设计了访问控制算法。模型在自主开发的大型平台软件钱塘中间件平台软件中得到了应用,可较好地支撑恒生证券交易系统等大型软件系统。

关键词:访问控制,虚拟角色,虚拟角色层次结构,双向继承

参考文献

[1]Ravi S Sandhu,Edward J Coyne,et al.Role-Based Access Model[J].IEEE Computer,1996,29(2):38-47.

[2]李帆,郑纬民.基于角色与组织的访问控制模型[J].计算机工程与设计,2005,26(8):36-40.

[3]Mohammad A.Al-Kahtani,Ravi Sandhu.A Model for Attribute-BasedUser-Role Assignment[C]//Computer Security Applications Confer-ence,2002:353-363.

[4]张绍莲,欧阳毅,等.角色层次关系的分析与研究[J].计算机科学,2002,29(3):72-74.

[5]Joon S Park*,Keith P Costello,et al.A Composite RBAC Approach forLarge[C]//Complex Organizations.SACMAT'04,2004:163-172.

[6]尹建伟,徐争前.增强权限约束支持的基于任务访问控制模型[J].计算机辅助设计与图形学学报,2006,18(1):143-149.

[7]王悦,高虎明.扩展式基于角色的访问控制模型的研究[J].计算机工程与设计,2008,29(2):309-311.

RBAC模型论文 篇4

关键词:软件即服务,基于角色访问控制,访问控制,模型

0 引言

Saa S系统可以定义为“将软件部署为服务并通过Interne进行访问”的系统,是单实例、多用户体系结构、基于Internet访问的系统。系统中每个环节都可能受到安全威胁。为了确保系统中数据的安全性、一致性、完整性,使客户能够放心地将具有重要性、机密性的商业数据交给Saa S服务提供商进行管理和控制,在开发一个Saa S系统的过程中,作为Saa S系统的重要组成部分———权限管理模块变得尤为重要。本文在研究基于角色的访问控制(RBAC)模型的基础上,提出了Saa S系统的一种权限管理模型。

1 RBAC模型研究

访问控制是针对越权使用资源的防御措施。基本目标是为了限制访问主体(用户、进程、服务等)对访问客体(文件、系统等)的访问权限,从而使计算机系统在合法范围内使用;决定用户能做什么,也决定代表一定用户利益的程序能做什么。企业环境中的访问控制策略一般有三种:自主型访问控制方法、强制型访问控制方法和基于角色的访问控制方法。其中,自主式太弱,强制式太强,二者工作量大,不便于管理。基于角色的访问控制方法是目前公认的解决大型企业的统一资源访问控制的有效方法。其基本原理是在用户和访问权限之间加入角色这一层,实现用户和权限的分离,用户只有通过激活角色才能获得访问权限,提高了防护的力度。同时通过角色对权限分组,大大简化了用户权限分配表,间接地实现了对用户的分组,提高了权限分配的效率。而且加入角色层后,访问控制机制更接近真实世界中的职业分配,便于权限管理,提高了灵活度。其显著的两大特征是:(1)减小授权管理的复杂性,降低管理开销;(2)灵活地支持企业的安全策略,并对企业的变化有很大的伸缩性。美国国家标准与技术研究院NIST(The National Institute of Standards and Technology)标准RBAC模型由四个部件模型组成,这四个部件模型分别是基本模型RBAC0(Core RBAC)、角色分级模型RBAC1(Hierarchal RBAC)、角色限制模型RBAC2(Constraint RBAC)和统一模型RBAC3(Combines RBAC)[1]。RBAC0模型如图1所示。

RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。在RBAC之中,包含用户(USERS)、角色(ROLES)、目标(OBS)、操作(OPS)、许可权(PRMS)五个基本数据元素,权限被赋予角色,而不是用户,当一个角色被指定给一个用户时,此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性,RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。

RBAC1引入角色间的继承关系,角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系,允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。

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

RBAC3包含了RBAC1和RBAC2,既提供了角色间的继承关系,又提供了责任分离关系。

通过上面对RBAC模型的研究,在RBAC模型中,访问控制都与角色相关,系统权限控制都通过角色来实现,权限粒度不够细化,权限层次不够清晰,不能很好地区分系统功能操作控制与系统数据访问控制。基于这些问题的考虑,提出了一种新型的权限管理模型———基于RBAC的分层控制模型。

2 Saa S系统的权限模型

随着社会的不断发展、竞争的不断加剧、社会分工的不断细化、企业之间的合作不断加强、业务的灵活性不断增强,企业对系统数据的安全性要求越来越高,原有基于单一角色的粗放式系统权限管理模式已不能满足现在用户的需要,需要对系统权限管理进行细化,实行更精细化的管理。根据对Saa S系统的分析了解,运用分层控制的思想对Saa S系统的权限管理实施多层访问控制,能够确保系统的安全性和数据访问的灵活性。分层控制的思想是基于RBAC模型的权限设计思想,对RBAC模型进行了部分改良和扩展。把Saa S系统的权限管理模型划分为系统许可证权限管理、系统功能操作控制管理、系统数据访问控制管理三个层次;引入许可证、岗位、组织机构(部门、小组、虚拟团队)等数据实体,并定义岗位与用户、用户与不同组织机构等实体之间的关系。其总体模型如图2所示。

Saa S系统权限管理模型包含的基本元素主要有:用户、小组、角色、资源、操作、岗位、许可证、虚拟团队、部门、组织、权限。主要的关系有:分配角色权限、分配用户角色、分配用户岗位、分配组织许可证、分配权限操作、分配操作资源、分配小组到不同组织机构。其形式化描述可以从系统许可控制、系统功能操作控制、系统数据访问控制三个层次对其进行描述。

2.1 系统许可证控制

定义1许可证许可证一般分为用户许可证和功能许可证。用户许可证控制访问系统的用户数,功能许可证控制访问功能模块的用户数。

定义2分配组织许可证实现组织和许可证之间多对多的关系。即一个组织可以拥有多个许可证,一个许可证可以分配给多个组织。

2.2 功能操作控制

功能操作控制层主要表示用户对系统功能和系统资源两个层面的访问控制。用户可以访问哪些系统功能,怎样访问这些功能;用户可以操作哪些系统资源,怎样操作这些资源。系统功能的访问控制和系统资源的访问控制最终反映到对系统页面的控制。一个用户拥有怎样的页面访问权限也就具有相应的系统功能及系统资源访问权限。操作控制层主要涉及到数据实体:用户、角色、权限、操作、资源;数据实体关系:用户角色分配、角色权限分配、权限操作、操作资源等。其模型如图3所示。

定义3资源是系统所要保护的,可以被访问的对象。

定义4角色角色对应于某一特定的工作岗位,是一组可执行任务的集合。在视图层面的控制,表现为角色的赋予,不同角色具有不同的功能视图。用户根据被赋予的角色个性化地使用系统。系统用户看到的页面视图范围为该用户所具有的所有角色所定义的视图的总和。其关系图如图4所示。

定义5权限权限是对计算机系统中的一个或多个数据对象进行某种方式访问的许可权,是数据操作任务访问数据资源的接口。权限分配的单位与载体,用来定义用户执行各种功能的权限。同时,还用于控制用户看到的各种页面布局和选项卡。

定义6用户是权限的拥有者或主体。用户和权限实现分离,通过授权管理进行绑定。

定义7操作完成资源的类别和访问策略之间的绑定。

定义8会话一个会话是一个用户对多个角色的映射,当用户激活了部分或全部他被授予的角色时,他就建立了一个会话,用户实际上可以执行的任务是在这次会话期间被激活的角色的任务集。

定义9分配角色权限(PA)权限配置表示权限和角色之间多对多的分配关系,即一个角色可以被授予多个权限,一个权限可以分配给多个角色。

定义10分配用户角色(UA)分配用户表示用户和角色之间多对多的分配关系,即一个用户可以被授予多个角色,一个角色可以分配给多个用户。

定义11分配权限操作分配权限操作表示权限与操作之间多对多的分配关系,即一个权限可以包含多个操作,一个操作可以分配给多个权限。

定义12分配操作资源分配操作资源表示操作与资源之间多对多的分配关系,即一个操作可以对应多个资源,一个资源可以分配给多个操作。

2.3 数据访问控制

现代企业内部之间的协作不断加强,企业之间的合作越来越紧密,根据不同的业务活动需要,在企业部门内部、企业部门之间、企业之间设立了不同的小组、虚拟组织等工作组织形式,有些组织中的员工虽然具有相同的功能操作权限,但具有不同的数据访问权限,这需要系统对数据访问进行严格、灵活的控制,数据访问控制层能很好地解决这些问题。数据访问控制层主要是对系统数据访问进行控制,控制系统数据的访问权限及数据的共享权限。不同级别用户群体具有不同的数据访问权限;不同机构用户群体具有不同的数据共享权限。其模型如图5所示。

定义13岗位是一个企业的某个部门的职位(相当于在部门下有相同职能的员工的集合),它隶属于某个具体的部门,并且可以有一个或多个员工在岗位上任职。一般情况是一人一岗,同时提供一人多岗的功能,以完成权限在数据层面的灵活控制。一个系统用户如果有两个岗位,那么他只能看到当前岗位下的数据,通过岗位切换,可以达到查看所属其它岗位下的数据信息。另外岗位有上下级关系,上级可以查看下级的数据,下级不能访问上级的数据,平级之间不能互相访问。其关系图如图6所示。

定义14用户是权限的拥有者或主体。用户和权限实现分离,通过授权管理进行绑定。

定义15组织机构根据不同用户属性划分的用户群体。在一个企业内部可以划分为部门、小组等不同组织形式;在企业之间可以划分为小组、虚拟团队等不同组织形式。一个部门可以划分多个小组,一个小组可以包含多个用户;部门跟用户存在一对多的关系,用户小组跟用户存在多对多的关系。组织机构与用户之间的关系具有多样性、灵活性,根据不同的业务活动需要可以进行细化。

定义16分配用户岗位表示用户与岗位之间多对多的分配关系,即一个用户可以拥有多个岗位,一个岗位可以分配给多个用户。

3 结束语

本文论述了一种基于RBAC模型的Saa S系统权限管理模型的研究。该权限管理模型已成功应用于系统的设计和开发实践,与应用系统具有很好的集成。实践表明,采用基于RBAC模型的新系统权限管理模型表现出以下优点:(1)采用分层思想实现权限管理,有利于权限控制与管理。(2)权限分配直观、容易理解,便于使用。(3)扩展性好,支持岗位、权限多变的需求。(4)通过资源的细分,为系统提供了不同粒度的权限控制。特别是将权限粒度控制到页面一级,并通过不同用户到不同页面的映射,可以实现用户界面的定制,实现了更大的灵活性。

RBAC模型论文 篇5

随着计算机互联网技术的发展和医疗技术水平的提高,病人迫切需要在家里就能接受医院的治疗。这就迫切需要构建一个医疗系统。通过这个系统,病人、医生、护士、病人的家人和朋友都能共享医疗信息资源。医生和护士能通过系统查看病人的文档,并对病人做出诊断。病人可以通过系统委托其他用户成为自己的监护人,全权管理自己的权限。病人的家人和朋友可以在病人授权容许的范围内查看有限的信息。整个系统对用户的权限有较高的限制要求,既不容许用户访问授权外的信息,也不容许用户查看不到授权内的信息。

由于医疗系统的用户数量庞大,所以权限管理在整个医疗系统设计中,起着至关重要的作用。在权限管理中,访问控制是实现整个权限的核心内容,它是实现数据保密性和完整性机制的主要手段[1]。在整个医疗系统中,用户对记录的访问是非常频繁的,而且记录具有私密性,没授权的用户是不容许访问的。用户对记录的访问在整个权限管理又是处于重中之重的地位。但是传统的两种访问控制,已无法满足这个医疗系统的需求,因为传统的访问机制都是对系统中所有用户的权限进行直接的管理,这样的权限管理既复杂又不灵活,如果记录信息膨胀的话,系统就难以管理和维护。基于角色的访问控制(Role-Based Access Control,RBAC)是解决大型企业统一资源访问控制的有效方法[2]。基于角色的访问控制,是通过分配和取消用户的角色来完成用户权限的授予和取消,使用户与访问权限在逻辑上分离[3]。本文主要利用基于角色的权限访问控制模型,研究和实现用户在医疗系统中的权限访问控制,重点研究不同用户对不同记录(Record)访问控制问题。

1 RBAC模型的概述

角色访问控制是介于自主访问控制和强制访问控制之间的一种访问控制技术。角色访问在20世纪70年代就有人提出,只是最近才有人提出形式化的角色模型。其中最有影响的是Sandhu在1996年提出的形式化模型[4]。基于角色的访问控制模型可以简单地用图1来表示[5]。在此模型中,包括4个基本的要素:用户、角色、权限和授予。用户就是正在登陆系统的人或主机,角色就是用户在系统和组织中执行的操作的集合,执行这些操作时就代表着系统和组织的一个角色,权限就是主体访问客体时的认可,权限代表了主体是否可以对客体进行某种操作[6,7,8]。它的基本思想是用户被授予角色,系统通过用户所授予的角色决定其权限[9]。模型中用户可以被授予多个角色,同时一个角色也可以被多个用户所拥有。同样,角色和权限也是多对多的关系[10]。

2 医疗系统中权限管理的分析与设计

2.1 医疗系统的应用模型分析

基于角色的访问控制模型主要需处理好用户、角色、权限和它们之间的关系。在医疗系统中,用户对记录的访问是整个系统的核心内容。

2.1.1 用户分析

用户是在医疗系统中拥有账号的一个使用者,也有可能是游客。他可以在平台里拥有多个角色。例如:用户可以是一名病人,同时他也可以是一名医疗机构的管理员,甚至他本身就是医生,同时他也可以是其他病人的监护人或者普通的家人和朋友。

2.1.2 角色分析

在实现系统访问控制模块时定义了平台管理员(Platform Administrator,PA)、机构管理员(Agency Administrator,AA)、机构用户(Agency User,AU)、病人(Patient,P)、家人和朋友(Family and Friends,F)等多个角色。整个系统都是以病人为中心,所有角色都是为病人服务的。

(1)平台管理员,负责医疗系统平台的日常管理工作。他的一项重要的工作是创建其他的用户,特别是创建医疗机构并加入这个医疗系统。整个医疗系统可以由多个医疗机构组成。

(2)机构管理员,负责医疗机构的日常管理工作。他的一项重要的工作是添加其他的用户成为本机构的用户,并且设置他们的权限。

(3)机构用户,是医疗机构的主要成员。他们是负责日常的医疗管理,主要是指护士和医生。机构用户不能添加其他的用户。

(4)病人,是医疗服务的对象。他由医疗机构管理员添加到医疗机构,并安排医生和护士加入其护理组。

(5)家人和朋友,他们由病人邀请进病人的护理组,并赋予权限决定是否能够访问或修改病人信息。

2.1.3 权限分析

本文重点研究的内容是不同用户对不同记录的访问控制问题。在设计的医疗系统中,病人的记录分为team_note,resume,plan_of_care,life_doc,health_record,office_visit,medication,resource_lib等8大类。病人为自己创建一个护理组,机构管理员、机构用户、家人和朋友只有在病人的护理组里才能查看病人的记录。不同类型的用户对病人的记录具有不同的访问权限。

首先,用户要访问病人的文档,这个用户一定是在这个病人的护理组里。其次要根据用户不同的角色决定其权限,机构用户的访问权限,由机构管理员默认设置,比如医生和护士的访问权限是不同的,医生可以读写病人的病历,而护士就只能读他的病历,这个权限的设置就由他们所在的机构管理员设置的;病人的家人或朋友的访问权限,由病人设置权限。

2.2 权限管理的数据库设计

在设计数据库时,为系统建立用户表、病人表、机构表、机构成员表、角色表、护理组表、权限表、记录表和角色权限表等几个表。

(1)用户表,存储该系统中所有用户的信息。用户表的设计如表1所示。

(2)病人表,存储该系统中所有病人的信息。病人表的设计如表2所示。

(3)机构表,存储该系统中所有机构的信息。机构表的设计如表3所示。

(4)角色表,存储该系统中的角色。角色表的设计如表4所示。

(5)机构成员表,存储该系统中所有机构下的成员信息。机构成员表的设计如表5所示。

(6)护理组表,存储该系统中病人和其他用户的关系表。护理组表的设计如表6所示。

(7)权限表,存储该系统中的权限。权限表的设计如表7所示。

(8)角色权限表,存储角色和权限的关联表。角色和权限是多对多的关系,利用标识符确定角色是否具有权限的存取或操作功能。角色权限表的设计如表8所示。

(9)记录表,存储文档的表。文档分为8大类,由TAXONOMY_ID进行分类,记录表的设计如表9所示。

3 医疗系统中访问权限的实现

该医疗系统的权限管理采用PHP+My Sq L+Apache作为框架,并以Zend Studio作为开发环境实现的。

3.1 AA/AU对病人记录的访问权限实现

AA/AU访问病人的记录时,首先获取当前要访问的记录ID,然后通过这个ID查询记录表,获取当前记录的TAXONOMY_ID,系统通过保存在Session的用户ID查询机构成员表,通过比较,确定用户是否为AA/AU,并且获得当前用户在这个机构的所有Role值。然后通过Role值、TAXONOMY_ID值和AGENCY_ID值在角色权限表中确定访问权限,任意一个Role有权限,则表明有权限。如果没权限,则判断当前用户是否是病人的FF,然后通过FF对病人记录的访问权限实现步骤确定权限。

3.2 FF对病人记录的访问权限实现

当FF访问病人的记录时,首先获取当前要访问的记录ID,然后通过这个ID查询记录表,获取当前记录的TAXONOMY_ID,系统通过保存在Session的用户ID查询护理组表,确定用户是否在病人的护理组里,并且获得当前用户在病人护理组里的权限,如有权限,则可访问。

3.3 用户对病人记录的访问权限

用户对病人记录的访问权限实现的整个流程图如图2所示。

4 结语

角色访问控制由于不是直接授予权限给用户,而是先授予权限给角色,然后再授予用户角色,所以通过角色,实现了用户和访问权限的逻辑分离,使权限管理简便化。

本文利用角色访问控制模型实现了医疗系统的访问控制策略,重点研究和分析了用户对不同记录的访问控制问题。实践证明基于角色的访问控制技术能够有效地解决用户权限的管理问题,降低了系统设计的复杂度。

参考文献

[1]林磊,骆建彬,邓宪.管理信息系统中基于角色的权限控制[J].计算机应用研究,2002(6):82-84.

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

[3]樊金生,关保灿,李晓东.基于角色的访问控制扩展模型及其实现[J].计算机工程与设计,2008(18):4718-4721.

[4]毛碧波,孙玉芳.角色控制访问[J].计算机科学,2003(1):122123.

[5]周锦程,张佳强,冷文浩.可扩展系统中基于RBAC模型的访问控制[J].计算机工程,2009,35(14):145-147.

[6]姜宇锋,付钰,吴晓平.基于RBAC的权限系统设计与实现[J].计算机与数字工程,2009(6):98-101.

[7]智勇.基于角色的权限管理在教学资源管理系统中的应用[J].计算机与现代化,2003(7):37-39.

[8]建东,张铁,王中文,等.角色访问控制技术在放射治疗中的应用[J].计算机工程,2008,34(10):269-270.

[9]陈金玉,刘东荣,李卓伟,等.基于角色控制的教学权限访问系统的设计与实现[J].重庆大学学报:自然科学版,2005,28(12):60-61.

RBAC模型论文 篇6

1 权限分配过程

通过RPMI模型中角色规格证书和角色分配证书及实现角色-资源-操作、角色-角色-权限分配矩阵, 实现了用户-角色的指派、角色-权限的分配、角色层次、角色代理, 支持最小特权原则、静态约束及动态约束, 对角色私有权限的保护及灵活的代理也提供了较好的支持[1]。

1.1 角色-资源/角色-操作/权限的分配 (RSOP处理)

角色-权限的分配在RPMI系统实现中有两种方式, 一种是角色-资源-操作的分配, 另一种是角色-角色-权限的分配, 两种分配方式在统一的RSOP处理中实现。角色的层次继承及私有权限的保护也在这里得到实现。

定义四元组RSOP= (R角色, S资源, O操作, P权限) :

(1) 角色- (资源-操作) 的分配:

assignRS (r, Pr) ={r∈R|Pr= (O→S) }:对角色集合R中的任意元r都有它的权限是作用在资源S上的O操作;

(2) 角色- (角色-权限) 的分配:

assignRR (r, Pr) ={r∈R|PrPRi, i=1, …, n}:对于角色集合R中元素r由于R被授予拥有其它角色R2, R3, …, Ri的全部或部分特权, 因此r也同时拥有权限Pr1, Pr2, …;

(3) 角色-角色的完全继承:

r∈R1, R1≥R2则Pr∈ (Pr1∪Pr2) (≥表示继承关系) ;

(4) 角色-角色的部分继承:

r∈R1, R1≥R2则Pr part of (Pr1∪Pr2) 并且去掉要保护的私有权限。

对于 (3) 角色A完全继承角色B, 将不对角色B的特权作选择, 默认全部继承;对于 (4) 角色A不继承角色B的私有权限, 将对Pr2集合进行选择, 根据策略, 去掉要保护的私有权限, 这样角色B的私有权限将不被角色A继承。 (3) 、 (4) 实质上是 (2) 的特殊情况。在进行角色-角色的分配中, 系统将自动监测是否有角色冲突发生。

分配结束后, 所得结果存入一个三维矩阵中, 送交“角色分析处理”模块。“角色分析处理”提取矩阵中R角色, 这将作为角色规格证书中的角色;对矩阵中对象O、权限P, 根据OID号的分类, 对角色和权限排序 (实践证明这有利于提高“特权验证者”的验证效率) , 这将作为角色规格证书中的属性。角色规格证书通过AA私钥签名, 发布到LDAP中。

1.2 角色代理

在X.509中规定只有SOA和AA有权发布证书, 对权限的代理主要通过证书扩展项pathLenConstraints和delegatedNameConstrai nts分别从路径空间和命名空间上作了限制。我们没有完全遵照这个限制, 或者说根本没作代理空间的限制, 用户之间可以自由代理其所拥有的权限, 但通过以下3条规则来保证系统的安全:

(1) 用户需要将它的角色或特权授予他人, 需先产生授权申请;

(2) 只有AA有权颁发证书;

(3) 发生代理时必须有安全管理员的参与。

代理是通过RSOP处理辅助实现的, 这也是RSOP的一个特色, 不但各级安全管理员可以使用, 个人用户也可以使用, 只是根据其PKC不同来授予不同的使用范围, 也就是说他可以管理的只是他个人拥有的角色、特权和资源。通过选择要代理出去的角色/特权, 生成信息交换文件, 并用其私钥签名, 送交SOA/AA。安全管理员根据策略检查许可后, 签发新的角色分配证书, 实现角色的委托代理, 同时将信息交换文件备案。虽然, 在分布式环境中, 如果用户可以在没有安全管理员的参与下就可将自己的角色/权限代理出去在某些场合很适用, 也确实可以做到根据预设策略, 例如只要验证签名正确和权限是在代理范围内, 就可由系统自动签发新的角色分配证书得到实现。但这里强调指出, 用户进行角色代理不能没有安全管理员的参与, 否则将产生严重安全漏洞。

用户-角色的分配[2]。用户-角色的分配通过二维矩阵 (X, Y) 来完成, 这里x为用户, y为角色。系统自动监测静态责权分离原则的实施。模型中动态责权分离在“特权验证者”中实施。在为角色分配权限时, 有的复杂的角色的权限就是其他几个角色的权限的和, 我们在做角色规范证书时, 就不一一列举此角色的权限了, 就只列举出他的角色组合就可以了。例如:角色Y他的权限就是由角色X, 角色Z, 角色W三者的权限简单相加组成, 那么我们就在角色Y的角色规范证书的属性列中写上角色X、Z、W就可以了。不用写上他们的具体权限, 简化了角色规范证书, 便于权限的管理。

最小特权原则。在每个受保护的资源处都有一个“特权验证者”, 此模块在系统初始化时加载, 装入所需角色/权限的OID。当有资源访问事件发生时, “特权验证者”只需查询角色证书中有无这些OID即可。OID可以是角色也可以是特权。这样, 一方面实现了最小权限规则, 同时保护了用户的权限不被滥用。

2 属性证书的签发过程

属性证书的签发流程:用户输入登陆信息, 若不合法, 则再输入, 合法, 就把用户请求属性证书所需要的信息如角色、资源、权限等写入请求文件中, 并用自己的私钥进行签名, 形成属性证书请求文件, 把请求文件送给AA签名之前, 要验证AA的合法性, 特别是验证AA的私钥的合法性, 若AA的私钥是合法的, 那么就验证AC请求文件的合法性, 如果也合法, 就初始化AC请求文件, 并设置证书中的各项参数, 最后用前向安全数字签名方法使用AA的私钥签发AC, 用户申请的AC就这样生成了[3]。

3 结语

本文详细介绍了RPMI系统中两个关键部分:“权限分配过程”、“属性证书签发过程”的实现。通过RPMI模型中角色规格证书和角色分配证书及实现角色-资源-操作、角色-角色-权限分配矩阵实现了权限分配, 在证书签发过程中使用前向安全数字签名签发属性证书, 整体提升RPMI系统性能。

参考文献

[1]谭强, 黄蕾.PMI原理及实现初探.计算机工程, 2002, 28 (8) :187.

[2]张大江, 钱华林.一个利用教学证书实现的RBAC模型[J].小型微型计算机系统, 2001, 22 (8) :936-939.

RBAC模型论文 篇7

随着企业信息管理系统的逐渐发展,数据权限的需求日益增加,在一个企业信息管理系统里,可能涉及到多类用户,每类用户对应着不同的数据访问范围。RBAC并不能很好的满足复杂的数据权限控制的需求。本文在RBAC模型的基础之上,提出了一个加强数据权限管理的数据权限模型,满足对复杂数据权限控制的需求。

1 基于角色的权限控制模型

RBAC的核心思想是将权限与角色联系起来,在系统中根据应用的需要为不同的工作岗位创建相应的角色,同时根据用户职责指派合适的角色,用户通过指派的角色获得相应的权限,实现对文件的访问。也就是说,传统的访问控制是直接将访问主体(发出访问操作,有存取要求的主动方)和客体(被调用的程序或欲存取的数据访问)相联系,而RBAC在中间加入角色,通过角色沟通主体和客体,角色的目的就是为了隔离用户和权限。角色作为一个用户与权限的代理层,解耦了权限和用户的关系,所有的授权应该给予角色而不是直接给用户,从而实现了用户与访问权限的逻辑分离。1996年,Sandhu发布了RBAC96的RBAC通用模型族。文献[5]介绍了一些基于角色系统的开发框架。图1显示了通用模型族中最通用的模型。

用户和角色之间是多对多的关系,一个用户可以被赋予若干角色,一个角色也可以被赋予若干个具体用户。同样角色和权限之间也是多对多的关系,一个角色可以具有多项权限,一个权限也可以赋予多个不同的角色。某系统的操作用户,可以通过他所具有的角色的权限来判断其可访问的系统资源和对系统资源可以进行的操作,这就是RBAC最基本的工作原理。

RBAC的描述如下:

u:User用户;

r:Role角色;

p:privilege权限。

此时,如果某个用户u对某个业务对象o具有的权限记为P(u,o),则有如下关系:

P(u,o)=Pr(r(u),o)

其中,Pr(r(u),o)是通过用户u所赋予的角色r对业务对象o的权限。

大型企业系统一般功能庞大复杂,不同身份和岗位的用户对系统模块功能的使用权限不同。这种基于角色的权限控制模型可以直接将企业组织结构映射到信息系统中,使得对用户权限的管理更加直观、方便和统一,在很大程度上简化了权限管理工作。

2 基于RBAC的数据权限模型

2.1 模型设计

在企业应用系统中,由于用户量大、用户层次结构复杂、业务对象庞杂,权限涉及到比较复杂的功能权限和数据权限,其中功能权限可以是一个按钮或者链接,而数据权限则是对不同层次用户的不同数据范围的限制,假设功能权限的数量为m,数据权限的数量为n,在RBAC模型中,对于完全的权限管理需要有m*n种权限关系,在大型的企业信息管理系统中,随着功能数量的增加,角色权限的配置非常庞大而复杂,并且一旦需要改变数据权限的类型数量,将需要对权限表做较大的调整,因此不具有良好的可扩展性。

针对上述问题,本文在角色的权限控制模型的基础之上,设计了一个新的数据权限模型如图2所示。

数据权限模型将权限划分为功能权限和数据权限,对功能权限和数据权限分别设置不同的角色,分别为数据角色和功能角色。为用户不仅需要赋予功能角色,同时也需要赋予数据角色。用户需要访问一个模块时,不仅要取得该模块对应的功能角色的权限,还要取得该模块对应的数据角色的数据权限,才可以访问该模块功能下的数据。

模型中将角色分为了类型角色,用户与角色关系变为了用户功能角色的关系和用户与数据角色的关系,虽然对用户角色赋予的工作量增加了,但是解耦了角色与功能权限、数据权限之间的关系,使得完全权限集仅需要包含m+n个权限即可。假设数据权限类型数量增加为n+x,则完全权限集只需增加为m+n+x即可,而RBAC模型中完全权限集所对应的m*(n+x)=m*n+m*x,同理,当功能权限增加为m+x时,完全权限集也仅增加为m+n+x,而RBAC模型中完全权限集所对应的(m+x)*n=m*n+n*x。这使得数据权限模型随着系统数据权限的变更具有更少的变动,具有更好的可扩展性,减少了功能权限和数据权限的增加为角色权限维护带来的大量的增改工作。在实际操作中,也可以使用户的角色赋予更加清晰,达到更为简洁的角色权限控制。

2.2 模型实现

数据权限模型的权限控制系统采用普遍的三层架构,包括表示层、业务层和数据层。其中数据层是由数据库系统组成,权限管理则以数据库作为基础来进行。数据库的设计结构如图3所示。

用户通过“用户-功能角色”和“用户-数据角色”建立起动态的对应关系,功能角色与“功能角色-模块-按键”建立动态的对应关系,数据角色则与“数据角色-模块-数据范围”建立动态的对应关系,通过这种动态的对应关系可以更简便的建立用户与功能权限和数据权限之间的对应关系。

用户授权的实现通过共九个部分实现,包括用户管理、模块管理、模块按键管理、模块数据范围管理、功能角色管理、数据角色管理、功能角色模块按键对应表管理、数据角色模块数据范围对应表管理、用户功能角色和数据角色分配管理。

其中模块按键和模块数据范围的实际应用中随着系统模块的增减而改变,维护量仅随着系统模块的增减以及数据权限范围的变化而线性变化。而用户授权部分由用户管理、功能角色管理、数据角色管理和用户功能角色和数据角色分配管理实现,根据实际需求,为用户需要访问的菜单模块和此菜单模块下访问的数据范围分配角色,可以实现方便快捷的实现权限管理。

具体的系统实现流程为:页面模块读入时,根据用户ID获取用户的功能权限和数据权限,根据功能角色判断用户对该页面模块的访问权限,获取通过后,判断该用户的数据权限,并将数据权限键值存储到Session中,在用户使用按键时,判断根据Session中的数据权限范围,将其注入到SQL查询语句中,此时只需要将一定的范围限制语句作为一个封装的方法加入到SQL语句中,即可实现对数据访问范围的控制,当用户在该模块下的数据权限范围发生变化时,只需在改变用户在该模块下的数据权限范围,并不需要改变数据访问层的代码。如果系统需要修改数据权限范围,只需改变对数据权限限制语句所封装的方法,即可实现对数据权限的修改,有效的减少数据访问层代码的修改。

此数据权限模型可以广泛适用于大型企业管理系统中的权限管理,特别适合于类似于具有省、市、部门、个人多级数据权限控制范围需求的应用系统权限管理,可以灵活的增加不同层次范围的数据控制需求,对于后期的用户角色权限授权管理比较方便。

3 结束语

权限管理是企业应用系统中重要组成部分,权限管理的技术和策略对系统的信息安全影响很大。数据权限的管理属于权限管理的一个重要组成部分,是影响系统的信息安全的重要因素。针对于传统的RBAC模型存在的数据权限管理方面的不足,本文提出的一种基于RBAC的数据权限模型的设计与实现方法,是在RBAC96模型理论基础上提出,并在实际应用中进行了验证,满足了数据权限和功能权限双重控制的需求,降低了权限管理和维护的复杂性。对开发类似的多组织层次的应用系统管理功能模块具有一定的参考价值。

参考文献

[1]王延彬,许林英,杨海琛.OA系统中基于角色的用户权限管理[J].微处理机.2008.

[2]肖军模,刘军,周海刚.网络信息安全[M].北京:机械工业出版社.2003.

[3]周文峰,尤军考,何基香.基于RBAC模型的权限管理系统设计与实现[J].微计算机信息.2006.

[4]Sandhu R S,Coyne E J,Feinstein H L,et al.Role-based AccessControl Models[J].IEEE Computer.1996.

上一篇:剪切运用下一篇:初三英语复习