密碼換過了，只是換成猜得到的那一組

換了鎖，鑰匙還是同一把的形狀

想像你家遭小偷，鑰匙被複製走了。你請鎖匠換鎖，新鑰匙卻只是在舊鑰匙尾端多磨了一個齒。手上有舊鑰匙的人，試幾次就打得開。

這次的「鎖」是一台自架的 n8n——我們拿來串排程、同步資料、呼叫 AI 的工作流程平台——背後的 PostgreSQL 資料庫。8 月 27 日那次環境變數外洩之後，我們在 8 月 30 日輪替了這個資料庫的 root 密碼，新值是「舊密碼後面加上 0829」。資料庫的 TCP port 一直對外轉發，網路上的掃描器每天都在敲它。10 月 15 日凌晨，有人不再只是敲門。

這是自家事件，第一手資料是我們自己的資料庫 log、Google Cloud 的 Monitoring 與 Audit Log。下面的時間全部是台北時間，證據照三級擺。

1. 2026-08-27
   部署平台環境變數外洩，其中包含這台資料庫的舊密碼，以及平台本身的 PASSWORD 變數（之後被用作憑證加密金鑰）
   INC-2026-0827 調查紀錄
2. 2026-08-30
   資料庫 root 密碼輪替，新值為「舊密碼＋0829」；平台的 PASSWORD 變數沒有換。同日把一把新的 Gemini API key 放進平台憑證庫（只限 Gemini API，未綁來源 IP）
   輪替腳本紀錄、部署平台變數現況
3. 10-15 00:16
   資料庫 log 出現一筆不是平台本身發出的查詢：用字串串接的方式撈「credentials_shared」表，表名猜錯而報錯
   PostgreSQL runtime log（ERROR 與 STATEMENT 各一行）
4. 10-15 00:43
   兩把憑證開始大量呼叫：具 Owner 權限的 GCP:Service Account 金鑰打 Vertex AI Gemini（europe-west1），Gemini API key 第一批呼叫出現，01:13 起每小時數千次，尖峰 8,039 次／小時
   Monitoring 依憑證分組的分鐘級請求數
5. 10-15 01:14
   Audit Log 記下 Google 為該專案初次建立 Vertex 服務代理
   Cloud Audit Logs（服務代理 SetIamPolicy）
6. 10-15 10:14–10:36
   看到帳單異常後作廢服務帳戶金鑰、刪除 API key、停用服務帳戶；兩條曲線隨即歸零
   IAM Audit Log、Monitoring
7. 10-15 16:02–16:04
   資料庫 root 改為 32 字隨機密碼並回填平台、重啟驗證；關閉資料庫對外轉發，只留內網
   本站處置紀錄、部署平台 API 回應

時間線裡最值得盯的是第三、四格之間的 27 分鐘：00:16 有人在資料庫裡找憑證，00:43 兩把憑證開始計費。先翻抽屜、再拿鑰匙出去用，順序對得上。

這裡要更正一件事。初版我們寫「服務帳戶金鑰在 00:01、00:02 各被呼叫 1 次，像是在驗證金鑰」，並據此推論攻擊者早在資料庫查詢之前就拿到鑰匙。之後把 Monitoring 拉到全 API、拉長到 30 天才發現，那兩筆是試算表 API 的讀取，平台每小時 :01、:02 都會跑一次，是自己的正常排程。這把金鑰第一次呼叫 Vertex AI，是在 00:43。看請求曲線時只看出事的那個 API、只看出事那一天，很容易把自己的排程誤認成攻擊者。

發現它的，又是帳單頁

這起事件不是被資料庫告警抓到的，因為資料庫沒有任何告警；是隔天上午看到 Google Cloud 帳單出現兩個異常項目，才往回追。兩個異常分屬兩個不同的 GCP 專案、兩種不同的憑證，看起來毫無關係。

把它們接起來的是時間：兩條請求曲線在同一個小時內從零起飛。再往下查，兩把憑證唯一的共同點，是它們都只存在同一個地方——那台工作流程平台的憑證庫。本機、repo、其他服務都沒有這兩把；只有平台裡有。

攻擊者怎麼做到

到這裡，其實已經足夠理解整起事件。如果你關心的是該怎麼避免，可以直接往「如何避免」繼續閱讀。如果你想知道我們怎麼把兩張帳單接回同一個資料庫，下面開始進入技術拆解。

白話結論：攻擊者沒有用任何漏洞。他需要的三樣東西，有兩樣早在八月就流出去了，第三樣只要用猜的。

