后臺設計之權限管理

29 評論 55146 瀏覽 449 收藏 8 分鐘

權限系統是每位后臺產品產品經理繞不過去的問題,好的權限系統可以明確公司內不同人員、不同部門的分工,降低操作風險發生概率,便于管理等優勢。筆者曾負責過若干種后臺系統的搭建,其中都繞不開“權限管理”,現愿意將我個人經驗和工作中所產生的的思考與大家進行分享。

1. 權限系統是什么

一句話概括,我個人認為權限系統就是:明確操作人員可在平臺內能做什么。即什么樣的人,可以做什么樣的事,這并不難理解,我們的用戶是所有可以登錄該平臺的人員。

2. 權限系統應該怎么做

在這筆者先介紹一下“RBAC”結構的含義,所謂RBAC即:權限與角色相關聯,用戶通過成為適當角色的成員而得到這些角色的權限。

由此可見,通常的權限管理,可分為三個部分及“用戶管理”、“角色管理”和“權限管理”三個部分。

通常來說,用戶與角色一一對應,一個用戶對應一個角色;同一個角色可對應多個后臺操作頁面;若公司具有多個產品線,那么多個角色對應同一個產品。其結構如下圖所示:

有些讀者可能會有疑問,如果去掉“角色”概念,直接將用戶與權限進行綁定是否可以減輕工作步驟?

表面上看來,如果沒有“角色”,也可以為用戶分配權限,但仔細思考后,會發現如下問題:

  1. 若不同用戶擁有相同權限,那么后臺操作人員將重復配置多次。
  2. 若用戶身份變更,需重新梳理權限。
  3. 若用戶離職,將出現多個無用權限,造成垃圾數據。

綜上所述,RBAC結構可通過“角色”搭建用戶與權限之間的關系,可在創建角色時綁定相應權限,再匹配到用戶,可提高整體的效率以及穩定性。

3. 權限系統三要素

前文已經講過,權限系統的核心三個功能為:用戶、角色和權限,下圖為簡要的腦圖,可輔助理解。

3.1 用戶管理

通常企業的后臺管理系統,可以同企業內部OA或企業微信等系統間打通,當用新員工入職時,可主動申請后臺相應權限,高級管理員(即權限分配者)根據用戶的職責,分配具體的角色。若后臺系統暫未與系統打通,則需管理員手動創建用戶。

用戶界面原型圖如上所示,該原型內為尚未連接企業OA,需手動創建用戶,所有可登錄后臺的用戶都將在表中展示。

添加用戶的界面如下圖所示:

在創建用戶時,需輸入用戶的基本信息,并直接為用戶綁定角色,那么如何設定角色呢?這是我們下一步需要說明的問題。

細心的同學不難發現,上圖頁面中存在“修改權限”的按鈕,該功能的存在是為了避免角色與權限的綁定過于僵化,可針對同一角色在不同用戶使用時,進行微調,避免每次都產生新的角色。

3.2 角色管理

角色可由兩個維度確認:

  1. 業務維度
  2. 等級維度

所謂業務相對來說方便理解,即不同的角色負責不同的功能,例如:配置專員,負責內容物料的配置以及上架;審核專員,負責上架前的審核工作。

等級維度,即超級管理員、普通管理員和XX專員,超級管理員擁有針對所有用戶添加角色、添加用戶的權限,普通專員只能圍繞自身業務進行管理,而專員的權限最弱,只負責基礎的執行工作。

業務維度視平臺的功能和業務定義,等級維度可按照系統復雜度以及人員架構方向確定。

角色列表同用戶列表一樣,將展示平臺內所有的角色,以及該角色對應的說明、人數以及狀態(開啟/關閉)。

創建角色的過程中,可為該角色配置相應的權限??刹捎秒p向樹結構或列表勾選的方式快速添加。

3.3 權限說明

權限系統,離不開具體的權限,之所以放到最后,是因為權限相比較前面兩個元素來說更為復雜。通常后臺的權限分為:頁面權限、操作權限和數據權限。

  • 頁面權限:用戶是否具備進入/瀏覽該頁面的權限,例如,負責物料上傳的運營人員,應有物料上架的頁面權限,但無需數據埋點反饋的頁面權限。
  • 操作權限:在擁有頁面權限后,是否可擁有對該頁面進行操作的權限。例如,數據專員可以對數據統計后臺的報表進行整合、下載等,但無法更改數據統計規則。
  • 數據權限:數據權限較比于其他兩個權限較為抽象。指的是用戶是否有針對某些數據的瀏覽權限。例如,同一個管理后臺內,可看到公司不同產品產品線的下載率、DAU、Crash率等等,但是作為某條產品線的員工,只能看到該產品線的數據,而無法對其他產品線的數據進行觀測。

