將軍令：資料安全平臺建設實踐

背景

近期，業內資料安全事件頻發，給相關企業造成了無可挽回的損失，更為資料安全防護意識薄弱的企業敲響了警鐘。如何對公司內部資料最為集中的資料分析、資料服務、資料治理等各種資料類產品進行許可權管控，已經成為資料安全建設中最為重要的任務。

如果從控制力的角度來進行劃分的話，許可權管控可以分為功能級許可權管控和資料級許可權管控。早期的資料安全產品大多使用傳統的許可權模型，只能實現功能級許可權管控，無法進行資料級許可權管控。基於資料類產品更高的安全要求，我們需要構建一個同時滿足各類產品資料安全的平臺。

為此，美團使用者平臺應用研發組不僅設計了能表達和管控各種複雜關係的許可權模型，還針對事前、事中、事後等三個場景，分別設計了審批、許可權、審計三個子系統以保障資料安全的完整閉環，進而滿足資料安全的各種要求。

許可權模型

傳統的許可權模型有ACL（Access Control List）訪問控制列表，RBAC（Role-Based Access Control）基於角色的訪問控制等。以上模型比較適用於應用型別產品的許可權管控，而資料型別的產品對資訊保安的要求更高，而且各類資源間的關係也更復雜，使用傳統的模型難以將內部關係進行清晰的表達，所以我們在RBAC許可權模型的基礎上，擴充套件設計了新的許可權模型。

• ACL訪問控制列表，使用者與許可權直接關聯，直接維護使用者與列表中資源的關係從而達到許可權管控的目的。

• RBAC模型則是角色與許可權進行關聯，使用者成為相應的角色而獲得對應的許可權。

為什麼要設計新的許可權模型？

1. ACL模型是使用者與資源直接建立關係，沒有角色的概念。當某些使用者需要一批同樣資源的許可權時，賦權操作就變得很複雜，此時這種模型就不太適應了。

2. RBAC模型引入了角色的概念，角色與資源建立關係。當某些使用者需要一批同樣資源的許可權時，只需要構建一個角色並賦予使用這批資源的許可權。當使用者加入這個角色時，則擁有該角色的所有許可權。解決了賦權操作複雜的問題。

不過ACL模型和RBAC模型，都存在以下幾個問題：

1. 資料類產品資源之間關係複雜，不能很好地表達這種複雜的關係。例如：一個報表下有多個標籤頁，一個標籤頁下有多個元件，一個元件下有多個維度、指標等。同時維度、指標又來自不同的資料模型、庫表等。資源與資源之間存在關係，當管理員給一個使用者賦予報表的全部或部分許可權時，報表下的子資源需要同時獲得對應的許可權。

2. RBAC模型中角色與角色之間沒有對應的關係。例如：組織架構中，員工所在的組織架構如下：華東區/銷售一區/銷售一組，員工擁有的角色是銷售一組的角色。當角色之間沒有關係時，員工如果需要華東區角色的許可權時，需要新增到華東區的角色中。而如果角色與角色之間具有從屬關係時，則能很好地解決這個問題。

新的許可權模型是如何解決上面這些問題的：

1. 設計資源模型時，資源與資源之間具有從屬關係，並且資源允許多層級，以樹形結構展示。例如報表是一個父資源，標籤、元件、維度指標都是報表下的子資源，這樣賦權時能清晰地展示出報表資源與下面的子資源的關係，賦權和鑑權時才能滿足各種許可權控制的要求。

2. 角色與角色之間具有從屬關係，例如員工在華東區/銷售一區/銷售一組的組織架構中，華東區/銷售一區/銷售一組這3個角色之間分別具有父子級的從屬關係，當員工在銷售一組部門下，則擁有華東區、銷售一區、銷售一組的所有許可權。當許可權不衝突時則直接合並所有許可權，衝突時則以“就近原則”進行覆蓋。

使用者中心：使用者管理、角色管理

• 角色分為個人、組織、自定義3種，一個使用者可以同時擁有多個角色，比如使用者預設對應一個個人角色，又可同時擁有在公司組織架構中組織角色、在自定義組織的自定義角色。

• 角色支援多層級，滿足角色間許可權繼承的表達方式。

• 使用者、部門資訊Mafka（美團基於Kafka開發的一個分散式訊息中介軟體綜合解決方案）實時更新，每天ETL定時同步，保證人員入職、轉崗、調離許可權實時同步。

• 資源型別支援自定義，在通用資源型別的基礎上支援自定義的資源接入，滿足各個系統不同資源的統一管控。

• 資源支援多層級，樹形結構的資源展示方式便於資源的統一賦權鑑權；給一個報表資源賦權時，掛在報表下的維度、指標等資源能統一獲得許可權。

• 支援資源打包簡化賦權流程。

• 資源安全密級、資源負責人，支援按照資源配置不同的審批模板進行許可權自助申請。

• 範圍策略：例如報表中的平臺維度的維值包括美團和大眾點評，賦權時，支援按要求給使用者賦予部分或全部許可權；鑑權時，按照規則解析為某人擁有某維度的部分或全部許可權。

