系统漏洞扫描是固定配置还是移动配置

一家银行的系统核心业务系统每季度做一次漏洞扫描，用的漏洞是固定配置。另一家初创公司每周跑一次扫描，扫描扫描目标清单却总在变——今天多了个新上线的固定API网关，明天又临时加了个测试环境。配置你说哪个算固定配置，还移哪个算移动配置？动配

其实这问题问反了。系统漏洞扫描的系统配置从来不是固定或移动的二选一，而是漏洞扫描策略固定、扫描范围动态。扫描拿我见过的固定一个运维团队举例，他们把所有生产服务器按业务重要性分成三档：核心支付系统每周扫一次，配置普通业务系统每月扫一次，还移开发测试环境只在版本发布前扫。动配扫描器用的系统规则库、端口列表、弱口令字典全是同一套标准配置，但每次扫描的目标IP段和排除项，都是当天早上根据变更工单临时调整的。

固定配置的底层逻辑是基线管理。你总得有个统一的扫描模板，否则今天用Nessus扫端口，明天换成OpenVAS扫Web漏洞，结果根本没法横向对比。但你要是真把扫描目标也写死成配置文件，那麻烦就大了——云环境里容器IP天天变，Kubernetes集群的Pod重建一次就换一批地址，固定IP清单第二天就失效大半。有个做电商的朋友跟我吐槽过，他们曾经把扫描目标写死在Ansible脚本里，结果某次促销活动临时扩容了20台云主机，漏扫愣是没覆盖到，等到被攻击者扫出个未打补丁的Redis漏洞才反应过来。

移动配置的价值在于适应资产变化。可移动不等于随意，得有个动态发现的机制兜底。靠谱的做法是用CMDB（配置管理数据库）当唯一数据源，扫描系统每天凌晨从CMDB拉一次全量资产清单，自动剔除已销毁的实例，再把新创建的虚拟机自动加入扫描队列。这样配置文件的“移动”其实是自动化流程在背后驱动，而不是靠人工手动改列表。

还有个容易忽略的细节：扫描策略本身也得半固定。漏洞库每周更新，你不能拿三个月前的插件版本去扫今天的系统。我见过最典型的翻车案例是某单位把扫描配置完全锁死，结果Log4j漏洞爆发后第三周才跑完一轮全量扫描——不是扫描器跑得慢，是规则库没更新，扫了也白扫。所以固定配置里至少得留一个“规则库自动更新”的开关，扫描频率可以按季度定，但检测引擎必须保持最新。

说到底，固定的是流程和基线，移动的是目标和范围。你把扫描策略制定成每周一次、用同一套认证凭据、输出统一格式的报告，这叫固定；但具体扫哪台机器、排除哪些维护窗口，得跟着业务变。有人非要把这两者对立起来，结果要么是扫描报告跟实际资产对不上号，要么是每次扫描前花半天时间改配置。真正的解法是让配置模板参数化——扫描端口范围、漏洞等级阈值、通知接收人这些写死，目标IP段和调度时间做成变量，由自动化平台根据资产变更事件触发。这样既保住了基线的一致性，又不会被动态环境卡住脖子。