CN100592315C - 一种xacml策略规则检测方法 - Google Patents

Abstract

本发明提供了一种XACML策略规则检测方法，属于信息安全中的授权策略分析领域，该方法针对XACML策略规则进行了规则状态定义、规则状态相关性定义、冲突类型分析，在此基础上，建立了基于语义树的策略索引并实施具体的XACML策略规则检测，分析了规则冲突和规则冗余，检测方法包含两种类型：基于属性层次操作关联的冲突检测方法；基于状态相关性的其他类型冲突检测方法，冗余分析方面，分别在允许优先、拒绝优先和首次适用消解算法下给出规则冗余的分析判定方法。策略管理者通过检测方法可以准确定位引发冲突的规则以及引发冲突的原因；冗余分析方面，可以根据分析结果优化策略结构，删除不影响访问判定结果的冗余规则，提高策略判定效率。

Description

一种XACML策略规则检测方法

技术领域

本发明主要涉及信息安全中的授权策略分析领域，确切给出一种针对XACML策略规则检测的方法。

背景技术

随着组织间业务协作、分布式计算、跨域资源共享等应用的大量涌现，policy-basedmanagement面临新的挑战。开放式计算环境下，跨组织边界的用户和服务资源动态加入或撤出组织，安全策略需要考虑的安全属性种类繁多，授权决策的辅助参数也趋向复杂，组织内的授权管理灵活多变，共享资源的访问策略通常由多个管理域协同制定。这些情况不可避免导致了内部策略冲突的威胁发生。应用系统的安全管理初衷能否被准确执行、策略间的冲突能否合理消解返回确定可知的安全状态是基于策略的授权系统要解决的难点。

OASIS发布的访问控制策略标记语言XACML(Extensible Access Control MarkupLanguage)基于属性匹配机制定义策略规则，适用于分布式异构访问控制、多管理域策略合成等应用场景，具备丰富动态的描述能力对主客体和系统环境属性进行细粒度刻化，同时也导致其内部比较复杂的策略规则冲突类型。规则间Target定义存在交集而判定结果相反是XACML策略冲突的基本类型；属性层次导致的权限继承以及主体、资源属性层次间的互操作关系也可能引发规则冲突。XACML标准中给出了若干冲突消解算法，从判定结果角度规避了策略冲突对访问请求的影响，但其自身缺乏从管理视图角度分析造成冲突的细节原因以及冲突预测验证能力。

随着XACML策略广泛使用并成为工业界标准，很多研究工作开始关注对其进行分析、推理和验证。Margave是Fisler等基于MTBDDS开发的策略分析工具，将XACML策略转化为多端二元判定图并进行策略验证和策略改动影响分析。Martin等人在Margave基础上借鉴软件测试的方法，生成变异测试用例检测策略有效性，但缺乏策略间的约束分析和冲突检测。Zhang等人基于RW语言提出模型检测算法，验证策略是否满足用户合法需求以及能否阻止非法访问，并将RW验证后的策略转化为XACML形式。Hughes等人应用一阶逻辑分析工具Alloy对XACML策略进行建模，验证策略合并后的特征一致性。Bryans将XACML协议栈在进程代数CSP体系下建模，验证策略实施的行为特征和有效性。Kolovski实现了XACML策略到描述逻辑DL的映射，借助DL分析工具进行策略对比、策略冗余和策略验证。其对策略冗余的各种情况缺乏完整分析，在策略比较时也没有对属性层次引起的冲突进行检测。

总的来看，逻辑方法验证XACML策略需要在逻辑转化方面做大量工作。Margave和RW等缺乏足够支持XACML语义的描述能力，并且策略分析的层面局限在策略满足性验证方面；Alloy等一阶逻辑工具分析能力强大，但大规模策略分析应用会带来难以承受的资源消耗代价。另外，现有工作大多数集中在策略目标的可满足性验证，缺乏对XACML基于属性的特质进行分析推理以发现策略结构性冲突。

XACML策略分析的一个重要瓶颈是如何建立高效的策略索引结构。XACML策略分层定义机制决定了策略匹配是一个约束粒度逐层细化的过程。细化过程会过滤一定数量的不相关策略，但无法避免对策略库的遍历式匹配。大部分应用XACML的项目如Sun XACMLImplementation、eXist、Parthenon Computing等都采用类似方式，将策略集合一次性加载，针对特定查询请求逐条匹配。环境单一的小规模策略环境下，遍历式匹配方法对系统效率没有显著影响。但在大规模策略集成应用场景中，会制约判定实施点PDP检索有效策略的概率。

发明内容

针对上述问题，本发明的主要目的是提供针对XACML策略规则冲突检测的预定位方法，以及在给定冲突消解算法的情况下对规则冗余的判定。

