re:Invent 2024: AWSチームがBackupを活用したRansomware対策を解説
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Building resilience against ransomware using AWS Backup (STG409)
この動画では、AWS BackupによるRansomware対策について、AWS Product ManagementのシニアマネージャーPalak DesaiとWorldwide Solutions ArchitectのSabith Venkitachalapathyが解説しています。Ransomwareの脅威は検知時点ですでに200日以上潜伏している可能性があり、Mean Time to Normal (MTTN)の短縮が重要です。3-2-1-1アプローチに基づき、AWS Organizationsを活用したWorkload Account、Key Vault Account、Bunker Account、Forensic Accountの適切な構成方法や、AWS Backup Restore TestingによるバックアップデータのMalware/Ranswareスキャン、Minimum Viable Companyの考え方に基づく段階的な復旧プロセスなど、実践的なCyber Resilience戦略を詳しく説明しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS Backupセッションの概要と目的
AWS Backup「SS TJ 409: Building resilience against ransomware with AWS Backup」へようこそ。AWS Product Managementのシニアマネージャーを務めるPalak Desaiです。本日は、Sabith Venkitachalapathyも参加しています。皆様、こんにちは。Sabith Venkitachalapathyと申します。AWS Backupチームに所属するWorldwide Solutions Architectで、お客様のRecovery Resilienceの構築をグローバルにサポートしています。改めまして、よろしくお願いいたします。
まず、本セッションについてご説明させていただきます。これは400レベルのセッションですので、基本的な概念から始めて、アーキテクチャの詳細に踏み込んでいきます。Cyber Resilienceを実現するための機能の活用方法についてお話しし、その後、Sabithがデモンストレーションを行います。スライドの撮影についてですが、多くのビルドアウトが含まれているため、カメラアイコンが表示されたときが、すべてのビルドアウトが完了したタイミングとなりますので、そのタイミングで撮影していただければと思います。
Cyber Resilienceの鍵は、サイバー事象からの迅速な復旧と、その影響を最小限に抑えるための強固な計画を整備することです。環境内のMalwareやRansomwareの事象は、可能性の段階から起こりうる段階へと進展しており、そのような事態に備えて復旧できる態勢を整えておく必要があります。効果的な復旧の鍵は、事象が発生した際に効率的に対応できるよう、計画を事前に整備しておくことです。このセッションでは、Ransomware事象からビジネス運営を迅速に復旧し、ダウンタイムやデータ損失を最小限に抑え、効率的に復旧するために活用できる多くの機能についてご紹介します。
本セッションでは、サイバー脅威の状況について詳しく説明します。サイバー脅威にどのような状況があり得るのか、環境をCyber Resilientにするためにバックアップが重要な理由と役割、そしてバックアップ戦略についてお話しします。環境を保護するためには様々な方法があります。AWS Backupの紹介とそれを活用した環境保護の方法、Recovery戦略についても説明し、最後にデモンストレーションを行い、主要なポイントをまとめます。
ランサムウェア攻撃シナリオと復旧計画の重要性
それでは、あるシナリオについてご説明します。月曜の朝、メールを受信します。一見、何の問題もない正当なメールに見え、リンクが含まれています。 そのリンクをクリックすることで、Ransomwareの侵入が始まります。新しい環境であっても、Malwareがダウンロードされ、潜伏状態となります。何が起きているのか気付かないうちに、環境内で拡散が進んでいきます。時間の経過とともに、ネットワーク内やデータ内での拡散が進み、脅威レベルが増大していきます。
そしてある日、環境内で重大な暗号化事象が発生していることに気付きます。脅威が何日もかけて環境内で進行していたことが判明します。データ、クラウドストレージ、データベースのすべてが暗号化されています。バックアップは削除されているか、バックアップへのアクセスが無効化されている可能性があります。 この時点で、選択肢は2つあります。身代金を支払うか、古いバックアップからの復旧を試みるかです。どちらの選択肢も望ましいものではありません。なぜなら、ビジネスのダウンタイムが発生し、評判が損なわれ、経済的な打撃を受けることになるからです。
では、どうすればよいのでしょうか？重要なのは、復旧計画を事前に用意しておくことです。バックアップについて十分に検討し、環境内でRansomwareイベントが発生していることを素早く検知できるようにします。そして、発生している事象を隔離し、論理的に分離された環境に保管されているバックアップを使用して迅速な復旧を行い、ビジネスを再開し、事業の継続性を確保します。Ransomwareはデータだけの問題ではありません。確かにデータは失われますが、ビジネスや評判にも影響を及ぼします。このような事態が発生した際の復旧に要する時間を最小限に抑えることが重要です。このような事象をビジネスにとっての大惨事にするか、それとも軽微な障害で済ませられるかの違いは、準備の度合い、つまり、どれだけ迅速に復旧できるかにかかっています。今日のセッションでは、このことについて詳しく説明していきます。
サイバー攻撃の時間軸とMean Time to Normal (MTTN)の概念
では、タイムラインを見ていきましょう。環境内で脅威を検知したとします。調査によると、環境内でMalwareやRansomwareが検知された時点で、実際にはすでに200日以上から1年もの間、潜伏して静かに拡散していたことが分かっています。
脅威は検知の何ヶ月も前に発生しており、環境内にRansomwareが存在することに気付いた時点で、その影響範囲を迅速に把握する必要があります。 この評価には通常、数時間から1日程度かかります。
脅威が検知されると、緩和フェーズに入ります。 インシデント対応を開始し、保険会社とコミュニケーションを取り、フォレンジック分析を実施します。これには通常5日から14日かかります。その後、 復旧メカニズムを開始し、バックアップからの復旧を試みて通常の業務運営を回復させます。1〜3ヶ月以内に、アプリケーションが再度オンラインになり、ビジネスが再開され、顧客のニーズに応えられるようになります。
ここでの重要な指標は、Mean Time to Normal (MTTN)です。 これは、インシデント発生後、ビジネスが正常な状態に戻るまでにかかる時間を測定するものです。MTTNを短縮することが重要です。なぜなら、それによってデータとビジネスを侵害から効果的に保護し、評判の低下や経済的損失を防ぐことができるからです。できるだけ早期に復旧を実現するための戦略を立てることが極めて重要です。
サイバーセキュリティの現状と規制環境
現在のサイバーセキュリティの状況における傾向と脅威について見ていきましょう。大小を問わずすべての企業がRansomwareの脅威にさらされている中、脅威は持続的に進化し続けています。このような事態が発生した際には、組織の連携が不可欠です。サイバー脅威対策チーム、セキュリティチーム、バックアップチームが効果的にコミュニケーションを取る必要があります。脅威を検知した瞬間から、誰が何をすべきか、どのように迅速に復旧するかについて、明確な手順を確立しておく必要があります。
その影響は、データ損失だけにとどまりません。経済的損失、評判の低下、規制上のプレッシャーなど、多岐にわたります。脅威は increasingly sophisticatedになってきており、当初は主要データのみを標的としていたものが、現在ではバックアップシステムも標的となっています。これにより、インシデント発生時のクリーンな復旧のために、論理的に隔離されたバックアップを含む詳細なバックアップ戦略が必要となっています。規制環境も進化しており、次のスライドでそれらの規制について詳しく見ていきます。
これらの規制では、継続的なテスト、安全なバックアップ、 復旧システムの継続的なコンプライアンス、監査、モニタリングが義務付けられています。これにより、このような事態が発生した際のビジネスのダウンタイムと経済的影響を最小限に抑えることができます。ここからは、多くのお客様とともにCyber Resilienceの確保に取り組んできたSabbathが、バックアップの役割、バックアップシステムが標的となる状況、そしてシステムを保護する方法について説明します。
ありがとうございます、Pollock。サイバー脅威の状況とお客様調査の概要を確認したところで、これらのリスクを軽減するためのバックアップの役割について探っていきましょう。重要なポイントは、サイバーイベントからの復旧手段を確実に確保することです。このようなイベントが発生した際、カギとなるのはMean Time to Normalを最小限に抑え、ビジネスへの影響をできる限り軽減することです。Ransomwareから防御する際、 最も重要なのはデータのRecoverabilityです。単にバックアップを取るだけでなく、必要な時に確実に復旧できる状態にしておくことが重要です。
Recovery Resilienceのための脅威モデリングとバックアップ戦略
全体像を理解する上で最も重要なステップは、何を達成しようとしているのかを正確に特定することです。ここで、Recovery Resilienceにおいて、Threat Modelingの概念を適用したいと考えています。基本的なフレームワークを使用してThreat Modelingの概念を適用する際、まず何を構築しようとしているのかを理解することが重要です。この場合、私たちは耐障害性のあるRecovery戦略の構築を目指しています。次に、そのRecovery戦略において、何が問題になり得るのか、どのような要因から保護する必要があるのかを検討します。
3番目の質問として、脅威を特定した後は、どのような対策戦略を実施するかを理解することです。特定された各脅威に対して、複数の対策戦略があるかもしれません。対策戦略がない場合は、おそらくRiskレジスターにそのリスクを記録して認識することになります。他のプランと同様に、常に継続的な改善を求める必要があり、進化する脅威の状況に適応するためにこれらの質問を繰り返し行います。これらの要素をThreat Modelドキュメントとしてまとめることで、Recovery Resilienceの基盤を築くことができます。
重要なのは、達成しようとしていることを理解することです。なぜなら、それが明確でない場合、インフラ全体を単にバックアップするだけになってしまう可能性があるからです。その場合、これらの作業を始めた理由を理解することもなく、コストが主な懸念事項となってしまいます。Threat Modelingの取り組みを体系的に開始すると、対処すべき状況を正確に理解できるようになります。では、バックアップを保護するための戦略についてお話ししましょう。業界標準のアプローチとして3-2-1-1アプローチがあり、これは3つの異なるデータコピーについて説明するものです。
これら3つの異なるコピーは、理想的には1つの本番データと2つのバックアップコピー、あるいは本番データ自体の3つの異なるコピーを意味することもできます。これらのバックアップのうち少なくとも2つは、論理的な境界を越えて保管することが推奨されています。クラウドネイティブの環境では、アカウント境界を越えて保管することについて説明しており、プライマリバックアップデータをローカルアカウントに保管し、2つ目のバックアップコピーはAWS Organization内の別のアカウントに保管します。これらのバックアップコピーの1つは、主にリージョンの耐障害性要件に対応するため、異なるリージョンに保管することが推奨されています。
バックアップをリージョン間でコピーできないデータレジデンシー要件がある場合、これは適用されないかもしれません。しかし、予期せぬリージョン障害からの復旧要件がある場合（これは計画しておく必要があります）、最後の「1」は、2つの異なるコピーのうち少なくとも1つをImmutableなバックアップVaultに保管する必要があることを意味します。Immutableな Vaultに保管する目的は、攻撃者が本番データだけでなくバックアップも侵害しようとした場合に、Immutableな Vaultに保管されているため、それができないようにすることです。
この戦略で最も重要な点は、ここにある「ゼロ」という数字です。これは単にバックアップを取るだけでなく、そのバックアップが確実にリカバリー可能で、必要な状況で復元できる状態にあることを保証するものです。このゼロという概念は、DORA、NYDFS、HIPAA、さらにはGDPRなど、多くの規制が示唆しようとしているものであり、データが保護されているだけでなく、予期せぬ状況でも確実に復元できる状態であることを求めています。
AWS Backupの機能と論理的エアギャップVaultの活用
それでは、バックアップの保護が重要である理由をシナリオベースで理解していきましょう。これは一例であり、私たちからの推奨事項ではありません。1枚のスライドですべてを説明するために、日次バックアップを行う14日間の保持期間を想定してみましょう。最初の7日間は、すべてのバックアップがクリーンで、テスト済みで、問題ありません。この7日間に何か問題が発生した場合は、常にこれらのバックアップを使用して復旧することができます。これは安全な期間と言えます。
次に、エンドポイント検知システムの大部分が誤作動を起こし、何らかのマルウェアが本番データに侵入してしまったという状況を想定してみましょう。本番データをバックアップしているため、バックアップにもマルウェアが複製されてしまいます。これらのバックアップはマルウェアに感染していますが、完全には侵害されていない状態です。バックアップ番号8、9、10のこの期間は、バックアップスキャンソフトウェアが脆弱性の正確な場所を特定できれば、まだ安全な期間と言えます。
例えば、EBSスナップショットにvirus.AXが存在することが分かっている場合、管理された環境で安全に展開し、その特定の感染のみを除去してから復元を試みることができます。そのため、この安全な期間中は、リカバリーポイントはそれほど損なわれません。しかし、本番データで暗号化イベントが発生すると、すべてのバックアップコピーにも暗号化が含まれることになります。これはすべてのバックアップリカバリーオプションが使い果たされた状況です。11から14番のバックアップからの復元は、マルウェアを環境に再び持ち込むことになるため、望ましくありません。この場合、管理された復元を行って回復を試みるオプションすら残されていません。
ここで重要なのは、バックアップ戦略を立てる際には、バックアップの頻度、保持期間、そして最も重要なこととして、データ内のこれらの侵害の有無をどれだけの頻度でテストするかについて、非常に慎重に検討する必要があるということです。このシナリオでは、14日間の期間内に脆弱性を発見できなかった場合、最後の正常なバックアップがライフサイクル削除されてしまい、侵害されたバックアップしか残っていない状況に陥る可能性があります。そのような状態で復元を実行しても、環境の改善には役立ちません。これで脅威の状況とバックアップの重要性について理解できたので、効果的なバックアップ戦略の実装方法についてより深く掘り下げていきましょう。
バックアップ戦略について説明する前に、まず重要な概念であるData VaultやBackup Vaultについてご紹介したいと思います。Backup VaultやData Vaultは、バックアップを論理的なコンテナとしてグループ化し、単一のエンティティとして管理できるようにするものです。組織によっては、データをPlatinum、Gold、Silver、Bronzeといった形で分類する要件があるかもしれません。その場合、データ分類に基づいてData Vaultを作成し、暗号化戦略だけでなく、Vaultレベルでのデータアクセス戦略も適用することができます。例えば、Platinumデータのバックアップには特権ユーザーのみがアクセスでき、PlasticやBronzeデータには権限の低いユーザーがアクセスできるといった具合です。
これらの戦略を実装する前に理解しておくべき重要な概念が、このBackup Vaultなのです。 適切なバックアップ戦略を確立する上で最も重要なステップは、何をバックアップする必要があるかを理解することです。私たちは脅威モデリングドキュメントを作成して、復旧を妨げる可能性のある脅威を分析しましたが、次のステップは何をVaultに保存する必要があるかを理解することです。ここで、データ分類と回復可能性が重要になってきます。なぜなら、既存のデータから復元や再作成が可能なデータは、必ずしもバックアップする必要がないかもしれないからです。
例えば、Data Lakeがあり、生データを取り込むパイプラインがあって、そこから加工されたデータがある場合、加工データのバックアップは必要ないかもしれません。なぜなら、生データからコンピューティングリソースを使って再作成できると確信できるからです。ただし、これは生データから加工データを再作成するのにかかる時間にも依存します。もし組織にとって生データからの加工データの再作成が重要である場合は、加工データもバックアップすることになるでしょう。 2番目のポイントは、Vaultのパーティショニング方法を理解することです。これにより、Vaultのアクセス制御とストレージメカニズムを明確に分類できます。PlatinumデータとPlasticデータ、あるいはBronzeデータとSilverデータを混在させたくはありません。
3番目の重要な側面は、Vaultの管理アクセスと、誰がこれらのバックアップにアクセスできるかということです。バックアップはデータ流出の主要な方法ではありませんが、特定のVaultからの復元や、Vaultからのデータコピーができる人を決める適切な制御がない場合、別の攻撃経路となる可能性があります。監視の緩い環境を通じてデータの不正利用を許してしまう可能性があるのです。 これらすべての上で最も重要な側面は、どのように復旧するかということです。環境でサイバーインシデントが発生した場合、初期フェーズでは、どこから復旧するかを決定する必要があります。これを私たちはDecision Time Objectiveと呼んでいます。
このDecision Timeフェーズでは、復旧オプションを理解し、プライマリバックアップから復旧するのか、コピーされたバックアップから復旧するのかという復旧パスを決定する必要があります。復旧プロセスは、どこから復旧を試みるかによって異なります。コピーから復旧する場合、通常は本番環境にデータを戻すという追加のステップが必要になります。このように、復旧がどのように行われるかを理解することが重要です。
これらの考慮事項に加えて、ソフトウェアやサービスプロバイダーなど、関係するすべてのコンポーネントを理解することも重要です。これには、バックアップのためのManaged Service Providerや、サードパーティのバックアップ提供者を利用しているかどうかも含まれます。また、リカバリープロセスにおけるすべての役割と責任を含む、関係する人員とプロセスについても理解する必要があります。特に組織のスポンサーシップは極めて重要です - もし組織がCyber Resilienceの重要性を理解していなければ、他のすべての取り組みは根本的に欠陥があることになってしまいます。
サイバーインシデントからの効果的な復旧計画と実施
このバックアップ戦略で取り上げたいもう一つの概念は、成熟度レベルです。どのお客様も小規模から始めて、できるだけ早く進めていきたいと考えています。理想的には、RPO要件に合わせた自動スケジュールバックアップを実装する基本的なアプローチから始めます。 ここで最も重要な考慮事項は、分析による麻痺状態に陥った場合、 バックアップ戦略を何も実装しないでいると、サイバーイベントが発生した際にリカバリーオプションがない状態で、より大きなリスクにさらされることです。これこそが、私たちが避けたい状況なのです。
初期の基本的なアプローチから、バックアップの論理的な分離を実装し、バックアップを保護し、AWS Organization全体に管理構造をもたらす高度なアプローチへと、常に進化させることが可能です。 そこから、自動化されたリストアテストやバックアップのマルウェアやランサムウェアの存在をスキャンする拡張フォレンジックを実装する、最終的なAdvanced Plusの状態へと進むことができます。また、ワンクリックで自動リカバリーを実現するリストアオーケストレーションも実装できます。重要なポイントは、初日からAdvanced Plusで始める必要はなく、基本的なアプローチから始めて、AdvancedやAdvanced Plusの段階へと進んでいけるということです。
AWSには、AWS Backupというサービスがあります。これは、コンピュートからストレージ、ファイラー、データベース、さらにはVMwareやSAP HANAなどの一部のオンプレミスリソースまで、様々なAWSリソースのバックアップを簡素化する、集中管理された、ポリシーベースのメカニズムです。AWS Backupを使用すると、継続的な増分バックアップまたは連続バックアップのスケジュールを設定し、RPOを決定し、バックアップ計画を自動的に実行することができます。これは、環境内で定期的なバックアップを実装するための、完全に自動化された、ポリシー駆動型のシステムです。
サイバー機能に関して、最近、Backup Logically Air-gapped Vaultと呼ばれる機能が一般提供されるようになりました。これは、バックアップが格納されるサービス管理アカウントを通じた分離を提供し、サービス管理の暗号化を使用してマルウェアやランサムウェアがバックアップを暗号化することを防ぎます。高可用性を備え、RAM共有を使用してランサムウェアからの復旧のために新しく作成されたアカウントにバックアップを共有する機能を提供します。 これにより、バックアップが不変であり、環境内のあらゆるイベントから安全であるという安心感が得られます。よく言われるように、バックアップはリストアできてこそ価値があるのです。
ランサムウェアインシデントへの対応を考える際、いかに復旧するか、そしていかに迅速に復旧するかを考慮する必要があります。そのため、昨年私たちは AWS Backup Restore Testing をリリースしました。これにより、リソースを自動化された方法で継続的にテストすることが可能になりました。バックアッププランと同様に、リストアテストプランを作成し、復元したいリソース、復元テストの頻度、復元したリソースを維持する期間を指定することができます。指定が完了すると、バックアップリストアプランが実行され、リソースが復元されます。その後、アプリケーション指向のテストを実施する時間が確保され、アプリケーションの復旧に備えることができます。そして、自動化によってリソースは自動的に削除されます。
これは、バックアップの検証を求めるすべての規制の中で最も重要な要素です。レポーティングの側面に対応するため、AWS Backup Audit Manager をリリースしました。 バックアップの取得が第一、リストア可能性のテストが第二、そして監査とコンプライアンスが第三です。規制当局に対して、論理的にAir-gappedされたVaultにバックアップを送信し、継続的にリストアテストを実施し、最も重要なリソースをバックアップで保護していることを証明する必要があります。Backup Audit Managerでは、コンプライアンス基準を定義でき、その基準に基づいてレポートが実行され、環境内で何が起きているかを把握し、環境をサイバーレジリエントにするために必要な措置を講じていることを規制当局に証明するための包括的なレポートが生成されます。
写真は千の言葉に値し、スライドは素晴らしいものですが、リファレンスアーキテクチャについて詳しく見ていきましょう。 これまで議論してきたこれらの概念すべてをリファレンスアーキテクチャに適用する際、「リファレンス」という言葉は実際とても重要です。これはリファレンスアーキテクチャであり、先ほど説明した脅威モデリングの演習に応じて、全体的にまたは部分的に適用される可能性があります。
AWS Cloud環境において、 AWS Organizationsのセットアップでは、理想的にはバックアップ委任と委任管理者アカウントの概念から始めます。これは数年前にリリースした機能で、最小権限の原則に従い、バックアップ管理者が管理アクセス権を持たずにAWS組織の別アカウントでバックアップ管理者の活動を実行できるようにすることを目的としています。バックアップポリシーを作成できる委任管理者アカウントをプロビジョニングします。バックアップポリシーを使用すると、データ保護戦略から逆算して、バックアップしたいリソース、バックアップの頻度、保持するバックアップコピーの数を定義できます。これらのバックアップポリシーを組織に適用すると、 AWS Backupが自動的にバックアップを作成します。
このリファレンスアーキテクチャにおけるもう一つの重要な概念は、Key Vaultアカウントと呼ばれるものです。お客様の環境で見られる一般的な脅威ベクトルの1つは、Customer Managed Keys（CMK）へのアクセスを失うという概念です。CMKを使用してデータを保存時に暗号化している場合、これらのCMKが悪意を持って削除される可能性のある侵害状況が発生する可能性があります。実際の削除までに最低7日間のスケジューリング期間があっても、アラートに適時に対応しなければキーを失う可能性があります。AWS組織内でKey Vaultアカウントをプロビジョニングし、CMKをワークロードアカウント間で共有することをお勧めします。これにより、キー管理を別のアカウントの責任とすることで、多層防御の原則が適用されます。また、数千のアカウントで個別のCMKを実行すると高いコストが発生するため、コスト面でもメリットがあります。代わりに、Key Vaultアカウントでデータ分類要件に基づいてキーをプロビジョニングし、ワークロードアカウントと共有することができます。
また、先ほど説明した論理的分離の考え方に沿って、Data Bunkerアカウントという概念も導入しました。これは、元のアカウントが侵害されるリスクに対応するためのものです。
バックアップのコピーは、Defense in Depthの原則に従って確実に保護された別のBunkerアカウントに保管することを常に推奨しています。Bunkerアカウントは、ワークロードが実行されているのと同じリージョンに配置します。また、Bunkerアカウントへのアクセスには、Break Glass（緊急時対応）ワークフローを適用することを推奨しています。これは、Bunkerアカウントを運用アカウントではなく、純粋なストレージアカウントとして維持するためです。Bunkerアカウントへの運用アクセスは、AWSのベストプラクティスに基づいて文書化されたBreak Glassワークフローを通じてのみ可能となります。
次に、すべてのワークロードアカウントについて見ていきましょう。これらは本番環境のワークロードアカウントで、本番環境とデータを実行する場所です。Delegated Adminアカウントで作成されたバックアップポリシーがワークロードアカウントに適用されているため、AWS Backupが面倒な作業を代行して定期的にローカルバックアップを実行します。これがデータの1つ目のコピーとなります。 また、ローカルVaultからBunkerアカウントにバックアップをコピーするプランとルールを設定することもできます。これは段階的なアプローチで実施できます。ローカルアカウントのバックアップには、おそらく1時間単位のRPOというより厳格な要件があるかもしれませんが、Bunkerアカウントには日次バックアップのみをコピーする形にすることもできます。このようにして、コストとメリットのバランスを取ることができます。
これが3-2-1アプローチで説明した2つ目のコピーです。リージョンの冗長性要件がある場合は、同様の原則に従って別のリージョンに設定されたBunkerアカウントに3つ目のコピーを送ることができます。お客様には、RPO要件をよく理解することをお勧めしています。ワークロードアカウントにある1つ目のコピーは運用上の復旧要件に対応するもので、1時間という厳格なRPOが設定されているかもしれません。別のリージョンのBunkerアカウントにあるコピーは、リージョンの冗長性要件に対応するもので、週次コピーというようなより緩やかなRPOかもしれません。サイバーレジリエンスのために、同じリージョンのBunkerアカウントに1日というサイバーRPOでコピーを保持します。このようにして、コストとメリットをコントロールすることができます。
これだけではありません。お客様には、AWS Organizations全体で独立したForensicsアカウントを用意することをお勧めしています。これにより、バックアップの検証を独立した隔離されたアカウントで実施することができます。別個のForensicsアカウントを推奨する理由は、適切なアクセス制御メカニズムを実装できるからです。これにより、Bunkerアカウントやワークロードアカウントにあるデータを、悪意のある脅威がどのようにしてアカウントに侵入したかを調査したい脅威ハンティングチームのような別チームと直接共有する必要がなくなります。リストアテストの後に何か問題が見つかった場合、BunkerアカウントやワークロードアカウントにあるデータのコピーをForensicsチームと共有する必要がなくなります。
これはリファレンスアーキテクチャです。このアーキテクチャを完全に実装しているお客様もいれば、部分的に実装している方、ローカルコピーのみを実装している方もいらっしゃいます。結局のところ、先ほど説明した脅威モデリングの演習に帰着します。リカバリを危険にさらす脅威と、その対策を理解する必要があります。このスライドは、適用可能なすべての対策をまとめたものです。
では、AWS Backupがこのシナリオでどのような機能を提供するのか、さらに詳しく見ていきましょう。ワークロードアカウントとVaultアカウントを持ち、データのコピーがVaultアカウントに送信されるという運用面について説明しました。このVaultアカウントには、ワークロードアカウントからのバックアップコピーを受け取ることができる論理的なエアギャップVaultを想定しています。先ほど説明したForensicsアカウントと同様に、別のアカウントを用意する場合は、データ保護要件から逆算して作業するのと同じように、AWS Backup Testingを設定します。バックアッププランを使用して、どのリソースに対してどのくらいの頻度でテストを実施するかを定義するRestoreテストプランを作成できます。AWS Backup Restore TestingはAWS Backup Audit Managerと緊密に統合されているため、テストで実行するすべてのジョブをAWS Backup Audit Managerのコントロール内で適切に監査・検証することができます。
ここで、AWS BackupのResource Access Manager共有機能を使用して、Forensicsアカウントに対してプレゼンテーションを行ってみましょう。これまでは、テストを実施する前に、VaultアカウントからForensicsアカウントにデータを深くコピーする必要がありました。しかし、AWS Backup Restore Testingと論理的なエアギャップVaultがシームレスに統合されたことで、共有上でRestoreテストを実行できるようになりました。
この共有を使用する際、AWS Backup Restore Testingは一時的なリストアリソースを作成します。これにより、リソースの復元に必要な最小限のRecovery Time（RT）を把握することができます。例えば、1テラバイトのEBSボリュームの復元に1分かかる場合、それがリカバリワークフローを構築する際の最小基準となります。
通常のリストアジョブであれ、Restoreテストジョブであれ、リストアジョブが完了するたびにEventBridge通知を受け取り、カスタムLambda関数をリストアジョブの完了時に呼び出すことができます。Elastic.comのパートナーソリューションを使用すると、一時的なリソースに対してスキャンを開始できます。ここでの利点は、復元されたデータに対して2種類の検証を実行できることです。EFSボリューム、FSXボリューム、S3バケット、EBSボリュームなど、どのようなリソースであっても、マルウェアやランサムウェアのスキャンを実行することができます。Elasticによるスキャンが完了すると、EventBridgeを通じて通知が送信され、Security Hubに直接保存するか、以前に設定したRestore検証Lambda経由で通知を受けることができます。
主な利点として、AWS Backupが新しいAPIであるRestore Validation Statusを提供するようになったことが挙げられます。これにより、Recovery Pointでのリストアテストのステータスを更新することができ、それによってリソースのクリーンアップが開始されます。これにより、バックアップの系統全体を確認し、どのバックアップがリストアテストされ、そのテスト結果がどうだったかを判断することができます。そのため、サイバーインシデントが発生した際には、どのバックアップから安全にリストアできるかを把握することができます。
ここまで、脅威の状況とバックアップ戦略の重要性について説明してきました。AWS Backupを使用してリカバリー戦略を実装する方法も含めて説明しましたが、ここで簡単なシナリオを考えてみましょう。金曜の夜、仕事を終えてお気に入りの飲み物を片手にソファに座り、お気に入りの映画を見ようとしているときに、ふと見上げると屋根から水漏れしているのに気付きました。そこで頭に浮かぶのは、水漏れの影響を分析し、屋根全体への水の広がりを評価し、天井が崩落する可能性はないか、配管工を呼ぶ必要があるか、そして明日は土曜日だということなど、様々な懸念事項です。
AWS Backupを用いたCyber Resilienceの実装デモ
この状況と同じように、サイバーインシデントが発生した際にも、すべての対応計画を事前に準備しておく必要があります。屋根の水漏れであれ、サイバーインシデントであれ、実際に発生してから対応を考えるのではいけません。成功的なリカバリーを実現するためには、適切な計画を事前に立てておくことが重要です。ここまで、適切なバックアップを作成し、リカバリーの基盤を確立するための戦略について説明してきましたが、リカバリー自体には、バックアップの作成とは別の計画が必要になります。
他のプロセスと同様に、すべてはリスク評価から始まります。何に対応しようとしているのか、どのように対応するのかを理解する必要があります。データ保護とバックアップの戦略があり、ここでリカバリー戦略とバックアップ戦略を整合させる必要があります。これは、以前のスライドで触れた組織的な不整合に対処するものです。サイバーインシデントに対応するすべてのチームが、作成したバックアップから何をリカバリーするかについて、同じ認識を持っていることが前提となります。
その後、これらの戦略をインシデント対応とリカバリー手順に統合し、作成した各バックアップからどのようにリカバリーするかを正確に把握します。すべてのチーム間で常に重要な協力と調整が必要となり、明確なコミュニケーションチャネルと対応プロトコルを確立する必要があります。最も重要な側面はテストとトレーニングです。これらのプロセスが常に実戦で使えるよう、継続的に評価する必要があります。これは世界中の規制当局が求めていることであり、一部は義務付けており、また一部は推奨事項としています。
他のプランと同様に、継続的な改善を実施する必要があります。これは、戦略を継続的にレビューし、改善を図ることを意味します。先ほど説明したように、戦略を見直し、反復を通じて改善を重ねていくのです。
また、Recovery Planningには成熟度モデルという考え方があり、すべての組織がこのプロセスを経て、継続的に評価と改善を行っていきます。
ここまでプランニングの重要性について見てきましたが、次はサイバーインシデントが発生し、復旧を開始する場合について考えてみましょう。復旧は一定の出発点から始まりますが、重要なビジネスサービスをすべて一度に復旧することはできません。重要なビジネスサービスを復旧するには、多くの基盤となるコンポーネントが必要です。これには、Identity Provider、コアとなるメッセージングサービス、AWSのLanding Zoneサービスなどが含まれます - これらの基盤サービスを復旧させなければ、本番環境のワークロードをプロビジョニングすることはできません。
次の復旧レベルでは、依存サービスに移ります。 依存サービスでは、実際の重要なビジネスサービスの復旧に必要な要素を検討します。これには、プロビジョニングが必要なグローバルデータベーステーブル、メッセージングサービス、CSPMなどのサードパーティソリューションやその他のコンポーネントが含まれます。
これらの要素を復旧した後、重要なビジネスサービスの復旧に着手します。サイバーインシデントへの対応中は慎重にリソースを扱う必要があるため、初日から重要なビジネスサービスを最大容量で復旧することは稀です。ここで重要となるのがMVS（Minimum Viable Service）、つまり復旧に必要な最小限のサービスという考え方です。
重要なビジネスサービスの各フェーズでこれを実装すると、私たちが「Minimum Viable Company（最小限の実行可能な会社）」と呼ぶものの復旧が完了します。Minimum Viable Companyとは、サイバーインシデント発生後に組織が事業を再開できるようにするために必要な一連のサービスのことです。これは、バックアップが必要なものを理解するという先ほどの要点に関連しており、バックアップ戦略はMinimum Viable Companyに合わせて設計される必要があります。管理している全アプリケーションのうち、どの程度の割合がMinimum Viable Companyを構成しているのかを理解することが重要です。この理解がなければ、適切な復旧計画を立てることが非常に困難になってしまいます。
Minimum Viable Companyの復旧が完了すると、通常はフェーズ1が完了したことになります。この時点で、その他すべてのサービスの復旧を開始することになります。一般的に、組織がサイバーインシデントに対応する際は、フェーズを分けて実施することが望ましいです。ここで重要なのは、常に復旧のクリティカルパスが存在するということです。すべてのサービスを同時並行で復元することは望ましくありません。そもそもAWSには並行復元に関するソフトリミットがあり、他の環境にもそれぞれ制限があるため、そのような同時復元は不可能です。適切な復旧を確実にするために、段階的なアプローチで適切に計画を立てる必要があります。
さて、最も重要な要約に移りましょう。ただし、Packに要約を任せる前に、これまで説明してきたことのデモをお見せしたいと思います。先ほど説明した参照アーキテクチャを振り返ってみましょう。ワークロードアカウント、Vaultアカウント、フォレンシックアカウント、そしてリカバリーアカウントがありました。デモがスムーズに進むように、デモ動画を用意しました。
ここに表示されているのは、先ほど説明した委任管理者アカウントです。この委任管理者アカウントで、バックアップポリシーを設定しています。 2つの異なるバックアップルールがあります。1つはローカルバックアップで、もう1つは異なるアカウントにデータをコピーするルールです。ここでは、ワークロードアカウント用のターゲットが設定されているのが確認できます。 つまり、ワークロードアカウントを設定すると、それに対して異なるバックアップポリシーが割り当てられるということです。この簡単な例では、AWS Organizationに「workloads」というOUがあり、委任管理者アカウントで作成したこのバックアップポリシーがそれらのOUに適用されます。
これは、Key Vaultアカウントを作成している部分です。このアカウントでは複数のCMKをプロビジョニングしており、組織の各部分で個々のワークロードアカウントからのアクセス方法に応じて共有されるようにします。 KMS Key Vaultアカウントで最も重要なのは、Key Vaultアカウントからワークロードアカウントへのキーの共有方法について、適切なアクセスパターンを持つことです。ワークロードアカウントからVaultアカウントにバックアップをコピーする際、最初のステップとして、コピー先のアカウントがリカバリーポイントを復号化するためのアクセス権を必要とします。
Key Vault Accountの導入により、これらのプロセスはシンプルになりました。Workload Accountでは、バックアッププランが読み取り専用のプランとして利用可能になり、個々のアカウントでは変更できなくなっています。すべてのWorkload Accountは、ポリシーから作成された共通の最小バックアップ戦略を使用してジョブを実行します。
これらは、Vault Accountにコピーを送信するコピージョブです。これは、AWS Organization全体で共通の最小バックアップ戦略を強制できる有利なアプローチです。個々のワークロードオーナーが適切なバックアップを作成するのを待つのではなく、バックアッププポリシーを強制して共通の最小バックアップ戦略を作成します。個々のワークロードオーナーは、より積極的なバックアップ戦略のために、ローカルで追加のバックアッププランを自由に作成できますが、これらは組織の共通の最小ポリシーで確立された基準に追加されるものとなります。
データの分類に基づいて、私のGold Vaultがあることがわかります。また、リストアやコピーのアクセス権限を指定するためのリソース制御ポリシーも適用されています。Bunker Accountでは、論理的な中央Lag Vaultが作成され、Workload Accountで以前作成されたすべてのバックアップがここにコピーされているのが確認できます。ここでもアクセスポリシーが実装されています。
AWS Backupの重要なポイントとして、バックアップの送信方向を定義するデータコリドーという概念があります。送信元と送信先の両アカウントでリソースポリシーを使用することで、特定のタグを持つ個々のリカバリーポイントをWorkload AccountからVaultにコピーできる方向を正確に定義したり、逆方向を禁止したり、あるいはバックアップの流出をすべて停止したりすることができます。Lag Vaultではアカウントの共有が可能で、私たちが呼ぶForensic Accountと共有しています。共有を個別に制御し、異なるアカウントと共有することができます。RAMとの統合により、すべての読み取り専用権限を制御できます。
Lag Vault共有はすべて読み取り専用の性質を持っており、これは送信先アカウントが元のソースデータに対して破壊的な操作を実行できないことを意味します。私のBunker Accountでは、RAM共有において、送信先アカウントでこれらの権限とタグのリストがすべて利用可能であることがわかります。Forensic Accountに切り替えて、このアカウントと共有されているVaultに移動すると、中央のLag Vaultに作成され存在するこの特定のVaultが、Forensic Accountで利用可能になっていることがわかります。
以前は、Vault アカウントからフォレンジックアカウントにリカバリーポイントをコピーする必要がありましたが、現在は Vault アカウントから簡単な共有を行うだけで、フォレンジックアカウントで Central Vault の内容を確認できるようになりました。Central Lag Vault をクリックすると、Central Vault に保存されているすべてのリカバリーポイントを確認できます 。宛先アカウントには読み取り専用の権限しかないことがわかります 。属性を確認すると、このアカウントと共有されていることと、所有アカウントが表示されます。
Restore Testing コンソールに移動すると、作成した Restore Testing プランと、リソースベースの選択を定義する機会があることがわかります。私は EBS 用と S3 用のプランを作成しました。また、この特定のアカウントと共有されている Lag Vault から、 1時間ごとにリスクテストを実行するように設定しています。テスト戦略に応じて、最後のバックアップまたはランダムなバックアップのいずれかを選択することができます 。
最も重要なポイントであるリソース選択では、リソースを 数時間保持するように指定することができます。これは、AWS Backup が一時的なリソースを保持する期間です。1時間の間、一時的なリソースは削除されません。これにより、先ほど説明したパートナーソリューションを使用するような、下流の検証システムを起動してデータの整合性検証を実行する機会が得られます。このように、単なる復元テストだけでなく、データの整合性の検証も行うことができます。
1時間後、またはPut Integrity Testing APIの呼び出し後、この機能を使用して検証が実行されます。1時間後またはAPI検証ステータスが呼び出された時点のいずれか早い方で、一時的なリソースは削除されます。さまざまなパラメータを制御でき、より詳細な復元パラメータを可能にするIAMサポートもあります。すべての復元ジョブはここで確認でき、実際に完了した復元ジョブが表示されています 。実際の復元が成功したかどうかを示すステータス、検証ステータス、AWS Backup が一時的なリソースの削除に成功したかどうかを示す削除ステータスという3つの異なるステータス表示があります。
検証ステータスは特に重要です 。この特定のケースを確認すると、リカバリーポイントがマルウェア検出0件、ランサムウェア検出100件で侵害されていることを示しています。このステータスは、ここで紹介しているシステムから送り返されたものです。テストが成功したかどうかを判断する1024文字までのメッセージを更新するオプションがあります 。他のシナリオでは、異なるタイプの検証を行うことができます。この特定のリカバリーポイントでは、テストが成功したことがわかります。これは、復元テストと検証の両方を正常に完了した最後の正常なバックアップとして、あなたのラインナップで考慮されることになります。
デモでお見せしたように、リストア作業の完了ステータスによって呼び出されるLambda関数があります。このLambda関数内で、ステータスを更新するリストアの検証を呼び出すことができます。テストが完了した後に呼び出される簡単なPython関数を実装することで、下流の検証を呼び出し、このAPIを呼び出してプロセスを完了することができます。
Cyber Resilienceの重要ポイントと結論
ここで学んだ重要なコンセプトをまとめますと、Mean Time to Normalを短縮するためにリカバリーは非常に重要です。これは重要なパラメータであり、これを短縮できれば災害と軽微なトラブルの違いを生み出すことができます。検知は多くの場合、クリティカルマスに依存しており、つまり通常、マルウェアがシステム内に長期間存在した後に検知されることを意味します。バックアップ戦略を計画する際は、すべてのデータが同じ価値を持つわけではないことを覚えておいてください。効果的なバックアップとリカバリー戦略を策定するために、Minimum Viable Companyを考慮してください。これにより、インシデントが発生した際に、アプリケーションを迅速に復旧し、通常運用に戻る準備が整います。Cyber Resilienceは単なる運用上の問題ではなく、対処が必要なビジネス上および財務上の課題であることを忘れないでください。本日はご参加いただき、ありがとうございました。お帰りの前に、プレゼンテーションの改善のため、アンケートでフィードバックとサムズアップをお願いいたします。ありがとうございました。良い一日をお過ごしください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion