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

語言: CN / TW / HK

編輯導語:在B端管理系統中,“許可權管理”是必不可少的功能,不同的系統中許可權的應用複雜程度不一樣,要根據實際產品以及需求而設定合理的許可權。本文作者通過介紹RBAC許可權模型的概念,結合實際案例,對B端產品的許可權設計進行了分析,一起來看一下吧。

隨著網際網路的快速發展,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),系統管理員能對整個系統操作維護,也就可以對系統中的所有清單都能操作(增、刪、改、查);假如分配給總部權責管理員的是清單1,那麼他將只能對清單1進行操作(增、改、查);普通使用者也許只有檢視資料的許可權,沒有資料操作的許可權(查),這裡的操作是系統中所有可點選的按鈕許可權操作,列舉的增刪改查只是最常見的幾種操作而已。

六、實戰案例總結

我目前所做的專案是一個關於權責管理平臺的B端系統,關於系統中的許可權需求我這裡簡單的介紹一下,並採用上面所總結的RBAC許可權模型對實際業務需求進行設計分析:

  1. 不同的區域管理員的許可權各不相同 (說明會存在不同的使用者具有不同的許可權,那麼我們就可以採用角色對其進行規範)
  2. 有大量的使用者具有相同的許可權(例如組織、部門等) (說明存在相同許可權的使用者,那麼我們就可以採用使用者組的概念)
  3. 上級管理員擁有下級人員的所有許可權 (說明存在繼承關係)
  4. 不同使用者所看到的資料和能編輯的資料不同,一些機密性的資料只允許部分人員看或者編輯 (說明存在約束)
  5. 會存在臨時性的使用者 (說明需要支援新建新角色)
  6. 同一使用者會存在多個角色 (多角色求合集或者切換使用者角色)

簡單說明一下,我所做這個專案的人員管理是在另外一個系統中管理的,權責平臺只是呼叫另外一個平臺的組織結構樹即可,所以許可權設定模組沒有做人員管理的模組。

根據上面對需求的分析,整個許可權管理模組中我們需要建立使用者組管理模組、功能角色管理模組、業務(資料)管理模組、許可權設定模組,下面就對每個模組做更細緻的頁面展示設計分析。

1. 使用者組管理模組

使用者組管理主要是對具有相同許可權的使用者分類建組,所以頁面中我們需要有新建使用者組的功能,每個使用者組下我們需要關聯對應的組織、部門、崗位、人員,讓這些具有相同許可權的使用者在同一個使用者組下,如下圖:

2. 功能角色管理模組

B端專案中一般會建立幾個預設的角色是不支援使用者修改、刪除的,例如最常見的系統管理員,而也會需要有其它角色的需求,所以此模組需要支援使用者新建角色,功能角色是對大模組的頁面和操作的許可權設定,操作許可權的顆粒度可以細分到每個頁面的每一個按鈕的操作,如下圖:

3. 業務(資料)角色管理模組

業務角色是對頁面中的資料檢視的許可權設定,而對於系統中的普通使用者檢視系統的許可權是常用不變的,所以我們考慮預設有一個普通使用者的角色,其它業務角色使用者根據實際需求情況自行建立即可。

由於我們權責系統的特殊性,我們需要滿足使用者對部分資料可編輯且對部分資料的欄位可編輯,按照常理來說,編輯的操作行為是屬於功能許可權的設定,但是這裡的操作行為是建立在資料的基礎之上的,所以如果把這裡對資料的操作許可權在功能角色模組中設定,就會顯得混亂。

所以我們直接在業務角色模組中加入對資料的可編輯許可權,這裡在設定的時候更方便靈活。

4. 許可權設定模組

許可權設定模組只需要設定許可權分配的物件,選擇對應的使用者或者使用者組,關聯對應的功能角色和業務(資料)角色即可,這樣就形成了一條完整的閉環的許可權設定。

對於06同一使用者會存在多個角色,我們系統是採用切換角色的模式來實現的,因為不同角色中存在互斥的情況,以及所涉及的領域不同,操作許可權差距較大,求合集不利於控制權限,所以只能採用切換的模式實現。

七、總結

許可權設定是B端專案必不可少的模組,也是令設計師頭疼的一件事,但是隻要理清楚實際的業務需求,合理運用RBAC許可權設定的原理,其實也沒那麼難,關於許可權設定的分享就到這來了,希望對處於B端設計的小夥伴有所幫助,也歡迎大家和我一起討論關於設計的有趣事情哦!

本文由 @設計小余 原創釋出於人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基於 CC0 協議