本发明的解决方法立足于策略规则分析，包括一系列基本前提要求：规则状态定义、规则相关性定义、冲突类型分析等。在这些工作的基础上，建立策略索引并实施具体的XACML策略规则冲突检测。检测方法包含两种类型：基于属性层次操作关联的冲突检测方法；基于状态相关性的其他类型冲突检测方法。冗余分析方面，分别在允许优先(permit-override)、拒绝优先(deny-override)和首次适用(first-applicable)消解算法下分析判定规则冗余。

第一部分构建形式化分析模型：

1)规则状态及相关定义

规则状态sub_i、res_i、ac_i和en_i分别代表Rule中一个主体、资源、动作和环境属性分量，每个分量包括使断言合取式

为真的一组属性值，其中断言match_j是作用在属性值上的布尔函数，

分别表示各种属性分量的并集，Decision表示Rule的effect类型，则Rule的规则状态表示为

规则状态满足规则状态满足若规则Rule_i声明主体SA在环境状态为EA时，可以对资源RA进行访问动作AA，则属性状态向量(SA，RA，AA，EA)满足规则状态State_i，表示为State_i|＝(SA，RA，AA，EA)^effect。

2)制定XACML中的权限继承和权限蕴含规则

若SA₁是SA₂的上层属性，表示为若RA₁是RA₂的上层属性，表示为

权限继承规则当若State_i|＝(SA₁，RA，AA)^permit，则State_i|＝(SA₂，RA，AA)^permit；若State_i|＝(SA₁，RA，AA)^deny，则State_i|＝(SA₂，RA，AA)^deny。

正向权限和负向权限都可以沿主体属性层次路径向下层主体属性传播。例如SoftDeveloper角色属性可以继承来自Employee的任意正向权限(允许读系统说明文档)和负向权限(禁止写系统测试文档)

权限蕴含规则 当

若State_i|＝(SA，RA₁，AA)^permit，则不能推导出State_i|＝(SA，RA₂，AA)^permit；若State_i|＝(SA，RA₁，AA)^deny，则State_i|＝(SA，RA₂，AA)^deny。

正向访问动作不能沿资源属性层次路径向下蕴含，负向访问动作可以向下层资源属性蕴含。例如允许读资源″Code/″并不能推导出允许读资源″Code/JavaCode″也成立，禁止写资源″Code/″可以推导出禁止写资源″Code/JavaCode″。

4)规则状态相关性定义

策略分析时需要比较规则间关系，将其转化为规则状态比较，有助于分析规则间可能存在的判定冲突。假设Rule_i和Rule_j的规则状态分别为

和

下面分别给出状态覆盖、状态相交和状态无关的定义。

状态覆盖 存在关系

则称State_j覆盖State_i，表示为 ${\mathrm{State}}_i<{\mathrm{State}}_j.$

在 ${\mathrm{State}}_i<{\mathrm{State}}_j$ 的情况下，规则Rule_i目标元素中定义的各种属性类型和属性取值范围或者包含在Rule_j中(表示为： ${\mathrm{sub}}_{i_n}\&Element;\underset{j=1}{\overset{m_1}{\&cup;}}{\mathrm{sub}}_{j_m},{\mathrm{res}}_{i_n}\&Element;\underset{j=1}{\overset{m_2}{\&cup;}}{\mathrm{res}}_{j_m}$ 等)，或者存在

和

的情况。当

时，下层主体属性

继承上层主体属性的访问权限，从权限包含的角度可以归为State_j覆盖State_i。当

时，将上层属性

理解为下层属性

的祖先节点，从资源划分的角度可以归为State_j覆盖State_i。

目标元素Target_i和Target_j如果存在部分重合，则两条规则可能在某些情况下适用于同一请求。根据目标元素的结构，会存在不同层次和粒度的重合相交关系：可能是某个属性分量的取值范围存在交集，也可能是属性分量组合的取值范围存在交集。

状态相交 存在关系

且Statej和Statei间不存在覆盖关系，则称Statej和Statei状态相交，表示为 ${\mathrm{State}}_i\frac{\&LeftRightArrow;}{\mathrm{granularity}}{\mathrm{State}}_j.$

granularity表示状态相交的粒度，例如Rule_i的主体属性为sub_i{role[developer，tester]，group[internal，external]∧service age[3～5]}，Rule_j为sub_j{role[developer，designer]，group[internal]∧service-age[2～4]}，则granularity表示为(sub.role，sub.group∧sub.service-age)。前者表示针对role属性存在交集(role.developer)，后者针对group属性和sevice-age属性组合存在交集(group.interneal∧service-age[3～4])。资源属性和动作属性等类似表示。

状态无关 存在关系

，则称State_j和State_i状态无关，表示为State_i⊥State_j。

如果两条规则间的各种属性分量集合以及具有相同属性名称的属性分量的取值范围完全不同，则认为两规则状态间状态无关。

4)属性层次操作关联类型分析

属性层次导致的权限继承和权限蕴含是XACML策略冲突的主要原因之一。例如manager角色的权限策略中包含规则状态

developer角色的权限策略中包含规则状态manager自身权限和继承自developer的权限发生冲突；规则状态

