11 月 1 日至 2 日夜间，俄罗斯主机与云服务商 Beget 遭遇了一次和勒索软件完全不同的攻击：攻击者没有加密数据、没有索要赎金，而是在拿到整套基础设施管理系统的控制权之后，直接运行删除脚本，把客户数据清零。受损范围覆盖 VPS、S3 对象存储、Kubernetes 集群，连用于整机恢复的 VPS 二进制备份也一并被销毁，CDN 与 IP 地址配置同样未能幸免。
事件概述
Beget 是俄罗斯互联网的关键节点之一，承载约 15% 的俄罗斯国家顶级域名活跃网站，数量在 33 万到 50 万之间。事故导致大量站点无法访问，依赖其服务的第三方也被波及——汽车共享平台 BelkaCar 因为跑在 Beget 上，被迫紧急迁移。
公司已把事件定性为不可抗力，并建议所有客户立即更换存放在受影响服务器上的密码与访问密钥。攻击者身份和入侵入口仍在调查中，公开信息里没有说明初始入口是钓鱼、凭证泄露还是某个面向公网的管理组件被利用。
技术细节
公开披露里最有价值的一句话是「攻击者获取了整个基础设施管理系统的控制权」。云主机商的管理面通常同时握着虚拟化平台 API、对象存储的管理密钥、K8s 集群的 kubeconfig 签发能力、以及备份系统的删除权限。它不是一个普通后台，而是一把能开所有房间的总钥匙。
拿到这把钥匙之后，删除脚本不需要利用任何漏洞，用合法 API 就能把 VPS 磁盘、S3 bucket、K8s 持久卷和备份镜像一起抹掉。这也解释了为什么「有备份」没能救场：被删的正是备份本身，而且是二进制级的整机备份。文件级备份幸存下来，成了唯一的恢复依据。
影响评估
恢复的难点不在技术，在信任。Beget 的工程师必须对超过 1000 台服务器做手动安全排查，确认没有隐藏后门和恶意软件之后才能逐台放行——否则恢复一台就被重新感染一台。这意味着云服务客户在短期内拿不回自己的数据。
结果分化很明显：普通虚拟主机上近 100% 的网站有望恢复，因为相关文件备份完整；云服务客户的不确定性大得多，部分数据可能永久丢失。对站点运营者来说，这是最难受的一种事故——服务商说「在恢复」，但你不知道自己的那一份在不在这批里。
修复建议
对使用云主机的站长和运维，这件事能落地成四条动作：
- 备份要异地，更要不可变。同账号、同区域、同一套权限体系下的备份，在管理面被攻破时等于没有。对象存储开版本控制加对象锁（WORM），备份账号与生产账号分离，删除权限单独授予
- 管理面不暴露公网。云平台 API、K8s apiserver、备份控制台全部收进内网或零信任网关，管理入口只留跳板机，跳板机再做来源 IP 白名单
- 给删除操作上刹车。批量删除、bucket 清空、快照与备份删除这类高危 API 加二次确认与审批流程；速率限制往往比事后告警更有效，因为删除脚本跑完只要几分钟
- 密钥分层。能用临时凭证就不留长期 AK，CI/CD 与运维人员各自独立身份，避免一把密钥通吃全部资源
如果你有站点跑在中小型海外主机商上，值得现在就问一句：他们的备份，是不是同一套权限体系就能删掉的？这个问题的答案，决定了下次事故里你是「恢复」还是「重做」。这也是传统「高防 + 防篡改」思路在云环境里必须补上的一环——防的不只是打进服务器的人，还有拿到管理台的人。