接下來這一段會稍微技術一些。你只需要先記住一件事：這個平台把所有憑證加密存在資料庫裡，而加密用的金鑰，就是八月那包外洩的環境變數裡的其中一個值。

這次外洩了什麼

這張表很長，是因為一個憑證庫被打開，裡面的每一把都要算進去。

最上面兩列是根因，第三、四列是帳單，最後一列是接下來兩週的工作量。

我們怎麼處理

上午看到帳單的當下，先做的是止血，不是追查：作廢服務帳戶金鑰、刪除 Gemini key、停用服務帳戶。這三步在二十分鐘內完成，兩條曲線在下一個小時區間歸零。

下午把兩張帳單接回同一個資料庫之後，處理的是根因。資料庫 root 改成 32 字的隨機密碼，先在資料庫端改、用新密碼驗證登入，再把平台的連線設定回填，重啟平台確認它能用新密碼連回去。接著把資料庫的對外轉發整個關掉，只留下平台在內網使用的 port，從外面再也敲不到。

傍晚換掉了那把主鑰：產生新的隨機加密金鑰，把憑證庫 42 筆憑證全部用新金鑰重新加密，重啟後確認 46 個工作流程正常、log 沒有解密錯誤。第一次嘗試只改了環境變數，沒改平台存在磁碟上的設定檔，平台因為「加密金鑰不一致」反覆重啟了六分鐘，先用備份回滾，再連設定檔一起改才成功。換主鑰之前先做備份、確認它存在哪幾個地方，這一步省不得。

還沒做完的有兩件：憑證庫裡其他每一組資料庫密碼、SSH 私鑰都要當成已外洩輪替；平台本身要升版。

申請減免：一張 US$1,976 帳單的申訴實錄

止血和修根因都是技術問題，申請費用減免則是流程問題。我們以為開個工單、貼上報告就結束了；實際走一遍，中間卡了七次，最後拿到的答覆也跟想像的不一樣。這一節把整個過程照時間順序記下來，下一個收到盜刷帳單的人，可以少走幾步冤枉路。

先把申訴的材料準備好

開口之前，先準備了四樣東西：明確的時段與金額、事發前後的用量對照、處置時間戳，以及一份書面報告。

金額不是自己從帳單頁加總，而是請 Console 的帳單助理依專案與 SKU 算出 10-14 到 10-15 這段期間的費用：US$1,976.01，涵蓋三個專案。除了前面那兩把，還有一把同期被盜打的服務帳戶金鑰，它在八月就外洩了。證據檔共 14 個：依 SKU 與服務分列的帳單報表、三把憑證各自的 30 天用量圖與放大圖、每小時請求數 CSV、IAM 稽核記錄，以及資料庫那一筆異常 SQL 的 log 節錄。

書面報告參考了網路上爭取成功的案例，共同點只有幾個：事前的基準線加上暴增曲線、SKU 明細、每一步處置的時間戳、已經補上的防線、明確的金額與時段，最後主動要求案件編號與審核時程。報告也老實寫了我們自己犯的錯，包括可預測的密碼和沒換的加密金鑰。

卡關一：找不到開申訴的入口

第一個直覺是 Console 左側選單的「支援 → 客服案件」。點進去，中間一條灰色提示寫著目前的支援方案不提供這項服務，要先選購付費方案才能建立案件。我們用的是免費的 Basic 方案，技術客服案件開不了。

第二個直覺是網路文章常引用的公開帳單表單。打開才發現它已經停用，網址會直接轉到官方說明頁「取得 Cloud Billing 支援」。說明頁的意思很清楚：帳單問題現在只剩一個入口，而且是免費的。

正確的路徑是這樣：

Google Cloud Console
 → 左側選單「支援」
 → 「帳單問題支援」（頁面寫著：取得免付費的帳單助理支援服務）
 → 兩個按鈕：
     「取得帳單支援」          ← 第一次申訴從這裡進
     「管理現有的帳單客服案件」 ← 之後上傳附件、留言、追蹤進度用

只有帳單帳戶管理員能查看和更新帳單案件。如果點得進入口、卻看不到案件，先檢查自己在帳單帳戶上的角色。

同一頁的上方還有一條紅色橫幅：「系統偵測到您的一項專案可能違反《使用限制政策》」。它跟帳單申訴無關，是被停權專案的申訴入口，後面會再講。

卡關二：先跟機器人講，再轉真人

按下「取得帳單支援」，接手的是 AI 帳單助理。它的開場白要你用幾句話說明問題，並說隨時可以要求轉接真人，它會把對話紀錄一起轉過去。聊天視窗不能上傳附件。

