RBAC模型是通過分離權限與用戶的耦合關系，將權限關聯(lián)在角色上，用戶通過扮演適當?shù)慕巧@得合適的權限的權限管理方式。本文在RBAC模型的基礎下，整理權限設計過程中的客戶場景、總結設計思路。

一、項目背景

本項目是一個關于OA系統(tǒng)升級改造的ToG項目，涉及3000+單位5萬用戶，橫跨市–區(qū)縣–鎮(zhèn)街3層行政區(qū)劃。各單位之間業(yè)務信息交流頻繁，業(yè)務上經(jīng)常需要跨單位、跨部門的協(xié)同運作。在系統(tǒng)層面，所有單位均在同一租戶下，由基礎平臺負責各業(yè)務子系統(tǒng)權限的統(tǒng)一管理。

二、從組織架構看權限的管理模式

回顧整個項目，在進行權限設計之前，必需先了解現(xiàn)場的組織架構。因為RBAC模型主要描述的只是用戶–角色–權限之間的關系，而決定RBAC模型復雜程度的是業(yè)務上的組織架構。

當組織架構達到一定量級的復雜程度后，根據(jù)系統(tǒng)部署的方式或管理理念的不同，會分化出不同的權限管理模式，不同的管理模式對系統(tǒng)權限設計也會有不一樣的要求。

下面以全市組織架構為例進行說明：

圖1 組織架構層級

1. 組織架構說明

以上的組織架構主要分為5種層級：

1. 行政區(qū)劃：具有業(yè)務屬性的單位集合；可用于數(shù)據(jù)權限劃分時的區(qū)域劃分；
2. 集合：沒有業(yè)務屬性的單位集合；通過集合的歸類，讓用戶更便捷地找到所需單位；
3. 單位：基礎的權限單元，指機關、團體或企業(yè)；
4. 部門：基礎的權限單元，指單位的下級分支機構；
5. 用戶：組織架構組成的最小單元。

2. 不同組織架構下的權限模型

1）基礎權限模型

適用場景：場景一 、場景二

基礎權限模型適用于單個單位或組織架構相對扁平的企業(yè)。系統(tǒng)完全交付后，通過系統(tǒng)管理員的管理即可滿足日常角色與權限的維護，各模塊業(yè)務數(shù)據(jù)需求明確，是基本的RBAC模型，其業(yè)務管理模式如下：

• 由系統(tǒng)管理員負責角色的權限及用戶分配。
• 由系統(tǒng)管理員創(chuàng)建單位管理員角色，由單位管理員負責角色的權限及用戶分配。

因此，在這種模式下，系統(tǒng)管理經(jīng)常兼任單位管理員的管理工作，對權限下放的設計要求不高，其角色樹如圖2所示。

圖2 系統(tǒng)管理員≥單位管理員＞業(yè)務角色

RBAC模型已經(jīng)定義了“用戶–角色–權限”的授權模式，將系統(tǒng)功能拆分為操作權限與數(shù)據(jù)權限兩個維度進行設計。在此框架下設計的權限模型，不管面向的企業(yè)對象如何變化，操作權限的設計思路都是不變的，僅需要對數(shù)據(jù)權限進行改造，即可滿足企業(yè)的業(yè)務使用。

2）多單位管理模型

適用場景：場景三 、場景四

多單位管理模型適用于大中型單位組織架構，單位之間存在上下級關系且業(yè)務交流頻繁。由于單位間的管理關系，需要橫向或縱向的跨單位數(shù)據(jù)管理，考驗權限對數(shù)據(jù)靈活配置的能力。

因此，大型系統(tǒng)的RBAC管理過程更為復雜，此時簡單的RBAC已不能滿足系統(tǒng)的訪問控制分級管理的要求。尤其在信息系統(tǒng)中存儲和管理大量企業(yè)單位的敏感數(shù)據(jù)，一旦這些數(shù)據(jù)被泄露或竊取，會給帶來難以彌補的損失。

另外在企業(yè)運營中經(jīng)常需要對組織架構和人員工作進行調(diào)整，相應地需要修改系統(tǒng)中訪問控制主體和權限的關系。而系統(tǒng)管理員由于不了解調(diào)整內(nèi)容導致授權工作滯后，即使修改后也不一定能準確反映調(diào)整狀態(tài)，常需要多次補充修改，導致授權效率較低，影響正常的業(yè)務工作進程。

