在B端和后臺系統(tǒng)中，經(jīng)常會用到權(quán)限設(shè)計。這篇文章，作者幫我們梳理了權(quán)限系統(tǒng)的類型、模型，希望能幫到大家。

這段時間在梳理公司的角色權(quán)限關(guān)系，為了設(shè)計更加合理，我對角色權(quán)限系統(tǒng)進行系統(tǒng)化的學(xué)習(xí)和整理，以下將我的整理結(jié)果，和大家分享一下。

一、權(quán)限管理概述

權(quán)限管理是所有后臺系統(tǒng)的都會涉及的一個重要組成部分，主要目的是對不同的人訪問資源進行權(quán)限的控制，避免因權(quán)限控制缺失或操作不當(dāng)引發(fā)的風(fēng)險問題，如操作錯誤，隱私數(shù)據(jù)泄露等問題。

在企業(yè)的權(quán)限管理中，通常有兩類權(quán)限，一類是頁面/應(yīng)用的訪問權(quán)限，一類是數(shù)據(jù)權(quán)限

二、權(quán)限控制類型

產(chǎn)品的權(quán)限由頁面、操作和數(shù)據(jù)構(gòu)成，頁面與操作相互關(guān)聯(lián)，必須擁有頁面權(quán)限，才能分配該頁面下對應(yīng)的操作權(quán)限。

其中：

• 頁面權(quán)限指的是可以看到的頁面
• 操作權(quán)限指的是用戶可以進行的操作，例如是否可以新增、刪除、編輯等
• 數(shù)據(jù)權(quán)限指的是可以查看數(shù)據(jù)的范圍。

1. 功能權(quán)限–對象

對象指賦予權(quán)限的人、角色、用戶組、組織、崗位

1）人

某個人擁有某個權(quán)限，在公司規(guī)模比較小的時候，可以簡單設(shè)置哪些人可以看到哪些權(quán)限，維護成本不高；若只綁定人而不綁定角色的弊端：

• 當(dāng)人數(shù)過多時沒有分類，無法快速辨別哪類人擁有權(quán)限；
• 當(dāng)一群人擁有多個模塊的相同權(quán)限時，需要把這群人分別為每個模塊添加權(quán)限，工作量成倍數(shù)增長；
• 當(dāng)創(chuàng)建新用戶時，需要為其增加多個模塊的權(quán)限。

2）角色

當(dāng)公司規(guī)模較多時，有可能一些人控制某個模塊的權(quán)限，這時候就需要引入角色的功能，把這些人綁定到一個角色里，再把角色賦予權(quán)限，這樣就可以清晰的看見模塊權(quán)限對應(yīng)哪些角色，解決用戶數(shù)量大的情況下，用戶分配權(quán)限繁瑣以及用戶—權(quán)限關(guān)系維護成本高的問題，節(jié)省了大量的資源。

3）用戶組

用戶組是將具有相同屬性的用戶組合在一起，用戶組是一群用戶的組合，而角色是用戶和權(quán)限之間的橋梁。

如果一批用戶需要相同的角色，我們也需要逐個為用戶分配角色。

例如，一個公司的客服部門有500多名員工。某一天，研發(fā)部門開發(fā)了一套后臺數(shù)據(jù)查詢產(chǎn)品，所有客服人員都需要使用。然而，由于之前并未統(tǒng)一為所有客服人員分配一個角色，現(xiàn)在需要新增一個角色，將權(quán)限分配給該角色，然后再逐個將角色分配給客服人員。發(fā)現(xiàn)為500名用戶逐個添加角色非常繁瑣。然而，客服人員具有共同屬性，因此我們可以創(chuàng)建一個用戶組，所有客服人員都屬于該客服用戶組，將角色分配給客服用戶組，這樣該用戶組下的所有用戶便擁有了所需權(quán)限。

用戶可以進行分組，這有助于簡化用戶與角色之間的對應(yīng)關(guān)系；用戶可以分組，權(quán)限也可以分組。

在權(quán)限特別繁多的情況下，可以將一個模塊的權(quán)限組合成一個權(quán)限組，這有助于簡化權(quán)限和角色之間的對應(yīng)關(guān)系。

4）組織

每個公司內(nèi)部均構(gòu)建有其獨特的組織架構(gòu)，而在實踐中，權(quán)限分配常常會依據(jù)這一架構(gòu)進行細化劃分。

