後臺權限設計實現方式（B端後臺權限設計）

2023-07-25 11:03:46

編輯導語：合理的B端後臺權限設計體系將有助於協助用戶處理更多事務，提升用戶的操作效率，也降低風險發生的可能性。那麼，你了解權限設計中的每個模型嗎？本篇文章裡，作者從自身經驗出發，闡述了B端後臺權限設計的多種解法，一起來看一下。

「權限設計」是中後臺的底層設計，它是系統設計中最為重要的一環。

優秀的權限設計能夠有效提高系統的安全性、降低用戶誤操作，數據洩露的風險；差勁的權限設計，往往會導致系統流程不通，系統的穩定性和安全性受到威脅。

而產品經理在設計權限時，往往會一頭霧水，不知從何下手。

其問題在於：一方面開源的權限產品較少，產品經理無從體驗，借鑑。另一方面關於權限的文章良莠不齊，缺乏系統性的文章幫助了解權限構成，產品們只能摸著石頭過河，犯一些認知之外的錯誤。

對此，筆者根據此前的產品實操經驗，整合網際網路優秀權限文章，輸出自身關於權限的淺薄認知，望能起到些拋磚引玉的作用。

一、權限的定義是什麼？

權限，百度百科將其定義為：「保證職責的有效履行，任職者必須具備的，對某事項能進行決策的範圍和程度。」

但筆者理解為：「不同的對象在不同使用場景下，所需要的產品相應的權力和責任的統一，其核心為權責明晰，權責分離，目的是建立分配資源的規則，以便用戶能夠通過這套規則，獲取他們應獲得的資源。」

二、權限的維度有多少？

通常情況下，我們會將權限分成兩個維度，分別為功能權限和數據權限。功能權限是指用戶能夠做什麼樣的操作，或者訪問哪些資源，使用哪些功能；數據權限是指哪些數據屬於你，或者屬於你可以操作的範圍。

從顆粒度維度來分，功能權限的顆粒度從粗到細一般分為「模塊級」>>「頁面級」>>「接口級」，由此引申出了常說的頁面權限、模塊權限、接口權限。

數據權限的顆粒度從粗到細一般分為「對象級」>>」欄位級」，由此引申出對象級數據權限（具體到實際用戶）、欄位級數據權限（具體到表單欄位）。

從權限操作維度來說，權限操作可以分為授權和鑑權。

鑑權是指驗證用戶是否擁有訪問系統的權利，一般是指針對具體人的行為，根據權限規則進行合法性鑑別。在邏輯上，鑑權一般先於授權。授權一般可理解為是分配給具體的權限給具體的人。它可分為功能授權和數據授權。

功能授權往往是單一維度的，一般會功能列表或者功能樹上進行勾選，來確定用戶所對應的可操作資源。

數據授權和功能授權不同，數據是多維的，是抽象的。因此，在做數據授權之前，往往需要考慮對數據維度進行拆分，而數據是抽象的，我們不能具象地看待單個用戶的某一條數據，那沒有任何意義，而是要內置抽象的規則，通過抽象的規則，去尋找數據背後的聯繫。

三、權限設計的模型有哪些？

1. 自主訪問控制（DAC：Discretionary Access Control）

自主訪問控制是指由用戶有權對自身所創建的訪問對象（文件、數據表等）進行訪問，擁有對象權限的用戶。

可將對這些對象的訪問權授予其他用戶和從授予權限的用戶收回其訪問權限，此類權限模型往往應用於文檔系統的權限設計，例如微軟的NTFS文件系統。

DAC不僅能夠分配權限，還能夠對權限進行累加，繼承，但是其最大的缺點在於，權限過於分散，不方便管理，例如，無法簡單地將一組文件設置一個統一的權限開發給制定的一群用戶。

2. 強制訪問控制（MAC：Mandatory Access Control）

MAC模型往往用於信息敏感行業，該模型將系統中的信息分密級和類進行管理，以保證每個用戶只能訪問到那些被標明可以由他訪問的信息的一種訪問約束機制。

通俗地來說，在強制訪問控制下，用戶（或其他主體）與文件（或其他客體）都被標記了固定的安全屬性（如安全級、訪問權限等），在每次訪問發生時，系統檢測安全屬性以便確定一個用戶是否有權訪問該文件。例如多級安全（MultiLevel Secure, MLS）就是一種強制訪問控制策略。

3. 訪問控制列表（ACL：Access Control List）

ACL（Access Control List）主要包含三個關鍵要素用戶（User）、資源（Resource）和操作（Operate）。

