角色访问控制论文

2024-08-06

角色访问控制论文(精选10篇)

角色访问控制论文 篇1

0 引言

基于角色访问控制 (RBAC) 是目前流行的一种访问控制策略, 是在用户和访问许可权之间引入角色的概念, 将权限与角色相联系, 通过对角色的分配和取消来完成用户权限的授予和撤消, 简化了用户和权限的管理。RBAC技术俨然已经成为传统的自主访问控制和强制访问控制技术的最佳替代者, 受到了越来越多的关注。

在大型管理信息系统中, 可以有成百上千个用户, 每个用户扮演着不同的角色, 每个角色可以拥有不同的权限.集中由一小组的安全管理人员来管理这些角色和用户是一项非常繁重的任务, 这就要求下放RBAC的管理权, 分散授权管理。基于角色访问控制的主要优点是省去了权限管理的麻烦, 因此运用RBAC来管理RBAC本身是可行的。近年来, 相继提出的RBAC管理模型有ARBAC97、ARBAC02和CL03。下面对这三个模型进行分析比较。

1 ARBAC97模型

ARBAC97将RBAC各组件的管理问题划分为三类:用户-角色指派 (URA97) 、权限-角色指派 (PRA97) 和角色-角色指派 (RRA97) , 实现了对RBAC分而治之的管理。

1.1 URA97模型

URA97是用户-角色管理模型, 主要解决的是对用户分配角色的问题, 包括规则角色与管理角色的分配。该模型有两个组件, 角色分配can_assign () 和角色撤消can_revoke () 。

定义1.用户-角色指派:can_assignAR×CR×2R, R是角色集, AR是管理角色集, CR表示所有可能在R中使用角色形成的先决条件集合。

例如can_assign (x, y, Z) 指一个管理角色x (或一个级别比x高的管理角色成员) 可以对一个用户, 当这个用户的规则角色满足先决条件y时, 就能授予该用户成为范围Z中的一个规则角色成员。

定义2.用户-角色指派撤消:can_revokeAR×2R

例如can_revok (x, Z) 指一个管理角色x (或一个级别比x高的管理角色成员) 可从任何规则角色z∈Z中撤消一个用户的成员资格。

URA97中的撤消操作是一种弱撤消, 仅对直接管理的角色适用。图1中, 如果一个用户同时是DIR与PL1的成员, 而DIR的权限又是由PL1继承而来的, 那么即使删除了用户的PL1角色成员资格, 该用户仍然可以通过角色DIR获得PL1的许可。

1.2 PRA97模型

PRA97是许可-角色管理模型, 主要解决的是许可的分配与取消问题。RBAC模型中与权限直接关联的是角色, 因此, 权限到角色的指派是RBAC管理操作中重要的环节。该模型也有两个组件, 权限分配can_assignp和权限回收can_revokep。

定义3.权限-角色指派:can_assignpAR×CR×2R

定义4.权限-角色指派回收:can_revokepAR×2R

从角色的角度看, 用户和许可具有相同的特征, 故PRA97与URA97具有一一对应的关系, 只要把URA97中与用户有关的数据换成是权限, 就可以得到PRA97模型。

1.3 RRA97模型

RRA97是角色-角色的管理模型, 主要解决的是角色本身的管理问题, 这是整个RBAC模型中最为复杂的部分。由于角色的继承关系会影响到用户-角色指派和权限-角色指派关系, 任何一种操作都会对角色偏序结构产生影响, 从而给RBAC模型的分布式管理带来困难。

RRA97仅讨论了普通角色的管理, 而对管理角色的管理则未做说明。模型中普通角色的管理包括对角色和角色继承关系的修改, 由can_mod ifyAR×2R操作控制。

例如:can_mod ify (x, Y) 的意思是管理角色x (或者级别比x更高的管理角色) 中的一员可以创建或者删除区间Y中的一个角色, 也可以改变区间Y中的角色层次关系。

ARBAC97模型虽然简单, 易于理解, 但在实际应用中还存在一些缺点:

首先, ARBAC97不能够对特定的角色层次结构进行操作;其次, 由于受到先决条件的限制, URA和PRA中分别存在着用户和权限多步分配的问题, 多步分配必须导致信息冗余;最后, 由于采用自顶向下的权限分配方法, PRA97中存在着不合理的许可流问题。

2 ARBAC02模型

针对ARBAC97模型存在的问题, 对其进行了改进, 并提出了一个新的管理模型-ARBAC02。该模型采用了一种更先进的管理方法, 在保留ARBAC97模型主要特征基础上, 引进了一个新的概念“组织结构”, 作为新用户和权限库, 以此取代角色层次结构中的先决条件角色, 同时设计了一个自底向上的权限分配方案。

2.1 组织结构与新的用户库和许可库

组织结构是一个树型结构且具有继承特性, 它独立于角色或角色层次。一个组织结构是由许多组织单元构成的, 每个组织单元中都包含着相关人员和相关工作职责。为了完成角色管理的目的, 我们可以把用户库和许可库看成是不同的组织结构。

定义5.OS-U代表用户库的组织结构, 包含了事先分配好的用户。图2是一个OS-U的例子。任何组织单元都有用户, 如果“Tom”是“PJ1”的一员, 这就意味着他在Project1中有一个工作职位。OS-U是一个树型结构, 且具有继承特征。因此, “Tom”作为“PJ1”的一员, 也是“ED”和“PRD”的一员。

定义6.OS-P代表许可库的组织结构, 包括了事先分配好的许可。从图3中看到OS-P是一个倒置的树型结构, 一般的许可分配给底层部门, 特殊的许可分配给高层部门, 生产部门的访问许可都分配给“PRD”, 而Projectl成员的特殊许可分配给“PJ1”, 在OS-P中许可被向下继承。

2.2 自底向上的许可-角色分配方式

ARBAC02模型采用自底向上的方式进行许可的分配, 一般的许可分配给较低层次的角色, 较高层次的角色可以继承这些许可;另外, 特殊的许可分配给层次较高的角色。图1中, 公司所有成员都拥有的许可分配给角色“E”, 工程部门成员拥有的许可分配给角色“ED”, Projectl的成员拥有的许可分配给角色“E1”。这样, 层次较高的角色可以通过继承来获得相应的许可, 避免了不合理的许可流向。

3 CL03模型

严格意义上讲, CL03不能算做管理模型, 真正的管理模型应该是SARBAC, 它是在RHA4基础上扩展出来的。RHA4是R H A层次管理模型系列中的一个组成部分, 其作用与RRA97相当。RHA4中有一个很重要概念就是“管理区间”。

定义7.S (r) 设是角色r的管理区间, 有S (r) ={s∈R:s≤r↑s↑r↓r}。

例如, a∈S (r) 表示从a开始的每条路径都经过r, 也就是说, 由r控制的关于a的任何改变都不会因继承特性而对层次结构产生影响。

SARBAC在RHA4 admin_authority操作基础上增加了与ARBAC97中和作用相当的两个操作:

控制用户-角色的指派:ua-constraintsR×A (R)

控制权限-角色的指派:pa-constraintsR×A (R)

用户和权限的指派关系是通过ua-constraints和pa-constraints的直接更新和间接更新实现的。这两种更新操作都能改变模型的层次结构, 如果角色r处在管理角色a的管理区间之内, 那么a就可以修改所有与r有关的操作, 包括添加删除角色r, 添加删除以r为端点的边线, 这样的操作可能破坏模型的层次结构, 这在ARBAC97中是不允许的, 因为ARBAC97中对角色层次结构的任何一种操作都必须保证角色区间的封装性;而在SARBAC中, 每个管理角色都和一个特定的管理区间相关联, 角色的管理区间是由层次结构决定的, 而层次结构又是ad min_authority由操作动态扩展的, 并且可以随着层次结构的变化而动态变化, 因此SARBAC的管理方法更加灵活, 适用范围更广。

另外, SARBAC在模型的完整性, 简单性, 实用性和多功能性等几个方面都比ARBAC97优秀, 在基于角色的模型框架下, 还可以很好地模拟自主访问控制机制, 降低由角色层次结构的继承性带来的复杂操作。

4 结论

ARBAC97是最基本的, 也是最容易理解的基于角色访问控制管理模型, 但该模型还存在着很多问题。ARBAC02针对ARBAC97中存在的问题提出了一些改进措施, 引进了组织结构的概念, 使用户和许可不再依赖于角色层次。同时, 模型采用自底向上的权限分配方案, 解决了ARBAC97中存在的不合理许可流问题。SARBAC管理模型的提出, 突破了ARBAC97只能在封装的角色区间内对角色层次结构进行修改的局限, 使得该模型比ARBAC97更有吸引力, 具有更多的理论和实际应用价值。

摘要:基于角色访问控制技术是保证信息和系统安全的最有效的技术, 将角色与权限对应起来, 用户根据他的责任和资格被赋予适当的角色而获得相应的权限。模型中角色的分布式管理是一个十分复杂的问题。为了使RBAC模型的管理更加方便, 灵活, 可以用RBAC来管理模型本身。ARBAC97、ARBAC02、CL03是近年来提出的RBAC管理模型。本文重点对这三个模型进行了介绍, 通过比较, 指出了ARBAC97中存在的不足及ARBAC02、CL03所做的改进。在分析各个模型过程中, 给出了自己的理解。

关键词:基于角色访问控制,管理模型,ARBAC97,ARBAC02,CL03

参考文献

[1]Ferraiolo D, Cugini J, Kuhn R.Role-based access control (RBAC) :features and motivations. In:proceedings of 11th Annual Computer Security Application Conference, New Orleans.LA.1995.12.

[2]Bertino E,  Feari E, Atluri V. Specification and Enforcement 0f Authorization Constrains in Workflow Management Systems.

角色访问控制论文 篇2

PC(10.1.1.2)---E0(10.1.1.1)[RouterA]S0(192.1.1.1)---S1(192.1.1.2)[RouterB]

做网络的单向访问其实实现的是防火墙的基本功能:我是内网,你是外网,我能访问你,但你不能访问我,

所以现在假设RouterA的E0口所连网段为内网段,RouterA S0所连的网段为外网段,还假设我想做的是内网的PC机能ping通外网RouterB的S1口,但RouterB却ping不进我的内网。

用ACL来实现类似的单向访问控制需要用到一种特殊的ACL,叫Reflexive ACL。Reflexive ACL的配置分为两个部分,一部分是outbound的配置,一部分是inbound的配置。

在继续下面的说明之前,先说点题外话。在最开始想到单向访问问题时,我(也包括其它一些我的同事)自然的就这么想:那我在E0口上允许PC的流量进来,然后再在S0口上禁止RouterB的流量进来不就行了?看上去好像没什么问题,但一试就知道其实是不行的。为什么不行呢,因为很多人都忽略了这么一个问题:即绝大多数的网络流量都是有去有回的,上面的方法只解决了去的问题,但这个流量在到达RouterB后,RouterB还需要返回这个流量给PC,这个返回的流量到了RouterA的S0口,但上面的方法却在S0口上禁止了RouterB的流量进来,回来的流量被挡住了,通讯失败。

