DDoS攻撃とBCPの関係

サイバーBCPの必要性

従来のBCP（事業継続計画）は自然災害を主な想定脅威としてきましたが、DDoS攻撃をはじめとするサイバー攻撃は、全く異なる特性を持つため、新たなアプローチが必要です。

従来BCPとサイバーBCPの比較分析：

項目	自然災害BCP	サイバーBCP	DDoS特有の考慮点
予兆	ある程度予測可能（気象情報等）	突発的・予兆なし	予告型攻撃も存在（脅迫）
影響範囲	地理的制限あり	全世界同時可能	分散攻撃で複数拠点同時被害
復旧時間	数日〜数週間	数時間〜数日	攻撃継続中は復旧困難
代替手段	別拠点で継続可能	オフライン化必要	完全停止の選択もあり
保険適用	充実した補償	発展途上・免責多い	サイバー保険必須
二次被害	物理的被害中心	情報漏洩・信用失墜	風評被害が甚大
対応要員	全社員で対応可能	専門スキル必要	IT部門への依存大
証拠保全	不要	必須（法的責任）	ログ保存が重要

統合型BCPの必要性：

現代のビジネスはITへの依存度が極めて高く、もはや自然災害とサイバー災害を区別することは現実的ではありません。以下の理由から、統合的なアプローチが不可欠です。

まず、複合災害への備えが重要です。2024年の能登半島地震では、地震による物理的被害に加え、通信インフラの混乱に乗じたサイバー攻撃が確認されました。災害時の混乱は攻撃者にとって好機であり、フィッシング詐欺やビジネスメール詐欺（BEC）も増加します。

次に、依存関係の複雑化があります。クラウドサービス、SaaS、外部APIへの依存により、自社だけでなくサプライチェーン全体のリスクを考慮する必要があります。サプライチェーン攻撃により、取引先経由でDDoS攻撃の影響を受ける可能性もあります。

さらに、規制要件の強化も無視できません。金融庁の「金融機関のITガバナンス」、経済産業省の「サイバーセキュリティ経営ガイドライン」など、サイバーBCPの策定が実質的に義務化されています。ISO22301（事業継続マネジメントシステム）でも、サイバー脅威への対応が要求事項に含まれています。

DDoS攻撃特有の課題：

DDoS攻撃がBCPにおいて特に難しい理由は、その継続性と不確実性です。自然災害は一過性ですが、DDoS攻撃は攻撃者の意思により、いつでも再開・継続される可能性があります。また、攻撃規模も数Gbpsから数Tbpsまで幅広く、事前の被害想定が困難です。

物理的な代替拠点も万能ではありません。インターネットに接続する限り、どこにいてもDDoS攻撃の標的となります。完全なオフライン運用への切り替えを含む、根本的に異なる継続戦略が必要です。

推進体制の構築

効果的なサイバーBCPの実現には、従来の総務主導型から、IT部門と事業部門が協働する体制への転換が不可欠です。

BCM委員会（経営層レベル）- 最高意思決定機関

CEO直轄の組織として設置し、四半期ごとにBCPの有効性をレビューします。メンバーは、CEO、CIO、CFO、CISO、事業部門長で構成。主な役割は、BCPへの投資判断、リスク許容度の決定、重大インシデント時の最終意思決定です。DDoS攻撃では、サービス停止の判断、[緊急予算の承認](/security/networking/ddos/column/legal-insurance/)、対外発表の承認など、経営判断が求められる事項を迅速に決定します。年間予算の1-3%をBCP関連投資に配分することが一般的です。

BCP推進チーム（部門横断）- 実務推進組織

総務部門、IT部門、事業部門から選出された実務者で構成し、月次で会議を開催。BCPの策定・更新、訓練計画の立案、改善施策の実行を担います。DDoS対策では、[RTO/RPO](/security/grc/bcp-dr/)の設定、代替手段の準備、訓練シナリオの作成が主要業務です。各部門に**BCP推進担当者**を配置し、部門固有の要件を収集・反映する体制も重要です。

インシデント対応チーム（24時間体制）- 初動対応組織

24時間365日の監視体制を維持し、DDoS攻撃の検知から初動対応までを担当。[SOC（Security Operation Center）](/security/networking/ddos/column/incident-response/)との連携、または統合運用が理想です。攻撃検知後15分以内にエスカレーション判断を行い、必要に応じてBCP発動を要請。メンバーは最小3名体制とし、ローテーションで対応します。アウトソーシングも選択肢ですが、意思決定プロセスの明確化が重要です。

