DDoS攻撃を受けた時の
実務対応

DDoS攻撃を受けた時の実務対応は、単なるサーバ障害対応ではありません。分散型サービス妨害攻撃は、情報資産の三要素である機密性、完全性、可用性のうち、主として可用性を侵害します。EC、金融、決済、予約、医療、公共、物流、ゲーム、SaaS、BtoBポータル、IRサイトでは、サービス停止そのものが売上、信用、契約履行、監督当局対応、投資判断に直結します。

このページでは、初動60分、初日、72時間、30日・60日、再発防止という時間軸に沿って、企業法務、危機管理、情報セキュリティ、広報、会計・監査、経営判断を一体で整理します。重要なのは、攻撃を完全に防げなかった事実よりも、準備不足、連絡不能、ログ欠落、責任分界の不明確さ、説明遅延、根拠のない安全宣言を避けることです。

次の一覧は、DDoS攻撃を受けた企業が同時並行で進める5つの実務を表しています。読者にとって重要なのは、技術担当だけで完結しない論点を最初から並べることで、初動の抜け漏れを防げる点です。各項目から、自社の連絡先、証拠、契約、説明、再発防止の準備状況を読み取ってください。

DDoS攻撃を受けた時の実務対応では、まず障害対応と危機対応を区別します。障害対応はサーバ、ネットワーク、アプリケーションを復旧させる作業です。危機対応は、誰が意思決定し、誰に連絡し、どの情報を公表し、どの法的義務を履行し、どの証拠を残し、どの損害を把握し、どの再発防止を約束するかを決める活動です。

次の表は、DDoS攻撃を受けた後の時間軸と主な成果物を表しています。読者にとって重要なのは、緩和作業と同時に、証拠、法務、顧客説明、経営報告を前倒しで動かす必要がある点です。時間帯ごとに、主目的、主担当、残すべき成果物を確認してください。

次の時系列は、上の時間軸を実務の順番として表しています。読者にとって重要なのは、復旧だけを追うと、初回説明、法定報告、契約通知、証拠保全が後手に回る点です。各段階で何を完了させるべきかを読み取ってください。

初動で避けるべき失敗には、攻撃か通常アクセス集中かを確認しないまま公表すること、緊急連絡先が分からないこと、再起動でログを消すこと、攻撃元IPを犯人と断定すること、部門ごとに異なる説明をすること、個人情報漏えいがないと早期に断言すること、攻撃者への支払いを少人数で検討すること、委託元・委託先の通知分担が未定であることが含まれます。

最初の15分は、技術的に細かく分析する時間ではなく、組織としてインシデントとして扱うことを決める時間です。主要サービスで通常の障害対応では説明できない大量通信がある場合、CDNやWAFなどから異常通知がある場合、顧客から同時多発的に接続不能の問い合わせがある場合、脅迫メールで指定された対象に異常通信が始まった場合、高コスト機能に異常アクセスが集中している場合は、DDoS疑いとして危機対応を起動します。

次の判断の流れは、初動60分に何をどの順番で確認するかを表しています。読者にとって重要なのは、技術的緩和、証拠保全、顧客説明を分離せず、同時に開始する点です。上から順に進めながら、分岐では復旧優先か保全優先かを記録に残す必要があることを読み取ってください。

外部事業者へ伝える情報は、攻撃開始時刻、対象FQDN、IPアドレス、ポート、プロトコル、攻撃ベクトル、pps、bps、rps、同時接続数、L3/4中心かL7中心か、正規トラフィックの維持要件、変更可能な範囲、止めてよい機能と止めてはいけない機能、証拠保全が必要なログ種別と保存期間です。30分を超えて影響が続く場合は、緩和、縮退、説明を同時に行います。

DDoS攻撃を受けた時の実務対応では、復旧を急ぐあまり証拠を失うことが多くあります。後日の刑事相談、損害賠償請求、保険請求、顧客説明、監査、取締役会報告では、攻撃が実在したこと、どの程度の影響があったこと、会社が合理的に対応したことを示す資料が必要です。

次の一覧は、証拠保全の対象を技術ログ以外も含めて整理したものです。読者にとって重要なのは、DDoSの記録は通信量だけでなく、意思決定、顧客影響、公表文、外部事業者とのやり取りまで含む点です。後日説明に使う証跡がどこに残るかを読み取ってください。

