写在 Zeabur 即将关停之际：安全无小事，不要再明文存储 key

昨天看到 Zeabur 即将关闭服务的消息，令我十分唏嘘。当年我也是最早的一批用户，还跟创始人有过一些交流。我知道他们去年开始有一些战略转型，但没想到最终促使他们关停服务的原因竟然是接连不断的黑客攻击。如今真实猴子手里也有 AK47，开发者们得把安全两字放在心上。

后面我也会分享一些加密存储方面的实践，包括我已经在生产中使用的开源项目：Meathill HSM，希望对大家有帮助。

🔥 事件脉络：Zeabur 两度沦陷，走向关停

Zeabur 曾经是一颗冉冉升起的新星。它有好用的控制台、响应及时的客服，支持 Docker 和各种语言开箱即用，是 Vercel 与 Railway 的有力竞争者。我当年也跟他们合作过，不仅很早就开始使用他们的产品，还带动身边的不少开发者一起用。

然而，2026 年 10 月 17 日，Zeabur 创始人袁霖发布了一则沉痛的官方公告：平台将于 2026 年 12 月 1 日起停止专属服务器续费，并在 12 月 31 日正式彻底关停所有服务。

压垮这个优秀产品的，不是商业化不顺，也不是同行竞争，而是不到两个月内接连发生的两次安全事故：

第一轮沦陷（2026 年 8 月 27 日）

攻击者利用部署在 Zeabur 上的某位租户公开服务的未修复漏洞作为跳板，一路穿透了四层隔离边界：从用户容器环境逃逸至共享集群内网，进而攻陷平台内部管理凭据，跨越至 AWS 基础设施层，并最终直接获得了生产数据库的只读权限。

在这场入侵中，数据库内存储的账户信息以及各项目的环境变量被攻击者全部导出。这其中包含了海量用户配置的第三方 AI 服务密钥（如 OpenAI、Anthropic、Google Gemini API Key）、数据库密码及第三方集成凭证。

随后，社区陆续爆出大量用户的 API Key 出现突发的高频盗刷。尽管官方紧急下线了 AI Hub 功能并承诺全额兜底补偿受损用户，但这不仅带来了沉重的财务负担，更重创了平台的核心商誉。

第二轮致命打击（2026 年 10 月 14 日至 15 日）

就在团队全力修复漏洞、试图重建安全护城河的紧要关头，噩梦在十月中旬重演。

调查显示，托管在 Google Cloud 上的部分独立服务器再度遭到未授权访问，攻击者以令人心碎的相似路径再次读取了平台数据库。受影响的项目环境变量、API Token 以及邮件发送 Key 等凭据再度外泄。

接连两次防线崩溃，意味着平台在多租户环境隔离与凭据生命周期管理上存在难以短时间内根治的系统性隐患。用官方的话说就是：

Zeabur 的系统最初只是三年半前一个快速开发的项目
……也逐渐积累了越来越高的系统复杂度和维护成本……

面对不可承受的潜在赔偿账单、法律风险以及无法挽回的信任坍塌，关停平台成了团队唯一负责任但极其惨烈的结局。

⚠️ 明文存储 API Key，看起来简单，后患无穷

对于一家提供 Docker Host 和全栈托管的平台来说，一旦环境变量与数据库被脱裤，平台要赔偿的可能远远超出自己的总营收。

因为被偷走的不是无意义的字符串，而是可以直接在外部计费平台上无限制透支几十万甚至数百万美元的真金白银。

但我们如果把目光从平台级 PaaS 收回到普通的独立开发项目，情况难道就会好很多吗？

恰恰相反。

当下各类 AI 驱动的出海热潮中，各种全栈模板以及各路开源 Boilerplate 极其流行。很多独立开发者几小时就能拼出一个 AI 对话、智能翻译或图像生成工具。

这些产品都会提供一个常见配置，让用户输入自己的 OpenAI、Claude 或 DeepSeek 密钥，接入自己的 AI 供应商。

那么，这些项目通常是怎么存储这些核心密钥的？

随便翻看几个开源项目和商业模板的实现，核心逻辑几乎无一例外是明文存储。

这些宝贵的密钥，被堂而皇之地以纯明文形式存放在 PostgreSQL、Supabase、MySQL 或者 SQLite / D1 的数据表里。

很多开发者会觉得：“我只是个小项目，没人会来黑我。”

但黑客扫描漏洞从来不挑对象。一旦项目出现常见的配置疏漏（比如前阵子 Next.js 提权漏洞），黑客只要拿到只读权限，整张表里的用户 Key 就会在几秒内全军覆没。

