クラウドストレージにログインできても、業務を復旧できると確認したことにはなりません。バックアップを取り出せるか、誰に連絡できるか、再開前に何を確認するかを、平時に試しておきます。
本記事は2026年11月2日付のNIST CSWP 50正式版、主に12、15、17、19–20ページに基づきます。記入表、テスト方法、完了の目安は筆者による整理です。NISTの原表でも、すべての事故に使える対処コマンドでもありません。進行中の事故で影響範囲を判断できない場合は、対応計画に記載した適切な専門家に連絡します。本記事だけでフォレンジック調査やシステムのクリーンアップを行わないでください。
1. 復旧する必要がある業務を決める
第1回の台帳から重要な提供業務を一つ選び、次の筆者作成の復旧記録を埋めます。
| 項目 | 記入する内容 |
|---|---|
| 復旧する業務 | 中断した提供業務と、関係するデータ、アカウント、端末 |
| 許容できる影響 | どの程度の更新の消失、どの長さの中断まで許容できるか。経営者が決める |
| コピーと保護 | バックアップの内容、場所、読み取り・変更・削除が可能な人やアカウント |
| 別の復旧経路 | 通常の端末や主要アカウントが使えない場合の、提供元のアクセス復旧手順 |
| 検証方法 | 内容が完全で、想定した版であり、業務に利用できることをどう確かめるか |
| 支援と連絡 | 提供元、専門家、そのほか連絡が必要な相手 |
これは業務上の必要条件を決めるための質問です。未検証の復旧時間を約束する根拠にはなりません。NISTはここで、すべてのひとり事業に共通するバックアップ間隔、許容損失量、復旧期限を定めていません。
2. コピーの保護を確認し、復元を試す
原文は定期的なバックアップと複数のコピーを検討し、そのうち少なくとも一つを日常の端末につながっていない媒体に置くことを勧めています。外付けドライブとクラウドが例に挙げられています。バックアップの保護とテスト、クラウド提供元のバックアップ方針の確認も勧めています。ランサムウェアはクラウドアカウントやSaaSにも影響し得るため、クラウドにコピーがあるだけで、分離や復旧可能性を確認したことにはなりません。原文15、17ページ
対象データ、利用できる版、アクセス権、削除権限、復旧手順を確認します。同期、版の保持、バックアップ、復元が同じ範囲をカバーするかは、実際の提供方針に照らして確認します。クラウドを一律に除外せず、同期を自動的に保護されたバックアップとみなさないようにします。
次は、筆者が提案する低リスクの練習方法です。
- 機密情報を含まない、内容が分かっているテスト用データを選び、期待する版を記録する。
- 確認済みのバックアップ手順で保存し、場所とアクセス条件を記録する。
- 業務データを上書きしないテスト用の場所へ復元する。
- 復元した内容を開き、期待する内容・版と比較して、想定用途に使えるか確かめる。
- 結果と制約を記録する。欠落や失敗に次の作業を設定し、再び試す。
記録には「日付、サンプル、保存先、復旧窓口、期待結果、実際の結果、問題、次の作業」を含めます。サンプルの成功が示すのは、そのテスト範囲だけです。すべてのシステムの復旧、フォレンジック調査の完了、悪意ある内容がないことを証明するものではありません。
3. 連絡先と代替業務の情報をオフラインでも取得できるようにする
NISTは、事前の対応計画と定期的な練習、印刷物やオフラインの重要連絡先を勧めています。主要なメールやパソコンを失っても情報を取得できるか確認します。原文2、12ページ
筆者作成の連絡先表には、少なくとも次を記入します。
- サービス提供元：確認済みのサポート・アカウント復旧窓口と、支援できる範囲。
- 専門的支援：事業に適した事故対応、法律、そのほかの連絡先。保険がある場合は、要件、補償範囲、連絡手順も確認する。
- 業務の連絡：必要な顧客・取引先、代替の連絡経路、通知義務の記録場所。
連絡先表にはパスワード、トークン、復旧コードを保存しません。代替の連絡経路と一時的な提供方法を記録し、実際に使えるか確認します。原文には、手作業による代替、一時的な提供方法、予備の連絡経路が例示されています。未検証の代替策を利用できると約束しないでください。原文19ページ
4. 乗っ取りや感染が疑われたら、拡大を抑えて事実を記録する
原文の基本的な封じ込め策には、端末をネットワークから切り離すこと、影響を受けた端末・システムの分離、セッションの無効化、侵害が疑われる端末やアカウントを復旧に使わないことが含まれます。順序は事故と計画によって判断し、汎用のクリーンアップコマンドとしてコピーしないようにします。原文19ページ
計画に沿って提供元や専門家に連絡するときは、同時に時系列の記録を整理します。
最初に発見した時刻とタイムゾーン：____
観察した現象：____
確認できたアカウント・端末・業務への影響：____
まだ確認中の範囲：____
取得できるログ、関連画像、管理された保管場所：____
実施済みの対応、実施者、時刻：____
連絡した相手と次の対応：____この筆者作成の記録は、観察、確認済みの事実、推測を区別します。不審なログイン通知だけで、顧客データすべてが漏えいしたと断定しません。アクセスを復旧する場合は、影響を受けていない端末と確認済みの提供元の手順を使います。主要メール自体が疑わしい場合は、信頼できる予備の連絡経路として扱わないでください。
通知先、内容、期限は、実際に適用される法令、規制、契約、方針によって異なります。本記事は共通の通知期限を定めません。計画に沿って義務を確認し、必要に応じて法律上の支援を求めます。次の筆者作成の文案は既知の情報を整理するためのもので、必要な正式通知には代えられません。
「時刻とタイムゾーン」に「現象」を発見しました。「影響」は確認済みで、「範囲」は引き続き調査中です。現在「対応」を実施しており、「信頼できる経路」で連絡します。
5. 再開前に完全性とアカウント設定を確認する
NISTは、バックアップやほかの資産を再利用する前に完全性を検証し、MFA、ユーザーアカウント、ファイル共有、活動中のセッション、転送ルールを確認するよう勧めています。復旧後に再び影響を受けるリスクを小さくするためです。原文20ページ
復元データが正しく業務に利用できるかと、アカウント・システムの設定を確認できたかは、別々に記録します。パスワードの変更やファイルが開くことだけでは、両方の確認は完了しません。完全性が不明、不審なセッションが残る、覚えのない転送ルールがある場合は、適切な専門家に確認し、復旧済みとしないでください。
実際の要件に従い、顧客や取引先と復旧を調整します。その後、発生内容、対応・復旧の作業、改善点を記録し、資産台帳、設定、計画を更新します。
完了の目安と限界
平時の準備として、取得できるオフラインの連絡先、範囲と結果を残した復元テスト、失敗項目への次の対応を用意します。事故からの復旧を終えられるかは、資産の完全性、アカウント設定、業務の検証、適用される連絡義務の対応状況にも左右され、必要に応じて専門的判断を求めます。
手順を終えれば絶対に安全という共通の保証はありません。本記事は、特定のクラウド、バックアップ製品、実際の事故を検証したものではなく、別添の表計算ファイルにあるNIST付録Iも再現していません。業務と依存関係の変化に合わせて計画を更新します。
抜けがないか第1回：資産とリスクの台帳へ戻り、見つかった設定の問題には第2回：アカウントと端末の保護を利用してください。