1.什么是「權(quán)限設(shè)計」

“權(quán)限設(shè)計”是中后臺的底層設(shè)計，用于明確操作人員可在平臺內(nèi)能做什么；即什么樣的人，可以做什么樣的事。

1.1.權(quán)限的意義

• 讓使用者在有效的限制范圍內(nèi)訪問被授權(quán)的資源。
• 讓管理者基于系統(tǒng)的安全規(guī)則與策略，控制不同用戶合理訪問對應(yīng)資源。

正是有了權(quán)限系統(tǒng)，才可以讓工作群組內(nèi)不同人員、不同組織的分工，讓不同角色專注于自己的工作范圍，也可以降低操作風(fēng)險發(fā)生概率，也便于管理。

1.2.權(quán)限的應(yīng)用

權(quán)限設(shè)計的應(yīng)用主要有兩種場景，分別是版本切割、角色權(quán)限管理：

• 角色權(quán)限管理：角色權(quán)限管理顧名思義是根據(jù)用戶角色類型進行權(quán)限分配；一個角色對應(yīng)一組權(quán)限組，一個用戶可能有多個角色。適用于中后臺邏輯復(fù)雜功能模塊繁多，需要對系統(tǒng)按權(quán)限進行切割的應(yīng)用場景。

• 版本管理：部分中后臺存在商業(yè)化訴求，基于前者的角色權(quán)限分配（也有可能不存在角色區(qū)分），再將完整的系統(tǒng)進行功能切割，將整個系統(tǒng)按功能切割為普通版、進階版，甚至更多版本；這些版本功能范圍基本處于一個包含關(guān)系。
• 
  

在B端中后臺的設(shè)計中，最常見的應(yīng)用場景為“角色權(quán)限管理”，角色權(quán)限管理涉及的維度也會比“版本切割”更為復(fù)雜，本指南會著重介紹角色權(quán)限管理場景下的設(shè)計。

1.3.權(quán)限設(shè)計要求

好的權(quán)限設(shè)計，需要達到以下三方面要求：

• 系統(tǒng)安全：基于系統(tǒng)的安全規(guī)則和策略進行設(shè)計，同時需要降低用戶操作錯誤導(dǎo)致的風(fēng)險概率。

• 關(guān)系明確：需要界定權(quán)限的邊界與關(guān)系，遵循一定的規(guī)則與用戶進行關(guān)聯(lián)。

• 拓展性高：需要確保權(quán)限管理的拓展性，系統(tǒng)的能力建設(shè)是持續(xù)的，用戶也是不斷流動的；保持高拓展性以此降低變更對安全性、穩(wěn)定性的影響。

1.4.權(quán)限設(shè)計的工作范疇

• 界面設(shè)計：權(quán)限查詢、管理與授權(quán)等一系列頁面設(shè)計。
• 業(yè)務(wù)梳理：權(quán)限構(gòu)成、賦予以及行使的邏輯、元素的梳理。

• 數(shù)據(jù)驗證&管理：數(shù)據(jù)管理層面，最終目標(biāo)是可被表達成一個運算則式，體驗方案的合理性與拓展性，驗證設(shè)計的有效性。

• 底層架構(gòu)開發(fā)：偏向于開發(fā)層面的系統(tǒng)底層架構(gòu)設(shè)計與研發(fā)。

權(quán)限系統(tǒng)的復(fù)雜度決定設(shè)計需要介入的層級深度；一般設(shè)計師在權(quán)限設(shè)計中的范疇包括厘清權(quán)限的業(yè)務(wù)邏輯、關(guān)注頁面本身的設(shè)計，其他的數(shù)據(jù)層面和實現(xiàn)層面即可交由產(chǎn)品和開發(fā)。

2.怎么做「權(quán)限設(shè)計」—業(yè)務(wù)梳理

2.1.準(zhǔn)備工作：權(quán)限模型的了解與選擇

