Zeabur 資安事件白話拆解：你的 API 金鑰是怎麼被偷走的？中小企業老闆的 72 小時止血清單

八月二十七號晚上，一大票台灣工程師的手機同時響了。信件內容大同小異：你放在平台上的環境變數可能已經外洩，請立刻更換所有金鑰。有人正在吃飯，有人已經躺下了，有人是隔天早上打開 Anthropic 後台，才看到半夜多出一筆自己完全沒跑過的用量。

這幾天我們內部一直在追這件事，也回頭確認了自家系統的憑證狀態，之後才坐下來寫這篇。看過的中文報導多半在講「發生了什麼」，比較少人把「所以你現在該做什麼、為什麼要這樣做」講清楚，這篇補的就是後面那一段。

先講結論。這次事件的核心是環境變數外洩。環境變數你可以想成一張貼在系統後台的便條紙，上面寫著這個系統要用到的所有服務密碼：AI 服務的 API 金鑰、資料庫帳密、金流的私密金鑰、GitHub 權杖。攻擊者拿到的就是那張便條紙。便條紙本身不值錢，值錢的是紙上每一行後面連著的帳戶。

Zeabur 是台灣新創做的雲端部署平台，開發者把程式碼交給它，它幫你跑起來、配好網域。INSIDE 的報導指出，這次被證實外洩的變數涵蓋 OPENAI_API_KEY、ANTHROPIC_API_KEY、OPENROUTER_API_KEY、GEMINI_API_KEY、AWS 存取金鑰、GITHUB_TOKEN、CLOUDFLARE_API_TOKEN、STRIPE_SECRET_KEY 以及資料庫連線字串。創辦人林沅霖在事後也公開證實，已經實際看到 Anthropic、OpenAI、OpenRouter 的金鑰被盜用。

這次事件一句話看懂：一把鑰匙開了所有人的抽屜

最簡單的比喻是這樣：一棟大樓的總務室有一把主鑰匙，可以打開全棟每一間辦公室的抽屜。有人把那把主鑰匙拿走了，然後挨間去翻抽屜，把裡面的名片、印章、存摺影本拍照帶走。大樓沒有被拆，門也沒有壞，但每個房客的東西都被看過一遍。

Zeabur 這次的情況接近這個模型。攻擊者取得了一組內部服務憑證，用它去讀取平台資料庫裡存放的客戶環境變數。平台本身還在跑，你的網站沒有掛，但你寫在裡面的每一組密碼都可能已經被拷貝出去。

這也是這類事件最麻煩的地方：被害人自己很難察覺。網站被塗改你會看到，資料庫被刪你會發現，金鑰被複製走則什麼徵兆都沒有，直到帳單寄來。

下面這張表把整件事濃縮成一頁，看完這張表你已經拿到八成的資訊。

關於 612GB 那則，值得多說一句。動區的報導提到暗網賣家宣稱手上有完整資料庫、原始碼、AWS 管理金鑰、GCP 專案權限、Google Workspace 憑證與 Kubernetes 叢集管理權；官方回應是日誌分析顯示攻擊止步於針對性的環境變數匯出，現有證據無法佐證那份清單。兩邊說法目前沒有第三方稽核可以裁決。

處理這種資訊落差有一個很實用的原則：把「查無證據」和「沒有發生」分開看。前者是事證不足以劃出可信的上限，後者是確定沒事。以你自己的風險決策來說，該用前者的標準去做準備。

先講最痛的：金鑰被偷會燒掉多少錢

直接給數字。一個墨西哥的三人小團隊把 Gemini API 金鑰不小心流出去，48 小時後收到 8.2 萬美元的帳單，換算新台幣約 262 萬。T客邦整理的這個案例裡，他們原本一個月的正常支出大約 180 美元，兩天內的用量暴衝超過 450 倍。更難堪的是後續：Google 引用共享責任模式，認為保護金鑰是客戶的責任，運算成本已經實際支出，帳單得由客戶自己吸收。

