這是”一文”系列的第二篇。本篇主要介紹基于RBAC模型權限設計的方法。

01 什么是RBAC模型權限？

我們先看下邊一個小場景：

小明同學想晚上10點后進入圖書館學習，就在晚上10點準備進入圖書館時被保安王大叔給攔住了，理由是只有圖書館管理員10點以后才能進入圖書館。

1. 怎么樣才能讓小明同學在10點以后進入圖書館學習？

“讓小明同學偷偷溜進去？” “給保安王大叔給好處？”

“還是讓小明同學去“某組織”申請成為“圖書館管理員”？”

看來還是申請成為“圖書館管理員”比較靠譜，雖然需要寫申請書，找老師簽字等走一系列的流程，雖然麻煩，但是這是晚上10點以后進入圖書館的正規(guī)途徑。

2. 進圖書館小場景和RBAC模型有什么聯系？

首先我們先看下百度百科的介紹

“RBAC（Role-Based?Access?Control）：基于角色的訪問控制（RBAC）是實施面向企業(yè)安全策略的一種有效的訪問控制方式。”

“其基本思想是，對系統(tǒng)操作的各種權限不是直接授予具體的用戶，而是在用戶集合與權限集合之間建立一個角色集合。每一種角色對應一組相應的權限。一旦用戶被分配了適當的角色后，該用戶就擁有此角色的所有操作權限。”

看了百度百科介紹是不是感覺一臉懵？我們結合上邊的小場景去看：

• 角色1：圖書館管理員
• 角色2：保安? ? ??
• 用戶：小明同學
• 權限：晚上10點以后進入圖書館的權限
• 系統(tǒng)：圖書館

“圖書館”將晚上10點以后進入圖書館的權限授權給“圖書館管理員”，只有“圖書館管理員”角色的權限才可以晚上10點進入圖書館。小明同學想晚上10點后進入圖書館，就需要成為“圖書館管理員”這個角色，直接將權限賦給小明是不可行的。如下圖：

通過小場景，我們簡單的理解了RBAC的基本概念，用“角色”將“用戶”與“權限”進行分割，實現“用戶”與“權限”的解耦。只要是小明同學屬于圖書館管理員角色，他就可以進入晚上10點后圖書館，其他同學如果也申請了圖書館管理角色，同理也是可以在晚上10點以后進入圖書館的。

有人問會有疑問，為什么要設置“角色”，直接把權限賦予給“用戶”就行啦，不需要這么麻煩呀。咱們接著往下看。

3. RBAC模型的特點

提升管理效率，降低授權復雜性

如果圖書館出了新規(guī)定，晚上10點禁止任何人進入圖書館。圖書館只需要將“圖書館管理員”角色下晚10點后進入圖書館權限關閉即可(如下圖)。反之，試想如果沒有“圖書館管理員”角色，直接將晚上10點以后進入圖書館權限賦給小明和其他同學。要取消權限就要對每個有權限的同學進行取消權限，大大增加了工作量。

適用企業(yè)管理變化

圖書館又發(fā)出新規(guī)定“圖書館出了新規(guī)定，晚上10點禁止任何人進入圖書館不合理，應該讓“保安”可以在晚上10點進入圖書館進行巡邏?！蓖ㄟ^RBAC模型方式，直接將“保安”角色賦予“晚上10點以后進入圖書館”的權限就可以了。

02 RBAC模型權限設計方法

模型1：RBAC0

RBAC0是RBAC的基礎，RBAC1，RBAC2，RBAC3模型都是從RBAC0模型拓展而成。

RBAC0模型中用戶，角色，權限都是多對多關系。例如：實際中企業(yè)可能由于各種原因會出現一人承擔多個角色。比如擔任人力崗位同時，也會承擔行政的工作。

模型2：RBAC1

RBAC1在RBAC0的基礎上，加入角色繼承的概念。將角色下分成各個等級的小角色(如圖),子級權限繼承父級。如下圖，根據子級等級不同來分配更細粒度的權限。

例如：公司的財務總監(jiān)可以看到整個公司所有部門的財務報表數據，而銷售部財務經理只能看到銷售部財務報表數據，在銷售部財務經理下可能還會設立其他崗位，比如財務專員，財務專員可能只有查看銷售部具體某個報表的權限。

模型3：RBAC2

RBAC2是對RBAC0在角色，權限上增加了限制條件，例如： 公司規(guī)定有人被賦予了財務角色，就不能再賦予他審計角色。這樣可以在一定程度上防止在年總審計時候，審計人與被審計人是同一個人。這就是角色互斥。

用戶擁有的角色數，角色可以被賦予給多少用戶數，角色擁有的權限數都是可以被限制的，這就是基數限制。

還有先決條件限制，比如想擁有高級產品經理，就必須先擁有產品經理角色。

最后還有一種是動態(tài)的限制用戶及其擁有的角色，如果一個用戶可以擁有兩個角色，在運行是只能使用一個角色，這就是運行互斥。例如：未申請具體角色登錄系統(tǒng)，角色為“通用角色”。通用角色可以使用系統(tǒng)崗位角色申請功能，同時也能使用系統(tǒng)中已對“通用角色”開通權限的功能，例如查看運維電話、幫助手冊。

模型4：RBAC3

RBAC3=RBAC1+RBAC2

RBAC3集成了RBAC1的角色分級繼承，同時也包括RBAC2中的各種限制。如下圖

03 實例復盤

1. 前期分析

A系統(tǒng)(企業(yè)內部營銷域平臺)是我最近在參與項目之一，主要職責一部分是設計后臺功能，這其中就包含了權限設計。

