目錄
1 為什麼需要權限管理
2 權限模型
2.1 權限設計
2.2 為什麼需要角色
2.3 權限模型的演進
2.3.1 RBAC模型
2.3.2 角色繼承的RBAC模型
2.3.3 帶限制的RBAC模型
2.4 使用者劃分
2.4.1 使用者組
2.4.2 組織
2.4.3 職位
2.5 理想的RBAC模型
3 權限系統表設計
3.1 标準RBAC模型表設計
3.2 理想RBAC模型表設計
4 結語
1 為什麼需要權限管理
日常工作中權限的問題時時刻刻伴随着我們，程式員新入職一家公司需要找人開通各種權限，比如網絡連接配接的權限、編碼下載下傳送出的權限、監控平台登入的權限、營運平台查資料的權限等等。在很多時候我們會覺得這麼多繁雜的申請給工作帶來不便，并且如果突然想要查一些資料，發現沒有申請過權限，需要再走審批流程，時間拉得會很長。那為什麼還需要這麼嚴格的權限管理呢？
舉個例子，一家支付公司有營運背景，營運背景可以查到所有的商戶資訊，法人代表資訊，交易資訊以及費率配置資訊，如果我們把這些資訊不加篩選都給到公司的每一個小夥伴，那麼跑市場的都可以操作商家的費率資訊，如果一個不小心把費率改了會造成巨大的損失。又比如商戶的資訊都是非常隐秘的，有些居心不良的小夥伴把這些資訊拿出來賣給商家的競争對手，會給商家造成嚴重的不良後果。雖然這麼做都是個别人人為的過錯，但是制度上如果本身這些資訊不開放出來就能在很大程度上避免違法亂紀的事情發生了。
總體來講權限管理是公司資料安全的重要保證，針對不同的崗位，不同的級别看到的資料是不一樣的，操作資料的限制也是不一樣的。比如涉及到資金的資訊隻開放給财務的相關崗位，涉及到配置的資訊隻開放給營運的相關崗位，這樣各司其職能避免很多不必要的安全問題。如何讓各個崗位的人在系統上各司其職，就是權限管理要解決的問題。
2 權限模型
2.1 權限設計
從業務分類上來講權限可以分為資料檢視權限，資料修改權限等，對應到系統設計中有頁面權限、菜單權限、按鈕權限等。菜單也分一級菜單、二級菜單甚至三級菜單，以csdn文章編輯頁面左側菜單欄為例是分了兩級菜單。菜單對應的頁面裡又有很多按鈕，我們在設計的時候最好把權限設計成樹形結構，這樣在申請權限的時候就可以一目了然的看到菜單的結構，需要哪些權限就非常的明了了。如下圖所示：
按照這個架構，按鈕的父級是二級菜單，二級菜單的父級是一級菜單，這樣使用者申請權限的時候非常清晰的看到自己需要哪些權限。
2.2 為什麼需要角色
權限結構梳理清晰之後，需要思考怎麼把權限配置設定給使用者，使用者少的情況下，可以直接配置設定，一個使用者可以有多個權限，統一一個權限可以被多個使用者擁有，使用者-權限的模型結構如下所示：
這種模型能夠滿足權限的基本配置設定能力，但是随着使用者數量的增長，這種模型的弊端就凸顯出來了，每一個使用者都需要去配置設定權限，非常的浪費管理者的時間和精力，并且使用者和權限雜亂的對應關系會給後期帶來巨大的維護成本。使用者-權限對應關系圖：
這種對應關系在使用者多的情況下基本無法維護了。其實很多使用者負責同一個業務子產品所需要的權限是一樣的，這樣的話我們是不是可以借助第三個媒介，把需要相同的權限都配置設定給這個媒介，然後使用者和媒介關聯起來，使用者就擁有了媒介的權限了。這就是經典的RBAC模型，其中媒介就是我們通常所說的角色。
2.3 權限模型的演進
2.3.1 RBAC模型
有了角色之後可以把權限配置設定給角色，需要相同權限的使用者和角色對應起來就可以了，一個權限可以配置設定給多個角色，一個角色可以擁有多個權限，同樣一個使用者可以配置設定多個角色，一個角色也可以對應多個使用者，對應模型如下所示：
這就是經典的RBAC模型了（role-based-access-control），在這裡面角色起到了橋梁左右，連接配接了使用者和權限的關系，每個角色可以擁有多個權限，每個使用者可以配置設定多個角色，這樣使用者就擁有了多個角色的多個權限。同時因為有角色作為媒介，大大降低了錯綜複雜的互動關系，比如一家有上萬人的公司，角色可能隻需要幾百個就搞定了，因為很多使用者需要的權限是一樣的，配置設定一樣的角色就可以了。這種模型的對應關系圖如下所示：
使用者和角色，角色和權限都是多對多的關系，這種模型是最通用的權限管理模型，節省了很大的權限維護成本， 但是實際的業務千變萬化，權限管理的模型也需要根據不同的業務模型适當的調整，比如一個公司内部的組織架構是分層級的，層級越高權限越大，因為層級高的人不僅要擁有自己下屬擁有的權限，二期還要有一些額外的權限。RBAC模型可以給不同層級的人配置設定不同的角色，層級高的對應角色的權限就多，這樣的處理方式可以解決問題，但是有沒有更好的解決辦法呢，答案肯定是有的，這就引出角色繼承的RBAC模型。
2.3.2 角色繼承的RBAC模型
角色繼承的RBAC模型又稱RBAC1模型。每個公司都有自己的組織架構，比如公司裡管理财務的人員有财務總監、财務主管、出納員等，财務主管需要擁有但不限于出納員的權限，财務總監需要擁有但不限于财務主管的權限，像這種管理關系向下相容的模式就需要用到角色繼承的RBAC模型。角色繼承的RBAC模型的思路是上層角色繼承下層角色的所有權限，并且可以額外擁有其他權限。模型如下所示：
從模型圖中可以看出下級角色擁有的權限，上級角色都擁有，并且上級角色可以擁有其他的權限。角色的層級關系可以分為兩種，一種是下級角色隻能擁有一個上級角色，但是上級角色可以擁有多個下級角色，這種結構用圖形表示是一個樹形結構，如下圖所示：
還有一種關系是下級角色可以擁有多個上級角色，上級角色也可以擁有多個下級角色，這種結構用圖形表示是一個有向無環圖，如下圖所示：
樹形圖是我們比較常用的，因為一個使用者一般情況下不會同時有多個直屬上級，比如财務部隻能有一個财務總監，但是可以有多個财務主管和收納員。
2.3.3 帶限制的RBAC模型
帶限制的RBAC模型又成RBAC2模型。在實際工作中，為了安全的考慮會有很多限制條件，比如财務部裡同一個人不能即是會計又是稽核員，跟一個人同一時間不能即是運動員又是裁判員是一個道理的，又比如财務部的稽核員不能超過2個，不能1個也沒有。因為角色和權限是關聯的，是以我們做好角色的限制就可以了，常見的限制條件有：角色互斥、基數限制、先決條件限制等。
角色互斥：如果角色A和角色B是互斥關系的話，那麼一個使用者同一時間不能即擁有角色A，又擁有角色B，隻能擁有其中的一個角色。比如我們給一個使用者賦予了會計的角色就不能同時再賦予稽核員的角色，如果想擁有稽核員的角色就必須先去掉會計的角色。假設送出角色和稽核角色是互質的，我們可以用圖形表示：
基數限制： 同一個角色被配置設定的使用者數量可以被限制，比如規定擁有超級管理者角色的使用者有且隻有1個；使用者被配置設定的角色數量也需要被限制，角色被配置設定的權限數量也可以被限制。
先決條件限制：使用者想被賦予上級角色，首先需要擁有下級角色，比如技術負責人的角色和普通技術員工角色是上下級關系，那麼使用者想要使用者技術負責人的角色就要先擁有普通技術員工的角色。
2.4 使用者劃分
2.4.1 使用者組
我們建立角色是為了解決使用者數量大的情況下，使用者配置設定權限繁瑣以及使用者-權限關系維護成本高的問題。抽象出一個角色，把需要一起操作的權限配置設定給這個角色，把角色賦予使用者，使用者就擁有了角色上的權限，這樣避免了一個個的給使用者配置設定權限，節省了大量的資源。同樣的如果有一批使用者需要相同的角色，我們也需要一個個的給使用者配置設定角色，比如一個公司的客服部門有500多個人，有一天研發部研發了一套查詢背景資料的産品，客服的小夥伴都需要使用，但是客服由于之前并沒有統一的一個角色給到所有的客服小夥伴，這時候需要新加一個角色，把權限配置設定給該角色，然後再把角色一個個配置設定給客服人員，這時候會發現給500個使用者一個個添加角色非常的麻煩。但是客服人員又有共同的屬性，是以我們可以建立一個使用者組，所有的客服人員都屬于客服使用者組，把角色配置設定給客服使用者組，這個使用者組下面的所有使用者就擁有了需要的權限。RBAC模型添加使用者組之後的模型圖如下所示：
很多朋友會問，使用者組和角色有什麼差別呢？簡單的來說，使用者組是一群使用者的組合，而角色是使用者和權限之間的橋梁。使用者組把相同屬性的使用者組合起來，比如同一個項目的開發、産品、測試可以是一個使用者組，同一個部門的相同職位的員工可以是一個使用者組， 一個使用者組可以是一個職級，可以是一個部門，可以是一起做事情的來自不同崗位的人。
使用者可以分組，權限也可以分組，權限特别多的情況下，可以把一個子產品的權限組合起來成為一個權限組，權限組也是解決權限和角色對應關系複雜的問題。比如我們定義權限的時候一級菜單、二級菜單、按鈕都可以是權限，一個一級菜單下面有幾十個二級菜單，每個二級菜單下面又有幾十個按鈕，這時候我們把權限一個個配置設定給角色也是非常麻煩的，可以采用分組的方法把權限分組，然後把分好的組賦予角色就可以了。給權限分組也是個技術活，需要理清楚權限之間的關系，比如支付的營運背景我們需要查各種資訊，賬務的資料、訂單的資料、商戶的資料等等，這些查詢的資料并不在一個頁面，每個頁面也有很多按鈕，我們可以把這幾個頁面以及按鈕對應的權限組合成一個權限組賦予角色。加入權限組之後的RBAC模型如下所示：
實際工作中我們很少給權限分組，給使用者分組的場景會多一些，有的時候使用者組也可以直接和權限關聯，這個看實際的業務場景是否需要，權限模型沒有統一的，業務越複雜業務模型會約多樣化。
2.4.2 組織
每個公司都有自己的組織架構，很多時候權限的配置設定可以根據組織架構來劃分。因為同一個組織内的小夥伴使用的大部分權限是一樣的。如下所示一個公司的組織架構圖：
按照這個組織架構，每一個組織裡的成員使用的基礎權限很可能是一樣的，比如人力資源都需要看到人才招聘的相關資訊，市場推廣都需要看到行業分析的相關資訊，按照組織來配置設定角色會有很多優勢：
實作權限配置設定的自動化：群組織關系打通之後，按照組織來配置設定角色，如果有新入職的使用者，被劃分在某個組織下面之後，會自動擷取該組織下所有的權限，無需人工配置設定。又比如有使用者調崗，隻需要把組織關系調整就可以了，權限會跟着組織關系自動調整，也無需人工幹預。 這麼做首先需要把權限群組織關系打通。
控制資料權限：把角色關聯到組織，組織裡的成員隻能看到本組織下的資料，比如市場推廣和大客定制，市場推廣針對的是零散的客戶，大可定制針對的是有一定體量的客戶，互相的資料雖然在一個平台，但是隻能看自己組織下的資料。
加入組織之後的RBAC模型如下所示：
使用者可以在多個組織中，因為組織也有層級結構，一個組織裡隻可以有多個使用者，是以使用者群組織的關系是多對多的關系，組織和角色的關系是一對一的關系。這個在工作中可以根據實際情況來确定對應關系。
2.4.3 職位
一個組織下面會有很多職位，比如财務管理會有财務總監、财務主管、會計、出納員等職位，每個職位需要的權限是不一樣的，可以像組織那樣根據職位來配置設定不同的角色，由于一個人的職位是固定的，是以使用者跟職位的對應關系時一對一的關系，職位跟角色的對應關系可以是多對多的關系。加入職位的RBAC模型如下所示：
2.5 理想的RBAC模型
RBAC模型根據不同業務場景的需要會有很多種演變，實際工作中業務是非常複雜的，權限配置設定也是非常複雜的，想要做出通用且高效的模型很困難。我們把RBAC模型的演變彙總起來會是一個支撐大資料量以及複雜業務的理想的模型。把RBAC、RBAC1、RBAC2、使用者組、組織、職位彙總起來的模型如下所示：
按照這個模型基本上能夠解決所有的權限問題，其中的對應關系可以根據實際的業務情況來确定，一般情況下，組織和職位是一對多的關系，特殊情況下可以有多對多的情況，需要根據實際情況來定。
理想的RBAC模型并不是說我們一開始建權限模型就可以這麼做，而是資料體量、業務複雜度達到一定程度之後可以使用這個模型來解決權限的問題，如果資料量特别少，比如剛成立的公司隻有十幾個人，那完全可以用使用者-權限模型，都沒有必要使用RBAC模型。
3 權限系統表設計
3.1 标準RBAC模型表設計
标準RBAC模型的表是比較簡單了，要表示使用者-角色-權限三者之前的關系，首先要建立使用者表、角色表、權限表，使用者和角色是多對多的關系，角色和權限是多對多的關系，需要再建立兩章關系表，分别是使用者-角色關系表和角色-權限關系表。這六張表的ER圖如下所示：
3.2 理想RBAC模型表設計
理想的RBAC模型是标準RBAC模型經過多次擴充得到的，表結構也會比較複雜，因為要維護很多關系，如下圖所示是理想的RBAC模型的ER圖：
這裡面需要強調的是角色互斥表，互斥的關系可以放在角色上，也可以放在權限上，看實際工作的需求。
4 結語
本文從易到難非常詳細的介紹了權限模型的設計，在工作中需要根據實際情況來定義模型，千人以内的公司使用RBAC模型是完全夠用的，沒有必要吧權限模型設計的過于複雜。模型的選擇要根據具體情況，比如公司體量、業務類型、人員數量等。總之最适合自己公司的模型就是最好的模型，權限模式和設計模式是一樣的，都是為了更好的解決問題，不要為了使用模型而使用模型。