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

“權限設計”是中后臺的底層設計，它是系統(tǒng)設計中最為重要的一環(huán)。

優(yōu)秀的權限設計能夠有效提高系統(tǒng)的安全性、降低用戶誤操作，數(shù)據(jù)泄露的風險；差勁的權限設計，往往會導致系統(tǒng)流程不通，系統(tǒng)的穩(wěn)定性和安全性受到威脅。

而產(chǎn)品經(jīng)理在設計權限時，往往會一頭霧水，不知從何下手。

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

對此，筆者根據(jù)此前的產(chǎn)品實操經(jīng)驗，整合互聯(lián)網(wǎng)優(yōu)秀權限文章，輸出自身關于權限的淺薄認知，望能起到些拋磚引玉的作用。

一、權限的定義是什么？

權限，百度百科將其定義為：“保證職責的有效履行，任職者必須具備的，對某事項能進行決策的范圍和程度?！?/p>

但筆者理解為：“不同的對象在不同使用場景下，所需要的產(chǎn)品相應的權力和責任的統(tǒng)一，其核心為權責明晰，權責分離，目的是建立分配資源的規(guī)則，以便用戶能夠通過這套規(guī)則，獲取他們應獲得的資源?！?/p>

二、權限的維度有多少？

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

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

數(shù)據(jù)權限的顆粒度從粗到細一般分為“對象級”>>”字段級”，由此引申出對象級數(shù)據(jù)權限（具體到實際用戶）、字段級數(shù)據(jù)權限（具體到表單字段）。

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

1. 鑒權是指驗證用戶是否擁有訪問系統(tǒng)的權利，一般是指針對具體人的行為，根據(jù)權限規(guī)則進行合法性鑒別。在邏輯上，鑒權一般先于授權。
2. 授權一般可理解為是分配給具體的權限給具體的人。它可分為功能授權和數(shù)據(jù)授權。

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

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

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

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

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

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

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

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

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

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

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

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

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

其優(yōu)點是，ACL及其簡單，不需要任何基礎設備就可完成訪問控制，但是由于其表單數(shù)量過多，導致若系統(tǒng)內(nèi)部有大量資源，管理訪問控制列表就成為了繁瑣的工作。

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

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

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

1）基本模型：RBAC0

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

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

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

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

再舉個例子，李五為B部門的產(chǎn)品經(jīng)理，權限為文章模板設置。但是因為某次調(diào)研，他需要A部門的文章審核、發(fā)布權限。當分配給他A部門產(chǎn)品運營角色后，此時，他的權限變成了文章審核、發(fā)布權限、文章模板設置。

但在實際業(yè)務中，對于用戶的理解并非如上文中所寫的那么淺薄。實際上，對于用戶的定義多種多樣，就筆者自身對用戶的理解而言：“用戶本質上為一個個需求的集合體“。

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

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

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

2）角色分層模型：RBAC1

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

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

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

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

3）角色限制模型：RBAC2

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

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

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

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

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

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

4）整合統(tǒng)一模型：RBAC3

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

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

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

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

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

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

1. 熟悉業(yè)務流程，盤點角色

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

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

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

將系統(tǒng)中的所有功能模塊進行歸納整理，并根據(jù)自身系統(tǒng)所需要的顆粒度，來選擇權限的顆粒度。

同時，在PRD中傳達一個系統(tǒng)的權限設計規(guī)則時，不應該采用“當…時，就….“的語句去表達規(guī)則，而是要將角色和單元繪制成網(wǎng)格，每一個交叉節(jié)點為描述該角色與權限的數(shù)據(jù)關系和限制。

特別要注意的是，在設計數(shù)據(jù)權限時，其查看權限往往應設計在“增、刪、改、查”之前。

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

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

4. 創(chuàng)建默認角色

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

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

5. 對系統(tǒng)的長期規(guī)劃需明確

在搭建權限系統(tǒng)時，應該詳細地了解系統(tǒng)的業(yè)務范圍和長期規(guī)劃，梳理角色，并盡可能多地獲取用戶信息。

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

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

當系統(tǒng)長時間運轉時，在權限上，可能會因為用戶離職，權限系統(tǒng)未及時更新，而導致內(nèi)部數(shù)據(jù)泄露的問題發(fā)生。針對這種情況，產(chǎn)品可采用權限系統(tǒng)與OA系統(tǒng)互通或者系統(tǒng)設置數(shù)據(jù)自動清洗的規(guī)則來解決。

7. 公司內(nèi)部的權限規(guī)則需統(tǒng)一

當一個系統(tǒng)非常龐大時，由多名產(chǎn)品經(jīng)理負責時，可能會出現(xiàn)由于沒有制定統(tǒng)一的權限規(guī)范，導致在提需求時，忘記說明而導致新功能沒有去實現(xiàn)權限控制。因此，在一個相對較大的項目中，產(chǎn)品經(jīng)理們可以針對權限、UI做一個統(tǒng)一的標準。

互聯(lián)網(wǎng)上優(yōu)秀的權限文章合集

• 【網(wǎng)易UEDC】角色權限設計的100種解法
• 【騰訊CDC】系統(tǒng)解讀：權限設計指南
• 【王賽】中后臺學習筆記-數(shù)據(jù)權限
• 【學習文檔】RBAC總結
• 【Enlink_Young】基于熟悉的訪問控制（ABAC）定義與思考

本文由 @lee的自我復盤 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協(xié)議。