在業(yè)界有很多關(guān)于權(quán)限系統(tǒng)的技術(shù)模型，常見的有ACL、ABAC、DAC、RBAC等等，不同體量的權(quán)限系統(tǒng)，我們可以參考不同的權(quán)限模型進行梳理和設(shè)計。

2.1.1.RBAC0模型

RBAC0的基礎(chǔ)理念是將“角色”這個概念賦予用戶，在用戶與權(quán)限之間通過角色進行關(guān)聯(lián)，實現(xiàn)靈活配置。

RBAC模型的三要素為：用戶、角色、權(quán)限。

• 用戶：是發(fā)起操作的主體，例如：后臺管理系統(tǒng)的用戶、OA系統(tǒng)的內(nèi)部員工、面向C端的用戶。

• 角色：用于連接了用戶和權(quán)限的橋梁，每個角色可以關(guān)聯(lián)多個權(quán)限，同時一個用戶也可以關(guān)聯(lián)多個角色，那么這個用戶就有了多個角色的多個權(quán)限。

• 權(quán)限：用戶可以訪問的資源，包括：頁面權(quán)限、操作權(quán)限、數(shù)據(jù)權(quán)限。   

* 2.1.2.ACL模型

ACL為查詢操作對象的權(quán)限控制列表。當(dāng)權(quán)限系統(tǒng)體量小，用戶直接對應(yīng)具體功能點即可滿足系統(tǒng)訴求時，可以考慮使用ACL模型作為參考。

ACL權(quán)限中，只有用戶、權(quán)限這兩個要素：

* 2.1.3.RBAC1模型：基于 RBAC0 加入角色繼承

RBAC1模型是在RBAC0模型基礎(chǔ)上，引入了角色繼承的概念，即角色具有上下級的關(guān)系，每個等級權(quán)限不同，從而實現(xiàn)更細粒度的權(quán)限管理。 

* 2.1.4.RBAC2 模型：基于 RBAC0 引入角色約束控制

RBAC2模型是在RBAC0模型基礎(chǔ)上，對角色進行約束控制。RBAC2模型中添加了責(zé)任分離關(guān)系，規(guī)定了權(quán)限被賦予角色時或角色被賦予用戶時，以及當(dāng)用戶在某一時刻激活一個角色時所應(yīng)遵循的強制性規(guī)則。主要包括以下約束:

• 互斥關(guān)系角色: 同一用戶只能分配到一組互斥角色集合中至多一個角色，互斥角色是指各自權(quán)限互相制約的兩個角色。例如：設(shè)計部有交互設(shè)計師和視覺設(shè)計師兩個角色，他們?nèi)绻谙到y(tǒng)中為互斥角色，那么用戶不能同時擁有這兩個角色，體現(xiàn)了職責(zé)分離原則。

• 基數(shù)約束: a.一個角色被分配的用戶數(shù)量受限；b.一個用戶可擁有的角色數(shù)目受限；c.同一個角色對應(yīng)的訪問權(quán)限數(shù)目受限；以此控制高級權(quán)限在系統(tǒng)中的分配。

• 先決條件角色: 簡單理解即如果某用戶想獲得上級角色，必須得先獲得其下一級的角色，以此為一個先決條件。

2.2.開始梳理：基于RBAC模型盤點要素

RBAC0在實際工作中用得較為頻繁，且對應(yīng)初階的設(shè)計師對于權(quán)限的理解也較為有幫助，所以本文接下來會基于RBAC模型來介紹權(quán)限系統(tǒng)的梳理及設(shè)計。

2.2.1.第一步：盤點角色

角色是連接用戶和權(quán)限的橋梁，在這一步對參與系統(tǒng)的角色進行窮舉，需要保證系統(tǒng)的運作能否絕對閉環(huán)，所以明確系統(tǒng)中的角色至關(guān)重要。

如何進行角色盤點，主要有以下兩種方式：

