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

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

一、權限管理概述

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

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

二、權限控制類型

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

B 端产品经理如何快速成长？

产品与业务架构主要是将整个业务工作流进行分层，梳理，然后抽象出一个个需求，将业务需求与产品合情合理的映射起来，最终使业务数据在产品中流动，执行，记录，使用。

查看详情 >

其中：

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

1. 功能權限–對象

對象指賦予權限的人、角色、用戶組、組織、崗位

1）人

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

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

2）角色

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

3）用戶組

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

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

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

用戶可以進行分組，這有助于簡化用戶與角色之間的對應關系；用戶可以分組，權限也可以分組。

在權限特別繁多的情況下，可以將一個模塊的權限組合成一個權限組，這有助于簡化權限和角色之間的對應關系。

4）組織

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

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

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

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

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

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

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

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

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

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

5）崗位

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

2. 功能權限–級別

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

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

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

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

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

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

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

三、權限的擴展功能

1. 菜單權限

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

2. 權限轉(zhuǎn)移

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

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

四、常見的權限管理模型

1. 基礎權限管理系統(tǒng)

–簡單清晰但無法承載復雜的需求

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

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

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

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

2. 基于角色概念的權限設計–RBAC模型

1）RBAC0

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

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

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

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

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

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

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

角色管理：對角色進行管理，給角色分配權限

2）RBAC1–引入繼承的概念

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

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

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

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

3）RBAC2–添加責任分離關系

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

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

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

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

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

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

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

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

3. 數(shù)據(jù)權限

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