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

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

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

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

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

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

一、權(quán)限的定義是什么？

權(quán)限，百度百科將其定義為：“保證職責的有效履行，任職者必須具備的，對某事項能進行決策的范圍和程度。”

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

二、權(quán)限的維度有多少？

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

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

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

從權(quán)限操作維度來說，權(quán)限操作可以分為授權(quán)和鑒權(quán)。

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

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

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

三、權(quán)限設(shè)計的模型有哪些？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1）基本模型：RBAC0

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

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

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

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

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

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

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

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

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

2）角色分層模型：RBAC1

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

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

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

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

3）角色限制模型：RBAC2

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

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

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

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

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

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

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

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

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

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

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

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

四、基于RBAC模型設(shè)計權(quán)限時應(yīng)注意什么？

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

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

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

2. 盤點權(quán)限，使用正確的描述方式

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

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

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

3. 做好無頁面權(quán)限的提示

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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