Amazon Web Services ブログ

AWS Backup マルチパーティ承認を使用して信頼性を高める方法

本ブログは、2025 年 7 月 1 日に公開された Improve recovery resilience with AWS Backup support for Multi-party approval を翻訳したものです。

組織は、進化するサイバー脅威からバックアップを保護する必要があります。包括的なバックアップと復旧戦略には、分離を確保した上で改ざんを防ぐ不変性、バックアップの信頼性を確保するための整合性検証、そして必要な時に使用できる可用性、3 つの基本的な柱が大切です。これらの柱は、効率的なデータ保護の基盤を形成します。分離を伴う不変性により、バックアップは変更されず消去不可能で、本番インフラストラクチャから分離され元の状態を維持します。整合性検証は、バックアップが破損しておらず復元可能であることを確認します。利用可能性は、復元が必要になった時にバックアップを確実に利用できることが保障され、重要な状況でのビジネス継続性を確保します。これらの要素が組み合わさることで、組織で最も価値があるといえるデータを多様な脅威から守る堅牢なセキュリティフレームワークが完成します。

AWS Backup は、堅牢なデータレジリエンス戦略の基盤を提供します。複数の アベイラビリティーゾーン (AZ) にわたってバックアップを保存することで、99.999999999% (イレブンナイン) の耐久性 を提供します。AWS Backup Vault Lock は、バックアップの改ざんを禁止することで不変性を確保します。AWS Backup 復元テスト は、バックアップの整合性を検証し、パートナーソリューションと統合してフォレンジック分析機能を拡張します。AWS Backup は、バックアップ対象となる基盤の AWS サービスと少なくとも同等レベルの回復力と耐久性を維持し、データ保護戦略の強固な基盤を提供します。

しかし、重大なセキュリティインシデント中にバックアップへのアクセスを確保するには、これらのネイティブ機能を超えた追加の制御が必要です。バックアップシステムが本番環境と認証境界を共有している場合、単一の認証情報が侵害されると両方の環境に影響を与える可能性があります。これにより、脅威アクターは本番データを暗号化し、復旧メカニズムへのアクセスをブロックして、バックアップと復旧戦略全体を損なう可能性があります。

このブログは 2 部構成になります。パート 1 となる本ブログでは、より堅牢なアプローチが必要となる背景を探り、新しくリリースされた マルチパーティ承認と AWS Backup Logically air-gapped vault の統合を紹介し、AWS 環境での設定手順を説明します。パート 2 では、ベストプラクティスと実用的な例を含む、AWS 環境でのマルチパーティ承認ワークフローの設定に関する実装ガイダンスを提供します。

従来の復旧アーキテクチャにおける連鎖障害のリスク

既存のバックアップと復旧戦略には、重要な考慮事項があります。それは、保護対象である本番環境と同じ認証境界を共有することが一般的だということです。データへのアクセスは適切に実装されたアイデンティティ戦略によって管理され、本番システムとバックアップシステム間で明確に分離された、より堅牢な復旧機能を実現するべきです。しかし、この重要な分離はしばしば見過ごされています。バックアップがソースアカウントの認証情報と密結合している場合、ソースアカウントの侵害がバックアップにまで波及する可能性があります。これは AWS Organizations において潜在的な脅威となります。クロスアカウントアクセスと共有認証依存関係が、セキュリティインシデントの影響範囲を拡大する可能性があるためです。

本番アカウントで昇格された権限を取得した脅威アクターを考えてみましょう。彼らは本番データを暗号化し、復旧メカニズムへのアクセスをブロックする可能性があります。この課題は、組織が拡大するにつれてさらに重要になります。単一の認証情報の侵害が、複数のアカウントとワークロードにわたってビジネス継続性に影響を与える可能性があるからです。本番アカウントと同じ信頼境界内にバックアップを維持する従来のアプローチは、脅威が悪用できる単一障害点を作り出し、最後の防御線であるべきものを脆弱なターゲットに変えてしまいます。

