建筑行業(yè)企業(yè)管理系統(tǒng)

申請免費試用、咨詢電話：400-8352-114

 　　建筑行業(yè)企業(yè)規(guī)劃管理系統(tǒng)規(guī)模的不斷擴大，通常會加大系統(tǒng)權(quán)限管理的難度。權(quán)限管理方案和實現(xiàn)方法的不合理，往往會導(dǎo)致權(quán)限泛濫，或失去足夠的靈活性。本文介紹了基于項目與角色的訪問控制(P-RBAC)策略，并結(jié)合城市規(guī)劃項目，與實際業(yè)務(wù)相結(jié)合，提出了一套權(quán)限管理高效的解決方案和具體實現(xiàn)方法。通過實際生產(chǎn)應(yīng)用，證明了此方案不僅可以滿足企業(yè)信息系統(tǒng)權(quán)限管理的要求，而且使權(quán)限管理具有很高的靈活性和可操作性。

　　一、 背景及訪問控制模型分析

　　隨著城市規(guī)劃業(yè)務(wù)的發(fā)展，以前基于某個功能的應(yīng)用程序已不能滿足需要，全面化、系統(tǒng)化已成為為業(yè)務(wù)系統(tǒng)的必然趨勢。項目管理系統(tǒng)的不斷擴大，系統(tǒng)的權(quán)限管理成為一個日益突出的問題。城市規(guī)劃項目管理系統(tǒng)具有嚴格的流程控制管理，對應(yīng)的流程又具有豐富的功能。系統(tǒng)中存儲大量的規(guī)劃數(shù)據(jù)資源。合理控制眾多用戶對數(shù)據(jù)資源的訪問權(quán)限，對于保證系統(tǒng)數(shù)據(jù)的安全，明確用戶的責(zé)任，都有著重要的意義。

　　近20年來，人們在訪問控制的研究方面取得了很大成果，有許多訪問控制模型被提出來。20世紀70年代，Harrison， Ruzzo和Ullman提出了HRU模型。接著，Jones等人在1976年提出了Take-Grant模型。后來，又有著名的自主訪問控制模型(DAC)和強制訪問控制模型(MAC)提出來了。

　　隨著應(yīng)用復(fù)雜度的不斷提高，傳統(tǒng)的訪問控制(比如基于Subject-Object 的MAC 和DAC 方式)越來越顯現(xiàn)出其局限性，其幾乎靜態(tài)化的個體——資源控制已經(jīng)無法適應(yīng)復(fù)雜多變的應(yīng)用系統(tǒng)——資源的變動、人員的變動，以及系統(tǒng)/任務(wù)之間相互協(xié)調(diào)和關(guān)聯(lián)關(guān)系。在這種情況下， Ferraiolo和Kuhn在1992年提出了基于角色的訪問控制模型(role-based access control)

　　目前基于角色和基于任務(wù)訪問控制方式，被廣泛的采納?；诮巧脑L問控制(RBAC)是在自主訪問控制(Discretionary Access Control)和強制訪問控制(Mandatory Access Control)的基礎(chǔ)之上發(fā)展起來的，RBAC與訪問者的身份認證密切相關(guān)，通過確定合法訪問者的身份來確定訪問者在系統(tǒng)中對哪類資源有什么樣的訪問權(quán)限。一個訪問者可以充當(dāng)多個角色，一個角色也可以由多個訪問者擔(dān)任。每個角色與一組用戶及相關(guān)的動作相互關(guān)聯(lián)，承擔(dān)某一角色的用戶有權(quán)執(zhí)行賦予該角色的操作，對相關(guān)資源進行訪問。

　　下面我們看看常用的幾種訪問控制(Access Control)特點：

　　1、自主訪問控制(DAC)

　　優(yōu)點：所有的主體和客體都在系統(tǒng)中列舉出來，并且給予每個主客體以明確的授權(quán)?；谒袡?quán)的、客體的擁有者可以任意將該客體的訪問權(quán)限授予其他主體。

　　缺點：一個客體被授權(quán)給另一個用戶后，對該客體的復(fù)制權(quán)限就無法控制。

　　2、強制訪問控制(MAC)

　　優(yōu)點：基于管理的、所有的主體和客體都會根據(jù)實現(xiàn)定義的敏感級別進行分類。

　　MAC的一個重要目的就是保證信息的機密性和完整性。通過級別控制信息流的方向，no read-up and no write-down或Chinese Wall policy。所謂no read-up就是說：低級別的主體不能從高級別的客體中讀取信息。所謂no write-down就是說：高級別的主體不能向低級別的客體中寫入信息。以上兩點約束都是方式信息流從高級別流向低級別。從而保證信息的安全。

　　缺點：缺乏靈活性，完整的實施也比較繁瑣。

　　3、基于任務(wù)的訪問控制

