收到「你的資料外洩了」通知信怎麼辦？30 分鐘處理順序（我們自己剛走過一次）

2026 年 8 月底，台灣一家雲端平台商發生資安事件：攻擊者取得了用戶專案的環境變數——也就是網站的資料庫密碼、金流金鑰、各種 API key。官方分批寄出通知信，其中已證實有 AI 服務的金鑰被拿去實際盜刷算力。

我們自己有專案在通知名單上。這篇是我們當時實際走的處理順序，整理成任何人收到這種信都能照做的四段——全部做完約 30 分鐘，而且第一步跟你直覺想做的相反：先不要點信裡的任何東西。

TL;DR

1. 驗真偽（5 分鐘）：看寄件域名、看信裡有沒有只有你和平台知道的細節；判定為真也不點信中連結，自己打網址登入後台
2. 排優先序（5 分鐘）：兩個問題——這個服務從外面連得到嗎？裡面是真資料還是可拋棄的快取？答案決定先換哪個
3. 輪替憑證（15 分鐘）：資料庫密碼要進資料庫改，只改環境變數沒用；API 金鑰先撤銷舊的再建新的
4. 收尾（5 分鐘）：查事件日之後的用量與帳單、留證據、追官方事件頁、設消費上限

第一步：驗真偽——真通知和假通知的差別

外洩事件後的一到兩週，是仿冒通知信的高峰期。詐騙集團知道大家這時候看到「安全警告」會緊張，假信會長得跟真信一模一樣。常見的判斷方法：

• 看寄件域名：是不是平台的官方域名（例如 notify.平台名.com）。像素級模仿的信，域名多半破功
• 看細節：真的通知信會列出你的專案名稱、服務名稱、環境變數名——這些只有你和平台知道，釣魚信偽造不出完整的清單
• 看動作：這是最好用的一條。真通知叫你自己登入後台改設定；假通知叫你點信裡的連結去「驗證身分」。方向完全相反

判定為真之後，仍然不點信中任何連結——自己打官方網址、登入後台、找官方的事件公告頁（status page）核對。這個習慣讓你在真假難辨的時候永遠安全。

第二步：排優先序——兩個問題決定先換哪個

通知信可能列出一長串「可能受影響」的憑證，全部一起換會手忙腳亂。我們當時用兩個問題排序：

兩個都命中「高」的先換。我們自己的例子：一顆存客戶資料的資料庫密碼，排在四個快取服務的密碼前面——前者洩了是客戶個資問題，後者洩了最多是快取重建。

一個例外會插隊：官方證實「已遭實際盜用」的憑證類型，不管有沒有被點名都跳到最前面。這次事件裡是 AI 服務的金鑰（被拿去盜刷算力）——這類金鑰的值有固定格式（sk- 開頭那種），掃一遍你所有專案的環境變數，變數叫什麼名字不重要，值長那樣就要換。

第三步：輪替憑證——兩個多數人會踩的坑

坑一：改環境變數不等於改密碼

資料庫（PostgreSQL、MySQL、MongoDB）的官方容器只在第一次啟動時讀密碼設定。事後改環境變數再重啟，密碼根本沒變——你以為換好了，舊密碼還能用。正確做法是進資料庫下改密碼的指令（例如 ALTER USER ... WITH PASSWORD），再更新環境變數、重新部署用到它的服務。

Redis 是例外：它的密碼是啟動參數，改環境變數重啟就生效。

坑二：只建新金鑰、沒撤銷舊的

API 金鑰（AI 服務、金流、雲端）要到各服務商的後台先撤銷（revoke）舊金鑰，再建新的。只建新不撤舊，舊金鑰照樣能被盜用——等於門換了鎖、舊鑰匙還插在門上。

兩個順手的細節：新密碼用純英文數字產生（特殊符號進連線字串常出解析問題）；改密碼到重新部署之間服務會短暫連不上，步驟排好一口氣做完，挑離峰時段。

第四步：收尾——查帳、留證、追蹤

• 查用量與帳單：從事件日開始查，AI 服務看 token 用量、金流看交易紀錄、雲端看資源用量。有異常就截圖存證（時間、金額、來源 IP），平台事後的賠償流程會要這些
• 設消費上限：AI 服務和雲端帳號關掉自動儲值、設每月上限——下次再出事，損失有天花板
• 檢查密碼複用：同一組密碼有沒有用在本地開發環境、CI、其他平台，有就一起換
• 追官方事件頁：通知信可能分批寄，第二批點名的內容第一批未必涵蓋；完整調查報告出來前，事件頁是唯一可靠的資訊源
• 順手關掉不需要的公開連接埠：這比換密碼更治本——密碼外洩不可怕，可怕的是那扇門本來就開在公網上

台灣個資法：什麼情況你自己也有通知義務

這是多數文章不會講、但老闆真正該知道的分界：

• 外洩的是 API 金鑰（AI、金流、雲端服務的鑰匙）→ 多數情況不涉及個資，沒有通知客戶的義務
• 外洩的是資料庫連線字串，而那顆資料庫裡有客戶個資（會員資料、訂單、對話紀錄）→ 個資法第 12 條要求你查明後以適當方式通知當事人

另外，個資保護委員會籌備處有一份事故通報辦法草案（知悉後 72 小時內通知、達一定規模要通報主管機關），寫這篇時還沒施行，但方向已定——把「出事後 72 小時要能說清楚影響範圍」當成日常整備的標準，不會錯。

平時能買的兩張保險

事件裡我們體會最深的反而是平時的兩件事：

1. 服務只走內網就不開公開埠。這次排序時「低風險」那一格的服務，全是因為只走內網——密碼被撈走也連不進來
2. 知道自己每個服務裡放了什麼。30 分鐘處理的前提是你答得出「這顆資料庫裡有什麼、這把金鑰能碰到什麼」。答不出來的話，光是把清單找齊就要半天

第二件事就是網站健檢在做的其中一塊。你的網站有哪些服務、哪些對外開著、金鑰放在哪——這張清單平時看起來無聊，出事那天它就是你的 30 分鐘和別人的三天的差別。

FAQ

Q1：通知信說「可能受影響」，我要全部照做嗎？

A: 要，而且官方自己也這樣建議——這類事件的通知常分批寄、判定標準會修正，「沒收到信」不等於「沒事」。用第二步的兩個問題排序，高風險的先做，低風險的排進這週做完。

Q2：我用的是開店平台（蝦皮、SHOPLINE 這類），也會遇到嗎？

A: 平台幫你管基礎設施，這類環境變數外洩多半輪不到你處理；你自己申請的服務金鑰（LINE 官方帳號、金流商後台、廣告帳號）是同一套邏輯：後台密碼夠強、能開兩步驟驗證就開、離職的人員權限要收回。

Q3：怎麼判斷我的網站有沒有這種風險？

A: 三個自查點：①你知不知道網站用了哪些外部服務、金鑰放在哪 ②資料庫是不是只有網站本身連得到（沒有對外開埠）③帳單有沒有設上限與告警。三題有任何一題答不出來，就值得找時間把清單建起來。

延伸閱讀

• 平時的整備：網站健檢完整指南
• 網站本身的防護：安全標頭 HSTS 與 CSP 是什麼
• 憑證的另一種過期：SSL 憑證過期的自動續約設定

收到這種通知信、不確定自己該做哪幾步，加 LINE 跟我們說一下狀況就好（用什麼平台、網站上有沒有會員或訂單資料）。需要的話，我們再約 30 分鐘把你的清單一起過一遍。