李果，宋晶晶

（清遠(yuǎn)職業(yè)技術(shù)學(xué)院網(wǎng)絡(luò)信息中心，清遠(yuǎn) 511510）

0 引言

對信息系統(tǒng)中的敏感信息和資源的訪問進(jìn)行控制一直是信息系統(tǒng)安全的一個基本需求。訪問控制通過協(xié)調(diào)用戶或者進(jìn)程對于特定資源或數(shù)據(jù)的訪問請求，決定是否允許訪問相應(yīng)的資源或數(shù)據(jù)，從而達(dá)到限制用戶和進(jìn)程對敏感信息的訪問的目的。在傳統(tǒng)的訪問控制機制中（DAC、MAC和RBAC等），都是在用戶發(fā)出訪問請求時應(yīng)用訪問控制規(guī)則，但是在用戶得到授權(quán)后系統(tǒng)就失去了對受保護(hù)對象的控制，無法實行持續(xù)的訪問控制，也無法改變主體或者客體的屬性[1-2]。而在當(dāng)今日益復(fù)雜的、多平臺、多客戶端的環(huán)境中，對于資源和數(shù)據(jù)訪問或者使用進(jìn)行持續(xù)的控制越來越成為一個基本的需求。為了解決這一問題，人們提出了多種解決方案。UCON是由Jaehong、Ravi等提出的一種系統(tǒng)性控制數(shù)字對象使用的訪問控制方式，其具體描述方式有多種，UCONABC模型是其中比較典型的一種，包含了授權(quán)、職責(zé)和條件三個核心模型，每個模型根據(jù)訪問決策時機的不同又可分為pre和on兩種情況[3-4]。

企業(yè)數(shù)據(jù)倉庫是一個面向整個企業(yè)開放的共享的數(shù)據(jù)及應(yīng)用平臺，開放性和共享性是它所必須具備的特征。正因為如此，企業(yè)數(shù)據(jù)倉庫的安全性才顯得更加重要。如何做到開放的同時又保持安全是企業(yè)數(shù)據(jù)倉庫必須解決的重要技術(shù)問題，也是實現(xiàn)企業(yè)數(shù)據(jù)倉庫的技術(shù)難點之一。實現(xiàn)企業(yè)數(shù)據(jù)倉庫的權(quán)限控制可能有很多不同的方法，目前主流的解決方案都是基于RBAC模型建立的，能夠很好地解決數(shù)據(jù)倉庫大部分的安全需求，但是在處理一些臨時依賴和動態(tài)決策的安全需求時就顯得無能為力了。

1 相關(guān)工作

1.1 UCON模型

傳統(tǒng)的訪問控制方式缺乏一種可用于任何環(huán)境（服務(wù)器端或客戶端）的系統(tǒng)化的、一致的方式來全面控制數(shù)字對象的使用，無法很好地滿足現(xiàn)代信息安全需要。文獻(xiàn)[4]重新定義了訪問控制中的基本問題，擴(kuò)展了訪問控制的內(nèi)涵，將傳統(tǒng)訪問控制、信任管理以及數(shù)字權(quán)利管理（DRM）等三個領(lǐng)域系統(tǒng)地揉合在一起，首次提出了“使用控制（Usage Control）”的概念，并從概念上描述了一種稱之為UCON的訪問控制模型。該模型由主體、客體和權(quán)利三個核心組件構(gòu)成，并包含三個額外的組件，即授權(quán)規(guī)則、條件和職責(zé)。它是基于會話的，與傳統(tǒng)的訪問控制方式相比有兩個顯著特性：決策持續(xù)性，即客體即使分發(fā)出去后其使用仍然受到授權(quán)規(guī)則的約束；屬性可變性，即在訪問客體前、訪問客體期間或者訪問客體后能對主體或客體的屬性進(jìn)行更新。文獻(xiàn)[3]在文獻(xiàn)[4]的基礎(chǔ)上提出了一個系統(tǒng)的、具體的訪問控制邏輯模型，并根據(jù)屬性更新的時間點討論了16種基本的UCONABC模型。文獻(xiàn)[1]從有限狀態(tài)機的角度對UCON模型進(jìn)行了擴(kuò)展，將訪問狀態(tài)分離為訪問和持續(xù)檢查兩個狀態(tài)，并討論了基于該擴(kuò)展模型的原型實現(xiàn)。文獻(xiàn)[11]對屬性的外延做了擴(kuò)展，將權(quán)限自身的屬性也考慮在內(nèi)，對UCONABC模型進(jìn)行了擴(kuò)充。

