なぜAPIは保護が難しいか
APIサービスの保護は従来のWebサイトより厄介です。脅威は悪意ある攻撃だけでなく、正当なユーザーによる乱用も含まれるためです。
- CAPTCHAは使えない — APIクライアントはプログラムでありブラウザではないため、人間向けの検証チャレンジはそのまま通用しません。
- 一人のテナントが全員を止める — ある顧客のバグったスクリプトがプラットフォーム全体のクォータを枯渇させます。
- 攻撃は通常トラフィックに見える — 高頻度API呼び出しは事業の通常稼働モードそのものです。
- Webhookが弱点 — コールバック端点は認証を持たないことが多く、自然な侵入経路になります。
APIプラットフォームの典型的リスク
| リスク | 症状 | 防御 |
|---|---|---|
| 端点フラッド | 単一端点への高頻度アクセス | 端点ごとのレートベースライン |
| クォータ悪用 | 意図を超えた有効キーの使用 | キー・テナントごとのクォータ制御 |
| スクレイピング | 自動ツールによる一括データ抽出 | 行動フィンガープリント＋順序解析 |
| Webhookフラッド | 偽装コールバックが内部端点を直撃 | 送信元検証＋署名検証 |
AwayDDoSがAPIをどう守るか
1. 階層制限：全体→テナント→端点
3段階のレート制御を設けます。全体でプラットフォームが圧倒されないよう、テナント単位で一人の顧客が全員を止めるのを防ぎ、端点単位で高負荷ルートを精密に保護します。いずれかの層で発動しても、他の層の通常トラフィックには影響しません。
2. マルチテナント分離と公平スケジューリング
あるテナントのトラフィックが異常でも、ポリシーはそのテナントのみに適用——他は一切影響を受けません。SaaSプラットフォームにとって重要：一人の顧客の問題が全員の障害になってはならないからです。
3. 機械学習の行動ベースライン
端点ごとの通常呼び出しパターン（QPS・パラメータ分布・送信元分布・時刻特性）をモデル化し、逸脱時に自動エスカレーション——キューイング、キャッシュ提供、再認証要求。詳細は CC攻撃とDDoSの違い を参照。
4. Webhook・コールバック保護
コールバック端点に送信元検証と署名検証を必須とし、異常呼び出しパターンにレート制限——偽装コールバックによる内部システムへの侵入を防ぎます。
APIチームが私たちを選ぶ理由
- CAPTCHAに依存しない — プログラムクライアント向けに設計し、API自動化を壊しません。
- 端点レベルの精度 — 大雑把な全体レート制限ではなく、重要ルートへの標的保護。
- 長接続とWebSocket対応 — モダンなAPIパターンをカバーします。
- 固定料金・ブラックホール化なし — API停止はすべての顧客へ連鎖するため、ブラックホール化は許容できません。
推奨導入方式
API事業は通常、DNS誘導（分単位で効果）と GRE / BGPトンネル を組み合わせ、内部サービス間通信を保護します。自社ラックでAPIを稼働させるなら、トンネルで全ポート・全プロトコルを一度にカバー。導入モデルの比較は 導入方式比較 を参照。