RBAC權(quán)限管理模型:基本模型及角色模型解析及舉例

66 評論 138006 瀏覽 714 收藏 9 分鐘

站在巨人的肩膀上我們可以看得更遠(yuǎn),而不是再造一個輪子。

我們在做任何一款產(chǎn)品的時候,或多或少都會涉及到用戶和權(quán)限的問題。譬如,做企業(yè)類軟件,不同部門、不同職位的人的權(quán)限是不同的;做論壇類產(chǎn)品的時候,版主和訪客權(quán)限也是不一樣的;再例如一款產(chǎn)品的收費(fèi)用戶和免費(fèi)用戶權(quán)限也是迥然不同的。

但在設(shè)計(jì)產(chǎn)品的用戶和權(quán)限的關(guān)系的時候,很多產(chǎn)品經(jīng)理可能按照感覺來,在并不清楚用戶和權(quán)限是否存在優(yōu)秀的理論模型的時候,就按照自我推理搭建了產(chǎn)品的用戶和權(quán)限模型。而這種基于感覺和推理的模型肯定是有諸多問題的,譬如寫死了關(guān)系導(dǎo)致權(quán)限不夠靈活、考慮不周導(dǎo)致權(quán)限覆蓋能力弱等等。

正如牛頓所言,站在巨人的肩膀上才能看的更遠(yuǎn)。我們不妨去參照已有的比較成熟的權(quán)限模型,如:RBAC(Role-Based Access Control)——基于角色的訪問控制。我搜集了網(wǎng)上很多關(guān)于RBAC的資料,大多與如何用數(shù)據(jù)表實(shí)現(xiàn)RBCA相關(guān),并不容易理解。所以,我會以產(chǎn)品經(jīng)理的角度去解析RBAC模型,并分別舉例如何運(yùn)用這套已得到驗(yàn)證的成熟模型。

一、RBAC模型是什么?

RBAC是一套成熟的權(quán)限模型。在傳統(tǒng)權(quán)限模型中,我們直接把權(quán)限賦予用戶。而在RBAC中,增加了“角色”的概念,我們首先把權(quán)限賦予角色,再把角色賦予用戶。這樣,由于增加了角色,授權(quán)會更加靈活方便。在RBAC中,根據(jù)權(quán)限的復(fù)雜程度,又可分為RBAC0、RBAC1、RBAC2、RBAC3。其中,RBAC0是基礎(chǔ),RBAC1、RBAC2、RBAC3都是以RBAC0為基礎(chǔ)的升級。我們可以根據(jù)自家產(chǎn)品權(quán)限的復(fù)雜程度,選取適合的權(quán)限模型。

1

二、基本模型RBAC0

解析:

RBAC0是基礎(chǔ),很多產(chǎn)品只需基于RBAC0就可以搭建權(quán)限模型了。在這個模型中,我們把權(quán)限賦予角色,再把角色賦予用戶。用戶和角色,角色和權(quán)限都是多對多的關(guān)系。用戶擁有的權(quán)限等于他所有的角色持有權(quán)限之和。

2

舉例:

譬如我們做一款企業(yè)管理產(chǎn)品,如果按傳統(tǒng)權(quán)限模型,給每一個用戶賦予權(quán)限則會非常麻煩,并且做不到批量修改用戶權(quán)限。這時候,可以抽象出幾個角色,譬如銷售經(jīng)理、財(cái)務(wù)經(jīng)理、市場經(jīng)理等,然后把權(quán)限分配給這些角色,再把角色賦予用戶。這樣無論是分配權(quán)限還是以后的修改權(quán)限,只需要修改用戶和角色的關(guān)系,或角色和權(quán)限的關(guān)系即可,更加靈活方便。此外,如果一個用戶有多個角色,譬如王先生既負(fù)責(zé)銷售部也負(fù)責(zé)市場部,那么可以給王先生賦予兩個角色,即銷售經(jīng)理+市場經(jīng)理,這樣他就擁有這兩個角色的所有權(quán)限。

三、角色分層模型RBAC1