ログ保全指示では、CDN、WAF、LB、FW、IDS/IPS、DNS、Web、AP、DB、OS、クラウド監査ログ、監視アラート、設定変更履歴、管理者操作履歴、外部事業者との連絡記録について、ローテーション、上書き、削除、改変、集約時の欠落が生じないよう指示します。期間は少なくとも発生前72時間、発生中、収束後72時間を目安にします。

攻撃元IPアドレスは、踏み台端末、ボットネット、オープンリゾルバ、反射サーバ、NAT、VPN、クラウド、プロキシ、侵害された第三者設備である可能性があります。DDoS攻撃は、電子計算機損壊等業務妨害罪等に該当し、5年以下の拘禁刑等の対象となる可能性があるとされています。警察相談時には、会社情報、攻撃対象、発生日時、影響、攻撃量、攻撃ベクトル、脅迫メール、社内対応経過、損害概算、公表済み内容を整理します。JPCERT/CCへの情報提供は、他組織への注意喚起や相関分析に役立つ可能性があります。

DDoS攻撃を受けた時、すべてを公開する必要はありませんが、何も共有しないことも適切とはいえません。非公開の技術情報共有は攻撃緩和や他社被害防止のために行い、顧客・取引先説明は利用者保護と契約履行のために行い、公表・IRは社会的説明や投資判断のために行い、監督官庁・法定報告は法令・業法上の義務履行のために行います。

次の表は、情報共有と公表の相手、目的、内容を整理したものです。読者にとって重要なのは、攻撃IPやパケット特徴のような技術情報を公開説明へそのまま出さず、相手ごとの目的に合わせて情報量を調整する点です。どの相手に、何のために、どの内容を出すかを読み取ってください。

ステータスページは、自社メインサイトが落ちることを前提に、メインインフラとは独立した環境に置きます。初回公表では、外部からの大量通信に起因するとみられる接続しづらい状態、緩和と復旧対応、確認済みの影響範囲、データへの不正アクセス有無は確認中であること、次回更新時刻を示します。収束後公表では、発生時刻、収束時刻、緩和策、監視継続、個人データ影響の確認範囲、再発防止を示します。

DDoSの原因は攻撃者ですが、事後レビューでそれだけを結論にしてはいけません。企業が分析すべきなのは、なぜ攻撃により大きな事業影響が出たのかです。オリジンIPの露出、CDN、WAF、DDoS保護の設定、DNS、認証、API、DB、外部連携のボトルネック、レート制限、監視アラート、緊急連絡先、法務・広報・CS・営業への連絡、顧客説明、ログ、契約通知、SLA判断を検証します。

次の一覧は、事後レビューで見るべき観点を表しています。読者にとって重要なのは、攻撃を受けた事実ではなく、影響を受けた理由と改善策を経営判断に変える点です。各項目から、自社の設計、運用、契約、説明責任の弱点を読み取ってください。

事後報告書は、技術報告書と経営報告書を分けます。技術報告書には、タイムライン、攻撃ベクトル、攻撃量、送信元分布、影響システム、ボトルネック、緩和策と効果、ログ・証跡、改善策を含めます。経営報告書には、事業影響、顧客・取引先影響、法的義務の履行状況、公表・通知、損害額、復旧費、補償、保険、取締役会・監査役・内部監査への報告、再発防止投資と期限を含めます。

再発防止策は、DDoS緩和サービスのAlways-on化または即時切替契約、CDN/WAF/Bot管理の設定見直し、オリジンIPの秘匿、DNSの冗長化、レート制限、APIキー管理、ログイン防御、SMS送信制限、ステータスページの外部独立化、緊急連絡先、権限、承認手順、ログ保存期間、委託契約、SLA、障害通知条項、年1回以上の演習、取締役会への年次報告まで具体化します。

Q1. DDoS攻撃を受けたら、必ず個人情報保護委員会へ報告する必要がありますか。

一般的には、DDoSは可用性を害する攻撃であり、個人データの漏えい等がない場合は、直ちに報告対象事態とは限らないとされています。ただし、不正アクセス、情報窃取、個人データの毀損・滅失が同時に疑われる場合は、報告対象事態に該当する可能性があります。具体的な対応は、ログや影響範囲を整理したうえで弁護士等の専門家へ相談する必要があります。

Q2. 攻撃元IPアドレスを顧客に教えてよいですか。

