基于雙單向安全傳輸的移動警務請求服務總線平臺的設計與實現

張 雷,樊志杰,張 冰,張丹丹,曹志威

(1.黑龍江省鶴崗市公安局 科技信通支隊，黑龍江 鶴崗 154103;2.上海辰銳信息科技公司 研發中心，上海 200031; 3.公安部第三研究所 信息安全技術部，上海 200031)

0 引言

當前，出于信息安全防護的需求，政府行業的內部網絡必然需要和互聯網等外部網絡進行物理隔離，這樣必然會造成內外網間數據交換的不便。在當下大數據和“互聯網+”戰略的趨勢下，以及一系列惠民便民政策的驅動下，各級政府機關急需要與其他企事業單位之間進行數據交換，其中與互聯網之間進行數據交換必不可少。同時，為了全面支撐便捷化的社會服務與各類政府的實戰業務，實現專業化、智能化、精準化的警務應用，亟需構建集“通道單向無反饋、協議高效穩定、資產智能調度、策略集中管控”等服務能力為一體的平臺。

政府行業信息化建設歷經多年，仍不斷暴露出“傳輸效率低、管控力度弱、監控能力差”等問題，影響便民服務效率的同時，還存在數據安全不可控的風險。此外，技術上不同網絡間的數據傳輸主要采用FTP協議，該協議本身存在效率低下和傳輸模式不合理的問題，其默認的ASCII傳輸模式甚至會造成文件損壞，需探索新模式的傳輸協議規避此類問題的再次發生；傳統信息化平臺建設多采用分布式部署、分布式管理，導致服務資源數據流轉情況不清晰、安全策略不統一、節點資源使用率未知，處于失聯狀態，因此需尋求技術手段，定義標準接口實現對服務資源和節點資源的統一管理和有效調度；傳統業務模式存在數據壟斷情況，為打破這一壁壘，實現服務資源目錄的公開化、服務資源使用的可授權化，需要定義安全可靠的統一請求調用接口，將對接能力服務化[1-5]。

鑒于此，本文提出泛政府行業信息化數據資源跨域共享的服務總線技術并研制系統，其主要采用雙單向安全傳輸模式，實現數據的物理單向無反饋安全傳輸；采用融合云計算和微服務的總線型技術架構，實現資源及服務統一管理、策略統一下發、日志統一上報；設計一種資源健康度評估模型，實現對資源通道的合理調度；基于限流熔斷機制，確保高峰期重要業務及服務能力的持續支撐；定義標準統一請求接口，實現不同網絡、不同區域間服務資源的授權訪問、調用和執行；采用MQ協議，實現服務數據的高效傳輸；基于證書的安全架構，保障任務配置、日志傳輸以及數據傳輸過程的安全管控。

1 系統結構及原理

本文研制的泛政府行業信息化數據互聯互通服務總線平臺[6]，軟件層面主要包括：外總線子系統、單向安全傳輸系統和內總線子系統，如圖1所示。

圖1 系統結構圖

本系統通過雙單向安全傳輸子系統將外總線子系統與內總線子系統分隔兩端。外總線和內總線子系統分別實現對應用請求的接收和響應，單向安全傳輸系統實現對通道任務的管理和數據資源的監控。

本文所提服務總線主要采用單向安全傳輸技術和ESB(enterprise service bus)技術，并通過兩臺單向安全傳輸系統實現服務總線數據的通道交換。

1)單向安全傳輸技術：單向安全傳輸從硬件層面提供了數據的單向傳輸，其采用雙主機硬件結構，內外端主機各采用一個光口收發不同方向信號，其中外端機光口作為發送端只能發送數據，內端機光口作為接收端則只能接收數據[7-10]。

2)ESB技術：本文所提系統內外總線主要基于ESB技術，解決多個應用系統互聯所面臨的復雜性，減低集成和維護成本[11-16]。

2 系統軟件設計

本文所設計的服務總線主要由“外總線子系統”、“單向安全傳輸子系統”和“內總線子系統”組成，其中“外、內總線子系統”包含的模塊和實現的功能相似，在軟件設計層面的思路相似。

2.1 外、內總線子系統

外、內總線子系統主要實現業務請求的傳輸與轉換，以及限流熔斷等功能。

