一种基于UML模型的起源感知访问控制策略分析方法

一种基于UML模型的起源感知访问控制策略分析方法*

孙连山1,祁志斌2,侯涛1

(1.陕西科技大学电气与信息工程学院，陕西 西安 710021;

2.中国石油长庆油田公司资金结算中心,陕西 西安 710021)

摘要：起源(Provenance)是记录数据演变历史的元数据。 最近研究者提出起源感知的访问控制,通过追溯和分析访问者或被访问对象的起源来决定允许或拒绝访问请求。 由于起源通常由系统在运行时记录并呈现为复杂的有向图,识别、规约和管理起源感知的访问控制策略非常困难。 为此,提出了一个基于UML模型的起源感知访问控制策略分析方法,包括对复杂起源图的抽象建模技术以及一个在面向对象的软件开发过程中系统地建立起源模型、规约起源感知访问控制策略的参考过程指南。 最后结合企业在线培训系统案例说明如何应用所提出的方法。

关键词：起源;起源模型;访问控制;UML;安全工程

中图分类号：TP311.5 文献标志码：A

doi:10.3969/j.issn.1007-130X.2015.06.013

收稿日期：*2014-01-24;修回日期：2014-08-14

基金项目：国家自然科学基金资助项目(61202019);陕西省教育厅自然科学专项 (14JK1098)

作者简介:

通信地址：710021 陕西省西安市未央区北郊大学城陕西科技大学电气与信息工程学院计算机系

Address:Department of Computer Science,College of Electrical and Information Engineering,Shaanxi University of Science and Technology,Xi’an 710021,Shaanxi,P.R.China

A UML model-based analysis approach for provenance-aware access control policies

SUN Lian-shan1,QI Zhi-bin2,HOU Tao1

(1.College of Electrical and Information Engineering,Shaanxi University of Science and Technology,Xi’an 710021;

2.Settlement Center,Petrochina Changqing Oilfield Company,Xi’an 710021,China)

Abstract:Provenance is the historical meta-data of data objects. It has recently been used to enable provenance-based access control (PBAC), which grants or denies an access request according to the provenance of either the subjects or the objects. However, provenance can only be collected at run-time via complex directed acyclic graphs, so it is very difficult for security architects to efficiently specify PBAC policies due to the complexity of provenance graphs and its unavailability at design time. We explore a UML model-based approach to analyze PBAC policies. Specifically, we first introduce a conceptual provenance model to shield the complexity of the provenance graphs and to enable policy analysis at the design time. We then introduce a UML model-based process to guide the analysis of the conceptual provenance model and the PBAC policies along with the object-oriented development. We validate the proposed approach within an enterprise online training system.

Key words:provenance;provenance model;access control;UML;security engineering

1引言

现代软件应用系统通过网络互联,形成动态变化的复杂软件网络[1]。大量数据在软件网络经历由不同用户和系统实施的复杂的加工处理过程，数据之间存在复杂的依赖关系，不仅数据的可用性至关重要,数据来源以及数据产生过程的可信性也非常重要[2,3]。借鉴艺术品鉴定领域记录艺术品的来源和流转过程的做法,人们提出了数据起源 (Provenance) 的概念[4]，并尝试实现了各种起源感知系统PAS(Provenance-Aware Systems)[3,4],解决诸如产品质量问题溯源、科学实验结果重建、智能金融决策、电子病例跟踪、访问控制等不同领域的需求[3,5]。数据的起源其实就是数据的演变历史档案,是一种特殊的元数据。起源记录了数据在其从产生到消亡的整个生命期内所涉及的各种数据、加工处理过程以及人员等信息[4～7]。数据溯源则是查询数据起源的活动。起源感知系统支持数据溯源,允许用户利用起源数据完成不同的任务。

起源数据具有迥异于普通数据和其它元数据的特点[8]。首先,起源数据通常是数据对象的历史,语义上具有不可变性;其次,数据对象的某个历史版本或处理过程实例往往不能单独刻画起源信息的本质,起源数据通常呈现为由实体以及实体之间的因果关系 (起源依赖关系) 构成的复杂有向图 (简称起源图)。起源数据的独特性质导致传统的安全模型、机制和策略规约语言和工具无法直接用于实现起源感知系统的访问控制[9,10]。具体来讲,起源数据对访问控制的影响至少体现在两个方面。首先,起源数据可能具有敏感性[11,12]。例如,学员的综合成绩不是敏感数据,但包含不同考核人员打分过程信息的起源数据却是敏感的。其次,起源数据也可作为决策的依据,控制用户对系统中的敏感资源的访问[13,14]。例如,规定员工的业绩必须经过至少三位以上同事的匿名评审之后,才能由其主管评定和提交最终考核成绩。这里员工业绩所经历的匿名评审次数作为起源数据是控制主管能否开始评定员工考核成绩的依据。针对这些新型访问控制需求以及起源感知系统的独特性质,研究者提出了一系列起源感知的访问控制模型、策略规约语言和相应的实施框架[10～14],为保护起源感知系统中敏感的数据起源以及其它敏感资源提供一种新途径。

作为现有访问控制系统的补充和发展,起源感知的访问控制系统包含两部分,即起源感知的访问控制策略以及相应的访问控制策略实施框架。访问控制策略规约用户或组织的安全需求;访问控制实施框架则在运行时截获访问请求并根据访问控制策略决定允许或拒绝访问请求[15]。本文仅关注起源感知访问控制策略的分析问题。事实上,起源感知的访问控制策略通常引用起源图的一个或多个子图。这些子图作为整体封装了定义访问控制策略所需的起源信息。通常需使用某种打包技术封装访问控制策略所需的起源子图[12,16]。如Syalim A等人[16]静态地定义需要保护的敏感起源子图,Cadenhead A等人[12]采用正则表达式表示起源问题，以动态地计算起源子图等。起源图往往非常复杂，子图繁多,且并不是所有子图都具有用户感兴趣的起源依赖语义。因此,识别与起源相关的访问控制需求并定义起源感知的访问控制策略非常困难。

