中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

在產(chǎn)品設(shè)計中，我們會接觸各種權(quán)限管理模型，但需要先對模型有所了解，才能選擇適合產(chǎn)品本身的模型。這篇文章，作者總結(jié)了七種權(quán)限模型及對應優(yōu)缺點，供大家參考。

1. 目的

探究市面上主流的各類權(quán)限管理模型，如基于用戶、角色組、實體等等的權(quán)限模型，結(jié)合產(chǎn)品本身的業(yè)務、面臨的問題和未來的發(fā)展兼容，進行權(quán)限模型選型，找到適合產(chǎn)品本身的權(quán)限范式體系。

2. 模型

2.1 ACL權(quán)限模型

在OA系統(tǒng)中，接觸了ACL（access control list）模型的權(quán)限設(shè)計。ACL是一種面向資源的訪問控制模型。ACL實體模型的核心在于用戶可以直接和權(quán)限掛鉤，權(quán)限模型包括：資源標識、用戶標識、授權(quán)狀態(tài)。

ACL的原理為：每一項資源，都配有一個列表，這個列表記錄的就是哪些用戶可以對這項資源執(zhí)行增加(Create)、檢索(Retrieve)、更新(Update)和刪除(Delete)等操作。當用戶試圖訪問這項資源時，會首先檢查這個列表中是否有關(guān)于當前用戶的訪問權(quán)限，從而確定當前用戶是否可執(zhí)行相應的操作?？傮w來說，ACL是一種面向資源的訪問控制模型，它的機制是圍繞“資源”展開的。

優(yōu)點：

• ACL權(quán)限模型原理簡單，直接將權(quán)限賦給用戶，便于理解和操作。
• 可以滿足個性化的需求，即為系統(tǒng)中的用戶單獨分配權(quán)限。

缺點：

• 由于需要維護每個用戶的訪問權(quán)限列表，管理者工作量大，所以需要解決復用性問題。

改進：

ACL不僅記錄用戶—資源—操作表，還記錄用戶組—資源—操作表，用于記錄用戶或者用戶組對資源擁有的權(quán)限。改進之后的權(quán)限模型包括：資源標識、主體標識、主體類型（用戶或用戶組）、授權(quán)狀態(tài)。

2.2 RBAC權(quán)限模型

RBAC（Role-Based Access Control ）基于角色的訪問控制。RBAC認為權(quán)限的過程可以抽象概括為：判斷【W(wǎng)ho對What是否可進行How的訪問操作】：

• Who：權(quán)限的擁用者或主體（如Principal、User、Group、Role、Actor等等）。
• What：權(quán)限針對的對象或資源（Resource、Class）。
• How：具體的權(quán)限（Privilege，正向授權(quán)與負向授權(quán)）。

RBAC的核心思想就是將訪問權(quán)限與角色相關(guān)聯(lián)，通過給用戶分配適合的角色，讓用戶與訪問權(quán)限相聯(lián)系。角色是根據(jù)組織內(nèi)為完成各種不同的任務需要而設(shè)置的，根據(jù)用戶在組織中的職權(quán)和責任來設(shè)定他們的角色，用戶可以在角色間進行轉(zhuǎn)換，系統(tǒng)可以添加、刪除角色，還可以對角色的權(quán)限進行添加、刪除。這樣通過應用RBAC可將安全性放在一個接近組織結(jié)構(gòu)的自然層面上進行管理。權(quán)限被賦予角色,而不是用戶，當一個角色被指定給一個用戶時，此用戶就擁有了該角色所包含的權(quán)限。一個用戶擁有若干角色，一個角色擁有若干權(quán)限，這就構(gòu)成“用戶-角色-權(quán)限”的授權(quán)模型。

在RBAC之中，用戶和角色是多對多的關(guān)系，角色與權(quán)限也是多對多關(guān)系：

• 一個用戶在不同的場景下可以擁有不同的角色，例如項目經(jīng)理也可以是項目架構(gòu)師等。
• 一個角色可以給多個用戶，例如一個項目中有多個組長，多個組員等。
• 一個角色可以擁有多項權(quán)限，同一個權(quán)限也可以授給多個角色。

