淺談許可權管理的設計與實現

dearfulan發表於2020-10-25

一、許可權管理的意義

保證安全：避免誤操作、人為破壞、資料洩露等。
資料隔離：不同的許可權能看到及操作不同的資料，互不干擾。
職責明確：不同角色處理不同事務，細化職責，規範並簡化流程。

二、許可權管理系統的通用設計思路

某個主體（subject也就是使用者） 對某個 客體（object也就是資源） 需要實施某種操作（operation），系統對這種操作的管理控制就是許可權控制。

1. 許可權分類

  • 操作許可權
    API 許可權
    選單許可權
    按鈕許可權
  • 資料許可權

所謂操作許可權就是使用者是否有執行某項操作的許可權，比方說是否可以審批你的考勤，具體表現形式就是使用者是否可以看到某個選單或者按鈕，是否能夠呼叫某個api(eg.對一些涉及使用者資訊的api做使用者的登陸校驗)。

所謂的資料許可權就是使用者是否有對某些資料的訪問許可權，比方說一個日誌選單，普通使用者只能看到自己的操作記錄，管理員就可以看到所有的使用者操作行為，具體表現形式就是當使用者有操作許可權的時候，但不代表其對所有的資料都有檢視或者修改許可權。

2.訪問控制許可權模型

訪問控制許可權模型有：ACL 、DAC、MAC、RBAC、ABAC

2.1 ACL 訪問控制列表

規定資源可以被哪些主體進行哪些操作

ACL， 訪問控制列表，通過訪問控制列表來維護使用者和資源之間的對映關係。在ACL中，包含使用者(User)、資源(Resource)、操作(Operation)三個元素。針對每一項資源，都配置有一個列表，記錄哪些使用者可以對這項資源執行哪些操作。當系統試圖訪問這項資源時，會檢查這個列表中是否有關於當前使用者的操作許可權。如果有，則可以執行操作，否則會被拒絕。

ACL訪問控制列表被廣泛地應用於路由器和三層交換機，它可以根據設定的條件對介面上的資料包進行過濾，允許其通過或丟棄。藉助於訪問控制列表，可以有效地控制使用者對網路的訪問，從而最大程度地保障網路安全。

應用場景: 路由器、防火牆、檔案系統

2.2 DAC 自主訪問控制

DAC規定資源可以被哪些主體進行哪些操作 同時，主體可以將資源、操作的許可權，授予其他主體。

DAC是ACL的一種實現，強調靈活性。純粹的ACL，許可權由中心管理員統一分配，缺乏靈活性。為了加強靈活性，在ACL的基礎上，DAC模型將授權的權力下放，允許擁有許可權的使用者，可以自主地將許可權授予其他使用者。

比如Windows的檔案許可權在這裡插入圖片描述

ACL和DAC最大缺陷都是對許可權控制比較分散，不便於管理，比如無法簡單地將一組檔案設定統一的許可權開放給指定的一群使用者。

2.3.MAC 強制訪問控制

強制訪問控制模型(MAC, Mandatory Access Control),是為了彌補DAC許可權控制過於分散的問題而誕生的。

a. 規定資源可以被哪些類別的主體進行哪些操作
b. 規定主體可以對哪些級別的資源進行哪些操作

當一個使用者執行一個操作時，需要同時滿足a與b，才會被允許操作。

在MAC訪問控制中，主體和資源都被賦予一定的安全級別，使用者不能改變自身和資源的安全級別，只有管理員才能夠確定使用者和組的訪問許可權。和DAC模型不同的是，MAC是一種多級訪問控制策略，它的主要特點是系統對使用者和被訪問資源實行強制訪問控制，系統事先給使用者和資源物件分配不同的安全級別屬性，在實施訪問控制時，系統先對使用者和資源物件的安全級別屬性進行比較，再決定使用者能否訪問該資源。

MAC非常適合機密機構或者其他等級觀念強烈的行業。但對於類似商業服務系統，則因為過重強調保密性，管理不夠靈活而不太適用。

