當前位置:首頁 » 文件傳輸 » rbac基於資源的訪問控制
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

rbac基於資源的訪問控制

發布時間: 2023-08-07 00:17:30

1. B端產品之許可權設計(RBAC許可權模型)

一、前言

隨著互聯網的快速發展,B端行業也逐漸崛起,很多企業管理中使用的軟體我們通常稱其為B端管理系統,而在B端系統中「許可權管理」是必不可少的功能,不同的系統中許可權的應用復雜程度不一樣,都是根據實際產品以及需求情況而設置合理的許可權。而我們現在對於許可權的設置基本上都是建立在RBAC許可權模型上的、擴展的,下面我會通過介紹RBAC許可權模型的概念以及結合實際業務情況列舉許可權設置的應用。

二、什麼是RBAC許可權模型?

RBAC是Role-BasedAccess Control的英文縮寫,意思是基於角色的訪問控制。RBAC認為許可權授權實際上是Who、What、How的問題。在RBAC模型中,who、what、how構成了訪問許可權三元組,也就是「Who對What進行How的操作,也就是「主體」對「客體」的操作。其中who是許可權的擁有者或主體(例如:User、Role),what是資源或對象(Resource、Class)。

簡單的理解其理念就是將「角色」這個概念賦予用戶,在系統中用戶與許可權之間通過角色進行關聯,以這樣的方法來實現靈活配置。

RBAC其實是一種分析模型,主要分為:基本模型RBAC0、角色分層模型RBAC1、角色限制模型RBAC2和統一模型RBAC3。

RBAC許可權模型是基於角色的許可權控制。模型中有幾個關鍵的術語:

用戶:系統介面及訪問的操作者

許可權:能夠訪問某介面或者做某操作的授權資格

角色:具有一類相同操作許可權的用戶的總稱

1)RBAC0

RBAC0是RBAC許可權模型的核心思想,RBAC1、RBAC2、RBAC3都是在RBAC0上進行擴展的。RBAC0是由四部分構成:用戶、角色、會話、許可。用戶和角色的含義很簡單,通過字面意思即可明白,會話:指用戶被賦予角色的過程,稱之為會話或者是說激活角色;許可: 就是角色擁有的許可權(操作和和被控制的對象),簡單的說就是用戶可使用的功能或者可查看的數據。

用戶與角色是多對多的關系,用戶與會話是一對一的關系,會話與角色是一對多的關系,角色與許可是多對多的關系。

2)RBAC1

RBAC1是在RBAC0許可權模型的基礎上,在角色中加入了繼承的概念,添加了繼承發的概念後,角色就有了上下級或者等級關系。

舉例:集團權責清單下包含的角色有:系統管理員、總部權責管理員、區域權責管理員、普通用戶,當管理方式向下兼容時,就可以採用RBAC1的繼承關系來實現許可權的設置。上層角色擁有下層的所有角色的許可權,且上層角色可擁有額外的許可權

3)RBAC2

RBAC2是在RBAC0許可權模型的基礎上,在用戶和角色以及會話和角色之間分別加入了約束的概念(職責分離),職責分離指的是同一個人不能擁有兩種特定的許可權(例如財務部的納入和支出,或者運動員和裁判員等等)。

用戶和角色的約束有以下幾種形式:

互斥角色:同一個用戶在兩個互斥角色中只能選擇一個(也會存在一個用戶擁有多個角色情況,但是需要通過切換用戶角色來實現對不同業務操作)

基數約束:一個用戶擁有的角色是有限的,一個角色擁有的許可也是有限的

先決條件約束:用戶想要獲得高級角色,首先必須擁有低級角色

會話和角色之間的約束,可以動態的約束用戶擁有的角色,例如一個用戶可以擁有兩個角色,但是運行時只能激活一個角色。

例如:iconfont和藍湖的用戶與角色就採用了約束的概念,超級管理員只允許只有一個

4)RBAC3

RBAC3是RBAC1與RBAC2的合集,所以RBAC3包含繼承和約束。

二、為什麼要引用RBAC許可權模型?

RBAC中具有角色的概念,如果沒有角色這個概念,那麼在系統中,每個用戶都需要單獨設置許可權,而系統中所涉及到的功能許可權和數據許可權都非常多,每個用戶都單獨設置許可權對於維護許可權的管理員來說無疑是一件繁瑣且工作量巨大的任務。

而引入角色這個概念後,我們只需要給系統設置不同的角色, 給角色賦予許可權,再將用戶與角色關聯,這樣用戶所關聯的角色就直接擁有了該角色下的所有許可權。

例如:用戶1~用戶8分別擁有以下許可權,,不同用戶具有相同許可權的我用不同的顏色做了區分,如下圖:

