[https://www.jianshu.com/p/2a07763bc81f](https://www.jianshu.com/p/2a07763bc81f) [http://www.woshipm.com/pd/2310691.html/comment-page-1](http://www.woshipm.com/pd/2310691.html/comment-page-1)  ##### 權限一句話來理解就是對資源的控制，對web應用來說就是對url的控制 權限系統理解透徹了很簡單的，就是**用戶和資源**！你的頁面也好，輸入框或者按鈕也罷，甚至列表里面的一行或一列，都可以理解為資源。然后，不就是A可以訪問某個頁面而B不可以，C可以錄入數據而D只能看么？所以說： **權限就是用戶使用資源的規則** 在這個規則里面，根本性的數據只有用戶和資源，但因為用戶太多，不方便授權操作，所以引入了角色、用戶組、組織機構等等。通過角色進行授權，又通過用戶組、職位這些關聯用戶可以大大減少具體的授權操作工作量。所以一個完善的權限系統，是必然要包含這些的。 ***** 編輯、查看、審核、刪除 、添加、數據管理、權限管理 ACL, DAC, MAC, RBAC, ABAC模型的不同應用場景 ### **ACL 訪問控制列表**  >[info] 規定**資源**可以被哪些**主體**進行哪些**操作** `ACL`是`Access Control List`的縮寫，稱為訪問控制列表. 定義了誰（用戶）可以對某個數據進行何種操作（權限）. 關鍵數據模型有: 用戶, 權限. ACL規則簡單, 也帶來一些問題: 資源的權限需要在用戶間切換的成本極大; 用戶數或資源的數量增長, 都會加劇規則維護成本; #### 典型應用 1. 文件系統 文件系統的文件或文件夾定義某個賬號(user)或某個群組(group)對文件(夾)的讀(read)/寫(write)/執行(execute)權限.  2. 網絡訪問 防火墻: 服務器限制不允許指定機器訪問其指定端口, 或允許特定指定服務器訪問其指定幾個端口. 3. 場景：部門隔離 適用資源：客戶頁面、人事頁面 在ACL權限模型下，權限管理是圍繞**資源**來設定的。我們可以對不同部門的頁面設定可以訪問的用戶。配置形式如下： ~~~ ACL配置表 資源: 客戶頁面 主體: 銷售部（組） 操作：增刪改查 主體: 王總（用戶） 操作: 增刪改查 資源: 人事頁面 主體: 王總（組） 操作: 增刪改查 ~~~ 注：主體可以是用戶，也可以是組。 在維護性上，一般在粗粒度和相對靜態的情況下，比較容易維護。 在細粒度情況下，比如將不同的客戶視為不同的資源，1000個客戶就需要配置1000張ACL表。如果1000個客戶的權限配置是有規律的，那么就要對每種資源做相同的操作；如果權限配置是無規律的，那么ACL不妨也是一種恰當的解決方案。 在動態情況下，權限經常變動，每添加一名員工，都需要配置所有他需要訪問的資源，這在頻繁變動的大型系統里，也是很難維護的。 在一些情況下，ACL也可應用于細粒度場景，接下來將介紹兩種ACL的拓展。 * * * ### **DAC 自主訪問控制** >[info] 規定**資源**可以被哪些**主體**進行哪些**操作** > 同時，**主體**可以將**資源**、**操作**的權限，授予其他**主體** 場景：文件系統 適用資源：人事培訓文檔 DAC是ACL的一種實現，強調靈活性。純粹的ACL，權限由中心管理員統一分配，缺乏靈活性。為了加強靈活性，在ACL的基礎上，DAC模型將授權的權力下放，允許擁有權限的用戶，**可以自主地將權限授予其他用戶**。 比如，在純粹ACL模型下，每次新人培訓，人事總監都要通知IT部，將培訓文檔的訪問權限授予新人。在DAC模型下，人事總監只需將文檔的訪問權限授予人事專員。之后，每次新人培訓，由人事專員將文檔的訪問權限授予不同的新人。 * * * ### **MAC 強制訪問控制** >[info] a. 規定**資源**可以被哪些**類別的主體**進行哪些**操作** > b. 規定**主體**可以對哪些**等級的資源**進行哪些**操作** > 當一個操作，同時滿足a與b時，允許操作。  場景：保密系統 適用資源：機密檔案 MAC是ACL的另一種實現，強調安全性。MAC會在系統中，對資源與主體，都劃分類別與等級。比如，等級分為：秘密級、機密級、絕密級；類別分為：軍事人員、財務人員、行政人員。 比如，一份機密級的財務檔案，可以確保只有主體的等級是機密級，且是財務人員才能訪問。如果是機密級的行政人員就無法訪問。 ~~~text 資源配置表 資源: 財務文檔 主體: 財務人員 等級：機密級 操作：查看 主體配置表 主體: 李女士 類別: 財務人員 等級：機密級 ~~~ 所以，MAC的優勢就是實現資源與主體的雙重驗證，確保資源的交叉隔離，提高安全性。 * * * ### **RBAC 基于角色的訪問控制** `RBAC`是`Role-based access control`的縮寫, 稱為 基于角色的訪問控制. 核心數據模型有: 用戶, 角色, 權限. * 權限：規定**角色**可以對哪些**資源**進行哪些**操作** * 角色：規定**主體**擁有哪些**角色**，一個角色，可擁有多個權限 * 賬戶：成員用賬戶登陸管理后臺，賬戶對應角色 如果層級比較深，業務線條多，可以增加‘部門’，用以抽象角色，方便更高效配置。比如銷售部門下，有助理和經理兩個角色，他們擁有銷售部共同的權限，也擁有各自角色不同權限，助理只能看到自己的銷售額，經理可以看到部門銷售總額。 用戶具有角色, 而角色具有權限, 從而表達用戶具有權限. 由于有角色作為中間紐帶, 當新增用戶時, 只需要為用戶賦予角色, 用戶即獲得角色所包含的所有權限. ## 權限有哪些 模型中權限這個元素，按顆粒度從大到小，可以分為： * 導航：由路由控制，是否可以訪問一組頁面 * 頁面：是否可以訪問某個頁面 * 操作：訪問某個頁面時，按鈕是否可以見，可否增刪改查 * 字段：頁面中某個字段是否可見、是否可編輯 導航權限最好實現，適用簡單管理后臺上線初期，協作者少的項目。比如電商業務開始只有商品和客服兩組人，商品要管理品類、上傳編輯商品、發起折扣；客戶要回復留言、查看購買記錄。如此組織，可將‘商品模塊’和‘客服模塊’的權限以導航組織，一級導航下整組頁面，所有數據可見，所有操作可執行。只是和開發商量好，設計數據結構和邏輯規則時考慮擴展性，準備好未來細化到操作甚至字段級別的顆粒度。 操作級別的權限，如果技術是微服務架構，可以做成以url控制操作。比如按鈕點擊時，訪問url，不同權限，可訪問不同url；未授權時點擊按鈕操作無效。若希望按鈕完全不可見，需要前端增加判斷。 字段級別，是最精細的權限控制。比如電銷人員瀏覽客戶信息時，電話號碼不可見，客服人員看到客戶銷售訂單時，銷售金額不可見；權限設計時，需要隱藏頁面上相應字段。 ## 任意組合權限，給誰？ 上述這些不同顆粒度權限，相互組合之后，分配給不同角色。比如電商中，創建以一個角色‘商品運營’，這個角色擁有權限可以這樣描述：可以訪問和編輯‘商品’一級導航下所有頁面。因為業務線上不止一個員工，‘商品運營’這個角色，可以有多個人承擔；在這些員工自己賬號下，分配‘商品運營’角色。 用角色作為權限和賬號的中介，最大好處在一次批量配置，不用每個賬號單獨配置。 ## 界面怎么畫？ 如果只要導航級別權限，其實只需要兩個頁面。一個角色頁面，一個賬戶頁面。角色頁面主體是角色列表，可新建角色，新建時勾選權限。賬戶頁面主體是賬戶列表，可新建賬戶，新建時選擇賬戶對應的角色。 更多具體細節，可以看SAAS產品的幫助文檔，因為是給客戶用的，文檔會有教科書級別的頁面和描述，比如某CRM產品權限模塊使用說明： > 如果員工沒有某對象“查看列表”的權限，則該對象的功能入口會被隱藏 如果員工沒有某對象的操作點權限，則在對象頁面上隱藏相應操作按鈕 如果員工沒有某對象的指定字段的可見權限，則在對象頁面上隱藏相應字段 `RBAC`存在多個擴展版本, `RBAC0`、`RBAC1`、`RBAC2`、`RBAC3`。這些版本的詳細說明可以參數[這里](https://www.jianshu.com/p/b078abe9534f)。我們在實際項目中經常使用的是`RBAC1`，即帶有角色繼承概念的RBAC模型。 RBAC其實是一種分析模型，主要分為：基本模型RBAC0（Core RBAC）、角色分層模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和統一模型RBAC3（Combines RBAC）。 #### **1）RBAC0** RBAC0，它是RBAC0的核心，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的擴展。RBAC0定義了能構成RBAC控制系統的最小的元素集合，RBAC0由四部分構成： * a、用戶（User） * b、角色（Role） * c、會話（Session） * d、許可（Pemission）,其中許可又包括“操作”和“控制對象”其中許可被賦予角色，而不是用戶，當一個角色被指定給一個用戶時，此用戶就擁有了該角色所包含的許可。會話是動態的概念，用戶必須通過會話才可以設置角色，是用戶與激活的角色之間的映射關系。 ##### 如圖，用戶與角色是多對多的關系；角色和許可也是多對多的關系；用戶與會話是一對一關系；會話與角色是一對多關系；  #### **2）RBAC1** RBAC1，它是RBAC角色的分層模型，RBAC1建立在RBAC0基礎之上，在角色中引入了繼承的概念，有了繼承那么角色就有了上下級或者等級關系，角色間的繼承關系可分為一般繼承關系和受限繼承關系。一般繼承關系僅要求角色繼承關系是一個絕對[偏序關系](https://link.jianshu.com?t=http://baike.baidu.com/view/1469650.htm)，允許角色間的多繼承。而受限繼承關系則進一步要求角色繼承關系是一個樹結構，實現角色間的單繼承。 這種模型合適于角色之間的層次明確，包含明確。  #### **3）RBAC2** RBAC2，它是RBAC的約束模型，RBAC2也是建立的RBAC0的基礎之上的，在RBAC0基礎上假如了約束的概念，主要引入了靜態職責分離SSD(Static Separation of Duty)和動態職責分離DSD(Dynamic Separation of Duty)。 ##### SSD是用戶和角色的指派階段加入的，主要是對用戶和角色有如下約束: * a、互斥角色：同一個用戶在兩個互斥角色中只能選擇一個 * b、基數約束：一個用戶擁有的角色是有限的，一個角色擁有的許可也是有限的 * c、先決條件約束：用戶想要獲得高級角色，首先必須擁有低級角色 ##### DSD是會話和角色之間的約束，可以動態的約束用戶擁有的角色，如一個用戶可以擁有兩個角色，但是運行時只能激活一個角色。  #### **4）RBAC3** RBAC3，它是RBAC1與RBAC2合集，所以RBAC3是既有角色分層又有約束的一種模型  場景：企業數據 適用資源：客戶信息 RBAC的思想，來源于現實世界的企業結構。比如，銷售角色，擁有查看客戶信息的權限。當一個銷售人員小王入職了，可以把銷售角色賦予小王，那么小王就擁有了查看客戶的權限。這種方式，避免了ACL模型下，每次新人入職，需要逐個配置資源表的情況。同樣，權限變動也變得很方便，只要修改角色，即可實現多用戶的權限修改。 **權限表** ~~~ 名稱：創建客戶 資源: 客戶信息 操作：創建 名稱：刪除客戶 資源: 客戶信息 操作：刪除 名稱：查看客戶 資源: 客戶信息 操作：查看 名稱：修改客戶 資源: 客戶信息 操作：修改 ~~~ **角色表** ~~~ 名稱：銷售角色 權限: 創建客戶、刪除客戶、查看客戶、修改客戶 ~~~ **用戶表** ~~~ 主體：小王 角色: 銷售角色 ~~~ RABC并不總能滿足所有權限的場景。比如，我們無法對銷售角色，進行個體定制。比如，銷售角色擁有創建、刪除的權限。如果我們要對銷售小李，去掉刪除的權限。那么，我們就必須創建另一個角色，來滿足需求。如果這種情況很頻繁，就會喪失角色的統一性，降低系統的可維護性。 角色和組兩個概念可能會讓人混淆，在這里做個區分： * 角色賦予的是主體，主體可以是用戶，也可以是組 * 角色是權限的集合 * 組是用戶的集合 * * * ### **ABAC 基于屬性的訪問控制** >[info] 規定哪些**屬性的主體**可以對哪些**屬性的資源**在哪些**屬性的情況**下進行哪些**操作**， `ABAC`是`Attribute-based access control`的縮寫, 稱為基于屬性的訪問控制. 權限和資源當時的狀態(屬性)有關, 屬性的值可以用于正向判斷(符合某種條件則通過), 也可以用于反向判斷(符合某種條件則拒絕): #### 典型應用 1. 論壇的評論權限, 當帖子是鎖定狀態時, 則不再允許繼續評論; 2. Github 私有倉庫不允許其他人訪問; 3. 發帖者可以編輯/刪除評論(如果是RBAC, 會為發帖者定義一個角色, 但是每個帖子都要新增一條用戶/發帖角色的記錄); 4. 微信聊天消息超過2分鐘則不再允許撤回; 5. 12306 只有實名認證后的賬號才能購票; 6. 已過期的付費賬號將不再允許使用付費功能; 場景：防火墻 適用資源：端口訪問 ABAC其中的屬性就是與主體、資源、情況相關的所有信息。 * 主體的屬性：指的是與主體相關的所有信息，包括主體的年齡、性別、職位等。 * 資源的屬性：指的是與資源相關的所有信息，包括資源的創建時間、創建位置、密級等。 * 情況的屬性：指的是客觀情況的屬性，比如當前的時間、當前的位置、當前的場景（普通狀態、緊急狀態）。 * 操作：含義還是一樣，比如增刪改查等。 設定一個權限，就是定義一條含有四類屬性信息的策略（Policy）。 ~~~css 策略表 效果：允許 操作：流入 主體：來自上海IP的客戶端 資源：所有以33開頭的端口（如3306） 情況：在北京時間 9:00~18:00 效果：禁止 操作：流出 主體：任何 資源：任何 情況：任何 ~~~ 一個請求會逐條匹配策略，如果沒有匹配到策略，則返回默認效果，默認效果可以根據場景定制，可以是默認拒絕或是默認允許。另外，匹配方式也可以根據場景定制，可以使用**逐條順序匹配**，匹配到策略直接返回。也可以使用**完全匹配**，匹配所有的策略，如果有一個拒絕（允許），則拒絕（允許）。 阿里云的RAM訪問控制運用的就是ABAC模型： ~~~bash 阿里云RAM策略配置表 { "Version": "1", "Statement": [{ "Effect": "Allow", "Action": ["oss:List*", "oss:Get*"], "Resource": ["acs:oss:*:*:samplebucket", "acs:oss:*:*:samplebucket/*"], "Condition": { "IpAddress": { "acs:SourceIp": "42.160.1.0" } } }] } ~~~ ABAC可以發揮權限系統最大的靈活性，但在靈活的同時，如果不對策略加以管理，也有可維護性的問題。