RBAC深度擴(kuò)展的通用權(quán)限系統(tǒng)

regon
2 評(píng)論 449 瀏覽 1 收藏 16 分鐘
🔗 产品经理专业技能指的是:需求分析、数据分析、竞品分析、商业分析、行业分析、产品设计、版本管理、用户调研等。

隨著系統(tǒng)數(shù)量的增加和業(yè)務(wù)復(fù)雜度的提升,傳統(tǒng)的分散式權(quán)限管理逐漸暴露出諸多問題,如管理難度大、監(jiān)管困難等。本文將詳細(xì)介紹一家中型互聯(lián)網(wǎng)公司如何基于RBAC理論構(gòu)建深度擴(kuò)展的通用權(quán)限系統(tǒng),實(shí)現(xiàn)權(quán)限管理的統(tǒng)一化、精細(xì)化和高效化。

一、背景和目標(biāo)

公司是一家中型互聯(lián)網(wǎng)類公司,人員規(guī)模在5000人左右,信息化已經(jīng)有了10余年的歷史。在這十多年中,進(jìn)行了非常多的信息系統(tǒng)建設(shè),每個(gè)系統(tǒng)都有自己的權(quán)限管理模塊。因?yàn)楦鱾€(gè)系統(tǒng)建設(shè)的時(shí)間不同、背景不同,權(quán)限管理的模塊差異很大、能力參差不齊,使得管理難度大幅提升,建設(shè)統(tǒng)一權(quán)限服務(wù)的需求就醞釀而生。

1.1 痛點(diǎn)

  • 業(yè)務(wù)細(xì)化、管理深入,不同系統(tǒng)對(duì)于權(quán)限管理的需求越來越精細(xì)
  • 系統(tǒng)眾多、難以管理,管理員在不同系統(tǒng)中進(jìn)行權(quán)限管理的難度增加
  • 系統(tǒng)眾多、監(jiān)管困難,權(quán)限散落在各個(gè)系統(tǒng),無法形成有效監(jiān)管

1.2 目標(biāo)

  • 建設(shè)統(tǒng)一的通用權(quán)限系統(tǒng),取代各個(gè)系統(tǒng)的權(quán)限管理模塊
  • 提供強(qiáng)大的權(quán)限管理能力,滿足全部系統(tǒng)的權(quán)限管理需求
  • 統(tǒng)一的管理方式,支持按照用戶角色授權(quán)管理,簡化授權(quán)操作

二、產(chǎn)品規(guī)劃

2.1 產(chǎn)品架構(gòu)圖

2.2 業(yè)務(wù)流程圖

2.3 理論基礎(chǔ)

公司選擇了基于RBAC理論的產(chǎn)品建設(shè),同時(shí)結(jié)合公司管理的精細(xì)度,進(jìn)行了抽象設(shè)計(jì),提煉出亮點(diǎn)能力包括完善的數(shù)據(jù)權(quán)限管理、以及中臺(tái)角色的集中管理。

2.3.1 RBAC理論

RBAC理論在互聯(lián)網(wǎng)企業(yè)得到了非常廣泛的使用,具備較好的用戶基礎(chǔ),對(duì)比之后,我們也選擇以RBAC為基礎(chǔ)。

RBAC是基于角色的權(quán)限管控,角色的一端是權(quán)限(菜單/功能),另一端是人,能較好解決基礎(chǔ)的權(quán)限管理問題。

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

隨著業(yè)務(wù)分工的細(xì)化,在很多系統(tǒng)中,單一的權(quán)限(菜單/功能),授權(quán)的不同用戶,其可查看的數(shù)據(jù)范圍不同,但RBAC0-RBAC3都無法支撐該問題的解決,所以我們拓展了RBAC,并最終選定了如下方案:

  • 基于RBAC,建立角色,配置角色權(quán)限(菜單/功能),把用戶添加到角色
  • 對(duì)每一個(gè)權(quán)限(菜單/功能),可設(shè)置所需要的數(shù)據(jù)權(quán)限維度
  • 角色中,每個(gè)用戶,針對(duì)每個(gè)權(quán)限(菜單/功能),可設(shè)置不同的數(shù)據(jù)權(quán)限