2.1.1 請求協議轉換

服務總線接收到來自請求方的請求后，通過請求方登記的注冊信息，按登記的請求方式和協議對請求內容重新組織，向目標服務發起請求，其過程如圖2所示。

圖2 請求協議轉換轉發圖

2.1.2 節點資源調度

資源調度管理作為系統內部整體統籌管理模塊。其結構如圖3所示。

圖3 資源調度模塊結構圖

通道資源池根據其物理通道上帶寬資源的分配方式不同，可以分為如圖4所示的6種類型。

圖4 通道資源池

本文提出的通道資源分配模型根據其通道占用方式不同，可以分為獨占通道、獨占帶寬、共享帶寬3種類型。

1)獨占通道：該通道為故障通道，無法對外提供數據傳輸服務。

2)獨占帶寬：該通道上承載了一個或多個獨占帶寬方式的數據傳輸業務。該類物理通道需要根據業務分配的帶寬容量，進行限流控制。

3)共享帶寬：該通道作為共享帶寬資源使用，為多個業務提供數據傳輸服務。該類物理通道以系統最大能力運行，并為多個業務動態分配資源，不做限流控制。

2.1.3 健康度評估

外端服務總線通過模擬請求的方式，請求內端服務總線。通過響應速度和兩端服務總線的設備狀態，分析系統的健康度，并上報日志，其過程如圖5所示。

圖5 健康度評估流程圖

2.1.4 限流熔斷管理

為了保證業務的高效、穩定運行，本文所研究的服務總線提出了“限流熔斷管理”模塊，主要從邊界的入口和出口兩個方向切入，基于“一個策略+兩個機制”實現相關保護。

圖6 限流熔斷示意圖

通過對邊界上運行各業務的重要性等級進行標定，指導擁塞保護機制對各業務執行不同等級的處置和取舍。

業務的優先等級，對應于業務的重要性，從高到低劃分為：

1)最高：最重要業務，在各種場景下都應予以保障，在系統異常時，應調集資源優先保障，盡一切可能使其運行不受影響。

2)高：重要業務，大部分場景下應予以保障，在系統異常時，應調集資源保障，盡可能使其運行不受影響。

3)中：普通業務，默認級別，正常情況下應得到服務保障，但在異常情況(特別是為保障重點業務需要犧牲時)，可容忍一定程度的服務受限。

4)低：可受限業務，在正常情況下一般都能得到服務，但在異常情況(特別是為保障重點業務需要犧牲時)，可容忍較大程度的服務受限。

5)最低：可忽略業務，在正常情況下一般都能得到服務，但在異常情況下，將首先被犧牲，以讓出資源保障高優先級業務。

2.2 單向安全傳輸子系統

2.2.1 通道任務管理

通道任務對外提供服務。供外、內服務區的資源調度模塊調用，實現通道任務的創建、修改、刪除、啟停。其流程如圖7所示。

圖7 通道任務管理流程圖

具體流程說明如下：

1)外、內資源調度模塊調用通道任務管理模塊對外提供的任務配置接口。

2)通道任務管理模塊收到任務數據信息后，封裝任務配置消息報文發送到主任務管理模塊。

4)各傳輸模塊根據任務配置報文類型更新數據庫，執行相應動作。同時發送任務配置到對端。

5)通道任務管理模塊返回資源調度模塊調用信息。

2.2.2 資源監控上報

資源監控上報模塊提供單向安全傳輸系統的硬件信息實時上報總線，總線根據單向安全傳輸系統狀態進行分發，具體流程如圖8和圖9所示。

圖8 設備資源注冊流程圖

圖9 設備資源報送流程圖

2.2.3 MQ通道處理

MQ服務作為內、外總線傳輸的中間協議，起到協議解耦、設備解耦作用。MQ通道處理流程如圖10所示。

圖10 MQ通道處理流程圖

具體流程說明如下：

從那時起，我們三人之間的關系發生了微妙的變化。老周再找老馬時，老馬總會說他不在家。幾次之后，老周也自覺沒趣，從此不再找他了。有一次我提起老周，老馬輕輕地說了一句：他只是個拍攝稻草的人，并不是愛稻草的人。我最不喜歡的是葉公好龍。

1)請求數據進入請求轉發服務端，服務端進行協議轉換并發送至MQ隊列。

