ある組織は、複数のBackupコピーを、複数の場所に保存していました。
一つのデータセンターだけでなく、別のデータセンターにも、さらにクラウド上にも、それぞれコピーを持っていました。
見た目には、十分に分散されているように見えました。
しかし、これらのコピーは、すべて同じ管理者アカウント、同じ管理権限から操作できる状態になっていました。
ある日、担当者はふと考えました。もし、この管理者アカウントそのものが侵害されたらどうなるだろうか、と。
地理的に離れた複数のコピーであっても、それを操作できる権限が一つに集中していれば、その権限が危険にさらされたとき、複数のコピーが同時に危険にさらされ得ることに気づいたのです。
「コピーが複数の場所にあること」と、「それらが同じ原因で同時に失われないこと」は、必ずしも同じではありません。
この章では、この違いについて整理していきます。
7.1 コピー数と場所の多様化だけでは足りない
これまでの章では、Backupの取得方式（Chapter 3）や、業務上の優先度と技術的な復旧順序の違い（Chapter 6）について見てきました。
この章では、Backupの「配置」について考えます。
複数のコピーを、複数の場所に持つことは、単一のコピーや単一の場所に依存するリスクを減らすうえで役立ちます。これは広く知られている、有用な考え方です。
しかし、コピーの数を増やしたり、場所を分散させたりするだけでは、十分ではない場合があります。冒頭のシナリオのように、コピーが物理的・地理的に離れていても、それらを操作できる権限が一つに集中していれば、その権限が侵害されたときに、複数のコピーが同時に危険にさらされ得るからです。
この章では、こうした「見えにくい共通の弱点」について整理していきます。
7.2 3-2-1という考え方
3-2-1は、Backupの配置を考える際に広く知られている考え方の一つです。
一般には、3つのコピー、2種類の異なる媒体、1つのoff-siteコピー、という形で説明されます。
この考え方の根底にあるのは、単一のコピーや単一の保存方式、単一の場所だけに頼らないという発想です。コピーの数を増やし、保存する媒体や方式を分散させ、少なくとも一つは離れた場所に置くことで、一つの原因ですべてのコピーが同時に失われる可能性を減らそうとする考え方です。
ここで注意しておきたいことがあります。3-2-1は、広く知られている目安ではありますが、この本の中で確認できた根拠の範囲では、「3」「2」「1」という数字そのものが、すべての状況に当てはまる唯一の正解として公式に定められているわけではありません。
したがって、この本では、3-2-1を「絶対に守るべき公式ルール」としてではなく、「コピーと保存方法を分散させるという考え方の、分かりやすい目安の一つ」として扱います。
7.3 Off-site / Offline / Isolated / Immutable — 似ているようで違う性質
3-2-1のような考え方を実践しようとすると、次のような言葉に出会います。
- Off-site（オフサイト）
- Offline（オフライン）
- Isolated（隔離された）
- Immutable（不変・変更不可）
これらは、いずれもBackupの安全性に関係する言葉ですが、同じ意味ではありません。 一つを満たしているからといって、他も満たしているとは限りません。
大まかに、それぞれ次のような性質を指します。
- Off-site: コピーが、本番のシステムとは異なる場所に置かれていること。
- Offline: コピーや仕組みが、通常時にネットワーク経由で到達できない状態になっていること。
- Isolated: コピーや仕組みが、本番環境や通常の管理経路から分離されていること。
- Immutable: 一定の条件のもとで、変更や削除が制限される性質を持つこと。
例えば、あるコピーが別の建物（Off-site）に置かれていても、それが常時ネットワークに接続されていて、通常の管理者アカウントからいつでも変更・削除できる状態であれば、OfflineでもIsolatedでもありません。
それぞれの性質の詳しい技術的な意味や、実際にどう確認すればよいかについては、次の章で改めて扱います。この章では、まず「これらは別々の性質である」ということを押さえておいてください。
4つの性質の整理
ここまでの内容を、簡単な表として整理します。
| 性質 | 主に何が変わるか | 何を分離するのに役立つか | それだけでは証明できないこと |
|---|---|---|---|
| Off-site | コピーの物理的な場所 | 同一拠点の災害・障害からの分離 | 管理権限やネットワーク経路が分かれていること |
| Offline | 通常時の接続状態 | 常時接続を悪用した攻撃からの分離 | コピーが最新か、検証済みか、管理上保護されているか |
| Isolated | 本番環境との経路・権限の分離 | どの領域が分離されているかは要確認 | ネットワーク・identity・管理・鍵・ストレージ・場所のうち、具体的にどれが分離されているか |
| Immutable | 変更・削除に対する制限 | 一定条件下での改ざん・削除からの保護 | 絶対的な安全性、あらゆる管理権限からの保護 |
この表もあくまで整理のための目安であり、安全性を数値化したスコアや、格付けを示すものではありません。それぞれの性質の詳しい確認方法は、次の章で扱います。
7.4 場所の分離と管理上の分離は別問題
ここが、この章でもっとも重要な点です。
物理的・地理的にコピーが離れていても、それらを同じ管理者アカウントや同じ管理権限から操作できるのであれば、管理上のFailure Domainが分離されているとは限りません。
冒頭のシナリオがまさにこの例です。コピーは複数の場所にありましたが、それらを操作できる権限は一つに集中していました。この場合、その権限が侵害されると、地理的に離れた複数のコピーが同時に危険にさらされ得ます。
この問題に対して、追加の承認や、別の管理境界を設けることで、重要な操作を保護する実装例もあります。例えば、Microsoft Azure BackupのResource Guardや、AWS Backupのmulti-party approvalといった仕組みは、破壊的な操作に対して、通常の管理者権限とは別の承認を必要とするよう構成できる、製品固有の実装例です。
こうした仕組みは一つの選択肢であり、唯一の解決策というわけではありません。また、具体的な設定方法はこの章では扱いません。重要なのは、場所の分離だけでは、管理上の分離まで自動的に得られるとは限らない、という考え方そのものです。
7.5 Failure Domainという考え方
この本では、同じ原因で一緒に失敗したり、同時に侵害されたりする可能性がある範囲を考えるために、Failure Domain（障害領域）という言葉を使います。
Backupやリカバリの仕組みそのものも、それぞれ固有のFailure Domainを持ち得ます。例えば、次のような要素が、本番システムと共通のFailure Domainになり得ることがあります。
- コピーが置かれている場所
- 依存しているストレージやネットワーク
- 認証情報やidentity
- 管理権限
- 暗号化に使われる鍵
- 復旧に使うツールそのもの
これらは、この本での整理のための例であり、すべての状況を網羅した公式な一覧というわけではありません。実際にどのような要素が共通のFailure Domainになり得るかは、システムの構成によって異なります。
7.6 隔離性を複数の観点から考える
ここまで見てきたように、「隔離されている」という言葉は、一つの側面だけでは語れません。
この本では、隔離性を考えるための整理の一例として、いくつかの観点に分けて見てみます。
- 地理的な観点（Geographic）: 物理的な場所が離れているか
- ネットワークの観点（Network）: 通常のネットワーク経路から切り離されているか
- ストレージの観点（Storage）: 保存基盤そのものが本番と共有されていないか
- Identityの観点: 認証主体や認証情報の管理が、本番環境と分かれているか
- 管理権限の観点（Administrative）: 管理操作を行える主体や権限が、本番環境の管理者と分かれているか
- 認可の観点（Authorization）: 重要な操作に対する許可の仕組みや認可経路が、通常の操作権限だけに依存していないか
- 暗号鍵の観点（Cryptographic）: 暗号化に使う鍵の管理が分かれているか
繰り返しになりますが、これはあくまでこの本での整理の一例であり、業界標準として定められた分類ではありません。また、これですべての観点を網羅しているとも限りません。
大切なのは、「隔離されている」かどうかを、一つの側面だけで判断せず、複数の観点から確認する必要がある、という考え方です。
7.7 まとめ
この章では、Backupの配置と隔離性について整理しました。
重要なのは、次の点です。
- 複数のコピーを複数の場所に持つことは有用だが、それだけでは十分でない場合がある。
- 3-2-1は広く知られている目安だが、この本ではすべての状況に当てはまる公式ルールとしては扱わない。
- Off-site、Offline、Isolated、Immutableは、それぞれ異なる性質であり、同じ意味ではない。
- 物理的・地理的な分離だけでは、管理上の分離まで自動的に得られるとは限らない。
- Backupやリカバリの仕組みも、本番システムと共通のFailure Domainを持ち得る。
- 隔離性は、地理・ネットワーク・ストレージ・Identity・管理権限・認可・暗号鍵など、複数の観点から考える必要がある。
Recovery copyの安全性は、コピー数や場所だけでなく、こうした複数の性質を組み合わせて考える必要があります。
次の章では、Off-site、Offline、Isolated、Immutableという性質について、それぞれをどのように確認すればよいかを、より詳しく見ていきます。
Chapter 7を読み終えた時点で考えてみてください
自分が担当しているシステムについて、次の質問に答えられるでしょうか。
- 3-2-1は何を目的とした考え方でしょうか。
- Off-siteとOfflineは同じ意味でしょうか。
- 複数の場所にBackupを置くだけでは、なぜ管理上の分離を保証できないのでしょうか。
- Failure Domainとは、この章ではどのような考え方でしょうか。
- 同じ管理者アカウントですべてのBackupコピーを操作できる構成には、どのような弱点がありますか。
すべて答えられなくても問題ありません。
むしろ、答えに詰まった点があれば、それがこの章で確認しておくべきポイントです。