统一安全管理平台性能测试之设备管理

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 车载防火墙日志示例