DDoS攻撃対策とは？仕組み・最近の脅威・企業防御を徹底解説

DDoS攻撃とは何か

多数の送信元から可用性を削る攻撃です

DDoS は Distributed Denial of Service の略で、複数の送信元から通信や要求を集中させ、サービスが応答できる余力を削って利用不能へ寄せる攻撃です。警察庁のDDoS攻撃は犯罪です！↗でも、多数の機器から一斉に問い合わせを送り、応答が追いつかない状態へ追い込む攻撃として説明されています。

ここで重要なのは、「大量アクセスが来る」という表現だけで理解を止めないことです。実際には、回線帯域が先に詰まるのか、L3/L4 の通信処理が先に詰まるのか、アプリケーションや API の処理が先に詰まるのかで、守り方が大きく変わります。DDoS は一つの技術ではなく、可用性を落とす複数の型の総称と考えた方が実務に合います。

また DDoS は、単独でも被害を出しますが、三重恐喝のように追加圧力として使われる場合もあります。ただし本記事では extortion の一部ではなく、DDoS 単体の防御設計を主役にして整理します。

『通信が増えた』だけでは、防御判断に足りません

DDoS 対策で最初につまずきやすいのは、「通信量が増えたから DDoS だ」と雑に判断することです。平常時より帯域が増えていても、回線が耐えるなら問題は顕在化しません。一方で帯域は余っていても、TLS handshake や HTTP request が偏るだけでアプリケーション層が詰まることもあります。

つまり企業側は、「どの層が先に限界へ達するか」を知らないままでは守れません。ここを曖昧にすると、CDN を入れて安心したつもりでも origin が直叩きされていたり、WAF はあるのに DNS が弱かったり、回線増強だけしてアプリ層の防御が空いたりします。

可用性を狙う攻撃なので、初動の遅れ自体が被害になります

DDoS は情報窃取型とは違い、止まること自体が被害です。だから初動が遅れると、そのまま売上、問い合わせ、信頼、社内オペレーションへ波及します。攻撃の真偽を完璧に見極めてから動くのではなく、可用性低下が見えた時点でエスカレーションできる runbookを持つことが重要です。

とくに B2C サイト、ログイン基盤、API 提供サービス、問い合わせフォーム、決済周辺は、止まる時間が短くても外部影響がすぐ可視化されます。DDoS 対策はネットワーク担当だけの宿題ではなく、サービス運営全体の継続性の問題として扱う必要があります。

ボリューム型・プロトコル型・アプリケーション型は何が違うか

ボリューム型は『太さ』、アプリ型は『重さ』を狙います

ボリューム型は、大量のトラフィックで帯域そのものを埋める攻撃です。いわば道路の幅を物理的にふさぐ発想なので、個々のパケット内容が単純でも被害になります。一方でアプリケーション型は、ログイン、検索、購入、API 呼び出しのような一件ごとに重い処理を集中的に叩き、少ない帯域でも内部資源を食わせます。

ここを混同すると、回線増強だけで安心したり、逆に WAF に期待しすぎたりします。DDoS 対策の設計は、「どの型でも一つの装置が全部止める」と考えず、上流防御とアプリ防御を分けて持つ方が現実的です。

プロトコル型は『機器の持久力』が弱点になります

プロトコル型では、L3/L4 の処理や stateful な接続管理が先に苦しくなります。ここではアプリの重さより、機器がどれだけ接続と状態を保持できるかが問題になります。境界機器、ロードバランサ、ファイアウォール、TLS 終端装置の設計が甘いと、帯域が残っていても落ちます。

そのため、DDoS 対策を考える時は外部接続点の可視化と一緒に、どこで TLS を終端し、どの機器が state を持つのか、origin へ直接届く経路が残っていないかを見ておく必要があります。可用性防御はネットワーク図と公開面の両方が揃って初めて設計できます。

アプリケーション型は『正常に見える要求』ほど厄介です

アプリケーション型の DDoS は、HTTP request 自体は正常に見えることが多く、単純な allow/deny だけでは切り分けにくいのが特徴です。検索やログイン、カート投入、問い合わせ、API の特定 endpoint を集中的に叩かれると、不正通信というより大量の利用に見えてしまうため、判断が遅れます。

ここで必要なのは、WAF だけではなく、キャッシュ化、認証前処理の軽量化、rate limit、bot 対策、origin 直叩き防止、重要 endpoint の優先監視です。つまりアプリ型 DDoS はインフラだけの話ではなく、サービス設計そのものの課題です。

