超全面的用戶權(quán)限系統(tǒng)產(chǎn)品設(shè)計(jì)方案
在B端和后臺(tái)系統(tǒng)中,經(jīng)常會(huì)用到權(quán)限設(shè)計(jì)。這篇文章,作者幫我們梳理了權(quán)限系統(tǒng)的類型、模型,希望能幫到大家。
這段時(shí)間在梳理公司的角色權(quán)限關(guān)系,為了設(shè)計(jì)更加合理,我對(duì)角色權(quán)限系統(tǒng)進(jìn)行系統(tǒng)化的學(xué)習(xí)和整理,以下將我的整理結(jié)果,和大家分享一下。
一、權(quán)限管理概述
權(quán)限管理是所有后臺(tái)系統(tǒng)的都會(huì)涉及的一個(gè)重要組成部分,主要目的是對(duì)不同的人訪問(wèn)資源進(jìn)行權(quán)限的控制,避免因權(quán)限控制缺失或操作不當(dāng)引發(fā)的風(fēng)險(xiǎn)問(wèn)題,如操作錯(cuò)誤,隱私數(shù)據(jù)泄露等問(wèn)題。
在企業(yè)的權(quán)限管理中,通常有兩類權(quán)限,一類是頁(yè)面/應(yīng)用的訪問(wèn)權(quán)限,一類是數(shù)據(jù)權(quán)限
二、權(quán)限控制類型
產(chǎn)品的權(quán)限由頁(yè)面、操作和數(shù)據(jù)構(gòu)成,頁(yè)面與操作相互關(guān)聯(lián),必須擁有頁(yè)面權(quán)限,才能分配該頁(yè)面下對(duì)應(yīng)的操作權(quán)限。
其中:
- 頁(yè)面權(quán)限指的是可以看到的頁(yè)面
- 操作權(quán)限指的是用戶可以進(jìn)行的操作,例如是否可以新增、刪除、編輯等
- 數(shù)據(jù)權(quán)限指的是可以查看數(shù)據(jù)的范圍。
1. 功能權(quán)限–對(duì)象
對(duì)象指賦予權(quán)限的人、角色、用戶組、組織、崗位
1)人
某個(gè)人擁有某個(gè)權(quán)限,在公司規(guī)模比較小的時(shí)候,可以簡(jiǎn)單設(shè)置哪些人可以看到哪些權(quán)限,維護(hù)成本不高;若只綁定人而不綁定角色的弊端:
- 當(dāng)人數(shù)過(guò)多時(shí)沒(méi)有分類,無(wú)法快速辨別哪類人擁有權(quán)限;
- 當(dāng)一群人擁有多個(gè)模塊的相同權(quán)限時(shí),需要把這群人分別為每個(gè)模塊添加權(quán)限,工作量成倍數(shù)增長(zhǎng);
- 當(dāng)創(chuàng)建新用戶時(shí),需要為其增加多個(gè)模塊的權(quán)限。
2)角色
當(dāng)公司規(guī)模較多時(shí),有可能一些人控制某個(gè)模塊的權(quán)限,這時(shí)候就需要引入角色的功能,把這些人綁定到一個(gè)角色里,再把角色賦予權(quán)限,這樣就可以清晰的看見(jiàn)模塊權(quán)限對(duì)應(yīng)哪些角色,解決用戶數(shù)量大的情況下,用戶分配權(quán)限繁瑣以及用戶—權(quán)限關(guān)系維護(hù)成本高的問(wèn)題,節(jié)省了大量的資源。
3)用戶組
用戶組是將具有相同屬性的用戶組合在一起,用戶組是一群用戶的組合,而角色是用戶和權(quán)限之間的橋梁。
如果一批用戶需要相同的角色,我們也需要逐個(gè)為用戶分配角色。
例如,一個(gè)公司的客服部門有500多名員工。某一天,研發(fā)部門開(kāi)發(fā)了一套后臺(tái)數(shù)據(jù)查詢產(chǎn)品,所有客服人員都需要使用。然而,由于之前并未統(tǒng)一為所有客服人員分配一個(gè)角色,現(xiàn)在需要新增一個(gè)角色,將權(quán)限分配給該角色,然后再逐個(gè)將角色分配給客服人員。發(fā)現(xiàn)為500名用戶逐個(gè)添加角色非常繁瑣。然而,客服人員具有共同屬性,因此我們可以創(chuàng)建一個(gè)用戶組,所有客服人員都屬于該客服用戶組,將角色分配給客服用戶組,這樣該用戶組下的所有用戶便擁有了所需權(quán)限。
用戶可以進(jìn)行分組,這有助于簡(jiǎn)化用戶與角色之間的對(duì)應(yīng)關(guān)系;用戶可以分組,權(quán)限也可以分組。
在權(quán)限特別繁多的情況下,可以將一個(gè)模塊的權(quán)限組合成一個(gè)權(quán)限組,這有助于簡(jiǎn)化權(quán)限和角色之間的對(duì)應(yīng)關(guān)系。
4)組織
每個(gè)公司內(nèi)部均構(gòu)建有其獨(dú)特的組織架構(gòu),而在實(shí)踐中,權(quán)限分配常常會(huì)依據(jù)這一架構(gòu)進(jìn)行細(xì)化劃分。
其原因在于,同一組織單元內(nèi)的成員通常需要執(zhí)行相似的工作職能,因而對(duì)權(quán)限的需求大體一致。
遵循公司的組織架構(gòu),同一組織內(nèi)成員所配備的基礎(chǔ)權(quán)限往往具有較高的一致性。
按照組織架構(gòu)來(lái)設(shè)定角色并分配權(quán)限的做法,實(shí)際上包括以下兩個(gè)優(yōu)勢(shì):
① 實(shí)現(xiàn)權(quán)限分配的自動(dòng)化
實(shí)現(xiàn)組織關(guān)系與權(quán)限系統(tǒng)的深度融合后,對(duì)于新入職員工,只需將其歸入相應(yīng)的組織單元,其角色權(quán)限便會(huì)自動(dòng)繼承該組織下的所有權(quán)限設(shè)定,無(wú)需逐一進(jìn)行人工分配。
同樣,當(dāng)員工發(fā)生崗位調(diào)動(dòng)時(shí),僅需對(duì)其組織關(guān)系作出相應(yīng)調(diào)整,權(quán)限配置將隨之聯(lián)動(dòng)更新,全程無(wú)須人工介入。
此方案的實(shí)施首要前提是實(shí)現(xiàn)權(quán)限體系與組織結(jié)構(gòu)間的有效對(duì)接。
② 控制數(shù)據(jù)權(quán)限
通過(guò)將角色與特定組織緊密關(guān)聯(lián),確保該組織成員僅能訪問(wèn)其所屬組織層級(jí)內(nèi)的數(shù)據(jù),各部門成員僅能查看與自身組織直接相關(guān)的數(shù)據(jù),實(shí)現(xiàn)了跨部門數(shù)據(jù)的隔離與保護(hù)。
5)崗位
一個(gè)組織下面會(huì)有很多職位,比如財(cái)務(wù)管理會(huì)有財(cái)務(wù)總監(jiān)、財(cái)務(wù)主管、會(huì)計(jì)、出納員等職位,每個(gè)職位需要的權(quán)限是不一樣的,可以像組織那樣根據(jù)職位來(lái)分配不同的角色
2. 功能權(quán)限–級(jí)別
級(jí)別也稱賬號(hào)安全級(jí)別,一般通過(guò)0-100的數(shù)字控制用戶賬號(hào)的功能權(quán)限,通常設(shè)置的數(shù)值越大,權(quán)限范圍越大。
適用場(chǎng)景:比如創(chuàng)建的正式員工默認(rèn)安全級(jí)別為10,外包員工默認(rèn)為0,則當(dāng)某個(gè)功能開(kāi)放給所有人,并且這個(gè)功能僅限正式員工可操作時(shí),可通過(guò)限制此功能的安全級(jí)別(調(diào)整為10)控制只能正式員工查看。
功能組合:安全級(jí)別還可與對(duì)象(組織、角色、崗位、人、用戶組)組合,達(dá)到更精細(xì)化控制權(quán)限的目的,比如安全級(jí)別與部門相搭配,可控制此部門下特定的安全范圍的人可以操作功能。
3. 數(shù)據(jù)權(quán)限–時(shí)間
權(quán)限中的時(shí)間是指數(shù)據(jù)到達(dá)某個(gè)時(shí)間節(jié)點(diǎn)后,是否要繼續(xù)給用戶查看,應(yīng)用場(chǎng)景:比如外部人員需要查看某一年度的數(shù)據(jù)時(shí),只需開(kāi)放對(duì)應(yīng)時(shí)間的數(shù)據(jù)給他們,這么做就可以保證數(shù)據(jù)的安全,不會(huì)遭到泄露。
4. 數(shù)據(jù)權(quán)限–區(qū)域
權(quán)限中的區(qū)域也可以理解為范圍,是指某一區(qū)間的值,可以對(duì)區(qū)域范圍內(nèi)的數(shù)據(jù)進(jìn)行查看,應(yīng)用場(chǎng)景:比如共享單車的運(yùn)維人員只需查看他所負(fù)責(zé)的區(qū)域的車輛數(shù)據(jù)即可
三、權(quán)限的擴(kuò)展功能
1. 菜單權(quán)限
菜單權(quán)限一般分為前端菜單權(quán)限和后端菜單權(quán)限。前端菜單權(quán)限是指用戶層面操作的菜單頁(yè)面,后端菜單權(quán)限是指系統(tǒng)管理員、系統(tǒng)運(yùn)維人員層面操作的菜單頁(yè)面。
2. 權(quán)限轉(zhuǎn)移
對(duì)于員工從原部門調(diào)走,離職等情況的發(fā)生,當(dāng)有新員工接手他的工作時(shí),則需要權(quán)限轉(zhuǎn)移的功能。
轉(zhuǎn)移的內(nèi)容一般為角色、菜單,更精細(xì)化的內(nèi)容還可以分為下屬、待辦、已辦、文檔等,如果是CRM系統(tǒng),還可以轉(zhuǎn)移他的客戶等。
四、常見(jiàn)的權(quán)限管理模型
1. 基礎(chǔ)權(quán)限管理系統(tǒng)
–簡(jiǎn)單清晰但無(wú)法承載復(fù)雜的需求
基礎(chǔ)權(quán)限系統(tǒng)的設(shè)計(jì),一般都是從「用戶-權(quán)限」這兩個(gè)緯度開(kāi)始的,管理員需要為每一個(gè)用戶單獨(dú)定義權(quán)限。
如果系統(tǒng)中用戶數(shù)在幾十個(gè)上下,權(quán)限變動(dòng)也不太多時(shí),這種「用戶-權(quán)限」的權(quán)限管理邏輯簡(jiǎn)單清晰,很好用。
但當(dāng)系統(tǒng)中用戶開(kāi)始增多,到達(dá)上千、上萬(wàn)時(shí),此種管理方法的局限性就暴露出來(lái)了:
- 當(dāng)人數(shù)過(guò)多時(shí)沒(méi)有分類,無(wú)法快速辨別哪類人擁有權(quán)限;
- 當(dāng)一群人擁有多個(gè)模塊的相同權(quán)限時(shí),需要把這群人分別為每個(gè)模塊添加權(quán)限,工作量成倍數(shù)增長(zhǎng);
- 當(dāng)創(chuàng)建新用戶時(shí),需要為其增加多個(gè)模塊的權(quán)限。
2. 基于角色概念的權(quán)限設(shè)計(jì)–RBAC模型
1)RBAC0
RBAC0是基于角色的訪問(wèn)控制的完美體現(xiàn),也就是把權(quán)限賦予角色,然后再把角色賦予用戶,在這個(gè)模型中,角色起到了連接用戶和權(quán)限關(guān)系的橋梁作用。
每個(gè)角色可以擁有多個(gè)權(quán)限,每個(gè)用戶可以被分配多個(gè)角色,從而使用戶具備多個(gè)角色的多個(gè)權(quán)限。
在對(duì)角色權(quán)限系統(tǒng)進(jìn)行設(shè)計(jì)時(shí),只需給對(duì)應(yīng)的角色配置系統(tǒng)中的權(quán)限(菜單/操作/字段),完成角色創(chuàng)建后,再將角色賦予系統(tǒng)用戶即可。
這樣在用戶登錄后,就能獲取該用戶的所屬角色,然后通過(guò)角色來(lái)找到擁有的權(quán)限,再加載對(duì)應(yīng)的權(quán)限資源。
一般來(lái)說(shuō)包含菜單管理、用戶管理、角色管理等功能頁(yè)面
菜單管理:對(duì)頁(yè)面進(jìn)行配置,與訪問(wèn)路徑映射,填寫菜單路徑,設(shè)置頁(yè)面順序,方便訪問(wèn)
用戶管理:對(duì)用戶進(jìn)行管理,給用戶賦予角色
角色管理:對(duì)角色進(jìn)行管理,給角色分配權(quán)限
2)RBAC1–引入繼承的概念
如果一個(gè)部門人員很多,如一級(jí)部門向下還有二級(jí)部門,二級(jí)部門向下才是員工,這樣就導(dǎo)致如果采用RBAC0模型進(jìn)行權(quán)限管理的話,則很有可能錯(cuò)配權(quán)限的問(wèn)題。
角色繼承的RBAC模型又稱RBAC1模型,在角色繼承的RBAC模型中,上層角色會(huì)繼承下層角色的所有權(quán)限,并且可以額外擁有其他權(quán)限。下級(jí)角色的權(quán)限上級(jí)角色都具備,并且上級(jí)角色可以擁有其他權(quán)限
RBAC1模型相較于RBAC0模型增加了角色繼承的概念,有了角色繼承就有父子的關(guān)系,即子角色可擁有父角色的權(quán)限。
在配置角色的時(shí)候可以增加父角色的選擇,可在父角色的基礎(chǔ)上進(jìn)行刪減權(quán)限,以避免錯(cuò)配權(quán)限的問(wèn)題。
3)RBAC2–添加責(zé)任分離關(guān)系
RBAC2模型是RBAC0的另一變種,對(duì)用戶、角色和權(quán)限三者之間增加了一些限制。這些限制可以分成兩類,即靜態(tài)職責(zé)分離SSD(Static Separation of Duty)和動(dòng)態(tài)職責(zé)分離DSD(Dynamic Separation of Duty)。
① 靜態(tài)職責(zé)分離
- 互斥角色限制:一個(gè)用戶不能同時(shí)分配互斥角色中的多個(gè)角色,即只能選擇一個(gè)。比如如果想擁有審核員的角色就必須先去掉會(huì)計(jì)的角色。假設(shè)提交角色和審核角色是互質(zhì)的,我們可以用圖形表示:
- 基數(shù)限制:一個(gè)用戶擁有的角色是有限的。例如規(guī)定擁有超級(jí)管理員角色的用戶只能有1個(gè),用戶被分配的角色數(shù)量,以及角色分配的權(quán)限數(shù)量也可以被限制。
- 先決條件限制:一個(gè)用戶想獲得更高級(jí)的角色,首先需先擁有低級(jí)角色。比如技術(shù)負(fù)責(zé)人角色和普通技術(shù)員工角色存在上下級(jí)關(guān)系,因此用戶想要擁有技術(shù)負(fù)責(zé)人角色就必須先擁有普通技術(shù)員工角色。
② 動(dòng)態(tài)職責(zé)分離
- 動(dòng)態(tài)限制:一個(gè)用戶可以擁有兩個(gè)角色,但是運(yùn)行時(shí)只能激活一個(gè)角色。
4)RBAC3–基于RBAC0、RBAC1和RBAC2進(jìn)行整合
3. 數(shù)據(jù)權(quán)限
為了數(shù)據(jù)權(quán)限控制的靈活度,在角色管理中還可以設(shè)置角色的數(shù)據(jù)權(quán)限范圍
作者:諾兒筆記本,公眾號(hào):諾兒筆記本
本文由 @諾兒筆記本 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來(lái)自Unsplash,基于CC0協(xié)議。
該文觀點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺(tái)僅提供信息存儲(chǔ)空間服務(wù)。
數(shù)據(jù)權(quán)限是需要手動(dòng)分配比較好,還是直接綁定用戶所在部門和下級(jí)部門的數(shù)據(jù)范圍比較好?大家能否給點(diǎn)建議?
大多數(shù)的B端后臺(tái)角色權(quán)限,都只是分配到頁(yè)面操作和數(shù)據(jù),對(duì)與崗位和用戶租的劃分比較少,所以一直沒(méi)接觸到這么細(xì)化的分配,也可能是自己看得少了。謝謝分享
學(xué)習(xí)了,前段時(shí)間剛好碰到角色繼承的困惑,要是早點(diǎn)看到就好了
感謝樓主分享,之前很多混沌不清的概念給搞清楚了。
想咨詢一個(gè)問(wèn)題哈,RBAC3模式里面,把數(shù)據(jù)權(quán)限做成查詢條件的下拉枚舉值,可以嗎?感覺(jué)上好像權(quán)限沒(méi)有控制枚舉值的吧,但是這是我能想到最合適的辦法了。求大佬解答一下。
22