Railwayが環境変数の侵害を報告｜鍵の失効と再デプロイで復旧を確認する

Railwayを利用するWebサイトやAPIの運営者は、画面へ再ログインできることと、安全な資格情報で最新コードが動くことを分けて確認してください。Railwayは2026年10月21日に環境変数を保存するシステムで不審な活動を検知したと公表し、一部の変数について復号済みの内容へアクセスされた可能性を説明しました。Railwayの初回開示は、APIキー、データベースや非公開レジストリーの資格情報を含む秘密情報の更新と、関連サービスのログ確認を推奨しています。

この記事は10月24日8時台（日本時間）に確認した公式開示と、10月23日付の復旧ガイドを基にしたインシデント記事です。復旧操作の具体的な手順例は本サイトの提案であり、実環境で試験した結果ではありません。停止中のコミットが自動で追い付くとは限らない点と、鍵の差し替えがデプロイまで届いたかを中心に整理します。

基盤の復旧と利用者の対応完了は別に扱う

Railway公式ステータスの障害記録は、10月23日22時06分UTC、日本時間10月24日7時06分に障害を解決済みとし、ビルド、デプロイ、API、ダッシュボードは正常と案内しています。一方、新規登録の一時停止とコミュニティーサイトの利用不能は別途継続しています。初回開示にある「全デプロイ停止」を現在の状態として読み続けないよう注意が必要です。

同記録の日本時間10月24日4時18分の更新では、高リスク通知の対象外でも侵害されていないと確認されたわけではないと説明しています。秘密情報の更新、旧資格情報の失効、依存サービスの再デプロイ、提供元での不審な利用の確認が必要です。封じ込め後にこれらを完了済みなら、この更新だけを理由に繰り返す必要はないとも案内しています。

影響範囲の数字より自分の接続先を確認する

Railwayの暫定調査報告は、最大1.85％、約10万ワークスペースで一部環境変数が侵害された可能性があるとしています。どの変数が復号されたかを特定できず、予防的な鍵の失効依頼はより広い範囲へ行われました。ソースコードへのアクセスは否定し切れておらず調査継続中です。報告ページの日付表示は10月22日、公式ステータスで公開を案内したのは10月23日であり、初回開示日とは区別します。

このため「自社に通知がない」「外部APIの鍵が止まった」という状況だけでは、影響の有無を判定できません。本サイトでは、Railwayへ保存していた秘密を起点に、どの外部サービスとデータへ到達できるかを一覧化することを提案します。Webの表示が正常でも、バックグラウンドの送信処理や管理用APIだけが古い資格情報を使い続けている場合を想定します。

調査報告はAI提供元の鍵を狙った攻撃だったとの見解も示していますが、攻撃の技術的詳細は未公開です。本記事では、AIによる攻撃手法が独立して検証されたとは扱いません。一般のDB、決済、メールなどを使うサイトも、保管していた資格情報を確認する判断が必要です。

最初に秘密の値を出さず依存関係を記録する

次の表は本サイトが提案する対応台帳です。実際の漏えい項目を示すものではありません。値そのものを表やチケットへ貼らず、変数名、発行元、用途、利用サービス、失効状態を記録します。秘密の有効性を調べるために、無関係な外部サービスへ値を送信してはいけません。

確認対象の例	照合する場所	完了記録
外部APIキー	発行元のキー管理と利用ログ	旧キー失効と新キーの識別子
DB接続資格情報	DB利用者と接続元アプリ・ワーカー	接続先と切替済みサービス
非公開レジストリー	pull用資格情報とビルド設定	新資格情報での取得成功
Railwayへのデプロイトークン	CIの秘密設定と対象環境	交換後の実行・デプロイID

対象は本番のWebサービス一つだけとは限りません。同じプロジェクトのプレビュー、ステージング、cron、キュー処理、手動運用スクリプトにも利用先がないかを調べます。同じキーを複数環境へ使い回していたなら、そのすべてが切替対象になります。担当者ごとに別の新キーを発行して上書きし合わないよう、発行と反映の責任者を一人に定めます。

変数を保存しただけでは反映は完了しない

Railway DocsのUsing Variablesでは、変数の追加・更新・削除はstaged changesとなり、レビューしてデプロイする必要があります。また共有変数と参照変数があり、値を一か所で変えても利用サービスの対応を把握する必要があります。Sealed variablesはUIやAPIで値を見せない機能ですが、ビルドとデプロイには値が渡されます。この仕様だけを根拠に今回の影響対象外とは判断できません。

本サイトが提案する基本順序は、発行元で旧資格情報の扱いを決め、新資格情報を必要最小限の権限で用意し、利用先の変数を更新してレビューし、依存サービスへ反映してから疎通を確かめることです。悪用が疑われる鍵は失効を優先し、切替による停止を受け入れる判断が必要になります。安全な並行発行ができる場合も、旧キーを有効なまま放置せず、切替期限を決めます。