为提高起源感知的访问控制策略规约的效率和灵活性,研究者在访问控制策略中嵌入起源查询语句,动态地计算需要引用的起源子图[12],避免必须静态地定义起源子图的局限。针对起源图的查询语句仍然很复杂,Park J等人[13,14]为起源查询语句命名,提出了依赖名的概念,允许开发者重复使用依赖名代替相似的起源查询语句,进一步提高了规约起源感知策略的效率。但是，现有研究工作仅关注于使用依赖名或其对应的动态起源查询语句规约访问控制策略的可行性,而没有从软件工程的视角考察依赖名与软件分析和设计模型等概念层模型之间的关系,没有讨论如何在软件开发过程当中正确并高效地定义依赖名和相应的访问控制策略等问题。

本文从软件工程的角度考察起源感知访问控制策略的分析问题,提出一个基于统一建模语言UML(Unified Modeling Language)模型的起源感知访问控制策略分析方法，包括对复杂起源图的抽象建模技术以及一个在面向对象的软件开发过程中建立起源模型、基于起源模型规约起源感知访问控制策略的参考过程指南。

本文余下部分的安排如下。第2节介绍一个贯穿全文的案例以及有关源感知的访问控制的基础知识。第3节提出了一种抽象的起源模型。该模型深化了依赖名的内涵,明确地定义其组成成分和各成分之间的组装规则和约束,将用户感兴趣的起源语义形式地建模为抽象的起源类型,阐明了起源类型与起源图中具有起源语义的子图之间的关系。抽象的起源模型能屏蔽起源数据的复杂性。引入抽象的起源模型是高效地定义和管理起源感知访问控制策略的关键。第4节分析抽象的起源模型与系统分析和设计模型的关系,给出一个基于UML模型的起源感知访问控制策略分析方法,指导开发者基于软件分析和设计模型建立抽象的起源模型，并进一步规约起源感知的访问控制策略。第5节则以企业在线培训系统为例说明所提出的抽象起源模型和访问控制策略分析方法。第6节介绍了相关工作并总结全文。

2案例及预备知识

本节首先介绍一个起源感知的在线培训系统OTS(Online Training System) 作为贯穿全文的案例,其次简要介绍基于起源的访问控制模型[13],作为理解下文论述的铺垫。

2.1在线培训系统

在线培训系统有学员、讲师和管理者等三类用户。培训活动围绕课程展开,每个课程包含教学课件、教学视频、作业列表以及参与课程的讲师和学员等。学员需浏览教学课件、在线完成练习题、离线完成作业并在线提交。每个作业有一个最终成绩和若干评语。学员可以上传和提交作业,并在提交作业后随机评阅他人作业。系统将在最后时限自动提交所有未提交作业的最新版本。讲师根据作业完成情况和学员对作业的互评结果给作业评分。在线培训系统在运行时记录诸如作业、评语、成绩等问题空间数据对象的起源,包括影响这些数据对象最终状态的中间制品、针对这些数据对象的操作、影响或执行相关操作的人员信息等。讲师可根据起源数据分析学员的学习行为,而管理者则可根据起源数据监督讲师使用在线培训系统实施培训的过程,改进企业的培训管理流程。此外,起源数据还可用于支持起源感知的访问控制,即根据起源数据控制用户对系统中敏感资源的访问 (部分起源数据本身可能也是敏感资源)。OTS的部分安全需求如下:

(1)学员在最终提交作业之前可多次修改作业。

(2)学员可评阅他人作业当且仅当:①该作业已经被提交;②学员本人已经主动提交了作业;③此学员未曾评阅过该作业;④该作业被评阅不多于三次;⑤该作业尚未被评分。

(3)讲师可选择并综合作业的部分评语为作业评出最终成绩当且仅当:①该作业仍未被评分;②该作业至少有两个评语;③该作业的提交者已经至少评阅了两个作业。

(4)系统在最后期限到达时自动提交所有未提交的作业。

(5)学员能查看他人对其作业的评语以及作业的最终成绩,但不能查看评阅人的信息。

(6)学员能评阅其它作业,且能查看其评语在最终评分过程中是否得到采用,但不能查看被评阅作业的作者。

(7)讲师可查看作业的所有者、评阅者是否涉嫌自评阅或相互评阅 (利益冲突)。

2.2起源感知的访问控制

起源通常呈现为影响数据对象的各种实体 (如制品、过程和代理) 以及实体之间的依赖关系所构成的有向图[17]。图1记录了在线培训系统中一个作业成绩的部分起源信息,表示学员S1在提交作业对象Hn之前多次对其进行修改得到H2,…,Hn-1。随后学员S2和S3评阅提交后的作业Hn得到评语R1和R2。讲师P1对Hn进行评分得到其最终成绩G1。起源图中的每个节点表示一个影响其它节点存在的实体。矩形表示数据对象所经历的加工处理过程。图1包括作业上传过程 upload、作业替换过程replace、作业提交过程 submit、作业评阅过程review 以及作业评分过程grade。椭圆形表示影响数据对象最终形态的中间制品。注意本文假设系统不会原地修改一个数据对象,任何对数据对象的修改都将在起源图中创建一个新的节点。图1中H1,H2,…,Hn等节点分别表示一个作业对象在不同时段的快照;R1和R2是作业对象的快照Hn的评语;G1是作业对象Hn的成绩。六边形则表示控制或影响处理过程的人员。图1中 S1是上传作业的学员;S2和S3是评阅作业的学员;P1是为作业评分的讲师。起源图中的边表示实体之间的依赖关系。每条有向边的起点在一定程度上依赖于其终点,即终点表示起点的部分起源信息。例如,图1中边〈H1,upload〉的标签g表明作业H1是由上传过程所产生的;边〈upload,S1〉的标签c表明上传过程upload是由学员S1控制的。

