哈嘍小伙伴們 ，今天給大家科普一個小知識。在日常生活中我們或多或少的都會接觸到權限管理系統設計（如何設計一個管理系統）方面的一些說法，有的小伙伴還不是很了解，今天就給大家詳細的介紹一下關于權限管理系統設計（如何設計一個管理系統）的相關內容。

權限管理系統設計（如何設計一個管理系統）

權限管理是所有后臺系統的一個重要組成部分，其目的是控制用戶（User）對資源（Resource）的操作（Action），避免因為權限控制缺失或操作不當引發風險，比如操作失誤，隱私數據泄露等問題。 迄今為止最為普及的權限設計模型是基于角色的訪問控制模型（Role-BasedAccessControl）。它主要是將用戶和用戶組捆綁在一起叫主體，資源和操作捆綁在一起叫權限，中間用角色做橋梁關聯二者。 但近年來隨著對數據管控的精細化，資源和操作的捆綁成為了其掣肘。所以資源也需要像用戶那樣擁有資源組的概念，這樣就變成了用戶/用戶組對資源/資源組有操作權限，這就是基于資源角色的訪問控制模型。 本文將詳細描述基于角色的訪問控制模型到基于資源角色的訪問控制模型的進化過程，并使用強大、高效的開源訪問控制框架 Casbin 來設計一個基于資源角色的訪問控制系統。

(資料圖)

最近在做產品權限模塊的開發，大致的需求如下：

1.系統要有角色的概念，不同的角色有不同的功能權限，并能夠支持用戶自己適配

2.系統能支持公司組織的管理，并能夠支持多個層級（不超過10個）

3.系統能夠支持對單個文件資源的控制，也能支持對多個文件資源的控制。

對于需求 1 和 2，基于角色的訪問控制模型 RBAC 就能夠很好地支持，而對于需求 3，我們對其做了充分的討論，發現了 RBAC 的不足，并對其做了改進升級。

基于角色的訪問控制模型 RBAC 在 20 世紀 90 年代期間被大量的專家學者和研究單位進行了深入的研究，先后提出了很多 RBAC 模型。這些模型主要為了解決這樣一個問題：判斷用戶對資源的操作是否為真。它需要支持三個公認的安全原則：

?最小特權原則：模型分配給用戶的權限不能超過其完成任務的需要即可（通過限制分配給角色權限的多少和大小）

?責任分離原則：同一用戶只能分配到一組互斥角色集合中至多一個角色（通過調用相互獨立互斥的角色來共同完成敏感的任務)

?數據抽象原則：用戶對資源的操作可以抽象，不限于操作系統提供的讀,寫,執行權限（操作支持適配）

1996 年以美國 George Mason 大學信息安全技術實驗室（LIST）提出的 RBAC96 模型最具有系統性，得到了普遍的公認。它是一個模型族，包括了 RBAC0 ~ RBAC3 四個概念模型。

RBAC0 定義了完全支持 RBAC 概念的任何系統的最低需求：用戶，角色，權限。其中用戶和角色是多對多關系，角色和權限也是多對多關系。其 E-R 如下：

用戶是發起操作的主體，比如測試人員，普通人員，管理人員

角色是連接用戶和權限的橋梁。它既關聯了多個權限，也關聯了多個用戶。設計角色的原因是因為很多人的權限是一樣的。如果直接關聯，給 100 個人分配 10 個權限要做 1000 次關聯操作，而使用角色則需要 10（權限-角色） + 100（用戶-角色） 次關聯操作。

權限是資源和操作組合，它的總數是資源數 * 操作數。比如文件 f 可讀，文件 f 可寫，文件 f 可刪。這里的資源包括頁面菜單資源，接口訪問資源和數據資源。

頁面菜單資源 指系統的導航菜單，包括多級菜單

接口訪問資源 指頁面的功能按鈕，包括增，刪，改，查等操作，其對應著后臺接口的訪問。（一般系統會要求“可見即可操作”）