• 參考組織本身的崗位劃分：絕大多數(shù)情況下，系統(tǒng)中的工作職責(zé)與實際工作崗位有較為緊密的相關(guān)性，我們可以參考已有的崗位來盤點系統(tǒng)中的角色。

舉例，研發(fā)運維工具中的角色定義，不同的崗位對應(yīng)不同的角色擁有不同工具的使用權(quán)。

• 根據(jù)任務(wù)流盤點：根據(jù)系統(tǒng)任務(wù)流對角色進行窮舉，即盤點需要創(chuàng)建哪些角色進行任務(wù)閉關(guān)。

舉例，支撐A平臺的智能客服知識庫，角色是我們在產(chǎn)品規(guī)劃過程中為其定義產(chǎn)生的。

本步驟產(chǎn)出物：「角色列表」 

2.2.2.第二步：盤點權(quán)限

權(quán)限是用戶能夠訪問的資源，本步驟需要將系統(tǒng)中所有權(quán)限點按照類型進行整理歸類，最終成表。權(quán)限點主要有以下幾種類型需要盤點：

頁面權(quán)限

通俗講即用戶在系統(tǒng)內(nèi)可見的頁面，由導(dǎo)航/菜單來控制，包括一級導(dǎo)航/菜單、二級導(dǎo)航/菜單，甚至三級導(dǎo)航/菜單；只要用戶有對應(yīng)導(dǎo)航/菜單的權(quán)限即可訪問頁面。 

舉例，智能客服知識庫系統(tǒng)的頁面權(quán)限： 

操作權(quán)限

通俗講即頁面的功能按鈕，包括查看、新增、修改、刪除、審核等等。

舉例，智能客服知識庫系統(tǒng)-敏感詞管理-黑名單頁面的操作權(quán)限：新增黑名單、修改、刪除 

在實際操作場景中，部分操作權(quán)限會因狀態(tài)而發(fā)生變化，在盤點操作權(quán)限時，需要使用狀態(tài)流轉(zhuǎn)化圖來檢查是否有缺漏。

數(shù)據(jù)權(quán)限

數(shù)據(jù)權(quán)限就是用戶在同一頁面看到的數(shù)據(jù)是不同的，比如：A部門只能看到其部門下的數(shù)據(jù)，B部門只看B部門的數(shù)據(jù)。數(shù)據(jù)權(quán)限分割的解決方案為：創(chuàng)建用戶組——將相同屬性或相同數(shù)據(jù)范圍訴求的用戶進行編組，不同的用戶組則享有不同的數(shù)據(jù)權(quán)限。

根據(jù)用戶組是否有上下級的關(guān)系，可將用戶組分為：具上下級關(guān)系用戶組、普通用戶組。

• 具上下級關(guān)系用戶組:最典型的例子就是部門組織。
• 
  

舉例：針對事項的受理審批有較為嚴謹?shù)牧鞒蹋鱾€單位需要各司其職，且公眾辦理的事項隸屬于各級層級區(qū)域，所以平臺權(quán)限系統(tǒng)需要形成較為嚴謹?shù)膮^(qū)域結(jié)構(gòu)和部門組織。例如，市公安局、民政局、水利局的辦事數(shù)據(jù)是對立的，我們可通過部門組織建立的用戶組來隔離數(shù)據(jù)權(quán)限。 

• 普通用戶組: 沒有上下級關(guān)系的用戶分組。在日常系統(tǒng)最常見的普通用戶組為“項目組”，按項目組來劃分用戶的數(shù)據(jù)權(quán)限。

舉例，以應(yīng)用項目的緯度控制用戶可訪問的數(shù)據(jù)范圍。

本步驟產(chǎn)出物：「權(quán)限點列表」

2.2.3.第三步：連接角色權(quán)限

