DDoS攻撃を受けた時の緊急対応マニュアル

DDoS攻撃を受けた時の緊急対応マニュアル｜初動から復旧まで

2025年11月07日作成

コラム

DDoS攻撃を受けた瞬間、冷静な判断と迅速な行動が被害を最小限に抑える鍵となります。しかし、「何から手を付けるべきか」「誰に連絡すべきか」と混乱するケースが少なくありません。本マニュアルでは、攻撃検知から15分以内の初動対応、エスカレーション基準、証拠保全方法、段階的復旧手順まで、時系列で具体的に解説します。チェックリスト、コマンド例、連絡テンプレートなど、すぐに使える実践的なツールも豊富に収録。CSIRT構築前の企業でも、このマニュアルに沿って対応することで、被害を最小限に抑え、迅速な復旧を実現できます。平時に印刷して、いざという時に備えてください。

攻撃を受けた時の初動対応

最初の15分でやるべきこと

DDoS攻撃への対応は、最初の15分が勝負です。この時間内の適切な判断と行動が、被害規模と復旧時間を大きく左右します。以下のタイムラインに沿って、冷静かつ迅速に対応してください。

攻撃検知から15分間のアクションタイムライン：

経過時間	アクション	担当	確認事項	次のステップ
0-3分	異常検知・状況確認	監視担当	アラート内容、影響範囲、エラー率	エスカレーション判断
3-5分	初期診断	インフラ担当	トラフィック量、攻撃種別、標的	緊急度レベル判定
5-10分	緊急対策実施	セキュリティ担当	Rate Limit設定、IP Block実行	効果測定・追加対策検討
10-15分	対策本部設置判断	管理者	事業影響度、必要リソース確認	体制構築・役割分担

緊急度判定フローチャート：

DDoS攻撃検知
　├─ サービスへの影響あり
　│　　├─ 全面停止（アクセス不可）
　│　　│　　→ 【最高優先度】即座に対策本部設置、全リソース投入
　│　　├─ 重度の劣化（応答10秒以上）
　│　　│　　→ 【高優先度】15分以内に主要メンバー招集
　│　　└─ 軽度の劣化（応答3-10秒）
　│　　　　　→ 【中優先度】30分以内に対応開始
　└─ サービス影響なし（予防的検知）
　　　　├─ 攻撃継続中
　　　　│　　→ 【監視強化】5分ごとの状況確認、エスカレーション準備
　　　　└─ 攻撃終了
　　　　　　　→ 【事後分析】ログ保全、レポート作成

初動対応において最も重要なのは、パニックに陥らないことです。過去の攻撃事例を参考に、組織的な対応を心がけてください。まず、現在のトラフィック量を確認し、平常時の何倍になっているかを把握します。多くの場合、10-100倍のトラフィックが観測されます。

次に、攻撃の種類を特定します。SYN Flood、UDP Flood、HTTP Floodなど、攻撃手法によって対策が異なります。netstatコマンドやtcpdumpを使用して、パケットレベルでの分析を行います。

# 接続状態の確認（SYN_RECV多数ならSYN Flood）
netstat -tan | grep SYN_RECV | wc -l

# トップ10攻撃元IPの特定
netstat -tan | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -10

# リアルタイムトラフィック監視
tcpdump -i eth0 -n -c 1000 | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn

緊急対策として、Rate Limitingの即座適用が効果的です。WAFが導入されている場合は、攻撃パターンに応じたルールを有効化します。CDNサービスを利用している場合は、Under Attack Modeなどの緊急防御機能を起動します。

緊急連絡と役割分担

攻撃が確認されたら、適切な連絡と役割分担が不可欠です。混乱を避けるため、事前に定められた連絡フローに従って、迅速に情報共有を行います。