數據資源 指用戶在同一個頁面能看到的數據是不同的，比如采購部只能看采購部上傳的文件，其它部門看各自部門的數據。（一般會把數據資源和具體的組織架構關聯起來）

RBAC1 在 RBAC0 基礎上增加了角色分級的概念， 也就是一個角色可以從另一個角色繼承權限。不過這種權限繼承是一個絕對偏序的關系，也就是樹結構繼承，不能出現閉環。這種設計可以給用戶分組和分層，在一定程度上簡化了權限管理工作。其 E-R 如下：

相較于 RBAC0， 角色表新增了 父節點id 這個屬性來實現角色的權限繼承問題。

RBAC2 在 RBAC0 基礎上增加了角色的約束控制：責任分離，它規定了權限被賦予角色時，角色被賦予用戶時，以及當用戶在某一個時刻激活一個角色時所應遵循的強制性規則。責任分離包括靜態責任分離和動態責任分離。主要包括以下約束：

?互斥角色同一個用戶只能分配到一組互斥角色集合中最多一個角色，支持責任分離原則。互斥角色是指各自權限相互制約的兩個角色。比如財務審計中會計員和審核員的兩個角色，這兩個角色是互斥的，同一個用戶不能同時擁有者兩個角色。

?基數約束一個角色被分配的用戶數量受限，一個用戶所用的角色數目受限，同樣一個角色對應的訪問權限數據也應受限，以控制高級權限在系統中的分配。

?先決條件角色用戶想要獲得上級角色必須先獲得其下一級的角色。

相較于 RBAC0， RBAC2 對角色的創建以及用戶和角色，角色和權限的關聯做了限制。這塊的變動主要是為了規范角色的使用，畢竟實現權限控制可以不用角色：直接讓用戶和權限關聯。使用角色的目的就是為了簡化權限管理工作，但不合理的使用可能使權限管理變得復雜，所以才有了角色的約束控制。這塊的規則對于 E-R 圖沒有任何變動，主要受產品的業務邏輯影響較大。

RBAC3 是在 RBAC0 的基礎上，將 RBAC1 和 RBAC2 進行整合而形成的最全面的權限管理模型。下圖是 RBAC96 模型的示例圖。該圖展示了 RBAC0 - RBAC3 的模型范疇。

在很多的管理系統或者平臺有應用中，我們都會發現在系統中有用戶組這樣用戶集合的概念，比如組織架構，職位。用戶組的出現主要有兩個原因:

?管理方便，減少 admin 的工作量

?用戶集合貼合公司實際情況

第二點比較好理解，畢竟任何公司都有不同的崗位以及它的組織架構。第一點可以這樣理解：當系統中用戶數目和角色數目較多時，很容易出現一部分人擁有相同的權限特性，比如研發部的所有員工，各個分公司的開發人員。如果直接給用戶分配角色，管理員的工作量就會很大（用戶分配多個角色），此時將相同特性的用戶規整到某個用戶組，那么管理員直接給用戶組分配角色，在用戶組的中每個用戶都擁有該角色。這樣用戶加入或退出某用戶組就實現了用戶的角色變更，無需 admin 管理角色。

用戶組是一個比較抽象的概念，它表示用戶的集合，它和權限的關聯還是需要通過角色來實現的。根據是否有上下級關系可以分為兩類：

?具有上下級關系的用戶組： 最典型的例子就是組織架構和職位。

?普通用戶組： 也就是沒有上下級關系。比較典型的就是公司里的虛擬小組和工會小組，它們的特性就是跨部門。虛擬小組是指針對某個項目臨時抽調不同部門的同事構成虛擬的項目小組。工會小組是指公司中通過興趣愛好構建的活動小組，比如籃球小組，羽毛球小組等。

因為組織架構比較常見，所以這里以組織架構為例來構建它的 E-R 圖。

