作者 | 天地練心
導讀
本文詳細探討了統一權限管理服務（MPS）的設計與開發，針對企業內部多平台權限管理混亂的問題，提出了一套綜合RBAC、ACL、DAC權限模型的解決方案。文章從需求分析、技術選型、功能設計等方面全面介紹了MPS的構建過程。在平台&節點管理方面，MPS支持多種業務平台接入方式，同時提供節點管理和組織管理功能。權限管理模塊涵蓋歷史權限導入、權限分配、鑑權服務等。申請&授權模塊實現了線上申請、審批流程和自動授權功能。權限審計&回收模塊支持權限數據下載、操作日誌記錄以及權限續期與回收。MPS的成功應用於百度內部展示了其卓越性能與潛力，有望為未來實現更高效的企業權限管理提供強有力的支持。
全文6171字，預計閲讀時間16分鐘。
01 背景
在當今信息技術高速發展的時代，企業內部的應用系統和數據平台日益增多，這些平台負責的業務、功能設計不盡相同，各平台權限系統自建，沒有統一的權限設計和規範的權限管理，導致出現權限管理混亂和層級劃分不明的問題。為了解決這一問題，移動數據中台決定開發一套統一權限管理服務（MEDD Permission Service，以下簡稱MPS），旨在整合數據中台所有平台權限，實現打通平台權限、業務、用户的集中管理，為未來實現全面的數據權限和平台工具互通的權限管理方式提供強有力的管理服務。
本文將詳細介紹統一權限管理服務的設計與實現，包括需求分析、技術選型、功能設計、平台&節點管理、權限管理、申請&授權、權限審計與回收等方面的內容。
02 需求分析
在需求分析階段，需要與相關的業務平台和數據平台團隊溝通，瞭解他們的權限系統特點、權限管理問題以及他們對統一權限管理服務的期望。需求分析主要包括：
平台權限整合：確定需要整合的業務平台和數據平台，瞭解它們的權限系統架構和功能，以便確保MPS能夠與它們無縫集成。
權限層級劃分：明確權限的層級劃分，包括用户角色、組織結構、資源類型等，以便建立合理的權限模型。
統一認證：確定是否需要引入統一的認證機制，以提高用户體驗和安全性。
審批流程：定義權限的申請、審批和回收流程，確保安全性和靈活性，同時考慮審批流程的可定製性。
API接口：考慮業務平台如何接入MPS，設計簡潔且易於集成的API接口，同時確保接口的安全性。
03 技術選型
MPS選擇使用GDP（Go Develop Platform）框架開發，GDP作為百度內部研發的Go開發框架，具備以下優勢：
廠內基礎設施支持：GDP在百度內部得到廣泛應用，因此可以更好地與百度內部的基礎設施和生態系統進行集成，提供更穩定和高效的服務。
易配置、易組裝：權限管理服務可能需要根據不同業務平台的要求進行靈活的組裝和配置，GDP的易配置、易組裝特性能夠幫助實現這一點。
RPC能力和通用基礎庫：權限管理服務需要與其他系統進行通信和集成，GDP提供了完善的RPC Client和RPC Server能力，同時配備通用基礎庫，有助於快速開發和集成。
支持標準化監控：GDP支持基於Prometheus的標準化監控解決方案，這有助於對MPS進行全面監控和運維。
04 權限模型設計
完成了業務平台的需求分析之後，我們要基於確定接入的業務平台的業務場景確定使用的權限模型，MPS採用了綜合RBAC和ACL、DAC的權限模型，以實現靈活、精確的權限控制。這種綜合模型結合了三種訪問控制的優點，為業務平台權限管理提供了更多的靈活性和粒度控制。
MPS將業務平台的權限分為兩大類：
業務權限：業務平台用户對某個節點或者權限包的權限，分為業務讀權限、業務寫權限和自定義權限類型。例如，用户在業務平台查看報表時所需要的讀權限。
管理權限：在MPS系統業務平台界面進行操作的權限，具體分為以下操作：
- 操作業務平台用户並授予其節點或權限包的權限。
- 操作業務平台權限包變更。
- 操作業務平台節點上、下線和屬性及結構變更。
MPS通過將權限分類後靈活運用到ACL、DAC和RBAC三種權限模型中。
ACL（Access Control List）：ACL是一種基於資源的訪問控制模型，它將資源的訪問權限授予用户或用户組的列表。每個資源都有一個ACL，其中列出了允許或拒絕訪問該資源的主體及其對應的權限。ACL模型適用於細粒度的訪問控制，可以實現針對單個資源的精確權限管理。ACL模型在MPS中體現為支持授予用户特點節點的權限，從而實現對節點的細粒度訪問控制。
DAC（Discretionary Access Control）：DAC是一種基於資源所有者的訪問控制模型，資源的所有者有權自主決定誰有權訪問其資源。在DAC模型中，資源的訪問權限由資源的所有者設置，他們可以授權其他用户或用户組來訪問自己的資源，並可以隨時撤銷這些授權。結合DAC模型的思想，MPS基於業務平台定義了不同用户角色，如超級管理員、節點管理員、普通用户等，每個用户角色擁有不同的菜單和節點管理權限, 有用户角色的用户可以自主的授予所屬業務平台其他用户的業務權限。
RBAC（Role-Based Access Control）：RBAC是一種基於角色的訪問控制模型，它將權限授予角色，再將角色授予用户。在RBAC模型中，角色代表一組相關的權限，而用户通過被分配到相應的角色來獲取權限。RBAC模型適用於大規模的訪問控制，通過角色的管理可以簡化權限分配和維護，提高了權限管理的效率和可維護性。MPS支持用户將多個節點組合為權限包，再將用户加入到權限包的方式授權。
05 功能設計
根據需求分析的結果，對MPS進行功能劃分，將權限管理服務劃分為四大模塊，每個模塊負責不同的功能。
1、平台&節點管理：
- 支持多個平台的接入，支持使用默認模板參數和定製化參數
- 支持節點的接入和組織管理。節點定義：業務平台抽象的需要進行權限管理的資源，例如報表、按鈕、頁面鏈接等
2、權限管理：
- 歷史權限導入
- 平台管理權限的增刪改查功能
- 平台業務權限的增刪改查功能
- 鑑權服務
3、申請&授權：
- 用户線上申請、定製審批流程、審批通過自動授權
- 權限變更後回調業務平台，可自定義回調方法
4、權限審計&回收：
- 權限到期、用户離職轉崗等場景下權限自動回收
- 業務平台操作記錄推送
- 權限審計數據下載
06 平台&節點管理
業務平台接入MPS需要提供以下初始化參數：
- 平台基本信息，存儲在圖表 1中的平台基礎信息表
- 平台的自定義權限類型，MPS默認為每個平台生成業務讀、寫權限，平台可以自定義更多的業務權限類型，存儲在圖表 1中的平台權限類型表
- 平台定製化菜單欄，MPS默認提供通用的菜單欄，平台可以選擇使用其中一部分，存儲在圖表 1中的平台菜單表
△圖表 1 業務平台管理
初始化參數確定之後，MPS會創建一個基礎業務平台（見圖表 3）。MPS為每個業務平台初始化一個初始節點，同時生成openapi訪問密匙，存儲在圖表 1中的平台密匙表，MPS提供了完善的openapi接口，密匙分為主密匙和次密匙，主密匙可以訪問MPS提供的所有openapi接口，次密匙在生成的時候需要指定訪問的openapi接口範圍，訪問超出範圍的api會鑑權失敗。
平台初始化完成之後，業務平台開發工程師可以將業務節點同步到MPS了，MPS提供了兩種節點同步方案：
推：業務平台將業務中需要進行權限管控的資源抽象為樹結構，並通過MPS提供的節點相關openapi接口將業務節點樹同步到MPS平台。
拉：業務平台需要按照MPS指定返回數據格式提供一個獲取節點樹結構的接口，MPS會實時獲取業務節點數據，並將其掛載在初始節點下。
方案一MPS會在本地存儲節點數據，分為兩張表存儲，基礎信息存儲在節點信息表，樹結構關係存儲在節點樹組織表（見圖表 2）。
△圖表 2 節點管理
方案一當業務節點變化的時候，例如報表下線，需要業務方將變化同步到MPS，如果同步失敗會導致數據不一致問題，可以通過定時全量同步和錯誤報警解決，優勢在於MPS存儲了節點數據，可以提供穩定的權限管理服務。
方案二優勢在於實時去獲取業務方的節點數據，可以第一時間感知節點變化，劣勢在於如果獲取數據失敗，只能使用緩存數據，可能和實時節點數據有差異，影響部分功能的使用。
綜上，考慮到業務平台的節點變化頻率有限，權限管理服務更注重系統的可用性和可靠性，MPS推薦使用方案一。
△圖表 3 MPS基礎業務平台
07 權限管理
業務平台接入MPS之後，為了不影響現有用户使用體驗，需要將已有的用户業務權限數據導入到MPS中，MPS為此提供了批量添加權限的openapi接口。
歷史用户權限數據導入完成後，對於增量業務權限，需要先添加平台管理員，管理員再通過MPS界面對用户進行授權操作。
業務平台的平台管理員分為兩種類型：
超級管理員：有所有菜單權限和所有節點的管理權限
節點管理員：有部分菜單權限和部分節點的管理權限，將用户設置為某個節點的節點管理員，用户可以管理此節點和下面的所有子節點。
一般來説，一個平台的超級管理員控制在2-3人，作為兜底的負責人使用，具體授權操作由業務平台下各個節點管理員負責。
為了實現同一個用户在MPS中多個業務平台之間的權限隔離，用户需要在MPS建立一個業務平台賬號。平台管理員可以先搜索一個用户，如果這個用户不是當前平台的用户，需要先將用户添加到平台，MPS在用户基礎信息表存儲用户的基本信息，在用户平台賬户表存儲用户在每個平台的賬户信息，這樣縱向通過用户賬户將用户在每個平台數據隔離開，橫向又可以通過用户名總覽用户跨平台的權限，方便權限review使用。
MPS支持兩種權限授權管理方式：
- 直接給用户添加節點的權限
- 將多個節點添加到權限包（見圖表 4），再將用户添加到權限包
第一種方式在權限review時更加清晰，第二種方式在批量添加權限時更方便。
△圖表 4 權限包創建
添加完用户權限之後，業務平台開發工程師需要在業務系統內部接入MPS的鑑權服務，當用户登錄業務平台訪問資源時，調用MPS的鑑權接口計算用户權限，MPS鑑權服務支持多種權限計算參數：
繼承父級權限：計算用户對於某個節點的權限時，可以只計算當前節點權限，也可以選擇繼承模式，從當前節點遞歸尋找父節點權限，直到尋找到或者到達根節點為止。
權限包或節點權限優先：支持權限包權限和節點權限哪個計算優先級更高，也可以混合計算。
△圖表 5 用户權限管理
08 申請&授權
業務平台用户添加權限可以通過平台管理員手動授權，但是這種方法的劣勢很明顯：
- 用户需要和管理員溝通並郵件或者IM備案，效率低下
- 權限管理佔用了管理員大量時間且可能誤操作
- 權限review時，查找權限開通的全流程記錄成本高
為了提升工作效率，減少用户和管理員負擔，設計瞭如圖表 6的線上授權流程
△圖表 6 用户線上申請流程
MPS平台設計了兩種線上申請的接入模式：
完全託管模式：MPS提供了一套通用的權限審批模型和申請頁面（如圖表 7），業務平台在用户訪問資源無權限時跳轉到MPS權限申請頁面。對於用户來説只需要關心填寫工單內容和選擇申請的節點或者權限包，對於平台只需要定製好每個節點的審批人。
自建頁面模式：如果通用的權限申請頁面不滿足業務平台的需求，可以自行開發前端頁面，之後調用MPS的申請單提交接口即可，後續的審批和授權由MPS負責。
△圖表 7 MPS申請頁面
MPS使用百度內部流程系統來提供審批能力，審批流程可以理解為如圖表 8的鏈式步驟。通過調研接入的業務平台，發現不同平台的審批流程需求差異性較大，有些平台所有節點都只需要一位負責人審批，有些平台根據節點的不同設置不同的審批流程。對於流程系統需要先確定好審批流程，之後用户申請就生成一個審批流程的實例。可以把審批流程理解為程序代碼開發中的一個實體類，如果對於需要多種審批流程的平台每個審批流程的節點都定製一個類，管理成本較高且擴展不靈活。
為此，MPS調研了平台的已有審批流程，設計瞭如圖表 8所示的通用審批流程類，為每個節點設置是否需要的參數，相當於為通用審批流程類設置了一個多個參數的構造函數。數據審批人就是業務平台設置到節點上的審批人，業務平台可以在同步節點的時候指定審批人，也可以管理員在圖表 10中配置。業務平台的節點需要設置一個新的審批流程時只需要提供定製化的參數，就可以生成符合需求的審批實例。
△圖表 8 通用審批流程
△圖表 9 線上申請管理
△圖表 10 節點屬性變更
用户提交申請之後，由審批人進行審批，審批結束會回調MPS給用户進行授權，根據一些業務平台的需求MPS支持了事件回調，業務平台可以配置回調方法，當自動授權後可觸發業務平台回調。
09 權限審計&回收
對於業務平台來説，經常會以季度或者月為週期對某些節點的權限進行review，判斷用户權限是否符合預期，並回收不符合預期的用户權限，延長部分快到期的用户權限。
MPS提供了完善的權限審計能力:
- 用户權限下載：業務平台可以在報備之後下載節點用户權限數據。
- 每日操作日誌：MPS會記錄業務平台上管理員的所有權限操作和節點操作併發送郵件給配置的接收人。
- MPS提供了完善的權限續期&回收能力：
- 通過每天的定時任務檢測用户，收集有效期少於10天的用户權限，並向用户發送續期郵件，郵件中帶有續期申請的鏈接，用户可以跳轉到申請頁面申請權限續期。
- 每天定時獲取離職和轉崗的用户，對於離職用户，MPS會將該用户帳號的狀態設置為失效，業務平台鑑權時會判斷用户狀態，用户狀態為失效時，直接返回該用户無權限。對於轉崗用户，MPS會將該用户置於觀察名單，併發送郵件給用户的上級，由用户的上級來判斷是否保留該用户的權限，上級確認保留，用户從觀察名單移出，反之將該用户的賬號凍結。如果需要恢復用户權限時，也只需要恢復用户賬號的狀態即可。
MPS同時支持郵件訂閲服務，管理員只需要訂閲相關郵件，MPS會每天發送平台相關的權限變更郵件和抄送發送給平台用户的郵件。
△圖表 11 權限回收和審計
10 總結
經過接入平台推廣效應的推動，結合使用用户的反饋意見進行升級和性能提升，MPS已成為數據中心的核心權限系統，並在百度MEG內部獲得廣泛應用。其接入已覆蓋近40個業務平台，有效管理超過10萬個權限節點，涵蓋50多個審批模型。每月處理約2000至3000條權限申請工單，服務超過2萬名用户。每日API調用峯值高達130萬次，並能夠提供每日30萬次的鑑權服務。
MPS的卓越性能源於明確的管理功能劃分和通用權限審批模型的巧妙應用。這為系統提供了強大的權限管理、申請和授權功能，解決了過去權限管理混亂和層級不明確的問題。同時，它還保障了數據的安全性與合規性，顯著提升了用户體驗和工作效率。
展望未來，MPS具備進一步擴展和通用化的潛力，可以為更多業務平台接入提供支持，實現全面的一體化權限管理，促進平台工具之間的互通。這必將進一步增強移動數據中心的權限管理體系，為企業提供更高效可靠的權限管理服務。
——END——
推薦閲讀
百度APP iOS端包體積50M優化實踐(五) HEIC圖片和無用類優化實踐
百度知道上雲與架構演進
百度APP iOS端包體積50M優化實踐(四)代碼優化
百度App啓動性能優化實踐篇
掃光動效在移動端應用實踐
