AWS におけるサイバーレジリエンスと事業継続のためのプロアクティブな戦略

本ブログは 2025 年 7 月 11 日に公開された AWS Blog “Proactive strategies for cyber resilience and business continuity on AWS” を翻訳したものです。

Amazon Web Services (AWS) は、サイバーセキュリティインシデントや、技術的な障害、自然災害といった事業継続を脅かすイベントに備えて、ワークロードを復旧できるよう準備しておくことを組織に推奨しています。この記事では、公共部門の組織が AWS インフラストラクチャを使用して、クラウド上でレジリエントなシステムを運用するためのガイダンスと戦略を紹介します。AWS がお客様に推奨している内容は次のとおりです。

• サイバーセキュリティと AWS アーキテクチャのベストプラクティスに関するフレームワークを使用する
• マルチアカウント環境を実装する
• AWS 環境とワークロードのデプロイに Infrastructure as Code (IaC) を使用する
• プライマリワークロードとは異なるアベイラビリティーゾーンまたはリージョンに復旧用アカウントを準備する
• すべてのアプリケーションコード、IaC コード、設定ファイル、その他の依存関係を復旧用アカウントに配置する
• 復旧用アカウントにデータをバックアップする戦略を定義する
• 復旧用アカウントで、ユニットテストとワークロード全体のテストを自動化する

確立されたフレームワークを使用する

ランサムウェアなどのサイバーセキュリティインシデントが増加し続ける中、公共部門の組織は、サイバーセキュリティリスクをより適切に管理するためのガイダンスとして、NIST Cybersecurity Framework (CSF) 2.0 などのフレームワークを参考にしています。このフレームワークは米国国立標準技術研究所 (NIST) が策定したものです。CSF はサイバーセキュリティの成果を機能 (統治、識別、防御、検知、対応、復旧) ごとに整理していますが、NIST はその成果を達成する具体的な方法までは規定していません。

より具体的なガイダンスについては、「AWS Blueprint for Ransomware Defense」などのリソースを参照してください。このリソースでは、具体的な AWS サービスを CSF の各機能にマッピングしています。AWS でのアーキテクチャ設計のベストプラクティスを深く理解するには、AWS Well-Architected フレームワークが役立ちます。このフレームワークは 6 つの柱に沿ってベストプラクティスを詳しく解説しており、クラウドアーキテクトが AWS 責任共有モデルに従って、さまざまなアプリケーションやワークロード向けに、安全で高性能、レジリエントかつ効率的なインフラストラクチャを構築できるよう支援します。さらに、これらのフレームワークを補完するのが AWS Security Reference Architecture (AWS SRA) です。AWS SRA は、AWS の推奨プラクティスに沿って AWS のセキュリティサービスを設計、実装、管理するのに役立ちます。この記事では、CSF と AWS Well-Architected を橋渡しする形で、サイバーセキュリティイベントや災害からの復旧に備えるための重要なパターンを紹介します。

AWS でマルチアカウント戦略を実装する

AWS では、ベストプラクティスとして、マルチアカウント戦略に基づいてクラウド環境を構築することを推奨しています。このようにマルチアカウント戦略に基づいて構築した環境はランディングゾーンとも呼ばれます。AWS Organizations を AWS Control Tower または Landing Zone Accelerator on AWS と組み合わせて使用すると、管理と自動化が容易な環境を構築できます。複数の AWS アカウントを使用すると、アプリケーションとデータを分離して管理しやすくなり、環境内での意図しない横方向の移動 (ラテラルムーブメント) を排除できます。

マルチアカウント戦略の一環として、AWS は AWS IAM Identity Center を使用してアイデンティティを一元管理することを推奨しています。AWS 外部の ID プロバイダーを IAM Identity Center と統合することも可能です。ただし、復旧時にはルート認証情報を使用しなければならない場合があります。AWS では、AWS アカウントへのルートアクセスは必要な場合にのみ使用することを推奨しています。アカウントの乗っ取りや不正アクセスを防ぐために、ルート認証情報は適切に保護する必要があります。AWS は 2024 年 11 月に、ブログ記事「AWS Organizations を使用するお客様のためのルートアクセスの一元管理」で、ルート認証情報を一元管理するための新機能を発表しました。ルート認証情報を一元管理することで、長期間有効なルート認証情報を削除し、認証情報が意図せず、または不正にリカバリされることを防止できるため、AWS 環境全体のセキュリティポスチャを強化できます。

