Security / DevOps
環境變數不是 Secret Manager：Zeabur 外洩事件後的 Secrets 架構
環境變數不是絕對禁止，但它缺少加密、版本、輪替、稽核與細粒度授權，並可能暴露於子行程、除錯資訊、容器設定、日誌或 dump。較穩健的做法是以 Secret Manager/Vault 作為 source of truth，透過 workload identity/IAM 取得短期或最小權限祕密，再於 runtime 以記憶體、檔案掛載或最後手段的 env 注入。
2026年8月29日3 分鐘閱讀👁 10
2026-08-30 更新：Zeabur 環境變數遭未授權存取
Zeabur 的官方事件頁確認有人未經授權使用內部服務憑證，讀取部分專案的環境變數紀錄；官方已撤銷該憑證、封鎖存取路徑並通知可能受影響使用者。事件資訊列出的可能曝險項目橫跨 OpenAI、Anthropic、OpenRouter、Gemini、AWS、GitHub、Cloudflare、Stripe、資料庫連線與 JWT secret。
這次事件正好驗證本文的核心：**環境變數可以是 runtime 注入介面，但不是獨立安全邊界。**如果部署平台控制面或高權限內部憑證可跨專案讀取 variables，把 Key 從程式碼移到 PaaS ENV 仍會形成集中爆炸半徑。
受影響使用者的正確處置順序：
- 到每個憑證的原始發行平台撤銷舊 Key，不只是修改 Zeabur Variables。
- 檢查事件前後的 usage、帳單、API request、來源 IP、雲端 audit log 與 GitHub security log。
- 對資料庫密碼與 JWT secret 評估終止既有連線、強制登出及重新簽發。
- 為不同服務、環境與用途建立獨立、最小權限、有額度上限的憑證。
- 能用 workload identity／IAM 短期憑證就不要部署長效 master secret；無法使用時則自動輪替、限制來源 IP 並監控異常。
官方資訊尚不足以判定完整根因、受影響專案數或 LiteLLM 是否為入侵起點；「暗網 612GB 完整資料庫」等說法也不能在缺乏證據時當成已證實事實。
延伸來源：Zeabur 官方事件頁／原始 Threads 架構建議
Security / Secrets Management
環境變數可以傳遞 secret，但不等於管理 secret
Threads 的核心方向正確，但要補一個重要細節：env vars 可以是 runtime injection mechanism；問題是把它當成 source of truth。真正的 Secret Manager 應提供加密、版本、輪替、最小權限、稽核、撤銷與工作負載身分整合。
為什麼普通 env vars 不夠
| 缺口 | 風險 |
|---|---|
| 缺乏集中生命週期 | 沒有內建版本、輪替、過期、撤銷及 owner 資訊。 |
| 可見範圍過大 | 環境變數可能被同一程序的子行程、除錯工具、錯誤報告、system dump、容器 inspect 或日誌意外讀到。 |
| 靜態 credential | 長期 API key 外洩後可被重複使用；workload identity 或短期動態憑證能縮小風險。 |
| 沒有細粒度授權 | 單一 .env 常把多服務祕密打包；服務 A 不應因此看見服務 B 的 key。 |
| 容易進入 artifact | 若寫進 Dockerfile ENV/ARG、Compose、CI YAML、shell history 或 Git，可能永久留在映像層與歷史。 |