文章总结： 文档介绍了生产环境安全运维的三个关键方面：补丁管理强调定期与临时策略结合；漏洞管理提出职责划分、多种处置方法及SLA制定建议；外部攻击面管理作为CMDB补充，帮助发现公网暴露资产。核心建议是建立清晰的修复流程和SLA，并通过EASM增强资产监控。 综合评分： 82 文章分类： 安全建设,安全运营,漏洞分析,应用安全

信息安全体系之生产环境安全运维(1)

原创

我是刘庆华 我是刘庆华

安全道

2026年3月1日 23:02 上海

前面的文章写了交付流程，应用经过交付流程就进入到了生产环境，也就是到了运维阶段，运维阶段有哪些安全工作需要做呢？上图

生产环境安全运维(图上右下侧内容)

应用在生产环境的安全运维内容非常多，并且在信息安全团队的工作中也是比较重的一块，我大体列了11项(图中右下侧蓝色斑块内容)，我将基于过往的实际工作把每项内容给大家简单介绍一下，考虑到可读性，本次不会讲太深，未来结合案例再深入探讨。那我们按照从上到下从左到右的顺序依次介绍一下。

1.补丁管理(Patch)

补丁指生产环境使用的操作系统、各种三方软件、云原生应用等的补丁。通常情况下补丁会支持一些新功能和修复一些bug和安全问题，因为我们这里是在谈信息安全，所以我们关注的是新功能里的安全功能和安全问题的修复。新功能可能是支持了备份数据的加密或者是可以对接三方KMS等，安全问题的修复可能包含了近期的一些CVE问题。

打补丁通常情况下会采用两种策略：

1.1定期打补丁

比如季度性或者是月度的，在计划好的维护窗口期IaaS/PaaS/供应商等团队负责完成。这里稍微展开一下，打补丁的最高形态是大版本的升级，大版本的升级一般会非常谨慎，因为要考虑兼容性问题，打个patch一般不会有什么问题，但如果是大版本升级，比如从6.0升到7.0，就需要综合考虑上下游应用的兼容程度、软件的官方支持期限、对近期业务是否会有较大影响等诸多因素，所以大版本升级会不那么频繁，有可能一年只做1-2次。

1.2临时打补丁

临时打补丁通常是因为有比较严重的安全漏洞(比如OpenSSL heartbleed, Log4j RCE这类史诗级漏洞或其它一些高风险问题)，需要马上打补丁以消除或降低风险。

2.漏洞管理(VM)

漏洞管理包含漏洞扫描和修复两个主要内容

2.1漏洞扫描

在实际落地时采取白盒扫描的形式对全部应用的底层基础设施进行扫描。

漏洞扫描通常会是在一些服务器或虚拟机上安装瘦客户端(Agent)，Agent按照下发的计划进行扫描并将结果发送至统一的管理服务器进行分析和总结归纳。有些设备无法安装Agent，例如供应商提供的基于完整VM镜像的软防火墙，这类设备就只能是黑盒扫描或者是给个账号进行登录扫描。

漏洞扫描对于运行中的容器会采用不太一样的做法，将运行中的容器做个临时镜像，然后对临时的镜像进行静态扫描，Wiz的就是这样实现的。变通一下，其实在镜像仓库中是存有和生产环境版本一致的镜像文件的，定期扫描这些文件也会可以的，但评估影响时没有扫生产环境的直观。

2.2漏洞修复

漏洞修复对于负责团队来说是一件有些头疼的事情，原因就是待处理的漏洞数量会比较大，当被扫描的底层基础设施比较多，尤其是大规模使用了容器，你可能很容易看到少则几千个风险多则几万几十万甚至几百万个。这种情况下制定出合适的修复策略就变得非常重要了，以下修复策略可供参考：

a.依据团队划分清楚职责

开发团队负责应用直接引入的漏洞，比如容器镜像中某个开发库的漏洞；负责基础镜像的团队负责处置基础容器镜像里操作系统的漏洞；网络团队负责网络设备的漏洞。各个团队职责清晰划分，各管各的漏洞。

b.制定出合适的处置方法