好,下面再切回来。Reflexive ACL中outbound的部分决定了我出去的哪些内网网络流量是需要被单向访问的,inbound部分决定了这些流量在返回后能被正确的识别并送给内网发起连接的PC机,

Reflexive ACL中outbound的部分:

ip access-list extended outbound_filter

permit icmp any any reflect icmp_traffic

permit ip any any

!---注意在Reflexive ACL中只能用named方式的ACL,不能用numbered方式的ACL。

!---基本配置和普通ACL并没有什么太多不同,不同之处是reflect icmp_traffic,它的意思是这条ACE作为单向流量来处理,并且给了一个名称叫icmp_traffic,icmp_traffic在inbound部分被引用。

!---permit ip any any并不是必要的,加在这里是为了另一个测试,下面会说明。

Reflexive ACL中inbound的部分:

ip access-list extended inbound_filter

evaluate icmp_traffic

deny ip any any log

自主访问控制研究 篇3

关键词: 自主访问控制    实现机制    特点    局限性

1.自主访问控制的概念

自主访问控制(Discretionary Access Control,DAC)是由客体资源的属主对自己的客体资源进行管理,由属主自己决定是否将自己的客体资源访问权或部分访问权授予其他主体,这种控制方式是自主的。也就是说,在自主访问控制下,用户可以按自己的意愿,有选择地与其他用户共享他的文件。

2. DAC的实现机制

在DAC中,把访问规则存储在访问控制矩阵中。访问控制矩阵是实现DAC策略的基本数据结构,矩阵的每一行代表一个主体,每一列代表一个客体,某个主体对某个客体的访问权限由矩阵中的每个元素表示。通过检查这个访问控制矩阵可以了解用户对任何客体的访问请求,如果矩阵中主体和客体的交叉点上有访问类型,那么访问就被允许,否则就被拒绝。

2.1基于行的DAC

这种机制是把每个主体对所在行上的有关客体(即非空矩阵元素所对应的那些客体)的访问控制信息以表的形式附加给主体,根据表中的内容不同又分为不同的具体实现机制。

2.1.1权限表机制

权限表中存放着主体可以访问的每个客体的权限(如读、写、执行等),主体只能按赋予的权限访问客体。程序中可以包含权限,权限也可以存储在数据文件中,为了防止权利信息被非法修改,可以采用硬件、软件和加密措施。因为允许主体把自己的权利转给其他进程,或从其他进程收回访问权,权限表机制是动态的,所以对一个程序而言,最好把该程序所需要访问的客体限制在最小范围内。

2.1.2口令机制

每个客体都有一个相应的口令。当主体对一个客体发出访问请求时,必须把该客体的口令提供给系统。口令不像权利那样是动态的,由于大多数实现自主访问控制的系统利用口令机制时仅允许把一个口令分配给每个客体或每个客体的每种访问模式。

2.1.3前缀表

前缀表中包含主体可访问的每个客体的名字及主体对它的访问权限。当某个主体要访问某个客体时,访问控制机制将检查该主体的前缀中是否具有它所请求的访问权。前缀表机制的实现存在以下困难:主体的前缀表可能很大,增加了系统管理的困难;只能由系统管理员进行修改,管理复杂;撤销与删除困难,系统难以决定谁对某一客体具有访问权。

2.2基于列的DAC

所谓基于列的自主访问控制是指把每个客体被所在列上的有关主体访问的控制信息以表的形式附加给该客体,然后依次进行访问控制。它有两种实现形式:保护位方式和访问控制表(ACL)方式。

2.2.1保护位机制

保护位对所有主体、主体组及该客体的拥有者指定了一个访问权限的集合,UNIX采用了这种机制。在保护位中包含主体组的名字和拥有者的名字。

2.2.2访问控制表(ACL)机制

任何一个特定的主体是否可对某一个客体进行访问都可以由访问控制表决定。它表示访问控制矩阵的方法是把一个主体明细表附加在客体上。对该客体的访问权和主体的身份都存在于该表中的每一项。目前,访问控制表(ACL)机制是实现自主访问控制策略的最好方法。

3.DAC的特点

自主访问控制是访问控制中最常见的一种方法,允许资源的所有者自主地在系统中决定可存取其资源客体的主体,即主体有自主的决定权,一个主体可以有选择地与其他主体共享资源,故此模型灵活性很高。但是由于这种自主性,自主访问控制是一种比较宽松的访问控制方式,一个主体的访问权限具有传递性。在自主访问控制中,信息总是可以从一个主体流向另一个主体,即使对于高机密的信息也是如此,因此自主访问控制的安全级别较低。另外,由于同一个用户对不同的客体资源有不同的存取权限,不同的用户对同一客体资源有不同的存取权限,用户、权限、客体资源之间的授权管理非常复杂。

4.DAC的局限性

自主访问控制将赋予或取消访问权限的一部分权利留给用户个人,系统管理者难以确定哪些用户对客体资源拥有访问权限,这样不利于全局访问控制的统一。

在许多系统关系中,用户对它所能访问的客体资源并不具有所有权,系统本身才是系统中资源的真正所有者。

在系统中,一般都希望实现访问控制与授权机制的结果与系统内部的规章制度一致,并且由管理部门统一实施访问控制,不允许用户自主地处理,显然自主访问控制已不能适应这些需求。

参考文献:

[1]张鹏.浅谈计算机访问控制技术[J].科技信息(学术版),2008.

[2]范九伦,等.访问控制技术研究进展[J].小型微型计算机系统,2004.

[3]窦燕.身份认证与访问控制系统的研究与实现[D].北京大学,2004.

[4]李晓林.信息系统中基于角色的访问控制[J].微机发展,2004.

基于角色的访问控制模型研究 篇4

访问控制在Web访问中占据重要的意义,其准确性直接关乎信息数据的安全性,其实现方式又关乎控制的管理灵活性。访问控制的方式主要体现为3种形式,DAC(Discretionary Access Control,自主访问控制),MAC(Mandatory Access Control,强制访问控制)和RBAC(Role-Based Access Control,基于角色的访问控制)。其中,强制访问控制系统直接将权限分配给用户,虽然直接可行,但是管理起来较为麻烦,当用户数量达到一定程度越发棘手。RBAC的出现有效地解决了实际应用过程中产生的这些问题。通过将主体,客体分类成用户,角色,权限3大块,进而基于此分配用户不同的角色,对不同的角色分配不同的权限,整个系统模型得以灵活地管理权限的分配,保证了访问控制的有效性和准确性。简单说,当一个组织机构的人员变动时,只需要对用户角色的分配,角色权限的分配稍加调整,就可以解决相应问题。整个过程实现了用户权限的逻辑分离,降低了系统的维护成本,增强了可操作性。

然后在实践中,依然可以发现以下问题:

(1)简单说,一个用户可以分配多个角色,在某些情况下,管理员可能发现,在此模型的基础上,系统分配权限的粒度并不充分。试想管理员对用户A分配的角色并没有满足充分地要求,需要微调,以对原用户进行更加细腻的约束。于是建议基于RBAC模型,采用适当的MAC规则加以辅助,具体看正文。

(2)在实际的网络访问中,如果没有特别的处理,来访的客户应该是平等的。提出在角色设置的时候可以适当的引入访问优先级。举个例子,角色中的user,manager和systemmanager在同时登录访问系统时应该被置于不同的优先级,从而得到不同的响应——高级管理者应该被系统优先接纳,反之亦然。

2 相关技术

自从最早的RBAC模型提出以来,在文献[1]中,Sandhu等人的模型统一了人们的认识,建立了相应的标准。而文献[2]则具体阐述了RBAC的建议标准。平坦型,层次型,约束型,对称型等具体的划分,使人们的认识更加清晰。简述如表1所示。

基于此有文献[3]形象地称之为RBAC0,RBAC1,RBAC2,RBAC3,并且用图形形象地表现出来,如图1所示。

其实现则主要体现在图2中:管理员通过分配用户的角色、分配角色的权限,达到了用户和角色的逻辑分离,使得数据的访问控制更加完善,降低了维护人员工作的复杂度,提升了管理的灵活性,而各个模型的管理不同又得以很明显的表示。

随着研究的深入,NIST版本的RBAC模型又基于前人工作出现,具体体现为核心RBAC,层次型RBAC,静态职责分离(static separation of duty SSOD)关系,和动态职责分离(dynamic separation of duty DSOD)关系,具体说来四个模型组件又和先前的RBAC模型相应的对应,这些文献[2]都有细说,此处略过。

文献[3]提及的整个模型的实现策略——安全Cookies,智能认证和LDAPS 3种实现方法,使得整个模型得以具体实现。由于RBAC控制策略的有效性,近年来被成功的应用于大型网站和一些系统软件中,而这些工作又反过来促进了RBAC研究工作的深入。比如文献[4]在身份认证上巧妙的采用安全cookies机制,实现对服务器和客户端的双向认证,有效防止黑客侵入,保证了通信的安全。但是相关的问题依然存在,比方说一个角色被分配了相关的权限,被分配此角色的用户就会无限的享受此权限效力。如果说一个用户只有在工作中,或者休息中,才能享受这些权限,那么原先的模型便不足以更细粒度的刻画这种约束。文献[5]中基于角色访问控制提出时间特性的概念,对原有模型进行时间特性的扩充,规定在特定的时间范围内权限的具体约束,从而保证会话的一致性,提高了访问控制的操作性。针对此种现象,也有学者提出基于规则和角色的访问控制,即在RBAC的基础上,扩充规则特性,规定在某个任务进行时才可以履行某个权限,这一点文献[6]有着详细的阐述,并且提及的相关概念中使能型权限,激活型权限和限制型权限很好的阐述了原模型应用中的一些不足,并给出了具体的新的拓展。

在此注意到,引言中提到的问题需求,与文献[6]中的面临问题确有相似之处:(1)虽然角色拥有所请求操作的相应权限,但能否真正执行操作要根据系统当前的状况决定。(2)不同用户行使同一角色的权限时能操作的客体集不完全一样,在此基于以往学者经验,特提出一种新的约束机制,即在传统的RBAC基础上,引入强制访问约束,以供参考。具体如图3所示。

具体说来就是针对RBAC的操作不足,在原模型的基础上引入强制访问约束。在Mac约束中可以具体规定具体用户的访问粒度,比如时间权限,任务特性,或者某个用户对具体对象object的约束控制。举个例子,管理员已经对某些用户权限的管理做好了分配,但实际应用中发现了不足,可能要针对用户A进一步限制,这时不需要改变其角色配置,仅仅在相应的Mac约束中加以说明,然后经后期的约束聚合,就可以达到灵活的访问控制。这样不至于遇见一个不合适的用户权限分配,就创造一个新的角色。此时,角色的管理更加方便。

