Railway 資安事件後怎麼輪替金鑰？Build、部署與備份驗收

先把影響範圍讀對#

官方指出，攻擊者先部分逃出 build 檔案系統隔離，取得 build 憑證，讀取其他 build 的 Temporal history；之後又利用錯誤 OIDC 綁定取得內部存取，讀取並解密部分環境變數。

報告中的「至多 1.85%、約 100,000 workspaces」是可能有環境變數遭解密的上限。紀錄定位到部分 environments，無法逐一辨識變數，不能把上限改寫成每個 workspace 都確定外洩。報告也列出 353 個 build histories 遭讀取，包含 sealed variables；因此盤點要納入建置時使用的憑證。

初步報告與處置建議要求客戶撤銷並重新設定 10/21 前存於 Railway 的敏感變數與金鑰。收到直接影響通知者應優先處理；尚未完成官方建議輪替的既有使用者，也應補做盤點。

輪替清單按發行端與使用者拆開#

先建立不含 secret 原文的紀錄：服務、environment、變數名稱、發行端、使用它的程序、舊 key ID／版本、新 key ID／版本及驗收結果。

已知暴露或持續遭濫用的 key 應立即撤銷，並接受必要的服務中斷。需要協調多個 consumer 的資料庫與簽章變更，則先寫清切換順序及中斷影響，避免只更新其中一個服務。

輪替過程只記 key ID、版本或發行時間，避免把新值列印在 logs、issue 或工單中。共同的憑證盤點原則也可參考 Zeabur 事件的金鑰輪替清單，但影響範圍仍以 Railway 本次報告為準。

Variables 改好後，分別驗收 build 與 runtime#

Railway Variables 文件說明變數修改需要部署後套用。建置時讀入的值與執行時讀入的值，要分開驗證：

1. 確認變更已部署。 記錄 environment、deployment、commit／image 與開始時間，確認檢查的是新 deployment。
2. 檢查 build consumer。 若憑證用於下載套件、拉取私有 image 或建置步驟，觸發需要該憑證的新建置；原本的成功 image 無法證明新 key 可用。
3. 檢查 runtime consumer。 由新 deployment 發出最小且低影響的 API 請求，並在發行端依時間與 key ID 核對。單看首頁 HTTP 200，可能只測到靜態頁或快取。
4. 檢查所有副本與背景程序。 Web 正常後，worker、cron 與其他 environment 仍要各自驗收。資料庫 pool 的舊連線也可能暫時掩蓋新密碼設定錯誤。
5. 最後核對舊 key。 優先用發行端顯示的撤銷狀態確認，不為測試而恢復權限或重新使用已知外洩憑證。

這份順序是輪替驗收建議，實際重建與部署方式需按服務設計調整。若無法確認哪個程序載入哪個版本，可加入不含 secret 的設定版本識別值，讓 logs 對應 deployment；識別值本身不能證明第三方 key 已成功使用，仍需最小請求佐證。

備份成功要另外確認#

事件報告特別提到：平台輪替 storage bucket credentials 後，執行中的容器保留舊值，曾導致資料庫 backup archiving 停止，之後由 Railway 重新部署處理。

因此服務恢復可用後，還要確認最近一次備份時間是否持續前進、archiving 是否有新錯誤，以及備份目的地是否收到新物件。有還原流程的系統，再於隔離環境做還原驗收；存在一份檔案，尚不足以證明可還原。

保留未知用量的時間、key ID、請求紀錄與帳單證據。官方報告的補償安排依 provider 分開處理，申請時應讀最新 Next steps，避免把支援個案當成一定退款的承諾。

參考資料：

Railway：October Security Incident 完整報告

Railway：初步報告與使用者處置建議

Railway：Variables