ACL將每一項資源都分配一個列表，當用戶需要訪問資源時，都會先去請求列表是否有當前用戶的訪問權限，從而確定當前用戶可否執行相應操作。

其優點是，ACL及其簡單，不需要任何基礎設備就可完成訪問控制，但是由於其表單數量過多，導致若系統內部有大量資源，管理訪問控制列表就成為了繁瑣的工作。

4. 基於角色的訪問控制制（RBAC：Role-Based Access Control）

RBAC模型是在實際業務中使用最多的模型，RBAC模型主要由3個基礎模塊組成，分別為用戶、角色、權限。系統通過編輯用戶與角色、角色與權限的映射關係，解耦用戶與權限的關係，大幅度降低數據冗餘，進而降低了系統的複雜度，提高了系統的靈活性。

RBAC模型它只是一個大類，它可以細緻地劃分為：RBAC0、RBAC1、RBAC2、RBAC3。

1）基本模型：RBAC0

RBAC0是RBAC的核心，它定義了能構成RBAC控制系統的最小元素的集合（角色）。在此模型中，它指明了角色、用戶、訪問權限和會話之間的關係。其流程為，通過用戶關聯角色，定義權限集（角色）的方法間接的賦予用戶權限，進而達到用戶和權限解耦的目的。

在RABC中，用戶與角色的關係可以分為為「N：1（多對一）的用戶角色關係」和」N:N（多對多）的用戶角色關係「。

舉個N：1的用戶角色關係的例子，李三、李四（用戶）都是A部門（用戶組）的人，崗位都為產品運營（角色），他們都需要文章審核、文章發布功能（權限）。因此，只需要對產品運營（角色）進行分配文章審核、文章發布（權限），將產品運營（角色）分配給李三、李四即可。

N：N（多對多）的用戶角色關係中，若一個用戶被分配了多個角色，那麼該用戶的權限為所分配角色的併集。

再舉個例子，李五為B部門的產品經理，權限為文章模板設置。但是因為某次調研，他需要A部門的文章審核、發布權限。當分配給他A部門產品運營角色後，此時，他的權限變成了文章審核、發布權限、文章模板設置。

但在實際業務中，對於用戶的理解並非如上文中所寫的那麼淺薄。實際上，對於用戶的定義多種多樣，就筆者自身對用戶的理解而言：「用戶本質上為一個個需求的集合體「。

從這個角度來講，在使用場景和需求相對一致的情況下，可以將這部分用戶看作一個需求集合體一致的群組，進而形成一個用戶組（即為用戶的集合體）。

拿之前的例子來說，若A部門為產品運營部，那麼我們無需對A部門內部的人去分配角色。而是以A部門為對象去分配角色。

同時，現實中同樣也存在以下使用場景，需要對用戶分配居多的權限，若一個個分配將特別繁瑣，因而可以選擇將相對固定的權限打包成組來賦予給用戶。

2）角色分層模型：RBAC1

RBAC1在RBAC0的基礎上，引入角色間的繼承關係，即角色上有了上下級的區別。角色間的繼承關係可分為一般繼承關係和受限繼承關係。

一般繼承關係僅要求角色繼承關係是一個絕對偏序關係（有向無環圖），可進行多繼承。而受限繼承關係則進一步要求角色繼承關係是一個樹結構（二叉樹）間的單繼承。

一般繼承的RBAC和受限繼承的RBAC兩者的區別在於：前者是圖，可多繼承；而後者可以有多個父節點但只能有一個子節點，是一個反向樹結構，只能單繼承。

RBAC1模型往往使用於角色之間層級明晰的產品中，一般會和組織架構關聯起來。例如，李三為產品運營，其上級李四為產品經理。則李四會將其部分權限授權給李三，也可認定為李三繼承了李四的部分權限，即子集繼承了父級部分權限。

3）角色限制模型：RBAC2

RBAC2模型中添加了責任分離關係。RBAC2的約束規定了權限被賦予角色時，或角色被賦予用戶時，以及當用戶在某一時刻激活一個角色時所應遵循的強制性規則。

責任分離包括靜態責任分離和動態責任分離。約束與用戶——角色——權限關係一起決定了RBAC2模型中用戶的訪問許可，此約束有多種，主要包括：

靜態限制（靜態責任分離）同一用戶只能分配到一組互斥角色集合中至多一個角色，支持責任分離的原則。例如：同一個人不能既是「運動員」又是「裁判員」，即當用戶分配給受眾運動員的角色後，權限頁面無法給於其分配裁判員的權限。