Figure 1　Provenance graph of OTS 图1　OTS起源数据示意图

注意，除单个边所表示的直接起源依赖语义之外,起源图中的某些路径也可能具有间接的起源依赖语义。例如,从Hn到H1的路径表示Hn源自H1,即H1,H2,…,Hn-1均是Hn的历史版本;G1到S2的路径表明作业的成绩G1在一定程度上取决于学员S2。注意起源图中的路径并不都具有起源语义。例如一个处理过程 p 生成了数据对象 a之后再使用数据对象 b生成数据对象c。尽管起源图中存在路径(a,p,b),但此路径却并不能表示a与b之间存在起源依赖关系。为了保护和使用具有起源语义的路径,必须显式地标示它们,使之区分于其它路径。

传统的访问控制模型通常依据访问主体及被保护对象的属性制定访问控制决策,最终允许或拒绝访问请求。而基于起源的访问控制模型PBAC(Provenance-BasedAccessControl) 则利用被保护的数据对象的起源信息做出访问控制决策。图2给出了一个基本的PBAC模型[13]。

Figure 2　Core PBAC model [13] 图2　基本的PBAC模型 [13]

AU (ActingUser) 表示发起请求的用户或用户代理。

A(Actions) 表示用户针对被访问对象执行的动作。

O(Objects) 表示被访问的对象集合。

访问请求 (au,a,o) 由活动用户、动作和被访问对象集合构成。

PD(ProvenanceData) 是被访问对象的起源信息。

DL(DependencyList) 是由若干对依赖名 (DependencyName) 和依赖路径模式 (DependencyPathPattern) 构成的列表。每个依赖名对应一个依赖路径模式。依赖路径模式实际上是针对起源图的查询语句模板。例如,在OTS中,作业提交之前可以被修改任意多次,则从作业的某个版本Hk(k=2,3,…n-1) 到作业的最初版本之间的路径符合如下模式:

(g,replace,u,Hw)*(g,upload,u)

其中，wasDerivedFrom是依赖名；而g、u是边类型；upload和Hw是节点类型；“*”是正则表达式运算符,表示在其之前出现的括号内容可出现任意多次。

抽象的依赖路径模式中的节点类型和边类型可实例化为起源图中的具体节点和边。这些通过实例化得到的节点和边与指定的起点和终点一起构成起源图中的起源依赖路径,表示起点与终点之间的起源依赖关系。例如,图1中 (Hn-1,wasDerivedFrom,H1) 和 (Hn-2,wasDerivedFrom,H1) 是两条路径,分别表示起点Hn-1、Hn-2与终点H1之间的起源依赖关系。依赖名在字面上体现路径的起点和终点之间的起源依赖语义.

P (Policies) 包含一系列起源感知的访问控制策略。每条策略是由一个或多个谓词通过逻辑运算符连接而成的一阶逻辑公式[18]。PBAC策略中的谓词可能引用起源依赖名,这些依赖名指代起源查询语句模板,与访问请求中的访问主体和被访问对象相结合之后就得到具体的起源查询语句,能在起源图中确定具体的起源子图。谓词则判定这些起源子图是否满足给定的条件。如,若某策略要求“学员只能在作业被评分之前修改其对该作业的评语”，此策略可以形式地表示为:

allow(u,revise,{o,r})⟹path(r,wasCreateBy,u)∧

Path(o,wasGradeBy,∅)

其中，wasCreateBy是wasGradeBy的依赖名；Path(r,wasCreateBy,u)是起源图中表示作业(o)的评语(r)由学员(u)创建的依赖路径；Path(o,wasGradedBy,∅)则表示作业(o)尚未被评分,即评分人集合为空集,起源图中不存在相应的路径。显然,如何确定依赖名、保证依赖名所指代的起源依赖路径模式的正确性,是高效、正确地规约起源感知访问控制策略的关键。

评估函数(AccessEvaluation) 根据给定策略评估访问请求并返回允许或拒绝访问的决策。

3概念层起源模型

软件工程学科通常采用抽象的模型规约和管理复杂系统,以控制软件开发和维护的复杂性。本文借鉴这一思想,解决由起源图的复杂性所带来的挑战。事实上,起源图中的实体和边是系统的运行时对象以及它们之间的相互关系在不同时刻的快照。例如,作业类可实例化为多个不同的作业对象,分属不同的学员;作业对象在不同时刻的快照即对应于起源图中的制品节点。再如,上传功能可被激活为多个并行执行的系统进程,为不同的学员提供服务;进程在不同时刻的快照即对应于起源图中的加工处理节点。为在概念层次上建模和管理起源数据,明确抽象的起源数据与软件系统概念模型 (如软件需求模型和设计模型) 之间的关系,管控起源图的复杂性,本节介绍一种类型化的起源模型TPM(TypedProvenanceModel) 及与之相对应的上下文无关 (Context-free) 的建模语言。图3 是TPM的元模型,包括实体类型 (Entity) 和起源依赖类型 (Dependency),分别与起源图中表示实体的节点以及表示实体之间起源依赖关系的边相对应。

Figure 3　A meta-model of the typed provenance model 图3　类型化的起源模型的元模型

3.1实体类型

TPM中包含多种实体类型。如图4所示,TPM包含三种与应用无关的实体类型,分别是表示数据对象的制品节点 (Artifact)、表示动作的加工处理节点 (Process) 和表示人员和组织的代理节点 (Agent) 等。由这些与应用无关的实体类型还可以进一步派生出特定于应用的实体类型。例如,在OTS中,可将作业类 (Homework) 看作一个特定应用的制品类型,图1中的制品节点H1,H2,…,Hn是作业类的实例;图1中,提交 (submit) 和评阅 (review) 等加工处理节点，则是需求模型中的业务功能或者设计模型中相应类的方法的实例,即相关的业务功能或方法是特定应用的加工处理类型;图1中,S1是学员角色的一个实例,即系统中用户角色是特定应用的代理类型。

