2020, Vol. 31
2. 软件工程国家工程研究中心(北京大学), 北京 100871
2. National Engineering Research Center for Software Engineering(Peking University), Beijing 100871, China
近年来, 云计算已经成为企业减少开销、按需分配计算资源的重要手段[1, 2].目前, 主流云平台通常利用Web接口提供服务.由于这些接口直接暴露在Internet上, 因此, 为了防止数据泄露和非授权访问, 有必要利用访问控制策略对云平台资源进行安全防护.近年来, 学术界提出了多种访问控制策略描述语言, 如XACML(extensible access control markup language)[3]、SPL(security policy language)[4]、Ponder[5]等.目前较为主流的XACML语言由标准组织OASIS提出, 采用基于属性访问控制(attribute-based access control, 简称ABAC)模型[6].然而, 除了JBoss、Axiomaics、OpenAZ等系统外, XACML并没有被业界云平台广泛应用.大型公有云提供商如AWS (Amazon Web services)、Microsoft Azure等更倾向于自行设计一套策略描述语言用于自身平台.类似的还有HP Openview PolicyXpert、CiscoAssure等网络管理平台, 也都仅支持自己的策略语言[7].OpenStack作为目前主流的开源IaaS(infrastructure as a service)云平台, 利用Keystone组件为其他服务提供统一的身份认证, 然而访问控制则依赖于云主机上本地存储的策略文件.该策略文件除了云服务提供商以外, 其他人无法进行修改.OpenStack策略支持ABAC及基于角色访问控制(role-based access control, 简称RBAC)[8, 9].这些模型都是硬编码到云平台中, 并且缺乏自定义功能.虽然目前多策略、混合策略成为访问控制策略领域的研究热点[10-12], 然而这些解决方案仍然侧重于提高策略描述语言的表达能力和功能, 大多数存在语法复杂、实现复杂度过高、难以直接适配实际环境等问题.
可见, 当前云平台上存在多种不同的访问控制机制、策略语言.其差异具体表现为3个方面.
1) 各访问控制模型在概念上存在区别, 难以互通.如RBAC定义了角色概念, ABAC定义了属性概念等.
2) 即使访问控制模型相同或相似, 不同的策略语言在语法层面仍存在巨大差异.例如, XACML与OpenStack策略都支持ABAC, 然而XACML定义了策略集、策略、规则、集成算法等元素, 并采用XML语法; 而OpenStack策略则采用较为简单的“条件-动作”式的规则集合表达正向授权动作, 基于JSON语法.
3) 策略决策、实施的逻辑需要依赖某种具体程序设计语言来实现.不同云平台的开发语言不同, 导致策略决策、实施逻辑无法跨云平台使用.例如, OpenStack采用Python实现, CloudStack则采用Java实现, 容器云平台Kubernetes则采用Go实现.即使这些云平台支持相同的访问控制模型及策略语言, 其策略决策、实施逻辑仍需要在多个开发语言上分别进行实现.
本文假设云用户具有策略编写的能力, 可以为本租户内的云资源定义访问控制策略.上述3个差异会造成如下问题:(1)若同时使用多个云平台, 云用户则需要学习多种安全策略语言, 学习成本较高, 并且云迁移时, 安全策略无法迁移, 需要重新编写; (2)云服务提供商需要自行设计一套安全策略语言, 并设计、实现相应的访问控制机制, 设计、开发成本较高.
为了解决上述问题, 本文提出一种基于请求(request)、策略(policy)、匹配器(matcher)、策略效果(effect)的访问控制元模型PERM(policy-effect-request-matcher), 并设计了相应的策略描述语言PML(PERM modeling language).PML能够表达一系列现有的访问控制模型, 如ACL(access control list), BLP(Bell LaPadula)[13]、RBAC、ABAC等.基于PML提出了策略实施机制PML-EM(PML enforcement mechanism).PML-EM包含策略规则层、策略规则适配器层、模型层、解释器层等.现有的访问控制机制在实施安全策略时, 通常直接依据某种具体策略语言设计相应的决策逻辑.这种方式虽然简单, 但与策略语言、策略所基于的访问控制模型、程序实现语言都存在紧耦合, 从而不具备通用型.本文提出了访问控制机制的3个性质:策略语言无关性、访问控制模型无关性、程序设计语言无关性.在PML-EM中, 策略规则适配器层实现了策略语言无关性, 模型层实现了访问控制模型无关性, 解释器层实现了程序设计语言无关性.这3个性质对云用户、云服务提供商的意义在于:
1) 策略语言无关性:策略编写者可以利用一种自身所熟悉或业务所依赖的安全策略语言, 对所有支持PML-EM的云平台实施统一访问控制.不需要因为业务迁移到不同云平台再学习额外的策略语言, 极大地节省了学习成本和迁移成本.
2) 访问控制模型无关性:策略语言本身通常基于某种访问控制模型, 因此实现访问控制模型无关性是实现策略语言无关性的基础.与策略语言无关性类似, 该性质方便了云用户使用同一套访问控制模型对不同云平台的资源实施访问控制.对云服务提供商而言, 则可以在不显著增加设计成本的情况下, 实现对多种访问控制模型(如BLP、RBAC、ABAC)的支持, 从而满足不同的应用场景.
3) 程序设计语言无关性:云服务提供商不需要使用自身云平台所使用的程序设计语言再将PML解释器再进行实现, 从而极大地降低了云服务提供商的开发成本.解释器通常逻辑比较复杂.由于现代软件迭代速度加快, 即使云服务提供商有意愿直接开发PML解释器, 也很难保证各程序设计语言的PML解释器的版本一致, 后续维护成本高昂.而在采用中间脚本语言如Lua实现PML解释器后, 云服务提供商只需要提供Lua解释器即可, 而Lua解释器在各知名程序设计语言中都有成熟的开源实现, 可以直接采用.
本文在OpenStack云平台上实现了PML-EM框架.实验结果表明, 在性能方面, 与OpenStack原有策略相比, PML的策略评估开销平均为4.8%;在策略转换方面, 实验验证了PML策略转换为XACML、OpenStack、IAM等策略的正确性; 在表达能力方面, PML支持BLP、RBAC、ABAC等访问控制模型以及多租户、RESTful (representational state transfer)[14]、策略集成、策略转换等特性, 更适于云环境的访问控制需求.
1 相关工作近年来, 学术界和工业界都致力于研究如何利用访问控制实现更安全的云计算.业界主流公有云AWS通过IAM(identity and access management)组件来实施基于身份的访问控制.IAM为租户提供了用户、组、角色、权限、属性等概念来表达安全策略, 包含了对RBAC和ABAC的支持.其他云平台如Microsoft Azure、Google App Engine也提供了类似的机制.这些安全策略通常都需要采用云服务提供商自己的策略语言来编写, 不同平台的安全策略之间无法通用.
OASIS组织基于ABAC提出了可扩展访问控制标记语言XACML[3].XACML定义了规则、策略、策略集等概念, 并支持拒绝优先(deny-override)、允许优先(permit-override)等将决策集成算法.XACML同时对访问控制框架进行了规范, 定义了包括策略决策点(policy decision point, 简称PDP)、策略执行点(policy enforcement point, 简称PEP)、策略信息点(policy information point, 简称PIP)以及它们之间的交互流程.然而, XACML仍存在一些不足, 如不支持租户, 以及必须依赖策略规则等限制.有些场景下(如BLP、静态属性的ABAC等), 只存在访问控制模型, 而缺乏动态可变的策略规则.因此, 若可以将访问控制模型和与其相应的策略规则分离, 则可以实现更灵活的定义, 如只定义访问控制模型而不定义策略规则.实现这种分离也有助于减少攻击面, 在不存在策略规则的情况下, 攻击者无法通过篡改策略进行攻击, 而静态的访问控制模型在系统运行中通常保持不变, 攻击者也难以进行篡改.
Wu等人[15]提出了访问控制即服务(access control as a service, 简称ACaaS)的思想来实施细粒度的访问控制, 然而该方法仅支持RBAC模型, 并且依赖AWS云平台的IAM, 难以在其他云平台如OpenStack上应用.Tang等人[16]提出了OSAC(OpenStack access control)模型, 对OpenStack的身份认证组件keystone中的域、租户等概念进行了形式化描述, 并提出了跨域信任以支持两个域之间的权限授权.该工作与本文方法是正交的:OSAC做出的域间信任决策可以看作PML策略的一个属性, 从而进一步提高访问控制的粒度.Jin等人[17]提出了适用于IaaS的形式化ABAC规范, 并在OpenStack上进行了实现.该规范包括操作模型IaaSop和管理模型IaaSad两部分, 支持对访问控制策略本身的管理.然而该方法不支持桩函数、决策集成等特性, 从而限制了模型的表达能力.
Damianou等人[5]提出了面向分布式系统的策略规范语言Ponder.Ponder支持授权策略、代理策略、信息过滤策略、抑制策略以及基于事件触发的义务策略.相比之下, PML只支持授权策略, 并采用表达式求值来实现其策略决策的灵活性.在授权策略方面, Ponder缺乏租户、算数运算符、逻辑运算符等表达特性, 支持静态策略冲突检测, 但缺乏决策集成机制(即冲突消解).Ribeiro等人[4]提出了安全策略语言(security policy language, 简称SPL).SPL支持实体、实体间关系的表达, 支持利用策略属性、量词的比较进行策略决策.SPL缺乏桩函数支持, 因此在自定义策略方面受限.Kagal等人[18]提出了基于道义逻辑的策略描述语言Rei, 以满足动态、开放环境中的安全需求.在Rei中, 策略以约束的形式规定可在资源上进行的授权或义务性操作.Rei通过元策略解决策略一致性和冲突问题.该语言支持组、角色等表达特性.Ashley等人[19]提出了企业级隐私授权语言(enterprise privacy authorization language, 简称EPAL).EPAL更侧重于隐私保护而不是访问控制.EPAL采用基于目的的访问控制模型(purpose-based access control).例如, 当医生具有治疗诊断目的时, 就可以访问对应病人的信息.该模型简化了传统的RBAC模型, 但引入了额外的目的元素.该语言提供了一定的策略精化和冲突检测机制.
2 PML语言实施访问控制策略通常包括策略规则以及实施这些策略规则的逻辑两个部分.一个支持多用户、多安全策略的系统通常支持用户自定义策略规则.然而实施这些策略规则的逻辑通常是静态不可改变的, 导致策略配置方面不够灵活.为了让云用户能够灵活配置自身策略, 需要明确策略评估中策略实施逻辑的概念.由于策略实施逻辑本质上反映了策略规则所属的访问控制模型, 因此有必要将访问控制模型与策略规则进行分离.在本文中, 将反映策略实施逻辑的抽象访问控制模型称为“模型”, 将被实施的策略规则称为“策略”或“策略规则”.模型代表了逻辑, 策略代表数据, 它们之间类似于一个程序中代码与数据之间的关系.
本节提出PERM建模语言(PERM modeling language, 简称PML)来表达访问控制模型及其策略规则.PML语言是一个元模型语言, 其基于本文提出的PERM(policy-effect-request-matcher)元模型.PERM元模型如图 1所示, 包含4个基本原语:Request、Policy、Effect、Matcher, 1个可选原语:Role以及若干特性, 如域、属性、桩函数等.
|
Fig. 1 PERM metamodel 图 1 PERM元模型 |
2.1 Request原语
Request原语是对访问请求的抽象, 其定义了访问请求的语义.一个访问请求通常由经典的三元组构成:进行访问的主体(subject)、被访问的客体(object)、访问动作(action).PML中描述上述三元组的Request原语可表示为
| $ r = sub, obj, act. $ |
PML提供了自定制Request原语的能力, 例如, 如果不需要控制到具体的资源, 可采用sub, act两元组的格式.如果主体需要采用所属域等额外信息来标识, 则可采用domain, sub, obj, act四元组作为Request原语声明.
2.2 Policy原语Policy原语定义了策略规则的语义, 该字段制定了PML策略的解释器应如何解释策略规则.为简单起见, 本文采用逗号分隔值(comma-separated values, 简称CSV)来作为策略规则的语法.与Request原语类似, 经典的Policy原语也由主体、客体、动作三元组构成:
| $ p = sub, obj, act. $ |
与其相应的策略规则可以为
| $ p, alice, data1, read. $ |
策略中的每一行都是一条策略规则.策略规则的第1个元素是策略类型, 该字段与Policy原语相对应, 通过指定不同的策略类型可以支持多个Policy原语, 如p, p2等.通常情况下, 不需要指定多个策略类型.上面的策略规则与之前的经典Policy原语的绑定关系为
| $ (alice, data1, read) \to (p.sub, p.obj, p.act). $ |
上述绑定类似于变量赋值, 可以在Matcher原语中使用.
2.3 Matcher原语Matcher原语定义了策略规则如何与访问请求进行匹配的匹配器, 其本质上是布尔表达式.可以理解为Request、Policy等原语定义了关于策略和请求的变量, 然后将这些变量代入Matcher原语中求值, 从而进行策略决策.Matcher原语支持+, -, *, /等算数运算符、==, !=, > , < 等关系运算符以及 & & (与), ||(或), !(非)等逻辑运算符. Matcher原语最终的运算结果应为布尔值0或1:1表示策略规则满足该匹配器, 0则表示不满足.与上节中列举的经典Policy原语相对应的Matcher原语为
| $ m=r.sub==p.sub\;\And \And\; r.obj==p.obj\;\And \And\; r.act==p.act. $ |
该Matcher原语表示访问请求中的主体、客体、动作三元组应与策略规则中的主体、客体、动作三元组分别对应相同.
2.4 Effect原语Effect原语定义了当多个策略规则同时匹配访问请求时, 该如何对多个决策结果进行集成以实现统一决策, 决策结果包括allow和deny两种.Effect原语支持some, any等量词以及条件关键字where, & & (与), ||(或), !(非)等逻辑运算符.some量词判断是否存在一条策略规则满足匹配器, any量词则判断是否所有的策略规则都满足匹配器.Where关键字表示后面跟策略规则的筛选条件.Effect原语可以表达允许优先(allow-override)、拒绝优先(deny-override)等多种决策集成方法.允许优先可以表达为
| $ e = some(where(p.eft = = allow)). $ |
该Effect原语表示如果存在任意一个决策结果为allow的匹配规则, 则最终决策结果为allow, 即allow- override.其中, p.eft表示策略规则的决策结果, 可以为allow或者deny.当不指定规则的决策结果时, 取默认值allow.利用Effect原语还可以表达拒绝优先:
| $ e = !some(where(p.eft = = deny)). $ |
该Effect原语表示如果不存在任何决策结果为deny的匹配规则, 则最终决策结果为allow, 否则为deny. Effect原语还可以利用逻辑运算符进行连接:
| $ e = some(where(p.eft = = allow))\;\& \&\; !some(where(p.eft = = deny)). $ |
该Effect原语表示当至少存在1个决策结果为allow的匹配规则, 且不存在决策结果为deny的匹配规则时, 则最终决策结果为allow.这时正向授权和负向授权同时存在, 并且拒绝优先.
2.5 Role原语Role原语定义了RBAC中的角色继承关系, 该原语的特点是支持多重RBAC体系的表达.比如, 当主体和客体同时具有角色(或组)的概念时, 主体角色和客体角色两套RBAC体系可以互不干扰.同时支持主体角色和客体角色的Role原语可以定义如下:
g=_, _
g2=_, _
上述Role原语表示g是一个RBAC体系, g2是另一个RBAC体系._, _表示角色继承关系的前项和后项, 即前项继承后项角色的权限.PML把角色继承关系也表达为策略规则, 如
| $ g, alice, data2\_admin. $ |
上述策略规则表示alice具有角色data2_admin.这里的alice可以为具体的某个主体或者另一个角色.g则表示策略类型, 与Role原语相对应.在Matcher原语中, 请求主体与策略规则主体之间的是否具有角色继承关系可以用布尔函数g(r.sub, p.sub)来表达:值为1表示两者具有角色继承关系, 0则表示不具备该关系.角色继承关系支持间接继承.可以看出, Matcher原语中的一个布尔函数g, 与Role原语中的g和策略规则中相应的策略类型g互相对应, 共同完成RBAC角色的指派.其他RBAC体系, 如g2用法类似, 这里不再赘述.下面的例子给出了完整的Matcher原语.
| $ m = g(r.sub, p.sub){\rm{ \;\& \&\; }}r.obj = = p.objr.act = = p.act. $ |
该Matcher原语表达了经典的RBAC场景:策略规则定义哪些角色可以具备哪些权限(即采用哪种动作访问哪个资源), 只有当请求主体继承策略规则中指定的角色, 并且请求与策略规则中的资源和动作对应相同时, Matcher原语才会成功匹配该请求与该策略规则.
2.6 域云平台中通常存在租户的概念.为了实现灵活的授权管理, PML通过域内Role原语来支持租户内的授权.一个域代表一个租户, 域内角色只在本域内生效, 也只能分配本域内的资源的权限.域内角色机制实现了云平台租户间的安全隔离.域内Role原语可以定义为
| $ g = \_, \_, \_. $ |
原语中第3个_表示域的概念.相对应的策略规则的实例如下:
● p, admin, tenant1, data1, read;
● p, admin, tenant2, data2, read;
● g, alice, admin, tenant1;
● g, alice, user, tenant2.
相对应的Matcher原语可以为
| $ m = g(r.sub, p.sub, r.dom){\rm{ \;\& \&\; }}r.dom = = p.dom{\rm{\;\& \&\; }}r.obj = = p.obj{\rm{\;\& \&\; }}r.act = = p.act. $ |
该实例表示tenant1的域内角色admin可以读取data1, tenant2的域内角色admin可以读取data2.alice是在tenant1域中是admin角色, 但在tenant2域中是user角色, 因此根据策略规则, alice只能读取data1而不能读取data2.
2.7 属性为了支持ABAC的属性概念, PML采用.(点)语法来表达元素属性(元素即主体、客体、动作等).属性本身也是元素, 因此可以继续获取属性的属性.例如, r.sub.domain表示访问请求的主体所在的域, 而r.sub.domain. owner则表示该域的所有者.
| $ m = r.sub.domain = = r.obj.domain. $ |
上述Matcher原语表示只有当请求的主体所在的域与请求的客体所在的域相同时, 才允许该请求.PML本身也依赖与属性类似的语法, 如r.sub可理解为请求r这个元素的sub属性.通过提供一致的语法, 有助于降低策略编写者学习语言的成本.
2.8 桩函数虽然PML的Matcher原语通过各种运算符提供了强大的表达能力, 但是仍有一些复杂的处理逻辑无法用PML表达, 如查询外部数据库、进行复杂数学运算等.PML中提供了桩函数机制以满足自定义处理逻辑的需求.策略编写者可以在PML以外以其他程序设计语言自定义若干桩函数(stub function), 然后将这些函数注册到PML中, 从而被PML的Matcher原语所识别和调用.桩函数与普通函数类似, 可以带有多个参数, 并具有返回值.下面给出桩函数my_func的例子.my_func判断请求客体与策略规则客体之间是否匹配, 并返回布尔值.首先需要将该函数进行注册:
| $ register\_function\left( ''my\_func'', my\_func \right). $ |
my_func的实现可以如下:
boolean my_func(r.obj, p.obj) {
return r.obj==p.obj
}
这样就可以在Matcher原语中指定该函数, 参与到匹配中:
| $ m=r.sub==p.sub\;\And \And\; my\_func(r.obj, p.obj)\;\And \And\; \text{ }r.act==p.act. $ |
PML提供内置的桩函数, 以满足常用Matcher匹配需求.比如, keyMatch(r.obj, p.obj)函数支持匹配RESTful路径, 当请求中的RESTful路径匹配策略规则时, 返回布尔值1, 并允许以“*”作为通配符.regexMatch(r.obj, p.obj)函数则提供了更强大的正则表达式匹配的功能, 当请求中的客体匹配策略规则中指定的正则表达式时, 返回布尔值1.
3 PML策略实施机制访问控制策略需要实施机制来保证策略的决策、实施, 例如, XACML策略由策略决策点PDP来进行实施.现有的策略实施机制都依赖于某种策略语言或访问控制模型, 并且需要在某个具体的程序设计语言上进行实现, 无法很好地满足前文提出的访问控制机制的3个性质:策略语言无关性、访问控制模型无关性、程序设计语言无关性.第2节提出的PML语言能够实现对不同访问控制模型的统一描述, 从而实现访问控制模型无关性.为了实现另外两个性质, 本节在PML的基础上提出了PML策略实施机制(PML enforcement mechanism, 简称PML-EM).
3.1 总体架构PML-EM的体系结构如图 2所示, 自顶向下包括以下4个层次.
|
Fig. 2 PML-EM: PML enforcement mechanism 图 2 PML策略实施机制PML-EM |
1) 策略规则层:策略规则层包含各个访问控制策略描述语言的策略规则, 所有策略编写者所制定的策略规则位于该层, 如XACML规则、OpenStack规则、IAM规则等.PML语言除了描述访问控制模型外, 自身也支持描述策略规则, 即PML规则, PML规则也属于策略规则层.与其他策略不同的是, PML规则可以直接与PML模型兼容, 因此不需要额外的策略规则适配器.
2) 策略规则适配器层:策略规则适配器层包含对各个策略描述语言的适配器, 适配器可以将某一种策略语言描述的规则转换为等价的PML规则.例如, XACML策略规则适配器可以将XACML规则等价转换为PML规则.这里, PML规则就类似于一种中间语言.该层通过适配器机制实现了策略语言无关性.需要注意的是, 该转换主要是语法层面的转换, 不包括语义的转换, 语义层面的解析由模型层负责.
3) 模型层:该层包含采用PML语言描述的各种不同的访问控制模型.不同的策略描述语言(如XACML、OpenStack等)的访问控制模型也不同, 因此需要采用PML语言进行统一描述.该层实现了访问控制模型无关性.
4) 解释器层:该层主要负责解析PML模型和规则, 依据解析结果对访问请求进行策略决策, 给出allow或者deny的结果.解释器采用通用的脚本语言Lua实现, 从而实现程序设计语言无关性.
在PML-EM机制中, 策略规则层即为不同策略语言所描述的具体策略规则, 如XACML规则、OpenStack规则以及本文的PML规则.而模型层则为PML语言所描述的各种不同的访问控制模型, 在第2节已经阐述.因此, 下文主要阐述另外两层:策略规则适配器层和解释器层.
3.2 策略规则适配器层策略规则适配器负责将某种策略语言描述的策略规则(即目标策略)转换为PML模型及PML规则.本节提出一种基于抽象语法树(abstract syntax tree, 简称AST)的策略转换方法.AST常用于编程语言源代码分析领域.将源代码通过词法、语法分析解析为AST后, 该AST不再依赖于具体编程语言语法, 相当于一种通用的“中间语言”, 为下一步处理提供一个清晰的接口.策略语言与编程语言有类似之处, 都具有特定的语法, 因此首先将策略语言(包括目标策略和PML模型、规则)转换为AST进行处理, 可以屏蔽策略语言的语法细节, 有助于实现策略转换.AST是一种无语义损失的表示形式, 意味着策略不仅可以转换为AST, AST还可以转换回原有的策略.利用AST技术, 原来的将目标策略转换为PML模型、规则的问题就可以简化为将目标策略AST转换为PML对应的AST的问题.由于策略语言大多基于某种通用数据格式, 如XML、JSON等, 因此可以直接借助相关的解析器等就能实现将目标策略的各个元素, 如策略、规则、主体、客体、动作等表达成AST.
为了完成策略转换, 给出一种策略转换算法.算法的输入是目标策略AST, 输出是PML对应的AST.目标策略AST也包含对请求格式的定义.策略转换算法的具体步骤如下.
1) 分析目标策略的请求格式AST, 将AST的每个叶子节点转换为Request原语AST的叶子节点.
2) 将目标请求AST中, 每一个带有匹配逻辑的AST子树转换为Matcher原语的AST子树.
3) 将目标策略AST中, 带有策略集成逻辑的AST子树转换为Effect原语的AST子树.
4) 将具有相同子树结构, 并具有同一个父节点的Matcher原语AST子树定义为同类Matcher原语, 将其合并为一个Matcher原语、一个Policy原语以及若干策略规则.
5) 相同格式的Policy原语进行合并, 合并为一个Policy原语, 同时合并对应的策略规则.
上述算法的伪代码如算法1所示.
算法 1.策略转换算法.
Input: targetAST:目标策略AST.
Output: pmlAST:PML AST.
1. pmlAST.Request.leafNodes=targetAST.request.leafNodes //生成PML AST的Request原语
2. for each p in targetAST.subTrees do
3. if hasMatchLogic(p) then
4. pmlAST.Matcher.subTrees.add(p) //转换带有匹配逻辑的AST子树
5. else if hasIntegrationLogic(p) then
6. pmlAST.Effect.subTrees.add(p) //转换带有策略集成逻辑的AST子树
7. end if
8. end for
9. for each m1, m2 in pmlAST.Matcher do
10. if hasSameParent(m1, m2) & & hasSameSubtree(m1, m2) then
11. m, p, rules=combineMatcher(m1, m2) //合并具有相同子树结构、父节点的Matcher原语
12. pmlAST.Matcher.add(m)
13. pmlAST.Policy.add(p)
14. pmlAST.Rules.add(rules)
15. end if
16. end for
17. for each p1, p2 in pmlAST.Policy do
18. if hasSameFormat(p1, p2) then
19. p=combinePolicy(p1, p2)
20. rules=combineRules(p1.rules, p2.rules)
21. pmlAST.Policy.add(p) //合并相同格式的Policy原语
22. pmlAST.Rules.add(rules) //合并对应的策略规则
23. end if
24. end for
25. return pmlAST
3.3 解释器层PML解释器主要包含3个原语:加载模型、加载策略和策略决策.本文假设PML模型、策略都存储在策略数据库中.接下来详细介绍这3个原语.
1) 加载模型:负责加载PML模型.输入为策略数据库, 输出为PML模型.加载PML模型主要包括解析各种原语:Request原语、Policy原语、Matcher原语、Effect原语、Role原语等, 以及加载用户注册的桩函数.
2) 加载策略:负责加载PML规则.输入为策略数据库, 输出为PML规则.加载策略较为简单, 主要是将PML规则一条一条地加载到解释器中.如果存在角色继承规则, 则需要在加载完毕时建立角色继承关系树, 从而实现对间接角色继承的判断.每一个RBAC角色体系都具有不同的角色继承关系树, 从而互不干扰.
3) 策略决策:对请求进行策略决策.输入为PML模型、PML规则以及访问请求, 输出为决策结果.在PML中, 访问请求的语义由Request原语定义, PML策略规则的语义则由Policy原语定义.在决策过程中, PML解释器会根据上述语义将访问请求的上下文(即具体的主体、客体、动作等)、每一条PML规则以及所有的桩函数代入到Matcher原语中, 然后对Matcher原语求值.对Matcher的求值可以采用Lua的按字符串执行的内置函数loadstring进行实现.需要注意的是, Role原语(包括域)和属性也是以桩函数的形式定义的, 因此可与用户自定义的桩函数一同代入到Matcher原语中, 不需要特殊处理.由于可能存在多条PML规则, 因此Matcher的求值结果也可能不唯一.这时, PML解释器再通过Effect原语对多个Matcher求值结果进行集成, 从而得到统一的决策结果.算法2描述了策略决策的过程.
算法 2.策略决策算法.
Input: model:PML模型; policy:PML策略; request:访问请求.
Output: decision:决策结果.
1. Set decisions={·}
2. for each matcher in model do
3. matcher.inject(model.stubFunctions) //将桩函数代入Matcher原语
4. matcher.inject(request) //将Request原语代入Matcher原语
5. for each rule in policy do
6. matcher.inject(rule) //将Policy原语对应的规则代入Matcher原语
7. decisions.add(evaluate(matcher)) //对Matcher求值并记录决策结果
8. end for
9. end for
10. decision=combineDecision(decisions, model.Effect) //利用Effect原语进行决策结果集成
11. return decision
由于Matcher需要执行外部的桩函数代码来进行策略决策, 假如桩函数内部存在恶意代码, 则会影响访问控制机制甚至整个云平台系统的安全性.这个问题的解决方案包括:
1) 为桩函数创建沙箱, 桩函数仅在沙箱内执行代码, 不会影响到整个PML解释器以及外部系统.Lua语言环境本身也是一层沙箱, 因此可以作为第2道防线.
2) 静态代码检查, 即服务提供商在为用户注册桩函数之前, 先通过代码静态分析等手段检查桩函数源代码, 确定其没有恶意行为.
3) 定制桩函数编辑接口, 即服务提供商不直接提供编写桩函数代码的功能, 而是将常用的功能封装在编辑接口(可以为命令行或图形界面)中, 用户只能采用预定义的编辑接口定制桩函数的功能, 由于编辑接口的安全性是可控的, 因此该方式也可以有效屏蔽恶意代码.
PML解释器本身采用脚本语言Lua编写.Lua是一种轻量级的脚本语言, 该语言代码通常不直接独立运行, 而是作为脚本语言嵌套在其他程序设计语言中执行特定逻辑.Lua的解释器通常非常轻量级(不大于200KB), 目前, 绝大多数主流程序设计语言如C、Java、Python等都有成熟、开源的Lua解释器实现.因此, 用Lua编写PML解释器具有跨程序设计语言的优势, 从而可实现程序设计语言无关性:需要实施访问控制的系统不需要实现PML解释器, 而只需要嵌入现有的Lua解释器, 即可实现对PML的支持.另外, 从接口交互来讲, 访问控制与系统其他模块的接口比较明确、耦合程度较低, 因此, 用脚本语言实现也不会造成系统复杂度的明显增加.
4 实验验证本文实验环境为OpenStack Pike云平台, 集群中包含1个控制节点(包含网络)、4个计算节点和2个块存储节点.本文实现的原型系统如图 3所示, 包含一个新增加的OpenStack组件Patron以及请求过滤器模块AEM (access endpoint middleware).AEM是一个安装在云平台其他组件(如Nova、Glance)上的WSGI(Web server gateway interface)过滤器组件.所有的云平台请求都会经过AEM的过滤, 将请求的安全上下文信息(如主体、客体、动作等)发送到Patron服务.Patron服务实现了PML-EM策略实施机制, 对AEM发送过来的请求进行授权决策, 决定是否允许该请求:若允许, 则AEM会放行该请求; 否则, 则返回HTTP 403拒绝访问错误.为了提高性能, AEM中加入缓存机制, 可将已进行的策略决策结果进行缓存, 从而减少对Patron的决策请求.
|
Fig. 3 Architecture of the OpenStack cloud after using PML 图 3 采用PML后的OpenStack云平台架构 |
Patron组件包括以下3个模块.
1) API模块(patron-api):对外以RESTful接口提供Patron服务, 接受决策请求, 返回决策结果.
2) 决策模块(patron-decide):负责进行策略决策.实现了PML-EM策略实施机制, 包括PML解释器、各策略规则适配器等.
3) 策略更新模块(patron-update):负责策略存储和策略更新.
原型系统中, PML解释器、策略规则适配器采用Lua语言实现, 其他模块则与OpenStack一致, 采用Python实现.这里的PML解释器、策略规则适配器可以在其他系统上重用, 印证了PML-EM的程序设计语言无关性, 即, 对需要实施访问控制系统的开发语言不存在依赖.
4.1 表达能力本文将PML与其他主流策略语言进行了对比, 结果见表 1.ACL模型允许客体的所有者(即属主)自动拥有对该客体的权限.在PML中, 可通过属性来描述ACL中属主的概念.BLP模型需要依据主体、客体的安全级别来决定主体是否可以读、写客体, 因此需要策略语言对安全级别的支持.PML可以通过Matcher原语提供安全级别的比较.PML的Role原语和属性机制则分别对RBAC和ABAC进行了支持.Superuser表示特权用户, 特权用户可以执行任意操作, 从而方便云服务提供商对自身进行管理.PML可以利用Matcher原语对特权用户进行定义, 当匹配特权用户ID时, 使决策结果为允许.云平台通常以租户(域)为单位来管理云用户, 因此, 是否支持多租户对云平台访问控制至关重要.PML通过域特性以支持云环境下租户粒度的权限管理.云平台以及其他Web服务通常采用RESTful[14]接口作为程序调用接口, PML通过内置桩函数keyMatch, regexMatch等支持对RESTful路径进行访问控制.从策略转换和多语言可以看出, 支持则是PML所独有的特性.PML-EM的策略规则适配器机制可将其他语言的策略转化为PML策略, 而多语言支持则允许PML解释器在不同开发语言所编写的系统中运行, 从而满足不同平台的访问控制需求.另外, 从表 1中可以看出, 所有策略语言均支持RBAC, 大部分策略语言支持ABAC.由于大多数策略语言并不是为云环境设计的, 因此不支持多租户.在策略语言中, 除了PML以外, XACML支持最多的语言特性.
|
Table 1 Expressiveness comparison of different policy languages 表 1 不同策略语言的表达能力对比 |
4.2 策略转换
为了验证策略规则适配器, 本文设计了XACML策略、OpenStack策略和AWS IAM策略的策略规则适配器, 并采用用例验证其效果.
4.2.1 XACML策略转换XACML访问控制策略采用XML语法来描述, 包括Policy、Rule等核心概念, 并通过策略集成算法和规则集成算法实现统一决策.本节通过XACML conformance测试集来验证XACML策略规则适配器的可用性.由OASIS推出的XACML conformance测试集提供了对XACML策略、请求、响应的标准测试.所有XACML PDP实现都需要满足该测试集的要求.该测试集包括强制的5类测试用例:IIA、IIB、IIC、IID、IIE, 分别为属性用例、目标用例、函数用例、集成算法用例和模式用例.下面以IIA001策略为例验证策略转换的效果, XACML策略规则适配器首先需要将IIA001策略预处理为如图 4所示的AST.
|
Fig. 4 AST of XACML policy: IIA001 图 4 XACML策略IIA001对应的抽象语法树 |
IIA001策略主要针对主体id、客体id、动作id进行匹配, 授权效果为Permit, 采用deny-overrides的规则集成算法.由于其动作id存在两个:read和write, 为了在PML规则中同时指定两个动作, 可以采用regexMatch桩函数进行正则匹配, 同时匹配read和write两个动作.根据第3.2节提出的策略转化算法, 可以设计出相应的XACML策略规则适配器.通过适配器转换后, IIA001策略可转换为PML模型和规则.其中, PML模型为:
r=sub, obj, act
p=sub, obj, act, eft
e=some(where(p.eft==allow)) & & !some(where(p.eft==deny))
m=r.sub==p.sub & & r.obj==p.obj & & regexMatch(r.act, p.act)
PML规则为
Julius Hibbert, http://medico.com/record/patient/BartSimpson, (read)|(write), allow.
XACML官方策略示例集共有374条策略, 本文XACML策略适配器已经成功适配其中的350条, 其他未适配的策略由于需要实现特殊的匹配函数(如复杂字符串操作), 在未实现相应PML桩函数时暂时无法匹配, 但在PML中注册相应的桩函数后也可实现.
4.2.2 OpenStack策略转换本节验证OpenStack策略规则适配器的可用性.以下为OpenStack Nova计算组件内置策略的一个片段.
“context_is_admin”: “role: admin”
“admin_or_owner”: “is_admin: True or project_id:%(project_id)s”
“default”: “rule: admin_or_owner”
“compute: get”: “·”
“compute: get_all”: “·”
“compute: get_all_tenants”: “is_admin: True”
“compute: delete”: “rule: admin_or_owner”
OpenStack策略主要采用的ABAC模型, 有很多属性的表达, 可以采用PML的属性机制来描述.例如, 其用户的管理员身份通过role和is_admin两个属性来表达, 因此在Matcher原语中, 可以采用r.sub.role==“admin”|| r.sub.is_admin==true来描述这两种属于管理员的情形.OpenStack策略中还有针对属主(owner)的权限, 即云资源的所有者对该资源具有访问权限, 具体是通过比较主体、客体两者的project_id属性(即租户id)是否相同来实现, 因此在PML中可以表述为r.sub.project_id==r.obj.project_id.由于OpenStack策略将动作划分成了Admin动作和Owner动作两组, Admin动作只有管理员能够执行, Owner动作则可以被管理员和资源所有者执行.因此在PML中, 可以将Owner动作用规则来枚举, 即出现在规则中的动作为Owner动作, 否则则为Admin动作.结合上述project_id属性的比较, 则可以给出Matcher原语:r.act==p.act & & r.sub.project_id==r.obj.project_id.
通过以上分析, 可以设计出相应的OpenStack策略规则适配器.通过适配器转换后, 上述Nova策略实例可转换为PML模型和规则.其中, PML模型为:
r=sub, obj, act
p=act
e=some(where(p.eft==allow))
m=r.sub.role==“admin”||r.sub.is_admin==true||(r.act==p.act & & r.sub.project_id==r.obj.project_id)
PML规则为:
compute: get
compute: get_all
compute: delete
通过分析易得出, OpenStack Nova内置策略和策略转换后的PML策略是等效的.本文还验证了Glance、Neutron、Cinder等其他组件的内置策略均可转换为等效的PML策略.
4.2.3 IAM策略转换本节验证AWS IAM策略规则适配器的可用性.IAM策略综合采用了RBAC与ABAC两种模型, 采用JSON格式进行描述.AWS公有云目前共内置261条安全策略, 分别应用于AWS的众多类型的云服务.以下为针对EC2(elastic compute cloud)弹性计算服务的AmazonEC2ReadOnlyAccess策略, 该策略允许附加该策略的用户只读访问EC2、ELB弹性负载均衡、AutoScaling自动扩缩服务、CloudWatch监控服务的所有资源.
“Version”: “2012-10-17”,
“Statement”: [{
“Effect”: “Allow”,
“Action”: “ec2: Describe*”,
“Resource”: “*”
}, {
“Effect”: “Allow”,
“Action”: “elasticloadbalancing: Describe*”,
“Resource”: “*”
}, {
“Effect”: “Allow”,
“Action”: [
“cloudwatch: ListMetrics”, “cloudwatch: GetMetricStatistics”, “cloudwatch: Describe*”
],
“Resource”: “*”
}, {
“Effect”: “Allow”,
“Action”: “autoscaling: Describe*”,
“Resource”: “*”
}]
设计AWS IAM策略适配器, 主要需要对客体(resource)、操作(action)、效果(effect)进行适配.
由于Resource和Action都需要通配符“*”的支持, 因此在PML中需要采用keyMatch桩函数来表达通配符“*”, 即keyMatch(r.obj, p.obj)和keyMatch(r.act, p.act).由于IAM策略采用绑定在主体上的方式进行策略生效操作, 因此策略本身并不出现主体, PML中也无需再描述主体信息.另外, 由于IAM策略支持Allow和Deny两种授权效果, 并且拒绝优先, 因此需要在PML的Effect原语指定请求允许当且仅当Matcher原语的匹配结果存在Allow且不存在Deny, 即some(where(p.eft==allow)) & & !some(where(p.eft==deny)).
通过以上分析, 可以设计出相应的AWS IAM策略规则适配器.
通过适配器转换后, 上述AmazonEC2ReadOnlyAccess策略实例可以转换为PML模型和规则.其中, PML模型为:
r=obj, act
p=obj, act, eft
e=some(where(p.eft==allow)) & & !some(where(p.eft==deny))
m=keyMatch(r.obj, p.obj) & & keyMatch(r.act, p.act)
PML规则为:
*, ec2: Describe*, allow
*, elasticloadbalancing: Describe*, allow
*, cloudwatch: ListMetrics, allow
*, cloudwatch: GetMetricStatistics, allow
*, cloudwatch: Describe*, allow
*, autoscaling: Describe*, allow
类似于上述AmazonEC2ReadOnlyAccess策略, 通过分析AWS现有的261条安全策略的策略转换结果, 验证了AWS原策略和策略转换后的PML策略是等效的.
4.3 策略评估性能本文采用OpenStack云平台的tempest测试集对PML策略评估性能进行测试.OpenStack原有安全策略与PML-EM的策略评估性能对比结果见表 2.在未引入AEM缓存时, PML-EM运行测试集的开销增加8.8%, 引入AEM缓存后开销降低为4.8%.这是由于时间开销主要是Patron与AEM之间的通信延迟.而在AEM引入缓存后, 能够将之前的决策结果缓存起来, 同类请求下次直接使用该决策结果, 从而不再需要查询Patron服务, 有效降低了开销.从表 2中可看出, 开销最坏情况发生在Cinder组件, 不开启缓存的延迟为15.4%, 开启后降低为7.9%.这是由于Cinder组件的每个请求的执行时间都比较短, 而PML-EM对每个请求引入的延迟是相对较为固定的(约为77ms), 这就导致决策延迟所占比例在Cinder上表现得比较明显.PML-EM的引入, 对Ceilometer组件的影响不明显.这是由于Ceilometer的操作较少, 策略也较为简单, 因此在策略决策方面开销较小.PML-EM对每个云平台访问请求引入的平均开销为77ms, 相对于云用户与云平台在Internet上的数据传输延迟来说是较小的, 因此不会显著影响用户体验.
|
|
Table 2 PML evaluation performance (s) 表 2 PML策略评估性能 (s) |
4.4 侵入性分析
PML-EM对OpenStack原有访问控制机制的侵入性见表 3.由于OpenStack原有策略依赖云平台中数量众多的钩子函数来进行权限检查, 这种方式导致访问控制机制与云平台业务逻辑耦合过于紧密.PML-EM原型系统中的策略决策组件Patron以独立组件的形式提供决策服务, 与云平台其他组件实现松耦合.AEM则以通用请求过滤器的形式进一步降低对云平台内部钩子函数的依赖.本文中, AEM对OpenStack其他组件的修改仅限于3个Python源代码文件.除了代码修改以外, 本文还分析了其他类型的修改, 如配置修改、PML模型修改、PML规则修改等, 产生的修改行数(lines of code, 简称LOC)增加约为0.42%.由于AEM是一个请求过滤插件, 因此需要对配置进行修改来启用该插件.PML模型和PML规则共同构成PML策略, 替代OpenStack原有的安全策略, 并保持策略语义不变.采用PML-EM可以去除对原有权限检查钩子的依赖, 从而不需要对云平台现有代码文件进行任何修改.在策略管理方面, Patron为云服务提供商和云用户(策略编写者)提供了策略管理的接口.当Patron组件所存储的策略被修改时, 为了保持一致性, AEM的决策缓存会被清除.AEM的缓存清除功能以API的形式提供, 与被AEM所过滤的云平台组件共用同一个RESTful接口, 这并不会增加被过滤组件的请求处理的复杂度.因为缓存清除的请求由AEM直接进行处理并进行响应, 不会进入到被过滤组件的业务逻辑中.所有基于OpenStack云平台的原有应用都可以不加修改地在应用PML-EM的云平台上运行而不受影响.
|
|
Table 3 Modification of PML-EM to OpenStack's original access control mechanism (LOC) 表 3 PML-EM对OpenStack原有访问控制机制的影响(LOC) |
5 总结与展望
本文提出一种基于元模型的访问控制策略描述语言PML及其实施机制PML-EM.PML支持表达BLP、RBAC、ABAC等多种访问控制模型, 并且具备多租户、RESTful、桩函数等特性, 以支持云平台场景下的访问控制.PML-EM则实现了策略语言无关性、访问控制模型无关性和程序设计语言无关性, 不仅降低了用户编写策略的成本, 而且降低了云服务提供商设计、开发访问控制机制的成本.在OpenStack上的实验结果表明, PML策略表达能力较强, 支持从XACML、OpenStack、IAM等其他策略进行转换.性能上, PML策略评估的开销平均为4.8%, 从而能够在不影响租户体验的同时, 有效提高云平台访问控制的安全性和灵活性.PML-EM机制的侵入性较小, 与云平台原有代码相比, 增加约0.42%.
下一步工作包括:研究PML策略之间的冲突检测问题, 给出冲突消解方案; 进一步探索提高策略转换、策略评估性能的优化方法.
| [1] |
Feng DG, Zhang M, Zhang Y, Xu Z. Study on cloud computing security. Ruan Jian Xue Bao/Journal of Software, 2011, 22(1): 71-83(in Chinese with English abstract).
http://www.jos.org.cn/1000-9825/3958.htm [doi:10.3724/SP.J.1001.2011.03958] |
| [2] |
Lin C, Su WB, Meng K, Liu Q, Liu WD. Cloud computing security:Architecture, mechanism and modeling. Chinese Journal of Computers, 2013, 36(9): 1765-1784(in Chinese with English abstract).
http://d.old.wanfangdata.com.cn/Periodical/rjxb201101006 |
| [3] |
Moses T. Extensible Access Control Markup Language (XACML) Version 2.0. Oasis Standard. 2005.
|
| [4] |
Ribeiro C, Zuquete A, Ferreira P, Guedes P. SPL: An access control language for security policies with complex constraints. In: Proc. of the Network and Distributed System Security Symp. 2001. 89-107.
|
| [5] |
Damianou N, Dulay N, Lupu E, Sloman M. The ponder policy specification language. In: Proc. of the Workshop on Policies for Distributed Systems and Networks (Policy 2001). 2001. 18-38.
|
| [6] |
Li NH, Mitchell JC, Winsborough WH. Design of a role-based trust-management framework. In: Proc. of the IEEE Symp. on Security and Privacy. 2002. 114-130.
|
| [7] |
Han WL, Lei C. A survey on policy languages in network and security management. Computer Networks, 2012, 56(1): 477-489.
[doi:10.1016/j.comnet.2011.09.014] |
| [8] |
Ferraolo D, Kuhn R. Role-based access control. In: Proc. of the 15th National Computer Security Conf. 1992. 554-563.
|
| [9] |
Sandhu RS, Coyne EJ, Feinstein HL, Youman CE. Role-based access control models. Computer, 1996, 29(2): 38-47.
[doi:10.1109/2.485845] |
| [10] |
Bao YB, Yin LH, Fang BX, Guo L. Approach of security policy expression and verification based on well-founded semantic. Ruan Jian Xue Bao/Journal of Software, 2012, 23(4): 912-927(in Chinese with English abstract).
http://www.jos.org.cn/1000-9825/4023.htm [doi:10.3724/SP.J.1001.2012.04023] |
| [11] |
Bertino E, Jajodia S, Samarati P. Supporting multiple access control policies in database systems. In: Proc. of the IEEE Symp. on Security and Privacy. 1996. 94-107. http://dl.acm.org/citation.cfm?id=884261
|
| [12] |
Minsky NH, Ungureanu V. Unified support for heterogeneous security policies in distributed systems. In: Proc. of the 7th USENIX Security Symp. 1998. 131-142. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.50.8706
|
| [13] |
Bell DE, Lapadula LJ. Secure computer systems: Mathematical foundations. MITRE Corporation Report, 1973.
|
| [14] |
Fielding RT, Taylor RN. Architectural styles and the design of network-based software architectures[Ph.D. Thesis]. University of California, 2000. http://dl.acm.org/citation.cfm?id=932295
|
| [15] |
Wu R, Zhang X, Ahn G, Sharifi H, Xie H. ACaaS: Access control as a service for iaas cloud. In: Proc. of the Int'l Conf. on Social Computing. 2013. 423-428. http://dl.acm.org/citation.cfm?id=2573038.2573922
|
| [16] |
Tang B, Sandhu R. Extending openstack access control with domain trust. In: Proc. of the Int'l Conf. on Network and System Security. 2014. 54-69. http://link.springer.com/10.1007/978-3-319-11698-3_5
|
| [17] |
Jin X, Krishnan R, Sandhu R. Role and attribute based collaborative administration of intra-tenant cloud IaaS. In: Proc. of the 10th IEEE Int'l Conf. on Collaborative Computing: Networking, Applications and Worksharing. IEEE, 2014. 261-274. http://ieeexplore.ieee.org/document/7014572/
|
| [18] |
Kagal L, Finin T, Joshi A. A policy language for a pervasive computing environment. In: Proc. of the Int'l Conf. on Collaborative Computing: Networking, Applications and Worksharing. 2003. 63-74. http://dl.acm.org/citation.cfm?id=826875
|
| [19] |
Ashley P, Hada S, Karjoth GUN, Powers C, Schunter M. Enterprise privacy authorization language (EPAL). In: Proc. of the IBM Research. 2003. 1−69.
|
| [1] |
冯登国, 张敏, 张妍, 徐震. 云计算安全研究. 软件学报, 2011, 22(1): 71-83.
http://www.jos.org.cn/1000-9825/3958.htm [doi:10.3724/SP.J.1001.2011.03958] |
| [2] |
林闯, 苏文博, 孟坤, 刘渠, 刘卫东. 云计算安全:架构、机制与模型评价. 计算机学报, 2013, 36(9): 1765-1784.
http://d.old.wanfangdata.com.cn/Periodical/rjxb201101006 |
| [10] |
包义保, 殷丽华, 方滨兴, 郭莉. 基于良基语义的安全策略表达与验证方法. 软件学报, 2012, 23(4): 912-927.
http://www.jos.org.cn/1000-9825/4023.htm [doi:10.3724/SP.J.1001.2012.04023] |