攻撃か正常か、を見極めるRate Limiting（レート制限）

攻撃されていることは確かでも、その攻撃の名前はおろか、それがどのような種類の攻撃なのかも分からないので対応が難しい、といった状況に陥ることも考えられます。たとえば、以下のような状況です。

• ログイン画面へ短時間に何百回もアクセスが試行される
• 問い合わせフォームが連続で送信される
• 商品検索やAPIが、通常では考えられない頻度で繰り返し呼び出される

このような現象に直面した際、攻撃の名前や手法を特定できなくても、「このアクセス回数は明らかに異常だ」という判断は可能でしょう。こうした「アクセスの速度や頻度」を軸に、過剰な通信を制限する仕組みが「Rate Limiting（レート制限）」です。

Rate Limitingでは、しきい値を設定し、それより頻度が高ければ攻撃、低ければ正当なアクセスと判断する仕組みです。しかし、最初にしきい値を設定すれば、後は放置しておけるというものではありません。

どの程度までが正常な利用量とみなすことができるのかを、まず判断し、制限ルールを設定、ログで正当なユーザーへの影響を確認しながら調整を重ねる。ここまで含めた継続的な「ログ運用」を実施して、初めてWebサイトの安定と安全を守ることができるのです。

この節では、Rate Limitingの基本的な考え方、守るべき入口の整理、探るべきログ運用のステップについて分かりやすく解説します。

通信の中身ではなく「頻度」を見るRate Limiting

ここで改めて、代表的なWebセキュリティの手法、WAF（Web Application Firewall）とRate Limitingの違いを簡単に整理しておきましょう。

• WAF： 送信された文字やコードなど「通信の中身（リクエストデータ）」を検査し、危険な攻撃命令が含まれていないかを判断
• Rate Limiting： 一定時間内に同じ操作が「何回繰り返されているか（アクセス頻度）」を計測し、過剰な通信を制限

例えば、1回のログイン試行そのものは、まったく正常な、日常的な通信です。通信データの中身をチェックするWAFのルールでも、問題なしと判定されるはずです。しかし、同じユーザーから1分間に何百回もログインが試行されているとすれば、それは普通の人間によるアクセスとは考えられません。

このような場合が、Rate Limitingの出番です。1回の通信だけでは異常と判断できなくても、「短時間での繰り返し」に着目することで不正なアクセスを見つけ出せる点に、Rate Limitingの大きな価値があります。

出典： Cloudflare Docs: Rate limiting rules

処理やコストが発生する「特定の入口」に絞って適用する

Rate Limitingは、Webサイト全体に一律で同じ制限をかけるものではありません。優先して守るべきなのは、アクセスされるたびに、データベースへの問い合わせなど、サーバー側の処理やコストが発生する「重要な」処理の入口です。次のようなものが挙げられます。

• ログイン・パスワード再設定画面（不正ログイン、Credential Stuffing対策）
• 問い合わせフォーム、会員登録画面（スパム連続投稿・アカウント大量作成対策）
• 商品検索、サイト内検索機能（サーバー負荷高騰、スクレイピング対策）
• カート投入、購入予約処理（買い占めBot対策）
• 各種API（APIの過剰利用、乱用対策）

「Webサイト内のどのページか」というURLだけで判断するのではなく、「そのアクセスによって、サーバーやデータベースでどんな処理が実行されるのか」という点までを考慮して設定対象を絞り込むことが基本です。

出典： Cloudflare Docs: Rate limiting best practices

「何回で止めるべきか」は、サイトの平常値（ログ）から割り出す

Rate Limitingの導入で最も悩ましいのが、「何回以上のアクセスで制限をかけるか」という数値（しきい値）の決め方です。たとえば、「1分間に10回」、あるいは「100回」、「1,000回」といった、一般的なWebサイトに共通する適切な数値は存在しません。

問い合わせフォームであれば、同じ人物が1分間に何十回も送信することは通常は考えられません。しかし、ECサイトの商品検索やAPIの呼び出しであれば、短時間に連続して複数回呼び出されても、正常な範囲の動作であることが多いからです。

そのため、数値（しきい値）を決める際は、必ず「平常時のログ分析」から始めるべきです。Cloudflareでは、通信全体の傾向を把握できる分析ツール、「Security Analytics」や、リクエスト頻度の分析機能などを活用して、「一般のユーザーは通常どれくらいの頻度でアクセスしているのか」を把握することができます。この平常値をベースにして、正当な利用を阻害しない安全な境界線を引くことができます。

出典： Cloudflare Docs: Find appropriate rate limit

正当なユーザーを不当に扱わないための設定テクニック

Rate Limitingを設定する際、注意しなければならないのが、正当なアクセスまで検出して遮断してしまう「誤検知」です。

例えば、単純に「同じIPアドレス」というだけでアクセス回数をカウントすると、正当なユーザーを巻き込んで遮断してしまうリスクがあります。というのも、会社や学校、ホテル、スマホの携帯キャリア回線など、複数のユーザーが同じ外部IPアドレスを共有している場合が多いからです。

このようなリスクを回避するために、以下のような設定テクニックを活用して、誤検知をできるだけ防ぐことが可能です。

失敗したレスポンス（エラーコード）だけをカウントする

例えばログイン画面への攻撃を防ぐ場合、ログインが「成功」した場合も含めた全アクセスを数えるのではなく、401（未認証）や403（禁止）などの「認証失敗」のレスポンスだけをカウントするようにします。これにより、正常にログインできている一般ユーザーに影響を与えることなく、試行錯誤を繰り返す不正アクセスだけに的を絞って制限できます。

