1. RBAC 模型是什么

RBAC（Role-Based Access Control）即：基于角色的權限控制。通過角色關聯用戶，角色關聯權限的方式間接賦予用戶權限。
RBAC 模型由 4 個基礎模型組成：

1. 基本模型 RBAC0（Core RBAC）
2. 角色分層模型 RBAC1（Hierarchal RBAC）
3. 角色限制模型 RBAC2（Constraint RBAC）
4. 統一模型 RBAC3（Combines RBAC）
   RBAC 授權的過程可以抽象概括為：判斷 Who 是否可以對 What 進行 How 的訪問操作，以及這個邏輯表達式的值是否為 True 的計算過程。
   Who、What、How 構成了訪問權限三元組，Who 是權限的擁有者或主體（User、Role），What 是資源（Resource），How 是具體的權限。
   

1.1. 基本模型 RBAC0

RBAC0 是最基礎也是最核心的模型，由五部分組成：用戶（User）、角色（Role）、許可（Permission）、會話（Session）、操作（operations OPS）。

角色通過權限（許可）被授權資源，角色又授權到用戶身上，通過會話管理用戶和角色的授權關系，用戶就繼承了角色的訪問資源權限。
我們舉一個很簡單的例子，例如：張三是一家企業的財務總監，同時他也是該企業對外的形象大使，財務總監有訪問公司財務數據的權限，形象大使有訪問公司市場部推廣計劃和編輯發言稿的權限。那么張三既有訪問公司財務數據的權限，又有訪問公司市場部推廣計劃和編輯發言稿的權限。突然有一天公司決定做職位調整，張三被任命為財務總監和人力資源總監，撤掉了形象大使。那么張三當前就只能訪問財務總監和人力資源總監所對應的授權資源。

1.2. 角色分層模型 RBAC1

該模型主要是在 RBAC0 的基礎上，增加了角色層級關系的繼承邏輯，也就是說角色有了組織樹的邏輯。

角色有了上下級關系，上一級的角色可以繼承其下所有角色的授權資源。
再比如張三是一家企業的財務總監，同時他也是該企業對外的形象大使，財務總監有訪問公司財務數據的權限，形象大使有訪問公司市場部推廣計劃和編輯發言稿的權限。那么他的上級領導，比如是該公司的 CFO，既有訪問公司財務數據的權限，又有訪問公司市場部推廣計劃和編輯發言稿的權限。這是繼承關系。

1.3. 角色限制模型 RBAC2

該模型主要添加了授權約束。約束規定了權限被賦予角色時，或角色被賦予用戶時，以及當用戶在某一時刻激活一個角色時所應遵循的強制性規則。
責任分離包括：靜態責任分離（SSD）和動態責任分離（DSD）。

SSD 是用戶和角色的指派階段加入的，主要是對用戶和角色有如下約束:

1. 角色互斥：同一個用戶在兩個互斥角色中只能選擇一個。比如財務部有會計和審核員兩個角色，他們是互斥角色，那么用戶不能同時擁有這兩個角色，體現了職責分離原則。
2. 基數約束：一個角色被分配的用戶數量受限，一個用戶可擁有的角色數目受限，同樣一個角色對應的訪問資源權限數目也受限，以控制高級權限在系統中的分配。比如李四是 COO，王五不能也是 COO。同樣的李四不能既是 COO 又是 CTO 又是 CFO。COO 、CTO、 CFO 三個角色所能訪問的資源權限也不能是一模一樣的。
3. 先決條件約束：用戶想要獲得高級角色，首先必須擁有低級角色。
   DSD 是會話和角色之間的約束，可以動態的約束用戶擁有的角色，也叫運行時互斥。如一個用戶可以擁有兩個角色，但是運行時只能激活一個角色。如一個人如果既是運動員又是教練，當比賽開始的時候，只能選擇一個角色身份入場。

1.4. 統一模型 RBAC3

RBAC3 是 RBAC1 與 RBAC2 的合集，所以 RBAC3 是既有角色分層又有約束的一種綜合授權模型了。

2. 什么是權限