為什麼 AI 金鑰特別容易變成提款機？因為它有三個特性同時成立：可以立刻換成算力、算力可以轉賣、而且大部分平台預設沒有硬性消費上限。攻擊者拿到金鑰之後不需要入侵你的系統，只要對著官方 API 一直打，用量就會累在你的帳上。實務上常見的做法是把偷來的金鑰餵進中介平台轉售存取權，買家在前台用，錢在你後台跑。

這也解釋了一件事：為什麼這次外洩清單裡，AI 金鑰是第一批被拿去用的。在所有外洩憑證裡，AI 金鑰的變現路徑最短。資料庫密碼要先找到入口、Stripe 金鑰要過風控、GitHub 權杖偷了原始碼還要找買家；AI 金鑰貼上去就能開始賺。

不同類型的金鑰被偷走之後，會發生的事情差很多，止血動作也不一樣。這張表建議直接存下來：

表格右邊那欄「多快會有感」是重點。會痛的其實是排在下面那幾種：完全無感的那幾類，等你發現時，資料早就在別人手上了好幾週。

這不是台灣獨有的問題。BleepingComputer 報導的一份研究裡，安全團隊把過去幾年在公開來源撈到的一萬多組外洩 AWS 憑證重新驗證，約 88% 到今天還能成功登入，其中數百組甚至帶著完整管理員權限。金鑰外洩之後沒有人去撤銷，是普遍現象。

攻擊鏈白話版：一把鑰匙怎麼一路開到你的抽屜

官方公布的攻擊鏈是五段：外洩的 AWS 管理憑證，進到東京的共用叢集，取得控制平面的 VPN 通道，摸到主資料庫，最後匯出客戶的環境變數。這段技術描述可以完整參考LonelySec 的事件分析，那篇把時間軸與可能的初始入口整理得很細。

換成大樓的說法會好懂很多：

真正值得學的是最後一列。LonelySec 那篇分析點出的架構問題是：同一個高權限身分，同時握有資料本身、以及打開資料的路徑。用大樓的講法，等於把保險箱和保險箱鑰匙放在同一個房間。任何一次憑證外洩，都會直接變成全量資料外洩，中間沒有第二道關卡替你爭取時間。

初始入口目前有幾種說法

那把 AWS 管理憑證怎麼流出去的，官方沒有給定論，安全社群整理出的可能性有幾條，每一條對你自己的系統都有對照意義：

• 供應鏈污染：2026 年 3 月 LiteLLM 曾有兩個含竊密程式的 PyPI 版本被上架，會蒐集環境變數、SSH 金鑰、雲端憑證與 Kubernetes 權杖。如果你的系統也裝過那幾個版本，往回追的時間點要拉到 3 月。

• 元件漏洞：LiteLLM Proxy 的一個 SQL 注入漏洞（CVE-2026-42208）允許未登入的攻擊者讀取甚至修改 Proxy 資料庫，連同它管理的憑證。

• 開發者電腦失陷：暗網貼文宣稱同時握有瀏覽器工作階段、SaaS 憑證與雲端金鑰，這個組合比較像是某台開發機中了竊密木馬，或密碼管理器被翻走。

• CI/CD 或秘密儲存層外洩：建置流程或秘密管理服務被入侵，一次就會拿到所有東西。

這四條的共同點是：入口全都落在日常開發流程裡。裝套件、跑 CI、開發者的筆電，這些地方平常沒人當成資安邊界在守，卻是最容易被走進來的門。

環境變數不等於保險箱：這個做法的天花板在哪

環境變數當初要解決的問題是「不要把密碼寫死在程式碼裡」，保密從來就沒被列進它的設計目標。這在十年前是一個很大的進步：OpenAI 官方的金鑰安全建議至今仍然把「用環境變數，不要 commit 進原始碼」列為基本功。這個建議沒有錯，只是它的天花板比多數人以為的低。

