Recovery Planは、すでに作成されています。
以前実施したTabletop Exerciseも、うまくいきました。
チームは、これで準備ができていると考えていました。
しかし、実際に復旧用のツールや手順を初めて使おうとしたとき、思いがけない問題が見つかりました。
ここで疑問が生じます。
「書かれている内容と、実際にできることは、なぜ同じではないのか。」
この章では、この違いについて考えていきます。
16.1 書いてあることと、実際にできることは同じではない
Chapter 15では、Restoreが終わったことと、Recoveryが成功したことは同じではないことを見ました。この章では、その考え方をさらに一歩進めます。
Recovery Planが書かれていることや、過去にTabletop Exerciseがうまくいったことは、それだけでは、実際にRecovery capabilityがあることを証明しません。
書かれた計画や、過去の議論ベースの確認は、それぞれ有用ではありますが、実際に手を動かして確認したこととは別のものです。
この章では、Recovery capabilityをどのようにtest・exerciseし、そこで見つかった問題（Gap）をどのように改善へつなげていくかについて考えます。
16.2 Test / Exerciseは何を確認するのか
TestやExerciseは、それぞれ異なる性質を確認します。
システムやコンポーネントが実際に動作するかどうかという確認と、計画・役割・準備状況（plan/role/readiness）についての確認は、混同してはいけません。
例えば、あるTestがシステムの技術的な動作を確認するものであったとしても、それは、担当者がその手順を実際に実行できる状態にあるかどうかまでを確認したことにはなりません。逆も同様です。
TestやExerciseの結果を見るときは、それが具体的に何を確認したものなのかを、はっきりさせておく必要があります。
16.3 Tabletop ExerciseとFunctional Exercise
TestやExerciseにはいくつかの種類がありますが、ここでは、そのうちの二つの違いを取り上げます。
Tabletop Exerciseは、議論を中心とした確認方法です。関係者が集まり、想定される状況について話し合いながら、対応の流れを確認します。
Functional Exerciseは、模擬的な環境の中で、実際に役割を演じながら操作を行う確認方法です。議論だけでなく、実際の操作や役割の遂行が求められます。
この二つは、性質が大きく異なります。
Tabletop Exerciseがうまくいったということは、それだけでは、技術的にRecoveryが可能であることを証明しません。議論の中で「うまくいきそうだ」と確認できたことと、実際に操作を行って確認できたことは、別のものです。
| 種類 | 何を確認するか | それだけでは証明しないこと |
|---|---|---|
| Tabletop Exercise | 対応の流れについての関係者の理解や合意 | 技術的に実際にRecoveryが可能かどうか |
| Functional Exercise | 模擬環境における実際の操作・役割の遂行 | 業務として実際に利用できる状態になるかどうか |
16.4 Recovery tools / proceduresも検証対象になる
実際に頼ることになるRecovery tools・proceduresは、それ自体もあらかじめtest・exerciseしておく必要があります。
Recovery Planの中で、あるツールや手順を使うことになっていても、それが実際に使われたことがなければ、いざというときに問題なく動作するかどうかは分かりません。
例えば、Restore用のスクリプト、Recovery用のアクセスツール、手順書に書かれた操作手順などは、いずれも実際に頼る前に、一度は試しておくことが望ましいと考えられます。
これらのツールをどのように設計・実装するか、どのような自動化の仕組みを使うかといった内容については、この章では扱いません。
16.5 TestでGapを見つける
TestやExerciseを行う目的の一つは、実際にやってみなければ分からなかった問題、つまりGapを見つけることです。
うまくいく場面ばかりを確認するテスト、いわゆるhappy pathだけのテストでは、通常とは異なる状況、例えば何らかの依存要素が使えない状況や、想定外の妨げが生じる状況でのRecoveryについては、十分な確認になりません。
ただし、この章では、具体的にどのような状況を必ず想定してテストしなければならないかという、決まったシナリオの一覧を示すことはしません。どのような状況を想定するかは、対象となるシステムや組織によって異なります。
16.6 Gapを改善へ戻し、Retestする
Gapが見つかったら、それを何らかの形で改善につなげる必要があります。
この本では、この一連の流れを、次のような循環として整理します。
Plan → Test / Exercise → Gap → Improve Plan / Dependency / Procedure → Retest
TestやExerciseの結果は、Recovery PlanやProcedureの改善に反映されるべきものです。改善の対象には、Planそのものだけでなく、依存関係（Dependency）に関する情報や、手順（Procedure）も含まれ得ます。
改善を行った後は、それが実際に機能するかどうかを、再びtestする（Retest）ことも、この循環の一部として考えられます。
この循環は、この本がここまでの複数の観点を整理してまとめたものであり、NISTやCISAが定めた標準的なタキソノミーや、公式のサイクルではありません。
16.7 一度の成功を過剰一般化しない
最後に、一つ注意しておきたい点があります。
一つのTestやExerciseがうまくいったからといって、Recovery capability全体が証明されたわけではありません。異なる種類のTestやExerciseは、それぞれ異なる性質を確認するものであり、一つの結果を、確認していない別の性質にまで広げて考えることはできません。
また、テストで確認できたことが、実際のインシデントでもそのまま成立するとは限りません。テストは、あくまでその時点・その条件のもとでの確認結果です。
TestやExerciseは、Recovery Pointを実際に利用できるかについての確信を高める材料にはなり得ます。ただし、その結果だけで、特定のRecovery Pointがすべての条件で安全であることを証明するわけではなく、確認できるのはテストした時点・範囲・条件に限られます。
16.8 まとめ
この章では、Recovery capabilityをどのようにtest・exerciseし、そこから改善につなげていくかについて整理しました。
重要なのは、次の点です。
- Recovery Planが書かれていることや、過去のTabletop Exerciseの成功は、それだけではRecovery capabilityを証明しない。
- TestやExerciseは、それぞれ異なる性質を確認するものであり、混同してはいけない。
- Tabletop ExerciseとFunctional Exerciseは、性質が大きく異なる。Tabletop Exerciseの成功は、技術的なRecoverabilityを証明しない。
- Recovery tools・proceduresも、実際に頼る前にそれ自体をtest・exerciseしておく必要がある。
- Testを通じて見つかったGapは、Plan・Dependency・Procedureの改善へとつなげ、必要に応じてRetestする。この循環は、この本独自の整理であり、NIST/CISAの標準的なサイクルではない。
- 一つのTest・Exerciseの成功を、確認していない別の性質や、実際のインシデントでの成功にまで過剰に一般化してはならない。
次のChapter 17からは視点を変えて、Backupとは目的の異なるArchiveとRetentionを扱い、その後Chapter 18で法令・規制・Privacy・Contractとの関係を見ていきます。
Chapter 16を読み終えた時点で考えてみてください
自分が担当しているシステムについて、次の質問に答えられるでしょうか。
- 書かれたRecovery Planや、過去のTestの成功だけでは、なぜRecovery capabilityを証明したことにならないのでしょうか。
- Tabletop ExerciseとFunctional Exerciseは、それぞれ何を確認するのでしょうか。
- Recovery tools・proceduresそれ自体を、事前にtest・exerciseしておく必要があるのはなぜでしょうか。
- Plan → Test / Exercise → Gap → Improve Plan / Dependency / Procedure → Retestという循環が、NISTの標準的なサイクルではないのはなぜでしょうか。
- 一つのTestが成功しても、実際のインシデントでの成功が保証されるとは限らないのはなぜでしょうか。
すべて答えられなくても問題ありません。
むしろ、答えに詰まった点があれば、それがこの章で確認しておくべきポイントです。