構建企業級用戶中心（下）：可擴展RBAC架構與權限治理模型_CRM|手機

【構建企業級用戶中心（下）：可擴展RBAC架構與權限治理模型】

文章圖片

在《構建企業級用戶中心（上）：核心價值、架構設計與功能模塊全景圖》中，我們解析了系統分層與核心模塊。本文作為系列終篇，將深入探討多業務系統下的RBAC擴展方案，覆蓋權限模型設計、角色治理框架、數據權限聯動三大核心場景，并附贈可復用的設計Checklist 。

RBAC：Role-Based Access Control 基于角色的訪問控制，主要包含角色、權限、用戶三者之間多對多的關系。
最常見的是單一業務系統建設中支持創建菜單權限，設置菜單路徑，角色關聯菜單，再將角色分給1個或n個用戶，而對于企業的用戶中心要考慮支持多個業務系統的角色權限，并將這些角色權限之間相互隔離，能在用戶詳情中查看到用戶擁有的每個業務系統的權限，權限大的管理員也能看到用戶沒有擁有的權限，并可直接為用戶分配沒有擁有的權限。用戶中心已支持創建多個業務系統、支持各個業務系統內單獨維護單點登錄的訪問權限，那么各個業務系統的角色權限及用戶也應在應用詳情內管理。

一、RBAC在企業級場景的挑戰與升級傳統RBAC（基于角色的訪問控制）在單一系統中表現良好，但面對企業多業務系統時需解決：

權限爆炸：N個系統×M個角色導致組合復雜度指數上升
跨系統隔離：電商客服角色（訂單系統權限）≠客服角色（CRM系統權限）
可視化管理：超級管理員需全局查看用戶權限分布

二、權限模塊設計：從樹形結構到動態規則

考慮到web端、手機端等不同使用端的菜單權限控制不同，需支持建立多個權限組，并且每個權限組的信息字段可進行定制化配置；
權限的基本管理功能，支持新增編輯刪除權限，支持移動權限，支持創建子權限，在刪除父權限時需將子權限都刪除完成，權限的啟用禁用，批量導入導出等功能；
權限一般為樹形菜單展示，便于清晰查看權限的層級結構；
因為用戶中心作為統一管理的位置，需將信息同步業務系統，需對應有相應的標準接口將權限可以同步至外部系統；
針對數據權限的設置，它也屬于權限的一種，但數據權限的設定無法和菜單權限保持一樣的設定，需要系統將常見的數據權限規則提前設計好，比如數據權限一般是設定可以看整個公司的數據、某個部門的數據等，那么部門的數據權限的數據維度就要提前設定好，以便于和組織機構管理模塊建立聯系。

三、角色模塊設計：柔性化治理框架

針對內部外部、上下級、多部門等情況的角色管理方式不同，用戶中心也應支持建立多個角色組，并且每個角色組的信息字段可進行定制化配置；如果角色管理的信息一致，也可以只建一個角色組，便于統一管理。
角色的基本管理功能，支持新增編輯刪除角色，支持移動角色，支持創建子角色，在刪除父角色時需將子角色都刪除完成、需要將角色下的用戶都移除掉才可刪除角色成功，角色的啟用禁用，批量導入導出等功能；
每個角色需分別綁定權限，綁定后的權限最好也為樹形展示，便于看出層級關系，對于未賦予的權限最好也能展示，因為角色管理主要為管理員服務，這么設計整體會非常清晰。
如果角色的管理需要到數據權限的級別，那么角色應支持綁定數據權限，不同角色可綁定不同維度的數據權限，并支持通過標準接口同步至外部系統；
角色編輯完成后可為角色分配人員，人員的角色分配可以在用戶詳情中，也可以在角色詳情中分配，一種是可以直接給一個用戶直接分配多個系統的角色，另一種可以直接給一個角色批量分配多個用戶，所以兩種方式都存在，對分配權限的管理者來講會增加很多便利性。
另外，對于批量操作，需要支持角色、用戶、數據權限的批量導入導出，方便數據維護與信息檢查。
有些企業的用戶管理會到崗位級別，如果業務系統的角色和崗位比較匹配，那么直接做成角色可以關聯崗位，之后有這個崗位的人員入職，就會自動分配角色。

綜上所屬，用戶中心設計時一方面要考慮怎么將相互關聯的功能設計的可拓展性更強，無論什么樣的業務系統接入用戶中心，都能滿足對應的需求，哪怕最開始沒想到，也應在后面的需求迭代中，以此原則為基礎展開；另一方面一定要著重考慮系統的便利性，因為用戶中心最后會分給各個業務系統的管理員，整體的操作實用性、自動性都需要全面考慮，盡量減少手工操作，釋放人效。
本文由 @產品貓頭鷹原創發布于人人都是產品經理。未經作者許可，禁止轉載
題圖來自Unsplash ，基于CC0協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務