系統中如果同時存在組織架構和職位這樣的設計，可以將二者放在同一張表中，以用戶組類型字段來進行區分。當然如果兩個實體的屬性差異較大時可以分開來建表。此外用戶屬組關系表和用戶組角色關系表是否存在（多對多關系需要，1對多關系可以集成到多的屬性中）看具體的業務需求。推薦使用多對多關系，這樣系統的可擴展性比較好。

?角色和用戶組的異同

用戶組是用戶的集合， 角色是用戶/用戶組與權限的關聯媒介，這是二者最大的差別。在同一個系統中，如果用戶組的權限和成員僅可以被 admin 修改的話，用戶組的機制是非常接近角色的概念。此外角色也可以在用戶組的基礎上實現，這有利于保持系統中的控制關系，此時角色和用戶組是一對一的關系。

?數據權限

博文[1]中提到組織架構的另外一個作用是控制數據權限，把角色關聯到組織，那么該用戶就只能看到該組織下的數據權限。的確，通過角色將組織和權限關聯起來，同一個組織中的用戶可以共享角色，也就意味著可以共享權限（資源+操作），也就意味著可以共享數據資源。這種數據權限的控制是該方案天然自帶的，也就是不管你要不要這種特性，它必然存在。而且如果你想做其它的數據控制，比如標注員對不同用戶組上傳的標注數據有標注的權限，此時只能通過創建新的角色來解決。

RBAC模型能支持資源組的概念么，理論上是不行的。

工作中碰到不少項目，客戶對數據資產的管理要求很嚴格，特別是當下大數據時代，數據湖的概念在業界彌漫。客戶需要的產品能夠支持對數據資產的嚴格把控。這些數據只有個別角色可見，那些數據只有某個特定角色可以修改等等。這里需要注意以下幾點:

?數據資源是用戶產生的，是后天的。與之相反的是頁面菜單和接口訪問，它們是先天的，系統出廠就已經定義好的。

?數據資源理論上是沒有上限的。因為是用戶上傳的，只要硬件支持，理論上數據資源的數目是不受限的。頁面菜單，接口訪問都是有限的。

?數據資源需要支持資源的分頁展示以及基本的字段篩選

從上面的注意點，我們發現 RBAC 模型天然對數據資源的管理比較弱，因為它只能支持最小粒度的資源，無法支持資源組的概念。為什么？因為 RBAC 模型最基本的前提假設是權限是資源和操作的乘積。對于頁面菜單和接口訪問，因為產品出廠即可初始化，而且數目有限，所以和操作的數目乘積也是屈指可數。但是對于數據資源而言，那就很夸張了。而且每增加一個數據資源就需要增加操作個數的權限記錄了，除了創建者對該數據資源進行分配外都需要 admin 來進行權限分配。

RBAC 模型最大的問題是資源和操作的耦合性較高，導致資源組的概念無法加入其中。要想引入資源組，需要重新定義權限和角色。 這里定義權限是個三元組<用戶/用戶組，資源/資源組，操作>，表示用戶或用戶組對資源或資源組的操作。角色屬于用戶組的一種，它和系統先天資源（頁面菜單和接口訪問）相對應，而用戶組（組織架構和職位）和系統后天資源（數據資源）相對應。

TIPS:在該模型中的角色不再是用戶和資源加操作的乘積，而是用戶組的一種，和組織架構，職位是同等地位的，區別在于角色對應系統的先天資源/功能資源，組織架構這些對應系統的后天資源/數據資源。這里角色不再是之前的概念是因為權限三元組已經完全取代了原來舊角色：集合用戶，資源，操作。

這里給出一個實際的應用場景以及對應的 E-R 圖。

上圖的實體表說明：

?用戶表 用戶信息

?角色表 根據系統的功能劃分的用戶集合，比如標注員，審核員等。支持層級

?用戶組表 根據數據的權限劃分的用戶集合，比如組織架構，職位等。這個和角色表有點類似，畢竟都是用戶的集合，只不過劃分的維度不一樣。支持層級

?按鈕表 系統的所有可點的按鈕或鏈接，其包括導航欄，也包括具體按鈕，當然有的按鈕還對應具體的路由請求。