其原因在于，同一組織單元內(nèi)的成員通常需要執(zhí)行相似的工作職能，因而對權(quán)限的需求大體一致。

遵循公司的組織架構(gòu)，同一組織內(nèi)成員所配備的基礎(chǔ)權(quán)限往往具有較高的一致性。

按照組織架構(gòu)來設(shè)定角色并分配權(quán)限的做法，實際上包括以下兩個優(yōu)勢：

① 實現(xiàn)權(quán)限分配的自動化

實現(xiàn)組織關(guān)系與權(quán)限系統(tǒng)的深度融合后，對于新入職員工，只需將其歸入相應(yīng)的組織單元，其角色權(quán)限便會自動繼承該組織下的所有權(quán)限設(shè)定，無需逐一進行人工分配。

同樣，當(dāng)員工發(fā)生崗位調(diào)動時，僅需對其組織關(guān)系作出相應(yīng)調(diào)整，權(quán)限配置將隨之聯(lián)動更新，全程無須人工介入。

此方案的實施首要前提是實現(xiàn)權(quán)限體系與組織結(jié)構(gòu)間的有效對接。

② 控制數(shù)據(jù)權(quán)限

通過將角色與特定組織緊密關(guān)聯(lián)，確保該組織成員僅能訪問其所屬組織層級內(nèi)的數(shù)據(jù)，各部門成員僅能查看與自身組織直接相關(guān)的數(shù)據(jù)，實現(xiàn)了跨部門數(shù)據(jù)的隔離與保護。

5）崗位

一個組織下面會有很多職位，比如財務(wù)管理會有財務(wù)總監(jiān)、財務(wù)主管、會計、出納員等職位，每個職位需要的權(quán)限是不一樣的，可以像組織那樣根據(jù)職位來分配不同的角色

2. 功能權(quán)限–級別

級別也稱賬號安全級別，一般通過0-100的數(shù)字控制用戶賬號的功能權(quán)限，通常設(shè)置的數(shù)值越大，權(quán)限范圍越大。

適用場景：比如創(chuàng)建的正式員工默認(rèn)安全級別為10，外包員工默認(rèn)為0，則當(dāng)某個功能開放給所有人，并且這個功能僅限正式員工可操作時，可通過限制此功能的安全級別（調(diào)整為10）控制只能正式員工查看。

功能組合：安全級別還可與對象（組織、角色、崗位、人、用戶組）組合，達到更精細化控制權(quán)限的目的，比如安全級別與部門相搭配，可控制此部門下特定的安全范圍的人可以操作功能。

3. 數(shù)據(jù)權(quán)限–時間

權(quán)限中的時間是指數(shù)據(jù)到達某個時間節(jié)點后，是否要繼續(xù)給用戶查看，應(yīng)用場景：比如外部人員需要查看某一年度的數(shù)據(jù)時，只需開放對應(yīng)時間的數(shù)據(jù)給他們，這么做就可以保證數(shù)據(jù)的安全，不會遭到泄露。

4. 數(shù)據(jù)權(quán)限–區(qū)域

權(quán)限中的區(qū)域也可以理解為范圍，是指某一區(qū)間的值，可以對區(qū)域范圍內(nèi)的數(shù)據(jù)進行查看，應(yīng)用場景：比如共享單車的運維人員只需查看他所負(fù)責(zé)的區(qū)域的車輛數(shù)據(jù)即可

三、權(quán)限的擴展功能

1. 菜單權(quán)限

菜單權(quán)限一般分為前端菜單權(quán)限和后端菜單權(quán)限。前端菜單權(quán)限是指用戶層面操作的菜單頁面，后端菜單權(quán)限是指系統(tǒng)管理員、系統(tǒng)運維人員層面操作的菜單頁面。

2. 權(quán)限轉(zhuǎn)移

對于員工從原部門調(diào)走，離職等情況的發(fā)生，當(dāng)有新員工接手他的工作時，則需要權(quán)限轉(zhuǎn)移的功能。

轉(zhuǎn)移的內(nèi)容一般為角色、菜單，更精細化的內(nèi)容還可以分為下屬、待辦、已辦、文檔等，如果是CRM系統(tǒng)，還可以轉(zhuǎn)移他的客戶等。

四、常見的權(quán)限管理模型

1. 基礎(chǔ)權(quán)限管理系統(tǒng)

–簡單清晰但無法承載復(fù)雜的需求

