向井氏が示した3-2-1-1-0ルールの最初の「3」は、オリジナルのソースデータとは別に3つのコピーを持つことを意味する。3つのコピーのうち2つは異なるAWSアカウントや異なるリージョンに持ち、うち1つはWORM技術を適用してイミュータブルな形で保存する。ディザスターリカバリー対策を兼ねて、コピーを異なるリージョンに保持する選択肢もある。

　従来のルールから加えられた4つ目の「1」は、コピーのうち1つを、障害復旧などですぐに戻せるようローカルに保持することを意味する。いわゆるバックアップが相当する。最後の「0」は、復旧テストや復旧訓練を行い、リストア時の問題をゼロにするというものだ。

　3-2-1-1-0ルールの実践においても、WORMによってイミュータブルにすることと、専用領域へのバックアップの隔離という2点が重要だと向井氏は述べた。

　WORMは前述の通り、AWSのさまざまなサービスによって実現できる。一方、専用領域への隔離は、「異なるアカウントへのコピー」によって実現できる点がAWSならではの特徴だという。

3-2-1-1-0ルール（筆者撮影：セッション資料）

　一般に、業務用システムを稼働させるAWSアカウントは複数の組織にまたがり、多くの関係者に利用される。しかし、アクセスできる関係者が多ければ、アカウント情報の漏えいなどによって、取得したバックアップが削除されてしまうリスクも高くなる。

　そこで向井氏が推奨するのが、AWS Backupを用い、異なるAWSアカウントへバックアップをコピーする方法だ。具体的にはバックアップ専用のAWSアカウントを作成し、一部の限られた従業員にのみアクセス権を与えることで、漏えい時のリスクを減らすことができる。

　こうしてバックアップにアクセスできるユーザーを限定し、さらにWORMによる保護をかけることで、万一、データ保護管理者の権限が漏えいしてしまった際でも、大事なバックアップデータを守っていくことができる。

よりアドバンストな対策で保護を徹底

　最後に紹介されたのが、「AWS Backup論理エアギャップボールト」を活用した、よりアドバンストな対策だ。バックアップデータをいっそう確実に隔離して保護し、復旧時間をさらに短縮できる点が利点だという。

　AWS Backup論理エアギャップボールトでは、利用者が作成して業務システムを稼働させているアカウントではなく、AWSの管理下にある専用アカウントでバックアップを取得し、隔離した形で保管する。デフォルトでVault Lockが有効化されているため、WORMによる保護を徹底できる。

論理エアギャップボールト（筆者撮影：セッション資料）

　さらに、「GuardDuty Malware Protection」と連携することで、取得したバックアップデータに対するマルウェアスキャンも可能だ。過去の報告では、マルウェア感染から復旧を図るべくリストアしようとしたら、実はバックアップデータまで汚染されていたというケースが存在している。しかし、定期的なスキャンに加え、リストア時に最新のシグネチャを用いてスキャンすれば、健全性を確認し、万全の体制でリストアできるようになる。

　向井氏はこのように、ランサムウェア感染に備えたバックアップの取得方法を説明した上で、さらに、リストアに備えた重要なポイントを指摘した。3-2-1-1-0ルールにも含まれている「復旧」のテストだ。

　ランサムウェア被害を受けてバックアップから復旧を図ろうとしてもうまくいかなかったという場合には、バックアップ自体が削除されたり、暗号化されたりするケースや、復旧準備の不備があるという。

　向井氏は、「ひとたび本番運用を開始したシステムでは、本当に業務が再開できるレベルで復旧作業を行うのは、非常に複雑で難易度が高い」と指摘し、本番稼働前の一度だけでなく、稼働後も定期的にリストアのテストを実施していくべきだとした。AWS Backupにはそれを支援する自動復元テスト機能が付属している。さらに、Amazon EventBridgeを利用して、その企業独自のテストを組み込むことも可能だ。

まずは「何を守りたいか」に基づいて対策の検討を

　向井氏は、AWS環境上での一連のバックアップ手法を説明した上で、最後に、オンプレミス環境からAmazon S3へのバックアップについても言及した。

　企業の状況によっては、クラウド移行を検討しながらもなかなかすぐには動けず、ひとまず、今のオンプレミス環境ですぐにランサムウェアからの復旧対策をしたいというニーズもある。そうした場合は、オンプレミス環境で広く利用されているバックアップソフトウェアを経由し、直接Amazon S3上へとバックアップが可能だ。製品によってはWORMによる保護を実施したり、リージョンをまたいでバックアップを取得してディザスターリカバリー対策を兼ねることもできる。

　最後に向井氏は「自社で抱える全てのシステムに対し画一的に対策が必要かというと、答えはノーです」と述べ、まず自分たちが守りたいデータを特定し、その重要度に応じてコストや要件とのトレードオフを検討しながら、複数のアプローチのうちどこまで対策を行うかを検討していってほしいと述べ、講演を締めくくった。