DDoS Protection

解決する課題

• 公開しているサイトや API が 大量のトラフィックで飽和させられ、正規ユーザーがアクセスできなくなる リスクを避けたい
• 攻撃は 帯域を圧迫する体積型 から、正規リクエストを装うアプリケーション層攻撃 まで多様で、自前で検出・緩和の仕組みを維持するのは負担が大きい
• ピーク時の急な負荷増加とDDoS攻撃を 見分けにくく、誤検知でユーザーを遮断してしまう懸念もある
• オンプレミスやハイブリッド環境を含め、ネットワーク全体を境界で守りたい

主要概念と用語

• DDoS（分散型サービス拒否）攻撃: 多数の送信元から大量のトラフィックやリクエストを送りつけ、対象のサービスを過負荷にして利用不能にしようとする攻撃
• エニーキャストネットワーク: 同一の IP アドレスを世界中の拠点が同時に広告する仕組み。攻撃トラフィックが最寄りの拠点に自動的に分散され、単一拠点に集中しにくくなる
• ネットワーク層・トランスポート層攻撃（L3/L4）: パケット量や接続数で対象を圧迫する体積型攻撃。SYN フラッドや大量の UDP パケット送信などが代表例
• アプリケーション層攻撃（L7）: 正規の HTTP リクエストに見える要求を大量に送りつけ、アプリケーションの処理能力を消耗させる攻撃
• マネージドルールセット: ネットワーク層向けとHTTP向けにあらかじめ用意された防御ルール群。しきい値や感度を調整して自組織のトラフィック特性に合わせられる
• Advanced DDoS Protection: 標準防御に加え、より高度な検知やカスタマイズ、専任チームによる支援を提供する上位プロテクション（上位プラン向け）
• Magic Transit: オンプレミスやデータセンターのネットワーク全体をエッジで守るサービス。IP プレフィックス単位でトラフィックをエッジ経由に引き込み、DDoS 防御を適用する
• Spectrum: HTTP/HTTPS 以外の TCP/UDP アプリケーション（ゲームサーバーなど）をプロキシしつつ DDoS 防御を適用するサービス

仕様・制限・クォータ

ドメインをオレンジ雲（プロキシ有効）でオンボードすると、ネットワーク層・アプリケーション層の基本的な DDoS 防御は追加設定なしで自動的に有効になります。個別の設定を行わなくても、既知の攻撃パターンに対する緩和が常時稼働します。

より細かい制御をしたい場合は、マネージドルールセットの感度やアクション（ログ・チャレンジ・ブロックなど）を調整できます。調整可能な項目やルールの粒度はプランによって異なり、上位プランほど詳細なカスタマイズや専用の緩和ポリシーを設定できます。

Magic Transit のようにネットワーク全体を保護対象とする場合は、IP プレフィックスの登録や経路広告の設定が別途必要です。具体的な料金体系や適用範囲の詳細は変更され得るため、導入前に公式ドキュメントで最新情報を確認してください。

内部の仕組み

Cloudflare の防御は、世界中に分散したデータセンターがすべて同一の IP アドレスを広告する エニーキャストネットワーク の構造に支えられています。攻撃者が送りつけるトラフィックは自動的に最寄りの拠点に分散されるため、一箇所に攻撃が集中しにくく、各拠点は自身の処理能力の範囲で緩和を行えます。

ネットワーク層・トランスポート層の攻撃に対しては、常時トラフィックを監視し、既知の攻撃シグネチャや統計的な異常を検出すると自動的に緩和を適用します。これはオンオフを意識する必要がない透過的な防御です。

アプリケーション層の攻撃に対しては、HTTP リクエストのパターンやレート、送信元の挙動を分析し、マネージドルールセットやレート制限、ボット対策と連携して不正なリクエストを遮断します。正規のアクセス急増（フラッシュクラウド）と攻撃を区別するため、平常時のトラフィックとの比較や複数シグナルの組み合わせが用いられます。

設計パターン / ベストプラクティス

• ドメインは必ずオレンジ雲（プロキシ有効）にし、オリジンサーバーを直接インターネットに公開しない。DNS を迂回して直接叩かれると、エッジの防御を素通りされる
• オリジン側では、Cloudflare からの接続のみを許可するように送信元を制限し、直接アクセスの経路を塞ぐ
• アプリケーション層攻撃に備え、WAF やレート制限を併用し、既知の不正パターンや異常なリクエスト頻度を遮断する
• API やログインエンドポイントなど狙われやすいパスには、専用のレート制限ルールを設定する
• ネットワーク全体を保護したい場合は Magic Transit、HTTP 以外のアプリケーションを保護したい場合は Spectrum の併用を検討する
• 重要なサービスでは、標準防御に加えて Advanced DDoS Protection の要否を可用性要件と照らして評価する

運用・監視

アナリティクスやログを通じて、通過したトラフィックのうちどれだけが緩和対象になったかを可視化できます。攻撃の種類や規模、対象となったリソースを把握することで、防御ルールの妥当性を継続的に見直せます。

平常時のトラフィック特性（アクセス地域、リクエストレート、ピーク時の傾向など）を把握しておくと、しきい値の調整や誤検知の切り分けがしやすくなります。イベント通知を設定し、大規模な攻撃が検知された際に運用担当者へ確実に届くようにしておくことが重要です。

コスト

ネットワーク層・アプリケーション層の基本的な DDoS 防御は、多くのプランで追加費用なしの標準機能として提供されます。より高度な検知・カスタマイズ・専任支援を伴う上位のプロテクションは、上位プランや追加のサブスクリプションとして提供されます。

Magic Transit のようにネットワーク全体を保護対象に含める場合は、保護範囲やトラフィック量に応じた別体系の費用が発生します。具体的な料金は変更され得るため、公式の料金ページで最新情報を確認してください。

セキュリティ

DDoS 防御は可用性を守ることに主眼があり、データの機密性や完全性を保証する仕組みではありません。SQL インジェクションやクロスサイトスクリプティングといったアプリケーションの脆弱性を悪用する攻撃は、WAF やセキュアコーディングで別途対処する必要があります。

アカウント内の権限管理を適切に行い、防御ルールやマネージドルールセットの設定変更を限られたメンバーやトークンに限定することも、意図しない設定変更を防ぐうえで重要です。

関連サービス・比較

WAF はアプリケーション層のリクエスト内容を検査して不正なものを個別に遮断するサービスで、DDoS Protection と役割が異なる補完関係にあります。DDoS Protection がトラフィックの量や挙動の異常に基づく防御であるのに対し、WAF はリクエストの中身を検査します。

ハンズオン / CLI例

DDoS 防御そのものはダッシュボードや API で有効化・調整しますが、Workers を使えばリクエストの特性に応じた追加のチェックをコードで実装できます。以下は wrangler で簡単な Worker をデプロイし、動作を確認する例です。

# 1) プロジェクトを作成
npm create cloudflare@latest -- ddos-check-demo

# 2) wrangler にログイン
npx wrangler login

# 3) src/index.ts でリクエストのヘッダーやレートに応じた処理を実装後、
#    ローカルで動作確認
npx wrangler dev

# 4) 本番へデプロイ
npx wrangler deploy

# 5) デプロイ後、レスポンスを確認
curl -I https://ddos-check-demo.example.workers.dev/