自動化によって AWS インフラストラクチャを構築する

AWS は、DevSecOps の重要な原則として、すべての AWS インフラストラクチャを IaC でデプロイすることを推奨しています。IaC を使用すると、インフラストラクチャを迅速に反復改善できるほか、一貫性と再現性の向上、設定ミスの削減、バージョン管理も実現できます。復旧の観点で特に重要なのは、IaC がインフラストラクチャのドキュメントとしても機能することです。IaC は、事業継続を脅かすイベントからの復旧と、それに備えたテストを迅速化します。これにより、新しい AWS アカウントや AWS リージョンにインフラストラクチャをすばやくデプロイできます。

AWS のサービスは IaC を前提に設計されており、組織のニーズに合わせてさまざまな IaC ツールから選択できます。AWS は、AWS CloudFormation や AWS Cloud Development Kit (AWS CDK) などの選択肢を提供しています。AWS CloudFormation ではテンプレートを使用してインフラストラクチャを定義でき、AWS CDK では使い慣れたプログラミング言語でクラウドリソースを定義できます。また、AWS CloudFormation では既存のインフラストラクチャからスタックを作成することもできるため、IaC への移行が容易になります。アプリケーションレベルでは、AWS サーバーレスアプリケーションモデル (AWS SAM) を利用できます。AWS SAM は、IaC を使用してサーバーレスアプリケーションを構築するためのオープンソースフレームワークです。AWS は HashiCorp Terraform もサポートしています。HashiCorp Terraform は、複数のクラウドサービスプロバイダーにまたがるリソースとオンプレミスのリソースの両方を、人間が読める形式の設定ファイルで定義できる IaC ツールです。この設定ファイルは、バージョン管理、再利用、共有が可能です。

どのツールを使用する場合でも、IaC はリソース名、AWS リージョン、IP 範囲などを変数化して開発できるため、AWS アカウントやリージョンをまたいでコードを簡単に再利用でき、復旧プロセスを迅速化できます。IaC コードは、GitLab などのソースコードリポジトリに保存してください。より迅速に復旧できるよう、独自の DevSecOps パイプラインを構築することも、AWS 規範ガイダンスに従って標準化することもできます。DevOps Pipeline Accelerator (DPA) は、前述のツールを使用して、アプリケーションやインフラストラクチャをデプロイするための継続的インテグレーションと継続的デリバリー (CI/CD) パイプライン全体の構築に役立つテンプレート群で構成されたソリューションです。IaC の詳細については、Infrastructure as Code のホワイトペーパーを参照してください。

復旧先を準備する

アイデンティティの侵害などのサイバーセキュリティインシデントに備えて、AWS は前述のマルチアカウント戦略を活用し、復旧用のアカウントを個別に用意することを推奨しています。AWS アカウント内のアイデンティティはロールに基づいて管理すべきですが、悪意のある攻撃者がルートアクセスを取得しているか、自身の権限を昇格させることができる場合は、同じアカウント内のバックアップも侵害される可能性があるためです。

技術的な障害や自然災害への対策として、可能性は低いものの、AWS アベイラビリティーゾーンが利用できなくなるシナリオからワークロードを保護できます。リージョン内でアベイラビリティーゾーン単位の復旧を行う場合は、復旧用のアベイラビリティーゾーンが、ワークロードのデプロイ先とは別のゾーンであることを確認してください。そのためには、アカウント間で一貫したアベイラビリティーゾーン ID (AZ ID) を使用します。AWS は、アカウントごとに AZ の名前をランダムに割り当てます。別のアカウントのアベイラビリティーゾーンを復旧に効果的に使用するには、リージョン内のすべてのアカウントで一貫した AZ ID を使用してください。この方法により、同じリージョン内の 2 つ以上のアベイラビリティーゾーンにワークロードを分散デプロイしてレジリエンスを確保しつつ、復旧用には別のアベイラビリティーゾーンを使用できます。一貫した AZ ID を使用すれば、復旧用のアベイラビリティーゾーンを、すべてのワークロードのデプロイ先とは確実に異なるゾーンにできます。