注意，起源图中特定于应用的实体类型都是需求模型和设计模型等系统概念模型中的元素,是运行时数据或加工实例在设计层的概念性表述。但是，并不是所有系统模型元素都可成为TPM中的实体类型。TPM中的系统模型元素在运行时被实例化相应的起源数据，这些起源数据是回答起源问题所必须的。开发者需分析系统需求模型和设计模型,识别这些元素,将之加入TPM模型。使用特定于应用的实体类型可在概念层次上检索和管理起源语义。如,用户可以查询哪些作业曾经被学员角色评阅过。

3.2依赖类型和组装规则

如图4所示,除实体类型之外,TPM还包括表示不同实体之间起源依赖关系的起源依赖类型。每个依赖类型封装了特定类型的实体之间可能出现的某种起源依赖语义。相关的两个实体类型分别扮演结果 (Effect) 和起因 (Cause) 等两个角色。依赖类型可形式地定义为:

其中,T是起源依赖类型的符号名称,N是T的别名。

N在字面上体现类型T的应用特定的起源依赖语义,E和C分别表示结果实体类型和起因实体类型。规定N具有唯一性,下文交替使用N或T指代一个依赖类型。可将N看作是从结果到起因的映射,即N:E→C。给定一个元素实例作为结果节点,可通过依赖类型计算其相关的起因。假设依赖类型SubmittedBy (Homework,Stud) 表示作业与学员之间的提交关系,则SubmittedBy (h1) 表示提交作业实例h1的学员集合。根据图1有SubmittedBy(h1) = {S1}。注意，上述定义明确地规定了依赖类型与实体类型的关系,即实体类型在依赖类型中扮演结果或起因。而实体类型来自软件分析和设计模型,即上述定义澄清了TPM与系统分析和设计模型之间的关系,为进一步基于软件分析和设计模型分析TPM奠定了理论基础。

TPM中的起源依赖类型可分为简单依赖类型 (PrimitiveDependency) 和复杂依赖类型 (CompositeDependency)。简单依赖类型可直接实例化为起源图中的边,而复杂依赖类型则不然。

如图3所示,TPM包括wasGeneratedBy、wasControlledBy以及Used等三类与特定应用无关的简单依赖类型以及一系列由它们所派生出来的与特定应用相关的简单依赖类型。与特定应用无关的简单依赖类型的结果实体类型和起因实体类型也与特定应用无关。例如,wasGeneratedBy关系的结果实体类型是制品 (Artifact),而起因实体则是加工处理 (Process)。而与特定应用相关的起源依赖类型的结果和起因实体类型也是特定于应用的。在特定的应用中,简单依赖类型对应于功能操作使用或产生数据或被某个用户控制的信息。

图4给出了OTS中围绕加工replace的四个简单依赖类型。表1则给出了它们的形式定义,其中UrepHwOld、GHwrep以及CrepStud等是依赖类型名。大写的首字母U (Used)、G (wasGeneratedBy)、C (wasControlledBy) 指示其派生于哪个与应用无关的简单依赖类型,下标部分则由结果实体类型和起因实体类型的缩写以及附加字符串构成。例如,在T1和T2的类型名UrepHwOld和UrepHwNew中,rep和Hw是类型缩写,Old和New则是附加字符串。附加字符串使得具有相同结果实体类型和起因实体类型的依赖类型T1和T2得以相互区分,分别表示加工replace (rep)以待替换的旧版本作业Homework (Hw) 以及用于替换的新版本作业Homework(Hw) 作为输入。通常每个加工处理类型对应于软件设计模型中的一个方法或需求模型中的一个业务操作。而相关的起因实体类型通常是方法或操作的输入参数类型,结果实体类型则是方法或操作的输出结果的类型。可根据系统模型中的接口声明自动或半自动地导出部分简单依赖类型。

Figure 4　Primitive dependencies 图4　简单依赖类型图示

除简单依赖类型之外,TPM还包括复杂依赖类型,封装那些不能由单个简单依赖类型表示的抽象的起源依赖语义,通常只能被实例化为起源图中包含多条有向边或某条有向边的逆的路径。复杂依赖类型由简单依赖类型按照一定的组装规则 (CompositionRules) 组装而成。组装规则是由依赖类型以及一系列组装算子所构成的表达式,满足一定的组装约束。下面分别介绍定义组装规则的组装算子和组装约束。

Table 1　Primitive dependencies of OTS

首先,最基本的组装算子‘·’可以连接两个依赖类型Ti和Tj得到一个 TiTj。如表2所示,复杂依赖类型T7表示作业及其上传者之间的起源依赖关系,其中upload(up) 是OTS中的上传操作,T5和T6分别表示upload创建作业对象以及upload受学员角色Stud控制。

Table 2　 Composite dependencies

第三,某些起源依赖语义可能由具有不确定长度的路径表示。路径长度的不确定性来源于某些中间加工过程的可选性。如作业被上传之后、提交之前可被替换任意多次。为建模这种情况,本文使用正则表达式运算符‘?’、‘+’以及‘*’构造复杂依赖类型。‘?’表示其前导元素出现一次或零次;‘+’表示其前导元素出现至少一次或任意多次;‘*’表示其前导元素出现零次或任意多次。表2中的复杂依赖类型T12表示作业 (Hw) 由提交过程 (sub) 产生,T13表示提交过程 (sub) 使用未提交的作业 (Hw)。T14的组装模式是一个正则表达式,表示提交的作业是经由哪些历史版本替换后得到的。

context T

invariant A.cause = B.effect

3.3一个上下文无关的类型化起源建模语言