AWS セキュリティフレームワーク: データ保護の構成要素

スケーラブルなセキュリティの基盤として機能する AWS Organizations は、企業は組織全体にわたって多層防御コントロールをデプロイおよび管理でき、相乗効果のあるセキュリティ体制を構築できます。Service Control Policies (SCP) は、アカウント全体で権限を制限するガードレールとして機能し、Resource Control Policies (RCP) は特定のリソースに対する大まかな制御を提供します。AWS Identity and Access Management (IAM) アクセス許可境界は、IAM プリンシパルのアクセス許可を制約し、最小権限の原則に沿って、当初意図されたものを超えないようにします。AWS Key Management Service (AWS KMS) は、カスタマー管理キーを使用した暗号化によりデータを保護でき、クロスアカウントコピーにより、バックアップの物理的分離を確保して復旧力を向上させます。しかし、これらのコントロールは強力である一方、従来の単一承認フレームワーク内で動作しており、内部攻撃や認証情報の侵害により、これらの保護を回避される可能性があります。

AWS Backup の Logically air-gapped vault

この課題に対処するため、AWS Backup は AWS Backup Logically air-gapped vault のマルチパーティ承認 をサポートし、運用の俊敏性を損なうことなくセキュリティを強化します。次のシナリオを考えてみてください。AWS Backup Vault Lock によって保護された不変のバックアップを作成し、AWS Backup Logically air-gapped vault で サービス所有鍵による暗号化 を通じて分離したとします。ランサムウェアインシデントの際に、脅威アクターがバックアップアカウントまたは組織の管理アカウントへのルートアクセスを取得したとします。バックアップは安全に保存されたままですが、アカウントへのアクセスを回復するために AWS Support に連絡する必要があります。

マルチパーティ承認は、図 1 に示すように、バックアップへの独立したアクセスパスを作成する仕組みです。この仕組みでは、重要な操作を実行する際に複数の承認者による合意が必要となり、一人の判断だけでは変更できないようになっています。これにより、一方的な変更や不正な操作を防ぐことができます。このネイティブな AWS 機能を使用することで、信頼できる個人で構成された承認チームを、AWS Backup Logically air-gapped vault に関連付けることができます。悪意のある行為により AWS アカウントにアクセスできなくなった場合、これらの承認チームは、現在の AWS Organizations 外のアカウントも含めて、1 つまたは複数の復旧アカウントからのボールト共有リクエストを承認できます。これにより、復旧に必要なバックアップへのアクセスを得るための手続きが不要になり、目標復旧時間 (RTO) が改善されます。

approval workflow for Multi-party approval

図 1: マルチパーティ承認ワークフロー

ユースケースとデプロイパターン

マルチパーティ承認と AWS Backup Logically air-gapped vault の統合により、データ保護のための堅牢なフレームワークが構築できます。Sheltered Harbor などに準拠する組織では、バックアップが不変性を維持し、本番インフラストラクチャからの分離を提供し、整合性検証を可能にすることが求められます。AWS Backup Logically air-gapped vault は、3 つの主要な機能を通じてこれらの基本要件に対応します。コンプライアンスモードによるロックを使用してバックアップの不変性を維持し、Logically air-gapped vault を通じて本番インフラストラクチャからの分離を提供し、AWS Backup 復元テストとの統合を通じてバックアップデータの検証を可能にします。このアーキテクチャは、元のインフラストラクチャから完全に分離されたバックアップを維持する必要がある金融機関やその他の規制対象企業にとって特に価値があります。

以下のセクションでは、組織がさまざまなシナリオでこの機能を戦略的に実装する方法について説明します。特に、2 つの重要なユースケースについて詳しく説明します。

  • AWS アカウント復旧: AWS Backup Logically air-gapped vault をホストする単一の AWS アカウントにアクセスできなくなった場合に、マルチパーティ承認がどのように復旧を可能にし、重要なセキュリティインシデント中でもビジネス継続性を確保するかを説明します。
  • AWS Organizations 復旧: Organizations 全体が侵害される複雑なシナリオを検証し、マルチパーティ承認が復旧のライフラインをどのように提供するかを説明します。