和

针对下层资源“code/java code”发生冲突。当比较两条具体的访问规则时，可以把存在直接或间接层次关系的属性关系归纳为二元关系。规则间属性层次的基本操作关联比较如图3(i)所示(设定动作属性相同，暂不考虑环境属性)：主体属性层次关系中SA₁表示上层属性，SA₂表示下层属性，SA₂继承来自SA₁的权限；资源属性层次关系中RA₁表示上层粗粒度资源，RA₂表示下层细粒度资源，RA₁对应的负向权限可蕴含至RA₂。(a)～(d)描述了两条规则的属性定义既存在主体属性层次也存在资源属性层次的情况，此时主体和资源的层次关联存在两种可能：交叉(同一规则内定义的主体属性和资源属性相对另一规则位于不同层次)和同级(同一规则内定义的主体属性和资源属性相对另一规则位于相同层次)，考虑effect的两种结果，组合在一起为四种类型；(e)～(f)描述了只存在资源属性层次的情况，此时两条规则定义了相同的主体属性，根据不同的effect结果分为两种类型；(g)～(h)描述了只存在主体属性层次的情况，此时两条规则定义了相同的资源属性，根据不同的effect结果分为两种类型。以上类型都是规则间属性层次操作关联的原子类型，囊括了属性层次导致的各种规则冲突原因，其它由属性层次引起的更复杂冲突场景都是这些原子类型的组合类型。

若Rule₁的规则状态State₁和Rule₂的规则状态State₂针对共同适用的访问请求存在判定冲突，表示为

要说明的是，并不是所有的原子类型都导致实际的规则冲突，下面是各种属性层次关联的原子类型冲突判定的形式化推导

(a)State₁|＝(SA₁，RA₂，AA)^Deny，State₂|＝(SA₂，RA₁，AA)^Permit

$\left\{\begin{array}{c}{\mathrm{State}}_1|={({\mathrm{SA}}_1,{\mathrm{RA}}_2,\mathrm{AA})}^{\mathrm{Deny}}\&DoubleRightArrow;{\mathrm{State}}_1|={({\mathrm{SA}}_2,{\mathrm{RA}}_2,\mathrm{AA})}^{\mathrm{Deny}}\\ {\mathrm{State}}_2|={({\mathrm{SA}}_2,{\mathrm{RA}}_1,\mathrm{AA})}^{\mathrm{Permit}}\&NotEqual;>{\mathrm{State}}_2|={({\mathrm{SA}}_2,{\mathrm{RA}}_2,\mathrm{AA})}^{\mathrm{Permit}}\end{array}\right\}\&NotEqual;>{\mathrm{conflict}}_{{\mathrm{State}}_2}^{{\mathrm{State}}_1}$

(b)State₁|＝(SA₁，RA₂，AA)^Permit，State₂|＝(SA₂，RA₁，AA)^Deny

$\left\{\begin{array}{c}{\mathrm{State}}_1|={({\mathrm{SA}}_1,{\mathrm{RA}}_2,\mathrm{AA})}^{\mathrm{Permit}}\&DoubleRightArrow;{\mathrm{State}}_1|={({\mathrm{SA}}_2,{\mathrm{RA}}_2,\mathrm{AA})}^{\mathrm{Permit}}\\ {\mathrm{State}}_2|={({\mathrm{SA}}_2,{\mathrm{RA}}_1,\mathrm{AA})}^{\mathrm{Deny}}\&DoubleRightArrow;{\mathrm{State}}_2|={({\mathrm{SA}}_2,{\mathrm{RA}}_2,\mathrm{AA})}^{\mathrm{Deny}}\end{array}\right\}\&DoubleRightArrow;{\mathrm{conflict}}_{{\mathrm{State}}_2}^{{\mathrm{State}}_1}$

(c)State₁|＝(SA₁，RA₁，AA)^Permit，State₂|＝(SA₂，RA₂，AA)^Deny

$\left\{\begin{array}{c}{\mathrm{State}}_1|={({\mathrm{SA}}_1,{\mathrm{RA}}_1,\mathrm{AA})}^{\mathrm{Permit}}\&DoubleRightArrow;{\mathrm{State}}_1|={({\mathrm{SA}}_2,{\mathrm{RA}}_1,\mathrm{AA})}^{\mathrm{Permit}}\&NotEqual;>{\mathrm{State}}_1|{=({\mathrm{SA}}_2,{\mathrm{RA}}_2,\mathrm{AA})}^{\mathrm{Permit}}\\ {\mathrm{State}}_2|={({\mathrm{SA}}_2,{\mathrm{RA}}_2,\mathrm{AA})}^{\mathrm{Deny}}\&DoubleRightArrow;{\mathrm{State}}_2|={({\mathrm{SA}}_2,{\mathrm{RA}}_2,\mathrm{AA})}^{\mathrm{Deny}}\end{array}\right\}\&NotEqual;>{\mathrm{conflict}}_{{\mathrm{State}}_2}^{{\mathrm{State}}_1}$

