RBAC模型:權限管理系統設計

    B端垂直的產品經理社區，是京東、阿里、美團等網際網路人學習和交流的平臺。我們不僅有CRM、ERP、OMS、WMS、TMS、OA等系統的Demo研習；    還有各種B端產品垂直的彈藥庫，包含產品說明書、操作手冊、白皮書、業務需求說明書、系統說明書；

對於後臺系統來說，權限管理是一個重要的模塊。本文將從理論知識和實際項目經驗相結合，介紹權限管理系統設計邏輯及過程，希望能給大家帶來幫助。

功能細分思維導圖

一、權限管理系統概述

1. 權限管理系統的作用

對整個後臺系統進行權限控制，目的是為了避免系統的使用者因為權限控制的缺失而出現操作不當、數據洩露、流程卡住等問題。比如：結算模塊指定財務、公司管理層能看，客服無法查看。

2. 權限管理系統的三要素

權限管理系統三要素分別是帳號、角色和權限。權限管理系統的存在，總的是為了將三要素之間的關係講清楚。

每個後臺系統的使用者，都有自己的帳號。帳號是使用者進入系統後臺的鑰匙，它的權限對應著使用者在系統中的操作範圍。後臺產品的帳號，通常是由公司內部對應的人員進行創建。

角色是搭建在帳號與權限之間的一道橋梁。系統中會有各種各樣的權限，如果每建一個帳號都要配置一遍權限，這樣工作效率將大大的降低。因此，角色作為使用者人群的集合，把需要的權限提前收歸於其中，然後再根據帳號的具體需求來配置角色。通常會根據不同的部門、崗位、工作內容等，對角色進行設置。

角色這一概念的引入，極大地增加了權限管理系統配置的靈活性和便捷性。創建帳號時，可以將不同的角色配置在同一個帳號上，也可以給不同的帳號配置相同的角色。創建角色時，可以根據角色的差異賦予其不同的權限。

權限可分為三類：數據權限、操作權限和頁面權限。

數據權限：控制帳號可看到的數據範圍。舉例說明，風控系統中，負責不同區域的信審人員，只能看到自己負責區域的標的，不能看到和修改其他區域的。

頁面權限：控制帳號可以看到的頁面，通常系統都會有這一層權限控制。這種控制相對操作權限來說比較粗放，難以對權限進行精細管理。

操作權限：控制帳號在頁面上可以操作的按鈕，通常指的是頁面中的新增、刪除、編輯、查詢功能。沒有操作權限，就只能看到頁面中的數據，但是不能對數據進行操作。操作權限是比頁面權限更精細一層的權限控制。

3. RBAC模型

(1) 定義

RBAC模型（Role-Based Access Control：基於角色的訪問控制），認為權限授權的過程可以抽象地概括為：Who是否可以對What進行How的訪問操作，並對這個邏輯表達式進行判斷是否為True的求解過程，也即是將權限問題轉換為What、How的問題，Who、What、How構成了訪問權限三元組。

在RBAC模型裡面，有3個基礎組成部分，分別是：用戶、角色和權限。

RBAC通過定義角色的權限，並對用戶授予某個角色從而來控制用戶的權限，實現了用戶和權限的邏輯分離（區別於ACL模型），極大地方便了權限的管理。

下面在講解之前，先介紹一些名詞：

(1) User（用戶）：每個用戶都有唯一的UID識別，並被授予不同的角色；

(2) Role（角色）：不同角色具有不同的權限；

(3) Permission（權限）：訪問權限；

用戶-角色映射：用戶和角色之間的映射關係；角色-權限映射：角色和權限之間的映射。

例如：管理員和普通用戶被授予不同的權限，普通用戶只能去修改和查看個人信息，而不能創建創建用戶和凍結用戶，而管理員由於被授 予所有權限，所以可以做所有操作。

當有多個帳號需要配置相同的權限時，有了角色後便不需要給每個帳號挨個配置權限，只需要在角色上配置權限，再把角色配置到帳號上。如果想批量調整帳號的權限，只需要調整帳號對應的角色的權限，無需對每個帳號進行調整。

(2) 類型

RBAC模型根據設計需要，可分為RBAC0、RBAC1、RBAC2、RBAC3四種類型。其中RBAC0是基礎，另外三種是RBAC0的升級。產品經理在進行權限系統設計時，可以結合實際情況來選擇使用的RBAC模型的類型。

具體對於RBAC模型詳細介紹，可查看此篇文章《RBAC權限管理模型》。

二、權限管理系統設計實例

下面介紹的系統是以RBAC0模型設計的，即把權限賦予角色，角色賦予帳號，帳號、角色、權限之間是多對多的關係。

1. 帳號(用戶)管理

(1) 帳號列表頁面

帳號管理模塊是對系統用戶信息進行統一的增、刪、改，列表主要展示編號、真實姓名、用戶名、部門、角色、創建時間、帳號狀態等重要欄位。

