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

3 評論 1504 瀏覽 7 收藏 16 分鐘

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

一、背景和目標

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

1.1 痛點

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

1.2 目標

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

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

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

2.2 業(yè)務流程圖

2.3 理論基礎

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

2.3.1 RBAC理論

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

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

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

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

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

這里為什么沒有把數(shù)據(jù)權(quán)限作為菜單/功能權(quán)限的一部分?即對每一類擁有相同數(shù)據(jù)權(quán)限的人設置為一個獨立角色,更符合RBAC定義、也更清晰,賣個關子,在文章最后我們再來回答這個問題。

2.3.3 中臺角色

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

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

2.4 相關用戶

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

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

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

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

3.授權(quán)人

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

4.普通用戶

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

三、功能設計

3.1 角色管理

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

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

3.1.1 角色一覽

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

3.1.2 角色新建/編輯

1.業(yè)務類型

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

2.授權(quán)范圍

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

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

3.1.3 權(quán)限設定

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

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

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

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

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

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

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

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

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

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

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

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

3.2 權(quán)限分配

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

3.2.1 權(quán)限一覽

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

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

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

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

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

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

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

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

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

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

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

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

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

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

哪些菜單授予了哪些數(shù)據(jù)權(quán)限組,是個一對多的關系。如圖中編號4處,可反向查看每個數(shù)據(jù)權(quán)限組和哪些菜單建立了關系,點擊編號4的圖標,會顯示該數(shù)據(jù)權(quán)限組對應的菜單列表。

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

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

3.3 菜單管理

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

3.3.1 菜單一覽

3.3.2 菜單新增/編輯

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

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

對應的,在角色管理中,也限定了不同類型角色只能引用該類型的菜單。

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

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

四、后記

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

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

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

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

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

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

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

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

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

更多精彩內(nèi)容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 您好,能不能幫解答下“使得一個角色只有唯一一組菜單、唯一一組數(shù)據(jù)權(quán)限”這句話什么含義?可否方便解答下

    來自山東 回復
  2. 感謝@盲點老師的點評,非常中肯。
    中臺型的產(chǎn)品,確實需要一些技術(shù)背景,更容易落地;
    本產(chǎn)品設計,站在了巨人的肩膀上,不斷在簡潔設計與豐富功能之間徘徊;我理解好的產(chǎn)品是要結(jié)合公司的落地去思考,如何讓多數(shù)人覺得產(chǎn)品依然簡單易用、少數(shù)專業(yè)人士也能滿足特定的一些管理訴求,有非常多的討論和取舍;
    在做這個產(chǎn)品之前,也被這個領域所困擾多年,不是最完善的設計,期望能拋磚引玉給更多人以思路參考。

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

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

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

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

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

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

    來自吉林 回復