この章は架空のケースです。
ここで扱う組織は実在しません。この章の内容は、実在する組織の検証や適合性判断ではなく、参照すべき標準アーキテクチャでもなく、特定の製品・ベンダーを推奨するものでもなく、法律相談でもありません。ここまでの各章で整理してきた考え方を、一つの架空のケースに当てはめて統合するための、この本の締めくくりです。
この章の位置づけ
Chapter 1からChapter 18まで、Backup、Recovery、Archiveをめぐるさまざまな観点を、一つずつ確認してきました。
この章では、新しい考え方を追加することはほとんどありません。代わりに、これまでに整理してきた考え方を、一つの架空の組織のケースに当てはめて、実際にどのように考えを進めていくかを確認します。
各節では、それぞれの緊張関係（tension）について、次の順番で考えていきます。
- どのような緊張関係があるか
- どの章の考え方を当てはめるか
- このケースに当てはめるとどうなるか
- それでも分からないまま残ること（UNKNOWN）は何か
架空の組織について
この章で扱う組織は、次の前提だけを持つ、架空の組織です。
- 従業員数はおおよそ50〜150人程度
- ハイブリッド／クラウド併用の中小規模組織
- 全社的なransomware・破壊的侵入が発生した、という想定
候補となるサービスとしては、次のようなものが考えられます（あくまで例であり、すべてが対象というわけではありません）。
- identity / directory
- DNS / network
- file services
- 業務アプリケーション（line-of-business application）
- database
- email / collaboration
- 公開Webサイト
候補となるデータとしては、次のようなものが考えられます（これも例です）。
- 業務データ
- 個人データ
- configuration
- credentials / secrets
- keys / certificates
- ログ
- 長期保持が必要とされる記録
この章では、これ以上に具体的な会社名、国・地域、正確な従業員数、正確なRTO・RPO、正確な保持期間、正確な法的義務、正確な攻撃の時系列、特定の製品名、データ量、予算、復旧に要した正確な時間、正確な組織体制は扱いません。それらは、この架空のケースの前提として与えられていないためです。
想定される脅威に関する前提
このケースでは、次のことが起こり得るという前提を置きます。あくまでこの架空のケースの前提であり、ransomwareに関する一般的な事実として述べているわけではありません。
- 特権的な権限が侵害されている可能性がある
- identity・管理経路が侵害されている、またはまだ信頼できない可能性がある
- アクセス可能なBackup infrastructureが標的にされている可能性がある
- credentialsが窃取されている可能性がある
- 直近のBackup状態にも、侵害された状態が含まれている可能性がある
攻撃者側の具体的な手口や、マルウェアの実装、フォレンジック調査の詳細については、この章では扱いません。
CT-01 — Business PriorityとTechnical Recovery Orderの緊張関係
どのような緊張関係があるか。
業務側は、最も重要なサービスから戻したいと考えます。しかし、技術的に実行可能な順序は、必ずしもその通りにはなりません。
どの章の考え方を当てはめるか。
Chapter 12では、Recoveryが依存要素の問題であることを見ました。Chapter 14では、Business Priority ≠ Technical Recovery Orderという整理を確認しました。
このケースに当てはめると。
この組織でも、業務上重要なアプリケーションが、他の技術要素（例えば、identityやdatabase）に依存している可能性があります。その場合、業務上の優先順位どおりに、単純にアプリケーションから戻せるとは限りません。
それでも分からないまま残ること。
この組織の実際の依存関係が、具体的にどのような構成になっているかは、このケースの前提として与えられていません。したがって、実際にどの順序でRecoveryを進めるべきかは、UNKNOWNのままとします。固定的な順序をここで決めることはしません。
CT-02 — Retention / Immutability / Privacy / Contractの緊張関係
どのような緊張関係があるか。
Immutableな設定での保持と、削除要求や契約上の削除義務が、衝突する場合があります。
どの章の考え方を当てはめるか。
Chapter 17では、Archiveのlifecycle managementには、Retentionだけでなくdispositionも含まれ得ることを見ました。Chapter 18では、保持・削除に関する要求を扱う前に、そのAuthority、Scope、条件、例外などを確認する必要があることを見ました。
このケースに当てはめると。
もし、この組織のデータの一部について、法律や契約に基づく保持・削除の要求が存在するとすれば、それがどのAuthorityから、誰に対して、どのデータについて、どの条件で課されているのかを、まず確認する必要があります。
それでも分からないまま残ること。
この組織がどの国・地域で事業を行っているか、どのような法律や契約の対象になるかは、このケースの前提として与えられていません。したがって、実際にどの義務が適用されるか、そしてImmutableな設定と削除義務のどちらが優先されるかは、UNKNOWNのままとします。この章でも、どちらが勝つかを決めることはしません。
CT-03 — 最新のRecovery Pointと安全なRecovery Pointの緊張関係
どのような緊張関係があるか。
最新のBackupが、そのまま安全に採用できるRecovery Pointとは限りません。
どの章の考え方を当てはめるか。
Chapter 11で見たとおり、Recovery Pointの選定には、その時点の新しさだけでなく、その状態が信頼できるかどうかも考慮する必要があります。
このケースに当てはめると。
この組織で、直近のBackup状態にも侵害された状態が含まれている可能性がある、という前提を置いています。そのため、単に「最新のBackup」を機械的に選ぶのではなく、その状態が信頼できるかどうかを確認する必要があります。
それでも分からないまま残ること。
実際にどの時点のBackupが信頼できる状態であるかは、このケースの前提だけでは分かりません。特定の時点が安全である、あるいは古いBackupの方が安全である、といった判断は、この章では行いません。
CT-04 / CT-05 — 特権管理とAdministrative Isolationの緊張関係
どのような緊張関係があるか。
Backupの管理権限が、通常の管理権限と分離されていない場合、両方が同時に侵害される可能性があります。また、単独の権限者による破壊的な操作をどう防ぐかという問題もあります。
どの章の考え方を当てはめるか。
Chapter 9では、credentialsやkeys、ツールをBackup Infrastructureの一部として保護する考え方を見ました。Chapter 10では、Separation of DutiesやDual Authorizationにより、単一の経路だけで破壊的操作を完結できない仕組みを作れることを見ました。
このケースに当てはめると。
このケースでは、特権的な権限が侵害されている可能性がある、という前提を置いています。そのため、この組織のBackup管理権限が、通常の管理権限からどの程度分離されているか、そして破壊的な操作に複数の認可主体が必要かどうかを、確認する必要がある論点として位置づけます。
それでも分からないまま残ること。
この組織の実際の組織図や、役割分担、権限の設計については、このケースの前提として与えられていません。特定の役職名や、RACIのような枠組みをここで作ることはしません。
CT-06 — Backupが存在することと、実際に使えることの緊張関係
どのような緊張関係があるか。
Backupのコピーが存在しているというだけでは、それが実際にRecoveryに使える状態にあるとは限りません。
どの章の考え方を当てはめるか。
Chapter 9のBackup Infrastructure保護の考え方、そしてChapter 12のdependency（依存要素）の考え方が関係します。「コピーが存在する＝Recoveryできる」という単純化は避ける必要があります。
このケースに当てはめると。
このケースでは、アクセス可能なBackup infrastructureが標的にされている可能性がある、という前提を置いています。Backupのコピー自体が無事であっても、それにアクセスするための経路や、復号に必要な鍵が利用できなければ、実際には使えない場合があります。
それでも分からないまま残ること。
この組織の実際のBackup経路や鍵管理の詳細な構成は、このケースの前提として与えられていません。特定のBackup構成が安全である、あるいは危険であるといった判断は、この章では行いません。
CT-07 — Restore成功とBusiness Recoveryの緊張関係
どのような緊張関係があるか。
技術的にRestoreが成功したことと、業務として実際に復旧できたことは、同じではありません。
どの章の考え方を当てはめるか。
Chapter 15では、Backup creation、Data Restore、System Recovery、Service Recovery、Multi-system / Business Recovery、Trusted-state validationを、異なる確認結果として区別しました。この整理は、この本独自の教材上の観点であり、標準的なタキソノミーではありません。
このケースに当てはめると。
この組織で、あるシステムのデータが復元できたとしても、それだけでは、そのシステムが実際に動作すること、関連するサービスが機能すること、そして業務として実際に利用できることまでは確認できていません。それぞれ別の確認が必要です。
それでも分からないまま残ること。
この組織にとって、どの段階まで確認できれば「業務が復旧した」と言えるのかという具体的な完了基準は、このケースの前提として与えられていません。
CT-08 — 通常の管理経路が使えない場合の緊張関係
どのような緊張関係があるか。
通常のidentityや管理経路、credentials、keys、手順書、管理ツールが利用できない、または信頼できない状態から、どうやってRecoveryを始めるかという問題です。
どの章の考え方を当てはめるか。
Chapter 12では、Recoveryが依存要素の問題であることを、Chapter 13では、通常の管理経路が使えない状態からRecoveryを始めるための経路（bootstrap path、Emergency Access）について整理しました。
このケースに当てはめると。
このケースでは、identity・管理経路が侵害されている、またはまだ信頼できない可能性がある、という前提を置いています。そのため、この組織の設計では、通常のidentityや管理経路が使えない場合に、どのようにRecoveryを始めるかを、あらかじめ考えておく必要がある論点として位置づけます。
それでも分からないまま残ること。
この組織が、実際にそのような代替の経路（Emergency Access）を用意しているかどうか、用意しているとして、それが実際のインシデントで機能するかどうかは、このケースの前提だけでは分かりません。特定の実装方式（break-glass製品や、特定の緊急アカウントの設計）をここで指定することはしません。
Recovery Copyの妥当性を多面的に評価する
ここまで見てきたように、Recoveryにはさまざまな観点が関係します。この本では、それらを整理するための一つの観点として、Recovery Copyの妥当性（suitability）は、複数の観点にわたって評価されるべきであるという考え方を示します。
具体的には、次のような観点が考えられます。
- location（どこに保管されているか）
- network reachability（ネットワーク的に到達できるか）
- identity（アクセスするための認証がどうなっているか）
- administrative authority（管理権限がどうなっているか）
- authorization（利用のための認可がどうなっているか）
- storage（記憶域の状態）
- cryptographic dependencies（暗号鍵などの依存要素）
- retention（保持の状態）
- actual restore accessibility（実際にRestoreに使える状態にあるか）
この整理は、この本がここまでの複数の章の観点を組み合わせてまとめた、一つの教材上の観点であり、NISTやISOなどが定めた標準的なタキソノミーではありません。
これは、Chapter 7で見たFailure Domainの視点を、Recovery Copyに共通する弱点がないか複数の観点から確認するために、教材上さらに整理したものとして捉えることができます。
この観点に、点数や順位をつけることはしません。また、この9つの観点で網羅的にすべてを言い尽くしているとも主張しません。
このケースに当てはめてみます。この組織が保持している複数のBackupコピーについて、例えば、次のような問いを立てることができます。
- そのコピーは、本番環境と同じ管理下にあるか、それとも別の場所にあるか（location）
- そのコピーに、ネットワーク越しに到達できるか（network reachability）
- そのコピーにアクセスするための認証は、通常のidentityと同じものに依存しているか（identity）
- そのコピーの管理権限は、本番環境の管理者と同じか、別か（administrative authority）
- そのコピーの復号や利用に必要な鍵は、どこに、どのように保管されているか（cryptographic dependencies）
このケースでは、これらの問いに対する具体的な答えは与えられていません。この章の目的は、答えを示すことではなく、確認すべき問いそのものを整理することにあります。
Recoveryの依存要素を整理する
Chapter 12で見たように、組織のRecoverabilityは、Backupデータの回復可能性だけでなく、identity、network、暗号鍵などの資産、configuration、tool、その他の依存要素の回復可能性にも依存します。
この組織にとっても、どのサービスが、どの依存要素に依存しているかを整理しておくことが、Recovery設計の出発点になります。ただし、すべてのシステムが同じ依存関係の構造を持つとは限りません。あるサービスの依存関係が、別のサービスにもそのまま当てはまるとは限らない点に、注意が必要です。
通常の経路が使えない場合の備え
Chapter 13で見たように、通常の管理経路が利用できない、またはまだ信頼できない状態からRecoveryを始めるためには、独立して統制されたEmergency Accessのような手段が必要になる場合があります。
この組織の設計でも、次のような問いを立てておくことが考えられます。
- 通常のidentityが使えない場合、どうやって最初の一歩を踏み出すか
- credentialsが信頼できない場合、どうするか
- 必要な鍵が利用できない場合、どうするか
- 手順書自体にアクセスできない場合、どうするか
- 通常の管理ツールが使えない場合、どうするか
これらの問いに対する、この組織固有の答えは、このケースの前提として与えられていません。
BIA・RTO・RPOについて
Chapter 4・Chapter 5ですでに見たように、BIAは業務影響を確認するための出発点であり、RTOとRPOは、それぞれ許容できる停止時間と許容できるデータ損失を表す目標です。RTOは単純なRestoreにかかる時間そのものではなく、RPOは単純なBackup取得間隔そのものでもありません。
この組織にとって、実際のRTO・RPOがどのような値になるかは、このケースの前提として与えられていません。組織固有の入力として、UNKNOWNのままとします。この章で、具体的な数値例を示すことはしません。
Archive / Retentionについて
Chapter 17で見たように、長期間保存しているというだけで、自動的にArchiveになるわけではありません。このケースでも、「長期保持が必要とされる記録」という名前だけで分類を決めず、何のために、どのように保持・管理するのかを確認する必要があります。
この組織にも、「長期保持が必要とされる記録」という、候補となるデータの種類があります。しかし、それが実際にどのようなArchiveとして分類され、どのようなlifecycle managementの対象になるかは、このケースの前提として与えられていません。
Legal / Privacy / Contractについて
Chapter 18では、保持・削除に関する要求について、AuthorityとScopeを区別し、適用条件や例外を確認してから設計へ反映する必要があることを見ました。
この組織がどの国・地域で事業を行っているか、どのような法律・規制・契約の対象になるかは、このケースの前提として与えられていません。この組織に、特定の法律や規制が適用されると仮定することはしません。もし、この組織に何らかの法的な保持・削除の義務が課されているとすれば、Chapter 18で見た7項目を確認することが出発点になります。それ以上の具体的な結論は、このケースの前提だけでは出せません。
この設計をどう検証していくか
ここまで、この架空の組織のケースについて、さまざまな観点から考えてきました。しかし、ここで整理した内容は、あくまで設計上の考え方の整理であり、それが実際に機能するかどうかは、また別の問題です。
Chapter 16で見たように、書かれたPlanや、過去の一度の成功だけでは、実際のRecovery capabilityを証明したことにはなりません。この本では、その確認の流れを、Plan → Test / Exercise → Gap → Improve Plan / Dependency / Procedure → Retestという循環として整理しました。この循環は、この本独自の整理であり、NISTやCISAが定めた標準的なサイクルではありません。
この組織の設計についても、ここで整理した内容が、実際にTest・Exerciseを通じて検証され、見つかったGapがPlanやDependency、Procedureの改善に反映されていく必要があります。この章では、その具体的なTest・Exerciseの設計までは行いません。
まとめ
この章では、Chapter 1からChapter 18までで整理してきた考え方を、一つの架空の組織のケースに当てはめて統合しました。
重要なのは、次の点です。
- このケースは架空のものであり、実在する組織の検証でも、参照アーキテクチャでも、製品選定でも、法律相談でもない。
- Business Priority、Retention/Immutability/Privacy/Contract、Recovery Pointの信頼性、特権管理、Backupの実際の利用可能性、Restore成功とBusiness Recovery、そして通常の管理経路が使えない場合の備えといった、複数の緊張関係が存在する。
- これらの緊張関係は、それぞれ関連する章の考え方を当てはめることで検討できるが、どちらが優先されるか、具体的にどうなるかを、この章で一律に決めることはしない。
- Recovery Copyの妥当性は、location、network reachability、identity、administrative authority、authorization、storage、cryptographic dependencies、retention、actual restore accessibilityといった複数の観点から評価される、というのが、この本での一つの整理である。
- この組織の実際の依存関係、RTO・RPO、保持期間、適用される法律、bootstrap pathの有無、実際にRecoveryが機能するかどうかは、いずれもこのケースの前提だけでは分からず、UNKNOWNのまま残される。
- UNKNOWNのまま残ることは、この章にとって失敗ではなく、想定された結果である。
全章を読み終えた時点で考えてみてください
自分が担当しているシステムについて、次の質問に答えられるでしょうか。
- Business Priorityと、実際に実行可能なTechnical Recovery Orderが異なる場合、どのように考えればよいでしょうか。
- RetentionやImmutabilityと、削除の要求が衝突する可能性がある場合、まず何を確認する必要があるでしょうか。
- Recovery Copyの妥当性を、location・identity・cryptographic dependenciesなど、複数の観点から評価する必要があるのはなぜでしょうか。
- 通常の管理経路が使えない状態から、どのようにRecoveryを始めるかを、あらかじめ考えておく必要があるのはなぜでしょうか。
- この章で整理した設計が、実際に機能するかどうかを確認する仕組みが、なぜ別途必要なのでしょうか。
この本を通じて繰り返し確認してきたように、「分からないこと」を「分かったこと」に置き換えてはいけません。分からないままにしておくべきことを、はっきりと分からないままにしておくことも、Recovery設計の一部です。