【ITニュース解説】When Cloudflare Rate Limit Locks Out Your Own Players

Cloudflareのレート制限は、Webサイトやサービスをインターネット上の脅威から守るための重要なセキュリティ機能だ。悪意のある大量のリクエスト、例えばDDoS攻撃（サービス妨害攻撃）や不正なログイン試行（クレデンシャルスタッフィング）などからサーバーを守るために利用される。しかし、このレート制限の設定を誤ると、守るべきはずの正規のユーザー、特にオンラインゲームのプレイヤーがアクセスを拒否されてしまう問題が発生することがある。

この問題の根本的な原因は、レート制限が通常、アクセス元のIPアドレスを基準にリクエスト数をカウントすることにある。多くのインターネットユーザーは、携帯電話会社のネットワーク、大学、企業のネットワークなどを通じてインターネットに接続しているが、これらのネットワークでは多数のユーザーが同じ一つのグローバルIPアドレスを共有していることが多い。これをキャリアグレードNATなどと呼ぶ。Cloudflareから見ると、同じIPアドレスから大量のリクエストが集中しているように見えるため、DDoS攻撃や不正アクセスと誤認し、正規のプレイヤーであってもブロックしてしまう。

典型的な失敗シナリオは、次のように展開する。まず、開発段階で「10秒間に同じIPアドレスから20回以上のリクエストがあったらブロックする」といったレート制限ルールを設定する。このしきい値は、少数のテスターで構成される開発環境では問題なく機能する。しかし、いざゲームのローンチ日を迎え、数百人ものプレイヤーが同じ携帯電話会社のNATネットワークから一斉にゲームに接続しようとすると、Cloudflareは彼ら全員を一つのIPアドレスからのアクセスとしてカウントする。その結果、設定されたしきい値をすぐに超えてしまい、Cloudflareは「429 Too Many Requests」というエラーを返したり、チャレンジ（人間であることの証明）を要求したりする。これにより、その地域にいる多数の正規プレイヤーが、まるで攻撃者であるかのように扱われ、ゲームをプレイできなくなる事態が発生するのだ。サポート部門には大量の問い合わせが殺到し、担当エンジニアはCloudflareの監視画面を確認する間もなく対応に追われることになる。

もちろん、この問題の解決策はレート制限を完全にオフにすることではない。ゲームサーバーはDDoS攻撃の主要な標的の一つであり、保護されていないマッチメイキングなどのエンドポイントは大きなリスクとなる。真の解決策は、悪意のあるトラフィックと、正規のユーザーによる共有IPアドレスからのトラフィックを区別できるように、レート制限の設定を工夫することだ。Cloudflareが提供する、より詳細な識別情報を使って設定を調整する必要がある。

レート制限の設定を変更する前に、いくつかの重要な前提条件を確認する必要がある。まず、Cloudflareの契約プランだ。無料プランやプロプランではIPアドレスのみでのカウントが基本だが、ビジネスプランでは「NATサポート付きIP」という機能が追加され、さらにエンタープライズプランではリクエストヘッダーやクッキー、クエリ値など、より詳細な情報をカウントキーとして利用できる「アドバンスドレート制限」が利用できる。自分のプランでどのような機能が使えるかを確認することが重要だ。次に、Cloudflareの管理画面やAPIを通じて、WAF（Webアプリケーションファイアウォール）やレート制限ルールを編集する権限を持っていることを確認する。また、設定変更が実際のトラフィックにどのような影響を与えるかを正確に把握するため、Cloudflareのログやセキュリティイベント画面を通じて、トラフィックを可視化できる環境を整えておく必要がある。さらに、ゲームサーバーのバックエンドシステムやヘルスチェックサービス、CI（継続的インテグレーション）パイプラインなど、意図的にAPIに大量アクセスする正規のシステム（高ボリュームクライアント）のIPアドレスをリストアップしておくことも重要だ。最後に、安全な展開パスを確保する。いきなり本番環境に適用するのではなく、テスト環境で試したり、エンタープライズプランであれば「ログ」アクションを使って実際にブロックせずに影響だけを記録したりする「カナリヤルール」を適用するなどの方法で、段階的に変更を進めるべきだ。

特に注意すべき点として、CloudflareがどのIPアドレスを見ているかを確認することが挙げられる。Cloudflareは、自分自身に直接接続してきたクライアントのIPアドレスを認識する。もしCloudflareの裏側に自前のロードバランサーがあっても、それは関係ない。しかし、Cloudflareのさらに手前に別のプロキシサーバーやVPN、CDNなどが存在する場合、CloudflareはそれらのプロキシのIPアドレスをクライアントIPとして認識する。そうなると、そのプロキシを利用している全てのプレイヤーが単一のカウント対象となってしまうため、レート制限のしきい値を設定する前に、この点を確実に確認する必要がある。

では、具体的な設定ステップを見ていこう。

最初のステップは、実際のカウントキーを特定することだ。レート制限ルールは、「どのリクエストを対象とするか」というマッチング条件と、「何を基準にリクエスト数を数えるか」という特性（カウントキー）の二つの部分で構成される。IPアドレスのみをカウントキーとすることが、共有IPアドレス問題の根本原因であった。より良い方法は、IPアドレスと「セッションに固有の情報」を組み合わせることだ。例えば、クライアント側で生成される一意のセッションヘッダー（例: X-Player-Session）をIPアドレスと組み合わせてカウントキーとすることで、同じIPアドレスの背後にいる複数のプレイヤーを個別の存在として識別できるようになる。ただし、ヘッダー情報はクライアント側で操作可能であるため、攻撃者が異なるセッションヘッダーを生成してレート制限を回避しようとする可能性も考慮し、IPアドレスのみを対象とした、より緩やかなバックストップルールも併用するのが賢明だ。もしヘッダーベースのカウントが契約プランで利用できない場合、ビジネスプランで提供される「IP with NAT support」機能が、共有IPアドレスの背後にいる異なるクライアントを区別するのに役立つ。