這時不要貼整封長信。我們送出的是一段五、六行的摘要：帳單帳戶、三把憑證外洩、呼叫次數與金額、上一個帳單週期幾乎是零、其中一個專案已被 Google 以盜用為由停權、我們已撤銷金鑰並修好根因、手上有完整報告。最後一句直接寫明要轉真人：AI 助理不能核准退費，這類案件一定要真人處理。

助理的回覆比預期有用。它依帳單帳戶查了 10-14 到 10-15（太平洋時間）的費用，列出 Gemini API US$1,623.04、Vertex AI US$352.97（已扣抵免），合計 US$1,976.01，並說系統已經把這幾筆暴增標記為成本異常。最後它問：要不要現在幫你轉接真人客服？

這組數字成了後面的申請金額。原本我們從帳單報表算的是整個 10 月，多了約 US$18；助理算的是盜打那兩天，而且是 Google 自己的數字，拿來申請更站得住。我們回覆確認轉接，並在同一句寫上「申請金額就是你算的 US$1,976.01」。

不到兩分鐘，真人客服就接手了。他的第一句話是問還有什麼要補充。我們先送一段重點，請他建立帳單案件讓我們上傳附件；再把約 8,000 字元的完整報告整份貼上。聊天框收下了，不用拆段。

卡關三：案件是聊天自動建的，主旨就是你的第一句話

真人客服接手後，給的案件編號是聊天開始時就自動建立的。案件主旨直接用了我們在聊天裡的第一句話，看起來不像一份正式申訴。這不影響審核，但第一句話最好一次寫清楚帳戶、時段、金額和訴求，因為它會一直掛在案件標題上。

卡關四：客服報的金額跟我們的不一樣

真人客服花七分鐘查完帳戶，報出的卻不是帳單助理算的那組，而是整個 10 月到目前為止的數字：Gemini API US$1,641.81，比助理算的多了約 US$18。差額是盜打那兩天以外的正常用量。機器人和真人各查各的，數字不一定對得上。

我們主動說明只申請盜打時段的 US$1,976.01，其他日期是正常用量、不在申請範圍內。理由很簡單：數字精確，比數字大更容易被核准，也不會讓人覺得我們在順便多要。

卡關五：聊天在最後一個問題斷線

客服問完「您認得這三個專案嗎」之後，聊天就斷了，問題沒來得及回答。斷線後才發現兩件事：聊天紀錄不會出現在案件頁上，是事後另外用 email 寄來；而客服口頭說「附件用 email 寄」，但案件頁本身就有附件欄。

最後的處理方式是改從案件頁接續：直接打開案件，在附件欄上傳 14 個檔，再在案件歷史記錄留言，補答「三個專案都是我們的，但那段用量不是我們用的」，並說明附件已上傳、會等 32 小時後的通知。當天晚上客服來信道歉，說稍晚會主動聯絡，從斷線的地方接著處理。

卡關六：被停權的專案要另外申訴

三個專案裡，有一個在盜打期間就被 Google 的濫用偵測自動停權了。費用減免走帳單案件，停權要走另一條管道：專案頁上方的紅色橫幅會連到申訴表單，送出後由另一個團隊處理，會另外寄一封確認信、給另一組單號，通常兩個工作天內回覆。這個專案的服務帳戶擁有上萬個雲端硬碟檔案，停權期間讀不到也搬不走，所以我們申請的是復權，並寫明「不要求恢復任何 AI 用量」。

Google 的正式答覆：「費用有效」，但給一次性調整

斷線後我們改從案件頁接續：先上傳 14 個證據檔，再留了兩則訊息：一則重申申請內容和兩個待確認的問題，一則補答「三個專案都認得，但用量不是我們的」。當天晚上客服在案件裡正式回信。前半段很直接：Google Cloud 是共同責任模式，執行個體與憑證的安全是客戶自己的責任，這類情況產生的費用屬於有效費用，照規定原本不能爭議。後半段才是重點：作為客戶的通融，他會替我們申請一次性調整（one-time adjustment）。

第一次讀到「charges are considered valid」很容易以為被拒絕了。其實這正是成功案例的典型說法：Google 不會承認費用無效，減免一律以「一次性通融」的名義給。所以申訴信不必爭「這不該算我的」，要證明的是三件事：用量確實不是我們產生的、我們已經止血並修好根因、以後不會再發生。

信裡還附了一份安全建議清單：API key 加上限制並定期輪替、設定專案層級的用量上限、設預算與警報、定期看用量。這些在我們的申訴報告裡大多已經做了，回覆時逐項說明，比單純道謝更有說服力。

