這是」一文」系列的第二篇。本篇主要介紹基於RBAC模型權限設計的方法。
我們先看下邊一個小場景：
小明同學想晚上10點後進入圖書館學習，就在晚上10點準備進入圖書館時被保安王大叔給攔住了，理由是只有圖書館管理員10點以後才能進入圖書館。
「讓小明同學偷偷溜進去？」 「給保安王大叔給好處？」
「還是讓小明同學去「某組織」申請成為「圖書館管理員」？」
看來還是申請成為「圖書館管理員」比較靠譜，雖然需要寫申請書，找老師籤字等走一系列的流程，雖然麻煩，但是這是晚上10點以後進入圖書館的正規途徑。
首先我們先看下百度百科的介紹
「RBAC（Role-Based Access Control）：基於角色的訪問控制（RBAC）是實施面向企業安全策略的一種有效的訪問控制方式。」
「其基本思想是，對系統操作的各種權限不是直接授予具體的用戶，而是在用戶集合與權限集合之間建立一個角色集合。每一種角色對應一組相應的權限。一旦用戶被分配了適當的角色後，該用戶就擁有此角色的所有操作權限。」
看了百度百科介紹是不是感覺一臉懵？我們結合上邊的小場景去看：
「圖書館」將晚上10點以後進入圖書館的權限授權給「圖書館管理員」，只有「圖書館管理員」角色的權限才可以晚上10點進入圖書館。小明同學想晚上10點後進入圖書館，就需要成為「圖書館管理員」這個角色，直接將權限賦給小明是不可行的。如下圖：
通過小場景，我們簡單的理解了RBAC的基本概念，用「角色」將「用戶」與「權限」進行分割，實現「用戶」與「權限」的解耦。只要是小明同學屬於圖書館管理員角色，他就可以進入晚上10點後圖書館，其他同學如果也申請了圖書館管理角色，同理也是可以在晚上10點以後進入圖書館的。
有人問會有疑問，為什麼要設置「角色」，直接把權限賦予給「用戶」就行啦，不需要這麼麻煩呀。咱們接著往下看。
提升管理效率，降低授權複雜性
如果圖書館出了新規定，晚上10點禁止任何人進入圖書館。圖書館只需要將「圖書館管理員」角色下晚10點後進入圖書館權限關閉即可(如下圖)。反之，試想如果沒有「圖書館管理員」角色，直接將晚上10點以後進入圖書館權限賦給小明和其他同學。要取消權限就要對每個有權限的同學進行取消權限，大大增加了工作量。
適用企業管理變化
圖書館又發出新規定「圖書館出了新規定，晚上10點禁止任何人進入圖書館不合理，應該讓「保安」可以在晚上10點進入圖書館進行巡邏。」通過RBAC模型方式，直接將「保安」角色賦予「晚上10點以後進入圖書館」的權限就可以了。
RBAC0是RBAC的基礎，RBAC1，RBAC2，RBAC3模型都是從RBAC0模型拓展而成。
RBAC0模型中用戶，角色，權限都是多對多關係。例如：實際中企業可能由於各種原因會出現一人承擔多個角色。比如擔任人力崗位同時，也會承擔行政的工作。
RBAC1在RBAC0的基礎上，加入角色繼承的概念。將角色下分成各個等級的小角色(如圖),子級權限繼承父級。如下圖，根據子級等級不同來分配更細粒度的權限。
例如：公司的財務總監可以看到整個公司所有部門的財務報表數據，而銷售部財務經理只能看到銷售部財務報表數據，在銷售部財務經理下可能還會設立其他崗位，比如財務專員，財務專員可能只有查看銷售部具體某個報表的權限。
RBAC2是對RBAC0在角色，權限上增加了限制條件，例如： 公司規定有人被賦予了財務角色，就不能再賦予他審計角色。這樣可以在一定程度上防止在年總審計時候，審計人與被審計人是同一個人。這就是角色互斥。
用戶擁有的角色數，角色可以被賦予給多少用戶數，角色擁有的權限數都是可以被限制的，這就是基數限制。
還有先決條件限制，比如想擁有高級產品經理，就必須先擁有產品經理角色。
最後還有一種是動態的限制用戶及其擁有的角色，如果一個用戶可以擁有兩個角色，在運行是只能使用一個角色，這就是運行互斥。例如：未申請具體角色登錄系統，角色為「通用角色」。通用角色可以使用系統崗位角色申請功能，同時也能使用系統中已對「通用角色」開通權限的功能，例如查看運維電話、幫助手冊。
RBAC3=RBAC1+RBAC2
RBAC3集成了RBAC1的角色分級繼承，同時也包括RBAC2中的各種限制。如下圖
A系統(企業內部營銷域平臺)是我最近在參與項目之一，主要職責一部分是設計後臺功能，這其中就包含了權限設計。
對於A系統的權限設計，我是從下邊三個點出發進行分析：
什麼人用？
用戶從哪來？
作為企業內部使用的營銷系統，用戶主體部分都是企業員工。其中少部分為供應商團隊用戶。企業內部員工通過與人力系統進行組織對接，打通人力系統與A系統用戶數據。員工可以直接使用統一企業帳號（portal)進行登錄。供應商團隊用戶是沒有portal的，這部分帳號需要進行創建分配。
什麼身份（角色）
在找到「人」之後就要進行開始「身份」調研了。「身份」調研階段是跟進在整個業務調研階段中，例如在調研中會梳理到實際業務組織架構。雖然已經確認有了人力系統組織架構，但是根據實際經驗往往人力架構與實際業務中架構會有一些差異。
通過前期業務調研後我們整理出組織架構，在組織架構梳理中明確了組織中父子級對應關係，在前期調研中也許明確出崗位角色中是否有「限制條件」，例如崗位角色是否有唯一性限制，如下圖所示中每個分公司裡只有一個運營總監，銷售總監等等。（RBAC2中基數限制）
用什麼功能（權限）
功能權限分為功能權限與數據權限。
功能權限指的角色在系統內操作範圍，例如角色A可以點擊報表導出按鈕或者管理員角色在系統中可以看到後臺管理菜單並可以對其進行操作。
數據權限指的角色在系統中可操作的數據範圍，例如報表中只顯示該角色的數據範圍內數據，比如上海公司的運營總監查看數據權限只是上海分公司內的，同時篩選數據條件範圍也只限於其權限內。
通過前期業務調研針對不同的業務場景流程，在設計相關功能時需整理出功能權限表，權限表體現需要標註具體功能可以對哪些角色可見，功能內某個按鈕具體操作權限。有了這份表格，我們可以在系統上線初始化時，將角色的權限配置好，方便用戶上線後即用。
在梳理了用戶，角色，權限（功能&數據）關係後，就要著手進行功能設計了。
根據用戶流向策略，繪製出了如下後臺業務流程圖（初版）。
用戶來源主要是來自人力組織對接與自行創建分配用戶。人力崗位與角色在對接中形成組織對接關係，在具體功能權限賦予時，需要系統運營人員根據實際業務需求進行配置。
基於初版流程圖，先整體設計出後臺功能架構。
用戶中心：帳號管理 數據管理
角色中心：角色管理 角色功能管理 角色組織崗位管理 角色數據管理
組織管理：組織對接
用戶心中：帳號管理主要功能為帳號創建，查看，刪除，導出，修改，帳號狀態修改(停用/凍結).針對供應商帳號可以該功能模塊進行創建，其他操作可以對所有帳號進行。數據管理主要展示用戶的數據權限查看，導出，刪除。
角色中心：角色管理主要功能為角色創建，查看，刪除，導出，修改。角色功能管理是角色與功能權限進行配置。角色組織崗位管理為角色與組織崗位關係的查看、導出。角色數據管理可為角色進行數據模板配置，用戶在提報角色數據權限時，只能根據數據模板設置進行相應權限提報。
組織管理：組織對接功能與人力系統進行組織對接。
張三是新入職新員工，其崗位是上海分公司一級銷售代表。在入職後張三需要使用A系統進行日常辦公。因為A系統與人力系統有組織對接，所以張三直接使用portal帳號密碼登錄即可，登錄後需要進行角色與數據權限申請。
申請時角色默認為組織對接后角色，數據權限申請範圍是該角色可選擇數據權限。例如張三崗位為上海分公司一級銷售代表，其角色為一級銷售代表，那麼張三進入申請功能時角色默認為一級銷售代表。但申請數據數據權限時只能選擇上海,品牌選擇現在為全部或多選（數據權限是通過角色數據管理進行配置）。張三選擇完數據權限，提交申請後，審批由張三的上一級領導進行操作，審批通過後張三可以以一級銷售代表的角色身份登錄系統開展業務。
下圖為新員工角色數據權限流程圖。
由於該項目暫時還未正式上線，所以復盤的時隱藏了大部分信息，例如原型圖。可能會導致大家閱讀起來比較困難，後續我會根據實際情況不斷更新項目實例。
給大家一點建議：整體權限設計應該在項目開始時就要貫穿其中，優秀的後臺權限設計方案，必定是依靠著前臺清晰的功能設計而生成的。所以儘量多參與項目調研階段與需求分析階段，最好整體都參與其中。
在整個項目權限設計中思想都是基於RBAC模型去設計的，RBAC模型的特點之一也是可以靈活多變的支持企業組織架構的伸縮，同時也提高了運維管理的效率。遺憾點是在設計初期並未考慮到分公司自行運營A系統的長遠需求（近幾年並不會實際落地），沒有在設計時提出「租戶」或者「用戶組」概念。
本文由 @Sean 原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議