国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

文檔已補充完，特別感謝高海東提出寶貴的意見。當然，這還不是結(jié)束。我們還會陸續(xù)的完善這個模型，包括安全策略、資源歸屬控制、責(zé)任分離關(guān)系等等等等吧。。

1.     概念

訪問控制技術(shù)是由美國國防部（Department of Defense, DoD）資助的研究和開發(fā)成果演變而來的。這一研究導(dǎo)致兩種基本類型訪問控制的產(chǎn)生：自主訪問控制（Discretionary Access Control, DAC）和強制訪問控制（Mandatory Access Control, MAC）。最初的研究和應(yīng)用主要是為了防止機密信息被未經(jīng)授權(quán)者訪問，近期的應(yīng)用主要是把這些策略應(yīng)用到為商業(yè)領(lǐng)域。

自主訪問控制，允許把訪問控制權(quán)的授予和取消留給個體用戶來判斷。為沒有訪問控制權(quán)的個體用戶授予和廢除許可。自主訪問控制機制允許用戶被授權(quán)和取消訪問其控制之下的任何客體（object），換句話說，用戶就是他們控制下的客體的擁有者。對于這些組織，公司或代理機構(gòu)是事實上的系統(tǒng)客體和處理他們的程序的擁有者。訪問優(yōu)先權(quán)受組織控制，而且也常常基于雇員功能而不是數(shù)據(jù)所有權(quán)。

強制訪問控制，在美國國防部 Trusted Computer Security Evaluation Criteria (TCSEC) 中定義如下：“一種限制訪問客體的手段，它以包含在這些客體中的信息敏感性和訪問這些敏感性信息的主體的正式授權(quán)信息（如清除）為基礎(chǔ)”。

什么是基于角色訪問控制（Role-Based Access Control, RBAC）？NIST 有如下定義。

訪問是一種利用計算機資源去做某件事情的的能力，訪問控制是一種手段，通過它這種能力在某些情況下被允許或者受限制（通常是通過物理上和基于系統(tǒng)的控制）?；谟嬎銠C的訪問控制不僅可規(guī)定是“誰”或某個操作有權(quán)使用特定系統(tǒng)資源，而且也能規(guī)定被允許的訪問類型。這些控制方式可在計算機系統(tǒng)或者外部設(shè)備中實現(xiàn)。

就基于角色訪問控制而言，訪問決策是基于角色的，個體用戶是某個組織的一部分。用戶具有指派的角色（比如醫(yī)生、護士、出納、經(jīng)理）。定義角色的過程應(yīng)該基于對組織運轉(zhuǎn)的徹底分析，應(yīng)該包括來自一個組織中更廣范圍用戶的輸入。

訪問權(quán)按角色名分組，資源的使用受限于授權(quán)給假定關(guān)聯(lián)角色的個體。例如，在一個醫(yī)院系統(tǒng)中，醫(yī)生角色可能包括進行診斷、開據(jù)處方、指示實驗室化驗等；而研究員的角色則被限制在收集用于研究的匿名臨床信息工作上。
   
    控制訪問角色的運用可能是一種開發(fā)和加強企業(yè)特殊安全策略，進行安全管理過程流程化的有效手段。

2.     核心對象模型設(shè)計（RBAC0）

根據(jù)RBAC模型的權(quán)限設(shè)計思想，建立權(quán)限管理系統(tǒng)的核心對象模型.對象模型中包含的基本元素主要有：用戶（Users）、用戶組（Group）、角色（Role）、控制對象（Resource Class）、訪問模式（Access Mode）、操作（Operator）。主要的關(guān)系有：分配角色權(quán)限PA（Permission Assignment）、分配用戶角色UA（Users Assignmen描述如下：

1.        控制對象：是系統(tǒng)所要保護的資源（Resource Class），可以被訪問的對象。資源的定義需要注意以下兩個問題：

a)        資源具有層次關(guān)系和包含關(guān)系。例如，網(wǎng)頁是資源，網(wǎng)頁上的按鈕、文本框等對象也是資源，是網(wǎng)頁節(jié)點的子節(jié)點，如可以訪問按鈕，則必須能夠訪問頁面。