• 表示式策略：當把報表給使用者賦權時，設定表示式為limit 10，表示當前使用者在該報表其他許可權的基礎上再進行限制，只能返回前10條記錄。

• 許可權自動合併：一個使用者擁有多個角色，多角色的同一資源的許可權鑑權時按照規則自動合併；規則解析時，許可權資料不衝突時取合集，衝突時按照優先順序取對應的值。

• 黑白名單：支援按照特定的規則，對某人針對某資源全面開發和封禁，黑白名單策略的優先順序最高，其中黑名單高於白名單。

挑戰

在建設資料安全平臺的過程中，主要面臨以下幾點挑戰：

• 隨著支援的業務線增加，通用平臺的不能滿足各個業務線的定製需求時，需要保證系統的靈活可擴充套件。

• 提供一個通用的資料安全平臺，滿足大部分的資料安全的要求，保證系統的通用性。

• 許可權系統作為一個高QPS訪問的系統，如何保證系統的高可用。

解決思路

1. 提供靈活可插拔的Plugin服務，在通用許可權基礎上，滿足各個業務線靈活的許可權管控要求。

2. 提供一個通用的資料安全平臺，滿足基本的許可權、審批、審計的基礎功能。

3. 微服務架構、核心與非核心服務分離、資料快取降級滿足系統高可用。

解決方案

• 提供各種靈活可插拔的Plugin服務，支援在通用服務的基礎基礎上進行定製開發。

• 提供基礎服務，滿足各種通用的資料安全要求。

• 提供管理工作臺，支援管理員對各種資料和規則進行頁面管理和配置。

具體方案

Plugin服務層，保證系統靈活可擴充套件

在滿足通用許可權的基礎上，各個業務線難免會有定製的許可權管控需求，於是設計了許可權Plugin模組。

通用服務提供使用者管理、資源管理、鑑權授權的服務，Plugin呼叫基礎服務實現特殊的許可權管控。Plugin模組的應用和資料各自單獨管理，通過RPC方式呼叫通用服務實現靈活可插拔。後續Plugin模組的服務支援各個接入的應用單獨定製開發。

• 通用服務提供使用者、資源、鑑權授權等通用服務，大部分的系統基於通用服務即可實現許可權管控要求。

• Plugin服務基於通用服務對外提供的SDK進行擴充，各個Plugin服務單獨部署，保證系統之間互相獨立。

最終的許可權實現分層管控，分為核心資料層（使用者、資源、許可權資料）和應用層。核心資料層的資料由通用服務進行管理，達到許可權資料統一管控的要求。應用層以Plugin服務方式接入，Plugin通過通用服務層對外的SDK進行許可權資料讀寫，達到定製的管控要求。應用層的資料各自儲存，可以自定義管控規則。介面之間的呼叫通過BA認證鑑權，保證服務之間呼叫的安全性。

基礎服務層，保證系統通用性

通用許可權系統架構

使用微服務架構設計，系統分為接入層、服務層、資料庫層、以及外部服務層。主要包含以下幾個核心服務：

• 使用者服務：主要包含使用者和部門資訊同步、角色管理。

• 資源服務：包含資源註冊、資源定時同步、資源密級及管理員管理、資源包管理。

• 賦權服務：許可權自助申請、管理員賦權。

• 鑑權服務：提供各種鑑權的SDK供使用方呼叫。

• 接入層：對外所有系統通過統一的SDK呼叫服務。

• 服務層：微服務架構，各個服務之間互相之間提供服務。

• 資料庫層：合理利用快取、資料降級，保證服務高可用。

• 整合公司公共服務，保證系統穩健執行。

審批系統架構

提供通用的審批服務，提供多級審批模板，使用時選擇模板啟動審批流，審批系統按照啟動的引數進行規則解析，自動適配對應的審批流程。縮減接入流程支援一鍵接入。

• 前期開發一個審批功能需要6個步驟，繪製流程圖，配置審批的組和成員，配置通知的訊息，配置事件對映，啟動審批流，開發回撥介面改狀態。

• 而我們在平臺的審批服務基礎上進行封裝，提供通用的審批模板，接入審批系統只需要選擇模板啟動審批流，並提供回撥介面即可。能滿足大部分的審批功能。

提供通用的規則解析引擎，支援審批人、審批條件、審批通知按照規則動態解析匹配。靈活實現自動審批、多人多級審批、定時催辦等多種通用功能。

對接許可權和審計系統，保證審批系統資料安全：

• 對接許可權系統，提供管理員許可權管控。

• 對接審計系統，運算元據落到審計系統便於後續的資料審計。

審計系統架構

提供通用的資料審計服務，客戶端日誌埋點上報，審計日誌按型別落到Elasticsearch中儲存。對接如意視覺化報表出審計報告，對接許可權系統管控資料許可權。

• 每個應用對應一個appkey，每個appkey按照模板分日期自動建立一個索引，支援自動擴充套件。

• 每種型別的審計日誌對應Elasticsearch索引中的一個type，新增一種操作日誌時，type自動建立。