一般的には、攻撃元IPアドレスの公開は慎重に扱う必要があるとされています。踏み台や反射サーバであることが多く、真の攻撃者とは限らないためです。警察、JPCERT/CC、DDoS緩和事業者、ISP等への非公開共有は有用な場合がありますが、公開文では確認済み事実に絞ることが多いです。

Q3. 身代金を支払う必要がありますか。

一般的には、ランサムDDoSの支払いは推奨されないとされています。支払っても攻撃停止が保証されず、再要求、制裁・AML、反社会的勢力、会計、取締役の善管注意義務、説明責任の問題が生じる可能性があります。脅迫メールを保全し、経営、法務、外部専門家、警察等と相談する必要があります。

Q4. DDoSは不可抗力として免責されますか。

一般的には、契約文言、予見可能性、対策可能性、SLAの除外事由、準備状況、顧客説明、復旧努力によって判断が変わるとされています。第三者攻撃であることだけで免責されるとは限りません。具体的には、契約書、障害記録、対応履歴を確認したうえで専門家へ相談する必要があります。

Q5. 上場会社は必ず適時開示する必要がありますか。

一般的には、必ず開示が必要とは限らず、損害規模、事業影響、投資判断への影響、個人情報漏えい等の併発、報道状況を踏まえて判断するとされています。重要なサービス停止や損害が投資判断に影響する可能性がある場合は、早期にIR、法務、財務、外部専門家で検討する必要があります。

Q6. 顧客にサイバー攻撃だったと説明してよいですか。

一般的には、確認できている場合は説明してよいとされています。ただし、根拠が曖昧な段階では、外部からの大量通信に起因するとみられる接続障害など、確認済み事実に基づく表現が望ましいです。攻撃であること、攻撃類型、個人情報影響、復旧見込みは確度が異なるため、分けて説明します。

Q7. 小規模企業がまず整えるべきことは何ですか。

一般的には、自社だけで防ごうとせず、ホスティング会社、クラウド、CDN、DNS、WAF、ISPの緊急窓口を確認することが重要とされています。ステータスページ、顧客向けテンプレート、ログ保存、バックアップ、管理者MFA、オリジンIP保護も整備します。具体的な優先順位は、事業規模とシステム構成で変わります。

Q8. DDoS攻撃中に海外からのアクセスを遮断してよいですか。

一般的には、事業内容によって判断が変わります。海外顧客がいないサービスでは一時的な地域制限が有効な場合がありますが、海外顧客、出張者、VPN、越境サービス、外国語サイト、海外決済、越境ECがある場合は正規顧客を遮断する可能性があります。利用規約、顧客契約、代替手段、期間、理由記録を確認する必要があります。

Q9. DDoS攻撃後に完全復旧と公表してよいですか。

一般的には、完全復旧という表現は慎重に使う必要があるとされています。攻撃再開の可能性、ログ調査継続、縮退運用、監視強化中であれば、通常利用可能な状態に復旧、監視を継続、一部機能は制限中など、実態に合う表現にします。

Q10. サイバー保険にはいつ通知する必要がありますか。

一般的には、契約条件によって異なりますが、重大インシデントの可能性がある時点で早期に通知することが望ましいとされています。通知遅延が保険金支払いに影響する場合があり、保険会社指定のフォレンジック会社、専門家、広報支援がある場合もあります。個別契約を確認する必要があります。

公的機関・標準文書

• 警察庁「DDoS攻撃は犯罪です！」
• 警察庁「サイバー事案に関する相談窓口」
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」
• 東京証券取引所「発生事実 災害に起因する損害又は業務遂行の過程で生じた損害」
• 東京証券取引所「業務若しくは財産又は当該上場株券等に関する重要な事実」
• 国家サイバー統括室「サイバー攻撃被害に係る情報の共有・公表ガイダンス検討会」
• NIST「SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management」
• NIST「Cybersecurity Framework 2.0」

サイバーセキュリティ実務資料

• JPCERT/CC「DDoS 攻撃を示唆して仮想通貨による送金を要求する脅迫行為（DDoS 脅迫）について」
• JPCERT/CC「Web サイトへのサイバー攻撃に備えて」
• JPCERT/CC「インシデント対応依頼」
• JPCERT/CC「サービス運用妨害（DoS）攻撃に加担しないために」
• Canadian Centre for Cyber Security「Defending against distributed denial of service (DDoS) attacks」
• Australian Signals Directorate「Preparing for and responding to denial-of-service attacks」