一個后臺的用戶角色權(quán)限系統(tǒng)總是可以大概劃分為三個打的模塊的：用戶管理、角色管理、權(quán)限管理。本文作者將就此三個模塊展開敘述，enjoy~

一. 用戶角色權(quán)限系統(tǒng)說明

1. RBAC權(quán)限設(shè)計模型

（1）RBAC

（Role-Based Access Control，基于角色的訪問控制），就是用戶通過角色與權(quán)限進(jìn)行關(guān)聯(lián)，從而獲得某些功能的使用權(quán)限。權(quán)限被賦予給角色，而不是用戶，但是一個用戶可以擁有若干個角色，當(dāng)一個角色被賦予給某一個用戶時，此用戶就擁有了該角色所包含的功能權(quán)限。簡單地說，一個用戶擁有若干角色，每一個角色擁有若干功能權(quán)限。這樣，就構(gòu)造成“用戶-角色-權(quán)限”的授權(quán)模型。在這種模型中，用戶與角色之間，角色與權(quán)限之間，一般者是多對多的關(guān)系。如下圖：

2. 三大模塊搭建后臺用戶角色權(quán)限系統(tǒng)

如上所述，一個后臺的用戶角色權(quán)限系統(tǒng)總是可以大概劃分為三個打的模塊的：用戶管理、角色管理、權(quán)限管理。用戶管理往往隨著行政部門劃分或者隨著業(yè)務(wù)線部門劃分，對應(yīng)部門或者小組內(nèi)的用戶有著基本相似的功能需求和權(quán)限等級；角色管理相對來講更加固定，它往往是基于業(yè)務(wù)管理需求而預(yù)先在系統(tǒng)中設(shè)定好的角色標(biāo)簽，一般不會隨意更改，更像是一個用戶分組標(biāo)簽；權(quán)限管理內(nèi)容相對更加龐雜和豐富，主要包含了目標(biāo)、操作和許可權(quán)三個部分，當(dāng)某一功能權(quán)限授權(quán)給用戶時，也就相當(dāng)于為該用戶開通了可以操作某個目標(biāo)功能的許可權(quán)。

角色權(quán)限系統(tǒng)屬于策略設(shè)計的范疇，它的設(shè)計非常考驗一個PM對業(yè)務(wù)的理解力以及對自己后臺所有功能的熟悉程度。做角色權(quán)限系統(tǒng)之前一定要先深度了解業(yè)務(wù)流程以及后臺的所有功能模塊，在不了解的情況下，多向相關(guān)同事請教，避免角色權(quán)限系統(tǒng)設(shè)計過程中出差錯和邏輯漏洞。

二. 用戶角色權(quán)限系統(tǒng)建設(shè)的三大模塊

1.? 用戶管理

用戶管理中的用戶主要是功能系統(tǒng)的使用者，這些用戶是一個一個的員工個體，這些個體往往從兩個維度來進(jìn)行劃分：行政關(guān)系（部門架構(gòu)）、業(yè)務(wù)部門（業(yè)務(wù)架構(gòu)）。用戶管理就是在此兩個維度來給員工個體進(jìn)行關(guān)聯(lián)性的初步分群或者分組。按照行政部門或者按照業(yè)務(wù)線部門劃分后，對應(yīng)部門或者小組內(nèi)的用戶有著基本相似的系統(tǒng)功能使用需求和權(quán)限等級；

注：上圖例為按照行政關(guān)系劃分的用戶管理模式

注：上圖例為按照業(yè)務(wù)線關(guān)系劃分的用戶管理模式

2. 角色管理

（1）角色管理

角色往往是基于業(yè)務(wù)管理需求而預(yù)先在系統(tǒng)中設(shè)定好的固定標(biāo)簽，每個角色對應(yīng)明確的系統(tǒng)權(quán)限，其所擁有的系統(tǒng)權(quán)限一般不會隨意更改，并且角色也不會隨著用戶的被添加和被移除而進(jìn)行改變，相較于用戶管理而言更加穩(wěn)定；

（2）自動賦權(quán)：用戶自動進(jìn)入角色

如果角色與行政關(guān)系下的組織部門存在綁定關(guān)系，那么如果一個用戶進(jìn)入到該組織部門后，該用戶會自動被加入到對應(yīng)的角色中，并且擁有該角色所有的系統(tǒng)權(quán)限。如一個財務(wù)人員【小張】入職財務(wù)部后，那么該用戶無需進(jìn)行額外的授權(quán)即可在對應(yīng)財務(wù)報表系統(tǒng)查看該部門員工可查看的財務(wù)數(shù)據(jù)報表和對應(yīng)的操作權(quán)限（比如操作財務(wù)審批等）；