(d)State₁|＝(SA₁，RA₁，AA)^Deny，State₂|＝(SA₂，RA₂，AA)^Permit

$\left\{\begin{array}{c}{\mathrm{State}}_1|={({\mathrm{SA}}_1,{\mathrm{RA}}_1,\mathrm{AA})}^{\mathrm{Deny}}\&DoubleRightArrow;{\mathrm{State}}_1|={({\mathrm{SA}}_2,{\mathrm{RA}}_1,\mathrm{AA})}^{\mathrm{Deny}}\&DoubleRightArrow;{\mathrm{State}}_1|{=({\mathrm{SA}}_2,{\mathrm{RA}}_2,\mathrm{AA})}^{\mathrm{Deny}}\\ {\mathrm{State}}_2|={({\mathrm{SA}}_2,{\mathrm{RA}}_2,\mathrm{AA})}^{\mathrm{Permit}}\&DoubleRightArrow;{\mathrm{State}}_2|={({\mathrm{SA}}_2,{\mathrm{RA}}_2,\mathrm{AA})}^{\mathrm{Permit}}\end{array}\right\}\&DoubleRightArrow;{\mathrm{conflict}}_{{\mathrm{State}}_2}^{{\mathrm{State}}_1}$

(e)State₁|＝(SA，RA₁，AA)^Permit，State₂|＝(Sa，RA₂，AA)^Deny

$\left\{\begin{array}{c}{\mathrm{State}}_1|={(\mathrm{SA},{\mathrm{RA}}_1,\mathrm{AA})}^{\mathrm{Permit}}\&NotEqual;>{\mathrm{State}}_1|={(\mathrm{SA},{\mathrm{RA}}_2,\mathrm{AA})}^{\mathrm{Permit}}\\ {\mathrm{State}}_2|={(\mathrm{SA},{\mathrm{RA}}_2,\mathrm{AA})}^{\mathrm{Deny}}\&DoubleRightArrow;{\mathrm{State}}_2|={(\mathrm{SA},{\mathrm{RA}}_2,\mathrm{AA})}^{\mathrm{Deny}}\end{array}\right\}\&NotEqual;>{\mathrm{conflict}}_{{\mathrm{State}}_2}^{{\mathrm{State}}_1}$

(f)State₁|＝(Sa，RA₁，AA)^Deny，State₂|＝(SA，RA₂，AA)^Permit

$\left\{\begin{array}{c}{\mathrm{State}}_1|={(\mathrm{SA},{\mathrm{RA}}_1,\mathrm{AA})}^{\mathrm{Deny}}\&DoubleRightArrow;{\mathrm{State}}_1|={(\mathrm{SA},{\mathrm{RA}}_2,\mathrm{AA})}^{\mathrm{Deny}}\\ {\mathrm{State}}_2|={(\mathrm{SA},{\mathrm{RA}}_2,\mathrm{AA})}^{\mathrm{Permit}}\&DoubleRightArrow;{\mathrm{State}}_2|={(\mathrm{SA},{\mathrm{RA}}_2,\mathrm{AA})}^{\mathrm{Permit}}\end{array}\right\}\&DoubleRightArrow;{\mathrm{conflict}}_{{\mathrm{State}}_2}^{{\mathrm{State}}_1}$

(g)State₁|＝(SA₁，RA，AA)^Permit，State₂|＝(SA₂，RA，AA)^Deny

$\left\{\begin{array}{c}{\mathrm{State}}_1|={({\mathrm{SA}}_1,\mathrm{RA},\mathrm{AA})}^{\mathrm{Permit}}\&DoubleRightArrow;{\mathrm{State}}_1|={({\mathrm{SA}}_2,\mathrm{RA},\mathrm{AA})}^{\mathrm{Permit}}\\ {\mathrm{State}}_2|={({\mathrm{SA}}_2,\mathrm{RA},\mathrm{AA})}^{\mathrm{Deny}}\&DoubleRightArrow;{\mathrm{State}}_2|={({\mathrm{SA}}_2,\mathrm{RA},\mathrm{AA})}^{\mathrm{Deny}}\end{array}\right\}\&DoubleRightArrow;{\mathrm{conflict}}_{{\mathrm{State}}_2}^{{\mathrm{State}}_1}$

(h)State₁|＝(SA₁，RA，AA)^Deny，State₂|＝(SA₂，RA，AA)^Permit

$\left\{\begin{array}{c}{\mathrm{State}}_1|={({\mathrm{SA}}_1,\mathrm{RA},\mathrm{AA})}^{\mathrm{Deny}}\&DoubleRightArrow;{\mathrm{State}}_1|={({\mathrm{SA}}_2,\mathrm{RA},\mathrm{AA})}^{\mathrm{Deny}}\\ {\mathrm{State}}_2|={({\mathrm{SA}}_2,\mathrm{RA},\mathrm{AA})}^{\mathrm{Permit}}\&DoubleRightArrow;{\mathrm{State}}_2|={({\mathrm{SA}}_2,\mathrm{RA},\mathrm{AA})}^{\mathrm{Permit}}\end{array}\right\}\&DoubleRightArrow;{\mathrm{conflict}}_{{\mathrm{State}}_2}^{{\mathrm{State}}_1}$

