刚换的密钥又被盗用：Zeabur备份把恢复流程拖回原点

Zeabur的2026年10月19日报告记录了一次恢复失败：新密钥进入备份后，又被非法使用。回看这起10月事故，问题不是密码够不够复杂，而是复制密码的通道有没有隔断。

这家应用部署平台此前已经出过一次事故。它的9月报告说，8月27日，攻击从一个用户部署的服务开始，逐步穿过内部网络和平台账户，最终进入生产环境。攻击者读取了项目配置，其中包含连接其他服务所需的密钥和数据库密码。平台随后宣布停用旧认证方式，并加强权限和网络隔离。

这里的“密钥”可以理解为软件替你办事时使用的通行证。人登录网站输入密码，程序连接云服务也需要类似凭证。权限如果太大，一张通行证丢失就不只影响一个小功能。Zeabur的8月报告承认，旧凭证缺少细分权限和有效期，内部服务持有的云权限也超过日常所需，让攻击越走越远。

报告区分了两件事：新钥匙进入备份及后来被盗用是已确认事实，攻击者下载该备份则是公司的调查判断。它像换完家门锁，又把新钥匙复印件送进别人仍可能打开的文件柜。换锁本身没错，漏掉的是复印件如何流转。

这并不说明自动备份不该做。备份负责防止数据丢失，权限管理负责防止数据落到不该拿的人手里，两件事必须一起设计。恢复服务时，如果只盯着主系统，保存副本的地方就可能成为盲点。判断安全恢复是否完成，不能只看新密码有没有生效。

Zeabur的官方状态页承认，凭证更换和安全改进没有充分落实。平台表示已撤销相关凭证、封堵已知入口、调整访问控制及备份做法，并提醒受影响用户：即使8月后已经换过密码和密钥，也需要按这次通知重新处理。服务重新能用，不等于已经流出的资料随之失效。

对把网站、自动化流程或数据库交给云平台的人，这个案例把一个抽象问题说得很具体：恢复不能只换门上的锁，还要找出所有仍能复制钥匙的地方。选择服务时，故障后怎样隔离入口、撤销旧权限和处理备份，同样是需要认真看的能力。

原始事故报告发布日期：2026年10月19日。