權限是資源的集合，這里的資源指的是軟件中所有的內容，包括模塊、菜單、頁面、字段、操作功能（增刪改查）等等。具體的權限配置上，目前形式多種多樣，按照我個人的理解，可以將權限分為：頁面權限、操作權限和數據權限。

2.1. 頁面權限

所有系統都是由一個個的頁面組成，頁面再組成模塊，用戶是否能看到這個頁面的菜單、是否能進入這個頁面就稱為頁面權限。

客戶列表、客戶黑名單、客戶審批頁面組成了客戶管理這個模塊。對于普通用戶，不能進行審批操作，即無客戶審批頁面權限，在他的賬號登錄后側邊導航欄只顯示客戶列表、客戶黑名單兩個菜單。

2.2. 操作權限

用戶凡是在操作系統中的任何動作、交互都是操作權限，如增刪改查等。

2.3. 數據權限

數據權限是指在一個系統，對于不同的用戶或用戶組，授予不同的數據訪問權限的過程。
這里的數據權限包含菜單、頁面以及字段等。這些權限可以限制用戶可以訪問哪些數據、以及他們可以對這些數據進行哪些操作。數據權限的目的是確保數據的安全性和保密性，同時也可以提高數據的可用性和可靠性。
簡單舉個例子：某系統中有銷售部門，銷售專員負責推銷商品，銷售主管負責管理銷售專員日常工作，經理負責組織管理銷售主管作業。

按照實際理解，“銷售專員張三”登錄時，只能看到自己負責的數據；銷售主管2登錄時，能看到他所領導的所有業務員負責的數據，但看不到其他團隊業務員負責的數據。
換另外一句話就是：我的客戶只有我和我的直屬上級以及直屬上級的領導能看到，這就是我理解的數據權限。
要實現數據權限有多種方式：

1. 可以利用RBAC1模型，通過角色分級來實現。
2. 在‘用戶-角色-權限’的基礎上，增加用戶與組織的關聯關系，用組織決定用戶的數據權限。
   具體如何做呢？
3. 組織層級劃分
   
4. 數據可視權限規則制定
   上級組織只能看到下級組織員工負責的數據，而不能看到其他平級組織及其下級組織的員工數據等。
   通過以上兩點，系統就可以在用戶登錄時，自動判斷要給用戶展示哪些數據了。

3. RBAC 設計實現

3.1. 用戶-角色-權限

最簡單的用戶、角色、權限（許可）模型。這里面又包含了2種：

1. 用戶和角色是多對一關系，即：一個用戶只充當一種角色，一種角色可以有多個用戶擔當。
2. 用戶和角色是多對多關系，即：一個用戶可同時充當多種角色，一種角色可以有多個用戶擔當。
   那么，什么時候該使用多對一的權限體系，什么時候又該使用多對多的權限體系呢？
   如果系統功能比較單一，使用人員較少，崗位權限相對清晰且確保不會出現兼崗的情況，此時可以考慮用多對一的權限體系。
   其余情況盡量使用多對多的權限體系，保證系統的可擴展性。如：張三既是行政，也負責財務工作，那張三就同時擁有行政和財務兩個角色的權限。

3.2. 用戶-組織-角色-權限

在“用戶-角色-權限”的基礎上，增加了用戶與組織的關聯關系，組織決定了用戶的數據范圍的權限。

系統都有數據私密性的要求：哪些用戶可以看到哪些數據，哪些用戶不可以看到哪些數據。這個時候，我們需要從組織結構出發思考，數據范圍權限其實是角色權限的重要屬性，但是由于數據范圍太靈活，如果加入“數據權限”，如果賬號下的數據量較大，用戶編輯數據權限的操作會很繁瑣。因此現在主流的后臺設計都會使用“組織結構”來對應數據權限。

常用數據范圍設置：全部數據權限、自定數據權限、本部門數據權限、本部門及以下數據權限、僅本人數據權限。

3.3. 用戶-組織-崗位-角色-權限

在第二種權限體系上進行優化的，增加了用戶與崗位的關聯關系

4. 組織結構數據庫存儲

https://blog.csdn.net/tongluren381/article/details/114874080

參考：
https://www.zhihu.com/question/428429216
https://www.woshipm.com/pd/1150093.html
https://blog.csdn.net/hao2713636/article/details/132326046