　　優(yōu)點：傾向基于應(yīng)用層的控制，是一種主動式安全模型。主動式安全模型：這種安全模型，更多的從活動或任務(wù)的角度看待安全和實施的控制問題，它抽象出了一種控制機制，用于任務(wù)運行期間的管理。其同時也抽象出任務(wù)之間的一些訪問/授權(quán)關(guān)聯(lián)關(guān)系，比如只有當(dāng)任務(wù)A 被授權(quán)訪問后，任務(wù)B 才能被授權(quán)訪問。所以，在主動式的安全模型中，許可就不是一個固定的狀態(tài)，授權(quán)和許可等行為都在被不斷的監(jiān)控，許可狀態(tài)也隨著不斷的變化。在基于任務(wù)的訪問控制中，更多體現(xiàn)出授權(quán)許可狀態(tài)，以及任務(wù)與任務(wù)之間的關(guān)聯(lián)關(guān)系。其中，許可狀態(tài)則是授權(quán)許可的結(jié)果反映。

　　4、基于角色的訪問控制

　　優(yōu)點：最小授權(quán)原則;

　　策略獨立

　　基于角色的接入控制(RBAC)是超級用戶模型的替代型方案，它將超級用戶的權(quán)限分離，打包進特殊的用戶帳戶或者角色，最后按照專門個人的工作需要而分配給他們。遵守最小特權(quán)的安全原理，規(guī)定任何用戶除了為執(zhí)行他個人的工作外，不會給予他更多的特權(quán)。這樣在一定程度上可簡化授權(quán)操作。使訪問控制適應(yīng)性更強，管理者可以通過調(diào)整用戶所屬角色及角色之間的層次，靈活地控制用戶訪問資源;不僅這樣，還可以很容易地將角色與內(nèi)部人事結(jié)構(gòu)結(jié)合起來，達到簡化管理、明確責(zé)任目的。

　　二、 建筑規(guī)劃管理軟件的方案設(shè)計

　　權(quán)限管理的核心，就是對不同權(quán)限的用戶，在適當(dāng)?shù)臅r候分配對應(yīng)權(quán)限的資源。

　　一般來說，現(xiàn)在的行政管理方式都或多或少實現(xiàn)了矩陣式管理，系統(tǒng)的權(quán)限與之對應(yīng)。通常，一個項目負責(zé)人員屬于某個項目小組(部門)，這是行政范圍，但在參與項目時，又在某段時間內(nèi)屬于項目，同時擁有了項目中的權(quán)限。 項目小組(部門)中的這類對象之間一般有所屬關(guān)系，如中心、部門、小組等。對于人員參與項目來說，在項目周期中，增加了項目權(quán)限，如看項目中的文檔、建立和修改文檔等。 那么，根據(jù)以上兩種類型的分類，權(quán)限和角色也同樣分為兩類，行政上的角色是相對穩(wěn)定的，在員工入職時就可以授予，在行政調(diào)動時再修改，離職時收回。而對于項目來說，角色相對不穩(wěn)定，只是在項目的生命周期中才有該角色和權(quán)限。

　　基于角色的訪問控制(RBAC)機制由于具有較高的可擴展型和靈活性，我們結(jié)合城市規(guī)劃項目管理實際，采用RBAC機制，提出基于項目與角色的訪問控制(P-RBAC)策略?，F(xiàn)將邏輯判斷、資源和角色進行如下設(shè)計：

　　1、邏輯判斷

　　權(quán)限邏輯判斷使用五元組實現(xiàn)(角色，項目，模板，流程，條件控制[是否部門相關(guān)，通知付款相關(guān)])進行控制，其中條件控制可以根據(jù)實際的情況給出控制條件

　　2、資源分類

　　系統(tǒng)操作功能：使用菜單形式進行表現(xiàn)，在系統(tǒng)登錄的同時檢測那些菜單可以顯示來控制權(quán)限。

　　項目操作功能：在項目的操作功能區(qū)進行顯示，在用戶訪問的同時采用自主訪問方式實現(xiàn)權(quán)限的判斷。

　　3、角色類型

　　在用戶組織模型中，采用了“項目流程內(nèi)”項目角色與“跨流程全局”的系統(tǒng)角色相結(jié)合。為了便于管理和應(yīng)用，把角色按照實際情況進行分類。

　　從形式上分普通角色，實際上就是一般意義上角色。只是為了與下面的幾個角色類型區(qū)分，特意加上“普通”一詞;動態(tài)角色，項目運轉(zhuǎn)中，會依據(jù)其所屬的狀態(tài)，而分配獲取相應(yīng)的權(quán)限。

　　從應(yīng)用范圍上分項目角色，在項目流程定義的時候，才會根據(jù)項目流程的中會存在有哪些執(zhí)行人(執(zhí)行角色)來的來定義。這些角色僅僅只能在當(dāng)前項目當(dāng)前流程內(nèi)使用;系統(tǒng)角色，同一個系統(tǒng)中，可存在項目并行，對于項目流程內(nèi)的角色，各個流程之間是獨立的，透明的。例如文檔審批人員，在任何項目中候選及本上都是相同的，只是根據(jù)實際提交情況再次確認。