這里為什么沒有把數(shù)據(jù)權(quán)限作為菜單/功能權(quán)限的一部分?即對(duì)每一類擁有相同數(shù)據(jù)權(quán)限的人設(shè)置為一個(gè)獨(dú)立角色,更符合RBAC定義、也更清晰,賣個(gè)關(guān)子,在文章最后我們?cè)賮砘卮疬@個(gè)問題。

2.3.3 中臺(tái)角色

公司的很多系統(tǒng)中,都有相同的角色設(shè)定,隨著產(chǎn)品功能越來越多,角色的能力邊界開始變得模糊,同一個(gè)物理角色在不同系統(tǒng)中被賦予了近似但不同的定義。

通過在集團(tuán)公司層面統(tǒng)一的角色管理和定位,每一個(gè)物理角色對(duì)應(yīng)唯一一個(gè)系統(tǒng)角色,跨系統(tǒng)進(jìn)行權(quán)限管控,對(duì)管理者、使用者、內(nèi)控/內(nèi)審等都是非常有價(jià)值的事情。

2.4 相關(guān)用戶

1.系統(tǒng)管理員

系統(tǒng)管理員(研發(fā))負(fù)責(zé)進(jìn)行基礎(chǔ)數(shù)據(jù)的配置,如各系統(tǒng)的菜單初始化導(dǎo)入、數(shù)據(jù)維度的字典創(chuàng)建

2.產(chǎn)品經(jīng)理

其他各業(yè)務(wù)系統(tǒng)的產(chǎn)品經(jīng)理是本產(chǎn)品的主要用戶,進(jìn)行角色管理,創(chuàng)建角色、為角色配置菜單、配置授權(quán)人

3.授權(quán)人

即業(yè)務(wù)管理員,比如人事、財(cái)務(wù)的系統(tǒng)對(duì)接人,是本產(chǎn)品最常用的用戶,日常給普通用戶做授權(quán)

4.普通用戶

被授權(quán)人,不直接進(jìn)入本系統(tǒng),通過本系統(tǒng)獲取特定系統(tǒng)功能的權(quán)限

三、功能設(shè)計(jì)

3.1 角色管理

RBAC是以角色為中心的,角色管理是基礎(chǔ)能力。除了常規(guī)的角色一覽、新增、編輯、刪除,還提供了復(fù)制的能力,同時(shí)重點(diǎn)介紹下權(quán)限設(shè)定的能力。

本功能的用戶是其他各業(yè)務(wù)系統(tǒng)的產(chǎn)品經(jīng)理。

3.1.1 角色一覽

產(chǎn)品原型圖供參考

3.1.2 角色新建/編輯

1.業(yè)務(wù)類型

如圖編號(hào)1,角色所屬的業(yè)務(wù)類型,不同業(yè)務(wù)類型的角色只能綁定對(duì)應(yīng)類型的菜單(下面菜單管理中也有業(yè)務(wù)類型屬性),這樣做到數(shù)據(jù)隔離。

2.授權(quán)范圍

通常,對(duì)于公司級(jí)的角色,設(shè)置授權(quán)人為業(yè)務(wù)管理員,比如人事、財(cái)務(wù)的系統(tǒng)對(duì)接人。

在授權(quán)方面,還支持部門內(nèi)授權(quán),即把一些偏行政類權(quán)限授權(quán)給部門負(fù)責(zé)人,部門負(fù)責(zé)人根據(jù)自己部門的需要再向下授權(quán)。

3.1.3 權(quán)限設(shè)定

1.同一個(gè)角色可管理的權(quán)限(菜單/功能)范圍跨越多個(gè)系統(tǒng)

參考圖中編號(hào)1,切換不同系統(tǒng)名稱可綁定多個(gè)系統(tǒng)的菜單到該角色。

2.菜單的數(shù)據(jù)維度設(shè)置

左側(cè)菜單列表中,菜單名稱右側(cè)的紅字,如圖中編號(hào)2,“業(yè)態(tài)”、“財(cái)務(wù)公司”、“部門”這些,就是數(shù)據(jù)維度,在菜單管理中,定義不同的菜單能支持哪些數(shù)據(jù)維度的權(quán)限控制。

