【正文】 成員。 權(quán)限指派（ Permission Assignment）：角色與權(quán)限之間的關(guān)系也是多對多的關(guān)系。進行權(quán)限分配時，應(yīng)遵循最小特權(quán)原則（ the Least Privilege Rule），即分配的權(quán)限集既能保證角色充分行使其職權(quán)，又不能超越職權(quán)范圍。用戶訪問的時候?qū)嶋H具有的角色只包含激活后的 角色，未激活的角色在訪問中不起作用。 會話（ Session）：用戶是一個靜態(tài)的概念，會話則是一個動態(tài)的概念。用戶與會話是一對多關(guān)系，一個用戶可同時打開多個會話。 在 RBAC 中，它遵循如下的基本原則： 角色繼承（ Role Inheritance） 為了提高效率，避免相同權(quán)限的重復(fù)設(shè)置， RBAC 采用了“角色繼承”的概念，定義了這樣的一些角色，他們有自己的屬性，但可能還繼承其他角色的屬性和權(quán)限。 最小權(quán)限原則（ the Least Privilege Rule） 所謂最小權(quán)限原則是指：用戶所擁有的權(quán)力不能超過他執(zhí)行工作時所需的權(quán)限。在 RBAC 中，可以根據(jù)組織內(nèi)的規(guī)章制度、職員的分工等設(shè)計擁有不同權(quán)限的角色，只有角色需要執(zhí)行的操作才授權(quán)給角色。 職責(zé)分離（ Separation of Duty） 對于某些特定的操作集，某一個角色或用戶不可能同時獨立地完成所有這些操作。 5 RBAC適用性分析 在 RBAC 模型中，一個用戶通過用戶授權(quán)獲得一個或者 幾個角色，但角色不能被同時激活；一個角色可以被同時授予多個用戶；每個角色有一個或多個節(jié)點，一個節(jié)點也可以被賦予多個角色；每個節(jié)點有一個或者多個功能，一個功能可以被同時掛在不同的節(jié)點上，而節(jié)點可以有子節(jié)點，子節(jié)點也可以再有子節(jié)點；一個功能對應(yīng)一個或多個頁面；一個頁面有一個或多個操作。 為更真實的描述現(xiàn)實， RBAC 模型還有許多的控制機制。對頁面的限制主要是限制用 戶在特定時間和特定地點所能看到的功能和所能進行的操作。模型中有了這些限制才更完整、更真實地反應(yīng)現(xiàn)實，從而使實際模型細化的過程更加平滑，現(xiàn)實和計算機實現(xiàn)策略達到較好的融合。對頁面的訪問控制可以從時間和空間兩個方面來進行，對頁面功能和數(shù)據(jù)的訪問，可以通過用戶登錄后所帶 session 中的信息進行控制。一般時間約束是指從 一個時間點持續(xù)到另一時間點之間可以訪問某個頁面，例如，企業(yè)商務(wù)系統(tǒng)中的商品招標頁面，它在某一指定時間段內(nèi)開放，對這種約束可以在用戶訪問網(wǎng)頁的時候判斷訪問時間是否在允許范圍內(nèi)?？臻g約束主要是對用戶在不同地方（網(wǎng)段）登錄所能看到的頁面以及頁面能提供的信息進行控制。一般系統(tǒng)的高層用戶都有一個固定的 IP 段，就可以對那些重要的頁面設(shè)置允許訪問的 IP 范圍來達到對關(guān)鍵資源的保護。 對頁面功能和數(shù)據(jù)的訪問需要知道用戶的大概類型，主要包括管理員、部門管理員、一般職工、游客（企業(yè)或單位以外的人員）等。 通過了解 RBAC模型的原理和 RBAC模型中對訪問控制的支持，我們可以看出，RBAC 模型可以很好的應(yīng)用于已有或?qū)⒁_發(fā)的企業(yè)商務(wù) Web 系統(tǒng)中。通過在系統(tǒng)中增加角色這個概念，很好的解決了這個 6 問題。 控制邏輯混亂的問題。尤其當(dāng)系統(tǒng)設(shè)計的用戶和角色比較多時，單純的依靠代碼進行訪問控制將變得相當(dāng)困難。在企業(yè)商務(wù) Web系統(tǒng)中利用 RBAC 模 型，可以簡便、科學(xué)、清晰地進行訪問控制，從而在一定程度上提高了整個 Web 系統(tǒng)的安全性?，F(xiàn)在普遍在使用的安全措施有如下幾種： （ 1）防止 SQL 注入 比如 URL、表單等提交信息時，通過一段防止 SQL 注入的過濾代碼即可防止出錯信息暴露，或者通過轉(zhuǎn)向，當(dāng)系統(tǒng)出錯時轉(zhuǎn)到一個提示出錯的頁面等。例如如果是年齡，就得限定必須是數(shù)字，大小必須限定在一個范圍之間，比如說 18120之間。 （ 2）驗證碼技術(shù) 所謂驗證碼，就是將一串隨機產(chǎn)生的數(shù)字或符號，生成一幅圖片，圖片里加上一些干擾象素，由用戶肉眼識別其中的驗證碼信息，輸入表單提交網(wǎng)站驗證，驗證成功后才能使用某項功能。 （ 3） MD5 加密技術(shù) MD5 的全稱是 MessageDigest Algorithm 5，當(dāng)用戶登錄的時候，系統(tǒng)把用戶輸入的密碼計算成 MD5 值，然后再去和保存在文件系統(tǒng)中的 MD5 值進行比較，進而確定輸入的密碼是否正確。這不但可以避免用戶的密碼被具有系統(tǒng)管理員權(quán)限的用戶知道，而且還在一定程度上增加了密碼被破解的難度。而圖片、文件一般是不能自動備份，需要手工操作，所以我們必須要定期手工對網(wǎng)站的圖片、文件進行備份操作。這一研究導(dǎo)致兩種基本類型訪問控制的產(chǎn)生：自主訪問控制（ Discretionary Access Control, DAC）和強制訪問控制（ Mandatory Access Control, MAC）。 自主訪問控制，允許把訪問控制權(quán)的授予和取消留給個體用戶來判斷。自主訪問控制機制允許用戶被授權(quán)和取消訪問其控制之下的任何客體（ object），換句話說，用戶就是他們控制下的客體的擁有者。對于這些組織，公司或代理機構(gòu)是事實上的系統(tǒng)客體和處理他們的程序的擁有者。 強制訪問控制，在美國國防部 Trusted Computer Security Evaluation Criteria (TCSEC) 中定義如下：“一種限制訪問客體的手段，它以包含在這些客體中的信息敏感性和訪問這些敏感性信息的主體的正式授權(quán)信息（如清除）為基礎(chǔ)”。強制訪問控制（ MAC）的主要特征是對所有主體及其所控制的客體（例如：進程、文件、段、設(shè)備）實施強制訪問控制。系統(tǒng)通過比較主體和客體的敏感標記來決定一個主體是否能 夠訪問某個客體。 強制訪問控制一般與自主訪問控制結(jié)合使用，并且實施一些附加的、更強的訪問限制。用戶可以利用自主訪問控制來防范其它用戶對自己客體的攻擊，由于用戶不能直接改變強制訪問控制屬性，所以強制訪問控制提供了一個不可逾越的、更強的安全保護層以防止其它用戶偶然或故意地濫用自主訪問控制。在這樣的環(huán)境下，安全目標支持產(chǎn)生于現(xiàn)有法律、道德規(guī)范、規(guī)章、或一般慣例的高端組織策略。 8 就基于角色訪問控制而言，訪問決策是基于角色的，個體用戶是某個組織的一部分。定義角色的過程應(yīng)該基于對組織運轉(zhuǎn)的徹底分析，應(yīng)該包括來自一個組織中更廣范圍用戶的輸入。例如，在一個商務(wù)管理系統(tǒng)中，經(jīng) 理角色可能包括人事管理、工資管理、分配項目等；而一般員工的角色則被限制為僅能瀏覽自己的一些信息，如基本信息、工資信息和工程項目信息等。 RBAC 訪問控制模型實現(xiàn)了用戶與訪問權(quán)限的邏輯分離，減少了授權(quán)管理的復(fù)雜性，降低了管理開銷和管理的復(fù)雜度。 綜上分析，控制訪問角色的運用是一種開發(fā)和 加強企業(yè)特殊安全策略，進行安全管理過程流程化的有效手段。 從目前的應(yīng)用現(xiàn)狀來看，以 MVC 為架構(gòu)而建成的 WEB 網(wǎng)站特別是商務(wù)網(wǎng)站的數(shù)量較為龐大，而由于其自身的管理特性，對安全措施的要求也越來越高，這就要求我們找到一種更為有效的權(quán)限管理方法去適應(yīng)網(wǎng)站對訪問控制技術(shù)的要求。 9 第二章 系統(tǒng)框架分析與設(shè)計 基于 MVC 架構(gòu)的 Web 系統(tǒng) 在當(dāng)前開發(fā)的商務(wù)系統(tǒng)中，一般都會包括部門管理功能模塊，員工管理功能模塊，工程項目管理功能模塊和員工薪水管理功能模塊，以及包括針對員工使用的信息查看模塊。 圖 21 系統(tǒng)功能模塊圖 部門管理模塊：針對公司內(nèi)部的所 有的部門進行管理，用戶可以方便地添加部門、修改部門信息、刪除某一部門和查詢某一部門的信息。 工程項目管理模塊：針對公司的工程項目進行管理，用戶可以方便地添加工程項目信息、修改某一工程項目的信息、刪除某工程項目的信息和查詢某一工程項目信息。 信息查看模塊：針對公司員工設(shè)計的功能模塊，通過該模塊員工可以方便的查看自己的基本信息，工資信息以及所負責(zé)的工程項目信息。 系統(tǒng)用戶管理模塊：用戶可以通過該模塊管理系統(tǒng)中涉及到的所有用戶，可以添加、刪除和修改。 在上述的商務(wù)系統(tǒng)中，在安全性上一般會有如下的要求： 能夠很好的實現(xiàn)訪問控制。當(dāng)所有的用戶面對同一個系統(tǒng)時，就應(yīng)該做到用戶之間要有區(qū)分，即進入系統(tǒng)后不同的用戶只能實行自身擁有的權(quán)限，不可以越權(quán)。公司中存在著一些決定企業(yè)利益的信息，這些信息只能由公司的管理人員來查看和管理，任何非法的侵入都有可能造成不良的后果。 圖 22 商務(wù)管理系統(tǒng)架構(gòu)圖 在圖 22中，系統(tǒng)架構(gòu)可以細分為以下 4個層次： 客戶層（ Client Layer）：運行在用戶機器的瀏覽器中，處理與用戶的交互。 業(yè)務(wù)邏輯層（ Business Layer）：運行在 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)用。 系統(tǒng)的架構(gòu)可以表示為 JSP+Struts+Database。此外，系統(tǒng)是由Java 來開發(fā)實現(xiàn)的， Java 的跨平臺特性實現(xiàn)了系統(tǒng)的可移植性。 RBAC 的核心思想就是：根據(jù)用戶需求，給用戶分派各種角色，為不同的角色分配各種權(quán)限，用戶通過自己所屬的角色獲得操作權(quán)限許可。 圖 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)系：多對多； Assignedusers： ，角色與用戶的映射，將一個角色與一組用戶相映射； ：權(quán)限 角色分配關(guān)系，多對多； Assigned privileges ： ，角色與權(quán)限的映射，將一個角色與一組權(quán)限相映射； Session ：會話集 {s1， s2， s3，??， sn } User_sessions ： ，用戶與會話的映射，將一個用戶與一個會話相映射； Session_roles ： ，會話與角色的映射，將一個會話與一組角色相映射； Avail_session_privilege ： ，在一次會話中一個用戶允許的權(quán)限； 用戶：不僅指人，也可以指機器，網(wǎng)絡(luò)或智能代理。 客體：指系統(tǒng)需要保護的資源。權(quán)限是與客體緊密相關(guān)的，不同的系統(tǒng)，其權(quán)限規(guī)定是不同的，既可以指網(wǎng)絡(luò)的應(yīng)用，如對某個子網(wǎng)的訪問權(quán)限，也可以指對數(shù)據(jù)庫的表單等的訪問。 會話：為了對系統(tǒng)資源進行操作，用戶需要建立會話，每個會話將一個用戶與他所對應(yīng)的角色集中的一部分建立映射關(guān)系，這一角色子集成為被會話激活的角色，在這次會話中，用戶可以執(zhí)行的操作就是該會話激活的角色對應(yīng)的權(quán)限所允許的操作。 RBAC 模型在 MVC 網(wǎng)站中的應(yīng)用 由需求分析可知，需要為企業(yè)內(nèi)部網(wǎng)管理系統(tǒng)設(shè)計一個用戶權(quán)限管理的功能模塊，從而達到對用戶權(quán)限進行管理的目的。 RBAC 模型描述了一種良好的訪問控制方法和原理。 通過以下幾個步驟，可以將 RBAC 模型應(yīng)用在 MVC 網(wǎng)站中。功能，即操作。 （ 2）建立權(quán)限節(jié)點的概念。 （ 3）建立角色的概念。角色與節(jié)點對應(yīng)好之后，也就意味著角色與某一個或某一組功能操作菜單建立了關(guān)聯(lián)。 （ 4）將系統(tǒng)的用戶和角色關(guān)聯(lián)起來。具有了某些權(quán)限，也就意味著擁有了某些功能（對系統(tǒng)的操作和管理）。這時，設(shè)定權(quán)限節(jié)點 1 下包含了管理整個公司信息的所有功能，權(quán)限節(jié)點 2下包含了管理某個部門信息的所有功能；將角色 A 與節(jié)點 1進行關(guān)聯(lián)，將角色 B與節(jié)點 2 進行關(guān)聯(lián)。在用戶甲和乙登陸系統(tǒng)后，就會看到自己所具有的功能菜單，其他用戶的功能菜單是非可見的，從而實現(xiàn)了訪問控制。 14 第三章 設(shè)計實現(xiàn) RBAC 框架實現(xiàn) 數(shù)據(jù)存儲是個非常重要的功能需求。良好的設(shè)計不但能減少因數(shù)據(jù)保存不當(dāng)造成的對系統(tǒng)的損害，而且能顯著地提高系統(tǒng)的性能。文件方式的好處在于簡單直觀，存取速度最快，但不夠安全，在 RBAC 的早 期版本中，我們采用的就是文件方式。有鑒于此，我們在系統(tǒng)中采用了數(shù)據(jù)庫方式作為本系統(tǒng)數(shù)據(jù)存儲方案。如表 31 所示。如表 32 所示。如表33 所示。如表 34所示。如表 35所示。如表 36所示。如表 37所示。如表 38所示 。如表 39所示。如表 310 所示。如表 311 所示。系統(tǒng)功能添加的實現(xiàn)過程可以描述為： 圖 31 系統(tǒng)功能模塊實現(xiàn)的流程圖 從圖 31可以看出，用戶在試圖添加一個系統(tǒng)功能時，應(yīng)該首先填寫表單，填寫好表單后，點擊表單的提交按鈕之后，會觸發(fā)一個請求事件（ Action），該瀏覽器 ActionForm 類 Action 類 提交表單 封裝表單數(shù)據(jù) 調(diào)用 查找 JavaBean 轉(zhuǎn)向 數(shù)據(jù)庫 18 事件由頁面的表單指定。此時表單的數(shù)據(jù)將會保存到該ActionForm 類中，在 Action 中就可以得到表單中的數(shù)據(jù)。在相應(yīng)的 JavaBean 中，完成與數(shù)據(jù)庫的交互，實現(xiàn)對數(shù)據(jù)的添加。 GnoperatorForm 的部分實現(xiàn)代碼如下：