為了解決信息系統(tǒng)中訪問控制管理的問題，適當簡化授權工作量，提高權限管理效率，需要建立基于角色的多單位授權管理模型，其業(yè)務管理模式如下：

• 由系統(tǒng)管理員負責角色的權限及用戶分配。
• 由系統(tǒng)管理員負責角色的權限分配，同時賦予單位管理員對角色分配用戶的權限（定義標準角色，實現(xiàn)權限管理的部分下放）。
• 由系統(tǒng)管理員負責創(chuàng)建單位管理員角色，由單位管理員負責角色的權限及用戶分配（不定義標準業(yè)務角色，實現(xiàn)權限的完全下放）。

在此模式下，系統(tǒng)管理員不再兼任單位管理員工作，需要實現(xiàn)權限的多級下放。

在場景四中，由于業(yè)務上對單位群進行劃分，需要系統(tǒng)管理員或特定區(qū)域管理員管理單位集合或超出單位管理員權限的特殊角色，角色樹較場景三更加復雜，具體角色樹如圖3所示。

圖3 系統(tǒng)管理員≥區(qū)域管理員＞單位管理員＞業(yè)務角色

3）多區(qū)域管理模型

適用場景：場景五

多區(qū)域管理模式是多單位管理模型的拓展。

首先是對數(shù)據(jù)管理的要求更高，除了系統(tǒng)、單位、科室、個人的層級外，需要新增區(qū)域?qū)蛹壱怨芾砟骋环秶鷥?nèi)的數(shù)據(jù)信息。

其次，由于涉及多層級的權限管理，在滿足多級權限下放需求，需要充分考慮不同層級角色對某一角色的管理問題、小權限角色對大權限角色的管理問題等。例如：區(qū)域管理與單位管理對某業(yè)務角色進行管理時，由于自身權限不同，可下放給此角色的權限也不相同。

如何避免小權限角色對大權限角色造成影響，需要我們結合業(yè)務實際使用情況進行設計。

業(yè)務管理模式如下：

• 由系統(tǒng)管理員負責角色的權限分配，同時賦予區(qū)域管理員、單位管理員對角色分配用戶的權限（定義標準角色，實現(xiàn)權限管理的部分下放）。
• 由系統(tǒng)管理員負責創(chuàng)建區(qū)域管理員角色，由區(qū)域管理員分配單位管理員角色，由單位管理員負責角色的權限及用戶分配（不定義標準業(yè)務角色，實現(xiàn)權限的完全下放）。

在此模式下，系統(tǒng)管理員也不再兼任區(qū)域管理員工作，角色樹如圖4所示。其中角色1-3為區(qū)域管理員，角色4-8為單位管理員。

圖4 系統(tǒng)管理員＞區(qū)域管理員＞單位管理員＞業(yè)務角色

三、定義角色、職位、職務之間的關系

在我們用戶信息管理中，需要填寫用戶的職位或職務，在定義角色、職位與職務的關系之前，需要先明確職位與職務之間的關系。

職位：指企業(yè)的某個員工需要完成的一個或一組任務；例如：銷售總監(jiān) 、銷售經(jīng)理、財務/出納員、司機、倉庫管理員等。

職務：職員所具有的頭銜稱謂，包括職權和職責兩方面內(nèi)容，隨著語義的拓展職位亦有此意思；例如：科員，主任，經(jīng)理，總經(jīng)理。

因此，職位包含職務的意義，職務基本也與職位相對應。而系統(tǒng)中的權限，是用戶在現(xiàn)實工作中的權限或工作范疇在系統(tǒng)中的映射。為了簡化角色與職位之間的關系，定義現(xiàn)實中用戶職位或職務中包含的權限，在系統(tǒng)上均通過角色進行管理設置。

四、角色權限的設計

角色設計主要分為角色管理、分配用戶及分配權限3個模塊，通過對這3個模塊的控制，實現(xiàn)多區(qū)域管理模型下的權限設計。

1. 角色管理

在多區(qū)域管理模型下，需要支持權限統(tǒng)一管理與多層級權限下放兩種場景。

分離角色的管理與使用權限，由創(chuàng)建單位對角色權限進行管理，創(chuàng)建單位與使用單位共同分配用戶，可滿足權限統(tǒng)一管理要求的同時，兼具各單位自行調(diào)整用戶的需求。

圖5 系統(tǒng)角色管理

2. 分配用戶

