先说一个数字：7 分钟，3.6 PB。
这是攻击者自己在留言里写的——他们声称 10 月 7 日凌晨那波操作，7 分钟加密了 225 个数据库、合计 3.6 PB，锁了 1.6 万块虚拟机磁盘，删掉 55 万多个快照副本。这些数字是攻击方给的，服务商 IDC Frontier 没有认领，但大方向对得上：软银集团旗下的云服务 IDCF Cloud，东日本第 1 区域的四个可用区（tesla / henry / pascal / joule）全线趴窝，官方一对一通知的受影响客户有 495 家，里头既有企业也有地方政府。
数字我核了两处：iThome 的报道和 certi.news 的复盘（后者带了攻击方留言原文）。「3.6 PB」「495 家客户」这类关键口径两边对得上；而「7 分钟」「225 个数据库」属于攻击方自报，服务商始终没认领，引用时留个「据攻击方称」的余地比较稳。
真正让同行背后发凉的，不是加密速度，是"处置速度"。
下面这段是当时媒体复盘里的说法，我没有一手来源，只当报道看：出事当天 IDCF 的运维团队在做的事，是反复重启那些根本起不来的虚拟机、反复重置控制台密码。据报道，这样的处置持续了 7 个小时，其间没有意识到那批机器不是"病了"，是被加密了。同一批报道里还有一处细节（同样是报道口径）：攻击者在留言里"贴心"附了排查指引——随便找一台 JE0 集群的 ESXi 宿主机，开 SSH 或 DCUI，看根目录下的 RECOVER-INFO.txt，"我们留了 225 份通知，你们一份都没看到"。
最后是客户先发现不对劲的。再后来，攻击者干脆把嘲讽留言打到了云控制台的首页。到这一步，事故才算"官方确认"。
这中间断掉的不是某一台机器，是整条链路：告警、研判、上报、公告，一环都没接上。
我不想只把它当笑话看。这种"失能"，太多团队的预案里都埋着种子——备份策略写着"每日异地容灾"，但快照和主存储挤在同一套存储域里，勒索软件一串连锁删除就一起带走。IDCF 这回最致命的，恰恰是"主存储和快照/备份被同时摧毁"：客户数据还能不能取出来，官方 10 月 8 日的公告说得含糊，大意是恐怕难，只能靠客户自己保管的离线备份重建。连带受灾的还有一对熟面孔——博客系统 Movable Type 的开发商 Six Apart，31 台服务器停摆，最后拿 10 月 7 日凌晨 1 点的 Google Cloud 备份，连夜迁到别家云重建；还有日本水产大厂 Nissui 的出入货系统、企业批发平台 NETSEA，以及茨城县政府和县警的官网（开了临时站顶着）。
云厂商遭受灭顶之灾的时候，客户几乎没有自救空间。这也是"上云即安全"这个认知错觉最贵的一次注脚：云的安全水位，本质上是服务商的安全水位；你的数据在谁的盘上，风险就跟着谁走。
能落到地上的动作其实很老套：
- 备份必须离线、不可变。 同一套存储域里的"快照"，不算备份。物理隔开的、或者上了对象存储 WORM（一次写入多次读取）锁定的，才算。
- 演练"看不见"的场景。 别只演"机房断电"，要演"你登录不进去、监控全瞎、厂商自己都在救火"——这时候你手里还剩什么。
- 留一手脱离厂商的排查能力。 至少要有一套不依赖云控制台的、自己的机器状态感知手段；控制台一停，等于你和机器之间唯一的那只眼睛被蒙上了。
说到"自己的眼睛"，这几年做远程批量管理，最大的体会是：机器一多，光靠一个中心化控制台迟早会翻车。七亿批量远程管理工具里不少设计就是冲这个去的——被控端的状态和凭据不往服务器回传，控制台那边出了岔子，手里的连接还在。云宕机这类"上游一起完蛋"的故事，我之前也写过一篇（《一个 DNS 缺陷，瘫了半个互联网 15 小时》）；备份到底该怎么分层、怎么才算真正"离线"，官网页那份安全科普聊得更细。
回头想，这事我最怕的不是那 7 分钟，是报道里那 7 个小时没人觉得"不对劲"。换我值班，大概率也是先重启再说。
评论