社内連絡 - 迅速なエスカレーション: 最初に連絡すべきは**CTO/セキュリティ責任者**で、攻撃検知から**5分以内**に第一報を入れます。Slackやメールではなく、電話での連絡を推奨します。次に、サービス影響が確認された場合は**15分以内**に経営層へエスカレーション。対外的な影響が予想される場合は、**30分以内**に広報部門へ連絡し、外部公表の準備を開始します。連絡の際は、「いつ」「何が」「どの程度」「現在の対応」を簡潔に伝えます。
ISP/データセンターへの連絡 - 上流での対策依頼: 大規模な攻撃の場合、自社だけでの対処は困難です。**NOC（Network Operation Center）**の緊急連絡先に電話し、状況を説明します。多くのISPはDDoS対策サービスを提供しており、上流でのトラフィック遮断やNull Routing設定が可能です。連絡時は、攻撃規模（Gbps）、攻撃種別、影響範囲を明確に伝えます。事前に用意した連絡票テンプレートを使用することで、必要情報の伝達漏れを防げます。
外部専門家への支援要請 - プロフェッショナルの活用: 自社での対応が困難と判断された場合、**インシデントレスポンス専門業者**への連絡を検討します。24時間対応可能な契約先がある場合は、SLAに基づいた対応を要請します。契約がない場合でも、緊急対応サービスを提供している企業は多数存在します。セキュリティベンダーのSOC（Security Operation Center）も、リアルタイムの脅威情報と対策アドバイスを提供してくれます。費用は高額になる場合がありますが、被害の最小化を優先すべきです。

役割分担マトリックス：

役割	担当者	主要タスク	必要スキル	バックアップ
指揮官	CTO/責任者	全体統括、意思決定	リーダーシップ、判断力	部門長
技術対応	インフラエンジニア	緊急対策実施、設定変更	ネットワーク、セキュリティ知識	SREチーム
分析担当	セキュリティエンジニア	攻撃分析、対策立案	ログ分析、攻撃手法知識	データアナリスト
連絡担当	PMO	社内外連絡、記録	コミュニケーション力	総務部
広報対応	広報責任者	対外発表、顧客対応	PR、危機管理	マーケティング

応急処置の実施

初動対応と並行して、即効性のある応急処置を実施します。完璧な対策でなくても、攻撃の影響を軽減することが最優先です。

攻撃トラフィックの識別

最初に、正常なトラフィックと攻撃トラフィックを区別します。アクセスログから攻撃元IPアドレスを抽出し、地理的分布、User-Agent、アクセスパターンを分析します。多くの場合、特定の国や地域からの集中的なアクセス、同一のUser-Agent、機械的なアクセス間隔などの特徴が見られます。
Rate Limitingの即座適用

Webサーバーレベルで、即座にレート制限を適用します。Nginxの場合はlimit_req_zone、Apacheの場合はmod_ratelimitを使用します。初期値は厳しめに設定し、状況を見ながら緩和していきます。同時に、WAF設定でもレート制限を強化します。1IPあたり10リクエスト/秒程度から開始し、正常なユーザーへの影響を確認しながら調整します。
地理的ブロッキング（GeoBlocking）の実施

攻撃元が特定の国や地域に集中している場合、一時的にその地域からのアクセスをブロックします。ただし、ビジネスへの影響を慎重に評価する必要があります。重要な顧客や取引先がブロック対象地域にいる場合は、個別にホワイトリスト登録します。CloudflareやAWS WAFなどのサービスでは、簡単にGeoBlockingを設定できます。
CDN/DDoS対策サービスの緊急有効化

CDNを利用している場合、Cloudflare Under Attack ModeやAWS Shield Advancedなどの高度な防御機能を有効化します。これにより、エッジでの攻撃遮断が可能になり、オリジンサーバーへの負荷を大幅に軽減できます。未契約の場合でも、緊急導入は30分程度で可能です。
オリジンIPアドレスの変更（最終手段）

上記の対策でも効果がない場合の最終手段として、オリジンサーバーのIPアドレス変更を検討します。新しいIPアドレスは絶対に公開せず、CDN経由のアクセスのみを許可します。DNS切り替えには時間がかかるため、TTLを事前に短く設定しておくことが重要です。

