基于策略的動態角色分配模型及應用?

馮 騏 馬晨輝

（華東師范大學信息化治理辦公室 上海 200062）

1 引言

在應用系統開發中，訪問控制［1～2］是一個重要的問題，因為不同的用戶可能有不同的權限和需求。傳統的訪問控制方案通常基于角色［3］，即將用戶分配到不同的角色，然后根據角色來授予或限制訪問權限［4］。然而，這種方案存在一些缺點，例如：用戶和角色之間的映射關系需要預先定義和同步，這會增加管理成本和同步開銷；應用系統無法靈活地自定義角色，而只能使用預設定的角色范圍，這會降低應用系統的適應性和靈活性；用戶和角色之間的映射關系是靜態的，無法根據用戶的上下文或需求進行動態調整，這會影響用戶體驗和效率。

為了解決這些問題，本文提出了一種基于策略的動態角色分配模型，它可以實現以下目標：應用系統無需同步用戶，也可以靈活地自定義角色，并通過策略匹配的方式實現動態分配；用戶可以根據自己的上下文或需求選擇合適的角色，并且可以在不同的場景下切換角色；模型具有良好的性能和可擴展性，可以支持大規模的用戶和角色管理；

2 工作介紹

基于角色的訪問控制［5］（RBAC）是一種廣泛使用的訪問控制模型，它將用戶和權限分離，通過角色來中介用戶和權限之間的關系。RBAC 有多種變體，例如RBAC0、RBAC1、RBAC2 和RBAC3。其中，RBAC0 是最基本的模型，它包括用戶、角色、權限和會話四個基本元素，以及用戶-角色賦值（UA）、角色-權限賦值（PA）和用戶會話（US）三個基本關系。RBAC1在RBAC0的基礎上增加了角色繼承（RH）關系，使得角色之間可以形成層次結構。RBAC2 在RBAC0 的基礎上增加了約束（C）元素，使得用戶-角色賦值和角色-權限賦值可以受到一些條件或限制的約束。RBAC3是在RBAC1和RBAC2的基礎上結合了角色繼承和約束兩個特性。

盡管RBAC 有很多優點，例如簡單、靈活、可擴展等，但它也存在一些缺點，例如：用戶和角色之間的映射關系需要預先定義和同步，這會增加管理成本和同步開銷；應用系統無法靈活地自定義角色，而只能使用預設定的角色范圍，這會降低應用系統的適應性和靈活性；用戶和角色之間的映射關系是靜態的，無法根據用戶的上下文或需求進行動態調整，這會影響用戶體驗和效率。

為了解決這些問題，一些研究者提出了基于屬性［6～7］的訪問控制（ABAC），它將用戶、資源、操作和環境［8～9］等因素抽象為屬性［10］，并通過屬性表達式［8］來定義策略。ABAC 有很多優點，例如：無需提前同步用戶，只需在認證時獲取屬性；可以根據用戶或資源或環境［11］等因素的變化動態地評估策略［12～13］等。

然而，ABAC 嚴重的依賴于身份認證提供方所預先建立的屬性標簽，在身份屬性不足以直接覆蓋角色需求時存在一定的局限性。林莉等［14］學者提出可以通過代數表達式的方式進行屬性運算并合成角色，然而代數表達式的形式對于普通用戶而言難以掌握，無法適應多租戶，自服務的應用場景

本文提出了一種基于策略［15］的動態角色分配模型（PDRA），該模型無需同步用戶，也可以靈活地自定義角色，并通過策略匹配的方式實現動態分配。模型通過分類的形式將策略的大類進行固化，從而易于普通用戶理解，并保持良好的擴展性以支持不斷變化的需求。

該模型保持了角色作為抽象層次和管理單元的作用，從而可以兼容現有的基于RBAC［16］的應用系統。模型在華東師范大學的數據治理平臺中進行了應用，并取得了良好的效果。

3 基于策略的動態角色分配模型