本节总结上述类型化的起源模型的构成,给出一个上下文无关的类型化起源建模语言。如表3所示,一个TPM包含实体类型集合ET 以及起源依赖类型集合DT。每个实体类型可能是一个制品类型An、一个过程类型Pm或一个代理类型Agk。依赖类型包括简单依赖类型PDT和复杂依赖类型CDT。简单依赖类型有三种形式G〈exp〉(An,Pm)、C〈exp〉(Pm,Agk)以及U〈exp〉(Pm,An)。复杂依赖类型则由其它依赖类型通过组装算子-1、·、∨、∧、?、+、*等组装而成。

Table 3　A context-free typed provenance modeling language

4访问控制策略分析方法

TPM在概念层次上建模了系统将捕获的起源数据及其能验证的起源语义。本节给出一个基于软件概念模型 (UML模型) 分析并建立TPM模型,进而利用TPM模型分析和规约起源感知的访问控制策略的方法。

如图5所示,实线矩形表示活动;箭头表示控制流;虚线圆角矩形表示由某些活动构成的子过程;两个无填充的圆角矩形表示需求分析活动和体系结构设计活动;有填充的虚线圆角矩形表示使用TPM模型定义访问控制策略的活动,相关活动贯穿需求分析和体系结构设计等两个阶段。下面概要介绍过程中的每个活动及相关制品。

Figure 5　A process for analyzing PBAC policies 图5　一个起源感知访问控制策略分析过程

(1)识别场景,建立需求模型。可用通用的需求分析方法识别目标系统中的场景。每个场景描述具有某种组织角色 (actor,如OTS 中的学员和讲师) 的用户在特定条件下(conditions) 针对系统对象(objects) 执行某项操作 (operation) 时与系统交互的过程。从场景中可以得到如〈actor,operation,objects,conditions〉的元组集合。根据系统采用的访问控制模型,一些访问条件可被识别为访问控制需求,而其它访问条件则作为功能需求的一部分。注意起源感知系统包含一些数据溯源场景[4]。这些场景的操作是查询数据对象的起源,而相关访问条件则往往涉及起源,这些场景是识别起源类型以及起源感知的访问控制策略的重要依据。

(2)识别实体类型和依赖类型,创建TPM初始模型。通过分析每个数据溯源场景,识别出一组数据对象,在软件设计过程中捕获这些数据对象的起源数据,保证使用这些起源信息能够回答溯源场景中的起源问题。同时，识别与这些数据对象相关的角色 (actors) 和操作 (operation),然后将他们定义为TPM中的实体类型。根据需求模型分析数据对象、操作以及与角色之间的关系,定义回答起源问题必需的依赖类型,给出依赖类型的形式定义,并选择恰当的依赖类型名，尽可能在字面上体现特定应用的起源依赖语义。注意本阶段属于需求分析阶段,此时识别的依赖类型往往是携带抽象起源依赖语义的复杂依赖类型,开发者仅能确定它们的名称以及相关的实体类型,而与之相关的组装规则只能推迟到设计阶段才能确定。

(3)识别起源感知的访问控制需求。基于场景以及TPM初始模型,可以识别并规约起源感知的访问控制需求。一方面,一些起源数据本身是敏感信息;另一方面,一些场景涉及的某些访问条件可使用数据起源加以验证。注意在使用起源数据验证场景访问条件的过程中可能引入新的起源依赖类型 (没有在第(2)步中被识别出来),即此活动与上一阶段的活动可能发生迭代。这些新起源依赖类型不直接用于回答用户的数据溯源问题,而只作为系统制定访问控制决策的部分依据。新起源依赖类型的出现说明起源感知的访问控制需求分析影响起源感知系统的体系结构设计。这一事实进一步说明了结合起源感知系统的开发过程识别和规约起源感知的访问控制需求的必要性和合理性。

(4)设计软件体系结构模型。软件体系结构设计就是将需求分配到不同的构件并定义构件之间的连接。每个构件提供一组公共接口供其它模块使用。多个构件通过接口相互连接在一起构成整个软件体系结构。接口包含一组方法。本文认为构件的接口方法是定义简单依赖类型的最小单元。例如,根据Homework类的replace方法 (见图6) 可得出图4中的简单依赖类型。软件体系结构通常包含多个视图,本文使用UML模型中的类图和状态图分别建模系统的静态结构和动态行为,并将它们作为精化TPM模型、识别简单依赖类型、定义与复杂依赖类型相关联的组装规则及组装约束的依据。

(5)精化实体类型和依赖类型,完善TPM模型。首先,识别UML类图中与需要捕获其起源数据的数据对象对应的类,精化TPM初始模型中的实体类型,得到一系列特定于应用的实体类型。包括特定应用的制品类型、加工类型以及代理类型等。其次,根据类图中给出的方法签名导出简单依赖类型并在必要时补充相关的实体类型,根据状态图定义相关的组装约束。最后,将每个复杂依赖类型映射为一系列简单依赖类型的组装表达式,并使之满足预定义的组装约束。这些映射是允许访问控制实施框架使用起源图评估由复杂依赖类型定义的访问控制策略的关键。

(6)精化并验证起源感知的访问控制策略。基于第(5)步精化得到的TPM模型,精化第(3)步定义的每个访问控制需求,形式地定义访问控制策略并验证其一致性。

注意，本文所给出的方法本身并不保证访问控制策略的完整性和正确性,这往往依赖于开发者的经验。除此之外,根据软件体系结构模型自动导出简单依赖类型以及形式化地描述和自动验证访问控制策略的正确性的工具仍有待进一步研究和实现。

5案例研究

本节结合OTS系统说明4.1节给出的基于UML模型的起源感知访问控制策略分析过程。

步骤1识别场景。识别并规约系统的使用场景是最基本的软件需求分析活动,有很多成熟的方法和工具供开发者选用。本文不深入讨论如何识别和规约场景,而只给出分析的结果。根据2.1节给出的OTS需求,得到如表4所示的场景列表,其中每一行代表一个场景。场景1～5是一般需求,场景6～8是数据溯源需求。

