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