2)單向安全傳輸系統的MQ客戶端獲取外總線MQ隊列數據，并擺渡至內總線MQ隊列。

3)內總線請求轉發客戶端從MQ隊列獲取數據，并對真實服務器發起請求。

4)請求響應客戶端收到數據后，轉存至MQ隊列。

5)單向安全傳輸系統的MQ客戶端獲取內總線MQ隊列數據，并擺渡至外總線MQ隊列。

6)外總線請求響應服務端從MQ隊列獲取響應數據，并最終返回請求方。

2.3 業務交互流程

2.3.1 數據交換業務

2.3.1.1 FTP協議數據交換業務注冊

FTP協議數據交互業務注冊流程如圖11所示，具體說明如下：

圖11 FTP協議數據交互業務注冊流程圖

1)接口服務向通道資源調度模塊發送業務注冊請求；

2)通道資源調度模塊根據申請的業務類型查找匹配的通道資源；

3)通道資源調度模塊根據申請的通道資源類型和帶寬要求等，從可用通道里分配該業務使用的通道資源；

4)通道資源調度模塊判斷設備是否支持任務動態配置接口，如果不支持則表示需要手工配置交換設備上的傳輸任務，跳過步驟5；

5)通道資源調度模塊向數據交換設備發送創建FTP傳輸任務請求；

6)通道資源調度模塊保存任務相關信息；

7)通道資源調度模塊向接口服務返回業務注冊成功響應。

2.3.1.2 FTP協議數據交換業務注銷

FTP協議數據交換業務注銷流程如圖12所示，具體說明如下：

圖12 FTP協議數據交換業務注銷流程圖

1)接口服務向通道資源調度模塊發送業務注銷請求；

2)通道資源調度模塊查找該業務相關的所有任務信息；

3)通道資源調度模塊向數據交換設備發送刪除任務請求；

4)通道資源調度模塊保存任務相關信息；

5)通道資源調度模塊向接口服務返回業務注銷成功響應。

2.3.1.3 FTP協議數據交換業務執行

對于雙向數據交換按照兩個單向數據交換任務分別獨立執行，二者的流程完全一樣，只是方向相反，因此這里只介紹單向數據交換的具體流程，如圖13所示。

圖13 FTP協議數據交換業務執行流程圖

1)業務系統向接口服務發送數據服務請求；

2)接口服務調用通道資源調度模塊獲取文件上傳位置；

3)接口服務將請求消息落地為文件；

4)接口服務將請求文件上傳到指定的FTP服務器；

5)數據交換設備從FTP服務器獲取請求文件；

6)數據交換設備負責將文件擺渡到對端；

7)對端數據交換設備將擺渡過來的文件上傳到接口服務指定的FTP服務器；

8)接口服務從FTP服務器下載請求文件；

9)接口服務調用業務系統接口提交數據服務請求。

2.3.1.4 FTP協議任務分發

FTP協議任務發布流程如圖14所示，具體說明如下：

圖14 FTP協議任務發布流程圖

1)接口服務向通道資源調度模塊發送查詢FTP任務分發通道請求；

2)通道資源調度模塊查找該業務對應的通道配置，從已按照通道負載系數排好序的隊列中取出第一個可用的通道；

3)通道資源調度模塊獲取該通道上對應該業務的FTP賬號信息；

4)通道資源調度模塊向接口服務返回成功響應，為了減少接口服務調用該接口的頻度，提高系統性能，一次查詢結果允許接口服務用于傳輸后續的多個文件。

2.3.1.5 流模式數據交換業務注冊

流模式數據交換業務注冊流程如圖15所示，具體說明如下：

圖15 流模式數據交換業務注冊流程圖

1)接口服務向通道資源調度模塊發送業務注冊請求；

2)通道資源調度模塊根據申請的業務類型查找匹配的通道資源，分配的數據交換設備應支持流模式；

3)通道資源調度模塊根據申請的通道資源類型和帶寬要求，從可用通道里分配該業務使用的通道資源；

4)通道資源調度模塊向數據交換設備發送創建流代理任務請求；

5)通道資源調度模塊保存任務相關信息；

6)通道資源調度模塊向接口服務返回業務注冊成功響應。

