AWS re:Invent 2025 にて、AWS Backup でできるランサムウェア対策というタイトルのセッションを聴講しました。
その際に「さすがに人間不信が過ぎるのでは？」と感じたスライドがありました。
管理者すら信用しない前提で設計されたバックアップ構成。
まさにゼロトラストな世界です。
本記事ではそのスライドを起点に、AWS が考えるランサムウェア時代のバックアップ設計思想について整理してみます。
1. 元ネタ
AWS re:Invent 2025 で参加した Breakout session です。
Building resilience against ransomware using AWS Backup (STG412)
セッション説明 (原文)
To counter evolving cyber threats, organizations must fortify their backup infrastructure for recovery resilience, aligned with NIST CSF 2.0. This session explores three critical pillars: immutability with isolation, integrity validation, and predictable availability. AWS Backup enables these through Vault Lock for tamper-proof backups, restore testing for integrity assurance, and integration with partner solutions for enhanced forensic analysis. Learn how to strengthen accessibility by isolating authentication boundaries to protect recovery mechanisms from compromised credentials. Discover practical strategies to align these pillars with NIST CSF 2.0, ensuring robust recovery resilience and business continuity.
セッション説明 (日本語訳)
進化するサイバー脅威に対抗するため、組織はNIST CSF 2.0に沿った復旧レジリエンスのためのバックアップ基盤を強化する必要があります。本セッションでは、3つの重要な柱を探ります：分離による不変性、完全性検証、予測可能な可用性。AWS Backupは、改ざん防止バックアップのためのVault Lock、完全性保証のための復元テスト、強化されたフォレンジック分析のためのパートナーソリューションとの統合を通じてこれらを実現します。認証境界を分離し、侵害された認証情報から復旧メカニズムを保護することで、アクセス制御を強化する方法を学びます。これらの基盤をNIST CSF 2.0に整合させる実践的な戦略を発見し、強固な復旧レジリエンスと事業継続性を確保しましょう。
2. バックアップでそこまでする？
セッションの最後の方で出てきた、サイバー攻撃に強い構成図がこちらです。
小さな四角がワークロードで、ほとんどがバックアップに関するサービスです。
「バックアップでそこまでする？」
と思ってしまいそうなスライドですが、よく見るとそこには多彩なサイバー攻撃を前提にした AWS の本気が詰まっています。
AWS がここまでバックアップを厳重に考える理由はシンプルです。
ランサムウェア攻撃者は、最後にバックアップを狙うからです。
- 管理者権限を奪う
- その権限でバックアップを消す
- 鍵を削除して復旧不能にする
このような攻撃が成立してしまうと、「バックアップは取っていたが、復旧はできない」という最悪の状態に陥ります。
つまり、バックアップは存在しているだけでは不十分で、攻撃者に消されず、確実に復旧に使える状態で残っていることが求められるのです。
Backups are only good as their recoverability
バックアップは復旧できなければ意味がない
この一言に、AWS Backup の設計思想が凝縮されていると感じました。
3. AWS のバックアップ設計思想
まず前提として、AWS は以下のような最悪シナリオ寄りの発想でバックアップ設計を考えています。
- 侵害を防ぎ切ることは不可能
- 管理者権限は奪われる
- 単独では間違える、もしくは悪意が潜む
つまり「人」や「権限」を信頼し切らない前提です。
この前提に立つと、従来の「管理者が復旧する」モデルは成立しません。
このような状況でもバックアップからの復旧を成功させるために、先ほどの構成図にはいくつかの思想的な工夫が込められています。
論理エアギャップ
アカウントや組織を超えた変更不可の Vault を用意します。
これにより、侵害されたアカウントから手が届かない場所を作ります。
ポイントは、バックアップを同じ信頼境界に置かないことです。
管理者権限を奪われても、バックアップそのものに触れられない構成にすることで、復旧の最後の砦を残します。
マルチアカウント
ワークロード用のアカウント以外に、復旧用アカウント、フォレンジック用アカウントを準備します。
侵害が疑われる環境をそのまま使って復旧を進めると、バックドアやマルウェアを再び持ち込むリスクがあります。
そのため、復旧先は明確に侵害ドメインの外に用意します。
また、復旧テストや検証作業も本番とは分離された環境で行うことで、安全性と再現性を高めます。
マルチパーティー承認
重要な操作は、複数人の承認がなければ進められないプロセスにします。
復旧アカウント内の Vault へのアクセスなどのケースが当てはまります。
これは、単独の管理者を信頼しない設計です。
1 人の認証情報や判断に依存しないことで、攻撃者が権限を奪取しても復旧経路を断ち切れないようにします。
復旧テスト
定期的な復旧テストを行います。
バックアップが存在していることと、それを実際に復旧できること、は全く違います。
復旧できる想定だったが、実際には手順が古い、時間が足りない、といった事態は珍しくありません。
AWS Backup の Restore Testing (RT) では、復旧テストの計画、実施、レポート生成、リソースの片付けまでを一連の流れで実施できます。
これにより、バックアップが信頼できることを継続的に検証できます。
多彩なサイバー攻撃を前提にした AWS の本気 (再掲)
まとめ
スライドを見た時は正直、「バックアップでここまでやるのか。人間不信が過ぎる！」と感じました。
しかしそれは、攻撃者がそこまで踏み込むシナリオが、すでに現実的であるということを示しているのだと思います。
ワークロードが重要であるほど、復旧できる前提を疑わなくてはならないと実感しました。
コストや労力とのバランスは取りつつも、セキュリティエンジニアとして備えておきたい着眼点であるように思います。
今日も小さな学びを。
AWS re:Invent 2025 のまとめ記事はこちら