（3）角色賦權(quán)：用戶被添加進(jìn)角色

業(yè)務(wù)是不斷創(chuàng)新和發(fā)展的，隨著業(yè)務(wù)的發(fā)展，會有越來越多的新的角色被設(shè)置和創(chuàng)建，比如公司新啟動了一個企業(yè)團(tuán)餐項目，項目部橫向的從各個部門找了多個員工組建項目團(tuán)隊，并且該項目的業(yè)務(wù)權(quán)限也只是授權(quán)給這批員工可查看和操作，那么，在此項目中，會產(chǎn)生一個新的角色 “ 財務(wù)1 ”，系統(tǒng)高級管理員會把從財務(wù)部門選中的財務(wù)【小張】添加到“ 財務(wù)1 ”這個角色中，那么【小張】即可獲得查看企業(yè)團(tuán)餐項目業(yè)務(wù)數(shù)據(jù)報表和操作的權(quán)限。這種權(quán)限的授予無法通過用戶行政關(guān)系的自動綁定來實現(xiàn)；

（4）角色繼承：角色權(quán)限的繼承

權(quán)限可以是獨有的，也可以是繼承的。每個角色都有自己的權(quán)限集，角色繼承其實也就是繼承父系角色的權(quán)限，一般角色在繼承其父系角色的全部權(quán)限的基礎(chǔ)上增加擁有一些自己的權(quán)限。而系統(tǒng)角色繼承往往存在于用戶分級管理比較明確的團(tuán)隊或者公司；

（5）角色互斥：角色包含的權(quán)限互斥

角色互斥的業(yè)務(wù)背景：當(dāng)一個業(yè)務(wù)流程由于風(fēng)控的原因，需要將其操作給劃分成分開的幾個步驟時，需要給這幾個不同的步驟授權(quán)不同的角色，并且這些角色之間需要進(jìn)行互斥。比如大額財務(wù)報銷審批流程，財務(wù)人員【小張】擁有了審批人權(quán)限后，就無法將審核確認(rèn)的權(quán)限再授予小張，以此來規(guī)避一個人完成大額報銷而帶來的財務(wù)風(fēng)險；

（6）臨時角色

臨時角色往往是針對特殊群體設(shè)置的，比如公司有特殊訪問團(tuán)隊蒞臨，需要給這些特殊的客戶一些臨時身份來體驗?zāi)承┕δ懿僮?。那么把這些人添加到部門的組織架構(gòu)中顯然是不合適的，因為這些人只是臨時的擺放者，不是企業(yè)員工；其次，這些客戶需要體驗的功能操作往往是橫跨多個業(yè)務(wù)模塊和產(chǎn)品線的（比較繁雜），一般公司并沒有現(xiàn)成的固定角色符合擁有客戶所需的全部操作權(quán)限，因此需要給這些客戶開設(shè)臨時角色，并且支持給臨時角色最大的權(quán)限選擇空間；

（7）黑白名單

3. 權(quán)限管理

（1）權(quán)限管理

權(quán)限管理更多是從功能菜單、功能操作、數(shù)據(jù)參數(shù)三個不同顆粒度等級來考量的。具體顆粒度的大小視公司結(jié)構(gòu)和團(tuán)隊規(guī)模而定，如果不是業(yè)務(wù)屬性一定要求將權(quán)限控制到非常精細(xì)的級別，其實就沒有必要將權(quán)限的顆粒度拆分到具體某一項操作或者某一個按鈕，畢竟后臺產(chǎn)品的核心是業(yè)務(wù)管理平臺，主要目標(biāo)是輔助業(yè)務(wù)的管理和推進(jìn)。

注：如圖為某一后臺產(chǎn)品的部分截圖，其中可見功能菜單頁、功能操作按鈕和數(shù)據(jù)字段。

（2）功能菜單權(quán)限

對于后臺產(chǎn)品來講，針對功能菜單來劃分用戶權(quán)限其實是比較粗顆粒度的一種管理方式，這種模式下用戶一旦獲得授權(quán)即可使用該菜單欄下的全部數(shù)據(jù)查看權(quán)限和功能操作權(quán)限；

（3）功能操作權(quán)限

功能操作層級的權(quán)限相對于功能菜單會更為深入，這種情況下，不同角色的用戶可以進(jìn)入同一菜單頁后臺查看相同的數(shù)據(jù)字段信息，但是他們可執(zhí)行的功能操作不同；

（4）數(shù)據(jù)字段權(quán)限

