今天咱們一起聊聊權限系統。

以大家熟知的電商場景舉例：

• 用戶可以分為普通用戶、VIP用戶：我們需要控制不同角色用戶的訪問范圍。比如，京東的PLUS會員，可以進入會員專區，而且能夠使用禮金領取優惠券，但是普通會員沒有這項功能；
• 用戶還可以范圍顧客、商家：顧客可以從APP下單，可以查看自己所有的訂單，這些訂單屬于不同的商家；商家可以從后臺看到自己店鋪的所有訂單，這些訂單分屬不同的顧客。

對于一個閉環的系統來說，無論是ToC還是ToB，權限系統都是基礎組件，用于保障用戶在權限范圍內操作有權限的數據。

如何控制權限

既然要控制權限，那我首先需要清楚需要控制的因素有哪些？

第一是控制維度，用戶可以做什么（Operation），在哪些對象（Object）操作：

• 比如：對某個數據的查詢、編輯、刪除。我們可以將之稱為功能權限。功能權限又可以細化為，看到菜單、打開頁面、頁面中有哪些按鈕、可以訪問哪些請求等。
• 比如：A可以管理甲乙丙三個店鋪；B可以管理丁一個店鋪。我們可以稱之為數據權限。數據權限可以細化為：單點、級聯、遞歸等。

控制維度

第二是控制粒度，我們的權限可以控制到一組人員，還是控制到一類人員：

• 按組區分：按照人員的角色進行劃分，比如，A、B、C是同一個部門，具備的權限都是一樣的，相同的功能權限、數據權限；
• 按類區分：按照用戶的特征進行劃分，比如，A、B、C是同一個部門，數據權限相同。但是A是正式員工，可以有刪除權限；B是正式員工，但是上個月績效太低，刪除權限被收回；C是實習生，只能有查詢權限，而且只能看到一個店鋪的數據。

兩種方式正好對應的業界常用的兩種權限模型：基于角色的訪問控制（Role-based access control，簡稱 RBAC）、基于屬性的訪問控制（Attribute-Based Access Control，簡稱 ABAC）。

什么是 RBAC

顧名思義，基于角色的訪問控制，就是給用戶定義角色，通過角色來控制權限。目前來說，基于角色權限控制模型是應用較廣的一個。

在RBAC中，包含用戶（User）、角色（Role）、權限（Permission），權限又分為對象（Object）、操作（Operation），總共五個基本元素。考慮到多種系統集合或者不同場景，還引入了會話（Session）。

用戶與角色之間是多對多，一個用戶有多個角色，比如既可以員工也可以是小組長；一個角色可以有多個用戶，比如公司所有人都是員工。

一個角色可以多種權限，這個很好理解。每個角色可以有查看、編輯等多種權限。

權限分為操作權限和對象權限，有的地方也稱為功能權限和數據權限。一個對應著可以執行的動作，一個對應著動作的數據范圍。

在這個模型中，還會細分為4個等級：

RBAC0

RBAC0

RBAC0包含了RBAC的所有元素，是RBAC的基本模型。幾個元素之間，就是簡單的多對多的關系。我們在市面上見到的大多數RBAC模型都是處于這個階段。

用戶根據會話選擇對應的角色，然后根據角色配置的操作權限，可以在系統中看到菜單、頁面、按鈕等，根據角色對應的數據權限，可以從對應的頁面看到對應的數據。

RBAC1

RBAC1

RBAC1是基于RBAC0，引入了角色繼承能力。比如有員工角色，可以瀏覽內部系統的公開信息，然后有老板角色，可以繼承員工角色，也就具備瀏覽內部系統的公開信息的能力。從用戶體驗上沒有差別，但是從事物認知上，更加符合我們的習慣。

RBAC2

RBAC2

RBAC2也是基于RBAC0，與RBAC1不同，RBAC2是增加了對角色的控制：

• 靜態職責分離（Static Separation of Duty，簡稱SSD）:

互斥角色：用戶只能分配一組互斥角色集合中的一種，比如會計和出納；

基數約束：一個角色可以被分配給有限的用戶，一個用戶可擁有有限的角色，一個角色對應有限的權限；

先決條件角色：想獲得較高的權限，要首先擁有低一級的權限。

• 動態職責分離（Dynamic Separation of Duty，簡稱DSD）
• 運行時互斥：一個用戶可以具備兩個角色，但是這兩個角色不能同時激活。

RBAC3

RBAC3

RBAC1和RBAC2具備兩種不同的思想，我們都想要，于是有了RBAC3。

實踐中的使用

一般來說，上面幾種模型可以覆蓋我們大多數的場景。有時候，我們還可以針對自己系統特點，還可以做一些擴展。

