• 這次外洩的不是平台的密碼，是使用者存放在裡面、通往別處的各種憑證。
  • 外洩清單中包含資料庫連線字串——對持有敏感個案資料的組織，這是最高等級的警訊。
  • 你的服務對象從來沒聽過這個平台，但風險已經傳到他身上了。
  • 事故公告的品質，直接決定當事人能不能及時保護自己。
  • 文末有三個今天就能回答的問題，以及一份事故公告的骨架。

先講結論，因為這篇會有點長：你不可能保證你用的每一個服務都不會被駭。但你可以決定兩件事——它被駭的時候，掉出來的鑰匙能開幾扇門；以及你的服務對象，多久之後會知道。

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 日修正了先前對攻擊路徑的描述，並公布賠償進度。

最值得學的是一句話。官方在說明資料存取範圍時寫道：目前的紀錄沒有發現大規模讀取其他資料的直接證據，但沒有直接證據，不等於能完全排除其他資料曾被存取。

這句話很難寫。它讓公告看起來沒那麼漂亮，但它讓使用者能做出正確的判斷。這正是事故公告存在的目的。

如果哪天輪到你的組織，這是一份可以直接拿來填的骨架：

  1. 什麼時候發現的，什麼時候公告的。兩個時間都寫出來。不要等調查完才說——調查往往要幾週，而當事人需要的是現在就開始防範。
  2. 已經確認外洩了什麼。具體到欄位：是姓名和電話，還是包含地址？分開講，不要用「部分個人資料」帶過。
  3. 還不確定的部分，明講不確定。「我們目前沒有證據顯示 X 被存取，但我們無法排除這個可能」——這句話寫出來，比事後被發現含糊要好太多。
  4. 當事人現在該做什麼。具體動作，不是「請提高警覺」。是「如果你曾經在本會登記過住址，請留意近期是否有陌生訪客或郵件」「如果你使用過本系統的登入功能，請更換密碼」。
  5. 我們正在做什麼，下次更新是什麼時候。給一個具體的時間點。沉默會被解讀成隱瞞。
  6. 預告會有假冒本組織的詐騙。並且說明你們絕對不會做的事（例如：本會不會用電話或訊息要求您提供密碼、匯款或身分證影本）。

台灣的組織出事時，最常見的第一反應是「先不要講，免得造成恐慌」。但如果你的服務對象是高風險族群，「先不要講」不是保護，是讓他們在不知情的狀況下繼續暴露。一個正在躲避跟蹤的人，有權利知道她的地址可能已經不在你們手上了——即使那個消息很難聽。

第二波：外洩之後的詐騙

Zeabur 在 8 月 30 日的更新裡，特別警告已經有人利用這起事件的資訊行騙。

這幾乎是每一起資安事件的固定續集，原因很簡單：受害者名單本身就是最精準的詐騙名單。這些人正在焦慮、正在等一封官方通知信、而且已經預期自己會被要求「處理一些事情」。此時一封看起來像官方的信，成功率高得驚人。

對組織來說，這代表你的事故公告有第二個任務：預先告訴當事人，什麼樣的聯繫一定不是你們。對個人來說，判斷原則是這幾條——

真正的官方通知不會要你點信裡的連結去登入、不會要你提供密碼或金鑰、不會有「限時補償方案」要你先付一筆錢、也不會急。要處理任何事情，關掉那封信，自己從書籤或搜尋進官網。

最後

這篇不是要說 Zeabur 有多糟，也不是要你換掉手上的服務。任何一家廠商都可能有一組憑證流出去，包括你自己的組織。

能做的事是把那條鏈看清楚，然後在自己這一節做兩件事：讓資料庫不要暴露在公開網路上，以及先想好萬一出事，那封信要怎麼寫。就算只做第一件，都已經比什麼都不做好很多。

如果你的組織想盤點一次目前的託管與權限狀況，或是想在事情還沒發生時先擬好事故應變與通知流程，歡迎與我聯繫。若你是個人——不管是擔心自己的資料在某個組織手上，或是正在處理跟蹤、騷擾相關的數位安全問題——一對一諮詢同樣可以，不需要透過任何機構。

資料來源