簡介
在業務系統開發過程中系統權限控制的設計是很重要的，尤其是大型的業務系統，一個好的權限控制設計可以爲後面業務開發和需求迭代節省大量的成本。
目前流行的權限控制模型常見有一下幾種：
- ACLs: access-control list
- RBAC: Role-Based access control
- ABAC: Attribute-Based Access Control
ACLs
這是一種比較常見的權限管理模型，在文件系統管理中常用到這種模型。它的經常由 {subject:action}的模式組成，例如一個文件node有以下的Acl：
{Alice:write; Bob:read}可以很清晰的表示出賦予了 Alice 寫權限和 Bob 讀權限。
在文件系統（ Microsoft Windows NT，OpenVMS， Unix-like, and Mac OS X operating systems）中通常以一個list數據結構來存儲 entires，每條 entrie中指定一個用戶或者一個組對一個文件、程序、進程的訪問權限，通常稱之爲 ACE。ACL通常存儲在這些系統上文件的擴展屬性中。
NFSv4 ACLs 和 POSIX.1e ACL 是兩種常用的file acl 標準。大多數的Unix系統和Unix-like系統（eg.Linux since 2.5.46 or November 2002,[6] BSD, or Solaris）支持 POSIX.e ACL 標準。如AIX，FreeBSD，[7]從版本10.4（“老虎”）開始的Mac OS X或具有ZFS文件系統的Solaris [8]，均支持NFSv4 ACL。目前Linux 有兩種實驗性的NFsv4實現：一種是對ext3文件系統的支持，另一種是對ext4文件系統的支持-- Richacls。
ACL 算法已經被移植到了SQL 和 現代關係型數據庫中 ， 許多的基於 SQL 開發的系統在其管理模塊中使用了ACL模型，例如：企業資源計劃和內容管理系統。
RBAC
基於角色的權限管理是在大型業務系統和企業管理系統中常用一種模型。它是一種圍繞 role 和 privileges 設計的模型，它滿足了政府和大型企業一些在行政管理上的要求，它既可以實現DAC(自由訪問控制) 也可以實現 MAC(強制訪問控制)。
將某些操作的權限綁定到 role，爲 user 分配不同的 role，通過 role 來管理 權限，可以通過新建 role 和 更換 role 來進行權限分配。簡化了權限管理的操作。
- S = Subject = A person or automated agent
- R = Role = Job function or title which defines an authority level
- P = Permissions = An approval of a mode of access to a resource
RBAC 系統設計時一般要遵循以下原則:
- role 分配：僅當 subject 已選擇或分配了 role 時，subject 才能行使權限。
- role 授權：必須爲一個 subject 賦予 active role。使用上面的規則1，此規則可確保用戶只能承擔授權的 role。
- permission 授權：僅當 subject 的 active role 被授權時，subject 才能行使權限。使用規則1和2，此規則可確保用戶只能行使其被授權的權限。
也可以應用其他約束，並且可以在層次結構中組合角色，其中更高級別的角色將包含子角色擁有的權限。
- SE = Session = A mapping involving S, R and/or P
- SA = Subject Assignment
- PA = Permission Assignment
- RH = Partially ordered Role Hierarchy. RH can also be written: ≥ (The notation: x ≥ y means that x inherits the permissions of y.)
Role-permission access-control.jpg
- subject : role = m : n
- permission : role = m : n
- operation : permission = m : n
角色管理系統也存在一些問題，因爲其管理的權限粒度不夠細，只有與role 綁定才能生效，經常會造成 role 爆炸的問題。
Acl vs RBAC
rbac 的權限控制粒度要比acl大，因爲RBAC系統將權限分配給具有組織意義的特定操作，而不是低級數據對象。比如acls可以指定誰寫入和讀取文件，但是不能指定 如何去修改文件。RBAC 可以限定某個操作比如：“買一個西瓜”，“增加一條消息日誌”等。
分配執行特定操作的權限是有意義的，因爲這些操作在應用程序中具有含義。事實證明，RBAC特別適合執行職責分離（SoD）要求，該要求可確保必須由兩個或更多人員參與授權關鍵操作。分析了RBAC中SoD安全性的充要條件。
SoD的基本原則是，任何人都不能通過雙重特權來破壞安全性。此外，任何人都不得擔任對另一個同時擔任的職務行使審計，控制或審查權限的職務。
然後，可以再次將“最小RBAC模型” RBACm與ACL機制ACLg(其中僅允許將組作爲ACL中的條目)進行比較。 Barkley（1997）[19]表明RBACm和ACLg是等效的。
ABAC
基於attributes的權限管理，這些策略可以使用任何類型的屬性（用戶屬性，資源屬性，對象，環境屬性等）。又可以稱爲基於 polices的權限管理模型。
與傳統的RBAC 相比，ABAC的主要區別在於表示複雜布爾規則集的策略的概念可以評估許多不同的屬性。屬性值可以設置值或原子值。集值屬性包含多個原子值。例如角色和項目。原子值屬性僅包含一個原子值。例如間隙和靈敏度。可以將屬性與靜態值進行比較，也可以將屬性進行比較，從而實現基於關係的訪問控制。
在Microsoft 中也被稱爲CBAC(claims-based access control ).實現ABAC的關鍵標準是XACML和ALFA（XACML）。
Attibutes
屬性大致可以分爲以下四類：
- Subject attributes: 描述用戶嘗試訪問的屬性，例如年齡，職務，部門，職位，職務...
- Action attributes：描述嘗試執行的動作的屬性，例如閱讀，刪除，查看，批准...
- Object attributes：描述正在訪問的對象（或資源）的屬性，例如對象類型（病歷，銀行帳戶...），部門，分類或敏感性，位置...
- Contextual(environment) attributes：涉及訪問控制場景的時間，位置或動態方面的屬性
Police
策略是將屬性彙總在一起以表示可能發生和不允許發生的情況的語句。 ABAC中的策略可以是授予或拒絕策略。策略也可以是本地策略或全局策略，並且可以以覆蓋其他策略的方式編寫。示例包括：
- 如果文檔與用戶位於同一部門，則用戶可以查看該文檔
- 如果用戶是所有者並且文檔處於草稿模式，則用戶可以編輯文檔
- 上午9點之前拒絕訪問
ABAC的概念可以應用於技術堆棧和企業基礎結構的任何級別。例如，ABAC可用於防火牆，服務器，應用程序，數據庫和數據層。屬性的使用帶來了更多的上下文，可以評估任何訪問請求的合法性，並告知授予或拒絕訪問的決定。
評估ABAC解決方案時，一個重要的考慮因素是瞭解其潛在的性能開銷及其對用戶體驗的影響。期望控件越精細，開銷越大。
應用
ABAC 與 傳統的RBAC 相比最大的區別就是可以將權限與資源關聯起來，RBAC、DAC、MAC 這些訪問控制模型是以用戶爲中心的，並不關心 subject 與 object 之間的關聯關心，這種從屬關係通常都是由開發人員在業務上實現。ABAC試圖通過基於描述請求實體（用戶），目標對象或資源，所需動作（查看，編輯，刪除...）以及環境或上下文信息的屬性定義訪問控制來解決此問題。這就是爲什麼訪問控制被稱爲基於屬性的原因。
ABAC 可以用於以下場景：
- API and micro services security
- Application security
- Database security
- Data security
- File server security
- Big data security
實現
ABAC帶有推薦的體系結構，如下所示：
- PEP或策略執行點：它負責保護您要對其應用ABAC的應用程序和數據。 PEP檢查該請求並生成一個授權請求，然後將其發送到PDP。
- PDP或策略決策點是體系結構的核心。這是根據已配置的策略評估傳入請求的部分。 PDP將返回“允許/拒絕”決定。 PDP也可以使用PIP來檢索丟失的元數據
- PIP或策略信息點將PDP橋接到屬性的外部來源，例如LDAP或數據庫