CRM 05:基于RBAC理論的權(quán)限設(shè)計
編輯導(dǎo)讀:權(quán)限設(shè)計對于大多數(shù)產(chǎn)品經(jīng)理來說都不陌生,本篇文章討論一個系統(tǒng)的權(quán)限設(shè)計有哪些機制,并重點介紹RBAC的機制,一起來看看吧。
在前文「CRM02-銷售域系統(tǒng)設(shè)計與實施中,講解到了權(quán)限的劃分」,本篇文章討論一個系統(tǒng)的權(quán)限設(shè)計有哪些機制,并重點介紹RBAC的機制。
一、基本邏輯
首先我來拆解下訪問的邏輯,一次完整的訪問,有如下組成:
- 用戶:發(fā)起訪問的主體(這個用戶還可以是用戶組的概念,即一組用戶,對應(yīng)了組織機構(gòu))
- 權(quán)限:被訪問的客體
- 對象:記錄用戶是否可以訪問某個對象。其實還能拆出給權(quán)限控制表的,為了好理解就簡化了
基于這個邏輯,訪問過程可以有不同的機制來控制。
二、訪問機制
當前市面上流傳比較廣的權(quán)限控制機制,如下3種:
- ABAC:基于屬性的訪問控制(Attribute Based Access Control)
- RBAC:基于角色的訪問控制(Role Based Access Control)
- PBAC:基于策略的訪問控制(Policy Based Access Control)
一瞬間甩出3個訪問控制機制,會讓人找不到抓手,我先從我的角度來介紹下,如果有說錯的歡迎老司機來斧正。
首先,這3個機制沒有好與壞,只有是否合適,每個機制下的擁護者都會說自己的機制代表了未來。
1. ABAC
是基于用戶上的某個屬性來控制訪問的,比如基于年齡屬性限制,某用戶18歲以下,就不能訪問某些頁面,這種就是ABAC。
優(yōu)點:集中化管理,一刀切
缺點:如果權(quán)限需求靈活多變,配置會死人,也無法看到某個用戶能否訪問具體某個對象
2. RBAC
基于角色的權(quán)限控制,增加了一層角色的抽象,這也是在設(shè)計CRM結(jié)構(gòu)中介紹的方法《引用第二篇文章》。通過不同的頁面授權(quán),把不同對象的權(quán)限集合成角色,達到靈活的配置。
優(yōu)點:用戶和對象的關(guān)系可直觀追溯,調(diào)整與配置很靈活。
缺點:如果公司業(yè)務(wù)規(guī)模較大,角色分工出現(xiàn)模糊,比如一個人有記賬的角色又有了監(jiān)管的角色,這種分工是極不合理的。按照這個層級模型,理論上對象越多,能排列出的權(quán)限組合越多,角色就越多。這種現(xiàn)象叫做
角色爆炸。基于角色爆炸,又引出了后面的PBAC。
3. PBAC
如果一個大的系統(tǒng)會有很多關(guān)聯(lián)子系統(tǒng),子系統(tǒng)中又有不同的權(quán)限配置,等級也不同,菜單也不同。
這個場景就更適合PBAC,基于策略的角色控制,這個機制下的配置邏輯,就是“按照原則去設(shè)計一條權(quán)限限制”,這個原則就組成了策略,如只要是某個部門的人都不需要打卡。舉例:當“部門屬性”=“運維組”,訪問頁面包含“系統(tǒng)配置”這類。
優(yōu)點:PBAC 支持環(huán)境和上下文控制,因此可以設(shè)置策略以在特定時間和特定位置授予對資源的訪問權(quán)限,甚至評估身份和資源之間的關(guān)系。策略可以快速調(diào)整,并在給定的時間段內(nèi)設(shè)置(例如響應(yīng)違規(guī)或其他緊急情況)。可以輕松添加、刪除或修改用戶組,單擊即可撤銷過時的權(quán)限。
缺點:配置的操作難度,不適用于一般的商業(yè)公司,對配置人員操作要求較高。
三、RBAC核心設(shè)計
介紹完不同的機制,我重點說下RBAC。
RBAC認為權(quán)限的過程可以抽象概括為:判斷【W(wǎng)ho是否可以對What進行How的訪問操作(Operator)】這個邏輯表達式的值是否為True的求解過程。
即將權(quán)限問題轉(zhuǎn)換為Who、What、How的問題。who、what、how構(gòu)成了訪問權(quán)限三元組。
RBAC支持公認的安全原則:最小特權(quán)原則、責任分離原則和數(shù)據(jù)抽象原則。
- 最小特權(quán)原則:某用戶對應(yīng)的角色的權(quán)限只要不超過該用戶完成其任務(wù)的需要就可以了。
- 責任分離原則:是指完成敏感任務(wù)過程中需要分配兩個責任上互相約束的兩個角色來實現(xiàn),例如在清查賬目時,只需要設(shè)置財務(wù)管理員和會計兩個角色參加就可以了。
- 數(shù)據(jù)抽象:如在賬目管理活動中,可以使用信用、借方等抽象許可權(quán),而不是使用操作系統(tǒng)提供的讀、寫、執(zhí)行等具體的許可權(quán)。
使用RBAC的機制,優(yōu)點對于業(yè)務(wù)環(huán)境來講就是很清晰,可以快速通過角色來識別角色包含的頁面,而且多個角色可以疊加取并集,讓配置的人操作量減少。
至于角色爆炸的問題,在CRM實施之初就提前規(guī)劃好,并約定好原則,這個問題就可以大概率避免。當然不排除后人破掉了這個限制,導(dǎo)致套娃
RBAC的核心設(shè)計如下綠圖:
【圖片來自于Apache Directory】
用戶和角色還有會話相互關(guān)聯(lián)(會話的作用可理解為每次訪問都要檢查用戶和角色的關(guān)系,如果角色沖突,就中斷會話)
角色單獨和權(quán)限管理,是權(quán)限的集合。權(quán)限內(nèi)部又包含了對象和操作。(如果不理解對象和操作,可查看之前的UML文章)
RBAC體系的邏輯可以大體這么理解:
RBAC0:RBAC96家族的核心部分,后面的123都是基于此發(fā)展
RBAC1?:在0的基礎(chǔ)上,增加角色分層和角色繼承的關(guān)系?。如區(qū)域經(jīng)理下方有門店店長這種關(guān)系
RBAC2:在0基礎(chǔ)上增加了角色約束,包含:
- 角色互斥約束,系統(tǒng)的運行中互斥角色只能生效一個,如Boss直聘里的牛人和BOSS,切換以后需要重新登錄
- 角色基數(shù)約束,限制某個用戶最多的角色數(shù)量/權(quán)限數(shù)量,防止濫用
- 先決條件角色約束,指某用戶只有在已經(jīng)擁有某個角色的前提下,才能分配到特定的其他角色,如想擁有線索放棄的權(quán)限,就必須擁有銷售角色的權(quán)限
RBAC3:
融合了RBAC1和RBAC2的所有特點,把角色關(guān)系和角色約束都整合到了一塊,在我們的業(yè)務(wù)環(huán)境中沒必要這么復(fù)雜,所以就用了RBAC0。
基于RBAC0的這種機制,落地到業(yè)務(wù)中,整體的權(quán)限配置效果如下:
- 一個用戶,可以批量關(guān)聯(lián)多個角色。一個角色可以批量授權(quán)給多個用戶
- 一個角色可以配置不同的頁面權(quán)限與操作權(quán)限(操作在我們設(shè)計的時候也抽象成了頁面,更簡單)
- 數(shù)據(jù)權(quán)限與組織樹權(quán)限的顆粒度精細到具體的用戶,只可單獨授權(quán)。同時數(shù)據(jù)的行權(quán)限和列權(quán)限不必單獨授權(quán),保留了能力
基于RBAC的權(quán)限設(shè)計就講到這里,希望在大家設(shè)計系統(tǒng)的時候有所幫助,如果在設(shè)計過程中卡在了頁面設(shè)計上,把上述的每個圓圈的內(nèi)容分別設(shè)計個列表和詳情頁,就有思路了,如圖。
角色管理:
角色詳情:
用戶管理:
用戶詳情:
本文核心理論部分來自于互聯(lián)網(wǎng),頁面截圖來自于過往脫敏經(jīng)歷。
參考資料
RBAC https://csrc.nist.gov/projects/role-based-access-control
PBAC VS RBAC https://blog.plainid.com/why-role-based-access-control-is-not-enough
PBAC VS ABAC https://blog.plainid.com/the-advantage-of-pbac-over-the-traditional-abac
RBAC核心設(shè)計 http://directory.apache.org/fortress/user-guide/1.3-what-rbac-is.html
感謝大家的閱讀!CRM系統(tǒng)設(shè)計的相關(guān)內(nèi)容到這里基本講完了,后面我會繼續(xù)出CRM外圍系統(tǒng)的相關(guān)內(nèi)容,歡迎大家追更~~
我這幾篇文章經(jīng)常提到UML,也是給大家實操了一遍,建議大家練習和使用。祝大家在產(chǎn)品的道路上找到自己喜歡的事情。
作者:羅文正雄;公眾號:羅文正雄
本文由 @羅文正雄 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自 Pexels,基于 CC0 協(xié)議
把數(shù)據(jù)權(quán)限是不是也可以掛到角色上? 另外,您是怎么設(shè)計字段權(quán)限控制的
崗位,地區(qū),部門等都可以掛載角色。只要你想