本節介紹了基于策略的動態角色分配模型（PDRA），包括模型的定義、策略匹配算法和與RBAC方案的兼容性和擴展性。

3.1 模型定義

基于策略的動態角色分配模型是一個五元組，表示為PDRA=（U，R，P，S，M），其中：

U 是用戶集合，表示所有可能訪問應用系統的用戶。R 是角色集合，表示應用系統自定義的角色。

P 是策略集合，表示應用系統定義的策略。每個策略p ∈P 是一個策略規則，表示用戶滿足該策略規則時可以被分配到某個角色。每個策略規則可以由通過用戶的屬性進行特定的匹配處理。我們認為最基礎的策略規則應該至少包含以下三種：基于列表名單的匹配規則；基于正則表達式的匹配規則；基于用戶屬性［17］的匹配規則等。

S 是會話集合，表示用戶在應用系統中的會話。每個會話s ∈S由一個用戶u ∈U和若干個角色r ∈R 組成，表示用戶u 在會話s 中被分配到若干角色r，一個用戶可能會同時擁有多個角色。

M 是策略匹配函數，表示根據用戶和策略來動態分配角色的函數。M：U×P →R，表示對于任意一個用戶u ∈U 和任意一個策略p ∈P，如果用戶u滿足策略p，則M（u，p）=r，其中r ∈R是與策略p關聯的角色；否則M（u，p）=⊥，表示無法分配角色。

以下是模型的偽代碼示例：

p1：u.name in｛“Alice”，“Bob”｝->r1//列表名單策略規則，如果用戶名在名單｛“Alice”，“Bob”｝內，則分配角色r1

p2：u.department=“sales_*”->r2//屬性匹配策略規則，如果用戶部門的前綴是sales_，則分配角色r2

p3：u.userid regex match“^［0-9］｛8｝$”// 正則表達式策略，如果用戶的ID 符合正則表達式，則分配角色r3

M（u1，p1）=｛r1｝//策略匹配函數，用戶u1 滿足策略p1，因此被分配角色r1

M（u2，p2）=｛r2｝//策略匹配函數，用戶u2 滿足策略p2，因此被分配角色r2

M（u3，p1）=｛r1｝//策略匹配函數，用戶u3 滿足策略p1，因此被分配角色r1

M（u3，p3）=｛r1，r3｝//策略匹配函數，用戶u3滿足策略p3，因此在r1上再被分配角色r3

M（u4，p4）= ⊥//策略匹配函數，用戶u4 不滿足任何策略，因此無法分配角色

3.2 策略匹配算法

為了實現基于策略的動態角色分配模型，我們需要設計一個有效的策略匹配算法。該算法的輸入是一個用戶u 和一組策略P，輸出是一個可用角色集合R'?R。該算法的主要步驟如下：

對于每個策略p ∈P，解析該策略的計算模型，并轉到該計算模型，獲取對應的用戶屬性進行匹配計算；

對于每個策略p ∈P，計算策略規則的真值，并判斷用戶u是否滿足該策略；

對于每個滿足用戶u的策略p ∈P，獲取與之關聯的角色r，并將其加入到可用角色集合R'中。

返回可用角色集合R'。

圖1展示了策略匹配算法的流程。

圖1 策略匹配算法

對于列表名單的匹配策略，是一個標準的搜索問題，通過排序結合二分查找有非常標準化的解決方案。對于正則表達式的匹配策略，也有標準化的解析算法可以直接應用。而屬性匹配規則與之不同，我們需要采取分層抽象的方式，形成可以標準化的解決方案。這其中包含數據連接層，屬性解析層，屬性組合層，策略匹配層四個部分。圖2 展示了屬性匹配的多層抽象方案：

圖2 屬性匹配抽象