對(duì)每個(gè)角色,選擇包含哪些菜單,同時(shí)設(shè)定這些菜單可以授權(quán)的數(shù)據(jù)維度的范圍,做出限定;限定后,在權(quán)限分配中,角色管理員,只能對(duì)用戶授予不超過該范圍的數(shù)據(jù)權(quán)限。

在實(shí)務(wù)場景中,多數(shù)情況數(shù)據(jù)維度的權(quán)限范圍會(huì)設(shè)置為“全部”,如圖中“業(yè)態(tài)”中全部數(shù)據(jù)、“財(cái)務(wù)公司”的全部數(shù)據(jù),這樣就把權(quán)利下放給了角色的授權(quán)人,授權(quán)人(業(yè)務(wù)管理員)在權(quán)限分配中可以靈活進(jìn)行數(shù)據(jù)權(quán)限配置。

3.為不同菜單限定數(shù)據(jù)權(quán)限范圍

參考圖中編號(hào)3,為不同的菜單設(shè)置不同的數(shù)據(jù)權(quán)限范圍,后文權(quán)限分配時(shí)會(huì)進(jìn)一步說明。

4.系統(tǒng)間權(quán)限隔離

不同的產(chǎn)品經(jīng)理,實(shí)際在負(fù)責(zé)不同的系統(tǒng),那么在角色中只能配置有權(quán)限系統(tǒng)的菜單權(quán)限。哪個(gè)產(chǎn)品經(jīng)理負(fù)責(zé)哪些系統(tǒng)也是一種權(quán)限設(shè)置,也通過本系統(tǒng)中內(nèi)置的角色實(shí)現(xiàn)。

5.菜單數(shù)據(jù)權(quán)限組合說明

  • 不同組合之間是并集的關(guān)系
  • 同一個(gè)組合之間不同的數(shù)據(jù)維度是交集的關(guān)系
  • 同一個(gè)組合之間的部分?jǐn)?shù)據(jù)權(quán)限是有關(guān)聯(lián)關(guān)系的,這是在后臺(tái)維護(hù)的,一般數(shù)據(jù)維度都是公司統(tǒng)一規(guī)劃的,未開放給產(chǎn)品經(jīng)理做前臺(tái)維護(hù)

3.2 權(quán)限分配

權(quán)限分配是產(chǎn)品使用率最高的功能,業(yè)務(wù)管理員,比如人事、財(cái)務(wù)的系統(tǒng)對(duì)接人,通過該功能,給普通用戶授予權(quán)限。

3.2.1 權(quán)限一覽

業(yè)務(wù)管理員只能查看有權(quán)限的角色對(duì)應(yīng)的授權(quán)數(shù)據(jù)

3.2.2 權(quán)限添加/編輯

業(yè)務(wù)管理員通過該功能給用戶添加/編輯權(quán)限;可以設(shè)置有效期,過期自動(dòng)失效;可以同時(shí)對(duì)多用戶進(jìn)行授權(quán)。

1.角色中跨多系統(tǒng)授權(quán)

作為業(yè)務(wù)管理員,比如人事的系統(tǒng)接口人,是可以管理全部人事系統(tǒng)的角色的,所以對(duì)人事相關(guān)的多個(gè)系統(tǒng)的菜單,其都可以進(jìn)行管理,不需要再做權(quán)限劃分,如圖中編號(hào)1,點(diǎn)擊不同系統(tǒng)名稱對(duì)不同系統(tǒng)菜單進(jìn)行設(shè)置。

2.角色中菜單權(quán)限范圍

對(duì)于該角色的用戶,其擁有該角色的全部功能(菜單)權(quán)限,為了保證管理的清晰,一個(gè)角色對(duì)應(yīng)的不同用戶的功能范圍是一致的,這也符合RBAC的規(guī)范。

3.對(duì)菜單授予數(shù)據(jù)權(quán)限

