10 月 7 日凌晨，软银集团旗下云平台 IDCF Cloud 遭遇勒索软件攻击，东日本第 1 区域大量虚拟服务器停机且无法重启。这起事故本身不算稀奇，离奇的是后续：黑客在每块数据存储的根目录都留下了勒索信，IDCF 运维却超过 7 小时毫无察觉，一直在给已经死掉的虚拟机反复按电源重启。最后是黑客拿下了 IDCF 官网挂出勒索信，替这家云厂商发了一份「安全公告」。
受影响范围不小：四个分区为 495 家企业和日本地方政府提供服务。黑客在勒索信里列出的战果包括：239 台虚拟化主机被触及，225 块数据存储全部加密，16600 多块虚拟机磁盘被封存，3.6 PB 主存储沦陷，55 万多个快照被销毁，41.5 PB 备份容量消失。
七小时里，运维在做什么
按黑客的说法，勒索信从当天凌晨 3 点起就放在每块数据存储的根目录，225 份，特意做到「不可能被错过」。运维要做的只是随便登录一台 ESXi 主机，跑一条 ls 命令就能看到。而现实是，IDCF 的网络运维中心在整整七小时里，一直在 vCenter 里对宕机虚拟机执行强制断电重启，并且反复轮换控制台密码，没有人查看存储卷的文件系统。
更讽刺的是客户的反应速度。日本时间早上 8 点 34 分，就有用户提交工单报告虚拟机无法启动，问题指向明确。IDCF 支持台的处理方式是用模板批量关闭工单，还顺手收集了客户对工单处理的满意度评分。事故公告则一条也没发。
这份勒索信为什么值得所有运维读一遍
抛开戏剧性，这起事件暴露的是云平台灾备流程的系统性失灵。第一道失守的是监控：勒索软件批量加密数据存储、销毁快照，不可能不留痕迹，异常却持续了七小时无人告警。第二道失守的是支持流程：客户工单是最直接的故障信号，被模板化批量关闭，等于亲手掐断了唯一有效的报警通道。第三道失守的是沟通：事故公告缺位，最后由攻击者代劳，云厂商的信誉比数据损失更难恢复。
技术上还有一个被反复验证的教训：备快照不等于有备份。黑客明确宣称备份容量已被清除，快照被销毁。快照与备份存放在同一套被攻陷的虚拟化体系里，就只是同一份资产的影子。真正的容灾必须异地、隔离、不可篡改，这条原则在勒索软件时代只贵在执行。
写在最后
黑客在信里写了一句值得抄下来的话：我们通常不会这样公开炫耀，没想到你们的反应这么糟。对云服务商来说，安全能力最终体现在最坏情况的响应流程里，而不是官网的宣传页上。一家云平台在七小时里既没发现勒索信、也没处理工单、还没发公告，客户用脚投票只是时间问题。国内同样在大力推企业上云，这份反面教材来得正是时候。
配图说明：本文封面为 AI 生成图像。
参考：蓝点网《黑客遇到日本企业也很无奈：挂了7小时还不停地戳电源重启 就是不看勒索信》报道，本文为基于公开信息的独立评述。