レジリエンス by デザイン: 効果的なランサムウェアからの復旧戦略の策定

このブログは 2025 年 9 月 2 日に Tom Tasker と Danny Johnston によって執筆された内容を日本語化したものです。原文はこちらを参照してください。

ランサムウェア攻撃は現代組織において取締役会レベルで優先課題となっています。データは次の明確な傾向を示しています: ランサムウェアのパンデミック発生以降、攻撃件数は 2 倍以上に増加し、特に金融サービス業界は標的となってきました。AWSでは、グローバルな金融サービスのお客様、規制当局、統制機関、業界パートナーとの分野横断的な連携により、Cloud Hosted Data Vault (CHDV、略称ボールト) の認定アーキテクチャを確立しました。

大規模サイバー攻撃発生時の業務継続性強化において、ボールトは重要な検討事項です。ボールトは組織の最も重要な資産を隔離した最終防衛ラインとして機能し、従来の高可用性 (HA)、事業継続 (BC)、災害復旧 (DR)、バックアップによる復旧ができない場合においても、事業の再構築を可能にします。既存の運用レジリエンス対策にボールトを組み込むには、多角的で綿密な計画が必要です。本記事では、その計画上の考慮事項と、既存の HA、BC/DR、バックアップソリューションにさらに保護レイヤーを追加する方法を解説します。技術導入だけでなく、ボールトを機能させるための人的要素、プロセス、実践的要素に関する重要な検討事項にも焦点を当てます。

1. 何をボールトに組み込む必要があるか？

どんな事業部門の責任者も、全て、あらゆるものを組み込む必要がある、と言うでしょう。しかし、全てボールトに含める必要があるわけではなく、少なくとも即座には必要ないです。大規模なサイバーインシデントを考える際、全てのデータ、アプリケーション、サービスを重要かつボールトに保管必須とラベル付けしたくなる誘惑に駆られます。必要でなければ本番環境に存在しないはずだ、と考えるかもしれません。しかし、初期の精査なしに全てを保護しようとすると、膨大なデータ量、コスト、意図しない復旧遅延を招く可能性があります。

真のサイバーインシデント発生時には、事業再開に不可欠な中核的な IT 機能と運用サービスを、12 時間後、24 時間後、48 時間後に再開すべきか自問する必要があります。同様に重要なのは、不要なものは何かを見極めることです。これらは「最小限の事業継続機能 (Minimum Viable Business: MVB)」とも呼ばれ、お客様だけでなく二次、三次、四次関係者にも提供される中核的な機能とサービスです。

Figure 1: 何をボールトに組み込む必要があるか？ – 主要な IT 機能と運用サービスに焦点を当てる。

この問いは一夜にして答えが出るものではありません。ボールトは単なる技術的なソリューションではなく、多くの分野からの意見が関わります。MVB を特定し、それを最善の方法で保護するには、IT、セキュリティ、法務、事業部門責任者、アプリケーション責任者、経営幹部など、複数のチームからの意見、経験、知識が必要です。

2. 復旧とはどのような状態を指すのか？

サイバー攻撃は、標準的な運用復旧メカニズム (HA、BC、DR、バックアップ) を通じてシステムやサービスをオンラインに戻すことを困難、あるいは不可能にするよう設計されています。悪意のある攻撃者が身代金を確保するためには、復旧可能性を最小限にした上で最大限の混乱を引き起こすことです。大規模なサイバー攻撃に対しては、通常の運用復旧方法のみに依存することはできず、事前に検討すべき重要な考慮事項がいくつか存在します:

• 決定時間目標 (DTO): ボールトから復旧するまでにどれだけの時間がかかるか、定義する目標です。セキュアで信頼できる環境における高度に自動化された復旧プロセスが侵害を受け、その結果、信頼性に不確実性が生じたり、破壊的な行為により完全に使用不能な事態が発生したとします。ボールトから完全または部分的にいつまでに復旧することが必要か、関係者と主要な意思決定ポイントを調整することが極めて重要です。
• サイバー復旧時間目標 (C-RTO) とサイバー復旧時点目標 (C-RPO): サイバーイベントの影響拡大と復旧時間を考慮して、復旧時間の期待値を調整します。従来数秒で済んだ復旧が数日かかる可能性があり、企業はサイバーインシデントに対応する方法を把握する必要があります。
• 最低限許容可能なサービス提供 (MASO): MVB が事業活動に焦点を当てる一方、MASO は顧客や第三者に対して提供すべき許容可能なサービス水準を問うものです。これは主要サービスの機能制限版、あるいは代替手段でアクセスするバックアップシステムとなる可能性があります。

Figure 2: 復旧とはどのような状態を指すのか？ – 通常数秒で完了する処理が数日かかる場合があるため、事前に計画を立てる。