最近の国内状況から何を学ぶべきか

国内でも DDoS は現実の業務停止要因として扱うべきです

警察庁と NISC は、DDoS攻撃への対策について↗で、2022 年に発生した一連の DDoS 攻撃の分析と対策をまとめています。ここから読み取れるのは、DDoS が海外の巨大企業だけの問題ではなく、国内の組織でも現実にサービス停止を引き起こす脅威として扱われていることです。

さらに警察庁は、DDoS 攻撃サービスを悪用した事案の検挙にも触れており、専門的な技術知識がなくても攻撃を委託・利用しやすい環境があることを示しています。つまり DDoS は、限られた国家級攻撃者だけが使う高度攻撃ではなく、使われるハードルが下がっている可用性攻撃と考える方が自然です。

学ぶべきなのは『誰に任せるか』ではなく『どこまで自社責任か』です

国内企業で DDoS 対策が弱くなりやすい理由の一つは、「CDN を使っている」「回線事業者が見ている」「WAF を入れている」といった理由で、自社責任の範囲を曖昧にしやすいことです。しかし実際には、origin が露出していたり、古い管理面が残っていたり、問い合わせ用サブドメインだけ別系統で守りが弱かったりすると、委託先や上流ベンダーの守備範囲をすり抜けます。

そのため、DDoS の国内事例から学ぶべきなのは「大きなベンダーを使えば十分」という話ではありません。どの host が CDN の裏にいるのか、どの API が直で届くのか、どの管理画面が外へ出ているのか、自社の公開面を把握して責任分界を固めることが先です。

可用性の incident は、対外説明まで含めて設計する必要があります

DDoS は情報漏えいが必ず起きるとは限りませんが、止まるだけで顧客影響が表面化します。だから incident 対応では、技術遮断と同時に、いつ告知するか、サポートへ何を渡すか、問い合わせをどう捌くかを決める必要があります。ここを後回しにすると、攻撃の技術的影響より先に、社内外の混乱で被害が広がります。

その意味で DDoS は、ランサムのような大きな事故でなくても、可用性と説明責任の両方を鍛える訓練題材になります。DDoS を単なる「一時的なアクセス集中」と見ず、事業継続の観点から runbook を持つことが大切です。

企業はどう防ぐべきか

第一に、守るべき公開面と origin を把握する必要があります

DDoS 対策の出発点は、CDN や WAF の導入有無ではありません。どのサービスが止まると困るのか、どの host が origin として残っているのか、どの API や管理面が直で届くのかを把握することです。ここが曖昧だと、防御製品を重ねても穴が残ります。

とくに見落としやすいのは、旧ドメイン、移行前サブドメイン、緊急用ログイン、メンテナンス用画面、外部ベンダー向け管理 URL です。平常時はアクセスが少ないため、いざ攻撃時に「そこも開いていたのか」と気づく形になりやすく、守りの薄い面から可用性が崩れる原因になります。

第二に、緩和レイヤーを一枚で済ませないことが重要です

DDoS を止める方法は一つではありません。ボリューム型には upstream mitigation や scrubbing、アプリ型には WAF や bot 制御、origin 保護には接続元制限や DNS 設計が必要です。つまり「一つの製品を入れれば終わり」ではなく、どの型をどのレイヤーで受けるかを決める方が大切です。

ここで役立つのが、防御レイヤーごとの責任分界表です。CDN ベンダー、回線事業者、クラウド、社内インフラ、アプリ開発がどこを担当し、どこから自社 runbook へ切り替えるのかを先に書いておくと、incident 時の混乱が減ります。

第三に、技術対策と対外説明を同じ運用で回す必要があります

DDoS は止まった瞬間から顧客影響が見えやすいので、技術的な緩和と対外説明を別チームの別作業にすると遅れます。監視、広報、サポート、営業、法務が「今は何が起きていて、何を確認中か」を同じ状態で共有できる runbook を用意しておく方が現実的です。

そのため、平時の訓練でも通信遮断だけを試すのでは足りません。問い合わせテンプレート、告知基準、証跡保存、復旧確認、再発防止の報告まで含めて動かして初めて、DDoS 対策が事業継続へつながります。

さらに、企業防御では「どこまでを止めるか」だけでなく、「どこを残して事業継続するか」も決めておく必要があります。会員ログインは絞ってもよいのか、API の一部を止めてもよいのか、 問い合わせフォームを別経路へ逃がすのか、といった判断基準があると、DDoS を単なる回線問題ではなく継続性の優先順位付けとして扱いやすくなります。