在這裡插入圖片描述

2.4 RBAC 基於角色的訪問控制

下述圖片來自1.3 - What ANSI RBAC is

目前最為常見的許可權設計模型大多都是RBAC模型， 基於角色的訪問控制（Role-Based Access Control)。RBAC模型的基本思路是將訪問許可權分配給一定的角色，使用者通過飾演不同的角色獲得角色所擁有的訪問許可權。

2.4.1.RBAC0

RBAC0是基於角色的訪問控制的基礎模型，它只包含核心的三要素，使用者，角色，許可權。其他的版本都是在 RBAC0 的基礎上進行相應的擴充套件。
在這裡插入圖片描述
每個角色會關聯一系列資源許可權(多對多)，而每個使用者會關聯一些系列角色(多對多)，這樣就可以很方便的控制使用者能夠訪問的資源了

2.4.2.RBAC1

Hierarchical Role，角色繼承。
引入父子角色的概念，所謂的角色繼承就是子角色可選擇繼承父角色的許可權，也就是RBAC1的模型。
在這裡插入圖片描述

2.4.3.RBAC2

Static Separation of Duties 也就是靜態職責分離，用於將使用者的許可權限制在正常範圍內，會在角色分配時應用SSD約束。

因為角色與角色，許可權與許可權之間可能會發生衝突，比如出納和會計， 運動員和裁判。 一個員工是不能既是出納，又是會計， 執行員不能既是執行員，又是裁判。

靜態職責分離是指使用者無法同時被賦予有衝突的角色，避免使用者超出其當前職位合理的許可權等級。簡單地說， 就是避免兩個角色間的衝突。如果員工已經有了出納的角色，那麼在給該員工賦予會計角色時，會提示角色有衝突，無法進行該操作。 也就是說在賦予角色時，會進行校驗。 無論角色之間是否存在繼承關係，都需要進行校驗。
在這裡插入圖片描述

2.4.4.RBAC3

Dynamic Separation of Duties 也就是動態職責分離，強制約束是在任何時間點都可以一起使用的函式。DSD約束可用於在多步驟審批過程中實施嚴格控制。一般在角色啟用時應用DSD約束。
在這裡插入圖片描述
動態職責分離，指相沖突的角色可以同時給一個使用者，但是使用者在一次會話(Session)中，不能同時啟用自身所擁有的，互相沖突的角色，只能選擇其一。

當使用者登入時，或者登入成功後，會讓使用者選擇角色，如使用者選擇了出納的角色。 在執行會話期間，該使用者是無法選擇會計的角色進行操作的，只能先退出，再重新登入。

2.5 ABAC 基於屬性的訪問控制

不同於常見的將使用者通過某種方式關聯到許可權的方式，ABAC則是通過動態計算一個或一組屬性是否滿足某種條件來進行授權判斷。

屬性通常來說分為四類：

  • 使用者屬性（比如使用者名稱稱）
  • 環境屬性（比如當前時間）
  • 操作屬性（比如讀取還是寫入）
  • 物件屬性（又稱資源屬性，比如一篇文章）

ABAC的控制粒度比RBAC更細，理論上能夠實現非常靈活的許可權控制，幾乎能滿足所有型別的需求。

使用者在攜帶自身的屬性值包括主體屬性，資源屬性，環境屬性，然後向資源傳送請求，授權引擎 會根據subject所攜帶的屬性進行判斷，然後會給出拒絕或者同意的結果給使用者，然後就可以訪問資源或者拒絕訪問。

例如規則：“允許所有班主任在上課時間自由進出校門”這條規則，其中，“班主任”是使用者的角色屬性，“上課時間”是環境屬性，“進出”是操作屬性，而“校門”就是物件屬性了。為了實現便捷的規則設定和規則判斷執行，ABAC通常有配置檔案（XML、YAML等）或DSL配合規則解析引擎使用

3. 資料許可權的實現思路