对上述各种类型进行归纳，可以看出引起规则冲突主要有以下几种原因：(1)继承自上层主体属性的正向权限和自身负向权限对下层资源属性的蕴含冲突，(b)属于这种情况；(2)继承自上层主体属性的负向权限对下层资源属性的蕴含与自身正向权限冲突，(d)属于这种情况；(3)自身负向权限对下层资源属性的蕴含和自身正向权限冲突，(f)属于这种情况；(4)相同资源属性节点下，主体自身负向权限和继承自上层主体属性的正向权限冲突，(g)属于这种情况；(5)相同资源属性节点下，主体自身正向权限和继承自上层主体属性的负向权限冲突，(h)属于这种情况。类型(a)(c)(e)不会引起规则冲突。

第二部分规则冲突检测：

1)建立基于资源语义树的策略索引结构

无论是策略静态分析还是PDP根据请求进行策略评估，有效的索引结构可以缩减用户检索的策略空间规模，避免对策略库的遍历式匹配。大规模资源共享系统中的资源标识通常具有语义层次结构，例如URI统一资源标识符、XML节点等，类似具有层次关系的资源属性可以使用语义树表示。虽然XACML策略采用多属性类型匹配的模式，但访问控制策略的特性决定了资源属性匹配与否是策略匹配与否的必要条件，资源属性和策略间存在优先匹配关系。如果能利用资源语义树中的属性节点将安全策略和其针对的资源进行有效关联，可实现符合资源自然语义的策略索引结构，带来可预期的策略分析与判定的效率提升。

一条XACML策略会涉及多个资源属性节点，同一资源属性也可能在多条策略中定义，图2是一个已建立策略索引的语义树示例。建立策略索引之前，为系统提供完整的资源语义树，并且语义树的每个节点都建立一个策略标识符列表。语义树中的节点可以转换为策略中resource属性值标识，其对应列表中存放涉及该资源属性的所有策略标识符，标识符条目指向实际的访问控制策略。可以将策略内部的permit和deny类型规则分类存储，以提高分析检测效率。设定语义树的资源节点集为N，策略库中policySet和policy的条目集合为M，条目i中定义的资源属性条目集合表示为R_i，这些条目来自policy或policyset自身的Target。R_i中包含的资源属性条目可能重复但都属于集合N。最耗时情况下，策略条目i需要进行Θ(|N|)次添加索引操作，整个策略库进行Θ(|M|×|N|)次添加索引操作。基于资源语义树的策略索引结构有利于请求评估和策略分析时快速定位适用策略集合，资源属性的分层化索引有助于分析属性层次导致的策略冲突影响。

2)基于属性层次操作关联的冲突检测

XACML策略中的主体属性层次和权限策略继承关系可采用类似图1的形式描述，基于语义树构建的策略索引决定了存在资源层次关系的规则必定包含在相邻节点或存在祖先关系节点的策略列表中。针对已经分析的多种冲突类型，根据XACML继承策略描述方式和基于资源语义树的策略索引结构给出基于属性层次操作关联的冲突检测步骤方法，并以算法方式提供。检测方法首先要定位下层主体属性策略和其引用继承的上层主体属性策略，然后根据effect类型分别进行比较。针对permit类型规则，不仅要分析自身资源属性节点对应的deny类型规则，还要检测其祖先节点对应的继承策略，发现继承策略中deny类型规则沿资源层次蕴含到下层资源所可能引发的冲突。针对deny类型规则，不仅要分析自身资源属性节点对应的permit类型规则，还要检测其孩子节点对应的继承策略，发现自身策略中deny类型规则沿资源层次蕴含到下层资源所可能引发的冲突。

3)基于状态相关性的其他类型冲突检测

除了属性层次操作关联导致规则冲突外，不存在继承关系的任意策略间由于规则状态性也会导致冲突。例如

和

存在 ${\mathrm{State}}_i<{\mathrm{State}}_j,$ 同时满足两个状态空间的访问请求会导致规则冲突。再如

和

存在 ${\mathrm{State}}_i\frac{\&LeftRightArrow;}{(\mathrm{sub},\mathrm{role},\mathrm{res},\mathrm{type},\mathrm{ac},\mathrm{en}.\mathrm{time})}{\mathrm{State}}_j,$ 请求req(role.developer，type.code，read)在时间段[11am，2pm]同时满足两个状态空间会导致判定冲突。另外由于负向权限对下层资源权限蕴含，上层属性节点的规则和下层节点规则如果存在状态相交也可能导致冲突。

第三部分规则冗余分析，这一部分的分析可以在规则冲突检测之前或者之后：

