編輯導(dǎo)語：一般市面上的權(quán)限設(shè)計，都會告訴大家RBAC模型，即把權(quán)限系統(tǒng)抽象出來三個實體：用戶、角色、資源，這三個實體之間的關(guān)系。那么，只有RBAC 模型夠用嗎？RBAC 模型的使用場景有哪些？一起來看一下吧。

一、什么是 RBAC 模型？

市面上有很多權(quán)限系統(tǒng)的設(shè)計都會告訴大家 RBAC 的這個模型，無非是說把權(quán)限系統(tǒng)抽象出來三個實體：用戶、角色、資源（權(quán)限的抽象），三個實體的關(guān)系如下圖：

也就是說，角色實際上是人和資源的一個中間橋梁，人通過擁有某個角色而獲得這個角色下面所有的權(quán)限。如下圖：

1. RBAC 模型的優(yōu)點是什么？

核心優(yōu)點無非是當(dāng)用戶的工作內(nèi)容發(fā)生異動時，只需要將用戶所關(guān)聯(lián)的角色解綁就可以，而不用把用戶身上的權(quán)限一個一個的刪除掉。

比如當(dāng)上面的財務(wù)總監(jiān)李總被降職為普通員工時，只需要把他和「財務(wù)」這個角色的關(guān)系去掉即可，而不需要去將他原來所有的權(quán)限一個一個去掉。

2. 只有 RBAC 夠用嗎？

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

如果僅有 RBAC 模型，在大型企業(yè)的復(fù)雜人員架構(gòu)和職能里，就會出現(xiàn)「角色」的膨脹，可能會出現(xiàn)成百上千個角色，這是非常難以管理的。

那要如何規(guī)范管理權(quán)限呢？

實際上我們并不是說 RBAC 不行，RBAC 只是一個基礎(chǔ)，在這個基礎(chǔ)之上，我們還應(yīng)當(dāng)有一些其他能力，幫助 RBAC 去更好地管控權(quán)限。

3. 場景有哪些？

我們在企業(yè)內(nèi)部做授權(quán)時，經(jīng)常發(fā)現(xiàn)很多的授權(quán)都是按照用戶的部門或者崗位來授權(quán)的。特別是崗位，比如財務(wù)經(jīng)理就有 XXX 權(quán)限，采購經(jīng)理就有 XXX 權(quán)限。于是乎我們很順其自然地就想到是否給崗位做一個角色呢？

在 RBAC 上再抽象一下，所謂的角色，我們可以理解為它既是用戶的集合，也是權(quán)限的集合。那么如果僅從用戶的集合來看，能否再抽象得通用一些，不如我們就叫他「用戶集合」吧？

那么，用戶的集合，在企業(yè)內(nèi)部通常會有哪些呢？相信你很快就會想到「部門」「崗位」「城市」「職級」等等。詳細(xì)點說：

OK，當(dāng)你抽象為用戶集合的時候，你會發(fā)現(xiàn)這種用戶集合比原來的角色更好用。原因是它可以和企業(yè)的 HR 系統(tǒng)聯(lián)動，當(dāng)一個用戶被調(diào)整到另一個部門時，他的用戶集合也會自動被調(diào)整，當(dāng)一個用戶的崗位被調(diào)整時，他的用戶集合也會被調(diào)整，從而實現(xiàn)與 HR 系統(tǒng)的打通，并且可以減少很多權(quán)限的維護成本。

我們姑且叫這種授權(quán)方式為「用戶集合授權(quán)」吧。

除此之外，在大型企業(yè)里，我們通常還會有一些比較復(fù)雜的場景。比如我們要求崗位是產(chǎn)品經(jīng)理且職級是 P8 的人才能夠擁有某些權(quán)限。

這種場景沒有辦法按照上面的方式來做用戶集合，比如你不能說職級 P8 的人都擁有某些權(quán)限，崗位是產(chǎn)品經(jīng)理的人都擁有某些權(quán)限，這兩種「用戶集合授權(quán)」都不能滿足這個場景。

我們還可以建立一個動態(tài)的、按照規(guī)則的用戶集合，這個用戶集合的人是要滿足某些規(guī)則才能夠被加進來的。

于是乎，我們發(fā)現(xiàn)這個可以定義規(guī)則的動態(tài)的用戶集合，它非常地健壯，當(dāng)某個人因工作內(nèi)容發(fā)生異動時，他馬上會被調(diào)整出這個用戶集合。也能夠很好地減少授權(quán)工作，讓授權(quán)跟隨 HR 系統(tǒng)地變更。

我們叫這種授權(quán)方式為「動態(tài)用戶集合授權(quán)」吧！

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

比如我們經(jīng)常會有一些系統(tǒng)管理員，這個系統(tǒng)管理員跟這個人的屬性沒有關(guān)系，我們不可能有一個崗位叫做系統(tǒng)管理員，也不會有一個部門叫做系統(tǒng)管理員，于是我們這時候只能老老實實去建一個角色叫做「系統(tǒng)管理員」了。我們就叫這種授權(quán)為「角色授權(quán)」吧。

我們也經(jīng)常會遇到一些人他需要臨時開通某些權(quán)限，但這個權(quán)限在正常的情況下他不應(yīng)該擁有，那么此時我們可以通過走審批流給這個人授權(quán)，但請記住，審批流一定要和權(quán)限系統(tǒng)打通，確保審批流通過后，自動地在權(quán)限系統(tǒng)給這個人授權(quán)。同時，還要記得這種臨時授權(quán)一定要有權(quán)限期限，到期自動收回！我們就叫這種授權(quán)為「臨時授權(quán)」吧。

二、總結(jié)

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

事實上大家會看到，上面這些方法都只是為了讓授權(quán)更加簡便而已，本質(zhì)上還是 RBAC 的模型。原因是當(dāng)組織大了以后，授權(quán)這件事是很繁瑣的，如果不把授權(quán)做得更「自動化」一些，那么權(quán)限系統(tǒng)的管理員可能會累死掉。

實踐中，我們強烈推薦多使用「用戶集合授權(quán)」，甚至要求 HR 部門配合我們都是應(yīng)該的，因為我始終認(rèn)為 HR 和 HR 系統(tǒng)都應(yīng)該為業(yè)務(wù)服務(wù)。盡可能少的使用「角色授權(quán)」，除非你真的沒有辦法了。

上面這些方式并不一定適合你的公司，如果你有一些關(guān)于權(quán)限系統(tǒng)好的實踐方式或者對我的批評指導(dǎo)，可以在評論留言，一起討論。

本文由 @產(chǎn)品經(jīng)理日常思考 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash，基于 CC0 協(xié)議