訳注: 2025 年 11 月以降に作成されたアカウントでは、従来はアカウントごとに AZ 名の対応がランダムだったリージョンでも、すべてのアカウントで同じ AZ 名が同じ AZ を指します。それより前に作成されたアカウントでは、従来どおり AZ 名がアカウントごとに個別に対応付けられているため、アカウント間で AZ を揃えるには引き続き AZ ID を使用します。参照: AZ IDs – AWS Regions and Availability Zones

次の図は、AZ ID を使用したワークロードアカウントと復旧用アカウントのアーキテクチャを示しています。

図 1. アベイラビリティーゾーン ID を使用したワークロードアカウントと復旧用アカウントの例

より広範囲に及ぶ技術的な障害や自然災害に対するレジリエンスを確保するには、マルチリージョンでの復旧を選択することもできます。AWS は、可能であれば、復旧用アカウントに別のリージョンを使用することを検討するよう推奨しています。例えば、米国東部 (バージニア北部) リージョン (us-east-1) をメインに、米国東部 (オハイオ) リージョン (us-east-2) をバックアップ先にする構成です。少なくとも、データは別のリージョンにバックアップすることを AWS は推奨しています。クロスリージョンのバックアップ先を使用する場合、別のアカウントでバックアップデータを復号できるよう、AWS Key Management Service (AWS KMS) を使用した暗号化キーの戦略を検討する必要があります。

なお、リージョン間のデータ転送料金はアベイラビリティーゾーン間よりも高くなる可能性があります。この点も、バックアップ先の戦略全体を検討する際に考慮してください。

バックアップ戦略を定義し、自動テストを実装する

AWS は、クラウドベースのソリューションに合わせてバックアップ戦略を策定することを推奨しています。前述のとおり復旧先を準備したら、AWS Backup を使用してワークロードデータを復旧用アカウントにバックアップできます。AWS Backup は、IaC、インフラストラクチャの設定データ、アプリケーションコード、アプリケーションの設定を復旧先に保存する用途にも使用できます。ほとんどのシナリオでは、ワークロードの復元にこれらすべての種類のデータが必要になります。クラウドベースのコードリポジトリを使用している場合は、十分なバックアップ機能がそのソリューションに既に備わっている可能性があります。

バックアップしたデータが実際に使用できるかを検証するために、AWS は復旧用アカウントで自動テストを実装することを推奨しています。例えば、バックアップの完了後に実行され、バックアップを正しく読み取れることを確認する自動プロセスを実装すると、ランサムウェアなどの脅威に対する効果的な緩和策になります。こうした攻撃への対策をさらに強化するために、バックアップしたすべてのコンポーネントについて複数のバージョンを保持し、必要に応じて古いバージョンのバックアップを復元できるようにしておくこともできます。また、バックアップ戦略の一環として、AWS Backup Vault Lock などの機能を使用したイミュータブルなバックアップの採用を検討するのもよいでしょう。

バックアップと IaC の戦略の一環として、ワークロードに必要なコンポーネントが復旧先に保存されていることを確認してください。対象には、IaC コード、インフラストラクチャの設定データ、Amazon マシンイメージ (AMI)、アプリケーションコード、アプリケーションの設定が含まれます。このプロセスは、DevSecOps と IaC の戦略全体に組み込む必要があります。DevSecOps パイプラインで変更が行われたときに、これらすべてのコンポーネントのバックアップをトリガーする自動プロセスを実装すれば、復旧用アカウントのバックアップを常に最新の状態に保つことができます。パイプラインの変更が頻繁に発生するシステムでは、毎日など定期的に実行される自動バックアッププロセスを選択することもできます。

復旧用アカウントの準備、IaC の実装、バックアップ戦略の確立が完了したら、復旧用アカウントでワークロード全体をテストすることを AWS は推奨しています。復旧用アカウント内の IaC コードとバックアップを使用して、そのアカウントでワークロード全体を定期的に構築してください。多くの場合、既存のコンポーネントテスト、統合テスト、ユーザー受け入れテストのスクリプトを、定期的な事業継続訓練に活用できます。このようなテストによって復旧機能の有効性を検証でき、事業継続を脅かすイベントが発生した場合にワークロードを復旧できることを確認できます。

まとめ

この記事で紹介したベストプラクティスに従うことで、公共部門の組織は AWS の機能を活用して、事業継続を脅かすイベントからの復旧に備えることができます。さらに詳しいガイダンスについては、AWS アカウントチームとソリューションアーキテクトにお問い合わせください。

本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。