頁面上還有新建帳號和篩選帳號的帳戶的功能，讓管理員快速針對帳號進行操作。

(2) 新建帳號

新建帳號功能出現的界面以彈窗展示、如果是界面的信息過多的話可用重開頁面顯示，頁面內容除了上述的基本信息外，還需要對帳號賦予角色，可選擇多個角色。

(3) 編輯帳號

除了需要創建新帳號外，還需要對已有的帳號進行修改（操作欄中「編輯」功能），帳號用戶的真實姓名和用戶名不可修改，其他信息可修改。當然大家可以按照項目實際需求，也可將真實姓名和用戶名轉為可編輯狀態。

2、角色管理

(1) 角色頁面展示

角色，即為擁有共同特徵的同一類人群身份的歸納，在角色管理模塊對角色進行設置，列表主要展示角色名稱、角色描述、創建時間、更新時間、狀態等重要欄位。

(2) 新建角色

新建角色是對角色進行描述並賦予權限的過程，若權限數量不多，可採用下拉列表的方式選擇。若權限數量多且分類繁雜，則可採用分組列表的方式展示，讓用戶通過複選框勾選。為了操作簡便，建議增加全選/反選功能。

權限如何產生可與技術同學進行溝通即可。

(3) 編輯角色

操作欄中的「編輯」功能，對已有角色進行修改，角色的名稱、描述、狀態、權限均可修改，每次修改後在列表中記錄更新時間。

（4）對應帳號

角色的對應帳號指的是配置過該角色的帳號，點擊後在新頁面中打開，展示帳號信息，包括帳號的真實姓名、用戶名、部門、創建時間、帳號狀態，並可在列表中對帳號進行編輯。

3. 權限管理

(1) 頁面設計

若系統中權限數量較多且權限類型複雜（頁面權限、操作權限、數據權限），為了保證管理員使用便捷及減低出錯概率，可以將權限管理頁面以列表的形式展示，展示頁面包含權限編號、名稱、類型、描述、創建時間等。

若系統權限較為簡單，則可用樹狀圖來展示權限，不需要對權限做過多描述。

(2) 新增權限

新增權限的輸入頁面，不同的系統要求不同，有的需要開發錄入代碼，有的需要產品經理錄入新權限的URL，還有的系統中不展示新增權限入口。產品經理在設計時需要和開發溝通，選擇適合目前技術能力的方案。

三、RBAC0模型的三種擴展

1. RBAC1模型（角色分級模型）

RBAC1建立在RBAC0基礎之上，在角色中引入了繼承的概念。簡單理解就是，給角色可以分成幾個等級，每個等級權限不同，從而實現更細粒度的權限管理。

例如：一個公司的銷售經理可能是分幾個等級的，譬如除了銷售經理，還有銷售副經理，而銷售副經理只有銷售經理的部分權限。這時候，我們就可以採用RBAC1的分級模型，把銷售經理這個角色分成多個等級，給銷售副經理賦予較低的等級即可。

2. RBAC2模型（角色限制模型）

該模型也是以RBAC0模型為基礎，引入了角色間的限制條件，共有4種限制條件。

(1) 角色互斥

(2) 基數限制

(3) 先決條件限制

(3) 運行限制

詳細介紹，可查看此篇文章《RBAC權限管理模型》。

3. RBAC3（統一模型）

RBAC3是RBAC1和RBAC2的合集，所以RBAC3既有角色分層，也包括可以增加各種限制。

四、補充說明

1. 用戶組設置

基於RBAC模型，還可以適當延展，使其更適合我們的產品。譬如增加用戶組概念，直接給用戶組分配角色，再把用戶加入用戶組。這樣用戶除了擁有自身的權限外，還擁有了所屬用戶組的所有權限。

譬如，我們可以把一個部門看成一個用戶組，如銷售部，財務部，再給這個部門直接賦予角色，使部門擁有部門權限，這樣這個部門的所有用戶都有了部門權限。用戶組概念可以更方便的給群體用戶授權，且不影響用戶本來就擁有的角色權限。

2. 角色的數據權限控制

在實際業務當中，相同的角色在同一頁面中，所擁有的數據權限也有可能是不同的。

例如：負責不同區域的審核人能看到各自區域的數據。所以在設置角色的權限時，應該要結合實際業務情況對角色的數據權限進行設置。也可能會出現同樣的角色，在同一個頁面上，所查看到的欄位權限不一樣。

3. 未設置權限的展示

對於角色中未設置的權限的情況，頁面上有兩種展示方式。第一種根據權限的設置來展示，沒有權限的不予展示。第二種是顯示所有的功能和權限，點擊時告知用戶是否有此權限。

歡迎加入pmdiss.com超級vip

添加優惠多多

下面是pmdiss微信號，加他！

風裡雪裡，我們等你

很開心找到志同道合的你

請關注我們