1.2 數(shù)據(jù)倉庫安全

在文獻(xiàn)[10]中提出應(yīng)該建立一個統(tǒng)一的數(shù)據(jù)倉庫，而不是通過分散的多個異構(gòu)的數(shù)據(jù)集市的方式來建立，并給出了基于Oracle數(shù)據(jù)庫特性的訪問控制方式。文獻(xiàn)[5]中描述了一種基于元數(shù)據(jù)的數(shù)據(jù)倉庫安全模型，提出通過元數(shù)據(jù)來描述和管理對于數(shù)據(jù)倉庫的訪問。文獻(xiàn)[6]提出基于視圖安全來建立數(shù)據(jù)倉庫的安全。文獻(xiàn)[7]中描述了一種將RBAC模型與UCON模型結(jié)合的方法，并描述了基于這種混合模型的系統(tǒng)的總體架構(gòu)和實現(xiàn)原型。文獻(xiàn)[8]從改進(jìn)SQL的角度提出了一種用于訪問控制的形式符號，以便更好地表達(dá)數(shù)據(jù)倉庫中多維數(shù)據(jù)集的訪問控制要求。文獻(xiàn)[9]描述了一種簡單的基于UCON的數(shù)據(jù)倉庫訪問控制模型。

2 基于UCON的數(shù)據(jù)倉庫訪問控制

2.1 數(shù)據(jù)倉庫主要面臨的安全風(fēng)險

數(shù)據(jù)倉庫和其他信息系統(tǒng)一樣存在著一些共同的安全需求，例如受保護(hù)的信息和資源只有經(jīng)過認(rèn)證的用戶才能訪問，不同的用戶根據(jù)職責(zé)的不同只能訪問部分資源和信息等。同時，數(shù)據(jù)倉庫作為一個綜合了多個異構(gòu)數(shù)據(jù)源、服務(wù)于多級別、多類型用戶的決策支持系統(tǒng)，又有著自己獨特的安全需要，主要體現(xiàn)在：

（1）服務(wù)于眾多的有著不同安全需求的用戶群體，他們的安全需求之間往往存在著沖突；

（2）安全功能應(yīng)當(dāng)足夠靈活、全面，但又不至于嚴(yán)重影響系統(tǒng)性能；

（3）用戶可能根據(jù)聚合結(jié)果推導(dǎo)出底層的細(xì)節(jié)數(shù)據(jù)，從而導(dǎo)致信息泄密的問題，這種問題被稱作推斷攻擊（Inference Attack）；

（4）從數(shù)據(jù)源抓取數(shù)據(jù)時對數(shù)據(jù)倉庫數(shù)據(jù)一致性或者完整性的破壞；

（5）得到授權(quán)的用戶對數(shù)據(jù)的濫用或者誤用。

針對上述問題，傳統(tǒng)的做法是一方面是采取系統(tǒng)化的方法建立安全的數(shù)據(jù)模型，這部分內(nèi)容不在本文的討論范圍內(nèi)；另一方面采用基于角色的訪問控制模型建立數(shù)據(jù)倉庫安全模型，實現(xiàn)對于受保護(hù)對象的訪問控制。但是在這種方式下，當(dāng)用戶拿到數(shù)據(jù)后系統(tǒng)也就無法對其再進(jìn)行訪問控制；另一方面，當(dāng)提交查詢的時候，數(shù)據(jù)倉庫可能并不能一次提供查詢要求的所有數(shù)據(jù)，它必須再從后臺的異構(gòu)數(shù)據(jù)庫中獲得需要的數(shù)據(jù)，這時也涉及到訪問控制的問題，也就是說，一次查詢執(zhí)行過程中也可能存在新的授權(quán)等安全需求。

2.2 基于RBAC的訪問控制模型的不足

