權限設計=功能權限+數據權限
很多企業管理的中使用的軟件,基本上都離不開“權限管理”。有的朋友對權限管理理解的很透徹,有些朋友對一些概念模糊不清。這里總結了一些常見的誤區,可供大家參考。
1. “普通用戶有刪除功能嗎”
權限實際上是功能權限和數據權限的組合,像“刪除”操作是一個功能操作權限,需要把“刪除”賦予給某個用戶,該用戶才能有這個操作權限。如這樣一個場景:企業IT管理員為系統定義角色,給用戶分配角色。
給新員工陳穎賦予“業務經理”角色,“業務經理”具有“新增客戶單位”、“查詢客戶單位”、“修改客戶單位”權限。此時張穎能夠進入系統,則可以進行這些操作。
2. “普通用戶能查看訂單數據嗎”
以上舉例,局限于功能訪問權限,還有一些數據權限的權限管理,如:陳穎是浙江區域的“業務經理”,所以她只能夠查看本區域的客戶單位,而不能查看到其它地區的客戶單位。甚至考慮到業務經理之間的競爭,系統可以控制更細粒度級別的數據權限,即普通業務經理的角色只能看到自己維護的客戶單位,而不能查看其他人員的客戶單位。軟件系統的權限管理其實是與線下實際管理策略相對應的。
有些企業本身制定和實施了嚴格的規章制度,那么軟件系統的權限管理就可以幫助企業更好的貫徹制度的實行,提高整體的運行效率和數據的安全。相反有些企業實際線下沒有明確的經營策略,存在著管理風險和員工之間的不正當競爭,寄希望于軟件系統的權限規范,但是實施過程中會有很多阻力。
3. “這不就是用戶管理系統嗎”
這是將用戶管理系統當做權限管理系統,其實權限基本都是基于角色的,用戶分配了對應的角色后,則會擁有對應的權限。而用戶管理系統,只是將用戶管理起來。
從控制力度來看,可以將權限管理分為兩大類:
- 功能級權限管理;
- 數據級權限管理。
從控制方向來看,也可以將權限管理分為兩大類:
- 從系統獲取數據,比如查詢訂單、查詢客戶資料;
- 向系統提交數據,比如刪除訂單、修改客戶資料。
“權限管理”是B端產品的基礎功能,B端產品經理不可避免會遇到權限設計的相關問題,行業里已經很成熟。雖然它不是核心業務功能,但卻牽一發而動全身,需要產品經理根據具體業務使用場景來設計。
通常情況下我們所說的“權限”,包括“功能權限”和“數據權限”,“功能權限”指用戶登錄系統后能看到哪些模塊,操作哪些按鈕,企業中的由于用戶擁有不同的角色,分工職責不盡相同。
比如常見的CRM系統,銷售人員和財務人員由于處理的業務不同,登錄系統后,看到的功能模塊也不盡相同;而同樣都是財務人員,因為職位等級不同,擁有的操作功能也可能不同。
尤其是針對刪除或者撤銷的功能權限的控制。比如“刪除”的操作,不會隨意提供給一個普通員工。而數據權限指的是用戶在某個模塊里能看到哪些范圍的數據,比如A業務經理只能看到自己的客戶數據,但是A的業務總監可以查看到各個區域業務員的客戶數據,
4. 功能權限中按角色訪問控制設計
其基本思想是,對系統操作的各種權限不是直接授予具體的用戶,而是在用戶集合與權限集合之間建立一個角色集合,每一種角色對應一組相應的權限。
一旦用戶被分配了適當的角色后,該用戶就擁有此角色的所有操作權限。
這樣做的好處是,不必在每次創建用戶時都進行分配權限的操作,只要分配用戶相應的角色即可。而且角色的權限變更比用戶的權限變更要少得多,這樣將簡化用戶的權限管理,減少系統的開銷。一般情況下的角色權限時相對穩定的,而用戶則因為時間的變化而需要獲取相關新的權限。
基礎模型:用戶與角色是多對多的關系。一個用戶可以擁有若干角色,一個角色也可以賦予若干用戶。但并不意味著角色之間的關系互斥與否。
在企業的后臺管理系統中,通常包含多種管理模塊,有針對供應商的模塊、客戶的模塊、財務人員的模塊、統計管理人員的模塊。為了避免內部信息的交叉傳播,以及操作人員可能存在的誤操作行為,我們就可以通過此種基于角色的訪問控制模型,為后臺的操作者設置多種角色,并為每個角色賦予不同的業務權限,精確到對應菜單模塊的控制,甚至是相應的按鈕權限。
這樣就可以讓銷售同事只能查閱和修改供應商管理模塊,無法查閱公司的財務信息。而財務同事也只能查閱和修改財務報表相關的管理模塊,無法查看公司的訂單匯總,不同崗位各司其職,互不干擾。
對于小型的企業,當一個人既負責銷售部,又負責運營部時,就可以為其賦予銷售人員、運營人員兩個角色,這樣他就擁有這兩個角色的所有權限,即可以訪問這兩個模塊的內容。但是公司規模越大,對每個崗位的權責要求也更為細致,角色之間可能會有相應的組合關系。有必要理清楚崗位,職務,職位,權限,角色。
毫無疑問:權限是這些概念中的最細粒度的一個東西,而角色是一組權限的集合。崗位是職位的同義詞,他們的側重點不同。
職務才是被大家忽略的一個概念:具體定義不是很清晰,但他是某一業務中某一角色應當承擔的責任或者說應該負責的事。
一個職位一般來說有多個職務,比如說我們的經理助理這么一個“職位”可能要負責的事情可能有很多類,如:協助安排經理的日程,對下面呈上來的某類報告做初步審理等等一條條。這些被我們認為梳理出來的一條條的東西就是職務 – 他在當前職位上需要擔負的義務。
大家初期容易將崗位抽象成一個角色,但是最終發現這個角色可能粒度太粗或者是不宜重用,這個時候就應該梳理一下每個職位的職務,以職務為單位抽象成角色,這樣才能制定出更細粒的角色。
當然職位由于他是我們看的見摸得著的,所以直接將職位映射成角色是非常簡單清晰沒有異議的,而職務就不同了,他需要產品人員深入理解客戶的業務,這樣才能根據客戶的業務情況梳理出一個業務職務體系,這個過程必然會很辛苦。
5. 關于功能權限設計的幾點Tips
- 如果項目初期不需要權限管理,一定記得提醒開發同學,預留相關接口。
- 功能權限設計,也包括頁面權限和接口權限,這一點沒有經驗的產品同學可能注意不到,需要保證沒有該模塊功能權限的用戶直接輸入頁面地址或調用接口時,也無法訪問。
- 一個頁面完成一件事,避免頁面交互方式太復雜,無法劃分功能權限。
- 功能權限與數據權限有時可以通過模塊進行轉換。
本文由@山人小道 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash,基于CC0協議
最重點的數據權限劃分,如何應用好職位、職務、和角色字段沒說??
舉個例子說明功能權限和數據權限的區別:
1. 功能權限:A和B都是銷售主管,所以他們的功能權限完全一樣,例如都可以訪問CRM系統,錄入線索,簽約客戶,并查看客戶的訂單;
2. 數據權限:A和B都是銷售主管,但A屬于華東區,B屬于華北區,所以其雖然功能權限一樣,但數據權限不一樣,A只能查看華東區的數據,B只能查看華北區的數據。
功能權限是一個系統橫向功能上的訪問控制,使用RBAC模型即可;數據權限是一個系統縱向同類業務數據的訪問控制,需要同時關注組織架構&RBAC。
請問下數據權限怎么做的呀?
數據權限需要結合功能權限以及組織架構,例如A銷售擁有“銷售”這個角色的所有權限,但數據權限上,A只能查看屬于自己客戶的數據,無法看到其他銷售的數據。B銷售擁有“銷售主管”的角色,他的功能權限和A基本是一樣的,但數據權限上,他可以看到本部門下所有銷售的數據。當然,B無法看到其他銷售部門的數據。
功能權限的設計相對簡單,RBAC模型就可以概括,但數據權限的設計好像沒有太多人關注,但工作中又必不可少
是的
(@_@;)
有個問題想請教下
一個關于RBAC模型的問題 RBAC模型是根據“角色”去判斷權限的 但實際業務場景有不同用戶是同一“角色” 但是不同權限點的情況 如果用創建多個“角色”來解決的話 覺得不太靈活 想到了改變這個模型 把權限直接和“用戶”掛鉤 而不是“角色” 但這個模型就變了 會不會用戶更難理解
這個問題您有什么意見嗎
…..這無所謂啊,模型就是總結了一個方法給你用。 你覺得不適合你的業務,直接改了就行。 為什么要照抄呢,一般的用戶并不知道RBAC,變了就變了唄
權限最開始就是 用戶-權限,后面人多了才有 角色 概念。
可以搜下訪問控制模型 權限相關的 了解下 角色、組織架構、崗位等等字段的出現跟企業的發展有怎樣關系。
個人認為,不同用戶是同一角色但職責又不同,原因是因為公司對崗位的理解和劃分不清晰,可以協助梳理崗位的職責以明確劃分,此外可以從產品角度,抽象兩個角色,根據不同的使用需求進行相關配置
父子角色
作者是否有實戰經驗,能否將 權限大小、交叉、數據隔離,以及最后的轉換模型 詳細分享下呢
您好,我想問一下權限在業務系統里還是單獨一個系統?
看情況,如果是單體就在一個系統,如果是微服務或sso等就抽取到一個系統
我覺得看你做的大小吧,一般僅僅是一個模塊。
您好,想問一下,怎么設計跨企業的業務流程?單位之間不存在隸屬關系,但是業務上有交叉
審批
您好,我想知道,權限設計應該在產品初成型的時候就做完整的梳理和設計,還是先做簡單權限區分,等產品相對成熟后再做更完善的權限設計?謝謝~
在設計的時候最好考慮未來一段時間的業務發展變化,基于這個變化來設計,不然權限體系很快就會落后,面臨調整或重構,我們的系統就是從上線到現在已經調整過三次了。
你好,還有個問題想問下,就是功能權限和數據權限的之間的關系,我認為既然是如果具有了對某個模塊的功能權限,那就必然獲得了對這個模塊的數據權限,畢竟是先要可見,才可以執行相應的操作,可以這么理解嗎?
我的理解是功能都是基于數據的衍生品,有了數據才有相對應的功能,所以我也不是很明白數據權限和功能權限的關系
應該這樣理解吧,有了功能權限肯定也是有數據權限,有了數據權限肯定也有功能權限,但是兩個角色都有某個功能權限,但他們兩個的數據權限不一定相同,數據權限的維度要低于功能權限
數據權限和功能權限應該是相互獨立的,權限是功能權限與數據權限交叉子集。有功能權限而無數據權限,無法操作該條數據;無功能權限而有數據權限,則也無法操作。必須同時擁有功能權限和數據權限,才能操作數據。
你的描述應該是想知道功能權限與數據權限及操作權限之間的關系吧,可以概括為:功能權限優于數據權限和操作權限:
1、獲得數據權限和操作權限一定要獲得功能權限,舉個例子:你需要查看公司數據銷售數據(數據權限)及新增報表字段(操作權限),必須得先有數據報表頁面(功能權限);
2、獲得功能權限不一定需要獲得數據權限和操作權限,舉個例子:你擁有數據報表功能,但你可以不展示數據(數據權限)和不進行操作(操作權限),這個依然是成立的;
具有了對某個模塊的功能權限,那就必然獲得了對這個模塊的數據權限,這句話對
但是文中的數據權限主要是講,不同角色的數據權限
例:部門經理和區域總監都有客戶管理中權限,但是對于數據范圍的要求是不同的
部門經理只能看到本部門及以下的客戶數據
區域總監則可以看到所有部門及以下的客戶數據
“數據權限”這個名字很容易誤導人,應該稱作“數據范圍”,即這個角色擁有的數據查看范圍。而數據范圍同組織架構,以及該用戶在該組織中的角色、層級有關系。例如張三是華北區一個普通銷售,他的數據權限局限在自己的業務上,只能查看自己的客戶數據。但李四是華北區總,他除了可以查看自己的客戶數據外,還能查看華北區其他銷售的客戶數據。
這里邊還是沒有說出如何解決同等權限下多任職之間數據權限如何處理數據的問題
是的。。我也是想知道這個。。你要是知道了可以分享一下嗎 ?
有兩種解決方案,第一種實現難度低,不用跟組織架構掛鉤,相對簡單,但是只適用于小公司團隊,第二種與組織架構相關,相對復雜;
1、將數據權限與功能權限區分開并與角色關聯,數據權限可以將不同模塊的數據拆分成不同層級顆粒大小的數據集,與功能權限一樣,進行勾選選擇即可;
2、第二種是通過組織架構的部門界定部門從屬關系,通過崗位界定人員從屬關系【關系到數據范圍】,比如員工在A\B兩個公司任職不同的崗位和角色,通過角色將組織信息帶出,然后選擇數據范圍和功能權限,切換組織可以解決不同組織同角色,同權限不同數據范圍的問題;
當然以上是本人結合作者的思考,如果有更好的、更加簡單的方案可以說下。
能否加wx交流下,目前在思考的問題和遇到的問題,比上述情況更棘手
兩者也會都包括呢,既要劃分數據范圍,比如個人的基礎信息、實名信息,也要根據組織架構來區分,比如員工都能看客戶基礎信息,但只能看自己部門的。
其實區分清楚什么是功能權限,什么是數據權限,那么就很好設計了
1.查看客戶基礎信息,在設計上你可以把他歸納到【客戶管理】-【基礎信息】的功能權限上
2.只能看自己部門的,這個是數據權限,一般我們可以把數據權限設計為:本角色信息、本部門信息、本部門及以下信息、全部信息
數據權限并不是說頁面上的數據,而是角色管理邊界
您好~您講的通俗易懂,基本都能看明白,但是最后的tips,第4點,可以詳細解釋下嗎,功能權限與數據權限有時可以通過模塊進行轉換,這個轉換是指什么意思呢?
同問
我理解應該指的是通過功能權限取控制數據權限,例如CRM系統中的客戶可以分為我的客戶、單位客戶、公司客戶,在設計功能模塊時可以將其設置為三個tab,這個就可以通過控制功能權限的來控制數據權限了。反之同理。所以在設計功能時要考慮權限的控制。
學習啦,求問作者一個小問題,文中有提到功能權限中是基于角色的訪問控制設計權限,那數據權限中是不是就是其中提到的以職務為單位將角色粒度細化?
不能這樣理解,數據權限側重的是數據;以職務為單位抽象成角色,只是說可以制定出更細粒的角色而已
多研究下,ERP系統,OA系統權限設計體系,在去其他輕量級產品,小菜一碟
??
好的 謝謝指導,權限設計體系之于OA系統和ERP系統是關鍵與核心
ERP的權限體系設計是最LOW的…已經遠達不到現在的權限管理需求..
去學習下,再來說你LOW,還是與時俱進其他廠商DE “LOW” 國內前兩名-SAAS-CRM 廠商合作很深,不知道你家排幾名?
EBS、SAP、用友這幾家的ERP產品都用過,SALESFORCE的權限也研究過,都沒看到權限體系有什么特別的,不知道你說的先進在哪里,公司現在業務系統權限體系都是內部自己設計的。
建議你去看下用友子公司暢捷通t+產品,或原用友子公司致遠產品的權限體系,以及參數設置,工作流設置
T+產品權限體系好不好不好說,在用友工作幾年,權限方面沒見到亮眼的產品。致遠的產品倒是沒用過…
自開產品,當然要設計自己特征,不存在哪個先進一說,權限體系大于小,復雜與簡單設計差異
權限的先進性不但要滿足業務需要,還要有易用性和好的用戶體驗。
你口口說先進,先進具體內容?那些產品滿足你說的所謂先進性?
舉個簡單的例子,某些ERP產品為了滿足業務權限管控需求,要在系統中設置幾百個角色,權限交叉像蜘蛛網,花費大量的人力,你覺得這種先進么.
英才:先進具體內容?那些產品滿足你說的所謂先進性?
倒數第二條和倒數第三條回復已經描述得很清楚了哈~
對!我覺的因為角色顆粒度細化,而衍生出的幾百個角色,確實能滿足權限管控需求,但是太麻煩了,一點都不便利,可是我找了很多權限體系,看不到能很好地滿足這兩點的,自己又設計不出來,唉
github開源代碼 smartadmin