境界セキュリティ - AWS 規範ガイダンス
境界サービスを 1 つのネットワークアカウントにデプロイする境界サービスを個々のアプリケーションアカウントにデプロイする。境界セキュリティ設定用の追加の AWS サービス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

境界セキュリティ

セキュリティ AWS リファレンスアーキテクチャ (AWS SRA) の未来に影響を与えるために、簡単なアンケートに回答してください。

このセクションでは、AWS SRAガイダンスを拡張して、AWS で安全な境界を構築するための推奨事項を提供します。AWS 境界サービスと、Word OUs で定義される AWSSRA への適合方法について詳しく説明します。

このガイダンスでは、perimeter (境界) はアプリケーションがインターネットに接続する境界として定義されています。境界のセキュリティには、安全なコンテンツ配信、アプリケーションレイヤーの保護、分散型サービス拒否 (DDoS) の緩和が含まれます。AWS境界サービスには、Amazon CloudFront、AWSWAF、AWS Shield、Amazon Route 53、AWS Global Accelerator が含まれます。これらのサービスは、AWS リソースとコンテンツ配信への安全で低レイテンシー、高性能なアクセスを提供するように設計されています。これらの境界サービスは、Amazon GuardDuty や AWS Firewall Manager などの他のセキュリティサービスで使用して、アプリケーションの安全な境界を構築できます。

境界セキュリティには複数のアーキテクチャパターンがあり、組織のさまざまなニーズに対応できます。このセクションでは、中央の (ネットワーク) アカウントに境界サービスを展開するパターンと、一部の境界サービスを個々のワークロード (アプリケーション) アカウントに展開する 2 つの一般的なパターンに焦点を当てます。このセクションでは、両方のアーキテクチャの利点と主な考慮事項について説明します。

境界サービスを 1 つのネットワークアカウントにデプロイする

次の図は、境界サービスがネットワークアカウントにデプロイされるアーキテクチャを説明するために、ベースラインの AWS SRA。

境界サービスをネットワークアカウントにデプロイする

境界サービスを 1 つのネットワークアカウントに展開することには、いくつかの利点があります。

  • このパターンは、規制の厳しい業界など、組織全体の境界サービスの管理を単一の専門チームに制限したい場合に役立ちます。

  • これにより、ネットワークコンポーネントの作成、変更、削除を制限するために必要な設定が簡単になります。

  • 検査が 1 か所で行われるため、ログの集約ポイントが少なくなるため、検出が簡単になります。

  • CloudFront ポリシーやエッジ関数などのカスタムベストプラクティスリソースを作成し、同じアカウントのディストリビューション間で共有できます。

  • コンテンツ配信ネットワーク (CDN) キャッシュ設定や DNS レコードなどの設定エラーの影響を受けやすいビジネスクリティカルなリソースの管理を簡素化し、変更が実装される場所を減らします。

以下のセクションでは、各サービスについて詳しく説明し、アーキテクチャ上の考慮事項について説明します。

Amazon CloudFront

Amazon CloudFront は、高いパフォーマンス、セキュリティ、開発者の利便性を実現するために構築されたコンテンツ配信ネットワーク (CDN) サービスです。インターネット向けパブリック HTTP エンドポイントでは、 CloudFront を使用してインターネット向けコンテンツを配信することをお勧めします。 CloudFront はリバースプロキシであり、アプリケーションの単一のエントリポイントとして機能します。また、AWS WAF や Lambda@Edge や CloudFront 関数などのエッジ関数と組み合わせて、コンテンツ配信のための安全でカスタマイズ可能なソリューションを作成することもできます。

このデプロイアーキテクチャでは、エッジ関数を含むすべての CloudFront 設定がネットワークアカウントにデプロイされ、一元化されたネットワークチームによって管理されます。ネットワークチームの権限を持つ従業員のみがこのアカウントにアクセスできるようにする必要があります。 CloudFront の設定または Word のウェブアクセスコントロールリスト (ウェブ ACLAWSWAF) を変更したいアプリケーションチームは、ネットワークチームにそれらの変更をリクエストする必要があります。アプリケーションチームが設定変更をリクエストするためのチケットシステムなどのワークフローを確立することをお勧めします。

このパターンでは、動的オリジンと静的オリジンの両方が個々のアプリケーションアカウントにあるため、これらのオリジンにアクセスするには、クロスアカウント権限とクロスアカウントロールが必要です。 CloudFront ディストリビューションからのログは、ログアーカイブアカウントに送信するように設定されています。