IP以外の識別条件（Cookie、APIキー、ヘッダー）を組み合わせる

CloudflareのRate Limitingでは、IPアドレスだけでなく、Cookie、HTTPヘッダー、APIキー、セッション情報などを組み合わせたカウントが可能です。認証付きAPIであれば、IPアドレス単位ではなく「APIキー単位」で制限をかけることで、より正確で安全な制御を実現できます。

出典： Cloudflare Docs: Rate limiting rules

ログの使い分け：Security AnalyticsとSecurity Events

Rate Limitingを安全に運用するには、Cloudflareが提供する2種類のログ・分析ツールを、役割、用途に応じて使い分ける必要があります。

• Security Analytics（全体を見る）
  • ブロックされた通信だけでなく、正当なアクセスも含めた通信全体を可視化。「平常時のアクセス量」、「ピーク時の頻度」、「特定のURLへの集中度」などを確認し、何が普通の状態なのか（平常値）を把握
• Security Events（異常を見る）
  • WAFやRate Limitingが実際に作動し、ブロック（Block）や確認処理（Challenge）を実行した通信の詳細ログを表示。ルールが正しく攻撃を捉えているか、誤検知が発生していないかを確認

Security Analyticsによって平常時の状態を調べてルールを設定し、Security Eventsによって発生したイベントを確認してチューニングする、というログ運用の循環を作ることが大切です。

出典： Cloudflare Docs: Security Analytics

出典： Cloudflare Docs: Security Events

いきなりブロックせず、Managed Challengeを活用した段階的な運用を

Rate Limitingの運用で注意すべきは、最初から厳しいしきい値を設定し、それを超えたら即Block（遮断）、ということのないようにすることです。

テレビの番組で取り上げられたり、大規模な広告キャンペーンを打った後、あるいはSNSでの拡散、新商品の発売時など、プロモーション活動などによって一時的にアクセスが急増することもあります。昨日までの平均アクセス数だけを基準にして厳しいしきい値を設定してBlockしてしまうと、せっかく訪れてくれた新規購入客やファンからのアクセスを弾いてしまう大きな「機会損失」につながりかねません。

そうならないためには、以下のような段階的なアプローチが推奨されます。

1. ログモード（Log）で設定し、平常時のログと突き合わせる
2. 指定回数を超えた通信に対して「Managed Challenge（自動確認）」を出す
3. さらに異常な頻度で連続アクセスしてくる通信のみを「Block（遮断）」する

「Managed Challenge」を挟むことで、人間のユーザーであれば自動的な確認処理（あるいは簡易判定）を経て、正常にアクセスを継続でき、自動化された攻撃プログラム（Bot）だけを効果的に足止めすることが可能となります。

DOMOの視点

数字を設定するだけではなく、「正常の基準」を作る運用を

DOMOとしてRate Limitingの設定を検討する際には、はじめから「何回でブロックしましょう」という数字を提示することはありません。まず確認させていただくのは、「どの入口を守り、日常的に誰がログを確認する運用体制になっているか」という点です。

ログイン画面、問い合わせフォーム、商品検索、APIでは、それぞれ「正常」とみなされるアクセス頻度がまったく異なります。全社一律の数字を設定するのではなく、事業の入口ごとに正常な境界線を定義することから始めます。

また、「誰が」ログやアラートを確認し、どのような「条件」で数値を調整するのか、担当者と運用フローを決めておくことも非常に重要です。

Webサイトの成長やマーケティング施策に伴って、アクセスの傾向は常に変化します。Rate Limitingは、一度設定して終わりにするのではなく、ログを見ながら自社の「正常の基準」を更新し続けるセキュリティ運用なのです。

出典： Cloudflare Docs: Alerts for security events

まとめ

Rate Limitingは、通信データの中身ではなく「アクセスの頻度、回数」を基準として、過剰な連続処理や攻撃を抑え込む仕組みです。以下のような運用が求められます。

• 特定の入口への適用： ログイン、フォーム、商品検索、APIなど、サーバー負荷やコストに直結する場所に設定する
• しきい値の決定： 平常時のログ（Security Analytics）からトラフィックを観察し、しきい値を決める
• 制御の工夫： 失敗レスポンスのカウントやAPIキー単位の制御を活用する
• 段階的な調整： いきなりブロックせず、ログの内容を検討しながら、Managed Challenge等を活用しつつ調整を重ねる
• 継続的な運用： ログの確認担当者を定め、定めたフローに従って継続的に運用する

まずは自社のログイン画面やフォームにおいて、現在どの程度の頻度のアクセスが発生しているか、ログの観察から始めましょう。

覚えておきたい用語

• Rate Limiting： 一定時間内のアクセス回数などに上限を設け、過剰な利用を制限する仕組み
• Security Analytics： Cloudflareへ届くHTTP通信全体を分析する機能
• Security Events： Cloudflareのセキュリティ機能が反応した通信を確認する機能
• Credential Stuffing： 流出したIDとパスワードを使ってログインを大量に試す攻撃
• Managed Challenge： Cloudflareが通信状況に応じて追加確認方法を判断する処理
• APIキー： API利用者やアプリケーションを識別、認証するために使われる文字列
• サンプリング： すべてではなく一部のデータを抽出して傾向を見る方法
• 誤検知： 正当なアクセスを攻撃や異常だと誤って判断すること