後臺許可權管理系統設計(圖文教程)
後臺許可權管理系統設計(圖文教程)
![](https://img-blog.csdnimg.cn/20181228125805100.jpg)
作者:橘子洲頭
全文共 2210 字 5 圖,閱讀需要 6 分鐘
參考:原文連結
———————— / BEGIN / ————————
在人人都是產品經理的網站上蟄居了4年,學習了四年,由於最近的工作方向偏向於後臺,在設計後臺時時常會查閱後臺的相關資料,但是關於後臺的文章等內容分享的太少了。
正好這一段時間在調整,想嘗試撰寫一系列的關於後臺文章,希望跟大家一起來探討、分享,希望對大家有所裨益。
由於不同的後臺需求多樣化,不能一一兼顧,只能蜻蜓點水,儘量深入淺出。
一、許可權管理系統定義
許可權管理是一個幾乎所有後臺系統的都會涉及的一個重要組成部分,主要目的是對整個後臺管理系統進行許可權的控制,而針對的物件是員工,避免因許可權控制缺失或操作不當引發的風險問題,如操作錯誤,資料洩露等問題。
其實許可權管理的設計並不難,就目前來說最廣泛的是一個賬號對應多個角色,每個角色對應相應的許可權集(RBAC模型)這種模型基本可以應對所有的問題,且通過角色可以實現靈活且多樣的的許可權操作需求,我們梳理一下上面主要提到的幾個名詞:賬號、角色、許可權。
1. 賬號的定義
每個員工想要進入系統肯定都會有一個賬號,而這個賬號就是一把鑰匙。
我們通過控制賬號所具備的許可權,進而控制這個員工的授權範圍。
因此需要告誡員工,賬號密碼不能輕易提供他人,不然遇到的問題由自己承擔。
2. 角色的定義
角色管理是確定角色具備哪些許可權的一個過程,他是一個集合的概念,是眾多最小許可權顆粒的組成。
我們通過把許可權給這個角色,再把角色給賬號,從而實現賬號的許可權,因此它承擔了一個橋樑的作用。
引入角色這個概念,可以幫助我們靈活的擴充套件,使一個賬號可以具備多種角色。
角色的命名最好按照職位而定,例如市場部普通員工,市場部主管等。因為職位在任何企業都是存在的,且是有限的,並且容易理解,市場部文員那就是市場部文員角色,方便我們配置許可權時的判斷,避免配置錯誤。
3. 許可權的定義
許可權可以分為三種:頁面許可權,操作許可權,資料許可權。
頁面許可權
控制你可以看到哪個頁面,看不到哪個頁面。
很多系統都只做到了控制頁面這一層級,它實現起來比較簡單,一些系統會這樣設計,但是比較古板,控制的許可權不精細,難以在頁面上對許可權進行更下一層級的劃分。
操作許可權
則控制你可以在頁面上操作哪些按妞。
可能你在某個頁面上,只能查詢資料,而不能修改資料。
資料許可權
資料許可權則是控制你可以看到哪些資料,比如市場A部的人只能看到或者修改A部建立的資料,他看不到或者不能修改B部的資料。
哪個頁面要放置哪些許可權,完全根據業務需要配置,你只需要把控制權限的地方列出來交給開發就好。
二、許可權管理系統基本的頁面設計
1. 角色列表頁
刪除角色,需要去判斷是否有賬號關聯了此角色,如果有關聯,則不允許刪除。如果角色不想用或者取消了,你可以將角色設定為無效狀態,賬戶獲取角色時會首先判斷角色是否有效。
從便捷性上可以提供一個功能批量給某角色新增賬戶,在新員工入職時特別是同一崗位的,設定的許可權時效率會大大提升。
給角色配置許可權
2. 賬戶列表頁
首先我們肯定有個賬戶列表,因為我們是給賬戶配置許可權。裡面可以查詢到或者新增到所有的人(為什麼說新增,因為很多大公司有很多的管理系統,而每一個管理系統只有一部分人用,所以不會把所有人都在賬戶列表顯示出來,故用到了新增)。
這裡需要注意的是賬號的禁用,用於防止員工離職後的問題。可以跟人事系統打通,人事那邊設定某員工離職後,所有系統賬號自動設為禁用。
有很多系統,提供了給賬號直接新增具體許可權的功能而不是通過角色,如同下圖,我是不提倡的,給某個員工增加某個特定許可權時,雖然操作更加便捷了,但是缺少規範性,一個員工明明是隻有市場部角色,居然有財務部的支付功能,這個在頁面上是解釋不通的,而且日積月累會導致人員許可權混亂,這種需求完全可以通過可以新增一個角色去處理。
賬戶列表
給賬戶配置角色
3. 從許可權新增賬戶
這種方式也是不提倡的,這種形式如果上面所講的,直接給賬號新增具體的許可權,雖然提升的操作的便捷性,但是影響了許可權的規範性與可維護性,角色這一橋樑就會變成斷橋,統一性就會破壞掉。
擷取的部分原型的頁面,頁面有點粗陋,僅供參考。
三、許可權的分配
許可權的分配要合理,很多公司分配給部門許可權的時候很隨意,部門要什麼許可權就給什麼許可權,其實這是有隱患的。
我們更多需要更深入的考慮部門能有什麼許可權,而不是要什麼許可權,而這一塊往往被忽略。
四、總結
歸根到底我想強調一件事情:許可權的管理,如何從公司制度上重視?
即如何規範許可權的分配,即那個部門哪個員工要哪個許可權都需要進行審批或郵件知會後才能幫其配置,還有哪些資料要設定許可權,哪些操作要設定許可權,這些許可權管理過程才是許可權系統的核心,恰恰這些核心的東西在系統上是體現不出來的。
前期的不經意就會在後期會變成麻煩,不僅影響業務效率,更會導致風險危機。
許可權管理最終是為了風控,如果許可權的風控意識沒做好,許可權系統做的再好也是枉然。
———— / END / ————