上周在南京河西的一栋写字楼里蹲了一下午，跟着某金融机构的运维组跑了半层的机房。刚摸完第三台服务器的登录日志，带队的张哥就把笔记本往桌上一摔——”又来？”
我凑过去看。屏幕上是刚跑出来的基线扫描报告，满屏的绿对勾，得分96。
“这报告拿出去，监管看了都得夸。”张哥扯了扯领口，”上周我们刚因为测试环境的数据库开了3306公网端口，被人扫了半宿，差点拖库。”
我愣了下。那这个96分的报告，是怎么打出来的？
别把基线核查当走流程
说白了，大部分人对网络安全基线核查的认知，还停留在”扫一遍弱口令、看一下开了哪些端口、补丁打没打全”的层面。
真到现场就知道根本不是这么回事。
上次接触的一家电商公司，生产环境的所有服务器基线项全合格，结果出事的是压测用的临时服务器——那台机器上线的时候没人走资产登记，基线扫描根本没扫到，上面跑的压测环境，密码还是默认的弱口令。
工具扫出来的结果，永远有滞后性。
你以为扫完所有IP就万事大吉？资产表上的IP可能有一半是早就下线的旧设备，剩下的一半里，还藏着没人记得的临时测试机、外包人员带进来的便携服务器、甚至是接在办公网里的打印机——这些设备的配置，没人会主动更新到台账里。
麻烦在于，很多公司做核查，只盯着生产环境的核心系统，觉得其他地方都是边角料。真等黑客从一个没人在意的边角料摸进来，横向渗透到核心数据库的时候，再翻之前的基线报告，才发现那上面全是没用的对勾。
整改不是打补丁那么简单
很多人觉得网络安全基线核查与整改，就是把扫描出来的高危项全消掉，改完就完事。
太天真了。
去年遇到的一个case，某制造业的生产调度系统，中间件版本是2018年的，基线扫描报了三个严重漏洞，要求升级。结果业务方直接拍桌子——这个系统是当年外包公司做的，源码早就丢了，现在跑的版本是唯一能兼容车间所有设备的版本，升级完直接停线，损失一天就是七位数。
你敢硬升？
最后他们的处理方式根本不是硬打补丁。把中间件的端口从公网撤下来，限制只有车间内部的三个固定IP能访问，每半小时审计一次登录日志，把公网暴露的风险直接压到了能接受的范围。
没人愿意做这种妥协。
但你要考虑业务的承受能力。上次有个刚毕业的运维，半夜按照基线要求，把生产服务器的默认共享关了，结果第二天整个财务系统跑不动——当年开发财务系统的人写代码的时候，就依赖这个共享路径取配置文件，没人记得这事。
整改不是对着条目打勾。
那些看起来冷冰冰的配置项背后，牵的是跑了好几年的老系统、是天天要对账的财务流程、是一停就会被客户投诉的业务接口，根本不是拿着扫描报告对着条目改就能解决的事。
别等出事了才补作业
我见过太多公司，平时没人管基线的事，等监管要上门检查了，才连夜拉着运维组跑一遍扫描，改一堆配置，等检查过了，又恢复原样。
这种临时抱佛脚的事，做了也白做。
上次那家要迎检的公司，为了过基线检查，半夜把所有员工的系统密码都改成了复杂度极高的随机字符串，结果第二天早上，一半的运维登不上自己的账号，连核心业务的监控平台都进不去，差点误了早高峰的业务。
真要把基线这事做扎实，根本不用等出事了补。
现在不少公司把核查环节嵌到了新服务器上线的流程里——机器刚装完系统，自动跑一遍基线扫描，不符合要求的直接打回，不让接入生产网络。比每年一次的全面核查有用得多。
前几天张哥给我发消息，说他们这次的基线报告交上去，没有把所有项都打勾，列了三个暂时没法彻底整改的老系统风险项，每个项后面都附了对应的临时防护措施和后续的升级计划。
领导没骂他。
反而说，这是这几年见过的最实在的一份基线报告。