分配用戶的頁面，需要根據(jù)用戶當前管理的權限范圍進行控制，僅支持查看和分配管轄范圍內(nèi)的用戶。例如單位管理員僅支持查看和分配自己單位的用戶，系統(tǒng)管理員可查看并分配系統(tǒng)內(nèi)的所有用戶。

由于同一角色可能支持多個管理員分配用戶，為了系統(tǒng)安全與方便追溯，可通過操作人字段記錄此用戶是由誰進行分配的。

圖6 分配用戶

3. 分配權限

為了實現(xiàn)對系統(tǒng)各模塊的權限管理，將每個模塊劃分為3個部分：菜單、頁面數(shù)據(jù)、按鈕。其中將菜單及按鈕納入操作權限，將頁面數(shù)據(jù)歸為數(shù)據(jù)權限。

由于各功能模塊都是根據(jù)業(yè)務具體場景進行設計開發(fā)的，因此權限也需要根據(jù)業(yè)務具體要求而進行劃分與設計。但為了系統(tǒng)的統(tǒng)一管理，可以建立統(tǒng)一的設計規(guī)范，以維持系統(tǒng)架構統(tǒng)一甚至減少開發(fā)工作量。

1）操作權限
操作權限用于控制此角色在系統(tǒng)中可對哪些模塊做哪種操作。

通過控制菜單，實現(xiàn)管理用戶控制特定模塊的需求；通過頁面按鈕，實現(xiàn)控制用戶在此模塊下可以進行的操作。

以角色管理頁面為例，分配角色管理菜單的用戶，即可查看對應的角色數(shù)據(jù)，再通過對“新增”“刪除”“啟用”“禁用”等按鈕的控制，限制用戶在此模塊下的操作。

部分頁面的字段還需要區(qū)分“只讀”“可改”，以實現(xiàn)各角色在相同頁面中不同的管理需求。

圖7 操作權限

2）數(shù)據(jù)權限

數(shù)據(jù)權限是權限管理中最核心的部分，隨著組織架構的復雜，數(shù)據(jù)權限的設計也逐漸復雜甚至需要個性化開發(fā)。但從通用性上可以將數(shù)據(jù)權限劃為兩種類型：管理范圍、列表字段。

管理范圍用于管理當前模塊的數(shù)據(jù)范圍，在多區(qū)域管理模式下，主要將數(shù)據(jù)分為個人、部門、單位、區(qū)域及自定義五個維度。

為了支持業(yè)務中個性化的數(shù)據(jù)管理要求，可以通過自定義實現(xiàn)數(shù)據(jù)的個性化管理；另外區(qū)域維度需要組織架構支持，如果區(qū)域較少時，可以直接考慮通過自定義來實現(xiàn)。

列表字段用于同一列表同一數(shù)據(jù)范圍下繼續(xù)細分的數(shù)據(jù)權限管理，以實現(xiàn)同一數(shù)據(jù)下對部分敏感信息的隱藏。

圖8 數(shù)據(jù)權限

五、寫在最后

從產(chǎn)品角度出發(fā)，在RBAC權限模型下，對業(yè)務數(shù)據(jù)的靈活配置，支持數(shù)據(jù)、操作權限的多層級下放，是滿足最多管理場景的設計模式。

但在項目角度，需要做好產(chǎn)品現(xiàn)狀及改造的成本評估，結合現(xiàn)場培訓、推廣及后續(xù)維護的工作難度，選擇合適的權限管理方式，才能盡快滿足項目驗收。

以本次項目為例，由于涉及單位較多，大型單位有頻繁的角色調(diào)整需求，部分一級單位需要查看附屬單位業(yè)務數(shù)據(jù)，但鎮(zhèn)街級單位或部分附屬單位人員較少，對系統(tǒng)使用要求不高。如果所有單位都自行管理系統(tǒng)角色，不僅增加了小型單位人員的工作量，還提高了前期推廣的培訓成本。

因此，對系統(tǒng)進行權限設計時，需要最大化場景考慮，以支持現(xiàn)場根據(jù)管理模式進行靈活調(diào)整。但現(xiàn)場也需要從實際業(yè)務出發(fā)，從自身成本與客戶利益角度選擇最優(yōu)的管理方案。

我們規(guī)劃大型系統(tǒng)平臺時，除了關注系統(tǒng)功能之外，還需要了解客戶的管理模式，從更宏觀的角度觀察整個業(yè)務的布局。因此在本次復盤中，除了對權限設計的總結外，還嘗試歸納不同組織架構下權限的管理方式。

希望與各位一同進步，在ToB領域乘風破浪一往無前！

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

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