エスカレーションフロー

社内エスカレーション基準

DDoS攻撃への対応において、適切なタイミングでのエスカレーションは極めて重要です。遅すぎると被害が拡大し、早すぎると過剰反応となります。以下の基準に基づいて、冷静に判断してください。

エスカレーションレベルマトリックス：

レベル	発動条件	通知対象	対応時間要件	付与権限	対応例
L1（通常）	小規模攻撃（10Gbps未満）、影響なし	チームリーダー	営業時間内対応	基本的な設定変更	Rate Limit調整
L2（警戒）	サービス劣化、一部機能停止	部門長、インフラ責任者	1時間以内	緊急変更権限	WAFルール追加、GeoBlocking
L3（緊急）	主要サービス停止、顧客影響大	CTO、役員クラス	30分以内	システム全権限	CDN切り替え、ISP連携
L4（危機）	事業継続困難、全サービス停止	CEO、取締役会	即時対応	BCP発動権限	代替サイト起動、対外発表

エスカレーション判断基準の詳細：

攻撃の深刻度を判断する際は、複数の指標を総合的に評価します：

ダウンタイム基準：5分（L1）、30分（L2）、1時間（L3）、3時間以上（L4）
影響顧客数：100名未満（L1）、1,000名（L2）、10,000名（L3）、全顧客（L4）
攻撃規模：10Gbps（L1）、50Gbps（L2）、100Gbps（L3）、それ以上（L4）
収益影響：時間10万円（L1）、100万円（L2）、1000万円（L3）、測定不能（L4）
レピュテーション：影響なし（L1）、SNS炎上（L2）、メディア報道（L3）、社会問題化（L4）

エスカレーション時は、RACI（Responsible, Accountable, Consulted, Informed）マトリックスに従って、適切な役割分担を行います。混乱を避けるため、指揮命令系統は一本化し、情報の錯綜を防ぎます。

外部機関への通報

特定の条件下では、外部機関への通報が必要または推奨されます。通報により、専門的な支援や法的措置が可能になる場合があります。

警察（サイバー犯罪相談窓口）- 犯罪性がある場合: DDoS攻撃に**恐喝や脅迫**が伴う場合、直ちに警察への通報を検討します。「攻撃を止めてほしければ金銭を支払え」といった要求があった場合は、明確な犯罪行為です。全国共通の相談電話**#9110**または、各都道府県警察のサイバー犯罪対策課に連絡します。通報時は、脅迫メールやメッセージのスクリーンショット、攻撃ログ、被害額の試算を準備します。警察は法的措置の助言も提供してくれます。
JPCERT/CC - 大規模・新型攻撃の情報共有: **JPCERT/CC（Japan Computer Emergency Response Team Coordination Center）**は、日本のナショナルCSIRTとして、インシデント対応の調整を行っています。特に、100Gbpsを超える大規模攻撃、新種の攻撃手法、他組織への波及が懸念される場合は、速やかに報告することが推奨されます。Webサイトのインシデント報告フォームから24時間受付可能で、技術的な助言や、攻撃元ISPとの調整支援も期待できます。報告は匿名も可能ですが、詳細な支援を受けるには組織情報の提供が必要です。
IPA（情報処理推進機構）- 脆弱性悪用の報告: 攻撃が特定の脆弱性を悪用している場合、**IPA**への報告が重要です。「情報セキュリティ安心相談窓口」（03-5978-7509）では、技術的な相談に応じてくれます。特に、ゼロデイ攻撃や標的型攻撃の兆候がある場合は、他組織への被害拡大を防ぐためにも早期の情報共有が求められます。IPAは収集した情報を分析し、注意喚起や対策情報を公開することで、日本全体のセキュリティ向上に貢献しています。

顧客・取引先への連絡

サービス影響が発生した場合、顧客や取引先への迅速かつ適切な連絡が信頼維持の鍵となります。情報公開の透明性と、具体的な対策の提示が重要です。