在此Mac约束的引入,可以明显提高访问控制的灵活性,又可以在系统允许范围内,适当的改善而又不会明显提高工作量、增加问题的复杂度。模型实践时,在访问具体对象时只需在原有的RBAC的基础上,将Mac约束和原先分配好的约束进行合并操作,得出的新的约束就是改进后的细粒度权限分配。

同时,又在角色集合上绑定优先级,从高到低优先级依次可设置为0,1,2,3等。以便服务器进行不同级别的响应,提高高优先级成员的访问速度。

3 模型的相关定义和实现

用户集:U={u1,u2,u3,……}.u1,u2等即RBAC中的普通用户,U为所有用户的集合。

角色集:R={r1,r2,r3,……}.r1,r2等即RBAC中的普通角色,如员工worker,管理者manager,超级管理员super_manager等,R为所有角色的集合。

权限集:P={p1,p2,p3,……}.p1,p2等即RBAC中的普通权限,比如对数据库的增、删、改、查,对网页信息的浏览,打印等操作。

优先级集合:Pre={n1,n2,n3,……}.其中n1到n3可依优先级从高到低设定为0,1,2具体应用时可以实际情况自行分配。

角色优先级绑定集合Rp={,,,……}.即对角色r1分配了n1的优先级,即对角色r2分配了n2的优先级,同理类同不赘述。当然在用户分配时针对一个用户多个角色的分配的情况,可对该用户默认设定为n1,n2等中的最高优先级n,暂记为n=max{n1,n2,……}。此项工作在最终权限判定时可以简单的优先级判定算法实现。

Mac约束集:UP={,,,……}.其中,即对用户u1在t1到t2时间段的p1权限进行限制,bool值为真即为允许操作,bool值为假即为禁止。同理,即为对用户u2在t3到t4时间段的p2权限进行限制,bool值为真允许操作,反之禁止,其它类同不赘述。由于实际操作的环境不同,此处仅对用户权限在某个时间段内某个权限进行约束,实际操作时可根据具体情况灵活扩展mac约束的子项,可以基于任务特性,也可以基于工作流,周期等。只是简要介绍一种新的模型,新的约束机制。

下面以一个正在开发的Web访问控制系统为例,介绍下其访问控制流程并简述如下:

(1)用户登录,进行身份验证。

(2)验证成功则跳转访问首页,否则报错,告知重新登录。

(3)在访问首页用户可以根据自己的需要进行相应的操作,比如对数据object的打印,浏览,增、删、改、查操作,当用户user进行某项操作时,询问数据库RBAC控制模块及mac约束模块,两模块约束进行叠加,得出当前用户user的访问权限是否为真。为真允许操作,反之则进行报错,告知无权访问。

(4)用户安全退出。

其流程图简述如图4所示。

一个相应的判定算法:

4 结语

首先,对RBAC的概念进行了深层的认识,仔细分析了其原型的产生,发展,以及良好管理效力所显示的强大生命力,并且跟据前人的成果,分析了原模型在实际操作中的不足之处,阐述了基于时间特性,基于任务工作流和基于规则的相关改进工作,并进行了相关的说明。在此基础上针对原模型的功能不足,提出了一种强制约束(MAC约束)与基本RBAC相结合的模型,使得用户,角色,权限的管理更加灵活,更加符合实际操作。

相关研究文献[7]中的提到的RBAC的细粒度控制研究工作,与本模型有共通之处,但也有区别。共同点皆是在原有的RBAC模型基础上引入细粒度操作,区别即前者是对资源访问权限进行的分解,细化,而是在相对粗粒度(即原模型)的基础上,引入了用户,权限间的直接约束,弥补了原模型的不足。而且值得注意的是,提及的MAC约束的具体的约束规则可根据用户需要灵活扩展,比如加入时间特性,任务流特性等,具有一定的适应能力和良好的可操作性。

在此,基于文中提及的改进型RBAC模型,正在探索相关系统的具体实现。相关的策略表示,具体的MAC实现和所有约束的聚合将是研究工作的重点。

参考文献

[1]Ferraiolo DF,Sandhu R,Gavrila S.Proposed NIST standardfor role-based access control.ACM Transactions on Informa-tion and System Security,2001,4(3):224-274.

[2]薛伟,怀进鹏.基于角色的访问控制模型的扩充和实现机制研究.[J].计算机研究与发展,2003,40(11):1636-1642.

[3]J Park,R Sandhu1 RBAC on the Web by smart certificates1In:Proc of the 4th ACM Workshop on Role2Based AccessControl1 Faixfax,VA:ACM Press,19991:1-9.

[4]桂艳峰,林作铨.一个基于角色的Web安全访问控制系统[J].计算机研究与发展,2003,40(8):1187-1194.

[5]黄建,卿斯汉,温红子.带时间特性的角色访问控制[J].软件学报,2003,14(11):1945-1954.

[6]芮国荣,邢桂芬.基于角色和规则的访问控制[J].计算机应用,2005,25(4):864-866.

CISCO控制VTY访问 篇5

实验拓扑如下:

实验目的:学习指定源IP可TELNET路由

实验要求:从FA0/0口只有192.168.2.100/24这台PC可以telnet到router上,

首先配置网络可通

--- System Configuration Dialog ---

Would you like to enter the initial configuration dialog? [yes/no]: no

Router>en

Router#conf t

Enter configuration commands, one per line. End with CNTL/Z.

Router(config)#hostname r1

//修改路由器名称为r1

r1(config)#no ip domain lookup

//输错命令不进行域名查询

r1(config)#line console 0

//进入管理控制台接口配置

r1(config-line)#logging synchronous

//日志进行同步

r1(config-line)#exit

配置接口地址:

r1(config)#interface fastEthernet 0/0

//进入接口视图

r1(config-if)#ip address 192.168.2.1 255.255.255.0

//配置IP地址

r1(config-if)#no shutdown

//开启接口

Mar 2 06:24:23.795: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up

//配置访问控制列表:

r1(config)#access-list 1 permit 192.168.2.100 0.0.0.0

//配置ACL列表只允许192.168.2.100这个IP通过

r1(config)#line vty 0 4

//进入虚拟控制台配置

r1(config-line)#password cisco

//配置telnet的登录密码

r1(config-line)#login

//允许远程登录

r1(config-line)#access-class 1 in

//将访问控制列表应用到VTY的进口方向

配置完毕,进行测试

192.168.2.99登陆不到设备上,换个100测试下

点击回车

验证成功,没有问题!!!

第一次做,请各位指正

角色访问控制论文 篇6

在RBAC中,权限被赋予角色,而不是用户。当角色被指定给一个用户时,此用户就拥有了该角色所包含的所有权限。RBAC约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。在NIST标准[1]中,约束包括静态约束和动态约束。

NIST给出了标准RBAC模型,在此基础上,人们提出了各种扩展模型,对RBAC模型的描述能力进行了扩充,使之适用于不同的应用需求。

现有的扩充模型中都没有引入空间的概念,因而模型中没有考虑对于不同的空间需求而引起模型的动态变化,并且模型的授权约束与空间无关。这两点极大地削弱了系统的安全性和模型的描述能力。在本文中,我们在原有的角色访问控制的形式化表达的基础上,作空间特性的扩展。

1 RBAC模型

NIST的RBAC参考模型包括核心RBAC、层次RBAC、静态职责分离和动态职责分离四个模型构件,分别描述RBAC系统某一方面的特征。在构造实际RBAC系统时,除核心RBAC构件是必选的,其它构件都是可选的。

1.1 核心RBAC

核心RBAC构件是任何RBAC系统都必须具备的基本需求,包括五个基本要素集:用户(USERS)、角色(ROLES)、对象(OBS)、操作(OPS)和访问权限(PRMS)。核心RBAC的结构如图1所示。

1.2 层次RBAC

在角色的层次结构中存在两种继承关系:访问权限的继承关系与用户的继承关系。由于实际组织中角色上下级关系常常存在某些限制,RBAC2001建议标准将角色层次区分为通用角色层次和限制角色层次。通用角色层次规定角色层次可以是任意的半序关系,因而包括多重继承。限制角色层次要求在角色层次上施加某种限制,通常是为了简化角色层次结构,如使角色层次成为树形结构。图2表示层次RBAC的结构。

1.3 有约束的RBAC

有约束的RBAC规定在RBAC模型上实施职责分离机制。实际组织中的岗位职责有可能是互相排斥的,解决这种利益冲突的办法是让不同的角色/用户承担互斥的职责以阻止非法操作。RBAC2001建议标准引入两种职责分离机制:静态职责分离和动态职责分离。

· 静态职责分离SSD(Static Separation of Duty Belations)

由于层次RBAC中的继承关系的存在,SSD必须考虑继承关系的影响,必须确保用户/角色的继承不会破坏SSD关系。图3是层次结构中的SSD关系。

· 动态职责分离DSD(Dynamic Separation of Duty Relations)

RBAC2001中的DSD是会话与角色集间的一种约束机制,如图4所示。

RBAC2001建议标准的职责分离原则主要包括互斥角色、最小权限和角色基数等约束机制。在有些文献中还提到权限基数、角色容量、先决条件、运行时间等约束机制。

从上节的陈述可以看出,NIST的RBAC模型并未涉及到访问的空间特性。

2 对角色授权约束及空间特性的分析

在对NIST RBAC模型中引入空间特征后,它就具有了更加灵活的刻画显示系统中授权管理的能力。本节对角色授权约束作相应的扩展,以适应引入空间特性的需要。

2.1 引入空间的授权约束

为了对RBAC系统作空间扩展,我们必须考虑对授权约束作相应的空间扩展。首先根据约束的空间特性,空间约束可分为激活空间范围约束、激活空间节点数量约束和激活空间范围内激活空间节点数量约束。

(1) 激活空间范围约束

该类约束规定用户、角色或者权限只能在特定的空间范围内可以激活。如在有空间限制的企业中即只允许特定地址或地址区间的用户、机器等访问该系统。

(2) 激活空间节点数量约束

该类约束规定同时访问该系统的用户地址数量不能超过一个给定的数值。可用该类约束限制同时介入该系统的地址数量以防协同作案并产生严重后果的可能。

(3) 激活空间范围内激活空间节点数量约束

该类约束规定用户、角色或者权限在特定的空间范围内同时激活的地址数量不能超过一个给定的数值。

2.2 空间约束的语义

对同一个空间约束,有两种不同的语义。第一种是该约束在约束的空间范围内总成立。第二种是该约束在约束的空间范围内可能成立但也可能不成立。例如:如果规定用户只能在特定的地址范围内激活自己的角色。但用户在实际工作中当然可以不激活自己的角色。

在形式化建模的过程中,我们可以通过逻辑运算,将所有第二种语义的空间约束改造成第一种语义的空间约束。

3 对RBAC的空间扩展(SRBAC)

本节对 RBAC 作空间上的扩展。首先我们对上一节提到的多种空间约束提出了形式化的定义。针对这些空间约束,我们对会话和全局系统状态空间也作了扩展,以实现文中提出的解决计算空间约束变化的几个算法。

