基于任务和角色的web访问控制模型

基于任务和角色的web访问控制模型

1hru模型随着网络技术的快速发展和普及，友好的web界面、轻松操作、低价和网络分布等web特性被认为是具有特定魅力的。许多组织正在整合他们的业务并将其整合，以基于web的大规模软件应用系统显示出巨大的潜在价值。例如，电子商务、电子电子商务和基于网络的远程医疗系统等。其中，只有电子商务，在普渡大学的统计下，近年来它已经拥有1万亿美元的市场价值。与此同时，考虑到网络安全问题，确保无线传感器的安全已成为一个紧迫的问题。为了实现无线传感器安全，我们需要从身份认证、访问控制、数据保护、可用性、完整性、抗欺诈等方面进行全面的安全改进。此外，web访问控制的主要目标是基于web应用程序的访问控制，因此我们需要对其进行全面的安全改进，基于web应用程序的访问控制。因此，为了简化描述，本文件中使用了wba访问控制，以显示web访问的控制。访问控制是实现信息安全的一种重要手段.对访问控制技术的研究也一直是国内外信息安全界的一个热点.从20世纪70年代开始,先后提出了Bell-Lapadula模型;HRU模型;Take-Grant模型;Biba模型等众多访问控制模型.1992年Ferraiolo和Kuhn提出了基于角色的访问控制模型(role-basedaccesscontrol,RBAC).这些访问控制模型的共同点在于它们都是从系统的角度出发保护资源.其访问控制的原理可以简单地描述为如果主体对客体有访问请求,而且该主体拥有对该客体的访问权限,那么提供访问操作,否则拒绝该访问请求.它们的弱点在于都没有把操作主体执行操作时所处的环境考虑在内,这样容易造成安全隐患.另外,在这些安全模型中,只要主体拥有对客体的访问权限,主体就可以无数次地使用该权限,而不能对主体所拥有的权限根据所处的环境进行动态管理.它们在进行授权时,将权限提前授予,不符合“最小特权原则”.在WBA中采用上述访问控制模型时,往往显得力不从心,难以实现对用户和权限的动态管理.目前大多数WBA所采用的访问控制机制是基于单个用户的,即每一个用户有一个帐号和与其对应的权限;或者是简单的矩阵式管理.显然这些访问控制机制已经无法满足企业规模不断扩大的需要.即使在WBA中采用RBAC模型,为了实现最小特权原则,提高系统安全性,也需要频繁地切换角色,而且难以随执行的上下文环境实现对权限的动态控制,不能实现对用户行为的时间关联约束,也不能实现控制权安全一致的传递,因此必须探寻行之有效的解决办法.Thomas和Sandhu于1993年提出了基于任务的访问控制(task-basedaccesscontrol,TBAC).TBAC从应用和企业级的角度来考虑和解决安全访问控制问题,而非以往从系统的角度.它面向任务,从任务和任务执行来建立安全模型并实现访问控制,在任务处理的过程中提供动态的权限管理.在TBAC中,主体所拥有的访问权限并不是静态的,而是随着所执行任务的上下文环境发生变化.邓集波等对TBAC模型进行了形式化描述.为了更好地适应企业级或更大型组织对WBA进行访问控制的安全需求,本文把用户对WBA的访问作为角色的任务执行请求(taskexecutingrequest),在WBA服务器端把需要进行访问控制的WBA根据具体的业务流程抽象为多个工作流(workflow),每个工作流由一个或多个任务组成.这样对WBA的访问控制问题就转化为基于任务和角色的访问控制.因此,本文对TBAC模型进行了改进,引入了角色的概念,进而把TBAC和RBAC结合起来,提出了基于任务和角色的双重Web访问控制模型(TRBAC),简化了对用户和访问权限的管理,克服了TBAC模型权限管理复杂的缺点,解决了基于角色的Web访问控制模型不能对用户访问行为实现时间关联约束,不能保证控制权安全一致的传递的问题.并对如何在Web上实现TRBAC模型进行了探讨.本文余下部分组织如下:第2节描述了TRBAC访问控制模型;第3节讨论了如何在Web上实现TRBAC模型;第4节给出了TRBAC访问控制模型在电子政务中的一个应用实例;最后是结论.2trbac模型TRBAC模型基于TBAC模型和RBAC模型.它将角色的概念引入到TBAC模型中,每个角色具有一定的权限,用户通过成为某个角色而获得相应的权限,但TRBAC模型中的角色与RBAC模型中的角色的语义不同.在TRBAC模型中,用户通过成为某个角色而拥有的权限在包含它的元授权步激活该角色之前并不能使用,当元授权步无效时,角色所拥有的权限被冻结.而在RBAC模型中,用户成为某个角色后就能够随时使用该角色所拥有的权限.由于在TRBAC模型中对用户的权限是通过角色和任务来进行分配和管理的,因此TRBAC模型称为双重访问控制模型,它能够满足许多WBA的访问控制要求(如电子政务、电子商务、基于网络的远程医疗等).由于实现了用户与访问权限的逻辑分离,基于角色的策略极大地方便了权限管理,而且对实际应用环境的访问控制需求的描述更自然.例如,如果一个用户的职位或任务发生变化,只要将用户当前的角色去掉,加入代表新的职务或任务的角色即可.研究表明,角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多,并且委派用户到角色并不需要很多技术,可以由行政管理人员来执行,而配置权限到角色的工作比较复杂,需要一定的技术,可以由专门的技术人员来承担.TBAC适用于工作流环境,通过组成工作流的任务来实现对用户权限的动态管理.在工作流环境中,每一步对数据的处理都与以前的处理相关,而且TBAC能够对同一工作流的不同任务实例实行不同的访问控制策略.TRBAC模型结合了RBAC模型和TBAC模型的优点,通过角色实现了用户与访问权限的逻辑分离,消除了用户变化(包括添加新用户、删除已有用户等)对工作流程的影响,有利于工作流程的标准化并增强了可重用性.同时通过任务实现了对访问权限的动态控制,实现了对用户访问行为的时间关联约束,保证了控制权安全一致的传递.2.1基于任务的双重web访问控制模型(1)元授权步(metaauthorizationstep).元授权步是指在一个工作流程中对处理对象的一次处理过程.它是TRBAC所能控制的最小单元.每个元授权步包含一个角色.(2)角色(role).角色是指一个组织或任务中的工作或位置,它代表了一种资格、权利和责任.角色用来实现用户和权限的逻辑隔离,即用户与角色相关联,角色与权限相关联,用户通过成为相应角色而获得相应权限.其中,角色所关联的用户集合称为受托人集(trustee-set),受托人集中的每个用户都可被授予执行元授权步,如图1所示.受托人集的成员被授予元授权步时拥有的访问许可称为角色许可集(rolepermissionsset).当元授权步初始化后,一个来自受托人集中的成员所具有的角色将被激活,并授予元授权步,这个受托人称为元授权步的执行委托者(executor-trustee),该执行委托者在执行元授权步的过程中所需许可的集合称为角色执行许可集(roleexecutor-permissionsset).在TRBAC模型中,一个元授权步的处理可以决定后续元授权步对处理对象的操作许可,这些许可称为激活许可集(enabled-permissionsset).角色执行许可集和激活许可集一起称为元授权步的保护态(protection-state).(3)授权步(authorizationstep).每个授权步由一个或多个元授权步组成,这些元授权步在逻辑上存在依赖关系.授权步分为一般授权步和原子授权步.一般授权步内的元授权步依次执行,原子授权步内部的每个元授权步紧密联系,其中任何一个元授权步失败都会导致整个原子授权步的失败.(4)任务(task).任务是工作流程中的一个逻辑单元.它是一个可区分的动作,可能与多个角色相关,也可能包括几个子任务.授权步是任务在计算机中进行控制的一个实例.任务中的子任务对应于授权步中的元授权步.(5)依赖(dependency).依赖是指元授权步之间或授权步之间的相互关系,包括顺序依赖、失败依赖、失败代理依赖、失败撤消依赖、分权依赖、分级分权代理依赖.依赖反映了基于任务和角色的双重Web访问控制模型的原则.为了节省篇幅,下面以授权步为例简单介绍一下这几种依赖,元授权步之间的依赖关系可类推.顺序依赖:授权步A1完成之后,A2才能被激活.失败依赖:授权步A1失败之后,A2才能被激活.失败代理依赖:授权步A1失败之后,对它的授权由A2代理.失败撤消依赖:授权步A1失败之后,A2的授权被收回.分权依赖:授权步A1和A2必须由不同的用户来完成.分级分权代理依赖:授权步A1和A2必须由不同级别的用户来完成.(6)工作流(workflow).工作流是指组织(如政府部门、企业等)内部各个任务的流动和处理方式,它可以用有向图来表示,图中的每个节点对应一个授权步,而图中的边表示授权步间的依赖关系.一个工作流的完整业务流程可以由多个任务构成.而每一个任务对应于一个授权步,每个授权步由特定的元授权步组成.授权步之间以及元授权步之间通过依赖关系联系在一起.2.2任务与角色的约束与权限TRBAC双重Web访问控制模型形式化描述如下:(1)TRBAC由工作流Wf、授权步As、元授权步mAs、角色R、用户U、许可集P、任务执行请求Ar七部分组成;(2)每个授权步As由一个或多个元授权步mAs组成,即As={mAs1,mAs2,…,mAsn},mAs之间的关系为mAs×mAs⊆2D,D={顺序依赖,失败依赖,分权依赖,分级分权代理依赖,失败代理依赖,失败撤消依赖};(3)每个Wf由一系列As组成,即Wf={As1,As2,…,Asn},As之间的关系为As×As⊆2D,D={顺序依赖,失败依赖,分权依赖,分级分权代理依赖,失败代理依赖,失败撤消依赖};工作流可以表示为有向图Wf=(As,E),其中As是节点,边E表示As之间的依赖关系;(4)UA⊆U×R,UA是用户到角色的多对多的关系;(5)As与R是1∶n关系,As→R是从授权步到一个角色的映射,随时间变化而变化.U→R是从U={U1,U2,…,Un}选择一个执行委托者扮演角色的函数.(6)As与P是1∶n关系,Initial(As,R)→P,P={p1,p2,…,pn}为许可集,Initial为角色执行许可集的激活函数;Revoke(As,R,P1)→P2,P1⊆2P,P2=P-P1,Revoke为权限回收函数.在TRBAC双重Web访问控制模型中,授权用五元组(R,O,P,L,mAs)来表示.其中,R表示角色;O表示客体(指需要进行访问控制的对象);P表示权限;L表示元授权步mAs的存活期限.P是元授权步mAs所激活的权限.在元授权步mAs被触发之前,它的保护态是无效的,其中包含的权限不可使用.当元授权步mAs被触发时,与其对应的角色所拥有的许可集中的权限被激活,同时它的存活期开始倒记时,在元授权步存活期间,五元组(R,O,P,L,mAs)有效.当生命期终止,即元授权步mAs无效时,五元组(R,O,P,L,mAs)无效,角色所拥有的权限被禁止.在TRBAC双重Web访问控制模型中,访问控制策略包含在As-As,mAs-mAs,As-R,U-R,As-P关系中.As-As和mAs-mAs的关系决定了一个工作流的执行过程,As-R,U-R和As-P组合决定了一个授权步的运行.它们的关系由WBA的系统管理员根据需要保护的WBA应用的具体业务流程和系统访问控制策略进行直接管理.通过基于任务和角色的动态权限管理,TRBAC双重Web访问控制模型支持两个著名的安全控制原则:①最小特权原则.在执行任务时只给用户完成该任务所需的权限,未执行任务或任务终止后用户不再拥有所分配的权限;而且在执行任务过程中,当某一权限不再使用时,授权步自动将该权限回收.②职责分离原则.某些情况下,一些敏感的任务需要不同的用户执行.如支票处理流程中申请支票和批准支票的职员必须不同,这可通过授权步或元授权步之间的分权依赖及角色之间的互斥实现.TRBAC模型通过角色实现了用户与访问权限的逻辑分离,简化了TBAC模型中对用户及权限的管理,消除了用户的变化对工作流程的影响;同时通过任务实现了对访问权限的动态控制,解决了基于角色的Web访问控制模型不能对用户访问行为实现时间关联约束,不能保证控制权安全一致的传递的问题.3web访问控制策略在实现TRBAC双重Web访问控制模型时,我们采用了与文献相同的安全cookies机制.这主要是出于以下几个原因:(1)在现有的Web浏览器和Web服务器中已经广泛采用了cookies技术保持Web状态信息.对其进行安全增强比较直接,代价较小;(2)HTTP协议是一个无状态的协议,cookies技术能够适应这种情况;(3)更主要的是因为TRBAC的Web访问控制与RBAC的Web访问控制的主要差别是在Web服务器端对通过认证的角色采用了不同的访问控制策略;而客户端尽管角色的含义在两个访问控制模型中不同,但是在安全cookies的构成和表达形式是一样的.因此,我们希望通过采用类似的实现机制,来说明TRBAC的双重Web访问控制模型在实际应用中实现的代价和难度也并不比RBAC的Web访问控制模型大,具有更好的实用价值.3.1k健全的充放电技术cookies是一种为Web所广泛采用的技术,它主要用于保持Web状态的连续性,在cookies中包含关于用户信息的字符串.当用户通过浏览器访问一个使用cookies的Web站点时,含有用户相关信息的cookies就会被送到用户的内存中.当浏览器关闭之后这些信息就会被存到用户的硬盘中去.此后,如果该用户再次访问这个Web站点时,Web服务器就可以从用户硬盘里存放cookies内容的文件中读取相应cookies中的内容.一般利用cookies最常见的目的是获取相关信息,使得在后续的浏览器与Web服务器的通信中不用再重复询问前面相同的问题.但是有一点必须注意,就是常规的cookies是以明文的形式存放并在网上传送的,这是很不安全的.3.2安全检测机制常规cookies没有考虑安全问题,必须对它们进行安全改造,使它们变成安全cookies,这些改造后的cookies必须提供身份认证、完整性和保密性服务.身份认证服务用于证实cookies拥有者的身份;完整性服务用于保护cookies免受非授权用户的篡改;保密性服务用于防止信息的泄漏.实际应用中到底使用哪种cookies以及其内容的确定要根据具体的使用环境而定.但是,不管是哪种应用,至少要有一个认证cookies以及一个提供完整性服务的cookies,因为只有这样才能构成基本的安全服务.图2是用于对Web实现TRBAC访问控制的一组安全cookies,它们形式上与文献中的安全cookies相同.其中NameCookie包含用户名.RoleCookie包含用户的角色信息.需要说明的是,尽管RoleCookie的内容在我们提出的TRBAC的双重Web访问控制模型和文献提出的RBAC的Web访问控制模型中是一样的,但是它的语义在两个模型中是完全不同的,本文中提到的角色在包含它的元授权步激活之前是无效的,角色不是实现访问控制的主体,而是通过包含角色的元授权步达到访问控制的目的.而文献中,用户一旦获得某个角色就能够任意使用角色所拥有的权限,角色是访问控制的主体.LifeCookie的CookieValue字段用于存放此安全cookies集的寿命信息,它使得WBA服务器可以对安全cookies集的生命期进行检验.为了保护这些cookies免受可能的攻击,我们使用IPCookie,PswdCookie和SealCookie来提供身份认证、完整性和保密性服务.IPCookie含有用户机器的IP地址,PswdCookie包含用户的已加密的口令.身份认证服务由IPCookie和PswdCookie实现,Web服务器通过比较cookies中的认证信息与那些来自用户的认证信息(IP地址和用户口令)来完成对用户的认证.保密性服务用于保护cookies内容,以免其泄漏给非授权实体.在我们的实现中,使用了IPCookie和PswdCookie.SealCookie包含用户-角色服务器对所发布的安全cookies集的数字签名,支持完整性服务,用于保护cookies的内容免受非授权的篡改.在具体的实现中,我们使用了由PGP包提供的基于公钥的安全解决方案,实现对安全cookies的加密.3.3web访问控制图3是在Web上实现TRBAC访问控制的示意图.以政府机构为例,根据政府组织结构和工作流程,可以把它的Web应用服务器上所提供的需要进行访问控制的多个WBA组织成多个工作流.根据部门设置,可以把一个部门作为一个域,每个域设置一个用户-角色服务器.用户-角色服务器中存放着所在域的用户角色信息.只有成功地通过对用户身份的认证,用户才能够收到从用户-角色服务器返回的为其分配的角色信息(也就是前面所提到的6个安全cookies).此后,当用户通过浏览器访问Web服务器时,Web服务器通过安全cookies来验证用户,并根据用户所希望访问的工作流状态来决定是否允许用户根据其角色来执行交互.需要再次强调的是,图3中的角色和文献中的角色在语义上是不同的(见第3.2节的解释).在TRBAC双重Web访问控制系统的具体实现细节上,与文献的主要区别在WBA服务器端.首先,在WBA服务器取出roles后实行的是TRBAC,而不是RBAC.其次,对于WBA服务器上需要进行访问控制的WBA,在本文中引入了工作流的概念,对其进行整体刻画,并对任务进行组织,而任务则用来实现对权限和用户的动态访问控制.而在RBACWeb访问控制模型中只是考虑了资源保护问题.因此我们下面只是简单描述一下如何在Web上实现TRBAC,安全cookies的详细创建和验证过程本文不再赘述,具体内容可以参考文献.假设科员ZhangSan希望访问本单位WBA服务器上的某个WBA.在访问开始时,她首先与她所在部门(此处假定域是按部门划分的,每个部门一个域)的用户-角色服务器连接,进行认证,当用户-角色服务器对其完成认证(获取并验证用户名/口令)之后,它从用户-角色分配表中找到ZhangSan这个用户所对应的角色,同时创建一组安全cookies:NameCookie,LifeCookie,RoleCookies,IPCookie,PswdCookie以及SealCookie.然后,这些安全cookies被送到ZhangSan的硬盘中并被保存下来.这样只要这些cookies没有过期,ZhangSan就不必再回到用户-角色服务器去获取其角色分配信息.当ZhangSan通过其浏览器要求访问一个支持TRBAC的WBA服务器时,浏览器自动发送相应的安全cookies到WBA服务器:NameCookie,LifeCookie,RoleCookies,IPCookie,PswdCookie和SealCookie.IPCookie含有用户计算机的IP地址,PswdCookie包含用户的已加密的口令.WBA服务器通过把IPCookie和PswdCookie中的IP地址和口令与直接来自用户的数据进行比较,从而完成对cookies属主的认证(用户-角色服务器用WBA服务器的公钥来加密用户的口令并保存在PswdCookie中,WBA服务器用自己的私钥解密PswdCookie中的加密的用户口令,并与直接获得的用户名/口令对中的口令相比较,如果两者一致,那么完成对cookies属主的认证).最后WBA服务器通过使用用户-角色服务器的公钥验证用户-角色服务器在SealCookie中的签名,从而完成对cookies完整性的检查.如果所有的cookies顺利通过验证,则WBA服务器相信RoleCookie中信息的真实性,然后利用这些信息以及用户所希望访问的工作流的状态来完成对用户的TRBAC双重Web访问控制.4对用户和权限的动态访问控制下面以我们所实现的一个电子政务系统为例,说明TRBAC双重Web访问控制模型在实际中的应用.该电子政务系统的公文流转子系统分为办文和发文,公文流转分阶段进行,按处室划分阶段.对应各阶段,公文流转中涉及到的办公人员分为收文人员、拟办人员、主办人员、协办人员、领导.收文人员的主要职能:对来文进行签收,填写收文登记簿.拟办人员的主要职能:填写拟办意见,催办,将办理好的公文及处理结果归档.主办人员的主要职能:办理公文,根据本处室、协办处室的意见以及领导的批示填写处理意见,催办.协办人员的主要职能:协助办理,提出意见.领导的主要职能:填写批示.由于政府部门工作性质的特殊性,政府公文流转系统涉及重要公文的流转,公文(收文,发文)流转过程比较复杂.而且,对系统数据安全、用户权限控制等信息安全问题都有严格要求.自主访问控制和强制访问控制方法都是由主体和访问权限直接发生关系,根据主体/客体的所属关系或主体/客体的安全级来决定主体是否拥有对客体的访问权.由于政府办公的特殊性,对公文访问的权限是动态变化的,用这两种传统的访问控制在复杂的公文流转系统中进行安全管理变得非常困难.基于角色访问控制引入角色这个中介,安全管理人员根据需要定义各种角色,并设置合适的访问权限,而用户根据其职责被指派为不同的角色.由于实现了用户与访问权限的逻辑分离,基于角色的策略极大地方便了权限管理.但是,在政府公文流转中,对一个具体公文的访问权限常常是动态产生的.比如公文在主控处室拟办之前,主办处室不能办理该公文,显然仅仅采用基于角色的访问控制并不能完全满足政府公文流转系统的访问控制需求.因此,我们在设计电子政务系统的公文流转子系统时采用了TRBAC双重Web访问控制模型,它有效地解决了上述问题,实现了安全管理,并在实际应用中已取得了满意的效果.方案如下(出于描述方便的考虑,我们对该系统的一些细节做了简化):整个公文流转系统由一台Web服务器、多个用户-角色服务器和多个客户端计算机组成.根据各个职能部门之间在公文处理流程上的先后顺序和制约关系,用授权步/元授权步之间的依赖关系来协调和控制各种公文在各相关部门的流动和处理.在每个职能部门设置一台用户-角色服务器,并配置一台计算机作为客户端.在用户-角色服务器上记录在本部门工作人员的角色信息,并对用户进行角色认证,对通过认证的用户提供相应的安全cookies.当用户从客户端的浏览器访问Web服务器进行公文处理时,Web服务器对从客户端发送过来的安全cookies进行属主认证和完整性检查,对通过检查的访问请求根据各个WBA的具体工作流程进