基于角色的訪問控制主要是從企業(yè)職責(zé)的角度來對權(quán)力和特權(quán)進(jìn)行分組、控制，對于一些臨時性的、持續(xù)性的訪問控制不能很好地進(jìn)行管理。例如，區(qū)域銷售經(jīng)理只能在每個季度的最后三天的工作時間內(nèi)查看本季度的銷售報表，且只能在辦公室內(nèi)打印該報表，最多只能打印三份。傳統(tǒng)的RBAC模型并不能很好地解決這種訪問控制需求，即使也能夠?qū)崿F(xiàn)，但是主要都是靠開發(fā)人員自己設(shè)計的方案，并沒有系統(tǒng)的解決方法。

從本質(zhì)上講，RBAC是通過將不同的角色賦予用戶來實現(xiàn)訪問控制的。每個角色都關(guān)聯(lián)一組許可，一個許可代表著對訪問對象進(jìn)行某種操作的權(quán)力，通過這種方式實現(xiàn)了用戶對對象訪問的權(quán)限控制。但是在如今人員變動頻繁、角色職責(zé)變更迅速的時代，這種訪問控制的方式的維護(hù)和管理都很麻煩。同時，針對一些臨時性的、動態(tài)依賴的訪問控制需求，RBAC也無法很好地解決。例如，有進(jìn)程在執(zhí)行過程中需要更多特權(quán)，或者一些客體在執(zhí)行過程中需要更新屬性值，例如某個用戶試圖抽取多個數(shù)據(jù)資源并且需要獲取其中某數(shù)據(jù)的授權(quán)，而在會話開始之前并沒有得到允許，則此進(jìn)程必須終止并重新啟動才行。

2.3 基于UCON的數(shù)據(jù)倉庫訪問控制模型

數(shù)據(jù)倉庫安全需求：

在數(shù)據(jù)倉庫中主要存在著以下幾類訪問控制需求：

（1）關(guān)系型數(shù)據(jù)庫的訪問

（2）OLAP數(shù)據(jù)庫的訪問

（3）企業(yè)數(shù)據(jù)倉庫中采用的其他工具軟件（如報表工具等）的權(quán)限

（4）應(yīng)用系統(tǒng)的訪問

（5）管理權(quán)限

上述五種權(quán)限的前三種和具體的產(chǎn)品相關(guān)，第四種和應(yīng)用系統(tǒng)的統(tǒng)一管理相關(guān)，而最后一種則規(guī)定了該角色是否具有管理者的權(quán)限。

在本小節(jié)中我們將提出一個我們認(rèn)為是完整的和可實現(xiàn)的企業(yè)數(shù)據(jù)倉庫訪問控制模型，并在下一小節(jié)中討論該模型的具體實現(xiàn)。我們所要建立的訪問控制模型以RBAC為基礎(chǔ)，對授權(quán)規(guī)則進(jìn)行擴(kuò)展，在進(jìn)行授權(quán)決策時不僅考慮用戶關(guān)聯(lián)的角色，同時還考慮用戶和被訪問對象的屬性，并在授權(quán)決定這一環(huán)節(jié)交由UCON組件來負(fù)責(zé)，從而實現(xiàn)一個可動態(tài)授權(quán)的、基于屬性的訪問控制模型。

訪問控制模型：

建立模型的基本考慮：

（1）建立企業(yè)數(shù)據(jù)倉庫中的用戶、用戶組和角色等基本概念，并規(guī)定整個企業(yè)數(shù)據(jù)倉庫的權(quán)限分配機制。

（2）定義企業(yè)數(shù)據(jù)倉庫中的各種操作和要進(jìn)行訪問控制的對象。企業(yè)數(shù)據(jù)倉庫中的操作一般來講可分為兩類，一類是常規(guī)的系統(tǒng)操作，包括工具的使用、應(yīng)用的訪問和管理等；一類是和數(shù)據(jù)倉庫特定相關(guān)的操作，包括數(shù)據(jù)的鉆取、切片、數(shù)據(jù)源的數(shù)據(jù)抓取等。要進(jìn)行訪問控制的對象也可相應(yīng)地分為工具、應(yīng)用等常規(guī)對象和數(shù)據(jù)項、維度和事實等數(shù)據(jù)倉庫特有的對象。

