后臺經(jīng)驗分享:如何做權(quán)限管理系統(tǒng)設(shè)計
作者分享了關(guān)于后臺設(shè)計中權(quán)限管理的相關(guān)知識,希望能夠給你的產(chǎn)品工作帶來一些幫助。
在人人都是產(chǎn)品經(jīng)理的網(wǎng)站上蟄居了4年,學(xué)習(xí)了四年,由于最近的工作方向偏向于后臺,在設(shè)計后臺時時常會查閱后臺的相關(guān)資料,但是關(guān)于后臺的文章等內(nèi)容分享的太少了,正好這一段時間在調(diào)整,想嘗試撰寫一系列的關(guān)于后臺文章,希望跟大家一起來探討、分享,希望對大家有所裨益,由于不同的后臺需求多樣化,不能一一兼顧,只能蜻蜓點水,盡量深入淺出。
權(quán)限管理系統(tǒng)定義
權(quán)限管理是一個幾乎所有后臺系統(tǒng)的都會涉及的一個重要組成部分,主要目的是對整個后臺管理系統(tǒng)進(jìn)行權(quán)限的控制,而針對的對象是員工,避免因權(quán)限控制缺失或操作不當(dāng)引發(fā)的風(fēng)險問題,如操作錯誤,數(shù)據(jù)泄露等問題。其實權(quán)限管理的設(shè)計并不難,就目前來說最廣泛的是一個賬號對應(yīng)多個角色,每個角色對應(yīng)相應(yīng)的權(quán)限集(RBAC模型)這種模型基本可以應(yīng)對所有的問題,且通過角色可以實現(xiàn)靈活且多樣的的權(quán)限操作需求,我們梳理一下上面主要提到的幾個名詞:賬號、角色、權(quán)限。
賬號的定義
每個員工想要進(jìn)入系統(tǒng)肯定都會有一個賬號,而這個賬號就是一把鑰匙。我們通過控制賬號所具備的權(quán)限,進(jìn)而控制這個員工的授權(quán)范圍。因此需要告誡員工,賬號密碼不能輕易提供他人,不然遇到的問題由自己承擔(dān)。
角色的定義
角色管理是確定角色具備哪些權(quán)限的一個過程,他是一個集合的概念,是眾多最小權(quán)限顆粒的組成。我們通過把權(quán)限給這個角色,再把角色給賬號,從而實現(xiàn)賬號的權(quán)限,因此它承擔(dān)了一個橋梁的作用。引入角色這個概念,可以幫助我們靈活的擴(kuò)展,使一個賬號可以具備多種角色。
角色的命名最好按照職位而定,例如市場部普通員工,市場部主管等。因為職位在任何企業(yè)都是存在的,且是有限的,并且容易理解,市場部文員那就是市場部文員角色,方便我們配置權(quán)限時的判斷,避免配置錯誤。
權(quán)限的定義
權(quán)限可以分為三種:頁面權(quán)限,操作權(quán)限,數(shù)據(jù)權(quán)限。
頁面權(quán)限控制你可以看到哪個頁面,看不到哪個頁面,很多系統(tǒng)都只做到了控制頁面這一層級,它實現(xiàn)起來比較簡單,一些系統(tǒng)會這樣設(shè)計,但是比較古板,控制的權(quán)限不精細(xì),難以在頁面上對權(quán)限進(jìn)行更下一層級的劃分。
操作權(quán)限則控制你可以在頁面上操作哪些按妞。(延伸:當(dāng)我們進(jìn)入一個頁面,我們的目的無非是在這個頁面上進(jìn)行增刪改查,那在頁面上對應(yīng)的操作可能是:查詢,刪除,編輯,新增四個按鈕)可能你在某個頁面上,只能查詢數(shù)據(jù),而不能修改數(shù)據(jù)。
數(shù)據(jù)權(quán)限則是控制你可以看到哪些數(shù)據(jù),比如市場A部的人只能看到或者修改A部創(chuàng)建的數(shù)據(jù),他看不到或者不能修改B部的數(shù)據(jù)(延伸:數(shù)據(jù)的控制我們一般通過部門去實現(xiàn),每條記錄都有一個創(chuàng)建人,而每一個創(chuàng)建人都屬于某個部門,因此部門分的越細(xì),數(shù)據(jù)的控制層級也就越精細(xì),這里是否有其他好的方式除了部門這個維度還有其他什么方式可以控制數(shù)據(jù)權(quán)限,大家可以提出來探討一下)。
哪個頁面要放置哪些權(quán)限,完全根據(jù)業(yè)務(wù)需要配置,你只需要把控制權(quán)限的地方列出來交給開發(fā)就好。
權(quán)限管理系統(tǒng)基本的頁面設(shè)計
角色列表頁
- 刪除角色,需要去判斷是否有賬號關(guān)聯(lián)了此角色,如果有關(guān)聯(lián),則不允許刪除。如果角色不想用或者取消了,你可以將角色設(shè)置為無效狀態(tài),賬戶獲取角色時會首先判斷角色是否有效。
- 從便捷性上可以提供一個功能批量給某角色添加賬戶,在新員工入職時特別是同一崗位的,設(shè)置的權(quán)限時效率會大大提升。
給角色配置權(quán)限
賬戶列表頁
- 首先我們肯定有個賬戶列表,因為我們是給賬戶配置權(quán)限。里面可以查詢到或者添加到所有的人(為什么說添加,因為很多大公司有很多的管理系統(tǒng),而每一個管理系統(tǒng)只有一部分人用,所以不會把所有人都在賬戶列表顯示出來,故用到了添加)。
- 這里需要注意的是賬號的禁用,用于防止員工離職后的問題。可以跟人事系統(tǒng)打通,人事那邊設(shè)置某員工離職后,所有系統(tǒng)賬號自動設(shè)為禁用。
- 有很多系統(tǒng),提供了給賬號直接添加具體權(quán)限的功能而不是通過角色,如同下圖,我是不提倡的,給某個員工增加某個特定權(quán)限時,雖然操作更加便捷了,但是缺少規(guī)范性,一個員工明明是只有市場部角色,居然有財務(wù)部的支付功能,這個在頁面上是解釋不通的,而且日積月累會導(dǎo)致人員權(quán)限混亂,這種需求完全可以通過可以新增一個角色去處理。
賬戶列表
給賬戶配置角色
從權(quán)限添加賬戶
這種方式也是不提倡的,這種形式如果上面所講的,直接給賬號添加具體的權(quán)限,雖然提升的操作的便捷性,但是影響了權(quán)限的規(guī)范性與可維護(hù)性,角色這一橋梁就會變成斷橋,統(tǒng)一性就會破壞掉。
截取的部分原型的頁面,頁面有點粗陋,僅供參考。
權(quán)限的分配
權(quán)限的分配要合理,很多公司分配給部門權(quán)限的時候很隨意,部門要什么權(quán)限就給什么權(quán)限,其實這是有隱患的,我們更多需要更深入的考慮部門能有什么權(quán)限,而不是要什么權(quán)限,而這一塊往往被忽略。
總結(jié)
歸根到底我想強(qiáng)調(diào)一件事情,權(quán)限的管理,如何從公司制度上重視,即如何規(guī)范權(quán)限的分配,即那個部門哪個員工要哪個權(quán)限都需要進(jìn)行審批或郵件知會后才能幫其配置,還有哪些數(shù)據(jù)要設(shè)置權(quán)限,哪些操作要設(shè)置權(quán)限,這些權(quán)限管理過程才是權(quán)限系統(tǒng)的核心,恰恰這些核心的東西在系統(tǒng)上是體現(xiàn)不出來的。前期的不經(jīng)意就會在后期會變成麻煩,不僅影響業(yè)務(wù)效率,更會導(dǎo)致風(fēng)險危機(jī)。權(quán)限管理最終是為了風(fēng)控,如果權(quán)限的風(fēng)控意識沒做好,權(quán)限系統(tǒng)做的再好也是枉然。
本文由 @橘子洲頭 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自PEXELS,基于CC0協(xié)議
感覺文字描述和原型圖的意思不一致。
2333
數(shù)據(jù)權(quán)限分配原型應(yīng)該怎么做比較好?
我是做客服的后臺系統(tǒng),請問由于權(quán)限被禁用導(dǎo)致相關(guān)角色無法查看歷史記錄,這種問題怎么解決呢?
能否查看歷史記錄本身推是一個權(quán)限,可設(shè)置是否開放該權(quán)限,或者設(shè)置權(quán)限開放時段
請問作者能留個微信么?
多年產(chǎn)品經(jīng)驗告訴我,嚴(yán)謹(jǐn)?shù)臋?quán)限需求是個偽需求。
真實的需求是,能隨時隨地審核權(quán)限,出事能找替罪羊?,F(xiàn)在看來,騰訊文檔,協(xié)作文檔這種交互最實用。。
請問 數(shù)據(jù)權(quán)限如何設(shè)計的呢
同問
先區(qū)分?jǐn)?shù)據(jù)類型,每種數(shù)據(jù)進(jìn)行任務(wù)溯源,根據(jù)溯源關(guān)系判斷是否需要針對角色開放權(quán)限
權(quán)限給角色、角色給用戶 這樣用戶就有對應(yīng)的權(quán)限了 是這樣嗎?
其實覺得角色分等級應(yīng)該也是可以的
151651
151
糾正一下,是RBAC模型
謝謝指出,打錯了
??
還不錯
??
權(quán)限配置,是典型的后端產(chǎn)品經(jīng)理干的,這么多年經(jīng)驗下來,建議后端產(chǎn)品經(jīng)理還是不要只關(guān)注原型、界面,后端的結(jié)構(gòu)才是相對重要的。
了解權(quán)限的注冊,生成,怎么通過權(quán)限組,角色,節(jié)點,賬號,甚至部門,職位,這些是怎么把Actor和auth連接起來的,他們的實體關(guān)系,權(quán)限類的設(shè)計、實例化,只有親自設(shè)計這些,你才能真正的將做一套適合現(xiàn)行需求的權(quán)限后臺。
另外,采用角色還是節(jié)點,怎么實現(xiàn)你的需求才是合適的,橫縱向擴(kuò)展性,這些都遠(yuǎn)比幾個界面來的實際和重要。
默默點贊,誰做誰知道 ??
說的很有道理,往下深鉆還要很多要點
大神 希望加個微信扣扣啥的 需要指點
唉,當(dāng)年小白時,沒接觸過,后來總算弄明白了。其實很簡單,就是沒人帶。這也是中國互聯(lián)網(wǎng)發(fā)展的毛病,沒有系統(tǒng)的教學(xué)。
是的 不過有本書可以推薦你 大象
你好,請問書名就叫《大象》嗎?
大佬,你知道是哪本書了嗎?我去搜大象,沒有找到相關(guān)的
求指教
這塊資料很多 權(quán)限最多用的模型就是RBAC和Auth 或者自己做 我們之前自己做了一套 采用ping的方式限制, RBAC有很多變種,站在產(chǎn)品角度,連接下實體構(gòu)成,實現(xiàn)模型就好,可以自己根據(jù)需求去做一些定制,例如我上面說的 加入部門、職位 來替代角色
謝謝,您說的很有幫助,這塊還不是一下就能吃透的,還是我需要時間來打磨,慢慢理解您說的話,非常感謝
~~~恩恩 多交流呀~~
大神 方便加個聯(lián)系方式么,我是一個剛踏入JAVA的菜鳥,特別需要一個指路人
大佬,我有個私活,后臺系統(tǒng)設(shè)計,能談一下嘛?
能推薦這方面的書嗎,或者資料
期待后續(xù)的文章
給出了錯誤示例,最好再來個正確示范咯
哪里錯了?
?
??