后臺用戶角色權限系統(tǒng)可以大致分為三十個模塊：用戶管理，角色管理和權限管理。本文作者將描述三個模塊，享受?

I.用戶角色權限系統(tǒng)描述

1. RBAC權限設計模型

（1）RBAC

（基于角色的訪問控制，基于角色的訪問控制），即用戶通過角色和權限與權限相關聯(lián)，以獲得對某些功能的訪問權限。權限授予角色，而不是用戶，但用戶可以擁有多個角色。將角色分配給用戶時，該用戶具有該角色包含的功能權限。簡而言之，用戶有多個角色，每個角色都有多個功能特權。以這種方式，它被構造為“用戶角色許可”的授權模型。在這個模型中，在用戶和角色之間，角色和權限之間，一般是多對多關系。如下圖所示：

2.構建后臺用戶角色權限系統(tǒng)的三個模塊

如上所述，后臺用戶角色許可系統(tǒng)可以總是大致分為三十個模塊：用戶管理，角色管理和權限管理。用戶管理通常由管理部門劃分或由業(yè)務部門劃分。相應部門或組中的用戶具有基本相似的功能要求和權限級別。角色管理相對固定。它通?；跇I(yè)務管理要求。系統(tǒng)中設置的角色標記通常不會隨意更改，更像是用戶組標記;權限管理內容相對更復雜和豐富，主要包括目標，操作和權限權限，當功能授予用戶權限時，相當于授予用戶操作目標功能的權限。

角色特權系統(tǒng)屬于策略設計范圍。它的設計是對PM對業(yè)務的理解以及對后臺所有功能的熟悉程度的測試。在執(zhí)行角色權限系統(tǒng)之前，您必須首先了解后臺的業(yè)務流程和所有功能模塊。如果您不理解，請詢問相關同事，以避免在設計角色權限系統(tǒng)的過程中出現(xiàn)錯誤和邏輯漏洞。

二。用戶角色權限系統(tǒng)構建的三個模塊

1.用戶管理

用戶管理中的用戶主要是功能系統(tǒng)的用戶。這些用戶是個人員工。這些人通常分為兩個維度：行政關系（部門結構）和業(yè)務部門（業(yè)務結構）。用戶管理是這兩個維度中員工之間關聯(lián)的初始分組或分組。在管理部門或業(yè)務部門之后，相應部門或組中的用戶具有基本相似的系統(tǒng)功能使用要求和權限級別;

注意：上圖是根據(jù)管理關系的用戶管理模式

注意：上圖是基于業(yè)務關系的用戶管理模式

2.角色管理

（1）角色管理

角色通常是根據(jù)業(yè)務管理要求在系統(tǒng)中設置的固定標簽。每個角色對應于顯式系統(tǒng)權限。他們擁有的系統(tǒng)權限通常不會隨意更改，并且用戶不會更改角色。添加和刪??除更改比用戶管理更穩(wěn)定;

（2）自動授權：用戶自動輸入角色

如果角色與管理關系下的組織部門具有綁定關系，則如果用戶進入組織部門，則會自動將用戶添加到相應的角色并具有該角色的所有系統(tǒng)特權。如果財務人員[小張]進入財務部門，則用戶可以查看財務數(shù)據(jù)報告和相應的操作權限（例如操作財務審批等），部門員工可以在相應的財務報表系統(tǒng)中查看，而無需額外的授權。 ;

（3）角色授權：用戶被添加到角色

企業(yè)不斷創(chuàng)新和發(fā)展。隨著業(yè)務的發(fā)展，將建立和創(chuàng)建越來越多的新角色。例如，該公司新近推出了企業(yè)集團餐飲項目，項目部門已經(jīng)從各個部門找到了更多。每個員工組成一個項目團隊，項目的業(yè)務權限僅授權員工查看和操作。然后，在這個項目中，將生成一個新的角色，“財務1”，系統(tǒng)管理員將把財務[小張]從財務部門中選擇添加到“財務1”的角色，然后[小張]可以獲得查看企業(yè)集團膳食項目的業(yè)務數(shù)據(jù)報告和操作的權限。通過自動綁定用戶管理關系無法實現(xiàn)此類權限的授予;

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

權限可以是唯一的或繼承的。每個角色都有自己的一組權限。實際上，角色繼承是繼承父角色的權利。一般角色基于繼承其父角色的所有權限而添加一些自己的權限。系統(tǒng)角色繼承通常存在于具有明確用戶層次管理的團隊或公司中;

（5）角色是互斥的：角色中包含的角色是互斥的

角色互斥的業(yè)務背景：由于風險控制需要將業(yè)務流程劃分為多個操作步驟時，有必要為這些不同的步驟授予不同的角色，這些角色需要互斥。例如，在大規(guī)模的財務報銷審批程序中，在財務人員[小張]擁有審批人權限后，不可能批準小張的批準，以免造成財務風險通過大量報銷;

（6）臨時角色

通常為特定組設置臨時角色。例如，如果公司有一個特殊的訪問團隊，則需要為這些特殊客戶提供一些臨時狀態(tài)，以體驗某些功能操作。將這些人添加到部門的組織結構中顯然是不合適的，因為這些人只是臨時安置，而不是企業(yè)員工;其次，這些客戶需要體驗的功能操作通常跨越多個業(yè)務模塊和產(chǎn)品。這條線（更復雜），一般公司沒有現(xiàn)成的固定角色來滿足客戶所需的所有操作權限，因此有必要為這些客戶提供臨時角色，并支持最大的權限空間。臨時角色;

