一種基于角色訪問控制模型的設(shè)計與實現(xiàn)

雷驚鵬

（安徽國防科技職業(yè)學(xué)院信息技術(shù)學(xué)院，安徽 六安 237011）

Web服務(wù)是互聯(lián)網(wǎng)提供的主要服務(wù)類型之一。用戶需求的多元化和技術(shù)的不斷演進(jìn)，使Web站點所提供的內(nèi)容類型日趨豐富，由此帶來的諸如計算、存儲、網(wǎng)絡(luò)等資源要求也更加嚴(yán)格。Web站點的架構(gòu)越來越多地采用復(fù)雜的集群環(huán)境。在此背景下，快速而有效地實施項目開發(fā)、運維、管理，也變得更加困難。近年來，隨著云計算技術(shù)的發(fā)展、成熟，業(yè)務(wù)系統(tǒng)可以被遷移到云平臺，以此減輕開發(fā)和運維人員的壓力。在業(yè)務(wù)系統(tǒng)的遷移過程中，應(yīng)首要考慮安全問題。內(nèi)容提供商注重數(shù)據(jù)隱私的保護(hù)，而云平臺提供商則具有自身的安全規(guī)則，二者之間需要找到合適的平衡點才能發(fā)揮出最好的效果。

為了限制訪問者（例如用戶、服務(wù)等）對被訪問者（資源）的訪問權(quán)限，避免因為越權(quán)、誤操作等帶來的數(shù)據(jù)風(fēng)險，對業(yè)務(wù)系統(tǒng)進(jìn)行合理、合適的權(quán)限配置，是一項必要的工作。訪問控制一般包含兩個主要過程，即“鑒別”（Authentication）和“授權(quán)”（Authorization），前者用以檢驗訪問主體身份的合法性，后者用以設(shè)置對資源的訪問能力。

1 訪問控制系統(tǒng)及其模型

訪問控制技術(shù)是保證Web服務(wù)組合增值應(yīng)用安全性和可靠性的關(guān)鍵技術(shù)［1］，也是實現(xiàn)保密性、完整性的主要方式。對權(quán)限訪問控制技術(shù)的研究可追溯到20世紀(jì)70年代，其主要思想是對用戶設(shè)置必要的系統(tǒng)資源訪問權(quán)，讓合法用戶可以訪問并且只能訪問被授權(quán)的資源，并拒絕非法用戶的訪問企圖，從而保障數(shù)據(jù)安全。一個完整的訪問控制系統(tǒng)，包括“主體”“客體”“策略”三個主要元素［2］。其中，主體作為可直接訪問系統(tǒng)的實體，以進(jìn)程為主要形式，也可以是用戶或其他子系統(tǒng)；客體通常是資源對象，是可被訪問的被動實體，典型的客體形式是存放在系統(tǒng)中的各類數(shù)據(jù)資源；策略是一組行為規(guī)則集，用來描述主體如何訪問客體，代表特定的授權(quán)行為。

由于可以對訪問者的身份進(jìn)行有效鑒別以防止非法訪問，訪問控制被廣泛應(yīng)用于各種業(yè)務(wù)系統(tǒng)的登錄過程。目前學(xué)術(shù)界對訪問控制的研究將權(quán)限管理分為系統(tǒng)權(quán)限和數(shù)據(jù)權(quán)限，前者適用于系統(tǒng)級別的權(quán)限管理，如操作系統(tǒng)權(quán)限、數(shù)據(jù)庫系統(tǒng)訪問權(quán)限等，后者一般根據(jù)具體的業(yè)務(wù)需求來進(jìn)行設(shè)置。從實施的角度分類，訪問控制采用的三種典型模型分別是MAC模型（Mandatory Access Control，強制訪問控制）、DAC模型（Discretionary Access Control，自主訪問控制）、RBAC模型（Role-Based Access Control，基于角色的訪問控制）。三種模型的對比如表1所示。

表1 訪問控制模型對比

1.1 MAC模型

MAC模型對惡意程序攻擊（比如木馬程序）具有一定的防護(hù)能力，最早由美國軍方于20世紀(jì)70年代提出。