3.1 空间系统定义

定义1 空间地址序列

SE={IPi|iN},是空间中所有地址集合。IPi代表地址空间中的一个IP地址,为一个四维向量IPi={ai,bi,ci,di}。我们定义空间中的<关系如下:

i,jN,∀IPi,IPjSE,IPi<IPjai<aj|ai=ajbi<bj| ai=ajbi=bjci<cj|ai=ajbi=bjci=cjdi<dj

S=seq(se)表示由空间地址构成的地址序列。我们要求序列中的元素是严格递增的。

定义2 空间范围定义

SR={(IPi,IPj)|IPi,IPjS,IPi<IPj}空间范围是由两个空间地址构成的区间。

SRS=2SR表示空间范围构成的集合。

3.2 SRBAC的模型

SRBAC继承了RBAC的所有元素,并作了相应的扩充。

3.2.1 SRBAC约束的构成

在第2节中,我们对SRBAC中的授权约束已做过讨论,本节将对空间约束给出一个形式化的描述。我们用C表示所有经过一阶谓词扩展后所描述的约束集合。SC表示所有SRBAC中的空间约束。

定义3 空间约束谓词定义

In_RangeC×SRS表示约束C在指定的空间范围集合SRS内必须成立。

N_SpaceC×N,N_Space(c,n)表示约束c最多只能在n个地址中激活。

SR_N_SpaceSRS×C×N,SP_N_Space(c,{IPi,IPj},n)表示约束C在指定空间范围内最多能激活n个地址。

定义4 空间约束(S_C)定义

S_C=S_S_C|M_S_C其中:

S_S_C=In_Range(C,SRS)

M_S_C=N_Space(C,i)|Sr_N_Space(C,SRS,2N)

3.2.2 SRBAC 的形式化

引入空间特性后的RBAC系统,会话在对系统的空间特性的研究中占有重要地位,整个模型的空间特性集中地体现在会话的空间特性上,所以要对会话作出相应的扩展。

定义5 session的扩展

session由以下7元组来描述,<users,roles,ua,pa,s_c,sc_i,task>。其中users,roles,ua,pa分别是全局系统中相应集合的子集,表示该会话所允许的用户、角色、用户角色的映射关系和角色权限映射关系。 s_c表示该会话在运行时必须满足的空间约束。sc_i记录该会话的状态。task表示会话需完成的一系列操作。

定义6 函数的扩展

currentip:ϕ→SE返回当前IP地址

in_range:表示该地址在此空间范围内

not_in_range:表示该地址不在此空间范围内

用户也可根据自身需要扩展相应的函数。

定义7 扩展后的系统状态空间

OLDS={si|iN}表示系统中已结束的会话集合。

BLOCKS={si|iN}表示系统中由于空间约束无法进行而阻塞的会话集合。

CURRENTS={si|iN}表示系统中当前正在进行的会话集合。

ERRORS={si|iN}表示系统中由于空间约束或其他原因而无法进行的会话集合。

以上集合互不相交。

此时,我们用state表示一个系统状态,states表示系统的所有状态空间:

state={U,R,P,UA,PA,SA,RH,CURRENTS,BLOCKS,ERRORS,S_C,S_IPS}

states=2state

4 SRBAC系统状态改变

4.1 保持空间约束的算法

SRBAC状态改变包括两类变化,普通RBAC的状态转变和有空间特性的系统状态的变化。本文主要讨论第二种变化。

每当系统有状态变化时,都应判断系统状态的合法性。此时我们根据每个空间约束,把相关会话放入相应的会话集合中作进一步处理。

4.2 会话的状态变化

在系统正常状态下,会话将在ERRORS,OLDS,CURRENTS,BLOCKS这4个会话集合中变化。当系统创建一个会话时,将根据会话的空间约束是否满足而将该会话放入CURRENTS或BLOCKS中。如果会话属性不发生变化,会话可能在CURRENTS或BLOCKS两个集合中迁移零次或多次,并最终将由CURRENTS中正常结束而被移动到OLDS中,或由于无法继续运行而被移动到ERRORS中。如果会话属性发生变化,也可能从BLOCKS中直接迁移到ERRORS或OLDS中。图5显示了会话的状态变化及引起状态变化的空间约束类型。

4.3 系统会话调度算法

对单会话空间约束来说,会话调度较为简单。在该会话被激活时进行判定即可。对于多会话空间约束而言,由于其空间约束涉及所有与该约束相关的会话,故除了单会话空间约束外,当一个新会话激活该约束、一个与该约束相关的会话暂停或终止运行时,都必须重新计算并调度。表1列出了三类空间约束的相应判定时机。

以下给出了系统会话的调度算法:

算法1 系统会话调度算法

5 总 结

SRBAC在RBAC基础上作了空间特性方面的扩展。使得原系统具备了更加丰富、更加实用的描述能力。SRBAC对约束、会话和系统状态空间本身进行了空间扩充。解决了有关访问控制中有关空间约束方面的需求,能够较好地应用于分布式访问控制。同时文中还提出了方便有效的会话调度算法,解决了空间授权约束和会话的状态转变问题。

同时,在会话的控制与恢复以及系统的一致性状态维护方面还有许多工作需要做进一步的研究。

摘要:基于角色的访问控制近年来得到了广泛的研究与发展。提出了一个引入空间特性的角色访问控制模型,在模型中对原有授权约束添加了空间特性,并提出了相应算法解决了空间授权约束和会话的状态转变问题。

关键词:访问控制,角色,会话,空间约束

参考文献

[1]Ferraiolo D,Sandhu R,et al.Proposed NIST Standard for Role-Based Access Control Standard,ACMTransaction on Information and Systems Security,2001,4(3).

[2]Osborn S,Sandhu R.Configuring role-based access control to enforce mandatory and discretionary access control policies.ACMTransactions on Information and System Security,2000,3(2):85-106.

[3]Ravi Sandhu,Venkata Bhamidipati,Qamar Munawer.The ARBAC97model for Role-based administration of Roles[J].ACM Transactions onInformation and System Security,1999,2(1):105-135.

角色访问控制中的职责分离约束 篇7

(1) 在用户和权限之间引入角色, 用户不直接拥有权限, 而是通过扮演角色间接拥有角色所拥有的权限, 从而简化了系统管理;

(2) 通过分析企业现有业务流程, 构建符合企业业务流程的角色, 并给角色分配必要的权限, 能够更好地反映企业业务逻辑, 从而有利于提高企业生产力和减少新员工的试用期;

(3) 基于角色的访问控制系统通过引入一系列的访问控制约束, 从而提高了系统的安全性和完整性, 并能在一定程度上简化系统规则的调整。

基于此本文在介绍基于角色访问控制系统中约束的重要性基础上, 对基于角色访问控制系统中的职责分离约束进行了综述, 并对其未来的研究方向进行了展望。

1 访问控制系统中的约束

基于角色访问控制系统, 通过在用户和权限之间引入角色的概念, 从而使得用户和一系列的角色相关, 角色和一系列的权限相关, 进而使得用户通过所拥有的角色集获得在系统执行任务所需要的权限结合。由于基于角色访问控制系统所具备的一系列优点, 从而得到越来越多的关注和研究, 也逐渐成为企业安全应用的首选模型。

基于角色访问控制系统模型包含核心角色访问控制模型RBAC0 (Core RBAC) , 其定义了基于角色访问控制系统所包含的必要元素及元素之间的相互关系, 层次角色访问控制模型RBAC1 (Hierarchal RBAC) , 其定义角色之间的相互继承关系, 使得用户通过角色间的继承进而获得低级角色, 角色限制模型RBAC2 (Constraint RBAC) , 其定义了基于角色访问控制模型下的一系列约束规则, 统一模型RBAC3 (Combines RBAC) , 该模型是RBAC1和RBAC2模型的融合, 其结构图如图1所示。

基于角色访问控制模型中的约束是访问控制机制得以保障的一个重要因素, 如果基于角色访问控制系统离开或者缺乏系统所规定的一系列约束条件, 那么其系统本身的安全性和完整性将不能保证, 从而也无法体现其相对于传统访问控制机制的优点;其次, 基于角色的访问控制系统可以支持最小权限原则、职责分离原则和数据抽象原则。如在某个基于角色访问控制系统中, 用户需要获取的权限组合为RQ={p1, p2, p3, p4, p5}, 假定该系统中角色r1所拥有的权限集合为{p1, p2, p3}, 角色r2所拥有的权限集合为{p3, p4, p5}, 则要确保该用户能够完成系统所需要的任务则必将同时拥有角色r1和角色r2, 然而如果角色r1和角色r2为互斥角色的话, 而将他们同时分配给用户的话, 则系统的安全性需求不能保证, 由此可见基于角色访问控制系统中的约束对保证系统的安全性具有举足轻重的作用;再者, 针对现有企业中拥有众多的用户和权限及角色, 从而造成用户角色分配关于复杂的问题, 基于角色的访问控制系统通过引入约束实现了系统角色分配权限的下方, 从而确保了系统高效地进行角色分配。

2 职责分离约束

在基于角色访问控制系统中约束的研究中, 由于职责分离约束在基于角色访问控制系统中保证信息安全所处的重要地位, 从而使得其逐渐成为基于角色访问控制系统中所有约束中研究的重点。基于角色访问控制系统中职责分离约束的研究主要分为三大类:一类为单自治域中的职责分离约束研究;二类为多自治域中的职责分离约束研究;三类为职责分离约束的生成研究。

2.1 单自治域职责分离约束研究

单自治域职责分离约束主要包括静态职责分离约束和动态职责分离约束两大类, 其中静态职责分离约束由Ferraiolo于1995年提出, 该约束指用户在拥有某个角色的同时必须确保其拥有的该角色不能与用户所拥有的其他角色之间是互斥的, 其目的是保证在完成一个安全任务或者相关工作时, 至少需要两个或者更多的人才能够拥有完成该项任务所拥有的全部权限, 从而来保证关键任务的安全性需求。例如角色r1代表企业某一部门会计所对应的角色, 而角色r2代表该部门出纳所对应的角色, 则角色r1和角色r2不能分配给同一个用户。而动态职责分离约束则允许用户同时拥有互斥的角色, 但是同时强调用户在执行任务的同一个会话过程中不能同时以两种互斥的角色身份出现。例如角色r1代表某次运动会中运动员所对应的角色, 而角色r2代表该次运动会中裁判所对应的角色, 则初始化时运动员角色r1和裁判员角色r2可以同时分配给同一个用户, 而该用户在具体比赛的过程中只能够以运动员身份或者裁判员的身份出现。

2.2 多自治域职责分离约束研究