b)        這里提及的資源概念是指資源的類別（Resource Class），不是某個特定資源的實例（Resource Instance）。資源的類別和資源的實例的區(qū)分，以及資源的粒度的細分，有利于確定權(quán)限管理系統(tǒng)和應(yīng)用系統(tǒng)之間的管理邊界，權(quán)限管理系統(tǒng)需要對于資源的類別進行權(quán)限管理，而應(yīng)用系統(tǒng)需要對特定資源的實例進行權(quán)限管理。兩者的區(qū)分主要是基于以下兩點考慮：

                         i.              一方面，資源實例的權(quán)限常具有資源的相關(guān)性。即根據(jù)資源實例和訪問資源的主體之間的關(guān)聯(lián)關(guān)系，才可能進行資源的實例權(quán)限判斷。 例如，在管理信息系統(tǒng)中，需要按照營業(yè)區(qū)域劃分不同部門的客戶，A區(qū)和B區(qū)都具有修改客戶資料這一受控的資源，這里“客戶檔案資料”是屬于資源的類別的范疇。如果規(guī)定A區(qū)只能修改A區(qū)管理的客戶資料，就必須要區(qū)分出資料的歸屬，這里的資源是屬于資源實例的范疇?？蛻魴n案（資源）本身應(yīng)該有其使用者的信息（客戶資料可能就含有營業(yè)區(qū)域這一屬性），才能區(qū)分特定資源的實例操作，可以修改屬于自己管轄的信息內(nèi)容。

                       ii.              另一方面，資源的實例權(quán)限常具有相當大的業(yè)務(wù)邏輯相關(guān)性。對不同的業(yè)務(wù)邏輯，常常意味著完全不同的權(quán)限判定原則和策略。

2.        操作（權(quán)限）：完成資源的類別和訪問策略之間的綁定。

3.        用戶：權(quán)限的擁有者或主體。用戶和權(quán)限實現(xiàn)分離，通過授權(quán)管理進行綁定。

4.        用戶組：一組用戶的集合。在業(yè)務(wù)邏輯的判斷中，可以實現(xiàn)基于個人身份或組的身份進行判斷。系統(tǒng)弱化了用戶組的概念，主要實現(xiàn)用戶（個人的身份）的方式。

5.        角色：權(quán)限分配的單位與載體。角色通過繼承關(guān)系支持分級的權(quán)限實現(xiàn)。例如，科長角色同時具有科長角色、科內(nèi)不同業(yè)務(wù)人員角色。

6.        分配角色權(quán)限PA：實現(xiàn)操作和角色之間的關(guān)聯(lián)關(guān)系映射。

7.        分配用戶角色UA：實現(xiàn)用戶和角色之間的關(guān)聯(lián)關(guān)系映射。

3.     HR數(shù)據(jù)權(quán)限模型設(shè)計初稿

3.1.   訪問主體

在本系統(tǒng)中訪問主體是員工和用戶組。

如圖3.1.1中每個主體都有多個角色。每個角色又可能同時屬于多個主體。

公司、部門、職位一定有對應(yīng)的一個用戶組，但用戶組不一定是公司、部門、職位當中一個，也可能是虛擬出來的一個組，比如：工會組織、公司籃球隊等等。

（圖3.1.1）

3.2.   分配用戶角色（Users Assignmen）

如圖3.1.1這里的Users指的是所有訪問主體。用戶組、員工。

用戶組是可以無限制擴充的。

無論添加幾個主體到最后都會映射到角色（roles）表中，成為多個角色。

然后對角色分配訪問權(quán)限控制。

3.3.     操作

操作（權(quán)限）=訪問模式+資源（resource class）

如圖3.3.1，比如：頁面A有個查詢員工信息的功能，我們在這里把他看成一個“訪問客體”，被權(quán)限控制的資源（resource class）。再假設(shè)訪問模式中有個“運行”模式，那么兩者組合起來就是有個有效的操作（權(quán)限），然后把這個權(quán)限賦予角色，就OK了。

（圖3.3.1）

3.4.     分配角色權(quán)限（Permission Assignment）