顧客向け連絡テンプレート（第一報）：

【重要】サービス障害のお詫びとご報告

平素より弊社サービスをご利用いただき、誠にありがとうございます。

現在、以下の障害が発生しており、お客様にご迷惑をおかけしておりますことを
深くお詫び申し上げます。

◆発生日時：2025年●月●日 ●●:●●頃
◆影響範囲：
　- [サービス名]へのアクセスが不安定
　- ログイン処理に時間がかかる場合がある
　- 一部機能が利用できない

◆現在の状況：
　外部からの大量アクセスによるものと判明しており、現在、防御措置を
　実施しております。

◆復旧見込み：
　●●:●●頃を目標に復旧作業を進めております。

◆お客様へのお願い：
　- 緊急でない操作は、復旧後に実施いただけますようお願いいたします
　- ログインエラーが発生した場合は、時間をおいて再度お試しください

最新情報は、以下にて随時更新してまいります。
URL: https://status.example.com

お客様には大変ご不便をおかけしており、重ねてお詫び申し上げます。
一刻も早い復旧に向けて、全力で対応しております。

連絡のタイミングは、影響確認後30分以内の第一報、その後1時間ごとの状況更新、復旧完了時の最終報告が基本となります。ビジネスメール詐欺に便乗した攻撃を防ぐため、公式サイトやSNSでの告知も並行して行います。

証拠保全と記録

ログ取得コマンド一覧

インシデント対応において、証拠保全は極めて重要です。適切に保全された証拠は、事後分析、再発防止、そして法的措置の際に不可欠となります。以下のコマンドを使用して、攻撃の痕跡を確実に記録してください。

ネットワーク関連の証拠取得コマンド：

#!/bin/bash
# 証拠保全スクリプト - 実行日時付きで保存

EVIDENCE_DIR="/evidence/$(date +%Y%m%d_%H%M%S)"
mkdir -p $EVIDENCE_DIR

# ネットワーク接続状態の記録
echo "[*] Capturing network connections..."
netstat -an > $EVIDENCE_DIR/netstat_all.txt
netstat -tan | grep ESTABLISHED > $EVIDENCE_DIR/netstat_established.txt
netstat -tan | grep SYN_RECV > $EVIDENCE_DIR/netstat_syn.txt
ss -an > $EVIDENCE_DIR/ss_all.txt

# パケットキャプチャ（5分間、最大100MB）
echo "[*] Starting packet capture..."
timeout 300 tcpdump -i eth0 -w $EVIDENCE_DIR/capture.pcap -C 100

# 接続統計の取得
echo "[*] Analyzing connection statistics..."
netstat -tan | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -100 > $EVIDENCE_DIR/top_ips.txt

# Webサーバーログ分析（Apache/Nginx）
echo "[*] Analyzing web server logs..."
if [ -f /var/log/nginx/access.log ]; then
	awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -100 > $EVIDENCE_DIR/nginx_top_ips.txt
	grep -E "4[0-9]{2}|5[0-9]{2}" /var/log/nginx/access.log > $EVIDENCE_DIR/nginx_errors.txt
fi

if [ -f /var/log/apache2/access.log ]; then
	awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -100 > $EVIDENCE_DIR/apache_top_ips.txt
fi

# ファイアウォール状態
echo "[*] Capturing firewall rules..."
iptables -L -n -v > $EVIDENCE_DIR/iptables_rules.txt
iptables -L -n -v -t nat > $EVIDENCE_DIR/iptables_nat.txt
ip6tables -L -n -v > $EVIDENCE_DIR/ip6tables_rules.txt

# システムリソース状態
echo "[*] Capturing system resources..."
top -b -n 1 > $EVIDENCE_DIR/top.txt
ps auxf > $EVIDENCE_DIR/ps_tree.txt
iostat -x 1 10 > $EVIDENCE_DIR/iostat.txt
vmstat 1 10 > $EVIDENCE_DIR/vmstat.txt
df -h > $EVIDENCE_DIR/disk_usage.txt
free -m > $EVIDENCE_DIR/memory.txt

