2019/3/10
什麼是RBAC
權限系統通常基於RBAC（Role-Based Access Control）的思想設計，擁有4個關鍵元素：
用戶 – 角色 – 權限 – 資源。
- 資源
被安全管理的對象（Resources頁面、菜單、按鈕、訂單等）
- 權限
訪問和操作資源的許可（Permit刪除、編輯、審批等）
- 角色
我們通過業務流程確定一個角色，實際是確定角色並角色具備的那些權限的過程，角色所以是權限的集合，是眾多權限顆粒組成；
我們通過把權限給這個角色，再把角色給用戶，從而實現用戶的權限，因此它承擔了一個橋樑的作用。
引入角色這個概念，可以幫助我們靈活的擴展，使一個用戶可以具備多種角色。
- 用戶
系統實際的操作員（User）
用戶-角色-權限-資源的關係
【用戶(user：誰)】被賦予【角色(role：具有1-n個權限)】，通過角色關聯的【權限(permit：許可)】去訪問/操作【資源(resource)】
場景：
張三（user）是人事主管（role），可以看到李四的請假申請（resource），並批覆同意（permit）
為什麼需要RBAC
傳統權限模型
傳統權限
傳統模型中無角色概念，用戶直接被賦予權限；
1、導致配置權限相當麻煩
2、無法快速為多個用戶批量刪除/編輯權限
3、用戶多身份下權限配置維護麻煩
用戶—角色—權限多對多的關係，解決了這些問題，權限修改只需對角色的關聯權限進行修改。
若多身份，只需多用戶進行多角色賦予即可。
權限通過角色來賦予至用戶，使得用戶即使發生變更、離職也不會影響權限本身的穩定性。
RBAC Types
RBAC模型可以分為4種類型：
RBAC0/ RBAC1/ RBAC2/ RBAC3
1、2、3種衍生類型均給予RBAC0衍化。
RBAC0
場景：
公司運營時段時間了，形成了不同的部門，每個部門專注於自身的工作內容和客戶，不同身份的員工應當杜絕互相看到或具備干預其他部門的業務情況出現，所以需要對每個員工進行權限的控制。
此場景處理時引入RBAC處理如下：
前提：資源已經被抽象出來，資源關聯的權限已經清晰。
抽象定義階段
1、抽取資源及相關權限
員工管理
查看員工、新增員工、修改員工、刪除員工 … else
客戶管理
查看客戶、新增客戶、修改客戶、刪除客戶 … else
… else
2、定義角色及關聯相關權限
角色定義，一般從崗位進行抽取，或者通過業務流程進行定義。
是指在組織內需要承擔特定的動作或活動，並且可能與其他業務角色有互動的角色。
角色 權限
人事專員 查看員工、新增員工、修改員工、刪除員工 … else
銷售專員 查看客戶、新增客戶、修改客戶、刪除客戶 … else
… else
功能落地階段
1、構建角色
構建角色
2、賦予員工對應角色
角色賦予
RBAC0是RBAC權限模型基礎。
權限設計時將權限賦予給角色，而不是用戶，一個用戶可以擁有若干角色，從而使用戶可以獲得更廣泛的權限。
就此構造成“用戶- 角色- 權限”的授權模型。
在這種模型中，用戶與角色之間，角色與權限之間，一般者是多對多的關係。
角色和權限綁定，用戶被賦予相應的角色，通過多對多的關係來實現授權和授權的快速變更，從而控制用戶對系統的功能使用和數據訪問權限。
多對多關係
在RBAC模型下，我們只需要將組織中的角色進行抽象，例如銷售經理、財務經理、市場經理、市場專員...
然後把權限分配給這些角色，再把角色賦予用戶。
這樣無論是分配權限還是後期進行權限的修改，只需要修改用戶和角色的關係（分配），或角色和權限的關係即可（維護），更加靈活方便。
此外，如果一個用戶有多個角色。
譬如王先生既負責銷售部也負責市場部，那麼可以給王先生賦予兩個角色，即銷售經理和市場經理，這樣他就擁有這兩個角色的所有權限。
RBAC1
場景：
A公司新招很多員工，其中包括很多管理崗位，it部門在位新員工開通賬號時發現，給管理崗位員工進行角色賦予時遇到一個很麻煩的問題，管理崗位不能直接擁有下屬的權限，
比如給銷售經理角色進行分配時，下面的銷售專員，銷售助理等她們的權限銷售經理是不能直接獲得的。
怎樣才能讓銷售經理直接擁有下屬員工的權限呢？
這種情況就適合RBAC1模型，對角色進行繼承。
基於RBAC0模型，引入角色間的繼承關係，即角色上有了上下級的區別；
角色間的繼承關係可分為一般繼承（General）和受限繼承（Limited）。
- 一般繼承關係：
要求角色繼承關係是一個絕對偏序關係，允許角色間的多繼承。
- 受限繼承關係：
進一步要求角色繼承關係是一個樹結構，實現角色間的單繼承。
受限繼承則增強了職責關係的分離
一般繼承和受限繼承的區別，一般繼承是圖；
受限繼承可以有多個父節點，但子節點只能有一個，是一個反向樹結構。
概念圖解：
λ一般繼承關係
行政主管
|
|--------------------|--------------------|
| | |
v v v
行政管理員 行政秘書 行政專員
xx權限 xx權限 xx權限
行政主管權限繼承自行政管理員、行政秘書、行政專員
一般繼承
- 受限繼承關係
受限繼承
角色繼承用來解決組織機構之間的權限關係。
角色繼承的方向和用戶關係的方向時相反的，舉例：
用戶繼承關係–>
業務員 -> 部門經理->總經理
角色繼承關係->
總經理-> 部門經理->業務員
舉例：所有role_Sales（業務員）的權限role_Mgr（部門經理）都具有，那麼即role_Mgr）繼承自role_Sales。
瞭解基本概念後，以上場景解決方案如下：
抽象定義階段
1、抽取業務角色
行政主管、行政專員、行政助理 … else
銷售主管、銷售專員、銷售助理 … else
產品主管、產品專員、產品助理 … else
人力主管、人力專員、人力助理 … else
市場主管、市場專員、市場助理 … else
… else
2、確定角色層級關係
行政主管
|--------------------|--------------------|
v v v
行政專員 行政助理 行政…
… else
3、確定角色與用戶賦予關係
哪些用戶，需要被賦予那些角色。
功能落地階段
1、角色創建/維護
角色構建
2、用戶創建/角色分配
用戶構建
角色管理
角色名稱 繼承角色 生效 操作 更新時間
行政專員 無 是 修改/刪除 Date
行政助理 無 否
行政主管 行政專員、行政助理
xx專員 無 是 修改/刪除 Date
xx助理 無 否
xx主管 xx專員、xx助理
… else
RBAC2
場景：
最近公司議論紛紛，因為一個叫張瑪麗的同事，他是老闆的小姨子，但在公司卻即是會計，還同時是審計，這錢怎麼支出的，合規不合規大家都不知道，財務總監也犯怵，萬一真在錢上出了叉子可怎麼辦？
這種情況就適合RBAC2模型，對角色進行限制。
RBAC2同樣建立在RBAC0基礎之上，僅是對用戶、角色和權限三者之間增加了一些限制，實現了責任分離。
RBAC2約束當角色被賦予給用戶時，或用戶在某一個時刻激活了一個角色時，需要遵循一些強制性的規則。
這些限制可以分成兩類，
即靜態職責分離SSD(Static Separation of Duty)和動態職責分離DSD(Dynamic Separation of Duty)。
約束（Constraining）和 用戶– 角色– 權限一起決定了RBAC2模型下用戶的訪問許可。
- 靜態職責分離（SSD）
當角色授權給用戶時，需要判斷當前用戶是否被賦予了一個與新角色衝突的角色，衝突的角色位一個二元關係，任何一個用戶在此場景下只能擁有其中一個角色。
- 動態職責分離（DSD）
在角色分配時可以將衝突的角色賦予給同一個用戶，但是在用戶使用系統時，一次會話中不能同時激活兩個角色。
舉例（引用）：
在超市POS系統中，楊翠花可以即是收銀員（role_staff），也是收銀主管（role_dire）。
收銀員必須要經過主管才能打開收銀機的抽屜修改某次結算錯誤。
在此場景下，DSD要求用戶必須先放棄收銀員的角色；
即，當發生結算錯誤時，收銀員需要先關閉抽屜，然後再以收銀主管的身份打開抽屜，才可以進行結算糾正相關的處理。
RBAC2對角色的限制有此類：
角色互斥、基數約束、先決條件角色約束、運行時互斥等。
1.角色互斥（SSD）：用戶不能分配到互斥角色集合中的多個，在互斥的角色中只能選擇一個
如：財務當中的會計和審計不能同時被賦予給同一個用戶
2.基數約束（SSD）：一個用戶能夠擁有的角色是有限的，一個角色擁有的權限也是有限的
如：某個角色是為CEO準備的，那就不能有多個
3.先決條件角色（SSD）：用戶想要獲得較高的權限，受限需要獲得低一級的權限
如：有副經理的權限才能有總經理的權限
4.運行時互斥（DSD）：如果用戶同時擁有多個互斥角色，但運行時只能激活其中一個角色
如：想要給自己發工資就需要先放棄自己員工的角色
針對本次場景，解決方案如下：
採用動態責任分離處理互斥角色處理
抽象定義階段
1、抽取業務角色
行政主管、行政專員、行政助理 … else
銷售主管、銷售專員、銷售助理… else
產品主管、產品專員、產品助理 … else
人力主管、人力專員、人力助理 … else
市場主管、市場專員、市場助理 … else
… else
2、確定角色互斥關係
角色名稱 互斥角色集合
會計 審計、出納 … else
3、確定角色與用戶賦予關係
哪些用戶，需要被賦予那些角色。
功能落地階段
1、構建角色
構建角色
2、角色賦予
角色賦予
RBAC3
RBAC3時RBAC1和RBAC2的合集，這種模式即要維護好角色間的繼承關係處理好分層，又要處理角色間的責任分離。
統一模型：
RBAC3 = RBAC1 + RBAC2
權限設計基本的模塊劃分
權限設計基本圍繞權限本身相關資源展開，核心包含用戶、權限、角色等
（簡單作為演示說明，實際根據業務豐富）
用戶管理
用戶為系統使用者，對應實際環境的員工。
用戶的管理包括用戶的構建，刪除，信息修改，激活，禁用，角色授權等。
用戶構建
用戶構建（示意）
如果授權動作叫複雜，內容項較多，用戶構建、用戶角色授權可以分開，上圖僅做示意
No 名稱 工號部門 職位 賬號 角色 狀態 操作
1 楊翠花 10 xx 收銀櫃臺 cuihuayang 收銀員，xxx 激活 xxx/xxx
…
用戶列表（示意）
角色管理
角色構建
角色創建（示意）
編號 角色名稱 狀態 權限 對應用戶 操作
xxx/xxx/xxx xxx/xxx/xxx
角色列表（示意）
權限管理
權限管理從功能操作（頁面+功能）、數據管理兩個不同顆粒度等級來考量的。
權限的抽取可以是開發層面隨著項目的迭代同時進行權限的控制，也可以做成後臺進行統一管理
權限構建
構建權限（示意）
權限名稱 權限類型 權限地址 管理操作
查看付款申請 功能權限 abc/def 編輯/刪除
… else
權限顆粒– 功能菜單權限
粗力度權限控制，獲得當前權限後頁面所有數據可查看或操作
權限顆粒– 功能操作權限
比菜單權限更細化，具象到不同角色即使看到相同數據，所具備的操作管理權限也不一樣
權限顆粒– 數據字段權限
最細顆粒的權限控制，實現了不同角色進入後，看到的數據字段都會不同。
