PR

情報セキュリティにおける継続性の設計

この記事は約9分で読めます。

本記事は学習用です。作成には ChatGPT と GitHub Copilot を使用しています。

1. 情報セキュリティの「継続」を扱う理由

情報セキュリティは「侵害を防ぐ」だけでなく、「侵害・停止が起きても重要業務を止めない／止まっても戻す」までを含みます。事業継続計画（BCP: Business Continuity Plan）は、重要業務が中断しないこと、または可能な限り短い期間で再開することを狙いとして位置付けられます。内閣府の事業継続ガイドラインでも、BCPは「経営レベルの戦略的課題」として整理されています。 (防災情報ポータル)

一方で、現場の計画類は分断しがちです。典型的には以下のように別々に作られ、緊急時に「結局どれを見るのか」が曖昧になりがちです。

  • BCP（事業をどう続けるか）
  • 緊急時対応計画（ER/IR：初動で何を止め、誰が判断するか）
  • 復旧計画（DR/ITSC：システムをいつ、どのレベルまで戻すか）
  • 障害復旧（運用手順書・Runbook：手を動かす具体）

この分断を解消するには、「緊急事態の区分」→「判断基準」→「起動する計画」→「復旧目標（RTO/RPO等）」→「具体手順」 の一本線で接続しておくことが重要です。

2. 事業継続計画（BCP）を情報セキュリティに接続する要点

BCPは、自然災害だけの話ではありません。システム障害、ランサムウェア、委託先障害、クラウド障害など、情報セキュリティ起因の停止もBCPの対象に含まれます（脅威カテゴリが違っても、事業影響は同じためです）。ISO 22301は、事業継続マネジメントシステム（BCMS: Business Continuity Management System）の枠組みとして、発生事象への対応・復旧・改善を継続的に回すことを求める考え方として整理されています。 (JQA)

情報セキュリティの継続を設計する際、BCP側が最低限決めておく項目は、次の5つに絞ると運用しやすくなります。

  1. 重要業務（Important Business Services）：止まると困る順に並べます
  2. 最大許容停止時間（MTPD）：その業務が止まって許される限界を定めます
  3. 復旧目標（RTO/RPO/RLO）：どれくらいの時間・時点・レベルで戻すかを定めます
  4. 代替手段：ITが戻るまでの手作業・迂回策を整理します
  5. 意思決定権限：停止判断、切替判断、対外発表判断の権限を明確にします

復旧目標は、IPAが整理する RLO（目標復旧レベル） / RTO（目標復旧時間） / RPO（目標復旧時点） の3点セットで定義すると、IT復旧と業務要件が噛み合いやすくなります。 (情報処理推進機構)

3. 緊急事態の区分：発生事象を「判断可能」にする分類表

緊急時に必要なのは「美しい分類」よりも、誰でも同じ判断に到達できる区分です。例えば「影響（Impact）」と「拡大速度（Urgency）」の2軸で整理し、レベルで運用する方式があります。

3.1 緊急区分の例（4段階）

区分例影響の目安初動の狙い起動する計画
Level 1 軽微単一サーバ障害、限定的な誤設定重要業務に影響なし/小迅速復旧・原因除去障害復旧（Runbook）
Level 2 重大一部サービス停止、性能劣化が継続重要業務に影響/代替で継続可影響封じ込め障害復旧＋（必要により）緊急時対応計画
Level 3 危機ランサム疑い、情報漏えい疑い、広域停止重要業務が停止/法令・契約影響拡大防止・証拠保全緊急時対応計画（IR）＋復旧計画（DR）
Level 4 非常事態甚大漏えい確定、基盤壊滅、長期停止事業継続が困難事業継続へ切替BCP（代替拠点/代替運用）＋DR

ここで重要なのは、サイバー事故（情報漏えい）と可用性事故（停止）を同じ表で扱うことです。JPCERT/CCのCSIRT資料でも、インシデントは「完全回避が難しい」前提に立ち、発生時の対応（準備・手順・役割）が中核になる点が示されています。 (jpcert.or.jp)