數(shù)據(jù)字段層面是較細(xì)顆粒度的拆分，他會實現(xiàn)不同角色用戶在進(jìn)入同一菜單頁后臺時，可見的數(shù)據(jù)字段都有差異。比如銷售人員進(jìn)入某銷售業(yè)績管理后臺時，可以看到自己的業(yè)績提升數(shù)據(jù)，但是財務(wù)人員看到的是業(yè)務(wù)工單的費用字段，這些字段共存在一個菜單頁中，只是受限于不同的角色權(quán)限而已。

三. 案例分析

1. 促銷活動權(quán)限系統(tǒng)權(quán)限對接

以某一促銷活動的后臺從無權(quán)限限制到接入用戶角色權(quán)限管理系統(tǒng)為例，詳情如下：

注：以上為某產(chǎn)品的促銷活動管理后臺截圖

2. 促銷活動后臺接入權(quán)限系統(tǒng)前

在促銷活動后臺接入權(quán)限系統(tǒng)之前，幾乎全部的系統(tǒng)權(quán)限都處于裸奔的狀態(tài)，所有人業(yè)務(wù)線成員都可以查看該后臺的運營活動內(nèi)容和運營結(jié)果數(shù)據(jù)，并且可以執(zhí)行相對敏感的操作。這種情況顯然是存在一定的管理風(fēng)險的，因此該后臺系統(tǒng)需要對接權(quán)限管理系統(tǒng)進(jìn)行系統(tǒng)化管理和風(fēng)險控制；

3. 促銷活動后臺接入權(quán)限系統(tǒng)時

促銷活動在接入權(quán)限管理系統(tǒng)過程中，需要拆解該功能模塊的權(quán)限元素（到一定顆粒度），因此需要根據(jù)業(yè)務(wù)特征來判斷需要拆分的顆粒度，是到功能菜單、功能操作還是數(shù)據(jù)字段的級別，明確拆分顆粒度之后，權(quán)限管理系統(tǒng)才可以給不同角色按照顆粒度授予權(quán)限；

4. 促銷活動后臺接入權(quán)限系統(tǒng)后

促銷活動在接入權(quán)限管理系統(tǒng)過程后，當(dāng)對應(yīng)角色的用戶再次登錄這個后臺時，首先后臺會校驗該用戶的角色是否擁有該功能模塊的權(quán)限，以及該角色權(quán)限對應(yīng)的操作權(quán)限和數(shù)據(jù)字段權(quán)限，校驗結(jié)果經(jīng)服務(wù)端處理會在產(chǎn)品端展示給用戶可見。這個時候，同一用戶再該后臺可見和可執(zhí)行的操作與接入權(quán)限管理系統(tǒng)之前可能有很大的不同，這就是基于用戶角色的權(quán)限管理系統(tǒng)帶來的改變。

四. Q&A

1. 一個用戶擁有多個角色，多角色之間如果存在互斥關(guān)系如何處理？

如果一個用戶已經(jīng)被添加到某一角色范圍下，那么，當(dāng)給該用戶添加一個與當(dāng)前角色存在權(quán)限互斥關(guān)系的角色時，系統(tǒng)會進(jìn)行互斥性判斷，后面的角色就無法給該用戶添加成功；

2. 業(yè)務(wù)發(fā)展過程中，如何保證不同角色之間權(quán)限拆分清晰？

隨著業(yè)務(wù)的快速發(fā)展，一定會不斷新增不同的角色和更多的功能模塊，而且這些角色和功能權(quán)限之間的關(guān)系也會日益混亂，這個時候需要產(chǎn)品經(jīng)理和業(yè)務(wù)方一起，及時的面對業(yè)務(wù)的發(fā)展變化，及時、快速的梳理業(yè)務(wù)調(diào)整范圍，作出對應(yīng)的改變；

3. 用戶權(quán)限管理系統(tǒng)核心難點是前期的產(chǎn)品設(shè)計嗎？

用戶權(quán)限管理系統(tǒng)核最難的不是前期的產(chǎn)品設(shè)計，而是后續(xù)的運營維護(hù)，因為權(quán)限系統(tǒng)的結(jié)構(gòu)往往不會隨意變更，但是隨著業(yè)務(wù)發(fā)展快速出現(xiàn)的角色和功能模塊，為了防止角色和功能權(quán)限之間的關(guān)系變得混亂，在建立新的角色和分配權(quán)限的時候需要思路清晰且慎重調(diào)整。

完結(jié)~

本文由 @陽明（劉同） & @云殊（張俊恒）原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

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