基于策略的動態(tài)角色分配模型及應(yīng)用?

馮 騏 馬晨輝

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

1 引言

在應(yīng)用系統(tǒng)開發(fā)中，訪問控制［1～2］是一個重要的問題，因為不同的用戶可能有不同的權(quán)限和需求。傳統(tǒng)的訪問控制方案通?；诮巧?］，即將用戶分配到不同的角色，然后根據(jù)角色來授予或限制訪問權(quán)限［4］。然而，這種方案存在一些缺點，例如：用戶和角色之間的映射關(guān)系需要預(yù)先定義和同步，這會增加管理成本和同步開銷；應(yīng)用系統(tǒng)無法靈活地自定義角色，而只能使用預(yù)設(shè)定的角色范圍，這會降低應(yīng)用系統(tǒng)的適應(yīng)性和靈活性；用戶和角色之間的映射關(guān)系是靜態(tài)的，無法根據(jù)用戶的上下文或需求進行動態(tài)調(diào)整，這會影響用戶體驗和效率。

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

2 工作介紹

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

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

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

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

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

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

3 基于策略的動態(tài)角色分配模型

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

3.1 模型定義

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

U 是用戶集合，表示所有可能訪問應(yīng)用系統(tǒng)的用戶。R 是角色集合，表示應(yīng)用系統(tǒng)自定義的角色。

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

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

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

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

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

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

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

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

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

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

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

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

3.2 策略匹配算法

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

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

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

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

返回可用角色集合R'。

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

圖1 策略匹配算法

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

圖2 屬性匹配抽象

在數(shù)據(jù)連接層中，我們需要定義用戶相關(guān)屬性對應(yīng)的數(shù)據(jù)獲取方式，一個用戶的屬性可能來自多個數(shù)據(jù)源，不同的數(shù)據(jù)源可能采取不同的連接方式，他們需要抽象為標(biāo)準(zhǔn)的向上接口以供屬性解析層處理。例如一個用戶他輔導(dǎo)員的屬性標(biāo)記可能來自于學(xué)工系統(tǒng)，通過數(shù)據(jù)庫方式連接，而他設(shè)備管理員的屬性標(biāo)記則可能來自于設(shè)備系統(tǒng)，通過API 接口連接，數(shù)據(jù)連接層需要對接不同的數(shù)據(jù)源，并向上屏蔽這些差異。

高職院校沒有系統(tǒng)的科研成果轉(zhuǎn)化管理辦法，激勵政策、考核細(xì)則、收入分配、成果管理制度不健全，所以科研人員意識不到科研成果推廣轉(zhuǎn)化是科研人員必須做、做了就會有收益的工作。高職院校與企業(yè)之間的合作尚處于經(jīng)驗摸索階段，沒有系統(tǒng)的科研成果轉(zhuǎn)化服務(wù)體系，高?？蒲谐晒愕貌坏接行У男麄?，校企之間無法形成良性互動，造成轉(zhuǎn)化率低[5-6]。

在屬性解析層中，將通過數(shù)據(jù)連接層獲取到的數(shù)據(jù)進行解析，并從中提取出我們定義的用戶屬性。用戶的屬性應(yīng)該有一個標(biāo)準(zhǔn)的規(guī)范化定義，并安裝屬性的標(biāo)準(zhǔn)對數(shù)據(jù)進行轉(zhuǎn)換，映射和解析。使得用戶在屬性層面能夠得到統(tǒng)一。

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

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

3.3 算法復(fù)雜度分析

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

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

空間復(fù)雜度分析：算法執(zhí)行過程中需要存儲用戶屬性集合、策略規(guī)則、可用角色集合等數(shù)據(jù)結(jié)構(gòu)，因此空間復(fù)雜度與這些數(shù)據(jù)結(jié)構(gòu)的大小有關(guān)。因此綜合空間復(fù)雜度為O（a+m+k）。

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

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

4 性能評估

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

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

表1 性能測試

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

5 實踐應(yīng)用

本節(jié)介紹了基于策略的動態(tài)角色分配模型在華東師范大學(xué)的數(shù)據(jù)治理平臺中的應(yīng)用，并介紹了應(yīng)用效果和收獲。

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

更為特殊的是，這些權(quán)限結(jié)構(gòu)本質(zhì)上是學(xué)校管理組織架構(gòu)的一種映射，而這種映射關(guān)系并沒有被完全的反饋到線上的身份管理平臺，并非用戶所需要的每個角色都在校級的身份管理中存在對應(yīng)的標(biāo)簽或者屬性。因此在數(shù)據(jù)治理平臺中，提供用戶自定義角色是必須的功能選項。

考慮到學(xué)校的每一個用戶，都存在訪問數(shù)據(jù)治理平臺并獲得一部分?jǐn)?shù)據(jù)查詢的權(quán)限（至少他應(yīng)該可以查詢自己數(shù)據(jù)的權(quán)限），然而實際活躍用戶的規(guī)模與業(yè)務(wù)的數(shù)據(jù)治理狀態(tài)相關(guān)，必然只有一小部分用戶在數(shù)據(jù)治理平臺中處于活躍狀態(tài)，因此同步用戶并靜態(tài)分配角色的方案，在華東師范大學(xué)的數(shù)據(jù)治理平臺中，顯然是很低效的模式。

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

考慮一個面向?qū)W生個人畫像的數(shù)據(jù)應(yīng)用場景，假定權(quán)限需要限定為計算機系的學(xué)生，那我們可以定義一個基于屬性匹配的角色CsStudent，其策略表達式方案為：department=cs AND userType=student。

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

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

圖3 角色查看界面

圖4 角色配置界面

6 結(jié)語

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

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