編輯導語：一般市面上的權限設計，都會告訴大家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 協議