MAC模型為每個主體和客體賦予一個固定的安全屬性（見圖1）作為標(biāo)記安全的特征，并根據(jù)此特征確定主體對客體的訪問權(quán)。訪問控制遵循兩個基本原則以實現(xiàn)數(shù)據(jù)的機密性：一是“上寫”原則，主體只能寫入安全等級大于該主體安全等級的客體；二是“下讀”原則，主體只能讀取那些安全等級小于該主體安全等級的客體［3］。

圖1 MAC模型

在MAC模型的實現(xiàn)上，D.Elliott Bell和Leonard J.LaPadula在1973年 提 出 了Bell-LaPadula模型（簡稱BLP模型）［4］，用來設(shè)定安全級別。盡管BLP安全模型在單向傳輸系統(tǒng)機密性的問題上提供了有效的解決措施，但其缺少對數(shù)據(jù)傳輸可靠性的保障，具有一定的局限性。

1.2 DAC模型

DAC模型允許用戶針對客體制定個性化保護(hù)策略。該模型為每個主體設(shè)置一個用戶名（用戶隸屬于用戶組或具有特定的角色）。主體可以針對客體設(shè)置ACL（Access Control List，訪問控制列表），該ACL用于在每次訪問發(fā)生時檢查用戶標(biāo)志，并根據(jù)標(biāo)志定義實現(xiàn)權(quán)限控制。

DAC模型允許資源所有者將自身擁有的權(quán)限授予其他用戶。一方面,這一特征使主體能對不同客體設(shè)置不同的訪問權(quán)限，另一方面，不同的主體也可以對同一客體設(shè)置不同的訪問權(quán)限。

1.3 RBAC模型

RBAC模型使用戶角色（Role）與訪問權(quán)限關(guān)聯(lián)。根據(jù)用戶角色決定用戶在系統(tǒng)中的訪問權(quán)限，以便實施授權(quán)和安全約束。該模型通過增加角色這一概念，將權(quán)限與角色之間、角色與用戶之間建立關(guān)聯(lián)，提高了授權(quán)的靈活性，更容易實現(xiàn)權(quán)限的最小化原則，以及職責(zé)分離等各種安全策略。

在眾多研究中，以美國喬治梅森大學(xué)信息安全技術(shù)實驗室（LIST）提出的RBAC96模型簇最具代表性［5］，其包括從RBAC0到RBAC3的四個概念性模型，RBAC0模型是核心部分，也是其他模型建立和改進(jìn)的基礎(chǔ)。RBAC0模型中的權(quán)限分配有用戶與角色的分配、角色和權(quán)限的分配兩種最基本的分配關(guān)系（見圖2）［6］。

圖2 RBAC0模型

以RBAC0為基礎(chǔ)并將繼承的概念引入角色中，可形成RBAC1。它將角色實施了進(jìn)一步劃分，形成不同的等級，且每個等級的權(quán)限有所區(qū)別，通過這種方式實現(xiàn)權(quán)限的細(xì)化。

RBAC2同樣建立在RBAC0的基礎(chǔ)上，但是添加了權(quán)限、角色和用戶之間的限制，這種限制被稱作“責(zé)任分離”，包括動態(tài)責(zé)任分離和靜態(tài)責(zé)任分離（見表2）。而由RBAC1和RBAC2整合而成的RBAC3則適用于對權(quán)限要求非常高的系統(tǒng)，既具有RBAC1的角色特征，也具備RBAC2的各種限制。

表2 RBAC2責(zé)任分離特征

通過以上對不同權(quán)限控制模型的分析和比較，不難看出，RBAC模型通過靈活的角色映射機制，在很大程度上提升了系統(tǒng)的可擴展性，降低了管理上的復(fù)雜性。該模型在分配權(quán)限時，遵循三條最基本的安全原則：

（1）只賦予角色完成任務(wù)必需的最小權(quán)限集合，即權(quán)限的最小化；

（2）任一用戶都不可能同時是互斥角色的成員，即職責(zé)分離；

（3）借助抽象許可的概念，實現(xiàn)在不同的層次對權(quán)限進(jìn)行不同的定義，即數(shù)據(jù)抽象。

