ある組織には複数世代のBackupがあります。
- 最新のBackupはRestoreできる
- 少し前のBackupもRestoreできる
- Ransomwareは今日検知された
- ただし、侵害がいつ始まったかは、まだ正確には分かっていない
担当者は考えます。
「RestoreできるBackupの中から、どの時点をRecoveryに採用すべきなのか。」
ここで重要なのは、Restoreできることと、Recoveryに採用してよい状態であることは、同じではないという点です。
この章では、この違いについて整理していきます。
11.1 Restoreできることと、採用できることは同じではない
Chapter 1では、Restore成功とRecovery成功は同じではないことを見ました。この章では、その考え方をさらに一歩進めます。
技術的にBackupからデータを正常に取り出せたとしても、その状態をそのまま本番へ戻してよいとは限りません。
技術的にRestoreできることは、それだけでは、安全なcyber recoveryを構成することを証明しません。
この本では、この関係を次のように整理します。
Restorable Backup ≠ Safe Cyber Recovery
これはこの本での理解を助けるための整理であり、NISTやCISAが定めた標準的な言い回しではありません。
米国国立標準技術研究所、NISTが公開している技術文書でも、復元作業（restoration）と、信頼できる状態の検証を分けて考える必要性が扱われています。この章では、その考え方をたどっていきます。
11.2 「最新」が常に最適とは限らない
Chapter 1では、削除や論理破損、悪意ある変更が起きた場合、より古い既知の正常な状態への復旧が必要になる場合があり、最新の状態が必ずしも正しい復旧状態とは限らないことを見ました。
この章では、この考え方をcyber recoveryの文脈でさらに掘り下げます。
最新のBackupが、必ずしも正しいcyber recovery stateとは限りません。
侵害の後に取得されたBackupは、次のような状態を保持している可能性があります。
- 暗号化された状態
- 破損した状態
- その他、何らかの形で安全とは言えない状態
この本では、この関係を次のように整理します。
Latest Backup ≠ Correct Recovery State
これも、この本での理解を助けるための整理であり、標準用語ではありません。
ここで一つ、注意しておきたいことがあります。この考え方は、「最新のBackupは危険である」という意味ではありません。「最新である」ということが、それだけで正しい復旧状態を自動的に保証するわけではない、ということです。実際にどの時点が適切かは、その時点の状態について分かっている情報に基づいて判断する必要があり、単純に「古いBackupを選べば安全」「何日前まで遡れば安全」という一律のルールがあるわけではありません。
11.3 Recovery Pointの状態をどう確認するか
では、どのようにしてRecovery Pointの状態を確認すればよいのでしょうか。
NISTの技術文書では、cyber recoveryにおいて、次の2つの段階での確認が扱われています。
- 復元に使う資産を、使用する前に確認すること
- 復元されたシステムやデータを、本番へ戻す前に確認すること
つまり、確認は一度だけではなく、少なくとも2つの異なる段階で必要になります。復元に使おうとしているBackupや関連する資産そのものが問題を抱えていないかをまず確認し、実際に復元した後も、その結果を本番投入する前にもう一度確認する、という流れです。
具体的にどのような手順で確認するか、どのようなツールを使うかといった詳細は、この章では扱いません。ここで押さえておきたいのは、「使う前」と「戻す前」という、二段階の確認が必要になるという考え方です。
11.4 「Clean Recovery Point」という呼び方について
この本では、理解しやすさのために、「Clean Recovery Point」という呼び方を候補として使うことがあります。
ただし、これはNISTやCISAが定めた標準用語ではありません。この本での候補的な呼び方です。
実際に、権威ある技術文書が使っている表現には、次のようなものがあります。
- last known good configuration（最後に確認できた正常な構成）
- correct backup version（正しいバックアップのバージョン）
- backup free of malicious code（悪意のあるコードを含まないバックアップ）
- secure or trusted state（安全な、または信頼できる状態）
これらの表現は、それぞれ少しずつニュアンスが異なりますが、いずれも「Clean Recovery Point」という単一の言葉に置き換えられる同義語というわけではありません。この本で「Clean Recovery Point」という言葉を使う場合も、それが標準規格の定義ではなく、教材上の呼び方であることを踏まえておいてください。
11.5 不確実性が残る場合の扱い
サイバー攻撃、特にランサムウェアのような事案では、いつ、どこから問題が始まったのかが、はっきりしない場合があります。
- 侵害が正確にいつ始まったのかが、分からないことがあります
- 調査を進めることで、不確実性を狭めることはできますが、完全に取り除けるとは限りません
ここで大切な考え方があります。
「分からないこと」を、「安全であること」に置き換えてはいけません。
例えば、次のような理由だけで、あるBackupを「クリーンだ」「安全だ」と結論づけるのは適切ではありません。
- Restoreに成功したから
- Immutableとして保護されていたから
- ハッシュ値が一致したから
- ウイルス対策ソフトのスキャンに合格したから
- 検知よりも前に取得されたBackupだから
これらは、それぞれ有用な手がかりにはなり得ますが、単独で「安全である」ことの証明にはなりません。分からないことは分からないままとして扱い、確認できた範囲と、まだ確認できていない範囲を、はっきり区別しておく必要があります。
11.6 次の章への接続
Chapter 10では、Backup自体が攻撃対象になり得ることを見ました。この章では、その問いをさらに進め、たとえコピーが無事であっても、どの時点を実際に信用してRecoveryに採用すべきかを考えてきました。
ここで確認した考え方は、次のような要素にも関係します。
Recovery Pointが実際に役立つかどうかは、そのRecovery Point自体の状態だけでなく、それを利用するために必要な依存要素が利用できるかどうかにも左右されます。この点については、後の章で改めて扱います。
また、通常のアクセス経路が使えない状態からどのようにRecoveryを開始するか、実際の復旧計画をどう組み立てるか、事前のテストによってRecovery Pointへの確信をどう高めるか、といった点も、それぞれ後の章で扱います。
11.7 まとめ
この章では、技術的にRestoreできるBackupと、安全にcyber recoveryへ採用できる状態を区別する考え方を整理しました。
重要なのは、次の点です。
- 技術的にRestoreできることは、それだけでは安全なcyber recoveryを証明しない（Restorable Backup ≠ Safe Cyber Recovery）。
- 最新のBackupが、必ずしも正しいcyber recovery stateとは限らない（Latest Backup ≠ Correct Recovery State）。ただし、これは「最新は危険」という意味ではなく、「最新であることが自動的に正しさを保証しない」という意味である。
- Recovery Pointの状態は、使用前の資産確認と、本番投入前の確認という、少なくとも二段階で確認する必要がある。
- 「Clean Recovery Point」はこの本での候補的な呼び方であり、NIST/CISAの標準用語ではない。
- 侵害開始時点などが不明な場合、その不確実性を「安全である」という結論に置き換えてはならない。
この章で確認する代表的な観点
ここまでの内容を、簡単な表として整理します。
| 観点 | 確認したいこと | それだけでは分からないこと |
|---|---|---|
| Restore可否 | 技術的にデータを取り出せるか | 取り出した状態が安全に使える状態か |
| 使用前の復元資産の確認 | 復元に使うBackupや関連資産に問題がないか | 復元後のシステム全体が安全かどうか |
| 復元後の状態確認 | 復元されたシステムやデータの状態 | 侵害の原因や範囲がすべて分かったかどうか |
| セキュリティ関連の手がかり | ハッシュ一致、スキャン結果、Immutable保護など | それらを満たすだけで安全と断定できるか |
| 業務上の妥当性 | 復元後、業務として実際に使える状態か | セキュリティ上安全かどうか |
この表は、Recovery Pointを自動的に判定するためのチェックリストではなく、この章で確認する代表的な観点を整理したものです。すべての行を満たしたからといって、そのRecovery Pointが自動的に安全であると証明されるわけではありません。
Chapter 11を読み終えた時点で考えてみてください
自分が担当しているシステムについて、次の質問に答えられるでしょうか。
- なぜRestoreできることだけでは、安全なCyber Recoveryを証明できないのでしょうか。
- 最新のBackupが常に正しいRecovery Pointとは限らないのはなぜでしょうか。
- 復元に使う資産と、復元された資産の両方を確認する必要があるのはなぜでしょうか。
- 「Clean Recovery Point」という言葉をNIST/CISAの標準用語として扱ってはいけないのはなぜでしょうか。
- 侵害開始時点が分からない場合に、「分からない」を「安全」と置き換えてはいけないのはなぜでしょうか。
すべて答えられなくても問題ありません。
むしろ、答えに詰まった点があれば、それがこの章で確認しておくべきポイントです。