（3）根據(jù)定義的操作和對象定義可施加在每一個對象上的操作的集合，并根據(jù)需要定義進(jìn)行相應(yīng)操作時應(yīng)履行的職責(zé)和滿足的條件，以及訪問前、訪問中或者訪問后應(yīng)該更新的屬性。

（4）為每個企業(yè)數(shù)據(jù)倉庫用戶規(guī)定權(quán)限。這一過程一般是通過將包括角色在內(nèi)的各種屬性賦予企業(yè)數(shù)據(jù)倉庫用戶/用戶組和對象來完成的。這樣在授權(quán)時將用戶/用戶組的屬性與對象的屬性根據(jù)授權(quán)規(guī)則進(jìn)行對比計算即可。

必須要指出的是，和常規(guī)的RBAC模型只根據(jù)用戶的角色屬性進(jìn)行授權(quán)不同，在我們這個模型中，授權(quán)時除了考慮角色這一屬性之外還會考慮其他屬性，以及相應(yīng)的要履行的職責(zé)和滿足的條件，并有可能在訪問前、訪問中或訪問后對用戶或者對象的某些屬性進(jìn)行更新，更具有動態(tài)性和靈活性。

數(shù)據(jù)倉庫訪問控制模型的定義：

定義1基本組件

ACModel={S，ROLE，R，OR，O，F(xiàn)，D，L，A，B，C，ATTR(S)，ATTR(O)，preA，preB，onB，preC，onC}

其中：

S：用戶集合

ROLE：角色的部分有序集合，定義了關(guān)系≥

R：除去OLAP之外的其他操作

OR：OLAP 操作

O：要進(jìn)行訪問控制的對象（不包括事實、維度等數(shù)據(jù)倉庫特有對象）

F：數(shù)據(jù)倉庫中的事實

D：數(shù)據(jù)倉庫中的維度

L：維度的層次的集合

A：授權(quán)

B：職責(zé)

C：條件

ATTR（S）：用戶屬性的集合

ATTR（O）：對象屬性的集合

preA，onA，preB，onB，preC，onC：分別代表訪問前授權(quán)決策、訪問中授權(quán)決策、訪問前職責(zé)履行檢測、訪問中職責(zé)履行檢測、訪問前條件檢查、訪問中條件檢測。

定義2數(shù)據(jù)倉庫操作基本定義

OR={read，drill-down，roll-up，drill-through，slice，audit}DH：D→2L，表示一個維度到對應(yīng)的維度層次的映射

PT：S×F→2D×DH×OR，表示一個用戶對一個事實到對應(yīng)的維度和維度層次能進(jìn)行的操作的映射

定義3基本訪問控制

sRole：S→2ROLE

oRole：O → 2ROLE

actRole：O → 2ROLE

ATTR(S)={sRole，actRole}

ATTR(O)={oRole}

ATTR(F)={2D}

allowed(S，O，R)→ actRole(S)?oRole≠?，

preA(ATTR(s)，ATTR(O)，R)

allowed(S，F(xiàn)，D，OR)→actRole(S)?oRole≠?，

preA(ATTR(s)，ATTR(O)，R)

定義4訪問期間授權(quán)

除了定義3之外，還包括以下規(guī)則：

onA（持續(xù)授權(quán)檢測）

allowed(S，O，R)→ true

allowed(S，F(xiàn)，D，OR)→true

stopped(S，O，R)→ ?onA(ATTR(S)，ATTR(O)，R)

stopped(S，D，F(xiàn)，OR)→ onA(ATTR(S)，ATTR(F)，D，OR)

定義5訪問前和訪問中職責(zé)檢查

除了定義4之外，還包括以下規(guī)則：

OBS→職責(zé)主體

OBO→職責(zé)對象

OB→要履行的職責(zé)

preOBL?OBS×OBO×OB

preFulfilled：OBS×OBO×OB→{true，false}

getPreOBL：S×O×R→2preOBL

getPreOBL：S×F×D×OR→2preOBL

preFulfilled(getPreOBL(S，O，R))

preFulfilled(getPreOBL(S，F(xiàn)，D，OR))

