信息系统安全事故

2023年11月，信息系统某省级三甲医院的安全核心业务系统被勒索病毒加密。凌晨两点，事故值班工程师在监控大屏上看到数据库响应时间从80毫秒跳到12秒，信息系统紧接着HIS系统全线飘红。安全急诊挂号停摆，事故手术排程无法调取，信息系统连门口的安全药房发药窗口都只能靠手写处方应急。事后溯源发现，事故攻击入口是信息系统一台连了内网的老旧CT机——厂商远程维护用的账号密码，六年没换过。安全

这不是事故孤例。我跟踪过十几起公开通报的信息系统信息系统事故，发现一个挺讽刺的安全规律：越是被寄予厚望的“高可用”架构，往往越容易在某个不起眼的事故角落被撕开口子。 双活数据中心、异地灾备、负载均衡，这些东西堆起来看着很踏实，但运维人员图省事留的一个后门、一个测试账号、一条没关的调试接口，就能让几千万的投入变成摆设。

去年某银行的事故更典型。他们的核心交易系统做了同城双活，切换演练季度一次，报告写得漂漂亮亮。结果某天下午，一个运维工程师在变更窗口执行了一条看似无害的配置命令，把主备之间的心跳线给断了。双活机制误判主节点宕机，自动切换——但切换后的节点因为一个未同步的存储卷，直接挂了。两套系统同时不可用，柜面交易中断47分钟。事后复盘，问题出在变更管理流程上：那条命令被三个审批人点了“通过”，没人注意到它会影响心跳。流程有了，但流程里的人没看懂。

安全事故的根子，十有八九不在技术本身。技术只是最后那个扣动扳机的动作。真正的问题藏在日常的懈怠里：密码复用、权限泛滥、日志没人看、告警被静音。我见过一个运维团队，监控系统每天产生两千多条告警，他们干脆把大部分阈值调高到几乎不会触发的水平。问起来就说“误报太多，烦”。等真出事的时候，告警还在，只是没人信了。

还有一类事故更隐蔽——数据泄露。某电商平台2022年被曝出用户信息打包出售，查到最后发现是一个离职半年的员工，用还没注销的VPN账号登进了测试库。测试库里有全量生产数据的副本，明文存储，没有脱敏。离职流程走了，账号没关，就这么简单。企业花大价钱建了数据防泄漏系统，拦住了外部攻击，却拦不住自己人从里面把门打开。

说回那家医院。系统恢复用了三天，部分数据永久丢失。院长在内部会上拍桌子，问为什么灾备没起作用。答案很尴尬：灾备系统确实有，但备份策略是每天凌晨全量、每小时增量，而病毒是在凌晨一点半开始加密的——增量备份还没跑，全量备份已经被加密覆盖了。灾备的“备”，和真正能用的“备”，中间隔着一次真实的恢复演练。

我自己的判断是，信息系统安全这件事，技术手段能解决百分之六十的问题，剩下的百分之四十靠的是人和流程的较真。但现实里，那百分之六十往往被当成全部，剩下的百分之四十被写在制度文件里，锁在柜子里，直到事故来了才翻出来看。安全不是买来的，也不是堆出来的。它是一个需要每天醒来重新确认一遍的状态。松懈一天，它就可能变成事故通报里的一个案例编号。