3.3節(jié)中提到，根據(jù)資源和訪問模式、我們這里就有了很多操作，也就是權(quán)限。

那么我們只需要把這些權(quán)限分配到角色就可以了。如圖3.4.1

（圖3.4.1）

3.5.     資源類別（Resources Class）

根據(jù)以上的描述可以看出來，在本模型中主體是可以無限制擴充的。那么客體呢？我們可以看到，不管你有多少客體，到最后也都是分解成了多個資源類別（和主體一樣，把每個主體都分解成了多個角色），然后和訪問模式組成了操作（權(quán)限），最后賦給角色。

我們再分析下資源類別模型。

我認為我們系統(tǒng)的資源類別可以分為2個方向，頁面功能和流程。

比如：員工資料查詢，這個頁面上就有查詢這個客體資源類別。

而員工轉(zhuǎn)正流程中又有直接主管審批這個資源。

那么我們把資源類別（resources class）設(shè)計成如圖3.5.1

（圖3.5.1）

功能模塊表中存放“流程”或“頁面功能”。

“功能模塊類別”用來區(qū)分，這條記錄是“頁面功能”還是“流程”。

一個流程有多個審批操作。我們可以放到資源類別中。

頁面功能同理。

4.     小結(jié)

該對象模型最終將訪問控制模型轉(zhuǎn)化為訪問矩陣形式。訪問矩陣中的行對應(yīng)于用戶，列對應(yīng)于操作，每個矩陣元素規(guī)定了相應(yīng)的角色，對應(yīng)于相應(yīng)的目標被準予的訪問許可、實施行為。按訪問矩陣中的行看，是訪問能力表CL(Access Capabilities)的內(nèi)容；按訪問矩陣中的列看，是訪問控制表ACL（Access Control Lists）的內(nèi)容。如表4.1

（表4.1）

圖4.1為整個權(quán)限模型。

（圖4.1）

5.     思考

5.1.   相對角色

在很多時候我們都會用到相對角色這個概念。比如：員工轉(zhuǎn)正流程中就有個直接主管審批，那么這個直接主管這個角色就是一個相對角色。這個相對角色在數(shù)據(jù)庫權(quán)限模型中其實也是一個角色，只用添加到角色表中給這個角色賦權(quán)限（操作）就可以了，但在開發(fā)過程中一定要注意相對角色的設(shè)定，特別是設(shè)定方法，公式。

5.2.   用戶組的聯(lián)想

用戶組可以是組織架構(gòu)中的實體單位。同時也可以是虛擬的，由用戶自己添加、配置的一個角色的集合。角色又是權(quán)限的集合。

那么我們可以這么做，添加一個系統(tǒng)管理員組，然后通過角色為這個組，分配好應(yīng)有的權(quán)限。以后如果有新的系統(tǒng)管理員，我們只需要放到這個組里面去就可以，沒必要再重新配置一個用戶。

這樣就完全可以實現(xiàn)windows的權(quán)限管理了。

5.3.   角色的繼承

給角色分配權(quán)限（操作）其實也是件比較復(fù)雜的工作。如果角色間存在一定的關(guān)系，可以直接把另外一個角色的權(quán)限直接復(fù)制過來，然后再添加自己需要的其他權(quán)限，這樣不是會方便很多嗎？

繼承可分為兩種方式，一般繼承關(guān)系和受限繼承關(guān)系。一般繼承關(guān)系僅要求角色繼承關(guān)系是一個絕對偏序關(guān)系（不能繼承自己的子類），允許角色間的多繼承。而受限繼承關(guān)系則進一步要求角色繼承關(guān)系是一個樹結(jié)構(gòu)（單繼承）。

5.4.   資源實例（Resource Instance）

場景1：有一個功能頁面，查詢員工資料。可訪問角色有“人事專員”和“部門經(jīng)理”。“人事專員”進入可以查出全公司的所有員工資料。“部門經(jīng)理”進入后，只能查出自己部門的員工資料。

場景1的解決方案：

1.        在功能模塊（functionmodule）表中添加“查詢員工資料”這個功能。