AWS WAF

AWS WAF、保護されたウェブアプリケーションリソースに転送される HTTP および HTTPS リクエストをモニタリングできるウェブアプリケーションファイアウォールです。このサービスは、一般的なウェブエクスプロイトや大量の脅威だけでなく、アカウント作成詐欺、ユーザーアカウントへの不正アクセス、検出を回避しようとするボットなどのより高度な脅威からもリソースを保護するのに役立ちます。AWS WAF は、 CloudFront ディストリビューション、Amazon API Gateway REST APIs、Application Load Balancer、 AppSync AWSGraphQL GraphQLAPIs、Amazon Cognito ユーザープール、AWS App Runner サービス、AWS Verified Access インスタンスのリソースタイプを保護するのに役立ちます。

このデプロイアーキテクチャでは、AWS WAF はネットワークアカウントで設定された CloudFront ディストリビューションにアタッチされます。AWS withWAF を設定すると CloudFront、境界フットプリントはアプリケーション CloudFront ではなく VPC エッジロケーションに拡張されます。これにより、悪意のあるトラフィックのフィルタリングがトラフィックのソースに近づき、悪意のあるトラフィックがコアネットワークに侵入するのを防ぐことができます。

ウェブACLsはネットワークアカウントにデプロイされますが、AWS Firewall Manager を使用してウェブACLsを一元管理し、すべてのリソースが準拠していることを確認することをお勧めします。セキュリティツールアカウントを Firewall Manager の管理者アカウントとして設定します。自動修復を使用して Firewall Manager ポリシーをデプロイし、アカウント内のすべての (または選択した) CloudFront ディストリビューションにウェブ ACL がアタッチされるようにします。

S3 バケットへのクロスアカウントアクセスを設定することで、ログアーカイブアカウントの S3 バケットに完全な AWS WAF ログを送信できます。詳細については、このトピックのAWS re:Post」記事を参照してください。

AWS Shield と AWS Route 53 のヘルスチェック

AWS Shield Standard と AWS Shield Advanced は、ネットワークレイヤーとトランスポートレイヤー (レイヤー 3 と 4) およびアプリケーションレイヤー (レイヤー 7) の DDoS リソースに対する分散型サービス拒否 (AWS) 攻撃に対する保護を提供します。Shield Standard は、AWS WAF およびその他の AWS サービスに対して既に支払っている料金を超える追加コストなしで自動的に含まれます。Shield Advanced は、Amazon DDoS インスタンス、Elastic Load Balancing ロードバランサー、 CloudFront ディストリビューション、および Route 53 ホストゾーンに対して拡張された EC2 イベント保護を提供します。可視性の高いウェブサイトを所有している場合、またはアプリケーションが頻繁に DDoS イベントを起こしやすい場合は、Shield Advanced が提供する追加機能を検討してください。

Shield スタンダードはユーザーが設定できないため、このセクションではShield の詳細設定に焦点を当てます。

CloudFront ディストリビューションを保護するように Shield Advanced を設定するには、ネットワークアカウントを Shield Advanced にサブスクライブします。アカウントで、Shield Response Team (SRT) サポートを追加し、SRT DDoSイベント中に Word チームがウェブ ACLs にアクセスするために必要なアクセス許可を付与します。アクティブな SRT イベント中に、いつでも DDoS に連絡して、アプリケーションのカスタム緩和策を作成および管理できます。アクセスを事前に設定しておくとSRT、イベント中にアクセス許可を管理することなく、ウェブACLsを柔軟にデバッグおよび修正できます。