對(duì)于該角色中的不同菜單,可以設(shè)置不同的數(shù)據(jù)權(quán)限組。通過選中左側(cè)特定的一個(gè)或多個(gè)菜單,點(diǎn)擊圖中編號(hào)3的按鈕,即可對(duì)選中菜單設(shè)置數(shù)據(jù)權(quán)限組。如果在設(shè)置過程中,右側(cè)有多個(gè)數(shù)據(jù)權(quán)限組,那么點(diǎn)擊編號(hào)3的按鈕時(shí),會(huì)彈出子窗口讓用戶選擇該選中菜單使用哪個(gè)數(shù)據(jù)權(quán)限組。

與菜單權(quán)限不同,該角色的不同用戶,可以擁有不同的數(shù)據(jù)權(quán)限。

在角色配置中,限定了一個(gè)角色只能設(shè)置一個(gè)菜單數(shù)據(jù)權(quán)限組,但在本頁面中,系統(tǒng)支持多菜單數(shù)據(jù)權(quán)限組,對(duì)不同的菜單,配置不同的數(shù)據(jù)權(quán)限組,使用上更靈活。

4.菜單授權(quán)數(shù)據(jù)權(quán)限狀態(tài)變化

對(duì)于已經(jīng)設(shè)置了數(shù)據(jù)權(quán)限的菜單,系統(tǒng)會(huì)顯示為“已配置”、未設(shè)置數(shù)據(jù)權(quán)限的菜單,系統(tǒng)會(huì)顯示“未配置”,參考圖中編號(hào)2,便于業(yè)務(wù)管理員直觀看到數(shù)據(jù)權(quán)限授予的情況。

5.菜單授予數(shù)據(jù)權(quán)限反向查看

哪些菜單授予了哪些數(shù)據(jù)權(quán)限組,是個(gè)一對(duì)多的關(guān)系。如圖中編號(hào)4處,可反向查看每個(gè)數(shù)據(jù)權(quán)限組和哪些菜單建立了關(guān)系,點(diǎn)擊編號(hào)4的圖標(biāo),會(huì)顯示該數(shù)據(jù)權(quán)限組對(duì)應(yīng)的菜單列表。

6.模版功能(添加模版)

對(duì)于經(jīng)常使用的數(shù)據(jù)權(quán)限組合,可以通過保存模版,達(dá)到一次配置,多次使用的目的。模版能力不展開介紹了。

3.3 菜單管理

通過菜單管理,配置其他各個(gè)系統(tǒng)的菜單/功能,供角色管理使用。

3.3.1 菜單一覽

3.3.2 菜單新增/編輯

1.菜單所屬系統(tǒng)、類型

參考圖中編號(hào)1,權(quán)限中臺(tái)會(huì)承載公司不同業(yè)務(wù)系統(tǒng),包括專屬的財(cái)務(wù)、人事系統(tǒng),以及通用的OA等系統(tǒng)。這里如果標(biāo)記為特定的類型,那么可以通過內(nèi)置的角色進(jìn)行數(shù)據(jù)授權(quán),控制哪些用戶可以訪問哪類的菜單數(shù)據(jù),從而達(dá)到數(shù)據(jù)隔離管理。

對(duì)應(yīng)的,在角色管理中,也限定了不同類型角色只能引用該類型的菜單。

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

參考圖中編號(hào)2,對(duì)于不同的菜單,對(duì)支持的數(shù)據(jù)維度進(jìn)行配置。僅當(dāng)菜單支持這個(gè)維度,那么在角色設(shè)置、權(quán)限分配中,才能對(duì)該菜單的這個(gè)數(shù)據(jù)維度配置權(quán)限。

四、后記

4.1 數(shù)據(jù)權(quán)限不作為菜單/功能的擴(kuò)展