解析:

RBAC1建立在RBAC0基礎(chǔ)之上,在角色中引入了繼承的概念。簡單理解就是,給角色可以分成幾個等級,每個等級權(quán)限不同,從而實(shí)現(xiàn)更細(xì)粒度的權(quán)限管理。

3

舉例:

基于之前RBAC0的例子,我們又發(fā)現(xiàn)一個公司的銷售經(jīng)理可能是分幾個等級的,譬如除了銷售經(jīng)理,還有銷售副經(jīng)理,而銷售副經(jīng)理只有銷售經(jīng)理的部分權(quán)限。這時候,我們就可以采用RBAC1的分級模型,把銷售經(jīng)理這個角色分成多個等級,給銷售副經(jīng)理賦予較低的等級即可。

四、角色限制模型RBAC2

解析:

RBAC2同樣建立在RBAC0基礎(chǔ)之上,僅是對用戶、角色和權(quán)限三者之間增加了一些限制。這些限制可以分成兩類,即靜態(tài)職責(zé)分離SSD(Static Separation of Duty)和動態(tài)職責(zé)分離DSD(Dynamic Separation of Duty)。具體限制如下圖:

4

舉例:

還是基于之前RBAC0的例子,我們又發(fā)現(xiàn)有些角色之間是需要互斥的,譬如給一個用戶分配了銷售經(jīng)理的角色,就不能給他再賦予財(cái)務(wù)經(jīng)理的角色了,否則他即可以錄入合同又能自己審核合同;再譬如,有些公司對角色的升級十分看重,一個銷售員要想升級到銷售經(jīng)理,必須先升級到銷售主管,這時候就要采用先決條件限制了。

五、統(tǒng)一模型RBAC3

解析:

RBAC3是RBAC1和RBAC2的合集,所以RBAC3既有角色分層,也包括可以增加各種限制。

5

舉例:

這個就不舉例了,統(tǒng)一模型RBAC3可以解決上面三個例子的所有問題。當(dāng)然,只有在系統(tǒng)對權(quán)限要求非常復(fù)雜時,才考慮使用此權(quán)限模型。

六、基于RBAC的延展——用戶組

解析:

基于RBAC模型,還可以適當(dāng)延展,使其更適合我們的產(chǎn)品。譬如增加用戶組概念,直接給用戶組分配角色,再把用戶加入用戶組。這樣用戶除了擁有自身的權(quán)限外,還擁有了所屬用戶組的所有權(quán)限。

6

舉例:

譬如,我們可以把一個部門看成一個用戶組,如銷售部,財(cái)務(wù)部,再給這個部門直接賦予角色,使部門擁有部門權(quán)限,這樣這個部門的所有用戶都有了部門權(quán)限。用戶組概念可以更方便的給群體用戶授權(quán),且不影響用戶本來就擁有的角色權(quán)限。

七、最后的話

無論是本次的權(quán)限模型,還是其他產(chǎn)品相關(guān)實(shí)現(xiàn)方案,很多都已經(jīng)被前人所總結(jié)提煉,我們應(yīng)深度掌握這些成熟的知識和經(jīng)驗(yàn),而不是絞盡腦汁自我推理。還是文章開頭那句話,站在巨人的肩膀上我們可以看得更遠(yuǎn),而不是再造一個輪子。

 

