面接問題：レートリミットを複数IPで回避する攻撃者からAPIを守る方法

問題¶

Attackers bypass your Rate Limiting using multiple IPs. How do you protect your API in production?

解答¶

IP ベースのレートリミット単体では簡単にバイパスできる。複数の対策を組み合わせる必要がある。

1. User/Session ベースのレートリミット¶

# IP ベース（簡単にバイパスされる）
limit_by: ip_address  # 攻撃者が IP を変えれば突破

# ユーザー/セッションベース（より耐性が高い）
limit_by: user_id      # 認証済みユーザーの ID で制限
limit_by: api_key      # API キーで制限
limit_by: account_id   # アカウント単位で制限

2. フィンガープリンティング¶

User-Agent + Accept-Language + タイムゾーン + TLS fingerprint
を組み合わせてクライアントを識別する

→ IP が変わっても同一クライアントと判定できる
→ JA3/JA4 fingerprint（TLS クライアント特性）も活用可能

3. Bot 検知・CAPTCHA¶

① 行動パターン分析
   - リクエスト間隔が一定すぎる → ボットの可能性
   - マウス動作・タイピングパターンの自然さを評価

② チャレンジ・レスポンス
   - reCAPTCHA / hCaptcha / Turnstile
   - 疑わしいトラフィックだけに適用（UX を守る）

4. IP ベース対策の強化¶

# IP レピュテーション（既知の悪意ある IP を拒否）
- MaxMind GeoIP2
- AbuseIPDB API
- Cloudflare のボット管理

# ASN（Autonomous System Number）で制限
- データセンター ASN からのリクエストに厳格なルール
- 住宅用 ISP は緩め（人間のユーザーが多い）

# Anycast CDN で吸収（Cloudflare, AWS Shield）
- DDoS 規模のトラフィックはエッジで吸収

5. スライディングウィンドウ + 複合キー¶

# Redis で複合キーによるレートリミット
def rate_limit_key(request):
    return "|".join([
        request.user_id or "anon",
        request.ip_address,
        request.api_key or "",
        get_device_fingerprint(request)
    ])

# 複合キーで制限することで、IP を変えても他の要素で捕まえる

6. Adaptive Rate Limiting¶

通常時: 100 req/min 許可
怪しい兆候（大量エラー・異常パターン）: 自動的に 10 req/min に絞る

面接でのポイント¶

「IP だけでは不十分」と即座に言える
認証済みユーザーには user_id ベース、未認証には複合フィンガープリントを使うことを説明
Cloudflare / AWS WAF などのマネージドサービスの活用に触れると実務経験として評価される