后臺經(jīng)驗(yàn)分享:如何做權(quán)限管理系統(tǒng)設(shè)計(jì)

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