# システムログのコピー
echo "[*] Backing up system logs..."
cp /var/log/syslog $EVIDENCE_DIR/syslog.backup
cp /var/log/messages $EVIDENCE_DIR/messages.backup 2>/dev/null
dmesg > $EVIDENCE_DIR/dmesg.txt

# ハッシュ値の計算（改ざん防止）
echo "[*] Calculating checksums..."
find $EVIDENCE_DIR -type f -exec sha256sum {} \; > $EVIDENCE_DIR/checksums.txt

echo "[*] Evidence collection completed: $EVIDENCE_DIR"

このスクリプトはroot権限で実行し、証拠データは改ざん防止のため、書き込み保護されたメディアにもバックアップを取ることを推奨します。

スクリーンショット取得項目

視覚的な証拠も、インシデントの状況を理解する上で重要です。以下の項目について、タイムスタンプ付きでスクリーンショットを取得します。

必須記録項目と保存要件：

対象	取得内容	ファイル形式	保存期間	用途
監視ダッシュボード	トラフィックグラフ、CPU/メモリ使用率	PNG/PDF	1年	攻撃規模の証明
エラー画面	503エラー、タイムアウト画面	PNG	1年	サービス影響の証拠
攻撃ログ	WAF/IDS検知ログ、上位攻撃元IP	TXT/CSV	3年	攻撃パターン分析
対応記録	Slack、メール、電話メモ	PDF	3年	対応プロセス検証
設定変更	変更前後のコンフィグファイル	TXT	3年	対策効果の評価
外部通信	ISP/ベンダーとのやり取り	PDF/メール	3年	責任範囲の明確化

スクリーンショット取得時は、システムクロックが正確であることを確認し、可能な限り画面全体を含めます。Windowsでは「Windowsキー + Shift + S」、macOSでは「Command + Shift + 4」で範囲指定してキャプチャできます。

タイムスタンプ記録方法

インシデント対応において、正確な時系列記録は事後検証や改善策立案に不可欠です。以下のフォーマットで、全ての事象と対応を記録します。

インシデント記録シートテンプレート：

================================================================================
インシデント記録シート
================================================================================
インシデントID: INC-2025-XXXX
記録開始: 2025-XX-XX XX:XX:XX (JST)
記録者: [氏名・所属]
更新日時: 2025-XX-XX XX:XX:XX (JST)

【インシデント概要】
種別: DDoS攻撃
検知方法: 監視アラート / ユーザー報告 / その他
最大攻撃規模: XXX Gbps / XXX Mrps
主要攻撃手法: SYN Flood / UDP Flood / HTTP Flood / 複合

【タイムライン】
※全て日本標準時（JST）で記録

14:23:15 - [検知] 監視システムでトラフィック異常検知 - 山田 - Datadogアラート発報
14:23:45 - [確認] ダッシュボード確認、通常の50倍のトラフィック - 山田 - エスカレーション判断
14:24:30 - [連絡] Slackで緊急チャンネル作成、メンバー招集 - 田中 - 5名参加確認
14:25:00 - [分析] tcpdumpでパケット分析開始 - 鈴木 - UDP Flood確認
14:26:00 - [対策] Rate Limiting設定（10req/s） - 鈴木 - 一部軽減確認
14:28:00 - [連絡] CTOへ電話連絡 - 田中 - 対策本部設置指示
14:30:00 - [対策] CloudflareでUnder Attack Mode有効化 - 山田 - 攻撃の80%遮断
14:35:00 - [確認] サービス応答改善確認 - 鈴木 - 3秒以内に回復
14:40:00 - [連絡] 顧客向け第一報配信 - 広報 - メール/Web告知
[以降も同様のフォーマットで継続記録]