3.2 区分判定に使うチェック項目（例）

  • 影響範囲：ユーザー数、拠点数、システム数、委託先波及
  • 重要業務への影響：止まった業務は何か、代替はあるか
  • 法令・契約：個人情報、監督官庁報告、SLA違反
  • 拡大兆候：不審通信増加、暗号化進行、権限昇格の兆候
  • 復旧難易度：バックアップ健全性、再構築可否、鍵の所在

4. 緊急時対応計画：初動の重点（封じ込め＋意思決定）

緊急時対応計画は、現場作業よりも 意思決定とコミュニケーションに重心を置きます。NISTの系統（IPA翻訳含む）では、BCPやDRP等の計画群を整理し、重大な事象時にどの計画を起動するかを明確にする考え方が示されています。 (情報処理推進機構)

4.1 緊急時対応計画（最低限の構成）

  • 目的と適用範囲（どのシステム・委託先まで含むか）
  • 体制（指揮系統、代行順位、連絡網、当番）
  • 区分判定（前セクションの表）
  • 初動プレイブック（停止／隔離／証拠保全の方針と実施内容）
  • 外部連携（法務・広報・委託先・JPCERT/CC等）
  • 記録（タイムライン、判断根拠、実施ログの保全先）

4.2 初動プレイブック例（ランサム疑い）

※フォレンジック、法令対応、対外公表判断などは、緊急区分（Level 3以上）で起動する計画に委ねます。初動はあくまで「拡大防止」と「意思決定に必要な情報収集」に焦点を当てます。初動の作業が複雑化しすぎると、「何を見てどう判断するか」が曖昧になりやすいためです。

T0（検知直後）
- 体制：インシデント指揮官の指名（当番→代行順位）
- 状況把握：影響範囲の一次推定（端末/サーバ/AD/クラウド）
- 拡大防止：感染疑い端末のネットワーク隔離
- 証拠保全：ログ保全（EDR/SIEM/Firewall）と、メモリ/ディスク保全方針の決定

T0+30分
- 判断：緊急区分の確定（Level 3以上の場合はIR計画を起動）
- 事業影響：重要業務の停止/継続判断（BCP観点で代替運用へ切り替えるか）
- データ保護：バックアップ健全性の確認（暗号化波及の有無）

T0+2時間
- 条件分岐：影響拡大が止まらない場合の追加措置（ネットワークセグメント遮断、ID無効化、外部接続遮断）
- 連携：対外連絡（委託先、必要に応じてJPCERT/CCへの相談）

IPA（NIST翻訳）の「インシデント対応ガイド」では、ポリシー→計画→手順→情報共有という階層で整備する点が強調されています。初動の迷いを減らすには、「手順」を計画と一体で管理できる形にしておくことが有効です。 (情報処理推進機構)

5. 復旧計画：復旧順序の決定（RTO/RPO起点）

復旧計画（Recovery Plan）では、復旧作業の根拠を 復旧目標に置きます。復旧目標は次の通り定義します。

  • RTO（Recovery Time Objective）：目標復旧時間
  • RPO（Recovery Point Objective）：目標復旧時点（どこまでデータを戻すか）
  • RLO（Recovery Level Objective）：目標復旧レベル（縮退運転を含む） (情報処理推進機構)

5.1 例：復旧優先度表（サンプル）

業務/システム依存関係RTORPORLO（縮退）復旧方式
認証基盤（IdP/AD等）なし2h15m認証のみ最低限DRサイト切替
顧客向けAPI認証/DB4h30m読み取り優先アプリ再デプロイ
DBストレージ/バックアップ4h30m主要テーブル優先PITR/レプリカ昇格
バッチ基盤DB24h6h停止可後回し

※RTO/RPOは事業要件とコストのトレードオフになります。数値の妥当性は、業務側（責任者）との合意が必要です。

5.2 ICT継続の標準との整合（ISO/IEC 27031）

ISO/IEC 27031は、事業継続のためのICT（情報通信技術）の備えに関するガイダンスとして位置付けられます。BCP（業務継続）とIT側の備え（設計・運用・復旧）を接続する観点で参照しやすい文書です。 (ISO)

6. 障害復旧：Runbook設計（再現性／権限／ログ保全）