2.3.1.6 流模式數據交換業務注銷

流模式數據交換業務注銷流程如圖16所示,具體說明如下：

圖16 流模式數據交換業務注銷流程圖

1)接口服務向通道資源調度模塊發送業務注銷請求；

2)通道資源調度模塊查找該業務相關的所有任務信息；

3)通道資源調度模塊向數據交換設備發送刪除流代理任務請求；

4)通道資源調度模塊保存任務相關信息；

5)通道資源調度模塊向接口服務返回業務注銷成功響應。

2.3.1.7 流模式數據交換業務執行

對于雙向數據交換按照兩個單向數據交換任務分別獨立執行，二者的流程完全一樣，只是方向相反，因此這里只介紹單向數據交換的具體流程，如圖17所示。

圖17 流模式數據交換業務執行流程圖

具體流程說明如下：

1)業務系統向接口服務發送數據服務請求；

2)接口服務將請求消息發布到消息隊列1中；

3)數據交換設備從消息隊列1中讀取請求消息；

4)數據交換設備通過流代理將數據擺渡到對端；

5)數據交換設備向消息隊列1返回確認消息；

6)對端數據交換設備將擺渡過來的請求消息發布到消息隊列2中；

7)接口服務從消息隊列2中讀取請求消息；

8)接口服務調用業務系統接口提交數據服務請求。

3 系統主要功能

本文所研究服務總線的主要功能模塊包括：請求業務傳輸功能、限流熔斷功能、安全控制功能[17-21]。

3.1 請求業務傳輸功能

將請求方的請求數據進行解析和轉換，生成符合標準的請求報文文件，傳輸至服務方；接收服務方響應報文文件并解析，將反饋結果返回至請求方。

接受請求：接收服務節點回傳的請求報文，解析報文，根據資源服務目錄，審核請求權限，調用已授權的服務方接口，發起資源使用請求并獲取數據。

響應請求：接收服務節點回傳的響應報文，根據請求方標識，調用請求方接口，向請求方反饋響應報文。

1)支持HTTP請求轉發，支持Restful、Webservice接口方式并提供統一入口。

2)支持參數格式檢查。

3.2 限流熔斷功能

在接入請求并發量高于邊界處理能力時，通過限制請求接入量的方式，降低系統負載，避免邊界擁塞。

3.3 安全控制功能

為了保障運行的安全性和穩定性，本系統建立了安全防護體系，具體的安全控制功能包括：

1)身份認證：管理員訪問基于泛政府行業信息化數據跨域共享服務總線的管理系統時需采用硬件數字證書登陸。

2)角色三權分立：提供業務管理員、系統審計員、系統管理員三類角色權限。

3)訪問控制：設置安全策略對服務調用進行訪問控制，包括時間段控制、訪問資源的IP地址黑白名單控制、請求頻率或流量控制、請求參數檢測與過濾、服務響應關鍵字過濾。

4)全流程監控審計：提供訪問接入、服務交換、路由調度、服務響應等全流程的運行監控、日志采集和審計功能，提供FTP、JDBC、JMS、SYSLOG等協議的日志推送接口支持，支持第三方審計系統的無縫對接。

5)高安全交換控制：提供高安全的服務訪問的控制功能，支持對IP地址信息的認證驗證；支持通過設置安全策略對服務調用進行訪問控制，包括時間段控制、IP地址黑白名單控制、請求頻率或流量控制、請求參數檢測與過濾、服務響應關鍵字過濾等。

6)數據加解密：外部提供HTTPS加密請求接口，保證請求數據安全。

7)上報基座：系統運行日志、業務訪問日志等實時上報基座，并由基座運算實時預警。

4 實施方式與應用案例

4.1 實施方式

本系統使用雙單向安全傳輸系統將外總線模塊與內總線模塊分隔兩端。外總線模塊接收應用系統請求后進行JSON-RPC協議轉換后發布請求消息，外端單向安全傳輸系統接收消息并將消息發布到內端消息服務器，內總線模塊接收消息后進行協議轉換并向信息資源系統發送請求，待獲得服務響應消息后協議轉換發布響應消息，內端單向安全傳輸系統接收消息并將消息發布到外端消息服務器，外總線模塊收到消息后進行協議轉換向應用系統發送響應消息。本系統根據不同業務量級可采用不同應用模式，具體實施方案如下：