步骤2识别实体类型和依赖类型,创建TPM初始模型。基于表4中的数据溯源场景6～8,可知OTS需要记录三类数据对象的起源,包括作业 (Homework)、评语 (Review) 以及成绩 (Grade)。从这三类数据对象出发,考察相关的操作和角色,可以得到如表5所示的OTS实体类型列表。

Table 5　A list of entity types of OTS

表5中AG表示代理类型;AT表示制品类型;PT表示加工类型。表5中大多数加工的含义均在2.1节有所介绍,而queryprov操作用于查询作业、评语或成绩等制品的起源。

表6给出了回答数据溯源问题6～8所需的起源依赖类型及其语义的简要描述。表6中的大部分类型都在第3节有所介绍。第2及第3个依赖类型分别表示加工grade(grd) 使用作业和评语作为输入。表6还给出了依赖类型与数据溯源场景的映射关系。

Table 6　Dependency types of OTS

步骤3识别起源感知的访问控制需求,进一步完善TPM模型。分析表4场景列表中的访问条件,识别起源感知的访问控制需求。首先,根据数据溯源场景6～8识别保护敏感起源的访问控制需求C1和C10。其中C1要求查阅作业评阅及评分状态的用户只能是拥有该作业的学员本人,C10则要求查阅某个评语是否被用于评分过程的用户必须是提交该评语的评阅人。其次,分析其它场景的访问条件,发现访问条件C1～C8也与作业及评语的起源相关,即与作业以及评语的演变历史信息相关。因此，相应的访问控制需求也能够实现为起源感知的访问控制策略。将这些访问条件实现为起源感知的访问控制策略，使得管理员能够灵活地新增或调整与数据对象历史相关的访问条件。例如,管理者可以很方便地为场景3添加一个新的访问条件“已经评阅了三本作业的学员不能再评阅其它作业”。场景1则仅与用户的角色相关,不宜实现为起源感知的访问控制策略;场景8的访问条件虽仅与用户角色相关,但其所保护的对象却是数据的起源,因此也是起源感知的访问控制需求。

Table 4　A list of OTS scenarios

为验证访问条件C2、C3、C6、C7、C8及C10,需引入若干新起源依赖类型 (不在表6中),如表7的第2、5～7行所示。其中,GHwsub表示作业是加工submit的输出;ReviewOn表示评语是对某个作业的评阅结果;ReviewOf表示评语由哪个评阅者创建。表6和表7中的起源依赖类型都将影响起源感知系统的体系结构设计,即开发者需要精心设计软件体系结构以回答相应的起源问题。

Table 7　Dependency types of OTS

步骤4设计软件体系架构。基于表4中的场景以及所识别的起源类型,设计者可以定义OTS的软件体系结构模型,包括类图 (如图6所示) 和状态图 (如图7所示)。图6包含一个用户类层次结构和一个文档类层次结构。其中,作业类、评语类和成绩类等均是文档类的子类。一个用户可以拥有零到多个文档;一个作业可以有零到一个成绩和零到多个评语;一个成绩可能仅包含相关作业的一部分评语。除文档类之外,其余六个类对应于表6给出的实体类型AG和AT。文档类的每个派生类重载了文档类的方法,实现各自的业务操作。例如,方法Hw.create(…)实现了业务操作upload,而Rw.create(…)则实现了业务操作review。Grd.create(…)创建空白成绩单,而Grd.append(…)负责将相关的评语附加到成绩单中。Grd.create(…)和Grd.append(…)共同实现了Hw.Grade(…)。类方法的详细规约是识别简单依赖类型的重要依据,但为了保证模型的可读性,图6没有显式地给出类方法的详细规约。

Figure 6　Class diagram of OTS 图6　OTS类图

Figure 7　State diagram of OTS 图7　OTS状态图

图7是OTS系统中作业类的状态图。作业有六个状态：Uploaded、Submitted、Review=1、Review=2、Review=3以及Graded。上传后的作业可被替换任意次直到其被提交为止。提交后的作业可被评阅至少两次、至多三次,直到其最终被评分为止。状态图描述了作业类的行为,是识别依赖类型组装约束的重要依据。如,替换操作只能发生在作业提交之前,即组装ReplacementOn(Hw,Hw)SubmissionOn(Hw,Hw)不合法。

步骤5细化实体类型和依赖类型,精化TPM模型。基于软件体系结构模型,可进一步精化部分实体类型,特别是加工类型,根据方法签名定义简单依赖类型,根据状态图定义依赖类型组装约束,定义与表6和表7中的复杂依赖类型对应的组装规则。例如,一些被识别为加工类型的业务操作,如表5中的upload,被实现为体系结构中的Hw.create(…)方法。开发者需精化表6中的加工类型以及表6和表7中的相关简单依赖类型。假设方法Hw.create(…)以作业内容(任意长的字符串(String))为输入,以作业对象为输出,则可以导出表8所示的简单类型T20～T22。若一个业务操作最终被实现为体系结构中的多个相互调用的方法,则相应的加工类型就要被精化为多个加工类型,原来的简单依赖类型将变为复杂依赖类型。

Table 8　 Primitive dependencies

表6和表7中的复杂依赖类型可被精化为简单依赖类型的组合。例如,依赖类型OwnedBy表示作业与其所有者之间的依赖关系。设计者可以定义与复杂依赖类型对应的组装规则,来决定如何利用系统中记录的简单依赖类型验证这种关系。例如,可以规定成功执行作业类的create、replace或submit方法的用户是作业的所有者。前文将这种所有关系定义为依赖类型T17,考虑到体系结构设计完成之后,部分加工类型如上传 (upload) 和替换 (replace) 被分别精化为Hw.create和 Hw.replace,相应地构成T17的部分依赖类型,如T1～T6均需要精化。这样就可在设计体系结构的过程中将表6 和表7 中的任意复杂依赖类型精化为一系列简单依赖类型的组合。