回答前文中對(duì)于數(shù)據(jù)權(quán)限設(shè)計(jì)的取舍問題,如果把數(shù)據(jù)權(quán)限作為菜單/功能權(quán)限的擴(kuò)展,使得一個(gè)角色只有唯一一組菜單、唯一一組數(shù)據(jù)權(quán)限,有以下幾點(diǎn)問題:

  • 擁有不同的數(shù)據(jù)權(quán)限的用戶,就會(huì)產(chǎn)生不同的角色,角色會(huì)非常多,管理困難;
  • 以我們公司管理的精細(xì)度來看,分工很精細(xì),基本上一個(gè)數(shù)據(jù)維度只有1個(gè)人,這樣角色的意義就不存在了。因?yàn)榻巧褪菫榱硕x一類人;
  • 因?yàn)闃I(yè)務(wù)分工細(xì)致(按數(shù)據(jù)維度),分工的調(diào)整也比較靈活,角色的設(shè)置無法滿足如此靈活的設(shè)置,而且如果定義了一個(gè)角色有多個(gè)人,那么彼此之間的權(quán)限又會(huì)互相影響;
  • 最后,從公司情況看,進(jìn)行角色梳理難度也比較大,業(yè)務(wù)價(jià)值不明顯,所以放棄了一定的規(guī)范性,而選擇了靈活性。

4.2 各產(chǎn)品接入權(quán)限中臺(tái)

本文專注于權(quán)限中臺(tái)的產(chǎn)品本身的設(shè)計(jì)和思考,并沒有過多體現(xiàn)相關(guān)產(chǎn)品的接入。

對(duì)企業(yè)來講,權(quán)限中臺(tái)的產(chǎn)品出現(xiàn)時(shí),必然已經(jīng)有很多獨(dú)立式煙囪產(chǎn)品存在了,而且這些獨(dú)立產(chǎn)品都有各自的權(quán)限模塊或能力,如何推動(dòng)相關(guān)產(chǎn)品放棄自己的權(quán)限模塊,接入權(quán)限中臺(tái),以及在這個(gè)過程中,權(quán)限中臺(tái)應(yīng)該怎么做好定位,如何厘定能力邊界,建設(shè)通用能力和靈活的適配能力,也是產(chǎn)品非常重要的組成部分,且更有挑戰(zhàn)性,受限于篇幅,就不在本文贅述了。

本文由 @regon 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)作者許可,禁止轉(zhuǎn)載

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