動態限制：運行時互斥：例如，允許一個用戶具有兩個角色的成員資格，但在運行中不可同時激活這兩個角色。當一個人被授予了運動員和裁判員角色，在一次比賽中，他只能選擇以一個身份進行，不能以兩種身份同時進行。

基數約束：一個角色被分配的用戶數量受限；一個用戶可擁有的角色數目受限；同樣一個角色對應的訪問權限數目也應受限，以控制高級權限。

先決條件角色：可以分配角色給用戶僅當該用戶已經是另一角色的成員；對應的可以分配訪問權限給角色，僅當該角色已經擁有另一種訪問權限。要想獲得較高的權限，要首先擁有低一級的權限。就像我們生活中，國家主席是從副主席中選舉的一樣。

4）整合統一模型：RBAC3

RBAC3包含了RBAC1和RBAC2，既提供了角色間的繼承關係，又提供了責任分離關係。

5. 基於屬性的權限驗證（ABAC：Attribute-Based Access Control）

ABAC被認為是權限控制的未來，由於其邏輯比較複雜，筆者並未吃透，所以只簡單地介紹一下。

ABAC可分為訪問控制策略、環境條件、主體、客體、主體屬性、客體屬性。它通過將主體屬性、客體屬性和環境條件結合起來，按照它們與訪問控制策略的匹配情況來確定訪問（即對系統客體的操作）。

簡單而言就是將主體和客體的屬性用策略相關聯，通過讀取策略來確定主體可對客體進行哪些操作。

四、基於RBAC模型設計權限時應注意什麼？

1. 熟悉業務流程，盤點角色

設計初期，應該重新梳理系統中不同模塊的業務流程，通過業務流程圖，來盤點各個節點的角色，在這一環節中，需要對角色進行窮舉，保證系統在運行過程中達到閉環。一般情況下：

角色通過崗位去劃分，例如在禪道中，通過不同的崗位來劃分不同的角色。角色通過任務流劃分，根據業務流程中的不同節點功能，可將定義角色，例如，在某審批系統，可將角色劃分為錄入人員、審核人員。

2. 盤點權限，使用正確的描述方式

將系統中的所有功能模塊進行歸納整理，並根據自身系統所需要的顆粒度，來選擇權限的顆粒度。

同時，在PRD中傳達一個系統的權限設計規則時，不應該採用「當…時，就….「的語句去表達規則，而是要將角色和單元繪製成網格，每一個交叉節點為描述該角色與權限的數據關係和限制。

特別要注意的是，在設計數據權限時，其查看權限往往應設計在「增、刪、改、查」之前。

3. 做好無頁面權限的提示

在正常情況下，當用戶無對應權限時，該頁面會直接隱藏，但也不排除用戶可以獲取到權限外的URL地址，因為當用戶訪問到沒有權限的頁面時，需提示該用戶無對應權限。

4. 創建默認角色

默認角色一般為系統中自帶的角色，其往往包括超級管理員，管理員、業務員等等。

一般情況下，超級管理員為隱形角色，為領導高層掌握，擁有整個系統的所有權限，管理員繼承超級管理員所分配的權限，若管理員唯一的情況下，自身不可編輯，不可刪除，防止用戶刪除管理員角色，導致系統無法正常運行。其餘角色為管理員創建，可編輯，可刪除。

5. 對系統的長期規劃需明確

在搭建權限系統時，應該詳細地了解系統的業務範圍和長期規劃，梳理角色，並儘可能多地獲取用戶信息。

例如，在數據權限配置過程種，我們通過數據打標來劃分數據權限，但是隨著數據的標識增加，權限判斷條件增多，就會出現大量用戶信息需要判斷的問題。

6. 用戶的長期維護需及時處理

當系統長時間運轉時，在權限上，可能會因為用戶離職，權限系統未及時更新，而導致內部數據洩露的問題發生。針對這種情況，產品可採用權限系統與OA系統互通或者系統設置數據自動清洗的規則來解決。

7. 公司內部的權限規則需統一

當一個系統非常龐大時，由多名產品經理負責時，可能會出現由於沒有制定統一的權限規範，導致在提需求時，忘記說明而導致新功能沒有去實現權限控制。因此，在一個相對較大的項目中，產品經理們可以針對權限、UI做一個統一的標準。

網際網路上優秀的權限文章合集

【網易UEDC】角色權限設計的100種解法【騰訊CDC】系統解讀：權限設計指南【王賽】中後臺學習筆記-數據權限【學習文檔】RBAC總結【Enlink_Young】基於熟悉的訪問控制（ABAC）定義與思考

本文由 @lee的自我復盤 原創發布於人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。

,