Northflank 安全事件：環境變數金鑰輪替、覆寫與重啟驗收

先盤點憑證的發行端與所有使用者#

先列出環境變數的名稱、發行服務、權限、使用它的 workload／job，以及是否在其他平台重複使用。這份清單不應包含完整秘密值，也不要將整份 .env 貼進問題回報或聊天工具。

依官方範圍，盤點不能只看目前開著的服務：還要查共用 Secret Group、Global Secrets、工作負載個別設定，以及建置或排程使用的憑證。若同一把金鑰也供其他平台使用，輪替會影響那些消費端，必須一併列入驗收。

可先用一列紀錄釐清工作：

1
變數名稱：PAYMENT_API_KEY（示意）
2
發行端：金流供應商
3
消費端：api-prod、nightly-job、另一平台的 worker
4
設定來源：Secret Group；api-prod 另有同名覆寫
5
新憑證建立：待處理
6
新部署與最小驗收：待處理
7
舊憑證撤銷：待處理

這只是盤點格式，不是本次事件的實際帳號資料。優先處理可直接造成損害的憑證；已確認或懷疑遭濫用的金鑰，應先在發行端停用或撤銷。需要短暫切換以維持服務的情況，也要把舊憑證撤銷列為明確步驟，不能無限期保留。

在發行端輪替，接著追到真正生效的位置#

輪替 API key 要在該 API 供應商建立替代憑證並撤銷舊值；資料庫憑證也要在對應資料庫或平台管理功能處理。只把 Northflank 裡的字串改成另一個名稱，不會讓原憑證失效。這個原則也符合 OWASP 的 secrets 生命週期指引。

官方同日 15<12> UTC 的事件更新說明，已向所有使用者啟用 Postgres 與 MongoDB 的 secret rotation。實際操作仍以目前控制台和官方指引為準，不能將這項說明外推成所有 addon 都有相同輪替按鈕。

新值建立後，沿盤點清單更新每個消費端。特別檢查 Northflank 的變數優先順序：服務或 job 個別設定的同名值，優先於繼承的 Secret Group。 共用群組換好，個別服務仍可能繼續讀取舊值。

同一變數存在多份時，記錄各份來源與用途再修改，不要一次刪除所有重複名稱來猜哪份生效。若使用 API 或 CLI 更新 Secret Group，官方文件提醒 secrets.variables／secrets.files 即使透過 PATCH 也會整份取代；只送一個新 key 可能丟掉其餘設定。需要這條路徑時，先在受控環境依文件準備完整集合，避免緊急處置又造成另一項設定遺失。

保存後，還要重啟服務或開始新的 job run#

Secret Groups 文件明確區分保存與套用：群組設定保存不會重啟工作負載；更新 runtime variables 後，需要重新啟動服務，或開始新的 job run。建置階段使用的值則要另行確認建置流程，不能只驗收 runtime。

對每個消費端保留以下證據：

1. 設定來源正確：確認已更新群組、全域值與個別覆寫；紀錄憑證識別碼或版本即可，不在 log 輸出秘密值。
2. 新執行環境已啟動：確認實際 deployment／job run 是更新後的新執行，而非舊容器仍在服務。不要為了測試而重跑會付款或寄信的正式 job，應使用可控的最小測試。
3. 新值能完成必要動作：用最小權限、低副作用的方式驗收依賴服務，並查看供應商端對應的成功或失敗紀錄。首頁回傳 200 不足以證明資料庫或第三方 API 已連通。
4. 舊值已失效：在發行端確認撤銷／停用狀態，按該服務支援的方式驗證，避免將舊秘密再次複製進一般 log。檢查異常用量、費用與存取紀錄，保留時間線供後續調查。

官方也要求停用已啟用的 addon 公開存取。先辨識依賴該公開位址的合法消費端並改用核准的連線方式，同時執行憑證輪替；關閉網路入口不能讓已外流、仍有效的金鑰自動失效。

平台恢復運作，仍需完成自己的撤銷清單#

輪替失敗時應修正新憑證權限或建立另一組替代值，不要把疑似外洩的舊值當成長期回復方案。服務重新上線、控制台可登入與秘密已撤銷，是不同的完成條件。

如果你也維護其他部署平台，可對照 Zeabur 事件的憑證輪替與部署驗收；事件事實仍以各平台官方公告為準，不能把另一家平台的原因套到 Northflank。本次可完成的是逐項留下新部署成功與舊憑證失效的證據，事件最終範圍則等待官方後續調查更新。

參考資料：

Northflank：Security incident

Northflank：Inject secrets

Northflank：Manage secret groups

OWASP：Secrets Management Cheat Sheet