【テクニカル・上級編】レート制限（Rate Limiting）によるブルートフォース攻撃の緩和 – アプリケーションセキュリティ & 安全な開発防御ガイド

レート制限の「その先」：分散型ブルートフォースと戦うためのアーキテクト的思考

多くの開発者が「レート制限」を実装する際、RedisのINCRコマンドとEXPIREを組み合わせて、IPアドレスごとにリクエスト数をカウントする実装で満足している。だが、実戦の現場において、攻撃者はもはや単一のIPからは来ない。数千台のプロキシネットワークや、IPレピュテーションを通過する住宅用IP（Residential Proxies）を駆使する彼らにとって、単純なIPベースの制限など「門番がいないのと同じ」だ。

今日は、OWASP Top 10の「不十分な認証（Broken Access Control）」を補完する、より深いレベルでのレート制限の設計論について紐解いていく。

—

1. メモリとパケットの観点から見た「制限の境界」

レート制限の本質は、アプリケーション層（L7）でのトラフィック制御にあるが、真に堅牢な設計はL4のコネクション追跡とメモリ管理に依存する。

攻撃者が狙うのは、認証処理そのものよりも、「認証処理を呼び出す前のハンドシェイク」や「不正なリクエストを処理する際のメモリ確保」だ。たとえば、JWTの検証処理において、不正な署名を持った巨大なペイロードを次々と送りつけられれば、検証ロジックが消費するCPUとメモリでDoS状態に陥る。

対策の勘所：

初期チェックのオフロード: 高コストなパース処理の前に、ヘッダーの整合性チェックと、最小限のレート制限バッファをL7ゲートウェイ（EnvoyやNginx）で即座に処理せよ。
コネクションの枯渇: TCPバックログとSO_REUSEADDRの挙動を理解し、接続数制限をグローバルに設定しなければ、レート制限が機能する前にOSレベルで接続を拒否される「意図しないDoS」が発生する。

—

2. 実践的な段階的ブロッキング戦略：IP+IDのハイブリッド設計

単一のIP制限は、NAT環境下のユーザーを切り捨てる可能性がある。一方でユーザーIDのみの制限は、セッションハイジャックやアカウント乗っ取りを助長する。推奨されるのは、階層型の「スコアリング制」だ。

実装例：Redis + Luaスクリプトによるアトミックな制御

RedisのLuaスクリプトは、Race Condition（競合状態）を避けるために必須だ。クライアントがリクエストを送るたびに、複数のキーを評価する。

— rate_limit.lua: クライアントIDとIPを組み合わせて評価
local key = KEYS[1] — 例: “rl:user:12345”
local limit = tonumber(ARGV[1]) — 許容回数
local window = tonumber(ARGV[2]) — 秒数

local current = redis.call(“INCR”, key)
if current == 1 then
redis.call(“EXPIRE”, key, window)
end

if current > limit then
return 0 — 制限超過
else
return 1 — 通過
end

このロジックを、APIゲートウェイのプラグインとして組み込み、さらに「異常検知」を組み合わせる。具体的には、失敗した認証の累積値が一定を超えたら、そのユーザーIDに対するCAPTCHAチャレンジを強制するといった段階的措置を自動化するのだ。

—

3. 生成AI時代のプロンプト・インジェクションとレート制限の新たな役割

昨今のLLMアプリケーション開発において、レート制限の定義は「リクエスト回数」から「トークン消費量」へとシフトしている。

プロンプト・インジェクション攻撃は、無限ループを誘発するような再帰的プロンプトによって、バックエンドの推論コストを食いつぶすことが可能だ。これに対するガードレイルとして、以下のアーキテクチャが求められる。

トークンバケットアルゴリズムの適用: 消費予測トークン量に基づき、セッション単位で動的な制限を行う。
セマンティック・レートリミッティング: リクエストの「内容」を軽量なモデルでベクトル化し、過去の攻撃パターンと類似度が高い場合は、リクエスト数に関わらず「即時遮断」または「低優先度キュー」へルーティングする。

—

4. 監査とインシデントハンドリングの極意

最後に、セキュリティアーキテクトとして最も重要なのは「観測可能性（Observability）」だ。レート制限が発動したとき、それは攻撃の兆候なのか、単なる設定ミスなのかを即座に判別しなければならない。

ログの粒度: IPアドレス、User-Agentだけでなく、JA3フィンガープリントをログに含めることを強く推奨する。IPが回転しても、攻撃者のツール（Python Requestsライブラリや特定のGo HTTPクライアント）のフィンガープリントは変わらないことが多い。
耐量子暗号への布石: 今後は通信の傍受によるセッション奪取を考慮し、TLS 1.3の導入はもちろん、将来的なポスト量子暗号（PQC）への移行を見据え、暗号化ライブラリの抽象化をコードベースで維持しておくこと。

結びに代えて

レート制限は単なる「防御」ではない。それは、システムという限られたリソースを守るための「経済圏のルール作り」だ。

脆弱性を見つけた時、それをパッチで塞ぐのはエンジニアの仕事だが、その脆弱性が「なぜそこに存在するのか」という設計思想に踏み込むのがアーキテクトの仕事だ。攻撃者は常にシステムの境界線の「最も脆い場所」を探している。その場所がどこか、コードを書く前に一度、攻撃者の視点で自分のAPIを呼び出してみてほしい。

次回のブログでは、APIキーの漏洩を検知し、自動的にローテーションさせる「自己修復型インフラ」の設計について深掘りする予定だ。現場の泥臭いログの山と格闘している同志たちへ。健闘を祈る。