【re:Invent 2025】AWS Backupを活用したマルチアカウント環境でのバックアップ&リストアのアーキテクチャについて考えてみる

こんにちは、サーバーワークスの今野です。

re:Invent 2025に現地で参加してきたAWS Backupに関するワークショップの体験を元に、マルチアカウント環境でのバックアップ&リストアのアーキテクチャについて考えたことを整理しブログにまとめました。現地でワークショップ講師の方との意見交換を踏まえた内容となっております。

参加したワークショップの概要
- そもそも、「論理エアギャップ」とは？
アーキテクチャの紹介
マルチアカウント環境でのアーキテクチャについて
おわりに
参考文献

参加したワークショップの概要

AWS Backupを活用したランサムウェア対策、特に論理的にエアギャップされたボールト（保管庫）からのデータ復旧をハンズオン形式で学ぶことを目的としたワークショップとなります。

正式名称: [STG403] Build ransomware data recovery with AWS Backup logically air-gapped vaults
目標: AWS Backupの高度な機能（論理エアギャップボールト、復元テスト、Audit Manager）を使用し、堅牢でコンプライアンスに準拠したバックアップ戦略の実装手法を習得する。
対象者: データ保護管理者、セキュリティエンジニア、コンプライアンス担当者。

そもそも、「論理エアギャップ」とは？

ここで言われる「論理エアギャップ（Logically air-gapped）」とは、いわば「クラウド内部における隔離保管室」です。物理的なエアギャップ（テープなど）との違いを含め下記が挙げられます。

物理的にオフラインにするのではなく、権限管理とネットワーク論理層で完全に分離する
管理アカウントからも直接アクセスできない強力なアクセス制御を持つ
ランサムウェアが本番環境を侵害しても、バックアップデータへの破壊活動を防ぐ「不変性（Immutability）」を持つ

docs.aws.amazon.com

アーキテクチャの紹介

今回のワークショップでは、下図のアーキテクチャの元、ハンズオンを実施しました。

このアーキテクチャの最大の特徴は、「バックアップデータの健全性を自動で検証し、結果に応じて隔離（エアギャップ）先のボールトを振り分ける」という点です。具体的な処理フローは以下の通りです。

保護対象（Crown Jewel）のバックアップ
- 重要なS3バケットやWebサーバー（EC2）を保護対象とし、まずは通常のバックアップボールト（Regular Vault）へバックアップを取得します。
AWS Backup Restore Testing による復元
- 「復元テストプラン（Restore test plan）」に基づき、定期的にバックアップデータから一時的なリソースを復元します。
脅威検知とスキャン（Elastio）
- 復元されたリソースに対し、セキュリティパートナーソリューションである Elastio がスキャンを実行し、ランサムウェアやマルウェアの痕跡がないかを確認します。
結果に基づく自動振り分け（Lambda & EventBridge）
- スキャン結果は EventBridge を介して Lambda（Restore validation Lambda）に通知され、以下の判定が行われます。
  - 汚染検知（Infected）: フォレンジック調査用ボールト（Forensics LAG Vault）へコピーし、証拠保全を行う。
  - 安全（Clean）: クリーンルーム用ボールト（Cleanroom LAG Vault）へコピーし、安全な復旧ポイントとして確保する。
結果の可視化とクリーンアップ
- スキャン結果は AWS Security Hub にも送信され、統合的なセキュリティ監視が可能になります。
- 検証に使用した一時的なリソースは、テスト終了後に自動的に削除（Clean up）されます。

このように、単にバックアップをとるだけでなく、「そのバックアップが汚染されていないか」を自動的にチェックし、安全なデータのみを論理エアギャップ環境へ隔離するという、極めて堅牢な運用フローを体験しました。

マルチアカウント環境でのアーキテクチャについて

アカウント分離（バックアップデータ）

ランサムウェアなどのサイバーセキュリティ攻撃を受けたアカウントは乗っ取られているため、そのアカウント内のバックアップからリストアを試みるのは最適ではありません。そのため、下図のようにアカウントを分離することが推奨されます。

論理的にエアギャップされたボールトを格納するアカウントを別で設けてアカウント分離する

サービスアカウントで取得したバックアップデータの中身をelastioでスキャンし、その結果、汚染されている/いないでコピー先のボールトを振り分けるようなアーキテクチャが考えられます。（EventBridge+Lambdaのような構成でバックアップコピーを自動化することが出来そうです）

※本番環境（Source Account）から、分離されたバックアップ専用アカウント（Backup Account）のボールトへデータをコピーする構成です。

リストア

重ねてですが、ランサムウェアなどのサイバーセキュリティ攻撃を受けたアカウントは乗っ取られているため、リストアするアカウントは新規で設ける形が良いでしょう。（この点はワークショップ講師の方と見解が一致してました）

下図のように、リストアする際には、論理エアギャップボールト（クリーンルーム）をリストア用のアカウントとResource Access Manager（RAM）にて共有し、復旧をすることが想定されます。

Data Bunker AccountとRecovery Accountで論理エアギャップボールトを共有

アカウント分離（暗号鍵）

ランサムウェア対策において、バックアップデータそのもの（ボールト）の保護と同じくらい重要なのが「暗号鍵（KMSキー）」の保護です。

もしアカウントが侵害された際、そのアカウント内で暗号鍵も管理していると、攻撃者に鍵を削除・無効化されてしまい、「データはあるのに復号できない（＝論理エアギャップがあっても戻せない）」という事態に陥るリスクがあります。

そのため、データと鍵の管理を明確に分離する「Key Vault Account（鍵管理専用アカウント）」という部分も考慮が必要です。

鍵管理の分離 暗号鍵（CMK）は、本番環境やバックアップアカウントとは独立した専用アカウントで作成・管理します。これにより、本番環境の管理権限が奪われても、暗号鍵自体は守られます。
クロスアカウントでの利用 Key Vault AccountにあるCMKを、バックアップ元だけでなく、復旧先（Recovery）や調査用（Forensics）のアカウントに対しても共有（KMS Share）します。これにより、「暗号化されたまま別のクリーンなアカウントへ持ち運び、そこで復号してリストアする」ことが可能になります。
MFAによる保護 キーポリシーの変更や削除といった特権操作には、IAM MFA（多要素認証）を必須とすることで、鍵自体への不正アクセスや誤削除を防止する多層防御が組めます。