4.1.1 總線與單向安全傳輸系統一對一部署

當業務場景請求和響應流量均衡，且并發均衡沒有達到總線性能極限時，單向安全傳輸系統及總線資源消耗相當，一對一的部署模式合理有效。具體部署方式如圖18所示。

圖18 一對一部署方式

4.1.2 總線與單向安全傳輸系統多對一部署

當業務場景請求和響應流量比較大時，外總線接收應用服務請求、內總線路由資源消耗資源較大，同時向應用服務響應消息性能降低，此時單向安全傳輸系統資源占用率低，可部署多套總線通過負載均衡分配資源，實現資源利用最大化。具體部署方式如圖19所示。

圖19 多對一部署方式

4.1.3 總線與單向安全傳輸系統一對多部署

當業務并發較大但是流量較小時，總線處理時間較短，單向安全傳輸系統性能達到極限，可部署多套單向安全傳輸系統加速傳輸消息，使整體性能發揮極致。具體部署方式如圖20所示。

圖20 一對多部署方式

4.2 應用案例

本文所設計系統已在某市相關部門進行實際驗證，并取得較好效果。具體部署方式如圖21所示。

圖21 某市相關部門服務總線平臺部署方式

某市社企專網與某部門信息內網間需實現跨網請求信息共享，特通過本文設計的服務總線平臺實現信息的高效交互。其中，分別在應用服務區和部門信息內網中部署了外服務總線系統和內服務總線系統，通過二者相互配合的形式實現對服務方請求接口的代理。同時支持接收中心服務推送的同步信息，包括：請求方/服務方的注冊信息、授權信息以及服務目錄和授權目錄等資源。當社企專網側請求方發起請求時，應用服務區外服務總線在接收到來自請求方的請求后，將通過請求方登記的注冊信息，按登記的請求方式和協議對請求內容進行重新組織，然后向部門信息內網業務服務器發起請求，在內服務器總線取得業務服務器響應后，轉發請求響應信息至社企專網側請求方。

結合該部門業務需求，平臺在設計登陸時采用了證書加密碼的多因子驗證登陸，用來實現超時鑒別登陸功能；系統管理權限采用了系統管理員、安全管理員、審計管理員三權分立管理能力；業務服務支持服務請求方、服務方的注冊、修改、審批、查詢功能；請求業務傳輸支持Restful、Webservice接口方式，并提供統一入口，支持http通訊協議；支持訪問控制，包括黑白名單訪問控制、調用頻率控制、字段過濾等功能。此外，為了滿足該部門請求服務的性能要求,本平臺設計了一種包含一個CRSS-CT(主節點)和三個CRSS-ND(子節點)的部署方式，當請求數據包大小1 kB時，請求并發數能達到7 200個/秒。

為了提升方案整體的安全性，通常在實際應用中需要在邊界保護區、應用服務區、安全隔離區進行安全加固。其中，各區域作用如下：

邊界保護區：該區域主要實現平臺和數據的第一層跨網域安全防護。

應用服務區：該區域主要處理各類與應用相關的操作，是跨網交互進行數據交換的數據緩存區域。

安全隔離區：該區域實現部門信息內網與應用服務區的信息單向傳輸，保證跨區域之間的安全隔離。

5 結束語

當前，面對以大數據、物聯網、人工智能為代表的新一輪科技革命浪潮，全國泛政府行業均在積極推進行業大數據戰略，在科技創新、數據共享、安全保護等方面進行前瞻性布局，全面推動政府工作質量變革、效率變革。本文提出的泛政府行業信息化數據資源跨域共享的服務總線，采用“資源狀態聯動計算”機制，實現獨占通道、獨占帶寬、共享帶寬三種類型的資源調度；采用“統一申請、授權”接口定義，實現服務資源、資產的統一管理，有效保障數據傳輸的安全、可控、可管；基于服務總線(ESB)體系架構，以及統一定義請求調用接口，實現跨區域、跨網絡間服務授權訪問、資源授權調用、數據安全轉發、監控信息上報。本文所提泛政府行業信息化數據跨域共享服務總線技術及系統，有效解決不同網域間數據的互聯互通，為政府行業實戰提供數據實時共享和應用。