大數(shù)據(jù)安全平臺
通過各種數(shù)據(jù)分析挖掘手段，為公司發(fā)展決策和業(yè)務開展提供數(shù)據(jù)支持。
在大數(shù)據(jù)時代，數(shù)據(jù)已經成為公司的核心競爭力。主要是通過各種數(shù)據(jù)分析挖掘手段，為公司發(fā)展決策和業(yè)務開展提供數(shù)據(jù)支持。業(yè)內數(shù)據(jù)安全事件頻發(fā)，給相關企業(yè)造成了無可挽回的損失，更為數(shù)據(jù)安全防護意識薄弱的企業(yè)敲響了警鐘。如何對公司內部數(shù)據(jù)最為集中的數(shù)據(jù)分析、數(shù)據(jù)服務、數(shù)據(jù)治理等各種數(shù)據(jù)類產品進行權限管控，已經成為數(shù)據(jù)安全建設中最為重要的任務。如果從控制力的角度來進行劃分的話，權限管控可以分為功能級權限管控和數(shù)據(jù)級權限管控。早期的數(shù)據(jù)安全產品大多使用傳統(tǒng)的權限模型，只能實現(xiàn)功能級權限管控，無法進行數(shù)據(jù)級權限管控。基于數(shù)據(jù)類產品更高的安全要求，我們需要構建一個同時滿足各類產品數(shù)據(jù)安全的我們需要構建一個同時滿足各類產品數(shù)據(jù)安全的平臺。為此，騰軟技術不僅設計了能表達和管控各種復雜關系的權限模型，還針對事前、事中、事后等三個場景，分別設計了審批、權限、審計三個子系統(tǒng)以保障數(shù)據(jù)安全的完整閉環(huán)，進而滿足數(shù)據(jù)安全的各種要求。
圖1 權限背景
功能應用類產品的權限表達，一般為“是否有權限”，而數(shù)據(jù)類產品權限表達的關系更加復雜。例如數(shù)據(jù)類產品的報表，不僅需要表達出用戶能否訪問這個報表，而且需要表達出用戶能訪問報表中的哪些維度、指標以及維值的范圍。還需要告知這些維度指標來自于哪些庫表模型，是否有權限訪問以及創(chuàng)建報表。
權限模型
傳統(tǒng)的權限模型有ACL（Access Control List）訪問控制列表，RBAC（Role-Based Access Control）基于角色的訪問控制等。以上模型比較適用于應用類型產品的權限管控，而數(shù)據(jù)類型的產品對信息安全的要求更高，而且各類資源間的關系也更復雜，使用傳統(tǒng)的模型難以將內部關系進行清晰的表達，所以我們在RBAC權限模型的基礎上，擴展設計了新的權限模型。
圖2 傳統(tǒng)權限模型
如圖2所示，傳統(tǒng)的權限模型：
?ACL訪問控制列表，用戶與權限直接關聯(lián)，直接維護用戶與列表中資源的關系從而達到權限管控的目的。
?RBAC模型則是角色與權限進行關聯(lián)，用戶成為相應的角色而獲得對應的權限。
為什么要設計新的權限模型？
1ACL模型是用戶與資源直接建立關系，沒有角色的概念。當某些用戶需要一批同樣資源的權限時，賦權操作就變得很復雜，此時這種模型就不太適應了。
2RBAC模型引入了角色的概念，角色與資源建立關系。當某些用戶需要一批同樣資源的權限時，只需要構建一個角色并賦予使用這批資源的權限。當用戶加入這個角色時，則擁有該角色的所有權限。解決了賦權操作復雜的問題。
不過ACL模型和RBAC模型，都存在以下幾個問題：
1數(shù)據(jù)類產品資源之間關系復雜，不能很好地表達這種復雜的關系。例如：一個報表下有多個標簽頁，一個標簽頁下有多個組件，一個組件下有多個維度、指標等。同時維度、指標又來自不同的數(shù)據(jù)模型、庫表等。資源與資源之間存在關系，當管理員給一個用戶賦予報表的全部或部分權限時，報表下的子資源需要同時獲得對應的權限。
2RBAC模型中角色與角色之間沒有對應的關系。例如：組織架構中，員工所在的組織架構如下：華東區(qū)/銷售一區(qū)/銷售一組，員工擁有的角色是銷售一組的角色。當角色之間沒有關系時，員工如果需要華東區(qū)角色的權限時，需要添加到華東區(qū)的角色中。而如果角色與角色之間具有從屬關系時，則能很好地解決這個問題。
新的權限模型是如何解決上面這些問題的：
1設計資源模型時，資源與資源之間具有從屬關系，并且資源允許多層級，以樹形結構展示。例如報表是一個父資源，標簽、組件、維度指標都是報表下的子資源，這樣賦權時能清晰地展示出報表資源與下面的子資源的關系，賦權和鑒權時才能滿足各種權限控制的要求。
2角色與角色之間具有從屬關系，例如員工在華東區(qū)/銷售一區(qū)/銷售一組的組織架構中，華東區(qū)/銷售一區(qū)/銷售一組這3個角色之間分別具有父子級的從屬關系，當員工在銷售一組部門下，則擁有華東區(qū)、銷售一區(qū)、銷售一組的所有權限。當權限不沖突時則直接合并所有權限，沖突時則以“就近原則”進行覆蓋。
圖3權限模型
如圖3所示，新的權限模型包含3個部分，用戶中心、資源中心、權限中心。
用戶中心：用戶管理、角色管理
?角色分為個人、組織、自定義3種，一個用戶可以同時擁有多個角色，比如用戶默認對應一個個人角色，又可同時擁有在公司組織架構中組織角色、在自定義組織的自定義角色。
?角色支持多層級，滿足角色間權限繼承的表達方式。
?用戶、部門信息實時更新，每天ETL定時同步，保證人員入職、轉崗、調離權限實時同步。
圖4 用戶中心
資源中心：資源管理
?資源類型支持自定義，在通用資源類型的基礎上支持自定義的資源接入，滿足各個系統(tǒng)不同資源的統(tǒng)一管控。
?資源支持多層級，樹形結構的資源展示方式便于資源的統(tǒng)一賦權鑒權；給一個報表資源賦權時，掛在報表下的維度、指標等資源能統(tǒng)一獲得權限。
?支持資源打包簡化賦權流程。
?資源安全密級、資源負責人，支持按照資源配置不同的審批模板進行權限自助申請。
圖5 資源中心
權限中心：角色與資源的關系的多種策略表達
?范圍策略：例如報表中的平臺維度的維值包括和，賦權時，支持按要求給用戶賦予部分或全部權限；鑒權時，按照規(guī)則解析為某人擁有某維度的部分或全部權限。
?表達式策略：當把報表給用戶賦權時，設置表達式為limit 10，表示當前用戶在該報表其他權限的基礎上再進行限制，只能返回前10條記錄。
?權限自動合并：一個用戶擁有多個角色，多角色的同一資源的權限鑒權時按照規(guī)則自動合并；規(guī)則解析時，權限數(shù)據(jù)不沖突時取合集，沖突時按照優(yōu)先級取對應的值。
?黑白名單：支持按照特定的規(guī)則，對某人針對某資源全面開發(fā)和封禁，黑白名單策略的優(yōu)先級最高，其中黑名單高于白名單。
圖6 權限中心
挑戰(zhàn)
在建設數(shù)據(jù)安全平臺的過程中，主要面臨以下幾點挑戰(zhàn)：
?隨著支持的業(yè)務線增加，通用平臺的不能滿足各個業(yè)務線的定制需求時，需要保證系統(tǒng)的靈活可擴展。
?提供一個通用的數(shù)據(jù)安全平臺，滿足大部分的數(shù)據(jù)安全的要求，保證系統(tǒng)的通用性。
?權限系統(tǒng)作為一個高QPS訪問的系統(tǒng)，如何保證系統(tǒng)的高可用。
解決思路
1提供靈活可插拔的Plugin服務，在通用權限基礎上，滿足各個業(yè)務線靈活的權限管控要求。
2提供一個通用的數(shù)據(jù)安全平臺，滿足基本的權限、審批、審計的基礎功能。
3微服務架構、核心與非核心服務分離、數(shù)據(jù)緩存降級滿足系統(tǒng)高可用。
解決方案
圖7 整體架構
如圖7所示，分3塊，數(shù)據(jù)內容權限平臺、審批流平臺、審計日志平臺：
?提供各種靈活可插拔的Plugin服務，支持在通用服務的基礎基礎上進行定制開發(fā)。
?提供基礎服務，滿足各種通用的數(shù)據(jù)安全要求。
?提供管理工作臺，支持管理員對各種數(shù)據(jù)和規(guī)則進行頁面管理和配置。
具體方案
Plugin服務層，保證系統(tǒng)靈活可擴展
在滿足通用權限的基礎上，各個業(yè)務線難免會有定制的權限管控需求，于是設計了權限Plugin模塊。通用服務提供用戶管理、資源管理、鑒權授權的服務，Plugin調用基礎服務實現(xiàn)特殊的權限管控。Plugin模塊的應用和數(shù)據(jù)各自單獨管理，通過RPC方式調用通用服務實現(xiàn)靈活可插拔。后續(xù)Plugin模塊的服務支持各個接入的應用單獨定制開發(fā)。
圖8 Plugin服務
如圖8所示，通用權限的服務與Plugin的服務是分離的，支持多個Plugin服務靈活可插拔：
?通用服務提供用戶、資源、鑒權授權等通用服務，大部分的系統(tǒng)基于通用服務即可實現(xiàn)權限管控要求。
?Plugin服務基于通用服務對外提供的SDK進行拓展，各個Plugin服務單獨部署，保證系統(tǒng)之間互相獨立。
最終的權限實現(xiàn)分層管控，分為核心數(shù)據(jù)層（用戶、資源、權限數(shù)據(jù)）和應用層。核心數(shù)據(jù)層的數(shù)據(jù)由通用服務進行管理，達到權限數(shù)據(jù)統(tǒng)一管控的要求。應用層以Plugin服務方式接入，Plugin通過通用服務層對外的SDK進行權限數(shù)據(jù)讀寫，達到定制的管控要求。應用層的數(shù)據(jù)各自存儲，可以自定義管控規(guī)則。接口之間的調用通過BA認證鑒權，保證服務之間調用的安全性。
基礎服務層，保證系統(tǒng)通用性
通用權限系統(tǒng)架構
使用微服務架構設計，系統(tǒng)分為接入層、服務層、數(shù)據(jù)庫層、以及外部服務層。主要包含以下幾個核心服務：
?用戶服務：主要包含用戶和部門信息同步、角色管理。
?資源服務：包含資源注冊、資源定時同步、資源密級及管理員管理、資源包管理。
?賦權服務：權限自助申請、管理員賦權。
?鑒權服務：提供各種鑒權的SDK供使用方調用。
圖9 權限系統(tǒng)架構
如圖9所示：
?接入層：對外所有系統(tǒng)通過統(tǒng)一的SDK調用服務。
?服務層：微服務架構，各個服務之間互相之間提供服務。
?數(shù)據(jù)庫層：合理利用緩存、數(shù)據(jù)降級，保證服務高可用。
?集成公司公共服務，保證系統(tǒng)穩(wěn)健運行。
審批系統(tǒng)架構
提供通用的審批服務，提供多級審批模板，使用時選擇模板啟動審批流，審批系統(tǒng)按照啟動的參數(shù)進行規(guī)則解析，自動適配對應的審批流程。縮減接入流程支持一鍵接入。
圖10 審批系統(tǒng)架構
如圖10所示：優(yōu)化審批接入流程，提供通用的審批服務，減少系統(tǒng)接入開發(fā)成本：
?前期開發(fā)一個審批功能需要6個步驟，繪制流程圖，配置審批的組和成員，配置通知的消息，配置事件映射，啟動審批流，開發(fā)回調接口改狀態(tài)。
?而我們在平臺的審批服務基礎上進行封裝，提供通用的審批模板，接入審批系統(tǒng)只需要選擇模板啟動審批流，并提供回調接口即可。能滿足大部分的審批功能。
提供通用的規(guī)則解析引擎，支持審批人、審批條件、審批通知按照規(guī)則動態(tài)解析匹配。靈活實現(xiàn)自動審批、多人多級審批、定時催辦等多種通用功能。對接權限和審計系統(tǒng)，保證審批系統(tǒng)數(shù)據(jù)安全：
?對接權限系統(tǒng)，提供管理員權限管控。
?對接審計系統(tǒng)，操作數(shù)據(jù)落到審計系統(tǒng)便于后續(xù)的數(shù)據(jù)審計。
審計系統(tǒng)架構
提供通用的數(shù)據(jù)審計服務，客戶端日志埋點上報，審計日志按類型落到Elasticsearch中存儲。對接如意可視化報表出審計報告，對接權限系統(tǒng)管控數(shù)據(jù)權限。
圖11 審計系統(tǒng)架構
如圖11所示：審計數(shù)據(jù)模型層支持自動擴展：
?每個應用對應一個appkey，每個appkey按照模板分日期自動創(chuàng)建一個索引，支持自動擴展。
?每種類型的審計日志對應Elasticsearch索引中的一個type，新增一種操作日志時，type自動創(chuàng)建。
?審計日志中的字段對應type中的字段，新增字段時自動擴展。
保證系統(tǒng)高可用微服務架構服務分離
隨著系統(tǒng)的模塊功能越來越多，單一架構模式已不再適合敏捷開發(fā)，模塊越來越大系統(tǒng)啟動則越慢，任一模塊出錯則整個系統(tǒng)的服務都不可用。為了保證服務的高可用和擴展性，于是以微服務架構把模塊進行拆分，并把核心與非核心服務進行分離。
圖12 微服務架構
如圖12所示：
?前端接入層通過HTTP接入，BA認證校驗請求合法性，通過Nginx負載均衡。
?管理控制臺，通過調用服務層的各個服務實現(xiàn)統(tǒng)一管理。
?服務層，抽象系統(tǒng)各個模塊，每個模塊都是一個微服務，每一個微服務都獨立部署，可以根據(jù)每個服務的規(guī)模按需部署。
?Client層，對外提供統(tǒng)一的Pigeon（內部分布式服務RPC通信框架）接口，通過POM引入調用服務層各個服務。
權限繼承
由于資源支持多層級，設計權限模型時支持權限繼承，當賦權時開啟繼承，則用戶默認擁有該資源以及下面所有資源的全部權限，數(shù)據(jù)存儲時只需要存儲祖先資源與用戶之間的關系。大大減少了權限矩陣大小。
圖13 權限繼承
權限數(shù)據(jù)存儲
接入的系統(tǒng)越多，則資源和用戶就越多。隨著系統(tǒng)運行越久，對應的權限數(shù)據(jù)也會隨之快速增長。如何在數(shù)據(jù)增長的同時保證接口的性能和高可用。
權限備份與恢復
參照HBase的版本號和MySQL的Binlog的設計思路，賦權時權限只存儲當前用戶最新權限數(shù)據(jù)，歷史權限數(shù)據(jù)和操作記錄用版本號的方式存儲到Elasticsearch中。用戶鑒權時只需要查詢MySQL的權限數(shù)據(jù)即可，保證鑒權接口的高效性。
圖14 權限備份與恢復
如圖14所示：
?賦權操作時，通過版本號管理權限數(shù)據(jù)，每次操作后版本號加1，MySQL和Redis中只存儲最新的權限數(shù)據(jù)。
?歷史權限數(shù)據(jù)通過版本號的方式存儲到Elasticsearch中，每次查看歷史操作記錄或恢復權限數(shù)據(jù)時，根據(jù)版本號回溯即可。
權限過期清理
?通過Crane定時調度，根據(jù)配置的通知規(guī)則，掃描即將過期的權限數(shù)據(jù)，發(fā)送消息通知用戶進行權限續(xù)期。
?掃描已過期的權限數(shù)據(jù)，清理MySQL和Redis中的過期權限數(shù)據(jù)，并轉儲到Elasticsearch中保存，已備后續(xù)的權限審計。
數(shù)據(jù)讀寫分離、緩存、備份以及服務熔斷降級
各個服務使用MySQL分庫存儲，使用Zebra（數(shù)據(jù)庫訪問層中間件）進行讀寫分離；合理使用數(shù)據(jù)緩存與備份，并支持服務的熔斷降級，以保證服務的高可用。
圖15 數(shù)據(jù)讀寫分離、緩存、備份以及服務熔斷降級
如圖15所示：
?各個服務使用MySQL分庫存儲；核心服務與非核心服務分離，服務和數(shù)據(jù)庫支持按需彈性拓展。
?角色、資源等熱點數(shù)據(jù)使用Redis做緩存，并在Redis緩存不可用時自動下沉到MySQL進行查詢。
?操作記錄和歷史數(shù)據(jù)等不活躍數(shù)據(jù)落地到Elasticsearch，以便審計和數(shù)據(jù)恢復。
?服務不可用時支持熔斷降級，以保證核心服務的可用性。
合理使用消息隊列、任務調度、線程池、分布式鎖
使用消息隊列、任務調度、線程池進行異步、削峰、解耦合，減少服務響應時間，提升用戶體驗。并使用分布式鎖保證數(shù)據(jù)一致性。
圖16 提高服務響應速度
如圖16所示：
?使用消息隊列處理用戶請求，實時返回操作成功，后臺根據(jù)接受到的MQ消息異步進行處理并修改狀態(tài)，頁面輪詢狀態(tài)展示最終結果或發(fā)送大象（內部通訊工具）消息進行最終結果推送。
?需要定時同步的任務通過Crane分布式任務調度平臺進行定時調度執(zhí)行。
?審批回調時使用線程池處理審批結果回調與失敗重試，較少創(chuàng)建銷毀線程的開銷。
?分布式鎖，保證同一個方法在同一操作上只能被一臺機器上的一個線程執(zhí)行，避免用戶重復提交或者多機器重復處理導致的數(shù)據(jù)不一致。