1.為什么需要權(quán)限管理

日常工作中權(quán)限的問(wèn)題時(shí)時(shí)刻刻伴隨著我們，程序員新入職一家公司需要找人開(kāi)通各種權(quán)限，比如網(wǎng)絡(luò)連接的權(quán)限、編碼下載提交的權(quán)限、監(jiān)控平臺(tái)登錄的權(quán)限、運(yùn)營(yíng)平臺(tái)查數(shù)據(jù)的權(quán)限等等。

在很多時(shí)候我們會(huì)覺(jué)得這么多繁雜的申請(qǐng)給工作帶來(lái)不便，并且如果突然想要查一些數(shù)據(jù)，發(fā)現(xiàn)沒(méi)有申請(qǐng)過(guò)權(quán)限，需要再走審批流程，時(shí)間拉得會(huì)很長(zhǎng)。那為什么還需要這么嚴(yán)格的權(quán)限管理呢？

舉個(gè)例子，一家支付公司有運(yùn)營(yíng)后臺(tái)，運(yùn)營(yíng)后臺(tái)可以查到所有的商戶(hù)信息，法人代表信息，交易信息以及費(fèi)率配置信息，如果我們把這些信息不加篩選都給到公司的每一個(gè)小伙伴，那么跑市場(chǎng)的都可以操作商家的費(fèi)率信息，如果一個(gè)不小心把費(fèi)率改了會(huì)造成巨大的損失。

又比如商戶(hù)的信息都是非常隱秘的，有些居心不良的小伙伴把這些信息拿出來(lái)賣(mài)給商家的競(jìng)爭(zhēng)對(duì)手，會(huì)給商家造成嚴(yán)重的不良后果。雖然這么做都是個(gè)別人人為的過(guò)錯(cuò)，但是制度上如果本身這些信息不開(kāi)放出來(lái)就能在很大程度上避免違法亂紀(jì)的事情發(fā)生了。

總體來(lái)講權(quán)限管理是公司數(shù)據(jù)安全的重要保證，針對(duì)不同的崗位，不同的級(jí)別看到的數(shù)據(jù)是不一樣的，操作數(shù)據(jù)的限制也是不一樣的。比如涉及到資金的信息只開(kāi)放給財(cái)務(wù)的相關(guān)崗位，涉及到配置的信息只開(kāi)放給運(yùn)營(yíng)的相關(guān)崗位，這樣各司其職能避免很多不必要的安全問(wèn)題。

如何讓各個(gè)崗位的人在系統(tǒng)上各司其職，就是權(quán)限管理要解決的問(wèn)題。

2.權(quán)限模型

2.1 權(quán)限設(shè)計(jì)

從業(yè)務(wù)分類(lèi)上來(lái)講權(quán)限可以分為數(shù)據(jù)查看權(quán)限，數(shù)據(jù)修改權(quán)限等，對(duì)應(yīng)到系統(tǒng)設(shè)計(jì)中有頁(yè)面權(quán)限、菜單權(quán)限、按鈕權(quán)限等。菜單也分一級(jí)菜單、二級(jí)菜單甚至三級(jí)菜單，以csdn文章編輯頁(yè)面左側(cè)菜單欄為例是分了兩級(jí)菜單。菜單對(duì)應(yīng)的頁(yè)面里又有很多按鈕，我們?cè)谠O(shè)計(jì)的時(shí)候最好把權(quán)限設(shè)計(jì)成樹(shù)形結(jié)構(gòu)，這樣在申請(qǐng)權(quán)限的時(shí)候就可以一目了然的看到菜單的結(jié)構(gòu)，需要哪些權(quán)限就非常的明了了。

如下圖所示：

圖片

按照這個(gè)架構(gòu)，按鈕的父級(jí)是二級(jí)菜單，二級(jí)菜單的父級(jí)是一級(jí)菜單，這樣用戶(hù)申請(qǐng)權(quán)限的時(shí)候非常清晰的看到自己需要哪些權(quán)限。