資料許可權是控制使用者可以看到的資料，符合某條件的使用者只能看到該條件下對應的資料資源。

訪問控制許可權是控制使用者能不能訪問某資源
資料許可權是在使用者擁有了訪問控制許可權後，對使用者所訪問的資料按照一定規則，進一步過濾出使用者能看到的資料

常見於需要對某部門或組織等下的使用者做資料可見性控制，如使用者只能檢視其本部門的資料。

常見的解決方案有：

  • 最簡單 :直接在sql程式碼中加入相應的SQL Where條件來過濾，適用於專案不大的場景
  • 攔截業務執行所生成的sql，然後自動拼接資料規則過濾條件，適用於單體應用，在分散式場景下，很難去過濾跨服務呼叫的資料
  • 在Controller層，通過切面的方式，按照給定的資料規則過濾出使用者的可見資料，也就是說先查詢出所有的資料，然後再按照一定規則來過濾可見資料

三、訪問控制許可權的常見解決方案

工作中我們使用的許可權模型主要都是基於 RBAC, 或者在RBAC基礎上進行一個擴充套件，常見的做法是在使用者或資源側新增額外的限制條件

1.標準場景(API、選單、按鈕)

在這裡插入圖片描述
這是最基礎的場景,也就是RBAC0模型。

API的許可權: 對使用者所有的請求都需要先經過API許可權的驗證(可以通過切面或者過濾器實現)
1）先獲取使用者的角色集合A,然後根據請求的API獲取擁有該API許可權的集合B,如果有交集則說明有許可權
2）獲取使用者的角色集合，之後獲取其所有有許可權的API集合A，判斷請求的API是否在集合A中

Menu許可權: 先根據使用者查詢出其角色集合，再獲得其對應的選單列表，組成選單樹，然後返回給前端渲染

按鈕許可權: 根據使用者的角色可以獲取其所有有許可權的按鈕集合B, 在渲染頁面時根據按鈕是否在集合B中決定按鈕是顯示還是隱藏

2.引入組

為了更好地管理使用者，對使用者進行分組歸類，可以引入組的概念。

在實際情況中，我們知道，組也可以具有自己的角色資訊、許可權資訊。比方說QQ使用者群，一個群可以有多個使用者，一個使用者也可以加入多個群。每個群具有自己的許可權資訊。例如檢視群共享。QQ群也可以具有自己的角色資訊，例如普通群、高階群等。
在這裡插入圖片描述
引入組的概念之後，使用者擁有的角色，即為使用者自身所擁有的角色集合與使用者所屬組擁有的角色集合的並集 ，這樣想要給某一使用者組的所有使用者都加上某角色的許可權，只需要給組賦予相應角色就可以了

3. 角色繼承

為了提高授權的便捷性，我們還可以提供角色複製、角色繼承的功能，即角色可以被拷貝、繼承，也就是前面提到的RBAC1的模型。

拷貝的角色可以擁有與被拷貝角色相同的許可權；而對於角色繼承，子角色可繼承父角色的許可權(跟java中的繼承型別)。
在這裡插入圖片描述

4. 引入功能模組

前面的資源分為API, 選單， 按鈕三類；但是很多資源之前都是有關聯性的，可以將關聯的資源聚合成功能模組，更方便我們對資源進行分配
在這裡插入圖片描述
我們可以將選單也視為一種功能模組，也可以將選單單獨授權

5. 多應用授權中心

如果有多個服務都需要設計許可權系統，那麼可以許可權服務獨立出來，讓其為多個應用提供許可權管理

每個需要進行管理的服務都可視為一個應用(Application), 每個應用下可以有各自的使用者、角色、資源，同時一個使用者也可屬於多個應用。

在這裡插入圖片描述
許可權服務不單單可以維護其他應用的許可權，還可以維護許可權服務自身的許可權。

參考資料:
1.3 - What ANSI RBAC is
許可權系統設計模型分析（DAC，MAC，RBAC，ABAC）

相關文章