一種基于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.