2.        在功能資源（functionresource）表中添加這個“查詢員工資料”的兩個資源，“部門經(jīng)理查詢”和“人事專員查詢”。

3.        抽象成資源類別（resourcesclass）。

4.        資源類別（resourcesclass）和訪問模式（accessmode）組合成2個操作（權(quán)限）。

5.        把這兩個權(quán)限分別賦予部門經(jīng)理組所擁有的角色和人事專員組所擁有的角色。

6.        在開發(fā)過程中就可以根據(jù)兩個不同的資源，在這個頁面做查詢條件的處理。

場景2：有一個功能頁面，部門花名冊?？稍L問角色有“部門經(jīng)理”和任何登錄后的員工。根據(jù)員工部門自動顯示所在部門的花名冊。如果是“部門經(jīng)理”，就顯示一些“部門經(jīng)理”可以看到的敏感信息。比如，工資。

場景2的解決方案：

1.        在功能模塊（functionmodule）表中添加“部門花名冊”這個功能。

2.        在功能資源（functionresource）表中添加這個“部門花名冊”的一個資源，“部門經(jīng)理花名冊”。

3.        抽象成資源類別（resourcesclass）。

4.        資源類別（resourcesclass）和訪問模式（accessmode）組合成1個操作（權(quán)限）。

5.        把這個權(quán)限賦予部門經(jīng)理組所擁有的角色。

6.        在開發(fā)過程中進入這個功能頁面，沒有這個權(quán)限的顯示一般花名冊。有這個權(quán)限的顯示部門經(jīng)理花名冊。

小結(jié)：

資源實例讓我們在按鈕級權(quán)限的基礎(chǔ)上，加上了對記錄和字段的控制。當然，你也可以把場景1和場景2結(jié)合起來。記錄、字段一起控制，這個肯定是可以的。

再擴展下。場景二中，如果有一天部門經(jīng)理所能看到的東西改變了，加一項或少一項，怎么辦呢？難道去改代碼？

其實在很多情況下，都是可以做死的。比如場景二中大家都只能看到自己部門的花名冊?？隙ú粫幸惶煲垂镜幕麅?，如果真有這個需求，那么就應(yīng)該再做個功能頁面。叫做“公司花名冊”。

但也有些情況，是要可以調(diào)整的。同樣是場景二，部門經(jīng)理能看到的東西。哪天公司想變變，這個也是有可能的。

其實這個功能實現(xiàn)起來也非常簡單。如圖5.4.1。

無論什么，到最后都會變成資源類別，我們直接給這個類別記錄一些屬性。到時候你只要根據(jù)這些屬性顯示就可以了，要變的時候把這些屬性變了就行了。只要愿意，完全可以做個維護頁面。

表資源設(shè)置（resourcesetting）記錄一些訪問條件。比如，這個資源按部門查詢。如果需要你可以把他改成按公司查詢。

表字段設(shè)置（fieldsetting）記錄的是這個資源的字段信息。比如，部門經(jīng)理可以看到“部門花名冊”的字段。

（圖5.4.1）

6.     總結(jié)

本模型的主要設(shè)計思想是把所有訪問主體，包括部門、職位、公司、人等等。全部分解成一個或多個角色。

把所有訪問控制客體全部分解成一個和多個資源類別（Resources Class）。

把資源類別加上訪問模式（讀、寫、刪、運行等）成為一個操作，也就是權(quán)限。

然后把這個權(quán)限賦予到角色。

這個模型支持頁面級權(quán)限、按鈕級權(quán)限、記錄級權(quán)限、字段級權(quán)限和這幾種權(quán)限的任意組合。

在角色的分配上。他本身是支持一個客體有多個角色，一個角色屬于多個客體。支持用戶組角色、角色繼承、相對角色等。特別是用戶組這個設(shè)計。部門、職位、公司這些組織都可以抽象成一個用戶組，直接給這個組分配權(quán)限就可以了。但用戶組不僅僅只有抽象實體組織這功能，他還可以無限制的擴展。比如可以添加一個虛擬的系統(tǒng)管理員組。他本身就是一個員工的集合，你可以以任何形式去組合人員。