前言
這期分享一下幾個權限模型，在設計系統的時候一個很重要的問題是權限。不同的場景用戶會有不同的使用需求，如何設計一個合適的權限模型就顯得尤關重要。下面會結合實際系統來介紹幾種常見的權限模型。
在經典教科書中一般對權限系統中權限的使用者爲主體，操作所針對的對象爲客體。
一般經常使用權限控制模型的場景：數據庫 大數據 文件系統 應用程序 APi等等，只要有系統就有access control
一，DAC 自主訪問控制（Discretionary Access Control）
DAC是使用中最常見的權限模型，很多具體的權限模型都是由DAC衍化而來，特點是每項操作都有其對應的權限，所有的權限存儲在系統的ACL表中，每個用戶針對於自己的資源可以決定其他人哪些人可以享有這些資源的權限。
擁有對象權限的用戶可以將該對象的權限賦給其他人，每個人只要被賦予了權利就可以有相對的自主權，此爲自主。系統管理員通過acl對權限統一管理。
DAC靈活的權限處理多被用到很多開放給具體用戶的場景，比如操作系統的文件權限，mysql的acl表權限等。
DAC最大缺陷就是對權限控制比較分散，不便於管理，比如無法簡單地將一組文件設置統一的權限開放給指定的一羣用戶。
這就也會導致如果想導出特定的權限比較麻煩，控制不好容易造成權限擴散，而且如果單單使用DAC用戶想要更細緻的權限處理需求就會變得很棘手。
二，MAC 強制訪問控制 （Mandatory Access Control）
DAC可以劃分成主體爲用戶/組/管理員 權限操作爲 讀/寫/執行 而和這樣每個主體和客體都有細分的權限不同。對於一些權限管控要求較高的系統來說並不想把權限放給每個用戶自己去管控。而是事先把所有客體都設置好權限等級，不同等級的用戶只能享有權限不能修改權限，權限強制性地交給系統管理員統一處理。你想獲得權限也要統一經過管理員大大的審覈後來獲得。
也就是說每個用戶有唯一的權限等級對應享有其等級權限對應的客體權限。
軍隊，官方系統都可以通過MAC這種方式管控，可以做到很好地中心管控權限，也不需要考慮很多場景，不過和DAC相比對應的喪失了權限管控的靈活性。
三，RBAC 基於角色的訪問控制 （Role-Based Access Control）
我們可以看到DAC的權限完全自主 權限管控下放到具體個人身上 MAC權限管控實行強制，有系統管理員統一處理。它們好像是天平的兩端，而基於DAC和MAC，RBAC就像是天平中間調節器的存在。
RBAC在用戶和權限之間引入了“角色（Role）”的概念
每個用戶關聯一個或多個角色，每個角色關聯一個或多個權限，從而可以實現了非常靈活的權限管理。角色可以根據實際業務需求靈活創建，這樣就省去了每新增一個用戶就要關聯一遍所有權限的麻煩。簡單來說RBAC就是：用戶關聯角色，角色關聯權限。另外，RBAC是可以模擬出DAC和MAC的效果的。可以說RBAC可以兼容DAC和MAC的特點，成爲更加靈活龐大的權限模型。
具體的RBAC分級：
RBAC0 平面角色權限模型 一個用戶可以對應多個角色並享有多個角色分別對應的權限 角色與角色之間的權限是互斥的
RBAC1 角色繼承權限模型 角色可以有上下級的繼承關係 這種設計可以對角色分組和分層，比如大領導的角色可以覆蓋區域總管的角色，我們沒必要再把主管角色的權限給大領導一份，直接角色權限繼承覆蓋掉就好
RBAC2 制定約束角色關係，互斥角色（有些角色不能共享和覆蓋，這些角色不能分配給同一個賬號），基數約束（某個角色被分配給賬號的數量有限） 先決條件角色（賬號必須先獲得低級別的角色，再被賦予高級別的角色，不能跨級）
RBAC3 綜合以上特點，既有分層又有約束
可以說從RBAC0到RBAC3設計難度是逐層遞增的，管控力度和細緻性也是越來越大，既要保證中央集權和系統的安全性，也要保證每個用戶相對的權限靈活。
四，ABAC 基於屬性的訪問控制（Attribute Based Access Control）
想想龐大的RBAC有什麼問題？
對於普通系統來說已經沒問題，但對於一個大生態，多維度需要多種方式控制權限控制的系統就顯得效率很低，我們要不斷增加角色不斷設定等級去滿足權限需求，而且這麼龐大的權限模型維護也是一個很大的問題。能不能出現一個模型讓我能根據今天的風向，道瓊斯股票指數，隔壁家小朋友是否上學以及NBA湖人是否總冠軍這些屬性來決定今天喫不吃麪包呢？
這就誕生了ABAC
ABAC也是PBAC，但是基於屬性制定策略來動態判斷授權，相當於加入了IF-THEN的條件判斷，去避免分角色導致的很多問題。
不同於常見的將用戶通過某種方式關聯到權限的方式，ABAC則是通過動態計算一個或一組屬性來是否滿足某種條件來進行授權判斷（可以編寫簡單的邏輯）。屬性通常來說分爲四類：用戶屬性（如用戶年齡），環境屬性（如當前時間），操作屬性（如讀取）和對象屬性（如一篇文章，又稱資源屬性），所以理論上能夠實現非常靈活的權限控制，幾乎能滿足所有類型的需求。
ABAC模型設計成以下幾個部分組成：
PEP(Policy Enforcement Point): 負責使用ABAC策略保護用戶數據以及應用。PEP處理訪問請求，獲得環境上下文，並將這些信息發送給PDP。
PDP(Policy Decision Point): 是ABAC的處理單元，根據所有的策略和PEP發送的請求來決定是Allow還是Deny，
PDP使用PIP獲得策略和屬性等。在宿主服務中直接判斷權限，並藉以PIP創建的緩存以及PDP自身的緩存，最大限度的提升權限判斷的性能。
PIP(Policy Information Point): 搭建PDP到外部各種數據源的橋樑。
PAP(Policy Administration Point): 策略管理終端。管理員通過PAP管控權限策略。
毋庸置疑，ABAC要更好更靈活，是面向未來的權限模型，現在AWS IAM已經有相對完整的ABAC策略，用戶可以擁有的屬性通過事先制定的策略去完成審覈，管理員通過PAP，可以使用json或者abac專門的語言XACML來制定策略。
ABAC和RBAC最大的區別就是加入了對權限判斷的上下文的判斷，該上下文包含但是不限於如下的內容：請求的源地址，請求的資源的owner，當前請求的時間，該用戶的認證方式，如CAS、或者第三方認證抑或Domain Trust用戶，甚至是用戶自定義的屬性。通過對context的判斷，在RBAC的基礎上增加了runtime信息的判斷，ip限制，黑名單等功能都可以簡單配置，可以組成更加強大的權限判斷的效果。
參考： 1. AWS IAM https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html