AWS アカウントの復旧

AWS Backup Logically air-gapped vault をホストしている AWS アカウントが、セキュリティインシデントや認証情報の侵害により完全にアクセス不可能になるシナリオを考えてみましょう。従来の復旧方法では AWS Support への連絡が必要となり、ビジネスの中断が長期化します。しかし、マルチパーティ承認を使用すると、次の図に示すように、事前定義された復旧戦略を実装できます。

このプロセスは、一元管理されたマルチパーティ承認チームの事前設定から始まります :

  1. 組織内の信頼できる個人で構成されるマルチパーティ承認チームを作成します。
  2. 作成した承認チームを共有します。
  3. 関連する AWS Backup Logically air-gapped vault とマルチパーティ承認チームを関連付けます。

アクセシビリティの侵害が発生した場合 :

  1. AWS Resource Access Manager (RAM) を使用し、承認チームを 1 つ、もしくは複数の復旧アカウントに共有します。
  2. 復旧チームが、1 つまたは複数の復旧アカウントから Vault 共有リクエストを送信します。
  3. マルチパーティ承認がトリガーされ、Logically air-gapped vault へのアクセス要求が保留中であることを承認者に通知します。
  4. 指定されたマルチパーティ承認チーム内のメンバーがリクエストに応答し、共有を承認します。
  5. チームから必要な数の承認を受け取ると、Logically air-gapped vault が復旧アカウントでアクセス可能になります。
  6. これで侵害された所有アカウントとは独立して、Logically air-gapped vault 内のバックアップを使用してリカバリ操作を実行できるようになりました。

この仕組みにより、単独の個人がバックアップデータに一方的にアクセスすることを防ぎ、堅牢なセキュリティ制御を維持しながらビジネス継続性を確保できます。プロセス全体で AWS のネイティブなインターフェースを使用することで、侵害されたアカウントの認証システムへの依存を排除し、RTO を大幅に短縮します。

sample workflow for cross-account implementation of multi-party approval

図 2: AWS クロスアカウント マルチパーティ承認ワークフロー

このアーキテクチャを実装することで、侵害された可能性のあるインフラストラクチャから独立して動作する、信頼できる復旧パスを作成できます。これにより、最も重要なセキュリティインシデントに対しても、回復力のあるソリューションを提供します。

AWS Organizations の復旧

前のシナリオでは個別アカウントの侵害に対処しましたが、Organization 全体にアクセスできなくなる状況にも備える必要があります。これは、大規模な侵害、重大な設定ミス、管理アカウントの侵害、または悪意のある内部関係者によって発生する可能性があります。このような場合、復旧プロセスにはさらに堅牢で独立した信頼モデルが必要になります。

このプロセスは、中央管理されたマルチパーティ承認チームの事前設定から始まります。これは図 3 にも示されています :

  1. プライマリインフラストラクチャとは別の復旧用 Organization を作成します。
  2. この Organization 用に独立したアイデンティティプロバイダー (IdP) を設定し、マルチパーティ承認と関連付けます。
  3. この独立した IdP を使用して、組織内の信頼できる個人で構成されるマルチパーティ承認チームを作成します。
  4. AWS RAM を使用して、このマルチパーティ承認チームを AWS Backup Logically air-gapped vault を使用するアカウントと共有します。
  5. 関連する AWS Backup Logically air-gapped vault に マルチパーティ承認チームを関連付けます。