在數據連接層中，我們需要定義用戶相關屬性對應的數據獲取方式，一個用戶的屬性可能來自多個數據源，不同的數據源可能采取不同的連接方式，他們需要抽象為標準的向上接口以供屬性解析層處理。例如一個用戶他輔導員的屬性標記可能來自于學工系統，通過數據庫方式連接，而他設備管理員的屬性標記則可能來自于設備系統，通過API 接口連接，數據連接層需要對接不同的數據源，并向上屏蔽這些差異。

高職院校沒有系統的科研成果轉化管理辦法，激勵政策、考核細則、收入分配、成果管理制度不健全，所以科研人員意識不到科研成果推廣轉化是科研人員必須做、做了就會有收益的工作。高職院校與企業之間的合作尚處于經驗摸索階段，沒有系統的科研成果轉化服務體系，高校科研成果便得不到有效的宣傳，校企之間無法形成良性互動，造成轉化率低[5-6]。

在屬性解析層中，將通過數據連接層獲取到的數據進行解析，并從中提取出我們定義的用戶屬性。用戶的屬性應該有一個標準的規范化定義，并安裝屬性的標準對數據進行轉換，映射和解析。使得用戶在屬性層面能夠得到統一。

在屬性組合層中，我們需要支持不同類型的屬性組合計算，例如多個屬性的AND 計算，屬性的模糊匹配計算（*）等。為了簡化用戶使用的理解，我們采取約定大于配置的設計方式，屬性的組合計算采用key-value 方式進行表達，通配符*放置在value 的值中實現模糊查詢。對于計算的連接詞而言，由于多個策略之間采取了OR 的匹配方式，因此對于屬性組合而言，只需要支持AND 一種連接詞即可，OR 連接的需求可以通過多條策略的方式實現。這使得對于終端用戶而言，他只需理解key-value 和通配符*兩個非常容易理解的概念，無需記憶復雜的表達式語法，使得整個項目更容易落地應用。

基于策略的動態角色分配模型完全兼容RBAC 方案，可以成為RBAC 方案的良好擴展機制。這樣可以保持RBAC 方案的優點，例如簡單、靈活、可擴展等，并且可以兼容現有的基于RBAC的應用系統［18］。

3.3 算法復雜度分析

為了評估策略匹配算法的效率，我們需要分析其時間復雜度和空間復雜度，以下假設策略集合的大小為m，角色集合的大小為k，用戶屬性集合的大小為a。

時間復雜度分析：算法的第一步是獲取用戶屬性集合，這需要遍歷用戶屬性集合，因此時間復雜度為O（a）。算法的第二步是解析策略規則，并轉到相應的計算模型，這需要遍歷策略集合P，因此時間復雜度為O（m）。算法的第三步是計算策略規則的真值，并判斷用戶是否滿足策略，這需要遍歷策略集合P 和用戶屬性集合，因此時間復雜度為O（ma）。算法的第四步是獲取滿足用戶的策略關聯的角色，并加入到可用角色集合中，這需要遍歷策略集合P 和角色集合R，因此時間復雜度為O（mk）。算法的第五步是返回可用角色集合，這只需要常數時間，因此時間復雜度為O（1）。因此綜合其時間復雜度為O（a+m+ma+mk+1）。

空間復雜度分析：算法執行過程中需要存儲用戶屬性集合、策略規則、可用角色集合等數據結構，因此空間復雜度與這些數據結構的大小有關。因此綜合空間復雜度為O（a+m+k）。

考慮實際情況下，用戶屬性的集合大小a 和策略集合的大小m都是一個較小的數值，且與角色集合無關。實際業務在運行過程中，用戶屬性集合的大小和策略集合的大小基本保持固定，可以看作常數。

因此我們可以將時間復雜度和空間復雜度均簡化為O（k），即只與角色集合有線性相關。

4 性能評估

本節評估了基于策略的動態角色分配模型的性能，以判斷它在實際生產環境中的可用性。基于3.3 節的復雜度分析，本模型的時間復雜度和空間復雜度均隨著角色的規模而線性增長，因此該方案必須擁有良好的性能以對沖角色規模增長帶來的匹配次數增加所產生的開銷。