對于A系統(tǒng)的權限設計，我是從下邊三個點出發(fā)進行分析：

什么人用？

用戶從哪來？

作為企業(yè)內部使用的營銷系統(tǒng)，用戶主體部分都是企業(yè)員工。其中少部分為供應商團隊用戶。企業(yè)內部員工通過與人力系統(tǒng)進行組織對接，打通人力系統(tǒng)與A系統(tǒng)用戶數據。員工可以直接使用統(tǒng)一企業(yè)賬號（portal)進行登錄。供應商團隊用戶是沒有portal的，這部分賬號需要進行創(chuàng)建分配。

什么身份（角色）

在找到“人”之后就要進行開始“身份”調研了?！吧矸荨闭{研階段是跟進在整個業(yè)務調研階段中，例如在調研中會梳理到實際業(yè)務組織架構。雖然已經確認有了人力系統(tǒng)組織架構，但是根據實際經驗往往人力架構與實際業(yè)務中架構會有一些差異。

通過前期業(yè)務調研后我們整理出組織架構，在組織架構梳理中明確了組織中父子級對應關系，在前期調研中也許明確出崗位角色中是否有“限制條件”，例如崗位角色是否有唯一性限制，如下圖所示中每個分公司里只有一個運營總監(jiān)，銷售總監(jiān)等等。（RBAC2中基數限制）

用什么功能（權限）

功能權限分為功能權限與數據權限。

功能權限指的角色在系統(tǒng)內操作范圍，例如角色A可以點擊報表導出按鈕或者管理員角色在系統(tǒng)中可以看到后臺管理菜單并可以對其進行操作。

數據權限指的角色在系統(tǒng)中可操作的數據范圍，例如報表中只顯示該角色的數據范圍內數據，比如上海公司的運營總監(jiān)查看數據權限只是上海分公司內的，同時篩選數據條件范圍也只限于其權限內。

通過前期業(yè)務調研針對不同的業(yè)務場景流程，在設計相關功能時需整理出功能權限表，權限表體現需要標注具體功能可以對哪些角色可見，功能內某個按鈕具體操作權限。有了這份表格，我們可以在系統(tǒng)上線初始化時，將角色的權限配置好，方便用戶上線后即用。

2. 設計階段

在梳理了用戶，角色，權限（功能&數據）關系后，就要著手進行功能設計了。

根據用戶流向策略，繪制出了如下后臺業(yè)務流程圖（初版）。

用戶來源主要是來自人力組織對接與自行創(chuàng)建分配用戶。人力崗位與角色在對接中形成組織對接關系，在具體功能權限賦予時，需要系統(tǒng)運營人員根據實際業(yè)務需求進行配置。

基于初版流程圖，先整體設計出后臺功能架構。

用戶中心：賬號管理? ?數據管理

角色中心：角色管理? ?角色功能管理? 角色組織崗位管理? 角色數據管理

組織管理：組織對接

用戶心中：賬號管理主要功能為賬號創(chuàng)建，查看，刪除，導出，修改，賬號狀態(tài)修改(停用/凍結).針對供應商賬號可以該功能模塊進行創(chuàng)建，其他操作可以對所有賬號進行。數據管理主要展示用戶的數據權限查看，導出，刪除。

角色中心：角色管理主要功能為角色創(chuàng)建，查看，刪除，導出，修改。角色功能管理是角色與功能權限進行配置。角色組織崗位管理為角色與組織崗位關系的查看、導出。角色數據管理可為角色進行數據模板配置，用戶在提報角色數據權限時，只能根據數據模板設置進行相應權限提報。

組織管理：組織對接功能與人力系統(tǒng)進行組織對接。

3. 場景演練

張三是新入職新員工，其崗位是上海分公司一級銷售代表。在入職后張三需要使用A系統(tǒng)進行日常辦公。因為A系統(tǒng)與人力系統(tǒng)有組織對接，所以張三直接使用portal賬號密碼登錄即可，登錄后需要進行角色與數據權限申請。

申請時角色默認為組織對接后角色，數據權限申請范圍是該角色可選擇數據權限。例如張三崗位為上海分公司一級銷售代表，其角色為一級銷售代表，那么張三進入申請功能時角色默認為一級銷售代表。但申請數據數據權限時只能選擇上海,品牌選擇現在為全部或多選（數據權限是通過角色數據管理進行配置）。張三選擇完數據權限，提交申請后，審批由張三的上一級領導進行操作，審批通過后張三可以以一級銷售代表的角色身份登錄系統(tǒng)開展業(yè)務。

下圖為新員工角色數據權限流程圖。

后記

由于該項目暫時還未正式上線，所以復盤的時隱藏了大部分信息，例如原型圖。可能會導致大家閱讀起來比較困難，后續(xù)我會根據實際情況不斷更新項目實例。

給大家一點建議：整體權限設計應該在項目開始時就要貫穿其中，優(yōu)秀的后臺權限設計方案，必定是依靠著前臺清晰的功能設計而生成的。所以盡量多參與項目調研階段與需求分析階段，最好整體都參與其中。

在整個項目權限設計中思想都是基于RBAC模型去設計的，RBAC模型的特點之一也是可以靈活多變的支持企業(yè)組織架構的伸縮，同時也提高了運維管理的效率。遺憾點是在設計初期并未考慮到分公司自行運營A系統(tǒng)的長遠需求（近幾年并不會實際落地），沒有在設計時提出“租戶”或者“用戶組”概念。

本文由 @Sean 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載

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