統一安全管理平臺性能測試之設備管理

01 背景介紹

車載防火墻是針對城市軌道交通車載TCMS系統和信號系統等設計開發的邊界隔離和安全防護產品。產品采用工業級ARM多核處理器芯片的硬件架構和自主知識產權的智能工控安全操作系統（IICS-OS），基于優化的軟硬件架構提高報文的處理能力，對主流工業協議進行深度報文解析（DPI，Deep Packet Inspection），運用“白名單+智能學習”技術建立車載數據通信及車載控制網絡區域間通信模型，保證只有可信任的流量可以在網絡上傳輸。產品在提供傳統工業防火墻功能的基礎上，可適應TCMS系統和信號系統應用場景，識別列車控制系統相關協議，并基于協議做訪問控制和安全策略，為車載控制網絡與外部網絡互聯、車載控制網絡內部區域之間的網絡連接提供安全保障。

產品設計之初為自管理形態，即防火墻應用與管理平臺運行在同一臺物理設備上。項目研發過程中為滿足客戶新需求，后期又增加了集中管理方式。具體運作方式為，統一安全管理平臺部署在地面管理非車載防火墻、日志審計等其他設備；白天列車運行過程中，車載防火墻進入自管理狀態，日志數據存儲在本地；夜間列車進站后，車載防火墻同時工作在自管理和集中管理狀態，需要將白天產生的日志數據上傳至地面部署的統一安全管理平臺，以實現對日志的統籌管理。

02 測試挑戰

原本的自管理形態，對于管理平臺而言日志數量相對較少、處理壓力較小； 對于集中管理，由于地 面部署的防火墻、日志審計等設備不是很多，處理起來比較輕松。 而車載防火墻在每輛列車上要部署2臺，當幾十輛甚至上百輛列車同時部署時，集中管理平臺就要面臨著處理上百臺甚至幾百臺設備的壓力，怎樣去管理這些設備以及這些設備上報的日志怎么處理是亟待解決的問題。

除了設備本身面臨的挑戰，測試人員怎樣去測試這些場景同樣是問題關鍵。當然，理想的情況是真的具備這么多車載防火墻和管理平臺進行交互，但在實驗室環境下顯然是不可能的，設備生產、設備存放、環境搭建、測試執行等操作成本太高且效率太低，既要驗證多設備場景，確保上線后不會出現嚴重問題，又要認清現狀、面對現實情況。在這種沖突與矛盾之中，急需尋求一種切實可行的測試方案，快速有效地解決實際問題。

03 測試構想

車載防火墻與統一安全管理平臺交互過程中涉及gatewayID和gatewayIP兩個關鍵字段。 其中，gatewayID表示車載防火墻唯一的ID標識； gatewayIP表示車載防火墻管理IP，也是與統一安全管理平臺通信所使用的IP地址。 單一改變gatewayID相對比較容易，無論是使用Python腳本還是shell腳本都可以實現。 但是，對于集中管理平臺而言還是只有一個IP地址與其通信，并且也不便于在管理平臺上基于IP地址進行檢索分析。 因此需要同時改變gatewayID和gatewayIP以更真實的場景來模擬不同的車載防火墻設備，進而得以驗證同一時間可以上線設備數量（新建速率）以及最多允許多少臺設備同時在線（并發數量）。

04 測試方案

搭建如圖4-1所示的性能測試拓撲，其中Linux客戶端可以修改上述gatewayID和gatewayIP，用于模擬多臺車載防火墻與統一安全管理平臺交互； 三層交換機配置ETH0和ETH1于同一VLAN，如 VLAN4093，接口VLAN-IF 4093配置多組IP地址，用于實現車載防火墻既可以和管理平臺二層通信又可以進行三層通信，適應客戶現場不同的組網環境。

圖4-1 性能測試拓撲圖

測試思路可以分為以下幾個步驟：

（1）Linux客戶端設定上線策略（如上線數量、上線速率、循環次數、延時等）

（2）Linux客戶端修改接口IP地址，即gatewayIP

（3）Linux客戶端根據接口IP地址修改gatewayID

（4）Linux客戶端模擬車載防火墻上線

如圖4-2所示，展示了一個基于shell腳本實現的實例，可以是物理機Linux，也可以是虛擬機Linux。

圖4-2 性能測試實例

在測試統一安全管理平臺日志分析性能時，可以在上述基礎上直接上傳各種類型日志。但在實施過程中遇到新的問題，如圖4-3所示，日志內容中GATEWAY_ID字段需要與上述gatewayID一一對應，否則所有日志都只能關聯到同一臺設備上，影響下一階段的日志查詢與分析。這里大家不妨先思考一下如何解決，欲知后事如何，且聽下回分解。

圖4-3 車載防火墻日志示例