該文觀點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺(tái)僅提供信息存儲(chǔ)空間服務(wù)

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
11-175989 瀏覽
白話清算
"="" class="meta">04-194842 瀏覽
"="" class="meta">
"="" class="meta"> "="" src="https://image.woshipm.com/wp-files/2023/04/GgUiEM4oNAc8DUchMgNG.jpg!/both/120x80" alt="B端產(chǎn)品設(shè)計(jì)如何做到「情懷」與「效率」兼?zhèn)洌?>
="">
"="" src="https://image.woshipm.com/wp-files/2023/04/GgUiEM4oNAc8DUchMgNG.jpg!/both/120x80" alt="B端產(chǎn)品設(shè)計(jì)如何做到「情懷」與「效率」兼?zhèn)洌?>
="">
"="" src="https://image.woshipm.com/wp-files/2023/04/GgUiEM4oNAc8DUchMgNG.jpg!/both/120x80" alt="B端產(chǎn)品設(shè)計(jì)如何做到「情懷」與「效率」兼?zhèn)洌?>
="">客戶體驗(yàn)|激活消費(fèi),體驗(yàn)先行,把產(chǎn)品做細(xì),把服務(wù)做暖!
02-076577 瀏覽
客戶體驗(yàn)|激活消費(fèi),體驗(yàn)先行,把產(chǎn)品做細(xì),把服務(wù)做暖!
評(píng)論
評(píng)論請(qǐng)登錄
  1. 感謝@盲點(diǎn)老師的點(diǎn)評(píng),非常中肯。
    中臺(tái)型的產(chǎn)品,確實(shí)需要一些技術(shù)背景,更容易落地;
    本產(chǎn)品設(shè)計(jì),站在了巨人的肩膀上,不斷在簡潔設(shè)計(jì)與豐富功能之間徘徊;我理解好的產(chǎn)品是要結(jié)合公司的落地去思考,如何讓多數(shù)人覺得產(chǎn)品依然簡單易用、少數(shù)專業(yè)人士也能滿足特定的一些管理訴求,有非常多的討論和取舍;
    在做這個(gè)產(chǎn)品之前,也被這個(gè)領(lǐng)域所困擾多年,不是最完善的設(shè)計(jì),期望能拋磚引玉給更多人以思路參考。

    來自北京 回復(fù)
  2. 這篇關(guān)于RBAC通用權(quán)限系統(tǒng)的文章,讀下來感覺作者把一個(gè)挺復(fù)雜的問題講得還算清楚,但整體讀起來有點(diǎn)像在啃“硬骨頭”,適合那些對(duì)權(quán)限管理有剛需的行內(nèi)人,外行估計(jì)會(huì)被繞暈。

    首先,背景部分很實(shí)在,直接點(diǎn)出了公司面臨的問題——系統(tǒng)多、權(quán)限管理模塊亂,管理起來費(fèi)勁,這種痛點(diǎn)很能引起有相似情況的企業(yè)的共鳴。目標(biāo)也很明確,就是要搞一個(gè)統(tǒng)一的權(quán)限系統(tǒng),把散落各處的權(quán)限管理整合起來,聽起來就很“解渴”。

    在產(chǎn)品規(guī)劃部分,架構(gòu)圖和業(yè)務(wù)流程圖看著挺專業(yè),不過對(duì)于沒技術(shù)背景的人來說,可能就跟看天書一樣。理論基礎(chǔ)講得比較細(xì),RBAC理論的引入很合理,畢竟這東西在互聯(lián)網(wǎng)企業(yè)用得挺廣,有群眾基礎(chǔ)。數(shù)據(jù)權(quán)限的拓展部分,能看出作者是下了功夫的,畢竟單純的RBAC理論解決不了他們公司的問題,這種“因地制宜”的改造挺有創(chuàng)意,但讀起來也挺燒腦的。

    功能設(shè)計(jì)這塊,角色管理和權(quán)限分配講得很細(xì),各種細(xì)節(jié)和功能點(diǎn)都考慮到了,能看出作者是站在實(shí)際使用場景的角度去設(shè)計(jì)的,很用心。不過,這些功能點(diǎn)雖然強(qiáng)大,但操作起來估計(jì)得花不少時(shí)間去學(xué)習(xí)和適應(yīng),對(duì)使用者的要求挺高的。

    最后的后記部分,作者解釋了為什么數(shù)據(jù)權(quán)限不作為菜單/功能的擴(kuò)展,這個(gè)解釋挺關(guān)鍵的,能讓人理解他們?cè)O(shè)計(jì)上的取舍,也讓整個(gè)系統(tǒng)的設(shè)計(jì)邏輯更完整。

    總的來說,這篇文章干貨很多,但讀起來比較費(fèi)勁,適合那些對(duì)權(quán)限管理有深入了解需求的人。對(duì)于普通讀者來說,可能會(huì)覺得有點(diǎn)晦澀難懂。不過,能看出來作者是花了心思去解決實(shí)際問題的,這種務(wù)實(shí)的態(tài)度還是值得肯定的。

    來自吉林 回復(fù)
专题
16106人已学习13篇文章
在互联网时代,把网站的服务封装成一系列计算机易识别的数据接口开放出去,供第三方开发者使用,这种行为就叫做Open API。 而提供开放API的平台本身就被称为开放平台。本专题的文章分享了开放平台的搭建思路。
专题
14842人已学习13篇文章
在产品的商业模式中,广告变现占据了很大的比重,那么广告功能就是产品里面非常重要的功能之一。本专题的文章分享了如何搭建广告投放系统。
专题
15283人已学习12篇文章
服务设计在流程性和系统性的问题解决方面提供很好的思路和方法。本专题的文章分享了如何做好服务设计。
专题
13123人已学习14篇文章
各种大模型和AI绘画的产品层出不穷,在各行业也在尝试进行应用。在这个阶段,AIGC能实现些什么?本专题的文章分享了AIGC的应用。
专题
36448人已学习15篇文章
击溃顾客最后的心理防线,让他们心甘情愿按下购买按钮。
专题
36208人已学习13篇文章
用户分层本身并不是目的,只是实现业务发展的手段方式。