RBAC模型是通過分離權限與用戶的耦合關係，將權限關聯在角色上，用戶通過扮演適當的角色獲得合適的權限的權限管理方式。本文在RBAC模型的基礎下，整理權限設計過程中的客戶場景、總結設計思路。
一、項目背景本項目是一個關於OA系統升級改造的ToG項目，涉及3000+單位5萬用戶，橫跨市–區縣–鎮街3層行政區劃。各單位之間業務信息交流頻繁，業務上經常需要跨單位、跨部門的協同運作。在系統層面，所有單位均在同一租戶下，由基礎平臺負責各業務子系統權限的統一管理。
二、從組織架構看權限的管理模式回顧整個項目，在進行權限設計之前，必需先了解現場的組織架構。因為RBAC模型主要描述的只是用戶–角色–權限之間的關係，而決定RBAC模型複雜程度的是業務上的組織架構。
當組織架構達到一定量級的複雜程度後，根據系統部署的方式或管理理念的不同，會分化出不同的權限管理模式，不同的管理模式對系統權限設計也會有不一樣的要求。
下面以全市組織架構為例進行說明：
圖1 組織架構層級
1. 組織架構說明以上的組織架構主要分為5種層級：
行政區劃：具有業務屬性的單位集合；可用於數據權限劃分時的區域劃分；集合：沒有業務屬性的單位集合；通過集合的歸類，讓用戶更便捷地找到所需單位；單位：基礎的權限單元，指機關、團體或企業；部門：基礎的權限單元，指單位的下級分支機構；用戶：組織架構組成的最小單元。2. 不同組織架構下的權限模型1）基礎權限模型
適用場景：場景一 、場景二
基礎權限模型適用於單個單位或組織架構相對扁平的企業。系統完全交付後，通過系統管理員的管理即可滿足日常角色與權限的維護，各模塊業務數據需求明確，是基本的RBAC模型，其業務管理模式如下：
由系統管理員負責角色的權限及用戶分配。由系統管理員創建單位管理員角色，由單位管理員負責角色的權限及用戶分配。因此，在這種模式下，系統管理經常兼任單位管理員的管理工作，對權限下放的設計要求不高，其角色樹如圖2所示。
圖2 系統管理員≥單位管理員＞業務角色
RBAC模型已經定義了「用戶–角色–權限」的授權模式，將系統功能拆分為操作權限與數據權限兩個維度進行設計。在此框架下設計的權限模型，不管面向的企業對象如何變化，操作權限的設計思路都是不變的，僅需要對數據權限進行改造，即可滿足企業的業務使用。
2）多單位管理模型
適用場景：場景三 、場景四
多單位管理模型適用於大中型單位組織架構，單位之間存在上下級關係且業務交流頻繁。由於單位間的管理關係，需要橫向或縱向的跨單位數據管理，考驗權限對數據靈活配置的能力。
因此，大型系統的RBAC管理過程更為複雜，此時簡單的RBAC已不能滿足系統的訪問控制分級管理的要求。尤其在信息系統中存儲和管理大量企業單位的敏感數據，一旦這些數據被洩露或竊取，會給帶來難以彌補的損失。
另外在企業運營中經常需要對組織架構和人員工作進行調整，相應地需要修改系統中訪問控制主體和權限的關係。而系統管理員由於不了解調整內容導致授權工作滯後，即使修改後也不一定能準確反映調整狀態，常需要多次補充修改，導致授權效率較低，影響正常的業務工作進程。
為了解決信息系統中訪問控制管理的問題，適當簡化授權工作量，提高權限管理效率，需要建立基於角色的多單位授權管理模型，其業務管理模式如下：
由系統管理員負責角色的權限及用戶分配。由系統管理員負責角色的權限分配，同時賦予單位管理員對角色分配用戶的權限（定義標準角色，實現權限管理的部分下放）。由系統管理員負責創建單位管理員角色，由單位管理員負責角色的權限及用戶分配（不定義標準業務角色，實現權限的完全下放）。在此模式下，系統管理員不再兼任單位管理員工作，需要實現權限的多級下放。
在場景四中，由於業務上對單位群進行劃分，需要系統管理員或特定區域管理員管理單位集合或超出單位管理員權限的特殊角色，角色樹較場景三更加複雜，具體角色樹如圖3所示。
圖3 系統管理員≥區域管理員＞單位管理員＞業務角色
3）多區域管理模型
適用場景：場景五
多區域管理模式是多單位管理模型的拓展。
首先是對數據管理的要求更高，除了系統、單位、科室、個人的層級外，需要新增區域層級以管理某一範圍內的數據信息。
其次，由於涉及多層級的權限管理，在滿足多級權限下放需求，需要充分考慮不同層級角色對某一角色的管理問題、小權限角色對大權限角色的管理問題等。例如：區域管理與單位管理對某業務角色進行管理時，由於自身權限不同，可下放給此角色的權限也不相同。
如何避免小權限角色對大權限角色造成影響，需要我們結合業務實際使用情況進行設計。
業務管理模式如下：
由系統管理員負責角色的權限分配，同時賦予區域管理員、單位管理員對角色分配用戶的權限（定義標準角色，實現權限管理的部分下放）。由系統管理員負責創建區域管理員角色，由區域管理員分配單位管理員角色，由單位管理員負責角色的權限及用戶分配（不定義標準業務角色，實現權限的完全下放）。在此模式下，系統管理員也不再兼任區域管理員工作，角色樹如圖4所示。其中角色1-3為區域管理員，角色4-8為單位管理員。
圖4 系統管理員＞區域管理員＞單位管理員＞業務角色
三、定義角色、職位、職務之間的關係在我們用戶信息管理中，需要填寫用戶的職位或職務，在定義角色、職位與職務的關係之前，需要先明確職位與職務之間的關係。
職位：指企業的某個員工需要完成的一個或一組任務；例如：銷售總監 、銷售經理、財務/出納員、司機、倉庫管理員等。
職務：職員所具有的頭銜稱謂，包括職權和職責兩方面內容，隨著語義的拓展職位亦有此意思；例如：科員，主任，經理，總經理。
因此，職位包含職務的意義，職務基本也與職位相對應。而系統中的權限，是用戶在現實工作中的權限或工作範疇在系統中的映射。為了簡化角色與職位之間的關係，定義現實中用戶職位或職務中包含的權限，在系統上均通過角色進行管理設置。
四、角色權限的設計角色設計主要分為角色管理、分配用戶及分配權限3個模塊，通過對這3個模塊的控制，實現多區域管理模型下的權限設計。
1. 角色管理在多區域管理模型下，需要支持權限統一管理與多層級權限下放兩種場景。
分離角色的管理與使用權限，由創建單位對角色權限進行管理，創建單位與使用單位共同分配用戶，可滿足權限統一管理要求的同時，兼具各單位自行調整用戶的需求。
圖5 系統角色管理
2. 分配用戶分配用戶的頁面，需要根據用戶當前管理的權限範圍進行控制，僅支持查看和分配管轄範圍內的用戶。例如單位管理員僅支持查看和分配自己單位的用戶，系統管理員可查看並分配系統內的所有用戶。
由於同一角色可能支持多個管理員分配用戶，為了系統安全與方便追溯，可通過操作人欄位記錄此用戶是由誰進行分配的。
圖6 分配用戶
3. 分配權限為了實現對系統各模塊的權限管理，將每個模塊劃分為3個部分：菜單、頁面數據、按鈕。其中將菜單及按鈕納入操作權限，將頁面數據歸為數據權限。
由於各功能模塊都是根據業務具體場景進行設計開發的，因此權限也需要根據業務具體要求而進行劃分與設計。但為了系統的統一管理，可以建立統一的設計規範，以維持系統架構統一甚至減少開發工作量。
1）操作權限
操作權限用於控制此角色在系統中可對哪些模塊做哪種操作。
通過控制菜單，實現管理用戶控制特定模塊的需求；通過頁面按鈕，實現控制用戶在此模塊下可以進行的操作。
以角色管理頁面為例，分配角色管理菜單的用戶，即可查看對應的角色數據，再通過對「新增」「刪除」「啟用」「禁用」等按鈕的控制，限制用戶在此模塊下的操作。
部分頁面的欄位還需要區分「只讀」「可改」，以實現各角色在相同頁面中不同的管理需求。
圖7 操作權限
2）數據權限
數據權限是權限管理中最核心的部分，隨著組織架構的複雜，數據權限的設計也逐漸複雜甚至需要個性化開發。但從通用性上可以將數據權限劃為兩種類型：管理範圍、列表欄位。
管理範圍用於管理當前模塊的數據範圍，在多區域管理模式下，主要將數據分為個人、部門、單位、區域及自定義五個維度。
為了支持業務中個性化的數據管理要求，可以通過自定義實現數據的個性化管理；另外區域維度需要組織架構支持，如果區域較少時，可以直接考慮通過自定義來實現。
列表欄位用於同一列表同一數據範圍下繼續細分的數據權限管理，以實現同一數據下對部分敏感信息的隱藏。
圖8 數據權限
五、寫在最後從產品角度出發，在RBAC權限模型下，對業務數據的靈活配置，支持數據、操作權限的多層級下放，是滿足最多管理場景的設計模式。
但在項目角度，需要做好產品現狀及改造的成本評估，結合現場培訓、推廣及後續維護的工作難度，選擇合適的權限管理方式，才能儘快滿足項目驗收。
以本次項目為例，由於涉及單位較多，大型單位有頻繁的角色調整需求，部分一級單位需要查看附屬單位業務數據，但鎮街級單位或部分附屬單位人員較少，對系統使用要求不高。如果所有單位都自行管理系統角色，不僅增加了小型單位人員的工作量，還提高了前期推廣的培訓成本。
因此，對系統進行權限設計時，需要最大化場景考慮，以支持現場根據管理模式進行靈活調整。但現場也需要從實際業務出發，從自身成本與客戶利益角度選擇最優的管理方案。
我們規劃大型系統平臺時，除了關注系統功能之外，還需要了解客戶的管理模式，從更宏觀的角度觀察整個業務的布局。因此在本次復盤中，除了對權限設計的總結外，還嘗試歸納不同組織架構下權限的管理方式。
希望與各位一同進步，在ToB領域乘風破浪一往無前！
本文由 @龐龐 原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議