2.2 為什么需要角色

權(quán)限結(jié)構(gòu)梳理清晰之后，需要思考怎么把權(quán)限分配給用戶(hù)，用戶(hù)少的情況下，可以直接分配，一個(gè)用戶(hù)可以有多個(gè)權(quán)限，統(tǒng)一一個(gè)權(quán)限可以被多個(gè)用戶(hù)擁有，用戶(hù)-權(quán)限的模型結(jié)構(gòu)如下所示：

圖片

這種模型能夠滿(mǎn)足權(quán)限的基本分配能力，但是隨著用戶(hù)數(shù)量的增長(zhǎng)，這種模型的弊端就凸顯出來(lái)了，每一個(gè)用戶(hù)都需要去分配權(quán)限，非常的浪費(fèi)管理員的時(shí)間和精力，并且用戶(hù)和權(quán)限雜亂的對(duì)應(yīng)關(guān)系會(huì)給后期帶來(lái)巨大的維護(hù)成本。用戶(hù)-權(quán)限對(duì)應(yīng)關(guān)系圖：

圖片

這種對(duì)應(yīng)關(guān)系在用戶(hù)多的情況下基本無(wú)法維護(hù)了。其實(shí)很多用戶(hù)負(fù)責(zé)同一個(gè)業(yè)務(wù)模塊所需要的權(quán)限是一樣的，這樣的話(huà)我們是不是可以借助第三個(gè)媒介，把需要相同的權(quán)限都分配給這個(gè)媒介，然后用戶(hù)和媒介關(guān)聯(lián)起來(lái)，用戶(hù)就擁有了媒介的權(quán)限了。這就是經(jīng)典的RBAC模型，其中媒介就是我們通常所說(shuō)的角色。

2.3 權(quán)限模型的演進(jìn)

2.3.1 RBAC模型

有了角色之后可以把權(quán)限分配給角色，需要相同權(quán)限的用戶(hù)和角色對(duì)應(yīng)起來(lái)就可以了，一個(gè)權(quán)限可以分配給多個(gè)角色，一個(gè)角色可以擁有多個(gè)權(quán)限，同樣一個(gè)用戶(hù)可以分配多個(gè)角色，一個(gè)角色也可以對(duì)應(yīng)多個(gè)用戶(hù)，對(duì)應(yīng)模型如下所示：

圖片

這就是經(jīng)典的RBAC模型了（role-based-access-control），在這里面角色起到了橋梁左右，連接了用戶(hù)和權(quán)限的關(guān)系，每個(gè)角色可以擁有多個(gè)權(quán)限，每個(gè)用戶(hù)可以分配多個(gè)角色，這樣用戶(hù)就擁有了多個(gè)角色的多個(gè)權(quán)限。

同時(shí)因?yàn)橛薪巧鳛槊浇?，大大降低了錯(cuò)綜復(fù)雜的交互關(guān)系，比如一家有上萬(wàn)人的公司，角色可能只需要幾百個(gè)就搞定了，因?yàn)楹芏嘤脩?hù)需要的權(quán)限是一樣的，分配一樣的角色就可以了。這種模型的對(duì)應(yīng)關(guān)系圖如下所示：

圖片

用戶(hù)和角色，角色和權(quán)限都是多對(duì)多的關(guān)系，這種模型是最通用的權(quán)限管理模型，節(jié)省了很大的權(quán)限維護(hù)成本， 但是實(shí)際的業(yè)務(wù)千變?nèi)f化，權(quán)限管理的模型也需要根據(jù)不同的業(yè)務(wù)模型適當(dāng)?shù)恼{(diào)整，比如一個(gè)公司內(nèi)部的組織架構(gòu)是分層級(jí)的，層級(jí)越高權(quán)限越大，因?yàn)閷蛹?jí)高的人不僅要擁有自己下屬擁有的權(quán)限，二期還要有一些額外的權(quán)限。