たとえばWebとワーカーが同じDB資格情報を使う構成なら、Webのログイン成功だけでは確認が足りません。ワーカーのジョブ処理、定期処理、再接続を伴う処理まで新しい資格情報で成功するかを確認します。これは仮想例であり、Railwayで当該構成の被害を確認したという意味ではありません。

検証時には環境変数を全件表示せず、発行元のキーIDや更新時刻、接続結果、デプロイIDを使います。失敗したからと失効済みの値へ戻すことは復旧になりません。ロールバックするコードにも新しい資格情報を渡せるよう、コードの版と秘密情報の版を別に管理します。

停止中のコミットと自動デプロイを照合する

RailwayのRecover Failing Deploysは、受付停止中にpushされたコミットはキューへ入らず、明示的に新しいデプロイを起動するまで最後の成功版が動くと説明しています。GitHub連携も解除されたため、必要な接続を戻し、Deploy Latest Commitを実行する案内です。チームでは元の接続担当者による再接続が必要になる点も確認してください。

ここで大切なのは、単に「最新」を押す前に、公開してよいコミットを選ぶことです。本サイトでは、停止前の稼働SHA、現在の稼働SHA、承認した対象SHAを記録することを提案します。停止中の変更にDB移行や外部API仕様変更が含まれる場合は、依存する変更も合わせてレビューします。デプロイ履歴が成功でも、狙ったコミットと異なれば完了にはしません。

接続復旧のためにGitHubの全リポジトリーへ広い権限を与える必要があるとは限りません。対象リポジトリーへ到達できるかと、通常運用で必要な権限だけを与えているかを確認します。再接続後には一つの小さな承認済み変更で経路を確かめ、重要サービスを一斉に更新する前にログと動作を確認します。

CLIとCIは認証の種類を混同しない

公式復旧ガイドはCLIの再ログインと、CIのRAILWAY_TOKENまたはRAILWAY_API_TOKENの再作成・差し替えを案内しています。前者はプロジェクトトークン、後者はアカウントまたはワークスペースのトークンです。再実行前に、CIの対象環境へ新しい値が設定されたかを確認します。

Railway DocsのPublic APIによると、プロジェクトトークンはプロジェクト内の特定環境、ワークスペーストークンは一つのワークスペース、アカウントトークンは本人の全リソースとワークスペースを対象にします。復旧を急いで最も広いアカウントトークンへ置き換えず、既存ジョブが必要とする範囲に合わせて選びます。

CIが認証エラーを返す場合も、原因を権限不足と決め付けないことが重要です。変数名の取り違え、環境ごとの秘密設定、古いジョブの再実行、別ワークスペースへのリンクを順に切り分けます。値のコピーをチケットやビルドログへ残さず、担当者が秘密管理画面で直接更新し、実行結果だけを共有します。

空のダッシュボードを見ても新規作成を急がない

RailwayのResolving Login Issuesは、元と異なるメールアドレスやGitHubアカウントでログインすると、新しい空のアカウントになる場合があると説明しています。プロジェクトが見えないときは同じ本人識別情報で入り直し、解決しなければ公式窓口へ相談します。問い合わせへパスワード、認証・復旧コード、APIトークン、秘密の値を送らないよう明記されています。

本サイトとしては、再作成した空のプロジェクトへ急いで本番DNSを向けるより、元のワークスペースを特定し、デプロイ履歴と秘密情報の切替記録をそろえることを勧めます。復旧手順を案内するメールを受け取った場合も、既知の公式サイトから窓口をたどり、認証情報の提出要求と正規の所有権確認を混同しないようにします。

完了条件は旧キーの拒否と新しい稼働実体

• 発行元で対象の旧資格情報が失効していることを確認する
• 全利用先の変数変更が反映され、承認したコミットが稼働していることを照合する
• Webだけでなくワーカー、cron、外部API、レジストリー取得を必要な範囲で検証する
• 提供元の利用ログを確認し、不審な操作・利用増加・新しい資格情報の発行を調べる
• 担当、対象、切替時刻、デプロイID、未確認範囲を記録して再確認の責任を残す

変更を段階的に適用して稼働実体を確認する考え方は「緊急パッチを安全に適用する実務ランブック」でも扱っています。同記事は10月23日時点の一般的な恒久対策で、今回のRailway事案の調査報告ではありません。今回はパッケージ更新より、資格情報とデプロイ経路の復旧が中心になる点を読み替えてください。

本記事は定期的な資料確認に基づき、常時監視や全件の安全確認を行ったものではありません。暫定調査には変更の余地があります。サービスが動いていること、提供元が復旧したこと、自社の秘密情報とコードが切り替わったことを、それぞれ別の記録で説明できる状態にすることが対応の要点です。