還有一個小地方要更正：信裡寫的金額是 US$1,994.78，也就是客服在聊天裡報的整月數字。我們回覆時再說明一次，申請的是盜打時段的 US$1,976.01，差額是正常用量。

卡關七：客服說「先不要付」，但帳單是自動扣款

客服建議審核期間先不要付款，這句話預設的是「自己手動付款」的帳戶。我們打開帳單帳戶的付款頁才發現，付款方式是每月結帳日自動扣款：上一次在 10 月 1 日自動刷了 9 月的費用，10 月 1 日到 15 日的餘額已經累積到 US$1,997.46，盜打的費用就在裡面。照這個節奏，11 月初會自動整筆扣款；自動扣款的帳戶如果餘額先達到付款門檻，也可能在月中提前扣。我們根本沒有「先不付」這個選項。

這時最直覺、也最危險的做法，是把信用卡移除，讓它扣不到錢。扣款失敗會讓帳單帳戶轉成「狀態不佳」，同一個帳戶下所有正常運作的專案都可能被暫停，損失遠比這筆帳單大。所以我們定了一個原則：不移除信用卡、不讓扣款失敗；真的被扣了也沒關係，減免核准後一樣拿得回來。

剩下的是把狀況講清楚，讓客服決定怎麼處理。我們先回信致謝、更正申請金額，再補一則留言，說明帳戶是自動扣款，請他確認兩件事：審核期間能不能暫緩這筆扣款；如果審核完成前就扣了，核准的調整是退回信用卡，還是轉成抵免額抵之後的帳單。

這一卡給下一個人的提醒很簡單：申訴之前，先去付款頁確認自己是手動付款還是自動扣款。客服的付款建議要對照自己的付款方式來讀，不要為了「先不付」去動信用卡。

結果：核准 US$1,497.77，以抵免入帳

32 小時的同步過了好幾天，案件一直沒有新消息。10 月 19 日上午我們在案件裡主動追蹤，順便把還沒得到答覆的自動扣款問題再問一次。當天下午客服回信：系統同步後的最終金額是 US$1,978.26，調整申請已經送出，1 到 3 個工作天內會有結果。

10 月 20 日深夜，結果來了：調整核准，金額 US$1,497.77。4 分鐘後客服補了第二封信，回答我們問了兩次的問題：調整是以抵免額（credit）的形式套用到帳單帳戶，不是退回信用卡。

打開帳單帳戶的交易頁對帳，10 月這一段只有三行：

10-01  自動付款（9 月帳單）                                   −US$  148.42
10-01～31  Google Cloud（10 月至今的費用，盜打就在裡面）          US$1,997.63
10-20  Service Adjustment - Goodwill Credit/Refund（本案）      −US$1,497.77
       ───────────────────────────────────────────
       期末餘額                                                 US$  499.86

這張表回答了兩個我們問了兩次的問題。第一，抵免是直接扣在 10 月的費用上，不是等扣款之後再退回信用卡；11 月初自動扣款時，扣的是抵免後的餘額。第二，10 月 1 日那筆扣款是 9 月的正常帳單，跟這次盜打無關，不會被退。

整個申訴從 10 月 15 日開口到 10 月 20 日核准，剛好 5 天、3 個工作天。

拿回七成六，剩下的我們沒有再追

核准的 US$1,497.77 是最終認定金額 US$1,978.26 的 75.7%，差額 US$480.49。兩封信都沒有說明差額怎麼算，交易記錄也只有一行總數。

我們討論過要不要再追，最後決定不追。理由有三個：信裡第一句就說了這是「有效費用」下的一次性通融，Google 沒有義務全額減免；申訴報告裡老實寫了可預測的密碼和沒換的加密金鑰，責任有一部分確實在我們；再追一輪的時間成本，不一定比四百多美元低。所以最後一封回信只確認看到抵免、請客服結案。

這筆差額，就是這次事件真正從口袋裡掏出去的錢，下面的成本表也照實列出來。

給下一個收到盜刷帳單的人

1. 入口：Console → 支援 → 帳單問題支援 → 取得帳單支援。技術客服案件要付費方案，帳單案件免費。
2. 先讓 AI 帳單助理算出盜打時段的金額，用 Google 自己的數字當申請金額，再要求轉真人。
3. 第一句話會變成案件主旨，一次寫清楚帳戶、時段、金額、訴求。
4. 聊天會斷，附件一律從案件頁上傳，留言補完聊天沒講完的話。
5. 「charges are considered valid」不是拒絕，是一次性通融的標準開場白。
6. 自動扣款的帳戶不要動信用卡；核准的調整會以抵免額扣在帳單上。
7. 32 小時後沒消息就主動追。我們追了一次，當天就拿到最終金額，隔天核准。
8. 不保證全額。這次拿回約七成六，差額沒有說明。

