Railwayの侵害：ダウンタイムなしでアプリのシークレットをローテーションする方法

10月21日、Railwayは、顧客の環境変数を保存するシステムに第三者が不正にアクセスし、その一部については攻撃者が復号済みの内容を入手した可能性があると公表しました。Railwayはすべてのデプロイを一時停止し、キーを失効させるよう上流のプロバイダーに通知したうえで、プライベートレジストリの認証情報を含む環境変数をローテーションするよう全ユーザーに求めました。

暫定報告書では、さらに詳しい状況が明らかになっています：

TechCrunchによると、Railwayは今回の件を、AI推論プロバイダーの侵害を狙ったプラットフォームへの広範な攻撃キャンペーンの一環とみています。同じ週には、AIコーディングツールのOpenCodeも、顧客の1%以上からAPIキーなどのシークレットが盗まれたと公表しました。

盗まれたAIキーには実際にお金になる価値があります。攻撃者はアクセス権を転売したり、自分たちの処理であなたの利用枠を使い切ったりします。研究者がLLMjackingと呼ぶ手口です。ホスティングプラットフォームは、こうしたキーを効率よく集められる場所です。何千ものアプリが、OpenAI、Anthropic、Stripe、データベースのキーを1か所にまとめて置いているからです。

Railwayの報告書には、目をそらしたくなる事実があります。変数は暗号化されていましたが、ビルドや稼働中のサービスに注入するために、プラットフォーム側は復号できなければなりません。攻撃者が適切な内部アクセスを得た時点で、保存時の暗号化は歯止めになりませんでした。これはRailwayに限った話ではありません。あなたのコードを動かすホストは、どこであってもあなたのシークレットを読めるのです。

つまり問うべきは「自分のホストは安全か？」ではありません。「明日ホストのシークレットが漏れたら、どれほどの被害になり、どれだけ早く復旧できるか？」です。

すでにいくつか「ローテーション」をクリックしていても、20分だけ時間をとってください。

1. すべてのシークレットを洗い出す。ステージングやプレビュー環境も含め、各プロジェクトと環境の変数名を一覧にします。.env.exampleがあれば、そこから始めるのがよいでしょう：

それぞれについて、何にアクセスできるキーなのかをメモします。データベース、決済プロバイダー、AIプロバイダー、メール、ストレージバケット、GitHubトークンなどです。

2. AIプロバイダーの利用状況と請求を確認する。10月20日以降に、利用量の急増や見覚えのないモデル、深夜などの不自然な時間帯のリクエストがないかを確認してください。不正利用が最初に表れやすいのはここです。

3. 手元にある監査ログを確認する。Railwayは特に、GitHubの監査ログとインストール済みアプリのアクセス権、Docker Hubなどのレジストリのログを確認するよう推奨しています。決済プロバイダーのAPIログやデータベースの接続ログもあわせて確認しましょう。

4. データベースがインターネットから到達可能か確認する。Railwayの報告書は、データベースへのパブリックネットワークアクセスを無効にするよう推奨しています。漏えいした接続文字列が誰でも接続できるデータベースを指していれば、その情報はすぐに悪用できてしまいます：

5. フロントエンドがすでに何を公開しているか確認する。今回のような侵害は、本物のシークレットと、もともと公開される前提の値とを分けて考えるきっかけになります。JavaScriptバンドルに含まれて配信されるキーは、そもそも秘密ではありません。

焦っているときにやりがちなのが、先に古いキーを失効させ、アプリがエラーを返す中で慌てて新しいキーをデプロイすることです。代わりに次の順序で進めてください：

リストは被害範囲の大きい順に処理します。決済キー、データベースの認証情報、クラウドとストレージのキー、AIプロバイダーのキー、GitHubとレジストリのトークン、そしてそれ以外のものです。Railway自身のガイダンスは10月21日より前に設定された変数を対象としており、その後の追加のアドバイスでは、GitHubの再接続と、CLIやCIの認証情報の作り直しも挙げています。

特に注意が必要なシークレットもあります：

ホストが侵害されるのを防ぐことはできません。しかし、漏えいしたシークレットの価値を下げることはできます。

キーの権限を絞る。プロバイダーが提供していれば、制限付きキーを使いましょう。チェックアウトセッションの作成しかできないStripeの制限付きキーは、フル権限のシークレットキーに比べて攻撃者にとってはるかに使い道がありません。

利用額に上限を設ける。すべてのAIプロバイダーで月間予算と利用アラートを設定しましょう。数百万円規模の想定外の請求が、1通のメールで済むようになります。

環境を分ける。本番のキーをステージングやプレビューのデプロイで使い回さないでください。環境ごとに専用の認証情報を持たせれば、1つの環境で漏えいが起きても別の環境まで明け渡すことはありません。

データベースは非公開にする。プラットフォームのプライベートネットワークを使いましょう。Supabaseを使っているなら、Row Level Securityを必ず有効にして、anonキーが漏れてもテーブルが丸見えにならないようにしてください。

アクセス可能なファイルにシークレットを置かない。Webルートにデプロイされた.envファイルは、侵害がなくてもそれだけで漏えいします。

ローテーションの手順書を今のうちに書いておく。ステップ1のリスト、上で紹介した順序、そして各キーをどこで管理しているか。そうすれば次回は、週末をつぶさずに1時間でローテーションが終わります。

デプロイしているすべてのアプリについて確認してください：

Railwayは迅速に公表し、ローテーションを促すという正しい対応をとりました。それでも、ホスティングや開発者向けプラットフォームではこうした事態が繰り返し起きています。キーが集まっている場所だからです。落ち着いて乗り切れるのは、自分がどんなシークレットを持っているかを把握し、半日で入れ替えられる開発者です。

後始末のついでに、アプリが外部から何を公開しているかも確認しておく価値があります。AppSafeは稼働中のサイトをスキャンし、JavaScriptバンドル内のAPIキー、公開された.envや.gitファイル、不足しているセキュリティヘッダーといったよくある問題を、わかりやすい修正方法とともに見つけます。AIで作ったアプリ向けのローンチチェックリストでは、その他の基本も押さえています。

すべてのローテーションが終わったら、無料のAppSafeスキャンを実行して、ほかに漏れているものがないか確かめましょう。