re:Invent 2023: AWSのバックアップと災害復旧戦略 - レジリエンス向上とランサムウェア対策
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Backup and disaster recovery strategies for increased resilience (ARC208)
この動画では、レジリエンスを高めるためのバックアップと災害復旧戦略について詳しく解説します。RPOとRTOの概念から始まり、AWS Elastic Disaster Recoveryを使った最新のDR手法、そしてランサムウェア対策まで幅広くカバーします。特に、コスト効率の高いCross-Region DRの実現方法や、データバンカーアカウントを活用したセキュアなバックアップ戦略など、クラウドならではの先進的なアプローチを学べます。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
レジリエンスを高めるバックアップと災害復旧戦略の概要
本日は、レジリエンスを高めるためのバックアップと災害復旧戦略について説明します。 まず、戦略を議論する前に重要な側面である、レジリエンス要件から始めます。データ保護、レジリエンス、災害復旧、バックアップについて、私たちが達成しようとしていること、要件は何かを特定する必要があります。これにより、私たち全員が同じ言語で話し、達成したいメトリクスとKPIを定義できます。その後、戦略について議論し、災害復旧とバックアップについて深く掘り下げ、アーキテクチャ図やワークフローを探ります。最後に、特にランサムウェアからの復旧と、実施したい対策について取り上げます。
レジリエンス要件の定義とデプロイメントパターンの考慮
各企業が自社のレジリエンス要件を定義する際に必要なものは何でしょうか？ここでは、レジリエンスとデータ保護要件の重要な側面をいくつか取り上げます。まずは復旧目標から始めましょう。 復旧目標、特にRPOとRTOは、復旧要件とレジリエンスに関する一般的な概念の一つです。RPO（Recovery Point Objective）は、インフラ障害、ランサムウェア攻撃、データ破損、ヒューマンエラーなどの事故が発生した場合に、失っても許容できるデータ量を示します。例えば、毎日データのスナップショットを取っている場合、復旧時に最大1日分のデータを失う可能性があります。さまざまな戦略でどのようにRPOを達成するかについて後ほど説明します。
RTO（Recovery Time Objective）は、事故発生時にどれだけのダウンタイムを許容できるかを指します。これは、たとえデータの一部を失っても、ビジネスを再開するまでにかかる時間のことです。RPOとRTOは非常に重要で、一律ではありません。ビジネス、システム、アプリケーション、さらにはリソースごとに異なります。異なるワークロードに対して、復旧目標を定義する必要があります。
次に、デプロイメントパターンについて話しましょう。これは当然、企業によって異なります。考慮すべき質問として、以下のようなものがあります：復旧が必要なオンプレミスで稼働しているワークロードがまだありますか？マルチクラウドにする必要がありますか？クラウド間の災害復旧戦略が必要ですか、それともすべてのワークロードがAWS上にありますか？また、戦略を定義する必要があります：Cross-Region復旧が必要ですか、それともCross-Availability Zone復旧が必要ですか？これらは、適切なソリューションを選択する前に議論し、定義する必要がある重要な概念です。
では、バックアップポリシーを決定しましょう。まず保持期間から始めます：バックアップしたデータをどれくらいの期間保持する必要がありますか？1週間、2週間必要ですか？頻度はどうでしょうか？これらは、業界によってはコンプライアンスや法的要件を含む複数の要件によって決まります。また、データ保護要件も考慮します。データをどれくらいの期間、どのような頻度で保持する必要があるかを知る必要があります。多くのお客様が、異なるワークロードに対して複数のポリシーを使用しているのを見かけます。
AWSリソースの保護と適切な解決策の選択
先ほど災害復旧について触れましたが、バックアップに関しても同様の考慮が必要です。クロスリージョンまたは同一リージョン内での復元が必要かどうか、オブジェクトロック（つまり、スナップショットの不変性）が必要かどうかを検討する必要があります。ランサムウェアについて詳しく説明する際に、この点についてさらに掘り下げます。また、バックアップ、災害復旧、本番ワークロードのアカウント間のトポロジーについても考慮が必要です。ランサムウェアはこれらの考慮事項の主要な要因ですが、他にも検討すべき点があります。
次に、達成すべきことだけでなく、何を保護するのかを特定する必要があります。Amazon EBS、Amazon S3、Amazon FSx、Amazon EFS、Amazon EC2、そしてAmazon Aurora、Amazon DynamoDB、Amazon RDS、Amazon Redshiftなどのデータベースを含む、AWSリソースに適切な保護を適用する必要があります。
これらのリソースに適した解決策を選択するには、さまざまなストレージサービス、コンピューティングサービス、マネージドデータベースで利用可能な様々なオプションを考慮する必要があります。それぞれに固有の制約とオプションがあり、その中から選択することができます。すべてのAWSリソースにわたって包括的な保護を確保するために、より広範な戦略と結びつけることが重要です。
クラウドを活用した災害復旧の新しいパラダイム
いくつかの高レベルの戦略とオプションに深入りする前に、災害復旧について少し話し、いわゆる「古い」やり方 に立ち返ってみましょう。オンプレミスの災害復旧パターンを見てみると、本番ワークロードを実行するためのハードウェアを備えたプライマリサイト、つまりプライマリデータセンターがあります。そこには、パフォーマンスの高いストレージ、高性能CPUがあり、本番ワークロードを実行するためにすべてが完全にプロビジョニングされています。一般的な方法は、オンプレミスにセカンダリの復旧サイトも用意することでした。別のデータセンターが必要で、2つのサイト間でストレージレベルやアプリケーションレベル、あるいはその両方でなんらかの形のレプリケーションを有効にする必要がありました。
復旧サイトはフェイルオーバー時に本番ワークロードを実行する必要があるため、完全にプロビジョニングされている必要があります。復旧サイトにも同じような高性能なストレージ、高性能なCPU、コンピューティングハードウェアが必要です。基本的に、コストが2倍になるわけです。 ほとんどのレプリケーションや継続的なレプリケーションソリューションは、完全にプロビジョニングされたリソースを必要としません。データをレプリケートするだけで、複雑な計算は行いません。データの読み取りもそれほど多くありません。そのため、「古い」やり方では、支出を倍増させ、いつか必要になるかもしれないからという理由で、現在使用していないにもかかわらず、すべてを前もって支払っていました。ただそこにあって、ほこりをかぶっているだけだったのです。
クラウドを使う理由、災害復旧にAWSを使う理由は何でしょうか？一言で言えば、それは「エラスティシティ」です。エラスティシティを備えたクラウドモデルの基本的な考え方は、「使った分だけ、使った時に支払う」というものです。いつか使うかもしれないからといって、前もって支払う必要はありません。災害復旧の「新しい」方法と呼ばれるこのパラダイムを見てみると、本番環境がオンプレミスで動いているか、AWSのクラウドで動いているか、Cross-RegionかCross-Availability Zoneかに関わらず、プライマリサイトは完全にプロビジョニングされ、本番ワークロードを実行している必要があります。
しかし、AWSにある復旧サイトは、完全にプロビジョニングされている必要はありません。継続的なレプリケーションをサポートするために必要な最小限のリソースだけを実行すればよいのです。つまり、通常時は、レプリケーション、つまり継続的なレプリケーションをサポートするために必要な最小限のコストまで大幅に削減できるのです。そして、DRドリルを実行する場合や、AWSの復旧サイトにフェイルオーバーする必要がある場合にのみ、本番用のリソースとインフラを完全にプロビジョニングします。つまり、1年中レプリケーションを行い、1日だけDRドリルを実行する場合、1日分の料金だけを支払えばよいのです。
クラウドにおけるデータレジリエンスのオプションとトレードオフ
では、クラウド全体におけるデータレジリエンスのオプションについて話しましょう。クラウドにおける災害復旧の意味と、それが「古い」パラダイムを変え、打ち破ることを理解しました。アーキテクチャ図に進むと、これらの領域について深く掘り下げ、どのように機能するのか、どこに魔法があるのかを見ていきます。しかし今は、鳥瞰図的に見て、クラウドにおけるデータレジリエンスのオプションを見てみましょう。まず、ご覧のように、これはスペクトラムです。なぜ複数のオプションがあるのでしょうか？いつものように、答えは「トレードオフがあるから」です。これらのオプションには重要なトレードオフがあります。
実際には、複数のトレードオフがあります。複雑さ、機能セット、レポーティングの簡便さ、モニタリング、メトリクスなど、ソリューションを選択する際には様々なトレードオフがあります。しかし、私たちが目にする最もシンプルで主要な要因に焦点を当てましょう：復旧目標（RPOとRTO）とコストのトレードオフです。
簡単に言えば、より積極的で低い復旧目標を望むなら、インフラにより多くの費用を支払う必要があります。スペクトラム全体のオプションを見てみましょう。
一方の極端には、バックアップとリストアがあります。ここでの目標は、できる限りコストを削減することです。そのため、RPOは数時間、あるいは1日近くになることもあり、バックアップのRTOも数時間かかる可能性があります。もう一方の極端には、アクティブ/アクティブまたはHigh Availabilityソリューションがあります。これらは、オンプレミス環境で見られるような、数秒のRPOとほぼリアルタイムのRTOを提供します。ただし、プライマリリージョンと復旧用のAvailability Zoneまたはリージョンの両方に、完全にプロビジョニングされたリソースが必要となるため、非常に低いRTOとダウンタイムゼロが求められる極端なケースにのみ適しています。
これらの両極端の間に、Pilot LightとWarm Standbyのパラダイムがあります。Warm Standbyは数分のRTOとRPOを提供し、High Availabilityソリューションよりも少し低コストです。Pilot Lightは、さらに低コストで、数分のRPOと数時間のRTOを提供します。このパラダイムは新しいものではありませんが、AWSでは、これらの常識に挑戦し、より良い結果を達成することを目指しています。Elastic Disaster Recoveryの目標は、可能な限り最高の復旧目標を最低のコストで提供することです。
Elastic Disaster Recoveryを見ると、興味深い組み合わせがあることがわかります。アクティブ/アクティブまたはHigh Availabilityソリューションと同様に、数秒のRPOを達成しており、ほとんどデータを失うことはありません。レプリケーションは非常に小さな増分で行われます。RTOは数分です。これは、一部のリソースがプロビジョニングの準備ができているものの、復旧時にまだ作業が必要だからです。しかし、コストはPilot Lightソリューションに匹敵します。私たちの主要なミッションの1つは、これらのパラダイムに挑戦し、より積極的な復旧目標を持つ、よりコスト効率の高いソリューションを提供することです。
AWS Elastic Disaster Recovery (DRS)の仕組みと利点
Elastic Disaster Recoveryの仕組みと構成図を詳しく見る前に、いくつかの主要な利点について話しましょう。 最初の重要な要素は、迅速な復旧です。私たちは、数時間ではなく、より低コストで数分のRTOを目指しています。つまり、非常に積極的でコスト効率の高いRTOを提供しています。さらに、テストが容易であることも、災害復旧戦略を考える上で重要です。
低コストと積極的な復旧目標を持つことは重要ですが、本当の問題は、必要なときに災害復旧ソリューションを確実に利用できるかどうかです。これは結局のところ、テストに帰着します。私たちは非破壊的なDRドリルを提供しており、進行中のレプリケーション、復旧態勢、または本番環境に影響を与えることなく、好きなだけテストを行うことができます。これらのテストは広範囲にわたり、機能性と復旧可能性の幅広いスペクトルを評価することができます。フェイルオーバーをテストできることが重要です。
私たちは先日、DRドリルにアプリケーションレベルの検証を組み込む機能をリリースしました。DRドリルは、ソース環境に全く影響を与えることなく、すべてのリソースをプロビジョニングしてフェイルオーバーを実行します。アプリケーションレベルでの事前定義された検証があります。インフラが稼働しているだけでは十分ではありません。データベースが機能しているか、さまざまなアプリケーションが動作しているか、エンドポイントにアクセスできるかを確認したいのです。複数の自動検証を組み込むことができるので、DRドリルが簡単になり、フィードバックを確認して好きな頻度で実行できます。また、DRドリル中の短時間だけプロビジョニングされたリソースに対して料金を支払えばよいので、コストもそれほどかかりません。
コスト削減について話しましたが、その仕組みを見ていきましょう。ランサムウェアからの復旧は大きなトピックで、バックアップと災害復旧の文脈で、その違いやベストプラクティスについて話し合います。データ保護に関しては、先ほど述べたように、非常に低いRPOを提供しています。できるだけデータの損失を最小限に抑えたいと考えており、もちろん、データの破損やランサムウェアなどの場合に備えて、特定時点へのリカバリーも提供しています。
ライフサイクルを簡単に見てから、その仕組みについて詳しく説明しましょう。まず、ソースサーバーにエージェントをインストールすることから始まります。オンプレミスで稼働している場合は、実際のレプリケーションを行うエージェントをインストールします。EC2で稼働している場合は、今日ではコンソールやAPIから有効にできるので、手動でエージェントをインストールする必要はありません。これにより、自動的にレプリケーションが開始され、レプリケーションに必要なリソースがプロビジョニングされます。つまり、レプリケーション用のリソースの管理やプロビジョニングにおけるオーバーヘッドはありません。
次にテストを行います。リカバリーが可能か、フェイルオーバーができるか、元のインフラストラクチャへのフェイルバックができるかを確認できます。繰り返しになりますが、これは非破壊的です。アプリケーションレベルのテストを組み込むこともできます。そして、運用フェーズに入ります。災害復旧とレプリケーションにおいては、これは継続的なプロセスです。レプリケーションは継続的に行われ、定期的なドリルを実行し、何か問題が発生した場合にはアラートを設定できます。何らかの理由でレプリケーション用のポートをブロックした場合、アラートを受け取るので、常に保護されていることがわかります。
そして、イベントが発生した場合、リージョン間、AZ間、オンプレミスからクラウドへのフェイルオーバーが可能で、必要に応じてフェイルバックもできます。フェイルバック時には、フェイルオーバー中に行われたすべての変更（デルタ）を取得し、プライマリサイトに複製します。
バックアップとリストアの戦略：クロスリージョンDRとオンプレミスからクラウドへの移行
では、その仕組みについて詳しく見ていきましょう。どのようにしてコストを抑えながら、このような積極的な復旧時間目標を達成できるのかを見ていきます。まず、オンプレミスのデータセンターからAWSへの例から始めましょう。左側にはあなたのデータセンターがあります。オンプレミスでサーバーやVMが稼働しています。この例では、AWSを復旧サイトとして使用します。ちなみに、これは非常に一般的な移行パターンだと考えています。お客様が最初に復旧サイトやリカバリデータセンターを撤退する際、まずAWSを復旧サイトとして使用し始め、その後完全な移行を行いたい場合は、単にフェイルオーバーしてフェイルバックしないという方法を取ることができます。
ソースサーバーにエージェントをインストールすると、レプリケーションが開始されます。レプリケーションは継続的で非同期、ブロックレベルで行われます。これは何を意味するかというと、まず、レプリケーションの非同期性により、ソースサーバーへの影響が最小限に抑えられるということです。進行中の書き込みを妨げることはありません。これは非常に重要なポイントです。また、継続的に非常に小さな単位でレプリケーションを行うため、RPOを最小限に、通常は数秒または1秒未満に抑えることができます。そして、これは圧縮および暗号化されて継続的にレプリケーションされるため、ネットワークコストを節約しながら、常に最新のデータがAWSに存在する状況を作り出すことができます。
そのためには、複製するデータを取得するために、AWSにリソースをプロビジョニングする必要があります。右側に、お客様のAWSアカウントが表示されています。AWSアカウント内で、AWS Elastic Disaster Recovery (DRS)がアプリケーションに必要なすべてのリソースをプロビジョニングします。これがステージングエリアです。
継続的なレプリケーションと復旧のために、異なるサブネットを使用できます。また、異なるVPCや異なるアカウントを選択することもでき、それをいつ、なぜ行うのかについても後ほど見ていきます。まず、基本的な構成要素を理解するために、DRSが低コストのEC2インスタンスをプロビジョニングしてレプリケーションのソースとなるステージングエリアを設けます。これらのEC2インスタンスは1対多の関係で機能し、複数のソースVMに対して1つの軽量EC2インスタンスでレプリケーションを処理できます。ソース上のドライブまたはディスクごとにアプリケーション用のEBSボリュームをプロビジョニングします。
ボリュームタイプは動的です。レプリケーションについて考えると、興味深い点は、ほとんど読み取りを行わないことです。データを書き込む必要があり、それも大量に書き込む必要がありますが、あまり読み取る必要はありません。読み取りの必要がない場合、ハイドレーションに敏感ではないため、ボリュームタイプを動的に変更して必要なパフォーマンスを得ることができます。DRSは、ソース上のデータの変更率に応じて異なるボリュームタイプを自動的に切り替え、常にコストを可能な限り低く抑えます。しかし、データはそこにあります。そのため、復旧が必要になったときには、継続的な状態でコストを大幅に削減しているにもかかわらず、最新のデータを持っています。
次に、復旧サブネットがあります。これも異なるVPCや異なるアカウントにすることができます。ここでは、EC2起動テンプレートやスマートな適切なサイジングのメカニズムとフレームワークに基づいて、最新のデータを取得します。復旧やDRドリルの場合、ターゲットのVPCアカウントまたはサブネットで、必要なものを完全にプロビジョニングして実行します。つまり、フェイルオーバーして1時間実行する場合、本番環境用に完全にプロビジョニングされた高性能ボリュームと高性能インスタンスを取得します。 フェイルバックが必要な場合、オンプレミスへのフェイルバックをサポートし、AWSにフェイルオーバーしている間に生成されたすべてのデータをレプリケートします。オンプレミスで実行できるフェイルバッククライアントがあり、これらのデルタをすべて取得できるため、オンプレミスにフェイルバックできます。
では、クロスリージョンDRと、オンプレミスからクラウドへの移行とクロスリージョンの違いについて話しましょう。アーキテクチャ図の違いの詳細にはすぐに入りますが、まずはクロスリージョンの主要な利点である、ネットワーク構成、レプリケーション、復旧について見ていきましょう。 左側に、本番環境を実行している1つのAWSリージョンがあります。DRSにエージェントをインストールします。インストールプロセス自体はEC2インスタンスプロファイルを使用できるため、認証情報は必要ありません。コンソールから実行でき、インスタンスにログインする必要もありません。そのため、エクスペリエンスは非常に優れていますが、基盤となるインフラストラクチャは同じです。
私たちは、他のAWS RegionやAvailability Zoneに対して、継続的なブロックレベルの非同期レプリケーションを行っています。しかし、データだけでなく設定も重要です。例えば、DRドリルを実施して成功し、望んでいたアプリケーションレベルのテストもすべて行えたとします。では、VPCが適切に設定されているかどうかをどのように確認すればよいでしょうか？
これは、将来の復旧シナリオにとって非常に重要な問題です。セキュリティグループが変更されたのに復旧サイトで更新し忘れたり、ACL、ルートテーブル、サブネット、あるいはトポロジーが少し異なっているかもしれません。この問題に対処するため、AWS Elastic Disaster Recovery (DRS)はデータ自体だけでなく、これらのVPC設定もレプリケートします。プライマリリージョンでセキュリティグループを変更すると、それも復旧リージョンにレプリケートされます。そのため、定期的なドリルを実行する際や、フェイルオーバーが必要な場合に、正常に機能する状態であることが分かります。
先ほど述べたように、セキュリティグループ、ACL、ルートテーブル、サブネットは、実際のデータやEC2インスタンス自体のメタデータとともにレプリケートされます。Cross-Regionでフェイルバックする必要がある場合、オンプレミスのデータセンターまで戻す必要はないので、クライアントを失敗させる必要はありません。そのため、かなり対称的です。APIを呼び出すか、コンソールからレプリケーションの方向を変更するだけです。夏の拠点、冬の拠点という戦略を取っているお客様もいます。単に定期的に一つのRegionや Availability Zoneから別のものにフェイルオーバーし、数ヶ月そこにとどまるのです。こうすることで、定期的にフェイルオーバーできることを確認し、障害から復旧する必要がある場合に備えられていると感じています。
これまで見てきた主な利点と、非対称レプリケーションの戦略が非常に強力である理由をまとめてみましょう。レプリケーションの非対称性を考えると、つまり一方に完全にプロビジョニングされたリソースがあり、もう一方には非常に軽くプロビジョニングされたリソースがありますが、小さな単位でレプリケートしています。日次スナップショットを取るのではありません。より長期のスナップショットを低頻度で取ることもありますが、それについても後で触れます。しかし、低コストの災害復旧のためには、この非対称性が重要なポイントであり、継続的にレプリケートする非常に小さなデータチャンクが必要です。これにより、RPOを積極的に保ちながらコストを削減できます。
テストは重要な要素です。ソリューションをテストし、頻繁にテストする必要があります。コンプライアンス要件で年に1回のみ災害復旧ドリルを行う場合でも、お客様にはより頻繁にテストすることをお勧めしています。頻繁にテストするためには、DRドリルを実行する際の摩擦を、コストと運用オーバーヘッドの両面で取り除き、減らす必要があります。簡単で、シンプルで、自動化されているべきです。本番環境への影響はゼロです。過去数ヶ月から数年の改善により、以前よりもはるかに頻繁にこれらのドリルを実行し始めているお客様が増えています。
ランサムウェアからの復旧：検知と保持ポリシーの重要性
では、バックアップとリストアについて話しましょう。私たちはディザスタリカバリについて話し、RPOをできるだけ低く抑えたいと考えていますが、それにはコストがかかります。そのコストを可能な限り最適化して下げたいと思いますが、それでも軽量のEC2インスタンスや低コストのEBS Volumeが必要で、ある程度のコストがかかります。では、重要度の低いアプリケーションやリソースについてはどうでしょうか？バックアップとリストアについて見ていきましょう。通常、バックアップと言えば、RTOやRPOが数時間単位のものを指します。最も一般的なのは、日次バックアップです。そして、長期保存が可能です。では、バックアップとリストアを使用して、イベントから復旧する例を見てみましょう。この例では、AWSのリージョン内で私のワークロードが稼働しており、EC2インスタンスがあります。
このEC2インスタンスにはEBS VolumeとRDSインスタンスがあり、すべて単一のAvailability Zoneで稼働しています。また、そのEC2インスタンスに接続されたEFSファイルシステムもあります。ここで、バックアップポリシーを有効にしてバックアップを実行します。EBSスナップショット、RDSスナップショット、そしてEFSをバックアップするためのAWS Backupを使用して、バックアップを実行しています。ここで重要なのは、これらのバックアップがすべてゾーン単位ではなく、リージョン単位で保存されているということです。つまり、特定のAvailability Zoneで何か起こっても影響を受けません。
停止が発生したとしましょう。この例では、AZの停止を想定していますが、データの破損や、環境や特定のリソースに固有の問題である可能性もあります。特定のリソースが誤動作している可能性もあります。私たちは常に障害に備える必要があります。しかし、この場合、そのAZが機能していません。これを、バックアップがゾーン単位であると呼びます。ここで、EBSスナップショットからリストアを行い、リストアされたボリュームをマウントするEC2インスタンスを作成し、EC2インスタンスを影響を受けていないEFSに接続し、RDSをリストアします。これらすべてを別のAvailability Zoneで行います。
これで、バックアップからリストアできます。RTOはあまり影響を受けないので、比較的積極的なRTOを維持できます。しかし、厳しいRPO要件がない場合、RPOは数時間になる可能性があります。同じアプローチをクロスリージョンのバックアップとリストアにも適用できます。S3レベルでクロスリージョンレプリケーションを有効にすることで、これを実現できます。これにより、スナップショットはゾーン単位ではなくリージョン単位になるだけでなく、クロスリージョンにもなります。スナップショットをレプリケートしたいリージョンを選択できます。これで、スナップショットは常に別のリージョンにあります。
より極端なイベントの場合など、別のリージョンに復旧したい場合は、単にそれらのリソースをすべて別のリージョンにリストアするだけです。ディザスタリカバリとバックアップ・リストアについて見てきました。問題は、「それぞれのオプションをいつ選択すべきか」ということです。そして、答えは、各アプリケーションの非常に具体的な要件によって異なります。時にはリソースレベルで、また時には両方の戦略を適用したいと考えることもあります。つまり、ディザスタリカバリを1日に絞り込み、コンプライアンス要件やデータ保護のために長期保存用のバックアップを持つということです。
では、次のトピックに移りましょう。ランサムウェアからの復旧について詳しく見ていく前に、まず検知について話しましょう。問題は「復旧が必要だと、どうやって分かるのか？リストアが必要だと、フェイルオーバーを実行する必要があると、どうやって分かるのか」ということです。時には簡単です。本番環境がダウンして、まったく利用できない場合。そうなれば復旧が必要だと分かります。運用アラートがあり、ダウンタイムが発生していることが分かるので、復旧が必要だと分かります。しかし、時にはもっと複雑です。データベース内の1つのレコードが破損した場合はどうでしょうか？そのような場合にリストアが必要だとしても、それを検知するのは少し遅れるかもしれません。数日後になることもあります。
そのようなシナリオでは、より長期間スナップショットを保持する必要があり、ここで保持ポリシーが重要になります。数日前に戻る必要がある場合、おそらくその日の何分や何時間単位の粒度はそれほど重要ではないので、コストを削減するために日次の保持にしたいでしょう。さらに遡って
コンプライアンス監査のために保持する場合は、その間隔をさらに広げることができます。非常によく見られるのは、より動的で複雑な保持ポリシーです。これも有効な戦略です。例えば、1ヶ月間毎日スナップショットを保存したり、災害復旧から始めて最初の1時間は10分ごとに保存したりします。そうすれば、イベントが発生して20分後に検知しても、丸1日戻る必要はありません。前日の24時間は1時間ごとに保存し、遡るほど間隔を広げていきます。その後、30日間は日次保持、1年間は月次保持、そしてコンプライアンス要件に基づいて年次保持を行います。これは、継続的なコストを削減し、トレードオフを管理するもう1つの方法です。
ランサムウェア対策のための包括的なアプローチ：分離、検知、復旧
では、ランサムウェアからの復旧について話しましょう。ランサムウェアは、ここ数年でますます増加しているという意味で非常にホットなトピックです。お客様にとってより大きな痛みの種、より大きな懸念事項になっているのを目にしています。まず、ランサムウェアとは何でしょうか？基本的には、ただのソフトウェアですが、マルウェアのような悪意のあるものです。通常、組織に侵入してデータの暗号化を開始します。そのデータは暗号化され、攻撃者は通常、データを復号化するためのキーを提供する代わりに何らかの支払いを要求します。これが身代金（ランサム）です。お客様がランサムウェアの身代金を支払いたくない理由はたくさんあります。明らかに支払いたくありませんが、ダウンタイムも発生します。その取引には時間がかかります。その間、組織はダウンしています。もちろん、何度も繰り返し発生する可能性があり、それは私たちが望む評判ではありません。
そのため、ランサムウェアから自身を守りたいと考えます。そのための重要な要素がいくつかあります。まずは復旧から始めましょう。本番アカウントがあるという例を見てみましょう。そこでは様々なワークロードが実行されており、データストア、コンピュートなどがあり、AWS Backupがそれらをバックアップするように設定されています。ランサムウェアの主要なリスクは、データの暗号化だけでなく、どのようにしてデータを暗号化できたかということです。「アカウントにアクセスできたのか？アカウントのrootアクセス権を持っていたのか？IDを盗まれたのか？どのように起こったのか？」影響を受けている最中にそれを理解したくはありません。そのため、異なる問題を分離し、切り離したいと考えます。
そのために、データバンカーアカウントを開設します。これは異なるAWS KMSキーセットを持つ別のアカウントです。そこで別のAWS Backup Vaultを定義しますが、コンプライアンスモードでBackup Vault Lockを有効にします。これにより、誰もスナップショットを削除できなくなります。主なリスクは、誰かがデータを暗号化することですが、そのアカウントにアクセスできる場合、バックアップをオフにしたり、スナップショットを削除したりする可能性があります。しかし、完全に分離されたデータバンカーアカウントを使用し、Vault Lockを有効にすれば、ルートアクセスでさえスナップショットを削除できません。ただし、スナップショットをまとめて保管する必要があります。そのため、Vault間でスナップショットをプッシュする機能を有効にする必要があります。これで、改ざんから完全に安全な不変のスナップショットを持つバンカーアカウントができました。
しかし、もし誰かが...少し戻って考えてみましょう。マルウェアやランサムウェアには、2つの非常に重要なイベントまたは時点があります。1つは感染の時点、つまりそのソフトウェアがリソースに到達した時です。2つ目は暗号化の時点、つまりデータの暗号化が始まった時です。そしてこの2つの間にはある程度の時間があるかもしれません。攻撃者がシステムに感染させ、後で暗号化を行うという形の攻撃も見られます。
攻撃者はバックアップをオフにしてから後で暗号化するかもしれません。そのため、暗号化を検出した時点では既に遅く、バックアップがない状態になっているかもしれません。攻撃者がバックアップを削除していなくても、バックアップをオフにして待機している可能性があります。 そのため、バックアップが停止されたり、設定が変更されたりした場合に適切にアラートを出し、監視するメカニズムを確保する必要があります。これを本番アカウントではなく、データバンカーアカウントで行いたいのです。誰かがバックアップをオフにしようとした場合、必要なすべてのアラートを受け取ることができます。
さて、この例でランサムウェアの影響を受けたとしましょう。復旧したいと思います。おそらく、そのワークロードアカウントは侵害されています。 そしてもし侵害されている場合、そのアカウントで何が起こったかを理解しようとせずに、できるだけ早く復旧したいと思います。そのため、ベストプラクティスの1つは、復旧用に別のアカウントを設定することです。 そのアカウントに別のAWS Backup Vaultを用意し、復旧のためにバックアップをプッシュします。 ここから、AWS Backupのリストア機能を使用して、 本番ワークロードを復旧できます。
このソリューションには、いくつかの補完的なサービスがあります。Amazon CloudWatchやAWS CloudTrailを使用してアラート、メトリクス、ログを取得したいですし、検出やスキャンツールも必要です。Amazon GuardDutyなどがこのソリューションを補完します。 では、より短いRecovery Point Objective (RPO)でのランサムウェア対策について話しましょう。ランサムウェア攻撃に対してRPOを短くするとはどういう意味でしょうか？データが暗号化されたとしても、失うデータ量を最小限に抑えたいということです。つまり、頻繁にポイントインタイムスナップショットを取る必要があります。1日全体をロールバックしたくはありません。しかし、それだけでは不十分です。迅速な検出とクリーンアップが必要です。ここで、ランサムウェア対策のためのディザスタリカバリが重要になってきます。
さて、バックアップ計画ができました。それに加えて、AWS Elastic Disaster Recoveryをランサムウェア対策に使用する場合も、同じコンセプトを適用します。まず、アカウントの分離から始めます。レプリケーションするデータを別のアカウントに置き、本番アカウントや復旧アカウントから完全に分離された、変更不可能なスナップショットを作成したいと考えています。バックアップフローで見たのと同様の変更不可能なスナップショットがありますが、レプリケーションは日次スナップショットではなく、ブロックレベルで行われます。そのため、タイトな特定時点のスナップショットを取得でき、十分に早く検知できれば、例えばランサムウェアが10分前にデータの暗号化を開始したことがわかれば、10分前にロールバックして10分のデータしか失わずに済み、丸1日分をロールバックする必要がありません。
しかし、そのためには検知が必要です。AWS Elastic Disaster Recoveryには、検知ソフトウェアとの統合機能があります。例えば、ソース側でパートナーシップを結んでいるCrowdStrikeやSentinelOneなどがあります。これらのソフトウェアがランサムウェアを検知すると、暗号化開始直後に、AWS DRSと完全に統合されて、データの最も近くてクリーンな状態への復旧を呼び出します。このように、復元能力によってダウンタイムを回避または最小限に抑えるだけでなく、データ損失も最小限に抑えることができます。繰り返しになりますが、短い特定時点での復旧、非常に迅速な検知、そして分離が必要です。なぜなら、1分後に再び感染してしまう状態に復旧したくないからです。
ここで、ランサムウェア攻撃には2つの異なる時点があったことを思い出してください。感染時点と暗号化時点です。データ損失を最小限に抑えたい場合、感染時点を見つけてそこまで戻るのではなく、非常に迅速な復旧と、そのランサムウェアを除去するクリーンアップメカニズムを持つことが望ましいです。
では、次は何をすべきでしょうか？まず、要件を定義することをお勧めします。そこから始めてください。復旧目標を理解し、コスト、データ損失、ダウンタイムに関する組織の制約を理解していることを確認してください。そして、必要なサービス、AWS Elastic Disaster Recovery、AWS Backupについて確認してください。無料のオンライントレーニングなども用意されています。以上で、本日のお時間をいただきありがとうございました。バックアップとDRについて何か学んでいただけたことを願っています。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion