權限管理系統
權限的抽象
分權分域
權限訪問控制模型
UGO（User、Group、Other）
ACL（訪問控制列表）
DAC（自主訪問控制）
MAC（強制訪問控制）
RBAC（基於角色的訪問控制）
ABAC（基於屬性的權限驗證）
權限管理系統
ToB 產品的權限管理系統是一個非常重要的組成部分，沒有權限管理的系統仿佛一個沒有門的房子，任何人都可以隨意查看甚至調整，對系統的安全性存在非常大的隱患。
權限管理，即：根據系統設置的安全規則（Rule）或策略（Policy），用戶可以且只能訪問自己被授權的資源。權限管理是任何系統的標配模塊，它的作用不僅在於保護系統數據的安全性、防止留下系統漏洞，更能在龐大的系統下進行模塊和數據配置，讓不同的角色進入系統看到不同的模塊和數據，最大程度地提高系統的易用性。
權限的抽象
權限到底是名詞屬性？還是動詞屬性？還是名詞、動詞屬性均包含？這對定義權限的含義很重要。如果是名詞屬性的話，那么它應該是有具體的指代物；如果是動詞，則應該具有行為表示。
權限的名詞屬性的指代物：API、頁面、功能點。
權限的動詞屬性的指代物：可操作、不可操作。
普遍的，權限是同時具有名詞、動詞屬性的，它表達了兩層含義。即：限制指定對象的操作。向上引申可將權限划分為 3 個組成部分：
頁面權限：用戶可以看到那些頁面；
操作權限：用戶可以在頁面內進行那些操作，增刪改查等；
數據權限：用戶可以看到那些數據或內容；
分權分域
分權分域，是權限管理系統所能實現的效果之一，簡單來說就是兩點：
（分權）定制用戶權限，不同的用戶登錄系統后的界面不同，所能進行的操作也不同。
（分域）控制用戶權限，防止越權訪問和跨域訪問。
權限訪問控制模型
權限訪問控制的本質就是詢問這么一個問題：“某個用戶，對某個資源，是否可以進行某種操作？”
UGO（User、Group、Other）
UGO 是 Linux 對文件對象進行權限管理的訪問控制模型，Linux 中一切資源都是文件，每個文件都可以設置三種角色的訪問權限（文件創建者，文件創建者所在組，其他人）。
UGO 模型的缺點很明顯，就是只能為一類用戶設置權限，如果這類用戶中有特殊的某一個人，那么它無能為力了。
ACL（訪問控制列表）
ACL 的原理是，每個資源都配置有一個列表，這個列表記錄哪些用戶可以對這項資源進行 CRUD 操作。當系統試圖訪問這項資源的時候，會首先檢查這個列表中是否有關於當前用戶的訪問權限，從而確定這個用戶是否有權限訪問當前資源。
Linux 在 UGO 之外，也增加了 ACL 模型，可以使用 getfacl、setfacl 指令來對某個資源設置增加某個人、某個組的權限列表。操作系統會根據這個權限列表進行判斷，當前用戶是否有權限操作這個資源。
DAC（自主訪問控制）
ACL 模式存在一個問題：誰可以為資源增加訪問控制權限？常見的辦法就是增加一個 Super Admin 來做統一的操作。還有一種辦法，由某個權限的用戶來負責給其他用戶分配權限。這個就叫做自主訪問控制。Windows 操作系統的 Administer 就是 DAC 模型。
系統首先會識別用戶，然后根據被操作對象的 ACL（Access Control List，權限控制列表）或者 ACM（Access Control Matrix，權限控制矩陣）的信息來決定用戶的是否能對其進行哪些操作，例如：讀取或修改。而擁有對象權限的用戶，又可以將該對象的權限分配給其他用戶，所以稱之為 “自主（Discretionary）” 控制。
DAC 最大缺陷就是所有用戶的權限不能統一管理，用戶和用戶的權限比較分散，后期調整只能單個進行調整，不易維護。
MAC（強制訪問控制）
MAC 和 DAC 模型相反，它不將某些權限下放給用戶，而是在更高維度（比如操作系統）上將所有的用戶設置某些策略，這些策略是需要所有用戶強制執行的。這種訪問控制也是基於某些安全因素考慮。
在 MAC 的模型中，每一個對象都都有一些權限標識，每個用戶同樣也會有一些權限標識，而用戶能否對該對象進行操作取決於雙方的權限標識的關系，這個限制判斷通常是由系統硬性限制且無法回避的。強制訪問控制多應用於對安全性要求比較高的系統，如：多級安全軍事系統；
RBAC（基於角色的訪問控制）
1996年，萊威·桑度（Ravi Sandhu）等人在前人的理論基礎上，提出以角色為基礎的訪問控制模型，故該模型又被稱為 RBAC96。之后，美國國家標准局重新定義了以角色為基礎的訪問控制模型，並將之納為一種標准，稱之為 NIST RBAC。
RBAC（Role-based access control，以角色為基礎的訪問控制）是當前使用范圍最廣的一種權限設計模型。不同於 DAC 和 MAC 方式，后兩者直接賦予使用者權限，而前者則是將權限賦予角色。RBAC 是一種更為中性且更具靈活性的訪問控制技術。
RBAC 的特點是在用戶和具體權限之間增加了一個角色。通過設置一個角色，比如管理員，然后將用戶關聯某個角色中，再將角色設置某個權限。用戶和角色是多對多關系，角色和權限是多對多關系。所以一個用戶是否有某個權限，根據用戶屬於哪些角色，再根據角色是否擁有某個權限來判斷這個用戶是否有某個權限。
如圖所示，每個用戶關聯一個或多個角色，每個角色關聯一個或多個權限，從而可以實現了非常靈活的權限管理。角色可以根據實際業務需求靈活創建，這樣就省去了每新增一個用戶就要關聯一遍所有權限的麻煩。
簡單來說 RBAC 就是：用戶關聯角色，角色關聯權限。並且在產品和數據設計層面，有更好的擴展性，可控制到任意的粒度。
標准的 RBAC 模型包括四個部件模型：
基本模型 RABC0：定義了完全支持 RBAC 概念的任何系統的最低需求。RBAC0 的模型中包括用戶（U）、角色（R）和許可權（P）等 3 類實體集合，RABC0 是權限管理的核心部分，其他的版本都是建立在 RABC0 的基礎上。
角色分級模型 RABC1：基於 RBAC0 模型，引入角色間的繼承關系，即：角色之間上有了上下級關系。角色間的繼承關系可分為一般繼承關系和受限繼承關系。一般繼承關系僅要求角色繼承關系是一個絕對偏序關系，允許角色間的多繼承；而受限繼承關系則進一步要求角色繼承關系是一個樹結構，實現角色間的單繼承。這種模型合適於角色之間的層次明確，包含明確。
角色限制模型 RABC2：引入了角色間的約束關系，約束概念有兩種：
一種是 SSD（Static Separation of Duty，靜態職責分離）：
a、互斥角色：同一個用戶在兩個互斥角色中只能選擇一個。
b、基數約束：一個用戶擁有的角色是有限的，一個角色擁有的許可也是有限的。
c、先決條件約束：用戶想要獲得高級角色，首先必須擁有低級角色。
一種是 DSD（Dynamic Separation of Duty，動態職責分離）：
可以動態的約束用戶擁有的角色，如一個用戶可以擁有兩個角色，但是運行時只能激活一個角色。
統一模型 RABC3：同時包含了 1 和 2 的特性，既有角色約束，又有角色繼承，就是前面兩種角色變種的集合。
通過對 RBAC 各部件的詳細配置，RBAC 可以支持三個著名的安全原則：
最小權限原則：RBAC 可以將其角色配置成其完成任務所需要的最小的權限集。
責任分離原則：通過調用相互獨立互斥的角色來共同完成敏感的任務來體現，例如：要求一個計帳員和財務管理員共參與同一過帳。
數據抽象原則：通過權限的抽象來體現，例如：財務操作用借款、存款等抽象權限，而不用操作系統提供的典型的讀、寫、執行權限。
ABAC（基於屬性的權限驗證）
ABAC（Attribute-based access control，基於屬性的權限驗證）通過動態計算一個或一組屬性，來是否滿足某種條件來進行授權判斷（可以編寫簡單的邏輯），即：使用屬性來標記資源的權限。屬性通常來說分為四類：用戶屬性（如用戶年齡），環境屬性（如當前時間），操作屬性（如讀取）和對象屬性（如一篇文章，又稱資源屬性），所以理論上能夠實現非常靈活的權限控制，幾乎能滿足所有類型的需求。該設計過於復雜，暫未參透。
Kubernetes 中就用到了這種方法，比如：某個資源有 Pod 屬性，有 Namespace 屬性，那么就可以這樣設置：
# 用戶 Bob 可以在命名空間 projectCaribou 中讀取 Pod：
{
"apiVersion":"abac.authorization.kubernetes.io/v1beta1",
"kind":"Policy",
"spec":{
"user":"bob",
"namespace":"projectCaribou",
"resource":"pods",
"readonly":true
}
}
-----------------------------------
©著作權歸作者所有：來自51CTO博客作者范桂颶51cto的原創作品，如需轉載，請注明出處，否則將追究法律責任
權限管理系統的分權分域設計
https://blog.51cto.com/u_15301988/3227163