復旧チーム（専門チーム制）- 復旧実行組織

技術復旧チーム、業務復旧チーム、顧客対応チーム、広報チームの4つの専門チームで構成。技術復旧チームは[CDN切り替え](/security/networking/ddos/column/cdn-defense/)、[WAF設定変更](/security/networking/ddos/column/waf-implementation/)などの技術的対策を実施。業務復旧チームは代替業務プロセスへの切り替えを担当。顧客対応チームはコールセンター増強や個別対応を実施。広報チームは対外発表とSNS対応を行います。各チーム5-10名程度で、相互に情報共有しながら並行作業を進めます。

成熟度モデル

組織のサイバーBCP成熟度を客観的に評価し、段階的な改善を図るための5段階成熟度モデルを提示します。

レベル1：初期段階（場当たり的対応）

• BCP未策定、または形骸化
• DDoS攻撃時は都度判断で対応
• 役割分担が不明確、混乱が発生
• 復旧に数日〜1週間を要する
• 改善指針：まず基本的なBCP文書を作成し、役割を明確化

レベル2：策定段階（文書化完了）

• BCP文書は存在するが、未検証
• 手順書はあるが、実効性は不明
• 年1回程度の見直しのみ
• 復旧に1-3日を要する
• 改善指針：机上訓練を開始し、文書の実効性を検証

レベル3：実装段階（手順確立）

• 手順が確立され、定期訓練を実施
• 多層防御の基本実装完了
• 月次で手順書を更新
• 復旧時間は24時間以内
• 改善指針：自動化ツールの導入、代替手段の充実化

レベル4：管理段階（継続的改善）

• PDCAサイクルが機能
• KPIベースの改善管理
• 自動化が進み、人的ミス削減
• 復旧時間は4時間以内
• 改善指針：予測的対応への移行、AIツールの活用

レベル5：最適化段階（予測的対応）

• 予兆検知と自動対応
• AI/機械学習による最適化
• ゼロダウンタイムを実現
• 攻撃を事前に回避
• 継続目標：新たな脅威への適応、業界リーダーとしての貢献

成熟度評価チェックリスト（各項目1点、合計点で判定）：
□ BCP文書が存在し、1年以内に更新されている
□ DDoS攻撃シナリオが明文化されている
□ 役割分担（RACI）が明確である
□ 年2回以上の訓練を実施している
□ RTO/RPOが設定され、達成率を測定している
□ 代替手段が準備され、切り替え手順が確立している
□ 外部ベンダーとの連携体制がある
□ 経営層がBCPの重要性を理解し、投資している
□ インシデント後の改善プロセスが機能している
□ 他社事例を収集し、自社BCPに反映している

評価基準：0-2点（レベル1）、3-4点（レベル2）、5-6点（レベル3）、7-8点（レベル4）、9-10点（レベル5）

---

事業影響度分析（BIA）

DDoS攻撃による事業影響評価

事業影響度分析（Business Impact Analysis: BIA）は、DDoS攻撃が各業務プロセスに与える影響を定量的に評価し、優先順位付けの根拠とする重要なプロセスです。

業務プロセス別の影響度マトリックス：

業務プロセス	重要度	許容停止時間	DDoS攻撃の影響	1時間あたりの損失額	代替手段
ECサイト運営	最重要	1時間	直接的・即座	500万円（売上喪失）	電話/FAX受注
基幹システム	重要	4時間	間接的・遅延	200万円（業務停滞）	スタンドアロン版
顧客サポート	重要	2時間	直接的・部分	150万円（顧客離反）	電話回線増強
メールシステム	中	8時間	間接的・部分	50万円（生産性低下）	携帯キャリアメール
社内ポータル	低	24時間	軽微	10万円（情報共有遅延）	掲示板・回覧
マーケティングサイト	中	12時間	直接的・限定	30万円（リード喪失）	SNS広告

影響の連鎖分析（カスケード効果）：