環境變數有三個結構性限制：

業界標準的下一步是秘密管理服務（AWS Secrets Manager、HashiCorp Vault、Google Secret Manager 這類），它們補的正是上面三件事：加密儲存、每一次讀取留下紀錄、可以設定自動輪替與到期。對中小企業來說這聽起來很重，但實務上有一個更輕的中間版本：先做到「一個服務一把金鑰、每把金鑰都有用量上限」，就已經能把單點外洩的損失壓在可承受的範圍。

這一段跟我們之前寫過的AI 對話為什麼不能貼金鑰是同一個底層問題：金鑰只要離開你能控制的範圍，它就處於「隨時可能被複製」的狀態，差別只在複製的人什麼時候動手。

我們的判斷是，接下來兩到三年，把金鑰放進部署平台的環境變數這個做法會慢慢被視為過渡方案，就像十年前大家從「密碼寫在程式碼裡」搬到環境變數一樣。中小企業不必急著上 Vault，但可以先從「盤點你現在總共有幾把金鑰、每一把分別給誰用」開始。多數公司光是把這張表拉出來，就會發現有三分之一的金鑰已經沒人在用，卻還活著。

72 小時止血清單：照著順序做就好

先給順序，再解釋為什麼。止血的黃金原則是先斷後補：先讓舊金鑰失效，再處理新金鑰要怎麼發。很多人反過來做，結果是新舊兩把同時活著，等於沒止血。

保留證據這件事比你想的重要

Zeabur 的賠償是以支援工單的資料逐案核實，創辦人表示最遲希望在 9 月 30 日前完成賠付，大額或特殊個案可能更久。這代表你手上的證據品質，會直接影響你拿得回多少。要留的東西包括：平台的通知信原文、金鑰名稱與建立時間、供應商後台的用量紀錄截圖、帳單異常的明細、以及你開工單的編號。電腦王阿達的整理也提到受影響使用者可以到官方技術支援頁面登記核實。

順帶提醒一個時間感的問題：AI 供應商的用量頁面通常只保留一段期間的細項。該截圖的東西今天就截，不要等賠償流程走到你才去翻。

新金鑰要帶著限制一起發

撤銷完舊的、要發新的時候，是唯一一次你可以順手把安全等級整個往上拉的機會，錯過就要等下一次事故。發新金鑰時建議一次做完這四件事：

• 設用量上限或預算上限：AI 服務多半可以在專案層級設月度硬上限，設了就算被盜用也有天花板。

• 設到期時間：能設就設，半年到一年。過期的金鑰是自動失效的資產，不需要有人記得去清。

• 限制來源 IP：如果你的系統跑在固定 IP 上，把金鑰綁住來源，外流之後在別的地方也用不了。

• 最小權限：只讀就不要給寫，只用某個模型就不要開整個帳號。權限給多少，外洩時就賠多少。

這四件事加起來大概花你四十分鐘，但它把「金鑰外洩」從一個可能燒掉兩百萬的事件，降級成一個要花一個下午處理的麻煩。

如果你的系統是外包做的、金鑰在廠商手上，這一段你自己做不了，直接跳到下一段。

老闆版：你不用會寫程式，但要會問這七個問題

這件事對找外包的老闆最直接的意義是：你公司的密碼，現在放在你看不到的地方。網站是外包做的、系統是接案團隊維護的、金鑰是工程師設進去的，出事的時候，第一個接到通知信的人不是你。

你不需要懂 Kubernetes，也不需要看得懂攻擊鏈。你只需要在下一次跟廠商開會時，把下面七個問題問出口，然後聽他怎麼答。答得出來的團隊，通常也真的有在管；答不出來的，這通電話本身就是最有價值的稽核。