随着信息技术和网络通信技术的快速发展, 使得不同部门、不同机构乃至不同自治域间信息的共享成为可能, 进而推动多自治域间信息共享及应用系统的不断发展, 从而对跨自治域间信息共享过程中的安全问题提出了更高地要求。基于此, 2000年Kapadia等人提出了多自治域间实现角色动态映射和转化的模型IRBAC2000, 该模型通过传递关联和非传递关联实现不同域角色间的转化, 从而使得外域的用户通过域间角色的映射在本域中扮演对应角色, 进而执行相应权限, 完成相应任务。而在具体的多自治域系统中, 可能存在某项任务的完成需要多个域中的不同角色配合来完成, 因此常规的职责分离约束已经不能满足多域间的需要, 例如进行项目评审时, 就需要评定委员会成员的构成不能全部来自同一个自治域, 以避免不科学的评审结果发生。基于此, 常规的职责分离约束规则已经不能满足该具体要求, 因此可定义满足多自治域环境下的一般职责分离约束规则为:

定义一:在具有n个权限的权限集合{p1, p2, …, pn}和m个域{D1, D2, …, Dm}中, 不允许少于k个来自不同域中的用户共拥有权限集合中的全部权限, 这样的原则被称为一般意义上的多域静态职责分离约束, 该一般意义上的多域静态职责分离约束可表示为:

其中{p1, p2, …, pn}表示基于多自治域角色访问控制系统中的一组权限集合, {D1, D2, …, Dm}表示多自治域系统中的不同自治域, m和k是正整数, 且满足2≤k, 2≤m, 该一般意义上的多域静态职责分离约束禁止少于k个域的用户共同拥有权限组{p1, p2, …, pn}中的所有权限。

更严格的可以定义满足多自治域环境下的严格职责分离约束规则为:

定义二:在具有n个权限的权限集合{p1, p2, …, pn}和m个域{D1, D2, …, Dm}中, 不允许少于ki个来自域Di中的用户共拥有权限集合中的全部权限, 这样的原则被称为严格意义上的多域静态职责分离约束, 该严格意义上的多域静态职责分离约束可表示为:

其中{p1, p2, …, pn}表示基于多自治域角色访问控制系统中的一组权限集合, {D1, D2, …, Dm}表示多自治域系统中的不同自治域, m和{k1, k2, …, km}是正整数, 该多域静态职责分离约束禁止少于ki个来自域Di中的用户共同拥有权限组{p1, p2, …, pn}中的所有权限。

2.3 职责分离约束的生成研究

职责分离约束生成研究文献较少, 其中文章讨论了互斥权限和互斥角色的定义, 并根据权限和角色之间互斥的原理, 指出要获取用户和权限分配表中隐含的权限组之间的互斥关系, 就是发现那些在分配关系中用户不能同时拥有的权限组, 并基于此通过关联规则算法Apriori生成满足最小加权支持度的互斥角色约束。然后上述的互斥角色和权限约束并没有考虑权限的权重, 从而造成生成的互斥约束不够完备, 基于此文章定义了权限的权重并在权限的权重基础之上重新定义了基于权限权重的职责分离约束规则的生成算法。

定义三权限pi的权重定义为

其中, ω0表示依据先验知识所确定的权限pi的初始权重, f1 (ua) 代表用户属性对权限pi的权重的影响程度, f2 (opa) 代表操作属性对权限pi的权重的影响程度, f3 (oba) 代表操作对象的属性对权限pi的权重的影响程度;α, β, γ和δ分别用来代表上述影响对权限权重的影响程度。

3 结语

基于角色的访问控制技术由于其自身的优点从而成为众多安全应用的首选模型, 而要确保安全系统的安全性和完整性得以实施, 则离不开系统所制定的一系列约束规则, 尤其是职责分离约束规则。与此同时, 随着对等计算、网格计算、云计算以及物联网等大型网络应用的快速发展, 职责分离约束规则在新兴网络环境下将面临更复杂的新问题, 这些都值得我们进一步深入研究和更广泛的讨论。

参考文献

[1]National Computer Security Center.Aguide to understanding discretionary access control in trusted system.NCSC-TG-003, September 1987, 1-29.

[2]David F.Ferraiolo, Janet A.Cugini and D.Richard Kuhn.Role-based access control (RBAC) :Features and motivations, in:proceedings of 11th annual computer security APPlications conference, 1995, 241-248.

[3]R.S.Sandhu, E.J.Coyne, H.L.Feinstein and C.E.Youman.Rolebased access control models.IEEEComputer, 1996, 29 (02) :38-47.

[4]Ansi, American national standard for information technology-role based access control.ANSI INCITS359, 2004, 1-5.

[5]Li Ruixuan, Lu Jianfeng, Li Tianyi, et al.An APProach for Resolving Inconsistency Conflicts in Access Control Policies.Chinese Journal of Computers, 2013, 36 (06) :1210-1223.

[6]Li, N., Bizri, Z., Tripunttara, M.V.On Mutually-exclusive Roles and Separation of Duty[C].In:Proceedings of the 11th ACM Conference on Computer and Communications Security, ACM Press, New York, 2004:42-51.

[7]K.Apu, J.Al-Muhtadi, R.Campbell, et al.IRBAC 2000:Secure Interoperability Using Dynamic Role Translation.Technical Report:UIUCDCS-R-2000-2162, 2000:1-8.

[8]Xiaopu Ma, Ruixuan Li, Zhengding Lu, et al.Global Static Separation of Duty in Multi-domains[C].In:Proceeding of the 2009 International Conference on Multimedia Information Networking and Security, Wuhan, China, 2009:18-20.

[9]Xiaopu Ma, Ruixuan Li, Zhengding Lu, et al.Mining Constraints in Role-Based Access Control.Mathematical and Computer Modelling, 2012, 55 (1-2) :87-96.

角色访问控制论文 篇8

Web服务是发布在网上的操作接口,采用XML文档和SOAP协议进行信息交互[1]。由于复杂的网络环境,以及协议具有的开放性和标准化特点,Web服务的安全性非常脆弱,这是影响其规模化应用的主因。近年来,Web服务访问控制技术已成为一个研究热点,其目标是保证服务资源只授予合法的访问主体,防止任何的未授权访问。

与传统应用相比,Web服务的访问控制面临着诸多挑战[2],如跨域访问控制、权限动态调整、与遗留系统整合,以及技术标准化等问题。目前已有许多学者从不同角度进行了研究。常见的有,基于身份的访问控制要求将权限和主体的身份关联起来,包括采用集中式身份管理和分布式身份联盟[3];基于角色的访问控制则根据主体的角色特征进行访问授权[4];基于属性的访问控制则是根据参与主体的某些特征属性制定授权策略[5]。

基于角色的访问控制模型RBAC及其扩展模型在传统的应用中已经比较成熟,将其引入到Web服务系统中的关键问题是如何将访问主体映射到合适的角色。文献[6]根据主体的身份信息为其分配角色,主体在激活角色时系统产生一个对应的执行者对象。文献[7]将Web服务分为单服务和组合服务两种类型进行研究,针对不同的服务客户,分配不同的角色。文献[4]针对Web服务业务处理过程,提出将参与业务过程的合作伙伴映射到角色,然后根据角色进行授权。类似这些面向Web服务的RBAC演化模型已经基本解决了Web服务客体的静态授权等问题,但是还存在以下两个方面的问题:

(1) 模型对基于角色的权限描述是粗粒度的,这使得为某个Web服务访问主体授权时只能达到角色层次,或者把角色的权限全部授予,或者全否[2,6,7]。目前还无法描述角色内的任意部分权限,但是在有些情况下只向主体授予角色的部分权限是必要的,这既能够避免创建更多新角色而造成更高实施和维护成本,又可使系统授权更加灵活方便。

(2) 静态的角色/权限和主体/角色映射使得主体的权限变更难以在应用中动态实现。目前,主体一旦分配了某个角色后,即拥有了对应的全部静态权限,还无法对主体的行为状态、系统的上下文环境等变化做出相应的调整[4,6]。

本文引入了量化角色的概念,它是对传统基于角色的Web服务访问控制模型中角色的扩展,能够描述其中任意部分的权限[8],例如对拥有一个Web服务全部权限的角色,可以根据量值实现对该服务的某个接口、属性的某种操作方法进行非常细粒度的访问控制。其意义在于,既提高了Web服务授权的灵活性,不再以角色一概而论,又便于根据环境的变化实现对量值的调整,这是量化角色中增加了量值这一数值属性所独有的优势。

1 细粒度的Web服务权限定义

1.1 RBAC96模型

RBAC96模型[9]是较为成熟的一个基于角色的访问控制模型,它通过两个映射来实现权限的授予:角色到权限的映射,使角色承载一定的权限;主体到角色的映射,使访问主体绑定到某个角色,从而拥有相应的权限。

定义1 RBAC96模型的定义包括集合、关系以及对应的约束,包括:

(1) 用户主体(简称主体)集U={u1,u2,…,um},角色集R={r1,r2,…,rn},权限集P={p1,p2,…,pk};

(2) UAU×R,表示从主体到角色的多对多的分配关系,UA(ui,rj)表示为主体ui分配了角色rj;

(3) PAP×R,表示从权限到角色的多对多的分配关系,PA(r,p)表示为角色r分配了权限p;

(4) Users:R→2U,表示从角色集R到主体集U的映射函数,记为Users(r)={U|(U,r)∈UA};

(5) Permissions:R→2P,表示从角色集R到权限集P的映射函数,记为Permissions(r)={P|(P,r)∈PA};

(6) RHR×R,表示角色之间的偏序关系,可用符号≤表示。(r1,r2)∈RH表示角色r1继承了角色r2的权限,可记为r1≤r2。

1.2 面向Web服务的模型扩展

RBAC96模型对权限的描述过于粗略,没提供精细刻画客体类型和访问方式的方法。而为了支持Web服务的授权,需要对模型进行扩展。本文把Web服务和服务属性当做与传统应用中的功能模块一样的客体,并定义访问模式集,从而扩展模型的适用范围,实现对包括Web服务在内的所有客体的一致管理。

定义2 可访问资源集。指系统中所有可单独标记并能被访问的功能对象的集合,记为FS。包括传统应用中的Web页面、逻辑类和功能模块等,记为FS0,以及Web服务和服务属性。

定义3 可访问Web服务集。指系统发布的所有可访问的Web服务接口的集合,记为WS

定义4 可访问的Web服务属性集。指系统中发布的所有可访问的Web服务属性的集合,它是服务调用过程中信息的承载者,体现为服务调用时的输入参数或返回结果,记为WSA

定义5 访问模式集。指对系统资源的操作类别的集合,包括读、写、执行和删除等,记为AM

因此,模型中的权限集合P可以由系统资源集和访问模式集运算得到:

P=[FS×AM]conditions