DDoS 発生時の初動と復旧判断

DDoS では、攻撃を受けた瞬間よりも、どの順序で判断するかが揃っていないと被害が長引きます。可用性事故は、情報漏えい事故のように調査が終わるまで待ってから動く余裕がありません。 だからこそ、平時の設計に加えて、発生時の初動と復旧判定をあらかじめ決めておく必要があります。

特に、DDoS はベンダーへ丸投げしやすい一方で、最終的に「どの host を優先的に守るか」「どこまで機能縮退を許容するか」「いつ対外告知を出すか」は自社判断になります。緩和開始、機能縮退、復旧確認の三つの節目 を持つと、現場が迷いにくくなります。

最初の10分でやるべきことは、原因特定より経路の切り分けです

まず確認すべきなのは、「どこが詰まっているか」です。回線帯域なのか、CDN 手前なのか、origin なのか、認証系 API なのかで、動くべき相手が変わります。 DDoS では、原因の完全特定より先に詰まり場所を切り分ける 方が復旧に直結します。

実務では、影響 host、特定パス、TLS 終端の状態、CDN の緩和発動状況、DNS 応答、origin への直到達の有無を同時に見ます。ここで「表側は落ちているが管理面は生きている」「CDN は安定しているが origin が苦しい」といった違いが見えると、 どのレイヤーへ連絡し、どこを閉じるべきかの順番を決めやすくなります。

復旧判断は『戻ったかどうか』ではなく『再度落ちないか』で見るべきです

一時的に応答が戻っただけで「復旧」と判定すると、再び同じ経路で落ちることがあります。DDoS の復旧では、レスポンスが返ることに加えて、同じ攻撃パターンが続いても耐えられる状態へ移れたか を確認する必要があります。

そのため、復旧判定には、帯域、HTTP 応答、主要 API の遅延、問い合わせ量、CDN や上流ベンダーの緩和状態、origin 直到達の遮断状況まで含めた方が安全です。 一枚のダッシュボードで「緑に戻った」だけでは足りず、再発条件が潰れているか を併せて見ないと、対外説明も不安定になります。

可用性事故では、説明文と技術証跡を同時に残してください

DDoS では、顧客や取引先が最初に知るのは「つながらない」という事実です。そのため、技術班が緩和を進める一方で、サポートと広報が何を説明するかを並行で決める必要があります。事実確認前に断定しない のは重要ですが、何も出さないまま待つと問い合わせ負荷だけが先に膨らみます。

さらに再発防止や取引先説明のためには、いつ、どの host に、どの型の負荷が来て、どの緩和が効いたかを残す必要があります。DDoS は漏えい事故ほど詳細調査に時間をかけないこともありますが、証跡を薄くすると次回の設計改善につながらない ため、通信指標、緩和開始時刻、機能縮退の判断、告知時刻をセットで記録してください。

また、復旧後の振り返りでは「どの防御が効いたか」だけでなく、「どの host や API が想定外に露出していたか」も確認してください。DDoS では、 防御製品の性能よりも、守る対象の定義漏れが原因で被害が広がることがあります。技術的に止まったあとに公開面の棚卸しへ戻る までを一連の運用として持つと、次回の初動が短くなります。

その意味で、DDoS の振り返りでは「何 Gbps 来たか」よりも、「どの host が誰の責任範囲だったか」「どの問い合わせ窓口へ顧客が流れたか」「どの旧 URL が混乱を広げたか」を見る方が改善に効きます。 可用性事故はインフラだけでは完結しないため、公開面、運用責任、説明導線をまとめて見直す ことが、次の incident を短くする近道です。

DDoS を受けたあとに公開面の整理まで戻せる組織ほど、同じ抜け道で再び苦しみにくくなります。

初動、復旧、振り返りを一つの運用として閉じられるかどうかが、DDoS 対策の成熟度を分けます。

だから DDoS 対策は、防御装置の導入可否だけで評価するより、公開面の把握、機能縮退の判断、対外説明、復旧判定までを同じ runbook で回せるかで見た方が、実務上の強さが分かりやすくなります。

公開 origin や古い管理導線を棚卸しするなら ASM診断 PRO

