薄 阳 夏春和,3
1(网络技术北京市重点实验室(北京航空航天大学) 北京 100191) 2(北京航空航天大学计算机学院 北京 100191) 3(广西师范大学计算机科学与信息工程学院 广西桂林 510004) (cseby@buaa.edu.cn)
2017-06-05;
2017-07-29
国家自然科学基金联合基金项目(U1636208);中航工业产学研项目(CXY2011BH07) This work was supported by the Joint Funds of National Natural Science Foundation of China (U1636208) and the Special Project on the Integration of Industry, Education and Research of the Aviation Industry Corporation of China (CXY2011BH07).
业务流程授权约束依从性分析
薄 阳1,2夏春和1,2,3
1(网络技术北京市重点实验室(北京航空航天大学) 北京 100191)2(北京航空航天大学计算机学院 北京 100191)3(广西师范大学计算机科学与信息工程学院 广西桂林 510004) (cseby@buaa.edu.cn)
授权约束的依从性研究是业务流程安全领域中的重要研究内容.针对授权约束提出了全新的业务流程依从性分析框架,该框架可以处理:1)流程授权和非流程授权;2)业务流程任务委托;3)角色继承关系;4)职责分离和职责绑定约束;5)静态约束和动态约束.提出授权图表示依从性分析框架,并给出授权图的构造和化简方法对授权图进行维护,然后设计了针对授权图的依从性分析算法.基于分析结果,给出了不依从授权约束的冲突模式,针对每一种冲突模式设计一组解决方案,并实现了原型系统.所提出的授权约束依从性分析框架独立于系统部署的平台,适用范围广泛.最后通过实例分析和实验验证说明了该方法的有效性.
业务流程;授权约束;依从性;职责分离;职责绑定;任务委托
业务流程是指为特定用户提供特定服务或者产品的一组相关的结构化的任务.为了保证这些服务和产品是用户所需要的,业务流程经常要依从于业务规则和策略,这些业务规则和策略被称之为依从性要求[1].本文主要关注依从性要求中的一类:授权约束[2-4].为了避免业务流程中权限滥用、误用和欺骗等情况的发生,从而会对组织机构造成损害,授权约束规定业务流程中的任务必须由系统指定的角色和用户来完成.业务流程授权约束依从性分析是判断业务流程中用户、角色和任务获取的权限是否依从于授权约束规定的过程.
业务流程生命周期包括流程设计和流程执行阶段.在流程设计阶段,流程专家对业务过程建模,并指定可以执行任务的角色以及完成任务需要的权限;在流程执行阶段,业务管理员为每个任务分配一个候选用户.由于系统当前状态和候选用户分配策略的不同,对于相同的业务流程模型经常可以得到不同的任务分配.因此,业务流程中授权约束的依从性分析既要分析业务流程模型的依从性,还要分析任务分配的依从性.同时,为了确保以用户为中心的业务管理并支持跨组织的协作[5],业务流程中候选用户经常需要将分配给他的任务委托给其他用户去执行,即任务委托.任务委托为用户获取权限提供了隐蔽通道.在依从性分析过程中必须予以考虑.
在业务流程环境中,为了满足企业的访问控制灵活多变以及主动和被动访问并存的需求,基于任务-角色的访问控制模型(task-role based access control, TRBAC)[6]得到了大量关注和应用.在TRBAC中,角色不会直接获取权限而是通过其分配的任务获取相应的权限.为了能够支持主动和被动2种访问需求,TRBAC中将任务进行了分类,简单来说分为流程任务和非流程任务.非流程任务是角色固有的任务,通过非流程任务获取的权限是被动权限;而流程任务是在业务流程生命周期分配给角色去执行的任务,是随着时间的变化而变化的,用户通过流程任务而获取的权限是主动权限.由于用户可能通过上述2种途径获取权限,因此,基于TRBAC的授权约束依从性分析除了考虑用户通过流程中的任务获取的动态权限,还需要考虑用户通过非流程任务获取的固有权限.
目前研究集中于主动访问或者被动访问的授权约束分析,为了能够分析TRBAC中主动访问和被动访问相结合的访问方式的依从性,本文提出了一种全新的依从性分析框架,该框架具有4个特点:
1) 该框架充分考虑了用户获取权限的3种途径和2种方式,用户获取权限的3种途分别为通过角色和任务获取权限、通过角色继承关系获取权限以及通过委托机制获取权限,用户获取权限的2种方式为主动获取和被动获取;
2) 提出授权图描述所提出的授权约束依从性分析框架,授权图易于构造和维护,授权图的依从性分析可以转换为对有向图的操作,提高了分析效率;
3) 提出的框架能够在业务流程设计和业务流程执行过程中发现违反授权约束的冲突,并且给出冲突模式和解决方案,为权限再次分配调整提供了依据;
4) 提出的授权约束依从性分析框架既考虑了业务流程环境中访问控制的特点,又考虑了业务流程执行过程中委托机制带来的权限变化情况,并独立于系统部署平台,具有广泛的适用范围.
1.1授权约束
在业务流程管理系统中,授权约束作为保证流程完整性以及差错控制和欺骗预防的机制而存在.为了避免业务流程中权限滥用、误用和欺骗等情况的发生,从而对组织机构造成损害,授权约束规定业务流程中的任务必须由系统指定的角色和用户来完成.授权约束是基于具有约束关系的实体而制定的[7].本文认为在TRBAC中这种具有约束关系的实体是权限.换言之,用户通过角色和任务等最终获取了对目标资源操作的权限是授权约束针对的对象,也是产生安全威胁的根本.典型的授权约束包括职责分离约束(separation of duty, SoD)和职责绑定约束(binding of duty, BoD).简单来讲,职责分离约束是指2个权限不能够分配给同一个用户;而职责绑定约束是指2个权限必须分配给同一个用户.职责分离约束反映了责任和权力必须分配给不同用户的需求[8],而职责绑定约束反映了机密数据只能够由少数人访问的需求.我们称具有职责分离关系的2个权限为互斥权限,具有职责绑定关系的2个权限为绑定权限.
职责分离约束和职责绑定约束在业务流程的设计阶段和运行阶段具有不同的含义.在设计阶段,职责分离约束是防止互斥权限分配给相同的任务、角色和用户.而职责绑定约束是指绑定权限能够分配给相同的任务、角色和用户.在运行阶段,职责分离约束是防止在一个流程实例中互斥权限被分配给同一个用户,而职责绑定约束是指绑定权限必须成对分配给同一个用户.
1.2TRBAC
不同于RBAC,在TRBAC中,用户通过角色获取任务的执行权限,通过任务获取资源的操作权限,文献[6]给出了TRBAC的基本结构,如图1所示:
Fig. 1 TRBAC model图1 基于任务角色的访问控制模型
容易理解,TRBAC中实体“任务”是区别于RBAC的关键.任务不仅仅是“子角色”,还有独有的含义和特点.根据是否属于业务流程还是不属于业务流程可以将任务分为流程任务和非流程任务.根据组织机构的结构和授权的继承关系可以分为可继承任务和不可继承任务.因此,结合上述2种分类方式可以将任务分为4种类型:不可继承非流程任务(P)、可继承非流程任务(S)、不可继承流程任务(W)和可继承流程任务(A).子角色能够通过继承关系获取可继承任务的执行权限,而不可继承任务的执行权限不能够被继承.非流程任务的授权在业务流程设计和执行阶段是不变,而流程任务在设计阶段存在多个候选执行角色和用户,在执行阶段只存在一个执行用户.TRBAC深入考虑了企业环境的特点和访问控制的需求,更适用于真实情况.本文的研究是在TRBAC的基础上展开的.
1.3业务流程任务委托
委托是业务流程系统以及其他很多应用领域的重要概念[9-10].传统的委托是指允许用户将其权限的一部分分配给其他不具有这些权限用户的机制[11].发起委托的用户称为委托人,接受委托的用户称为被委托人.在业务流程环境中委托是指委托人能够授权被委托人执行业务流程中的任务[10].一般来讲,任务委托可以分为2类:授予(grant)和转移(transfer)[10,12].授予型委托是指委托成功实施后,委托人和被委托均具有任务的执行权限;而转移型委托是指委托成功实施后任务执行权限从委托人转移到被委托人.委托的本质是任务执行权限在用户之间复制和转移的过程.因此,任务委托提高了授权管理的灵活性.但是,由于用户发起任务委托以及被委托任务存在不确定性,对系统授权状态也带来了不确定的变化,容易引发潜在的安全问题.委托与授权约束之间固有的复杂性成为业务流程委托过程需要解决的重要问题[13].
授权约束的依从性是指用户通过访问控制策略和委托机制获取的权限是否依从于授权约束的规定.本文授权约束主要指职责分离约束和职责绑定约束.职责分离约束是指需要多名用户来完成一项工作[14].Ferraiolo将职责分离定义为:对于指定的业务集合,不允许同一个人执行该集合中的所有业务[15].Botha在业务流程环境中讨讨论职责分离,定义了可能的冲突、冲突用户、冲突角色、冲突任务和冲突权限等[16].在Botha的定义中,除了冲突用户表示的是具有某种社会关系(例如夫妻、父子等家庭关系)的用户以外,冲突角色、冲突任务都是由于角色和任务具有冲突权限而产生的.因此,本文认为冲突权限是授权约束中的基本约束.Wolter针对工作流模式讨论了授权约束,他认为职责绑定约束是指2个任务必须由同一个用户来执行,职责绑定约束反映了如机密数据只能被一小部分用户访问的需求[7].
本文沿用了Botha,Wolter等人的定义,并进一步将权限约束从约束双方的角度进行了划分,分为固有权限约束、固有权限与主动权限约束以及主动权限约束.业务流程包括设计阶段和执行阶段,相应的这2个阶段的主动权限可以分为静态主动权限和动态主动权限,具体地,在业务流程模型中用户能够获取的权限称为静态主动权限,在业务流程任务分配中用户能够获取的权限称为动态主动权限.由于静态主动权限和动态主动权限具有不同的特点,因此,在分析授权约束依从性时要分别处理.根据业务流程生命周期和获取权限的特点,我们将授权约束依从性分析框架划分为2个阶段,即业务流程模型依从性分析框架和任务分配依从性分析框架.
2.1业务流程模型依从性分析框架
业务流程模型依从性分析框架可以分析固有权限之间、固有权限和静态主动权限之间以及静态主动权限之间的约束.依从性分析框架是由约束(constraint)、任务(task)、组织(organization)、主动访问(active access)以及被动访问(passive access)等5部分构成.
约束是指权限以及权限之间的约束关系.权限指主体对客体的操作.约束关系包括职责分离关系、职责绑定关系.任务是一个基本工作单元,与权限相关联,任务具有权限后可以对目标资源进行操作.一个任务既可以是为了实现业务目标而设计(流程任务),也可以是为了实现系统的特定功能而设计(非流程任务).任务分为人工任务和非人工任务(更新数据库、自动发送邮件等).在业务流程中,一个人工任务分配给一个用户来完成[16].非人工任务不在本文研究范围之内.组织是指系统中的角色以及角色之间的继承关系.主动访问是指用户通过角色获取流程任务的执行权限.被动访问是指用户通过角色获取非流程任务的执行权限.
令P={permission}表示权限集合,T={task,taskType}表示任务集合,taskType∈{P,S,W,A},Tbp表示流程任务,Tnbp表示非流程任务,则T=Tbp∪Tnbp,且Tbp∩Tnbp=∅(如果存在既属于流程任务集合又属于非流程任务集合的任务,那么具有非流程任务执行权限的用户可以在流程生命周期的任何时刻来执行该任务,威胁流程正常执行).R={role}表示角色集合,Rbp表示主动角色,Rnbp表示被动角色,R=Rbp∪Rnbp,主动角色能够执行流程任务,而被动角色能够执行非流程任务.需要注意到是一个角色可以同时成为主动角色和被动角色.U={user}表示用户集合.我们将业务流程模型依从性分析框架(business process model compliance analysis framework,BPMCAF)记为
BPMCAF∷=(CONST,TASK,ORG,AA,PA),
CONST∷=(P,PPC)表示权限以及权限之间的约束关系.其中,P表示权限集合;PPC={p1,p2,constType},p1,p2∈P,constType∈{BoD,SoD}表示权限与权限之间的约束关系.
TASK∷=(T,P,TP)表示任务、权限以及任务和权限之间的分配关系.其中,T表示任务集合;P表示权限集合;TP={task,permission},task∈T,permission∈P表示权限与任务之间的分配关系.
ORG∷=(R,RR)表示系统中的角色以及角色之间的继承关系.其中,R表示角色集合;RR={r1,r2},r1,r2∈R,表示角色之间的继承关系,其中r1为父角色,r2为子角色.
AA∷=(Tbp,Rbp,Ubp,TRbp,URbp)表示流程任务、角色、用户及其分配关系.其中,Tbp∈T,表示流程任务集合;Rbp⊂R,表示与流程任务有关的角色集合;Ubp⊂U,表示与Rbp有关的用户集合;TRbp={task,role},task∈Tbp,role∈Rbp表示流程任务和角色之间的分配关系;URbp={user,role},user∈Ubp,role∈Rbp表示用户和角色之间的分配关系.
PA∷=(Tnbp,Rnbp,Unbp,TRnbp,URnbp)表示非流程任务、角色、用户及其分配关系.其中,Tnbp∈T,表示非流程任务集合;Rnbp属于R表示与非流程任务有关的角色集合;Unbp属于U表示与Rnbp有关的用户集合;TRnbp={task,role},task∈Tnbp,role∈Rnbp表示非流程任务和角色之间的分配关系;URnbp={user,role},user∈Unbp,role∈Rnbp表示用户和角色之间的分配关系.
2.2任务分配依从性分析框架
业务流程中的任务分配是指为流程中的每一个任务分配用户来执行的过程.我们把包含某流程中所有任务的任务分配称为该流程的一个分配计划,同一业务流程模型在不同时刻的分配计划可能不同,同一分配计划在执行过程中也可能动态变化,例如任务执行者由于用户生病、请假等一些原因不能执行分配计划中任务时需要其他用户来代替.任务委托是解决上述问题的一种机制.当用户不能执行分配计划中的任务时,如果该任务可以被委托,则该用户可将任务委托给其他用户去执行,从而保证业务流程顺利完成.任务分配依从性分析框架能够分析分配计划,以及分配计划与用户固有权限之间是否存在冲突,以及在发生任务委托的情况下是否存在上述2种冲突.
TACAF∷=(CONST,TASK,ORG,ASSIGN,PA,DELEG)
CONST∷=(Pi,PPCi)表示权限以及权限之间的约束关系.其中,PPCi={p1,p2,constType},p1,p2∈Pi,constType∈{SoD,BoD}表示权限与权限之间的约束关系;
TASK∷=(Ti∪Tnbp,Pi,TPi)表示任务、权限以及任务和权限之间的分配关系.其中,TPi={task,permission},task∈Ti∪Tnbp,permission∈Pi表示权限与任务之间的分配关系;
ORG∷=(R,RR)表示系统中的角色以及角色之间的继承关系.其中,R表示角色集合;RR={r1,r2},r1,r2∈R,表示角色之间的继承关系,其中r1为父角色,r2为子角色;
ASSIGN∷=(Ui,Ti,UT)表示用户、任务及任务分配关系.其中,UT={u,t},u∈Ui,t∈Ti,表示用户u是任务t的执行者;
PA∷=(Tnbp,Rnbp,Unbp,TRnbp,URnbp)表示非流程任务、角色、用户及其分配关系.其中,Tnbp∈T,表示非流程任务集合;Rnbp属于R表示与非流程任务有关的角色集合;Unbp属于U表示与Rnbp有关的用户集合;TRnbp={task,role},task∈Tnbp,role∈Rnbp表示非流程任务和角色之间的分配关系;URnbp={user,role},user∈Unbp,role∈Rnbp表示用户和角色之间的分配关系;
DELEG∷=(Ui,Ti,UD)表示用户和任务的委托关系.其中,UD={u1,u2,t,dType},u1,u2∈Ui,u1表示委托人,u2表示被委托人,t∈Ti,表示委托任务,dType∈{grant,tranfer}表示委托类型.在TRBAC中,由于权限与任务绑定,因此,在业务流程执行过程中通常是一个用户将任务实例委托给另一个用户去执行[17].被委托人在获取任务执行权限的同时,也获取了执行该任务所需的权限.
2.3授权图
授权图是依从性分析框架的图形化表示.从系统科学的角度来讲,依从性分析框架包括用户、角色、任务和权限4种组分,而组分之间的关系主要来源于不同组分之间(相同组分之间的关系可以转换为不同组分之间的关系,第3节有详细阐述),因此,可以使用分层的图形化方法来表示依从性分析框架.由于不同层次之间的顶点之间关系的语义有明显的指向性,因此,使用有向图来表示依从性分析框架.我们称由用户、角色、任务和权限为顶点,他们之间的关系为边构成的有向图为授权图.由于业务流程模型依从性分析框架和任务分配依从性分析框架的构成组分和关系有所不同,相应的授权图也有所不同,使用TASK,PA,AA,ORG构建业务流程模型依从性分析框架的授权图,称为静态授权图(static authority digraph, SAD),使用TASK,PA,ASSIGN,ORG构建任务分配依从性分析框架的授权图,称为动态授权图(dynamic authority digraph,DAD).DELEG作为任务分配依从性分析的另外一个输入,CONST是业务流程模型和任务分配依从性分析的内容.下面给出静态授权图和动态授权图的构建步骤.
静态授权图步骤构建:
1) 若权限p∈P且p∉SAD,则创建节点p;
2) 若任务t∈T且t∉SAD,则创建节点t;
3) 若角色r∈R且r∉SAD,则创建节点r;
4) 若用户u∈U且u∉SAD,则创建节点u;
5) 若(t,p)∈TP且(t,p)∉SAD,则创建边(t,p);
6) 若(t,r)∈TRbp∪TRnbp且(t,r)∉SAD,则创建边(r,t);
7) 若(u,r)∈URbp∪URnbp且(u,r)∉SAD,则创建边(u,r);
8) 若(r1,r2)∈RR且(r2,r1)∉SAD,则创建边(r2,r1).
动态授权图步骤构建:
1) 若权限p∈Pi且p∉SAD,则创建节点p;
2) 若任务t∈Ti∪Tnbp且t∉SAD,则创建节点t;
3) 若角色r∈Rnbp且r∉SAD,则创建节点r;
4) 若用户u∈Ui∪Unbp且u∉SAD,则创建节点u;
5) 若(t,p)∈TPi且(t,p)∉SAD,则创建边(t,p);
Fig. 2 Static authorization digraph GS图2 静态授权图GS
6) 若(t,r)∈TRnbp且(t,r)∉SAD,则创建边(r,t);
7) 若(u,r)∈URnbp且(u,r)∉SAD,则创建边(u,r);
8) 系(r1,r2)∈RR且(r2,r1)∉SAD,则创建边(r2,r1);
9) 若(u,t)∈UT且(u,t)∉SAD,则创建边(u,t).
使用有向图GS和GD分别表示静态授权图和动态授权图,则GS和GD分别如图2和图3所示.由于SAD和DAD中定义的用户、角色、任务和权限之间的关系均为二元关系,通过TRBAC和业务流程模型及实例的相关定义易知,GS和GD能够分别的准确表示BPMCAF和TACAF的含义.
Fig. 3 Dynamic authorization digraph GD图3 动态授权图GD
通过第2节给出的依从性分析框架及其图形化表示,可以构建由用户、角色、任务和权限为顶点,他们之间的关系为边构成的授权图.在授权图中,从用户节点U到权限节点P的路径表示该用户U可以获取权限P;从角色节点R到权限节点P的路径表示角色R可以获取权限P;从任务节点T到权限节点P的边表示任务T具有权限P.我们定义权限P之间存在安全约束,那么职责分离约束依从性分析是分析能够获取互斥权限的任务集合、角色集合和用户集合的过程.职责绑定约束依从性分析是分析绑定权限不能够被分配给同一用户的过程.在第1节中已经给出用户获取权限的3种途径,分别为通过角色和任务获取、通过继承关系获取和通过委托机制获取.在授权图中,通过角色和任务获取权限方式是由不同层节点之间的关系获取,从用户到权限的路径长度为固定值3,因而在算法实现过程中具有较高的效率.而通过继承关系获取权限是通过同层次节点获取权限的方法,从用户到权限的路径长度存在不确定性,难于直接分析.同样地,在业务流程执行过程中发生的任务委托也增加了用户所具有权限的不确定性.因此,需要消除上述不确定性.
本节首先给出授权图节点间继承关系的预处理方法,化简继承关系;然后给出委托关系预处理方法,消除由于委托关系带来的不确定性;最后进行授权约束依从性分析.
3.1继承关系化简
Oh等人[6]对TRBAC中的继承关系进行了定义,与RBAC中的继承关系不同,TRBAC中的角色权限是任务的执行权限,继承的权限也是任务执行权限.根据任务类型的不同,子角色继承父角色的部分权限.Oh等人将任务分为P,S,W,A四类,分别表示不可继承被动任务、可继承被动任务、不可继承主动任务和可继承主动任务.子角色可以继承父角色的S类和A类的任务执行权限.
在授权图中,继承关系是角色层中节点之间的边来表示,我们希望通过将这种同层关系化简为不同层面之间的关系从而降低授权图的复杂程度便于依从性分析.使用TP,TS,TW和TA分别表示P,S,W,A四类任务集合,则TP∪TS=Tnbp,TW∪TA=Tbp.可以给出继承关系化简规则,即:
继承关系化简的主要思路是将父角色的可继承任务的权限直接赋予子角色.化简的优势是将依从性分析框架中角色之间的关系转换为角色与任务之间的关系,从而简化依从性分析的过程.角色的继承关系反应系统中角色的组织结构,而角色的组织结构通常是类似树形结构.在化简过程中,为了保证子节点能够继承父节点以及其他祖先节点的任务执行权限,需要按照原则进行化简:1)从根节点的继承关系开始化简;2)在所有父节点的继承关系化简完成之后,子节点才能够进行化简.图4为继承关系化简算法伪代码.
(a) Reduction algorithm of one (b) Reduction algorithm of all roles role inheritance inheritance in the organization
Fig. 4 Algorithm of inheritance reduction
图4 继承关系化简算法
3.2委托关系化简
为了确保以用户为中心的业务管理并支持跨组织的协作,业务流程中候选用户经常需要将分配给他的任务委托给其他用户去执行.完整的委托包括4个要素:委托人、被委托人、任务实例和委托方式.其中,委托方式包括授予和转移.当委托人将任务实例执行权限授予被委托人时,委托人与被委托人均具有任务实例的执行权限.当委托人将任务实例执行权限转移给被委托人时,只有被委托人具有任务实例执行权限.由于2种委托方式对任务实例执行权限的分配能够造成不同的影响,因此在化简时需要分别处理.
委托关系是用户和用户之间的关系,委托的内容是任务的执行权限,委托关系使委托人和被委托人所具有的任务执行权限发生变化.因此,为了能够得到用户在业务流程执行过程中某一时刻能够获取的所有权限,需要将被委托人和委托任务联系起来.下面给出委托关系化简规则,
委托关系化简规则的主要思路是将用户之间的委托关系转换为用户和角色以及角色和任务之间的分配关系.在化简过程中,如果委托类型为transfer,那么委托人将失去任务的执行权限.如果委托类型为grant,那么委托之后委托人和被委托人均具有任务的执行权限.委托化简的伪代码如图5所示:
Fig. 5 Algorithm of delegation reduction图5 委托关系化简算法
3.3依从性分析
通过继承关系和委托关系化简,可以得到由用户、角色、任务和权限为顶点,不同类型顶点之间的关系为边构成的授权图.在这个授权图中,我们可以通过有向图的运算得到能够获取指定权限的所有任务集合(包括流程任务和非流程任务)、角色集合(包括流程角色、非流程角色以及通过角色间的继承关系得到的权限)以及用户集合(包括所有用户以及通过用户之间的委托关系得到的权限).
依从性分析是分析授权图中用户、角色和任务所具有的权限是否违反授权约束的要求.依从性分析框架主要分析职责分离和职责绑定约束.在业务流程环境中,职责分离约束可以分为静态职责分离和动态职责分离约束,在本文中,静态职责分离约束是指在业务流程设计阶段,同一任务、角色或者用户无论通过流程授权还是非流程授权均不能获取互斥权限的规定.动态职责分离约束是指在业务流程执行阶段,同一用户无论通过流程授权还是非流程授权均不能获取互斥权限的规定.同样地,职责绑定约束分为静态职责绑定约束和动态职责绑定约束.静态职责绑定约束是指在业务流程设计阶段,绑定权限能够分配给同一个用户.动态职责绑定约束是指业务流程执行阶段,绑定权限能且只能分配给相同的用户.下面给出上述4种约束的依从性分析算法.
静态职责分离约束依从性分析的输入是静态授权图SAD和互斥权限(v,w).如图6所示分析过程:
1) 判断是否存在任务t同时具有权限v和权限w,如果存在这样的任务t,则发生了任务不依从.
2) 否则,判断是否存在角色r能够同时获取权限v和权限w,如果存在这样的角色r,则发生了角色不依从.
3) 否则,判断是否存在用户u能够同时获取权限v和权限w,如果存在这样的用户u,则发生了用户不依从.
Fig. 6 Algorithm of static SoD conflict checking图6 静态职责分离冲突分析算法
动态职责分离约束依从性分析的输入是动态授权图DAD、互斥权限(v,w).动态授权图刻画的是流程实例的权限分配情况,由于任务以及非流程角色的职责分离依从性在静态分析中已经进行分析,因此在这里只需要分析用户的职责分离依从性,分析算法如图7所示:
Fig. 7 Algorithm of dynamic SoD conflict checking图7 动态职责分离冲突分析算法
静态职责绑定依从性分析的输入是静态授权图SAD和绑定权限(v,w).如果不存在任何用户能够同时获取权限v和权限w,则违反静态职责绑定约束,分析算法如图8所示:
Fig. 8 Algorithm of static BoD conflict checking图8 静态职责绑定冲突分析算法
动态职责绑定依从性分析的输入是动态授权图DAD和绑定权限(v,w).如果存在用户u,只能够获取权限v或者只能够获取权限w,则违反动态职责绑定约束,分析算法如图9所示:
Fig. 9 Algorithm of dynamci BoD conflict checking
通过对角色继承关系和委托关系的化简,我们得到简单授权图.使用依从性分析算法对简单授权图进行分析可以发现4类违反授权约束的冲突.为了能够消解所发现的冲突,需要对这4类冲突做进一步的分析.
4.1静态职责分离冲突
任务层静态职责分离冲突:当一个任务同时具有2个互斥权限时发生任务层静态职责分离冲突.如图10中冲突模式1所示,权限PA和PB为互斥权限,任务TA同时具有这2个权限.这种冲突是根本性的冲突且易于发现,但是在业务流程执行过程中存在严重的安全隐患,必须予以解决.冲突发生原因是在设计任务时没有考虑职责分离约束的限制.解决思路是重新设计任务,如图10中解决方案1所示,将任务TA分解为2个子任务TB和TC,将互斥权限分配给这2个不同任务.
Fig. 10 Static SoD conflict with tasks图10 任务层静态职责分离冲突
Fig. 11 Static SoD conflict with roles图11 角色层静态职责分离冲突
角色层静态职责分离冲突:当一个角色通过分配给他的任务获取互斥权限时发生角色层静态职责分离冲突,如图11中冲突模式2所示.角色层职责分离冲突使能够激活该角色的用户都能够获取互斥权限,安全隐患较为严重.解决思路是将任务角色RA进一步划分为子角色RC和RD,并分别分配任务TA和TB,如图11解决方案2所示;或者将任务TB分配给另外的角色RB来执行,如图11解决方案3所示.角色可以通过任务分配和继承父角色来获取任务的执行权限.针对继承父角色获取任务执行权限导致的角色层静态职责分离冲突,可以通过调整角色间的继承关系来消解冲突.
用户层静态职责分离冲突:当一个用户通过其激活的角色执行任务获取互斥权限时发生用户层静态职责分离冲突,如图12中冲突模式3所示.随着系统规模的不断扩大和用户的增加,这一类冲突容易发生且难于发现,但是想比较而言安全威胁较小.解决这一类冲突有2种思路:
1) 如图12中解决方案4和解决方案5所示,将任务TB分配给除角色RB以外的角色去执行,或者在角色RB中删除用户UA.这样做的优点是一劳永逸,从根本上避免冲突发生;缺点是对系统调整较大,可能会影响系统执行效率.
2) 在业务流程运行阶段进行安全检查,在流程实例中避免用户UA同时能够执行任务TA和TB.
Fig. 12 Static SoD conflict with users图12 用户层静态职责分离冲突
4.2动态职责分离冲突
动态职责分离冲突:当一个用户通过分配给其的任务以及固有任务获取互斥权限时发生动态职责分离冲突,如图13所示.动态职责分离冲突发生在业务流程运行阶段.对于图13(a)和图13(b)所示的职责分离冲突,可以将任务TB分配给另外的用户UB去执行,如解决方案6和解决方案8所示.如果UA执行任务TB是通过任务委托获取的权限,那么这样的委托请求将被拒绝.对于图13(a)中的职责分离冲突,还可以通过删除角色RA中的用户UA来消解冲突,如解决方案7所示.
Fig. 13 Dynamic SoD conflict图13 动态职责分离冲突
4.3静态职责绑定冲突
静态职责绑定冲突:当不存在任何用户能够同时获取绑定关系的权限时发生静态职责绑定冲突,如图14冲突模式6所示.解决思路是将任务TA和TB合并为一个任务TC,或者将相关角色合并得到一个角色RD,或者修改用户与角色间的分配关系,使得某些用户(UB)能够同时获取权限PA和PB,分别如图14中解决方案9~11所示.
Fig. 14 Static BoD conflict图14 静态职责绑定冲突
4.4动态职责绑定冲突
动态职责绑定冲突:当一个用户获取绑定权限中的一个而不能够获取另外一个时发生动态职责绑定冲突,如图15所示.对于冲突模式7和冲突模式8,将分配计划中的UB,TB修改为UA,TB则消除了职责绑定冲突,如解决方案12和解决方案13所示.对于动态职责绑定冲突,解决思路主要是通过修改分配计划达到消解冲突的目的.
Fig. 15 Dynamci BoD conflict图15 动态职责绑定冲突
5.1实例分析
本节使用销售部门的实例来说明所提出框架和分析方法的有效性.该部门设置销售经理(sales manager)、销售前台(sales man)和销售后台(sales clerk)3个角色;接收订单(receive order)、查看库存(check product stock)、查看付款信息(check payment)、审批订单(approve order)、查看销售结果(review sales results)和查看销售统计(review sales statistics)6个任务.角色之间继承关系以及业务流程逻辑结构分别如图16和图17所示.用户角色、角色任务以及任务权限的分配关系分别如表1~3所示.应用本文所提出授权图构造方法以及继承关系化简方法得到授权图如图18所示.在这个实例中存在3个授权约束:1)约束1.创建订单和修改订单是绑定权限;2)约束2.创建订单和确认订单是互斥权限;3)约束3.修改订单和确认订单是互斥权限.我们基于Java编写了原型系统实现本文所提出的依从性分析框架和方法,该原型系统独立于系统部署的平台,通过开发中间件的方式从系统中获取依从性分析所需数据,具有较为广泛的应用范围.执行原型系统得到依从性分析结果如表4所示.
Fig. 16 Organization structure of sales department图16 销售部门组织结构
Fig. 17 Logic structure of sales process图17 销售流程逻辑结构
Table 1 User Role Assignment表1 用户角色分配关系
Table 2 Role Task Assignment表2 角色任务分配关系
Table 3 Task Permission Assignment表3 任务权限分配关系
Fig. 18 Authorization graph of sales process图18 销售流程授权图
Table 4 Result of Compliance Analysis表4 依从性分析结果
从表4可以看出,该实例存在角色层静态职责分离冲突和用户层静态职责分离冲突.由于销售经理继承了销售前台和销售后台的角色,而销售前台和销售后台能够执行的任务接收订单和审批订单都是可继承的,因此,销售经理获取了接收订单和审批订单的执行权限,从而获取了创建、修改订单和确认订单的权限,违反角色层静态职责分离约束.由于这种冲突是由于角色继承关系引起的,因此可以通过令销售经理不再继承销售前台的方法来消解.员工丙具有销售后台和销售前台2个角色,同样的也能够获取创建、修改订单和确认订单的权限,违反了用户层职责分离冲突.针对这种冲突可以在流程运行阶段通过动态依从性检查的方法判断用户丙是否在同一个流程实例中获取这2个权限.
5.2实验验证
我们使用Java实现了业务流程授权约束依从性分析的原型系统.但是由于获取实际的授权数据存在较大的困难[18-19],我们采用了文献[18]的思路,设计并实现了授权图的实例产生器.该实例产生器能够产生实验所需的静态授权图和动态授权图,静态授权包括主动访问(AA)、被动访问(PA)、组织(ORG)、任务(TASK)和约束(CONST).动态授权包括分配计划(ASSIGN)、被动访问(PA)、组织(ORG)、任务(TASK)、约束(CONST)和委托(DELEG).
我们将授权图的节点数量n作为参数输入实例产生器,按照规则产生用户、角色、任务和权限的数量.具体地,用户数量un=n×4/10,角色数量rn=n×1/10,任务数量tn=n×2/10,权限数量pn=n×3/10.节点之间的关系(即边)随机生成,生成率为5%(每一个2元关系矩阵的0和1比率为95∶5).角色间的继承关系为深度为3的树形结构.职责分离和职责绑定约束的数量由权限数量决定,我们设置每10个权限产生一个职责分离约束,每20个权限产生一个职责绑定约束.我们将节点总数分别设置为100,200,300,400和500,并且每个规模产生10个授权图.这样我们能够分别得到50个静态授权图实例和50个动态授权图实例.对这5个规模共100个授权图进行依从性分析,我们使用一台1.40 GHz Intel Core i3-3229Y CPU,4 GB内存的电脑进行实验,得到实验结果如表5和表6所示:
Table 5 Result of Static Compliance Analysis Experiment表5 静态依从性分析实验结果
Table 6 Result of Dynamci Compliance Analysis Experiment表6 动态依从性分析实验结果
表5和表6是统计数据,我们对每一种规模的授权图进行依从性分析,记录产生的边数、分析所消耗的时间、被违反的职责分离和职责绑定约束的数量,然后取平均值.从实验结果来看:
1) 随着节点规模的增长,授权图中的边数急剧增长,依从性分析消耗的时间也在增长,当静态授权图节点数为500时,平均有2 759.7条边,而依从性分析的时间是474 ms,分析效率比较理想.而动态授权图由于分配计划是针对每一个任务分配一个用户,因此节点间的关系比静态授权图简单,边的数量比同等规模的静态授权图减少很多,分析效率也比较理想.
2) 从表7能够发现职责分离约束被违反的比例随着节点规模的增长在不断增加,而职责绑定冲突发生的比例在不断减少.节点规模为500时,15个职责分离约束几乎全部会被违反(99%和95%的比例),职责绑定约束几乎不会被违反(1%和7%的比例).这是因为节点的增加导致边的增加,而边的增加意味着用户获取权限路径的增加,从而同一个用户获取具有职责分离关系和职责绑定关系的概率都得到增长,导致职责分离冲突发生的概率增加和职责绑定冲突发生的概率减少.这一结论也说明本文的意义所在,职责分离冲突在系统规模较小时不易发生,但是随着系统规模的扩大而冲突发生的概率急速增长,给出一种能够适用于大规模业务流程系统的高效依从性分析方法就势在必行.另外,由于在分配计划中流程任务节点的入度始终为1,因此动态授权图中冲突发生的比例随着节点增加的变化要相对缓慢一些.
Table 7 Violation Percentage of Authorization Constraints表7 授权约束被违反的比例
以上对本文所提出方法的时间效率进行了分析.下面与现有研究中其他方法进行定性比较.比较结果如表8所示.通过比较可以看到,相对于以往的研究,本文所提出的依从性分析框架兼顾了静态约束、动态约束、职责分离约束、职责绑定约束、流程授权、非流程授权、委托等各个方面,更贴近实际企业环境,易于应用.同时针对所发现的授权冲突给出解决方案.我们对相关算法进行试验,给出效率分析,与Armando所提出的模型检查的方法相比具有明显优势.
Table 8 Compare of the Compliance Analysis Framework with Other Researches
Note:“√” means support.
现有的工作在业务流程授权约束依从性分析方面进行了大量的工作.进行授权约束依从性分析时,首先需要明确系统的访问控制模型和授权约束.因此,相关工作将从访问控制模型和授权约束,及依从性分析方法2个方面展开.
首先,在访问控制模型及授权约束方面,Bertino等人[2]首次提出约束描述语言用于描述RBAC所不能描述的约束,如职责分离约束.Ultra等人[22]提出了简单职责分离模型,能够方便的与基于角色的访问控制模型相结合.Brucker 等人[23]提出了在业务流程设计阶段和运行阶段基于RBAC安全需求的描述方法.Li 等人[4]提出了SoDA来描述业务流程授权约束,包括质量约束(例如执行任务的角色)和数量约束(例如SoD).上述方法都是基于RBAC展开的,由于RBAC未考虑系统中的业务流程以及任务与角色的区别,未能很好适应企业业务流程环境,因此研究者提出了基于“任务-角色”的访问控制模型.
Xing等人[24]提出了基于角色和任务的工作流授权模型.在该模型中角色不再直接具有权限,而是通过分配给其的任务获取权限.同时,文章提出了基于角色和任务的约束描述语言RTCL来描述职责分离等约束.Oh等人[6]提出了TRBAC的访问控制模型来满足企业环境中经常产生主动访问(业务流程访问)和被动访问(基于RBAC的访问)相结合的需求,并对任务的类型进行了深入分析.上述方法对RBAC进行扩展,提出了任务的概念,这些方法在业务流程授权过程中遵循了最小权限原则,提高了安全性.但是使用形式化方法描述授权约束,使得约束的表现形式不够灵活,同时也使得约束描述和分析过程必须具备一定的专业知识,不易广泛地应用,本文使用了权限1、权限2、约束类型三元组来描述授权约束,不仅易于描述和理解,便于灵活使用,在依从性分析时也具有较高的效率.
在授权约束依从性分析方法方面,Liu等人[25]使用Petri网描述工作流,使用Prolog语言描述职责分离规则,使用逻辑推理的方法找到满足安全规则的有效执行链.Lu 等人[8]使用着色Petri网来验证业务流程设计阶段职责分离约束的正确性和一致性.Schefer-Wenzl 等人[13]给出了流程感知信息系统中基于角色访问控制模型的委托建模方法,并在此基础上分析了委托情况下存在的授权冲突,给出解决方案.该方法能够分析委托是否会产生冲突,但是没有考虑委托之外的授权引起的授权冲突,并且未考虑职责绑定约束.Salnitri 等人[26-27]提出了SecBPMN来扩展BPMN以描述描述信息系统,使用SecBPMN-Q描述安全策略,并给出了SecBPMN-Q语言所描述安全策略的验证方法.该方法依赖于BPMN,具有局限性.Strembeck 等人[21]提出了业务流程环境中互斥和绑定约束一致性分析的通用算法,避免约束冲突,保证在流程设计和执行阶段的依从性.该方法给出了业务流程静态设计和动态执行时职责分离和职责绑定约束依从性分析的通用算法,但是该算法没有考虑被动授权的情况,本文也未对算法的效率进行说明.
另外,模型检查作为业务流程是否满足安全策略的检测方法也得到了大量关注[20,28-30].上述方法中,使用推理、Petri网等形式化的方法具有较大的局限性,并且应用起来需要一定的专业知识,不易广泛应用.给出的一些通用算法不能够完全适应当前企业流程环境.而模型检查的方法在较大规模的系统中应用时存在状态空间急剧增长的问题,与实际应用存在较大的距离.
基于上述研究现状,结合企业业务流程环境的实际需求,本文基于TRBAC提出了授权约束依从性分析框架,所提出的框架考虑了流程授权和非流程授权、业务流程任务委托、角色继承关系、职责分离和职责绑定约束、静态约束和动态约束,并提出授权图来表示框架内所包含的内容,通过将依从性分析问题转换为有向图的分析问题来高效地发现授权约束冲突.
本文提出了一种支持任务委托的业务流程授权约束依从性分析框架.该框架能够描述业务流程授权和非业务流程授权,能够描述角色之间的继承关系、业务流程中任务委托.提出了授权图来表示依从性分析框架,给出了授权图的构造和化简方法,并基于授权图给出了依从性分析方法.我们所提出的分析方法能够分析静态职责分离、动态职责分离、静态职责绑定和动态职责绑定4类冲突以及8种冲突模式,并针对每一种冲突模式给出一组解决方案.实现了所提出框架和方法的原型系统,并通过实例分析和实验验证说明了所提出框架和方法的有效性.
近些年,我们发现学术界和业界对流程感知信息系统的关注不断增加,我们也相信越来越多的流程感知信息系统将会应用于实际环境中去.因此,权限的管理也随之变得更为重要.本文所提出的授权约束依从性分析框架对于保障权限的正确分配和任务的安全执行具有重要意义.
[1] Ly L T, Rinderle-Ma S, Knuplesch D, et al. Monitoring business process compliance using compliance rule graphs[C] //Proc of OTM’11. Berlin: Springer, 2011: 82-99
[2] Bertino E, Ferrari E, Atluri V. An authorization model for supporting the specification and enforcement of authorization constraints in workflow management systems[J]. ACM Trans on Information System Security, 1999, 2(1): 65-104
[3] Wolter C, Schaad A. Modeling of task-based authorization constraints in BPMN[C] //Proc of the 5th Int Conf on Business Process Management. Berlin: Springer, 2007: 64-79
[4] Li Ninghui, Wang Qihua. Beyond separation of duty: An algebra for specifying high-level security policies[C] //Proc of the 13th ACM Conf on Computer and Communications Security. New York: ACM, 2006: 356-369
[5] Schaad A. A framework for evidence lifecycle management[C] //Proc of WISE’07. Berlin: Springer, 2007: 191-200
[6] Oh S, Park S. Task-role-based access control model[J]. Information Systems, 2003, 28(6): 533-562
[7] Wolter C, Schaad A, Meinel C. Task-based entailment constraints for basic workflow patterns[C] //Proc of ACM Symp on Access Control Models and Technologies. New York: ACM, 2008: 51-60
[8] Lu Yahui, Zhang Li, Sun Jiaguang. Using colored Petri nets to model and analyze workflow with separation of duty constraints[J]. The International Journal of Advanced Manufacturing Technology, 2009, 40(1): 179-192
[9] Hasebe K, Mabuchi M, Matsushita A. Capability-based delegation model in RBAC[C] //Proc of ACM SACMAT’10. New York: ACM, 2010: 109-118
[10] Crampton J, Khambhammettu H. On delegation and workflow execution models[C] //Proc of ACM SAC’08. New York: ACM, 2008: 2137-2144
[11] Crampton J, Khambhammettu H. Delegation and satisfiability in workflow systems[C] //Proc of ACM SACMAT’08. New York: ACM, 2008: 31-40
[12] Crampton J, Khambhammettu H. Delegation in role-based access control[J]. International Journal of Information Security, 2008, 7(2): 123-136
[13] Schefer-Wenzl S, Strembeck M. Modeling support for role-based delegation in process-aware information systems[J]. Business & Information Systems Engineering, 2014, 6(4): 215-237
[14] Simon R, Zurko M E. Separation of duty in role-based environments[C] //Proc of the 10th Computer Security Foundations Workshop. Piscataway, NJ: IEEE, 1997: 183-194
[15] Ferraiolo D, Cugini J, Kuhn D R. Role-based access control (RBAC): Features and motivations[C] //Proc of the 11th Annual Computer Security Applications Conf. Piscataway, NJ: IEEE, 1995: 241-248
[16] Botha R A, Eloff J H P. Separation of duties for access control enforcement in workflow environments[J]. IBM Systems Journal, 2001, 40(3): 666-682
[17] Hsu H J, Wang F J. A delegation framework for task-role based access control in WFMS[J]. Journal of Information Science & Engineering, 2011, 27(3): 1011-1028
[18] Cohen D, Crampton J, Gagarin A, et al. Engineering algorithms for workflow satisfiability problem with user-independent constraints[C] //Proc of FAW 2014. Berlin: Springer, 2014: 48-59
[19] Wang Qihua, Li Ninghui. Satisfiability and resiliency in workflow authorization systems[J]. ACM Trans on Information & System Security, 2010, 13(4): 1-35
[20] Armando A, Ponta S E. Model checking authorization requirements in business processes[J]. Computer Security, 2014, 40: 1-22
[21] Strembeck M, Mendling J. Generic algorithms for consistency checking of mutual-exclusion and binding constraints in a business process context[G] //LNCS 6426: Proc of OTM 2010. Berlin: Springer, 2010: 204-221
[22] Ultra J D, Pancho-Festin S. A simple model of separation of duty for access control models[J]. Computers & Security, 2017, 68: 69-80
[23] Brucker A D, Hang I, Ckemeyer G, et al. SecureBPMN: Modeling and enforcing access control requirements in business processes[C] //Proc of ACM SACMAT’12. New York: ACM, 2012: 123-126
[24] Xing Guanglin, Hong Fan. A workflow authorization model based on role and task and constraints specification[J]. Journal of Computer Research and Development, 2005, 42(11): 1946-1953 (in Chinese)
(邢光林, 洪帆. 基于角色和任务的工作流授权模型及约束描述[J]. 计算机研究与发展, 2005, 42(11): 1946-1953)
[25] Liu Daobin, Guo Li, Bai Shuo. A methodology for analyzing security policy in workflow[J]. Journal of Computer Research and Development, 2008, 45(6): 967-973 (in Chinese)
(刘道斌, 郭莉, 白硕. 一种工作流安全策略分析方法[J]. 计算机研究与发展, 2008, 45(6): 967-973)
[26] Salnitri M, Dalpiaz F, Giorgini P. Modeling and Verifying Security Policies in Business Processes[G] //LNBIP 175: Proc of BPMDS’14. Berlin: Springer, 2014: 200-214
[27] Salnitri M, Dalpiaz F, Giorgini P. Designing secure business processes with SecBPMN[J]. Software & Systems Modeling, 2017, 16(3): 737-757
[28] Arsac W, Compagna L, Pellegrino G, et al. Security validation of business processes via model-checking[C] //Proc of ESSoS’11. Berlin: Springer, 2011: 29-42
[29] Mendt T, Sinz C, Tveretina O. Analyzing Separation of Duties Constraints with a Probabilistic Model Checker[M]. Berlin: Springer, 2011: 18-29
[30] Armando A, Carbone R, Compagna L. SATMC: A SAT-based model checker for security protocols, business processes, and security APIs[J]. International Journal on Software Tools for Technology Transfer, 2016, 18(2): 187-204BoYang, born in 1985. PhD candidate of computer science at Beihang University. His main research interests include the security and privacy of network and business process.
ComplianceAnalysisofAuthorizationConstraintsinBusinessProcess
Bo Yang1,2and Xia Chunhe1,2,3
1(BeijingKeyLaboratoryofNetworkTechnology(BeihangUniversity),Beijing100191)2(SchoolofComputerScienceandEngineering,BeihangUniversity,Beijing100191)3(CollegeofComputerScienceandInformationTechnology,GuangxiNormalUniversity,Guilin,Guangxi510004)
A novel framework of business process compliance analysis is proposed in this paper, and the proposed framework can process 1)business process authorization and non-business process authorization; 2)delegation of task of business processes; 3)inheritance of roles; 4)separation of duty and binding of duty constraints; 5)statics constraints and dynamic constraints. Authorization graph is proposed to describe the framework, and construct and reduce methods of authorization graph are designed to maintain the graph, then compliance analysis algorithms of authorization graph are proposed. Based on the analysis results, conflict patterns are presented. A set of resolutions for each pattern are provided, and a prototype system is implemented. The framework of authorization constraint compliance analysis, independent of platform, can be widely applied to system security analyzing. The effectiveness of the proposed method is reported by a case study and experiments at the end of this paper.
business process; authorization constraints; compliance; separation of duty; binding of duty; task delegation
TP391
XiaChunhe, born in 1965. Professor and PhD supervisor of Beihang University. Director of Key Laboratory of Beijing Network Technology. Senior member of CCF. His main research interests include network security, network management and security policy analysis.
2015年《计算机研究与发展》高被引论文TOP10
数据来源:CSCD,中国知网;统计日期:2016-12-05