RBAC引入了角色的概念，目的是為了隔離用戶與權(quán)限。角色（Role）作為一個用戶（User）與權(quán)限（Privilege）的代理層，解耦了權(quán)限和用戶的關(guān)系，所有的授權(quán)應該給予角色而不是直接給用戶。

基于角色的訪問控制方法（RBAC）的顯著的兩大特征是：

1.由于角色/權(quán)限之間的變化比角色/用戶關(guān)系之間的變化相對要慢得多，減小了授權(quán)管理的復雜性，降低管理成本。

2.靈活地支持企業(yè)的安全策略，并對企業(yè)的變化有很大的伸縮性。

優(yōu)點：

• RBAC是把用戶按角色進行歸類，通過用戶的角色來確定用戶能否針對某項資源進行某項操作。相對于ACL最大的優(yōu)勢就是它簡化了用戶與權(quán)限的管理，通過對用戶進行分類，使得角色與權(quán)限關(guān)聯(lián)起來，而用戶與權(quán)限變成了間接關(guān)聯(lián)，從而解耦。
• 通過對角色設(shè)置權(quán)限，可一次性對角色下的所有用戶設(shè)置權(quán)限。在角色組中增刪單個成員，也不會對角色組整體產(chǎn)生影響。

缺點：

• 由于權(quán)限是以角色為載體分配的，因此無法對某一角色下的個別用戶需要進行特別的權(quán)限定制，只能再重新創(chuàng)建角色。即不可對角色組下的單個成員進行個性化權(quán)限設(shè)置。
• RBAC模型只給角色賦予了權(quán)限，沒有提供這些權(quán)限的操作順序控制機制。這一缺陷使得RBAC模型很難應用關(guān)于那些要求有嚴格操作順序的實體系統(tǒng)。例如，在購物控制系統(tǒng)中要求系統(tǒng)對購買步驟的控制，在客戶未付款之前不應讓他把商品拿走。RBAC模型要求把這種控制機制放到權(quán)限模型中預設(shè)好。

改進：

原來模型關(guān)系為“用戶—角色—權(quán)限”，為了解決個性化問題，可在此基礎(chǔ)上，增加“用戶—權(quán)限”的關(guān)聯(lián)關(guān)系。除了可以給角色授權(quán)外，還可以給用戶直接授權(quán)。這樣一來，用戶擁有的所有權(quán)限，就是用戶個人擁有的權(quán)限與該用戶所在角色擁有的權(quán)限之和。

2.3 DAC權(quán)限模型

DAC是自主訪問控制模型。定義：規(guī)定資源可以被哪些主體進行哪些操作，同時，主體可以將資源、操作的權(quán)限，授予其他主體。

在ACL的基礎(chǔ)上，DAC模型將授權(quán)的權(quán)力下放，允許擁有權(quán)限的用戶，可以自主地將權(quán)限授予其他用戶。

DAC的應用場景：DAC常見于文件系統(tǒng)，LINUX，UNIX、WindowsNT版本的操作系統(tǒng)都提供DAC的支持。在實現(xiàn)上，先對用戶鑒權(quán)，然后根據(jù)控制列表決定用戶能否訪問資源。用戶控制權(quán)限的修改通常由特權(quán)用戶或者管理員組實現(xiàn)。

缺點：

• DAC最大缺陷是對權(quán)限控制過于分散，比如無法簡單地將一組文件設(shè)置統(tǒng)一的權(quán)限開放給指定的一群用戶。
• 主體的權(quán)限太大，授權(quán)其他用戶時，無意間可能造成泄露信息。

2.4 MAC權(quán)限模型

MAC是強制訪問控制模型，是為了彌補DAC權(quán)限控制過于分散的問題而誕生的。主體被賦予一定的安全級別，客體被賦予一定的安全級別，主體能否訪問客體由雙方的關(guān)系安全級別決定，這個判斷通常有系統(tǒng)硬性限制。

定義：當一個操作，同時滿足a與b時，允許操作

• a. 規(guī)定資源可以被哪些類別的主體進行哪些操作
• b. 規(guī)定主體可以對哪些等級的資源進行哪些操作