自動修復で Firewall Manager を使用して、 CloudFront ディストリビューションを保護されたリソースとして追加します。アプリケーションロードバランサーなど、インターネットに接続する他のリソースがある場合は、それらを Shield Advanced の保護対象リソースとして追加することを検討してください。ただし、データフローに複数の Shield Advanced で保護されたリソースがある場合 (例えば、Application Load Balancer が CloudFront のオリジンである場合）、Shield Advanced の重複データ転送 (DTO) 料金を削減するために、保護されたリソースとしてエントリポイントのみを使用することをお勧めします。

プロアクティブエンゲージメント機能を有効にして、SRT が保護されたリソースをプロアクティブにモニタリングし、必要に応じて連絡できるようにします。プロアクティブエンゲージメント機能を効果的に設定するには、アプリケーションの Route 53 ヘルスチェックを作成し、 CloudFront ディストリビューションに関連付けます。Shield Advanced は、イベントを評価する際の追加のデータポイントとしてヘルスチェックを使用します。検出による誤検出を減らすには、Health チェックを適切に定義する必要があります。ヘルスチェックの正しいメトリクスを特定する方法の詳細については、AWS ドキュメントの「Shield Advanced でヘルスチェックを使用するためのベストプラクティス」を参照してください。DDoS の試行を検出した場合は、SRT に連絡して、サポートプランで使用可能な最も高い重要度を選択できます。

AWS Certificate Manager と AWS Route 53

AWS Certificate Manager (ACM） は、パブリックおよびプライベートの SSL/TLS X.509 証明書のプロビジョニング、管理、更新に役立ちます。ACM を使用して証明書を管理する場合、証明書のプライベートキーは、強力な暗号化とキー管理のベストプラクティスを使用して安全に保護され、保存されます。

ACM ディストリビューションのパブリック TLS 証明書を生成するために、 CloudFront がネットワークアカウントにデプロイされます。ビューワーと TLS 間の HTTPS 接続を確立するには、 CloudFront 証明書が必要です。詳細については、CloudFront ドキュメントを参照してください。ACM は、ドメインの所有権を検証するための DNS または E メールの検証を提供します。Route 53 を使用してパブリック DNS レコードを管理することで、ACM から直接レコードを更新できるため、E メール検証の代わりに DNS 検証を使用することをお勧めします。ACM は、証明書が使用中で DNS レコードが配置されている限り、DNS 検証済み証明書を自動的に更新します。

CloudFront アクセスログと AWS WAF ログ

デフォルトでは、 CloudFront アクセスログはネットワークアカウントに保存され、AWS WAF ログは Firewall Manager ログ記録オプションを使用して Security Tooling アカウントに集約されます。これらのログは Log Archive アカウントに複製して、一元化されたセキュリティチームがモニタリング目的でアクセスできるようにすることをお勧めします。

設計上の考慮事項

  • このアーキテクチャでは、1 つのネットワークチームに多数の依存関係があると、変更を迅速に行うことができなくなる可能性があります。

  • 各アカウントのサービスクォータを監視してください。サービスクォータは、制限とも呼ばれ、AWS アカウントのサービスリソースまたはオペレーションの最大数です。詳細については、AWS ドキュメントの「Word Service Quotas」を参照してください。 AWS

  • ワークロードチームに特定のメトリクスを提供すると、複雑になる場合があります。

  • アプリケーションチームは設定へのアクセスを制限しているため、ネットワークチームが代わりに変更を実装するのを待つことでオーバーヘッドが発生する可能性があります。

  • 1 つのアカウントでリソースを共有するチームは、同じリソースと予算をめぐって競合する可能性があり、リソースの割り当てが難しくなる可能性があります。Networking アカウントにデプロイされた境界サービスを使用するアプリケーションチームからチャージバックする仕組みを導入することをお勧めします。

境界サービスを個々のアプリケーションアカウントにデプロイする。

次の図は、境界サービスを個々のアプリケーションアカウントに個別に展開および管理するアーキテクチャパターンを示しています。

境界サービスを個々のアプリケーションアカウントに展開する。

境界サービスをアプリケーションアカウントに展開することには、いくつかの利点があります。

  • この設計により、個々のワークロードアカウントがニーズに基づいてサービス構成を自主的にカスタマイズできるようになります。このアプローチにより、共有アカウント内のリソースへの変更を実施する専門チームへの依存がなくなり、各チームの開発者が構成を個別に管理できるようになります。

  • 各アカウントには独自のサービスクォータがあるため、アプリケーション所有者は共有アカウントのクォータの範囲内で作業する必要はありません。

  • この設計は、悪意のあるアクティビティを特定のアカウントに限定し、攻撃が他のワークロードに広がるのを防ぐことで、その影響を抑えるのに役立ちます。

  • 影響の範囲は問題のワークロードのみに限定されるため、変更のリスクが排除されます。IAM を使用して変更を実装できるチームを制限することもできます。そのため、ワークロードチームと中央ネットワークチームは論理的に分離されます。

  • ネットワークの入出力の実装を分散させながら、共通の論理制御 (AWS Firewall Manager などのサービスを使用) を行うことで、制御目標の最小基準を満たしながら、特定のワークロードに合わせてネットワーク制御を調整できます。

以下のセクションでは、各サービスについて詳しく説明し、アーキテクチャ上の考慮事項について説明します。

Amazon CloudFront

このデプロイアーキテクチャでは、エッジ関数を含む Amazon CloudFront 設定が管理され、個々のアプリケーションアカウントにデプロイされます。これにより、各アプリケーション所有者とワークロードアカウントには、アプリケーションのニーズに基づいて境界サービスを設定する自律性があることが確認されます。

動的オリジンと静的オリジンは同じアプリケーションアカウントにあり、 CloudFront ディストリビューションはこれらのオリジンにアカウントレベルでアクセスできます。 CloudFront ディストリビューションからのログは、各アプリケーションアカウントにローカルに保存されます。ログは Log Archive アカウントに複製できるため、コンプライアンスや規制上のニーズに対応できます。

AWS WAF

このデプロイアーキテクチャでは、AWS WAF はアプリケーションアカウントで設定された CloudFront ディストリビューションにアタッチされます。前のパターンと同様に、AWS Firewall Manager を使用してウェブ ACLs を一元管理し、すべてのリソースが準拠していることを確認することをお勧めします。AWS マネージドコアWAFルールセットや Amazon IP 評価リストなどの一般的な AWS ルールをデフォルトとして追加する必要があります。これらのルールは、アプリケーションアカウント内の適格なリソースに自動的に適用されます。

Firewall Manager によって適用されるルールに加えて、各アプリケーション所有者は、アプリケーションセキュリティに関連する WAF AWS ルールをウェブ ACL に追加できます。これにより、Security Tooling アカウントの全体的な制御を維持したまま、各アプリケーションアカウントに柔軟に対応できます。

Firewall Manager のログオプションを使用して、ログを一元化し、Security Tooling アカウントの S3 バケットに送信します。各アプリケーションチームには、アプリケーションの AWS WAF ダッシュボードを確認するアクセス権が付与されます。Amazon QuickSight などのサービスを使用してダッシュボードを設定できます。誤検出が特定された場合、または AWS WAF ルールのその他の更新が必要な場合は、Firewall Manager によってデプロイされるウェブ WAF にアプリケーションレベルの AWS ACLを追加できます。ログは Log Archive アカウントに複製され、セキュリティ調査のためにアーカイブされます。

AWS Global Accelerator

AWS Global Accelerator を使用すると、ローカルユーザーとグローバルユーザー向けのアプリケーションのパフォーマンスを向上させるアクセラレーターを作成できます。Global Accelerator は、1 つ以上の AWS リージョンでホストされているアプリケーションへの固定エントリポイントとして機能する静的 IP アドレスを提供します。これらのアドレスは、Application Load Balancer、Network Load Balancer、AWS インスタンス、Elastic IP アドレスなどのリージョンの EC2 リソースまたはエンドポイントに関連付けることができます。これにより、トラフィックは可能な限りユーザーに近い AWS グローバルネットワークに進入できるようになります。

グローバルアクセラレータは現在、クロスアカウントオリジンをサポートしていません。そのため、オリジンエンドポイントと同じアカウントにデプロイされます。各アプリケーションアカウントにアクセラレーターをデプロイし、同じアカウントに AWS Shield Advanced の保護対象リソースとして追加します。Shield 緩和は、有効なトラフィックがグローバルアクセラレータの標準アクセラレータのリスナーエンドポイントに到達することのみを許可します。

AWS Shield Advanced と AWS Route 53 のヘルスチェック

AWS ディストリビューションを保護するように Word Shield Advanced を設定するには、各アプリケーションアカウントを Shield Advanced にサブスクライブする必要があります。 CloudFront Shield Response Team (SRT) へのアクセスやプロアクティブエンゲージメントなどの機能は、リソースと同じアカウントで設定する必要があるため、アカウントレベルで設定する必要があります。自動修復で Firewall Manager を使用して、 CloudFront ディストリビューションを保護されたリソースとして追加し、ポリシーを各アカウントに適用します。各 CloudFront ディストリビューションの Route 53 ヘルスチェックは、同じアカウントにデプロイし、リソースに関連付ける必要があります。

Amazon Route 53 ゾーンと ACM

Amazon CloudFront などのサービスを使用する場合、アプリケーションアカウントは、カスタムサブドメインを作成し、Amazon Certificate Manager (ACM） またはサードパーティーの証明書によって発行された証明書を適用するために、ルートドメインをホストするアカウントにアクセスする必要があります。Amazon Route 53 ゾーン委任を使用して、中央の共有サービスアカウントから個々のアプリケーションアカウントにパブリックドメインを委任できます。ゾーン委任を使用すると、各アカウントは API や静的サブドメインなどのアプリケーション固有のサブドメインを作成および管理できます。各アカウントの ACM を使用すると、各アプリケーションアカウントは、必要に応じて証明書の審査と検証プロセス (組織検証、拡張検証、またはドメイン検証) を管理できます。

CloudFront アクセスログ、Global Accelerator フローログ、AWS WAF ログ

このパターンでは、個々のアプリケーションアカウントの S3 バケットに CloudFront アクセスログと Global Accelerator フローログを設定します。パフォーマンスチューニングや誤検出を減らすためにログを分析したい開発者は、中央のログアーカイブへのアクセスをリクエストしなくても、これらのログに直接アクセスできます。ローカルに保存されたログは、データレジデンシーや PII 難読化などのリージョンのコンプライアンス要件もサポートできます。

完全な AWSWAF ログは、Firewall Manager のログ記録を使用して、ログアーカイブアカウントの S3 バケットに保存されます。アプリケーションチームは、Amazon QuickSight などのサービスを使用して設定されたダッシュボードを使用してログを表示できます。さらに、各アプリケーションチームは、クイックデバッグのために、自分のアカウントからサンプリングされた AWS WAF ログにアクセスできます。

Log Archive アカウントにある一元化されたデータレイクにログを複製することをお勧めします。ログを一元化されたデータレイクに集約すると、AWS WAF リソースとディストリビューションへのすべてのトラフィックを包括的に表示できます。これにより、セキュリティチームはグローバルなセキュリティ脅威パターンを一元的に分析して対応することができます。

設計上の考慮事項

  • このパターンでは、ネットワークとセキュリティの管理責任がアカウントオーナーと開発者に移り、開発プロセスのオーバーヘッドが増える可能性があります。

  • 意思決定に矛盾が生じる可能性があります。効果的なコミュニケーション、テンプレート、トレーニングを確立して、サービスが正しく構成され、セキュリティの推奨事項に従っていることを確認する必要があります。

  • 基本となるセキュリティ統制とアプリケーション固有の統制を組み合わせることには、自動化が重要であり、明確な期待が寄せられています。

  • Firewall Manager や AWS Config などのサービスを使用して、デプロイされたアーキテクチャがセキュリティのベストプラクティスに準拠していることを確認します。さらに、 CloudTrail AWS モニタリングを設定して、設定ミスを検出します。

  • ログとメトリクスを一元的に集約して分析すると、複雑になる場合があります。

境界セキュリティ設定用の追加の AWS サービス

ダイナミックオリジン: Application Load Balancer

動的コンテンツ配信に Application Load Balancer オリジンを使用するように Amazon CloudFront を設定できます。この設定により、リクエストパス、ホスト名、クエリ文字列パラメータなどのさまざまな要素に基づいて、リクエストを異なる Application Load Balancer オリジンにルーティングできます。

Application Load Balancer のオリジンはアプリケーションアカウントにデプロイされます。 CloudFront ディストリビューションがネットワークアカウントにある場合は、Application Load Balancer オリジンにアクセスするためのクロスアカウントアクセス許可を CloudFront ディストリビューションに設定する必要があります。Application Load Balancer からのログは、ログアーカイブアカウントに送信されます。

ユーザーが CloudFront を経由せずに Application Load Balancer に直接アクセスできないようにするには、以下の大まかなステップを実行します。

  • Application Load Balancer に送信するリクエストにカスタム HTTP ヘッダーを追加するように CloudFront を設定し、カスタム HTTP ヘッダーを含むリクエストのみを転送するように Application Load Balancer を設定します。

  • Application Load Balancer セキュリティグループの AWS 用の CloudFront マネージドプレフィックスリストを使用します。これにより、Application Load Balancer へのインバウンド HTTP/HTTPS トラフィックが、 CloudFront のオリジン向けサーバーに属する IP アドレスのみに制限されます。

詳細については、 CloudFront ドキュメントの「Application Load Balancer へのアクセスの制限」を参照してください。

静的オリジン: Amazon S3 および AWS Elemental MediaStore

静的コンテンツ配信に Amazon S3 または AWS Elemental MediaStore オリジンを使用する CloudFront ように Word を設定できます。これらのオリジンはアプリケーションアカウントにデプロイされます。 CloudFront ディストリビューションがネットワークアカウントにある場合、オリジンにアクセスするには、ネットワークアカウントの CloudFront ディストリビューションにクロスアカウントアクセス許可を設定する必要があります。

静的オリジンエンドポイントがパブリックインターネット経由で直接アクセスするのではなく、 CloudFront 経由でのみアクセスされることを確認するには、オリジンアクセスコントロール (OAC) 設定を使用できます。アクセスの制限の詳細については、Word CloudFrontドキュメントのAmazon S3オリジンへのアクセスの制限」および「a MediaStore オリジンへのアクセスの制限」を参照してください。

AWS Firewall Manager

AWS Firewall Manager は、AWS WAF、AWS Shield Advanced、Amazon VPC セキュリティグループ、AWS Network Firewall、Amazon Route 53 Resolver DNS Firewall など、複数のアカウントとリソースにわたる管理およびメンテナンスタスクを簡素化し、さまざまな保護を行います。

Security Tooling アカウントを Firewall Manager のデフォルトの管理者アカウントとして委任し、それを使用して組織アカウント全体で AWSWAF ルールと Shield Advanced 保護を一元管理します。Firewall Manager を使用して一般的な AWS ルールを一元管理し、各アプリケーションチームがウェブ WAF にアプリケーション固有のルールを柔軟に追加できるようにしますACL。これにより、アプリケーションチームがアプリケーションに固有の AWS WAFルールを追加できるようにしながら、一般的な脆弱性に対する保護など、組織全体のセキュリティポリシーを適用できます。

Firewall Manager のログ記録を使用して、AWS WAFログを Security Tooling アカウントの S3 バケットに一元化し、ログをログアーカイブアカウントにレプリケートして、セキュリティ調査のためにアーカイブできるようにします。さらに、Firewall Manager を AWS Security Hub と統合して、Security Hub で設定の詳細と DDoS 通知を一元的に視覚化します。

その他の推奨事項については、このガイドの Security Tooling アカウントセクションのAWS Firewall Manager」を参照してください。

AWS Security Hub

Firewall Manager とSecurity Hub 統合により、次の 4 種類の検出結果がSecurity Hub に送信されます。

  • AWS WAF ルールで適切に保護されていないリソース

  • AWS Shield Advanced で適切に保護されていないリソース

  • DDoS 攻撃が進行中であることを示す Shield Advanced の検出結果

  • 不適切に使用されているセキュリティグループ

すべての組織メンバーアカウントからのこれらの検出結果は、Security Hub 委任管理者 (Security Tooling) アカウントに集約されます。Security Hub を使用すると、セキュリティアラート (検出結果) を集計、整理、優先順位付けする 1 つの場所があります。Amazon CloudWatch Events ルールを使用して、結果をチケット発行システムに送信したり、悪意のある IP 範囲のブロックなどの自動修復を作成したりできます。

その他の推奨事項については、このガイドの Security Tooling アカウントセクションのAWS Security Hub」を参照してください。

Amazon GuardDuty

Amazon GuardDuty が提供する脅威インテリジェンスを使用して、 GuardDuty の検出結果に応じてウェブ ACLs を自動的に更新できます。例えば、 GuardDuty が疑わしいアクティビティを検出すると、追加の調査と修復を実行している間、オートメーションを使用して AWS WAF IP セットのエントリを更新し、影響を受けるリソースに AWS WAF ウェブACLsを適用して、疑わしいホストからの通信をブロックできます。Security Tooling アカウントは、 GuardDuty の委任管理者アカウントです。したがって、クロスアカウントアクセス許可を持つ AWS Lambda 関数を使用して、アプリケーションアカウントの AWSWAF IP セットを更新する必要があります。

その他の推奨事項については、このガイドの Security Tooling アカウントセクションの「Amazon GuardDuty」を参照してください。

AWS設定

AWS Config は Firewall Manager の前提条件であり、ネットワークアカウントとアプリケーションアカウントを含む AWS アカウントにデプロイされます。さらに、AWS Config ルールを使用して、デプロイされたリソースがセキュリティのベストプラクティスに準拠していることを確認します。例えば、AWS Config ルールを使用して、すべての CloudFront ディストリビューションがウェブ ACL に関連付けられているかどうかをチェックしたり、すべての CloudFront ディストリビューションを S3 バケットにアクセスログを配信するように設定したりできます。

一般的な推奨事項については、このガイドの Security Tooling アカウントセクションのAWS Config」を参照してください。