RBAC模型可以給不同層級(jí)的人分配不同的角色，層級(jí)高的對(duì)應(yīng)角色的權(quán)限就多，這樣的處理方式可以解決問(wèn)題，但是有沒(méi)有更好的解決辦法呢，答案肯定是有的，這就引出角色繼承的RBAC模型。

2.3.2 角色繼承的RBAC模型

角色繼承的RBAC模型又稱(chēng)RBAC1模型。每個(gè)公司都有自己的組織架構(gòu)，比如公司里管理財(cái)務(wù)的人員有財(cái)務(wù)總監(jiān)、財(cái)務(wù)主管、出納員等，財(cái)務(wù)主管需要擁有但不限于出納員的權(quán)限，財(cái)務(wù)總監(jiān)需要擁有但不限于財(cái)務(wù)主管的權(quán)限，像這種管理關(guān)系向下兼容的模式就需要用到角色繼承的RBAC模型。角色繼承的RBAC模型的思路是上層角色繼承下層角色的所有權(quán)限，并且可以額外擁有其他權(quán)限。

模型如下所示：

圖片

從模型圖中可以看出下級(jí)角色擁有的權(quán)限，上級(jí)角色都擁有，并且上級(jí)角色可以擁有其他的權(quán)限。角色的層級(jí)關(guān)系可以分為兩種，一種是下級(jí)角色只能擁有一個(gè)上級(jí)角色，但是上級(jí)角色可以擁有多個(gè)下級(jí)角色，這種結(jié)構(gòu)用圖形表示是一個(gè)樹(shù)形結(jié)構(gòu)，如下圖所示：

圖片

還有一種關(guān)系是下級(jí)角色可以擁有多個(gè)上級(jí)角色，上級(jí)角色也可以擁有多個(gè)下級(jí)角色，這種結(jié)構(gòu)用圖形表示是一個(gè)有向無(wú)環(huán)圖，如下圖所示：

圖片

樹(shù)形圖是我們比較常用的，因?yàn)橐粋€(gè)用戶(hù)一般情況下不會(huì)同時(shí)有多個(gè)直屬上級(jí)，比如財(cái)務(wù)部只能有一個(gè)財(cái)務(wù)總監(jiān)，但是可以有多個(gè)財(cái)務(wù)主管和收納員。

2.3.3 帶約束的RBAC模型

帶約束的RBAC模型又成RBAC2模型。在實(shí)際工作中，為了安全的考慮會(huì)有很多約束條件，比如財(cái)務(wù)部里同一個(gè)人不能即是會(huì)計(jì)又是審核員，跟一個(gè)人同一時(shí)間不能即是運(yùn)動(dòng)員又是裁判員是一個(gè)道理的，又比如財(cái)務(wù)部的審核員不能超過(guò)2個(gè)，不能1個(gè)也沒(méi)有。因?yàn)榻巧蜋?quán)限是關(guān)聯(lián)的，所以我們做好角色的約束就可以了。

常見(jiàn)的約束條件有：角色互斥、基數(shù)約束、先決條件約束等。

角色互斥： 如果角色A和角色B是互斥關(guān)系的話(huà)，那么一個(gè)用戶(hù)同一時(shí)間不能即擁有角色A，又擁有角色B，只能擁有其中的一個(gè)角色。

比如我們給一個(gè)用戶(hù)賦予了會(huì)計(jì)的角色就不能同時(shí)再賦予審核員的角色，如果想擁有審核員的角色就必須先去掉會(huì)計(jì)的角色。假設(shè)提交角色和審核角色是互質(zhì)的，我們可以用圖形表示：

圖片

基數(shù)約束： 同一個(gè)角色被分配的用戶(hù)數(shù)量可以被限制，比如規(guī)定擁有超級(jí)管理員角色的用戶(hù)有且只有1個(gè)；用戶(hù)被分配的角色數(shù)量也需要被限制，角色被分配的權(quán)限數(shù)量也可以被限制。