MAC是在ACL基礎(chǔ)上的另一種實現(xiàn)，強調(diào)安全性。MAC會在系統(tǒng)中，對資源與主體，都劃分類別與等級。MAC非常適合機密機構(gòu)或者其他等級觀念強烈的行業(yè)，但對于類似商業(yè)服務系統(tǒng)，則因為不夠靈活而不能適用。MAC可以繼續(xù)使用DAC的模型，但是要對用戶進行等級劃分，比如一級，二級，三級……，對對象資源也要做劃分，比如機密，秘密和最高機密。用戶訪問的資源的時候，根據(jù)用戶等級與資源訪問級別來做判斷，比如一級用戶只能訪問機密文件，如果訪問的是最高機密文件，系統(tǒng)就會拒絕。這一系列規(guī)則是優(yōu)先于DAC的，如果MAC與DAC混用，要先校驗MAC再校驗DAC。

優(yōu)點：

MAC的優(yōu)勢就是實現(xiàn)資源與主體的雙重驗證，確保資源的交叉隔離，提高安全性。

缺點：

只適用于特定的安全性高要求較高的場景。過重強調(diào)保密性，使得管理不夠靈活。

改進：

在實現(xiàn)上，MAC和DAC通常為每個用戶賦予對客體的訪問權(quán)限規(guī)則集，考慮到管理的方便，在這一過程中還經(jīng)常將具有相同職能的用戶聚集為組，然后再為每個用戶組分配權(quán)限。

2.5 ABAC權(quán)限模型

ABAC是基于屬性的訪問控制權(quán)限模型。定義：規(guī)定哪些屬性的主體可以對哪些屬性的資源在哪些屬性的環(huán)境下進行哪些操作屬性。

ABAC其中的屬性就是與主體、資源、環(huán)境相關(guān)的所有信息：

• 主體的屬性：指的是與主體相關(guān)的所有信息，包括主體的年齡、性別、職位等。
• 資源的屬性：指的是與資源相關(guān)的所有信息，包括資源的創(chuàng)建時間、創(chuàng)建位置、密級等。
• 環(huán)境的屬性：指的是客觀情況的屬性，比如當前的時間、當前的位置、當前的場景（普通狀態(tài)、緊急狀態(tài)）。
• 操作屬性：指的是可進行的全部操作，如增刪改查等。

當企業(yè)中參與權(quán)限管理的用戶數(shù)量很多、或者角色數(shù)量很多時，傳統(tǒng)的RBAC模型會顯露出一些缺點，比如容易遺漏需要參與到權(quán)限管理的部分用戶，并且容易受到“角色數(shù)量爆炸”的影響。RBAC雖然是目前最普遍的權(quán)限控制模型。

但是某些情況下，RBAC是無法滿足并且也實現(xiàn)不了的。比如業(yè)務員1和業(yè)務員2都屬于業(yè)務員角色，都有查看客戶訂單的權(quán)限。當有一個需求，要求業(yè)務員1只能查看北京地區(qū)的客戶的訂單，業(yè)務員2只能查看上海的客戶的訂單。這單單使用RBAC是無法實現(xiàn)。借助RBAC，可行的做法是，分地區(qū)創(chuàng)建角色，然后程序中根據(jù)角色做數(shù)據(jù)的過濾，這種做法缺點是，每次需求變更的時候可能都需要修改代碼。

此時需要新的權(quán)限管理方法來控制對企業(yè)的訪問，允許特定用戶在特定場景下?lián)碛刑囟?quán)限。通?？紤]的第一種解決方案是基于屬性的訪問控制（ABAC），會在系統(tǒng)中設(shè)置好基于用戶屬性、資源屬性、環(huán)境屬性和操作權(quán)限的預定義規(guī)則，當某個用戶進入到系統(tǒng)中時，會獲取用戶和當前場景的屬性，基于這些屬性，自動為該用戶分配權(quán)限。所以說，ABAC中可以完全自動化——可根據(jù)所獲取到的屬性進行自動判定和授權(quán)，而不需要使用管理員手動設(shè)置授權(quán)。

傳統(tǒng)的 RBAC 與 ACL 等訪問控制機制，可以認為是 ABAC 的子集。