根据前面状态覆盖的定义可以看出，如果Rule_i和Rule_j存在 ${\mathrm{State}}_{{\mathrm{Rule}}_i}<{\mathrm{State}}_{{\mathrm{Rule}}_j},$ 且Rule_j对Rule_i适用的访问请求进行评估都能给出明确的判定结果(permit或者deny)，那么在特定的评估结果合并算法下，Rule_i可能对访问请求的判定不产生实际影响，将这类规则判定为冗余规则。冗余规则的判定和策略或策略集所选定的消解合并算法是密切相关的，相同规则在不同的合并算法下，其冗余判定结果可能不同。另外，冗余判定的过程遵照先策略内部后策略间的顺序。在策略内部被判定冗余的规则不再和其他策略中的规则进行冗余比较。策略内部根据规则合并算法进行冗余判定；策略间根据策略合并算法进行冗余判定。在进行冗余判定的过程中需按照下列定理进行判定。

定理1 若采用XACML标准中的允许优先合并算法，Rule_i的effect为任意类型，Rule_j的effect为permit，存在 ${\mathrm{State}}_{{\mathrm{Rule}}_i}<{\mathrm{State}}_{{\mathrm{Rule}}_j},$ 且不存在

则Rule_i是冗余规则。

定理2 若采用XACML标准中的否定优先合并算法，Rule_i的effect为任意类型，Rule_j的effect为deny，存在 ${\mathrm{State}}_{{\mathrm{Rule}}_i}<{\mathrm{State}}_{{\mathrm{Rule}}_j},$ 则Rule_i是冗余规则。

定理3 若采用XACML标准中的首次适用合并算法，seq(Rule_j)＜seq(Rule_i)，存在 ${\mathrm{State}}_{{\mathrm{Rule}}_i}<{\mathrm{State}}_{{\mathrm{Rule}}_j}.$ 若Rule_j.effect＝deny，则Rule_i是冗余规则；若Rule_j.effect＝permit且不存在

则Rule_i是冗余规则。

本发明从管理视图角度分析造成冲突的细节原因以及冲突预测验证能力。策略管理者通过本发明的方法可以准确定位引发冲突的规则以及引发冲突的原因；冗余分析方面，提供了不同评估合并算法下规则冗余分析判定方法，判定评估系统可以根据分析结果优化策略结构，删除不影响访问判定结果的冗余规则，提高策略判定效率。

附图说明

图1XACML中的权限继承示意图

图2基于资源语义树的XACML策略索引示意图

图3主体层次和资源层次操作关联类型分析图

图4基于属性层次操作关联的冲突检测算法示意图

图5基于状态相关的其他类型冲突检测算法示意图

图6规则冗余判定策略集实例图

具体实施方式

图4描述了基于属性层次操作关联的冲突检测算法。该算法输入包括需检测的主体属性策略pol和其引用继承的上层主体属性的权限策略列表，输出是由若干冲突规则对pair(rule_p，rule_d)组成的集合conSet。算法具体过程如下。针对pol中的permit类型规则rule_p，确定rule_p中资源属性resAttr_p在语义树上的节点Node_res，对Node_res自身策略标识列表中的每个策略pol_Δ进行检测。逐一分析pol_Δ中的deny类型规则rule_d，若rule_p和rule_d状态相关性为

则pair(rule_p，rule_d)属于上节分析的第(5)种类型，将其加入conSet。调用递归函数Traverse-up-checking(Node_res)处理Node_res上层节点的负向权限蕴含可能引发的规则冲突。Traverse-up-checking函数检索Node_res父节点权限策略列表中的每个策略：若策略pol包含在其中并判定

为真，则说明策略pol对Node_res的负向权限蕴含与自身对Node_res的正向权限发生冲突，属于第(3)种类型；若其中存在某策略pol_Δ∈rePoList并判定若

为真，则说明引用策略pol_Δ对Node_res的负向权限蕴含与pol对Node_res的正向权限发生冲突，属于第(2)种类型。将上述产生的规则冲突对加入conSet中。若Node_res的父节点Node_res.parent不是语义树的根节点，则继续调用Traverse-up-checking(Node_res.parent)。针对pol中deny类型规则rule_d，根据第(5)种类型冲突的检测方法步骤可以发现第(4)种类型冲突。rule_d对下层节点的负向权限蕴含与引用策略对下层节点的正向权限可能引发第(1)种类型冲突，需要调用递归函数Traverse-down-checking(Node_res)处理此类冲突。此函数目的是遍历Node_res及其子节点，检测策略标识列表中的引用策略是否存在rule_p，

判定为真。若存在，将pair(rule_p，rule_d)加入conSet。至此，算法对上文分析的5种冲突类型检测完毕，返回conSet。具体算法如下：

基于属性层次操作关联的冲突检测算法

输入：pol//某主体属性的权限策略

      rePoList//pol直接引用或间接引用的上层主体属性权限策略列表