3. ボールトをどのように分割するか？

単一のボールトに全てを統合するか、サービスごとにボールトを設けるかに関わらず、管理性、実用性、セキュリティのバランスを取ることが鍵となります。

• 簡素性: ボールトは理解、操作、復元が可能な限り明確になるように保ちます。複雑さは遅延を生みます。
• 独立性: 各ボールトは単独で機能し、待機時間を最小化し並列処理を促進します。
• サービスマッピング: 復元の開始点はどこか、最適な復元順序は何か把握します。
• 役割と責任: 責任者と管理者はサービス、アプリケーション、インフラストラクチャごとに割り当てられます。
• 保守: アプリケーションの更新やビジネスユースケースの変化に伴い、ボールトも変化します。

Figure 3: ボールトをどのように分割するか？ – 管理性、内容、復旧プロセスのバランスをとる。

AWS が提供する柔軟性は、技術的負債を残すことなく、テスト、失敗、改善を繰り返しながら最適解を見つけることを可能にする点で非常に価値があります。ホワイトボード上でうまく機能したものが、最初の机上演習で失敗することもあり、そこから得た教訓は次のボールトでの試行に反映できます。ビジネスに適応する柔軟性を持つことで、ソリューションと復旧プロセスへの信頼性が向上します。ボールトに格納されるものは単なる「データ」の問題ではないです。—アプリケーションの責任者や事業部門からの意見が必要です。

4. ボールトをどのように管理するか？

ボールトは運用環境から切り離す必要があります。これにより、本番環境を横方向に移動するサイバー攻撃はぼーるとの入口で遮断されます。このレベルの分離がなければ、サイバー攻撃時にボールトも侵害される可能性があります。従来のエアギャップ方式では、メディアの抜去や物理的分離により、保護機構と運用環境の間に文字通りの空気の隙間 (エアギャップ) を設けていました。この隔離をクラウド環境とボールトにどう適用すべきでしょうか？クラウド上で同様のセキュリティ対策を実現するには以下の要件が必要です:

• イングレスゾーン: アクセス可能な時間帯にのみ利用可能な一時的な領域、サービス、機能。
• 多要素認証: 許可された担当者だけがアクセス可能な物理トークン。
• ゼロトラスト: あらゆる段階での認証。
• AWS Identity and Access Management (IAM): 制限された役割と責任。
• 変更管理: トークンとアカウントへの承認済みアクセスを処理するプロセス。

Figure 4: ボールトをどのように管理するか？ – 可視性を維持しつつ意図的に隔離する。

5. 物流とサービスプロバイダーについてはどのように計画するか？

サイバーインシデントへの対応策を検討する際、物理的な解決策は見過ごされがちです。中核となるサービス、アプリケーション、基盤インフラに焦点を当てることで、それらを復旧させる方法を考える際に周辺的な物理的依存関係が焦点から外れてしまいます。例えば:

• 内部および外部ネットワークへのアクセス: 災害が発生しなくてもサービス中断を引き起こす接続障害だけで十分ニュースになります。
• ソフトウェアリポジトリ: 自動化されたソフトウェアデプロイとは、デジタル依存関係なしに取得できる、引き出しに置かれた USB スティックなどの物理メディアを意味します。
• サプライチェーン: 物理機器が機能不全に陥った場合、必要な場所に大量のハードウェアを調達する計画とプロセスはありますか？
• 物理的な物流:: 大規模なイベントに対して大規模な対応が必要な場合、人員、設備、作業スペースをどう確保しますか？

Figure 5: 物流とサービスプロバイダー – 計画を外部依存関係まで拡大する。

サイバー攻撃の高度な手法では、個々の障害が通常の業務運営において想定され、かつ、影響も最小限であるような障害を複数強制的に発生させます。これらの障害が大規模に発生すると、複合的な影響をもたらし、複雑性と復旧の遅れを増大させる可能性があります。

6. ボールトに関するプロセスは誰が責任を持つのか？

責任者は、ボールトに関するプロセスと管理を持ち、ベストプラクティスを提供し、復旧が必要な際には最前線に立つことになります。どのチームがボールトを責任を持つか決定することは極めて重要で、必ずしも単純な作業ではありません。ボールトの基本原則は、保護・計画・プロセスという多面的な要素をカバーするという事実に基づいており、これらには単一チームではなく、複数の部門からの意見が必要となります。

復旧の優先順位付けは、依存関係、コンプライアンス要件、ビジネスへの影響に関する理解に基づき、バックアップチームではなくビジネスステークホルダーが主導すべきです。効果的なサイバー復旧計画には、技術チームとビジネスチーム間の明確なコミュニケーションが不可欠です。

