【文章內(nèi)容簡介】 較主體和客體的敏感標(biāo)記來決定一個(gè)主體是否能 夠訪問某個(gè)客體。用戶的程序不能改變他自己及任何其它客體的敏感標(biāo)記，從而系統(tǒng)可以防止特洛伊木馬的攻擊。 強(qiáng)制訪問控制一般與自主訪問控制結(jié)合使用，并且實(shí)施一些附加的、更強(qiáng)的訪問限制。一個(gè)主體只有通過了自主與強(qiáng)制性訪問限制檢查后，才能訪問某個(gè)客體。用戶可以利用自主訪問控制來防范其它用戶對(duì)自己客體的攻擊，由于用戶不能直接改變強(qiáng)制訪問控制屬性，所以強(qiáng)制訪問控制提供了一個(gè)不可逾越的、更強(qiáng)的安全保護(hù)層以防止其它用戶偶然或故意地濫用自主訪問控制。 以上訪問控制策略對(duì)于處理一些無需保密但又敏感的信息的政府和行業(yè)組織的需求并不 是特別的適合。在這樣的環(huán)境下，安全目標(biāo)支持產(chǎn)生于現(xiàn)有法律、道德規(guī)范、規(guī)章、或一般慣例的高端組織策略。這些環(huán)境通常需要控制個(gè)體行為的能力，而不僅僅是如何根據(jù)信息的敏感性為其設(shè)置標(biāo)簽從而訪問這一信息的個(gè)人能力。 8 就基于角色訪問控制而言，訪問決策是基于角色的，個(gè)體用戶是某個(gè)組織的一部分。用戶具有指派的角色（比如醫(yī)生、護(hù)士、出納、經(jīng)理）。定義角色的過程應(yīng)該基于對(duì)組織運(yùn)轉(zhuǎn)的徹底分析，應(yīng)該包括來自一個(gè)組織中更廣范圍用戶的輸入。 訪問權(quán)按角色名分組，資源的使用受限于授權(quán)給假定關(guān)聯(lián)角色的個(gè)體。例如，在一個(gè)商務(wù)管理系統(tǒng)中，經(jīng) 理角色可能包括人事管理、工資管理、分配項(xiàng)目等；而一般員工的角色則被限制為僅能瀏覽自己的一些信息，如基本信息、工資信息和工程項(xiàng)目信息等。 基于角色的訪問控制模型 RBAC 比傳統(tǒng)的自主訪問控制和強(qiáng)制訪問控制更優(yōu)越，同時(shí)也提供了更高的靈活性和擴(kuò)展性。 RBAC 訪問控制模型實(shí)現(xiàn)了用戶與訪問權(quán)限的邏輯分離，減少了授權(quán)管理的復(fù)雜性，降低了管理開銷和管理的復(fù)雜度。對(duì)于現(xiàn)在規(guī)模日益增大的基于 MVC 架構(gòu)的商務(wù)信息管理系統(tǒng)來說，采用 RBAC 訪問控制模型的訪問控制模塊將會(huì)起到越來越大的作用。 綜上分析，控制訪問角色的運(yùn)用是一種開發(fā)和 加強(qiáng)企業(yè)特殊安全策略，進(jìn)行安全管理過程流程化的有效手段。運(yùn)用 RBAC 模型可以很好的解決 Web 系統(tǒng)中提出的訪問控制要求，而 DAC、 MAC 等等訪問控制技術(shù)由于各種各樣的局限性和特性，都不是 WEB 系統(tǒng)下實(shí)現(xiàn)訪問控制的最好選擇。 從目前的應(yīng)用現(xiàn)狀來看，以 MVC 為架構(gòu)而建成的 WEB 網(wǎng)站特別是商務(wù)網(wǎng)站的數(shù)量較為龐大，而由于其自身的管理特性，對(duì)安全措施的要求也越來越高，這就要求我們找到一種更為有效的權(quán)限管理方法去適應(yīng)網(wǎng)站對(duì)訪問控制技術(shù)的要求。而 RBAC 作為一種科學(xué)、合理、靈活、成熟的訪問控制技術(shù)，最適合于在 WEB 環(huán)境下使 用，所以如何使它應(yīng)用到那些基于 MVC 架構(gòu)的網(wǎng)站中去，會(huì)是一個(gè)具有相當(dāng)研究價(jià)值的課題。 9 第二章 系統(tǒng)框架分析與設(shè)計(jì) 基于 MVC 架構(gòu)的 Web 系統(tǒng) 在當(dāng)前開發(fā)的商務(wù)系統(tǒng)中，一般都會(huì)包括部門管理功能模塊，員工管理功能模塊，工程項(xiàng)目管理功能模塊和員工薪水管理功能模塊，以及包括針對(duì)員工使用的信息查看模塊。先下面給出一個(gè)已經(jīng)設(shè)計(jì)完善的基于 MVC 架構(gòu)的 WEB 網(wǎng)站，系統(tǒng)的功能模塊圖如圖 21所示。 圖 21 系統(tǒng)功能模塊圖 部門管理模塊：針對(duì)公司內(nèi)部的所 有的部門進(jìn)行管理，用戶可以方便地添加部門、修改部門信息、刪除某一部門和查詢某一部門的信息。 員工管理模塊：針對(duì)公司內(nèi)部的所有的員工進(jìn)行管理，用戶可以方便地添加員工信息、修改員工信息、刪除某一員工信息和查詢某一部門的所有員工信息。 工程項(xiàng)目管理模塊：針對(duì)公司的工程項(xiàng)目進(jìn)行管理，用戶可以方便地添加工程項(xiàng)目信息、修改某一工程項(xiàng)目的信息、刪除某工程項(xiàng)目的信息和查詢某一工程項(xiàng)目信息。 員工工資管理模塊：針對(duì)公司內(nèi)部的所有的員工的薪酬進(jìn)行管理，用戶可以方便地添加工資信息、修改工資信息、刪除工資信息和查詢某一員工在某段時(shí) 間內(nèi)的所有工資信息。 信息查看模塊：針對(duì)公司員工設(shè)計(jì)的功能模塊，通過該模塊員工可以方便的查看自己的基本信息，工資信息以及所負(fù)責(zé)的工程項(xiàng)目信息。 系統(tǒng)的功能模塊 部門管理模塊 員工管理模塊 工程項(xiàng)目管理模塊 員工工資管理模塊 信息查看模塊 系統(tǒng)功能管理模塊 系統(tǒng)用戶管理模塊 系統(tǒng)角色管理模塊 10 系統(tǒng)功能管理模塊：用戶可以通過該模塊管理系統(tǒng)中涉及到的所有功能，可以添加、刪除和修改。 系統(tǒng)用戶管理模塊：用戶可以通過該模塊管理系統(tǒng)中涉及到的所有用戶，可以添加、刪除和修改。 系統(tǒng)角色管理模塊：用戶可以通過該模塊為系統(tǒng)中的不同的用戶設(shè)置不同的權(quán)限，并能夠修改某一用戶所賦予的權(quán)限。 在上述的商務(wù)系統(tǒng)中，在安全性上一般會(huì)有如下的要求： 能夠很好的實(shí)現(xiàn)訪問控制。在一個(gè)企業(yè) 中，存在著很多種不同的用戶，如經(jīng)理、董事長、一般職工，系統(tǒng)維護(hù)人員等。當(dāng)所有的用戶面對(duì)同一個(gè)系統(tǒng)時(shí)，就應(yīng)該做到用戶之間要有區(qū)分，即進(jìn)入系統(tǒng)后不同的用戶只能實(shí)行自身擁有的權(quán)限，不可以越權(quán)。 部分信息的保密。公司中存在著一些決定企業(yè)利益的信息，這些信息只能由公司的管理人員來查看和管理，任何非法的侵入都有可能造成不良的后果。 現(xiàn)代主流的 Web 系統(tǒng)的體系架構(gòu)設(shè)計(jì)基于 J2EE 平臺(tái)上的 MVC 設(shè)計(jì)模式，應(yīng)用 Struts 框架，采用 B/S 模式，具體的架構(gòu)設(shè)計(jì)如圖 22 所示。 圖 22 商務(wù)管理系統(tǒng)架構(gòu)圖 在圖 22中，系統(tǒng)架構(gòu)可以細(xì)分為以下 4個(gè)層次： 客戶層（ Client Layer）：運(yùn)行在用戶機(jī)器的瀏覽器中，處理與用戶的交互。 表現(xiàn)層（ Presentation Layer）：運(yùn)行在 J2EE Web 容器中，產(chǎn)生系統(tǒng)的表現(xiàn)邏輯，處理用戶的請(qǐng)求并做出響應(yīng)；整個(gè) Web 層建立在 Struts 框架基礎(chǔ)上，其中 View 由 HTML 和 JSP 頁面組成，其數(shù)據(jù)表示是 ActionForm Bean； Controller由 ActionServlet 組合 和 Action 類組成；而 Model 則交由Action Action Action HTML JSPs Struts Tags(JSTL) Style Sheet Action Servlet Request Processor Web Container Controller Model Presentation Layer Http Response Http Request BusinessManagement_MessagerResources.properties View Java Bean Business Objects Database Layer Business Layer Client Layer Oracle 9i Browser 11 業(yè)務(wù)邏輯層來實(shí)現(xiàn)。 業(yè)務(wù)邏輯層（ Business Layer）：運(yùn)行在 J2EE Web 容器中，完成系統(tǒng)的業(yè)務(wù)需求，為 Web 層提供所需的業(yè)務(wù)方法，由 JavaBean 構(gòu)成系統(tǒng)的 Business Objects（ BO），并使用 DAO 模式把數(shù)據(jù)訪問封裝起來，以供在其他應(yīng)用層中統(tǒng)一調(diào)用。 數(shù)據(jù)源層（ Database Layer）：即數(shù)據(jù)庫層，存放系統(tǒng)的應(yīng)用數(shù)據(jù)，系統(tǒng)采用 Oracle9i 作為數(shù)據(jù)庫服務(wù)器。 系統(tǒng)的架構(gòu)可以表示為 JSP+Struts+Database。使用這種架構(gòu)一方 面便于系統(tǒng)的開發(fā)和管理；另一方面，層與層之間的開發(fā)幾乎是完全獨(dú)立的，從而降低了數(shù)據(jù)在各層之間的耦合性，提高了系統(tǒng)的可維護(hù)性和可擴(kuò)展性。此外，系統(tǒng)是由Java 來開發(fā)實(shí)現(xiàn)的， Java 的跨平臺(tái)特性實(shí)現(xiàn)了系統(tǒng)的可移植性。 RBAC 模型的建立 根據(jù)上述商務(wù)系統(tǒng)對(duì)安全性的需求，通過在 Web 系統(tǒng)中使用 RBAC 模型可以很好的滿足各項(xiàng)需求。 RBAC 的核心思想就是：根據(jù)用戶需求，給用戶分派各種角色，為不同的角色分配各種權(quán)限，用戶通過自己所屬的角色獲得操作權(quán)限許可。其核心模型如圖23 所示。 圖 23 RBAC 模型 核心 RBAC 模型的組成部分是： Users：用戶集 {u1， u2， u3?? ， un}； Roles：角色集 {r1， r2， r3，?? ， rn}； OPS：操作集 {op1， op2， op3，??， opn} OBJ：客體集 {obj1， obj2， obj3，??， objn} P= OPS X 0BJ：權(quán)限集是不同客體上不同操作的描述 {pl， p2， p3， .? ， pn} 12 R olesU sersUA *? ：用戶 — 角色分配關(guān)系：多對(duì)多； Assignedusers： ，角色與用戶的映射，將一個(gè)角色與一組用戶相映射； ：權(quán)限 角色分配關(guān)系，多對(duì)多； Assigned privileges ： ，角色與權(quán)限的映射，將一個(gè)角色與一組權(quán)限相映射； Session ：會(huì)話集 {s1， s2， s3，??， sn } User_sessions ： ，用戶與會(huì)話的映射，將一個(gè)用戶與一個(gè)會(huì)話相映射； Session_roles ： ，會(huì)話與角色的映射，將一個(gè)會(huì)話與一組角色相映射； Avail_session_privilege ： ，在一次會(huì)話中一個(gè)用戶允許的權(quán)限； 用戶：不僅指人，也可以指機(jī)器，網(wǎng)絡(luò)或智能代理。 角色：管理員依據(jù)安全策略劃分出來的操作集合，表示該角色 成員所授予的職權(quán)和責(zé)任。 客體：指系統(tǒng)需要保護(hù)的資源。 權(quán)限：對(duì)系統(tǒng)中的客體進(jìn)行特定存取的許可。權(quán)限是與客體緊密相關(guān)的，不同的系統(tǒng)，其權(quán)限規(guī)定是不同的，既可以指網(wǎng)絡(luò)的應(yīng)用，如對(duì)某個(gè)子網(wǎng)的訪問權(quán)限，也可以指對(duì)數(shù)據(jù)庫的表單等的訪問。權(quán)限的粒度大小取決于實(shí)際系統(tǒng)的定義。 會(huì)話：為了對(duì)系統(tǒng)資源進(jìn)行操作，用戶需要建立會(huì)話，每個(gè)會(huì)話將一個(gè)用戶與他所對(duì)應(yīng)的角色集中的一部分建立映射關(guān)系，這一角色子集成為被會(huì)話激活的角色，在這次會(huì)話中，用戶可以執(zhí)行的操作就是該會(huì)話激活的角色對(duì)應(yīng)的權(quán)限所允許的操作。 上述 RBAC 模型是 RBAC 核心模型，此模型保留了 RBAC 的最小特征集，是每個(gè) RBAC 系統(tǒng)都需要的元素。 RBAC 模型在 MVC 網(wǎng)站中的應(yīng)用 由需求分析可知，需要為企業(yè)內(nèi)部網(wǎng)管理系統(tǒng)設(shè)計(jì)一個(gè)用戶權(quán)限管理的功能模塊，從而達(dá)到對(duì)用戶權(quán)限進(jìn)行管理的目的。當(dāng)今的大型的信息管理系統(tǒng)都具有 13 功能復(fù)雜，用戶眾多的特點(diǎn)，如果仍采用傳統(tǒng)的權(quán)限管理方式，直接將權(quán)限分配給用戶，對(duì)具有相同權(quán)限的一類用戶同樣的授權(quán)操作將被重復(fù)很多遍，一旦用戶工作崗位有變化，則對(duì)其權(quán)限的調(diào)整將非常復(fù)雜，而基于 RBAC 模型的權(quán)限控制方法則大大簡化了這種授權(quán)管理的復(fù)雜度，降低了 系統(tǒng)管理的開銷。 RBAC 模型描述了一種良好的訪問控制方法和原理。通過在商務(wù) Web 系統(tǒng)中使用 RBAC 模型可以方便、科學(xué)、合理地進(jìn)行訪問控制，有了良好的訪問控制，不同的用戶在使用系統(tǒng)的時(shí)候僅能訪問自身被賦予的權(quán)限，用戶之間不能越權(quán)訪問，從而保證了信息的安全性和一致性，從而提高了系統(tǒng)的安全性。 通過以下幾個(gè)步驟，可以將 RBAC 模型應(yīng)用在 MVC 網(wǎng)站中。 （ 1）建立功能的概念。功能，即操作。在系統(tǒng)中，如對(duì)員工的添加、刪除和修改的操作，都可以描述為一個(gè)功能。 （ 2）建立權(quán)限節(jié)點(diǎn)的概念。權(quán)限節(jié)點(diǎn)，顧名思義，它對(duì)應(yīng)著一個(gè) 或一組功能操作菜單，表示了該節(jié)點(diǎn)可以進(jìn)行系統(tǒng)操作的范圍。 （ 3）建立角色的概念。將角色與節(jié)點(diǎn)對(duì)應(yīng)起來，一個(gè)角色可以對(duì)應(yīng)多個(gè)節(jié)點(diǎn)，一個(gè)節(jié)點(diǎn)也可以對(duì)應(yīng)多個(gè)角色，這是一個(gè)多對(duì)多的關(guān)系。角色與節(jié)點(diǎn)對(duì)應(yīng)好之后，也就意味著角色與某一個(gè)或某一組功能操作菜單建立了關(guān)聯(lián)。系統(tǒng)中存在不同類型的用戶，也即不同的用戶隸屬于不同的角色。 （ 4）將系統(tǒng)的用戶和角色關(guān)聯(lián)起來。一旦一個(gè)用戶被設(shè)置了某個(gè)角色，那么也就意味著該用戶具有了某些權(quán)限。具有了某些權(quán)限，也就意味著擁有了某些功能（對(duì)系統(tǒng)的操作和管理）。 舉例來說，假設(shè)系統(tǒng)中存在兩個(gè)權(quán)限 節(jié)點(diǎn) 1和 2，兩個(gè)角色 A 和 B，用戶有甲（經(jīng)理）和乙（部門經(jīng)理），很顯然甲和乙在登陸系統(tǒng)后應(yīng)該具有不同的權(quán)限，甲可以管理整個(gè)公司的信息，而乙僅能管理所在部門的信息。這時(shí)，設(shè)定權(quán)限節(jié)點(diǎn) 1 下包含了管理整個(gè)公司信息的所有功能，權(quán)限節(jié)點(diǎn) 2下包含了管理某個(gè)部門信息的所有功能；將角色 A 與節(jié)點(diǎn) 1進(jìn)行關(guān)聯(lián)，將角色 B與節(jié)點(diǎn) 2 進(jìn)行關(guān)聯(lián)。最后，將用戶甲的角色設(shè)定為角色 A，用戶乙的角色設(shè)定為角色 B。在用戶甲和乙登陸系統(tǒng)后，就會(huì)看到自己所具有的功能菜單，其他用戶的功能菜單是非可見的，從而實(shí)現(xiàn)了訪問控制。 簡言之，通過在系統(tǒng)中設(shè)置功能、權(quán) 限和角色的概念，就可以在系統(tǒng)中實(shí)現(xiàn)RBAC 模型，并讓它很好地為 Web 系統(tǒng)提供訪問控制功能。 14 第三章 設(shè)計(jì)實(shí)現(xiàn) RBAC 框架實(shí)現(xiàn) 數(shù)據(jù)存儲(chǔ)是個(gè)非常重要的功能需求。系統(tǒng)中很多的地方都要存儲(chǔ)數(shù)據(jù)，并且其格式要求也不相同，數(shù)據(jù)量也差別較大。良好的設(shè)計(jì)不但能減少因數(shù)據(jù)保存不當(dāng)造成的對(duì)系統(tǒng)的損害，而且能顯著地提高系統(tǒng)的性能。在考慮數(shù)據(jù)存儲(chǔ)方案時(shí)，有三種可行的選擇