在許可權系統中,只有RBAC模型嗎?

語言: CN / TW / HK

編輯導語:一般市面上的許可權設計,都會告訴大家RBAC模型,即把許可權系統抽象出來三個實體:使用者、角色、資源,這三個實體之間的關係。那麼,只有RBAC 模型夠用嗎?RBAC 模型的使用場景有哪些?一起來看一下吧。

一、什麼是 RBAC 模型?

市面上有很多許可權系統的設計都會告訴大家 RBAC 的這個模型,無非是說把許可權系統抽象出來三個實體:使用者、角色、資源(許可權的抽象),三個實體的關係如下圖:

也就是說,角色實際上是人和資源的一箇中間橋樑,人通過擁有某個角色而獲得這個角色下面所有的許可權。如下圖:

1. RBAC 模型的優點是什麼?

核心優點無非是當用戶的工作內容發生異動時,只需要將使用者所關聯的角色解綁就可以,而不用把使用者身上的許可權一個一個的刪除掉。

比如當上面的財務總監李總被降職為普通員工時,只需要把他和「財務」這個角色的關係去掉即可,而不需要去將他原來所有的許可權一個一個去掉。

2. 只有 RBAC 夠用嗎?

實際上,僅僅只有 RBAC 模型,只能夠滿足一些很小型企業的訴求,大型企業實際上僅有 RBAC 是完全不夠用的。

如果僅有 RBAC 模型,在大型企業的複雜人員架構和職能裡,就會出現「角色」的膨脹,可能會出現成百上千個角色,這是非常難以管理的。

那要如何規範管理許可權呢?

實際上我們並不是說 RBAC 不行,RBAC 只是一個基礎,在這個基礎之上,我們還應當有一些其他能力,幫助 RBAC 去更好地管控許可權。

3. 場景有哪些?

我們在企業內部做授權時,經常發現很多的授權都是按照使用者的部門或者崗位來授權的。特別是崗位,比如財務經理就有 XXX 許可權,採購經理就有 XXX 許可權。於是乎我們很順其自然地就想到是否給崗位做一個角色呢?

在 RBAC 上再抽象一下,所謂的角色,我們可以理解為它既是使用者的集合,也是許可權的集合。那麼如果僅從使用者的集合來看,能否再抽象得通用一些,不如我們就叫他「使用者集合」吧?

那麼,使用者的集合,在企業內部通常會有哪些呢?相信你很快就會想到「部門」「崗位」「城市」「職級」等等。詳細點說:

OK,當你抽象為使用者集合的時候,你會發現這種使用者集合比原來的角色更好用。原因是它可以和企業的 HR 系統聯動,當一個使用者被調整到另一個部門時,他的使用者集合也會自動被調整,當一個使用者的崗位被調整時,他的使用者集合也會被調整,從而實現與 HR 系統的打通,並且可以減少很多許可權的維護成本。

我們姑且叫這種授權方式為「使用者集合授權」吧。

除此之外,在大型企業裡,我們通常還會有一些比較複雜的場景。比如我們要求崗位是產品經理且職級是 P8 的人才能夠擁有某些許可權。

這種場景沒有辦法按照上面的方式來做使用者集合,比如你不能說職級 P8 的人都擁有某些許可權,崗位是產品經理的人都擁有某些許可權,這兩種「使用者集合授權」都不能滿足這個場景。

我們還可以建立一個動態的、按照規則的使用者集合,這個使用者集合的人是要滿足某些規則才能夠被加進來的。

於是乎,我們發現這個可以定義規則的動態的使用者集合,它非常地健壯,當某個人因工作內容發生異動時,他馬上會被調整出這個使用者集合。也能夠很好地減少授權工作,讓授權跟隨 HR 系統地變更。

我們叫這種授權方式為「動態使用者集合授權」吧!

最後的兩種場景通常是用來兜底的。

比如我們經常會有一些系統管理員,這個系統管理員跟這個人的屬性沒有關係,我們不可能有一個崗位叫做系統管理員,也不會有一個部門叫做系統管理員,於是我們這時候只能老老實實去建一個角色叫做「系統管理員」了。我們就叫這種授權為「角色授權」吧。

我們也經常會遇到一些人他需要臨時開通某些許可權,但這個許可權在正常的情況下他不應該擁有,那麼此時我們可以通過走審批流給這個人授權,但請記住,審批流一定要和許可權系統打通,確保審批流通過後,自動地在許可權系統給這個人授權。同時,還要記得這種臨時授權一定要有許可權期限,到期自動收回!我們就叫這種授權為「臨時授權」吧。

二、總結

上文雖然比較零散,但實際上我是按照從通用 -> 特殊的場景順序來介紹的,總共介紹了 4 種場景,下面給你總結一下這四種情況。

事實上大家會看到,上面這些方法都只是為了讓授權更加簡便而已,本質上還是 RBAC 的模型。原因是當組織大了以後,授權這件事是很繁瑣的,如果不把授權做得更「自動化」一些,那麼許可權系統的管理員可能會累死掉。

實踐中,我們強烈推薦多使用「使用者集合授權」,甚至要求 HR 部門配合我們都是應該的,因為我始終認為 HR 和 HR 系統都應該為業務服務。儘可能少的使用「角色授權」,除非你真的沒有辦法了。

上面這些方式並不一定適合你的公司,如果你有一些關於許可權系統好的實踐方式或者對我的批評指導,可以在評論留言,一起討論。

本文由 @產品經理日常思考 原創釋出於人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基於 CC0 協議