【入門編】 APIゲートウェイにおけるレートリミット超過とブルートフォースの相関分析 – インシデントレスポンス & フォレンジック（DFIR）防御ガイド

こんにちは！SOC（セキュリティ・オペレーション・センター）で日夜インシデントの調査やアナリストの指揮をしている者です。

セキュリティの現場というと、「なんだか冷たくて難しい専門用語ばかりの世界だな…」と感じてしまうこと、ありませんよね。今回は、開発現場やITインフラに携わり始めたばかりのあなたに向けて、APIを守るための「レートリミット（回数制限）」と「ブルートフォース（総当たり攻撃）」の相関分析について、身近な防犯にたとえながら優しく紐解いていきたいと思います。

一歩ずつ、安全なシステム作りを学んでいきましょう！

—

1. 家の鍵と泥棒にたとえる「ブルートフォース攻撃」

皆さんの大切なご自宅の玄関を思い浮かべてみてください。頑丈な鍵がついていますよね。もし、泥棒があなたの家の合鍵を作ろうと企んだとします。

泥棒がどうやって侵入を試みるでしょうか？
1. 本物の鍵をこっそり作ろうとする。
2. あるいは、ありとあらゆる形の針金を鍵穴に差し込み、開くまでガチャガチャと猛烈な勢いで試す。

この「ありとあらゆるパターンを短時間で何度も試す行為」こそが、セキュリティの世界で言うブルートフォース（総当たり）攻撃です。

インターネットの世界では、この「玄関の鍵」にあたるのが、ログイン画面やAPI（アプリケーション・プログラミング・インターフェース）の入り口になります。「パスワードを当てるまで、1秒間に1,000回のペースでログイン試行を繰り返す」といった攻撃が、まさにこれに該当します。

2. 「レートリミット」ってなに？防犯カメラと自動シャッターの仕組み

では、そんな泥棒の猛烈なアタックに対して、私たちはどう備えればよいでしょうか。

もし、家の玄関の鍵穴に「1分間に3回以上ガチャガチャと失敗したら、自動的に10分間、鍵穴がガチッとロックされて動かなくなる仕組み」や「怪しい動きをする人を警察に通報する防犯カメラ」があったとしたらどうでしょう？泥棒は慌てて逃げ出しますよね。

この「一定時間内にやり取りできる回数に制限をかける仕組み」のことを、ITの世界ではレートリミット（Rate Limiting）と呼びます。

APIゲートウェイ（すべてのリクエストの玄関口となるシステム）は、まさにこの優秀な警備員であり防犯カメラの役割を果たしています。「おいおい、このIPアドレス、1秒間に何回アクセスしてくるんだ？怪しすぎるぞ！」と検知し、一時的にシャッターを閉める（アクセスを遮断する）のが、今回のテーマである「レートリミット超過とブルートフォースの相関分析および自動遮断」のフローになります。

—

3. レスポンスヘッダーを優しく読んでみよう

APIとやり取りするとき、サーバーは私たちに「今のあなたの利用状況はどうなっているか」をコッソリ教えてくれます。それがレスポンスヘッダーと呼ばれる目に見えないお便りです。

開発をしていると、ブラウザのデベロッパーツールなどで以下のようなアルファベットを目にしたことはありませんか？

X-RateLimit-Limit: 「あなた、この時間内に合計で何回までアクセスしていいですよ」という上限（例: 100回）
X-RateLimit-Remaining: 「あと何回アクセスできますよ」という残り回数（例: 0回になったらピンチ！）
X-RateLimit-Reset: 「あと何秒待ったら回数がリセットされますよ」という時間

もし攻撃者がこの制限を無視してガンガンリクエストを送り続け、制限を超えると、APIゲートウェイは有名なあのステータスコードを返します。

429 Too Many Requests （リクエストが多すぎます！）

この 429 エラーのログが、短時間に特定のクライアント（IPアドレス）から大量発生しているのを見つけること。これが、まさにSOCアナリストが日々行っている「ログの相関分析」の第一歩なのです。

—

4. 実践！APIゲートウェイでのレートリミットと遮断の仕組み

それでは、実際の現場でどのようにこの防御を組み立てているのか、具体的なイメージを見てみましょう。ここでは、NginxなどのWebサーバーやAPIゲートウェイでよく使われる設定の考え方を、分かりやすくコード風に表現してみます。

# --- レートリミット（回数制限）の基本設定例 ---

# 1分間（$binary_remote_addr単位）に「10回」を超えるアクセスを制限するためのゾーンを定義します
# 例えるなら「1人につき1分間に10杯までしかお代わりできないスープバー」のようなものです
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=10r/m;

server {
    listen 80;
    server_name api.yourcompany.com;

    location /api/v1/login {
        # 定義したゾーンを適用し、バースト（一時的な急増）は最大5回まで許容、
        # それを超えたらすぐに「nodelay（待たせずに即エラー）」を返します
        limit_req zone=login_limit burst=5 nodelay;

        # 制限を超えた場合に返すステータスコードを明確にします
        limit_req_status 429;

        # 通常のバックエンド処理へ転送
        proxy_pass http://backend_auth_servers;
    }
}

ログを監視して「自動遮断」につなげるフロー

上記の設定で 429 Too Many Requests が発生すると、アクセスログに記録されます。SOCの現場では、このログをリアルタイムで監視（SIEMツールなどを使用）し、次のような自動化スクリプトや連携フローを動かします。

1. 検知: 「IPアドレス 203.0.113.50 から、過去1分間に 429 エラーが50回も発生している！」とログ監視システムがアラートを上げる。
2. 判定: 「これは明らかにブルートフォース攻撃（総当たりによる不正ログイン試行）だ」と判断する。
3. 自動遮断: 連携スクリプトがファイアウォールやAPIゲートウェイに対し、そのIPアドレスからの通信を即座にブロック（拒否）するよう命令を飛ばす。

この一連の流れがスムーズに自動化されているかどうかが、夜間の安心な睡眠を確保できるかどうかの分かれ道になります。

—

まとめとこれからのステップ

今回は、APIゲートウェイにおけるレートリミット超過とブルートフォース攻撃の相関分析について、身近な防犯にたとえて解説しました。

ブルートフォース攻撃 ＝玄関の鍵穴を不正に何回もガチャガチャ試す行為。
レートリミット ＝回数制限を設けて、怪しい動きを足止めする防犯システム。
相関分析と自動遮断 ＝「429エラー」の多発をいち早く察知し、自動で門前払いするスマートな警備。

難しく思えるセキュリティの仕組みも、私たちの日常生活の防犯に置き換えてみると、グッと理解しやすくなったのではないでしょうか。「なぜこの制限が必要なのか」「ログをどう読むべきか」という視点を持つことが、信頼されるエンジニアへの第一歩です。

一歩ずつ、安全で快適なシステムを作っていきましょう！それではまた次回のブログでお会いしましょう。