安全无小事：一个月里，我用的两个平台相继出事
我有两个一直留着的账号。
一个是 TiDB Cloud。2023 年 4 月 20 日晚上 10 点 35 分，我在上面建了第一个数据库：AWS 新加坡节点，入门套餐，MySQL 兼容。那会儿 TiDB Cloud 还挺新鲜，一个做 DBA 的，看到分布式数据库能像点外卖一样点开就用，总忍不住想试试。
另一个是 Zeabur。2023 年 8 月 19 日早上 6 点半，我注册了它。它的口号是 Deploy your services gracefully——优雅地部署你的服务。图的就是方便：小项目丢上去，不用再伺候服务器。
三年多过去，两个账号都还亮着 Active。然后就是 2026 年 10 月。
先是 Zeabur。其实 8 月底它已经出过一次事，攻击者顺着一个租户应用的漏洞摸进生产数据库，把用户的环境变量成批读走。团队道了歉、赔了钱、发布了完整的调查报告，看起来要痛改前非。结果 10 月 14 日，第二次事件来了，共享集群的管理凭据泄露，用户容器被直接执行命令。10 月 17 日，创始人林沅霖发信：平台关停，12 月 31 日全面停服。
紧接着是 PingCAP。10 月 19 日，事件报告发布：从 9 月 9 日到 10 月 7 日，攻击者拿着偷来的服务账号凭证，在 PingCAP 的内部系统里进出了 28 天，拷走了客户数据和源代码。日本的用户在 10 月 20 日、21 日连着收到两封邮件，一封致歉报告，一封请大家轮换 API 密钥。
本专栏前两篇文章，写的正是这两件事：《数据库没被攻破，厂商被端了》和《Zeabur 宣布关停》。动笔时是当新闻写的，写完才后知后觉：新闻里的两个主角，恰好都是我三年前注册的平台，我还是人家的早期用户。
结局是两种。
一家直接没了。三年半，从毕业专题做到 10 万注册用户、200 万美元种子轮，不到一个月前还在增长——关停信一封，全清零。
一家还在，而且体量大得多，扛住了。但「扛住」的代价也不轻：源代码被人拷走，日本国内约 5 万件个人信息泄露，用户在控制台里写过的 SQL 成了对方的战利品，而且逐个客户的影响范围，到今天还没有完全确认完。一个死于安全，一个伤于安全。
但说实话，比结局更让我在意的，是两家把消息送到用户手里的方式。这一个月，两家的「通知」我亲身体验了两种版本。
PingCAP 那边，消息是追着用户来的。公告发在网站上之外，邮件直接进邮箱：10 月 20 日一封事件报告与致歉，10 月 21 日又追加一封，单独把轮换 API 密钥这件事点名发给 TiDB Cloud 账户持有人。你不用刷新闻，不用登录控制台，该知道的风险、该做的动作，都摆到了你面前。上面那张截图，就是邮箱里的两行记录。
Zeabur 那边，要分开说。关停这件事，它是发了邮件的：10 月 17 日，创始人林沅霖的信就到了邮箱，标题是 Zeabur is shutting down: what happens next。这封信我先前漏看了，一度以为关停消息只发在网站上——那是我弄错了。
但 8 月底那次安全事件，我没有收到过任何邮件通知。用户的环境变量被成批读走、API 密钥被盗用，我都是这次关停之后，回头去翻公告和报道，才第一次知道。也就是说，真正需要用户马上动手的那种消息——你放在平台上的密钥可能已经泄露，请尽快轮换——没有进过我的邮箱。
差别就藏在这里。两家的公告都发了，邮件也都发了；但 PingCAP 的两封邮件，写的都是安全事件本身，第二封还把「该做什么」单独拎出来讲。而 Zeabur 那次安全事件的说明，只躺在网站的调查报告里，等用户自己去看。放在网站上等用户自己来看，是披露；主动送到用户手里、并且告诉用户该做什么，才叫通知。 群发一封邮件，在所有善后动作里成本大概是最低的一项，但它最能说明问题：出事之后，厂商先想到的是把公告页做好，还是先想到用户需不需要立刻动手。
回头复盘这两条攻击链，最让我感慨的是：没有一环是大事。
Zeabur 那边，是一个租户应用的未修复漏洞、一批没有权限范围、没有有效期的旧 API Key、一把长期躺在内部服务环境变量里的 AWS root 密钥。PingCAP 那边，入口只是一个被盗的服务账号凭证。每一环单拎出来，都是运维日常里「先记着，回头再收拾」的小事。小事摞小事，摞出一家公司的关停信，和另一家公司的事件报告。
安全无小事，这话以前听着像墙上的标语。这个月之后，我觉得它更像一句会计语言：小事是要计息的，平时不还，利滚利，最后一次性结清。
第二重感慨，是关于「早期用户」这四个字。
我们说起自己是某个产品的早期用户，语气里多少带着点资历。但早期用户的另一面是：你把数据、项目和密钥，托付给一家还没被时间验证过的公司。它的安全投入、运维纪律，创始人遇到坏消息时的取舍，你其实一无所知，只能用信任去补信息差。补得对了，叫眼光；补错了，就是 Zeabur 的用户这个月在交的学费——两个半月，把自己的服务从一艘确定要沉的船上搬走。
第三重感慨，是留给自己的功课。
平台出事，用户基本是被动的，这没错。但两次事件看下来，用户的处境还是有差别：你放在平台环境变量里的密钥给了多大权限，备份有没有一份在平台之外，重要的服务是不是全押在了一个地方——这三件事平时做与不做，等到出事那天，就是两种处境。厂商的安全决定你的下限，自己留的后手决定你的损失上限。
最后说回那句口号。
Deploy your services gracefully，优雅地部署你的服务。到最后，Zeabur 用一封创始人署名的信、一份专门写给 AI 编程助手读的迁移指南、两个半月的缓冲期，把优雅做到了告别上。在关停的公司里，这已经算体面。
TiDB Cloud 还在，我那个 2023 年建的库也还在，控制台打开，一切如常。只是从这个月起，每次登录，心里都会多一根弦：Active 这个状态的下面，永远压着一行小字——
安全无小事。
更正：本文初版误写「没有收到 Zeabur 的任何邮件说明，关停是登录网站才知道的」。关停邮件其实已于 10 月 17 日发出，是我漏看了；没有邮件通知的是 8 月底那次安全事件。相关段落已按此修正（2026 年 10 月 23 日）。
原文作者: liups.com
原文链接: http://liups.com/posts/fb578c63/
许可协议: 知识共享署名-非商业性使用 4.0 国际许可协议