對于 RBAC來說，訪問機制的實現(xiàn)只是基于主體的屬性“角色”而已，ACL 只是基于主體的屬性是“單個用戶”。而ABAC 基于更多的屬性，能做到更細粒度的授權(quán)管理。例如，ABAC權(quán)限模型中通過眾多屬性來決策實現(xiàn)，只有姓張的工程師在處理項目A時才能訪問某個資源，其中“姓張、工程師、項目A”都是決策所依據(jù)的屬性。因此，ABAC模型不需要關(guān)注特定的用戶好角色，只需要對提煉出的各種“屬性”進行授權(quán)規(guī)則設(shè)置，管理對象為屬性和權(quán)限。

ABAC對用戶本身的屬性進行標識，通過屬性標識來判斷用戶權(quán)限。這樣的設(shè)計使得ABAC非常靈活，可擴展性也很高。ABAC一般來說，都是搭配著ACL或RBAC一起使用，不會單獨成體系。以上述業(yè)務員查看訂單為例，說明ABAC的一種實現(xiàn)方式：

• 在RBAC的基礎(chǔ)上，擴展一個實體規(guī)則。其中，訂單就是實體，地區(qū)是實體的屬性。
• 然后針對實體（訂單）的屬性（地區(qū)）設(shè)置一系列規(guī)則。規(guī)則存儲格式可以是json、SQL語句等等，能解析即可。規(guī)則為：業(yè)務員1只能查看北京地區(qū)的客戶的訂單，業(yè)務員2只能查看上海的客戶的訂單。
• 保存規(guī)則，包括規(guī)則內(nèi)容(即json、SQL語句等)、規(guī)則實體(即訂單)、適用操作（即增刪改查等）。
• 將創(chuàng)建好實體的規(guī)則與角色做關(guān)聯(lián)，也就是將北京地區(qū)的規(guī)則關(guān)聯(lián)到北京地區(qū)業(yè)務員角色上，上海地區(qū)的規(guī)則關(guān)聯(lián)到上海地區(qū)業(yè)務員角色上。
• 后端做權(quán)限校驗的時候，還是先按RBAC模型的控制方式進行校驗(是否具備訂單查看權(quán)限)，然后根據(jù)當前操作對象(也就是實體)，取出用戶所屬角色關(guān)聯(lián)的對應實體的規(guī)則。然后解析規(guī)則，動態(tài)拼接Sql語句。

以上只是針對地區(qū)屬性實現(xiàn)了動態(tài)權(quán)限控制。實際業(yè)務中，要控制可能更多，比如字段權(quán)限、數(shù)據(jù)范圍等等。要滿足這些復雜的控制，需要制定一套完整的規(guī)則，以及針對規(guī)則編寫相應的解析程序。

優(yōu)點：

• 可適用于用戶數(shù)量和角色數(shù)量很多的權(quán)限管理場景，在設(shè)置好預定義規(guī)則之后，系統(tǒng)可對用戶進行自動授權(quán)，不需要使用管理員手動設(shè)置授權(quán)。

缺點：

• 當采用ABAC模型時，隨著屬性數(shù)量的不斷增加，定義與單個用戶相關(guān)聯(lián)的每個屬性的復雜性也隨之增加，從而增加了管理整個企業(yè)的訪問管理的難度。需要IT團隊部署和維護。
• 實現(xiàn)成本高：ABAC非常的靈活，但是實現(xiàn)比較困難。這其中涉及到邏輯的動態(tài)執(zhí)行，數(shù)據(jù)動態(tài)過濾等，更加具體就是動態(tài)拼接SQL語句。

基于屬性的訪問控制模型(ABAC)被認為是訪問控制模型的未來。但并不是當前權(quán)限管理場景下的最優(yōu)方案。

2.6 TBAC權(quán)限模型

TBAC是基于任務的訪問控制模型。它從工作流中的任務角度建模,可以依據(jù)任務和任務狀態(tài)的不同,對權(quán)限進行動態(tài)管理。適用于工作流、分布式處理和事務管理系統(tǒng)中的決策制定與權(quán)限管理。

ACL、RBAC、DAC、MAC都是從系統(tǒng)的角度(控制環(huán)境是靜態(tài)的)出發(fā)保護資源。其訪問控制的原理可以簡單地描述為:如果主體對某客體有訪問操作請求,而且主體擁有操作權(quán)限,則提供訪問操作。

