將軍令：數據安全平臺建設實踐

背景

在大數據時代，數據已經成爲公司的核心競爭力。此前，咱們介紹了美團酒旅起源數據治理平臺的建設與實踐，主要是經過各類數據分析挖掘手段，爲公司發展決策和業務開展提供數據支持。

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

若是從控制力的角度來進行劃分的話，權限管控能夠分爲功能級權限管控和數據級權限管控。早期的數據安全產品大多使用傳統的權限模型，只能實現功能級權限管控，沒法進行數據級權限管控。基於數據類產品更高的安全要求，咱們須要構建一個同時知足各種產品數據安全的咱們須要構建一個同時知足各種產品數據安全的平臺。

爲此，美團用戶平臺應用研發組不只設計了能表達和管控各類複雜關係的權限模型，還針對事前、事中、過後等三個場景，分別設計了審批、權限、審計三個子系統以保障數據安全的完整閉環，進而知足數據安全的各類要求。

功能應用類產品的權限表達，通常爲「是否有權限」，而數據類產品權限表達的關係更加複雜。例如數據類產品的報表，不只須要表達出用戶可否訪問這個報表，並且須要表達出用戶能訪問報表中的哪些維度、指標以及維值的範圍。還須要告知這些維度指標來自於哪些庫表模型，是否有權限訪問以及建立報表。

權限模型

傳統的權限模型有ACL（Access Control List）訪問控制列表，RBAC（Role-Based Access Control）基於角色的訪問控制等。以上模型比較適用於應用類型產品的權限管控，而數據類型的產品對信息安全的要求更高，並且各種資源間的關係也更復雜，使用傳統的模型難以將內部關係進行清晰的表達，因此咱們在RBAC權限模型的基礎上，擴展設計了新的權限模型。

如圖2所示，傳統的權限模型：

• ACL訪問控制列表，用戶與權限直接關聯，直接維護用戶與列表中資源的關係從而達到權限管控的目的。
• RBAC模型則是角色與權限進行關聯，用戶成爲相應的角色而得到對應的權限。

爲何要設計新的權限模型？

1. ACL模型是用戶與資源直接創建關係，沒有角色的概念。當某些用戶須要一批一樣資源的權限時，賦權操做就變得很複雜，此時這種模型就不太適應了。
2. RBAC模型引入了角色的概念，角色與資源創建關係。當某些用戶須要一批一樣資源的權限時，只須要構建一個角色並賦予使用這批資源的權限。當用戶加入這個角色時，則擁有該角色的全部權限。解決了賦權操做複雜的問題。

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

1. 數據類產品資源之間關係複雜，不能很好地表達這種複雜的關係。例如：一個報表下有多個標籤頁，一個標籤頁下有多個組件，一個組件下有多個維度、指標等。同時維度、指標又來自不一樣的數據模型、庫表等。資源與資源之間存在關係，當管理員給一個用戶賦予報表的所有或部分權限時，報表下的子資源須要同時得到對應的權限。
2. RBAC模型中角色與角色之間沒有對應的關係。例如：組織架構中，員工所在的組織架構以下：華東區/銷售一區/銷售一組，員工擁有的角色是銷售一組的角色。當角色之間沒有關係時，員工若是須要華東區角色的權限時，須要添加到華東區的角色中。而若是角色與角色之間具備從屬關係時，則能很好地解決這個問題。

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

1. 設計資源模型時，資源與資源之間具備從屬關係，而且資源容許多層級，以樹形結構展現。例如報表是一個父資源，標籤、組件、維度指標都是報表下的子資源，這樣賦權時能清晰地展現出報表資源與下面的子資源的關係，賦權和鑑權時才能知足各類權限控制的要求。
2. 角色與角色之間具備從屬關係，例如員工在華東區/銷售一區/銷售一組的組織架構中，華東區/銷售一區/銷售一組這3個角色之間分別具備父子級的從屬關係，當員工在銷售一組部門下，則擁有華東區、銷售一區、銷售一組的全部權限。當權限不衝突時則直接合並全部權限，衝突時則以「就近原則」進行覆蓋。

如圖3所示，新的權限模型包含3個部分，用戶中心、資源中心、權限中心。

用戶中心：用戶管理、角色管理

• 角色分爲我的、組織、自定義3種，一個用戶能夠同時擁有多個角色，好比用戶默認對應一個我的角色，又可同時擁有在公司組織架構中組織角色、在自定義組織的自定義角色。
• 角色支持多層級，知足角色間權限繼承的表達方式。
• 用戶、部門信息Mafka（美團基於Kafka開發的一個分佈式消息中間件綜合解決方案）實時更新，天天ETL定時同步，保證人員入職、轉崗、調離權限實時同步。

資源中心：資源管理

• 資源類型支持自定義，在通用資源類型的基礎上支持自定義的資源接入，知足各個系統不一樣資源的統一管控。
• 資源支持多層級，樹形結構的資源展現方式便於資源的統一賦權鑑權；給一個報表資源賦權時，掛在報表下的維度、指標等資源能統一得到權限。
• 支持資源打包簡化賦權流程。
• 資源安全密級、資源負責人，支持按照資源配置不一樣的審批模板進行權限自助申請。

權限中心：角色與資源的關係的多種策略表達

• 範圍策略：例如報表中的平臺維度的維值包括美團和大衆點評，賦權時，支持按要求給用戶賦予部分或所有權限；鑑權時，按照規則解析爲某人擁有某維度的部分或所有權限。
• 表達式策略：當把報表給用戶賦權時，設置表達式爲limit 10，表示當前用戶在該報表其餘權限的基礎上再進行限制，只能返回前10條記錄。
• 權限自動合併：一個用戶擁有多個角色，多角色的同一資源的權限鑑權時按照規則自動合併；規則解析時，權限數據不衝突時取合集，衝突時按照優先級取對應的值。
• 黑白名單：支持按照特定的規則，對某人針對某資源全面開發和封禁，黑白名單策略的優先級最高，其中黑名單高於白名單。

挑戰

在建設數據安全平臺的過程當中，主要面臨如下幾點挑戰：

• 隨着支持的業務線增長，通用平臺的不能知足各個業務線的定製需求時，須要保證系統的靈活可擴展。
• 提供一個通用的數據安全平臺，知足大部分的數據安全的要求，保證系統的通用性。
• 權限系統做爲一個高QPS訪問的系統，如何保證系統的高可用。

解決思路

1. 提供靈活可插拔的Plugin服務，在通用權限基礎上，知足各個業務線靈活的權限管控要求。
2. 提供一個通用的數據安全平臺，知足基本的權限、審批、審計的基礎功能。
3. 微服務架構、核心與非核心服務分離、數據緩存降級知足系統高可用。

解決方案

如圖7所示，將軍令分3塊，數據內容權限平臺、審批流平臺、審計日誌平臺：

• 提供各類靈活可插拔的Plugin服務，支持在通用服務的基礎基礎上進行定製開發。
• 提供基礎服務，知足各類通用的數據安全要求。
• 提供管理工做臺，支持管理員對各類數據和規則進行頁面管理和配置。

具體方案

Plugin服務層，保證系統靈活可擴展

在知足通用權限的基礎上，各個業務線不免會有定製的權限管控需求，因而設計了權限Plugin模塊。

通用服務提供用戶管理、資源管理、鑑權受權的服務，Plugin調用基礎服務實現特殊的權限管控。Plugin模塊的應用和數據各自單獨管理，經過RPC方式調用通用服務實現靈活可插拔。後續Plugin模塊的服務支持各個接入的應用單獨定製開發。

如圖8所示，通用權限的服務與Plugin的服務是分離的，支持多個Plugin服務靈活可插拔：

• 通用服務提供用戶、資源、鑑權受權等通用服務，大部分的系統基於通用服務便可實現權限管控要求。
• Plugin服務基於通用服務對外提供的SDK進行拓展，各個Plugin服務單獨部署，保證系統之間互相獨立。

最終的權限實現分層管控，分爲核心數據層（用戶、資源、權限數據）和應用層。核心數據層的數據由通用服務進行管理，達到權限數據統一管控的要求。應用層以Plugin服務方式接入，Plugin經過通用服務層對外的SDK進行權限數據讀寫，達到定製的管控要求。應用層的數據各自存儲，能夠自定義管控規則。接口之間的調用經過BA認證鑑權，保證服務之間調用的安全性。

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

通用權限系統架構

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

• 用戶服務：主要包含用戶和部門信息同步、角色管理。
• 資源服務：包含資源註冊、資源定時同步、資源密級及管理員管理、資源包管理。
• 賦權服務：權限自助申請、管理員賦權。
• 鑑權服務：提供各類鑑權的SDK供使用方調用。

如圖9所示：

• 接入層：對外全部系統經過統一的SDK調用服務。
• 服務層：微服務架構，各個服務之間互相之間提供服務。
• 數據庫層：合理利用緩存、數據降級，保證服務高可用。
• 集成公司公共服務，保證系統穩健運行。

審批系統架構

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

如圖10所示：優化審批接入流程，提供通用的審批服務，減小系統接入開發成本：

• 前期開發一個審批功能須要6個步驟，繪製流程圖，配置審批的組和成員，配置通知的消息，配置事件映射，啓動審批流，開發回調接口改狀態。
• 而咱們在平臺的審批服務基礎上進行封裝，提供通用的審批模板，接入審批系統只須要選擇模板啓動審批流，並提供回調接口便可。能知足大部分的審批功能。

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

對接權限和審計系統，保證審批系統數據安全：

• 對接權限系統，提供管理員權限管控。
• 對接審計系統，操做數據落到審計系統便於後續的數據審計。

審計系統架構

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

如圖11所示：審計數據模型層支持自動擴展：

• 每一個應用對應一個appkey，每一個appkey按照模板分日期自動建立一個索引，支持自動擴展。
• 每種類型的審計日誌對應Elasticsearch索引中的一個type，新增一種操做日誌時，type自動建立。
• 審計日誌中的字段對應type中的字段，新增字段時自動擴展。