随之而来的可怕景象不需要我赘述。

🛑 简单加密好一些，但不足以长期依赖

有些开发者意识到明文不妥，会在服务端简单加密后再存进数据库。但这从系统安全的角度来看，只是一座现代版的马奇诺防线。因为钥匙和锁被放在了同一扇门后。

回顾 Zeabur 的遭遇：攻击者通过漏洞攻入环境，读取了环境变量，又读取了数据库。如果你的应用遭遇类似渗透，攻击者拿到了代码环境和环境变量，就拿到了 APP_SECRET_KEY；再拿到数据库里的密文，解密只是一行脚本的事情。

单点防御在横向渗透面前是不堪一击的。一旦应用节点或者数据库单点被突破，所有的本地对称加密瞬间化为乌有。

🛡️ 零信任救赎：两把钥匙永远不放在同一处

真正的安全设计原则只有一条：零信任（Zero-Trust）。

也就是说：即便数据库被黑客全量 Dump，即使应用服务器被攻陷，攻击者从数学上也无法逆向还原出任何密钥。

核心逻辑非常简单：让任何单一角色无法凑齐完整的解密钥匙。

在 Mizu 时，我们也面临同样的问题：客户有很多机密信息要存在我们的服务器上，一旦被脱库，后果不堪设想。于是我设计并实现了轻量级开源项目 Meathill HSM（运行在 Cloudflare Workers + KV 上，提供在线服务 https://hsm.meathill.com）。

它的本质是 KSM（Key Store Management），不过名字不重要。因为现在它不需要昂贵的物理硬件，随手就可以部署一个只属于你自己的实例。它的核心密码学逻辑就一句话：密钥分片（Key Splitting）+ 信封加密。

1. 钥匙拆成两半：

   • Part A（服务端分片）：保存在 HSM 服务的环境变量中；

   • Part B（客户端分片）：由调用方或用户自己持有，在请求时通过 X-HSM-Secret Header 传入。

2. 服务端永不保存 Part B：加解密只在内存瞬间完成；

3. 两边缺一不可：

   • 就算黑客攻陷了数据库，把 KV 里的数据全部拖走，因为没有调用方的 Part B，拿到的只是毫无意义的密文；

   • 就算黑客拿到了客户端的 Part B，没有服务端的 Part A，同样无法解密。

此外，存储时数据的路径（Path）会经过 HMAC 哈希混淆，并作为 AES-GCM 的附加认证数据（AAD）绑定在密文中。黑客哪怕拿到数据库，不仅解不开内容，连哪个 Key 属于哪个用户、存了什么服务都看不出来。

🚀 极简接入 HSM：给你的项目加一把锁

接入这套零信任方案不需要大改架构，调用方式就像存取普通键值对一样直接：

// 存储用户的 API Key：明文直接送给 HSM 加密落地，业务库只存业务 ID
await fetch(`${HSM_BASE_URL}/keys/apps/mysaas/users/${userId}/openai`, {
  method: 'PUT',
  headers: {
    'Content-Type': 'application/json',
    'X-HSM-Secret': userOrClientSecret, // 只有调用方持有的钥匙分片
  },
  body: JSON.stringify({ value: rawApiKey }),
});

// 需要发起调用时：临时取出解密，内存中用完即弃
const res = await fetch(`${HSM_BASE_URL}/keys/apps/mysaas/users/${userId}/openai`, {
  method: 'GET',
  headers: { 'X-HSM-Secret': userOrClientSecret },
});
const { data } = await res.json();
const apiKey = data.value;

因为原生支持 CORS，如果是纯前端工具或浏览器插件，前端甚至可以直接跟 HSM 通信，用户的 API Key 压根不需要流经你的业务后端，彻底消除中间人泄露的可能。

部署在 Cloudflare Workers 上，每天有免费的 10 万次请求额度，对绝大多数独立项目来说，成本几乎始终是 $0。

不放心的话，你可以让 AI 帮你审计我的代码，确认没问题后，随手部署一套自己的服务。不需要跟我有任何交流。

💡 总结

Zeabur 的关停令人痛惜。一个做了三年半、体验极佳的云产品，被接连两次安全击穿和随之而来的赔偿压力逼到不得不关停的地步。

这给所有现代全栈开发者和独立创业者敲响了警钟：

不要再对明文存储抱有侥幸心理，也不要把全部希望寄托在“我的运维不会出错”上。利用零信任和密钥分片，把数据和钥匙隔离开来，即便有一天数据库不幸被脱裤，也能在数学上守住最底层的防线。

希望大家的产品都不会被黑。