• 審計日誌中的欄位對應type中的欄位，新增欄位時自動擴充套件。

保證系統高可用

微服務架構服務分離

隨著系統的模組功能越來越多，單一架構模式已不再適合敏捷開發，模組越來越大系統啟動則越慢，任一模組出錯則整個系統的服務都不可用。

為了保證服務的高可用和擴充套件性，於是以微服務架構把模組進行拆分，並把核心與非核心服務進行分離。

• 前端接入層通過HTTP接入，BA認證校驗請求合法性，通過Nginx負載均衡。

• 管理控制檯，通過呼叫服務層的各個服務實現統一管理。

• 服務層，抽象系統各個模組，每個模組都是一個微服務，每一個微服務都獨立部署，可以根據每個服務的規模按需部署。

• Client層，對外提供統一的Pigeon（美團內部分散式服務RPC通訊框架）介面，通過POM引入呼叫服務層各個服務。

許可權繼承

由於資源支援多層級，設計許可權模型時支援許可權繼承，當賦權時開啟繼承，則使用者預設擁有該資源以及下面所有資源的全部許可權，資料儲存時只需要儲存祖先資源與使用者之間的關係。大大減少了許可權矩陣大小。

接入的系統越多，則資源和使用者就越多。隨著系統執行越久，對應的許可權資料也會隨之快速增長。如何在資料增長的同時保證介面的效能和高可用。

許可權備份與恢復

參照HBase的版本號和MySQL的Binlog的設計思路，賦權時許可權只儲存當前使用者最新許可權資料，歷史許可權資料和操作記錄用版本號的方式儲存到Elasticsearch中。使用者鑑權時只需要查詢MySQL的許可權資料即可，保證鑑權介面的高效性。

• 賦權操作時，通過版本號管理許可權資料，每次操作後版本號加1，MySQL和Redis中只儲存最新的許可權資料。

• 歷史許可權資料通過版本號的方式儲存到Elasticsearch中，每次檢視歷史操作記錄或恢復許可權資料時，根據版本號回溯即可。

許可權過期清理

• 通過Crane定時排程，根據配置的通知規則，掃描即將過期的許可權資料，傳送訊息通知使用者進行許可權續期。

• 掃描已過期的許可權資料，清理MySQL和Redis中的過期許可權資料，並轉儲到Elasticsearch中儲存，已備後續的許可權審計。

資料讀寫分離、快取、備份以及服務熔斷降級

各個服務使用MySQL分庫儲存，使用Zebra（美團資料庫訪問層中介軟體）進行讀寫分離；合理使用資料快取與備份，並支援服務的熔斷降級，以保證服務的高可用。

• 各個服務使用MySQL分庫儲存；核心服務與非核心服務分離，服務和資料庫支援按需彈性擴充。

• 角色、資源等熱點資料使用Redis做快取，並在Redis快取不可用時自動下沉到MySQL進行查詢。

• 操作記錄和歷史資料等不活躍資料落地到Elasticsearch，以便審計和資料恢復。

• 服務不可用時支援熔斷降級，以保證核心服務的可用性。

合理使用訊息佇列、任務排程、執行緒池、分散式鎖

使用訊息佇列、任務排程、執行緒池進行非同步、削峰、解耦合，減少服務響應時間，提升使用者體驗。並使用分散式鎖保證資料一致性。

• 使用訊息佇列處理使用者請求，實時返回操作成功，後臺根據接受到的MQ訊息非同步進行處理並修改狀態，頁面輪詢狀態展示最終結果或傳送大象（美團內部通訊工具）訊息進行最終結果推送。

• 需要定時同步的任務通過Crane分散式任務排程平臺進行定時排程執行。

• 審批迴調時使用執行緒池處理審批結果回撥與失敗重試，較少建立銷燬執行緒的開銷。

• 分散式鎖，保證同一個方法在同一操作上只能被一臺機器上的一個執行緒執行，避免使用者重複提交或者多機器重複處理導致的資料不一致。

展望

作為一個通用的資料安全平臺，各個業務線的各種定製需求不可能都滿足。目前在系統架構上已支援提供多個可插拔的Plugin服務，在通用服務的基礎上實現定製的許可權管控。後續將軍令將針對許可權、審批、審計提供Plugin開發規範，支援接入的系統在現有的基礎上進行定製開發。

• 後續將對外提供統一的Plugin開發規範，支援各個接入方系統以Plugin服務的形式在平臺基礎服務之上進行定製開發，以滿足各自的特殊許可權管控要求。從而實現資料產品許可權集中管控確保資料安全。

• 把將軍令中的規則從現有的服務中分離出來，抽象出一個通用的規則引擎服務，實現規則靈活可配置。

作者簡介

夷山，美團點評技術專家，現任TechClub-Java俱樂部主席，2006年畢業於武漢大學，先後就職於IBM、用友、風行以及阿里。2014年加入美團，長期致力於BI工具、資料安全與資料質量工作等方向。

中華，美團點評資料系統研發工程師，2017年加入美團點評資料中心，長期從事於BI工具、資料安全相關工作。