输出：conSet//冲突规则对pair(rule_p，rule_d)组成的集合

begin

for eachrule_p∈pol

 for each resAttr_p∈rule_p.res

 {

 get the Node_res of resAttr_p

 for each pol_Δ∈policyList of Node_res

  if pol_Δ∈rePoList

   for edch rule_d∈pol_Δ

    if

//第(5)种类型

      add pair(rule_p，rule_d)to conSet

 traverse-up-checking(Node_res)

 {

  for each pol_Δ∈policyList of Node_res.parent

   if pol_Δ＝＝pol

     for each rule_d∈pol

      if

       //第(3)种类型

       add pair(rule_p，rule_d)to conSet

    else if pol_Δ∈rePoList

     for each rule_d ∈pol_Δ

      if

       //第(2)种类型

       add pair(rule_p，rule_d)to conSet

   if Node_res.parent isn′t root-node

     traverse-up-checking(Node_res.parent)

  }

 }

for each rule_d∈pol

 for each resAttr_d∈rule_d.res

 {

  get the node Node_res of resAttr_d

  for each pol_Δ∈policyList of Node_res

   if pol_Δ∈rePoList

    for each rule_p∈pol_Δ

     if

//第(4)种类型

        add pair(rule_p，rule_d)to conSet

  traverse-down-checking(Node_res)

  {

   for each node_child∈Node_res.child

    for each pol_Δ∈policyList of Node_res

     if pol_Δ∈rePoList

      for each rule_p∈pol_Δ

       if//第(1)种类型

        add pair(rule_p，rule_d)to conSet

    if node_child isn′t leaf-node

     for each N ∈node_child.child

      traverse-down-checking(N)

  }

 }

returnconSet

end

图5描述了基于状态相关的其他类型冲突检测算法，算法输入为要检测的资源属性节点node，输出是冲突规则对集合conSet和冲突威胁规则对集合p-conSet。算法具体过程如下。获取node的策略标识列表并检测其中每个策略包含的permit类型规则rule_p。若rule_p中存在资源属性对应节点node，运行递归函数Traverse-up-checking(node)。函数将遍历node的父节点和祖先节点，目的是检测节点对应的策略标识列表，针对其中任意策略pol_Δ当rule_d∈pol_Δ且

为真时，rule_p和rule_d的状态向量空间存在属性分量的交集，将pair(rule_p，rule_d)加入conSet。若

为真，将pair(rule_p，rule_d)加入p-conSet。此类冲突是否发生依赖访问上下文信息，虽然规则的主体属性不存在交集，但用户实际访问时拥有的主体属性可能同时满足两个规则从而引起访问权限冲突，因此将pair(rule_p，rule_d)定义为冲突威胁规则对。

基于状态相关的其他类型冲突检测算法

输入：node //要检测的资源属性节点

输出：conSet  //冲突规则pair(rule_p，rule_d)组成的集合

      p-conSet //冲突威胁规则对pair(rule_p，rule_d)组成的集合

begin

get policyList of node

for each pol∈policyList

{

 for each rule_p∈pol

  if

resAttr∈rule_p.res:resAttr map node

    traverse-up-checking(node)

    {

      get policyList_Δ of node

      for each pol_Δ∈policyList_Δ

       for each rule_d∈pol_Δ

         if

           add pair(rule_p，rule_d)to conSet

         else if

           add pair(rule_p，rule_d)to p-conSet

       if node isn′t root-node

            traverse-up-checking(node.parent)

        }

}

return conSet and p-conSet

end

图6是一个策略集，通过这个实例说明规则冗余判定实施过程。策略集PS采用first-applicable策略合并算法，它包含3条策略元素P1、P2和P3。P1包含规则R1、R2和R3，采用permit-override规则合并算法；P2包含规则R4和R5，采用first-applicable规则合并算法；P3包含规则R6和R7，并采用deny-override规则合并算法。对这个系统进行策略内规则冗余判定和策略间规则冗余判定。策略P1中 ${\mathrm{State}}_{R2}<{\mathrm{State}}_{R3},$ 又因为R3的effect类型为permit且P1采用允许优先合并算法，所以可推出规则R2冗余。需要注意的是，虽然R1和R3之间也存在关系 ${\mathrm{State}}_{R2}<{\mathrm{State}}_{R3},$ 但因为正向permit权限不会沿资源属性路径向下层资源传播，所以规则R3针对访问请求(admin-root/doc，write)并不能给出明确的判定结果。同理可推出策略P2中规则R5冗余。策略P3中R6和R7存在关系 ${\mathrm{State}}_{R7}<{\mathrm{State}}_{R6},$ 并且R6的effect类型为deny，可以沿资源属性路径向下层传播，其针对访问请求(project-root/code，write)给出判定结果deny，所以可推出R7是冗余规则。完成策略内规则冗余分析后，需要进一步对策略间规则冗余进行分析。对于已经在策略内部被判定冗余的策略不再进行策略间的规则比较，例如比较策略P1和P2内的规则，只需要分别对(R1，R4)和(R3，R4)进行比较。可以看出因为 ${\mathrm{State}}_{R6}<{\mathrm{State}}_{R4}$ 且策略集PS采用首次适用策略合并算法，所以推出R6是冗余规则。下表是该策略集的冗余判定结果