allowed(S，O，R)→ onFulfilled(getOnOBL(S，O，R))

allowed(S，F(xiàn)，D，OR)→ onFulfilled(getOnOBL(S，F(xiàn)，D，OR))

定義6訪問前和訪問中條件檢測

除了定義5之外，還包括以下規(guī)則：

preCON(條件元素集合)

getPreCon：S×O×R→2preCON

getPreCon：S×F×D×OR→2preCON

preConChecked：preCON →{true，false}

preC(S，O，R)= ∧preCon∈getPreCON(S，O，R)preConChecked(preCon)

preC(S，F(xiàn)，D，OR)= ∧preCon∈getPreCON(S，F(xiàn)，D，OR)preConChecked(preCon)

allowed(S，O，R)→ preC(S，O，R)

allowed(S，F(xiàn)，D，OR)→ preC(S，F(xiàn)，D，OR)

onCON(條件元素集合）

getOnCON：S×O×R→2preCON

getOnCON：S×F×D×OR→2preCON

onConChecked：onCON →{true，false}

onC(S，O，R)= ∧onCon∈getPreCON(S，O，R)onConChecked(onCon)

onC(S，F(xiàn)，D，OR)= ∧onCon∈getPreCON(S，F(xiàn)，D，OR)onConChecked(onCon)

allowed(S，O，R)→ onC(S，O，R)

allowed(S，F(xiàn)，D，OR)→ onC(S，F(xiàn)，D，R)

原型實現(xiàn)：

本文所討論的訪問控制模型是以RBAC為基礎(chǔ)建立的，但是與單純的RBAC不同的地方主要有兩點，一是在決策考慮范圍上進(jìn)行了擴(kuò)展，進(jìn)行授權(quán)決策時不僅考慮到用戶所關(guān)聯(lián)的角色，還包括了用戶和所訪問的資源的屬性；二是在處理一次請求時整個授權(quán)決策過程是動態(tài)的，可根據(jù)屬性和環(huán)境進(jìn)行靈活的動態(tài)決策，而不像RBAC一樣，在一次請求中一旦角色確定了所關(guān)聯(lián)的權(quán)限也就固定了。在實現(xiàn)該訪問控制模型時主要需要考慮以下幾個問題：

（1）對于用戶請求的授權(quán)決策是以會話為基礎(chǔ)的，即權(quán)限的授予是在一次會話開始后，隨著會話的結(jié)束而結(jié)束，因此需要在處理請求時要對會話進(jìn)行管理；

（2）由于在授權(quán)決策時不僅會考慮用戶的角色屬性，還會需要用戶和資源的屬性信息，因此應(yīng)該有專門的組件來管理用戶和資源的屬性；

（3）授權(quán)的決策和授權(quán)實際上是兩個獨立的過程，授權(quán)的決策主要負(fù)責(zé)的是根據(jù)策略對用戶請求做出處理，決定該請求是否符合對應(yīng)的授權(quán)規(guī)則，而授權(quán)則是權(quán)限的賦予，它根據(jù)授權(quán)決策的結(jié)果來決定是允許請求還是拒絕。

（4）由于訪問策略中可能會包含用戶和資源的屬性、條件以及職責(zé)，需要一種合適的表達(dá)方式來描述，并能根據(jù)具體應(yīng)用的需要對表達(dá)方式所能描述的內(nèi)容進(jìn)行擴(kuò)展，同時還要好能很好地實現(xiàn)ABAC和UCON的語義。XACML（Extensible Access Control Markup Language）即可擴(kuò)展的訪問控制標(biāo)記語言，是一種聲明式的訪問控制策略語言，以XML的形式表示。它鼓勵將使用點與訪問決策點隔離開來，即將對資源的使用抽象為一個操作，將對這個資源的使用的決策過程抽象為另一個操作，這符合我們邏輯模型的設(shè)計。它已經(jīng)實現(xiàn)了ABAC的語義，我們只需要再對其進(jìn)行擴(kuò)展，實現(xiàn)UCON的語義即可。

（5）在我們的設(shè)計中，將是否允許請求的執(zhí)行（執(zhí)行點）與進(jìn)行授權(quán)決策（決策點）分離為兩個不同的點，即執(zhí)行點接收到請求后只是簡單地將其轉(zhuǎn)發(fā)給決策點，自身并不進(jìn)行任何判斷，決策點負(fù)責(zé)根據(jù)授權(quán)規(guī)則進(jìn)行決策，并將決策結(jié)果返回給執(zhí)行點，讓其根據(jù)決策結(jié)果決定下一步的操作。因此在實現(xiàn)中需要將用戶的請求單獨抽象為一個對象，考慮到采用XACML來描述訪問策略，我們在實現(xiàn)層面執(zhí)行點應(yīng)當(dāng)先將用戶的請求轉(zhuǎn)換為XACML再轉(zhuǎn)發(fā)給決策點，決策點將決策的結(jié)果也以XACML的形式發(fā)回給執(zhí)行點，再由執(zhí)行點對其進(jìn)行處理。

（6）執(zhí)行點與決策點的實現(xiàn)。執(zhí)行點需要對每一個用戶請求都進(jìn)行檢查和轉(zhuǎn)發(fā)，因此它應(yīng)當(dāng)以全局?jǐn)r截的方式來實現(xiàn)；而決策點深入到具體方法執(zhí)行上，需要進(jìn)行更為精細(xì)的控制，執(zhí)行頻率非常高，涉及的決策邏輯也比較復(fù)雜，因此在實現(xiàn)時必須考慮到其帶來的影響。

