ある組織には、Off-siteかつImmutableとして保護されたBackupコピーがありました。
コピーそのものは、無事でした。
しかし、そのBackupを管理しているのは、一つの管理者アカウントでした。この管理者アカウントからは、Backup jobの設定変更や、保護設定そのものの変更など、管理上重要な操作を行うことができました。
さらに、Recoveryに必要な暗号鍵や管理ツールも、同じ通常の管理経路に依存していました。
担当者は、あらためて考えてみて、次のことに気づきました。
「Backupコピーだけを守れば十分」というわけではありません。それを管理し、実際にRecoveryへ使うための権限や基盤そのものも、保護対象になります。
この章では、Backup infrastructure自身、つまりBackupを支える管理権限、認証情報、鍵、ログ、ツールをどう守るかについて見ていきます。
9.1 コピーが無事でも、それだけでは足りない
Chapter 7と8では、Backupコピー自体の配置や性質について見てきました。複数の場所に分散させること、Off-site・Offline・Isolated・Immutableといった性質を確認すること、いずれもコピーそのものをどう守るかという話でした。
しかし、コピーがどれだけ適切に保護されていても、それを操作し、管理し、実際にRecoveryへ利用するための仕組みが同じ弱点を抱えていれば、結局のところBackup全体としては十分に守られていない場合があります。
この章で扱う中心的な考え方は、次のとおりです。
Recoverabilityは、Backupデータそのものだけでなく、それを安全に使うために必要な管理権限、認証情報、鍵、ツールといった要素にも依存します。
この本では、組織やシステムがRecoveryを実際に行える状態にあることを、Recoverability（復旧可能性）と呼びます。本文中のRecovery capabilityも、特別な技術的区別を示さない限り、この広い意味で使います。
Backup infrastructureそのものを、保護すべき対象の一つとして見ていきましょう。
9.2 Backup管理用の認証情報を分ける
まず考えたいのは、Backupを管理するための認証情報です。
Backupを管理するための認証情報を、通常の本番環境やネットワーク管理用の認証情報と同じものに依存させないことが重要です。
もし、Backupを管理する権限が、日常的な本番システムの管理権限と同じアカウントに紐づいていれば、本番環境の管理権限が侵害されたときに、Backupの管理権限まで一緒に侵害される可能性があります。
この考え方には、次のような関連する要素もあります。
- 必要最小限の権限だけを与える（least privilege）
- 通常のネットワークとは異なる経路で管理する（network segregation）
- 削除など破壊的な操作には、追加の保護（MFAなど）を設ける
これらは、Backup管理用の認証情報を分離するという考え方を補強する要素として、ここでは軽く触れるに留めます。具体的な認証情報の値や、特定製品での設定手順は、この章では扱いません。
9.3 保護を無効化できる権限を確認する
認証情報を分離していても、まだ確認すべきことがあります。
認可分離や追加保護の仕組みが存在していても、保護される側の管理者自身が、その仕組みを無効化・再設定できる十分な権限を持っていれば、保護の効果は限定的になり得ます。
例えば、「重要な操作には追加の承認が必要」という仕組みを導入していても、その仕組み自体を無効にできる権限を、保護対象のBackup管理者がそのまま持っていれば、意図した分離は成立しません。
ここで押さえておきたい問いは、次のものです。
「この保護を無効化できる権限を、誰が持っているか？」
例えばAzureでは、Resource Guardという仕組みにより、重要な操作に対して、通常のBackup管理者とは別の認可境界を設けることができます。ただし、その保護対象であるBackup管理者自身に、Resource Guardを管理する強い権限まで与えてしまうと、意図した分離が弱まる場合があります。
例えばAWSでは、multi-party approvalという、複数の承認者による分散的な承認の仕組みが用意されています。
これらはあくまで特定製品におけるbounded implementation exampleです。製品ごとに実装の仕組みは異なり、どちらか一方がすべての状況で唯一の解決策というわけではありません。
9.4 鍵管理という別の管理対象
Chapter 8では、「誰が保護を解除できるか」を確認する必要があることを見ました。
この章では、その問いを一段進めて、その管理権限そのものは、どう守られているかを考えます。
Chapter 8で見たように、バックアップデータそのものが残っていても、復号に必要な鍵などの暗号材料が失われたり、変更されたり、利用できなくなったりすれば、実際にはそのデータを復旧に使えない場合があります。
この章で新たに考えたいのは、その鍵を管理・変更・削除できる権限を、誰が持っているかという点です。
データだけでなく、復号に必要な鍵を管理する権限も、Recoveryを左右する管理対象です。鍵そのものが安全に保管されていても、その鍵を扱う権限が本番環境の管理権限と同じであれば、9.2で見た問題と同じ構造の弱点になり得ます。
具体的な鍵管理システムの設計や、鍵のローテーション手順については、この章では扱いません。
9.5 ログと管理ツールも保護対象になり得る
Backup Infrastructureを構成する要素は、認証情報や管理権限、鍵だけではありません。
ログ・監査証跡
ログや監査証跡も、Backup Infrastructureの状態や、誰がどのような操作を行ったかを後から確認するために重要な要素になり得ます。
具体的にどのような操作をログすべきか、ログをどれくらいの期間保持すべきか、といった詳細な設計は、この章では扱いません。ここでは、ログ自体も保護すべき対象の一つとして意識しておくことが重要だという点を押さえておいてください。
Recovery / Backupに必要なツール
Recoveryに必要なツールや管理機能自体が利用できなければ、Backupデータが存在していても、実際の復旧作業を進められない場合があります。
Backup / Recoveryに必要なツールそのものも、Backup Infrastructureの一部として考える必要があります。具体的にどのようなツール構成が必要かは、システムによって異なるため、この章では個別の製品構成までは扱いません。
基盤的なサービスへの依存
Backupの管理そのものが、identityや認証といった基盤的なサービスの可用性に依存している場合もあります。Recovery planningを考えるときには、こうした基盤的なサービスの可用性や信頼性も考慮する必要があります。ただし、identityや認証だけがこうした基盤的な依存の唯一の例というわけではありません。
この章で確認する代表的な要素
ここまでの内容を、簡単な表として整理します。
| 要素 | 何を支えるか | 共通の弱点を持った場合の問題 | 確認すべきこと |
|---|---|---|---|
| Backup管理用の認証情報 | Backupの操作・設定変更 | 本番環境の侵害がBackup管理権限にも及ぶ | 通常の管理用認証情報と分離されているか |
| 保護を無効化できる権限 | 追加保護・認可分離の実効性 | 保護対象の管理者が保護自体を解除できてしまう | その権限を誰が持っているか |
| 暗号鍵の管理権限 | データを実際に使える状態にすること | 鍵管理権限が本番と共有され、鍵ごと危険にさらされる | 鍵を管理・変更できる権限は分かれているか |
| ログ・監査証跡 | 状態・操作の事後確認 | 必要な記録を後から確認できなくなる可能性がある | ログもBackup Infrastructureの一部として意識されているか |
| Recovery / Backupツール | 実際の復旧作業の実行 | ツールが使えなければ復旧作業が進められない | 必要なツール自体の可用性が考慮されているか |
この表は、この章で確認する代表的な観点の整理であり、業界標準として定められた必須項目一覧ではありません。実際にどの要素がどこまで重要になるかは、システムの構成によって異なります。
9.6 Backup Infrastructure全体を守るという考え方
ここまで見てきた、認証情報、管理権限、鍵、ログ、ツールは、いずれもBackupデータそのものとは別の要素です。しかし、これらのいずれかが本番環境と同じ弱点を共有していれば、Backupコピー自体がどれだけ適切に保護されていても、実際のRecoveryは守られていない場合があります。
Backupを無効化しようとする攻撃を考えるときも、この考え方は重要です。Backup自体を狙う攻撃者は、コピーそのものだけでなく、それを管理する権限や基盤も標的にし得ます。
また、通常の認証情報や管理ツールが利用できなくなる可能性も考えると、平時からBackup Infrastructure自体を保護しておく必要があります。通常の管理経路が使えなくなった場合にどう対応するかという点については、後の章で改めて扱います。
9.7 まとめ
この章では、Backup Infrastructure自身を保護対象として見る考え方を整理しました。
重要なのは、次の点です。
- Backupコピー自体が保護されていても、それだけではRecoveryが守られているとは限らない。
- Backupを管理するための認証情報は、通常の本番環境・ネットワーク管理用の認証情報とは分離すべきである。
- 認可分離の仕組みがあっても、保護対象の管理者自身がその仕組みを無効化できる権限を持っていれば、保護効果は限定的になり得る。
- データが残っていても、復号に必要な鍵を管理・変更できる権限が守られていなければ、同じ構造の弱点になり得る。
- ログや監査証跡、Recovery/Backupに必要なツールも、Backup Infrastructureの一部として保護対象になり得る。
次の章では、Ransomwareや内部関係者による脅威など、Backup Infrastructureを直接標的とする攻撃について、より詳しく見ていきます。
Chapter 9を読み終えた時点で考えてみてください
自分が担当しているシステムについて、次の質問に答えられるでしょうか。
- Backupコピーが無事でも、それだけではRecoveryが守られていると言えないのはなぜでしょうか。
- Backup管理用の認証情報を、通常の管理用認証情報と分ける理由を説明できますか。
- 保護を無効化できる権限を誰が持つか確認する必要があるのはなぜでしょうか。
- Backupデータが残っていても、鍵の管理が問題になる理由を説明できますか。
- ログやRecovery用ツールも保護対象になり得るのはなぜでしょうか。
すべて答えられなくても問題ありません。
むしろ、答えに詰まった点があれば、それがこの章で確認しておくべきポイントです。