Zeabur 近期公開的資安事件，最值得企業警惕的不是「某家雲端服務出事了」，而是現代部署平台的環境變數（Environment Variables）中，往往集中放置了整間公司的命脈——從 OpenAI、Claude 等 AI 服務的 API Key、雲端存取權杖、資料庫連線字串（Connection String），到各式應用程式密鑰。

一旦平台內部的存取路徑被突破，攻擊者根本不需要大費周章去駭個別客戶的系統，就能直接把這些立即可用的憑證打包帶走。

依據 Zeabur 官方事件調查報告（亦可參閱 Zeabur Status 即時事件中心 的完整紀錄），攻擊路徑是駭客先取得內部外洩的 AWS 管理憑證，進入東京區共享叢集，再透過控制平面 VPN 連進主要資料庫。官方證實攻擊者確實針對使用者環境變數進行了查詢與匯出，且行為模式明顯鎖定 AI 服務 API 金鑰等高價值憑證。

如果你的團隊也重度依賴雲端部署、串接 AI API 或使用代管資料庫，請別只是被動等待通知。現在最該做的是把這次事件當成一次實戰演練，立刻照著以下 5 個步驟把破口補起來。

1. 全面盤點：別漏掉測試區與已下線的舊專案

很多人盤點機密時，往往只查目前線上有在跑的正式專案。但攻擊者撈資料是不分新舊的，那些被遺忘在平台上的測試環境、Git 分支、Demo 站或已關閉的專案，裡面放的憑證很可能也是同一組！

• 重點盤點標籤：優先標記 OpenAI、Anthropic、OpenRouter、GitHub、AWS、Cloudflare、Stripe 等第三方 API 憑證，以及資料庫密碼、JWT Secret、SSH 金鑰與 Webhook Token。
• 逐一列出清單：記錄名稱、實際用途、建立時間、最後使用時間、負責人，以及這組金鑰目前是否還在運作。

小細節千萬別忽略：Zeabur 官方特別說明，即使你曾改過環境變數名稱（例如把 OPENAI_API_KEY 改叫 MY_AI_KEY），只要字串的值符合特定服務的 Token 格式，攻擊者一樣辨識得出來。企業在做內部秘密掃描時，工具必須能檢查「值的特徵」與歷史版本，光搜尋欄位名稱是遠遠不夠的。

2. 正確換金鑰：「先撤銷舊的，再換上新的」

很多人以為去後台點一下「產生新金鑰」就沒事了，但如果沒有手動撤銷（Revoke）舊金鑰，舊的依然可以使用，攻擊者手上的權限根本沒有斷掉。

• 依照風險排序處理：先撤銷會直接扣款、產生帳單費用（如 AI 模型調用）或能異動雲端資源的金鑰；接著處理資料庫密碼、雲端管理身分與程式碼平台權杖。
• 設定過渡期停用時間：如果線上服務需要無縫接軌，可以採用短暫的雙金鑰機制，但一定要明確設定舊金鑰的最晚刪除時間。千萬別抱著「先留著以防萬一」的心態，最後讓過期憑證永久暴露在外面。

在強化應用程式防護時，除了保護後端憑證，前端流量的過濾也同樣重要。如果你正在評估整體的邊緣防護機制，可以參考邊緣保護不是把流量搬上 CDN：企業網站上線前先補的 5 個 WAF 檢查，確保從邊緣到原站都不留後門。

3. 調閱用量與帳單：查出過去有沒有被盜用

金鑰輪替只能阻止「未來」的存取，但沒辦法告訴你「過去」到底有沒有被偷用過。

• 比對異常活動：登入各服務商後台，調出近期的 API 調用次數、Token 消耗量、雲端操作紀錄與資料庫連線日誌。
• 鎖定 AI API 異常特徵：特別留意有沒有在半夜離峰時段突然爆量、呼叫來源 IP 異常，或是突然切換到高單價模型（例如原本用輕量模型，卻突然出現大量頂級模型的調用紀錄）。
• 設定硬性防線：開啟每日用量上限（Usage Limit）、速率限制（Rate Limit）與即時花費告警。同時請下載並留存這段期間的用量報表與時間戳記，一旦發現被盜刷，這些都是向服務商通報爭議與爭取補償的關鍵證據。

面對網路層層疊疊的威脅，想要更全面防堵外部利用外洩憑證發動攻擊，導入具備 AI 即時預判與分析能力的 Cloudbric AI WAF 解決方案，能有效攔截可疑的 API 惡意調用與異常行為。

4. 收攏邊界：資料庫不要裸奔，管理入口切離公網

憑證一旦外洩，後果有多嚴重，完全取決於拿著憑證能連到哪裡。

• 資料庫嚴格鎖 IP：資料庫連線千萬不能直接開在公網上。若必須對外，請務必綁定來源 IP 白名單、設定最小權限帳號，並將讀取與寫入權限分開。
• 全面檢視伺服器連線：如果有透過 Zeabur 管理伺服器，請立刻更換 SSH 金鑰或密碼。檢查 /root/.ssh/authorized_keys 是否被塞入陌生的 Public Key，並關閉密碼登入，改用金鑰認證。
• 傳輸通道加密防護：確保所有傳輸通道皆有嚴格加密，基礎架構應全面導入正規的 SSL 數位憑證安全連線，防範中間人竊聽並保護機密傳輸安全。

5. 實測收斂：用證據證明風險真的排除了

最後一步是做「反向驗證」，確認所有破口都已經封死：

• 刻意測試舊金鑰：故意拿已經撤銷的舊 Key 去呼叫 API 或連線資料庫，確認系統確實回傳 401 Unauthorized 或直接拒絕連線。
• 清理殘留設定：檢查本機的 .env 檔案、CI/CD 變數與團隊共用筆記，把舊的機密內容徹底刪除。
• 留存結案紀錄：將受影響的資產、處理人員、換鑰時間點、撤銷截圖與日誌比對結果整理成一份簡單的紀錄，讓團隊隨時掌握處置進度。

常見問題 FAQ