次に重要なステップは、認証済みトラフィックと未認証トラフィックを分離することだ。ゲームのAPIエンドポイントは、ログインやトークンの更新など、まだユーザーが認証されていない状態でのリクエストと、セッション認証が確立された後にゲームへの参加や結果の送信などを行うリクエストの二種類に大別できる。これらは異なる種類のセキュリティリスクを抱えており、それぞれに異なるレート制限のしきい値を適用すべきだ。ログインのような未認証のトラフィックは、クレデンシャルスタッフィング攻撃の主要なターゲットとなるため、IPアドレスベースの厳しいレート制限を適用する必要がある。一方、セッション情報を持つ認証済みのトラフィックは、セッションヘッダーなどをカウントキーに含めることで、より緩やかな制限を設定できる。ここで一つ注意が必要なのは、Cloudflareが提供する「マネージドチャレンジ」などの人間認証は、Webブラウザ環境での解決を前提としている点だ。ネイティブのゲームクライアントやランチャーがAPIを呼び出す場合、チャレンジ画面を表示して解決することができないため、実質的にはブロックと同じ結果となる。そのため、ゲームクライアントからのログインフローでは、チャレンジではなく直接ブロックするアクションを選択する方が、挙動が明確になる。

三番目のステップは、まずログモードで展開し、その後適用することだ。エンタープライズプランであれば、新しいレート制限ルールは、いきなりブロックアクションを適用するのではなく、まず「ログ」アクションで展開することを強く推奨する。ログモードでは、ルールが適用された場合にどうなるかを記録するだけで、実際にリクエストをブロックすることはない。これにより、正規のプレイヤーが意図せずブロックされることがないかを、実際のトラフィックで検証できる。ログモードが利用できないプランの場合は、最初は非常に保守的（つまり、めったにトリガーされないような緩やかな）しきい値から設定を開始し、Cloudflareのセキュリティイベントログを注意深く監視しながら、徐々にしきい値を調整していくのが良いだろう。特にゲームサーバーの場合、ルールを「ブロック」に切り替える前に、週末の夜間など、最もトラフィックが集中するピーク時間帯に十分な検証を行うことが不可欠だ。平日の静かな時間帯では問題なく見えても、ピーク時には大量の誤検知を引き起こす可能性があるため、注意が必要である。

四番目のステップは、既知のインフラを許可リストに追加することだ。ゲームサーバーのバックエンドシステムは、ヘルスチェックや地域間のデータ同期、管理者ツールなど、様々な理由で自身のAPIを呼び出すことがある。これらの正規の通信は、レート制限の対象外とすべきだ。Cloudflareのカスタムルール機能を使って、特定のIPアドレス範囲からのリクエストに対して「Skip（スキップ）」アクションを設定することで、レート制限を完全にバイパスさせることができる。このスキップルールは、レート制限ルールよりも先に処理されるフェーズに配置する必要があるため、ルールの実行順序を理解することが重要だ。ただし、WAFのマネージドルールまでスキップするかどうかは慎重に検討すべきだ。内部システムであっても、もし侵害された場合にはWAFによる保護が適用されなくなるため、そのリスクとトレードオフを考慮する必要がある。

これらの設定変更を行った後は、必ず検証とテストを行うことが不可欠だ。ダッシュボード上での確認だけでなく、具体的なテストシナリオを通じて設定が正しく機能しているかを確かめる。例えば、同じIPアドレスから異なるセッションヘッダーを使って複数のリクエストを送信し、それぞれが個別のカウンターでカウントされることを確認する。Cloudflareのセキュリティイベントログをフィルタリングして、どのリクエストがどのルールによってカウントまたはブロックされたかを確認し、期待通りの挙動になっているかを詳細にチェックする。許可リストに追加した既知のインフラからのトラフィックが、レート制限によって一切ブロックされていないことも確認する。もしブロックされている場合は、IPアドレスのリストやスキップルールの設定、有効化状況などを再確認する必要がある。また、クレデンシャルスタッフィングのような攻撃パターンと、正規のログイン集中が似たようなトラフィックパターンを示すことがあるため、ログイン経路に対して模擬的な負荷テストを実施し、設定されたレート制限が正しく機能し、正規のユーザーをブロックしないかを確認することも重要だ。

Cloudflareのレート制限は、強力な保護手段ではあるが、設定は「一度きりの作業」ではない。単一の魔法のようなしきい値に頼るのではなく、複数のルールを組み合わせて、認証済みトラフィックと未認証トラフィックを分離し、共有IPアドレスの背後のユーザーを適切に識別し、既知の正規のインフラを明示的に許可することが、適切な設定の基本となる。そして、これらの設定は、ゲームのローンチや大規模なパッチ適用、イベント開催などのタイミングに合わせて、継続的に見直し、調整していくべき「生きた設定」として扱う必要がある。そうすることで、セキュリティを確保しつつ、正規のプレイヤーが不意にサービスから締め出される事態を防ぐことができる。