依赖类型的组合必须满足给定约束。状态图(如图7所示) 是获取这种组合约束的重要来源。如作业在上传之后、提交之前可被修改多次,但只能在提交之后被评阅,评阅最多只能三次且最少被评阅两次之后才能被评分。如前文所述,可采用OCL形式地描述必须满足的组装约束。事实上,采用OCL描述的组装约束可在建模过程中得到自动验证,以保证所定义的复杂依赖类型满足相关的组装约束。这需要开发相应的起源模型建模工具,这是本文的下一步研究工作。

步骤6精化并验证起源感知的访问控制策略。使用表6和表7中的依赖类型以及它们的逆,可形式地定义表9中的访问控制策略,实现与起源数据相关的访问条件C1～C8以及C10。本文采用一阶逻辑形式地描述访问控制策略[18]。

Table 9　PBAC polices in OTS

表9中的u、h、g和r分别代表用户(User)、作业(Homework)、成绩 (Grade) 以及评语 (Review) 等实体类型的实例,P是表示用户u可以针对作业或者作业评语进行某种操作的谓词。每个起源依赖类型都实例化为一个从结果节点到起因节点的依赖关系,例如u∈OwnedBy(h) 表示作业h的所有者是用户u。

注意,本文是针对业务操作设计表9中的形式化访问控制策略。在实际系统中,每个业务操作将被实现为一系列体系结构构件的方法。因此，在系统实现阶段,开发者必须进一步精细化表9中的概念层访问控制策略,得到与具体构件方法相关联的实现层访问控制策略[20,21]。

6相关工作和讨论

起源数据常被用于验证数据对象的来源、自动重现实验结果等[3,4],其安全性至关重要[8]。起源数据具有迥异于传统数据的特点:一方面起源数据代表数据的历史,具有语义上的不可变性;另一方面起源数据往往呈现为复杂的有向图[8]。起源数据的特殊性导致传统的访问控制模型、策略规约语言乃至实施框架都不再适用。研究者提出了一系列起源感知的访问控制模型[10～14]。在研究起源感知的访问控制模型的过程中,研究者发现复杂的起源图导致访问控制策略规约困难,并提出了一系列静态或动态的打包技术封装访问控制策略中引用的起源数据[12～14,16]。特别地,Cadenhead T等人[12]采用正则表达式表示起源问题,Park J 等人[13,14]进一步为正则表达式的起源问题进行命名,称为依赖名,并使用依赖名规约访问控制策略,提高策略规约的效率。但是，这些工作都没有从软件开发过程的角度考察起源感知访问控制策略的分析和规约问题,没有深入探讨由正则表达式所表示的起源问题以及相应的依赖名与软件概念模型的关系。本文则引入抽象的起源模型—TPM,屏蔽底层起源图的复杂性,明确定义了TPM与系统概念模型的关系,为开发者在软件分析和设计过程中基于UML模型分析起源感知的访问控制策略提供系统化的指导。

起源感知系统通常包含起源数据采集机制、起源数据模型以及起源数据存储和查询基础设施等三个要素[22]。很多起源感知系统针对不同领域的需要采用了独特的起源数据模型[22,23]。近年来,为实现跨系统的起源数据共享,起源数据研究团体提出了一个开放起源数据模型标准OPM (Open Provenance Model)[17]。OPM体现了目前研究领域内的最大共识。OPM明确了起源数据的内涵,即影响数据最终状态的各种实体以及实体之间的因果关系。OPM还定义了诸如制品、加工和代理等与应用无关的实体类型以及wasGeneratedBy、wasControlledBy和Used等与应用无关的依赖类型。W3C扩展了OPM，在2012年6月发布了一个面向互联网应用的起源数据相关标准族——PROV-DM[24]。相对于OPM以及PROV-DM等与应用无关的开放起源模型,本文提出的TPM是对特定应用的起源数据的抽象,捕获特定应用的起源语义,更易于被领域专家和开发者所理解和操作,允许策略开发者在软件开发过程中识别、规约和精化起源感知的访问控制策略。仔细检查可以发现,本文提出的TPM与OPM兼容,是对OPM的一种扩展,以支持特定应用的开发。TPM不但包含与应用无关的起源数据基本实体类型和基本依赖类型,TPM还包括与特定应用相关的起源数据实体类型和起源依赖类型。特别地,TPM允许开发者通过组装的方式定义复杂起源依赖类型。本文给出相应的基于上下文的起源模型组装建模语言。

安全性是软件应用的一个重要质量属性。近年来,以安全软件系统开发技术、方法和工具为研究目标的安全工程已经成为软件工程学科的一个重要分支[25，26]。安全工程认为应该从软件分析和设计之初就开始分析和设计软件系统的安全性,并在整个软件开发过程中对软件安全性分析和实现给予系统化的支持。本文关注安全性的一个特殊方面——访问控制,实践了安全工程的思想。在起源感知系统的分析和设计过程中分析起源感知的访问控制策略,解决了起源数据的复杂性带来的挑战。此外,Miles S等人[5]提出了一个起源感知系统的开发方法学 (PrIMe)。PrIMe 以用例和场景 (起源问题) 作为输入,识别需要记录起源的数据对象,调整系统的体系结构,使得系统能够恰当地捕获起源数据，回答起源问题。但是，PrIMe 没有考虑如何开发起源感知的访问控制策略的问题,也没有在设计层捕获抽象的起源模型。

7结束语

数据起源与传统数据和其它元数据的不同之处在于其具有不可变性且呈现为复杂的有向图。起源图中的单个节点、边以及蕴含应用特定的起源依赖语义的子图均可用于定义访问控制策略。起源图的复杂性使得利用起源数据规约访问控制策略变得非常困难。本文采用“抽象”的方法解决起源图复杂性所带来的挑战,提出一种在软件分析和设计过程中分析和规约起源感知访问控制策略的方法。使用此方法,开发者首先基于软件的分析和设计模型,如场景列表、类图以及状态图等UML模型,建立抽象的起源模型；其次开发者进一步基于抽象的起源模型规约和精化起源感知的访问控制策略。其中起源模型是底层复杂起源图的概念抽象,是在较高抽象层次上高效地规约起源感知的访问控制策略的关键。本文采用了一个企业在线培训系统案例来说明所提出的方法。下一步工作包括在更多的案例中评估本文所提出的方法并研制TPM建模工具原型。