本步驟主要工作在于連接權(quán)限點與角色的關(guān)系，最終整理出一張完整的角色權(quán)限表。在梳理角色和權(quán)限的關(guān)系時，可以借助設(shè)計分析方法“角色任務(wù)行為窮舉”來進行權(quán)限點轉(zhuǎn)化和連接。 

通常情況下，用戶為達成目標(biāo)而需完成某些任務(wù)，這些任務(wù)以及任務(wù)的聚合往往會影響我們對于整個系統(tǒng)信息架構(gòu)的設(shè)計考量。所以各個角色的任務(wù)經(jīng)常與我們的頁面一一對應(yīng)，從而產(chǎn)生頁面權(quán)限。而又因為完成任務(wù)需要進行一些特定的行為，而這些行為又與操作按鈕一一對應(yīng)，從而產(chǎn)生了操作權(quán)限。

本步驟產(chǎn)出物：「角色權(quán)限總表」

2.2.4.第四步：設(shè)計用戶導(dǎo)入與授權(quán)流程

在建立了角色與權(quán)限的關(guān)系后，需要去明確用戶授權(quán)/導(dǎo)入的方式，并給導(dǎo)入的用戶賦予角色權(quán)限。

明確賬號體系

有部分公司域下的中后臺，用戶已有有統(tǒng)一的驗證方式，例如：騰訊OA身份驗證；也有部分中后臺需要用戶創(chuàng)建獨立的ID賬號密碼作為身份驗證。我們首先需要去明確我們設(shè)計的中后臺是以上哪種方式作為身份驗證，這將影響用戶導(dǎo)入流程的設(shè)計。

初始用戶授權(quán)流程

• 已有賬號：如為公司域下中后臺的用戶導(dǎo)入，用戶賬號為現(xiàn)成的我們不需要考慮用戶的賬號?？芍苯訛橛脩糍x予權(quán)限，授權(quán)分為兩種方式：為用戶選擇角色、為角色添加用戶。

為用戶選擇角色可用在單個授權(quán)的場景，以下為授權(quán)流程可供參考： 

為角色添加用戶可用在批量授權(quán)的場景，以下為授權(quán)流程可供參考：

為豐富場景，提升體驗，建議兩種方式共存。

• 無賬號：如需要用戶創(chuàng)建ID的用戶導(dǎo)入，則適用于以下流程：

為保障安全，邀請碼需具有時效性。

授權(quán)申請流程

在實際工作中，用戶為完成某項任務(wù)卻無權(quán)限時，需要為用戶提供清晰的申請流程。申請權(quán)限有兩種場景。

• 場景一：權(quán)限存在崗位身份之分，身份與某組權(quán)限進行綁定，用戶主動申請崗位身份并獲得審批通過后，即可獲得該組權(quán)限，流程參考下圖：

場景二：用戶在訪問系統(tǒng)時，系統(tǒng)頁面提示用戶無訪問/操作權(quán)限，用戶針對該頁面/操作進行權(quán)限申請，通過后即可獲得該頁面/操作權(quán)限，流程參考下圖：

繪制狀態(tài)轉(zhuǎn)換圖

如果需要展示狀態(tài)轉(zhuǎn)換關(guān)系，關(guān)注狀態(tài)變化過程，甚至是檢測流程是否存在缺陷，我們可以通過繪制狀態(tài)轉(zhuǎn)換圖來梳理流轉(zhuǎn)狀態(tài)。使用狀態(tài)圖的過程中，設(shè)計師可以清晰的了解同一界面的各種狀態(tài)，便于對設(shè)計方案系統(tǒng)化的進行設(shè)計。在同一界面中，可以模塊化對比設(shè)計差異內(nèi)容。

導(dǎo)入/授權(quán)后的消息通知消息通知

可以及時地將狀態(tài)、內(nèi)容的更新觸達到用戶。在權(quán)限系統(tǒng)中，導(dǎo)入用戶環(huán)節(jié)或者是審批用戶權(quán)限環(huán)節(jié)，都離不開及時的消息通知。特別是導(dǎo)入用戶環(huán)節(jié)，為了確保安全性，邀請碼具有一定的時效性，所以消息的及時傳遞非常重要，務(wù)必需要對用戶進行及時的消息推送。