（7）其他考慮。在我們的訪問控制模型中，有可能根據(jù)策略需要進(jìn)行持續(xù)的條件檢查和屬性更新，一般來講有兩種實現(xiàn)方式，一是基于時間，即每隔一定的時間進(jìn)行檢查或更新，另一種是基于事件，即當(dāng)某事件發(fā)生時進(jìn)行檢查或者更新。事實上基于時間的實現(xiàn)方式可以看做是基于事件的一種特殊實現(xiàn)方式，即當(dāng)?shù)搅艘欢〞r間即視作發(fā)生了一件事情，因此在實現(xiàn)中應(yīng)當(dāng)選用更靈活的基于事件的實現(xiàn)方式；另外，由于我們的訪問控制模型主要是應(yīng)用在數(shù)據(jù)倉庫環(huán)境中，絕大部分操作最終都會歸于對數(shù)據(jù)庫數(shù)據(jù)的讀寫和過濾操作，因此在實現(xiàn)訪問控制時必須進(jìn)行充分考慮，以避免對性能造成大的影響。我們專門實現(xiàn)了一個SQL語句解析和轉(zhuǎn)換組件，當(dāng)訪問控制判斷涉及到SQL語句時負(fù)責(zé)對SQL語句進(jìn)行解析和過濾，并根據(jù)授權(quán)策略進(jìn)行判斷，只返回得到授權(quán)的數(shù)據(jù)。

整個系統(tǒng)的實現(xiàn)架構(gòu)如圖1所示。

3 結(jié)語

本文首先討論了數(shù)據(jù)倉庫安全中的主要問題，并以基于角色的訪問控制（RBAC）模型為基礎(chǔ)，根據(jù)基于屬性的訪問控制（ABAC）對該模型進(jìn)行了擴(kuò)展，并將實際的授權(quán)決策過程交由UCON組件來執(zhí)行，從而建立了一個新的數(shù)據(jù)倉庫安全模型；隨后我們給出了該安全模型包含的主要組件以及其形式定義，最后討論了基于該模型的原型系統(tǒng)的實現(xiàn)。

訪問控制模型實際上包含了訪問控制和訪問控制管理兩部分的內(nèi)容，本文主要討論了訪問控制方面的內(nèi)容，沒有涉及訪問控制管理方面的問題。另外，在本文所提出的安全控制模型中，對數(shù)據(jù)庫的每次查詢都會進(jìn)行SQL語句的過濾和轉(zhuǎn)換，在實際中對系統(tǒng)的性能是個極大的考驗，如何優(yōu)化SQL解析過濾器，不使其成為系統(tǒng)性能的瓶頸是需要認(rèn)真考慮的一個問題。

圖1 系統(tǒng)實現(xiàn)架構(gòu)