发现漏洞那一时刻并不是所有漏洞都能被彻底修复掉，可能受制于多种因素，比如漏洞所在的软件其供应商还未发布官方修复方案、漏洞的利用方式非常复杂且对应用无直接影响。所以需要针对每个漏洞依据具体情况选择使用合适的处置方法：

• 彻底修复

适合修复方案就绪且很容易马上采纳的场景

• 一定程度消减

例如供应商尚未提供修复方案，但给出了暂时的缓解措施这类场景。

• 接受风险

综合考虑漏洞的影响和修复的时间/费用成本，判定接受风险最合适。

• 标记为无影响

  漏洞确实存在，但对应用和系统无直接影响，可以在漏洞扫描工具和风险跟踪系统里将其标记为无影响。但未来如果能顺便修复掉它更好一些，因为一切都在变化，未来应用的业务场景变化了，可能这个漏洞就不是无影响了。还有就是从合规角度来说，让漏洞从扫描报告中消失是最稳妥的办法，不然当被内保外部审计的时候，还需要专门花精力解释，多一事不如少一事。

• 标记为误报

  毕竟是工具发现的，所以会有误报漏洞。随着扫描工具的不断演进以及AI的加持，误报的漏洞会越来越少。

c.制定合适的处置SLA

对于生产环境中已经承载了业务的应用和系统，为降低漏洞所带来的风险，需要结合公司所在行业、整体业务规模、可支配的资源等因素制定出SLA。各个行业、各家公司可能都不太一样，但大总体SLA的差别不大，以下是推荐的修复时限SLA:

严重漏洞(Critical)：1-2天之内

高风险漏洞(High)：5-7天之内

中风险漏洞(Medium)：30天之内

低风险漏洞(Low)：90天之内

这些SLA需要在公司漏洞管理制度中明确规定，并对一线团队和管理层广泛培训告知，不然在执行时一定会有阻力，抱怨修复那么多漏洞会影响项目上线，话说回来，安全工作本就应该是每个项目必须投入的成本，但如果公司安全成熟度比较低安全工作就很容被忽略。

在落地执行时需注意SLA是一个供参考的要求，不代表硬性要求必须100%做到。比如严重漏洞要求1-2天内修复掉，但如果修复方案极其复杂且必须依赖外部供应商的协助，那处理时会是团队安排不同批次的人24×7持续处理直至修复掉，时间上可能会超出SLA，但不应被判定没有满足SLA。

对整体的漏洞修复SLA, KPI可以关注每个团队不同级别的漏洞平均修复时长与规定SLA的偏离度。

3.外部攻击面管理(EASM)

外部攻击面管理是最近几年出现的概念，其和企业的资产管理有着比较密切的关系。EASM是用来检测和管理企业在公网暴露的资产，资产类型包含域名、web应用、API、IP地址、数字证书等, 云资产如果可以公网访问也是可以被EASM监控的。

EASM的核心价值是能够帮助企业自动化检查发现并管理暴露在公网上的资产。那有人会问了，既然是企业自己的资产，按说企业内部都有记录的，为什么还需要从外部监控呢？现实的原因是当企业规模比较大时，内部的资产管理很容易会效率低下，各个BU各个团队各自负责自己的IT资产，即便有CMDB(即配置管理数据库)，资产也很容易未被收录进去，当有些资产要在公网暴露时可能就直接放出去了，未经信息安全团队评估审查。所以作为CMDB的补充，从外部视角发现这些资产并依据情况做必要的安全评审和防护就会很有价值了。例如EASM发现了某个web应用，但这个应用在最近上线前未做信息安全评估，带着很多安全漏洞上线运行，一旦这个情况被发现了，信息安全团队就可以立刻通知相关团队补做必要的安全评审并处置发现的安全风险。

现在的EASM产品也会带漏洞扫描功能，但比较弱，都是黑盒扫描，只能发现一些表面的安全问题，比如使用自签名证书、TLS版本过低等，和白盒漏洞扫描以及入侵测试等是无法比的，但聊胜于无。

这一篇就先说这三项，后面文章再继续讲其它项。

2026年3月1日

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全道 我是刘庆华 我是刘庆华《信息安全体系之生产环境安全运维(1)》