保證系統高可用

微服務架構服務分離

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

爲了保證服務的高可用和擴展性，因而以微服務架構把模塊進行拆分，並把核心與非核心服務進行分離。

如圖12所示：

• 前端接入層經過HTTP接入，BA認證校驗請求合法性，經過Nginx負載均衡。
• 管理控制檯，經過調用服務層的各個服務實現統一管理。
• 服務層，抽象系統各個模塊，每一個模塊都是一個微服務，每個微服務都獨立部署，能夠根據每一個服務的規模按需部署。
• Client層，對外提供統一的Pigeon（美團內部分佈式服務RPC通訊框架）接口，經過POM引入調用服務層各個服務。

權限繼承

因爲資源支持多層級，設計權限模型時支持權限繼承，當賦權時開啓繼承，則用戶默認擁有該資源以及下面全部資源的所有權限，數據存儲時只須要存儲祖先資源與用戶之間的關係。大大減小了權限矩陣大小。

權限數據存儲

接入的系統越多，則資源和用戶就越多。隨着系統運行越久，對應的權限數據也會隨之快速增加。如何在數據增加的同時保證接口的性能和高可用。

權限備份與恢復

參照HBase的版本號和MySQL的Binlog的設計思路，賦權時權限只存儲當前用戶最新權限數據，歷史權限數據和操做記錄用版本號的方式存儲到Elasticsearch中。用戶鑑權時只須要查詢MySQL的權限數據便可，保證鑑權接口的高效性。

如圖14所示：

• 賦權操做時，經過版本號管理權限數據，每次操做後版本號加1，MySQL和Redis中只存儲最新的權限數據。
• 歷史權限數據經過版本號的方式存儲到Elasticsearch中，每次查看歷史操做記錄或恢復權限數據時，根據版本號回溯便可。

權限過時清理

• 經過Crane定時調度，根據配置的通知規則，掃描即將過時的權限數據，發送消息通知用戶進行權限續期。
• 掃描已過時的權限數據，清理MySQL和Redis中的過時權限數據，並轉儲到Elasticsearch中保存，已備後續的權限審計。

數據讀寫分離、緩存、備份以及服務熔斷降級

各個服務使用MySQL分庫存儲，使用Zebra（美團數據庫訪問層中間件）進行讀寫分離；合理使用數據緩存與備份，並支持服務的熔斷降級，以保證服務的高可用。

如圖15所示：

• 各個服務使用MySQL分庫存儲；核心服務與非核心服務分離，服務和數據庫支持按需彈性拓展。
• 角色、資源等熱點數據使用Redis作緩存，並在Redis緩存不可用時自動下沉到MySQL進行查詢。
• 操做記錄和歷史數據等不活躍數據落地到Elasticsearch，以便審計和數據恢復。
• 服務不可用時支持熔斷降級，以保證核心服務的可用性。

合理使用消息隊列、任務調度、線程池、分佈式鎖

使用消息隊列、任務調度、線程池進行異步、削峯、解耦合，減小服務響應時間，提高用戶體驗。並使用分佈式鎖保證數據一致性。

如圖16所示：

• 使用消息隊列處理用戶請求，實時返回操做成功，後臺根據接受到的MQ消息異步進行處理並修改狀態，頁面輪詢狀態展現最終結果或發送大象（美團內部通信工具）消息進行最終結果推送。
• 須要定時同步的任務經過Crane分佈式任務調度平臺進行定時調度執行。
• 審批迴調時使用線程池處理審批結果回調與失敗重試，較少建立銷燬線程的開銷。
• 分佈式鎖，保證同一個方法在同一操做上只能被一臺機器上的一個線程執行，避免用戶重複提交或者多機器重複處理致使的數據不一致。

展望

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

如圖17所示：

• 後續將對外提供統一的Plugin開發規範，支持各個接入方系統以Plugin服務的形式在平臺基礎服務之上進行定製開發，以知足各自的特殊權限管控要求。從而實現數據產品權限集中管控確保數據安全。
• 把將軍令中的規則從現有的服務中分離出來，抽象出一個通用的規則引擎服務，實現規則靈活可配置。

做者簡介

• 夷山，美團點評技術專家，現任TechClub-Java俱樂部主席，2006年畢業於武漢大學，前後就任於IBM、用友、風行以及阿里。2014年加入美團，長期致力於BI工具、數據安全與數據質量工做等方向。
• 中華，美團點評數據系統研發工程師，2017年加入美團點評數據中心，長期從事於BI工具、數據安全相關工做。

招聘信息

最後插播一個招聘廣告，有對數據產品工具開發感興趣的能夠發郵件給 fuyishan#meituan.com。

咱們是一羣擅長大數據領域數據工具，數據治理，智能數據應用架構設計及產品研發的工程師。

歡迎加入美團大數據技術交流羣，跟做者零距離交流。進羣方式：請加美美同窗微信（微信號：MTDPtech02），回覆：數據安全，美美會自動拉你進羣。