在一個典型的Web應(yīng)用系統(tǒng)中，不同用戶執(zhí)行某些模塊化的操作，如對文件內(nèi)容的刪改、對某些菜單或按鈕等素材的訪問，采用基于角色的授權(quán)模型更便捷、擴展能力更強。我們的系統(tǒng)也采用該方案設(shè)計和實踐。

2 基于角色的權(quán)限管理系統(tǒng)

隨著各類業(yè)務(wù)系統(tǒng)向云平臺遷移，數(shù)據(jù)安全成為管理人員關(guān)注的首要問題，基于角色的訪問實施權(quán)限控制成為熱門研究方向。

2.1 權(quán)限管理系統(tǒng)的模塊設(shè)計

基于角色實施訪問控制的模型，不再直接面向用戶分配權(quán)限，而是面向角色實施權(quán)限分配，將用戶與角色、角色與權(quán)限建立關(guān)聯(lián)，更加便于權(quán)限的分配、回收。在相對更大一些的系統(tǒng)中，可以通過“用戶組”把特征、權(quán)限相同或相似的用戶納入到同一個組，以增加權(quán)限控制的靈活性。根據(jù)上述思路，我們設(shè)計了三個模塊：用戶（組）管理模塊、角色管理模塊、權(quán)限管理模塊（見表3）。

表3 權(quán)限管理系統(tǒng)模塊

在具體的系統(tǒng)層面，該模型把角色劃分為管理者角色和訪問者角色，前者具備管理用戶（組）權(quán)限，以及創(chuàng)建、編輯和刪除Web站點內(nèi)容的權(quán)限，后者具備瀏覽內(nèi)容的權(quán)限。

2.2 前后端設(shè)計

主要的功能模塊確定后，我們在數(shù)據(jù)庫服務(wù)器端進(jìn)行功能實踐。MySQL是很多Linux 發(fā)行版都能有效支持的數(shù)據(jù)庫，例如本系統(tǒng)測試用的CentOS 7。對權(quán)限進(jìn)行判斷的邏輯為：通過識別用戶標(biāo)識符（ID），獲得用戶角色；如果該用戶（組）屬于超級用戶（系統(tǒng)管理員），則該角色不受任何限制，可執(zhí)行任何操作；如果是其他用戶（組），則獲得角色所屬權(quán)限，并根據(jù)權(quán)限取得訪問列表。

依據(jù)上述權(quán)限判斷邏輯，設(shè)計并實現(xiàn)user表、role表及access表，分別對應(yīng)用戶、角色和權(quán)限。設(shè)計并實現(xiàn)user_role表、role_access表，調(diào)用前三張表中的ID字段對其建立關(guān)聯(lián)。

我們基于SpringBoot框架設(shè)計數(shù)據(jù)庫系統(tǒng)結(jié)構(gòu)，開 發(fā)DAO層、Entity層、Service層、Controller層四個模塊。每個模塊實現(xiàn)一定的功能：DAO層負(fù)責(zé)實現(xiàn)對上述數(shù)據(jù)表內(nèi)容的增、刪、改、查等基本數(shù)據(jù)操作；Entity層作為實體層，包含實體類的屬性和對應(yīng)屬性方法，例如set方法、get方法；Service層主要負(fù)責(zé)業(yè)務(wù)模塊的邏輯應(yīng)用設(shè)計，實現(xiàn)業(yè)務(wù)邏輯的獨立性和功能復(fù)用，通過本層調(diào)用DAO層的接口，并接收由DAO層返回的數(shù)據(jù)；Controller層負(fù)責(zé)流程控制，實現(xiàn)前后端交互，處理前端請求并向客戶端返回響應(yīng)頁面及數(shù)據(jù)。

權(quán)限管理系統(tǒng)的前端采用HTML/CSS/Javascript結(jié)構(gòu)，通過Ajax函數(shù)向后端傳值，而后端向前端返回JSON對象。利用Apache Shiro安全框架，設(shè)計并實現(xiàn)身份驗證、授權(quán)等權(quán)限控制管理。獲取用戶權(quán)限信息這個過程是在Realm中完成的，包括繼承AuthorizingRealm，重寫接口獲取用戶的權(quán)限信息。

執(zhí)行認(rèn)證過程：

protected AuthenticationInfo doGet-AuthenInfo（AuthenToken authenToken）throws AuthenException {

//用戶登錄平臺提交的用戶名信息和密碼數(shù)據(jù)封裝在Token中

Log_Username_Password_Token username_Password_Token =（Username_Password_Token） authenticationToken；

//提交用戶輸入至數(shù)據(jù)庫進(jìn)行查詢，獲得用戶信息

Log_User user = userService.queryByName（Username_Password_Token.getName（））；

if（user==null）{

return null；

}

return new NewAuthenInfo（log_user，log_user.GetPassword（），″″

）；

}

執(zhí)行授權(quán)過程：

protected AuthorizationInfo doGetAuthorInfo（PrincipalCollection principalCollection）

{

Subject subject = SecurityUtils.getSubject（）；

Log_User currentUser = （Log_User）subject.getPrincipal（）；

//角色設(shè)置

Set roles = new HashSet<>（）；

roles.add（currentUser.getRole（））；

//角色權(quán)限設(shè)置

SimpleAuthorInfo info = new SimpleAuthorInfo（roles）；

}

3 利用Docker部署權(quán)限管理系統(tǒng)

3.1 Web站點架構(gòu)的演進(jìn)

傳統(tǒng)的Web站點架構(gòu)采用單機架構(gòu)。由于業(yè)務(wù)系統(tǒng)數(shù)量與訪問用戶數(shù)量少，可以在同一臺服務(wù)器上部署Web服務(wù)器和數(shù)據(jù)庫系統(tǒng)。此時的訪問流程是：瀏覽器訪問某域名（例如web.test.com）時，通過DNS服務(wù)器（域名系統(tǒng)）的解析，把目標(biāo)域名轉(zhuǎn)換為Web服務(wù)器的真實IP，隨后客戶端瀏覽器轉(zhuǎn)而訪問該IP對應(yīng)的Web站點。這種架構(gòu)實現(xiàn)起來非常直觀、簡單，但是隨著用戶數(shù)的增長，其性能已不足以支撐業(yè)務(wù)需求。

通過將諸如管理、鑒權(quán)等功能代碼進(jìn)行抽象，形成單獨的服務(wù)進(jìn)行管理，是近年來“微服務(wù)”的主要思路。“微服務(wù)”架構(gòu)是一項在云中部署應(yīng)用和服務(wù)的新技術(shù)［7］。服務(wù)和應(yīng)用之間通過不同形式的請求（例如HTTP形式、RPC形式等）訪問公共服務(wù)，并通過解耦服務(wù)和應(yīng)用的各個組件，實現(xiàn)更加便利的升級與擴張。

3.2 利用Docker實現(xiàn)系統(tǒng)部署

Docker為“微服務(wù)”架構(gòu)提供了落地實施方案。目前云計算技術(shù)以IaaS（Infrastructure as a Service，基 礎(chǔ) 設(shè) 施 即 服 務(wù)）、SaaS（Software as a Service，軟件即服務(wù)）、PaaS（Platform as a Service，平臺即服務(wù)）為主要形式。Docker屬于PaaS，是一種操作系統(tǒng)級別的虛擬化技術(shù)。Docker作為目前最流行的一種業(yè)務(wù)系統(tǒng)部署方式，解決了復(fù)雜的環(huán)境配置要求、不同平臺下的運維測試、較低的資源利用等問題，實現(xiàn)“一次開發(fā)、多處應(yīng)用”的目標(biāo)，為軟件開發(fā)人員和網(wǎng)絡(luò)管理人員都帶來了極大的便利。

Docker的工作結(jié)構(gòu)采用了典型的C/S （Client/Server）架構(gòu)。Docker守護(hù)進(jìn)程（Daemon）提供服務(wù)端功能，響應(yīng)客戶端需求，采取本地部署或遠(yuǎn)程部署方式，通過Rest API與客戶端實現(xiàn)通信。圖3顯示了Docker的架構(gòu)和工作流程。

圖3 C/S架構(gòu)的Docker

容器、鏡像、倉庫是Docker技術(shù)三個最重要的概念。鏡像提供了軟件及其運行環(huán)境，并以只讀文件系統(tǒng)的形式出現(xiàn)；容器是運行的鏡像，是在原有只讀文件系統(tǒng)之上再掛載了一層可寫的文件系統(tǒng)；倉庫則提供了鏡像的存儲場所，可以是本地倉庫或是置于互聯(lián)網(wǎng)上。

鏡像底層采用引導(dǎo)文件系統(tǒng)（Bootfs），包括用于初始化處理工作的啟動引導(dǎo)程序Bootloader和被調(diào)用的系統(tǒng)內(nèi)核Kernel。進(jìn)行必要的初始化之后，在Bootfs之上掛載只讀型根文件系統(tǒng)Rootfs（Root Filesystem）。Rootfs層包含有基礎(chǔ)鏡像層，以及可在基礎(chǔ)鏡像層之上繼續(xù)掛載的多個只讀層。每個只讀層包含運行容器所需的文件系統(tǒng)（即目錄及文件）。容器即以此種層層“疊加”而成的鏡像為基礎(chǔ)，由Docker Daemon程序在只讀層上構(gòu)建一個可寫的文件系統(tǒng)層，從而實現(xiàn)讀寫功能。

接著編寫Dockerfile定義項目運行所需的鏡像。Dockerfile由多條指令構(gòu)成，根據(jù)UnionFS 的設(shè)計理念，Dockerfile中的每條指令在上一層鏡像之上生成一個新的文件系統(tǒng)層（除了首條FROM指令），同時原鏡像被新鏡像覆蓋。典型的關(guān)鍵指令如表4所示。

表4 Dockerfile典型指令集

按照規(guī)定的格式和命令集編制配置文件，實現(xiàn)個性化的鏡像定制。圖4所示代碼顯示了通過基礎(chǔ)鏡像CentOS 7定制Web服務(wù)器程序及其運行環(huán)境。

圖4 通過Dockerfile定制鏡像

Docker 引擎調(diào)用build程序?qū)崿F(xiàn)從 Dockerfile 構(gòu)建鏡像。圖5顯示了這一過程。每一個Step的順利執(zhí)行，都是在原有鏡像基礎(chǔ)上覆蓋一層新的只讀文件系統(tǒng)，直至正常結(jié)束。

圖5 鏡像形成過程

實際的業(yè)務(wù)系統(tǒng)往往需要多個鏡像、多個容器的支持才能正常運行，因此需要有實現(xiàn)容器編排功能的組件。Docker-Compose承擔(dān)了這一功能。通過對容器進(jìn)行編排，用戶可以定義和運行多個容器。Docker-Compose 依靠YAML文件實現(xiàn)編排功能，圖6顯示了本系統(tǒng)數(shù)據(jù)庫容器的YAML文件，該文件有嚴(yán)格的語法要求。圖7則顯示了YAML文件被調(diào)用的方法。

圖6 實現(xiàn)容器編排的YAML文件

圖7 調(diào)用和執(zhí)行YAML文件

完成系統(tǒng)部署后，測試用戶提交登錄請求，服務(wù)端程序首先執(zhí)行認(rèn)證過程，負(fù)責(zé)解析用戶請求內(nèi)容，并根據(jù)請求內(nèi)容、參數(shù)等信息調(diào)用授權(quán)過程；全部響應(yīng)過程處理完成后訪問頁面反饋處理結(jié)果。

4 結(jié)語

我們結(jié)合權(quán)限分配和管理的問題，分析了三種典型的權(quán)限控制模型，通過對三種模型的特征分析，設(shè)計并實現(xiàn)RBAC模型系統(tǒng)。在測試該系統(tǒng)的功能時，為了解決開發(fā)環(huán)境依賴、部署過程復(fù)雜、資源使用效率低下的問題，我們選擇了通過云計算技術(shù)進(jìn)行部署測試，并在Docker容器中實際部署和測試了系統(tǒng)的有效性。

實驗結(jié)果同時表明，以Docker為代表的容器技術(shù)，在實現(xiàn)業(yè)務(wù)系統(tǒng)一次構(gòu)建、多處運行的目標(biāo)方面，能有效提高工作效率。