【対応メンバー】
役割: 氏名 (参加時刻-離脱時刻)
- 指揮官: 佐藤CTO (14:28-18:00)
- 技術リード: 鈴木 (14:23-20:00)
- 分析担当: 山田 (14:23-19:00)
[全メンバーを記録]

【実施した対策】
時刻 - 対策内容 - 効果
14:26 - Rate Limiting (10req/s) - 20%軽減
14:30 - Under Attack Mode - 80%遮断
[全対策を時系列で記録]

【学んだこと】
- Good: 初動対応が迅速だった（5分以内）
- Bad: ISPへの連絡が遅れた（30分後）
- 改善: 緊急連絡先リストの更新が必要

記録はリアルタイムで行い、後から記憶に頼って作成しないことが重要です。可能であれば、記録専任者を割り当て、技術対応者の負荷を軽減します。

復旧と再発防止

段階的復旧手順

攻撃が収束しても、性急な全面復旧は危険です。段階的に正常化を進め、各段階で安定性を確認しながら、慎重に復旧作業を進めます。

復旧フェーズと確認事項：

フェーズ	作業内容	確認項目	判定基準	ロールバック条件
Phase 1: 攻撃停止確認	トラフィック正常化確認	5分間の継続監視	平常時の1.5倍以下	-
Phase 2: 制限緩和	Rate Limit段階的緩和	CPU/メモリ負荷	CPU<50%、メモリ<70%	負荷急上昇で即再設定
Phase 3: 機能復旧	停止機能の段階的再開	エラー率、応答時間	エラー<0.1%、応答<1秒	エラー急増で一時停止
Phase 4: 全面復旧	全機能・全ユーザー解放	全監視指標	SLA基準達成	いずれか悪化でPhase 3へ
Phase 5: 事後対策	恒久対策の実施	セキュリティ強度	脆弱性解消	-

復旧前チェックリスト：

□ 攻撃トラフィックが30分以上観測されていない
□ システムリソース（CPU/メモリ/帯域）に余裕がある
□ データベースの整合性チェック完了
□ キャッシュクリアまたは再構築完了
□ セッション情報の妥当性確認
□ ログローテーション正常動作
□ 監視アラートの閾値リセット
□ バックアップの最新化確認
□ 関係者への復旧作業開始連絡完了
□ ロールバック手順の確認

各フェーズの移行は、技術責任者の承認を得てから実施します。Phase 3以降は、ユーザーへの影響を最小化するため、可能な限りトラフィックの少ない時間帯に実施することを推奨します。

復旧作業では、CDN設定の見直しや、WAFルールの最適化も並行して実施します。一時的に設定した厳格なルールは、段階的に緩和していきますが、セキュリティレベルを攻撃前より高く保つことが重要です。

動作確認項目

復旧後の動作確認は、体系的かつ網羅的に実施する必要があります。見落としがあると、二次障害や顧客クレームにつながる可能性があります。

基本機能確認 - ユーザー視点での検証

最初に、エンドユーザーが利用する基本機能を確認します。ログイン機能では、通常ログイン、ソーシャルログイン、二要素認証が正常に動作することを確認。主要ページは、トップページ、商品ページ、マイページなど、アクセス頻度の高いページから順次確認します。API応答は、レスポンスタイムとステータスコードを監視し、エラー率が通常範囲内であることを確認。データベース接続は、読み書き両方のクエリが正常に処理されることを検証。外部サービス連携では、決済、配送、SNS連携などが正常に機能することを確認します。
パフォーマンス確認 - 定量的な性能評価

応答時間測定では、主要なエンドポイントごとに95パーセンタイル値を測定し、SLA基準を満たしていることを確認します。同時接続テストは、通常時の1.5倍程度の接続数で安定動作することを検証。負荷試験は、JMeterやGatlingを使用して段階的に負荷を上げ、ボトルネックがないことを確認。この際、本番環境への影響を避けるため、ステージング環境での実施を推奨します。CDNキャッシュ率は、80%以上を維持できているか確認し、必要に応じてキャッシュルールを調整します。
セキュリティ確認 - 防御態勢の検証