DDoS攻撃発生
 ├→ Webサイト停止
 │   ├→ 新規受注停止 → 日次売上30%減少 → キャッシュフロー悪化
 │   ├→ 既存顧客のアクセス不可 → 顧客満足度低下 → LTV20%低下
 │   └→ SEOランキング低下 → 検索流入40%減少（3ヶ月継続）
 │
 ├→ API停止
 │   ├→ 連携サービス停止 → パートナー企業の業務停止 → 損害賠償リスク
 │   ├→ モバイルアプリ機能不全 → アプリ評価1.5ポイント低下 → DAU30%減少  
 │   └→ 外部データ連携断絶 → リアルタイム分析不可 → 意思決定遅延
 │
 └→ メールシステム停止
	 ├→ 社内コミュニケーション断絶 → 対応遅延2時間 → 被害拡大
	 ├→ 顧客連絡不可 → クレーム増加300% → 対応コスト増
	 └→ 取引先連絡不可 → 納期遅延 → 違約金発生

この連鎖分析により、一見軽微に見える影響も、時間経過とともに幾何級数的に拡大することが明らかになります。特に、顧客接点となるシステムの停止は、直接的な売上損失だけでなく、ブランドイメージや顧客ロイヤリティへの長期的影響を考慮する必要があります。

定性的影響の評価：

金額換算が困難な影響も、BIAでは重要な評価項目です：

• レピュテーション損失：SNSでの炎上、メディア報道によるブランド毀損
• 競争優位性の喪失：競合他社への顧客流出、市場シェアの低下
• 法規制違反リスク：SLA違反、個人情報保護法違反
• 従業員モラル低下：残業増加、ストレス増大による離職率上昇
• イノベーション停滞：復旧対応でリソースが奪われ、新規開発が遅延

RTO/RPOの設定

復旧目標を明確に定義することで、投資判断の根拠となり、訓練の達成目標が明確になります。

RTO（Recovery Time Objective）- 目標復旧時間

DDoS攻撃においては、攻撃の規模と継続性を考慮した**段階的RTO**の設定が現実的です。レベル1（軽微な攻撃/10Gbps未満）：1時間以内に自動対策で復旧。レベル2（中規模攻撃/10-100Gbps）：4時間以内に手動対策を含めて復旧。レベル3（大規模攻撃/100Gbps以上）：24時間以内に代替手段を含めて事業継続。この段階的アプローチにより、過剰な投資を避けながら、現実的な目標設定が可能になります。

RPO（Recovery Point Objective）- 目標復旧時点

DDoS攻撃は主にサービス可用性への攻撃であり、データ損失は通常発生しません。しかし、ランサムウェアとの複合攻撃や、攻撃中の不正アクセスによるデータ改ざんのリスクがあります。そのため、RPOは通常業務と同じ基準（例：1時間ごとのバックアップ）を維持しつつ、攻撃検知時点でのスナップショット取得を追加要件とします。クラウドサービスでは、リアルタイムレプリケーションにより、RPOをほぼゼロにすることも可能です。

MTD（Maximum Tolerable Downtime）- 最大許容停止時間

事業が破綻する限界点を示す指標です。一般的なEコマースでは48-72時間が限界とされますが、金融取引システムでは4時間、医療システムでは1時間など、業界特性により大きく異なります。MTDを超えると、顧客の永久離脱、取引停止、事業免許取消などの回復不能な損害が発生します。この時間を明確にすることで、BCP投資の上限が決まります。

業務プロセス別RTO/RPO設定例：

業務システム	RTO	RPO	MTD	設定根拠
決済システム	30分	0分	2時間	PCI DSS要件、顧客影響甚大
受注システム	1時間	15分	8時間	売上直結、代替手段あり
在庫管理	4時間	1時間	24時間	リアルタイム性は中程度
経理システム	8時間	4時間	48時間	月次処理以外は許容可
人事システム	24時間	24時間	1週間	給与計算期以外は影響小

優先復旧業務の選定

限られたリソースで効果的な復旧を実現するため、優先順位付けマトリックスによる客観的な選定が重要です。

優先順位決定要因：

1. 顧客影響度（40%のウェイト）

   • 高：直接的なサービス提供、顧客データアクセス
   • 中：間接的なサービス支援、情報提供
   • 低：社内業務、バックオフィス

2. 収益影響度（30%のウェイト）

   • 高：売上の50%以上に影響
   • 中：売上の10-50%に影響
   • 低：売上の10%未満

3. 法規制要件（20%のウェイト）

   • あり：金融取引、医療情報、個人情報を扱う
   • なし：一般的な業務情報のみ

4. 代替手段の可用性（10%のウェイト）

   • なし：システムでのみ実行可能
   • あり：手動またはオフラインで代替可能

3段階の復旧グループ分類：

グループ1（即時復旧：RTO 1時間以内）

• オンライン決済システム
• 顧客認証基盤
• 緊急連絡システム
• これらは事業の生命線であり、専用のDDoS対策と冗長化が必須

グループ2（優先復旧：RTO 4時間以内）

• 受発注システム
• 在庫管理システム
• CRMシステム
• 手動代替は可能だが、効率が著しく低下する業務

グループ3（通常復旧：RTO 24時間以内）

• 社内ポータル
• ナレッジベース
• 開発環境
• 一時的な停止が許容される業務

---

代替手段の準備

オフライン業務への切り替え

DDoS攻撃の特性上、インターネット接続を前提とした代替策では不十分です。完全オフライン運用への切り替え準備が、真の事業継続を実現します。

オンライン業務の代替手段マッピング：

通常業務（オンライン）	代替手段（オフライン）	必要な事前準備	切替所要時間	処理能力
Web受注	電話/FAX受注	受注票印刷、要員教育、回線増設	30分	通常の20%
オンライン決済	銀行振込/代引き	与信枠リスト、請求書発行体制	即時	制限なし
クラウドERP	ローカルスタンドアロン版	日次データ同期、端末準備	2時間	通常の50%
ビデオ会議	電話会議/対面	緊急連絡網、会議室確保	10分	通常の70%
電子承認	紙面承認	承認フォーム、代理承認規定	1時間	通常の30%
チャット	内線電話/SMS	携帯番号リスト、SMS一斉送信	即時	情報量限定

切り替え判断基準とトリガー：

オフライン切り替えの判断は、以下の明確な基準に基づいて行います：

1. 自動トリガー（システム判断）

   • Webサイト応答時間が30秒超過（5分間継続）
   • エラー率が50%超過（3分間継続）
   • 監視システムからの自動アラート

2. 手動トリガー（人的判断）

   • 攻撃規模が100Gbps超過
   • 復旧見込みが2時間以上
   • 顧客クレームが10件/分を超過

3. エスカレーショントリガー

   • 経営判断による即時切り替え
   • 重要イベント時の予防的切り替え

オフライン受注票サンプル：

━━━━━━━━━━━━━━━━━━━━━━━━━━━
緊急時受注票（DDoS攻撃時用）    No.________
━━━━━━━━━━━━━━━━━━━━━━━━━━━
受注日時：2025年___月___日 ___時___分
担当者：________________

【顧客情報】
会社名：_________________________________
担当者名：_______________________________  
電話番号：_______________________________
既存顧客ID（分かれば）：_________________

【注文内容】
商品コード | 商品名 | 数量 | 単価 | 金額
__________|________|_____|______|______
__________|________|_____|______|______
__________|________|_____|______|______

【配送情報】
配送先：_________________________________
希望納期：_______________________________
特記事項：_______________________________

【決済方法】
□銀行振込（後日請求） □代金引換 
□売掛（与信確認要：限度額________万円）

【処理記録】
システム復旧後入力：___月___日 処理者：_______
伝票番号：_______________________________
━━━━━━━━━━━━━━━━━━━━━━━━━━━

代替サイトの準備

完全停止を避けるため、機能を限定した代替サイトを事前に準備することが重要です。

3段階の代替サイト戦略：

1. 静的サイト（最小機能）

   Amazon S3 + CloudFrontなどの静的ホスティングで、最低限の情報提供を継続します。動的機能は一切なく、会社情報、連絡先、障害告知のみを掲載。月額コストは1,000円程度で、設定も簡単です。通常時からemergency.example.comなどのサブドメインで公開しておき、DNSを切り替えるだけで移行可能にします。

2. 縮退サイト（基本機能）

   別ドメイン（例：example-backup.com）で、主要機能のみを提供する軽量版サイトです。商品検索、在庫確認、問い合わせフォームなど、最低限の双方向機能を維持。通常の1/10程度のリソースで動作するよう設計し、CDN保護下で常時スタンバイ。データは1時間ごとに同期し、切り替え時の差分を最小化します。

3. フルバックアップ（完全代替）

   別クラウドリージョン、または別クラウドプロバイダーに完全な代替環境を構築。コストは高額（月額数十万円）ですが、RTOを最小化できます。平常時はステージング環境として活用し、投資の無駄を防ぎます。マルチクラウド戦略の一環として、ベンダーロックインも回避できます。

緊急時静的ページの実装例：