先決條件約束：用戶(hù)想被賦予上級(jí)角色，首先需要擁有下級(jí)角色，比如技術(shù)負(fù)責(zé)人的角色和普通技術(shù)員工角色是上下級(jí)關(guān)系，那么用戶(hù)想要用戶(hù)技術(shù)負(fù)責(zé)人的角色就要先擁有普通技術(shù)員工的角色。

2.4 用戶(hù)劃分

2.4.1 用戶(hù)組

我們創(chuàng)建角色是為了解決用戶(hù)數(shù)量大的情況下，用戶(hù)分配權(quán)限繁瑣以及用戶(hù)-權(quán)限關(guān)系維護(hù)成本高的問(wèn)題。抽象出一個(gè)角色，把需要一起操作的權(quán)限分配給這個(gè)角色，把角色賦予用戶(hù)，用戶(hù)就擁有了角色上的權(quán)限，這樣避免了一個(gè)個(gè)的給用戶(hù)分配權(quán)限，節(jié)省了大量的資源。

同樣的如果有一批用戶(hù)需要相同的角色，我們也需要一個(gè)個(gè)的給用戶(hù)分配角色，比如一個(gè)公司的客服部門(mén)有500多個(gè)人，有一天研發(fā)部研發(fā)了一套查詢(xún)后臺(tái)數(shù)據(jù)的產(chǎn)品，客服的小伙伴都需要使用，但是客服由于之前并沒(méi)有統(tǒng)一的一個(gè)角色給到所有的客服小伙伴，這時(shí)候需要新加一個(gè)角色，把權(quán)限分配給該角色，然后再把角色一個(gè)個(gè)分配給客服人員，這時(shí)候會(huì)發(fā)現(xiàn)給500個(gè)用戶(hù)一個(gè)個(gè)添加角色非常的麻煩。但是客服人員又有共同的屬性，所以我們可以創(chuàng)建一個(gè)用戶(hù)組，所有的客服人員都屬于客服用戶(hù)組，把角色分配給客服用戶(hù)組，這個(gè)用戶(hù)組下面的所有用戶(hù)就擁有了需要的權(quán)限。

RBAC模型添加用戶(hù)組之后的模型圖如下所示：

圖片

很多朋友會(huì)問(wèn)，用戶(hù)組和角色有什么區(qū)別呢？簡(jiǎn)單的來(lái)說(shuō)，用戶(hù)組是一群用戶(hù)的組合，而角色是用戶(hù)和權(quán)限之間的橋梁。 用戶(hù)組把相同屬性的用戶(hù)組合起來(lái)，比如同一個(gè)項(xiàng)目的開(kāi)發(fā)、產(chǎn)品、測(cè)試可以是一個(gè)用戶(hù)組，同一個(gè)部門(mén)的相同職位的員工可以是一個(gè)用戶(hù)組， 一個(gè)用戶(hù)組可以是一個(gè)職級(jí)，可以是一個(gè)部門(mén)，可以是一起做事情的來(lái)自不同崗位的人。

用戶(hù)可以分組，權(quán)限也可以分組，權(quán)限特別多的情況下，可以把一個(gè)模塊的權(quán)限組合起來(lái)成為一個(gè)權(quán)限組，權(quán)限組也是解決權(quán)限和角色對(duì)應(yīng)關(guān)系復(fù)雜的問(wèn)題。

比如我們定義權(quán)限的時(shí)候一級(jí)菜單、二級(jí)菜單、按鈕都可以是權(quán)限，一個(gè)一級(jí)菜單下面有幾十個(gè)二級(jí)菜單，每個(gè)二級(jí)菜單下面又有幾十個(gè)按鈕，這時(shí)候我們把權(quán)限一個(gè)個(gè)分配給角色也是非常麻煩的，可以采用分組的方法把權(quán)限分組，然后把分好的組賦予角色就可以了。