ASM診断 PRO は DDoS を直接緩和する製品ではありません。CDN、scrubbing、upstream mitigation の代替にもなりません。ただし、それでも DDoS 対策の前段で役立つ理由があります。実務では、DDoS が長引く原因の一つが「守っているつもりの表側ではなく、古いサブドメイン、CDN 未経由の origin、残置された管理画面、問い合わせ用の別ドメインが露出していた」という構造だからです。防御装置の話へ進む前に、まずどの公開面が今も外から届くかを揃える必要があります。

ASM診断 PRO なら、ドメイン、サブドメイン、証明書、公開ログイン画面、古い管理 URL、公開 API の観点から、外から見える接点を棚卸しできます。DDoS の文脈では特に、「CDN 配下のつもりだったが実は直接届く host が残っていた」「移行前の origin が生きていた」「緊急用の管理導線が外へ出たままだった」といった運用負債を見直す起点として使いやすいです。防御レイヤーの議論を始める前に、守る対象と漏れている経路を確認する方が、優先順位をつけやすくなります。

DDoS 対策は回線や機器だけで閉じません。公開面の把握、origin の遮蔽、管理導線の整理、問い合わせ系サブドメインの棚卸し、運用責任の明確化がつながって初めて安定します。ASM診断 PRO はそのうちの「公開面の現状把握」を支える補助線として、外から見える面を先に揃え、どこを CDN や WAF、ネットワーク対策へ結び付けるべきかの判断を助けます。可用性防御を設計する最初の一歩として、まずは自社の外部公開面を見直してください。

よくある質問（FAQ）

DDoS と DoS は何が違いますか

DoS は単一または少数の送信元でも成立しうる広い概念で、DDoS はそこに distributed、つまり多数の送信元からの分散実行が加わったものです。実務では DDoS の方が帯域や多様な送信元を伴いやすく、緩和を上流へ寄せる必要が高くなります。

CDN を入れていれば DDoS 対策は十分ですか

十分とは言えません。CDN は有効な防御層ですが、origin 直叩きが残る、管理画面が別ドメインで露出する、API が CDN の裏にいない、問い合わせ系サブドメインが未保護といった構成だと抜け道が残ります。CDN の有無より、どこが直接届くかの把握が先です。

DDoS は情報漏えいが起きないなら優先度を下げてもよいですか

いいえ。DDoS は可用性を直接狙うので、売上、問い合わせ、顧客接点、社内運用へ即座に影響します。情報漏えいが無くても業務停止そのものが被害であり、顧客への説明やブランド影響も生みます。情報漏えいが無いから軽いとは言えません。

DDoS 対策で企業が最初に確認すべきことは何ですか

守るべき公開面と origin、CDN や WAF の責任分界、古い管理導線の残置、重要 endpoint の優先度、初動 runbook の 5 点です。まず対象と責任分界が曖昧だと、防御装置を増やしても incident 時の判断が遅れます。

ASM診断 PRO は DDoS 緩和そのものを行いますか

いいえ。DDoS 緩和や scrubbing を直接行う製品ではありません。役割は、公開 origin、古い管理面、外から届く接続点を棚卸しし、可用性対策の前提になる公開面の整理を支えることです。

まとめ

DDoS 攻撃対策で重要なのは、「大量通信を止める方法」だけを考えないことです。実際には、帯域、通信処理、アプリ処理のどこが先に詰まるかを見分け、CDN、WAF、upstream mitigation、origin 保護、運用 runbook を層として設計する必要があります。ボリューム型、プロトコル型、アプリケーション型は同じ DDoS でも守り方が違うため、単一の製品や単純な回線増強だけでは足りません。どの host、API、管理画面、問い合わせ系サブドメインが守る対象かを先に把握し、そのうえで責任分界と初動手順を固める方が実務に合います。

また DDoS は、技術的に止まることだけでなく、顧客説明、問い合わせ対応、社内意思決定の遅れを通じて被害を広げます。だから防御はネットワーク担当だけの仕事ではなく、広報、サポート、運用、経営まで含めた継続性の設計です。まずは自社の公開面と origin を棚卸しし、どこが直で届くのか、どのレイヤーで守るのか、どの手順で外へ説明するのかを揃えてください。DDoS 対策は、可用性を守る仕組みを平時から設計できているかを問うテーマです。

平時に公開面が揃っていれば、incident 時の判断も速くなります。どの host が顧客向けで、どの host が管理用で、どこが CDN 配下、どこが直到達なのかが見えていれば、 緩和、機能縮退、告知の優先順を決めやすくなります。DDoS 対策は防御製品の比較だけでなく、守る対象の棚卸しと復旧判断の準備 まで含めて設計してください。