Railwayで認証情報が漏えいした可能性、全ユーザーにキー更新を推奨

ホスティングサービスのRailwayは10月21日、第三者が保存中の環境変数に不正アクセスし、一部の内容を読み取った可能性があると発表しました。影響が一部ユーザーに限られる可能性はあるものの、調査は続いており、同社は予防措置として全ユーザーに認証情報の即時更新を強く勧めています。

古いキーは発行元で無効化する

Railwayの説明では、第三者が暗号化された環境変数にアクセスし、その一部について復号後の内容も取得した可能性があります。環境変数にはAPIキー、データベースやプライベートレジストリの認証情報が含まれる場合があり、同社は影響が確認されたユーザーだけでなく、全ユーザーに更新を推奨しています。

APIキーなどは発行元で古いものを失効させ、再発行した値をRailwayに登録します。Railway上の値を編集するだけでは、外部サービスの古いキーは失効しません。更新した認証情報を利用するアプリにもデプロイして反映させ、関連サービスのログに不審な利用がないか調べてください。

バケットのキー更新後は、利用サービスを再デプロイ

10月22日の復旧ガイドによると、Railwayはすべての環境のストレージバケットで、アクセスキーIDとシークレットアクセスキーを無効化し、再生成しました。このキーの再生成では、バケット名、エンドポイント、保存済みオブジェクトは変更されません。

ただし、コンテナは起動時に環境変数を読み込むため、稼働中のサービスに新しいキーを反映するには再デプロイが必要です。環境ごとにバケットの認証情報が異なるので、利用している環境をそれぞれ確認します。

古いキーを変数の値として直接貼り付けている場合は、バケットの認証情報への参照に置き換えてデプロイします。Railwayの外にあるCI、ローカル開発環境、S3クライアントも更新対象です。再デプロイ後は、オブジェクトの一覧取得や書き込みができるか確かめてください。

GitHubの再接続と、レジストリ用トークンの交換

Railwayが保持していたGitHubアカウント接続用のトークンもリセットされました。GitHubを利用している場合は、アカウント設定から再接続し、Railway GitHub Appのリポジトリ権限、サービスに接続されたリポジトリとブランチ、自動デプロイの設定を確認します。

GitHub Container Registry（GHCR）のプライベートイメージを使うサービスには、別の対応も必要です。Railwayはレジストリ認証用に保存していた個人アクセストークンを削除しましたが、この削除だけではGitHub側のトークンは失効しません。古いトークンをGitHubで失効させ、新しく発行したトークンをサービスごとのレジストリ認証情報に登録して、再デプロイします。

ビルドがまだ使えないワークスペースでは、再デプロイを伴う手順は再開を待ってください。対応状況はRailwayの公式ステータスページで確認できます。