オンプレミスDDoS時代は終わった

PLURA

🛑 もはやオンプレミスでDDoSを防ぐ時代は終わりました。

DDoS（分散型サービス拒否攻撃）は、大規模なトラフィックを利用するボリュメトリック（Volumetric）攻撃から、
アプリケーション層（L7）攻撃まで多様化しており、主要ターゲットはウェブサービスになっています。
公開されているウェブサービスは本質的に外部トラフィックを受け入れなければならないため、
オンプレミスでこれらをすべて防ぐことは、物理的・コスト的な限界がますます大きくなっています。

✅ 結論から言えば、外部向けサービス（External-Facing）はパブリッククラウドへ移行し、
内部サービス（Internal-Facing）は専用ネットワークとポリシーで徹底的に分離すべきです。
クラウド事業者が保有する大規模なDDoS防御インフラとグローバルCDN、
さらに内部ネットワークの構造的分離によって、攻撃がそもそも到達できない設計をすることが重要です。

DDoS, オンプレミス防御の限界

1. DDoSはウェブサービスを狙う

DDoS攻撃は、以下の2つの軸で大きく分類できます。

  1. ボリューム型（Volumetric）攻撃：
    大量のトラフィックを送り、ネットワーク帯域を枯渇させたり、サーバーを過負荷状態にする。

  2. アプリケーション層（L7）攻撃：
    HTTP(S)、DNS、APIリクエストを悪用し、比較的少ないトラフィックでサーバーリソースを徐々に消耗させる。

この2種類の攻撃は、公開されたIPとURLを持つウェブサービスを主なターゲットにしています。
💡 つまり、DDoS防御の核心は「誰でもアクセス可能なウェブサービスをどう守るか」です。

2. オンプレミスDDoS防御の限界

オンプレミスに独自の防御装置（ファイアウォール、IPS、DDoS専用機器など）を設置して防ごうとすると、以下の問題が発生します。

  • 大規模トラフィックへの物理的・回線的な限界：
    攻撃量が増加すると、最終的にISP側でトラフィックを遮断するか、企業の回線帯域が枯渇し、正常なトラフィックも受信しにくくなる。

  • コスト・運用負担：
    高性能ハードウェアやライセンス費用が高額であり、維持・管理にかかる人員の負担も大きい。

  • 複合攻撃（Volumetric + L7）が続く場合、防御装置自体がボトルネックとなり、全体のサービスが麻痺するリスクがある。

💡 したがって、大規模なDDoS対策はクラウドに委託し、内部サービスと外部サービスを物理・論理的に分離することが必須です。

3. DDoS対応戦略：クラウド活用・ネットワーク分離

以下の原則に基づいて防御戦略を構築すれば、大規模攻撃がオンプレミスに到達する前にブロックできます。

🛠 (1) 外部向けサービスはパブリッククラウドで提供

  • Oracle OCI、AWS、Azure、GCPなどグローバルクラウド事業者はAnycastベースの大規模DDoS防御インフラをすでに備えています。
  • Naver CloudのDDoS防御システムも検討可能。
  • Cloudflare、Akamai、AWS Shieldなどの専用DDoS保護サービスを統合活用することで、
    攻撃トラフィックがオンプレミスに到達する前に遮断されます。
  • CDN（Content Delivery Network）を積極的に導入し、攻撃者が特定のサーバーIPを直接攻撃できないように回避/キャッシュ構造を構築。

🔥 (2) 内部で外部向けウェブサービスを直接運用しない

  • オンプレミスでウェブサーバーを運用すると、そのサーバーが攻撃の最前線になります。
  • 内部データセンターはバックエンドAPIサーバー、管理システム、コラボレーションシステムのみに使用し、
    外部公開ウェブサービスはクラウドに移行    しましょう。

🛡 (3) オンプレミスに残されたサービスはISPとの協力とNull Routingで補完

  • すべてのサービスをクラウドに移行できない場合、ISP（インターネットサービスプロバイダー）と協力し、
    攻撃元IPをNull Routingで処理することが可能です。
  • ただし、Null Routingは正常なトラフィックまで誤って遮断される可能性があるため、
    正確な攻撃パターン・ソースIPの識別が必要    です。

🔒 (4) ファイアウォールポリシーを「デフォルト拒否（Default Deny）」に設定

  • 受信（Inbound）トラフィックは基本的にブロックし、必要なサービス（ポート）のみ例外として許可。
  • SSH、RDPなどの管理ポートはVPN経由の内部専用経路を使用するZero Trust方式が推奨されます。

4. ネットワークアーキテクチャの変革：単純化と分離

DDoSを防ぐには、単にクラウド移行するだけでなく、ネットワーク全体のアーキテクチャも「サービス分離」中心に再設計する必要があります。

🌐 (5) 外部サービスネットワークと内部ネットワークの完全分離

  • VLAN/VXLAN、物理ネットワークの分離、Zero Trust Network Architecture（ZTNA）を適用し、
    外部トラフィックが内部システムに直接到達しないように設計します。
  • 外部トラフィックは クラウド（CDN・WAF） → 内部ネットワーク の経路でのみ許可し、
    外部IPが直接内部サーバーにアクセスできないように制限します。

📌 (6) ファイアウォール・セキュリティ機器のルールを単純化（100件以下の管理を目指す）

  • ポリシーが複雑になるほど、ポリシーの衝突や管理ミスが発生しやすくなります。
  • 外部公開サービスと内部ネットワークを分離することで、ファイアウォールやセキュリティルールを単純化し、管理しやすくなります。

🏗 (7) 重要度別にネットワークを分離し、DDoSの影響を最小化

  • 重要システム（データベース、主要サービス）と優先度の低いシステム（テストサーバー）を
    別のサブネット/VPCに分離することで、特定のサブネットが攻撃されても影響の拡散を防げます。
  • 外部に公開する必要があるサービスも、独立したネットワークセグメントとして構成し、
    メインインフラとは論理的に切り離すことが重要です。

5. ハイブリッド・規制対応環境向けの考慮も必要

一部の金融・公共・製造業では、規制やデータ主権の問題により、すべてのサービスをパブリッククラウドに移行できないケースがあります。
この場合でも、公開サービスのトラフィックをクラウドのScrubbing CenterやCDNで事前にフィルタリングし、
精査されたトラフィックのみオンプレミスに送るハイブリッド方式が有効です。

  • クラウドDDoS Scrubbing + 専用回線によるトラフィック伝送
  • オンプレミスWAFとクラウドWAFの二重化による段階的防御

このようにして、大量の攻撃トラフィックが直接社内ネットワークに流入しないように設計することが重要です。

6. 結論：「オンプレミスDDoS防御」だけでは不十分

💡 DDoS攻撃はL7層まで進化しており、単なる帯域攻撃を超えています。
これをオンプレミスで防ごうとすると、コスト・運用負担が急増し、最終的には回線自体が麻痺する可能性があります。

✅ DDoS対策戦略まとめ

  1. 外部向けサービスはパブリッククラウドで運用
  2. 内部システムと外部サービスをネットワーク・ポリシーで完全分離
  3. オンプレミスのサービスはNull Routing、ISP協力、ハイブリッドScrubbingで補完
  4. ファイアウォールポリシーはDefault Deny（拒否がデフォルト）を原則
  5. ネットワークアーキテクチャは単純化し、重要度別に分離
  6. 規制対応が必要な場合、ハイブリッドDDoS Scrubbing Centerを活用

📖 関連リンク

Tags