![【セッションレポート】 ランサムウェアに対して最優先で取るべき AWS の復旧対策－ [STG205]](https://images.ctfassets.net/ct0aopd36mqt/2sMbSSrXeIu2nkTZlaLSue/2120d94341b741bb1319162f3a6738f5/aws-summit-japan2026.png?w=3840&fm=webp)
【セッションレポート】 ランサムウェアに対して最優先で取るべき AWS の復旧対策－ [STG205]
こんにちは！クラウド事業本部のおつまみです。
AWS Summit Japan 2026に参加してきました！
本記事では、聴講したセッション「ランサムウェアに対して最優先で取るべき AWS の復旧対策」のレポートをお届けします。
セッションの概要
| 項目 | 内容 |
|---|---|
| タイトル | ランサムウェアに対して最優先で取るべき AWS の復旧対策 |
| 対象者 | AWSを利用する組織の管理者・担当者、クラウドアーキテクト、インフラエンジニア。ランサムウェア復旧に関心のある方 |
| ゴール | すぐに始められる効果的な復旧対策と、そのネクストステップとなる包括的な復旧対策を理解すること |
セッションは、ランサムウェアの脅威の整理から始まり、「すぐに始められる対策」「包括的な対策」「オンプレミス環境向けの対策」という3つのシチュエーションに沿って、AWSのストレージサービスを軸にした復旧戦略を解説していく構成でした。
なぜ「復旧」に焦点を当てるのか
ランサムウェアは、攻撃者がデータを暗号化したり盗み出したりして、金銭を要求する攻撃手法です。
セッション冒頭で印象的だったのは、IPAの「情報セキュリティ10大脅威 2026」でランサムウェア攻撃が11年連続で選出、ここ数年は毎年1位という話でした。もはや「いつか来るかも」ではなく「対策していて当然」というフェーズに入っていることを改めて突きつけられます。
セキュリティ対策は一般的に「防御・検知・対応・復旧」のフェーズに分けられますが、登壇者はこのうち復旧にフォーカスしていました。
「防御・検知・対応は基本的にランサムウェア固有ではなく一般的なセキュリティ対策と共通だが、データを暗号化してくるという特徴を踏まえると、暗号化・削除されたデータをどう復元し業務を再開するかという『復旧』こそがランサムウェア固有の論点になる」という整理でした。
ここは私も強く共感したポイントです。
防御・検知に予算を寄せがちですが、「破られた前提」で復旧できる状態を作っておかないと、いざという時に事業が止まります。
シチュエーション1：すぐに始められる効果的な対策
最初のシチュエーションは「AWSへ移行後、すぐに始められる効果的な対策を行いたい」というもの。
ここで軸になるのが、データ保護の3つの手法の比較でした。
- ローカルへのバックアップとリカバリ：比較的小規模な障害からの復旧を想定。普段取得している一般的なバックアップ
- ディザスタリカバリ（DR）：大規模災害からの復旧を想定。東京リージョンから大阪リージョンなど別リージョンへコピー
- サイバー脅威からのリカバリ：ランサムウェアなどに備え、専用に隔離された・イミュータブルなデータのコピーを持つ（サイバーボールトの考え方）
登壇者が繰り返し強調していたのが、「専用に隔離」と「イミュータブル」の2点です。この2語がセッション全体を貫くキーワードでした。
イミュータブルを支える「WORM」
イミュータブル（変更不可能・不変）を実現する技術仕様が WORM（Write Once Read Many） です。
書き込みは一度だけ、読み取りは何度でも可能という記録方式で、テープメディアの時代から存在する枯れた技術だという説明がありました。「最新の脅威に、古くからある技術で立ち向かう」というのが個人的には面白い点で、奇をてらわず堅実な発想だと感じます。
このWORMを、AWSの各ストレージサービスでどう実現するかが具体的に紹介されました。
- Amazon S3：オブジェクトロック（バケット単位で適用。既存オブジェクトはS3バッチオペレーションズで適用）
- Amazon EBS：EBSスナップショットロック（既存スナップショットへ都度APIでロック適用）
- Amazon FSx for NetApp ONTAP：SnapLock（ファイル単位でロックの有無や保持期限を指定可能）
- AWS Backup：Vault Lock（複数サービスのバックアップを一元管理する格納庫=Vaultをまとめて保護）
ここで登壇者が「EBSスナップショットロックは EventBridge や Lambda を組み合わせれば定期的・自動的にロックできるが、そもそも AWS Backup の Vault Lock を使うほうが簡単」と言い切っていたのが実務的でした。個別サービスのロックを自前で運用するより、AWS Backup に寄せて一元管理するほうが運用負荷が低い、というのは同じ考えです。
ロックモードの違いは要注意
比較表で特に注目してほしいと案内されていたのがロックモードの違いです。
- ガバナンスモード / エンタープライズモード：一般ユーザーは削除・上書き不可。ただし管理者は例外的に特権削除が可能
- コンプライアンスモード：指定した保持期間中は管理者を含め誰も削除できない
コンプライアンスモードは後からやり直しが効かないため、登壇者は「まずはガバナンス／エンタープライズモードで運用し、慣れたらコンプライアンスモードへ移行」を勧めていました。
いきなりコンプライアンスモードにして設定をミスると、不要なバックアップを保持期間中ずっと消せず、ストレージコストが膨らみ続けるという事故になりかねません。
シチュエーション2：包括的な対策
2つ目は、すぐに始められる対策のネクストステップとなる包括的な対策です。
指針として紹介されたのが 3-2-1-1-0 ルールでした。
- 3：元データに加えて3つのコピーを持つ
- 2：そのうち2つは異なるAWSアカウントや異なるリージョンに持つ
- 1：そのうち1つはイミュータブルに保護する
- 1：そのうち1つは障害時にすぐ戻せるようローカルに持つ（一般的なバックアップ）
- 0：復旧テストを行い、問題がゼロであること
登壇者は「イミュータブルは前半で説明したので一旦置いておき、今回特に押さえてほしいのは別アカウントへの分離と復旧テスト（0）の2点」と整理していました。この絞り込み方が分かりやすかったです。
バックアップを別アカウントへ「分離」する
業務システムが稼働するAWSアカウントは、開発・情シス・ユーザー部門・運用保守などアクセスし得る関係者が多い。同じアカウント内のバックアップも同様で、権限漏洩によってバックアップごと削除されるリスクが高い、という指摘はまさにその通りです。
解決策が、AWS Backup による別アカウントへのコピー。バックアップ専用アカウントを作り、アクセスできるのはデータ保護管理者など一部の限られた社員のみにする。さらにクロスリージョンコピーと組み合わせれば、別アカウント かつ 大阪リージョンへコピーしてDR対策も兼ねられます。
そして「万が一データ保護管理者の権限まで漏洩したら？」への備えとして、コピー先（できればコピー元とコピー先の両方）で Vault Lock を有効化してWORM保護する、という多層防御の組み立てでした。
より隔離したいなら「論理エアギャップボールト」
さらにアドバンストな対策として紹介されたのが AWS Backup 論理エアギャップボールト（Logically Air-Gapped Vault） です。
ポイントは、バックアップをユーザーではなくAWSが管理する専用アカウントへ取得して隔離すること。デフォルトでVault Lockが有効化されているためWORM保護が徹底されます。
リストアが必要になったら、AWS RAM（Resource Access Manager）でバックアップをコピーではなく共有し、そこからリストアすることで復旧時間を短縮できる、という仕組みも秀逸でした。
ただし、登壇者は質疑でよく聞かれる点として「論理エアギャップボールトは現時点でRDSには対応していない」と明言していました。ここは設計時の制約として要注意です。対応リソースは事前に必ず確認しましょう。
マルウェアスキャンと監査
包括的な対策では、さらに2つの機能が紹介されました。
- AWS Backup Audit Manager：各リソースが論理エアギャップボールトで保護されているか、バックアップが取得されているか、WORM保護されているか、別アカウントへコピーされているか、といった観点で定期的に監査レポートを作成
- GuardDuty Malware Protection との連携：取得したバックアップに対し、バックアップの都度またはオンデマンドでマルウェアスキャン（現在 EC2 / EBS / S3 のバックアップに対応）
マルウェアスキャンについては「定期的にスキャンしつつ、いざリストア時には最新のシグネチャで改めてフルスキャンする」という運用の勘どころが共有されました。
バックアップ取得時点では検知できなかった潜伏型マルウェアが、後日の定義更新で検知できることもあるため、この二段構えは理にかなっています。
「0」＝復旧テストを忘れない
個人的に一番刺さったのがここでした。
サイバー攻撃のレポートでは、バックアップを取得していたのに復旧できなかった2大要因として、
- 取得したバックアップ自体が削除・暗号化されていた
- 復旧準備に不備があった
が挙げられるそうです。1つ目はWORMと分離で対処できますが、2つ目はテストでしか潰せません。
そこで紹介されたのが AWS Backup の自動復元テスト。復元テストプランに沿って各リソースの復元を自動実行し、さらに復元後のリソースを時間指定で自動削除するところまでできます。EventBridge と組み合わせて独自テストを差し込むことも可能とのこと。
「テストはやったほうがいい」とは誰もが分かっていても続かないものなので、自動化で仕組みに落とし込めるのは大きな価値だと感じました。
シチュエーション3：オンプレミス環境向けの対策
3つ目は、オンプレミス環境ですぐに対策したい方向け。
方法はシンプルで、既存のバックアップソフトウェアから Amazon S3 へバックアップするというもの。
主要なバックアップソフトの多くはS3バックアップに対応しており、製品によってはS3オブジェクトロックと連携してWORM保護まで可能。さらに大阪・海外リージョンのS3に取得すればDRも兼ねられます。
災害時に使えるデータセンターがなくても、対応ソフトであればS3のバックアップからAWSの仮想サーバーへ直接リストアできる、という退避経路も紹介されました。
クラウド移行が済んでいなくても、まず「バックアップだけはクラウドへ分離する」という第一歩を踏み出せるのは現実的で良い提案だと思います。
全部やらなくていい、という大事なメッセージ
セッション終盤、登壇者が「自社の全てのシステムに画一的な対策が必要かというと、答えはノー」と明言したのが印象的でした。
守りたいデータを特定し、その重要度に応じてコストや要件のトレードオフを考えながら、例えば3段階くらいにレベル分けして「どこまで対策するか」を決める。
セキュリティ系セッションは「あれもこれも必要」と煽りがちな中で、現実的なレベル分けを促す姿勢は誠実で、お客様にもそのまま伝えたい考え方だと感じました。
さいごに
本記事では、AWS Summit Japan 2026のセッション「ランサムウェアに対して最優先で取るべき AWS の復旧対策」を紹介しました。
要点をまとめると以下のとおりです。
- すぐに始められる対策：WORMでデータをイミュータブルに保護する（S3 Object Lock / EBS Snapshot Lock / FSx ONTAP SnapLock / AWS Backup Vault Lock）。モードの違いに注意し、まずはガバナンス/エンタープライズから
- 包括的な対策：3-2-1-1-0ルールに沿って、別アカウント分離・論理エアギャップボールト・マルウェアスキャン・自動復元テストを組み合わせる
- 全部やる必要はない：データの重要度に応じてレベル分けし、トレードオフを考えて対策範囲を決める
「破られた前提で、いかに早く・確実に復旧できる状態を作っておくか」。ランサムウェア対策の本質を、AWSのサービスに落とし込んで具体的に学べる良いセッションでした。
弊社ではランサムウェア対策をはじめ、AWSの復旧・セキュリティ設計のご支援を行っています。
自社の状況に合わせて相談したい方は、ぜひお気軽にお問い合わせください。
最後までお読みいただきありがとうございました！
どなたかのお役に立てれば幸いです。
以上、おつまみ（@AWS11077）でした！
