雷驚鵬

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

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

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

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

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

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

表1 訪問(wèn)控制模型對(duì)比

1.1 MAC模型

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

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

圖1 MAC模型

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

1.2 DAC模型

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

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

1.3 RBAC模型

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

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

圖2 RBAC0模型

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2 前后端設(shè)計(jì)

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

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

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

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

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

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

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

Log_Username_Password_Token username_Password_Token =（Username_Password_Token） authenticationToken；

//提交用戶輸入至數(shù)據(jù)庫(kù)進(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)過(guò)程：

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站點(diǎn)架構(gòu)的演進(jìn)

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

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

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

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

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

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

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

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

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

表4 Dockerfile典型指令集

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

圖4 通過(guò)Dockerfile定制鏡像

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

圖5 鏡像形成過(guò)程

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

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

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

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

4 結(jié)語(yǔ)

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

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