每日干货分享

【原創乾貨】三個模塊搭建後台用戶角色許可權管理系統!| SG小組第二期


前言:

SG小組(Study Group)是幾個在杭州的產品經理小夥伴基於興趣而自發組建的學習小組,我們每周會定期開展學習和討論會,以期通過分享討論各自熟悉的領域和正在進行的產品項目來達到互相提升的目的。並且,我們會不定期的輸出我們每周學習小組的討論內容,整理成文章的形式與大家共享,歡迎批評指正~ 

第二期主題:三大模塊搭建後台用戶角色許可權系統 !

分享人:陽明(劉同)

  • 用戶角色許可權系統說明
  • 用戶角色許可權系統建設的三大模塊
  • 案例分析
  • Q&A

第一章:用戶角色許可權系統說明

1. RBAC許可權設計模型

  • RBAC:

   (Role-Based Access Control,基於角色的訪問控制),就是用戶通過角色與許可權進行關聯,從而獲得某些功能的使用許可權。許可權被賦予給角色,而不是用戶,但是一個用戶可以擁有若干個角色,當一個角色被賦予給某一個用戶時,此用戶就擁有了該角色所包含的功能許可權。簡單地說,一個用戶擁有若干角色,每一個角色擁有若干功能許可權。這樣,就構造成「用戶-角色-許可權」的授權模型。在這種模型中,用戶與角色之間,角色與許可權之間,一般者是多對多的關係。(如下圖)

【原創乾貨】三個模塊搭建後台用戶角色許可權管理系統!| SG小組第二期

2. 三大模塊搭建後台用戶角色許可權系統

       如上所述,一個後台的用戶角色許可權系統總是可以大概劃分為三個打的模塊的:用戶管理、角色管理、許可權管理。用戶管理往往隨著行政部門劃分或者隨著業務線部門劃分,對應部門或者小組內的用戶有著基本相似的功能需求和許可權等級;角色管理相對來講更加固定,它往往是基於業務管理需求而預先在系統中設定好的角色標籤,一般不會隨意更改,更像是一個用戶分組標籤;許可權管理內容相對更加龐雜和豐富,主要包含了目標、操作和許可權三個部分,當某一功能許可權授權給用戶時,也就相當於為該用戶開通了可以操作某個目標功能的許可權。

       角色許可權系統屬於策略設計的範疇,它的設計非常考驗一個PM對業務的理解力以及對自己後台所有功能的熟悉程度。做角色許可權系統之前一定要先深度了解業務流程以及後台的所有功能模塊,在不了解的情況下,多向相關同事請教,避免角色許可權系統設計過程中出差錯和邏輯漏洞。

【原創乾貨】三個模塊搭建後台用戶角色許可權管理系統!| SG小組第二期

第二章:用戶角色許可權系統建設的三大模塊

1. 用戶管理

  • 用戶管理中的用戶主要是功能系統的使用者,這些用戶是一個一個的員工個體,這些個體往往從兩個維度來進行劃分:行政關係(部門架構)、業務部門(業務架構)。用戶管理就是在此兩個維度來給員工個體進行關聯性的初步分群或者分組。按照行政部門或者按照業務線部門劃分后,對應部門或者小組內的用戶有著基本相似的系統功能使用需求和許可權等級;

【原創乾貨】三個模塊搭建後台用戶角色許可權管理系統!| SG小組第二期

註:上圖例為按照行政關係劃分的用戶管理模式;

        【原創乾貨】三個模塊搭建後台用戶角色許可權管理系統!| SG小組第二期

註:上圖例為按照業務線關係劃分的用戶管理模式;

2. 角色管理

  • 角色管理:

     角色往往是基於業務管理需求而預先在系統中設定好的固定標籤,每個角色對應明確的系統許可權,其所擁有的系統許可權一般不會隨意更改,並且角色也不會隨著用戶的被添加和被移除而進行改變,相較於用戶管理而言更加穩定;

【原創乾貨】三個模塊搭建後台用戶角色許可權管理系統!| SG小組第二期

  • 自動賦權:用戶自動進入角色

       如果角色與行政關係下的組織部門存在綁定關係,那麼如果一個用戶進入到該組織部門后,該用戶會自動被加入到對應的角色中,並且擁有該角色所有的系統許可權。如一個財務人員【小張】入職財務部后,那麼該用戶無需進行額外的授權即可在對應財務報表系統查看該部門員工可查看的財務數據報表和對應的操作許可權(比如操作財務審批等);

  • 角色賦權:用戶被添加進角色

       業務是不斷創新和發展的,隨著業務的發展,會有越來越多的新的角色被設置和創建,比如公司新啟動了一個企業團餐項目,項目部橫向的從各個部門找了多個員工組建項目團隊,並且該項目的業務許可權也只是授權給這批員工可查看和操作,那麼,在此項目中,會產生一個新的角色 「 財務1 」,系統高級管理員會把從財務部門選中的財務【小張】添加到「 財務1 」這個角色中,那麼【小張】即可獲得查看企業團餐項目業務數據報表和操作的許可權。這種許可權的授予無法通過用戶行政關係的自動綁定來實現;

  • 角色繼承:角色許可權的繼承

       許可權可以是獨有的,也可以是繼承的。每個角色都有自己的許可權集,角色繼承其實也就是繼承父系角色的許可權,一般角色在繼承其父系角色的全部許可權的基礎上增加擁有一些自己的許可權。而系統角色繼承往往存在於用戶分級管理比較明確的團隊或者公司;

  • 角色互斥:角色包含的許可權互斥

       角色互斥的業務背景:當一個業務流程由於風控的原因,需要將其操作給劃分成分開的幾個步驟時,需要給這幾個不同的步驟授權不同的角色,並且這些角色之間需要進行互斥。比如大額財務報銷審批流程,財務人員【小張】擁有了審批人許可權后,就無法將審核確認的許可權再授予小張,以此來規避一個人完成大額報銷而帶來的財務風險;

  • 臨時角色:

       臨時角色往往是針對特殊群體設置的,比如公司有特殊訪問團隊蒞臨,需要給這些特殊的客戶一些臨時身份來體驗某些功能操作。那麼把這些人添加到部門的組織架構中顯然是不合適的,因為這些人只是臨時的擺放者,不是企業員工;其次,這些客戶需要體驗的功能操作往往是橫跨多個業務模塊和產品線的(比較繁雜),一般公司並沒有現成的固定角色符合擁有客戶所需的全部操作許可權,因此需要給這些客戶開設臨時角色,並且支持給臨時角色最大的許可權選擇空間;

  • 黑白名單