通常頁面權限和操作權限將會在權限列表中拉取系統內的所有頁面和可進行的操作,通過樹狀圖展示給操作人員,進行配置,而數據權限則需要貼合公司的業務進行分析。

4. 總結

以上就是筆者對于權限系統設計的思考與總結,后臺系統的設計,沒有絕對的好與壞,也沒有DAU、MAU的壓力,但是也有自己的獨特之處即一定要圍繞業務來做,以滿足業務為核心,提高效率為目標。

如有機會,后續將會介紹CRM系統以及內容管理CMS系統。

 

本文由 @Forza 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自 Unsplash,基于 CC0 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 想問一下admin賬號是怎么來的,是后端設置的嗎?

    來自四川 回復
  2. 數據權限可以和用戶直接綁定,功能權限和角色綁定

    回復
  3. 你好,如果為一個用戶添加多個角色,在用戶登錄時該如何處理呢?合并權限或是角色切換,或者是別的方案?

    來自浙江 回復
    1. 合并權限,取權限的并集

      來自中國 回復
  4. 學到了,寫的很好理解。表達棒棒噠

    回復
  5. 你好,我是做B端ERP系統的,請問一下,數據權限隔離,這個數據權限隔離怎么和用戶關聯起來,按照我的理解,同一個頁面,某些數據你可以看,我看不到,那這些數據前提應該是和用戶建立綁定關系,這是我自己的理解,不知道對不對

    回復
    1. ERP系統應該是根據業務建立崗位和標準角色,根據崗位來做數據權限的授權吧

      來自四川 回復
  6. 角色管理

    回復
  7. 數據權限如何設計?

    回復
    1. 同問。

      來自四川 回復
  8. 數據權限和頁面權限感覺很像

    回復
    1. 還是有不一樣的吧,我的理解是頁面權限屬于分配頁面(欄目),有些欄目只有一定等級的人員可以查看,比如管理人員可以查看統計報表而普通員工無法查看;而數據權限屬于對頁面內的數據的權限,同一個頁面中可能有多類數據,比如業務人員只能查看自己的業務情況,但是管理人員可以查看所有人的業務情況,這個屬于同一個頁面的不同數據權限劃分了。淺薄之見哈

      來自湖南 回復
    2. 謝謝

      來自廣東 回復
  9. 數據權限該如何配置?

    來自福建 回復
  10. 也很感謝你的這篇文章,第3遍閱讀了,對優化公司產品起了很大的作用!

    來自北京 回復
    1. ??

      來自浙江 回復
    2. 哈哈,承蒙感謝,十分榮幸。大家一起學習哈

      來自北京 回復
  11. 也會有不同用戶處于同一角色,但數據權限不同的情況

    來自北京 回復
    1. 不同用戶同一角色 但組織結構不同 權限也就會不同

      來自北京 回復
  12. “通常來說,用戶與角色一一對應,一個用戶對應一個角色”

    ——用戶與角色大部分情況下不是一 一對應的;一個用戶可能會有多個角色,一個角色也可能會有多個用戶

    來自北京 回復
    1. 實際上,確實是一用戶包含多角色,優化之前公司的產品(2B產品),看到用戶與角色綁定,角色與權限綁定的設計,無非都是為了圖快滿足客戶的一時需求,而后又不做更新迭代優化,處理起來改動很大。

      來自北京 回復
    2. 謝謝您的建議,學習啦

      來自北京 回復
    3. 角色可以不斷的建,一個用戶多個角色,我理解其實可以建立一個角色,把多個角色的權限加進到這一個角色,再給這個用戶,綁定這個角色,這樣不知行不行

      來自浙江 回復
  13. 第一篇么,鼓勵一下加油。我也是做B端產品的,有興趣的話,可以一起努力,目前我發布了十篇文章。微信:znc0520 ??

    來自河南 回復
    1. 沒想到能在這遇到你,之前閱讀過你的文章“三年產品經理的轉正述職報告”,我也在做智慧校園業務 ??

      來自北京 回復
    2. 哈哈哈,我無處不在。可以加個朋友一起學習進步。 ??

      來自河南 回復
  14. 用戶、角色、權限三者分開,以角色作為橋梁將用戶和權限關聯起來,這樣的配置賊方便
    再給權限分個組:預先將權限分好,并設置一批角色,比較方便
    再加一個權限轉移的功能,解決人員變動帶來的權限調整

    來自浙江 回復
    1. 謝謝您的建議

      來自北京 回復
    2. ?? 別這么客氣,一起學習,一起成長

      來自浙江 回復