时间：2015-12-20 22:11:41 所属分类：信息安全 浏览量:
引言 随着IT技术的飞速发展,人们对于高性能计算和大数据存储的需求日益彰显,云计算作为共享IT资源的一种方式,能够满足人们日益增长的需求. 根据NIST的定义,云计算包含IaaS,PaaS和SaaS 3层服务模式.在3层服务模式中,IaaS层通过虚拟化抽象整合硬件资源,对外提
引言
随着IT技术的飞速发展,人们对于高性能计算和大数据存储的需求日益彰显,云计算作为共享IT资源的一种方式,能够满足人们日益增长的需求.
根据NIST的定义,云计算包含IaaS,PaaS和SaaS 3层服务模式.在3层服务模式中,IaaS层通过虚拟化抽象整合硬件资源,对外提供虚拟资源池服务,服务屏蔽了底层硬件的细节和差异,使得虚拟化资源能够以基础设施即服务的方式被用户管理和使用.因此,IaaS层是整个云计算体系结构的基础,其安全性也决定着云计算体系的安全.
目前,CSA(cloud security alliance)组织针对云安全事故的相关研究表明,当前的IaaS环境存在复杂的资源共享架构,但缺少出于安全性考虑的设计,无法提供强有力的资源保护手段,从而导致资源管理上的漏洞.为了解决这些问题,目前的研究围绕着资源的访问控制展开,旨在通过规定主体对客体的访问限制,保证组件间交互资源不被非法访问.但是,由于IaaS层环境存在海量的组件交互协议和交互接口,这些协议和接口既面向普通租户,也面向内部组件,租户与组件之间产生大量的访问请求,访问请求频繁且复杂,导致传统的访问控制策略在应用于云计算IaaS层时出现一些新的安全问题.
首先,传统的访问控制是静态的,在确定主体对客体的访问权限时,没有考虑系统所处的当前环境.当主体拥有对客体的访问权限时,主体就可以无数次地使用该权限.而在多任务并发的IaaS云环境下,服务内部的各种组件参与出现了很多的不确定性,组件角色不断变化,组件部署的任务类型也不断变化,这些情况下确定组件访问权限是需要考虑系统当前环境的.
其次,传统的访问控制模型在应用于IaaS云计算时,存在无法满足最小授权的问题,最小授权原则是设计容错系统的一个重要原则.在IaaS云计算平台中,用户提交的任务往往只需要访问有限的底层资源,但却拥有访问该服务所关联的所有资源的权限,这样就导致攻击者可以利用上层应用攻击底层系统平台,从而导致系统安全无法保证.
针对传统访问控制在以上两方面的不足,本文结合云环境IaaS层结构,从动态配置主客体安全属性和细化授权对象范围角度出发,将传统基于任务和角色的访问控制模型作进一步改进和扩展,以服务接口为授权节点,通过引入组件访问消息传递机制和组件访问控制中间件,实现基于服务实例的工作流模型分解和基于服务授权历史的动态角色激活,再依据分解后的任务节点与激活后的临时角色代理在服务内的实体约束关系作进一步的算法合成,构造最小授权单元,最终实现满足动态授权和最小授权的云计算IaaS层访问控制策略.
1 相关研究
访问控制作为一种有效控制系统资源流向的策略手段,能够通过对访问主体身份及其所属的预先定义的策略来限制其使用资源的能力,有效保证资源的保密性、完整性、可用性和合法使用性,是对系统不同角色访问行为进行安全隔离、限制安全风险的关键策略之一.关于传统访问控制在解决动态授权和最小授权问题的国内外研究中,文献[7]提出了一种基于工作流状态的动态访问控制,同时还给出了工作流的Petri网描述,并在此基础上证明了采用这种动态访问控制机制可以降低资源访问越界的危险性;文献[8]提出了一种面向服务的角色访问控制技术,通过引入服务和授权迁移的概念,对实际任务和服务状态进行管理,有效加强对用户角色权限的控制.
上述访问控制模型都通过工作流形式化描述,对访问控制中的授权实体作相应的理论分析,为解决访问控制中动态授权问题和最小授权问题提供有效的解决方案.但这些控制策略不是针对云计算IaaS作模型设计,其交互实体的约束规则并不完全适用于云环境.云环境下的访问控制研究方面,文献[9]借鉴了Linux安全控制模块SELinux提出了访问控制即服务(ACaaS)模型,将云计算访问控制外包给ACaaS层,提出一种可热插拔的云计算访问控制中间件模型.
文献[10]提出了基于使用控制(usage control,UCON)授权模型的访问控制架构,该架构将信任评估的方法引入UCON的授权机制中,提高了使用访问控制模型的灵活性和安全性;文献[11]提出面向组件交互实体的服务可信协商及访问控制策略,通过信任规则表达访问实体的可信程度,构建服务级别协议.文献[12]提出了基于任务和角色的云计算访问控制模型,通过整合RBAC模型和TBAC模型的优点,将“任务”和“角色”作为访问控制的基本要素,采用了以任务为中心的“用户-角色-任务-权限”的四级访问控制结构.上述文献中,文献[9]和[10]通过构造独立的访问控制模块,有效加强了资源访问控制的灵活性和动态性.文献[11]和[12]通过明确组件交互约束规则,细化授权对象范围,有效保证了访问控制最小授权原则.
以上研究虽然针对当前云计算访问资源的合法使用性提出了一系列的访问控制策略方法,但是这些方法仍存在云计算环境下工作流控制节点划分,组件角色信任度计算与组件授权管理复杂等问题.而解决这些问题是实现访问控制动态性和授权粒度最小性的根本落脚点.因此,将IaaS模块组件对外数据和方法的简单封装定义为组件服务,本文提出了一种基于任务和角色面向服务的访问控制策略(task and role-based service-oriented acecess control,TRSAC),该策略结合上述访问控制策略的优点,通过构造以服务为中心的任务-角色-服务三级访问控制结构,建立彼此约束关系,达到访问控制的目的.
2 TRSAC策略描述 传统的TRBAC访问控制模型中,访问权限被定义为任务和角色的映射关系,而在TRSAC模型中表现为面向服务接口的任务节点和角色执行代理的映射关系.
定义1 TRSAC={(WF,Task),(Role,Ac-tor),(Service,App)}.
定义1描述TRSAC的组成,它由基于任务层面,基于角色层面和面向服务集三部分组成.
定义1中的符号及下文引用的符号定义如表1.【表1】
系统动态激活角色时,相应地创建临时执行代理,执行代理所获得的权限由工作流分解的任务节点和服务接口的匹配关系决定.
任务执行时只给当前执行代理分配所需要的权限,当权限不再使用时,执行代理将被释放,权限将被动态收回;服务实例在虚拟机平台根据角色执行代理的访问权限和任务需求动态调用应用系统的服务方法,申请系统物理资源,服务完成以后,资源将被回收.其访问控制过程中产生约束关系如图1所示.【图1】
由上述访问控制实体约束关系可知,如何构造以服务为中心的任务-角色-服务3层访问控制结构是实现TRSAC策略的核心.
本文将从基于服务实例的工作流模型分解和基于服务授权历史的动态角色激活,以及分解后的任务节点与激活后的临时角色代理在服务内的实体约束关系三方面作访问控制策略描述,并在此基础上对策略方法做形式化证明.最终实现满足动态授权和最小授权的云IaaS层访问控制.
2.1 基于服务实例的工作流任务分解 首先根据文献[中对IaaS云环境以及构成云组件的形式化描述,分析组件间服务依赖关系,然后根据依赖关系对工作流进行模型分解,最终形成服务 接 口 与 任 务 节 点 映 射 关 系fmap:Task→2SERVICES.其服务间依赖关系描述如下:
1)并发依赖Task1,Task2,WF(Task1)WF(Task2),当Task1和Task2同时进入激活状态,则Task1和Task2对应的服务间存在并发依赖关系.
2)顺序依赖Task1,Task2,WF(Task1)≤ WF(Task2),当Task2必须在Task1已经完成后才能进入激活状态,则Task1和Task2间对应的服务间存在顺序依赖关系.
3)失败依赖Task1,Task2, WF(Task1)→ WF(Task2),当Task1失败后才能触发Task2,则Task1和Task2对应的服务间存在失败依赖关系.
4)互斥依赖Task1,Task2,WF(Task1)→ WF(Task2),Task1和Task2不能 同时被激 活 时,则Task1和Task2对应的服务间存在互斥依赖关系.
根据上述依赖关系以及文献提出的分解算法,本文对云IaaS环境工作流作如下形式化分解,我们假定无环工作流网具有完备性,首先根据云环境工作流的形式化描述得到其基本回路;然后对基本回路,仅保留除回滚和并发之外的所有变迁动作,得到一个变迁链,每次变迁动作对应工作流中的一次任务执行;对于每个变迁链中的任务节点,根据相应的算法得到并发变迁的兄弟节点,将并发变迁的兄弟节点与其变迁链中涉及的变迁动作合并,生成一个并发变迁链;最后得到的工作流分解树即为若干并发变迁链的集合,其对应一个服务实例路由(图2).【图2】
在图2中,工作流分解为服务实例的集合WF={BI(i)|1≤i≤n}.其中,BI(i)是服务实例的并发任务步集合BI(i)={PTS(i,j)|1≤j≤mi},mi为服务实例BI(i)的步数,PTS(i,j)为服务实例BI(i)第j步并发执行的所有任务的集合PTS(i,j)={tijp|1≤p≤sij},sij为PTS(i,j)中并发执行的任务数.设表示BI(i)中任务步并发执行的先后关系,显然〈BI(i),〉为一个拟序集〈PTS(i,j),PTS(i,k)〉∈,记为PTS i,( j) PTS i,( )k,表示PTS(i,j)在PTS(i,k)前执行.服务实例路由之间的节点通过组件消息传递机制进行动作变迁,访问控制模块通过hook函数对组件间的消息传递进行截获,并依据角色权限做相应的访问控制决策,从而达到访问控制的目的.
2.2 基于服务授权历史的动态角色激活
传统基于任务和角色访问控制将组件角色同访问权限联系起来,对访问组件赋予相应角色的权力,组件所能访问的资源权限就是该组件所拥有的角色权限集合的并集.每个角色代表了一个独立的访问权限的实体,它们之间可以有继承、限制等关系.但是这种权限的集合是预先定义的,无法满足动态环境的安全需求.
本文在传统任务和角色的访问控制模型的基础上,通过引入组件访问控制中间件,构造多级安全动态角色激活机制.针对服务接口和任务节点的映射关系,通过增加相应的转换和管理模块,对系统访问控制中的主体角色进行有效控制.中间件包括信任度管理模块和授权模块.信任度管理模块首先基于文献的信任度评估算法计算当前实体信任度,并将它存储在安全管理数据库中;然后结合服务授权历史记录,提取信任样本,作假设检验分析,获取当前信任值的合理程度.
最后由授权模块根据被评价实体的信任值,结合交互上下文即服务实例路由作权限仲裁,动态激活相应角色,创建角色执行代理.
根据仲裁结果,本文将访问组件角色分为以下3类:
1)拒绝类角色:访问客体拒绝被访问,角色级别可被继承,适合被动访问模式.
2)监管类角色:访问客体可通过主体内部方法间接访问,角色级别不可被继承,适合被动访问模式.
3)批准类角色:访问客体允许被直接访问,角色级别不可被继承,适合主动访问模式.
设有主体S和客体O,交互上下文Context={0,1},0表示无关,1表示有关,主体的信任度为Level(),客体资源的安全访问控制域为Type().
若Level(s)∈Type(o),则定义客体角色为批准类角色;若Level(s)Type(o),且Context=1,则定义客体角色为监管类角色;若Level(s)Type(o),且Context=0,则定义客体角色为拒绝类角色;访问主体角色通过动态激活中间件进行实时的角色授权,划分角色安全等级,配置当前任务节点的安全属性,从而实现访问控制的时态特性.
2.3 TRSAC服务实体关系描述 在TRSAC模型中,组件的访问控制由任务节点和角色执行代理决定,而任务节点和角色执行代理又由服务的安全访问控制域决定,因此对组件的访问控制最终要分解为对服务的访问控制.
本节我们将从面向服务的角度出发,对参与服务的访问控制实体进行状态分析和约束分析.先根据服务实例得到粗粒度的基本授权单元,然后根据安全上下文约束规则作进一步行为约减,最后根据控制策略的合成算法得到面向服务组件的最小授权单元.
2.3.1 基本授权单元描述方法 系统的有效状态空间StatusSpacet是贯彻于控制模型逐个实体及其间有效关系之上的一个多元关系:StatusSpacet SERVICES× WF× VMS×ROLES×TASKS×APPS×ACTORS.定义2有效状态空间内系统动态创建产生的实例集合r:r={rs,rwf,rvm,rr,rt,rap,rac}∈Status-Spacet定义3基本授权服务函数fParticipants:VMS×APPS→2SERVICES,其中2SERVICES是SERVICES的幂集.fParticipants(vm,ap)={s|r.rs=s,r.rvm=vm,r.rap=ap,forr∈StatusSpacet}.fpaticipants(vm,ap)计算结果ParticipatesIn为所有服务于vm管理下的应用系统ap的服务实体集合.定义4 Dependencies表示两个服务间的依赖关系,两者参与了同一虚拟机上的应用系统.即:s1,s2,s1≠s2,Dependencies(s1,s2) vm,ap,s1∈fPaticipants(vm,ap)∧s2∈fPaticipants(vm,ap).
性质1 1,2若Dependencies(s1,s2)成立,则s1,s2所属授权组件共同参与同一虚拟机vm,并且s1,s2同服务于该vm管理下同一任务节点Task.该性质表明如果两个服务相互间存在依赖关系,则它们各自所属的授权组件同时参与了某个虚拟资源,建立了彼此信任关系,并且两者处于彼此的应用上下文.基本授权单元保证存在协作关系的服务组件间能够进行交互.根据以上定义和性质的描述,本文将一个服务s的粗粒度基本授权单元,即可与s交互的服务集合描述为AuthUnit(s)={s′|s′∈SERVICES,De-pendencies(s,s′)}.
2.3.2 安全上下文约束规则 在TRSAC模型中,组件交互被看作是双方平等地服务于应用系统,它们各自所具有的安全属性应同时被作为访问决策的依据.
本文引入“安全上下文”(TaskContext)概念描述服务在应用系统内的关联状态,包括其参与系统的任务节点以及连接到该任务节点上时所具有的角色权限,其表现为图2中基于角色激活的服务实例路由的可达性:TaskContextTASKS×ROLES 通过安全上下文所表达的安全属性,制定相应的访问控制约束规则.该规则将服务实例与分解后的任务节点和激活后的角色执行代理相关联,根据当前环境的上下文匹对计算结果,作访问控制决策.
规则1 TCMatch对交互的双方属性考察的安全策略表达为安全上下文匹配关系集合,即对应的相容TaskContext匹配对:TCMatchSERVIC-ES×(TaskContext)2.
规则2安全上下文匹对函数定义为:fMatchTC:SERVICES× TASKS× ROLES→2ROLES×TASKS,根据TCMatcht计算与某个TaskCon-text相容TaskContext集 合.fMatchTC(s,(t,r))={(t′,r′)|TCMatcht(s,(t,r),(t′,r′))∨TCMatch(s,(t′,r′),(t,r))}.
规则3一个服务在某一虚拟机内应用系统的上下文可通过计算fTaskContext:SERVICES×VM×APPS→2TASKS×ROLES即fTaskContext(s,vm,ap)={(t,r)|(s,vm,r,t,ap)∈StatusSpacet}.
2.3.3 TRSAC访问控制策略算法描述 在基本授权单元的基础上,将安全上下文约束规则引入授权模型中,在某一个应用系统虚拟机vm内,服务s可交互组件安全控制域Authset(s,vm)可通过以下算法计算获得:【表】
因此,工作流中总授权服务集合为:Auth(s)= ∪vm∈VMSAuthSet(s,vm) 2.4 TRSAC策略方法安全性分析及证明 本文提出的TRSAC策略通过任务节点和角色代理在服务实体内的关系描述,以基本授权单元为基础作安全上下文约束分析,求解授权服务集合,实现 对 服 务 的 访 问 控 制.
为 验 证 本 文 所 提 出 的TRSAC策略满足最小授权原则和动态授权原则,给出如下定理,并予以证明.定理1有效空间内,s1和s2可交互的必要条件是(vm,a)∈ParticipatesIn,使得fTaskContext(s1,vm,a)∩fTaskContext(s2,vm,a)≠.证假设r1,r2∈ROLES,t1,t2∈TASKS,{(task2,role2)}∩fMatchTC(a,(task1,role1))=,a∈APPS,task1,task2∈TASKS,即在服务实例中无法找到(task2,role2)的上下文,则TCMatch在应用系统a中task1,task2所连接的服务之间不存在交互,产生矛盾,定理1得证.定理2在 有 效 状 态 空 间StatusSpacet内,s1,s2,s1∈AuthSet(s2)s2∈AuthSet(s1).证当s1∈AuthSet(s2,vm),由fParticipants定义知,ap∈APPS使得可以根据算法找到上 下文TContext1和TContext2分别满足条件TContext1∈fTaskContext(s1,vm,ap)以及TContext2∈fTaskContext(s2,vm,ap),且(s1,TContext1,TContext2)∈TC-Matcht,由fParticipants(s1,vm,a)≠,存在(s1,vm,r,t,ap)∈StatusSpacet成立,再将参数(s1,vm,r,t,ap)带入算法中,可得s2∈AuthSet(s1,vm),同理可得当s2∈AuthSet(s1)时,可得s1∈AuthSet(s2),证毕.
定理1说明在有效空间内可通过安全上下文匹配构造组件安全交互约束方法,保证组件交互对象的惟一性和动态变更性.组件作为访问控制的客体,授权操作会根据安全上下文变化不断更新,保证权限只在对象生命周期内有效,访问过程完成后动态收回访问权限,进而保证主体的动态授权原则.
定理2说明交互组件双方实施的访问控制不会出现重复和矛盾,保证总授权集合满足最小性,从而使得参与服务的交互实体满足最小授权原则.
至此,本文从理论角度对TRSAC策略进行了安全性分析,分析结果表明,基于任务和角色面向服务的访问控制模型满足动态授权原则和最小授权原则,进而解决了前文所提出的问题.下一步本文将从实验角度出发,旨在证明TRSAC在运用于云计算IaaS环境时,能够有效实现满足最小授权和动态授权的访问控制策略,并且该策略对云基础设施服务不会产生性能上的影响.
3 TRSAC策略方法实现 3.1 TRSAC整体框架 本文在现有云计算IaaS层结构模型的基础上拓展访问控制模块,如图3所示,服务接口模块存在于IaaS层的服务层中,策略管理模块存在于服务构造层中,权限仲裁模块存在于虚拟资源层中,而安全控制模块存在于对资源进行抽象的虚拟化平台中.
这样的设计即保证了对底层资源的安全控制,也保证了IaaS云计算体系的完整性和层次性.图3中服务层通过调用组件接口,申请物理资源;资源访问过程通过权限仲裁结果动态配置安全属性;资源调度层通过层中对资源调用的权限判定,控制虚拟机之间对资源的访问。【图3】
3.2 TRSAC访问控制模块设计 根据以上关于TRSAC模型的描述,本文设计的访问控制模块主要分为3类:①策略管理类模块(strategy management);②权限仲裁类模块(per-mission arbitration);③安全控制类模块(securitycontrol).
1)策略管理模块(SM)主要接收上层接口对策略的操作,将TRSAC中的算法计算结 果转化为XML格式存储.并将相应访问控制权限评测信息装载到资源调度模块中.
2)权限仲裁模块(PA)主要通过信任度算法计算访问实体的信任度,作假设检验分析,动态授权,再通过安全上下文判断授权实体的权限信息.
3)安全控制模块(SC)嵌入到资源调度层中执行访问控制策略,通过hook函数拦截系统的资源调度并作访问控制判断,主要是4种hook函数:①资源调度方面的hook函数;②虚拟机绑定上的hook函数;③服务 实例管 理 方 面 的hook函 数;④获取权限仲裁信息方面的hook函数.
策略管理模块向上提供配置访问控制策略的管理控制接口;权限仲裁模块通过评估授权实体角色权限与最小授权单元作访问控制仲裁;安全控制模块向下提供底层资源安全属性配置信息,实现访问控制.其模块实现流程如图4所示.【图4】
3.3 TRSAC方法实现流程 根 据 访 问 控 制 模 块 的 设 计,本 文 提 出 的TRSAC访问控制实现流程如图5所示.【图5】
实现过程:①工作流分解,通过前面提出的算法实现基于服务实例的工作流分解;②服务接口调用,形成服务接口与任务节点的映射关系;③资源调度,根据任务需求申请底层资源;④分配虚拟资源,根据信任度计算匹配相应的角色权限;⑤任务与虚拟机绑定,通过TRSAC合成算法,构造虚拟机资源的最小授权单元,实现资源访问控制.
4 实验与结果分析
4.1实验工具介绍
为了更好的说明提出策略的有效性,本文采用了云计算的仿真工具CloudSim进行试验.CloudSim支持大型云计算基础设施的建模与仿真,是一个自足的支持数据中心、服务代理、资源调度、分配和控制策略的平台.CloudSim是开源的,各服务模块均以类的方式对外封装,其设计思想与本文所提出的面向服务组件的思想相契合.实验可在Windows上运行,用户可以根据自己的研究内容进行扩展,加入自己的代码.
依据CloudSim源代码,有几个核心类:
1)Cloudlet类:构建云环境任务;2)DataCenterBroker类:虚拟机的管理,如创建、任务提交、虚拟机的销毁等;3)VirtualMachine类:虚拟机类,运行在host上,与其他虚拟机共享资源,每台虚拟机由一个拥有者所有,可提交任务并由VMScheduler类定制该虚拟机的调度策略;4)VMScheduler类:虚拟机的调度策略用来管理执行任务,实现了任务接口.
基于以上描述,本文实验采用云计算仿真工具CloudSim3.0.2,并在Myeclipse8.5上进行编译和发布.
4.2 实验应用场景设计
基于TRSAC访 问 控 制 模 块 设 计,本 文 对Cloudsim类进行扩展,增加类AccessControl来实现安全控制功能,增加类AccessPolice来实现策略管理功能,增加类listlable实现权限仲裁功能,重写了DataCenterBroker类 中 提 供 的bindCloudlet-ToVm方法,将任务捆绑到指定的虚拟机上运行,重写了VmAllocationPolicySimple类 中 的allocate-HostForVm函数,增加调用资源调度hook函数,实现访问权限判断.
增加AccessControl类中的Role-Allocation函数模拟安全属性配置,属性值存储在lable.xml中,并用listlable进行管理;实验通过服务内资源属性的评测,实现资源的访问控制.实验的应用场景为:虚拟机个数固定在100个,工作流长度在500~4 500 MI(million of instruc-tions)之间随机产生.
任务节点总数控制在0~100之间,模拟云存储资源访问控制,实验模拟的仲裁模块组件信任度样本值如表2所示.【表2】
4.3 有效性分析
基于上述应用场景的设计和TRSAC访问控制实现流程,本文进行有效性分析,目标是验证访问控制策略中角色信任度计算策略的有效性和验证构造服务最小授权单元方法的有效性,其效果分别如图6和图7所示.
图6是本文基于服务授权历史的动态角色激活策略的具体实现,实验首先提取服务授权历史的信任样本,然后结合当前实体的信任度,作假设检验分析,再根据分 析结果判 断组件安 全属性.以图中(U2,S0)信任值为例,将该信任值放到信任样本(表2)中作t假设检验,经过计算,该值处于t检验的拒绝域中,故被淘汰.实验结果表明,该策略在解决交互组件角色授权方面具有有效性.
图7是本文TRSAC算法构造服务最小授权单元的具体实现,实验模拟信任值为0.697 8的云存储资源请求服务,实验中访问控制实现过程:首先调用Cloudsim服务接口类函数,实现任务与服务映射关系,再通过Cloudsim仲裁模块判断信任值为0.697 8的任务安全属性,最后在服务内通过安全属性与任务需求构造的安全上下文求解云存储资源请求的最小授权单元.
实验结果表明,在100个虚拟机绑定任务中根据算法计算求解最小授权单元后,只有10个资源请求成功,满足了最小授权原则,证明了该策略能有效保证资源访问有效实体在最小范围内进行. 4.4 性能分析
性能开销是一个很重要的评价参数,如果保护方案性能开销过大,系统运行会受到严重的干扰.因此,将对访问控制的整体机制作性能分析和评价.性能指标是仿真云平台的总运行时间.
通过与未采用TRSAC访问控制的仿真云平台进行比较,得出性能分析结果.基于设计的应用场景,通过累计记载10次总运行时间,在相同任务的情况下作仿真实验比较,测试结果如图8所示。实验结果表明,在虚拟机数量固定的情况下,随着云任务的增加,安全机制的仿真运行相对于普通仿真运行的性能损耗差异较小.因此,本文安全访问控制机制不会对系统运行造成影响.
5 结论
IaaS云计算下资源管理问题一直是不可忽略的安全问题,本文针对传统的访问控制在应用于云计算IaaS层资源访问时出现的动态授权和最小授权问题,提出了一种基于任务和角色面向服务的访问控制(TRSAC)策略.该策略利用独立访问控制模块通过服务关系划分动态分配权限,既满足了分布式访问控制的要求,同时也具有清晰的角色层次管理.
本文通过分析TRSAC策略对于云计算访问控制的适用性,构建了一个面向共享安全的访问控制机制,从策略管理、权限仲裁、安全控制3个方面解决了云计算访问控制中的安全要求.理论分析与实验结果表明,该方法能较好地保证访问控制中的动态授权原则和最小授权原则,有效地增强了云计算基础设施服务整体的安全性.但是TRSAC模型也有不足,在未来的研究工作中期望能不断改进完善,而云计算数据除了访问控制之外,还有如数据存储安全等问题,同样有待进一步的研究.
转载请注明来自：http://www.zazhifabiao.com/lunwen/dzxx/xxaq/27993.html
下一篇：构建商业银行信息安全体系的建议