作者:Monster,小滿科技產(chǎn)品經(jīng)理,公眾號:PM怪物Monster

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

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 用戶組的舉例,建議改成銷售組織(或者省級業(yè)務(wù)中心)

    來自浙江 回復(fù)
  2. 之前所在的產(chǎn)品項(xiàng)目也是b端,有很多類似模塊感覺應(yīng)該是有經(jīng)驗(yàn)積累下來的輪子的,但是又不知道去哪找,求教 ??

    來自廣東 回復(fù)
    1. 我已經(jīng)很久沒找輪子了。。一般是百度搜一下。。

      來自浙江 回復(fù)
  3. 學(xué)到了!!多了解輪子真的蠻重要的,請問作者平時是通過哪些渠道來了解到產(chǎn)品設(shè)計(jì)中的輪子的呢?

    來自廣東 回復(fù)
  4. 大神,想請教一下關(guān)于集團(tuán)性公司部門組織架構(gòu)建立,一個集團(tuán)下包含總分子公司,如果總公司有一個體系,這個體系下既有總公司的部門a,又有分公司的部門b,在創(chuàng)建組織架構(gòu)的時候,分公司那個部門b應(yīng)該創(chuàng)建在分公司的架構(gòu)下嗎?
    我考慮了這兩種情況:
    1.如果這個b部門創(chuàng)建在總公司下,可能從業(yè)務(wù)上來講,負(fù)責(zé)這個體系的領(lǐng)導(dǎo)查看整個體系的數(shù)據(jù)沒有問題,但是從職能上來講,分公司財(cái)務(wù)需要能看到這個b部門的數(shù)據(jù),但是架構(gòu)設(shè)置在總部
    2.如果b部門創(chuàng)建在分公司架構(gòu)下,那負(fù)責(zé)這個體系的領(lǐng)導(dǎo)還要單獨(dú)給他這只b部門的權(quán)限

    如果有其他大神有解,歡迎探討

    來自上海 回復(fù)
    1. 不是大神,產(chǎn)品小白,根據(jù)你說的內(nèi)容,個人認(rèn)為一般情況是第二種情況符合;特殊情況為集團(tuán)直屬控制部門,例如總公司財(cái)務(wù)部門要特殊處理,培訓(xùn)部門特殊處理;

      來自北京 回復(fù)
  5. 基于RBAC的延展——用戶組.我們可以把一個部門看成一個用戶組,如銷售部,財(cái)務(wù)部,再給這個部門直接賦予角色,使部門擁有部門權(quán)限,這樣這個部門的所有用戶都有了部門權(quán)限。這個部門銷售部、財(cái)務(wù)部所有人的權(quán)限都是一樣的嗎?

    來自廣東 回復(fù)
    1. 是的,先可以有簡單的、共有的部門權(quán)限,然后部門職員還可以有自己崗位特殊的角色權(quán)限。

      來自廣東 回復(fù)
  6. 這個讓我想到一個案例: 一個平臺里面要管理多個店的管理員和類目商品管理,類目商品有多個以上的上級進(jìn)行匯報工作(例如洗滌用品的要管理多個店的洗滌區(qū)域,飲料類的要管理多個店的飲料區(qū)域),同時要和單店管理員 和公司商品經(jīng)理雙線匯報公司,這樣的的賬號,角色,權(quán)限就用這個模型對應(yīng)關(guān)聯(lián)起來;

    來自廣東 回復(fù)
  7. 會員體系的搭建是不是也可以用這個模型?

    來自廣東 回復(fù)
    1. 會員體系好像不是后臺系統(tǒng)的范疇

      來自江蘇 回復(fù)
  8. 對于RBAC1,角色的等級不是確定的,需要用戶自己去配置等級權(quán)限,這種該怎么設(shè)計(jì)呢

    來自廣東 回復(fù)
  9. 大神,我們的系統(tǒng)終于實(shí)現(xiàn)了這個巨人的理論了 ?

    來自廣東 回復(fù)
    1. 恭喜你,理論是一回事,落地又是一回事,你能推動落地非常棒!

      來自浙江 回復(fù)
  10. 我的文章真是棒棒的鴨鴨鴨!?。。。。。。。。。。。。。?/p>

    來自浙江 回復(fù)
    1. 每看一字都收益良多,佩服大神,到這里瞬間出戲 ?

      來自北京 回復(fù)
    2. 哈哈哈哈哈哈哈哈哈哈哈哈

      來自浙江 回復(fù)
    3. 確實(shí)很棒,受益匪淺

      來自廣東 回復(fù)
  11. 關(guān)于權(quán)限的分配感謝指教,但是我還想請問你數(shù)據(jù)權(quán)限和功能權(quán)限如何區(qū)分?在配置功能權(quán)限時,有粗有細(xì),大到功能模塊,小到每一個頁面的小按鈕,那這種分法都在什么場景下使用呢?關(guān)于數(shù)據(jù)權(quán)限我現(xiàn)在還是沒有想清楚怎么設(shè)計(jì),麻煩大神指點(diǎn)一下

    來自浙江 回復(fù)
    1. 1、數(shù)據(jù)權(quán)限和功能權(quán)限分開配置;
      2、場景太多了,按照你實(shí)際需求來;
      3、數(shù)據(jù)權(quán)限類似,你和你老板都能使用組織架構(gòu)功能,但是你只看到你團(tuán)隊(duì)的人,你老板看到全公司的人。組織架構(gòu)算一個功能,需要賦予你和你老板,看到哪些人算數(shù)據(jù)權(quán)限,你看到的和你老板看到的范圍就不一樣了,也是需要設(shè)置的。

      來自浙江 回復(fù)
    2. 作者您好,就你所說的組織架構(gòu)算一個功能,需要賦予你和你老板,看到哪些人算數(shù)據(jù)權(quán)限,你看到的和你老板看到的范圍就不一樣了,也是需要設(shè)置的。怎么設(shè)置呢?可以具體在舉例說明嗎?目前我也遇到數(shù)據(jù)范圍權(quán)限的設(shè)置,還是不特別清楚。麻煩指點(diǎn)一下哦。非常感謝

      來自北京 回復(fù)
    3. 在你數(shù)據(jù)本身做文章。例如你是銷售部經(jīng)理,老板是總經(jīng)理。那么員工本身有歸屬于某個部門,此時數(shù)據(jù)權(quán)限可分為,1.你看到的是部門時銷售部的所有員工。2.老板看到的是所有部門的員工。這樣數(shù)據(jù)權(quán)限不就區(qū)分開了嗎

      來自福建 回復(fù)
    4. 是要把所有的人都要分組展示,然后做成可勾選嗎?

      來自北京 回復(fù)
    5. 比如,看到:我的訂單,我所在部門下的訂單,我所在部門及下級部門的訂單,全部訂單。。等等。

      來自浙江 回復(fù)
    6. 需要把職員分部門分負(fù)責(zé)人這樣去設(shè)計(jì),才能夠進(jìn)行數(shù)據(jù)的區(qū)分(區(qū)分的前提是用戶跟數(shù)據(jù)本身是有關(guān)聯(lián)的)

      來自廣東 回復(fù)
  12. 站在巨人的肩膀上我們可以看得更遠(yuǎn)……同意。

    來自山東 回復(fù)
    1. 三克油~

      來自浙江 回復(fù)
  13. 你好,受教了,但個人對于“用戶組”和“角色”之間的關(guān)系和應(yīng)用場景還是有點(diǎn)模糊,盼舉例指點(diǎn)一二,感激!

    來自上海 回復(fù)
    1. 臨時組建一個項(xiàng)目部,給項(xiàng)目部分配權(quán)限,但是每個人在自己原先的崗位上還有角色和崗位

      來自浙江 回復(fù)
    2. 舉個例子,現(xiàn)在為公司的500名客服部門員工設(shè)置權(quán)限,這些員工的角色都屬于“客服”,我如果每一個客服都去設(shè)置一下,為什么不創(chuàng)建一個客服組,給這個組匹配“客服”這個角色,之后就是往里面添加員工即可,效率是不是提高了;這還是只是一個角色的情況下,如果公司有一批相同崗位的員工都具有N種相同的角色,此時會不會覺得角色組更好用呢?

      來自浙江 回復(fù)
    3. 這個時候不是用部門麼,
      還有就是用組的話,要報超級的用戶添加到組里也是一件不少的工作量呵,對吧?

      來自上海 回復(fù)
  14. 請問一般來說,一個用戶會歸屬于多個用戶組嗎?

    來自江蘇 回復(fù)
    1. 可以歸屬多個用戶組

      來自廣東 回復(fù)
  15. 用戶權(quán)限有RBAC……,有什么其他比較成熟的業(yè)務(wù)模式么?

    來自浙江 回復(fù)
  16. 棒棒棒!!!
    求教RBAC3模型???

    來自北京 回復(fù)
    1. 不教鴨!

      來自浙江 回復(fù)
  17. 非常棒,講得深入淺出條理清晰。

    來自浙江 回復(fù)
    1. 謝謝哈~

      來自浙江 回復(fù)
  18. 目前只用到了RBAC0,保持最大的靈活度,沒想到B端產(chǎn)品有這么多專業(yè)名詞,感謝分享

    來自浙江 回復(fù)
  19. 感謝分享,非常受用

    來自北京 回復(fù)
  20. 大多時候做的都是后臺型產(chǎn)品,感覺有些隔閡,終于!發(fā)現(xiàn)了新世界的大門 :mrgreen:

    來自江蘇 回復(fù)
    1. 謝謝哈,加油

      來自廣東 回復(fù)
  21. 又重新看了一篇,看懂了但是實(shí)際使用時怎么用呢?

    來自上海 回復(fù)
    1. 我舉了例子哈,也不是很清楚你具體場景,但是你可以理解邏輯后,自己針對具體業(yè)務(wù)梳理哈

      來自廣東 回復(fù)
    2. RBAC1模型角色分等級,角色不同等級看成不同角色,是不是與RBAC0相同了,在實(shí)際使用中,與RBAC0有什么具體區(qū)別?

      來自上海 回復(fù)
  22. 感謝分享~

    來自天津 回復(fù)
    1. 不客氣哈

      來自廣東 回復(fù)
  23. 看了幾遍后終于看懂了,產(chǎn)品之路還得好好修煉 小白 ??

    來自上海 回復(fù)
    1. 嗯嗯,加油

      來自廣東 回復(fù)
  24. 感謝分享~

    來自上海 回復(fù)
    1. 不客氣~

      來自廣東 回復(fù)
  25. 干貨!正好對我現(xiàn)在遇到的問題很有幫助,感謝!

    來自天津 回復(fù)
    1. 不客氣哈,加油

      來自廣東 回復(fù)
  26. 用戶組的概念從操作層面可以理解為用戶的集合,從背后權(quán)限分配的層面可以理解為對于一組用戶固定分配的一個角色,不知道可否這樣去理解

    來自四川 回復(fù)
    1. 可以這樣理解,棒棒噠

      來自廣東 回復(fù)
    2. 那是不是相當(dāng)于組里面的人有兩個角色?只是不互斥?

      來自廣東 回復(fù)
  27. 最后的用戶組,通常情況下是不是可以等同于通訊錄的部門。因?yàn)榇蠖鄶?shù)情況下,每個部門是有獨(dú)特的權(quán)限的,比如市場部可以看報表,財(cái)務(wù)部可以看報銷,人事部可以看請假…

    來自廣東 回復(fù)
    1. 你提到的這種場景可以用用戶組滿足哈,一般情況下的確可能按部門來設(shè)置用戶組,然后給部門授權(quán)~棒棒噠

      來自廣東 回復(fù)
  28. 說的好

    來自北京 回復(fù)
    1. 謝謝哈

      來自廣東 回復(fù)
  29. 如果一個用戶組下面又分組長和組員,
    q1:組長和組員的權(quán)限是不同的要怎么分
    q2:組長可以創(chuàng)建組員(用戶管理),但給組員分配權(quán)限既不能高于他自己,又和他自己有區(qū)別,這個時候就矛盾了,怎么細(xì)分

    來自浙江 回復(fù)
    1. 這里創(chuàng)建用戶組的目的只是為了方便群體授權(quán)(該部門所有人都有的權(quán)限),權(quán)限并不能包含用戶管理。而你說的分等級應(yīng)該在角色劃分時確定

      來自浙江 回復(fù)
  30. 站在巨人的肩膀上我們可以看得更遠(yuǎn),而不是再造一個輪子

    來自湖南 回復(fù)
    1. 對!對!對!

      來自廣東 回復(fù)