工作流是為完成某一目標而由多個相關(guān)的任務(即活動)構(gòu)成的業(yè)務流程。工作流所關(guān)注的問題是處理過程的自動化，對人和其他資源進行協(xié)調(diào)管理，從而完成整個工作流程。當數(shù)據(jù)在工作流中流動時,執(zhí)行操作的用戶在改變，用戶的權(quán)限也在改變，這與數(shù)據(jù)處理的前后節(jié)點環(huán)境相關(guān)。采用傳統(tǒng)的訪問控制技術(shù)，如 DAC、MAC等，則難以做到這一點；若采用 RBAC，也需要頻繁地更換角色，且不適合工作流程的運轉(zhuǎn)。TBAC則可對工作流中的各任務節(jié)點進行動態(tài)權(quán)限管理。在 TBAC 中，主體（即角色組等）的訪問權(quán)限并不是靜止不變的，而是隨著工作流的任務流轉(zhuǎn)不斷發(fā)生變化。在工作流中，每一步對數(shù)據(jù)的處理都與以前的處理相關(guān)，相應的訪問控制也是這樣，因而TBAC是一種與前后任務節(jié)點相關(guān)的訪問控制模型。

基于任務的權(quán)限模型有以下特點：

• TBAC不僅能對不同工作流實行不同的訪問控制策略,也能對同一工作流的不同任務節(jié)點實行不同的訪問控制策略。
• 因為任務都有時效性（即工作流流轉(zhuǎn)到下個任務節(jié)點時，當前任務節(jié)點時效結(jié)束），所以TBAC中，用戶對于授予他的權(quán)限使用也是有時效性的。

優(yōu)點：

在業(yè)務流、工作流等特定情況下，可以動態(tài)管理權(quán)限，比傳統(tǒng)的靜態(tài)權(quán)限模型更貼合場景。

缺點：

實現(xiàn)成本高，需要IT團隊開發(fā)和維護。工作流的任務節(jié)點數(shù)量和形式可能不固定，各節(jié)點的流轉(zhuǎn)要求也不盡相同，每次進行調(diào)整時都要對權(quán)限模型進行修改。只有在結(jié)構(gòu)穩(wěn)定工作流中，才可穩(wěn)定運行。

2.7 EBAC權(quán)限模型

EBAC是基于受控實體的訪問控制技術(shù)。對各種客觀存在的和邏輯定義的企業(yè)信息資源（即主體擁有訪問權(quán)限的客體），定義為受控實體。

傳統(tǒng)的訪問控制策略 DAC和 MAC存在安全缺陷和應用復雜性等問題，當前企業(yè)應用系統(tǒng)中采用較多的是RBAC。在訪問控制對象和操作比較明確的系統(tǒng)中，RBAC 能夠提供一種靈活、有效的用戶行為能力的組織機制。但 RBAC 是一種被動的、提前授權(quán)的訪問控制技術(shù)，主體可以無限制使用其擁有的客體及客體資源的訪問權(quán)限，不能依據(jù)操作環(huán)境進行訪問主體和客體的動態(tài)變更。

TBAC通過對工作流中任務步驟的動態(tài)授權(quán)，可以清晰地表達復雜工作流的控制機制，主體權(quán)限的時效性也因任務的時效性得以解決，在一定程度上能夠?qū)崿F(xiàn)授權(quán)管理的自動化。但是TBAC強調(diào)工作流各任務的原子性，受限于工作流和任務的數(shù)量，造成權(quán)限配置的復雜性。其次，主體訪問權(quán)限的動態(tài)性和頻繁改變的特性，增加了系統(tǒng)安全控制實現(xiàn)的難度，也給整個系統(tǒng)的運行效率造成影響。

EBAC模型以受控實體為訪問客體，并以其為中心實現(xiàn)安全控制機制。一方面，用戶通過對受控實體的管理，間接獲取訪問權(quán)限；另一方面，受控實體可動態(tài)地對用戶權(quán)限集和屬性集的訪問進行自主控制。EBAC 是一個隨受控實體業(yè)務調(diào)度變化的動態(tài)訪問控制模型。