3. 許可權管理

  • 許可權管理:

       許可權管理更多是從功能菜單、功能操作、數據參數三個不同顆粒度等級來考量的。具體顆粒度的大小視公司結構和團隊規模而定,如果不是業務屬性一定要求將許可權控制到非常精細的級別,其實就沒有必要將許可權的顆粒度拆分到具體某一項操作或者某一個按鈕,畢竟後台產品的核心是業務管理平台,主要目標是輔助業務的管理和推進。

【原創乾貨】三個模塊搭建後台用戶角色許可權管理系統!| SG小組第二期

註:如圖為某一後台產品的部分截圖,其中可見功能菜單頁、功能操作按鈕和數據欄位。

  • 功能菜單許可權:

       對於後台產品來講,針對功能菜單來劃分用戶許可權其實是比較粗顆粒度的一種管理方式,這種模式下用戶一旦獲得授權即可使用該菜單欄下的全部數據查看許可權和功能操作許可權;

  • 功能操作許可權:

       功能操作層級的許可權相對於功能菜單會更為深入,這種情況下,不同角色的用戶可以進入同一菜單頁後台查看相同的數據欄位信息,但是他們可執行的功能操作不同;

  • 數據欄位許可權:

       數據欄位層面是較細顆粒度的拆分,他會實現不同角色用戶在進入同一菜單頁後台時,可見的數據欄位都有差異。比如銷售人員進入某銷售業績管理後台時,可以看到自己的業績提升數據,但是財務人員看到的是業務工單的費用欄位,這些欄位共存在一個菜單頁中,只是受限於不同的角色許可權而已。


第三章:案例分析

1. 促銷活動許可權系統許可權對接

以某一促銷活動的後台從無許可權限制到接入用戶角色許可權管理系統為例,詳情如下:

【原創乾貨】三個模塊搭建後台用戶角色許可權管理系統!| SG小組第二期

【原創乾貨】三個模塊搭建後台用戶角色許可權管理系統!| SG小組第二期

註:以上為某產品的促銷活動管理後台截圖。

  • 促銷活動後台接入許可權系統前:

       在促銷活動後台接入許可權系統之前,幾乎全部的系統許可權都處於裸奔的狀態,所有人業務線成員都可以查看該後台的運營活動內容和運營結果數據,並且可以執行相對敏感的操作。這種情況顯然是存在一定的管理風險的,因此該後台系統需要對接許可權管理系統進行系統化管理和風險控制;

  • 促銷活動後台接入許可權系統時:

       促銷活動在接入許可權管理系統過程中,需要拆解該功能模塊的許可權元素(到一定顆粒度),因此需要根據業務特徵來判斷需要拆分的顆粒度,是到功能菜單、功能操作還是數據欄位的級別,明確拆分顆粒度之後,許可權管理系統才可以給不同角色按照顆粒度授予許可權;

  • 促銷活動後台接入許可權系統后:

       促銷活動在接入許可權管理系統過程后,當對應角色的用戶再次登錄這個後台時,首先後台會校驗該用戶的角色是否擁有該功能模塊的許可權,以及該角色許可權對應的操作許可權和數據欄位許可權,校驗結果經服務端處理會在產品端展示給用戶可見。這個時候,同一用戶再該後台可見和可執行的操作與接入許可權管理系統之前可能有很大的不同,這就是基於用戶角色的許可權管理系統帶來的改變。


第四章:Q&A

1. 一個用戶擁有多個角色,多角色之間如果存在互斥關係如何處理?

  • 如果一個用戶已經被添加到某一角色範圍下,那麼,當給該用戶添加一個與當前角色存在許可權互斥關係的角色時,系統會進行互斥性判斷,後面的角色就無法給該用戶添加成功;

2. 業務發展過程中,如何保證不同角色之間許可權拆分清晰?

  • 隨著業務的快速發展,一定會不斷新增不同的角色和更多的功能模塊,而且這些角色和功能許可權之間的關係也會日益混亂,這個時候需要產品經理和業務方一起,及時的面對業務的發展變化,及時、快速的梳理業務調整範圍,作出對應的改變;

3. 用戶許可權管理系統核心難點是前期的產品設計嗎?

  • 用戶許可權管理系統核最難的不是前期的產品設計,而是後續的運營維護,因為許可權系統的結構往往不會隨意變更,但是隨著業務發展快速出現的角色和功能模塊,為了防止角色和功能許可權之間的關係變得混亂,在建立新的角色和分配許可權的時候需要思路清晰且慎重調整。


更多SG小組分享內容資料:

【原創乾貨】用戶標籤/用戶分群在DMP(數據管理平台)中的應用 | SG小組第一期