# 當用戶信任你，你信任平台，平台信任雲端——Zeabur 事件與那條沒人看見的鏈 > 8 月底，台灣的雲端部署平台 Zeabur 遭入侵，使用者存放的環境變數被匯出，外洩清單裡包含資料庫連線字串。如果你的組織把網站、表單或個案系統託管在類似的平台上，這篇是寫給你的：不是要你恐慌，是要你看清楚那條鏈長什麼樣、你在哪一節，以及萬一哪天輪到你，該怎麼把傷害降到最低。 *資安事件簿 · 更新於 2026.09.09 · 約 9 分鐘閱讀* --- ![](https://ethome.cc/wp-content/uploads/2026/09/9d13bba7-7788-4f35-8557-23620f30dc52_1200x600-1024x512.jpg) - 這次外洩的不是平台的密碼，是使用者存放在裡面、通往別處的各種憑證。 - 外洩清單中包含資料庫連線字串——對持有敏感個案資料的組織，這是最高等級的警訊。 - 你的服務對象從來沒聽過這個平台，但風險已經傳到他身上了。 - 事故公告的品質，直接決定當事人能不能及時保護自己。 - 文末有三個今天就能回答的問題，以及一份事故公告的骨架。 先講結論，因為這篇會有點長：**你不可能保證你用的每一個服務都不會被駭。**但你可以決定兩件事——它被駭的時候，掉出來的鑰匙能開幾扇門；以及你的服務對象，多久之後會知道。 8 月底發生的 Zeabur 事件，剛好把這兩件事都示範了一次。 ## 發生了什麼 Zeabur 是台灣團隊做的雲端部署平台，讓人可以把網站或應用程式一鍵架上線，不用自己管伺服器。8 月 27 日，它的監測系統偵測到一組內部服務憑證被未授權使用。 依官方後續公布的說明，攻擊者的起點是一組外洩的 AWS 高權限管理憑證。他們用它進入 Zeabur 位於 AWS 東京機房、當時正在逐步停用的一個邊緣服務叢集，再從叢集內部取得系統控制平面的 VPN 存取權，一路連上主資料庫。進到資料庫之後，攻擊者對使用者的環境變數執行了目標明確的查詢與匯出。 已確認外洩的憑證種類很廣：OpenAI、Anthropic、OpenRouter、Gemini 等 AI 服務的 API 金鑰，GitHub、AWS、Cloudflare、Stripe 的權杖，以及**資料庫連線字串、密碼、JWT Secret**。已有使用者回報 AI 服務出現不明扣款——被偷走的金鑰，正在被拿去花受害者的錢。 **什麼是「環境變數」？**寫程式時不能把密碼、金鑰直接寫死在程式碼裡（那樣一上傳到 GitHub 就等於公開了），所以會把這些秘密另外存在一個地方，程式執行時再讀進來。那個地方就是環境變數。換句話說，它是**設計上專門用來放秘密的位置**——這也是為什麼攻擊者進到資料庫之後，直奔那裡。 ## 那條沒人看見的鏈 現在把鏡頭拉遠一點。 一位當事人走進你的服務據點，填了一張表單。她信任的是你，是接待她的社工，是這個組織二十年的名聲。她信任的範圍就到這裡為止。 而那張表單的資料，可能存在你們的網站後台；那個網站，可能架在某個一鍵部署平台上；那個平台，可能把一部分服務放在某家國際雲端商的機房；而那家雲端商的一組管理憑證，某天外流了。 **當事人 → 你的組織 → 託管平台 → 雲端服務商。**信任是一層一層轉包出去的，但責任不是。當事人不認識這條鏈上的任何一環，她只認得你。真的出事的時候，她會來問你，而不是去問 AWS。 這就是為什麼這次外洩清單裡的「資料庫連線字串」特別值得停下來看。API 金鑰被偷，損失是帳單；**資料庫連線字串被偷，損失是資料本身**。而 Zeabur 在官方 Q&A 裡寫得很直接：如果使用者在環境變數裡填了可以直接使用的資料庫憑證，而那個資料庫又能從公開網路直接連上，攻擊者有可能用腳本工具嘗試存取。 對一間電商來說，這是訂單和客戶名單。對服務家庭暴力、性別暴力、跨性別者、移工、無戶籍者的組織來說，資料庫裡是庇護所的位置、是當事人的現居地址、是還沒對家人出櫃的人的本名與身分證字號。 那已經不是資安問題了。 如果你的組織持有**庇護處所位置、當事人住居所、未公開的身分或就醫資訊**，那麼「我們的資料庫可以從公開網路直接連上」這件事本身就需要處理，**不必等到有人外洩**。這不是為了因應這次事件，是因為那個狀態在任何一天都是可被利用的。 ## 三個你今天就能回答的問題 我不打算給你一份四十項的稽核表，那種東西通常會被存起來然後再也不打開。先回答三個問題就好。如果答不出來，那個「答不出來」本身就是這次的發現。 **問題一：我們的個案資料，實際存在哪裡？** 不是「在系統裡」，也不是「在雲端」。是：哪一家公司的服務、哪一個機房、由誰負責維護。如果你們用的是外包廠商做的系統，這個問題要問廠商，而且要書面回覆。 **問題二：那個資料庫，能不能從公開網路直接連上？** 正確的狀態是「不行，只能從特定的內部網路或經過 VPN 才連得到」。如果答案是「可以，用帳號密碼就能連」，那麼那組帳號密碼一旦外洩，資料就跟著出去了。這是這次事件最直接的教訓。 **問題三：現在有誰的手上，握著能連到它的憑證？** 包含：離職的同仁、結案的外包廠商、實習生、以及當年幫忙架站那位「認識的工程師朋友」。憑證不會因為人離開而自動失效，它會一直有效到有人主動去撤銷為止。 - 我們能具體說出個案資料存放在哪一家服務、哪個地區的機房 - 資料庫不能從公開網路直接連線（或我們已經知道它可以，並排定了處理時程） - 我們有一份清單，記錄誰持有哪些系統的存取權 - 離職與結案時的權限撤銷，是流程的一部分，不是靠某個人記得 - 我們知道萬一出事，誰負責對外說明、誰負責通知當事人 ## 如果哪天輪到你：一份事故公告的骨架 Zeabur 這次的處理有值得學的地方，這點應該講清楚：8 月 27 日偵測到異常，8 月 28 日就發出第一則公告並列出已確認外洩的變數名稱、逐一通知可能受影響的使用者；8 月 29 日發現旗下另一項服務有可疑活動就主動暫停；8 月 30 日修正了先前對攻擊路徑的描述，並公布賠償進度。 最值得學的是一句話。官方在說明資料存取範圍時寫道：目前的紀錄沒有發現大規模讀取其他資料的直接證據，**但沒有直接證據，不等於能完全排除其他資料曾被存取**。 這句話很難寫。它讓公告看起來沒那麼漂亮，但它讓使用者能做出正確的判斷。這正是事故公告存在的目的。 如果哪天輪到你的組織，這是一份可以直接拿來填的骨架： - **什麼時候發現的，什麼時候公告的。**兩個時間都寫出來。不要等調查完才說——調查往往要幾週，而當事人需要的是現在就開始防範。 - **已經確認外洩了什麼。**具體到欄位：是姓名和電話，還是包含地址？分開講，不要用「部分個人資料」帶過。 - **還不確定的部分，明講不確定。**「我們目前沒有證據顯示 X 被存取，但我們無法排除這個可能」——這句話寫出來，比事後被發現含糊要好太多。 - **當事人現在該做什麼。**具體動作，不是「請提高警覺」。是「如果你曾經在本會登記過住址，請留意近期是否有陌生訪客或郵件」「如果你使用過本系統的登入功能，請更換密碼」。 - **我們正在做什麼，下次更新是什麼時候。**給一個具體的時間點。沉默會被解讀成隱瞞。 - **預告會有假冒本組織的詐騙。**並且說明你們絕對不會做的事（例如：本會不會用電話或訊息要求您提供密碼、匯款或身分證影本）。 台灣的組織出事時，最常見的第一反應是「先不要講，免得造成恐慌」。但如果你的服務對象是高風險族群，**「先不要講」不是保護，是讓他們在不知情的狀況下繼續暴露**。一個正在躲避跟蹤的人，有權利知道她的地址可能已經不在你們手上了——即使那個消息很難聽。 ## 第二波：外洩之後的詐騙 Zeabur 在 8 月 30 日的更新裡，特別警告已經有人利用這起事件的資訊行騙。 這幾乎是每一起資安事件的固定續集，原因很簡單：受害者名單本身就是最精準的詐騙名單。這些人正在焦慮、正在等一封官方通知信、而且已經預期自己會被要求「處理一些事情」。此時一封看起來像官方的信，成功率高得驚人。 對組織來說，這代表你的事故公告有第二個任務：**預先告訴當事人，什麼樣的聯繫一定不是你們**。對個人來說，判斷原則是這幾條—— 真正的官方通知不會要你點信裡的連結去登入、不會要你提供密碼或金鑰、不會有「限時補償方案」要你先付一筆錢、也不會急。要處理任何事情，關掉那封信，自己從書籤或搜尋進官網。 ## 最後 這篇不是要說 Zeabur 有多糟，也不是要你換掉手上的服務。任何一家廠商都可能有一組憑證流出去，包括你自己的組織。 能做的事是把那條鏈看清楚，然後在自己這一節做兩件事：讓資料庫不要暴露在公開網路上，以及先想好萬一出事，那封信要怎麼寫。就算只做第一件，都已經比什麼都不做好很多。 如果你的組織想盤點一次目前的託管與權限狀況，或是想在事情還沒發生時先擬好事故應變與通知流程，歡迎[與我聯繫](#)。若你是個人——不管是擔心自己的資料在某個組織手上，或是正在處理跟蹤、騷擾相關的數位安全問題——一對一諮詢同樣可以，不需要透過任何機構。 ### 資料來源 - INSIDE，[〈Zeabur 環境變數外洩！Anthropic、OpenAI、OpenRouter API 憑證遭盜用，官方公布輪替指南〉](https://www.inside.com.tw/article/42241-zeabur-environment-variable-leak-api-keys-stolen) - 數位時代，[〈Zeabur 遭駭懶人包：一組外洩 AWS 憑證，如何偷走用戶 AI 金鑰？受災戶 6 大 QA 一次看〉](https://www.bnext.com.tw/article/92061/zeabur-env-var-leak-api-key-stolen) - TechNews 資安人，[〈雲端部署平台 Zeabur 遭駭，使用者 API 金鑰、資料庫憑證外流〉](https://infosecu.technews.tw/2026/08/31/zeabur-security-incident)，2026 年 8 月 31 日 - 鏈新聞 ABMedia，[〈台灣雲平台 Zeabur 遭駭，用戶 API 金鑰外洩、AI 帳單被盜刷〉](https://abmedia.io/zeabur-security-incident-api-key-leak-taiwan) - Darrell TW，[〈Zeabur 資安事件：環境變數外洩後，怎麼確認災情與輪替密碼〉](https://www.darrelltw.com/zeabur-security-incident-env-leak/) --- 來源：[當用戶信任你，你信任平台，平台信任雲端——Zeabur 事件與那條沒人看見的鏈](https://ethome.cc/zeabur-leak-npo-supply-chain/) ethome.cc — 生活化的資安科普