WAFルール動作は、テスト用の攻撃パターンを送信し、適切にブロックされることを確認します。ただし、本番環境では最小限のテストに留めます。ログ収集が正常に行われ、SIEM等への転送も問題ないことを確認。アラート通知は、閾値を一時的に下げてテストし、適切に発報されることを検証。バックアップは、攻撃前後のデータが適切に保存され、リストア可能であることを確認します。侵入検知システムも正常に機能していることを確認します。

事後レポートと改善計画

インシデント対応の最終段階として、詳細な事後レポートを作成し、再発防止に向けた改善計画を立案します。

1. エグゼクティブサマリー - 経営層向け要約: 1ページで全体像を把握できるよう、インシデントの概要、ビジネスへの影響（ダウンタイム、影響顧客数、推定損失額）、実施した対応の要点、今後の対策方針を簡潔にまとめます。技術的詳細は避け、ビジネス視点での影響と対策効果を中心に記述します。グラフや図表を活用し、視覚的に理解しやすい構成とします。
2. 詳細タイムライン - 時系列での完全記録: 攻撃検知から完全復旧まで、全てのイベントと対応を分単位で記録します。各アクションの実施者、判断根拠、結果を明記し、意思決定プロセスの妥当性を検証可能にします。特に、判断に迷った点、想定外だった事象、効果的だった対策を詳細に記述します。このタイムラインは、次回のインシデント対応の貴重な参考資料となります。
3. 原因分析 - 技術的な深掘り: 攻撃手法の技術的分析（攻撃パターンの詳細）、なぜ初期防御を突破されたのか、どの対策が効果的だったか、システムの脆弱点はどこにあったかを分析します。ログ分析結果、パケットキャプチャの解析結果を含め、技術チーム向けの詳細な情報を提供します。可能であれば、攻撃者のTTP（Tactics, Techniques, and Procedures）を推定します。
4. 改善提案 - 具体的なアクションプラン: 短期（1ヶ月以内）、中期（3ヶ月以内）、長期（1年以内）の改善計画を立案します。技術的対策（WAF強化、CDN導入）、プロセス改善（対応手順の見直し、訓練実施）、体制強化（24時間監視、外部委託）を含めます。各対策の費用対効果、実施優先度、必要リソースを明記し、経営判断の材料を提供します。
5. 学習事項 - 組織的な知識共有: Good Points（うまくいった点）とBad Points（改善が必要な点）を率直に評価します。例えば、初動対応の迅速さ、チームワークの良さ、事前準備の効果などを評価し、一方で連絡の遅れ、判断ミス、スキル不足などの課題も明確にします。これらの学習事項を組織全体で共有し、次回のインシデントに備えます。また、今回の経験を踏まえた対応マニュアルの改訂も実施します。

FAQ（よくある質問）