Figure 6: 人とプロセス – この2つの要素のバランスを取ることが優れた実践を推進する。

この部門横断的な協力の結果として、企業が採用し遵守しなければならない復旧計画が策定されます。しかし、バッドプラクティスにつながる可能性のある硬直的なアプローチにより、サイバーイベント復旧シナリオの質が意図せず低下する可能性があります。過度に負担の大きいプロセス、俊敏性の欠如、そして最も当たり障りのない方法を選ぶという傾向により、最良の計画が実装されない可能性があります。これはセキュリティと復旧手順には即座に影響しません。しかしながら、ボールトの原則が適用されていないことに気付く最悪のタイミングは、それらが必要な時です。サイバーイベントからの効果的な復旧を確実にするためには、組織は日常業務にベストプラクティスをシームレスに統合する必要があります。この統合には、堅牢な復旧要件と、チームがセキュリティや効率性を損なうことなく一貫して従うことができる実用的で持続可能なプロセスとの間の絶妙なバランスを取ることが必要です。

7. なぜスポンサーが必要なのか？

組織に追加業務を導入することで、コストと苦労は確実に増大し、他の事業開発から時間とリソースを奪うことになります。時間、資金、人的リソースを消費する技術ソリューションが収益をなぜ生み出さないのか、と最高財務責任者 (CFO) なら疑問に思います。企業は、ボールトと積極的に中核業務に組み込もうとしないでしょう。したがって、その本質的価値と活用事例を理解することが極めて重要です。経営陣レベルのリーダーシップによる「トップダウン」アプローチによってのみ達成可能です。

Figure 7: スポンサーシップ – トップダウンアプローチにより、事業全体を導く。

AWS で始めましょう

AWS はランサムウェア攻撃に対する多重防御層を提供します。複数の AWS データサービスにわたる即時データ保護のため、AWS Backup は不正な改ざんの防止だけでなく迅速な復旧オプションも可能なイミュータブルバックアップと論理的なエアギャップを備えた集中管理型バックアップ管理を提供します。バージョニングとObject Lock を備えた Amazon S3、および Amazon FSx for NetApp ONTAP は、重要データのための改ざん防止ストレージ機能を提供します。

検知においては、Amazon GuardDuty が不審な活動を監視し、AWS Security Hub が包括的なセキュリティ状況を可視化します。Amazon Macie は標的となる可能性のある機密データを特定し、AWS Shield と AWS WAF は初期の攻撃になりうる DDoS 攻撃や Web エクスプロイトから保護します。AWS Network Firewall はネットワークレベルで悪意のあるトラフィックをフィルタリングします。elastio などのパートナーは AWS Backup と連携し、組織がほぼリアルタイムでデータの整合性を検証できるようにします。これにより、ダウンタイムとデータ損失を最小限に抑えながら、あらゆる事象から完全な復旧を実現します。

アイデンティティ保護のため、AWS IAM で最小権限アクセスを実装し、AWS Organizations でアカウント横断的なセキュリティポリシー管理を実現します。AWS Config と AWS CloudTrail は構成変更と API アクティビティの可視性を提供するため、インシデント後のフォレンジック分析に不可欠です。

まとめ

サイバー攻撃、特にランサムウェア攻撃は年々増加しています。偶発的なインシデントから標的型攻撃に対する防御への移行は、企業と経営陣が迅速に対応転換する必要があることを意味しています。これは、深刻ではあるものの現実的に起こりうる事象が、サービスを麻痺させるだけでなく、事業を永久に閉鎖させるリスク範囲を小さくするためです。増加するサイバー攻撃への技術的ソリューションは対策の一環ではありますが、全てではありません。標的型攻撃への対応策を計画することは、日常業務で慣れ親しんだ固定観念を取り除く一環でもあります。サイバーイベントは日常業務ではないため、重要な決定をその場しのぎで行うことがないように、適切な準備と計画が必要です。効果的なサイバーレジリエンスには、組織全体にわたる包括的なアプローチが不可欠です。まず自社の業務運営において「復旧成功」の定義を明確にし、詳細な計画を通じて最悪のシナリオを想定した準備を進めます。これらの計画は定期的に見直し、復旧プロセスや手順が実際に機能することを確認するため、徹底的なテストと検証を実施してください。最も重要なのは、サイバーレジリエンスが IT 部門の枠をはるかに超える課題である点です。これは本質的に全社的な取り組みを必要とするビジネス上の課題です。運用部門や財務部門から経営陣、現場スタッフに至るまで、あらゆるチームがレジリエンス構築とインシデント発生時の復旧において重要な役割を担います。成功は「CEO からシステム管理者まで」組織全体でサイバーレジリエンスを共有責任とすることにかかっています。