09:47，网络监控大屏上跳出一条红色告警——财务共享服务器的攻击CPU使用率瞬间飙到97%。我端着咖啡站在值班台前，应急演练第一反应是记录“又有人跑爬虫了”。但三秒后，网络网管老周喊了一嗓子：“数据库在往外吐数据！攻击”

那感觉像被人掐住了喉咙。应急演练财务数据库是记录核心中的核心，备份策略再完善，网络也架不住数据实时外泄。攻击我们按预案拉响二级响应，应急演练电话通知到应急小组时，记录我听见有人小声嘀咕：“上周刚演练过，网络又来？攻击”——没人笑得出来。

攻击源锁定在一台运维跳板机上。应急演练日志显示凌晨4点有人用合法账号登录，之后每隔十分钟执行一次数据导出命令。手法不算高明，但足够阴——它避开了所有流量监控，因为走的是内部通道。老周切断跳板机外联，我按下数据库的紧急只读开关，整个过程用了大概六分钟。

真正的麻烦在恢复环节。财务对账系统依赖实时数据流，只读模式一开，业务直接停摆。电话那头财务总监的声音明显压着火：“你们搞演练能不能挑个下班时间？”我没法告诉她这不是演练。应急小组分成两拨，一拨追查跳板机上的残留进程，另一拨手动核对导出记录，看哪些表被碰过。

十点二十分，攻击源彻底隔离。排查结果让人后背发凉——导出记录里躺着近三个月的客户交易明细，但时间戳断断续续，像是有人故意打乱节奏。我们翻遍跳板机，最后在/tmp目录下找到一个伪装成日志的脚本，里面写死了每小时的随机延迟。写脚本的人很懂运维习惯，知道没人会半夜盯着/tmp目录看。

事后复盘，最尴尬的是我们发现这个账号的密码三个月没换过，而密码本身是“Finance@2024”。安全部门年初就发过整改通知，但财务那边以“影响业务连续性”为由申请了延期。延期申请单上签字的正是那位财务总监。

那天下午三点，全公司收到一份内部通告，措辞很克制，只说“监测到异常行为，已处置”。但我知道，财务部内部开了整整两小时的会，晚上八点我离开时，那层楼的灯还亮着。第二天一早，所有核心系统强制启用双因素认证，跳板机密码策略改为每两周轮换一次。

这次事件没有造成实际数据泄露，但给所有人提了个醒——应急演练再频繁，也挡不住一个过期密码加上一次侥幸心理。技术手段能拦住大多数攻击，拦不住的是人的惰性。那杯凉透的咖啡，我到现在都记得味道。