障害復旧（Operational Recovery）は、復旧計画を「実行可能」な形に落とす領域です。ここが弱いと、RTO/RPOを決めても達成が難しくなります。

6.1 Runbookに含めたい項目

  • 前提（対象バージョン、構成図、必要権限、保守窓）
  • 入力（どのアラート/メトリクスをトリガにするか）
  • 手順（コマンド、GUI操作、確認観点）
  • ロールバック（失敗時に戻す）
  • 証跡（ログ、チケット、タイムラインの保存先）

6.2 Runbook断片（例：DBフェイルオーバーのチェックリスト）

- 目的：RTO 4h / RPO 30m を満たすため、レプリカ昇格による復旧を実施
1) 影響確認：アプリのエラー率、コネクション、遅延
2) データ保護：現Primaryの最終ログ位置の記録（可能ならスナップショット）
3) 切替：レプリカ昇格→接続先更新→アプリ再起動
4) 整合確認：主要テーブル件数、最新更新時刻、業務テスト（最小）
5) 証跡：操作ログ、判断理由、時刻（T0〜）の記録

※情報漏えい疑いがある場合、復旧を急ぎすぎると証拠が失われる可能性があります。封じ込め・保全の優先順位は、緊急区分（Level 3以上）に応じて切り替えます。

7. 訓練と継続的改善：計画を「動く状態」に保つ運用

計画は作成時点から陳腐化が始まります。そのため、運用に組み込んで「鮮度」を保ちます。ISO 22301/BCMSの発想でも、監視・レビュー・継続的改善を回すことが狙いとして挙げられています。 (JQA)

7.1 最低限の年間サイクル例

頻度実施内容成果物
月次連絡網・権限の棚卸し、バックアップ成功率レビュー差分更新
四半期障害復旧訓練（机上＋一部実機）記録、改善チケット
半期重大インシデント机上演習（ランサム等）タイムライン、意思決定レビュー
年次DR切替訓練（重要系のみでも可）RTO/RPO達成可否、改善計画

机上演習は、IPAが教材（ランサム想定）を公開しており、教育と標準化に活用しやすいです。 (情報処理推進機構)

7.2 よくある失敗パターン

  • 緊急区分が抽象的で、結局「偉い人」の感覚で決まりがちです
  • BCPにRTO/RPOがない（または現実離れした数値になっている）状態です
  • 復旧計画とRunbookの整合が取れず、手順が存在しない状態です
  • 証跡設計がなく、事後レビューが難しくなります
  • 委託先・クラウドの責任分界が計画に含まれていません

8. まとめ：初動迅速化のための5観点（一本線の接続）

情報セキュリティの継続性は、次の接続が成立して初めて機能します。

  1. 事業継続計画（BCP）：重要業務と停止許容（MTPD）を決めます (防災情報ポータル)
  2. 緊急事態の区分：判断基準を表で固定します
  3. 緊急時対応計画：封じ込め・意思決定・連絡を標準化します (jpcert.or.jp)
  4. 復旧計画：RTO/RPO/RLOから復旧順序を決めます (情報処理推進機構)
  5. 障害復旧：Runbookで再現性を担保します

この5つを「区分→起動→目標→手順」の一本線に統合すると、緊急時の迷い（誰が何を見るか）が減り、結果として被害規模と停止時間の圧縮につながります。

A. 参考サイト

  • 内閣府「事業継続ガイドライン 第二版」（PDF） (防災情報ポータル)
  • 内閣府 防災情報「事業継続計画（BCP）の文書構成モデル例等」 (防災情報ポータル)
  • IPA（NIST翻訳）「コンピュータセキュリティ インシデント対応ガイド」（PDF） (情報処理推進機構)
  • JPCERT/CC「インシデントハンドリングマニュアル」（PDF） (jpcert.or.jp)
  • NIST SP 800-34 Rev.1 “Contingency Planning Guide for Federal Information Systems”（PDF） (NIST技術シリーズ出版物)
  • ISO「ISO/IEC 27031（ICT継続のガイダンス）」 (ISO)

B. 関連書籍

コメント