この記事はJapan AWS Top Engineers Advent Calendar 2025のDay9 の記事です。
対象読者
-
Amazon Web Services（AWS）でバックアップ戦略を検討している方
-
ランサムウェア対策としてのバックアップ設計を検討している方
-
AWS Backupの論理的エアギャップボールト（Logically Air-Gapped Vault）に興味がある方
-
マルチアカウント構成でのバックアップ管理を検討している方
はじめに
本記事ではランサムウェア対策としてのバックアップ戦略をご紹介します。
「バックアップを取っていれば安心」という時代は終わりました。現代のランサムウェア攻撃は、バックアップデータそのものを標的にします。本記事では、Veeamが提唱する「3-2-1-1-0ルール」をベースに、AWSでどのようにバックアップを保護するかを、2025年にリリースされた最新機能も交えて解説します。
ランサムウェア攻撃の脅威
増加する標的型ランサムウェア攻撃
ランサムウェアとは、「Ransom（身代金）」と「Software（ソフトウェア）」を組み合わせた造語です。感染したシステム上のデータを暗号化し、復号と引き換えに身代金を要求するマルウェアの一種です。
近年、「人手によるランサムウェア攻撃（human-operated ransomware attacks）」と呼ばれる標的型の攻撃が増加しています。
この攻撃の特徴は、自動化されたマルウェアとは異なり、攻撃者が手動でネットワークに侵入し、権限を昇格させた上で、最も効果的なタイミングでランサムウェアを展開する点にあります。
IPAによる脅威評価
IPAの「情報セキュリティ10大脅威2025」では、ランサム攻撃による被害が組織向け脅威の第1位に位置づけられています。これは10年連続10回目の選出であり、継続的かつ深刻な脅威であることを示しています。
バックアップがあれば大丈夫？
「データを暗号化されてもバックアップから戻せばいいじゃん」
そう思っていた時期が私にもありました…確かにバックアップは最後の砦です。
しかし、攻撃者もそれを理解しています。
バックアップを狙う攻撃の実態
攻撃者はバックアップも狙ってきます。公的機関からも以下のような警告が出されています。
| 機関 | 内容 |
|---|---|
| IPA（情報処理推進機構） | ネットワークにバックアップサーバが接続されていると、バックアップサーバも被害に遭う可能性がある |
| 警察庁 | ランサムウェアにより、バックアップデータやログも暗号化されてしまう事例が確認されている |
参考資料:
バックアップ保護の必要性
バックアップを取得しているだけでは不十分です。バックアップデータそのものを攻撃から保護する戦略が必要です。
復旧できて初めてバックアップはバックアップたりえます。（新卒の時先輩社員に教えてもらいました）
バックアップの保護戦略
では、バックアップデータをどのように保護すればいいのでしょうか。
本記事では保護戦略としてVeeamが提唱する「3-2-1-1-0ルール」を紹介します。これは従来の「3-2-1ルール」をランサムウェア時代向けに拡張したものです。
3-2-1-1-0ルールとは
| 意味 | |
|---|---|
| 3 | データは少なくとも3つのコピーを保持する（本番データ＋2つのバックアップ） |
| 2 | 2種類以上の異なるメディア/ストレージに保存する |
| 1 | 1つはオフサイト（別拠点/別リージョン）に保管する |
| 1 | 1つはオフライン、エアギャップ、または**イミュータブル（改変不可）**な状態で保管する |
| 0 | 定期的なリカバリテストでエラー0件を確認する |
従来の3-2-1ルールとの違い
従来の3-2-1ルールでは、バックアップの「存在」を担保していましたが、ランサムウェア対策としては不十分でした。
追加された「1」と「0」が重要です。
-
イミュータブル（改変不可）なコピー：たとえ攻撃者が管理者権限を奪取しても、バックアップを削除・暗号化できない
-
定期的なリカバリテスト：いざというときに復旧できることを事前に確認
参考: Veeam: 3-2-1 Backup Rule Explained
AWS Backupで3-2-1-1-0ルールを実現する
実現アーキテクチャの概要
AWS Backupの機能を活用して、3-2-1-1-0ルールを実現するアーキテクチャを設計します。
3-2-1-1-0アーキテクチャ図
3-2-1-1-0ルールの対応表
| ルール | AWSでの実現方法 |
|---|---|
| 3コピー | 本番データ ＋ 東京リージョンVault ＋ 大阪リージョンVault |
| 2メディア | EBS/RDS（ブロックストレージ）＋ S3（オブジェクトストレージ） |
| 1オフサイト | クロスリージョンコピー（東京→大阪） |
| 1イミュータブル | 論理的エアギャップボールト（Vault Lock） |
| 0エラー | AWS Backup 復元テスト機能で定期検証 |
4つ目の1を実現するために重要なポイント
4つ目の1（1つはオフライン、エアギャップ、または**イミュータブル（改変不可）**な状態で保管する）を実現するために2つの重要なポイントがあります。それぞれのポイントの設計意図についてご説明いたします。
1. 論理的エアギャップボールト
1つ目のポイントはAWS Backupの論理的エアギャップボールト（Logically Air-Gapped Vault）の使用です。
以下の特徴の通りこのボールトを利用することで、本番ワークロードから隔離され、イミュータブルなバックアップを実現することができるため利用しています。
2025年11月に論理的エアギャップボールトを直接バックアップ先として指定可能になりましたので、こちらの機能を活用してエアギャップボールトをバックアップアカウントにバックアップします。
参考: AWS Backup now supports backing up directly to a logically air-gapped vault
論理的エアギャップボールトのメリット主な特徴：
-
自動的にVault Lockがコンプライアンスモードで設定：保持期間内はrootであっても誰もが削除不可（WORM）
-
AWS RAMによるクロスアカウント共有：別アカウントから直接リストア可能
-
バックアップはAWSサービス所有アカウントに保存：ワークロードアカウントと論理的に分離
-
マルチパーティ承認との統合：リストア時のプロセスをより厳格化することが可能 詳細は後述
参考: AWS Backup Logically Air-Gapped Vault
2. マルチアカウント構成
もう1つのポイントはマルチアカウント構成です。
本番アカウントが侵害された際、バックアップをクロスアカウントで保存することでより隔離された状態（オフライン・エアギャップに近い状態）を実現します。
単一アカウントでバックアップを保管するリスク
単一アカウントでは、攻撃者が管理者権限を奪取した場合、以下のようなアクションでバックアップを破壊され、証跡も削除される可能性がございます。。
-
IAMの変更
-
Vault Lockの解除試行
-
CloudTrailログの改ざん・削除
たとえVault Lockでバックアップを保護しても、攻撃者は復旧プロセスを妨害したり、新たなバックアップの取得を阻止したりできます。
リスク軽減策としてのアカウント分離による多層防御
AWS Well-Architected Frameworkでは、アカウントを「強固な境界」として位置づけています。
AWS では、アカウントが強固な境界となります。例えば、開発およびテストのワークロードと本番稼働ワークロードを切り離すために、アカウントレベルの分離を強くお勧めします。
― AWS Well-Architected セキュリティの柱「AWS アカウントの管理と分離」
バックアップアカウントを分離することで：
-
爆発半径（Blast Radius）の最小化：本番アカウントが侵害されても、バックアップアカウントは独立しているため、侵害を抑えられる可能性
-
認証情報の分離：適切なIAM設計を行うことで、バックアップアカウントにアクセスさせないように制御可能
-
SCPによる組織レベルの保護：Organizations経由で強制的にポリシーを適用することでIAMを超えた保護を実現
Organizationsの活用によるさらなる保護
Organizationsを活用できる方は、単なるアカウント分離だけではなく、Organizationsの機能を活用することをお勧めします。
SCPによる厳格な制御
アカウントを分けるだけでもIAMの境界線を作ることができるため有効ではありますが、さらに境界を強固なものにするためにSCPを設定します。
これによりIAMの管理者であっても禁止された操作は実行できません。SCPでバックアップの削除を禁止しておくことで、さらにバックアップの消失リスクを抑えることができます。
Organizationsの設計例
先にご紹介した3-2-1-1-0実現アーキテクチャ図 でもOrganizationsを活用しています。それぞれのアカウントの役割についてご説明します。
バックアップアカウント
バックアップを本番アカウントから分離して保管するためのアカウントです。
Security OU に厳格なSCPをかけておくことで、ボールトを安全に保管できます。
リカバリアカウント
本番アカウント侵害時に本番ワークロードを復旧させるためのアカウントです。
1度侵害されたアカウントに復旧すると再度侵害される恐れがあります。そのためクリーンなアカウントに再度IaCを流して再構築を行った後、リストアすることで安全にシステムを再開させます。
SCPによるバックアップ保護
バックアップアカウントに対して、以下のようなSCPを適用することで保護を強化します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyBackupVaultDeletion",
"Effect": "Deny",
"Action": [
"backup:DeleteBackupVault",
"backup:DeleteRecoveryPoint",
"backup:UpdateRecoveryPointLifecycle"
],
"Resource": "*",
"Condition": {
"StringNotLike": {
"aws:PrincipalArn": "arn:aws:iam::*:role/BreakGlassRole"
}
}
}
]
}
補足：
-
通常の管理者でもバックアップの削除を禁止
-
緊急時用のBreakGlassロールのみ例外（このロール自体も厳重に管理）
他にも様々なユースケースで活用できるSCPについてAWS Blogが公開されております。
Multi-Party Approval（MPA）による緊急時アクセス
BreakGlassロールは緊急時の最終手段ですが、そのロール自体が侵害された場合の備えとしてMPAという機能をご紹介いたします。
2025年6月にGAとなったMulti-Party Approval（MPA）連携機能により、アカウントが完全にアクセス不能になった場合でも、バックアップにアクセスできる仕組みが追加されました。
動作の流れ：
-
Organizations管理アカウントで承認チーム（Approval Team）を作成
-
論理的エアギャップボールトに承認チームを関連付け
-
アカウント侵害時、別アカウントからボールト共有をリクエスト
-
承認チームメンバーがApproval Portal経由で承認
-
承認完了後、リカバリアカウントからバックアップにアクセス可能
この機能のポイントは以下の通りです。
-
AWS IAM Identity Center経由の別認証パス
-
AWSアカウントの認証情報とは完全に独立
-
たとえroot権限を奪取されても、この復旧プロセスは阻止できない
参考: AWS Backup adds new Multi-party approval for logically air-gapped vaults
5つ目の0を実現するための定期的な復旧テスト
3-2-1-1-0ルールの「0」を実現するには、定期的な復旧テストを行います。
AWS Backupには復旧テスト機能が具備されているので、定期的なバックアップを行うことでリカバリエラー「0」を実現します。
論理的エアギャップボールトからの復旧テストについては以下のAWS Blogで解説されています。
まとめ
本記事では、ランサムウェア対策としてのバックアップ戦略を、AWS Backupの機能を活用して実現する方法を解説しました。
今回は手厚い保護を行いましたが、その分コストがかさみます。
どこまでコストをかけて保護するかはシステムの判断によりますが、筆者個人としては近年増加しているランサムウェアによる被害と天秤にかけるとやりすぎでもない気がします。
参考資料
AWS公式ドキュメント
アップデート情報
-
AWS Backup now supports backing up directly to a logically air-gapped vault
-
AWS Backup adds new Multi-party approval for logically air-gapped vaults
ランサムウェア対策（公的機関）
Veeam 3-2-1-1-0ルール
NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。