EBAC 充分利用企業(yè)資源類屬的有限性和依據(jù)管理策略組織的特性，以受控實體為訪問客體，并由其自主控制訪問主體對訪問客體權(quán)限集和屬性集的訪問能力，采用靜態(tài)權(quán)限分配和動態(tài)權(quán)限授予相結(jié)合的方式。

3. 分析

3.1 ACL與RBAC模型改進比較

ACL由于用戶和權(quán)限直接掛鉤，可以滿足個性化，即為系統(tǒng)中的用戶單獨分配權(quán)限；RBAC由于角色和權(quán)限直接掛鉤，使得權(quán)限可以被復用，把用戶按角色進行歸類。

兩種模型的改進，都是為了彌補自身不足而演變而來的，即ACL需要解決復用性問題，RBAC需要解決個性化問題。其實，兩種改進模型都駛向了一個平衡點，雖然RBAC改進模型中會讓表個數(shù)增多，但是原理還是一樣的。

RBAC在ACL的基礎(chǔ)上加入了角色的概念，權(quán)限列表或訪問控制列表里維護的不再是用戶與功能的關(guān)系，而是角色與功能的關(guān)系。ACL可以和RBAC混著用，既可以在角色上設(shè)置權(quán)限，也可以直接給用戶設(shè)置權(quán)限，更加靈活。借助角色的思想，可以在用戶組，組織，職位等等上設(shè)置權(quán)限，以便更好的做好權(quán)限管理，也就是將權(quán)限設(shè)置從單一個體轉(zhuǎn)移到某一類組合上。

3.2 RBAC與ABAC模型比較

RBAC權(quán)限模型是粗粒度和靜態(tài)的權(quán)限模型，ABAC是細粒度和動態(tài)的權(quán)限模型。

要真正的落地實現(xiàn)ABAC比較復雜。每次都要針對具體情況獲取屬性解析規(guī)則，對程序的性能也會造成影響，就算使用緩存，命中的概率也是非常的小，因為很多因素都是動態(tài)的。所以，如果需要根據(jù)屬性做權(quán)限判斷的場景不是很多的話，還是建議使用RBAC，在程序中做判斷也比較省事省力。

3.3 ABAC與TBAC模型比較

ABAC、TBAC模型都是動態(tài)授權(quán)模型。但兩種模型做出動態(tài)配置的依據(jù)不同，ABAC模型是根據(jù)主體、資源和環(huán)境做出動態(tài)權(quán)限配置。TBAC模型是根據(jù)任務和任務狀態(tài)做出動態(tài)權(quán)限配置。

4. 總結(jié)

權(quán)限系統(tǒng)作為中后臺的基礎(chǔ)能力之一，能夠讓不同組織下的不同人員專注于自己的工作領(lǐng)域，降低數(shù)據(jù)風險，實現(xiàn)人員和數(shù)據(jù)的高效管理。

在選擇權(quán)限模型時：

• 面向用戶量和權(quán)限量少、更新頻次低、無明確職能劃分的小型組織進行權(quán)限設(shè)計時，可以考慮參考開發(fā)成本低的ACL權(quán)限列表權(quán)限設(shè)計，基于賬號進行授權(quán)設(shè)計；
• 面向用戶量和權(quán)限量多、更新頻次多、有明確職能劃分的中型組織進行權(quán)限設(shè)計時，可以考慮維護成本低的RBAC角色權(quán)限設(shè)計，基于角色進行授權(quán)設(shè)計；面向用戶量和權(quán)限量多、更新頻次高、無明確職能劃分、有安全合規(guī)訴求、權(quán)限定制多樣化的大型組織，可以考慮在保障效率的同時降低安全風險的ABAC屬性權(quán)限設(shè)計，基于屬性規(guī)則進行授權(quán)設(shè)計。

在權(quán)限設(shè)計時需要基于業(yè)務角度考慮多個方面：

• 頁面的賦權(quán)設(shè)計需要注意關(guān)聯(lián)體現(xiàn)頁面間的層級關(guān)系與對應操作權(quán)限；
• 操作的賦權(quán)設(shè)計需要注意數(shù)據(jù)狀態(tài)變化導致的操作變化；
• 數(shù)據(jù)的賦權(quán)設(shè)計需要注意多業(yè)務數(shù)據(jù)是否需要基于安全性進行分隔處理。