作者：剑客阿凡

01 G行中间件安全漏洞修复体系建设-背景介绍

近年来随着国内外形势变化，信息安全的重要性日益提升，金融行业作为安全攻击的重灾区，信息安全防控建设逐渐成为科技部门的一项重要工作。根据SkyboxSecurity发布的2020年上半年漏洞和威胁趋势报告，2020年漏洞数量预计将超过20000个，可能会创历史新高。

中间件类安全漏洞是高危漏洞圈子的常客，主要集中于应用中间件及Web中间件，常见中间件高危漏洞如下:

中间件安全漏洞具有易被利用，影响范围广，与应用关系紧密等特点，部分漏洞如java反序列化漏洞受限于JDK相关功能机制，难以彻底修复，相应漏洞会不断出现，所以中间件相关安全漏洞修复是一个长期持续，不断循环的过程，需要完备的流程和体系对整个修复阶段流程进行支持，否则漏洞修复就会成为一次次运动式专项行动，造成大量不必要的人力浪费，漏洞全生命周期管理建设势在必行。

漏洞管理生命周期包括，漏洞发现、漏洞评估、漏洞修复、漏洞验证。本文主要聚焦于漏洞修复环节，从G行中间件安全漏洞修复体系建设入手，抛砖引玉，讨论一下安全漏洞快速修复方案。

02 G行中间件安全漏洞修复体系建设-痛点识别

G行的漏洞标准修复流程如下图：

这是一个通用标准流程，但是在实际执行中遇到如下痛点:

1.配置管理不够准确，漏洞影响范围需要写检查脚本，在生产环境全量下发排查，为避免遗漏，受影响列表依赖应用团队人工确认，确认耗时较长，且依然容易遗漏。

2.漏洞修复方案仅有安全团队提供的基础指导方案，如打补丁或修改配置文件，需要项目组结合自己的系统环境适配修复方案，导致项目组与中间件专业团队之间存在大量沟通确认工作。

3.修复测试要求不明确，部分系统为避免生产实施风险，修复升级不管什么情况都要进行全量功能及非功能测试，测试工作量较大，导致修复完成周期大大加长。而另一部分系统为了尽快修复漏洞，仅进行少量或不进行任何测试，直接进行生产修复，易造成生产事件。

4.每个系统测试完成时间不同，测试结果跟踪耗费大量人力，生产实施也只能随各系统测试完成时间分散安排，实施方案和时间的不确定性使运维人员疲于奔命，也使生产版本碎片化，生产漏洞修复追踪困难。

03 G行中间件安全漏洞修复体系建设-优化方案

为解决上述痛点，G行对中间件漏洞修复方案进行了全体系优化，目标是在加快大批量漏洞修复效率的同时尽可能减少部门整体修复成本以及避免大批量修复导致的生产环境事件：

一、建立中间件标准化管理体系

中间件的产品种类众多，实施部署方案也随项目情况各有不同，想做到安全漏洞快速修复，其基石是标准化，即标准的产品范围，标准的部署架构，标准的安装路径，标准的版本，标准组件，标准的参数配置文件及安全参数。

产品范围：对同一类型的中间件，如应用服务器、Web服务器、消息中间件等，使用一款主流商用加一款主流开源作为行内主推版本的模式，明确产品目录，严格控制非产品目录中间件产品随意使用，对确实有必要新引入的中间件产品，执行明确的引入标准，提供标准交付文档，经过研究、试用、主推三个阶段，完成标准化引入。

部署架构：关注互联网等高危网络区域中间件部署情况，禁止将应用中间件直接部署在互联网相关域，应使用web中间件对请求进行安全过滤和转发，禁止直接透传全部请求。

安装路径：限定标准中间件软件路径、应用部署路径、日志路径、配置文件路径，便于统一管理及标准工具开发。

标准版本：维护一个主推版本，非主推版本的环境需要在应用系统任意基础组件（包括操作系统、数据库、中间件）触发升级策略时，一同升级至最新的主推版本。

