概要#
2026年3月30日、クラウドプラットフォームのRailwayにおいて、CDN（Content Delivery Network）の設定ミスにより、認証されたユーザーのデータが他のユーザーに表示される重大なセキュリティインシデントが発生しました。
インシデントの詳細#
発生時間と影響範囲#
障害は2026年3月30日の10:42 UTCから11:34 UTC（52分間）にわたって発生しました。影響を受けたのはRailway上のドメインの約0.05%で、CDNが無効になっているドメインでHTTP GETレスポンスが誤ってキャッシュされました。
技術的な問題#
CDNは通常、アプリケーションのコンテンツを世界中のエッジサーバーにキャッシュすることで、ユーザーへの配信速度を向上させる仕組みです。Railwayでは、CDNキャッシュはオプトイン方式で提供されており、CDNが無効なドメインは常にアプリケーションに直接リクエストを送信する設計となっています。
今回の障害は、Surrogate Keysを有効にしてドメインごとにアセットをキャッシュできるようにする設定更新の際、CDNが無効になっているドメインでも誤ってキャッシュが有効になってしまったことが原因でした。
データ漏洩の内容#
この設定ミスにより、認証されたユーザー向けのレスポンスを含む内容がエッジキャッシュに保存され、元のリクエスト送信者以外のユーザーに配信される事態が発生しました。つまり、あるユーザー向けのページが別のユーザーに表示される可能性がありました。
ただし、Origin Cache-Controlディレクティブは適切に尊重され、Set-Cookieレスポンスヘッダーはキャッシュされませんでした。しかし、明示的なキャッシュヘッダーのないほとんどのGETレスポンスがデフォルトでキャッシュされていました。
対応タイムライン#
10:42 UTC: RailwayエンジニアがCDNプロバイダーへの設定更新をデプロイ。CDNが無効なドメインで誤ってキャッシュが有効化
11:14 UTC: 内部情報とユーザーからの報告により問題を初めて特定
11:34 UTC: 変更を完全にロールバックし、グローバルでキャッシュされたアセットをすべてパージ
再発防止策#
Railwayは以下の対策を既に実装しています：
追加テスト: 本番環境への変更前に、正しいキャッシュ動作と不正なキャッシュ動作の両方をテストする追加テストの導入
段階的展開: CDNロールアウトを分単位から時間単位のアグレッシブなシャーディングに変更
開発優先度の見直し: 新機能開発よりも安全性とセキュリティを優先する方針への変更
筆者の見解#
CDNの設定ミスによる認証データの誤配信は、クラウドサービスにおいて最も深刻なセキュリティインシデントの一つです。52分間という短時間ではありましたが、ユーザーの機密情報が第三者に露出する可能性があったことは重大な問題といえるでしょう。
Railwayの迅速な対応と透明性の高いインシデント報告、そして具体的な再発防止策の実装は評価できますが、このようなインシデントがユーザーの信頼に与える影響は深刻です。クラウドサービス事業者にとって、設定変更時の厳格なテスト体制と段階的な展開プロセスの重要性を改めて示すケースとなりました。
