はじめに
本シリーズでは、AWS Well-Architected Framework（WAF）のベストプラクティスに沿ってランサムウェア対策を整理し、AWSネイティブで実現できる範囲と、Rubrikによってどのように強化を加えられるかを解説していきます。全5回を予定しており、構成は以下のとおりです。
第1回：バックアップの隔離（本稿）
第2回：クリーンなリカバリポイントの特定
第3回：クリーン環境へのリカバリ実装
第4回：運用効率化
第5回：AIエージェントが引き起こす脅威への備え
攻撃者は、環境への侵入に成功すると、多くのケースでバックアップデータの破壊を試みることが分かっています。データを人質に取る攻撃において、復旧の命綱であるバックアップを消去・暗号化することは、いわば彼らのセオリーです。このような攻撃に備えるためには、大きく2つのポイントが重要になります。
1つ目は「いかにバックアップデータを死守するか」
——どれだけ権限を奪われても、物理的に削除も改ざんもできない状態を維持することです。
2つ目は「いかに早く攻撃に気づき復旧するか」
——万が一侵入を許しても、どのデータが安全で、どの時点から復旧可能なのかを瞬時に特定し、早期に事業を復旧させる能力です。
第1回の本稿では、この1つ目のポイント、「攻撃者や内部の特権ユーザーが、バックアップそのものを破壊・改ざんできないようにする仕組み」を扱います。
WAFのベストプラクティス：REL09-BP02「バックアップの保護と暗号化」
バックアップの保護について、WAFの信頼性の柱（Reliability）の中で以下のベストプラクティスを定めています。
「認証と承認を使用して、バックアップへのアクセスを制御し、検出します。暗号化によりバックアップのデータ保全性が損なわれることを防止、検出します。
セキュリティコントロールを実装して、バックアップデータへの不正アクセスを防止します。バックアップを暗号化して、データの機密性と整合性を保護します。」
— REL09-BP02 Secure and encrypt backups
WAFのサイバーレジリエンス対策としては、以下の4点が明記されています。
対策 | 内容 |
イミュータブル化 | AWS Backup Vault LockまたはS3 Object Lockで、保持期間中の削除・改ざんを防止 |
論理的な隔離 | AWS Backup 論理エアギャップボールト（LAGボールト）で、本番環境とバックアップ環境を論理的に分離 |
バックアップの完全性検証 | AWS Backup Restore Testingで、定期的に復元可能性を検証 |
マルチパーティ承認 | AWS Backup Multi-party Approvalで、重要な復旧操作に複数承認者の許可を要求 |
また、アンチパターンとして次の点が挙げられています（一部抜粋）。
● 削除や改ざんから保護するためのイミュータビリティを実装していない。
● 本稼働システムとバックアップシステムに同じセキュリティドメインを使用する。
本稿ではこの2点「イミュータブル化」と「論理的な隔離」を掘り下げます。
AWSでの実装ポイント
S3 Object Lock / Immutable Storage を設定しても残るリスクを排除する
Amazon S3のObject Lockは、指定した保持期間中はオブジェクトの削除・上書きを禁止する強力な機能です。Compliance Modeであれば、ルートユーザであっても削除することはできません。
しかし、ここには見落とされがちな残存リスクがあります。「オブジェクトが消せないこと」と「オブジェクトの中身が読めること」は別問題だという点です。
S3でSSE-KMS（カスタマー管理キー、CMK）を使って暗号化している場合、Object Lockが有効でも、その暗号化キーが削除・無効化されてしまうと、データは復号不可能になります。KMSキーの削除には7〜30日の待機期間（デフォルト30日）が設けられていますが、これは「猶予期間があるから安全」なのではなく、「その気になれば管理者権限で復号不可能な状態を作れてしまう」というリスクであるとも言えます。同様に、暗号化設定が変更されてしまった場合、それ以降の新規バックアップが危険にさらされます。
つまりObject Lockは「消せない」を実現しますが、「安全に読める状態を維持する」ためには、暗号化キーの管理を考慮した設計を行う必要があります。具体的な例として、お客様自身で次のような運用を組み込む必要があります。
対策 | 内容 |
権限制限 | kms:ScheduleKeyDeletion / kms:DisableKey を通常ロールから除外し、MFA必須の専用管理者ロールのみに限定する |
SCP設定 | アカウント全体でキー削除を原則禁止し、例外は変更管理プロセスに組み込む |
削除監視 | CloudTrail + EventBridgeでScheduleKeyDeletionを検知し、即時アラートを発報する |
待機期間活用 | 最短7日（デフォルト30日）の待機期間内にCancelKeyDeletionで取り消せる体制を整備する |
設定変更制限 | s3:PutEncryptionConfigurationをIAMで制限し、暗号化設定の変更を防ぐ |
これらはいずれも「正しく設計・運用されていれば」機能する対策です。裏を返せば、鍵管理と監視の設計・運用そのものが組織の管理責任として残り続けるということでもあります。
AWS Backupの活用と、論理エアギャップボールトの適用範囲を認識する
AWS Backupは複数のAWSサービスを横断的に管理できる統合バックアップサービスで、上記のリスクに対応するため、AWS Backup 論理エアギャップボールト（LAGボールト）が提供されています。LAGボールトはAWSのサービス所有アカウントにバックアップデータを格納し、本番アカウントの管理者権限が侵害されても到達できない構造を実現します。
ただし、LAGボールトには現時点で未対応のサービスがあることを認識しておく必要があります。執筆時点（2026年8月）では、RDSとFSx for NetApp ONTAPが未対応となっています。
また、保護リソースごとにAWS Backupの利用に必要な料金体系が異なるため、コスト最適化の観点でも比較検討が必要となります。
Rubrikによる強化
設定不要のデフォルトイミュータブル
Rubrikのバックアップ基盤は、S3 Object LockやVault Lockのように「有効化を選択する」設定ではなく、アーキテクチャそのものが追記専用（WORM）のため、設定ミスによってイミュータブル性が損なわれる余地がありません。「有効にし忘れる」「誤って設定を緩める」といった人為的リスクが構造的に排除されています。
RCVによる論理エアギャップ
Rubrik Cloud Vault（RCV）は、Rubrikが管理する専用アカウント上で稼働する論理エアギャップストレージです。暗号鍵はRubrik管理アカウント側にあり、お客様側には削除・変更の操作権限そのものが存在しません。これは前述したS3 Object Lockの残存リスクを、運用でカバーするのではなく構造的に消し去るアプローチになります。
前述の通り、お客様自身の管理でも強固なイミュータブル構成を実現することは可能ですが、その場合の責任はお客様側で担う必要があり、管理工数と組織リスクが残り続けます。RCVは、その責任をRubrikが構造的に引き受けることで、お客様側の運用負荷とリスクを取り除きます。
図1：Rubrik Cloud Vaultによるアカウント分離構成イメージ
RDS等、LAGボールト未対応領域への適用
AWS Backup LAGボールトは現時点でRDSやFSx for NetApp ONTAPに未対応ですが、Rubrikではこれらを含む幅広いリソースに対して、RCV による論理エアギャップ領域への格納を適用できます。
※執筆時点でRDS for Oracleは、RCVへの格納適用対象外となっております
まとめ
バックアップの隔離を考えるうえで重要なのは、「削除されないこと」の設定だけでなく、関連するリスクにも目を向けることです。とりわけ、お客様の管理者権限そのものが奪われてしまった場合にも被害を最小化できるよう、設計・運用の段階でリスクを織り込んでおく必要があります。
AWSの強固な仕組みを組み合わせることでもリスクを最小化することは可能ですが、管理の主体をRubrikに委譲することで、このリスクを構造的に解消できます。
また、AWS Backupそのものの利用コストや、鍵管理・監視体制の設計・運用にかかるコストまで考慮すると、Rubrikの採用によってTCO削減につながるケースもあります。
次回は、バックアップの隔離によって守られたあと、実際にどの時点のバックアップなら安全に戻れるかを見極める、クリーンなリカバリポイントの特定を扱います。この見極めにかかる時間は、そのままRTO（目標復旧時間）の長さに直結します。