在沒有引入RBAC許可權模型的情況下,用戶與許可權的關系圖可採用下圖的楊叔叔展示,每個用戶分別設置對應的許可權,即便是具有相同許可權的用戶也需要多次設置許可權。

引入RBAC許可權模型及引入了角色的概念,根據上面表格的統計,用戶1、用戶3、用戶5、用戶8擁有的許可權相同,用戶2、用戶6、用戶7擁有相同的許可權,用戶4是獨立的許可權,所以我們這里可以根據數據統計,以及實際的需求情況,可以建立三個不同的角色,角色A、角色B、角色C,三個角色分別對應三組用戶不同的許可權,如下圖所示:

對應的上面的案例表格我們就可以調整為含有角色列的數據表,這樣便可以清楚的知道每個用戶所對應的角色及許可權。

通過引用RBAC許可權模型後,對於系統中大量的用戶的許可權設置可以更好的建立管理,角色的引入讓具有相同許可權的用戶可以統一關聯到相同的的角色中,這樣只需要在系統中設置一次角色的許可權,後續的用戶便可以直接關聯這些角色,這樣就省去了重復設置許可權的過程,對於大型平台的應用上,用戶的數量成千上萬,這樣就可避免在設置許可權這項工作上浪費大量的時間。

三、引入用戶組的概念

我們依舊拿上面表格案例舉例,雖然前面我們應用的RBAC許可權模型的概念,但是對於大量用戶擁有相同許可權的用戶,我們同樣的也需要對每個用戶設置對應的角色,如果一個部門上萬人,那麼我們就需要給這個部門上萬人分別設置角色,而這上萬其實是具有相同的許可權的,如果直接採用基礎的RBAC許可權模型的話,那麼面對這樣的情況,無疑也是具有一個龐大的重復的工作量,並且也不利於後期用戶變更的維護管理,那麼針對相同用戶具有相同的許可權的情況,我們便可以引入用戶組的概念。

什麼是用戶組呢? 用戶組:把具有相同角色的用戶進行分類。

上面我們的數據表格案例中的用戶1、用戶3、用戶5、用戶8具有相同的角色A,用戶2、用戶6、用戶7也擁有相同的角色B,那麼我們就可以將這些具有相同角色的用戶建立用戶組的關系,拿上面的案例,我們分別對相同角色的用戶建立組關系,如下:

用戶1、用戶3、用戶5、用戶8→建立用戶組1

用戶2、用戶6、用戶7→建立用戶組2

因為用戶4隻有一個用戶,所以直接還是單獨建立用戶與角色的關系,不需要建立用戶組,當然盡管只有一個用戶也是可以建立用戶組的關系,這樣有利於後期其他用戶與用於4具有相同的角色時,就可以直接將其他用戶添加到這個用戶組下即可,根據業務的實際情況而選擇適合的方案即可。

通過案例表格的變化我們就可以直觀的看出許可權設置變得清晰簡潔了,通過第用戶組賦予角色,可以減少大量的重復的工作,我們常見的企業組織、部門下經常會出現不同用戶具有相同角色的情況,所以採用用戶組的方式,便可以很好的解決這個問題,給具有相同許可權的用戶建立用戶組,將用戶組關聯到對應的角色下,此用戶組就擁有了此角色下的所有許可權,而用戶是屬於用戶組的,所以用戶組下的所有用戶也就同樣的擁有了此角色下的所有許可權。一個用戶可以屬於多個用戶組,一個用戶組也可以包括多個用戶,所以用戶與用戶組是多對多的關系。

四、引入許可權組的概念

許可權組與用戶組的原理差不多,是將一些相對固定的功能或者許可權建立組的關系,然後再給此許可權組賦予角色,目前我所接觸的B端項目中使用許可權組的概念的比較少,可簡單的看一下關系圖

四、功能許可權和數據許可權

B端系統中一般產品的許可權由頁面、操作和數據構成。頁面與操作相互關聯,必須擁有頁面許可權,才能分配該頁面下對應的操作許可權,數據可被增刪改查。所以將許可權管理分為 功能許可權管理和數據許可權管理。

功能許可權管理:指的是用戶可看到那些模塊,能操作那些按鈕,因為企業中的用戶擁有不同的角色,擁有的職責也是不同的。

數據許可權管理:指的是用戶可看到哪些模塊的哪些數據。

例如:一個系統中包含多個權責清單(清單1、清單2、清單3),系統管理員能對整個系統操作維護。。。。。

完整內容請查看公眾號原文鏈接

原文鏈接:B端產品之許可權設計(RBAC許可權模型)

來源公眾號《設計小余》