接下來是聊天全文，英文原文與中文翻譯並列，專案、帳戶、案件編號與人名都已去識別化。

哪裡做對，哪裡做錯

做對的是兩件事。第一，止血先於追查——攻擊者的計費不會等你查清楚。第二，把兩個看似無關的帳單異常，用「同一個小時起飛」這條線接起來，而不是當成兩起各自處理；不接起來，我們會換掉兩把 Google 憑證，然後在下週看到第三張帳單。

做錯的也是兩件，而且都發生在八月那一次「已經處理好了」的輪替裡。第一，輪替是為了讓舊值失效，但「舊值＋0829」讓舊值仍然是一把幾乎可以用的鑰匙：持有舊值的人，正是我們輪替要防的那個人。第二，我們換了資料庫密碼，卻沒有換那把能解開所有憑證的加密金鑰——因為它在設定裡長得像一個普通的 PASSWORD 變數，看不出它其實是整個憑證庫的主鑰。資料庫對外開著這件事，則是讓上面兩個錯誤從「理論上的風險」變成「凌晨十二點的一筆 SQL」。

如何避免

當天就能做的是兩件事。把所有資料庫的對外轉發列出來，平台只在內網用的，直接關掉。再把上次外洩之後換過的密碼逐一看一遍，凡是新值看得出舊值的影子，再換一次，這次用隨機產生器。

一週內做的是把「主鑰」找出來。每個自架平台都有一兩個不起眼的變數，掌管著整個平台的加密：n8n 的加密金鑰、各種框架的 secret key、session key。把它們跟一般密碼分開列管，外洩事件的輪替清單一定要包含它們，而且要知道換了之後要做哪些重新加密。

這一季做的是收斂放進第三方平台的憑證權限。工作流程平台的本質就是一個裝滿別人鑰匙的盒子，盒子被打開時，損失由裡面最大的那把鑰匙決定。放進去的服務帳戶只給它需要的那一個角色，絕不給 Owner；API key 綁平台的出口 IP；每個計費帳戶設預算警報，讓下一次異常在凌晨就有信進來，而不是等到上午看帳單。

這篇提到的項目要花多少錢

這張表左右兩邊的對比很清楚：攻擊者取得憑證的成本趨近於零，我們補上防線的成本也趨近於零，中間那兩列是一張 US$1,976.01 的帳單，再扣掉 Google 核准的 US$1,497.77 抵免。

proven 列相加是 US$478.24：盜打那兩列的 US$1,976.01，扣掉 Google 核准的 US$1,497.77 抵免。以客服最終認定的 US$1,978.26 計算，實際自付是 US$480.49，約新台幣一萬五千元。其他 proven 列都是零，因為它們本來就該做、而且不用錢。

你可以學到什麼

站在攻擊者那一側看，八月那包外洩的環境變數不是一次性的收穫，是一份會一直增值的資產。我們以為輪替完就結束了；對他來說，那份資料告訴了他三件事：資料庫在哪、密碼長什麼樣子、憑證庫怎麼解。他只要偶爾回來試一下，等我們把新的、更值錢的鑰匙放進那個盒子。

跟我們的防暴筆記對照

對照 INC-2026-0827（排程回報「找不到帳戶」，被停權的是整個專案）。那一次被拿走的是一把掛著 Owner 的服務帳戶金鑰；這一次，被拿走的又是一把掛著 Owner 的服務帳戶金鑰。中間隔了七週，我們輪替了二十組資料庫密碼，卻在其中一組用了舊值加日期，也漏掉了那個不叫 KEY、其實是主鑰的變數。輪替的盲點那篇講的是「換了，但有人還拿著舊的」；這篇補上另一半：換了，但新的跟舊的長得一樣。

回到那把多磨了一個齒的鑰匙

八月我們換了鎖，也真的換了二十把。只是其中一把，新鑰匙看得出舊鑰匙的形狀；而門旁邊那把能打開所有抽屜的總鑰匙，我們沒有認出它來。

現在那扇門已經不對外了，鎖也換成了誰都猜不到的那一種，總鑰匙當天傍晚就換了。抽屜裡的每一把，是接下來兩週的事。帳單那一邊，Google 核准了 US$1,497.77 的抵免，剩下約 US$480，是這次學費的實際價格。