一個後台的用戶角色權限系統總是可以大概劃分為三個打的模塊的：用戶管理、角色管理、權限管理。本文作者将就此三個模塊展開叙述，enjoy~

一. 用戶角色權限系統說明

1. RBAC權限設計模型

（1）RBAC

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

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

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

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

二. 用戶角色權限系統建設的三大模塊

1. 用戶管理

用戶管理中的用戶主要是功能系統的使用者，這些用戶是一個一個的員工個體，這些個體往往從兩個維度來進行劃分：行政關系（部門架構）、業務部門（業務架構）。用戶管理就是在此兩個維度來給員工個體進行關聯性的初步分群或者分組。按照行政部門或者按照業務線部門劃分後，對應部門或者小組内的用戶有着基本相似的系統功能使用需求和權限等級；

注：上圖例為按照行政關系劃分的用戶管理模式

注：上圖例為按照業務線關系劃分的用戶管理模式

2. 角色管理

（1）角色管理

角色往往是基于業務管理需求而預先在系統中設定好的固定标簽，每個角色對應明确的系統權限，其所擁有的系統權限一般不會随意更改，并且角色也不會随着用戶的被添加和被移除而進行改變，相較于用戶管理而言更加穩定；

（2）自動賦權：用戶自動進入角色

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

（3）角色賦權：用戶被添加進角色

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

（4）角色繼承：角色權限的繼承

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

（5）角色互斥：角色包含的權限互斥

角色互斥的業務背景：當一個業務流程由于風控的原因，需要将其操作給劃分成分開的幾個步驟時，需要給這幾個不同的步驟授權不同的角色，并且這些角色之間需要進行互斥。比如大額财務報銷審批流程，财務人員【小張】擁有了審批人權限後，就無法将審核确認的權限再授予小張，以此來規避一個人完成大額報銷而帶來的财務風險；

（6）臨時角色

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

（7）黑白名單

3. 權限管理

（1）權限管理

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

注：如圖為某一後台産品的部分截圖，其中可見功能菜單頁、功能操作按鈕和數據字段。

（2）功能菜單權限

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

（3）功能操作權限

功能操作層級的權限相對于功能菜單會更為深入，這種情況下，不同角色的用戶可以進入同一菜單頁後台查看相同的數據字段信息，但是他們可執行的功能操作不同；

（4）數據字段權限

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

三. 案例分析

1. 促銷活動權限系統權限對接

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

注：以上為某産品的促銷活動管理後台截圖

2. 促銷活動後台接入權限系統前

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

3. 促銷活動後台接入權限系統時

促銷活動在接入權限管理系統過程中，需要拆解該功能模塊的權限元素（到一定顆粒度），因此需要根據業務特征來判斷需要拆分的顆粒度，是到功能菜單、功能操作還是數據字段的級别，明确拆分顆粒度之後，權限管理系統才可以給不同角色按照顆粒度授予權限；

4. 促銷活動後台接入權限系統後

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

四. Q&A

1. 一個用戶擁有多個角色，多角色之間如果存在互斥關系如何處理？

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

2. 業務發展過程中，如何保證不同角色之間權限拆分清晰？

随着業務的快速發展，一定會不斷新增不同的角色和更多的功能模塊，而且這些角色和功能權限之間的關系也會日益混亂，這個時候需要産品經理和業務方一起，及時的面對業務的發展變化，及時、快速的梳理業務調整範圍，作出對應的改變；

3. 用戶權限管理系統核心難點是前期的産品設計嗎？

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

完結~

本文由 @陽明（劉同） & @雲殊（張俊恒）原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自 unsplash，基于 CC0 協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部