アクセシビリティの侵害が発生した場合 :

  1. AWS RAM を使用して、承認チームを 1 つまたは複数の復旧アカウントと共有します。
  2. 指定された復旧チームのメンバーが、1 つまたは複数の復旧アカウントから Vault 共有リクエストを開始します。
  3. マルチパーティ承認ワークフローがトリガーされ、Logically air-gapped vault へのアクセス要求が保留中であることをチームメンバーに通知します。
  4. 指定されたマルチパーティ承認チーム内の承認者が承認リクエストに応答し、共有を承認します。
  5. 承認チームから必要な数の承認を受け取ると、Logically air-gapped vault が復旧アカウントでアクセス可能になります。
  6. 侵害された所有アカウントに依存することなく、Logically air-gapped vault のバックアップを使用して復旧操作を進めることができるようになりました。

standard cross-Organization workflow for Multi-party approval and AWS Backup

図 3: Organization を横断したマルチパーティ承認ワークフロー

このアーキテクチャは、Organization 全体がアクセス不能になった場合でも、重要なバックアップデータへのアクセスを維持する復旧パスを作成します。最小権限の原則と独立したアイデンティティ制御を組み合わせることで、最も厳格なコンプライアンス、規制、セキュリティ復旧シナリオに対して最高レベルの回復力を提供できます。

ハイレベル参照アーキテクチャ

AWS Backup のリファレンスアーキテクチャには、次の図に示すように、複数の保護と検証レイヤーが含まれます。プライマリワークロードアカウントでは、本番システムがローカルの AWS Backup ボールトにバックアップされます。そこから、これらのバックアップのコピーが同じアカウント内の AWS Backup Logically air-gapped vault に送信され、さらなる分離レイヤーを提供します。データの整合性を確保するため、この Logically air-gapped vault は AWS RAM を通じて専用のフォレンジックアカウントと共有されます。フォレンジックアカウントでは、AWS Backup 復元テストがサードパーティソリューションと併せて実施され、バックアップデータの整合性と復旧可能性が検証されます。この継続的な検証プロセスにより、バックアップが破損せず信頼性を保つことが保証されます。

復旧シナリオでは、2 つのパスが利用できます。まず、AWS RAM を通じたデフォルトの共有により、フォレンジックアカウントの認証されたユーザーが、通常の状況下または迅速なデータ損失復旧のためにバックアップにアクセスして検証できます。次に、プライマリアカウントまたは Organization 全体にアクセスできなくなった状況では、マルチパーティ承認によりバックアップに安全にアクセスできます。この 2 つのアプローチにより、日常的な運用の柔軟性と堅牢な危機復旧メカニズムの両方が提供され、潜在的なセキュリティインシデントの規模に関係なく、重要なデータへの利用可能性と整合性が確保されます。

full multi-Organization architecture for AWS Backup, including Multi-party approval

図 4: AWS Backup のリファレンスアーキテクチャ

まとめ

効果的な復旧戦略には、3 つの重要な柱が必要です。分離を確保し改ざんを防ぐ不変性、信頼性を確保する整合性検証、そして可用性です。AWS Backup は、不変性と分離のための vault lock を備えた Logically air-gapped vault、整合性検証のための AWS Backup 復元テスト、そして重要なセキュリティインシデント中でもバックアップへの信頼性の高いアクセスを確保するマルチパーティ承認を通じて、これらを提供します。マルチパーティ承認は、単一アカウントのインシデントから組織全体のイベントまで、バックアップアクセスを可能にすることで復旧戦略を変革します。最小限の必要な承認ベースの決定フローと独立した ID インフラストラクチャにより、従来の認証方法が失敗した場合でも復旧パスを利用可能にします。

今すぐ復旧計画にマルチパーティ承認を使用することを検討し、あらゆるシナリオにおいて組織が重バックアップデータへのアクセスを維持できるようにしてください。職務の明確な分離と独立したアイデンティティメカニズムを備えたこれらの復旧パターンを実装することで、あらゆるサイバーインシデントから復旧する組織の能力が強化されます。常に覚えておいてください。復旧戦略は必要な時に実行できるかが鍵となります。