（7）黑白名單

3.權利管理

（1）權力管理

權限管理更關注三種不同的粒度級別：功能菜單，功能操作和數(shù)據(jù)參數(shù)。特定粒度的大小取決于公司的結構和團隊的規(guī)模。如果不需要business屬性來將權限控制到非常精細的級別，則無需將權限的粒度拆分為特定操作或按鈕。畢竟，后端產(chǎn)品的核心是業(yè)務管理平臺，主要目標是協(xié)助業(yè)務的管理和推廣。

注意：屏幕截圖是背景產(chǎn)品的部分屏幕截圖，其中功能菜單頁面，功能操作按鈕和數(shù)據(jù)字段可見。

（2）功能菜單權限

對于后臺產(chǎn)品，功能菜單的用戶權限劃分實際上是一種相對粗略的粒度管理模式。在該模式下，一旦用戶被授權，就可以使用菜單欄下的所有數(shù)據(jù)查看權限和功能操作權限;

（3）功能操作權限

功能操作級別權限比功能菜單更深。在這種情況下，不同角色的用戶可以進入相同的菜單頁面，在后臺查看相同的數(shù)據(jù)字段信息，但他們可以執(zhí)行的功能不同;

（4）數(shù)據(jù)字段權限

數(shù)據(jù)字段級別是更精細的粒度分割，當進入相同的菜單頁面背景時，這將使不同用戶的不同用戶可以看到數(shù)據(jù)字段。例如，當銷售人員進入銷售業(yè)績管理背景時，他可以看到自己的績效改進數(shù)據(jù)，但財務人員會看到業(yè)務工作訂單的費用字段。這些字段存在于一個菜單頁面中，但受不同角色的限制。僅限許可。

案例研究

1.促銷權限系統(tǒng)權限對接

以無權限限制的升級為背景，以訪問用戶角色權限管理系統(tǒng)為例。詳情如下：

注意：以上是產(chǎn)品促銷管理的屏幕截圖

2.之前的促銷背景訪問權限制度

在促銷后臺訪問權限系統(tǒng)之前，幾乎所有系統(tǒng)權限都處于裸奔狀態(tài)，并且所有業(yè)務線成員都可以查看后臺的操作活動內容和操作結果數(shù)據(jù)，并且可以執(zhí)行相對敏感的操作。這種情況顯然存在一定的管理風險，因此后端系統(tǒng)需要對接權限管理系統(tǒng)的系統(tǒng)管理和風險控制;

3.當系統(tǒng)備份促銷時，

在訪問權限管理系統(tǒng)的過程中，促銷需要反匯編功能模塊的權限要素（到一定的粒度），因此有必要根據(jù)業(yè)務特征判斷需要分割的粒度，到功能菜單，功能操作或數(shù)據(jù)。在明確拆分字段級別后，權限管理系統(tǒng)可以根據(jù)粒度授予不同角色的權限;

4.升級后的后臺訪問權限系統(tǒng)

在訪問管理系統(tǒng)進程中訪問促銷活動后，當相應角色的用戶再次登錄后臺時，后臺將首先驗證用戶角色是否具有功能模塊的權限，以及操作權限和角色權限對應的數(shù)據(jù)字段。權限，驗證結果由服務器顯示并顯示給產(chǎn)品側的用戶。此時，同一用戶可以在后臺看到可見和可執(zhí)行的操作，并且訪問權限管理系統(tǒng)可能非常不同，這是由基于用戶角色的權限管理系統(tǒng)帶來的變化。

Q&安培; A

1.用戶具有多個角色。你如何處理多個角色之間的互斥？

如果已將用戶添加到角色作用域，則在向用戶添加與當前角色具有互斥關系的角色時，系統(tǒng)將執(zhí)行互斥判斷，并且后續(xù)角色無法將用戶添加到用戶。成功;

2.如何在業(yè)務開發(fā)過程中確保不同角色之間明確的權限分離？

隨著業(yè)務的快速發(fā)展，不斷增加不同的角色和更多的功能模塊，這些角色與功能權利之間的關系將變得越來越混亂。此時，產(chǎn)品經(jīng)理和業(yè)務方需要及時在一起。對于業(yè)務的發(fā)展，及時，快速地整理業(yè)務調整范圍，并做出相應的變更;

3.用戶權限管理系統(tǒng)的核心難點是前一時期的產(chǎn)品設計嗎？

關于用戶權限管理系統(tǒng)核心最困難的事情不是以前的產(chǎn)品設計，而是后續(xù)的操作和維護，因為特權系統(tǒng)的結構往往不是隨意改變的，而是隨著開發(fā)而快速出現(xiàn)的角色和功能模塊業(yè)務，以防止角色和功能。權限之間的關系變得令人困惑，在創(chuàng)建新角色和分配權限時需要進行清晰而仔細的調整。

成品?

本文最初由@陽明（劉同）& @云殊（張俊恒）。未經(jīng)許可，禁止轉載

該地圖來自unsplash，基于CC0協(xié)議

« 微商“高回贈”隱藏陷阱平臺應加強審核機制 | 華為邁芒7評價：無所畏懼的全面提升 »