第六題特別值得展開。離職權限回收是台灣中小企業最常見的破口，我們在酷澎個資外洩事件那篇整理過一份離職權限回收 SOP，可以直接拿去當附件寄給廠商。

還有一個問題適合問自己而不是問廠商：如果明天這家外包公司聯絡不上了，你拿得回自己的系統嗎？金鑰、網域、程式碼倉庫、資料庫備份，這四樣東西的最終擁有權應該在你的帳號底下，廠商是被授權的使用者。這件事寫在合約裡的成本是零，事後補的成本可能是整套系統重做。

談到備份，順帶一提：金鑰外洩最壞的下游情境是資料被撈走或被加密勒索，這時候能救你的是備份策略而不是資安工具。資料備份與災難復原完整指南那篇有完整的 3-2-1 法則與 RPO / RTO 設定方式。

事後補強：中小企業金鑰治理的最低配

這一段給的是「做完就可以先睡覺」的最低標準，不是資安顧問會給的完整框架。三件事，一個下午做得完。

第一件：把金鑰清單拉出來

開一份試算表，每一列一把金鑰，欄位放：服務名稱、金鑰用途、放在哪個平台、誰建立的、建立日期、有沒有設上限。這份表拉出來的當下，你通常會發現兩件事：有幾把金鑰早就沒人在用，還有幾把金鑰同時被三個專案共用。前者直接刪掉，後者是下次外洩時的放大器。

第二件：一個服務一把金鑰

共用金鑰最大的問題其實是出事的時候你不敢換。一把金鑰同時給五個系統用，你要換它就得同時協調五個系統，於是拖著不換。拆開之後每一把都可以獨立作廢，止血速度會差好幾個小時。

第三件：用量警示要寄到看得到的地方

每一個 AI 服務、每一個雲端帳號，都設一個「超過平常用量就寄信」的警示，收件人放公司實際會看信的人，不要只放工程師的個人信箱。前面那個 262 萬的案例裡，48 小時是有時間反應的，缺的只是有人看到。

如果你的團隊正在把 AI 接進日常流程，這三件事應該跟導入本身同步做，而不是等出事再補。我們在員工日常用 AI 不洩密完整 SOP裡整理過人的那一面（哪些內容不能貼進對話框），這篇補的是系統的那一面。

那還要不要用 Zeabur？

這個問題我們必須誠實回答，因為站上原本就有一篇Zeabur 的深度評測，也有一篇五大 PaaS 平台比較。我們的看法是，出過事的平台跟沒出過事的平台，差別往往只在有沒有被發現。真正該換的判斷依據是事後處理：有沒有公開攻擊鏈、有沒有逐一通知、有沒有給賠償時程。這三件事 Zeabur 都做了，這在台灣的新創圈其實不常見。

比較務實的做法是調整你的用法而非全盤搬家：把最敏感的憑證（金流、資料庫主帳號、AWS 管理權限）從部署平台的環境變數移出去，改用秘密管理服務或至少獨立帳號；留在平台上的金鑰全部設上限與到期。搬家本身也有成本與風險，換一個平台再出一次事，你會回到同一個位置。

如果你現在不確定自己有沒有中

最難受的狀態往往是這個：你知道公司有東西跑在雲端，但不確定金鑰放在哪、也不確定誰在管。這種情況下第一步是先把現況畫出來，資安工具的事情可以往後放。

看到這裡，如果你也在想「我們公司到底有幾把金鑰、放在誰手上」，我們很樂意聽你聊聊現在的實際情況，一起把系統跟金鑰的分布盤一遍，看看哪幾塊要先動。如果你的系統本來就是我們這類客製化開發的範圍，客製化系統開發在交付時就會把金鑰治理與權限邊界一起規劃進去。

這篇提到的三張表（金鑰盤點表、72 小時止血檢核、外包廠商七問）已經整理成一份可以直接填的檔案。開下來當天就能填完第一輪，多數公司填到一半就會發現有幾把金鑰早就沒人在用了。