五大權限系統模型該如何選擇?
文章目錄
- 五大權限系統模型該如何選擇?
- **ACL模型：通路控制清單**
- **DAC模型：自主通路控制**
- **MAC模型：強制通路控制**
- **ABAC模型：基于屬性的通路控制**
- **RBAC，基于角色的權限通路控制**
- **RBAC的深度拓展**
- 1. RBAC0模型
- 2. RBAC1模型
- 3. RBAC2模型
- 4. RBAC3模型
- **RBAC 權限管理的在實際系統中的應用**
- 1.使用者管理
- 2.角色管理
- **1. 自動獲得基礎角色**
- **2. 臨時角色與失效時間**
- **3. 虛拟角色**
- **4. 黑白名單**
- 3. 權限管理
- **1. 頁面/菜單權限**
- **2. 操作權限**
- **3. 資料權限**
- **4. 資料權限如何管控**
- **使用者管理系統權限設計中的更多實踐細節**
- 1.超級管理者
- 2.互斥角色如何處理
- 3.使用者管理權限系統設計一定要簡單清晰
- 4.無權提示頁
- 結語
介紹一下權限系統的設計以及主流的五種權限模型。
權限管控可以通俗的了解為權力限制，即不同的人由于擁有不同權力，他所看到的、能使用的可能不一樣。對應到一個應用系統，其實就是一個使用者可能擁有不同的資料權限（看到的）和操作權限（使用的）。
主流的權限模型主要分為以下五種：
- ACL模型：通路控制清單
- DAC模型：自主通路控制
- MAC模型：強制通路控制
- ABAC模型：基于屬性的通路控制
- RBAC模型：基于角色的權限通路控制
ACL模型：通路控制清單
Access Control List，ACL是最早的、最基本的一種通路控制機制，是基于客體進行控制的模型，在其他模型中也有ACL的身影。為了解決相同權限的使用者挨個配置的問題，後來也采用了使用者組的方式。
原理：每一個客體都有一個清單，清單中記錄的是哪些主體可以對這個客體做哪些行為，非常簡單。
例如：當使用者A要對一篇文章進行編輯時，ACL會先檢查一下文章編輯功能的控制清單中有沒有使用者A，有就可以編輯，無則不能編輯。再例如：不同等級的會員在産品中可使用的功能範圍不同。
缺點：當主體的數量較多時，配置和維護工作就會成本大、易出錯。
DAC模型：自主通路控制
Discretionary Access Control，DAC是ACL的一種拓展。
原理：在ACL模型的基礎上，允許主體可以将自己擁有的權限自主地授予其他主體，是以權限可以任意傳遞。
例如：常見于檔案系統，LINUX，UNIX、WindowsNT版本的作業系統都提供DAC的支援。
缺點：對權限控制比較分散，例如無法簡單地将一組檔案設定統一的權限開放給指定的一群使用者。主體的權限太大，無意間就可能洩露資訊。
MAC模型：強制通路控制
Mandatory Access Control，MAC模型中主要的是雙向驗證機制。常見于機密機構或者其他等級觀念強烈的行業，如軍用和市政安全領域的軟體。關注公衆号：“碼猿技術專欄”，回複關鍵詞：“081“ 擷取阿裡内部的Spring Cloud Alibaba進階教程！
原理：主體有一個權限辨別，客體也有一個權限辨別，而主體能否對該客體進行操作取決于雙方的權限辨別的關系。
例如：将軍分為上将>中将>少将，軍事檔案保密等級分為絕密>機密>秘密，規定不同軍銜僅能通路不同保密等級的檔案，如少将隻能通路秘密檔案；當某一賬号通路某一檔案時，系統會驗證賬号的軍銜，也驗證檔案的保密等級，當軍銜和保密等級相對應時才可以通路。
缺點：控制太嚴格，實作工作量大，缺乏靈活性。
ABAC模型：基于屬性的通路控制
Attribute-Based Access Control，能很好地解決RBAC的缺點，在新增資源時容易維護。
原理：通過動态計算一個或一組屬性是否滿足某種機制來授權，是一種很靈活的權限模型，可以按需實作不同顆粒度的權限控制。
屬性通常有四類：
- 主體屬性，如使用者年齡、性别等；
- 客體屬性，如一篇文章等；
- 環境屬性，即空間限制、時間限制、頻度限制；
- 操作屬性，即行為類型，如讀寫、隻讀等。
例如：早上9:00，11:00期間A、B兩個部門一起以考生的身份考試，下午14:00，17:00期間A、B兩個部門互相閱卷。
缺點：規則複雜，不易看出主體與客體之間的關系，實作非常難，現在應用的很少。
RBAC，基于角色的權限通路控制
Role-Based Access Control，核心在于使用者隻和角色關聯，而角色代表對了權限，是一系列權限的集合。
RBAC三要素：
- 使用者：系統中所有的賬戶
- 角色：一系列權限的集合（如：管理者，開發者，審計管理者等）
- 權限：菜單，按鈕，資料的增删改查等詳細權限。
在RBAC中，權限與角色相關聯，使用者通過成為适當角色的成員而得到這些角色的權限。
角色是為了完成各種工作而創造，使用者則依據它的責任和資格來被指派相應的角色，使用者可以很容易地從一個角色被指派到另一個角色。關注公衆号：“碼猿技術專欄”，回複關鍵詞：“081“ 擷取阿裡内部的Spring Cloud Alibaba進階教程！
角色可依新的需求和系統的合并而賦予新的權限，而權限也可根據需要而從某角色中回收。角色與角色的關系同樣也存在繼承關系防止越權。
優點：便于角色劃分，更靈活的授權管理；最小顆粒度授權；
RBAC的深度拓展
RBAC模型可以分為：RBAC0、RBAC1、RBAC2、RBAC3 四個階段，一般公司使用RBAC0的模型就可以。另外，RBAC0相當于底層邏輯，後三者都是在RBAC0模型上的拔高。
我先簡單介紹下這四個RBAC模型：
1. RBAC0模型
使用者和角色、角色和權限多對多關系。
簡單來說就是一個使用者擁有多個角色，一個角色可以被多個使用者擁有，這是使用者和角色的多對多關系；同樣的，角色和權限也是如此。
RBAC0模型如下圖：沒有畫太多線，但是已經能夠看出多對多關系。
2. RBAC1模型
相對于RBAC0模型，增加了角色分級的邏輯，類似于樹形結構，下一節點繼承上一節點的所有權限，如role1根節點下有role1.1和role1.2兩個子節點
角色分級的邏輯可以有效的規範角色建立（主要得益于權限繼承邏輯），我之前做過BD工具（類CRM），BD之間就有分級（經理、主管、專員），如果采用RBAC0模型做權限系統，我可能需要為經理、主管、專員分别建立一個角色（角色之間權限無繼承性），極有可能出現一個問題，由于權限配置錯誤，主管擁有經理都沒有權限。關注公衆号：“碼猿技術專欄”，回複關鍵詞：“081“ 擷取阿裡内部的Spring Cloud Alibaba進階教程！
而RBAC1模型就很好解決了這個問題，建立完經理角色并配置好權限後，主管角色的權限繼承經理角色的權限，并且支援針對性删減主管權限。
3. RBAC2模型
基于RBAC0模型，對角色增加了更多限制條件。
如角色互斥，比較經典的案例是财務系統中出納不得兼管稽核，那麼在賦予财務系統操作人員角色時，同一個操作員不能同時擁有出納和稽核兩個角色。
如角色數量限制，例如：一個角色專門為公司CEO建立的，最後發現公司有10個人擁有CEO角色，一個公司有10個CEO？這就是對角色數量的限制，它指的是有多少使用者能擁有這個角色。
RBAC2 模型主要是為了增加角色賦予的限制條件，這也符合權限系統的目标：權責明确，系統使用安全、保密。
4. RBAC3模型
同樣是基于RBAC0模型，但是綜合了RBAC1和RBAC2的所有特點
這裡就不在多描述，讀者傳回去看RBAC1和RBAC2模型的描述即可。
RBAC 權限管理的在實際系統中的應用
RBAC 權限模型由三大部分構成，即使用者管理、角色管理、權限管理。
使用者管理按照企業架構或業務線架構來劃分，這些結構本身比較清晰，擴充性和可讀性都非常好。
角色管理一定要在深入了解業務邏輯後再來設計，一般使用各部門真實的角色作為基礎，再根據業務邏輯進行擴充。
權限管理是前兩種管理的再加強，做太細容易太碎片，做太粗又不夠安全，這裡我們需要根據經驗和實際情況來設計。
1.使用者管理
使用者管理中的使用者，是企業裡每一位員工，他們本身就有自己的組織架構，我們可以直接使用企業部門架構或者業務線架構來作為線索，建構使用者管理系統。
需要特殊注意：實際業務中的組織架構可能與企業部門架構、業務線架構不同，需要考慮資料共享機制，一般的做法為授權某個人、某個角色組共享某個組織層級的某個對象組資料。關注公衆号：“碼猿技術專欄”，回複關鍵詞：“081“ 擷取阿裡内部的Spring Cloud Alibaba進階教程！
2.角色管理
在設計系統角色時，我們應該深入了解公司架構、業務架構後，再根據需求設計角色及角色内的等級。
一般角色相對于使用者來說是固定不變的，每個角色都有自己明确的權限和限制，這些權限在系統設計之處就确定了，之後也輕易不會再變動。
1. 自動獲得基礎角色
當員工入職到某部門時，該名員工的賬号應該自動被加入該部門對應的基礎角色中，并擁有對應的基礎權限。這種操作是為了保證系統安全的前提下，減少了管理者大量手動操作。使新入職員工能快速使用系統，提高工作效率。
2. 臨時角色與失效時間
公司業務有時需要外援來支援，他們并不屬于公司員工，也隻是在某個時段在公司做支援。此時我們需要設定臨時角色，來應對這種可能跨多部門協作的臨時員工。
如果公司安全級别較高，此類賬号預設有固定失效時間，到達失效時間需再次稽核才能重新開啟。避免臨時賬号因為流程不完善，遺忘在系統中，引起安全隐患。
3. 虛拟角色
部門角色中的等級，可以授權同等級的員工擁有相同的權限，但某些員工因工作原因，需要調用角色等級之外的權限，相同等級不同員工需要使用的權限還不相同。
這種超出角色等級又合理的權限授予，我們可以設定虛拟角色。這一虛拟角色可內建這一工作所需的所有權限，然後将它賦予具體的員工即可。這樣即不用調整組織架構和對應的角色，也可以滿足工作中特殊情況的權限需求。
4. 黑白名單
白名單：某些使用者自身不擁有某部門的頂級角色，但處于業務需求，需要給他角色外的進階權限，那麼我們可以設計限制範圍的白名單，将需要的使用者添加進去即可。
在安全流程中，我們僅需要對白名單設計安全流程，即可稽核在白名單中的特殊使用者，做到監控擁有特殊權限的使用者，減少安全隐患。
黑名單：比較常見的黑名單場景是某些犯了錯誤的員工，雖然在職，但已經不能給他們任何公司權限了。這種既不能取消角色關聯，也不能完全停用賬号的情況，可以設定黑名單，讓此類使用者可以登入賬号，檢視基本資訊，但大多數關鍵權限已經被黑名單限制。
3. 權限管理
權限管理一般從三個方面來做限制。頁面/菜單權限，操作權限，資料權限。
1. 頁面/菜單權限
對于沒有權限操作的使用者，直接隐藏對應的頁面入口或菜單選項。這種方法簡單快捷直接，對于一些安全不太敏感的權限，使用這種方式非常高效。
2. 操作權限
操作權限通常是指對同一組資料，不同的使用者是否可以增删改查。對某些使用者來說是隻讀浏覽資料，對某些使用者來說是可編輯的資料。
3. 資料權限
對于安全需求高的權限管理，僅從前端限制隐藏菜單，隐藏編輯按鈕是不夠的，還需要在數接口上做限制。如果使用者試圖通過非法手段編輯不屬于自己權限下的資料，伺服器端會識别、記錄并限制通路。
4. 資料權限如何管控
資料權限可以分為行權限和列權限。行權限控制：看多少條資料。列權限控制：看一條資料的多少個字段
簡單系統中可以通過組織架構來管控行權限，按照角色來配置列權限，但是遇到複雜情況，組織架構是承載不了複雜行權限管控，角色也更不能承載列的特殊化展示。
目前行業的做法是提供行列級資料權規則配置，把規則當成類似權限點配置賦予某個角色或者某個使用者。
使用者管理系統權限設計中的更多實踐細節
1.超級管理者
超級管理者是用來啟動系統，配置系統的賬号。這個賬号應該在配置好系統，建立管理者之後被隐藏起來。超級管理者賬号擁有系統中全部權限，可穿梭檢視各部門資料，如果使用不恰當，是系統管理的安全隐患。
2.互斥角色如何處理
當使用者已經有用的角色和即将添加的角色互互相斥時，應該在添加新角色時，提示管理者因角色互斥的原因，無法進行新角色添加。如需添加，要先撤銷掉前一個角色，再添加新角色。
3.使用者管理權限系統設計一定要簡單清晰
在設計權限系統之處，一定要理清思路，一切從簡，能不增加的多餘角色和權限邏輯，就一定不要增加。因為随着公司業務的擴大，權限和角色也會随之增多，如果初期設計思路不嚴謹，那麼權限系統會随着業務的擴大而無限混亂下去，此時再來整理權限，已經太晚了。是以初期設計就一定要條理清晰，簡單明了，能避免後續非常多不必要的麻煩。