后臺(tái)用戶角色權(quán)限管理系統(tǒng)

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

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

RBAC(Role-Based Access Control,基于角色的訪問(wèn)控制),就是用戶通過(guò)角色與權(quán)限進(jìn)行關(guān)聯(lián),從而獲得某些功能的使用權(quán)限。權(quán)限被賦予給角色,而不是用戶,但是一個(gè)用戶可以擁有若干個(gè)角色,當(dāng)一個(gè)角色被賦予給某一個(gè)用戶時(shí),此用戶就擁有了該角色所包含的功能權(quán)限。

簡(jiǎn)單地說(shuō),一個(gè)用戶擁有若干角色,每一個(gè)角色擁有若干功能權(quán)限。這樣,就構(gòu)造成“用戶-角色-權(quán)限”的授權(quán)模型。在這種模型中,用戶與角色之間,角色與權(quán)限之間,一般者是多對(duì)多的關(guān)系。如下圖:

image.jpeg

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

一個(gè)后臺(tái)的用戶角色權(quán)限系統(tǒng)總是可以大概劃分為三個(gè)打的模塊的:用戶管理、角色管理、權(quán)限管理。

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

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

image.jpeg

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

1. 用戶管理

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

image.jpeg

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

image.jpeg

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

2. 角色管理

(1)角色管理

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

image.jpeg

(2)自動(dòng)賦權(quán):用戶自動(dòng)進(jìn)入角色

如果角色與行政關(guān)系下的組織部門存在綁定關(guān)系,那么如果一個(gè)用戶進(jìn)入到該組織部門后,該用戶會(huì)自動(dòng)被加入到對(duì)應(yīng)的角色中,并且擁有該角色所有的系統(tǒng)權(quán)限。

如一個(gè)財(cái)務(wù)人員【小張】入職財(cái)務(wù)部后,那么該用戶無(wú)需進(jìn)行額外的授權(quán)即可在對(duì)應(yīng)財(cái)務(wù)報(bào)表系統(tǒng)查看該部門員工可查看的財(cái)務(wù)數(shù)據(jù)報(bào)表和對(duì)應(yīng)的操作權(quán)限(比如操作財(cái)務(wù)審批等);

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

業(yè)務(wù)是不斷創(chuàng)新和發(fā)展的,隨著業(yè)務(wù)的發(fā)展,會(huì)有越來(lái)越多的新的角色被設(shè)置和創(chuàng)建。

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

(4)角色繼承:角色權(quán)限的繼承

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

(5)角色互斥:角色包含的權(quán)限互斥

角色互斥的業(yè)務(wù)背景:當(dāng)一個(gè)業(yè)務(wù)流程由于風(fēng)控的原因,需要將其操作給劃分成分開的幾個(gè)步驟時(shí),需要給這幾個(gè)不同的步驟授權(quán)不同的角色,并且這些角色之間需要進(jìn)行互斥。

比如大額財(cái)務(wù)報(bào)銷審批流程,財(cái)務(wù)人員【小張】擁有了審批人權(quán)限后,就無(wú)法將審核確認(rèn)的權(quán)限再授予小張,以此來(lái)規(guī)避一個(gè)人完成大額報(bào)銷而帶來(lái)的財(cái)務(wù)風(fēng)險(xiǎn);

(6)臨時(shí)角色

臨時(shí)角色往往是針對(duì)特殊群體設(shè)置的,比如公司有特殊訪問(wèn)團(tuán)隊(duì)蒞臨,需要給這些特殊的客戶一些臨時(shí)身份來(lái)體驗(yàn)?zāi)承┕δ懿僮?。那么把這些人添加到部門的組織架構(gòu)中顯然是不合適的,因?yàn)檫@些人只是臨時(shí)的擺放者,不是企業(yè)員工;

其次,這些客戶需要體驗(yàn)的功能操作往往是橫跨多個(gè)業(yè)務(wù)模塊和產(chǎn)品線的(比較繁雜),一般公司并沒(méi)有現(xiàn)成的固定角色符合擁有客戶所需的全部操作權(quán)限,因此需要給這些客戶開設(shè)臨時(shí)角色,并且支持給臨時(shí)角色最大的權(quán)限選擇空間;

(7)黑白名單

顧名思義,黑名單即不能擁有任何權(quán)限,白名單即可以擁有相應(yīng)的權(quán)限。這個(gè)需要根據(jù)業(yè)務(wù)需求特殊設(shè)置。

3. 權(quán)限管理

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

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

image.jpeg

注:如圖為某一后臺(tái)產(chǎn)品的部分截圖,其中可見(jiàn)功能菜單頁(yè)、功能操作按鈕和數(shù)據(jù)字段。

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

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

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

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

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

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

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

數(shù)據(jù)是指系統(tǒng)內(nèi)的某些類別的數(shù)據(jù)需要擁有權(quán)限才可以操作,如同樣是客戶數(shù)據(jù),但需要將不同渠道來(lái)的客戶加以劃分,分配給不同的管理人員管理。例如某個(gè)員工擁有編輯客戶資料的權(quán)限,但是對(duì)應(yīng)編輯的客戶數(shù)據(jù)沒(méi)有權(quán)限也是不能操作的。

三. 案例分析

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

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

image.jpeg
image.jpeg

注:以上為某產(chǎn)品的促銷活動(dòng)管理后臺(tái)截圖

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

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

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

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

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

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

四. Q&A

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

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

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

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

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

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

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容