給權(quán)限分組也是個(gè)技術(shù)活，需要理清楚權(quán)限之間的關(guān)系，比如支付的運(yùn)營(yíng)后臺(tái)我們需要查各種信息，賬務(wù)的數(shù)據(jù)、訂單的數(shù)據(jù)、商戶(hù)的數(shù)據(jù)等等，這些查詢(xún)的數(shù)據(jù)并不在一個(gè)頁(yè)面，每個(gè)頁(yè)面也有很多按鈕，我們可以把這幾個(gè)頁(yè)面以及按鈕對(duì)應(yīng)的權(quán)限組合成一個(gè)權(quán)限組賦予角色。加入權(quán)限組之后的RBAC模型如下所示：

圖片

實(shí)際工作中我們很少給權(quán)限分組，給用戶(hù)分組的場(chǎng)景會(huì)多一些，有的時(shí)候用戶(hù)組也可以直接和權(quán)限關(guān)聯(lián)，這個(gè)看實(shí)際的業(yè)務(wù)場(chǎng)景是否需要，權(quán)限模型沒(méi)有統(tǒng)一的，業(yè)務(wù)越復(fù)雜業(yè)務(wù)模型會(huì)約多樣化。

2.4.2 組織

每個(gè)公司都有自己的組織架構(gòu)，很多時(shí)候權(quán)限的分配可以根據(jù)組織架構(gòu)來(lái)劃分。因?yàn)橥粋€(gè)組織內(nèi)的小伙伴使用的大部分權(quán)限是一樣的。如下所示一個(gè)公司的組織架構(gòu)圖：

圖片

按照這個(gè)組織架構(gòu)，每一個(gè)組織里的成員使用的基礎(chǔ)權(quán)限很可能是一樣的，比如人力資源都需要看到人才招聘的相關(guān)信息，市場(chǎng)推廣都需要看到行業(yè)分析的相關(guān)信息，按照組織來(lái)分配角色會(huì)有很多優(yōu)勢(shì)：

實(shí)現(xiàn)權(quán)限分配的自動(dòng)化： 和組織關(guān)系打通之后，按照組織來(lái)分配角色，如果有新入職的用戶(hù)，被劃分在某個(gè)組織下面之后，會(huì)自動(dòng)獲取該組織下所有的權(quán)限，無(wú)需人工分配。又比如有用戶(hù)調(diào)崗，只需要把組織關(guān)系調(diào)整就可以了，權(quán)限會(huì)跟著組織關(guān)系自動(dòng)調(diào)整，也無(wú)需人工干預(yù)。這么做首先需要把權(quán)限和組織關(guān)系打通。

控制數(shù)據(jù)權(quán)限： 把角色關(guān)聯(lián)到組織，組織里的成員只能看到本組織下的數(shù)據(jù)，比如市場(chǎng)推廣和大客定制，市場(chǎng)推廣針對(duì)的是零散的客戶(hù)，大可定制針對(duì)的是有一定體量的客戶(hù)，相互的數(shù)據(jù)雖然在一個(gè)平臺(tái)，但是只能看自己組織下的數(shù)據(jù)。

加入組織之后的RBAC模型如下所示：

圖片

用戶(hù)可以在多個(gè)組織中，因?yàn)榻M織也有層級(jí)結(jié)構(gòu)，一個(gè)組織里只可以有多個(gè)用戶(hù)，所以用戶(hù)和組織的關(guān)系是多對(duì)多的關(guān)系，組織和角色的關(guān)系是一對(duì)一的關(guān)系。這個(gè)在工作中可以根據(jù)實(shí)際情況來(lái)確定對(duì)應(yīng)關(guān)系。

2.4.3 職位

一個(gè)組織下面會(huì)有很多職位，比如財(cái)務(wù)管理會(huì)有財(cái)務(wù)總監(jiān)、財(cái)務(wù)主管、會(huì)計(jì)、出納員等職位，每個(gè)職位需要的權(quán)限是不一樣的，可以像組織那樣根據(jù)職位來(lái)分配不同的角色，由于一個(gè)人的職位是固定的，所以用戶(hù)跟職位的對(duì)應(yīng)關(guān)系時(shí)一對(duì)一的關(guān)系，職位跟角色的對(duì)應(yīng)關(guān)系可以是多對(duì)多的關(guān)系。加入職位的RBAC模型如下所示：

