談一談B端的功能權(quán)限設(shè)計(jì)
如果你做過企業(yè)端或者后臺(tái)產(chǎn)品,你對權(quán)限設(shè)計(jì)應(yīng)該不會(huì)陌生。權(quán)限設(shè)計(jì)是所有企業(yè)系統(tǒng)的基礎(chǔ), 企業(yè)系統(tǒng)中所有的功能模塊都需要考慮到權(quán)限的控制。
B端產(chǎn)品經(jīng)理不可避免會(huì)遇到權(quán)限設(shè)計(jì)的相關(guān)問題,“權(quán)限管理”是B端產(chǎn)品的基礎(chǔ)功能,行業(yè)里已經(jīng)很成熟,雖然它不是核心業(yè)務(wù)功能,但卻牽一發(fā)而動(dòng)全身,需要產(chǎn)品經(jīng)理根據(jù)具體業(yè)務(wù)使用場景來設(shè)計(jì)。
我們所說的“權(quán)限”,包括“功能權(quán)限”和“數(shù)據(jù)權(quán)限”,“功能權(quán)限”指用戶登錄系統(tǒng)后能看到哪些模塊,操作哪些按鈕
比如常見的CRM系統(tǒng),銷售人員和財(cái)務(wù)人員由于處理的業(yè)務(wù)不同,登錄系統(tǒng)后,看到的功能模塊也不盡相同;同樣都是財(cái)務(wù)人員,職位大小不同,擁有的操作功能也可能不同。
比如“刪除”的操作,不會(huì)隨意提供給一個(gè)普通員工。而數(shù)據(jù)權(quán)限指的是用戶在某個(gè)模塊里能看到哪些范圍的數(shù)據(jù),比如華南的銷售總監(jiān)可以看到華南地區(qū)的銷售數(shù)據(jù),而華北的銷售總監(jiān)只能看到華北地區(qū)的銷售數(shù)據(jù)。
本篇我們主要談一下功能權(quán)限設(shè)計(jì)方面的問題,關(guān)于數(shù)據(jù)權(quán)限,我們下一篇再見。
功能權(quán)限主要有以下3種設(shè)計(jì)方式
1. 自主訪問控制(DAC:Discretionary Access Control)
自主訪問控制是由《可信計(jì)算機(jī)系統(tǒng)評估準(zhǔn)則》所定義的訪問控制中的一種類型。
被操作對象,根據(jù)訪問控制規(guī)則,來判斷操作主體可對操作對象做哪些操作,比如只讀或者是可寫的權(quán)限。
Windows中的系統(tǒng)權(quán)限設(shè)計(jì)是典型的DAC應(yīng)用,擁有訪問權(quán)限的用戶,可以直接將訪問權(quán)限賦予其他成員,比如管理員有計(jì)算機(jī)的完全訪問權(quán),標(biāo)準(zhǔn)用戶可以使用系統(tǒng)內(nèi)的大多數(shù)軟件。
在windows系統(tǒng)中,通過高級用戶賬戶設(shè)置,賦予成員不同的系統(tǒng)操作權(quán)限,從而達(dá)到控制成員操作權(quán)限的目的。
2. 強(qiáng)制訪問控制(MAC:Mandatory Access Control)
被操作對象及用戶兩方均有各自的權(quán)限標(biāo)識(shí),用戶能否對對象進(jìn)行操作,取決于權(quán)限標(biāo)識(shí)的對照關(guān)系。
MAC一般會(huì)給用戶和資源分級。
比如,用戶級別分為:初級 、高級;文件級別分為:公開、絕密,系統(tǒng)管理員會(huì)制定訪問策略,如初級用戶僅可以訪問公開文件,高級用戶可以訪問全部文件。
從而達(dá)到不同標(biāo)識(shí)的用戶,訪問不同標(biāo)識(shí)的操作對象。
3. 基于角色的訪問控制(RBAC:Role-Based Access Control)
其基本思想是,對系統(tǒng)操作的各種權(quán)限不是直接授予具體的用戶,而是在用戶集合與權(quán)限集合之間建立一個(gè)角色集合。每一種角色對應(yīng)一組相應(yīng)的權(quán)限。
一旦用戶被分配了適當(dāng)?shù)慕巧螅撚脩艟蛽碛写私巧乃胁僮鳈?quán)限。
這樣做的好處是,不必在每次創(chuàng)建用戶時(shí)都進(jìn)行分配權(quán)限的操作,只要分配用戶相應(yīng)的角色即可,而且角色的權(quán)限變更比用戶的權(quán)限變更要少得多,這樣將簡化用戶的權(quán)限管理,減少系統(tǒng)的開銷。
RBAC0,基礎(chǔ)模型:用戶與角色是多對多的關(guān)系。一個(gè)用戶可以擁有若干角色,一個(gè)角色也可以賦予若干用戶。
企業(yè)的后臺(tái)管理系統(tǒng),通常包含多種管理模塊,有面向供應(yīng)商的管理,面向財(cái)務(wù)的管理,面向日常運(yùn)營的管理,為了避免內(nèi)部信息的交叉?zhèn)鞑?,以及操作人員可能存在的誤操作行為,我們就可以通過RBAC0模型,為后臺(tái)的操作者設(shè)置多種角色,并為每個(gè)角色賦予不同的業(yè)務(wù)權(quán)限。
這樣就可以讓銷售同事只能查閱和修改供應(yīng)商管理模塊,無法查閱公司的財(cái)務(wù)信息,而財(cái)務(wù)同事也只能查閱和修改財(cái)務(wù)報(bào)表相關(guān)的管理模塊,無法干預(yù)公司的日常運(yùn)營,運(yùn)營同事則只被授予面向產(chǎn)品的運(yùn)營管理能力,不同崗位各司其職,互不干擾。
當(dāng)一個(gè)人既負(fù)責(zé)銷售部,又負(fù)責(zé)運(yùn)營部時(shí),就可以為其賦予銷售人員、運(yùn)營人員兩個(gè)角色,這樣他就擁有這兩個(gè)角色的所有權(quán)限。
RBAC1,用戶分級模型:相比RBAC0,需要設(shè)計(jì)角色間層級關(guān)系和角色間繼承關(guān)系。
公司規(guī)模越大,對每個(gè)崗位的權(quán)責(zé)要求也更為細(xì)致。我們可以通過RBAC1模型,為用戶提供角色間的繼承關(guān)系。
如銷售角色,可以分為銷售主管和普通銷售2個(gè)級別,普通銷售默認(rèn)繼承銷售主管的權(quán)限,并支持在銷售主管級別的基礎(chǔ)上,刪減普通銷售的權(quán)限。
這樣,通過角色分級,可以控制不同級別權(quán)責(zé)的差異化,避免出現(xiàn)下級比上級權(quán)限大的情況。
RBAC2,角色限制模型:用戶和角色為多對多的關(guān)系,如果采用責(zé)任分離模型,則需要定義角色和角色間的互斥關(guān)系,也就是約束規(guī)則。
有些公司對于“責(zé)任分離”比較重視,如合同的錄入與審核不能為同一個(gè)人,銷售人員來做合同錄入,財(cái)務(wù)人員來做合同審核,那么一個(gè)合同管理模塊,如何做到責(zé)任分離呢?RBAC2模型,通過角色互斥可以實(shí)現(xiàn)。
給一個(gè)員工分配了銷售人員角色時(shí),就不能再分配財(cái)務(wù)人員的角色,保證一個(gè)員工不會(huì)既有銷售人員,又有財(cái)務(wù)人員的角色,約束工作職責(zé)。
RBAC3,統(tǒng)一模型:包括了繼承和分離兩種情況的更為復(fù)雜的模型,即既要定義角色間的繼承關(guān)系,也要維護(hù)好角色間的責(zé)任分離關(guān)系。
RBAC3=RBAC1+RBAC2,可以解決上述3個(gè)問題,既能實(shí)現(xiàn)角色的分級與繼承關(guān)系,避免出現(xiàn)下級比上級權(quán)限大的情況,又可以定義角色間的互斥關(guān)系,保證一個(gè)員工不會(huì)同時(shí)操作互斥的功能。
關(guān)于功能權(quán)限設(shè)計(jì)的幾點(diǎn)Tips
- 如果項(xiàng)目初期不需要權(quán)限管理,一定記得提醒開發(fā)同學(xué),預(yù)留相關(guān)接口。
- 功能權(quán)限設(shè)計(jì),也包括頁面權(quán)限和接口權(quán)限,這一點(diǎn)沒有經(jīng)驗(yàn)的產(chǎn)品同學(xué)可能注意不到,需要保證沒有該模塊功能權(quán)限的用戶直接輸入頁面地址或調(diào)用接口時(shí),也無法訪問。
- 一個(gè)頁面完成一件事,避免頁面交互方式太復(fù)雜,無法劃分功能權(quán)限。
本文由 @菡子同學(xué) 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議。
方便加微信跟您咨詢下嗎?剛好在做這塊
很贊,正在調(diào)研企業(yè)管理的功能設(shè)計(jì),有推薦的學(xué)習(xí)路徑嗎,謝謝
可以多看一些crm
沙發(fā)???
?