3.怎么做「權(quán)限設(shè)計」—界面設(shè)計

3.1.頁面權(quán)限設(shè)計點

無權(quán)限頁面申請指引設(shè)計

在2.2.4章節(jié)中，我們提到用戶在實際工作中為完成某項任務(wù)，對無權(quán)限頁面/操作會存在申請的場景訴求，我們除了要為用戶提供清晰的申請流程，也需要有清晰的指引，實際上也是針對空狀態(tài)的設(shè)計。

• 線上申請：用戶通過觸發(fā)申請按鈕，發(fā)起申請，并在線上填寫表單完成申請。在此場景下，除了申請按鈕，我們需要也很明確的告知用戶當(dāng)前為無權(quán)限的狀態(tài)，甚至將原因也給予簡單說明；同時建議告知用戶申請的審批人是誰，需要審批多久。

舉例：無權(quán)限頁面 

• 線下申請：頁面僅告訴用戶申請方式，一般為授權(quán)人的聯(lián)系方式。

舉例：無權(quán)限頁面

3.2.數(shù)據(jù)權(quán)限設(shè)計點

數(shù)據(jù)權(quán)限范圍的展示與切換

在2.2.2章節(jié)中，數(shù)據(jù)權(quán)限的不同導(dǎo)致用戶在同一頁面看到的數(shù)據(jù)是不同的，數(shù)據(jù)權(quán)限的范圍可由具有層級關(guān)系的組織架構(gòu)劃分，也可由普通用戶組進行劃分。通常，系統(tǒng)允許用戶擁有單個或多個數(shù)據(jù)權(quán)限；所以在我們的系統(tǒng)界面中，需要有承載數(shù)據(jù)權(quán)限范圍展示和切換的設(shè)計。

由于數(shù)據(jù)權(quán)限的展示和切換控制著用戶對于整個系統(tǒng)的數(shù)據(jù)范圍，故需要存在于系統(tǒng)架構(gòu)的第一層級，一般可獨立放置于一級菜單之上。

舉例：項目切換 

3.3.操作權(quán)限設(shè)計點

無權(quán)限操作展示設(shè)計

• 可申請

對于開放申請的操作權(quán)限的展示，可將操作權(quán)限點置灰，表示用戶當(dāng)前不可操作；在用戶hover置灰權(quán)限點時，提供氣泡提示置灰原因為無操作權(quán)限并提供申請權(quán)限入口。 

• 不可申請
• 
  

有些系統(tǒng)要求用戶可見操作全貌，即所有操作無論是否有權(quán)限都為可見的；若無權(quán)限則且不可申請，則直接置灰操作有些系統(tǒng)要求"可見即可操作"，即為有權(quán)限的操作則顯示，無權(quán)限的操作則隱藏，這里就需要前端來配合，前端開發(fā)把用戶的權(quán)限信息緩存，在頁面判斷用戶是否包含此權(quán)限。站在用戶體驗角度，更建議用后者這種方式進行權(quán)限隔離。 

總結(jié)

在中后臺中，權(quán)限系統(tǒng)或許不像業(yè)務(wù)模塊一樣備受重視，僅僅只是中后臺背后默默支撐的功能，但卻是必不可忽視的，正是有了權(quán)限系統(tǒng)，才可以讓工作群組內(nèi)不同人員、不同組織的分工，讓不同角色專注于自己的工作范圍，降低操作風(fēng)險發(fā)生概率，便于管理。在實際項目中，會遇到多個系統(tǒng)、多個用戶類型、多個使用場景，這需要具體問題具體分析；但萬變不離其宗，不管多么復(fù)雜，邏輯如何變化，最核心的RBAC模型還是一樣適用。 

Powered by Froala Editor