對于用戶比較多的系統，相同角色的用戶可能比較多，比如有100個用戶都有角色1和角色2，某一天系統升級，增加了新功能，創建了角色3，于是需要給這100個人都增加角色3，操作起來不太方便。我們可以增加用戶組的概念，擁有相同角色的用戶添加到一個用戶組中，用戶組與角色綁定，當需要給一部分用戶增加或減少角色的時候，只需要修改用戶組與角色的關系即可。

用戶組

權限分為操作和對象，一般在實踐中中，也會將角色分為操作角色和對象角色，兩者彼此分離。

角色

還有一種場景是，針對某些對象，可以有查看和編輯的權限，針對另外的對象，只有查看權限。這個時候，我們需要建立三者關系，角色、操作權限、數據權限。用戶具備角色一，角色一可以操作對象一、對象二，對對象一可以查看和編輯，對對象二可以查看。這種場景是更加細粒度的控制。只有在管控非常嚴格的系統中才會看到，比如，財務系統。

角色/操作/對象

什么是 ABAC

上面提到的最后一種場景中，我們能夠看到用戶在對象權限和操作權限上的靈活配置。本節我們介紹一種更加靈活的模型：基于屬性的訪問控制（Attribute-Based Access Control，簡稱 ABAC），它的原理是通過屬性組合動態判斷一個操作是否可以被允許。

考慮ABAC的模型時，我們需要一個更加復雜的場景：OA系統中的文檔系統（下面例子靈感來源于Authing官網）。

1. 授權員工張三有《xxx公告》的編輯權限；
2. 當《xxx公告》的所屬部門跟李四的部門相同時，李四可以訪問這個文檔；
3. 當王五是《xxx公告》的擁有者并且《xxx公告》的狀態是草稿時，王五可以編輯這個文檔；
4. 早上九點前禁止 A 部門的人訪問《xxx公告》；
5. 在除了上海以外的地方禁止以管理員身份訪問 A 系統。

從上面這個例子中，我們可以看到ABAC模型與RBAC模型的區別：RBAC是靜態的，用戶具備的權限只與關聯角色相關，不隨自身特征變化而改變；ABAC是動態的，時移世易，隨著用戶特征值的變化，權限也隨之變化。如果將角色看做一種特征值，那RBAC就是一維的ABAC。

ABAC

在 ABAC 模型中，一個操作是否被允許是基于對象、資源、操作和環境信息共同動態計算決定的：

• 對象是當前請求訪問資源的用戶，用戶的屬性包括ID、員工性質（正式、實習、外包等）、員工類型（普通、銷售、一線等）、崗位角色、所在部門、辦公地點、組織成員身份等；
• 資源是當前用戶要訪問的資產或對象，例如文件、數據、服務器、API等；
• 操作是用戶試圖對資源進行的操作，常見的操作包括查詢、編輯（新增、修改）、復制、刪除、導出等；
• 環境是每個訪問請求的上下文，環境屬性包含訪問的時間、位置，對象的設備，通信協議和加密強度等。

在 ABAC模型 的決策語句的執行過程中，決策引擎會根據定義好的決策語句，結合對象、資源、操作、環境等因素動態計算出決策結果。每當發生訪問請求時，ABAC模型決策系統都會分析屬性值是否與已建立的策略匹配。如果有匹配的策略，訪問請求就會被通過。

DAC與MAC

為了本文的完整，這里在介紹一下常見但是不常用的兩個模型：

• 自主訪問控制（Discretionary Access Control，簡稱DAC）：被操作對象，根據訪問控制規則（權限控制列表（ACL: Access Control List）或者權限控制矩陣（ACL: Access Control Matrix）），來判斷操作主體可對操作對象做哪些操作，比如只讀或者是可寫的權限。而自主的含義，則是擁有某種權限的用戶，可以把權限賦予其他用戶。
• 強制訪問控制（MAC: Mandatory Access Control）：被操作對象及用戶兩方均有各自的權限標識，用戶能否對對象進行操作，取決于雙方的權限標識的關系，這個限制判斷通常是由系統硬性限制的。這種模型多用于等級制度明顯，信息訪問安全性要求高的場景，比如軍事。

文末總結

本文一共介紹了四種常見權限模型：基于角色的訪問控制（Role-based access control，簡稱 RBAC）、基于屬性的訪問控制（Attribute-Based Access Control，簡稱 ABAC）、自主訪問控制（Discretionary Access Control，簡稱DAC）、強制訪問控制（MAC: Mandatory Access Control）。模型是死的，業務是活的。在實踐過程中，還會有很多的變體，萬變不離其宗，只要掌握了這幾種模型的核心，任何變體都可以隨心所欲。