權限管理系統簡單模型

權限管理系統定義

權限管理是一個幾乎全部後臺系統的都會涉及的一個重要組成部分，主要目的是對整個後臺管理系統進行權限的控制，而針對的對象是員工，避免因權限控制缺失或操做不當引起的風險問題，如操做錯誤，數據泄露等問題。其實權限管理的設計並不難，就目前來講最普遍的是一個帳號對應多個角色，每一個角色對應相應的權限集（RBAC模型）這種模型基本能夠應對全部的問題，且經過角色能夠實現靈活且多樣的的權限操做需求，咱們梳理一下上面主要提到的幾個名詞：帳號、角色、權限。

帳號的定義

每一個員工想要進入系統確定都會有一個帳號，而這個帳號就是一把鑰匙。咱們經過控制帳號所具有的權限，進而控制這個員工的受權範圍。所以須要告誡員工，帳號密碼不能輕易提供他人，否則遇到的問題由本身承擔。

角色的定義

角色管理是肯定角色具有哪些權限的一個過程，他是一個集合的概念，是衆多最小權限顆粒的組成。咱們經過把權限給這個角色，再把角色給帳號，從而實現帳號的權限，所以它承擔了一個橋樑的做用。引入角色這個概念，能夠幫助咱們靈活的擴展，使一個帳號能夠具有多種角色。

角色的命名最好按照職位而定，例如市場部普通員工，市場部主管等。由於職位在任何企業都是存在的，且是有限的，而且容易理解，市場部文員那就是市場部文員角色，方便咱們配置權限時的判斷，避免配置錯誤。

權限的定義

權限能夠分爲三種：頁面權限，操做權限，數據權限。

頁面權限控制你能夠看到哪一個頁面，看不到哪一個頁面，不少系統都只作到了控制頁面這一層級，它實現起來比較簡單，一些系統會這樣設計，可是比較古板，控制的權限不精細，難以在頁面上對權限進行更下一層級的劃分。

操做權限則控制你能夠在頁面上操做哪些按妞。（延伸：當咱們進入一個頁面，咱們的目的無非是在這個頁面上進行增刪改查，那在頁面上對應的操做多是：查詢，刪除，編輯，新增四個按鈕）可能你在某個頁面上，只能查詢數據，而不能修改數據。

數據權限則是控制你能夠看到哪些數據，好比市場A部的人只能看到或者修改A部建立的數據，他看不到或者不能修改B部的數據（延伸：數據的控制咱們通常經過部門去實現，每條記錄都有一個建立人，而每個建立人都屬於某個部門，所以部門分的越細，數據的控制層級也就越精細，這裏是否有其餘好的方式除了部門這個維度還有其餘什麼方式能夠控制數據權限，你們能夠提出來探討一下）。

哪一個頁面要放置哪些權限，徹底根據業務須要配置，你只須要把控制權限的地方列出來交給開發就好。

權限管理系統基本的頁面設計

角色列表頁

1. 刪除角色，須要去判斷是否有帳號關聯了此角色，若是有關聯，則不容許刪除。若是角色不想用或者取消了，你能夠將角色設置爲無效狀態，帳戶獲取角色時會首先判斷角色是否有效。
2. 從便捷性上能夠提供一個功能批量給某角色添加帳戶，在新員工入職時特別是同一崗位的，設置的權限時效率會大大提高。

給角色配置權限

帳戶列表頁

1. 首先咱們確定有個帳戶列表，由於咱們是給帳戶配置權限。裏面能夠查詢到或者添加到全部的人（爲何說添加，由於不少大公司有不少的管理系統，而每個管理系統只有一部分人用，因此不會把全部人都在帳戶列表顯示出來，故用到了添加）。
2. 這裏須要注意的是帳號的禁用，用於防止員工離職後的問題。能夠跟人事系統打通，人事那邊設置某員工離職後，全部系統帳號自動設爲禁用。
3. 有不少系統，提供了給帳號直接添加具體權限的功能而不是經過角色，如同下圖，我是不提倡的，給某個員工增長某個特定權限時，雖然操做更加便捷了，可是缺乏規範性，一個員工明明是隻有市場部角色，竟然有財務部的支付功能，這個在頁面上是解釋不通的，並且日積月累會致使人員權限混亂，這種需求徹底能夠經過能夠新增一個角色去處理。

帳戶列表

給帳戶配置角色

從權限添加帳戶

這種方式也是不提倡的，這種形式若是上面所講的，直接給帳號添加具體的權限，雖然提高的操做的便捷性，可是影響了權限的規範性與可維護性，角色這一橋樑就會變成斷橋，統一性就會破壞掉。

截取的部分原型的頁面，頁面有點粗陋，僅供參考。

權限的分配

權限的分配要合理，不少公司分配給部門權限的時候很隨意，部門要什麼權限就給什麼權限，其實這是有隱患的，咱們更多須要更深刻的考慮部門能有什麼權限，而不是要什麼權限，而這一塊每每被忽略。

總結

歸根到底我想強調一件事情，權限的管理，如何從公司制度上重視，即如何規範權限的分配，即那個部門哪一個員工要哪一個權限都須要進行審批或郵件知會後才能幫其配置，還有哪些數據要設置權限，哪些操做要設置權限，這些權限管理過程纔是權限系統的核心，偏偏這些核心的東西在系統上是體現不出來的。前期的不經意就會在後期會變成麻煩，不只影響業務效率，更會致使風險危機。權限管理最終是爲了風控，若是權限的風控意識沒作好，權限系統作的再好也是枉然。