Q: 攻撃中にサービスを完全停止すべきですか？: A: 状況によりますが、基本的には**完全停止は最終手段**です。多くの場合、攻撃トラフィックの遮断や制限により、正常なサービスを維持しながら防御できます。ただし、以下の場合は一時停止を検討すべきです：（1）データ漏洩や改ざんのリスクがある場合、（2）システムリソースが完全に枯渇し、部分的な対策では効果がない場合、（3）攻撃がSQLインジェクションなど、別の攻撃と組み合わされている場合。停止する際は、メンテナンスページを表示し、復旧見込み時間を明記することで、顧客の不安を軽減します。また、停止期間中も攻撃分析と対策準備を進め、再開時に同じ攻撃を受けないよう万全を期します。
Q: 警察への通報タイミングはいつですか？: A: 以下の条件のいずれかに該当する場合は、**速やかに通報**することを推奨します：（1）金銭要求や脅迫がある場合（即座に通報）、（2）重要インフラや人命に関わるサービスへの攻撃、（3）国家的な攻撃の可能性、（4）被害額が明確で告訴を検討する場合。通報は#9110（警察相談専用電話）または所轄のサイバー犯罪対策課へ。通報により、捜査への協力義務が生じる可能性がありますが、法的措置や保険請求の際には警察への被害届が必要となることが多いため、早期の相談が有益です。
Q: 攻撃者との交渉はすべきですか？: A: **原則として交渉は推奨しません**。特に金銭要求には絶対に応じてはいけません。理由は：（1）支払っても攻撃が止まる保証がない、（2）一度支払うと繰り返し標的にされる、（3）犯罪者への資金提供となる、（4）他の攻撃者も誘引する。ただし、攻撃者からの連絡内容は重要な証拠となるため、全て保存してください。対応は法執行機関や専門のセキュリティ企業に相談し、適切な指導を受けることが重要です。
Q: 復旧を急ぐべきか、原因究明を優先すべきか？: A: **ビジネス影響を最小化することが最優先**ですが、証拠保全も重要です。理想的な対応は：（1）最小限の証拠保全（ログバックアップ、スクリーンショット）を5分以内に実施、（2）サービス復旧に注力し、ビジネスを正常化、（3）復旧後に詳細な原因究明と分析を実施。ただし、アカウント乗っ取りや情報漏洩の疑いがある場合は、被害拡大防止のため原因究明を優先する必要があります。判断に迷う場合は、経営層と相談し、ビジネス優先順位を明確にしてから対応します。
Q: 顧客データが漏洩した可能性がある場合は？: A: **個人情報漏洩の可能性がある場合**は、特別な対応が必要です：（1）即座に詳細調査を開始し、漏洩の有無と範囲を特定、（2）確認され次第、個人情報保護委員会への報告（速報は3日以内）、（3）影響を受ける個人への通知、（4）データ漏洩対応の専門家やフォレンジック業者への相談。DDoS攻撃は他の攻撃のカモフラージュとして使われることもあるため、ログを詳細に分析し、不正アクセスの痕跡がないか確認することが重要です。
Q: 再発した場合の対応は？: A: 短期間での再発は、**前回の対策が不十分**だったことを示しています。対応方針：（1）前回の対策を即座に適用し、基本防御を確立、（2）攻撃パターンの変化を分析し、新たな対策を追加、（3）より強力なDDoS対策サービスの導入を検討、（4）24時間監視体制の構築、（5）インシデントレスポンス・リテイナー契約の締結。再発は攻撃者が執拗であることを示すため、組織的・継続的な攻撃（APT）の可能性も考慮し、包括的なセキュリティ強化を図る必要があります。

まとめ：備えあれば憂いなし

DDoS攻撃への対応は、事前準備が成否を分けます。本マニュアルで解説した内容を、平時から準備・訓練しておくことが重要です。

緊急対応の成功要因：

明確な役割分担と指揮命令系統
段階的なエスカレーション基準
すぐ使える対応手順とツール
適切な証拠保全と記録
段階的で安全な復旧プロセス

平時の準備事項：

対応マニュアルの印刷と配布
緊急連絡先リストの定期更新
月1回の机上訓練実施
DDoS対策サービスの事前契約
ログ保存容量の確保

継続的改善：
インシデント対応は、経験を重ねることで向上します。各インシデントから学んだ教訓を組織知として蓄積し、対応能力を継続的に強化してください。

「備えあれば憂いなし」—平時の準備と訓練が、有事の際の迅速で的確な対応を可能にします。

【重要なお知らせ】

本マニュアルは一般的なガイドラインであり、個々の状況に応じた判断が必要です
法的対応については、必ず専門家や法執行機関に相談してください
証拠保全は法的要件を満たすよう、適切な手順で実施してください
個人情報漏洩の可能性がある場合は、個人情報保護法に基づく対応が必要です
最新の脅威情報はJPCERT/CC等で確認してください

更新履歴

2025年11月07日: 初稿公開