参考文献:

[1]Yang Fu-qing, Lü Jian, Mei Hong. Internetware architecture: An architecture centered approach[J].Sciences in China(E):Information Science,2008,38(6):1-11. (in Chinese)

[2]Mei Hong, Cao Dong-gang.Software trustworthiness:Challenges posed by the Internte[J].Communications of the CCF,2010,6(2):20-27. (in Chinese)

[3]Muniswamy-Reddy,Kiran-Kumar.Foundations for provenance-aware systems [D]. Cambridge,Massachusetts:Harvard University,2010.

[4]Buneman P, Khanna S, Tan W C. Data provenance: Some basic issues[C]//Proc of the 20th Conference on Foundations of Software Technology and Theoretical Computer Science,2000:87-93.

[5]Miles S, Groth P, Munroe S, et al. PrIME:A methodology for developing provenance-aware applications [J]. ACM Transactions on Software Engineering and Methodology,2011,20(3):1-42.

[6]Shen Zhi-hong,Zhang Xiao-lin. Data provenance model in semantic web environment-An overview [J]. New Technology of Library and Information Service,2011 (4):1-8.(in Chinese)

[7]Li Bin, Wang Yi-fei, Pei Ji-sheng, et al. Business process checking based on provenance data [J]. Journal of Tsinghua University (Science and Technology),2013,53(12):1768-1776.(in Chinese)

[8]Braun U,Shinnar A,Seltzer M. Secure provenance[C] //Proc of the 3rd USENIX Workshop on Hot Topics in Security Berkeley,2008:1-5.

[9]Hasan R, Sion R, Winslett M. Introducing Secure provenance:Problems and challenges[C] //Proc of the 2007 ACM Workshop on Storage Security and Survivability(StorageSS’07),2007:13-18.

[10]Braun U,Shinnar A. A security model for provenance[R]. Technical Report TR-04-06.Cambridge:Harvard University,2006.

[11]Ni Q,Xu S,Bertino E,et al. An access control language for a general provenance model[C]//Proc of SDM ’09,2009:68-88.

[12]Cadenhead T,Khadilkar V. A language for provenance access control[C]//Proc of CODASPY ’11,2011:133-144.

[13]Park J,Nguyen D,Sandhu R. A provenance-based access control model [C]//Proc of the IEEE 10th Annual Conference on Privacy,Security and Trust,2012:1.

[14]Nguyen D,Park J,Sandhu R. Dependency path patterns as the foundation of access control in provenance-aware systems[C]//Proc of TAPP ’2012,2012:1.

[15]Sandhu R,Samarati P. Access control:Principle and practice [J]. IEEE Communications Magazine,1994,32(9):40-48.

[16]Syalim A,Hori Y,Sakurai K. Grouping provenance information to improve efficiency of access control [C]//Proc of the 3rd International Conference and Workshops on Advances in Information Security and Assurance,2009:51-59.

[17]Moreau L,Clifford B,Freire J,et al. The open provenance model-core specification (v1.1) [J]. Future Generation Computer Systems,2009,27(6):743-756.

[18]Halpern J Y,Weissman V. Using first-order logic to reason about policies[J]. ACM Transactions on Information System Security,2008,11(4):1-21.

[19]Richters M,Gogolla M. OCL:Syntax,Semantics,and tools[C]//Proc of Object Modeling with the OCL,2002:42-68.

[20]Sun L, Huang G, Sun Y, et al. An approach for generation of J2EE access control configurations from requirements specification[C]//Proc of QSIC’08,2008:87-96.

[21]Sun L,Huang G. Towards accuracy of role-based access control configurations in component-based systems[J]. Jounal of Systems Architecture,2011,57(3):314-326.

[22]Freire J,Koop D,Santos E,et al. Provenance for computational tasks:A survey [J]. Computing in Science and Engineering,2008,10(3):11-21.

[23]Marinho A,Murta L,Werner C,et al. Provmanager:A provenance management system for scientific workflows [J]. Concur-

rency and Computation:Practice and Experience,2012,24(13):1513-1530.

[24]Belhajjame K,B’Far R,Cheney J,et al. Prov-dm:The prov data model [R]. WD-prov-dm-20120724.W3C,2012.

[25]Fabian B,Gürses S,Heisel M,et al. A comparison of security requirements engineering methods [J]. Requirements Engineering,2010,15(1):7-40.

[26]Strembeck M. Scenario-driven role engineering [J]. IEEE Security & Privacy,2010,8(1):28-35.

参考文献：附中文

[1]杨芙清,吕建,梅宏. 网构软件技术体系:一种以体系结构为中心的途径[J]. 中国科学E辑:信息科学,2008,38(6):1-11.

[2]梅宏,曹东刚. 软件可信性:互联网带来的挑战[J]. 计算机学会通讯， 2010,6(2):20-27.

[6]沈志宏,张晓林. 语义网环境下数据溯源表达模型研究综述[J]. 现代图书情报技术,2011 (4):1-8.

[7]李斌,王艺霏,裴继升,等. 基于溯源数据的业务流程合规性检测[J]. 清华大学学报(自然科学版),2013,53(12):1768-1776.

孙连山(1977-),男,黑龙江集贤人，博士，副教授，CCF会员(E200031404M)，研究方向为非功能需求、软件体系结构和软件安全工程。E-mail:sunlianshan@sina.com

SUN Lian-shan,born in 1977,PhD,associate professor,CCF member(E200031404M)，his research interests include nonfunctional requirements,software architecture, and secure software engineering.