我們使用go 語言實現了第3 節的角色分配方案，并通過測試用例驗證了角色分配的有效性。在性能方面，我們通過go 語言的benchmark 工具開展了性能測試，表1 顯示了在AMD Ryzen 5 3600 6-Core Processor 配置下不同角色數量級下對應的性能。

表1 性能測試

可以看到隨著角色數量的規模上升，對應的響應速率，每次響應的內存開銷都對應的線性上升。這說明改算法尚有優化的空間。然而考慮實際的應用場景，1000 個角色數量已經遠遠超出了絕大多數應用系統的角色規模，而在此規模下每秒近400的并發性能，已經足以支撐10萬以上規模用戶的身份認證場景，該并發請求下所消耗的1G 左右的內存，也完全在可接受的范圍之內。而第四節的實踐應用中也驗證了該方案在實踐中的可行性。

5 實踐應用

本節介紹了基于策略的動態角色分配模型在華東師范大學的數據治理平臺中的應用，并介紹了應用效果和收獲。

數據治理是一種高校數字化轉型的核心工作之一，它需要提供數據目錄、數據質量、數據安全等功能。在數據治理平臺中，訪問控制是一個重要的問題，因為不同的用戶可能有不同的權限和需求。例如，例如部門管理員可能只能查看自己部門的數據，而學校管理員可能可以查看所有部門的數據；學工的老師允許查看所有學生的數據，然而輔導員可能只允許查看自己學生的數據；一些用戶可能只能進行數據查詢，而一些用戶可能可以進行數據修改。

更為特殊的是，這些權限結構本質上是學校管理組織架構的一種映射，而這種映射關系并沒有被完全的反饋到線上的身份管理平臺，并非用戶所需要的每個角色都在校級的身份管理中存在對應的標簽或者屬性。因此在數據治理平臺中，提供用戶自定義角色是必須的功能選項。

考慮到學校的每一個用戶，都存在訪問數據治理平臺并獲得一部分數據查詢的權限（至少他應該可以查詢自己數據的權限），然而實際活躍用戶的規模與業務的數據治理狀態相關，必然只有一小部分用戶在數據治理平臺中處于活躍狀態，因此同步用戶并靜態分配角色的方案，在華東師范大學的數據治理平臺中，顯然是很低效的模式。

因此我們采用了基于策略的動態角色分配模型，無需同步用戶，僅在用戶登錄時，動態的根據事先定義好的策略計算角色，然后再通過這些角色進行RBAC的權限控制。

考慮一個面向學生個人畫像的數據應用場景，假定權限需要限定為計算機系的學生，那我們可以定義一個基于屬性匹配的角色CsStudent，其策略表達式方案為：department=cs AND userType=student。

考慮另一個場景，需要維護這個畫像的管理員，他可能是計算機系的某個老師再加上某幾個參與開發的同學，這樣的標簽顯然不可能由學校的身份平臺提供。因此我們可以定義一個基于用戶列表的角色CsStudent-DataManager，其策略表達式為userid in［us-er01，user02，user03］。

考慮整個平臺的靈活性，我們采取了多租戶［19］的模式，允許用戶自定義角色，并允許將定義的角色設置為public 模式公開，從而允許一些通用的角色被整個平臺的用戶復用。圖3和圖4分別展示了數據治理平臺中角色的管理界面和角色策略的配置界面。

圖3 角色查看界面

圖4 角色配置界面

6 結語

本文提出了一種基于策略的動態角色分配模型，使得應用系統無需同步用戶，也可以靈活地自定義角色，并通過策略匹配的方式實現動態分配。本文給出了模型的定義和算法，并評估了模型的性能，并在華東師范大學的數據治理平臺中進行了應用，驗證了該方案的可行性。

此模型還存在一些不足和改進空間，特別是在性能方面目前與角色數量之前還是線性關系，在超大角色數量的規模下性能不佳，是未來需要優化的方向。：