?功能組表 是按鈕的集合，比如對文件的操作會包含增加，刪除，編輯，列表查看，詳情查看等多個按鈕。支持層級

?文件表 用戶上傳的文件，是一種數據資源

?加工表 用戶通過加工文件得到的新的數據資源，比如抽取文件構建圖譜等。

?數據組表 數據資源組表，通過數據組類型進行數據資源區分。支持層級

關系表說明：

?用戶角色表 用戶和角色的關系表

?用戶屬組權限表 用戶和用戶組的關系表

?功能按鈕權限表 功能組表和按鈕表的關系表

?文件組文件權限表 文件組和文件的關系表，該表示文件能夠列表展示的關鍵

?文件組加工權限表 文件組和加工的關系表，該表示加工數據能夠列表展示的關鍵

?角色功能權限表 角色表和功能組表的關系表，通過一定的邏輯可以替代角色按鈕權限表，用戶按鈕權限表，用戶功能權限表。包含操作屬性

?用戶組數據組權限表 用戶組合數據組的關系表，通過一定的邏輯可以替代用戶數據組權限表，用戶文件權限表，用戶組文件權限表，用戶加工權限表，用戶組加工權限表。包含操作屬性

通過上面的 E-R 圖，雖然實現了相應的功能，但是需要創建的關系表太多。有沒有簡單粗暴的解決方案呢？答案就是使用 Casbin。它是一個強大的，高效的開源訪問控制框架，其權限管理機制支持多種訪問控制模型。

為什么 Casbin 能夠實現上面的需求，有以下幾點：

?支持自定義請求的個數，默認請求格式為 {subject, object, action}。這點和我們權限的定義<用戶/用戶組，資源/資源組，操作>不謀而合。

?具有訪問控制模型 model 和策略 policy 兩個核心概念。從 RBAC3 中加入用戶組，再試圖加入數據組，可見 E-R圖的變動是很夸張的，而 Casbin 天然支持多 model。

?支持 RBAC 中多層角色繼承，不止主題可以有角色，資源也可以有角色。這里的角色就是組的概念，和上面的設計類似，不過上面做了更細的劃分。

?不支持用戶列表和角色列表的管理，只存儲用戶和角色的映射關系。Casbin 的權限表是用來取代關系表的。如果用戶和角色不是很多（萬級別以上）可以直接搜數據庫， 如果記錄數很多可以像文件組文件權限表那樣增加關系表。

下圖給出了上面的樣例 E-R 圖如何轉變成使用 Casbin 來構建表結構，并能夠支持上述需求的。這里需要注意的是文件組文件關系表和加工組加工關系表是保留的。保留的原因是文件表和加工表的記錄數很大（萬級別以上），如果單純的使用g2規則的話， casbin規則表會增加很多條記錄（萬級別以上）。

對比 E-R 圖的前后變化，發現基于 Casbin 實現的資源角色管理模型將很多用戶和資源的關系表轉換成 g 規則和 g2 規則，將很多權限表變成 p 規則。從而大大縮減表結構。此外因為 casbin 規則表都會加載進內存，所以它判定用戶對資源有沒有相應的操作權限很快。而該表的記錄數在合理的設計下基本會成線性增長。而每條記錄的長度基本可以保持一定長度不變（不存儲詳細信息，只標識唯一id）。

1.RBAC用戶、角色、權限、組設計方案[2]

2.可能是史上最全的權限系統設計[3]

3.rbac96模型ppt[4]

4.casbin官網[5]

[1] 博文:https://zhuanlan.zhihu.com/p/87009472[2] RBAC用戶、角色、權限、組設計方案:https://zhuanlan.zhihu.com/p/63769951[3] 可能是史上最全的權限系統設計:https://zhuanlan.zhihu.com/p/87009472[4] rbac96模型ppt:https://profsandhu.com/cs6393_s12/lecture-rbac96.pdf[5] casbin官網:https://casbin.org/docs/zh-CN/overview