写在 Zeabur 即将关停之际：安全无小事，不要再明文存储 key
内容提要
Zeabur 因两个月内两次遭黑客攻击，数据库被窃取，大量用户 API Key 明文泄露并遭盗刷，最终宣布关停。作者借此指出，独立开发项目普遍将 OpenAI 等密钥明文存于数据库，简单加密也因密钥与数据同处一地而失效。他提出零信任方案：用 Meathill HSM 将密钥分片，服务端与调用方各持一半，缺一不可，即使数据库被脱库也无法解密，且可免费部署于 Cloudflare Workers。
延伸解读
平台级事故的连锁代价
Zeabur 两次被攻破后，泄露的不只是账户信息，还有大量用户配置的 OpenAI、Anthropic、Gemini 等第三方密钥。这些密钥能在外部计费平台被直接盗刷，赔偿金额可能远超平台营收。这说明托管平台一旦失守，损失会沿着用户链条放大，安全投入不能只按自身业务规模衡量。
同库加密为何挡不住脱库
文章指出，把密钥简单加密后存进数据库，等于把锁和钥匙放在同一扇门后。攻击者若同时拿到环境变量中的 APP_SECRET_KEY 和数据库密文，解密只需一行脚本。Zeabur 的攻击路径正是先进入环境、再读取数据库，因此本地对称加密在横向渗透面前很难提供实质保护。
密钥分片的实际边界
Meathill HSM 把密钥拆成服务端分片和调用方分片，缺一不可，并对存储路径做 HMAC 混淆、绑定为 AES-GCM 的 AAD。即便如此，方案仍依赖调用方妥善保管自己的分片；文章强调的是数据库被全量拖走时无法还原明文，而非所有攻击场景都绝对安全。
低成本接入的适用场景
该方案运行在 Cloudflare Workers + KV 上，每天有 10 万次免费请求额度，对多数独立项目成本接近零。原生支持 CORS，纯前端工具可让密钥不经过业务后端。但文章也建议自行审计代码后再部署自有实例，说明便利性之外仍需承担部署与验证责任。
Q&A
Zeabur 为什么最终宣布关停服务？
Zeabur 在不到两个月内接连遭遇两次黑客攻击，导致生产数据库被读取，大量用户的 API Key、数据库密码等凭据泄露并遭盗刷。平台面临沉重的赔偿负担、法律风险和信任坍塌，最终决定关停。
独立开发项目通常怎么存储用户的 OpenAI API Key？有什么风险？
很多开源模板和商业项目将用户的 OpenAI、Claude 等 API Key 以明文形式直接存放在 PostgreSQL、Supabase、MySQL 或 SQLite/D1 等数据库中。一旦项目出现配置漏洞被黑客拿到只读权限，整张表的密钥就会在几秒内全部泄露，可能被用于盗刷产生高额费用。
为什么在服务端简单加密后再存数据库还不够安全？
因为加密密钥（如 APP_SECRET_KEY）通常和密文放在同一环境或同一系统中。攻击者一旦通过漏洞攻入应用环境，就能同时拿到环境变量中的密钥和数据库中的密文，解密只需一行脚本，简单加密形同虚设。
Meathill HSM 是如何做到即使数据库被拖走也无法解密密钥的？
Meathill HSM 采用密钥分片和信封加密：服务端分片（Part A）保存在 HSM 环境变量中，客户端分片（Part B）由调用方持有并通过请求头传入，服务端永不保存 Part B。加解密只在内存中瞬间完成，缺少任一分片都无法还原密钥。此外，存储路径经 HMAC 混淆并作为 AES-GCM 的附加认证数据绑定，攻击者即使拿到数据库也看不出密钥归属和内容。
接入 Meathill HSM 复杂吗？需要多少成本？
接入很简单，调用方式类似普通键值对存取，通过 PUT/GET 请求并携带 X-HSM-Secret 请求头即可。它原生支持 CORS，纯前端工具可直接与 HSM 通信，API Key 无需经过业务后端。部署在 Cloudflare Workers 上每天有 10 万次免费请求额度，对多数独立项目成本几乎为 0。
对于独立开发者，存储用户 API Key 应该遵循什么安全原则？
应遵循零信任原则，不要把数据和钥匙放在同一处。避免明文存储，也不要依赖与数据同处一地的简单加密。使用密钥分片方案，让服务端和调用方各持一半密钥，确保即使数据库被全量拖走或应用服务器被攻陷，攻击者也无法在数学上还原出任何密钥。