圖片

2.5 理想的RBAC模型

RBAC模型根據(jù)不同業(yè)務(wù)場(chǎng)景的需要會(huì)有很多種演變，實(shí)際工作中業(yè)務(wù)是非常復(fù)雜的，權(quán)限分配也是非常復(fù)雜的，想要做出通用且高效的模型很困難。我們把RBAC模型的演變匯總起來(lái)會(huì)是一個(gè)支撐大數(shù)據(jù)量以及復(fù)雜業(yè)務(wù)的理想的模型。把RBAC、RBAC1、RBAC2、用戶(hù)組、組織、職位匯總起來(lái)的模型如下所示：

圖片

按照這個(gè)模型基本上能夠解決所有的權(quán)限問(wèn)題，其中的對(duì)應(yīng)關(guān)系可以根據(jù)實(shí)際的業(yè)務(wù)情況來(lái)確定，一般情況下，組織和職位是一對(duì)多的關(guān)系，特殊情況下可以有多對(duì)多的情況，需要根據(jù)實(shí)際情況來(lái)定。

理想的RBAC模型并不是說(shuō)我們一開(kāi)始建權(quán)限模型就可以這么做，而是數(shù)據(jù)體量、業(yè)務(wù)復(fù)雜度達(dá)到一定程度之后可以使用這個(gè)模型來(lái)解決權(quán)限的問(wèn)題，如果數(shù)據(jù)量特別少，比如剛成立的公司只有十幾個(gè)人，那完全可以用用戶(hù)-權(quán)限模型，都沒(méi)有必要使用RBAC模型。

3 權(quán)限系統(tǒng)表設(shè)計(jì)

3.1 標(biāo)準(zhǔn)RBAC模型表設(shè)計(jì)

標(biāo)準(zhǔn)RBAC模型的表是比較簡(jiǎn)單了，要表示用戶(hù)-角色-權(quán)限三者之前的關(guān)系，首先要?jiǎng)?chuàng)建用戶(hù)表、角色表、權(quán)限表，用戶(hù)和角色是多對(duì)多的關(guān)系，角色和權(quán)限是多對(duì)多的關(guān)系，需要再創(chuàng)建兩章關(guān)系表，分別是用戶(hù)-角色關(guān)系表和角色-權(quán)限關(guān)系表。這六張表的ER圖如下所示：

圖片

3.2 理想RBAC模型表設(shè)計(jì)

理想的RBAC模型是標(biāo)準(zhǔn)RBAC模型經(jīng)過(guò)多次擴(kuò)展得到的，表結(jié)構(gòu)也會(huì)比較復(fù)雜，因?yàn)橐S護(hù)很多關(guān)系，如下圖所示是理想的RBAC模型的ER圖：

圖片

這里面需要強(qiáng)調(diào)的是角色互斥表，互斥的關(guān)系可以放在角色上，也可以放在權(quán)限上，看實(shí)際工作的需求。

4.結(jié)語(yǔ)

本文從易到難非常詳細(xì)的介紹了權(quán)限模型的設(shè)計(jì)，在工作中需要根據(jù)實(shí)際情況來(lái)定義模型，千人以?xún)?nèi)的公司使用RBAC模型是完全夠用的，沒(méi)有必要吧權(quán)限模型設(shè)計(jì)的過(guò)于復(fù)雜。模型的選擇要根據(jù)具體情況，比如公司體量、業(yè)務(wù)類(lèi)型、人員數(shù)量等?？傊钸m合自己公司的模型就是最好的模型，權(quán)限模式和設(shè)計(jì)模式是一樣的，都是為了更好的解決問(wèn)題，不要為了使用模型而使用模型。