=[(FS0∪WSWSAAM]conditions (1)

式中[X]conditions表示对集合X按照条件conditions做选择运算,只保留满足系统要求的权限。P中的元素p是一个由功能fs和访问方式am组成的二元组(fs,am)。

需要说明的是,这种扩展不需要Web服务现有标准做出任何修改。因为系统中的各种集合数据和访问控制程序都存储或运行于服务提供者一端,服务请求主体只需要按照正常方式请求访问,服务提供者会根据主体的角色进行验证并控制访问行为。

1.3 权限量值与量化角色

许多情况下,基于角色的部分授权,以及对访问主体进行部分权限的动态调整是必要的。例如,表1为中石化 “石油地面建设工程定额管理Web服务系统”中的主要角色权限分配表。

同样拥有油田生产单位(OPUnit)的角色,在一定时间内不同Web服务用户可能需要不同权限,例如胜利油田的服务可能拥有全部三项权限,但中原油田的只有定额数据查询(P_QuotaFind)权限;又如,可能因为某服务请求主体做了破坏性删除,或它的网络变差,系统需要调整它的权限。这些需求使得基于角色的部分授权,以及Web服务授权的动态调整是必要的。

RBAC96中的角色r被关联到PA中一组形如(r,p)的元组(这里p包括扩展后的Web服务和服务属性权限),这些元组构成了r的权限源。

定义6 角色的权限源函数rolePS与权限源的基。

rolePS:R→2PA,表示从角色集R到权限源的映射函数,记为rolePS(r)={(r,p)|(r,p)∈PA};运算|r|表示r的权限源的基,即|r|=|rolePS(r)|。

为了唯一标识r的权限源中的元组,为每个元组tuple分配一个数值2i(iN∪{0}),其中N为自然数集,称该数值为元组的权限量值,并规定同一角色的各元组量值互不相同,取值从小到大依次为20,21,…,2|r|-1。

表2列出了为角色权限分配表中各元组分配的量值。

元组的量值由管理员分配和维护。

定义7 权限元组的量值函数tupleQty

tupleQty:PAN,表示从权限源到自然数集的映射函数,记为tupleQty(tuple)={n|nN},该函数将PA中的元组映射到其量值。

定义8 角色权限总量值和总量值函数roleQty

角色具有的权限元组的总量值是该角色权限源中所有元组的量值之和。

roleQty:RN,表示从角色集到自然数集的映射函数,记为roleQty(r)=tupleroleΡS(r)tupleQty(tuple)

通过对普通角色施加量值限制,产生形如(r,k) 的二元组,其中rRkN ∧0 < k<=roleQty (r),它表示由角色r的权限源中的部分元组(可通过k的值运算获得)产生的权限的集合,代表角色的部分权限,通过改变k的值可以调整(r,k)表示的不同权限集合,因此称(r,k)为量化角色,k称为该量化角色的量值。由权限源的量值定义可知,角色的各个权限源中元组的量值各不相同,并且形成一个超递增序列。可以证明,对任意给定的(r,k),方程k=0i<|r|ai2i在{0,1}上有唯一解[8]。给定k后,判断角色r中的某元组是否在量化角色中的方法为:

(1) 解集中若aj1,aj1,…,ajm(0<m≤|r|∧0≤ji<|r|)的值为1,则认为集合{2j1,2j1,…,2jm}是(r,k)的量值集;

(2) 若2i属于(r,k)的量值集,则认为角色r中量值为2i的元组包含在量化角色 (r,k)的权限源中。

例如,量化角色(OPUnit,5)的权限包括{(OPUnit, P_ DataUp),( OPUnit, P_ QuotaFind)};又如量化角色(QCCost,1)仅拥有普通角色QCCost的P_ DataSum部分权限。

定义9 量化角色的权限源函数qtyRolePS

QtyR={(r,k)|rR∧0<kroleQty(r)},表示量化角色的集合;

kseq:QtyR→2N∪{0},表示从量化角色集到量值集的映射函数,用于求(r,k)的量值集,记为:

kseq((r,k))={2i-1|k二进制表示中i位取值1}

qtyRolePS:QtyR→2PA,表示从量化角色集到权限源集合的映射函数,记为:

qtyRolePS((r,k))={(r,p)|(r,p)∈PA

tupleQty((r,p))∈kseq((r,k))}

2 基于角色量值的Web服务访问控制模型

2.1 模型结构

图1为本文提出的基于量化角色的Web服务访问控制模型结构。

该模型包括如下5部分:

(1) 权限生成 通过引入Web服务和服务属性等资源集、访问模式集,实现了对权限的细化扩展,见式(1)。

(2) 角色权限分配 指通过为角色分配权限生成PA集的过程,包括创建普通角色、为角色分配权限,以及对角色中权限元组分配量值。

(3) Web服务主体角色分配 指通过为Web服务主体分配角色建立UA集的过程。这里分配的是量化角色qr(r,k),k限定了Web服务主体拥有的最大权限范围。

(4) Web服务主体登录角色激活 主体通过SOAP协议登录并访问系统,激活相应的量化角色,并产生一个会话。角色激活条件为:

[uUsers(r)]∧[(fs,am)∈qtyRolePS(r,k)] (2)

其中,r为量化角色qr(r,k)对应的普通角色,k为量值,am表示访问fs的操作模式。

(5) Web服务主体权限的动态调整 量化角色中的量值k具有数值属性,是动态可调的,这是量化角色适用于权限动态调整的根本优势所在。

确定了动态调整权限的思路:定义Web服务主体的行为量值,根据请求对象的行为和上下文环境,计算行为量值;依据该量值的变化判断在一定的周期内是否需要修改该服务对应角色的量值。定义Web服务行为量值的计算规则和量化角色的调整方法是关键问题。

2.2 Web服务主体的行为量值及其计算

参考基于信任授权控制模型中的信任值[10],定义了一个能反映Web服务主体访问系统时行为安全性的指标数据,称为Web服务主体的行为量值。

定义10 Web服务主体的行为量值BValue

BValue={(u,β)|uU∧0≤β≤1},表示行为量值的集合,二元组(u,β)表示主体u的行为量值为β;

fBtoRqty:BValue→2N,表示从行为量值集到角色量值集的映射函数,用于根据主体的行为量值(u,β)计算量化角色的量值,记为:

fBtoRqty((u,β))={k|kN}

对于Web服务主体u,计算其行为量值时不同的上下文可能需要不同的行为特征,并采取不同的算法,如图2所示。

定义11 Web服务主体访问系统的上下文Context

Context={(bf,t)|bfBFtT},其中BF表示上下文要求的Web服务主体行为特征子集,T表示计算行为量值时的算法集;

BF={bfi:(fi,wi)|iN},其中fi为Web服务主体的行为特征元素,wi表示计算时该元素所占权重,N为自然数集;

T={t1,t2,…,tj,…,tm},其中tj表示一个具体算法,如加权平均weight法、算术平均average法等。

Web服务主体u在确知环境c(Bfu,t)下,计算行为量值的算法为:

(u,β)c=t(f1,w1,f2,w2,…,fn,wn) (3)

2.3 Web服务主体的量化角色动态调整

本文设计了如图3所示的Web服务主体权限动态调整流程,其中函数fBtoRqty(参见定义10)能够根据行为量值(小数)计算服务主体应该具有的角色量值(自然数)。另外,为了防止权限调整过于频繁,在系统初始化时设定更新周期和行为量值的调整阈值。只有自上次权限调整后的时间超过这个周期,系统才开始计算前后行为量值的差,而且只有当这个差值超过设定阈值后,才计算主体的量化角色的新量值并更新。

3 应用与评价

XACML是一种通用的Web服务访问控制策略语言,它既可以用于描述通用的访问控制需求,也能够用来构建请求访问控制决策的查询报文。实现时,如果构建XACML授权框架,需要按照WSRF构建相应的WS-Resource,即构建与XACML授权框架相对应的有状态资源和Web服务对象。文中模型主要在Web服务提供者的应用服务器端实现,以数据存储和算法验证、Web服务开发为主,这些对于Web服务的各项现有标准完全支持,而XACML等Web服务安全标准可以作为额外的安全机制加以补充。下面是以基于量值的角色部分授权和动态调整为核心的两个实现场景。

(1) 定额系统中Web服务主体的部分授权

场景:胜利油田Web服务用户u_sl拥有OPUnit角色的全部权限,而服务u_zy只可被赋予P_QuotaFind权。据此可分别制定如下的授权票据:

ua1=(u_sl,(OPUnit,7)) (4)

ua2=(u_zy,(OPUnit,4)) (5)

将其加入授权关系UA中,作为访问时验证的依据。

(2) 定额系统中Web服务主体的权限调整

场景:因为主体u_sl在调用Web服务BasicDataMngService时误删除了系统重要数据,系统根据式(3)计算其行为量值降为(u_sl,β)=0.7,变化量Δ(u_sl,β)=1.0-0.7=0.3,大于设定的行为阈值th=0.25,在新周期到来时对u_sl的量化角色进行调整:

ua1=(u_sl,(OPUnit,7))→(u_sl,(OPUnit,4))这样u_sl也仅具有了P_QuotaFind权,系统将更加安全。

Web服务对象的开发仍将关注于系统所要求的功能实现即可。该模型在定额系统中进行了试用,共建立了5个普通角色,并以此为基础定义了12个量化角色,实现了14个主体的预授权,并测试了多种情形下的主体权限调整,试用结果表明该模型对授权的管理方便、操作灵活,系统运行安全平稳。

4 结 语

本文分析了目前基于角色的Web服务访问控制模型在支持细粒度的授权和权限动态调整方面存在的不足,引入了权限量值和量化角色理论,提出了行为量值的概念,建立了一个细粒度的Web服务访问控制模型,并将其应用于中石化“石油地面建设工程定额管理系统”中。理论分析和测试运行情况均表明该模型拥有如下优点:

(1) 通过定义Web服务、服务属性和访问模式集,扩展了权限集的定义,实现了对包括Web服务在内的所有客体的一致管理。

(2) 通过为Web服务权限元组分配量值,实现了对角色内任意部分权限的表达和控制,从而使授权的粒度更加精细,应用更加灵活。

(3) 提出了Web服务主体行为量值的概念,并建立了它与Web服务主体所属角色的量值之间的映射函数,实现了根据Web服务主体的行为和上下文环境动态计算行为量值并调整该服务主体权限的方法。

建立一套完整、合理的Web服务访问主体的行为特征是一个重点和难点问题,改进Web服务主体的行为量值和角色量值之间的映射函数等也是下一步我们感兴趣的问题。

参考文献

[1]Kreger H.Web Services Conceptual Architecture 1.0[S/OL].IBMSoftwareGroup,2001.http://www-3.ibm.com/software/solution/webservi-ces/pdf/WSCA.pdf.

[2]颜学雄,王清贤,马恒太.Web服务访问控制模型研究[J].计算机科学,2008,35(5):38-41.

[3]Union 1T.ITU-T recommendation X.509(08/97)-informationtechn-ology-open systems interconnection–the directory:Authenticationframework[S].Aug,1997.

[4]Liu P,Chen Z.An Access Control Model for Web Services in BusinessProcess[C]//Proceedings of the IEEE/WIC/ACM international Con-ference on Web Intelligence(WI’04),2004:292-298.

[5]Yuan E,Tong J.Attributed-based Access Control(ABAC)for WebServices[C]//IEEE International Conference on Web Services(IC-WS’05),2005:561-569.

[6]Xu F,Lin G,Huang H,et al.Role-based Access Control System forWeb Services[C]//The 4th International Conference on Computer andInformation Technology(TIT’04),2004:357-362.

[7]Wonohoesodo R,Tari Z.A Role-based Access Control for Web Serv-ices[C]//2004 IEEE International Conference on Services and Com-puting(SCC’04),2004:49-56.

[8]翟征德.基于量化角色的可控委托模型[J].计算机学报,2006,29(8):1401-1407.

[9]Sandhu R.Rational for the RBAC96 family of access control models[C]//ACM Workshop on Role-Based Access Control.New York:ACM Press,1996:38-47.

角色访问控制论文 篇9

随着信息技术与网络技术的高速发展, 给人们的工作和日常生活带来便利的同时也带来了大量的安全隐患。对数据的及时性与安全性要求很高的医院信息系统, 面对日益猖獗的病毒与木马以及各种网络攻击手段, 内网的安全性和可靠性是急需解决的问题。

传统的基于RBAC模型[4]的网络访问控制技术在可靠性、易用性、高效性等方面表现出色, 但是在动态调整的灵活性方面出现了不足, 主要表现在以下两个方面: (1) RBAC模型建立在主体-客体访问控制思想上, 采用静态授权方式, 缺乏对角色权限的动态调整能力。 (2) 访问控制策略必须人工定义, 不能根据网络状态的变化进行自增学习。

针对以上的问题, 本文参考了基于行为的网络访问控制技术 (Behavior-Based Network Access Control, BB-NAC) [2,3]的思想, 提出了RB-NAC机制, 其核心思想是建立角色模型来划定权限集, 建立行为簇来动态调整用户权限。RB-NAC弥补了RBAC-based NAC的缺陷, 并加强了对用户实时行为的监控。

二、基于角色与行为的访问控制机制 (RB-NAC) 2.1 RB-NAC的访问控制策略

RB-NAC核心思想是以角色模型来划定权限集, 利用行为簇来动态调整用户可使用的权限, 其体系结构如图1所示。

RB-NAC的访问控制策略主要包括两部分内容: (1) 建立角色访问控制模型 (2) 建立行为簇动态调整用户的权限范围。

1. 建立角色模型主要包括:

定义系统角色, 为角色分配权限, 为用户分配适当的角色。这些操作可以由高级管理员或者某些合适的代理角色来完成。可以利用现有的RBAC模型及其改进版本 (例如ARBAC97) 来建立RB-NAC中的角色模型。RB-NAC具有很强的扩展性, 现有的RBAC-based NAC经过修改后可以很容易的扩展成RB-NAC。

2. 建立行为簇, 根据用户的网络行为动态决定用户可使用的权限, 主要包含三个部分:

分簇[1,5]、计算阈值、动态调整。

(1) 分簇:为每个角色建立簇组, 并为每个簇分配适合的权限。例如, 在角色r中, 其权限集合记为Q, 为角色r建立4个行为簇, 分别标记为c1, c2, c3, c4, 并为每个簇分配适当的权限记为q1, q2, q3, q4, 且每个行为簇都对应一组相似的用户行为特征。每个用户根据其网络行为特征被分配到适当的簇中, 并具有该簇的权限。簇的划分策略, 即用户的行为特征与簇的对应关系可以根据不同的需求来设计。

在准备阶段, 系统需要收集用户的网络行为信息作为动态归簇的依据, 这些信息被称之为行为档案 (behavior profiles) , 简称为BP。BP中包含的是一系列的网络行为的特征值, 例如, 针对80端口的行为的特征值可以是连接不同IPs的总数量、数据包的总数、每个数据流的大小等等。将每个接入设备的BP用一个矢量pi来代表:pi={pi[0], pi[1], …pi[n]}, 其中每个pi[l]代表特征l的平均值l=0..n。系统在准备阶段采集足够多的样本数据, 分布在各个簇中并作为系统的初始数据使用。

(2) 计算阈值:完成分簇之后就获得了簇的信息以及每个簇中的样本数据, NAC的执行点开始计算每个设备的阈值。阈值代表每个设备与同簇中的其他设备之间的最大距离, 如图2所示。在RB-NAC中使用BP代表设备计算阈值, 这些阈值在之后的动态访问控制中起到至关重要的作用。对于每个pi来说, 其阈值的计算公式如下所示:

pi与pj代表两个BP, n代表特征值的数量。公式1用来计算pi与pj之间的距离, 也就是pi与pj之间的相似度。公式2用来计算每个pi的阈值, q代表pi所属的簇中的BP的个数, d代表使用公式1所计算出来的pi, pj之间的距离。

(3) 动态访问控制

完成分簇与计算阈值的工作之后, 系统进入动态访问控制阶段。动态访问控制主要处理两类设备, 一类是新设备 (未提交BP) , 另一类是存量设备 (已提交BP) 。新设备刚进入时系统还无法获知其BP的信息, 可以在簇组中设置一个通用簇用来做过度之用。系统在后续的权限使用过程中, 将新设备的行为特征记下, 并在适当的时候提交BP, 然后分析归簇。进行归簇时, NAC的执行点用公式3计算与新设备的BP最接近的簇 (如图3所示) 。

公式3

其中k代表簇中BP的数目, pnew代表新设备的BP, c[i]代表每个簇i的中心, c[i]的计算过程如公式4所示:

其中cn代表第n个特征值的平均数, q代表簇i中BP的数量。

选出最近的簇之后, 由簇中的所有成员进行投票表决是否接受新设备加入到网络中, 如图3所示。投票的结果决定是否同意让新成员加入。投票的方法按照公式5进行:

其中, q代表簇中成员的个数, ti是pi的阈值 (由之前计算得到) 。v代表投票的结果值, 如果系统要求簇中至少60%的成员投赞成票才允许新设备进入, 则v必须大于0.6。对于存量设备, 当设备经过一段时间后其BP可能发生变化, 这时系统将更新之后的BP提交给NAC执行点, 由NAC执行点通过公式3~5对其进行归簇计算。

2.2增量学习

RB-NAC主要针对访问设备行为信息 (即BP) 进行增量学习。对于新设备, 还未提交BP不能参与簇内的投票, 只有当其提交BP并执行归簇之后才能参与投票。新设备的BP自动添加到所属的簇中, 更新簇的BP集合。对于存量设备, 当其BP信息发生改变时需要重新进行归簇计算, 将旧的BP从原来的簇中删除, 并将更新后的BP添加到新簇的BP集合中。RB-NAC采用增量学习的方式自动对动态归簇策略进行调整已符合当前网络的状态, 提高了系统的灵活性与可靠性。

三、应用实例分析

医院内部某用户拥有对服务器资源进行各种业务操作的权限, 然而在某个阶段, 该用户的设备因感染了病毒而对服务器发起大量的恶意行为, 此时RB-NAC系统检测并发现此攻击行为, 根据其行为的特征将其划分到特定的簇中 (例如簇A) , 由于处于簇A中的设备被限定了一部分的核心权限 (比如访问网络的权限) , 因而可以有效的控制住该设备试图造成的危害, 同时簇A中还保留了该设备其他一部分权限, 在控制用户的异常行为的同时还适当保留了用户的一些基本操作权限。依据用户的行为在簇组内做动态调整从而分配或限制用户的权限, 这种设计方案使得权限随着网络行为的安全等级做动态调整, 提高了系统的灵活性。

四、总结

本文提出了一种基于角色与行为的访问控制机制:RB-NAC机制, 其核心思想是以角色模型来划定权限集, 利用行为簇来动态调整用户可使用的权限, 克服了RBAC-based NAC在动态权限调整方面的缺陷。RB-NAC利用行为簇分配或限制了用户的权限, 并利用用户实时的网络行为特征的变化, 对用户进行动态归簇, 提高了系统的灵活性。此外RB-NAC还能自动完成增量学习, 无需人工干预就能适应多变的网络环境。综上所述RB_NAC机制能有效的加强医院内网的安全性与可靠性。

参考文献

[1]许春根, 黄生, 一种新型的基于角色访问控制的角色管理, 计算机工程, 2003, 29 (8) :26-29

[2]V.Frias-Martinez, S.Stolfo, and A.Keromytis, “Behav-ior-based network access control:A proof-of-concept, ”in Infor-mation Security Conference (ISC) , 2008.

[3]Vanessa Frias-Martinez, Joseph Sherrick, Salvatore J.Stolfo, Angelos D.Keromytis, “A network access control mechanism basedon behavior profiles”, in Annual Computer Security ApplicationsConference (ACSAC) , 2009.

[4]Sandhu R, Coyne E, Feinstein H, et a1.Role-based accesscontrol model[s J].IEEE Computer, 1996, 29 (2) :38—47.

角色访问控制论文 篇10

根据人们认识世界的规律,面向对象的基本思想认为:客观世界是由许多各种各样的对象所组成。每种对象都有各自的内部状态和行为规则,不同对象间的相互作用和联系就构成了各种不同的系统,构成了我们所面对的客观世界。当客观世界映射到数字世界,就构成了各种信息系统。随着信息技术的不断发展和大规模应用,信息系统的安全性越来越突出,同时对信息系统的安全管理也带来了巨大的挑战,对系统的安全控制问题正越来越受到重视。

本文针对面向对象系统进行研究,从信息流的角度研究面向对象系统中的消息传递的可控性问题。由于RBAC96模型并不是为面向对象系统所设计,不完全适应于面向对象系统,本文在对RBAC96模型进行分析的基础上,针对面向对象系统的特点,提出了面向对象的基于角色的可控模型OORBC(Object-Oriented role-based controllability)。该模型能有效地保障面向对象系统中对象与对象之间消息传递的可控性,防止信息的泄漏。

1 相关研究

在面向对象系统中,对象与对象之间的相互交互是通过信息流进行的,因此对信息流进行控制以阻止不安全的信息流从而保证敏感的信息不被泄漏是至关重要的。信息流控制即依据信息系统的安全策略控制信息不能流向违反安全策略的实体。文献[1]最早提出了信息流控制概念。信息流控制方法在保密性模型中已得到了广泛的研究与应用[2]。完整性安全模型的研究借助保密性模型的方法,定义了完整性信息流控制[3]。事实证明DAC和MAC在控制系统内部的信息流方面是有效的。Osborn等人研究证明了RBAC 是一种更一般的访问控制模型[4,5,6] ,他们利用RBAC 模型成功地模拟了MAC 和DAC,即可以用RBAC实现DAC和MAC。因此作为更一般的访问控制模型,RBAC也可用于信息流的控制。文献[7,8,9,10]使用了RBAC控制系统中的信息流。文献[9]定义了一个面向对象的基于角色的访问控制模型,该模型可用于分布式环境,并给出了一个信息流分析方法。文献[10]提出了一个扩展的RBAC模型,该模型可以嵌入到面向对象系统中用以控制信息流,并定义了一种语言OORBACL,该语言使用JAVA作为目标语言用来执行安全的应用。文献中总结了面向对象系统中的信息流控制模型应该具备的五个特征,具体描述如下:

(1) 控制对象与对象之间的信息流;

(2) 通过参数传递控制对象之间的方法调用;

(3) 允许基于用途的方法调用并阻止对象内部的信息泄漏;

(4) 精确控制写入操作;

(5) 防止特洛伊木马。

2 面向对象系统的控制模型定义

文献[10]基于RBAC96模型定义了一个扩展的RBAC模型OORBAC,模型中对于角色以及角色等级的定义比较模糊,利用该模型不能对角色进行有效的管理,由于RBAC中的核心就是角色,因此对于角色关系的管理是比较重要的问题。本文在其基础上进行研究,对角色和角色之间的关系给出了详细的描述,并给出了一个面向对象系统的基于角色的可控模型OORBC。

2.1 原有模型介绍

在文献[10]中,对于面向对象系统,引入了一个信息流控制关系的定义ICRel(Information flow Control Relationship),其用来表达控制信息流过程中类和类之间的关系,具体定义为:ICRel存在于两个类之间,如果这两个类的实例之间可能有直接的消息传递。每个ICRel都对应一个安全策略,类的实例必须遵循这个安全策略。如果类的实例需要遵循多个安全策略,则需要在类和类之间定义多个ICRel,每个ICRel指定一种安全策略。模型的定义如图1所示。

对原有模型的分析:

(1) 在面向对象系统中,对信息流的控制最重要的是对动态实例化和删除的对象之间的信息流的控制。而类之间的关系对于控制对象之间的信息流是极为有用的。由于面向对象系统中类和类之间的关系是错综复杂的,如上所述,如果两个类之间的实例需要遵循多个安全策略时,就需要定义多个ICRel,因此会导致ICRel的数量众多而难以管理。

(2) 在上述模型中,对于角色的定义比较模糊。其角色定义为由ICRel所实例化的Session所关联的对象即为角色,这样每个与ICRel相关联的类的实例化对象均为该Session中的角色,这样就会导致对角色管理的复杂性。

(3) 模型中角色等级的定义为系统中所有类的继承关系,而没有对类的范围进行限定,这样对于角色等级的管理增加了负担。

2.2 面向对象系统的基于角色的可控模型

2.2.1 模型定义

本文提出的面向对象的基于角色的可控模型如图2所示。

2.2.2 形式化描述

模型中的各个元素定义如下:

定义1 Users是用户的集合,用户是对系统中资源对象进行访问的独立主体。

定义2 RoleClasses是角色类的集合,角色类是根据系统中用户的不同身份以及不同权限所建立的类的集合。

定义3 Roles是角色的集合,角色是角色类的实例化。

定义4 Perms是权限的集合,权限是用户对系统资源进行访问的许可。

定义5 Sessions是会话的集合,会话代表了一次实例化的过程。这里要求一个用户在一次会话中只能具有一个角色,在这点上区别于RBAC96模型。

OORBC模型中各组件之间的关系如下表示:

定义6 UA(用户分配):UAUsers×Roles,是用户和角色之间的多对多关系:

assigned-user(r)={(u,r)∈UA|uUsers,rRoles}

定义7 PA(权限分配):PAPerms×Roles,是权限和角色之间的多对多关系:

assigned-permation(r)={(p,r)∈PA|pPerms,rRoles}

定义8 RH:RHRoles×Roles,是角色集上的一个偏序关系,称为角色等级或角色层次。

定义9 SU:SU,对应一个会话到一个用户的映射。

定义10 SR:SR,对应一个会话到一个角色的映射。

定义11 IT:ITRoleClasses×Roles,实例化是角色类和角色之间的一对多关系。

由于ICRel在控制信息流过程中类和类之间的关系是极为有用的,在模型中的角色类和其他类之间也采用ICRel来描述角色类和其他类之间的安全策略,这样就大大减少了ICRel的数量,更加易于管理。

如定义2,角色类是一个角色的对象化,每个角色类可表示为roleclass=(rname,rpset,rmset),其中rname表示角色类的名称,rpset表示角色类中属性的集合,rmset是该角色类所具有的方法的集合,可能包含不止一个方法。

角色的权限间的关系决定了角色间的关系,角色类是对角色的封装,因此角色类同样具有角色之间的关系。角色间的关系包括四种:角色包含关系、角色相交关系、角色独立关系和角色增广关系。

定义12 (角色包含关系):∀r1,r2∈Roles,如果r1的权限⊆r2的权限,则称r2包含r1。

定义13 (角色相交关系):∀r1,r2∈Roles,如果r1的权限和r2的权限至少有一个相同,则称r1和r2是相交的。

定义14 (角色独立关系):∀r1,r2∈Roles,如果r1的权限和r2的权限没有相同的,则称r1相对于r2是独立的或r2相对于r1是独立的。

定义15 (角色增广关系):∀r1,r2,…,rnRoles,如果∃rn+1,其权限包含所有r1,r2,…,rn的权限,则称rn+1和r1,r2,…,rn是增广关系。

角色类间的继承关系,可以通过面向对象技术中的继承特性来表示。从一个角色类可以派生出新的角色类,并可以规定自己的权限。在某些情况下,子角色类并不希望继承父角色类中所有的权限,因此可以通过在父角色类中设置private权限和public权限,子角色类只能继承父角色类中的public权限,这样的处理充分利用了面向对象的继承特性,也便于角色权限的管理。

3 信息流控制

面向对象系统中,信息流的控制包括直接的信息流控制和间接信息流控制。直接信息流控制是指对一个对象内部以及两个对象之间的信息流的控制;间接信息流控制是指对多个对象之间的信息流的控制。

同文献[10],在模型中引入类属性和类方法的访问控制列表ACLs以及数据源,定义如下:

定义16 类属性ACL:

propACL=(propName,className,RACLpropname,WACLpropname)

其中propName指类属性的名称,className指类的名称,RACLpropname是指允许读propName属性的方法的集合,WACLpropname是指允许写propName属性的方法的集合。

定义17 类方法变量ACL:

mdVarACL=(VarName,mdName,className,RACLpropname,WACLpropname)

其中VarName指方法变量的名称,mdName指方法的名称,className指类的名称,RACLvarname是指允许读varName变量的方法的集合,WACLvarname是指允许写varName变量的方法的集合。

定义18 类方法返回变量ACL:

mdRetVarACL=(mdName,className,RACLmdname,WACLmdname)

其中mdName指方法的名称,className指类的名称,RACLmdname是指允许读方法mdName返回变量的方法的集合,WACLmdname是指允许写方法mdName返回变量的方法的集合。

定义19 数据源:DSOURCEvar,类中的每个变量var对应一个数据源,该数据源是方法的集合,表示该变量的数据是由数据源中的方法写入的,其用来控制写访问。

3.1 直接信息流控制

直接信息流存在于同一个对象内部和两个对象之间,其安全性应该满足以下两个条件:

(1) 访问对象所赋予的角色类中具有访问被访问对象的权限;

(2) 信息流应该满足所涉及变量的ACL的要求。其中涉及两个方面包括RACL和WACL的要求[10]。

假设变量varn+1由变量var1,var2,…,varn在方法md中导出,则变量varn+1的RACL和WACL需要满足以下的要求:

(a) (RACLvar n+1⊆RACLvar 1∩RACLvar 2∩…∩RACLvar n)∩(md∈(RACLvar 1∩RACLvar 2∩…∩RACLvar n))

表示能够对变量varn+1进行读操作的方法必须是能够对var1,var2,…,varn进行读操作的方法。

(b) WACLvar n+1⊇(DSOURCEvar 1∪DSOURCEvar 2∪…∪DSOURCEvar n∪{md})

表示对变量varn+1进行写操作的方法必须包括var1,var2,…,varn的数据源中的方法和方法md

3.2 间接信息流控制

对间接信息流的控制对于控制信息安全传播具有重要的意义。这里采用文献[10]中的定义,其可以避免特洛伊木马。

假设变量var3是由变量var1和变量var2通过方法md所导出,其中var1和var2的ACL分别为{RACLvar1;WACLvar 1}和{RACLvar 2;WACLvar 2},var1和var2的数据源分别为DSOURCEvar 1和DSOURCEvar 2,则⊕定义为:

ACLvar 3=ACLvar 1⊕ACLvar 2

={RACLvar 1∩RACLvar 2;WACLvar 1∪WACLvar 2∪md}

其表示:(1)该操作所生成的变量var3的ACL要求对其进行读操作方法的必须对var1和var2都具有读操作权限,否则不能读取变量var3。(2)对变量var3进行具有写操作权限的方法仅限于对var1或var2具有写操作权限的方法或方法md。因此在进行该操作以后,变量var3的数据源为:

DSOURCEvar 3=DSOURCEvar 1∪DSOURCEvar 2∪md

4 结束语

本文针对面向对象系统进行研究,从信息流的角度研究面向对象系统中的消息传递的可控性问题,提出了面向对象的基于角色的可控模型(OORBC)。本模型建立在文献[10]的基础上,文中分析了原有模型所存在的不足,并通过在模型中添加角色类并描述了角色类的继承关系,有效地减少了面向对象系统中类和类之间的关系,更加便于类和类之间安全策略的描述和管理。最后描述了该模型的信息流控制特征,其能够有效地保障面向对象系统中对象与对象之间消息传递的可控性,防止信息的泄漏。

参考文献

[1]Denning D E.Alattice model of secure information flow[J].Communi-cations of ACM,1976,19(5):236-243.

[2] Sabelfeld A Myersa.Language-based information flow security[J].IEEE J Selected Areas in Communiction,2003,21(1):5-20.

[3] Biba K.Integrity considerations for secure computing systems,Mitre ReportMTR - 3153[R].Bedford: Mitre Corportion,1975.

[4]OsbomS.Mandatory access control and role-based access control revisi-ted[C]//Proceedings of the Second ACM Workshop on Role-BasedAccess Control.1997:31-40.

[5]Nvnchama M,OSBOM S.Modeling mandatory access control in role-based security systems[C]//Database Security IX:Status and Pros-pects.1995:129-144.

[6] Osborn S,Sandhu R S,Munawer Q.Configuring Role-Based Access Control to Enforce Mandatory and Discretionary Access Control Policies[J].ACM Trans on Information and System Security,2000,3(2):85-106.

[7] Tari Z,Chan S W.A role-based access control for Intranet security[J].IEEE Internet Computing,1997(5):24-34.

[8] Izaki K,Tanaka K,Takizama M.Information flow control in role-based model for distributed objects[C]//Proceedings of the 8th International Conference on Parallel and Distributed Systems.2001:363-370.

[9]Zhan C N,Yang C.An object-oriented RBAC model for distributed sys-tem[C]//Proceedings of the Working IEEE/IFIP Conference onSoft-ware Architecture.2001:24-32.

上一篇:林业虫害下一篇:中学政治课改革