<!DOCTYPE html>
<html lang="ja">
<head>
	<meta charset="UTF-8">
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
	<title>【重要】システム障害のお知らせ - 株式会社Example</title>
	<style>
		body { 
			font-family: sans-serif; 
			max-width: 800px; 
			margin: 0 auto; 
			padding: 20px;
			background: #f0f0f0;
		}
		.alert {
			background: #fff3cd;
			border: 2px solid #ffc107;
			padding: 20px;
			margin: 20px 0;
			border-radius: 5px;
		}
		.contact {
			background: white;
			padding: 20px;
			border-radius: 5px;
		}
		h1 { color: #d32f2f; }
		.update-time {
			color: #666;
			font-size: 0.9em;
		}
	</style>
</head>
<body>
	<h1>【重要】システム障害のお知らせ</h1>
	
	<div class="alert">
		<strong>現在、システム障害により、オンラインサービスをご利用いただけません。</strong><br>
		ご迷惑をおかけして誠に申し訳ございません。
	</div>

	<div class="contact">
		<h2>お急ぎのお客様は以下までご連絡ください</h2>
		<ul>
			<li><strong>電話受付（24時間対応）</strong><br>
				0120-XXX-XXXX（フリーダイヤル）<br>
				※現在、お電話が大変混み合っております
			</li>
			<li><strong>FAX受付</strong><br>
				03-XXXX-XXXX<br>
				<a href="order-form.pdf">注文用紙ダウンロード（PDF）</a>
			</li>
			<li><strong>緊急メール窓口</strong><br>
				emergency@example.com<br>
				※返信に時間を要する場合があります
			</li>
		</ul>
	</div>

	<h2>復旧状況</h2>
	<p>現在、全力で復旧作業を進めております。</p>
	<ul>
		<li>障害発生：2025年XX月XX日 XX時XX分</li>
		<li>復旧見込み：2025年XX月XX日 XX時頃</li>
		<li class="update-time">最終更新：2025年XX月XX日 XX時XX分</li>
	</ul>

	<h2>最新情報</h2>
	<p>以下のSNSでも随時情報を発信しております：</p>
	<ul>
		<li>Twitter: <a href="https://twitter.com/example">@example</a></li>
		<li>Facebook: <a href="https://facebook.com/example">facebook.com/example</a></li>
	</ul>

	<footer>
		<p>株式会社Example<br>
		〒100-0001 東京都千代田区...<br>
		© 2025 Example Corp. All rights reserved.</p>
	</footer>
</body>
</html>

コミュニケーション手段の確保

DDoS攻撃により通常の通信手段が使用不能になることを想定し、多層的な代替通信手段を準備します。

社内連絡 - 従業員への確実な情報伝達

主要な代替手段として、携帯電話網（音声通話）は最も信頼性が高く、データ通信が不安定でも利用可能です。全従業員の携帯番号を記載した紙の緊急連絡網を、各部門で保管します。SMS一斉送信システム（Twilio等）は、簡潔な指示伝達に有効で、既読確認も可能です。災害用伝言板（171）は、通信輻輳時でも優先接続されるため、安否確認に活用できます。フィッシング対策として、事前に決めた合言葉を使用することも重要です。Slack/Teamsは別インフラ（AWS/Azure）で動作するため、自社システム停止時も利用可能ですが、認証システムとの依存関係に注意が必要です。

顧客連絡 - 信頼性の維持と二次被害防止

公式TwitterなどのSNSは、リアルタイム情報発信に最適で、顧客も確認しやすい媒体です。ただし、偽アカウントによるなりすましに注意し、認証マーク付きアカウントを使用します。プレスリリース配信は、メディア経由での情報拡散により、広範な周知が可能です。コールセンターは、外部委託先も含めて回線を増強し、想定の3倍の入電に対応できる体制を準備します。定型的な問い合わせにはIVR（自動音声応答）を活用し、オペレーター負荷を軽減します。重要顧客には、営業担当から個別に電話連絡を行い、影響を最小化します。

取引先連絡 - サプライチェーンへの影響最小化

事前に構築した緊急連絡網により、主要取引先のIT担当者へ直接連絡します。業界団体や商工会議所経由での一斉連絡も、効率的な情報伝達手段です。EDI（電子データ交換）が停止した場合は、FAXやメールでの代替発注に切り替えます。サプライチェーン全体での影響を考慮し、2次、3次取引先への情報伝達も重要です。定期的な連絡先更新（四半期ごと）と、連絡訓練の実施により、実効性を担保します。

---

訓練と改善

机上訓練シナリオ

机上訓練（Table Top Exercise: TTX）は、実システムに影響を与えずに意思決定プロセスを検証できる効果的な訓練方法です。

シナリオA：通常営業時間中の段階的エスカレーション型攻撃

【訓練シナリオ：平日火曜日のDDoS攻撃】

09:00 - 監視アラート（軽微）
- トラフィック通常の2倍（20Gbps）を検知
- Webサイト応答速度が3秒から5秒に低下
[質問1] この時点での対応は？エスカレーションは必要か？

09:15 - サービス劣化の進行  
- トラフィック50Gbpsに増加
- エラー率10%、応答時間10秒超過
- SNSで「サイトが重い」との投稿が5件
[質問2] BCP発動の判断は？顧客への告知は？

09:30 - 全面的なサービス停止
- トラフィック200Gbps、完全にアクセス不能
- コールセンターへの問い合わせが急増（通常の10倍）
- 競合他社のサイトで「緊急割引セール」開始
[質問3] 代替サイトへの切り替え判断は？広報対応は？

10:00 - 対策本部設置
- CEOが対策本部長に就任
- 攻撃元の7割が海外（主に東欧）
- 攻撃者から「500BTC支払えば止める」とのメール
[質問4] 警察への通報は？身代金への対応は？

11:00 - メディアからの取材
- 大手ニュースサイトが「〇〇社にサイバー攻撃」と報道
- 株価が3%下落
- 金融庁から状況確認の連絡
[質問5] 対外発表の内容は？ステークホルダーへの説明は？

14:00 - 攻撃の沈静化
- トラフィックが50Gbpsに減少
- 断続的にアクセス可能な状態
[質問6] サービス再開の判断基準は？再攻撃への備えは？

【振り返りポイント】
・意思決定は適切なタイミングで行われたか
・情報共有は円滑だったか
・代替手段は機能したか
・改善すべき点は何か

シナリオB：連休中の継続的大規模攻撃

【訓練シナリオ：ゴールデンウィーク中の攻撃】

Day1（5月3日）23:00 - 攻撃開始
- 休日当番（1名）が監視中
- 100Gbpsの大規模攻撃を検知
- 自動防御システムが作動するも効果限定的
[質問1] 休日の要員召集基準は？判断権限は？

Day2（5月4日）02:00 - 自動対策の限界
- 攻撃が300Gbpsに増大
- CDNも飽和状態
- 海外からのアクセスも含めて全面遮断すべきか
[質問2] 深夜の意思決定プロセスは？CEO起こすか？

Day2 08:00 - 要員参集と体制構築
- 召集できたのは全体の30%（他は旅行中）
- リモートでの対応指示に混乱
- 主要取引先も休業中で連絡つかず
[質問3] 最小要員での優先順位は？外部支援の要請は？

Day2 14:00 - 攻撃の長期化判明
- 攻撃者が「1週間続ける」と宣言
- 代替サイトも標的に
- 従業員の疲労が蓄積
[質問4] 長期戦への体制は？ローテーションは？

Day3（5月5日）10:00 - 二次被害の発生
- 攻撃に乗じた不正アクセスの痕跡
- 顧客データベースへのアクセス試行
- ランサムウェアの痕跡も発見
[質問5] 複合攻撃への対応は？データ保全は？

Day4（5月6日）- 通常営業日前
- 翌日からの通常営業に影響必至
- 取引先への事前連絡が必要
- メディア対応も必要
[質問6] 営業再開の可否判断は？縮退運用？

【特別な考慮事項】
・休日の権限委譲ルール
・最小要員での運用方法
・長期戦への備え
・複合攻撃への対応

機能訓練の実施

機能訓練では、実際のシステムや手順を使用して、実効性を検証します。

訓練項目別の実施計画：

訓練内容	実施頻度	参加者	所要時間	達成基準（KPI）	評価方法
初動対応訓練	月次	運用チーム（5名）	30分	15分以内に対策開始	実機での時間測定
代替切替訓練	四半期	IT全員（20名）	2時間	1時間以内に切替完了	チェックリスト確認
オフライン訓練	半期	事業部門（50名）	4時間	代替手段での業務遂行	処理件数測定
全体総合訓練	年次	全社（200名）	1日	RTO達成率90%以上	外部監査
夜間訓練	年2回	当直チーム（3名）	2時間	30分以内にエスカレーション	録音記録確認

訓練シナリオの例（代替切替訓練）：

1. 事前準備（訓練1週間前）

   • 参加者への訓練概要通知
   • ただし、開始時刻は非通知（抜き打ち）
   • 評価者の選定と評価シート準備

2. 訓練開始（T+0分）

   • 「DDoS攻撃発生」のメール/電話連絡
   • Webサイトへの模擬負荷投入

3. 初動対応（T+15分目標）

   • 監視ダッシュボード確認
   • インシデント対応チームへの連絡
   • 初期診断の実施

4. 対策実施（T+30分目標）

   • CDN設定変更
   • WAFルール追加
   • Rate Limiting適用

5. 代替切替（T+60分目標）

   • 静的サイトへのDNS切り替え
   • オフライン受注体制の確立
   • 顧客告知の実施

評価指標（KPI）の設定：

• 時間指標：各フェーズの所要時間、RTO達成率
• 品質指標：手順書との適合率、ミスの発生件数
• 連携指標：情報共有の速度、伝達精度
• 顧客指標：問い合わせ対応率、告知までの時間

PDCAサイクル

継続的改善により、BCPの実効性を高め、新たな脅威に対応します。

Plan（計画）フェーズ - 訓練計画の立案：

年間訓練計画を策定し、段階的にレベルを上げていきます。最初は単純なシナリオから始め、徐々に複雑化。最新の攻撃トレンドを反映したシナリオを作成し、現実的な訓練とします。外部専門家によるレッドチーム演習も、年1回は実施することを推奨します。

Do（実行）フェーズ - 訓練の実施と記録：

訓練は必ず記録し、後の分析に活用します。ビデオ録画、音声録音、スクリーンキャプチャ、タイムスタンプ付きログなど、多面的に記録。参加者の行動だけでなく、意思決定プロセスや連携の様子も記録します。

Check（評価）フェーズ - 達成度評価と課題抽出：

定量的評価（KPI達成度）と定性的評価（参加者フィードバック）を組み合わせます。目標未達の項目は、原因分析（なぜなぜ分析）を実施。良好だった点も記録し、ベストプラクティスとして共有します。

Act（改善）フェーズ - BCP改定と次回への反映：

抽出された課題に基づき、BCPを改定します。手順書の修正、体制の見直し、ツールの追加などを実施。改善事項は次回訓練で効果を検証し、PDCAサイクルを継続します。

改善管理表テンプレート：

課題ID	発見日	課題内容	影響度	改善策	担当者	期限	状況
#001	2025/3/1	代替サイト切替に2時間	高	DNS事前設定、TTL短縮	山田	3/31	完了
#002	2025/3/1	緊急連絡網の不備	中	四半期更新ルール化	田中	4/15	進行中
#003	2025/3/1	役割分担の曖昧さ	高	RACI表作成、周知	鈴木	3/20	完了
#004	2025/4/1	夜間対応の遅れ	中	当直権限の拡大	佐藤	5/1	計画中

---

FAQ（よくある質問）

Q: 中小企業でもサイバーBCPは必要ですか？規模的に難しそうです。

A: はい、むしろ中小企業こそサイバーBCPが重要です。大企業と比べてリソースが限られる分、DDoS攻撃の影響は相対的に大きくなります。ただし、大企業と同じレベルは不要です。まず、（1）最重要業務の特定（売上の80%を占める業務）、（2）簡易な代替手段の準備（電話受注、手書き伝票）、（3）最小限の訓練（年2回の机上訓練）から始めてください。費用をかけずにできることも多く、例えば緊急連絡網の作成、無料CDNの導入、クラウドバックアップなどは、すぐに実施可能です。重要なのは完璧を求めず、段階的に改善していくことです。

Q: 訓練の頻度はどの程度が適切ですか？業務への影響が心配です。

A: 訓練頻度は組織の成熟度により異なりますが、最低限として**机上訓練を四半期に1回、機能訓練を年2回**実施することを推奨します。業務影響を最小化するため、（1）机上訓練は会議室で2時間程度、実システムには触らない、（2）機能訓練は閑散期や休日前日の夕方に実施、（3）全体訓練は年1回、事前告知の上で半日程度、という工夫が有効です。また、訓練を「コスト」ではなく「投資」と捉え、訓練で発見した課題により、実際のインシデント時の損害を大幅に削減できることを経営層に説明することも重要です。

Q: DDoS攻撃時、完全停止とサービス継続のどちらを選ぶべきですか？

A: 状況により異なりますが、判断基準を事前に定めておくことが重要です。**完全停止すべきケース**：（1）ランサムウェアなど二次攻撃の兆候がある、（2）データ改ざんや漏洩のリスクがある、（3）防御コストが事業継続の利益を上回る。**縮退運用で継続すべきケース**：（1）単純なDDoS攻撃のみ、（2）代替手段で最低限のサービス提供可能、（3）完全停止による信用失墜が致命的。多くの場合、**段階的アプローチ**が現実的で、まず機能制限→縮退運用→最終的に完全停止という段階を踏みます。

Q: オフライン代替が困難な業務はどうすればよいですか？

A: 完全なオフライン化が困難でも、リスク軽減策はあります。例えば、（1）**時限的処理**：リアルタイム処理を一時的にバッチ処理に変更、（2）**優先順位付け**：VIP顧客のみ手動対応、一般顧客は復旧後に対応、（3）**外部サービス活用**：競合しない他社システムの一時利用、（4）**縮小版サービス**：最小限の機能のみ別インフラで提供。例えば、オンラインゲームなら、ゲームは停止してもユーザーコミュニティ（Discord等）は維持し、補償内容を告知するなど、完全停止以外の選択肢を検討します。

Q: 代替サイトの準備にどの程度の投資が必要ですか？

A: 投資額は求めるレベルにより大きく異なります。**最小構成（静的サイト）**なら、AWS S3+CloudFrontで月額1,000円程度。**中規模（縮退サイト）**は、小規模インスタンス+CDNで月額3-5万円。**完全冗長化**は、本番環境と同等で月額数十万円〜数百万円です。コスト最適化のポイントは、（1）平常時はステージング環境として活用、（2）オートスケーリングで最小構成から開始、（3）マルチクラウドでベンダーロックイン回避。重要なのは、事業影響度分析（BIA）に基づき、必要十分なレベルを選択することです。

Q: 従業員が訓練を嫌がります。どう動機付けすればよいですか？

A: 訓練への動機付けは組織文化の問題でもあります。効果的なアプローチとして、（1）**ゲーミフィケーション**：チーム対抗でスコアを競う、優秀チームを表彰、（2）**実例の共有**：最新の被害事例を紹介し、他人事でないことを認識、（3）**小さな成功体験**：簡単な訓練から始めて達成感を演出、（4）**経営層の参加**：トップが率先して参加することで重要性を示す、（5）**インセンティブ**：訓練参加を人事評価に反映、スキル認定制度の導入。また、訓練を「失敗を探す場」ではなく「改善のための学習機会」と位置付け、心理的安全性を確保することも重要です。

---

まとめ：レジリエントな組織を目指して

DDoS攻撃に対する事業継続計画は、もはや選択肢ではなく必須の経営課題です。本記事で解説した要点を整理します。

サイバーBCP構築の要点：

1. 従来の自然災害BCPとは異なるアプローチが必要
2. IT部門と事業部門の協働による推進体制
3. 事業影響度分析に基づく優先順位付け
4. オンライン/オフラインの柔軟な切り替え
5. 継続的な訓練と改善のサイクル

実践のためのステップ：

• Step1：現状評価（成熟度診断）と体制構築
• Step2：BIAの実施とRTO/RPO設定
• Step3：代替手段の準備と手順書作成
• Step4：段階的な訓練実施
• Step5：PDCAによる継続的改善

投資対効果の考え方：
適切なBCP投資は、一度の大規模インシデントで回収可能です。さらに、平常時の業務改善、従業員のスキル向上、顧客信頼の獲得など、副次的効果も大きいです。

最も重要なのは、完璧を求めずに始めることです。小さな一歩から始め、継続的に改善していくことで、DDoS攻撃だけでなく、あらゆる脅威に対してレジリエント（しなやかで回復力のある）な組織を構築できます。

サイバー脅威は今後も進化し続けますが、適切な準備と訓練により、必ず乗り越えることができます。

---

【重要なお知らせ】

• 本記事の内容は一般的なガイドラインであり、組織特性に応じた調整が必要です
• 訓練シナリオは例示であり、実際の使用には組織に合わせたカスタマイズが必要です
• 法規制要件は業界により異なるため、監督官庁のガイドラインをご確認ください
• BCPは定期的な見直しが必要です（最低年1回）
• 最新の脅威情報はJPCERT/CC等でご確認ください