ある組織には、複数のRecovery copyがありました。
Copy Aは、本番とは別のサイトに置かれていました。Off-siteです。ただし、通常のネットワークから常時到達でき、本番と同じ管理経路から削除することもできる状態でした。
Copy Bは、一定期間Immutable（変更・削除を制限される状態）として保護されていました。ただし、オンライン状態で稼働しており、通常のネットワークから到達できました。
担当者は、これらのコピーを見て、当初は「これで十分に守られている」と考えていました。
しかし、あらためて考え直してみると、次のことに気づきました。
「Off-siteだから安全」「Immutableだから絶対に安全」とは、言い切れません。
Copy Aは場所こそ離れているものの、削除できる経路は本番と共有されています。Copy Bは変更・削除が制限されているとはいえ、その保護がどのような条件で、いつまで、誰に対して有効なのかを確認しなければ、本当に安全かどうかは分かりません。
この章では、Off-site、Offline、Isolated、Immutableという4つの性質について、それぞれ何を確認すべきかを整理していきます。
8.1 ラベルだけでは安全性を判断できない
Chapter 7では、複数のコピーを複数の場所に持つことは有用だが、それだけでは十分ではない場合があること、そして場所の分離と管理上の分離は別問題であることを見ました。
この章では、その考え方をさらに具体化します。
Backupやリカバリのコピーについて語るとき、次のような言葉がよく使われます。
- Off-site（オフサイト）
- Offline（オフライン）
- Isolated（隔離された）
- Immutable（不変・変更不可）
これらは、いずれも保護に関係する重要な性質です。しかし、一つのラベルが付いているからといって、他の性質まで満たしているとは限りません。 ある性質を満たしていることと、実際にどこまで安全なのかということは、別に確認する必要があります。
この章では、それぞれの性質が「何を確立するのか」「何を確立しないのか」を、一つずつ具体的に見ていきます。
8.2 Off-site — 場所の分離が守るもの、守らないもの
Off-siteとは、コピーや復旧に必要な仕組みが、本番とは異なる物理的な場所にあることを指します。
これは、本番のある場所そのものが災害や障害で失われた場合に、コピーまで同時に失われることを避けるうえで役立ちます。
しかし、Off-siteであるということは、それ以上のことを自動的には意味しません。場所が離れているからといって、次のようなことまで保証されるわけではありません。
- 管理上の権限が本番とは分かれていること
- 認証情報が本番とは分かれていること
- ネットワーク経路が本番とは分かれていること
- 暗号鍵の管理が本番とは分かれていること
冒頭のシナリオのCopy Aがまさにこの例です。場所は離れていても、削除できる経路は本番と共有されていました。
Off-siteなコピーを見たときは、次のように自問してみてください。「場所が離れていること以外に、何が分離されているだろうか？」
8.3 Offline — 到達可能性という観点
Offlineとは、コピーや仕組みが、通常時にはネットワーク経由で接続・到達できない状態にあることを指します。
常時接続されているシステムは、その接続経路を通じて攻撃や誤操作の影響を受ける可能性があります。Offlineであることは、そうした通常経路からの影響を避けるうえで役立ちます。
ここで一つ注意しておきたいことがあります。この本で確認できた根拠の範囲では、「物理的に完全に切断されている状態」と「論理的な経路だけが遮断されている状態」、あるいは「一時的にのみ切断される状態」といった細かい区分を、それぞれ厳密に定義づける記述は見当たりませんでした。したがって、この章では、Offlineを「物理的air-gap」のような特定の実装方式と同一視せず、まずは「通常時に到達できない状態」という一般的な観点として扱います。
また、Offlineであることは、次のようなことまでは証明しません。
- そのコピーが最新の状態であること
- そのコピーが検証済みであること
- そのコピーが管理上保護されていること
「普段つながっていないから安心」というだけでなく、「そのコピーは本当に使える状態なのか」も、別に確認する必要があります。
8.4 Isolated — 何が分離されているかを確認する
Isolatedとは、何らかの障害・制御ドメインが、本番から分離されていることを指します。
ここで重要なのは、「何が分離されているのか」を具体的に確認する必要がある、という点です。「隔離されている」という言葉だけでは、次のうちどれが分離されているのかが分かりません。
- ネットワーク
- Identity（認証主体や認証情報の管理）
- 管理権限
- 認可の経路
- ストレージ
- 暗号鍵
- 場所
例えば、ネットワーク経路が本番とは分かれていても、同じ管理者identityや同じ鍵管理に依存している場合があります。その場合、ネットワークの観点では分離されていても、管理権限や鍵の観点では分離されていないことになります。
この本では、こうした観点の整理として、Chapter 7で紹介した複数の観点（地理・ネットワーク・ストレージ・Identity・管理権限・認可・暗号鍵）を参考にできます。これはあくまでこの本での整理の一例であり、業界標準として定められた分類ではありません。
大切なのは、「Isolated」という言葉を見たときに、具体的にどの観点で分離されているのかを確認する習慣です。
8.5 Immutable — 「不変」の中身を確認する
ここまでの3つの性質と比べて、Immutableは特に注意が必要な性質です。
Immutableというラベルだけでは、実際にどこまで変更・削除に耐えられるかは判断できません。
「Immutable = 破壊不可能」「Immutable = 永久に保護される」「Immutable = あらゆる管理者から保護される」というのは、正しい理解ではありません。Immutableは、あくまで「一定の条件のもとで」変更・削除が制限される性質です。また、ImmutableであることはOfflineであることやIsolatedであることを意味しません。オンライン状態のまま、Immutable保護だけが設定されている場合もあります。
Immutableというラベルを見たとき、少なくとも次の6つの点を確認する必要があります。
- lock state / enforcement mode（現在の状態）: 保護は今どのような状態にあるか。その状態から保護を弱めたり解除したりできるか。
- override authority（誰が上書き・解除できるか）: 保護そのものを無効化・変更できる主体は誰か。
- irreversibility timing（いつ不可逆になるか）: 保護は設定した瞬間から不可逆なのか、それとも一定の猶予期間や状態遷移を経て不可逆になるのか。
- retention-policy authority（保持期間を誰が決めるか）: 保持期間そのものだけでなく、誰がその期間を設定・変更できるかも重要です。
- protected scope（保護される範囲）: どのデータ・どのリソースが保護対象になっているか。
- excluded backup types / resources（対象外のもの）: どのようなバックアップ種別やリソースが、保護の対象から外れているか。
Azure Backupの例
例えばAzure Backupでは、immutabilityには「有効化された状態」と「ロックされた状態」があり、それぞれ解除できるかどうかという可逆性の性質が異なります。これは、上記1番目の「現在の状態」を確認することの重要性を示す一つの実装例です。
AWS Backupの例
AWS Backup Vault Lockには、governance modeとcompliance modeという異なるモードがあり、上書き・解除できる条件がそれぞれ異なります。また、compliance modeの保護は、猶予期間（grace period）の状態に依存する場合があります。これは、上記2番目・3番目の確認項目に関わる実装例です。
これらはあくまで特定製品におけるbounded implementation exampleです。すべてのImmutable Backup製品が同じ仕組みを持つとは限りません。 Azureの用語やAWSの用語を、Immutableという性質そのものの定義であるかのように扱わないでください。
8.6 Soft Deleteだけでは十分とは限らない
Immutableと近い文脈で登場する仕組みに、Soft Delete（論理削除）があります。
Soft Deleteは、削除操作が行われても、一定期間はデータを復元できる状態にしておく仕組みです。
ただし、Soft Deleteがあるというだけでは、復旧可能性が保証されるとは限りません。
考えてみてください。削除後に一定期間復元可能であっても、その削除に誰も気づかなければ、あるいは気づいても通知が届かなければ、あるいは通知が届いても対応が期限に間に合わなければ、結局のところ復旧できなくなってしまいます。
つまり、実際の復旧につなげるには、例えば次のような一連の運用まで含めて考える必要があります。
Soft Delete
+
検知（Detection）
+
通知の到達（Alert Delivery）
+
保持期間内での対応（Response within Retention Window）この一連のつながりは、この本での教育的な整理であり、業界標準として定められた分類ではありません。しかし、「削除保護の仕組みがある」ということと、「実際に間に合って復旧できる」ということは、別の問題だという考え方は押さえておく必要があります。
8.7 データが残っていても復旧できない場合
もう一つ、見落とされがちな観点があります。
バックアップデータそのものが削除されていなくても、そのデータを復号するために必要な暗号鍵やその他の暗号材料が失われたり、変更されたり、利用できなくなったりすれば、実際にはそのデータを復旧に使えない場合があります。
これは、データそのものの保護とは別に、暗号鍵の管理も独立した復旧上の依存要素として考える必要があることを示しています。
具体的な鍵管理の仕組みや設計については、この章では扱いません。ここでは、「データが残っていること」と「そのデータを実際に使えること」は別問題であり得る、という点を押さえておいてください。
8.8 保護されていることと正しい復旧点は別問題
最後に、もう一つ重要な視点を確認します。
Chapter 1では、削除や論理破損、悪意ある変更が起きた場合、最新の状態ではなく、より古い既知の正常な状態への復旧が必要になる場合があることを見ました。
この章で見てきたOff-site、Offline、Isolated、Immutableといった性質は、いずれもコピーが「守られているかどうか」に関わるものです。しかし、コピーが十分に守られていることと、そのコピーが実際に復旧に使うべき正しい時点の状態であることは、別の問題です。
保護されたコピーであっても、それが自動的に正しい復旧点になるとは限りません。どの時点の状態を信用して復旧に使うべきかという判断については、後の章で改めて扱います。
8.9 まとめ
この章では、Off-site、Offline、Isolated、Immutableという4つの性質について整理しました。
重要なのは、次の点です。
- Off-site、Offline、Isolated、Immutableは、それぞれ異なる性質であり、一つを満たしていても他を満たしているとは限らない。
- Off-siteは場所の分離を示すが、管理権限やネットワーク、鍵の分離までは意味しない。
- Offlineは通常時の到達可能性に関する性質であり、最新性や検証済みであることまでは証明しない。
- Isolatedと言われたときは、具体的に何が分離されているのかを確認する必要がある。
- Immutableというラベルだけでは安全性は判断できず、lock state、override authority、irreversibility timing、retention-policy authority、protected scope、対象外のリソースを確認する必要がある。
- Soft Deleteは、検知・通知・保持期間内の対応と併せて考える必要がある。
- データが残っていても、暗号鍵が失われれば実際には復旧に使えない場合がある。
- 保護されていることと、正しい復旧点であることは別問題である。
次の章では、Backup Infrastructure自体、つまりBackupを支える管理権限や認証情報、鍵、ログ、ツールそのものをどう守るかについて見ていきます。
Chapter 8を読み終えた時点で考えてみてください
自分が担当しているシステムについて、次の質問に答えられるでしょうか。
- Off-siteであることは何を保証し、何を保証しないでしょうか。
- Immutableというラベルを見たとき、具体的に何を確認すべきでしょうか。
- Soft Deleteだけでは不十分な理由を説明できますか。
- データが残っていても復旧に使えない場合があるのはなぜでしょうか。
- 保護されたコピーが、自動的に正しい復旧点になるとは限らない理由を説明できますか。
すべて答えられなくても問題ありません。
むしろ、答えに詰まった点があれば、それがこの章で確認しておくべきポイントです。