标准组件：为确保安全，对环境一些高危组件进行删减，如weblogicwsat高危war文件，tomcat控制台、各中间件产品自带的示例程序等。

标准配置文件及安全参数：对启停涉及的脚本及配置文件进行二次封装，明确配置文件安全参数设置要求，控制脚本修改权限，通过工具对脚本及配置文件进行统一检查。

标准化是漏洞快速修复方案的基础，在推进标准化的初期一般会遇到各种阻力，这时需要领导层大力支持，严格控制非标环境上线，同时对存量非标环境制定整改计划，并将漏洞修复负责人进行分类，即标准化环境修复，由运维部门统一负责实施，非标准环境修复由项目组负责实施，未能按时修复会进行相应考核，督促项目组配合完成中间件环境标准化。

二、完善配置管理完整性、准确性

配置管理的完备程度决定了安全漏洞修复的准确性，人工维护配置管理数据的方式是很难做到数据完整且准确的，G行通过配置管理系统SMDB的建设以及设立部门长期KPI指标考核配置管理完备性等方案不断提升自动化配置管理水平，现已实现了全环境配置管理覆盖，可对中间件环境进行自动发现，自动关联管理人员、网络域等信息。每次新漏洞发布时，可根据漏洞情况，快速生成影响范围和实施列表，消除低效人工确认环节。

三、安全漏洞修复方案固化为标准工具集，明确部门安全漏洞修复预案，形成安全漏洞修复标准工艺

在中间件环境标准化及配置管理完整准确的前提下，对标准修复方案进行工具化，形成一键在线升级工具、一键在线打补丁工具、标准参数修改工具等，使漏洞需求可大范围批量执行，无需项目组关注安全修复动作明细。

开发中心、测试中心、运维中心共同明确漏洞修复测试标准，识别为小版本的补丁修复、配置变更及版本升级仅需进行完备功能测试，识别为大版本升级时才需补充进行性能、稳定性等非功能测试，合理使用测试资源。

安全修复的整体节奏为运维集中推送，按标准批次实施，应用系统分别自行验证，预留验证时间，验证有问题的举手反馈，使用一键回退工具进行变更回退，并列入独立修复清单由安全团队跟踪。通过预定时长的系统日常测试替代专门的功能测试，通过逐步扩大试点实施范围验证安全漏洞修复的可靠性，通过快速回退工具实现修复异常的快速处理，通过这些预案，可在力保最后生产实施批次安全的前提下，做到无需为补丁升级单独安排额外功能测试，同时可将生产修复固定在若干个批次之内，减少运维团队的实施和验证成本，还可在确保系统得到较充分验证的前提下，大大加速安全漏洞的修复速度，同时减少安全修复环节人员的开销，做到润物细无声。

04 总结

通过近年的中间件安全漏洞修复体系建设，G行商用中间件的标准化率已接近100%，总结出的一定经验，简单来说就是：

1.体系标准化：实现中间件产品选型、安装配置、运维规范等方面的标准体系建设，打好自动化运维基础。

2.工具自动化：建设具备自动发现、自动采集功能的配置管理系统，确保其准确性；建设高效的自动化修复工具和自动化验证工具，减少修复成本。

3.流程工艺化：建设合理有效的修工作流程，通过流程工艺把控实施节奏，减少生产修复风险，明确各相关方在漏洞修复过程中应承担的职责，使各方各司其职，共同推进安全漏洞快速修复。

这些经验不仅限于中间件安全漏洞修复，其他系统组件的漏洞修复机制也可做参考。下一阶段我们将着力推进平台化建设，将现有安全漏洞修复工具、流程、实施工艺通过平台进行统一封装，实现中间件安全漏洞自动无感知修复及验证、漏洞生命周期可视化管理、总分行全机构服务覆盖等目标，进一步提升中间件安全漏洞管理水平。

欢迎留言交流分享，祝近安。

中国光大银行信息科技部

声明：本文来自安全内参，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。