基礎(chǔ)權(quán)限系統(tǒng)的設(shè)計，一般都是從「用戶-權(quán)限」這兩個緯度開始的，管理員需要為每一個用戶單獨定義權(quán)限。

如果系統(tǒng)中用戶數(shù)在幾十個上下，權(quán)限變動也不太多時，這種「用戶-權(quán)限」的權(quán)限管理邏輯簡單清晰，很好用。

但當(dāng)系統(tǒng)中用戶開始增多，到達上千、上萬時，此種管理方法的局限性就暴露出來了：

2. 基于角色概念的權(quán)限設(shè)計–RBAC模型

1）RBAC0

RBAC0是基于角色的訪問控制的完美體現(xiàn)，也就是把權(quán)限賦予角色，然后再把角色賦予用戶，在這個模型中，角色起到了連接用戶和權(quán)限關(guān)系的橋梁作用。

每個角色可以擁有多個權(quán)限，每個用戶可以被分配多個角色，從而使用戶具備多個角色的多個權(quán)限。

在對角色權(quán)限系統(tǒng)進行設(shè)計時，只需給對應(yīng)的角色配置系統(tǒng)中的權(quán)限（菜單/操作/字段），完成角色創(chuàng)建后，再將角色賦予系統(tǒng)用戶即可。

這樣在用戶登錄后，就能獲取該用戶的所屬角色，然后通過角色來找到擁有的權(quán)限，再加載對應(yīng)的權(quán)限資源。

一般來說包含菜單管理、用戶管理、角色管理等功能頁面

菜單管理：對頁面進行配置，與訪問路徑映射，填寫菜單路徑，設(shè)置頁面順序，方便訪問

用戶管理：對用戶進行管理，給用戶賦予角色

角色管理：對角色進行管理，給角色分配權(quán)限

2）RBAC1–引入繼承的概念

如果一個部門人員很多，如一級部門向下還有二級部門，二級部門向下才是員工，這樣就導(dǎo)致如果采用RBAC0模型進行權(quán)限管理的話，則很有可能錯配權(quán)限的問題。

角色繼承的RBAC模型又稱RBAC1模型，在角色繼承的RBAC模型中，上層角色會繼承下層角色的所有權(quán)限，并且可以額外擁有其他權(quán)限。下級角色的權(quán)限上級角色都具備，并且上級角色可以擁有其他權(quán)限

RBAC1模型相較于RBAC0模型增加了角色繼承的概念，有了角色繼承就有父子的關(guān)系，即子角色可擁有父角色的權(quán)限。

在配置角色的時候可以增加父角色的選擇，可在父角色的基礎(chǔ)上進行刪減權(quán)限，以避免錯配權(quán)限的問題。

3）RBAC2–添加責(zé)任分離關(guān)系

RBAC2模型是RBAC0的另一變種，對用戶、角色和權(quán)限三者之間增加了一些限制。這些限制可以分成兩類，即靜態(tài)職責(zé)分離SSD(Static Separation of Duty)和動態(tài)職責(zé)分離DSD(Dynamic Separation of Duty)。

① 靜態(tài)職責(zé)分離

• 互斥角色限制：一個用戶不能同時分配互斥角色中的多個角色，即只能選擇一個。比如如果想擁有審核員的角色就必須先去掉會計的角色。假設(shè)提交角色和審核角色是互質(zhì)的，我們可以用圖形表示：

• 基數(shù)限制：一個用戶擁有的角色是有限的。例如規(guī)定擁有超級管理員角色的用戶只能有1個，用戶被分配的角色數(shù)量，以及角色分配的權(quán)限數(shù)量也可以被限制。

• 先決條件限制：一個用戶想獲得更高級的角色，首先需先擁有低級角色。比如技術(shù)負(fù)責(zé)人角色和普通技術(shù)員工角色存在上下級關(guān)系，因此用戶想要擁有技術(shù)負(fù)責(zé)人角色就必須先擁有普通技術(shù)員工角色。

② 動態(tài)職責(zé)分離

• 動態(tài)限制：一個用戶可以擁有兩個角色，但是運行時只能激活一個角色。

4）RBAC3–基于RBAC0、RBAC1和RBAC2進行整合

3. 數(shù)據(jù)權(quán)限

為了數(shù)據(jù)權(quán)限控制的靈活度，在角色管理中還可以設(shè)置角色的數(shù)據(jù)權(quán)限范圍

作者：諾兒筆記本，公眾號：諾兒筆記本

本文由 @諾兒筆記本 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議。

該文觀點僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。