Claims (6)

1、一种XACML策略规则检测方法，用于分析规则冲突，其步骤包括：

1)构建XACML策略规则分析的形式化模型，根据XACML描述属性的结构和特征，定义规则状态及规则状态满足，规则状态表示为

其中：

sub_i、res_i、ac_i和en_i分别代表Rule中一个主体、资源、动作和环境属性分量，每个分量包括使断言合取式

为真的一组属性值，其中断言match_j是作用在属性值上的布尔函数，

分别表示各种属性分量的并集，Decision表示Rule的effect类型；规则状态满足，若规则Rule_i声明主体SA在环境状态为EA时，可以对资源RA进行访问动作AA，则属性状态向量(SA，RA，AA，EA)满足规则状态State_i，表示为State_i|＝(SA，RA，AA，EA)^effect；

2)制定XACML中的权限继承和权限蕴含规则，所述权限继承规则为正向权限和负向权限都可以沿主体属性层次路径向下层主体属性传播；所述权限蕴含规则为正向访问动作不能沿资源属性层次路径向下蕴含，负向访问动作可以向下层资源属性蕴含；

3)定义XACML中规则状态的关系，分为状态覆盖、状态相交或是状态无关，规则目标元素中定义的各种属性类型和属性取值范围包含在另一规则状态中，规则状态为覆盖；规则目标元素某个属性分量或属性分量组合的取值范围存在交集，规则状态为相交；两条规则间的各种属性分量集合以及具有相同属性名称的属性分量的取值范围完全不同，规则状态为无关；

4)通过描述属性层次操作关联类型，分析属性层次引起的规则间冲突类型，类型包括：

(1)继承自上层主体属性的正向权限和自身负向权限对下层资源属性的蕴含冲突；

(2)继承自上层主体属性的负向权限对下层资源属性的蕴含与自身正向权限冲突；

(3)自身负向权限对下层资源属性的蕴含和自身正向权限冲突；

(4)相同资源属性节点下，主体自身负向权限和继承自上层主体属性的正向权限冲突；

(5)相同资源属性节点下，主体自身正向权限和继承自上层主体属性的负向权限冲突；

5)建立基于资源语义树的策略索引结构，具体是为系统提供完整的资源语义树，并且语义树的每个节点都建立一个策略标识符列表，语义树中的节点可以转换为策略中属性值标识，其对应列表中存放涉及该资源属性的所有策略标识符，标识符条目指向实际的访问控制策略；

6)运行基于属性层次操作关联的冲突检测算法，算法输入包括需检测的主体属性策略和其引用继承的上层主体属性的权限策略列表，检测步骤4)中分析的规则间冲突类型，输出是由若干冲突规则对组成的集合；

7)运行基于状态相关的其他类型冲突检测算法，算法输入包括要检测的资源属性节点，检测步骤3)中的规则状态相交产生的规则冲突情况，输出是冲突规则对集合和冲突威胁规则对集合。

2、如权利要求1所述的方法，其特征在于，所述步骤4)之后还包括进行规则冗余检测的步骤，具体为：

a)建立策略集，包含若干策略，每条策略包含若干规则；

b)根据冗余分析定理，进行策略内部规则冗余判断，标记冗余规则；

c)根据冗余分析定理，进行策略之间的规则冗余判断，标记冗余规则，已被标记的规则不再和其他策略中的规则进行冗余判断。

3、如权利要求1所述的方法，其特征在于，所述步骤5)中语义树中的节点可以转换为策略中资源属性值标识，其对应列表中存放涉及该资源属性的所有策略标识符，标识符条目指向实际的访问控制策略。

4、如权利要求1所述的方法，其特征在于，所述步骤6)检测时根据规则类型分别进行比较：

针对permit类型规则，不仅要分析自身资源属性节点对应的继承策略中deny类型规则，还要检测资源上层节点对应的继承策略，发现继承策略中的deny类型规则沿资源层次蕴含到下层资源所可能引发的冲突；

针对deny类型规则，不仅要分析自身资源属性节点对应的继承策略中permit类型规则，还要检测资源下层节点对应的继承策略，发现自身策略中deny类型规则沿资源层次蕴含到下层资源所可能引发的冲突。

5、如权利要求1所述的方法，其特征在于，所述步骤7)冲突威胁规则对是用户实际访问时拥有的主体属性可能同时满足两个规则从而引起访问权限冲突。

6、如权利要求2所述的方法，其特征在于，进行规则冗余检测时根据XACML标准中的允许优先合并算法、否定优先合并算法和首先适用合并算法，策略内部和策略之间分别采用相应的规则冗余分析定理进行冗余判断。

Images