ある組織には、検証済みでRestoreできるBackupがあります。
Backupデータ自体は、確かに残っています。
しかし、実際にRecoveryを始めようとすると、次のような問題が見つかります。
- 認証に必要な経路が使えない
- 復号に必要な鍵が利用できない
- Recoveryに必要な、それ以外の依存要素が利用できない
担当者は気づきます。
「Backupデータが存在すること」と「そのBackupを使ってシステムをRecoveryできること」は、同じではない。
この章では、この違いがなぜ生じるのかを整理していきます。
12.1 BackupがあってもRecoveryできない場合がある
これまでの章では、Backupデータそのものの性質や、Recovery Pointとしての信頼性について見てきました。
しかし、Backupデータが存在し、技術的にRestoreできる状態であっても、それだけでRecoveryが完了するとは限りません。
組織のRecovery能力は、Backupデータだけの性質ではなく、そのデータを安全に使うために必要な、さまざまな依存要素の回復可能性にも左右されます。
この本では、この考え方を次のように整理します。
組織のRecoverabilityは、Backupデータの回復可能性だけでなく、identity、network、暗号鍵などの資産、configuration、tool、その他Recoveryに必要な依存要素の回復可能性にも依存する。
これは、この本がここまでの複数の観点を統合して整理した見方であり、単一の権威ある文書がこの全体像をそのまま定めているわけではありません。
12.2 利用可能であることと、信頼できること
依存要素がRecoveryを妨げる場合、その理由は一つとは限りません。
少なくとも、次の2つは別の問題として区別しておく必要があります。
- その依存要素が利用できない場合
- その依存要素は利用できるが、まだ信頼できない場合
例えば、あるシステムへの管理経路そのものが復旧していなければ、それは「利用できない」状態です。一方で、管理経路自体は動いていても、その経路や、それを使ってアクセスしてくる主体が、侵害を受けていないと確認できていなければ、それは「信頼できるとまだ言えない」状態です。
利用できることと、信頼して利用できることは、別の問題です。
「利用できる」ことは、そのまま「信頼できる」ことを意味しません。同じように、「到達できる」ことも、そのまま「安全である」ことを意味しません。この本の中で使ってきた資料でも、通常の管理経路が利用できない場合と、まだ信頼できない場合の両方が、Recoveryを妨げ得る別々の状況として扱われています。
12.3 Recovery dependencyをどう整理するか
ここまで見てきたように、Recoveryは、Backupデータ以外のさまざまな要素にも依存し得ます。
この本では、それらの依存要素を整理するための、一つの統合的な観点を示します。
この整理は、本書がここまでの複数の観点を組み合わせてまとめたものであり、NISTやCISAが単一の公式チェックリストとして定めたものではありません。
以下の表は、代表的な依存要素のグループと、それぞれがRecoveryにどう関係し得るかを整理したものです。
| 依存要素 | Recoveryでなぜ関係するか | 利用できない場合に起こり得ること | この章で扱わない詳細 |
|---|---|---|---|
| Identity / Administrative Access | システムやデータへアクセスするための認証・管理経路が必要になる場合がある | Recoveryを開始・実行できない場合がある | 資格情報分離、MFA、Dual Authorization、Emergency Accessの設計（Chapter 9/10/13） |
| DNS / Network / Time | 必要なサービスの名前解決や到達性、時刻同期に依存する場合がある | 必要なシステムやサービスに到達できない、または時刻に依存する仕組みが正しく動作しない場合がある | DNSアーキテクチャ、ルーティング設計、NTPセキュリティ（本章では扱わない） |
| Storage / Database / Application | Backupデータを実際に格納・展開する記憶域や、データベース、アプリケーション/ランタイムの動作に依存する場合がある | データは残っていても、それを展開・実行する基盤が利用できない場合がある | ストレージレプリケーション理論、データベースリカバリ内部構造、ミドルウェア（本章では扱わない） |
| Keys / Certificates / Secrets | 復号や接続に必要な鍵、証明書、secretに依存する場合がある | Backupデータ自体は残っていても、復号や接続ができない場合がある | PKIアーキテクチャ、KMS/HSM設計、secret管理フレームワーク（本章では扱わない） |
| Configuration / Tools | システムを復元・運用するために必要な設定情報や、復元作業に使うツールに依存する場合がある | 復元先のシステムを正しく構成できない、または復元作業自体を実行できない場合がある | CMDB、IaC、構成管理フレームワーク（本章では扱わない） |
| Monitoring / Validation | 復元した環境が期待どおりに動作しているかを確認する仕組みに依存する場合がある | 復元後の状態を確認・判断する手段がない場合がある | SIEM/SOCアーキテクチャ、監査ログ保護の設計（Chapter 9/10） |
| External Services / Communication | Backupコピー自体には含まれない、外部サービスや連絡手段に依存する場合がある | 必要な外部の連携先や連絡手段が使えない場合がある | 特定のSaaS、CA、クラウドAPIの個別設計（本章では扱わない） |
この表は、Recovery dependencyを自動的に判定するためのチェックリストではありません。すべての行が組織のあらゆる状況に当てはまるとは限らず、また、ここに挙げた分類も、優先順位や重要度の順位付けを意味するものではありません。
12.4 基盤となるDependency
先の表のうち、Identity / Administrative AccessとDNS / Network / Timeは、他の多くの依存要素を利用するための前提になりやすい、基盤的な性質を持っています。
Recoveryには、システムやデータへアクセスするための、機能していて、かつ信頼できる認証・管理経路が必要になる場合があります。この経路自体が使えなければ、他の依存要素が無事であっても、それを利用する手段がありません。
同様に、必要なサービスへの到達性や名前解決、時刻同期についても、それ自体が高度な技術内容というわけではなくても、他の多くの仕組みの前提になっている場合があります。DNSは、必要なサービスの名前解決に使われる場合があります。Networkは、必要なシステムやサービスへの到達性に関係する場合があります。Timeは、一部のシステムやセキュリティの仕組みが、十分に正しい時刻情報に依存している場合があります。
この章では、これらの要素について、それぞれの技術的な仕組みや構成方法までは扱いません。ここで押さえておきたいのは、これらが「基盤的な依存要素になり得る」という考え方です。
なお、資格情報の分離、MFA、Dual Authorization、Emergency Accessといった、これらの経路をどう保護するかという設計については、Chapter 9・Chapter 10ですでに扱ったとおりであり、この章では再度扱いません。
12.5 データを使うためのDependency
Backupデータそのものが残っていても、それを実際に使えるようにするためには、いくつかの依存要素が必要になる場合があります。
Storageについては、Backupコピー自体は残っていても、それをRecoveryのために展開・利用するための記憶域が利用できなければ、実際には使えません。Databaseについては、アプリケーションがデータベースの可用性や状態に依存している場合があります。Application/ランタイムについては、データだけが戻っても、それを扱うために必要なアプリケーションやランタイムが利用できなければ、十分ではない場合があります。
また、Keys / Certificates / Secretsも、この文脈で重要な依存要素です。
Backupデータが残っていても、復号や接続に必要な情報が利用できなければ、そのデータを使えるでしょうか。
鍵、証明書、secretは、それぞれ役割の異なる依存要素です。この本では、教材上の整理としてまとめて扱うことがありますが、これらは同一の概念ではなく、それぞれ別々に利用可能性を確認する必要がある点に注意してください。
Configuration / Toolsについても触れておきます。Recoveryには、システムを復元・構成するために必要な設定情報や、復元作業自体に使うツールが必要になる場合があります。
これらの技術的な内部構造(ストレージのレプリケーション方式、データベースリカバリの内部動作、PKIアーキテクチャ、CMDBやIaCの設計など)については、この章では扱いません。
12.6 Monitoring / Validation / External dependencies
Recoveryには、復元された環境が期待どおりに機能しているかどうかを観察・確認するための仕組みが必要になる場合があります。
Chapter 9では、ログをBackup Infrastructureの一部として保護する考え方を扱いました。Chapter 10では、監査情報の保護について扱いました。この章では、それらを再び扱うのではなく、Monitoring/Loggingの仕組みそのものが、復元後の状態を理解・運用・確認するために必要な依存要素になり得るという点だけを確認します。
また、Recoveryは、Backupコピー自体には含まれない、外部のサービスや連絡手段に依存する場合もあります。特定のサービスや製品を前提とせず、一般的な考え方として押さえておいてください。
SIEMやSOCのアーキテクチャ設計、具体的な外部サービス・CA・クラウドAPIの個別の仕組みについては、この章では扱いません。
Recoveryは、技術要素だけで完結するとは限らず、必要な担当者や手順が利用できることも影響する場合があります。
12.7 Dependencyは単純な順番とは限らない
ここまで見てきた依存要素は、それぞれRecoveryを妨げ得る要素ですが、それらの間に、常に一つの決まった順番があるわけではありません。
依存要素の存在は、Recoveryの順序に制約を与える場合があります。しかし、依存関係を把握しただけで、Recoveryを実行する具体的な順序が自動的に決まるわけではありません。
さらに、依存関係は、単純な一直線の並びになるとは限りません。
あるサービスを戻すために別のサービスが必要で、その別のサービスを戻すために最初のサービスが必要になる、といった循環的な依存が問題になる場合もあります。
この章では、こうした循環的な依存が存在し得るということまでを確認するにとどめ、それをどう解決するかについては扱いません。通常のアクセス経路が使えない状態からどのようにRecoveryを開始するかについては、後の章で扱います。
依存関係を把握すると、実際のRecovery順序を考える材料になります。具体的な復旧計画や実行順序の組み立て方については、後の章で扱います。
12.8 まとめ
この章では、RecoveryがBackupデータだけの問題ではなく、依存関係の問題でもあることを整理しました。
重要なのは、次の点です。
- 組織のRecoverabilityは、Backupデータの回復可能性だけでなく、identity、network、暗号鍵などの資産、configuration、tool、その他の依存要素の回復可能性にも依存する。
- 依存要素は、「利用できない」場合と、「利用できるがまだ信頼できない」場合の、少なくとも2つの異なる理由でRecoveryを妨げ得る。
- この章で示した依存要素の整理は、本書独自の統合的な観点であり、NISTやCISAが単一の公式チェックリストとして定めたものではない。
- 依存要素はRecoveryの順序に制約を与え得るが、それだけで具体的な実行順序が自動的に決まるわけではなく、循環的な依存が存在する場合もある。
Chapter 12を読み終えた時点で考えてみてください
自分が担当しているシステムについて、次の質問に答えられるでしょうか。
- Backupデータが存在していてもRecoveryできない場合があるのはなぜでしょうか。
- Dependencyが「利用可能」であることと「信頼できる」ことは、なぜ別の観点なのでしょうか。
- Identityや鍵以外に、Recoveryが依存し得る要素を2〜3個説明できますか。
- この章のdependency一覧をNIST/CISA公式チェックリストとして扱ってはいけないのはなぜでしょうか。
- Dependencyを把握しただけでは、Recoveryの実行順序が自動的に決まらないのはなぜでしょうか。
すべて答えられなくても問題ありません。
むしろ、答えに詰まった点があれば、それがこの章で確認しておくべきポイントです。