- 1. DDoS攻撃の脅威(基礎知識編):なぜ「分散」すると防御困難なのか
- 2. DDoS攻撃の体系的分類(技術分析編):L3/L4攻撃とL7攻撃
- 3. DDoS対策の最適解(アーキテクチャ編):セキュリティ担当者の「結論」
- 4. 実務としてのDDoS対策(運用・体制編)
- 結論:防御から「サイバー・レジリエンス」への意識改革
東証プライム企業で情報システム部のセキュリティ担当をしている、城咲子です。私はCISSPや登録セキスペ(情報処理安全確保支援士)の資格を持ち、日々、企業のセキュリティ戦略と向き合っています。
今日は、サイバー攻撃の中でも最も古典的でありながら、今、最も「変貌」を遂げている脅威、「DDoS攻撃」について、企業のセキュリティ担当者、そして経営層が知るべき「すべて」を解説します。
単なる「Webサイトが重くなる」といった迷惑行為のレベルではありません。2025年のDDoS攻撃は、AIとIoT、そして地政学的な意図と結びつき、企業の事業継続性を根幹から揺るがす「経営リスク」そのものへと進化しています。
独立行政法人情報処理推進機構(IPA)が発表した「情報セキュリティ10大脅威 2025」において、DDoS攻撃が組織編の第8位に「再浮上」しました 3。
なぜ、一度はランキング圏外に去った古典的な攻撃が、ランサムウェアや標的型攻撃と並んで、再びランクインしたのでしょうか。
それは、攻撃の「質」と「量」が、従来の防御の常識を遥かに超えるレベルに進化したからです。
- AIによる攻撃の適応化: 防御側の対策をAIがリアルタイムで学習し、回避する
4 - 5GとIoTによる攻撃リソースの爆発: 脆弱なIoT機器
5が5G網5に接続され、わずかな台数で「テラビット級」5の攻撃トラフィックを生み出す。 - 地政学リスクとの連動: 2024年10月、日本の複数の組織がプロロシア派ハクティビスト集団「NoName057(16)」などによるDDoS攻撃を受けました
7。これは政治的動機に基づく明確な「サイバー兵器」としての利用例です。
この記事は、DDoS攻撃に関する「まとめ記事」です。 セキュリティ担当者としての実務経験(Experience)と専門知識(Expertise)に基づき、DDoS攻撃の基礎知識から、競合サイトでは語られない「なぜCDNとWAFの“階層型防御”が最強なのか」「なぜオンプレミス型対策は“気休め”でしかないのか」といった技術的な本質、そして「インシデントレスポンス体制」という組織論まで、網羅的に解説します。
この記事を読み終える頃には、あなたのDDoS対策に関する解像度は飛躍的に向上しているはずです。
1. DDoS攻撃の脅威(基礎知識編):なぜ「分散」すると防御困難なのか
まず、DDoS攻撃が「DoS攻撃」と何が違うのか、そしてなぜそれが「企業の責任」問題にまで発展するのか、基本を抑えましょう。
1-1. DoS攻撃とDDoS攻撃の根本的な違い
どちらも「サービスを利用不能にする」目的は同じですが、「実行犯の数」が決定的に異なります 1。
DoS (Denial of Service) 攻撃:
- 「1対1」の攻撃。攻撃者1人が、ターゲット1台に過剰なリクエストを送る
2。 - 防御: 攻撃元のIPアドレスが単一(または少数)なため、そのIPを特定してブロックすれば、比較的容易に対処可能
1。
- 「1対1」の攻撃。攻撃者1人が、ターゲット1台に過剰なリクエストを送る
DDoS (Distributed Denial of Service) 攻撃:
- 「多対1」の攻撃。「分散型」の名の通り、攻撃者がマルウェア(ボット)に感染させて乗っ取った何百、何千、何百万台
2ものデバイス(ボットネット)から、一斉に攻撃を仕掛ける。 - 防御: 攻撃元のIPアドレスが膨大に分散しているため、個別のIPブロックでは全く追いつきません
1。これがDDoS攻撃の防御を著しく困難にする最大の要因です。
- 「多対1」の攻撃。「分散型」の名の通り、攻撃者がマルウェア(ボット)に感染させて乗っ取った何百、何千、何百万台
1-2. 攻撃のメカニズム(1):攻撃基盤「ボットネット」
DDoS攻撃の「弾薬庫」となるのが「ボットネット(Botnet)」です 2。
これは、攻撃者がマルウェア(ボット)に感染させ、遠隔操作できるようになったデバイス(PC、サーバー、スマホ、IoT機器)のネットワーク(集合体)を指します 9。
1. 感染: 攻撃者はOSの脆弱性 9 やフィッシングメール 9 を通じて、あなたの会社のPCや、自宅のルーター、Webカメラにボットを侵入させます。
2. C&Cサーバーへの接続: ボットは感染を気づかせないよう静かに動作し、攻撃者の司令塔である「C&C (Command & Control) サーバー」 9 に接続し、「ゾンビ」として命令待機状態になります。
3. 攻撃実行: 攻撃者はC&Cサーバー経由で、世界中に散らばる何百万台のゾンビに対し、「一斉にあのサイトを攻撃しろ」と命令を下します 2。
1-3. 攻撃のメカニズム(2):攻撃力を増幅させる「リフレクション攻撃」
ボットネットの攻撃力をさらに数十倍、数百倍に増幅させる巧妙な手口が「リフレクション(反射・増幅)攻撃」です 10。
これは、攻撃者がターゲットを直接狙うのではなく、インターネット上に存在する「無関係な第三者のサーバー」を「反射台(リフレクター)」として悪用する手口です 10。
1. IPアドレスの偽装: 攻撃者は、ボットネットから送るリクエストの「送信元IPアドレス」を、自分のものではなく「攻撃対象(ターゲット)のIPアドレス」に偽装します 10。
2. リフレクターへの送信: この偽装パケットを、インターネット上で設定不備のまま公開されているサーバー(リフレクター)に送りつけます。この時のリクエストは「小さな」サイズです 10。
3. 反射・増幅: リフレクターは、偽装されたリクエストとは知らずに処理し、偽装された送信元IPアドレス(=ターゲット)に対し、「巨大な」応答パケットを返信します 10。
4. ターゲットへの集中: ターゲットのサーバーには、世界中のリフレクターから、何倍にも増幅された大量のパケットが集中砲火として届き、ネットワーク帯域が枯渇します。
1-4. 【重要】企業の「社会的責任」:加害者(踏み台)にならないために
このリフレクション攻撃の仕組みは、セキュリティ担当者に非常に重い事実を突きつけます。
【ファクトに基づく考察(城咲子の分析)】
DDoS対策とは、「被害者にならない」ための防御(インバウンド)だけではありません。 自社が管理するサーバーやネットワーク機器の設定不備(例:オープンリゾルバ11、SNMPの外部公開10)によって、自社が「リフレクター(反射台)」として攻撃に加担してしまう、「加害者(踏み台)」になるリスク(アウトバウンド)を防ぐことも、同等に重要なのです。JPCERT/CCやIPAが「オープンリゾルバの停止」
11を強く推奨しているのはこのためです。自社のIPアドレスが「踏み台」としてDDoS攻撃に利用された場合、そのIPはブラックリストに登録され、自社の「IPレピュテーション(信頼性)」は著しく毀損します。結果として、自社から発信する重要なビジネスメールが取引先に届かなくなるなど、事業継続に深刻な影響を及ぼしかねません。
これはもはや技術的な問題ではなく、企業の社会的責任(CSR)とレピュテーションリスク管理の問題です。
2. DDoS攻撃の体系的分類(技術分析編):L3/L4攻撃とL7攻撃
DDoS攻撃と一口に言っても、狙う「層(レイヤ)」によって、その性質と対策は全く異なります。この違いを理解することが、後述する「CDN」と「WAF」の役割を理解する鍵となります。
2-1. なぜレイヤ(L3, L4, L7)での分類が重要なのか
OSI参照モデルに基づき、DDoS攻撃は大きく2つに大別されます。
L3/L4 (ネットワーク層 / トランスポート層) の攻撃:
- 狙い: 企業のインターネット回線の「帯域幅」や「ネットワーク機器(ファイアウォール等)」のリソース枯渇
13。 - 特徴: BPS (Bits Per Second) や PPS (Packets Per Second) といった「量」で計測される、「ボリューム型攻撃」
13。 * 例: SYNフラッド、UDPフラッド、リフレクション攻撃
- 狙い: 企業のインターネット回線の「帯域幅」や「ネットワーク機器(ファイアウォール等)」のリソース枯渇
L7 (アプリケーション層) の攻撃:
- 狙い: Webサーバーやデータベースといった「アプリケーション」のリソース(CPU、メモリ等)の枯渇
13。 - 特徴: RPS (Requests Per Second) で計測される「質」の攻撃。トラフィック量自体は少なくても、サーバーに高い負荷をかける「効率的な」攻撃
14。 - 例: HTTPフラッド、Slowloris
- 狙い: Webサーバーやデータベースといった「アプリケーション」のリソース(CPU、メモリ等)の枯渇
重要なポイントは、「L3/L4対策」と「L7対策」は、全く別物であるということです。 L3/L4対策(例:大容量回線)はL7攻撃(Slowloris)を防げませんし、L7対策(例:WAF)はL3/L4の帯域飽和(UDPフラッド)を防げません。
2-2. L3/L4 (ネットワーク/トランスポート層) の攻撃
インフラの「パイプ」を、大量のゴミ(パケット)で物理的に詰まらせる攻撃です。
SYNフラッド攻撃 (SYN Flood):
- TCP接続の「3ウェイハンドシェイク」という正規のプロセスを悪用する、最も古典的かつ効果的な攻撃
1。 * 攻撃者は、IPを偽装した接続要求(SYN)16だけを大量に送りつけます。 - サーバーは、接続リソースを確保して応答(SYN/ACK)を返しますが、偽装されているため最後の応答(ACK)が永遠に来ません
16。 - サーバーの接続待機テーブルは、この「半開接続(Half-Open)」
15で瞬く間に埋め尽くされ、正規のユーザーが接続できなくなります。
- TCP接続の「3ウェイハンドシェイク」という正規のプロセスを悪用する、最も古典的かつ効果的な攻撃
UDPフラッド攻撃 (UDP Flood):
- 接続確認が不要なUDPプロトコル
1の特性を悪用し、大量のUDPパケットを一方的に送りつけます15。 - サーバーは受信したパケットの処理に追われ、同時にネットワーク帯域全体が飽和します。
- 接続確認が不要なUDPプロトコル
リフレクション(増幅)攻撃:
- 前述のDNS
11やSNMP10などを悪用した攻撃。その主な目的はターゲットのネットワーク帯域(L3/L4)を飽和させることであるため、ここに分類されます。
- 前述のDNS
2-3. L7 (アプリケーション層) の攻撃
「量」ではなく「質」でサーバーをダウンさせる、より巧妙な攻撃です。一見すると正規のアクセスと見分けがつきにくいのが特徴です 2。
HTTPフラッド攻撃 (HTTP Flood):
- ボットネットから、正規のHTTPリクエスト(GETやPOST)を大量に送信する攻撃
1。 - 特に、検索機能やログインフォーム、動的コンテンツ生成ページ(.phpなど)
18といった、サーバーやデータベースに負荷がかかる(キャッシュが効かない)17処理を意図的に狙い撃ちし、CPUやメモリを枯渇させます。
- ボットネットから、正規のHTTPリクエスト(GETやPOST)を大量に送信する攻撃
Slow HTTP DoS Attack (Slowlorisなど):
- 「Low and Slow(低速・少量)」攻撃
15の代表格。 - HTTPフラッドとは逆に、大量のリクエストを送りません。
- 「意図的に“超”低速な」リクエストを送信します
15。接続を確立した後、データを数秒に1バイトといったペースで送り続け、リクエストを完了させません。 - 多くのWebサーバーは、リクエストが完了するまで接続セッションを保持し続けます。攻撃者はこの仕組みを悪用し、ごく少量のトラフィックでサーバーの最大同時接続数をすべて占有(ハングアップ)
15させ、正規のユーザーを締め出します。
- 「Low and Slow(低速・少量)」攻撃
【まとめ】DDoS攻撃手法のレイヤ別比較
| レイヤ | 主な攻撃手法 | 攻撃対象リソース | 攻撃の特性(指標) | 防御の主な考え方 |
|---|---|---|---|---|
| L3/L4 | SYNフラッド 1 |
ネットワーク帯域、FW/ルーターのセッション | 「量」:大量のパケット(高PPS)、大容量トラフィック(高BPS) | トラフィックの「吸収」と「分散」(大容量回線、CDN、DDoS専用ミティゲーションサービス) |
UDPフラッド 1 |
ネットワーク帯域 | 「量」:大容量トラフィック(高BPS) | 同上 | |
リフレクション攻撃 10 |
ネットワーク帯域 | 「量」:増幅された大容量トラフィック(高BPS) | 同上、およびリフレクター(踏み台)の通信遮断 | |
| L7 | HTTPフラッド 17 |
Webサーバー(CPU、メモリ)、DB接続 | 「質」:大量のリクエスト(高RPS)、正規アクセスとの判別困難 | リクエストの「内容」と「振る舞い」の検査(WAF)、レートリミット |
Slow HTTP DoS (Slowloris) 15 |
Webサーバーの同時接続セッション | 「質」:低速・少量のトラフィック、長時間のセッション占有 | 接続タイムアウト値の厳格化、振る舞い検知(WAF) |
3. DDoS対策の最適解(アーキテクチャ編):セキュリティ担当者の「結論」
DDoS対策の技術論において、実務担当者が最も悩むのが「CDNとWAF、どちらを導入すべきか?」という問題です。そして、ベンダーのセールストークに惑わされがちなのが「オンプレミス型DDoS対策機器」の是非です。
ここでは、企業のセキュリティ担当者として、この2つの問いに明確な「結論」を提示します。
3-1. 陥りがちな誤解:「CDN」と「WAF」の根本的な役割の違い
CDNとWAFは、どちらもWebサイトの手前に配置されますが、その「主目的」と「得意分野」は全く異なります。
CDN (Content Delivery Network):
- 主目的: Webサイトの表示速度向上と、オリジンサーバーの負荷軽減
21。 - 仕組み: 画像やCSSなどの「キャッシュ可能な」コンテンツを、世界中に分散配置したエッジサーバーにコピー(キャッシュ)し、ユーザーに最も近いサーバーから配信します
21。 - DDoS対策(副次的): この「分散」アーキテクチャは、L3/L4のボリューム型攻撃に「副次的」に非常に有効です
21。攻撃トラフィックは、オリジンサーバーという「一点」ではなく、CDN事業者の巨大なネットワーク帯域(数T〜数十Tbps)22に「分散」・「吸収」されます。 - 限界: CDNはセキュリティ専用ツールではありません
22。通信の「内容」までは深く検査しないため、L7攻撃(HTTPフラッドやSlowloris)の多くは「正規のアクセス」としてオリジンサーバーに通過させてしまいます21。
- 主目的: Webサイトの表示速度向上と、オリジンサーバーの負荷軽減
WAF (Web Application Firewall):
- 主目的: L7のアプリケーション層攻撃からWebアプリケーションを保護するセキュリティ専用ツール
21。 - 仕組み: HTTPリクエストの「内容」を詳細に検査し、SQLインジェクションやXSSといった脆弱性を突く攻撃を遮断します
22。 - DDoS対策: L7の検査に特化しているため、L7 DDoS攻撃(HTTPフラッド、Slowlorisなど)の検知・遮断にも有効です
21。「同一IPからの異常な頻度のPOSTリクエスト」などを振る舞い検知します。 - 限界: WAFはL7専用であり、L3/L4のボリューム型攻撃には全くの無力です
21。WAFに通信が届く手前のネットワーク帯域が飽和すれば、WAFは何もできません。
- 主目的: L7のアプリケーション層攻撃からWebアプリケーションを保護するセキュリティ専用ツール
【関連記事】WAFとCDNの役割の違いと連携の重要性
- CDNがどうWebサイトを高速化(SEO改善)するか、その基本的な仕組みについては、こちらの記事で詳しく解説しています。
- WAFがL7攻撃(SQLインジェクションなど)をどう防ぐのか、その仕組みと「誤検知」問題については、こちらの記事が専門です。
3-2. 最強の構成:「CDN → WAF → オリジンサーバー」の階層型防御
L3/L4に強いがL7に弱い「CDN」と、L7に強いがL3/L4に弱い「WAF」。
【ファクトに基づく考察(城咲子の分析)】
この明確な補完関係こそが、両者を「併用」すべき最大の理由です22。現代のDDoS対策における最も強力かつ論理的で、経済合理性にも優れたアーキテクチャは、「CDN → WAF → オリジンサーバー」という順番で配置する「階層型構造」
21です。この構成が最強である理由は、トラフィックを「ふるい」にかけるプロセスにあります。
1. 最前線(CDN): インターネットからの全トラフィック(攻撃含む)を受け止めます。
* 【L3/L4防御】: SYNフラッドやUDPフラッドといった「大洪水(ボリューム型攻撃)」は、ここでCDNの巨大なネットワーク帯域によって「吸収」・「緩和」されます
21。 * 【高速化】: 正規アクセスのうち、キャッシュ可能なコンテンツ(画像など)は、ここで即座に返され、サイトは高速化します21。2. 中間(WAF): CDNという「巨大なダム」を通過した、キャッシュが効かない「動的なリクエスト」(ログイン、検索など)だけが、WAFに転送されます
21。* 【L7防御】: WAFは、L3/L4の大洪水から解放された状態で、この「浄化された」動的リクエストの検査にリソースを集中できます。ここでHTTPフラッド、Slowloris、SQLインジェクションといった「質の高い」攻撃を精密に検知・遮断します。
3. 最後尾(オリジンサーバー): 二重のフィルタリングを経て、「クリーン」かつ「正規」で、「サーバーが本当に処理すべき」最小限のトラフィックのみが、オリジンサーバーに到達します。
この構成は、セキュリティを強固にする(L3/L4 + L7の全レイヤ対応)
21だけでなく、WAFが処理するトラフィック量をCDNが劇的に減らすため、WAFのコスト(従量課金の場合)を削減21し、サイト全体のパフォーマンスも向上させる21という、一石三鳥のメリットをもたらします。
3-3. なぜオンプレミス型は「気休め」にしかならないのか
今でも「DDoS対策専用アプライアンス(オンプレミス型の箱)」を提案するベンダーがいますが、私は企業のセキュリティ担当者として、これには明確に「否」を突きつけます。
【ファクトに基づく考察(城咲子の分析)】
結論から言います。現代のDDoS攻撃対策において、オンプレミス型のアプライアンス([6-1])は、もはや「気休め」にしかなりません。理由は単純明快です。DDoS攻撃の本質は「リソースの飽和」
15です。[1-4]で述べた通り、5GとIoTボットネットが可能にする攻撃は、1Tbps(テラビット毎秒)級
5が当たり前になりました。一方で、あなたの会社が契約しているインターネット回線帯域はいくつでしょうか? 1Gbpsですか? 10Gbpsですか?
1Tbps (= 1,000Gbps) の攻撃トラフィックが来た場合、あなたの会社がデータセンターに設置した「高価なDDoS対策の箱」にトラフィックが到達する“手前”で、契約している「回線(パイプ)」が完全に詰まり、飽和します
15。どんなに高性能な箱(アプライアンス)も、自分より巨大なリソース(帯域)には勝てません。
リソースの飽和攻撃には、攻撃側を上回るリソースで対抗するしかありません。そのリソースを自社単独で確保することが非現実的な現代において、「クラウド型」サービス(CDNやクラウド型WAF、DDoSミティゲーションサービス)が持つ、世界中に分散された巨大なネットワーク([6-1])を活用することだけが、唯一の論理的な解となります。
【関連記事】クラウド型WAF/CDNの「3大サービス」徹底比較
- 「オンプレがダメなのは分かった。では、クラウド型の3大サービス(Akamai, AWS, Cloudflare)のうち、中小企業はどれを選ぶべきか?」
- この疑問に答えるため、AWS WAFの「従量課金リスク」と、Cloudflareの「固定費プラン(初期10万+月額1万〜)」を徹底的に比較した記事がこちらです。
4. 実務としてのDDoS対策(運用・体制編)
最強のアーキテクチャ(CDN + WAF)を導入したとしても、「買って終わり」ではDDoS対策は完了しません。セキュリティ担当者の実務は、むしろ「運用」と「体制構築」にあります。
レベル1:今すぐできる基本対策(Nginx設定例)
高価なソリューションを導入する前に、まずはWebサーバー側でできる基本的な対策(レートリミット)を適用しましょう。これはL7のHTTPフラッド攻撃に対して一定の効果があります。
(ここでは、広く使われているNginxでの設定例 18 を紹介します)
1. ルールの「定義」 (limit_req_zone)
http ブロック内で、IPアドレスごとに1秒あたり5リクエストまで、というルールを定義します。
http { ... # $binary_remote_addr: 接続元IPアドレスをキーにする # zone=lrz:5m: 'lrz'という名前で5MBのメモリ領域を確保 # rate=5r/s: 1秒あたり5リクエスト(5 requests/second)を許可 limit_req_zone $binary_remote_addr zone=lrz:5m rate=5r/s; ... }
2. ルールの「適用」 (limit_req)
負荷が高くなりやすい動的コンテンツ(例:.php)の location ブロックで、定義したルールを適用します。
server { ... location ~ \.php$ { # 'lrz'ルールを適用 # burst=10: レート(5r/s)を超えた場合、10リクエストまではキューで待たせる # nodelay: burstも超えたら、即座に 503 エラーを返す limit_req zone=lrz burst=10 nodelay; ... } ... }
【実務上の注意点(城咲子)】
この設定は強力ですが、設定値を誤ると正規のユーザーまでブロックしてしまいます(誤検知)18。 まさに、これが自力でWAFを運用する際の「悪夢」(waf 誤 検 知)の始まりです。 この「チューニング」を自社で行う工数がない、という中小企業の担当者様は、次の記事で「プロに任せる」という選択肢を解説しています。【関連記事】WAFの「誤検知」とチューニング問題の解決策
- なぜWAFの誤検知は起きるのか、そして「Cloudflare無料版」ではなぜ解決できないのか。「初期10万+月額1万〜」の固定費で、面倒なチューニングごとプロ(DOMO)に任せる現実解を解説します。
レベル2:ソリューション選定の実務(ベンダー選定チェックリスト)
クラウド型DDoS対策(CDN/WAF)の導入を決めた後、セキュリティ担当者は「どのベンダーを選ぶか」という選定業務に入ります。
ベンダーに見積もりや提案を依頼する(RFI/RFP)際には、以下のポイントを必ず確認し、比較検討してください 15。
1. 防御範囲(レイヤ): * L3/L4のボリューム型攻撃にのみ対応か? * L7のアプリケーション層攻撃(HTTPフラッド, Slowloris)まで検知・防御できるか? 2. ネットワーク性能(キャパシティ): * サービス全体の総ネットワーク帯域(Tbps)は十分か?(Tbps級の攻撃を吸収できるか) * 「平時」の通信速度を低下させないか?(パフォーマンスへの影響) 3. 料金体系(コスト): * 月額固定料金制か? 従量課金制か? * (最重要)従量課金制の場合、大規模な攻撃を受けた際に防御コストが青天井になる「請求書DoS」のリスクはないか? 料金の上限(キャップ)設定は可能か? 4. サポート体制(運用): * 24時間365日のサポート体制があるか? * サポートは日本語で対応可能か? * 攻撃検知時のアラートは迅速か? * 自社に専門家がいない場合、設定や運用を代行してくれる「マネージドサービス」は提供されているか? 5. 運用性(UI/UX): * 管理画面(ダッシュボード)は直感的か? 攻撃状況をリアルタイムで把握できるか? * 防御ルールのチューニングは自社で容易に行えるか?
レベル3:攻撃を「前提」とした体制構築(インシデントレスポンス計画)
DDoS攻撃は、どれだけ予防しても100%防ぎきることはできません。
【ファクトに基づく考察(城咲子の分析)】
私の信念の一つに「属人性の徹底排除、チームとして行動すべし」というものがあります。 DDoS対策において最悪なのは、「攻撃発生を前提とした対応プロセス(インシデントレスポンス計画)」20が存在しないことです。計画書を作って「棚に飾る」のも同様に最悪です。
実務で機能するインシデントレスポンス計画とは、「有事の際に、誰が、何を見て、どう判断し、何を操作し、どこに連絡するか」が、具体的な手順書として明確化され、かつ定期的な「訓練」
20によって関係者全員(情シス、インフラ担当、CDN/WAFベンダー)がその動きを「筋肉」にしている状態を指します。最低限、以下の項目を定義し、チームで共有してください
20。1. 検知 (Detection):
* 「新商品の発売(正規の急増)」と「DDoS攻撃」を何で見分けるか? * 監視すべきメトリクス(BPS, PPS, RPS, サーバーCPU使用率)と、その「正常時の閾値」は? * 第一報は誰が受け、誰(責任者)にエスカレーションするか?
2. 対応 (Response):
* 攻撃と判断した場合、誰がどのシステム(CDN/WAFの管理画面、ファイアウォール)を操作し、緩和措置(例:防御モードの強化、特定国からのアクセス遮断
2)を講じるか? * (重要)CDN/WAFベンダーの「緊急連絡窓口」はどこか?3. 復旧 (Recovery):
* 攻撃収束をどう判断するか? * 強化した防御設定(例:アクセス遮断)を、いつ「平時」に戻すか?
このプロセスを「ルール化」([2025-08-28])し、訓練で回すこと。それこそが、攻撃発生時のダウンタイムを最小限に抑え、組織のレジリエンス(回復力)を高める唯一の方法です。
結論:防御から「サイバー・レジリエンス」への意識改革
DDoS攻撃は、もはや一時的な「イベント」ではなく、インターネットに接続する以上、常に向き合うべき「環境(ノイズ)」 7 となりました。
AI 4 と5G/IoT 5 によって「質」と「量」の両面で変貌をGg,
現代のDDoS攻撃に対し、かつての「オンプレミスの箱で防ぎきる」 15 という要塞型の防御思想は完全に破綻しています。
現代のDDoS対策は、攻撃を「防ぐ」のではなく、「受け流す(ミティゲーション)」思想に基づいています。
それは、自社を遥かに上回るリソースを持つ「クラウド」 15 のスケーラビリティを最大限に活用し、「CDN → WAF」という「階層型防御」 21 によって攻撃トラフィックを段階的にフィルタリングし、正規のトラフィックのみを保護するアーキテクチャです。
セキュリティ担当者として、私たちが目指すべきは、完璧な「防御」ではなく、強靭な「回復力(サイバー・レジリエンス)」 20 の構築です。
1. テクノロジーによる「予防」: CDN + WAF の階層型アーキテクチャ 21。
2. 体制による「対応」: 実効性のあるインシデントレスポンス計画と訓練 20。
3. 管理による「社会的責任」: 踏み台にならない適切な資産管理(オープンリゾルバの閉鎖 11)。
DDoSという脅威と「共存」しながら事業継続性を確保する――この「サイバー・レジリエンス」を構築・維持し、経営層にその重要性を説くことこそが、「経営の片腕」([2025-08-28])として情報システム部に課せられた、現代の重要な責務に他なりません。
【関連記事】DDoS対策の「その先」へ:ゼロトラストという選択肢
- 今回は「Webサイトを守る」DDoS対策(WAF/CDN)を解説しましたが、Cloudflareは「社内システムを守る」セキュリティ(ゼロトラスト)も提供しています。
- VPN運用に限界を感じている中小企業担当者様は、Cloudflareで「脱VPN」を月額0円から始める方法を解説した、こちらの記事もぜひご覧ください。
引用文献
- DDoS(ディードス)攻撃とは?事例や対策をわかりやすく解説|NTT西日本
- DDoS攻撃とはどんな攻撃?攻撃の種類や対策をご紹介|KDDI BUSINESS
- IPA「情報セキュリティ10大脅威2025」解説|専門家が語るTOP10|NRIセキュア
- 増加・巧妙化する「DDoS攻撃」と求められる対策|IT Insight|Orix rentec
- DDoS攻撃の最新動向2025|IoTボットネット・事例・今後の脅威|Guardian
- 2025 DDoS Trends Report|MazeBolt
- DDoS Attacks Against Japan|NETSCOUT
- Gaming Industry Faces 94% Surge in DDoS Attacks|Infosecurity Magazine
- ボットネットとは? 仕組みや感染経路、攻撃例、対策法を解説|SKYSEA Client View
- DDoS攻撃の一種である「リフレクション攻撃」とは?被害や対策例|KAGOYA CLOUD
- DNSリフレクション攻撃とは?その手法や対策方法をわかりやすく|GMOブランドセキュリティ
- DDoS攻撃の傾向と対策について|NOTICE
- DDoS 攻撃の規模の指数関数的な増大|Google Cloud 公式ブログ
- Five Most Famous DDoS Attacks and Then Some|A10 Networks
- おすすめのDDoS対策サービス|選び方・比較のポイントも解説|お名前.com
- 詳細図解 TCP|Zenn
- レイヤ7 DDoS攻撃: 手法と緩和策|Wallarm
- 【Nginx】DoS対策_limit_req_zone|すこぶる.net
- NGINXのRate Limitingの設定調査メモ|Zenn
- 進化するDDoS攻撃への備えとは?企業の包括的対策のポイントを解説|STNet
- CDNとWAFは併用がおすすめ!併用するメリットと構成例、注意点|アクセリア
- CDNとWAFを併用する理由とは?それぞれの違いについてもわかり|攻撃遮断くん
- IT業向け|DDoS対策ツール5選を価格で徹底比較|ITトレンド
- クラウド型WAF「攻撃遮断くん」価格・料金プラン|攻撃遮断くん
- DDoSの対策とは?DDoS攻撃の防御が難しい理由や対策方法を詳しく解説|攻撃遮断くん