**の新しいコンソールエクスペリエンスの紹介 AWS WAF**
更新されたエクスペリエンスを使用して、コンソールの任意の場所で AWS WAF 機能にアクセスできるようになりました。詳細については、[「コンソールの使用](https://docs.aws.amazon.com/waf/latest/developerguide/working-with-console.html)」を参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS Shield
Distributed Denial of Service (DDoS) 攻撃から保護することは、インターネットに直接接続するアプリケーションにとって極めて重要です。でアプリケーションを構築する場合 AWS、 AWS が提供する保護を追加料金なしで使用できます。さらに、 AWS Shield Advanced マネージド脅威保護サービスを使用して、DDoS 検出、緩和、対応機能を追加してセキュリティ体制を改善できます。
AWS は、インターネット上の不正行為者に対する防御において高可用性、セキュリティ、回復性を確保するためのツール、ベストプラクティス、およびサービスを提供することに全力を注いでいます。このガイドは、IT 関連事項の意思決定者やセキュリティエンジニアが、Shield と Shield Advanced を使用して DDoS 攻撃や他の外部の脅威からアプリケーションをより適切に保護する方法を理解できるように提供されています。
でアプリケーションを構築すると AWS、UDP リフレクション攻撃や TCP SYN フラッドなどの一般的なボリューメトリック DDoS 攻撃ベクトル AWS に対して、 によって自動的に保護されます。これらの保護を活用して、DDoS 回復性のためにアーキテクチャを設計および設定 AWS することで、 で実行するアプリケーションの可用性を確保できます。
このガイドでは、DDoS レジリエンシーを実現するためのアプリケーションアーキテクチャの設計、作成、および設定に役立つ推奨事項について説明します。このガイドで提供されるベストプラクティスに準拠するアプリケーションは、大規模な DDoS 攻撃や広範囲の DDoS 攻撃ベクトルによってターゲットとされた場合に、改善された可用性の維持の恩恵を受けることができます。さらに、このガイドでは、Shield Advanced を使用して、重要なアプリケーション向けに最適化された DDoS 保護体制を実装する方法について説明します。これには、顧客に一定レベルの可用性が保証されているアプリケーションや、DDoS イベント AWS 中に からの運用サポートを必要とするアプリケーションが含まれます。
セキュリティは、 AWS とお客様の間の責任共有です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)では、これをクラウドのセキュリティおよびクラウド内のセキュリティとして説明しています。
+ **クラウドのセキュリティ** – AWS は、 で AWS サービスを実行するインフラストラクチャを保護する責任を担います AWS クラウド。 は、お客様が安全に使用できるサービス AWS も提供します。セキュリティの有効性は、[AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)の一環として、サードパーティーの審査機関によって定期的にテストおよび検証されています。AWSServiceRoleForAWSShield に適用されるコンプライアンスプログラムについては、「[コンプライアンスプログラムによる対象範囲内のAWS のサービス](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。
+ **クラウド内のセキュリティ** – お客様の責任は、使用する AWS サービスによって決まります。また、お客様は、お客様のデータの機密性、組織の要件、および適用可能な法律および規制などの他の要因についても責任を担います。
![\[図は、水平に分割された長方形を示しています。上半分のタイトルは [カスタマー: クラウド「内の」セキュリティの責任] であり、下半分のタイトルは [AWS: クラウド「の」セキュリティに対する責任] です。お客様用の上半分には 4 つの層が含まれています。一番上は [Customer data] (顧客データ) です。2 つ目は、[Platform, applications, identity and access management] (プラットフォーム、アプリケーション、アイデンティティ、およびアクセス管理) です。3 つ目は、[Operating system, network and firewall configuration] (オペレーティングシステム、ネットワーク、ファイアウォールの設定) です。お客様のエリアの第 4 層と最下層は 3 つのセクションに分割され、隣り合って表示されます。これらの左側には、[Client-side data, encryption and data integrity, authentication] (クライアント側のデータ、暗号化とデータの整合性、認証) があります。真ん中は、[Server-side encryption (file system and/or data)] (サーバー側の暗号化 (ファイルシステムやデータ)) です。右側には、[Networking traffic protection (encryption, integrity, identity)] (ネットワークトラフィック保護 (暗号化、整合性、アイデンティティ)) があります。これで、図の上半分のお客様に関する内容は終わりです。図の下 AWS 半分には、ソフトウェアというタイトルの階層が上部と下部に、ハードウェア/AWS グローバルインフラストラクチャというタイトルの階層が含まれています。ソフトウェアの階層は、[Compute] (コンピューティング)、[Storage] (ストレージ)、[Database] (データベース)、[Networking] (ネットワーク) という 4 つのサブセクションに分割されており、それぞれが隣り合っています。ハードウェアの階層は、[Regions] (リージョン)、[Availability Zones] (アベイラビリティゾーン)、[edge locations] (エッジロケーション) という 3 つのサブセクションに分割されており、それぞれが隣り合っています。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/shared-responsibility-model.png)
# AWS Shield と Shield Advanced の仕組み
このページでは、 AWS Shield Standard と の違いについて説明します AWS Shield Advanced。また、Shield が検出する攻撃のクラスについても説明します。
AWS Shield Standard と は、ネットワークレイヤーとトランスポートレイヤー (レイヤー 3 と 4) およびアプリケーションレイヤー (レイヤー 7) のリソースに対する AWS 分散型サービス拒否 (DDoS) 攻撃に対する保護 AWS Shield Advanced を提供します。DDoS 攻撃は、侵害された複数のシステムが、ターゲットに対してトラフィックでフラッディングを試みる攻撃です。DDoS 攻撃は正当なエンドユーザーがターゲットのサービスにアクセスするのを妨げ、圧倒的なトラフィック量のためにターゲットがクラッシュする可能性があります。
AWS Shield は、幅広い既知の DDoS 攻撃ベクトルとゼロデイ攻撃ベクトルに対する保護を提供します。Shield の検出および緩和は、検出時において、サービスにとって明示的に既知でなくても、脅威に対するカバレッジを提供するように設計されています。
Shield Standard は、 AWSの使用時に自動的に提供され、追加料金はかかりません。攻撃に対するより高いレベルの保護のために、 AWS Shield Advancedサブスクライブすることができます。
Shield が検出する攻撃のクラスには、次のものが含まれます。
+ **[Network volumetric attacks (layer 3)]** (ネットワークボリューム攻撃 (レイヤー 3)) – これは、インフラストラクチャレイヤー攻撃のベクトルのサブカテゴリです。これらのベクトルは、正当なユーザーへのサービスを拒否するために、ターゲットネットワークまたはリソースの容量を飽和させることを試みます。
+ **[Network protocol attacks (layer 4)]** (ネットワークプロトコル攻撃 (レイヤー 4)) – これは、インフラストラクチャレイヤー攻撃のベクトルのサブカテゴリです。これらのベクトルは、プロトコルを悪用してターゲットリソースへのサービスを拒否します。ネットワークプロトコル攻撃の一般的な例は TCP SYN フラッドです。TCP SYN フラッドは、サーバー、ロードバランサー、ファイアウォールなどのリソースの接続状態を使い果たす可能性があります。ネットワークプロトコル攻撃は、帯域幅消費型である場合もあります。例えば、大規模な TCP SYN フラッドには、ターゲットリソースまたは中間リソースの状態を使い果たしながら、ネットワークの容量を飽和させる意図があるかもしれません。
+ **アプリケーションレイヤー攻撃 (レイヤー 7)** - このカテゴリの攻撃ベクトルは、ウェブリクエストのフラッドなど、ターゲットに対して有効なクエリをアプリケーションにフラッディングすることによって、正当なユーザーへのサービス提供の拒否を試みます。
**Contents**
+ [AWS Shield Standard の概要](ddos-standard-summary.md)
+ [AWS Shield Advanced の概要](ddos-advanced-summary.md)
+ [が AWS Shield Advanced 保護する AWS リソースのリスト](ddos-advanced-summary-protected-resources.md)
+ [AWS Shield Advanced 機能とオプション](ddos-advanced-summary-capabilities.md)
+ [追加の保護をサブスクライブ AWS Shield Advanced して適用するかどうかを決定する](ddos-advanced-summary-deciding.md)
+ [DDoS 攻撃の例](types-of-ddos-attacks.md)
+ [がイベント AWS Shield を検出する方法](ddos-event-detection.md)
+ [AWS Shield インフラストラクチャレイヤーの脅威の検出ロジック (レイヤー 3 とレイヤー 4)](ddos-event-detection-infrastructure.md)
+ [アプリケーションレイヤーの脅威に対する Shield Advanced 検出ロジック (レイヤー 7)](ddos-event-detection-application.md)
+ [アプリケーション内の複数のリソースの Shield Advanced 検出ロジック](ddos-event-detection-multiple-resources.md)
+ [がイベント AWS Shield を軽減する方法](ddos-event-mitigation.md)
+ [AWS Shield DDoS 緩和機能のリスト](ddos-event-mitigation-features.md)
+ [AWS Shield CloudFront と Route 53 の緩和ロジック](ddos-event-mitigation-logic-continuous-inspection.md)
+ [AWS Shield AWS リージョンの緩和ロジック](ddos-event-mitigation-logic-regions.md)
+ [AWS Shield AWS Global Accelerator 標準アクセラレーターの緩和ロジック](ddos-event-mitigation-logic-gax.md)
+ [AWS Shield Advanced Elastic IPs の緩和ロジック](ddos-event-mitigation-logic-adv-eip.md)
+ [AWS Shield Advanced ウェブアプリケーションの緩和ロジック](ddos-event-mitigation-logic-adv-web-app.md)
# AWS Shield Standard の概要
AWS Shield は、アプリケーションの境界を保護するマネージド脅威保護サービスです。境界は、 AWS ネットワーク外からのアプリケーショントラフィックの最初のエントリポイントです。
アプリケーションの境界がどこにあるかを判断するには、ユーザーがインターネットからアプリケーションにどのようにアクセスするかを検討します。最初のエントリポイントが AWS リージョンにある場合、アプリケーション境界は Amazon Virtual Private Cloud (VPC) です。ユーザーが Amazon Route 53 によってアプリケーションに誘導され、最初に Amazon CloudFront または を使用してアプリケーションにアクセスする場合 AWS Global Accelerator、アプリケーション境界は AWS ネットワークのエッジから始まります。
Shield は、 で実行されているすべてのアプリケーションに DDoS 検出と緩和の利点を提供しますが AWS、アプリケーションアーキテクチャを設計するときに行う決定は、DDoS の耐障害性のレベルに影響します。DDoS Resiliency は、攻撃を受けている最中に、想定されるパラメータ内でアプリケーションが動作し続ける能力です。
すべての AWS お客様は、Shield Standard の自動保護を追加料金なしで利用できます。Shield Standard は、お客様のウェブサイトやアプリケーションを標的として一般的かつ頻繁に発生するネットワークおよび転送レイヤーの DDoS 攻撃に対して防御します。Shield Standard はすべての AWS お客様を保護するのに役立ちますが、Amazon Route 53 ホストゾーン、Amazon CloudFront ディストリビューション、および AWS Global Accelerator 標準アクセラレーターには特に利点があります。これらのリソースは、既知のすべてのネットワークおよびトランスポートレイヤー攻撃に対して、可用性についての包括的な保護を受けます。
# AWS Shield Advanced の概要
AWS Shield Advanced は、DDoS 攻撃、ボリューメトリックボット、脆弱性悪用の試みなどの外部脅威からアプリケーションを保護するのに役立つマネージドサービスです。攻撃に対するより高いレベルの保護のために、 AWS Shield Advancedサブスクライブすることができます。
Shield Advanced をサブスクライブしてリソースに保護を追加すると、Shield Advanced は、それらのリソースのために拡張された DDoS 攻撃保護を提供します。Shield Advanced から受ける保護は、アーキテクチャと設定の選択内容によって異なります。このガイドの情報を参照して、Shield Advanced を使用して回復力のあるアプリケーションを構築して保護し、エキスパートのサポートが必要なときにエスカレーションできます。
**Shield Advanced サブスクリプションと AWS WAF コスト**
Shield Advanced サブスクリプションは、Shield Advanced で保護するリソースに標準 AWS WAF 機能を使用するコストをカバーします。Shield Advanced 保護の対象となる標準 AWS WAF 料金は、保護パック (ウェブ ACL) あたりのコスト、ルールあたりのコスト、ウェブリクエスト検査の 100 万リクエストあたりの基本料金、最大 1,500 WCUs、およびデフォルトの本文サイズです。
Shield Advanced 自動アプリケーションレイヤー DDoS 緩和を有効にすると、150 個の保護パック (ウェブ ACL) キャパシティユニット (WCU) はルールグループに追加されます。これらの WCU は、保護パック (ウェブ ACL) 内の WCU の使用量に対してカウントされます。詳細については[Shield Advanced によるアプリケーションレイヤー DDoS 自動緩和](ddos-automatic-app-layer-response.md)、[Shield Advanced ルールグループによるアプリケーションレイヤーの保護](ddos-automatic-app-layer-response-rg.md)、および[のウェブ ACL キャパシティユニット (WCUs) AWS WAF](aws-waf-capacity-units.md)を参照してください。
Shield Advanced のサブスクリプションでは、Shield Advanced を使用して保護しないリソース AWS WAF の の使用はカバーされません。また、保護されたリソースの標準以外の追加 AWS WAF コストもカバーしません。標準以外の AWS WAF コストの例としては、Bot Control、CAPTCHAルールアクション、1,500 WCUs を超えるウェブ ACLs、およびデフォルトの本文サイズを超えるリクエスト本文の検査などがあります。完全なリストは AWS WAF 料金ページに記載されています。Shield Advanced へのサブスクリプションには、 Layer 7 Anti-DDoS Amazon Managed Rule グループへのアクセスが含まれます。サブスクリプションの一環として、Shield Advanced で保護された AWS WAF リソースに対するリクエストは 1 か月あたり最大 500 億件になります。500 億を超えるリクエストは、 AWS Shield Advanced 料金ページに従って請求されます。
詳細情報および料金の例については、「[Shield の料金](https://aws.amazon.com/shield/pricing/)」および「[AWS WAF の料金](https://aws.amazon.com/waf/pricing/)」を参照してください。
**Shield Advanced サブスクリプションの請求**
AWS チャネルリセラーの場合は、アカウントチームに情報とガイダンスを求めてください。この請求情報は、 AWS チャネルリセラーではないお客様を対象としています。
他のすべてについては、次のサブスクリプションと請求のガイドラインが適用されます。
+ AWS Organizations 組織のメンバーであるアカウントの場合、 は、支払者アカウント自体がサブスクライブされているかどうかにかかわらず、組織の支払者アカウントに対して Shield Advanced サブスクリプションを AWS 請求します。
+ 同じ [AWS Organizations 一括請求 (コンソリデーティッドビリング) アカウントファミリー](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) に属する複数のアカウントをサブスクライブする場合、1 つのサブスクリプション料金はファミリー内のすべてのサブスクライブアカウントに対するものです。組織は、すべての AWS アカウント とそのすべてのリソースを所有している必要があります。
+ 複数の組織のために複数のアカウントをサブスクライブする場合でも、すべてを所有しているのであれば、すべての組織、アカウント、リソースのサブスクリプション料金の支払いを引き続き 1 回で行うことができます。アカウントマネージャーまたは AWS サポートに連絡して、組織の 1 つを除くすべての AWS Shield Advanced サブスクリプション料金の免除をリクエストしてください。
詳細な料金情報と例については、「[AWS Shield の料金表](https://aws.amazon.com/shield/pricing/)」を参照してください。
**Topics**
# が AWS Shield Advanced 保護する AWS リソースのリスト
**注記**
Shield Advanced 保護は、Shield Advanced で明示的に指定したリソース、または Shield AWS Firewall Manager Advanced ポリシーで保護するリソースに対してのみ有効になります。Shield Advanced は、リソースを自動的に保護しません。
Shield Advanced を使用すると、次のリソースタイプで高度なモニタリングと保護を行うことができます。
+ Amazon CloudFront ディストリビューション。CloudFront の継続的デプロイでは、Shield Advanced は保護対象のプライマリディストリビューションに関連付けられているすべてのステージングディストリビューションを保護します。
+ Amazon Route 53 ホストゾーン。
+ AWS Global Accelerator 標準アクセラレーター。
+ Amazon EC2 Elastic IP アドレス。Shield Advanced は、保護された Elastic IP アドレスに関連付けられているリソースを保護します。
+ Amazon EC2 インスタンス (Amazon EC2 Elastic IP アドレスへの関連付け経由)
+ 次の Elastic Load Balancing (ELB) ロードバランサー:
+ Application Load Balancer。
+ Classic Load Balancer。
+ Network Load Balancer (Amazon EC2 Elastic IP アドレスへの関連付け経由)。
これらのリソースタイプの保護に関する追加情報については、「[が AWS Shield Advanced 保護するリソースのリスト](ddos-protections-by-resource-type.md)」を参照してください。
# AWS Shield Advanced 機能とオプション
AWS Shield Advanced サブスクリプションには、次の機能とオプションが含まれています。これらは、既に提供されている DDoS 検出および緩和機能を補完します AWS。
+ **AWS WAF 統合** – Shield Advanced は、アプリケーションレイヤー保護の一部として AWS WAF ウェブ ACLs、ルール、およびルールグループを使用します。詳細については AWS WAF、「」を参照してください[の AWS WAF 仕組み](how-aws-waf-works.md)。
**注記**
Shield Advanced サブスクリプションは、Shield Advanced で保護するリソースに標準 AWS WAF 機能を使用するコストをカバーします。Shield Advanced 保護の対象となる標準 AWS WAF 料金は、保護パック (ウェブ ACL) あたりのコスト、ルールあたりのコスト、ウェブリクエスト検査の 100 万リクエストあたりの基本料金、最大 1,500 WCUs、およびデフォルトの本文サイズです。
Shield Advanced 自動アプリケーションレイヤー DDoS 緩和を有効にすると、150 個の保護パック (ウェブ ACL) キャパシティユニット (WCU) はルールグループに追加されます。これらの WCU は、保護パック (ウェブ ACL) 内の WCU の使用量に対してカウントされます。詳細については[Shield Advanced によるアプリケーションレイヤー DDoS 自動緩和](ddos-automatic-app-layer-response.md)、[Shield Advanced ルールグループによるアプリケーションレイヤーの保護](ddos-automatic-app-layer-response-rg.md)、および[のウェブ ACL キャパシティユニット (WCUs) AWS WAF](aws-waf-capacity-units.md)を参照してください。
Shield Advanced のサブスクリプションは、Shield Advanced を使用して保護しないリソース AWS WAF の の使用を対象としていません。また、保護されたリソースの標準以外の追加 AWS WAF コストもカバーしません。標準以外の AWS WAF コストの例としては、Bot Control、CAPTCHAルールアクション、1,500 WCUs を超えるウェブ ACLs、およびデフォルトの本文サイズを超えるリクエスト本文の検査などがあります。完全なリストは AWS WAF 料金ページに記載されています。Shield Advanced へのサブスクリプションには、 Layer 7 Anti-DDoS Amazon Managed Rule グループへのアクセスが含まれます。サブスクリプションの一環として、Shield Advanced で保護された AWS WAF リソースに対するリクエストは 1 か月あたり最大 500 億件になります。500 億を超えるリクエストは、 AWS Shield Advanced 料金ページに従って請求されます。
詳細情報および料金の例については、「[Shield の料金](https://aws.amazon.com/shield/pricing/)」および「[AWS WAF の料金](https://aws.amazon.com/waf/pricing/)」を参照してください。
+ **アプリケーションレイヤーの DDoS の自動緩和** - Shield Advanced は、保護されたリソースに対するアプリケーションレイヤー (レイヤー 7) 攻撃を自動的に緩和して対応するように設定できます。自動緩和により、Shield Advanced は既知の DDoS ソースからのリクエストに AWS WAF レート制限を適用し、検出された DDoS 攻撃に応じてカスタム AWS WAF 保護を自動的に追加および管理します。攻撃の一部であるウェブリクエストをカウントまたはブロックするように自動緩和を設定できます。
詳細については、「[Shield Advanced によるアプリケーションレイヤー DDoS 自動緩和](ddos-automatic-app-layer-response.md)」を参照してください。
+ **ヘルスベースの検出** – Shield Advanced で Amazon Route 53 ヘルスチェックを使用して、イベントの検出と緩和の通知を受けることができます。ヘルスチェックは、仕様に従ってアプリケーションをモニタリングし、仕様が満たされた場合は正常、そうでない場合は異常を報告します。Shield Advanced でヘルスチェックを使用すると、誤検出を防止するのに役立つともに、保護されたリソースが異常な場合により迅速に検出および緩和できます。Route 53 ホストゾーンを除くリソースタイプのために、ヘルスベースの検出を使用できます。Shield Advanced のプロアクティブエンゲージメントは、ヘルスベースの検出が有効になっているリソースでのみ使用できます。
詳細については、「[Shield Advanced と Route 53 を使用したヘルスチェックを使用したヘルスベースの検出](ddos-advanced-health-checks.md)」を参照してください。
+ **保護グループ** – 保護グループを使用して、保護されたリソースの論理グループを作成し、グループ全体の検出と緩和を強化できます。新しく保護されたリソースを自動的に含めるように、保護グループのメンバーシップの条件を定義できます。保護されたリソースは、複数の保護グループに所属できます。
詳細については、「[AWS Shield Advanced 保護のグループ化](ddos-protection-groups.md)」を参照してください。
+ **DDoS イベントと攻撃の可視性の向上** – Shield Advanced を使用すると、高度なリアルタイムのメトリクスとレポートにアクセスして、保護された AWS のリソースに対するイベントと攻撃の可視性を高めることができます。この情報には、Shield Advanced API とコンソール、および Amazon CloudWatch メトリクスを通じてアクセスできます。
詳細については、「[Shield Advanced による DDoS イベントの可視性](ddos-viewing-events.md)」を参照してください。
+ ** AWS Firewall Managerによる Shield Advanced 保護の一元管理** – Firewall Manager を使用して、新しいアカウントとリソースに Shield Advanced 保護を自動的に適用し、ウェブ ACL に AWS WAF ルールをデプロイできます。Firewall Manager Shield Advanced 保護ポリシーは、Shield Advanced のお客様に追加料金なしでご利用いただけます。また、Amazon Simple Notification Service (SNS) トピックまたは AWS Security Hub CSPMで Firewall Manager を使用して、アカウントの Shield Advanced モニタリングアクティビティを一元化することもできます。
Firewall Manager を使用して Shield Advanced 保護機能を管理する方法については、「[AWS Firewall Manager](fms-chapter.md)」および「[Firewall Manager での AWS Shield Advanced ポリシーの使用](shield-policies.md)」を参照してください。Firewall Manager の料金については、「[AWS Firewall Manager の料金](https://aws.amazon.com/firewall-manager/pricing/)」を参照してください。
+ **AWS Shield Response Team (SRT)** – SRT は AWS、、Amazon.com、およびその子会社の保護において豊富な経験を持っています。 AWS Shield Advanced のお客様は、アプリケーションの可用性に影響を与える DDoS 攻撃を受けている最中に、いつでも SRT に連絡してサポートを求めることができます。SRT と連携して、リソースのカスタム緩和策を作成および管理することもできます。SRT のサービスを使用するには、[ビジネスサポートプラン](https://aws.amazon.com/premiumsupport/business-support/)または[エンタープライズサポートプラン](https://aws.amazon.com/premiumsupport/enterprise-support/)をサブスクライブする必要もあります。
詳細については、「[Shield Response Team (SRT) サポートによるマネージド DDoS イベントレスポンス](ddos-srt-support.md)」を参照してください。
+ **プロアクティブな関与** – Shield Advanced が検出したイベントの発生中に、保護されたリソースに関連付けられた Amazon Route 53 ヘルスチェックが異常になった場合、プロアクティブな関与によって、Shield Response Team (SRT) はお客様に直接ご連絡します。これにより、アプリケーションの可用性に影響を及ぼす可能性のある攻撃が疑われる場合に、エキスパートとより迅速に連携することができます。
詳細については、「[SRT が直接連絡するためのプロアクティブエンゲージメントの設定](ddos-srt-proactive-engagement.md)」を参照してください。
+ **コスト保護の機会** – Shield Advanced は、保護されたリソースに対する DDoS 攻撃に起因する可能性のある AWS 請求の急増に対するコスト保護を提供します。これには、Shield Advanced データ転送アウト (DTO) 使用料の急増に対する補償が含まれる場合があります。Shield Advanced は、Shield Advanced サービスクレジットという形であらゆるコスト保護を提供します。
詳細については、「[攻撃 AWS Shield Advanced 後の でのクレジットのリクエスト](ddos-request-service-credit.md)」を参照してください。
# 追加の保護をサブスクライブ AWS Shield Advanced して適用するかどうかを決定する
AWS Shield Advanced をサブスクライブするアカウントと追加の保護を適用する場合を判断するのに役立てるため、このセクションのシナリオを確認してください。Shield Advanced では、一括請求 (コンソリデーティッドビリング) の支払いアカウントで作成されたすべてのアカウントについて、1 つの月額サブスクリプション料金をお支払いいただきます。さらに、転送されたデータの GB (OUT) に基づく使用料金もお支払いいただきます。Shield Advanced の料金については、「[AWS Shield Advanced の料金](https://aws.amazon.com/shield/pricing/)」を参照してください。
Shield Advanced でアプリケーションとそのリソースを保護するには、アプリケーションを管理するアカウントを Shield Advanced にサブスクライブし、アプリケーションのリソースに保護を追加します。アカウントのサブスクライブとリソースの保護については、「[セットアップ AWS Shield Advanced](getting-started-ddos.md)」を参照してください。
**Shield Advanced サブスクリプションと AWS WAF コスト**
Shield Advanced サブスクリプションは、Shield Advanced で保護するリソースに標準 AWS WAF 機能を使用するコストをカバーします。Shield Advanced 保護の対象となる標準 AWS WAF 料金は、保護パック (ウェブ ACL) あたりのコスト、ルールあたりのコスト、ウェブリクエスト検査の 100 万リクエストあたりの基本料金、最大 1,500 WCUs、およびデフォルトの本文サイズです。
Shield Advanced 自動アプリケーションレイヤー DDoS 緩和を有効にすると、150 個の保護パック (ウェブ ACL) キャパシティユニット (WCU) はルールグループに追加されます。これらの WCU は、保護パック (ウェブ ACL) 内の WCU の使用量に対してカウントされます。詳細については[Shield Advanced によるアプリケーションレイヤー DDoS 自動緩和](ddos-automatic-app-layer-response.md)、[Shield Advanced ルールグループによるアプリケーションレイヤーの保護](ddos-automatic-app-layer-response-rg.md)、および[のウェブ ACL キャパシティユニット (WCUs) AWS WAF](aws-waf-capacity-units.md)を参照してください。
Shield Advanced のサブスクリプションでは、Shield Advanced を使用して保護しないリソース AWS WAF の の使用はカバーされません。また、保護されたリソースの標準以外の追加 AWS WAF コストもカバーしません。標準以外の AWS WAF コストの例としては、Bot Control、CAPTCHAルールアクション、1,500 WCUs を超えるウェブ ACLs、およびデフォルトの本文サイズを超えるリクエスト本文の検査などがあります。完全なリストは AWS WAF 料金ページに記載されています。Shield Advanced へのサブスクリプションには、 Layer 7 Anti-DDoS Amazon Managed Rule グループへのアクセスが含まれます。サブスクリプションの一環として、Shield Advanced で保護された AWS WAF リソースに対するリクエストは 1 か月あたり最大 500 億件になります。500 億を超えるリクエストは、 AWS Shield Advanced 料金表ページに従って請求されます。
詳細情報および料金の例については、「[Shield の料金](https://aws.amazon.com/shield/pricing/)」および「[AWS WAF の料金](https://aws.amazon.com/waf/pricing/)」を参照してください。
**Shield Advanced サブスクリプションの請求**
AWS チャネルリセラーの場合は、アカウントチームに情報とガイダンスを求めてください。この請求情報は、 AWS チャネルリセラーではないお客様を対象としています。
他のすべてについては、次のサブスクリプションと請求のガイドラインが適用されます。
+ AWS Organizations 組織のメンバーであるアカウントの場合、 は、支払者アカウント自体がサブスクライブされているかどうかにかかわらず、組織の支払者アカウントに対して Shield Advanced サブスクリプションを AWS 請求します。
+ 同じ [AWS Organizations 一括請求 (コンソリデーティッドビリング) アカウントファミリー](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) に属する複数のアカウントをサブスクライブする場合、1 つのサブスクリプション料金はファミリー内のすべてのサブスクライブアカウントに対するものです。組織は、すべての AWS アカウント とそのすべてのリソースを所有している必要があります。
+ 複数の組織のために複数のアカウントをサブスクライブする場合でも、すべてを所有しているのであれば、すべての組織、アカウント、リソースのサブスクリプション料金の支払いを引き続き 1 回で行うことができます。アカウントマネージャーまたは AWS サポートに連絡して、組織の 1 つを除くすべての AWS Shield Advanced サブスクリプション料金の免除をリクエストしてください。
詳細な料金情報と例については、「[AWS Shield の料金表](https://aws.amazon.com/shield/pricing/)」を参照してください。
**保護するアプリケーションの特定**
次のいずれかが必要なアプリケーションには、Shield Advanced 保護を実装することを検討してください。
+ アプリケーションのユーザーに保証された可用性。
+ DDoS 攻撃によってアプリケーションが影響を受ける場合における、DDoS 緩和のエキスパートへの迅速なアクセス。
+ アプリケーション AWS が DDoS 攻撃の影響を受ける可能性があることを認識し、セキュリティチームまたは運用チームからの攻撃 AWS の通知とエスカレーション。
+ クラウドコストの予測可能性 (DDoS 攻撃が AWS のサービスの利用に影響を与える場合を含む)。
アプリケーションまたはそのリソースが上記のいずれかを必要とする場合は、関連アカウントのサブスクリプションを作成することを検討してください。
**保護するリソースの特定**
サブスクライブした各アカウントについて、次のいずれかの特性を持つ各リソースに Shield Advanced 保護を追加することを検討してください。
+ このリソースは、インターネット上の外部ユーザーにサービスを提供します。
+ リソースはインターネットに公開されます。また、重要なアプリケーションの一部でもあります。インターネット上のユーザーがアクセスするかどうかにかかわらず、公開されているすべてのリソースを検討してください。
+ リソースは AWS WAF ウェブ ACL によって保護されます。
リソースの保護の作成と管理の詳細については、「[でのリソース保護 AWS Shield Advanced](ddos-resource-protections.md)」を参照してください。
さらに、このガイドの推奨事項は、DDoS レジリエンシーを考慮してアプリケーションを設計し、最適な保護を実現するために Shield Advanced の機能を適切に設定するのに役立ちます。
# DDoS 攻撃の例
AWS Shield Advanced は、さまざまなタイプの攻撃に対する保護を拡張します。
次のリストでは、いくつかの一般的な攻撃の種類について説明します。
**User Datagram Protocol (UDP) リフレクション攻撃**
UDP リフレクション攻撃では、攻撃者はリクエストの発生元を偽装し、UDP を使用してサーバーから大量のレスポンスを引き出すことができます。攻撃対象の偽装 IP アドレスに向かう追加のネットワークトラフィックにより、対象のサーバーは遅くなり、正当なエンドユーザーが必要なリソースにアクセスできなくなります。
**TCP SYN フラッド**
TCP SYN フラッド攻撃の目的は、接続を半開状態にして、システムの利用可能なリソースを枯渇させることです。ユーザーがウェブサーバーのような TCP サービスに接続すると、クライアントは TCP SYN パケットを送信します。サーバーが肯定応答を返し、クライアントがそれ自体の肯定応答を返すことで、3 ウェイハンドシェイクが完了します。TCP SYN フラッドでは、3 回目の肯定応答が返されることはなく、サーバーはレスポンスを待ったままになります。このため、他のユーザーはサーバーに接続できなくなります。
**DNS クエリフラッド**
DNS クエリフラッドでは、攻撃者は複数の DNS クエリを使用して DNS サーバーのリソースを使い果たします。 AWS Shield Advanced は、Route 53 DNS サーバーの DNS クエリフラッド攻撃に対する保護を提供します。
**HTTP フラッド/キャッシュ無効化 (レイヤー 7) 攻撃**
`GET` および `POST` フラッドを含む HTTP フラッドにより、攻撃者はウェブアプリケーションの実際のユーザーからのように見せかけて多数の HTTP リクエストを送信します。キャッシュ無効化攻撃は、HTTP フラッドの一種です。HTTP リクエストのクエリ文字列のバリエーションを使用して、エッジでキャッシュされているコンテンツが使用されないようにし、オリジンウェブサーバーからコンテンツが送信されるようにすることで、オリジンウェブサーバーに損害につながる可能性があるほどの負荷をかけます。
# がイベント AWS Shield を検出する方法
AWS は AWS 、ネットワークおよび個々の AWS サービスのサービスレベル検出システムを運用し、DDoS 攻撃中にそれらが引き続き利用可能であることを確認します。さらに、リソースレベルの検出システムは、個々の AWS リソースをモニタリングして、リソースへのトラフィックが予想されるパラメータ内に留まるようにします。この組み合わせは、既知の不正なパケットを削除し、悪意のある可能性のあるトラフィックを強調し、エンドユーザーからのトラフィックに優先順位を付ける緩和策を適用することで、ターゲット AWS リソースと AWS サービスの両方を保護します。
イベントは、Shield Advanced のイベントの概要、攻撃の詳細、Amazon CloudWatch メトリクスに、DDoS 攻撃ベクトルの名前として、または評価がシグネチャではなくトラフィック量に基づいている場合は `Volumetric` として表示されます。`DDoSDetected` CloudWatch メトリクス内で利用可能な攻撃ベクトルのディメンションの詳細については、[AWS Shield Advanced メトリクス](shield-metrics.md) を参照してください。
**Topics**
+ [AWS Shield インフラストラクチャレイヤーの脅威の検出ロジック (レイヤー 3 とレイヤー 4)](ddos-event-detection-infrastructure.md)
+ [アプリケーションレイヤーの脅威に対する Shield Advanced 検出ロジック (レイヤー 7)](ddos-event-detection-application.md)
+ [アプリケーション内の複数のリソースの Shield Advanced 検出ロジック](ddos-event-detection-multiple-resources.md)
# AWS Shield インフラストラクチャレイヤーの脅威の検出ロジック (レイヤー 3 とレイヤー 4)
このページでは、インフラストラクチャ (ネットワークと移転) レイヤーでイベント検出がどのように機能するかについて説明します。
インフラストラクチャレイヤー (レイヤー 3 とレイヤー 4) の DDoS 攻撃からターゲット AWS リソースを保護するために使用される検出ロジックは、リソースタイプとリソースが保護されているかどうかによって異なります AWS Shield Advanced。
**Amazon CloudFront と Amazon Route 53 の検出**
CloudFront および Route 53 でウェブアプリケーションを提供すると、アプリケーションへのすべてのパケットが完全インライン DDoS 緩和システムによって検査されます。これにより、観測可能なレイテンシーが発生することはありません。CloudFront ディストリビューションおよび Route 53 ホストゾーンに対する DDoS 攻撃は、リアルタイムで緩和されます。これらの保護は、 AWS Shield Advancedを使用するかどうかにかかわらず適用されます。
DDoS イベントの迅速な検出と緩和のために、可能な場合は常に、ウェブアプリケーションのエントリポイントとしての CloudFront と Route 53 の利用に関するベストプラクティスに従います。
**AWS Global Accelerator および リージョンのサービスの検出**
リソースレベルの検出は、Classic Load Balancer、Application Load Balancer、Elastic IP アドレス (EIPs) などの AWS リージョンで起動される AWS Global Accelerator 標準アクセラレーターとリソースを保護します。これらのリソースタイプは、緩和が必要な DDoS 攻撃の存在を示している可能性のあるトラフィックの増加をモニタリングします。毎分、各 AWS リソースへのトラフィックが評価されます。リソースへのトラフィックが上昇した場合は、リソースの容量を測定するために追加のチェックが実行されます。
Shield は次の標準チェックを実行します。
+ **Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、Amazon EC2 インスタンスにアタッチされた EIP** – Shield は保護されたリソースから容量を取得します。容量は、ターゲットのインスタンスタイプ、インスタンスサイズ、およびインスタンスが拡張ネットワークを使用しているかどうかなどの他の要因によって異なります。
+ **Classic Load Balancer と Application Load Balancer** – Shield はターゲットのロードバランサーノードから容量を取得します。
+ **Network Load Balancer にアタッチされた EIP** – Shield はターゲットのロードバランサーから容量を取得します。容量は、ターゲットのロードバランサーのグループ設定とは無関係です。
+ **AWS Global Accelerator 標準アクセラレーター** – Shield は、エンドポイント設定に基づいて容量を取得します。
これらの評価は、ポートやプロトコルなど、ネットワークトラフィックの複数のディメンションにわたって行われます。ターゲットリソースの容量を超えると、Shield は DDoS 緩和策を実行します。Shield によって実施された緩和策は DDoS トラフィックを削減しますが、完全に排除することはできない場合があります。Shield は、既知の DDoS 攻撃ベクトルと一致するトラフィックディメンションでリソースの容量がわずかに超過した場合も、緩和策を講じることがあります。Shield は、この緩和策を有効期限 (TTL) を設けて実施し、攻撃が続く限り延長されます。
**注記**
Shield によって実施された緩和策は DDoS トラフィックを削減しますが、完全に排除することはできない場合があります。Shield を のようなソリューション AWS Network Firewall や のようなホスト上のファイアウォールで強化iptablesすることで、アプリケーションがアプリケーションに有効でないか、正当なエンドユーザーによって生成されなかったトラフィックを処理できないようにすることができます。
Shield Advanced の保護では、既存の Shield の検出アクティビティに次が追加されます。
+ **[Lower detection thresholds]** (検出しきい値を下げる) – Shield Advanced は、計算された容量の半分に緩和策を実施します。これにより、ゆっくり増加する攻撃をより迅速に緩和し、より曖昧なボリュームシグネチャを持つ攻撃を緩和できます。
+ **[Intermittent attack protection]** (断続的な攻撃からの保護) – Shield Advanced は、攻撃の頻度と期間に基づいて、指数関数的に増加する有効期限 (TTL) で緩和策を実施します。これにより、リソースが頻繁にターゲットとなり、短いバーストで攻撃が発生する際に、緩和策が長く維持されます。
+ **[Health-based detection]** (ヘルスベースの検出) – Route 53 ヘルスチェックを Shield Advanced で保護されたリソースに関連付けると、ヘルスチェックのステータスが検出ロジックで使用されます。検出されたイベント中、ヘルスチェックが正常である場合、Shield Advanced では、緩和策を行う前に、そのイベントが攻撃であるというより強力な確信が必要です。代わりにヘルスチェックが異常な場合は、信頼が確立される前でも Shield Advanced が緩和策を講じることがあります。この機能は、誤検出を回避するのに役立つとともに、アプリケーションに影響する攻撃への迅速な対応を提供します。Shield Advanced を使用したヘルスチェックの詳細については、「[Shield Advanced と Route 53 を使用したヘルスチェックを使用したヘルスベースの検出](ddos-advanced-health-checks.md)」を参照してください。
# アプリケーションレイヤーの脅威に対する Shield Advanced 検出ロジック (レイヤー 7)
このページでは、アプリケーション層におけるイベント検出の仕組みについて説明します。
AWS Shield Advanced は、保護された Amazon CloudFront ディストリビューションと Application Load Balancer のウェブアプリケーションレイヤー検出を提供します。これらのリソースタイプを Shield Advanced で保護する場合、 AWS WAF ウェブ ACL を保護に関連付けて、ウェブアプリケーションレイヤーの検出を有効にすることができます。Shield Advanced は、関連付けられたウェブ ACL のリクエストデータを消費し、アプリケーションのトラフィックベースラインを構築します。ウェブアプリケーションレイヤーの検出は、Shield Advanced と AWS WAFのネイティブ統合に依存しています。 AWS WAF ウェブ ACL を Shield Advanced で保護されたリソースに関連付けるなど、アプリケーションレイヤーの保護の詳細については、「」を参照してください[AWS Shield Advanced および を使用したアプリケーションレイヤー (レイヤー 7) の保護 AWS WAF](ddos-app-layer-protections.md)。
ウェブアプリケーションレイヤーの検出では、Shield Advanced はアプリケーショントラフィックをモニタリングし、異常を検出する過去のベースラインと比較します。このモニタリングは、トラフィックの総量と構成をカバーします。DDoS 攻撃を受けている最中、トラフィックの量と構成の両方が変化することが想定され、Shield Advanced では、イベントを宣言するために両方における統計的に有意な偏差が必要です。
Shield Advanced は、過去のタイムウィンドウに照らして測定を実行します。このアプローチを使用すると、トラフィック量の正当な変化や、毎日同じ時間に提供される販売など、想定されるパターンに一致するトラフィックの変化による誤検出の通知が減少します。
**注記**
Shield Advanced が通常の正当なトラフィックパターンを表すベースラインを確立する時間を与えることで、Shield Advanced 保護の誤検出を回避できます。Shield Advanced は、ウェブ ACL を保護されたリソースに関連付けると、ベースラインの情報を収集し始めます。ウェブトラフィックに異常なパターンを引き起こす可能性のある予定イベントの少なくとも 24 時間前に、ウェブ ACL を保護リソースに関連付けます。Shield Advanced のウェブアプリケーションレイヤー検出は、30 日間の通常のトラフィックが観測された場合に最も正確です。
Shield Advanced がイベントを検出するのにかかる時間は、トラフィック量で見られる変化の量の影響を受けます。量の変化が少ない場合、Shield Advanced は、イベントが発生していることについてのより強い確信を持つために、トラフィックをより長い期間にわたって観察します。量の変化が大きい場合、Shield Advanced はイベントをより迅速に検出してレポートします。
ウェブ ACL のレートベースのルールは、ユーザーによって追加されるか、Shield Advanced 自動アプリケーションレイヤー緩和機能によって追加されるかにかかわらず、検出可能なレベルに達する前に攻撃を軽減できます。アプリケーションレイヤー DDoS の自動緩和の詳細については、[Shield Advanced によるアプリケーションレイヤー DDoS 自動緩和](ddos-automatic-app-layer-response.md) を参照してください。
**注記**
トラフィックの増加やロードに対応してスケールするようにアプリケーションを設計して、小規模なリクエストフラッドの影響を受けないようにすることができます。Shield Advanced を使用すると、保護されたリソースはコスト保護の対象となります。これは、DDoS 攻撃の結果として発生する可能性のあるクラウド料金の想定外の増加を防ぐのに役立ちます。Shield Advanced のコスト保護の詳細については、「[攻撃 AWS Shield Advanced 後の でのクレジットのリクエスト](ddos-request-service-credit.md)」を参照してください。
# アプリケーション内の複数のリソースの Shield Advanced 検出ロジック
このページでは、アプリケーション内の複数のリソースのためにイベント検出の仕組みについて説明します。
AWS Shield Advanced 保護グループを使用して、同じアプリケーションの一部である保護されたリソースのコレクションを作成できます。グループに配置する保護されたリソースを選択するか、同じタイプのすべてのリソースを 1 つのグループとして扱うことを指定できます。例えば、すべての Application Load Balancer のグループを作成できます。保護グループを作成すると、Shield Advanced 検出は、グループ内の保護されたリソースに関するすべてのトラフィックを集約します。これは、トラフィック量は少ないが、集約されたボリュームが大きいリソースが多数ある場合に有益です。また、保護されたリソース間でトラフィックが転送されるブルーグリーンデプロイメント向けに、保護グループを使用してアプリケーションベースラインを保持することもできます。
次のいずれかの方法で保護グループ内のトラフィックを集約することを選択できます。
+ **[Sum]** (合計) – この集計は、保護グループ内のリソース全体のすべてのトラフィックを合計します。この集約を使用して、新しく作成されたリソースに既存のベースラインが確実に存在しているようにしたり、検出の感度を下げて、誤検出を防いだりすることができます。
+ **[Mean]** (平均) – この集計は、保護グループ全体のすべてのトラフィックの平均を使用します。この集約は、ロードバランサーのように、リソース間のトラフィックが均一であるアプリケーションに使用できます。
+ **[Max]** (最大) – この集約は、保護グループ内のリソースの中で最も高いトラフィックを使用します。この集約は、保護グループにアプリケーションの階層が複数ある場合に使用できます。例えば、CloudFront ディストリビューション、その Application Load Balancer のオリジン、および Application Load Balancer の Amazon EC2 インスタンスターゲットを含む保護グループがあるとします。
また、保護グループを使用して、複数のインターネットに接続する Elastic IP または AWS Global Accelerator 標準のアクセラレーターをターゲットとする攻撃に対して、Shield Advanced が緩和策を実施する速度を向上させることもできます。保護グループ内の 1 つのリソースがターゲットになると、Shield Advanced は、グループ内の他のリソースについての信頼を確立します。これにより、Shield Advanced 検出がアラート状態になり、追加の緩和策の作成に必要な時間を短縮できます。
保護グループの詳細については、「[AWS Shield Advanced 保護のグループ化](ddos-protection-groups.md)」を参照してください。
# がイベント AWS Shield を軽減する方法
このページでは、 AWS Shield イベント緩和の仕組みについて説明します。
アプリケーションを保護する緩和ロジックは、アプリケーションのアーキテクチャによって異なります。Amazon CloudFront および Amazon Route 53 でウェブアプリケーションを保護する場合、ウェブおよび DNS ユースケースに固有の緩和策と、サービスのすべてのトラフィックを保護する緩和策の恩恵を受けることができます。アプリケーションのエントリポイントが リージョンで AWS 実行されるリソースである場合、緩和ロジックはサービス、リソースタイプ、および の使用によって異なります AWS Shield Advanced。
AWS DDoS 緩和システムは Shield エンジニアによって開発され、 AWS サービスと緊密に統合されています。エンジニアは、ターゲットリソースの容量や健全性など、アーキテクチャの側面を考慮に入れます。Shield エンジニアは、DDoS 緩和システムの有効性とパフォーマンスを継続的に監視し、新しい脅威が発見または予測されたときに迅速に対応できます。
トラフィックの増加やロードに対応してスケールするようにアプリケーションを設計して、小規模なリクエストフラッドの影響を受けないようにする手助けをします。Shield Advanced を使用してリソースを保護すると、DDoS 攻撃の結果として発生する可能性のあるクラウド料金の予想外の増加を防ぐことができます。
**インフラストラクチャの緩和**
インフラストラクチャレイヤー攻撃の場合、 AWS Shield DDoS 緩和システムは AWS ネットワーク境界と AWS エッジロケーションに存在します。 AWS インフラストラクチャ全体に複数のレベルのセキュリティコントロールを配置することで、クラウドアプリケーションにdefense-in-depthを提供します。
Shield により、インターネットからの進入のすべてのポイントで DDoS 軽減システムを維持されます。Shield は DDoS 攻撃を検出すると、進入ポイントごとに、同じ場所にある DDoS 緩和システムを介してトラフィックを再ルーティングします。これにより、観測可能なレイテンシーがさらに発生することはなく、すべての AWS リージョンとすべてのエッジロケーションにおいて、100 テラビット/秒 (Tbps) を超える緩和能力を実現します。Shield は、トラフィックを外部またはリモートのスクラビングセンターに再ルーティングすることなく、リソースの可用性を保護します。これにより、レイテンシーが増加する可能性があります。
+ AWS ネットワーク境界では、あらゆる AWS サービスまたはリソースについて、DDoS 緩和システムはインターネットからのインフラストラクチャレイヤー攻撃を軽減します。Shield による検出または Shield Response Team (SRT) のエンジニアによる通知があると、システムは緩和を実行します。
+ AWS エッジロケーションでは、DDoS 緩和システムは、オリジンに関係なく、Amazon CloudFront ディストリビューションと Amazon Route 53 ホストゾーンに転送されるすべてのパケットを継続的に検査します。必要な場合、システムはウェブおよび DNS トラフィック向けに特別に設計された緩和策を適用します。Amazon CloudFront と Amazon Route 53 を使用してウェブアプリケーションを保護することで付加される利点の 1 つは、Shield 検出からのシグナルを必要とせずに DDoS 攻撃を即座に軽減できることです。
**アプリケーションレイヤーの緩和**
Shield Advanced は、Shield Advanced 保護を有効にした Amazon CloudFront ディストリビューションと Application Load Balancer 向けに、ウェブアプリケーションレイヤー緩和を提供します。保護を有効にすると、 AWS WAF ウェブ ACL をリソースに関連付けて、ウェブアプリケーションレイヤーの検出を有効にします。さらに、自動アプリケーションレイヤー軽減を有効にするオプションがあります。これは、DDoS 攻撃中に保護を管理するよう Shield Advanced に指示します。
Shield は、Shield Advanced と自動アプリケーションレイヤー緩和を有効にしたリソースに対するアプリケーションレイヤー攻撃に対してのみカスタム緩和策を提供します。自動緩和により、Shield Advanced は既知の DDoS ソースからのリクエストに AWS WAF レート制限を適用し、検出された DDoS 攻撃に応じてカスタム AWS WAF 保護を自動的に追加および管理します。このタイプの緩和の詳細については、「[Shield Advanced が自動緩和を管理する方法](ddos-automatic-app-layer-response-behavior.md)」を参照してください。。
ウェブ ACL のレートベースのルールは、ユーザーが追加した場合でも、Shield Advanced 自動アプリケーションレイヤー緩和機能によって追加された場合でも、検出可能なレベルに達する前に攻撃を軽減できます。検知の詳細については、[アプリケーションレイヤーの脅威に対する Shield Advanced 検出ロジック (レイヤー 7)](ddos-event-detection-application.md) を参照してください。
**Topics**
+ [AWS Shield DDoS 緩和機能のリスト](ddos-event-mitigation-features.md)
+ [AWS Shield CloudFront と Route 53 の緩和ロジック](ddos-event-mitigation-logic-continuous-inspection.md)
+ [AWS Shield AWS リージョンの緩和ロジック](ddos-event-mitigation-logic-regions.md)
+ [AWS Shield AWS Global Accelerator 標準アクセラレーターの緩和ロジック](ddos-event-mitigation-logic-gax.md)
+ [AWS Shield Advanced Elastic IPs の緩和ロジック](ddos-event-mitigation-logic-adv-eip.md)
+ [AWS Shield Advanced ウェブアプリケーションの緩和ロジック](ddos-event-mitigation-logic-adv-web-app.md)
# AWS Shield DDoS 緩和機能のリスト
AWS Shield DDoS 緩和の主な機能は次のとおりです。
+ **パケット検証** — これにより、検査されたすべてのパケットが期待される構造に適合し、そのプロトコルに対して有効であることが保証されます。サポートされているプロトコル検証には、IP、TCP（ヘッダーとオプションを含む）、UDP、ICMP、DNS、および NTP が含まれます。
+ **アクセスコントロールリスト (ACL) と Shaper** — ACL は特定の属性に対してトラフィックを評価し、一致するトラフィックをドロップするか、シェーパーにマッピングします。シェーパーは、一致するトラフィックのパケットレートを制限し、送信先に到達するボリュームを含めるために余分なパケットを削除します。 AWS Shield detection and Shield Response Team (SRT) エンジニアは、予想されるトラフィックへの専用レート割り当てと、既知の DDoS 攻撃ベクトルに一致する属性を持つトラフィックへのより制限的なレート割り当てを提供できます。ACL が照合できる属性には、パケットペイロード内のポート、プロトコル、TCP フラグ、宛先アドレス、送信元の国、および任意のパターンが含まれます。
+ **疑惑のスコアリング** — これにより、Shield が期待するトラフィックに関する知識を使用して、すべてのパケットにスコアを適用されます。既知の正常なトラフィックのパターンに近いパケットには、より低い疑惑スコアが割り当てられます。既知の不良トラフィック属性を観察すると、パケットの疑惑スコアが高まる可能性があります。レート制限パケットが必要な場合、Shield は疑惑スコアが高いパケットからドロップします。これは、Shield が誤検知を回避しながら、既知の DDoS 攻撃とゼロデイ攻撃の両方を軽減するのに役立ちます。
+ **TCP SYN プロキシ** — これにより、TCP SYN Cookie が保護されたサービスに渡すのを許可する前に新しい接続に挑戦するために TCP SYN Cookie を送信することで、TCP SYN フラッドに対する保護が提供されます。Shield DDoS 緩和によって提供される TCP SYN プロキシはステートレスであり、ステートを使い果たすことなく、既知の最大の TCP SYN フラッド攻撃を軽減できます。これは、クライアントと保護された AWS サービスの間で継続的なプロキシを維持するのではなく、 サービスと統合して接続状態を渡すことによって実現されます。TCP SYN プロキシは、現在 Amazon CloudFront と Amazon Route 53 で利用できます。
+ **レートの分布** — これにより、保護されたリソースへのトラフィックの入力パターンに基づいて、ロケーションシェーパーの値を継続的に調整します。これにより、 AWS ネットワークに均等に入らない可能性のある顧客トラフィックのレート制限を防ぐことができます。
# AWS Shield CloudFront と Route 53 の緩和ロジック
このページでは、Shield DDoS 緩和が Cloud Front および Route 53 のトラフィックを継続的に検査する仕組みについて説明します。これらのサービスは、 AWS エッジロケーションのグローバルに分散されたネットワークから動作し、Shield の DDoS 緩和容量への広範なアクセスを提供し、エンドユーザーに近いインフラストラクチャからアプリケーションを提供します。
**重要**
AWS Shield Advanced は CloudFront テナントをサポートしていません。
+ **CloudFront** — Shield DDoS 緩和では、Web アプリケーションがサービスへのパススルーに有効なトラフィックのみを許可します。これにより、UDP リフレクション攻撃など、多くの一般的な DDoS ベクトルに対して自動的に保護されます。
CloudFront はアプリケーションオリジンへの永続的な接続を維持し、Shield TCP SYN プロキシ機能との統合によって TCP SYN フラッドが自動的に緩和され、Transport Layer Security (TLS) はエッジで終了します。これらの機能を組み合わせることで、アプリケーションオリジンは整形式のウェブリクエストのみを受信し、下位層の DDoS 攻撃、接続フラッド、および TLS 不正使用から保護されます。
CloudFront は DNS トラフィック方向とエニーキャストルーティングの組み合わせを使用します。これらの手法は、ソースに近い攻撃を緩和し、障害を分離し、容量へのアクセスを確保して既知の最大の攻撃を軽減することで、アプリケーションの復元力を向上させます。
+ **Route 53** — Shield 緩和では、有効な DNS リクエストのみがサービスに到達することを許可します。Shield は、既知の正常なクエリに優先順位を付け、疑わしいまたは既知の DDoS 攻撃属性を含むクエリの優先度を下げる、疑わしいスコアリングを使用して DNS クエリのフラッドを軽減します。
Route 53 は、シャッフルシャーディングを使用して、IPv4 と IPv6 の両方のホストゾーンに 4 つのリゾルバー IP アドレスの一意のセットを提供します。各 IP アドレスは、Route 53 ロケーションの異なるサブセットに対応します。各ロケーションサブセットは、他のサブセットのインフラストラクチャと部分的にしか重複しない権限を持つ DNS サーバーで構成されます。これにより、何らかの理由でユーザークエリが失敗した場合、再試行時に正常に処理されるようになります。
Route 53 は、エニーキャストルーティングを使用して、ネットワークの近接度に基づいて DNS クエリを最も近いエッジロケーションに送信します。エニーキャストはまた、DDoS トラフィックを多くのエッジロケーションにファンアウトし、攻撃が単一のロケーションに集中するのを防ぎます。
緩和の速度に加えて、CloudFront と Route 53 は Shield のグローバルに分散された容量への幅広いアクセスを提供します。これらの機能を活用するには、これらのサービスを動的または静的ウェブアプリケーションのエントリーポイントとして使用します。
CloudFront と Route 53 を使用してウェブアプリケーションを保護する方法の詳細については、「[How to Help Protect Dynamic Web Applications Against DDoS Attacks by Using Amazon CloudFront and Amazon Route 53](https://aws.amazon.com/blogs/security/how-to-protect-dynamic-web-applications-against-ddos-attacks-by-using-amazon-cloudfront-and-amazon-route-53/)」(Amazon CloudFront と Amazon Route 53 を使用して DDoS 攻撃から動的ウェブアプリケーションを保護する方法) を参照してください。Route 53 での障害分離の詳細については、「[グローバルフォールトアイソレーションのケーススタディ](https://aws.amazon.com/blogs/architecture/a-case-study-in-global-fault-isolation/)」を参照してください。
# AWS Shield AWS リージョンの緩和ロジック
このページでは、Shield イベント緩和ロジックが AWS リージョンでどのように機能するかについて説明します。
AWS リージョンで起動されるリソースは、Shield リソースレベル検出によって配置される AWS Shield DDoS 緩和システムによって保護されます。リージョンリソースには、Elastic IP (EIP)、クラシックロードバランサー、アプリケーションロードバランサーなどがあります。
緩和を実施する前に、Shield はターゲットリソースとその容量を特定します。Shield は、キャパシティを使用して、緩和がリソースに転送できる最大合計トラフィックを決定します。アクセスコントロールリスト（ACL）および緩和策内のその他のシェーパによって、既知の DDoS 攻撃ベクトルに一致するトラフィックや、大量の受信が予想されないトラフィックなど、一部のトラフィックで許可されるボリュームが減少する可能性があります。これにより、UDP リフレクション攻撃や TCP SYN フラグまたは FIN フラグを持つ TCP トラフィックに対して、緩和によって許可されるトラフィック量がさらに制限されます。
Shield は、リソースタイプごとにキャパシティを決定し、緩和を別々に配置します。
+ Amazon EC2 インスタンス、または Amazon EC2 インスタンスにアタッチされている EIP の場合、Shield はインスタンスタイプおよびその他のインスタンス属性 (インスタンスで拡張ネットワーキングが有効になっているかどうかなど) に基づいて容量を計算します。
+ Application Load Balancer または Classic Load Balancer の場合、Shield はロードバランサーのターゲットノードごとに個別に容量を計算します。これらのリソースに対する DDoS 攻撃の緩和は、Shield DDoS 緩和とロードバランサーによる自動スケーリングの組み合わせによって提供されます。Shield Response Team (SRT) がApplication Load Balancer またはClassic Load Balancer のリソースに対する攻撃に従事している場合、追加の保護対策としてスケーリングを加速する可能性があります。
+ Shield は、基盤となる AWS インフラストラクチャの使用可能な容量に基づいて、一部の AWS リソースの容量を計算します。これらのリソースタイプには、Network Load Balancer (NLBsと、Gateway Load Balancer または を介してトラフィックをルーティングするリソースが含まれます AWS Network Firewall。
**注記**
Shield Advanced で保護されている EIP をアタッチして、ネットワークロードバランサーを保護します。SRT と連携して、基盤となるアプリケーションの予想されるトラフィックと容量に基づくカスタム緩和を構築できます。
Shield が緩和策を設定すると、Shield が緩和ロジックで定義した初期レート制限が、すべての Shield DDoS 緩和システムに等しく適用されます。たとえば、Shield が 100,000 パケット/秒 (pps) の制限で緩和を設定した場合、最初はすべてのロケーションで 100,000 pps を許可します。次に、Shield は継続的に緩和メトリクスを集約してトラフィックの実際の比率を決定し、その比率を使用して各ロケーションのレート制限を調整します。これにより、誤検出を防ぎ、緩和が過度に許容されないようにします。
# AWS Shield AWS Global Accelerator 標準アクセラレーターの緩和ロジック
このページでは、Shield イベント緩和ロジックが AWS Global Accelerator 標準アクセラレーターでどのように機能するかについて説明します。Shield 緩和は、有効なトラフィックがグローバルアクセラレータの標準アクセラレータのリスナーエンドポイントに到達することのみを許可します。
標準アクセラレーターはグローバルにデプロイされ、任意の AWS リージョンの AWS リソースにトラフィックをルーティングするために使用できる IP アドレスを提供します。Shield が Global Accelerator への緩和に対して適用するレート制限は、標準アクセラレータがトラフィックをルーティングするリソースの容量に基づいています。Shield は、総トラフィックが決められたレートを超えたとき、および既知の DDoS ベクトルに対してそのレートの割合を超えた場合に、緩和を実行します。
標準アクセラレータを設定するときは、アプリケーションのトラフィックをルーティングする AWS リージョンごとにエンドポイントグループを定義します。Shield が緩和策を設定すると、各エンドポイントグループの容量が計算され、それに応じて各 Shield DDoS 緩和システムのレート制限が更新されます。レートは、トラフィックがインターネットから AWS リソースにルーティングされる方法について Shield が行った仮定に基づいて、場所によって異なります。エンドポイントグループのキャパシティは、グループ内のリソースの数に、グループ内の任意のリソースの最小容量を乗じて計算されます。一定の間隔で、Shield はアプリケーションの容量を再計算し、必要に応じてレート制限を更新します。
**注記**
トラフィックダイヤルを使用してエンドポイントグループに誘導されるトラフィックの割合を変更しても、Shield DDoS 軽減システムに対してレート制限を計算または配布する方法は変わりません。トラフィックダイヤルを使用する場合は、リソースタイプと数量について相互にミラーリングするようにエンドポイントグループを構成します。これにより、Shield によって計算されたキャパシティが、アプリケーションのトラフィックを処理しているリソースを代表するようにできます。
Global Accelerator のエンドポイントグループとトラフィックダイヤルの詳細については、「[AWS Global Accelerator 標準アクセラレーター](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoint-groups.html)のエンドポイントグループ」を参照してください。
# AWS Shield Advanced Elastic IPs の緩和ロジック
このページでは、 で Shield イベント緩和ロジックが Elastic IPs に対してどのように機能するかについて説明します AWS Shield Advanced。で Elastic IP (EIP) を保護すると AWS Shield Advanced、Shield Advanced は Shield が DDoS イベント中に導入する緩和策を強化します。
Shield Advanced DDoS 緩和システムは、EIP が関連付けられているパブリックサブネットのネットワーク ACL (NACL) 設定を複製します。たとえば、NACL がすべての UDP トラフィックをブロックするように設定されている場合、Shield Advanced はそのルールを Shield が配置する緩和にマージします。
この追加機能は、アプリケーションに対して有効ではないトラフィックによる可用性リスクを回避するのに役立ちます。NACL を使用して、個々の送信元 IP アドレスまたは送信元 IP アドレス CIDR 範囲をブロックすることもできます。これは、分散されていない DDoS 攻撃の緩和ツールとして役立ちます。また、 AWS エンジニアの介入に頼ることなく、独自の許可リストを簡単に管理したり、アプリケーションと通信すべきではない IP アドレスをブロックしたりできます。
# AWS Shield Advanced ウェブアプリケーションの緩和ロジック
AWS Shield Advanced は AWS WAF を使用してウェブアプリケーションレイヤー攻撃を軽減します。 AWS WAF は、追加コストなしで Shield Advanced に含まれています。
**アプリケーションレイヤー標準保護**
Amazon CloudFront ディストリビューションまたは Application Load Balancer を Shield Advanced で保護する場合、Shield Advanced を使用して AWS WAF ウェブ ACL を保護されたリソースにまだ関連付けていない場合は、関連付けることができます。ウェブ ACL をまだ設定していない場合は、Shield Advanced コンソールウィザードを使用して作成して、レートベースのルールを追加できます。レートベースのルールは、各 IP アドレスの 5 分間の時間枠あたりの要求数を制限し、ウェブアプリケーション層のリクエストのフラッドに対する基本的な保護を提供します。レートは 10 から設定できます。詳細については、「[AWS WAF ウェブ ACLs と Shield Advanced によるアプリケーションレイヤーの保護](ddos-app-layer-web-ACL-and-rbr.md)」を参照してください。
AWS WAF サービスを使用してウェブ ACL を管理することもできます。を通じて AWS WAF、ウェブ ACL 設定を拡張して、特定のウェブリクエストコンポーネントの文字列一致やパターンの検査、カスタムリクエストとレスポンスの処理の追加、リクエストオリジンの位置情報との照合などを行うことができます。 AWS WAF ルールの詳細については、「」を参照してください[AWS WAF ルール](waf-rules.md)。
**アプリケーションレイヤーの自動緩和**
保護を強化するには、Shield Advanced アプリケーションレイヤーの自動緩和を有効にします。このオプションを使用すると、Shield Advanced は既知の DDoS ソースからのリクエストの AWS WAF レート制限ルールを維持し、検出された DDoS 攻撃のカスタム緩和を提供します。
Shield Advanced は、保護されたリソースに対する攻撃を検出すると、アプリケーションへの通常のトラフィックから攻撃トラフィックを分離する攻撃シグネチャの特定を試みます。Shield Advanced は、識別された攻撃シグネチャを攻撃対象のリソースおよび同じウェブ ACL に関連付けられている他のリソースについての過去のトラフィックパターンに照らして評価します。
Shield Advanced は、攻撃シグネチャが DDoS 攻撃に関与しているトラフィックのみを分離していると判断した場合、関連付けられたウェブ ACL 内の AWS WAF ルールにシグネチャを実装します。Shield Advanced に、一致したトラフィックのみをカウントする、またはブロックする緩和を配置するように指示できます。この設定はいつでも変更できます。Shield Advanced は、緩和ルールが不要になったと判断すると、そのルールをウェブ ACL から削除します。アプリケーションレイヤーイベントの緩和の詳細については、「[Shield Advanced によるアプリケーションレイヤー DDoS 自動緩和](ddos-automatic-app-layer-response.md)」を参照してください。
Shield Advanced アプリケーションレイヤー の緩和の詳細については、「[AWS Shield Advanced および を使用したアプリケーションレイヤー (レイヤー 7) の保護 AWS WAF](ddos-app-layer-protections.md)」を参照してください。
# Shield Advanced を使用した基本的な DDoS 耐障害性アーキテクチャの構築
このページでは、分散型サービス拒否 (DDoS) の障害耐性について説明し、2 つのアーキテクチャ例を紹介します。
DDoS 耐障害性とは、正規ユーザーに引き続きサービスを提供しながら、分散型サービス拒否 (DDoS) 攻撃に耐えるアプリケーションアーキテクチャの機能です。高い耐障害性を持つアプリケーションは、エラーやレイテンシーなどのパフォーマンスメトリクスへの影響を最小限に抑えながら、攻撃を受けている最中も引き続き利用可能な状態を維持できます。このセクションでは、いくつかの一般的なアーキテクチャの例を示し、 AWS および Shield Advanced によって提供される DDoS 検出および緩和機能を使用して DDoS レジリエンシーを高める方法について説明します。
このセクションのアーキテクチャの例では、デプロイされたアプリケーションに DDoS レジリエンシーの最大のメリットを提供する AWS のサービスに焦点を当てています。主なサービスには、次のようなメリットがあります。
+ **グローバルに分散されたネットワーク容量へのアクセス** – Amazon CloudFront、および Amazon Route 53 のサービスにより AWS Global Accelerator、 AWS グローバルエッジネットワーク全体のインターネットおよび DDoS 緩和容量にアクセスできます。これは、大規模にテラビットに達する可能性がある、比較的大きなボリューム攻撃を緩和するのに有益です。アプリケーションを任意の AWS リージョンで実行し、これらのサービスを使用して可用性を保護し、正当なユーザーのパフォーマンスを最適化できます。
+ **ウェブアプリケーションレイヤーの DDoS 攻撃のベクトルに対する保護** – ウェブアプリケーションレイヤーの DDoS 攻撃は、アプリケーションのスケールとウェブアプリケーションファイアウォール (WAF) の組み合わせを使用することによって最も効果的に緩和されます。Shield Advanced は、 からのウェブリクエスト検査ログ AWS WAF を使用して、自動で、または Shield Response Team (SRT) とのエンゲージメントを通じて軽減できる異常を検出します AWS 。自動緩和は、デプロイされた AWS WAF レートベースのルールと、Shield Advanced アプリケーションレイヤー DDoS 自動緩和を通じて利用できます。
これらの例を確認することに加えて、「[AWS Best Practices for DDoS Resiliency](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency)」(DDoS レジリエンシーに関するのベストプラクティス) で該当するベストプラクティスを確認し、それに従います。
**Topics**
+ [一般的なウェブアプリケーションの Shield Advanced DDoS 耐障害性アーキテクチャの例](ddos-resiliency-example-web.md)
+ [TCP および UDP アプリケーションの Shield Advanced DDoS 耐障害性アーキテクチャの例](ddos-resiliency-example-tcp-udp.md)
# 一般的なウェブアプリケーションの Shield Advanced DDoS 耐障害性アーキテクチャの例
このページでは、 AWS ウェブアプリケーションによる DDoS 攻撃に対する耐障害性を最大化するためのアーキテクチャの例を示します。
任意の AWS リージョンにウェブアプリケーションを構築し、リージョンで AWS が提供する検出および緩和機能から DDoS 自動保護を受けることができます。
この例は、Classic Load Balancer、Application Load Balancer、Network Load Balancer、 AWS Marketplace ソリューション、または独自のプロキシレイヤーなどのリソースを使用して、エンドユーザーをウェブアプリケーションにルーティングするアーキテクチャ向けです。これらの AWS WAF ウェブアプリケーションリソースとユーザーの間に Amazon Route 53 ホストゾーン、Amazon CloudFront ディストリビューション、ウェブ ACLs を挿入することで、DDoS の耐障害性を向上させることができます。これらの挿入により、アプリケーションのオリジンが難読化され、エンドユーザーにより近いリクエストを処理し、アプリケーションレイヤーのリクエストのフラッドを検出して緩和できます。CloudFront および Route 53 を使用してエンドユーザーに静的または動的コンテンツを提供するアプリケーションは、インフラストラクチャレイヤー攻撃をリアルタイムで緩和する、統合された完全インライン DDoS 緩和システムによって保護されます。
これらのアーキテクチャの改善を実施することにより、Shield Advanced を使用して Route 53 ホストゾーンと CloudFront ディストリビューションを保護できます。CloudFront ディストリビューションを保護すると、Shield Advanced は AWS WAF ウェブ ACLs関連付けてレートベースのルールを作成するように求め、アプリケーションレイヤー DDoS 自動緩和またはプロアクティブエンゲージメントを有効にするオプションを提供します。プロアクティブなエンゲージメントとアプリケーションレイヤー DDoS 自動緩和では、リソースに関連付ける Route 53 ヘルスチェックを使用します。これらのオプションの詳細については、「[でのリソース保護 AWS Shield Advanced](ddos-resource-protections.md)」を参照してください。
次の参照図は、ウェブアプリケーション用のこの DDoS 回復アーキテクチャを示しています。
![\[この図には「AWS cloud」というタイトルの長方形が示されており、左側にユーザーのグループがあります。クラウドの長方形の内側には、他の 2 つの長方形が隣り合っています。左側の長方形には AWS Shield Advanced というタイトルが付けられており、右側の長方形には VPC というタイトルが付けられています。左側の AWS Shield Advanced 三角形には、垂直に積み上げられた 3 つの AWS アイコンがあります。上から下まで、アイコンは Amazon Route 53、Amazon CloudFront、および です AWS WAF。CloudFront のアイコンには、 AWS WAFのアイコンとの間に双方向の矢印があります。ユーザーグループには、右に向かって水平に伸びる矢印があり、分岐して、Route 53 と CloudFront のアイコンを指しています。Shield Advanced の長方形の右側にある VPC の長方形には、隣り合っている 2 つのアイコンが含まれています。これらのアイコンは、左が Elastic Load Balancing、右が Amazon Elastic Compute Cloud です。CloudFront アイコンには、右側に向けて水平に突き出ている矢印があり、Elastic Load Balancing アイコンにつながっています。Elastic Load Balancing アイコンには、右側に向けて水平に突き出ている矢印があり、Amazon EC2 アイコンにつながっています。そのため、ユーザーリクエストは Route 53 と CloudFront に送信されます。CloudFront は、 AWS WAF とインタラクションし、ロードバランサーにリクエストを送信します。ロードバランサーは、Amazon EC2 にリクエストを送信します。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/shield-resilient-web-app-arch.png)
このアプローチがウェブアプリケーションに提供するメリットには、次のものがあります。
+ 頻繁に使用されるインフラストラクチャレイヤー (レイヤー 3 およびレイヤー 4) の DDoS 攻撃に対する保護。検出の遅延はありません。さらに、リソースが頻繁にターゲットになっている場合、Shield Advanced はより長期にわたって緩和策を実施します。また、Shield Advanced は、Network ACL (NACL) から推測されるアプリケーションコンテキストを使用して、望ましくないトラフィックがさらにアップストリームするのをブロックします。これにより、ソースにより近い障害を隔離でき、正当なエンドユーザーへの影響が最小限に抑えられます。
+ TCP SYN フラッドに対する保護。CloudFront、Route 53、 と統合された DDoS 緩和システムは、新しい接続試行にチャレンジし、正当なユーザーのみを提供する TCP SYN プロキシ機能 AWS Global Accelerator を提供します。
+ DNS アプリケーションレイヤー攻撃に対する保護 (Route 53 は権威 DNS レスポンスを処理する責任があるため)。
+ ウェブアプリケーションレイヤーリクエストのフラッドに対する保護。 AWS WAF ウェブ ACL で設定したレートベースのルールは、ルールで許可されているよりも多くのリクエストを送信するときにソース IPs をブロックします。
+ CloudFront ディストリビューションのアプリケーションレイヤー DDoS 自動緩和機能 (このオプションを有効にした場合)。自動 DDoS 緩和により、Shield Advanced は、既知の DDoS ソースからのリクエストの量を制限するレートベースのルールをディストリビューションに関連付けられた AWS WAF ウェブ ACL に維持します。さらに、Shield Advanced は、アプリケーションのヘルスに影響を及ぼすイベントを検出すると、ウェブ ACL の緩和ルールを自動的に作成、テスト、および管理します。
+ Shield Response Team (SRT) とのプロアクティブなエンゲージメント (このオプションを有効にした場合)。Shield Advanced がアプリケーションのヘルスに影響を与えるイベントを検出すると、SRT は、提供された連絡先情報を使用して、お客様のセキュリティチームまたはオペレーションチームとプロアクティブに対応します。SRT はトラフィックのパターンを分析し、 AWS WAF ルールを更新して攻撃をブロックできます。
# TCP および UDP アプリケーションの Shield Advanced DDoS 耐障害性アーキテクチャの例
この例は、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスまたは Elastic IP (EIP) アドレスを使用する AWS リージョンの TCP および UDP アプリケーション向けの DDoS に対する耐性の高いアーキテクチャを示しています。
この一般的な例に従って、次のアプリケーションタイプの DDoS レジリエンシーを改善できます。
+ TCP または UDP アプリケーション。ゲーム、IoT、およびボイスオーバー IP に使用されるアプリケーションはその一例です。
+ 静的 IP アドレスを必要とするウェブアプリケーション、または Amazon CloudFront がサポートしていないプロトコルを使用するウェブアプリケーション。たとえば、アプリケーションでは、ユーザーがファイアウォール許可リストに追加でき、他の AWS お客様が使用していない IP アドレスが必要になる場合があります。
Amazon Route 53 および AWS Global Acceleratorを導入することで、これらのアプリケーションタイプの DDoS レジリエンシーを改善できます。これらのサービスは、エンドユーザーをアプリケーションにルーティングでき、 AWS グローバルエッジネットワークを介してルーティングされるエニーキャストである静的 IP アドレスをアプリケーションに提供できます。Global Accelerator 標準アクセラレーターは、エンドユーザーのレイテンシーを最大 60% 改善できます。ウェブアプリケーションがある場合は、Application Load Balancer でアプリケーションを実行し、ウェブ ACL で Application Load Balancer を保護することで、 AWS WAF ウェブアプリケーションレイヤーリクエストのフラッドを検出して軽減できます。
アプリケーションの構築後、Shield Advanced を使用して、Route 53 ホストゾーン、Global Accelerator 標準アクセラレーター、および Application Load Balancer を保護します。Application Load Balancer を保護するときは、 AWS WAF ウェブ ACLs関連付けてレートベースのルールを作成できます。新規または既存の Route 53 ヘルスチェックを関連付けることで、Global Accelerator 標準アクセラレーターと Application Load Balancerの両方のために、SRT とのプロアクティブエンゲージメントを設定できます。オプションの詳細については、「[でのリソース保護 AWS Shield Advanced](ddos-resource-protections.md)」を参照してください。
次の図は、TCP および UDP アプリケーションの DDoS に対する耐性が高いアーキテクチャの例を示しています。
![\[この図は、Route 53 と に接続されているユーザーを示しています AWS Global Accelerator。アクセラレーターは、 AWS Shield Advanced と で保護されている Elastic Load Balancing アイコンに接続されています AWS WAF。伸縮性ロードバランサーは、それ自体が Amazon EC2 インスタンスに接続されています。この伸縮性ロードバランサーインスタンスと Amazon EC2 インスタンスはリージョン 1 にあります。 AWS Global Accelerator は、保護された Elastic Load Balancing インスタンスの背後にあるものではない別の Amazon EC2 インスタンスにも直接接続されます。この 2 つ目の Amazon EC2 インスタンスはリージョン n にあります。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/shield-resilient-tcp-udp-app-arch.png)
このアプローチがアプリケーションに提供するメリットには、次のものがあります。
+ 最大の既知のインフラストラクチャレイヤー (レイヤー 3 およびレイヤー 4) の DDoS 攻撃に対する保護。攻撃の量によって の上流で輻輳が発生した場合 AWS、障害はソースの近くで分離され、正当なユーザーへの影響は最小限に抑えられます。
+ DNS アプリケーションレイヤー攻撃に対する保護 (Route 53 は権威 DNS レスポンスを処理する責任があるため)。
+ ウェブアプリケーションがある場合、このアプローチはウェブアプリケーションレイヤーのリクエストのフラッドに対する保護を提供します。 AWS WAF ウェブ ACL で設定したレートベースのルールは、ルールで許可されているよりも多くのリクエストを送信している間、ソース IPs をブロックします。
+ Shield Response Team (SRT) とのプロアクティブなエンゲージメント (対象リソースのためにこのオプションを有効にした場合)。Shield Advanced がアプリケーションのヘルスに影響を与えるイベントを検出すると、SRT は、提供された連絡先情報を使用して、お客様のセキュリティチームまたはオペレーションチームとプロアクティブに対応します。
# Shield Advanced と他の の組み合わせ AWS のサービス
Shield Advanced を使用すると、さまざまなシナリオでリソースを保護できます。ただし、場合によっては、他のサービスを使用するか、他のサービスと Shield Advanced を組み合わせて最高の保護を提供する必要があります。以下は、Shield Advanced または他の AWS のサービスを使用してリソースを保護する方法の例です。
| 目標 | 推奨するサービス | 関連サービスドキュメント |
| --- | --- | --- |
| DDoS 攻撃からウェブアプリケーションと RESTful API を保護する | Amazon CloudFront ディストリビューションと Application Load Balancer を保護する Shield Advanced | [Elastic Load Balancing ドキュメント](https://docs.aws.amazon.com/elasticloadbalancing/)、[Amazon CloudFront ドキュメント](https://docs.aws.amazon.com/cloudfront/) |
| DDoS 攻撃から TCP ベースのアプリケーションを保護する | AWS Global Accelerator 標準アクセラレーターを保護する Shield Advanced、Elastic IP アドレスにアタッチ | [AWS Global Accelerator ドキュメント](https://docs.aws.amazon.com/global-accelerator/)、[Elastic Load Balancing ドキュメント](https://docs.aws.amazon.com/elasticloadbalancing/) |
| DDoS 攻撃から UDP ベースのゲームサーバーを保護する | Elastic IP アドレスにアタッチされた Amazon EC2 インスタンスを保護する Shield Advanced | [Amazon Elastic Compute Cloud のドキュメント](https://docs.aws.amazon.com/ec2/) |
例えば、Shield Advanced を使用して Elastic IP アドレスを保護する場合、Shield Advanced はそれに関連付けられているすべてのリソースを保護します。攻撃中、Shield Advanced はネットワーク ACLsを AWS ネットワークの境界に自動的にデプロイします。ネットワーク ACL がネットワークの境界にある場合、Shield Advanced はより大きな DDoS イベントに対する保護を提供できます。通常、ネットワーク ACL は Amazon VPC 内の Amazon EC2 インスタンスの近くで適用されます。ネットワーク ACL は、Amazon VPC とインスタンスが処理できるだけの大きさの攻撃を緩和できます。Amazon EC2 インスタンスにアタッチされたネットワークインターフェイスが最大 10 Gbps を処理できる場合、10 Gbps を超えるボリュームは遅くなり、そのインスタンスへのトラフィックがブロックされる可能性があります。攻撃を受けている最中に、Shield Advanced はネットワーク ACL を AWS 境界に昇格させ、数テラバイトのトラフィックを処理できます。ネットワーク ACL は、典型的なネットワークの容量を超えてリソースを十分に保護することができます。ネットワーク ACL の詳細については、「[ネットワーク ACL](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html)」を参照してください。
# セットアップ AWS Shield Advanced
このチュートリアルでは、Shield Advanced コンソール AWS Shield Advanced を使用した の開始方法について説明します。
**注記**
Shield Advanced にはサブスクリプションが必要ですが、そう AWS Shield Standard ではありません。Shield Standard で提供される保護は、すべての AWS のお客様に無料でご利用いただけます。
Shield Advanced では、ネットワークレイヤー (レイヤー 3)、トランスポートレイヤー (レイヤー 4)、およびアプリケーションレイヤー (レイヤー 7) 攻撃に対して、高度な DDoS 検出、緩和、保護が可能です。Shield Advanced の詳細については、「[AWS Shield Advanced の概要](ddos-advanced-summary.md)」を参照してください。
AWS 技術コミュニティは、Infrastructure as Code (IaC) ツール AWS CloudFormation と Terraform を使用して Shield Advanced を設定するための自動プロセスの例を公開しました。アカウントが の組織の一部であり AWS Organizations 、Amazon Route 53 または 以外のリソースタイプを保護している場合は、このソリューション AWS Firewall Manager で を使用できます AWS Global Accelerator。このオプションの詳細については、「[aws-samples / aws-shield-advanced-one-click-deployment](https://github.com/aws-samples/aws-shield-advanced-one-click-deployment)」のコードリポジトリと「[Shield Advanced のワンクリックデプロイ](https://youtu.be/LCA3FwMk_QE)」のチュートリアルを参照してください。
**注記**
Distributed Denial of Service (DDoS) イベントが発生する前に Shield Advanced の設定を完了することが重要です。設定を完了すると、アプリケーションが保護され、アプリケーションが DDoS 攻撃の影響を受けた場合に対応する準備ができているようにします。
Shield Advanced の使用を開始するには、次の手順を順番に実行します。
**Contents**
+ [へのサブスクライブ AWS Shield Advanced](enable-ddos-prem.md)
+ [Shield Advanced を使用したリソース保護の追加と設定](ddos-choose-resources.md)
+ [を使用したアプリケーションレイヤー (レイヤー 7) DDoS 保護の設定 AWS WAF](ddos-get-started-web-acl-rbr.md)
+ [Shield Advanced と Route 53 による保護のためのヘルスベースの検出の設定](ddos-get-started-health-checks.md)
+ [Shield Advanced と Amazon SNS を使用したアラームと通知の設定](ddos-get-started-create-alarms.md)
+ [Shield Advanced で保護構成の確認および終了](ddos-get-started-review-and-configure.md)
+ [DDoS AWS イベントレスポンスの Shield Response Team (SRT) サポートの設定](authorize-srt.md)
+ [CloudWatch で DDoS ダッシュボードを作成し、CloudWatch アラームを設定する](deploy-waf-dashboard.md)
# へのサブスクライブ AWS Shield Advanced
このページでは、Shield Advanced にアカウントをサブスクライブし、サービスの使用を開始する方法について説明します。
保護 AWS アカウント する ごとに Shield Advanced をサブスクライブする必要があります。Shield Standard に登録する必要はありません。
**Shield Advanced サブスクリプションの請求**
AWS チャネルリセラーの場合は、アカウントチームに情報とガイダンスを求めてください。この請求情報は、 AWS チャネルリセラーではないお客様を対象としています。
他のすべてについては、次のサブスクリプションと請求のガイドラインが適用されます。
+ AWS Organizations 組織のメンバーであるアカウントの場合、 は、支払者アカウント自体がサブスクライブされているかどうかにかかわらず、組織の支払者アカウントに対して Shield Advanced サブスクリプションを AWS 請求します。
+ 同じ [AWS Organizations 一括請求 (コンソリデーティッドビリング) アカウントファミリー](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) に属する複数のアカウントをサブスクライブする場合、1 つのサブスクリプション料金はファミリー内のすべてのサブスクライブアカウントに対するものです。組織は、すべての AWS アカウント とそのすべてのリソースを所有している必要があります。
+ 複数の組織のために複数のアカウントをサブスクライブする場合でも、すべてを所有しているのであれば、すべての組織、アカウント、リソースのサブスクリプション料金の支払いを引き続き 1 回で行うことができます。アカウントマネージャーまたは AWS サポートに連絡して、組織の 1 つを除くすべての AWS Shield Advanced サブスクリプション料金の免除をリクエストしてください。
詳細な料金情報と例については、「[AWS Shield の料金表](https://aws.amazon.com/shield/pricing/)」を参照してください。
**でサブスクリプションを簡素化することを検討する AWS Firewall Manager**
アカウントが組織の一部である場合は、できればその組織のサブスクリプションと保護を自動化するために AWS Firewall Manager を使用することをおすすめします。Firewall Manager は、Amazon Route 53 および AWS Global Acceleratorを除くすべての保護されたリソースタイプをサポートします。Firewall Manager を使用するには、「[AWS Firewall Manager](fms-chapter.md)」と「[AWS Firewall Manager AWS Shield Advanced ポリシーの設定](getting-started-fms-shield.md)」を参照してください。
Firewall Manager を使用しない場合は、保護するリソースを持つアカウントごとに、次の手順を使用してサブスクライブし、保護を追加します。
**アカウントを にサブスクライブするには AWS Shield Advanced**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/) で AWS WAF & Shield コンソールを開きます。
1. **AWS Shield** ナビゲーションバーで、**[Getting started]** (はじめに) を選択します。**[Subscribe to Shield Advanced]** (Shield Advanced をサブスクライブ) を選択します。
1. **[Subscribe to Shield Advanced]** (Shield Advanced をサブスクライブ) ページで、契約の各条件を読み、条件を承諾する意思を表示するために、すべてのチェックボックスを選択します。一括請求 (コンソリデーティッドビリング) ファミリーのアカウントについては、各アカウントの条件に同意する必要があります。
**重要**
サブスクライブされている場合、サブスクライブを解除するには、[AWS サポート](https://console.aws.amazon.com/support) に連絡する必要があります。
サブスクリプションの自動更新を無効にするには、Shield API オペレーション [UpdateSubscription](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_UpdateSubscription.html) または CLI コマンド [update-subscription](https://docs.aws.amazon.com/cli/latest/reference/shield/update-subscription.html) を使用する必要があります。
**[Subscribe to Shield Advanced]** (Shield Advanced をサブスクライブ) を選択します。これにより、アカウントが Shield Advanced にサブスクライブされ、サービスが有効になります。
お客様のアカウントはサブスクライブされています。次のステップを続行して、Shield Advanced でアカウントのリソースを保護します。
**注記**
サブスクライブ後、Shield Advanced はリソースを自動的に保護しません。Shield Advanced で保護するリソースを指定する必要があります。
# Shield Advanced を使用したリソース保護の追加と設定
このページでは、リソースの保護を追加および設定する手順を説明します。
Shield Advanced は、Shield Advanced を通じて、または Firewall Manager Shield Advanced ポリシーで指定したリソースのみを保護します。サブスクライブアカウントのリソースは自動的に保護されません。
**注記**
保護に Shield Advanced AWS Firewall Manager ポリシーを使用する場合は、このステップを実行する必要はありません。保護するリソースタイプを指定してポリシーを設定すると、Firewall Manager はポリシーの範囲内にあるリソースに自動的に保護を追加します。
Firewall Manager を使用しない場合は、保護するリソースを持つアカウントごとに次の手順を実行します。
**Shield Advanced を使用して保護するリソースを選択するには**
1. 前の手順のサブスクリプション確認ページから、または **[Protected resources]** (保護されたリソース) または **[Overview]** (概要) ページから、**[Add resources to protect]** (保護するリソースを追加) を選択します。
1. **[Choose resources to protect with Shield Advanced]** (Shield Advanced で保護するリソースの選択) ページの **[Specify the Region and resource types]** (リージョンとリソースタイプの指定) で、保護するリソースのリージョンとリソースタイプの仕様を指定します。**[All Regions]** (すべてのリージョン) を選択すると複数のリージョンのリソースを保護でき、**[Global]** (グローバル) を選択すると選択範囲をグローバルリソースに絞り込むことができます。保護しないリソースタイプは、すべて選択解除できます。リソースタイプの保護については、「[が AWS Shield Advanced 保護するリソースのリスト](ddos-protections-by-resource-type.md)」を参照してください。
1. **[Load resources]** (リソースをロード) を選択します。Shield Advanced は、**[Select Resources]** (リソースの選択) セクションに条件に一致する AWS リソースを入力します。
1. **[Select Resources]** (リソースの選択) セクションでは、リソースリストで検索する文字列を入力して、リソースのリストをフィルタリングできます。
保護するリソースを選択します。
1. 作成しようとしている Shield Advanced 保護にタグを追加する場合は、**[Tags]** (タグ) セクションでそれらを指定します。 AWS リソースのタグ付けの詳細については、「[タグエディタの使用](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html)」を参照してください。
1. **[Protect with Shield Advanced]** (Shield Advanced で保護) を選択します。これにより、Shield Advanced 保護がリソースに追加されます。
コンソールウィザードの画面を続行して、リソース保護の設定を完了します。
**Topics**
+ [を使用したアプリケーションレイヤー (レイヤー 7) DDoS 保護の設定 AWS WAF](ddos-get-started-web-acl-rbr.md)
+ [Shield Advanced と Route 53 による保護のためのヘルスベースの検出の設定](ddos-get-started-health-checks.md)
+ [Shield Advanced と Amazon SNS を使用したアラームと通知の設定](ddos-get-started-create-alarms.md)
+ [Shield Advanced で保護構成の確認および終了](ddos-get-started-review-and-configure.md)
# を使用したアプリケーションレイヤー (レイヤー 7) DDoS 保護の設定 AWS WAF
このページでは、 AWS WAF ウェブ ACLs でアプリケーションレイヤー保護を設定する手順について説明します。
アプリケーションレイヤーリソースを保護するために、Shield Advanced はレートベースのルールを持つ AWS WAF ウェブ ACL を出発点として使用します。 AWS WAF は、アプリケーションレイヤーリソースに転送される HTTP および HTTPS リクエストをモニタリングし、リクエストの特性に基づいてコンテンツへのアクセスを制御できるウェブアプリケーションファイアウォールです。レートベースのルールは、リクエスト集約条件に基づいてトラフィックの量を制限し、アプリケーションに基本的な DDoS 防御を提供します。詳細については、「[の AWS WAF 仕組み](how-aws-waf-works.md)」および「[でのレートベースのルールステートメントの使用 AWS WAF](waf-rule-statement-type-rate-based.md)」を参照してください。
また、オプションで Shield Advanced の自動アプリケーションレイヤーの DDoS 談話を有効にして、既知の DDoS ソースから Shield Advanced レート制限リクエストを受け取り、インシデント固有の保護を自動的に提供することもできます。
**重要**
Shield Advanced ポリシー AWS Firewall Manager を使用して を通じて Shield Advanced 保護を管理する場合、ここではアプリケーションレイヤー保護を管理することはできません。Firewall Manager Shield Advanced ポリシーで管理する必要があります。
**Shield Advanced サブスクリプションと AWS WAF コスト**
Shield Advanced サブスクリプションは、Shield Advanced で保護するリソースに標準 AWS WAF 機能を使用するコストをカバーします。Shield Advanced 保護の対象となる標準 AWS WAF 料金は、保護パック (ウェブ ACL) あたりのコスト、ルールあたりのコスト、ウェブリクエスト検査の 100 万リクエストあたりの基本料金、最大 1,500 WCUs、デフォルトの本文サイズです。
Shield Advanced 自動アプリケーションレイヤー DDoS 緩和を有効にすると、150 個の保護パック (ウェブ ACL) キャパシティユニット (WCU) はルールグループに追加されます。これらの WCU は、保護パック (ウェブ ACL) 内の WCU の使用量に対してカウントされます。詳細については[Shield Advanced によるアプリケーションレイヤー DDoS 自動緩和](ddos-automatic-app-layer-response.md)、[Shield Advanced ルールグループによるアプリケーションレイヤーの保護](ddos-automatic-app-layer-response-rg.md)、および[のウェブ ACL キャパシティユニット (WCUs) AWS WAF](aws-waf-capacity-units.md)を参照してください。
Shield Advanced へのサブスクリプションは、Shield Advanced を使用して保護しないリソース AWS WAF の の使用には適用されません。また、保護されたリソースの標準以外の追加 AWS WAF コストもカバーしません。標準以外の AWS WAF コストの例としては、Bot Control、CAPTCHAルールアクション、1,500 WCUs を超えるウェブ ACLs、およびデフォルトの本文サイズを超えるリクエスト本文の検査などがあります。完全なリストは AWS WAF 料金ページに記載されています。Shield Advanced へのサブスクリプションには、 Layer 7 Anti-DDoS Amazon Managed Rule グループへのアクセスが含まれます。サブスクリプションの一環として、Shield Advanced で保護された AWS WAF リソースに対するリクエストは 1 か月あたり最大 500 億件になります。500 億を超えるリクエストは、 AWS Shield Advanced 料金表ページに従って請求されます。
詳細情報および料金の例については、「[Shield の料金](https://aws.amazon.com/shield/pricing/)」および「[AWS WAF の料金](https://aws.amazon.com/waf/pricing/)」を参照してください。
**リージョン用にレイヤー 7 DDoS 保護を設定するには**
Shield Advanced では、選択したリソースが配置されている各リージョンについて、レイヤー 7 DDoS 緩和策を設定するオプションを使用できます。複数のリージョンに保護を追加する場合、ウィザードはリージョンごとに次の手順を説明します。
1. **[Configure layer 7 DDoS protections]** (レイヤー 7 DDoS 保護の設定) ページには、ウェブ ACL にまだ関連付けられていない各リソースが一覧表示されます。これらのそれぞれについて、既存のウェブ ACL を選択するか、新しいウェブ ACL を作成します。ウェブ ACL が既に関連付けられているリソースについては、まず現在のウェブ ACL の関連付けを解除することでウェブ ACLs を変更できます AWS WAF。詳細については、「[AWS リソースとの保護の関連付けまたは関連付け解除](web-acl-associating-aws-resource.md)」を参照してください。
レートベースのルールがまだないウェブ ACL の場合、設定ウィザードでルールを追加するよう求められます。レートベースのルールは、大量のリクエストを送信している IP アドレスからのトラフィックを制限します。レートベースのルールは、ウェブリクエストのフラッドからアプリケーションを保護するのに役立つとともに、DDoS 攻撃の可能性を示していることがあるトラフィックの急増についてアラートを出すことができます。**[Add rate limit rule]** (レート制限ルールを追加) を選択し、レート制限とルールアクションを指定して、レートベースのルールをウェブ ACL に追加します。を介してウェブ ACL で追加の保護を設定できます AWS WAF。
レートベースのルールの追加設定オプションを含む、Shield Advanced 保護でのウェブ ACL およびレートベースのルールの使用方法については、「[AWS WAF ウェブ ACLs と Shield Advanced によるアプリケーションレイヤーの保護](ddos-app-layer-web-ACL-and-rbr.md)」を参照してください。
1. **自動アプリケーションレイヤー DDoS 緩和**では、Shield Advanced がアプリケーションレイヤーリソースに対する DDoS 攻撃を自動的に軽減する場合は、**有効化**を選択し、Shield Advanced がカスタム AWS WAF ルールで使用するルールアクションを選択します。この設定は、このウィザードセッションで管理しているリソースのすべてのウェブ ACL に適用されます。
アプリケーションレイヤー DDoS 自動緩和により、Shield Advanced は、既知の DDoS ソースからのリクエストの量を制限するレートベースのルールをリソースの AWS WAF ウェブ ACL に維持します。さらに、Shield Advanced は、現在のトラフィックパターンと過去のトラフィックベースラインを比較して、DDoS 攻撃を示している可能性のある逸脱を検出します。Shield Advanced が DDoS 攻撃を検出すると、応答するカスタム AWS WAF ルールを作成、評価、デプロイして応答します。カスタムルールが、ユーザーに代わって攻撃に対してカウントまたはブロックするかどうかを指定します。
**注記**
自動アプリケーションレイヤー DDoS 緩和は、最新バージョンの (v2) を使用して作成された保護パック AWS WAF (ウェブ ACLs) でのみ機能します。
この機能を使用するための注意点やベストプラクティスなど、Shield Advanced 自動アプリケーションレイヤー DDoS 緩和の詳細については、[Shield Advanced によるアプリケーションレイヤー DDoS 自動緩和](ddos-automatic-app-layer-response.md) を参照してください。
1. [**次へ**] を選択します。コンソールウィザードは、ヘルスベースの検出のページに進みます。
# Shield Advanced と Route 53 による保護のためのヘルスベースの検出の設定
このページでは、ヘルスベースの検出を使用するように Shield Advanced を設定する手順を説明します。これにより、攻撃の検出と緩和における応答性と精度を向上させることができます。
イベントを正確に検出するには、適切に設定されたヘルスチェックが不可欠です。Route 53 ホストゾーンを除くリソースタイプのために、ヘルスベースの検出を設定できます。
ヘルスベースの検出を使用するには、まず Route 53 でリソースのヘルスチェックを定義してから、ヘルスチェックを Shield Advanced の保護に関連する必要があります。設定するヘルスチェックがリソースの正常性を正確に反映していることが重要です。Shield Advanced で使用するヘルスチェックの設定に関する情報と例については、「[Shield Advanced と Route 53 を使用したヘルスチェックを使用したヘルスベースの検出](ddos-advanced-health-checks.md)」を参照してください。
Shield Response Team (SRT) のプロアクティブなエンゲージメントサポートには、ヘルスチェックが必要です。プロアクティブなエンゲージメントの詳細については、「[SRT が直接連絡するためのプロアクティブエンゲージメントの設定](ddos-srt-proactive-engagement.md)」を参照してください。
**注記**
ヘルスチェックを Shield Advanced 保護に関連付ける場合、正常であることが報告されている必要があります。
**ヘルスベースの検出を設定するには**
1. **[Associated Health Check]** (ヘルスチェックを関連付ける) で、保護に関連付けるヘルスチェックの ID を選択します。
**注記**
必要なヘルスチェックが表示されない場合は、Route 53 コンソールに移動して、ヘルスチェックとその ID を検証します。詳細については、「[ヘルスチェックの作成と更新](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html)」を参照してください。
1. **[Next]** (次へ) を選択します。コンソールウィザードは、アラームと通知のページに進みます。
# Shield Advanced と Amazon SNS を使用したアラームと通知の設定
このページでは、必要に応じて、検出された Amazon CloudWatch アラームとレートベースのルールアクティビティに対する Amazon Simple Notification Service 通知の設定について説明します。これらを使用すると、Shield が保護対象リソースでイベントを検出したとき、またはレートベースのルールで設定されたレート制限を超えたときに通知を受け取ることができます。
Shield Advanced CloudWatch のメトリクスについては、「[AWS Shield Advanced メトリクス](shield-metrics.md)」を参照してください。Amazon SNS の詳細については、「[Amazon Simple Notification Service デベロッパーガイド](https://docs.aws.amazon.com/sns/latest/dg/)」を参照してください。
**アラームと通知を設定するには**
1. 通知の対象となる Amazon SNS トピックを選択します。すべての保護されたリソースとレートベースのルールに単一の Amazon SNSトピックを使用することも、組織に合わせてカスタマイズされた異なるトピックを選択することもできます。例えば、特定のリソースセットのインシデント対応を担当するチームごとに SNS トピックを作成できます。
1. [**次へ**] を選択します。コンソールウィザードは、リソース保護の確認ページに進みます。
# Shield Advanced で保護構成の確認および終了
**設定を確認および終了するには**
1. **[Review and configure DDoS mitigation and visibility]** (DDoS の緩和と可視性を確認および設定) ページで、設定を確認します。変更するには、変更する部分で **[Edit]** (編集) を選択します。これにより、コンソールウィザードの関連するページに戻ります。変更を加えた後、**[Review and configure DDoS mitigation and visibility]** (DDoS の緩和と可視性を確認および設定) ページに戻るまで、後続のページで **[Next]** (次へ) を選択します。
1. **[Finish configuration]** (設定を終了) を選択します。**[Protected resources]** (保護されたリソース) ページには、新しく保護されたリソースが一覧表示されます。
# DDoS AWS イベントレスポンスの Shield Response Team (SRT) サポートの設定
このページでは、Shield Response Team (SRT) サポートを設定する手順について説明します。
SRT は DDoS イベントへの対応を専門とするセキュリティエンジニアの集団です。必要に応じて、DDoS イベント中に SRT がユーザーに代わってリソースを管理できるようにするアクセス許可を追加できます。さらに、保護対象リソースに関連する Route 53 ヘルスチェックが検出されたイベント中に異常が発生した場合に、事前に対処するように SRT を設定できます。この両方の保護機能を追加することで、DDoS イベントへの迅速な対応が可能になります。
**注記**
Shield Response Team (SRT) のサービスを使用するには、[ビジネスサポートプラン](https://aws.amazon.com/premiumsupport/business-support/)または[エンタープライズサポートプラン](https://aws.amazon.com/premiumsupport/enterprise-support/)をサブスクライブする必要があります。
SRT は、アプリケーションレイヤーイベント中に AWS WAF リクエストデータとログをモニタリングして、異常なトラフィックを特定できます。これらは、問題のあるトラフィックソースを軽減するためのカスタム AWS WAF ルールの作成に役立ちます。必要に応じて、SRT は、リソースをレコメンデーションとより適切に一致させるために、アーキテクチャに関するレコメンデ AWS ーションを作成する場合があります。
SRT 関数の詳細については、「[Shield Response Team (SRT) サポートによるマネージド DDoS イベントレスポンス](ddos-srt-support.md)」を参照してください。
**SRT にアクセス許可を付与するには**
1. AWS Shield コンソール**の概要**ページの**「SRT サポートの設定 AWS **」で、**「SRT アクセスの編集**」を選択します。**Edit AWS Shield Response Team (SRT) アクセス**ページが開きます。
1. **SRT アクセス設定**には、次のいずれかのオプションを選択します。
+ **アカウントへのアクセス権を SRT に付与しない** – Shield は、アカウントとリソースにアクセスするために以前に SRT に付与したすべての許可を削除します。
+ **[Create a new role for the SRT to access my account]** (SRT が自分のアカウントにアクセスするための新しいロールを作成する) — Shield は、SRT を表すサービスプリンシパル `drt.shield.amazonaws.com` を信頼するロールを作成し、マネージドポリシー `AWSShieldDRTAccessPolicy` をそれにアタッチします。管理ポリシーは、SRT がユーザーに代わって および AWS WAF API コールを行い AWS Shield Advanced 、ログにアクセスすることを許可します AWS WAF 。管理ポリシーの詳細については、「[AWS マネージドポリシー: AWSShieldDRTAccessPolicy](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy)」を参照してください。
+ **SRT がアカウントにアクセスするための既存のロールを選択する** – このオプションでは、 AWS Identity and Access Management 次のように (IAM) でロールの設定を変更する必要があります。
+ マネージドポリシー `AWSShieldDRTAccessPolicy` をロールにアタッチします。この管理ポリシーにより、SRT はユーザーに代わって および AWS WAF API コールを行い AWS Shield Advanced 、ログにアクセスできるようになります AWS WAF 。管理ポリシーの詳細については、「[AWS マネージドポリシー: AWSShieldDRTAccessPolicy](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy)」を参照してください。マネージドポリシーをロールにアタッチする方法については、「[Attaching and Detaching IAM Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)」(IAM ポリシーのアタッチとデタッチ) を参照してください。
+ サービスプリンシパル `drt.shield.amazonaws.com` を信頼するようにロールを変更します。これは、SRT を表すサービスプリンシパルです。詳細については、「[IAM JSON ポリシーエレメント: プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)」を参照してください。
1. **[保存]** を選択して変更を保存します。
SRT に保護とデータへのアクセスを許可する方法の詳細については、「[SRT へのアクセスの許可](ddos-srt-access.md)」を参照してください。
**SRT のプロアクティブな関与を有効にするには**
1. AWS Shield コンソール**の概要**ページの**「プロアクティブエンゲージメントとコンタクト**」の「コンタクトエリア」で、**「編集**」を選択します。
**[Edit contacts]** (連絡先を編集) ページで、SRT がプロアクティブな関与のために連絡する担当者の連絡先情報を入力します。
複数の連絡先を提供する場合は、**[Notes]** (備考) に、各連絡先を使用する必要がある状況を記載してください。プライマリおよびセカンダリの連絡先指定を含めて、各連絡先の空き時間およびタイムゾーンを指定します。
問い合わせメモの例:
+ これは、24 時間年中無休でスタッフが対応するホットラインです。応答するアナリストにご協力ください。この担当者は、適切な担当者を呼び出します。
+ 5 分以内にホットラインが応答しない場合は、私までお問い合わせください。
1. **[Save]** (保存) を選択します。
**[Overview]** (概要) ページには、更新された連絡先情報が反映されます。
1. **[Edit proactive engagement feature]** (プロアクティブな関与機能を編集) を選択し、**[Enable]** (有効化) を選択してから、**[Save]** (保存) を選択してプロアクティブな関与を有効にします。
プロアクティブな関与の詳細については、「[SRT が直接連絡するためのプロアクティブエンゲージメントの設定](ddos-srt-proactive-engagement.md)」を参照してください。
# CloudWatch で DDoS ダッシュボードを作成し、CloudWatch アラームを設定する
このページでは、CloudWatch で DDoS ダッシュボードを作成し、CloudWatch アラームの設定について説明します。
Amazon CloudWatch を使用して潜在的な DDoS アクティビティをモニタリングすることで、Shield Advanced から未加工データを収集し、リアルタイムに近い読み取り可能なメトリクスとして加工できます。CloudWatch の統計を使用して、ウェブアプリケーションやサービスの動作状況を把握できます。CloudWatch の詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[What is CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html)」(CloudWatch とは) を参照してください。
+ CloudWatch ダッシュボードを作成する手順については、「[Amazon CloudWatch によるモニタリング](monitoring-cloudwatch.md)」を参照してください。
+ ダッシュボードに追加できる Shield Advanced メトリクスの説明については、「[AWS Shield Advanced メトリクス](shield-metrics.md)」を参照してください。
Shield Advanced は、リソースメトリクスを、進行中のイベントがないときと比較して、DDoS イベント中により頻繁に CloudWatch にレポートします。Shield Advanced は、イベント中は 1 分ごとに、およびイベント終了直後に 1 回、メトリクスをレポートします。イベントが発生していない間、Shield Advanced は 1 日に 1 回、リソースに割り当てられた時間にメトリクスを報告します。この定期的なレポートにより、メトリクスをアクティブに保ち、ユーザーのカスタム CloudWatch アラームで使用できるようにします。
これで、Shield Advanced の開始方法のチュートリアルは完了です。選択した保護機能を最大限に活用するには、Shield Advanced の機能とオプションの検索を続けてください。まず、[Shield Advanced による DDoS イベントの可視性](ddos-viewing-events.md) および [での DDoS イベントへの対応 AWS](ddos-responding.md) でイベントを表示して対応するためのオプションをよく理解してください。
# Shield Response Team (SRT) サポートによるマネージド DDoS イベントレスポンス
このページでは、Shield Response Team (SRT) の機能について説明します。
SRT は、Shield Advanced のお客様に追加のサポートを提供します。SRT は DDoS イベントへの対応を専門とするセキュリティエンジニアの集団です。 AWS サポート プランに対するサポートの追加レイヤーとして、SRT と直接やり取りして、イベント対応ワークフローの一環として SRT の専門知識を活用できます。オプションの詳細および設定ガイダンスについては、次のトピックを参照してください。
**注記**
Shield Response Team (SRT) のサービスを使用するには、[ビジネスサポートプラン](https://aws.amazon.com/premiumsupport/business-support/)または[エンタープライズサポートプラン](https://aws.amazon.com/premiumsupport/enterprise-support/)をサブスクライブする必要があります。
Shield Response Team (SRT) は、Shield Advanced が利用可能なリージョン、および GovCloud リージョン、 AWS GovCloud (米国東部）、 AWS GovCloud (米国西部) のお客様にサービスを提供しています。
**SRT のサポートアクティビティ**
SRT との連携の主な目標は、アプリケーションの可用性とパフォーマンスを保護することです。DDoS イベントのタイプとアプリケーションのアーキテクチャに応じて、SRT は次のいずれかまたは複数のアクションを実行することがあります。
+ **AWS WAF ログ分析とルール** – AWS WAF ウェブ ACL を使用するリソースの場合、SRT は AWS WAF ログを分析してアプリケーションウェブリクエストの攻撃特性を特定できます。エンゲージメント中に承認を得た場合、SRT はウェブ ACL に変更を適用して、特定した攻撃をブロックできます。
+ **カスタムネットワーク緩和策の構築** – SRT は、インフラストラクチャレイヤーの攻撃に対して、お客様のためにカスタム緩和策を作成できます。SRT はユーザーと連携して、アプリケーションについて想定されるトラフィックを理解し、予期しないトラフィックをブロックし、パケット/秒のレート制限を最適化できます。詳細については、「[SRT による DDoS 攻撃に対するカスタム緩和策の設定](ddos-srt-custom-mitigations.md)」を参照してください。
+ **ネットワークトラフィックエンジニアリング** – SRT は AWS ネットワークチームと密接に連携して Shield Advanced のお客様を保護します。必要に応じて、インターネットトラフィックが AWS ネットワークに到達する方法 AWS を変更して、アプリケーションにより多くの緩和キャパシティを割り当てることができます。
+ **アーキテクチャの推奨事項** – SRT は、攻撃の最善の緩和策として、 AWS ベストプラクティスにより合致するアーキテクチャの変更が必要であると判断し、これらのプラクティスの実装をサポートします。詳細については、「[DDoS 耐性向上のためのAWS のベストプラクティス](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency)」を参照してください。
以下のセクションでは、SRT を利用する手順について説明します。
**Topics**
+ [SRT へのアクセスの許可](ddos-srt-access.md)
+ [SRT が直接連絡するためのプロアクティブエンゲージメントの設定](ddos-srt-proactive-engagement.md)
+ [疑わしい DDoS イベントに関する SRT への問い合わせ](ddos-srt-contacting.md)
+ [SRT による DDoS 攻撃に対するカスタム緩和策の設定](ddos-srt-custom-mitigations.md)
# SRT へのアクセスの許可
このページでは、SRT が AWS WAF ログにアクセスし、 AWS Shield Advanced および AWS WAF APIs を呼び出して保護を管理できるように、ユーザーに代わって動作するアクセス許可を SRT に付与する手順を示します。
アプリケーションレイヤー DDoS イベント中、SRT は AWS WAF リクエストをモニタリングして異常なトラフィックを特定し、問題のあるトラフィックソースを軽減するためのカスタム AWS WAF ルールを作成できます。
さらに、Application Load Balancer、Amazon CloudFront、またはサードパーティーのソースからのパケットキャプチャやログなど、Amazon S3 バケットに保存されている他のデータへのアクセス権を SRT に付与することもできます。
**注記**
Shield Response Team (SRT) のサービスを使用するには、[ビジネスサポートプラン](https://aws.amazon.com/premiumsupport/business-support/)または[エンタープライズサポートプラン](https://aws.amazon.com/premiumsupport/enterprise-support/)をサブスクライブする必要があります。
**SRT の許可を管理するには**
1. AWS Shield コンソール**の概要**ページの**「SRT サポートの設定 AWS **」で、**「SRT アクセスの編集**」を選択します。**Edit AWS Shield Response Team (SRT) アクセス**ページが開きます。
1. **SRT アクセス設定**には、次のいずれかのオプションを選択します。
+ **アカウントへのアクセス権を SRT に付与しない** – Shield は、アカウントとリソースにアクセスするために以前に SRT に付与したすべての許可を削除します。
+ **[Create a new role for the SRT to access my account]** (SRT が自分のアカウントにアクセスするための新しいロールを作成する) — Shield は、SRT を表すサービスプリンシパル `drt.shield.amazonaws.com` を信頼するロールを作成し、マネージドポリシー `AWSShieldDRTAccessPolicy` をそれにアタッチします。管理ポリシーは、SRT がユーザーに代わって および AWS WAF API コールを行い AWS Shield Advanced 、ログにアクセスすることを許可します AWS WAF 。管理ポリシーの詳細については、「[AWS マネージドポリシー: AWSShieldDRTAccessPolicy](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy)」を参照してください。
+ **SRT がアカウントにアクセスするための既存のロールを選択する** – このオプションでは、 AWS Identity and Access Management 次のように (IAM) でロールの設定を変更する必要があります。
+ マネージドポリシー `AWSShieldDRTAccessPolicy` をロールにアタッチします。この管理ポリシーにより、SRT はユーザーに代わって および AWS WAF API コールを行い AWS Shield Advanced 、ログにアクセスできるようになります AWS WAF 。管理ポリシーの詳細については、「[AWS マネージドポリシー: AWSShieldDRTAccessPolicy](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy)」を参照してください。マネージドポリシーをロールにアタッチする方法については、「[Attaching and Detaching IAM Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)」(IAM ポリシーのアタッチとデタッチ) を参照してください。
+ サービスプリンシパル `drt.shield.amazonaws.com` を信頼するようにロールを変更します。これは、SRT を表すサービスプリンシパルです。詳細については、「[IAM JSON ポリシーエレメント: プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)」を参照してください。
1. **(オプション): Amazon S3 バケットへの SRT アクセスを付与**します。 AWS WAF ウェブ ACL ログにないデータを共有する必要がある場合は、これを設定します。Application Load Balancer アクセスログ、Amazon CloudFront ログ、またはサードパーティーのソースからのログはその一例です。
**注記**
AWS WAF ウェブ ACL ログに対してこれを行う必要はありません。SRT は、アカウントへのアクセス権が付与されると、それらにアクセスできるようになります。
1. 次のガイドラインに従って Amazon S3 バケットを設定します。
+ バケットの場所は、前のステップの **AWS Shield Response Team (SRT) アクセスで SRT** に一般アクセス権を付与したもの AWS アカウント と同じ にある必要があります。
+ バケットは、プレーンテキストまたは SSE-S3 暗号化のいずれかです。Amazon S3 SSE-S3 暗号化の詳細については、「Amazon S3 ユーザーガイド」の「[Amazon S3 が管理する暗号化キーによるサーバー側の暗号化 (SSE−S3) を使用したデータの保護](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html)」を参照してください。
SRT は、 AWS Key Management Service () に保存されているキーで暗号化されたバケットに保存されているログを表示または処理することはできませんAWS KMS。
1. Shield Advanced の **[(Optional): Grant SRT access to an Amazon S3 bucket]** ((オプション): Amazon S3 バケットへのアクセス権を SRT に付与) セクションで、データまたはログが保存されている各 Amazon S3 バケットについてバケットの名前を入力し、**[Add Bucket]** (バケットを追加) を選択します。バケットは最大 10 個まで追加できます。
これにより、SRT に各バケットに対する次の `s3:GetBucketLocation`、`s3:GetObject`、および `s3:ListBucket` 許可が付与されます。
10 個を超えるバケットにアクセスする許可を SRT に付与する場合は、追加のバケットポリシーを編集し、SRT についてここにリストされている許可を手動で付与することで、これを実行できます。
ポリシーリストの例を以下に示します。
```
{
"Sid": "AWSDDoSResponseTeamAccessS3Bucket",
"Effect": "Allow",
"Principal": {
"Service": "drt.shield.amazonaws.com"
},
"Action": [
"s3:GetBucketLocation",
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::bucket-name",
"arn:aws:s3:::bucket-name/*"
]
}
```
1. **[保存]** を選択して変更を保存します。
また、IAM ロールを作成してポリシー AWSShieldDRTAccessPolicy をアタッチしてから、そのロールをオペレーション [AssociateDRTRole](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_AssociateDRTRole.html) に渡すことで、API を通じて SRT を承認することもできます。
# SRT が直接連絡するためのプロアクティブエンゲージメントの設定
このページでは、SRT とのプロアクティブエンゲージメントを設定する手順について説明します。
プロアクティブなエンゲージメントにより、攻撃の可能性があるためにアプリケーションの可用性またはパフォーマンスが影響を受ける場合は、SRT から直接連絡します。このエンゲージメントモデルでは、SRT による最も迅速な対応が提供され、SRT がお客様と連絡を取り合う前であってもトラブルシューティングを開始できるため、推奨されています。
プロアクティブエンゲージメントは、Elastic IP アドレスと AWS Global Accelerator 標準アクセラレーターでのネットワークレイヤーイベントとトランスポートレイヤーイベント、および Amazon CloudFront ディストリビューションと Application Load Balancer でのウェブリクエストフラッドに使用できます。プロアクティブエンゲージメントは、Amazon Route 53 ヘルスチェックが関連付けられている Shield Advanced リソース保護でのみ利用できます。ヘルスチェックの管理と使用の詳細については、「[Shield Advanced と Route 53 を使用したヘルスチェックを使用したヘルスベースの検出](ddos-advanced-health-checks.md)」を参照してください。
Shield Advanced によって検出されたイベント中、SRT はヘルスチェックの状態を使用して、イベントがプロアクティブなエンゲージメントの対象となるかどうかを判断します。その場合は、プロアクティブな関与の設定で提供された連絡ガイダンスに従って、SRT から連絡が送られます。
プロアクティブな関与のために最大 10 件の連絡先を設定でき、SRT がお客様に連絡する際に参考となるメモを入力できます。イベント中、お客様側のプロアクティブな関与の連絡先は、SRT と対話が可能な状態になっている必要があります。24 時間年中無休のオペレーションセンターがない場合は、ポケットベルの連絡先を提供し、連絡先メモにこの連絡先設定を記載できます。
プロアクティブなエンゲージメントのために、次を実行する必要があります。
+ [ビジネスサポートプラン](https://aws.amazon.com/premiumsupport/business-support/)または[エンタープライズサポートプラン](https://aws.amazon.com/premiumsupport/enterprise-support/)に加入している必要があります。
+ Amazon Route 53 ヘルスチェックは、プロアクティブなエンゲージメントで保護するリソースに関連付ける必要があります。SRT は、イベントにプロアクティブなエンゲージメントが必要かどうかを判断するのをサポートするために、ヘルスチェックのステータスを使用します。したがって、ヘルスチェックが保護されたリソースの状態を正確に反映していることが重要です。詳細とガイダンスについては、「[Shield Advanced と Route 53 を使用したヘルスチェックを使用したヘルスベースの検出](ddos-advanced-health-checks.md)」を参照してください。
+ AWS WAF ウェブ ACL が関連付けられているリソースの場合、最新バージョンの AWS WAF (v2) を使用してウェブ ACL を作成する必要があります AWS WAF。
+ イベント中、プロアクティブなエンゲージメントのために、SRT による使用を目的として、少なくとも 1 名の連絡先を提供する必要があります。連絡先情報を完全かつ最新の状態に保ちます。
**SRT のプロアクティブな関与を有効にするには**
1. AWS Shield コンソール**の概要**ページの**「プロアクティブエンゲージメントと問い合わせ**」の「問い合わせエリア」で、**「編集**」を選択します。
**[Edit contacts]** (連絡先を編集) ページで、SRT がプロアクティブな関与のために連絡する担当者の連絡先情報を入力します。
複数の連絡先を提供する場合は、**[Notes]** (備考) に、各連絡先を使用する必要がある状況を記載してください。プライマリおよびセカンダリの連絡先指定を含めて、各連絡先の空き時間およびタイムゾーンを指定します。
問い合わせメモの例:
+ これは、24 時間年中無休でスタッフが対応するホットラインです。応答するアナリストにご協力ください。この担当者は、適切な担当者を呼び出します。
+ 5 分以内にホットラインが応答しない場合は、私までお問い合わせください。
1. **[Save]** (保存) を選択します。
**[Overview]** (概要) ページには、更新された連絡先情報が反映されます。
1. **[Edit proactive engagement feature]** (プロアクティブな関与機能を編集) を選択し、**[Enable]** (有効化) を選択してから、**[Save]** (保存) を選択してプロアクティブな関与を有効にします。
# 疑わしい DDoS イベントに関する SRT への問い合わせ
次のいずれかの方法で SRT に連絡できます。
**サポートケース**
**[AWS サポートセンター]** コンソールの **[AWS Shield]** でケースを開くことができます。
サポートケースの作成に関するガイダンスについては、「[AWS サポート センター](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html)」を参照してください。
状況に適した重要度を選択し、連絡先の詳細を入力します。説明では、可能な限り詳細に入力します。影響を受ける可能性があると思われる保護されたリソースと、エンドユーザーエクスペリエンスの現在の状態に関する情報を入力してください。例えば、ユーザーエクスペリエンスが低下したり、アプリケーションの一部が現在利用できない場合は、その情報を提供してください。
+ **DDoS 攻撃が疑われる状況** –アプリケーションの可用性またはパフォーマンスが DDoS 攻撃の可能性がある現象によって現在影響を受けている場合は、次の重要度と連絡先のオプションを選択します。
+ 重要度については、サポートプランで使用可能な最も高い重要度を選択します。
+ ビジネスサポートの場合、これは **[Production system down: < 1 hour]** (本番稼働用システムのダウン: 1 時間未満) です。
+ エンタープライズサポートの場合、これは **[Business-critical system down: < 15 minutes]** (ビジネスクリティカルなシステムのダウン: 15 分未満) です。
+ 連絡先オプションについては、**[Phone]** (電話) または **[Chat]** (チャット) のいずれかを選択し、詳細を入力してください。ライブのお問い合わせ方法を使用すると、最速で応答が得られます。
**プロアクティブな関与**
AWS Shield Advanced プロアクティブエンゲージメントでは、検出されたイベント中に保護されたリソースに関連付けられた Amazon Route 53 ヘルスチェックが異常になった場合、SRT から直接連絡されます。このオプションの詳細については、「[SRT が直接連絡するためのプロアクティブエンゲージメントの設定](ddos-srt-proactive-engagement.md)」を参照してください。
# SRT による DDoS 攻撃に対するカスタム緩和策の設定
このページでは、SRT を使用して DDoS 攻撃に対するカスタム緩和策を構築する手順を示します。
Elastic IPs (EIPs) と AWS Global Accelerator 標準アクセラレーターについては、SRT を使用してカスタム緩和策を設定できます。これは、緩和の導入時に適用すべき特定のロジックがわかっている場合に便利です。例えば、特定の国からのトラフィックのみを許可する、特定のレート制限を適用する、オプションの検証を設定する、フラグメントを許可しない、パケットペイロードの特定のパターンに一致するトラフィックのみを許可する、などの設定が可能です。
一般的なカスタム緩和の例には、次のようなものがあります。
+ **パターンが一致** - クライアントサイドアプリケーションとやり取りするサービスを運用する場合、それらのアプリケーションに固有の既知のパターンを照合するように選択できます。例えば、お客様が配布する特定のソフトウェアをエンドユーザーがインストールする必要があるゲームまたは通信サービスを運用する場合があります。アプリケーションがサービスに送信するすべてのパケットにマジックナンバーを含めることができます。フラグメント化されていない TCP または UDP パケットペイロードおよびヘッダーを最大 128 バイト（個別または連続）まで照合できます。一致は、パケットペイロードの先頭からの特定のオフセット、または既知の値に続くダイナミックオフセットとして 16 進表記で表すことができます。たとえば、緩和はバイト `0x01` を探すことができ、次の 4 バイトとして `0x12345678` が予測されます。
+ **DNS 固有** — グローバルアクセラレータや Amazon Elastic Compute Cloud (Amazon EC2) などのサービスを使用して独自の権威ある DNS サービスを運用する場合、パケットが有効な DNS クエリであることを確認し、DNS トラフィックに固有の特定の属性を評価する疑惑スコアリングを適用するパケットを検証するカスタム緩和をリクエストできます。
SRT でのカスタム緩和策の構築に関する問い合わせは、 AWS Shieldでサポートケースを作成します。 AWS サポート ケースの作成の詳細については、[「 の開始方法 AWS サポート](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html)」を参照してください。
# でのリソース保護 AWS Shield Advanced
リソース AWS Shield Advanced の保護を追加および設定できます。1 つのリソースのための保護を管理でき、保護されたリソースを論理コレクションにグループ化して、イベント管理を改善できます。を使用して Shield Advanced 保護の変更を追跡することもできます AWS Config。
**注記**
Shield Advanced は、Shield Advanced または Shield Advanced AWS Firewall Manager ポリシーを通じて指定したリソースのみを保護します。リソースは自動的に保護されません。
AWS Firewall Manager Shield Advanced ポリシーを使用している場合は、ポリシーの範囲内にあるリソースの保護を管理する必要はありません。Firewall Manager は、ポリシーの設定に従って、ポリシーの範囲内にあるアカウントおよびリソースの保護を自動的に管理します。詳細については、「[Firewall Manager での AWS Shield Advanced ポリシーの使用](shield-policies.md)」を参照してください。
**Topics**
+ [が AWS Shield Advanced 保護するリソースのリスト](ddos-protections-by-resource-type.md)
+ [Shield Advanced を使用した Amazon EC2 インスタンスおよび Network Load Balancer の保護](ddos-protections-ec2-nlb.md)
+ [AWS Shield Advanced および を使用したアプリケーションレイヤー (レイヤー 7) の保護 AWS WAF](ddos-app-layer-protections.md)
+ [Shield Advanced と Route 53 を使用したヘルスチェックを使用したヘルスベースの検出](ddos-advanced-health-checks.md)
+ [AWS リソースへの AWS Shield Advanced 保護の追加](configure-new-protection.md)
+ [AWS Shield Advanced 保護の編集](manage-protection.md)
+ [Shield Advanced で保護されたリソースのアラームと通知の作成](add-alarm-ddos.md)
+ [AWS リソースからの AWS Shield Advanced 保護の削除](remove-protection.md)
+ [AWS Shield Advanced 保護のグループ化](ddos-protection-groups.md)
+ [での Shield Advanced リソース保護の変更の追跡 AWS Config](ddos-add-config.md)
# が AWS Shield Advanced 保護するリソースのリスト
このセクションは、各リソースタイプの Shield Advanced 保護に関する情報を提供します。
Shield Advanced は、ネットワークレイヤーとトランスポートレイヤー (レイヤー 3 と 4) とアプリケーションレイヤー (レイヤー 7) の AWS リソースを保護します。一部のリソースを直接保護し、他のリソースを保護されたリソースとの関連付けを通じて保護することができます。Shield Advanced は IPv4 をサポートしていますが、IPv6 はサポートしていません。
**注記**
Shield Advanced は、Shield Advanced で、または AWS Firewall Manager Shield Advanced ポリシーを通じて指定したリソースのみを保護します。リソースは自動的に保護されません。
Shield Advanced を使用すると、次のリソースタイプで高度なモニタリングと保護を行うことができます。
+ Amazon CloudFront ディストリビューション。CloudFront の継続的デプロイでは、Shield Advanced は保護対象のプライマリディストリビューションに関連付けられているすべてのステージングディストリビューションを保護します。
+ Amazon Route 53 ホストゾーン。
+ AWS Global Accelerator 標準アクセラレーター。
+ Amazon EC2 Elastic IP アドレス。Shield Advanced は、保護された Elastic IP アドレスに関連付けられているリソースを保護します。
+ Amazon EC2 インスタンス (Amazon EC2 Elastic IP アドレスへの関連付け経由)
+ 次の Elastic Load Balancing (ELB) ロードバランサー:
+ Application Load Balancer。
+ Classic Load Balancer。
+ Network Load Balancer (Amazon EC2 Elastic IP アドレスへの関連付け経由)。
**注記**
Shield Advanced を使用して他のリソースタイプを保護することはできません。例えば、 AWS Global Accelerator カスタムルーティングアクセラレータや Gateway Load Balancer を保護することはできません。
**注記**
NAT ゲートウェイはアウトバウンドトラフィックのみを処理しますが、Shield Advanced はインバウンド DDoS から保護します。アウトバウンドトラフィックの保護には、 を使用します[AWS Network Firewall](https://docs.aws.amazon.com//network-firewall/latest/developerguide/what-is-aws-network-firewall.html)。
AWS アカウントあたり各リソースタイプについて最大 1,000 のリソースをモニタリングおよび保護できます。例えば、1 つのアカウントで、1,000 の Amazon EC2 Elastic IP アドレス、1,000 の CloudFront ディストリビューション、および 1,000 の Application Load Balancer を保護できます。[https://console.aws.amazon.com/servicequotas/](https://console.aws.amazon.com/servicequotas/) の Service Quotas コンソールで、Shield Advanced で保護できるリソースの数の増加をリクエストできます。
# Shield Advanced を使用した Amazon EC2 インスタンスおよび Network Load Balancer の保護
このページでは、Amazon EC2 インスタンスと Network Load Balancer AWS Shield Advanced の保護を使用する方法について説明します。
Amazon EC2 インスタンスおよび Network Load Balancer を保護するには、まずこれらのリソースを Elastic IP アドレスにアタッチし、次に Shield Advanced で Elastic IP アドレスを保護します。
Elastic IP アドレスを保護すると、Shield Advanced は、それらがアタッチされているリソースを識別して保護します。Shield Advanced は、Elastic IP アドレスにアタッチされているリソースのタイプを自動的に識別し、そのリソースのために適切な検出および緩和策を適用します。これには、その Elastic IP アドレスに固有のネットワーク ACL を設定することが含まれます。 AWS リソースでの Elastic IP アドレスの使用の詳細については、[Amazon Elastic Compute Cloud のドキュメント](https://docs.aws.amazon.com/ec2/)または [Elastic Load Balancing のドキュメント](https://docs.aws.amazon.com/elasticloadbalancing/)のガイドを参照してください。
攻撃中、Shield Advanced はネットワーク ACLsを AWS ネットワークの境界に自動的にデプロイします。ネットワーク ACL がネットワークの境界にある場合、Shield Advanced はより大きな DDoS イベントに対する保護を提供できます。通常、ネットワーク ACL は Amazon VPC 内の Amazon EC2 インスタンスの近くで適用されます。ネットワーク ACL は、Amazon VPC とインスタンスが処理できるだけの大きさの攻撃を緩和できます。例えば、Amazon EC2 インスタンスに接続されたネットワークインターフェイスが最大 10 Gbps を処理できる場合、10 Gbps を超えるボリュームは遅くなり、そのインスタンスへのトラフィックをブロックする可能性があります。攻撃を受けている最中に、Shield Advanced はネットワーク ACL を AWS 境界に昇格させ、数テラバイトのトラフィックを処理できます。ネットワーク ACL は、典型的なネットワークの容量を超えてリソースを十分に保護することができます。ネットワーク ACL の詳細については、「[ネットワーク ACL](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html)」を参照してください。
などの一部のスケーリングツールでは AWS Elastic Beanstalk、Network Load Balancer に Elastic IP アドレスを自動的にアタッチすることはできません。このような場合、Elastic IP アドレスを手動でアタッチする必要があります。
# AWS Shield Advanced および を使用したアプリケーションレイヤー (レイヤー 7) の保護 AWS WAF
このページでは、Shield Advanced と AWS WAF が連携してアプリケーションレイヤー (レイヤー 7) のリソースを保護する方法について説明します。
Shield Advanced を使用してアプリケーションレイヤーのリソースを保護するには、まず AWS WAF ウェブ ACL をリソースに関連付けて、それに 1 つ以上のレートベースのルールを追加します。さらに、アプリケーションレイヤー DDoS 自動緩和を有効にすることもできます。これにより、DDoS 攻撃への対応として、Shield Advanced がユーザーのために自動的にウェブ ACL ルールを作成および管理するようになります。
Shield Advanced を使用してアプリケーションレイヤーリソースを保護する場合、Shield Advanced は、トラフィックを時間の経過に合わせて分析し、ベースラインを確立して維持します。Shield Advanced は、DDoS 攻撃を示している可能性のあるトラフィックパターンの異常を検出するために、これらのベースラインを使用します。Shield Advanced が攻撃を検出するポイントは、Shield Advanced が攻撃前にモニタリングできる状態になっていたトラフィックと、ウェブアプリケーションで使用するアーキテクチャによって異なります。Shield Advanced の動作に影響を与える可能性があるアーキテクチャのバリエーションには、使用するインスタンスのタイプ、インスタンスのサイズ、該当するインスタンスのタイプが拡張ネットワーキングをサポートするかどうかなどがあります。Shield Advanced を設定して、アプリケーションレイヤー攻撃に対して自動的に緩和策を実施することもできます。
**Shield Advanced サブスクリプションと AWS WAF コスト**
Shield Advanced サブスクリプションは、Shield Advanced で保護するリソースの標準 AWS WAF 機能を使用するコストをカバーします。Shield Advanced 保護の対象となる標準 AWS WAF 料金は、保護パック (ウェブ ACL) あたりのコスト、ルールあたりのコスト、ウェブリクエスト検査の 100 万リクエストあたりの基本料金、最大 1,500 WCUs、およびデフォルトの本文サイズです。
Shield Advanced 自動アプリケーションレイヤー DDoS 緩和を有効にすると、150 個の保護パック (ウェブ ACL) キャパシティユニット (WCU) はルールグループに追加されます。これらの WCU は、保護パック (ウェブ ACL) 内の WCU の使用量に対してカウントされます。詳細については[Shield Advanced によるアプリケーションレイヤー DDoS 自動緩和](ddos-automatic-app-layer-response.md)、[Shield Advanced ルールグループによるアプリケーションレイヤーの保護](ddos-automatic-app-layer-response-rg.md)、および[のウェブ ACL キャパシティユニット (WCUs) AWS WAF](aws-waf-capacity-units.md)を参照してください。
Shield Advanced のサブスクリプションでは、Shield Advanced を使用して保護しないリソース AWS WAF の の使用はカバーされません。また、保護されたリソースの標準以外の追加 AWS WAF コストもカバーしません。標準以外の AWS WAF コストの例としては、Bot Control、CAPTCHAルールアクション、1,500 WCUs を超えるウェブ ACLs、およびデフォルトの本文サイズを超えるリクエスト本文の検査などがあります。完全なリストは AWS WAF 料金ページに記載されています。Shield Advanced へのサブスクリプションには、 Layer 7 Anti-DDoS Amazon Managed Rule グループへのアクセスが含まれます。サブスクリプションの一環として、Shield Advanced で保護された AWS WAF リソースへのリクエストは 1 か月あたり最大 500 億件になります。500 億を超えるリクエストは、 AWS Shield Advanced 料金ページに従って請求されます。
詳細情報および料金の例については、「[Shield の料金](https://aws.amazon.com/shield/pricing/)」および「[AWS WAF の料金](https://aws.amazon.com/waf/pricing/)」を参照してください。
**Topics**
+ [Shield Advanced によるアプリケーションレイヤーのイベント検出と緩和に影響する要因のリスト](ddos-app-layer-detection-mitigation.md)
+ [AWS WAF ウェブ ACLs と Shield Advanced によるアプリケーションレイヤーの保護](ddos-app-layer-web-ACL-and-rbr.md)
+ [AWS WAF レートベースのルールと Shield Advanced によるアプリケーションレイヤーの保護](ddos-app-layer-rbr.md)
+ [Shield Advanced によるアプリケーションレイヤー DDoS 自動緩和](ddos-automatic-app-layer-response.md)
# Shield Advanced によるアプリケーションレイヤーのイベント検出と緩和に影響する要因のリスト
このセクションでは、Shield Advanced によるアプリケーションレイヤーイベントの検出と緩和に影響する要因について説明します。
**ヘルスチェック**
アプリケーションの全体的な状態を正確に報告するヘルスチェックは、アプリケーションが経験しているトラフィック条件に関する情報を Shield Advanced に提供します。Shield Advanced では、アプリケーションが異常を報告している場合に潜在的な攻撃を指している情報が少なくなり、アプリケーションが正常を報告している場合に攻撃の証拠がさらに必要になります。
アプリケーションの状態を正確にレポートするには、ヘルスチェックを設定することが重要です。詳細とガイダンスについては、「[Shield Advanced と Route 53 を使用したヘルスチェックを使用したヘルスベースの検出](ddos-advanced-health-checks.md)」を参照してください。
**トラフィックのベースライン**
トラフィックのベースラインは、アプリケーションの通常のトラフィックの特性に関する Shield Advanced 情報を提供します。Shield Advanced は、これらのベースラインを使用して、アプリケーションが通常のトラフィックを受信していないタイミングを認識します。そのため、アプリケーションは通知を行い、設定に従って、潜在的な攻撃に対抗するための緩和オプションの考案とテストを開始できます。Shield Advanced がトラフィックベースラインを使用して潜在的なイベントを検出する方法の詳細については、概要セクション [アプリケーションレイヤーの脅威に対する Shield Advanced 検出ロジック (レイヤー 7)](ddos-event-detection-application.md) を参照してください。
Shield Advanced は、保護されたリソースに関連付けられているウェブ ACL によって提供される情報からベースラインを作成します。ウェブ ACL は、Shield Advanced がアプリケーションのベースラインを確実に決定できるようになるまで、少なくとも 24 時間から最大 30 日間、リソースに関連付ける必要があります。必要な時間は、Shield Advanced または AWS WAFを介してウェブ ACL を関連付けたときに開始されます。
Shield Advanced アプリケーションレイヤー保護でウェブ ACL を使用する方法の詳細については、[AWS WAF ウェブ ACLs と Shield Advanced によるアプリケーションレイヤーの保護](ddos-app-layer-web-ACL-and-rbr.md) を参照してください。
**レートベースのルール**
レートベースのルールは、攻撃の軽減に役立ちます。また、攻撃が通常のトラフィックのベースラインやヘルスチェックのステータスレポートに現れるほど大きな問題になる前に対処することで、攻撃を目立たなくすることもできます。
Shield Advanced でアプリケーションリソースを保護する場合は、ウェブ ACL でレートベースのルールを使用することをお勧めします。緩和策によって潜在的な攻撃を目立たなくすることはありますが、これらは貴重な第一の防御線であり、正当な顧客に対してアプリケーションの利用可能性を確保するのに役立ちます。レートベースのルールが検出するトラフィックとレート制限は、 AWS WAF メトリクスに表示されます。
独自のレートベースのルールに加えて、自動アプリケーションレイヤー DDoS 緩和を有効にすると、Shield Advanced は攻撃の軽減に使用するルールグループをウェブ ACL に追加します。このルールグループで、Shield Advanced は常に、DDoS 攻撃のソースであることが判明している IP アドレスからのリクエストの量を制限するレートベースのルールを保持しています。Shield Advanced ルールが緩和するトラフィックのメトリクスは表示できません。
レートベースのルールの詳細については、「[でのレートベースのルールステートメントの使用 AWS WAF](waf-rule-statement-type-rate-based.md)」を参照してください。Shield Advanced アプリケーションレイヤー DDoS 自動緩和の詳細については、[Shield Advanced ルールグループによるアプリケーションレイヤーの保護](ddos-automatic-app-layer-response-rg.md) を参照してください。
Shield Advanced と AWS WAF メトリクスの詳細については、「」を参照してください[Amazon CloudWatch によるモニタリング](monitoring-cloudwatch.md)。
# AWS WAF ウェブ ACLs と Shield Advanced によるアプリケーションレイヤーの保護
このページでは、 AWS WAF ウェブ ACL と Shield Advanced が連携して基本的なアプリケーションレイヤー保護を作成する方法について説明します。 ACLs
Shield Advanced でアプリケーションレイヤーリソースを保護するには、まずウェブ ACL を AWS WAF リソースに関連付けることから始めます。 AWS WAF は、アプリケーションレイヤーリソースに転送される HTTP および HTTPS リクエストをモニタリングし、リクエストの特性に基づいてコンテンツへのアクセスを制御できるウェブアプリケーションファイアウォールです。リクエストの発信元、クエリ文字列とクッキーのコンテンツ、単一の IP アドレスからのリクエストのレートなどの要因に基づいて、リクエストをモニタリングおよび管理するウェブ ACL を設定できます。少なくとも、Shield Advanced 保護では、ウェブ ACL をレートベースのルールに関連付けて、各 IP アドレスのリクエストのレートを制限する必要があります。
関連付けられたウェブ ACL にレートベースのルールが定義されていない場合、Shield Advanced から少なくとも 1 つ定義するように求められます。レートベースのルールは、定義したしきい値を超えると、ソース IP からのトラフィックを自動的にブロックします。これらは、ウェブリクエストのフラッドからアプリケーションを保護するのに役立つとともに、DDoS 攻撃の可能性を示していることがあるトラフィックの急増についてアラートを出すことができます。
**注記**
レートベースのルールは、ルールがモニタリングしているトラフィックの急増に非常に迅速に応答します。このため、レートベースのルールは、攻撃だけでなく、Shield Advanced 検出によって、潜在的な攻撃も検出できます。このトレードオフは、攻撃パターンを完全に可視化するよりも防止を優先します。攻撃に対する防御の最前線として、レートベースのルールを使用することをお勧めします。
ウェブ ACL を設定すると、DDoS 攻撃が発生した場合、ウェブ ACL にルールを追加して管理することで緩和策を適用します。これは、直接行うことができるほか、Shield レスポンスチーム (SRT、Shield Response Team) のサポートを受けて、またはアプリケーションレイヤー DDoS 自動緩和を通じて自動的に行うこともできます。
**重要**
自動アプリケーションレイヤー DDoS 緩和も使用する場合は、[アプリケーションレイヤー DDoS 自動緩和機能を使用するためのベストプラクティス。](ddos-automatic-app-layer-response-bp.md) でウェブ ACL を管理するためのベストプラクティスを参照してください。
AWS WAF を使用してウェブリクエストのモニタリングおよび管理ルールを管理する方法については、「」を参照してください[で保護パック (ウェブ ACL) を作成する AWS WAF](web-acl-creating.md)。
# AWS WAF レートベースのルールと Shield Advanced によるアプリケーションレイヤーの保護
このページでは、 AWS WAF レートベースのルールと Shield Advanced が連携して基本的なアプリケーションレイヤー保護を作成する方法について説明します。
デフォルト設定でレートベースのルールを使用すると、 は過去 5 分間の時間枠のトラフィック AWS WAF を定期的に評価します。 は、リクエストレートが許容レベルに低下するまで、ルールのしきい値を超える IP アドレスからのリクエストを AWS WAF ブロックします。Shield Advanced を通じてレートベースのルールを設定する際は、任意の 5 分間の時間枠内で期待される通常のトラフィックレートを超える値にレートしきい値を設定してください。
ウェブ ACL で複数のレートベースのルールを使用したい場合があります。例えば、高いしきい値を持つすべてのトラフィックについて 1 つのレートベースのルールを指定するとともに、ウェブアプリケーションの特定の部分と一致するように設定され、しきい値が低い追加のルールを 1 つ以上指定できます。例えば、ログインページに対する不正を緩和するために、しきい値を低くして URI `/login.html` に対する照合を行うことができます。
別の評価時間枠を使用し、ヘッダー値、ラベル、クエリ引数などの多数のリクエストコンポーネントによってリクエストを集約するように、レートベースのルールを設定できます。詳細については、「[でのレートベースのルールステートメントの使用 AWS WAF](waf-rule-statement-type-rate-based.md)」を参照してください。
追加情報とガイダンスについては、セキュリティブログ記事[「The three most important AWS WAF rate-based rules](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/)」を参照してください。
**を使用して設定オプションを拡張 AWS WAF**
Shield Advanced コンソールでは、レートベースのルールを追加し、基本のデフォルト設定で構成できます。レートベースのルールを管理することで、追加の設定オプションを定義できます AWS WAF。例えば、転送された IP アドレス、クエリ文字列、およびラベルなどのキーに基づく集約リクエストのルールを設定できます。また、ルールにスコープダウンステートメントを追加して、一部のリクエストを評価およびレート制限から除外することも可能です。詳細については、「[でのレートベースのルールステートメントの使用 AWS WAF](waf-rule-statement-type-rate-based.md)」を参照してください。
# Shield Advanced によるアプリケーションレイヤー DDoS 自動緩和
**注記**
2026 年 3 月 26 日以降、 の Anti-DDoS Managed Rule Group (Anti-DDOS AMR) が HTTP リクエストフラッド攻撃に対する保護のデフォルトソリューション AWS WAF になります ([Anti-DDoS AMR 起動ブログ](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-the-aws-waf-application-layer-ddos-protection/)を参照）。Layer 7 Auto Mitigation (L7AM) 機能よりも優先されます。既存の Shield Advanced のお客様は、既存のアカウントまたは新しい AWS アカウントでレガシーソリューションを引き続き使用できます。ただし、DDoS 対策 DDoS マネージドルールグループを採用することをお勧めします。Anti-DDoS Managed Rule Group は、攻撃を数分ではなく数秒以内に検出して軽減します。Shield Advanced の新規のお客様で、レガシーソリューションへのアクセスが必要な場合は、 AWS サポートにお問い合わせください。
このページでは、アプリケーションレイヤーの自動 DDoS 緩和のトピックを紹介し、関連する規制を一覧表示します。
攻撃の一部であるウェブリクエストをカウントまたはブロックすることで、保護されたアプリケーションレイヤーリソースに対するアプリケーションレイヤー (レイヤー 7) 攻撃を自動的に緩和して対応するよう Shield Advanced を設定できます。このオプションは、 AWS WAF ウェブ ACL と独自のレートベースのルールを使用して Shield Advanced を介して追加するアプリケーションレイヤー保護に追加されます。
リソースの自動緩和が有効になっている場合、Shield Advanced はリソースの関連するウェブ ACL にルールグループを管理し、リソースに代わって緩和ルールを管理します。ルールグループには、DDoS 攻撃のソースであることが判明している IP アドレスからのリクエストの量を追跡するレートベースのルールが含まれています。
さらに、Shield Advanced は、現在のトラフィックパターンと過去のトラフィックベースラインを比較して、DDoS 攻撃を示している可能性のある逸脱を検出します。Shield Advanced は、ルールグループに追加のカスタム AWS WAF ルールを作成、評価、デプロイすることで、検出された DDoS 攻撃に応答します。
## 自動アプリケーションレイヤー DDoS 緩和の使用に関する規制
次のリストでは、Shield Advanced アプリケーションレイヤー DDoS 自動緩和の注意事項と、対応が必要となる可能性があるステップについて説明します。
+ 自動アプリケーションレイヤー DDoS 緩和は、最新バージョンの (v2) を使用して作成された保護パック AWS WAF (ウェブ ACLs) でのみ機能します。
+ Shield Advanced には、アプリケーションの通常の履歴トラフィックのベースラインを確立する時間が必要です。これを活用して、攻撃トラフィックを検出して通常のトラフィックから分離し、攻撃トラフィックを軽減します。ベースラインを確立する時間は、ウェブ ACL を保護されたアプリケーションリソースに関連付ける時点から 24 時間から 30 日の間です。トラフィックベースラインの詳細については、[Shield Advanced によるアプリケーションレイヤーのイベント検出と緩和に影響する要因のリスト](ddos-app-layer-detection-mitigation.md) を参照してください。
+ 自動アプリケーションレイヤー DDoS 緩和を有効にすると、150 個の保護パック (ウェブ ACL) キャパシティユニット (WCU)。これらの WCU は、保護パック (ウェブ ACL) 内の WCU の使用量に対してカウントされます。詳細については「[Shield Advanced ルールグループによるアプリケーションレイヤーの保護](ddos-automatic-app-layer-response-rg.md)」および「[のウェブ ACL キャパシティユニット (WCUs) AWS WAF](aws-waf-capacity-units.md)」を参照してください。
+ Shield Advanced ルールグループは AWS WAF メトリクスを生成しますが、表示することはできません。これは、 AWS マネージドルールルールグループなど、保護パック (ウェブ ACL) で使用する他のルールグループと同じですが、所有していません。 AWS WAF メトリクスの詳細については、「」を参照してください[AWS WAF メトリクスとディメンション](waf-metrics.md)。Shield Advanced 保護オプションの機能については、[Shield Advanced によるアプリケーションレイヤー DDoS 自動緩和](#ddos-automatic-app-layer-response) を参照してください。
+ 複数のリソースを保護するウェブ ACL の場合、自動緩和は、どのリソースにも悪影響をおよぼさないカスタム緩和策のみを展開します。
+ DDoS 攻撃の開始から Shield Advanced がカスタム自動緩和ルールを実行するまでの時間は、各イベントによって異なります。一部の DDoS 攻撃は、カスタムルールがデプロイされる前に終了することがあります。他の攻撃は、緩和策が既に実施されている場合に発生する可能性があるため、これらのルールによってイベントの開始時から緩和される可能性があります。さらに、ウェブ ACL および Shield Advanced ルールグループのレートベースのルールは、潜在的なイベントとして検出される前に、攻撃トラフィックを軽減する可能性があります。
+ Amazon CloudFront などのコンテンツ配信ネットワーク (CDN) を介してトラフィックを受信する Application Load Balancer では、それらの Application Load Balancer リソース向けの Shield Advanced のアプリケーションレイヤーの自動緩和機能は低減します。Shield Advanced は、クライアントトラフィック属性を使用して、アプリケーションへの通常のトラフィックから攻撃トラフィックを識別および分離します。CDN は、元のクライアントトラフィック属性を保持または転送しない場合があります。CloudFront を使用する場合は、CloudFront ディストリビューションで自動緩和策を有効にすることをお勧めします。
+ アプリケーションレイヤー DDoS 自動緩和は、保護グループとインタラクションしません。保護グループに含まれるリソースのために自動緩和を有効にできますが、Shield Advanced は、保護グループの検出結果に基づいて攻撃の緩和策を自動的に適用しません。Shield Advanced は、個々のリソースのために攻撃の自動緩和を適用します。
**Contents**
+ [自動アプリケーションレイヤー DDoS 緩和の使用に関する規制](#ddos-automatic-app-layer-response-caveats)
+ [アプリケーションレイヤー DDoS 自動緩和機能を使用するためのベストプラクティス。](ddos-automatic-app-layer-response-bp.md)
+ [アプリケーションレイヤー DDoS 自動緩和の有効化](ddos-automatic-app-layer-response-config.md)
+ [自動緩和を有効にした場合の実行内容](ddos-automatic-app-layer-response-config.md#ddos-automatic-app-layer-response-enable)
+ [Shield Advanced が自動緩和を管理する方法](ddos-automatic-app-layer-response-behavior.md)
+ [Shield Advanced が自動緩和機能で DDoS 攻撃に対応する方法](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-ddos-attack)
+ [Shield Advanced がルールアクション設定を管理する方法](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-rule-action)
+ [攻撃が沈静化した場合に Shield Advanced が緩和を管理する方法](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-after-attack)
+ [自動緩和を無効にした場合の実行内容](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-disable)
+ [Shield Advanced ルールグループによるアプリケーションレイヤーの保護](ddos-automatic-app-layer-response-rg.md)
+ [リソースのアプリケーションレイヤー DDoS 自動緩和設定の表示](view-automatic-app-layer-response-configuration.md)
+ [アプリケーションレイヤー DDoS 自動緩和の有効化と無効化](enable-disable-automatic-app-layer-response.md)
+ [アプリケーションレイヤー DDoS 自動緩和に使用されるアクションの変更](change-action-of-automatic-app-layer-response.md)
+ [アプリケーションレイヤー DDoS 自動緩和 AWS CloudFormation での の使用](manage-automatic-mitigation-in-cfn.md)
# アプリケーションレイヤー DDoS 自動緩和機能を使用するためのベストプラクティス。
自動緩和機能を使用する場合は、このセクションに記載されているガイダンスを遵守してください。
**一般的な保護管理**
自動緩和保護を計画および実装する場合は、以下のガイドラインに従ってください。
+ Shield Advanced を通じて、または AWS Firewall Manager を使用して Shield Advanced 自動緩和設定を管理している場合は Firewall Manager を通じて、すべての自動緩和保護を管理します。これらの保護を管理するために Shield Advanced と Firewall Manager を合わせて使用しないでください。
+ 同一のウェブ ACL と保護設定を使用して類似のリソースを管理し、別々のウェブ ACL を使用して類似していないリソースを管理してください。Shield Advanced は、保護されたリソースに対する DDoS 攻撃を緩和する場合、リソースに関連付けられているウェブ ACL のルールを定義し、ウェブ ACL に関連付けられているすべてのリソースのトラフィックに対してルールをテストします。Shield Advanced は、関連付けられたリソースに悪影響を及ぼさない場合にのみルールを適用します。詳細については、「[Shield Advanced が自動緩和を管理する方法](ddos-automatic-app-layer-response-behavior.md)」を参照してください。
+ Amazon CloudFront ディストリビューションを介してすべてのインターネットトラフィックがプロキシされる Application Load Balancer では、CloudFront ディストリビューションでの自動緩和のみを有効にします。CloudFront ディストリビューションが持つ元のトラフィック属性の数は常に最大となります。これは、Shield Advanced が攻撃を緩和するために活用します。
**検出と緩和の最適化**
自動緩和が保護されたリソースに提供する保護を最適化するには、以下のガイドラインに従ってください。アプリケーションレイヤーの検出と緩和の概要については、[Shield Advanced によるアプリケーションレイヤーのイベント検出と緩和に影響する要因のリスト](ddos-app-layer-detection-mitigation.md) を参照してください。
+ 保護されたリソースのヘルスチェックを設定し、それを使用して Shield Advanced 保護でヘルスベースの検出を有効にします。ガイダンスについては、「[Shield Advanced と Route 53 を使用したヘルスチェックを使用したヘルスベースの検出](ddos-advanced-health-checks.md)」を参照してください。
+ Shield Advanced が通常の履歴トラフィックのベースラインを確立するまで、Count モードで自動緩和を有効にします。Shield Advanced では、ベースラインを確立するのに 24 時間から 30 日かかります。
通常のトラフィックパターンのベースラインを確立するには、以下が必要です:
+ ウェブ ACL と保護されたリソースとの関連。を使用してウェブ ACL AWS WAF を直接関連付けるか、Shield Advanced アプリケーションレイヤー保護を有効にして使用するウェブ ACL を指定するときに Shield Advanced に関連付けさせることができます。
+ 保護されたアプリケーションの通常のトラフィックフロー。アプリケーションの起動前など、アプリケーションに通常のトラフィックが発生していない場合や、本番環境のトラフィックが長期間不足している場合、履歴データを収集することはできません。
**ウェブ ACL 管理**
自動緩和で使用されるウェブ ACL を管理するには、以下のガイドラインに従ってください。
+ 保護されたリソースに関連付けられているウェブ ACL を置き換える必要がある場合は、次の変更を順番に行います。
1. Shield Advanced が自動緩和を管理する方法。
1. で AWS WAF、古いウェブ ACL の関連付けを解除し、新しいウェブ ACL を関連付けます。
1. Shield Advanced で自動緩和を管理します。
Shield Advanced は、古いウェブ ACL から新しいウェブ ACL に自動緩和を自動的に転送しません。
+ 名前が `ShieldMitigationRuleGroup` で始まるウェブ ACL からルールグループルールを削除しないでください。このルールグループを削除すると、ウェブ ACL に関連付けられているすべてのリソースについて、Shield Advanced 自動緩和機能によって提供される保護が無効になります。さらに、Shield Advanced が変更の通知を受け取り、設定を更新するのに時間がかかることがあります。この間、Shield Advanced コンソールページには誤った情報が表示されます。
ルールグループの詳細については、「[Shield Advanced ルールグループによるアプリケーションレイヤーの保護](ddos-automatic-app-layer-response-rg.md)」を参照してください。
+ 名前が `ShieldMitigationRuleGroup` で始まるルールグループルールの名前を変更しないでください。変更すると、ウェブ ACL を介して Shield Advanced 自動緩和機能によって提供される保護が妨げられる可能性があります。
+ ルールとルールグループを作成するときには、`ShieldMitigationRuleGroup` で始まる名前を使用しないでください。この文字列は、Shield Advanced が自動緩和を管理するために使用します。
+ ウェブ ACL ルールの管理では、優先順位の設定として 10,000,000 を割り当てないでください。Shield Advanced は、自動緩和ルールグループルールを追加するときに、この優先順位設定をそのルールグループルールに割り当てます。
+ `ShieldMitigationRuleGroup` ルールの優先順位を維持し、ウェブ ACL 内の他のルールと関連して必要なときに実行できるようにします。Shield Advanced は、優先順位を 10,000,000 に設定したルールグループルールをウェブ ACL に追加し、他のルールよりも後に実行します。 AWS WAF コンソールウィザードを使用してウェブ ACL を管理する場合は、ウェブ ACL にルールを追加した後、必要に応じて優先度設定を調整します。
+ AWS CloudFormation を使用してウェブ ACLs を管理する場合、`ShieldMitigationRuleGroup`ルールグループルールを管理する必要はありません。「[アプリケーションレイヤー DDoS 自動緩和 AWS CloudFormation での の使用](manage-automatic-mitigation-in-cfn.md)」のガイダンスに従います。
# アプリケーションレイヤー DDoS 自動緩和の有効化
このページでは、アプリケーションレイヤー攻撃に自動的に対応するように Shield Advanced を設定する方法について説明します。
Shield Advanced 自動緩和機能は、リソースのためのアプリケーションレイヤーの DDoS 保護の一部として有効にします。コンソールからこれを実行する方法については、「[アプリケーションレイヤー DDoS 保護を設定する](manage-protection.md#configure-app-layer-protection)」を参照してください。
自動緩和機能を使用するには、次の操作を行う必要があります。
+ **[Associate a web ACL with the resource]** (ウェブ ACL をリソースに関連付ける) – これは、Shield Advanced アプリケーションレイヤー保護のために必須です。複数のリソースに同じウェブ ACL を使用できます。同様のトラフィックを持つリソースについてのみ、これを行うことをお勧めします。ウェブ ACL を複数のリソースで使用するための要件など、ウェブ ACL の詳細については、「[の AWS WAF 仕組み](how-aws-waf-works.md)」を参照してください。
+ **[Enable and configure Shield Advanced automatic application layer DDoS mitigation]** (Shield Advanced アプリケーションレイヤー DDoS 自動緩和を有効にして設定する) – これを有効にする際に、Shield Advanced が DDoS 攻撃の一部であると判断したウェブリクエストを自動的にブロックまたはカウントするかどうかを指定します。Shield Advanced は、関連付けられたウェブ ACL にルールグループを追加し、それを使用して、リソースに対する DDoS 攻撃に対する対応を動的に管理します。ルールアクションのオプションについては、「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」を参照してください。
+ **(オプションですが、推奨されます) ウェブ ACL にレートベースのルールを追加する** – デフォルトでは、レートベースのルールは、個々の IP アドレスによる短時間の大量リクエスト送信を防ぐことで、DDoS 攻撃に対する基本的な保護をリソースに提供します。カスタムリクエストの集約オプションや例など、レートベースのルールの詳細については、「[でのレートベースのルールステートメントの使用 AWS WAF](waf-rule-statement-type-rate-based.md)」を参照してください。
## 自動緩和を有効にした場合の実行内容
Shield Advanced は、自動緩和を有効にすると、次の処理を実行します。
+ **必要に応じて、 は Shield Advanced 用のルールグループを追加します** – リソースに関連付けられた AWS WAF ウェブ ACL に、アプリケーションレイヤー DDoS 自動緩和専用の AWS WAF ルールグループルールがまだない場合、Shield Advanced はルールグループを追加します。
グループルールのルール名は `ShieldMitigationRuleGroup` で始まります。ルールグループには常に `ShieldKnownOffenderIPRateBasedRule` という名前のレートベースのルールが含まれており、DDoS 攻撃のソースであることが判明している IP アドレスからのリクエストの量を制限します。Shield Advanced ルールグループと参照するウェブ ACL ルールの詳細については、「[Shield Advanced ルールグループによるアプリケーションレイヤーの保護](ddos-automatic-app-layer-response-rg.md)」を参照してください。
+ **[Starts responding to DDoS attacks against the resource]** (リソースに対する DDoS 攻撃への対応を開始) – Shield Advanced は、保護されたリソースに対する DDoS 攻撃に自動的に対応します。常に存在するレートベースのルールに加えて、Shield Advanced はルールグループを使用して DDoS 攻撃の軽減のためのカスタム AWS WAF ルールをデプロイします。Shield Advanced は、これらのルールをアプリケーションとアプリケーションが経験する攻撃に合わせて調整し、デプロイする前にリソースの過去のトラフィックに照らし合わせてテストします。
Shield Advanced は、自動緩和に使用するウェブ ACL で単一のルールグループルールを使用します。Shield Advanced が、別の保護されたリソースのルールグループを追加している場合、ウェブ ACL には別のルールグループを追加しません。
アプリケーションレイヤー DDoS 自動緩和は、攻撃を緩和するためのルールグループの存在によって異なります。何らかの理由でルールグループが AWS WAF ウェブ ACL から削除された場合、削除はウェブ ACL に関連付けられているすべてのリソースの自動緩和を無効にします。
# Shield Advanced が自動緩和を管理する方法
このセクションのトピックでは、Shield Advanced がアプリケーションレイヤー DDoS 自動緩和の設定変更をどのように処理するか、および自動緩和が有効になっている場合の DDoS 攻撃の処理方法について説明します。
**Topics**
+ [Shield Advanced が自動緩和機能で DDoS 攻撃に対応する方法](#ddos-automatic-app-layer-response-ddos-attack)
+ [Shield Advanced がルールアクション設定を管理する方法](#ddos-automatic-app-layer-response-rule-action)
+ [攻撃が沈静化した場合に Shield Advanced が緩和を管理する方法](#ddos-automatic-app-layer-response-after-attack)
+ [自動緩和を無効にした場合の実行内容](#ddos-automatic-app-layer-response-disable)
## Shield Advanced が自動緩和機能で DDoS 攻撃に対応する方法
保護対象リソースで自動軽減機能を有効にすると、Shield Advanced ルールグループのレートベースのルール `ShieldKnownOffenderIPRateBasedRule` は、既知の DDoS ソースからのトラフィックの量の増加に自動的に応答します。このレート制限は迅速に適用され、攻撃に対する最前線の防御として機能します。
Shield Advanced が攻撃を検出すると、次の処理が実行されます。
1. アプリケーションへの通常のトラフィックから攻撃トラフィックを分離する攻撃シグネチャの特定を試みます。目標は、攻撃トラフィックにのみ影響し、アプリケーションへの通常のトラフィックに影響を与えない、質の高い DDoS 緩和ルールを作成することです。
1. 識別された攻撃シグネチャを、攻撃対象のリソースおよび同じウェブ ACL に関連付けられている他のリソースについての過去のトラフィックパターンに照らして評価します。Shield Advanced は、イベントに対応してルールをデプロイする前にこれを実行します。
Shield Advanced は、評価結果に応じて、次のいずれかを実行します。
+ Shield Advanced は、攻撃シグネチャが DDoS 攻撃に関与するトラフィックのみを隔離すると判断した場合、ウェブ ACL の Shield Advanced 緩和ルールグループの AWS WAF ルールにシグネチャを実装します。Shield Advanced は、これらのルールに、リソースの自動緩和のために設定したアクション設定 (Count または Block) を提供します。
+ その他の場合、Shield Advanced は緩和策を講じません。
攻撃全体を通じて、Shield Advanced は、基本的な Shield Advanced アプリケーションレイヤー保護と同じ通知を送信し、同じイベント情報を提供します。Shield Advanced イベントコンソールで、イベントと DDoS 攻撃に関する情報、および攻撃に対する Shield Advanced の緩和策に関する情報を確認できます。詳細については、「[Shield Advanced による DDoS イベントの可視性](ddos-viewing-events.md)」を参照してください。
Block ルールアクションを使用するように自動緩和を設定し、Shield Advanced がデプロイした緩和ルールからの誤検出が発生した場合は、ルールアクションを Count に変更できます。これを行う方法については、「[アプリケーションレイヤー DDoS 自動緩和に使用されるアクションの変更](change-action-of-automatic-app-layer-response.md)」を参照してください。
## Shield Advanced がルールアクション設定を管理する方法
自動緩和策のルールアクションは Block または Count に設定できます。
保護されたリソースの自動緩和ルールアクション設定を変更すると、Shield Advanced は、リソースのすべてのルール設定を更新します。Sheild Advanced ルールグループのリソースに現在適用されているルールが更新され、新しいルールの作成時に新しいアクション設定が使用されます。
同じウェブ ACL を使用するリソースに対して異なるアクションを指定すると、Shield Advanced はルールグループのレートベースのルール `ShieldKnownOffenderIPRateBasedRule` の Block アクション設定を使用します。Shield Advanced は、特定の保護対象リソースに代わってルールグループ内の他のルールを作成および管理し、リソースに指定したアクション設定を使用します。ウェブ ACL 内の Shield Advanced ルールグループのすべてのルールは、関連するすべてのリソースのウェブトラフィックに適用されます。
アクション設定を変更すると、反映されるまでに数秒かかる場合があります。この間、ルールグループが使用されている場所によっては古い設定が表示され、他の場所では新しい設定が表示される場合があります。
自動緩和設定のルールアクション設定は、コンソールのイベントページ、およびアプリケーションレイヤー設定ページで変更できます。イベントページの詳細については、「[での DDoS イベントへの対応 AWS](ddos-responding.md)」を参照してください。設定ページについては、「[アプリケーションレイヤー DDoS 保護を設定する](manage-protection.md#configure-app-layer-protection)」を参照してください。
## 攻撃が沈静化した場合に Shield Advanced が緩和を管理する方法
Shield Advanced は、特定の攻撃に対してデプロイされた緩和ルールが不要になったと判断すると、そのルールを Shield Advanced 緩和ルールグループから削除します。
緩和ルールの削除は、必ずしも攻撃の終了と一致しません。Shield Advanced は、保護されたリソースで検出された攻撃のパターンをモニタリングします。攻撃の最初の発生に対してデプロイしたルールを所定の位置に保持することで、特定のシグネチャを使用した攻撃の再発を先回りして防御できる場合があります。必要に応じて、Shield Advanced はルールを保持する時間枠を拡大します。このようにして、Shield Advanced は、保護されたリソースに影響が及ぶ前に、特定のシグネチャで繰り返される攻撃を緩和する場合があります。
Shield Advanced が、DDoS 攻撃のソースであることが判明している IP アドレスからのリクエストの量を制限するレートベースのルール `ShieldKnownOffenderIPRateBasedRule` を削除することはありません。
## 自動緩和を無効にした場合の実行内容
Shield Advanced は、リソースのための自動緩和を無効にすると、次の処理を実行します。
+ **[Stops automatically responding to DDoS attacks]** (DDoS 攻撃への自動対応を停止) – Shield Advanced は、リソースのための自動応答アクティビティを中止します。
+ **[Removes unneeded rules from the Shield Advanced rule group]** (Shield Advanced ルールグループから不要なルールを削除) – Shield Advanced が保護されたリソースのためにマネージドルールグループ内のルールを維持している場合、それらを削除します。
+ **[Removes the Shield Advanced rule group, if it's no longer in use]** (Shield Advanced ルールグループが使用されなくなった場合は削除) – リソースに関連付けたウェブ ACL が、自動緩和が有効になっている他のリソースに関連付けられていない場合、Shield Advanced は、そのルールグループルールをウェブ ACL から削除します。
# Shield Advanced ルールグループによるアプリケーションレイヤーの保護
このページでは、ウェブ ACL での Shield Advanced ルールグループの仕組みについて説明します。
Shield Advanced は、所有および管理するルールグループ内のルールを使用して、自動緩和アクティビティを管理します。Shield Advanced は、保護されたリソースに関連付けたウェブ ACL 内のルールを使用してルールグループを参照します。
**ウェブ ACL におけるルールグループルール**
ウェブ ACL の Shield Advanced ルールグループルールには、次のプロパティがあります。
+ **[Name]** (名前) – `ShieldMitigationRuleGroup``_account-id_web-acl-id_unique-identifier`
+ **[Web ACL capacity units (WCU)]** (ウェブ ACL キャパシティーユニット (WCU)) – 150。これらの WCU は、ウェブ ACL 内の WCU の使用量に対してカウントされます。
Shield Advanced は、優先度設定が 10,000,000 のウェブ ACL にこのルールを作成します。このルールは、ウェブ ACL の他のルールとルールグループがウェブ ACL のルールを、 上の最も低い数値優先度設定から AWS WAF 実行した後に実行されます。ウェブ ACL の管理中に、この優先順位の設定が変更される場合があります。
自動緩和機能は、ウェブ ACL のルール グループによって使用される WCU を除き、アカウント内の追加の AWS WAF リソースを消費しません。例えば、Shield Advanced ルールグループは、アカウントのルールグループの 1 つとしてカウントされません。のアカウント制限の詳細については AWS WAF、「」を参照してください[AWS WAF クォータ](limits.md)。
**ルールグループ内のルール**
参照先の Shield Advanced ルールグループ内では、Shield Advanced が DDoS 攻撃のソースであることが判明している IP アドレスからのリクエストの量を制限するレートベースのルール `ShieldKnownOffenderIPRateBasedRule` を維持します。このルールは常にルールグループに存在し、トラフィックパターンの分析に頼らずに攻撃を封じ込めるため、あらゆる攻撃に対する防御の最前線として機能します。このルールのアクションは、ルールグループの他のルールと同様に、自動緩和策で選択したアクションに設定されます。レートベースルールの詳細については、「[でのレートベースのルールステートメントの使用 AWS WAF](waf-rule-statement-type-rate-based.md)」を参照してください。
**注記**
レートベースのルール `ShieldKnownOffenderIPRateBasedRule` の動きは、Shield Advanced イベント検出とは無関係です。自動緩和が有効になっている間、このルールレートは DDoS 攻撃のソースとして知られている IP アドレスを制限します。これらの IP アドレスの場合、ルールのレート制限により、攻撃を防止し、Shield Advanced 検出情報に攻撃が表示されないようにすることができます。このトレードオフは、攻撃パターンを完全に可視化するよりも防止を優先します。
上記の永久レートベースのルールに加えて、ルールグループには、Shield Advanced が現在 DDoS 攻撃を軽減するために使用しているすべてのルールが含まれます。Shield Advanced は、必要に応じてこれらのルールを追加、変更、削除します。詳細については、「[Shield Advanced が自動緩和を管理する方法](ddos-automatic-app-layer-response-behavior.md)」を参照してください。
**メトリクス**
ルールグループは AWS WAF メトリクスを生成しますが、このルールグループは Shield Advanced によって所有されているため、これらのメトリクスを表示することはできません。詳細については、「[AWS WAF メトリクスとディメンション](waf-metrics.md)」を参照してください。
# リソースのアプリケーションレイヤー DDoS 自動緩和設定の表示
リソースのアプリケーションレイヤー DDoS 自動緩和設定は、**[保護リソース]** ページと個々の保護ページで表示できます。
**リソースのアプリケーションレイヤー DDoS 自動緩和設定を表示するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/) で AWS WAF & Shield コンソールを開きます。
1. AWS Shield ナビゲーションペインで、**保護されたリソース**を選択します。保護対象リソースのリストの **[アプリケーションレイヤー DDoS 自動緩和]** 列は、自動緩和が有効になっているかどうか、また有効になっている場合は緩和で Shield Advanced が使用するアクションを示します。
任意のアプリケーションレイヤーリソースを選択することによっても、リソースの保護ページにリストされているのと同じ情報を表示することもできます。
# アプリケーションレイヤー DDoS 自動緩和の有効化と無効化
次の手順では、保護されたリソースのための自動対応を有効または無効にする方法を示しています。
**単一のリソースのアプリケーションレイヤー DDoS 自動緩和を有効または無効にするには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/) で AWS WAF & Shield コンソールを開きます。
1. AWS Shield ナビゲーションペインで、**保護されたリソース**を選択します。
1. **[Protections]** (保護) タブで、自動緩和を有効にするアプリケーションレイヤーリソースを選択します。リソースの保護ページが開きます。
1. リソースの保護ページで、**[Edit]** (編集) を選択します。
1. **[グローバルリソース用のレイヤー 7 DDoS 緩和を設定 - *オプション*]** ページの **[アプリケーションレイヤー DDoS 自動緩和]** で、自動緩和に使用するオプションを選択します。コンソールのオプションを以下に示します。
+ **[Keep current settings]** (現在の設定を保持) — 保護されたリソースの自動緩和設定は変更されません。
+ **[Enable]** (有効化) — 保護されたリソースの自動緩和を有効にします。このオプションを選択する場合、ウェブ ACL ルールで使用するルールアクションも選択します。ルールアクションの設定については、「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」を参照してください。
保護されたリソースに通常のアプリケーショントラフィックの履歴がまだない場合は、Shield Advanced がベースラインを確立できるようになるまで、Count モードで自動緩和を有効にします。Shield Advanced は、ウェブ ACL を保護されたリソースに関連付けると、ベースラインの情報を収集し始めます。通常のトラフィックの適切なベースラインを確立するには 24 時間から 30 日間までかかる場合があります。
+ **[Disable]** (無効化) — 保護されたリソースの自動緩和を無効にします。
1. 残りのページを最後まで順を追って確認し、設定を保存します。
**[Protections]** (保護) ページで、リソースの自動軽減設定が更新されます。
# アプリケーションレイヤー DDoS 自動緩和に使用されるアクションの変更
コンソール内の複数の場所で、Shield Advanced がアプリケーションレイヤーの自動対応に使用するアクションを変更できます。
+ **[Automatic mitigation configuration]** (自動緩和設定) - リソースのための自動緩和を設定するときに、アクションを変更します。手順については、前のセクションの「[アプリケーションレイヤー DDoS 自動緩和の有効化と無効化](enable-disable-automatic-app-layer-response.md)」を参照してください。
+ **[Event details page]** (イベントの詳細ページ) – コンソールでイベント情報を表示しているときに、イベントの詳細ページでアクションを変更します。詳細については、「[AWS Shield Advanced イベントの詳細の表示](ddos-event-details.md)」を参照してください。
ウェブ ACL を共有する保護対象リソースが 2 つあり、一方のアクションを Count に、他方のアクションを Block に設定した場合、Shield Advanced はルールグループのレートベースのルール `ShieldKnownOffenderIPRateBasedRule` のアクションを Block に設定します。
# アプリケーションレイヤー DDoS 自動緩和 AWS CloudFormation での の使用
このページでは、 CloudFormation を使用して保護と AWS WAF ウェブ ACLs を管理する方法について説明します。
**アプリケーションレイヤー DDoS 自動緩和の有効化または無効化**
`AWS::Shield::Protection` リソースを使用して AWS CloudFormation、 を通じてアプリケーションレイヤー DDoS 自動緩和を有効または無効にできます。コンソールやその他のインターフェイスからでも、同じようにこの機能を有効または無効にできます。 CloudFormation リソースの詳細については、 *AWS CloudFormation ユーザーガイド*の[AWS::Shield::Protection](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-shield-protection.html)」を参照してください。
**自動緩和で使用されるウェブ ACL の管理**
Shield Advanced は、保護されたリソースの AWS WAF ウェブ ACL のルールグループルールを使用して、保護されたリソースの自動緩和を管理します。 AWS WAF コンソールと APIs を通じて、ウェブ ACL ルールに で始まる名前でリストされているルールが表示されます`ShieldMitigationRuleGroup`。このルールはアプリケーションレイヤー DDoS 自動緩和専用で、Shield Advanced と AWS WAFがユーザーに代わって管理します。詳細については、「[Shield Advanced ルールグループによるアプリケーションレイヤーの保護](ddos-automatic-app-layer-response-rg.md)」および「[Shield Advanced が自動緩和を管理する方法](ddos-automatic-app-layer-response-behavior.md)」を参照してください。
CloudFormation を使用してウェブ ACLs を管理する場合は、Shield Advanced ルールグループルールをウェブ ACL テンプレートに追加しないでください。自動緩和保護で使用されているウェブ ACL を更新すると、 はウェブ ACL のルールグループルール AWS WAF を自動的に管理します。
管理する他のウェブ ACLs と比較して、次の違いがあります CloudFormation。
+ CloudFormation は、Shield Advanced ルールグループルールを使用したウェブ ACL の実際の設定と、ルールを使用しないウェブ ACL テンプレートの間のスタックドリフトステータスのドリフトを報告しません。Shield Advanced ルールは、ドリフト詳細でリソースの実際のリストには表示されません。
Shield Advanced ルールグループルールは AWS WAF、コンソールや AWS WAF APIs など、 AWS WAF から取得したウェブ ACL リストで確認できます。
+ スタックでウェブ ACL テンプレートを変更 AWS WAF し、Shield Advanced が更新されたウェブ ACL で Shield Advanced 自動緩和ルールを自動的に維持する場合。Shield Advanced が提供する自動緩和保護は、ウェブ ACL を更新しても中断されることはありません。
CloudFormation ウェブ ACL テンプレートで Shield Advanced ルールを管理しないでください。ウェブ ACL テンプレートで Shield Advanced ルールを表示しないでください。「[アプリケーションレイヤー DDoS 自動緩和機能を使用するためのベストプラクティス。](ddos-automatic-app-layer-response-bp.md)」のウェブ ACL 管理のベストプラクティスに従ってください。
# Shield Advanced と Route 53 を使用したヘルスチェックを使用したヘルスベースの検出
ヘルスベースの検出を使用するように Shield Advanced を設定することで、攻撃の検出と緩和策の応答性と精度を改善できます。このオプションは、Route 53 ホストゾーンを除くすべてのリソースタイプで使用できます。
ヘルスベースの検出を設定するには、Route 53 でリソースのヘルスチェックを定義し、正常であると報告されていることを検証してから、Shield Advanced 保護と関連付けます。Route 53 ヘルスチェックの詳細については、「Amazon Route 53 デベロッパーガイド」の「[Amazon Route 53 がリソースのヘルスをチェックする方法](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/welcome-health-checks.html)」および「[ヘルスチェックの作成、更新、削除](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-deleting.html)」を参照してください。
**注記**
Shield Response Team (SRT) のプロアクティブなエンゲージメントサポートには、ヘルスチェックが必要です。プロアクティブなエンゲージメントの詳細については、「[SRT が直接連絡するためのプロアクティブエンゲージメントの設定](ddos-srt-proactive-engagement.md)」を参照してください。
ヘルスチェックでは、定義した要件に基づいて、リソースのヘルスを測定します。ヘルスチェックのステータスは、Shield Advanced 検出メカニズムに重要な入力を提供します。これにより、特定のアプリケーションの現在の状態に対する感度が向上します。
Route 53 ホストゾーンを除くリソースタイプのために、ヘルスベースの検出を有効にできます。
+ **ネットワークおよびトランスポートレイヤー (レイヤー 3 /レイヤー 4) のリソース** – ヘルスベースの検出により、ネットワークレイヤーおよびトランスポートレイヤーのイベント検出の精度と、Network Load Balancer、Elastic IP アドレス、および Global Accelerator 標準アクセラレーターのための緩和が改善されます。Shield Advanced を使用してこれらのリソースタイプを保護する場合、Shield Advanced は、トラフィックがアプリケーションの容量内である場合でも、小規模な攻撃の緩和と、攻撃のより迅速な緩和を行うことができます。
ヘルスベースの検出を追加する場合、関連付けられたヘルスチェックが異常な期間中に、Shield Advanced を使用してより迅速に、低いしきい値で緩和策を行えます。
+ **アプリケーションレイヤー (レイヤー 7) リソース** - ヘルスベースの検出により、CloudFront ディストリビューションおよび Application Load Balancer のウェブリクエストのフラッド検出の精度が向上します。Shield Advanced を使用してこれらのリソースタイプを保護する場合、リクエストの特性に基づいて、トラフィックパターンの大幅な変化を伴うトラフィック量の統計的に有意な偏差がある場合に、ウェブリクエストのフラッド検出アラートが送信されます。
ヘルスベースの検出では、関連付けられた Route 53 ヘルスチェックが異常な期間中に、Shield Advanced は、アラートするためにより小さな偏差を必要とし、より迅速にイベントを報告します。逆に、関連付けられた Route 53 ヘルスチェックが正常である場合、Shield Advanced では、アラートするためにより大きな偏差が必要です。
アプリケーションが許容可能なパラメータ内で実行されている場合にのみヘルスチェックが正常であることを報告し、そうでないときにのみ異常であることを報告する場合に、Shield Advanced におけるヘルスチェックの使用から最も大きな恩恵を受けることができます。このセクションのガイダンスを使用して、Shield Advanced でヘルスチェックの関連付けを管理します。
**注記**
Shield Advanced は、ヘルスチェックを自動的に管理しません。
Shield Advanced でヘルスチェックを使用するには、次が必要です。
+ ヘルスチェックは、Shield Advanced 保護に関連付けるときに、正常であると報告するものである必要があります。
+ ヘルスチェックは、保護されたリソースのヘルスに関連している必要があります。お客様は、アプリケーションの特定の要件に基づいて、アプリケーションのヘルスを正確に報告するヘルスチェックを定義し、維持する責任があります。
+ ヘルスチェックは、Shield Advanced 保護で使用できるようにしておく必要があります。Shield Advanced 保護に使用している Route 53 のヘルスチェックを削除しないでください。
**Contents**
+ [Shield Advanced でヘルスチェックを使用するためのベストプラクティス](health-checks-best-practices.md)
+ [Shield Advanced によるヘルスチェックに一般的に使用される CloudWatch メトリクス](health-checks-metrics.md)
+ [アプリケーションのヘルスをモニタリングするために使用されるメトリクス](health-checks-metrics.md#health-checks-metrics-common)
+ [各リソースタイプの Amazon CloudWatch メトリクス](health-checks-metrics.md#health-checks-protected-resource-metrics)
+ [Shield Advanced で保護されたリソースにヘルスチェックを関連付ける](associate-health-check.md)
+ [Shield Advanced で保護されたリソースとヘルスチェックの関連解除する](disassociate-health-check.md)
+ [Shield Advanced でのヘルスチェックの関連ステータスの表示](health-check-association-status.md)
+ [Shield Advanced のヘルスチェックの例](health-checks-examples.md)
+ [Amazon CloudFront ディストリビューション](health-checks-examples.md#health-checks-example-cloudfront)
+ [ロードバランサー](health-checks-examples.md#health-checks-example-load-balancer)
+ [Amazon EC2 Elastic IP アドレス (EIP)](health-checks-examples.md#health-checks-example-elastic-ip)
# Shield Advanced でヘルスチェックを使用するためのベストプラクティス
Shield Advanced でヘルスチェックを作成して使用する場合は、このセクションのベストプラクティスに従います。
+ モニタリングするインフラストラクチャのコンポーネントを特定して、ヘルスチェックを計画します。ヘルスチェックでは、次のリソースタイプを検討してください。
+ 重要なリソース。
+ Shield Advanced の検出と緩和で高感度が必要なリソース。
+ Shield Advanced からプロアクティブに通知を受けたいリソース。プロアクティブなエンゲージメントは、ヘルスチェックのステータスによって通知されます。
モニタリングする可能性のあるリソースの例には、Amazon CloudFront ディストリビューション、インターネット向けロードバランサー、Amazon EC2 インスタンスが含まれます。
+ 可能な限り少ない通知で、アプリケーションオリジンのヘルスを正確に反映するヘルスチェックを定義します。
+ アプリケーションが利用できない場合や許容可能なパラメータ内で動作しない場合のみ異常になるようにヘルスチェックを記述します。お客様は、アプリケーションの特定の要件に基づいてヘルスチェックを定義し、維持する責任があります。
+ アプリケーションのヘルスを引き続き正確に報告しながら、できる限り少ないヘルスチェックを使用します。例えば、すべてが同じ問題を報告するアプリケーションの複数の領域からの複数のアラームは、情報価値をもたらすことなく、レスポンスアクティビティにオーバーヘッドを追加する可能性があります。
+ 計算されたヘルスチェックを使用して、Amazon CloudWatch メトリクスの組み合わせを用いてアプリケーションのヘルスをモニタリングします。例えば、アプリケーションサーバーのレイテンシーと 5xx エラー率に基づいて、複合ヘルスを計算できます。これは、オリジンサーバーがリクエストを満たしていないことを示唆します。
+ 必要に応じて、独自のアプリケーションヘルスインジケーターを作成し、CloudWatch カスタムメトリクスに発行して、計算されたヘルスチェックで使用します。
+ ヘルスチェックを実装および管理して、検出を改善し、不要なメンテナンス作業を減らします。
+ ヘルスチェックを Shield Advanced 保護に関連付ける前に、ヘルスチェックが正常な状態であることを確認してください。異常を報告しているヘルスチェックを関連付けると、保護されたリソースに関する Shield Advanced 検出メカニズムが歪む可能性があります。
+ ヘルスチェックは Shield Advanced で使用できるようにしておきます。Shield Advanced 保護に使用している Route 53 のヘルスチェックを削除しないでください。
+ ステージング環境とテスト環境は、ヘルスチェックのテストにのみ使用します。本番稼働レベルのパフォーマンスと可用性を必要とする環境のヘルスチェックの関連付けのみを維持します。ステージングおよびテスト環境のために、Shield Advanced でヘルスチェックの関連付けを維持しないでください。
# Shield Advanced によるヘルスチェックに一般的に使用される CloudWatch メトリクス
このセクションには、Distributed Denial of Service (DDoS) イベント中のアプリケーションのヘルスを測定するためのヘルスチェックで一般的に使用される Amazon CloudWatch メトリクスが記載されています。各リソースタイプの CloudWatch メトリクスに関する詳細については、表の後のリストを参照してください。
**Topics**
+ [アプリケーションのヘルスをモニタリングするために使用されるメトリクス](#health-checks-metrics-common)
+ [各リソースタイプの Amazon CloudWatch メトリクス](#health-checks-protected-resource-metrics)
## アプリケーションのヘルスをモニタリングするために使用されるメトリクス
| リソース | メトリクス | 説明 |
| --- | --- | --- |
| Route 53 | `HealthCheckStatus` | ヘルスチェックエンドポイントのステータス。 |
| CloudFront | `5xxErrorRate` | HTTP ステータスコードが 5xx であるすべてのリクエストの割合。これは、アプリケーションに影響を与えている攻撃を示しています。 |
| Application Load Balancer | `HTTPCode_ELB_5XX_Count` | ロードバランサーによって生成された HTTP 5xx クライアントエラーコードの数。 |
| Application Load Balancer | `RejectedConnectionCount` | ロードバランサーが接続の最大数に達したため、拒否された接続の数。 |
| Application Load Balancer | `TargetConnectionErrorCount` | ロードバランサーとターゲット間で正常に確立されなかった接続数。 |
| Application Load Balancer | `TargetResponseTime` | リクエストがロードバランサーを離れてから、ターゲットからの応答を受信するまでの経過時間 (秒)。 |
| Application Load Balancer | `UnHealthyHostCount` | 異常とみなされるターゲットの数。 |
| Amazon EC2 | `CPUUtilization` | 割り当てられた EC2 コンピューティングユニットのうち、現在使用されているものの割合。 |
## 各リソースタイプの Amazon CloudWatch メトリクス
保護されたリソースのために使用できるメトリクスの詳細については、リソースガイドの次のセクションを参照してください。
+ Amazon Route 53 – 「Amazon Route 53 デベロッパーガイド」の「[Amazon Route 53 のヘルスチェックと Amazon CloudWatch を使用したリソースのモニタリング](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-cloudwatch.html)」。
+ Amazon CloudFront – 「Amazon CloudFront デベロッパーガイド」の「[Amazon CloudWatch による CloudFront のモニタリング](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/monitoring-using-cloudwatch.html)」。
+ Application Load Balancer – 「Application Load Balancer のユーザーガイド」の「[Application Load Balancer の CloudWatch メトリクス](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)」。
+ Network Load Balancer – 「Network Load Balancer のユーザーガイド」の「[Network Load Balancer の CloudWatch メトリクス](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html)」。
+ AWS Global Accelerator – [デベロッパーガイドの「 での Amazon CloudWatch AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/cloudwatch-monitoring.html) の使用」。 AWS Global Accelerator
+ Amazon Elastic Compute Cloud – https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ の「[インスタンスの利用可能な CloudWatch メトリクスのリスト表示](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html)」。
+ Amazon EC2 Auto Scaling – 「Amazon EC2 Auto Scaling ユーザーガイド」の「[Monitoring CloudWatch metrics for your Auto Scaling groups and instances](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)」(オートスケーリンググループおよびインスタンス用の CloudWatch メトリクスのモニタリング)。
# Shield Advanced で保護されたリソースにヘルスチェックを関連付ける
次の手順は、Amazon Route 53 ヘルスチェックを保護されたリソースに関連付ける方法を示しています。
**注記**
ヘルスチェックを Shield Advanced 保護に関連付ける前に、ヘルスチェックが正常な状態であることを確認してください。詳細については、「Amazon Route 53 デベロッパーガイド」の「[ヘルスチェックのステータスモニタリングと通知の受信](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-monitor-view-status.html)」を参照してください。
**ヘルスチェックを関連付けるには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/) で AWS WAF & Shield コンソールを開きます。
1. AWS Shield ナビゲーションペインで、**保護されたリソース**を選択します。
1. **[Protections]** (保護) タブで、ヘルスチェックに関連付けるリソースを選択します。
1. **[Configure protections]** (保護を設定) を選択します。
1. **[Configure health check based DDoS detection - *optional]*** (ヘルスチェックベースの DDoS 検出を設定 - オプション) ページが表示されるまで **[Next]** (次へ) を選択します。
1. **[Associated Health Check]** (ヘルスチェックを関連付ける) で、保護に関連付けるヘルスチェックの ID を選択します。
**注記**
必要なヘルスチェックが表示されない場合は、Route 53 コンソールに移動して、ヘルスチェックとその ID を検証します。詳細については、「[ヘルスチェックの作成と更新](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html)」を参照してください。
1. 設定を完了するまで残りのページを順を追って確認します。**[Protections]** (保護) ページに、リソースについて、更新されたヘルスチェックの関連付けが一覧表示されます。
1. **[Protections]** (保護) ページで、新しく関連付けられたヘルスチェックが正常であるとレポートされていることを確認します。
ヘルスチェックが異常を報告している間は、Shield Advanced でヘルスチェックの使用を正常に開始することはできません。そうすることで、Shield Advanced は非常に低いしきい値で誤検出を検出し、Shield Response Team (SRT) がリソースにプロアクティブなエンゲージメントを提供する能力にも悪影響を及ぼす可能性があります。
新しく関連付けられたヘルスチェックで異常が報告されている場合は、次の手順を実行します。
1. Shield Advanced で、ヘルスチェックと保護機能の関連付けを解除します。
1. Amazon Route 53 のヘルスチェックの仕様を再確認し、アプリケーション全体のパフォーマンスと可用性を検証します。
1. アプリケーションが良好なヘルスのためのパラメータ内で実行され、ヘルスチェックが正常であると報告している場合は、Shield Advanced でのヘルスチェックの関連付けをもう一度お試しください。
ヘルスチェックの関連付け手順は、新しいヘルスチェックの関連付けを確立し、Shield Advanced で正常であると報告されると完了します。
# Shield Advanced で保護されたリソースとヘルスチェックの関連解除する
次の手順は、保護されたリソースから Amazon Route 53 ヘルスチェックの関連付けを解除する方法を示しています。
**ヘルスチェックの関連付けを解除するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/) で AWS WAF & Shield コンソールを開きます。
1. AWS Shield ナビゲーションペインで、**保護されたリソース**を選択します。
1. **[Protections]** (保護) タブで、ヘルスチェックから関連付けを解除するリソースを選択します。
1. **[Configure protections]** (保護を設定) を選択します。
1. **[Configure health check based DDoS detection - *optional]*** (ヘルスチェックベースの DDoS 検出を設定 - オプション) ページが表示されるまで **[Next]** (次へ) を選択します。
1. **[Associated Health Check]** (関連付けられたヘルスチェック) で、**-** としてリストされている空のオプションを選択します。
1. 設定を完了するまで残りのページを順を追って確認します。
**[Protections]** (保護) ページでは、リソースのヘルスチェックフィールドが **-** に設定されます。これは、ヘルスチェックの関連付けがないことを示しています。
# Shield Advanced でのヘルスチェックの関連ステータスの表示
保護に関連付けられているヘルスチェックのステータスは、 AWS WAF & Shield コンソールの **[Protected resources]** (保護されたリソース) ページと各リソースの詳細ページで確認できます。
+ **[Healthy]** (正常) - ヘルスチェックが使用可能で、正常であると報告されています。
+ **[Unhealthy]** (異常) - ヘルスチェックが使用可能で、異常があると報告されています。
+ **[Unavailable]** (使用不可) - Shield Advanced によるヘルスチェックは使用できません。
****[Unavailable]** (使用不可) のヘルスチェックを解決するには**
新しいヘルスチェックを作成して使用します。Shield Advanced でステータスが使用不可になった後、ヘルスチェックを再度関連付けないでください。
これらのステップの実行に関する詳細なガイダンスについては、前のトピックを参照してください。
1. Shield Advanced で、リソースからヘルスチェックの関連付けを解除します。
1. Route 53 で、リソースの新しいヘルスチェックを作成し、その ID を記録します。詳細については、「Amazon Route 53 デベロッパーガイド」の「[ヘルスチェックの作成と更新](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html)」を参照してください。
1. Shield Advanced で、新しいヘルスチェックをリソースに関連付けます。
# Shield Advanced のヘルスチェックの例
このセクションは、計算されたヘルスチェックで使用できるヘルスチェックの例を示します。計算されたヘルスチェックでは、多数の個別のヘルスチェックを使用して、組み合わせたステータスを決定します。個々のヘルスチェックのステータスは、エンドポイントのヘルスまたは Amazon CloudWatch メトリクスの状態に基づきます。ヘルスチェックを計算されたヘルスチェックに組み込んでから、個々のヘルスチェックの組み合わせられたヘルスステータスに基づいてヘルスをレポートするように、計算されたヘルスチェックを設定します。アプリケーションのパフォーマンスと可用性の要件に応じて、計算されたヘルスチェックの感度をチューニングします。
計算されたヘルスチェックの詳細については、「Amazon Route 53 デベロッパーガイド」の「[他のヘルスチェック (算出したヘルスチェック) のモニタリング](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-values.html#health-checks-creating-values-calculated)」を参照してください。詳細については、「[Route 53 Improvements – Calculated Health Checks and Latency Checks](https://aws.amazon.com/blogs/aws/route-53-improvements-calculated-health-checks-and-latency-checks/)」(Route 53 の改善 – 計算されたヘルスチェックとレイテンシーチェック) のブログ記事を参照してください。
**Topics**
+ [Amazon CloudFront ディストリビューション](#health-checks-example-cloudfront)
+ [ロードバランサー](#health-checks-example-load-balancer)
+ [Amazon EC2 Elastic IP アドレス (EIP)](#health-checks-example-elastic-ip)
## Amazon CloudFront ディストリビューション
次の例では、CloudFront ディストリビューションの計算されたヘルスチェックと組み合わせることができるヘルスチェックについて説明します。
+ 動的コンテンツを提供するディストリビューション上のパスへのドメイン名を指定して、エンドポイントをモニタリングします。正常な応答には、HTTP レスポンスコード 2xx と 3xx が含まれます。
+ CloudFront オリジンのヘルスを測定する CloudWatch アラームの状態をモニタリングします。例えば、Application Load Balancer メトリクス `TargetResponseTime` で CloudWatch アラームを維持し、アラームのステータスを反映するヘルスチェックを作成できます。ヘルスチェックは、応答時間 (リクエストがロードバランサーから発信されてから、ロードバランサーがターゲットから応答を受け取るまでの時間) がアラームで設定されたしきい値を超えると、異常になることがあります。
+ レスポンスの HTTP ステータスコードが 5xx であるリクエストの割合を測定する CloudWatch アラームの状態をモニタリングします。CloudFront ディストリビューションの 5xx エラーレートが CloudWatch アラームで定義されたしきい値よりも高い場合、このヘルスチェックのステータスは異常に切り替わります。
## ロードバランサー
次の例では、Application Load Balancer、Network Load Balancer、または Global Accelerator 標準アクセラレーターの計算されたヘルスチェックで使用できるヘルスチェックについて説明します。
+ クライアントがロードバランサーに対して確立した新しい接続の数を測定する CloudWatch アラームの状態をモニタリングします。新しい接続の平均数に関するアラームのしきい値は、毎日の平均よりある程度高い値に設定できます。各リソースタイプのメトリクスは次のとおりです。
+ Application Load Balancer: `NewConnectionCount`
+ Network Load Balancer: `ActiveFlowCount`
+ Global Accelerator: `NewFlowCount`
+ Application Load Balancer および Network Load Balancer では、正常とみなされるロードバランサーの数を測定する CloudWatch アラームの状態をモニタリングします。アラームのしきい値は、アベイラビリティーゾーン、またはロードバランサーが必要とする最小数の正常なホストで設定できます。ロードバランサーのリソースで使用可能なメトリクスは次のとおりです。
+ Application Load Balancer: `HealthyHostCount`
+ Network Load Balancer: `HealthyHostCount`
+ Application Load Balancer では、ロードバランサーのターゲットによって生成された HTTP 5xx レスポンスコードの数を測定する CloudWatch アラームの状態をモニタリングします。Application Load Balancer の場合、メトリクス `HTTPCode_Target_5XX_Count` を使用して、ロードバランサーのすべての 5xx エラーの合計に基づいてアラームしきい値を設定できます。
## Amazon EC2 Elastic IP アドレス (EIP)
次のヘルスチェックの例を、Amazon EC2 Elastic IP アドレスの計算されたヘルスチェックに組み合わせることができます。
+ Elastic IP アドレスへの IP アドレスを指定して、エンドポイントをモニタリングします。IP アドレスの背後にあるリソースと TCP 接続を確立できる限り、ヘルスチェックは正常なままです。
+ 割り当てられた Amazon EC2 コンピューティングユニットのうち、現在インスタンス上で使用されているものが占める割合を測定する CloudWatch アラームの状態をモニタリングします。Amazon EC2 メトリクス `CPUUtilization` を使用して、高いと考えるアプリケーションの CPU 使用率 (90% など) に基づいてアラームしきい値を設定できます。
# AWS リソースへの AWS Shield Advanced 保護の追加
Shield Advanced 保護を 1 つ以上のリソースに追加するには、このセクションのガイダンスに従います。
**AWS リソースの保護を追加するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/) で AWS WAF & Shield コンソールを開きます。
1. ナビゲーションペインで、**保護されたリソース** AWS Shield を選択します。
1. **[Add resources to protect]** (保護するリソースを追加) を選択します。
1. **[Choose resources to protect with Shield Advanced]** (Shield Advanced で保護するリソースの選択) ページの **[Specify the Region and resource types]** (リージョンとリソースタイプの指定) で、保護するリソースのリージョンとリソースタイプの仕様を指定します。**[All Regions]** (すべてのリージョン) を選択すると複数のリージョンのリソースを保護でき、**[Global]** (グローバル) を選択すると選択範囲をグローバルリソースに絞り込むことができます。保護しないリソースタイプは、すべて選択解除できます。リソースタイプの保護については、「[が AWS Shield Advanced 保護するリソースのリスト](ddos-protections-by-resource-type.md)」を参照してください。
1. **[Load resources]** (リソースをロード) を選択します。Shield Advanced は、**[Select Resources]** (リソースの選択) セクションに条件に一致する AWS リソースを入力します。
1. **[Select Resources]** (リソースの選択) セクションでは、リソースリストで検索する文字列を入力して、リソースのリストをフィルタリングできます。
保護するリソースを選択します。
1. 作成しようとしている Shield Advanced 保護にタグを追加する場合は、**[Tags]** (タグ) セクションでそれらを指定します。 AWS リソースのタグ付けの詳細については、「[タグエディタの使用](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html)」を参照してください。
1. **[Protect with Shield Advanced]** (Shield Advanced で保護) を選択します。これにより、Shield Advanced 保護がリソースに追加されます。
# AWS Shield Advanced 保護の編集
AWS Shield Advanced 保護の設定はいつでも変更できます。これを行うには、選択した保護のオプションを確認し、変更する必要がある設定を変更します。
**保護されたリソースを管理するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/) で AWS WAF & Shield コンソールを開きます。
1. AWS Shield ナビゲーションペインで、**保護されたリソース**を選択します。
1. **[Protections]** (保護) タブで、保護するリソースを選択します。
1. 必要な **[Configure protections]** (保護を設定) とリソース指定オプションを選択します。
1. 各リソース保護オプションを順を追って確認し、必要に応じて変更を行います。
## アプリケーションレイヤー DDoS 保護を設定する
Amazon CloudFront および Application Load Balancer リソースに対する攻撃から保護するために、 AWS WAF ウェブ ACLs を追加したり、レートベースのルールを追加したりできます。詳細については、「[AWS WAF ウェブ ACLs と Shield Advanced によるアプリケーションレイヤーの保護](ddos-app-layer-web-ACL-and-rbr.md)」を参照してください。
Shield Advanced アプリケーションレイヤー DDoS 自動緩和機能を有効にすることもできます。の AWS WAF 仕組みについては、「」を参照してください[AWS WAF](waf-chapter.md)。自動緩和機能の詳細については、「[Shield Advanced によるアプリケーションレイヤー DDoS 自動緩和](ddos-automatic-app-layer-response.md)」を参照してください。
**重要**
Shield Advanced ポリシー AWS Firewall Manager を使用して を通じて Shield Advanced 保護を管理する場合、ここではアプリケーションレイヤー保護を管理することはできません。他のすべてのリソースについては、ウェブ ACL にルールが含まれていない場合でも、少なくとも各リソースにウェブ ACL をアタッチすることをお勧めします。
**注記**
リソースのためにアプリケーションレイヤー DDoS 自動緩和を有効にすると、必要に応じて、オペレーションは、サービスにリンクされたロールをアカウントに自動的に追加し、ウェブ ACL 保護の管理に必要な許可を Shield Advanced に付与します。詳細については、「[Shield Advanced のサービスにリンクされたロールの使用](shd-using-service-linked-roles.md)」を参照してください。
**アプリケーションレイヤー DDoS 保護を設定するには**
1. **[Configure layer 7 DDoS protections]** (レイヤー 7 DDoS 保護を設定) ページで、リソースがまだウェブ ACL に関連付けられていない場合は、既存のウェブ ACL を選択するか、独自のウェブ ACL を作成できます。
ウェブ ACL を作成するには、次のステップに従います。
1. **[Create web ACL]** (ウェブ ACL の作成) を選択します。
1. 名前を入力します。ウェブ ACL の作成後は、名前を変更することはできません。
1. **[Create]** (作成) を選択します。
**注記**
リソースが既にウェブ ACL に関連付けられている場合、別のウェブ ACL に変更することはできません。ACL を変更する場合は、最初にリソースから関連するウェブ ACL を削除します。詳細については、「[AWS リソースとの保護の関連付けまたは関連付け解除](web-acl-associating-aws-resource.md)」を参照してください。
1. ウェブ ACL にレートベースのルールが定義されていない場合は、**[Add rate limit rule]** (レート制限ルールを追加) を選択し、次のステップを実行してルールを追加できます。
1. 名前を入力します。
1. レート制限を入力します。これは、レートベースのルールアクションが IP アドレスに適用される前の任意の 5 分間に許可される、単一の IP アドレスからのリクエストの最大数です。IP アドレスからのリクエストが制限を下回ると、アクションは中止されます。
1. リクエストの数が制限を超えている間に IP アドレスからのリクエストをカウントまたはブロックするルールアクションを設定します。ルールアクションの適用と削除は、IP アドレスのリクエストレートが変更されてから有効になるまでに 1 ～ 2 分かかる場合があります。
1. **[Add Rule]** (ルールの追加) を選択します。
1. **[Automatic application layer DDoS mitigation]** (アプリケーションレイヤー DDoS 自動緩和) の場合、次のように、Shield Advanced がユーザーのために DDoS 攻撃を自動的に緩和するかどうかを選択します。
+ 自動緩和を有効にするには、**有効化** を選択し、Shield Advanced がカスタム AWS WAF ルールで使用するルールアクションを選択します。選択内容は Count と Block です。これらの AWS WAF ルールアクションの詳細については、「」を参照してください[でのルールアクションの使用 AWS WAF](waf-rule-action.md)。Shield Advanced がこのアクション設定を管理する方法については、「[Shield Advanced がルールアクション設定を管理する方法](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-rule-action)」を参照してください。
+ 自動緩和を無効にするには、**[Disable]** (無効化) を選択します。
+ 管理しているリソースの自動緩和設定を変更しない場合は、デフォルトの選択である **[Keep current settings]** (現在の設定を保持) のままにします。
Shield Advanced アプリケーションレイヤー DDoS 自動緩和の詳細については、「[Shield Advanced によるアプリケーションレイヤー DDoS 自動緩和](ddos-automatic-app-layer-response.md)」を参照してください。
1. [**次へ**] を選択します。
# Shield Advanced で保護されたリソースのアラームと通知の作成
次の手順では、保護されたリソースに関する CloudWatch アラームを管理する方法を示します。
**注記**
CloudWatch には追加料金が発生します。CloudWatch の料金については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)」を参照してください。
**アラームと通知を作成するには**
1. 保護に関する **[Create alarms and notifications - *optional*]** (アラームと通知を作成 - オプション) ページで、受け取るアラームと通知の SNS トピックを設定します。通知が不要なリソースでは、**[No topic]** (トピックなし) を選択します。Amazon SNS トピックを追加するか、新しいトピックを作成できます。
1. Amazon SNS トピックを作成するには、次のステップに従います。
1. ドロップダウンリストで、**[Create an SNS topic]** (SNS トピックを作成) を選択します。
1. トピック名を入力します。
1. オプションで、Amazon SNS メッセージの送信先メールアドレスを入力し、**[Add email]** (Eメールの追加) を選択します。複数入力できます。
1. **[Create]** (作成) を選択します。
1. [**次へ**] を選択します。
# AWS リソースからの AWS Shield Advanced 保護の削除
任意の AWS リソースからいつでも AWS Shield Advanced 保護を削除できます。
**重要**
AWS リソースを削除しても、リソースは削除されません AWS Shield Advanced。また、この手順で説明されているように AWS Shield Advanced、 からリソースに対する保護を削除する必要があります。
**AWS リソースから AWS Shield Advanced 保護を削除する**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/) で AWS WAF & Shield コンソールを開きます。
1. AWS Shield ナビゲーションペインで、**保護されたリソース**を選択します。
1. **[Protections]** (保護) タブで、保護を削除するリソースを選択します。
1. **[Delete protections]** (保護を削除) を選択します。
1. この保護用に設定された Amazon CloudWatch アラームがある場合は、このアラームを保護と一緒に削除するオプションが与えられます。この時点でアラームを削除しない場合は、代わりに CloudWatch コンソールを使用してアラームを後で削除することができます。
**注記**
Amazon Route 53 ヘルスチェックが設定されている保護は、後から再度追加した場合でも、保護にヘルスチェックが含まれます。
前述のステップでは、特定の AWS リソースから AWS Shield Advanced 保護を削除します。 AWS Shield Advanced サブスクリプションはキャンセルされません。このサービスに対しては引き続き料金が発生します。 AWS Shield Advanced サブスクリプションの詳細については、 [AWS サポート センター](https://console.aws.amazon.com/support/home#/)にお問い合わせください。
## CloudWatch アラームの Shield Advanced 保護からの削除
CloudWatch アラームを Shield Advanced 保護から削除するには、次のいずれかの操作を行います。
+ 「[AWS リソースからの AWS Shield Advanced 保護の削除](#remove-protection)」の説明に従って保護を削除します。**[Also delete related DDoSDetection alarm]** (関連する DDoSDetection アラームも削除する) の横にあるチェックボックスをオンにしてください。
+ CloudWatch コンソールを使用してアラームを削除します。削除するアラームの名前は、**DDoSDetectedAlarmForProtection** で始まります。
# AWS Shield Advanced 保護のグループ化
保護グループを使用して、保護されたリソースの論理コレクションを作成し、その保護をグループとして管理します。リソース保護の管理の詳細については、「[AWS Shield Advanced 保護の編集](manage-protection.md)」を参照してください。
**注記**
アプリケーションレイヤー DDoS 自動緩和は、保護グループとインタラクションしません。保護グループに含まれるリソースのために自動緩和を有効にできますが、Shield Advanced は、保護グループの検出結果に基づいて攻撃の緩和策を自動的に適用しません。Shield Advanced は、個々のリソースのために攻撃の自動緩和を適用します。
AWS Shield Advanced 保護グループを使用すると、複数の保護されたリソースを 1 つのユニットとして扱うことで、検出と緩和の範囲をセルフサービスでカスタマイズできます。リソースのグループ化は、多くのメリットをもたらす場合があります。
+ 検出の精度を向上させます。
+ 実行不可能なイベントの通知を減らします。
+ イベント中に影響を受ける可能性のある保護されたリソースを含めるように、緩和アクションの対象範囲を拡大します。
+ 複数の類似ターゲットに対する攻撃の緩和にかかる時間を短縮します。
+ 新しく作成された保護対象リソースの自動保護を容易にします。
保護グループは、リソースがゼロ負荷に近い状態と完全に負荷がかかっている状態を交互に繰り返すブルー/グリーンスワップなどの状況で誤検出を減らすのに役立ちます。もう 1 つの例は、グループのメンバー間で共有されるロードレベルを維持しながら、リソースを頻繁に作成および削除する場合です。このような状況では、個々のリソースをモニタリングすると誤検出が発生する可能性がありますが、リソースグループのヘルスのモニタリングでは発生しません。
保護グループを設定して、すべての保護されたリソース、特定のリソースタイプのすべてのリソース、または個別に指定したリソースを含めることができます。保護グループの基準を満たす新しく保護されたリソースは、自動的に保護グループに含まれます。保護されたリソースは、複数の保護グループに所属できます。
# Shield Advanced 保護グループの作成
**保護グループを作成するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/) で AWS WAF & Shield コンソールを開きます。
1. AWS Shield ナビゲーションペインで、**保護されたリソース**を選択します。
1. **[Protection groups]** (保護グループ) タブを選択してから、**[Create protection group]** (保護グループを作成) を選択します。
1. **[Create protection group]** (保護グループを作成) ページで、グループの名前を入力します。この名前を使用して、保護されたリソースのリスト内のグループを識別します。保護グループの作成後にその名前を変更することはできません。
1. **[Protection grouping criteria]** (保護のグループ化の基準) で、Shield Advanced がグループに含める保護されたリソースを識別するために使用する基準を選択します。選択した基準に基づいて追加の選択を行います。
1. **[Aggregation]** (集約) で、イベントの検出、緩和、およびレポートのために、Shield Advanced がグループのリソースデータをどのように組み合わせるかを選択します。
+ **[Sum]** (合計) – グループ全体のトラフィックの合計を使用します。これは、ほとんどの場合に適切な選択です。例には、手動または自動でスケールする Amazon EC2 インスタンスの Elastic IP アドレスが含まれます。
+ **[Mean]** (平均) – グループ全体のトラフィックの平均を使用します。これは、トラフィックを均一に共有するリソースに適した選択です。例には、アクセラレーターとロードバランサーが含まれます。
+ **[Max]** (最大) – 各リソースからの最大のトラフィックを使用します。これは、トラフィックを共有しないリソースや、不均一な方法でトラフィックを共有するリソースに有益です。例には、Amazon CloudFront ディストリビューションと CloudFront ディストリビューションのオリジンリソースが含まれます。
1. **[Save]** (保存) を選択して保護グループを保存し、**[Protected resources]** (保護されたリソース) ページに戻ります。
**[Shield** **Events]** (Shield イベント) ページでは、保護グループのイベントを表示し、ドリルダウンして、グループ内の保護されたリソースに関する追加情報を確認できます。
# Shield Advanced 保護グループの更新
**保護グループを更新するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/) で AWS WAF & Shield コンソールを開きます。
1. AWS Shield ナビゲーションペインで、**保護されたリソース**を選択します。
1. **[Protection groups]** (保護グループ) タブで、変更する保護グループの横にあるチェックボックスを選択します。
1. 保護グループのページで、**[Edit]** (編集) を選択します。保護グループの設定を変更します。
1. **[Save]** (保存) を選択して変更を保存します。
# Shield Advanced 保護グループの削除
**保護グループを削除するには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/) で AWS WAF & Shield コンソールを開きます。
1. AWS Shield ナビゲーションペインで、**保護されたリソース**を選択します。
1. **[Protection groups]** (保護グループ) タブで、削除する保護グループの横にあるチェックボックスを選択します。
1. 保護グループのページで、**[Delete]** (削除) を選択し、アクションを確認します。
# での Shield Advanced リソース保護の変更の追跡 AWS Config
このページでは、 を使用してリソース AWS Shield Advanced の保護に対する変更を記録する方法について説明します AWS Config。この情報を使用して、監査およびトラブルシューティングのために設定変更履歴を維持することができます。
保護の変更を記録するには、追跡するリソース AWS Config ごとに を有効にします。詳細については、「*AWS Config デベロッパーガイド*」の」「[AWS Configの使用開始](https://docs.aws.amazon.com/config/latest/developerguide/getting-started.html)」を参照してください。
追跡されたリソース AWS リージョン を含む各 AWS Config に対して を有効にする必要があります。 AWS Config 手動で を有効にすることも、 *CloudFormation ユーザーガイド*の StackSets サンプルテンプレートで CloudFormation テンプレート「有効化 AWS Config」を使用することもできます。 [CloudFormation StackSets ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-sampletemplates.html)
有効にすると AWS Config、[AWS Config 料金](https://aws.amazon.com/config/pricing/)表ページの説明に従って課金されます。
**注記**
必要なリージョンとリソースに対して を既に AWS Config 有効にしている場合は、リソースに対する保護の変更に関する . AWS Config logs が自動的に入力され始めます。
有効にしたら AWS Config、 AWS Config コンソールで米国東部 (バージニア北部) リージョンを使用して、 AWS Shield Advanced グローバルリソースの設定変更履歴を表示します。
米国東部 (バージニア北部）、米国東部 (オハイオ）、米国西部 (オレゴン）、米国西部 (北カリフォルニア）、欧州 (アイルランド）、欧州 (フランクフルト）、アジアパシフィック (東京）、アジアパシフィック (シドニー) の各リージョンで、 AWS Config コンソールを使用して AWS Shield Advanced リージョンリソースの変更履歴を表示します。
# Shield Advanced による DDoS イベントの可視性
AWS Shield は、以下のカテゴリのイベントとイベントアクティビティを可視化します。
+ **グローバル** – すべてのお客様は、直近 2 週間のグローバル脅威アクティビティの集約ビューにアクセスできます。この情報は、 AWS Shield コンソールの**「開始方法**」ページと**「グローバル脅威ダッシュボード**」ページに表示されます。詳細については、「[AWS Shield グローバルアクティビティとアカウントアクティビティの表示](ddos-standard-event-visibility.md)」を参照してください。
+ **アカウント** - すべてのお客様は、前年度のアカウントのイベントの概要にアクセスできます。この情報は、 AWS Shield コンソール**の開始方法**ページに表示されます。詳細については、「[AWS Shield グローバルアクティビティとアカウントアクティビティの表示](ddos-standard-event-visibility.md)」を参照してください。
Shield Advanced をサブスクライブしてリソースに保護を追加すると、保護されたリソースに対するイベントや DDoS 攻撃に関する追加情報にアクセスできます。
+ **保護されたリソースのイベント** – Shield Advanced は、 AWS Shield コンソールの**イベント**ページを通じて各イベントの詳細情報を提供します。詳細については、「[AWS Shield Advanced イベントの表示](ddos-events.md)」を参照してください。
+ **保護されたリソースのイベントメトリクス** – Shield Advanced は、保護するすべてのリソースの検出、緩和、上位寄稿者の Amazon CloudWatch メトリクスを発行します。これらのメトリクスを使用して、CloudWatch ダッシュボードとアラームを設定できます。詳細については、「[AWS Shield Advanced メトリクス](shield-metrics.md)」を参照してください。
+ **保護されたリソースのクロスアカウントイベントの可視性** – AWS Firewall Manager を使用して Shield Advanced 保護を管理する場合、Firewall Manager を組み合わせて使用することで、複数のアカウントにわたる保護の可視性を有効にできます AWS Security Hub CSPM。詳細については、「[AWS Firewall Manager と AWS アカウント を使用して複数の にまたがる Shield Advanced イベントを表示する AWS Security Hub CSPM](ddos-viewing-multiple-accounts.md)」を参照してください。
アプリケーションレイヤー保護の自動アプリケーションレイヤー DDoS 緩和を有効にすると、Shield Advanced は自動保護の管理に使用するルールグループを保護パック (ウェブ ACL) に追加します。このルールグループは AWS WAF メトリクスを生成しますが、表示することはできません。これは、 AWS マネージドルールルールグループなど、保護パック (ウェブ ACL) で使用する他のルールグループと同じですが、所有していません。 AWS WAF メトリクスの詳細については、「」を参照してください[AWS WAF メトリクスとディメンション](waf-metrics.md)。Shield Advanced 保護オプションの機能については、[Shield Advanced によるアプリケーションレイヤー DDoS 自動緩和](ddos-automatic-app-layer-response.md) を参照してください。
**Topics**
+ [AWS Shield グローバルアクティビティとアカウントアクティビティの表示](ddos-standard-event-visibility.md)
+ [AWS Shield Advanced イベントの表示](ddos-events.md)
+ [AWS Firewall Manager と AWS アカウント を使用して複数の にまたがる Shield Advanced イベントを表示する AWS Security Hub CSPM](ddos-viewing-multiple-accounts.md)
# AWS Shield グローバルアクティビティとアカウントアクティビティの表示
このページでは、 AWS Shield コンソールの**「開始方法」ページと「グローバル脅威ダッシュボード******」ページで、グローバル脅威アクティビティの集約ビューとアカウントごとのイベント概要にアクセスする手順について説明します。
次のスクリーンショットは、**[Getting Started]** (開始方法) ページの例を示しています。
![\[AWS Shield コンソールには、グローバル脅威とアカウントイベントの概要ペインを含む開始方法ページが表示されます。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/shield-console-global-account.png)
**AWS Shield コンソールにアクセスするには**
+ にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/) で AWS WAF & Shield コンソールを開きます。
グローバルアクティビティとアカウントイベントの概要情報にアクセスするために、Shield Advanced のサブスクリプションは必要ありません。
**グローバルアクティビティ**
この情報は、 AWS Shield コンソール**のグローバル脅威ダッシュボード**と**開始方法**ページから入手できます。次のスクリーンショットは、グローバルアクティビティペインの例を示しています。
![\[Shield によって検出されたグローバルアクティビティというタイトルの AWS Shield コンソールペインには、過去 2 週間にグローバル脅威が検出されたエリアのヒートマップマークが重ねられたワールドマップが表示されます。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/shield-console-global-activity.png)
グローバルアクティビティは、すべての AWS お客様に見られる DDoS イベントを記述します。1 時間に 1 回、 は過去 2 週間の情報 AWS を更新します。コンソールペインで、 AWS リージョンごとに分割され、ワールドヒートマップに表示される結果を確認できます。マップの横には、最大パケット攻撃、最大ビットレート、最も一般的なベクトル、Shield の総数、脅威レベルなどの概要情報が表示されます。脅威レベルは、 AWS が通常観察するものと比較した現在のグローバルアクティビティの評価です。デフォルトの脅威レベル値は **[Normal]** (通常) です。 AWS は、昇格された DDoS アクティビティの値を自動的に **[High]** (高) に更新します。
**[Global threat dashboard]** (グローバル脅威ダッシュボード) は、時系列メトリクスも提供し、期間の変更を可能にします。重大な DDoS 攻撃の履歴を表示するには、ダッシュボードをカスタマイズして、最終日から過去 2 週間までを表示できます。時系列メトリクスは、選択した時間枠 AWS 内に で実行されている AWS Shield アプリケーションについて、 によって検出されたすべてのイベントの最大ビットレート、パケットレート、またはリクエストレートを表示します。
**アカウントアクティビティ**
この情報は、 AWS Shield コンソール**の開始方法**ページにあります。
次のスクリーンショットは、アカウントアクティビティペインの例を示しています。
![\[Shield によって検出されたアカウントアクティビティというタイトルの AWS Shield コンソールペインには、過去 1 年間のイベントの概要と、イベントの合計数、最大パケットレート、リクエストレートなどの情報が表示されます。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/shield-console-account-activity.png)
アカウントアクティビティは、Shield Advanced による保護の対象となるリソースに関して Shield が検出した DDoS イベントを明らかにします。毎日、Shield は前日の 00:00 UTC で終わる 1 年の概要メトリクスを作成し、イベントの合計、最大ビットレート、最大パケットレート、および最大リクエストレートを表示します。
+ Shield がアプリケーションを宛先とするトラフィックで疑わしい属性を観察するたびに、合計イベントメトリクスで反映されます。疑わしい属性には、通常のボリュームよりも大きいトラフィック、アプリケーションの過去のプロファイルに一致しないトラフィック、有効なアプリケーショントラフィック用に Shield で定義されているヒューリスティックに一致しないトラフィックが含まる場合があります。
+ すべてのリソースで、最大ビットレートと最大のパケットレートの統計情報を使用できます。
+ 最大リクエストレート統計は、 AWS WAF ウェブ ACL が関連付けられている Amazon CloudFront ディストリビューションと Application Load Balancer でのみ使用できます。
**注記**
AWS Shield API オペレーション [DescribeAttackStatistics](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_DescribeAttack.html) を使用して、アカウントレベルのイベント概要にアクセスすることもできます。
# AWS Shield Advanced イベントの表示
このページでは、Shield Advanced のイベントに関する情報にアクセスする手順について説明します。
Shield Advanced をサブスクライブしてリソースを保護すると、リソースの追加の可視性機能にアクセスできます。これには、Shield Advanced によって検出されたイベントのほぼリアルタイムの通知や、検出されたイベントおよび緩和に関する追加情報が含まれます。
**注記**
Shield Advanced コンソールのイベント情報は、Shield Advanced メトリクスに基づいています。Shield Advanced メトリクスについては、[AWS Shield Advanced メトリクス](shield-metrics.md) を参照してください。
AWS Shield は、保護されたリソースへのトラフィックを複数のディメンションに沿って評価します。異常が検出されると、Shield Advanced は影響を受けるリソースごとに個別のイベントを作成します。
Shield コンソールの **[Events]** (イベント) ページからイベントの概要と詳細にアクセスできます。上位レベルの **[Events]** (イベント) ページには、現在および過去のイベントの概要が表示されます。
次のスクリーンショットは、単一の進行中のイベントを含む **[Events]** (イベント) ページの例を示しています。このアクティブなイベントには、左側のナビゲーションペインにもフラグが立てられます。
![\[AWS Shield コンソールの左側のナビゲーションペインでは、イベントの選択が赤で強調表示され、その横に赤い円の中に数字 1 が付きます。[Events] (イベント) ページが開き、イベントリストに 1 行が表示されます。行には、CloudFront ディストリビューションタイプの AWS リソースが一覧表示されます。[Current status] (現在のステータス) フィールドには、[Mitigation in progress] (緩和中) という語句の横に赤い三角形のアイコンが含まれています。[Attack vectors status] (攻撃ベクトルのステータス) フィールドには、[UDP traffic] (UDP トラフィック) が含まれています。[Start time] (開始時刻) フィールドには、「Sep 16th 2020, 2:43:00 pm SAST」と表示されています。[Duration] (期間) フィールドには「6 minutes」と表示されています。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/shield-console-event-summary1.png)
また、Shield Advanced は、トラフィックの種類と設定された保護に応じて、攻撃に対する緩和策を自動的に実施する場合があります。これらの緩和策により、過剰なトラフィックを受信したり、既知の DDoS 攻撃シグネチャに一致するトラフィックを受信したりしないようにリソースを保護できます。
次のスクリーンショットは、すべてのイベントが Shield Advanced によって緩和されたか、自然に沈静化した **[Events]** (イベント) のリストの例を示しています。
![\[Events というタイトルの AWS Shield コンソールページには、最近検出されたイベントとその現在のステータスが一覧表示されます。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/shield-console-events.png)
**イベントが発生する前にリソースを保護する**
DDoS 攻撃の対象となる前に、通常の予想トラフィックを受信している間に Shield Advanced でリソースを保護することで、イベント検出の精度を向上させます。
保護されたリソースのイベントを正確に報告するには、Shield Advanced はまずそのリソースの想定されるトラフィックパターンのベースラインを確立する必要があります。
+ Shield Advanced は、少なくとも 15 分間保護されたリソースのインフラストラクチャレイヤーイベントをレポートします。
+ Shield Advanced は、少なくとも 24 時間保護されたリソースのウェブアプリケーションレイヤーイベントをレポートします。アプリケーションレイヤーのイベントの検出精度は、Shield Advanced が 30 日間にわたって想定されるトラフィックをモニタリングした後に最適となります。
**AWS Shield コンソールでイベント情報にアクセスするには**
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/) で AWS WAF & Shield コンソールを開きます。
1. AWS Shield ナビゲーションペインで、**イベント**を選択します。コンソールに **[Events]** (イベント) ページが表示されます。
1. **[Events]** (イベント) ページから、リスト内の任意のイベントを選択して、イベントの追加の概要情報と詳細を表示できます。
**Topics**
+ [AWS Shield Advanced イベント概要のフィールドのリスト](ddos-event-summaries.md)
+ [AWS Shield Advanced イベントの詳細の表示](ddos-event-details.md)
# AWS Shield Advanced イベント概要のフィールドのリスト
このページでは、Shield Advanced イベント概要のフィールドを一覧表示して定義します。
イベントの概要と詳細情報は、イベントのコンソールページに表示できます。イベントのページを開くには、**イベント**ページリストからその AWS リソース名を選択します。
次のスクリーンショットは、ネットワークレイヤーイベントのイベント概要の例を示しています。
![\[AWS Shield コンソールイベントページの概要ペインには、イベントに関する情報が一覧表示され、影響を受ける AWS リソース、攻撃ベクトル、開始時刻と終了時刻、緩和情報とステータス情報が含まれます。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/shield-console-event-summary2.png)
イベントページの概要に関する情報には次が含まれます。
+ **[Current status]** (現在のステータス) - イベントの状態と Shield Advanced がイベントに対して実行したアクションを示す値。ステータス値は、インフラストラクチャレイヤー (レイヤー 3 または 4) およびアプリケーションレイヤー (レイヤー 7) のイベントに適用されます。
+ **[Identified (ongoing)]** (識別済み (進行中)) および **[Identified (subsided)]** (識別済み (沈静化済み)) – これらは、Shield Advanced がイベントを検出したが、これまでのところアクションを実行していないことを示します。**[Identified (subsided)]** (識別済み (沈静化済み)) は、Shield が検出した疑わしいトラフィックが介入なしに停止したことを示します。
+ **[Mitigation in progress]** (緩和中) および **[Mitigated]** (緩和済み) – これらは、Shield Advanced がイベントを検出し、それに対してアクションが実行されたことを示します。**[Mitigated]** (緩和済み) は、ターゲットリソースが Amazon CloudFront ディストリビューションまたは Amazon Route 53 ホストゾーンであり、独自の自動インライン緩和機能がある場合にも使用されます。
+ **[Attack vectors]** (攻撃ベクトル) - TCP SYN フラッドや Shield Advanced 検出ヒューリスティックなどの DDoS 攻撃ベクトル (リクエストフラッドなど)。これらは DDoS 攻撃を示している場合があります。
+ **[Start time]** (開始時刻) – 最初の異常なトラフィックデータポイントが検出された日時。
+ **[Duration or end time]** (期間または終了時刻) – イベントの開始時刻から Shield Advanced が最後に観察した異常なデータポイントまでの経過時間を示します。イベントが進行中であっても、これらの値は引き続き増加します。
+ **[Protection]** (保護) – リソースに関連付けられている Shield Advanced 保護に名前を付け、その保護ページへのリンクを提供します。これは、個々のイベントのページで確認できます。
+ **[Automatic application layer DDoS mitigation]** (アプリケーションレイヤーの DDoS の自動緩和) - Shield Advanced アプリケーションレイヤー DDoS 自動緩和がリソースのために有効になっているかどうかを示すために、アプリケーションレイヤーの保護に使用されます。有効になっている場合、これは、設定にアクセスして管理するためのリンクを提供します。これは、個々のイベントのページで確認できます。
+ **[Network layer automatic mitigation]** (ネットワークレイヤーの自動緩和) – リソースがネットワークレイヤーで自動緩和されているかどうかを示します。リソースにネットワークレイヤーコンポーネントがある場合、これは有効になります。この情報は、個々のイベントのページで入手できます。
頻繁にターゲットが設定されるリソースの場合、Shield は、さらに繰り返し発生するイベントを防ぐために、過剰なトラフィックが沈静化した後も緩和策をそのままにすることができます。
**注記**
AWS Shield API オペレーション [ListAttacks](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_ListAttacks.html) を通じて、保護されたリソースに関するイベントの概要にアクセスすることもできます。
# AWS Shield Advanced イベントの詳細の表示
イベントのコンソールページの下部のセクションで、イベントの検出、緩和策、および上位の寄稿者に関する詳細を確認できます。このセクションには、正当なトラフィックと望ましくないものである可能性があるトラフィックが混在している可能性があり、保護されたリソースに渡されたトラフィックと Shield 緩和によってブロックされたトラフィックの両方が表われている場合があります。
+ **[検出と緩和]** – 観察されたイベントと、それに対して適用された緩和策に関する情報を提供します。イベントの緩和については、「[での DDoS イベントへの対応 AWS](ddos-responding.md)」を参照してください。
+ **[上位の寄稿者]** – イベントに関係するトラフィックを分類し、Shield がカテゴリごとに特定したトラフィックの主要なソースを一覧表示します。アプリケーションレイヤーイベントの場合、上位の寄稿者情報を使用してイベントの性質に関する一般的なアイデアを取得しますが、セキュリティ上の意思決定には AWS WAF ログを使用します。詳細については、次のセクションを参照してください。
Shield Advanced コンソールのイベント情報は、Shield Advanced メトリクスに基づいています。Shield Advanced メトリクスについては、[AWS Shield Advanced メトリクス](shield-metrics.md) を参照してください。
Amazon CloudFront または Amazon Route 53 リソースには緩和メトリクスは含まれません。これらのサービスは、常に有効になっている緩和システムによって保護されており、個別のリソース用の緩和策を必要としないためです。
詳細セクションは、情報がインフラストラクチャ層またはアプリケーションレイヤーイベントのどちらに関するものであるかによって異なります。
**Topics**
+ [Shield Advanced でのアプリケーションレイヤー (レイヤー 7) イベントの詳細の表示](ddos-event-details-application-layer.md)
+ [Shield Advanced でのインフラストラクチャレイヤー (レイヤー 3 または 4) イベントの詳細の表示](ddos-event-details-infrastructure-layer.md)
# Shield Advanced でのアプリケーションレイヤー (レイヤー 7) イベントの詳細の表示
イベントの検出、緩和策、および上位の寄稿者に関する詳細は、イベントのコンソールページの下部のセクションで確認できます。このセクションには、正当なトラフィックと潜在的に望ましくないトラフィックの両方が含まれる可能性があり、保護対象のリソースに渡されたトラフィックと、Shield Advanced の緩和措置によってブロックされたトラフィックの両方を表す場合があります。
緩和策の詳細は、ウェブ ACL で定義されている攻撃やレートベースのルールに応じて特にデプロイされるルールなど、リソースに関連付けられているウェブ ACL 内のすべてのルールに関するものです。アプリケーションのアプリケーションレイヤー DDoS の自動緩和を有効にすると、緩和メトリクスにはこれらの追加ルールのメトリクスが含まれます。これらのアプリケーションレイヤー保護の詳細については、[AWS Shield Advanced および を使用したアプリケーションレイヤー (レイヤー 7) の保護 AWS WAF](ddos-app-layer-protections.md) を参照してください。
## 検出と緩和
アプリケーションレイヤー (レイヤー 7) イベントの場合、**検出と緩和**タブには、 AWS WAF ログから取得した情報に基づく検出メトリクスが表示されます。緩和メトリクスは、望ましくないトラフィックをブロックするように設定された、関連付けられたウェブ ACL の AWS WAF ルールに基づいています。
Amazon CloudFront ディストリビューションでは、自動緩和を適用するように Shield Advanced を設定できます。任意のアプリケーションレイヤーリソースを使用して、ウェブ ACL で独自の緩和ルールを定義することを選択したり、Shield レスポンスチーム (SRT、Shield Response Team) にサポートをリクエストしたりできます。これらのオプションについては、「[での DDoS イベントへの対応 AWS](ddos-responding.md)」を参照してください。
次のスクリーンショットは、数時間後に沈静化したアプリケーションレイヤーイベントの検出メトリクスの例を示しています。
![\[検出メトリクスグラフには、11:30 から 16:00 に沈静化するまでのリクエストフラッドトラフィックの検出が示されています。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/shield-app-detection-metrics.png)
緩和ルールが有効になる前に沈静化するイベントトラフィックは、緩和メトリクスに表れません。これにより、検出グラフに表示されるウェブリクエストのトラフィックと、緩和グラフに表示される許可およびブロックメトリクスが異なることがあります。
## 上位の寄稿者
アプリケーションレイヤーイベントの**上位寄与要因**タブには、Shield が取得した AWS WAF ログに基づいてイベントで特定した上位 5 つの寄与要因が表示されます。Shield は、上位の寄稿者情報をソースIP、送信元国、送信先 URLなどのディメンションで分類します。
**注記**
アプリケーションレイヤーイベントに寄与しているトラフィックに関する最も正確な情報については、 AWS WAF ログを使用します。
Shield アプリケーションレイヤーの上位の寄稿者情報は、攻撃の性質を大まかに把握するためにのみ使用し、それに基づいてセキュリティ上の決定を行うべきではありません。アプリケーションレイヤーイベントの場合、 AWS WAF ログは攻撃の寄与要因を理解し、緩和戦略を考案するための最適な情報源です。
Shield の上位寄与要因情報は、必ずしも AWS WAF ログにデータを完全に反映しているとは限りません。Shield は、ログを取り込む際に、ログから完全なデータを取得することよりも、システムパフォーマンスへの影響を減らすことを優先します。その結果、Shield で分析に使用できるデータの粒度が失われる可能性があります。ほとんどの場合、情報の大部分は入手可能ですが、上位の寄稿者のデータは、攻撃によってはある程度偏る可能性があります。
次のスクリーンショットは、アプリケーションレイヤーイベントの **[上位の寄稿者]** タブの例を示しています。
![\[アプリケーションレイヤーイベントの [上位の寄稿者] タブには、多くのウェブリクエスト特性の上位 5 位の寄稿者が表示されます。画面には、上位 5 位の送信元 IP アドレス、上位 5 位の送信先 URL、上位 5 位の送信元国、上位 5 位のユーザーエージェントが表示されます。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/shield-app-event-top-contributors.png)
コントリビューターに関する情報は、正当なトラフィックと望ましくない可能性があるトラフィックの両方に対するリクエストに基づいています。大量のイベントやリクエストソースが高度に分散されていないイベントは、識別可能な上位の寄稿者を持っている可能性が比較的高いです。大幅に分散した攻撃では、任意の数のソースが存在する可能性があり、攻撃の上位の寄稿者を特定することが困難です。Shield Advanced が特定のカテゴリの重要な寄稿者を特定しない場合、データは利用不可として表示されます。
# Shield Advanced でのインフラストラクチャレイヤー (レイヤー 3 または 4) イベントの詳細の表示
イベントのコンソールページの下部のセクションで、イベントの検出、緩和策、および上位の寄稿者に関する詳細を確認できます。このセクションには、正当なトラフィックと望ましくないものである可能性があるトラフィックが混在している可能性があり、保護されたリソースに渡されたトラフィックと Shield 緩和によってブロックされたトラフィックの両方が表われている場合があります。
## 検出と緩和
インフラストラクチャレイヤー (レイヤー 3 または 4) イベントの場合、**[Detection and mitigation]** (検出と緩和) タブには、サンプリングされたネットワークフローに基づく検出メトリクスと、緩和システムによって観察されたトラフィックに基づく緩和メトリクスが表示されます。緩和メトリクスは、リソースへのトラフィックをより正確に測定します。
Shield は、保護されたリソースタイプの緩和策 Elastic IP (EIP)、Classic Load Balancer (CLB)、Application Load Balancer (ALB)、および AWS Global Accelerator 標準アクセラレーターを自動的に作成します。EIP アドレスと AWS Global Accelerator 標準アクセラレーターの緩和メトリクスは、渡されたパケットとドロップされたパケットの数を示します。
次のスクリーンショットは、インフラストラクチャレイヤーイベントの **[Detection and mitigation]** (検出と緩和) タブの例を示しています。
![\[ネットワークイベントの検出グラフと緩和グラフでは、検出メトリクスの SYN フラッドトラフィックとパケットフラッドトラフィックが増加し、それに合わせて緩和メトリクスでは数秒後にトラフィックがドロップされる緩和策が増加していることがわかります。緩和策が増加してから約 30 秒後、トラフィックフラッドは停止します。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/shield-network-event-detection-mitigation.png)
Shield が緩和策を行う前に沈静化するイベントトラフィックは、緩和メトリクスに表れません。これにより、検出グラフに表示されるトラフィックと、緩和グラフに表示されるパスおよびドロップメトリクスが異なることがあります。
## 上位の寄稿者
インフラストラクチャレイヤーイベントの **[上位の寄稿者]** タブには、いくつかのトラフィックディメンションで最大 100 の上位の寄稿者に関するメトリクスが一覧表示されます。詳細には、少なくとも 5 つの重要なトラフィックソースを特定できる任意のディメンションのネットワークレイヤープロパティが含まれます。トラフィックのソースの例としては、ソース IP とソース ASN があります。
次のスクリーンショットは、インフラストラクチャレイヤーイベントの **[上位の寄稿者]** タブの例を示しています。
![\[ネットワークイベントの [上位の寄稿者] タブには、イベントに最も関与したトラフィックのカテゴリが表示されます。この場合のカテゴリには、プロトコル別のボリューム、プロトコルと宛先ポート別のボリューム、プロトコルと送信元 ASN 別のボリューム、TCP フラグ別のボリュームが含まれます。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/shield-network-event-top-contributors.png)
コントリビューターメトリクスは、正当なトラフィックと望ましくない可能性があるトラフィックの両方についてサンプリングされたネットワークフローに基づいています。大量のイベントやトラフィックソースが高度に分散されていないイベントは、識別可能な上位の寄稿者を持っている可能性が比較的高いです。大幅に分散した攻撃では、任意の数のソースが存在する可能性があり、攻撃に対する上位の寄稿者を特定することが困難です。Shield が特定のメトリクスまたはカテゴリの重要な寄稿者を特定しない場合、データは利用不可として表示されます。
インフラストラクチャレイヤー DDoS 攻撃では、トラフィックソースがスプーフィングまたはリフレクトされる可能性があります。スプーフィングされたソースは、攻撃者によって意図的に偽造されます。反映されたソースは、検出されたトラフィックの実際のソースですが、攻撃に積極的に参加しているわけではありません。例えば、攻撃者は、通常は正当なインターネット上のサービスの攻撃を反射して、ターゲットに対する大規模で増幅されたトラフィックのフラッドを生成する可能性があります。この場合、ソース情報は、有効ではあるものの、実際の攻撃元ではない可能性があります。これらの要因により、パケットヘッダーに基づいてソースをブロックする緩和技術の実行可能性が制限される可能性があります。
# AWS Firewall Manager と AWS アカウント を使用して複数の にまたがる Shield Advanced イベントを表示する AWS Security Hub CSPM
AWS Firewall Manager と を使用して AWS Security Hub CSPM 、複数のアカウントで AWS Shield Advanced 保護されたリソースを管理およびモニタリングできます。
Firewall Manager を使用すると、すべてのアカウントで DDoS 保護のコンプライアンスを報告および適用する Shield Advanced セキュリティポリシーを作成できます。Firewall Manager は、Shield Advanced ポリシーの対象となる新しいリソースへの保護の追加を含め、保護されたリソースをモニタリングします。
Firewall Manager を と統合 AWS Security Hub CSPM すると、Firewall Manager が Shield Advanced セキュリティポリシーに準拠していないリソースを特定したときに、Shield Advanced と Firewall Manager のコンプライアンス検出結果によって検出された DDoS イベントを報告する単一のダッシュボードを取得できます。
次の図は、Firewall Manager と Security Hub CSPM を使用して Shield Advanced で保護されたリソースをモニタリングするための一般的なアーキテクチャを示しています。
![\[図の上部には AWS Organizations アイコンがあります。下矢印があり、隣り合っている 2 つのアイコンをポイントするように分割されています。左側のアイコンにはタイトル「Production OU」が付けられており、右側のアイコンにはタイトル「Security OU」が付けられています。これらのアイコンの下には、左から右へのタイトルが付いた AWS Shield Advanced、 AWS Firewall Manager、 の 3 つのアイコンがあります AWS Security Hub CSPM。本番稼働用 OU アイコンには、Shield Advanced アイコンを指す下矢印があります。セキュリティ OU アイコンには、Firewall Manager と Security Hub CSPM アイコンを指すように分割された下向きの矢印があります。Shield Advanced アイコンには、「Shield Advanced protected resources」というタイトルが付いた長方形を指す下矢印があります。四角形の内部には、Application Load Balancer、CloudFront ディストリビューション、Elastic IP アドレスのアイコンがあります。Firewall Manager のアイコンには、Shield Advanced protected resources 長方形を指す下矢印もあり、Enforces compliance of protected resources ラベルが付いています。Shield Advanced アイコンには、DDoS alarm ラベルが付いた Firewall Manager アイコンを指す水平方向の矢印があります。Firewall Manager アイコンには、 というラベルの付いた Security Hub CSPM アイコンを指す水平矢印がありますDDoS alarm and compliance findings。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/shield-arch-fms-ash-integration.png)
Firewall Manager を Security Hub CSPM と統合すると、実行するアプリケーションの他のアラートやコンプライアンスステータス情報とともに、セキュリティ検出結果を 1 か所で表示できます AWS。
次のスクリーンショットは、このタイプの統合がある場合に Security Hub CSPM コンソール内で Shield Advanced イベントに表示される情報を示しています。
![\[このスクリーンショットは、Security Hub CSPM コンソールの結果ページ、字幕 検出結果はセキュリティの問題または失敗したセキュリティチェックです。このセクションには、[Title EQUALS Shield Advanced detected attack against monitored resource] (タイトル EQUALS Shield Advanced は、モニタリング対象リソースに対する攻撃を検出しました) および [Product name EQUAL Firewall Manager] (製品名 EQUAL Firewall Manager) の文字列を強調する赤いアウトラインがあります。画面には、特定の攻撃とそのステータスに関する詳細のセットが表示されます。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/shield-console-security-hub-event.png)
Firewall Manager と Security Hub CSPM を Shield Advanced と統合して、保護されたアカウント間でイベントとコンプライアンスのモニタリングを一元化する方法については、 AWS 「セキュリティブログ」の[DDoS イベントの集中モニタリングのセットアップ」および「非準拠リソースの自動修復](https://aws.amazon.com/blogs/security/set-up-centralized-monitoring-for-ddos-events-and-auto-remediate-noncompliant-resources/)」を参照してください。
# での DDoS イベントへの対応 AWS
このページでは、 が DDoS 攻撃にどのように AWS 応答するかを説明し、さらに応答する方法のオプションを提供します。
AWS は、ネットワークレイヤーとトランスポートレイヤー (レイヤー 3 とレイヤー 4) の DDoS 攻撃を自動的に軽減します。Shield Advanced を使用して Amazon EC2 インスタンスを保護する場合、攻撃を受けている最中に、Shield Advanced は、Amazon VPC ネットワーク ACL を AWS ネットワークの境界に自動的にデプロイします。これにより、Shield Advanced は、大規模な DDoS イベントに対する保護を提供できます。ネットワーク ACL の詳細については、「[ネットワーク ACL](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html)」を参照してください。
アプリケーションレイヤー (レイヤー 7) DDoS 攻撃の場合、CloudWatch AWS アラームを通じて AWS Shield Advanced 顧客を検出して通知しようとします。デフォルトでは、有効なユーザートラフィックが誤ってブロックされないように、緩和策は自動的に適用されません。
アプリケーションレイヤー (レイヤー 7) リソースでは、攻撃に対応するために次のオプションを使用できます。
+ **[Provide your own mitigations]** (独自の緩和策を提供する) – 独自に攻撃を調査して緩和することができます。詳細については、「[アプリケーションレイヤー DDoS 攻撃の手動による緩和](ddos-responding-manual.md)」を参照してください。
+ **[Contact support]** (サポートに問い合わせる) – Shield Advanced をご利用の場合は、[AWS サポート Center](https://console.aws.amazon.com/support/home#/) に問い合わせて緩和に関するサポートを受けることができます。重大かつ緊急のケースは DDoS エキスパートに直接、ルーティングされます。詳細については、「[アプリケーションレイヤー DDoS 攻撃を受けている最中のサポートセンターへの問い合わせ](ddos-responding-contact-support.md)」を参照してください。
さらに、攻撃が発生する前に、次の緩和オプションをプロアクティブに有効にできます。
+ **[Automatic mitigations on Amazon CloudFront distributions]** (Amazon CloudFront ディストリビューションでの自動緩和) - このオプションを使用すると、Shield Advanced は、ウェブ ACL で緩和ルールを定義および管理します。アプリケーションレイヤーの自動緩和の詳細については、「[Shield Advanced によるアプリケーションレイヤー DDoS 自動緩和](ddos-automatic-app-layer-response.md)」を参照してください。
+ **プロアクティブエンゲージメント** – がアプリケーションの 1 つに対する大規模なアプリケーションレイヤー攻撃 AWS Shield Advanced を検出すると、SRT はプロアクティブに連絡できます。SRT は DDoS イベントをトリアージし、 AWS WAF 緩和策を作成します。SRT はお客様に連絡し、お客様の同意を得て、 AWS WAF ルールを適用することができます。このオプションの詳細については、「[SRT が直接連絡するためのプロアクティブエンゲージメントの設定](ddos-srt-proactive-engagement.md)」を参照してください。
# アプリケーションレイヤー DDoS 攻撃を受けている最中のサポートセンターへの問い合わせ
このページでは、アプリケーションレイヤー DDoS 攻撃を受けている最中のサポートセンターへの問い合わせについて説明します。
AWS Shield Advanced のお客様は、 [AWS サポート センター](https://console.aws.amazon.com/support/home#/)に連絡して緩和策についてサポートを受けることができます。重大かつ緊急のケースは DDoS エキスパートに直接、ルーティングされます。では AWS Shield Advanced、複雑なケースを AWS Shield Response Team (SRT) にエスカレーションできます。SRT は AWS、、Amazon.com とその子会社の保護において豊富な経験を持っています。SRT 関数の詳細については、「[Shield Response Team (SRT) サポートによるマネージド DDoS イベントレスポンス](ddos-srt-support.md)」を参照してください。
Shield Response Team (SRT) のサポートを受けるには、[AWS サポート Center](https://console.aws.amazon.com/support/home#/) に問い合わせてください。ケースへの応答時間は、選択した重要度と応答回数によって異なります (「[AWS サポート プラン](https://aws.amazon.com/premiumsupport/compare-plans/)」ページを参照)。
次のオプションを選択してください。
+ ケースタイプ: テクニカルサポート
+ サービス: Distributed Denial of Service (DDoS)
+ カテゴリ: へのインバウンド AWS
+ 重要度: *適切なオプションを選択してください*
担当者と話し合うときは、お客様が DDoS 攻撃の可能性がある AWS Shield Advanced と説明してください。担当者がお客様の問い合わせを適切な DDoS エキスパートに取り次ぎます。**[Distributed Denial of Service (DDoS)]** サービスタイプを使用して [AWS サポート Center](https://console.aws.amazon.com/support/home#/) でケースを開いた場合は、チャットや電話で DDoS エキスパートと直接お話しいただけます。DDoS サポートエンジニアは、攻撃の特定、 AWS アーキテクチャの改善の推奨、DDoS 攻撃の軽減のための AWS サービスの使用に関するガイダンスの提供を支援します。
アプリケーションレイヤー攻撃の場合、SRT は疑わしいアクティビティを分析するのをサポートします。リソースについて自動緩和が有効になっている場合、SRT は Shield Advanced が攻撃に対して自動的に実施している緩和策を確認できます。いずれの場合でも、SRT は問題の確認と緩和をサポートできます。SRT が推奨する緩和策では、多くの場合、SRT がアカウントで AWS WAF ウェブアクセスコントロールリスト (ウェブ ACLs) を作成または更新する必要があります。SRT がこの作業を行うには、お客様の許可が必要となります。
**重要**
有効化の一環として AWS Shield Advanced、[SRT へのアクセスの許可](ddos-srt-access.md)「」の手順に従って、攻撃中に支援するために必要なアクセス許可を SRT に事前に提供することをお勧めします。事前に許可を付与することで、実際に攻撃が発生した場合の遅延を防ぐことができます。
SRT は、DDoS 攻撃を分類して、攻撃シグネチャとパターンを識別できるようにお客様を支援します。お客様の同意を得て、SRT は攻撃を軽減するための AWS WAF ルールを作成してデプロイします。
また、緩和策を確認したり、カスタム緩和策を開発してデプロイしたりするために、攻撃の可能性が生じる前であっても、または生じている最中に SRT に問い合わせることもできます。例えば、ウェブアプリケーションを実行していて、ポート 80 と 443 だけを開く必要がある場合は、SRT と連携してポート 80 と 443 だけを [Allow] (許可) するようにウェブ ACL を事前設定できます。
SRT への連絡と承認はアカウントレベルで行います。つまり、Firewall Manager Shield Advanced ポリシー内で Shield Advanced を使用する場合、アカウント所有者 (Firewall Manager 管理者ではない) は SRT にサポートを依頼する必要があります。Firewall Manager 管理者は、所有しているアカウントに関してのみ SRT に問い合わせることができます。
# アプリケーションレイヤー DDoS 攻撃の手動による緩和
このページでは、アプリケーションレイヤーの DDoS 攻撃を手動で軽減する手順について説明します。
リソースのイベントページのアクティビティが DDoS 攻撃を表していると判断した場合は、ウェブ ACL に独自の AWS WAF ルールを作成して攻撃を軽減できます。これは、Shield Advanced のお客様でない場合に使用できる唯一のオプションです。 AWS WAF は追加料金なしで AWS Shield Advanced に含まれています。ウェブ ACL でのルール作成の詳細については、「[での保護の設定 AWS WAF](web-acl.md)」を参照してください。
を使用する場合は AWS Firewall Manager、Firewall Manager AWS WAF ポリシーに AWS WAF ルールを追加できます。
**アプリケーションレイヤー DDoS 攻撃の可能性がある状況を手動で緩和するには**
1. 異常な動作に一致する条件を使用して、ウェブ ACL にルールステートメントを作成します。まず、一致するリクエストをカウントするように設定します。ウェブ ACL およびルールステートメントの設定については、「[のルールとルールグループで保護パック (ウェブ ACLs) を使用する AWS WAF](web-acl-processing.md)」および「[AWS WAF 保護のテストとチューニング](web-acl-testing.md)」を参照してください。
**注記**
最初に Block の代わりにルールアクション Count を使用して、常に最初にルールをテストしてください。新しいルールが正しいリクエストを識別していることを確認した後、リクエストをブロックするためにそれらを変更できます。
1. リクエスト数をモニタリングして、一致するリクエストをブロックするかどうかを決定します。リクエストの量が異常に多い状況が継続しており、そのような状況を引き起こしているリクエストをルールがキャプチャしていると確信できる場合は、ウェブ ACL のルールを変更してそのリクエストをブロックします。
1. イベントページのモニタリングを続行して、トラフィックが希望どおりに処理されるようにします。
AWS には、すぐに使用を開始できるように事前設定されたテンプレートが用意されています。テンプレートには、一般的なウェブベースの攻撃をブロックするためにカスタマイズして使用できる一連の AWS WAF ルールが含まれています。詳細については、「[AWS WAF セキュリティオートメーション](https://aws.amazon.com/solutions/aws-waf-security-automations/)」を参照してください。
# 攻撃 AWS Shield Advanced 後の でのクレジットのリクエスト
にサブスクライブ AWS Shield Advanced していて、Shield Advanced で保護されたリソースの使用率を高める DDoS 攻撃が発生した場合は、Shield Advanced によって軽減されない範囲で、使用率の増加に関連する料金に対して Shield Advanced サービスクレジットをリクエストできます。
**注記**
このプロセスを通じて受け取ったクレジットは、Shield Advanced の使用にのみ適用できます。Shield Advanced クレジットは、他のサービスでは使用できません。
クレジットは、次のタイプの請求でのみ使用できます。
+ Shield Advanced データ転送アウト
+ Amazon CloudFront HTTP/HTTPS リクエスト
+ CloudFront データ転送アウト
+ Amazon Route 53 クエリ
+ AWS Global Accelerator 標準アクセラレーターデータ転送
+ Application Load Balancer のロードバランサー容量ユニット
+ 攻撃に対応して自動スケーリングポリシーによって作成、保護された Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのインスタンスコスト
**クレジットをリクエストするための前提条件**
クレジットの付与を受けるための要件を満たすには、攻撃が始まる前に、次のことを完了している必要があります。
+ クレジットをリクエストするリソースに Shield Advanced 保護を追加しておく必要があります。攻撃を受けている最中に追加された保護対象リソースは、コスト保護の対象外です。
**注記**
で Shield Advanced を有効に AWS アカウント しても、個々のリソースに対して Shield Advanced 保護が自動的に有効になるわけではありません。
Shield Advanced を使用して AWS リソースを保護する方法の詳細については、「」を参照してください[AWS リソースへの AWS Shield Advanced 保護の追加](configure-new-protection.md)。
+ 該当する CloudFront および Application Load Balancer で保護されたリソースについては、 AWS WAF ウェブ ACL を関連付け、 Block モードでウェブ ACL にレートベースのルールを実装している必要があります。 AWS WAF のレートベースルールの詳細については、「[でのレートベースのルールステートメントの使用 AWS WAF](waf-rule-statement-type-rate-based.md)」を参照してください。ウェブ ACLs「」を参照してください[での保護の設定 AWS WAF](web-acl.md)。 AWS
+ DDoS 攻撃を受けている最中のコストを最小限に抑えるようにアプリケーションを設定するには、「[DDoS レジリエンシーに関するAWS のベストプラクティス](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency)」の適切なベストプラクティスを実装しておく必要があります。
**クレジットの申請方法**
クレジットの付与を受けるために要件を満たすには、攻撃が発生した請求月の直後から 15 日以内にクレジットリクエストを送信する必要があります。
クレジットを申請するには、[AWS サポート Center](https://console.aws.amazon.com/support/home#/) を通じて請求ケースを提出してください。リクエストには次の内容を含めます。
+ 件名の「DDoS Concession」という文字
+ クレジットをリクエストしている各イベントまたは可用性の中断の日時
+ 影響を受けた AWS サービスと特定のリソース
リクエストを送信すると、Shield Response Team (SRT) AWS は DDoS 攻撃が発生したかどうか、発生した場合は、保護されたリソースが DDoS 攻撃を吸収するためにスケーリングされたかどうかを検証します。が、 AWS 保護されたリソースが DDoS 攻撃を吸収するためにスケールされたと判断した場合、 AWS は が DDoS 攻撃によって引き起こされた AWS と判断したトラフィックのその部分にクレジットを発行します。クレジットは 12 か月間有効です。
# AWS Shield サービスの使用におけるセキュリティ
このセクションでは、 責任共有モデルがどのように適用されるかについて説明します AWS Shield。
でのクラウドセキュリティが最優先事項 AWS です。お客様は AWS 、セキュリティを最も重視する組織の要件を満たすように構築されたデータセンターとネットワークアーキテクチャを活用できます。
**注記**
このセクションでは、Shield Advanced 保護など、 AWS Shield サービスとその AWS リソースの使用に関する標準的な AWS セキュリティガイダンスを提供します。
Shield と Shield Advanced を使用して AWS リソースを保護する方法については、この AWS Shield ガイドの残りの部分を参照してください。
セキュリティは、 AWS とお客様の間の責任共有です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)では、これをクラウドのセキュリティおよびクラウド内のセキュリティとして説明しています。
+ **クラウドのセキュリティ** – AWS は、 で AWS サービスを実行するインフラストラクチャを保護する責任を担います AWS クラウド。 は、お客様が安全に使用できるサービス AWS も提供します。セキュリティの有効性は、[AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)の一環として、サードパーティーの審査機関によって定期的にテストおよび検証されています。Shield に適用するコンプライアンスプログラムの詳細については、「[コンプライアンスプログラムによる対象範囲内のAWS のサービス](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。
+ **クラウドのセキュリティ** – お客様の責任は、使用する AWS サービスによって決まります。また、お客様は、お客様のデータの機密性、組織の要件、および適用可能な法律および規制などの他の要因についても責任を担います。
このドキュメントは、Shield を使用する際に責任共有モデルを適用する方法を理解するのに役立ちます。次のトピックでは、セキュリティとコンプライアンスの目的を達成するために Shield を設定する方法を示します。また、Shield リソースのモニタリングや保護に役立つ他の AWS サービスの使用方法についても説明します。
**Topics**
+ [Shield でのデータの保護](shd-data-protection.md)
+ [での IAM の使用 AWS Shield](shd-security-iam.md)
+ [Shield でのログ記録とモニタリング](shd-incident-response.md)
+ [Shield でのコンプライアンス検証](shd-security-compliance.md)
+ [Shield での耐障害性の構築](shd-disaster-recovery-resiliency.md)
+ [のインフラストラクチャセキュリティ AWS Shield](shd-infrastructure-security.md)
# Shield でのデータの保護
このセクションでは、Shield でのデータ保護に 責任 AWS 共有モデルがどのように適用されるかについて説明します。
責任 AWS [共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)、 でのデータ保護に適用されます AWS Shield。このモデルで説明されているように、 AWS はすべての を実行するグローバルインフラストラクチャを保護する責任があります AWS クラウド。ユーザーは、このインフラストラクチャでホストされるコンテンツに対する管理を維持する責任があります。また、使用する「 AWS のサービス 」のセキュリティ設定と管理タスクもユーザーの責任となります。データプライバシーの詳細については、[データプライバシーに関するよくある質問](https://aws.amazon.com/compliance/data-privacy-faq/)を参照してください。欧州でのデータ保護の詳細については、*AWS セキュリティブログ*に投稿された「[AWS 責任共有モデルおよび GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/)」のブログ記事を参照してください。
データ保護の目的で、認証情報を保護し AWS アカウント 、 AWS IAM アイデンティティセンター または AWS Identity and Access Management (IAM) を使用して個々のユーザーを設定することをお勧めします。この方法により、それぞれのジョブを遂行するために必要な権限のみが各ユーザーに付与されます。また、次の方法でデータを保護することもお勧めします:
+ 各アカウントで多要素認証 (MFA) を使用します。
+ SSL/TLS を使用して AWS リソースと通信します。TLS 1.2 は必須ですが、TLS 1.3 を推奨します。
+ で API とユーザーアクティビティのログ記録を設定します AWS CloudTrail。CloudTrail 証跡を使用して AWS アクティビティをキャプチャする方法については、「 *AWS CloudTrail ユーザーガイド*」の[CloudTrail 証跡の使用](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)」を参照してください。
+ AWS 暗号化ソリューションと、 内のすべてのデフォルトのセキュリティコントロールを使用します AWS のサービス。
+ Amazon Macie などの高度な管理されたセキュリティサービスを使用します。これらは、Amazon S3 に保存されている機密データの検出と保護を支援します。
+ コマンドラインインターフェイスまたは API AWS を介して にアクセスするときに FIPS 140-3 検証済み暗号化モジュールが必要な場合は、FIPS エンドポイントを使用します。利用可能な FIPS エンドポイントの詳細については、「[連邦情報処理規格 (FIPS) 140-3](https://aws.amazon.com/compliance/fips/)」を参照してください。
お客様の E メールアドレスなどの極秘または機密情報を、タグ、または **[名前]** フィールドなどの自由形式のテキストフィールドに含めないことを強くお勧めします。これは、コンソール、API、または SDK を使用して Shield AWS CLIまたは他の AWS のサービス を使用する場合も同様です。 AWS SDKs タグ、または名前に使用される自由記述のテキストフィールドに入力したデータは、請求または診断ログに使用される場合があります。外部サーバーに URL を提供する場合、そのサーバーへのリクエストを検証できるように、認証情報を URL に含めないことを強くお勧めします。
Shield のエンティティ (保護など) は、中国 (北京) や中国 (寧夏) など、暗号化が利用できない特定のリージョンを除き、保管時に暗号化されます。リージョンごとに一意の暗号化キーが使用されます。
# での IAM の使用 AWS Shield
このセクションでは、 で IAM を使用する方法について説明します AWS Shield。
AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御 AWS のサービス するのに役立つ です。IAM 管理者は、Shield リソースを使用するための、認証 (サインイン) および認可 (アクセス許可を持つ) ができるユーザーを制御します。IAM は、追加料金なしで使用できる AWS のサービス です。
**Topics**
+ [オーディエンス](#security_iam_audience)
+ [アイデンティティを使用した認証](#security_iam_authentication)
+ [ポリシーを使用したアクセスの管理](#security_iam_access-manage)
+ [が IAM と AWS Shield 連携する方法](shd-security_iam_service-with-iam.md)
+ [のアイデンティティベースのポリシーの例 AWS Shield](shd-security_iam_id-based-policy-examples.md)
+ [AWS の 管理ポリシー AWS Shield](shd-security-iam-awsmanpol.md)
+ [AWS Shield ID とアクセスのトラブルシューティング](shd-security_iam_troubleshoot.md)
+ [Shield Advanced のサービスにリンクされたロールの使用](shd-using-service-linked-roles.md)
## オーディエンス
AWS Identity and Access Management (IAM) の使用方法は、Shield で行う作業によって異なります。
**サービスユーザー** - Shield サービスを使用してジョブを実行する場合は、必要なアクセス許可と認証情報を管理者が用意します。作業を実行するためにさらに多くの Shield 機能を使用するとき、追加の許可が必要になる場合があります。アクセスの管理方法を理解すると、管理者に適切なアクセス許可をリクエストするのに役に立ちます。Shield の特徴にアクセスできない場合は、「[AWS Shield ID とアクセスのトラブルシューティング](shd-security_iam_troubleshoot.md)」を参照してください。
**サービス管理者** - 社内の Shield リソースを担当している場合は、通常、Shield へのフルアクセスがあります。サービスのユーザーがどの Shield 機能やリソースにアクセスするかを決めるのは管理者の仕事です。その後、IAM 管理者にリクエストを送信して、サービスユーザーの権限を変更する必要があります。このページの情報を点検して、IAM の基本概念を理解してください。お客様の会社にて Shield により IAM を利用する方法の詳細については、[が IAM と AWS Shield 連携する方法](shd-security_iam_service-with-iam.md) をご参照ください。
**IAM 管理者** - IAM 管理者は、Shield へのアクセスを管理するためのポリシーの作成方法について、詳細を知りたい場合があります。IAM で使用できる Shield アイデンティティベースのポリシーの例を表示するには、「[のアイデンティティベースのポリシーの例 AWS Shield](shd-security_iam_id-based-policy-examples.md)」を参照してください。
## アイデンティティを使用した認証
認証とは、ID 認証情報 AWS を使用して にサインインする方法です。、IAM ユーザー AWS アカウントのルートユーザー、または IAM ロールを引き受けることで認証される必要があります。
AWS IAM アイデンティティセンター (IAM Identity Center)、シングルサインオン認証、Google/Facebook 認証情報などの ID ソースからの認証情報を使用して、フェデレーティッド ID としてサインインできます。サインインの詳細については、「*AWS サインイン ユーザーガイド*」の「[AWS アカウントにサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。
プログラムによるアクセスの場合、 は SDK と CLI AWS を提供してリクエストを暗号化して署名します。詳細については、「*IAM ユーザーガイド*」の「[API リクエストに対するAWS 署名バージョン 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。
### AWS アカウント ルートユーザー
を作成するときは AWS アカウント、すべての AWS のサービス および リソースへの完全なアクセス権を持つ AWS アカウント *ルートユーザー*と呼ばれる 1 つのサインインアイデンティティから始めます。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー認証情報を必要とするタスクについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。
### フェデレーテッドアイデンティティ
ベストプラクティスとして、人間のユーザーが一時的な認証情報 AWS のサービス を使用して にアクセスするには、ID プロバイダーとのフェデレーションを使用する必要があります。
*フェデレーティッド ID* は、エンタープライズディレクトリ、ウェブ ID プロバイダー、または ID ソースからの認証情報 AWS のサービス を使用して Directory Service にアクセスするユーザーです。フェデレーテッドアイデンティティは、一時的な認証情報を提供するロールを引き受けます。
アクセスを一元管理する場合は、 AWS IAM アイデンティティセンターをお勧めします。詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[IAM アイデンティティセンターとは](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」を参照してください。
### IAM ユーザーとグループ
*[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*は、特定の個人やアプリケーションに対する特定のアクセス許可を持つアイデンティティです。長期認証情報を持つ IAM ユーザーの代わりに一時的な認証情報を使用することをお勧めします。詳細については、*IAM ユーザーガイド*の[「ID プロバイダーとのフェデレーションを使用して にアクセスすることを人間 AWS のユーザーに要求する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、IAM ユーザーの集合を指定し、大量のユーザーに対するアクセス許可の管理を容易にします。詳細については、「*IAM ユーザーガイド*」の「[IAM ユーザーに関するユースケース](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)」を参照してください。
### IAM ロール
*[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*は、特定のアクセス許可を持つアイデンティであり、一時的な認証情報を提供します。[ユーザーから IAM ロール (コンソール) に切り替えるか、 または API オペレーションを呼び出すことで、ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)を引き受けることができます。 AWS CLI AWS 詳細については、「*IAM ユーザーガイド*」の「[ロールを引き受けるための各種方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)」を参照してください。
IAM ロールは、フェデレーションユーザーアクセス、一時的な IAM ユーザーのアクセス許可、クロスアカウントアクセス、クロスサービスアクセス、および Amazon EC2 で実行するアプリケーションに役立ちます。詳細については、*IAM ユーザーガイド* の [IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。
## ポリシーを使用したアクセスの管理
でアクセスを制御する AWS には、ポリシーを作成し、ID AWS またはリソースにアタッチします。ポリシーは、アイデンティティまたはリソースに関連付けられたときにアクセス許可を定義します。 は、プリンシパルがリクエストを行うときにこれらのポリシー AWS を評価します。ほとんどのポリシーは JSON ドキュメント AWS として に保存されます。JSON ポリシードキュメントの詳細については、「*IAM ユーザーガイド*」の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。
管理者は、ポリシーを使用して、どの**プリンシパル**がどの**リソース**に対して、どのような**条件**で**アクション**を実行できるかを定義することで、誰が何にアクセスできるかを指定します。
デフォルトでは、ユーザーやロールにアクセス許可はありません。IAM 管理者は IAM ポリシーを作成してロールに追加し、このロールをユーザーが引き受けられるようにします。IAM ポリシーは、オペレーションの実行方法を問わず、アクセス許可を定義します。
### アイデンティティベースのポリシー
アイデンティティベースのポリシーは、アイデンティティ (ユーザー、グループ、またはロール) にアタッチできる JSON アクセス許可ポリシードキュメントです。これらのポリシーは、アイデンティティがどのリソースに対してどのような条件下でどのようなアクションを実行できるかを制御します。アイデンティティベースポリシーの作成方法については、*IAM ユーザーガイド* の [カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) を参照してください。
アイデンティティベースのポリシーは、*インラインポリシー* (単一の ID に直接埋め込む) または*管理ポリシー* (複数の ID にアタッチされたスタンドアロンポリシー) にすることができます。管理ポリシーとインラインポリシーのいずれかを選択する方法については、「*IAM ユーザーガイド*」の「[管理ポリシーとインラインポリシーのいずれかを選択する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html)」を参照してください。
### リソースベースのポリシー
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。例としては、IAM *ロール信頼ポリシー*や Amazon S3 *バケットポリシー*などがあります。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスを制御できます。リソースベースのポリシーでは、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。
リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーでは、IAM の AWS マネージドポリシーを使用できません。
### アクセスコントロールリスト (ACL)
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
Amazon S3、および Amazon VPC は AWS WAF、ACLs。ACL の詳細については、*Amazon Simple Storage Service デベロッパーガイド* の [アクセスコントロールリスト (ACL) の概要](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) を参照してください。
### その他のポリシータイプ
AWS は、より一般的なポリシータイプによって付与されるアクセス許可の最大数を設定できる追加のポリシータイプをサポートしています。
+ **アクセス許可の境界** – アイデンティティベースのポリシーで IAM エンティティに付与することのできるアクセス許可の数の上限を設定します。詳細については、「*IAM ユーザーガイド*」の「[IAM エンティティのアクセス許可境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。
+ **サービスコントロールポリシー (SCP)** - AWS Organizations内の組織または組織単位の最大のアクセス許可を指定します。詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。
+ **リソースコントロールポリシー (RCP)** – は、アカウント内のリソースで利用できる最大数のアクセス許可を定義します。詳細については、「*AWS Organizations ユーザーガイド*」の「[リソースコントロールポリシー (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)」を参照してください。
+ **セッションポリシー** – ロールまたはフェデレーションユーザーの一時セッションを作成する際にパラメータとして渡される高度なポリシーです。詳細については、「*IAM ユーザーガイド*」の「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」を参照してください。
### 複数のポリシータイプ
1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成されるアクセス許可を理解するのがさらに難しくなります。が複数のポリシータイプが関与する場合にリクエストを許可するかどうか AWS を決定する方法については、*「IAM ユーザーガイド*」の[「ポリシー評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)」を参照してください。
# が IAM と AWS Shield 連携する方法
このセクションでは、 で IAM の機能を使用する方法について説明します AWS Shield。
IAM を使用して Shield へのアクセスを管理する前に、Shield で利用できる IAM の機能について学びます。
**で使用できる IAM 機能 AWS Shield**
| IAM 機能 | Shield のサポート |
| --- | --- |
| [アイデンティティベースのポリシー](#shd-security_iam_service-with-iam-id-based-policies) | あり |
| [リソースベースのポリシー](#shd-security_iam_service-with-iam-resource-based-policies) | なし |
| [ポリシーアクション](#shd-security_iam_service-with-iam-id-based-policies-actions) | あり |
| [ポリシーリソース](#shd-security_iam_service-with-iam-id-based-policies-resources) | はい |
| [ポリシー条件キー (サービス固有)](#shd-security_iam_service-with-iam-id-based-policies-conditionkeys) | はい |
| [ACL](#shd-security_iam_service-with-iam-acls) | なし |
| [ABAC (ポリシー内のタグ)](#shd-security_iam_service-with-iam-tags) | 部分的 |
| [一時認証情報](#shd-security_iam_service-with-iam-roles-tempcreds) | あり |
| [転送アクセスセッション (FAS)](#shd-security_iam_service-with-iam-principal-permissions) | あり |
| [サービスロール](#shd-security_iam_service-with-iam-roles-service) | あり |
| [サービスにリンクされたロール](#shd-security_iam_service-with-iam-roles-service-linked) | はい |
Shield およびその他の AWS のサービスがほとんどの IAM 機能と連携する方法の概要については、「IAM *ユーザーガイド*」の[AWS 「IAM と連携する のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
## Shield のアイデンティティベースのポリシー
このセクションでは、アイデンティティベースのポリシーの例を示します AWS Shield。
**ID ベースのポリシーのサポート:** あり
アイデンティティベースポリシーは、IAM ユーザー、ユーザーグループ、ロールなど、アイデンティティにアタッチできる JSON 許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件をコントロールします。アイデンティティベースポリシーの作成方法については、「*IAM ユーザーガイド*」の「[カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。
IAM アイデンティティベースのポリシーでは、許可または拒否するアクションとリソース、およびアクションを許可または拒否する条件を指定できます。JSON ポリシーで使用できるすべての要素について学ぶには、「*IAM ユーザーガイド*」の「[IAM JSON ポリシーの要素のリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)」を参照してください。
Shield アイデンティティベースのポリシーの例を表示するには、「[のアイデンティティベースのポリシーの例 AWS Shield](shd-security_iam_id-based-policy-examples.md)」を参照してください。
## Shield 内のリソースベースのポリシー
**リソースベースのポリシーのサポート:** なし
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM *ロールの信頼ポリシー*や Amazon S3 *バケットポリシー*があげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または を含めることができます AWS のサービス。
クロスアカウントアクセスを有効にするには、全体のアカウント、または別のアカウントの IAM エンティティを、リソースベースのポリシーのプリンシパルとして指定します。詳細については、IAM ユーザーガイド**の[IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)を参照してください。
## Shield のポリシーアクション
**ポリシーアクションのサポート:** あり
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。
Shield アクションのリストを確認するには、「*Service Authorization Reference*」の「[AWS Shieldで定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-actions-as-permissions)」を参照してください。
Shield のポリシーアクションは、アクションの前に以下のプレフィックス を使用します。
```
shield
```
単一のステートメントで複数のアクションを指定するには、アクションをカンマで区切ります。
```
"Action": [
"shield:action1",
"shield:action2"
]
```
ワイルドカード (\$1) を使用すると、複数のアクションを指定することができます。たとえば、Shield で `List` で始まるすべてのアクションを指定するには、次のアクションを含めます。
```
"Action": "shield:List*"
```
Shield アイデンティティベースのポリシーの例を表示するには、「[のアイデンティティベースのポリシーの例 AWS Shield](shd-security_iam_id-based-policy-examples.md)」を参照してください。
## Shield のポリシーリソース
**ポリシーリソースのサポート:** あり
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件**下で**アクション**を実行できるかということです。
`Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。リソースレベルのアクセス許可をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (\$1) を使用します。
```
"Resource": "*"
```
Shield リソースタイプとそれらの ARN のリストを確認するには、「*Service Authorization Reference*」の「[AWS Shieldで定義されるリソース](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-resources-for-iam-policies)」を参照してください。どのアクションで各リソースの ARN を指定できるかについては、「[AWS Shieldで定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-actions-as-permissions)」を参照してください。Shield リソースのサブセットへのアクセスを許可または拒否するには、ポリシーの `resource` 要素にリソースの ARN を含めます。
では AWS Shield、リソースは*保護*と*攻撃*です。これらのリソースには、次の表に示すとおり、一意の Amazon リソースネーム (ARN) が関連付けられています。
****
| AWS Shield コンソールの名前 | AWS Shield SDK/CLI の名前 | ARN 形式 |
| --- | --- | --- |
| イベントまたは攻撃 | AttackDetail | `arn:aws:shield::account:attack/ID` |
| 保護 | Protection | `arn:aws:shield::account:protection/ID` |
Shield リソースのサブセットへのアクセスを許可または拒否するには、ポリシーの `resource` 要素にリソースの ARN を含めます。Shield の ARN の形式は次のとおりです。
```
arn:partition:shield::account:resource/ID
```
*[account]* (アカウント)、*[resource]* (リソース)、および *[ID]* 変数を有効な値に置き換えます。有効な値は次のとおりです。
+ *アカウント*: の ID AWS アカウント。値を指定する必要があります。
+ *resource*: Shield リソースのタイプ (`attack` または `protection` のいずれか)。
+ *ID*: Shield リソースの ID、または ワイルドカード (`*`)。ワイルドカードは、指定した AWS アカウントに関連付けられている、指定したタイプのすべてのリソースを示します。
例えば、次の ARN はアカウント `111122223333` のすべての保護を指定します。
```
arn:aws:shield::111122223333:protection/*
```
Shield リソースの ARN の形式は次のとおりです。
```
arn:partition:shield:region:account-id:scope/resource-type/resource-name/resource-id
```
ARN の仕様に関する一般情報については、「 Amazon Web Services 全般のリファレンス」の「[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)」を参照してください。
`wafv2` リソースの ARN に固有の要件は以下の通りです。
+ *region*: Amazon CloudFront ディストリビューションを保護するために使用する Shield リソースの場合は、これを `us-east-1` に設定します。それ以外の場合は、保護されたリージョンリソースで使用している領域を設定します。
+ *スコープ*: Amazon CloudFront ディストリビューション`global`で使用するか、 が AWS WAF サポートするリージョンリソース`regional`で使用するスコープを に設定します。リージョンリソースは、Amazon API Gateway REST API、Application Load Balancer、 AWS AppSync GraphQL API、Amazon Cognito ユーザープール、 AWS App Runner サービス、 AWS Verified Access インスタンスです。
+ *resource-type*: イベント用または攻撃用の `attack`、保護用の `protection` のいずれかの値を指定します。
+ *resource-name*: Shield リソースに付けた名前を指定するか、ARN の他の仕様を満たすすべてのリソースを示すワイルドカード (`*`) を指定します。リソース名とリソース ID のどちらかを指定するか、両方にワイルドカードを指定する必要があります。
+ *resource-id*: Shield リソースの ID を指定するか、ワイルドカード (`*`) を指定して ARN の他の仕様を満たすすべてのリソースを指定します。リソース名とリソース ID のどちらかを指定するか、両方にワイルドカードを指定する必要があります。
例えば、次の ARN は、リージョン `us-west-1` におけるアカウント `111122223333` のリージョンレベルの範囲のすべてのウェブ ACL を指定します。
```
arn:aws:wafv2:us-west-1:111122223333:regional/webacl/*/*
```
次の ARN は、リージョン `us-east-1` のアカウント `111122223333` に対して、グローバルスコープを持つ `MyIPManagementRuleGroup` というルールグループを指定します。
```
arn:aws:wafv2:us-east-1:111122223333:global/rulegroup/MyIPManagementRuleGroup/1111aaaa-bbbb-cccc-dddd-example-id
```
Shield アイデンティティベースのポリシーの例を表示するには、「[のアイデンティティベースのポリシーの例 AWS Shield](shd-security_iam_id-based-policy-examples.md)」を参照してください。
## Shield のポリシー条件キー
**サービス固有のポリシー条件キーのサポート:** あり
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
`Condition` 要素は、定義された基準に基づいてステートメントが実行される時期を指定します。イコールや未満などの[条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)を使用して条件式を作成して、ポリシーの条件とリクエスト内の値を一致させることができます。すべての AWS グローバル条件キーを確認するには、*「IAM ユーザーガイド*」の[AWS 「グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。
Shield の条件キーのリストを確認するには、「*Service Authorization Reference*」の「[AWS Shieldの条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-policy-keys)」を参照してください。条件キーを使用できるアクションとリソースについては、[「 で定義されるアクション AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-actions-as-permissions)」を参照してください。
Shield アイデンティティベースのポリシーの例を表示するには、「[のアイデンティティベースのポリシーの例 AWS Shield](shd-security_iam_id-based-policy-examples.md)」を参照してください。
## Shield の ACL
**ACL のサポート:** なし
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
## Shield 付き ABAC
**ABAC (ポリシー内のタグ) のサポート:** 一部
属性ベースのアクセスコントロール (ABAC) は、タグと呼ばれる属性に基づいてアクセス許可を定義する認可戦略です。IAM エンティティと AWS リソースにタグをアタッチし、プリンシパルのタグがリソースのタグと一致するときにオペレーションを許可するように ABAC ポリシーを設計できます。
タグに基づいてアクセスを管理するには、`aws:ResourceTag/key-name`、`aws:RequestTag/key-name`、または `aws:TagKeys` の条件キーを使用して、ポリシーの[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)でタグ情報を提供します。
サービスがすべてのリソースタイプに対して 3 つの条件キーすべてをサポートする場合、そのサービスの値は**あり**です。サービスが一部のリソースタイプに対してのみ 3 つの条件キーのすべてをサポートする場合、値は「**部分的**」になります。
ABAC の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可でアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。ABAC をセットアップする手順を説明するチュートリアルについては、「*IAM ユーザーガイド*」の「[属性ベースのアクセスコントロール (ABAC) を使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)」を参照してください。
## Shield での一時的な認証情報の使用
**一時的な認証情報のサポート:** あり
一時的な認証情報は、 AWS リソースへの短期的なアクセスを提供し、フェデレーションまたはスイッチロールの使用時に自動的に作成されます。長期的なアクセスキーを使用する代わりに、一時的な認証情報を動的に生成 AWS することをお勧めします。詳細については、「*IAM ユーザーガイド*」の「[IAM の一時的な認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)」および「[AWS のサービス と IAM との連携](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
## Shield の転送アクセスセッション
**転送アクセスセッション (FAS) のサポート:** あり
転送アクセスセッション (FAS) は、 を呼び出すプリンシパルのアクセス許可と AWS のサービス、ダウンストリームサービス AWS のサービス へのリクエストをリクエストする を使用します。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。
## Shield のサービスロール
**サービスロールのサポート:** あり
サービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受ける [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、IAM ユーザーガイド**の [AWS のサービスに許可を委任するロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)を参照してください。
**警告**
サービスロールの許可を変更すると、Shield の機能が破損する可能性があります。Shield が指示する場合以外は、サービスロールを編集しないでください。
## Shield のサービスリンクロール
**サービスリンクロールのサポート:** あり
サービスにリンクされたロールは、 にリンクされたサービスロールの一種です AWS のサービス。サービスは、ユーザーに代わってアクションを実行するロールを引き受けることができます。サービスにリンクされたロールは に表示され AWS アカウント 、サービスによって所有されます。IAM 管理者は、サービスリンクロールのアクセス許可を表示できますが、編集することはできません。
Shield サービスにリンクされたロールの作成または管理の詳細については、「[Shield Advanced のサービスにリンクされたロールの使用](shd-using-service-linked-roles.md)」を参照してください。
# のアイデンティティベースのポリシーの例 AWS Shield
デフォルトでは、ユーザーおよびロールには、Shield リソースを作成または変更するアクセス許可はありません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。
これらのサンプルの JSON ポリシードキュメントを使用して IAM アイデンティティベースのポリシーを作成する方法については、「*IAM ユーザーガイド*」の「[IAM ポリシーを作成する (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)」を参照してください。
Shield が定義するアクションとリソースタイプ (リソースタイプごとの ARN の形式を含む) の詳細については、「*Service Authorization Reference*」の「[Actions, resources, and condition keys for AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html)」を参照してください。
**Topics**
+ [ポリシーに関するベストプラクティス](#shd-security_iam_service-with-iam-policy-best-practices)
+ [Shield コンソールの使用](#shd-security_iam_id-based-policy-examples-console)
+ [自分の権限の表示をユーザーに許可する](#shd-security_iam_id-based-policy-examples-view-own-permissions)
+ [Shield Advanced の保護機能に対する読み取りアクセスの許可](#shd-example0)
+ [Shield、CloudFront、CloudWatch に読み取り専用のアクセス権を付与する](#shd-example1)
+ [Shield、CloudFront、CloudWatch へのフルアクセス権を付与する](#shd-example2)
## ポリシーに関するベストプラクティス
ID ベースのポリシーは、ユーザーのアカウントで誰かが Shield リソースを作成、アクセス、または削除できるどうかを決定します。これらのアクションでは、 AWS アカウントに費用が発生する場合があります。アイデンティティベースポリシーを作成したり編集したりする際には、以下のガイドラインと推奨事項に従ってください:
+ ** AWS 管理ポリシーを開始し、最小特権のアクセス許可に移行する** – ユーザーとワークロードにアクセス許可の付与を開始するには、多くの一般的なユースケースにアクセス許可を付与する*AWS 管理ポリシー*を使用します。これらは で使用できます AWS アカウント。ユースケースに固有の AWS カスタマー管理ポリシーを定義することで、アクセス許可をさらに減らすことをお勧めします。詳細については、*IAM ユーザーガイド* の [AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) または [ジョブ機能のAWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) を参照してください。
+ **最小特権を適用する** – IAM ポリシーでアクセス許可を設定する場合は、タスクの実行に必要な許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、最小特権アクセス許可とも呼ばれています。IAM を使用して許可を適用する方法の詳細については、*IAM ユーザーガイド* の [IAM でのポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) を参照してください。
+ **IAM ポリシーで条件を使用してアクセスをさらに制限する** - ポリシーに条件を追加して、アクションやリソースへのアクセスを制限できます。たとえば、ポリシー条件を記述して、すべてのリクエストを SSL を使用して送信するように指定できます。条件を使用して、サービスアクションが などの特定の を通じて使用されている場合に AWS のサービス、サービスアクションへのアクセスを許可することもできます CloudFormation。詳細については、*IAM ユーザーガイド* の [IAM JSON ポリシー要素:条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) を参照してください。
+ **IAM アクセスアナライザー を使用して IAM ポリシーを検証し、安全で機能的な権限を確保する** - IAM アクセスアナライザー は、新規および既存のポリシーを検証して、ポリシーが IAM ポリシー言語 (JSON) および IAM のベストプラクティスに準拠するようにします。IAM アクセスアナライザーは 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーの作成をサポートします。詳細については、*IAM ユーザーガイド* の [IAM Access Analyzer でポリシーを検証する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) を参照してください。
+ **多要素認証 (MFA) を要求する** – で IAM ユーザーまたはルートユーザーを必要とするシナリオがある場合は AWS アカウント、MFA をオンにしてセキュリティを強化します。API オペレーションが呼び出されるときに MFA を必須にするには、ポリシーに MFA 条件を追加します。詳細については、*IAM ユーザーガイド* の [MFA を使用した安全な API アクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) を参照してください。
IAM でのベストプラクティスの詳細については、*IAM ユーザーガイド* の [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) を参照してください。
## Shield コンソールの使用
AWS Shield コンソールにアクセスするには、最小限のアクセス許可のセットが必要です。これらのアクセス許可により、 の Shield リソースの詳細を一覧表示および表示できます AWS アカウント。最小限必要な許可よりも制限が厳しいアイデンティティベースのポリシーを作成すると、そのポリシーを持つエンティティ (ユーザーまたはロール) に対してコンソールが意図したとおりに機能しません。
AWS CLI または AWS API のみを呼び出すユーザーには、最小限のコンソールアクセス許可を付与する必要はありません。代わりに、実行しようとしている API オペレーションに一致するアクションのみへのアクセスが許可されます。
AWS コンソールにアクセスして使用できるユーザーは、 AWS Shield コンソールにアクセスすることもできます。追加のアクセス許可は必要ありません。
### コンソールのみの API
コンソールでは、次の分散型サービス拒否 (DDoS) 攻撃情報にアクセスできます。特定のアクションを許可または拒否するには、IAM ポリシーで次の API アクセス許可を指定します。
| アクション | 説明 |
| --- | --- |
| DescribeAttackContributors | 特定の DDoS 攻撃の寄与者に関する詳細情報を取得するアクセス許可を付与します。 |
| ListMitigations | DDoS 攻撃中に適用された緩和アクションのリストを取得するアクセス許可を付与します。 |
| GetGlobalThreatData | Shield AWS の脅威モニタリングシステムからグローバルな脅威インテリジェンスデータと傾向を取得するアクセス許可を付与します。 |
この例では、コンソールで DDoS 攻撃情報を表示できるようにするポリシーを作成する方法を示します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"shield:DescribeAttackContributors"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"shield:ListMitigations"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"shield:GetGlobalThreatData"
],
"Resource": "*"
}
]
}
```
------
## 自分の権限の表示をユーザーに許可する
この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を IAM ユーザーに許可するポリシーの作成方法を示します。このポリシーには、コンソールで、または AWS CLI または AWS API を使用してプログラムでこのアクションを実行するアクセス許可が含まれています。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## Shield Advanced の保護機能に対する読み取りアクセスの許可
AWS Shield はクロスアカウントリソースアクセスを許可しますが、クロスアカウントリソース保護を作成することはできません。リソースの保護は、それらのリソースを所有するアカウント内からのみ作成できます。
すべてのリソースの `shield:ListProtections` アクションの許可を付与するポリシーの例を次に示します。Shield は、一部の API アクションについて、リソース ARN (リソースレベルの許可と呼ばれる) を使用した特定のリソースの識別をサポートしていません。そのため、ワイルドカード文字 (\$1) を指定する必要があります。これは、アクション `ListProtections` を通して取得できるリソースへのアクセスのみを許可するものです。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ListProtections",
"Effect": "Allow",
"Action": [
"shield:ListProtections"
],
"Resource": "*"
}
]
}
```
------
## Shield、CloudFront、CloudWatch に読み取り専用のアクセス権を付与する
次のポリシーでは、Amazon CloudFront リソースや Amazon CloudWatch メトリクスなど、Shield の関連付けられたリソースへの読み取り専用アクセスをユーザーに付与します。これは、Shield 保護と攻撃の設定を表示したり、CloudWatch でメトリクスをモニタリングする許可が必要なユーザーにとって役立ちます。これらのユーザーは、Shield リソースを作成、更新、または削除することはできません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ProtectedResourcesReadAccess",
"Effect": "Allow",
"Action": [
"cloudfront:List*",
"route53:List*",
"cloudfront:Describe*",
"elasticloadbalancing:Describe*",
"cloudwatch:Describe*",
"cloudwatch:Get*",
"cloudwatch:List*",
"cloudfront:GetDistribution*",
"globalaccelerator:ListAccelerators",
"globalaccelerator:DescribeAccelerator"
],
"Resource": [
"arn:aws:elasticloadbalancing:*:*:*",
"arn:aws:cloudfront::*:*",
"arn:aws:route53:::hostedzone/*",
"arn:aws:cloudwatch:*:*:*:*",
"arn:aws:globalaccelerator::*:*"
]
},
{
"Sid": "ShieldReadOnly",
"Effect": "Allow",
"Action": [
"shield:List*",
"shield:Describe*",
"shield:Get*"
],
"Resource": "*"
}
]
}
```
------
## Shield、CloudFront、CloudWatch へのフルアクセス権を付与する
次のポリシーにより、ユーザーは Shield オペレーションを実行し、CloudFront ウェブディストリビューションで任意のオペレーションを実行して、CloudWatch でメトリクスとリクエストのサンプルをモニタリングできます。これは、Shield の管理者であるユーザーにとって便利です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ProtectedResourcesReadAccess",
"Effect": "Allow",
"Action": [
"cloudfront:List*",
"route53:List*",
"cloudfront:Describe*",
"elasticloadbalancing:Describe*",
"cloudwatch:Describe*",
"cloudwatch:Get*",
"cloudwatch:List*",
"cloudfront:GetDistribution*",
"globalaccelerator:ListAccelerators",
"globalaccelerator:DescribeAccelerator"
],
"Resource": [
"arn:aws:elasticloadbalancing:*:*:*",
"arn:aws:cloudfront::*:*",
"arn:aws:route53:::hostedzone/*",
"arn:aws:cloudwatch:*:*:*:*",
"arn:aws:globalaccelerator::*:*"
]
},
{
"Sid": "ShieldFullAccess",
"Effect": "Allow",
"Action": [
"shield:*"
],
"Resource": "*"
}
]
}
```
------
管理者許可を持つユーザーに対しては多要素認証 (MFA) を設定することを強くお勧めします。詳細については、「*IAM ユーザーガイド*」の「[AWSでの多要素認証 (MFA) デバイスの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/Using_ManagingMFA.html)」を参照してください。
# AWS の 管理ポリシー AWS Shield
AWS 管理ポリシーは、 によって作成および管理されるスタンドアロンポリシーです AWS。 AWS 管理ポリシーは、ユーザー、グループ、ロールにアクセス許可の割り当てを開始できるように、多くの一般的なユースケースにアクセス許可を付与するように設計されています。
AWS 管理ポリシーは、すべての AWS お客様が使用できるため、特定のユースケースに対して最小特権のアクセス許可を付与しない場合があることに注意してください。ユースケースに固有の[カスタマー管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)を定義して、アクセス許可を絞り込むことをお勧めします。
AWS 管理ポリシーで定義されているアクセス許可は変更できません。が AWS 管理ポリシーで定義されたアクセス許可 AWS を更新すると、ポリシーがアタッチされているすべてのプリンシパル ID (ユーザー、グループ、ロール) に影響します。 AWS は、新しい が起動されるか、新しい API オペレーション AWS のサービス が既存のサービスで使用できるようになったときに、 AWS 管理ポリシーを更新する可能性が高くなります。
詳細については、「**IAM ユーザーガイド」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。
## AWS マネージドポリシー: AWSShieldDRTAccessPolicy
このセクションでは、Shield の AWS 管理ポリシーを使用する方法について説明します。
AWS Shield は、Shield Response Team (SRT) にユーザーに代わって行動するためのアクセス許可を付与するときに、この管理ポリシーを使用します。このポリシーは、重大度の高いイベント中の DDoS 攻撃の軽減を支援するために、SRT に AWS アカウントへの制限付きアクセスを許可します。このポリシーにより、SRT は AWS WAF ルールと Shield Advanced 保護を管理し、 AWS WAF ログにアクセスできます。
SRT に代行操作を許可する方法については、「[SRT へのアクセスの許可](ddos-srt-access.md)」を参照してください。
ポリシーの詳細については、IAM コンソールの「[AWSShieldDRTAccessPolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSShieldDRTAccessPolicy)」を参照してください。
## AWS マネージドポリシー: AWSShieldServiceRolePolicy
Shield Advanced は、アプリケーションレイヤーの自動 DDoS 軽減を有効にする際に、この管理ポリシーを使用して、アカウントのリソース管理に必要な権限を設定します。このポリシーにより、Shield Advanced は、保護されたリソースに関連付けたウェブ ACLs に AWS WAF ルールとルールグループを作成して適用し、DDoS 攻撃に自動的に対応できます。
お客様の IAM エンティティに、AWSShieldServiceRolePolicy をアタッチすることはできません。Shield はこのポリシーをサービス連動ロール `AWSServiceRoleForAWSShield` に添付し、Shield が代わりにアクションを実行できるようにします。
アプリケーションレイヤーの DDoS 自動緩和機能を有効にすると、Shield Advanced でこのポリシーの使用が可能になります。このポリシーの使用の詳細については、[Shield Advanced によるアプリケーションレイヤー DDoS 自動緩和](ddos-automatic-app-layer-response.md) を参照してください。
このポリシーを使用するサービス連携ロール AWSServiceRoleForAWSShield の詳細は、「[Shield Advanced のサービスにリンクされたロールの使用](shd-using-service-linked-roles.md)」を参照してください。
ポリシーの詳細については、IAM コンソールで「[AWSShieldServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/AWSShieldServiceRolePolicy)」を参照してください。
## AWS マネージドポリシーへの Shield 更新
このサービスがこれらの変更の追跡を開始してからの Shield の AWS マネージドポリシーの更新に関する詳細を表示します。このページの変更に関する自動通知については、[ドキュメント履歴](doc-history.md) の Shield ドキュメントの履歴ページの RSS フィードをサブスクライブしてください。
| ポリシー | 変更点の説明 | 日付 |
| --- | --- | --- |
| `AWSShieldServiceRolePolicy` このポリシーにより、Shield はユーザーに代わってアプリケーションレイヤー DDoS 攻撃に自動的に対応するために、 AWS リソースにアクセスして管理できます。 IAM コンソールの詳細: [AWSShieldServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/AWSShieldServiceRolePolicy) サービスにリンクされたロール `AWSServiceRoleForAWSShield` はこのポリシーを使用します。詳細については、「[Shield Advanced のサービスにリンクされたロールの使用](shd-using-service-linked-roles.md)」を参照してください。 | アプリケーションレイヤー DDoS 自動緩和機能に必要な許可を Shield Advanced に提供するため、このポリシーを追加しました。この機能については、「[Shield Advanced によるアプリケーションレイヤー DDoS 自動緩和](ddos-automatic-app-layer-response.md)」を参照してください。 | 2021 年 12 月 1 日 |
| Shield は変更の追跡を開始しました | Shield は、 AWS 管理ポリシーの変更の追跡を開始しました。 | 2021 年 3 月 3 日 |
# AWS Shield ID とアクセスのトラブルシューティング
次の情報は、Shield と IAM の使用に伴って発生する可能性がある一般的な問題の診断や修復に役立ちます。
**Topics**
+ [Shield でアクションを実行する権限がない](#shd-security_iam_troubleshoot-no-permissions)
+ [iam:PassRole を実行する権限がありません](#shd-security_iam_troubleshoot-passrole)
+ [自分の 以外のユーザーに Shield リソース AWS アカウント へのアクセスを許可したい](#shd-security_iam_troubleshoot-cross-account-access)
## Shield でアクションを実行する権限がない
あるアクションを実行する権限がないというエラーが表示された場合、そのアクションを実行できるようにポリシーを更新する必要があります。
次のエラー例は、`mateojackson` IAM ユーザーがコンソールを使用して、ある `my-example-widget` リソースに関する詳細情報を表示しようとしたことを想定して、その際に必要な `shield:GetWidget` アクセス許可を持っていない場合に発生するものです。
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: shield:GetWidget on resource: my-example-widget
```
この場合、`shield:GetWidget` アクションを使用して `my-example-widget` リソースへのアクセスを許可するように、`mateojackson` ユーザーのポリシーを更新する必要があります。
サポートが必要な場合は、 AWS 管理者にお問い合わせください。サインイン認証情報を提供した担当者が管理者です。
## iam:PassRole を実行する権限がありません
`iam:PassRole` アクションを実行する権限がないというエラーが表示された場合は、ポリシーを更新して Shield にロールを渡せるようにする必要があります。
一部の AWS のサービス では、新しいサービスロールまたはサービスにリンクされたロールを作成する代わりに、そのサービスに既存のロールを渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。
以下の例のエラーは、`marymajor` という IAM ユーザーがコンソールを使用して Shield でアクションを実行しようする場合に発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与されたアクセス許可が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
この場合、Mary のポリシーを更新してメアリーに `iam:PassRole` アクションの実行を許可する必要があります。
サポートが必要な場合は、 AWS 管理者にお問い合わせください。サインイン資格情報を提供した担当者が管理者です。
## 自分の 以外のユーザーに Shield リソース AWS アカウント へのアクセスを許可したい
他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。
詳細については、以下を参照してください:
+ Shield でこれらの特徴がサポートされるかどうかを確認するには、「[が IAM と AWS Shield 連携する方法](shd-security_iam_service-with-iam.md)」を参照してください。
+ 所有 AWS アカウント している のリソースへのアクセスを提供する方法については、[「IAM ユーザーガイド」の「所有 AWS アカウント している別の の IAM ユーザーへのアクセスを提供する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)」を参照してください。 **
+ リソースへのアクセスをサードパーティーに提供する方法については AWS アカウント、*IAM ユーザーガイド*の[「サードパーティー AWS アカウント が所有する へのアクセスを提供する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)」を参照してください。
+ ID フェデレーションを介してアクセスを提供する方法については、*IAM ユーザーガイド*の[外部で認証されたユーザー (ID フェデレーション) へのアクセスの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html)を参照してください。
+ クロスアカウントアクセスでのロールとリソースベースのポリシーの使用の違いの詳細については、*IAM ユーザーガイド*の[IAM ロールとリソースベースのポリシーとの相違点](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html)を参照してください。
# Shield Advanced のサービスにリンクされたロールの使用
このセクションでは、サービスにリンクされたロールを使用して、Shield Advanced に AWS アカウントのリソースへのアクセスを許可する方法について説明します。
AWS Shield Advanced は AWS Identity and Access Management (IAM)[ サービスにリンクされたロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)を使用します。サービスにリンクされたロールは、Shield Advanced に直接リンクされた一意のタイプの IAM ロールです。サービスにリンクされたロールは Shield Advanced によって事前定義されており、サービスがユーザーに代わって他の AWS サービスを呼び出すために必要なすべてのアクセス許可が含まれています。
サービスにリンクされたロールを使用することで、必要な許可を手動で追加する必要がなくなるため、Shield Advanced の設定が簡単になります。Shield Advanced は、サービスにリンクされたロールの許可を定義します。特に定義されている場合を除き、Shield Advanced のみがそのロールを引き受けることができます。定義される許可には、信頼ポリシーと許可ポリシーが含まれており、その許可ポリシーを他のIAM エンティティにアタッチすることはできません。
サービスにリンクされたロールは、まずその関連リソースを削除しなければ削除できません。これにより、リソースへの意図しないアクセスによる許可の削除が防止され、Shield Advanced リソースは保護されます。
サービスにリンクされたロールをサポートする他のサービスについては、「[IAM と連携するAWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照して、**サービスにリンクされたロール**列が**はい**になっているサービスを見つけてください。そのサービスに関するサービスにリンクされたロールに関するドキュメントを表示するには、リンクが設定されている **[Yes]** (はい) を選択します。
## Shield Advanced のサービスにリンクされたロールの許可
Shield Advanced は、**AWSServiceRoleForAWSShield** という名前のサービスにリンクされたロールを使用します。このロールにより、Shield Advanced はユーザーに代わってアプリケーションレイヤー DDoS 攻撃に自動的に対応するために、 AWS リソースにアクセスして管理できます。この関数の詳細については、「[Shield Advanced によるアプリケーションレイヤー DDoS 自動緩和](ddos-automatic-app-layer-response.md)」を参照してください。
サービスにリンクされたロール AWSServiceRoleForAWSShield は、次のサービスを信頼してロールを引き受けます。
+ `shield.amazonaws.com`
AWSShieldServiceRolePolicy という名前のロールアクセス許可ポリシーにより、Shield Advanced はすべての AWS リソースに対して次のアクションを実行できます。
+ `wafv2:GetWebACL`
+ `wafv2:UpdateWebACL`
+ `wafv2:GetWebACLForResource`
+ `wafv2:ListResourcesForWebACL`
+ `cloudfront:ListDistributions`
+ `cloudfront:GetDistribution`
すべての AWS リソースでアクションが許可されている場合、これはポリシーに と表示されます`"Resource": "*"`。これは、サービスにリンクされたロールが、アクションが*サポートする*すべての AWS リソースに対して、指定された各アクションを実行できることを意味します。例えば、アクション `wafv2:GetWebACL` は `wafv2` ウェブ ACL リソースでのみサポートされます。
Shield Advanced は、アプリケーションレイヤー保護機能を有効にしている保護されたリソースと、それらの保護されたリソースに関連付けられているウェブ ACL についてのみ、リソースレベルの API コールを実行します。
サービスにリンクされたロールの作成、編集、削除をIAM エンティティ (ユーザー、グループ、ロールなど) に許可するには、許可を設定する必要があります。詳細については、「*IAM ユーザーガイド*」の「[サービスにリンクされたロールの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
## Shield Advanced のサービスにリンクされたロールの作成
サービスリンクロールを手動で作成する必要はありません。 AWS マネジメントコンソール、、 AWS CLIまたは AWS API でリソースのアプリケーションレイヤー DDoS 自動緩和を有効にすると、Shield Advanced によってサービスにリンクされたロールが作成されます。
このサービスリンクロールを削除した後で再度作成する必要が生じた場合は同じ方法でアカウントにロールを再作成できます。リソースのためにアプリケーションレイヤー DDoS 自動緩和を有効にすると、Shield Advanced は、サービスにリンクされたロールを再作成します。
## Shield Advanced のサービスにリンクされたロールの編集
Shield Advanced で、AWSServiceRoleForAWSShield のサービスにリンクされたロールを編集することはできません。サービスにリンクされたロールを作成すると、多くのエンティティによってロールが参照される可能性があるため、ロール名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については、「*IAM ユーザーガイド*」の「[サービスにリンクされたロールの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
## Shield Advanced のサービスにリンクされたロールの削除
サービスにリンクされたロールが必要な機能またはサービスが不要になった場合には、そのロールを削除することをお勧めします。そうすることで、積極的にモニタリングまたは保守されていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスにリンクされたロールのリソースをクリーンアップする必要があります。
**注記**
リソースを削除する際に、Shield Advanced でロールが使用されている場合、削除は失敗することがあります。失敗した場合は、数分待ってからオペレーションを再試行してください。
**AWSServiceRoleForAWSShield で使用されている Shield Advanced リソースを削除するには**
アプリケーションレイヤー DDoS 保護が設定されているすべてのリソースについて、アプリケーションレイヤー DDoS 自動緩和を無効にします。コンソールの手順については、「[アプリケーションレイヤー DDoS 保護を設定する](manage-protection.md#configure-app-layer-protection)」を参照してください。
**IAM を使用して、サービスにリンクされたロールを手動で削除するには**
IAM コンソール、 AWS CLI、または AWS API を使用して、AWSServiceRoleForAWSShield サービスにリンクされたロールを削除します。詳細については、「[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」の「*サービスリンクロールの削除*」を参照してください。
## Shield Advanced のサービスにリンクされたロールをサポートするリージョン
Shield Advanced では、このサービスが利用可能なすべての リージョンで、サービスにリンクされたロールの使用をサポートしています。詳細については、「[Shield Advanced エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/shield.html)」を参照してください。
# Shield でのログ記録とモニタリング
このセクションでは、 でイベントをモニタリングおよび応答するための AWS ツールを使用する方法について説明します AWS Shield。
モニタリングは、Shield と AWS ソリューションの信頼性、可用性、パフォーマンスを維持する上で重要な部分です。マルチポイント障害が発生した場合は、その障害をより簡単にデバッグできるように、 AWS ソリューションのすべての部分からモニタリングデータを収集する必要があります。 には、Shield リソースをモニタリングし、潜在的なイベントに対応するための複数のツール AWS が用意されています。
**Amazon CloudWatch アラーム**
Amazon CloudWatch アラームを使用して、指定した期間にわたって 1 つのメトリクスを確認します。メトリクスが指定されたしきい値を超えると、CloudWatch は Amazon SNS トピックまたは AWS Auto Scaling ポリシーに通知を送信します。詳細については、「[Amazon CloudWatch によるモニタリング](monitoring-cloudwatch.md)」を参照してください。
**AWS CloudTrail ログ**
CloudTrail は、Shield のユーザー、ロール、または AWS のサービスによって実行されたアクションの記録を提供します。CloudTrail で収集された情報を使用して、Shield に対するリクエスト、リクエスト元の IP アドレス、リクエスト者、リクエスト日時などの詳細を確認できます。詳細については、「[での AWS CloudTrail API コールのログ記録](logging-using-cloudtrail.md)」を参照してください。
# Shield でのコンプライアンス検証
このセクションでは、 を使用する際のコンプライアンス責任について説明します AWS Shield。
AWS のサービス が特定のコンプライアンスプログラムの範囲内にあるかどうかを確認するには、[AWS のサービス 「コンプライアンスプログラムによる対象範囲内](https://aws.amazon.com/compliance/services-in-scope/)」の「コンプライアンス」を参照して、関心のあるコンプライアンスプログラムを選択します。一般的な情報については、[AWS 「コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)」を参照してください。
を使用して、サードパーティーの監査レポートをダウンロードできます AWS Artifact。詳細については、[「Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)」を参照してください。
を使用する際のお客様のコンプライアンス責任 AWS のサービス は、お客様のデータの機密性、貴社のコンプライアンス目的、適用される法律および規制によって決まります。を使用する際のコンプライアンス責任の詳細については AWS のサービス、[AWS 「 セキュリティドキュメント](https://docs.aws.amazon.com/security/)」を参照してください。
# Shield での耐障害性の構築
このセクションでは、 AWS アーキテクチャが のデータ冗長性をサポートする方法について説明します AWS Shield。
AWS グローバルインフラストラクチャは、 AWS リージョン およびアベイラビリティーゾーンを中心に構築されています。 は、低レイテンシー、高スループット、高度に冗長なネットワークで接続された、物理的に分離および分離された複数のアベイラビリティーゾーン AWS リージョン を提供します。アベイラビリティーゾーンでは、アベイラビリティーゾーン間で中断せずに、自動的にフェイルオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、耐障害性、およびスケーラビリティが優れています。
AWS リージョン およびアベイラビリティーゾーンの詳細については、[AWS 「 グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。
# のインフラストラクチャセキュリティ AWS Shield
このセクションでは、 がサービストラフィックを AWS Shield 分離する方法について説明します。
マネージドサービスである AWS Shield は、 AWS グローバルネットワークセキュリティで保護されています。 AWS セキュリティサービスと がインフラストラクチャ AWS を保護する方法については、[AWS 「 クラウドセキュリティ](https://aws.amazon.com/security/)」を参照してください。インフラストラクチャセキュリティのベストプラクティスを使用して環境を AWS 設計するには、*「Security Pillar AWS Well‐Architected Framework*」の[「Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)」を参照してください。
AWS 公開された API コールを使用して、ネットワーク経由で Shield にアクセスします。クライアントは以下をサポートする必要があります。
+ Transport Layer Security (TLS)。TLS 1.2 が必須で、TLS 1.3 をお勧めします。
+ DHE (楕円ディフィー・ヘルマン鍵共有) や ECDHE (楕円曲線ディフィー・ヘルマン鍵共有) などの完全前方秘匿性 (PFS) による暗号スイート。これらのモードは、Java 7 以降など、最近のほとんどのシステムでサポートされています。
# AWS Shield Advanced クォータ
AWS Shield Advanced には、リージョンあたりのエンティティ数に対するデフォルトのクォータがあります。このクォータの[引き上げをリクエスト](https://console.aws.amazon.com/servicequotas/home/services/shield/quotas)できます。
| [リソース] | デフォルトのクォータ |
| --- | --- |
| アカウントごとに、 が保護 AWS Shield Advanced を提供するリソースタイプごとの保護されたリソースの最大数。 | 1,000 |
| アカウントごとの保護グループの最大数。 | 100 |
| 保護グループに具体的に含めることができる個別の保護されたリソースの最大数。API では、これは保護グループ `Pattern` を `ARBITRARY` に設定するときに指定する `Members` に適用されます。コンソールでは、これは保護グループのために選択するリソースに適用されます **[Choose from protected resources]** (保護されたリソースから選択) | 1,000 |