**の新しいコンソールエクスペリエンスの紹介 AWS WAF** 更新されたエクスペリエンスを使用して、コンソールの任意の場所で AWS WAF 機能にアクセスできるようになりました。詳細については、[「コンソールの使用](https://docs.aws.amazon.com/waf/latest/developerguide/working-with-console.html)」を参照してください。翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # AWS WAF AWS WAF は、保護されたウェブアプリケーションリソースに転送される HTTP(S) リクエストをモニタリングできるウェブアプリケーションファイアウォールです。以下のリソースタイプを保護できます。 + Amazon CloudFront ディストリビューション + Amazon API Gateway REST API + Application Load Balancer + AWS AppSync GraphQL API + Amazon Cognito ユーザープール + AWS App Runner サービス + AWS Verified Access インスタンス + AWS Amplify AWS WAF では、コンテンツへのアクセスを制御できます。リクエストの発生元の IP アドレスまたはクエリ文字列の値など、指定した条件に基づいて、保護されたリソースに関連付けられたサービスはリクエストに対し、リクエストされたコンテンツ、HTTP 403 ステータスコード (禁止)、カスタム応答のいずれかで応答します。 **注記** を使用して AWS WAF 、Amazon Elastic Container Service (Amazon ECS) コンテナでホストされているアプリケーションを保護することもできます。Amazon ECS は、クラスターで Docker コンテナを簡単に実行、停止、管理できる非常にスケーラブルで高速なコンテナ管理サービスです。このオプションを使用するには、が有効になっている Application Load Balancer を使用して、サービス内のタスク間で HTTP(S) レイヤー 7 トラフィックをルーティングおよび保護 AWS WAF するように Amazon ECS を設定します。詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[Service load balancing](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html)」を参照してください。 **Topics** + [ # の使用を開始する AWS WAF ](getting-started.md) + [ # の AWS WAF 仕組み ](how-aws-waf-works.md) + [ # での保護の設定 AWS WAF ](web-acl.md) + [ # AWS WAF ルール ](waf-rules.md) + [ # AWS WAF ルールグループ ](waf-rule-groups.md) + [ # のウェブ ACL キャパシティユニット (WCUs) AWS WAF ](aws-waf-capacity-units.md) + [ # でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF ](waf-oversize-request-components.md) + [ # でサポートされている正規表現構文 AWS WAF ](waf-regex-pattern-support.md) + [ # の IP セットと正規表現パターンセット AWS WAF ](waf-referenced-set-managing.md) + [ # でカスタマイズされたウェブリクエストとレスポンス AWS WAF ](waf-custom-request-response.md) + [ # でのウェブリクエストのラベル付け AWS WAF ](waf-labels.md) + [ # でのインテリジェントな脅威の軽減 AWS WAF ](waf-managed-protections.md) + [ # 保護 AWS WAF パック (ウェブ ACL) トラフィックのデータ保護とログ記録 ](waf-data-protection-and-logging.md) + [ # AWS WAF 保護のテストとチューニング ](web-acl-testing.md) + [ # Amazon CloudFront AWS WAF でのの使用 ](cloudfront-features.md) + [ # AWS WAF サービスの使用におけるセキュリティ ](security.md) + [ # AWS WAF クォータ ](limits.md) + [ # AWS WAF Classic リソースのへの移行 AWS WAF ](waf-migrating-from-classic.md) # の使用を開始する AWS WAF の使用開始 AWS WAF は、使用するコンソールエクスペリエンスによって異なります。どちらのエクスペリエンスでも同じコア AWS WAF 機能にアクセスできますが、ウェブアプリケーション保護の設定と管理方法は異なります。 AWS WAF には、コンソールを使用するための 2 つのオプションがあります。 **新しいコンソール** は、標準のコンソールワークフローに必要なウェブ ACL 設定プロセスを簡素化することを目的としています。ガイド付きワークフローを使用して、保護パックを通じてウェブ ACL の作成および管理プロセスを簡素化できます。保護パックを使用すると、コンソールでのウェブ ACL の使用と管理が容易になりますが、ウェブ ACL と機能的に違いはありません。新しいコンソールでは、保護設定プロセスの改善に加えて、セキュリティダッシュボードを通じて保護の可視性が向上し、 AWS WAF コンソール内のセキュリティ体制を簡単にモニタリングできるようになります。 **標準 AWS WAF コンソール**は、ウェブ ACLs を使用してウェブアプリケーションのファイアウォール保護を設定する従来のアプローチを提供します。個々のルールとルールグループをきめ細かく制御でき、既存の AWS WAF ユーザーにとって使い慣れています。このコンソールを使用すると、保護設定を詳細に制御できるため、セキュリティ設定を正確にカスタマイズできます。 **ヒント** ニーズに最適なコンソールエクスペリエンスを選択します。を初めて使用する場合 AWS WAF や、 AWS レコメンデーションに基づいて保護の設定を開始する場合は、新しいコンソールエクスペリエンスから始めることをお勧めします。ただし、標準エクスペリエンスは、コンソールのナビゲーションペインからいつでも開くことができます。以下のセクションでは、両方のコンソールエクスペリエンスの開始方法に関するガイダンスを提供します。各アプローチを確認し、セキュリティ要件と運用上の好みに最も適したものを選択してください。 **Topics** + [ # 新しいコンソールエクスペリエンス AWS WAF の使用を開始する ](setup-iap-console.md) + [ # 標準コンソールエクスペリエンス AWS WAF の使用を開始する ](setup-existing-console.md) # 新しいコンソールエクスペリエンス AWS WAF の使用を開始するこのセクションでは、簡素化された設定ワークフローと強化されたセキュリティ管理機能を提供する新しいコンソールエクスペリエンス AWS WAF を使用してを設定する方法について説明します。 ## 新しいコンソールエクスペリエンスにアクセスする新しい AWS WAF コンソールエクスペリエンスにアクセスするには: 新しいにサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2-pro](https://console.aws.amazon.com/wafv2-pro) で AWS WAF コンソールを開きます。 + ナビゲーションペインで、**新しいエクスペリエンスを試す** を見つけて選択します。 **注記** ナビゲーションペインのリンクを使用して、コンソールエクスペリエンスをいつでも切り替えることができます。 ## 保護パック (ウェブ ACL) の使用を開始するこのチュートリアルでは、アプリケーションを保護するために保護パック (ウェブ ACL) を作成して設定する方法を示します。保護パック (ウェブ ACL) は、特定のワークロードタイプに合わせて事前設定されたセキュリティルールを提供します。このチュートリアルの学習内容は次のとおりです。 + 保護パック (ウェブ ACL) を作成する + アプリケーション固有の保護設定を構成する + 保護する AWS リソースを追加する + ルールを選択してカスタマイズする + ログ記録とモニタリングプレーンを設定する **注記** AWS 通常、は、このチュートリアルで作成したリソースに対して 1 日あたり 0.25 USD 未満を請求します。終了したら、不要な料金が発生しないようにリソースを削除することをお勧めします。 ### ステップ 1: をセットアップする AWS WAF [アカウントを設定してサービスを使用する](setting-up-waf.md) の一般的なセットアップ手順をまだ実行していない場合、今すぐ実行してください。 ### ステップ 2: 保護パック (ウェブ ACL) を作成するこのステップでは、保護パック (ウェブ ACL) を作成し、アプリケーションタイプに合わせて基本的な設定を行います。 1. 新しいにサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2-pro](https://console.aws.amazon.com/wafv2-pro) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで、**[リソースと保護パック (ウェブ ACL)]** を選択します。 1. **リソースと保護パック (ウェブ ACL)** ページで、**保護パック (ウェブ ACL) の追加** を選択します。 1. **「アプリについて教えてください**」の「**アプリカテゴリ**」で、アプリケーションに最も該当するアプリカテゴリを 1 つ以上選択します。 1. **トラフィックソース** で、アプリケーションが処理するトラフィックのタイプを選択します。 + **API** - API 専用アプリケーション用 + **ウェブ** - ウェブ専用アプリケーション用 + **API とウェブの両方** - 両方のタイプのトラフィックを処理するアプリケーション用 ### ステップ 3: 保護するリソースを追加する次に、保護パック (ウェブ ACL) で保護する AWS リソースを指定します。 1. **保護するリソース** で、**リソースの追加** を選択します。 1. この保護パック (ウェブ ACL) に関連付ける AWS リソースのカテゴリを選択します。 + Amazon CloudFront ディストリビューション + リージョナルリソースリソースタイプの詳細については、「[AWS リソースへの保護の関連付け](web-acl-associating.md)」を参照してください。 ### ステップ 4: 初期保護を選択するこのステップでは、保護パック (ウェブ ACL) のルールを選択します。初めて使用する場合は、**推奨** オプションを選択することをお勧めします。 AWS WAF は、**アプリに関するお問い合わせ**セクションで選択した内容に基づいて**推奨**を生成します。これらのパックは、アプリケーションタイプのセキュリティのベストプラクティスを実装します。 + **次へ** を選択して、保護パック (ウェブ ACL) のセットアップを続行します。 **注記** カスタムルールを作成したり、**ビルドする** オプションを使用したりする場合は、まず事前設定されたオプションの使用経験を積むことをお勧めします。カスタム保護パック (ウェブ ACL) とルールの作成については、「[で保護パック (ウェブ ACL) を作成する AWS WAF](web-acl-creating.md)」を参照してください。 ### ステップ 5: 保護パック (ウェブ ACL) 設定をカスタマイズする次に、デフォルトのアクション、レート制限、ログ記録などの追加設定を行います。 1. **名前と説明** に、保護パック (ウェブ ACL) の名前を入力します。必要に応じて説明に説明を入力します。 **注記** 保護パック (ウェブ ACL) の作成後は、名前を変更することはできません。 1. **保護パック (ウェブ ACL) のカスタマイズ** で、次の設定を行います。 1. **デフォルトルールアクション** で、どのルールにも一致しないリクエストのデフォルトアクションを選択します。詳細については、「[でカスタマイズされたウェブリクエストとレスポンス AWS WAF](waf-custom-request-response.md)」を参照してください。 1. **ルール設定** で、以下の設定をカスタマイズします。 + **デフォルトのレート制限** - DDoS 攻撃から保護するための制限を設定する + **IP アドレス** - IP 許可/ブロックリストを設定する + **国固有のオリジン** - 国ごとにアクセスを管理する 1. **ログ記録先** では、ログを保存する場所を設定します。詳細については、「[AWS WAF ログ記録の送信先](logging-destinations.md)」を参照してください。 1. 設定を確認し、**保護パック (ウェブ ACL) の追加** を選択します。 ### ステップ 6: リソースをクリーンアップするこれでチュートリアルは完了です。アカウントに AWS WAF 追加料金が発生しないようにするには、作成した保護パック (ウェブ ACL) を削除するか、本番環境のニーズに合わせて変更する必要があります。 **保護パック (ウェブ ACL) を削除するには** 1. ナビゲーションペインで、**[リソースと保護パック (ウェブ ACL)]** を選択します。 1. 作成した保護パック (ウェブ ACL) を選択します。 1. ごみ箱アイコンを選択し、「削除」と入力して削除を確認します。 **注記** この保護パック (ウェブ ACL) を本番環境で使用する場合は、削除する代わりに、アプリケーションのセキュリティ要件に合わせて保護設定を確認して調整する必要があります。 # 標準コンソールエクスペリエンス AWS WAF の使用を開始する AWS WAF コンソールでは、リクエストの送信元の IP アドレスやリクエストの値など、指定した条件に基づいてウェブリクエストをブロックまたは許可 AWS WAF するようにを設定するプロセスについて説明します。このステップでは、保護パック (ウェブ ACL) を作成します。 AWS WAF 保護パック (ウェブ ACLs「」を参照してください[での保護の設定 AWS WAF](web-acl.md)。このチュートリアルでは、 AWS WAF を使用して以下のタスクを実行する方法を示します。 + セットアップします AWS WAF。 + AWS WAF コンソールのウィザードを使用して、ウェブアクセスコントロールリスト (ウェブ ACL) を作成します。 **ウェブ ACL を作成するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. AWS WAF ホームページから、**ウェブ ACL の作成**を選択します。 1. **[Name]** (名前) で、このウェブ ACL の識別に使用する名前を入力します。 **注記** ウェブ ACL の作成後は、名前を変更することはできません。 1. (オプション) 必要に応じて、**[Description - optional]** (説明 - オプション) に、ウェブ ACL の詳しい説明を入力します。 1. **[CloudWatch metric name]** (CloudWatch メトリクス名) で、必要に応じてデフォルト名を変更します。有効な文字については、コンソールのガイダンスに従ってください。名前には、特殊文字、空白や、「All」および「Default\$1Action」などの AWS WAF用に予約されたメトリクス名を使用できません。 **注記** ウェブ ACL の作成後は CloudWatch メトリクス名を変更できません。 1. **[Resource type]** (リソースタイプ) で、**[CloudFront distributions]** (CloudFront ディストリビューション) を選択します。**[Region]** (リージョン) が、CloudFront ディストリビューションの **[Global (CloudFront)]** (グローバル (CloudFront)) に自動的に入力されます。 1. (オプション) **関連 AWS リソース - オプション**で、** AWS リソースの追加**を選択します。ダイアログボックスで、関連付けるリソースを選択し、**[Add]** (追加) を選択します。 AWS WAF は **[Describe web ACL and associated AWS resources]** (ウェブ ACL と関連付けられたリソースの説明) ページに戻します。 1. [**次へ**] を選択します。 **注記** AWS 通常、は、このチュートリアルで作成したリソースに対して 1 日あたり 0.25 USD 未満を請求します。チュートリアルを終了したら、不要な料金が発生しないようにリソースを削除することをお勧めします。 ## ステップ 1: をセットアップする AWS WAF [アカウントを設定してサービスを使用する](setting-up-waf.md) の一般的なセットアップ手順をまだ実行していない場合、今すぐ実行してください。 ## ステップ 2: ウェブ ACL を作成する AWS WAF コンソールでは、リクエストの送信元の IP アドレスやリクエストの値など、指定した条件に基づいてウェブリクエストをブロックまたは許可 AWS WAF するようにを設定するプロセスについて説明します。このステップでは、ウェブ ACL を作成します。 AWS WAF ウェブ ACLs「」を参照してください[での保護の設定 AWS WAF](web-acl.md)。 **ウェブ ACL を作成するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. AWS WAF ホームページから、**ウェブ ACL の作成**を選択します。 1. **[Name]** (名前) で、このウェブ ACL の識別に使用する名前を入力します。 **注記** ウェブ ACL の作成後は、名前を変更することはできません。 1. (オプション) 必要に応じて、**[Description - optional]** (説明 - オプション) に、ウェブ ACL の詳しい説明を入力します。 1. **[CloudWatch metric name]** (CloudWatch メトリクス名) で、必要に応じてデフォルト名を変更します。有効な文字については、コンソールのガイダンスに従ってください。名前には、特殊文字、空白や、「All」および「Default\$1Action」などの AWS WAF用に予約されたメトリクス名を使用できません。 **注記** ウェブ ACL の作成後は CloudWatch メトリクス名を変更できません。 1. **[Resource type]** (リソースタイプ) で、**[CloudFront distributions]** (CloudFront ディストリビューション) を選択します。**[Region]** (リージョン) が、CloudFront ディストリビューションの **[Global (CloudFront)]** (グローバル (CloudFront)) に自動的に入力されます。 1. (オプション) **関連 AWS リソース - オプション**で、** AWS リソースの追加**を選択します。ダイアログボックスで、関連付けるリソースを選択し、**[Add]** (追加) を選択します。 AWS WAF は **[Describe web ACL and associated AWS resources]** (ウェブ ACL と関連付けられたリソースの説明) ページに戻します。 1. **[Next]** (次へ) を選択します。 ## ステップ 3: 文字列一致ルールを追加するこのステップでは、文字列一致ステートメントを使用してルールを作成し、一致リクエストの処理方法を指定します。文字列一致ルールステートメントは、 AWS WAF がリクエストで検索する文字列を識別します。通常、文字列は印刷可能な ASCII 文字で構成されますが、16 進数 0x00 〜 0xFF (10 進数 0 〜 255) の任意の文字を指定できます。検索する文字列を指定するだけでなく、ヘッダー、クエリ文字列、リクエストボディなど、検索するウェブリクエストコンポーネントを指定します。このステートメントタイプは、ウェブリクエストコンポーネントで動作し、次のリクエストコンポーネント設定が必要です。 + **[リクエストコンポーネント]** — ウェブリクエストの検査対象部分 (クエリ文字列や本文など)。 **警告** リクエストコンポーネント**本文**、**JSON 本文**、**ヘッダー**、または **Cookie** を検査する場合は、で検査 AWS WAF できるコンテンツの量に関する制限についてお読みください[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)。ウェブリクエストコンポーネントの詳細については、「[でのルールステートメント設定の調整 AWS WAF](waf-rule-statement-fields.md)」を参照してください。 + **オプションのテキスト変換** – 検査する前にリクエストコンポーネントで AWS WAF 実行する変換。例えば、小文字に変換したり、空白を正規化したりできます。複数の変換を指定すると、はリストされた順序で変換 AWS WAF を処理します。詳細については、「[でのテキスト変換の使用 AWS WAF](waf-rule-statement-transformation.md)」を参照してください。 AWS WAF ルールの詳細については、「」を参照してください[AWS WAF ルール](waf-rules.md)。 **文字列一致ルールステートメントを作成するには** 1. **[Add rules and rule groups]** (ルールとルールグループの追加) ページで、**[Add rules]** (ルールの追加)、**[Add my own rules and rule groups]** (独自のルールとルールグループの追加)、**[Rule builder]** (ルールビルダー)、**[Rule visual editor]** (ルールビジュアルエディタ) の順に選択します。 **注記** コンソールには、**ルールビジュアルエディタ**と**ルール JSON エディタ**が用意されています。JSON エディタを使用すると、ウェブ ACL 間で設定を簡単にコピーできます。これは、ネストのレベルが複数あるルールセットなど、より複雑なルールセットに必要です。この手順では、**ルールビジュアルエディタ**を使用します。 1. **[Name]** (名前) で、このルールの識別に使用する名前を入力します。 1. **[Type]** (タイプ) で、**[Regular rule]** (通常のルール) を選択します。 1. **[If a request]** (リクエストの状態) で、**[matches the statement]** (ステートメントに一致) を選択します。その他のオプションは、論理ルールステートメントタイプ用です。これらを使用して、他のルールステートメントの結果を組み合わせたり、否定したりできます。 1. **ステートメント**で、**Inspect** でドロップダウンを開き、 AWS WAF 検査するウェブリクエストコンポーネントを選択します。この例では、**[単一ヘッダー]** を選択します。 **[単一ヘッダー]** を選択した場合は、 AWS WAF で検査するヘッダーも指定します。**User-Agent** と入力します。この値では大文字と小文字は区別されません。 1. **[Match type]** (一致タイプ) で、指定した文字列が `User-Agent` ヘッダーに表示される場所を選択します。この例では、**[Exactly matches string]** (文字列に完全一致) を選択します。これは、が各ウェブリクエストの user-agent ヘッダー AWS WAF を検査し、指定した文字列と同じ文字列がないかを示します。 1. **[String to match]** (照合する文字列) で、 AWS WAF で検索する文字列を指定します。**[String to match]** (照合する文字列) は最大 200 文字です。base64 でエンコードされた値を指定する場合、エンコード前の長さで最大 200 文字指定できます。この例では、**MyAgent** と入力します。 AWS WAF はウェブリクエストの `User-Agent`ヘッダーに値がないか検査します`MyAgent`。 1. **[Text transformation]** (テキスト変換) を **[None]** (なし) のままにします。 1. **[Action]** (アクション) で、ウェブリクエストに一致したときにルールによって実行されるアクションを選択します。この例では、**[Count]** (カウント) を選択し、他の選択肢はそのままにしておきます。カウントアクションにより、ルールに一致するウェブリクエストのメトリクスが作成されますが、リクエストが許可またはブロックされるかどうかには影響しません。アクションの選択の詳細については、「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」および「[ルールの優先度を設定する](web-acl-processing-order.md)」を参照してください。 1. **[Add rule]** (ルールの追加) を選択します。 ## ステップ 4: AWS マネージドルールルールグループを追加する AWS マネージドルールには、一連のマネージドルールグループが用意されており、その大部分は AWS WAF お客様に無料で提供されます。ルールグループの詳細については、「[AWS WAF ルールグループ](waf-rule-groups.md)」を参照してください。 AWS マネージドルールルールグループをこのウェブ ACL に追加します。 **AWS マネージドルールルールグループを追加するには** 1. **[Add rules and rule groups]** (ルールとルールグループの追加) ページで、**[Add rules]** (ルールの追加) を選択し、**[Add managed rule groups]** (マネージドルールグループの追加) を選択します。 1. **[マネージドルールグループを追加]** ページで、**[AWS マネージドルールグループ]** のリストを展開します。( AWS Marketplace 販売者に提供される出品も表示されます。サービスにサブスクライブし、 AWS マネージドルールルールグループと同じ方法で使用できます。) 1. 追加するルールグループについて、次を実行します。 1. **[Action]** (アクション) 列で、**[Add to web ACL]** (ウェブ ACL に追加) 切り替えボタンをオンにします。 1. **[Edit]** (編集) を選択し、ルールグループの **[Rules]** (ルール) リストで **[Override all rule actions]** (すべてのルールアクションをオーバーライド) ドロップダウンを開いて **[Count]** を選択します。これにより、ルールグループ内のすべてのルールのアクションがカウントのみに設定されます。これにより、ルールグループのルールを使用する前に、ルールグループのすべてのルールがウェブリクエストでどのように動作するかを確認できます。 1. **[Save rule]** (ルールを保存) を選択します。 1. **[Add managed rule groups]** (マネージドルールグループを追加) ページで、**[Add rules]** (ルールを追加) を選択します。これにより、**[Add rules and rule groups]** (ルールとルールグループを追加) ページに戻ります。 ## ステップ 5: ウェブ ACL の設定を完了するルールとルールグループをウェブ ACL 設定に追加したら、ウェブ ACL 内のルールの優先順位を管理し、メトリクス、タグ付け、ログ記録などの設定を行うことで完了します。 **ウェブ ACL の設定を完了するには** 1. **[Add rules and rule groups]** (ルールとルールグループの追加) ページで、**[Next]** (次へ) を選択します。 1. **ルールの優先度の設定** ページで、ウェブ ACL のルールとルールグループの処理順序を確認できます。 AWS WAF はリストの上部から処理します。処理順序は、ルールを上下に移動することで変更できます。これを行うには、リストで 1 つを選択し、**[Move up]** (上へ移動) または **[Move down]** (下へ移動) を選択します。ルーティングの優先度の詳細については、「[ルールの優先度を設定する](web-acl-processing-order.md)」をご覧ください。 1. [**次へ**] を選択します。 1. **[Configure metrics]** (メトリクスの設定) ページの **[Amazon CloudWatch metrics]** (Amazon CloudWatch メトリクス) で、ルールとルールグループ用の計画されたメトリクスと、ウェブリクエストのサンプリングオプションを確認できます。サンプリングされたリクエストの表示方法については、「[ウェブリクエストのサンプルの表示](web-acl-testing-view-sample.md)」を参照してください。Amazon CloudWatch メトリクスの詳細については、「[Amazon CloudWatch によるモニタリング](monitoring-cloudwatch.md)」を参照してください。ウェブトラフィックメトリクスの概要には、 AWS WAF コンソールのウェブ ACL のページで、**トラフィックの概要**タブからアクセスできます。コンソールダッシュボードには、ウェブ ACL の Amazon CloudWatch メトリクスの概要がほぼリアルタイムで表示されます。詳細については、「[保護パック (ウェブ ACL) のトラフィック概要ダッシュボード](web-acl-dashboards.md)」を参照してください。 1. **[Next]** (次へ) を選択します。 1. **[Review and create web ACL]** (ウェブ ACL の確認と作成) ページで、設定を確認し、**[Create web ACL]** (ウェブ ACL の作成) を選択します。ウィザードによって **[ウェブ ACL]** ページに戻ります。このページには、新しいウェブ ACL が一覧表示されます。 ## ステップ 6: リソースをクリーンアップするこれでチュートリアルは完了です。アカウントに AWS WAF 追加料金が発生しないようにするには、作成した AWS WAF オブジェクトをクリーンアップします。または、実際に使用するウェブリクエストに合わせて設定を変更することもできます AWS WAF。 **注記** AWS 通常、は、このチュートリアルで作成したリソースに対して 1 日あたり 0.25 USD 未満を請求します。終了したら、不要な料金が発生しないようにリソースを削除することをお勧めします。 **が AWS WAF 課金するオブジェクトを削除するには** 1. **[ウェブ ACL]** ページで、リストからウェブ ACL を選択し、**[編集]** を選択します。 1. **関連付けられた AWS リソース**タブで、関連付けられたリソースごとに、リソース名の横にあるラジオボタンを選択し、**関連付け解除**を選択します。これにより、ウェブ ACL と AWS リソースの関連付けが解除されます。 1. 次の各画面で、**[ウェブ ACL]** に戻るまで **[次へ]** を選択します。 **[ウェブ ACL]** ページで、リストからウェブ ACL を選択し、**[削除]** を選択します。ルールおよびルールステートメントは、ルールグループおよびウェブ ACL 定義の外部には存在しません。ウェブ ACL を削除すると、ウェブ ACL で定義した個々のルールがすべて削除されます。ウェブ ACL からルールグループを削除する場合は、そのグループへの参照を削除するだけです。 # の AWS WAF 仕組みを使用して AWS WAF 、保護されたリソースが HTTP(S) ウェブリクエストにどのように応答するかを制御します。これを行うには、ウェブアクセスコントロールリスト (ウェブ ACL) を定義し、保護する 1 つ以上のウェブアプリケーションリソースと関連付けます。関連付けられたリソースは、ウェブ ACL による検査 AWS WAF のために受信リクエストをに転送します。 **新しいコンソール** は、ウェブ ACL 設定プロセスを簡素化します。セキュリティルールを完全に制御しながらセットアップを効率化する保護パックが導入されました。保護パックはウェブ ACL の新しい場所であり、コンソールでのウェブ ACL 管理を簡素化しますが、基盤となるウェブ ACL 機能は変更されません。標準コンソールまたは API を使用する場合でも、ウェブ ACL で引き続き直接作業できます。保護パック (ウェブ ACL) では、リクエスト内で検索するトラフィックパターンを定義し、一致するリクエストに対して実行するアクションを指定するルールを作成します。アクションの選択肢は次のとおりです。 + 処理と応答のために、リクエストを保護されたリソースに送信することを許可する。 + リクエストをブロックする。 + リクエストをカウントする。 + リクエストに対して CAPTCHA またはチャレンジチェックを実行して、人間のユーザーと標準的なブラウザの使用を確認します。 **AWS WAF コンポーネント** 以下は、の主要なコンポーネントです AWS WAF。 + **ウェブ ACLs** – ウェブアクセスコントロールリスト (ウェブ ACL) を使用して、一連の AWS リソースを保護します。ウェブ ACL を作成し、ルールを追加してその保護戦略を定義します。ルールは、ウェブリクエストを検査する基準を定義し、条件に一致するリクエストに対して取る行動を指定します。また、ルールによってまだブロックまたは許可されていないすべてのリクエストをブロックするか、許可するかを示すウェブ ACL に対してデフォルトのアクションをセットします。ウェブ ACL の詳細については、「[での保護の設定 AWS WAF](web-acl.md)」を参照してください。ウェブ ACL は AWS WAF リソースです。 + **保護パック (ウェブ ACL)** - 新しいコンソールでは、保護パックはウェブ ACL の新しい場所になります。セットアップ時に、アプリケーションとリソースに関する情報を提供します。はシナリオに合わせた保護パック AWS WAF を推奨し、選択した保護パック (ウェブ ACL) で定義されたルール、ルールグループ、アクションを含むウェブ ACL を作成します。保護パック (ウェブ ACL) の詳細については、「[での保護の設定 AWS WAF](web-acl.md)」を参照してください。保護パック (ウェブ ACL) は AWS WAF リソースです。 + **ルール** - 各ルールには、検査基準を定義するステートメントと、ウェブリクエストがその基準を満たす場合に実行するアクションが含まれます。ウェブリクエストが条件を満たしている場合、それは一致となります。CAPTCHA パズルまたはサイレントクライアントブラウザのチャレンジを使用する一致リクエストをブロック、許可、カウント、ボットコントロールを実行するルールを設定できます。ルールの詳細については、「[AWS WAF ルール](waf-rules.md)」を参照してください。ルールは AWS WAF リソースではありません。ルールは保護パック (ウェブ ACL) またはルールグループのコンテキストでのみ定義されます。 + **ルールグループ** – 保護パック (ウェブ ACL) 内または再利用可能なルールグループでルールを直接定義できます。 AWS マネージドルールと AWS Marketplace 販売者は、使用するマネージドルールグループを提供します。また、独自のルールグループを定義することもできます。ルールグループの詳細については、「[AWS WAF ルールグループ](waf-rule-groups.md)」を参照してください。ルールグループは AWS WAF リソースです。 + **ウェブ ACL キャパシティユニット (WCUs)** – WCUs AWS WAF を使用して、ルール、ルールグループ、保護パック (ウェブ ACLs)、またはウェブ ACLs。 WCU は AWS WAF リソースではありません。保護パック (ウェブ ACL)、ルール、またはルールグループのコンテキストでのみ存在します。 # で保護できるリソース AWS WAF AWS WAF 保護パック (ウェブ ACL) を使用して、グローバルまたはリージョンのリソースタイプを保護できます。保護パック (ウェブ ACL) を保護するリソースに関連付けることにより、これを実行できます。保護パック (ウェブ ACL) およびそれらが使用する AWS WAF リソースは、関連するリソースがあるリージョンに配置する必要があります。Amazon CloudFront ディストリビューションの場合、これは米国東部 (バージニア北部) に設定されます。 **Amazon CloudFront ディストリビューション** AWS WAF コンソールまたは APIs を使用して、 AWS WAF 保護パック (ウェブ ACL) を CloudFront ディストリビューションに関連付けることができます。ディストリビューション自体を作成または更新するとき、保護パック (ウェブ ACL) を CloudFront ディストリビューションに関連付けることもできます。で関連付けを設定するには AWS CloudFormation、CloudFront ディストリビューション設定を使用する必要があります。Amazon CloudFront の詳細については、*Amazon CloudFront デベロッパーガイド*[AWS WAF 」の「を使用してコンテンツへのアクセスを制御する](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-awswaf.html)」を参照してください。 AWS WAF は CloudFront ディストリビューションでグローバルに利用できますが、米国東部 (バージニア北部) リージョンを使用して、保護パック (ウェブ ACL) と、ルールグループ、IP セット、正規表現パターンセットなど、保護パック (ウェブ ACL) で使用されるリソースを作成する必要があります。一部のインターフェイスでは、[Global (CloudFront)] (グローバル (CloudFront)) のリージョンを選択できます。これを選択することは、米国東部 (バージニア北部) リージョンまたは us-east-1 を選択することと同じです。 **地域リソース** AWS WAF が利用可能なすべてのリージョンでリージョンリソースを保護できます。「*Amazon Web Services 全般のリファレンス*」の「[AWS WAF エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/waf.html)」でリストを確認できます。を使用して AWS WAF 、次のリージョンリソースタイプを保護できます。 + Amazon API Gateway REST API + Application Load Balancer + AWS AppSync GraphQL API + Amazon Cognito ユーザープール + AWS App Runner サービス + AWS Verified Access インスタンス + AWS Amplify 保護パック (ウェブ ACL) を AWS リージョン内にある Application Load Balancer にのみ関連付けることができます。例えば、保護パック (ウェブ ACL) を AWS Outposts上にある Application Load Balancer に関連付けることはできません。 Global CloudFront リージョンで Amplify アプリに関連付ける保護パック (ウェブ ACL) を作成する必要があります。にリージョン保護パック (ウェブ ACL) が既にある可能性がありますが AWS アカウント、Amplify と互換性がありません。使用する保護パック (ウェブ ACL) およびその他の AWS WAF リソースは、保護されたリソースと同じリージョンに配置する必要があります。保護されたリージョンリソースのウェブリクエストをモニタリングおよび管理する場合、は保護されたリソースと同じリージョン内のすべてのデータ AWS WAF を保持します。 **複数リソースの関連付けにおける制限** 1 つの保護パック (ウェブ ACL) を 1 つ以上の AWS リソースに関連付けることができますが、以下の制限があります。 + 各 AWS リソースを関連付けることができる保護パック (ウェブ ACL) は 1 つだけです。保護パック (ウェブ ACL) と AWS リソースの関係は one-to-manyです。 + 保護パック (ウェブ ACL) を 1 つ以上の CloudFront ディストリビューションに関連付けることができます。CloudFront ディストリビューションに関連付けられている保護パック (ウェブ ACL) を他の AWS リソースタイプに関連付けることはできません。 # 更新されたコンソールエクスペリエンスを使用する AWS WAF には、コンソールを使用するための 2 つのオプションがあります。 **新しいコンソール** は、標準のコンソールワークフローに必要なウェブ ACL 設定プロセスを簡素化することを目的としています。ガイド付きワークフローを使用して、保護パック (ウェブ ACL) を通じてウェブ ACL の作成および管理プロセスを簡素化できます。保護パック (ウェブ ACL) を使用すると、コンソールでのウェブ ACL の使用と管理が容易になりますが、ウェブ ACL と機能的に違いはありません。新しいコンソールでは、保護設定プロセスの改善に加えて、セキュリティダッシュボードを通じて保護の可視性が向上し、 AWS WAF コンソール内のセキュリティ体制を簡単にモニタリングできます。 **標準 AWS WAF コンソール**は、ウェブ ACLs を使用してウェブアプリケーションのファイアウォール保護を設定する従来のアプローチを提供します。個々のルールとルールグループをきめ細かく制御でき、既存の AWS WAF ユーザーにとって使い慣れています。このコンソールを使用すると、保護設定を詳細に制御できるため、セキュリティ設定を正確にカスタマイズできます。 **ヒント** ニーズに最適なコンソールエクスペリエンスを選択します。を初めて使用する場合 AWS WAF や、 AWS レコメンデーションに基づいて保護の設定を開始する場合は、新しいコンソールエクスペリエンスから始めることをお勧めします。ただし、標準エクスペリエンスは、コンソールのナビゲーションペインからいつでも開くことができます。 ## 新しいコンソールエクスペリエンスと標準コンソールエクスペリエンス間の機能のパリティ新しいコンソールエクスペリエンスは、新機能を導入しながら、既存のコンソールとの完全な機能パリティを維持します。 + 既存の AWS WAF 機能はすべて引き続き使用できます。 + 統合ダッシュボードによる可視性の向上 + 設定ワークフローの簡素化 + 新しい保護パック (ウェブ ACL) テンプレート **重要** 新しいコンソールエクスペリエンスでは、既存のコンソールと同じ WAFv2 API を使用します。つまり、新しいコンソールで作成された保護パックは、API レベルで標準の WAFv2 ウェブ ACL として実装されます。 ## 主な違い **コンソールエクスペリエンスの比較** | 機能 | 以前の AWS WAF コンソールエクスペリエンス | コンソールエクスペリエンスの更新 | | --- | --- | --- | | 設定プロセス | マルチページワークフロー | 単一ページインターフェイス | | ルールの設定 | 個々のルールの作成 | 事前設定された保護パックのオプション | | モニタリング | 分離ダッシュボード | AI トラフィック分析を含む統一された可視性 | ## 新しいダッシュボードを理解する新しく提供されるダッシュボードでは、次の視覚化を通じて、セキュリティ体制の統一された可視性が提供されます。 **トラフィックインサイトの推奨事項** – AWS 脅威インテリジェンスは、過去 2 週間の許可されたトラフィックをモニタリングし、脆弱性を分析し、以下を提供します。 + トラフィックベースのルールの提案 + アプリケーション固有のセキュリティに関する推奨事項 + 保護最適化ガイダンス **概要** - 指定された時間範囲内のすべてのトラフィックのリクエスト数を表示します。次の条件を使用して、トラフィックデータをフィルタリングできます。 + **ルール** - 保護パック内の個々のルールでフィルタリングします。 + **アクション** - 許可、ブロック、キャプチャ、チャレンジなど、トラフィックに対して実行された特定のアクションの数を表示します。 + **トラフィックタイプ** - DDoS 対策やボットなどの特定のトラフィックタイプの数のみを表示します。 + **時間範囲** - 事前定義された時間範囲から選択するか、カスタム範囲を設定します。 + **ローカルまたは UTC 時間** - 任意の時間形式を設定できます。 **AI トラフィック分析** – AI ボットとエージェントのアクティビティを包括的に可視化します。 + **ボット識別** – ボット名、組織、検証ステータス。 + **インテント分析** – AI エージェントの目的と動作のパターン。 + **アクセスパターン** – 最も頻繁にアクセスURLs とエンドポイント。 + **一時的な傾向** – 時間帯別アクティビティパターンと過去の傾向 (0～14 日）。 + **トラフィック特性** – AI トラフィックのボリューム、分散、異常検出。 **保護アクティビティ** - 保護ルールとその順序がアクションの終了にどのように影響するかを視覚化します。 + **ルールを通過するトラフィックフロー** - ルールを通過するトラフィックフローを表示します。**シーケンシャルルールビュー** から **非シーケンシャルルールビュー** に切り替えて、ルールの順序が結果にどのように影響するかを確認します。 + **ルールアクションとその結果** - 指定した期間にルールがトラフィックに対して実行した終了アクションを表示します。 **アクションの合計** - 指定された時間範囲でリクエストに対して実行されたアクションの合計数を視覚化するグラフ。現在の時間範囲と過去 3 時間の時間枠を比較するには、**過去 3 時間のオーバーレイ** オプションを使用します。以下でデータをフィルタリングできます。 + **アクションを許可する** + **アクションの合計** + **キャプチャアクション** + **チャレンジアクション** + **ブロックブロック** **すべてのルール** - 保護パック内のすべてのルールのメトリクスを視覚化するグラフ。 + 現在の時間範囲と過去 3 時間の時間枠を比較するには、**過去 3 時間のオーバーレイ** オプションを使用します。 **概要ダッシュボード** - 以下を含む、セキュリティステータスの包括的でグラフィカルなビューを提供します。 + **トラフィック特性** - トラフィックの概要を、オリジン、攻撃タイプ、またはリクエストを送信したクライアントのデバイスタイプ別に表示します。 + **ルールの特性** - 10 個の最も一般的なルールと終了アクションによる攻撃の内訳。 + **ボット** - ボットアクティビティ、検出、カテゴリ、ボット関連のシグナルラベルを視覚化します。 + **DDoS 対策** - 検出および軽減されたレイヤー 7 DDoS アクティビティの概要。 # での保護の設定 AWS WAF このページでは、保護パック (ウェブ ACL) とその仕組みについて説明します。保護パック (ウェブ ACL) を使用すると、保護されたリソースが応答するすべての HTTP(S) ウェブリクエストをきめ細かく制御できます。Amazon CloudFront、Amazon API Gateway、Application Load Balancer、 AWS AppSync Amazon Cognito、 AWS App Runner AWS Amplify、Amazon CloudWatch、 AWS Verified Access リソースを保護できます。次のような基準を使用すると、リクエストを許可またはブロックできます。 + リクエストの IP アドレスの送信元 + リクエストの送信元の国 + リクエストの一部に含まれる文字列一致または正規表現 (regex) 一致 + リクエストの特定の部分のサイズ + 悪意のある SQL コードまたはスクリプトの検出これらの条件の任意の組み合わせをテストすることもできます。指定された条件を満たすだけでなく、1 分間にわたって指定された数のリクエストを超えるウェブリクエストを、ブロックまたはカウントできます。論理演算子を使用して条件を組み合わせることができます。リクエストに対して CAPTCHA パズルやサイレントクライアントセッションのチャレンジを実行することもできます。一致する条件と、 AWS WAF ルールステートメントの一致に対して実行するアクションを指定します。ルールステートメントは、保護パック (ウェブ ACL) 内、および保護パック (ウェブ ACL) で使用する再利用可能なルールグループで直接定義できます。オプションの詳細なリストについては、「[でのルールステートメントの使用 AWS WAF](waf-rule-statements.md)」および「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」を参照してください。保護パック (ウェブ ACL) を作成するときに、その ACL を使用するリソースのタイプを指定します。詳細については、「[で保護パック (ウェブ ACL) を作成する AWS WAF](web-acl-creating.md)」を参照してください。保護パック (ウェブ ACL) を定義した後、その ACL をリソースに関連付けて、リソースの保護を開始できます。詳細については、「[AWS リソースとの保護の関連付けまたは関連付け解除](web-acl-associating-aws-resource.md)」を参照してください。 **注記** 場合によっては、リクエストを許可またはブロックするかどうかに関する関連 AWS リソースへの応答を遅らせる内部エラーが発生する AWS WAF ことがあります。そのような場合は、CloudFront がリクエストを許可するか、コンテンツを提供するのが一般的ですが、およびリージョンレベルのサービスはリクエストを拒否し、コンテンツを提供しないのが一般的です。 **本番稼働トラフィックのリスク** 本番稼働トラフィックの保護パック (ウェブ ACL) に変更をデプロイする前に、ステージング環境またはテスト環境でテストおよびチューニングしてトラフィックへの潜在的な影響を確認します。その後、更新したルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。ガイダンスについては、「[AWS WAF 保護のテストとチューニング](web-acl-testing.md)」を参照してください。 **注記** 保護パック (ウェブ ACL) で 1,500 WCU を超える容量を使用すると、保護パック (ウェブ ACL) の基本料金を超えるコストが発生します。詳細については、「[のウェブ ACL キャパシティユニット (WCUs) AWS WAF](aws-waf-capacity-units.md)」と「[AWS WAF 料金表](https://aws.amazon.com/waf/pricing/)」を参照してください。 **更新中の一時的な不一致** 保護パック (ウェブ ACL) または他の AWS WAF リソースを作成または変更すると、リソースが保存されているすべての領域にその変更が反映されるまでに少し時間がかかります。伝播時間は、数秒から数分までかかります。次の内容では、変更伝播中に直面する一時的な不整合性の例を紹介します。 + 保護パック (ウェブ ACL) を作成した後、それをリソースに関連付けようとすると、保護パック (ウェブ ACL) が利用できないことを示す例外が表示される場合があります。 + ルールグループを保護パック (ウェブ ACL) に追加した後、新しいルールグループのルールは、保護パック (ウェブ ACL) が使用されるエリアで有効になり、別のエリアでは有効にならない場合があります。 + ルールのアクション設定を変更した後、古いアクションを一部のエリアで確認され、新しいアクションを別のエリアで確認される場合があります。 + ブロックルールで使用されている IP セットに IP アドレスを追加した後、新しいアドレスはあるエリアではブロックされ、別のエリアでは許可される場合があります。 **Topics** + [ # で保護パック (ウェブ ACL) を作成する AWS WAF ](web-acl-creating.md) + [ # での保護パック (ウェブ ACL) の編集 AWS WAF ](web-acl-editing.md) + [ # ルールグループの動作を管理する ](web-acl-rule-group-settings.md) + [ # AWS リソースとの保護の関連付けまたは関連付け解除 ](web-acl-associating-aws-resource.md) + [ # のルールとルールグループで保護パック (ウェブ ACLs) を使用する AWS WAF ](web-acl-processing.md) + [ # で保護パック (ウェブ ACL) のデフォルトアクションを設定する AWS WAF ](web-acl-default-action.md) + [ # でのボディ検査の管理に関する考慮事項 AWS WAF ](web-acl-setting-body-inspection-limit.md) + [ # での CAPTCHA、チャレンジ、トークンの設定 AWS WAF ](web-acl-captcha-challenge-token-domains.md) + [ # でのウェブトラフィックメトリクスの表示 AWS WAF ](web-acl-working-with.md) + [ # 保護パック (ウェブ ACL) の削除 ](web-acl-deleting.md) # で保護パック (ウェブ ACL) を作成する AWS WAF ------ #### [ Using the new console ] このセクションでは、新しい AWS コンソールを使用して保護パック (ウェブ ACLs) を作成する手順について説明します。新しい保護パック (ウェブ ACL) を作成するには、このページの手順に従って保護パック (ウェブ ACL) 作成ウィザードを使用します。 **本番稼働トラフィックのリスク** 本番稼働トラフィックの保護パック (ウェブ ACL) に変更をデプロイする前に、ステージング環境またはテスト環境でテストおよびチューニングしてトラフィックへの潜在的な影響を確認します。その後、更新したルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。ガイダンスについては、「[AWS WAF 保護のテストとチューニング](web-acl-testing.md)」を参照してください。 **注記** 保護パック (ウェブ ACL) で 1,500 WCU を超える容量を使用すると、保護パック (ウェブ ACL) の基本料金を超えるコストが発生します。詳細については、「[のウェブ ACL キャパシティユニット (WCUs) AWS WAF](aws-waf-capacity-units.md)」と「[AWS WAF 料金表](https://aws.amazon.com/waf/pricing/)」を参照してください。 1. 新しいにサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2-pro](https://console.aws.amazon.com/wafv2-pro) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで、**[リソースと保護パック (ウェブ ACL)]** を選択します。 1. **リソースと保護パック (ウェブ ACL)** ページで、**保護パック (ウェブ ACL) の追加** を選択します。 1. 「**アプリについて教えてください**」の「**アプリカテゴリ**」で、1 つ以上のアプリカテゴリを選択します。 1. **トラフィックソース**　では、アプリケーションがエンゲージするトラフィックのタイプを選択します。**API**、**ウェブ**、または **API とウェブの両方** です。 1. **保護するリソース** で、**リソースの追加** を選択します。 1. この保護パック (ウェブ ACL) に関連付ける AWS リソースのカテゴリ (Amazon CloudFront ディストリビューションまたはリージョンリソース) を選択します。詳細については、「[AWS リソースとの保護の関連付けまたは関連付け解除](web-acl-associating-aws-resource.md)」を参照してください。 1. 「**初期保護の選択**」で、**推奨**、**必須**、または **ビルドする** のいずれかの保護レベルを選択します。 1. (オプション) **ビルドする** を選択する場合は、ルールを構築します。 1. (オプション) 独自のルールを追加する場合は、**[ルールの追加]** ページで **[カスタムルール]** を選択し、**[次へ]** を選択します。 1. ロールタイプを選択します。 1. **[Action]** (アクション) で、ウェブリクエストに一致したときにルールによって実行されるアクションを選択します。選択の詳細については、「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」と「[のルールとルールグループで保護パック (ウェブ ACLs) を使用する AWS WAF](web-acl-processing.md)」を参照してください。 **[CAPTCHA]** または **[Challenge]** アクションを使用している場合、このルールの必要に応じて **[Immunity time]** (イミュニティ時間) の設定を調整します。設定を指定しない場合、ルールは保護パック (ウェブ ACL) から設定を継承します。保護パック (ウェブ ACL) のイミュニティ時間設定を変更するには、保護パック (ウェブ ACL) の作成後にウェブ ACL を編集します。イミュニティ時間の詳細については、「[でのタイムスタンプの有効期限とトークンイミュニティ時間の設定 AWS WAF](waf-tokens-immunity-times.md)」を参照してください。 **注記** CAPTCHA または Challenge ルールアクションを 1 つのルールで使用、あるいはルールグループでルールアクションのオーバーライドとして使用すると、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。リクエストまたはレスポンスをカスタマイズする場合は、そのオプションを選択し、カスタマイズの詳細を入力します。詳細については、「[でカスタマイズされたウェブリクエストとレスポンス AWS WAF](waf-custom-request-response.md)」を参照してください。一致するウェブリクエストにルールがラベルを追加するようにする場合は、そのオプションを選択し、ラベルの詳細を入力します。詳細については、「[でのウェブリクエストのラベル付け AWS WAF](waf-labels.md)」を参照してください。 1. **[Name]** (名前) で、このルールの識別に使用する名前を入力します。`AWS`、`Shield`、`PreFM`、または `PostFM` で始まる名前は使用しないでください。これらの文字列は、予約されているか、他のサービスが管理するルールグループと混同される可能性があります。 1. 必要に応じて、ルールの定義を入力します。論理 `AND` および `OR` ルールステートメントの中でルールを組み合わせることができます。ウィザードに、コンテキストに応じた各ルールのオプションが表示されます。ルールのオプションについては、「[AWS WAF ルール](waf-rules.md)」を参照してください。 1. **[‬ルールを作成]‭** を選択します。 **注記** 保護パック (ウェブ ACL) に複数のルールを追加すると、は保護パック (ウェブ ACL) にリストされている順序でルール AWS WAF を評価します。詳細については、「[のルールとルールグループで保護パック (ウェブ ACLs) を使用する AWS WAF](web-acl-processing.md)」を参照してください。 1. (オプション) マネージドルールグループを追加する場合は、[**ルールの追加**] ページで、**[AWSマネージドルールグループ]** または **[AWS マーケットプレイスルールグループ]** を選択し、**[次へ]** を選択します。追加するマネージドルールグループごとに次を実行します。 1. **ルールの追加**ページで、マネージドルールグループまたは AWS Marketplace 販売者のリスト AWS を展開します。 1. ルールグループのバージョンを選択します。 1. 保護パック (ウェブ ACL) がルールグループを使用する方法をカスタマイズするには、**[編集]** を選択します。一般的なカスタマイズ設定は次のとおりです。 + **[検査]** セクションにスコープダウンステートメントを追加することで、ルールグループが検査するウェブリクエストのスコープを縮小します。このオプションについては、「[でのスコープダウンステートメントの使用 AWS WAF](waf-rule-scope-down-statements.md)」を参照してください。 + **ルールオーバーライド** の一部またはすべてのルールのルールアクションをオーバーライドします。ルールにオーバーライドアクションを定義しない場合、評価にはルールグループ内で定義されているルールアクションが使用されます。このオプションについては、「[でのルールグループアクションの上書き AWS WAF](web-acl-rule-group-override-options.md)」を参照してください。 + 一部のマネージドルールグループは追加の設定が必要です。マネージドルールグループのプロバイダーのドキュメントを参照してください。 AWS マネージドルールのルールグループに固有の情報については、「」を参照してください[AWS のマネージドルール AWS WAF](aws-managed-rule-groups.md)。 1. [**次へ**] を選択します。 1. (オプション) 独自のルールグループを追加する場合は、**[ルールの追加]** ページで **[カスタムルールグループ]** を選択し、**[次へ]** を選択します。追加するルールグループごとに次を実行します。 1. **[名前]** で、この保護パック (ウェブ ACL) のルールグループのルールに使用する名前を入力します。`AWS`、`Shield`、`PreFM`、または `PostFM` で始まる名前は使用しないでください。これらの文字列は、予約されているか、他のサービスが管理するルールグループと混同される可能性があります。「[他のサービスによって提供されるルールグループを識別する](waf-service-owned-rule-groups.md)」を参照してください。 1. リストからルールグループを選択します。 1. (オプション) **[ルール設定]**で、**[ルールオーバーライド]** を選択します。マネージドルールグループの場合と同様に、ルールアクションを任意の有効なアクション設定に上書きできます。 1. (オプション) **[ラベルの追加]** で **[ラベルの追加]** を選択し、ルールに一致するリクエストに追加するラベルを入力します。同じ保護パック (ウェブ ACL) で後で評価されるルールは、このルールが追加するラベルを参照できます。 1. **[‬ルールを作成]‭** を選択します。 1. **名前と説明** に、保護パック (ウェブ ACL) の名前を入力します。必要に応じて説明に説明を入力します。 **注記** 保護パック (ウェブ ACL) の作成後は、名前を変更することはできません。 1. (オプション) **保護パックのカスタマイズ (ウェブ ACL)** で、デフォルトのルールアクション、設定、ログ記録の送信先を設定します。 1. (オプション) **デフォルトのルールアクション** で、保護パック (ウェブ ACL) のデフォルトのアクションを選択します。これは、保護パック (ウェブ ACL) のルールが明示的にアクションを実行しない場合に、リクエスト AWS WAF に対してが実行するアクションです。詳細については、「[でカスタマイズされたウェブリクエストとレスポンス AWS WAF](waf-custom-request-response.md)」を参照してください。 1. (オプション) ルール設定で、保護パック (ウェブ ACL) のルールの設定をカスタマイズします。 + **デフォルトのレート制限** - 可用性に影響を与えたり、セキュリティを侵害したり、過剰なリソースを消費したりする可能性のあるサービス拒否 (DoS) 攻撃をブロックするようにレート制限を設定します。このルールレートは、アプリケーションの許容レートを超える IP アドレスあたりのリクエストをブロックします。詳細については、[でのレートベースのルールステートメントの使用 AWS WAF](waf-rule-statement-type-rate-based.md)を参照してください。 + **IP アドレス** - ブロックまたは許可する IP アドレスを入力します。この設定は、他のルールをオーバーライドします。 + **国固有のオリジン** - 指定された国からのリクエストをブロックするか、すべてのトラフィックをカウントします。 1. **ログ記録先** の場合は、ログ記録先タイプとログを保存する場所を設定します。詳細については、「[AWS WAF ログ記録の送信先](logging-destinations.md)」を参照してください。 1. 設定を確認し、**保護パック (ウェブ ACL) の追加** を選択します。 ------ #### [ Using the standard console ] このセクションでは、 AWS コンソールを使用してウェブ ACLs を作成する手順について説明します。新しいウェブ ACL を作成するには、このページの手順に従ってウェブ ACL 作成ウィザードを使用します。 **本番稼働トラフィックのリスク** 本番稼働トラフィックのウェブ ACL に変更をデプロイする前に、ステージング環境またはテスト環境でテストおよびチューニングしてトラフィックへの潜在的な影響を確認します。その後、更新したルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。ガイダンスについては、「[AWS WAF 保護のテストとチューニング](web-acl-testing.md)」を参照してください。 **注記** 保護パック (ウェブ ACL) で 1,500 WCU を超える容量を使用すると、保護パック (ウェブ ACL) の基本料金を超えるコストが発生します。詳細については、「[のウェブ ACL キャパシティユニット (WCUs) AWS WAF](aws-waf-capacity-units.md)」と「[AWS WAF 料金表](https://aws.amazon.com/waf/pricing/)」を参照してください。 **ウェブ ACL を作成するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインの **[Web ACLs]** (ウェブ ACL) を選択してから、**[Create web ACL]** (ウェブ ACL を作成) を選択します。 1. **[Name]** (名前) で、このウェブ ACL の識別に使用する名前を入力します。 **注記** ウェブ ACL の作成後は、名前を変更することはできません。 1. (オプション) 必要に応じて、**[Description - optional]** (説明 - オプション) に、ウェブ ACL の詳しい説明を入力します。 1. **[CloudWatch metric name]** (CloudWatch メトリクス名) で、必要に応じてデフォルト名を変更します。有効な文字については、コンソールのガイダンスに従ってください。名前には、「All」や「Default\$1Action」など AWS WAF、予約されている特殊文字、空白、またはメトリクス名を含めることはできません。 **注記** ウェブ ACL の作成後は CloudWatch メトリクス名を変更できません。 1. **[リソースタイプ]** で、このウェブ ACL に関連付ける AWS リソースのカテゴリ (Amazon CloudFront ディストリビューションまたはリージョンリソース) を選択します。詳細については、「[AWS リソースとの保護の関連付けまたは関連付け解除](web-acl-associating-aws-resource.md)」を参照してください。 1. **リージョン**でリージョンリソースタイプを選択した場合は、ウェブ ACL AWS WAF を保存するリージョンを選択します。このオプションは、リージョン別リソースタイプの場合にのみ選択する必要があります。CloudFront ディストリビューションの場合、グローバル (CloudFront) アプリケーションであれば、リージョンは `us-east-1` (米国東部 (バージニア北部) リージョン) にハードコードされています。 1. (CloudFront、API Gateway、Amazon Cognito 、App Runner、Verified Access) **[ウェブリクエスト検査サイズの制限 – オプション]**に対して、別の本体検査サイズ制限を指定したい場合に、制限を選択します。デフォルトの 16 KB を超えるボディサイズを検査すると、追加費用が発生する可能性があります。このオプションについては、「[でのボディ検査の管理に関する考慮事項 AWS WAF](web-acl-setting-body-inspection-limit.md)」を参照してください。 1. (オプション) **関連 AWS リソース - オプション**で、今すぐリソースを指定する場合は、**リソースの追加 AWS **を選択します。ダイアログボックスで、関連付けるリソースを選択し、**Add**. AWS WAF returns you to the **Describe web ACL and associated AWS resources** page を選択します。 **注記** Application Load Balancer をウェブ ACL に関連付けることを選択すると、**リソースレベルの DDoS 保護** が有効になります。詳細については、「[AWS WAF 分散サービス拒否 (DDoS) の防止](waf-anti-ddos.md)」を参照してください。 1. **[Next]** (次へ) を選択します。 1. (オプション) マネージドルールグループを追加する場合は、**[Add rules and rule groups]** (ルールとルールグループの追加) ページで、**[Add rules]** (ルールの追加) を選択し、**[Add managed rule groups]** (マネージドルールグループの追加) を選択します。追加するマネージドルールグループごとに次を実行します。 1. **マネージドルールグループの追加**ページで、マネージドルールグループまたは選択した AWS Marketplace 販売者のリスト AWS を展開します。 1. 追加するルールグループでは、**[Action]** (アクション) 列で **[Add to web ACL]** (ウェブ ACL に追加) 切り替えボタンをオンにします。ウェブ ACL がルールグループを使用する方法をカスタマイズするには、**[Edit]** (編集) を選択します。一般的なカスタマイズ設定は次のとおりです。 + 一部またはすべてのルールのルールアクションをオーバーライドします。ルールにオーバーライドアクションを定義しない場合、評価にはルールグループ内で定義されているルールアクションが使用されます。このオプションについては、「[でのルールグループアクションの上書き AWS WAF](web-acl-rule-group-override-options.md)」を参照してください。 + スコープダウンステートメントを追加することで、ルールグループが検査するウェブリクエストのスコープを縮小します。このオプションについては、「[でのスコープダウンステートメントの使用 AWS WAF](waf-rule-scope-down-statements.md)」を参照してください。 + 一部のマネージドルールグループは追加の設定が必要です。マネージドルールグループのプロバイダーのドキュメントを参照してください。 AWS マネージドルールのルールグループに固有の情報については、「」を参照してください[AWS のマネージドルール AWS WAF](aws-managed-rule-groups.md)。設定が完了したら、**[Save rule]** (ルールを保存) を選択します。 **[Add rules]** (ルールの追加) を選択してマネージドルールの追加を終了し、**[Add rules and rule groups]** (ルールとルールグループの追加) ページに戻ります。 **注記** ウェブ ACL に複数のルールを追加すると、はウェブ ACL にリストされている順序でルール AWS WAF を評価します。詳細については、「[のルールとルールグループで保護パック (ウェブ ACLs) を使用する AWS WAF](web-acl-processing.md)」を参照してください。 1. (オプション) 独自のルールグループを追加する場合は、**[Add rules and rule groups]** (ルールとルールグループの追加) ページで、**[Add rules]** (ルールの追加) を選択し、**[Add my own rules and rule groups]** (独自のルールとルールグループの追加) を選択します。追加するルールグループごとに次を実行します。 1. **[Add my own rules and rule groups]** (独自のルールとルールグループの追加) ページで、**[Rule group]** (ルールグループ) を選択します。 1. **[Name]** (名前) で、このウェブ ACL のルールグループのルールに使用する名前を入力します。`AWS`、`Shield`、`PreFM`、または `PostFM` で始まる名前は使用しないでください。これらの文字列は、予約されているか、他のサービスが管理するルールグループと混同される可能性があります。「[他のサービスによって提供されるルールグループを識別する](waf-service-owned-rule-groups.md)」を参照してください。 1. リストからルールグループを選択します。 **注記** 独自のルールグループのルールアクションを上書きする場合は、まずウェブ ACL に保存し、ウェブ ACL のルールリストでウェブ ACL とルールグループ参照ステートメントを編集します。マネージドルールグループの場合と同様に、ルールアクションを任意の有効なアクション設定に上書きできます。 1. [**ルールを追加**] を選択してください。 1. (オプション) 独自のルールを追加する場合は、**[Add rules and rule groups]** (ルールとルールグループの追加) ページで、**[Add rules]** (ルールの追加)、**[Add my own rules and rule groups]** (独自のルールとルールグループの追加)、**[Rule builder]** (ルールビルダー)、**[Rule visual editor]** (ルールビジュアルエディタ) の順に選択します。 **注記** コンソールの **[Rule visual editor]** (ルールビジュアルエディタ) は、1 レベルのネストをサポートします。例えば、単一の論理 `AND` または `OR` ステートメントを使用して、その中に 1 レベルの他のステートメントをネストすることはできますが、論理ステートメントの中に論理ステートメントをネストすることはできません。より複雑なルールステートメントを管理するには、**[Rule JSON editor]** (ルール JSON エディタ) を使用します。ルールのすべてのオプションについては、「[AWS WAF ルール](waf-rules.md)」を参照してくださいこの手順では、**[Rule visual editor]** (ルールビジュアルエディタ) について説明します。 1. **[Name]** (名前) で、このルールの識別に使用する名前を入力します。`AWS`、`Shield`、`PreFM`、または `PostFM` で始まる名前は使用しないでください。これらの文字列は、予約されているか、他のサービスが管理するルールグループと混同される可能性があります。 1. 必要に応じて、ルールの定義を入力します。論理 `AND` および `OR` ルールステートメントの中でルールを組み合わせることができます。ウィザードに、コンテキストに応じた各ルールのオプションが表示されます。ルールのオプションについては、「[AWS WAF ルール](waf-rules.md)」を参照してください。 1. **[Action]** (アクション) で、ウェブリクエストに一致したときにルールによって実行されるアクションを選択します。選択の詳細については、「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」と「[のルールとルールグループで保護パック (ウェブ ACLs) を使用する AWS WAF](web-acl-processing.md)」を参照してください。 **[CAPTCHA]** または **[Challenge]** アクションを使用している場合、このルールの必要に応じて **[Immunity time]** (イミュニティ時間) の設定を調整します。設定を指定しない場合、ルールはウェブ ACL から設定を継承します。ウェブ ACL のイミュニティ時間設定を変更するには、ウェブ ACL の作成後にウェブ ACL を編集します。イミュニティ時間の詳細については、「[でのタイムスタンプの有効期限とトークンイミュニティ時間の設定 AWS WAF](waf-tokens-immunity-times.md)」を参照してください。 **注記** CAPTCHA または Challenge ルールアクションを 1 つのルールで使用、あるいはルールグループでルールアクションのオーバーライドとして使用すると、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。リクエストまたはレスポンスをカスタマイズする場合は、そのオプションを選択し、カスタマイズの詳細を入力します。詳細については、「[でカスタマイズされたウェブリクエストとレスポンス AWS WAF](waf-custom-request-response.md)」を参照してください。一致するウェブリクエストにルールがラベルを追加するようにする場合は、そのオプションを選択し、ラベルの詳細を入力します。詳細については、「[でのウェブリクエストのラベル付け AWS WAF](waf-labels.md)」を参照してください。 1. **[Add Rule]** (ルールの追加) を選択します。 1. ウェブ ACL のデフォルトアクションに Block または Allow を選択します。これは、ウェブ ACL のルールがリクエストを明示的に許可またはブロックしない場合に、リクエストに対してが AWS WAF 実行するアクションです。詳細については、「[で保護パック (ウェブ ACL) のデフォルトアクションを設定する AWS WAF](web-acl-default-action.md)」を参照してください。デフォルトのアクションをカスタマイズする場合は、そのオプションを選択し、カスタマイズの詳細を入力します。詳細については、「[でカスタマイズされたウェブリクエストとレスポンス AWS WAF](waf-custom-request-response.md)」を参照してください。 1. **[Token domain list]** (トークンドメインリスト) を定義して、保護されたアプリケーション間でトークンの共有を有効にできます。トークンは、 AWS WAF 不正コントロールアカウント作成不正防止 (ACFP)、 AWS WAF 不正コントロールアカウント乗っ取り防止 (ATP)、 AWS WAF ボットコントロールに AWS Managed Rules ルールグループを使用するときに実装する CAPTCHAChallengeアクションとアプリケーション統合 SDKs によって使用されます。パブリックサフィックスは許可されません。たとえば、`gov.au` または `co.uk` をトークンドメインとして使用することはできません。デフォルトでは、は保護されたリソースのドメインに対してのみトークン AWS WAF を受け入れます。このリストにトークンドメインを追加すると、はリスト内のすべてのドメインと、関連付けられたリソースのドメインのトークン AWS WAF を受け入れます。詳細については、「[AWS WAF 保護パック (ウェブ ACL) トークンドメインリスト設定](waf-tokens-domains.md#waf-tokens-domain-lists)」を参照してください。 1. **[Next]** (次へ) を選択します。 1. **ルールの優先度の設定**ページで、ルールとルールグループを選択して、 AWS WAF 処理する順序に移動します。は、リストの上部からルール AWS WAF を処理します。ウェブ ACL を保存すると、 AWS WAF では、リストされている順に、優先順位の数値設定がルールに割り当てられます。詳細については、「[ルールの優先度を設定する](web-acl-processing-order.md)」を参照してください。 1. **[Next]** (次へ) を選択します。 1. **[Configure metrics]** (メトリクスを設定) ページで、オプションを確認し、必要な更新を適用します。複数のソースからのメトリクスを組み合わせるには、それらに同じ **[CloudWatch metric name]** (CloudWatch メトリクス名) を指定します。 1. **[Next]** (次へ) を選択します。 1. **[Review and create web ACL]** (ウェブ ACL の確認と作成) ページで定義を確認します。エリアを変更する場合は、エリアの **[Edit]** (編集) を選択します。これにより、ウェブ ACL ウィザードのページに戻ります。変更を加えてから、**[Review and create web ACL]** (確認してウェブ ACL を作成する) ページに戻るまで、**[Next]** (次へ) を選択してページを進みます。 1. **[Create web ACL]** (ウェブ ACL の作成) を選択します。新しいウェブ ACL は、**[Web ACLs]** (ウェブ ACL) ページにリストされます。 ------ # での保護パック (ウェブ ACL) の編集 AWS WAF ------ #### [ Using the new console ] このセクションでは、 AWS コンソールを使用して保護パック (ウェブ ACLs) を編集する手順について説明します。保護パック (ウェブ ACL) のルールを追加、削除、あるいは設定を変更するには、このページの手順を使用して保護パック (ウェブ ACL) にアクセスします。保護パック (ウェブ ACL) の更新中に、は保護パック (ウェブ ACL) に関連付けられたリソースに継続的なカバレッジ AWS WAF を提供します。 **本番稼働トラフィックのリスク** 本番稼働トラフィックの保護パック (ウェブ ACL) に変更をデプロイする前に、ステージング環境またはテスト環境でテストおよびチューニングしてトラフィックへの潜在的な影響を確認します。その後、更新したルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。ガイダンスについては、「[AWS WAF 保護のテストとチューニング](web-acl-testing.md)」を参照してください。 **注記** 保護パック (ウェブ ACL) で 1,500 WCU を超える容量を使用すると、保護パック (ウェブ ACL) の基本料金を超えるコストが発生します。詳細については、「[のウェブ ACL キャパシティユニット (WCUs) AWS WAF](aws-waf-capacity-units.md)」と「[AWS WAF 料金表](https://aws.amazon.com/waf/pricing/)」を参照してください。 **保護パック (ウェブ ACL) を編集するには** 1. 新しいにサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2-pro](https://console.aws.amazon.com/wafv2-pro) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで、**[リソースと保護パック (ウェブ ACL)]** を選択します。 1. 編集する保護パック (ウェブ ACL) を選択します。コンソールはメイン保護パック (ウェブ ACL) カードを編集可能にし、編集できる詳細を含むサイドペインも開きます。 1. 必要に応じて保護パック (ウェブ ACL) を編集します。以下は、編集可能な保護パック (ウェブ ACL) 設定コンポーネントの一覧です。このセクションでは、 AWS コンソールを使用してウェブ ACLs を編集する手順について説明します。ウェブ ACL のルールを追加、削除、あるいは設定を変更するには、このページの手順を使用してウェブ ACL にアクセスします。ウェブ ACL の更新中に、はウェブ ACL に関連付けられたリソースに継続的なカバレッジ AWS WAF を提供します。 **本番稼働トラフィックのリスク** 本番稼働トラフィックのウェブ ACL に変更をデプロイする前に、ステージング環境またはテスト環境でテストおよびチューニングしてトラフィックへの潜在的な影響を確認します。その後、更新したルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。ガイダンスについては、「[AWS WAF 保護のテストとチューニング](web-acl-testing.md)」を参照してください。 **注記** 保護パック (ウェブ ACL) で 1,500 WCU を超える容量を使用すると、保護パック (ウェブ ACL) の基本料金を超えるコストが発生します。詳細については、「[のウェブ ACL キャパシティユニット (WCUs) AWS WAF](aws-waf-capacity-units.md)」と「[AWS WAF 料金表](https://aws.amazon.com/waf/pricing/)」を参照してください。 **更新中の一時的な不一致** 保護パック (ウェブ ACL) または他の AWS WAF リソースを作成または変更すると、リソースが保存されているすべての領域にその変更が反映されるまでに少し時間がかかります。伝播時間は、数秒から数分までかかります。次の内容では、変更伝播中に直面する一時的な不整合性の例を紹介します。 + 保護パック (ウェブ ACL) を作成した後、それをリソースに関連付けようとすると、保護パック (ウェブ ACL) が利用できないことを示す例外が表示される場合があります。 + ルールグループを保護パック (ウェブ ACL) に追加した後、新しいルールグループのルールは、保護パック (ウェブ ACL) が使用されるエリアで有効になり、別のエリアでは有効にならない場合があります。 + ルールのアクション設定を変更した後、古いアクションを一部のエリアで確認され、新しいアクションを別のエリアで確認される場合があります。 + ブロックルールで使用されている IP セットに IP アドレスを追加した後、新しいアドレスはあるエリアではブロックされ、別のエリアでは許可される場合があります。 ------ #### [ Using the standard console ] このセクションでは、 AWS コンソールを使用してウェブ ACL を編集する手順について説明します。ウェブ ACL のルールを追加、削除、あるいは設定を変更するには、このページの手順を使用してウェブ ACL にアクセスします。ウェブ ACL の更新中に、はウェブ ACL に関連付けられたリソースに継続的なカバレッジ AWS WAF を提供します。 **本番稼働トラフィックのリスク** 本番稼働トラフィックのウェブ ACL に変更をデプロイする前に、ステージング環境またはテスト環境でテストおよびチューニングしてトラフィックへの潜在的な影響を確認します。その後、更新したルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。ガイダンスについては、「[AWS WAF 保護のテストとチューニング](web-acl-testing.md)」を参照してください。 **注記** 保護パック (ウェブ ACL) で 1,500 WCU を超える容量を使用すると、保護パック (ウェブ ACL) の基本料金を超えるコストが発生します。詳細については、「[のウェブ ACL キャパシティユニット (WCUs) AWS WAF](aws-waf-capacity-units.md)」と「[AWS WAF 料金表](https://aws.amazon.com/waf/pricing/)」を参照してください。 **ウェブ ACL を編集するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで **[ウェブ ACL]** を選択します。 1. 編集するウェブ ACL の名前を選択します。コンソールでウェブ ACL の説明が表示されます。 1. 必要に応じてウェブ ACL を編集します。関心のある設定領域のタブを選択し、ミュータブルな設定を編集します。編集する設定ごとに **[保存]** を選択してウェブ ACL の説明ページに戻ると、コンソールではウェブ ACL に変更が保存されます。ウェブ ACL 設定コンポーネントを含むタブを以下に示します。 + **[ルール]** タブ + **ウェブ ACL で定義したルール** – ウェブ ACL で定義したルールは、ウェブ ACL の作成時と同様に編集および管理できます。 **注記** ウェブ ACL に手動で追加していないルールの名前は変更しないでください。他のサービスを使用してルールを管理している場合、名前を変更すると、意図した保護を提供する機能が削除または低下する可能性があります。 AWS Shield Advanced と AWS Firewall Manager の両方がウェブ ACL にルールを作成できます。詳細については、「[他のサービスによって提供されるルールグループを識別する](waf-service-owned-rule-groups.md)」を参照してください。 **注記** ルールの名前を変更し、ルールのメトリクス名に変更を反映する場合は、メトリクス名も更新する必要があります。ルール名を変更しても、ルールのメトリクス名は自動的に更新 AWS WAF されません。ルールの JSON エディターを使用して、コンソールでルールを編集するときに、メトリック名を変更できます。API や、保護パック (ウェブ ACL) またはルールグループの定義に使用する JSON リストを使用して、両方の名前を変更することもできます。ルールおよびルールグループの設定については、「[AWS WAF ルール](waf-rules.md)」と「[AWS WAF ルールグループ](waf-rule-groups.md)」を参照してください。 + **[使用するウェブ ACL ルールキャパシティーユニット]** – ウェブ ACL の現在のキャパシティ使用量。これは表示のみです。 + **[どのルールにも一致しないリクエストに対するデフォルトのウェブ ACL アクション]** – この設定の詳細については、「[で保護パック (ウェブ ACL) のデフォルトアクションを設定する AWS WAF](web-acl-default-action.md)」を参照してください。 + **[ウェブ ACL CAPTCHA およびチャレンジ設定]** – これらのイミュニティ時間によって、CAPTCHA またはチャレンジトークンの取得後の有効期間が決まります。ウェブ ACL の作成後、この設定は、このタブでしか変更できません。これらの設定については、「[でのタイムスタンプの有効期限とトークンイミュニティ時間の設定 AWS WAF](waf-tokens-immunity-times.md)」を参照してください。 + **トークンドメインリスト – **リスト内のすべてのドメインと、関連付けられたリソースのドメインのトークン AWS WAF を受け入れます。詳細については、「[AWS WAF 保護パック (ウェブ ACL) トークンドメインリスト設定](waf-tokens-domains.md#waf-tokens-domain-lists)」を参照してください。 + **関連付けられた AWS リソース**タブ + **[ウェブリクエスト検査サイズの制限]** – CloudFront ディストリビューションを保護するウェブ ACL にのみ含まれます。ボディ検査サイズ制限は、検査 AWS WAF のためにに転送されるボディコンポーネントの量を決定します。この設定の詳細については「[でのボディ検査の管理に関する考慮事項 AWS WAF](web-acl-setting-body-inspection-limit.md)」を参照してください。 + **[関連付けられた AWS リソース]** – ウェブ ACL が現在関連付けられ、保護しているリソースのリスト。ウェブ ACL と同じリージョン内にあるリソースを見つけて、ウェブ ACL に関連付けることができます。詳細については、「[AWS リソースとの保護の関連付けまたは関連付け解除](web-acl-associating-aws-resource.md)」を参照してください。 + **[カスタムレスポンス本文]** タブ + アクションが Block に設定されているウェブ ACL ルールで使用できるカスタムレスポンス本文。詳細については、「[Block アクションのカスタムレスポンスの送信](customizing-the-response-for-blocked-requests.md)」を参照してください。 + **[ログ記録とメトリクス]** タブ + **ログ記録** – ウェブ ACL で評価されるトラフィックのログ記録。詳細については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。 + **Security Lake 統合** – Amazon Security Lake のウェブ ACL 用に設定したデータ収集のステータス。詳細については、*「Amazon Security Lake* [ユーザーガイド」の AWS 「サービスからのデータ収集](https://docs.aws.amazon.com/security-lake/latest/userguide/internal-sources.html)」を参照してください。 + **サンプリングされたリクエスト** – ウェブリクエストに一致するルールに関する情報。サンプリングされたリクエストの表示方法については、「[ウェブリクエストのサンプルの表示](web-acl-testing-view-sample.md)」を参照してください。 + **データ保護設定** – ウェブ ACL で使用可能なすべてのデータと、が設定されたウェブ ACL ログ記録先 AWS WAF に送信するデータに対してのみ、ウェブトラフィックデータの秘匿化とフィルタリングを設定できます。データ保護については、「[保護 AWS WAF パック (ウェブ ACL) トラフィックのデータ保護とログ記録](waf-data-protection-and-logging.md)」を参照してください。 + **CloudWatch メトリクス** – ウェブ ACL 内のルールのメトリクス。Amazon CloudWatch メトリクスの詳細については、「[Amazon CloudWatch によるモニタリング](monitoring-cloudwatch.md)」を参照してください。 **更新中の一時的な不一致** 保護パック (ウェブ ACL) または他の AWS WAF リソースを作成または変更すると、リソースが保存されているすべての領域にその変更が反映されるまでに少し時間がかかります。伝播時間は、数秒から数分までかかります。次の内容では、変更伝播中に直面する一時的な不整合性の例を紹介します。 + 保護パック (ウェブ ACL) を作成した後、それをリソースに関連付けようとすると、保護パック (ウェブ ACL) が利用できないことを示す例外が表示される場合があります。 + ルールグループを保護パック (ウェブ ACL) に追加した後、新しいルールグループのルールは、保護パック (ウェブ ACL) が使用されるエリアで有効になり、別のエリアでは有効にならない場合があります。 + ルールのアクション設定を変更した後、古いアクションを一部のエリアで確認され、新しいアクションを別のエリアで確認される場合があります。 + ブロックルールで使用されている IP セットに IP アドレスを追加した後、新しいアドレスはあるエリアではブロックされ、別のエリアでは許可される場合があります。 ------ # ルールグループの動作を管理するこのセクションでは、保護パック (ウェブ ACL) でルールグループを使用する方法を変更するオプションについて説明します。この情報は、すべてのルールグループタイプに適用されます。ルールグループを保護パック (ウェブ ACL) に追加すると、ルールグループ内の個々ルールのアクションを Count またはその他の有効なルールアクション設定にオーバーライドできます。ルールグループの結果として生じるアクションを Count にオーバーライドすることもできます。これは、ルールグループ内でルールがどのように評価されるかについて影響されません。これらのオプションについては、「[でのルールグループアクションの上書き AWS WAF](web-acl-rule-group-override-options.md)」を参照してください。 ## ルールグループ内のルールアクションのオーバーライド保護パック (ウェブ ACL) の各ルールグループにおいて、一部またはすべてのルールに含まれているルールのアクションをオーバーライドできます。この場合の最も一般的な使用例は、ルールアクションを Count にオーバーライドし、新しいまたは更新されたルールをテストすることです。メトリクスを有効にしている場合、上書きするルールごとにメトリクスが受信されます。テストの詳細については、「[AWS WAF 保護のテストとチューニング](web-acl-testing.md)」を参照してください。これらの変更は、マネージドルールグループを保護パック (ウェブ ACL) に追加するときに行うことができ、保護パック (ウェブ ACL) を編集するときに任意のタイプのルールグループに行うことができます。この手順は、保護パック (ウェブ ACL) にすでに追加されているルールグループを対象としています。このオプションに関する追加情報については、[ルールグループのルールアクションの上書き](web-acl-rule-group-override-options.md#web-acl-rule-group-override-options-rules) を参照してください。 ------ #### [ Using the new console ] **ルールグループのルールアクションのオーバーライド方法** 1. 編集する保護パック (ウェブ ACL) を選択します。コンソールはメイン保護パック (ウェブ ACL) カードを編集可能にし、編集できる詳細を含むサイドパネルも開きます。 1. 保護パック (ウェブ ACL) カードで、**[ルール]** の横にある **[編集]** リンクを選択して、**[ルールの管理]** パネルを開きます。 1. ルールグループの **[ルールの管理]** セクションで、[マネージドルール] を選択してアクション設定を開きます。 + **ルールグループをオーバーライド** – ルールグループのアクションをカウントモードに変更しますが、個々のすべてのルールアクションは変更されません。 + **すべてのルールアクションをオーバーライド** – すべてのルールにルールアクションを適用し、現在の状態をオーバーライドします。 + **単一ルールをオーバーライド** – ルールアクションを個々のルールに適用します。 1. 変更が完了したら、**[Save Rule]** (ルールを保存) を選択します。 ------ #### [ Using the standard console ] **ルールグループのルールアクションのオーバーライド方法** 1. ウェブ ACL を編集します。 1. ウェブ ACL ページの **[Rules]** (ルール) タブで、ルールグループを選択し、**[Edit]** (編集) を選択します。 1. ルールグループの **[Rules]** (ルール) セクションで、必要に応じてアクション設定を管理します。 + **すべてのルール** – ルールグループ内のすべてのルールにオーバーライドアクションを設定するには、**[Override all rule actions]** (すべてのルールアクションをオーバーライド) ドロップダウンを開いてオーバーライドアクションを選択します。すべてのルールのオーバーライドを削除するには、**[Remove all overrides]** (すべてのオーバーライドを削除) を選択します。 + **単一ルール** – 単一ルールにオーバーライドアクションを設定するには、ルールのドロップダウンを開いてオーバーライドアクションを選択します。ルールのオーバーライドを削除するには、ルールのドロップダウンを開いて **[Remove override]** (オーバーライドを削除) を選択します。 1. 変更が完了したら、**[Save Rule]** (ルールを保存) を選択します。ルールアクションおよびオーバーライドアクション設定は、ルールグループページに一覧表示されます。 ------ 次の JSON リストの例は、ルール `CategoryVerifiedSearchEngine` および `CategoryVerifiedSocialMedia` に対してルールアクションを Count にオーバーライドする保護パック (ウェブ ACL) 内のルールグループ宣言を示しています。JSON では、個々ルールごとに `RuleActionOverrides` エントリを指定することで、すべてのルールアクションをオーバーライドします。 ``` { "Name": "AWS-AWSBotControl-Example", "Priority": 5, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesBotControlRuleSet", "RuleActionOverrides": [ { "ActionToUse": { "Count": {} }, "Name": "CategoryVerifiedSearchEngine" }, { "ActionToUse": { "Count": {} }, "Name": "CategoryVerifiedSocialMedia" } ], "ExcludedRules": [] }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSBotControl-Example" } } ``` ## ルールグループの評価結果を Count にオーバーライドルールグループ内のルールの設定または評価方法を変更せずに、ルールグループ評価の結果によって発生するアクションをオーバーライドできます。このオプションは一般的に使用されません。ルールグループ内のいずれかのルールが一致した場合、このオーバーライドはルールグループの結果として生じるアクションを Count に設定します。 **注記** これはまれなユースケースです。ほとんどのアクションオーバーライドは、[ルールグループ内のルールアクションのオーバーライド](#web-acl-rule-group-rule-action-override) で説明されているように、ルールグループ内のルールレベルで行われます。ルールグループを追加または編集するとき、保護パック (ウェブ ACL) 内でルールグループの結果として生じるのアクションをオーバーライドできます。コンソールで、ルールグループの **[Override rule group action - optional]** (ルールグループアクションのオーバーライド - オプション) ペインを開いてオーバーライドを有効にします。次のリストの例に示すように、JSON セットで `OverrideAction` をルールグループステートメントに設定します。 ``` { "Name": "AWS-AWSBotControl-Example", "Priority": 5, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesBotControlRuleSet" } }, "OverrideAction": { "Count": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSBotControl-Example" } } ``` # AWS リソースとの保護の関連付けまたは関連付け解除を使用して AWS WAF 、保護パック (ウェブ ACLs) とリソースの間に次の関連付けを作成できます。 + リージョナル保護パック (ウェブ ACL) を以下のリージョナルリソースのいずれかに関連付けます。このオプションでは、保護パック (ウェブ ACL) はリソースと同じ地域にある必要があります。 + Amazon API Gateway REST API + Application Load Balancer + AWS AppSync GraphQL API + Amazon Cognito ユーザープール + AWS App Runner サービス + AWS Verified Access インスタンス + AWS Amplify + グローバル保護パック (ウェブ ACL) を Amazon CloudFront ディストリビューションに関連付けます。グローバル保護パック (ウェブ ACL) には、米国東部 (バージニア北部) リージョンのハードコードリージョンを持ちます。ディストリビューション自体を作成または更新するとき、保護パック (ウェブ ACL) を CloudFront ディストリビューションに関連付けることもできます。詳細については、*Amazon CloudFront デベロッパーガイド*[AWS WAF 」の「を使用してコンテンツへのアクセスを制御する](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-awswaf.html)」を参照してください。 **複数の関連付けに関する制限** 以下の制限に従って、1 つの保護パック (ウェブ ACL) を 1 つ以上の AWS リソースに関連付けることができます。 + 各 AWS リソースを関連付けることができる保護パック (ウェブ ACL) は 1 つだけです。保護パック (ウェブ ACL) と AWS リソースの関係は one-to-manyです。 + 保護パック (ウェブ ACL) を 1 つ以上の CloudFront ディストリビューションに関連付けることができます。CloudFront ディストリビューションに関連付けられている保護パック (ウェブ ACL) を他の AWS リソースタイプに関連付けることはできません。 **追加の制限** 保護パック (ウェブ ACL) の関連付けについて、次の追加制限が適用されます。 + 保護パック (ウェブ ACL) は、 AWS リージョン内の Application Load Balancer にのみ関連付けることができます。例えば、保護パック (ウェブ ACL) を AWS Outpostsにある Application Load Balancer に関連付けることはできません。 + Amazon Cognito ユーザープールを Fraud Control Account Creation AWS WAF Fraud Prevention (ACFP) マネージドルールグループ`AWSManagedRulesACFPRuleSet`または AWS WAF Fraud Control Account Takeover Prevention (ATP) マネージドルールグループを使用する保護パック (ウェブ ACL) に関連付けることはできません`AWSManagedRulesATPRuleSet`。Account Creation Fraud Prevention については、「[AWS WAF Fraud Control アカウント作成不正防止 (ACFP)](waf-acfp.md)」を参照してください。アカウント乗っ取り防止の情報については、「[AWS WAF Fraud Control アカウント乗っ取り防止 (ATP)](waf-atp.md)」を参照してください。 **本番稼働トラフィックのリスク** 本番稼働トラフィックに保護パック (ウェブ ACL) をデプロイする前に、トラフィックへの潜在的な影響に慣れるまで、ステージング環境またはテスト環境でテストおよびチューニングします。その後、ルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。ガイダンスについては、「[AWS WAF 保護のテストとチューニング](web-acl-testing.md)」を参照してください。 # AWS リソースへの保護の関連付け ------ #### [ Using the new console ] 1. 編集する保護パック (ウェブ ACL) を選択します。コンソールはメイン保護パック (ウェブ ACL) カードを編集可能にし、編集できる詳細を含むサイドパネルも開きます。 1. 保護パック (ウェブ ACL) カードで、**[リソース]** の横にある **[編集]** リンクを選択して、**[リソースの管理]** パネルを開きます。 1. ルールグループの **[リソースの管理]** セクションで、**[リージョナルリソースの追加]** または **[グローバルリソースの追加]** を選択します。 1. [リソース] 選択し、**[追加]** を選択します。 ------ #### [ Using the standard console ] ウェブ ACL を AWS リソースに関連付けるには、次の手順を実行します。 **ウェブ ACL を AWS リソースに関連付けるには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで **[ウェブ ACL]** を選択します。 1. リソースに関連付けるウェブ ACL の名前を選択します。コンソールでウェブ ACL の説明が表示され、そこで編集できます。 1. **関連 AWS リソース**タブで、** AWS リソースの追加**を選択します。 1. プロンプトが表示されたら、リソースの種類を選択し、関連付けるリソースの横にあるラジオボタンを選択してから、**[Add]** (追加) を選択します。 ------ # AWS リソースから保護の関連付けを解除する ------ #### [ Using the new console ] 1. 編集する保護パック (ウェブ ACL) を選択します。コンソールはメイン保護パック (ウェブ ACL) カードを編集可能にし、編集できる詳細を含むサイドパネルも開きます。 1. 保護パック (ウェブ ACL) カードで、**[リソース]** の横にある **[編集]** リンクを選択して、**[リソースの管理]** パネルを開きます。 1. ルールグループの **[リソースの管理]** セクションで、関連付けを解除するリソースを選択し、**[関連付けを解除]** を選択します。 **注記** 一度に 1 つのリソースの関連付けを解除する必要があります。リソースを選択する際に複数選択しないでください。 1. 確認ページで「関連付け解除」と入力し、[**関連付け解除**] を選択します。 ------ #### [ Using the standard console ] ウェブ ACL と AWS リソースの関連付けを解除するには、次の手順を実行します。 **AWS リソースからウェブ ACL の関連付けを解除するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで **[ウェブ ACL]** を選択します。 1. リソースとの関連付けを解除するウェブ ACL の名前を選択します。コンソールでウェブ ACL の説明が表示され、そこで編集できます。 1. **関連 AWS リソース**タブで、このウェブ ACL の関連付けを解除するリソースを選択します。 **注記** 一度に 1 つのリソースの関連付けを解除する必要があります。リソースを選択する際に複数選択しないでください。 **注記** Application Load Balancer をウェブ ACL に関連付けることを選択すると、**リソースレベルの DDoS 保護** が有効になります。詳細については、「[AWS WAF 分散サービス拒否 (DDoS) の防止](waf-anti-ddos.md)」を参照してください。 1. [**関連付け解除**] を選択してください。コンソールに確認ダイアログが表示されます。 AWS リソースからウェブ ACL の関連付けを解除する選択を確認します。 ------ # のルールとルールグループで保護パック (ウェブ ACLs) を使用する AWS WAF このセクションでは、保護パック (ウェブ ACL) とウェブ ACL がルールとルールグループと連携する方法について説明します。保護パック (ウェブ ACL) がウェブリクエストを処理する方法は、次に応じて異なります。 + 保護パック (ウェブ ACL) およびルールグループ内のルールの優先順位の数値設定 + ルールおよび保護パック (ウェブ ACL) のアクション設定 + 追加したルールグループ内のルールに設定した上書きルールアクション設定のリストについては、「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」を参照してください。ルールアクション設定とデフォルトの保護パック (ウェブ ACL) アクション設定で、リクエストと応答の処理をカスタマイズできます。詳細については、「[でカスタマイズされたウェブリクエストとレスポンス AWS WAF](waf-custom-request-response.md)」を参照してください。 **Topics** + [ # ルールの優先度を設定する ](web-acl-processing-order.md) + [ # がルールとルールグループのアクション AWS WAF を処理する方法 ](web-acl-rule-actions.md) + [ # でのルールグループアクションの上書き AWS WAF ](web-acl-rule-group-override-options.md) # ルールの優先度を設定するこのセクションでは、 AWS WAF が数値優先度設定を使用してルールの評価順序を設定する方法について説明します。保護パック (ウェブ ACL) および任意のルールグループ内では、優先順位の数値設定を使用してルールの評価順序を決定します。保護パック (ウェブ ACL) 内の各ルールには、その保護パック (ウェブ ACL) 内で一意の優先順位を設定する必要があります。また、ルールグループ内の各ルールには、そのルールグループ内で一意の優先順位を設定する必要があります。 **注記** コンソールを使用してルールグループ、保護パック (ウェブ ACLs) を管理すると、はリスト内のルールの順序に基づいて一意の数値優先度設定 AWS WAF を割り当てます。はリストの上部にあるルールに最小の数値優先度を割り当て、下部にあるルールに最大の数値優先度を AWS WAF 割り当てます。は、ウェブリクエストに対してルールグループ、保護パック (ウェブ ACL) AWS WAF を評価すると、評価を終了するか、すべてのルールを使い果たす一致が見つかるまで、の最小の数値優先度設定からルールを評価します。例えば、保護パック (ウェブ ACL) に次のルールとルールグループがあり、次のように優先順位付けされているとします。 + Rule1 — 優先度 0 + RuleGroupA – 優先度 100 + RuleA1 – 優先度 10,000 + RuleA2 – 優先度 20,000 + Rule2 — 優先度 200 + RuleGroupB – 優先度 300 + RuleB1 – 優先度 0 + RuleB2 – 優先度 1 AWS WAF は、この保護パック (ウェブ ACL) のルールを次の順序で評価します。 + Rule1 + RuleGroupA RuleA1 + RuleGroupA RuleA2 + Rule2 + RuleGroupB RuleB1 + RuleGroupB RuleB2 # がルールとルールグループのアクション AWS WAF を処理する方法このセクションでは、 AWS WAF がルールとルールグループを使用してアクションを処理する方法について説明します。ルールとルールグループを設定するときは、一致するウェブリクエスト AWS WAF の処理方法を選択します。 + **Allow および Block は終了アクションです** – Allow および Block アクションは、一致するウェブリクエストにおける保護パック (ウェブ ACL) のその他の処理をすべて停止されます。保護パック (ウェブ ACL) のルールがリクエストの一致を検出し、ルールアクションが Allowまたはの場合Block、その一致によって保護パック (ウェブ ACL) のウェブリクエストの最終処理が決まります。 AWS WAF は、一致するルールの後にある保護パック (ウェブ ACL) 内の他のルールを処理しません。これに該当するのは、保護パック (ウェブ ACL) に直接追加するルールや、追加されたルールグループに属するルールです。Block アクションでは、保護されたリソースはウェブリクエストを受信または処理しません。 + **Count は非終了アクションです** – Count アクションのあるルールがリクエストと一致すると、 AWS WAF はリクエストをカウントし、その後に保護パック (ウェブ ACL) ルールセットに従うルールの処理を続行します。 + **CAPTCHA およびは、非終了アクションまたは終了アクションChallengeにすることができます** – これらのアクションのいずれかを持つルールがリクエストに一致すると、はそのトークンステータス AWS WAF をチェックします。リクエストに有効なトークンがある場合、は一致と同様にCount一致 AWS WAF を処理し、保護パック (ウェブ ACL) ルールセットに続くルールの処理を続行します。リクエストに有効なトークンがない場合、は評価 AWS WAF を終了し、解決する CAPTCHA パズルまたはサイレントバックグラウンドクライアントセッションチャレンジをクライアントに送信します。ルール評価で終了アクションが発生しない場合、は保護パック (ウェブ ACL) のデフォルトアクションをリクエスト AWS WAF に適用します。詳細については、「[で保護パック (ウェブ ACL) のデフォルトアクションを設定する AWS WAF](web-acl-default-action.md)」を参照してください。保護パック (ウェブ ACL) では、ルールグループ内のルールのアクション設定をオーバーライドしたり、ルールグループによって返されるアクションを上書きしたりできます。詳細については、「[でのルールグループアクションの上書き AWS WAF](web-acl-rule-group-override-options.md)」を参照してください。 **アクションと優先度設定の相互作用** ウェブリクエスト AWS WAF に適用されるアクションは、保護パック (ウェブ ACL) のルールの数値優先度設定の影響を受けます。例えば、保護パック (ウェブ ACL) に Allow アクションと 50 の優先順位の数値を持つルール、ならび Count アクションと 100 の優先順位の数値を持つ別のルールがあるとします。 AWS WAF は優先順位に応じて最小のものからウェブ ACL 内のルールが評価するため、許可ルールをカウントルールより先に評価します。両方のルールに一致するウェブリクエストは、最初に許可ルールに一致します。Allow は終了アクションであるため、 AWS WAF はこの一致で評価を停止し、カウントルールに対してリクエストを評価しません。 + 許可ルールに一致しないリクエストのみをカウントルールメトリクスに含める場合は、ルールの優先度設定が便利です。 + 一方、許可ルールに一致するリクエストに対してもカウントルールのカウントメトリクスを取得する場合、カウントルールには許可ルールより小さい優先順位の数値を設定し、先に実行されるようにする必要があります。優先順位の設定の詳細については、「[ルールの優先度を設定する](web-acl-processing-order.md)」を参照してください。 # でのルールグループアクションの上書き AWS WAF このセクションでは、ルールグループアクションを上書きする方法について説明します。ルールグループを保護パック (ウェブ ACL) に追加するとき、一致するウェブリクエストに対して実行されるアクションをオーバーライドできます。保護パック (ウェブ ACL) 設定内のルールグループのアクションをオーバーライドしても、ルールグループ自体は変更されません。保護パック (ウェブ ACL) のコンテキストでがルールグループ AWS WAF を使用する方法のみを変更します。 ## ルールグループのルールアクションの上書きルールグループ内のルールのアクションは、任意の有効なルールアクションにオーバーライドきできます。これを実行すると、一致するリクエストは、設定されたルールのアクションがオーバーライド設定である場合とまったく同様に処理されます。 **注記** ルールアクションは、終了アクションまたは非終了アクションである場合があります。終了アクションは、リクエストの保護パック (ウェブ ACL) 評価を停止し、保護されたアプリケーションへのリクエストの継続を許可またはブロックします。ルールアクションのオプションは以下のとおりです。 + **Allow** – AWS WAF リクエストを保護された AWS リソースに転送して処理および応答できるようにします。これは終了アクションです。定義したルールでは、リクエストを保護されたリソースに転送する前に、カスタムヘッダーを挿入できます。 + **Block** – リクエストを AWS WAF ブロックします。これは終了アクションです。デフォルトでは、保護された AWS リソースは HTTP `403 (Forbidden)`ステータスコードで応答します。定義したルールでは、応答をカスタマイズできます。がリクエストを AWS WAF ブロックすると、Blockアクション設定によって、保護されたリソースがクライアントに返すレスポンスが決まります。 + **Count** – リクエストを AWS WAF カウントしますが、許可するかブロックするかは決定しません。これは非終了アクションです。 AWS WAF は保護パック (ウェブ ACL) の残りのルールの処理を継続します。定義したルールでは、リクエストにカスタムヘッダーを挿入し、他のルールで一致するラベルを追加できます。 + **CAPTCHA および Challenge** – CAPTCHA パズルとサイレントチャレンジ AWS WAF を使用して、リクエストがボットから送信されていないことを確認し、トークン AWS WAF を使用して最近成功したクライアントレスポンスを追跡します。 CAPTCHA パズルとサイレントチャレンジは、ブラウザが HTTPS エンドポイントにアクセスしている場合にのみ実行できます。トークンを取得するには、ブラウザクライアントが安全なコンテキストで実行されている必要があります。 **注記** CAPTCHA または Challenge ルールアクションを 1 つのルールで使用、あるいはルールグループでルールアクションのオーバーライドとして使用すると、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。これらのルールアクションは、リクエスト内のトークンの状態に応じて、終了アクションまたは非終了アクションである場合があります。 + **有効で有効期限が切れていないトークンの非終了** – トークンが有効で、設定された CAPTCHA またはチャレンジイミュニティ時間に従って有効期限が切れていない場合、は Count action のようなリクエスト AWS WAF を処理します。 AWS WAF は引き続き、保護パック (ウェブ ACL) の残りのルールに基づいてウェブリクエストを検査します。Count 設定と同様に、定義したルールでは、リクエストに挿入するカスタムヘッダーを使用してこれらのアクションを設定したり (オプション)、他のルールが照合できるラベルを追加したりできます。 + 無効**または期限切れのトークンのブロックされたリクエストで終了** – トークンが無効であるか、指定されたタイムスタンプの有効期限が切れている場合、は Block アクションと同様にウェブリクエストの検査 AWS WAF を終了し、リクエストをブロックします。 AWS WAF その後、はカスタムレスポンスコードでクライアントに応答します。CAPTCHA には、リクエスト内容はクライアントのブラウザが処理できることが示された場合、 AWS WAF は人間のクライアントとボットを区別するように設計された JavaScript インタースティシャルで CAPTCHA パズルを送信します。Challenge アクションの場合、は、通常のブラウザをボットによって実行されているセッションと区別するように設計されたサイレントチャレンジで JavaScript インタースティシャル AWS WAF を送信します。詳細については、「[CAPTCHA および Challengeの AWS WAF](waf-captcha-and-challenge.md)」を参照してください。このオプションの使用方法については、「[ルールグループ内のルールアクションのオーバーライド](web-acl-rule-group-settings.md#web-acl-rule-group-rule-action-override)」を参照してください。 ### ルールアクションを Count にオーバーライドルールアクションオーバーライドの最も一般的な使用例は、ルールアクションの一部またはすべてを Count にオーバーライドして、ルールグループの動作を本番稼働に移行する前にテストおよびモニタリングすることです。これを使用して誤検出を生成しているルールグループをトラブルシューティングすることもできます。誤検出は、ブロックすると想定していないトラフィックをルールグループがブロックするときに発生します。ルールグループ内で、許可したいリクエストをブロックするルールを特定した場合、そのルールに対するこのカウントアクションのオーバーライドを保持し、リクエストに対するアクションを除外できます。テストでルールアクションのオーバーライドを使用する詳細については、「[AWS WAF 保護のテストとチューニング](web-acl-testing.md)」を参照してください。 ### JSON リスト: `RuleActionOverrides` を `ExcludedRules` に置き換えます 2022 年 10 月 27 日より前に保護パック (ウェブ ACL) 設定Countでルールグループのルールアクションをに設定した場合、は保護パック (ウェブ ACL) JSON にオーバーライドをとして AWS WAF 保存しました`ExcludedRules`。これで、ルールを Count にオーバーライドする JSON 設定が `RuleActionOverrides` 設定に追加されました。 JSON リストですべての `ExcludedRules` 設定は、アクションを Count に設定した `RuleActionOverrides` 設定に更新することをお勧めします。API はどちらの設定も受け付けますが、新しい `RuleActionOverrides` 設定のみを使用した場合、コンソール作業と API 作業の間で JSON リストの一貫性が保たれます。 **注記** AWS WAF コンソールでは、保護パック (ウェブ ACL) **のサンプルリクエスト**タブには、古い設定のルールのサンプルは表示されません。詳細については、「[ウェブリクエストのサンプルの表示](web-acl-testing-view-sample.md)」を参照してください。 AWS WAF コンソールを使用して既存のルールグループ設定を編集すると、コンソールは JSON のすべての`RuleActionOverrides`設定を `ExcludedRules` 設定に自動的に変換し、オーバーライドアクションはに設定されますCount。 + 現在の設定例: ``` "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesAdminProtectionRuleSet", "RuleActionOverrides": [ { "Name": "AdminProtection_URIPATH", "ActionToUse": { "Count": {} } } ] ``` + 古い設定例: ``` OLD SETTING "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesAdminProtectionRuleSet", "ExcludedRules": [ { "Name": "AdminProtection_URIPATH" } ] OLD SETTING ``` ## ルールグループの戻り値アクションを Count に上書きルールグループが返すアクションをオーバーライドして、Count に設定できます。 **注記** これは、がルールグループ自体 AWS WAF を評価する方法を変更しないため、ルールグループのルールをテストするには適していません。ルールグループ評価から保護パック (ウェブ ACL) に返される結果 AWS WAF の処理方法にのみ影響します。ルールグループ内のルールをテストする場合は、前述のセクションで説明したオプション [ルールグループのルールアクションの上書き](#web-acl-rule-group-override-options-rules) を使用します。ルールグループアクションをに上書きするとCount、はルールグループ評価を正常に AWS WAF 処理します。ルールグループ内のルールが一致しない、あるいはすべての一致するルールに Count アクションがある場合、このオーバーライドはルールグループまたは保護パック (ウェブ ACL) の処理に影響を与えません。ウェブリクエストに一致し、終了ルールアクションを持つルールグループの最初のルールは、 AWS WAF がルールグループの評価を停止し、終了アクションの結果を保護パック (ウェブ ACL) 評価レベルに返します。この時点で、保護パック (ウェブ ACL) 評価では、このオーバーライドが有効になります。ルールグループ評価の結果がアクションのみになるように、このオーバーライドは終了Countアクションを AWS WAF 上書きします。 AWS WAF その後、は保護パック (ウェブ ACL) の残りのルールの処理を続行します。このオプションの使用方法については、「[ルールグループの評価結果を Count にオーバーライド](web-acl-rule-group-settings.md#web-acl-rule-group-action-override)」を参照してください。 # で保護パック (ウェブ ACL) のデフォルトアクションを設定する AWS WAF このセクションでは、保護パック (ウェブ ACL) のデフォルトアクションの仕組みについて説明します。保護パック (ウェブ ACL) を作成および設定するときに、保護パック (ウェブ ACL) のデフォルトアクションを設定する必要があります。 AWS WAF は、終了アクションが適用されることなく、保護パック (ウェブ ACL) のルール評価をすべて通過したウェブリクエストすべてに、このアクションを適用します。終了アクションは、リクエストの保護パック (ウェブ ACL) 評価を停止し、保護されたアプリケーションへのリクエストの継続を許可またはブロックします。ルールアクションについては、「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」を参照してください。保護パック (ウェブ ACL) のデフォルトアクションがウェブリクエストの最終的な処理を決定する必要があります。したがって、これは終了アクションです。 + **Allow** – ほとんどのユーザーに対してウェブサイトへのアクセスを許可する一方、指定した IP アドレスからのリクエストまたは悪意のある SQL コードや指定した値が含まれている可能性があるリクエストを行う攻撃者に対してアクセスを拒否する場合、デフォルトアクションとして Allow を選択します。その後、ブロックする特定のリクエストを識別してブロックするルールを、保護パック (ウェブ ACL) に追加します。このアクションを使用すると、保護されたリソースに転送する前に、カスタムヘッダーをリクエストに挿入できます。 + **Block** – ほとんどのユーザーに対してはウェブサイトへのアクセスを拒否する一方、指定した IP アドレスからのリクエストまたは指定した値が含まれているリクエストを行うユーザーに対してアクセスを許可する場合、デフォルトアクションとして Block を選択します。その後、許可する特定のリクエストを識別して許可するルールを、保護パック (ウェブ ACL) に追加します。デフォルトでは、 Blockアクションでは、 AWS リソースは HTTP `403 (Forbidden)`ステータスコードで応答しますが、応答をカスタマイズできます。リクエストとレスポンスをカスタマイズする方法については、「[でカスタマイズされたウェブリクエストとレスポンス AWS WAF](waf-custom-request-response.md)」を参照してください。独自のルールとルールグループの設定は、ほとんどのウェブリクエストを許可するかブロックするかに応じて、一部が異なります。例えば、ほとんどのリクエストを *許可する* 場合、保護パック (ウェブ ACL) のデフォルトアクションを Allow に設定し、その後に *ブロックする* ウェブリクエストを識別するルールを追加します。これには次のようなリクエストが該当します。 + リクエスト数が不当に多い IP アドレスからのリクエスト + お客様がビジネスを行っていない国、または頻繁に攻撃元になっている国からのリクエスト + `User-agent` ヘッダーに不正な値が含まれているリクエスト + 悪意のある SQL コードが含まれている可能性があるリクエストマネージドルールグループのルールは通常、Block アクションを使用しますが、すべての場合に限りません。例えば、Bot Control に使用される一部のルールでは、CAPTCHA および Challenge アクション設定を使用します。マネージドルールグループの詳細については、「[でのマネージドルールグループの使用 AWS WAF](waf-managed-rule-groups.md)」を参照してください。 # でのボディ検査の管理に関する考慮事項 AWS WAF 本文検査サイズ制限は、が検査 AWS WAF できるリクエスト本文の最大サイズです。ウェブリクエスト本文が制限より大きい場合、基盤となるホストサービスは、制限内のコンテンツを検査 AWS WAF のためにに転送します。 + Application Load Balancer およびの場合 AWS AppSync、制限は 8 KB (8,192 バイト) に固定されます。 + CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Access の場合、デフォルトの制限は 16 KB (16,384 バイト) であり、任意のリソースタイプの制限を 16 KB、最大 64 KB の増分で増やすことができます。設定オプションは 16 KB、32 KB、48 KB、および 64 KB です。 **重要** AWS WAF は、gRPC トラフィックのリクエスト本文検査ルールをサポートしていません。これらのルールを CloudFront ディストリビューションまたは Application Load Balancer の保護パック (ウェブ ACL) で有効にした場合、gRPC を使用するすべてのリクエストでは、リクエスト本文の検査ルールを無視します。他のすべての AWS WAF ルールは引き続き適用されます。詳細については、*Amazon CloudFront デベロッパーガイド*」の[「ディストリビューション AWS WAF の有効化](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/WAF-one-click.html)」を参照してください。 **オーバーサイズ本文の処理** ウェブトラフィックに制限を超えるサイズのボディが含まれている場合は、設定されたオーバーサイズ処理が適用されます。オーバーサイズの処理のオプションの詳細については、[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md) を参照してください。 **制限設定を増やすための料金に関する考慮事項** AWS WAF は、リソースタイプのデフォルト制限内にあるトラフィックを検査するためのベースレートを請求します。 CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Access リソースの場合、制限設定を増やすと、検査 AWS WAF できるトラフィックには、新しい制限までの本文サイズが含まれます。ボディサイズがデフォルトの 16 KB よりも大きいリクエストの検査に対してのみ、追加料金がかかります。料金の詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。 **ボディ検査サイズの制限の変更オプション** CloudFront、API Gateway、Amazon Cognito、App Runner、または Verified Access リソースのボディ検査サイズ制限を設定できます。保護パック (ウェブ ACL) を作成または編集するときは、リソースの関連付け設定でボディ検査サイズの制限を修正できます。API については、[AssociationConfig](https://docs.aws.amazon.com/waf/latest/APIReference/API_AssociationConfig.html) の保護パック (ウェブ ACL) の関連付け設定を参照してください。コンソールについては、保護パック (ウェブ ACL) の関連リソースを指定するページにある設定を参照してください。コンソール設定に関するガイダンスについては、「[でのウェブトラフィックメトリクスの表示 AWS WAF](web-acl-working-with.md)」を参照してください。 # での CAPTCHA、チャレンジ、トークンの設定 AWS WAF CAPTCHA またはルールChallengeアクションを使用するルールと、 AWS WAF マネージド保護のサイレントクライアントチャレンジを管理するアプリケーション統合 SDKs に対して、保護パック (ウェブ ACL) のオプションを設定できます。これらの機能は、エンドユーザーに CAPTCHA パズルで挑戦させて、クライアントセッションにサイレントチャレンジを提供することにより、ボットの活動を軽減します。クライアントが応答に成功すると、 AWS WAF はクライアントがウェブリクエストで使用するトークンを提供します。このトークンは最後に成功したパズルおよびチャレンジレス応答のタイムスタンプが付いています。詳細については、「[でのインテリジェントな脅威の軽減 AWS WAF](waf-managed-protections.md)」を参照してください。保護パック (ウェブ ACL) 設定では、がこれらのトークン AWS WAF を管理する方法を設定できます。 + **CAPTCHA およびチャレンジイミュニティ時間** – CAPTCHA またはチャレンジのタイムスタンプの有効期間を指定します。保護パック (ウェブ ACL) 設定は、独自のイミュニティ時間設定が設定されていないすべてのルール、ならびにアプリケーション統合 SDK にも継承されます。詳細については、「[でのタイムスタンプの有効期限とトークンイミュニティ時間の設定 AWS WAF](waf-tokens-immunity-times.md)」を参照してください。 + **トークンドメイン** – デフォルトでは、は保護パック (ウェブ ACL) が関連付けられているリソースのドメインに対してのみトークン AWS WAF を受け入れます。トークンドメインリストを設定すると、はリスト内のすべてのドメインと、関連付けられたリソースのドメインのトークン AWS WAF を受け入れます。詳細については、「[AWS WAF 保護パック (ウェブ ACL) トークンドメインリスト設定](waf-tokens-domains.md#waf-tokens-domain-lists)」を参照してください。 # でのウェブトラフィックメトリクスの表示 AWS WAF このセクションでは、ウェブトラフィックメトリクスの概要にアクセスする方法について説明します。使用している保護パック (ウェブ ACL) については、 AWS WAF コンソールの保護パック (ウェブ ACL) のページのトラフィック概要タブにあるウェブ**トラフィック**メトリクスの概要にアクセスできます。コンソールダッシュボードには、アプリケーションウェブトラフィックを評価するときにが AWS WAF 収集する Amazon CloudWatch メトリクスの概要がほぼリアルタイムで表示されます。ダッシュボードのページの詳細については、「[保護パック (ウェブ ACL) のトラフィック概要ダッシュボード](web-acl-dashboards.md)」を参照してください。保護パック (ウェブ ACL) のトラフィックのモニタリングに関する追加情報については、「[AWS WAF 保護のモニタリングと調整](web-acl-testing-activities.md)」を参照してください。 # 保護パック (ウェブ ACL) の削除このセクションでは、 AWS コンソールから保護パック (ウェブ ACLs) を削除する手順について説明します。 **重要** 保護パック (ウェブ ACL) の削除は永続的であり、元に戻すことはできません。保護パック (ウェブ ACL) を削除するには、まず保護パック (ウェブ ACL) からすべての AWS リソースの関連付けを解除します。次の手順を実行します。 ------ #### [ Using the new console ] 1. 新しいにサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2-pro](https://console.aws.amazon.com/wafv2-pro) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで、**[リソースと保護パック (ウェブ ACL)]** を選択します。 1. 保護パック (ウェブ ACL) カードで、**[リソース]** の横にある **[編集]** リンクを選択して、**[リソースの管理]** パネルを開きます。 1. ルールグループの **[リソースの管理]** セクションで、関連付けを解除するリソースを選択し、**[関連付けを解除]** を選択します。 **注記** 一度に 1 つのリソースの関連付けを解除する必要があります。リソースを選択する際に複数選択しないでください。 1. 確認ページで「関連付け解除」と入力し、[**関連付け解除**] を選択します。保護パック (ウェブ ACL) 内の各リソースの関連付け解除を繰り返します。 1. 削除する保護パック (ウェブ ACL) を選択します。コンソールはメイン保護パック (ウェブ ACL) カードを編集可能にし、編集できる詳細を含むサイドパネルも開きます。 1. 詳細パネルで、ごみ箱アイコンを選択します。 1. 確認ページで「delete」と入力し、**[削除]** を選択します。 ------ #### [ Using the standard console ] 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで **[ウェブ ACL]** を選択します。 1. 削除するウェブ ACL の名前を選択します。コンソールでウェブ ACL の説明が表示され、そこで編集できます。 **注記** 削除するウェブ ACL が表示されない場合は、ウェブ ACL セクション内のリージョン選択が正しいことを確認してください。Amazon CloudFront ディストリビューションを保護するウェブ ACL は **[グローバル (CloudFront)]** にあります。 1. **関連付けられた AWS リソース**タブで、関連付けられたリソースごとに、リソース名の横にあるラジオボタンを選択し、**関連付け解除**を選択します。これにより、 AWS リソースから保護パック (ウェブ ACL) の関連付けが解除されます。 1. ナビゲーションペインで **[ウェブ ACL]** を選択します。 1. 削除するウェブ ACL の横にあるラジオボタンを選択し、**[Delete]** (削除) を選択します。 ------ # AWS WAF ルールこのセクションでは、 AWS WAF ルールとその仕組みについて説明します。 AWS WAF ルールは、HTTP(S) ウェブリクエストを検査する方法と、検査基準に一致するリクエストに対して実行するアクションを定義します。ルールは、ルールグループまたは保護パック (ウェブ ACL) のコンテキストでのみ定義されます。ルール自体はに存在しません AWS WAF 。これらは AWS リソースではなく、Amazon リソースネーム (ARNs) もありません。ルールが定義されているルールグループまたは保護パック (ウェブ ACL) に含まれる名前を使用してルールにアクセスします。ルールを管理し、他の保護パック (ウェブ ACL) にコピーするには、そのルールが含まれているルールグループまたは保護パック (ウェブ ACL) の JSON ビューを使用します。また、保護パック (ウェブ ACLs) とルールグループで使用できる AWS WAF コンソールルールビルダーを使用して管理することもできます。 **ルール名** 各ルールには名前が必要です。`AWS` で始まる名前や、他のサービスによって管理されているルールグループまたはルールに使用されている名前は避けてください。「[他のサービスによって提供されるルールグループを識別する](waf-service-owned-rule-groups.md)」を参照してください。 **注記** ルールの名前を変更し、ルールのメトリクス名に変更を反映する場合は、メトリクス名も更新する必要があります。ルール名を変更しても、ルールのメトリクス名は自動的に更新 AWS WAF されません。ルールの JSON エディターを使用して、コンソールでルールを編集するときに、メトリック名を変更できます。API や、保護パック (ウェブ ACL) またはルールグループの定義に使用する JSON リストを使用して、両方の名前を変更することもできます。 **ルールステートメント** 各ルールには、ルールがウェブリクエストを検査する方法を定義するルールステートメントも必要です。ルールステートメントには、ルールとステートメントのタイプに応じて、ネストされたステートメントを任意の深さに含めることができます。一部のルールステートメントは、条件のセットを採用します。例えば、IP セット一致ルールに最大 10,000 個の IP アドレスまたは IP アドレス範囲を指定できます。次のような基準を検査するルールを定義できます。 + 悪意のある可能性が高いスクリプト。攻撃者は、ウェブアプリケーションの脆弱性を悪用できるスクリプトを埋め込みます。これはクロスサイトスクリプティング (XSS) と呼ばれます。 + リクエストの発生元の IP アドレスまたはアドレス範囲。 + リクエスト送信元の国または地理的場所。 + クエリ文字列など、リクエストの指定した部分の長さ。 + 悪意のある可能性が高い SQL コード。攻撃者は、ウェブリクエストに悪意のある SQL コードを埋め込むことで、データベースからデータを抽出しようとします。これは SQL インジェクションと呼ばれます。 + リクエストに表示される文字列。例えば、`User-Agent` ヘッダーに表示される値、またはクエリ文字列に表示されるテキスト文字列です。正規表現を使用してこれらの文字列を指定することもできます。 + 保護パック (ウェブ ACL) の以前のルールがリクエストに追加したラベル。上記のリストにあるようなウェブリクエスト検査基準を持つステートメントに加えて、は、ルール内のステートメントを組み合わせるために`NOT`使用する `AND`、`OR`、およびの論理ステートメント AWS WAF をサポートします。例えば、攻撃者からの最近のリクエストに基づいて、次のネストされたステートメントを組み合わせた論理 `AND` ステートメントを使用してルールを作成できます。 + リクエストが 192.0.2.44 から発生した。 + リクエストの `User-Agent` ヘッダーに `BadBot` 値が含まれる。 + それらのクエリ文字列には、SQL などのコードが含まれる。この場合、上位のレベルの `AND` に一致するようにするには、ウェブリクエストはすべてのステートメントに一致する必要があります。 **Topics** + [ # でのルールアクションの使用 AWS WAF ](waf-rule-action.md) + [ # でのルールステートメントの使用 AWS WAF ](waf-rule-statements.md) + [ # での一致ルールステートメントの使用 AWS WAF ](waf-rule-statements-match.md) + [ # での論理ルールステートメントの使用 AWS WAF ](waf-rule-statements-logical.md) + [ # でのレートベースのルールステートメントの使用 AWS WAF ](waf-rule-statement-type-rate-based.md) + [ # でのルールグループルールステートメントの使用 AWS WAF ](waf-rule-statements-rule-group.md) # でのルールアクションの使用 AWS WAF このセクションでは、ルールアクションの仕組みについて説明します。ルールアクションは、ウェブリクエストがルールで定義された条件と一致する場合に AWS WAF 、ウェブリクエストの処理を指示します。オプションで、各ルールアクションにカスタム動作を追加できます。 **注記** ルールアクションは、終了アクションまたは非終了アクションである場合があります。終了アクションは、リクエストの保護パック (ウェブ ACL) 評価を停止し、保護されたアプリケーションへのリクエストの継続を許可またはブロックします。ルールアクションのオプションは以下のとおりです。 + **Allow** – AWS WAF リクエストを保護された AWS リソースに転送して処理および応答できるようにします。これは終了アクションです。定義したルールでは、リクエストを保護されたリソースに転送する前に、カスタムヘッダーを挿入できます。 + **Block** – リクエストを AWS WAF ブロックします。これは終了アクションです。デフォルトでは、保護された AWS リソースは HTTP `403 (Forbidden)`ステータスコードで応答します。定義したルールでは、応答をカスタマイズできます。がリクエストを AWS WAF ブロックすると、Blockアクション設定によって、保護されたリソースがクライアントに返すレスポンスが決まります。 + **Count** – リクエストを AWS WAF カウントしますが、許可するかブロックするかは決定しません。これは非終了アクションです。 AWS WAF は保護パック (ウェブ ACL) の残りのルールの処理を継続します。定義したルールでは、リクエストにカスタムヘッダーを挿入し、他のルールで一致するラベルを追加できます。 + **CAPTCHA および Challenge** – CAPTCHA パズルとサイレントチャレンジ AWS WAF を使用して、リクエストがボットから来ていないことを確認し、トークン AWS WAF を使用して最近成功したクライアントレスポンスを追跡します。 CAPTCHA パズルとサイレントチャレンジは、ブラウザが HTTPS エンドポイントにアクセスしている場合にのみ実行できます。トークンを取得するには、ブラウザクライアントが安全なコンテキストで実行されている必要があります。 **注記** CAPTCHA または Challenge ルールアクションを 1 つのルールで使用、あるいはルールグループでルールアクションのオーバーライドとして使用すると、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。これらのルールアクションは、リクエスト内のトークンの状態に応じて、終了アクションまたは非終了アクションである場合があります。 + **有効で有効期限が切れていないトークンの非終了** – トークンが有効で、設定された CAPTCHA またはチャレンジイミュニティ時間に従って有効期限が切れていない場合、は Count action のようなリクエスト AWS WAF を処理します。 AWS WAF は引き続き、保護パック (ウェブ ACL) の残りのルールに基づいてウェブリクエストを検査します。Count 設定と同様に、定義したルールでは、リクエストに挿入するカスタムヘッダーを使用してこれらのアクションを設定したり (オプション)、他のルールが照合できるラベルを追加したりできます。 + 無効**または期限切れのトークンのブロックされたリクエストで終了** – トークンが無効であるか、指定されたタイムスタンプの有効期限が切れている場合、は Block アクションと同様にウェブリクエストの検査 AWS WAF を終了し、リクエストをブロックします。 AWS WAF その後、はカスタムレスポンスコードでクライアントに応答します。CAPTCHA には、リクエスト内容はクライアントのブラウザが処理できることが示された場合、 AWS WAF は人間のクライアントとボットを区別するように設計された JavaScript インタースティシャルで CAPTCHA パズルを送信します。Challenge アクションの場合、は、通常のブラウザをボットによって実行されているセッションと区別するように設計されたサイレントチャレンジで JavaScript インタースティシャル AWS WAF を送信します。詳細については、「[CAPTCHA および Challengeの AWS WAF](waf-captcha-and-challenge.md)」を参照してください。リクエストとレスポンスをカスタマイズする方法については、「[でカスタマイズされたウェブリクエストとレスポンス AWS WAF](waf-custom-request-response.md)」を参照してください。一致するリクエストへのラベルの追加については、「[でのウェブリクエストのラベル付け AWS WAF](waf-labels.md)」を参照してください。保護パック (ウェブ ACL) とルール設定の相互作用の詳細については、「[のルールとルールグループで保護パック (ウェブ ACLs) を使用する AWS WAF](web-acl-processing.md)」を参照してください。 # でのルールステートメントの使用 AWS WAF このセクションでは、ルールステートメントの仕組みについて説明します。ルールステートメントは、ウェブリクエストを検査 AWS WAF する方法をに指示するルールの一部です。がウェブリクエストで検査基準 AWS WAF を見つけると、ウェブリクエストはステートメントと一致すると表示されます。すべてのルールステートメントは、ステートメントのタイプに応じて、何をどのように検索するかを指定します。のすべてのルール AWS WAF には 1 つの最上位ルールステートメントがあり、他のステートメントを含めることができます。ルールステートメントは非常にシンプルにすることができます。例えば、ウェブリクエストを検査するための送信国のセットを提供するステートメントを作成したり、保護パック (ウェブ ACL) でルールグループを参照するだけのルールステートメントを保持したりできます。ルールステートメントはまた、非常に複雑にすることもできます。例えば、他の多くのステートメントを論理 AND、OR、および NOT ステートメントと組み合わせたステートメントを作成できます。ほとんどのルールでは、一致するリクエストにカスタム AWS WAF ラベルを追加できます。 AWS マネージドルールルールルールグループのルールは、一致するリクエストにラベルを追加します。ルールが追加するラベルは、保護パック (ウェブ ACL) および AWS WAF ログとメトリクスの後半で評価されるルールへのリクエストに関する情報を提供します。ラベル付けの詳細については、[でのウェブリクエストのラベル付け AWS WAF](waf-labels.md) と [ラベル一致ルールステートメント](waf-rule-statement-type-label-match.md) を参照してください。 **ルールステートメントのネスト** AWS WAF は、多くのルールステートメントのネストをサポートしていますが、すべてではありません。例えば、ルールグループステートメントを別のステートメント内にネストすることはできません。スコープダウンステートメントや論理ステートメントなど、一部のシナリオではネストを使用する必要があります。ルールステートメントのリストとそれに続くルールの詳細では、各カテゴリとルールのネスト機能と要件について説明されています。コンソール内のルールのビジュアルエディタでは、ルールステートメントの 1 レベルのネストしかサポートされません。例えば、論理 AND または OR ルール内に多くのタイプのステートメントをネストできますが、他の AND または OR ルールをネストすることはできません。2 レベルのネストが必要になるからです。複数のレベルのネストを実装するには、コンソールの JSON ルールエディタまたは API を使用して、JSON でルール定義を指定します。 **Topics** + [ # でのルールステートメント設定の調整 AWS WAF ](waf-rule-statement-fields.md) + [ # でのスコープダウンステートメントの使用 AWS WAF ](waf-rule-scope-down-statements.md) + [ # で再利用可能なエンティティを参照する AWS WAF ](waf-rule-statement-reusable-entities.md) # でのルールステートメント設定の調整 AWS WAF このセクションでは、ウェブリクエストのコンポーネントを検査するルールステートメントで指定できる設定について説明します。使用の詳細については、「[での一致ルールステートメントの使用 AWS WAF](waf-rule-statements-match.md)」で個別のルールステートメントを参照してください。これらのウェブリクエストコンポーネントのサブセットは、カスタムリクエスト集約キーとしてレートベースのルールで使用することもできます。詳細については、「[でのレートベースのルールの集計 AWS WAF](waf-rule-statement-type-rate-based-aggregation-options.md)」を参照してください。リクエストコンポーネントの設定では、コンポーネントタイプ自体と、コンポーネントタイプに応じる追加オプションを指定します。例えば、テキストを含むコンポーネントタイプを検査する場合、検査する前にテキスト変換を適用できます。 **注記** 特に明記されていない限り、ウェブリクエストにルールステートメントで指定されたリクエストコンポーネントがない場合、 AWS WAF はリクエストをルール条件に一致しないものとして評価します。 **Contents** + [ # でコンポーネントをリクエストする AWS WAF ](waf-rule-statement-fields-list.md) + [ ## HTTP メソッド ](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-http-method) + [ ## 単一ヘッダー ](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-single-header) + [ ## すべてのヘッダー ](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-headers) + [ ## ヘッダーの順序 ](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-header-order) + [ ## cookie ](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-cookies) + [ ## URI フラグメント ](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-uri-fragment) + [ ## URI パス ](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-uri-path) + [ ## JA3 フィンガープリント ](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-ja3-fingerprint) + [ ## JA4 フィンガープリント ](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-ja4-fingerprint) + [ ## クエリ文字列 ](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-query-string) + [ ## Single query parameter (単一クエリパラメータ) ](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-single-query-param) + [ ## All query parameters (すべてのクエリパラメータ) ](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-all-query-params) + [ ## [Body] (本文) ](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-body) + [ ## JSON 本文 ](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-json-body) + [ # で転送された IP アドレスを使用する AWS WAF ](waf-rule-statement-forwarded-ip-address.md) + [ # での HTTP/2 擬似ヘッダーの検査 AWS WAF ](waf-rule-statement-request-components-for-http2-pseudo-headers.md) + [ # でのテキスト変換の使用 AWS WAF ](waf-rule-statement-transformation.md) # でコンポーネントをリクエストする AWS WAF このセクションでは、検査のために指定できるウェブリクエストのコンポーネントについて説明します。ウェブリクエスト内のパターンを検索する一致ルールステートメントのリクエストコンポーネントを指定します。これらのステートメントのタイプには、文字列一致、正規表現一致、サイズ制約、SQL インジェクション攻撃などのステートメントがあります。リクエストコンポーネント設定の使用方法については、「[での一致ルールステートメントの使用 AWS WAF](waf-rule-statements-match.md)」で個々のルールステートメントを参照してください。特に明記されていない限り、ウェブリクエストにルールステートメントで指定されたリクエストコンポーネントがない場合、 AWS WAF はリクエストをルール条件に一致しないものとして評価します。 **注記** リクエストコンポーネントは、それを必要とするルールステートメントごとに 1 つずつ指定します。リクエストの複数のコンポーネントを検査するには、コンポーネントごとにルールステートメントを作成します。 AWS WAF コンソールと API のドキュメントには、次の場所のリクエストコンポーネント設定に関するガイダンスが記載されています。 + コンソールの**ルールビルダー** – 通常のルールタイプの **[Statement]** (ステートメント) 設定で、**[Request components]** (コンポーネントをリクエスト) の下の **[Inspect]** (検査) ダイアログで検査するコンポーネントを選択します。 + **API ステートメントのコンテンツ** – `FieldToMatch` このセクションの残りの部分では、ウェブリクエストの検査対象部分のオプションについて説明します。 **Topics** + [ ## HTTP メソッド ](#waf-rule-statement-request-component-http-method) + [ ## 単一ヘッダー ](#waf-rule-statement-request-component-single-header) + [ ## すべてのヘッダー ](#waf-rule-statement-request-component-headers) + [ ## ヘッダーの順序 ](#waf-rule-statement-request-component-header-order) + [ ## cookie ](#waf-rule-statement-request-component-cookies) + [ ## URI フラグメント ](#waf-rule-statement-request-component-uri-fragment) + [ ## URI パス ](#waf-rule-statement-request-component-uri-path) + [ ## JA3 フィンガープリント ](#waf-rule-statement-request-component-ja3-fingerprint) + [ ## JA4 フィンガープリント ](#waf-rule-statement-request-component-ja4-fingerprint) + [ ## クエリ文字列 ](#waf-rule-statement-request-component-query-string) + [ ## Single query parameter (単一クエリパラメータ) ](#waf-rule-statement-request-component-single-query-param) + [ ## All query parameters (すべてのクエリパラメータ) ](#waf-rule-statement-request-component-all-query-params) + [ ## [Body] (本文) ](#waf-rule-statement-request-component-body) + [ ## JSON 本文 ](#waf-rule-statement-request-component-json-body) ## HTTP メソッドリクエストの HTTP メソッドが検査されます。HTTP メソッドは、ウェブリクエストが保護対象リソースに対して実行を求めている操作のタイプ (`POST` または `GET` など) を示しています。 ## 単一ヘッダーリクエスト内の単一の名前付きヘッダーが検査されます。このオプションでは、`User-Agent` や `Referer` などのヘッダー名を指定します。名前の文字列一致では大文字と小文字は区別されず、リクエストヘッダーとルールの両方から先頭と末尾のスペースをトリミングした後に実行されます。 ## すべてのヘッダーすべてのリクエストヘッダー (cookie を含む) を検査します。フィルターを適用して、すべてのヘッダーのサブセットを検査できます。このオプションでは、次の仕様を指定します。 + **一致パターン** – inspection のヘッダーのサブセットを取得するために使用するフィルター。は、ヘッダーキーでこれらのパターン AWS WAF を探します。一致パターン設定は、次のいずれかになります。 + **[All]** (すべて) – すべてのキーに一致します。すべてのヘッダーのルール検査基準を評価します。 + **[Excluded headers]** (除外されるヘッダー) – ここで指定した文字列のいずれとも一致しないキーを持つヘッダーのみを検査します。キーと一致する文字列は大文字と小文字に区別されません。一致は、リクエストヘッダーと一致ルールから先頭と末尾のスペースをトリミングした後に実行されます。 + **[Included headers]** (含まれるヘッダー) – ここで指定した文字列のいずれかに一致するキーを持つヘッダーのみを検査します。キーと一致する文字列は大文字と小文字に区別されません。一致は、リクエストヘッダーと一致ルールから先頭と末尾のスペースをトリミングした後に実行されます。 + **一致範囲** – がルール検査基準で検査 AWS WAF する必要があるヘッダーの部分。**[キー]**、**[値]**、または **[すべて]** を指定して、キーと値の両方で一致するものがあるかどうかを検査することができます。 **[すべて]** では、キーで一致するもの、および値で一致するものを見つける必要はありません。キー、値、またはその両方で一致するものを見つける必要があります。キーと値で一致するものを見つけるようにするには、論理 `AND` ステートメントを使用して、キーを検査する一致ルールと値を検査する一致ルールの 2 つを組み合わせます。 + **オーバーサイズ処理** – AWS WAF が検査 AWS WAF できるよりも大きいヘッダーデータを持つリクエストを処理する方法。は、リクエストヘッダーの最初の 8 KB (8,192 バイト) まで、および最初の 200 個のヘッダーまで検査 AWS WAF できます。コンテンツは、最初の制限に達する AWS WAF まで検査できます。検査を続行するか、検査をスキップするかを選択できます。検査をスキップする場合、リクエストがルールに一致するとマークするか一致しないとマークするかを選択できます。オーバーサイズコンテンツの処理の詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。 ## ヘッダーの順序が検査のために AWS WAF 受け取るウェブリクエストに表示される順序で、リクエストのヘッダー名のリストを含む文字列を検査します。 AWS WAF は文字列を生成し、それを検査のコンポーネントと一致するフィールドとして使用します。は、文字列内のヘッダー名をコロンで AWS WAF 区切り、スペースを追加しません。例: `host:user-agent:accept:authorization:referer`。このオプションでは、次の仕様を指定します。 + **オーバーサイズ処理** – AWS WAF が検査 AWS WAF できる数以上のヘッダーデータを持つリクエストを処理する方法。は、リクエストヘッダーの最初の 8 KB (8,192 バイト) まで、および最初の 200 ヘッダーまでを検査 AWS WAF できます。コンテンツは、最初の制限に達する AWS WAF まで検査できます。使用可能なヘッダーの検査を続行するか、検査をスキップするかを選択できます。検査をスキップする場合、リクエストがルールに一致するか一致しないかをマークします。オーバーサイズコンテンツの処理の詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。 ## cookie すべてのリクエスト cookie を検査します。フィルターを適用して、すべての cookie のサブセットを検査できます。このオプションでは、次の仕様を指定します。 + **[Match patterns]** (一致パターン) – 検査用の cookie のサブセットを取得するために使用するフィルター。 AWS WAF は、cookie キーでこれらのパターンを検索します。一致パターン設定は、次のいずれかになります。 + **[All]** (すべて) – すべてのキーに一致します。すべての cookie のルール検査基準を評価します。 + **[Excluded cookies]** (除外される cookie) – ここで指定した文字列のいずれとも一致しないキーを持つ cookie のみを検査します。キーの文字列一致は大文字と小文字が区別され、完全に一致する必要があります。 + **[Included cookies]** (含まれる cookie) – ここで指定した文字列のいずれかに一致するキーを持つ cookie のみを検査します。キーの文字列一致は大文字と小文字が区別され、完全に一致する必要があります。 + **一致範囲** – がルール検査基準で検査 AWS WAF する必要がある Cookie の一部。キーと値の両方に、**[Keys]** (キー)、**[Values]** (値)、または **[All]** (すべて) を指定できます。 **[すべて]** では、キーで一致するもの、および値で一致するものを見つける必要はありません。キー、値、またはその両方で一致するものを見つける必要があります。キーと値で一致するものを見つけるようにするには、論理 `AND` ステートメントを使用して、キーを検査する一致ルールと値を検査する一致ルールの 2 つを組み合わせます。 + **オーバーサイズ処理** – AWS WAF が検査 AWS WAF できるよりも大きい Cookie データを持つリクエストを処理する方法。は、リクエスト Cookie の最初の 8 KB (8,192 バイト) まで、および最初の 200 個の Cookie まで検査 AWS WAF できます。コンテンツは、最初の制限に達する AWS WAF まで検査できます。検査を続行するか、検査をスキップするかを選択できます。検査をスキップする場合、リクエストがルールに一致するとマークするか一致しないとマークするかを選択できます。オーバーサイズコンテンツの処理の詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。 ## URI フラグメント **注記** フラグメント検査は、CloudFront ディストリビューションと Application Load Balancer でのみ利用可能です。「\$1」記号の後に続く URL の一部を検査し、\$1section2 など、リソースに関する追加情報を提供します。詳細については、「[Uniform Resource Identifier (URI): 一般的な構文](https://tools.ietf.org/html/rfc3986#section-3)」を参照してください。このオプションでテキスト変換を使用しない場合、 AWS WAF は URI フラグメントを正規化せず、リクエストでクライアントから受信したとおりに検査します。テキスト変換については、「[でのテキスト変換の使用 AWS WAF](waf-rule-statement-transformation.md)」を参照してください。 **ルールステートメントの要件** このルールステートメントにはフォールバック動作を指定する必要があります。フォールバック動作は、URI にフラグメントがないか、関連するサービスが Application Load Balancer または CloudFront でない場合にウェブリクエスト AWS WAF に割り当てる一致ステータスです。一致を選択した場合、はリクエストをルールステートメントに一致するものとして AWS WAF 処理し、ルールアクションをリクエストに適用します。一致しないことを選択した場合、はリクエストをルールステートメントと一致しないものとして AWS WAF 扱います。 ## URI パス URL 内でリソースを識別する部分 (`/images/daily-ad.jpg` など) が検査されます。詳細については、「[Uniform Resource Identifier (URI): 一般的な構文](https://tools.ietf.org/html/rfc3986#section-3)」を参照してください。このオプションでテキスト変換を使用しない場合、 AWS WAF は URI を正規化せず、リクエストでクライアントから受信したとおりに検査します。テキスト変換については、「[でのテキスト変換の使用 AWS WAF](waf-rule-statement-transformation.md)」を参照してください。 ## JA3 フィンガープリントリクエストの JA3 フィンガープリントを検査します。 **注記** JA3 フィンガープリント検査は、Amazon CloudFront ディストリビューションと Application Load Balancer でのみ利用可能です。 JA3 フィンガープリントは、受信リクエストの TLS Client Hello から生成される 32 文字のハッシュです。このフィンガープリントは、クライアントの TLS 設定の一意の識別子として機能します。 AWS WAF は、計算に十分な TLS Client Hello 情報を持つリクエストごとに、このフィンガープリントを計算してログに記録します。この情報は、ほとんどすべてのウェブリクエストに含まれています。 **クライアントの JA3 フィンガープリントを取得する方法** クライアントリクエストの JA3 フィンガープリントは、保護パック (ウェブ ACL) ログからを取得できます。 AWS WAF がフィンガープリントを計算できる場合は、それをログに含めます。フィールドのログ記録については、「[保護パック (ウェブ ACL) トラフィックのログフィールド](logging-fields.md)」を参照してください。 **ルールステートメントの要件** JA3 フィンガープリントは、指定した文字列と完全に一致するように設定されている文字列一致ステートメント内のみで検査することができます。同じ TLS 設定を持つ将来のリクエストと一致させるために、文字列一致ステートメントの仕様のログから JA3 フィンガープリント文字列を指定します。文字列一致ルールステートメントの詳細については、「[文字列一致ルールステートメント](waf-rule-statement-type-string-match.md)」を参照してください。このルールステートメントにはフォールバック動作を指定する必要があります。フォールバック動作は、が JA3 フィンガープリントを計算できない場合にウェブリクエスト AWS WAF AWS WAF に割り当てる一致ステータスです。一致を選択した場合、 AWS WAF はリクエストをルールステートメントに一致するものとして処理し、ルールアクションをリクエストに適用します。一致しないことを選択した場合、はリクエストをルールステートメントと一致しないものとして AWS WAF 扱います。この一致オプションを使用するには、保護パック (ウェブ ACL) トラフィックをログに記録する必要があります。詳細については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。 ## JA4 フィンガープリントリクエストの JA4 フィンガープリントを検査します。 **注記** JA4 フィンガープリント検査は、Amazon CloudFront ディストリビューションと Application Load Balancer でのみ使用できます。 JA4 フィンガープリントは、受信リクエストの TLS Client Hello から派生した 36 文字のハッシュです。このフィンガープリントは、クライアントの TLS 設定の一意の識別子として機能します。JA4 フィンガープリントは JA3 フィンガープリントの拡張機能であり、一部のブラウザでは一意のフィンガープリントが少なくなります。 AWS WAF は、計算に十分な TLS Client Hello 情報を持つリクエストごとにこのフィンガープリントを計算してログに記録します。この情報は、ほとんどすべてのウェブリクエストに含まれています。 **クライアントの JA4 フィンガープリントを取得する方法** クライアントリクエストの JA4 フィンガープリントは、保護パック (ウェブ ACL) ログからを取得できます。 AWS WAF がフィンガープリントを計算できる場合は、それをログに含めます。フィールドのログ記録については、「[保護パック (ウェブ ACL) トラフィックのログフィールド](logging-fields.md)」を参照してください。 **ルールステートメントの要件** JA4 フィンガープリントは、指定した文字列と完全に一致するように設定された文字列一致ステートメント内でのみ検査できます。同じ TLS 設定を持つ将来のリクエストと一致するように、文字列一致ステートメント仕様のログから JA4 フィンガープリント文字列を指定します。文字列一致ルールステートメントの詳細については、「[文字列一致ルールステートメント](waf-rule-statement-type-string-match.md)」を参照してください。このルールステートメントにはフォールバック動作を指定する必要があります。フォールバック動作は、が JA4 フィンガープリントを計算できない場合にウェブリクエスト AWS WAF AWS WAF に割り当てる一致ステータスです。一致を選択した場合、 AWS WAF はリクエストをルールステートメントに一致するものとして処理し、ルールアクションをリクエストに適用します。一致しないことを選択した場合、はリクエストをルールステートメントと一致しないものとして AWS WAF 扱います。この一致オプションを使用するには、保護パック (ウェブ ACL) トラフィックをログに記録する必要があります。詳細については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。 ## クエリ文字列 URL 内で `?` 文字の後に続く部分 (ある場合) が検査されます。 **注記** クロスサイトスクリプティングの一致ステートメントについては、**[Query string]** (クエリ文字列) ではなく、**[All query parameters]** (すべてのクエリパラメータ) を選択することをお勧めします。**[All query parameters]** (すべてのクエリパラメータ) を選択すると、基本コストに 10 WCU が追加されます。 ## Single query parameter (単一クエリパラメータ) クエリ文字列の一部として定義した単一のクエリパラメータを検査します。 AWS WAF は、指定したパラメータの値を検査します。このオプションでは、**[Query argument]** (クエリ引数) も指定します。例えば、URL が `www.xyz.com?UserName=abc&SalesRegion=seattle` である場合は、クエリ引数として `UserName` または `SalesRegion` を指定できます。引数の名前は最大 30 文字です。名前では大文字と小文字が区別されないため、`UserName` と指定すると、 AWS WAF では `UserName` のすべてのバリエーション (`username`、`UsERName` など) と一致します。クエリ文字列に、指定したクエリ引数の複数のインスタンスが含まれている場合、 OR はロジックを使用して一致のすべての値を AWS WAF 検査します。例えば、URL `www.xyz.com?SalesRegion=boston&SalesRegion=seattle` では、 AWS WAF は、指定された名前を `boston` および `seattle` に対して評価します。いずれかが一致する場合、検査結果は一致となります。 ## All query parameters (すべてのクエリパラメータ) リクエスト内のすべてのクエリパラメータが検査されます。これは単一のクエリパラメータコンポーネントの選択に似ていますが、クエリ文字列内のすべての引数の値を AWS WAF 検査します。例えば、URL が `www.xyz.com?UserName=abc&SalesRegion=seattle` である場合は、`UserName` または `SalesRegion` の値が検査基準に一致すると、 AWS WAF は一致をトリガーします。このオプションを選択すると、基本コストに 10 WCU が追加されます。 ## [Body] (本文) プレーンテキストとして評価されて、リクエストボディが検査されます。また、JSON コンテンツタイプを使用して、本文を JSON として評価することもできます。リクエストボディは、リクエストの一部で、リクエストヘッダーの直後に続く部分です。これには、フォームからのデータなど、ウェブリクエストに必要な追加データが含まれます。 + コンソールで、**[Content type]** (コンテンツタイプ) の **[Plain text]** (プレーンテキスト) を選択して、**[Request option]** (リクエストオプション) の **[Body]** (本文) でこれを選択します。 + API では、ルールの `FieldToMatch` の指定で、リクエストボディをプレーンテキストとして検査するように `Body` を指定します。 Application Load Balancer およびの場合 AWS AppSync、はリクエストの本文の最初の 8 KB を検査 AWS WAF できます。CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Access では、デフォルトで最初の 16 KB を検査 AWS WAF でき、保護パック (ウェブ ACL) 設定で制限を最大 64 KB まで増やすことができます。詳細については、「[でのボディ検査の管理に関する考慮事項 AWS WAF](web-acl-setting-body-inspection-limit.md)」を参照してください。このコンポーネントタイプには、オーバーサイズの処理を指定する必要があります。オーバーサイズ処理は、が検査 AWS WAF できるよりも大きい本文データを持つリクエストをが AWS WAF 処理する方法を定義します。検査を続行するか、検査をスキップするかを選択できます。検査をスキップする場合、リクエストがルールに一致するとマークするか一致しないとマークするかを選択できます。オーバーサイズコンテンツの処理の詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。本文を解析された JSON として評価することもできます。これに関する詳細については、次のセクションを参照してください。 ## JSON 本文 JSON として評価されて、リクエストボディが検査されます。本文をプレーンテキストとして評価することもできます。リクエストボディは、リクエストの一部で、リクエストヘッダーの直後に続く部分です。これには、フォームからのデータなど、ウェブリクエストに必要な追加データが含まれます。 + コンソールで、**[Content type]** (コンテンツタイプ) の **[JSON]** を選択して、**[Request option]** (リクエストオプション) の **[Body]** (本文) でこれを選択します。 + API で、ルールの `FieldToMatch` の指定で `JsonBody` を指定します。 Application Load Balancer およびの場合 AWS AppSync、はリクエストの本文の最初の 8 KB を検査 AWS WAF できます。CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Access では、デフォルトで最初の 16 KB を検査 AWS WAF でき、保護パック (ウェブ ACL) 設定で制限を最大 64 KB まで増やすことができます。詳細については、「[でのボディ検査の管理に関する考慮事項 AWS WAF](web-acl-setting-body-inspection-limit.md)」を参照してください。このコンポーネントタイプには、オーバーサイズの処理を指定する必要があります。オーバーサイズ処理は、が検査 AWS WAF できるよりも大きい本文データを持つリクエストをが AWS WAF 処理する方法を定義します。検査を続行するか、検査をスキップするかを選択できます。検査をスキップする場合、リクエストがルールに一致するとマークするか一致しないとマークするかを選択できます。オーバーサイズコンテンツの処理の詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。このオプションを選択すると、一致ステートメントの基本コスト WCU が 2 倍になります。例えば、一致ステートメントのベースコストが JSON 解析なしで 5 WCU の場合、JSON 解析を使用すると、コストが 10 WCU に倍増します。このオプションでは、以下のセクションで説明されている通り追加の仕様を提供します。 **が JSON 本文検査 AWS WAF を処理する方法** は、ウェブリクエスト本文を JSON として AWS WAF 検査する場合、本文を解析し、検査用に JSON 要素を抽出するステップを実行します。は、設定の選択に従ってこれらのステップ AWS WAF を実行します。が AWS WAF 実行するステップを以下に示します。 1. **本文の内容を解析する** – は、検査用に JSON 要素を抽出するためにウェブリクエスト本文の内容を AWS WAF 解析します。は本文のコンテンツ全体を解析するために最善を AWS WAF 尽くしますが、コンテンツのさまざまなエラー状態で解析が失敗する可能性があります。例としては、無効な文字、重複するキー、切り捨て、ルートノードがオブジェクトまたは配列ではないコンテンツなどがあります。オプションの**本文解析フォールバック動作**によって AWS WAF 、JSON 本文を完全に解析できなかった場合の動作が決まります。 + **None (デフォルトの動作)** - 解析エラーが発生した時点までのみコンテンツ AWS WAF を評価します。 + **文字列として評価** - 本文をプレーンテキストとして検査します。は、JSON 検査用に定義したテキスト変換と検査基準を本文テキスト文字列 AWS WAF に適用します。 + **一致** - ウェブリクエストをルールステートメントに一致するものとして扱います。はルールアクションをリクエスト AWS WAF に適用します。 + **一致なし** - ウェブリクエストをルールステートメントと一致しないものとして処理します。 **注記** このフォールバック動作は、JSON 文字列の解析中にでエラー AWS WAF が発生した場合にのみトリガーされます。 **解析では JSON が完全に検証されません** AWS WAF 解析では入力 JSON 文字列が完全に検証されないため、無効な JSON であっても解析が成功する可能性があります。たとえば、はエラーなしで次の無効な JSON を AWS WAF 解析します。 + カンマ不足: `{"key1":"value1""key2":"value2"}` + コロン不足: `{"key1":"value1","key2""value2"}` + 余分なコロン: `{"key1"::"value1","key2""value2"}` このように、解析は成功したものの結果が完全に有効な JSON ではない場合、評価の後続のステップの結果が異なることがあります。抽出で一部の要素が欠落したり、ルール評価で予期しない結果が出たりする可能性があります。アプリケーションで受信した JSON を検証し、必要に応じて無効な JSON を処理することをお勧めします。 1. **JSON 要素を抽出** – 設定に従って検査する JSON 要素のサブセット AWS WAF を識別します。 + オプション **JSON 一致スコープ**は、が検査 AWS WAF する JSON 内の要素のタイプを指定します。キーと値の両方に、**[Keys]** (キー)、**[Values]** (値)、または **[All]** (すべて) を指定できます。 **[すべて]** では、キーで一致するもの、および値で一致するものを見つける必要はありません。キー、値、またはその両方で一致するものを見つける必要があります。キーと値で一致するものを見つけるようにするには、論理 `AND` ステートメントを使用して、キーを検査する一致ルールと値を検査する一致ルールの 2 つを組み合わせます。 + **検査するコンテンツ**オプションは、 AWS WAF 検査するサブセットに設定された要素をフィルタリングする方法を指定します。いずれかを指定する必要があります。 + **[完全な JSON コンテンツ]** – すべての要素を評価します。 + **[含まれる要素のみ]** – パスが提供された JSON ポインタの基準に一致する要素のみを評価します。このオプションで JSON 内のすべてのパスを表示しないでください。**代わりに **[完全な JSON コンテンツ]** を使用してください。 JSON ポインタ構文の詳細については、インターネットエンジニアリングタスクフォース (IETF) ドキュメントの「[JavaScript オブジェクト表記 (JSON) ポインタ](https://tools.ietf.org/html/rfc6901)」を参照してください。例えば、コンソールで次の内容を指定できます。 ``` /dogs/0/name /dogs/1/name ``` API または CLI では、次を指定できます。 ``` "IncludedPaths": ["/dogs/0/name", "/dogs/1/name"] ``` 例えば、**[検査するコンテンツ]** 設定が **[含まれる要素のみ]** で、含まれている要素設定が `/a/b` であるとします。たとえば、次の JSON ボディの例の場合: ``` { "a":{ "c":"d", "b":{ "e":{ "f":"g" } } } } ``` が各 **JSON 一致スコープ**設定を検査 AWS WAF する要素セットを以下に示します。含まれている要素のパスの一部であるキー `b` は評価されないことを注意してください。 + **すべて**: `e`、`f,` および `g`。 + **キー **: `e` および `f`。 + **値**: `g`。 1. **JSON 要素セットの検査** – 抽出された JSON 要素に指定したテキスト変換 AWS WAF を適用し、結果の要素セットをルールステートメントの一致基準と照合します。これは、他のウェブリクエストコンポーネントに対するものと同じ変換および評価の動作です。抽出された JSON 要素のいずれかが一致する場合、そのウェブリクエストはルールに一致します。 # で転送された IP アドレスを使用する AWS WAF このセクションは、ウェブリクエストの IP アドレスを使用するルールステートメントに適用されます。デフォルトでは、はウェブリクエストオリジンの IP アドレス AWS WAF を使用します。ただし、ウェブリクエストが 1 つ以上のプロキシまたはロードバランサーを通過する場合、ウェブリクエストの発信元には、クライアントの発信アドレスではなく、最後のプロキシのアドレスが含まれます。この場合、通常、発信元のクライアントアドレスは別の HTTP ヘッダーに転送されます。このヘッダーは通常 `X-Forwarded-For` (XFF) ですが、別のヘッダーにすることもできます。 **IP アドレスを使用するルールステートメント** IP アドレスを使用するルールステートメントは次のとおりです。 + [IP セット一致](waf-rule-statement-type-ipset-match.md) - IP セットで定義されているアドレスと一致する IP アドレスを検査します。 + [地理的一致](waf-rule-statement-type-geo-match.md) - IP アドレスを使用して発信元の国と地域を特定し、それを国のリストと照合します。 + [ASN 一致](waf-rule-statement-type-asn-match.md) - IP アドレスを使用して AS 番号 (ASN) を判別し、ASN のリストに対して ASN を照合します。 + [レートベースのルールステートメントの使用](waf-rule-statement-type-rate-based.md) - IP アドレスでリクエストを集約して、個々の IP アドレスがリクエストを過度に高いレートで送信しないようにできます。IP アドレスの集約は、単独で使用することも、他の集約キーと組み合わせて使用することもできます。ウェブリクエストのオリジンを使用する代わりに、 `X-Forwarded-For` ヘッダーまたは別の HTTP ヘッダーのいずれかから、これらのルールステートメントに転送された IP アドレスを使用する AWS WAF ようにに指示できます。仕様を指定する方法の詳細については、個別のルールステートメントタイプのガイダンスを参照してください。 **注記** ヘッダーがない場合、はそのヘッダーを「一致なし」として使用するステートメント AWS WAF を評価します。NOT ステートメントを「一致なし」の結果で使用すると、は評価を「一致 AWS WAF 」に変換します。ヘッダーが見つからない場合、フォールバック動作はトリガーされません。無効なヘッダー値のみがトリガーされます。 **フォールバック動作** 転送された IP アドレスを使用する場合、リクエストに指定された位置に有効な IP アドレスがない場合 AWS WAF にがウェブリクエストに割り当てる一致ステータスを指定します。 + **MATCH** - ウェブリクエストをルールステートメントに一致するものとして扱います。はルールアクションをリクエスト AWS WAF に適用します。 + **一致なし** - ウェブリクエストをルールステートメントと一致しないものとして処理します。 **AWS WAF Bot Control で使用される IP アドレス** Bot Control マネージドルールグループは、IP アドレスを使用してボットを検証します AWS WAF。Bot Control を使用し、プロキシまたはロードバランサーを介してルーティングするボットを検証した場合は、カスタムルールを使用して明示的に許可する必要があります。例えば、転送された IP アドレスを使用して検証済みボットを検出および許可するカスタム IP セット一致ルールを設定できます。ルールを使用して、さまざまな方法でボット管理をカスタマイズできます。説明と例については、「[AWS WAF ボットコントロール](waf-bot-control.md)」を参照してください。 **転送された IP アドレスの使用に関する一般的な考慮事項** 転送された IP アドレスを使用する前に、次の一般的な注意事項に留意してください。 + ヘッダーは途中でプロキシによって変更でき、プロキシはヘッダーをさまざまな方法で処理することがあります。 + 攻撃者は、 AWS WAF 検査をバイパスしようとしてヘッダーの内容を変更する可能性があります。 + ヘッダー内の IP アドレスは、形式が正しくないか、無効である可能性があります。 + 指定したヘッダーは、リクエストにまったく存在しない可能性があります。 **で転送された IP アドレスを使用する際の考慮事項 AWS WAF** 次のリストでは、転送された IP アドレスをで使用するための要件と注意点について説明します AWS WAF。 + 単一のルールでは、転送された IP アドレス用に 1 つのヘッダーを指定できます。ヘッダーの仕様では、大文字と小文字は区別されません。 + レートベースのルールステートメントでは、ネストされたスコープステートメントは、転送された IP 設定を継承しません。転送された IP アドレスを使用する各ステートメントの設定を指定します。 + 地理的一致、ASN 一致、レートベースのルールの場合、はヘッダーの最初のアドレス AWS WAF を使用します。たとえば、ヘッダーにが含まれている場合、は `10.1.1.1, 127.0.0.0, 10.10.10.10` AWS WAF を使用します。 `10.1.1.1` + IP セットの一致では、ヘッダーの最初のアドレス、最後のアドレス、または任意のアドレスのいずれと照合するかを指定します。指定した場合、はヘッダー内のすべてのアドレスに一致がないか、最大 10 個のアドレス AWS WAF を検査します。ヘッダーに 10 個を超えるアドレスが含まれている場合、は最後の 10 個 AWS WAF を検査します。 + 複数のアドレスを含むヘッダーでは、アドレスの間にカンマ区切り文字を使用する必要があります。リクエストでカンマ以外の区切り文字が使用されている場合、 AWS WAF はヘッダーの IP アドレスの形式が正しくないとみなします。 + ヘッダー内の IP アドレスが不正な形式であるか、または無効である場合、 AWS WAF は、転送された IP 設定で指定したフォールバック動作に従って、ウェブリクエストをルールに一致するか一致しないかを指定します。 + 指定したヘッダーがリクエストに存在しない場合、 AWS WAF はリクエストにルールをまったく適用しません。つまり、 AWS WAF はルールアクションを適用せず、フォールバック動作も適用しません。 + IP アドレス用に転送された IP ヘッダーを使用するルールステートメントでは、ウェブリクエストの発信元によって報告された IP アドレスは使用されません。 **で転送された IP アドレスを使用するためのベストプラクティス AWS WAF** 転送された IP アドレスを使用する場合は、次のベストプラクティスを使用します。 + 転送された IP 設定を有効にする前に、リクエストヘッダーの可能な状態をすべて慎重に検討してください。目的の動作を実現するには、複数のルールを使用する必要がある場合があります。 + 複数の転送された IP ヘッダーを検査したり、ウェブリクエストの発信元と転送された IP ヘッダーを検査したりするには、IP アドレスのソースごとに 1 つのルールを使用します。 + 無効なヘッダーを持つウェブリクエストをブロックするには、ブロックするようにルールアクションを設定し、転送された IP 設定のフォールバック動作を一致するように設定します。 **転送された IP アドレスの JSON の例** 次の地理一致ステートメントは、発信元の国が `US` である IP が `X-Forwarded-For` ヘッダーに含まれている場合にのみ一致します。 ``` { "Name": "XFFTestGeo", "Priority": 0, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "XFFTestGeo" }, "Statement": { "GeoMatchStatement": { "CountryCodes": [ "US" ], "ForwardedIPConfig": { "HeaderName": "x-forwarded-for", "FallbackBehavior": "MATCH" } } } } ``` 次のレートベースのルールは、`X-Forwarded-For` ヘッダーの最初の IP に基づいてリクエストを集約します。ルールは、ネストされた地理一致ステートメントに一致するリクエストのみをカウントし、地理一致ステートメントに一致するリクエストのみをブロックします。ネストされた地理一致ステートメントは、`X-Forwarded-For` ヘッダーを使用して、IP アドレスが `US` の発信元の国を示しているかどうかも判断します。示している場合、またはヘッダーが存在していても形式が間違っている場合、地理一致ステートメントは一致を返します。 ``` { "Name": "XFFTestRateGeo", "Priority": 0, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "XFFTestRateGeo" }, "Statement": { "RateBasedStatement": { "Limit": "100", "AggregateKeyType": "FORWARDED_IP", "ScopeDownStatement": { "GeoMatchStatement": { "CountryCodes": [ "US" ], "ForwardedIPConfig": { "HeaderName": "x-forwarded-for", "FallbackBehavior": "MATCH" } } }, "ForwardedIPConfig": { "HeaderName": "x-forwarded-for", "FallbackBehavior": "MATCH" } } } } ``` # での HTTP/2 擬似ヘッダーの検査 AWS WAF このセクションでは、 AWS WAF を使用して HTTP/2 擬似ヘッダーを検査する方法について説明します。 HTTP/2 トラフィックをサポートする保護された AWS リソースは、検査 AWS WAF のために HTTP/2 擬似ヘッダーをに転送しませんが、 AWS WAF 検査するウェブリクエストコンポーネントに擬似ヘッダーのコンテンツを提供します。を使用して AWS WAF 、次の表に示す擬似ヘッダーのみを検査できます。 **ウェブリクエストコンポーネントにマップされた HTTP/2 疑似ヘッダーの内容** | HTTP/2 擬似ヘッダー | 検査するウェブリクエストコンポーネント | ドキュメント | | --- | --- | --- | | `:method` | HTTP メソッド | [HTTP メソッド](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-http-method) | | `:authority` | `Host` ヘッダー | [単一ヘッダー](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-single-header) [すべてのヘッダー](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-headers) | | `:path` URI パス | URI パス | [URI パス](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-uri-path) | | `:path` クエリ | クエリ文字列 | [クエリ文字列](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-query-string) [Single query parameter (単一クエリパラメータ)](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-single-query-param) [All query parameters (すべてのクエリパラメータ)](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-all-query-params) | # でのテキスト変換の使用 AWS WAF このセクションでは、リクエストを検査する前にが適用 AWS WAF する変換を提供する方法について説明します。パターンを探したり制約を設定したりするステートメントでは、リクエストを検査する前にが適用 AWS WAF する変換を指定できます。変換では、 AWS WAFをバイパスするために攻撃者が使用する異常なフォーマットの一部を削除するために、ウェブリクエストが再フォーマットされます。これを JSON 本文リクエストコンポーネントの選択で使用する場合、 AWS WAF は JSON から検査する要素を解析および抽出した後、変換を適用します。詳細については、「[JSON 本文](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-json-body)」を参照してください。複数の変換が指定された場合、 AWS WAF は変換の適用順序も設定します。 **WCU** - テキスト変換ごとには 10 個の WCU。 AWS WAF コンソールと API のドキュメントには、以下の場所におけるこれらの設定に関するガイダンスも記載されています。 + コンソールの**ルールビルダー** - **[Text transformation]** (テキスト変換)。このオプションは、リクエストコンポーネントの使用時に選択できます。 + **API ステートメントのコンテンツ** – `TextTransformations`テキスト変換のオプション各変換リストには、コンソールと API の仕様が表示され、説明が続きます。 Base64 decode – `BASE64_DECODE` AWS WAF は Base64-encodedされた文字列をデコードします。 Base64 decode extension – `BASE64_DECODE_EXT` AWS WAF は Base64-encodedされた文字列をデコードしますが、無効な文字を無視する寛容な実装を使用します。 Command line – `CMD_LINE` このオプションは、攻撃者がオペレーティングシステムのコマンドラインコマンドを挿入し、異常なフォーマットを使用して、コマンドの一部またはすべてを偽装する状況を緩和します。このオプションを使用して、次の変換を実行します。 + 次の文字を削除します: `\ " ' ^` + 次の文字の前にあるスペースを削除します: `/ (` + 次の文字をスペースに置き換えます: `, ;` + 複数のスペースを 1 つのスペースに置き換えます。 + 大文字 `A-Z` を小文字 `a-z` に変換します。 Compress whitespace – `COMPRESS_WHITE_SPACE` AWS WAF は、複数のスペースを 1 つのスペースに置き換え、次の文字をスペース文字 (ASCII 32) に置き換えることで、空白を圧縮します。 + フォームフィード (ASCII 12) + タブ (ASCII 9) + 改行 (ASCII 10) + キャリッジリターン (ASCII 13) + 垂直タブ (ASCII 11) + 改行なしスペース (ASCII 160) CSS decode – `CSS_DECODE` AWS WAF は、CSS 2.x エスケープルールを使用してエンコードされた文字をデコードします`syndata.html#characters`。この関数は、デコード処理で最大 2 バイトを使用するため、通常はエンコードされない CSS エンコーディングを使用してエンコードされた ASCII 文字を発見するのに役立ちます。また、バックスラッシュと 16 進数以外の文字の組み合わせである回避対策にも役立ちます。たとえば、`javascript` の `ja\vascript` を設定します。 Escape sequences decode – `ESCAPE_SEQ_DECODE` AWS WAF は、次の ANSI C エスケープシーケンスをデコードします: `\a`、`\b`、、`\f`、`\n``\r`、`\t`、`\v`、、`\\``\?`、`\xHH`、 (16 進数)`\"`、 `\0OOO` (8 `\'`進数）。有効でないエンコーディングは出力に残ります。 Hex decode – `HEX_DECODE` AWS WAF は 16 進数の文字の文字列をバイナリにデコードします。 HTML entity decode – `HTML_ENTITY_DECODE` AWS WAF は、16 進数形式`&#xhhhh;`または 10 進数形式で表される文字を対応する文字`&#nnnn;`に置き換えます。 AWS WAF は、次の HTML エンコード文字をエンコードされていない文字に置き換えます。このリストでは小文字の HTML エンコーディングを使用しますが、処理では大文字と小文字が区別されません。例えば、`&QuOt;` と `"` は同じように扱われます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/waf-rule-statement-transformation.html) JS decode – `JS_DECODE` AWS WAF は JavaScript エスケープシーケンスをデコードします。`\uHHHH` コードが `FF01-FF5E` の全角 ASCII コード範囲内にある場合、高位バイトを使用して下位バイトが検出され、調整されます。そうでない場合は、下位バイトのみが使用され、上位バイトはゼロになり、情報が失われる可能性があります。 Lowercase – `LOWERCASE` AWS WAF は大文字 (A～Z) を小文字 (a～z) に変換します。 MD5 – `MD5` AWS WAF は、入力内のデータから MD5 ハッシュを計算します。計算されたハッシュは生のバイナリ形式です。 None – `NONE` AWS WAF は、テキスト変換なしで、受信したウェブリクエストを検査します。 Normalize path – `NORMALIZE_PATH` AWS WAF は、入力の先頭にない複数のスラッシュ、ディレクトリの自己参照、およびディレクトリのバックリファレンスを削除することで、入力文字列を正規化します。 Normalize path Windows – `NORMALIZE_PATH_WIN` AWS WAF はバックスラッシュ文字をスラッシュに変換し、`NORMALIZE_PATH`変換を使用して結果の文字列を処理します。 Remove nulls – `REMOVE_NULLS` AWS WAF は入力からすべての`NULL`バイトを削除します。 Replace comments – `REPLACE_COMMENTS` AWS WAF は、C 形式のコメント (/\$1 ... \$1/) の各出現を 1 つのスペースに置き換えます。コメントが複数連続しているときは、圧縮しません。コメントの終端がないときもスペース (ASCII 0x20) に置き換えられます。コメントの終端 (\$1/) のみがあるときは変更されません。 Replace nulls – `REPLACE_NULLS` AWS WAF は、入力の各バイトをスペース文字 (ASCII `NULL` 0x20) に置き換えます。 SQL hex decode – `SQL_HEX_DECODE` AWS WAF は SQL 16 進数のデータをデコードします。たとえば、は (`0x414243`) を () に AWS WAF デコードします`ABC`。 URL decode – `URL_DECODE` AWS WAF は URL エンコードされた値をデコードします。 URL decode Unicode – `URL_DECODE_UNI` `URL_DECODE` と同様ですが、Microsoft 固有の `%u` エンコーディングをサポートしています。コードが `FF01-FF5E` の全角 ASCII コード範囲内にある場合、高位バイトを使用して下位バイトが検出され、調整されます。それ以外の場合は、下位バイトのみが使用され、高位バイトはゼロになります。 UTF8 to Unicode – `UTF8_TO_UNICODE` AWS WAF は、すべての UTF-8 文字シーケンスを Unicode に変換します。これは、入力を正規化し、非英語の言語における誤検知（偽陽性や偽陰性）を最小限に抑えるのに役立ちます。 # でのスコープダウンステートメントの使用 AWS WAF このセクションでは、スコープダウンステートメントとその仕組みについて説明します。スコープダウンステートメントは、マネージドルールグループステートメントまたはレートベースのステートメント内に追加できるネスト可能なルールステートメントで、包含ルールが評価するリクエストのセットを絞り込むことができます。包含ルールは、スコープダウンステートメントに最初に一致するリクエストのみを評価します。 + **マネージドルールグループステートメント** – マネージドルールグループステートメントにスコープダウンステートメントを追加すると、はスコープダウンステートメントと一致しないリクエストをルールグループと一致しないものとして AWS WAF 評価します。スコープダウンステートメントに一致するリクエストのみがルールグループに対して評価されます。評価されたリクエスト数に基づいて料金が発生するマネージドルールグループでは、スコープダウンステートメントはコストを抑えるのに役立ちます。マネージドルールグループステートメントの詳細については、「[でのマネージドルールグループステートメントの使用 AWS WAF](waf-rule-statement-type-managed-rule-group.md)」を参照してください。 + **レートベースのルールステートメント** – スコープダウンステートメントのレートを含まないレートベースのルールステートメントは、評価するすべてのリクエストのレートを制限します。特定のカテゴリのリクエストのレートのみを制御する場合は、レートベースのルールにスコープダウンステートメントを追加します。例えば、特定の地理的エリアから送信されたリクエストのレートだけを追跡および制御するには、地理的照合ステートメントでその地理的エリアを指定することで、スコープダウンステートメントとしてレートベースのルールに追加できます。レートベースのルールステートメントの詳細については、「[でのレートベースのルールステートメントの使用 AWS WAF](waf-rule-statement-type-rate-based.md)」を参照してください。スコープダウンステートメントでは、任意のネスト可能なルールを使用できます。利用可能なステートメントについては、「[での一致ルールステートメントの使用 AWS WAF](waf-rule-statements-match.md)」および「[での論理ルールステートメントの使用 AWS WAF](waf-rule-statements-logical.md)」を参照してください。スコープダウンステートメントの WCU は、その中で定義するルールステートメントに必要な WCU です。スコープダウンステートメントの使用に追加コストは発生しませんスコープダウンステートメントは、通常のルールでステートメントを使用する場合と同じ方法で設定できます。例えば、検査対象のウェブリクエストコンポーネントにテキスト変換を適用したり、IP アドレスとして使用するために転送された IP アドレスを指定したりできます。これらの設定はスコープダウンステートメントにのみ適用され、包含マネージドルールグループやレートベースのルールステートメントには継承されません。例えば、スコープダウンステートメントのクエリ文字列にテキスト変換を適用すると、スコープダウンステートメントは変換を適用後、クエリ文字列を検査します。リクエストがスコープダウンステートメントの基準に一致する場合は、 AWS WAF スコープダウンステートメントの変換を行わずに、元の状態でウェブリクエストを包含ルールに渡します。スコープダウンステートメントを含むルールは、独自のテキスト変換を適用する場合がありますが、スコープダウンステートメントから継承されるものはありません。スコープダウンステートメントを使用して、包含ルールステートメントのリクエスト検査設定を指定することはできません。スコープダウンステートメントを、包含ルールステートメントのウェブリクエストプリプロセッサとして使用することはできません。スコープダウンステートメントの唯一の役割は、どのリクエストを包含ルールステートメントに渡して検査するかを決定することです。 # で再利用可能なエンティティを参照する AWS WAF このセクションでは、 AWS WAFでの再利用可能なエンティティの仕組みについて説明します。一部のルールでは、再利用可能なエンティティを使用し、ユーザー AWSまたは AWS Marketplace 販売者がウェブ ACLs の外部で管理します。再利用可能なエンティティが更新されると、 AWS WAF は更新をルールに伝達します。たとえば、保護パック (ウェブ ACL) で AWS マネージドルールルールグループを使用する場合、がルールグループ AWS を更新すると、はウェブ ACL に変更を AWS 伝播して動作を更新します。ルールで IP セットステートメントを使用する場合、セットを更新すると、はそれを参照するすべてのルールに変更 AWS WAF を伝達するため、これらのルールを使用する保護パック (ウェブ ACLs) は変更に合わせてup-to-date状態を維持します。ルールステートメントで使用できる再利用可能なエンティティを次に示します。 + **IP セット** - 独自の IP セットを作成および管理します。コンソールでは、ナビゲーションペインからこれらにアクセスできます。IP セットの管理については、「[の IP セットと正規表現パターンセット AWS WAF](waf-referenced-set-managing.md)」を参照してください。 + **正規表現一致セット** - 独自の正規表現一致セットを作成および管理します。コンソールでは、ナビゲーションペインからこれらにアクセスできます。正規表現パターンセットの管理については、「[の IP セットと正規表現パターンセット AWS WAF](waf-referenced-set-managing.md)」を参照してください。 + **AWS マネージドルールルールグループ** – これらのルールグループ AWS を管理します。コンソールでは、マネージドルールグループを保護パック (ウェブ ACL) に追加する際にこれらを使用できます。これらの詳細については、「[AWS マネージドルールのルールグループリスト](aws-managed-rule-groups-list.md)」を参照してください。 + **AWS Marketplace マネージドルールグループ** – AWS Marketplace 販売者はこれらのルールグループを管理し、それらをサブスクライブして使用できます。サブスクリプションを管理するには、コンソールのナビゲーションペインで [**AWS Marketplace**] を選択します。 AWS Marketplace マネージドルールグループは、マネージドルールグループを保護パック (ウェブ ACL) に追加すると一覧表示されます。まだサブスクライブしていないルールグループについては、そのページ AWS Marketplace にもへのリンクがあります。 AWS Marketplace 販売者マネージドルールグループの詳細については、「」を参照してください[AWS Marketplace ルールグループ](marketplace-rule-groups.md)。 + **独自のルールグループ** - マネージドルールグループでは利用できない動作が必要な場合は通常、独自のルールグループを管理します。コンソールでは、ナビゲーションペインからこれらにアクセスできます。詳細については、「[独自のルールグループの管理](waf-user-created-rule-groups.md)」を参照してください。 **参照先のセットまたはルールグループの削除** 参照されるエンティティを削除すると、 AWS WAF は、そのエンティティが保護パック (ウェブ ACL) で現在使用されているかどうかを確認します。が使用中である AWS WAF と判断した場合、警告が表示されます。 AWS WAF はほとんどの場合、エンティティが保護パック (ウェブ ACL) によって参照されているかどうかを判断できます。ただし、まれに判別できないことがあります。削除するエンティティが使用中でないことを確認する必要がある場合は、削除する前にウェブ ACL でエンティティを確認してください。 # での一致ルールステートメントの使用 AWS WAF このセクションでは、一致ステートメントとは何か、またその仕組みについて説明します。一致ステートメントは、ウェブリクエストまたはその送信元を、指定された基準と比較します。このタイプの多くのステートメントでは、はコンテンツのマッチングリクエストの特定のコンポーネント AWS WAF を比較します。一致ステートメントはネスト可能です。これらのステートメントはいずれも論理ルールステートメント内にネストできる他、スコープダウンステートメントで使用できます。倫理ルールステートメントの詳細については、「[での論理ルールステートメントの使用 AWS WAF](waf-rule-statements-logical.md)」を参照してください。スコープダウンステートメントの詳細については、「[でのスコープダウンステートメントの使用 AWS WAF](waf-rule-scope-down-statements.md)」を参照してください。この表では、ルールに追加できる標準の一致ステートメントについて説明し、それぞれの保護パック (ウェブ ACL) キャパシティーユニット (WCU) 使用量を計算するためのガイドラインを提供します。WCU の詳細については、「[のウェブ ACL キャパシティユニット (WCUs) AWS WAF](aws-waf-capacity-units.md)」を参照してください。 | 一致ステートメント | 説明 | WCU | | --- | --- | --- | | [地理的一致](waf-rule-statement-type-geo-match.md) | リクエストの送信元の国を検査し、その国および地域のラベルを適用します。 | 1 | | [ASN 一致](waf-rule-statement-type-asn-match.md) | リクエストを IP アドレスおよびアドレス範囲に関連付けられた ASN と照合します。 | 1 | | [IP セット一致](waf-rule-statement-type-ipset-match.md) | リクエストを一連の IP アドレスおよびアドレス範囲と照合します。 | ほとんどの場合 1。転送された IP アドレスを持つヘッダーを使用するようにステートメントを設定し、Any のヘッダー内の位置を指定すると、WCU が 4 増えます。 | | [ラベル一致ルールステートメント](waf-rule-statement-type-label-match.md) | 同じ保護パック (ウェブ ACL) 内の他のルールによって追加されたラベルのリクエストを検査します。 | 1 | | [正規表現一致ルールステートメント](waf-rule-statement-type-regex-match.md) | 正規表現パターンを指定されたリクエストコンポーネントと比較します。 | 3 (基本コストとして)。 **[All query parameters]** (すべてのクエリパラメータ) のリクエストコンポーネントを使用する場合、10 WCU を追加します。**[JSON body]** (JSON 本文) のリクエストコンポーネントを使用する場合、基本コストの WCU を倍増させます。適用する各**テキスト変換**について、10 WCU を追加します。 | | [正規表現パターンセット](waf-rule-statement-type-regex-pattern-set-match.md) | 正規表現パターンを指定されたリクエストコンポーネントと比較します。 | パターンセットあたり 25 (基本コストとして)。 **[All query parameters]** (すべてのクエリパラメータ) のリクエストコンポーネントを使用する場合、10 WCU を追加します。**[JSON body]** (JSON 本文) のリクエストコンポーネントを使用する場合、基本コストの WCU を倍増させます。適用する各**テキスト変換**について、10 WCU を追加します。 | | [サイズ制約](waf-rule-statement-type-size-constraint-match.md) | 指定されたリクエストコンポーネントに対してサイズ制約をチェックします。 | 1 (基本コストとして)。 **[All query parameters]** (すべてのクエリパラメータ) のリクエストコンポーネントを使用する場合、10 WCU を追加します。**[JSON body]** (JSON 本文) のリクエストコンポーネントを使用する場合、基本コストの WCU を倍増させます。適用する各**テキスト変換**について、10 WCU を追加します。 | | [SQLi 攻撃](waf-rule-statement-type-sqli-match.md) | 指定されたリクエストコンポーネント内の悪意のある SQL コードを検査します。 | 20 (基本コストとして)。**[All query parameters]** (すべてのクエリパラメータ) のリクエストコンポーネントを使用する場合、10 WCU を追加します。**[JSON body]** (JSON 本文) のリクエストコンポーネントを使用する場合、基本コストの WCU を倍増させます。適用する各**テキスト変換**について、10 WCU を追加します。 | | [文字列一致](waf-rule-statement-type-string-match.md) | 指定されたリクエストコンポーネントと文字列を比較します。 | 基本コストは、文字列の一致のタイプによって異なり、1 ～ 10 の範囲です。**[All query parameters]** (すべてのクエリパラメータ) のリクエストコンポーネントを使用する場合、10 WCU を追加します。**[JSON body]** (JSON 本文) のリクエストコンポーネントを使用する場合、基本コストの WCU を倍増させます。適用する各**テキスト変換**について、10 WCU を追加します。 | | [XSS スクリプティング攻撃](waf-rule-statement-type-xss-match.md) | 指定されたリクエストコンポーネントでのクロスサイトスクリプティング攻撃を検査します。 | 40 (基本コストとして)。**[All query parameters]** (すべてのクエリパラメータ) のリクエストコンポーネントを使用する場合、10 WCU を追加します。**[JSON body]** (JSON 本文) のリクエストコンポーネントを使用する場合、基本コストの WCU を倍増させます。適用する各**テキスト変換**について、10 WCU を追加します。 | # 地理的一致ルールステートメントこのセクションでは、地理的な一致ステートメントとは何か、またその仕組みについて説明します。地理的または地理照合ステートメントを使用して、発信元の国や地域に基づいてウェブリクエストを管理します。地理的照合ステートメントは、ウェブリクエストに発信国や発信地域を示すラベルを追加します。これらのラベルは、ステートメントの条件がリクエストと一致するかどうかに関係なく追加されます。また、地理的照合ステートメントは、リクエストの発信国に対する一致も実行します。 ## 地理的一致ステートメントの使用方法地理的一致ステートメントは、次のような国や地域のマッチングに使用できます。 + **国** — 地理的一致ルールを単独で使用し、発信国のみに基づいてリクエストを管理できます。ルールステートメントは国コードに対する一致を実行します。また、発信元のラベルに一致するラベル一致ルールが適用されている地域的一致ルールに従うこともできます。 **注記** 香港からのトラフィックをフィルタリングするには、地理一致ステートメントで ISO 3166-1 alpha-2 国コード `HK` を使用します。 + **地域** — 地理的一致ルールに続いてラベル一致ルールを使用し、発信地域に基づいてリクエストを管理します。地理的一致ルールだけを使用して地域コードとの一致を実行することはできません。ラベルマッチルールの使用方法については、「[ラベル一致ルールステートメント](waf-rule-statement-type-label-match.md)」および「[でのウェブリクエストのラベル付け AWS WAF](waf-labels.md)」を参照してください。 ## 地理的一致ステートメントのしくみ geo 一致ステートメントでは、は各ウェブリクエストを次のように AWS WAF 管理します。 1. **リクエストの国とリージョンコードを決定します**。IP アドレスに基づいてリクエストの国とリージョン AWS WAF を決定します。デフォルトでは、はウェブリクエストのオリジンの IP アドレス AWS WAF を使用します。ルールステートメント設定で転送された IP 設定を有効にする`X-Forwarded-For`ことで、などの代替リクエストヘッダーから IP アドレスを使用する AWS WAF ようにに指示できます。 AWS WAF は、MaxMind GeoIP データベースを使用してリクエストの場所を決定します。MaxMind は、国レベルでの非常に高精度なデータを報告しますが、精度は国や IP の種類などの要因によって異なります。MaxMind の詳細については、「[MaxMind IP Geolocation](https://support.maxmind.com/hc/en-us/sections/4407519834267-IP-Geolocation)」を参照してください。GeoIP データのいずれかが正しくないと思われる場合は、[MaxMind Correct GeoIP2 Data](https://support.maxmind.com/hc/en-us/articles/4408252036123-GeoIP-Correction) で Maxmind に修正リクエストを送信できます。 AWS WAF は、国際標準化機構 (ISO) 3166 規格の alpha-2 の国と地域のコードを使用します。コードは次の場所にあります。 + ISO ウェブサイトでは、「[ISO Online Browsing Platform (OBP)](https://www.iso.org/obp/ui#home)」(ISO オンラインブラウジングプラットフォーム (OBP)) で国コードを検索できます。 + ウィキペディアでは、国コードは「[ISO 3166-2](https://en.wikipedia.org/wiki/ISO_3166-2)」に一覧表示されています。国の地域コードは `https://en.wikipedia.org/wiki/ISO_3166-2:` の URL に一覧表示されています。たとえば、米国の地域は「[ISO 3166-2:US](https://en.wikipedia.org/wiki/ISO_3166-2:US)」にあり、ウクライナの地域は「[ISO 3166-2:UA](https://en.wikipedia.org/wiki/ISO_3166-2:UA)」にあります。 1. **リクエストに追加する国ラベルおよび地域ラベルを決定します** — ラベルは、地理一致ステートメントが発信元 IP 設定を使用するか、転送された IP 設定を使用するかを示します。 + **発信元 IP** 国ラベルは `awswaf:clientip:geo:country:` です。米国の例は `awswaf:clientip:geo:country:US` です。地域ラベルは `awswaf:clientip:geo:region:-` です。米国のオレゴン州の例は `awswaf:clientip:geo:region:US-OR` です。 + **転送された IP** 国ラベルは `awswaf:forwardedip:geo:country:` です。米国の例は `awswaf:forwardedip:geo:country:US` です。地域ラベルは `awswaf:forwardedip:geo:region:-` です。米国のオレゴン州の例は `awswaf:forwardedip:geo:region:US-OR` です。リクエストが指定した IP アドレスの国または地域コードがない場合、 AWS WAF はラベル内で値の代わりに `XX` を使用します。たとえば、次のラベルは国コードがないクライアント IP 用です。`awswaf:clientip:geo:country:XX` および次のラベルは、国が米国であるが地域コードがない転送先 IP 用です。`awswaf:forwardedip:geo:region:US-XX`。 1. **リクエストの国コードをルール基準に参照して評価** 地理一致ステートメントは、一致するものを見つけるかどうかにかかわらず、検査するすべてのリクエストに国と地域のラベルを追加します。 **注記** AWS WAF は、ルールのウェブリクエスト評価の最後にラベルを追加します。そのため、地理的一致ステートメントのラベルに対して使用するラベル一致は、地理的一致ステートメントを含むルールとは別のルールで定義する必要があります。地域値のみを調べる場合、Count アクションと単一の国コード一致で地域的一致ルールを記述し、その後に地域ラベルのラベル一致ルールを作成することができます。この方法でも、地域一致ルールを評価するには国コードを入力する必要があります。サイトへのトラフィック元になる可能性が非常に低い国を指定することで、ログ記録およびカウントメトリクスを減らすことができます。 ## CloudFront ディストリビューションおよび CloudFront 地域制限機能 CloudFront ディストリビューションでは、CloudFront の地域制限機能を使用する場合、ブロックされたリクエストは AWS WAFに転送されないことに注意してください。許可されたリクエストはに転送されます AWS WAF。地域と指定できるその他の基準に基づいてリクエストをブロックする場合は AWS WAF、 AWS WAF 地理的一致ステートメントを使用し、CloudFront の地理的制限機能を使用しないでください。 ## ルールステートメントの特性 **ネスト可能** - このステートメントタイプはネスト可能です。 **WCU** - 1 つの WCU。 **設定** – このステートメントは次の設定を使用します。 + **国コード** – 地理一致のために比較する国コードの配列。これらは、ISO 3166 国際規格の alpha-2 の国 ISO コード (たとえば、`["US","CN"]` など) を基準とした 2 文字の国コードである必要があります。 + **(オプション) 転送された IP 設定** – デフォルトでは、はウェブリクエストオリジンの IP アドレス AWS WAF を使用して、オリジンの国を決定します。または、 `X-Forwarded-For` などの HTTP ヘッダーで転送された IP を使用するようにルールを設定できます。は、ヘッダーの最初の IP アドレス AWS WAF を使用します。この設定では、ヘッダーに不正な形式の IP アドレスを持つウェブリクエストに適用するフォールバック動作も指定します。フォールバック動作は、リクエストの一致結果を、一致または不一致のいずれにするかを設定します。詳細については、「[転送された IP アドレスの使用](waf-rule-statement-forwarded-ip-address.md)」を参照してください。 ## このルールステートメントの場所 + コンソールの**ルールビルダー** - **[Request option]** (リクエストオプション) で **[Originates from a country in]** (次の国からの送信) を選択します。 + **API** – 「[GeoMatchStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_GeoMatchStatement.html)」 ## 例地域一致ステートメントを使用して、特定の国または地域からのリクエストを管理できます。たとえば、特定の国からのリクエストをブロックしても、それらの国に属する一連の IP アドレスからのリクエストを許可するには、Block に設定されたアクションと次のネストされたステートメント (次の疑似コードで表示) を含めたルール作成できます。 + AND ステートメント + ブロックする国をリストした地理一致ステートメント + NOT ステートメント + 許可する IP アドレスを指定する IP セットステートメントまたは、特定の国の一部地域をブロックしても、それらの国における他の地域からのリクエストを許可するには、まずアクションセットを持った地理一致リールを Count に定義できます。その後、追加された地理一致ラベルと照合し、必要に応じてリクエストを処理するラベルマッチルールを定義します。次の擬似コードは、このアプローチの例について説明しています。 1. 地理一致ステートメントはブロックする地域がある国をリストしますが、アクションを Count に設定された状態で実行します。これにより、マッチステータスに関係なくすべてのウェブリクエストにラベルが付けられ、対象国のカウントメトリクスも表示されます。 1. Block アクションを含む `AND` ステートメント + ブロックする国のラベルを指定するラベル一致ステートメント + `NOT` ステートメント + 許可する国の地域のラベルを指定するラベル一致ステートメント次の JSON リストは、前述の擬似コードで説明した 2 つのルールの実装を示しています。これらのルールは、オレゴン州とワシントン州からのトラフィックを除く米国からのトラフィックをすべてブロックします。地理一致ステートメントは、検査するすべてのリクエストに国と地域のラベルを追加します。ラベル一致ルールは地理一致ルールの後に実行されるため、地理一致ルールが追加したばかりの国や地域のラベルと照合できます。地理一致ステートメントは転送された IP アドレスを使用するため、ラベル一致は転送された IP ラベルも指定します。 ``` { "Name": "geoMatchForLabels", "Priority": 10, "Statement": { "GeoMatchStatement": { "CountryCodes": [ "US" ], "ForwardedIPConfig": { "HeaderName": "X-Forwarded-For", "FallbackBehavior": "MATCH" } } }, "Action": { "Count": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "geoMatchForLabels" } }, { "Name": "blockUSButNotOROrWA", "Priority": 11, "Statement": { "AndStatement": { "Statements": [ { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:forwardedip:geo:country:US" } }, { "NotStatement": { "Statement": { "OrStatement": { "Statements": [ { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:forwardedip:geo:region:US-OR" } }, { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:forwardedip:geo:region:US-WA" } } ] } } } } ] } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "blockUSButNotOROrWA" } } ``` 別の例として、地理一致とレートベースのルールを組み合わせて、特定の国または地域のユーザーのリソースに優先順位を付けることができます。ユーザーを区別するために使用する地理一致またはラベル一致のステートメントごとに、異なるレートベースのステートメントを作成します。優先させる国または地域のユーザーのレート制限をより高く設定し、他のユーザーのレート制限をより低く設定します。次の JSON リストは、米国からのトラフィック量を制限する地理一致ルールの次にレートベースのルールを示しています。このルールにより、オレゴン州からのトラフィックは、同国の他の地域からのトラフィックよりも高いレートで許可されます。 ``` { "Name": "geoMatchForLabels", "Priority": 190, "Statement": { "GeoMatchStatement": { "CountryCodes": [ "US" ] } }, "Action": { "Count": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "geoMatchForLabels" } }, { "Name": "rateLimitOregon", "Priority": 195, "Statement": { "RateBasedStatement": { "Limit": 3000, "AggregateKeyType": "IP", "ScopeDownStatement": { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:clientip:geo:region:US-OR" } } } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "rateLimitOregon" } }, { "Name": "rateLimitUSNotOR", "Priority": 200, "Statement": { "RateBasedStatement": { "Limit": 100, "AggregateKeyType": "IP", "ScopeDownStatement": { "AndStatement": { "Statements": [ { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:clientip:geo:country:US" } }, { "NotStatement": { "Statement": { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:clientip:geo:region:US-OR" } } } } ] } } } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "rateLimitUSNotOR" } } ``` # IP セット一致ルールステートメントこのセクションでは、IP セット一致ステートメントとは何か、またその仕組みについて説明します。 IP セット一致ステートメントは、一連の IP アドレスおよびアドレス範囲に対してウェブリクエストの IP アドレスを検査します。これを使用して、リクエストの送信元の IP アドレスに基づいてウェブリクエストを許可またはブロックします。デフォルトでは、 AWS WAF はウェブリクエストの発信元からの IP アドレスを使用しますが、代わりに `X-Forwarded-For` などの HTTP ヘッダーを使用するようにルールを設定できます。 AWS WAF は、を除くすべての IPv4 および IPv6 CIDR 範囲をサポートします`/0`。CIDR 表記の詳細については、Wikipedia の「[Classless Inter-Domain Routing](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing)」(クラスレスドメイン間ルーティング) を参照してください。IP セットには、チェック対象として最大 10,000 個の IP アドレスまたは IP アドレス範囲を保持できます。 **注記** 各 IP セット一致ルールは IP セットを参照します。このセットは、ルールとは無関係に作成し、維持します。複数のルールで 1 つの IP セットを使用できます。参照されるセットを更新すると、はそれを参照するすべてのルール AWS WAF を自動的に更新します。 IP セットの作成および管理については、「[での IP セットの作成と管理 AWS WAF](waf-ip-set-managing.md)」を参照してください。ルールグループまたは保護パック (ウェブ ACL) でルールを追加または更新する場合は、**[IP set]** (IP セット) オプションを選択し、使用する IP セットの名前を選択します。 ## ルールステートメントの特性 **ネスト可能** - このステートメントタイプはネスト可能です。 **WCU**- ほとんどの場合 1 WCU。転送された IP アドレスを使用するようにステートメントを設定し、ANY の位置を指定すると、WCU の使用量が 4 増えます。このステートメントには、次の設定を使用します。 + **IP セットの指定** - 使用する IP セットをリストから選択するか、新しい IP セットを作成します。 + **(オプション) 転送された IP 設定** – リクエストの発信元の代わりに使用する代替の転送された IP ヘッダー名。ヘッダーの最初のアドレス、最後のアドレス、または任意のアドレスを照合するかどうかを指定します。指定したヘッダーに不正な形式の IP アドレスを持つウェブリクエストに適用するフォールバック動作も指定します。フォールバック動作は、リクエストの一致結果を、一致または不一致のいずれにするかを設定します。詳細については、「[転送された IP アドレスの使用](waf-rule-statement-forwarded-ip-address.md)」を参照してください。 ## このルールステートメントの場所 **このルールステートメントの場所** + コンソールの**ルールビルダー** - **[Request option]** (リクエストオプション) で **[Originates from an IP address in]** (次の IP アドレスからの送信) を選択します。 + コンソールの **[Add my own rules and rule groups]** (独自のルールとルールグループの追加) ページ - **[IP set]** (IP セット) オプションを選択します。 + **API** – 「[IPSetReferenceStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_IPSetReferenceStatement.html)」 # AS 番号 (ASN) 一致ルールステートメントの ASN 一致ルールステートメント AWS WAF を使用すると、リクエストの IP アドレスに関連付けられた自律システム番号 (ASN) に基づいてウェブトラフィックを検査できます。ASN は、インターネットサービスプロバイダー、企業、大学、政府機関などの組織が管理する大規模なインターネットネットワークに割り当てられる一意の識別子です。ASN 一致ステートメントを使用すると、個々の IP アドレスを管理することなく、特定のネットワーク組織からのトラフィックを許可またはブロックできます。このアプローチでは、ASN は IP 範囲より変化の頻度が低くなるため、IP ベースのルールと比較して、より安定して効率的にアクセスを制御できます。 ASN マッチングは、既知の問題のあるネットワークからのトラフィックをブロックしたり、信頼できるパートナーネットワークからのアクセスのみを許可したりするなどのシナリオで特に役立ちます。ASN 一致ステートメントは、オプションの転送された IP 設定を使用してクライアント IP アドレスを柔軟に判断できるため、コンテンツ配信ネットワーク (CDN) やリバースプロキシを使用するネットワーク設定など、さまざまなネットワーク設定との互換性を確保します。 **注記** ASN マッチングは、標準の認証と認可のコントロールを補完しますが、置き換えるものではありません。アプリケーション内のすべてのリクエストの ID を検証するために、IAM などの認証および認可メカニズムを実装することをお勧めします。 ## ASN 一致ステートメントの仕組み AWS WAF は、IP アドレスに基づいてリクエストの ASN を決定します。デフォルトでは、はウェブリクエストのオリジンの IP アドレス AWS WAF を使用します。ルールステートメント設定で転送された IP 設定を有効にする`X-Forwarded-For`ことで、などの代替リクエストヘッダーから IP アドレスを使用する AWS WAF ようにを設定できます。 ASN 一致ステートメントは、リクエストの ASN をルールで指定された ASN のリストと比較します。ASN がリスト内の ASN と一致する場合、ステートメントは true と評価され、関連付けられたルールアクションが適用されます。 ### マッピングされていない ASN の処理が有効な IP アドレスの ASN を決定 AWS WAF できない場合、ASN 0 が割り当てられます。これらのケースを明示的に処理するために、ルールに ASN 0 を含めることができます。 ### 無効な IP アドレスのフォールバック動作転送された IP アドレスを使用するように ASN 一致ステートメントを設定する場合、指定されたヘッダーに無効または欠落している IP アドレスを持つリクエストに対して、*一致* または *一致なし* のフォールバック動作を指定できます。 ## ルールステートメントの特性 **ネスト可能** - このステートメントタイプはネスト可能です。 **WCU** - 1 つの WCU このステートメントには、次の設定を使用します。 + **ASN リスト** – ASN 一致と比較する ASN 番号の配列。有効な値の範囲は 0～4294967295 です。ルールごとに最大 100 個の ASN を指定できます。 + **(オプション) 転送された IP 設定** – デフォルトでは、はウェブリクエストオリジンの IP アドレス AWS WAF を使用して ASN を決定します。または、代わりに `X-Forwarded-For` などの HTTP ヘッダーで転送された IP を使用するようにルールを設定することもできます。ヘッダーの最初のアドレス、最後のアドレス、または任意のアドレスを使用するかどうかを指定します。この設定では、ヘッダーに不正な形式の IP アドレスを持つウェブリクエストに適用するフォールバック動作も指定します。フォールバック動作は、リクエストの一致結果を、一致または不一致のいずれにするかを設定します。詳細については、「[転送した IP アドレスの使用](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-forwarded-ip-address.html)」を参照してください。 ## このルールステートメントの場所 + コンソールの **ルールビルダー** - **[リクエストオプション]** では、**[次の ASN からの送信]** を選択します。 + **API** – [AsnMatchStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_AsnMatchStatement.html) ## 例この例では、`X-Forwarded-For` ヘッダーから派生した 2 つの特定の ASN からのリクエストをブロックします。ヘッダーの IP アドレスの形式が正しくない場合、設定されたフォールバック動作は `NO_MATCH` です。 ``` { "Action": { "Block": {} }, "Name": "AsnMatchStatementRule", "Priority": 1, "Statement": { "AsnMatchStatement": { "AsnList": [64496, 64500] }, "ForwardedIPConfig": { "FallbackBehavior": "NO_MATCH", "HeaderName": "X-Forwarded-For" } }, "VisibilityConfig": { "CloudWatchMetricsEnabled": true, "MetricName": "AsnMatchRuleMetrics", "SampledRequestsEnabled": true } }, "VisibilityConfig": { "CloudWatchMetricsEnabled": true, "MetricName": "WebAclMetrics", "SampledRequestsEnabled": true } } ``` # ラベル一致ルールステートメントこのセクションでは、ラベル一致ステートメントとは何か、またその仕組みについて説明します。ラベル一致ステートメントは、ウェブリクエストにあるラベルを文字列指定に照らして検査します。検査用のルールで使用できるラベルは、同じ保護パック (ウェブ ACL) 評価内の他のルールによってウェブリクエストに既に追加されているラベルです。ラベルは保護パック (ウェブ ACL) 評価の外では保持されませんが、CloudWatch のラベルメトリクスにアクセスでき、 AWS WAF コンソールで任意の保護パック (ウェブ ACL) のラベル情報の概要を確認できます。詳細については、「[ラベルメトリクスとディメンション](waf-metrics.md#waf-metrics-label)」および「[AWS WAF 保護のモニタリングと調整](web-acl-testing-activities.md)」を参照してください。ログにはラベルも表示されます。詳細については、「[保護パック (ウェブ ACL) トラフィックのログフィールド](logging-fields.md)」を参照してください。 **注記** ラベル一致ステートメントは、保護パック (ウェブ ACL) で以前に評価されたルールのラベルのみを表示できます。が保護パック (ウェブ ACL) 内のルールとルールグループ AWS WAF を評価する方法については、「」を参照してください[ルールの優先度を設定する](web-acl-processing-order.md)。ラベルの追加と一致の詳細については、「[でのウェブリクエストのラベル付け AWS WAF](waf-labels.md)」を参照してください。 ## ルールステートメントの特性 **ネスト可能** - このステートメントタイプはネスト可能です。 **WCU** - 1 つの WCU このステートメントには、次の設定を使用します。 + **[Match scope]** (一致範囲) – これを **[Label]** (ラベル) に設定して、ラベル名と、ならびにオプションで、先行する名前空間およびプレフィックスと照合します。これを **[Namespace]** (名前空間) に設定して、名前空間の指定の一部または全部、およびオプションで、先行するプレフィックスと照合します。 + **[Key]** (キー) – 照合する文字列。名前空間一致の範囲を指定する場合、これは、名前空間と、オプションでプレフィックスのみを指定する必要があり、末尾にコロンを付けます。ラベル一致の範囲を指定する場合、これはラベル名を含む必要があり、オプションで前述の名前空間とプレフィックスを含めることができます。これらの設定の詳細については、「[AWS WAF ラベルに一致するルール](waf-rule-label-match.md)」および「[AWS WAF ラベル一致の例](waf-rule-label-match-examples.md)」を参照してください。 ## このルールステートメントの場所 + コンソールの**ルールビルダー** - **[Request option]** (リクエストオプション) で **[Has label]** (ラベルあり) を選択します。 + **API** – 「[LabelMatchStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_LabelMatchStatement.html)」 # 正規表現一致ルールステートメントこのセクションでは、正規表現一致ステートメントとは何か、またその仕組みについて説明します。正規表現一致ステートメントは、リクエストコンポーネントを単一の正規表現 (正規表現) と照合 AWS WAF するようにに指示します。リクエストコンポーネントが指定した正規表現と一致する場合、ウェブリクエストはステートメントと一致します。このステートメントタイプは、数理論理を使用して一致基準を組み合わせることを希望する状況において、[正規表現パターンセット一致ルールステートメント](waf-rule-statement-type-regex-pattern-set-match.md) に代わる優れた方法です。例えば、リクエストコンポーネントを一部の正規表現パターンと照合し、他の正規表現パターンと照合しないようにする場合は、[AND ルールステートメント](waf-rule-statement-type-and.md) と [NOT ルールステートメント](waf-rule-statement-type-not.md) を使用して正規表現一致ステートメントを組み合わせることができます。 AWS WAF は、いくつかの例外`libpcre`を除いて、PCRE ライブラリで使用されるパターン構文をサポートします。ライブラリは、「[PCRE - Perl Compatible Regular Expressions](http://www.pcre.org/)」で文書化されています。 AWS WAF サポートの詳細については、「」を参照してください[でサポートされている正規表現構文 AWS WAF](waf-regex-pattern-support.md)。 ## ルールステートメントの特性 **ネスト可能** - このステートメントタイプはネスト可能です。 **WCU**- 3 WCU (基本コストとして)。**[All query parameters]** (すべてのクエリパラメータ) のリクエストコンポーネントを使用する場合、10 WCU を追加します。**[JSON body]** (JSON 本文) のリクエストコンポーネントを使用する場合、基本コストの WCU を倍増させます。適用する各**テキスト変換**について、10 WCU を追加します。このステートメントタイプは、ウェブリクエストコンポーネントで動作し、次のリクエストコンポーネント設定が必要です。 + **[リクエストコンポーネント]** — ウェブリクエストの検査対象部分 (クエリ文字列や本文など)。 **警告** リクエストコンポーネントの**本文**、**JSON 本文**、**ヘッダー**、または **Cookie** を検査する場合は、で検査 AWS WAF できるコンテンツの量に関する制限についてお読みください[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)。ウェブリクエストコンポーネントの詳細については、「[でのルールステートメント設定の調整 AWS WAF](waf-rule-statement-fields.md)」を参照してください。 + **オプションのテキスト変換** – 検査する前にリクエストコンポーネントで AWS WAF 実行する変換。例えば、小文字に変換したり、空白を正規化したりできます。複数の変換を指定すると、はリストされた順序で変換 AWS WAF を処理します。詳細については、「[でのテキスト変換の使用 AWS WAF](waf-rule-statement-transformation.md)」を参照してください。 ## このルールステートメントの場所 + コンソールの**ルールビルダー** – **[Match type]** (一致タイプ) で、**Matches regular expression]** (正規表現に一致) を選択します。 + **API** – 「[RegexMatchStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_RegexMatchStatement.html)」 # 正規表現パターンセット一致ルールステートメントこのセクションでは、正規表現パターンセット一致ステートメントとは何か、またその仕組みについて説明します。正規表現パターンセット一致は、ウェブリクエストの指定した部分を、正規表現パターンセット内の指定した正規表現パターンに照らして検査します。 AWS WAF は、いくつかの例外`libpcre`を除いて、PCRE ライブラリで使用されるパターン構文をサポートします。ライブラリは、「[PCRE - Perl Compatible Regular Expressions](http://www.pcre.org/)」で文書化されています。 AWS WAF サポートの詳細については、「」を参照してください[でサポートされている正規表現構文 AWS WAF](waf-regex-pattern-support.md)。 **注記** 各正規表現パターンセット一致ルールは、正規表現パターンセットを参照します。このパターンセットは、ルールとは無関係に作成し、維持します。複数のルールで 1 つの正規表現パターンセットを使用できます。参照されるセットを更新すると、はそれを参照するすべてのルール AWS WAF を自動的に更新します。正規表現パターンセットの作成および管理については、「[での正規表現パターンセットの作成と管理 AWS WAF](waf-regex-pattern-set-managing.md)」を参照してください。正規表現パターンセット一致ステートメントは、選択したリクエストコンポーネント内のセット内のパターンを検索する AWS WAF ようにに指示します。リクエストコンポーネントがセット内のいずれかのパターンに一致する場合、ウェブリクエストはパターンセットルールステートメントと一致します。論理を使用して正規表現パターンの一致を組み合わせる場合、例えば、一部の正規表現と照合し、他の正規表現とは照合しない場合は、[正規表現一致ルールステートメント](waf-rule-statement-type-regex-match.md) を使用することを検討してください。 ## ルールステートメントの特性 **ネスト可能** - このステートメントタイプはネスト可能です。 **WCU** - 基本コストとして 25 WCU。**[All query parameters]** (すべてのクエリパラメータ) のリクエストコンポーネントを使用する場合、10 WCU を追加します。**[JSON body]** (JSON 本文) のリクエストコンポーネントを使用する場合、基本コストの WCU を倍増させます。適用する各**テキスト変換**について、10 WCU を追加します。このステートメントタイプは、ウェブリクエストコンポーネントで動作し、次のリクエストコンポーネント設定が必要です。 + **[リクエストコンポーネント]** — ウェブリクエストの検査対象部分 (クエリ文字列や本文など)。 **警告** リクエストコンポーネント**本文**、**JSON 本文**、**ヘッダー**、または **Cookie** を検査する場合は、で検査 AWS WAF できるコンテンツ量の制限についてお読みください[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)。ウェブリクエストコンポーネントの詳細については、「[でのルールステートメント設定の調整 AWS WAF](waf-rule-statement-fields.md)」を参照してください。 + **オプションのテキスト変換** – 検査する前にリクエストコンポーネントで AWS WAF 実行する変換。例えば、小文字に変換したり、空白を正規化したりできます。複数の変換を指定すると、はリストされた順序で変換 AWS WAF を処理します。詳細については、「[でのテキスト変換の使用 AWS WAF](waf-rule-statement-transformation.md)」を参照してください。このステートメントには、次の設定が必要です。 + 正規表現パターンセットの指定 - 使用する正規表現パターンセットをリストから選択するか、新しい IP セットを作成します。 ## このルールステートメントの場所 + コンソールの**ルールビルダー** - **[Match type]** (一致タイプ) で **[String match condition]** (文字列一致条件) > **[Matches pattern from regular expression set]** (正規表現セットのパターンに一致) を選択します。 + **API** – 「[RegexPatternSetReferenceStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_RegexPatternSetReferenceStatement.html)」 # サイズ制約ルールステートメントこのセクションでは、サイズ制約ステートメントとは何か，またその仕組みについて説明します。サイズ制約ステートメントは、ウェブリクエストコンポーネントに対してが AWS WAF 受け取るバイト数と、指定したバイト数を比較し、比較基準に従って一致させます。比較基準は、「より大きい (>)」や「より小さい (<)」などの演算子です。例えば、100 バイトを超えるサイズのクエリ文字列を含むリクエストの一致を実行できます。 URI パスを検査する場合、パス内の `/` は 1 文字としてカウントされます。例えば、URI パスの `/logo.jpg` は 9 文字の長さになります。 **注記** このステートメントはウェブリクエストコンポーネントのサイズのみを検査します。コンポーネントのコンテンツは検査されません。 ## ルールステートメントの特性 **ネスト可能** - このステートメントタイプはネスト可能です。 **WCU**- 1 WCU (基本コストとして)。**[All query parameters]** (すべてのクエリパラメータ) のリクエストコンポーネントを使用する場合、10 WCU を追加します。**[JSON body]** (JSON 本文) のリクエストコンポーネントを使用する場合、基本コストの WCU を倍増させます。適用する各**テキスト変換**について、10 WCU を追加します。このステートメントタイプは、ウェブリクエストコンポーネントで動作し、次のリクエストコンポーネント設定が必要です。 + **[リクエストコンポーネント]** — ウェブリクエストの検査対象部分 (クエリ文字列や本文など)。ウェブリクエストコンポーネントの詳細については、「[でのルールステートメント設定の調整 AWS WAF](waf-rule-statement-fields.md)」を参照してください。サイズ制約ステートメントは、何らかの変換が適用された後のコンポーネントのサイズのみを検査します。コンポーネントのコンテンツは検査されません。 + **オプションのテキスト変換** – サイズを検査する前にリクエストコンポーネントで AWS WAF 実行する変換。例えば、空白を圧縮したり、HTML エンティティをデコードしたりすることができます。複数の変換を指定すると、はリストされた順序で変換 AWS WAF を処理します。詳細については、「[でのテキスト変換の使用 AWS WAF](waf-rule-statement-transformation.md)」を参照してください。さらに、このステートメントには、次の設定が必要です。 + **Size match condition (サイズ一致条件)** - これは、提供するサイズと選択したリクエストコンポーネントを比較するために使用する数値比較演算子を示します。リストから演算子を選択します。 + **Size** (サイズ) - 比較で使用するサイズ設定 (バイト単位)。 ## このルールステートメントの場所 + コンソールの**ルールビルダー** - **[Match type]** (一致タイプ) の **[Size match condition]** (サイズ一致条件) で、使用する条件を選択します。 + **API** – 「[SizeConstraintStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_SizeConstraintStatement.html)」 # SQL インジェクション攻撃ルールステートメントこのセクションでは、SQL インジェクションルールステートメントとは何か、またその仕組みについて説明します。 SQL インジェクションルールステートメントは、悪意のある SQL コードを検査します。攻撃者は、データベースを変更したり、データベースからデータを抽出したりするために、悪意のある SQL コードをウェブリクエストに挿入します。 ## ルールステートメントの特性 **ネスト可能** - このステートメントタイプはネスト可能です。 **WCU** – 基本コストは、ルールステートメントの感度レベルの設定によって異なります。Low のコストは 20 で、High のコストは 30 です。 **[All query parameters]** (すべてのクエリパラメータ) のリクエストコンポーネントを使用する場合、10 WCU を追加します。**[JSON body]** (JSON 本文) のリクエストコンポーネントを使用する場合、基本コストの WCU を倍増させます。適用する各**テキスト変換**について、10 WCU を追加します。このステートメントタイプは、ウェブリクエストコンポーネントで動作し、次のリクエストコンポーネント設定が必要です。 + **[リクエストコンポーネント]** — ウェブリクエストの検査対象部分 (クエリ文字列や本文など)。 **警告** リクエストコンポーネントの**本文**、**JSON 本文**、**ヘッダー**、または **Cookie** を検査する場合は、で検査 AWS WAF できるコンテンツの量に関する制限についてお読みください[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)。ウェブリクエストコンポーネントの詳細については、「[でのルールステートメント設定の調整 AWS WAF](waf-rule-statement-fields.md)」を参照してください。 + **オプションのテキスト変換** – 検査する前にリクエストコンポーネントで AWS WAF 実行する変換。例えば、小文字に変換したり、空白を正規化したりできます。複数の変換を指定すると、はリストされた順序で変換 AWS WAF を処理します。詳細については、「[でのテキスト変換の使用 AWS WAF](waf-rule-statement-transformation.md)」を参照してください。さらに、このステートメントには、次の設定が必要です。 + **感度レベル** – この設定は、SQL インジェクション一致基準の感度を調整します。オプションは LOW と HIGH です。デフォルトの設定は LOW です。 HIGH 設定は、より多くの SQL インジェクション攻撃を検出するため、推奨される設定です。感度が高いため、この設定では、特にウェブリクエストに通常とは異なる文字列が一般的に含まれている場合に、より多くの誤検知が生成されます。保護パック (ウェブ ACL) のテストとチューニング中に、誤検知を軽減するためにさらに多くの作業が必要になる場合があります。詳細については、「[AWS WAF 保護のテストとチューニング](web-acl-testing.md)」を参照してください。設定が低いほど、SQL インジェクションの検出の厳格度も緩くなり、誤検知も少なくなります。LOW は、SQL インジェクション攻撃に対する他の保護を備えているリソースや、誤検知に対する許容度が低いリソースにとって、より適切な選択肢である可能性があります。 ## このルールステートメントの場所 + コンソールの**ルールビルダー** - **[Match type]** (一致タイプ) で **[Attack match condition]** (攻撃一致条件) > **[Contains SQL injection attacks]** (SQL インジェクション攻撃を含む) を選択します。 + **API** – 「[SqliMatchStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_SqliMatchStatement.html)」 # 文字列一致ルールステートメントこのセクションでは、文字列一致ステートメントとは何か、またその仕組みについて説明します。文字列一致ステートメントは、リクエストで AWS WAF 検索する文字列、検索するリクエスト内の場所、および方法を示します。例えば、リクエストに含まれるクエリ文字列の先頭にある特定の文字列、またはリクエストの `User-agent` ヘッダーと完全に一致する特定の文字列を検索できます。通常、文字列は印刷可能な ASCII 文字で構成されますが、16 進数 0x00 〜 0xFF (10 進数 0 〜 255) の任意の文字を使用できます。 ## ルールステートメントの特性 **ネスト可能** - このステートメントタイプはネスト可能です。 **WCU** – 基本コストは、使用する一致のタイプによって異なります。 + **次の文字列に完全一致** - 2 + **文字列で始まる** - 2 + **文字列で終わる** - 2 + **文字列を含む** - 10 + **単語を含む** – 10 **[All query parameters]** (すべてのクエリパラメータ) のリクエストコンポーネントを使用する場合、10 WCU を追加します。**[JSON body]** (JSON 本文) のリクエストコンポーネントを使用する場合、基本コストの WCU を倍増させます。適用する各**テキスト変換**について、10 WCU を追加します。このステートメントタイプは、ウェブリクエストコンポーネントで動作し、次のリクエストコンポーネント設定が必要です。 + **[リクエストコンポーネント]** — ウェブリクエストの検査対象部分 (クエリ文字列や本文など)。 **警告** リクエストコンポーネント**本文**、**JSON 本文**、**ヘッダー**、または **Cookie** を検査する場合は、で検査 AWS WAF できるコンテンツ量の制限についてお読みください[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)。ウェブリクエストコンポーネントの詳細については、「[でのルールステートメント設定の調整 AWS WAF](waf-rule-statement-fields.md)」を参照してください。 + **オプションのテキスト変換** – 検査する前にリクエストコンポーネントで AWS WAF 実行する変換。例えば、小文字に変換したり、空白を正規化したりできます。複数の変換を指定すると、はリストされた順序で変換 AWS WAF を処理します。詳細については、「[でのテキスト変換の使用 AWS WAF](waf-rule-statement-transformation.md)」を参照してください。さらに、このステートメントには、次の設定が必要です。 + **一致する文字列** – これは、指定されたリクエストコンポーネント AWS WAF と比較する文字列です。通常、文字列は印刷可能な ASCII 文字で構成されますが、16 進数 0x00 〜 0xFF (10 進数 0 〜 255) の任意の文字を使用できます。 + **文字列一致条件** – AWS WAF 実行する検索タイプを示します。 + **Exactly matches string** (次の文字列に完全一致) - リクエストコンポーネントの文字列と値が同一です。 + **Starts with string** (次の文字列で始まる) - この文字列は、リクエストコンポーネントの先頭に出現します。 + **Ends with string** (次の文字列で終わる) - この文字列は、リクエストコンポーネントの末尾に出現します。 + **Contains string** (次の文字列を含む) - この文字列は、リクエストコンポーネント内の任意の場所に出現します。 + **Contains word** (次の文字列を含む) - 指定した文字列がリクエストコンポーネントに出現する必要があります。このオプションの場合、指定する文字列には英数字またはアンダースコア (A〜Z、a〜z、0〜9、または\$1) のみを使用できます。リクエストが一致するには、次のいずれかに当てはまる必要があります。 + 文字列が、ヘッダーの値など、リクエストコンポーネントの値と正確に一致する。 + 文字列が、リクエストコンポーネントの先頭にあり、英数字または下線 (\$1) 以外の文字が続く (例: `BadBot;`)。 + 文字列が、リクエストコンポーネントの末尾にあり、英数字または下線 (\$1) 以外の文字が先行する (例: `;BadBot`)。 + 文字列が、リクエストコンポーネントの中央にあり、英数字または下線 (\$1) 以外の文字が前後にある (例: `-BadBot;`)。 ## このルールステートメントの場所 + コンソールの**ルールビルダー** - **[Match type]** (一致タイプ) で **[String match condition]** (文字列一致条件) を選択し、一致させる文字列を入力します。 + **API** – 「[ByteMatchStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_ByteMatchStatement.html)」 # クロスサイトスクリプティング攻撃ルールステートメントこのセクションでは、XSS (クロスサイトスクリプティング) 攻撃ステートメントとは何か、またその仕組みについて説明します。 XSS 攻撃ステートメントは、ウェブリクエストコンポーネント内の悪意のあるスクリプトを検査します。XSS 攻撃では、攻撃者は、悪意のあるクライアントサイトスクリプトを他の正当なウェブブラウザに挿入するための手段として、悪意のないウェブサイトの脆弱性を利用します。 ## ルールステートメントの特性 **ネスト可能** - このステートメントタイプはネスト可能です。 **WCU**- 40 WCU (基本コストとして)。**[All query parameters]** (すべてのクエリパラメータ) のリクエストコンポーネントを使用する場合、10 WCU を追加します。**[JSON body]** (JSON 本文) のリクエストコンポーネントを使用する場合、基本コストの WCU を倍増させます。適用する各**テキスト変換**について、10 WCU を追加します。このステートメントタイプは、ウェブリクエストコンポーネントで動作し、次のリクエストコンポーネント設定が必要です。 + **[リクエストコンポーネント]** — ウェブリクエストの検査対象部分 (クエリ文字列や本文など)。 **警告** リクエストコンポーネントの**本文**、**JSON 本文**、**ヘッダー**、または **Cookie** を検査する場合は、で検査 AWS WAF できるコンテンツの量に関する制限についてお読みください[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)。ウェブリクエストコンポーネントの詳細については、「[でのルールステートメント設定の調整 AWS WAF](waf-rule-statement-fields.md)」を参照してください。 + **オプションのテキスト変換** – 検査する前にリクエストコンポーネントで AWS WAF 実行する変換。例えば、小文字に変換したり、空白を正規化したりできます。複数の変換を指定すると、はリストされた順序で変換 AWS WAF を処理します。詳細については、「[でのテキスト変換の使用 AWS WAF](waf-rule-statement-transformation.md)」を参照してください。 ## このルールステートメントの場所 + コンソールの**ルールビルダー** - **[Match type]** (一致タイプ) で **[Attack match condition]** (攻撃一致条件) > **[Contains XSS injection attacks]** (SQL インジェクション攻撃を含む) を選択します。 + **API** – 「[XssMatchStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_XssMatchStatement.html)」 # での論理ルールステートメントの使用 AWS WAF このセクションでは、ロジックルールステートメントとは何か、またその仕組みについて説明します。論理ルールステートメントを使用して他のステートメントを組み合わせたり、結果を否定したりします。すべての論理ルールステートメントに、1 つ以上のネストされたステートメントが必要です。ルールステートメントの結果を論理的に結合または否定するには、ステートメントを論理ルールステートメントの下にネストします。論理ルールステートメントはネスト可能です。他の論理ルールステートメント内にネストして、スコープダウンステートメントで使用できます。スコープダウンステートメントの詳細については、「[でのスコープダウンステートメントの使用 AWS WAF](waf-rule-scope-down-statements.md)」を参照してください。 **注記** コンソールのビジュアルエディタは、1 レベルのルールステートメントのネストをサポートしており、多くのニーズに対応しています。より多くのレベルをネストするには、コンソールでルールの JSON 表現を編集するか、API を使用します。この表では、論理ルールステートメントについて説明し、それぞれの保護パック (ウェブ ACL) キャパシティーユニット (WCU) 使用量を計算するためのガイドラインを提供します。WCU の詳細については、「[のウェブ ACL キャパシティユニット (WCUs) AWS WAF](aws-waf-capacity-units.md)」を参照してください。 | 論理ステートメント | 説明 | WCU | | --- | --- | --- | | [AND のロジック](waf-rule-statement-type-and.md) | ネストされたステートメントを AND ロジックと組み合わせます。 | ネストされたステートメントに基づく | | [NOT のロジック](waf-rule-statement-type-not.md) | ネストされたステートメントの結果を否定します。 | ネストされたステートメントに基づく | | [OR のロジック](waf-rule-statement-type-or.md) | ネストされたステートメントを OR ロジックと組み合わせます。 | ネストされたステートメントに基づく | # AND ルールステートメント AND ルールステートメントは、ネストされたステートメントを論理 AND 演算と組み合わせるため、AND ステートメントが一致するには、ネストされたステートメントがすべて一致する必要があります。これには、1 つ以上のネストされたステートメントが必要です。 ## ルールステートメントの特性 **ネスト可能** - このステートメントタイプはネスト可能です。 **WCU** - ネストされたステートメントに応じて異なります。 ## このルールステートメントの場所 + コンソールの**ルールビルダー** - **[If a request]** (リクエストの状態) で **[matches all the statements (AND)]** (すべてのステートメントに一致する場合 (AND)) を選択してから、ネストされたステートメントに入力します。 + **API** – [AndStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_AndStatement.html) ## 例次のリストは、AND および NOT 論理ルールステートメントを使用して、SQL インジェクション攻撃ステートメントの一致から誤検知を排除する方法を示しています。この例では、誤検知につながるリクエストと一致する 1 バイトの一致ステートメントを記述できるとします。 AND ステートメントは、バイト一致ステートメントと一致せず、SQL インジェクション攻撃ステートメントと一致するリクエストと一致します。 ``` { "Name": "SQLiExcludeFalsePositives", "Priority": 0, "Statement": { "AndStatement": { "Statements": [ { "NotStatement": { "Statement": { "ByteMatchStatement": { "SearchString": "string identifying a false positive", "FieldToMatch": { "Body": { "OversizeHandling": "MATCH" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "CONTAINS" } } } }, { "SqliMatchStatement": { "FieldToMatch": { "Body": { "OversizeHandling": "MATCH" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } } ] } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "SQLiExcludeFalsePositives" } } ``` コンソールルールビジュアルエディタを使用して、非論理ステートメントまたは NOT ステートメントを OR または AND ステートメントの下にネストできます。NOT ステートメントのネストは、前の例に示されています。コンソールルールビジュアルエディタを使用すると、ほとんどのネスト可能なステートメントを、前の例に示したような論理ルールステートメントの下にネストできます。ビジュアルエディタを使用して OR または AND ステートメントをネストすることはできません。このタイプのネストを設定するには、JSON でルールステートメントを指定する必要があります。例えば、次の JSON ルールリストには、AND ステートメント内にネストされた OR ステートメントが含まれています。 ``` { "Name": "match_rule", "Priority": 0, "Statement": { "AndStatement": { "Statements": [ { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:bot-control:bot:category:monitoring" } }, { "NotStatement": { "Statement": { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:bot-control:bot:name:pingdom" } } } }, { "OrStatement": { "Statements": [ { "GeoMatchStatement": { "CountryCodes": [ "JM", "JP" ] } }, { "ByteMatchStatement": { "SearchString": "JCountryString", "FieldToMatch": { "Body": {} }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "CONTAINS" } } ] } } ] } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "match_rule" } } ``` # NOT ルールステートメント NOT ルールステートメントは、単一のネストされたステートメントの結果を論理的に否定するため、NOT ステートメントが一致するには、ネストされたステートメントが一致してはならず、その逆も同様です。これには、ネストされたステートメントが 1 つ必要です。例えば、特定の国を送信元としないリクエストをブロックする場合は、アクションをブロックに設定した NOT ステートメントを作成し、国を指定する地理的一致ステートメントをネストします。 ## ルールステートメントの特性 **ネスト可能** - このステートメントタイプはネスト可能です。 **WCU** - ネストされたステートメントに応じて異なります。 ## このルールステートメントの場所 + コンソールの**ルールビルダー** - **[If a request]** (リクエストの状態) で **[doesn't match the statement (NOT)]** (すべてのステートメントに一致しない場合 (NOT)) を選択してから、ネストされたステートメントに入力します。 + **API** – 「[NotStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_NotStatement.html)」 # OR ルールステートメント OR ルールステートメントは、ネストされたステートメントを OR ロジックと組み合わせるため、OR ステートメントが一致するには、ネストされたステートメントのいずれか 1 つが一致する必要があります。これには、1 つ以上のネストされたステートメントが必要です。例えば、特定の国から送信されたリクエストや特定のクエリ文字列を含むリクエストをブロックする場合は、OR ステートメントを作成し、その国の地理的照合ステートメントとクエリ文字列の文字列照合ステートメントをネストします。代わりに、特定の国から送信されて*いない*リクエストや特定のクエリ文字列を含むリクエストをブロックする場合は、前述の OR ステートメントを変更して、NOT ステートメント内の 1 レベル下に地理的照合ステートメントをネストします。コンソールでは 1 レベルのネストしかサポートされないため、このレベルのネストでは JSON 形式を使用する必要があります。 ## ルールステートメントの特性 **ネスト可能** - このステートメントタイプはネスト可能です。 **WCU** - ネストされたステートメントに応じて異なります。 ## このルールステートメントの場所 + コンソールの**ルールビルダー** - **[If a request]** (リクエストの状態) で **[matches at least one of the statements (OR)]** (1 つ以上のステートメントに一致する場合 (OR)) を選択してから、ネストされたステートメントに入力します。 + **API** – 「[OrStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_OrStatement.html)」 **例** 次のリストは、OR を使用して他の 2 つのステートメントを結合する方法を示しています。ネストされたステートメントのいずれかが一致する場合、OR ステートメントは一致します。 ``` { "Name": "neitherOfTwo", "Priority": 1, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "neitherOfTwo" }, "Statement": { "OrStatement": { "Statements": [ { "GeoMatchStatement": { "CountryCodes": [ "CA" ] } }, { "IPSetReferenceStatement": { "ARN": "arn:aws:wafv2:us-east-1:111111111111:regional/ipset/test-ip-set-22222222/33333333-4444-5555-6666-777777777777" } } ] } } } ``` コンソールルールビジュアルエディタを使用すると、ネスト可能なステートメントのほとんどを論理ルールステートメントの下にネストできますが、ビジュアルエディタを使用して OR または AND ステートメントをネストすることはできません。このタイプのネストを設定するには、JSON でルールステートメントを指定する必要があります。例えば、次の JSON ルールリストには、AND ステートメント内にネストされた OR ステートメントが含まれています。 ``` { "Name": "match_rule", "Priority": 0, "Statement": { "AndStatement": { "Statements": [ { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:bot-control:bot:category:monitoring" } }, { "NotStatement": { "Statement": { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:bot-control:bot:name:pingdom" } } } }, { "OrStatement": { "Statements": [ { "GeoMatchStatement": { "CountryCodes": [ "JM", "JP" ] } }, { "ByteMatchStatement": { "SearchString": "JCountryString", "FieldToMatch": { "Body": {} }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "CONTAINS" } } ] } } ] } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "match_rule" } } ``` # でのレートベースのルールステートメントの使用 AWS WAF このセクションでは、レートベースのルールステートメントとは何か、またその仕組みについて説明します。レートベースのルールでは、受信リクエストをカウントし、レートが速すぎる場合にはリクエストを制限します。このルールは、条件に従ってリクエストを集約し、ルールの評価ウインドウ、リクエスト制限とアクション設定に基づいて集約されたグループを記入およびレート制限します。 **注記** Bot Control AWS マネージドルールルールグループのターゲットを絞った保護レベルを使用して、ウェブリクエストをレート制限することもできます。マネージドルールグループの使用には追加料金が発生します。詳細については、「[レートベースのルールとターゲットを絞った Bot Control ルールにおけるレート制限のオプション](waf-rate-limiting-options.md)」を参照してください。 AWS WAF は、使用するレートベースのルールのインスタンスごとにウェブリクエストを個別に追跡および管理します。たとえば、2 つのウェブ ACLs で同じレートベースのルール設定を指定すると、2 つのルールステートメントはそれぞれレートベースのルールの個別のインスタンスを表し、それぞれが独自の追跡と管理を取得します AWS WAF。ルールグループ内でレートベースのルールを定義し、そのルールグループを複数の場所で使用する場合、各使用により、独自の追跡および管理を取得するレートベースのルールの個別のインスタンスが作成されます AWS WAF。 **ネスト不可** - このステートメントタイプを他のステートメント内にネストすることはできません。このタイプは、保護パック (ウェブ ACL) およびルールグループに直接含めることができます。 **スコープダウンステートメント** – このルールタイプは、オプションのスコープダウンステートメントを使用して、レートベースのステートメントが追跡するリクエストの範囲を絞り込むことができます。スコープダウンステートメントは、他のルール設定に応じて、オプションでも必須でもかまいません。詳細については、このセクションで説明します。スコープダウンステートメントの詳細については、[でのスコープダウンステートメントの使用 AWS WAF](waf-rule-scope-down-statements.md) を参照してください。 **WCU** - 2 個の WCU (基本コストとして)。指定するカスタム集約キーごとに、30 個の WCU を追加します。ルールでスコープダウンステートメントを使用する場合は、その分の WCU を計算して追加します。 **このルールステートメントの場所** + 保護パック (ウェブ ACL) のコンソールの**ルールビルダー** – **[Rule]** (ルール) の **[Type]** (タイプ) で、**[Rate-based rule]** (レートベースのルール) を選択します。 + **API** – 「[RateBasedStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_RateBasedStatement.html)」 **Topics** + [ # でのレートベースのルールの高レベル設定 AWS WAF ](waf-rule-statement-type-rate-based-high-level-settings.md) + [ # のレートベースのルールに関する注意事項 AWS WAF ](waf-rule-statement-type-rate-based-caveats.md) + [ # でのレートベースのルールの集計 AWS WAF ](waf-rule-statement-type-rate-based-aggregation-options.md) + [ # レートベースのルール集約インスタンスとカウント ](waf-rule-statement-type-rate-based-aggregation-instances.md) + [ # でのリクエストへのレート制限の適用 AWS WAF ](waf-rule-statement-type-rate-based-request-limiting.md) + [ # のレートベースのルールの例 AWS WAF ](waf-rule-statement-type-rate-based-examples.md) + [ # レートベースのルールによってレート制限されている IP アドレスの一覧表示 ](listing-managed-ips.md) # でのレートベースのルールの高レベル設定 AWS WAF レートベースのルールステートメントでは、次の概要レベル設定を使用します。 + **評価ウィンドウ** – 現在の時点から遡って、 AWS WAF がリクエスト数に含めるべき時間（秒単位）。たとえば、設定が 120 の場合、がレート AWS WAF をチェックすると、現在の時刻の直前の 2 分間のリクエストがカウントされます。有効な設定は、60 (1 分）、120 (2 分）、300 (5 分）、600 (10 分) で、300 (5 分) がデフォルトです。この設定では、レート AWS WAF をチェックする頻度ではなく、チェックするたびにレートがどの程度戻るかが決まります。 AWS WAF は、評価ウィンドウの設定とは無関係のタイミングでレートを頻繁にチェックします。 + **レート制限** – 指定された評価ウィンドウに対して追跡 AWS WAF する基準に一致するリクエストの最大数。許可される最小制限設定は 10 です。この制限を超えると、は条件に一致する追加のリクエストにルールアクション設定 AWS WAF を適用します。 AWS WAF は、設定した制限の近くにレート制限を適用しますが、は制限の完全一致を保証しません。詳細については、「[レートベースのルールの規制](waf-rule-statement-type-rate-based-caveats.md)」を参照してください。 + **リクエスト集約** – レートベースのルールがカウントおよびレート制限するウェブリクエストで使用する集約条件です。設定したレート制限は、各集約インスタンスに適用されます。詳細については、「[レートベースのルールの集計](waf-rule-statement-type-rate-based-aggregation-options.md)」および「[集約インスタンスおよびカウント](waf-rule-statement-type-rate-based-aggregation-instances.md)」を参照してください。 + **アクション** – ルールによってレート制限されているリクエストに対して実行するアクションです。Allow 以外のルールアクションを使用できます。これは通常どおりルールレベルで設定されますが、レートベースのルールに固有の制限と動作があります。ルールアクションの一般情報については、「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」を参照してください。レート制限の固有情報については、このセクションの [でのリクエストへのレート制限の適用 AWS WAF](waf-rule-statement-type-rate-based-request-limiting.md) を参照してください。 + **検査の範囲とレート制限** – スコープダウンステートメントを追加して、レートベースのステートメントが追跡およびレート制限するリクエストの範囲を絞り込むことができます。スコープダウンステートメントを指定すると、ルールはスコープダウンステートメントに一致するリクエストのみを集約、カウント、およびリスト制限します。リクエスト集約オプションの **[すべてをカウント]** を選択する場合は、スコープダウンステートメントが必要です。スコープダウンステートメントの詳細については、「[スコープダウンステートメントの使用](waf-rule-scope-down-statements.md)」を参照してください。 + **(オプション) 転送された IP 設定** – 単独で、またはカスタムキー設定の一部としてリクエスト集約で **[ヘッダーの IP アドレス]** を指定する場合にのみ使用されます。 AWS WAF は指定されたヘッダーの最初の IP アドレスを取得し、それを集約した値として使用します。この用途によく使用されるヘッダーは `X-Forwarded-For` ですが、任意のヘッダーを指定できます。詳細については、「[転送された IP アドレスの使用](waf-rule-statement-forwarded-ip-address.md)」を参照してください。 # のレートベースのルールに関する注意事項 AWS WAF このセクションでは、レートベースのルールを使用するための規制を一覧表示します。 AWS WAF レート制限は、高いリクエストレートを制御し、アプリケーションの可用性を可能な限り最も効率的かつ効果的な方法で保護するように設計されています。リクエストレートを正確に制限することを意図したものではありません。 + AWS WAF は、より最近のリクエストをより重視するアルゴリズムを使用して、現在のリクエストレートを推定します。このため、 AWS WAF は設定した制限の近くにレート制限を適用しますが、は正確な制限の一致を保証しません。 + がリクエストのレートを AWS WAF 見積もるたびに、は設定された評価ウィンドウ中に着信したリクエストの数を AWS WAF 振り返ります。このような要因や伝播の遅延などの要因により、 AWS WAF が検出してレート制限する前に、リクエストが最大数分間高すぎる可能性があります。同様に、リクエスト率が一定期間制限以下になると、 AWS WAF がその減少を検出してレート制限のアクションを停止するまで時間がかかることがあります。通常、この遅延は 30 秒未満です。 + 使用中のルールのレート制限設定を変更すると、その変更はルールのレート制限カウントをリセットします。これにより、ルールのレート制限アクティビティを最大 1 分間一時停止できます。レート制限設定は、評価ウィンドウ、レート制限、リクエスト集約設定、転送された IP 設定、検査範囲です。 # でのレートベースのルールの集計 AWS WAF このセクションでは、リクエストを集約するためのオプションについて説明します。デフォルトでは、レートベースのルールはリクエスト IP アドレスに基づき、リクエストを集約してレート制限します。他のさまざまな集約キーやキーの組み合わせを使用するようにルールを設定できます。例えば、転送された IP アドレス、HTTP メソッド、またはクエリ引数に基づいて集約できます。IP アドレスと HTTP メソッド、または 2 つの異なる Cookie の値など、集約キーの組み合わせを指定できます。 **注記** リクエストを評価したり、ルールによってレート制限したりするには、集約キーで指定するすべてのリクエストコンポーネントがウェブリクエストに含まれている必要があります。レートベースのルールは、次の集約オプションを使用して設定できます。 + **送信元 IP アドレス** – ウェブリクエストの発信元 IP アドレスのみを使用して集約します。送信元 IP アドレスには、発信元クライアントのアドレスが含まれていない場合があります。ウェブリクエストが 1 つ以上のプロキシまたはロードバランサーを経由する場合、これには最後のプロキシのアドレスが含まれます。 + **ヘッダーの IP アドレス** – HTTP ヘッダー内のクライアントアドレスのみを使用して集約します。これは転送された IP アドレスとも呼ばれます。この設定では、ヘッダーに不正な形式の IP アドレスを持つウェブリクエストに適用するフォールバック動作も指定します。フォールバック動作は、リクエストの一致結果を、一致または不一致のいずれにするかを設定します。不一致の場合、レートベースのルールは、リクエストをカウントまたはレート制限しません。一致の場合、レートベースのルールは、指定されたヘッダーに不正な形式の IP アドレスを持つ他のリクエストとともに、リクエストをグループ化します。このオプションでは、プロキシによって一貫性のないヘッダー処理が行われ、検査を回避するように変更される可能性があるため、注意が必要です。追加情報とベストプラクティスについては、「[で転送された IP アドレスを使用する AWS WAF](waf-rule-statement-forwarded-ip-address.md)」を参照してください。 + **ASN** – ソース IP アドレスに関連付けられた AS 番号 (ASN) を集約キーとして使用して集約します。これは、発信元クライアントのアドレスでは可能性があります。ウェブリクエストが 1 つ以上のプロキシまたはロードバランサーを経由する場合、これには最後のプロキシのアドレスが含まれます。が IP アドレスから ASN を取得 AWS WAF できない場合、ASN は ASN 0 としてカウントされます。マッピングされていない ASN にレート制限を適用しない場合は、ASN 0 のリクエストを除外するスコープダウンルールを作成できます。 + **ヘッダーの ASN** – HTTP ヘッダー内のクライアント IP アドレスに関連付けられた ASN を使用して集約します。これは転送された IP アドレスとも呼ばれます。この設定では、無効または不正な形式の IP アドレスを持つウェブリクエストに適用するフォールバック動作も指定します。フォールバック動作は、リクエストの一致結果を、一致または不一致のいずれにするかを設定します。転送された IP 設定でフォールバック動作が一致するように設定した場合、は無効な IP アドレスを一致する値として AWS WAF 扱います。これにより、 AWS WAF はレートベースのルールの複合キーの残りの部分の評価を継続できます。不一致の場合、レートベースのルールは、リクエストをカウントまたはレート制限しません。このオプションでは、プロキシによって一貫性のないヘッダー処理が行われ、検査を回避するように変更される可能性があるため、注意が必要です。追加情報とベストプラクティスについては、「[で転送された IP アドレスを使用する AWS WAF](waf-rule-statement-forwarded-ip-address.md)」を参照してください。 + **すべてをカウント** – ルールのスコープダウンステートメントに一致するすべてのリクエストをカウントおよびレート制限します。このオプションには、スコープダウンステートメントが必要です。これは通常、特定のラベルが付いた全リクエストや特定の地域からの全リクエストなど、特定のリクエストセットをレート制限するために使用されます。 + **カスタムキー** – 1 つ以上のカスタム集約キーを使用して集約します。いずれかの IP アドレスオプションを他の集約キーと組み合わせるには、それらをカスタムキーで定義します。カスタム集約キーは、「[でコンポーネントをリクエストする AWS WAF](waf-rule-statement-fields-list.md)」で説明されているウェブリクエストコンポーネントオプションのサブセットです。キーオプションは次のとおりです。特に明記されていない限り、オプションは複数回使用できます。例えば、2 つのヘッダーや 3 つのラベル名前空間などが使用可能です。 + **ラベル名前空間** – ラベル名前空間を集約キーとして使用します。指定されたラベル名前空間を持つ個別の完全修飾ラベル名はそれぞれ、集約インスタンスに影響します。カスタムキーとしてラベル名前空間を 1 つだけ使用する場合、各ラベル名は集約インスタンスを完全に定義します。レートベースのルールが使用するラベルは、保護パック (ウェブ ACL) であらかじめ評価されたルールによってリクエストに追加されたものに限ります。ラベル名前空間とラベル名の詳細については、「[でのラベル構文と命名要件 AWS WAF](waf-rule-label-requirements.md)」を参照してください。 + **ヘッダー** – 名前付きヘッダーを集約キーとして使用します。ヘッダー内の個別の値はそれぞれ、集約インスタンスに影響します。ヘッダーはオプションでテキスト変換を実行します。「[でのテキスト変換の使用 AWS WAF](waf-rule-statement-transformation.md)」を参照してください。 + **Cookie** – 名前付き Cookie を集約キーとして使用します。Cookie 内の個別の値はそれぞれ、集約インスタンスに影響します。 Cookie はオプションでテキスト変換を実行します。「[でのテキスト変換の使用 AWS WAF](waf-rule-statement-transformation.md)」を参照してください。 + **クエリ引数** – リクエスト内で 1 つのクエリ引数を集約キーとして使用します。名前付きクエリ引数の個別の値はそれぞれ、集約インスタンスに影響します。クエリ引数はオプションでテキスト変換を実行します。「[でのテキスト変換の使用 AWS WAF](waf-rule-statement-transformation.md)」を参照してください。 + **クエリ文字列** – リクエスト内のクエリ文字列全体を集約キーとして使用します。個別のクエリ文字列はそれぞれ、集約インスタンスに影響します。このキータイプは一度だけ使用できます。クエリ文字列はオプションでテキスト変換を実行します。「[でのテキスト変換の使用 AWS WAF](waf-rule-statement-transformation.md)」を参照してください。 + **URI パス** — リクエスト内の URI パスを集約キーとして使用します。個別の URI パスはそれぞれ、集約インスタンスに影響します。このキータイプは一度だけ使用できます。 URI パスはオプションでテキスト変換を実行します。「[でのテキスト変換の使用 AWS WAF](waf-rule-statement-transformation.md)」を参照してください。 + **JA3 フィンガープリント** – リクエストで JA3 フィンガープリントを集計キーとして使用します。個別の JA3 フィンガープリントはそれぞれ、集約インスタンスに影響します。このキータイプは一度だけ使用できます。 + **JA4 フィンガープリント** – リクエストで JA4 フィンガープリントを集計キーとして使用します。個別の JA4 フィンガープリントはそれぞれ、集約インスタンスに影響します。このキータイプは一度だけ使用できます。 + **HTTP メソッド** – リクエストの HTTP メソッドを集約キーとして使用します。個別の HTTP メソッドはそれぞれ、集約インスタンスに影響します。このキータイプは一度だけ使用できます。 + **IP アドレス** – ウェブリクエストの発信元 IP アドレスを他のキーと組み合わせて集約します。これには、発信元クライアントのアドレスが含まれていない可能性があります。ウェブリクエストが 1 つ以上のプロキシまたはロードバランサーを経由する場合、これには最後のプロキシのアドレスが含まれます。 + **ヘッダーの IP アドレス** – HTTP ヘッダー内のクライアントアドレスを他のキーと組み合わせて集約します。これは転送された IP アドレスとも呼ばれます。このオプションでは、プロキシによって一貫性のないヘッダー処理が行われ、検査を回避するように変更される可能性があるため、注意が必要です。追加情報とベストプラクティスについては、「[で転送された IP アドレスを使用する AWS WAF](waf-rule-statement-forwarded-ip-address.md)」を参照してください。 # レートベースのルール集約インスタンスとカウントこのセクションでは、レートベースのルールがウェブリクエストを評価する方法について説明します。レートベースのルールが集約条件を使用してウェブリクエストを評価する場合、指定された集約キーに対してルールが検出した一意の値セットはそれぞれ、一意の *集約インスタンス* を定義します。 + **複数キー** - 複数のカスタムキーを定義した場合、各キーの値は集約インスタンスの定義に影響します。値の一意の組み合わせはそれぞれ、集約インスタンスを定義します。 + **単一キー** - カスタムキーで単一キーを選択した場合、またはシングルトン IP アドレスの選択肢の中から単一キーを選択した場合、キーの一意の値はそれぞれ、集約インスタンスを定義します。 + **すべてをカウント - キーなし** - 集約オプションの **[すべてをカウント]** を選択した場合、ルールが評価するすべてのリクエストは、ルールの 1 つの集約インスタンスに属します。この選択には、スコープダウンステートメントが必要です。レートベースのルールは、識別された集約インスタンスごとにウェブリクエストを個別にカウントします。例えば、レートベースのルールが次の IP アドレスと HTTP メソッドの値を持つウェブリクエストを評価するとします。 + IP アドレス 10.1.1.1、HTTP メソッド POST + IP アドレス 10.1.1.1、HTTP メソッド GET + IP アドレス 127.0.0.0、HTTP メソッド POST + IP アドレス 10.1.1.1、HTTP メソッド GET このルールは、集約条件に従ってさまざまな集約インスタンスを作成します。 + 集約基準が IP アドレスのみの場合、個々の IP アドレスは集約インスタンスであり、はリクエストを個別に AWS WAF カウントします。この例の集約インスタンスおよびリクエストカウントは次のようになります。 + IP アドレス 10.1.1.1: カウント 3 + IP アドレス 127.0.0.0: カウント 1 + 集約条件が HTTP メソッドの場合、個々の HTTP メソッドが集約インスタンスになります。この例の集約インスタンスおよびリクエストカウントは次のようになります。 + HTTP メソッド POST: カウント 2 + HTTP メソッド GET: カウント 2 + 集約条件が IP アドレスと HTTP メソッドの場合、各 IP アドレスと各 HTTP メソッドは、複合的な集約インスタンスに影響します。この例の集約インスタンスおよびリクエストカウントは次のようになります。 + IP アドレス 10.1.1.1、HTTP メソッド POST: カウント 1 + IP アドレス 10.1.1.1、HTTP メソッド GET: カウント 2 + IP アドレス 127.0.0.0、HTTP メソッド POST: カウント 1 # でのリクエストへのレート制限の適用 AWS WAF このセクションでは、レートベースのルールでレート制限の動作の仕組みについて説明します。レートベースのルールのリクエストをレート制限するために AWS WAF が使用する条件は、 AWS WAF がルールのリクエストを集計するために使用する条件と同じです。ルールのスコープダウンステートメントを定義すると、はスコープダウンステートメントに一致するリクエスト AWS WAF のみを集計、カウント、レート制限します。レートベースのルールが特定のウェブリクエストにルールアクション設定を適用する一致条件は、次のとおりです。 + ウェブリクエストは、ルールのスコープダウンステートメントと一致している（定義されている場合）。 + ウェブリクエストは、現在リクエストカウントがルールの制限を超えている集約インスタンスに属している。 **がルールアクション AWS WAF を適用する方法** レートベースのルールがリクエストにレート制限を適用すると、ルールアクションが適用されます。アクション仕様でカスタム処理やラベル付けを定義している場合、ルールはそれらを適用します。このリクエスト処理は、一致ルールが一致したウェブリクエストにアクション設定を適用する方法と同じです。レートベースのルールは、レート制限が積極的に行われているリクエストにのみラベルを適用したり、他のアクションを実行したりします。 Allow 以外のルールアクションを使用できます。ルールアクションの一般情報については、「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」を参照してください。次のリストは、各アクションのレート制限の仕組みを示しています。 + **Block** – リクエストを AWS WAF ブロックし、定義したカスタムブロック動作を適用します。 + **Count** – リクエストを AWS WAF カウントし、定義したカスタムヘッダーまたはラベルを適用し、リクエストの保護パック (ウェブ ACL) の評価を続行します。このアクションはリクエストのレートを制限しません。制限を超えるリクエストのみを記入します。 + **CAPTCHA または Challenge** - AWS WAF はリクエストのトークンの状態に応じて、Count または Block のいずれかのようにリクエストを処理します。このアクションは、有効なトークンを持つリクエストのレートを制限しません。これは、リクエストが指定された上限を超えていて、さらに有効なトークンが含まれていない場合、そのリクエストの数を制限します。 + リクエストに有効期限が切れていない有効なトークンがない場合、このアクションはリクエストをブロックし、CAPTCHA パズルまたはブラウザのチャレンジをクライアントに返送します。エンドユーザーまたはクライアントブラウザが正常に応答すると、クライアントは有効なトークンを受け取り、元のリクエストが自動的に再送信されます。集約インスタンスのレート制限がまだ有効である場合、有効期限が切れていない有効なトークンを含むこの新しいリクエストには、次の箇条書きで説明するアクションが適用されます。 + リクエストに有効期限が切れていない有効なトークンがある場合、CAPTCHA また Challenge アクションはトークンを検証し、Count アクションと同様にリクエストに対してアクションを実行しません。レートベースのルールは、終了アクションを実行せずにリクエスト評価を保護パック (ウェブ ACL) に戻し、保護パック (ウェブ ACL) はリクエストの評価を続行します。詳細については、「[CAPTCHA および Challengeの AWS WAF](waf-captcha-and-challenge.md)」を参照してください。 **IP アドレスまたは転送された IP アドレスのみをレート制限する場合** 転送されたIPアドレスに対してのみIPアドレスのレート制限を行うようにルールを設定すると、そのルールが現在レート制限を適用しているIPアドレスのリストを取得できます。スコープダウンステートメントを使用する場合、レート制限されるリクエストは、スコープダウンステートメントと一致する IP リスト内のリクエストだけです。IP アドレスリストの取得の詳細については、「[レートベースのルールによってレート制限されている IP アドレスの一覧表示](listing-managed-ips.md)」を参照してください。 # のレートベースのルールの例 AWS WAF このセクションでは、一般的なレートベースのルールのさまざまなユースケースにおける設定例について説明します。各例は、ユースケースの説明を提供し、カスタム設定ルールの JSON リストにそのソリューションを示します。 **注記** これらの例に示されている JSON リストは、ルールを設定し、**Rule JSON エディタ**を使用して編集することにより、コンソールで作成されました。 **Topics** + [ # ログインページへのリクエストをレート制限する ](waf-rate-based-example-limit-login-page.md) + [ # 任意の IP アドレス、ユーザーエージェントペアからのログインページへのリクエストをレート制限する ](waf-rate-based-example-limit-login-page-keys.md) + [ # 特定のヘッダーが欠落しているリクエストをレート制限する ](waf-rate-based-example-limit-missing-header.md) + [ # 特定のラベルを使用してリクエストをレート制限する ](waf-rate-based-example-limit-labels.md) + [ # ラベル名前空間が指定されたラベルのリクエストをレート制限する ](waf-rate-based-example-limit-label-aggregation.md) + [ # 特定の ASN を使用してリクエストをレート制限する ](waf-rate-based-example-limit-asn.md) # ログインページへのリクエストをレート制限するウェブサイトのログインページへのリクエスト数を、サイトの他の部分へのトラフィックに影響を与えることなく制限するには、ログインページへのリクエストに一致するスコープダウンステートメントを含むレートベースのルールを作成し、リクエスト集約を **[すべてをカウント]** に設定します。レートベースのルールは、単一の集約インスタンス内のログインページのすべてのリクエストをカウントし、リクエストが制限を超えたときに、スコープダウンステートメントに一致するすべてのリクエストにルールアクションを適用します。次の JSON リストは、このルール設定の例を示しています。集約をすべてカウントするオプションは、`CONSTANT` 設定として JSON に記載されています。この例は、`/login` で始まるログインページと一致します。 ``` { "Name": "test-rbr", "Priority": 0, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "test-rbr" }, "Statement": { "RateBasedStatement": { "Limit": 1000, "EvaluationWindowSec": 300, "AggregateKeyType": "CONSTANT", "ScopeDownStatement": { "ByteMatchStatement": { "FieldToMatch": { "UriPath": {} }, "PositionalConstraint": "STARTS_WITH", "SearchString": "/login", "TextTransformations": [ { "Type": "NONE", "Priority": 0 } ] } } } } } ``` # 任意の IP アドレス、ユーザーエージェントペアからのログインページへのリクエストをレート制限する IP アドレス、ユーザーエージェントペアが制限を超えた場合に、ウェブサイトのログインページへのリクエスト数を制限するには、リクエスト集約を **[カスタムキー]** に設定して集約条件を指定します。次の JSON リストは、このルール設定の例を示しています。この例では、IP アドレス、ユーザーエージェントペアごとに 5 分間の時間枠でのお制限を 100 リクエストに設定しています。 ``` { "Name": "test-rbr", "Priority": 0, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "test-rbr" }, "Statement": { "RateBasedStatement": { "Limit": 100, "EvaluationWindowSec": 300, "AggregateKeyType": "CUSTOM_KEYS", "CustomKeys": [ { "Header": { "Name": "User-Agent", "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } }, { "IP": {} } ], "ScopeDownStatement": { "ByteMatchStatement": { "FieldToMatch": { "UriPath": {} }, "PositionalConstraint": "STARTS_WITH", "SearchString": "/login", "TextTransformations": [ { "Type": "NONE", "Priority": 0 } ] } } } } } ``` # 特定のヘッダーが欠落しているリクエストをレート制限する特定のヘッダーが欠落しているリクエスト数を制限するには、スコープダウンステートメントで **[すべてをカウント]** 集約オプションを使用できます。ヘッダーが存在していて値がある場合にのみ true を返すステートメントを含む、論理 `NOT` ステートメントを使用してスコープダウンステートメントを設定します。次の JSON リストは、このルール設定の例を示しています。 ``` { "Name": "test-rbr", "Priority": 0, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "test-rbr" }, "Statement": { "RateBasedStatement": { "Limit": 1000, "AggregateKeyType": "CONSTANT", "EvaluationWindowSec": 300, "ScopeDownStatement": { "NotStatement": { "Statement": { "SizeConstraintStatement": { "FieldToMatch": { "SingleHeader": { "Name": "user-agent" } }, "ComparisonOperator": "GT", "Size": 0, "TextTransformations": [ { "Type": "NONE", "Priority": 0 } ] } } } } } } } ``` # 特定のラベルを使用してリクエストをレート制限する複数のカテゴリのリクエストの数を制限するには、リクエストにラベルを追加する任意のルールまたはルールグループとレート制限を組み合わせることができます。そのためには、保護パック (ウェブ ACL) を次のように設定します。 + ラベルを追加するルールまたはルールグループを追加し、レート制限するリクエストがブロックまたは許可されないように設定します。マネージドルールグループを使用する場合、この動作を実現するために一部のルールグループのルールアクションを Count にオーバーライドすることが必要になる場合があります。 + ラベル付けルールとルールグループよりも高い優先度番号設定のレートベースのルールを保護パック (ウェブ ACL) に追加します。は、最も低いものから順にルール AWS WAF を評価するため、レートベースのルールはラベル付けルールの後に実行されます。ルールのスコープダウンステートメントのラベル一致とラベル集約を組み合わせて、ラベルのレート制限を設定します。次の例では、Amazon IP 評価リストの AWS Managed Rules ルールグループを使用します。このルールグループのルールである `AWSManagedIPDDoSList` は、IP が DDoS 攻撃に積極的に関与していることがわかっているリクエストを検出し、ラベルを付けます。ルールのアクションは、ルールグループ定義で Count に設定されています。ルールグループの詳細については、「[Amazon IP 評価リストマネージドルールグループ](aws-managed-rule-groups-ip-rep.md#aws-managed-rule-groups-ip-rep-amazon)」を参照してください。次の保護パック (ウェブ ACL) JSON リストでは、IP 評価ルールグループの後にラベル一致のレートベースのルールが続いています。レートベースのルールでは、スコープダウンステートメントを使用して、ルールグループのルールでマークされたリクエストをフィルタリングします。レートベースのルールステートメントは、フィルタリングされたリクエストを IP アドレスで集約してレート制限します。 ``` { "Name": "test-web-acl", "Id": ... "ARN": ... "DefaultAction": { "Allow": {} }, "Description": "", "Rules": [ { "Name": "AWS-AWSManagedRulesAmazonIpReputationList", "Priority": 0, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesAmazonIpReputationList" } }, "OverrideAction": { "None": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSManagedRulesAmazonIpReputationList" } }, { "Name": "test-rbr", "Priority": 1, "Statement": { "RateBasedStatement": { "Limit": 100, "EvaluationWindowSec": 300, "AggregateKeyType": "IP", "ScopeDownStatement": { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:amazon-ip-list:AWSManagedIPDDoSList" } } } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "test-rbr" } } ], "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "test-web-acl" }, "Capacity": 28, "ManagedByFirewallManager": false, "RetrofittedByFirewallManager": false, "LabelNamespace": "awswaf:0000000000:webacl:test-web-acl:" } ``` # ラベル名前空間が指定されたラベルのリクエストをレート制限する **注記** Bot Control マネージドルールグループの共通レベルルールは、さまざまなカテゴリのボットにラベルを追加しますが、ブロックするのは未検証ボットからのリクエストに限ります。これらのルールの詳細については、「[Bot Control のルールリスト](aws-managed-rule-groups-bot.md#aws-managed-rule-groups-bot-rules)」を参照してください。 Bot Control マネージドルールグループを使用する場合、個々の検証済みボットからのリクエストにレート制限を追加できます。そのためには、Bot Control ルールグループの後に実行されて、リクエストをボット名のラベル別に集約するレートベースのルールを追加します。**[ラベル名前空間]** 集約キーを指定し、名前空間キーを `awswaf:managed:aws:bot-control:bot:name:` と設定します。指定された名前空間を持つ一意のラベルはそれぞれ、集約インスタンスを定義します。例えば、`awswaf:managed:aws:bot-control:bot:name:axios` と `awswaf:managed:aws:bot-control:bot:name:curl` というラベルは、それぞれに集約インスタンスを定義します。次の保護パック (ウェブ ACL) JSON リストは、この設定を示しています。この例のルールでは、単一のボット集約インスタンスに対するリクエストを 2 分間で最大 1,000 件に制限しています。 ``` { "Name": "test-web-acl", "Id": ... "ARN": ... "DefaultAction": { "Allow": {} }, "Description": "", "Rules": [ { "Name": "AWS-AWSManagedRulesBotControlRuleSet", "Priority": 0, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesBotControlRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesBotControlRuleSet": { "InspectionLevel": "COMMON" } } ] } }, "OverrideAction": { "None": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSManagedRulesBotControlRuleSet" } }, { "Name": "test-rbr", "Priority": 1, "Statement": { "RateBasedStatement": { "Limit": 1000, "EvaluationWindowSec": 120, "AggregateKeyType": "CUSTOM_KEYS", "CustomKeys": [ { "LabelNamespace": { "Namespace": "awswaf:managed:aws:bot-control:bot:name:" } } ] } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "test-rbr" } } ], "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "test-web-acl" }, "Capacity": 82, "ManagedByFirewallManager": false, "RetrofittedByFirewallManager": false, "LabelNamespace": "awswaf:0000000000:webacl:test-web-acl:" } ``` # 特定の ASN を使用してリクエストをレート制限するリクエストの IP アドレスに基づいて特定の AS 番号 (ASN)からのリクエスト数を制限するには、リクエスト集約を *カスタムキー* に設定し、集約基準を指定します。次の JSON は、`X-Forwarded-For` ヘッダーにある転送された IP アドレスから派生した ASN を集計するルールの例を示しています。IP アドレスの形式が正しくないためにが ASN を取得 AWS WAF できない場合、フォールバック動作はに設定されます`MATCH`。 ``` { "Name": "test-rbr", "Priority": 0, "Statement": { "RateBasedStatement": { "AggregateKeyType": "CUSTOM_KEYS", "CustomKeys": [ { "ASN": {} }, { "ForwardedIP": {} } ], "EvaluationWindowSec": 300, "ForwardedIPConfig": { "FallbackBehavior": "MATCH", "HeaderName": "X-Forwarded-For" }, "Limit": 2000 } }, "VisibilityConfig": { "CloudWatchMetricsEnabled": true, "MetricName": "test-rbr", "SampledRequestsEnabled": true } } ``` # レートベースのルールによってレート制限されている IP アドレスの一覧表示このセクションでは、CLI、API、または任意の SDK を使用して、レートベースのルールによって現在レート制限されている IP アドレスのリストにアクセスする方法を調べる方法について説明します。レートベースのルールが IP アドレスまたは転送された IP アドレスでのみ集計される場合、ルールが現在レート制限している IP アドレスのリストを取得できます。は、これらの IP アドレスをルールのマネージドキーリストに AWS WAF 保存します。 **注記** このオプションは、IP アドレスのみ、またはヘッダーの IP アドレスのみを集約する場合に限り使用できます。カスタムキーのリクエスト集約を使用する場合、カスタムキーでいずれかの IP アドレス仕様を使用しても、レート制限されている IP アドレスのリストは取得できません。レートベースのルールは、そのルールのスコープダウンステートメントと一致する、ルールのマネージドキーリストからのリクエストにルールアクションを適用します。ルールにスコープダウンステートメントがない場合は、リストに含まれている IP アドレスからのすべてのリクエストにアクションが適用されます。ルールアクションはデフォルトで Block ですが、Allow を除く有効なルールアクションであればどれでもかまいません。単一のレートベースのルールインスタンスを使用して制限をレート AWS WAF できる IP アドレスの最大数は 10,000 です。10,000 を超えるアドレスがレート制限を超えると、はレートが最も高いアドレス AWS WAF を制限します。 CLI、API、または任意の SDK を使用して、レートベースのルールのマネージドキーリストにアクセスできます。このトピックでは、CLI および API を使用したアクセスについて説明します。現時点では、コンソールからリストにアクセスすることはできません。 AWS WAF API の場合、コマンドは [GetRateBasedStatementManagedKeys](https://docs.aws.amazon.com/waf/latest/APIReference/API_GetRateBasedStatementManagedKeys.html) です。 AWS WAF CLI の場合、コマンドは [get-rate-based-statement-managed-keys](https://docs.aws.amazon.com/cli/latest/reference/wafv2/get-rate-based-statement-managed-keys.html) です。 Amazon CloudFront ディストリビューションの保護パック (ウェブ ACL) で使用されているレートベースのルールのレート制限されている IP アドレスのリストを取得する構文を次に示します。 ``` aws wafv2 get-rate-based-statement-managed-keys --scope=CLOUDFRONT --region=us-east-1 --web-acl-name=WebACLName --web-acl-id=WebACLId --rule-name=RuleName ``` 以下は、リージョンアプリケーション、Amazon API Gateway REST API、Application Load Balancer、 AWS AppSync GraphQL API、Amazon Cognito ユーザープール、 AWS App Runner サービス AWS Amplify、または AWS Verified Access インスタンスの構文を示しています。 ``` aws wafv2 get-rate-based-statement-managed-keys --scope=REGIONAL --region=region --web-acl-name=WebACLName --web-acl-id=WebACLId --rule-name=RuleName ``` AWS WAF はウェブリクエストをモニタリングし、保護パック (ウェブ ACL)、オプションのルールグループ、レートベースのルールの一意の組み合わせごとにキーを個別に管理します。例えば、ルールグループ内でレートベースのルールを定義してから、ウェブ ACL でルールグループを使用すると、 AWS WAF はウェブリクエストをモニタリングし、その保護パック (ウェブ ACL)、ルールグループ参照ステートメント、およびレートベースのルールインスタンスのキーを管理できます。2 番目の保護パック (ウェブ ACL) で同じルールグループを使用する場合、はウェブリクエスト AWS WAF を監視し、この 2 番目の使用のキーを最初とは完全に独立して管理します。ルールグループ内で定義したレートベースのルールの場合は、ルールグループ内の保護パック (ウェブ ACL) 名とレートベースのルール名に加えて、リクエストでルールグループ参照ステートメントの名前を指定する必要があります。レートベースのルールがルールグループ内で定義され、保護パック (ウェブ ACL) でルールグループが使用されるリージョンレベルのアプリケーションの構文を次に示します。 ``` aws wafv2 get-rate-based-statement-managed-keys --scope=REGIONAL --region=region --web-acl-name=WebACLName --web-acl-id=WebACLId --rule-group-rule-name=RuleGroupRuleName --rule-name=RuleName ``` # でのルールグループルールステートメントの使用 AWS WAF **注記** ルールグループのルールステートメントはネストできません。このセクションでは、保護パック (ウェブ ACL) で使用できるルールグループのルールステートメントについて説明します。ルールグループの保護パック (ウェブ ACL) キャパシティーユニット (WCU) は、ルールグループの作成時にルールグループの所有者によって設定されます。WCU の詳細については、「[のウェブ ACL キャパシティユニット (WCUs) AWS WAF](aws-waf-capacity-units.md)」を参照してください。 | ルールグループステートメント | 説明 | WCU | | --- | --- | --- | | [マネージドルールグループステートメントを使用する](waf-rule-statement-type-managed-rule-group.md) | 指定されたマネージドルールグループで定義されているルールを実行します。スコープダウンステートメントを追加することで、ルールグループで評価されるリクエストの範囲を絞り込むことができます。マネージドルールグループステートメントは、他のステートメントタイプ内にネストできません。 | ルールグループと、スコープダウンステートメント用の追加の WCU によって定義されます。 | | [ルールグループステートメントの使用](waf-rule-statement-type-rule-group.md) | 管理するルールグループで定義されているルールを実行します。独自のルールグループのルールグループ参照ステートメントにスコープダウンステートメントを追加することはできません。ルールグループステートメントは、他のステートメントタイプ内にネストできません。 | WCU の制限は、ルールグループを作成するときに定義します。 | # でのマネージドルールグループステートメントの使用 AWS WAF このセクションでは、マネージドルールグループのルールステートメントの仕組みについて説明します。マネージドルールグループルールステートメントは、保護パック (ウェブ ACL) ルールリストに含まれる参照をマネージドルールグループに追加します。コンソールのルールステートメントにはこのオプションは表示されませんが、保護パック (ウェブ ACL) の JSON 形式を操作しているときには、追加したマネージドルールグループがこのタイプとしてウェブ ACL ルールに表示されます。マネージドルールグループは、 AWS マネージドルールルールグループのいずれかであり、そのほとんどは AWS WAF お客様が無料で利用できます AWS Marketplace 。有料の AWS マネージドルールルールグループを保護パック (ウェブ ACL) に追加すると、自動的にサブスクライブします。 AWS Marketplace マネージドルールグループは、を通じてサブスクライブできます AWS Marketplace。詳細については、「[でのマネージドルールグループの使用 AWS WAF](waf-managed-rule-groups.md)」を参照してください。ルールグループを保護パック (ウェブ ACL) に追加すると、グループ内のルールのアクションを Count またはその他のルールアクションにオーバーライドできます。詳細については、「[でのルールグループアクションの上書き AWS WAF](web-acl-rule-group-override-options.md)」を参照してください。がルールグループで AWS WAF 評価するリクエストの範囲を絞り込むことができます。これを行うには、ルールグループステートメント内にスコープダウンステートメントを追加します。スコープダウンステートメントの詳細については、「[でのスコープダウンステートメントの使用 AWS WAF](waf-rule-scope-down-statements.md)」を参照してください。これは、ルールグループがトラフィックに与える影響を管理し、ルールグループを使用するときにトラフィック量に関連するコストを抑えるのに役立ちます。 AWS WAF Bot Control マネージドルールグループでスコープダウンステートメントを使用する情報と例については、「」を参照してください[AWS WAF ボットコントロール](waf-bot-control.md)。 ## ルールステートメントの特性 **ネスト不可** - このステートメントタイプを他のステートメント内にネストしたり、ルールグループに含めたりすることはできません。このタイプは保護パック (ウェブ ACL) に直接含めることができます。 **(オプション) スコープダウンステートメント** – このルールタイプは、オプションのスコープダウンステートメントを使用して、ルールグループが評価するリクエストの範囲を絞り込みます。詳細については、「[でのスコープダウンステートメントの使用 AWS WAF](waf-rule-scope-down-statements.md)」を参照してください。 **WCU** - 作成時にルールグループに設定します。 ## このルールステートメントの場所 + **コンソール** - 保護パック (ウェブ ACL) の作成プロセス中に、**[Add rules and rule groups]** (ルールとルールグループの追加) ページで **[Add managed rule groups]** (マネージドルールグループの追加) を選択し、使用するルールグループを見つけて選択します。 + **API** – 「[ManagedRuleGroupStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_ManagedRuleGroupStatement.html)」 # でのルールグループステートメントの使用 AWS WAF このセクションでは、ルールグループルールステートメントの仕組みについて説明します。ルールグループルールステートメントは、保護パック (ウェブ ACL) ルールリストへの参照を、管理されているルールグループに追加します。コンソールのルールステートメントにはこのオプションは表示されませんが、保護パック (ウェブ ACL) の JSON 形式を操作しているときには、追加した独自のルールグループがこのタイプとして保護パック (ウェブ ACL) ルールに表示されます。独自のルールグループの使用については、「[独自のルールグループの管理](waf-user-created-rule-groups.md)」を参照してください。ルールグループを保護パック (ウェブ ACL) に追加すると、グループ内のルールのアクションを Count またはその他のルールアクションにオーバーライドできます。詳細については、「[でのルールグループアクションの上書き AWS WAF](web-acl-rule-group-override-options.md)」を参照してください。 ## ルールステートメントの特性 **ネスト不可** - このステートメントタイプを他のステートメント内にネストしたり、ルールグループに含めたりすることはできません。このタイプは保護パック (ウェブ ACL) に直接含めることができます。 **WCU** - 作成時にルールグループに設定します。 ## このルールステートメントの場所 + **コンソール** - 保護パック (ウェブ ACL) の作成プロセス中に、**[Add rules and rule groups]** (ルールとルールグループの追加) ページで、**[Add my own rules and rule groups]** (独自のルールとルールグループの追加)、**[Rule group]** (ルールグループ) を選択し、使用するルールグループを追加します。 + **API** – 「[RuleGroupReferenceStatement](https://docs.aws.amazon.com/waf/latest/APIReference/API_RuleGroupReferenceStatement.html)」 # AWS WAF ルールグループこのセクションでは、ルールグループとは、また、その仕組みについて説明します。ルールグループは、保護パック (ウェブ ACL) に追加できる再利用可能なルールのセットです。保護パック (ウェブ ACL) の詳細については、「[での保護の設定 AWS WAF](web-acl.md)」を参照してください。ルールグループは、主に次のカテゴリに分類されます。 + ユーザー独自のルールグループは、ユーザーが作成して管理します。 + マネージドルールチームが作成および管理する AWS マネージドルールグループ。 + AWS Marketplace 販売者が作成および管理するマネージドルールグループ。 + AWS Firewall Manager や Shield Advanced などの他のサービスによって所有および管理されているルールグループ。 **ルールグループと保護パック (ウェブ ACL) の相違点** ルールグループと保護パック (ウェブ ACL) には、どちらもルールが含まれています。ルールは、両方の場所で同じ方法で定義されます。ルールグループは、次の点で保護パック (ウェブ ACL) と異なります。 + ルールグループには、ルールグループ参照ステートメントを含めることはできません。 + 各保護パック (ウェブ ACL) にルールグループリファレンスステートメントを追加することで、複数の保護パック (ウェブ ACL) で 1 つのルールグループを再利用できます。保護パック (ウェブ ACL) を再利用することはできません。 + ルールグループにはデフォルトのアクションがありません。保護パック (ウェブ ACL) では、含めるルールまたはルールグループごとにデフォルトのアクションを設定します。ルールグループまたは保護パック (ウェブ ACL) 内の個々のルールには、アクションが定義されています。 + ルールグループを AWS リソースに直接関連付けることはありません。ルールグループを使用してリソースを保護するには、保護パック (ウェブ ACL) でルールグループを使用します。 + システムは、保護パック (ウェブ ACL) ごとに最大容量が 5,000 の保護パック (ウェブ ACL) キャパシティユニット (WCU) を定義します。各ルールグループには、作成時に設定する必要がある WCU 設定があります。この設定を使用して、ルールグループを使用して保護パック (ウェブ ACL) に追加される追加の容量要件を計算できます。WCU の詳細については、「[のウェブ ACL キャパシティユニット (WCUs) AWS WAF](aws-waf-capacity-units.md)」を参照してください。ルールについては、「[AWS WAF ルール](waf-rules.md)」を参照してください。このセクションでは、独自のルールグループを作成および管理するためのガイダンス、使用できるマネージドルールグループの説明、マネージドルールグループの使用に関するガイダンスを提供します。 **Topics** + [ # でのマネージドルールグループの使用 AWS WAF ](waf-managed-rule-groups.md) + [ # 独自のルールグループの管理 ](waf-user-created-rule-groups.md) + [ # AWS Marketplace ルールグループ ](marketplace-rule-groups.md) + [ # 他のサービスによって提供されるルールグループを識別する ](waf-service-owned-rule-groups.md) # でのマネージドルールグループの使用 AWS WAF このセクションでは、マネージドルールグループとは何か、そしてその仕組みについて説明します。マネージドルールグループは、 ready-to-useルールのコレクションです。 AWS AWS Marketplace マネージドルールグループの使用には、基本 AWS WAF 料金が適用されます。 AWS WAF 料金情報については、[AWS WAF 「 ](https://aws.amazon.com/waf/pricing/)料金表」を参照してください。 + * AWS WAF Bot Control、 AWS WAF Fraud Control アカウント乗っ取り防止 (ATP)、および AWS WAF Fraud Control アカウント作成不正防止 (ACFP) の AWS Managed Rules ルールグループは*、基本料金以外の追加料金で利用できます AWS WAF 。料金の詳細については、「[AWS WAF の料金](https://aws.amazon.com/waf/pricing/)」を参照してください。 + *他のすべての AWS マネージドルールルールグループは*、追加料金なしで AWS WAF 利用できます。 + *AWS Marketplace ルールグループは*、を通じてサブスクリプションで使用できます AWS Marketplace。これらのルールグループはそれぞれ、 AWS Marketplace 販売者によって所有および管理されます。 AWS Marketplace ルールグループを使用するための料金情報については、 AWS Marketplace 販売者にお問い合わせください。一部のマネージドルールグループは、WordPress、Joomla、PHP などの特定のタイプのウェブアプリケーションを保護するために設計されています。「[OWASP Top 10](https://owasp.org/www-project-top-ten/)」にリストされているものを含め、既知の脅威や一般的なウェブアプリケーションの脆弱性に対する幅広い保護を提供するものもあります。PCI や HIPAA などの規制の遵守が必要な場合は、マネージドルールグループを使用してウェブアプリケーションファイアウォールの要件を満たすことができます。 **自動更新** 絶えず変化する脅威の状況に遅れずについていくには、時間とコストがかかることがあります。マネージドルールグループを使用すると、 AWS WAFを実装して使用する際の時間を節約できます。多くの AWS および AWS Marketplace 販売者は、新しい脆弱性や脅威が発生すると、マネージドルールグループを自動的に更新し、新しいバージョンのルールグループを提供します。場合によっては、多くのプライベート開示コミュニティへの参加により、 AWS は公開前に新しい脆弱性について通知されます。このような場合、新しい脅威が広く知られる前でも、は AWS マネージドルールのルールグループを更新してデプロイ AWS できます。 **マネージドルールグループのルールへの制限付きアクセス** 各マネージドルールグループには、どのようなタイプの攻撃や脆弱性に対して保護するように設計されているかが包括的に定義されています。ルールグループプロバイダーの知的財産を保護するために、ルールグループ内の個々のルールのすべての詳細を表示することはできません。この制限は、悪意のあるユーザーが公開されたルールを特に回避する脅威を設計するのを防ぐのにも役立ちます。 **Topics** + [ # でのバージョニングされたマネージドルールグループの使用 AWS WAF ](waf-managed-rule-groups-versioning.md) + [ # マネージドルールグループの使用 ](waf-using-managed-rule-groups.md) + [ # AWS のマネージドルール AWS WAF ](aws-managed-rule-groups.md) # でのバージョニングされたマネージドルールグループの使用 AWS WAF このセクションでは、マネージドルールグループのバージョニングの処理方法について説明します。多くのマネージドルールグループプロバイダーはバージョニングを利用して、ルールグループのオプションと機能を更新します。通常、マネージドルールグループの特定のバージョンは静的です。場合によっては、例えば新しいセキュリティの脅威に対応するために、プロバイダーがマネージドルールグループの静的バージョンの一部または全部を更新する必要がある場合があります。保護パック (ウェブ ACL) でバージョニングされたマネージドルールグループを使用する場合、デフォルトバージョンを選択し、使用する静的バージョンをプロバイダーに管理させるか、特定の静的バージョンを選択できます。 **必要なバージョンが見つかりませんか?** ルールグループのバージョン一覧にバージョンが表示されない場合は、そのバージョンの有効期限の失効が予定されているか、すでに期限切れになっている可能性があります。バージョンの有効期限がスケジュールされると、ではルールグループにバージョンを選択 AWS WAF できなくなります。 **AWS マネージドルールルールグループの SNS 通知** AWS マネージドルールルールグループはすべて、IP 評価ルールグループを除き、バージョニングと SNS 更新の通知を提供します。通知を提供する AWS マネージドルールルールグループは、すべて同じ SNS トピックの Amazon リソースネーム (ARN) を使用します。SNS 通知にサインアップするには、[新しいバージョンとアップデートの通知を受け取る](waf-using-managed-rule-groups-sns-topic.md) を参照してください。 **Topics** + [ # マネージドルールグループのバージョンライフサイクル ](waf-managed-rule-groups-versioning-lifecycle.md) + [ # マネージドルールグループのバージョンの有効期限 ](waf-managed-rule-groups-versioning-expiration.md) + [ # マネージドルールグループのバージョン処理に関するベストプラクティス ](waf-managed-rule-groups-best-practice.md) # マネージドルールグループのバージョンライフサイクルプロバイダーは、マネージドルールグループの静的バージョンの次のライフサイクルステージを処理します。 + **リリースとアップデート** – マネージドルールグループのプロバイダーは、Amazon Simple Notification Service (Amazon SNS) トピックに対する通知を通じて、マネージドルールグループの今後のバージョンと新しい静的バージョンを知らせます。また、プロバイダーは、緊急時の必須の更新など、ルールグループに関するその他の重要な情報を伝達するためにトピックを使用する場合もあります。ルールグループのトピックをサブスクライブし、通知の受信方法を設定できます。詳細については、「[新しいバージョンとアップデートの通知を受け取る](waf-using-managed-rule-groups-sns-topic.md)」を参照してください。 + **有効期限のスケジュール** – マネージドルールグループのプロバイダーは、古いバージョンのルールグループの有効期限をスケジュールします。失効予定のバージョンは、保護パック (ウェブ ACL) ルールに追加できません。バージョンの有効期限がスケジュールされると、は Amazon CloudWatch のカウントダウンメトリクスを使用して有効期限 AWS WAF を追跡します。 + **バージョンの有効期限** – マネージドルールグループの期限切れバージョンを使用するように保護パック (ウェブ ACL) を設定している場合、保護パック (ウェブ ACL) の評価中に、はルールグループのデフォルトバージョン AWS WAF を使用します。さらに、は、ルールグループを削除しない、またはそのバージョンを有効期限が切れていないものに変更しない保護パック (ウェブ ACL) の更新を AWS WAF ブロックします。 AWS Marketplace マネージドルールグループを使用する場合は、バージョンライフサイクルに関する追加情報をプロバイダーに依頼してください。 # マネージドルールグループのバージョンの有効期限このセクションでは、バージョニングされたマネージドルールグループでバージョンの有効期限がどのように機能するかについて説明します。ルールグループの特定のバージョンを使用する場合は、有効期限切れのバージョンを使用し続けないようにしてください。バージョンの有効期限は、ルールグループの SNS 通知と Amazon CloudWatch メトリクスを通じてモニタリングできます。保護パック (ウェブ ACL) で使用しているバージョンの有効期限が切れている場合、は、ルールグループの有効期限が切れていないバージョンへの移行を含まない保護パック (ウェブ ACL) の更新を AWS WAF ブロックします。ルールグループを使用可能なバージョンに更新するか、保護パック (ウェブ ACL) から削除できます。マネージドルールグループの有効期限の処理は、ルールグループプロバイダーによって異なります。 AWS マネージドルールのルールグループの場合、期限切れになったバージョンはルールグループのデフォルトバージョンに自動的に変更されます。 AWS Marketplace ルールグループについては、プロバイダーに有効期限の処理方法を尋ねます。プロバイダーは、ルールグループの新しいバージョンを作成するときに、バージョンの予測される有効期間を設定します。このバージョンは有効期限が切れるようにスケジュールされていませんが、Amazon CloudWatch メトリクス値は予測されたライフタイムに設定されており、CloudWatch でメトリクスのフラット値が表示されます。プロバイダーがメトリクスの有効期限をスケジュールすると、メトリクス値は有効期限の到来時にゼロになるまで、毎日減少します。モニタリング有効期限の詳細については、[バージョンの有効期限の追跡](waf-using-managed-rule-groups-expiration.md) を参照してください。 # マネージドルールグループのバージョン処理に関するベストプラクティスバージョン管理されたマネージドルールグループを使用する場合は、このベストプラクティスのガイダンスに従ってバージョニングを行ってください。保護パック (ウェブ ACL) でマネージドルールグループを使用する場合は、ルールグループの特定の静的バージョンを使用するか、デフォルトバージョンを使用するように選択できます。 + **デフォルトバージョン** – AWS WAF 常にデフォルトバージョンをプロバイダーが現在推奨している静的バージョンに設定します。推奨される静的バージョンをプロバイダーが更新すると、 AWS WAF は、保護パック (ウェブ ACL) のルールグループのデフォルトバージョンの設定を自動的に更新します。マネージドルールグループのデフォルトバージョンを使用する場合は、ベストプラクティスとして次の手順を実行します。 + **通知をサブスクライブする** – ルールグループへの変更に関する通知をサブスクライブし、それらを監視します。ほとんどのプロバイダーは、新しい静的バージョンとデフォルトバージョンの変更について事前通知を送信します。これにより、が AWS デフォルトバージョンを切り替える前に、新しい静的バージョンの影響を確認できます。詳細については、「[新しいバージョンとアップデートの通知を受け取る](waf-using-managed-rule-groups-sns-topic.md)」を参照してください。 + **デフォルトを新しい静的バージョンに設定する前に、その影響を確認し、必要に応じて調整する** – デフォルトを新しい静的バージョンに設定する前に、ウェブリクエストのモニタリングと管理に対する静的バージョンの影響を確認します。新しい静的バージョンには、確認する新しいルールが含まれている可能性があります。ルールグループの使用方法を変更する必要がある場合に備えて、誤検出やその他の予期しない動作を見つけます。例えば、新しい動作の処理方法を把握しながら、トラフィックをブロックしないようにするために、ルールをカウントに設定できます。詳細については、「[AWS WAF 保護のテストとチューニング](web-acl-testing.md)」を参照してください。 + **静的バージョン** – 静的バージョンを使用する場合は、ルールグループの新しいバージョンを採用する準備ができたら、バージョン設定を手動で更新する必要があります。マネージドルールグループの静的バージョンを使用する場合は、ベストプラクティスとして次の手順を実行します。 + **バージョンを最新の状態に保つ** – マネージドルールグループを可能な限り最新バージョンに近いものにします。新しいバージョンがリリースされたら、それをテストし、必要に応じて設定を調整し、適時に実装してください。テストについては、「[AWS WAF 保護のテストとチューニング](web-acl-testing.md)」を参照してください。 + **通知をサブスクライブする** – ルールグループに対する変更に関する通知をサブスクライブして、プロバイダーが新しい静的バージョンをいつリリースするかを把握します。ほとんどのプロバイダーは、バージョン変更に関する事前の通知を提供します。さらに、セキュリティホールをふさぐため、またはその他の緊急の理由で、使用している静的バージョンをプロバイダーが更新する必要がある場合があります。プロバイダーの通知をサブスクライブすると、状況について知ることができます。詳細については、「[新しいバージョンとアップデートの通知を受け取る](waf-using-managed-rule-groups-sns-topic.md)」を参照してください。 + **[Avoid version expiration]** (バージョンの有効期限切れを回避する) - これ使用している間は、静的バージョンの有効期限が切れないようにします。期限切れのバージョンのプロバイダーによる処理はさまざまであり、使用可能なバージョンへのアップグレードの強制や、予期しない結果をもたらす可能性のあるその他の変更が含まれる場合があります。 AWS WAF 有効期限メトリクスを追跡し、サポートされているバージョンに正常にアップグレードするのに十分な日数を提供するアラームを設定します。詳細については、「[バージョンの有効期限の追跡](waf-using-managed-rule-groups-expiration.md)」を参照してください。 # マネージドルールグループの使用このセクションでは、マネージドルールグループにアクセスして管理するためのガイダンスを提供します。マネージドルールグループを保護パック (ウェブ ACL) に追加すると、独自のルールグループと同じ設定オプションに加えて、追加設定を選択できます。コンソールで、保護パック (ウェブ ACL) でルールを追加および編集するプロセス中に、マネージドルールグループの情報にアクセスします。API とコマンドラインインターフェイス (CLI) を通じて、マネージドルールグループの情報を直接リクエストできます。保護パック (ウェブ ACL) でマネージドルールグループを使用する場合、次の設定を編集できます。 + **[Version]** (バージョン) – これは、ルールグループがバージョン管理されている場合にのみ使用できます。詳細については、「[でのバージョニングされたマネージドルールグループの使用 AWS WAF](waf-managed-rule-groups-versioning.md)」を参照してください。 + **ルールアクションのオーバーライド** – ルールグループ内のルールのアクションを任意のアクションにオーバーライドできます。Count に設定すると、ルールグループを使用してウェブリクエストを管理する前に、そのルールグループをテストするときに便利です。詳細については、「[ルールグループのルールアクションの上書き](web-acl-rule-group-override-options.md#web-acl-rule-group-override-options-rules)」を参照してください。 + **[Scope-down statement]** (スコープダウンステートメント) – スコープダウンステートメントを追加して、ルールグループで評価したくないウェブリクエストを除外できます。詳細については、「[でのスコープダウンステートメントの使用 AWS WAF](waf-rule-scope-down-statements.md)」を参照してください。 + **[Override rule group action]** (ルールグループアクションを上書き) – ルールグループ評価の結果として生じるアクションを上書きして、Count のみに設定できます。このオプションは、一般的に使用されません。がルールグループ内のルール AWS WAF を評価する方法は変更されません。詳細については、「[ルールグループの戻り値アクションを Count に上書き](web-acl-rule-group-override-options.md#web-acl-rule-group-override-options-rule-group)」を参照してください。 **保護パック (ウェブ ACL) でマネージドルールグループの設定を編集するには** + **コンソール** + (オプション) マネージドルールグループを保護パック (ウェブ ACL) に追加する場合、**[Edit]** (編集) を選択して、設定を表示および編集できます。 + (オプション) マネージドルールグループを保護パック (ウェブ ACL) に追加したら、**[保護パック (ウェブ ACL)]** ページから、作成したばかりの保護パック (ウェブ ACL) を選択します。これにより、保護パック (ウェブ ACL) 編集ページが表示されます。 + **[Rules]** (ルール) を選択します。 + ルールグループを選択し、**[Edit]** (編集) を選択して、設定を表示および編集します。 + **API および CLI** - コンソールの外部で保護パック (ウェブ ACL) を作成および更新するときに、マネージドルールグループの設定を管理できます。 # マネージドルールグループのリストの取得保護パック (ウェブ ACL) で使用可能なマネージドルールグループのリストを取得できます。このリストには、以下が含まれます。 + すべての AWS マネージドルールルールグループ。 + サブスクライブしている AWS Marketplace ルールグループ。 **注記** AWS Marketplace ルールグループへのサブスクライブの詳細については、「」を参照してください[AWS Marketplace ルールグループ](marketplace-rule-groups.md)。マネージドルールグループのリストを取得すると、返されるリストは、使用しているインターフェイスによって異なります。 + **コンソール** – コンソールでは、まだサブスクライブしていないルールグループを含む、すべてのマネージド AWS Marketplace ルールグループを表示できます。まだサブスクライブしていないものについては、インターフェイスにサブスクライブするためのリンクが用意されています。 + **API および CLI** - コンソールの外部では、リクエストは使用可能なルールグループのみを返します。 **マネージドルールグループのリストを取得するには** + **コンソール** - ウェブ ACL の作成プロセス中に、**[Add rules and rule groups]** (ルールとルールグループの追加) ページで **[Add managed rule groups]** (マネージドルールグループの追加) を選択します。最上位レベルには、プロバイダー名が一覧表示されます。各プロバイダーリストを展開して、マネージドルールグループのリストを表示します。バージョン対応ルールグループでは、このレベルで表示される情報はデフォルトバージョンの情報です。マネージドルールグループを保護パック (ウェブ ACL) に追加すると、コンソールに命名スキーム `-` に基づいて一覧表示されます。 + **API** – + `ListAvailableManagedRuleGroups` + **CLI** – + `aws wafv2 list-available-managed-rule-groups --scope=` # マネージドルールグループのルールの取得マネージドルールグループ内のルールのリストを取得できます。API コールと CLI コールは、JSON モデルまたはで参照できるルール仕様を返します AWS CloudFormation。 **マネージドルールグループ内のルールの一覧を取得するには** + **コンソール** + (オプション) マネージドルールグループを保護パック (ウェブ ACL) に追加する場合、**[Edit]** (編集) を選択してルールを表示できます。 + (オプション) マネージドルールグループを保護パック (ウェブ ACL) に追加したら、**[保護パック (ウェブ ACL)]** ページから、作成したばかりの保護パック (ウェブ ACL) を選択します。これにより、保護パック (ウェブ ACL) 編集ページが表示されます。 + **[Rules]** (ルール) を選択します。 + ルールリストを表示するルールグループを選択し、**Edit** を選択します。ルールグループ内のルールのリスト AWS WAF を表示します。 + **API** – `DescribeManagedRuleGroup` + **CLI** – `aws wafv2 describe-managed-rule-group --scope= --vendor-name --name ` # マネージドルールグループで使用可能なバージョンの取得マネージドルールグループの利用可能なバージョンは、まだ期限切れになる予定がないバージョンです。このリストは、ルールグループの現在のデフォルトバージョンであるバージョンを示します。 **マネージドルールグループの使用可能なバージョンのリストを取得するには** + **コンソール** + (オプション) マネージドルールグループを保護パック (ウェブ ACL) に追加する場合は、**[Edit]** (編集) を選択して、ルールグループの情報を表示します。**[Version]** (バージョン) ドロップダウンを展開して、使用可能なバージョンのリストを表示します。 + (オプション) マネージドルールグループを保護パック (ウェブ ACL) に追加したら、保護パック (ウェブ ACL) で **[Edit]** (編集) を選択し、ルールグループルールを選択して編集します。**[Version]** (バージョン) ドロップダウンを展開して、使用可能なバージョンのリストを表示します。 + **API** – + `ListAvailableManagedRuleGroupVersions` + **CLI** – + `aws wafv2 list-available-managed-rule-group-versions --scope= --vendor-name --name ` # コンソールを通じた保護パック (ウェブ ACL) へのマネージドルールグループの追加このセクションでは、コンソールを使用してマネージドルールグループを保護パック (ウェブ ACL) に追加する方法を説明します。このガイダンスは、すべての AWS マネージドルールルールグループと、サブスクライブしている AWS Marketplace ルールグループに適用されます。 **本番稼働トラフィックのリスク** 本番稼働トラフィックの保護パック (ウェブ ACL) に変更をデプロイする前に、ステージング環境またはテスト環境でテストおよびチューニングしてトラフィックへの潜在的な影響を確認します。その後、更新したルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。ガイダンスについては、「[AWS WAF 保護のテストとチューニング](web-acl-testing.md)」を参照してください。 **注記** 保護パック (ウェブ ACL) で 1,500 WCU を超える容量を使用すると、保護パック (ウェブ ACL) の基本料金を超えるコストが発生します。詳細については、「[のウェブ ACL キャパシティユニット (WCUs) AWS WAF](aws-waf-capacity-units.md)」と「[AWS WAF 料金表](https://aws.amazon.com/waf/pricing/)」を参照してください。 **コンソールで保護パック (ウェブ ACL) にマネージドルールグループを追加するには** **コンソールでウェブ ACL にマネージドルールグループを追加するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで **[保護パック (ウェブ ACL)]** を選択します。 1. **[保護パック (ウェブ ACL)]** ページで、保護パック (ウェブ ACL) のリストから、ルールグループを追加する保護パック (ウェブ ACL) を選択します。これにより、単一の保護パック (ウェブ ACL) のページが表示されます。 1. 保護パック (ウェブ ACL) ページで、**[ルール]** タブを選択します。 1. **[Rules]** (ルール) ペインで、**[Add rules]** (ルールを追加) を選択してから、**[Add managed rule groups]** (マネージドルールグループを追加) を選択します。 1. **[Add managed rule groups]** (マネージドルールグループを追加) ページで、ルールグループのベンダーの選択を展開して、使用可能なルールグループのリストを表示します。 1. 追加するルールグループごとに、**[保護パック (ウェブ ACL) に追加]** を選択します。ルールグループの保護パック (ウェブ ACL) の設定を変更する場合は、**[編集]** を選択し、変更を加えてから、**[ルールを保存]** を選択します。オプションの詳細については、[でのバージョニングされたマネージドルールグループの使用 AWS WAF](waf-managed-rule-groups-versioning.md) のバージョニングに関するガイダンス、および [でのマネージドルールグループステートメントの使用 AWS WAF](waf-rule-statement-type-managed-rule-group.md) の保護パック (ウェブ ACL) でのマネージドルールグループの使用に関するガイダンスを参照してください。 1. **[Add managed rule groups]** (マネージドルールグループを追加) ページの下部で、**[Add rules]** (ルールを追加) を選択します。 1. **[Set rule priority]** (ルールの優先度を設定) ページで、必要に応じてルールが実行される順序を調整し、**[Save]** (保存) を選択します。詳細については、「[ルールの優先度を設定する](web-acl-processing-order.md)」を参照してください。保護パック (ウェブ ACL) のページで、追加したマネージドルールグループが **[ルール]** タブに一覧表示されます。本番トラフィックに使用する前に、 AWS WAF 保護の変更をテストして調整します。詳細については、「[AWS WAF 保護のテストとチューニング](web-acl-testing.md)」を参照してください。 **更新中の一時的な不一致** 保護パック (ウェブ ACL) または他の AWS WAF リソースを作成または変更すると、リソースが保存されているすべての領域にその変更が反映されるまでに少し時間がかかります。伝播時間は、数秒から数分までかかります。次の内容では、変更伝播中に直面する一時的な不整合性の例を紹介します。 + 保護パック (ウェブ ACL) を作成した後、それをリソースに関連付けようとすると、保護パック (ウェブ ACL) が利用できないことを示す例外が表示される場合があります。 + ルールグループを保護パック (ウェブ ACL) に追加した後、新しいルールグループのルールは、保護パック (ウェブ ACL) が使用されるエリアで有効になり、別のエリアでは有効にならない場合があります。 + ルールのアクション設定を変更した後、古いアクションを一部のエリアで確認され、新しいアクションを別のエリアで確認される場合があります。 + ブロックルールで使用されている IP セットに IP アドレスを追加した後、新しいアドレスはあるエリアではブロックされ、別のエリアでは許可される場合があります。 # マネージドルールグループに対する新しいバージョンと更新の通知を受け取るこのセクションでは、新しいバージョンと更新に関する Amazon SNS 通知を受信する方法について説明します。マネージドルールグループプロバイダーは、SNS 通知を使用して、今後の新しいバージョンや緊急のセキュリティアップデートなどのルールグループの変更を知らせます。 **SNS 通知をサブスクライブするには** ルールグループの通知をサブスクライブするには、米国東部 (バージニア北部) リージョン us-east-1 のルールグループの Amazon SNS トピック ARN の Amazon SNS サブスクリプションを作成します。サブスクライブする方法については、「[Amazon Simple Notification Service デベロッパーガイド](https://docs.aws.amazon.com/sns/latest/dg/)」を参照してください。 **注記** SNS トピックのサブスクリプションを、us-east-1 リージョンでのみ作成します。バージョニングされた AWS マネージドルールルールグループはすべて、同じ SNS トピックの Amazon リソースネーム (ARN) を使用します。 AWS マネージドルールのルールグループ通知の詳細については、「」を参照してください[デプロイ通知](waf-managed-rule-groups-deployments-notifications.md)。 **マネージドルールグループの Amazon SNS トピック ARN を確認できる場所** AWS マネージドルールルールグループは 1 つの SNS トピック ARN を使用するため、いずれかのルールグループからトピック ARN を取得してサブスクライブし、SNS 通知を提供するすべての AWS マネージドルールルールルールグループの通知を取得できます。 + **コンソール** + (オプション) マネージドルールグループを保護パック (ウェブ ACL) に追加する場合は、**[Edit]** (編集) を選択して、ルールグループの Amazon SNS トピック ARN を含むルールグループの情報を表示します。 + (オプション) マネージドルールグループを保護パック (ウェブ ACL) に追加したら、保護パック (ウェブ ACL) で **[Edit]** (編集) を選択し、ルールグループのルールを選択して編集し、ルールグループの Amazon SNS トピック ARN を表示します。 + **API** – `DescribeManagedRuleGroup` + **CLI** – `aws wafv2 describe-managed-rule-group --scope= --vendor-name --name ` Amazon SNS 通知形式に関する一般的な情報と、受信する通知をフィルタリングする方法については、「Amazon Simple Notification Service デベロッパーガイド」の「[メッセージ形式を解析する](https://docs.aws.amazon.com/sns/latest/dg/sns-message-and-json-formats.html)」と「[Amazon SNS サブスクリプションフィルターポリシー](https://docs.aws.amazon.com/sns/latest/dg/sns-subscription-filter-policies.html)」を参照してください。 # ルールグループのバージョンの有効期限の追跡このセクションでは、Amazon CloudWatch を介したマネージドルールグループの有効期限スケジュールをモニタリングする方法について説明します。ルールグループの特定のバージョンを使用する場合は、有効期限切れのバージョンを使用し続けないようにしてください。 **ヒント** マネージドルールグループの Amazon SNS 通知にサインアップし、マネージドルールグループバージョンで最新の状態を維持します。ルールグループからの最新の保護により、有効期限を先取りできます。詳細については、「[新しいバージョンとアップデートの通知を受け取る](waf-using-managed-rule-groups-sns-topic.md)」を参照してください。 **Amazon CloudWatch を使用してマネージドルールグループの有効期限スケジュールをモニタリングするには** 1. CloudWatch で、マネージドルールグループのの有効期限メトリクスを見つけ AWS WAF ます。メトリクスには、以下のメトリック名とディメンションがあります: + メトリクス名: DaysToExpiry + メトリクスのディメンション: Region、ManagedRuleGroup、Vendor、および Version トラフィックを評価する保護パック (ウェブ ACL) にマネージドルールグループがある場合、そのメトリクスが取得されます。このメトリクスは、使用されていないルールグループでは使用できません。 1. 関心のあるメトリクスにアラームを設定して、新しいバージョンのルールグループに切り替えるよう通知を適時に受け取れるようにします。 Amazon CloudWatch メトリクスの使用とアラームの設定については、「[Amazon CloudWatch ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/)」を参照してください。 # JSON および YAML でのマネージドルールグループ設定の例このセクションでは、マネージドルールグループの設定の例を紹介します。 API コールと CLI コールは、JSON モデルまたはで参照できるマネージドルールグループ内のすべてのルールのリストを返します AWS CloudFormation。 **JSON** JSON を使用して、ルールステートメント内でマネージドルールグループを参照および変更できます。次のリストは、 AWS マネージドルールルールグループを JSON 形式で示`AWSManagedRulesCommonRuleSet`しています。RuleActionOverrides 仕様には、アクションが Count にオーバーライドされたルールが一覧表示されています。 ``` { "Name": "AWS-AWSManagedRulesCommonRuleSet", "Priority": 0, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesCommonRuleSet", "RuleActionOverrides": [ { "ActionToUse": { "Count": {} }, "Name": "NoUserAgent_HEADER" } ], "ExcludedRules": [] } }, "OverrideAction": { "None": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSManagedRulesCommonRuleSet" } } ``` **YAML** CloudFormation YAML テンプレートを使用して、ルールステートメント内のマネージドルールグループを参照および変更できます。次のリストは、 `AWSManagedRulesCommonRuleSet` CloudFormation テンプレート内の AWS マネージドルールルールグループを示しています。RuleActionOverrides 仕様には、アクションが Count にオーバーライドされたルールが一覧表示されています。 ``` Name: AWS-AWSManagedRulesCommonRuleSet Priority: 0 Statement: ManagedRuleGroupStatement: VendorName: AWS Name: AWSManagedRulesCommonRuleSet RuleActionOverrides: - ActionToUse: Count: {} Name: NoUserAgent_HEADER ExcludedRules: [] OverrideAction: None: {} VisibilityConfig: SampledRequestsEnabled: true CloudWatchMetricsEnabled: true MetricName: AWS-AWSManagedRulesCommonRuleSet ``` # AWS のマネージドルール AWS WAF このセクションでは、の AWS マネージドルールについて説明します AWS WAF 。 AWS のマネージドルール AWS WAF は、アプリケーションの脆弱性やその他の不要なトラフィックに対する保護を提供するマネージドサービスです。最大保護パック (ウェブ ACL) 容量単位 (WCU) の制限まで、ウェブ ACL ごとに AWS マネージドルールから 1 つ以上のルールグループを選択できます。 **誤検出の軽減とルールグループの変更のテスト** 本番稼働でルールグループを使用する前に、[AWS WAF 保護のテストとチューニング](web-acl-testing.md) にあるガイダンスに従って、非本番稼働環境でテストします。保護パック (ウェブ ACL) にルールグループを追加する場合、新しいバージョンのルールグループをテストする場合、およびルールグループが必要に応じてウェブトラフィックを処理していないときは、テストとチューニングのガイダンスに従ってください。 **セキュリティ責任の共有** AWS マネージドルールは、一般的なウェブ脅威から保護するように設計されています。ドキュメントに従って使用すると、 AWS マネージドルールルールグループはアプリケーションに別のセキュリティレイヤーを追加します。ただし、 AWS マネージドルールルールグループは、選択した AWS リソースによって決定されるセキュリティ責任に代わるものではありません。責任[共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)を参照して、のリソースが適切に保護 AWS されていることを確認します。 **重要** AWS マネージドルールは、一般的なウェブ脅威から保護するように設計されています。ドキュメントに従って使用すると、 AWS マネージドルールルールグループはアプリケーションに別のセキュリティレイヤーを追加します。ただし、 AWS マネージドルールルールグループは、選択した AWS リソースによって決定されるセキュリティ責任に代わるものではありません。責任[共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)を参照して、のリソースが適切に保護 AWS されていることを確認します。 # AWS マネージドルールのルールグループリストこのセクションでは、使用可能な AWS マネージドルールルールグループのリストを示します。このセクションでは、 AWS マネージドルールルールグループの最新バージョンについて説明します。これらの情報は、保護パック (ウェブ ACL) にマネージドルールグループを追加するときにコンソールに表示されます。API を使用して、を呼び出すことで、サブスクライブしている AWS Marketplace ルールグループとともにこのリストを取得できます`ListAvailableManagedRuleGroups`。 **注記** AWS マネージドルールのルールグループのバージョンを取得する方法については、「」を参照してください[マネージドルールグループで使用可能なバージョンの取得](waf-using-managed-rule-groups-versions.md)。すべての AWS マネージドルールルールグループはラベル付けをサポートし、このセクションのルールリストにはラベル仕様が含まれています。`DescribeManagedRuleGroup` を呼び出すことにより、API を介してマネージドルールグループのラベルを取得できます。ラベルは、応答の AvailableLabels プロパティにリストされています。ラベル付けの詳細については、「[でのウェブリクエストのラベル付け AWS WAF](waf-labels.md)」を参照してください。本番トラフィックに使用する前に、 AWS WAF 保護の変更をテストして調整します。詳細については、「[AWS WAF 保護のテストとチューニング](web-acl-testing.md)」を参照してください。 **Contents** + [ # ベースラインルールグループ ](aws-managed-rule-groups-baseline.md) + [ ## コアルールセット (CRS) マネージドルールグループ ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-crs) + [ ## 管理者保護マネージドルールグループ ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-admin) + [ ## 既知の不正な入力マネージドルールグループ ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-known-bad-inputs) + [ # ユースケース固有のルールグループ ](aws-managed-rule-groups-use-case.md) + [ ## SQL データベースマネージドルールグループ ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-sql-db) + [ ## Linux オペレーティングシステムマネージドルールグループ ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-linux-os) + [ ## POSIX オペレーティングシステムマネージドルールグループ ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-posix-os) + [ ## Windows オペレーティングシステムマネージドルールグループ ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-windows-os) + [ ## PHP アプリケーションマネージドルールグループ ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-php-app) + [ ## WordPress アプリケーションマネージドルールグループ ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-wordpress-app) + [ # IP 評価ルールグループ ](aws-managed-rule-groups-ip-rep.md) + [ ## Amazon IP 評価リストマネージドルールグループ ](aws-managed-rule-groups-ip-rep.md#aws-managed-rule-groups-ip-rep-amazon) + [ ## 匿名 IP リストマネージドルールグループ ](aws-managed-rule-groups-ip-rep.md#aws-managed-rule-groups-ip-rep-anonymous) + [ # AWS WAF Fraud Control アカウント作成不正防止 (ACFP) ルールグループ ](aws-managed-rule-groups-acfp.md) + [ ## このルールグループの使用に関する考慮事項 ](aws-managed-rule-groups-acfp.md#aws-managed-rule-groups-acfp-using) + [ ## このルールグループによって追加されるラベル ](aws-managed-rule-groups-acfp.md#aws-managed-rule-groups-acfp-labels) + [ ### トークンラベル ](aws-managed-rule-groups-acfp.md#aws-managed-rule-groups-acfp-labels-token) + [ ### ACFP ラベル ](aws-managed-rule-groups-acfp.md#aws-managed-rule-groups-acfp-labels-rg) + [ ## Account Creation Fraud Prevention ルールリスト ](aws-managed-rule-groups-acfp.md#aws-managed-rule-groups-acfp-rules) + [ # AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループ ](aws-managed-rule-groups-atp.md) + [ ## このルールグループの使用に関する考慮事項 ](aws-managed-rule-groups-atp.md#aws-managed-rule-groups-atp-using) + [ ## このルールグループによって追加されるラベル ](aws-managed-rule-groups-atp.md#aws-managed-rule-groups-atp-labels) + [ ### トークンラベル ](aws-managed-rule-groups-atp.md#aws-managed-rule-groups-atp-labels-token) + [ ### ATP ラベル ](aws-managed-rule-groups-atp.md#aws-managed-rule-groups-atp-labels-rg) + [ ## アカウント乗っ取り防止のルールリスト ](aws-managed-rule-groups-atp.md#aws-managed-rule-groups-atp-rules) + [ # AWS WAF Bot Control ルールグループ ](aws-managed-rule-groups-bot.md) + [ ## 保護レベル ](aws-managed-rule-groups-bot.md#aws-managed-rule-groups-bot-prot-levels) + [ ## このルールグループの使用に関する考慮事項 ](aws-managed-rule-groups-bot.md#aws-managed-rule-groups-bot-using) + [ ## このルールグループによって追加されるラベル ](aws-managed-rule-groups-bot.md#aws-managed-rule-groups-bot-labels) + [ ### トークンラベル ](aws-managed-rule-groups-bot.md#aws-managed-rule-groups-bot-labels-token) + [ ### Bot Control ラベル ](aws-managed-rule-groups-bot.md#aws-managed-rule-groups-bot-labels-rg) + [ ## Bot Control のルールリスト ](aws-managed-rule-groups-bot.md#aws-managed-rule-groups-bot-rules) + [ # AWS WAF 分散サービス拒否 (DDoS) 防止ルールグループ ](aws-managed-rule-groups-anti-ddos.md) + [ ## このルールグループの使用に関する考慮事項 ](aws-managed-rule-groups-anti-ddos.md#aws-managed-rule-groups-anti-ddos-using) + [ ## このルールグループによって追加されるラベル ](aws-managed-rule-groups-anti-ddos.md#aws-managed-rule-groups-anti-ddos-labels) + [ ### トークンラベル ](aws-managed-rule-groups-anti-ddos.md#aws-managed-rule-groups-anti-ddos-labels-token) + [ ### DDoS 対策ラベル ](aws-managed-rule-groups-anti-ddos.md#aws-managed-rule-groups-anti-ddos-labels-rg) + [ ## DDoS 対策ルールのリスト ](aws-managed-rule-groups-anti-ddos.md#aws-managed-rule-groups-anti-ddos-rules) # ベースラインルールグループベースラインマネージドルールグループは、さまざまな一般的な脅威に対する一般的な保護を提供します。これらのルールグループを 1 つ以上選択して、リソースのベースライン保護を確立します。 ## コアルールセット (CRS) マネージドルールグループ VendorName: `AWS`、名前: `AWSManagedRulesCommonRuleSet`、WCU: 700 **注記** このドキュメントでは、このマネージドルールグループの最新の静的バージョンリリースについて説明します。バージョンの変更は、[AWS マネージドルールの変更ログ](aws-managed-rule-groups-changelog.md) の変更ログにレポートされます。他のバージョンの情報については、API コマンド [DescribeManagedRuleGroup](https://docs.aws.amazon.com/waf/latest/APIReference/API_DescribeManagedRuleGroup.html) を使用してください。 AWS マネージドルールルールのルールグループでルール用に公開する情報は、不正なアクターにルールを回避するために必要なものを与えることなく、ルールを使用するために必要なものを提供することを目的としています。ここに記載されている以上の情報が必要な場合は、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/) にお問い合わせください。コアルールセット (CRS) ルールグループには、ウェブアプリケーションに一般的に適用可能なルールが含まれています。これにより、[OWASP Top 10](https://owasp.org/www-project-top-ten/) などの OWASP の出版物に記載されている、リスクが高く一般的に発生するいくつかの脆弱性を含む、さまざまな脆弱性の悪用に対する保護が提供されます。 AWS WAF ユースケースには、このルールグループの使用を検討してください。このマネージドルールグループは、評価対象のウェブリクエストに保護パック (ウェブ ACL) 内のこのルールグループの後に実行されるルールでも使用できるラベルを追加します。 AWS WAF は、Amazon CloudWatch メトリクスにもラベルを記録します。ラベルとラベルメトリクスに関する一般的な情報については、「[ウェブリクエストのラベル付け](waf-labels.md)」および「[ラベルメトリクスとディメンション](waf-metrics.md#waf-metrics-label)」を参照してください。 | ルール名 | 説明とラベル | | --- | --- | | NoUserAgent\$1HEADER | HTTP `User-Agent` ヘッダーが欠落しているリクエストを検査します。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:NoUserAgent_Header` | | UserAgent\$1BadBots\$1HEADER | リクエストが不正なボットであることを示す一般的な `User-Agent` ヘッダー値を検査します。パターンの例には、`nessus`、`nmap` などがあります。ボット管理については、「[AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md)」も参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:BadBots_Header` | | SizeRestrictions\$1QUERYSTRING | 2,048 バイトを超える URI クエリ文字列を検査します。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:SizeRestrictions_QueryString` | | SizeRestrictions\$1Cookie\$1HEADER | 10,240 バイトを超える cookie ヘッダーを検査します。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:SizeRestrictions_Cookie_Header` | | SizeRestrictions\$1BODY | 8 KB (8,192 バイト) を超えるリクエストボディを検査します。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:SizeRestrictions_Body` | | SizeRestrictions\$1URIPATH | 1,024 バイトを超える URI パスを検査します。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:SizeRestrictions_URIPath` | | EC2MetaDataSSRF\$1BODY | リクエストボディから Amazon EC2 メタデータを盗み出す試みがないかを検査します。このルールは、保護パック (ウェブ ACL) とリソースタイプのボディサイズ制限に達するリクエストボディのみを検査します。Application Load Balancer との場合 AWS AppSync、制限は 8 KB に固定されます。CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Access の場合、デフォルトの制限は 16 KB で、保護パック (ウェブ ACL) 設定で制限を最大 64 KB に増やすことができます。このルールは、オーバーサイズコンテンツの処理に `Continue` オプションを使用します。詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:EC2MetaDataSSRF_Body` | | EC2MetaDataSSRF\$1COOKIE | リクエスト cookie から Amazon EC2 メタデータを盗み出す試みがないかを検査します。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:EC2MetaDataSSRF_Cookie` | | EC2MetaDataSSRF\$1URIPATH | リクエスト URI パスから Amazon EC2 メタデータを盗み出す試みがないかを検査します。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:EC2MetaDataSSRF_URIPath` | | EC2MetaDataSSRF\$1QUERYARGUMENTS | リクエストクエリ引数から Amazon EC2 メタデータを盗み出す試みがないかを検査します。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:EC2MetaDataSSRF_QueryArguments` | | GenericLFI\$1QUERYARGUMENTS | クエリ引数に、ローカルファイルインクルージョン (LFI) を悪用する形跡がないかを検査します。例には、`../../` などの手法を使用したパストラバーサルの試行があります。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:GenericLFI_QueryArguments` | | GenericLFI\$1URIPATH | URI パスに、ローカルファイルインクルージョン (LFI) を悪用する形跡がないかを検査します。例には、`../../` などの手法を使用したパストラバーサルの試行があります。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:GenericLFI_URIPath` | | GenericLFI\$1BODY | リクエストボディに、ローカルファイルインクルージョン (LFI) を悪用する形跡がないかを検査します。例には、`../../` などの手法を使用したパストラバーサルの試行があります。このルールは、保護パック (ウェブ ACL) とリソースタイプのボディサイズ制限に達するリクエストボディのみを検査します。Application Load Balancer との場合 AWS AppSync、制限は 8 KB に固定されます。CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Access の場合、デフォルトの制限は 16 KB で、保護パック (ウェブ ACL) 設定で制限を最大 64 KB に増やすことができます。このルールは、オーバーサイズコンテンツの処理に `Continue` オプションを使用します。詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:GenericLFI_Body` | | RestrictedExtensions\$1URIPATH | 読み取りや実行が安全でないシステムファイルの拡張子が URI パスに含まれているリクエストを検査します。パターンの例には、`.log` や `.ini` などの拡張子があります。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:RestrictedExtensions_URIPath` | | RestrictedExtensions\$1QUERYARGUMENTS | クエリ引数に、読み取りや実行が安全でないシステムファイル拡張子が含まれているリクエストを検査します。パターンの例には、`.log` や `.ini` などの拡張子があります。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:RestrictedExtensions_QueryArguments` | | GenericRFI\$1QUERYARGUMENTS | IPv4 アドレスを含む URL を埋め込むことにより、Web アプリケーションでRFI (リモートファイルインクルード) を悪用しようとする試みに対して、すべてのクエリパラメーターの値を検査します。例としては、`http://`、`https://`、`ftp://`、`ftps://`、`file://` などのパターンがあり、悪用の試みに IPv4 ホストヘッダーが含まれています。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:GenericRFI_QueryArguments` | | GenericRFI\$1BODY | IPv4 アドレスを含む URL を埋め込むことにより、ウェブアプリケーションの RFI (リモートファイルインクルージョン) を悪用しようとする試行に対してリクエストボディを検査します。例としては、`http://`、`https://`、`ftp://`、`ftps://`、`file://` などのパターンがあり、悪用の試みに IPv4 ホストヘッダーが含まれています。このルールは、保護パック (ウェブ ACL) とリソースタイプのボディサイズ制限に達するリクエストボディのみを検査します。Application Load Balancer との場合 AWS AppSync、制限は 8 KB に固定されます。CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Access の場合、デフォルトの制限は 16 KB で、保護パック (ウェブ ACL) 設定で制限を最大 64 KB に増やすことができます。このルールは、オーバーサイズコンテンツの処理に `Continue` オプションを使用します。詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:GenericRFI_Body` | | GenericRFI\$1URIPATH | IPv4 アドレスを含む URL を埋め込むことにより、ウェブアプリケーションの RFI (リモートファイルインクルージョン) を悪用しようとする試行に対してURI パスを検査します。例としては、`http://`、`https://`、`ftp://`、`ftps://`、`file://` などのパターンがあり、悪用の試みに IPv4 ホストヘッダーが含まれています。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:GenericRFI_URIPath` | | CrossSiteScripting\$1COOKIE | 組み込みを使用して、一般的なクロスサイトスクリプティング (XSS) パターンの Cookie ヘッダーの値を検査します AWS WAF [クロスサイトスクリプティング攻撃ルールステートメント](waf-rule-statement-type-xss-match.md)。パターンの例には、`` などのスクリプトあります。 AWS WAF ログのルール一致の詳細は、このルールグループのバージョン 2.0 では入力されません。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:CrossSiteScripting_Cookie` | | CrossSiteScripting\$1QUERYARGUMENTS | 組み込みを使用して、一般的なクロスサイトスクリプティング (XSS) パターンのクエリ引数の値を検査します AWS WAF [クロスサイトスクリプティング攻撃ルールステートメント](waf-rule-statement-type-xss-match.md)。パターンの例には、`` などのスクリプトあります。 AWS WAF ログのルール一致の詳細は、このルールグループのバージョン 2.0 では入力されません。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:CrossSiteScripting_QueryArguments` | | CrossSiteScripting\$1BODY | 組み込みを使用して、一般的なクロスサイトスクリプティング (XSS) パターンのリクエストボディを検査します AWS WAF [クロスサイトスクリプティング攻撃ルールステートメント](waf-rule-statement-type-xss-match.md)。パターンの例には、`` などのスクリプトあります。 AWS WAF ログのルール一致の詳細は、このルールグループのバージョン 2.0 では入力されません。このルールは、保護パック (ウェブ ACL) とリソースタイプのボディサイズ制限に達するリクエストボディのみを検査します。Application Load Balancer との場合 AWS AppSync、制限は 8 KB に固定されます。CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Access の場合、デフォルトの制限は 16 KB で、保護パック (ウェブ ACL) 設定で制限を最大 64 KB に増やすことができます。このルールは、オーバーサイズコンテンツの処理に `Continue` オプションを使用します。詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:CrossSiteScripting_Body` | | CrossSiteScripting\$1URIPATH | 組み込みのを使用して、URI パスの値を検査して、一般的なクロスサイトスクリプティング (XSS) パターンを確認します AWS WAF [クロスサイトスクリプティング攻撃ルールステートメント](waf-rule-statement-type-xss-match.md)。パターンの例には、`` などのスクリプトあります。 AWS WAF ログのルール一致の詳細は、このルールグループのバージョン 2.0 では入力されません。ルールアクション: Block ラベル: `awswaf:managed:aws:core-rule-set:CrossSiteScripting_URIPath` | ## 管理者保護マネージドルールグループ VendorName: `AWS`、名前: `AWSManagedRulesAdminProtectionRuleSet`、WCU: 100 **注記** このドキュメントでは、このマネージドルールグループの最新の静的バージョンリリースについて説明します。バージョンの変更は、[AWS マネージドルールの変更ログ](aws-managed-rule-groups-changelog.md) の変更ログにレポートされます。他のバージョンの情報については、API コマンド [DescribeManagedRuleGroup](https://docs.aws.amazon.com/waf/latest/APIReference/API_DescribeManagedRuleGroup.html) を使用してください。 AWS マネージドルールルールのルールグループでルール用に公開する情報は、不正なアクターにルールを回避するために必要なものを与えることなく、ルールを使用するために必要なものを提供することを目的としています。ここに記載されている以上の情報が必要な場合は、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/) にお問い合わせください。管理者保護ルールグループには、公開されている管理ページへの外部アクセスをブロックするためのルールが含まれています。これは、サードパーティーのソフトウェアを実行している場合や、悪意のあるアクターがアプリケーションへの管理アクセスを得るリスクを緩和したい場合に便利です。このマネージドルールグループは、評価対象のウェブリクエストに保護パック (ウェブ ACL) 内のこのルールグループの後に実行されるルールでも使用できるラベルを追加します。 AWS WAF は、Amazon CloudWatch メトリクスにもラベルを記録します。ラベルとラベルメトリクスに関する一般的な情報については、「[ウェブリクエストのラベル付け](waf-labels.md)」および「[ラベルメトリクスとディメンション](waf-metrics.md#waf-metrics-label)」を参照してください。 | ルール名 | 説明とラベル | | --- | --- | | AdminProtection\$1URIPATH | 一般的にウェブサーバーまたはアプリケーションの管理用に確保されている URI パスの有無を検査します。パターンの例には、`sqlmanager` などがあります。ルールアクション: Block ラベル: `awswaf:managed:aws:admin-protection:AdminProtection_URIPath` | ## 既知の不正な入力マネージドルールグループ VendorName: `AWS`、名前: `AWSManagedRulesKnownBadInputsRuleSet`、WCU: 200 **注記** このドキュメントでは、このマネージドルールグループの最新の静的バージョンリリースについて説明します。バージョンの変更は、[AWS マネージドルールの変更ログ](aws-managed-rule-groups-changelog.md) の変更ログにレポートされます。他のバージョンの情報については、API コマンド [DescribeManagedRuleGroup](https://docs.aws.amazon.com/waf/latest/APIReference/API_DescribeManagedRuleGroup.html) を使用してください。 AWS マネージドルールルールのルールグループでルール用に公開する情報は、不正なアクターにルールを回避するために必要なものを与えることなく、ルールを使用するために必要なものを提供することを目的としています。ここに記載されている以上の情報が必要な場合は、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/) にお問い合わせください。既知の不正な入力ルールグループには、無効であることがわかっており脆弱性の悪用または発見に関連するリクエストパターンをブロックするルールが含まれています。これにより、悪意のあるアクターが脆弱なアプリケーションを発見するリスクを緩和できます。このマネージドルールグループは、評価対象のウェブリクエストに保護パック (ウェブ ACL) 内のこのルールグループの後に実行されるルールでも使用できるラベルを追加します。 AWS WAF は、Amazon CloudWatch メトリクスにもラベルを記録します。ラベルとラベルメトリクスに関する一般的な情報については、「[ウェブリクエストのラベル付け](waf-labels.md)」および「[ラベルメトリクスとディメンション](waf-metrics.md#waf-metrics-label)」を参照してください。 | ルール名 | 説明とラベル | | --- | --- | | JavaDeserializationRCE\$1HEADER | HTTP リクエストヘッダーのキーと値に、Spring Core および Cloud Function RCE の脆弱性 (CVE-2022-22963、CVE-2022-22965) などの Java デシリアライゼーション Remote Command Execution (RCE) の試行を示すパターンがないかどうかを検査します。パターンの例には、`(java.lang.Runtime).getRuntime().exec("whoami")` などがあります。このルールは、リクエストヘッダーの最初の 8 KB または最初の 200 個のヘッダーのうち、いずれかの制限に先に達した方のみを検査し、オーバーサイズコンテンツの処理に `Continue` オプションを使用します。詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:known-bad-inputs:JavaDeserializationRCE_Header` | | JavaDeserializationRCE\$1BODY | リクエスト本文で、Spring Core および Cloud Function RCE の脆弱性 (CVE-2022-22963、CVE-2022-22965) などの Java デシリアライゼーション Remote Command Execution (RCE) の試行を示すパターンがないかどうかを検査します。パターンの例には、`(java.lang.Runtime).getRuntime().exec("whoami")` などがあります。このルールは、保護パック (ウェブ ACL) とリソースタイプのボディサイズ制限に達するリクエストボディのみを検査します。Application Load Balancer との場合 AWS AppSync、制限は 8 KB に固定されます。CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Access の場合、デフォルトの制限は 16 KB で、保護パック (ウェブ ACL) 設定で制限を最大 64 KB に増やすことができます。このルールは、オーバーサイズコンテンツの処理に `Continue` オプションを使用します。詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:known-bad-inputs:JavaDeserializationRCE_Body` | | JavaDeserializationRCE\$1URIPATH | リクエスト URI で、Spring Core および Cloud Function RCE の脆弱性 (CVE-2022-22963、CVE-2022-22965) などの Java デシリアライゼーション Remote Command Execution (RCE) の試行を示すパターンがないかどうかを検査します。パターンの例には、`(java.lang.Runtime).getRuntime().exec("whoami")` などがあります。ルールアクション: Block ラベル: `awswaf:managed:aws:known-bad-inputs:JavaDeserializationRCE_URIPath` | | JavaDeserializationRCE\$1QUERYSTRING | リクエストクエリ文字列で、Spring Core および Cloud Function RCE の脆弱性 (CVE-2022-22963、CVE-2022-22965) などの Java デシリアライゼーション Remote Command Execution (RCE) の試行を示すパターンがないかどうかを検査します。パターンの例には、`(java.lang.Runtime).getRuntime().exec("whoami")` などがあります。ルールアクション: Block ラベル: `awswaf:managed:aws:known-bad-inputs:JavaDeserializationRCE_QueryString` | | Host\$1localhost\$1HEADER | リクエストのホストヘッダーに、localhost を示すパターンがないかを検査します。パターンの例には、`localhost` などがあります。ルールアクション: Block ラベル: `awswaf:managed:aws:known-bad-inputs:Host_Localhost_Header` | | PROPFIND\$1METHOD | リクエストの HTTP メソッドに、`PROPFIND` がないかを検査します。このメソッドは `HEAD` と同様ですが、XML オブジェクトを抽出しようとする点が異なります。ルールアクション: Block ラベル: `awswaf:managed:aws:known-bad-inputs:Propfind_Method` | | ExploitablePaths\$1URIPATH | URI パスに、悪用可能なウェブアプリケーションパスにアクセスする試みがないかを検査します。パターンの例には、`web-inf` などのパスがあります。ルールアクション: Block ラベル: `awswaf:managed:aws:known-bad-inputs:ExploitablePaths_URIPath` | | Log4JRCE\$1HEADER | リクエストヘッダーのキーと値に Log4j の脆弱性 ([CVE-2021-44228](https://www.cve.org/CVERecord?id=CVE-2021-44228)、[CVE-2021-45046](https://www.cve.org/CVERecord?id=CVE-2021-45046)、[CVE-2021-45105](https://www.cve.org/CVERecord?id=CVE-2021-45105)) の存在の有無を検査し、Remote Code Execution (RCE) の試行から保護します。パターンの例には、`${jndi:ldap://example.com/}` などがあります。このルールは、リクエストヘッダーの最初の 8 KB または最初の 200 個のヘッダーのうち、いずれかの制限に先に達した方のみを検査し、オーバーサイズコンテンツの処理に `Continue` オプションを使用します。詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:known-bad-inputs:Log4JRCE_Header` | | Log4JRCE\$1QUERYSTRING | クエリ文字列に Log4j の脆弱性 ([CVE-2021-44228](https://www.cve.org/CVERecord?id=CVE-2021-44228)、[CVE-2021-45046](https://www.cve.org/CVERecord?id=CVE-2021-45046)、[CVE-2021-45105](https://www.cve.org/CVERecord?id=CVE-2021-45105)) の存在の有無を検査し、Remote Code Execution (RCE) の試行から保護します。パターンの例には、`${jndi:ldap://example.com/}` などがあります。ルールアクション: Block ラベル: `awswaf:managed:aws:known-bad-inputs:Log4JRCE_QueryString` | | Log4JRCE\$1BODY | 本文に Log4j の脆弱性 ([CVE-2021-44228](https://www.cve.org/CVERecord?id=CVE-2021-44228)、[CVE-2021-45046](https://www.cve.org/CVERecord?id=CVE-2021-45046)、[CVE-2021-45105](https://www.cve.org/CVERecord?id=CVE-2021-45105)) の存在の有無を検査し、Remote Code Execution (RCE) の試行から保護します。パターンの例には、`${jndi:ldap://example.com/}` などがあります。このルールは、保護パック (ウェブ ACL) とリソースタイプのボディサイズ制限に達するリクエストボディのみを検査します。Application Load Balancer との場合 AWS AppSync、制限は 8 KB に固定されます。CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Access の場合、デフォルトの制限は 16 KB で、保護パック (ウェブ ACL) 設定で制限を最大 64 KB に増やすことができます。このルールは、オーバーサイズコンテンツの処理に `Continue` オプションを使用します。詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:known-bad-inputs:Log4JRCE_Body` | | Log4JRCE\$1URIPATH | URI パスに Log4j の脆弱性 ([CVE-2021-44228](https://www.cve.org/CVERecord?id=CVE-2021-44228)、[CVE-2021-45046](https://www.cve.org/CVERecord?id=CVE-2021-45046)、[CVE-2021-45105](https://www.cve.org/CVERecord?id=CVE-2021-45105)) の存在の有無を検査し、Remote Code Execution (RCE) の試行から保護します。パターンの例には、`${jndi:ldap://example.com/}` などがあります。ルールアクション: Block ラベル: `awswaf:managed:aws:known-bad-inputs:Log4JRCE_URIPath` | | ReactJSRCE\$1BODY | CVE-2025-55182 の存在を示すパターンについて、リクエスト本文を検査します。このルールは、保護パック (ウェブ ACL) とリソースタイプのボディサイズ制限に達するリクエストボディのみを検査します。Application Load Balancer と AWS AppSyncの場合、その制限は 8 KB に固定されます。CloudFront、API Gateway、Amazon Cognito、App Runner、 AWS Verified Access の場合、デフォルトの制限は 16 KB であり、保護パック (ウェブ ACL) 設定で制限を最大 64 KB に増やすことができます。このルールは、オーバーサイズコンテンツの処理に `CONTINUE` オプションを使用します。詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:known-bad-inputs:ReactJSRCE_Body` | # ユースケース固有のルールグループユースケース固有のルールグループは、さまざまな AWS WAF ユースケースに対して段階的な保護を提供します。アプリケーションに適用するルールグループを選択します。 ## SQL データベースマネージドルールグループ VendorName: `AWS`、名前: `AWSManagedRulesSQLiRuleSet`、WCU: 200 **注記** このドキュメントでは、このマネージドルールグループの最新の静的バージョンリリースについて説明します。バージョンの変更は、[AWS マネージドルールの変更ログ](aws-managed-rule-groups-changelog.md) の変更ログにレポートされます。他のバージョンの情報については、API コマンド [DescribeManagedRuleGroup](https://docs.aws.amazon.com/waf/latest/APIReference/API_DescribeManagedRuleGroup.html) を使用してください。 AWS マネージドルールルールのルールグループでルール用に公開する情報は、ルールを回避するために必要なものを不正なアクターに与えることなく、ルールを使用するために必要なものを提供することを目的としています。ここに記載されている以上の情報が必要な場合は、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/) にお問い合わせください。 SQL Database ルールグループには、SQL インジェクション攻撃などの SQL データベースの悪用に関連するリクエストパターンをブロックするルールが含まれています。これにより、不正なクエリのリモートインジェクションを防ぐことができます。アプリケーションが SQL データベースと連結している場合は、このルールグループを評価します。このマネージドルールグループは、評価対象のウェブリクエストに保護パック (ウェブ ACL) 内のこのルールグループの後に実行されるルールでも使用できるラベルを追加します。 AWS WAF は、Amazon CloudWatch メトリクスにもラベルを記録します。ラベルとラベルメトリクスに関する一般的な情報については、「[ウェブリクエストのラベル付け](waf-labels.md)」および「[ラベルメトリクスとディメンション](waf-metrics.md#waf-metrics-label)」を参照してください。 | ルール名 | 説明とラベル | | --- | --- | | SQLi\$1QUERYARGUMENTS | 組み込みのを使用し AWS WAF [SQL インジェクション攻撃ルールステートメント](waf-rule-statement-type-sqli-match.md)、機密レベルをに設定してLow、悪意のある SQL コードに一致するパターンがないか、すべてのクエリパラメータの値を検査します。ルールアクション: Block ラベル: `awswaf:managed:aws:sql-database:SQLi_QueryArguments` | | SQLiExtendedPatterns\$1QUERYARGUMENTS | すべてのクエリパラメータの値に、悪意のある SQL コードに一致するパターンがないかを検査します。このルールが検査するパターンは、ルール `SQLi_QUERYARGUMENTS` の対象外です。ルールアクション: Block ラベル: `awswaf:managed:aws:sql-database:SQLiExtendedPatterns_QueryArguments` | | SQLi\$1BODY | 組み込みのを使用し AWS WAF [SQL インジェクション攻撃ルールステートメント](waf-rule-statement-type-sqli-match.md)、機密レベルをに設定してLow、悪意のある SQL コードに一致するパターンがないかリクエストボディを検査します。このルールは、保護パック (ウェブ ACL) とリソースタイプのボディサイズ制限に達するリクエストボディのみを検査します。Application Load Balancer との場合 AWS AppSync、制限は 8 KB に固定されます。CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Access の場合、デフォルトの制限は 16 KB で、保護パック (ウェブ ACL) 設定で制限を最大 64 KB に増やすことができます。このルールは、オーバーサイズコンテンツの処理に `Continue` オプションを使用します。詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:sql-database:SQLi_Body` | | SQLiExtendedPatterns\$1BODY | リクエストボディに、悪意のある SQL コードに一致するパターンがないかを検査します。このルールが検査するパターンは、ルール `SQLi_BODY` の対象外です。このルールは、保護パック (ウェブ ACL) とリソースタイプのボディサイズ制限に達するリクエストボディのみを検査します。Application Load Balancer との場合 AWS AppSync、制限は 8 KB に固定されます。CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Access の場合、デフォルトの制限は 16 KB で、保護パック (ウェブ ACL) 設定で制限を最大 64 KB に増やすことができます。このルールは、オーバーサイズコンテンツの処理に `Continue` オプションを使用します。詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:sql-database:SQLiExtendedPatterns_Body` | | SQLi\$1COOKIE | 組み込みのを使用し AWS WAF [SQL インジェクション攻撃ルールステートメント](waf-rule-statement-type-sqli-match.md)、機密レベルをに設定してLow、悪意のある SQL コードに一致するパターンがないかリクエスト Cookie ヘッダーを検査します。ルールアクション: Block ラベル: `awswaf:managed:aws:sql-database:SQLi_Cookie` | | SQLi\$1URIPATH | 組み込みのを使用し AWS WAF [SQL インジェクション攻撃ルールステートメント](waf-rule-statement-type-sqli-match.md)、機密レベルをに設定してLow、悪意のある SQL コードに一致するパターンがないかリクエスト Cookie ヘッダーを検査します。ルールアクション: Block ラベル: `awswaf:managed:aws:sql-database:SQLi_URIPath` | ## Linux オペレーティングシステムマネージドルールグループ VendorName: `AWS`、名前: `AWSManagedRulesLinuxRuleSet`、WCU: 200 **注記** このドキュメントでは、このマネージドルールグループの最新の静的バージョンリリースについて説明します。バージョンの変更は、[AWS マネージドルールの変更ログ](aws-managed-rule-groups-changelog.md) の変更ログにレポートされます。他のバージョンの情報については、API コマンド [DescribeManagedRuleGroup](https://docs.aws.amazon.com/waf/latest/APIReference/API_DescribeManagedRuleGroup.html) を使用してください。 AWS マネージドルールルールのルールグループでルール用に公開する情報は、ルールを回避するために必要なものを不正なアクターに与えることなく、ルールを使用するために必要なものを提供することを目的としています。ここに記載されている以上の情報が必要な場合は、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/) にお問い合わせください。 Linux オペレーティングシステムルールグループには、Linux 固有のローカルファイルインクルージョン (LFI) 攻撃など、Linux 固有の脆弱性の悪用に関連するリクエストパターンをブロックするルールが含まれています。これにより、攻撃者がアクセスしてはならないファイルの内容を公開したり、コードを実行したりする攻撃を防ぐことができます。アプリケーションの一部が Linux で実行されている場合は、このルールグループを評価する必要があります。このルールグループは、[POSIX オペレーティングシステム](#aws-managed-rule-groups-use-case-posix-os) ルールグループと組み合わせて使用する必要があります。このマネージドルールグループは、評価対象のウェブリクエストに保護パック (ウェブ ACL) 内のこのルールグループの後に実行されるルールでも使用できるラベルを追加します。 AWS WAF は、Amazon CloudWatch メトリクスにもラベルを記録します。ラベルとラベルメトリクスに関する一般的な情報については、「[ウェブリクエストのラベル付け](waf-labels.md)」および「[ラベルメトリクスとディメンション](waf-metrics.md#waf-metrics-label)」を参照してください。 | ルール名 | 説明とラベル | | --- | --- | | LFI\$1URIPATH | リクエストパスに、ウェブアプリケーションのローカルファイルインクルージョン (LFI) の脆弱性を悪用する試みがないかを検査します。パターンの例には、攻撃者にオペレーティングシステムの情報を提供できる `/proc/version` などのファイルがあります。ルールアクション: Block ラベル: `awswaf:managed:aws:linux-os:LFI_URIPath` | | LFI\$1QUERYSTRING | クエリ文字列の値に、ウェブアプリケーションのローカルファイルインクルージョン (LFI) の脆弱性を悪用する試みがないかを検査します。パターンの例には、攻撃者にオペレーティングシステムの情報を提供できる `/proc/version` などのファイルがあります。ルールアクション: Block ラベル: `awswaf:managed:aws:linux-os:LFI_QueryString` | | LFI\$1HEADER | リクエストヘッダーに、ウェブアプリケーションのローカルファイルインクルージョン (LFI) の脆弱性を悪用する試みの有無を検査します。パターンの例には、攻撃者にオペレーティングシステムの情報を提供できる `/proc/version` などのファイルがあります。このルールは、リクエストヘッダーの最初の 8 KB または最初の 200 個のヘッダーのうち、いずれかの制限に先に達した方のみを検査し、オーバーサイズコンテンツの処理に `Continue` オプションを使用します。詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:linux-os:LFI_Header` | ## POSIX オペレーティングシステムマネージドルールグループ VendorName: `AWS`、名前: `AWSManagedRulesUnixRuleSet`、WCU: 100 **注記** このドキュメントでは、このマネージドルールグループの最新の静的バージョンリリースについて説明します。バージョンの変更は、[AWS マネージドルールの変更ログ](aws-managed-rule-groups-changelog.md) の変更ログにレポートされます。他のバージョンの情報については、API コマンド [DescribeManagedRuleGroup](https://docs.aws.amazon.com/waf/latest/APIReference/API_DescribeManagedRuleGroup.html) を使用してください。 AWS マネージドルールルールのルールグループでルール用に公開する情報は、ルールを回避するために必要なものを不正なアクターに与えることなく、ルールを使用するために必要なものを提供することを目的としています。ここに記載されている以上の情報が必要な場合は、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/) にお問い合わせください。 POSIX オペレーティングシステムルールグループには、POSIX および POSIX と同等のオペレーティングシステムに固有の脆弱性の悪用 (ローカルファイルインクルージョン (LFI) 攻撃など) に関連するリクエストパターンをブロックするルールが含まれています。これにより、攻撃者がアクセスしてはならないファイルの内容を公開したり、コードを実行したりする攻撃を防ぐことができます。アプリケーションの一部が POSIX または POSIX と同等のオペレーティングシステム (Linux、AIX、HP-UX、macOS、Solaris、FreeBSD、OpenBSD など) で実行されている場合は、このルールグループを評価する必要があります。このマネージドルールグループは、評価対象のウェブリクエストに保護パック (ウェブ ACL) 内のこのルールグループの後に実行されるルールでも使用できるラベルを追加します。 AWS WAF は、Amazon CloudWatch メトリクスにもラベルを記録します。ラベルとラベルメトリクスに関する一般的な情報については、「[ウェブリクエストのラベル付け](waf-labels.md)」および「[ラベルメトリクスとディメンション](waf-metrics.md#waf-metrics-label)」を参照してください。 | ルール名 | 説明とラベル | | --- | --- | | UNIXShellCommandsVariables\$1QUERYSTRING | Unix システム上で動作するウェブアプリケーションにおいて、コマンドインジェクション、LFI、およびパストラバーサルの脆弱性を悪用しようとする試みを検出するために、クエリ文字列の値を検査します。パターンの例には、`echo $HOME` や `echo $PATH` などがあります。ルールアクション: Block ラベル: `awswaf:managed:aws:posix-os:UNIXShellCommandsVariables_QueryString` | | UNIXShellCommandsVariables\$1BODY | リクエストボディに、Unix システムで実行されるウェブアプリケーションのコマンドインジェクション、LFI、パストラバーサルの脆弱性を悪用する試みがないかを検査します。パターンの例には、`echo $HOME` や `echo $PATH` などがあります。このルールは、保護パック (ウェブ ACL) とリソースタイプのボディサイズ制限に達するリクエストボディのみを検査します。Application Load Balancer との場合 AWS AppSync、制限は 8 KB に固定されます。CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Access の場合、デフォルトの制限は 16 KB で、保護パック (ウェブ ACL) 設定で制限を最大 64 KB に増やすことができます。このルールは、オーバーサイズコンテンツの処理に `Continue` オプションを使用します。詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:posix-os:UNIXShellCommandsVariables_Body` | | UNIXShellCommandsVariables\$1HEADER | すべてのリクエストヘッダーに、Unix システムで実行されるウェブアプリケーションのコマンドインジェクション、LFI、パストラバーサルの脆弱性を悪用する試みがないかを検査します。パターンの例には、`echo $HOME` や `echo $PATH` などがあります。このルールは、リクエストヘッダーの最初の 8 KB または最初の 200 個のヘッダーのうち、いずれかの制限に先に達した方のみを検査し、オーバーサイズコンテンツの処理に `Continue` オプションを使用します。詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:posix-os:UNIXShellCommandsVariables_Header` | ## Windows オペレーティングシステムマネージドルールグループ VendorName: `AWS`、名前: `AWSManagedRulesWindowsRuleSet`、WCU: 200 **注記** このドキュメントでは、このマネージドルールグループの最新の静的バージョンリリースについて説明します。バージョンの変更は、[AWS マネージドルールの変更ログ](aws-managed-rule-groups-changelog.md) の変更ログにレポートされます。他のバージョンの情報については、API コマンド [DescribeManagedRuleGroup](https://docs.aws.amazon.com/waf/latest/APIReference/API_DescribeManagedRuleGroup.html) を使用してください。 AWS マネージドルールルールのルールグループでルール用に公開する情報は、ルールを回避するために必要なものを不正なアクターに与えることなく、ルールを使用するために必要なものを提供することを目的としています。ここに記載されている以上の情報が必要な場合は、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/) にお問い合わせください。 Windows オペレーティングシステムのルールグループには、PowerShell コマンドのリモート実行など、Windows 固有の脆弱性の悪用に関連するリクエストパターンをブロックするルールが含まれています。これにより、攻撃者が不正なコマンドまたは悪意のあるコードを実行できる脆弱性の悪用を防ぐことができます。アプリケーションの一部が Windows オペレーティングシステムで実行されている場合は、このルールグループを評価します。このマネージドルールグループは、評価対象のウェブリクエストに保護パック (ウェブ ACL) 内のこのルールグループの後に実行されるルールでも使用できるラベルを追加します。 AWS WAF は、Amazon CloudWatch メトリクスにもラベルを記録します。ラベルとラベルメトリクスに関する一般的な情報については、「[ウェブリクエストのラベル付け](waf-labels.md)」および「[ラベルメトリクスとディメンション](waf-metrics.md#waf-metrics-label)」を参照してください。 | ルール名 | 説明とラベル | | --- | --- | | WindowsShellCommands\$1COOKIE | ウェブアプリケーションでの WindowsShell コマンドインジェクションの試行についてリクエスト cookie ヘッダーを検査します。一致パターンは WindowsShell コマンドを表します。パターンの例には、`\|\|nslookup`、`;cmd` などがあります。ルールアクション: Block ラベル: `awswaf:managed:aws:windows-os:WindowsShellCommands_Cookie` | | WindowsShellCommands\$1QUERYARGUMENTS | ウェブアプリケーションでの WindowsShell コマンドインジェクションの試行についてすべてのクエリパラメータの値を検査します。一致パターンは WindowsShell コマンドを表します。パターンの例には、`\|\|nslookup`、`;cmd` などがあります。ルールアクション: Block ラベル: `awswaf:managed:aws:windows-os:WindowsShellCommands_QueryArguments` | | WindowsShellCommands\$1BODY | ウェブアプリケーションでの WindowsShell コマンドインジェクションの試行についてリクエストボディの値を検査します。一致パターンは WindowsShell コマンドを表します。パターンの例には、`\|\|nslookup`、`;cmd` などがあります。このルールは、保護パック (ウェブ ACL) とリソースタイプのボディサイズ制限に達するリクエストボディのみを検査します。Application Load Balancer との場合 AWS AppSync、制限は 8 KB に固定されます。CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Access の場合、デフォルトの制限は 16 KB で、保護パック (ウェブ ACL) 設定で制限を最大 64 KB に増やすことができます。このルールは、オーバーサイズコンテンツの処理に `Continue` オプションを使用します。詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:windows-os:WindowsShellCommands_Body` | | PowerShellCommands\$1COOKIE | ウェブアプリケーションでの PowerShell コマンドインジェクションの試行についてリクエスト cookie を検査します。一致パターンは PowerShell コマンドを表します。例えば、`Invoke-Expression`。ルールアクション: Block ラベル: `awswaf:managed:aws:windows-os:PowerShellCommands_Cookie` | | PowerShellCommands\$1QUERYARGUMENTS | ウェブアプリケーションでの PowerShell コマンドインジェクションの試行についてすべてのクエリパラメータの値を検査します。一致パターンは PowerShell コマンドを表します。例えば、`Invoke-Expression`。ルールアクション: Block ラベル: `awswaf:managed:aws:windows-os:PowerShellCommands_QueryArguments` | | PowerShellCommands\$1BODY | ウェブアプリケーションでの PowerShell コマンドインジェクションの試行についてリクエストボディを検査します。一致パターンは PowerShell コマンドを表します。例えば、`Invoke-Expression`。このルールは、保護パック (ウェブ ACL) とリソースタイプのボディサイズ制限に達するリクエストボディのみを検査します。Application Load Balancer との場合 AWS AppSync、制限は 8 KB に固定されます。CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Access の場合、デフォルトの制限は 16 KB で、保護パック (ウェブ ACL) 設定で制限を最大 64 KB に増やすことができます。このルールは、オーバーサイズコンテンツの処理に `Continue` オプションを使用します。詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:windows-os:PowerShellCommands_Body` | ## PHP アプリケーションマネージドルールグループ VendorName: `AWS`、名前: `AWSManagedRulesPHPRuleSet`、WCU: 100 **注記** このドキュメントでは、このマネージドルールグループの最新の静的バージョンリリースについて説明します。バージョンの変更は、[AWS マネージドルールの変更ログ](aws-managed-rule-groups-changelog.md) の変更ログにレポートされます。他のバージョンの情報については、API コマンド [DescribeManagedRuleGroup](https://docs.aws.amazon.com/waf/latest/APIReference/API_DescribeManagedRuleGroup.html) を使用してください。 AWS マネージドルールルールのルールグループでルール用に公開する情報は、ルールを回避するために必要なものを不正なアクターに与えることなく、ルールを使用するために必要なものを提供することを目的としています。ここに記載されている以上の情報が必要な場合は、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/) にお問い合わせください。 PHP アプリケーションルールグループには、安全でない PHP 関数のインジェクションなど、PHP プログラミング言語の使用に固有の脆弱性の悪用に関連するリクエストパターンをブロックするルールが含まれています。これにより、攻撃者が許可されていないコードまたはコマンドを遠隔で実行できる脆弱性の悪用を防ぐことができます。アプリケーションが連結するサーバーに PHP がインストールされている場合は、このルールグループを評価します。このマネージドルールグループは、評価対象のウェブリクエストに保護パック (ウェブ ACL) 内のこのルールグループの後に実行されるルールでも使用できるラベルを追加します。 AWS WAF は、Amazon CloudWatch メトリクスにもラベルを記録します。ラベルとラベルメトリクスに関する一般的な情報については、「[ウェブリクエストのラベル付け](waf-labels.md)」および「[ラベルメトリクスとディメンション](waf-metrics.md#waf-metrics-label)」を参照してください。 | ルール名 | 説明とラベル | | --- | --- | | PHPHighRiskMethodsVariables\$1HEADER | PHP スクリプトコードインジェクションの試行について、すべてのヘッダーを検査します。パターンの例には、`fsockopen` や `$_GET` スーパーグローバル変数などの関数があります。このルールは、リクエストヘッダーの最初の 8 KB または最初の 200 個のヘッダーのうち、いずれかの制限に先に達した方のみを検査し、オーバーサイズコンテンツの処理に `Continue` オプションを使用します。詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:php-app:PHPHighRiskMethodsVariables_Header` | | PHPHighRiskMethodsVariables\$1QUERYSTRING | リクエスト URL の最初の `?` 以降をすべて検査し、PHP スクリプトコードインジェクションの試行がないかを調べます。パターンの例には、`fsockopen` や `$_GET` スーパーグローバル変数などの関数があります。ルールアクション: Block ラベル: `awswaf:managed:aws:php-app:PHPHighRiskMethodsVariables_QueryString` | | PHPHighRiskMethodsVariables\$1BODY | リクエストボディの値に、PHP スクリプトコードインジェクションがないかを検査します。パターンの例には、`fsockopen` や `$_GET` スーパーグローバル変数などの関数があります。このルールは、保護パック (ウェブ ACL) とリソースタイプのボディサイズ制限に達するリクエストボディのみを検査します。Application Load Balancer との場合 AWS AppSync、制限は 8 KB に固定されます。CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Access の場合、デフォルトの制限は 16 KB で、保護パック (ウェブ ACL) 設定で制限を最大 64 KB に増やすことができます。このルールは、オーバーサイズコンテンツの処理に `Continue` オプションを使用します。詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:php-app:PHPHighRiskMethodsVariables_Body` | | PHPHighRiskMethodsVariables\$1URIPATH | PHP スクリプトコードの挿入試行のリクエストパスを検査します。パターンの例には、`fsockopen` や `$_GET` スーパーグローバル変数などの関数があります。ルールアクション: Block ラベル: `awswaf:managed:aws:php-app:PHPHighRiskMethodsVariables_URIPath` | ## WordPress アプリケーションマネージドルールグループ VendorName: `AWS`、名前: `AWSManagedRulesWordPressRuleSet`、WCU: 100 **注記** このドキュメントでは、このマネージドルールグループの最新の静的バージョンリリースについて説明します。バージョンの変更は、[AWS マネージドルールの変更ログ](aws-managed-rule-groups-changelog.md) の変更ログにレポートされます。他のバージョンの情報については、API コマンド [DescribeManagedRuleGroup](https://docs.aws.amazon.com/waf/latest/APIReference/API_DescribeManagedRuleGroup.html) を使用してください。 AWS マネージドルールルールのルールグループでルール用に公開する情報は、ルールを回避するために必要なものを不正なアクターに与えることなく、ルールを使用するために必要なものを提供することを目的としています。ここに記載されている以上の情報が必要な場合は、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/) にお問い合わせください。 WordPress アプリケーションルールグループには、WordPress サイト固有の脆弱性の悪用に関連するリクエストパターンをブロックするルールが含まれています。WordPress を実行している場合は、このルールグループを評価する必要があります。このルールグループは、[SQL データベース](#aws-managed-rule-groups-use-case-sql-db) および [PHP アプリケーション](#aws-managed-rule-groups-use-case-php-app) ルールグループと組み合わせて使用する必要があります。このマネージドルールグループは、評価対象のウェブリクエストに保護パック (ウェブ ACL) 内のこのルールグループの後に実行されるルールでも使用できるラベルを追加します。 AWS WAF は、Amazon CloudWatch メトリクスにもラベルを記録します。ラベルとラベルメトリクスに関する一般的な情報については、「[ウェブリクエストのラベル付け](waf-labels.md)」および「[ラベルメトリクスとディメンション](waf-metrics.md#waf-metrics-label)」を参照してください。 | ルール名 | 説明とラベル | | --- | --- | | WordPressExploitableCommands\$1QUERYSTRING | リクエストクエリ文字列に、脆弱なインストールまたはプラグインで悪用される可能性のある高リスクの WordPress コマンドがないかを検査します。パターンの例には、`do-reset-wordpress` などのコマンドがあります。ルールアクション: Block ラベル: `awswaf:managed:aws:wordpress-app:WordPressExploitableCommands_QUERYSTRING` | | WordPressExploitablePaths\$1URIPATH | リクエストの URI パスに、脆弱性が簡単に悪用されることがわかっている `xmlrpc.php` などの WordPress ファイルがないかを検査します。ルールアクション: Block ラベル: `awswaf:managed:aws:wordpress-app:WordPressExploitablePaths_URIPATH` | # IP 評価ルールグループ IP 評価ルールグループはソース IP アドレスに基づいてリクエストをブロックします。 **注記** これらのルールは、ウェブリクエストの発信元のソース IP アドレスを使用します。トラフィックが 1 つ以上のプロキシまたはロードバランサーを通過する場合、ウェブリクエストの発信元には、クライアントの発信アドレスではなく、最後のプロキシのアドレスが含まれます。ボットトラフィックや悪用の試みを緩和する場合、またはコンテンツに地理的制限を適用する場合は、これらのルールグループを 1 つ以上選択します。ボット管理については、「[AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md)」も参照してください。このカテゴリのルールグループは、バージョニングや SNS 更新通知を提供しません。 ## Amazon IP 評価リストマネージドルールグループ VendorName: `AWS`、名前: `AWSManagedRulesAmazonIpReputationList`、WCU: 25 **注記** AWS マネージドルールルールのルールグループでルール用に公開する情報は、ルールを回避するために必要なものを不正なアクターに与えることなく、ルールを使用するために必要なものを提供することを目的としています。ここに記載されている以上の情報が必要な場合は、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/) にお問い合わせください。 Amazon IP 評価リストルールグループには、Amazon 内部脅威インテリジェンスに基づくルールが含まれています。これは、通常、ボットやその他の脅威に関連付けられている IP アドレスをブロックする場合に便利です。これらの IP アドレスをブロックすることで、ボットを緩和し、悪意のあるアクターが脆弱なアプリケーションを発見するリスクを緩和できます。このマネージドルールグループは、評価対象のウェブリクエストに保護パック (ウェブ ACL) 内のこのルールグループの後に実行されるルールでも使用できるラベルを追加します。 AWS WAF は、Amazon CloudWatch メトリクスにもラベルを記録します。ラベルとラベルメトリクスに関する一般的な情報については、「[ウェブリクエストのラベル付け](waf-labels.md)」および「[ラベルメトリクスとディメンション](waf-metrics.md#waf-metrics-label)」を参照してください。 | ルール名 | 説明とラベル | | --- | --- | | AWSManagedIPReputationList | 悪意のあるアクティビティに積極的に関与していると特定された IP アドレスを検査します。 AWS WAF は、Amazon がサイバー犯罪から顧客を保護するために使用する脅威インテリジェンスツールである MadPot など、さまざまなソースから IP アドレスリストを収集します。MadPot の詳細については、[https://www.aboutamazon.com/news/aws/amazon-madpot-stops-cybersecurity-crime](https://www.aboutamazon.com/news/aws/amazon-madpot-stops-cybersecurity-crime) を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:amazon-ip-list:AWSManagedIPReputationList` | | AWSManagedReconnaissanceList | AWS リソースに対して偵察を実行している IP アドレスからの接続を検査します。ルールアクション: Block ラベル: `awswaf:managed:aws:amazon-ip-list:AWSManagedReconnaissanceList` | | AWSManagedIPDDoSList | DDoS アクティビティにアクティブに関与していると識別された IP アドレスを検査します。ルールアクション: Count ラベル: `awswaf:managed:aws:amazon-ip-list:AWSManagedIPDDoSList` | ## 匿名 IP リストマネージドルールグループ VendorName: `AWS`、名前: `AWSManagedRulesAnonymousIpList`、WCU: 50 **注記** AWS マネージドルールルールのルールグループでルール用に公開する情報は、ルールを回避するために必要なものを不正なアクターに与えることなく、ルールを使用するために必要なものを提供することを目的としています。ここに記載されている以上の情報が必要な場合は、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/) にお問い合わせください。匿名 IP リストのルールグループには、ビューワー ID の難読化を許可するサービスからのリクエストをブロックするルールが含まれています。これには、VPN、プロキシ、Tor ノード、ウェブホスティングプロバイダーなどからのリクエストが含まれます。このルールグループは、アプリケーションから ID を隠そうとするビューワーを除外する場合に便利です。これらのサービスの IP アドレスをブロックすると、ボットの緩和や地理的制限の回避に役立ちます。このマネージドルールグループは、評価対象のウェブリクエストに保護パック (ウェブ ACL) 内のこのルールグループの後に実行されるルールでも使用できるラベルを追加します。 AWS WAF は、Amazon CloudWatch メトリクスにもラベルを記録します。ラベルとラベルメトリクスに関する一般的な情報については、「[ウェブリクエストのラベル付け](waf-labels.md)」および「[ラベルメトリクスとディメンション](waf-metrics.md#waf-metrics-label)」を参照してください。 | ルール名 | 説明とラベル | | --- | --- | | AnonymousIPList | クライアントの情報を匿名化することがわかっているソース (TOR ノード、一時プロキシ、その他のマスキングサービスなど) の IP アドレスのリストを検査します。ルールアクション: Block ラベル: `awswaf:managed:aws:anonymous-ip-list:AnonymousIPList` | | HostingProviderIPList | エンドユーザートラフィックのソースになる可能性が低いウェブホスティングプロバイダーとクラウドプロバイダーの IP アドレスのリストを検査します。IP リストには AWS IP アドレスは含まれません。ルールアクション: Block ラベル: `awswaf:managed:aws:anonymous-ip-list:HostingProviderIPList` | # AWS WAF Fraud Control アカウント作成不正防止 (ACFP) ルールグループこのセクションでは、 AWS WAF Fraud Control アカウント作成不正防止 (ACFP) マネージドルールグループの動作について説明します。 VendorName: `AWS`、名前: `AWSManagedRulesACFPRuleSet`、WCU: 50 **注記** このドキュメントでは、このマネージドルールグループの最新の静的バージョンリリースについて説明します。バージョンの変更は、[AWS マネージドルールの変更ログ](aws-managed-rule-groups-changelog.md) の変更ログにレポートされます。他のバージョンの情報については、API コマンド [DescribeManagedRuleGroup](https://docs.aws.amazon.com/waf/latest/APIReference/API_DescribeManagedRuleGroup.html) を使用してください。 AWS マネージドルールルールのルールグループでルール用に公開する情報は、ルールを回避するために必要なものを不正なアクターに与えることなく、ルールを使用するために必要なものを提供することを目的としています。ここに記載されている以上の情報が必要な場合は、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/) にお問い合わせください。 AWS WAF Fraud Control Account Creation Fraud Prevention (ACFP) マネージドルールグループは、不正なアカウント作成の試みの一部である可能性のあるリクエストにラベルを付けて管理します。ルールグループは、クライアントがアプリケーションの登録エンドポイントとアカウント作成エンドポイントに送信するアカウント作成リクエストを検査することでこれを行います。 ACFP ルールグループは、さまざまな方法でアカウント作成の試みを検査し、悪意のある可能性のあるインタラクションを可視化し、コントロールできるようにします。ルールグループは、リクエストトークンを使用して、クライアントブラウザに関する情報と、アカウント作成リクエストの作成における人間のインタラクティビティのレベルに関する情報を収集します。ルールグループは、IP アドレスとクライアントセッションごとにリクエストを集計し、物理アドレスや電話番号などの提供されたアカウント情報ごとに集計することで、一括アカウント作成の試みを検出および管理します。さらに、ルールグループは、侵害された認証情報を使用した新しいアカウントの作成を検出してブロックします。これは、アプリケーションと新しいユーザーのセキュリティ体制の保護に役立ちます。 ## このルールグループの使用に関する考慮事項このルールグループには、アプリケーションのアカウント登録パスとアカウント作成パスの仕様を含むカスタム設定が必要です。特に明記されている場合を除き、このルールグループのルールは、クライアントがこれらの 2 つのエンドポイントに送信するすべてのリクエストを検査します。このルールグループを設定および実装するには、「[AWS WAF Fraud Control アカウント作成不正防止 (ACFP)](waf-acfp.md)」のガイダンスを参照してください。 **注記** このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。このルールグループは、 AWS WAFでのインテリジェントな脅威の軽減保護の一部です。詳細については、「[でのインテリジェントな脅威の軽減 AWS WAF](waf-managed-protections.md)」を参照してください。コストを抑え、ウェブトラフィックを希望どおりに管理していることを確実にするには、[でのインテリジェントな脅威軽減のベストプラクティス AWS WAF](waf-managed-protections-best-practices.md) のガイダンスに従ってこのルールグループを使用してください。このルールグループは、Amazon Cognito ユーザープールでは使用できません。このルールグループを使用する保護パック (ウェブ ACL) をユーザープールに関連付けることはできません。また、このルールグループをユーザープールに既に関連付けられた保護パック (ウェブ ACL) に追加することはできません。 ## このルールグループによって追加されるラベルこのマネージドルールグループは、評価対象のウェブリクエストに保護パック (ウェブ ACL) 内のこのルールグループの後に実行されるルールでも使用できるラベルを追加します。 AWS WAF は、Amazon CloudWatch メトリクスにもラベルを記録します。ラベルとラベルメトリクスに関する一般的な情報については、「[ウェブリクエストのラベル付け](waf-labels.md)」および「[ラベルメトリクスとディメンション](waf-metrics.md#waf-metrics-label)」を参照してください。 ### トークンラベルこのルールグループは、 AWS WAF トークン管理を使用して、 AWS WAF トークンのステータスに従ってウェブリクエストを検査し、ラベル付けします。は、クライアントセッションの追跡と検証にトークン AWS WAF を使用します。トークンおよびトークンの管理の詳細については、「[AWS WAF インテリジェントな脅威の軽減におけるトークンの使用](waf-tokens.md)」を参照してください。ここで説明するラベルコンポーネントについては、「[でのラベル構文と命名要件 AWS WAF](waf-rule-label-requirements.md)」を参照してください。 **クライアントセッションラベル** ラベルには、 AWS WAF トークン管理がクライアントセッションを識別するために使用する一意の識別子`awswaf:managed:token:id:identifier`が含まれています。この識別子は、クライアントが使用していたトークンを破棄した後など、新しいトークンを取得すると変わる可能性があります。 **注記** AWS WAF は、このラベルの Amazon CloudWatch メトリクスを報告しません。 **ブラウザフィンガープリントラベル** ラベルには、 AWS WAF トークン管理がさまざまなクライアントブラウザシグナルから計算する堅牢なブラウザフィンガープリント識別子`awswaf:managed:token:fingerprint:fingerprint-identifier`が含まれています。この識別子は、複数のトークン取得の試行全体で同じままです。フィンガープリント識別子は、単一のクライアントに対して一意ではありません。 **注記** AWS WAF は、このラベルの Amazon CloudWatch メトリクスを報告しません。 **トークンステータスラベル: ラベル名前空間プレフィックス** トークンステータスラベルは、トークン、チャレンジのステータス、およびそれに含まれる CAPTCHA 情報を報告します。各トークンステータスラベルは、次のプレフィクスの 1 つで始まります。 + `awswaf:managed:token:`— トークンの一般的なステータスを報告したり、トークンのチャレンジ情報のステータスを報告したりするために使用されます。 + `awswaf:managed:captcha:`— トークンの CAPTCHA 情報のステータスを報告するために使用されます。 **トークンステータスラベル: ラベル名** プレフィックスに続いて、ラベルの残りの部分には詳細なトークンステータス情報が表示されます。 + `accepted` - リクエストトークンが存在し、以下の内容が含まれています。 + 有効なチャレンジまたは CAPTCHA ソリューション。 + 有効期限が切れていないチャレンジまたは CAPTCHA タイムスタンプ。 + 保護パック (ウェブ ACL) に有効なドメイン仕様。例: ラベル `awswaf:managed:token:accepted` には、ウェブリクエストのトークンに有効なチャレンジソリューション、有効期限が切れていないチャレンジタイムスタンプ、および有効なドメインがあることが示されています。 + `rejected` - リクエストトークンは存在するが、承認基準を満たしていない。トークン管理では、拒否されたラベルに加えて、理由を示すカスタムラベル名前空間と名前が追加されます。 + `rejected:not_solved` — トークンにチャレンジまたは CAPTCHA ソリューションがない。 + `rejected:expired` — 保護パック (ウェブ ACL) に設定されているトークンイミュニティ時間によると、トークンのチャレンジまたは CAPTCHA タイムスタンプの有効期限が切れている。 + `rejected:domain_mismatch` — トークンのドメインが、保護パック (ウェブ ACL) のトークンドメイン設定と一致しない。 + `rejected:invalid` – 指定されたトークンを読み取ることが AWS WAF できませんでした。例: ラベル `awswaf:managed:captcha:rejected` と `awswaf:managed:captcha:rejected:expired` とともに、トークンの CAPTCHA タイムスタンプがウェブ ACL で設定されている CAPTCHA トークンのイミュニティ時間を超えたために、リクエストには有効な CAPTCHA 解決がなかったことが示されています。 + `absent` — リクエストにトークンがないか、トークンマネージャーがそれを読み取れなかった。例: ラベル `awswaf:managed:captcha:absent` には、リクエストにトークンがないことが示されています。 ### ACFP ラベルこのルールグループは、名前空間プレフィックス `awswaf:managed:aws:acfp:` が付いたラベルを生成し、その後にカスタム名前空間およびラベル名が付いたラベルを生成します。ルールグループは、リクエストに複数のラベルを追加する場合があります。 `DescribeManagedRuleGroup` を呼び出すことにより、API を介してルールグループのすべてのラベルを取得できます。ラベルは、応答の `AvailableLabels` プロパティにリストされています。 ## Account Creation Fraud Prevention ルールリスト次のセクションには、`AWSManagedRulesACFPRuleSet` の ACFP ルールとルールグループがウェブリクエストに追加するラベルが示されています。このルールグループ内のすべてのルールでは、最初の 2 つの `UnsupportedCognitoIDP` と `AllRequests` を除き、ウェブリクエストトークンが必要です。トークンが提供する情報の説明については、「[AWS WAF トークンの特性](waf-tokens-details.md)」を参照してください。特に明記されていない限り、このルールグループのルールは、ルールグループの設定で指定したアカウント登録ページのパスとアカウント作成ページのパスにクライアントが送信するすべてのリクエストを検査します。このルールグループの設定の詳細については、「[AWS WAF Fraud Control アカウント作成不正防止 (ACFP)](waf-acfp.md)」を参照してください。 **注記** このドキュメントでは、このマネージドルールグループの最新の静的バージョンリリースについて説明します。バージョンの変更は、[AWS マネージドルールの変更ログ](aws-managed-rule-groups-changelog.md) の変更ログにレポートされます。他のバージョンの情報については、API コマンド [DescribeManagedRuleGroup](https://docs.aws.amazon.com/waf/latest/APIReference/API_DescribeManagedRuleGroup.html) を使用してください。 AWS マネージドルールルールのルールグループでルール用に公開する情報は、ルールを回避するために必要なものを不正なアクターに与えることなく、ルールを使用するために必要なものを提供することを目的としています。ここに記載されている以上の情報が必要な場合は、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/) にお問い合わせください。 | ルール名 | 説明とラベル | | --- | --- | | UnsupportedCognitoIDP | Amazon Cognito ユーザープールに向かうウェブトラフィックの有無を検査します。ACFP は Amazon Cognito ユーザープールでは使用できません。このルールは、他の ACFP ルールグループのルールがユーザープールのトラフィックの評価に使用されないようにすることに役立ちます。ルールアクション: Block ラベル: `awswaf:managed:aws:acfp:unsupported:cognito_idp` および `awswaf:managed:aws:acfp:UnsupportedCognitoIDP` | | AllRequests | 登録ページのパスにアクセスするリクエストにルールアクションを適用します。ルールグループを設定するときに、登録ページのパスを設定します。デフォルトでは、このルールは Challenge をリクエストに適用します。このアクションを適用することにより、ルールは、ルールグループ内の残りのルールによってリクエストが評価される前に、クライアントがチャレンジトークンを取得するようにします。エンドユーザーがアカウント作成リクエストを送信する前に、登録ページのパスをロードするようにします。トークンは、クライアントアプリケーション統合 SDK、ならびに CAPTCHA および Challenge のルールアクションによってリクエストに追加されます。最も効率的にトークンを取得するために、アプリケーション統合 SDK を使用することを強くお勧めします。詳細については、「[でのクライアントアプリケーション統合 AWS WAF](waf-application-integration.md)」を参照してください。ルールアクション: Challenge ラベル: なし | | RiskScoreHigh | IP アドレスやその他の非常に疑わしい要素が含まれるアカウント作成リクエストを検査します。この評価は通常、複数の寄与要因に基づいており、ルールグループがリクエストに追加する `risk_score` ラベルで確認できます。ルールアクション: Block ラベル: `awswaf:managed:aws:acfp:risk_score:high` および `awswaf:managed:aws:acfp:RiskScoreHigh` このルールは、`medium` または `low` のリスクスコアラベルをリクエストに適用することもできます。 AWS WAF がウェブリクエストのリスクスコアの評価に成功しない場合、ルールはラベルを追加します。 `awswaf:managed:aws:acfp:risk_score:evaluation_failed ` さらに、このルールは、IP レピュテーションや盗難された認証情報の評価など、特定のリスクスコアの寄与要因のリスクスコアの評価ステータスと結果を含む名前空間 `awswaf:managed:aws:acfp:risk_score:contributor:` のラベルを追加します。 | | SignalCredentialCompromised | 盗まれた認証情報データベースで、アカウント作成リクエストで送信された認証情報を検索します。このルールにより、新しいクライアントは、好ましいセキュリティ体制でアカウントを初期化するようになります。カスタムブロックレスポンスを追加して、エンドユーザーに問題を説明し、続行方法を伝えることができます。詳細については、「[ACFP の例: 侵害された認証情報についてのカスタムレスポンス](waf-acfp-control-example-compromised-credentials.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:acfp:signal:credential_compromised` および `awswaf:managed:aws:acfp:SignalCredentialCompromised` ルールグループは次の関連ラベルを適用しますが、アカウント作成のすべてのリクエストに認証情報があるわけではないため、それに対するアクションは実行されません: `awswaf:managed:aws:acfp:signal:missing_credential`。 | | SignalClientHumanInteractivityAbsentLow | アカウント作成リクエストのトークンで、人間によるアプリケーションとの異常なインタラクティブ性を示すデータがないかどうかを検査します。人間のインタラクティビティは、マウスの動きやキーの押下などのインタラクションを通じて検出されます。ページに HTML フォームがある場合、人間によるインタラクションにはフォームとのインタラクションが含まれます。このルールは、アカウント作成パスに対するリクエストのみを検査し、アプリケーション統合 SDK を実装している場合にのみ評価されます。SDK を実装することで、人間のインタラクティブ性を受動的にキャプチャし、その情報をリクエストトークンに保存できます。詳細については、「[AWS WAF トークンの特性](waf-tokens-details.md)」および「[でのクライアントアプリケーション統合 AWS WAF](waf-application-integration.md)」を参照してください。ルールアクション: CAPTCHA ラベル: なし。このルールはさまざまな要因に基づいて一致を決定するため、考えられるすべての一致シナリオに適用される個別のラベルはありません。ルールグループは、次の 1 つ以上のラベルをリクエストに適用できます。 `awswaf:managed:aws:acfp:signal:client:human_interactivity:low\|medium\|high` `awswaf:managed:aws:acfp:SignalClientHumanInteractivityAbsentLow\|Medium\|High` `awswaf:managed:aws:acfp:signal:client:human_interactivity:insufficient_data` `awswaf:managed:aws:acfp:signal:form_detected`. | | AutomatedBrowser | クライアントブラウザが自動化されている可能性を示す要素がないかを検査します。ルールアクション: Block ラベル: `awswaf:managed:aws:acfp:signal:automated_browser` および `awswaf:managed:aws:acfp:AutomatedBrowser` | | BrowserInconsistency | ブラウザ調査のデータに一貫性がないかどうかを確認するために、リクエストのトークンを検査します。詳細については、「[AWS WAF トークンの特性](waf-tokens-details.md)」を参照してください。ルールアクション: CAPTCHA ラベル: `awswaf:managed:aws:acfp:signal:browser_inconsistency` および `awswaf:managed:aws:acfp:BrowserInconsistency` | | VolumetricIpHigh | 個々の IP アドレスから送信された大量のアカウント作成リクエストを検査します。大量とは、10 分ウィンドウにリクエストが 20 件を超えることです。このルールが適用するしきい値は、レイテンシーによって若干異なる場合があります。大量の場合、ルールアクションが適用される前に、いくつかのリクエストが制限を超える可能性があります。ルールアクション: CAPTCHA ラベル: `awswaf:managed:aws:acfp:aggregate:volumetric:ip:creation:high` および `awswaf:managed:aws:acfp:VolumetricIpHigh` ルールは、中程度の量 (10 分間の時間枠あたり 15 件以上のリクエスト）および少量 (10 分間の時間枠あたり 10 件以上のリクエスト）のリクエストに対して、以下のラベル `awswaf:managed:aws:acfp:aggregate:volumetric:ip:creation:medium` および `awswaf:managed:aws:acfp:aggregate:volumetric:ip:creation:low` を適用しますが、アクションは実行しません。 | | VolumetricSessionHigh | 個々のクライアントセッションから送信された大量のアカウントリクエストを検査します。大量とは、30 分間の時間枠にリクエストが 10 件を超えることです。このルールが適用するしきい値は、レイテンシーによって若干異なる場合があります。ルールアクションが適用される前に、いくつかのリクエストが制限を超えることがあります。ルールアクション: Block ラベル: `awswaf:managed:aws:acfp:aggregate:volumetric:session:creation:high` および `awswaf:managed:aws:acfp:VolumetricSessionHigh` ルールグループは、中程度の量 (30 分間の時間枠あたり 5 件以上のリクエスト) および少量 (30 分間の時間枠あたり 1 件以上のリクエスト)のリクエストに対して、以下のラベル `awswaf:managed:aws:acfp:aggregate:volumetric:session:creation:medium` および `awswaf:managed:aws:acfp:aggregate:volumetric:session:creation:low` を適用しますが、アクションは実行しません。 | | AttributeUsernameTraversalHigh | 異なるユーザー名を使用する単一のクライアントセッションからアカウント作成リクエストが高頻度で発生していないかどうかを検査します。30 分間のリクエスト数が 10 件を超えている場合は、大量であると評価されます。このルールが適用するしきい値は、レイテンシーによって若干異なる場合があります。ルールアクションが適用される前に、いくつかのリクエストが制限を超えることがあります。ルールアクション: Block ラベル: `awswaf:managed:aws:acfp:aggregate:attribute:username_traversal:creation:high` および `awswaf:managed:aws:acfp:AttributeUsernameTraversalHigh` ルールグループは、ユーザー名トラバーサルリクエストの中程度の量 (30分間の時間枠あたり 5 件以上のリクエスト) および少量 (30 分間の時間枠あたり 1 件以上のリクエスト) に対して、以下のラベル `awswaf:managed:aws:acfp:aggregate:attribute:username_traversal:creation:medium` および `awswaf:managed:aws:acfp:aggregate:attribute:username_traversal:creation:low` を適用しますが、アクションは実行しません。 | | VolumetricPhoneNumberHigh | 同じ電話番号を使用する大量のアカウント作成リクエストが発生していないかを検査します。30 分間のリクエスト数が 10 件を超えている場合は、大量であると評価されます。このルールが適用するしきい値は、レイテンシーによって若干異なる場合があります。ルールアクションが適用される前に、いくつかのリクエストが制限を超えることがあります。ルールアクション: Block ラベル: `awswaf:managed:aws:acfp:aggregate:volumetric:phone_number:high` および `awswaf:managed:aws:acfp:VolumetricPhoneNumberHigh` ルールグループは、中程度の量 (30 分間の時間枠あたり 5 件以上のリクエスト) および少量 (30 分間の時間枠あたり 1 件以上のリクエスト)のリクエストに対して、以下のラベル `awswaf:managed:aws:acfp:aggregate:volumetric:phone_number:medium` および `awswaf:managed:aws:acfp:aggregate:volumetric:phone_number:low` を適用しますが、アクションは実行しません。 | | VolumetricAddressHigh | 同じ物理的な住所を使用する大量のアカウント作成リクエストが発生していないかを検査します。30 分間の時間枠あたりのリクエスト数が 100 件を超えている場合は、大量であると評価されます。このルールが適用するしきい値は、レイテンシーによって若干異なる場合があります。ルールアクションが適用される前に、いくつかのリクエストが制限を超えることがあります。ルールアクション: Block ラベル: `awswaf:managed:aws:acfp:aggregate:volumetric:address:high` および `awswaf:managed:aws:acfp:VolumetricAddressHigh` | | VolumetricAddressLow | 同じ物理的な住所を使用する少量または中程度の量のアカウント作成リクエストが発生していないかを検査します。中程度の評価のしきい値は 30 分間の時間枠あたり 50 件以上のリクエストであり、低評価のしきい値は 30 分間の時間枠あたり 10 件以上のリクエストです。このルールは、中程度の量または少量のいずれかの場合にアクションを適用します。このルールが適用するしきい値は、レイテンシーによって若干異なる場合があります。ルールアクションが適用される前に、いくつかのリクエストが制限を超えることがあります。ルールアクション: CAPTCHA ラベル: `awswaf:managed:aws:acfp:aggregate:volumetric:address:low\|medium` および `awswaf:managed:aws:acfp:VolumetricAddressLow\|Medium` | | VolumetricIPSuccessfulResponse | 単一の IP アドレスに対する大量の正常なアカウント作成リクエストを検査します。このルールは、保護されたリソースからのアカウント作成リクエストに対する成功レスポンスを集計します。10 分間の時間枠あたりのリクエスト数が 10 件を超えている場合は、大量であると評価されます。このルールは、アカウントの一括作成の試みからの保護に役立ちます。リクエストのみをカウントするルール `VolumetricIpHigh` よりもしきい値が低くなります。レスポンス本文または JSON コンポーネントを検査するようにルールグループを設定している場合、はこれらのコンポーネントタイプの最初の 65,536 バイト (64 KB) で成功または失敗のインジケータを検査 AWS WAF できます。このルールは、同じ IP アドレスからの最新のログイン試行に対する保護されたリソースからの成功応答と失敗応答に基づいて、IP アドレスからの新しいウェブリクエストにルールアクションとラベリングを適用します。ルールグループを設定するときに、成功数と失敗数のカウント方法を定義します。 AWS WAF は、Amazon CloudFront ディストリビューションを保護する保護パック (ウェブ ACLs) でのみこのルールを評価します。このルールが適用するしきい値は、レイテンシーによって若干異なる場合があります。ルールがその後の試みに対して一致処理を開始する前に、正常なアカウント作成の試みが、許可されているよりも多くクライアントから送信される可能性があります。ルールアクション: Block ラベル: `awswaf:managed:aws:acfp:aggregate:volumetric:ip:successful_creation_response:high` および `awswaf:managed:aws:acfp:VolumetricIPSuccessfulResponse` ルールグループは、次の関連ラベルもリクエストに適用します。関連するアクションはありません。すべてのカウントは 10 分間の時間枠のものです。5 件以上の成功したリクエストには `awswaf:managed:aws:acfp:aggregate:volumetric:ip:successful_creation_response:medium`、1 件以上の成功したリクエストには `awswaf:managed:aws:acfp:aggregate:volumetric:ip:successful_creation_response:low`、10 件以上の失敗したリクエストには `awswaf:managed:aws:acfp:aggregate:volumetric:ip:failed_creation_response:high`、5 件以上の失敗したリクエストには `awswaf:managed:aws:acfp:aggregate:volumetric:ip:failed_creation_response:medium`、1 件以上の失敗したリクエストには `awswaf:managed:aws:acfp:aggregate:volumetric:ip:failed_creation_response:low` です。 | | VolumetricSessionSuccessfulResponse | 単一のクライアントセッションから送信されるアカウント作成リクエストに対する、保護されたリソースからの少量の成功したレスポンスを検査します。これは、アカウントの一括作成の試みからの保護に役立ちます。30 分間の時間枠あたりのリクエスト数が 1 件を超えている場合は、少量であると評価されます。これは、アカウントの一括作成の試みからの保護に役立ちます。このルールは、リクエストのみをカウントするルール `VolumetricSessionHigh` よりも低いしきい値を使用します。レスポンス本文または JSON コンポーネントを検査するようにルールグループを設定している場合、はこれらのコンポーネントタイプの最初の 65,536 バイト (64 KB) で成功または失敗のインジケータを検査 AWS WAF できます。このルールは、同じクライアントセッションからの最新のログイン試行に対する保護されたリソースからの成功応答と失敗応答に基づいて、クライアントセッションからの新しいウェブリクエストにルールアクションとラベリングを適用します。ルールグループを設定するときに、成功数と失敗数のカウント方法を定義します。 AWS WAF は、Amazon CloudFront ディストリビューションを保護する保護パック (ウェブ ACLs) でのみこのルールを評価します。このルールが適用するしきい値は、レイテンシーによって若干異なる場合があります。ルールがその後の試みに対して一致処理を開始する前に、失敗したアカウント作成の試みが、許可されているよりも多くクライアントから送信される可能性があります。ルールアクション: Block ラベル: `awswaf:managed:aws:acfp:aggregate:volumetric:session:successful_creation_response:low` および `awswaf:managed:aws:acfp:VolumetricSessionSuccessfulResponse` ルールグループは、次の関連ラベルもリクエストに適用します。すべてのカウントは 30 分間の時間枠のものです。10 件以上の成功したリクエストには `awswaf:managed:aws:acfp:aggregate:volumetric:session:successful_creation_response:high`、5 件以上の成功したリクエストには `awswaf:managed:aws:acfp:aggregate:volumetric:session:successful_creation_response:medium`、10 件以上の失敗したリクエストには `awswaf:managed:aws:acfp:aggregate:volumetric:session:failed_creation_response:high`、5 件以上の失敗したリクエストには `awswaf:managed:aws:acfp:aggregate:volumetric:session:failed_creation_response:medium`、1 件以上の失敗したリクエストには `awswaf:managed:aws:acfp:aggregate:volumetric:session:failed_creation_response:low` です。 | | VolumetricSessionTokenReuseIp | アカウント作成リクエストを検査して、5 つを超える異なる IP アドレス間で単一のトークンが使用されていないかどうかをチェックします。このルールが適用するしきい値は、レイテンシーによって若干異なる場合があります。ルールアクションが適用される前に、いくつかのリクエストが制限を超えることがあります。ルールアクション: Block ラベル: `awswaf:managed:aws:acfp:aggregate:volumetric:session:creation:token_reuse:ip` および `awswaf:managed:aws:acfp:VolumetricSessionTokenReuseIp` | # AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループこのセクションでは、 AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) マネージドルールグループの動作について説明します。 VendorName: `AWS`、名前: `AWSManagedRulesATPRuleSet`、WCU: 50 **注記** このドキュメントでは、このマネージドルールグループの最新の静的バージョンリリースについて説明します。バージョンの変更は、[AWS マネージドルールの変更ログ](aws-managed-rule-groups-changelog.md) の変更ログにレポートされます。他のバージョンの情報については、API コマンド [DescribeManagedRuleGroup](https://docs.aws.amazon.com/waf/latest/APIReference/API_DescribeManagedRuleGroup.html) を使用してください。 AWS マネージドルールのルールグループでルール用に公開する情報は、ルールを回避するために必要なものを不正なアクターに与えることなく、ルールを使用するために必要なものを提供することを目的としています。ここに記載されている以上の情報が必要な場合は、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/) にお問い合わせください。 AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) マネージドルールグループは、悪意のあるアカウント乗っ取りの試みの一部である可能性のあるリクエストにラベルを付けて管理します。ルールグループは、クライアントでアプリケーションのログインエンドポイントに送信するログイン試行を検査することでこれを行います。 + **リクエスト検査** – ATP を使用すると、異常なログイン試行や盗まれた認証情報を使用するログイン試行を可視化して制御できるため、不正行為につながる可能性のあるアカウントの乗っ取りを防ぐことができます。ATP は、盗まれた認証情報のデータベースに照らして E メールとパスワードの組み合わせをチェックします。このデータベースは、漏洩された認証情報がダークウェブ上で新しく見つかると定期的に更新されます。ATP は、IP アドレスやクライアントセッションごとにデータを集約し、不審なリクエストを大量に送信するクライアントを検出してブロックします。 + **レスポンス検査** – CloudFront ディストリビューションの場合、ATP ルールグループは、受信したログインリクエストを検査するだけでなく、ログイン試行に対するアプリケーションの応答も検査して、成功率と失敗率を追跡します。この情報を使用して、ATP はログイン失敗の回数が過度に多いクライアントセッションまたは IP アドレスを一時的にブロックできます。 AWS WAF は、レスポンス検査を非同期で実行するため、ウェブトラフィックのレイテンシーが大きくなることはありません。 ## このルールグループの使用に関する考慮事項このルールグループには特定の設定が必要です。このルールグループを設定および実装するには、「[AWS WAF Fraud Control アカウント乗っ取り防止 (ATP)](waf-atp.md)」のガイダンスを参照してください。このルールグループは、 AWS WAFでのインテリジェントな脅威の軽減保護の一部です。詳細については、「[でのインテリジェントな脅威の軽減 AWS WAF](waf-managed-protections.md)」を参照してください。 **注記** このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。コストを抑え、ウェブトラフィックを希望どおりに管理していることを確実にするには、[でのインテリジェントな脅威軽減のベストプラクティス AWS WAF](waf-managed-protections-best-practices.md) のガイダンスに従ってこのルールグループを使用してください。このルールグループは、Amazon Cognito ユーザープールでは使用できません。このルールグループを使用する保護パック (ウェブ ACL) をユーザープールに関連付けることはできません。また、このルールグループをユーザープールに既に関連付けられた保護パック (ウェブ ACL) に追加することはできません。 ## このルールグループによって追加されるラベルこのマネージドルールグループは、評価対象のウェブリクエストに保護パック (ウェブ ACL) 内のこのルールグループの後に実行されるルールでも使用できるラベルを追加します。 AWS WAF は、Amazon CloudWatch メトリクスにもラベルを記録します。ラベルとラベルメトリクスに関する一般的な情報については、「[ウェブリクエストのラベル付け](waf-labels.md)」および「[ラベルメトリクスとディメンション](waf-metrics.md#waf-metrics-label)」を参照してください。 ### トークンラベルこのルールグループは、 AWS WAF トークン管理を使用して、 AWS WAF トークンのステータスに従ってウェブリクエストを検査し、ラベル付けします。は、クライアントセッションの追跡と検証にトークン AWS WAF を使用します。トークンおよびトークンの管理の詳細については、「[AWS WAF インテリジェントな脅威の軽減におけるトークンの使用](waf-tokens.md)」を参照してください。ここで説明するラベルコンポーネントについては、「[でのラベル構文と命名要件 AWS WAF](waf-rule-label-requirements.md)」を参照してください。 **クライアントセッションラベル** ラベルには、 AWS WAF トークン管理がクライアントセッションを識別するために使用する一意の識別子`awswaf:managed:token:id:identifier`が含まれています。この識別子は、クライアントが使用していたトークンを破棄した後など、新しいトークンを取得すると変わる可能性があります。 **注記** AWS WAF は、このラベルの Amazon CloudWatch メトリクスを報告しません。 **ブラウザフィンガープリントラベル** ラベルには、 AWS WAF トークン管理がさまざまなクライアントブラウザシグナルから計算する堅牢なブラウザフィンガープリント識別子`awswaf:managed:token:fingerprint:fingerprint-identifier`が含まれています。この識別子は、複数のトークン取得の試行全体で同じままです。フィンガープリント識別子は、単一のクライアントに対して一意ではありません。 **注記** AWS WAF は、このラベルの Amazon CloudWatch メトリクスを報告しません。 **トークンステータスラベル: ラベル名前空間プレフィックス** トークンステータスラベルは、トークン、チャレンジのステータス、およびそれに含まれる CAPTCHA 情報を報告します。各トークンステータスラベルは、次のプレフィクスの 1 つで始まります。 + `awswaf:managed:token:`— トークンの一般的なステータスを報告したり、トークンのチャレンジ情報のステータスを報告したりするために使用されます。 + `awswaf:managed:captcha:`— トークンの CAPTCHA 情報のステータスを報告するために使用されます。 **トークンステータスラベル: ラベル名** プレフィックスに続いて、ラベルの残りの部分には詳細なトークンステータス情報が表示されます。 + `accepted` - リクエストトークンが存在し、以下の内容が含まれています。 + 有効なチャレンジまたは CAPTCHA ソリューション。 + 有効期限が切れていないチャレンジまたは CAPTCHA タイムスタンプ。 + 保護パック (ウェブ ACL) に有効なドメイン仕様。例: ラベル `awswaf:managed:token:accepted` には、ウェブリクエストのトークンに有効なチャレンジソリューション、有効期限が切れていないチャレンジタイムスタンプ、および有効なドメインがあることが示されています。 + `rejected` - リクエストトークンは存在するが、承認基準を満たしていない。トークン管理では、拒否されたラベルに加えて、理由を示すカスタムラベル名前空間と名前が追加されます。 + `rejected:not_solved` — トークンにチャレンジまたは CAPTCHA ソリューションがない。 + `rejected:expired` — 保護パック (ウェブ ACL) に設定されているトークンイミュニティ時間によると、トークンのチャレンジまたは CAPTCHA タイムスタンプの有効期限が切れている。 + `rejected:domain_mismatch` — トークンのドメインが、保護パック (ウェブ ACL) のトークンドメイン設定と一致しない。 + `rejected:invalid` – 指定されたトークンを読み取ることが AWS WAF できませんでした。例: ラベル `awswaf:managed:captcha:rejected` と `awswaf:managed:captcha:rejected:expired` とともに、トークンの CAPTCHA タイムスタンプがウェブ ACL で設定されている CAPTCHA トークンのイミュニティ時間を超えたために、リクエストには有効な CAPTCHA 解決がなかったことが示されています。 + `absent` — リクエストにトークンがないか、トークンマネージャーがそれを読み取れなかった。例: ラベル `awswaf:managed:captcha:absent` には、リクエストにトークンがないことが示されています。 ### ATP ラベル ATP マネージドルールグループは、名前空間プレフィックス `awswaf:managed:aws:atp:` が付いたラベルを生成し、その後にカスタム名前空間およびラベル名が付いたラベルを生成します。ルールグループは、ルールリストに記載されているラベルに加えて、次のラベルのいずれかを追加する場合があります。 + `awswaf:managed:aws:atp:signal:credential_compromised` – リクエストで送信された認証情報が、盗まれた認証情報データベースに含まれていることを示します。 + `awswaf:managed:aws:atp:aggregate:attribute:suspicious_tls_fingerprint` – 保護されている Amazon CloudFront ディストリビューションでのみ利用できます。クライアントセッションが、疑わしい TLS フィンガープリントを使用した複数のリクエストを送信したことを示します。 + `awswaf:managed:aws:atp:aggregate:volumetric:session:token_reuse:ip` - 5 つを超える異なる IP アドレス間で単一のトークンが使用されていることを示します。このルールが適用するしきい値は、レイテンシーによって若干異なる場合があります。ラベルが適用される前に、いくつかのリクエストが制限を超えることがあります。 `DescribeManagedRuleGroup` を呼び出すことにより、API を介してルールグループのすべてのラベルを取得できます。ラベルは、応答の `AvailableLabels` プロパティにリストされています。 ## アカウント乗っ取り防止のルールリスト次のセクションには、`AWSManagedRulesATPRuleSet` の ATP ルールとルールグループがウェブリクエストに追加するラベルが示されています。 **注記** このドキュメントでは、このマネージドルールグループの最新の静的バージョンリリースについて説明します。バージョンの変更は、[AWS マネージドルールの変更ログ](aws-managed-rule-groups-changelog.md) の変更ログにレポートされます。他のバージョンの情報については、API コマンド [DescribeManagedRuleGroup](https://docs.aws.amazon.com/waf/latest/APIReference/API_DescribeManagedRuleGroup.html) を使用してください。 AWS マネージドルールのルールグループでルール用に公開する情報は、ルールを回避するために必要なものを不正なアクターに与えることなく、ルールを使用するために必要なものを提供することを目的としています。ここに記載されている以上の情報が必要な場合は、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/) にお問い合わせください。 | ルール名 | 説明とラベル | | --- | --- | | UnsupportedCognitoIDP | Amazon Cognito ユーザープールに向かうウェブトラフィックの有無を検査します。ATP は Amazon Cognito ユーザープールでは使用できません。このルールは、他の ATP ルールグループのルールがユーザープールのトラフィックの評価に使用されないようにすることに役立ちます。ルールアクション: Block ラベル: `awswaf:managed:aws:atp:unsupported:cognito_idp` および `awswaf:managed:aws:atp:UnsupportedCognitoIDP` | | VolumetricIpHigh | 個々の IP アドレスから送信された大量のリクエストを検査します。大量とは、10 分ウィンドウにリクエストが 20 件を超えることです。このルールが適用するしきい値は、レイテンシーによって若干異なる場合があります。大量の場合、ルールアクションが適用される前に、いくつかのリクエストが制限を超える可能性があります。ルールアクション: Block ラベル: `awswaf:managed:aws:atp:aggregate:volumetric:ip:high` および `awswaf:managed:aws:atp:VolumetricIpHigh` ルールグループは、中程度の量 (10 分間の時間枠あたり 15 件以上のリクエスト) および少量 (10 分間の時間枠あたり 10 件以上のリクエスト）のリクエストに対して、以下のラベル `awswaf:managed:aws:atp:aggregate:volumetric:ip:medium` および `awswaf:managed:aws:atp:aggregate:volumetric:ip:low` を適用しますが、アクションは実行しません。 | | VolumetricSession | 個々のクライアントセッションから送信された大量のリクエストを検査します。しきい値は、30 分ウィンドウあたり 20 を超えるリクエスト数に設定します。この検査は、ウェブリクエストにトークンがある場合にのみ適用されます。トークンは、アプリケーション統合 SDK、ならびに CAPTCHA および Challenge のルールアクションによってリクエストに追加されます。詳細については、「[AWS WAF インテリジェントな脅威の軽減におけるトークンの使用](waf-tokens.md)」を参照してください。このルールが適用するしきい値は、レイテンシーによって若干異なる場合があります。ルールアクションが適用される前に、いくつかのリクエストが制限を超えることがあります。ルールアクション: Block ラベル: `awswaf:managed:aws:atp:aggregate:volumetric:session` および `awswaf:managed:aws:atp:VolumetricSession` | | AttributeCompromisedCredentials | 盗まれた認証情報を使用する同じクライアントセッションからの複数リクエストを検査します。ルールアクション: Block ラベル: `awswaf:managed:aws:atp:aggregate:attribute:compromised_credentials` および `awswaf:managed:aws:atp:AttributeCompromisedCredentials` | | AttributeUsernameTraversal | ユーザー名トラバーサルを使用する同じクライアントセッションからの複数リクエストを検査します。ルールアクション: Block ラベル: `awswaf:managed:aws:atp:aggregate:attribute:username_traversal` および `awswaf:managed:aws:atp:AttributeUsernameTraversal` | | AttributePasswordTraversal | パスワードトラバーサルと同じユーザー名を使用する複数のリクエストを検査します。ルールアクション: Block ラベル: `awswaf:managed:aws:atp:aggregate:attribute:password_traversal` および `awswaf:managed:aws:atp:AttributePasswordTraversal` | | AttributeLongSession | 長期に継続するセッションを使用する同じクライアントセッションからの複数リクエストを検査します。しきい値は、30 分ごとに少なくとも 1 つのログインリクエストが存在する 6 時間を超えるトラフィックです。この検査は、ウェブリクエストにトークンがある場合にのみ適用されます。トークンは、アプリケーション統合 SDK、ならびに CAPTCHA および Challenge のルールアクションによってリクエストに追加されます。詳細については、「[AWS WAF インテリジェントな脅威の軽減におけるトークンの使用](waf-tokens.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:atp:aggregate:attribute:long_session` および `awswaf:managed:aws:atp:AttributeLongSession` | | TokenRejected | トークン管理によって拒否された AWS WAF トークンを含むリクエストを検査します。この検査は、ウェブリクエストにトークンがある場合にのみ適用されます。トークンは、アプリケーション統合 SDK、ならびに CAPTCHA および Challenge のルールアクションによってリクエストに追加されます。詳細については、「[AWS WAF インテリジェントな脅威の軽減におけるトークンの使用](waf-tokens.md)」を参照してください。ルールアクション: Block ラベル: なし。トークンが拒否されたかどうか確認するには、ラベル一致ルールを使用してラベル `awswaf:managed:token:rejected` を照合します。 | | SignalMissingCredential | 認証情報を含むリクエストに、ユーザー名またはパスワードが不足しているかどうか検査します。ルールアクション: Block ラベル: `awswaf:managed:aws:atp:signal:missing_credential` および `awswaf:managed:aws:atp:SignalMissingCredential` | | VolumetricIpFailedLoginResponseHigh | 最近のログイン試行の失敗率が過度に高い IP アドレスを検査します。大量とは、10 分間の時間枠に 1 つの IP アドレスからの失敗したログインリクエストが 10 件を超えることです。レスポンス本文または JSON コンポーネントを検査するようにルールグループを設定している場合、はこれらのコンポーネントタイプの最初の 65,536 バイト (64 KB) で成功または失敗のインジケータを検査 AWS WAF できます。このルールは、同じ IP アドレスからの最新のログイン試行に対する保護されたリソースからの成功応答と失敗応答に基づいて、IP アドレスからの新しいウェブリクエストにルールアクションとラベリングを適用します。ルールグループを設定するときに、成功数と失敗数のカウント方法を定義します。 AWS WAF は、Amazon CloudFront ディストリビューションを保護する保護パック (ウェブ ACLs) でのみこのルールを評価します。このルールが適用するしきい値は、レイテンシーによって若干異なる場合があります。ルールがその後のログイン試行に対して一致処理を開始する前に、許可されているよりも多い回数の失敗したログイン試行がクライアントから送信される可能性があります。ルールアクション: Block ラベル: `awswaf:managed:aws:atp:aggregate:volumetric:ip:failed_login_response:high` および `awswaf:managed:aws:atp:VolumetricIpFailedLoginResponseHigh` ルールグループは、次の関連ラベルもリクエストに適用します。関連するアクションはありません。すべてのカウントは 10 分間の時間枠のものです。5 件以上の失敗したリクエストには `awswaf:managed:aws:atp:aggregate:volumetric:ip:failed_login_response:medium`、1 件以上の失敗したリクエストには `awswaf:managed:aws:atp:aggregate:volumetric:ip:failed_login_response:low`、10 件以上の成功したリクエストには `awswaf:managed:aws:atp:aggregate:volumetric:ip:successful_login_response:high`、5 件以上の成功したリクエストには `awswaf:managed:aws:atp:aggregate:volumetric:ip:successful_login_response:medium`、1 件以上の成功したリクエストには `awswaf:managed:aws:atp:aggregate:volumetric:ip:successful_login_response:low` です。 | | VolumetricSessionFailedLoginResponseHigh | 最近のログイン試行の失敗率が過度に高いクライアントセッションを検査します。大量とは、30 分間の時間枠にクライアントセッションからの失敗したログインリクエストが 10 件を超えることです。レスポンス本文または JSON コンポーネントを検査するようにルールグループを設定している場合、はこれらのコンポーネントタイプの最初の 65,536 バイト (64 KB) で成功または失敗のインジケータを検査 AWS WAF できます。このルールは、同じクライアントセッションからの最新のログイン試行に対する保護されたリソースからの成功応答と失敗応答に基づいて、クライアントセッションからの新しいウェブリクエストにルールアクションとラベリングを適用します。ルールグループを設定するときに、成功数と失敗数のカウント方法を定義します。 AWS WAF は、Amazon CloudFront ディストリビューションを保護する保護パック (ウェブ ACLs) でのみこのルールを評価します。このルールが適用するしきい値は、レイテンシーによって若干異なる場合があります。ルールがその後のログイン試行に対して一致処理を開始する前に、許可されているよりも多い回数の失敗したログイン試行がクライアントから送信される可能性があります。この検査は、ウェブリクエストにトークンがある場合にのみ適用されます。トークンは、アプリケーション統合 SDK、ならびに CAPTCHA および Challenge のルールアクションによってリクエストに追加されます。詳細については、「[AWS WAF インテリジェントな脅威の軽減におけるトークンの使用](waf-tokens.md)」を参照してください。ルールアクション: Block ラベル: `awswaf:managed:aws:atp:aggregate:volumetric:session:failed_login_response:high` および `awswaf:managed:aws:atp:VolumetricSessionFailedLoginResponseHigh` ルールグループは、次の関連ラベルもリクエストに適用します。関連するアクションはありません。すべてのカウントは 30 分間の時間枠のものです。5 件以上の失敗したリクエストには `awswaf:managed:aws:atp:aggregate:volumetric:session:failed_login_response:medium`、1 件以上の失敗したリクエストには `awswaf:managed:aws:atp:aggregate:volumetric:session:failed_login_response:low`、10 件以上の成功したリクエストには `awswaf:managed:aws:atp:aggregate:volumetric:session:successful_login_response:high`、5 件以上の成功したリクエストには `awswaf:managed:aws:atp:aggregate:volumetric:session:successful_login_response:medium`、1 件以上の成功したリクエストには `awswaf:managed:aws:atp:aggregate:volumetric:session:successful_login_response:low` です。 | # AWS WAF Bot Control ルールグループこのセクションでは、Bot Control マネージドルールグループの動作について説明します。 VendorName: `AWS`、名前: `AWSManagedRulesBotControlRuleSet`、WCU: 50 **注記** このドキュメントでは、このマネージドルールグループの最新の静的バージョンリリースについて説明します。バージョンの変更は、[AWS マネージドルールの変更ログ](aws-managed-rule-groups-changelog.md) の変更ログにレポートされます。他のバージョンの情報については、API コマンド [DescribeManagedRuleGroup](https://docs.aws.amazon.com/waf/latest/APIReference/API_DescribeManagedRuleGroup.html) を使用してください。 AWS マネージドルールルールのルールグループでルール用に公開する情報は、不正なアクターにルールを回避するために必要なものを与えることなく、ルールを使用するために必要なものを提供することを目的としています。 Bot Control の新しいボット分類をリクエストする必要がある場合、またはここで説明されていない追加情報が必要な場合は、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/)にお問い合わせください。 Bot Control マネージドルールグループは、ボットからのリクエストを管理するルールを提供します。ボットは過剰なリソースを消費し、ビジネスメトリクスを歪め、ダウンタイムを引き起こし、悪意のあるアクティビティを実行する可能性があります。 ## 保護レベル Bot Control マネージドルールグループには、次の 2 レベルの保護から選択できます。 + **共通** – ウェブスクレイピングフレームワーク、検索エンジン、自動ブラウザなど、さまざまな自己識別ボットを検出します。このレベルの Bot Control 保護は、静的リクエストデータ分析など、従来のボット検出技術を使用して一般的なボットを識別します。ルールはこれらのボットからのトラフィックにラベルを付け、検証できないものはブロックします。 + **ターゲットを絞った** – 一般的な保護機能に加え、自己識別を行わない高度なボットに対するターゲットを絞った検出機能も追加されています。ターゲットを絞った保護は、レート制限と CAPTCHA およびバックグラウンドブラウザのチャレンジの組み合わせを使用してボットアクティビティを軽減します。 + **`TGT_`** – ターゲットを絞った保護を提供するルールには、`TGT_` で始まる名前が付いています。すべてのターゲットを絞った保護では、ブラウザ調査、フィンガープリント、行動ヒューリスティックなどの検出技術を使用して不正なボットトラフィックを識別します。 + **`TGT_ML_`** – 機械学習を使用するターゲットを絞った保護のルールには、`TGT_ML_` で始まる名前が付いています。これらのルールでは、ウェブサイトトラフィック統計の自動機械学習分析を使用して、分散された調整されたボットアクティビティを示す異常な動作を検出します。は、タイムスタンプ、ブラウザの特性、以前にアクセスした URL などのウェブサイトトラフィックに関する統計 AWS WAF を分析し、Bot Control 機械学習モデルを改善します。機械学習機能はデフォルトで有効になっていますが、ルールグループ設定で無効にすることができます。機械学習が無効になっている場合、 AWS WAF はこれらのルールを評価しません。ターゲットを絞った保護レベルと AWS WAF レートベースのルールステートメントはどちらもレート制限を提供します。この 2 つのオプションの比較については、「[レートベースのルールとターゲットを絞った Bot Control ルールにおけるレート制限のオプション](waf-rate-limiting-options.md)」を参照してください。 ## このルールグループの使用に関する考慮事項このルールグループは、 AWS WAFでのインテリジェントな脅威の軽減保護の一部です。詳細については、「[でのインテリジェントな脅威の軽減 AWS WAF](waf-managed-protections.md)」を参照してください。 **注記** このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。コストを抑え、ウェブトラフィックを希望どおりに管理していることを確実にするには、[でのインテリジェントな脅威軽減のベストプラクティス AWS WAF](waf-managed-protections-best-practices.md) のガイダンスに従ってこのルールグループを使用してください。ボットの予測を改善するために、ターゲットを絞った保護レベルの ML に基づくルールの機械学習 (ML) モデルを定期的に更新しています。ML に基づくルールには、`TGT_ML_` で始まる名前があります。これらのルールによって行われたボット予測に突然、大幅な変更が見られた場合は、アカウントマネージャーを通じて当社に連絡するか、「[AWS サポートセンター](https://console.aws.amazon.com/support/home#/)」でケースを開いてください。 ## このルールグループによって追加されるラベルこのマネージドルールグループは、評価対象のウェブリクエストに保護パック (ウェブ ACL) 内のこのルールグループの後に実行されるルールでも使用できるラベルを追加します。 AWS WAF は、Amazon CloudWatch メトリクスにもラベルを記録します。ラベルとラベルメトリクスに関する一般的な情報については、「[ウェブリクエストのラベル付け](waf-labels.md)」および「[ラベルメトリクスとディメンション](waf-metrics.md#waf-metrics-label)」を参照してください。 ### トークンラベルこのルールグループは、 AWS WAF トークン管理を使用して、 AWS WAF トークンのステータスに従ってウェブリクエストを検査し、ラベル付けします。は、クライアントセッションの追跡と検証にトークン AWS WAF を使用します。トークンおよびトークンの管理の詳細については、「[AWS WAF インテリジェントな脅威の軽減におけるトークンの使用](waf-tokens.md)」を参照してください。ここで説明するラベルコンポーネントについては、「[でのラベル構文と命名要件 AWS WAF](waf-rule-label-requirements.md)」を参照してください。 **クライアントセッションラベル** ラベルには、 AWS WAF トークン管理がクライアントセッションを識別するために使用する一意の識別子`awswaf:managed:token:id:identifier`が含まれています。この識別子は、クライアントが使用していたトークンを破棄した後など、新しいトークンを取得すると変わる可能性があります。 **注記** AWS WAF は、このラベルの Amazon CloudWatch メトリクスを報告しません。 **ブラウザフィンガープリントラベル** ラベルには、 AWS WAF トークン管理がさまざまなクライアントブラウザシグナルから計算する堅牢なブラウザフィンガープリント識別子`awswaf:managed:token:fingerprint:fingerprint-identifier`が含まれています。この識別子は、複数のトークン取得の試行全体で同じままです。フィンガープリント識別子は、単一のクライアントに対して一意ではありません。 **注記** AWS WAF は、このラベルの Amazon CloudWatch メトリクスを報告しません。 **トークンステータスラベル: ラベル名前空間プレフィックス** トークンステータスラベルは、トークン、チャレンジのステータス、およびそれに含まれる CAPTCHA 情報を報告します。各トークンステータスラベルは、次のプレフィクスの 1 つで始まります。 + `awswaf:managed:token:`— トークンの一般的なステータスを報告したり、トークンのチャレンジ情報のステータスを報告したりするために使用されます。 + `awswaf:managed:captcha:`— トークンの CAPTCHA 情報のステータスを報告するために使用されます。 **トークンステータスラベル: ラベル名** プレフィックスに続いて、ラベルの残りの部分には詳細なトークンステータス情報が表示されます。 + `accepted` - リクエストトークンが存在し、以下の内容が含まれています。 + 有効なチャレンジまたは CAPTCHA ソリューション。 + 有効期限が切れていないチャレンジまたは CAPTCHA タイムスタンプ。 + 保護パック (ウェブ ACL) に有効なドメイン仕様。例: ラベル `awswaf:managed:token:accepted` には、ウェブリクエストのトークンに有効なチャレンジソリューション、有効期限が切れていないチャレンジタイムスタンプ、および有効なドメインがあることが示されています。 + `rejected` - リクエストトークンは存在するが、承認基準を満たしていない。トークン管理では、拒否されたラベルに加えて、理由を示すカスタムラベル名前空間と名前が追加されます。 + `rejected:not_solved` — トークンにチャレンジまたは CAPTCHA ソリューションがない。 + `rejected:expired` — 保護パック (ウェブ ACL) に設定されているトークンイミュニティ時間によると、トークンのチャレンジまたは CAPTCHA タイムスタンプの有効期限が切れている。 + `rejected:domain_mismatch` — トークンのドメインが、保護パック (ウェブ ACL) のトークンドメイン設定と一致しない。 + `rejected:invalid` – 指定されたトークンを読み取ることが AWS WAF できませんでした。例: ラベル `awswaf:managed:captcha:rejected` と `awswaf:managed:captcha:rejected:expired` とともに、トークンの CAPTCHA タイムスタンプがウェブ ACL で設定されている CAPTCHA トークンのイミュニティ時間を超えたために、リクエストには有効な CAPTCHA 解決がなかったことが示されています。 + `absent` — リクエストにトークンがないか、トークンマネージャーがそれを読み取れなかった。例: ラベル `awswaf:managed:captcha:absent` には、リクエストにトークンがないことが示されています。 ### Bot Control ラベル Bot Control マネージドルールグループは、名前空間プレフィックス `awswaf:managed:aws:bot-control:` の後にカスタム名前空間およびラベル名が続くラベルを生成します。ルールグループは、リクエストに複数のラベルを追加する場合があります。各ラベルは、Bot Control ルールの検出結果を反映しています。 + `awswaf:managed:aws:bot-control:bot:` – リクエストに関連付けられたボットに関する情報。 + `awswaf:managed:aws:bot-control:bot:name:` – ボット名は (利用可能な場合)、たとえばカスタム名前空間 `bot:name:slurp`、`bot:name:googlebot`、`bot:name:pocket_parser`。 + `awswaf:managed:aws:bot-control:bot:name:` – WBA 署名の RFC 製品トークンを使用して特定のボットを識別します。これは、特定のボットの詳細なカスタムルールを作成するために使用されます。たとえば、他のクローラを許可`GoogleBot`し、レート制限します。 + `awswaf:managed:aws:bot-control:bot:category:` – ボットのカテゴリ AWS WAF。 `bot:category:search_engine`やなどで定義されます`bot:category:content_fetcher`。 + `awswaf:managed:aws:bot-control:bot:account:` – Amazon Bedrock エージェントコアを使用するボットのみ。このラベルには、エージェントを所有する AWS アカウントを一意に識別する不透明なハッシュが含まれています。このラベルを使用して、ログにアカウント IDs を公開することなく、特定の AWS アカウントのボットを許可、ブロック、またはレート制限するカスタムルールを作成します。 + `awswaf:managed:aws:bot-control:bot:web_bot_auth:` – ウェブボット認証 (WBA) 検証がリクエストに対して実行されるときに適用されます。ステータスサフィックスは検証結果を示します。 + `web_bot_auth:verified` – パブリックキーディレクトリに対して正常に検証された署名 + `web_bot_auth:invalid` – 署名は存在しますが、暗号検証は失敗しました + `web_bot_auth:expired` – 署名が期限切れの暗号キーを使用 + `web_bot_auth:unknown_bot` – キーディレクトリにキー ID が見つかりません **注記** `web_bot_auth:verified` ラベルが存在する場合、ルール`CategoryAI`と `TGT_TokenAbsent`ルールが一致しないため、検証済みの WBA ホストを続行できます。 + `awswaf:managed:aws:bot-control:bot:organization:` – ボットのパブリッシャー (例: `bot:organization:google`)。 + `awswaf:managed:aws:bot-control:bot:verified` – 自己を識別し、Bot Control が検証できたボットを示すために使用されます。これは、一般的な望ましいボットに使用され、`bot:category:search_engine` のようなカテゴリラベルや `bot:name:googlebot` のような名前ラベルと組み合わせると便利です。 **注記** Bot Control は、ウェブリクエストの送信元の IP アドレスを使用して、ボットが検証されているかどうかを判断します。 AWS WAF 転送される IP 設定を使用して別の IP アドレスソースを検査するように設定することはできません。プロキシまたはロードバランサーを介してルーティングするボットを検証した場合、Bot Control ルールグループの前に実行するルールを追加してこの問題に対処します。転送された IP アドレスを使用し、検証済みのボットからのリクエストを明示的に許可するように新しいルールを設定します。転送した IP アドレスの詳細については、「[で転送された IP アドレスを使用する AWS WAF](waf-rule-statement-forwarded-ip-address.md)」を参照してください。 + `awswaf:managed:aws:bot-control:bot:vendor:` – 検証済みボットのベンダーまたはオペレーターを識別します。現在、Agentcore でのみ使用できます。を使用して、個々のボット名に関係なく、特定のボットベンダーを許可またはブロックするカスタムルールを作成します。 + `awswaf:managed:aws:bot-control:bot:user_triggered:verified` – 検証済みのボットに類似しているが、エンドユーザーによって直接呼び出される可能性のあるボットを示すために使用されます。このカテゴリのボットは、Bot Control のルールによって未検証のボットのように扱われます。 + `awswaf:managed:aws:bot-control:bot:developer_platform:verified` – 検証済みのボットに類似しているが、Google Apps Script などのデベロッパープラットフォームによってスクリプト作成のために使用されるボットを示すために使用されます。このカテゴリのボットは、Bot Control のルールによって未検証のボットのように扱われます。 + `awswaf:managed:aws:bot-control:bot:unverified` – 自己を識別するボットを示すために使用されるため、名前を付けて分類できます。ただし、そのボットのアイデンティティを個別に検証する場合に使用する情報は公開されていません。これらの種類のボットシグネチャは改ざんされる可能性があるため、未検証として扱われます。 + `awswaf:managed:aws:bot-control:targeted: ` — Bot Control の対象となる保護に固有のラベルに使用されます。 + `awswaf:managed:aws:bot-control:signal:` および `awswaf:managed:aws:bot-control:targeted:signal: ` — 一部の状況において、リクエストに関する追加情報を提供するために使用されます。シグナルラベルの例は、次のとおりです。これは網羅的なリストではありません。 + `awswaf:managed:aws:bot-control:signal:cloud_service_provider:` – リクエストのクラウドサービスプロバイダー (CSP) を示します。CSP の例には Amazon Web Services インフラストラクチャの `aws`、Google Cloud Platform (GCP) インフラストラクチャの `gcp`、Microsoft Azure クラウドサービスの `azure`、Oracle Cloud サービスの `oracle` などがあります。 + `awswaf:managed:aws:bot-control:targeted:signal:browser_automation_extension` — Selenium IDE など、自動化をサポートするブラウザー拡張機能が検出されたことを示します。このラベルは、ユーザーがこのタイプの拡張をインストールすると、ユーザーが自発的に使用していない場合でも追加されます。このためのラベル照合ルールを実装する場合は、ルールロジックとアクション設定で誤検出が発生する可能性があることに注意してください。たとえば、オートメーションが使用されていることを確保するために、Block の代わりに CAPTCHA アクションを使用したり、このラベルマッチを他のラベルマッチと組み合わせたりすることができます。 + `awswaf:managed:aws:bot-control:signal:automated_browser` — リクエストに、クライアントブラウザが自動化されている可能性があることを示す要素が含まれていることを示します。 + `awswaf:managed:aws:bot-control:targeted:signal:automated_browser` – リクエストの AWS WAF トークンに、クライアントブラウザが自動化されている可能性があることを示すインジケータが含まれていることを示します。 `DescribeManagedRuleGroup` を呼び出すことにより、API を介してルールグループのすべてのラベルを取得できます。ラベルは、応答の `AvailableLabels` プロパティにリストされています。 Bot Control マネージドルールグループは、一般的に許可されている検証可能な一連のボットにラベルを適用します。ルールグループは、これらの検証済みボットをブロックしません。必要に応じて、Bot Control マネージドルールグループによって適用されたラベルを使用するカスタムルールを記述することで、それらのボットまたはそのサブセットをブロックできます。これと例の詳細については、「[AWS WAF ボットコントロール](waf-bot-control.md)」を参照してください。 ## Bot Control のルールリストこのセクションには Bot Control ルールが表示されています。 **注記** このドキュメントでは、このマネージドルールグループの最新の静的バージョンリリースについて説明します。バージョンの変更は、[AWS マネージドルールの変更ログ](aws-managed-rule-groups-changelog.md) の変更ログにレポートされます。他のバージョンの情報については、API コマンド [DescribeManagedRuleGroup](https://docs.aws.amazon.com/waf/latest/APIReference/API_DescribeManagedRuleGroup.html) を使用してください。 AWS マネージドルールルールのルールグループでルール用に公開する情報は、不正なアクターにルールを回避するために必要なものを与えることなく、ルールを使用するために必要なものを提供することを目的としています。 Bot Control の新しいボット分類をリクエストする必要がある場合、またはここで説明されていない追加情報が必要な場合は、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/)にお問い合わせください。 | ルール名 | 説明 | | --- | --- | | CategoryAdvertising | 広告目的で使用されるボットを検査します。例えば、プログラムによるウェブサイトへのアクセスを必要とするサードパーティーの広告サービスを使用する場合があります。未検証のボットにのみ適用されるルールアクション: Block ラベル: `awswaf:managed:aws:bot-control:bot:category:advertising` および `awswaf:managed:aws:bot-control:CategoryAdvertising` 検証済みボットについては、ルールグループはこのルールに一致もしないし、アクションを実行しませんが、ボット名とカテゴリにラベル付け、また、ラベル `awswaf:managed:aws:bot-control:bot:verified` を追加します。 | | CategoryArchiver | アーカイブ目的で使用されるボットを検査します。これらのボットは、アーカイブを作成する目的でウェブをクロールし、コンテンツをキャプチャします。未検証のボットにのみ適用されるルールアクション: Block ラベル: `awswaf:managed:aws:bot-control:bot:category:archiver` および `awswaf:managed:aws:bot-control:CategoryArchiver` 検証済みボットについては、ルールグループはこのルールに一致もしないし、アクションを実行しませんが、ボット名とカテゴリにラベル付け、また、ラベル `awswaf:managed:aws:bot-control:bot:verified` を追加します。 | | CategoryContentFetcher | ユーザーに代わってアプリケーションのウェブサイトにアクセスし、RSS フィードのようなコンテンツを取得したり、コンテンツを検証したりするボットを検査します。未検証のボットにのみ適用されるルールアクション: Block ラベル: `awswaf:managed:aws:bot-control:bot:category:content_fetcher` および `awswaf:managed:aws:bot-control:CategoryContentFetcher` 検証済みボットについては、ルールグループはこのルールに一致もしないし、アクションを実行しませんが、ボット名とカテゴリにラベル付け、また、ラベル `awswaf:managed:aws:bot-control:bot:verified` を追加します。 | | CategoryEmailClient | アプリケーションのウェブサイトを指し示すメール内のリンクをチェックするボットを検査します。これには、E メール内のリンクを確認したり、疑わしい電子メールにフラグを立てたりする企業や E メールプロバイダーによって実行されるボットが含まれます。未検証のボットにのみ適用されるルールアクション: Block ラベル: `awswaf:managed:aws:bot-control:bot:category:email_client` および `awswaf:managed:aws:bot-control:CategoryEmailClient` 検証済みボットについては、ルールグループはこのルールに一致もしないし、アクションを実行しませんが、ボット名とカテゴリにラベル付け、また、ラベル `awswaf:managed:aws:bot-control:bot:verified` を追加します。 | | CategoryHttpLibrary | さまざまなプログラミング言語の HTTP ライブラリからボットによって生成されたリクエストを検査します。これらには、許可またはモニタリングする API リクエストが含まれる場合があります。未検証のボットにのみ適用されるルールアクション: Block ラベル: `awswaf:managed:aws:bot-control:bot:category:http_library` および `awswaf:managed:aws:bot-control:CategoryHttpLibrary` 検証済みボットについては、ルールグループはこのルールに一致もしないし、アクションを実行しませんが、ボット名とカテゴリにラベル付け、また、ラベル `awswaf:managed:aws:bot-control:bot:verified` を追加します。 | | CategoryLinkChecker | 壊れたリンクをチェックするボットを検査します。未検証のボットにのみ適用されるルールアクション: Block ラベル: `awswaf:managed:aws:bot-control:bot:category:link_checker` および `awswaf:managed:aws:bot-control:CategoryLinkChecker` 検証済みボットについては、ルールグループはこのルールに一致もしないし、アクションを実行しませんが、ボット名とカテゴリにラベル付け、また、ラベル `awswaf:managed:aws:bot-control:bot:verified` を追加します。 | | CategoryMiscellaneous | 他のカテゴリに一致しないその他のボットを検査します。未検証のボットにのみ適用されるルールアクション: Block ラベル: `awswaf:managed:aws:bot-control:bot:category:miscellaneous` および `awswaf:managed:aws:bot-control:CategoryMiscellaneous` 検証済みボットについては、ルールグループはこのルールに一致もしないし、アクションを実行しませんが、ボット名とカテゴリにラベル付け、また、ラベル `awswaf:managed:aws:bot-control:bot:verified` を追加します。 | | CategoryMonitoring | モニタリング目的で使用されるボットを検査します。例えば、パフォーマンスや稼働時間などをモニタリングするために、アプリケーションのウェブサイトに定期的に ping を送信するボットモニタリングサービスを使用することができます。未検証のボットにのみ適用されるルールアクション: Block ラベル: `awswaf:managed:aws:bot-control:bot:category:monitoring` および `awswaf:managed:aws:bot-control:CategoryMonitoring` 検証済みボットについては、ルールグループはこのルールに一致もしないし、アクションを実行しませんが、ボット名とカテゴリにラベル付け、また、ラベル `awswaf:managed:aws:bot-control:bot:verified` を追加します。 | | CategoryPagePreview | コンテンツがメッセージングプラットフォーム、ソーシャルメディア、またはコラボレーションツールで共有されているときに、ページプレビューを生成し、プレビューをリンクするボットを検査します。未検証のボットにのみ適用されるルールアクション: Block ラベル: `awswaf:managed:aws:bot-control:bot:category:page_preview` および `awswaf:managed:aws:bot-control:CategoryPagePreview` 検証済みボットについては、ルールグループはこのルールに一致もしないし、アクションを実行しませんが、ボット名とカテゴリにラベル付け、また、ラベル `awswaf:managed:aws:bot-control:bot:verified` を追加します。 | | CategoryScrapingFramework | ウェブサイトからのコンテンツのクロールと抽出を自動化するために使用される、ウェブスクレイピングフレームワークからのボットを検査します。未検証のボットにのみ適用されるルールアクション: Block ラベル: `awswaf:managed:aws:bot-control:bot:category:scraping_framework` および `awswaf:managed:aws:bot-control:CategoryScrapingFramework` 検証済みボットについては、ルールグループはこのルールに一致もしないし、アクションを実行しませんが、ボット名とカテゴリにラベル付け、また、ラベル `awswaf:managed:aws:bot-control:bot:verified` を追加します。 | | CategorySearchEngine | ウェブサイトをクロールしてコンテンツをインデックス化し、その情報を検索エンジンの結果に利用できるようにする検索エンジンボットを検査します。未検証のボットにのみ適用されるルールアクション: Block ラベル: `awswaf:managed:aws:bot-control:bot:category:search_engine` および `awswaf:managed:aws:bot-control:CategorySearchEngine` 検証済みボットについては、ルールグループはこのルールに一致もしないし、アクションを実行しませんが、ボット名とカテゴリにラベル付け、また、ラベル `awswaf:managed:aws:bot-control:bot:verified` を追加します。 | | CategorySecurity | ウェブアプリケーションの脆弱性をスキャンしたり、セキュリティ監査を実施したりするボットを検査します。例えば、ウェブアプリケーションのセキュリティをスキャン、モニタリング、または監査するサードパーティーのセキュリティベンダーを利用することができます。未検証のボットにのみ適用されるルールアクション: Block ラベル: `awswaf:managed:aws:bot-control:bot:category:security` および `awswaf:managed:aws:bot-control:CategorySecurity` 検証済みボットについては、ルールグループはこのルールに一致もしないし、アクションを実行しませんが、ボット名とカテゴリにラベル付け、また、ラベル `awswaf:managed:aws:bot-control:bot:verified` を追加します。 | | CategorySeo | 検索エンジンの最適化に使用されるボットを検査します。例えば、検索エンジンのランキングを向上させるために、サイトをクロールする検索エンジンツールを使用することができます。未検証のボットにのみ適用されるルールアクション: Block ラベル: `awswaf:managed:aws:bot-control:bot:category:seo` および `awswaf:managed:aws:bot-control:CategorySeo` 検証済みボットについては、ルールグループはこのルールに一致もしないし、アクションを実行しませんが、ボット名とカテゴリにラベル付け、また、ラベル `awswaf:managed:aws:bot-control:bot:verified` を追加します。 | | CategorySocialMedia | ユーザーがコンテンツを共有するときに、コンテンツの概要を提供するためにソーシャルメディアプラットフォームで使用されるボットを検査します。未検証のボットにのみ適用されるルールアクション: Block ラベル: `awswaf:managed:aws:bot-control:bot:category:social_media` および `awswaf:managed:aws:bot-control:CategorySocialMedia` 検証済みボットについては、ルールグループはこのルールに一致もしないし、アクションを実行しませんが、ボット名とカテゴリにラベル付け、また、ラベル `awswaf:managed:aws:bot-control:bot:verified` を追加します。 | | CategoryWebhooks | HTTP コールバックを通じて、あるアプリケーションから別のアプリケーションに自動的に通知とデータ更新を配信するボットを検査します。未検証のボットにのみ適用されるルールアクション: Block ラベル: `awswaf:managed:aws:bot-control:bot:category:webhooks` および `awswaf:managed:aws:bot-control:CategoryWebhooks` 検証済みボットについては、ルールグループはこのルールに一致もしないし、アクションを実行しませんが、ボット名とカテゴリにラベル付け、また、ラベル `awswaf:managed:aws:bot-control:bot:verified` を追加します。 | | CategoryAI | 人工知能 (AI) ボットを検査します。このルールは、ボットの検証の有無にかかわらず、すべての一致のアクションに適用します。ルールアクション: Block ラベル: `awswaf:managed:aws:bot-control:bot:category:ai` および `awswaf:managed:aws:bot-control:CategoryAI` 検証済みボットの場合、ルールグループはこのルールに一致し、アクションを実行します。さらに、ボット名とカテゴリのラベル付け、ルールのラベル付け、ラベル `awswaf:managed:aws:bot-control:bot:verified` が追加されます。 | | SignalAutomatedBrowser | 検証済みのボットからのリクエストを検査し、クライアントブラウザが自動化されている可能性があることを示す要素があるかどうかを確認します。自動ブラウザはテストやスクレイピングに使用できます。例えば、以下のようなタイプのブラウザを使用して、アプリケーションウェブサイトのモニタリングや検証を行うことができます。ルールアクション: Block ラベル: `awswaf:managed:aws:bot-control:signal:automated_browser` および `awswaf:managed:aws:bot-control:SignalAutomatedBrowser` 検証済みボットの場合、ルールグループはこのルールに一致せず、シグナルラベルやルールラベルは適用されません。 | | SignalKnownBotDataCenter | 検証済みのボットからではないリクエストを検査し、ボットが通常使用するデータセンターの要素があるかどうかを確認します。ルールアクション: Block ラベル: `awswaf:managed:aws:bot-control:signal:known_bot_data_center` および `awswaf:managed:aws:bot-control:SignalKnownBotDataCenter` 検証済みボットの場合、ルールグループはこのルールに一致せず、シグナルラベルやルールラベルは適用されません。 | | SignalNonBrowserUserAgent | 検証済みのボットからではないリクエストを検査し、ウェブブラウザからではないと考えられるユーザーエージェント文字列を検査します。このカテゴリには API リクエストが含まれる場合があります。ルールアクション: Block ラベル: `awswaf:managed:aws:bot-control:signal:non_browser_user_agent` および `awswaf:managed:aws:bot-control:SignalNonBrowserUserAgent` 検証済みボットの場合、ルールグループはこのルールに一致せず、シグナルラベルやルールラベルは適用されません。 | | TGT\$1VolumetricIpTokenAbsent | 検証済みのボットからではないリクエストを検査し、過去 5 分間の単一クライアントからのリクエストで、有効なチャレンジトークンが含まれていないものが 5 つ以上あるかどうかを確認します。トークンの詳細については、「[AWS WAF インテリジェントな脅威の軽減におけるトークンの使用](waf-tokens.md)」を参照してください。同じクライアントからのリクエストで、最近トークンの欠落が発生するようになったという場合は、このルールがトークンを有するリクエストに一致する可能性があります。このルールが適用されるしきい値は、レイテンシーによって若干異なる場合があります。このルールは、トークンラベル `awswaf:managed:token:absent` とは異なる方法で欠落したトークンを処理します。トークンラベルは、トークンがない個々のリクエストにラベルを付けます。このルールは、各クライアント IP のトークンが欠落しているリクエスト数を把握し、制限を超過するクライアントに一致させます。ルールアクション: Challenge ラベル: `awswaf:managed:aws:bot-control:targeted:aggregate:volumetric:ip:token_absent` および `awswaf:managed:aws:bot-control:TGT_VolumetricIpTokenAbsent` | | TGT\$1TokenAbsent | 有効なチャレンジトークンを含まない検証済みのボットからのリクエストを検査します。トークンの詳細については、「[AWS WAF インテリジェントな脅威の軽減におけるトークンの使用](waf-tokens.md)」を参照してください。ルールアクション: Count ラベル: `awswaf:managed:aws:bot-control:TGT_TokenAbsent` | | TGT\$1VolumetricSession | 5 分間で、単一クライアントセッションの検証済みのボットからではないリクエスト数が異常に多いかどうかを検査します。評価は、履歴トラフィックパターンを使用してが AWS WAF 維持する標準ボリューメトリックベースラインとの比較に基づいています。この検査は、ウェブリクエストにトークンがある場合にのみ適用されます。トークンは、アプリケーション統合 SDK、ならびに CAPTCHA および Challenge のルールアクションによってリクエストに追加されます。詳細については、「[AWS WAF インテリジェントな脅威の軽減におけるトークンの使用](waf-tokens.md)」を参照してください。このルールは、有効にしてから有効になるまでに 5 分かかることがあります。Bot Control は、現在のトラフィックをが AWS WAF 計算するトラフィックベースラインと比較することで、ウェブトラフィックの異常な動作を識別します。ルールアクション: CAPTCHA ラベル: `awswaf:managed:aws:bot-control:targeted:aggregate:volumetric:session:high` および `awswaf:managed:aws:bot-control:TGT_VolumetricSession` ルールグループは、最小しきい値を超える中規模および低ボリュームのリクエストに次のラベルを適用します。これらのレベルでは、クライアントが検証されているかどうかにかかわらず、ルールは何も実行しません。すなわち、`awswaf:managed:aws:bot-control:targeted:aggregate:volumetric:session:medium` および `awswaf:managed:aws:bot-control:targeted:aggregate:volumetric:session:low`。 | | TGT\$1VolumetricSessionMaximum | 5 分間で、単一クライアントセッションの検証済みのボットからではないリクエスト数が異常に多いかどうかを検査します。評価は、履歴トラフィックパターンを使用してが AWS WAF 維持する標準ボリューメトリックベースラインとの比較に基づいています。このルールは、評価における最大の信頼度を示します。この検査は、ウェブリクエストにトークンがある場合にのみ適用されます。トークンは、アプリケーション統合 SDK、ならびに CAPTCHA および Challenge のルールアクションによってリクエストに追加されます。詳細については、「[AWS WAF インテリジェントな脅威の軽減におけるトークンの使用](waf-tokens.md)」を参照してください。このルールは、有効にしてから有効になるまでに 5 分かかることがあります。Bot Control は、現在のトラフィックをが AWS WAF 計算するトラフィックベースラインと比較することで、ウェブトラフィックの異常な動作を識別します。ルールアクション: Block ラベル: `awswaf:managed:aws:bot-control:targeted:aggregate:volumetric:session:maximum` および `awswaf:managed:aws:bot-control:TGT_VolumetricSessionMaximum` | | TGT\$1SignalAutomatedBrowser | クライアントブラウザが自動化されている可能性があることを示す要素がないか、リクエストのトークンを検査します。詳細については、「[AWS WAF トークンの特性](waf-tokens-details.md)」を参照してください。この検査は、ウェブリクエストにトークンがある場合にのみ適用されます。トークンは、アプリケーション統合 SDK、ならびに CAPTCHA および Challenge のルールアクションによってリクエストに追加されます。詳細については、「[AWS WAF インテリジェントな脅威の軽減におけるトークンの使用](waf-tokens.md)」を参照してください。ルールアクション: CAPTCHA ラベル: `awswaf:managed:aws:bot-control:targeted:signal:automated_browser` および `awswaf:managed:aws:bot-control:TGT_SignalAutomatedBrowser` | | TGT\$1SignalBrowserAutomationExtension | Selenium IDE などの自動化を支援するブラウザ拡張機能の存在を示す検証済みのボットからではないリクエストを検査します。このルールの一致は、ユーザーがこのタイプの拡張をインストールすると、ユーザーが自発的に使用していない場合でも追加されます。この検査は、ウェブリクエストにトークンがある場合にのみ適用されます。トークンは、アプリケーション統合 SDK、ならびに CAPTCHA および Challenge のルールアクションによってリクエストに追加されます。詳細については、「[AWS WAF インテリジェントな脅威の軽減におけるトークンの使用](waf-tokens.md)」を参照してください。ルールアクション: CAPTCHA ラベル: `awswaf:managed:aws:bot-control:targeted:signal:browser_automation_extension` および `awswaf:managed:aws:bot-control:TGT_SignalBrowserAutomationExtension` | | TGT\$1SignalBrowserInconsistency | 検証済みボットからではないリクエストを検査し、一貫性のないブラウザインテロゲーションデータがないかを確認します。詳細については、「[AWS WAF トークンの特性](waf-tokens-details.md)」を参照してください。この検査は、ウェブリクエストにトークンがある場合にのみ適用されます。トークンは、アプリケーション統合 SDK、ならびに CAPTCHA および Challenge のルールアクションによってリクエストに追加されます。詳細については、「[AWS WAF インテリジェントな脅威の軽減におけるトークンの使用](waf-tokens.md)」を参照してください。ルールアクション: CAPTCHA ラベル: `awswaf:managed:aws:bot-control:targeted:signal:browser_inconsistency` および `awswaf:managed:aws:bot-control:TGT_SignalBrowserInconsistency` | | TGT\$1ML\$1CoordinatedActivityLow, TGT\$1ML\$1CoordinatedActivityMedium, TGT\$1ML\$1CoordinatedActivityHigh | 検証済みボットからではないリクエストを検査し、分散、および調整されたボットアクティビティと一致する異常な動作があるかどうかを確認します。ルールレベルは、リクエストのグループが協調攻撃に参加しているかどうかの信頼度のレベルを示します。これらのルールは、ルールグループが機械学習 (ML) を使用するように設定されている場合にのみ実行されます。この場合の設定については、「[AWS WAF Bot Control マネージドルールグループをウェブ ACL に追加する](waf-bot-control-rg-using.md)」を参照してください。このルールが適用するしきい値は、レイテンシーによって若干異なる場合があります。ルールアクションが適用される前に、いくつかのリクエストが制限を超えることがあります。 AWS WAF は、ウェブサイトトラフィック統計の機械学習分析を通じてこの検査を実行します。は、数分ごとにウェブトラフィック AWS WAF を分析し、多くの IP アドレスに分散されている低強度で長期間のボットの検出のために分析を最適化します。これらのルールは、協調攻撃が進行中ではないと判断される前に、ごく少数のリクエストに一致する場合があります。そのため、表示された一致が 1 つか 2 つしかない場合は、結果が誤検出である可能性があります。ただし、これらのルールからの一致が多数表示されている場合は、協調攻撃を受けていると考えられます。 ML オプションで Bot Control ターゲットルールを有効にしてから、これらのルールが有効になるまでに最大 24 時間かかることがあります。Bot Control は、現在のトラフィックをが計算した AWS WAF トラフィックベースラインと比較することで、ウェブトラフィックの異常な動作を識別します。は、Bot Control のターゲットルールを ML オプションで使用している間 AWS WAF のみベースラインを計算し、意味のあるベースラインを確立するまでに最大 24 時間かかる場合があります。これらのルールの機械学習モデルを定期的に更新して、ボットの予測を改善します。これらのルールによってボット予測が突然大幅に変更された場合は、アカウントマネージャーに連絡するか、「[AWS サポートセンター](https://console.aws.amazon.com/support/home#/)」でケースを開きます。ルールのアクション: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-bot.html) ラベル: `awswaf:managed:aws:bot-control:targeted:aggregate:coordinated_activity:low\|medium\|high` および `awswaf:managed:aws:bot-control:TGT_ML_CoordinatedActivityLow\|Medium\|High` | | TGT\$1TokenReuseIpLow, TGT\$1TokenReuseIpMedium, TGT\$1TokenReuseIpHigh | 過去 5 分間に、検証済みのボットからではないリクエストを検査し、複数の IP 間で単一のトークンが使用されているかを確認します。各レベルには、個別の IP 数制限があります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-bot.html) このルールが適用するしきい値は、レイテンシーによって若干異なる場合があります。ルールアクションが適用される前に、いくつかのリクエストが制限を超えることがあります。ルールのアクション: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-bot.html) ラベル: `awswaf:managed:aws:bot-control:targeted:aggregate:volumetric:session:token_reuse:ip:low\|medium\|high` および `awswaf:managed:aws:bot-control:TGT_TokenReuseIpLow\|Medium\|High` | | TGT\$1TokenReuseCountryLow, TGT\$1TokenReuseCountryMedium, TGT\$1TokenReuseCountryHigh | 過去 5 分間に、検証済みのボットからではないリクエストを検査し、複数の国/地域で 1 つのトークンを使用しているかどうかを確認します。各レベルには、個別の国/地域の数に制限があります: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-bot.html) このルールが適用するしきい値は、レイテンシーによって若干異なる場合があります。ルールアクションが適用される前に、いくつかのリクエストが制限を超えることがあります。ルールのアクション: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-bot.html) ラベル: `awswaf:managed:aws:bot-control:targeted:aggregate:volumetric:session:token_reuse:country:low\|medium\|high` および `awswaf:managed:aws:bot-control:TGT_TokenReuseCountryLow\|Medium\|High` | | TGT\$1TokenReuseAsnLow, TGT\$1TokenReuseAsnMedium, TGT\$1TokenReuseAsnHigh | 検証済みボットからのものではないリクエストを検査し、過去 5 分間に、複数のネットワーク AS 番号 (ASN) で 1 つのトークンが使用されるかどうかを確認します。各レベルには、個別の ASN 数制限があります: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-bot.html) このルールが適用するしきい値は、レイテンシーによって若干異なる場合があります。ルールアクションが適用される前に、いくつかのリクエストが制限を超えることがあります。ルールのアクション: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-bot.html) ラベル: `awswaf:managed:aws:bot-control:targeted:aggregate:volumetric:session:token_reuse:asn:low\|medium\|high` および `awswaf:managed:aws:bot-control:TGT_TokenReuseAsnLow\|Medium\|High` | # AWS WAF 分散サービス拒否 (DDoS) 防止ルールグループこのセクションでは、分散型サービス拒否 (DDoS) 攻撃に対する保護の AWS WAF マネージドルールグループについて説明します。 VendorName: `AWS`、名前: `AWSManagedRulesAntiDDoSRuleSet`、WCU: 50 **注記** このドキュメントでは、このマネージドルールグループの最新の静的バージョンリリースについて説明します。バージョンの変更は、[AWS マネージドルールの変更ログ](aws-managed-rule-groups-changelog.md) の変更ログにレポートされます。他のバージョンの情報については、API コマンド [DescribeManagedRuleGroup](https://docs.aws.amazon.com/waf/latest/APIReference/API_DescribeManagedRuleGroup.html) を使用してください。 AWS マネージドルールのルールグループでルール用に公開する情報は、ルールを回避するために必要なものを不正なアクターに与えることなく、ルールを使用するために必要なものを提供することを目的としています。ここに記載されている以上の情報が必要な場合は、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/) にお問い合わせください。 DDoS 対策マネージドルールグループは、DDoS 攻撃に関与しているか、その可能性が高いリクエストを検出して管理するルールを提供します。さらに、ルールグループは、可能性の高いイベント中に評価されるすべてのリクエストにラベルを付けます。 ## このルールグループの使用に関する考慮事項このルールグループは、DDoS 攻撃を受けているリソースに送信されるウェブリクエストをソフトかつハードに軽減します。さまざまな脅威レベルを検出するには、両方の緩和タイプの機密性を高、中、または低の疑惑レベルに調整できます。 + **ソフトな軽減** — ルールグループは、チャレンジインタースティシャルを処理できるリクエストに応答して、サイレントブラウザチャレンジを送信できます。チャレンジを実行するための要件については、「[CAPTCHA および Challenge アクション動作](waf-captcha-and-challenge-actions.md)」を参照してください。 + **ハードな軽減** — ルールグループはリクエストを完全にブロックできます。ルールグループの動作方法とその設定方法の詳細については、「[Anti-DDoS マネージドルールグループを使用した高度な AWS WAF Anti-DDoS 保護](waf-anti-ddos-advanced.md)」を参照してください。 **注記** このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。このルールグループは、 AWS WAFでのインテリジェントな脅威の軽減保護の一部です。詳細については、「[でのインテリジェントな脅威の軽減 AWS WAF](waf-managed-protections.md)」を参照してください。コストを最小限に抑え、トラフィック管理を最適化するには、ベストプラクティスガイドラインに従ってこのルールグループを使用します。「[でのインテリジェントな脅威軽減のベストプラクティス AWS WAF](waf-managed-protections-best-practices.md)」を参照してください。 ## このルールグループによって追加されるラベルこのマネージドルールグループは、評価対象のウェブリクエストに保護パック (ウェブ ACL) 内のこのルールグループの後に実行されるルールでも使用できるラベルを追加します。 AWS WAF は、Amazon CloudWatch メトリクスにもラベルを記録します。ラベルとラベルメトリクスに関する一般的な情報については、「[ウェブリクエストのラベル付け](waf-labels.md)」および「[ラベルメトリクスとディメンション](waf-metrics.md#waf-metrics-label)」を参照してください。 ### トークンラベルこのルールグループは、 AWS WAF トークン管理を使用して、 AWS WAF トークンのステータスに従ってウェブリクエストを検査し、ラベル付けします。は、クライアントセッションの追跡と検証にトークン AWS WAF を使用します。トークンおよびトークンの管理の詳細については、「[AWS WAF インテリジェントな脅威の軽減におけるトークンの使用](waf-tokens.md)」を参照してください。ここで説明するラベルコンポーネントについては、「[でのラベル構文と命名要件 AWS WAF](waf-rule-label-requirements.md)」を参照してください。 **クライアントセッションラベル** ラベルには、 AWS WAF トークン管理がクライアントセッションを識別するために使用する一意の識別子`awswaf:managed:token:id:identifier`が含まれています。この識別子は、クライアントが使用していたトークンを破棄した後など、新しいトークンを取得すると変わる可能性があります。 **注記** AWS WAF はこのラベルの Amazon CloudWatch メトリクスを報告しません。 **ブラウザフィンガープリントラベル** ラベルには、 AWS WAF トークン管理がさまざまなクライアントブラウザシグナルから計算する堅牢なブラウザフィンガープリント識別子`awswaf:managed:token:fingerprint:fingerprint-identifier`が含まれています。この識別子は、複数のトークン取得の試行全体で同じままです。フィンガープリント識別子は、単一のクライアントに対して一意ではありません。 **注記** AWS WAF はこのラベルの Amazon CloudWatch メトリクスを報告しません。 **トークンステータスラベル: ラベル名前空間プレフィックス** トークンステータスラベルは、トークン、チャレンジのステータス、およびそれに含まれる CAPTCHA 情報を報告します。各トークンステータスラベルは、次のプレフィクスの 1 つで始まります。 + `awswaf:managed:token:`— トークンの一般的なステータスを報告したり、トークンのチャレンジ情報のステータスを報告したりするために使用されます。 + `awswaf:managed:captcha:`— トークンの CAPTCHA 情報のステータスを報告するために使用されます。 **トークンステータスラベル: ラベル名** プレフィックスに続いて、ラベルの残りの部分には詳細なトークンステータス情報が表示されます。 + `accepted` - リクエストトークンが存在し、以下の内容が含まれています。 + 有効なチャレンジまたは CAPTCHA ソリューション。 + 有効期限が切れていないチャレンジまたは CAPTCHA タイムスタンプ。 + 保護パック (ウェブ ACL) に有効なドメイン仕様。例: ラベル `awswaf:managed:token:accepted` には、ウェブリクエストのトークンに有効なチャレンジソリューション、有効期限が切れていないチャレンジタイムスタンプ、および有効なドメインがあることが示されています。 + `rejected` - リクエストトークンは存在するが、承認基準を満たしていない。トークン管理では、拒否されたラベルに加えて、理由を示すカスタムラベル名前空間と名前が追加されます。 + `rejected:not_solved` — トークンにチャレンジまたは CAPTCHA ソリューションがない。 + `rejected:expired` — 保護パック (ウェブ ACL) に設定されているトークンイミュニティ時間によると、トークンのチャレンジまたは CAPTCHA タイムスタンプの有効期限が切れている。 + `rejected:domain_mismatch` — トークンのドメインが、保護パック (ウェブ ACL) のトークンドメイン設定と一致しない。 + `rejected:invalid` – 指定されたトークンを読み取ることが AWS WAF できませんでした。例: ラベル `awswaf:managed:captcha:rejected` と `awswaf:managed:captcha:rejected:expired` とともに、トークンの CAPTCHA タイムスタンプがウェブ ACL で設定されている CAPTCHA トークンのイミュニティ時間を超えたために、リクエストには有効な CAPTCHA 解決がなかったことが示されています。 + `absent` — リクエストにトークンがないか、トークンマネージャーがそれを読み取れなかった。例: ラベル `awswaf:managed:captcha:absent` には、リクエストにトークンがないことが示されています。 ### DDoS 対策ラベル DDoS 対策マネージドルールグループは、名前空間プレフィックス `awswaf:managed:aws:anti-ddos:` が付いたラベルを生成し、その後にカスタム名前空間およびラベル名が付いたラベルを生成します。各ラベルには、DDoS 対策の検出結果の一部が反映されています。ルールグループは、個々のルールによって追加されるラベルに加えて、次のラベルをリクエストに複数追加できます。 + `awswaf:managed:aws:anti-ddos:event-detected` – マネージドルールグループが DDoS イベントを検出する保護されたリソースにリクエストが送信されることを示します。マネージドルールグループは、リソースへのトラフィックがリソースのトラフィックベースラインから大幅に逸脱した場合にイベントを検出します。ルールグループは、この状態のリソースに送信されるすべてのリクエストにこのラベルを追加するため、正当なトラフィックと攻撃トラフィックはこのラベルを取得します。 + `awswaf:managed:aws:anti-ddos:ddos-request` – リクエストがイベントに参加している疑いのあるソースからのものであることを示します。ルールグループは、一般ラベルに加えて、信頼度を示す次のラベルを追加します。 `awswaf:managed:aws:anti-ddos:low-suspicion-ddos-request` – DDoS 攻撃の可能性があるリクエストを示します。 `awswaf:managed:aws:anti-ddos:medium-suspicion-ddos-request` – DDoS 攻撃の可能性が高いリクエストを示します。 `awswaf:managed:aws:anti-ddos:high-suspicion-ddos-request` – DDoS 攻撃の可能性が非常に高いリクエストを示します。 + `awswaf:managed:aws:anti-ddos:challengeable-request` – リクエスト URI が Challenge アクションを処理できることを示します。マネージドルールグループは、URI が除外されていないすべてのリクエストにこれを適用します。URI は、ルールグループの除外 URI 正規表現と一致する場合、除外されます。サイレントブラウザチャレンジを実行できるリクエストの要件については、「[CAPTCHA および Challenge アクション動作](waf-captcha-and-challenge-actions.md)」を参照してください。 `DescribeManagedRuleGroup` を呼び出すことにより、API を介してルールグループのすべてのラベルを取得できます。ラベルは、応答の `AvailableLabels` プロパティにリストされています。 DDoS 対策マネージドルールグループは、リクエストにラベルを適用しますが、必ずしもそれらに対して対応するとは限りません。リクエスト管理は、ルールグループが攻撃への参加を決定する信頼度によって異なります。必要に応じて、ルールグループの後に実行されるラベル一致ルールを追加して、ルールグループがラベル付けするリクエストを管理できます。これと例の詳細については、「[AWS WAF 分散サービス拒否 (DDoS) の防止](waf-anti-ddos.md)」を参照してください。 ## DDoS 対策ルールのリストこのセクションでは、DDoS 対策ルールを一覧表示します。 **注記** このドキュメントでは、このマネージドルールグループの最新の静的バージョンリリースについて説明します。バージョンの変更は、[AWS マネージドルールの変更ログ](aws-managed-rule-groups-changelog.md) の変更ログにレポートされます。他のバージョンの情報については、API コマンド [DescribeManagedRuleGroup](https://docs.aws.amazon.com/waf/latest/APIReference/API_DescribeManagedRuleGroup.html) を使用してください。 AWS マネージドルールのルールグループでルール用に公開する情報は、ルールを回避するために必要なものを不正なアクターに与えることなく、ルールを使用するために必要なものを提供することを目的としています。ここに記載されている以上の情報が必要な場合は、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/) にお問い合わせください。 | ルール名 | 説明 | | --- | --- | | ChallengeAllDuringEvent | 現在攻撃を受けている保護されたリソースのラベル `awswaf:managed:aws:anti-ddos:challengeable-request` を持つリクエストに一致します。ルールアクション: Challenge このルールアクションは、Allow または Count にのみオーバーライドできます。Allow の使用はお勧めしません。ルールアクション設定では、ルールは `challengeable-request` ラベルを持つリクエストのみに一致します。このルールの設定は、次のルールの評価に影響します`ChallengeDDoSRequests`。は、マネージドルールグループのウェブ ACL の設定で、このルールのアクションにオーバーライドがに設定されている場合にのみCount、そのルール AWS WAF を評価します。ワークロードが予期しないリクエストボリュームの変更に対して脆弱である場合は、デフォルトのアクション設定を Challenge のままにして、すべてのチャレンジ可能なリクエストにチャレンジすることをお勧めします。機密性の低いアプリケーションでは、このルールに対するアクションを Count に設定し、ルール `ChallengeDDoSRequests` を使用して Challenge レスポンスの感度を調整できます。ラベル: `awswaf:managed:aws:anti-ddos:ChallengeAllDuringEvent` | | ChallengeDDoSRequests | リソースが攻撃を受けている期間中に、ルールグループで設定されたチャレンジ感度のしきい値以上を満たす、保護対象リソースへのリクエストに一致します。ルールアクション: Challenge このルールアクションは、Allow または Count にのみオーバーライドできます。Allow の使用はお勧めしません。いずれの場合も、ルールは `challengeable-request` ラベルを持つリクエストのみに一致します。 AWS WAF は、前のルール Countでアクションをに上書きする場合にのみ、このルールを評価します`ChallengeAllDuringEvent`。ラベル: `awswaf:managed:aws:anti-ddos:ChallengeDDoSRequests` | | DDoSRequests | リソースが攻撃されている間に、ルールグループの設定されたブロック感度設定を満たすか超える保護されたリソースのリクエストに一致します。ルールアクション: Block ラベル: `awswaf:managed:aws:anti-ddos:DDoSRequests` | # バージョニングされた AWS マネージドルールルールグループのデプロイこのセクションでは、が AWS マネージドルールのルールグループに更新を AWS デプロイする方法について説明します。 AWS は、リリース候補、静的バージョン、デフォルトバージョンの 3 つの標準デプロイで、バージョン管理ルール AWS ルールグループに変更をデプロイします。さらに、例外デプロイをリリースするか、デフォルトバージョンのデプロイをロールバックする必要がある AWS 場合があります。 **注記** このセクションは、バージョニングされた AWS マネージドルールのルールグループにのみ適用されます。バージョニングされていないルールグループは、IP 評価ルールグループのみです。 **Topics** + [ # AWS マネージドルールのルールグループのデプロイに関する通知 ](waf-managed-rule-groups-deployments-notifications.md) + [ # AWS マネージドルールの標準デプロイの概要 ](waf-managed-rule-groups-deployments-standard.md) + [ # AWS マネージドルールの一般的なバージョン状態 ](waf-managed-rule-groups-typical-version-states.md) + [ # AWS マネージドルールの候補デプロイをリリースする ](waf-managed-rule-groups-deployments-release-candidate.md) + [ # AWS マネージドルールの静的バージョンデプロイ ](waf-managed-rule-groups-deployments-static-version.md) + [ # AWS マネージドルールのデフォルトバージョンのデプロイ ](waf-managed-rule-groups-deployments-default-version.md) + [ # AWS マネージドルールの例外デプロイ ](waf-managed-rule-groups-deployments-exceptions.md) + [ # AWS マネージドルールのデフォルトのデプロイのロールバック ](waf-managed-rule-groups-deployments-default-rollbacks.md) # AWS マネージドルールのルールグループのデプロイに関する通知このセクションでは、Amazon SNS 通知が AWS Managed Rules ルールグループと連携する方法について説明します。バージョニングされた AWS マネージドルールのルールグループはすべてデプロイの SNS 更新通知を提供し、すべて同じ SNS トピック Amazon リソースネーム (ARN) を使用します。バージョニングされていないルールグループは、IP 評価ルールグループのみです。保護に影響するデプロイ (デフォルトバージョンへの変更など) の場合、 AWS は SNS 通知を提供して、計画されたデプロイについて通知し、デプロイが開始されるタイミングを知らせます。保護に影響しないデプロイ (リリース候補や静的バージョンのデプロイなど) の場合、 AWS は、デプロイが開始された後や完了した後でも通知を行う場合があります。新しい静的バージョンのデプロイが完了すると、はこのガイドをの変更ログで更新[AWS マネージドルールの変更ログ](aws-managed-rule-groups-changelog.md)し、のドキュメント履歴ページで AWS 更新します[ドキュメント履歴](doc-history.md)。 AWS マネージドルールルールグループに AWS が提供するすべての更新を受け取るには、このガイドの任意の HTML ページから RSS フィードにサブスクライブし、 AWS マネージドルールルールグループの SNS トピックにサブスクライブします。SNS 通知のサブスクライブの詳細については、[マネージドルールグループに対する新しいバージョンと更新の通知を受け取る](waf-using-managed-rule-groups-sns-topic.md) を参照してください。 **SNS 通知のコンテンツ** Amazon SNS 通知のフィールドには常に題名、本文、メッセージ属性が含まれます。追加のフィールドは、メッセージのタイプと通知対象のマネージドルールグループによって異なります。`AWSManagedRulesCommonRuleSet` の通知リストの例を次に示します。 ``` { "Type": "Notification", "MessageId": "4286b830-a463-5e61-bd15-e1ae72303868", "TopicArn": "arn:aws:sns:us-west-2:123456789012:MyTopic", "Subject": "New version available for rule group AWSManagedRulesCommonRuleSet", "Message": "Welcome to AWSManagedRulesCommonRuleSet version 1.5! We've updated the regex specification in this version to improve protection coverage, adding protections against insecure deserialization. For details about this change, see http://updatedPublicDocs.html. Look for more exciting updates in the future! ", "Timestamp": "2021-08-24T11:12:19.810Z", "SignatureVersion": "1", "Signature": "EXAMPLEHXgJm...", "SigningCertURL": "https://sns.us-west-2.amazonaws.com/SimpleNotificationService-f3ecfb7224c7233fe7bb5f59f96de52f.pem", "SubscribeURL": "https://sns.us-west-2.amazonaws.com/?Action=ConfirmSubscription&TopicArn=arn:aws:sns:us-west-2:123456789012:MyTopic&Token=2336412f37...", "MessageAttributes": { "major_version": { "Type": "String", "Value": "v1" }, "managed_rule_group": { "Type": "String", "Value": "AWSManagedRulesCommonRuleSet" } } } ``` # AWS マネージドルールの標準デプロイの概要 AWS は、リリース候補、静的バージョン、デフォルトバージョンの 3 つの標準デプロイステージを使用して、新しい AWS マネージドルール機能をロールアウトします。次の図は、これらの標準的なデプロイを示しています。それぞれについて、以降のセクションで詳しく説明します。 ![\[4 つの垂直スイムレーンは、異なる標準デプロイ段階を示しています。一番左のスイムレーンは、推奨された静的バージョン 1.4 にセットされたデフォルトバージョンを示しています。2 つ目のスイムレーンは、テストとチューニング用のリリース候補 (RC) バージョンにセットされたデフォルトを示しています。RC バージョンには 1.4 ルールと RC ルールが含まれています。注記は、テスト後にデフォルトが推奨された静的バージョンに戻ることを示しています。3 つ目のスイムレーンは、リリース候補バージョンのルールから静的バージョン 1.5 の作成を示しています。4 つ目のスイムレーンは、新しい推奨された静的バージョン 1.5 にセットされたデフォルトバージョンを示しています。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/amr-rg-versions-flowchart-diagram.png) # AWS マネージドルールの一般的なバージョン状態通常、バージョニングされたマネージドルールグループには有効期限が切れていない静的バージョンが多数あり、デフォルトバージョンはが AWS 推奨する静的バージョンを指します。次の図は、典型的な一連の静的バージョンとデフォルトバージョンの設定における例を示しています。 ![\[3 つの静的バージョン、Version_1.2、Version_1.3、Version_1.4 がスタックされ、Version_1.4 が一番上に表示されます。Version_1.4 には、RuleA と RuleB という 2 つのルールがあり、どちらも稼働アクションがあります。デフォルトのバージョンインジケータは Version_1.4 を指します。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/amr-rg-versions-diagram.png) 静的バージョンにおけるほとんどのルールの稼働アクションは Block ですが、別のアクションにセットされる場合があります。ルールアクション設定の詳細については、「[AWS マネージドルールのルールグループリスト](aws-managed-rule-groups-list.md)」で各ルールグループに関するルールのリストを参照してください。 # AWS マネージドルールの候補デプロイをリリースするこのセクションでは、一時リリース候補デプロイの仕組みについて説明します。 AWS にマネージドルールグループのルール変更の候補セットがある場合、一時的なリリース候補デプロイでテストします。 AWS は、本番トラフィックに対してカウントモードで候補ルールを評価し、誤検出の軽減を含む最終的な調整アクティビティを実行します。は、ルールグループのデフォルトバージョンを使用するすべての顧客に対して、この方法でリリース候補ルールを AWS テストします。リリース候補のデプロイは、ルールグループの静的バージョンを使用するお客様には適用されません。デフォルトバージョンを使用する場合、リリース候補のデプロイは、ルールグループによるウェブトラフィックの管理方法を変更しません。候補ルールがテストされている間、次のことに気づくかもしれません。 + デフォルトバージョン名が `Default (using Version_X.Y)` から `Default (using Version_X.Y_PLUS_RC_COUNT)` に変更された。 + 名前に `RC_COUNT` が含まれる Amazon CloudWatch の追加のカウントメトリクス。これらはリリース候補ルールによって生成されます。 AWS はリリース候補を約 1 週間テストし、それを削除してデフォルトバージョンを現在の推奨静的バージョンにリセットします。 AWS は、リリース候補のデプロイに対して次のステップを実行します。 1. **リリース候補を作成する** – 現在の推奨静的バージョンに基づいてリリース候補 AWS を追加します。これは、デフォルトが指しているバージョンです。リリース候補の名前は、静的バージョン名に `_PLUS_RC_COUNT` が付加されたものです。例えば、現在推奨されている静的バージョンが `Version_2.1` である場合、リリース候補の名前は `Version_2.1_PLUS_RC_COUNT` になります。リリース候補には次のルールが含まれています。 + ルール設定を変更せずに、現在推奨されている静的バージョンから正確にコピーされたルール。 + ルールアクションが Count に設定され、名前が `_RC_COUNT` で終わる候補の新しいルール。ほとんどの候補ルールは、ルールグループに既に存在するルールに対して提案された改善を提供します。これらの各ルールの名前は、既存のルールの名前に `_RC_COUNT` が付加されたものです。 1. **デフォルトバージョンをリリース候補に設定し、テスト**する – 本番トラフィックに対してテストを実行するために、新しいリリース候補を指すようにデフォルトバージョン AWS を設定します。通常、テストには約 1 週間かかります。デフォルトバージョンの名前が、静的バージョンのみを示すもの (`Default (using Version_1.4)` など) から、静的バージョンとリリース候補ルールを示すもの (`Default (using Version_1.4_PLUS_RC_COUNT)` など) に変更されます。この命名スキームにより、ウェブトラフィックの管理に使用している静的バージョンを特定できます。次の図は、この時点でのサンプルルールグループバージョンの状態を示しています。 ![\[図の上部には、スタックされた静的バージョンが 3 つ表示され、Version_1.4 が一番上にあります。静的バージョンスのタックとは別に、Version_1.4_PLUS_RC_COUNT バージョンがあります。このバージョンには、Version_1.4 のルールが含まれており、RuleB_RC_COUNT と RuleZ_RC_COUNT の 2 つのリリース候補ルールも含まれ、どちらもカウントアクションがあります。デフォルトのバージョンインジケータは Version_1.4_PLUS_RC_COUNT を指します。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/amr-rg-versions-rc-diagram.png) リリース候補ルールは常に Count アクションで設定されているため、ルールグループがウェブトラフィックを管理する方法が変更されることはありません。リリース候補ルールは、 AWS が動作の検証と誤検出の特定に使用する Amazon CloudWatch カウントメトリクスを生成します。必要に応じて調整 AWS を行い、リリース候補カウントルールの動作を調整します。リリース候補バージョンは静的バージョンではないため、静的ルールグループバージョンのリストから選択することはできません。デフォルトバージョンの仕様では、リリース候補バージョンの名前のみが表示されます。 1. **デフォルトバージョンを推奨静的バージョンに戻す – **リリース候補ルールをテストした後、 AWS はデフォルトバージョンを現在の推奨静的バージョンに戻します。デフォルトバージョン名の設定では `_PLUS_RC_COUNT` の末尾が削除され、ルールグループはリリース候補ルールの CloudWatch カウントメトリクスの生成を停止します。これはサイレント変更であり、デフォルトバージョンロールバックのデプロイとは異なります。次の図は、リリース候補のテストが完了した後のサンプルルールグループのバージョンの状態を示しています。 ![\[これは典型的なバージョンの状態図です。Version_1.2、Version_1.3、および Version_1.4 の 3 つの静的バージョンがスタックされ、Version_1.4 が一番上に表示されます。Version_1.4 には、RuleA と RuleB という 2 つのルールがあり、どちらも稼働アクションがあります。デフォルトのバージョンインジケータは Version_1.4 を指します。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/amr-rg-versions-rc-complete-diagram.png) **タイミングと通知** AWS は、ルールグループの改善をテストするために、必要に応じてリリース候補バージョンをデプロイします。 + **SNS** – デプロイの開始時に SNS 通知 AWS を送信します。通知には、リリース候補がテストされる推定時間が表示されます。テストが完了すると、は 2 回目の通知なしで、デフォルトを静的バージョン設定に AWS サイレントに返します。 + **変更ログ** – このタイプのデプロイでは、変更ログやこのガイドの他の部分を更新 AWS しません。 # AWS マネージドルールの静的バージョンデプロイがリリース候補がルールグループに重要な変更を提供する AWS と判断した場合、はリリース候補に基づいてルールグループの新しい静的バージョンを AWS デプロイします。このデプロイでは、ルールグループのデフォルトバージョンは変更されません。新しい静的バージョンには、リリース候補からの次のルールが含まれています。 + リリース候補ルールの中に置換候補がない、以前の静的バージョンのルール。 + 次の変更を加えて、候補ルールをリリースします。 + AWS は、リリース候補のサフィックスを削除してルール名を変更します`_RC_COUNT`。 + AWS は、ルールアクションをから本番稼働用ルールアクションCountに変更します。以前の既存のルールを置き換えるリリース候補ルールの場合、これは新しい静的バージョンの以前のルールの機能を置き換えます。次の図は、リリース候補から新しい静的バージョンを作成する方法を示しています。 ![\[図の上部には、以前のリリース候補のデプロイ図と同じルールを持つリリース候補バージョン、Version_1.4_PLUS_RC_COUNT があります。このバージョンには、Version_1.4 のルールが含まれており、RuleB_RC_COUNT と RuleZ_RC_COUNT というリリース候補ルールも含まれ、どちらもカウントアクションを持っています。この下には、図の下部に静的バージョン Version_1.5 があります。このバージョンには、ルール RuleA、RuleB、RuleZ が含まれており、すべて稼働アクションを持っています。矢印は RC バージョンから Version_1.5 を指しており、RuleA が Version_1.4 ルールからコピーされ、RuleB と RuleZ がリリース候補ルールからコピーされたことを示します。Version_1.5 のすべてのルールには稼働アクションがあります。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/amr-rg-versions-create-static-diagram.png) デプロイ後、新しい静的バージョンをテストして、必要に応じて保護に使用できます。[AWS マネージドルールのルールグループリスト](aws-managed-rule-groups-list.md) のルールグループのルールリストで、新規および更新されたルールアクションと説明を確認できます。静的バージョンはデプロイ後に変更できず、 AWS が期限切れになったときにのみ変更されます。バージョンのライフサイクルについては、「[でのバージョニングされたマネージドルールグループの使用 AWS WAF](waf-managed-rule-groups-versioning.md)」を参照してください。 **タイミングと通知** AWS は、ルールグループ機能の改善をデプロイするために、必要に応じて新しい静的バージョンをデプロイします。静的バージョンのデプロイは、デフォルトのバージョン設定には影響しません。 + **SNS** – デプロイが完了すると SNS 通知 AWS を送信します。 + **変更ログ** – 利用可能なすべての場所でデプロイが完了すると、 AWS WAF は必要に応じてこのガイドのルールグループ定義 AWS を更新し、 AWS マネージドルールのルールグループ変更ログとドキュメント履歴ページでリリースを発表します。 # AWS マネージドルールのデフォルトバージョンのデプロイ新しい静的バージョンが現在のデフォルトと比較してルールグループの保護を改善するとが AWS 判断した場合、はデフォルトバージョンを新しい静的バージョン AWS に更新します。ルールグループのデフォルトバージョンに昇格する前に、複数の静的バージョンをリリース AWS する可能性があります。次の図は、がデフォルトバージョン設定を新しい静的バージョン AWS に移行した後のルールグループバージョンの例の状態を示しています。 ![\[これは典型的なバージョン状態図と似ていますが、Version_1.5 がスタックの一番上にあり、デフォルトのインジケータがそれを指しています。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/amr-rg-versions-new-default-diagram.png) この変更をデフォルトバージョンにデプロイする前に、は今後の変更をテストして準備できるように通知 AWS を提供します。デフォルトバージョンを使用する場合は、何も実行せずに、更新後もそのバージョンに留まることができます。デフォルトバージョンのデプロイの計画された開始の前に、代わりに新しいバージョンへの切り替えを遅らせたい場合、デフォルトが設定されている静的バージョンを使用するように、ルールグループを明示的に設定できます。 **タイミングと通知** AWS は、現在使用されているものとは異なる静的バージョンをルールグループに推奨する場合、デフォルトバージョンを更新します。 + **SNS** – ターゲットデプロイ日の少なくとも 1 週間前に SNS 通知を送信し、デプロイ日のデプロイ開始時に別の SNS 通知 AWS を送信します。各通知には、ルールグループ名、デフォルトバージョンの更新先の静的バージョン、デプロイ日、更新が実行されている各 AWS リージョンのデプロイのスケジュールされたタイミングが含まれます。 + **変更ログ** – このタイプのデプロイでは、変更ログやこのガイドの他の部分を更新 AWS しません。 # AWS マネージドルールの例外デプロイ AWS は、重要なセキュリティリスクに対処する更新を迅速にデプロイするために、標準のデプロイステージをバイパスすることがあります。例外デプロイには、標準デプロイタイプのいずれかが含まれる場合があり、 AWS リージョン間で迅速にデプロイされる可能性があります。 AWS は、例外デプロイについて可能な限り多くの事前通知を提供します。 **タイミングと通知** AWS は、必要な場合にのみ例外デプロイを実行します。 + **SNS** – ターゲットデプロイ日のできるだけ前に SNS 通知 AWS を送信し、デプロイの開始時に別の通知を送信します。各通知には、ルールグループ名、行われる変更、およびデプロイ日が含まれます。 + **変更ログ** – デプロイが静的バージョンの場合、利用可能なすべての場所でデプロイが完了した後、 AWS WAF は必要に応じてこのガイドのルールグループ定義 AWS を更新し、 AWS マネージドルールのルールグループ変更ログとドキュメント履歴ページでリリースを発表します。 # AWS マネージドルールのデフォルトのデプロイのロールバック特定の条件下で AWS は、デフォルトバージョンを以前の設定にロールバックすることがあります。ロールバックには通常、すべての AWS リージョンで 10 分未満かかります。 AWS は、許容できないほど高いレベルの誤検出など、静的バージョンの重大な問題を軽減するためにのみロールバックを実行します。デフォルトバージョン設定のロールバック後、は、問題のある静的バージョンの有効期限と、問題に対処するための新しい静的バージョンのリリースの両方を AWS 迅速化します。 **タイミングと通知** AWS は、必要な場合にのみデフォルトバージョンのロールバックを実行します。 + **SNS** – ロールバック時に単一の SNS 通知 AWS を送信します。通知には、ルールグループ名、デフォルトバージョンが設定されるバージョン、およびデプロイ日が含まれます。このデプロイタイプは非常に高速なので、通知はリージョンのタイミング情報を提供しません。 + **変更ログ** – このタイプのデプロイでは、変更ログやこのガイドの他の部分を更新 AWS しません。 # AWS マネージドルールの変更ログこのセクションでは、2019 年 11 月のリリース AWS WAF 以降のの AWS マネージドルールの変更を一覧表示します。 **注記** この変更ログは、 AWS マネージドルールのルールとルールグループの変更を報告します AWS WAF。 [IP 評価ルールグループ](aws-managed-rule-groups-ip-rep.md) において、この変更ログはルールとルールグループの変更を報告し、ルールが使用する IP アドレスリストのソースに大きな変更を報告します。このルールで使用されている IP アドレスリストは動的であるため、これらのリストの変更は報告されません。IP アドレスリストについて質問がある場合は、アカウントマネージャーに連絡するか、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/)でケースを開きます。 | ルールグループおよびルール | 説明 | 日付 | | --- | --- | --- | | [PHP アプリケーションマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-php-app) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 2.2 をリリースしました。検出が改善され、`PHPHighRiskMethodsVariables_URIPATH`ルールが追加されました。 | 2026-03-24 | | [AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md) 新しいルール: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 5.0 をリリースしました。ページプレビューとウェブフックの 2 つの新しいボットカテゴリとそれぞれのルールを含む、複数のカテゴリにまたがる 400 以上の新しいボットを追加しました。 **主な改善点** ボット検出シグナルと一般的なボットパターンマッチングの精度が向上し、トラフィック分類の精度が向上しました。この更新により、マネージドルールグループがボット検出を優先する方法が変更されます。特定の未検証のボットパターンが、一般的なパターンと検出シグナルの前に評価されるようになりました。つまり、リクエストは一般的な指標ではなく、最も具体的な特性に基づいて分類される可能性が高くなります。 **これはトラフィックにとって何を意味しますか。** 一般的なボットパターンの一致頻度が低くなりました。これらのパターンは、より具体的なボットルールがまだトラフィックを特定していない場合にのみ適用されます。これにより、過剰分類が軽減され、利用可能な最も正確なボット識別でリクエストにラベルが付けられます。リクエストがクラウドサービスプロバイダー、既知のボットデータセンターから発信された、またはブラウザ以外のユーザーエージェントを使用していることを示すインジケータなどの検出シグナルが、ボット識別ルールの後に適用されるようになりました。これにより、特定のボット分類が一般的なトラフィックシグナルよりも優先されます。 **影響:** リクエストが特定のボットルールによってより正確に分類されるようになったため、トラフィックログには汎用ボットパターンのラベルが少なくなる場合があります。これにより、自動トラフィックの実際の性質をより明確に把握でき、過度に広範なパターンマッチングによるノイズが軽減されます。未検証のボット分類は、より目立つ正確なものになり、アプリケーションへの自動リクエストをよりよく理解して管理するのに役立ちます。 **注:** このバージョンには Version\$14.0 からの`awswaf:managed:aws:bot-control:bot:web_bot_auth`ラベルとルールの更新が含まれていますが、`Web Bot Auth`この機能は引き続き CloudFront でのみ使用できます。 | 2026-02-25 | | [POSIX オペレーティングシステムマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-posix-os) | このルールグループの静的バージョン 3.2 をリリースしました。すべてのルールの検出署名が改善されました。 | 2026-01-15 | | [既知の不正な入力マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-known-bad-inputs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.25 をリリースしました。検出を改善する`ReactJSRCE_BODY`ためにを更新しました。 | 2025-12-08 | | [POSIX オペレーティングシステムマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-posix-os) | このルールグループの静的バージョン 3.1 をリリースしました。すべてのルールの検出署名が改善されました。 | 2025-12-08 | | [既知の不正な入力マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-known-bad-inputs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.24 をリリースしました。検出を改善する`ReactJSRCE_BODY`ためにを更新しました。 | 2025-12-04 | | [AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md) 新しいラベル:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) スコープ: CloudFront | Web Bot Authentication (WBA) による暗号化ボット検証をサポートする新しい静的バージョン `AWSManagedRulesBotControlRuleSet` Version\$14.0 をデプロイしました。このバージョンは明示的に選択する必要があり、デフォルトバージョンを使用して既存のデプロイを自動的に更新することはありません。新機能: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) ルールの更新: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) Version\$14.0 は静的バージョンのみであり、デフォルトのバージョン動作は変更されません。WBA 機能を使用するには、ウェブ ACL を設定するときにバージョン \$14.0 を明示的に選択します。 | 2025-11-20 | | [AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md) 新しい検証済みボットラベル:広告:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html)AI:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html)コンテンツフェッチャー:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html)ソーシャルメディア:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | 主な改善点: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) Bot Control のボットカテゴリルールは、検証されていないボットでのみトリガーされます。ただし、検証済みのボットでもトリガーされる CategoryAI は除きます。Version\$13.3 は静的バージョンのみであり、デフォルトのバージョン動作は変更されません。 | 2025-11-17 | | [コアルールセット (CRS) マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-crs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.20 をリリースしました。 Server Side Request Forgery (SSRF) ルールの検出署名が改善されました。 | 2025-10-02 | | [コアルールセット (CRS) マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-crs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.19 をリリースしました。クロスサイトスクリプティングルールの検出シグネチャが改善されました。 | 2025-08-14 | | [コアルールセット (CRS) マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-crs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.18 をリリースしました。クロスサイトスクリプティングルールの検出シグネチャが改善されました。 | 2025-06-18 | | [AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md) 新しいラベル: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 3.2 をリリースしました。リストされている新しいラベルを追加しました。 | 2025-05-29 | | [コアルールセット (CRS) マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-crs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.17 をリリースしました。クロスサイトスクリプティングルールの検出シグネチャが改善されました。 | 2025-03-03 | | [SQL データベースマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-sql-db) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.3 をリリースしました。リストされたルールにダブル `URL_DECODE_UNI` テキスト変換を追加しました。 | 2025-01-24 | | [Linux オペレーティングシステムマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-linux-os) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 2.6 をリリースしました。検出の向上を図るために署名を追加しました。 | 2025-01-24 | | [AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md) Bot Control ラベルの新しいボット名ラベル: `awswaf:managed:aws:bot-control:bot::name:nytimes` | このルールグループの静的バージョン 3.1 をリリースしました。ボット名ラベルのリストに New York Times ラベルを追加しました。 | 2024-11-07 | | [コアルールセット (CRS) マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-crs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.16 をリリースしました。クロスサイトスクリプティングルールの検出シグネチャが改善されました。 | 2024-10-16 | | [AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md) 新しいルール: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) 削除されたルール: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) 新しいラベル: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) 既存のルールの追加ラベル付け。 | このルールグループの静的バージョン 2.0 および 3.0 をリリースしました。バージョン 2.0 はバージョン 3.0 と同じですが、すべての新しいルールのルールアクションは Count に設定されています。このガイドは、各ルールグループの最新バージョンについて記録します。リストされている新しいルールを追加しました。すべてのルールがパターン `awswaf:managed:aws:bot-control:` を持つラベルを適用するようにラベルを更新しました。 Bot Control シグナルラベルにクラウドサービスプロバイダーラベルを追加しました。ボットカテゴリルールによって検査される新しいボット名ラベルを追加しました。 | 2024-09-13 | | [AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループ](aws-managed-rule-groups-atp.md) すべてのルール | このルールグループの静的バージョン 1.1 をリリースしました。すべてのルールがパターン `awswaf:managed:aws:atp:` を持つラベルを適用するようにラベルを更新しました。 | 2024-09-13 | | [AWS WAF Fraud Control アカウント作成不正防止 (ACFP) ルールグループ](aws-managed-rule-groups-acfp.md) すべてのルール | このルールグループの静的バージョン 1.1 をリリースしました。すべてのルールがパターン `awswaf:managed:aws:acfp:` を持つラベルを適用するようにラベルを更新しました。 | 2024-09-13 | | [Linux オペレーティングシステムマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-linux-os) すべてのルール | このルールグループの静的バージョン 2.5 をリリースしました。検出の向上を図るために署名を追加しました。 | 2024-09-02 | | [コアルールセット (CRS) マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-crs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.15 をリリースしました。汎用 LFI ルールの検出署名が改善されました。 | 2024-08-30 | | [Windows オペレーティングシステムマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-windows-os) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 2.3 をリリースしました。リストされたルールでは、誤検出を減らすために検出シグネチャをチューニングしました。 | 2024-08-28 | | [WordPress アプリケーションマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-wordpress-app) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.3 をリリースしました。リストされたルールに JS\$1DECODE テキスト変換を追加しました。 | 2024-07-15 | | [Linux オペレーティングシステムマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-linux-os) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 2.4 をリリースしました。リストされたルールに JS\$1DECODE テキスト変換を追加しました。 | 2024-07-12 | | [コアルールセット (CRS) マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-crs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.14 をリリースしました。リストされているルールに JS\$1DECODE テキスト変換を追加しました。 | 2024-07-09 | | [PHP アプリケーションマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-php-app) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 2.1 をリリースしました。リストされているルールに JS\$1DECODE テキスト変換を追加しました。 | 2024-07-03 | | [Windows オペレーティングシステムマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-windows-os) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 2.2 をリリースしました。リストされているルールに JS\$1DECODE テキスト変換を追加しました。 | 2024-07-03 | | [Linux オペレーティングシステムマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-linux-os) すべてのルール | このルールグループの静的バージョン 2.3 をリリースしました。検出の向上を図るために署名を追加しました。 | 2024-06-06 | | [AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md) [AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループ](aws-managed-rule-groups-atp.md) [AWS WAF Fraud Control アカウント作成不正防止 (ACFP) ルールグループ](aws-managed-rule-groups-acfp.md) | ボットおよび不正ルールグループがバージョン管理されるようになりました。これらのルールグループを使用している場合、この更新によってウェブトラフィックの処理方法が変更されることはありません。この更新では、現在のルールグループバージョンを静的バージョン 1.0 に設定し、それを指すデフォルトバージョンを設定します。バージョンで管理されたルールの詳細については、以下の内容を参照してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | 2024-05-29 | | [POSIX オペレーティングシステムマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-posix-os) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 3.0 をリリースしました。 `UNIXShellCommandsVariables_QUERYARGUMENTS` を削除し、`UNIXShellCommandsVariables_QUERYSTRING` で置き換えました。`UNIXShellCommandsVariables_QUERYARGUMENTS` のラベルに一致するルールがある場合、このバージョンを使用する場合は、`UNIXShellCommandsVariables_QUERYSTRING` のラベルと一致するように切り替えます。新しいラベルは `awswaf:managed:aws:posix-os:UNIXShellCommandsVariables_QueryString` です。すべてのヘッダーに一致するルール `UNIXShellCommandsVariables_HEADER` を追加しました。改善された検出ロジックで管理ルールグループのすべてのルールを更新しました。 `UNIXShellCommandsVariables_BODY` のラベルの大文字が文書化されている箇所を修正しました。 | 2024-05-28 | | [コアルールセット (CRS) マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-crs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.12 をリリースしました。検出の向上と誤検出の低減のため、クロスサイトのスクリプティングルール全体にシグネチャーを追加しました。 | 2024-05-21 | | [SQL データベースマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-sql-db) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.2 をリリースしました。リストされたルールに `JS_DECODE` テキスト変換を追加しました。 | 2024-05-14 | | [既知の不正な入力マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-known-bad-inputs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.22 をリリースしました。リストされたルールに `JS_DECODE` テキスト変換を追加しました。 | 2024-05-08 | | [POSIX オペレーティングシステムマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-posix-os) | このルールグループの静的バージョン 2.2 をリリースしました。 2 つのルールに `JS_DECODE` テキスト変換を追加しました。 | 2024-05-08 | | [Windows オペレーティングシステムマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-windows-os) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 2.1 をリリースしました。検出結果の改善を図るために署名を `PowerShellCommands_BODY` に追加しました。 | 2024-05-03 | | [Amazon IP 評価リストマネージドルールグループ](aws-managed-rule-groups-ip-rep.md#aws-managed-rule-groups-ip-rep-amazon) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | IP 評価リストのソースを更新し、悪意のあるアクティビティに積極的に関与しているアドレスの特定を改善し、誤検出を減らしました。このルールグループはバージョン化されていないため、この更新には新しいバージョンは含まれません。 | 2024-03-13 | | [既知の不正な入力マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-known-bad-inputs) | このルールグループの静的バージョン 1.21 をリリースしました。検出を改善し、誤検出を減らすためにシグネチャを追加しました。 | 2023-12-16 | | [既知の不正な入力マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-known-bad-inputs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.20 をリリースしました。 Atlassian Confluence CVE-2023-22518 の不適切な認可の脆弱性に一致するリクエストの検出を追加するように `ExploitablePaths_URIPATH` ルールを更新しました。この脆弱性は Confluence Data Center および Server のすべてのバージョンに影響します。詳細については、「[NIST: National Vulnerability Database: CVE-2023-22518 Detail](https://nvd.nist.gov/vuln/detail/CVE-2023-22518)」を参照してください。 | 2023-12-14 | | [コアルールセット (CRS) マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-crs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.11 をリリースしました。検出の向上と誤検出の低減のため、クロスサイトのスクリプティングルール全体にシグネチャーを追加しました。 | 2023-12-06 | | [AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | ルールグループの対象保護レベルラベルに調整されたアクティビティの下限ラベルを追加しました。このラベルはいずれのルールにも関連付けられていません。このラベルは、中レベルおよび高レベルのルールとラベルに追加されるものです。 | 2023-12-05 | | [Bot Control ラベル](aws-managed-rule-groups-bot.md#aws-managed-rule-groups-bot-labels-rg) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | 自動化を支援するブラウザ拡張機能が検出されたことを示すシグナルラベルをルールグループに追加しました。このラベルは個々のルールに固有のものではありません。 | 2023-11-14 | | [コアルールセット (CRS) マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-crs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.10 をリリースしました。 1 つのルールを更新し、検出の向上と誤検出の低減を実現しました。 | 2023-11-02 | | [コアルールセット (CRS) マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-crs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.9 をリリースしました。ルールが更新され、検出の向上と誤検出の低減を実現しました。 | 2023-10-30 | | [POSIX オペレーティングシステムマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-posix-os) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 2.1 をリリースしました。クエリ引数ルールを更新して、検出を改善しました。 | 2023-10-12 | | [コアルールセット (CRS) マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-crs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.8 をリリースしました。ルールを更新して検出を改善しました。 | 2023-10-11 | | [既知の不正な入力マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-known-bad-inputs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | 例外のデプロイ: このルールグループの静的バージョン 1.19 をリリースしました。バージョン 1.19 を使用するようにデフォルトバージョンを更新しました。 Atlassian Confluence CVE-2023-22515 の権限昇格の脆弱性に一致するリクエストの検出を追加するように `ExploitablePaths_URIPATH` ルールを更新しました。この脆弱性は、Atlassian Confluence の一部のバージョンに影響を及ぼします。詳細については、「[NIST: National Vulnerability Database: CVE-2023-22515 Detail](https://nvd.nist.gov/vuln/detail/CVE-2023-22515)」および「[Atlassian Support: FAQ for CVE-2023-22515](https://confluence.atlassian.com/kb/faq-for-cve-2023-22515-1295682188.html)」を参照してください。デプロイタイプの詳細については、「[AWS マネージドルールの例外デプロイ](waf-managed-rule-groups-deployments-exceptions.md)」を参照してください。 | 2023-10-04 | | [既知の不正な入力マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-known-bad-inputs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | 例外のデプロイ: このルールグループの静的バージョン 1.18 をリリースしました。これは、この静的バージョンの迅速なロールアウトであり、バージョン 1.19 の作成とロールアウトに対応するためのものです。検出を改善するため、`Host_localhost_HEADER` ルールとすべての Log4J および Java 逆シリアル化ルールを更新しました。デプロイタイプの詳細については、「[AWS マネージドルールの例外デプロイ](waf-managed-rule-groups-deployments-exceptions.md)」を参照してください。 | 2023-10-04 | | [AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | Count アクションでルールグループにルールを追加しました。トークン再利用 IP ルールは、IP アドレス間でのトークンの共有を検出してカウントします。調整されたアクティビティルールは、ウェブサイトのトラフィックを機械学習 (ML) で自動的に分析し、ボット関連のアクティビティを検出します。ルールグループ設定で、ML の使用をオプトアウトできます。このリリースでは、ターゲットを絞った保護レベルを現在使用しているユーザーが ML の使用にオプトインされます。オプトアウトすると、調整されたアクティビティルールが無効になります。 | 2023-09-06 | | [AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | ルール `CategoryAI` をルールグループに追加しました。 | 2023-08-30 | | [コアルールセット (CRS) マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-crs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.7 をリリースしました。制限付き拡張ルールおよび EC2 メタデータ SSRF ルールを更新し、検出の向上と誤検出の低減を実現しました。 | 2023-07-26 | | [AWS WAF Fraud Control アカウント作成不正防止 (ACFP) ルールグループ](aws-managed-rule-groups-acfp.md) 新しいルールグループ内のすべてのルール | ルールグループ AWSManagedRulesACFPRuleSet を追加しました。 | 2023-06-13 | | [Linux オペレーティングシステムマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-linux-os) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 2.2 をリリースしました。検出の向上を図るために署名を追加しました。 | 2023-05-22 | | [コアルールセット (CRS) マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-crs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.6 をリリースしました。クロスサイトスクリプティング (XSS) および制限付き拡張ルールを更新し、検出の向上と誤検出の低減を実現しました。 | 2023-04-28 | | [PHP アプリケーションマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-php-app) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 2.0 をリリースしました。すべてのルールで検出を改善するために署名を追加しました。ルール `PHPHighRiskMethodsVariables_QUERYARGUMENTS` を、クエリ引数だけでなくクエリ文字列全体を検査する `PHPHighRiskMethodsVariables_QUERYSTRING` に置き換えました。ルール `PHPHighRiskMethodsVariables_HEADER` を追加し、すべてのヘッダーを含むようにカバレッジを拡張しました。標準の AWS マネージドルールのラベル付けに合わせて、次のラベルを更新しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | 2023-02-27 | | [AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループ](aws-managed-rule-groups-atp.md)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | 保護されている Amazon CloudFront ディストリビューションで使用するためのログインレスポンス検査ルールを追加しました。これらのルールは、最近のログイン試行の失敗回数が過度に多い IP アドレスやクライアントセッションからの新たなログイン試行をブロックします。 | 2023-02-15 | | [コアルールセット (CRS) マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-crs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.5 をリリースしました。検出を改善するため、クロスサイトスクリプティング (XSS) フィルターを更新しました。 | 2023-01-25 | | [Linux オペレーティングシステムマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-linux-os) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 2.1 をリリースしました。ルール `LFI_COOKIE` およびそのラベル `awswaf:managed:aws:linux-os:LFI_Cookie` を削除し、新しいルール `LFI_HEADER` およびそのラベル `awswaf:managed:aws:linux-os:LFI_Header` に置き換えました。この変更により、検査が複数のヘッダーに拡張されます。検出を改善するため、すべてのルールにテキスト変換および署名を追加しました。 | 2022-12-15 | | [コアルールセット (CRS) マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-crs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.4 をリリースしました。すべての NULL バイトを削除するため、テキスト変換を `NoUserAgent_HEADER` に追加しました。検出を改善するため、クロスサイトのスクリプティングルールのフィルターを更新しました。 | 2022-12-05 | | [既知の不正な入力マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-known-bad-inputs) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.17 をリリースしました。 Java 逆シリアル化ルールを更新し、1.10.0 以前の Apache Commons Text バージョンのリモートコード実行 (RCE) 脆弱性である Apache CVE-2022-42889 に一致するリクエストの検出を追加しました。詳細については、「[NIST: National Vulnerability Database: CVE-2022-42889 Detail](https://nvd.nist.gov/vuln/detail/CVE-2022-42889)」(NIST: 国家脆弱性データベース: CVE-2022-42889 詳細) および「[CVE-2022-42889: Apache Commons Text prior to 1.10.0 allows RCE when applied to untrusted input due to insecure interpolation defaults](https://lists.apache.org/thread/n2bd4vdsgkqh2tm14l1wyc3jyol7s1om)」(CVE-2022-42889: 信頼されない入力に適用された場合にセキュアでない補間デフォルトが原因で 1.10.0 以前の Apache Commons Text で RCE が許可される) を参照してください。 `Host_localhost_HEADER` での検出を改善しました。 | 2022-10-20 | | [既知の不正な入力マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-known-bad-inputs)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.16 をリリースしました。バージョン 1.15 で AWS 識別された誤検出を削除しました。 | 2022-10-05 | | [POSIX オペレーティングシステムマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-posix-os) [PHP アプリケーションマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-php-app) [WordPress アプリケーションマネージドルールグループ](aws-managed-rule-groups-use-case.md#aws-managed-rule-groups-use-case-wordpress-app) | 記載されているラベル名を修正しました。 | 2022-09-19 | | [IP 評価ルールグループ](aws-managed-rule-groups-ip-rep.md) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | この変更により、ルールグループがウェブトラフィックを処理する方法が変更されることはありません。 Amazon 脅威インテリジェンスに従い、DDoS アクティビティに積極的に関与している IP アドレスを検査する Count アクションを含む新しいルールが追加されました。 | 2022-08-30 | | [既知の不正な入力マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-known-bad-inputs)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループの静的バージョン 1.15 をリリースしました。誤検出のよりきめ細かにモニタリングと管理を行うため、`Log4JRCE` を削除して `Log4JRCE_HEADER`、`Log4JRCE_QUERYSTRING`、`Log4JRCE_URI`、`Log4JRCE_BODY` に置き換えました。 `PROPFIND_METHOD` とすべての `JavaDeserializationRCE*` と `Log4JRCE*` ルールに対する検出とブロックを改善するため、署名を追加しました。 `Host_localhost_HEADER` と全ての `JavaDeserializationRCE*` ルールにおける大文字化の修正をするためにラベルを更新しました。 `JavaDeserializationRCE_HEADER` の記述を修正しました。 | 2022-08-22 | | [AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループ](aws-managed-rule-groups-atp.md)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | Amazon Cognito ユーザープールのウェブトラフィック用のアカウント乗っ取り防止マネージドルールグループの使用を防止するルールを追加しました。 | 2022-08-11 | | [コアルールセット (CRS) マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-crs) | AWS には、ルールグループのバージョン `Version_1.2` と `Version_2.0` の有効期限がスケジュールされています。このバージョンの有効期限は 2022 年 9 月 9 日に失効します。バージョンの有効期限の詳細については、「[でのバージョニングされたマネージドルールグループの使用 AWS WAF](waf-managed-rule-groups-versioning.md)」を参照してください。 | 2022-06-09 | | [コアルールセット (CRS) マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-crs)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループのバージョン 1.3 をリリースしました。このリリースでは、検出を改善するため、`GenericLFI_URIPATH` および `GenericRFI_URIPATH` のルールにある一致する署名が更新されます。 | 2022-05-24 | | [AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | ルール `CategoryEmailClient` をルールグループに追加しました。 | 2022-04-06 | | [既知の不正な入力マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-known-bad-inputs)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループのバージョン 1.14 をリリースしました。4 つの `JavaDeserializtionRCE` ルールが Block モードに移行します。 | 2022-03-31 | | [既知の不正な入力マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-known-bad-inputs)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループのバージョン 1.13 をリリースしました。Spring Core および Cloud Function RCE 脆弱性のテキスト変換を更新しました。これらのルールは、メトリクスを収集して一致したパターンを評価するため、カウントモードになっています。ラベルは、カスタムルール内のリクエストをブロックするために使用できます。後続のバージョンは、これらのルールがブロックモードになった状態でデプロイされます。 | 2022-03-31 | | [既知の不正な入力マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-known-bad-inputs)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループのバージョン 1.12 をリリースしました。Spring Core および Cloud Function RCE の脆弱性の署名を追加しました。これらのルールは、メトリクスを収集して一致したパターンを評価するため、カウントモードになっています。ラベルは、カスタムルール内のリクエストをブロックするために使用できます。後続のバージョンは、これらのルールがブロックモードになった状態でデプロイされます。ルール `Log4JRCE_HEADER`、`Log4JRCE_QUERYSTRING`、`Log4JRCE_URI`、`Log4JRCE_BODY` を削除してルール `Log4JRCE` に置き換えました。 | 2022-03-30 | | [IP 評価ルールグループ](aws-managed-rule-groups-ip-rep.md) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | アクションをカウントからブロックに変更するように AWSManagedReconnaissanceList ルールを更新しました。 | 2022-02-15 | | [AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループ](aws-managed-rule-groups-atp.md) 新しいルールグループ内のすべてのルール | ルールグループ AWSManagedRulesATPRuleSet を追加しました。 | 2022-02-11 | | [既知の不正な入力マネージドルールグループ](aws-managed-rule-groups-baseline.md#aws-managed-rule-groups-baseline-known-bad-inputs)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループのバージョン 1.9 をリリースしました。この機能を柔軟に使用できるように、ルール `Log4JRCE` を削除し、ルール `Log4JRCE_HEADER`、`Log4JRCE_QUERYSTRING`、`Log4JRCE_URI`、および `Log4JRCE_BODY` に置き換えました。検出とブロックを改善するために署名を追加しました。 | 2022-01-28 | | コアルールセット (CRS) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループのバージョン 2.0 をリリースしました。これらのルールでは、誤検出を減らすために検出シグネチャをチューニングしました。`URL_DECODE` テキスト変換をダブル `URL_DECODE_UNI` テキスト変換に置き換えました。`HTML_ENTITY_DECODE` テキスト変換を追加しました。 | 2022-01-10 | | コアルールセット (CRS) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループのバージョン 2.0 のリリースの一部として、`URL_DECODE_UNI`テキスト変換が追加されました。`RestrictedExtensions_URIPATH` から `URL_DECODE` テキスト変換を削除しました。 | 2022-01-10 | | SQL データベース [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | このルールグループのバージョン 2.0 をリリースしました。`URL_DECODE` テキスト変換をダブル `URL_DECODE_UNI` テキスト変換に置き換え、`COMPRESS_WHITE_SPACE` テキスト変換を追加しました。検出シグネチャを `SQLiExtendedPatterns_QUERYARGUMENTS` に追加しました。 `SQLi_BODY` に JSON 検査を追加しました。ルール `SQLiExtendedPatterns_BODY` を追加しました。ルール `SQLi_URIPATH` を削除しました。 | 2022-01-10 | | 既知の不正な入力 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | ヘッダーの検査と一致基準を改善するために、ルール `Log4JRCE` のバージョン 1.8 をリリースしました。 | 2021-12-17 | | 既知の不正な入力 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | 一致基準をチューニングし、追加のヘッダーを検査するために、ルール `Log4JRCE` のバージョン 1.4 をリリースしました。バージョン 1.5 をリリースし、一致条件をチューニングしました。 | 2021-12-11 | | 既知の不正な入力 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-changelog.html) | Log4j 内で最近公開されたセキュリティ問題に対応して、ルール `Log4JRCE` バージョン 1.2 を追加しました。詳細については、「[CVE-2021-44228](https://www.cve.org/CVERecord?id=CVE-2021-44228)」を参照してください。このルールは、共通の URI パス、クエリ文字列、リクエストボディの最初の 8 KB、および共通ヘッダーを検査します。ルールはダブル `URL_DECODE_UNI` テキスト変換を使用します。一致基準をチューニングし、追加のヘッダーを検査するために、`Log4JRCE` のバージョン 1.3 をリリースしました。ルール `BadAuthToken_COOKIE_AUTHORIZATION` を削除しました。 | 2021-12-10 | 次の表には、2021 年 12 月よりも前の変更が記載されています。 | ルールグループおよびルール | 説明 | Date | | --- | --- | --- | | Amazon IP 評価リスト | `AWSManagedReconnaissanceList` | モニタリング/カウントモードの AWSManagedReconnaissanceList ルールを追加しました。このルールには、 AWS リソースに対して偵察を実行している IP アドレスが含まれています。 | 2021-11-23 | | Windows オペレーティングシステム | `WindowsShellCommands` `PowerShellCommands` | WindowsShell コマンド用に 3 つの新しいルールを追加しました: `WindowsShellCommands_COOKIE`、`WindowsShellCommands_QUERYARGUMENTS`、および `WindowsShellCommands_BODY`。新しい PowerShell ルールを追加しました: `PowerShellCommands_COOKIE`。文字列 \$1Set1 と \$1Set2 を削除して、`PowerShellComands` ルールの命名を再構築しました。より包括的な検出シグネチャを `PowerShellRules` に追加しました。すべての Windows オペレーティングシステムのルールに `URL_DECODE_UNI` テキスト変換を追加しました。 | 2021-11-23 | | Linux オペレーティングシステム | `LFI_URIPATH` `LFI_QUERYSTRING` `LFI_BODY` `LFI_COOKIE` | ダブル `URL_DECODE` テキスト変換をダブル `URL_DECODE_UNI` に置き換えました。 2 つ目のテキスト変換として `NORMALIZE_PATH_WIN` を追加しました。 `LFI_BODY` ルールを `LFI_COOKIE` ルールに置き換えました。すべての `LFI` ルールに、より包括的な検出シグネチャを追加しました。 | 2021-11-23 | | コアルールセット (CRS) | `SizeRestrictions_BODY` | 8 KB を超える本文ペイロードを持つウェブリクエストをブロックするためのサイズ制限を縮小しました。これまでは、制限は 10 KB でした。 | 2021-10-27 | | コアルールセット (CRS) | `EC2MetaDataSSRF_BODY` `EC2MetaDataSSRF_COOKIE` `EC2MetaDataSSRF_URIPATH` `EC2MetaDataSSRF_QUERYARGUMENTS` | 検出シグネチャを追加しました。ブロックを改善するためにダブルユニコード URL デコードを追加しました。 | 2021-10-27 | | コアルールセット (CRS) | `GenericLFI_QUERYARGUMENTS` `GenericLFI_URIPATH` `RestrictedExtensions_URIPATH` `RestrictedExtensions_QUERYARGUMENTS` | ブロックを改善するためにダブルユニコード URL デコードを追加しました。 | 2021-10-27 | | コアルールセット (CRS) | `GenericRFI_QUERYARGUMENTS` `GenericRFI_BODY` `GenericRFI_URIPATH` | お客様からのフィードバックに基づいて、誤検出を減らすためにルールシグネチャを更新しました。ブロックを改善するためにダブルユニコード URL デコードを追加しました。 | 2021-10-27 | | すべて | すべてのルール | AWS WAF ラベル付けをまだサポートしていないすべてのルールにラベルのサポートを追加しました。 | 2021-10-25 | | Amazon IP 評価リスト | `AWSManagedIPReputationList_xxxx` | IP 評価リストを再構築し、ルール名からサフィックスを削除し、 AWS WAF ラベルのサポートを追加しました。 | 2021-05-04 | | 匿名 IP リスト | `AnonymousIPList` `HostingProviderList` | AWS WAF ラベルのサポートが追加されました。 | 2021-05-04 | | Bot Control | すべて | Bot Control ルールセットを追加しました。 | 2021-04-01 | | コアルールセット (CRS) | `GenericRFI_QUERYARGUMENTS` | 二重 URL デコードを追加しました。 | 2021-03-03 | | コアルールセット (CRS) | `RestrictedExtensions_URIPATH` | ルールの設定を改善し、追加の URL デコードを追加しました。 | 2021-03-03 | | 管理者保護 | `AdminProtection_URIPATH` | 二重 URL デコードを追加しました。 | 2021-03-03 | | 既知の不正な入力 | `ExploitablePaths_URIPATH` | ルールの設定を改善し、追加の URL デコードを追加しました。 | 2021-03-03 | | Linux オペレーティングシステム | `LFI_QUERYARGUMENTS` | ルールの設定を改善し、追加の URL デコードを追加しました。 | 2021-03-03 | | Windows オペレーティングシステム | すべて | ルールの設定を改善しました。 | 2020-09-23 | | PHP アプリケーション | `PHPHighRiskMethodsVariables_QUERYARGUMENTS` `PHPHighRiskMethodsVariables_BODY` | ブロックを改善するために、テキスト変換を HTML デコードから URL デコードに変更しました。 | 2020-09-16 | | POSIX オペレーティングシステム | `UNIXShellCommandsVariables_QUERYARGUMENTS` `UNIXShellCommandsVariables_BODY` | ブロックを改善するために、テキスト変換を HTML デコードから URL デコードに変更しました。 | 2020-09-16 | | コアルールセット | `GenericLFI_QUERYARGUMENTS` `GenericLFI_URIPATH` GenericLFI\$1BODY | ブロックを改善するために、テキスト変換を HTML デコードから URL デコードに変更しました。 | 2020-08-07 | | Linux オペレーティングシステム | `LFI_URIPATH` `LFI_QUERYARGUMENTS` `LFI_BODY` | 検出とブロックを改良するために、テキスト変換を HTML エンティティデコードから URL デコードに変更しました。 | 2020-05-19 | | 匿名 IP リスト | すべて | ビューワー ID の難読化を許可するサービスからのリクエストをブロックする [IP 評価ルールグループ](aws-managed-rule-groups-ip-rep.md) の新しいルールグループは、ボットや地理的制限の回避に対する軽減に役立ちます。 | 2020-03-06 | | WordPress アプリケーション | `WordPressExploitableCommands_QUERYSTRING` | クエリ文字列内の悪用の対象となるコマンドをチェックする新しいルール。 | 2020-03-03 | | コアルールセット (CRS) | `SizeRestrictions_QUERYSTRING` `SizeRestrictions_Cookie_HEADER` `SizeRestrictions_BODY` `SizeRestrictions_URIPATH` | 精度を向上させるために、サイズ値の制約を調整しました。 | 2020-03-03 | | SQL データベース | `SQLi_URIPATH` | ルールは、メッセージ URI をチェックするようになりました。 | 2020-01-23 | | SQL データベース | `SQLi_BODY` `SQLi_QUERYARGUMENTS` `SQLi_COOKIE` | テキスト変換を更新しました。 | 2019-12-20 | | コアルールセット (CRS) | `CrossSiteScripting_URIPATH` `CrossSiteScripting_BODY` `CrossSiteScripting_QUERYARGUMENTS` `CrossSiteScripting_COOKIE` | テキスト変換を更新しました。 | 2019-12-20 | # 独自のルールグループの管理独自のルールグループを作成して、マネージドルールグループサービスに見つからないルールのコレクションや、自分で処理したいルールのコレクションを再利用できます。作成したルールグループは、保護パック (ウェブ ACL) と同じようにルールを保持し、保護パック (ウェブ ACL) と同じようにルールグループにルールを追加します。独自のルールグループを作成する場合は、そのルールにイミュータブルな最大容量を設定する必要があります。 **Topics** + [ # ルールグループの作成 ](waf-rule-group-creating.md) + [ # ルールグループの編集 ](waf-rule-group-editing.md) + [ # 保護パック (ウェブ ACL) でのルールグループの使用 ](waf-rule-group-using.md) + [ # ルールグループの削除 ](waf-rule-group-deleting.md) + [ # ルールグループの共有 ](waf-rule-group-sharing.md) # ルールグループの作成新しいルールグループを作成するには、このページにある手順に従います。 **ルールグループを作成するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで、**[Rule groups]** (ルールグループ)、**[Create rule group]** (ルールグループの作成) の順に選択します。 1. ルールの名前と説明を入力します。これらを使用して、ルールセットを識別して管理し、使用します。 `AWS`、`Shield`、`PreFM`、または `PostFM` で始まる名前は使用しないでください。これらの文字列は、予約されているか、他のサービスが管理するルールグループと混同される可能性があります。「[他のサービスによって提供されるルールグループを識別する](waf-service-owned-rule-groups.md)」を参照してください。 **注記** ウェブ ACL の作成後は、名前を変更できません。 1. **[Region]** (リージョン) で、ルールグループを保存するリージョンを選択します。Amazon CloudFront ディストリビューションを保護する保護パック (ウェブ ACL) でルールグループを使用するには、グローバル設定を使用する必要があります。リージョン別アプリケーションにもグローバル設定を使用できます。 1. [**次へ**] を選択します。 1. 保護パック (ウェブ ACL) 管理の場合と同様に、[**Rule builder (ルールビルダー)**] ウィザードを使用してルールグループにルールを追加します。唯一の違いは、ルールグループを別のルールグループに追加できないことです。 1. **[Capacity]** (容量) で、ルールグループによる保護パック (ウェブ ACL) 容量ユニット (WCU) の使用の最大値を設定します。この設定はイミュータブルです。WCU の詳細については、「[のウェブ ACL キャパシティユニット (WCUs) AWS WAF](aws-waf-capacity-units.md)」を参照してください。ルールグループにルールを追加すると、**[Add rules and set capacity]** (ルールの追加と容量の設定) ペインに、追加済みのルールに基づいて、必要な最小容量が表示されます。これとルールグループの将来の計画を使用して、ルールグループに必要な容量を見積もることができます。 1. ルールグループの設定を確認し、**[Create]** (作成) を選択します。 # ルールグループの編集ルールグループを追加、削除、あるいは設定を変更するには、このページの手順を使用してルールグループにアクセスします。 **本番稼働トラフィックのリスク** 保護パック (ウェブ ACL) で現在使用しているルールグループを変更すると、その変更は、使用されている場所に関係なく保護パック (ウェブ ACL) の動作に影響します。トラフィックへの潜在的な影響に納得がいくまで、すべての変更をステージング環境またはテスト環境でテストし、調整するようにしてください。その後、更新したルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。ガイダンスについては、「[AWS WAF 保護のテストとチューニング](web-acl-testing.md)」を参照してください。 **ルールグループを編集するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで、**[Rule groups]** (ルールグループ) を選択します。 1. 編集するルールグループ名を選択します。コンソールにルールグループのページが表示されます。 **注記** 編集するルールグループが表示されない場合は、**[ルールグループ]** セクション内に選択されたリージョンを確認してください。Amazon CloudFront ディストリビューションの保護に使用されるルールグループの場合は、**[グローバル (CloudFront)]** 設定を使用します。 1. 必要に応じてルールグループを編集します。ルールグループの変更可能なプロパティは、作成時と同様に編集できます。変更内容は、実行中にコンソールに保存されます。 **注記** ルールの名前を変更し、ルールのメトリクス名に変更を反映する場合は、メトリクス名も更新する必要があります。ルール名を変更しても、ルールのメトリクス名は自動的に更新 AWS WAF されません。ルールの JSON エディターを使用して、コンソールでルールを編集するときに、メトリック名を変更できます。API や、保護パック (ウェブ ACL) またはルールグループの定義に使用する JSON リストを使用して、両方の名前を変更することもできます。 **更新中の一時的な不一致** 保護パック (ウェブ ACL) または他の AWS WAF リソースを作成または変更すると、リソースが保存されているすべての領域にその変更が反映されるまでに少し時間がかかります。伝播時間は、数秒から数分までかかります。次の内容では、変更伝播中に直面する一時的な不整合性の例を紹介します。 + 保護パック (ウェブ ACL) を作成した後、それをリソースに関連付けようとすると、保護パック (ウェブ ACL) が利用できないことを示す例外が表示される場合があります。 + ルールグループを保護パック (ウェブ ACL) に追加した後、新しいルールグループのルールは、保護パック (ウェブ ACL) が使用されるエリアで有効になり、別のエリアでは有効にならない場合があります。 + ルールのアクション設定を変更した後、古いアクションを一部のエリアで確認され、新しいアクションを別のエリアで確認される場合があります。 + ブロックルールで使用されている IP セットに IP アドレスを追加した後、新しいアドレスはあるエリアではブロックされ、別のエリアでは許可される場合があります。 # 保護パック (ウェブ ACL) でのルールグループの使用保護パック (ウェブ ACL) でルールグループを使用するには、ルールグループリファレンスステートメントの保護パック (ウェブ ACL) にルールグループを追加します。 **本番稼働トラフィックのリスク** 本番稼働トラフィックの保護パック (ウェブ ACL) に変更をデプロイする前に、ステージング環境またはテスト環境でテストおよびチューニングしてトラフィックへの潜在的な影響を確認します。その後、更新したルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。ガイダンスについては、「[AWS WAF 保護のテストとチューニング](web-acl-testing.md)」を参照してください。 **注記** 保護パック (ウェブ ACL) で 1,500 WCU を超える容量を使用すると、保護パック (ウェブ ACL) の基本料金を超えるコストが発生します。詳細については、「[のウェブ ACL キャパシティユニット (WCUs) AWS WAF](aws-waf-capacity-units.md)」と「[AWS WAF 料金表](https://aws.amazon.com/waf/pricing/)」を参照してください。 **ルールグループを使用するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで、**[Rule groups]** (ルールグループ) を選択します。 1. 使用するルールグループ名を選択します。 1. **[ルールの追加]** を選択してから **[独自のルールとルールグループの追加]** を選択します。 1. **[ルールグループ]** を選択し、リストからルールグループを選択します。保護パック (ウェブ ACL) では、個々のルールアクションが Count またはその他のアクションを起こすように設定することで、ルールグループおよびそのルールの動作を変更できます。これは、ルールグループのテスト、ルールグループ内のルールからの誤検出の特定、マネージドルールグループによるリクエストの処理方法のカスタマイズなどを行うのに役立ちます。詳細については、「[でのルールグループアクションの上書き AWS WAF](web-acl-rule-group-override-options.md)」を参照してください。ルールグループにレートベースのステートメントが含まれている場合、ルールグループを使用する各保護パック (ウェブ ACL) は、ルールグループを使用する他の保護パック (ウェブ ACL) とは無関係に、レートベースのルールについて独自のレートトラッキングと管理を行います。詳細については、「[でのレートベースのルールステートメントの使用 AWS WAF](waf-rule-statement-type-rate-based.md)」を参照してください。 **更新中の一時的な不一致** 保護パック (ウェブ ACL) または他の AWS WAF リソースを作成または変更すると、リソースが保存されているすべての領域にその変更が反映されるまでに少し時間がかかります。伝播時間は、数秒から数分までかかります。次の内容では、変更伝播中に直面する一時的な不整合性の例を紹介します。 + 保護パック (ウェブ ACL) を作成した後、それをリソースに関連付けようとすると、保護パック (ウェブ ACL) が利用できないことを示す例外が表示される場合があります。 + ルールグループを保護パック (ウェブ ACL) に追加した後、新しいルールグループのルールは、保護パック (ウェブ ACL) が使用されるエリアで有効になり、別のエリアでは有効にならない場合があります。 + ルールのアクション設定を変更した後、古いアクションを一部のエリアで確認され、新しいアクションを別のエリアで確認される場合があります。 + ブロックルールで使用されている IP セットに IP アドレスを追加した後、新しいアドレスはあるエリアではブロックされ、別のエリアでは許可される場合があります。 # ルールグループの削除ルールグループを削除するには、このセクションのガイダンスに従います。 **参照セットとルールグループの削除** IP セット、正規表現パターンセット、ルールグループなど、保護パック (ウェブ ACL) で使用できるエンティティを削除すると、はエンティティが保護パック (ウェブ ACL) で現在使用されている AWS WAF かどうかを確認します。使用中であることがわかった場合、は AWS WAF 警告します。 AWS WAF はほとんどの場合、エンティティが保護パック (ウェブ ACL) によって参照されているかどうかを判断できます。ただし、まれに判別できないことがあります。エンティティが現在使用中でないことを確認する必要がある場合は、削除する前に保護パック (ウェブ ACL) でそのエンティティを確認してください。エンティティが参照されているセットである場合は、ルールグループでエンティティが使用されていないことも確認してください。 **ルールグループを削除するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで、**[Rule groups]** (ルールグループ) を選択します。 1. 削除するスナップショットを選択し、**[Delete]** (削除) を選択します。 **注記** 削除したいルールグループが表示されない場合は、**[ルールグループ]** セクション内のリージョンの選択を確認してください。Amazon CloudFront ディストリビューションの保護に使用されるルールグループの場合は、**[グローバル (CloudFront)]** 設定を使用します。 # ルールグループの共有ルールグループを別のアカウントと共有して、そのアカウントで使用することができます。 **ルールグループの共有** 1 つ以上の特定のアカウントと共有でき、組織内のすべてのアカウントと共有できます。ルールグループを共有するには、 AWS WAF API を使用して、必要なルールグループ共有のポリシーを作成します。詳細については、「*AWS WAF API リファレンス*」の「[PutPermissionPolicy](https://docs.aws.amazon.com/waf/latest/APIReference/API_PutPermissionPolicy.html)」を参照してください。 **共有されているルールグループの使用** ルールグループがアカウントと共有されている場合は、API 経由でアクセスでき、API 経由で保護パック (ウェブ ACL) を作成または更新するときに参照できます。詳細については、*AWS WAF API リファレンス*の「[GetRuleGroup](https://docs.aws.amazon.com/waf/latest/APIReference/API_GetRuleGroup.html)」、「[CreateWebACL](https://docs.aws.amazon.com/waf/latest/APIReference/API_CreateWebACL.html)」、および「[UpdateWebACL](https://docs.aws.amazon.com/waf/latest/APIReference/API_UpdateWebACL.html)」を参照してください。共有されているルールグループは、 AWS WAF コンソールのルールグループリストに表示されません。 # AWS Marketplace ルールグループこのセクションでは、 AWS Marketplace ルールグループを使用する方法について説明します。 AWS Marketplace ルールグループは、の AWS Marketplace コンソールからサブスクリプションで使用できます[AWS Marketplace](https://aws.amazon.com/marketplace)。 AWS Marketplace ルールグループをサブスクライブしたら、で使用できます AWS WAF。 AWS Firewall Manager AWS WAF ポリシーで AWS Marketplace ルールグループを使用するには、組織内の各アカウントがルールグループをサブスクライブする必要があります。 **さまざまなタイプのルールグループをサブスクライブするには、以下を使用します AWS Marketplace。** + AWS WAF パートナーマネージドルールグループ + クライアント側の保護本番トラフィックに使用する前に、 AWS WAF 保護の変更をテストして調整します。詳細については、「[AWS WAF 保護のテストとチューニング](web-acl-testing.md)」を参照してください。 **AWS Marketplace ルールグループの料金** AWS Marketplace ルールグループは、長期契約や最低契約金なしで使用できます。ルールグループをサブスクライブすると、月額料金 (時間単位の日割り計算) と、ボリュームに基づく継続的なリクエスト料金が課金されます。ただし、サブスクライブされたルールグループをウェブ ACL に追加して使用を開始した場合にのみ、サブスクリプション料金が課金されます。詳細については、「」の[AWS WAF 「料金](https://aws.amazon.com/waf/pricing/)表」と「各 AWS Marketplace ルールグループの説明」を参照してください[AWS Marketplace](https://aws.amazon.com/marketplace)。 **AWS Marketplace ルールグループについて質問がありますか?** AWS Marketplace 販売者が管理するルールグループに関する質問や機能の変更をリクエストするには、プロバイダーのカスタマーサポートチームにお問い合わせください。連絡先情報を検索するには、「[AWS Marketplace](https://aws.amazon.com/marketplace)」のプロバイダーのリストを参照してください。 AWS Marketplace ルールグループプロバイダーは、ルールグループを更新する方法や、ルールグループがバージョニングされているかどうかなど、ルールグループを管理する方法を決定します。プロバイダーは、ルール、ルールアクション、ルールが一致するウェブリクエストに追加するラベルなど、ルールグループの詳細も決定します。 ## AWS Marketplace ルールグループのサブスクライブ AWS WAF コンソールで AWS Marketplace ルールグループをサブスクライブまたはサブスクライブ解除できます。 **重要** AWS Firewall Manager ポリシーで AWS Marketplace ルールグループを使用するには、まず組織内の各アカウントがそのルールグループにサブスクライブする必要があります。 **AWS Marketplace ルールグループをサブスクライブするには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで、**[アドオン保護]** を選択します。 1. **AWS Marketplace** セクションで、ルールグループの名前を選択して、詳細と料金情報を表示します。 **ヒント** フィルターを使用して、最も関心のあるルールをすばやくソートします。例えば、**カテゴリ** フィルターを使用して、クライアント側の保護のみを表示できます。 1. AWS Marketplace ルールグループにサブスクライブするには: 1. ルールグループに移動し、**[Marketplace 経由でサブスクライブ]** を選択します。 1. 開いた Marketplace ページで、**[購入オプションを表示]** を選択し、**[サブスクライブ]** を選択します。 **注記** ルールグループをサブスクライブしない場合は、ポップアップを閉じます。 AWS Marketplace ルールグループをサブスクライブしたら、他のマネージドルールグループと同様に保護パック (ウェブ ACLs) で使用します。詳細については、「[で保護パック (ウェブ ACL) を作成する AWS WAF](web-acl-creating.md)」を参照してください。ルールグループを保護パック (ウェブ ACL) に追加する場合、ルールグループ内のルールおよびルールグループの結果のアクションをオーバーライドできます。詳細については、「[でのルールグループアクションの上書き AWS WAF](web-acl-rule-group-override-options.md)」を参照してください。 ## AWS Marketplace ルールグループからのサブスクリプション解除 AWS Marketplace コンソールで AWS Marketplace ルールグループのサブスクリプションを解除できます。 **重要** AWS Marketplace ルールグループのサブスクリプション料金を停止するには、ルールグループのサブスクリプションを解除するだけでなく、Firewall Manager AWS WAF ポリシー AWS WAF のすべての保護パック (ウェブ ACLs) から削除する必要があります。 AWS Marketplace ルールグループからサブスクリプションを解除しても、保護パック (ウェブ ACLs) から削除しない場合は、サブスクリプションに対して引き続き課金されます。 **AWS Marketplace ルールグループのサブスクリプションを解除するには** 1. すべての保護パック (ウェブ ACL) からルールグループを削除します。詳細については、「[での保護パック (ウェブ ACL) の編集 AWS WAF](web-acl-editing.md)」を参照してください。 1. [https://console.aws.amazon.com/marketplace](https://console.aws.amazon.com/marketplace) で AWS コンソールを開きます。 **[サブスクリプションを管理]** ページが表示されます。 1. **[配信方法]** リストを開き、**[SaaS]** を選択します。 1. **[契約]** で、**[アクションリスト]** を開き、サブスクリプションを解除するルールグループの名前の横にある **[サブスクリプションをキャンセル]** を選択します。 1. **[サブスクリプションをキャンセル]** ダイアログボックスで、**confirm** と入力し、**[はい、サブスクリプションをキャンセルします]** を選択します。 ## AWS Marketplace ルールグループのトラブルシューティング AWS Marketplace ルールグループが正当なトラフィックをブロックしていることがわかった場合は、次の手順を実行して問題をトラブルシューティングできます。 **AWS Marketplace ルールグループのトラブルシューティングを行うには** 1. アクションをオーバーライドして、正当なトラフィックをブロックしているルールをカウントします。 AWS WAF サンプリングされたリクエストまたは AWS WAF ログを使用して、特定のリクエストをブロックしているルールを特定できます。ログの `ruleGroupId` フィールドまたはサンプリングされたリクエストの `RuleWithinRuleGroup` フィールドを調べることによって、ルールを識別できます。パターン `##` 内のルールを識別できます。 1. リクエストのみをカウントするように特定のルールを設定しても問題が解決しない場合は、すべてのルールアクションを上書きするか、 AWS Marketplace ルールグループ自体のアクションを**上書きなし**から**上書きしてカウントするように**変更できます。これにより、ルールグループ内の個々のルールアクションに関係なく、ウェブリクエストが通過します。 1. 個々のルールアクションまたは AWS Marketplace ルールグループアクション全体を上書きした後、ルールグループプロバイダーのカスタマーサポートチームに連絡して、問題のトラブルシューティングをさらに行ってください。連絡先については、「 AWS Marketplace」の製品リストページのルールグループリストを参照してください。 ### AWS サポートへのお問い合わせ AWS WAF またはが管理するルールグループに関する問題については AWS、にお問い合わせください AWS サポート。 AWS Marketplace 販売者が管理するルールグループに関する問題については、プロバイダーのカスタマーサポートチームにお問い合わせください。連絡先情報を確認するには、プロバイダーのリストを参照してください AWS Marketplace。 # 他のサービスによって提供されるルールグループを識別するユーザーまたは組織の管理者が AWS Firewall Manager またはを使用してリソース保護 AWS Shield Advanced を管理する場合 AWS WAF、アカウントの保護パック (ウェブ ACLs) に追加されたルールグループのリファレンスステートメントが表示されることがあります。これらのルールグループの名前は、次の文字列で始まります。 + **`ShieldMitigationRuleGroup`** – これらのルールグループはによって管理 AWS Shield Advanced され、保護されたアプリケーションレイヤー (レイヤー 7) リソースにアプリケーションレイヤー DDoS の自動緩和を提供するために使用されます。保護されたリソースでアプリケーションレイヤー DDoS 自動緩和を有効にすると、Shield Advanced は、リソースに関連付けた保護パック (ウェブ ACL) に、これらのルールグループの 1 つを追加します。Shield Advanced は、ルールグループ参照ステートメントに優先順位の設定として 10,000,000 を割り当て、ユーザーが保護パック (ウェブ ACL) で設定したルールの後に実行されるようにします。これらのルールタイプの詳細については、「[Shield Advanced によるアプリケーションレイヤー DDoS 自動緩和](ddos-automatic-app-layer-response.md)」を参照してください。 **警告** 保護パック (ウェブ ACL) 内のこのルールグループを手動で管理しないでください。特に、`ShieldMitigationRuleGroup` ルールグループ参照ステートメントを保護パック (ウェブ ACL) から手動で削除しないでください。これにより、保護パック (ウェブ ACL) に関連付けられているすべてのリソースに意図しない結果が生じていた可能性もあります。代わりに、Shield Advanced を使用して、保護パック (ウェブ ACL) に関連付けられているリソースの自動緩和を無効にします。Shield Advanced は、ルールグループが自動緩和に必要でない場合に、ユーザーに代わって削除します。 + **`PREFMManaged` および `POSTFMManaged`** – これらのルールグループは、Firewall Manager AWS WAF ポリシー設定 AWS Firewall Manager に基づいてによって管理されます。Firewall Manager は、Firewall Manager が管理する保護パック (ウェブ ACL) 内にそれらのルールグループを提供します。 Firewall Manager は、`FMManagedWebACLV2` で始まる名前で保護パック (ウェブ ACL) を作成します。既存の保護パック (ウェブ ACL) を改良するように Firewall Manager を設定することもできます。その場合、保護パック (ウェブ ACL) 名は作成時に指定した名前です。いずれの場合も、Firewall Manager はこれらのルールグループを保護パック (ウェブ ACL) に追加します。詳細については、「[Firewall Manager での AWS WAF ポリシーの使用](waf-policies.md)」を参照してください。 # のウェブ ACL キャパシティユニット (WCUs) AWS WAF このセクションでは、ウェブ ACL キャパシティーユニット (WCU) とは何か、およびそれらの仕組みについて説明します。 AWS WAF は WCUs を使用して、ルール、ルールグループ、およびウェブ ACLs の実行に必要な運用リソースを計算および制御します。は、ルールグループとウェブ ACL を設定するときに WCU ACLs 制限 AWS WAF を適用します。WCUs がウェブトラフィックを AWS WAF 検査する方法には影響しません。 AWS WAF は、ルール、ルールグループ、およびウェブ ACLs容量を管理します。 **ルール WCU** AWS WAF は、ルールを作成または更新するときにルール容量を計算します。は、各ルールの相対コストを反映するために、ルールタイプごとに異なる容量を AWS WAF 計算します。実行コストがほとんどない単純なルールでは、処理能力が大きい複雑なルールよりも使用される WCU が少なくなります。例えば、サイズ制約ルールステートメントでは、正規表現パターンセットを使用して検査するステートメントよりも使用する WCU が少なくなります。ルール容量要件は通常、ルールタイプの基本コストに始まり、検査前にテキスト変換を追加する場合や JSON 本文を検査する場合など、複雑になるほど増えていきます。ルール容量要件については、「[でのルールステートメントの使用 AWS WAF](waf-rule-statements.md)」にあるルールステートメントのリストを参照してください。 **ルールグループ WCU** ルールグループの WCU 要件は、ルールグループ内で定義したルール数によって決まります。ルールグループの最大容量は 5,000 WCU です。各ルールグループには、所有者が作成時に割り当てるイミュータブルな容量設定があります。これは、で作成するマネージドルールグループとルールグループに当てはまります AWS WAF。ルールグループを変更する場合、それらの変更に伴うルールグループの WCU を容量内に収める必要があります。そうすることで、ルールグループを使用している保護パック (ウェブ ACL) が確実に容量要件内にとどまります。ルールグループで使用されている WCUs は、ルールの WCUs の合計から、ルールの動作を組み合わせることで取得 AWS WAF できる処理の最適化を引いたものです。たとえば、同じウェブリクエストコンポーネントを調べるために 2 つのルールを定義し、各ルールが検査する前にコンポーネントに特定の変換を適用する場合、変換の適用に対して 1 回だけ課金できる AWS WAF 可能性があります。保護パック (ウェブ ACL) のルールグループを使用するための WCU コストは、常にルールグループ作成時に定義した固定の WCU 設定です。ルールグループを作成するときは、ルールグループの有効期間中に使用するルール数に対応できる十分な容量を設定するように注意してください。 **保護パック (ウェブ ACL) WCU** 保護パック (ウェブ ACL) の WCU 要件は、保護パック (ウェブ ACL) 内で使用するルールとルールグループの数によって決まります。 + 保護パック (ウェブ ACL) のルールグループの使用コストは、ルールグループの容量設定に基づきます。 + ルールを使用するコストは、ルールの計算された WCUs から、保護パック (ウェブ ACL) のルールの組み合わせから取得 AWS WAF できる処理の最適化を引いたものです。たとえば、同じウェブリクエストコンポーネントを調べるために 2 つのルールを定義し、各ルールが検査する前にコンポーネントに特定の変換を適用する場合、変換の適用に対して 1 回だけ課金できる AWS WAF 可能性があります。保護パック (ウェブ ACL) の基本料金には、最大 1,500 WCU の容量が含まれます。階層型料金モデルに従って、1,500 を超える WCUs を使用すると、追加料金が発生します。は、保護パック (ウェブ ACL) の WCU 使用量の変化に応じて、保護パック (ウェブ ACL) の料金 AWS WAF を自動的に調整します。料金の詳細については、「[AWS WAF の料金](https://aws.amazon.com/waf/pricing/)」を参照してください。保護パック (ウェブ ACL) の最大容量は 5,000 WCU です。 ## ルールグループまたは保護パック (ウェブ ACL) の WCU を決定する前のセクションで説明したように、ルールグループまたは保護パック (ウェブ ACL) で使用される WCU の合計は、ルールグループまたは保護パック (ウェブ ACL) で定義されているすべてのルールの WCU の合計と同じか *それ以下* になります。 AWS WAF コンソールでは、保護パック (ウェブ ACL)、ウェブ ACL、またはルールグループにルールを追加するときに消費される容量を確認できます。ルールを追加するときに使用された現在のキャパシティユニットがコンソールに表示されます。 API を介して、保護パック (ウェブ ACL) またはルールグループで使用するルールの最大容量要件を確認できます。確認する場合は、チェックキャパシティコールでルールの JSON リストを指定します。詳細については、「*AWS WAF V2 API リファレンス*」の「[CheckCapacity](https://docs.aws.amazon.com/waf/latest/APIReference/API_CheckCapacity.html)」を参照してください。 # でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF このセクションでは、 AWS WAFでウェブリクエストのボディ、ヘッダー、および cookie を検査する際のサイズ制限を管理する方法を説明します。 AWS WAF は、ウェブリクエストコンポーネント本文、ヘッダー、または Cookie の非常に大きなコンテンツの検査をサポートしていません。基盤となるホストサービスには、検査 AWS WAF のために転送されるホストサービスの数とサイズの制限があります。たとえば、ホストサービスは 200 を超えるヘッダーをに送信しないため AWS WAF、205 ヘッダーのウェブリクエストの場合、 AWS WAF は最後の 5 つのヘッダーを検査できません。がウェブリクエストを保護されたリソースに進めること AWS WAF を許可すると、ウェブリクエスト全体が送信されます。これには、検査 AWS WAF できたカウントとサイズの制限外のコンテンツも含まれます。 **コンポーネント検査のサイズ制限** コンポーネント検査のサイズ制限は次のとおりです。 + **`Body` および `JSON Body`** – Application Load Balancer およびの場合 AWS AppSync、リクエストの本文の最初の 8 KB を検査 AWS WAF できます。CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Access では、デフォルトで最初の 16 KB を検査 AWS WAF でき、保護パック (ウェブ ACL) 設定で制限を最大 64 KB まで増やすことができます。詳細については、「[でのボディ検査の管理に関する考慮事項 AWS WAF](web-acl-setting-body-inspection-limit.md)」を参照してください。 + **`Headers`** – は、リクエストヘッダーの最初の 8 KB (8,192 バイト) まで、および最初の 200 個のヘッダーまで検査 AWS WAF できます。コンテンツは、最初の制限に達する AWS WAF まで検査できます。これらの制限は、リクエスト内のすべてのヘッダーを検査する場合に適用されます。1 つのヘッダーを検査する場合、はこれらのサイズや数の制限なしに、そのヘッダーの全内容を検査 AWS WAF できます。 + **`Cookies`** – は、リクエスト Cookie の最初の 8 KB (8,192 バイト) まで、および最初の 200 個の Cookie まで検査 AWS WAF できます。コンテンツは、最初の制限に達する AWS WAF まで検査できます。 **ルールステートメントのオーバーサイズの処理オプション** これらのリクエストコンポーネントタイプのいずれかを検査するルールステートメントを記述するときは、オーバーサイズコンポーネントの処理方法を指定します。オーバーサイズ処理は、ルールが検査するリクエストコンポーネントがサイズ制限を超えたときにウェブリクエストを AWS WAF どうするかを指示します。オーバーサイズコンポーネントを処理するためのオプションは次のとおりです。 + **Continue** – ルール検査基準に従って、リクエストコンポーネントを正常に検査します。 AWS WAF は、サイズ制限内にあるリクエストコンポーネントのコンテンツを検査します。 + **Match** – ウェブリクエストをルールステートメントに一致するものとして扱います。は、ルールの検査基準に照らして評価することなく、ルールアクションをリクエスト AWS WAF に適用します。 + **No match** – ウェブリクエストは、ルールの検査基準に照らして評価せずに、ルールステートメントと一致しないものとして扱います。は、一致しないルールの場合と同様に、保護パック (ウェブ ACL) の残りのルールを使用してウェブリクエストの検査 AWS WAF を続行します。 AWS WAF コンソールでは、これらの処理オプションのいずれかを選択する必要があります。コンソールの外では、デフォルトのオプションは Continue です。 Block に設定されたアクションを含むルールで Match オプションを使用する場合、そのルールは、検査したコンポーネントがオーバーサイズであるリクエストをブロックします。その他の設定では、リクエストの最終的な処理は、保護パック (ウェブ ACL) 内の他のルールの設定や、保護パック (ウェブ ACL) のデフォルトのアクション設定など、さまざまな要因によって異なります。 **ユーザーが所有していないルールグループでのオーバーサイズの処理** コンポーネントのサイズと数の制限は、保護パック (ウェブ ACL) で使用するすべてのルールに適用されます。これには、マネージドルールグループ内および別のアカウントと共有しているルールグループ内にある、使用しているが管理されていないルールが含まれます。ユーザーが管理していないルールグループを使用する場合、ルールグループに制限されたリクエストコンポーネントを検査するルールがあっても、そのルールではオーバーサイズのコンテンツが必要な方法で処理されない場合があります。 AWS マネージドルールがオーバーサイズコンポーネントを管理する方法については、「」を参照してください[AWS マネージドルールのルールグループリスト](aws-managed-rule-groups-list.md)。他のルールグループの詳細については、ルールグループプロバイダーにお問い合わせください。 **保護パック (ウェブ ACL) 内のオーバーサイズコンポーネントを管理するためのガイドライン** 保護パック (ウェブ ACL) でオーバーサイズのコンポーネントを処理する方法は、リクエストコンポーネントのコンテンツの予想サイズ、保護パック (ウェブ ACL) のデフォルトリクエスト処理、保護パック (ウェブ ACL) 内の他のルールがリクエストと一致して処理する方法など、さまざまな要因によって異なります。オーバーサイズのウェブリクエストコンポーネントを管理するための一般的なガイドラインは、以下のとおりです。 + オーバーサイズのコンポーネントコンテンツを含む一部のリクエストを許可する必要がある場合は、可能な場合は、それらのリクエストのみを明示的に許可するルールを追加します。同じコンポーネントタイプを検査する保護パック (ウェブ ACL) 内の他のルールより先に実行されるように、これらのルールの優先度を上げます。この方法では、 AWS WAF を使用して、保護されたリソースに渡すことを許可するオーバーサイズコンポーネントのコンテンツ全体を検査することはできません。 + 他のすべてのリクエストでは、次のように、制限を超えるリクエストをブロックすることで、余計なバイトが通過するのを防ぐことができます。 + **ルールとルールグループ** – サイズ制限のあるコンポーネントを検査するルールで、制限を超過するリクエストをブロックするようにオーバーサイズの処理を設定します。例えば、ルールで特定のヘッダーコンテンツを含むリクエストをブロックする場合、オーバーサイズのヘッダーコンテンツを持つリクエストと一致するようにオーバーサイズの処理を設定できます。別の例として、保護パック (ウェブ ACL) によりデフォルトでリクエストがブロックされ、かつルールで特定のヘッダーコンテンツが許可されている場合、オーバーサイズのヘッダーコンテンツを持つすべてのリクエストと一致しないように、ルールのオーバーサイズ処理を設定できます。 + **管理していないルールグループ** – 管理していないルールグループでオーバーサイズのリクエストコンポーネントを許可しないようにするには、リクエストコンポーネントタイプを検査して制限を超えるリクエストをブロックする別のルールを追加します。保護パック (ウェブ ACL) でそのルールがルールグループより先に実行されるように、ルールの優先度を上げます。例えば、保護パック (ウェブ ACL) で本文検査ルールを実行する前に、オーバーサイズの本文コンテンツを含むリクエストをブロックできます。次の手順では、このタイプのルールを追加する方法について説明します。 ## オーバーサイズのウェブリクエストコンポーネントのブロック保護パック (ウェブ ACL) にルールを追加して、オーバーサイズのコンポーネントを使用したリクエストをブロックできます。 **オーバーサイズのコンテンツをブロックするルールを追加するには** 1. 保護パック (ウェブ ACL) を作成または編集するときは、ルール設定で、**[Add rules]** (ルールを追加)、**[Add my own rules and rule groups]** (独自のルールとルールグループを追加)、**[Rule builder]** (ルールビルダー)、**[Rule visual editor]** (ルールビジュアルエディタ) の順に選択します。保護パック (ウェブ ACL) の作成または編集に関するガイダンスについては、「[でのウェブトラフィックメトリクスの表示 AWS WAF](web-acl-working-with.md)」を参照してください。 1. ルールの名前を入力し、**[Type]** (タイプ) 設定を **[Regular rule]** (通常のルール) のままにします。 1. 次の一致設定をデフォルトから変更します。 1. **[Statement]** (ステートメント) の **[Inspect]** (検査) で、ドロップダウンを開き、必要なウェブリクエストコンポーネント (**[Body]** (本文)、**[Headers]** (ヘッダー)、**[Cookies]** (cookie) のいずれか) を選択します。 1. **[Match type]** (一致タイプ) で、**[Size greater than]** (次より大きいサイズ:) を選択します。 1. **[サイズ]** で、コンポーネントタイプの最小サイズ以上の数値を入力します。ヘッダーと Cookie の場合は、`8192` を入力します。Application Load Balancer または AWS AppSync 保護パック (ウェブ ACLs) で、本文にと入力します`8192`。CloudFront、API Gateway、Amazon Cognito 、App Runner、または Verified Access 保護パック (ウェブ ACL) の本文で、デフォルトのボディサイズ制限を使用している場合は、`16384` を入力します。それ以外の場合は、護パック (ウェブ ACL) のために定義した本文のサイズ制限を入力します。 1. **[Oversize handling]** (オーバーサイズ処理) で、**[Match]** (一致) を選択します。 1. **[Action]** (アクション) で、**[Block]** (ブロック) を選択します。 1. **[Add Rule]** (ルールの追加) を選択します。 1. ルールを追加したら、**[Set rule priority]** (ルールの優先度の設定) ページで、同じコンポーネントタイプを検査する護パック (ウェブ ACL) 内のルールまたはルールグループよりも上に移動します。これにより、新しいルールの優先順位が低くなり、 AWS WAF が最初に評価します。詳細については、「[ルールの優先度を設定する](web-acl-processing-order.md)」を参照してください。 # でサポートされている正規表現構文 AWS WAF AWS WAF は、PCRE ライブラリで使用される正規表現パターン構文をサポートします`libpcre`。ライブラリは、「[PCRE - Perl Compatible Regular Expressions](http://www.pcre.org/)」で文書化されています。 AWS WAF は、ライブラリのすべてのコンストラクトをサポートしているわけではありません。例えば、一部のゼロ幅アサーションをサポートしますが、すべてではありません。サポートされているコンストラクトの包括的なリストはありません。ただし、無効な正規表現パターンを指定したり、サポートされていないコンストラクトを使用したりすると、 AWS WAF API は失敗を報告します。 AWS WAF は、次の PCRE パターンをサポートしていません。 + 後方参照と部分式取得 + サブルーチン参照と再帰パターン + 条件付きパターン + バックトラック制御動詞 + \$1C シングルバイトディレクティブ + \$1R 改行一致ディレクティブ + \$1K 一致開始位置リセットディレクティブ + コールアウトと埋め込みコード + アトミックグループと所有格量指定子 # の IP セットと正規表現パターンセット AWS WAF このセクションでは、IP セットと正規表現パターンセットのトピックについて説明します。 AWS WAF は、より複雑な情報をルールで参照して使用するセットに保存します。これらのセットにはそれぞれ名前があり、作成時に Amazon リソースネーム (ARN) が割り当てられます。これらのセットは、ルールステートメント内から管理でき、コンソールのナビゲーションペインから単独でアクセスして管理できます。ルールグループまたは保護パック (ウェブ ACL) で管理セットを使用できます。 + IP セットを使用するには、[IP セット一致ルールステートメント](waf-rule-statement-type-ipset-match.md) を参照してください。 + 正規表現パターンセットを使用するには、[正規表現パターンセット一致ルールステートメント](waf-rule-statement-type-regex-pattern-set-match.md) を参照してください。 **更新中の一時的な不一致** 保護パック (ウェブ ACL) または他の AWS WAF リソースを作成または変更すると、リソースが保存されているすべての領域にその変更が反映されるまでに少し時間がかかります。伝播時間は、数秒から数分までかかります。次の内容では、変更伝播中に直面する一時的な不整合性の例を紹介します。 + 保護パック (ウェブ ACL) を作成した後、それをリソースに関連付けようとすると、保護パック (ウェブ ACL) が利用できないことを示す例外が表示される場合があります。 + ルールグループを保護パック (ウェブ ACL) に追加した後、新しいルールグループのルールは、保護パック (ウェブ ACL) が使用されるエリアで有効になり、別のエリアでは有効にならない場合があります。 + ルールのアクション設定を変更した後、古いアクションを一部のエリアで確認され、新しいアクションを別のエリアで確認される場合があります。 + ブロックルールで使用されている IP セットに IP アドレスを追加した後、新しいアドレスはあるエリアではブロックされ、別のエリアでは許可される場合があります。 **Topics** + [ # での IP セットの作成と管理 AWS WAF ](waf-ip-set-managing.md) + [ # での正規表現パターンセットの作成と管理 AWS WAF ](waf-regex-pattern-set-managing.md) # での IP セットの作成と管理 AWS WAF IP セットは、ルールステートメントで一緒に使用する IP アドレスと IP アドレス範囲のコレクションを提供します。IP セットは AWS リソースです。保護パック (ウェブ ACL) またはルールグループで IP セットを使用するには、まずアドレス仕様`IPSet`で AWS リソースを作成します。その後、IP セットルールステートメントを保護パック (ウェブ ACL) またはルールグループに追加するときに、このセットを参照します。 ## IP セットの作成新しい IP セットを作成するには、このセクションの手順に従います。 **注記** このセクションの手順に加えて、IP 一致ルールを保護パック (ウェブ ACL) またはルールグループに追加するときに、新しい IP セットを追加するオプションがあります。このオプションを選択する場合は、この手順で必要な設定と同じ設定を指定する必要があります。 **IP セットを作成するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで、**[IP sets]** (IP セット) を選択し、**[Create IP set]** (IP セットの作成) を選択します。 1. IP セットの名前と説明を入力します。これらを使用して、セットを使用するときにそのセットを識別します。 **注記** IP セットの作成後は、名前を変更できません。 1. **[Region]** (リージョン) で、Global (CloudFront)、または IP セットを保存するリージョンを選択します。リージョン IP セットは、リージョンのリソースを保護する保護パック (ウェブ ACL) でのみ使用できます。Amazon CloudFront ディストリビューションを保護する保護パック (ウェブ ACL) で IP セットを使用するには、グローバル (CloudFront) を使用する必要があります。 1. **[IP version]** (IP バージョン) で、使用するバージョンを選択します。 1. **IP アドレス**テキストボックスに、CIDR 表記に 1 行あたり 1 つの IP アドレスまたは IP アドレス範囲を入力します。は、を除くすべての IPv4 および IPv6 CIDR 範囲 AWS WAF をサポートします`/0`。CIDR 表記の詳細については、Wikipedia の「[Classless Inter-Domain Routing](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing)」(クラスレスドメイン間ルーティング) 記事を参照してください。次に例を示します。 + IPv4 アドレス 192.0.2.44 を指定するには、**192.0.2.44/32** と入力します。 + IPv6 アドレス 2620:0:2d0:200:0:0:0:0 を指定するには、**2620:0:2d0:200:0:0:0:0/128** と入力します。 + IPv4 アドレス範囲 192.0.2.0～192.0.2.255 を指定するには、**192.0.2.0/24** と入力します。 + IPv6 アドレス範囲の 2620:0:2d0:200:0:0:0:0～2620:0:2d0:200:ffff:ffff:ffff:ffff を指定するには、**2620:0:2d0:200::/64** と入力します。 1. IP セットの設定を確認し、**[Create IP set]** (IP セットの作成) を選択します。 ## IP セットの削除参照セットを削除するには、このセクションのガイダンスに従います。 **参照セットとルールグループの削除** IP セット、正規表現パターンセット、ルールグループなど、保護パック (ウェブ ACL) で使用できるエンティティを削除すると、はエンティティが保護パック (ウェブ ACL) で現在使用されている AWS WAF かどうかを確認します。使用中であることがわかった場合、は AWS WAF 警告します。 AWS WAF はほとんどの場合、エンティティが保護パック (ウェブ ACL) によって参照されているかどうかを判断できます。ただし、まれに判別できないことがあります。エンティティが現在使用中でないことを確認する必要がある場合は、削除する前に保護パック (ウェブ ACL) でそのエンティティを確認してください。エンティティが参照されているセットである場合は、ルールグループでエンティティが使用されていないことも確認してください。 **IP セットを削除するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで **[IP sets]** (IP セット) を選択します。 1. 削除する IP セットを選択し、**[Delete]** (削除) を選択します。 # での正規表現パターンセットの作成と管理 AWS WAF 正規表現パターンセットは、ルールステートメントで一緒に使用する正規表現のコレクションを提供します。正規表現パターンセットは AWS リソースです。保護パック (ウェブ ACL) またはルールグループで正規表現パターンセットを使用するには、まず正規表現パターン仕様`RegexPatternSet`を使用して AWS リソースを作成します。その後、正規表現パターンセットルールステートメントを保護パック (ウェブ ACL) またはルールグループに追加するときに、このセットを参照します。正規表現パターンセットには、少なくとも1つの正規表現パターンが含まれている必要があります。正規表現パターンセットに複数の正規表現パターンが含まれている場合、ルールで使用される場合、パターン一致は `OR` ロジックと組み合わされます。つまり、リクエストコンポーネントがセット内のいずれかのパターンに一致する場合、ウェブリクエストはパターンセットルールステートメントと一致します。 AWS WAF は、いくつかの例外`libpcre`を除いて、PCRE ライブラリで使用されるパターン構文をサポートします。ライブラリは、「[PCRE - Perl Compatible Regular Expressions](http://www.pcre.org/)」で文書化されています。 AWS WAF サポートの詳細については、「」を参照してください[でサポートされている正規表現構文 AWS WAF](waf-regex-pattern-support.md)。 ## 正規表現パターンセットの作成新しい正規表現パターンセットを作成するには、このセクションの手順に従います。 **正規表現パターンセットを作成するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで、**[Regex pattern sets]** (正規表現パターンセット) を選択し、**[Create regex pattern set]** (正規表現パターンセットを作成) を選択します。 1. 正規表現パターンセットの名前と説明を入力します。これらを使用して、セットを使用するときに識別します。 **注記** 正規表現パターンセットの作成後は、名前を変更できません。 1. **[Region]** (リージョン) で、Global (CloudFront)、または正規表現パターンセットを保存するリージョンを選択します。正規表現パターンセットは、リージョンのリソースを保護する保護パック (ウェブ ACL) でのみ使用できます。Amazon CloudFront ディストリビューションを保護する保護パック (ウェブ ACL) で正規表現パターンセットを使用するには、グローバル (CloudFront) を使用する必要があります。 1. **[Regular expressions]** (正規表現) テキストボックスに、1 行につき 1 つの正規表現パターンを入力します。例えば、正規表現 `I[a@]mAB[a@]dRequest` は、`IamABadRequest`、`IamAB@dRequest`、`I@mABadRequest`、および `I@mAB@dRequest` の文字列に一致します。 AWS WAF は、いくつかの例外`libpcre`を除いて、PCRE ライブラリで使用されるパターン構文をサポートします。ライブラリは、「[PCRE - Perl Compatible Regular Expressions](http://www.pcre.org/)」で文書化されています。 AWS WAF サポートの詳細については、「」を参照してください[でサポートされている正規表現構文 AWS WAF](waf-regex-pattern-support.md)。 1. 正規表現パターンセットの設定を確認し、**[Create regex pattern set]** (正規表現パターンセットを作成) を選択します。 ## 正規表現パターンセットの削除参照セットを削除するには、このセクションのガイダンスに従います。 **参照セットとルールグループの削除** IP セット、正規表現パターンセット、ルールグループなど、保護パック (ウェブ ACL) で使用できるエンティティを削除すると、はエンティティが保護パック (ウェブ ACL) で現在使用されている AWS WAF かどうかを確認します。使用中であることがわかった場合、は AWS WAF 警告します。 AWS WAF はほとんどの場合、エンティティが保護パック (ウェブ ACL) によって参照されているかどうかを判断できます。ただし、まれに判別できないことがあります。エンティティが現在使用中でないことを確認する必要がある場合は、削除する前に保護パック (ウェブ ACL) でそのエンティティを確認してください。エンティティが参照されているセットである場合は、ルールグループでエンティティが使用されていないことも確認してください。 **正規表現パターンセットを削除するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで、**[Regex pattern sets]** (正規表現パターンセット) を選択します。 1. 削除する正規表現パターンセットを選択し、**[Delete]** (削除) を選択します。 # でカスタマイズされたウェブリクエストとレスポンス AWS WAF このセクションでは、 AWS WAF ルールアクションとデフォルト保護パック (ウェブ ACL) アクションにカスタムウェブリクエストとレスポンスの処理動作を追加する方法について説明します。カスタム設定は、アタッチ先のアクションが適用されるたびに適用されます。ウェブリクエストとレスポンスは、次の方法でカスタマイズできます。 + Allow、Count、CAPTCHA、Challenge アクションを使用すると、カスタムヘッダーをウェブリクエストに挿入できます。 AWS WAF がウェブリクエストを保護されたリソースに転送する場合、リクエストには、元のリクエスト全体と、挿入したカスタムヘッダーが含まれます。CAPTCHA および Challenge アクションの場合、リクエストが CAPTCHA またはチャレンジトークン検査に合格した場合のみに、 AWS WAF がカスタマイズを適用します。 + Block アクションを使用すると、レスポンスコード、ヘッダー、本文を含めた完全なカスタムレスポンスを定義できます。保護されたリソースは、が提供するカスタムレスポンスを使用してリクエストに応答します AWS WAF。カスタムレスポンスは、`403 (Forbidden)` のデフォルトの Block アクションレスポンスを置き換えます。 **カスタマイズできるアクション設定** 次のアクション設定を定義する際に、カスタムリクエストまたはレスポンスを指定できます。 + ルールアクション。詳細については、「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」を参照してください。 + 保護パック (ウェブ ACL) のデフォルトアクション。詳細については、「[で保護パック (ウェブ ACL) のデフォルトアクションを設定する AWS WAF](web-acl-default-action.md)」を参照してください。 **カスタマイズできないアクション設定** 保護パック (ウェブ ACL) で使用するルールグループについては、オーバーライドアクションでカスタムリクエスト処理を指定することは *できません*。「[のルールとルールグループで保護パック (ウェブ ACLs) を使用する AWS WAF](web-acl-processing.md)」を参照してください。「[でのマネージドルールグループステートメントの使用 AWS WAF](waf-rule-statement-type-managed-rule-group.md)」および「[でのルールグループステートメントの使用 AWS WAF](waf-rule-statement-type-rule-group.md)」も参照してください。 **更新中の一時的な不一致** 保護パック (ウェブ ACL) または他の AWS WAF リソースを作成または変更すると、リソースが保存されているすべての領域にその変更が反映されるまでに少し時間がかかります。伝播時間は、数秒から数分までかかります。次の内容では、変更伝播中に直面する一時的な不整合性の例を紹介します。 + 保護パック (ウェブ ACL) を作成した後、それをリソースに関連付けようとすると、保護パック (ウェブ ACL) が利用できないことを示す例外が表示される場合があります。 + ルールグループを保護パック (ウェブ ACL) に追加した後、新しいルールグループのルールは、保護パック (ウェブ ACL) が使用されるエリアで有効になり、別のエリアでは有効にならない場合があります。 + ルールのアクション設定を変更した後、古いアクションを一部のエリアで確認され、新しいアクションを別のエリアで確認される場合があります。 + ブロックルールで使用されている IP セットに IP アドレスを追加した後、新しいアドレスはあるエリアではブロックされ、別のエリアでは許可される場合があります。 **カスタムリクエストとレスポンスの使用制限** AWS WAF は、カスタムリクエストとレスポンスを使用するための最大設定を定義します。保護パック (ウェブ ACL) またはルールグループあたりのリクエストヘッダーの最大数、および単一のカスタムレスポンス定義のカスタムヘッダーの最大数はその一例です。詳細については、「[AWS WAF クォータ](limits.md)」を参照してください。 **Topics** + [ # ノンブロッキングアクションのためのカスタムリクエストヘッダーの挿入 ](customizing-the-incoming-request.md) + [ # Block アクションのカスタムレスポンスの送信 ](customizing-the-response-for-blocked-requests.md) + [ # カスタムレスポンスでサポートされるステータスコード ](customizing-the-response-status-codes.md) # ノンブロッキングアクションのためのカスタムリクエストヘッダーの挿入このセクションでは、ルールアクションがリクエストをブロックしない場合に、 AWS WAF にカスタムヘッダーを元の HTTP リクエストに挿入するように指示する方法について説明します。このオプションでは、リクエストにのみ追加します。元のリクエストの一部を変更したり、置き換えたりすることはできません。カスタムヘッダー挿入のユースケースには、挿入されたヘッダーに基づいてリクエストを異なる方法で処理するようにダウンストリームアプリケーションに通知し、分析のためにリクエストのフラグを立てることが含まれます。 **重要** このオプションは、ルールアクション Allow、Count、CAPTCHA、Challenge に適用され、Allow に設定されている保護パック (ウェブ ACL) のデフォルトアクションにも適用されます。ルールアクションの詳細については、「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」を参照してください。デフォルトの保護パック (ウェブ ACL) アクションの詳細については、「[で保護パック (ウェブ ACL) のデフォルトアクションを設定する AWS WAF](web-acl-default-action.md)」を参照してください。 ## カスタムリクエストヘッダー名を使用する場合の考慮事項 **リクエストヘッダーに追加されたプレフィックス** AWS WAF は、リクエストにすでに存在するヘッダーとの混同を避けるために`x-amzn-waf-`、で挿入するすべてのリクエストヘッダーにプレフィックスを付けます。たとえば、ヘッダー名を指定すると`sample`、はヘッダー AWS WAF を挿入します`x-amzn-waf-sample`。 **重要** セキュリティプラクティスとして、ヘッダーがすでに `x-amzn-waf-` で始まるリクエストをブロックする文字列一致ルールを追加できます。これにより、カスタムリクエストヘッダーを処理するときにによって AWS WAF 挿入される`x-amzn-waf-`プレフィックス文字列を模倣する非AWS WAF ソースからのリクエストがブロックされます。次の例は、`x-amzn-waf-`プレフィックスが挿入されなかったトラフィックをブロックするように設定された文字列一致ルールを示しています AWS WAF。 ``` "Rules": [ { "Name": "CustomHeader", "Priority": 0, "Statement": { "ByteMatchStatement": { "SearchString": " x-amzn-waf-", "FieldToMatch": { "Headers": { "MatchPattern": { "All": {} }, "MatchScope": "KEY", "OversizeHandling": "MATCH" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "STARTS_WITH" } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "CustomHeader" } } ] ``` 文字列一致ルールの使用については、「[文字列一致ルールステートメント](waf-rule-statement-type-string-match.md)」を参照してください。 **同じ名前のヘッダー** リクエストに既に挿入されているのと同じ名前のヘッダーがある場合、 AWS WAF はヘッダーを AWS WAF 上書きします。したがって、同じ名前の複数のルールでヘッダーを定義すると、リクエストを検査して一致を見つける最後のルールにはヘッダーが追加され、それよりも前のルールには追加されません。 ## 終了しないルールアクションを含むカスタムヘッダーの使用 Allow アクションとは異なり、Countアクションは保護パック (ウェブ ACL) の残りのルールを使用したウェブリクエストの処理 AWS WAF を停止しません。同様に、 CAPTCHAおよびがリクエストトークンが有効であるChallengeと判断した場合、これらのアクションはウェブリクエストの処理 AWS WAF を停止しません。したがって、これらのアクションを使用するルールでカスタムヘッダーを挿入する場合、後続のルールもカスタムヘッダーを挿入することがあります。ルールアクションの動作については、「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」を参照してください。例えば、表示された順序で優先順位付けされた次のルールがあるとします。 1. Count アクションと `RuleAHeader` という名前のカスタマイズされたヘッダーを持つ RuleA。 1. Allow アクションと `RuleBHeader` という名前のカスタマイズされたヘッダーを持つ RuleB。リクエストが RuleA と RuleB の両方に一致する場合、はヘッダーと `x-amzn-waf-RuleAHeader` AWS WAF を挿入し`x-amzn-waf-RuleBHeader`、保護されたリソースにリクエストを転送します。 AWS WAF は、リクエストの検査が完了すると、カスタムヘッダーをウェブリクエストに挿入します。したがって、アクションが Count に設定されているルールでカスタムリクエスト処理を使用する場合、追加するカスタムヘッダーは後続のルールによって検査されません。 ## カスタムリクエスト処理の例ルールのアクションまたは保護パック (ウェブ ACL) のデフォルトアクション用に、カスタムリクエスト処理を定義します。次のリストは、保護パック (ウェブ ACL) のデフォルトアクションに追加されたカスタム処理用の JSON を示しています。 ``` { "Name": "SampleWebACL", "Scope": "REGIONAL", "DefaultAction": { "Allow": { "CustomRequestHandling": { "InsertHeaders": [ { "Name": "fruit", "Value": "watermelon" }, { "Name": "pie", "Value": "apple" } ] } } }, "Description": "Sample protection pack (web ACL) with custom request handling configured for default action.", "Rules": [], "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "SampleWebACL" } } ``` # Block アクションのカスタムレスポンスの送信このセクションでは、に設定されたルールアクションまたは保護パック (ウェブ ACL) のデフォルトアクションのためにカスタム HTTP レスポンスをクライアントに送信する AWS WAF ようにに指示する方法について説明しますBlock。ルールアクションの詳細については、「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」を参照してください。デフォルトの保護パック (ウェブ ACL) アクションの詳細については、「[で保護パック (ウェブ ACL) のデフォルトアクションを設定する AWS WAF](web-acl-default-action.md)」を参照してください。 Block アクションのカスタムレスポンス処理を定義すると、ステータスコード、ヘッダー、レスポンス本文を定義します。で使用できるステータスコードのリストについては AWS WAF、次のセクション「」を参照してください[カスタムレスポンスでサポートされるステータスコード](customizing-the-response-status-codes.md)。 **ユースケース** カスタムレスポンスのユースケースには、次が含まれます。 + 非デフォルトのステータスコードをクライアントに送り返します。 + カスタムレスポンスヘッダーをクライアントに送り返します。`content-type` を除き、任意のヘッダー名を指定できます。 + 静的エラーページをクライアントに送り返します。 + クライアントを別の URL にリダイレクトします。これを行うには、`301 (Moved Permanently)` または `302 (Found)` などの `3xx` リダイレクトステータスコードのいずれかを指定してから、新しい URL で `Location` という名前が付けられた新しいヘッダーを指定します。 **保護されたリソースで定義したレスポンスとのインタラクション** アクションに AWS WAF Block指定したカスタムレスポンスは、保護されたリソースで定義したレスポンス仕様よりも優先されます。で保護する AWS リソースのホストサービスは、ウェブリクエストのカスタムレスポンス処理を許可する AWS WAF 場合があります。次に例を示します。 + Amazon CloudFront を使用して、ステータスコードに基づいてエラーページをカスタマイズできます。カスタムエラーページの詳細については、「*Amazon CloudFront デベロッパーガイド*」の「[カスタムエラーレスポンスの生成](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GeneratingCustomErrorResponses.html)」を参照してください。 + Amazon API Gateway では、ゲートウェイのレスポンスおよびステータスコードを定義できます。詳細については、「*Amazon API Gateway デベロッパーガイド*」の「[API Gateway でのゲートウェイレスポンス](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-gatewayResponse-definition.html)」を参照してください。保護された AWS リソースの AWS WAF カスタムレスポンス設定とカスタムレスポンス設定を組み合わせることはできません。個々のウェブリクエストの応答の仕様は、 AWS WAF または保護されたリソースから、そのすべてが取得されます。が AWS WAF ブロックするウェブリクエストの場合、優先順位を次に示します。 1. **AWS WAF カスタムレスポンス** – AWS WAF Blockアクションでカスタムレスポンスが有効になっている場合、保護されたリソースは設定されたカスタムレスポンスをクライアントに送り返します。保護されたリソース自体で定義する応答設定は、効果がありません。 1. **保護されたリソースで定義されているカスタムレスポンス** - それ以外の場合、保護されたリソースにカスタムレスポンス設定が指定されているときは、保護されたリソースはそれらの設定を使用してクライアントに応答します。 1. **AWS WAF デフォルトBlockレスポンス** – それ以外の場合、保護されたリソースは AWS WAF デフォルトのレスポンスでクライアントにBlock応答します`403 (Forbidden)`。が AWS WAF 許可するウェブリクエストの場合、保護されたリソースの設定によって、クライアントに返送するレスポンスが決まります。許可されたリクエスト AWS WAF に対してでレスポンス設定を構成することはできません。許可されたリクエスト AWS WAF に対してで設定できる唯一のカスタマイズは、リクエストを保護されたリソースに転送する前に、元のリクエストにカスタムヘッダーを挿入することです。このオプションについては、前のセクション「[ノンブロッキングアクションのためのカスタムリクエストヘッダーの挿入](customizing-the-incoming-request.md)」で説明しました。 **カスタムレスポンスヘッダー** `content-type` を除き、任意のヘッダー名を指定できます。 **カスタムレスポンス本文** カスタムレスポンスの本文は、それを使用する保護パック (ウェブ ACL) またはルールグループのコンテキスト内で定義します。カスタムレスポンスボディの定義後、それを作成した保護パック (ウェブ ACL) またはルールグループの他の場所を参照して使用できます。個々の Block アクション設定では、使用するカスタム本文を参照し、カスタムレスポンスのステータスコードおよびヘッダーを定義します。コンソールでカスタムレスポンスを作成するときは、既に定義したレスポンス本文から選択するか、新しい本文を作成できます。コンソールの外部では、保護パック (ウェブ ACL) またはルールグループレベルでカスタムレスポンス本文を定義し、保護パック (ウェブ ACL) またはルールグループ内のアクション設定から参照します。これは、次のセクションの JSON の例で示されます。 **カスタムレスポンスの例** 次の例は、カスタムレスポンス設定を持つルールグループの JSON をリストします。カスタムレスポンス本文は、ルールグループ全体のために定義され、ルールアクションでキーによって参照されます。 ``` { "ARN": "test_rulegroup_arn", "Capacity": 1, "CustomResponseBodies": { "CustomResponseBodyKey1": { "Content": "This is a plain text response body.", "ContentType": "TEXT_PLAIN" } }, "Description": "This is a test rule group.", "Id": "test_rulegroup_id", "Name": "TestRuleGroup", "Rules": [ { "Action": { "Block": { "CustomResponse": { "CustomResponseBodyKey": "CustomResponseBodyKey1", "ResponseCode": 404, "ResponseHeaders": [ { "Name": "BlockActionHeader1Name", "Value": "BlockActionHeader1Value" } ] } } }, "Name": "GeoMatchRule", "Priority": 1, "Statement": { "GeoMatchStatement": { "CountryCodes": [ "US" ] } }, "VisibilityConfig": { "CloudWatchMetricsEnabled": true, "MetricName": "TestRuleGroupReferenceMetric", "SampledRequestsEnabled": true } } ], "VisibilityConfig": { "CloudWatchMetricsEnabled": true, "MetricName": "TestRuleGroupMetric", "SampledRequestsEnabled": true } } ``` # カスタムレスポンスでサポートされるステータスコードこのセクションでは、カスタムレスポンスで使用できるステータスコードを一覧表示します。HTTP ステータスコードの詳細については、Internet Engineering Task Force (IETF) による「[Status Codes](https://www.rfc-editor.org/rfc/rfc9110.html#name-status-codes)」(ステータスコード) およびウィキペディアの「[List of HTTP status codes](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes)」(HTTP ステータスコードのリスト) を参照してください。カスタムレスポンスでが AWS WAF サポートする HTTP ステータスコードは次のとおりです。 + `2xx Successful` + `200` – `OK` + `201` – `Created` + `202` – `Accepted` + `204` – `No Content` + `206` – `Partial Content` + `3xx Redirection ` + `300` – `Multiple Choices` + `301` – `Moved Permanently` + `302` – `Found` + `303` –`See Other` + `304` – `Not Modified` + `307` – `Temporary Redirect` + `308` – `Permanent Redirect` + `4xx Client Error ` + `400` – `Bad Request` + `401` – `Unauthorized` + `403` – `Forbidden` + `404` – `Not Found` + `405` – `Method Not Allowed` + `408` – `Request Timeout` + `409` – `Conflict` + `411` – `Length Required` + `412` – `Precondition Failed` + `413` – `Request Entity Too Large` + `414` – `Request-URI Too Long` + `415` – `Unsupported Media Type` + `416` – `Requested Range Not Satisfiable` + `421` – `Misdirected Request` + `429` – `Too Many Requests` + `5xx Server Error` + `500` – `Internal Server Error` + `501` – `Not Implemented` + `502` – `Bad Gateway` + `503` – `Service Unavailable` + `504` – `Gateway Timeout` + `505` – `HTTP Version Not Supported` # でのウェブリクエストのラベル付け AWS WAF このセクションでは、 AWS WAF ラベルについて説明します。ラベルは、ルールがリクエストと一致するときに、ルールによってウェブリクエストに追加されるメタデータです。追加された場合、保護パック (ウェブ ACL) 評価が終了するまで、ラベルはリクエストに引き続き存在します。保護パック (ウェブ ACL) の評価で後から実行されるルール内のラベルには、ラベル照合ステートメントを使用してアクセスできます。詳細については、「[ラベル一致ルールステートメント](waf-rule-statement-type-label-match.md)」を参照してください。ウェブリクエストのラベルは Amazon CloudWatch ラベルメトリクスを生成します。メトリクスとディメンションのリストについては、「[ラベルメトリクスとディメンション](waf-metrics.md#waf-metrics-label)」を参照してください。CloudWatch および AWS WAF コンソールからメトリクスとメトリクスの概要にアクセスする方法については、「[AWS WAF 保護のモニタリングと調整](web-acl-testing-activities.md)」を参照してください。 **ラベリングのユースケース** AWS WAF ラベルの一般的なユースケースは次のとおりです。 + **リクエストに対してアクションを実行する前に、複数のルールステートメントに対するウェブリクエストを評価する – **保護パック (ウェブ ACL) 内のルールで一致が見つかった後、ルールアクションが保護パック (ウェブ ACL) 評価を終了しない場合、は保護パック (ウェブ ACL) に対するリクエストの評価 AWS WAF を続行します。リクエストを許可または拒否するか判断する前、ラベルを使用して複数のルールから情報を評価および収集できます。これを行うには、既存のルールのアクションを Count に変更し、ラベルを一致リクエストに追加するように設定します。その後、他のルールの後に実行する新しいルールを 1 つ以上追加し、ラベルを評価してラベル一致の組み合わせに応じてリクエストを管理するように設定します。 + **地域別のウェブリクエストの管理** – 地理的一致ルールを単独で使用して、ウェブリクエストを発信国別に管理できます。地域レベルの精度で場所を微調整するには、地理一致ルールを Count アクションと一緒に使用し、それに続いてラベルマッチルールを使用します。地理一致ルールの情報については、「[地理的一致ルールステートメント](waf-rule-statement-type-geo-match.md)」を参照してください。 + **複数のルール間でロジックを再利用する** – 複数のルールで同じロジックを再利用する必要がある場合は、ラベルを使用してそのロジックを単一のソースにして、結果をテストします。ネストされたルールステートメントの共通のサブセットを使用する複雑なルールが複数ある場合、複雑なルール間で共通ルールセットを複製すると、時間がかかり、エラーが発生しやすくなります。ラベルを使用すると、一致するリクエストをカウントし、それらにラベルを追加する共通ルールサブセットを使用して新しいルールを作成できます。新しいルールを保護パック (ウェブ ACL) に追加して、元の複雑なルールの前に実行されるようにします。その後、元のルールで、共有ルールサブセットを、ラベルをチェックする単一のルールに置き換えます。例えば、ログインパスにのみ適用する複数のルールがあるとします。各ルールで潜在的なログインパスと一致する同じロジックを指定するのではなく、そのロジックを含む 1 つの新しいルールを実装できます。新しいルールで、一致するリクエストにラベルを追加して、リクエストがログインパス上にあることを示します。保護パック (ウェブ ACL) で、この新しいルールの優先順位の数値設定を、元のルールの数値よりも小さく設定して、最初に実行されるようにします。その後、元のルールで、共有ロジックをラベルの存在のチェックに置き換えます。ジョブの優先順位の設定については、「[ルールの優先度を設定する](web-acl-processing-order.md)」を参照してください。 + **ルールグループ内のルールに対する例外を作成する** – このオプションは、表示または変更できないマネージドルールグループに特に役立ちます。多くのマネージドルールグループのルールはウェブリクエストにラベルを追加して一致したルールを示し、場合によってはその一致に関する追加情報を提供します。リクエストにラベルを追加するルールグループを使用すると、ルールグループのルールが一致をカウントするようにオーバーライドし、その後にルールグループラベルに基づいたウェブリクエストを処理するルールグループの後にルールを実行できます。すべての AWS マネージドルールは、一致するウェブリクエストにラベルを追加します。詳細については、「[AWS マネージドルールのルールグループリスト](aws-managed-rule-groups-list.md)」のルールの説明を参照してください。 + **ラベルメトリクスの使用によるトラフィックパターンの監視** — ルールを使用して追加したラベルのメトリクスや、保護パック (ウェブ ACL) で使用するマネージドルールグループによって追加されたメトリクスのメトリクスにアクセスできます。 AWS マネージドルールのルールグループのすべては、評価するウェブリクエストにラベルを追加します。ラベルメトリクスとディメンションのリストについては、「[ラベルメトリクスとディメンション](waf-metrics.md#waf-metrics-label)」を参照してください。メトリクスとメトリクスの概要には、CloudWatch および AWS WAF コンソールの保護パック (ウェブ ACL) ページからアクセスできます。詳細については、「[AWS WAF 保護のモニタリングと調整](web-acl-testing-activities.md)」を参照してください。 # でのラベル付けの仕組み AWS WAF このセクションでは、 AWS WAF ラベルの仕組みについて説明します。ルールがウェブリクエストに一致すると、ルールにラベルが定義されている場合、はルール評価の最後にラベルをリクエスト AWS WAF に追加します。保護パック (ウェブ ACL) 内のルール一致後に評価されるルールは、ルールが追加したラベルと照合できます。 **何によってリクエストにラベルが追加されるのか** リクエストを評価する保護パック (ウェブ ACL) コンポーネントは、リクエストにラベルを追加できます。 + ルールグループ参照ステートメントではないルールは、一致するウェブリクエストにラベルを追加できます。ラベル付け基準はルール定義の一部であり、ウェブリクエストがルールと一致すると、はルールのラベルをリクエスト AWS WAF に追加します。詳細については、「[AWS WAF ラベルを追加するルール](waf-rule-label-add.md)」を参照してください。 + 地理照合ステートメントは、ステートメントの結果が一致するかどうかに関係なく、検査するすべてのリクエストに国と地域のラベルを追加します。詳細については、「[地理的一致ルールステートメント](waf-rule-statement-type-geo-match.md)」を参照してください。 + AWS WAF すべての AWS の管理ルールは、検査するリクエストにラベルを追加します。ルールグループ内のルールの一致に基づいてラベルを追加します。また、インテリジェントな脅威軽減ルールグループを使用すると追加されるトークンラベルなど、マネージドルールグループが使用する AWS プロセスに基づいてラベルを追加します。各マネージドルールグループが追加するラベルの詳細については、「[AWS マネージドルールのルールグループリスト](aws-managed-rule-groups-list.md)」を参照してください。 **がラベル AWS WAF を管理する方法** AWS WAF は、ルールによるリクエストの検査の最後に、ルールのラベルをリクエストに追加します。ラベル付けは、アクションと同様にルールの照合アクティビティの一部です。保護パック (ウェブ ACL) 評価が終了した後、ラベルはウェブリクエストに保持されません。ルールが追加するラベルに照らして他のルールが照合するためには、ルールアクションが保護パック (ウェブ ACL) によるウェブリクエストの評価を終了してはなりません。ルールアクションは Count、CAPTCHA、Challenge に設定する必要があります。保護パック (ウェブ ACL) の評価が終了しない場合、保護パック (ウェブ ACL) 内の後続のルールは、リクエストに対してラベル一致基準を実行できます。ルールアクションの詳細については、「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」を参照してください。 **保護パック (ウェブ ACL) 評価中のラベルにアクセスする** 追加すると、 AWS WAF が保護パック (ウェブ ACL) に対してリクエストを評価する限り、ラベルはリクエストで使用できます。保護パック (ウェブ ACL) 内のすべてのルールは、同じ保護パック (ウェブ ACL) で既に実行されているルールによって追加されたラベルにアクセスできます。これには、保護パック (ウェブ ACL) 内で直接定義されたルールと、保護パック (ウェブ ACL) で使用されるルールグループ内の手以後されたルールが含まれます。 + ラベル一致ステートメントを使用してルールのリクエスト検査基準のラベルと照合できます。リクエストに添付されているどのラベルとも照合できます。ステートメントの詳細については、「[ラベル一致ルールステートメント](waf-rule-statement-type-label-match.md)」を参照してください。 + 地理的照合ステートメントは、一致の有無にかかわらずラベルを追加しますが、ステートメントに含まれる保護パック (ウェブ ACL) ルールがリクエストの評価を完了して初めて使用できるようになります。 + 論理 `AND` ステートメントなどの単一のルールを使用して、地理的ラベルに対して地域照合ステートメントの後にラベル照合チステートメントを実行することはできません。ラベル照合ステートメントは、地理的照合ステートメントを含むルールの後に実行される別のルールに記述する必要があります。 + 地理的照合ステートメントをレートベースのルールステートメント、またはマネージドルールグループ参照ステートメント内のスコープダウンステートメントとして使用する場合、地理的照合ステートメントによって追加されたラベルは、包含ルールステートメントでは検査用に使用できません。レートベースのルールステートメントまたはルールグループの地理的ラベルを調べる必要がある場合は、事前に実行される別のルールで地理的照合ステートメントを実行する必要があります。 **保護パック (ウェブ ACL) 評価対象外のラベル情報にアクセスする** 保護パック (ウェブ ACL) 評価が終了した後、ラベルはウェブリクエストに保持されませんが、 AWS WAF はラベル情報をログとメトリクスに記録します。 + AWS WAF は、1 つのリクエストで最初の 100 個のラベルの Amazon CloudWatch メトリクスを保存します。ラベルメトリクスへのアクセスの詳細については、「[Amazon CloudWatch によるモニタリング](monitoring-cloudwatch.md)」および「[ラベルメトリクスとディメンション](waf-metrics.md#waf-metrics-label)」を参照してください。 + AWS WAF は、 AWS WAF コンソールの保護パック (ウェブ ACL) トラフィック概要ダッシュボードの CloudWatch ラベルメトリクスを要約します。ダッシュボードにはどの保護パック (ウェブ ACL) ページからでもアクセスできます。詳細については、「[保護パック (ウェブ ACL) のトラフィック概要ダッシュボード](web-acl-dashboards.md)」を参照してください。 + AWS WAF は、リクエストの最初の 100 個のラベルのラベルをログに記録します。ルールアクションとともにラベルを使用して、 AWS WAF が記録するログをフィルタリングできます。詳細については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。保護パック (ウェブ ACL) の評価では、ウェブリクエストに 100 個を超えるラベルを適用し、100 個を超えるラベルと照合できますが、ログとメトリクスには最初の 100 個 AWS WAF のみが記録されます。 # でのラベル構文と命名要件 AWS WAF このセクションでは、 AWS WAF ラベルを構築して照合する方法について説明します。ラベルは、プレフィックス、オプションの名前空間、および名前で構成される文字列です。ラベルのコンポーネントはコロンで区切られます。ラベルには次の要件と特性があります。 + ラベルでは、大文字と小文字が区別されます。 + 各ラベル名前空間またはラベル名には、最大 128 文字を使用できます。 + ラベルには、最大 5 つの名前空間を指定できます。 + ラベルのコンポーネントはコロン (`:`) で区切られます。 + ラベルに指定する名前空間または名前で次の予約済み文字列を使用することはできません: `awswaf`、`aws`、`waf`、`rulegroup`、`webacl`、`regexpatternset`、`ipset`、および `managed`。 ## ラベル構文完全修飾ラベルには、プレフィックス、オプションの名前空間、およびラベル名があります。プレフィクスは、ラベルを追加したルールのルールグループまたは保護パック (ウェブ ACL) コンテキストを識別します。名前空間は、ラベルのコンテキストを追加するために使用されることがあります。ラベル名は、ラベルの詳細レベルが最も低いレベルになります。多くの場合、リクエストにラベルを追加した特定のルールを示します。ラベルのプレフィックスは、そのオリジンによって異なります。 + **ラベル** – 保護パック (ウェブ ACL) およびルールグループのルールで作成するラベルの完全なラベル構文を次に示します。エンティティタイプは `rulegroup` と `webacl` です。 ``` awswaf:::::...: ``` + ラベル名前空間プレフィックス: `awswaf::::` + カスタム名前空間の追加: `:…:` ルールグループまたは保護パック (ウェブ ACL) でルールのラベルを定義する場合は、カスタム名前空間文字列とラベル名をコントロールします。残りはによって生成されます AWS WAF。は、すべてのラベルにとアカウント`awswaf`および保護パック (ウェブ ACL) またはルールグループのエンティティ設定 AWS WAF を自動的にプレフィックスします。 + **マネージドルールグループのラベル** – マネージドルールグループのルールによって作成されるラベルの完全なラベル構文を次に示します。 ``` awswaf:managed::::...: ``` + ラベル名前空間プレフィックス: `awswaf:managed:::` + カスタム名前空間の追加: `:…:` すべての AWS マネージドルールルールグループはラベルを追加します。マネージドルールグループの詳細については、「[でのマネージドルールグループの使用 AWS WAF](waf-managed-rule-groups.md)」を参照してください。 + **他の AWS プロセスのラベル** – これらのプロセスは AWS マネージドルールルールグループによって使用されるため、マネージドルールグループを使用して評価するウェブリクエストに追加されます。マネージドルールグループによって呼び出されるプロセスが作成するラベルの完全なラベル構文を次に示します。 ``` awswaf:managed:::...: ``` + ラベル名前空間プレフィックス: `awswaf:managed::` + カスタム名前空間の追加: `:…:` このタイプのラベルは、 AWS プロセスを呼び出すマネージドルールグループ用に一覧表示されます。マネージドルールグループの詳細については、「[でのマネージドルールグループの使用 AWS WAF](waf-managed-rule-groups.md)」を参照してください。 ## ルールの例にラベルを付ける次のラベルの例は、アカウント 111122223333 に属する `testRules` という名前のルールグループのルールによって定義されています。 ``` awswaf:111122223333:rulegroup:testRules:testNS1:testNS2:LabelNameA ``` ``` awswaf:111122223333:rulegroup:testRules:testNS1:LabelNameQ ``` ``` awswaf:111122223333:rulegroup:testRules:LabelNameZ ``` 次のリストは、JSON のラベル指定の例を示しています。これらのラベル名には、末尾のラベル名の前にカスタム名前空間文字列が含まれます。 ``` Rule: { Name: "label_rule", Statement: {...} RuleLabels: [ Name: "header:encoding:utf8", Name: "header:user_agent:firefox" ], Action: { Count: {} } } ``` **注記** このタイプのリストには、ルール JSON エディタを通じてコンソールでアクセスできます。前述のラベルの例と同じルールグループおよびアカウントで前述のルールを実行すると、結果として生じる完全修飾ラベルは次のようになります。 ``` awswaf:111122223333:rulegroup:testRules:header:encoding:utf8 ``` ``` awswaf:111122223333:rulegroup:testRules:header:user_agent:firefox ``` ## マネージドルールグループのラベル例マネージド AWS ルールのルールグループとプロセスから呼び出すラベルの例を次に示します。 ``` awswaf:managed:aws:core-rule-set:NoUserAgent_Header ``` ``` awswaf:managed:aws:sql-database:SQLiExtendedPatterns_QueryArguments ``` ``` awswaf:managed:aws:atp:aggregate:attribute:compromised_credentials ``` ``` awswaf:managed:token:accepted ``` # AWS WAF ラベルを追加するルールほぼすべてのルールで、ラベルを定義し AWS WAF 、一致するリクエストに適用できます。次のルールタイプが唯一の例外です。 + **レートベースのルールは、レート制限中のみラベルを付与します** – レートベースのルールは、特定の集計インスタンスが AWS WAFによってレート制限されている間のみ、ウェブリクエストにラベルを追加します。レートベースルールの詳細については、「[でのレートベースのルールステートメントの使用 AWS WAF](waf-rule-statement-type-rate-based.md)」を参照してください。 + **ルールグループ参照ステートメントではラベル付けは許可されません** – コンソールは、ルールグループステートメントまたはマネージドルールグループステートメントのラベルを受け付けません。API を使用して、いずれかのステートメントタイプのラベルを指定すると、検証例外が発生します。これらのステートメントのタイプについては、「[でのマネージドルールグループステートメントの使用 AWS WAF](waf-rule-statement-type-managed-rule-group.md)」および「[でのルールグループステートメントの使用 AWS WAF](waf-rule-statement-type-rule-group.md)」を参照してください。 **WCU** – 保護パック (ウェブ ACL) またはルールグループのルールで定義する 5 つのラベルごとに 1 つの WCU。 **ステートメントの場所** + コンソールの**ルールビルダー** – ルールの **[Action]** (アクション) 設定の **[Label]** (ラベル) の下。 + **API データタイプ** – `Rule` `RuleLabels` ルールでラベルを定義するには、ラベル名前空間プレフィックスに追加するカスタム名前空間文字列と名前を指定します。は、ルールを定義するコンテキストからプレフィックス AWS WAF を取得します。これについては、「[でのラベル構文と命名要件 AWS WAF](waf-rule-label-requirements.md)」の下のラベル構文情報を参照してください。 # AWS WAF ラベルに一致するルールこのセクションでは、ラベル一致ステートメントを使用して、ウェブリクエストラベルを評価する方法について説明します。ラベル名が必要な *[Label]* (ラベル)、または名前空間の指定が必要な *[Namespace]* (名前空間) と照合できます。ラベルまたは名前空間のいずれの場合も、オプションで、前述の名前空間とプレフィックスを指定に含めることができます。このステートメントタイプの一般的な情報については、「[ラベル一致ルールステートメント](waf-rule-statement-type-label-match.md)」を参照してください。ラベルのプレフィクスは、ラベルのルールが定義されているルールグループまたは保護パック (ウェブ ACL) のコンテキストを定義します。ルールのラベル一致ステートメントで、ラベルまたは名前空間一致文字列でプレフィックスが指定されていない場合、はラベル一致ルールのプレフィックス AWS WAF を使用します。 + 保護パック (ウェブ ACL) 内で直接定義されたルールのラベルには、保護パック (ウェブ ACL) コンテキストを指定するプレフィックスが付いています。 + ルールグループ内にあるルールのラベルには、ルールグループコンテキストを指定するプレフィクスがあります。これは、独自のルールグループでも、マネージドルールグループでもかまいません。これについては、「[でのラベル構文と命名要件 AWS WAF](waf-rule-label-requirements.md)」のラベル構文を参照してください。 **注記** 一部のマネージドルールグループは、ラベルを追加します。`DescribeManagedRuleGroup` を呼び出すことにより、API を介してこれらを取得できます。ラベルは、応答の `AvailableLabels` プロパティにリストされています。ルールのコンテキストとは異なるコンテキストにあるルールと照合する場合は、一致文字列にプレフィックスを指定する必要があります。例えば、マネージドルールグループのルールによって追加されたラベルと照合する場合は、一致文字列でルールグループのプレフィクスとその後に追加の一致基準が指定されるラベル一致ステートメントを使用して、保護パック (ウェブ ACL) にルールを追加できます。ラベル一致ステートメントの一致文字列で、ラベルまたは名前空間のいずれかを指定します。 + **ラベル** – 一致のラベルの指定は、ラベルの終了部分で構成されます。ラベル名の直前に、連続するネームスペースをいくつでも含めて、その後に名前を含めることができます。指定の先頭をプレフィックスにして、完全修飾ラベルを指定することもできます。指定の例: + `testNS1:testNS2:LabelNameA` + `awswaf:managed:aws:managed-rule-set:testNS1:testNS2:LabelNameA` + **名前空間** – 一致の名前空間の指定は、名前を除くラベルの指定の連続するサブセットで構成されます。プレフィックスを含めることができ、1 つ以上の名前空間文字列を含めることができます。指定の例: + `testNS1:testNS2:` + `awswaf:managed:aws:managed-rule-set:testNS1:` # AWS WAF ラベル一致の例このセクションは、ラベル一致ルールステートメントの一致の指定の例を示します。 **注記** これらの JSON リストは、ラベル一致指定を使用して保護パック (ウェブ ACL) にルールを追加し、ルールを編集して **Rule JSON エディタ**に切り替えることでコンソールで作成されました。API またはコマンドラインインターフェイスを通じて、ルールグループまたは保護パック (ウェブ ACL) の JSON を取得することもできます。 **Topics** + [ ## ローカルラベルと照合する ](#waf-rule-label-match-examples-local-label) + [ ## 別のコンテキストのラベルと照合する ](#waf-rule-label-match-examples-label) + [ ## マネージドルールグループラベルと照合する ](#waf-rule-label-match-examples-mgd-rg-label) + [ ## ローカル名前空間と照合する ](#waf-rule-label-match-examples-local-namespace) + [ ## マネージドルールグループ名前空間と照合する ](#waf-rule-label-match-examples-mgd-rg-namespace) ## ローカルラベルと照合する次の JSON リストは、このルールと同じコンテキストで、ウェブリクエストにローカルに追加されたラベルのラベル一致ステートメントを示しています。 ``` Rule: { Name: "match_rule", Statement: { LabelMatchStatement: { Scope: "LABEL", Key: "header:encoding:utf8" } }, RuleLabels: [ ...generate_more_labels... ], Action: { Block: {} } } ``` アカウント 111122223333 でこの一致ステートメントを使用する場合、保護パック (ウェブ ACL) `testWebACL` のために定義するルールで、次のラベルと照合します。 ``` awswaf:111122223333:webacl:testWebACL:header:encoding:utf8 ``` ``` awswaf:111122223333:webacl:testWebACL:testNS1:testNS2:header:encoding:utf8 ``` ラベル文字列が完全に一致しないため、次のラベルには一致しません。 ``` awswaf:111122223333:webacl:testWebACL:header:encoding2:utf8 ``` コンテキストが同じではないため、次のラベルには一致せず、したがってプレフィックスは一致しません。これは、ルールが定義されている保護パック (ウェブ ACL) `testWebACL` にルールグループ `productionRules` を追加した場合であっても当てはまります。 ``` awswaf:111122223333:rulegroup:productionRules:header:encoding:utf8 ``` ## 別のコンテキストのラベルと照合する次の JSON リストは、ユーザーが作成したルールグループ内のルールのラベルと照合するラベル一致ルールを示しています。名前が挙げられるルールグループに属さない保護パック (ウェブ ACL) で実行されているすべてのルールの指定では、プレフィックスが必要です。このラベル指定の例では、正確なラベルのみと一致します。 ``` Rule: { Name: "match_rule", Statement: { LabelMatchStatement: { Scope: "LABEL", Key: "awswaf:111122223333:rulegroup:testRules:header:encoding:utf8" } }, RuleLabels: [ ...generate_more_labels... ], Action: { Block: {} } } ``` ## マネージドルールグループラベルと照合するこれは、一致ルールのコンテキストとは別のコンテキストからのラベルとの一致の特殊なケースです。次の JSON リストは、マネージドルールグループラベルのラベル一致ステートメントを示しています。これは、ラベル一致ステートメントのキー設定で指定された正確なラベルのみと一致します。 ``` Rule: { Name: "match_rule", Statement: { LabelMatchStatement: { Scope: "LABEL", Key: "awswaf:managed:aws:managed-rule-set:header:encoding:utf8" } }, RuleLabels: [ ...generate_more_labels... ], Action: { Block: {} } } ``` ## ローカル名前空間と照合する次の JSON リストは、ローカル名前空間のラベル一致ステートメントを示しています。 ``` Rule: { Name: "match_rule", Statement: { LabelMatchStatement: { Scope: "NAMESPACE", Key: "header:encoding:" } }, Labels: [ ...generate_more_labels... ], Action: { Block: {} } } ``` ローカル `Label` 一致と同様に、アカウント 111122223333 でこのステートメントを使用する場合、保護パック (ウェブ ACL) `testWebACL` のために定義するルールで、次のラベルと照合します。 ``` awswaf:111122223333:webacl:testWebACL:header:encoding:utf8 ``` アカウントが同じではないため、次のラベルには一致せず、したがってプレフィックスは一致しません。 ``` awswaf:444455556666:webacl:testWebACL:header:encoding:utf8 ``` プレフィックスは、次のようなマネージドルールグループによって適用されるラベルにも一致しません。 ``` awswaf:managed:aws:managed-rule-set:header:encoding:utf8 ``` ## マネージドルールグループ名前空間と照合する次の JSON リストは、マネージドルールグループ名前空間のラベル一致ステートメントを示しています。所有しているルールグループの場合、ルールのコンテキスト外にある名前空間と照合するために、プレフィックスを指定する必要もあります。 ``` Rule: { Name: "match_rule", Statement: { LabelMatchStatement: { Scope: "NAMESPACE", Key: "awswaf:managed:aws:managed-rule-set:header:" } }, RuleLabels: [ ...generate_more_labels... ], Action: { Block: {} } } ``` この指定は、次のサンプルラベルと照合します。 ``` awswaf:managed:aws:managed-rule-set:header:encoding:utf8 ``` ``` awswaf:managed:aws:managed-rule-set:header:encoding:unicode ``` 次のラベルとは一致しません。 ``` awswaf:managed:aws:managed-rule-set:query:badstring ``` # でのインテリジェントな脅威の軽減 AWS WAF このセクションでは、が提供するマネージド型のインテリジェントな脅威軽減機能について説明します AWS WAF。これらは、悪意のあるボットやアカウント乗っ取りの試みなどの脅威から保護するために実装できる、高度で特殊な保護機能です。 **注記** ここで説明する機能には、の使用の基本料金を超える追加コストが発生します AWS WAF。詳細については、[AWS WAF の料金](https://aws.amazon.com/waf/pricing/)を参照してください。このセクションで提供されるガイダンスは、 AWS WAF ウェブ ACLs、およびルールグループの作成と管理の一般的な方法を知っているユーザーを対象としています。これらのトピックは、このガイドの前のセクションでカバーされています。 **Topics** + [ # でのインテリジェントな脅威軽減のオプション AWS WAF ](waf-managed-protections-comparison-table.md) + [ # でのインテリジェントな脅威軽減のベストプラクティス AWS WAF ](waf-managed-protections-best-practices.md) + [ # AWS WAF インテリジェントな脅威の軽減におけるトークンの使用 ](waf-tokens.md) + [ # AWS WAF Fraud Control アカウント作成不正防止 (ACFP) ](waf-acfp.md) + [ # AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ](waf-atp.md) + [ # AWS WAF ボットコントロール ](waf-bot-control.md) + [ # AWS WAF 分散サービス拒否 (DDoS) の防止 ](waf-anti-ddos.md) + [ # でのクライアントアプリケーション統合 AWS WAF ](waf-application-integration.md) + [ # CAPTCHA および Challengeの AWS WAF ](waf-captcha-and-challenge.md) # でのインテリジェントな脅威軽減のオプション AWS WAF このセクションでは、インテリジェントな脅威の軽減を実装するためのオプションを詳細に比較します。 AWS WAF は、インテリジェントな脅威の軽減のために次のタイプの保護を提供します。 + **AWS WAF Fraud Control Account Creation Fraud Prevention (ACFP)** – アプリケーションのサインアップページで悪意のあるアカウント作成の試みを検出および管理します。コア機能は、ACFP マネージドルールグループによって提供されます。詳細については、「[AWS WAF Fraud Control アカウント作成不正防止 (ACFP)](waf-acfp.md)」および「[AWS WAF Fraud Control アカウント作成不正防止 (ACFP) ルールグループ](aws-managed-rule-groups-acfp.md)」を参照してください。 + **AWS WAF Fraud Control アカウント乗っ取り防止 (ATP)** – アプリケーションのログインページで悪意のある乗っ取りの試みを検出および管理します。コア機能は、ATP マネージドルールグループによって提供されます。詳細については、「[AWS WAF Fraud Control アカウント乗っ取り防止 (ATP)](waf-atp.md)」および「[AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループ](aws-managed-rule-groups-atp.md)」を参照してください。 + **AWS WAF Bot Control** – フレンドリボットと悪意のあるボットの両方を識別、ラベル付け、管理します。この機能により、アプリケーション間で一意のシグネチャを持つ一般的なボットや、アプリケーション固有のシグネチャを持つターゲットしたボットを管理できます。コア機能は、Bot Control マネージドルールグループによって提供されます。詳細については、「[AWS WAF ボットコントロール](waf-bot-control.md)」および「[AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md)」を参照してください。 + **クライアントアプリケーション統合 SDKs** – ウェブページでクライアントセッションとエンドユーザーを検証し、クライアントがウェブリクエストで使用する AWS WAF トークンを取得します。ACFP、ATP、または Bot Control を使用する場合、可能であればクライアントアプリケーションにアプリケーション統合 SDK を実装し、ルールグループのすべての機能を最大限に活用してください。重大なリソースを迅速に保護する必要があり、SDK 統合に十分な時間がないときにのみ、一時的な対策として SDK を統合せずにこれらのルールグループを使用することをお勧めします。SDK を実装する情報については、「[でのクライアントアプリケーション統合 AWS WAF](waf-application-integration.md)」を参照してください。 + **Challenge および CAPTCHAルールアクション** – クライアントセッションとエンドユーザーを検証し、クライアントがウェブリクエストで使用する AWS WAF トークンを取得します。これらは、ルールアクションを指定する任意の場所、ルール内、使用するルールグループのオーバーライドとして実装できます。これらのアクションは AWS WAF JavaScript インタースティシャルを使用してクライアントまたはエンドユーザーを調査し、JavaScript をサポートするクライアントアプリケーションを必要とします。詳細については、「[CAPTCHA および Challengeの AWS WAF](waf-captcha-and-challenge.md)」を参照してください。インテリジェントな脅威軽減 AWS マネージドルールルールグループは、ACFP、ATP、および Bot Control のトークンを使用して高度な検出を行います。トークンがルールグループで有効にする機能については、「[ACFP でのアプリケーション統合 SDK の使用](waf-acfp-with-tokens.md)」、「[ATP でアプリケーション統合 SDK を使用](waf-atp-with-tokens.md)」、「[Bot Control のアプリケーション統合 SDK の使用](waf-bot-with-tokens.md)」を参照してください。インテリジェントな脅威軽減を実装するためのオプションは、チャレンジを実行し、トークン取得を強制するルールアクションの基本的な使用から、インテリジェントな脅威軽減 AWS マネージドルールルールグループが提供する高度な機能まで多岐にわたります。次の表では、基本および高度な機能のオプションを詳細に比較します。 **Topics** + [ # チャレンジおよびトークン取得のオプション ](waf-managed-protections-comparison-table-token.md) + [ # インテリジェントな脅威を軽減するマネージドルールグループのオプション ](waf-managed-protections-comparison-table-rg.md) + [ # レートベースのルールとターゲットを絞った Bot Control ルールにおけるレート制限のオプション ](waf-rate-limiting-options.md) # チャレンジおよびトークン取得のオプションこのセクションでは、チャレンジ管理オプションとトークン管理オプションを比較します。 AWS WAF アプリケーション統合 SDKsまたはルールアクション Challengeおよびを使用して、チャレンジを提供し、トークンを取得できますCAPTCHA。大まかに言うと、ルールアクションは実装がより簡単ですが、追加コストが発生してカスタマーエクスペリエンスへの悪影響が大きくなり、JavaScript が必要になります。SDK はクライアントアプリケーションでプログラミングする必要がありますが、より優れたカスタマーエクスペリエンスを提供できます。さらに無料で使用できて JavaScript で使用、あるいは Android または iOS アプリケーションで使用できます。アプリケーション統合 SDK は、次のセクションで説明する有料のインテリジェント脅威軽減のマネージドルールグループをいずれか 1 つ使用する保護パック (ウェブ ACL) でのみ使用できます。 **チャレンジおよびトークン取得のオプション比較** | | Challenge ルールアクション | CAPTCHA ルールアクション | JavaScript SDK チャレンジ | モバイル SDK チャレンジ | | --- | --- | --- | --- | --- | | その内容とは | ブラウザクライアントにサイレントチャレンジインタースティシャルを提示することで AWS WAF トークンの取得を強制するルールアクション | クライアントエンドユーザーにビジュアルまたはオーディオチャレンジインタースティシャルを提示することで AWS WAF トークンの取得を強制するルールアクション | JavaScript を実行するクライアントブラウザおよびその他のデバイス向けのアプリケーション統合レイヤー。サイレントチャレンジをレンダリングし、トークンを取得します。 | Android および iOS アプリケーション向けのアプリケーション統合レイヤー。サイレントチャレンジをネイティブにレンダリングし、トークンを取得します | | こんなことにお勧めします | ボットセッションに対するサイレント検証および JavaScript をサポートするクライアントにトークン取得の強制 | JavaScript をサポートするクライアントに、ボットセッションに対するエンドユーザーおよびサイレント検証、ならびにトークン取得の強制 | ボットセッションに対するサイレント検証および JavaScript をサポートするクライアントにトークン取得の強制。SDK はレイテンシーを最小限に抑え、アプリケーション内で実行されるチャレンジスクリプトの場所を最適に制御します。 | ボットセッションに対するサイレント検証および Android iOS のネイティブモバイルアプリケーションにトークン取得の強制。SDK はレイテンシーを最小限に抑え、アプリケーション内で実行されるチャレンジスクリプトの場所を最適に制御します。 | | 実装の考慮事項 | ルールアクション設定として実装済 | ルールアクション設定として実装済 | 保護パック (ウェブ ACL) の ACFP、ATP、または Bot Control の有料ルールグループの 1 つが必要です。クライアントアプリケーションでのコーディングが必要です。 | 保護パック (ウェブ ACL) の ACFP、ATP、または Bot Control の有料ルールグループの 1 つが必要です。クライアントアプリケーションでのコーディングが必要です。 | | ランタイムの考慮事項 | 有効なトークンがないリクエストの侵入的なフロー。クライアントは AWS WAF チャレンジインタースティシャルにリダイレクトされます。ネットワークラウンドトリップを追加し、ウェブリクエストの 2 次評価が必要とします。 | 有効なトークンがないリクエストの侵入的なフロー。クライアントは AWS WAF CAPTCHA インタースティシャルにリダイレクトされます。ネットワークラウンドトリップを追加し、ウェブリクエストの 2 次評価が必要とします。 | 舞台裏で実行できます。チャレンジ体験をより広範囲に制御できます。 | 舞台裏で実行できます。チャレンジ体験をより広範囲に制御できます。 | | JavaScript が必要 | はい | はい | あり | なし | | サポートされているクライアント | Javascript を実行するブラウザおよびデバイス | Javascript を実行するブラウザおよびデバイス | Javascript を実行するブラウザおよびデバイス | Android および iOS デバイス | | 単一ページアプリケーション (SPA) をサポート | 強制適用のみ。Challenge アクションを SDK と組み合わせて使用することで、リクエストが有効なチャレンジトークンを確実に持つようにできます。このルールアクションを使用してチャレンジスクリプトをページに配信することはできません。 | 強制適用のみ。CAPTCHA アクションを SDK と組み合わせて使用することで、リクエストが有効な CAPTCHA トークンを確実に持つようにできます。このルールアクションを使用して CAPTCHA スクリプトをページに配信することはできません。 | はい | 該当なし | | 追加料金 | はい。定義したルールまたは使用するルールグループのルールアクションのオーバーライドとして明示的に指定するアクション設定に適用されます。それ以外の場合は、いいえ。 | はい。定義したルールまたは使用するルールグループのルールアクションのオーバーライドとして明示的に指定するアクション設定に適用されます。それ以外の場合は、いいえ。 | いいえ。ただし、ACFP、ATP、または Bot Control のいずれかの有料ルールグループが必要です。 | いいえ。ただし、ACFP、ATP、または Bot Control のいずれかの有料ルールグループが必要です。 | これらのオプションに関連するコストの詳細については、「[AWS WAF の料金表](https://aws.amazon.com/waf/pricing/)」のインテリジェントな脅威の軽減情報を参照してください。 Challenge または CAPTCHA アクションを含むルールを追加するだけで、チャレンジを実行して基本的なトークンの強制がより簡単にできます。アプリケーションコードにアクセスできない場合など、ルールアクションの使用が必要になる場合があります。ただし、SDK を実装できれば、Challenge アクションを使用する場合と比較し、クライアントのウェブリクエストの保護パック (ウェブ ACL) 評価におけるコストを節約し、レイテンシーを低減できます。 + アプリケーションの任意の時点でチャレンジを実行するように SDK 実装を記述できます。保護されたリソースにウェブリクエストを送信するカスタマーアクションの前、トークンをバックグラウンドで取得できます。これにより、クライアントの最初のリクエストでトークンを送信できるようになります。 + 代わりに、Challenge アクションを含むルールを実装してトークンを取得する場合、クライアントが最初にリクエストを送信、ならびにトークンの有効期限が切れるとき、ルールおよびアクションに追加のウェブリクエスト評価と処理が必要になります。Challenge アクションは、有効期限が切れていない有効なトークンがないリクエストをブロックし、チャレンジインタースティシャルをクライアントに送り返します。クライアントがチャレンジの応答に成功した後、インタースティシャルは元のウェブリクエストを有効なトークンで再送信し、そのトークンが保護パック (ウェブ ACL) によって再度評価されます。 # インテリジェントな脅威を軽減するマネージドルールグループのオプションこのセクションでは、マネージドルールグループのオプションを比較します。インテリジェントな脅威軽減 AWS マネージドルールルールグループは、基本的なボットの管理、高度な悪意のあるボットの検出と緩和、アカウント乗っ取りの試みの検出と緩和、不正なアカウント作成の試みの検出と緩和を提供します。これらのルールグループは、前のセクションで説明したアプリケーション統合 SDK と組み合わせると、最も高度な保護およびクライアントアプリケーションとの安全な連携が可能になります。 **マネージドルールのグループオプションの比較** | | ACFP | ATP | Bot Control の共通レベル | Bot Control の目標レベル | | --- | --- | --- | --- | --- | | その内容とは | アプリケーションの登録ページおよびサインアップページでのアカウントの不正な作成の試みの一環である可能性のあるリクエストを管理します。ボットを管理しません。「[AWS WAF Fraud Control アカウント作成不正防止 (ACFP) ルールグループ](aws-managed-rule-groups-acfp.md)」を参照してください。 | アプリケーションのログインページで、悪意のある乗っ取りの試みの一部である可能性があるリクエストを管理します。ボットを管理しません。「[AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループ](aws-managed-rule-groups-atp.md)」を参照してください。 | アプリケーション間で一意のシグネチャで自己識別を行う一般的なボットを管理します。「[AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md)」を参照してください。 | アプリケーション固有のシグネチャで自己識別を行わないターゲットしたボットを管理します。「[AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md)」を参照してください。 | | こんなことにお勧めします | ユーザー名トラバーサルによる作成の試みや、単一の IP アドレスから作成された多数の新しいアカウントなど、不正なアカウント作成攻撃がないかを確認するための、アカウント作成トラフィックの検査。 | パスワードトラバーサルによるログイン試行や同じ IP アドレスから多数のログイン試行など、アカウント乗っ取り攻撃におけるログイントラフィックの検査。トークンと併用すると、大量の失敗したログイン試行の IP およびクライアントセッションにおけるレート制限などの総合的な保護も提供されます。 | 一般的な自動ボットトラフィックの基本的なボット保護およびラベル付け。 | クライアントセッションレベルでのレート制限、ならびに Selenium や Puppeteer などのブラウザ自動化ツールの検出と軽減を含め、高度なボットに対するターゲットを絞った保護。 | | 評価結果を示すラベルを追加します | はい | はい | はい | はい | | トークンラベルを追加します | はい | はい | はい | はい | | 有効なトークンがないリクエストのブロック | 含まれません。「[有効な AWS WAF トークンを持たないリクエストのブロック](waf-tokens-block-missing-tokens.md)」を参照してください。 | 含まれません。「[有効な AWS WAF トークンを持たないリクエストのブロック](waf-tokens-block-missing-tokens.md)」を参照してください。 | 含まれません。「[有効な AWS WAF トークンを持たないリクエストのブロック](waf-tokens-block-missing-tokens.md)」を参照してください。 | トークンなしで 5 回のリクエストを送信するクライアントセッションをブロックします。 | | AWS WAF トークンが必要です aws-waf-token | すべてのルールで必須です。「[ACFP でのアプリケーション統合 SDK の使用](waf-acfp-with-tokens.md)」を参照してください。 | 多くのルールに必要です。「[ATP でアプリケーション統合 SDK を使用](waf-atp-with-tokens.md)」を参照してください。 | いいえ | はい | | AWS WAF トークンを取得します。 aws-waf-token | はい。ルール AllRequests によって強制されます | いいえ | いいえ | トークンを取得する Challenge または CAPTCHA ルールアクションを使用するルールがあります。 | これらのオプションに関連するコストの詳細については、「[AWS WAF の料金表](https://aws.amazon.com/waf/pricing/)」のインテリジェントな脅威の軽減情報を参照してください。 # レートベースのルールとターゲットを絞った Bot Control ルールにおけるレート制限のオプションこのセクションでは、レートベースの緩和オプションを比較します。 AWS WAF Bot Control ルールグループのターゲットレベルと AWS WAF レートベースのルールステートメントの両方がウェブリクエストレート制限を提供します。以下の表は、これら 2 つのオプションを比較したものです。 **レートベースの検出と緩和のためのオプションの比較** | | AWS WAF レートベースのルール | AWS WAF Bot Control のターゲットルール | | --- | --- | --- | | レート制限の適用方法 | レートが高すぎるリクエストのグループに対して動作します。Allow 以外のアクションを適用できます。 | リクエストトークンの使用を通じて、人間のようなアクセスパターンを実施し、動的なレート制限を適用します。 | | 履歴的なトラフィックベースラインに基づく | いいえ | はい | | 履歴的なトラフィックベースラインを蓄積するために要する時間 | 該当なし | 動的しきい値の場合は 5 分。トークンがない場合は該当なし。 | | 軽減までの時間差 | 通常は 30～50 秒。最大で数分かかる場合もあります。 | 通常は 10 秒未満。最大で数分かかる場合もあります。 | | 緩和の対象 | 設定可能です。スコープダウンステートメントと、IP アドレス、HTTP メソッド、クエリ文字列などの 1 つ以上の集約キーを使用してリクエストをグループ化できます。 | IP アドレスとクライアントセッション | | 緩和をトリガーするために必要なトラフィック量のレベル | 中 – 指定された時間枠で 10 リクエストまで設定できます | 低 – 低速なスクレイパーなどのクライアントパターンを検出するためのもの | | カスタマイズ可能なしきい値 | はい | なし | | デフォルトの緩和アクション | コンソールのデフォルトは Block です。API にデフォルト設定はなく、設定が必要です。これは、Allow 以外の任意の有効なルールアクションに設定できます。 | ルールグループのルールアクション設定は、トークンがない場合には Challenge、単一のクライアントセッションからの大量のトラフィックの場合には CAPTCHA になります。これらのルールのいずれかを、任意の有効なルールアクションに設定できます。 | | 高度に分散された攻撃に対する耐久性 | 中 – 単独で IP アドレスを制限する場合は最大 10,000 の IP アドレス | 中程度 – IP アドレスとトークン間の合計で 50,000 個に制限されます | | [AWS WAF 料金](https://aws.amazon.com/waf/pricing/) | の標準料金に含まれています AWS WAF。 | Bot Control のインテリジェントな脅威軽減のターゲットレベル料金に含まれています。 | | 詳細情報 | [でのレートベースのルールステートメントの使用 AWS WAF](waf-rule-statement-type-rate-based.md) | [AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md) | # でのインテリジェントな脅威軽減のベストプラクティス AWS WAF インテリジェントな脅威の軽減機能の最も効果的でコスト効率性に優れた実装については、このセクションのベストプラクティスに従ってください。 + **JavaScript とモバイルアプリケーション統合 SDK を実装する** – アプリケーション統合を実装して、可能な限り最も効果的な方法で ACFP、ATP、または Bot Control 機能のすべて有効にします。マネージドルールグループは、SDK が提供するトークンを使用して、セッションレベルで正規のクライアントトラフィックを望ましくないトラフィックから分離させます。アプリケーション統合 SDK は、これらのトークンが常に利用可能であることを確実にします。詳細については、以下を参照してください。 + [ACFP でのアプリケーション統合 SDK の使用](waf-acfp-with-tokens.md) + [ATP でアプリケーション統合 SDK を使用](waf-atp-with-tokens.md) + [Bot Control のアプリケーション統合 SDK の使用](waf-bot-with-tokens.md) クライアントにチャレンジを実装したり、JavaScript の場合は CAPTCHA パズルがエンドユーザーに提示される方法をカスタマイズしたりするために、統合を使用します。詳細については、「[でのクライアントアプリケーション統合 AWS WAF](waf-application-integration.md)」を参照してください。 JavaScript API を使用して CAPTCHA パズルをカスタマイズし、保護パック (ウェブ ACL) の任意の場所でCAPTCHAルールアクションを使用する場合は、のクライアントで AWS WAF CAPTCHA レスポンスを処理するためのガイダンスに従ってください[からの CAPTCHA レスポンスの処理 AWS WAF](waf-js-captcha-api-conditional.md)。このガイダンスは、ACFP マネージドルールグループや Bot Control マネージドルールグループのターゲットを絞った保護レベルなど、CAPTCHA アクションを使用するすべてのルールに適用されます。 + **ACFP、ATP、Bot Control ルールグループに送信するリクエストを制限する** – インテリジェントな脅威軽減 AWS マネージドルールルールグループの使用には追加料金が発生します。ACFP ルールグループは、指定したアカウント登録エンドポイントと作成エンドポイントに対するリクエストを検査します。ATP ルールグループは、指定したログインエンドポイントに対するリクエストを検査します。Bot Control ルールグループは、保護パック (ウェブ ACL) 評価で、到達するすべてのリクエストを検査します。これらのルールグループの使用を減らすため、以下のアプローチを検討してください。 + マネージドルールグループステートメント内のスコープダウンステートメントを使用して、検査からリクエストを除外します。これは、ネスト可能なステートメントならどれでも実行できます。詳細については、「[でのスコープダウンステートメントの使用 AWS WAF](waf-rule-scope-down-statements.md)」を参照してください。 + ルールグループの前にルールを追加することで、検査からリクエストを除外します。スコープダウンステートメントで使用できないルール、およびラベル付けの後にラベルの照合が行われるような複雑な状況については、ルールグループの前に実行されるルールを追加する必要があるかもしれません。詳細については、「[でのスコープダウンステートメントの使用 AWS WAF](waf-rule-scope-down-statements.md)」および「[でのルールステートメントの使用 AWS WAF](waf-rule-statements.md)」を参照してください。 + 低料金のルールを実行してからルールグループを実行します。何らかの理由でリクエストをブロックする他の標準 AWS WAF ルールがある場合は、これらの有料ルールグループの前に実行します。ルールとルール管理の詳細については、「[でのルールステートメントの使用 AWS WAF](waf-rule-statements.md)」を参照してください。 + インテリジェントな脅威の軽減のためのマネージドルールグループを複数使用している場合は、Bot Control、ATP、ACFP の順に実行すると、コストを抑えることができます。料金の詳細については、「[AWS WAF の料金表](https://aws.amazon.com/waf/pricing/)」を参照してください。 + **DDoS 対策ルールグループに送信するリクエストを制限しない** – このルールグループは、明示的に許可していないすべてのウェブトラフィックをモニタリングするように設定する場合に最適です。ウェブ ACL に配置して、Allow ルールアクションを持つルールの後、および他のすべてのルールの前にのみ評価されるようにします。 + **分散型サービス拒否 (DDoS) の保護では、DDoS 対策または Shield Advanced のアプリケーションレイヤー DDoS 自動緩和を使用する** – 他のインテリジェントな脅威の軽減ルールグループは DDoS 保護を提供しません。ACFP は、アプリケーションのサインアップページに対するアカウントの不正な作成の試みから保護します。ATP は、ログインページに対するアカウント乗っ取りの試みを防ぎます。Bot Control は、トークンとクライアントセッションに対する動的なレート制限を使用して、人間のようなアクセスパターンを実施することに重点を置いています。 DDoS 対策を使用すると、DDoS 攻撃をモニタリングおよび制御できるため、脅威に迅速に対応して軽減できます。自動アプリケーションレイヤー DDoS 緩和を備えた Shield Advanced は、ユーザーに代わってカスタム AWS WAF 緩和を作成、評価、デプロイすることで、検出された DDoS 攻撃に自動的に応答します。 Shield Advanced の詳細については、「[AWS Shield Advanced の概要](ddos-advanced-summary.md)」および「[AWS Shield Advanced およびを使用したアプリケーションレイヤー (レイヤー 7) の保護 AWS WAF](ddos-app-layer-protections.md)」を参照してください。分散型サービス拒否 (DDoS) の防止の詳細については、「[DDoS 対策ルールグループ](aws-managed-rule-groups-anti-ddos.md)」および「[分散型サービス拒否 (DDoS) の防止](waf-anti-ddos.md)」を参照してください。 + **通常のウェブトラフィック中に DDoS 対策ルールグループと Bot Control ルールグループのターゲットを絞った保護レベルを有効にする** – これらのルールカテゴリには、通常のトラフィックのベースラインを確立する時間が必要です。 **通常のウェブトラフィック中に Bot Control ルールグループのターゲットを絞った保護レベルを有効にする** – ターゲットを絞った保護レベルのルールの一部では、通常のトラフィックパターンのベースラインを確立してからでないと、不規則なトラフィックパターンや悪意のあるトラフィックパターンに対する認識と対応が行えません。例えば、`TGT_ML_*` ルールのウォームアップには最大 24 時間かかります。攻撃を受けていないときにこれらの保護を追加し、ルールが適切に対応することを期待する前に、トラフィックパターンのベースラインを確立するための猶予時間を与えます。攻撃中にこれらのルールを追加する場合は、カウントモードで DDoS 対策ルールグループを有効にする必要があります。攻撃が収まった後、ベースラインを確立するまでにかかる時間は通常の 2 倍から 3 倍になります。これは、攻撃トラフィックによって歪みが生じるためです。ルールとルールのウォームアップに必要な時間に関する詳細については、「[ルールの一覧](aws-managed-rule-groups-bot.md#aws-managed-rule-groups-bot-rules)」を参照してください。 + **分散型サービス拒否 (DDoS) からの保護には、Shield Advanced のアプリケーションレイヤー DDoS 自動緩和を使用する** – インテリジェントな脅威の軽減ルールグループは DDoS 保護を提供しません。ACFP は、アプリケーションのサインアップページに対するアカウントの不正な作成の試みから保護します。ATP は、ログインページに対するアカウント乗っ取りの試みを防ぎます。Bot Control は、トークンとクライアントセッションに対する動的なレート制限を使用して、人間のようなアクセスパターンを実施することに重点を置いています。自動アプリケーションレイヤー DDoS 緩和を有効にして Shield Advanced を使用すると、Shield Advanced はユーザーに代わってカスタム AWS WAF 緩和を作成、評価、デプロイすることで、検出された DDoS 攻撃に自動的に応答します。Shield Advanced の詳細については、「[AWS Shield Advanced の概要](ddos-advanced-summary.md)」および「[AWS Shield Advanced およびを使用したアプリケーションレイヤー (レイヤー 7) の保護 AWS WAF](ddos-app-layer-protections.md)」を参照してください。 + **DDoS 対策ルールグループのベースラインを確立するときに本番トラフィック負荷を使用する** – 人工テストトラフィックを使用して他のルールグループをテストするのが一般的です。ただし、DDoS 対策ルールグループのベースラインをテストして確立する場合は、本番環境の負荷を反映するトラフィックフローを使用することをお勧めします。一般的なトラフィックを使用して DDoS 対策ベースラインを確立することは、ルールグループが本番環境で有効になっているときにリソースを保護する最善の方法です。 + **トークン処理を調整および設定する** – 最高のユーザーエクスペリエンスが得られるように、保護パック (ウェブ ACL) のトークン処理を調整します。 + 運用コストを削減し、エンドユーザーエクスペリエンスを改善するには、トークン管理のイミュニティ時間をセキュリティ要件が許容する最大時間に調整します。これにより、CAPTCHA パズルやサイレントチャレンジの使用を最小限に抑えることができます。詳細については、「[でのタイムスタンプの有効期限とトークンイミュニティ時間の設定 AWS WAF](waf-tokens-immunity-times.md)」を参照してください。 + 保護されたアプリケーション間でトークン共有を有効にするには、保護パック (ウェブ ACL) のトークンドメインリストを設定します。詳細については、「[でのトークンドメインとドメインリストの指定 AWS WAF](waf-tokens-domains.md)」を参照してください。 + **任意のホスト仕様を持つリクエストを拒否する** – ウェブリクエストの `Host` ヘッダーがターゲットリソースに一致することを必須とするように保護対象リソースを設定します。ホストについて、1 つの値、または特定の値セット (`myExampleHost.com` および `www.myExampleHost.com` など) を受け入れることはできますが、任意の値は受け入れないでください。 + **CloudFront ディストリビューションのオリジンである Application Load Balancer の場合、適切なトークン処理 AWS WAF のために CloudFront とを設定します** – 保護パック (ウェブ ACL) を Application Load Balancer に関連付け、Application Load Balancer を CloudFront ディストリビューションのオリジンとしてデプロイする場合は、「」を参照してください[CloudFront からの Application Load Balancers に必要な設定](waf-tokens-with-alb-and-cf.md)。 + **デプロイ前にテストして調整する** – 保護パック (ウェブ ACL) に変更を実装する前に、本ガイドのテストおよび調整手順に従って、期待通りの動作が得られることを確認してください。これらの有料機能を使用する場合は特に重要です。一般的なガイダンスについては、「[AWS WAF 保護のテストとチューニング](web-acl-testing.md)」を参照してください。有料マネージドルールグループ固有の情報については、「[ACFP のテストとデプロイ](waf-acfp-deploying.md)」、「[ATP のテストとデプロイ](waf-atp-deploying.md)」、「[AWS WAF Bot Control のテストとデプロイ](waf-bot-control-deploying.md)」を参照してください。 # AWS WAF インテリジェントな脅威の軽減におけるトークンの使用このセクションでは、 AWS WAF トークンの動作について説明します。 AWS WAF トークンは、 AWS WAF インテリジェントな脅威の軽減によって提供される強化された保護の不可欠な部分です。トークンは、フィンガープリントとも呼ばれ、クライアントが保存し、送信するすべてのウェブリクエストに提供する単一のクライアントセッションに関する情報のコレクションです。はトークン AWS WAF を使用して、悪意のあるクライアントセッションを 1 つの IP アドレスから発信した場合でも、正当なセッションから識別して分離します。トークンの使用によるコストは、正規ユーザーにとってはごくわずかですが、ボットネットにとってはかなり高額になります。 AWS WAF はトークンを使用して、アプリケーション統合 SDKs とルールアクション Challengeおよびによって提供されるブラウザおよびエンドユーザーチャレンジ機能をサポートしますCAPTCHA。さらに、トークンは AWS WAF Bot Control とアカウント乗っ取り防止マネージドルールグループの機能を有効にします。 AWS WAF は、サイレントチャレンジや CAPTCHA パズルに正常に応答するクライアントのトークンを作成、更新、暗号化します。トークンを持つクライアントがウェブリクエストを送信すると、暗号化されたトークンが含まれ、トークンを AWS WAF 復号してその内容を検証します。 **Topics** + [ # がトークン AWS WAF を使用する方法 ](waf-tokens-usage.md) + [ # AWS WAF トークンの特性 ](waf-tokens-details.md) + [ # でのタイムスタンプの有効期限とトークンイミュニティ時間の設定 AWS WAF ](waf-tokens-immunity-times.md) + [ # でのトークンドメインとドメインリストの指定 AWS WAF ](waf-tokens-domains.md) + [ # のトークンラベルのタイプ AWS WAF ](waf-tokens-labeling.md) + [ # 有効な AWS WAF トークンを持たないリクエストのブロック ](waf-tokens-block-missing-tokens.md) + [ # CloudFront からの Application Load Balancers に必要な設定 ](waf-tokens-with-alb-and-cf.md) # がトークン AWS WAF を使用する方法このセクションでは、がトークン AWS WAF を使用する方法について説明します。 AWS WAF はトークンを使用して、次のタイプのクライアントセッション検証を記録および検証します。 + **CAPTCHA** — CAPTCHA パズルは、ボットと人間のユーザーを区別するうえで役立ちます。CAPTCHA は CAPTCHA ルールアクションによってのみ実行されます。パズルの完了が成功すると、CAPTCHA スクリプトはトークンの CAPTCHA タイムスタンプを更新します。詳細については、「[CAPTCHA および Challengeの AWS WAF](waf-captcha-and-challenge.md)」を参照してください。 + **チャレンジ** — 通常のクライアントセッションとボットセッションを区別しやすくし、ボットの運用コストを高めるために、チャレンジはサイレントで実行されます。チャレンジが正常に完了すると、チャレンジスクリプトは AWS WAF 必要に応じてから新しいトークンを自動的に取得し、トークンのチャレンジタイムスタンプを更新します。 AWS WAF は、次の状況でチャレンジを実行します。 + **アプリケーション統合 SDK** — アプリケーション統合 SDK は、クライアントアプリケーションセッション内で実行され、クライアントがチャレンジの応答に成功した後にのみログイン試行が許可されるようにします。詳細については、「[でのクライアントアプリケーション統合 AWS WAF](waf-application-integration.md)」を参照してください。 + **Challenge ルールアクション** – 詳細については、「[CAPTCHA および Challengeの AWS WAF](waf-captcha-and-challenge.md)」を参照してください。 + **CAPTCHA** — CAPTCHA インタースティシャルを実行するときにクライアントがまだトークンを持っていない場合、スクリプトは最初に自動的にチャレンジを実行し、クライアントセッションを検証してトークンを初期化します。トークンは、インテリジェントな脅威の AWS Managed Rules ルールグループの多くのルールで必要です。このルールは、セッションレベルでのクライアントの区別、ブラウザの特性の判断、アプリケーションウェブページにおける人間のインタラクティビティのレベルの理解などを行うためにトークンを使用します。これらのルールグループは AWS WAF トークン管理を呼び出し、ルールグループが検査するトークンのラベル付けを適用します。 + **AWS WAF Fraud Control Account Creation Fraud Prevention (ACFP)** – ACFP ルールには、有効なトークンを含むウェブリクエストが必要です。ルールの詳細については、「[AWS WAF Fraud Control アカウント作成不正防止 (ACFP) ルールグループ](aws-managed-rule-groups-acfp.md)」を参照してください。 + **AWS WAF Fraud Control アカウント乗っ取り防止 (ATP)** – 大量のクライアントセッションや長時間のクライアントセッションを防ぐ ATP ルールには、有効期限が切れていないチャレンジタイムスタンプを持つ有効なトークンを持つウェブリクエストが必要です。詳細については、「[AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループ](aws-managed-rule-groups-atp.md)」を参照してください。 + **AWS WAF Bot Control** – このルールグループのターゲットルールは、有効なトークンなしでクライアントが送信できるウェブリクエストの数を制限し、セッションレベルのモニタリングと管理にトークンセッション追跡を使用します。必要に応じて、ルールは Challenge および CAPTCHA ルールアクションを適用して、トークン取得および有効なクライアント動作を強制します。詳細については、「[AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md)」を参照してください。 # AWS WAF トークンの特性各トークンには次の特徴があります。 + トークンは、`aws-waf-token` という名前のクッキーに保存されます。 + トークンは暗号化されます。 + トークンは、次の情報を含む精度の高い識別子でクライアントセッションをフィンガープリントします。 + クライアントがサイレントチャレンジに対して最後に成功した応答のタイムスタンプ。 + エンドユーザーが CAPTCHA に対して最後に成功した応答のタイムスタンプ。これは保護機能で CAPTCHA を使用している場合にのみ表示されます。 + 正規のクライアントを迷惑なトラフィックから切り離すうえで役立つクライアントおよびクライアント行動に関する追加情報。この情報には、自動化されたアクティビティを検出するために使用可能なさまざまなクライアント識別子およびクライアント側の信号が含まれます。収集される情報は一意ではなく、個別の人間を特定することはできません。 + すべてのトークンには、オートメーションやブラウザ設定の不整合を示唆する要素など、クライアントブラウザの問い合わせから得られたデータが含まれています。この情報は、Challenge アクションによって実行されるスクリプトおよびクライアントアプリケーション SDK によって取得されます。スクリプトはブラウザに積極的に問い合わせて、結果をトークンに含めます。 + さらに、クライアントアプリケーション統合 SDK を実装すると、トークンには、アプリケーションページとのエンドユーザーのインタラクティビティについて受動的に収集された情報が含まれます。インタラクティビティには、マウスの動き、キーの押下、およびページ上に存在する HTML フォームとのインタラクションが含まれます。この情報は、 AWS WAF がクライアントにおける人間のインタラクティビティのレベルを検出し、人間ではないように見えるユーザーにチャレンジを提示するのに役立ちます。クライアント側の統合については、「[でのクライアントアプリケーション統合 AWS WAF](waf-application-integration.md)」を参照してください。セキュリティ上の理由から、 AWS トークンの内容の完全な説明や AWS WAF トークン暗号化プロセスに関する詳細情報は提供しません。 # でのタイムスタンプの有効期限とトークンイミュニティ時間の設定 AWS WAF このセクションでは、チャレンジと CAPTCHA タイムスタンプの有効期限について説明します。 AWS WAF はチャレンジと CAPTCHA イミュニティ時間を使用して、1 つのクライアントセッションにチャレンジまたは CAPTCHA を提示できる頻度を制御します。エンドユーザーが CAPTCHA に応答に成功した後、そのエンドユーザーに対して別の CAPTCHA が表示されない期間は、CAPTCHA イミュニティ時間によって決まります。同様に、チャレンジのイミュニティ時間は、チャレンジへの応答に成功した後、クライアントセッションが再度チャレンジを受けない期間を決定します。 ** AWS WAF トークンイミュニティ時間の仕組み** AWS WAF は、トークン内の対応するタイムスタンプを更新することで、チャレンジまたは CAPTCHA への正常な応答を記録します。がトークンにチャレンジまたは CAPTCHA がないか AWS WAF 検査すると、現在の時刻からタイムスタンプが減算されます。結果が設定されたイミュニティ時間よりも大きい場合、タイムスタンプは期限切れになります。 ** AWS WAF トークンイミュニティ時間の設定可能な側面** チャレンジおよび CAPTCHA のイミュニティ時間は、保護パック (ウェブ ACL) および CAPTCHA または Challenge ルールアクションを使用する任意のルールで設定できます。 + 両方のイミュニティ時間におけるデフォルトの保護パック (ウェブ ACL) 設定は 300 秒です。 + CAPTCHA または Challenge アクションを使用するすべてのルールにイミュニティ時間を指定できます。ルールにイミュニティ時間を指定しない場合、保護パック (ウェブ ACL) の設定が継承されます。 + CAPTCHA または Challenge アクションを使用するルールグループ内のルールには、ルールのイミュニティ時間を定義しない場合、ルールグループを使用する各保護パック (ウェブ ACL) から設定が継承されます。 + アプリケーション統合 SDK は、保護パック (ウェブ ACL) のチャレンジイミュニティ時間を使用します。 + チャレンジイミュニティ時間の最小値は 300 秒です。CAPTCHA イミュニティ時間の最小値は 60 秒です。両方のイミュニティ時間の最大値は 259,200 秒、または 3 日間です。保護パック (ウェブ ACL) およびルールレベルのイミュニティ時間設定を使用して、CAPTCHA アクション、Challenge、SDK チャレンジ管理の動作を調整できます。たとえば、機密性の高いデータへのアクセスを制御するルールを低いイミュニティ時間で設定し、その後に保護パック (ウェブ ACL) 内で他のルールや SDK が承継するより高いイミュニティ時間を設定できます。特に CAPTCHA の場合、パズルを解くことは顧客のウェブサイトエクスペリエンスを低下させる恐れがあるため、CAPTCHA のイミュニティ時間を調整すると必要な保護を提供し続けながら、顧客エクスペリエンスへの影響を軽減することに役立ちます。 Challenge および CAPTCHA ルールアクションを使用する際にイミュニティ時間の調整に関する詳細については、「[CAPTCHA および Challenge アクションを使用するベストプラクティス](waf-captcha-and-challenge-best-practices.md)」を参照してください。 # AWS WAF トークンのイミュニティ時間を設定する場所イミュニティ時間は、保護パック (ウェブ ACL) および Challenge や CAPTCHA ルールアクションを使用するルールで設定できます。保護パック (ウェブ ACL) およびそのルールの管理に関する一般情報については、「[でのウェブトラフィックメトリクスの表示 AWS WAF](web-acl-working-with.md)」を参照してください。 **保護パック (ウェブ ACL) のイミュニティ時間を設定する場所** + **コンソール** — 保護パック (ウェブ ACL) を編集するとき、**[Rules]** (ルール) タブで、**[保護パック (ウェブ ACL) の CAPTCHA 設定]** および **[保護パック (ウェブ ACL) のチャレンジ設定]** ペインの設定を編集して変更します。コンソールでは、保護パック (ウェブ ACL) を作成した後にのみ、保護パック (ウェブ ACL) の CAPTCHA およびチャレンジのイミュニティ時間を設定できます。 + **コンソールの外部** – 保護パック (ウェブ ACL) のデータタイプには CAPTCHA およびチャレンジの設定パラメータがあり、保護パック (ウェブ ACL) の作成および更新操作に設定して提供できます。 **ルールのイミュニティ時間を設定する場所** + **コンソール** – ルールを作成または編集して CAPTCHA または Challenge アクションを指定すると、ルールのイミュニティ時間設定を変更できます。 + **コンソールの外部** – ルールのデータタイプには CAPTCHA およびチャレンジの設定パラメータがあり、ルールを定義するときに設定できます。 # でのトークンドメインとドメインリストの指定 AWS WAF このセクションでは、がトークンで AWS WAF 使用し、がトークンで受け入れるドメインを設定する方法について説明します。がクライアントのトークン AWS WAF を作成すると、トークンドメインで設定されます。 AWS WAF がウェブリクエスト内のトークンを検査するとき、そのドメインが保護パック (ウェブ ACL) で有効と見なされるドメインと一切一致しない場合、そのトークンは無効として拒否されます。デフォルトでは、は、ドメイン設定が保護パック (ウェブ ACL) に関連付けられているリソースのホストドメインと完全に一致するトークン AWS WAF のみを受け入れます。これはウェブリクエスト内の `Host` ヘッダーの値です。ブラウザでは、このドメインは JavaScript `window.location.hostname` プロパティ、ならびにユーザーのアドレスバーに表示されるアドレスに含まれます。次のセクションで説明するように、保護パック (ウェブ ACL) 設定で許容されるトークンドメインを指定することもできます。この場合、はホストヘッダーと完全一致とトークンドメインリストのドメインの両方 AWS WAF を受け入れます。ドメインを設定するとき AWS WAF 、および保護パック (ウェブ ACL) でトークンを評価するときに使用するのトークンドメインを指定できます。指定するドメインには `gov.au` など、パブリックサフィックスを使用できません。使用できないドメインについては、「[パブリックサフィックスリスト](https://publicsuffix.org/list/)」のリスト ([https://publicsuffix.org/list/public_suffix_list.dat](https://publicsuffix.org/list/public_suffix_list.dat)) を参照してください。 ## AWS WAF 保護パック (ウェブ ACL) トークンドメインリスト設定トークンドメインリストに AWS WAF 受け入れる追加のドメインを指定することで、複数の保護されたリソース間でトークンを共有するように保護パック (ウェブ ACL) を設定できます。トークンドメインリストを使用して、 AWS WAF はリソースのホストドメインを受け入れます。さらに、プレフィックス付きのサブドメインを含め、トークンドメインリスト内のすべてのドメインを受け入れます。たとえば、トークンドメインリスト内のドメイン仕様 `example.com` は `example.com` (`http://example.com/` から)、`api.example.com` (`http://api.example.com/` から)、`www.example.com` (`http://www.example.com/` から) と一致します。`example.api.com` (`http://example.api.com/` から) または `apiexample.com` (`http://apiexample.com/` から) と一致しません。トークンドメインリストは、作成または編集するときに保護パック (ウェブ ACL) で設定できます。保護パック (ウェブ ACL) の管理に関する一般情報については、「[でのウェブトラフィックメトリクスの表示 AWS WAF](web-acl-working-with.md)」を参照してください。 ## AWS WAF トークンドメイン設定 AWS WAF は、アプリケーション統合 SDKs と Challengeおよび CAPTCHAルールアクションによって実行されるチャレンジスクリプトのリクエストでトークンを作成します。がトークン AWS WAF に設定するドメインは、トークンをリクエストするチャレンジスクリプトのタイプと、指定した追加のトークンドメイン設定によって決まります。 AWS WAF は、トークンのドメインを、設定で確認できる最も短く、最も一般的な設定に設定します。 + **JavaScript SDK** — JavaScript SDK は、1 つ以上のドメインを含むことができるトークンドメイン仕様で構成できます。設定するドメインは、保護されたホストドメインと保護パック (ウェブ ACL) のトークンドメインリストに基づいて、 AWS WAF が受け入れるドメインである必要があります。がクライアントのトークン AWS WAF を発行すると、ホストドメインと設定済みリスト内のドメインの中から、トークンドメインをホストドメインに一致する最短のトークンドメインに設定します。たとえば、ホストドメインが `api.example.com`で、トークンドメインリストにがある場合`example.com`、はトークン`example.com`で AWS WAF を使用します。これは、ホストドメインと一致し、短いためです。JavaScript API 設定でトークンドメインリストを指定しない場合、は保護されたリソースのホストドメインにドメイン AWS WAF を設定します。詳細については、「[トークンで使用するドメインの提供](waf-js-challenge-api-set-token-domain.md)」を参照してください。 + **モバイル SDK** — アプリケーションコードでは、トークンドメインプロパティでモバイル SDK を設定する必要があります。このプロパティは、保護されたホストドメインおよび保護パック (ウェブ ACL) のトークンドメインリストに基づき、 AWS WAF が受け入れるドメインでなければなりません。がクライアントのトークン AWS WAF を発行する場合、このプロパティをトークンドメインとして使用します。は、モバイル SDK AWS WAF クライアントに対して発行するトークンでホストドメインを使用しません。詳細については、「[AWS WAF モバイル SDK 仕様](waf-mobile-sdk-specification.md)」で `WAFConfiguration` `domainName` 設定を参照してください。 + **Challenge アクション** – 保護パック (ウェブ ACL) でトークンドメインリストを指定すると、は、ホストドメインとリスト内のドメインの中から、 AWS WAF トークンドメインをホストドメインと一致するものに設定します。たとえば、ホストドメインが `api.example.com`で、トークンドメインリストにがある場合`example.com`、はトークン`example.com`で AWS WAF を使用します。これは、ホストドメインと一致し、短いためです。保護パック (ウェブ ACL) にトークンドメインリストを指定しない場合、は保護されたリソースのホストドメインにドメイン AWS WAF を設定します。 # のトークンラベルのタイプ AWS WAF このセクションでは、 AWS WAF トークン管理がウェブリクエストに追加するラベルについて説明します。ラベルの一般情報については、[でのウェブリクエストのラベル付け AWS WAF](waf-labels.md)を参照してください。 AWS WAF ボットまたは不正コントロールマネージドルールグループを使用する場合、ルールグループは AWS WAF トークン管理を使用してウェブリクエストトークンを検査し、リクエストにトークンラベルを適用します。マネージドルールグループの詳細については、「[AWS WAF Fraud Control アカウント作成不正防止 (ACFP) ルールグループ](aws-managed-rule-groups-acfp.md)」、「[AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループ](aws-managed-rule-groups-atp.md)」、「[AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md)」を参照してください。 **注記** AWS WAF は、これらのインテリジェントな脅威軽減マネージドルールグループのいずれかを使用する場合にのみトークンラベルを適用します。トークン管理では、以下のラベルをウェブリクエストに追加できます。 **クライアントセッションラベル** ラベルには、 AWS WAF トークン管理がクライアントセッションを識別するために使用する一意の識別子`awswaf:managed:token:id:identifier`が含まれています。この識別子は、クライアントが使用していたトークンを破棄した後など、新しいトークンを取得すると変わる可能性があります。 **注記** AWS WAF は、このラベルの Amazon CloudWatch メトリクスを報告しません。 **ブラウザフィンガープリントラベル** ラベルには、 AWS WAF トークン管理がさまざまなクライアントブラウザシグナルから計算する堅牢なブラウザフィンガープリント識別子`awswaf:managed:token:fingerprint:fingerprint-identifier`が含まれています。この識別子は、複数のトークン取得の試行全体で同じままです。フィンガープリント識別子は、単一のクライアントに対して一意ではありません。 **注記** AWS WAF は、このラベルの Amazon CloudWatch メトリクスを報告しません。 **トークンステータスラベル: ラベル名前空間プレフィックス** トークンステータスラベルは、トークン、チャレンジのステータス、およびそれに含まれる CAPTCHA 情報を報告します。各トークンステータスラベルは、次のプレフィクスの 1 つで始まります。 + `awswaf:managed:token:`— トークンの一般的なステータスを報告したり、トークンのチャレンジ情報のステータスを報告したりするために使用されます。 + `awswaf:managed:captcha:`— トークンの CAPTCHA 情報のステータスを報告するために使用されます。 **トークンステータスラベル: ラベル名** プレフィックスに続いて、ラベルの残りの部分には詳細なトークンステータス情報が表示されます。 + `accepted` - リクエストトークンが存在し、以下の内容が含まれています。 + 有効なチャレンジまたは CAPTCHA ソリューション。 + 有効期限が切れていないチャレンジまたは CAPTCHA タイムスタンプ。 + 保護パック (ウェブ ACL) に有効なドメイン仕様。例: ラベル `awswaf:managed:token:accepted` には、ウェブリクエストのトークンに有効なチャレンジソリューション、有効期限が切れていないチャレンジタイムスタンプ、および有効なドメインがあることが示されています。 + `rejected` - リクエストトークンは存在するが、承認基準を満たしていない。トークン管理では、拒否されたラベルに加えて、理由を示すカスタムラベル名前空間と名前が追加されます。 + `rejected:not_solved` — トークンにチャレンジまたは CAPTCHA ソリューションがない。 + `rejected:expired` — 保護パック (ウェブ ACL) に設定されているトークンイミュニティ時間によると、トークンのチャレンジまたは CAPTCHA タイムスタンプの有効期限が切れている。 + `rejected:domain_mismatch` — トークンのドメインが、保護パック (ウェブ ACL) のトークンドメイン設定と一致しない。 + `rejected:invalid` – 指定されたトークンを読み取ることが AWS WAF できませんでした。例: ラベル `awswaf:managed:captcha:rejected` と `awswaf:managed:captcha:rejected:expired` とともに、トークンの CAPTCHA タイムスタンプがウェブ ACL で設定されている CAPTCHA トークンのイミュニティ時間を超えたために、リクエストには有効な CAPTCHA 解決がなかったことが示されています。 + `absent` — リクエストにトークンがないか、トークンマネージャーがそれを読み取れなかった。例: ラベル `awswaf:managed:captcha:absent` には、リクエストにトークンがないことが示されています。 # 有効な AWS WAF トークンを持たないリクエストのブロックこのセクションでは、 AWS WAF モバイル SDK の使用時にトークンが欠落しているログインリクエストをブロックする方法について説明します。インテリジェントな脅威の AWS Managed Rules ルールグループ `AWSManagedRulesACFPRuleSet`、`AWSManagedRulesATPRuleSet`、およびを使用すると`AWSManagedRulesBotControlRuleSet`、ルールグループは AWS WAF トークン管理を呼び出してウェブリクエストトークンのステータスを評価し、それに応じてリクエストにラベルを付けます。 **注記** トークンのラベル付けは、これらのマネージドルールグループのいずれかを使用して評価したウェブリクエストにのみ適用されます。適用されるトークン管理のラベル付けについては、前述の「[のトークンラベルのタイプ AWS WAF](waf-tokens-labeling.md)」セクションを参照してください。その後、インテリジェントな脅威軽減マネージドルールグループは、トークンの要件を次のように処理します。 + `AWSManagedRulesACFPRuleSet` `AllRequests` ルールは、すべてのリクエストに対して Challenge アクションを実行するように設定されており、`accepted` トークンラベルのないリクエストは効果的にブロックされます。 + `AWSManagedRulesATPRuleSet` は、`rejected` トークンラベルを持つリクエストをブロックしますが、`absent` トークンラベルを持つリクエストはブロックしません。 + `accepted`トークンラベルなしでリクエストを 5 回送信すると、`AWSManagedRulesBotControlRuleSet` のターゲットを絞った保護レベルが、クライアントにチャレンジを送信します。有効なトークンを持たない個別のリクエストはブロックされません。ルールグループの共通の保護レベルでは、トークンの要件は管理されません。インテリジェントな脅威ルールグループの詳細については、「[AWS WAF Fraud Control アカウント作成不正防止 (ACFP) ルールグループ](aws-managed-rule-groups-acfp.md)」、「[AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループ](aws-managed-rule-groups-atp.md)」、および「[AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md)」を参照してください。 **Bot Control または ATP マネージドルールグループの使用時にトークンを持たないリクエストをブロックするには** Bot Control と ATP ルールグループを使用すると、有効なトークンを持たないリクエストがルールグループの評価を終了し、保護パック (ウェブ ACL) によって引き続き評価される可能性があります。トークンが不足ているリクエスト、あるいはトークンが拒否されたリクエストをすべてブロックするには、マネージドルールグループの直後に実行するルールを追加し、ルールグループがユーザーに代わって処理しないリクエストをキャプチャしてブロックします。次の内容では、ATP マネージドルールグループを使用する保護パック (ウェブ ACL) の JSON リストの例を示します。保護パック (ウェブ ACL) には、`awswaf:managed:token:absent` ラベルをキャプチャして処理するルールが追加されています。このルールは、ATP ルールグループの範囲に合わせて、ログインエンドポイントに送信されるウェブリクエストに評価を絞り込みます。追加されたルールは太字で表示されます。 ``` { "Name": "exampleWebACL", "Id": "55555555-6666-7777-8888-999999999999", "ARN": "arn:aws:wafv2:us-east-1:111111111111:regional/webacl/exampleWebACL/55555555-4444-3333-2222-111111111111", "DefaultAction": { "Allow": {} }, "Description": "", "Rules": [ { "Name": "AWS-AWSManagedRulesATPRuleSet", "Priority": 1, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesATPRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesATPRuleSet": { "LoginPath": "/web/login", "RequestInspection": { "PayloadType": "JSON", "UsernameField": { "Identifier": "/form/username" }, "PasswordField": { "Identifier": "/form/password" } }, "ResponseInspection": { "StatusCode": { "SuccessCodes": [ 200 ], "FailureCodes": [ 401, 403, 500 ] } } } } ] } }, "OverrideAction": { "None": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSManagedRulesATPRuleSet" } }, { "Name": "RequireTokenForLogins", "Priority": 2, "Statement": { "AndStatement": { "Statements": [ { "Statement": { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:token:absent" } } }, { "ByteMatchStatement": { "SearchString": "/web/login", "FieldToMatch": { "UriPath": {} }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "STARTS_WITH" } }, { "ByteMatchStatement": { "SearchString": "POST", "FieldToMatch": { "Method": {} }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "EXACTLY" } } ] } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "RequireTokenForLogins" } } ], "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "exampleWebACL" }, "Capacity": 51, "ManagedByFirewallManager": false, "RetrofittedByFirewallManager": false, "LabelNamespace": "awswaf:111111111111:webacl:exampleWebACL:" } ``` # CloudFront からの Application Load Balancers に必要な設定保護パック (ウェブ ACL) を Application Load Balancer に関連付けし、その Application Load Balancer を CloudFront ディストリビューションのオリジンとしてデプロイする場合、このセクションをお読みください。このアーキテクチャでは、トークン情報が正しく処理されるには、次の追加設定を行う必要があります。 + `aws-waf-token` クッキーを Application Load Balancer に転送するように CloudFront を設定します。デフォルトでは、CloudFront はウェブリクエストをオリジンに転送する前にクッキーを削除します。トークンクッキーをウェブリクエストに含めるには、トークンキッキーのみまたはすべてのクッキーを含むように CloudFront キャッシュ動作を設定します。これを行う方法の情報については、「*Amazon CloudFront デベロッパーガイド*」の「[クッキーに基づくコンテンツのキャッシュ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Cookies.html)」を参照してください。 + CloudFront ディストリビューションのドメインを有効なトークンドメインとして認識 AWS WAF するようにを設定します。デフォルトでは、CloudFront は `Host`ヘッダーを Application Load Balancer オリジンに設定し、保護されたリソースのドメイン AWS WAF として使用します。ただし、クライアントブラウザは CloudFront ディストリビューションをホストドメインとして見なし、クライアント用に生成されたトークンは CloudFront ドメインをトークンドメインとして使用します。追加の設定がない場合、が保護されたリソースドメインをトークンドメインと AWS WAF 照合すると、不一致が発生します。これを修正するには、CloudFront ディストリビューションのドメイン名を保護パック (ウェブ ACL) 設定のトークンドメインリストに追加します。これを行う方法については、「[AWS WAF 保護パック (ウェブ ACL) トークンドメインリスト設定](waf-tokens-domains.md#waf-tokens-domain-lists)」を参照してください。 # AWS WAF Fraud Control アカウント作成不正防止 (ACFP) このセクションでは、 AWS WAF Fraud Control アカウント作成不正防止 (ACFP) の機能について説明します。アカウント作成の不正行為は、攻撃者が 1 つ以上の偽のアカウントの作成を試みるオンライン上の違法行為です。攻撃者は、プロモーションやサインアップボーナスの濫用、なりすまし、フィッシングなどのサイバー攻撃などの不正行為のために偽のアカウントを使用します。偽のアカウントの存在は、顧客からの評判に傷をつけたり、金銭的な被害を伴う不正行為のリスクを生じさせたりするものであり、ビジネスに悪影響を及ぼす可能性があります。 ACFP 機能を実装することで、アカウント作成の不正試行をモニタリングおよび制御できます。この機能は、コンパニオンアプリケーション統合 SDKs `AWSManagedRulesACFPRuleSet`を備えた AWS Managed Rules ルールグループで AWS WAF 提供されます。 ACFP マネージドルールグループは、悪意のあるアカウント作成の試みの一部である可能性があるリクエストにラベルを付けて管理します。ルールグループは、クライアントでアプリケーションのアカウントサインアップエンドポイントに送信するアカウント作成の試みを検査することでこれを行います。 ACFP は、アカウントのサインアップリクエストをモニタリングして異常なアクティビティがないかを確認し、疑わしいリクエストを自動的にブロックすることで、アカウントサインアップページを保護します。ルールグループは、リクエスト ID、行動分析、機械学習を使用して不正なリクエストを検出します。 + **検査のリクエスト**– ACFP を使用すると、アカウントの異常な作成の試みや、盗まれた認証情報を使用する試みを可視化して制御でき、不正なアカウントの作成を防止できます。ACFP は、盗まれた認証情報のデータベースに照らして E メールとパスワードの組み合わせをチェックします。このデータベースは、漏えいされた認証情報がダークウェブ上で新しく見つかると定期的に更新されます。ACFP は、メールアドレスで使用されているドメインを評価し、電話番号や住所のフィールドの使用をモニタリングして、エントリを検証するとともに、不正行為を検出します。ACFP は、IP アドレスやクライアントセッションごとにデータを集約し、不審なリクエストを大量に送信するクライアントを検出してブロックします。 + **レスポンス検査** – CloudFront ディストリビューションの場合、ACFP ルールグループは、受信したアカウント作成リクエストを検査するだけでなく、アカウント作成の試みに対するアプリケーションのレスポンスも検査して、成功率と失敗率を追跡します。この情報を使用して、ACFP は失敗した試行回数が過度に多いクライアントセッションまたは IP アドレスを一時的にブロックできます。 AWS WAF は、レスポンス検査を非同期で実行するため、ウェブトラフィックのレイテンシーが大きくなることはありません。 **注記** このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。 **注記** ACFP 機能は、Amazon Cognito ユーザープールでは使用できません。 **Topics** + [ # AWS WAF ACFP コンポーネント ](waf-acfp-components.md) + [ # ACFP でのアプリケーション統合 SDK の使用 ](waf-acfp-with-tokens.md) + [ # ACFP マネージドルールグループをウェブ ACL に追加 ](waf-acfp-rg-using.md) + [ # ACFP のテストとデプロイ ](waf-acfp-deploying.md) + [ # AWS WAF Fraud Control アカウント作成不正防止 (ACFP) の例 ](waf-acfp-control-examples.md) # AWS WAF ACFP コンポーネント AWS WAF Fraud Control Account Creation Fraud Prevention (ACFP) の主なコンポーネントは次のとおりです。 + **`AWSManagedRulesACFPRuleSet`** – この AWS マネージドルールルールグループのルールは、さまざまなタイプの不正なアカウント作成アクティビティを検出、ラベル付け、処理します。ルールグループは、指定されたアカウント登録エンドポイントにクライアントが送信する HTTP `GET` テキスト/HTML リクエストと、指定されたアカウントサインアップエンドポイントにクライアントが送信する `POST` ウェブリクエストを検査します。保護された CloudFront ディストリビューションでは、ルールグループはディストリビューションがアカウント作成リクエストに送り返すレスポンスも検査します。このルールグループのルールのリストについては、「[AWS WAF Fraud Control アカウント作成不正防止 (ACFP) ルールグループ](aws-managed-rule-groups-acfp.md)」を参照してください。マネージドルールグループ参照ステートメントを使用して、このルールグループを保護パック (ウェブ ACL) に含めます。このルールグループの使用については、「[ACFP マネージドルールグループをウェブ ACL に追加](waf-acfp-rg-using.md)」を参照してください。 **注記** このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。 + **アプリケーションのアカウント登録ページと作成ページに関する詳細** – 保護パック (ウェブ ACL) に `AWSManagedRulesACFPRuleSet` ルールグループを追加する際には、アカウント登録ページと作成ページに関する情報を提供する必要があります。これにより、ルールグループは検査するリクエストの範囲を絞り込み、アカウント作成ウェブリクエストを適切に検証できます。登録ページは `GET` テキスト/HTML リクエストを受け入れる必要があります。アカウント作成パスは `POST` リクエストを受け入れる必要があります。ACFP ルールグループは、電子メール形式のユーザー名に対応します。詳細については、「[ACFP マネージドルールグループをウェブ ACL に追加](waf-acfp-rg-using.md)」を参照してください。 + **(保護された CloudFront ディストリビューションの場合) アカウント作成の試みに対するアプリケーションのレスポンスに関する詳細** – アカウント作成の試みに対するアプリケーションのレスポンスに関する詳細を提供すると、ACFP ルールグループは、単一の IP アドレスまたは単一のクライアントセッションからのアカウントの一括作成の試みを追跡および管理します。このオプションの設定については、「[ACFP マネージドルールグループをウェブ ACL に追加](waf-acfp-rg-using.md)」を参照してください。 + **JavaScript とモバイルアプリケーションの統合 SDKs** – ACFP 実装で AWS WAF JavaScript とモバイル SDKs を実装して、ルールグループが提供する機能の完全なセットを有効にします。ACFP ルールの多くは、セッションレベルのクライアント検証および動作集約に SDK から提供された情報を使用し、正規のクライアントトラフィックをボットトラフィックから分離するために必要です。SDK の詳細については、「[でのクライアントアプリケーション統合 AWS WAF](waf-application-integration.md)」を参照してください。 ACFP 実装を次と組み合わせて、保護のモニタリング、チューニング、およびカスタマイズに役立てることができます。 + **ログ記録とメトリクス** – 保護パック (ウェブ ACL) 用にログ、Amazon Security Lake データ収集と　Amazon CloudWatch メトリクスを設定して有効にすることで、トラフィックをモニタリングし、ACFP マネージドルールグループがトラフィックにどのように影響するのかを理解できます。`AWSManagedRulesACFPRuleSet` がウェブリクエストに追加するラベルは、データに含まれます。オプションの詳細については、[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)、[Amazon CloudWatch によるモニタリング](monitoring-cloudwatch.md)、及び「[What is Amazon Security Lake?](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html)」を参照してください。ニーズと確認できるトラフィックに応じて、`AWSManagedRulesACFPRuleSet` の実装をカスタマイズできます。例えば、ACFP 評価から一部のトラフィックを除外したり、スコープダウンステートメントやラベルマッチングルールなどの AWS WAF 機能を使用して、識別したアカウント作成の不正試行の処理方法を変更したりできます。 + **ラベルとラベル一致ルール** – `AWSManagedRulesACFPRuleSet` のどのルールでも、ブロック動作をカウントに切り替えて、ルールによって追加されたラベルと照合することができます。このアプローチを使用し、ACFP マネージドルールグループによって識別されるウェブリクエストの処理方法をカスタマイズします。ラベル付けおよびラベル一致ステートメントの使用の詳細については、「[ラベル一致ルールステートメント](waf-rule-statement-type-label-match.md)」および「[でのウェブリクエストのラベル付け AWS WAF](waf-labels.md)」を参照してください。 + **カスタムリクエストとレスポンス** - 許可するリクエストにはカスタムヘッダーを追加し、ブロックするリクエストにはカスタムレスポンスを送信できます。これを行うには、ラベル一致を AWS WAF カスタムリクエストおよび応答機能とペアリングします。リクエストとレスポンスをカスタマイズする方法については、「[でカスタマイズされたウェブリクエストとレスポンス AWS WAF](waf-custom-request-response.md)」を参照してください。 # ACFP でのアプリケーション統合 SDK の使用 ACFP ルールグループを最も効率的に使用するためにも、アプリケーション統合 SDK を実装することを強くお勧めします。 + **完全なルールグループ機能** – ACFP ルール `SignalClientHumanInteractivityAbsentLow` は、アプリケーション統合によって情報が提供されたトークンでのみ機能します。このルールは、アプリケーションページに対する人間の異常なインタラクションを検出および管理します。アプリケーション統合 SDK は、マウスの動き、キーの押下、その他の測定を通じて、人間の通常のインタラクティビティを検出できます。ルールアクション CAPTCHA および Challenge によって送信されるインタースティシャルは、このタイプのデータを提供できません。 + **レイテンシーの短縮** – ルールグループのルール `AllRequests` は、チャレンジトークンをまだ持っていないリクエストに Challenge ルールアクションを適用します。これが発生すると、リクエストはルールグループによって 2 回評価されます。1 回目の評価はトークンなしで実行され、2 回目の評価は Challenge アクションインタースティシャルによってトークンが取得された後に実行されます。`AllRequests` ルールを使用するだけであれば追加料金は発生しませんが、このアプローチではウェブトラフィックに対するオーバーヘッドが大きくなり、エンドユーザーエクスペリエンスのレイテンシーが長くなります。アプリケーション統合を使用してクライアント側でトークンを取得する場合、アカウント作成リクエストを送信する前に、ACFP ルールグループがリクエストを 1 回評価します。ルールグループ機能の情報については、「[AWS WAF Fraud Control アカウント作成不正防止 (ACFP) ルールグループ](aws-managed-rule-groups-acfp.md)」を参照してください。 SDK の詳細については、「[でのクライアントアプリケーション統合 AWS WAF](waf-application-integration.md)」を参照してください。 AWS WAF トークンの詳細については、「」を参照してください[AWS WAF インテリジェントな脅威の軽減におけるトークンの使用](waf-tokens.md)。ルールアクションの情報については、「[CAPTCHA および Challengeの AWS WAF](waf-captcha-and-challenge.md)」を参照してください。 # ACFP マネージドルールグループをウェブ ACL に追加このセクションでは、`AWSManagedRulesACFPRuleSet` ルールグループを追加および設定する方法について説明します。ウェブトラフィックのアカウントの不正な作成アクティビティを認識するように ACFP マネージドルールグループを設定するには、クライアントが登録ページにアクセスする方法、およびアプリケーションにアカウント作成リクエストを送信する方法に関する情報を入力します。保護された Amazon CloudFront ディストリビューションでは、アカウント作成リクエストに対するアプリケーションの応答方法に関する情報も指定します。この設定は、マネージドルールグループの通常の設定に追加されます。ルールグループの説明とルールリストについては、「[AWS WAF Fraud Control アカウント作成不正防止 (ACFP) ルールグループ](aws-managed-rule-groups-acfp.md)」を参照してください。 **注記** 盗まれた認証情報の ACFP データベースには、E メール形式のユーザー名のみが含まれています。このガイダンスは、 AWS WAF 保護パック (ウェブ ACL)、ルール、およびルールグループを作成および管理する方法を一般的に認識しているユーザーを対象としています。これらのトピックは、このガイドの前のセクションでカバーされています。マネージドルールグループを保護パック (ウェブ ACL) に追加する方法の基本については、「[コンソールを通じた保護パック (ウェブ ACL) へのマネージドルールグループの追加](waf-using-managed-rule-group.md)」を参照してください。 **ベストプラクティスに従う** ACFP ルールグループは、「[でのインテリジェントな脅威軽減のベストプラクティス AWS WAF](waf-managed-protections-best-practices.md)」に記載されているベストプラクティスに従って使用してください。 **保護パック (ウェブ ACL) で `AWSManagedRulesACFPRuleSet` ルールグループを使用するには** 1. AWS マネージドルールグループを保護パック (ウェブ ACL) `AWSManagedRulesACFPRuleSet`に追加し、保存する前にルールグループ設定**を編集**します。 **注記** このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。 1. **[ルールグループを設定]** ペインで、ACFP ルールグループがアカウント作成リクエストの検査に使用する情報を入力します。 1. **「パスで正規表現を使用する**」で、登録およびアカウント作成ページのパス仕様に対して正規表現マッチング AWS WAF を実行する場合は、これをオンに切り替えます。 AWS WAF は、いくつかの例外`libpcre`を除いて、PCRE ライブラリで使用されるパターン構文をサポートします。ライブラリは、「[PCRE - Perl Compatible Regular Expressions](http://www.pcre.org/)」で文書化されています。 AWS WAF サポートの詳細については、「」を参照してください[でサポートされている正規表現構文 AWS WAF](waf-regex-pattern-support.md)。 1. **[登録ページのパス]** で、アプリケーションの登録ページのエンドポイントのパスを指定します。このページは `GET` テキスト/HTML リクエストを受け入れる必要があります。ルールグループは、指定された登録ページのエンドポイントに対する HTTP `GET` テキスト/HTML リクエストのみを検査します。 **注記** エンドポイントの照会では大文字と小文字が区別されません｡正規表現の仕様には、大文字と小文字を区別しない照合を無効にするフラグ `(?-i)` を含めてはいけません。文字列の指定はフォワードスラッシュ「`/`」で始まる必要があります。例えば、URL `https://example.com/web/registration` では、文字列パスの指定「`/web/registration`」を指定できます。指定したパスで始まる登録ページのパスは一致とみなされます。例えば、`/web/registration` は登録パス `/web/registration`、`/web/registration/`、`/web/registrationPage`、および `/web/registration/thisPage` に一致しますが、パス `/home/web/registration` または `/website/registration` には一致しません。 **注記** エンドユーザーがアカウント作成リクエストを送信する前に、登録ページをロードするようにします。これは、クライアントからのアカウント作成リクエストに、有効なトークンが確実に含まれているようにするのに役立ちます。 1. **[アカウント作成パス]**には、入力済みの新規ユーザー情報を受け入れるウェブサイトの URI を指定します。この URI は `POST` リクエストを受け入れる必要があります。 **注記** エンドポイントの照会では大文字と小文字が区別されません｡正規表現の仕様には、大文字と小文字を区別しない照合を無効にするフラグ `(?-i)` を含めてはいけません。文字列の指定はフォワードスラッシュ「`/`」で始まる必要があります。例えば、URL `https://example.com/web/newaccount` では、文字列パスの指定「`/web/newaccount`」を指定できます。指定したパスで始まるアカウント作成パスは一致とみなされます。例えば、`/web/newaccount` はアカウント作成パス `/web/newaccount`、`/web/newaccount/`、`/web/newaccountPage`、および `/web/newaccount/thisPage` に一致しますが、パス `/home/web/newaccount` または `/website/newaccount` には一致しません。 1. **[リクエスト検査]** で、リクエストのペイロードタイプと、ユーザー名、パスワード、他のアカウント作成の詳細が指定されているリクエスト本文内のフィールドの名前を指定して、アプリケーションがアカウント作成の試みを受け入れる方法を指定します。 **注記** 主な住所フィールドと電話番号フィールドについては、リクエストペイロードに表示される順にフィールドを指定します。これらのフィールド名の指定は、ペイロードタイプによって異なります。 + **JSON ペイロードタイプ** – JSON Pointer 構文でフィールド名を指定します。JSON Pointer 構文の詳細については、インターネットエンジニアリングタスクフォース (IETF) ドキュメントの「[JavaScript Object Notation (JSON) Pointer](https://tools.ietf.org/html/rfc6901)」を参照してください。例えば、次の JSON ペイロードの例では、ユーザー名フィールドの仕様は `/signupform/username` で、主な住所フィールドの仕様は `/signupform/addrp1`、`/signupform/addrp2`、および `/signupform/addrp3` です。 ``` { "signupform": { "username": "THE_USERNAME", "password": "THE_PASSWORD", "addrp1": "PRIMARY_ADDRESS_LINE_1", "addrp2": "PRIMARY_ADDRESS_LINE_2", "addrp3": "PRIMARY_ADDRESS_LINE_3", "phonepcode": "PRIMARY_PHONE_CODE", "phonepnumber": "PRIMARY_PHONE_NUMBER" } } ``` + **FORM\$1ENCODED ペイロードタイプ** – HTML 形式の名前を使用します。例えば、`username1` と `password1` という名前のユーザーおよびパスワードの入力要素を持つ HTML フォームの場合、ユーザー名フィールドの指定は `username1` で、パスワードフィールドの指定は `password1` です。 1. Amazon CloudFront ディストリビューションが保護されている場合、**[レスポンス検査]** で、アプリケーションがアカウント作成の試みに対するレスポンスで成功や失敗をどのように示すかを指定します。 **注記** ACFP レスポンス検査は、CloudFront ディストリビューションを保護している保護パック (ウェブ ACL) でのみ使用できます。 ACFP で検査するアカウント作成レスポンスのコンポーネントを 1 つ指定します。**Body** および **JSON** コンポーネントタイプの場合、 AWS WAF はコンポーネントの最初の 65,536 バイト (64 KB) を検査できます。インターフェイスに示されているように、コンポーネントタイプの検査基準を指定します。コンポーネント内で検査する成功基準と失敗基準の両方を指定する必要があります。例えば、アプリケーションがアカウント作成の試みのステータスをレスポンスのステータスコードで示し、成功の場合は「`200 OK`」、失敗の場合は「`401 Unauthorized`」または「`403 Forbidden`」を使用するとします。レスポンス検査の **[コンポーネントタイプ]** を **[ステータスコード]** に設定し、**[成功]** テキストボックスに「`200`」と入力し、**[失敗]** テキストボックスの 1 行目に「`401`」、2 行目に「`403`」と入力します。 ACFP ルールグループは、成功または失敗の検査基準に一致するレスポンスのみをカウントします。ルールグループのルールは、アカウントの一括作成の試みを軽減するために、カウントされるレスポンスの成功率が高すぎるクライアントに対してアクションを実行します。ルールグループのルールが正確に動作するように、アカウント作成の試みの成功と失敗の両方に関する詳細な情報を必ず入力してください。アカウント作成のレスポンスを検査するルールを確認するには、「[AWS WAF Fraud Control アカウント作成不正防止 (ACFP) ルールグループ](aws-managed-rule-groups-acfp.md)」のルールリストで `VolumetricIPSuccessfulResponse` と `VolumetricSessionSuccessfulResponse` を探します。 1. ルールグループに必要な追加設定を指定します。マネージドルールグループステートメントにスコープダウンステートメントを追加することで、ルールグループが検査するリクエストの範囲をさらに限定できます。例えば、特定のクエリ引数または cookie を持つリクエストのみを検査できます。ルールグループは、スコープダウンステートメントの基準に一致し、ルールグループ設定で指定したアカウント登録パスとアカウント作成パスに送信されたリクエストのみを検査します。スコープダウンステートメントの詳細については、「[でのスコープダウンステートメントの使用 AWS WAF](waf-rule-scope-down-statements.md)」を参照してください。 1. 変更を保護パック (ウェブ ACL) に保存します。本番稼働トラフィックに ACFP 実装をデプロイする前に、トラフィックへの潜在的な影響に慣れるまで、ステージング環境またはテスト環境でテストおよびチューニングします。その後、ルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。ガイダンスについては、次のセクションを参照してください。 # ACFP のテストとデプロイこのセクションでは、サイトの AWS WAF Fraud Control Account Creation Fraud Prevention (ACFP) 実装を設定およびテストするための一般的なガイダンスを提供します。実行する具体的なステップは、ニーズ、リソース、および受け取るウェブリクエストによって異なります。この情報は、[AWS WAF 保護のテストとチューニング](web-acl-testing.md) で提供されているテストおよび調整に関する一般情報とは別です。 **注記** AWS マネージドルールは、一般的なウェブ脅威から保護するように設計されています。ドキュメントに従って使用すると、 AWS マネージドルールルールグループはアプリケーションに別のセキュリティレイヤーを追加します。ただし、 AWS マネージドルールルールグループは、選択した AWS リソースによって決定されるセキュリティ責任に代わるものではありません。責任[共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)を参照して、のリソースが適切に保護 AWS されていることを確認します。 **本番稼働トラフィックのリスク** 本番稼働トラフィックに ACFP 実装をデプロイする前に、トラフィックへの潜在的な影響に慣れるまで、ステージング環境またはテスト環境でテストおよびチューニングします。その後、ルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。 AWS WAF は、ACFP 設定の検証に使用できるテスト認証情報を提供します。次の手順では、ACFP マネージドルールグループを使用するようにテスト保護パック (ウェブ ACL) を設定し、ルールグループによって追加されたラベルをキャプチャするルールを設定してから、これらのテスト認証情報を使用してアカウント作成の試みを実行します。アカウント作成の試みに関する Amazon CloudWatch メトリクスを確認して、保護パック (ウェブ ACL) が試行を正しく管理していることを検証します。このガイダンスは、 AWS WAF 保護パック (ウェブ ACL)、ルール、およびルールグループを作成および管理する方法を一般的に認識しているユーザーを対象としています。これらのトピックは、このガイドの前のセクションでカバーされています。 **Fraud Control Account Creation AWS WAF Fraud Prevention (ACFP) の実装を設定してテストするには** これらのステップを最初にテスト環境で実行し、次に本番環境で実行します。 1. **AWS WAF Fraud Control アカウント作成不正防止 (ACFP) マネージドルールグループをカウントモードに追加する** **注記** このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。 AWS マネージドルールルールグループ`AWSManagedRulesACFPRuleSet`を新規または既存の保護パック (ウェブ ACL) に追加し、現在の保護パック (ウェブ ACL) の動作を変更しないように設定します。このルールグループのルールとラベルの詳細については、「[AWS WAF Fraud Control アカウント作成不正防止 (ACFP) ルールグループ](aws-managed-rule-groups-acfp.md)」を参照してください。 + マネージドルールグループを追加する際には、それを編集し、次の手順を実行します。 + **[ルールグループを設定]** ペインで、アプリケーションのアカウント登録ページと作成ページの詳細を入力します。ACFP ルールグループは、この情報を使用してサインインアクティビティをモニタリングします。詳細については、「[ACFP マネージドルールグループをウェブ ACL に追加](waf-acfp-rg-using.md)」を参照してください。 + **[Rules]** (ルール) ペインで、**[Override all rule actions]** (すべてのルールアクションをオーバーライド) ドロップダウンを開いて、**[Count]** を選択します。この設定では、 AWS WAF は、ルールグループ内のすべてのルールに対してリクエストを評価し、その結果の一致のみをカウントしつつ、引き続きリクエストにラベルを追加します。詳細については、「[ルールグループ内のルールアクションのオーバーライド](web-acl-rule-group-settings.md#web-acl-rule-group-rule-action-override)」を参照してください。このオーバーライドにより、ACFP マネージドルールの影響をモニタリングして、例外 (内部のユースケースの例外など) を追加するかどうか判断できます。 + 保護パック (ウェブ ACL) の既存のルールの後に評価されるように、ルールグループを配置します。優先順位の設定の数値は、既に使用しているルールまたはルールグループよりも高くなります。詳細については、「[ルールの優先度を設定する](web-acl-processing-order.md)」を参照してください。これにより、現在のトラフィックの処理が中断されることはありません。例えば、SQL インジェクションやクロスサイトスクリプティングなどの悪意のあるトラフィックを検出するルールがある場合、そのルールは引き続き検出し、それをログに記録します。または、既知の悪意のないトラフィックを許可するルールがある場合、ACFP マネージドルールグループによってブロックされるようにすることなく、そのトラフィックを許可し続けることができます。テストおよびチューニングのアクティビティ中に、処理順序を調整することもできます。 1. **アプリケーション統合 SDK を実装する** AWS WAF JavaScript SDK をブラウザのアカウント登録パスとアカウント作成パスに統合します。は、iOS デバイスと Android デバイスを統合するモバイル SDKs AWS WAF も提供します。統合 SDK の詳細については、「[でのクライアントアプリケーション統合 AWS WAF](waf-application-integration.md)」を参照してください。このレコメンデーションについては、「[ACFP でのアプリケーション統合 SDK の使用](waf-acfp-with-tokens.md)」を参照してください。 **注記** アプリケーション統合 SDK を使用できない場合は、保護パック (ウェブ ACL) で ACFP ルールグループを編集し、`AllRequests` ルールに設定したオーバーライドを削除することで、その ACFP ルールグループをテストできます。これにより、ルールの Challenge アクションの設定が有効になり、有効なチャレンジトークンが確実にリクエストに含まれるようになります。これは最初にテスト環境で実行し、その後に本番環境で細心の注意を払って実行してください。このアプローチは、ユーザーをブロックする可能性があります。例えば、登録ページのパスが `GET` テキスト/HTML リクエストを受け入れない場合、このルール設定は、登録ページですべてのリクエストを効果的にブロックできます。 1. **保護パック (ウェブ ACL) のサンプリング、ログ記録、およびメトリクスの有効化** 必要に応じて、保護パック (ウェブ ACL) のログ記録、Amazon Security Lake データ収集、リクエストサンプリング、Amazon CloudWatch メトリクスを設定します。これらの可視化ツールを使用して ACFP マネージドルールグループとトラフィックとのインタラクションをモニタリングできます。 + ログ作成の詳細については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。 + Amazon Security Lake の詳細については、[「Amazon Security Lake とは](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html)」および*「Amazon Security Lake* [ユーザーガイド」の AWS 「サービスからデータを収集](https://docs.aws.amazon.com/security-lake/latest/userguide/internal-sources.html)する」を参照してください。 + Amazon CloudWatch メトリクスの詳細については、「[Amazon CloudWatch によるモニタリング](monitoring-cloudwatch.md)」を参照してください。 + ウェブリクエストサンプリングの詳細については、「[ウェブリクエストのサンプルの表示](web-acl-testing-view-sample.md)」を参照してください。 1. **保護パック (ウェブ ACL) をリソースに関連付ける** 保護パック (ウェブ ACL) がテストリソースに関連付けられていない場合は、関連付けます。詳細については、「[AWS リソースとの保護の関連付けまたは関連付け解除](web-acl-associating-aws-resource.md)」を参照してください。 1. **トラフィックと ACFP ルールの一致をモニタリングする** 通常のトラフィックがフローしていることと、ACFP マネージドルールグループのルールが一致するウェブリクエストにラベルを追加していることを確認します。ログにラベルが表示され、Amazon CloudWatch メトリクスで ACFP とラベルのメトリクスを確認できます。ログでは、ルールグループでカウントするようにオーバーライドしたルールが、カウントに設定された `action` と、オーバーライドした設定済のルールアクションを示す `overriddenAction` とともに、`ruleGroupList` に表示されます。 1. **ルールグループの認証情報チェック機能をテストする** テスト用の侵害された認証情報を使用してアカウント作成を試行し、ルールグループが想定どおりに照合することを確認します。 1. 保護されたリソースのアカウント登録ページにアクセスし、新しいアカウントの追加を試みます。次の AWS WAF テスト認証情報ペアを使用して、任意のテストを入力します。 + ユーザー: `WAF_TEST_CREDENTIAL@wafexample.com` + パスワード: `WAF_TEST_CREDENTIAL_PASSWORD` これらのテスト認証情報は侵害された認証情報として分類され、ACFP マネージドルールグループはアカウント作成リクエストに `awswaf:managed:aws:acfp:signal:credential_compromised` ラベル (ログでの確認が可能) を追加します。 1. 保護パック (ウェブ ACL) ログで、テストアカウント作成リクエストのログエントリの `labels` フィールドで `awswaf:managed:aws:acfp:signal:credential_compromised` ラベルを探します。ログ作成の詳細については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。侵害された認証情報をルールグループが想定どおりにキャプチャすることを検証したら、保護されたリソースに必要な実装を設定するステップを実行できます。 1. **CloudFront ディストリビューションの場合、アカウントの一括作成の試みについてのルールグループによる管理をテストします。** ACFP ルールグループに設定したレスポンスの成功基準それぞれに対してこのテストを実行します。テストとテストの間は 30 分以上あけてください。 1. 成功基準ごとに、レスポンス内のその成功基準で成功するアカウント作成の試みを特定します。その後、単一のクライアントセッションから、30 分未満で少なくとも 5 回のアカウント作成の正常な試みを実行します。通常、ユーザーはサイトでアカウントを 1 つだけ作成します。最初のアカウント作成が成功した後、`VolumetricSessionSuccessfulResponse` ルールは他のアカウント作成レスポンスとの照合を開始し、ルールアクションのオーバーライドに基づいてそれらにラベル付けをしてカウントします。レイテンシーにより、ルールで最初の 1 回または 2 回が見逃される可能性があります。 1. 保護パック (ウェブ ACL) ログで、テストアカウント作成ウェブリクエストのログエントリの `labels` フィールドで `awswaf:managed:aws:acfp:aggregate:volumetric:session:successful_creation_response:high` ラベルを探します。ログ作成の詳細については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。これらのテストは、ルールによって集計された成功数がルールのしきい値を超えていることを確認することで、成功基準がレスポンスと一致していることを検証します。しきい値に達した後も同じセッションからアカウント作成リクエストを送信し続けると、成功率がしきい値を下回るまでルールによる一致が継続されます。しきい値を超えている間、ルールはセッションアドレスからの正常なアカウント作成の試みと失敗したアカウント作成の試みの両方に一致させます。 1. **ACFP ウェブリクエストの処理をカスタマイズする** 必要に応じて、リクエストを明示的に許可またはブロックする独自のルールを追加して、ACFP ルールがそのリクエストを処理する方法を変更します。例えば、ACFP ラベルを使用して、リクエストを許可またはブロックしたり、リクエスト処理をカスタマイズしたりできます。ACFP マネージドルールグループの後にラベル一致ルールを追加して、適用する処理のためにラベル付きリクエストをフィルタリングできます。テスト後、関連する ACFP ルールをカウントモードで維持し、カスタムルールでリクエストの処理に関する決定を維持します。例については、[ACFP の例: 侵害された認証情報についてのカスタムレスポンス](waf-acfp-control-example-compromised-credentials.md)を参照してください。 1. **テストルールを削除し、ACFP マネージドルールグループ設定を有効にする** 状況によっては、一部の ACFP ルールをカウントモードのままにすると判断していた可能性もあります。ルールグループ内で設定したとおりに実行するルールについては、保護パック (ウェブ ACL) ルールグループ設定でカウントモードを無効にします。テストが終了したら、テストラベル一致ルールを削除することもできます。 1. **モニタリングおよびチューニング** ウェブリクエストが希望どおりに処理されていることを確認するには、使用することを希望する ACFP 機能を有効にした後、トラフィックを注意深くモニタリングします。ルールグループに対するルールカウントの上書きと独自のルールを使用して、必要に応じて動作を調整します。 ACFP ルールグループの実装のテストが完了したら、 AWS WAF JavaScript SDK をブラウザのアカウント登録ページとアカウント作成ページにまだ統合していない場合は、統合することを強くお勧めします。また、には、iOS デバイスと Android デバイスを統合するモバイル SDKs AWS WAF も用意されています。統合 SDK の詳細については、「[でのクライアントアプリケーション統合 AWS WAF](waf-application-integration.md)」を参照してください。このレコメンデーションについては、「[ACFP でのアプリケーション統合 SDK の使用](waf-acfp-with-tokens.md)」を参照してください。 # AWS WAF Fraud Control アカウント作成不正防止 (ACFP) の例このセクションでは、 AWS WAF Fraud Control Account Creation Fraud Prevention (ACFP) の実装の一般的なユースケースに対応できる設定例を示します。各例は、ユースケースの説明を提供し、カスタム設定ルールの JSON リストにそのソリューションを示します。 **注記** これらの例に示されているような JSON リストは、コンソール保護パック (ウェブ ACL) JSON ダウンロードやルール JSON エディタを介して、または API やコマンドラインインターフェイスでの `getWebACL` オペレーションを介して取得できます。 **Topics** + [ # ACFP の例: シンプルな設定 ](waf-acfp-control-example-basic.md) + [ # ACFP の例: 侵害された認証情報についてのカスタムレスポンス ](waf-acfp-control-example-compromised-credentials.md) + [ # ACFP の例: レスポンス検査の設定 ](waf-acfp-control-example-response-inspection.md) # ACFP の例: シンプルな設定次の JSON リストは、 AWS WAF Fraud Control アカウント作成不正防止 (ACFP) マネージドルールグループを使用した保護パック (ウェブ ACL) の例を示しています。検証するために、`CreationPath` および `RegistrationPagePath` の追加設定と、ペイロードタイプ、およびペイロード内の新しいアカウント情報を見つけるために必要な情報に注意してください。ルールグループはこの情報を使用して、アカウント作成リクエストをモニタリングおよび管理します。この JSON には、ラベル名前空間や保護パック (ウェブ ACL) のアプリケーション統合 URL など、保護パック (ウェブ ACL) の自動生成された設定が含まれます。 ``` { "Name": "simpleACFP", "Id": "... ", "ARN": "arn:aws:wafv2:us-east-1:111122223333:regional/webacl/simpleACFP/... ", "DefaultAction": { "Allow": {} }, "Description": "", "Rules": [ { "Name": "AWS-AWSManagedRulesACFPRuleSet", "Priority": 0, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesACFPRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesACFPRuleSet": { "CreationPath": "/web/signup/submit-registration", "RegistrationPagePath": "/web/signup/registration", "RequestInspection": { "PayloadType": "JSON", "UsernameField": { "Identifier": "/form/username" }, "PasswordField": { "Identifier": "/form/password" }, "EmailField": { "Identifier": "/form/email" }, "PhoneNumberFields": [ { "Identifier": "/form/country-code" }, { "Identifier": "/form/region-code" }, { "Identifier": "/form/phonenumber" } ], "AddressFields": [ { "Identifier": "/form/name" }, { "Identifier": "/form/street-address" }, { "Identifier": "/form/city" }, { "Identifier": "/form/state" }, { "Identifier": "/form/zipcode" } ] }, "EnableRegexInPath": false } } ] } }, "OverrideAction": { "None": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSManagedRulesACFPRuleSet" } } ], "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "simpleACFP" }, "Capacity": 50, "ManagedByFirewallManager": false, "RetrofittedByFirewallManager": false, "LabelNamespace": "awswaf:111122223333:webacl:simpleACFP:" } ``` # ACFP の例: 侵害された認証情報についてのカスタムレスポンスデフォルトでは、ルールグループ `AWSManagedRulesACFPRuleSet` によって実行される認証情報チェックは、リクエストにラベル付けしてブロックすることで、侵害された認証情報を処理します。ルールグループとルールの動作の詳細については、「[AWS WAF Fraud Control アカウント作成不正防止 (ACFP) ルールグループ](aws-managed-rule-groups-acfp.md)」を参照してください。ユーザーが提供したアカウント認証情報が侵害されたことをユーザーに通知するために、次を実行できます。 + **`SignalCredentialCompromised` ルールを Count にオーバーライド** — これにより、ルールは一致するリクエストをカウントしてラベル付けのみします。 + **カスタム処理でラベル一致ルールの追加** – ACFP ラベルと照合し、カスタム処理を実行するようにルールを設定します。次の保護パック (ウェブ ACL) リスティングは、`SignalCredentialCompromised` ルールアクションがカウントするようにオーバーライドされた状態で、前の例の ACFP マネージドルールグループを示しています。この設定では、このルールグループは、侵害された認証情報を使用するウェブリクエストを評価すると、リクエストにラベルを付けますが、ブロックすることはありません。さらに、保護パック (ウェブ ACL) には `aws-waf-credential-compromised` という名前のカスタムレスポンスと `AccountSignupCompromisedCredentialsHandling` という名前の新しいルールが追加されました。ルールの優先順位にはルールグループよりも大きい数値が設定されているため、保護パック (ウェブ ACL) 評価では、ルールはルールグループの後に実行されます。新しいルールは、ルールグループの侵害された認証情報ラベルを持つすべてのリクエストと照合します。ルールは一致を見つけると、カスタムレスポンス本文を含むリクエストに Block アクションを適用します。カスタムレスポンス本文は、認証情報が侵害されたという情報をエンドユーザーに提供し、実行するアクションを提案します。 ``` { "Name": "compromisedCreds", "Id": "... ", "ARN": "arn:aws:wafv2:us-east-1:111122223333:regional/webacl/compromisedCreds/...", "DefaultAction": { "Allow": {} }, "Description": "", "Rules": [ { "Name": "AWS-AWSManagedRulesACFPRuleSet", "Priority": 0, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesACFPRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesACFPRuleSet": { "CreationPath": "/web/signup/submit-registration", "RegistrationPagePath": "/web/signup/registration", "RequestInspection": { "PayloadType": "JSON", "UsernameField": { "Identifier": "/form/username" }, "PasswordField": { "Identifier": "/form/password" }, "EmailField": { "Identifier": "/form/email" }, "PhoneNumberFields": [ { "Identifier": "/form/country-code" }, { "Identifier": "/form/region-code" }, { "Identifier": "/form/phonenumber" } ], "AddressFields": [ { "Identifier": "/form/name" }, { "Identifier": "/form/street-address" }, { "Identifier": "/form/city" }, { "Identifier": "/form/state" }, { "Identifier": "/form/zipcode" } ] }, "EnableRegexInPath": false } } ], "RuleActionOverrides": [ { "Name": "SignalCredentialCompromised", "ActionToUse": { "Count": {} } } ] } }, "OverrideAction": { "None": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSManagedRulesACFPRuleSet" } }, { "Name": "AccountSignupCompromisedCredentialsHandling", "Priority": 1, "Statement": { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:acfp:signal:credential_compromised" } }, "Action": { "Block": { "CustomResponse": { "ResponseCode": 406, "CustomResponseBodyKey": "aws-waf-credential-compromised", "ResponseHeaders": [ { "Name": "aws-waf-credential-compromised", "Value": "true" } ] } } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AccountSignupCompromisedCredentialsHandling" } } ], "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "compromisedCreds" }, "Capacity": 51, "ManagedByFirewallManager": false, "RetrofittedByFirewallManager": false, "LabelNamespace": "awswaf:111122223333:webacl:compromisedCreds:", "CustomResponseBodies": { "aws-waf-credential-compromised": { "ContentType": "APPLICATION_JSON", "Content": "{\n \"credentials-compromised\": \"The credentials you provided have been found in a compromised credentials database.\\n\\nTry again with a different username, password pair.\"\n}" } } } ``` # ACFP の例: レスポンス検査の設定次の JSON リストは、オリジンレスポンスを検査するように設定された AWS WAF Fraud Control Account Creation Fraud Prevention (ACFP) マネージドルールグループを使用した保護パック (ウェブ ACL) の例を示しています。成功とレスポンスステータスコードを指定する応答検査設定を注意してください。ヘッダー、ボディ、ボディの JSON 一致に基づいて成功とレスポンスの設定を構成することもできます。この JSON には、ラベル名前空間や保護パック (ウェブ ACL) のアプリケーション統合 URL など、保護パック (ウェブ ACL) の自動生成された設定が含まれます。 **注記** ATP レスポンス検査は、CloudFront ディストリビューションが保護されている保護パック (ウェブ ACL) でのみ使用できます。 ``` { "Name": "simpleACFP", "Id": "... ", "ARN": "arn:aws:wafv2:us-east-1:111122223333:regional/webacl/simpleACFP/... ", "DefaultAction": { "Allow": {} }, "Description": "", "Rules": [ { "Name": "AWS-AWSManagedRulesACFPRuleSet", "Priority": 0, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesACFPRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesACFPRuleSet": { "CreationPath": "/web/signup/submit-registration", "RegistrationPagePath": "/web/signup/registration", "RequestInspection": { "PayloadType": "JSON", "UsernameField": { "Identifier": "/form/username" }, "PasswordField": { "Identifier": "/form/password" }, "EmailField": { "Identifier": "/form/email" }, "PhoneNumberFields": [ { "Identifier": "/form/country-code" }, { "Identifier": "/form/region-code" }, { "Identifier": "/form/phonenumber" } ], "AddressFields": [ { "Identifier": "/form/name" }, { "Identifier": "/form/street-address" }, { "Identifier": "/form/city" }, { "Identifier": "/form/state" }, { "Identifier": "/form/zipcode" } ] }, "ResponseInspection": { "StatusCode": { "SuccessCodes": [ 200 ], "FailureCodes": [ 401 ] } }, "EnableRegexInPath": false } } ] } }, "OverrideAction": { "None": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSManagedRulesACFPRuleSet" } } ], "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "simpleACFP" }, "Capacity": 50, "ManagedByFirewallManager": false, "RetrofittedByFirewallManager": false, "LabelNamespace": "awswaf:111122223333:webacl:simpleACFP:" } ``` # AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) このセクションでは、 AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) の機能について説明します。アカウント乗っ取りは、攻撃者が個人のアカウントへの不正アクセスを得るオンラインの違法行為です。攻撃者は、盗まれた認証情報を使用したり、一連の試行を通じて被害者のパスワードを推測するなど、さまざまな方法でこれを行う可能性があります。攻撃者がアクセスできるようになると、被害者から金銭や情報を盗んだり、サービスを不正に利用したりする可能性があります。攻撃者は、被害者が所有する他のアカウントにアクセスしたり、他の人や組織のアカウントにアクセスしたりするために、被害者としてふるまう可能性があります。さらに、被害者であるユーザーが自分のアカウントからブロックされるようにするために、そのユーザーのパスワードを変更しようとする場合があります。 ATP 機能を実装することで、アカウント乗っ取りの試行をモニタリングおよび制御できます。は、この機能を AWS マネージドルールのルールグループ`AWSManagedRulesATPRuleSet`およびコンパニオンアプリケーション統合 SDKs で AWS WAF 提供します。 ATP マネージドルールグループは、悪意のあるアカウント乗っ取りの試みの一部である可能性があるリクエストにラベルを付けて管理します。ルールグループは、クライアントでアプリケーションのログインエンドポイントに送信するログイン試行を検査することでこれを行います。 + **リクエスト検査** – ATP を使用すると、異常なログイン試行や盗まれた認証情報を使用するログイン試行を可視化して制御できるため、不正行為につながる可能性のあるアカウントの乗っ取りを防ぐことができます。ATP は、盗まれた認証情報のデータベースに照らして E メールとパスワードの組み合わせをチェックします。このデータベースは、漏洩された認証情報がダークウェブ上で新しく見つかると定期的に更新されます。ATP は、IP アドレスやクライアントセッションごとにデータを集約し、不審なリクエストを大量に送信するクライアントを検出してブロックします。 + **レスポンス検査** – CloudFront ディストリビューションの場合、ATP ルールグループは、受信したログインリクエストを検査するだけでなく、ログイン試行に対するアプリケーションの応答も検査して、成功率と失敗率を追跡します。この情報を使用して、ATP はログイン失敗の回数が過度に多いクライアントセッションまたは IP アドレスを一時的にブロックできます。 AWS WAF は、レスポンス検査を非同期で実行するため、ウェブトラフィックのレイテンシーが大きくなることはありません。 **注記** このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。 **注記** ATP 機能は、Amazon Cognito ユーザープールでは使用できません。 **Topics** + [ # AWS WAF ATP コンポーネント ](waf-atp-components.md) + [ # ATP でアプリケーション統合 SDK を使用 ](waf-atp-with-tokens.md) + [ # ATP マネージドルールグループを保護パック (ウェブ ACL) に追加 ](waf-atp-rg-using.md) + [ # ATP のテストとデプロイ ](waf-atp-deploying.md) + [ # AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) の例 ](waf-atp-control-examples.md) # AWS WAF ATP コンポーネント AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) の主なコンポーネントは次のとおりです。 + **`AWSManagedRulesATPRuleSet`** – この AWS マネージドルールルールグループのルールは、さまざまなタイプのアカウント乗っ取りアクティビティを検出、ラベル付け、処理します。ルールグループは、クライアントから指定したログインエンドポイントに送信される HTTP `POST` ウェブリクエストを検査します。保護された CloudFront ディストリビューションでは、ルールグループはディストリビューションがこれらのリクエストに送り返す応答も検査します。ルールグループのルールのリストについては、「[AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループ](aws-managed-rule-groups-atp.md)」を参照してください。マネージドルールグループ参照ステートメントを使用して、このルールグループを保護パック (ウェブ ACL) に含めます。このルールグループの使用については、「[ATP マネージドルールグループを保護パック (ウェブ ACL) に追加](waf-atp-rg-using.md)」を参照してください。 **注記** このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。 + **アプリケーションのログインページに関する詳細** – `AWSManagedRulesATPRuleSet` ルールグループを保護パック (ウェブ ACL) に追加する際、ログインページに関する情報を提供する必要があります。これにより、ルールグループは検査するリクエストの範囲を絞り込み、ウェブリクエストで認証情報の使用状況を適切に検証できます。ATP ルールグループは、電子メール形式のユーザー名に対応します。詳細については、「[ATP マネージドルールグループを保護パック (ウェブ ACL) に追加](waf-atp-rg-using.md)」を参照してください。 + **保護された CloudFront ディストリビューションの場合、ログイン試行に対するアプリケーションの応答方法に関する詳細** – ログイン試行に対するアプリケーションの応答に関する詳細を指定すると、ルールグループはログイン試行の失敗回数が過度に多いクライアントを追跡および管理します。このオプションの設定については、「[ATP マネージドルールグループを保護パック (ウェブ ACL) に追加](waf-atp-rg-using.md)」を参照してください。 + **JavaScript とモバイルアプリケーションの統合 SDKs** – ATP 実装を使用して AWS WAF JavaScript とモバイル SDKs を実装し、ルールグループが提供する機能の完全なセットを有効にします。ATP ルールの多くは、セッションレベルのクライアント検証および動作集約に SDK から提供された情報を使用し、正規のクライアントトラフィックをボットトラフィックから分離するために必要です。SDK の詳細については、「[でのクライアントアプリケーション統合 AWS WAF](waf-application-integration.md)」を参照してください。 ATP 実装を次と組み合わせて、保護のモニタリング、チューニング、およびカスタマイズに役立てることができます。 + **ログ記録とメトリクス** – 保護パック (ウェブ ACL) 用にログ、Amazon Security Lake データ収集と　Amazon CloudWatch メトリクスを設定して有効にすることで、トラフィックをモニタリングし、ACFP マネージドルールグループがトラフィックにどのように影響するのかを理解できます。`AWSManagedRulesATPRuleSet` がウェブリクエストに追加するラベルは、データに含まれます。オプションの詳細については、[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)、[Amazon CloudWatch によるモニタリング](monitoring-cloudwatch.md)、及び「[What is Amazon Security Lake?](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html)」を参照してください。ニーズと確認できるトラフィックに応じて、`AWSManagedRulesATPRuleSet` の実装をカスタマイズできます。たとえば、ATP 評価から一部のトラフィックを除外したり、スコープダウンステートメントやラベルマッチングルールなどの AWS WAF 機能を使用して、識別したアカウント乗っ取り試行の処理方法を変更したりできます。 + **ラベルとラベル一致ルール** – `AWSManagedRulesATPRuleSet` のどのルールでも、ブロック動作をカウントに切り替えて、ルールによって追加されたラベルと照合することができます。このアプローチを使用し、ATP マネージドルールグループによって識別されるウェブリクエストの処理方法をカスタマイズします。ラベル付けおよびラベル一致ステートメントの使用の詳細については、「[ラベル一致ルールステートメント](waf-rule-statement-type-label-match.md)」および「[でのウェブリクエストのラベル付け AWS WAF](waf-labels.md)」を参照してください。 + **カスタムリクエストとレスポンス** - 許可するリクエストにはカスタムヘッダーを追加し、ブロックするリクエストにはカスタムレスポンスを送信できます。これを行うには、ラベル一致を AWS WAF カスタムリクエストおよび応答機能とペアリングします。リクエストとレスポンスをカスタマイズする方法については、「[でカスタマイズされたウェブリクエストとレスポンス AWS WAF](waf-custom-request-response.md)」を参照してください。 # ATP でアプリケーション統合 SDK を使用このセクションでは、ATP でアプリケーション統合 SDK を使用する方法について説明します。 ATP マネージドルールグループには、アプリケーション統合 SDK が生成するチャレンジトークンが必要です。トークンは、ルールグループが提供するすべての保護を有効にします。 ATP ルールグループを最も効果的に使用するためにも、アプリケーション統合 SDK を実装することを強くお勧めします。チャレンジスクリプトが取得するトークンからのメリットを ATP ルールグループが得るには、ATP ルールグループの前にチャレンジスクリプトを実行する必要があります。アプリケーション統合 SDK を使用すると、これが自動的に行われます。SDK を使用できない場合は、代替手段として、ATP ルールグループが検査するすべてのリクエストに対して CAPTCHA または Challenge ルールアクションを実行するように保護パック (ウェブ ACL) を設定することができます。Challenge または CAPTCHA ルールアクションを使用すると、追加料金が発生する場合があります。料金の詳細については、「[AWS WAF の料金](https://aws.amazon.com/waf/pricing/)」を参照してください。 **トークンを必要としない ATP ルールグループの機能** ウェブリクエストにトークンが含まれていないときは、ATP マネージドルールグループ以下のタイプのトラフィックをブロックできます。 + 多数のログインリクエストを行う単一の IP アドレス。 + 短時間で多数の失敗したログインリクエストが行われた単一の IP アドレス。 + 同じユーザー名を使用してもパスワードを変更してパスワードトラバーサルでログイン試行。 **トークンを必要とする ATP ルールグループの機能** チャレンジトークンで提供される情報により、ルールグループとクライアントアプリケーションセキュリティ全体の機能が拡張されます。このトークンは、ウェブリクエストごとにクライアント情報を提供します。これにより、ATP ルールグループは、正規のクライアントセッションと動作の悪いクライアントセッションが両方とも単一の IP アドレスから発信された場合でも、前者を後者から分離できます。ルールグループは、トークン内の情報を使用してクライアントセッションリクエストの動作を集約し、微調整した検出および軽減を実現します。トークンがウェブリクエストで使用可能な場合、ATP ルールグループは次の追加カテゴリのクライアントをセッションレベルで検出してブロックできます。 + SDK が管理するサイレントチャレンジに失敗するクライアントセッション。 + ユーザー名またはパスワードを経由するクライアントセッション。これはクレデンシャルスタッフィングとも呼ばれます。 + 盗まれた認証情報を繰り返し使用してログインするクライアントセッション。 + ログインに長時間かかるクライアントセッション。 + 多数のログインリクエストを行うクライアントセッション。ATP ルールグループは、IP アドレスでクライアントをブロックできる AWS WAF レートベースのルールよりも優れたクライアント分離を提供します。ATP ルールグループでは、より低いしきい値も使用されています。 + 短時間で多数の失敗したログインリクエストが行われたクライアントセッション。この機能は、保護されている Amazon CloudFront ディストリビューションで利用できます。ルールグループ機能の情報については、「[AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループ](aws-managed-rule-groups-atp.md)」を参照してください。 SDK の詳細については、「[でのクライアントアプリケーション統合 AWS WAF](waf-application-integration.md)」を参照してください。 AWS WAF トークンの詳細については、「」を参照してください[AWS WAF インテリジェントな脅威の軽減におけるトークンの使用](waf-tokens.md)。ルールアクションの情報については、「[CAPTCHA および Challengeの AWS WAF](waf-captcha-and-challenge.md)」を参照してください。 # ATP マネージドルールグループを保護パック (ウェブ ACL) に追加このセクションでは、`AWSManagedRulesATPRuleSet` ルールグループを追加および設定する方法について説明します。ウェブトラフィックのアカウント乗っ取りアクティビティを認識するように ATP マネージドルールグループを設定するには、アプリケーションにログインリクエストを送信する方法に関する情報をクライアントで指定します。保護された Amazon CloudFront ディストリビューションでは、ログインリクエストに対するアプリケーションの応答方法に関する情報も指定します。この設定は、マネージドルールグループの通常の設定に追加されます。ルールグループの説明とルールリストについては、「[AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループ](aws-managed-rule-groups-atp.md)」を参照してください。 **注記** 盗まれた認証情報の ATP データベースには、E メール形式のユーザー名のみが含まれています。このガイダンスは、 AWS WAF 保護パック (ウェブ ACL)、ルール、およびルールグループを作成および管理する方法を一般的に認識しているユーザーを対象としています。これらのトピックは、このガイドの前のセクションでカバーされています。マネージドルールグループを保護パック (ウェブ ACL) に追加する方法の基本については、「[コンソールを通じた保護パック (ウェブ ACL) へのマネージドルールグループの追加](waf-using-managed-rule-group.md)」を参照してください。 **ベストプラクティスに従う** ATP ルールグループは、「[でのインテリジェントな脅威軽減のベストプラクティス AWS WAF](waf-managed-protections-best-practices.md)」に記載されているベストプラクティスに従って使用してください。 **保護パック (ウェブ ACL) で `AWSManagedRulesATPRuleSet` ルールグループを使用するには** 1. AWS マネージドルールグループを保護パック (ウェブ ACL) `AWSManagedRulesATPRuleSet`に追加し、保存する前にルールグループ設定**を編集**します。 **注記** このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。 1. **[ルールグループを設定]** ペインで、ATP ルールグループがログインリクエストの検査に使用する情報を入力します。 1. **「パスで正規表現を使用する**」で、ログインページパスの仕様に合わせて正規表現マッチング AWS WAF を実行する場合は、これをオンにします。 AWS WAF は、いくつかの例外`libpcre`を除いて、PCRE ライブラリで使用されるパターン構文をサポートします。ライブラリは、「[PCRE - Perl Compatible Regular Expressions](http://www.pcre.org/)」で文書化されています。 AWS WAF サポートの詳細については、「」を参照してください[でサポートされている正規表現構文 AWS WAF](waf-regex-pattern-support.md)。 1. **[Login path]** (ログインパス) で、アプリケーションのログインエンドポイントのパスを指定します。ルールグループは、指定されたログインエンドポイントに対する HTTP `POST` リクエストのみを検査します。 **注記** エンドポイントの照会では大文字と小文字が区別されません｡正規表現の仕様には、大文字と小文字を区別しない照合を無効にするフラグ `(?-i)` を含めてはいけません。文字列の指定はフォワードスラッシュ「`/`」で始まる必要があります。例えば、URL `https://example.com/web/login` では、文字列パスの指定「`/web/login`」を指定できます。指定したパスで始まるログインパスは一致と見なされます。例えば、`/web/login` はログインパス `/web/login`、`/web/login/`、`/web/loginPage`、および `/web/login/thisPage` に一致しますが、ログインパス `/home/web/login` または `/website/login` には一致しません。 1. **[リクエスト検査]** で、リクエストのペイロードタイプと、ユーザー名とパスワードが指定されているリクエスト本文内のフィールドの名前を指定して、アプリケーションがログイン試行を受け入れる方法を指定します。これらのフィールド名の指定は、ペイロードタイプによって異なります。 + **JSON ペイロードタイプ** – JSON Pointer 構文でフィールド名を指定します。JSON Pointer 構文の詳細については、インターネットエンジニアリングタスクフォース (IETF) ドキュメントの「[JavaScript Object Notation (JSON) Pointer](https://tools.ietf.org/html/rfc6901)」を参照してください。例えば、次の JSON ペイロードの例では、ユーザー名フィールドの指定は `/login/username` で、パスワードフィールドの指定は `/login/password` です。 ``` { "login": { "username": "THE_USERNAME", "password": "THE_PASSWORD" } } ``` + **FORM\$1ENCODED ペイロードタイプ** – HTML 形式の名前を使用します。例えば、`username1` と `password1` という名前の入力要素を持つ HTML フォームの場合、ユーザー名フィールドの指定は `username1` で、パスワードフィールドの指定は `password1` です。 1. Amazon CloudFront ディストリビューションが保護されている場合、**[レスポンス検査]** で、アプリケーションがログイン試行に対する応答で成功や失敗をどのように示すかを指定します。 **注記** ATP レスポンス検査は、CloudFront ディストリビューションが保護されている保護パック (ウェブ ACL) でのみ使用できます。 ATP で検査するログインレスポンスのコンポーネントを 1 つ指定します。**本文**および **JSON** コンポーネントタイプの場合、 AWS WAF はコンポーネントの最初の 65,536 バイト (64 KB) を検査できます。インターフェイスに示されているように、コンポーネントタイプの検査基準を指定します。コンポーネント内で検査する成功基準と失敗基準の両方を指定する必要があります。例えば、アプリケーションがログイン試行のステータスを応答のステータスコードで示し、成功の場合は「`200 OK`」、失敗の場合は「`401 Unauthorized`」または「`403 Forbidden`」を使用するとします。レスポンス検査の **[コンポーネントタイプ]** を **[ステータスコード]** に設定し、**[成功]** テキストボックスに「`200`」と入力し、**[失敗]** テキストボックスの 1 行目に「`401`」、2 行目に「`403`」と入力します。 ATP ルールグループは、成功または失敗の検査基準に一致する応答のみをカウントします。ルールグループのルールは、カウントされた応答の失敗率が過度に高いクライアントに適用されます。ルールグループのルールが正確に動作するように、ログイン試行の成功と失敗の両方に関する詳細な情報を必ず入力してください。ログインレスポンスを検査するルールを確認するには、「[AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループ](aws-managed-rule-groups-atp.md)」のルールリストで `VolumetricIpFailedLoginResponseHigh` と `VolumetricSessionFailedLoginResponseHigh` を探します。 1. ルールグループに必要な追加設定を指定します。マネージドルールグループステートメントにスコープダウンステートメントを追加することで、ルールグループが検査するリクエストの範囲をさらに限定できます。例えば、特定のクエリ引数または cookie を持つリクエストのみを検査できます。ルールグループは、スコープダウンステートメントの基準に一致する、指定したログインエンドポイントへの HTTP `POST` リクエストのみを検査します。スコープダウンステートメントの詳細については、「[でのスコープダウンステートメントの使用 AWS WAF](waf-rule-scope-down-statements.md)」を参照してください。 1. 変更を保護パック (ウェブ ACL) に保存します。本番稼働トラフィックに ATP 実装をデプロイする前に、トラフィックへの潜在的な影響に慣れるまで、ステージング環境またはテスト環境でテストおよびチューニングします。その後、ルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。ガイダンスについては、次のセクションを参照してください。 # ATP のテストとデプロイこのセクションでは、サイトの AWS WAF Fraud Control Account Takeover Prevention (ATP) 実装を設定およびテストするための一般的なガイダンスを提供します。実行する具体的なステップは、ニーズ、リソース、および受け取るウェブリクエストによって異なります。この情報は、[AWS WAF 保護のテストとチューニング](web-acl-testing.md) で提供されているテストおよび調整に関する一般情報とは別です。 **注記** AWS マネージドルールは、一般的なウェブ脅威から保護するように設計されています。ドキュメントに従って使用すると、 AWS マネージドルールルールグループはアプリケーションに別のセキュリティレイヤーを追加します。ただし、 AWS マネージドルールルールグループは、選択した AWS リソースによって決定されるセキュリティ責任に代わるものではありません。責任[共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)を参照して、のリソースが適切に保護 AWS されていることを確認します。 **本番稼働トラフィックのリスク** 本番稼働トラフィックに ATP 実装をデプロイする前に、トラフィックへの潜在的な影響に慣れるまで、ステージング環境またはテスト環境でテストおよびチューニングします。その後、ルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。 AWS WAF は、ATP 設定の検証に使用できるテスト認証情報を提供します。次の手順では、ATP マネージドルールグループを使用するようにテスト保護パック (ウェブ ACL) を設定し、ルールグループによって追加されたラベルをキャプチャするルールを設定してから、これらのテスト認証情報を使用してログイン試行を実行します。ログイン試行に関する Amazon CloudWatch メトリクスを確認して、ウェブ ACL が試行を正しく管理していることを検証します。このガイダンスは、 AWS WAF 保護パック (ウェブ ACL)、ルール、およびルールグループを作成および管理する方法を一般的に認識しているユーザーを対象としています。これらのトピックは、このガイドの前のセクションでカバーされています。 **AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) 実装を設定してテストするには** これらのステップを最初にテスト環境で実行し、次に本番環境で実行します。 1. **Fraud AWS WAF Control アカウント乗っ取り防止 (ATP) マネージドルールグループをカウントモードに追加する** **注記** このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。 AWS マネージドルールルールグループ`AWSManagedRulesATPRuleSet`を新規または既存の保護パック (ウェブ ACL) に追加し、現在の保護パック (ウェブ ACL) の動作を変更しないように設定します。このルールグループのルールとラベルの詳細については、「[AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループ](aws-managed-rule-groups-atp.md)」を参照してください。 + マネージドルールグループを追加する際には、それを編集し、次の手順を実行します。 + **[Rule group configuration]** (ルールグループを設定) ペインで、アプリケーションのログインページの詳細を入力します。ATP ルールグループは、この情報を使用してサインインアクティビティをモニタリングします。詳細については、「[ATP マネージドルールグループを保護パック (ウェブ ACL) に追加](waf-atp-rg-using.md)」を参照してください。 + **[Rules]** (ルール) ペインで、**[Override all rule actions]** (すべてのルールアクションをオーバーライド) ドロップダウンを開いて、**[Count]** を選択します。この設定では、 AWS WAF は、ルールグループ内のすべてのルールに対してリクエストを評価し、その結果の一致のみをカウントしつつ、引き続きリクエストにラベルを追加します。詳細については、「[ルールグループ内のルールアクションのオーバーライド](web-acl-rule-group-settings.md#web-acl-rule-group-rule-action-override)」を参照してください。このオーバーライドにより、ATP マネージドルールの影響をモニタリングして、例外 (内部のユースケースの例外など) を追加するかどうか判断できます。 + 保護パック (ウェブ ACL) の既存のルールの後に評価されるように、ルールグループを配置します。優先順位の設定の数値は、既に使用しているルールまたはルールグループよりも高くなります。詳細については、「[ルールの優先度を設定する](web-acl-processing-order.md)」を参照してください。これにより、現在のトラフィックの処理が中断されることはありません。例えば、SQL インジェクションやクロスサイトスクリプティングなどの悪意のあるトラフィックを検出するルールがある場合、そのルールは引き続き検出し、それをログに記録します。または、既知の悪意のないトラフィックを許可するルールがある場合、ATP マネージドルールグループによってブロックされるようにすることなく、そのトラフィックを許可し続けることができます。テストおよびチューニングのアクティビティ中に、処理順序を調整することもできます。 1. **保護パック (ウェブ ACL) のサンプリング、ログ記録、およびメトリクスの有効化** 必要に応じて、保護パック (ウェブ ACL) のログ記録、Amazon Security Lake データ収集、リクエストサンプリング、Amazon CloudWatch メトリクスを設定します。これらの可視化ツールを使用して ATP マネージドルールグループとトラフィックとのインタラクションをモニタリングできます。 + ログ記録の設定と使用については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。 + Amazon Security Lake の詳細については、[「Amazon Security Lake とは](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html)」および*「Amazon Security Lake* [ユーザーガイド」の AWS 「サービスからのデータ収集](https://docs.aws.amazon.com/security-lake/latest/userguide/internal-sources.html)」を参照してください。 + Amazon CloudWatch メトリクスの詳細については、「[Amazon CloudWatch によるモニタリング](monitoring-cloudwatch.md)」を参照してください。 + ウェブリクエストサンプリングの詳細については、「[ウェブリクエストのサンプルの表示](web-acl-testing-view-sample.md)」を参照してください。 1. **保護パック (ウェブ ACL) をリソースに関連付ける** 保護パック (ウェブ ACL) がテストリソースに関連付けられていない場合は、関連付けます。詳細については、「[AWS リソースとの保護の関連付けまたは関連付け解除](web-acl-associating-aws-resource.md)」を参照してください。 1. **トラフィックと ATP ルールの一致をモニタリングする** 通常のトラフィックがフローしていることと、ATP マネージドルールグループのルールが一致するウェブリクエストにラベルを追加していることを確認します。ログにラベルが表示され、Amazon CloudWatch メトリクスで ATP とラベルのメトリクスを確認できます。ログでは、ルールグループでカウントするようにオーバーライドしたルールが、カウントに設定された `action` と、オーバーライドした設定済のルールアクションを示す `overriddenAction` とともに、`ruleGroupList` に表示されます。 1. **ルールグループの認証情報チェック機能をテストする** テスト用の侵害された認証情報を使用してログインを試行し、ルールグループが想定どおりに照合することを確認します。 1. 次の AWS WAF テスト認証情報ペアを使用して、保護されたリソースのログインページにログインします。 + ユーザー: `WAF_TEST_CREDENTIAL@wafexample.com` + パスワード: `WAF_TEST_CREDENTIAL_PASSWORD` これらのテスト認証情報は侵害された認証情報として分類され、ATP マネージドルールグループはログインリクエストに `awswaf:managed:aws:atp:signal:credential_compromised` ラベル (ログでの確認が可能) を追加します。 1. 保護パック (ウェブ ACL) ログで、テストログインウェブリクエストのログエントリの `labels` フィールドで `awswaf:managed:aws:atp:signal:credential_compromised` ラベルを探します。ログ作成の詳細については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。侵害された認証情報をルールグループが想定どおりにキャプチャすることを検証したら、保護されたリソースに必要な実装を設定するステップを実行できます。 1. **CloudFront ディストリビューションで、ルールグループのログイン失敗管理をテストする** 1. ATP ルールグループに設定した応答の失敗基準それぞれに対してテストを実行します。テストとテストの間は 10 分以上あけてください。単一の失敗基準をテストするには、その条件で失敗するログイン試行を応答内で特定します。次に、単一のクライアント IP アドレスからの失敗したログイン試行を、10 分以内に少なくとも 10 回実行します。最初の 6 回の試行が失敗した後、ボリューメトリックが失敗したログインルールが、残りのログイン試行に対する一致、ラベル付け、およびカウントを開始します。レイテンシーにより、ルールで最初の 1 回または 2 回が見逃される可能性があります。 1. 保護パック (ウェブ ACL) ログで、テストログインウェブリクエストのログエントリの `labels` フィールドで `awswaf:managed:aws:atp:aggregate:volumetric:ip:failed_login_response:high` ラベルを探します。ログ作成の詳細については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。これらのテストでは、失敗したログイン回数がルール `VolumetricIpFailedLoginResponseHigh` のしきい値を超えているかどうかをチェックして、失敗基準が応答に一致しているかどうかを検証します。しきい値に達した後も同じ IP アドレスからログインリクエストを送信し続けると、失敗率がしきい値を下回るまでルールによる一致が継続されます。しきい値を超えている間、ルールは IP アドレスからの成功したログインと失敗したログインの両方に一致させます。 1. **ATP ウェブリクエストの処理をカスタマイズする** 必要に応じて、リクエストを明示的に許可またはブロックする独自のルールを追加して、ATP ルールがそのリクエストを処理する方法を変更します。例えば、ATP ラベルを使用して、リクエストを許可またはブロックしたり、リクエスト処理をカスタマイズしたりできます。ATP マネージドルールグループの後にラベル一致ルールを追加して、適用する処理のためにラベル付きリクエストをフィルタリングできます。テスト後、関連する ATP ルールをカウントモードで維持し、カスタムルールでリクエストの処理に関する決定を維持します。例については、[ATP の例: 認証情報の不足および侵害された認証情報のカスタム処理](waf-atp-control-example-user-agent-exception.md)を参照してください。 1. **テストルールを削除し、ATP マネージドルールグループ設定を有効にする** 状況によっては、一部の ATP ルールをカウントモードのままにすると判断していた可能性もあります。ルールグループ内で設定したとおりに実行するルールについては、保護パック (ウェブ ACL) ルールグループ設定でカウントモードを無効にします。テストが終了したら、テストラベル一致ルールを削除することもできます。 1. **モニタリングおよびチューニング** ウェブリクエストが希望どおりに処理されていることを確認するには、使用することを希望する ATP 機能を有効にした後、トラフィックを注意深くモニタリングします。ルールグループに対するルールカウントの上書きと独自のルールを使用して、必要に応じて動作を調整します。 ATP ルールグループの実装のテストが終了した後、まだ行っていない場合は、検出機能を強化するために、 AWS WAF JavaScript SDK をブラウザのログインページに統合することを強くお勧めします。には、iOS デバイスと Android デバイスを統合するモバイル SDKs AWS WAF も用意されています。統合 SDK の詳細については、「[でのクライアントアプリケーション統合 AWS WAF](waf-application-integration.md)」を参照してください。このレコメンデーションについては、「[ATP でアプリケーション統合 SDK を使用](waf-atp-with-tokens.md)」を参照してください。 # AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) の例このセクションでは、 AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) の実装の一般的なユースケースに対応できる設定例を示します。各例は、ユースケースの説明を提供し、カスタム設定ルールの JSON リストにそのソリューションを示します。 **注記** これらの例に示されているような JSON リストは、コンソール保護パック (ウェブ ACL) JSON ダウンロードやルール JSON エディタを介して、または API やコマンドラインインターフェイスでの `getWebACL` オペレーションを介して取得できます。 **Topics** + [ # ATP の例: シンプルな設定 ](waf-atp-control-example-basic.md) + [ # ATP の例: 認証情報の不足および侵害された認証情報のカスタム処理 ](waf-atp-control-example-user-agent-exception.md) + [ # ATP の例: レスポンス検査の設定 ](waf-atp-control-example-response-inspection.md) # ATP の例: シンプルな設定次の JSON リストは、 AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) マネージドルールグループを使用した保護パック (ウェブ ACL) の例を示しています。追加のサインインページ設定は、ルールグループがログインリクエストをモニタリングおよび管理するために必要な情報を提供することにご注意ください。この JSON には、ラベル名前空間や保護パック (ウェブ ACL) のアプリケーション統合 URL など、保護パック (ウェブ ACL) の自動生成された設定が含まれます。 ``` { "WebACL": { "LabelNamespace": "awswaf:111122223333:webacl:ATPModuleACL:", "Capacity": 50, "Description": "This is a test protection pack (web ACL) for ATP.", "Rules": [ { "Priority": 1, "OverrideAction": { "None": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AccountTakeOverValidationRule" }, "Name": "DetectCompromisedUserCredentials", "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesATPRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesATPRuleSet": { "LoginPath": "/web/login", "RequestInspection": { "PayloadType": "JSON", "UsernameField": { "Identifier": "/form/username" }, "PasswordField": { "Identifier": "/form/password" } }, "EnableRegexInPath": false } } ] } } } ], "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "ATPValidationAcl" }, "DefaultAction": { "Allow": {} }, "ManagedByFirewallManager": false, "RetrofittedByFirewallManager": false, "Id": "32q10987-65rs-4tuv-3210-98765wxyz432", "ARN": "arn:aws:wafv2:us-east-1:111122223333:regional/webacl/ATPModuleACL/32q10987-65rs-4tuv-3210-98765wxyz432", "Name": "ATPModuleACL" }, "ApplicationIntegrationURL": "https://9z87abce34ea.us-east-1.sdk.awswaf.com/9z87abce34ea/1234567a1b10/", "LockToken": "6d0e6966-95c9-48b6-b51d-8e82e523b847" } ``` # ATP の例: 認証情報の不足および侵害された認証情報のカスタム処理デフォルトでは、ルールグループ `AWSManagedRulesATPRuleSet` によって実行される認証情報チェックは次のようにウェブリクエストを処理します。 + **認証情報の不足** – リクエストにラベルを付けてブロックします。 + **[Compromised credentials]** (侵害された認証情報) - リクエストにラベルを付けますが、ブロックしたりカウントしたりしません。ルールグループとルールの動作の詳細については、「[AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループ](aws-managed-rule-groups-atp.md)」を参照してください。次の手順を実行して、認証情報が不足している、または侵害されたウェブリクエストのカスタム処理を追加できます。 + **`MissingCredential` ルールを Count にオーバーライド** — このルールアクションのオーバーライドにより、ルールは一致するリクエストをカウントしてラベル付けのみします。 + **カスタム処理でラベル一致ルールの追加** – 両方の ATP ラベルと照合し、カスタム処理を実行するようにルールを設定します。例えば、顧客をサインアップページにリダイレクトできます。次のルールは、`MissingCredential` ルールアクションがカウントするようにオーバーライドされた状態で、前の例の ATP マネージドルールグループを示しています。これにより、ルールはリクエストをブロックするのではなく、一致するリクエストにラベルを適用し、リクエストのみをカウントします。 ``` "Rules": [ { "Priority": 1, "OverrideAction": { "None": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AccountTakeOverValidationRule" }, "Name": "DetectCompromisedUserCredentials", "Statement": { "ManagedRuleGroupStatement": { "ManagedRuleGroupConfigs": [ { "AWSManagedRulesATPRuleSet": { "LoginPath": "/web/login", "RequestInspection": { "PayloadType": "JSON", "UsernameField": { "Identifier": "/form/username" }, "PasswordField": { "Identifier": "/form/password" } }, "EnableRegexInPath": false } } ] "VendorName": "AWS", "Name": "AWSManagedRulesATPRuleSet", "RuleActionOverrides": [ { "ActionToUse": { "Count": {} }, "Name": "MissingCredential" } ], "ExcludedRules": [] } } } ], ``` この設定では、このルールグループは、認証情報が不足し、または侵害されたウェブリクエストを評価すると、リクエストにラベルを付けますが、ブロックすることはありません。次のルールは、前のルールグループよりも優先順位が高く設定されています。 AWS WAF は、優先順位の低いルールから順番に評価するため、このルールはルールグループの後に評価されます。認証情報のラベルのどちらかと照合し、一致するリクエストにカスタムレスポンスを送信するようにルールが設定されています。 ``` "Name": "redirectToSignup", "Priority": 10, "Statement": { "OrStatement": { "Statements": [ { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:atp:signal:missing_credential" } }, { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:atp:signal:credential_compromised" } } ] } }, "Action": { "Block": { "CustomResponse": { your custom response settings } } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "redirectToSignup" } ``` # ATP の例: レスポンス検査の設定次の JSON リストは、オリジンレスポンスを検査するように設定された AWS WAF Fraud Control Account Takeover Prevention (ATP) マネージドルールグループを含む保護パック (ウェブ ACL) の例を示しています。成功とレスポンスステータスコードを指定する応答検査設定を注意してください。ヘッダー、ボディ、ボディの JSON 一致に基づいて成功とレスポンスの設定を構成することもできます。この JSON には、ラベル名前空間や保護パック (ウェブ ACL) のアプリケーション統合 URL など、保護パック (ウェブ ACL) の自動生成された設定が含まれます。 **注記** ATP レスポンス検査は、CloudFront ディストリビューションが保護されている保護パック (ウェブ ACL) でのみ使用できます。 ``` { "WebACL": { "LabelNamespace": "awswaf:111122223333:webacl:ATPModuleACL:", "Capacity": 50, "Description": "This is a test protection pack (web ACL) for ATP.", "Rules": [ { "Priority": 1, "OverrideAction": { "None": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AccountTakeOverValidationRule" }, "Name": "DetectCompromisedUserCredentials", "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesATPRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesATPRuleSet": { "LoginPath": "/web/login", "RequestInspection": { "PayloadType": "JSON", "UsernameField": { "Identifier": "/form/username" }, "PasswordField": { "Identifier": "/form/password" } }, "ResponseInspection": { "StatusCode": { "SuccessCodes": [ 200 ], "FailureCodes": [ 401 ] } }, "EnableRegexInPath": false } } ] } } } ], "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "ATPValidationAcl" }, "DefaultAction": { "Allow": {} }, "ManagedByFirewallManager": false, "RetrofittedByFirewallManager": false, "Id": "32q10987-65rs-4tuv-3210-98765wxyz432", "ARN": "arn:aws:wafv2:us-east-1:111122223333:regional/webacl/ATPModuleACL/32q10987-65rs-4tuv-3210-98765wxyz432", "Name": "ATPModuleACL" }, "ApplicationIntegrationURL": "https://9z87abce34ea.us-east-1.sdk.awswaf.com/9z87abce34ea/1234567a1b10/", "LockToken": "6d0e6966-95c9-48b6-b51d-8e82e523b847" } ``` # AWS WAF ボットコントロールこのセクションでは、Bot Control の仕様について説明します。 Bot Control を使用すると、スクレーパー、スキャナ、クローラ、ステータスモニター、検索エンジンなどのボットを簡単にモニタリング、ブロック、レート制限の適用ができます。ルールグループの対象検査レベルを使用する場合、自己識別しないボットにチャレンジを仕掛けることができるため、悪意のあるボットがウェブサイトを狙うことが難しくなり、ボットの運用コストも高くなります。Bot Control マネージドルールグループのみを使用するか、他の AWS マネージドルールルールグループや独自のカスタム AWS WAF ルールと組み合わせてアプリケーションを保護することができます。 Bot Control には、リクエストサンプリングに基づいて、ボットからの現在のトラフィックの量を示すコンソールダッシュボードが含まれています。Bot Control マネージドルールグループを保護パック (ウェブ ACL) に追加すると、ボットトラフィックに対してアクションを実行したり、アプリケーションへの一般的なボットトラフィックに関する詳細なリアルタイム情報を受け取ったりすることができます。 **注記** このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。 Bot Control マネージドルールグループには、自己識別ボットにラベルを追加、一般的に望ましいボットを検証、信頼度の高いボットシグネチャを検出する基本かつ共通の保護レベルが用意されています。これにより、ボットトラフィックの共通カテゴリをモニタリングおよび制御できます。 Bot Control ルールグループには、自己識別を行わない高度なボットに対する検出機能が追加された、ターゲットを絞った保護レベルも用意されています。ターゲットを絞った保護では、ブラウザ調査、フィンガープリント、行動ヒューリスティックなどの検出技術を使用して不正なボットトラフィックを識別します。さらに、ターゲットを絞った保護では、ウェブサイトのトラフィック統計を機械学習で自動的に分析して、ボット関連のアクティビティを検出することもできます。機械学習を有効にすると、 AWS WAF はタイムスタンプ、ブラウザの特性、以前にアクセスした URL など、ウェブサイトのトラフィックに関する統計を使用して Bot Control の機械学習モデルを改善します。が Bot Control マネージドルールグループに対してウェブリクエスト AWS WAF を評価すると、ルールグループはボット関連として検出したリクエストにラベルを追加します。たとえば、ボットのカテゴリやボット名などです。独自の AWS WAF ルールでこれらのラベルと照合して、処理をカスタマイズできます。Bot Control マネージドルールグループによって生成されるラベルは、Amazon CloudWatch メトリクスと保護パック (ウェブ ACL) ログに含まれます。 AWS Firewall Manager AWS WAF ポリシーを使用して、組織の一部である複数のアカウントのアプリケーション全体に Bot Control マネージドルールグループをデプロイすることもできます AWS Organizations。 Bot Control マネージドルールグループの詳細については、「[AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md)」を参照してください。 ## AI エージェントのウェブボット認証 AWS WAF Bot Control は、CloudFront ディストリビューションにアクセスするボットと AI エージェントの暗号化検証方法としてウェブボット認証 (WBA) をサポートするようになりました。この機能により、正当な AI クローラとエージェントは、従来のチャレンジレスポンスメカニズムを必要とせずにアイデンティティを証明できます。バージョン要件: `AWSManagedRulesBotControlRuleSet` Version\$14.0 以降。(静的バージョンは明示的に選択する必要があります）。ラベル分類とルールの動作の詳細については、以下を参照してください。 + [AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md) + [でのウェブリクエストのラベル付け AWS WAF](waf-labels.md) + [AWS マネージドルールの変更ログ](aws-managed-rule-groups-changelog.md) # AWS WAF Bot Control コンポーネント Bot Control の実装の主なコンポーネントは次のとおりです。 + **`AWSManagedRulesBotControlRuleSet`** – さまざまなカテゴリのボットを検出して処理するルールを持つ Bot Control マネージドルールグループ。このルールグループは、ボットトラフィックとして検出されたウェブリクエストにラベルを追加します。 **注記** このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。 Bot Control マネージドルールグループには、次の 2 レベルの保護から選択できます。 + **共通** – ウェブスクレイピングフレームワーク、検索エンジン、自動ブラウザなど、さまざまな自己識別ボットを検出します。このレベルの Bot Control 保護は、静的リクエストデータ分析など、従来のボット検出技術を使用して一般的なボットを識別します。ルールはこれらのボットからのトラフィックにラベルを付け、検証できないものはブロックします。 + **ターゲットを絞った** – 一般的な保護機能に加え、自己識別を行わない高度なボットに対するターゲットを絞った検出機能も追加されています。ターゲットを絞った保護は、レート制限と CAPTCHA およびバックグラウンドブラウザのチャレンジの組み合わせを使用してボットアクティビティを軽減します。 + **`TGT_`** – ターゲットを絞った保護を提供するルールには、`TGT_` で始まる名前が付いています。すべてのターゲットを絞った保護では、ブラウザ調査、フィンガープリント、行動ヒューリスティックなどの検出技術を使用して不正なボットトラフィックを識別します。 + **`TGT_ML_`** – 機械学習を使用するターゲットを絞った保護のルールには、`TGT_ML_` で始まる名前が付いています。これらのルールでは、ウェブサイトトラフィック統計の自動機械学習分析を使用して、分散された調整されたボットアクティビティを示す異常な動作を検出します。は、タイムスタンプ、ブラウザの特性、以前にアクセスした URL などのウェブサイトトラフィックに関する統計 AWS WAF を分析し、Bot Control 機械学習モデルを改善します。機械学習機能はデフォルトで有効になっていますが、ルールグループ設定で無効にすることができます。機械学習が無効になっている場合、 AWS WAF はこれらのルールを評価しません。ルールグループルールに関する情報を含む詳細については、「[AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md)」を参照してください。マネージドルールグループ参照ステートメントを使用して、このルールグループを保護パック (ウェブ ACL) に含め、使用する検査レベルを指定します。ターゲットレベルでは、機械学習を有効にするかどうかも指定します。このマネージドルールグループを保護パック (ウェブ ACL) に追加する方法については、「[AWS WAF Bot Control マネージドルールグループをウェブ ACL に追加する](waf-bot-control-rg-using.md)」を参照してください。 + **[Bot Control dashboard]** (Bot Control ダッシュボード) – 保護パック (ウェブ ACL) のボットモニタリングダッシュボード。保護パック (ウェブ ACL) Bot Control のタブから利用できます。トラフィックをモニタリングし、さまざまなタイプのボットからのトラフィックの量を理解するために、このダッシュボードを使用します。これは、このトピックで説明するように、ボット管理をカスタマイズするための開始点とすることができます。また、これを使用して、変更を検証し、さまざまなボットやボットカテゴリのアクティビティをモニタリングすることもできます。 + **AI トラフィック分析ダッシュボード** – 詳細な AI ボットとエージェントのアクティビティ分析専用のダッシュボード。保護パック (ウェブ ACL) AI トラフィック分析タブから入手できます。標準の Bot Control メトリクスを超えた AI 固有のトラフィックパターン、ボットインテント、アクセス動作の可視性を強化します。 + **JavaScript とモバイルアプリケーションの統合 SDKs** – Bot Control ルールグループのターゲットを絞った保護レベルを使用する場合は、 AWS WAF JavaScript とモバイル SDKs を実装する必要があります。ターゲットルールは、クライアントトークン内で SDK から提供された情報を使用し、悪意のあるボットに対する検出を強化します。SDK の詳細については、「[でのクライアントアプリケーション統合 AWS WAF](waf-application-integration.md)」を参照してください。 + **ログ記録とメトリクス** – AWS WAF ログ、Amazon Security Lake、Amazon CloudWatch で保護パック (ウェブ ACL) 用に収集されたデータを調査することで、ボットトラフィックをモニタリングし、Bot Control マネージドルールグループがトラフィックを評価して処理する方法を理解できます。Bot Control がウェブリクエストに追加するラベルは、そのデータに含まれています。これらのオプションの詳細については、[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)、[Amazon CloudWatch によるモニタリング](monitoring-cloudwatch.md)、及び「[What is Amazon Security Lake?](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html)」を参照してください。ニーズと確認できるトラフィックに応じて、Bot Control の実装をカスタマイズできます。最も一般的に使用されるオプションの一部は次のとおりです。 + **スコープダウンステートメント** – Bot Control マネージドルールグループの参照ステートメント内にスコープダウンステートメントを追加することにより、Bot Control マネージドルールグループが評価するウェブリクエストからの一部トラフィックを除外できます。スコープダウンステートメントは、ネスト可能なルールステートメントとすることができます。リクエストがスコープダウンステートメントと一致しない場合、は、ルールグループに対して AWS WAF 評価せずに、ルールグループ参照ステートメントと一致していないと評価します。スコープダウンステートメントの詳細については、「[でのスコープダウンステートメントの使用 AWS WAF](waf-rule-scope-down-statements.md)」を参照してください。 Bot Control マネージドルールグループを使用するためのコストは、 AWS WAF がルールグループを使用して評価するウェブリクエスト数に応じて上がります。スコープダウンステートメントを使用してルールグループが評価するリクエストを制限することで、これらのコストを削減できます。たとえば、ボットを含むすべてのユーザーにホームページのロードを許可し、その後にアプリケーション API に送信されるリクエスト、あるいは特定のタイプのコンテンツを含むリクエストにルールグループのルールを適用できます。 + **ラベルとラベル一致ルール** – Bot Control ルールグループが AWS WAF ラベル一致ルールステートメントを使用して識別するボットトラフィックの一部を処理する方法をカスタマイズできます。Bot Control ルールグループは、ウェブリクエストにラベルを追加します。Bot Control ラベルと一致する Bot Control ルールグループの後にラベル一致ルールを追加し、必要な処理を適用できます。ラベル付けおよびラベル一致ステートメントの使用の詳細については、「[ラベル一致ルールステートメント](waf-rule-statement-type-label-match.md)」および「[でのウェブリクエストのラベル付け AWS WAF](waf-labels.md)」を参照してください。 + **カスタムリクエストとレスポンス** – カスタムヘッダーを許可したリクエストに追加し、ラベルマッチングをカスタムリクエストとレスポンス機能と組み合わせることで、ブロックしたリクエストに対して AWS WAF カスタムレスポンスを送信できます。リクエストとレスポンスをカスタマイズする方法については、「[でカスタマイズされたウェブリクエストとレスポンス AWS WAF](waf-custom-request-response.md)」を参照してください。 # Bot Control のアプリケーション統合 SDK の使用このセクションでは、アプリケーション統合 SDK を Bot Control で使用する方法について説明します。 Bot Control マネージドルールグループのターゲット保護のほどんどには、アプリケーション統合 SDK が生成するチャレンジトークンが必要です。リクエストにチャレンジトークンを必要としないルールは、Bot Control の共通レベルの保護とターゲットレベルの機械学習ルールです。ルールグループの保護レベルとルールの説明については、「[AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md)」を参照してください。 Bot Control ルールグループを最も効果的に使用するためにも、アプリケーション統合 SDK を実装することを強くお勧めします。チャレンジスクリプトが取得するトークンからのメリットを Bot Control ルールグループが得るには、Bot Control ルールグループの前にチャレンジスクリプトを実行する必要があります。 + アプリケーション統合 SDK では、スクリプトは自動的に実行されます。 + SDK を使用できない場合は、Bot Control ルールグループが検査するすべてのリクエストに対して Challenge または CAPTCHA ルールアクションを実行するように保護パック (ウェブ ACL) を設定することができます。Challenge または CAPTCHA ルールアクションを使用すると、追加料金が発生する場合があります。料金の詳細については、「[AWS WAF の料金](https://aws.amazon.com/waf/pricing/)」を参照してください。アプリケーション統合 SDK をクライアントに実装、またはチャレンジスクリプトを実行するルールアクションの 1 つを使用するときは、ルールグループと、クライアントアプリケーションセキュリティ全体の機能が拡張されます。トークンは、各ウェブリクエストでクライアント情報を提供します。この追加情報により、Bot Control のルールグループは、正規のクライアントセッションと動作の悪いクライアントセッションが両方とも単一の IP アドレスから発信された場合でも、前者を後者から分離できます。ルールグループは、トークン内の情報を使用してクライアントセッションリクエストの動作を集約し、ターゲットを絞った保護レベルが提供する微調整した検出および軽減を実現します。 SDK の詳細については、「[でのクライアントアプリケーション統合 AWS WAF](waf-application-integration.md)」を参照してください。 AWS WAF トークンの詳細については、「」を参照してください[AWS WAF インテリジェントな脅威の軽減におけるトークンの使用](waf-tokens.md)。ルールアクションの情報については、「[CAPTCHA および Challengeの AWS WAF](waf-captcha-and-challenge.md)」を参照してください。 # AWS WAF Bot Control マネージドルールグループをウェブ ACL に追加するこのセクションでは、`AWSManagedRulesBotControlRuleSet` ルールグループを追加および設定する方法について説明します。 Bot Control マネージドルールグループ `AWSManagedRulesBotControlRuleSet` は、実装する保護レベルを特定するための追加設定が必要です。ルールグループの説明とルールリストについては、「[AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md)」を参照してください。このガイダンスは、 AWS WAF 保護パック (ウェブ ACL)、ルール、およびルールグループを作成および管理する方法を一般的に認識しているユーザーを対象としています。これらのトピックは、このガイドの前のセクションでカバーされています。マネージドルールグループを保護パック (ウェブ ACL) に追加する方法の基本については、「[コンソールを通じた保護パック (ウェブ ACL) へのマネージドルールグループの追加](waf-using-managed-rule-group.md)」を参照してください。 **ベストプラクティスに従う** Bot Control ルールグループは、「[でのインテリジェントな脅威軽減のベストプラクティス AWS WAF](waf-managed-protections-best-practices.md)」に記載されているベストプラクティスに従って使用してください。 **保護パック (ウェブ ACL) で `AWSManagedRulesBotControlRuleSet` ルールグループを使用するには** 1. AWS マネージドルールグループを保護パック (ウェブ ACL) `AWSManagedRulesBotControlRuleSet`に追加します。ルールグループの詳細な説明については、「[AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md)」を参照してください。 **注記** このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。ルールグループを追加する際は、ルールグループの設定ページを開くように編集します。 1. ルールグループの設定ページの **[Inspection level]** (検査レベル) ペインで、使用する検査レベルを選択します。 + **共通** – ウェブスクレイピングフレームワーク、検索エンジン、自動ブラウザなど、さまざまな自己識別ボットを検出します。このレベルの Bot Control 保護は、静的リクエストデータ分析など、従来のボット検出技術を使用して一般的なボットを識別します。ルールはこれらのボットからのトラフィックにラベルを付け、検証できないものはブロックします。 + **ターゲットを絞った** – 一般的な保護機能に加え、自己識別を行わない高度なボットに対するターゲットを絞った検出機能も追加されています。ターゲットを絞った保護は、レート制限と CAPTCHA およびバックグラウンドブラウザのチャレンジの組み合わせを使用してボットアクティビティを軽減します。 + **`TGT_`** – ターゲットを絞った保護を提供するルールには、`TGT_` で始まる名前が付いています。すべてのターゲットを絞った保護では、ブラウザ調査、フィンガープリント、行動ヒューリスティックなどの検出技術を使用して不正なボットトラフィックを識別します。 + **`TGT_ML_`** – 機械学習を使用するターゲットを絞った保護のルールには、`TGT_ML_` で始まる名前が付いています。これらのルールでは、ウェブサイトトラフィック統計の自動機械学習分析を使用して、分散された調整されたボットアクティビティを示す異常な動作を検出します。は、タイムスタンプ、ブラウザの特性、以前にアクセスした URL などのウェブサイトトラフィックに関する統計 AWS WAF を分析し、Bot Control 機械学習モデルを改善します。機械学習機能はデフォルトで有効になっていますが、ルールグループ設定で無効にすることができます。機械学習が無効になっている場合、 AWS WAF はこれらのルールを評価しません。 1. ターゲットを絞った保護レベルを使用していて、ウェブトラフィックの分析に機械学習 (ML) AWS WAF を使用しない場合は、機械学習オプションを無効にします。名前が `TGT_ML_` で始まる Bot Control ルールでは機械学習が必要になります。これらのルールの詳細については、「[Bot Control のルールリスト](aws-managed-rule-groups-bot.md#aws-managed-rule-groups-bot-rules)」を参照してください。 1. ルールグループの使用コストを抑えるスコープダウンステートメントを追加します。スコープダウンステートメントは、ルールグループが検査する一連のリクエストを絞り込みます。ユースケースの例として、[Bot Control の例: ログインページにのみ Bot Control を使用します](waf-bot-control-example-scope-down-login.md) および [Bot Control の例: 動的コンテンツにのみ Bot Control を使用する](waf-bot-control-example-scope-down-dynamic-content.md) で始めてください。 1. ルールグループに必要な追加設定を指定します。 1. 変更を保護パック (ウェブ ACL) に保存します。本番稼働トラフィックに Bot Control 実装をデプロイする前に、トラフィックへの潜在的な影響に慣れるまで、ステージング環境またはテスト環境でテストおよびチューニングします。その後、ルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。ガイダンスについては、次のセクションを参照してください。 # AWS WAF Bot Control を使用した誤検出のシナリオ例このセクションでは、 AWS WAF Bot Control で誤検出が発生する可能性のある状況の例を示します。誤検出を最小限に抑えるために、 AWS WAF Bot Control マネージドルールグループのルールを慎重に選択しました。グローバルトラフィックに対してルールをテストし、テスト保護パック (ウェブ ACL) に対する影響をモニタリングします。ただし、トラフィックパターンの変化が原因で誤検出が引き続き検出されることがあります。さらに、一部のユースケースは誤検出を引き起こすことが知られており、ウェブトラフィックに特化したカスタマイズが必要になります。誤検出が発生する可能性のある状況には、次のような例が含まれます。 + 通常、モバイルアプリにはブラウザ以外のユーザーエージェントがあり、`SignalNonBrowserUserAgent` ルールではデフォルトでブロックされます。モバイルアプリからのトラフィックや、ブラウザ以外のユーザーエージェントによるその他の正当なトラフィックが予想される場合は、例外を追加して許可する必要があります。 + アップタイムのモニタリング、統合テスト、マーケティングツールなど、特定のボットトラフィックに依拠する場合があります。許可するボットトラフィックを Bot Control が識別してブロックする場合は、独自のルールを追加して処理を変更する必要があります。これは必ずしもすべてのお客様の誤検出のシナリオではありませんが、誤検出のシナリオに該当する場合、誤検出の場合と同じ処理が必要になります。 + Bot Control マネージドルールグループは、IP アドレスを使用してボットを検証します AWS WAF。Bot Control を使用し、プロキシまたはロードバランサーを介してルーティングするボットを検証した場合は、カスタムルールを使用して明示的に許可する必要がある場合があります。このタイプのカスタムルールを作成する方法については、「[で転送された IP アドレスを使用する AWS WAF](waf-rule-statement-forwarded-ip-address.md)」を参照してください。 + グローバルに誤検出率が低い Bot Control ルールが特定のデバイスまたはアプリケーションに大きな影響を与える可能性があります。例えば、テストや検証では、トラフィック量の少ないアプリケーションや、あまり一般的でないブラウザまたはデバイスからのリクエストが観察されなかった可能性があります。 + 以前から誤検出率が低い Bot Control ルールで有効なトラフィックの誤検出が増加している可能性があります。これは、新しいトラフィックパターンまたは有効なトラフィックを伴って出現するリクエスト属性が原因となっている可能性があります。これにより、以前は存在していなかったルールと一致するようになる可能性があります。これらの変更は、次のような状況によって発生する可能性があります。 + ロードバランサーやコンテンツ配信ネットワーク (CDN) など、ネットワークアプライアンスを通じてトラフィックがフローする際に変更されたトラフィックの詳細。 + トラフィックデータの新たな変化 (新しいブラウザや既存のブラウザの新しいバージョンなど)。 AWS WAF Bot Control マネージドルールグループから発生する可能性のある誤検出を処理する方法については、後のセクション「[AWS WAF Bot Control のテストとデプロイ](waf-bot-control-deploying.md)」のガイダンスを参照してください。 # AWS WAF Bot Control のテストとデプロイこのセクションでは、サイトの AWS WAF Bot Control 実装を設定およびテストするための一般的なガイダンスを提供します。実行する具体的なステップは、ニーズ、リソース、受け取るウェブリクエストによって異なります。この情報は、[AWS WAF 保護のテストとチューニング](web-acl-testing.md) で提供されているテストおよび調整に関する一般情報とは別です。 **注記** AWS マネージドルールは、一般的なウェブ脅威から保護するように設計されています。ドキュメントに従って使用すると、 AWS マネージドルールルールグループはアプリケーションに別のセキュリティレイヤーを追加します。ただし、 AWS マネージドルールルールグループは、選択した AWS リソースによって決定されるセキュリティ責任に代わるものではありません。責任[共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)を参照して、のリソースが適切に保護 AWS されていることを確認します。 **本番稼働トラフィックのリスク** 本番稼働トラフィックに Bot Control 実装をデプロイする前に、トラフィックへの潜在的な影響に慣れるまで、ステージング環境またはテスト環境でテストおよびチューニングします。その後、ルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。このガイダンスは、 AWS WAF 保護パック (ウェブ ACL)、ルール、およびルールグループを作成および管理する方法を一般的に認識しているユーザーを対象としています。これらのトピックは、このガイドの前のセクションでカバーされています。 **Bot Control の実装を設定およびテストするには** これらのステップを最初にテスト環境で実行し、次に本番環境で実行します。 1. **Bot Control マネージドルールグループを追加する** **注記** このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。マネージド AWS ルールグループ`AWSManagedRulesBotControlRuleSet`を新規または既存の保護パック (ウェブ ACL) に追加し、現在の保護パック (ウェブ ACL) の動作を変更しないように設定します。 + マネージドルールグループを追加する際には、それを編集し、次の手順を実行します。 + **[Inspection level]** (検査レベル) ペインで、使用する検査レベルを選択します。 + **共通** – ウェブスクレイピングフレームワーク、検索エンジン、自動ブラウザなど、さまざまな自己識別ボットを検出します。このレベルの Bot Control 保護は、静的リクエストデータ分析など、従来のボット検出技術を使用して一般的なボットを識別します。ルールはこれらのボットからのトラフィックにラベルを付け、検証できないものはブロックします。 + **ターゲットを絞った** – 一般的な保護機能に加え、自己識別を行わない高度なボットに対するターゲットを絞った検出機能も追加されています。ターゲットを絞った保護は、レート制限と CAPTCHA およびバックグラウンドブラウザのチャレンジの組み合わせを使用してボットアクティビティを軽減します。 + **`TGT_`** – ターゲットを絞った保護を提供するルールには、`TGT_` で始まる名前が付いています。すべてのターゲットを絞った保護では、ブラウザ調査、フィンガープリント、行動ヒューリスティックなどの検出技術を使用して不正なボットトラフィックを識別します。 + **`TGT_ML_`** – 機械学習を使用するターゲットを絞った保護のルールには、`TGT_ML_` で始まる名前が付いています。これらのルールでは、ウェブサイトトラフィック統計の自動機械学習分析を使用して、分散された調整されたボットアクティビティを示す異常な動作を検出します。は、タイムスタンプ、ブラウザの特性、以前にアクセスした URL などのウェブサイトトラフィックに関する統計 AWS WAF を分析し、Bot Control 機械学習モデルを改善します。機械学習機能はデフォルトで有効になっていますが、ルールグループ設定で無効にすることができます。機械学習が無効になっている場合、 AWS WAF はこれらのルールを評価しません。この選択の詳細については、「[AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md)」を参照してください。 + **[Rules]** (ルール) ペインで、**[Override all rule actions]** (すべてのルールアクションをオーバーライド) ドロップダウンを開いて、**[Count]** を選択します。この設定では、はルールグループ内のすべてのルールに対するリクエスト AWS WAF を評価し、その結果の一致のみをカウントしながら、リクエストにラベルを追加します。詳細については、「[ルールグループ内のルールアクションのオーバーライド](web-acl-rule-group-settings.md#web-acl-rule-group-rule-action-override)」を参照してください。このオーバーライドにより、Bot Control ルールがトラフィックに与える潜在的な影響をモニタリングでき、内部のユースケースや目的のボットなどの例外を追加するかどうか判断します。 + 保護パック (ウェブ ACL) で最後に評価されるように、ルールグループを配置します。優先順位の設定の数値は、既に使用している他のルールまたはルールグループよりも高くなります。詳細については、「[ルールの優先度を設定する](web-acl-processing-order.md)」を参照してください。これにより、現在のトラフィックの処理が中断されることはありません。たとえば、SQL インジェクションやクロスサイトスクリプティングなどの悪意のあるトラフィックを検出するルールがある場合、そのようなリクエストを継続的に検出してログ記録します。または、既知の悪意のないトラフィックを許可するルールがある場合、Bot Control マネージドルールグループによってブロックされるようにすることなく、そのトラフィックを許可し続けることができます。テストおよび調整アクティビティ中に処理順序を調整することができますが、開始する方法としてお勧めします。 1. **保護パック (ウェブ ACL) のサンプリング、ログ記録、およびメトリクスの有効化** 必要に応じて、保護パック (ウェブ ACL) のログ記録、Amazon Security Lake データ収集、リクエストサンプリング、Amazon CloudWatch メトリクスを設定します。これらの可視化ツールを使用して Bot Control マネージドルールグループとトラフィックとのインタラクションをモニタリングできます。 + ログ作成の詳細については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。 + Amazon Security Lake の詳細については、[「Amazon Security Lake とは](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html)」および*「Amazon Security Lake* [ユーザーガイド」の AWS 「サービスからのデータ収集](https://docs.aws.amazon.com/security-lake/latest/userguide/internal-sources.html)」を参照してください。 + Amazon CloudWatch メトリクスの詳細については、「[Amazon CloudWatch によるモニタリング](monitoring-cloudwatch.md)」を参照してください。 + ウェブリクエストサンプリングの詳細については、「[ウェブリクエストのサンプルの表示](web-acl-testing-view-sample.md)」を参照してください。 1. **保護パック (ウェブ ACL) をリソースに関連付ける** 保護パック (ウェブ ACL) がリソースに関連付けられていない場合は、関連付けます。詳細については、「[AWS リソースとの保護の関連付けまたは関連付け解除](web-acl-associating-aws-resource.md)」を参照してください。 1. **トラフィックと Bot Control ルールの一致をモニタリングする** トラフィックがフローしていることと、Bot Control マネージドルールグループのルールが一致するウェブリクエストにラベルを追加していることを確認します。ログにラベルが表示され、Amazon CloudWatch メトリクスでボットとラベルのメトリクスを確認できます。ログでは、ルールグループでカウントするようにオーバーライドしたルールが、カウントに設定された `action` と、オーバーライドした設定済のルールアクションを示す `overriddenAction` とともに、`ruleGroupList` に表示されます。 **注記** Bot Control マネージドルールグループは、 AWS WAFからの IP アドレスを使用してボットを検証します。Bot Control を使用し、プロキシまたはロードバランサーを介してルーティングするボットを検証した場合は、カスタムルールを使用して明示的に許可する必要がある場合があります。カスタムルールの作成方法については、「[で転送された IP アドレスを使用する AWS WAF](waf-rule-statement-forwarded-ip-address.md)」を参照してください。ルールを使用して Bot Control ウェブリクエストの処理をカスタマイズする方法については、次のステップを参照してください。ウェブリクエスト処理を詳細にレビューして、カスタム処理で軽減する必要のある誤検出があるかどうかを確認してください。誤検知の例については、「[AWS WAF Bot Control を使用した誤検出のシナリオ例](waf-bot-control-false-positives.md)」を参照してください。 1. **Bot Control ウェブリクエストの処理をカスタマイズする** 必要に応じて、リクエストを明示的に許可またはブロックする独自のルールを追加して、Bot Control ルールがそのリクエストを処理する方法を変更します。これをどのように実行するかはユースケースによって異なりますが、一般的な解決策は次のとおりです。 + Bot Control マネージドルールグループの前に追加したルールを含むリクエストを明示的に許可します。これにより、許可されたリクエストが評価のためにルールグループに到達することはありません。これは、Bot Control マネージドルールグループの使用コストを抑えるのに役立ちます。 + Bot Control マネージドルールグループのステートメント内のスコープダウンステートメントを追加し、Bot Control 評価からのリクエストを除外します。これは、前述のオプションと同じように機能します。スコープダウンステートメントと一致しないリクエストがルールグループの評価に到達することはないため、Bot Control マネージドルールグループの使用コストを抑えるのに役立ちます。スコープダウンステートメントの詳細については、「[でのスコープダウンステートメントの使用 AWS WAF](waf-rule-scope-down-statements.md)」を参照してください。例については、以下を参照してください。 + [ボット管理からの IP 範囲を除外する](waf-bot-control-example-scope-down-ip.md) + [コントロールしているボットからのトラフィックを許可する](waf-bot-control-example-scope-down-your-bot.md) + リクエスト処理に Bot Control ラベルを使用して、リクエストを許可またはブロックします。Bot Control マネージドルールグループの後にラベル一致ルールを追加して、ブロックするリクエストから、許可するラベル付きリクエストをブロックするリクエストを除外します。テスト後、関連する Bot Control ルールをカウントモードで維持し、カスタムルールでリクエストの処理に関する決定を維持します。ラベル一致ステートメントの詳細については、「[ラベル一致ルールステートメント](waf-rule-statement-type-label-match.md)」を参照してください。この種類のカスタマイズの例については、以下を参照してください。 + [ブロックされたユーザーエージェントの例外を作成する](waf-bot-control-example-user-agent-exception.md) + [特定のブロックされたボットを許可する](waf-bot-control-example-allow-blocked-bot.md) + [検証済みボットをブロックする](waf-bot-control-example-block-verified-bots.md) その他の例については、「[AWS WAF Bot Control の例](waf-bot-control-examples.md)」を参照してください。 1. **必要に応じて、Bot Control マネージドルールグループ設定を有効にします** 状況によっては、一部の Bot Control ルールをカウントモードの状態で維持する、あるいは異なるアクションのオーバーライドに適用すると判断する場合があります。ルールグループ内で設定されているときに実行するルールについては、通常のルール設定を有効にします。これを行うには、保護パック (ウェブ ACL) のルールグループステートメントを編集し、**[Rules]** (ルール) ペインで変更を行います。 # AWS WAF Bot Control の例このセクションでは、 AWS WAF Bot Control 実装のさまざまな一般的なユースケースを満たす設定例を示します。各例は、ユースケースの説明を提供し、カスタム設定ルールの JSON リストにそのソリューションを示します。 **注記** これらの例に示されている JSON リストは、ルールを設定し、**Rule JSON エディタ**を使用して編集することにより、コンソールで作成されました。 **Topics** + [ # Bot Control の例: 簡単な設定 ](waf-bot-control-example-basic.md) + [ # Bot Control の例: 検証済みボットを明示的に許可する ](waf-bot-control-example-allow-verified-bots.md) + [ # Bot Control の例: 検証済みボットをブロックする ](waf-bot-control-example-block-verified-bots.md) + [ # Bot Control の例: 特定のブロックされたボットを許可する ](waf-bot-control-example-allow-blocked-bot.md) + [ # Bot Control の例: ブロックされたユーザーエージェントの例外を作成する ](waf-bot-control-example-user-agent-exception.md) + [ # Bot Control の例: ログインページにのみ Bot Control を使用します ](waf-bot-control-example-scope-down-login.md) + [ # Bot Control の例: 動的コンテンツにのみ Bot Control を使用する ](waf-bot-control-example-scope-down-dynamic-content.md) + [ # Bot Control の例: ボット管理から IP 範囲を除外する ](waf-bot-control-example-scope-down-ip.md) + [ # Bot Control の例: コントロールしているボットからのトラフィックを許可する ](waf-bot-control-example-scope-down-your-bot.md) + [ # Bot Control の例: ターゲット検査レベルの有効化 ](waf-bot-control-example-targeted-inspection-level.md) + [ # Bot Control の例: 2 つのステートメントを使用してターゲット検査レベルの使用を制限する ](waf-bot-control-example-common-and-targeted-inspection-level.md) # Bot Control の例: 簡単な設定次の JSON リストは、 AWS WAF Bot Control マネージドルールグループを使用した保護パック (ウェブ ACL) の例を示しています。可視性設定に注意してください。これにより、 AWS WAF はモニタリング目的でリクエストサンプルとメトリクスを保存します。 ``` { "Name": "Bot-WebACL", "Id": "...", "ARN": "...", "DefaultAction": { "Allow": {} }, "Description": "Bot-WebACL", "Rules": [ { ... }, { "Name": "AWS-AWSBotControl-Example", "Priority": 5, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesBotControlRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesBotControlRuleSet": { "InspectionLevel": "COMMON" } } ], "RuleActionOverrides": [], "ExcludedRules": [] }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSBotControl-Example" } } } ], "VisibilityConfig": { ... }, "Capacity": 1496, "ManagedByFirewallManager": false, "RetrofittedByFirewallManager": false } ``` # Bot Control の例: 検証済みボットを明示的に許可する AWS WAF Bot Control は、が一般的 AWS で検証可能なボットであることがわかっているボットをブロックしません。Bot Control が検証済みボットからのウェブリクエストを識別すると、ボットに名前を付けるラベルと、検証済みボットであることを示すラベルが追加されます。Bot Control は、既知の正常なボットがブロックされないように、シグナルラベルなどの他のラベルを追加しません。検証済みボットをブロックする他の AWS WAF ルールがある場合があります。検証済みのボットが確実に許可されるようにするには、Bot Control ラベルに基づいてそれらのボットを許可するカスタムルールを追加します。ラベルを照合できるように、新しいルールは Bot Control マネージドルールグループの後に実行される必要があります。次のルールは、検証済みボットを明示的に許可します。 ``` { "Name": "match_rule", "Statement": { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:bot-control:bot:verified" } }, "RuleLabels": [], "Action": { "Allow": {} } } ``` # Bot Control の例: 検証済みボットをブロックする検証済みのボットをブロックするには、 AWS WAF Bot Control マネージドルールグループの後に実行されるボットをブロックするルールを追加する必要があります。これを行うには、ブロックするボット名を特定し、ラベル一致ステートメントを使用して、それらを識別してブロックします。検証済みのすべてのボットをブロックするだけの場合は、`bot:name:` ラベルとの照合を省略できます。次のルールは、`bingbot` 検証済みボットのみをブロックします。このルールは、Bot Control マネージドルールグループの後に実行する必要があります。 ``` { "Name": "match_rule", "Statement": { "AndStatement": { "Statements": [ { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:bot-control:bot:name:bingbot" } }, { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:bot-control:bot:verified" } } ] } }, "RuleLabels": [], "Action": { "Block": {} } } ``` 次のルールは、すべての検証済みボットをブロックします。 ``` { "Name": "match_rule", "Statement": { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:bot-control:bot:verified" } }, "RuleLabels": [], "Action": { "Block": {} } } ``` # Bot Control の例: 特定のブロックされたボットを許可する複数の Bot Control ルールによってボットがブロックされる可能性があります。各ブロッキングルールについて、次の手順を実行します。 AWS WAF Bot Control ルールがブロックしないボットをブロックしている場合は、次の操作を行います。 1. ログをチェックして、ボットをブロックしている Bot Control ルールを特定します。ブロックルールは、名前が `terminatingRule` で始まるフィールドのログで指定されます。保護パック (ウェブ ACL) ログの詳細については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。ルールがリクエストに追加するラベルに注意してください。 1. 保護パック (ウェブ ACL) で、ブロッキングルールのアクションをカウントするようにオーバーライドします。コンソールでこれを行うには、保護パック (ウェブ ACL) でルールグループのルールを編集し、ルールに Count のルールアクションオーバーライドを選択します。これにより、ボットがルールによってブロックされないようにしても、ルールは一致するリクエストにラベルを適用します。 1. Bot Control マネージドルールグループの後に、保護パック (ウェブ ACL) にラベル一致ルールを追加します。オーバーライドされたルールのラベルと照合し、ブロックしたくないボットを除くすべての一致するリクエストをブロックするようにルールを設定します。これで、保護パック (ウェブ ACL) が設定され、許可するボットが、ログを通じて特定したブロックルールによってブロックされなくなります。トラフィックとログをもう一度チェックして、ボットの通過が許可されていることを確認します。許可されていない場合は、上記の手順を再度実行してください。例えば、`pingdom` を除くすべてのモニタリングボットをブロックするとします。この場合、`CategoryMonitoring` ルールがカウントするようにオーバーライドし、その後にボット名ラベル `pingdom` が付いているものを除くすべてのモニタリングボットをブロックするルールを記述します。次のルールは、Bot Control マネージドルールグループを使用しますが、`CategoryMonitoring` のルールアクションがカウントするようにオーバーライドします。カテゴリモニタリングルールは、一致するリクエストに通常どおりラベルを適用しますが、通常のブロックアクションを実行するのではなく、カウントするだけです。 ``` { "Name": "AWS-AWSBotControl-Example", "Priority": 5, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesBotControlRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesBotControlRuleSet": { "InspectionLevel": "COMMON" } } ], "RuleActionOverrides": [ { "ActionToUse": { "Count": {} }, "Name": "CategoryMonitoring" } ], "ExcludedRules": [] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSBotControl-Example" } } ``` 次のルールは、前の `CategoryMonitoring` ルールが一致するウェブリクエストに追加するカテゴリモニタリングラベルと照合します。カテゴリモニタリングリクエストの中で、このルールはボット名 `pingdom` のラベルを持つものを除くすべてをブロックします。次のルールは、保護パック (ウェブ ACL) の処理順序で、前の Bot Control マネージドルールグループの後に実行する必要があります。 ``` { "Name": "match_rule", "Priority": 10, "Statement": { "AndStatement": { "Statements": [ { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:bot-control:bot:category:monitoring" } }, { "NotStatement": { "Statement": { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:bot-control:bot:name:pingdom" } } } } ] } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "match_rule" } } ``` # Bot Control の例: ブロックされたユーザーエージェントの例外を作成する一部のブラウザ以外のユーザーエージェントからのトラフィックが誤ってブロックされている場合は、問題のある AWS WAF Bot Control ルール`SignalNonBrowserUserAgent`をカウントに設定し、ルールのラベル付けを例外条件と組み合わせることで、例外を作成できます。 **注記** 通常、モバイルアプリにはブラウザ以外のユーザーエージェントがあり、`SignalNonBrowserUserAgent` ルールではデフォルトでブロックされます。次のルールは、Bot Control マネージドルールグループを使用しますが、`SignalNonBrowserUserAgent` のルールアクションがカウントするようにオーバーライドします。シグナルルールは、一致するリクエストに通常どおりラベルを適用しますが、通常のブロックアクションを実行するのではなく、カウントするだけです。 ``` { "Name": "AWS-AWSBotControl-Example", "Priority": 5, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesBotControlRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesBotControlRuleSet": { "InspectionLevel": "COMMON" } } ], "RuleActionOverrides": [ { "ActionToUse": { "Count": {} }, "Name": "SignalNonBrowserUserAgent" } ], "ExcludedRules": [] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSBotControl-Example" } } ``` 次のルールは、Bot Control `SignalNonBrowserUserAgent` ルールが一致するウェブリクエストに追加したシグナルラベルと照合します。シグナルリクエストの中では、このルールは当社が許可するユーザーエージェントを持つものを除くすべてをブロックします。次のルールは、保護パック (ウェブ ACL) の処理順序で、前の Bot Control マネージドルールグループの後に実行する必要があります。 ``` { "Name": "match_rule", "Statement": { "AndStatement": { "Statements": [ { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:bot-control:signal:non_browser_user_agent" } }, { "NotStatement": { "Statement": { "ByteMatchStatement": { "FieldToMatch": { "SingleHeader": { "Name": "user-agent" } }, "PositionalConstraint": "EXACTLY", "SearchString": "PostmanRuntime/7.29.2", "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } } } } ] } }, "RuleLabels": [], "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "match_rule" } } ``` # Bot Control の例: ログインページにのみ Bot Control を使用します次の例では、スコープダウンステートメントを使用して、URI パスによって識別されるウェブサイトのログインページに送信されるトラフィックにのみ AWS WAF Bot Control を適用します`login`。ログインページへの URI パスは、アプリケーションや環境によっては、この例とは異なる場合があります。 ``` { "Name": "AWS-AWSBotControl-Example", "Priority": 5, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesBotControlRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesBotControlRuleSet": { "InspectionLevel": "COMMON" } } ], "RuleActionOverrides": [], "ExcludedRules": [] }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSBotControl-Example" }, "ScopeDownStatement": { "ByteMatchStatement": { "SearchString": "login", "FieldToMatch": { "UriPath": {} }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "CONTAINS" } } } } ``` # Bot Control の例: 動的コンテンツにのみ Bot Control を使用するこの例では、スコープダウンステートメントを使用して、動的コンテンツにのみ AWS WAF Bot Control を適用します。スコープダウンステートメントは、正規表現パターンセットの一致結果を否定することにより、静的コンテンツを除外します。 + 正規表現パターンセットは、*静的コンテンツ*の拡張子と一致するように設定されています。例えば、正規表現パターンセットの指定は `(?i)\.(jpe?g|gif|png|svg|ico|css|js|woff2?)$` である場合があります。正規表現のパターンセットとステートメントの詳細については、「[正規表現パターンセット一致ルールステートメント](waf-rule-statement-type-regex-pattern-set-match.md)」を参照してください。 + スコープダウンステートメントでは、`NOT` ステートメント内に正規表現パターンセットのステートメントをネストすることにより、一致する静的コンテンツを除外します。`NOT` ステートメントについては、「[NOT ルールステートメント](waf-rule-statement-type-not.md)」を参照してください。 ``` { "Name": "AWS-AWSBotControl-Example", "Priority": 5, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesBotControlRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesBotControlRuleSet": { "InspectionLevel": "COMMON" } } ], "RuleActionOverrides": [], "ExcludedRules": [] }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSBotControl-Example" }, "ScopeDownStatement": { "NotStatement": { "Statement": { "RegexPatternSetReferenceStatement": { "ARN": "arn:aws:wafv2:us-east-1:123456789:regional/regexpatternset/excludeset/00000000-0000-0000-0000-000000000000", "FieldToMatch": { "UriPath": {} }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } } } } } } ``` # Bot Control の例: ボット管理から IP 範囲を除外する AWS WAF Bot Control 管理からウェブトラフィックのサブセットを除外し、ルールステートメントを使用してそのサブセットを識別できるようにする場合は、Bot Control マネージドルールグループステートメントにスコープダウンステートメントを追加して除外します。次のルールは、特定の IP アドレス範囲からのウェブリクエストを除き、すべてのウェブトラフィックに対して通常の Bot Control ボット管理を実行します。 ``` { "Name": "AWS-AWSBotControl-Example", "Priority": 5, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesBotControlRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesBotControlRuleSet": { "InspectionLevel": "COMMON" } } ], "RuleActionOverrides": [], "ExcludedRules": [] }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSBotControl-Example" }, "ScopeDownStatement": { "NotStatement": { "Statement": { "IPSetReferenceStatement": { "ARN": "arn:aws:wafv2:us-east-1:123456789:regional/ipset/friendlyips/00000000-0000-0000-0000-000000000000" } } } } } } ``` # Bot Control の例: コントロールしているボットからのトラフィックを許可する一部のサイトモニタリングボットとカスタムボットは、カスタムヘッダーを送信するように設定できます。このようなボットからのトラフィックを許可する場合、ヘッダーに共有シークレットを追加するように設定できます。その後、 AWS WAF Bot Control マネージドルールグループステートメントにスコープダウンステートメントを追加することで、ヘッダーを持つメッセージを除外できます。次のルール例は、シークレットヘッダーを持つトラフィックを Bot Control 検査から除外します。 ``` { "Name": "AWS-AWSBotControl-Example", "Priority": 5, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesBotControlRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesBotControlRuleSet": { "InspectionLevel": "COMMON" } } ], "RuleActionOverrides": [], "ExcludedRules": [] }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSBotControl-Example" }, "ScopeDownStatement": { "NotStatement": { "Statement": { "ByteMatchStatement": { "SearchString": "YSBzZWNyZXQ=", "FieldToMatch": { "SingleHeader": { "Name": "x-bypass-secret" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "EXACTLY" } } } } } } ``` # Bot Control の例: ターゲット検査レベルの有効化保護レベルを強化するために、 AWS WAF Bot Control マネージドルールグループでターゲット検査レベルを有効にできます。次の例では、機械学習機能が有効になっています。`EnableMachineLearning` を `false` に設定することで、この動作をオプトアウトできます。 ``` { "Name": "AWS-AWSBotControl-Example", "Priority": 5, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesBotControlRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesBotControlRuleSet": { "InspectionLevel": "TARGETED", "EnableMachineLearning": true } } ], "RuleActionOverrides": [], "ExcludedRules": [] }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSBotControl-Example" } } } ``` # Bot Control の例: 2 つのステートメントを使用してターゲット検査レベルの使用を制限するコスト最適化として、保護パック (ウェブ ACL) で 2 つの AWS WAF Bot Control マネージドルールグループステートメントを使用し、個別の検査レベルとスコープを設定できます。例えば、より機密性の高いアプリケーションエンドポイントにのみ、ターゲット検査レベルのステートメントを評価できます。次の例の 2 つのステートメントには、相互に排他的な評価があります。この設定がない場合、リクエストによって 2 つの Bot Control 評価が請求される可能性があります。 **注記** コンソールのビジュアルエディターでは、複数のステートメントリファレンス `AWSManagedRulesBotControlRuleSet` はサポートされていません。代わりに、JSON エディターを使用します。 ``` { "Name": "Bot-WebACL", "Id": "...", "ARN": "...", "DefaultAction": { "Allow": {} }, "Description": "Bot-WebACL", "Rules": [ { ... }, { "Name": "AWS-AWSBotControl-Common", "Priority": 5, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesBotControlRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesBotControlRuleSet": { "InspectionLevel": "COMMON" } } ], "RuleActionOverrides": [], "ExcludedRules": [] }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSBotControl-Common" }, "ScopeDownStatement": { "NotStatement": { "Statement": { "ByteMatchStatement": { "FieldToMatch": { "UriPath": {} }, "PositionalConstraint": "STARTS_WITH", "SearchString": "/sensitive-endpoint", "TextTransformations": [ { "Type": "NONE", "Priority": 0 } ] } } } } } }, { "Name": "AWS-AWSBotControl-Targeted", "Priority": 6, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesBotControlRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesBotControlRuleSet": { "InspectionLevel": "TARGETED", "EnableMachineLearning": true } } ], "RuleActionOverrides": [], "ExcludedRules": [] }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSBotControl-Targeted" }, "ScopeDownStatement": { "Statement": { "ByteMatchStatement": { "FieldToMatch": { "UriPath": {} }, "PositionalConstraint": "STARTS_WITH", "SearchString": "/sensitive-endpoint", "TextTransformations": [ { "Type": "NONE", "Priority": 0 } ] } } } } } ], "VisibilityConfig": { ... }, "Capacity": 1496, "ManagedByFirewallManager": false, "RetrofittedByFirewallManager": false } ``` # AWS WAF 分散サービス拒否 (DDoS) の防止 AWS WAF は、 AWS リソース内の DDoS 攻撃に対する高度でカスタマイズ可能な保護を提供します。このセクションで説明されているオプションを確認し、セキュリティとビジネスニーズを満たす DDoS 対策保護のレベルを選択します。 AWS WAFでは、2 つの DDoS 保護階層から選択できます。リソースレベルの DDoS 保護標準階層は、Application Load Balancer 内で動作し、ホストフィルタリングを通じて既知の悪意のあるソースから保護します。潜在的な DDoS イベントに最もよく反応するように保護動作を設定できます。リソースレベルの DDoS 保護: + トラフィックパターンを自動的にモニタリングします。 + 脅威インテリジェンスをリアルタイムで更新します。 + 既知の悪意のあるソースから保護します。 **Application Load Balancer のウェブ ACL リクエストコストを最適化するには** リソースレベルの保護を有効にするには、ウェブ ACL を Application Load Balancer に関連付ける必要があります。Application Load Balancer が設定のないウェブ ACL に関連付けられている場合、 AWS WAF リクエストに対して料金は発生しませんが、CloudWatch メトリクスの Application Load Balancer に対してサンプルリクエストやレポートを提供し AWS WAF ません。Application Load Balancer のオブザーバビリティ機能を有効にするには、次のアクションを実行できます。 + `DefaultAction` のカスタムリクエストヘッダーで `Allow` アクションまたは `Block` アクションを使用します。詳細については、「[ノンブロッキングアクションのためのカスタムリクエストヘッダーの挿入](customizing-the-incoming-request.md)」を参照してください。 + 任意のルールをウェブ ACL に追加します。詳細については、「[AWS WAF ルール](waf-rules.md)」を参照してください。 + ログ記録の送信先を有効にします。詳細については、「[保護パック (ウェブ ACL) のログ記録の設定](logging-management-configure.md)」を参照してください。 + ウェブ ACL を AWS Firewall Manager ポリシーに関連付けます。詳細については、「[の AWS Firewall Manager ポリシーの作成 AWS WAF](create-policy.md#creating-firewall-manager-policy-for-waf)」を参照してください。 AWS WAF は、これらの設定がないと、サンプルリクエストを提供したり、CloudWatch メトリクスを発行したりしません。 AWS マネージドルールグループの DDoS 保護 DDoS 保護の高度な階層は、`AWSManagedRulesAntiDDoSRuleSet` を通じて提供されます。マネージドルールグループは、リソースレベルの保護階層を補完しますが、次の大きな違いがあります。 + 保護は Application Load Balancer と CloudFront ディストリビューションの両方に拡張されます + トラフィックベースラインは、新しい攻撃パターンの検出を改善するために、保護されたリソース用に作成されます。 + 保護動作は、選択した感度レベルに応じてアクティブ化されます。 + DDoS イベントの発生時に、保護されたリソースへのリクエストを管理およびラベル付けします。含まれているルールと機能の包括的なリストについては、「[AWS WAF 分散サービス拒否 (DDoS) 防止ルールグループ](aws-managed-rule-groups-anti-ddos.md)」を参照してください。 **注記** このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。 **Topics** + [ # Application Load Balancer のリソースレベルの DDoS 保護 ](waf-anti-ddos-alb.md) + [ # Anti-DDoS マネージドルールグループを使用した高度な AWS WAF Anti-DDoS 保護 ](waf-anti-ddos-advanced.md) # Application Load Balancer のリソースレベルの DDoS 保護 **リソースレベルの DDoS 保護**は、 AWS WAF マネージドルールグループのデプロイ料金を発生させることなく、Application Load Balancer に即時の防御を追加します。この標準レベルのアンチ DDoS 保護では、 AWS 脅威インテリジェンスとトラフィックパターン分析を使用して Application Load Balancer を保護します。既知の悪意のあるソースを特定するために、DDoS 対策保護は直接クライアント IP アドレスと X-Forwarded-For (XFF) ヘッダーの両方のオンホストフィルタリングを実行します。既知の悪意のあるソースが特定されると、次の 2 つのモードのいずれかで保護がアクティブ化されます。 **DDoS 下でアクティブ** はデフォルトの保護モードであり、ほとんどのユースケースで推奨されます。このモードでは、以下を行います。 + 高負荷条件または潜在的な DDoS イベントを検出すると、保護を自動的にアクティブ化します + 攻撃条件中にのみ既知の悪意のあるソースからのトラフィックをレート制限します。 + 通常のオペレーション中の正当なトラフィックへの影響を最小限に抑えます + Application Load Balancer のヘルスメトリクスと AWS WAF レスポンスデータを使用して、いつ保護をエンゲージするかを判断します **常時オン** はオプションモードであり、有効にすると常時アクティブになります。このモードでは、以下を行います。 + 既知の悪意のあるソースに対する継続的な保護を維持します + 既知の悪意のあるソースからのトラフィックをリアルタイムでレート制限します + XFF ヘッダーの悪意のある IP を使用した直接接続とリクエストの両方に保護を適用します + 正当なトラフィックに大きな影響を与える可能性がありますが、最大限のセキュリティを提供しますリソースレベルの DDoS 保護によってブロックされたリクエストは、CloudWatch ログに `LowReputationPacketsDropped`または `LowReputationRequestsDenied`メトリクスとして記録されます。詳細については、「[AWS WAF コアメトリクスとディメンション](waf-metrics.md#waf-metrics-general)」を参照してください。 ## 既存のウェブ ACL で標準 DDoS 保護を有効にしますウェブ ACL を作成するとき、または Application Load Balancer に関連付けられた既存のウェブ ACL を更新するときに、DDoS 保護を有効にできます。 **注記** Application Load Balancer に関連付けられている既存のウェブ ACL がある場合、DDoS 保護はデフォルトで **DDoS モードでアクティブ** で有効になります。 **AWS WAF コンソールで DDoS 対策保護を有効にするには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで **[ウェブ ACL]** を選択し、Application Load Balancer に関連付けられているウェブ ACL を開きます。 1. **関連付けられた AWS リソース**を選択します。 1. **リソースレベルの DDoS 保護** で、**編集** を選択します。 1. 次のいずれかのモードを選択します。 + **DDoS でアクティブ** (推奨) - 保護は高負荷条件中でのみ機能します + **常時オン** - 既知の悪意のあるソースに対する常時オンの保護 1. **[Save changes]** (変更の保存) をクリックします。 **注記** ウェブ ACL の作成については、「[で保護パック (ウェブ ACL) を作成する AWS WAF](web-acl-creating.md)」を参照してください。 **Application Load Balancer のウェブ ACL リクエストコストを最適化するには** リソースレベルの保護を有効にするには、ウェブ ACL を Application Load Balancer に関連付ける必要があります。Application Load Balancer が設定のないウェブ ACL に関連付けられている場合、 AWS WAF リクエストに対して料金は発生しませんが、CloudWatch メトリクスの Application Load Balancer に対してサンプルリクエストやレポートを提供し AWS WAF ません。Application Load Balancer のオブザーバビリティ機能を有効にするには、次のアクションを実行できます。 `DefaultAction` のカスタムリクエストヘッダーで `Allow` アクションまたは `Block` アクションを使用します。詳細については、「[ノンブロッキングアクションのためのカスタムリクエストヘッダーの挿入](customizing-the-incoming-request.md)」を参照してください。任意のルールをウェブ ACL に追加します。詳細については、「[AWS WAF ルール](waf-rules.md)」を参照してください。ログ記録の送信先を有効にします。詳細については、「[保護パック (ウェブ ACL) のログ記録の設定](logging-management-configure.md)」を参照してください。ウェブ ACL を AWS Firewall Manager ポリシーに関連付けます。詳細については、「[の AWS Firewall Manager ポリシーの作成 AWS WAF](create-policy.md#creating-firewall-manager-policy-for-waf)」を参照してください。 AWS WAF は、これらの設定がないと、サンプルリクエストを提供したり、CloudWatch メトリクスを発行したりしません。 # Anti-DDoS マネージドルールグループを使用した高度な AWS WAF Anti-DDoS 保護 `AWSManagedRulesAntiDDoSRuleSet` マネージドルールグループは、で利用可能な DDoS 対策保護の最も高度な階層です AWS WAF。 **注記** このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。 ## AWS WAF DDoS 対策コンポーネントに高度なアンチ DDoS 保護を実装するための主なコンポーネント AWS WAF は次のとおりです。 **`AWSManagedRulesAntiDDoSRuleSet`** – DDoS 攻撃に参加している可能性が高いリクエストを検出、ラベル付け、チャレンジします。また、イベント中に保護されたリソースへのすべてのリクエストにラベル付けします。ルールグループのルールとラベルの詳細については、「[AWS WAF 分散サービス拒否 (DDoS) 防止ルールグループ](aws-managed-rule-groups-anti-ddos.md)」を参照してください。このルールグループを使用するには、マネージドルールグループ参照ステートメントを使用して保護パック (ウェブ ACL) に含めます。詳細については、「[DDoS 対策マネージドルールグループを保護パック (ウェブ ACL) に追加する](waf-anti-ddos-rg-using.md)」を参照してください。 + **ウェブ ACL トラフィック概要ダッシュボード** – コンソールで DDoS アクティビティと DDoS 対策レスポンスをモニタリングします。詳細については、「[保護パック (ウェブ ACL) のトラフィック概要ダッシュボード](web-acl-dashboards.md)」を参照してください。 + **ログ記録とメトリクス** – トラフィックをモニタリングし、DDoS 対策保護の効果を理解できます。保護パック (ウェブ ACL) のログ、Amazon Security Lake データ収集、Amazon CloudWatch メトリクスを設定します。これらのオプションの詳細については、[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)、[Amazon CloudWatch によるモニタリング](monitoring-cloudwatch.md)、及び「[What is Amazon Security Lake?](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html)」を参照してください。 + **ラベルとラベル一致ルール** – DDoS 対策マネージドルールグループによって特定されるウェブリクエストの処理をカスタマイズできます。`AWSManagedRulesAntiDDoSRuleSet`のどのルールでも、カウントモードに切り替えて、追加されたラベルと照合できます。詳細については、「[ラベル一致ルールステートメント](waf-rule-statement-type-label-match.md)」および「[でのウェブリクエストのラベル付け AWS WAF](waf-labels.md)」を参照してください。 + **カスタムリクエストとレスポンス** - 許可されたリクエストにカスタムヘッダーを追加し、ブロックされたリクエストではカスタムレスポンスを送信できます。ラベルマッチングを AWS WAF カスタムリクエストおよびレスポンス機能とペアリングします。詳細については、「[でカスタマイズされたウェブリクエストとレスポンス AWS WAF](waf-custom-request-response.md)」を参照してください。 # DDoS 対策マネージドルールグループを保護パック (ウェブ ACL) に追加するこのセクションでは、`AWSManagedRulesAntiDDoSRuleSet` ルールグループを追加および設定する方法について説明します。 DDoS 対策マネージドルールグループを設定するには、DDoS 攻撃に対してルールグループがどれだけ機密であるかや、攻撃に参加している、または参加している可能性のあるリクエストに対してルールグループが実行するアクションを含む設定を指定します。この設定は、マネージドルールグループの通常の設定に追加されます。ルールグループの説明およびルールとラベルのリストについては、「[AWS WAF 分散サービス拒否 (DDoS) 防止ルールグループ](aws-managed-rule-groups-anti-ddos.md)」を参照してください。このガイダンスは、 AWS WAF 保護パック (ウェブ ACL)、ルール、およびルールグループを作成および管理する方法を一般的に認識しているユーザーを対象としています。これらのトピックは、このガイドの前のセクションでカバーされています。マネージドルールグループを保護パック (ウェブ ACL) に追加する方法の基本については、「[コンソールを通じた保護パック (ウェブ ACL) へのマネージドルールグループの追加](waf-using-managed-rule-group.md)」を参照してください。 **ベストプラクティスに従う** DDoS 対策ルールグループは、「[でのインテリジェントな脅威軽減のベストプラクティス AWS WAF](waf-managed-protections-best-practices.md)」に記載されているベストプラクティスに従って使用してください。 **保護パック (ウェブ ACL) で `AWSManagedRulesAntiDDoSRuleSet` ルールグループを使用するには** 1. AWS マネージドルールグループを保護パック (ウェブ ACL) `AWSManagedRulesAntiDDoSRuleSet`に追加し、保存する前にルールグループ設定**を編集**します。 **注記** このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。 1. **ルールグループ設定** ペインで、`AWSManagedRulesAntiDDoSRuleSet` ルールグループのカスタム設定を指定します。 1. **ブロックの機密性レベル** では、ルールグループの DDoS 疑惑ラベル付けで一致するときに、ルール `DDoSRequests` をどれだけ機密にするかを指定します。機密性が高いほど、ルールが一致するラベル付けのレベルが低くなります。 + 低い機密性では機密の程度が低く、高い疑惑ラベル `awswaf:managed:aws:anti-ddos:high-suspicion-ddos-request` がある、攻撃の最も明白な参加者でのみルールが一致します。 + 中程度の機密性では、中程度と高い疑惑ラベルでルールが一致します。 + 高い機密性では、ルールは低、中、高のすべての疑惑ラベルで一致します。このルールは、DDoS 攻撃に参加している疑いがあるウェブリクエストの最も重大な処理を提供します。 1. **チャレンジを有効にする** では、ルール `ChallengeDDoSRequests` と `ChallengeAllDuringEvent` を有効にするかどうかを選択します。これにより、デフォルトで、一致するリクエストに Challenge アクションが適用されます。これらのルールは、正当なユーザーが DDoS 攻撃の参加者をブロックしながらリクエストを続行できるようにすることを目的としたリクエスト処理を提供します。アクション設定を Allow または Count にオーバーライドするか、完全に使用を無効にすることができます。これらのルールを有効にする場合は、必要な追加設定を指定します。 + **チャレンジの機密レベル** では、ルール `ChallengeDDoSRequests` をどれだけ機密にするかを指定します。機密性が高いほど、ルールが一致するラベル付けのレベルが低くなります。 + 低い機密性では機密の程度が低く、高い疑惑ラベル `awswaf:managed:aws:anti-ddos:high-suspicion-ddos-request` がある、攻撃の最も明白な参加者でのみルールが一致します。 + 中程度の機密性では、中程度と高い疑惑ラベルでルールが一致します。 + 高い機密性では、ルールは低、中、高のすべての疑惑ラベルで一致します。 + **除外 URI 正規表現** では、サイレントブラウザチャレンジを処理できないウェブリクエストの URI に一致する正規表現を指定します。Challenge アクションは、サイレントブラウザチャレンジを処理できない限り、チャレンジトークンがない URI からのリクエストを効果的にブロックします。 Challenge アクションは、HTML コンテンツを想定しているクライアントによってのみ適切に処理できます。アクションの仕組みの詳細については、「[CAPTCHA および Challenge アクション動作](waf-captcha-and-challenge-actions.md)」を参照してください。デフォルトの正規表現を確認し、必要に応じて更新します。ルールは、指定された正規表現を使用して、Challenge アクションを処理できないリクエスト URI を特定し、ルールがチャレンジを返さないようにします。この方法で除外するリクエストは、ルール `DDoSRequests` でルールグループによってのみブロックできます。コンソールで提供されるデフォルトの式は、ほとんどのユースケースを対象としていますが、アプリケーションに合わせて確認して調整する必要があります。 AWS WAF は、いくつかの例外`libpcre`を除いて、PCRE ライブラリで使用されるパターン構文をサポートします。ライブラリは、「[PCRE - Perl Compatible Regular Expressions](http://www.pcre.org/)」で文書化されています。 AWS WAF サポートの詳細については、「」を参照してください[でサポートされている正規表現構文 AWS WAF](waf-regex-pattern-support.md)。 1. ルールグループに必要な追加設定を指定し、ルールを保存します。 **注記** AWS では、このマネージドルールグループでスコープダウンステートメントを使用しないことをお勧めします。スコープダウンステートメントは、ルールグループが監視するリクエストを制限するため、トラフィックベースラインが不正確になり、DDoS イベント検出が低下する可能性があります。スコープダウンステートメントオプションは、すべてのマネージドルールグループステートメントで使用できますが、このステートメントには使用しないでください。スコープダウンステートメントの詳細については、「[でのスコープダウンステートメントの使用 AWS WAF](waf-rule-scope-down-statements.md)」を参照してください。 1. **ルールの優先度の設定** ページで、新しい DDoS 対策マネージドルールグループルールを上に移動させ、持っている Allow アクションルールの後で他のルールの前にのみ実行されるようにします。これにより、ルールグループは DDoS 対策保護のトラフィックを最も多く追跡できます。 1. 変更を保護パック (ウェブ ACL) に保存します。本番稼働トラフィックに DDoS 対策実装をデプロイする前に、トラフィックへの潜在的な影響に慣れるまで、ステージング環境またはテスト環境でテストおよびチューニングします。その後、ルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。ガイダンスについては、次のセクションを参照してください。 # DDoS 対策のテストとデプロイ機能をデプロイする前に、 AWS WAF 分散サービス拒否 (DDoS) 防止を設定してテストする必要があります。このセクションは設定とテストの一般的なガイダンスを提供しますが、実行する具体的なステップは、ニーズ、リソース、および受け取るウェブリクエストによって異なります。この情報は、[AWS WAF 保護のテストとチューニング](web-acl-testing.md) で提供されているテストおよび調整に関する一般情報とは別です。 **注記** AWS マネージドルールは、一般的なウェブ脅威から保護するように設計されています。ドキュメントに従って使用すると、 AWS マネージドルールルールグループはアプリケーションに別のセキュリティレイヤーを追加します。ただし、 AWS マネージドルールルールグループは、選択した AWS リソースによって決定されるセキュリティ責任に代わるものではありません。責任[共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)を参照して、のリソースが適切に保護 AWS されていることを確認します。 **本番稼働トラフィックのリスク** トラフィックへの潜在的な影響に納得がいくまで、実装をステージング環境またはテスト環境でテストおよび調整します。その後、ルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。このガイダンスは、 AWS WAF 保護パック (ウェブ ACL)、ルール、およびルールグループを作成および管理する方法を一般的に認識しているユーザーを対象としています。これらのトピックは、このガイドの前のセクションでカバーされています。 **AWS WAF 分散サービス拒否 (DDoS) 防止実装を設定してテストするには** これらのステップを最初にテスト環境で実行し、次に本番環境で実行します。 1. **AWS WAF 分散サービス拒否 (DDoS) 防止マネージドルールグループをカウントモードに追加する** **注記** このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。 AWS マネージドルールルールグループ`AWSManagedRulesAntiDDoSRuleSet`を新規または既存の保護パック (ウェブ ACL) に追加し、現在の保護パック (ウェブ ACL) の動作を変更しないように設定します。このルールグループのルールとラベルの詳細については、「[AWS WAF 分散サービス拒否 (DDoS) 防止ルールグループ](aws-managed-rule-groups-anti-ddos.md)」を参照してください。 + マネージドルールグループを追加する際には、それを編集し、次の手順を実行します。 + **ルールグループ設定** ペインで、ウェブトラフィックの DDoS 対策アクティビティを実行するために必要な詳細を指定します。詳細については、「[DDoS 対策マネージドルールグループを保護パック (ウェブ ACL) に追加する](waf-anti-ddos-rg-using.md)」を参照してください。 + **[Rules]** (ルール) ペインで、**[Override all rule actions]** (すべてのルールアクションをオーバーライド) ドロップダウンを開いて、**[Count]** を選択します。この設定では、 AWS WAF は、ルールグループ内のすべてのルールに対してリクエストを評価し、その結果の一致のみをカウントしつつ、引き続きリクエストにラベルを追加します。詳細については、「[ルールグループ内のルールアクションのオーバーライド](web-acl-rule-group-settings.md#web-acl-rule-group-rule-action-override)」を参照してください。このオーバーライドを使用すると、DDoS 対策マネージドルールの潜在的な影響をモニタリングして、サイレントブラウザチャレンジを処理できない URI の正規表現を拡張するなど、変更を加えるかどうかを判断できます。 + トラフィックを許可するルールの直後に、できるだけ早く評価されるようにルールグループを配置します。ルールは昇順の優先順位で評価されます。コンソールは、ルールリストの最上部から順番を設定します。詳細については、「[ルールの優先度を設定する](web-acl-processing-order.md)」を参照してください。 1. **保護パック (ウェブ ACL) のサンプリング、ログ記録、およびメトリクスの有効化** 必要に応じて、保護パック (ウェブ ACL) のログ記録、Amazon Security Lake データ収集、リクエストサンプリング、Amazon CloudWatch メトリクスを設定します。これらの可視化ツールを使用して DDoS 対策マネージドルールグループとトラフィックとのインタラクションをモニタリングできます。 + ログ記録の設定と使用については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。 + Amazon Security Lake の詳細については、[「Amazon Security Lake ユーザーガイド」の「Amazon Security Lake とは](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html)[」および AWS 「サービスからのデータの収集](https://docs.aws.amazon.com/security-lake/latest/userguide/internal-sources.html)」を参照してください。 ** + Amazon CloudWatch メトリクスの詳細については、「[Amazon CloudWatch によるモニタリング](monitoring-cloudwatch.md)」を参照してください。 + ウェブリクエストサンプリングの詳細については、「[ウェブリクエストのサンプルの表示](web-acl-testing-view-sample.md)」を参照してください。 1. **保護パック (ウェブ ACL) をリソースに関連付ける** 保護パック (ウェブ ACL) がテストリソースに関連付けられていない場合は、関連付けます。詳細については、「[AWS リソースとの保護の関連付けまたは関連付け解除](web-acl-associating-aws-resource.md)」を参照してください。 1. **トラフィックと DDoS 対策ルールの一致をモニタリングする** 通常のトラフィックがフローしていることと、DDoS 対策マネージドルールグループのルールが一致するウェブリクエストにラベルを追加していることを確認します。ログにラベルが表示され、Amazon CloudWatch メトリクスで DDoS 対策とラベルのメトリクスを確認できます。ログでは、ルールグループでカウントするようにオーバーライドしたルールが、カウントに設定された `action` と、オーバーライドした設定済のルールアクションを示す `overriddenAction` とともに、`ruleGroupList` に表示されます。 1. **DDoS 対策ウェブリクエストの処理をカスタマイズする** 必要に応じて、リクエストを明示的に許可またはブロックする独自のルールを追加して、DDoS 対策ルールがそのリクエストを処理する方法を変更します。例えば、DDoS 対策ラベルを使用して、リクエストを許可またはブロックしたり、リクエスト処理をカスタマイズしたりできます。DDoS 対策マネージドルールグループの後にラベル一致ルールを追加して、適用する処理のためにラベル付きリクエストをフィルタリングできます。テスト後、関連する DDoS 対策ルールをカウントモードで維持し、カスタムルールでリクエストの処理に関する決定を維持します。 1. **テストルールを削除し、DDoS 対策設定を構成する** テスト結果を確認して、モニタリングのみのためにカウントモードで保持する DDoS 対策ルールを決定します。アクティブな保護で実行するルールについては、保護パック (ウェブ ACL) ルールグループ設定でカウントモードを無効にして、設定されたアクションを実行できるようにします。これらの設定を確定したら、本番環境用に作成したカスタムルールを保持しながら、一時的なテストラベル一致ルールを削除します。DDoS 対策設定に関するその他の考慮事項については、「[でのインテリジェントな脅威軽減のベストプラクティス AWS WAF](waf-managed-protections-best-practices.md)」を参照してください。 1. **モニタリングおよびチューニング** ウェブリクエストが希望どおりに処理されていることを確認するには、使用することを希望する DDoS 対策機能を有効にした後、トラフィックを注意深くモニタリングします。ルールグループに対するルールカウントの上書きと独自のルールを使用して、必要に応じて動作を調整します。 # DDoS 対策のベストプラクティス + **通常のトラフィック期間中の保護を有効にする** – これにより、保護は攻撃に対応する前にベースライントラフィックパターンを確立できます。攻撃が発生していない場合は保護を追加し、ベースライン確立の時間を確保します。 + **メトリクスを定期的にモニタリングする** – CloudWatch メトリクスを確認して、トラフィックパターンと保護の有効性を理解します。 + **重要なアプリケーションにはプロアクティブモードを検討する** – ほとんどのユースケースではリアクティブモードが推奨されますが、既知の脅威に対する継続的な保護を必要とするアプリケーションにはプロアクティブモードの使用を検討してください。 + **ステージング環境でテストする** – 本番環境で保護を有効にする前に、ステージング環境で設定をテストおよび調整して、正当なトラフィックへの影響を理解します。 # でのクライアントアプリケーション統合 AWS WAF このセクションでは、インテリジェントな脅威統合 APIsと JavaScript CAPTCHA 統合 API を AWS WAF の機能で使用する方法について説明します。 AWS WAF クライアントアプリケーション統合 APIs を使用して、クライアント側の保護と AWS サーバー側の保護パック (ウェブ ACL) 保護を組み合わせて、保護されたリソースにウェブリクエストを送信するクライアントアプリケーションが意図したクライアントであり、エンドユーザーが人間であることを確認します。クライアント統合を使用して、サイレントブラウザのチャレンジと CAPTCHA パズルを管理し、ブラウザとエンドユーザーの応答が成功したことを証明するトークンを取得し、保護されたエンドポイントへのリクエストにこれらのトークンを含めます。 AWS WAF トークンの一般的な情報については、「」を参照してください[AWS WAF インテリジェントな脅威の軽減におけるトークンの使用](waf-tokens.md)。クライアント統合を、リソースへのアクセスに有効なトークンを必要とする保護パック (ウェブ ACL) 保護と組み合わせます。次のセクション [インテリジェントな脅威統合と AWS マネージドルール](waf-application-integration-with-AMRs.md) に示されているような、チャレンジトークンをチェックおよびモニタリングするルールグループを使用できるため、「[CAPTCHA および Challengeの AWS WAF](waf-captcha-and-challenge.md)」の説明に従い、CAPTCHA および Challenge ルールアクションを使用してチェックします。 AWS WAF は、JavaScript アプリケーションには 2 つのレベルの統合を提供し、モバイルアプリケーションには 1 つのレベルの統合を提供します。 + **インテリジェントな脅威統合** – クライアントアプリケーションを検証し、 AWS トークンの取得と管理を提供します。これは、ルールアクションによって提供される機能に似ています AWS WAF Challenge。この機能により、クライアントアプリケーションは、`AWSManagedRulesACFPRuleSet` マネージドルールグループ、`AWSManagedRulesATPRuleSet` マネージドルールグループ、および `AWSManagedRulesBotControlRuleSet` マネージドルールグループのターゲットを絞った保護レベルと完全に統合されます。インテリジェントな脅威統合 APIs AWS WAF 、サイレントブラウザチャレンジを使用して、クライアントが有効なトークンを取得した後にのみ、保護されたリソースへのログイン試行やその他の呼び出しが許可されるようにします。API は、クライアントアプリケーションセッションのトークン認可を管理し、クライアントに関する情報を収集して、ボットによる操作か、人間による操作かを判断します。 **注記** JavaScript ならびに Android および iOS モバイルアプリケーションで使用できます。 + **CAPTCHA 統合** – アプリケーションで管理するカスタマイズされた CAPTCHA パズルでエンドユーザーを検証します。これはルールアクションによって AWS WAF CAPTCHA提供される機能に似ていますが、パズルの配置と動作をさらに制御できます。この統合では、JavaScript のインテリジェントな脅威統合を活用してサイレントチャレンジを実行し、顧客のページに AWS WAF トークンを提供します。 **注記** これは JavaScript アプリケーションで使用できます。 **Topics** + [ # インテリジェントな脅威統合と AWS マネージドルール ](waf-application-integration-with-AMRs.md) + [ # AWS WAF クライアントアプリケーション統合 APIs へのアクセス ](waf-application-integration-location-in-console.md) + [ # AWS WAF JavaScript 統合 ](waf-javascript-api.md) + [ # AWS WAF モバイルアプリケーションの統合 ](waf-mobile-sdk.md) # インテリジェントな脅威統合と AWS マネージドルールこのセクションでは、インテリジェントな脅威統合 APIs AWS Managed Rules ルールグループと連携する方法について説明します。インテリジェントな脅威統合 API は、インテリジェントな脅威ルールグループを使用する保護パック (ウェブ ACL) と連携して、これらの高度なマネージドルールグループの全機能を有効にします。 + AWS WAF Fraud Control アカウント作成不正防止 (ACFP) マネージドルールグループ `AWSManagedRulesACFPRuleSet`。アカウント作成の不正行為は、サインアップボーナスの受け取りやなりすましなどの目的で、攻撃者がアプリケーションで無効なアカウントを作成するオンライン上の違法行為です。ACFP マネージドルールグループには、不正なアカウント作成の試みの一部の可能性があるリクエストをブロック、ラベル付け、管理するためのルールが含まれています。API は、ACFP ルールが使用する微調整されたクライアントブラウザの検証および人間のインタラクティビティに関する情報を有効にし、有効なクライアントトラフィックを悪意のあるトラフィックから分離します。詳細については、「[AWS WAF Fraud Control アカウント作成不正防止 (ACFP) ルールグループ](aws-managed-rule-groups-acfp.md)」および「[AWS WAF Fraud Control アカウント作成不正防止 (ACFP)](waf-acfp.md)」を参照してください。 + AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) マネージドルールグループ `AWSManagedRulesATPRuleSet`。アカウント乗っ取りは、攻撃者が個人のアカウントへの不正アクセスを得るオンラインの違法行為です。ATP マネージドルールグループには、悪意のあるアカウント乗っ取りの試行の一部の可能性があるリクエストをブロック、ラベル付け、管理するためのルールが含まれています。API は、ATP ルールが使用する微調整されたクライアント検証および動作集約を有効にし、有効なクライアントトラフィックを悪意のあるトラフィックから分離します。詳細については、「[AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループ](aws-managed-rule-groups-atp.md)」および「[AWS WAF Fraud Control アカウント乗っ取り防止 (ATP)](waf-atp.md)」を参照してください。 + AWS WAF Bot Control マネージドルールグループのターゲットを絞った保護レベル`AWSManagedRulesBotControlRuleSet`。ボットには、ほとんどの検索エンジンやクローラーなど、自己識別型や便利なボットから、ウェブサイトを狙って動作し、自己識別を行わない悪意のあるものまでの範囲に及びます。Bot Control マネージドルールグループは、ウェブトラフィックのボットアクティビティをモニタリング、ラベル付け、管理するルールを提供します。このルールグループのターゲットを絞った保護レベルを使用すると、ターゲットルールは API が提供するクライアントセッション情報を使用し、悪意のあるボットをより適切に検出します。詳細については、「[AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md)」および「[AWS WAF ボットコントロール](waf-bot-control.md)」を参照してください。これらのマネージドルールグループのいずれかを保護パック (ウェブ ACL) に追加するには、手順 [ACFP マネージドルールグループをウェブ ACL に追加](waf-acfp-rg-using.md)、[ATP マネージドルールグループを保護パック (ウェブ ACL) に追加](waf-atp-rg-using.md)、[AWS WAF Bot Control マネージドルールグループをウェブ ACL に追加する](waf-bot-control-rg-using.md) を参照してください。 **注記** マネージドルールグループは現在、トークンが不足しているリクエストをブロックしていません。トークンが不足しているリクエストをブロックするには、アプリケーション統合 API を実装した後、[有効な AWS WAF トークンを持たないリクエストのブロック](waf-tokens-block-missing-tokens.md) のガイダンスに従ってください。 # AWS WAF クライアントアプリケーション統合 APIs へのアクセスこのセクションでは、 AWS WAF コンソールでアプリケーション統合 APIsを見つける場所について説明します。 JavaScript 統合 API は一般利用可能で、JavaScript を実行するブラウザや他のデバイスに使用できます。 AWS WAF は、Android および iOS モバイルアプリ用のカスタムのインテリジェントな脅威統合 SDKs を提供します。 + Android モバイルと TV アプリの場合、 SDK は Android API バージョン 23 (Android バージョン 6) 以降で動作します。Android バージョンの詳細については、「[SDK Platform リリースノート](https://developer.android.com/tools/releases/platforms)」を参照してください。 + iOS モバイルアプリの場合、 SDK は iOS バージョン 13 以降で動作します。iOS バージョンの詳細については、「[iOS と iPadOS のリリースノート](https://developer.apple.com/documentation/ios-ipados-release-notes)」を参照してください。 + Apple TV アプリの場合、SDK は tvOS バージョン 14 以降で動作します。tvOS バージョンの詳細については、「[tvOS のリリースノート](https://developer.apple.com/documentation/tvos-release-notes)」を参照してください。 **コンソールで統合 API にアクセスするには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインの **[アプリケーション統合]** を選択してから、関心のあるタブを選択します。 + **インテリジェントな脅威に対応した統合** は、JavaScript とモバイルアプリケーションで使用できます。タブには次のものが含まれています。 + インテリジェントな脅威に対応したアプリケーション統合が有効になっている保護パック (ウェブ ACL) のリスト。リストには、`AWSManagedRulesACFPRuleSet` マネージドルールグループ、`AWSManagedRulesATPRuleSet` マネージドルールグループ、または `AWSManagedRulesBotControlRuleSet` マネージドルールグループのターゲットを絞った保護レベルを使用する各保護パック (ウェブ ACL) が含まれます。インテリジェントな脅威に対応した API を実装するときは、統合する保護パック (ウェブ ACL) の統合 URL を使用します。 + ユーザーがアクセスできる API。JavaScript API は常に利用可能です。モバイル SDK にアクセスするには、「[AWSへのお問い合わせ](https://aws.amazon.com/contact-us)」にてサポート担当者までお問い合わせください。 + **CAPTCHA 統合**は、JavaScript アプリケーションで使用できます。タブには次のものが含まれています。 + 統合で使用する統合 URL。 + クライアントアプリケーションドメイン用に作成した API キー。CAPTCHA API を使用するには、暗号化された API キーが必要です。これにより、クライアントは自分のドメインから AWS WAF CAPTCHA にアクセスできるようになります。統合するクライアントごとに、クライアントのドメインを含む API キーを使用します。これらの要件とキーの管理の詳細については、「[JS CAPTCHA API の API キーの管理](waf-js-captcha-api-key.md)」を参照してください。 # AWS WAF JavaScript 統合このセクションでは、 AWS WAF JavaScript 統合を使用する方法について説明します。 JavaScript 統合 APIs を使用して、JavaScript を実行するブラウザやその他のデバイスに AWS WAF アプリケーション統合を実装できます。 CAPTCHA パズルとサイレントチャレンジは、ブラウザが HTTPS エンドポイントにアクセスしている場合にのみ実行できます。トークンを取得するには、ブラウザクライアントが安全なコンテキストで実行されている必要があります。 + インテリジェントな脅威に対応した API を使用すると、クライアント側のサイレントブラウザのチャレンジを通じてトークン認可を管理し、保護されたリソースに送信するリクエストにトークンを含めることができます。 + CAPTCHA 統合 API にインテリジェントな脅威に対応した API が追加され、クライアントアプリケーションでの CAPTCHA パズルの配置と特性をカスタマイズすることができるようになりました。この API は、インテリジェントな脅威に対応した API を活用し、エンドユーザーが CAPTCHA パズルの完成に成功した後にページで使用する AWS WAF トークンを取得します。これらの統合を使用すると、クライアントによるリモートプロシージャコールに有効なトークンが含まれていることを確認できます。これらの統合 API がアプリケーションのページで実行されている場合、有効なトークンを含まないリクエストをブロックするなどの緩和ルールを保護パック (ウェブ ACL) で実装できます。ルール内の Challenge または CAPTCHA アクションを使用して、クライアントアプリケーションが取得したトークンの使用を強制するルールを実装することもできます。 **インテリジェントな脅威 API の実施例** 次のリストは、ウェブアプリケーションページでのインテリジェントな脅威に対応した API の一般的な実装の基本コンポーネントを示しています。 ``` ``` **CAPTCHA JavaScript API の実施例** CAPTCHA 統合 API を使用すると、エンドユーザーの CAPTCHA パズルエクスペリエンスをカスタマイズできます。CAPTCHA 統合では、ブラウザの検証とトークン管理用に JavaScript のインテリジェントな脅威に対応した統合が活用されているだけでなく、CAPTCHA パズルの設定とレンダリング用の機能も追加されています。次のリストは、ウェブアプリケーションページでの CAPTCHA JavaScript API の一般的な実装の基本コンポーネントを示しています。 ```

``` **Topics** + [ # トークンで使用するドメインの提供 ](waf-js-challenge-api-set-token-domain.md) + [ # コンテンツセキュリティポリシーでの JavaScript API の使用 ](waf-javascript-api-csp.md) + [ # インテリジェントな脅威に対応した JavaScript API の使用 ](waf-js-challenge-api.md) + [ # CAPTCHA JavaScript API を使用する ](waf-js-captcha-api.md) # トークンで使用するドメインの提供このセクションでは、トークンに追加のドメインを提供する方法について説明します。デフォルトでは、がトークン AWS WAF を作成すると、保護パック (ウェブ ACL) に関連付けられているリソースのホストドメインが使用されます。 AWS WAF が JavaScript API 用に作成するトークンには、追加のドメインを指定できます。これを行うには、グローバル変数 `window.awsWafCookieDomainList` に 1 つ以上のトークンドメインを設定します。がトークン AWS WAF を作成すると、のドメイン`window.awsWafCookieDomainList`と、保護パック (ウェブ ACL) に関連付けられているリソースのホストドメインの組み合わせの中から、最も適切で最短のドメインが使用されます。設定の例 ``` window.awsWafCookieDomainList = ['.aws.amazon.com'] ``` ``` window.awsWafCookieDomainList = ['.aws.amazon.com', 'abc.aws.amazon.com'] ``` このリストではパブリックサフィックスを使用できません。例えば、`gov.au` または `co.uk` をリストでトークンドメインとして使用することはできません。このリストで指定するドメインは、他のドメインやドメイン設定と互換性がある必要があります。 + ドメインは、保護されたホストドメインと、保護パック (ウェブ ACL) 用に設定されたトークンドメインリストに基づいて、が AWS WAF 受け入れるドメインである必要があります。詳細については、「[AWS WAF 保護パック (ウェブ ACL) トークンドメインリスト設定](waf-tokens-domains.md#waf-tokens-domain-lists)」を参照してください。 + JavaScript CAPTCHA API を使用する場合、CAPTCHA API キー内の少なくとも 1 つのドメインが、`window.awsWafCookieDomainList` のトークンドメインの 1 つと完全に一致するか、いずれかのトークンドメインの apex ドメインである必要があります。例えば、トークンドメイン `mySubdomain.myApex.com` の場合、API キー `mySubdomain.myApex.com` は完全に一致し、API キー `myApex.com` は apex ドメインです。どちらかのキーがトークンドメインに一致します。 API キーの詳細については、「[JS CAPTCHA API の API キーの管理](waf-js-captcha-api-key.md)」を参照してください。 `AWSManagedRulesACFPRuleSet` マネージドルールグループを使用する場合、ルールグループ設定に指定したアカウント作成パスのドメインと一致するドメインを設定できます。この設定の詳細については、「[ACFP マネージドルールグループをウェブ ACL に追加](waf-acfp-rg-using.md)」を参照してください。 `AWSManagedRulesATPRuleSet` マネージドルールグループを使用する場合、ルールグループ設定に指定したログインパスのドメインと一致するドメインを設定できます。この設定の詳細については、「[ATP マネージドルールグループを保護パック (ウェブ ACL) に追加](waf-atp-rg-using.md)」を参照してください。 # コンテンツセキュリティポリシーでの JavaScript API の使用このセクションでは、apex AWS WAF ドメインを許可リストに登録するための設定例を示します。コンテンツセキュリティポリシー (CSP) をリソースに適用し、JavaScript 実装を機能させるには、apex AWS WAF ドメインを許可リストに登録する必要があります`awswaf.com`。JavaScript SDK は異なる AWS WAF エンドポイントを呼び出すため、このドメインを許可リストに登録すると、SDK の動作に必要な権限が付与されます。以下は、apex AWS WAF ドメインを許可リストに登録するための設定例です。 ``` connect-src 'self' https://*.awswaf.com; script-src 'self' https://*.awswaf.com; script-src-elem 'self' https://*.awswaf.com; ``` CSP を使用するリソースで JavaScript SDKs を使用しようとしたときに、 AWS WAF ドメインを許可リストに登録していない場合は、次のようなエラーが表示されます。 ``` Refused to load the script ...awswaf.com/<> because it violates the following Content Security Policy directive: “script-src ‘self’ ``` # インテリジェントな脅威に対応した JavaScript API の使用このセクションでは、クライアントアプリケーションでインテリジェントな脅威 JavaScript API を使用する手順について説明します。インテリジェントな脅威 APIsは、ユーザーのブラウザに対してサイレントチャレンジを実行するオペレーションと、チャレンジと CAPTCHA レスポンスが成功した証拠を提供する AWS WAF トークンを処理するオペレーションを提供します。 JavaScript 統合を最初にテスト環境で実装し、次に本番環境で実装します。追加のコーディングガイダンスについては、次のセクションを参照してください。 **インテリジェントな脅威に対応した API を使用するには** 1. **API のインストール** CAPTCHA API を使用している場合は、このステップをスキップできます。CAPTCHA API をインストールすると、スクリプトはインテリジェントな脅威に対応した API を自動的にインストールします。 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで、**[Application integration]** (アプリケーション統合) を選択します。**[アプリケーション統合]** ページに、タブ付きのオプションが表示されます。 1. **[インテリジェントな脅威に対応した統合]** を選択 1. タブで、統合する保護パック (ウェブ ACL) を選択します。保護パック (ウェブ ACL) リストには、`AWSManagedRulesACFPRuleSet` マネージドルールグループ、`AWSManagedRulesATPRuleSet` マネージドルールグループ、または `AWSManagedRulesBotControlRuleSet` マネージドルールグループのターゲットを絞った保護レベルを使用する保護パック (ウェブ ACL) のみが含まれます。 1. **[JavaScript SDK]** ペインを開き、統合で使用するスクリプトタグをコピーします。 1. `` セクションのアプリケーションページコードに、保護パック (ウェブ ACL) 用にコピーしたスクリプトタグを挿入します。この包含により、クライアントアプリケーションは、ページをロードする際にバックグラウンドでトークンを自動的に取得します。 ``` ``` **クライアントがデフォルトで `aws-waf-token` Cookie にアタッチしない場合のトークンとのアタッチ** `AwsWafIntegration.getToken()` は有効なトークンを取得し、それを Cookie として保存しますが、デフォルトの場合、すべてのクライアント呼び出しがこの Cookie にアタッチするわけではありません。例えば、ホストドメイン間で行われた呼び出しは Cookie にアタッチしません。 `fetch` ラッパーはこれらのケースを自動的に処理しますが、`fetch`ラッパーを使用できない場合は、Cookie から読み取るだけでなく、このヘッダーのカスタム `x-aws-waf-token` header. AWS WAF reads `aws-waf-token` トークンを使用して処理できます。次のコードは、ヘッダーの設定例を示しています。 ``` const token = await AwsWafIntegration.getToken(); const result = await fetch('/url', { headers: { 'x-aws-waf-token': token, }, }); ``` デフォルトでは、はリクエストされたホストドメインと同じドメインを含むトークン AWS WAF のみを受け入れます。クロスドメイントークンには、保護パック (ウェブ ACL) トークンドメインリストの対応するエントリが必要です。詳細については、「[AWS WAF 保護パック (ウェブ ACL) トークンドメインリスト設定](waf-tokens-domains.md#waf-tokens-domain-lists)」を参照してください。クロスドメイントークンの使用の詳細については、「[aws-samples/aws-waf-bot-control-api-protection-with-captcha](https://github.com/aws-samples/aws-waf-bot-control-api-protection-with-captcha)」を参照してください。 # CAPTCHA JavaScript API を使用するこのセクションでは、CAPTCHA 統合 API を使用する手順について説明します。 CAPTCHA JavaScript API を使用すると、CAPTCHA パズルを設定し、クライアントアプリケーションの任意の場所に配置できます。この API は、インテリジェントな脅威の JavaScript APIs の機能を活用して、エンドユーザーが CAPTCHA パズルを正常に完了した後に AWS WAF トークンを取得して使用します。 JavaScript 統合を最初にテスト環境で実装し、次に本番環境で実装します。追加のコーディングガイダンスについては、次のセクションを参照してください。 **CAPTCHA 統合 API を使用するには** 1. **API のインストール** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで、**[Application integration]** (アプリケーション統合) を選択します。**[アプリケーション統合]** ページに、タブ付きのオプションが表示されます。 1. **[CAPTCHA 統合]** を選択します。 1. リストされている JavaScript 統合スクリプトタグをコピーして、統合で使用します。 1. `` セクションのアプリケーションページコードに、コピーしたスクリプトタグを挿入します。これにより、CAPTCHA パズルの設定および使用が可能になります。 ``` ``` この `

``` **構成設定の例** 次のリストの例は、幅とタイトルのオプションをデフォルト以外で設定した `renderCaptcha` を示しています。 ``` AwsWafCaptcha.renderCaptcha(container, { apiKey: "...API key goes here...", onSuccess: captchaExampleSuccessFunction, onError: captchaExampleErrorFunction, dynamicWidth: true, skipTitle: true }); ``` 設定オプションの詳細な情報については、「[CAPTCHA JavaScript API 仕様](waf-js-captcha-api-specification.md)」を参照してください。 # からの CAPTCHA レスポンスの処理 AWS WAF このセクションでは、CAPTCHA レスポンスを処理する例を示します。 CAPTCHA アクションを持つ AWS WAF ルールは、リクエストに有効な CAPTCHA タイムスタンプを持つトークンがない場合、一致するウェブリクエストの評価を終了します。リクエストが `GET` テキスト/HTML 呼び出しの場合、CAPTCHA アクションは CAPTCHA パズルを含むインタースティシャルをクライアントに提供します。CAPTCHA JavaScript API を統合しない場合、インタースティシャルはパズルを実行し、エンドユーザーが問題を正しく解決すると、自動的にリクエストを再送信します。 CAPTCHA JavaScript API を統合し、CAPTCHA 処理をカスタマイズする場合は、終了 CAPTCHA レスポンスを検出し、カスタム CAPTCHA を提供する必要があります。その後、エンドユーザーがパズルを正しく解決した場合は、クライアントのウェブリクエストを再送信します。次のコード例は、これを実行する方法を説明しています。 **注記** AWS WAF CAPTCHA アクションレスポンスのステータスコードは HTTP 405 で、このコードのCAPTCHAレスポンスを認識するために使用します。保護されたエンドポイントが HTTP 405 ステータスコードを使用して同じ呼び出しのために他の種類のレスポンスを通信する場合、このサンプルコードはそれらのレスポンスのためにも CAPTCHA パズルをレンダリングします。 ```

``` # JS CAPTCHA API の API キーの管理このセクションでは、API キーを生成および削除する手順について説明します。 JavaScript API を使用して AWS WAF CAPTCHA をクライアントアプリケーションに統合するには、JavaScript API 統合タグと、CAPTCHA パズルを実行するクライアントドメインの暗号化された API キーが必要です。 JavaScript の CAPTCHA アプリケーション統合では、暗号化された API キーを使用して、クライアントアプリケーションドメインに CAPTCHA API AWS WAF を使用するアクセス許可があることを確認します。JavaScript クライアントから CAPTCHA API を呼び出すときは、現在のクライアントのドメインを含むドメインリストに API キーを含めます。1 つの暗号化キーに最大 5 つのドメインを列挙することができます。 **API キー要件** CAPTCHA 統合で使用する API キーには、そのキーを使用するクライアントに適用されるドメインが含まれている必要があります。 + クライアントのインテリジェントな脅威に対応した統合で `window.awsWafCookieDomainList` を指定する場合、API キーの少なくとも 1 つのドメインが `window.awsWafCookieDomainList` のトークンドメインの 1 つと完全一致するか、いずれかのトークンドメインの apex ドメインである必要があります。例えば、トークンドメイン `mySubdomain.myApex.com` の場合、API キー `mySubdomain.myApex.com` は完全に一致し、API キー `myApex.com` は apex ドメインです。どちらかのキーがトークンドメインに一致します。トークンドメインリストの設定については、「[トークンで使用するドメインの提供](waf-js-challenge-api-set-token-domain.md)」を参照してください。 + それ以外の場合は、現在のドメインが API キーに含まれている必要があります。現在のドメインは、ブラウザのアドレスバーで確認できるドメインです。使用するドメインは、保護されたホストドメインとウェブ ACL 用に設定されたトークンドメインリストに基づいて、が AWS WAF 受け入れるドメインである必要があります。詳細については、「[AWS WAF 保護パック (ウェブ ACL) トークンドメインリスト設定](waf-tokens-domains.md#waf-tokens-domain-lists)」を参照してください。 **API キーのリージョンを選択する方法** AWS WAF は、 AWS WAF が利用可能な任意のリージョンで CAPTCHA API キーを生成できます。原則として、保護パック (ウェブ ACL) に使用するのと同じリージョンを CAPTCHA API キーに使用する必要があります。ただし、リージョナル保護パック (ウェブ ACL) のグローバルオーディエンスが予想される場合は、CloudFront にスコープされた CAPTCHA JavaScript 統合タグと CloudFront にスコープされた API キーを取得し、リージョナル保護パック (ウェブ ACL) で使用できます。このアプローチにより、クライアントは自分に最も近いリージョンから CAPTCHA パズルをロードできるため、レイテンシーが短縮されます。 CloudFront 以外のリージョンに限定されている CAPTCHA API キーは、複数のリージョンでは使用できません。これらは、限定されたリージョンでのみ使用できます。 **クライアントドメインの API キーを生成するには** 統合 URL を取得し、コンソールを介して API キーを生成および取得するには。 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで、**[Application integration]** (アプリケーション統合) を選択します。 1. ペインで、**[アプリケーション統合のために有効にする保護パック (ウェブ ACL)]** で、API キーに使用したいリージョンを選択します。**[CAPTCHA 統合]** タブの **[API キー]** ペインでリージョンを選択することもできます。 1. タブ **[CAPTCHA 統合]** を選択します。このタブには、統合で使用できる CAPTCHA JavaScript 統合タグと API キーリストが表示されます。どちらも選択したリージョンに限定されます。 1. **[API キー]** ペインで、**[キーを生成]** を選択します。[キー生成] ダイアログが表示されます。 1. キーに含めるクライアントドメインを入力します。最大 5 つまで入力できます。完了したら、**[キーを生成]** を選択します。インターフェイスが CAPTCHA 統合タブに戻り、新しいキーが一覧表示されます。一度作成された API キーは、イミュータブルです。キーを変更する必要がある場合は、新しいキーを生成し、代わりにそれを使用します。 1. (オプション) 新しく生成されたキーをコピーして、統合で使用します。この作業には、REST APIs または言語固有の AWS SDKsのいずれかを使用することもできます。REST API コールは「[CreateAPIKey](https://docs.aws.amazon.com/waf/latest/APIReference/API_CreateAPIKey.html)」と「[ListAPIKeys](https://docs.aws.amazon.com/waf/latest/APIReference/API_ListAPIKeys.html)」です。 **API を削除するには** API キーを削除するには、REST API または言語固有の AWS SDKsのいずれかを使用する必要があります。REST API コールは「[DeleteAPIKey](https://docs.aws.amazon.com/waf/latest/APIReference/API_DeleteAPIKey.html)」です。コンソールでキーを削除することはできません。キーを削除すると、がすべてのリージョンでキーの使用を禁止する AWS WAF までに最大 24 時間かかることがあります。 # AWS WAF モバイルアプリケーションの統合このセクションでは、 AWS WAF モバイル SDKs を使用して、Android および iOS モバイルアプリと TV アプリ用の AWS WAF インテリジェントな脅威統合 SDKs を実装するトピックを紹介します。TV アプリの場合、SDK は Android TV や Apple TV などの主要なスマート TV プラットフォームと互換性があります。 + Android モバイルと TV アプリの場合、 SDK は Android API バージョン 23 (Android バージョン 6) 以降で動作します。Android バージョンの詳細については、「[SDK Platform リリースノート](https://developer.android.com/tools/releases/platforms)」を参照してください。 + iOS モバイルアプリの場合、 SDK は iOS バージョン 13 以降で動作します。iOS バージョンの詳細については、「[iOS と iPadOS のリリースノート](https://developer.apple.com/documentation/ios-ipados-release-notes)」を参照してください。 + Apple TV アプリの場合、SDK は tvOS バージョン 14 以降で動作します。tvOS バージョンの詳細については、「[tvOS のリリースノート](https://developer.apple.com/documentation/tvos-release-notes)」を参照してください。モバイル AWS WAF SDK を使用すると、トークン認可を管理し、保護されたリソースに送信するリクエストにトークンを含めることができます。SDK を使用すると、クライアントによるこれらのリモートプロシージャコールに有効なトークンが含まれていることを確認できます。さらに、この統合がアプリケーションのページで実行されている場合、有効なトークンを含まないリクエストをブロックするなど、保護パック (ウェブ ACL) で緩和ルールを実装できます。モバイル SDK にアクセスするには、「[AWSへのお問い合わせ](https://aws.amazon.com/contact-us)」にてサポート担当者までお問い合わせください。 **注記** AWS WAF モバイル SDKs は CAPTCHA のカスタマイズには使用できません。 SDK を使用するための基本的なアプローチは、設定オブジェクトを使用してトークンプロバイダーを作成し、トークンプロバイダーを使用してトークンを取得することです AWS WAF。デフォルトでは、トークンプロバイダーは、保護されたリソースに対するウェブリクエストに取得したトークンを含めます。主要なコンポーネントを示す SDK 実装の一部を次に示します。詳細な例については、「[AWS WAF モバイル SDK のコード例](waf-mobile-sdk-coding-examples.md)」を参照してください。 ------ #### [ iOS ] ``` let url: URL = URL(string: "protection pack (web ACL) integration URL")! let configuration = WAFConfiguration(applicationIntegrationUrl: url, domainName: "Domain name") let tokenProvider = WAFTokenProvider(configuration) let token = tokenProvider.getToken() ``` ------ #### [ Android ] ``` URL applicationIntegrationURL = new URL("protection pack (web ACL) integration URL"); String domainName = "Domain name"; WAFConfiguration configuration = WAFConfiguration.builder().applicationIntegrationURL(applicationIntegrationURL).domainName(domainName).build(); WAFTokenProvider tokenProvider = new WAFTokenProvider(Application context, configuration); WAFToken token = tokenProvider.getToken(); ``` ------ # AWS WAF モバイル SDK のインストールこのセクションでは、 AWS WAF モバイル SDK をインストールする手順について説明します。モバイル SDK にアクセスするには、「[AWSへのお問い合わせ](https://aws.amazon.com/contact-us)」にてサポート担当者までお問い合わせください。モバイル SDK を最初にテスト環境で実装し、次に本番環境で実装します。 **AWS WAF モバイル SDK をインストールするには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで、**[Application integration]** (アプリケーション統合) を選択します。 1. **[インテリジェントな脅威に対応した統合]** タブで、次の操作を行います。 1. **[アプリケーション統合が有効になっている保護パック (ウェブ ACL)]** ペインで、統合する保護パック (ウェブ ACL) を見つけます。実装で使用するアプリケーション統合が有効になっている保護パック (ウェブ ACL) 統合 URL をコピーして保存します。この URL は、API コール `GetWebACL` を通じて取得することもできます。 1. モバイルデバイスのタイプとバージョンを選択してから、**[Download]** (ダウンロード) を選択します。任意のバージョンを選択できますが、最新バージョンを使用することをお勧めします。はデバイスの`zip`ファイルを標準のダウンロード場所に AWS WAF ダウンロードします。 1. アプリケーション開発環境で、ファイルを任意の作業場所に解凍します。zip ファイルの最上位ディレクトリで、`README` を見つけて開きます。ファイルの指示`README`に従って、 AWS WAF モバイルアプリコードで使用するモバイル SDK をインストールします。 1. 次のセクションのガイダンスに従って、アプリケーションをプログラムします。 # AWS WAF モバイル SDK 仕様このセクションでは、 AWS WAF モバイル SDK の利用可能な最新バージョンに対応する SDK オブジェクト、オペレーション、および構成設定を一覧表示します。構成設定のさまざまな組み合わせでトークンプロバイダーとオペレーションがどのように連携するかについては、「[AWS WAF モバイル SDK の仕組み](waf-mobile-sdk-how-it-works.md)」を参照してください。 **`WAFToken`** AWS WAF トークンを保持します。 **`getValue()`** `WAFToken` の `String` 表現を取得します。 **`WAFTokenProvider`** モバイルアプリケーションでトークンを管理します。`WAFConfiguration` オブジェクトを使用してこれを実装します。 **`getToken()`** バックグラウンド更新が有効になっている場合、キャッシュされたトークンが返されます。バックグラウンド更新が無効になっている場合、への同期呼び出しがブロック AWS WAF され、新しいトークンを取得します。 **`loadTokenIntoProvider(WAFToken)`** 指定されたトークンを `WAFTokenProvider` にロードし、プロバイダーが管理していたトークンを置き換えます。トークンプロバイダーは新しいトークンの所有権を取得し、今後の更新を処理します。このオペレーションでは、`WAFConfiguration` で `setTokenCookie` が有効になっている場合、Cookie ストアのトークンも更新されます。 **`onTokenReady(WAFTokenResultCallback)`** アクティブなトークンの準備ができたら、トークンを更新し、指定されたコールバックを呼び出すようにトークンプロバイダーに指示します。トークンプロバイダーは、トークンがキャッシュされて準備ができたときに、バックグラウンドスレッドでコールバックを呼び出します。アプリケーションが最初にロードされたときや、アクティブ状態に戻ったときにこれを呼び出します。アクティブ状態に戻ることの詳細については、「[アプリケーションが非アクティブ状態になった後のトークンの取得](waf-mobile-sdk-how-it-works.md#waf-mobile-sdk-how-back-from-inactive)」を参照してください。 Android または iOS アプリケーションの場合、`WAFTokenResultCallback` を、リクエストされたトークンの準備ができたときにトークンプロバイダーが呼び出すオペレーションに設定できます。`WAFTokenResultCallback` の実装では、パラメータ `WAFToken`、`SdkError` を取得する必要があります。iOS アプリケーションでは、代わりにインライン関数を作成できます。 **`storeTokenInCookieStorage(WAFToken)`** 指定された AWS WAF トークンを SDK の Cookie マネージャーに保存`WAFTokenProvider`するようにに指示します。デフォルトでは、トークンは最初に取得されたときと更新されたときのみ、Cookie ストアに追加されます。アプリケーションが何らかの理由で共有 Cookie ストアをクリアした場合、SDK は次回の更新まで AWS WAF トークンを自動的に追加しません。 **`WAFConfiguration`** `WAFTokenProvider` の実装のための設定を保持します。これを実装すると、保護パック (ウェブ ACL) の統合 URL、トークンで使用するドメイン名、トークンプロバイダーが使用するデフォルト以外の設定を指定します。次のリストは、`WAFConfiguration` オブジェクトで管理できる構成設定を示しています。 **`applicationIntegrationUrl`** アプリケーション統合 URL。これを AWS WAF コンソールまたは `getWebACL` API コールから取得します。必須: はいタイプ: アプリケーション固有の URL。iOS の場合は、「[iOS URL](https://developer.apple.com/documentation/foundation/url)」を参照してください。Android の場合は、「[java.net URL](https://docs.oracle.com/javase/7/docs/api/java/net/URL.html)」を参照してください。 **`backgroundRefreshEnabled`** トークンプロバイダーがバックグラウンドでトークンを更新するかどうかを示します。これを設定すると、トークンプロバイダーは、自動トークン更新アクティビティを管理する構成設定に従って、バックグラウンドでトークンを更新します。必須: いいえタイプ: `Boolean` デフォルト値: `TRUE` **`domainName`** トークンで使用するドメインは、トークン取得とクッキーの保存に使用されます。例えば、`example.com`、`aws.amazon.com` です。これは通常、保護パック (ウェブ ACL) に関連付けられているリソースのホストドメインであり、ウェブリクエストの送信先です。ACFP マネージドルールグループ `AWSManagedRulesACFPRuleSet` の場合、通常はルールグループ設定で指定したアカウント作成パスのドメインと一致する単一のドメインになります。ATP マネージドルールグループ `AWSManagedRulesATPRuleSet` の場合、通常はルールグループ設定で指定したログインパスのドメインと一致する単一のドメインになります。パブリックサフィックスは許可されません。たとえば、`gov.au` または `co.uk` をトークンドメインとして使用することはできません。ドメインは、保護されたホストドメインと保護パック (ウェブ ACL) のトークンドメインリストに基づいて、 AWS WAF が受け入れるドメインである必要があります。詳細については、「[AWS WAF 保護パック (ウェブ ACL) トークンドメインリスト設定](waf-tokens-domains.md#waf-tokens-domain-lists)」を参照してください。必須: はいタイプ: `String` **`maxErrorTokenRefreshDelayMsec`** 失敗した試行後にトークンの更新を繰り返すまでの待機時間の最大値 (ミリ秒)。失敗した試行の自動再試行ごとに、指定された入力遅延時間までエクスポネンシャルバックオフが追加されます。この値は、トークンの取得が失敗し、`maxRetryCount` 回再試行された後に使用されます。必須: いいえタイプ: `Integer` デフォルト値: `5000` (5 秒) 許容される最小値: `1` (1 ミリ秒) 許容される最大値: `30000` (30 秒) **`maxRetryCount`** トークンがリクエストされたときに、エクスポネンシャルバックオフで実行する最大再試行回数。必須: いいえタイプ: `Integer` デフォルト値: `Infinity` 許容される最小値: `0` 許容される最大値: `100` **`setTokenCookie`** SDK の Cookie マネージャーがリクエストに、およびその他のエリアにトークン Cookie を追加するかどうかを示します。 `TRUE` 値の場合: + cookie マネージャーは、パスが `tokenCookiePath` で指定されたパスの下にあるすべてのリクエストにトークン Cookie を追加します。 + `WAFTokenProvider` オペレーションは、トークンプロバイダーにロードするだけでなく、Cookie ストアのトークン `loadTokenIntoProvider()` を更新します。必須: いいえタイプ: `Boolean` デフォルト値: `TRUE` **`tokenCookiePath`** `setTokenCookie` が `TRUE` の場合に使用されます。SDK の cookie マネージャーでトークン cookie を追加する最上位レベルのパスを示します。マネージャーは、このパスに送信するすべてのリクエストとすべての子パスにトークン cookie を追加します。例えば、これを `/web/login` に設定すると、マネージャーには、`/web/login` に送信されるすべてのトークン cookie と、その子パスのいずれかが含まれます (`/web/login/help` など)。`/`、`/web`、`/web/order` などの他のパスに送信されたリクエストのトークンは含まれません。必須: いいえタイプ: `String` デフォルト値: `/` **`tokenRefreshDelaySec`** バックグラウンドの更新に使用されます。バックグラウンドトークンが更新されるまでの最大時間 (秒)。必須: いいえタイプ: `Integer` デフォルト値: `88` 許容される最小値: `88` 許容される最大値: `300` (5 分) ## AWS WAF モバイル SDK エラーこのセクションでは、現在の AWS WAF モバイル SDK バージョンで発生する可能性のあるエラーを一覧表示します。 **`SdkError`** トークンの取得に失敗した場合に返されるエラータイプ。Android と iOS SDK のエラータイプは同じです。 AWS WAF モバイル SDK には次のエラータイプがあります。 **`invalidChallenge`** このエラーは、トークンサーバーが無効なチャレンジデータを返すか、レスポンス BLOB が攻撃者によって変更された場合に返されます。 **`errorInvokingGetChallengeEndpoint`** このエラーは、トークンサーバーが成功しないレスポンスコードをクライアントに返すか、ネットワークエラーが発生したときに返されます。 **`invalidVerifyChallengeResponse`** このエラーは、 AWS WAF サーバーの検証レスポンス`aws-waf-token`からを取得する際にエラーが発生した場合、またはサーバーレスポンスが改ざんされた場合に返されます。 **`errorInvokingVerifyEndpoint`** このエラーは、クライアントが AWS WAF サーバーから不正な応答を受け取ったとき、または解決されたチャレンジを検証するときにネットワークエラーを受け取ったときに返されます。 **`internalError`** このエラーは、SDK 自体の内部で発生する可能性のある他のすべてのエラーに対して返されます。 **`socketTimeoutException`** このエラーは、トークンの取得中にネットワークエラーが発生したときに返されることがよくあります。これにエラー、以下によって発生する可能性があります。 + 低ネットワーク帯域幅: ネットワーク接続設定を確認する + ミューテーションされたアプリケーション統合 URL: AWS WAF コンソールに表示される内容から統合 URL が変更されていないことを確認します。 # AWS WAF モバイル SDK の仕組みこのセクションでは、 AWS WAF モバイル SDK クラス、プロパティ、およびオペレーションがどのように連携するかについて説明します。モバイル SDK は、トークンの取得と利用のために使用できる設定可能なトークンプロバイダーを提供します。トークンプロバイダーは、許可するリクエストが正規の顧客からのものであることを検証します。保護するリソースに AWS リクエストを送信するときは AWS WAF、Cookie にトークンを含めてリクエストを検証します。トークン cookie は手動で処理することも、トークンプロバイダーに処理させることもできます。このセクションでは、モバイル SDK に含まれるクラス、プロパティ、およびメソッド間のインタラクションについて説明します。SDK の仕様については、「[AWS WAF モバイル SDK 仕様](waf-mobile-sdk-specification.md)」を参照してください。 ## トークンの取得とキャッシュモバイルアプリケーションでトークンプロバイダーインスタンスを作成するときに、トークンとトークンの取得を管理する方法を設定します。主に、アプリケーションのウェブリクエストで使用するための、有効で期限切れになっていないトークンを維持する方法を選択できます。 + **[Background refresh enabled]** (バックグラウンド更新が有効) - これがデフォルトのトランスコードプリセットです。トークンプロバイダーは、バックグラウンドでトークンを自動的に更新し、キャッシュします。バックグラウンド更新が有効になっている場合、`getToken()` を呼び出すと、オペレーションはキャッシュされたトークンを取得します。トークンプロバイダーは、設定可能な間隔でトークンの更新を実行します。これにより、アプリケーションがアクティブな間、期限切れでないトークンは常にキャッシュ内で利用可能な状態となります。アプリケーションが非アクティブ状態の間、バックグラウンドの更新が一時停止されます。詳細については、「[アプリケーションが非アクティブ状態になった後のトークンの取得](#waf-mobile-sdk-how-back-from-inactive)」を参照してください。 + **[Background refresh disabled]** (バックグラウンド更新が無効) - バックグラウンドトークンの更新を無効にして、オンデマンドでのみトークンを取得できます。オンデマンドで取得されたトークンはキャッシュされません。また、必要に応じて複数のトークンを取得できます。各トークンは、取得する他のトークンとは独立しており、有効期限を計算するために使用される独自のタイムスタンプを備えています。バックグラウンド更新が無効になっている場合のトークンの取得には、次の選択肢があります。 + **`getToken()`** – バックグラウンド更新を無効に`getToken()`してを呼び出すと、呼び出しは同期的に新しいトークンを取得します AWS WAF。これは、メインスレッドで呼び出すと、アプリケーションの応答性に影響する可能性のあるブロッキング呼び出しである場合があります。 + **`onTokenReady(WAFTokenResultCallback)`** - この呼び出しは、新しいトークンを非同期的に取得し、トークンの準備ができたときに提供された結果コールバックをバックグラウンドスレッドで呼び出します。 ### トークンプロバイダーが失敗したトークンの取得を再試行する方法トークンプロバイダーは、取得に失敗したときにトークンの取得を自動的に再試行します。再試行は、開始の再試行の待ち時間が 100 ミリ秒のエクスポネンシャルバックオフを使用して最初に実行されます。エクスポネンシャル再試行の詳細については、「[AWSでのエラー再試行とエクスポネンシャルバックオフ](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)」を参照してください。再試行回数が設定された `maxRetryCount` に達すると、トークンプロバイダーは、トークン取得のタイプに応じて、試行を停止するか、`maxErrorTokenRefreshDelayMsec` ミリ秒ごとの試行に切り替えます。 + **`onTokenReady()`** – トークンプロバイダーは、試行間の待機時間を `maxErrorTokenRefreshDelayMsec` ミリ秒に切り替えて、トークン取得の試行を続行します。 + **バックグラウンド更新** – トークンプロバイダーは、試行間の待機時間を `maxErrorTokenRefreshDelayMsec` ミリ秒に切り替えて、トークンの取得の試行を続行します。 + **バックグラウンド更新が無効になっている場合のオンデマンド `getToken()` 呼び出し** – トークンプロバイダーはトークンの取得の試行を停止し、前のトークン値を返します。前のトークンがない場合は null 値を返します。 ## トークン取得の再試行シナリオトークンプロバイダーがトークンを取得しようとすると、トークンの取得フローのどこでトークンの取得が失敗するかに応じて、自動再試行が発生する可能性があります。このセクションでは、自動再試行が表示される可能性のある場所を一覧表示します。 + **/inputs または /verify による AWS WAF チャレンジの取得または検証:** + AWS WAF チャレンジを取得して検証するリクエストが行われて失敗すると、自動再試行が発生する可能性があります。 + ここで自動再試行が `socketTimeoutException` エラーとともに発生することがあります。これには、次のような複数の原因が考えられます。 + 低ネットワーク帯域幅: ネットワーク接続設定を確認する + ミューテーションされたアプリケーション統合 URL: AWS WAF コンソールに表示される内容から統合 URL が変更されていないことを確認します。 + 自動再試行カウントは、`maxRetryCount()` 関数で設定できます + **トークンの更新:** + トークンハンドラーを介してトークンの更新リクエストが行われると、自動再試行が発生する可能性があります。 + ここでの自動再試行数は、`maxRetryCount()` 関数で設定できます。自動再試行のない設定は、`maxRetryCount(0)` を設定することで可能です。 ## トークンイミュニティ時間とバックグラウンド更新ウェブ ACL で設定したトークンイミュニティ時間は、 AWS WAF モバイル SDK で設定したトークン更新間隔とは無関係です。バックグラウンド更新を有効にすると、SDK は `tokenRefreshDelaySec()` を使用して指定した間隔でトークンを更新します。これにより、設定されたイミュニティ時間に応じて、複数の有効なトークンが同時に存在する可能性があります。複数の有効なトークンを防ぐには、バックグラウンド更新を無効にし、`getToken()` 関数を使用してモバイルアプリでトークンのライフサイクルを管理できます。 ## アプリケーションが非アクティブ状態になった後のトークンの取得バックグラウンド更新は、アプリケーションがアプリケーションタイプについてアクティブであるとみなされる場合にのみ実行されます。 + **iOS** – バックグラウンド更新は、アプリケーションがフォアグラウンドにあるときに実行されます。 + **Android** - バックグラウンドの更新は、アプリケーションがフォアグラウンドまたはバックグラウンドのいずれにあるかにかかわらず、アプリケーションが閉じられていないときに実行されます。アプリケーションが設定された `tokenRefreshDelaySec` 秒より長くバックグラウンド更新をサポートしない状態のままである場合、トークンプロバイダーはバックグラウンド更新を一時停止します。例えば、iOS アプリケーションの場合、`tokenRefreshDelaySec` が 300 で、300 秒以を超える時間にわたって、アプリケーションが閉じられていたり、バックグラウンド状態になっていたりすると、トークンプロバイダーはトークンの更新を停止します。アプリケーションがアクティブな状態に戻ると、トークンプロバイダーは自動的にバックグラウンド更新を再開します。アプリケーションがアクティブ状態に戻ったら、トークンプロバイダーが新しいトークンを取得してキャッシュしたときに通知を受け取ることができるように `onTokenReady()` を呼び出します。キャッシュには最新の有効なトークンがまだ含まれていない可能性があるため、単に `getToken()` を呼び出さないでください。 ## アプリケーション統合 URL AWS WAF モバイル SDK アプリケーション統合 URL は、アプリケーション統合を有効にしたウェブ ACL を指します。この URL は、リクエストを正しいバックエンドサーバーにルーティングし、顧客に関連付けます。ハードセキュリティコントロールとして機能しないため、統合 URL を公開してもセキュリティリスクは生じません。提供された統合 URL を技術的に変更しても、トークンを取得できます。ただし、チャレンジ解決率の可視性が失われたり、`socketTimeoutException` エラーによるトークンの取得の失敗が発生する可能性があるため、これはお勧めしません。 ## 依存関係ダウンロード可能な各 AWS WAF モバイル SDK には、SDK の特定バージョンの依存関係を一覧表示する README ファイルが含まれています。お使いのバージョンのモバイル SDK の依存関係については、README を参照してください。 ## 難読化/ProGuard (Android SDK のみ) ProGuard などの難読化または最小化製品を使用する場合は、モバイル SDK が正しく動作するように特定の名前空間を除外する必要がある場合があります。お使いのバージョンのモバイル SDK の README をチェックして、名前空間と除外ルールのリストを見つけます。 # AWS WAF モバイル SDK のコード例このセクションでは、モバイル SDK を使用するためのコード例を提供します。 ## トークンプロバイダーの初期化とトークンの取得設定オブジェクトを使用して、トークンプロバイダーインスタンスを開始します。その後、使用可能なオペレーションを使用してトークンを取得できます。必要なコードの基本コンポーネントを次に示します。 ------ #### [ iOS ] ``` let url: URL = URL(string: "protection pack (web ACL) integration URL")! let configuration = WAFConfiguration(applicationIntegrationUrl: url, domainName: "Domain name") let tokenProvider = WAFTokenProvider(configuration) //onTokenReady can be add as an observer for UIApplication.willEnterForegroundNotification self.tokenProvider.onTokenReady() { token, error in if let token = token { //token available } if let error = error { //error occurred after exhausting all retries } } //getToken() let token = tokenProvider.getToken() ``` ------ #### [ Android ] Java の例: ``` String applicationIntegrationURL = "protection pack (web ACL) integration URL"; //Or URL applicationIntegrationURL = new URL("protection pack (web ACL) integration URL"); String domainName = "Domain name"; WAFConfiguration configuration = WAFConfiguration.builder().applicationIntegrationURL(applicationIntegrationURL).domainName(domainName).build(); WAFTokenProvider tokenProvider = new WAFTokenProvider(Application context, configuration); // implement a token result callback WAFTokenResultCallback callback = (wafToken, error) -> { if (wafToken != null) { // token available } else { // error occurred in token refresh } }; // Add this callback to application creation or activity creation where token will be used tokenProvider.onTokenReady(callback); // Once you have token in token result callback // if background refresh is enabled you can call getToken() from same tokenprovider object // if background refresh is disabled you can directly call getToken()(blocking call) for new token WAFToken token = tokenProvider.getToken(); ``` Kotlin の例: ``` import com.amazonaws.waf.mobilesdk.token.WAFConfiguration import com.amazonaws.waf.mobilesdk.token.WAFTokenProvider private lateinit var wafConfiguration: WAFConfiguration private lateinit var wafTokenProvider: WAFTokenProvider private val WAF_INTEGRATION_URL = "protection pack (web ACL) integration URL" private val WAF_DOMAIN_NAME = "Domain name" fun initWaf() { // Initialize the tokenprovider instance val applicationIntegrationURL = URL(WAF_INTEGRATION_URL) wafConfiguration = WAFConfiguration.builder().applicationIntegrationURL(applicationIntegrationURL) .domainName(WAF_DOMAIN_NAME).backgroundRefreshEnabled(true).build() wafTokenProvider = WAFTokenProvider(getApplication(), wafConfiguration) // getToken from tokenprovider object println("WAF: "+ wafTokenProvider.token.value) // implement callback for where token will be used wafTokenProvider.onTokenReady { wafToken, sdkError -> run { println("WAF Token:" + wafToken.value) } } } ``` ------ ## SDK による HTTP リクエストでのトークン cookie の提供の許可 `setTokenCookie` が `TRUE` である場合、トークンプロバイダーは、`tokenCookiePath` で指定されたパスの下のすべての場所に対するウェブリクエストにトークン cookie を含めます。デフォルトでは、`setTokenCookie` は `TRUE`、`tokenCookiePath` は `/` です。トークン cookie のパスを指定することで、トークン cookie を含むリクエストの範囲を絞り込むことができます (例: `/web/login`)。これを行う場合は、他のパスに送信するリクエストのトークンが AWS WAF ルールで検査されていないことを確認します。`AWSManagedRulesACFPRuleSet` ルールグループを使用する場合、アカウントの登録パスと作成パスを設定すると、ルールグループはそれらのパスに送信されるリクエスト内のトークンをチェックします。詳細については、「[ACFP マネージドルールグループをウェブ ACL に追加](waf-acfp-rg-using.md)」を参照してください。同様に、`AWSManagedRulesATPRuleSet` ルールグループを使用する場合は、ログインパスを設定し、ルールグループはそのパスに送信されるリクエストのトークンをチェックします。詳細については、「[ATP マネージドルールグループを保護パック (ウェブ ACL) に追加](waf-atp-rg-using.md)」を参照してください。 ------ #### [ iOS ] `setTokenCookie` がの場合`TRUE`、トークンプロバイダーは AWS WAF トークンをに保存`HTTPCookieStorage.shared`し、で指定したドメインへのリクエストに Cookie を自動的に含めます`WAFConfiguration`。 ``` let request = URLRequest(url: URL(string: domainEndpointUrl)!) //The token cookie is set automatically as cookie header let task = URLSession.shared.dataTask(with: request) { data, urlResponse, error in }.resume() ``` ------ #### [ Android ] `setTokenCookie` がの場合`TRUE`、トークンプロバイダーはアプリケーション全体で共有されている`CookieHandler`インスタンスに AWS WAF トークンを保存します。トークンプロバイダーは、`WAFConfiguration` で指定したドメインへのリクエストに cookie を自動的に含めます。 Java の例: ``` URL url = new URL("Domain name"); //The token cookie is set automatically as cookie header HttpsURLConnection connection = (HttpsURLConnection) url.openConnection(); connection.getResponseCode(); ``` Kotlin の例: ``` val url = URL("Domain name") //The token cookie is set automatically as cookie header val connection = (url.openConnection() as HttpsURLConnection) connection.responseCode ``` `CookieHandler` デフォルトインスタンスが既に初期化されている場合、トークンプロバイダーは、それを使用して cookie を管理します。そうでない場合、トークンプロバイダーは AWS WAF トークンを使用して新しい`CookieManager`インスタンスを初期化`CookiePolicy.ACCEPT_ORIGINAL_SERVER`し、この新しいインスタンスをのデフォルトインスタンスとして設定します`CookieHandler`。次のコードは、アプリケーションで使用できない場合に cookie マネージャーと cookie ハンドラーを SDK が初期化する方法を示しています。 Java の例: ``` CookieManager cookieManager = (CookieManager) CookieHandler.getDefault(); if (cookieManager == null) { // Cookie manager is initialized with CookiePolicy.ACCEPT_ORIGINAL_SERVER cookieManager = new CookieManager(); CookieHandler.setDefault(cookieManager); } ``` Kotlin の例: ``` var cookieManager = CookieHandler.getDefault() as? CookieManager if (cookieManager == null) { // Cookie manager is initialized with CookiePolicy.ACCEPT_ORIGINAL_SERVER cookieManager = CookieManager() CookieHandler.setDefault(cookieManager) } ``` ------ ## HTTP リクエストにおけるトークン cookie の手動による提供 `setTokenCookie` を `FALSE` に設定した場合、保護されたエンドポイントに対するリクエストで、cookie HTTP リクエストヘッダーとしてトークン cookie を手動で提供する必要があります。次のコードは、これを実行する方法を説明しています。 ------ #### [ iOS ] ``` var request = URLRequest(url: wafProtectedEndpoint) request.setValue("aws-waf-token=token from token provider", forHTTPHeaderField: "Cookie") request.httpShouldHandleCookies = true URLSession.shared.dataTask(with: request) { data, response, error in } ``` ------ #### [ Android ] Java の例: ``` URL url = new URL("Domain name"); HttpsURLConnection connection = (HttpsURLConnection) url.openConnection(); String wafTokenCookie = "aws-waf-token=token from token provider"; connection.setRequestProperty("Cookie", wafTokenCookie); connection.getInputStream(); ``` Kotlin の例: ``` val url = URL("Domain name") val connection = (url.openConnection() as HttpsURLConnection) val wafTokenCookie = "aws-waf-token=token from token provider" connection.setRequestProperty("Cookie", wafTokenCookie) connection.inputStream ``` ------ # CAPTCHA および Challengeの AWS WAF このセクションでは、 CAPTCHA と Challengeの操作方法について説明します AWS WAF。 AWS WAF ルールの検査基準に一致するウェブリクエストに対して CAPTCHAまたは Challengeアクションを実行するようにルールを設定できます。また、CAPTCHA パズルやブラウザチャレンジをローカルで実行するように JavaScript クライアントアプリケーションをプログラムすることもできます。 CAPTCHA パズルとサイレントチャレンジは、ブラウザが HTTPS エンドポイントにアクセスしている場合にのみ実行できます。トークンを取得するには、ブラウザクライアントが安全なコンテキストで実行されている必要があります。 + **CAPTCHA** – エンドユーザーが CAPTCHA パズルを解いて、人間がリクエストを送信していることを証明する必要があります。CAPTCHA パズルは、人間にとっては非常に簡単かつ短時間で完了に成功できる一方、コンピュータにとっては完了に成功、あるいは有意義な成功率でランダムに完了させることを困難にすることを意図しています。保護パック (ウェブ ACL) ルールでは、Block アクションが正当なリクエストを多く止めてしまう場合によく CAPTCHA が使用されますが、すべてのトラフィックを許可すると、ボットなどからの望ましくないリクエストが非常に多くなる可能性があります。ルールアクションの動作については、[AWS WAF CAPTCHA および Challenge ルールアクションの仕組み](waf-captcha-and-challenge-how-it-works.md) を参照してください。クライアントアプリケーション統合 API で CAPTCHA パズルの実装をプログラムすることもできます。パズルをクライアントアプリケーションにプログラムするときに、クライアントアプリケーションでパズルの動作と配置をカスタマイズできます。詳細については、「[でのクライアントアプリケーション統合 AWS WAF](waf-application-integration.md)」を参照してください。 + **Challenge** – サイレントチャレンジを実行して、クライアントセッションがボットではなく、ブラウザであることを検証する必要があります。検証は、エンドユーザーの関与なしでバックグラウンドで実行されます。これは、CAPTCHA パズルでエンドユーザーのエクスペリエンスに悪影響を与えることなく、無効だと思われるクライアントを検証する場合に適したオプションです。ルールアクションの動作については、[AWS WAF CAPTCHA および Challenge ルールアクションの仕組み](waf-captcha-and-challenge-how-it-works.md) を参照してください。 Challenge ルールアクションは、「[でのクライアントアプリケーション統合 AWS WAF](waf-application-integration.md)」で説明されている、インテリジェントな脅威に対応したクライアント統合 API が実行するチャレンジと似ています。 **注記** CAPTCHA または Challenge ルールアクションを 1 つのルールで使用、あるいはルールグループでルールアクションのオーバーライドとして使用すると、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。すべてのルールアクションオプションの説明については、[でのルールアクションの使用 AWS WAF](waf-rule-action.md) を参照してください。 **Topics** + [ # AWS WAF CAPTCHA パズル ](waf-captcha-puzzle.md) + [ # AWS WAF CAPTCHA および Challenge ルールアクションの仕組み ](waf-captcha-and-challenge-how-it-works.md) + [ # CAPTCHA および Challenge アクションを使用するベストプラクティス ](waf-captcha-and-challenge-best-practices.md) # AWS WAF CAPTCHA パズルこのセクションでは、 AWS WAF CAPTCHA パズルの特徴と機能について説明します。 AWS WAF は、ユーザーが人間であることを確認するように要求する標準の CAPTCHA 機能を提供します。CAPTCHA は、「Completely Automated Public Turing test to tell Computers and Humans Apart」(コンピューターと人間を区別する完全自動公開チューリングテスト) の略です。CAPTCHA パズルは、人間がリクエストを送信していることを検証し、ウェブスクレイピング、クレデンシャルスタッフィング、スパムなどのアクティビティを防ぐように設計されます。CAPTCHA パズルは望ましくないリクエストをすべて排除することはできません。機械学習と人工知能を駆使することによって多くの CAPTCHA パズルが解決されました。CAPTCHA を回避するため、一部の組織は人間が介入した自動化技術で補完しています。それにもかかわらず、CAPTCHA は洗練度の低いボットトラフィックを防ぎ、大規模な運営に必要なリソースを増やすための便利なツールとして役割を果たし続けています。 AWS WAF は CAPTCHA パズルをランダムに生成し、ローテーションスルーして、ユーザーに固有の課題が提示されるようにします。 AWS WAF は定期的に新しいタイプのパズルとスタイルを追加して、自動化手法に対して効果的を維持します。 AWS WAF CAPTCHA スクリプトは、パズルに加えて、タスクが人間によって完了されていることを確認し、再生攻撃を防ぐために、クライアントに関するデータを収集します。各 CAPTCHA パズルには、エンドユーザーが新しいパズルをリクエストしたり、音声パズルと視覚パズルを切り替えたり、追加の指示にアクセスしたり、パズルの解答を送信したりするための標準的なコントロールセットが含まれています。すべてのパズルには、スクリーンリーダー、キーボードコントロール、コントラスト色のサポートが含まれています。 AWS WAF CAPTCHA パズルは、ウェブコンテンツアクセシビリティガイドライン (WCAG) の要件を満たしています。詳細については、World Wide Web Consortium (W3C) ウェブサイトの「[Web Content Accessibility Guidelines (WCAG) Overview](https://www.w3.org/WAI/standards-guidelines/wcag/)」(Web Content Accessibility Guidelines (WCAG) の概要) を参照してください。 **Topics** + [ # CAPTCHA パズル言語へのサポート ](waf-captcha-puzzle-language-support.md) + [ # CAPTCHA パズルの例 ](waf-captcha-puzzle-examples.md) # CAPTCHA パズル言語へのサポートこのセクションでは、 AWS WAF CAPTCHA パズルでサポートされている言語を一覧表示します。 CAPTCHA パズルは、クライアントブラウザ言語での書面による指示、またはブラウザ言語がサポートされていない場合は英語で始まります。このパズルには、ドロップダウンメニューによって代替言語オプションを用意しています。ユーザーは、ページの下部にあるヘッドフォンアイコンを選択して、音声指示に切り替えることができます。音声バージョンのパズルでは、ユーザーがテキストボックスに入力する必要があるテキストに関する指示に、バックグラウンドノイズを重ねて発信します。次の表に、CAPTCHA パズルの書面的な手順と、各選択肢の音声サポートで選択できる言語を示します。 **AWS WAF CAPTCHA パズルでサポートされている言語** | 書面的な指示のサポート | ロケールコード | 音声指示のサポート | | --- | --- | --- | | アラビア語 | ar-SA | アラビア語 | | 簡体字中国語 | zh-CN | 英語の音声 | | Dutch | nl-NL | Dutch | | 英語 | en-US | 英語 | | French | fr-FR | フランス語 | | ドイツ語 | de-DE | German | | Italian | it-IT | Italian | | Japanese | ja-JP | 英語の音声 | | ブラジルポルトガル語 | pt-BR | ブラジルポルトガル語 | | Spanish | es-ES | Spanish | | Turkish | tr-TR | Turkish | # CAPTCHA パズルの例一般的なビジュアル CAPTCHA パズルでは、ユーザーが 1 つ以上のイメージを理解して操作できることを示すためのインタラクションが必要です。次のスクリーンショットは、画像グリッドパズルの例を示しています。このパズルでは、特定のタイプのオブジェクトを含むグリッド内のすべての画像を選択する必要があります。 ![\[画面には、「人間であることの確認させてください」というタイトルと「すべての椅子を選択してください」というテキストが含まれています。テキストの下には 3x3 グリッドの画像があり、その中には椅子が含まれているものもあれば、ベッドや窓などの椅子ではないオブジェクトが含まれているものもあります。画面の下部には、別のパズルをロード、情報ボックスの表示と非表示を切り替え、オーディオパズルを切り替え、言語を変更するオプションがあります。また、下部には [確認] ボタンがあります。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/CAPTCHAPuzzleGrid.png) 音声パズルオプションでは、ユーザーがテキストボックスに入力する必要があるテキストに関する発音指示に、バックグラウンドノイズを重ねて発信します。次のスクリーンショットは、選択した音声パズルの表示内容を示しています。 ![\[画面には「Solve the puzzle」(パズルを解いてください) というタイトルと「Click play to listen to instructions」(再生をクリックして指示を聞いてください) というテキストが含まれています。テキストの下には、[Play] (再生) ボタンを示す画像があります。画像の下には「Keyboard audio toggle: alt + space」(キーボード音声切り替え: alt + スペース) というテキストがあります。以下は「Enter your response」(回答を入力) というタイトルで、その下にテキスト入力ボックスがあります。開いている情報ボックスには、「Solve by listening to the recording and typing your answer into the text box」(録音を聞いて、テキストボックスに回答を入力して解いてください) というテキストが含まれています。画面の下部には、別のパズルをロードしたり、情報ボックスの表示と非表示を切り替えたり、視覚パズルに切り替えたりするオプションがあります。また、下部には [Submit] (送信) ボタンがあります。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/CAPTCHAPuzzleAudio.png) # AWS WAF CAPTCHA および Challenge ルールアクションの仕組みこのセクションでは、CAPTCHA と Challenge の仕組みについて説明します。 AWS WAF CAPTCHA と Challengeは標準のルールアクションであるため、実装は比較的簡単です。どちらかを使用するには、検査するリクエストを識別するルールの検査基準を作成し、2 つのルールアクションのうち 1 つを指定します。ルールアクションのオプションの一般的な情報については、「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」を参照してください。サーバー側からサイレントチャレンジと CAPTCHA パズルを実装するだけでなく、サイレントチャレンジを JavaScript ならびに iOS および Android のクライアントアプリケーションに統合したり、JavaScript クライアントで CAPTCHA パズルをレンダリングしたりできます。これらの統合を使用すると、エンドユーザーがより良いパフォーマンスと CAPTCHA パズルエクスペリエンスを享受できるだけでなく、ルールアクションやインテリジェントな脅威の軽減を目的としたルールグループの使用に関連するコストを削減できます。これらのパラメータの詳細については「[でのクライアントアプリケーション統合 AWS WAF](waf-application-integration.md)」を参照してください。料金に関する情報については、[[AWS WAF の料金](https://aws.amazon.com/waf/pricing/)]を参照してください。 **Topics** + [ # CAPTCHA および Challenge アクション動作 ](waf-captcha-and-challenge-actions.md) + [ # ログとメトリクスの CAPTCHA および Challenge アクション ](waf-captcha-and-challenge-logs-metrics.md) # CAPTCHA および Challenge アクション動作このセクションでは、CAPTCHA および Challenge アクションの役割について説明します。ウェブリクエストが CAPTCHAまたは Challengeアクションでルールの検査基準に一致すると、はトークンの状態とイミュニティ時間設定に従ってリクエストを処理する方法 AWS WAF を決定します。は、リクエストが CAPTCHA パズルまたはチャレンジスクリプトインタースティシャルを処理できるかどうか AWS WAF も考慮します。スクリプトは HTML コンテンツとして処理されるように設計されており、HTML コンテンツを想定しているクライアントによってのみ適切に処理されることが可能です。 **注記** CAPTCHA または Challenge ルールアクションを 1 つのルールで使用、あるいはルールグループでルールアクションのオーバーライドとして使用すると、追加料金が請求されます。詳細については、「[AWS WAF 料金](https://aws.amazon.com/waf/pricing/)」を参照してください。 **アクションがウェブリクエストを処理する方法** AWS WAF は、次のように CAPTCHAまたは Challengeアクションをウェブリクエストに適用します。 + **有効なトークン** – アクションと同様にこれ AWS WAF を処理します。は、ルールCountアクション用に設定したラベルとリクエストのカスタマイズ AWS WAF を適用し、保護パック (ウェブ ACL) の残りのルールを使用してリクエストの評価を続行します。 + **トークンの欠落、無効、または期限切れ** — リクエストの保護パック (ウェブ ACL) の評価 AWS WAF を中止し、意図した送信先への送信をブロックします。 AWS WAF は、ルールアクションタイプに従って、クライアントに返されるレスポンスを生成します。 + **Challenge** – AWS WAF はレスポンスに次のものが含まれます。 + 値が `challenge` のヘッダー `x-amzn-waf-action`。 **注記** クライアントブラウザで実行されている Javascript アプリケーションの場合、このヘッダーはアプリケーションのドメイン内でのみ使用できます。ヘッダーは、クロスドメイン取得には使用できません。詳細については、次のセクションを参照してください。 + HTTP ステータスコード `202 Request Accepted`。 + 値が `text/html` の `Accept` ヘッダーがリクエストに含まれている場合、応答にはチャレンジスクリプトを備えた JavaScript ページインタースティシャルが含まれます。 + **CAPTCHA** – レスポンスに以下 AWS WAF を含めます。 + 値が `captcha` のヘッダー `x-amzn-waf-action`。 **注記** クライアントブラウザで実行されている Javascript アプリケーションの場合、このヘッダーはアプリケーションのドメイン内でのみ使用できます。ヘッダーは、クロスドメイン取得には使用できません。詳細については、次のセクションを参照してください。 + HTTP ステータスコード `405 Method Not Allowed`。 + `text/html` の値の `Accept` ヘッダーがリクエストに含まれている場合、応答には CAPTCHA スクリプトを使った JavaScript ページのインタースティシャルが含まれます。保護パック (ウェブ ACL) またはルールレベルでトークンの有効期限が切れるタイミングを設定するには、「[でのタイムスタンプの有効期限とトークンイミュニティ時間の設定 AWS WAF](waf-tokens-immunity-times.md)」を参照してください。 **ヘッダーは、クライアントブラウザで実行される JavaScript アプリケーションでは使用できません** が CAPTCHA またはチャレンジ AWS WAF レスポンスでクライアントリクエストに応答する場合、Cross-Origin Resource Sharing (CORS) ヘッダーは含まれません。CORS ヘッダーは、JavaScript アプリケーションがどのドメイン、HTTP メソッド、および HTTP ヘッダーを使用できるかをクライアントウェブブラウザに指示する一連のアクセスコントロールヘッダーです。CORS ヘッダーがないと、クライアントブラウザで実行されている JavaScript アプリケーションには HTTP ヘッダーへのアクセスが許可されないため、CAPTCHA および Challenge 応答で提供される `x-amzn-waf-action` ヘッダーを読み取ることができません。 **チャレンジと CAPTCHA インタースティシャルの機能** チャレンジインタースティシャルが実行されると、クライアントが応答に成功した後、まだトークンがない場合、インタースティシャルがトークンを初期化します。その後、チャレンジ解決のタイムスタンプでトークンを更新します。 CAPTCHA インタースティシャルを実行するとき、クライアントがまだトークンを持っていない場合、CAPTCHA インタースティシャルはまずチャレンジスクリプトを呼び出し、ブラウザにチャレンジしてトークンを初期化します。その後、インタースティシャルは CAPTCHA パズルを実行します。エンドユーザーがパズルの完成に成功すると、インタースティシャルはトークンを CAPTCHA 解決のタイムスタンプで更新します。いずれの場合も、クライアントが応答に成功してスクリプトがトークンを更新した後、スクリプトは更新されたトークンを使用して元のウェブリクエストを再送信します。がトークン AWS WAF を処理する方法を設定できます。詳細については、「[AWS WAF インテリジェントな脅威の軽減におけるトークンの使用](waf-tokens.md)」を参照してください。 # ログとメトリクスの CAPTCHA および Challenge アクションこのセクションでは、が CAPTCHAおよび Challengeアクションのログ記録とメトリクス AWS WAF を処理する方法について説明します。 Challenge および CAPTCHA アクションは、Count のように終了しない場合もあれば、Block のように終了する場合もあります。結果は、リクエストがアクションタイプの有効期限が切れていない有効なトークンがあるかどうかによって異なります。 + **有効なトークン** – アクションが有効なトークンを見つけてリクエストをブロックしない場合、はメトリクスとログを次のように AWS WAF キャプチャします。 + `CaptchaRequests` および `RequestsWithValidCaptchaToken` または `ChallengeRequests` および `RequestsWithValidChallengeToken` のいずれかのメトリクスを増分します。 + CAPTCHA または Challenge のアクションで `nonTerminatingMatchingRules` エントリとして一致をログに記録します。次のリストは、CAPTCHA アクションを使ったこの一致タイプにおけるログのセクションを示しています。 ``` "nonTerminatingMatchingRules": [ { "ruleId": "captcha-rule", "action": "CAPTCHA", "ruleMatchDetails": [], "captchaResponse": { "responseCode": 0, "solveTimestamp": 1632420429 } } ] ``` + **トークンの欠落、無効、または期限切れ** – アクションがトークンの欠落または無効なためにリクエストをブロックすると、はメトリクスとログを次のように AWS WAF キャプチャします。 + `CaptchaRequests` または `ChallengeRequests` のメトリクスを増分させます。 + 一致を HTTP `405` ステータスコードを含む `CaptchaResponse` エントリ、あるいは HTTP `202` ステータスコードを含む `ChallengeResponse` エントリとしてログ記録します。ログは、リクエストにトークンが不足しているか、トークンの有効期限が切れているか示します。ログには、がクライアントに CAPTCHA インタースティシャルページを送信したか、クライアントブラウザにサイレントチャレンジ AWS WAF を送信したかも示されます。次のリストは、CAPTCHA アクションを含むこのタイプの一致におけるログのセクションを示しています。 ``` "terminatingRuleId": "captcha-rule", "terminatingRuleType": "REGULAR", "action": "CAPTCHA", "terminatingRuleMatchDetails": [], ... "responseCodeSent": 405, ... "captchaResponse": { "responseCode": 405, "solveTimestamp": 0, "failureReason": "TOKEN_MISSING" } ``` AWS WAF ログの詳細については、「」を参照してください[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)。 AWS WAF メトリクスの詳細については、「」を参照してください[AWS WAF メトリクスとディメンション](waf-metrics.md)。ルールアクションのオプションの一般的な情報については、「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」を参照してください。 **トークンのないリクエストは、ログとメトリクスに 2 回表示されるように見える** このセクションで説明されている [CAPTCHA および Challenge アクション動作](waf-captcha-and-challenge-actions.md)、ログ記録とメトリクスに基づいて、トークンのないリクエストは通常、ログとメトリクスに 2 回表示されます。これは、意図した 1 つのリクエストが実際にクライアントによって 2 回送信されるためです。 + トークンのない最初のリクエストは、欠落、無効、または期限切れのトークンについて、上記のログ記録とメトリクス処理を受け取ります。CAPTCHA または Challenge アクションはこの最初のリクエストを終了し、サイレントチャレンジまたは CAPTCHA パズルのいずれかでクライアントに応答します。 + クライアントはチャレンジまたはパズルを評価し、クライアントブラウザまたはエンドユーザーが正常に応答すると、新しく取得したトークンを使用してリクエストを再度送信します。この 2 番目のリクエストは、有効なトークンを持つリクエストについて、上記のログ記録とメトリクス処理を受け取ります。　 # CAPTCHA および Challenge アクションを使用するベストプラクティスこのセクションのガイダンスに従って、CAPTCHA AWS WAF またはチャレンジを計画および実装します。 **CAPTCHA およびチャレンジの実装の計画** ウェブサイトの使用状況、保護するデータの機密性、リクエストのタイプに基づいて、CAPTCHA パズルまたはサイレントチャレンジを配置する場所を決定します。必要に応じてパズルを提示できるように、CAPTCHA に適用するリクエストを選択します。ただし、役に立たずにユーザーエクスペリエンスを低下させる可能性がある場合、パズルの提示を控えてください。Challenge アクションを使用てエンドユーザーへの影響が少ないサイレントチャレンジを実行しますが、リクエストが JavaScript 対応のブラウザから送信されていることを確認できます。 CAPTCHA パズルとサイレントチャレンジは、ブラウザが HTTPS エンドポイントにアクセスしている場合にのみ実行できます。トークンを取得するには、ブラウザクライアントが安全なコンテキストで実行されている必要があります。 **クライアントで CAPTCHA パズルやサイレントチャレンジを実行する場所を決定** CSS や画像のリクエストなど、CAPTCHA による影響を受けたくないリクエストを特定します。CAPTCHA は必要な場合にのみ使用してください。たとえば、ログイン時に CAPTCHA チェックを行う予定で、ユーザーが常にログインから別の画面に直接ダイレクトされる場合、2 つ目の画面で CAPTCHA チェックを要求することはおそらく不要であり、ユーザーエクスペリエンスを低下させる可能性があります。が`GET``text/html`リクエストに応じて CAPTCHA パズルとサイレントチャレンジ AWS WAF のみを送信するように Challengeと CAPTCHAを設定します。`POST`リクエスト、クロスオリジンリソース共有 (CORS) プリフライト`OPTIONS`要求、またはその他の非要求`GET`リクエストタイプに応答しても、パズルもチャレンジも実行することはできません。他のリクエストに対するブラウザの動作は異なる場合があり、インタースティシャルを適切に処理できない可能性があります。クライアントが HTML を受け入れられても、CAPTCHA またはチャレンジインタースティシャルを処理できない場合があります。たとえば、小さな iFrame を持つウェブページ上のウィジェットは HTML を受け入れますが、CAPTCHA の表示またはその処理ができない場合があります。このようなタイプのリクエストのルールアクションは、HTML を受け入れないリクエストと同じように、設定しないでください。 **以前に取得したトークンの確認に CAPTCHA または Challenge を使用** ルールアクションは、正規ユーザーが常にトークンを持っている必要がある場所で、有効なトークンの存在を確認する場合にのみ使用できます。このような状況では、リクエストでインタースティシャルを処理できるかどうかは問題ではありません。例えば、JavaScript クライアントアプリケーションの CAPTCHA API を実装し、保護されたエンドポイントに最初のリクエストを送信する直前にクライアントで CAPTCHA パズルを実行する場合、最初のリクエストには、チャレンジと CAPTCHA の両方に有効なトークンが常に含まれている必要があります。JavaScript クライアントアプリケーション統合については、「[AWS WAF JavaScript 統合](waf-javascript-api.md)」を参照してください。この状況では、保護パック (ウェブ ACL) に、この最初の呼び出しと一致するルールを追加し、Challenge または CAPTCHA ルールアクションでルールを設定することができます。ルールが正規のエンドユーザーとブラウザに一致すると、アクションは有効なトークンを検索します。したがって、アクションがリクエストをブロックしたり、リクエストに応答してチャレンジや CAPTCHA パズルを送信したりすることはありません。ルールアクションの仕組みの詳細については、「[CAPTCHA および Challenge アクション動作](waf-captcha-and-challenge-actions.md)」を参照してください。 **CAPTCHA および Challenge で機密性のある非 HTML データを保護する** 次のアプローチで、API などの機密性の高い非 HTML データに CAPTCHA および Challenge 保護を使用できます。 1. HTML レスポンスを受け取り、機密性の高い HTML 以外のデータに対するリクエストの近くで実行されるリクエストを特定します。 1. HTML のリクエストと照合し、機密データのリクエストと照合する CAPTCHA または Challenge ルールを記述します。 1. CAPTCHA および Challenge イミュニティ時間の設定を調整し、通常のユーザーインタラクションで、クライアントが HTML リクエストから取得するトークンが、機密データのリクエストにおいて利用可能で有効期限が切れないようします。チューニングの情報については、「[でのタイムスタンプの有効期限とトークンイミュニティ時間の設定 AWS WAF](waf-tokens-immunity-times.md)」を参照してください。機密データのリクエストが CAPTCHA または Challenge ルールに一致すると、クライアントが以前のパズルまたはチャレンジからの有効なトークンをまだ持っている場合、そのリクエストはブロックされません。トークンが利用できない、あるいはタイムスタンプが有効期限が切れている場合、機密データをアクセスするリクエストは失敗します。ルールアクションの仕組みの詳細については、「[CAPTCHA および Challenge アクション動作](waf-captcha-and-challenge-actions.md)」を参照してください。 **CAPTCHA および Challenge を使用して既存ルールの調整** 既存のルールを確認し、変更するか追加するかを確認します。一般的なシナリオをいくつか次に示します。 + トラフィックをブロックするレートベースルールがあるものの、正規ユーザーのブロックを避けるためにレート制限を比較的高く維持する場合、ブロックルールの後に 2 つ目のレートベースルールを追加することを検討してください。2 つ目のルールにブロッキングルールよりも低い制限を設定し、ルールアクションを CAPTCHA また Challenge に設定します。ブロッキングルールは、高すぎるレートでリクエストを受け取らないように引き続きブロックします。新しいルールは、ほとんどの自動化トラフィックをさらに低いレートでブロックします。レートベースルールの詳細については、「[でのレートベースのルールステートメントの使用 AWS WAF](waf-rule-statement-type-rate-based.md)」を参照してください。 + リクエストをブロックするマネージドルールグループがある場合、一部またはすべてのルールの動作を Block から CAPTCHA または Challenge に切り替えることができます。これを行うには、マネージドルールグループの設定で、ルールアクション設定をオーバーライドします。ルールアクションのオーバーライドの情報については、「[ルールグループのルールアクションの上書き](web-acl-rule-group-override-options.md#web-acl-rule-group-override-options-rules)」を参照してください。 **デプロイする前に CAPTCHA およびチャレンジの実装をテストしてください** すべての新機能については、[AWS WAF 保護のテストとチューニング](web-acl-testing.md) のガイダンスに従ってください。テストのとき、トークンタイムスタンプの有効期限要件を確認し、ウェブ ACL およびルールレベルのイミュニティ時間を設定して、ウェブサイトへのアクセスを制御および顧客に優れたエクスペリエンスを提供することのバランスが適切に維持できるようにします。詳細については、「[でのタイムスタンプの有効期限とトークンイミュニティ時間の設定 AWS WAF](waf-tokens-immunity-times.md)」を参照してください。 # 保護 AWS WAF パック (ウェブ ACL) トラフィックのデータ保護とログ記録このセクションでは、で使用できるデータログ記録、収集、保護オプションについて説明します AWS WAF。オプションは次のとおりです。 + **ログ記録** – ウェブリクエストトラフィックのログを任意のログ記録先に送信するように保護パック (ウェブ ACL) を設定できます。この選択では、フィールドの秘匿化とフィルタリングを設定できます。ログ記録では、データ保護設定の適用後に使用可能なデータを使用します。このオプションについては、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。 + **リクエストサンプリング** – 評価対象のウェブリクエストをサンプリングするように保護パック (ウェブ ACL) を設定して、アプリケーションが受信するトラフィックのタイプを把握できます。リクエストサンプリングでは、データ保護設定の適用後に使用可能なデータを使用します。このオプションについては、「[ウェブリクエストのサンプルの表示](web-acl-testing-view-sample.md)」を参照してください。 + **Amazon Security Lake** – Security Lake を設定して、保護パック (ウェブ ACL) データを収集できます。Security Lake は、正規化、分析、管理のためにさまざまな AWS ソースからログとイベントデータを収集します。Security Lake は、データ保護設定の適用後に使用可能なデータから収集します。このオプションの詳細については、[「Amazon Security Lake ユーザーガイド」の「Amazon Security Lake とは](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html)[」および「 AWS のサービスからデータを収集](https://docs.aws.amazon.com/security-lake/latest/userguide/internal-sources.html)する」を参照してください。 ** AWS WAF は、このオプションの使用に対して課金しません。料金については、「*Amazon Security Lake ユーザーガイド*」の「[Security Lake Pricing](https://aws.amazon.com/security-lake/pricing/)」と「[How Security Lake pricing is determined](https://docs.aws.amazon.com/security-lake/latest/userguide/estimating-costs.html)」を参照してください。 + **データ保護** – ウェブトラフィックデータのデータ保護は、次の 2 つのレベルで設定できます。 + **保護パック (ウェブ ACL) のデータ保護** – 保護パック (ウェブ ACL) ごとにデータ保護を設定できます。これにより、特定のウェブトラフィックデータを静的文字列または暗号化ハッシュに置き換えることができます。このレベルでのデータ保護は一元的に設定でき、すべてのログ記録とデータコレクションオプションに適用されます。このオプションについては、「[データ保護](data-protection-masking.md)」を参照してください。 + **ログ記録の秘匿化とフィルタリング** – ログ記録のみの場合、ウェブトラフィックデータの一部をログから秘匿化するように設定し、ログに記録するデータをフィルタリングできます。このオプションは、設定したデータ保護設定に加えて、が設定したログ記録先 AWS WAF に送信するデータにのみ影響します。 **Topics** + [ # ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック ](logging.md) + [ # データ保護 ](data-protection-masking.md) # ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィックこのセクションでは、 AWS WAF 保護パック (ウェブ ACLs) のログ記録オプションについて説明します。ログ記録を有効にして、ウェブ ACL で分析されるトラフィックに関する詳細情報を取得できます。ログに記録された情報には、 AWS がリソースからウェブリクエストを AWS WAF 受信した時間、リクエストに関する詳細情報、およびリクエストが一致したルールに関する詳細が含まれます。保護パック (ウェブ ACL) ログは、Amazon CloudWatch Logs ロググループ、Amazon Simple Storage Service (Amazon S3) バケット、または Amazon Data Firehose 配信ストリームに送信できます。は、保護パック (ウェブ ACLs) に対して有効にできるログに加えて、によって処理されたウェブサイトまたはアプリケーショントラフィックのサービスログ AWS も使用 AWS WAF して、 AWS 顧客およびサービスのセキュリティをサポートし、保護します。 **注記** 保護パック (ウェブ ACL) のログ記録設定は、 AWS WAF ログにのみ影響します。特に、ログ記録用に編集されたフィールド設定は、リクエストサンプリングや Security Lake データ収集には影響しません。保護パック (ウェブ ACL) データ保護を設定することで、収集またはサンプリングからフィールドを除外できます。データ保護以外に、Security Lake データ収集は、Security Lake サービスを通じて完全に設定されます。 **Topics** + [ # 保護パック (ウェブ ACL) トラフィックのログ記録の料金に関する情報 ](logging-pricing.md) + [ # AWS WAF ログ記録の送信先 ](logging-destinations.md) + [ # 保護パック (ウェブ ACL) のログ記録の設定 ](logging-management-configure.md) + [ # 保護パック (ウェブ ACL) レコードの検索 ](logging-management.md) + [ # 保護パック (ウェブ ACL) トラフィックのログフィールド ](logging-fields.md) + [ # 保護パック (ウェブ ACL) トラフィックのログ例 ](logging-examples.md) **その他のデータ収集および分析オプション** ログ記録に加えて、データ収集と分析のために以下のオプションを有効にすることができます。 + **Amazon Security Lake** – Security Lake を設定して、保護パック (ウェブ ACL) データを収集できます。Security Lake は、正規化、分析、管理のためにさまざまなソースからログとイベントデータを収集します。このオプションの詳細については、[「Amazon Security Lake ユーザーガイド」の「Amazon Security Lake とは](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html)[」および「 AWS のサービスからデータを収集](https://docs.aws.amazon.com/security-lake/latest/userguide/internal-sources.html)する」を参照してください。 ** AWS WAF は、このオプションの使用に対して課金しません。料金については、「*Amazon Security Lake ユーザーガイド*」の「[Security Lake Pricing](https://aws.amazon.com/security-lake/pricing/)」と「[How Security Lake pricing is determined](https://docs.aws.amazon.com/security-lake/latest/userguide/estimating-costs.html)」を参照してください。 + **リクエストサンプリング** – 評価対象のウェブリクエストをサンプリングするように保護パック (ウェブ ACL) を設定して、アプリケーションが受信するトラフィックのタイプを把握できます。このオプションについては、「[ウェブリクエストのサンプルの表示](web-acl-testing-view-sample.md)」を参照してください。 # 保護パック (ウェブ ACL) トラフィックのログ記録の料金に関する情報このセクションで、保護パック (ウェブ ACL) トラフィックログの使用についての料金に関する考慮事項について説明します。保護パック (ウェブ ACL) トラフィックに関する情報のログ記録について、各ログの宛先タイプに関連するコストに応じて請求されます。これらの料金は、 AWS WAFの使用料に加算されます。コストは、選択した宛先タイプやログに記録するデータ量などの要因によって異なる場合があります。各ログ記録の宛先タイプの料金に関する情報へのリンクを次に示します。 + **CloudWatch Logs** – 料金は公開ログ配信についてのものです。「[Amazon CloudWatch Logs の料金](https://aws.amazon.com/cloudwatch/pricing/)」を参照してください。**[Paid Tier]** (有料の階層) で **[Logs]** (ログ) タブを選択し、**[Vended Logs]** (公開ログ) で **[Delivery to CloudWatch Logs]** (CloudWatch Logs に配信) の情報を確認します。 + **Amazon S3 バケット** – Amazon S3 の料金は、CloudWatch Logs が Amazon S3 バケットに公開ログ配信した料金と Amazon S3 を使用した料金を合計したものです。 + Amazon S3 については、「[Amazon S3 の料金](https://aws.amazon.com/s3/pricing/)」を参照してください。 + CloudWatch Logs が Amazon S3 に提供する公開ログ配信については、「[Amazon CloudWatch Logs の料金](https://aws.amazon.com/cloudwatch/pricing/)」を参照してください。**[Paid Tier]** (有料の階層) で **[Logs]** (ログ) タブを選択し、**[Vended Logs]** (公開ログ) で **[Delivery to S3]** (S3 に配信) の情報を確認します。 + **Firehose** –「[Amazon Data Firehose Pricing](https://aws.amazon.com/kinesis/data-firehose/pricing/)」を参照してください。 AWS WAF 料金の詳細については、[AWS WAF 「 ](https://aws.amazon.com/waf/pricing/)料金表」を参照してください。 # AWS WAF ログ記録の送信先このセクションでは、 AWS WAF ログ用に選択できるログ記録のオプションについて説明します。各セクションでは、ログを設定するためのガイダンスと、送信先の種類に固有の動作に関する情報を提供します。ログ記録の送信先を設定したら、保護パック (ウェブ ACL) ログ記録設定にその指定を入力して、送信先へのログ記録を開始することができます。 **Topics** + [CloudWatch Logs](logging-cw-logs.md) + [Amazon S3](logging-s3.md) + [Firehose](logging-kinesis.md) # Amazon CloudWatch Logs ロググループへの保護パック (ウェブ ACL) トラフィックログの送信このトピックは、保護パック (ウェブ ACL) トラフィックログの CloudWatch Logs ロググループへの送信に関する情報を提供します。 **注記** AWS WAFの使用料金に加えて、ログ記録の料金が請求されます。詳細については、「[保護パック (ウェブ ACL) トラフィックのログ記録の料金に関する情報](logging-pricing.md)」を参照してください。 Amazon CloudWatch Logs にログを送信するには、CloudWatch Logs ロググループを作成します。ログインを有効にするときは AWS WAF、ロググループ ARN を指定します。保護パック (ウェブ ACL) のログ記録を有効にすると、はログストリームの CloudWatch Logs ロググループにログを AWS WAF 配信します。 CloudWatch Logs を使用すると、 AWS WAF コンソールで保護パック (ウェブ ACL) のログを調べることができます。保護パック (ウェブ ACL) ページで、**[Logging insights]** (ログ記録のインサイト) タブを選択します。このオプションは、CloudWatch コンソールで CloudWatch Logs に提供されるログ記録インサイトに追加されるものです。 AWS WAF 保護パック (ウェブ ACL) と同じリージョンで、保護パック (ウェブ ACL) の管理に使用するのと同じアカウントを使用して、保護パック (ウェブ ACL) ログのロググループを設定します。CloudWatch Logs ロググループの設定については、「[ロググループとログストリームの操作](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html)」を参照してください。 ## CloudWatch Logs のロググループに関する配分 CloudWatch Logs には、スループットのデフォルトの最大クォータがあり、リージョン内のすべてのロググループで共有されます。これに対して、増加をリクエストできます。ログ記録の要件が既存のスループット設定に対して高すぎる場合は、アカウントの `PutLogEvents` のスロットリングメトリクスが表示されます。Service Quotas コンソールで制限を表示して引き上げをリクエストするには、「[CloudWatch Logs PutLogEvents quota](https://console.aws.amazon.com/servicequotas/home/services/logs/quotas/L-7E1FAE88)」を参照してください。 ## ロググループの命名ロググループ名は `aws-waf-logs-` で始まる必要があり、末尾を任意のサフィックスにすることができます (例: `aws-waf-logs-testLogGroup2`)。結果として生じる ARN 形式は次のとおりです。 ``` arn:aws:logs:Region:account-id:log-group:aws-waf-logs-log-group-suffix ``` ログストリームの命名形式は次のとおりです。 ``` Region_web-acl-name_log-stream-number ``` リージョン `us-east-1` の保護パック (ウェブ ACL) `TestWebACL` のログストリームの例を次に示します。 ``` us-east-1_TestWebACL_0 ``` ## CloudWatch Logs にログを発行するために必須のアクセス許可 CloudWatch Logs ロググループの保護パック (ウェブ ACL) トラフィックログ記録を設定するには、このセクションで説明する許可設定が必要です。アクセス許可は、 AWS WAF フルアクセス管理ポリシーの 1 つ、`AWSWAFConsoleFullAccess`またはを使用する場合に設定されます`AWSWAFFullAccess`。ログ記録と AWS WAF リソースへのよりきめ細かなアクセスを管理する場合は、アクセス許可を自分で設定できます。アクセス許可の管理の詳細については、*IAM ユーザーガイド*の[AWS 「リソースのアクセス管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html)」を参照してください。 AWS WAF マネージドポリシーの詳細については、「[AWS の管理ポリシー AWS WAF](security-iam-awsmanpol.md)」を参照してください。これらの許可を使用すると、保護パック (ウェブ ACL) ログ記録設定の変更、CloudWatch Logs のログ配信の設定、およびロググループに関する情報の取得が可能となります。これらの許可は、 AWS WAFの管理に使用するユーザーにアタッチされる必要があります。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "wafv2:PutLoggingConfiguration", "wafv2:DeleteLoggingConfiguration" ], "Resource": [ "*" ], "Effect": "Allow", "Sid": "LoggingConfigurationAPI" }, { "Sid": "WebACLLoggingCWL", "Action": [ "logs:CreateLogDelivery", "logs:DeleteLogDelivery", "logs:PutResourcePolicy", "logs:DescribeResourcePolicies", "logs:DescribeLogGroups" ], "Resource": [ "*" ], "Effect": "Allow" } ] } ``` ------ すべての AWS リソースでアクションが許可されている場合、ポリシーに `"Resource"`の設定で示されます`"*"`。つまり、各アクションがサポートするすべての AWS リソースでアクションが許可されます。 **例えば、アクション `wafv2:PutLoggingConfiguration` は、`wafv2` のログ記録設定リソースでのみサポートされます。 # Amazon Simple Storage Service バケットへの保護パック (ウェブ ACL) トラフィックログの送信このトピックは、保護パック (ウェブ ACL) トラフィックログの Amazon S3 バケットへの送信に関する情報を提供します。 **注記** AWS WAFの使用料金に加えて、ログ記録の料金が請求されます。詳細については、「[保護パック (ウェブ ACL) トラフィックのログ記録の料金に関する情報](logging-pricing.md)」を参照してください。保護パック (ウェブ ACL) トラフィックログを Amazon S3 に送信するには、保護パック (ウェブ ACL) を管理するのと同じアカウントから Amazon S3 バケットを設定し、バケットに `aws-waf-logs-` で始まる名前を付けます。ログインを有効にするときは AWS WAF、バケット名を指定します。ロギングバケットの作成については、「*Amazon Simple Storage Service ユーザーガイド*」の「[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html)」を参照してください。 Amazon Athena インタラクティブクエリサービスを使用して、Amazon S3 ログにアクセスし、分析することができます。Athena を使用すれば、標準 SQL を使用した Amazon S3 内のデータを直接分析しやすくなります。のいくつかのアクションを使用すると AWS マネジメントコンソール、Amazon S3 に保存されているデータを Athena にポイントし、標準 SQL を使用してアドホッククエリを実行し、結果を取得できます。詳細については、[「Amazon Athena ユーザーガイド」の AWS WAF 「ログのクエリ](https://docs.aws.amazon.com/athena/latest/ug/waf-logs.html)」を参照してください。 *Amazon Athena * その他のサンプル Amazon Athena クエリについては、GitHub ウェブサイトの[aws-samples/waf-log-sample-athena-queries](https://github.com/aws-samples/waf-log-sample-athena-queries)を参照してください。 **注記** AWS WAF は、キータイプの Amazon S3 キー (SSE-S3) および for AWS Key Management Service (SSE-KMS) の Amazon S3 バケットによる暗号化をサポートしています AWS KMS keys。 AWS WAF は、によって管理される AWS Key Management Service キーの暗号化をサポートしていません AWS。保護パック (ウェブ ACL) からのログファイルは、5 分間隔で Amazon S3 バケットに発行されます。各ログファイルには、前の 5 分間に記録されたトラフィックのログレコードが含まれています。ログファイルの最大ファイルサイズは 75 MB です。ログファイルが 5 分以内にファイルサイズの上限に達した場合、ログはレコードの追加を停止し、Amazon S3 バケットに発行してから、新しいログファイルを作成します。ログファイルは圧縮されます。Amazon S3 コンソールを使用してファイルを開くと、Amazon S3 はログレコードを解凍して表示します。ログファイルをダウンロードする場合、レコードを表示するには解凍する必要があります。 1 つのログファイルには、複数のレコードを含むインターリーブされたエントリが含まれます。保護パック (ウェブ ACL) のすべてのログファイルを表示するには、保護パック (ウェブ ACL) 名、リージョン、およびアカウント ID で集約されたエントリを探します。 ## 命名要件と構文 AWS WAF ログ記録のバケット名はで始まり`aws-waf-logs-`、任意のサフィックスで終わることができます。例えば、`aws-waf-logs-LOGGING-BUCKET-SUFFIX`。 **バケットの場所** バケットの場所は次の構文を使用します。 ``` s3://aws-waf-logs-LOGGING-BUCKET-SUFFIX/ ``` **バケット ARN** バケットの Amazon リソースネーム (ARN) の形式は次のとおりです。 ``` arn:aws:s3:::aws-waf-logs-LOGGING-BUCKET-SUFFIX ``` **プレフィックスを使用したバケットの場所** オブジェクトキー名にプレフィックスを使用してバケットに保存するデータを整理する場合は、ロギングバケット名にプレフィックスを指定できます。 **注記** このオプションはコンソールからは使用できません。 AWS WAF APIs、CLI、またはを使用します AWS CloudFormation。 Amazon S3 でのプレフィックスの使用については、「*Amazon Simple Storage Service ユーザーガイド*」の「[プレフィックスを使用してオブジェクトを整理する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-prefixes.html)」を参照してください。プレフィックスを使用したバケットの場所には、次の構文が使用されます。 ``` s3://aws-waf-logs-LOGGING-BUCKET-SUFFIX/KEY-NAME-PREFIX/ ``` **バケットフォルダとファイル名** バケット内で、指定したプレフィックスに従って、 AWS WAF ログはアカウント ID、リージョン、保護パック (ウェブ ACL) 名、および日時によって決定されるフォルダ構造で書き込まれます。 ``` AWSLogs/account-id/WAFLogs/Region/web-acl-name/YYYY/MM/dd/HH/mm ``` フォルダ内では、ログファイル名は同様の形式になります。 ``` account-id_waflogs_Region_web-acl-name_timestamp_hash.log.gz ``` フォルダ構造およびログファイル名で使用される時間の指定は、タイムスタンプ形式の仕様 `YYYYMMddTHHmmZ` に準拠しています。 `aws-waf-logs-LOGGING-BUCKET-SUFFIX` という名前のバケット用の Amazon S3 バケットに存在するログファイルの例を次に示します。 AWS アカウントはです`11111111111`。保護パック (ウェブ ACL) は `TEST-WEBACL` で、リージョンは `us-east-1` です。 ``` s3://aws-waf-logs-LOGGING-BUCKET-SUFFIX/AWSLogs/11111111111/WAFLogs/us-east-1/TEST-WEBACL/2021/10/28/19/50/11111111111_waflogs_us-east-1_TEST-WEBACL_20211028T1950Z_e0ca43b5.log.gz ``` **注記** AWS WAF ログ記録用のバケット名はで始まり`aws-waf-logs-`、任意のサフィックスで終わることができます。 ## Amazon S3 にログを発行するために必須のアクセス許可 Amazon S3 バケットの保護パック (ウェブ ACL) トラフィックログ記録を設定するには、次の許可設定が必要です。 AWS WAF フルアクセスマネージドポリシーのいずれか (`AWSWAFConsoleFullAccess` または `AWSWAFFullAccess`) を使用すると、これらの許可が設定されます。ログ記録と AWS WAF リソースへのアクセスをさらに管理する場合は、これらのアクセス許可を自分で設定できます。アクセス許可の管理については、「IAM ユーザーガイド**」の「[AWS リソースのアクセス管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html)」を参照してください。 AWS WAF 管理ポリシーの詳細については、「」を参照してください[AWS の管理ポリシー AWS WAF](security-iam-awsmanpol.md)。次の許可を使用すると、保護パック (ウェブ ACL) ログ記録設定を変更し、Amazon S3 バケットへのログ配信を設定できます。これらの許可は、 AWS WAFの管理に使用するユーザーにアタッチされる必要があります。 **注記** 以下に示すアクセス許可を設定すると、アクセスが拒否されたことを示すエラーが AWS CloudTrail ログに表示されることがありますが、そのアクセス許可は AWS WAF ログ記録に正確です。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Action":[ "wafv2:PutLoggingConfiguration", "wafv2:DeleteLoggingConfiguration" ], "Resource":[ "*" ], "Effect":"Allow", "Sid":"LoggingConfigurationAPI" }, { "Sid":"WebACLLogDelivery", "Action":[ "logs:CreateLogDelivery", "logs:DeleteLogDelivery" ], "Resource": "*", "Effect":"Allow" }, { "Sid":"WebACLLoggingS3", "Action":[ "s3:PutBucketPolicy", "s3:GetBucketPolicy" ], "Resource": [ "arn:aws:s3:::aws-waf-logs-amzn-s3-demo-destination-bucket-suffix" ], "Effect":"Allow" } ] } ``` ------ すべての AWS リソースでアクションが許可されている場合、ポリシーに `"Resource"`の設定で示されます`"*"`。つまり、各アクションがサポートするすべての AWS リソースでアクションが許可されます。 **例えば、アクション `wafv2:PutLoggingConfiguration` は、`wafv2` のログ記録設定リソースでのみサポートされます。デフォルトでは、Amazon S3 バケットとそれに含まれているオブジェクトはプライベートです。バケット所有者のみが、そのバケットとそれに含まれているオブジェクトにアクセスできます。ただし、バケット所有者は、アクセスポリシーを記述することで他のリソースおよびユーザーに許可を付与することができます。フローログを作成しているユーザーがバケットを所有している場合、そのバケットにログを発行する許可をフローログに付与するため、サービスは次のポリシーを自動的にバケットにアタッチします。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AWSLogDeliveryWrite", "Effect": "Allow", "Principal": { "Service": "delivery.logs.amazonaws.com" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::aws-waf-logs-amzn-s3-demo-destination-bucket-suffix/AWSLogs/123456789012/*", "Condition": { "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control", "aws:SourceAccount": ["123456789012"] }, "ArnLike": { "aws:SourceArn": ["arn:aws:logs:us-east-2:123456789012:*"] } } }, { "Sid": "AWSLogDeliveryAclCheck", "Effect": "Allow", "Principal": { "Service": "delivery.logs.amazonaws.com" }, "Action": "s3:GetBucketAcl", "Resource": "arn:aws:s3:::aws-waf-logs-amzn-s3-demo-destination-bucket-suffix", "Condition": { "StringEquals": { "aws:SourceAccount": ["123456789012"] }, "ArnLike": { "aws:SourceArn": ["arn:aws:logs:us-east-2:123456789012:*"] } } } ] } ``` ------ **注記** AWS WAF ログ記録用のバケット名はで始まり`aws-waf-logs-`、任意のサフィックスで終わることができます。ログを作成しているユーザーがバケットを所有していないか、バケットに対する `GetBucketPolicy` および `PutBucketPolicy` 許可がない場合、ログの作成は失敗します。この場合、バケット所有者はバケットに手動で前述のポリシーを追加して、ログ作成者の AWS アカウント ID を指定する必要があります。詳細については、「*Amazon Simple Storage Service ユーザーガイド*」の「[S3 バケットポリシーを追加する方法](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html)」を参照してください。バケットが複数のアカウントからログを受け取る場合は、各アカウントの `AWSLogDeliveryWrite` ポリシーステートメントに `Resource` エレメントエントリを追加します。たとえば、次のバケットポリシーでは AWS アカウント、 `111122223333`がという名前のバケットにログを発行できるようにします`aws-waf-logs-LOGGING-BUCKET-SUFFIX`。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "AWSLogDeliveryWrite20150319", "Statement": [ { "Sid": "AWSLogDeliveryWrite", "Effect": "Allow", "Principal": { "Service": "delivery.logs.amazonaws.com" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::aws-waf-logs-amzn-s3-demo-destination-bucket-suffix/AWSLogs/111122223333/*", "Condition": { "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control", "aws:SourceAccount": ["111122223333"] }, "ArnLike": { "aws:SourceArn": ["arn:aws:logs:us-east-1:111122223333:*"] } } }, { "Sid": "AWSLogDeliveryAclCheck", "Effect": "Allow", "Principal": { "Service": "delivery.logs.amazonaws.com" }, "Action": "s3:GetBucketAcl", "Resource": "arn:aws:s3:::aws-waf-logs-amzn-s3-demo-destination-bucket-suffix", "Condition": { "StringEquals": { "aws:SourceAccount": ["111122223333"] }, "ArnLike": { "aws:SourceArn": ["arn:aws:logs:us-east-1:111122223333:*"] } } } ] } ``` ------ **注記** `s3:ListBucket` アクセス許可が `delivery.logs.amazonaws.com` に付与されていないと、 AWS CloudTrail で `AccessDenied` エラーが表示される場合があります。CloudTrail ログにこのようなエラーが表示されないようにするには、`s3:ListBucket` が `delivery.logs.amazonaws.com` にアクセスアクセス許可を付与し、前述のバケットポリシーで設定された `s3:GetBucketAcl ` アクセス許可で示されている `Condition` パラメータを含める必要があります。これを簡単にするには、新しい `Statement` を作成する代わりに、`AWSLogDeliveryAclCheck` を `“Action”: [“s3:GetBucketAcl”, “s3:ListBucket”]` であるように直接更新することができます。 ## KMS キー AWS Key Management Service でを使用するためのアクセス許可ログ記録先が AWS Key Management Service (SSE-KMS) に保存されているキーによるサーバー側の暗号化を使用していて、カスタマーマネージドキー (KMS キー) を使用する場合は、KMS キーを使用するアクセス AWS WAF 許可を付与する必要があります。そのためには、選択した送信先の KMS キーにキーポリシーを追加します。これにより、 AWS WAF ロギングがログファイルを送信先に書き込むことができます。次のキーポリシーを KMS キーに追加して、 AWS WAF が Amazon S3 バケットにログ記録できるようにします。 ``` { "Sid": "Allow AWS WAF to use the key", "Effect": "Allow", "Principal": { "Service": [ "delivery.logs.amazonaws.com" ] }, "Action": "kms:GenerateDataKey*", "Resource": "*" } ``` ## Amazon S3 ログファイルへのアクセスに必要なアクセス許可 Amazon S3 は、アクセスコントロールリスト (ACL) を使用して、 AWS WAF ログによって作成されたログファイルへのアクセスを管理します。デフォルトでは、バケット所有者が各ログファイルで `FULL_CONTROL` 許可を持ちます。ログ配信の所有者 (バケット所有者とは異なる場合) は、許可を持ちません。ログ配信アカウントには、`READ` および `WRITE` 許可があります。詳細については、「Amazon Simple Storage Service ユーザーガイド」の「[アクセスコントロールリスト (ACL) の概要](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html)」を参照してください。 # Amazon Data Firehose 配信ストリームへの保護パック (ウェブ ACL) トラフィックログ送信このセクションは、保護パック (ウェブ ACL) トラフィックログの Amazon Data Firehose 配信ストリームへの送信に関する情報を提供します。 **注記** AWS WAFの使用料金に加えて、ログ記録の料金が請求されます。詳細については、「[保護パック (ウェブ ACL) トラフィックのログ記録の料金に関する情報](logging-pricing.md)」を参照してください。ログを Amazon Data Firehose に送信するには、保護パック (ウェブ ACL) から Firehose で設定した Amazon Data Firehose 配信ストリームにログを送信します。ログ記録を有効にすると、は Firehose の HTTPS エンドポイントを介してストレージ宛先にログを AWS WAF 配信します。 1 つの AWS WAF ログは、1 つの Firehose レコードに相当します。通常、1 秒あたり 10,000 件のリクエストを受信していて、完全なログを有効にする場合、Firehose には 1 秒あたり 10,000 件のレコード設定を行う必要があります。Firehose を正しく設定しない場合、すべてのログは記録 AWS WAF されません。詳細については、「[Amazon Kinesis Data Firehose quotas](https://docs.aws.amazon.com/firehose/latest/dev/limits.html)」を参照してください。 Amazon Data Firehose 配信ストリームを作成し、保存されているログを確認する方法については、「[What Is Amazon Data Firehose?](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)」を参照してください。配信ストリームの作成の詳細については、「[Creating an Amazon Data Firehose delivery stream](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html)」を参照してください。 ## 保護パック (ウェブ ACL) の Amazon Data Firehose 配信ストリームを設定する保護パック (ウェブ ACL) の Amazon Data Firehose 配信ストリームを次のように設定します。 + 保護パック (ウェブ ACL) の管理に使用するアカウントと同じアカウントを使用して作成します。 + 保護パック (ウェブ ACL) と同じリージョンに作成します。Amazon CloudFront のログをキャプチャしている場合は、米国東部 (バージニア北部) リージョン `us-east-1` に Firehose を作成します。 + データ Firehose にプレフィックス `aws-waf-logs-` で始まる名前を付けます。例えば、`aws-waf-logs-us-east-2-analytics`。 + Direct PUT 用に設定し、アプリケーションが配信ストリームに直接アクセスできるようにします。「[Amazon Data Firehose コンソール](https://console.aws.amazon.com/firehose)」で、配信ストリームの **[ソース]** の設定に **[Direct PUT または他のソース]** を選択します。API を通じて、配信ストリームのプロパティ `DeliveryStreamType` を `DirectPut` に設定します。 **注記** `Kinesis stream` をソースとして使用しないでください。 ## Amazon Data Firehose にログを発行するために必須のアクセス権限 Kinesis Data Firehose の設定に必要な許可を理解するには、「[Controlling Access with Amazon Kinesis Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html)」(Amazon Kinesis Data Firehose によるアクセスの制御) を参照してください。 Amazon Data Firehose 配信ストリームを使用して保護パック (ウェブ ACL) のログ記録を正常に有効化するには、次のアクセス権限が付与されている必要があります。 + `iam:CreateServiceLinkedRole` + `firehose:ListDeliveryStreams` + `wafv2:PutLoggingConfiguration` サービスにリンクされたロールおよび `iam:CreateServiceLinkedRole` 許可の詳細については、「[のサービスにリンクされたロールの使用 AWS WAF](using-service-linked-roles.md)」を参照してください。 # 保護パック (ウェブ ACL) のログ記録の設定このセクションでは、保護パック (ウェブ ACL) のデータ保護を設定する手順について説明します。 **注記** AWS WAFの使用料金に加えて、ログ記録の料金が請求されます。詳細については、「[保護パック (ウェブ ACL) トラフィックのログ記録の料金に関する情報](logging-pricing.md)」を参照してください。保護パック (ウェブ ACL) のログ記録を有効にするには、使用するログ記録の送信先を既に設定しておく必要があります。ターゲットの選択肢とそれぞれの要件については、「[AWS WAF ログ記録の送信先](logging-destinations.md)」を参照してください。 **保護パック (ウェブ ACL) のログ記録を設定するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで、**[保護パック (ウェブ ACL)]** を選択します。 1. ログ記録を有効にする保護パック (ウェブ ACL) の名前を選択します。コンソールで保護パック (ウェブ ACL) の説明が表示され、そこで編集できます。 1. **[ログ記録]** タブで **[ログ記録を有効にする]** を選択します。 1. ログ記録の送信先タイプを選択し、設定したログ記録先を選択します。名前が `aws-waf-logs-` で始まるログ記録先を選択する必要があります。 1. (オプション) ログに一部のフィールドを含めたくない場合は、それらをマスキングします。マスキングするフィールドを選び、**[Add]** (追加) を選択します。必要に応じて手順を繰り返し、追加のフィールドをマスキングします。マスキングされたフィールドは、ログに `xxx` と表示されます。 **注記** この設定は、リクエストサンプリングには影響しません。保護パック (ウェブ ACL) データ保護を設定するか、保護パック (ウェブ ACL) のサンプリングを無効にすることで、リクエストサンプリングからフィールドを除外できます。 1. (オプション) すべてのリクエストをログに送信しない場合は、フィルタリング条件と動作を追加します。**[Filter logs]** (ログをフィルタリング) で、適用する各フィルターについて **[Add filter]** (フィルターを追加) を選択し、次にフィルター基準を選択して、基準に一致するリクエストを保持するかドロップするかを指定します。フィルターの追加が完了したら、必要に応じて、**[Default logging behavior]** (デフォルトのログ記録動作) を変更します。 **注記** 複数のフィルターを追加すると、 AWS WAF はそれらを上部から評価します。 1. **[Enable logging]** (ログの有効化) を選択します。 **注記** ログ記録を正常に有効にすると、 AWS WAF はログ記録の送信先にログを書き込むために必要なアクセス許可を持つサービスにリンクされたロールを作成します。詳細については、「[のサービスにリンクされたロールの使用 AWS WAF](using-service-linked-roles.md)」を参照してください。 # 保護パック (ウェブ ACL) レコードの検索このセクションでは、保護パック (ウェブ ACL) レコードを検索する方法について説明します。 **注記** AWS WAFの使用料金に加えて、ログ記録の料金が請求されます。詳細については、「[保護パック (ウェブ ACL) トラフィックのログ記録の料金に関する情報](logging-pricing.md)」を参照してください。 **ログにログレコードが見つからない場合** まれに、 AWS WAF ログ配信が 100% を下回ることがあり、ログはベストエフォートベースで配信されます。 AWS WAF アーキテクチャは、他のすべての考慮事項よりもアプリケーションのセキュリティを優先します。ロギングフローでトラフィックスロットリングが発生する場合など、状況によってはレコードがドロップされることがあります。影響するレコードは数件に限られます。ログエントリがいくつか欠落していることに気付いた場合は、[AWS サポートセンター](https://console.aws.amazon.com/support/home#/)に連絡してください。保護パック (ウェブ ACL) のログ記録設定で、 AWS WAF がログに送信する内容をカスタマイズできます。 + **フィールドのマスキング** – 対応する一致設定を使用するルールのログレコードの次のフィールドをマスキングできます: **[URI パス]**、**[クエリ文字列]**、**[単一ヘッダー]**、および **[HTTP メソッド]**。マスキングされたフィールドは、ログに `REDACTED` と表示されます。例えば、ログ内の **[クエリ文字列]** フィールドをマスキングすると、**[クエリ文字列]** 一致コンポーネント設定を使用するすべてのルールで `REDACTED` としてリストされます。マスキングは、ルールで一致するように指定したリクエストコンポーネントにのみ適用されるため、**[単一ヘッダー]** コンポーネントのマスキングは、**[ヘッダー]** で照合するルールには適用されません。ログフィールドのリストについては、「[保護パック (ウェブ ACL) トラフィックのログフィールド](logging-fields.md)」を参照してください。 **注記** この設定は、リクエストサンプリングには影響しません。保護パック (ウェブ ACL) データ保護を設定するか、保護パック (ウェブ ACL) のサンプリングを無効にすることで、リクエストサンプリングからフィールドを除外できます。 + **ログのフィルタリング** – フィルタリングを追加して、ログに保持されるウェブリクエストとドロップされるウェブリクエストを指定できます。ウェブリクエストの評価中 AWS WAF に適用される設定をフィルタリングします。次の設定でフィルタリングできます。 + **完全修飾ラベル** – 完全修飾ラベルには、プレフィックス、オプションの名前空間、およびラベル名があります。プレフィクスは、ラベルを追加したルールのルールグループまたは保護パック (ウェブ ACL) コンテキストを識別します。ラベルの詳細については、「[でのウェブリクエストのラベル付け AWS WAF](waf-labels.md)」を参照してください。 + **ルールアクション** – 通常のルールアクション設定だけでなく、ルールグループのルールのレガシー `EXCLUDED_AS_COUNT` オーバーライドオプションをフィルタリングできます。ルールアクションの設定については、「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」を参照してください。ルールグループのルールの現在のルールアクションオーバーライドとレガシールールアクションオーバーライドについては、「[でのルールグループアクションの上書き AWS WAF](web-acl-rule-group-override-options.md)」を参照してください。 + 通常のルールアクションフィルターは、ルールで設定されたアクションだけでなく、ルールグループのルールアクションをオーバーライドするための現在のオプションを使用して設定されたアクションにも適用されます。 + `EXCLUDED_AS_COUNT` ログフィルターは、`Count` アクションログフィルターと重複しています。`EXCLUDED_AS_COUNT` は、ルールグループのルールアクションを Count にオーバーライドするための現在のオプションとレガシーオプションの両方をフィルタリングします。 # 保護パック (ウェブ ACL) トラフィックのログフィールド次のリストは、可能なログフィールドについて説明しています。 **action** がリクエスト AWS WAF に適用した終了アクション。これは許可、ブロック、CAPTCHA、チャレンジのいずれかを示します。ウェブリクエストに有効なトークンが含まれていないとき、CAPTCHA および Challenge アクションは終了します。 **args** クエリ文字列。 **captchaResponse** CAPTCHA アクションがリクエストに適用されたときに入力される、リクエストの CAPTCHA アクションステータス。このフィールドは、終了の有無にかかわらず、すべての CAPTCHA アクションに入力されます。リクエストに CAPTCHA アクションが複数回適用されている場合、このフィールドはアクションが最後に適用された時点から入力されます。リクエストにトークンが含まれていない、あるいはトークンが無効または有効期限切れているとき、CAPTCHA アクションはウェブリクエストの検査を終了します。CAPTCHA アクションが終了している場合、このフィールドにはレスポンスコードと失敗の理由が含まれます。アクションが非終了型の場合、このフィールドには解決タイムスタンプが含まれます。終了アクションと非終了アクションを区別するには、このフィールドで空でない `failureReason` 属性をフィルタリングできます。 **cfDistributionTenantId** ウェブリクエストに関連付けられた CloudFront ディストリビューションテナントの識別子。このフィールドはオプションであり、CloudFront ディストリビューションテナントに関連付けられた保護パック (ウェブ ACL) にのみ適用されます。 **challengeResponse** Challenge アクションがリクエストに適用されたときに入力される、リクエストのチャレンジアクションステータス。このフィールドは、終了の有無にかかわらず、すべての Challenge アクションに入力されます。リクエストに Challenge アクションが複数回適用されている場合、このフィールドはアクションが最後に適用された時点から入力されます。リクエストにトークンが含まれていない、あるいはトークンが無効または有効期限切れているとき、Challenge アクションはウェブリクエストの検査を終了します。Challenge アクションが終了している場合、このフィールドにはレスポンスコードと失敗の理由が含まれます。アクションが非終了型の場合、このフィールドには解決タイムスタンプが含まれます。終了アクションと非終了アクションを区別するには、このフィールドで空でない `failureReason` 属性をフィルタリングできます。 **clientAsn** ウェブリクエストのオリジンの IP アドレスに関連付けられた AS 番号 (ASN)。 **clientAsn** は、ASN 一致ステートメントが使用されている場合にのみ AWS WAF ログに記録されます。このフィールドは、それ以外の場合はログに記録されません。 **clientIp** リクエストを送信するクライアントの IP アドレス。 **country** リクエストの送信国。 AWS WAF が原産国を特定できない場合、このフィールドはに設定されます`-`。 **country** リクエストの送信国。 AWS WAF が原産国を特定できない場合、このフィールドはに設定されます`-`。 **excludedRules** ルールグループのルールにのみ使用されます。除外されているルールグループ内のルールのリスト。これらのルールのアクションは Count に設定されています。オーバーライドルールアクションのオプションを使用してルールがカウントするようにオーバーライドする場合、一致するものはここには一覧表示されません。アクションペア `action` および `overriddenAction` として一覧表示されています。 exclusionType 除外されたルールにアクション Count があることを示すタイプ。 ruleId 除外されたルールグループ内のルールの ID。 **formatVersion** ログの形式バージョン。 **forwardedAsn** ウェブリクエストを転送したエンティティのの IP アドレスに関連付けられた AS 番号 (ASN)。 **headers** ヘッダーの一覧。 **httpMethod** リクエストの HTTP メソッド。 **httpRequest** リクエストに関するメタデータです。 **httpSourceId** 関連付けられたリソースの ID。 + Amazon CloudFront ディストリビューションの場合、ID は ARN 構文で `distribution-id` です。 `arn:partitioncloudfront::account-id:distribution/distribution-id` + Application Load Balancer の場合、ID は ARN 構文で `load-balancer-id` です。 `arn:partition:elasticloadbalancing:region:account-id:loadbalancer/app/load-balancer-name/load-balancer-id` + Amazon API Gateway REST API の場合、ID は ARN 構文で `api-id` です。 `arn:partition:apigateway:region::/restapis/api-id/stages/stage-name` + AWS AppSync GraphQL API の場合、ID は ARN 構文`GraphQLApiId`のです。 `arn:partition:appsync:region:account-id:apis/GraphQLApiId` + Amazon Cognito ユーザープールの場合、ID は ARN 構文で `user-pool-id` です。 `arn:partition:cognito-idp:region:account-id:userpool/user-pool-id` + AWS App Runner サービスの場合、ID は ARN 構文`apprunner-service-id`のです。 `arn:partition:apprunner:region:account-id:service/apprunner-service-name/apprunner-service-id` **httpSourceName** リクエストの送信元。指定できる値: Amazon CloudFront `CF` の場合、`APIGW`Amazon API Gateway `ALB` の場合、Application Load Balancer `APPSYNC`の場合、Amazon Cognito AWS AppSync`COGNITOIDP` の場合、App Runner `APPRUNNER` の場合、Verified Access `VERIFIED_ACCESS` の場合。 **httpVersion** HTTP のバージョン。 **ja3Fingerprint** リクエストの JA3 フィンガープリント。 JA3 フィンガープリント検査は、Amazon CloudFront ディストリビューションと Application Load Balancer でのみ利用可能です。 JA3 フィンガープリントは、受信リクエストの TLS Client Hello から生成される 32 文字のハッシュです。このフィンガープリントは、クライアントの TLS 設定の一意の識別子として機能します。 AWS WAF は、計算に十分な TLS Client Hello 情報を持つリクエストごとに、このフィンガープリントを計算してログに記録します。この値は、保護パック (ウェブ ACL) ルールで JA3 フィンガープリントの一致を設定するときに指定します。JA3 フィンガープリントとの一致を作成する方法については、「[でコンポーネントをリクエストする AWS WAF](waf-rule-statement-fields-list.md)」の「[JA3 フィンガープリント](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-ja3-fingerprint)」に記載されているルールステートメントを参照してください。 **ja4Fingerprint** リクエストの JA4 フィンガープリント。 JA4 フィンガープリント検査は、Amazon CloudFront ディストリビューションと Application Load Balancer でのみ使用できます。 JA4 フィンガープリントは、受信リクエストの TLS Client Hello から派生した 36 文字のハッシュです。このフィンガープリントは、クライアントの TLS 設定の一意の識別子として機能します。 AWS WAF は、計算に十分な TLS Client Hello 情報を持つリクエストごとに、このフィンガープリントを計算してログに記録します。この値は、保護パック (ウェブ ACL) ルールで JA4 フィンガープリントの一致を設定するときに指定します。JA4 フィンガープリントとの一致の作成については、ルールステートメント[でコンポーネントをリクエストする AWS WAF](waf-rule-statement-fields-list.md)の [JA4 フィンガープリント](waf-rule-statement-fields-list.md#waf-rule-statement-request-component-ja4-fingerprint)の「」を参照してください。 **ラベル** ウェブリクエストのラベル。これらのラベルは、最初の 100 AWS WAF 個のラベルの評価に使用されたルールによって適用されました。 **nonTerminatingMatchingRules** リクエストに一致した非終了型ルールのリスト。各リスト項目には、次の情報が含まれています。 action がリクエスト AWS WAF に適用したアクション。カウント、CAPTCHA、チャレンジのいずれかを示します。ウェブリクエストに有効なトークンが含まれていると、CAPTCHA および Challenge は終了処理しません。 ruleId リクエストに一致し、非終了ルールの ID。 ruleMatchDetails リクエストに一致したルールに関する詳細情報。このフィールドは、SQL インジェクションおよびクロスサイトスクリプティング (XSS) 一致ルールステートメントに対してのみ設定されます。一致ルールでは、複数の検査基準の一致が必要になる場合があるため、これらの一致の詳細は、一致基準の配列として提供されます。各ルールに提供される追加情報は、ルール設定、ルール一致タイプ、一致の詳細などの要因によって異なります。たとえば、CAPTCHA または Challenge アクションを持つルールの場合、`captchaResponse` または`challengeResponse` が一覧表示されます。一致するルールがルールグループにあり、その設定済みルールアクションをオーバーライドした場合、設定済みアクションは `overriddenAction` で提供されます。 **oversizeFields** 保護パック (ウェブ ACL) によって検査され、 AWS WAF 検査制限を超えているウェブリクエスト内のフィールドのリスト。フィールドがオーバーサイズであっても、保護パック (ウェブ ACL) が検査しない場合、ここには表示されません。このリストには、`REQUEST_BODY`、`REQUEST_JSON_BODY`、`REQUEST_HEADERS`、および `REQUEST_COOKIES` の値が何個か含まれることも、含まれないこともあります。オーバーサイズフィールドの詳細については、「[でのウェブリクエストコンポーネントのオーバーサイズ化 AWS WAF](waf-oversize-request-components.md)」を参照してください。 **rateBasedRuleList** このリクエストで動作したレートベースのルールのリスト。レートベースルールの詳細については、「[でのレートベースのルールステートメントの使用 AWS WAF](waf-rule-statement-type-rate-based.md)」を参照してください。 rateBasedRuleId このリクエストで動作したレートベースのルールの ID。これがリクエストを終了した場合、`rateBasedRuleId` の ID は、`terminatingRuleId` の ID と同じです。 rateBasedRuleName このリクエストで動作したレートベースのルールの名前。 limitKey ルールが使用している集約のタイプ。指定できる値は、ウェブリクエストの発信元用の `IP`、リクエストのヘッダーで転送された IP 用の `FORWARDED_IP`、カスタム集約キー設定用の `CUSTOMKEYS`、および集約なしですべてのリクエストをまとめてカウントする用の `CONSTANT` です。 limitValue 単一の IP アドレスタイプでレート制限を行う場合にのみ使用される。リクエストに有効ではない IP アドレスが含まれている場合、`limitvalue` は `INVALID` です。 maxRateAllowed 特定の集約インスタンスに対して指定された時間枠で許可されるリクエストの最大数。集約インスタンスは、`limitKey` およびレートベースのルール設定で提供される追加のキー仕様によって定義されます。 evaluationWindowSec がリクエストに AWS WAF 含めた時間を秒単位でカウントします。 customValues リクエスト内のレートベースのルールによって識別される一意の値。文字列値の場合、ログは文字列値の最初の 32 文字を出力します。キータイプに応じて、これらの値は HTTP メソッドやクエリ文字列といったキーだけの場合もあれば、ヘッダーやヘッダー名のようなキーと名前の場合もあります。 **requestHeadersInserted** カスタムリクエストの処理用に挿入されるヘッダーのリスト。 **requestId** 基盤となるホストサービスによって生成されるリクエストの ID。Application Load Balancer では、これはトレース ID です。その他すべての場合、これはリクエスト ID です。 **responseCodeSent** カスタムレスポンスで送信されるレスポンスコード。 **ruleGroupId** ルールグループの ID ルールがリクエストをブロックした場合、`ruleGroupID` の ID は、`terminatingRuleId` の ID と同じです。 **ruleGroupList** このリクエストに対して動作したルールグループのリスト (一致情報を含む)。 **terminatingRule** リクエストを終了したルール。これが存在する場合、次の情報が含まれます。 action がリクエスト AWS WAF に適用した終了アクション。これは許可、ブロック、CAPTCHA、チャレンジのいずれかを示します。ウェブリクエストに有効なトークンが含まれていないとき、CAPTCHA および Challenge アクションは終了します。 ruleId リクエストに一致したルールの ID。 ruleMatchDetails リクエストに一致したルールに関する詳細情報。このフィールドは、SQL インジェクションおよびクロスサイトスクリプティング (XSS) 一致ルールステートメントに対してのみ設定されます。一致ルールでは、複数の検査基準の一致が必要になる場合があるため、これらの一致の詳細は、一致基準の配列として提供されます。各ルールに提供される追加情報は、ルール設定、ルール一致タイプ、一致の詳細などの要因によって異なります。たとえば、CAPTCHA または Challenge アクションを持つルールの場合、`captchaResponse` または`challengeResponse` が一覧表示されます。一致するルールがルールグループにあり、その設定済みルールアクションをオーバーライドした場合、設定済みアクションは `overriddenAction` で提供されます。 **terminatingRuleId** リクエストを終了したルールの ID。リクエストを終了したものがない場合、この値は `Default_Action` となります。 **terminatingRuleMatchDetails** リクエストに一致した終了ルールに関する詳細情報。終了ルールには、ウェブリクエストに対する検査プロセスを終了するアクションがあります。終了ルールに可能なアクションには、Allow、Block、CAPTCHA、Challenge が含まれます。ウェブリクエストの検査中に、リクエストに一致し、終了アクションを持つ最初のルールで、は検査 AWS WAF を停止し、アクションを適用します。ウェブリクエストには、一致する終了ルールのログで報告された脅威に加えて、他の脅威が含まれている可能性があります。これは、SQL インジェクションおよびクロスサイトスクリプティング (XSS) 一致ルールステートメントに対してのみ設定されます。一致ルールでは、複数の検査基準の一致が必要になる場合があるため、これらの一致の詳細は、一致基準の配列として提供されます。 **terminatingRuleType** リクエストを終了したルールのタイプ。可能な値: RATE\$1BASED、REGULAR、GROUP、MANAGED\$1RULE\$1GROUP。 **timestamp** タイムスタンプ (ミリ秒単位)。 **uri** リクエストの URI。 **fragment** 「\$1」記号の後に続く URL の一部で、\$1section2 など、リソースに関する追加情報を提供します。 **webaclId** 保護パック (ウェブ ACL) の GUID。 # 保護パック (ウェブ ACL) トラフィックのログ例このセクションでは、保護パック (ウェブ ACL) トラフィックをログに記録する例を示します。 **Example レートベースのルール 1: キーが 1 つで、`Header:dogname` に設定されたルール設定** ``` { "Name": "RateBasedRule", "Priority": 1, "Statement": { "RateBasedStatement": { "Limit": 100, "AggregateKeyType": "CUSTOM_KEYS", "CustomKeys": [ { "Header": { "Name": "dogname", "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } } ] } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "RateBasedRule" } } ``` **Example レートベースのルール 1: レートベースのルールによってブロックされたリクエストのログエントリ** ``` { "timestamp":1683355579981, "formatVersion":1, "webaclId": ..., "terminatingRuleId":"RateBasedRule", "terminatingRuleType":"RATE_BASED", "action":"BLOCK", "terminatingRuleMatchDetails":[ ], "httpSourceName":"APIGW", "httpSourceId":"EXAMPLE11:rjvegx5guh:CanaryTest", "ruleGroupList":[ ], "rateBasedRuleList":[ { "rateBasedRuleId": ..., "rateBasedRuleName":"RateBasedRule", "limitKey":"CUSTOMKEYS", "maxRateAllowed":100, "evaluationWindowSec":"120", "customValues":[ { "key":"HEADER", "name":"dogname", "value":"ella" } ] } ], "nonTerminatingMatchingRules":[ ], "requestHeadersInserted":null, "responseCodeSent":null, "httpRequest":{ "clientIp":"52.46.82.45", "country":"FR", "headers":[ { "name":"X-Forwarded-For", "value":"52.46.82.45" }, { "name":"X-Forwarded-Proto", "value":"https" }, { "name":"X-Forwarded-Port", "value":"443" }, { "name":"Host", "value":"rjvegx5guh.execute-api.eu-west-3.amazonaws.com" }, { "name":"X-Amzn-Trace-Id", "value":"Root=1-645566cf-7cb058b04d9bb3ee01dc4036" }, { "name":"dogname", "value":"ella" }, { "name":"User-Agent", "value":"RateBasedRuleTestKoipOneKeyModulePV2" }, { "name":"Accept-Encoding", "value":"gzip,deflate" } ], "uri":"/CanaryTest", "args":"", "httpVersion":"HTTP/1.1", "httpMethod":"GET", "requestId":"Ed0AiHF_CGYF-DA=" } } ``` **Example レートベースのルール 2: キーが 2 つで、`Header:dogname` および `Header:catname` に設定されたルール設定** ``` { "Name": "RateBasedRule", "Priority": 1, "Statement": { "RateBasedStatement": { "Limit": 100, "AggregateKeyType": "CUSTOM_KEYS", "CustomKeys": [ { "Header": { "Name": "dogname", "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } }, { "Header": { "Name": "catname", "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } } ] } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "RateBasedRule" } } ``` **Example レートベースのルール 2: レートベースのルールによってブロックされたリクエストのログエントリ** ``` { "timestamp":1633322211194, "formatVersion":1, "webaclId":..., "terminatingRuleId":"RateBasedRule", "terminatingRuleType":"RATE_BASED", "action":"BLOCK", "terminatingRuleMatchDetails":[ ], "httpSourceName":"APIGW", "httpSourceId":"EXAMPLE11:rjvegx5guh:CanaryTest", "ruleGroupList":[ ], "rateBasedRuleList":[ { "rateBasedRuleId":..., "rateBasedRuleName":"RateBasedRule", "limitKey":"CUSTOMKEYS", "maxRateAllowed":100, "evaluationWindowSec":"120", "customValues":[ { "key":"HEADER", "name":"dogname", "value":"ella" }, { "key":"HEADER", "name":"catname", "value":"goofie" } ] } ], "nonTerminatingMatchingRules":[ ], "requestHeadersInserted":null, "responseCodeSent":null, "httpRequest":{ "clientIp":"52.46.82.35", "country":"FR", "headers":[ { "name":"X-Forwarded-For", "value":"52.46.82.35" }, { "name":"X-Forwarded-Proto", "value":"https" }, { "name":"X-Forwarded-Port", "value":"443" }, { "name":"Host", "value":"23llbyn8v3.execute-api.eu-west-3.amazonaws.com" }, { "name":"X-Amzn-Trace-Id", "value":"Root=1-64556629-17ac754c2ed9f0620e0f2a0c" }, { "name":"catname", "value":"goofie" }, { "name":"dogname", "value":"ella" }, { "name":"User-Agent", "value":"Apache-HttpClient/UNAVAILABLE (Java/11.0.19)" }, { "name":"Accept-Encoding", "value":"gzip,deflate" } ], "uri":"/CanaryTest", "args":"", "httpVersion":"HTTP/1.1", "httpMethod":"GET", "requestId":"EdzmlH5OCGYF1vQ=" } } ``` **Example SQLi 検出 (終了) でトリガーされたルールのログ出力** ``` { "timestamp": 1576280412771, "formatVersion": 1, "webaclId": "arn:aws:wafv2:ap-southeast-2:111122223333:regional/webacl/STMTest/1EXAMPLE-2ARN-3ARN-4ARN-123456EXAMPLE", "terminatingRuleId": "STMTest_SQLi_XSS", "terminatingRuleType": "REGULAR", "action": "BLOCK", "terminatingRuleMatchDetails": [ { "conditionType": "SQL_INJECTION", "sensitivityLevel": "HIGH", "location": "HEADER", "matchedData": [ "10", "AND", "1" ] } ], "httpSourceName": "-", "httpSourceId": "-", "ruleGroupList": [], "rateBasedRuleList": [], "nonTerminatingMatchingRules": [], "httpRequest": { "clientIp": "1.1.1.1", "country": "AU", "headers": [ { "name": "Host", "value": "localhost:1989" }, { "name": "User-Agent", "value": "curl/7.61.1" }, { "name": "Accept", "value": "*/*" }, { "name": "x-stm-test", "value": "10 AND 1=1" } ], "uri": "/myUri", "args": "", "httpVersion": "HTTP/1.1", "httpMethod": "GET", "requestId": "rid" }, "labels": [ { "name": "value" } ] } ``` **Example SQLi 検出 (非終了) でトリガーされたルールのログ出力** ``` { "timestamp":1592357192516 ,"formatVersion":1 ,"webaclId":"arn:aws:wafv2:us-east-1:123456789012:global/webacl/hello-world/5933d6d9-9dde-js82-v8aw-9ck28nv9" ,"terminatingRuleId":"Default_Action" ,"terminatingRuleType":"REGULAR" ,"action":"ALLOW" ,"terminatingRuleMatchDetails":[] ,"httpSourceName":"-" ,"httpSourceId":"-" ,"ruleGroupList":[] ,"rateBasedRuleList":[] ,"nonTerminatingMatchingRules": [{ "ruleId":"TestRule" ,"action":"COUNT" ,"ruleMatchDetails": [{ "conditionType":"SQL_INJECTION" ,"sensitivityLevel": "HIGH" ,"location":"HEADER" ,"matchedData":[ "10" ,"and" ,"1"] }] }] ,"httpRequest":{ "clientIp":"3.3.3.3" ,"country":"US" ,"headers":[ {"name":"Host","value":"localhost:1989"} ,{"name":"User-Agent","value":"curl/7.61.1"} ,{"name":"Accept","value":"*/*"} ,{"name":"myHeader","myValue":"10 AND 1=1"} ] ,"uri":"/myUri","args":"" ,"httpVersion":"HTTP/1.1" ,"httpMethod":"GET" ,"requestId":"rid" }, "labels": [ { "name": "value" } ] } ``` **Example ルールグループ内でトリガーされた複数のルールのログ出力 (RuleA-XSS は終了、Rule-B は非終了)** ``` { "timestamp":1592361810888, "formatVersion":1, "webaclId":"arn:aws:wafv2:us-east-1:123456789012:global/webacl/hello-world/5933d6d9-9dde-js82-v8aw-9ck28nv9" ,"terminatingRuleId":"RG-Reference" ,"terminatingRuleType":"GROUP" ,"action":"BLOCK", "terminatingRuleMatchDetails": [{ "conditionType":"XSS" ,"location":"HEADER" ,"matchedData":["<","frameset"] }] ,"httpSourceName":"-" ,"httpSourceId":"-" ,"ruleGroupList": [{ "ruleGroupId":"arn:aws:wafv2:us-east-1:123456789012:global/rulegroup/hello-world/c05lb698-1f11-4m41-aef4-99a506d53f4b" ,"terminatingRule":{ "ruleId":"RuleA-XSS" ,"action":"BLOCK" ,"ruleMatchDetails":null } ,"nonTerminatingMatchingRules": [{ "ruleId":"RuleB-SQLi" ,"action":"COUNT" ,"ruleMatchDetails": [{ "conditionType":"SQL_INJECTION" ,"sensitivityLevel": "LOW" ,"location":"HEADER" ,"matchedData":[ "10" ,"and" ,"1"] }] }] ,"excludedRules":null }] ,"rateBasedRuleList":[] ,"nonTerminatingMatchingRules":[] ,"httpRequest":{ "clientIp":"3.3.3.3" ,"country":"US" ,"headers": [ {"name":"Host","value":"localhost:1989"} ,{"name":"User-Agent","value":"curl/7.61.1"} ,{"name":"Accept","value":"*/*"} ,{"name":"myHeader1","value":""} ,{"name":"myHeader2","value":"10 AND 1=1"} ] ,"uri":"/myUri" ,"args":"" ,"httpVersion":"HTTP/1.1" ,"httpMethod":"GET" ,"requestId":"rid" }, "labels": [ { "name": "value" } ] } ``` **Example コンテンツタイプ JSON を使用したリクエストボディの検査のためにトリガーされたルールのログ出力** AWS WAF は現在、JSON 本文検査の場所をとして報告しています`UNKNOWN`。 ``` { "timestamp": 1576280412771, "formatVersion": 1, "webaclId": "arn:aws:wafv2:ap-southeast-2:123456789012:regional/webacl/test/111", "terminatingRuleId": "STMTest_SQLi_XSS", "terminatingRuleType": "REGULAR", "action": "BLOCK", "terminatingRuleMatchDetails": [ { "conditionType": "SQL_INJECTION", "sensitivityLevel": "LOW", "location": "UNKNOWN", "matchedData": [ "10", "AND", "1" ] } ], "httpSourceName": "ALB", "httpSourceId": "alb", "ruleGroupList": [], "rateBasedRuleList": [], "nonTerminatingMatchingRules": [], "requestHeadersInserted":null, "responseCodeSent":null, "httpRequest": { "clientIp": "1.1.1.1", "country": "AU", "headers": [], "uri": "", "args": "", "httpVersion": "HTTP/1.1", "httpMethod": "POST", "requestId": "null" }, "labels": [ { "name": "value" } ] } ``` **Example 有効期限が切れていない有効な CAPTCHA トークンを使用したウェブリクエストに対する CAPTCHA ルールのログ出力** 次のログリストは、CAPTCHA アクションを持つルールと一致したウェブリクエストについてのものです。ウェブリクエストには有効で有効期限が切れていない CAPTCHA トークンがあり、Countアクションの動作と同様に AWS WAF、による CAPTCHA 一致としてのみ記録されます。この CAPTCHA の一致については、`nonTerminatingMatchingRules` に記載されています。 ``` { "timestamp": 1632420429309, "formatVersion": 1, "webaclId": "arn:aws:wafv2:us-east-1:123456789012:regional/webacl/captcha-web-acl/585e38b5-afce-4d2a-b417-14fb08b66c67", "terminatingRuleId": "Default_Action", "terminatingRuleType": "REGULAR", "action": "ALLOW", "terminatingRuleMatchDetails": [], "httpSourceName": "APIGW", "httpSourceId": "123456789012:b34myvfw0b:pen-test", "ruleGroupList": [], "rateBasedRuleList": [], "nonTerminatingMatchingRules": [ { "ruleId": "captcha-rule", "action": "CAPTCHA", "ruleMatchDetails": [], "captchaResponse": { "responseCode": 0, "solveTimestamp": 1632420429 } } ], "requestHeadersInserted": [ { "name": "x-amzn-waf-test-header-name", "value": "test-header-value" } ], "responseCodeSent": null, "httpRequest": { "clientIp": "72.21.198.65", "country": "US", "headers": [ { "name": "X-Forwarded-For", "value": "72.21.198.65" }, { "name": "X-Forwarded-Proto", "value": "https" }, { "name": "X-Forwarded-Port", "value": "443" }, { "name": "Host", "value": "b34myvfw0b.gamma.execute-api.us-east-1.amazonaws.com" }, { "name": "X-Amzn-Trace-Id", "value": "Root=1-614cc24d-5ad89a09181910c43917a888" }, { "name": "cache-control", "value": "max-age=0" }, { "name": "sec-ch-ua", "value": "\"Chromium\";v=\"94\", \"Google Chrome\";v=\"94\", \";Not A Brand\";v=\"99\"" }, { "name": "sec-ch-ua-mobile", "value": "?0" }, { "name": "sec-ch-ua-platform", "value": "\"Windows\"" }, { "name": "upgrade-insecure-requests", "value": "1" }, { "name": "user-agent", "value": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.54 Safari/537.36" }, { "name": "accept", "value": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9" }, { "name": "sec-fetch-site", "value": "same-origin" }, { "name": "sec-fetch-mode", "value": "navigate" }, { "name": "sec-fetch-user", "value": "?1" }, { "name": "sec-fetch-dest", "value": "document" }, { "name": "referer", "value": "https://b34myvfw0b.gamma.execute-api.us-east-1.amazonaws.com/pen-test/pets" }, { "name": "accept-encoding", "value": "gzip, deflate, br" }, { "name": "accept-language", "value": "en-US,en;q=0.9" }, { "name": "cookie", "value": "aws-waf-token=51c71352-41f5-4f6d-b676-c24907bdf819:EQoAZ/J+AAQAAAAA:t9wvxbw042wva7E2Y6lgud/bS6YG0CJKVAJqaRqDZ140ythKW0Zj9wKB2O8lSkYDRqf1yONcVBFo5u0eYi0tvT4rtQCXsu+KanAardW8go4QSLw4yoED59lgV7oAhGyCalAzE7ra29j+RvvZPsQyoQuDCrtoY/TvQyMTXIXzGPDC/rKBbg==" } ], "uri": "/pen-test/pets", "args": "", "httpVersion": "HTTP/1.1", "httpMethod": "GET", "requestId": "GINMHHUgoAMFxug=" } } ``` **Example CAPTCHA トークンがないウェブリクエストに対する CAPTCHA ルールのログ出力** 次のログリストは、CAPTCHA アクションを持つルールと一致したウェブリクエストについてのものです。ウェブリクエストに CAPTCHA トークンがなく、によってブロックされました AWS WAF。 ``` { "timestamp": 1632420416512, "formatVersion": 1, "webaclId": "arn:aws:wafv2:us-east-1:123456789012:regional/webacl/captcha-web-acl/585e38b5-afce-4d2a-b417-14fb08b66c67", "terminatingRuleId": "captcha-rule", "terminatingRuleType": "REGULAR", "action": "CAPTCHA", "terminatingRuleMatchDetails": [], "httpSourceName": "APIGW", "httpSourceId": "123456789012:b34myvfw0b:pen-test", "ruleGroupList": [], "rateBasedRuleList": [], "nonTerminatingMatchingRules": [], "requestHeadersInserted": null, "responseCodeSent": 405, "httpRequest": { "clientIp": "72.21.198.65", "country": "US", "headers": [ { "name": "X-Forwarded-For", "value": "72.21.198.65" }, { "name": "X-Forwarded-Proto", "value": "https" }, { "name": "X-Forwarded-Port", "value": "443" }, { "name": "Host", "value": "b34myvfw0b.gamma.execute-api.us-east-1.amazonaws.com" }, { "name": "X-Amzn-Trace-Id", "value": "Root=1-614cc240-18b57ff33c10e5c016b508c5" }, { "name": "sec-ch-ua", "value": "\"Chromium\";v=\"94\", \"Google Chrome\";v=\"94\", \";Not A Brand\";v=\"99\"" }, { "name": "sec-ch-ua-mobile", "value": "?0" }, { "name": "sec-ch-ua-platform", "value": "\"Windows\"" }, { "name": "upgrade-insecure-requests", "value": "1" }, { "name": "user-agent", "value": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.54 Safari/537.36" }, { "name": "accept", "value": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9" }, { "name": "sec-fetch-site", "value": "cross-site" }, { "name": "sec-fetch-mode", "value": "navigate" }, { "name": "sec-fetch-user", "value": "?1" }, { "name": "sec-fetch-dest", "value": "document" }, { "name": "accept-encoding", "value": "gzip, deflate, br" }, { "name": "accept-language", "value": "en-US,en;q=0.9" } ], "uri": "/pen-test/pets", "args": "", "httpVersion": "HTTP/1.1", "httpMethod": "GET", "requestId": "GINKHEssoAMFsrg=" }, "captchaResponse": { "responseCode": 405, "solveTimestamp": 0, "failureReason": "TOKEN_MISSING" } } ``` # データ保護 AWS WAF データ保護設定を使用すると、ヘッダー、パラメータ、本文コンテンツなどの特定のデータフィールドに、機密情報 (パスワード、API キー、認証トークン、その他の機密データ) のカスタマイズされたきめ細かな保護を実装できます。データ保護は、次のいずれかで設定できます。 + すべての出力先に適用される保護パック (ウェブ ACL) レベル。 + ログ記録のみ。これは、が設定されたログ記録先 AWS WAF に送信するデータにのみ影響します。データ保護は、置換またはハッシュとして指定できます。置換とは、コンテンツを `REDACTED` という単語に置き換えることを指します。ハッシュとは、文字列から Base64 への SHA-256 バイナリにコンテンツを置き換えることを指します。 1. まず、アルゴリズムは account\$1number とコンテンツから文字列を構築します。 1. 次に、SHA-256 を適用してバイナリハッシュを生成します。 1. 最後に、Base64 を使用してこれらのバイトをエンコードします。 **ヒント** 適切なデータ保護方法を選択する前に、SHA-256 ハッシュの特性を確認して、要件を満たしているかどうかを判断する必要があります。暗号化またはトークン化と同等の結果を実現する場合は、SHA-256 ハッシュを使用することはお勧めしません。 **Topics** + [ # データ保護の有効化 ](enable-protection.md) + [ # データ保護の例外 ](data-protection-exceptions.md) + [ # データ保護制限 ](data-protection-limitations.md) + [ # データ保護の例 ](data-protection-examples.md) + [ # 保護パック (ウェブ ACL) のデータ保護の設定 ](data-protection-configure.md) # データ保護の有効化このセクションでは、コンソールから選択できるデータ保護とログ設定オプションについて説明します。特定のフィールドでデータ保護を有効にすることで、ログに表示されるデータを保護できます。データ保護を適用して、フルログ、サンプルリクエスト、Security Lake など、さまざまなタイプの出力で機密情報を変換できます。 ** AWS WAF コンソールでデータ保護を有効にするには** コンソールで **保護パック (ウェブ ACL)** ページに移動して、**保護設定の有効化** を行います。ログのデータ保護を有効にするには、それをすべてのログに適用するか、特定のログ送信先に適用するかを選択します。詳細については、「[保護パック (ウェブ ACL) トラフィックのログフィールド](logging-fields.md)」を参照してください。 **注記** すべてのログ記録にデータ保護を適用するために、ログ記録を有効にする必要はありません。データ保護は、ログ記録が有効になっているかどうかにかかわらず、すべての出力先に適用されます。 **[保護設定の有効化]** ページの下部で、**[データ保護]** フィールドパネルの **[フィールドの追加]** ボタンを選択します。ドロップダウンメニューからフィールドタイプを選択します。各フィールドのデータがデータ保護でどのように保護されるかについては、以下の表を参照してください。 | フィールドタイプ | Details | | --- | --- | | `Single header` | 指定されたオプション (ハッシュまたは部分配置) に従って、指定されたヘッダーキー値を永続的に変換します。変換された値は完全なログにも反映されます。 | | `Body` | 本文の値を永続的に変換します。ログ内の `RuleMatchDetails` にのみ適用できます。 | | `Query string` | 指定されたオプション (ハッシュまたは部分配置) に従って、クエリ文字列を永続的に変換します。変換された値は完全なログにも反映されます。 | | `Single query argument` | 指定されたオプション (ハッシュまたは部分配置) に従って、指定されたクエリ引数値を永続的に変換します。変換された値は完全なログにも反映されます。 | | `Single cookie` | 指定されたオプション (ハッシュまたは部分配置) に従って、Cookie 値を永続的に変換します。変換された値は完全なログにも反映されます。 | # データ保護の例外有効にすると、`RuleMatchDetails` や `rateBasedRuleList` など、有効になっているフィールドにデータ保護が適用されます。ただし、トラブルシューティングと可視性の目的で、保護されたデータとコンテンツを `RuleMatchDetails` および `rateBasedRuleList` に含める必要がある場合があります。これらのシナリオでは、そのフィールドのデータ保護に例外を指定できます。 + **`ExcludeRuleMatchDetails`**: 特定のフィールドにこの例外を指定すると、`RuleMatchDetails` はフィールドの値を表示し、データ保護の対象外になります。 + **`ExcludeRateBasedDetails`**: 特定のフィールドにこの例外を指定すると、`rateBasedRuleList` はフィールドの値を表示し、データ保護の対象外になります。例: `ExcludeRateBasedDetails` ルールは「dogname」の **SINGLE\$1HEADER** と **HEADER\$1NAME** で有効になっています。ルールに例外が適用されない場合、「dogname」の値は `REDACTED` として表示されます。 ``` "rateBasedRuleList":[ {"rateBasedRuleId": ..., "rateBasedRuleName":"RateBasedRule", "limitKey":"CUSTOMKEYS", "maxRateAllowed":100, "evaluationWindowSec":"120", "customValues":[ {"key":"HEADER", "name":"dogname", "value":"REDACTED" } ] } ] ``` ルールで例外が有効になっている場合、「dogname」値がログに表示されます。 ``` "rateBasedRuleList":[ {"rateBasedRuleId": ..., "rateBasedRuleName":"RateBasedRule", "limitKey":"CUSTOMKEYS", "maxRateAllowed":100, "evaluationWindowSec":"120", "customValues":[ {"key":"HEADER", "name":"dogname", "value":"ELLA" } ] } ] ``` **警告** データ保護機能は、トラブルシューティング AWS WAF 機能に影響を与える可能性があります。これらの設定により、予期しない検出および緩和動作が発生する可能性があります。特定のパラメータのデータ保護を、絶対に必要なパラメータのみに制限します。 # データ保護制限以下は、データ保護を使用する際に考慮すべき制限です。 ## QueryString と SingleQueryArg **QueryString の保護** + `QueryString` のデータ保護は、すべてのクエリ引数に適用され、指定された設定に従ってキーと値の両方を置換/ハッシングします。 `RuleMatch` の詳細と `RateBased` ルールリストの **QueryString** + データ保護が単一クエリ引数に適用される場合、クエリ文字列全体が完全なログの `RuleMatchDetails` および `RateBasedRule` セクションで置換/ハッシングされます。 + 複数の単一クエリ引数で異なる保護方法 (置換とハッシング) が指定されている場合、より厳密なメソッドである置換は、完全なログの `RuleMatchDetails` および `RateBasedRule` セクションのクエリ文字列全体に適用されます。 ## cookie **注記** データ保護は、単一ヘッダー Cookie が保護されている場合にのみ、 Cookie の値に適用されます。 **`RuleMatchDetails` および `RateBasedRule` リストの単一 Cookie** + データ保護が 1 つの Cookie に適用される場合、Cookie ヘッダー全体が完全なログの `RuleMatchDetails` および `RateBasedRule` セクションで置換/ハッシングされます。 + 異なる保護方法 (置換とハッシング) が指定されている場合、より厳密なメソッドである置換は、完全なログの `RuleMatchDetails` および `RateBasedRule` セクションの Cookie 全体に適用されます。 # データ保護の例このセクションでは、保護パック (ウェブ ACL) トラフィックのデータ保護ログ記録のログ例を示します。 ## DataProtection ハッシング Webacl 設定 ``` "data_protection_config": { "data_protections": [ { "field": { "field_type": "SINGLE_QUERY_ARGUMENT", "field_keys": [ "hoppy" ] }, "action": "HASH", "exclude_rule_match_details": false, "exclude_rate_based_details": false } ] } ``` DataProtection ハッシングの例: SingleQuery 引数「hoppy」が保護されたログエントリ。 ``` { "timestamp": 1738705092889, "formatVersion": 1, "webaclId": "arn:aws:wafv2:us-east-1:111122223333:regional/webacl/DataProtectionhashACL/4eede063-e611-44f5-b357-ffc9d7b7fed5", "terminatingRuleId": "Default_Action", "terminatingRuleType": "REGULAR", "action": "ALLOW", "terminatingRuleMatchDetails": [], "httpSourceName": "APIGW", "httpSourceId": "746533260405:xt7v59bhn7:ABC", "ruleGroupList": [], "rateBasedRuleList": [], "nonTerminatingMatchingRules": [{ "ruleId": "ProtectedSQLIHeadersVisibleInSTM", "action": "COUNT", "ruleMatchDetails": [{ "conditionType": "SQL_INJECTION", "sensitivityLevel": "HIGH", "location": "SINGLE_QUERY_ARG", "matchedData": [ "z6hpYAFaMYdtiTeHhxnN5ydgRE5E1WgyVIdgqH0D3iM=" ], "matchedFieldName": "hoppy" }] }], "requestHeadersInserted": null, "responseCodeSent": null, "httpRequest": { "clientIp": "54.239.98.137", "country": "US", "headers": [{ "name": "X-Forwarded-For", "value": "54.239.98.137" }, { "name": "X-Forwarded-Proto", "value": "https" }, { "name": "X-Forwarded-Port", "value": "443" }, { "name": "Host", "value": "xt7xxx9bhn7.gamma.execute-api.us-east-1.amazonaws.com" }, { "name": "X-Amzn-Trace-Id", "value": "Root=1-67a288c4-27acb3cd5795dd8456b7e3c3" }, { "name": "Accept-Encoding", "value": "gzip" }, { "name": "User-Agent", "value": "okhttp/3.12.1" }], "uri": "/CanaryTest", "args": "hoppy=z6hpYAFaMYdtiTeHhxnN5ydgRE5E1WgyVIdgqH0D3iM=&yellow=hello&x-hoppy-extra=generic-%3Cwords%3E-in-angle-brackets", "httpVersion": "HTTP/1.1", "httpMethod": "GET", "requestId": "FepO0F8fIAMEqoQ=" }, "labels": [{ "name": "awswaf:forwardedip:geo:country:US" }, { "name": "awswaf:forwardedip:geo:region:US-VA" }] } ``` ## DataProtection の置換 Webacl 設定 ``` "data_protection_config": { "data_protections": [ { "field": { "field_type": "SINGLE_QUERY_ARGUMENT", "field_keys": [ "hoppy" ] }, "action": "SUBSTITUTION", "exclude_rule_match_details": false, "exclude_rate_based_details": false } ] } ``` DataProtection 置換の例: 単一クエリ引数「hoppy」が保護されたログエントリ ``` { "timestamp": 1738705092889, "formatVersion": 1, "webaclId": "arn:aws:wafv2:us-east-1:111122223333:regional/webacl/DataProtectionhashACL/4eede063-e611-44f5-b357-ffc9d7b7fed5", "terminatingRuleId": "Default_Action", "terminatingRuleType": "REGULAR", "action": "ALLOW", "terminatingRuleMatchDetails": [], "httpSourceName": "APIGW", "httpSourceId": "746533260405:xt7v59bhn7:ABC", "ruleGroupList": [], "rateBasedRuleList": [], "nonTerminatingMatchingRules": [] "requestHeadersInserted": null, "responseCodeSent": null, "httpRequest": { "clientIp": "54.239.98.137", "country": "US", "headers": [{ "name": "X-Forwarded-For", "value": "54.239.98.137" }, { "name": "X-Forwarded-Proto", "value": "https" }, { "name": "X-Forwarded-Port", "value": "443" }, { "name": "Host", "value": "xt7xxx9bhn7.gamma.execute-api.us-east-1.amazonaws.com" }, { "name": "X-Amzn-Trace-Id", "value": "Root=1-67a288c4-27acb3cd5795dd8456b7e3c3" }, { "name": "Accept-Encoding", "value": "gzip" }, { "name": "User-Agent", "value": "okhttp/3.12.1" }], "uri": "/CanaryTest", "args": "hoppy=REDACTED&yellow=hello&x-hoppy-extra=generic-%3Cwords%3E-in-angle-brackets", "httpVersion": "HTTP/1.1", "httpMethod": "GET", "requestId": "FepO0F8fIAMEqoQ=" }, "labels": [{ "name": "awswaf:forwardedip:geo:country:US" }, { "name": "awswaf:forwardedip:geo:region:US-VA" }] } ``` ## RuleMatchDetails でのデータの保持 Webacl 設定 ``` "data_protection_config": { "data_protections": [ { "field": { "field_type": "SINGLE_HEADER", "field_keys": [ "hoppy" ] }, "action": "HASH", "exclude_rule_match_details": true, "exclude_rate_based_details": false } ] } ``` RuleMatchDetails でデータを保持する例: 単一の `Header`「hoppy」が保護されているが、値は `RuleMatchDetails` でのみ保持されるログエントリ。 ``` { "timestamp": 1738705092889, "formatVersion": 1, "webaclId": "arn:aws:wafv2:us-east-1:111122223333:regional/webacl/DataProtectionhashACL/4eede063-e611-44f5-b357-ffc9d7b7fed5", "terminatingRuleId": "Default_Action", "terminatingRuleType": "REGULAR", "action": "ALLOW", "terminatingRuleMatchDetails": [], "httpSourceName": "APIGW", "httpSourceId": "746533260405:xt7v59bhn7:ABC", "ruleGroupList": [], "rateBasedRuleList": [], "nonTerminatingMatchingRules": [{ "ruleId": "ProtectedSQLIHeadersVisibleInSTM", "action": "COUNT", "ruleMatchDetails": [{ "conditionType": "SQL_INJECTION", "sensitivityLevel": "HIGH", "location": "HEADER", "matchedData": [ "10", "AND", "1" ], "matchedFieldName": "hoppy" }] }], "requestHeadersInserted": null, "responseCodeSent": null, "httpRequest": { "clientIp": "54.239.98.137", "country": "US", "headers": [{ "name": "X-Forwarded-For", "value": "54.239.98.137" }, { "name": "X-Forwarded-Proto", "value": "https" }, { "name": "X-Forwarded-Port", "value": "443" }, { "name": "Host", "value": "xt7xxx9bhn7.gamma.execute-api.us-east-1.amazonaws.com" }, { "name": "X-Amzn-Trace-Id", "value": "Root=1-67a288c4-27acb3cd5795dd8456b7e3c3" }, { "name": "hoppy", "value": "zuomr2mxQxofg6EI6f7hMNGaJhhPxt0rFVAXog6FLxE=" }, { "name": "Accept-Encoding", "value": "gzip" }, { "name": "User-Agent", "value": "okhttp/3.12.1" }, { "name": "hoppy", "value": "z6hpYAFaMYdtiTeHhxnN5ydgRE5E1WgyVIdgqH0D3iM=" }], "uri": "/CanaryTest", "args": "happy=true", "httpVersion": "HTTP/1.1", "httpMethod": "GET", "requestId": "FepO0F8fIAMEqoQ=" }, "labels": [{ "name": "awswaf:forwardedip:geo:country:US" }, { "name": "awswaf:forwardedip:geo:region:US-VA" }] } ``` ## rateBasedRule でのデータの保持 ``` "data_protection_config": { "data_protections": [ { "field": { "field_type": "SINGLE_HEADER", "field_keys": [ "hoppy" ] }, "action": "HASH", "exclude_rule_match_details": false, "exclude_rate_based_details": true } ] } ``` rateBasedRuleList でのデータの保持例: 単一の `Header`「hoppy」が保護されているが、値は `rateBasedRuleList` でのみ保持されるログエントリ ``` { "timestamp": 1683355579981, "formatVersion": 1, "webaclId": ..., "terminatingRuleId": "RateBasedRule", "terminatingRuleType": "RATE_BASED", "action": "BLOCK", "terminatingRuleMatchDetails": [], "httpSourceName": "APIGW", "httpSourceId": "EXAMPLE11:rjvegx5guh:CanaryTest", "ruleGroupList": [], "rateBasedRuleList": [{ "rateBasedRuleId": ..., "rateBasedRuleName": "RateBasedRule", "limitKey": "CUSTOMKEYS", "maxRateAllowed": 100, "evaluationWindowSec": "120", "customValues": [{ "key": "HEADER", "name": "hoppy", "value": "ella" }] }], "nonTerminatingMatchingRules": [], "requestHeadersInserted": null, "responseCodeSent": null, "httpRequest": { "clientIp": "52.46.82.45", "country": "FR", "headers": [{ "name": "X-Forwarded-For", "value": "52.46.82.45" }, { "name": "X-Forwarded-Proto", "value": "https" }, { "name": "X-Forwarded-Port", "value": "443" }, { "name": "Host", "value": "rjvegx5guh.execute-api.eu-west-3.amazonaws.com" }, { "name": "X-Amzn-Trace-Id", "value": "Root=1-645566cf-7cb058b04d9bb3ee01dc4036" }, { "name": "hoppy", "value": "zuomr2mxQxofg6EI6f7hMNGaJhhPxt0rFVAXog6FLxE=" }, { "name": "User-Agent", "value": "RateBasedRuleTestKoipOneKeyModulePV2" }, { "name": "Accept-Encoding", "value": "gzip,deflate" }], "uri": "/CanaryTest", "args": "", "httpVersion": "HTTP/1.1", "httpMethod": "GET", "requestId": "Ed0AiHF_CGYF-DA=" } } ``` ## 本文のデータ保護 AWS WAF の本文のサブセットのみをログに記録します`RuleMatchDetails`。 Webacl 設定 ``` "data_protection_config": { "data_protections": [ { "field": { "field_type": "BODY" }, "action": "SUBSTITUTE", "exclude_rule_match_details": false, "exclude_rate_based_details": false } ] } ``` 本文の DataProtection の例: 本文が `ruleMatchDetails` にサブセットされたログエントリ。 ``` { "timestamp": 1738705092889, "formatVersion": 1, "webaclId": "arn:aws:wafv2:us-east-1:111122223333:regional/webacl/DataProtectionhashACL/4eede063-e611-44f5-b357-ffc9d7b7fed5", "terminatingRuleId": "Default_Action", "terminatingRuleType": "REGULAR", "action": "ALLOW", "terminatingRuleMatchDetails": [], "httpSourceName": "APIGW", "httpSourceId": "746533260405:xt7v59bhn7:ABC", "ruleGroupList": [], "rateBasedRuleList": [], "nonTerminatingMatchingRules": [{ "ruleId": "ProtectedSQLIBody", "action": "COUNT", "ruleMatchDetails": [{ "conditionType": "SQL_INJECTION", "sensitivityLevel": "HIGH", "location": "BODY", "matchedData": ["REDACTED"] }] }], "requestHeadersInserted": null, "responseCodeSent": null, "httpRequest": { "clientIp": "54.239.98.137", "country": "US", "headers": [{ "name": "X-Forwarded-For", "value": "54.239.98.137" }, { "name": "X-Forwarded-Proto", "value": "https" }, { "name": "X-Forwarded-Port", "value": "443" }, { "name": "Host", "value": "xt7xxx9bhn7.gamma.execute-api.us-east-1.amazonaws.com" }, { "name": "X-Amzn-Trace-Id", "value": "Root=1-67a288c4-27acb3cd5795dd8456b7e3c3" }, { "name": "Accept-Encoding", "value": "gzip" }, { "name": "User-Agent", "value": "okhttp/3.12.1" }, { "name": "cookie", "value": "hoppy=dog;" }], "uri": "/CanaryTest", "args": "baloo=abc&hoppy-query=xyz&x-hoppy-extra=generic-%3Cwords%3E-in-angle-brackets", "httpVersion": "HTTP/1.1", "httpMethod": "GET", "requestId": "FepO0F8fIAMEqoQ=" }, "labels": [{ "name": "awswaf:forwardedip:geo:country:US" }, { "name": "awswaf:forwardedip:geo:region:US-VA" }] } ``` ## `SINGLE_COOKIE` のデータ保護 Webacl 設定 ``` "data_protection_config": { "data_protections": [ { "field": { "field_type": "SINGLE_COOKIE", "field_keys": [ "MILO" ] }, "action": "HASH", "exclude_rule_match_details": false, "exclude_rate_based_details": false } ] } ``` `SINGLE_COOKIE` の DataProtection の例: 保護された「MILO」という名前の `SINGLE_COOKIE` ログエントリ。完全なログには、MILO という名前の Cookie が `ruleMatchDetails` で保護され、Cookie ヘッダーが表示されます。Cookie 値のみが保護され、キー名は除外されます。 **注記** すべての保護されたフィールド (単一ヘッダー、Cookie、クエリ引数) では、大文字と小文字は区別されません。したがって、この例では、「MILO」は「milo」と一致します。 ``` { "timestamp": 1738705092889, "formatVersion": 1, "webaclId": "arn:aws:wafv2:us-east-1:111122223333:regional/webacl/DataProtectionhashACL/4eede063-e611-44f5-b357-ffc9d7b7fed5", "terminatingRuleId": "Default_Action", "terminatingRuleType": "REGULAR", "action": "ALLOW", "terminatingRuleMatchDetails": [], "httpSourceName": "APIGW", "httpSourceId": "746533260405:xt7v59bhn7:ABC", "ruleGroupList": [], "rateBasedRuleList": [], "nonTerminatingMatchingRules": [{ "ruleId": "ProtectedSQLIHeadersVisibleInSTM", "action": "COUNT", "ruleMatchDetails": [{ "conditionType": "SQL_INJECTION", "sensitivityLevel": "HIGH", "location": "COOKIE", "matchedData": ["zuomr2mxQxofg6EI6f7hMNGaJhhPxt0rFVAXog6FLxE="], "matchedFieldName": "milo" }] }], "requestHeadersInserted": null, "responseCodeSent": null, "httpRequest": { "clientIp": "54.239.98.137", "country": "US", "headers": [{ "name": "X-Forwarded-For", "value": "54.239.98.137" }, { "name": "X-Forwarded-Proto", "value": "https" }, { "name": "X-Forwarded-Port", "value": "443" }, { "name": "Host", "value": "xt7xxx9bhn7.gamma.execute-api.us-east-1.amazonaws.com" }, { "name": "X-Amzn-Trace-Id", "value": "Root=1-67a288c4-27acb3cd5795dd8456b7e3c3" }, { "name": "Accept-Encoding", "value": "gzip" }, { "name": "User-Agent", "value": "okhttp/3.12.1" }, { "name": "cookie", "value": "hoppy=dog;milo=zuomr2mxQxofg6EI6f7hMNGaJhhPxt0rFVAXog6FLxE=;aws-waf-token=51c71352-41f5-4f6d-b676-c24907bdf819:EQoAZ/J+AAQAAAAA:t9wvxbw042wva7E2Y6lgud/bS6YG0CJKVAJqaRqDZ140ythKW0Zj9wKB2O8lSkYDRqf1yONcVBFo5u0eYi0tvT4rtQCXsu+KanAardW8go4QSLw4yoED59lgV7oAhGyCalAzE7ra29j+RvvZPsQyoQuDCrtoY/TvQyMTXIXzGPDC/rKBbg==" }], "uri": "/CanaryTest", "args": "baloo=abc&hoppy-query=xyz&x-hoppy-extra=generic-%3Cwords%3E-in-angle-brackets", "httpVersion": "HTTP/1.1", "httpMethod": "GET", "requestId": "FepO0F8fIAMEqoQ=" }, "labels": [{ "name": "awswaf:forwardedip:geo:country:US" }, { "name": "awswaf:forwardedip:geo:region:US-VA" }] } ``` ## すべての Cookie のデータ保護 `SINGLE_HEADER` を使用して Cookie のデータ保護を設定できます。Cookie 値のみが保護され、キー名は除外されます。 ``` "DataProtectionConfig": { "DataProtections": [ { "Field": { "FieldType": "SINGLE_HEADER", "FieldKeys": ["cookie"] }, "Action": "SUBSTITUTION", "ExcludeRuleMatchDetails": false, "ExcludeRateBasedDetails": false } ] } ``` `header `「COOKIE」の DataProtection の例: Cookie ヘッダーが保護されたログエントリ。 **注記** Cookie 名 `AWS-WAF-TOKEN` はデータ保護の対象外です。 ``` { "timestamp": 1738705092889, "formatVersion": 1, "webaclId": "arn:aws:wafv2:us-east-1:111122223333:regional/webacl/DataProtectionhashACL/4eede063-e611-44f5-b357-ffc9d7b7fed5", "terminatingRuleId": "Default_Action", "terminatingRuleType": "REGULAR", "action": "ALLOW", "terminatingRuleMatchDetails": [], "httpSourceName": "APIGW", "httpSourceId": "746533260405:xt7v59bhn7:ABC", "ruleGroupList": [], "rateBasedRuleList": [], "nonTerminatingMatchingRules": [], "requestHeadersInserted": null, "responseCodeSent": null, "httpRequest": { "clientIp": "54.239.98.137", "country": "US", "headers": [{ "name": "X-Forwarded-For", "value": "54.239.98.137" }, { "name": "X-Forwarded-Proto", "value": "https" }, { "name": "X-Forwarded-Port", "value": "443" }, { "name": "Host", "value": "xt7xxx9bhn7.gamma.execute-api.us-east-1.amazonaws.com" }, { "name": "X-Amzn-Trace-Id", "value": "Root=1-67a288c4-27acb3cd5795dd8456b7e3c3" }, { "name": "Accept-Encoding", "value": "gzip" }, { "name": "User-Agent", "value": "okhttp/3.12.1" }, { "name": "cookie", "value": "hoppy=REDACTED;milo=REDACTED;aws-waf-token=51c71352-41f5-4f6d-b676-c24907bdf819:EQoAZ/J+AAQAAAAA:t9wvxbw042wva7E2Y6lgud/bS6YG0CJKVAJqaRqDZ140ythKW0Zj9wKB2O8lSkYDRqf1yONcVBFo5u0eYi0tvT4rtQCXsu+KanAardW8go4QSLw4yoED59lgV7oAhGyCalAzE7ra29j+RvvZPsQyoQuDCrtoY/TvQyMTXIXzGPDC/rKBbg==" }], "uri": "/CanaryTest", "args": "baloo=xyz=&hoppy-query=abc&x-hoppy-extra=abc", "httpVersion": "HTTP/1.1", "httpMethod": "GET", "requestId": "FepO0F8fIAMEqoQ=" }, "labels": [{ "name": "awswaf:forwardedip:geo:country:US" }, { "name": "awswaf:forwardedip:geo:region:US-VA" }] } ``` ## 単一クエリ引数のデータ保護 `SINGLE_QUERY_ARGUMENT` を使用して、クエリ文字列のデータ保護を設定できます。これは、すべてのクエリ引数のキーと値に影響します。次の例では、元のクエリ文字列は `baloo=10 AND 1=1&hoppy=10 AND 1=1&x-hoppy-extra=generic-%3Cwords` でした。 Webacl 設定 ``` "DataProtectionConfig": { "DataProtections": [ { "Field": { "FieldType": "SINGLE_QUERY_ARGUMENT", "FieldKeys": ["hoppy"] }, "Action": "SUBSTITUTION", "ExcludeRuleMatchDetails": false, "ExcludeRateBasedDetails": false } ] } ``` `SINGLE_QUERY_ARGUEMENT` の DataProtection の例: 置換で保護された「hoppy」クエリ文字列を含むログエントリ。 ``` { "timestamp": 1738705092889, "formatVersion": 1, "webaclId": "arn:aws:wafv2:us-east-1:111122223333:regional/webacl/DataProtectionSubstituteQueryString/4eede063-e611-44f5-b357-ffc9d7b7fed5", "terminatingRuleId": "Default_Action", "terminatingRuleType": "REGULAR", "action": "ALLOW", "terminatingRuleMatchDetails": [], "httpSourceName": "APIGW", "httpSourceId": "746533260405:xt7v59bhn7:ABC", "ruleGroupList": [], "rateBasedRuleList": [], "nonTerminatingMatchingRules": [ { "ruleId": "ProtectedHoppyQueryArg", "action": "COUNT", "ruleMatchDetails": [ { "conditionType": "SQL_INJECTION", "sensitivityLevel": "HIGH", "location": "SINGLE_QUERY_ARG", "matchedData": ["REDACTED"], "matchedFieldName": "hoppy" }] }, { "ruleId": "FullQueryStringInspectionWhichDetectsTheFirstFieldWithSQLi_Baloo_IsAlsoMaskedMasked", "action": "COUNT", "ruleMatchDetails": [ { "conditionType": "SQL_INJECTION", "sensitivityLevel": "HIGH", "location": "QUERY_ARGS", "matchedData": ["REDACTED"], }] }, { "ruleId": "ProtectedBalooQueryArg", "action": "COUNT", "ruleMatchDetails": [ { "conditionType": "SQL_INJECTION", "sensitivityLevel": "HIGH", "location": "SINGLE_QUERY_ARG", "matchedData": [ "10", "AND", "1" ], "matchedFieldName": "baloo" }] } ], "requestHeadersInserted": null, "responseCodeSent": null, "httpRequest": { "clientIp": "54.239.98.137", "country": "US", "headers": [{ "name": "X-Forwarded-For", "value": "54.239.98.137" }, { "name": "X-Forwarded-Proto", "value": "https" }, { "name": "X-Forwarded-Port", "value": "443" }, { "name": "Host", "value": "xt7xxx9bhn7.gamma.execute-api.us-east-1.amazonaws.com" }, { "name": "X-Amzn-Trace-Id", "value": "Root=1-67a288c4-27acb3cd5795dd8456b7e3c3" }, { "name": "Accept-Encoding", "value": "gzip" }, { "name": "User-Agent", "value": "okhttp/3.12.1" }], "uri": "/CanaryTest", "args": "baloo=10 AND 1=1&hoppy=REDACTED&x-hoppy-extra=generic-%3Cwords", "httpVersion": "HTTP/1.1", "httpMethod": "GET", "requestId": "FepO0F8fIAMEqoQ=" }, "labels": [{ "name": "awswaf:forwardedip:geo:country:US" }, { "name": "awswaf:forwardedip:geo:region:US-VA" }] } ``` ## クエリ文字列のデータ保護 `QUERY_STRING` を使用して、クエリ文字列のデータ保護を設定できます。これは、すべてのクエリ引数のキーと値に影響します。次の例では、元のクエリ文字列は `baloo=10 AND 1=1&hoppy-query=10 AND 1=1&x-hoppy-extra=generic-%3Cwords` でした。 Webacl 設定 ``` "DataProtectionConfig": { "DataProtections": [ { "Field": { "FieldType": "QUERY_STRING" }, "Action": "SUBSTITUTION", "ExcludeRuleMatchDetails": false, "ExcludeRateBasedDetails": false } ] } ``` `QUERY_STRING` の DataProtection の例: 置換で保護されたクエリ文字列を含むログエントリ。 ``` { "timestamp": 1738705092889, "formatVersion": 1, "webaclId": "arn:aws:wafv2:us-east-1:111122223333:regional/webacl/DataProtectionSubstituteQueryString/4eede063-e611-44f5-b357-ffc9d7b7fed5", "terminatingRuleId": "Default_Action", "terminatingRuleType": "REGULAR", "action": "ALLOW", "terminatingRuleMatchDetails": [], "httpSourceName": "APIGW", "httpSourceId": "746533260405:xt7v59bhn7:ABC", "ruleGroupList": [], "rateBasedRuleList": [], "nonTerminatingMatchingRules": [ { "ruleId": "ProtectedHoppyQueryArg", "action": "COUNT", "ruleMatchDetails": [ { "conditionType": "SQL_INJECTION", "sensitivityLevel": "HIGH", "location": "QUERY_STRING", "matchedData": ["REDACTED"] }] }, { "ruleId": "ProtectedBalooQueryArg", "action": "COUNT", "ruleMatchDetails": [ { "conditionType": "SQL_INJECTION", "sensitivityLevel": "HIGH", "location": "SINGLE_QUERY_ARG", "matchedData": [ "REDACTED" ], "matchedFieldName": "REDACTED" }] } ], "requestHeadersInserted": null, "responseCodeSent": null, "httpRequest": { "clientIp": "54.239.98.137", "country": "US", "headers": [{ "name": "X-Forwarded-For", "value": "54.239.98.137" }, { "name": "X-Forwarded-Proto", "value": "https" }, { "name": "X-Forwarded-Port", "value": "443" }, { "name": "Host", "value": "xt7xxx9bhn7.gamma.execute-api.us-east-1.amazonaws.com" }, { "name": "X-Amzn-Trace-Id", "value": "Root=1-67a288c4-27acb3cd5795dd8456b7e3c3" }, { "name": "Accept-Encoding", "value": "gzip" }, { "name": "User-Agent", "value": "okhttp/3.12.1" }], "uri": "/CanaryTest", "args": "REDACTED", "httpVersion": "HTTP/1.1", "httpMethod": "GET", "requestId": "FepO0F8fIAMEqoQ=" }, "labels": [{ "name": "awswaf:forwardedip:geo:country:US" }, { "name": "awswaf:forwardedip:geo:region:US-VA" }] } ``` ## 複数のクエリ引数のデータ保護 `SINGLE_QUERY_ARGUMENT` を使用して、個々のクエリ引数のデータ保護を設定できます。ローカル情報を報告する際は、ローカル保護を使用します。ただし、クエリ文字列と Cookie ヘッダーで一致した文字列には、適用される可能性のある多くの保護設定があります。簡素化するために、`RuleMatchDetails` の最も厳密な保護が適用されます。これは、一致した特定のデータ範囲と重複していない場合でも適用されます。次の例では、元のクエリ文字列は `baloo=is_a_good_boy&hoppy=likes_to_sleep&x-hoppy-extra=10 AND 1=1` でした。 ``` "DataProtectionConfig": { "DataProtections": [ { "Field": { "FieldType": "SINGLE_QUERY_ARGUMENT", "FieldKeys": ["hoppy"] }, "Action": "SUBSTITUTION", "ExcludeRuleMatchDetails": false, "ExcludeRateBasedDetails": false }, { "Field": { "FieldType": "SINGLE_QUERY_ARGUMENT", "FieldKeys": ["baloo"] }, "Action": "HASH", "ExcludeRuleMatchDetails": false, "ExcludeRateBasedDetails": false } ] } ``` 複数のクエリ引数の DataProtection の例。 ``` { "timestamp": 1738705092889, "formatVersion": 1, "webaclId": "arn:aws:wafv2:us-east-1:111122223333:regional/webacl/DataProtectionSubstituteQueryString/4eede063-e611-44f5-b357-ffc9d7b7fed5", "terminatingRuleId": "Default_Action", "terminatingRuleType": "REGULAR", "action": "ALLOW", "terminatingRuleMatchDetails": [], "httpSourceName": "APIGW", "httpSourceId": "746533260405:xt7v59bhn7:ABC", "ruleGroupList": [], "rateBasedRuleList": [], "nonTerminatingMatchingRules": [ { "ruleId": "ProtectedHoppyQueryArg", "action": "COUNT", "ruleMatchDetails": [ { "conditionType": "SQL_INJECTION", "sensitivityLevel": "HIGH", "location": "SINGLE_QUERY_ARG", "matchedData": ["REDACTED"], "matchedFieldName": "hoppy" }] }, { "ruleId": "ProtectedBalooQueryArg", "action": "COUNT", "ruleMatchDetails": [ { "conditionType": "SQL_INJECTION", "sensitivityLevel": "HIGH", "location": "SINGLE_QUERY_ARG", "matchedData": ["zuomr2mxQxofg6EI6f7hMNGaJhhPxt0rFVAXog6FLxE="], "matchedFieldName": "baloo" }] }, { "ruleId": "FullQueryStringDetects_x-hoppy-extra_IsSubstituted", "action": "COUNT", "ruleMatchDetails": [ { "conditionType": "SQL_INJECTION", "sensitivityLevel": "HIGH", "location": "QUERY_ARGS", "matchedData": ["REDACTED"], // Harshest of Protection Config }] } ], "requestHeadersInserted": null, "responseCodeSent": null, "httpRequest": { "clientIp": "54.239.98.137", "country": "US", "headers": [{ "name": "X-Forwarded-For", "value": "54.239.98.137" }, { "name": "X-Forwarded-Proto", "value": "https" }, { "name": "X-Forwarded-Port", "value": "443" }, { "name": "Host", "value": "xt7xxx9bhn7.gamma.execute-api.us-east-1.amazonaws.com" }, { "name": "X-Amzn-Trace-Id", "value": "Root=1-67a288c4-27acb3cd5795dd8456b7e3c3" }, { "name": "Accept-Encoding", "value": "gzip" }, { "name": "User-Agent", "value": "okhttp/3.12.1" }], "uri": "/CanaryTest", "args": "baloo=zuomr2mxQxofg6EI6f7hMNGaJhhPxt0rFVAXog6FLxE=&hoppy=REDACTED&x-hoppy-extra=10 AND 1=1", "httpVersion": "HTTP/1.1", "httpMethod": "GET", "requestId": "FepO0F8fIAMEqoQ=" }, "labels": [{ "name": "awswaf:forwardedip:geo:country:US" }, { "name": "awswaf:forwardedip:geo:region:US-VA" }] } ``` **注記** 同じウェブ ACL で **QueryString マスキング** と **シングルクエリ配列マスキング** の両方を指定することはできません。 # 保護パック (ウェブ ACL) のデータ保護の設定このセクションでは、保護パック (ウェブ ACL) のデータ保護を設定する手順について説明します。 **保護パック (ウェブ ACL) のデータ保護を設定するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで、**[保護パック (ウェブ ACL)]** を選択します。 1. データ保護を有効にする保護パック (ウェブ ACL) の名前を選択します。コンソールで保護パック (ウェブ ACL) の説明が表示され、そこで編集できます。 1. **[ログ記録とメトリクス]** タブの **[データ保護設定]** ペインで、**[有効化]** または **[編集]** を選択します。 1. 範囲 **[グローバル]** を選択し、フィールドデータ保護選択を行います。フィールドデータ保護設定ごとに、保護動作から除外する例外を指定することもできます。 1. 選択が完了したら、**[保存]** を選択します。インターフェイスは、選択内容が要約されている **ログ記録とメトリクス** タブに戻ります。 # AWS WAF 保護のテストとチューニングこのセクションでは、 AWS WAF 保護パック (ウェブ ACLs)、ルール、ルールグループ、IP セット、正規表現パターンセットをテストおよびチューニングするためのガイダンスを提供します。ウェブサイトまたはウェブアプリケーショントラフィックに適用する前に、 AWS WAF 保護パック (ウェブ ACL) の変更をテストして調整することをお勧めします。 **本番稼働トラフィックのリスク** 本番稼働トラフィックに保護パック (ウェブ ACL) 実装をデプロイする前に、トラフィックへの潜在的な影響に慣れるまで、ステージング環境またはテスト環境でテストおよびチューニングします。その後、ルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。また、このセクションでは、他のユーザーによって管理されているルールグループの使用をテストするための一般的なガイダンスも提供します。これには、 AWS マネージドルールルールグループ、 AWS Marketplace マネージドルールグループ、および別のアカウントによって共有されるルールグループが含まれます。これらのルールグループについては、ルールグループプロバイダーから取得したガイダンスにも従ってください。 + Bot Control AWS マネージドルールのルールグループについては、「」も参照してください[AWS WAF Bot Control のテストとデプロイ](waf-bot-control-deploying.md)。 + アカウント乗っ取り防止 AWS マネージドルールのルールグループについては、「」も参照してください[ATP のテストとデプロイ](waf-atp-deploying.md)。 + アカウント作成の不正防止 AWS マネージドルールのルールグループについては、「」も参照してください[ACFP のテストとデプロイ](waf-acfp-deploying.md)。 **更新中の一時的な不一致** 保護パック (ウェブ ACL) または他の AWS WAF リソースを作成または変更すると、リソースが保存されているすべての領域にその変更が反映されるまでに少し時間がかかります。伝播時間は、数秒から数分までかかります。次の内容では、変更伝播中に直面する一時的な不整合性の例を紹介します。 + 保護パック (ウェブ ACL) を作成した後、それをリソースに関連付けようとすると、保護パック (ウェブ ACL) が利用できないことを示す例外が表示される場合があります。 + ルールグループを保護パック (ウェブ ACL) に追加した後、新しいルールグループのルールは、保護パック (ウェブ ACL) が使用されるエリアで有効になり、別のエリアでは有効にならない場合があります。 + ルールのアクション設定を変更した後、古いアクションを一部のエリアで確認され、新しいアクションを別のエリアで確認される場合があります。 + ブロックルールで使用されている IP セットに IP アドレスを追加した後、新しいアドレスはあるエリアではブロックされ、別のエリアでは許可される場合があります。 # ハイレベルステップのテストとチューニングこのセクションでは、ウェブ ACL が使用するルールまたはルールグループなど、ウェブ ACL に対する変更をテストするための手順のチェックリストを示します。 **注記** このセクションのガイダンスに従うには、保護パック (ウェブ ACL)、ルール、ルールグループなどの AWS WAF 保護の作成および管理方法を理解する必要があります。この情報は、このガイドの前のセクションで説明しています。 **保護パック (ウェブ ACL) をテストおよび調整するには** これらのステップを最初にテスト環境で実行し、次に本番環境で実行します。 1. **テストの準備** モニタリング環境を準備し、新しい AWS WAF 保護をテスト用のカウントモードに切り替え、必要なリソースの関連付けを作成します。「[AWS WAF 保護のテストの準備](web-acl-testing-prep.md)」を参照してください。 1. **テスト環境および本番環境での監視とチューニング** 最初にテスト環境またはステージング環境で、次に本番環境で、必要に応じてトラフィックを処理できることを確認するまで、 AWS WAF 保護を監視および調整します。「[AWS WAF 保護のモニタリングと調整](web-acl-testing-activities.md)」を参照してください。 1. **本番環境で保護を有効にする** テスト保護に納得できたら、それらを本番モードに切り替え、不要なテストアーティファクトをクリーンアップして、監視を続行します。「[本番環境で保護の有効化](web-acl-testing-enable-production.md)」を参照してください。変更の実装が完了したら、本番環境でウェブトラフィックと保護を監視し、必要に応じて動作していることを確認します。Web トラフィックパターンは時間の経過とともに変化することがあるため、時々保護を調整する必要がある場合があります。 # AWS WAF 保護のテストの準備このセクションでは、をセットアップして AWS WAF 保護をテストおよび調整する方法について説明します。 **注記** このセクションのガイダンスに従うには、 AWS WAF 保護パック (ウェブ ACLs)、ルール、ルールグループなどの保護を作成および管理する方法を一般的に理解する必要があります。この情報は、このガイドの前のセクションで説明しています。 **テストを準備するには** 1. **保護パック (ウェブ ACL) のログ記録、Amazon CloudWatch メトリクス、および保護パック (ウェブ ACL) のウェブリクエストサンプリングを有効にする** ログ記録、メトリクス、およびサンプリングを使用して、保護パック (ウェブ ACL) ルールとウェブトラフィックとの相互作用を監視します。 + **ログ記録** – 保護パック (ウェブ ACL) が評価するウェブリクエストをログ AWS WAF に記録するようにを設定できます。ログを、CloudWatch ログ、Amazon S3 バケット、または Amazon Data Firehose 配信ストリームに送信できます。フィールドの修正やフィルタリングの適用も可能です。詳細については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。 + **Amazon Security Lake** – Security Lake を設定して、保護パック (ウェブ ACL) データを収集できます。Security Lake は、正規化、分析、管理のためにさまざまなソースからログとイベントデータを収集します。このオプションの詳細については、[「Amazon Security Lake ユーザーガイド」の「Amazon Security Lake とは](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html)[」および「 AWS のサービスからデータを収集](https://docs.aws.amazon.com/security-lake/latest/userguide/internal-sources.html)する」を参照してください。 ** + **Amazon CloudWatch メトリクス** — 保護パック (ウェブ ACL) 設定で、監視するすべてのメトリック仕様を指定します。および AWS WAF CloudWatch コンソールを使用してメトリクスを表示できます。詳細については、「[Amazon CloudWatch によるモニタリング](monitoring-cloudwatch.md)」を参照してください。 + **ウェブリクエストサンプリング** — 保護パック (ウェブ ACL) が評価するすべてのウェブリクエストのサンプルを表示できます。ウェブリクエストサンプリングの詳細については、「[ウェブリクエストのサンプルの表示](web-acl-testing-view-sample.md)」を参照してください。 1. **保護を Count モードに設定します。** 保護パック (ウェブ ACL) 設定で、テストするものをカウントモードに切り替えます。これにより、テスト保護は、リクエストの処理方法を変更することなく、ウェブリクエストに対する一致を記録します。メトリクス、ログ、およびサンプリングされたリクエストで一致を確認し、一致条件を検証し、ウェブトラフィックにどのような影響があるかを理解することができます。一致するリクエストにラベルを追加するルールは、ルールのアクションに関係なくラベルを追加します。 + **保護パック (ウェブ ACL) で定義されているルール** — 保護パック (ウェブ ACL) のルールを編集し、アクションを Count に設定します。 + **ルールグループ** — 保護パック (ウェブ ACL) 設定で、ルールグループのルールステートメントを編集し、**[Rules]** (ルール) ペインで **[Override all rule actions]** (すべてのルールアクションをオーバーライド) ドロップダウンを開いて **[Count]** 選択します。JSON で保護パック (ウェブ ACL) を管理する場合、ルールグループ参照ステートメントで `RuleActionOverrides` 設定にリールを追加し、`ActionToUse` を Count に設定します。次のリスト例は、`AWSManagedRulesAnonymousIpList` AWS マネージドルールルールグループの 2 つのルールのオーバーライドを示しています。 ``` "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesAnonymousIpList", "RuleActionOverrides": [ { "ActionToUse": { "Count": {} }, "Name": "AnonymousIPList" }, { "ActionToUse": { "Count": {} }, "Name": "HostingProviderIPList" } ], "ExcludedRules": [] } }, ``` ルールアクションのオーバーライドの詳細については、「[ルールグループ内のルールアクションのオーバーライド](web-acl-rule-group-settings.md#web-acl-rule-group-rule-action-override)」を参照してください。独自のルールグループについては、ルールグループ自体のルールアクションを変更しないでください。ルールグループルールCountアクションは、テストに必要なメトリクスやその他のアーティファクトを生成しません。さらに、ルールグループを変更すると、それを使用するすべての保護パック (ウェブ ACL) に影響しますが、保護パック (ウェブ ACL) 設定内の変更は単一の保護パック (ウェブ ACL) にのみ影響します。 + **保護パック (ウェブ ACL)** — 新しい保護パック (ウェブ ACL) をテストする場合は、リクエストを許可する保護パック (ウェブ ACL) のデフォルトのアクションを設定します。これにより、トラフィックに影響を与えずにウェブ ACL を試すことができます。一般的に、カウントモードは本番稼働よりも多くの一致が生成されます。これは、リクエストをカウントするルールが保護パック (ウェブ ACL) によるリクエストの評価を停止しないため、保護パック (ウェブ ACL) で後で実行されるルールもリクエストと一致する場合があるためです。ルールアクションを本番設定に変更すると、リクエストを許可またはブロックするルールは、一致するリクエストの評価を終了します。その結果、一致するリクエストは通常、保護パック (ウェブ ACL) 内のより少ないルールで検査されます。ウェブリクエストの全体的な評価に対するルールアクションの影響の詳細については、「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」を参照してください。。これらの設定を使用すると、新しい保護によってウェブトラフィックは変更されませんが、メトリクス、保護パック (ウェブ ACL) ログ、およびリクエストサンプルで一致情報が生成されます。 1. **保護パック (ウェブ ACL) をリソースに関連付ける** 保護パック (ウェブ ACL) がリソースに関連付けられていない場合は、関連付けます。「[AWS リソースとの保護の関連付けまたは関連付け解除](web-acl-associating-aws-resource.md)」を参照してください。これで、保護パック (ウェブ ACL) を監視してチューニングする準備ができました。 # AWS WAF 保護のモニタリングと調整 AWS WAF 保護を監視および調整します。 **注記** このセクションのガイダンスに従うには、 AWS WAF 保護パック (ウェブ ACLs)、ルール、ルールグループなどの保護を作成および管理する方法を一般的に理解する必要があります。この情報は、このガイドの前のセクションで説明しています。ウェブトラフィックとルールの一致をモニタリングして、保護パック (ウェブ ACL) の動作を確認します。問題が見つかった場合は、ルールを調整して修正し、モニタリングして調整を確認します。保護パック (ウェブ ACL) が必要に応じてウェブトラフィックを管理するまで、次の手順を繰り返します。 **モニタリングおよびチューニング** 1. **トラフィックとルールの一致をモニタリングする** トラフィックがフローしていることと、テストルールで一致するリクエストが検出されていることを確認します。テストしている保護については、次の情報を参照してください。 + **ログ** — 以下はウェブリクエストに一致するルールに関するアクセス情報です。 + **ルール** - Count アクションがある保護パック (ウェブ ACL) のルールは、`nonTerminatingMatchingRules` にリストされます。Allow または Block を持つルールは、`terminatingRule` として一覧表示されます。CAPTCHA または Challenge を持つルールは、終了する場合と終了しない場合があり、そのためにルール一致の結果に応じて、2 つのカテゴリのいずれかに一覧表示されます。 + **ルールグループ** - ルールグループは `ruleGroupId` フィールドで識別され、そのルールに一致するルールはスタンドアロンルールと同様に分類されます。 + **ラベル** - ルールがリクエストに適用したラベルが `Labels` フィールドに一覧表示されます。詳細については、「[保護パック (ウェブ ACL) トラフィックのログフィールド](logging-fields.md)」を参照してください。 + **Amazon CloudWatch メトリクス** – 保護パック (ウェブ ACL) リクエスト評価の次のメトリクスにアクセスできます。 + **ルール** – メトリクスはルールアクションによってグループ化されます。例えば、Count モードでルールをテストする場合、一致したルールが保護パック (ウェブ ACL) の `Count` メトリクスとして一覧表示されます。 + **ルールグループ** – ルールグループのメトリクスは、ルールグループメトリクスの下に一覧表示されます。 + **別のアカウントが所有するルールグループ** – ルールグループメトリクスは、通常、ルールグループの所有者にのみ表示されます。ただし、ルールのルールアクションを上書きすると、そのルールのメトリクスが保護パック (ウェブ ACL) メトリクスの下に一覧表示されます。さらに、ルールグループによって追加されたラベルは、保護パック (ウェブ ACL) メトリクスに一覧表示されます。ルールグループのカウントアクションルールは、ウェブ ACL ディメンションメトリクスを出力しません - Rule、RuleGroup、およびリージョンディメンションのみ。これは、ルールグループがウェブ ACL で参照されている場合でも適用されます。このカテゴリにあるルールグループは [AWS のマネージドルール AWS WAF](aws-managed-rule-groups.md)、[AWS Marketplace ルールグループ](marketplace-rule-groups.md)、[他のサービスによって提供されるルールグループを識別する](waf-service-owned-rule-groups.md)、また、他のアカウントから共有されたルールグループも含まれます。Firewall Manager を介して保護パック (ウェブ ACL) がデプロイされると、カウントアクションを持つ WebACL 内のルールはメンバーアカウントにメトリクスを表示しません。 + **ラベル** – 評価中にウェブリクエストに追加されたラベルは、保護パック (ウェブ ACL) のラベルメトリクスに一覧表示されます。自分のルールやルールグループによって追加されたか、他のアカウントが所有するルールグループのルールによって追加されたかにかかわらず、すべてのラベルのメトリクスにアクセスできます。詳細については、「[ウェブ ACL のメトリクスの表示](web-acl-testing-view-metrics.md)」を参照してください。 + **保護パック (ウェブ ACL) トラフィック概要ダッシュボード** – AWS WAF コンソールで保護パック (ウェブ ACL) のページに移動し、トラフィック**概要タブを開いて、保護パック (ウェブ ACL) が評価したウェブトラフィック**の概要にアクセスします。トラフィック概要ダッシュボードには、アプリケーションのウェブトラフィックを評価するときにが AWS WAF 収集する Amazon CloudWatch メトリクスのほぼリアルタイムの概要が表示されます。詳細については、「[保護パック (ウェブ ACL) のトラフィック概要ダッシュボード](web-acl-dashboards.md)」を参照してください。 + **ウェブリクエストのサンプル** — ウェブリクエストのサンプルと一致するルールのアクセス情報。サンプル情報では、保護パック (ウェブ ACL) 内のルールのメトリクス名で一致するルールを識別します。ルールグループの場合、メトリックはルールグループ参照ステートメントを識別します。ルールグループ内のルールの場合、サンプルは `RuleWithinRuleGroup` の一致ルール名をリストします。詳細については、「[ウェブリクエストのサンプルの表示](web-acl-testing-view-sample.md)」を参照してください。 1. **誤検知に対処するための緩和を構成する** ルールが、本来は一致しないはずのウェブリクエストに一致して、誤検出を発生させていると判断した場合、次のオプションを使用して保護パック (ウェブ ACL) 保護を調整して緩和できます。 **ルールの検査基準の修正** 自分のルールについては、多くの場合、ウェブリクエストを検査するために使用する設定を調整する必要があります。例としては、正規表現パターンセット内の仕様の変更、検査前にリクエストコンポーネントに適用するテキスト変換の調整、転送 IP アドレスへの切り替えなどがあります。「[でのルールステートメントの使用 AWS WAF](waf-rule-statements.md)」にある問題の原因となっているルールタイプのガイダンスを参照してください。 **より複雑な問題の修正** 制御しない検査基準や複雑なルールについては、要求を明示的に許可またはブロックするルールを追加したり、問題のあるルールによる評価から要求を排除したりするなど、その他の変更が必要になることがあります。管理ルールグループでは、通常、このタイプの緩和策が必要ですが、他のルールも可能です。例としては、レートベースのルールステートメントと SQL インジェクション攻撃ルールステートメントなどがあります。誤検出を軽減するために行う方法は、ユースケースによって異なります。一般的なアプローチは以下のとおりです。 + **緩和ルールの追加**：新しいルールの前に実行され、誤検出の原因となっているリクエストを明示的に許可するルールを追加します。ウェブ ACL でのルールの評価順序の詳細については、「[ルールの優先度を設定する](web-acl-processing-order.md)」を参照してください。この方法では、許可されたリクエストは保護されたリソースに送信されるため、評価のために新しいルールに到達することはありません。新しいルールが有料管理ルールグループである場合、このアプローチはルールグループの使用コストを抑えるのにも役立ちます。 + **緩和ルールで論理ルールを追加する**：論理ルールステートメントを使用して、新しいルールと誤検出を除外するルールを組み合わせます。詳細については、「[での論理ルールステートメントの使用 AWS WAF](waf-rule-statements-logical.md)」を参照してください。たとえば、リクエストのカテゴリに対して誤検出を生成する SQL インジェクションアタック match ステートメントを追加するとします。これらの要求に一致するルールを作成し、論理ルールステートメントを使用してルールを組み合わせて、両方が誤検出条件に一致せず、SQL インジェクション攻撃条件に一致するリクエストに対してのみ一致するようにします。 + **スコープダウンステートメントを追加する**：レートベースのステートメントおよび管理ルールグループ参照ステートメントの場合、メインステートメント内にスコープダウンステートメントを追加して、誤検出の原因となるリクエストを評価から除外します。スコープダウンステートメントと一致しないリクエストは、ルールグループまたはレートベースの評価に到達することはありません。スコープダウンステートメントの詳細については、「[でのスコープダウンステートメントの使用 AWS WAF](waf-rule-scope-down-statements.md)」を参照してください。例については、[ボット管理からの IP 範囲を除外する](waf-bot-control-example-scope-down-ip.md)を参照してください。 + **ラベルマッチルールを追加する**— ラベリングを使用するルールグループでは、問題のあるルールがリクエストに適用されているラベルを特定します。ルールグループのルールをまだカウントモードに設定していない場合は、最初にカウントモードに設定する必要がある場合があります。問題のあるルールによって追加されているラベルと一致するラベル一致ルールを、ルールグループの後に実行するように追加します。ラベル一致ルールでは、ブロックするリクエストから許可するリクエストをフィルタリングできます。この方法を使用する場合、テストが終了したら、問題のあるルールをルールグループ内でカウントモードで保持し、カスタムラベルマッチルールをそのまま維持します。ラベル一致ステートメントの詳細については、「[ラベル一致ルールステートメント](waf-rule-statement-type-label-match.md)」を参照してください。例については、「[特定のブロックされたボットを許可する](waf-bot-control-example-allow-blocked-bot.md)」および「[ATP の例: 認証情報の不足および侵害された認証情報のカスタム処理](waf-atp-control-example-user-agent-exception.md)」を参照してください。 + **マネージドルールグループのバージョンの変更**— バージョン対応管理ルールグループの場合、使用しているバージョンを変更します。たとえば、正常に使用していた最後の静的バージョンに戻すことができます。これは通常、一時的な修正です。テスト環境またはステージング環境で最新バージョンのテストを継続している間、またはプロバイダーから互換性が高いバージョンを待っている間に、本番トラフィックのバージョンを変更する場合があるかもしれません。マネージドルールグループの詳細については、「[でのマネージドルールグループの使用 AWS WAF](waf-managed-rule-groups.md)」を参照してください。新しいルールが必要なリクエストと一致していることに納得できたら、テストの次の段階に進み、この手順を繰り返します。テストと調整の最終段階は、本番稼働環境で実行します。 # ウェブ ACL のメトリクスの表示このセクションでは、保護パック (ウェブ ACL) のメトリクスを表示する方法について説明します。保護パック (ウェブ ACL) を 1 つ以上の AWS リソースに関連付けると、関連付けの結果メトリクスを Amazon CloudWatch グラフで表示できます。 AWS WAF メトリクスの詳細については、「」を参照してください[AWS WAF メトリクスとディメンション](waf-metrics.md)。Amazon CloudWatch メトリクスの詳細については、「[Amazon CloudWatch ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)」を参照してください。保護パック (ウェブ ACL) の各ルールと、関連付けられたリソースが保護パック (ウェブ ACL) AWS WAF のに転送するすべてのリクエストについて、CloudWatch では以下を実行できます。 + 1 時間前または 3 時間前のデータを表示する + データポイント間の間隔を変更する + CloudWatch がデータに対して実行する計算 (最大、最小、平均、合計など) を変更する **注記** AWS WAF CloudFront を使用したはグローバルサービスであり、メトリクスはで**米国東部 (バージニア北部)** リージョンを選択した場合にのみ使用できます AWS マネジメントコンソール。別のリージョンを選択した場合、 AWS WAF メトリクスは CloudWatch コンソールに表示されません。 **保護パック (ウェブ ACL) でルールのデータを表示するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) で CloudWatch コンソールを開きます。 1. 必要に応じて、リージョンを AWS リソースがあるリージョンに変更します。CloudFront の場合、米国東部 (バージニア北部) リージョンを選択する必要があります。 1. ナビゲーションペインの **[Metrics]** (メトリクス) で、**[All metrics]** (すべてのメトリクス) を選択し、**[Browse]** (参照) タブで `AWS::WAFV2` メトリクスを検索します。 1. データを表示する保護パック (ウェブ ACL) のチェックボックスをオンにします。 1. 該当する設定を変更します。 **[Statistic] (統計)** CloudWatch がデータに対して実行する計算内容を選択します。 **[Time range] (時間範囲)** 前の 1 時間のデータを表示するか、前の 3 時間のデータを表示するかを選択します。 **[Period] (期間)** グラフでのデータポイント間の間隔を変更します。 **[Rules] (ルール)** データを表示するルールを選択します。ルールの名前を変更し、ルールのメトリクス名に変更を反映する場合は、メトリクス名も更新する必要があります。ルール名を変更しても、ルールのメトリクス名は自動的に更新 AWS WAF されません。ルールの JSON エディターを使用して、コンソールでルールを編集するときに、メトリック名を変更できます。API や、保護パック (ウェブ ACL) またはルールグループの定義に使用する JSON リストを使用して、両方の名前を変更することもできます。次の点に注意してください。 + 最近保護パック (ウェブ ACL) を AWS リソースに関連付けた場合、データがグラフに表示され、保護パック (ウェブ ACL) のメトリクスが使用可能なメトリクスのリストに表示されるまで数分待つ必要がある場合があります。 + 複数のリソースを保護パック (ウェブ ACL) に関連付けると、CloudWatch データにはそれらすべてのリクエストが含まれます。 + データポイントの上にマウスカーソルを置くと、詳細情報が表示されます。 + グラフは自動的には更新されません。表示を更新するには、更新 (![\[Icon to refresh the CloudWatch graph\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/cloudwatch-refresh-icon.png)) アイコンを選択します。 CloudWatch のメトリクスの詳細については、「[Amazon CloudWatch によるモニタリング](monitoring-cloudwatch.md)」を参照してください。 # 保護パック (ウェブ ACL) のトラフィック概要ダッシュボードこのセクションでは、 AWS WAF コンソールの保護パック (ウェブ ACL) トラフィック概要ダッシュボードについて説明します。保護パック (ウェブ ACL) を 1 つ以上の AWS リソースに関連付け、保護パック (ウェブ ACL) のメトリクスを有効にすると、 AWS WAF コンソールの保護パック (ウェブ ACL) の**トラフィック概要**タブに移動して、保護パック (ウェブ ACL) が評価するウェブトラフィックの概要にアクセスできます。ダッシュボードには、特殊な AI ボットやエージェントのアクティビティ分析など、アプリケーションのウェブトラフィックを評価するときにが AWS WAF 収集する Amazon CloudWatch メトリクスのほぼリアルタイムの概要が含まれています。 **注記** ダッシュボードに何も表示されない場合は、保護パック (ウェブ ACL) でメトリクスが有効になっていることを確認してください。保護パック (ウェブ ACL) の **[トラフィック概要]** タブには、次のカテゴリの情報を含むタブ付きダッシュボードがあります。 + **トップセキュリティインサイト** – Amazon CloudWatch logsを直接クエリすることでが AWS WAF 取得する AWS WAF 保護に関するインサイト。ダッシュボードの残りの部分では、CloudWatch メトリクスを使用します。これらのインサイトはより豊富な情報を提供しますが、CloudWatch ログのクエリに追加のコストが発生します。追加コストの詳細については、「[Amazon CloudWatch Logs の料金](https://aws.amazon.com/cloudwatch/pricing/)」を参照してください。 + **AI トラフィック分析** – ボットの識別、インテント分類、アクセスパターン、一時的な傾向など、AI ボットとエージェントのアクティビティについて分析されたウェブリクエスト。このタブは、保護パック (ウェブ ACL) が AI ボットトラフィックを受信したときに使用できます。 + **[すべてのトラフィック]** — 保護パック (ウェブ ACL) で評価されるすべてのウェブリクエスト。ダッシュボードではアクションの終了に重点が置かれていますが、以下の場所でカウントルールに一致するものを確認できます。 + このダッシュボードの **[上位 10 件のルール]** ペイン。**[カウントアクションに切り替える]** をオンにすると、一致するカウントルールが表示されます。 + 保護パック (ウェブ ACL) ページの **[サンプルリクエスト]** タブ。この新しいタブには、ルールに一致したすべてのグラフが含まれています。詳細については、「[ウェブリクエストのサンプルの表示](web-acl-testing-view-sample.md)」を参照してください。 + **DDoS 対策** – `AntiDDoSRuleSet` DDoS 対策マネージドルールグループを使用して保護パック (ウェブ ACL) が評価するウェブリクエスト。このタブは、保護パック (ウェブ ACL) 内のこのルールグループを使用している場合にのみ使用できます。 + **[Bot Control]** — Bot Control マネージドルールグループを使用して保護パック (ウェブ ACL) で評価されるウェブリクエスト。 + 保護パック (ウェブ ACL) でこのルールグループを使用していない場合、このタブにはウェブトラフィックのサンプリングを Bot Control ルールと照合して評価した結果が表示されます。これにより、アプリケーションが受信するボットトラフィックがわかり、この機能は無料でご利用いただけます。このルールグループは、 AWS WAF が提供するインテリジェントな脅威軽減オプションの一部です。詳細については、「[AWS WAF ボットコントロール](waf-bot-control.md)」および「[AWS WAF Bot Control ルールグループ](aws-managed-rule-groups-bot.md)」を参照してください。 + **アカウント乗っ取り防止** – AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) マネージドルールグループを使用して保護パック (ウェブ ACL) が評価するウェブリクエスト。このタブは、保護パック (ウェブ ACL) 内のこのルールグループを使用している場合にのみ使用できます。 ATP ルールグループは、 AWS WAF インテリジェントな脅威の軽減保護の一部です。詳細については、「[AWS WAF Fraud Control アカウント乗っ取り防止 (ATP)](waf-atp.md)」および「[AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルールグループ](aws-managed-rule-groups-atp.md)」を参照してください。 + **アカウント作成不正防止** – Fraud Control Account Creation AWS WAF Fraud Prevention (ACFP) マネージドルールグループを使用して保護パック (ウェブ ACL) が評価するウェブリクエスト。このタブは、保護パック (ウェブ ACL) 内のこのルールグループを使用している場合にのみ使用できます。 ACFP ルールグループは、 AWS WAF のインテリジェントな脅威の緩和保護機能の一部です。詳細については、「[AWS WAF Fraud Control アカウント作成不正防止 (ACFP)](waf-acfp.md)」および「[AWS WAF Fraud Control アカウント作成不正防止 (ACFP) ルールグループ](aws-managed-rule-groups-acfp.md)」を参照してください。ダッシュボードは保護パック (ウェブ ACL) の CloudWatch メトリクスに基づいており、グラフが CloudWatch の対応するメトリクスへのアクセスを提供します。Bot Control のようなインテリジェントな脅威軽減ダッシュボードでは、使用されるメトリクスは主にラベルメトリクスです。 + AWS WAF が提供するメトリクスのリストについては、「」を参照してください[AWS WAF メトリクスとディメンション](waf-metrics.md)。 + Amazon CloudWatch メトリクスの詳細については、「[Amazon CloudWatch ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)」を参照してください。ダッシュボードには、選択した終了アクションと日付範囲のトラフィックパターンの概要が表示されます。インテリジェント脅威軽減ダッシュボードには、マネージドルールグループ自体が終了アクションを適用したかどうかに関係なく、対応するマネージドルールグループが評価したリクエストが含まれます。たとえば、Block が選択されている場合、**[Account Takeover Prevention]** ダッシュボードには、ATP マネージドルールグループによって評価されたものと、保護パック (ウェブ ACL) 評価中のある時点でブロックされたものの両方のすべてのウェブリクエストの情報が表示されます。リクエストは ATP マネージドルールグループ、保護パック (ウェブ ACL) のルールグループの後に実行されたルール、または保護パック (ウェブ ACL) のデフォルトアクションによってブロックされる場合があります。 # 保護パック (ウェブ ACL) のダッシュボードを表示する保護パック (ウェブ ACL) ダッシュボードにアクセスし、データフィルタリング条件を設定するには、このセクションの手順に従います。最近 AWS リソースに保護パック (ウェブ ACL) を関連付けた場合、ダッシュボードでデータが利用可能になるまで数分かかることがあります。ダッシュボードには、保護パック (ウェブ ACL) に関連付けたすべてのリソースのリクエストが含まれます。 **保護パック (ウェブ ACL) の **[トラフィックの概要]** ダッシュボードを表示するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで、**[保護パック (ウェブ ACL)]** を選択し、目的のウェブ ACL を検索します。 1. 保護パック (ウェブ ACL) を選択します。コンソールで保護パック (ウェブ ACL) のページが表示されます。**[トラフィックの概要]** タブがデフォルトで選択されています。 1. **[データフィルター]** の設定を必要に応じて変更します。 + **[終了ルールアクション]** — ダッシュボードに含める終了アクションを選択します。保護パック (ウェブ ACL) 評価によって選択されたアクションが適用されたウェブリクエストのメトリクスがダッシュボードに要約されます。実行可能なアクションをすべて選択すると、ダッシュボードには評価されたウェブリクエストがすべて含まれます。アクションの詳細については、「[がルールとルールグループのアクション AWS WAF を処理する方法](web-acl-rule-actions.md)」を参照してください。 + **[時間範囲]** — ダッシュボードに表示する時間間隔を選択します。過去 3 時間や過去 1 週間など、現在を基準にした時間枠を表示したり、カレンダーから絶対的な時間範囲を選択したりできます。 + **[タイムゾーン]** — この設定は、絶対時間で範囲を指定した場合に適用されます。ブラウザのローカルタイムゾーンまたは UTC (協定世界時) を使用できます。関心があるタブの情報を確認します。データフィルターの選択は、すべてのダッシュボードに適用されます。グラフペインでは、データポイントまたは領域の上にカーソルを置くと、その他の詳細が表示されます。 **Count アクションルール** カウントアクションの一致に関する情報は、2 つの場所のいずれかで表示できます。 + この **[トラフィック概要]** タブの **[すべてのトラフィック]** ダッシュボードで、**[トップ 10 ルール]** ペインを見つけ、**[カウントアクションに切り替え]** をオンにします。このトグルをオンにすると、ペインには一致したルールだけでなく、一致したルールも表示されます。 + 保護パック (ウェブ ACL) の **[サンプルリクエスト]** タブで、**[トラフィック概要]** で設定した期間のルールの一致とアクションの全グラフを参照します。**[サンプルリクエスト]** タブについて詳細は、「[ウェブリクエストのサンプルの表示](web-acl-testing-view-sample.md)」を参照してください。 **Amazon CloudWatch メトリクス** ダッシュボードのグラフペインでは、グラフ化されたデータの CloudWatch メトリクスにアクセスできます。グラフペインの上部またはペイン右上の **[⋮]** (垂直省略記号) ドロップダウンメニューからオプションを選択します。 **ダッシュボードの更新** ダッシュボードは自動的には更新されません。表示を更新するには、更新 ![\[Icon to refresh the dashboard graph\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/cloudwatch-refresh-icon.png) アイコンを選択します。 # 保護パック (ウェブ ACL) のトラフィックの概要ダッシュボード例このセクションでは、保護パック (ウェブ ACL) のトラフィック概要ダッシュボードの画面例を示しています。 **注記** すでに AWS WAF を使用してアプリケーションリソースを保護している場合は、 AWS WAF コンソールのページで任意の保護パック (ウェブ ACLs) のダッシュボードを表示できます。詳細については、「[保護パック (ウェブ ACL) のダッシュボードを表示する](web-acl-dashboards-accessing.md)」を参照してください。 **画面例: データフィルターと **[すべてのトラフィック]** ダッシュボードのアクション数** 次のスクリーンショットは、**[すべてのトラフィック]** タブが選択された状態で、保護パック (ウェブ ACL) のトラフィック概要を示しています。データフィルターはデフォルトに設定されており、過去 3 時間のすべての終了アクションを示しています。すべてのトラフィックダッシュボードには、さまざまな終了アクションのアクション合計が表示されます。各ペインにはリクエスト数が一覧表示され、過去 3 時間の時間範囲からの変化を示す上向き/下向きの矢印が表示されます。 ![\[AWS WAF コンソールには、デフォルトのデータフィルターが選択された保護パック (ウェブ ACL) ページのトラフィック概要タブが表示されます。終了ルールアクションのオプションは Block、Allow、CAPTCHA、および Challenge です。データフィルターセクションの下には、すべてのトラフィック、Bot Control、アカウント乗っ取り防止のタブがあります。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/web-acl-dashboard-data-filters-default-top-actions.png) **画面の例: **[Bot Control]** ダッシュボードのアクション数** 次のスクリーンショットは、Bot Control ダッシュボードのアクション数を示しています。これは時間範囲で同じ合計ペインを表示していますが、この数は Bot Control ルールグループが評価したリクエストのみを対象としています。さらに下の **[アクション合計]** ペインには、指定した 3 時間の時間範囲におけるアクション数が表示されます。この時間範囲では、ルールグループが評価したどのリクエストにも CAPTCHA アクションは適用されませんでした。 ![\[AWS WAF コンソールには Bot Control ダッシュボードの上部が表示され、時間範囲のアクション合計と時間範囲全体のアクション合計が表示されます。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/web-acl-dashboard-bot-action-totals.png) **画面の例: **AI トラフィック分析ダッシュボード**のアクション数** 次のスクリーンショットは、保護パック (ウェブ ACL) の AI トラフィック分析ダッシュボードを示しています。ダッシュボードには、ボットの組織、インテントタイプ、検証ステータスのフィルターを使用して、選択した時間範囲における AI ボットアクティビティが表示されます。 ![\[AWS WAF コンソールには、AI トラフィック分析ダッシュボードの上部に、時間範囲の上位クローラと上位パス、および時間範囲全体のアクション合計が表示されます。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/waf-phantom-edge-dashboard.png) ダッシュボードには以下が含まれます。 + **Bot Identity パネル** – 検出された AI ボットを名前と組織で一覧表示します + **目的分類** – ボットの目的 (クローリング、インデックス作成、調査など) を分類します。 + **アクセスパターン** – リクエスト数で AI エージェントによってアクセスされた上位 URLs + **時間分析** – 14 日間の履歴ビューを含む時間単位および日単位のアクティビティの傾向 + **組織の内訳** — ボット所有者組織別のトラフィック量 **画面の例: **[Bot Control]** ダッシュボードのトークンステータスの概要グラフ** 次のスクリーンショットは、Bot Control ダッシュボードに表示される 2 つの概要グラフィックを示しています。**[トークンステータス]** ペインには、さまざまなトークンステータスラベルの数と、リクエストに適用されたルールアクションが表示されます。**[IP トークン不在しきい値]** ペインには、トークンなしで大量のリクエストを送信していた IP からのリクエストのデータが表示されます。グラフの任意の領域にカーソルを合わせると、利用可能な情報の詳細が表示されます。このスクリーンショットの **[トークンステータス]** ペインでは、マウスはグラフの線上にない特定の時点にカーソルを合わせているので、コンソールにはその時点のすべての線のデータが表示されます。 ![\[AWS WAF コンソールには、トークンステータスと IP トークンにしきい値がない 2 つのペインが表示され、ブロックされたリクエストとチャレンジされたリクエストのグラフ行は各ペインに似ています。[トークンステータス] ペインには、許可されたリクエストのグラフもあります。\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/images/web-acl-dashboard-bot-token-panes.png) このセクションには、保護パック (ウェブ ACL) トラフィック概要ダッシュボードに表示されるトラフィックの概要の一部だけが表示されます。保護パック (ウェブ ACL) のダッシュボードを表示するには、コンソールで保護パック (ウェブ ACL) のページを開きます。これを行う方法については、「[保護パック (ウェブ ACL) のダッシュボードを表示する](web-acl-dashboards-accessing.md)」でガイダンスを参照してください。 # ウェブリクエストのサンプルの表示このセクションでは、 AWS WAF コンソールの保護パック (ウェブ ACL) **のサンプルリクエスト**タブについて説明します。このタブでは、 AWS WAF が検査したウェブリクエストのすべてのルール一致のグラフを表示できます。さらに、保護パック (ウェブ ACL) に対してリクエストサンプリングが有効になっている場合は、 AWS WAF が検査したウェブリクエストのサンプルのテーブルビューが表示されます。また、API コールを通じてサンプルリクエスト情報を取得することもできます `GetSampledRequests`。リクエストのサンプルには、保護パック (ウェブ ACL) のルールの基準に一致した最大 100 件のリクエストと、いずれのルールにも一致せず、保護パック (ウェブ ACL) のデフォルトアクションが適用されたリクエストの別の 100 件のリクエストが含まれます。サンプルのリクエストは、過去 3 時間にコンテンツについてのリクエストを受け取ったすべての保護されたリソースからのものです。ウェブリクエストがルールの基準に一致し、そのルールのアクションがリクエスト評価を終了しない場合、は保護パック (ウェブ ACL) の後続のルールを使用してウェブリクエストの検査を AWS WAF 続行します。このため、ウェブリクエストが複数回表示される可能性があります。ルールアクションの動作については、「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」を参照してください。 **すべてのルールグラフとサンプルされたリクエストを表示するには** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ナビゲーションペインで、**[保護パック (ウェブ ACL)]** を選択します。 1. リクエストを表示する保護パック (ウェブ ACL) の名前を選択します。コンソールで保護パック (ウェブ ACL) の説明が表示され、そこで編集できます。 1. **[サンプルリクエスト]** タブには、次の内容が表示されます。 + [**すべてのルールグラフ**] — このグラフには、指定した期間中に実行されたすべての Web リクエスト評価の一致ルールとルールアクションが表示されます。 **注記** このグラフの時間範囲は、保護パック (ウェブ ACL) の **[トラフィック概要]** タブの **[データフィルター]** セクションで設定されます。詳細については、「[保護パック (ウェブ ACL) のダッシュボードを表示する](web-acl-dashboards-accessing.md)」を参照してください。 + **サンプルリクエストテーブル** — このテーブルには、過去 3 時間のサンプルリクエストデータが表示されます。 **注記** マネージドルールグループで期待されるサンプルが表示されない場合は、この手順の下のセクションを参照してください。この表には、エントリごとに以下のデータが表示されます。 **メトリクス名** リクエストに一致した保護パック (ウェブ ACL) 内のルールの CloudWatch メトリクス名。ウェブリクエストが保護パック (ウェブ ACL) のルールと一致しない場合、この値は**デフォルト**。ルールの名前を変更し、ルールのメトリクス名に変更を反映する場合は、メトリクス名も更新する必要があります。ルール名を変更しても、ルールのメトリクス名は自動的に更新 AWS WAF されません。ルールの JSON エディターを使用して、コンソールでルールを編集するときに、メトリック名を変更できます。API や、保護パック (ウェブ ACL) またはルールグループの定義に使用する JSON リストを使用して、両方の名前を変更することもできます。 **[Source IP] (送信元 IP)** リクエストの発生元の IP アドレス (ビューワーが HTTP プロキシまたは Application Load Balancer を使用してリクエストを送信した場合は、そのプロキシまたは Application Load Balancer の IP アドレス)。 **[URI]** URL 内でリソースを識別する部分 (`/images/daily-ad.jpg` など)。 **ルールグループ内のルール** メトリック名がルールグループ参照ステートメントを識別する場合、これにより、リクエストに一致するルールグループ内のルールが識別されます。 **Action** 対応するルールのアクションを示します。取りうるルールアクションの情報については、「[でのルールアクションの使用 AWS WAF](waf-rule-action.md)」を参照してください。ルールグループでカウントアクションを使用するルールのサンプルリクエストは、ウェブ ACL ビューでは使用できません。ルールグループルールのカウントメトリクスとサンプリングされたリクエストは、ルールグループの所有者にのみ表示されます。 **Time** が保護されたリソースからリクエストを AWS WAF 受信した時間。ウェブリクエストのコンポーネントに関する追加情報を表示するには、リクエストの行にある URI の名前を選択します。 **マネージドルールグループのルールのサンプリングされたリクエスト** コンソールには、トリガーされたルールを指定する「ルールグループ内のルール」を含むルールグループのメトリクスが表示されます。最新の`RuleActionOverrides`設定を使用して、デフォルトのアクションルールセットとルールのメトリクスを表示できます。古い`ExcludedRules`設定を使用するルールの場合、**Sampled Requests** メトリクスルールドロップダウンからルールセット内から特定のルールを選択します。古い設定が表示された場合は、それらを新しい設定に置き換えて、サンプルリクエストをコンソールで使用可能にします。これを行うには、保護パック (ウェブ ACL) のマネージドルールグループを編集して保存します。 AWS WAF は古い設定を自動的に `RuleActionOverrides` 設定に置き換え、ルールアクションオーバーライドを Count に設定します。これらの 2 つの設定の詳細については、「[JSON リスト: `RuleActionOverrides` を `ExcludedRules` に置き換えます](web-acl-rule-group-override-options.md#web-acl-rule-group-override-replaces-exclude)」を参照してください。 AWS WAF REST API、SDKs、またはコマンドラインを使用して、古いオーバーライドが設定されているルールのサンプルリクエストにアクセスできます。詳細については、「*AWS WAF API リファレンス*」の [GetSampledRequests](https://docs.aws.amazon.com/waf/latest/APIReference/API_GetSampledRequests.html) を参照してください。コマンドラインリクエストの構文を次に示します。 ``` aws wafv2 get-sampled-requests \ --web-acl-arn webACL ARN \ --rule-metric-name Metric name of the rule in the managed rule group \ --scope=REGIONAL or CLOUDFRONT \ --time-window StartTime=UTC timestamp,EndTime=UTC timestamp \ --max-items 100 ``` # 本番環境で保護の有効化このセクションでは、本番稼働でチューニングされた保護を有効にする手順について説明します。本番環境でのテストとチューニングの最終段階が終了したら、本番モードで保護を有効にします。 **本番稼働トラフィックのリスク** 本番稼働トラフィックに保護パック (ウェブ ACL) 実装をデプロイする前に、トラフィックへの潜在的な影響に慣れるまで、テスト環境でテストおよびチューニングします。また、本番稼働用トラフィックの保護を有効にする前に、本番稼働用トラフィックでカウントモードでテストおよびチューニングします。 **注記** このセクションのガイダンスに従うには、 AWS WAF 保護パック (ウェブ ACLs)、ルール、ルールグループなどの保護を作成および管理する方法を一般的に理解する必要があります。この情報は、このガイドの前のセクションで説明しています。これらのステップを最初にテスト環境で実行し、次に本番環境で実行します。 **本番環境で AWS WAF 保護を有効にする** 1. **本番環境保護に切り替える** 保護パック (ウェブ ACL) を更新し、本番環境の設定を切り替えます。 1. **不要なテストルールをすべて削除する** 本番環境では必要ないテストルールを追加した場合は、それらを削除します。ラベル一致ルールを使用して管理ルールグループルールの結果をフィルタリングする場合は、必ずそれらのルールをそのままにしておいてください。 1. **本番用アクションに切り替える** 新しいルールのアクション設定を、意図したプロダクション設定に変更します。 + **保護パック (ウェブ ACL) で定義されているルール** — 保護パック (ウェブ ACL) のルールを編集し、Count からのそれらのアクションを本番環境のアクションに変更します。 + **ルールグループ** — ルールグループの保護パック (ウェブ ACL) 設定で、独自のアクションを使用するようにルールを切り替えるか、テストおよびチューニングのアクティビティの結果に応じて、Count アクションオーバーライドがあるままにします。ラベル一致ルールを使用してルールグループルールの結果をフィルタリングする場合は、必ずそのルールのオーバーライドをそのまま残してください。ルールのアクションの使用に切り替えるには、保護パック (ウェブ ACL) 設定で、ルールグループのルールステートメントを編集し、ルールの Count オーバーライドを削除します。JSON で保護パック (ウェブ ACL) を管理する場合、ルールグループ参照ステートメントで `RuleActionOverrides` リストからルールのエントリを削除します。 + **保護パック (ウェブ ACL)** — 保護パック (ウェブ ACL) のデフォルトアクションをテスト用に変更した場合は、本番用の設定に切り替えます。これらの設定により、意図したとおりに新しい保護がウェブトラフィックを管理します。保護パック (ウェブ ACL) を保存すると、それが関連付けられているリソースは本番設定を使用します。 1. **モニタリングおよびチューニング** ウェブリクエストが希望どおりに処理されていることを確認するには、新しい機能を有効にした後、トラフィックを注意深く監視します。チューニング作業で監視していたカウントアクションではなく、本番ルールアクションのメトリクスとログを監視します。ウェブトラフィックの変化に適応するために、必要に応じて動作を監視し、調整してください。 # Amazon CloudFront AWS WAF でのの使用 Amazon CloudFront 機能 AWS WAF でを使用する方法について説明します。保護パック (ウェブ ACL) を作成するときに、 AWS WAF で検査する 1 つ以上の CloudFront ディストリビューションを指定できます。CloudFront は、個々のテナントを保護する標準ディストリビューションと、単一の共有設定テンプレートを使用して複数のテナントを保護するマルチテナントディストリビューションの 2 種類のディストリビューションをサポートしています。 AWS WAF は、保護パック (ウェブ ACL) で定義したルールに基づいて、両方のディストリビューションタイプのウェブリクエストを検査し、タイプごとに実装パターンが異なります。 **Topics** + [ ## がさまざまなディストリビューションタイプと AWS WAF 連携する方法 ](#cloudfront-features-distribution-types) + [ ## CloudFront 定額料金プラン AWS WAF でのの使用 ](#waf-cf-pricing-plans) + [ # で CloudFront ディストリビューションを保護するための一般的なユースケース AWS WAF ](cloudfront-waf-use-cases.md) ## がさまざまなディストリビューションタイプと AWS WAF 連携する方法 ### ディストリビューションタイプ AWS WAF は、標準およびマルチテナントディストリビューション CloudFront ディストリビューションの両方にウェブアプリケーションファイアウォール機能を提供します。 #### 標準ディストリビューション標準ディストリビューションの場合、はディストリビューションごとに 1 つの保護パック (ウェブ ACL) を使用して保護 AWS WAF を追加します。この保護を有効にするには、既存の保護パック (ウェブ ACL) を CloudFront ディストリビューションに関連付けるか、CloudFront コンソールでワンクリック保護を使用します。これにより、保護パック (ウェブ ACL) を変更すると、それに関連付けられたディストリビューションにのみ影響するため、各ディストリビューションのセキュリティコントロールを個別に管理できます。 CloudFront ディストリビューションを保護するこの簡単な方法は、個々のドメインに単一の保護パック (ウェブ ACL) からの特定の保護を提供するのに最適です。 ##### 標準ディストリビューションに関する考慮事項 + 保護パック (ウェブ ACL) の変更は、関連付けられたディストリビューションにのみ影響します + 各ディストリビューションには、独立した保護パック (ウェブ ACL) 設定が必要です + ルールとルールグループはディストリビューションごとに個別に管理されます #### マルチテナントディストリビューションマルチテナントディストリビューションの場合、は単一の保護パック (ウェブ ACL) を使用して複数のドメインに保護 AWS WAF を追加します。マルチテナントディストリビューションによって管理されるドメインは、ディストリビューションテナントと呼ばれます。マルチテナントディストリビューション AWS WAF の保護は、マルチテナントディストリビューションの作成プロセス中または作成後に、CloudFront コンソールでのみ有効にできます。ただし、保護パック (ウェブ ACL) への変更は、 AWS WAF コンソールまたは API を通じて管理されます。マルチテナントディストリビューションは、次の 2 つのレベルで AWS WAF 保護を可能にする柔軟性を提供します。 + **マルチテナントディストリビューションレベル** – 関連付けられた保護パック (ウェブ ACL) は、そのディストリビューションを共有するすべてのアプリケーションに適用されるベースラインセキュリティコントロールを提供します + **ディストリビューションテナントレベル** – マルチテナントディストリビューション内の個々のテナントは、追加のセキュリティコントロールを実装したり、マルチテナントディストリビューション設定をオーバーライドしたりするために、独自の保護パック (ウェブ ACL) を持つことができますこれらの 2 つの階層により、マルチテナントディストリビューションは、個々のディストリビューションのセキュリティをカスタマイズする能力を失うことなく、複数のドメイン間で AWS WAF 保護を共有するのに最適です。 #### マルチテナントディストリビューションに関する考慮事項 + 個々のディストリビューションテナントは、関連するマルチテナントディストリビューションに関連付けられている保護パック (ウェブ ACL) に加えられた変更を継承します + 特定のディストリビューションテナントに関連付けられた保護パック (ウェブ ACL) は、マルチテナント保護パック (ウェブ ACL) レベルで設定された設定をオーバーライドできます + マネージドルールグループは、ディストリビューションレベルとディストリビューションテナントレベルの両方で実装できます + アプリケーション識別子をログに保存して、ディストリビューション別にセキュリティイベントを追跡できます ### AWS WAF ディストリビューションタイプ別の機能 **保護パック (ウェブ ACL) の実装を比較する** | AWS WAF 機能 | 標準ディストリビューション | マルチテナントディストリビューション | | --- | --- | --- | | 保護パック (ウェブ ACL) の関連付け | ディストリビューションごとに 1 つの保護パック (ウェブ ACL) | オプションでテナント固有の保護パック (ウェブ ACL) を使用して、テナント間で保護パック (ウェブ ACL) を共有できます | | ルールの管理 | ルールが 1 つのディストリビューションに影響する | マルチテナントディストリビューションルールは、関連付けられたすべてのテナントに影響します。ディストリビューションテナント固有のルールは、そのテナントにのみ影響します | | マネージドルールグループ | 個々のディストリビューションに適用 | すべてのテナントにマルチテナントディストリビューションレベルで、または特定のアプリケーションにテナントレベルで適用できます | | ログ記録 | 標準 AWS WAF ログ | ログには、セキュリティイベント属性のテナント識別子が含まれます | ## CloudFront 定額料金プラン AWS WAF でのの使用 CloudFront 定額料金プランは、Amazon CloudFront グローバルコンテンツ配信ネットワーク (CDN) と複数の AWS のサービスおよび機能を、トラフィックの急増や攻撃に関係なく、超過料金なしで月額料金で組み合わせます。定額料金プランには、シンプルな月額料金の以下の AWS のサービスおよび機能が含まれます。 + CloudFront CDN + AWS WAF および DDoS 保護 + ボット管理と分析 + Amazon Route 53 DNS + Amazon CloudWatch Logs の取り込み + TLS 証明書 + サーバーレスエッジコンピューティング + 毎月の Amazon S3 ストレージクレジットプランは、アプリケーションのニーズに合わせて、無料、プロ、ビジネス、プレミアムの各階層で利用できます。プランでは、ベストレートを取得するために年間コミットメントは必要ありません。無料プランから始めて、より多くの機能や使用量にアップグレードできます。プランと機能の詳細なリストについては、「Amazon [CloudFront デベロッパーガイド」の「CloudFront 定額料金プラン](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/flat-rate-pricing-plan.html)」を参照してください。 *Amazon CloudFront * **重要** 料金プランを使用する場合は、有効な AWS WAF 保護パック (ウェブ ACL) を CloudFront ディストリビューションに関連付ける必要があります。pay-as-you-goに切り替えない限り、保護パック (ウェブ ACL) の関連付けを削除することはできません。 AWS WAF ウェブ ACL はディストリビューションに関連付けられている必要がありますが、セキュリティ設定を完全に制御できます。ウェブ ACL で有効または無効にするルールを調整して保護をカスタマイズし、セキュリティ要件に合わせてルール設定を変更できます。ウェブ ACL ルールの管理については、[AWS WAF 「ルール](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rules.html)」を参照してください。 # で CloudFront ディストリビューションを保護するための一般的なユースケース AWS WAF 以下の AWS WAF 機能は、すべての CloudFront ディストリビューションで同じように機能します。マルチテナントディストリビューションに関する考慮事項は、各機能シナリオの後に一覧表示されます。 ## CloudFront カスタムエラーページ AWS WAF でのの使用デフォルトでは、が指定した条件に基づいてウェブリクエストを AWS WAF ブロックすると、HTTP ステータスコードを CloudFront `403 (Forbidden)`に返し、CloudFront はそのステータスコードをビューワーに返します。ビューワーには、次のような簡潔で特に書式設定されていないデフォルトメッセージが表示されます。 ``` Forbidden: You don't have permission to access /myfilename.html on this server. ``` カスタムレスポンスを定義することで、 AWS WAF 保護パック (ウェブ ACL) ルールでこの動作を上書きできます。 AWS WAF ルールを使用したレスポンス動作のカスタマイズの詳細については、「」を参照してください[Block アクションのカスタムレスポンスの送信](customizing-the-response-for-blocked-requests.md)。 **注記** AWS WAF ルールを使用してカスタマイズしたレスポンスは、CloudFront カスタムエラーページで定義したレスポンス仕様よりも優先されます。場合によってウェブサイトの他の部分と同じフォーマットを使用して、CloudFront を介してカスタムエラーメッセージを表示したい場合は、カスタムエラーメッセージを含むオブジェクト (HTML ファイルなど) をビューワーに返すように CloudFront を設定できます。 **注記** CloudFront は、オリジンによって返される HTTP ステータスコード 403 と、リクエストがブロックされた AWS WAF ときにによって返される HTTP ステータスコード 403 を区別できません。つまり、HTTP ステータスコード 403 のさまざまな原因に基づいて、異なるカスタムエラーページを返すことはできません。 CloudFront カスタムエラーページの詳細については、「*Amazon CloudFront デベロッパーガイド*」の「[カスタムエラーレスポンスの生成](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GeneratingCustomErrorResponses.html)」を参照してください。 ### マルチテナントディストリビューションのカスタムエラーページ CloudFront マルチテナントディストリビューションでは、次の方法でカスタムエラーページを設定できます。 + マルチテナントレベル - これらの設定は、マルチテナントディストリビューションテンプレートを使用するすべてのテナントディストリビューションに適用されます。 + AWS WAF ルール経由 - 保護パック (ウェブ ACLsマルチテナントディストリビューションとテナントレベルのカスタムエラーページの両方よりも優先されます。 ## 独自の HTTP サーバーで実行されているアプリケーションに CloudFront AWS WAF でを使用する CloudFront AWS WAF でを使用すると、Amazon Elastic Compute Cloud (Amazon EC2) で実行されているウェブサーバーでも、プライベートに管理するウェブサーバーでも、任意の HTTP ウェブサーバーで実行されているアプリケーションを保護できます。CloudFront と独自のウェブサーバー間、およびビューワーと CloudFront の間で HTTPS が必須になるように CloudFront を設定することもできます。 **CloudFront と独自のウェブサーバー間での HTTPS の必須化** CloudFront と独自のウェブサーバー間で HTTPS を必須にするには、CloudFront カスタムオリジン機能を使用し、特定のオリジンの **[Origin Protocol Policy]** (オリジンプロトコルポリシー) および **[Origin Domain Name]** (オリジンドメイン名) の設定を構成します。CloudFront 設定では、オリジンからオブジェクトをフェッチするとき CloudFront で使用するポートとプロトコルとともに、サーバーの DNS 名を指定できます。また、カスタムオリジンサーバー上の SSL/TLS 証明書が、設定したオリジンドメイン名と一致することを確認する必要もあります。の外部で独自の HTTP ウェブサーバーを使用する場合は AWS、信頼できるサードパーティー認証機関 (CA) によって署名された証明書を使用する必要があります。例えば、Comodo、DigiCert、Symantec などです。CloudFront と独自のウェブサーバー間の通信に HTTPS を要求する方法の詳細については、「Amazon CloudFront デベロッパーガイド」の「[CloudFront とカスタムオリジン間の通信で HTTPS を必須にする](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-custom-origin.html)」のトピックを参照してください。 **ビューワーと CloudFront との間での HTTPS の必須化** ビューワーと CloudFront の間に HTTPS を要求するために、CloudFront ディストリビューションの 1 つ以上のキャッシュ動作の**ビューワープロトコルポリシー**を変更できます。ビューワーと CloudFront 間での HTTPS の使用の詳細については、「*Amazon CloudFront デベロッパーガイド*」の「[ビューワーと CloudFront 間の通信で HTTPS を必須にする](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html)」のトピックを参照してください。独自の SSL 証明書を使用して、ビューワーが独自のドメイン名を使用して HTTPS 経由で CloudFront ディストリビューションに接続できるようにすることもできます (例: *https://www.mysite.com*)。詳細については、「*Amazon CloudFront デベロッパーガイド*」の「[代替ドメイン名とHTTPS を使用する](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-procedures.html)」のトピックを参照してください。マルチテナントディストリビューションの場合、HTTP メソッド設定は次の階層に従います。 + テンプレートレベルの設定は、すべてのテナントディストリビューションで許可されるベースライン HTTP メソッドを定義します。 + テナントディストリビューションは、これらの設定を次のようにオーバーライドできます。 + マルチテナントディストリビューションよりも少ないメソッドを許可する ( AWS WAF ルールを使用して追加のメソッドをブロックする) + マルチテナントディストリビューションがサポートするように設定されている場合、より多くのメソッドを許可する + AWS WAF マルチテナントディストリビューションレベルとテナントレベルの両方のルールは、CloudFront 設定に関係なく HTTP メソッドをさらに制限できます。 ## CloudFront が応答する HTTP メソッドの選択 Amazon CloudFront のウェブディストリビューションを作成するときは、CloudFront によって処理されてオリジンに転送される HTTP メソッドを選択します。次のオプションから選択できます。 + **`GET`、`HEAD`** – CloudFront を使用して、オリジンからのオブジェクトの取得またはオブジェクトヘッダーの取得のみを行うことができます。 + **`GET`、`HEAD`、`OPTIONS`** – CloudFront を使用して、オリジンからのオブジェクトの取得、オブジェクトヘッダーの取得、またはオリジンサーバーがサポートするオプションのリスト取得のみを行うことができます。 + **`GET`、`HEAD`、`OPTIONS`、`PUT`、`POST`、`PATCH`、`DELETE`** – CloudFront を使用して、オブジェクトの取得、追加、更新、削除、およびオブジェクトヘッダーの取得を行うことができます。また、ウェブフォームからのデータの送信など、その他の `POST` オペレーションも実行できます。「」で説明されているように、 AWS WAF バイト一致ルールステートメントを使用して、HTTP メソッドに基づいてリクエストを許可またはブロックすることもできます[文字列一致ルールステートメント](waf-rule-statement-type-string-match.md)。`GET` やなど、CloudFront がサポートするメソッドの組み合わせを使用する場合は`HEAD`、他のメソッドを使用するリクエストをブロック AWS WAF するようにを設定する必要はありません。`GET`、、など、CloudFront がサポートしていないメソッドの組み合わせを許可する場合は`POST`、すべてのメソッドに応答するように CloudFront `HEAD`を設定し、を使用して他のメソッドを使用するリクエスト AWS WAF をブロックできます。が応答するメソッドの選択の詳細については、「*Amazon CloudFront デベロッパーガイド*」で「[ウェブディストリビューションを作成または更新する場合に指定する値](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html)」トピックの「[許可される HTTP メソッド](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesAllowedHTTPMethods)」を参照してください。 **HTTP メソッド設定がマルチテナントディストリビューションで許可されている** マルチテナントディストリビューションの場合、マルチテナントディストリビューションレベルで設定された HTTP メソッド設定は、デフォルトですべてのテナントディストリビューションに適用されます。テナントディストリビューションは、必要に応じてこれらの設定をオーバーライドできます。 + `GET` やなど、CloudFront がサポートするメソッドの組み合わせを使用する場合は`HEAD`、他のメソッドを使用するリクエストをブロック AWS WAF するようにを設定する必要はありません。 + `GET`、、など、CloudFront がデフォルトでサポートしていないメソッドの組み合わせを許可する場合は`POST`、すべてのメソッドに応答するように CloudFront `HEAD`を設定し、を使用して他のメソッドを使用するリクエスト AWS WAF をブロックできます。マルチテナントディストリビューションにセキュリティヘッダーを実装する場合は、次の点を考慮してください。 + テンプレートレベルのセキュリティヘッダーは、すべてのテナントディストリビューションでベースライン保護を提供します + テナントディストリビューションは次のことができます。 + マルチテナントディストリビューションで定義されていない新しいセキュリティヘッダーを追加する + テナント固有のヘッダーの値を変更する + マルチテナントディストリビューションレベルで設定されたセキュリティヘッダーを削除またはオーバーライドすることはできません + すべてのテナントに適用する必要がある重要なセキュリティコントロールには、マルチテナントディストリビューションレベルのヘッダーを使用することを検討してください。 ## ログ記録に関する考慮事項標準ディストリビューションとマルチテナントディストリビューションの両方が AWS WAF ログ記録をサポートしていますが、ログの構造と管理方法には重要な違いがあります。 **ログ記録の比較** | 標準ディストリビューション | マルチテナントディストリビューション | | --- | --- | | ディストリビューションごとに 1 つのログ設定 | テンプレートとテナントレベルのログ記録オプション | | 標準ログフィールド | 追加のテナント識別子フィールド | | ディストリビューションごとに 1 つの送信先 | マルチテナントディストリビューションとテナントログに可能な別々の送信先 | ## その他のリソース + マルチテナントディストリビューションの詳細については、「*Amazon CloudFront デベロッパーガイド*」の「[ディストリビューションの設定](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-working-with.html)」を参照してください。 + CloudFront AWS WAF でのの使用の詳細については、*Amazon CloudFront * [デベロッパーガイド」の AWS WAF 「保護](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-awswaf.html)の使用」を参照してください。 + AWS WAF ログの詳細については、「」を参照してください[保護パック (ウェブ ACL) トラフィックのログフィールド](logging-fields.md)。 # AWS WAF サービスの使用におけるセキュリティこのセクションでは、責任共有モデルがどのように適用されるかについて説明します AWS WAF。でのクラウドセキュリティが最優先事項 AWS です。お客様は AWS 、セキュリティを最も重視する組織の要件を満たすように構築されたデータセンターとネットワークアーキテクチャを活用できます。 **注記** このセクションでは、 AWS WAF 保護パック (ウェブ ACLs) やルールグループなど、 AWS WAF サービスとその AWS リソースの使用に関する標準的な AWS セキュリティガイダンスを提供します。を使用して AWS リソースを保護する方法については AWS WAF、この AWS WAF ガイドの残りの部分を参照してください。セキュリティは、 AWS お客様とお客様の間の責任共有です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)では、これをクラウドのセキュリティおよびクラウド内のセキュリティとして説明しています。 + **クラウドのセキュリティ** – AWS は、で AWS サービスを実行するインフラストラクチャを保護する責任を担います AWS クラウド。は、お客様が安全に使用できるサービス AWS も提供します。セキュリティの有効性は、[AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)の一環として、サードパーティーの審査機関によって定期的にテストおよび検証されています。が適用されるコンプライアンスプログラムの詳細については AWS WAF、[AWS 「コンプライアンスプログラムによる対象範囲内のサービス](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。 + **クラウドのセキュリティ** – お客様の責任は、使用する AWS サービスによって決まります。また、お客様は、お客様のデータの機密性、組織の要件、および適用可能な法律および規制などの他の要因についても責任を担います。このドキュメントは、を使用する際の責任共有モデルの適用方法を理解するのに役立ちます AWS WAF。以下のトピックでは、セキュリティとコンプライアンスの目的を達成する AWS WAF ようにを設定する方法を示します。また、 AWS WAF リソースのモニタリングや保護に役立つ他の AWS サービスの使用方法についても説明します。 **Topics** + [ # でのデータの保護 AWS WAF ](data-protection.md) + [ # での IAM の使用 AWS WAF ](security-iam.md) + [ # でのログ記録とモニタリング AWS WAF ](waf-incident-response.md) + [ # でのコンプライアンスの検証 AWS WAF ](waf-compliance.md) + [ # でのレジリエンスの構築 AWS WAF ](disaster-recovery-resiliency.md) + [ # のインフラストラクチャセキュリティ AWS WAF ](infrastructure-security.md) # でのデータの保護 AWS WAF 責任 AWS [共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)、でのデータ保護に適用されます AWS WAF。このモデルで説明されているように、 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 メールアドレスなどの極秘または機密情報を、タグ、または **[名前]** フィールドなどの自由形式のテキストフィールドに含めないことを強くお勧めします。これは、コンソール AWS WAF 、API、または SDK を使用して AWS CLIまたは他の AWS のサービスを操作する場合も同様です。 AWS SDKs タグ、または名前に使用される自由記述のテキストフィールドに入力したデータは、請求または診断ログに使用される場合があります。外部サーバーに URL を提供する場合、そのサーバーへのリクエストを検証できるように、認証情報を URL に含めないことを強くお勧めします。 AWS WAF 保護パック (ウェブ ACLs)、ルールグループ、IP セットなどのエンティティは、中国 (北京) や中国 (寧夏) など、暗号化が利用できない特定のリージョンを除き、保管時に暗号化されます。リージョンごとに一意の暗号化キーが使用されます。 ## AWS WAF リソースの削除 AWS WAFで作成したリソースは削除できます。次のセクションの各リソースタイプのガイダンスを参照してください。 + [保護パック (ウェブ ACL) の削除](web-acl-deleting.md) + [ルールグループの削除](waf-rule-group-deleting.md) + [IP セットの削除](waf-ip-set-managing.md#waf-ip-set-deleting) + [正規表現パターンセットの削除](waf-regex-pattern-set-managing.md#waf-regex-pattern-set-deleting) # での IAM の使用 AWS WAF このセクションでは、で IAM を使用する方法について説明します AWS WAF。 AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御 AWS のサービスするのに役立つです。IAM 管理者は、誰を*認証* (サインイン) し、誰に AWS WAF リソースの使用*を許可する* (アクセス許可を付与する) かを制御します。IAM は、追加料金なしで使用できる AWS のサービスです。 **Topics** + [ ## オーディエンス ](#security_iam_audience) + [ ## アイデンティティを使用した認証 ](#security_iam_authentication) + [ ## ポリシーを使用したアクセスの管理 ](#security_iam_access-manage) + [ # が IAM と AWS WAF 連携する方法 ](security_iam_service-with-iam.md) + [ # のアイデンティティベースのポリシーの例 AWS WAF ](security_iam_id-based-policy-examples.md) + [ # AWS の管理ポリシー AWS WAF ](security-iam-awsmanpol.md) + [ # AWS WAF ID とアクセスのトラブルシューティング ](security_iam_troubleshoot.md) + [ # のサービスにリンクされたロールの使用 AWS WAF ](using-service-linked-roles.md) ## オーディエンス AWS Identity and Access Management (IAM) の使用方法は、ロールによって異なります。 + **サービスユーザー** - 機能にアクセスできない場合は、管理者にアクセス許可をリクエストします (「[AWS WAF ID とアクセスのトラブルシューティング](security_iam_troubleshoot.md)」を参照)。 + **サービス管理者** - ユーザーアクセスを決定し、アクセス許可リクエストを送信します (「[が IAM と AWS WAF 連携する方法](security_iam_service-with-iam.md)」を参照) + **IAM 管理者** - アクセスを管理するためのポリシーを作成します (「[のアイデンティティベースのポリシーの例 AWS WAF](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 マネージドポリシーを使用できません。 ### その他のポリシータイプ 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 WAF 連携する方法このセクションでは、で IAM の機能を使用する方法について説明します AWS WAF。 IAM を使用してへのアクセスを管理する前に AWS WAF、使用できる IAM 機能を確認してください AWS WAF。 **で使用できる IAM 機能 AWS WAF** | IAM 機能 | AWS WAF サポート | | --- | --- | | [アイデンティティベースのポリシー](#security_iam_service-with-iam-id-based-policies) | あり | | [リソースベースのポリシー](#security_iam_service-with-iam-resource-based-policies) | はい | | [ポリシーアクション](#security_iam_service-with-iam-id-based-policies-actions) | あり | | [ポリシーリソース](#security_iam_service-with-iam-id-based-policies-resources) | はい | | [ポリシー条件キー (サービス固有)](#security_iam_service-with-iam-id-based-policies-conditionkeys) | はい | | [ACL](#security_iam_service-with-iam-acls) | なし | | [ABAC (ポリシー内のタグ)](#security_iam_service-with-iam-tags) | 部分的 | | [一時認証情報](#security_iam_service-with-iam-roles-tempcreds) | あり | | [転送アクセスセッション (FAS)](#security_iam_service-with-iam-principal-permissions) | あり | | [サービスロール](#security_iam_service-with-iam-roles-service) | あり | | [サービスリンクロール](#security_iam_service-with-iam-roles-service-linked) | はい | AWS WAF およびその他の AWS のサービスがほとんどの IAM 機能とどのように連携するかの概要については、「IAM *ユーザーガイド*」の[AWS 「IAM と連携するのサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。 ## のアイデンティティベースのポリシー AWS WAF **アイデンティティベースのポリシーのサポート:** ありアイデンティティベースポリシーは、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)」を参照してください。 AWS WAF アイデンティティベースのポリシーの例を表示するには、「」を参照してください[のアイデンティティベースのポリシーの例 AWS WAF](security_iam_id-based-policy-examples.md)。 ## 内のリソースベースのポリシー AWS WAF **リソースベースのポリシーのサポート:** ありリソースベースのポリシーは、リソースに添付する 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)を参照してください。 AWS WAF はリソースベースのポリシーを使用して、アカウント間のルールグループの共有をサポートします。リソースベースのポリシー設定を AWS WAF API コールまたは同等の CLI `PutPermissionPolicy`または SDK コールに提供することで、所有するルールグループを別の AWS アカウントと共有します。その他の利用可能な言語の例やドキュメントへのリンクなどの詳細については、 AWS WAF API リファレンスの[PutPermissionPolicy](https://docs.aws.amazon.com/waf/latest/APIReference/API_PutPermissionPolicy.html)」を参照してください。この機能は、コンソールや CloudFormationなどの他の方法では使用できません。 ## のポリシーアクション AWS WAF **ポリシーアクションのサポート:** あり管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。 JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。それぞれの AWS WAF アクションとアクセス許可のリストを確認するには、*「サービス認可リファレンス*」の[AWS WAF V2 で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswafv2.html#awswafv2-actions-as-permissions)」を参照してください。のポリシーアクションは、アクションの前に次のプレフィックス AWS WAF を使用します。 ``` wafv2 ``` 単一のステートメントで複数のアクションを指定するには、アクションをカンマで区切ります。 ``` "Action": [ "wafv2:action1", "wafv2:action2" ] ``` ワイルドカード (\$1) を使用すると、複数のアクションを指定することができます。たとえば、で始 AWS WAF まるのすべてのアクションを指定するには`List`、次のアクションを含めます。 ``` "Action": "wafv2:List*" ``` AWS WAF アイデンティティベースのポリシーの例を表示するには、「」を参照してください[のアイデンティティベースのポリシーの例 AWS WAF](security_iam_id-based-policy-examples.md)。 ### 追加のアクセス許可設定が必要なアクション一部のアクションには、*「サービス認可リファレンス*」の[AWS WAF V2 で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswafv2.html#awswafv2-actions-as-permissions)」で完全に説明できないアクセス許可が必要です。このセクションは、追加のアクセス許可に関する情報を説明します。 **Topics** + [ #### `AssociateWebACL` のアクセス権限 ](#security_iam_action-AssociateWebACL) + [ #### `DisassociateWebACL` のアクセス権限 ](#security_iam_action-DisassociateWebACL) + [ #### `GetWebACLForResource` のアクセス権限 ](#security_iam_action-GetWebACLForResource) + [ #### `ListResourcesForWebACL` のアクセス権限 ](#security_iam_action-ListResourcesForWebACL) #### `AssociateWebACL` のアクセス権限このセクションでは、 AWS WAF アクション`AssociateWebACL` を使用してウェブ ACL をリソースに関連付けるために必要なアクセス許可の一覧を示します。 Amazon CloudFront ディストリビューションでは、このアクションの代わりに CloudFront アクション `UpdateDistribution` を使用してください。詳細については、「*Amazon CloudFront API リファレンス*」の「[UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)」を参照してください。 **Amazon API Gateway REST API** REST API リソースタイプ`SetWebACL`で API Gateway を呼び出し、保護パック (ウェブ ACL) でを呼び AWS WAF `AssociateWebACL`出すアクセス許可が必要です。 ``` { "Sid": "AssociateWebACL1", "Effect": "Allow", "Action": [ "wafv2:AssociateWebACL" ], "Resource": [ "arn:aws:wafv2:region:account-id:regional/webacl/*/*" ] }, { "Sid": "AssociateWebACL2", "Effect": "Allow", "Action": [ "apigateway:SetWebACL" ], "Resource": [ "arn:aws:apigateway:*::/restapis/*/stages/*" ] } ``` **Application Load Balancer** Application Load Balancer リソースタイプで `elasticloadbalancing:SetWebACL`アクションを呼び出し、保護パック (ウェブ ACL) `AssociateWebACL`でを呼び AWS WAF 出すアクセス許可が必要です。 ``` { "Sid": "AssociateWebACL1", "Effect": "Allow", "Action": [ "wafv2:AssociateWebACL" ], "Resource": [ "arn:aws:wafv2:region:account-id:regional/webacl/*/*" ] }, { "Sid": "AssociateWebACL2", "Effect": "Allow", "Action": [ "elasticloadbalancing:SetWebACL" ], "Resource": [ "arn:aws:elasticloadbalancing:*:account-id:loadbalancer/app/*/*" ] } ``` **AWS AppSync GraphQL API** GraphQL API リソースタイプでを呼び出し AWS AppSync `SetWebACL`、保護パック (ウェブ ACL) でを呼び AWS WAF `AssociateWebACL`出すアクセス許可が必要です。 ``` { "Sid": "AssociateWebACL1", "Effect": "Allow", "Action": [ "wafv2:AssociateWebACL" ], "Resource": [ "arn:aws:wafv2:region:account-id:regional/webacl/*/*" ] }, { "Sid": "AssociateWebACL2", "Effect": "Allow", "Action": [ "appsync:SetWebACL" ], "Resource": [ "arn:aws:appsync:*:account-id:apis/*" ] } ``` **Amazon Cognito ユーザープール** ユーザープールリソースタイプで Amazon Cognito `AssociateWebACL`アクションを呼び出し、保護パック (ウェブ ACL) でを呼び AWS WAF `AssociateWebACL`出すアクセス許可が必要です。 ``` { "Sid": "AssociateWebACL1", "Effect": "Allow", "Action": [ "wafv2:AssociateWebACL" ], "Resource": [ "arn:aws:wafv2:region:account-id:regional/webacl/*/*" ] }, { "Sid": "AssociateWebACL2", "Effect": "Allow", "Action": [ "cognito-idp:AssociateWebACL" ], "Resource": [ "arn:aws:cognito-idp:*:account-id:userpool/*" ] } ``` **AWS App Runner サービス** App Runner サービスリソースタイプで App Runner `AssociateWebACL`アクションを呼び出し、ウェブ ACL でを呼び AWS WAF `AssociateWebACL`出すアクセス許可が必要です。 ``` { "Sid": "AssociateWebACL1", "Effect": "Allow", "Action": [ "wafv2:AssociateWebACL" ], "Resource": [ "arn:aws:wafv2:region:account-id:regional/webacl/*/*" ] }, { "Sid": "AssociateWebACL2", "Effect": "Allow", "Action": [ "apprunner:AssociateWebAcl" ], "Resource": [ "arn:aws:apprunner:*:account-id:service/*/*" ] } ``` **AWS Verified Access インスタンス** Verified Access インスタンスリソースタイプで `ec2:AssociateVerifiedAccessInstanceWebAcl`アクションを呼び出し、ウェブ ACL でを呼び AWS WAF `AssociateWebACL`出すアクセス許可が必要です。 ``` { "Sid": "AssociateWebACL1", "Effect": "Allow", "Action": [ "wafv2:AssociateWebACL" ], "Resource": [ "arn:aws:wafv2:region:account-id:regional/webacl/*/*" ] }, { "Sid": "AssociateWebACL2", "Effect": "Allow", "Action": [ "ec2:AssociateVerifiedAccessInstanceWebAcl" ], "Resource": [ "arn:aws:ec2:*:account-id:verified-access-instance/*" ] } ``` #### `DisassociateWebACL` のアクセス権限このセクションでは、 AWS WAF アクション `DisassociateWebACL` を使用して保護パック (ウェブ ACL) とリソースの関連付けを解除するために必要なアクセス許可を一覧表示します。 Amazon CloudFront ディストリビューションでは、このアクションの代わりに、空の保護パック (ウェブ ACL) ID を持つ CloudFront アクション `UpdateDistribution` を使用してください。詳細については、「*Amazon CloudFront API リファレンス*」の「[UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)」を参照してください。 **Amazon API Gateway REST API** REST API リソースタイプで API ゲートウェイ `SetWebACL` を呼び出すアクセス許可が必要です。を呼び出すアクセス許可は必要ありません AWS WAF `DisassociateWebACL`。 ``` { "Sid": "DisassociateWebACL", "Effect": "Allow", "Action": [ "apigateway:SetWebACL" ], "Resource": [ "arn:aws:apigateway:*::/restapis/*/stages/*" ] } ``` **Application Load Balancer** Application Load Balancer リソースタイプで `elasticloadbalancing:SetWebACL` アクションを呼び出すアクセス許可が必要です。を呼び出すアクセス許可は必要ありません AWS WAF `DisassociateWebACL`。 ``` { "Sid": "DisassociateWebACL", "Effect": "Allow", "Action": [ "elasticloadbalancing:SetWebACL" ], "Resource": [ "arn:aws:elasticloadbalancing:*:account-id:loadbalancer/app/*/*" ] } ``` **AWS AppSync GraphQL API** GraphQL API リソースタイプでを呼び出す AWS AppSync `SetWebACL`アクセス許可が必要です。を呼び出すアクセス許可は必要ありません AWS WAF `DisassociateWebACL`。 ``` { "Sid": "DisassociateWebACL", "Effect": "Allow", "Action": [ "appsync:SetWebACL" ], "Resource": [ "arn:aws:appsync:*:account-id:apis/*" ] } ``` **Amazon Cognito ユーザープール** ユーザープールリソースタイプで Amazon Cognito `DisassociateWebACL`アクションを呼び出し、を呼び出すアクセス許可が必要です AWS WAF `DisassociateWebACL`。 ``` { "Sid": "DisassociateWebACL1", "Effect": "Allow", "Action": "wafv2:DisassociateWebACL", "Resource": "*" }, { "Sid": "DisassociateWebACL2", "Effect": "Allow", "Action": [ "cognito-idp:DisassociateWebACL" ], "Resource": [ "arn:aws:cognito-idp:*:account-id:userpool/*" ] } ``` **AWS App Runner サービス** App Runner サービスリソースタイプで App Runner `DisassociateWebACL`アクションを呼び出し、を呼び出すアクセス許可が必要です AWS WAF `DisassociateWebACL`。 ``` { "Sid": "DisassociateWebACL1", "Effect": "Allow", "Action": "wafv2:DisassociateWebACL", "Resource": "*" }, { "Sid": "DisassociateWebACL2", "Effect": "Allow", "Action": [ "apprunner:DisassociateWebAcl" ], "Resource": [ "arn:aws:apprunner:*:account-id:service/*/*" ] } ``` **AWS Verified Access インスタンス** Verified Access インスタンスリソースタイプで `ec2:DisassociateVerifiedAccessInstanceWebAcl`アクションを呼び出し、を呼び出すアクセス許可が必要です AWS WAF `DisassociateWebACL`。 ``` { "Sid": "DisassociateWebACL1", "Effect": "Allow", "Action": "wafv2:DisassociateWebACL", "Resource": "*" }, { "Sid": "DisassociateWebACL2", "Effect": "Allow", "Action": [ "ec2:DisassociateVerifiedAccessInstanceWebAcl" ], "Resource": [ "arn:aws:ec2:*:account-id:verified-access-instance/*" ] } ``` #### `GetWebACLForResource` のアクセス権限このセクションでは、 AWS WAF アクション `GetWebACLForResource` を使用して保護対象リソースの保護パック (ウェブ ACL) を取得するために必要なアクセス許可の一覧を示します。 Amazon CloudFront ディストリビューションでは、このアクションの代わりに CloudFront アクション `GetDistributionConfig` を使用してください。詳細については、「*Amazon CloudFront API リファレンス*」の「[GetDistributionConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_GetDistributionConfig.html)」を参照してください。 **注記** `GetWebACLForResource` によって `GetWebACL` を呼び出すにはアクセス許可が必要です。このコンテキストでは、は、が`GetWebACLForResource`返す保護パック (ウェブ ACL) にアクセスするために必要なアクセス許可がアカウントにあることを検証するために`GetWebACL`のみ AWS WAF 使用します。を呼び出すと`GetWebACLForResource`、アカウントが resource `wafv2:GetWebACL`に対して実行する権限がないことを示すエラーが表示されることがあります。このタイプのエラーは AWS CloudTrail イベント履歴に追加 AWS WAF されません。 **Amazon API Gateway REST API、Application Load Balancer、 AWS AppSync GraphQL API** 保護パック (ウェブ ACL) `GetWebACL` のとを呼び AWS WAF `GetWebACLForResource`出すアクセス許可が必要です。 ``` { "Sid": "GetWebACLForResource", "Effect": "Allow", "Action": [ "wafv2:GetWebACLForResource", "wafv2:GetWebACL" ], "Resource": [ "arn:aws:wafv2:region:account-id:regional/webacl/*/*" ] } ``` **Amazon Cognito ユーザープール** ユーザープールリソースタイプで Amazon Cognito `GetWebACLForResource`アクションを呼び出し、とを呼び AWS WAF `GetWebACLForResource`出すアクセス許可が必要です`GetWebACL`。 ``` { "Sid": "GetWebACLForResource1", "Effect": "Allow", "Action": [ "wafv2:GetWebACLForResource", "wafv2:GetWebACL" ], "Resource": [ "arn:aws:wafv2:region:account-id:regional/webacl/*/*" ] }, { "Sid": "GetWebACLForResource2", "Effect": "Allow", "Action": [ "cognito-idp:GetWebACLForResource" ], "Resource": [ "arn:aws:cognito-idp:*:account-id:userpool/*" ] } ``` **AWS App Runner サービス** App Runner サービスリソースタイプで App Runner `DescribeWebAclForService`アクションを呼び出し、 `GetWebACLForResource` とを呼び AWS WAF 出すアクセス許可が必要です`GetWebACL`。 ``` { "Sid": "GetWebACLForResource1", "Effect": "Allow", "Action": [ "wafv2:GetWebACLForResource", "wafv2:GetWebACL" ], "Resource": [ "arn:aws:wafv2:region:account-id:regional/webacl/*/*" ] }, { "Sid": "GetWebACLForResource2", "Effect": "Allow", "Action": [ "apprunner:DescribeWebAclForService" ], "Resource": [ "arn:aws:apprunner:*:account-id:service/*/*" ] } ``` **AWS Verified Access インスタンス** Verified Access インスタンスリソースタイプで `ec2:GetVerifiedAccessInstanceWebAcl`アクションを呼び出し、とを呼び AWS WAF `GetWebACLForResource`出すアクセス許可が必要です`GetWebACL`。 ``` { "Sid": "GetWebACLForResource1", "Effect": "Allow", "Action": [ "wafv2:GetWebACLForResource", "wafv2:GetWebACL" ], "Resource": [ "arn:aws:wafv2:region:account-id:regional/webacl/*/*" ] }, { "Sid": "GetWebACLForResource2", "Effect": "Allow", "Action": [ "ec2:GetVerifiedAccessInstanceWebAcl" ], "Resource": [ "arn:aws:ec2:*:account-id:verified-access-instance/*" ] } ``` #### `ListResourcesForWebACL` のアクセス権限このセクションには、 AWS WAF アクション `ListResourcesForWebACL` を使用して保護パック (ウェブ ACL) の保護対象リソースのリストを取得するために必要なアクセス許可の一覧が記載されています。 Amazon CloudFront ディストリビューションでは、このアクションの代わりに CloudFront アクション `ListDistributionsByWebACLId` を使用してください。詳細については、「*Amazon CloudFront API リファレンス*」の「[ListDistributionsByWebACLId](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListDistributionsByWebACLId.html)」を参照してください。 **Amazon API Gateway REST API、Application Load Balancer、 AWS AppSync GraphQL API** ウェブ ACL のを呼び AWS WAF `ListResourcesForWebACL`出すアクセス許可が必要です。 ``` { "Sid": "ListResourcesForWebACL", "Effect": "Allow", "Action": [ "wafv2:ListResourcesForWebACL" ], "Resource": [ "arn:aws:wafv2:region:account-id:regional/webacl/*/*" ] } ``` **Amazon Cognito ユーザープール** ユーザープールリソースタイプで Amazon Cognito `ListResourcesForWebACL` アクションを呼び出し、 AWS WAF `ListResourcesForWebACL` を呼び出すためのアクセス許可が必要です。 ``` { "Sid": "ListResourcesForWebACL1", "Effect": "Allow", "Action": [ "wafv2:ListResourcesForWebACL" ], "Resource": [ "arn:aws:wafv2:region:account-id:regional/webacl/*/*" ] }, { "Sid": "ListResourcesForWebACL2", "Effect": "Allow", "Action": [ "cognito-idp:ListResourcesForWebACL" ], "Resource": [ "arn:aws:cognito-idp:*:account-id:userpool/*" ] } ``` **AWS App Runner サービス** App Runner サービスリソースタイプで App Runner `ListAssociatedServicesForWebAcl`アクションを呼び出し、を呼び出すアクセス許可が必要です AWS WAF `ListResourcesForWebACL`。 ``` { "Sid": "ListResourcesForWebACL1", "Effect": "Allow", "Action": [ "wafv2:ListResourcesForWebACL" ], "Resource": [ "arn:aws:wafv2:region:account-id:regional/webacl/*/*" ] }, { "Sid": "ListResourcesForWebACL2", "Effect": "Allow", "Action": [ "apprunner:ListAssociatedServicesForWebAcl" ], "Resource": [ "arn:aws:apprunner:*:account-id:service/*/*" ] } ``` **AWS Verified Access インスタンス** 検証済みアクセスインスタンスのリソースタイプで `ec2:DescribeVerifiedAccessInstanceWebAclAssociations` アクションを呼び出すには、 AWS WAF `ListResourcesForWebACL` を呼び出すためのアクセス許可が必要です。 ``` { "Sid": "ListResourcesForWebACL1", "Effect": "Allow", "Action": [ "wafv2:ListResourcesForWebACL" ], "Resource": [ "arn:aws:wafv2:region:account-id:regional/webacl/*/*" ] }, { "Sid": "ListResourcesForWebACL2", "Effect": "Allow", "Action": [ "ec2:DescribeVerifiedAccessInstanceWebAclAssociations" ], "Resource": [ "arn:aws:ec2:*:account-id:verified-access-instance/*" ] } ``` ## のポリシーリソース AWS WAF **ポリシーリソースのサポート:** あり管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件**下で**アクション**を実行できるかということです。 `Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。リソースレベルのアクセス許可をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (\$1) を使用します。 ``` "Resource": "*" ``` AWS WAF リソースタイプとその ARNs[AWS WAF V2 で定義されるリソース](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswafv2.html#awswafv2-resources-for-iam-policies)」を参照してください。 **各リソースの ARN を指定できるアクションについては、[AWS WAF V2 で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswafv2.html#awswafv2-actions-as-permissions)」を参照してください。 AWS WAF リソースのサブセットへのアクセスを許可または拒否するには、ポリシーの `resource`要素にリソースの ARN を含めます。リソースの AWS WAF `wafv2` ARNs の形式は次のとおりです。 ``` arn:partition:wafv2: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 ディストリビューションの保護に使用する AWS WAF リソースの場合は、これをに設定します`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 インスタンスです。 + *リソースタイプ*: 次の値のいずれかを指定します。`webacl`、`rulegroup`、`ipset`、`regexpatternset`、`managedruleset`。 + *resource-name*: AWS WAF リソースに付けた名前を指定、あるいは ARN の他の仕様を満たすすべてのリソースを示すワイルドカード (`*`) を指定します。リソース名とリソース ID のどちらかを指定するか、両方にワイルドカードを指定する必要があります。 + *resource-id*: AWS WAF リソースの 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 ``` AWS WAF アイデンティティベースのポリシーの例を表示するには、「」を参照してください[のアイデンティティベースのポリシーの例 AWS WAF](security_iam_id-based-policy-examples.md)。 ## のポリシー条件キー AWS WAF **サービス固有のポリシー条件キーのサポート:** あり管理者は 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)」を参照してください。さらに、は、IAM ポリシーにきめ細かなフィルタリングを提供するために使用できる以下の条件キー AWS WAF をサポートしています。 + **wafv2:LogDestinationResource** この条件キーは、ログ記録の送信先の Amazon リソースネーム (ARN) 仕様を取得します。これは、REST API コール `PutLoggingConfiguration` を使用する際に、ログ送信先として指定する ARN です。 ARN を明示的に指定し、ARN のフィルタリングを指定できます。次の例では、特定の位置とプレフィックスを持つ Amazon S3 バケット ARN のフィルタリングを指定します。 ``` "Condition": { "ArnLike": { "wafv2:LogDestinationResource": "arn:aws:s3:::aws-waf-logs-suffix/custom-prefix/*" } } ``` + **wafv2:LogScope** この条件キーは、文字列内のログ記録設定のソースを定義します。現在、これは常にのデフォルトに設定されています。これは `Customer`、ログ記録の送信先がユーザーによって所有および管理されていることを示します。 AWS WAF 条件キーのリストを確認するには、*「サービス認可リファレンス*[」の AWS WAF V2 の条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswafv2.html#awswafv2-policy-keys)」を参照してください。条件キーを使用できるアクションとリソースについては、[AWS WAF V2 で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswafv2.html#awswafv2-actions-as-permissions)」を参照してください。 AWS WAF アイデンティティベースのポリシーの例を表示するには、「」を参照してください[のアイデンティティベースのポリシーの例 AWS WAF](security_iam_id-based-policy-examples.md)。 ## ACLs AWS WAF **ACL のサポート:** なしアクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。 ## を使用した ABAC AWS WAF **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)」を参照してください。 ## での一時的な認証情報の使用 AWS WAF **一時的な認証情報のサポート:** あり一時的な認証情報は 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)」を参照してください。 ## サービスの転送アクセスセッション AWS WAF **転送アクセスセッション (FAS) のサポート:** あり転送アクセスセッション (FAS) は、を呼び出すプリンシパルのアクセス許可と AWS のサービス、ダウンストリームサービス AWS のサービスへのリクエストをリクエストするを使用します。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。 ## のサービスロール AWS WAF **サービスロールのサポート:** ありサービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受ける [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)を参照してください。 **警告** サービスロールのアクセス許可を変更すると、 AWS WAF 機能が破損する可能性があります。 AWS WAF が指示する場合にのみ、サービスロールを編集します。 ## のサービスにリンクされたロール AWS WAF **サービスリンクロールのサポート:** ありサービスにリンクされたロールは、にリンクされたサービスロールの一種です AWS のサービス。サービスは、ユーザーに代わってアクションを実行するロールを引き受けることができます。サービスにリンクされたロールはに表示され AWS アカウント、サービスによって所有されます。IAM 管理者は、サービスリンクロールのアクセス許可を表示できますが、編集することはできません。 AWS WAF サービスにリンクされたロールの作成または管理の詳細については、「」を参照してください[のサービスにリンクされたロールの使用 AWS WAF](using-service-linked-roles.md)。 # のアイデンティティベースのポリシーの例 AWS WAF このセクションでは、アイデンティティベースのポリシーの例を示します AWS WAF。デフォルトでは、ユーザーおよびロールには、 AWS WAF リソースを作成または変更する権限はありません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。これらのサンプルの JSON ポリシードキュメントを使用して IAM アイデンティティベースのポリシーを作成する方法については、「*IAM ユーザーガイド*」の「[IAM ポリシーを作成する (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)」を参照してください。各リソースタイプの ARN の形式など AWS WAF、で定義されるアクションとリソースタイプの詳細については、*「サービス認可リファレンス*」の[AWS WAF V2 のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswafv2.html)」を参照してください。 ARNs **Topics** + [ ## ポリシーに関するベストプラクティス ](#security_iam_service-with-iam-policy-best-practices) + [ ## AWS WAF コンソールの使用 ](#security_iam_id-based-policy-examples-console) + [ ## 自分の権限の表示をユーザーに許可する ](#security_iam_id-based-policy-examples-view-own-permissions) + [ ## 、CloudFront AWS WAF、および CloudWatch への読み取り専用アクセスを付与する ](#security_iam_id-based-policy-examples-read-only1) + [ ## 、CloudFront AWS WAF、および CloudWatch へのフルアクセスを付与する ](#security_iam_id-based-policy-examples-full-access1) + [ ## 単一のへのアクセスを許可する AWS アカウント ](#security_iam_id-based-policy-examples-access-to-account) + [ ## 単一の保護パック (ウェブ ACL) へのアクセスを付与する ](#security_iam_id-based-policy-examples-access-to-web-acl) + [ ## 保護パック (ウェブ ACL) およびルールグループに対して、CLI アクセス権を付与 ](#security_iam_id-based-policy-examples-cli-access-to-web-acl) ## ポリシーに関するベストプラクティス ID ベースのポリシーは、アカウント内の AWS WAF リソースを作成、アクセス、または削除できるかどうかを決定します。これらのアクションでは、 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) を参照してください。 ## AWS WAF コンソールの使用 AWS WAF コンソールにアクセスするには、最小限のアクセス許可のセットが必要です。これらのアクセス許可により、の AWS WAF リソースの詳細を一覧表示および表示できます AWS アカウント。最小限必要な許可よりも制限が厳しいアイデンティティベースのポリシーを作成すると、そのポリシーを持つエンティティ (ユーザーまたはロール) に対してコンソールが意図したとおりに機能しません。 AWS CLI または AWS API のみを呼び出すユーザーには、最小限のコンソールアクセス許可を付与する必要はありません。代わりに、実行しようとしている API オペレーションに一致するアクションのみへのアクセスが許可されます。ユーザーとロールが AWS WAF コンソールを使用できるようにするには、少なくとも AWS WAF `AWSWAFConsoleReadOnlyAccess` AWS 管理ポリシーをエンティティにアタッチします。このマネージドポリシーの情報については、「[AWS マネージドポリシー: AWSWAFConsoleReadOnlyAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSWAFConsoleReadOnlyAccess)」を参照してください。マネージドポリシーをユーザーにアタッチする方法の詳細については、「*IAM ユーザーガイド*」の「[Adding permissions to a user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)」(ユーザーに許可の追加) を参照してください。 ## 自分の権限の表示をユーザーに許可するこの例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を 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": "*" } ] } ``` ## 、CloudFront AWS WAF、および CloudWatch への読み取り専用アクセスを付与する次のポリシーは、 AWS WAF リソース、Amazon CloudFront ウェブディストリビューション、および Amazon CloudWatch メトリクスへの読み取り専用アクセスをユーザーに付与します。これは、 AWS WAF 条件、ルール、保護パック (ウェブ ACLs) で設定を表示し、保護パック (ウェブ ACL) に関連付けられているディストリビューションを確認し、CloudWatch でメトリクスとリクエストのサンプルを監視するアクセス許可が必要なユーザーに役立ちます。これらのユーザーは、 AWS WAF リソースを作成、更新、または削除することはできません。 ``` { "Version": "2012-10-17", "Statement": [ { "Action": [ "wafv2:Get*", "wafv2:List*", "cloudfront:GetDistribution", "cloudfront:GetDistributionConfig", "cloudfront:ListDistributions", "cloudfront:ListDistributionsByWebACLId", "cloudfront:ListDistributionTenantsByCustomization", "cloudfront:ListDistributionTenants", "cloudfront:GetDistributionTenant", "cloudwatch:GetMetricData", "cloudwatch:ListMetrics", "cloudwatch:GetMetricStatistics", "ec2:DescribeRegions", "pricingplanmanager:GetSubscription", "pricingplanmanager:ListSubscriptions", "route53:ListHostedZones", "route53:GetHostedZone" ], "Effect": "Allow", "Resource": "*" } ] } ``` ## 、CloudFront AWS WAF、および CloudWatch へのフルアクセスを付与する次のポリシーでは、ユーザーは任意の AWS WAF オペレーションを実行し、CloudFront ウェブディストリビューションに対して任意のオペレーションを実行し、CloudWatch でメトリクスとリクエストのサンプルを監視できます。これは、 AWS WAF 管理者であるユーザーにとって便利です。 ``` { "Version": "2012-10-17", "Statement": [ { "Action": [ "wafv2:*", "cloudfront:CreateDistribution", "cloudfront:ListDistributions", "cloudfront:ListDistributionsByWebACLId", "cloudfront:UpdateDistribution", "cloudfront:GetDistributionConfig", "cloudfront:GetDistribution", "cloudfront:DisassociateDistributionTenantWebACL", "cloudfront:DisassociateDistributionWebACL", "cloudfront:AssociateDistributionTenantWebACL", "cloudfront:AssociateDistributionWebACL", "cloudfront:ListDistributionTenantsByCustomization", "cloudfront:ListDistributionTenants", "cloudfront:DeleteDistribution", "cloudfront:GetDistributionTenant", "cloudfront:DeleteDistributionTenant", "cloudwatch:GetMetricData", "cloudwatch:ListMetrics", "cloudwatch:GetMetricStatistics", "ec2:DescribeRegions", "pricingplanmanager:GetSubscription", "pricingplanmanager:ListSubscriptions", "pricingplanmanager:UpdateSubscription", "pricingplanmanager:CancelSubscription", "pricingplanmanager:CancelSubscriptionChange", "pricingplanmanager:AssociateResourcesToSubscription", "pricingplanmanager:DisassociateResourcesFromSubscription", "route53:ListHostedZones", "route53:GetHostedZone" ], "Effect": "Allow", "Resource": "*" } ] } ``` 管理者許可を持つユーザーに対しては多要素認証 (MFA) を設定することを強くお勧めします。詳細については、「*IAM ユーザーガイド*」の「[AWSでの多要素認証 (MFA) デバイスの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/Using_ManagingMFA.html)」を参照してください。 ## 単一のへのアクセスを許可する AWS アカウントこのポリシーは、アカウント 444455556666 に次の許可を付与します。 + すべての AWS WAF オペレーションとリソースへのフルアクセス。 + 保護パック (ウェブ ACL) と CloudFront ディストリビューションを関連付けるための、すべての CloudFront ディストリビューションへの読み取りおよび更新アクセス。 + すべての CloudWatch メトリクスとメトリクス統計への読み取りアクセスにより、 AWS WAF コンソールで CloudWatch データおよびリクエストのサンプルを表示できます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "wafv2:*" ], "Resource": [ "arn:aws:wafv2:us-east-1:444455556666:*" ] }, { "Effect": "Allow", "Action": [ "cloudfront:GetDistribution", "cloudfront:GetDistributionConfig", "cloudfront:ListDistributions", "cloudfront:ListDistributionsByWebACLId", "cloudfront:UpdateDistribution", "cloudwatch:ListMetrics", "cloudwatch:GetMetricStatistics", "ec2:DescribeRegions" ], "Resource": [ "*" ] } ] } ``` ------ ## 単一の保護パック (ウェブ ACL) へのアクセスを付与する次のポリシーでは、ユーザーは、アカウント内の特定の保護パック (ウェブ ACL) でコンソールを介して任意の AWS WAF オペレーションを実行できます`444455556666`。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "wafv2:*" ], "Resource": [ "arn:aws:wafv2:us-east-1:444455556666:regional/webacl/test123/112233d7c-86b2-458b-af83-51c51example" ] }, { "Sid": "consoleAccess", "Effect": "Allow", "Action": [ "wafv2:ListWebACLs", "ec2:DescribeRegions" ], "Resource": [ "*" ] } ] } ``` ------ ## 保護パック (ウェブ ACL) およびルールグループに対して、CLI アクセス権を付与次のポリシーでは、ユーザーは、アカウント内の特定の保護パック (ウェブ ACL) と特定のルールグループに対して CLI を介して任意の AWS WAF オペレーションを実行できます`444455556666`。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "wafv2:*" ], "Resource": [ "arn:aws:wafv2:us-east-1:444455556666:regional/webacl/test123/112233d7c-86b2-458b-af83-51c51example", "arn:aws:wafv2:us-east-1:444455556666:regional/rulegroup/test123rulegroup/555555555-6666-1234-abcd-00d11example" ] } ] } ``` ------ 次のポリシーでは、ユーザーは、アカウント内の特定の保護パック (ウェブ ACL) でコンソールを介して任意の AWS WAF オペレーションを実行できます`444455556666`。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "wafv2:*" ], "Resource": [ "arn:aws:wafv2:us-east-1:444455556666:regional/webacl/test123/112233d7c-86b2-458b-af83-51c51example" ] }, { "Sid": "consoleAccess", "Effect": "Allow", "Action": [ "wafv2:ListWebACLs", "ec2:DescribeRegions" ], "Resource": [ "*" ] } ] } ``` ------ # AWS の管理ポリシー AWS WAF このセクションでは、の AWS 管理ポリシーを使用する方法について説明します AWS WAF。 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 マネージドポリシー: AWSWAFReadOnlyAccess このポリシーは、Amazon CloudFront、Amazon API Gateway、Application Load Balancer、 AWS AppSync Amazon Cognito、、Amazon AWS App Runner AWS Amplify Amazon CloudWatch、 AWS Verified Access などの統合サービスの AWS WAF リソースとリソースへのアクセスをユーザーに許可する読み取り専用アクセス許可を付与します。このポリシーを IAM ID にアタッチできます。は、ユーザーに代わってがアクションを実行できるようにするサービスロール AWS WAF にもこのポリシー AWS WAF をアタッチします。このポリシーの詳細については、IAM コンソールで「[AWSWAFReadOnlyAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFReadOnlyAccess$serviceLevelSummary)」を参照してください。 ## AWS マネージドポリシー: AWSWAFFullAccess このポリシーは、Amazon CloudFront、Amazon API Gateway、Application Load Balancer、、 AWS AppSync Amazon Cognito、 AWS App Runner、 AWS Amplify Amazon CloudWatch、 AWS Verified Access などの統合サービスの AWS WAF リソースとリソースへのフルアクセスを許可します。このポリシーを IAM ID にアタッチできます。は、ユーザーに代わってがアクションを実行できるようにするサービスロール AWS WAF にもこのポリシー AWS WAF をアタッチします。このポリシーの詳細については、IAM コンソールで「[AWSWAFFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFFullAccess$serviceLevelSummary)」を参照してください。 ## AWS マネージドポリシー: AWSWAFConsoleReadOnlyAccess このポリシーは、 AWS WAF コンソールに読み取り専用アクセス許可を付与します。これには、Amazon CloudFront、Amazon API Gateway、Application Load Balancer、 AWS AppSync Amazon Cognito、 AWS App Runner AWS Amplify、Amazon CloudWatch、 AWS Verified Access などの AWS WAF 統合サービスのおよびリソースが含まれます。このポリシーは IAM アイデンティティにアタッチできます。このポリシーの詳細については、IAM コンソールで「[AWSWAFConsoleReadOnlyAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFConsoleReadOnlyAccess$serviceLevelSummary)」を参照してください。 ## AWS マネージドポリシー: AWSWAFConsoleFullAccess このポリシーは、コンソールへのフルアクセスを許可します。 AWS WAF コンソールには、Amazon CloudFront、Amazon API Gateway、Application Load Balancer、 AWS AppSync Amazon Cognito、 AWS App Runner AWS Amplify、Amazon CloudWatch、 AWS Verified Access などの AWS WAF 統合サービスのリソースとリソースが含まれます。このポリシーを IAM ID にアタッチできます。は、ユーザーに代わってがアクションを実行できるようにするサービスロール AWS WAF にもこのポリシー AWS WAF をアタッチします。このポリシーの詳細については、IAM コンソールで「[AWSWAFConsoleFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFConsoleFullAccess$serviceLevelSummary)」を参照してください。 ## AWS マネージドポリシー: WAFV2LoggingServiceRolePolicy このポリシーにより、 AWS WAF は Amazon Data Firehose にログを書き込むことができます。このポリシーは、ログインを有効にした場合にのみ使用されます AWS WAF。このポリシーは、`AWSServiceRoleForWAFV2Logging` サービスにリンクされたロールにアタッチされます。サービスにリンクされたロールの詳細については、「[のサービスにリンクされたロールの使用 AWS WAF](using-service-linked-roles.md)」を参照してください。このポリシーの詳細については、IAM コンソールで「[WAFV2LoggingServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/WAFV2LoggingServiceRolePolicy$serviceLevelSummary)」を参照してください。 ## AWS WAF AWS 管理ポリシーの更新このサービスがこれらの変更の追跡を開始 AWS WAF してからのの AWS 管理ポリシーの更新に関する詳細を表示します。このページの変更に関する自動アラートについては、の AWS WAF ドキュメント履歴ページの RSS フィードにサブスクライブしてください[ドキュメント履歴](doc-history.md)。 | ポリシー | 変更点の説明 | 日付 | | --- | --- | --- | | `AWSWAFConsoleFullAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS コンソールリソースやその他の AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFConsoleFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFConsoleFullAccess$serviceLevelSummary)。 | CloudFront 料金プランに次のアクセス許可を追加しました。詳細については、「」を参照してください。 [CloudFront 定額料金プラン AWS WAF でのの使用](cloudfront-features.md#waf-cf-pricing-plans) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/security-iam-awsmanpol.html) | 2025-11-18 | | `AWSWAFConsoleReadOnlyAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS コンソールリソースやその他の AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFConsoleReadOnlyAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFConsoleReadOnlyAccess$serviceLevelSummary)。 | CloudFront 料金プランに次のアクセス許可を追加しました。詳細については、「」を参照してください。 [CloudFront 定額料金プラン AWS WAF でのの使用](cloudfront-features.md#waf-cf-pricing-plans) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/security-iam-awsmanpol.html) | 2025-11-18 | | `AWSWAFConsoleReadOnlyAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS コンソールリソースやその他の AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFConsoleReadOnlyAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFConsoleReadOnlyAccess$serviceLevelSummary)。 | 以下のアクセス許可が更新されました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/security-iam-awsmanpol.html) 以下の権限を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/security-iam-awsmanpol.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/security-iam-awsmanpol.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/security-iam-awsmanpol.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/security-iam-awsmanpol.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/security-iam-awsmanpol.html) | 2025-11-03 | | `AWSWAFConsoleFullAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS コンソールリソースやその他の AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFConsoleFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFConsoleFullAccess$serviceLevelSummary)。 | 以下のアクセス許可が更新されました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/security-iam-awsmanpol.html) 以下の権限を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/security-iam-awsmanpol.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/security-iam-awsmanpol.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/security-iam-awsmanpol.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/security-iam-awsmanpol.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/security-iam-awsmanpol.html) | 2025-11-03 | | `AWSWAFFullAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFFullAccess$serviceLevelSummary)。 | に必要なアクセス許可 AssociateWebACL、DisassociateWebACL、GetWebACLForResource、および ListResourcesForWebACL を追加しました AWS Amplify。 | 2025-05-05 | | `AWSWAFReadOnlyAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS リソースを管理できます。このポリシーの詳細については、IAM コンソールで「[AWSWAFReadOnlyAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFReadOnlyAccess$serviceLevelSummary)」を参照してください。 | に必要な GetWebACLForResource および ListResourcesForWebACL のアクセス許可を追加しました AWS Amplify。 | 2025-05-05 | | `AWSWAFConsoleReadOnlyAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS コンソールリソースやその他の AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFConsoleReadOnlyAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFConsoleReadOnlyAccess$serviceLevelSummary)。 | 以下の権限を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/security-iam-awsmanpol.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/security-iam-awsmanpol.html) | 2025-05-05 | | `AWSWAFConsoleFullAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS コンソールリソースやその他の AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFConsoleFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFConsoleFullAccess$serviceLevelSummary)。 | 以下の権限を追加しました。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/security-iam-awsmanpol.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/security-iam-awsmanpol.html) | 2025-05-05 | | `WAFV2LoggingServiceRolePolicy` このポリシーにより、 AWS WAF は Amazon Data Firehose にログを書き込むことができます。これは、ログ記録を有効にする場合にのみ使用されます。 IAM コンソールの詳細: [WAFV2LoggingServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/WAFV2LoggingServiceRolePolicy$serviceLevelSummary)。 | このポリシーがアタッチされているサービスにリンクされたロールのアクセス権限設定にステートメント ID (Sid) を追加しました。 | 2024-06-03 | | `AWSServiceRoleForWAFV2Logging` このサービスにリンクされたロールは、が Amazon Data Firehose AWS WAF にログを書き込むことを許可するアクセス許可ポリシーを提供します。 IAM コンソールの詳細: [AWSServiceRoleForWAFV2Logging](https://console.aws.amazon.com/iam/home#/roles/details/AWSServiceRoleForWAFV2Logging)。 | アクセス権限設定にステートメント ID (Sid) を追加しました。 | 2024-06-03 | | AWS WAF 変更追跡へのの追加 | AWS WAF は、管理ポリシー`WAFV2LoggingServiceRolePolicy`とサービスにリンクされたロールの変更の追跡を開始しました`AWSServiceRoleForWAFV2Logging`。 | 2024-06-03 | | `AWSWAFFullAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFFullAccess$serviceLevelSummary)。 | 保護できるリソースタイプに AWS Verified Access インスタンスを追加するアクセス許可を拡張しました AWS WAF。 | 2023-06-17 | | `AWSWAFReadOnlyAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS リソースを管理できます。 IAM コンソールの詳細: 「[AWSWAFReadOnlyAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFReadOnlyAccess$serviceLevelSummary)」 | 保護できるリソースタイプに AWS Verified Access インスタンスを追加するアクセス許可を拡張しました AWS WAF。 | 2023-06-17 | | `AWSWAFConsoleFullAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS コンソールリソースやその他の AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFConsoleFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFConsoleFullAccess$serviceLevelSummary)。 | 保護できるリソースタイプに AWS Verified Access インスタンスを追加するアクセス許可を拡張しました AWS WAF。 | 2023-06-17 | | `AWSWAFConsoleReadOnlyAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS コンソールリソースやその他の AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFConsoleReadOnlyAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFConsoleReadOnlyAccess$serviceLevelSummary)。 | 保護できるリソースタイプに AWS Verified Access インスタンスを追加するアクセス許可を拡張しました AWS WAF。 | 2023-06-17 | | `AWSWAFFullAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFFullAccess$serviceLevelSummary)。 | AWS App Runner サービスのアクセス設定を修正するためのアクセス許可を拡張しました。 | 2023-06-06 | | `AWSWAFReadOnlyAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS リソースを管理できます。 IAM コンソールの詳細: 「[AWSWAFReadOnlyAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFReadOnlyAccess$serviceLevelSummary)」 | AWS App Runner サービスのアクセス設定を修正するためのアクセス許可を拡張しました。 | 2023-06-06 | | `AWSWAFConsoleFullAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS コンソールリソースやその他の AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFConsoleFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFConsoleFullAccess$serviceLevelSummary)。 | AWS App Runner サービスのアクセス設定を修正するためのアクセス許可を拡張しました。 | 2023-06-06 | | `AWSWAFConsoleReadOnlyAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS コンソールリソースやその他の AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFConsoleReadOnlyAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFConsoleReadOnlyAccess$serviceLevelSummary)。 | AWS App Runner サービスのアクセス設定を修正するためのアクセス許可を拡張しました。 | 2023-06-06 | | `AWSWAFFullAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFFullAccess$serviceLevelSummary)。 | 保護できるリソースタイプに AWS App Runner サービスを追加するためのアクセス許可を拡張しました AWS WAF。 | 2023-03-30 | | `AWSWAFReadOnlyAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS リソースを管理できます。 IAM コンソールの詳細: 「[AWSWAFReadOnlyAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFReadOnlyAccess$serviceLevelSummary)」 | 保護できるリソースタイプに AWS App Runner サービスを追加するためのアクセス許可を拡張しました AWS WAF。 | 2023-03-30 | | `AWSWAFConsoleFullAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS コンソールリソースやその他の AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFConsoleFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFConsoleFullAccess$serviceLevelSummary)。 | 保護できるリソースタイプに AWS App Runner サービスを追加するためのアクセス許可を拡張しました AWS WAF。 | 2023-03-30 | | `AWSWAFConsoleReadOnlyAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS コンソールリソースやその他の AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFConsoleReadOnlyAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFConsoleReadOnlyAccess$serviceLevelSummary)。 | 保護できるリソースタイプに AWS App Runner サービスを追加するためのアクセス許可を拡張しました AWS WAF。 | 2023-03-30 | | `AWSWAFFullAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFFullAccess$serviceLevelSummary)。 | 保護できるリソースタイプに Amazon Cognito ユーザープールを追加するアクセス許可を拡張しました AWS WAF。 | 2022-08-25 | | `AWSWAFReadOnlyAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS リソースを管理できます。 IAM コンソールの詳細: 「[AWSWAFReadOnlyAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFReadOnlyAccess$serviceLevelSummary)」 | 保護できるリソースタイプに Amazon Cognito ユーザープールを追加するアクセス許可を拡張しました AWS WAF。 | 2022-08-25 | | `AWSWAFConsoleFullAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS コンソールリソースやその他の AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFConsoleFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFConsoleFullAccess$serviceLevelSummary)。 | 保護できるリソースタイプに Amazon Cognito ユーザープールを追加するアクセス許可を拡張しました AWS WAF。 | 2022-08-25 | | `AWSWAFConsoleReadOnlyAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS コンソールリソースやその他の AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFConsoleReadOnlyAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFConsoleReadOnlyAccess$serviceLevelSummary)。 | 保護できるリソースタイプに Amazon Cognito ユーザープールを追加するアクセス許可を拡張しました AWS WAF。 | 2022-08-25 | | `AWSWAFFullAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFFullAccess$serviceLevelSummary)。 | Amazon Simple Storage Service (Amazon S3) と Amazon CloudWatch Logs のログ配信の許可設定を修正しました。この変更により、ログ記録設定中に発生していたアクセス拒否エラーが解決されます。保護パック (ウェブ ACL) トラフィックのログ記録の詳細については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。 | 2022-01-11 | | `AWSWAFConsoleFullAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS コンソールリソースやその他の AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFConsoleFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFConsoleFullAccess$serviceLevelSummary)。 | Amazon Simple Storage Service (Amazon S3) と Amazon CloudWatch Logs のログ配信の許可設定を修正しました。この変更により、ログ記録設定中に発生していたアクセスエラーが解決されます。保護パック (ウェブ ACL) トラフィックのログ記録の詳細については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。 | 2022-01-11 | | `AWSWAFFullAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFFullAccess$serviceLevelSummary)。 | 拡張ログ記録オプション用の新しい許可を追加しました。この変更により、追加のログ記録先 Amazon Simple Storage Service (Amazon S3) と Amazon CloudWatch Logs AWS WAF にアクセスできます。保護パック (ウェブ ACL) トラフィックのログ記録の詳細については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。 | 2021-11-15 | | `AWSWAFConsoleFullAccess` このポリシーにより AWS WAF 、は AWS WAF および統合サービスでユーザーに代わって AWS コンソールリソースやその他の AWS リソースを管理できます。 IAM コンソールの詳細: [AWSWAFConsoleFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSWAFConsoleFullAccess$serviceLevelSummary)。 | 拡張ログ記録オプション用の新しい許可を追加しました。この変更により、追加のログ記録先 Amazon Simple Storage Service (Amazon S3) と Amazon CloudWatch Logs AWS WAF にアクセスできます。保護パック (ウェブ ACL) トラフィックのログ記録の詳細については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。 | 2021-11-15 | | AWS WAF が変更の追跡を開始しました | AWS WAF は、 AWS 管理ポリシーの変更の追跡を開始しました。 | 2021-3-01 | # AWS WAF ID とアクセスのトラブルシューティング以下の情報は、および IAM の使用時に発生する可能性がある一般的な問題の診断 AWS WAF と修正に役立ちます。 **Topics** + [ ## でアクションを実行する権限がありません AWS WAF ](#security_iam_troubleshoot-no-permissions) + [ ## iam:PassRole を実行する権限がありません ](#security_iam_troubleshoot-passrole) + [ ## 自分の以外のユーザーに自分の AWS WAF リソース AWS アカウントへのアクセスを許可したい ](#security_iam_troubleshoot-cross-account-access) ## でアクションを実行する権限がありません AWS WAF アクションを実行する権限がないというエラーが表示された場合は、そのアクションを実行できるようにポリシーを更新する必要があります。次のエラー例は、`mateojackson` IAM ユーザーがコンソールを使用して、ある `my-example-widget` リソースに関する詳細情報を表示しようとしたことを想定して、その際に必要な `wafv2:GetWidget` アクセス許可を持っていない場合に発生するものです。 ``` User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: wafv2:GetWidget on resource: my-example-widget ``` この場合、`wafv2:GetWidget` アクションを使用して `my-example-widget` リソースへのアクセスを許可するように、`mateojackson` ユーザーのポリシーを更新する必要があります。サポートが必要な場合は、 AWS 管理者にお問い合わせください。サインイン認証情報を提供した担当者が管理者です。 ## iam:PassRole を実行する権限がありません `iam:PassRole` アクションを実行する権限がないというエラーが表示された場合は、ポリシーを更新して AWS WAFにロールを渡すことができるようにする必要があります。一部の AWS のサービスでは、新しいサービスロールまたはサービスにリンクされたロールを作成する代わりに、既存のロールをそのサービスに渡すことができます。そのためには、サービスにロールを渡す権限が必要です。以下の例のエラーは、`marymajor` という IAM ユーザーがコンソールを使用して AWS WAFでアクションを実行しようとする場合に発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与された権限が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。 ``` User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole ``` この場合、Mary のポリシーを更新してメアリーに `iam:PassRole` アクションの実行を許可する必要があります。サポートが必要な場合は、 AWS 管理者にお問い合わせください。サインイン資格情報を提供した担当者が管理者です。 ## 自分の以外のユーザーに自分の AWS WAF リソース AWS アカウントへのアクセスを許可したい他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。詳細については、以下を参照してください: + がこれらの機能 AWS WAF をサポートしているかどうかを確認するには、「」を参照してください[が IAM と AWS WAF 連携する方法](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/access_policies-cross-account-resource-access.html)」を参照してください。 # のサービスにリンクされたロールの使用 AWS WAF このセクションでは、サービスにリンクされたロールを使用して、アカウント AWS 内のリソース AWS WAF へのアクセスを許可する方法について説明します。 AWS WAF は 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)を使用します。サービスにリンクされたロールは、直接リンクされた一意のタイプの IAM ロールです AWS WAF。サービスにリンクされたロールはによって事前定義 AWS WAF されており、サービスがユーザーに代わって他の AWS サービスを呼び出すために必要なすべてのアクセス許可が含まれています。サービスにリンクされたロールを使用すると、必要なアクセス許可を手動で追加する必要がなくなるため、の設定 AWS WAF が簡単になります。は、サービスにリンクされたロールのアクセス許可 AWS WAF を定義し、特に定義されている場合を除き、のみがそのロールを引き受け AWS WAF ることができます。定義された許可には、信頼ポリシーと許可ポリシーが含まれます。この許可ポリシーを他の IAM エンティティにアタッチすることはできません。サービスにリンクされたロールを削除するには、まずそのロールの関連リソースを削除します。これにより、 AWS WAF リソースへのアクセス許可が誤って削除されないため、リソースが保護されます。サービスにリンクされたロールをサポートする他のサービスについては、「[IAM と連携するAWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照して、**サービスにリンクされたロール**列が**はい**になっているサービスを見つけてください。サービスにリンクされた役割に関するドキュメントをサービスで表示するには[**はい**] リンクを選択してください。 ## のサービスにリンクされたロールのアクセス許可 AWS WAF AWS WAF は、サービスにリンクされたロール`AWSServiceRoleForWAFV2Logging`を使用して Amazon Data Firehose にログを書き込みます。このロールは、ログインを有効にした場合にのみ使用されます AWS WAF。ログ作成の詳細については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。このサービスにリンクされたロールは、 AWS マネージドポリシーにアタッチされます`WAFV2LoggingServiceRolePolicy`。管理ポリシーの詳細については、「[AWS マネージドポリシー: WAFV2LoggingServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-WAFV2LoggingServiceRolePolicy)」を参照してください。 `AWSServiceRoleForWAFV2Logging` サービスにリンクされたロールは、ロール `wafv2.amazonaws.com` を引き受けるためにサービスを信頼します。ロールのアクセス許可ポリシーにより AWS WAF 、は指定されたリソースに対して次のアクションを実行できます。 + Amazon Data Firehose のアクション: `aws-waf-logs-` で始まる名前を持つ `PutRecord` および `PutRecordBatch` は Firehose データストリームリソースに対するアクション。例えば、`aws-waf-logs-us-east-2-analytics`。 + AWS Organizations アクション: Organizations 組織のリソース`DescribeOrganization`。 IAM コンソールのサービスにリンクされたロール全体を参照してください: [AWSServiceRoleForWAFV2Logging](https://console.aws.amazon.com/iam/home#/roles/details/AWSServiceRoleForWAFV2Logging)。サービスリンクロールの作成、編集、削除を IAM エンティティ (ユーザー、グループ、ロールなど) に許可するにはアクセス許可を設定する必要があります。詳細については、「*IAM ユーザーガイド*」の「[サービスリンクロールの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。 ## のサービスにリンクされたロールの作成 AWS WAF サービスリンクロールを手動で作成する必要はありません。で AWS WAF ログ記録を有効にするか AWS マネジメントコンソール、 AWS WAF CLI または AWS WAF API で`PutLoggingConfiguration`リクエストを行うと、によってサービスにリンクされたロールが自動的に AWS WAF 作成されます。ログ記録を有効化するためには、`iam:CreateServiceLinkedRole` 許可が必要です。このサービスリンクロールを削除した後で再度作成する必要が生じた場合は同じ方法でアカウントにロールを再作成できます。 AWS WAF ログ記録を有効にすると、によってサービスにリンクされたロールが再度 AWS WAF 作成されます。 ## のサービスにリンクされたロールの編集 AWS WAF AWS WAF では、`AWSServiceRoleForWAFV2Logging`サービスにリンクされたロールを編集することはできません。サービスリンクロールを作成すると、多くのエンティティによってロールが参照される可能性があるため、ロール名を変更することはできません。ただし、IAM を使用したロール記述の編集はできます。詳細については、「*IAM ユーザーガイド*」の「[サービスリンクロールの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。 ## のサービスにリンクされたロールの削除 AWS WAF サービスリンクロールを必要とする機能やサービスが不要になった場合は、ロールを削除することをお勧めします。そうすることで、積極的にモニタリングまたは保守されていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスリンクロールのリソースをクリーンアップする必要があります。 **注記** リソースを削除しようとしたときに AWS WAF サービスがロールを使用している場合、削除が失敗する可能性があります。失敗した場合は数分待ってから操作を再試行してください。 **で使用される AWS WAF リソースを削除するには `AWSServiceRoleForWAFV2Logging`** 1. AWS WAF コンソールで、すべてのウェブ ACL からログ記録を削除します。詳細については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。 1. API または CLI を使用して、ログ記録が有効化されている各ウェブ ACL に `DeleteLoggingConfiguration` リクエストを送信します。詳細については、「[AWS WAF API リファレンス](https://docs.aws.amazon.com/waf/latest/APIReference/Welcome.html)」を参照してください。 **IAM を使用して、サービスにリンクされたロールを手動で削除するには** `AWSServiceRoleForWAFV2Logging` サービスにリンクされたロールを削除するには、IAM コンソール、IAM CLI、または IAM API を使用します。詳細については、*IAM ユーザーガイド*の「[サービスにリンクされたロールの削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。 ## AWS WAF サービスにリンクされたロールでサポートされているリージョン AWS WAF は、サービスが利用可能なすべてのリージョンでサービスにリンクされたロールの使用をサポートします。詳細については、「[AWS WAF エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/waf.html)」を参照してください。 # でのログ記録とモニタリング AWS WAF このセクションでは、でイベントをモニタリングおよび応答するための AWS ツールを使用する方法について説明します AWS WAF。モニタリングは、および AWS WAF AWS ソリューションの信頼性、可用性、パフォーマンスを維持する上で重要な部分です。マルチポイント障害が発生した場合は、その障害をより簡単にデバッグできるように、 AWS ソリューションのすべての部分からモニタリングデータを収集する必要があります。には、 AWS WAF リソースをモニタリングし、潜在的なイベントに対応するための複数のツール AWS が用意されています。 **Amazon CloudWatch アラーム** Amazon CloudWatch アラームを使用して、指定した期間にわたって 1 つのメトリクスを確認します。メトリクスが指定されたしきい値を超えると、CloudWatch は Amazon SNS トピックまたは AWS Auto Scaling ポリシーに通知を送信します。詳細については、「[Amazon CloudWatch によるモニタリング](monitoring-cloudwatch.md)」を参照してください。 **AWS CloudTrail ログ** CloudTrail は、ユーザー、ロール、または AWS のサービスによって実行されたアクションの記録を提供します AWS WAF。CloudTrail によって収集された情報を使用して、リクエストの実行元の IP アドレス AWS WAF、リクエストの実行者、リクエストの実行日時などの詳細を確認できます。詳細については、「[での AWS CloudTrail API コールのログ記録](logging-using-cloudtrail.md)」を参照してください。 **AWS WAF 保護パック (ウェブ ACL) トラフィックのログ記録** AWS WAF は、保護パック (ウェブ ACLs) が分析するトラフィックのログ記録を提供します。ログには、保護された AWS リソースからリクエスト AWS WAF を受信した時間、リクエストに関する詳細情報、リクエストが一致したルールのアクション設定などの情報が含まれます。詳細については、「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」を参照してください。 # でのコンプライアンスの検証 AWS WAF このセクションでは、を使用する際のコンプライアンス責任について説明します AWS WAF。 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/)」を参照してください。 # でのレジリエンスの構築 AWS WAF このセクションでは、 AWS アーキテクチャがのデータ冗長性をサポートする方法について説明します AWS WAF。 AWS グローバルインフラストラクチャは、 AWS リージョンおよびアベイラビリティーゾーンを中心に構築されています。は、低レイテンシー、高スループット、高度に冗長なネットワークで接続された、物理的に分離および分離された複数のアベイラビリティーゾーン AWS リージョンを提供します。アベイラビリティーゾーンでは、アベイラビリティーゾーン間で中断せずに、自動的にフェイルオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、耐障害性、およびスケーラビリティが優れています。 AWS リージョンおよびアベイラビリティーゾーンの詳細については、[AWS 「グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。 # のインフラストラクチャセキュリティ AWS WAF このセクションでは、がサービストラフィックを AWS WAF 分離する方法について説明します。マネージドサービスである AWS WAF は、 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 コールを使用して、ネットワーク AWS WAF 経由でにアクセスします。クライアントは以下をサポートする必要があります。 + Transport Layer Security (TLS)。TLS 1.2 が必須で、TLS 1.3 をお勧めします。 + DHE (楕円ディフィー・ヘルマン鍵共有) や ECDHE (楕円曲線ディフィー・ヘルマン鍵共有) などの完全前方秘匿性 (PFS) による暗号スイート。これらのモードは、Java 7 以降など、最近のほとんどのシステムでサポートされています。 # AWS WAF クォータ **注記** これはの最新バージョンです AWS WAF。 AWS WAF Classic については、「」を参照してください[AWS WAF クラシック](classic-waf-chapter.md)。 AWS WAF には、次のクォータが適用されます (以前は制限と呼ばれていました）。これらのクォータは、が利用可能なすべてのリージョンで同じ AWS WAF です。各リージョンでは、これらのクォータが個別に適用されます。クォータは、リージョンにまたがって累積されません。 AWS WAF には、アカウントごとに保持できるエンティティの最大数に対するデフォルトのクォータがあります。このクォータの[引き上げをリクエスト](https://console.aws.amazon.com/servicequotas/home/services/wafv2/quotas)できます。 | リソース | 1 リージョン、1 アカウントあたりのデフォルトのクォータ | | --- | --- | | 保護パック (ウェブ ACL) の最大数 | 100 | | ルールグループの最大数 | 100 | | IP セットの最大数 | 100 | | 保護パック (ウェブ ACL) ごとの 1 秒あたりの最大リクエスト数 | 100,000 | | 保護パック (ウェブ ACL) またはルールグループあたりのカスタムリクエストヘッダーの最大数 | 100 | | 保護パック (ウェブ ACL) またはルールグループあたりのカスタムレスポンスヘッダーの最大数 | 100 | | 保護パック (ウェブ ACL) またはルールグループあたりのカスタムレスポンス本文の最大数 | 50 | | 保護パック (ウェブ ACL) トークンドメインリストのトークンドメインの最大数 | 10 | | 正規表現パターンセットの最大数 | 10 | | 保護パック (ウェブ ACL) あたりの Application Load Balancer の関連付けの最大数 | 100 | CloudFront AWS WAF でに許可される 1 秒あたりの最大リクエスト数 (RPS) は CloudFront によって設定され、[CloudFront デベロッパーガイド](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html)」で説明されています。 AWS WAF には、リージョンごとにアカウントごとに次のエンティティ設定に対する固定クォータがあります。これらのクォータは変更できません。 | リソース | 1 アカウント、1 リージョンあたりのクォータ | | --- | --- | | 保護パック (ウェブ ACL) あたりの最大保護パック (ウェブ ACL) キャパシティーユニット (WCU)\$1 | 5,000 | | ルールグループあたりの最大 WCU | 5,000 | | ルールグループあたりの参照ステートメントの最大数。ルールグループでは、参照ステートメントは IP セットまたは正規表現パターンセットを参照できます。 | 50 | | 保護パック (ウェブ ACL) あたりの参照ステートメントの最大数。保護パック (ウェブ ACL) では、参照ステートメントはルールグループ、IP セット、または正規表現パターンセットを参照できます。 | 50 | | IP セットあたりの CIDR 表記の IP アドレスの最大数 | 10,000 | | 保護パック (ウェブ ACL) あたりのレートベースのルールの最大数 | 10 | | ルールグループあたりのレートベースのルールの最大数 | 4 | | レートベースのルールに対して定義できる最小リクエスト率 | 10 | | レートベースのルールごとにレート制限できる一意の IP アドレスの最大数 | 10,000 | | 文字列一致ステートメントの最大文字数 | 200 | | 各正規表現パターンの最大文字数 | 200 | | 正規表現パターンセットあたりの一意の正規表現パターンの最大数 | 10 | | Application Load Balancer と AWS AppSync 保護を検査できるウェブリクエストボディの最大サイズ | 8 KB | | CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Access 保護について検査できるウェブリクエストボディの最大サイズ\$1\$1 | 64 KB | | ルールステートメントあたりのテキスト変換の最大数 | 10 | | 単一のカスタムレスポンス定義のカスタムレスポンス本文コンテンツの最大サイズ | 4 KB | | 1 つのカスタムレスポンス定義のカスタムヘッダーの最大数 | 10 | | 1 つのカスタムリクエスト定義のカスタムヘッダーの最大数 | 10 | | 単一のルールグループまたは単一の保護パック (ウェブ ACL) 用のすべてのレスポンス本文コンテンツの最大合計サイズ | 50 KB | | 1 つのルール内の地域一致国コードの最大数 | 50 | \$1保護パック (ウェブ ACL) で 1,500 WCU を超える容量を使用すると、保護パック (ウェブ ACL) の基本料金を超えるコストが発生します。詳細については、「[のウェブ ACL キャパシティユニット (WCUs) AWS WAF](aws-waf-capacity-units.md)」と「[AWS WAF 料金表](https://aws.amazon.com/waf/pricing/)」を参照してください。 \$1\$1デフォルトでは、CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Access リソースのボディ検査制限は 16 KB に設定されていますが、保護パック (ウェブ ACL) 設定のこれらのリソースのいずれについても、リストされている最大数まで引き上げることができます。詳細については、「[でのボディ検査の管理に関する考慮事項 AWS WAF](web-acl-setting-body-inspection-limit.md)」を参照してください。 AWS WAF には、リージョンごとのアカウントごとの呼び出しに対して次の固定クォータがあります。これらのクォータは、コンソール、CLI、 AWS CloudFormation、REST API、SDK など、利用可能な手段を通じてサービスへのコールの合計に適用されます。これらのクォータは変更できません。 | コールタイプ | 1 アカウント、1 リージョンあたりのクォータ | | --- | --- | | AssociateWebACL へのコールの最大数 | 2 秒あたり 1 回のリクエスト | | DisassociateWebACL へのコールの最大数 | 2 秒あたり 1 回のリクエスト | | GetWebACLForResource へのコールの最大数 | 1 秒あたり 1 回のリクエスト | | ListResourcesForWebACL へのコールの最大数 | 1 秒あたり 1 回のリクエスト | | GetDecryptedAPIKey へのコールの最大数 | 2 秒あたり 1 回のリクエスト | | 個々の Get または List アクションに対するコールの最大数 (他にクォータが定義されていない場合) | 1 秒あたり 5 回のリクエスト | | 個々の Create、Put、または Update アクションへのコールの最大数 (他にクォータが定義されていない場合) | 1 秒あたり 1 回のリクエスト | AWS WAF には、の 1 つの組織内のすべてのアカウントによる呼び出しに対して次の固定クォータがあります AWS Organizations。これらのクォータは、コンソール、CLI、 AWS CloudFormation、REST API、SDK など、利用可能な手段を通じてサービスへのコールの合計に適用されます。これらのクォータは変更できません。 | コールタイプ | 1 つのリージョンの組織あたりの配分 | | --- | --- | | 組織内のすべてのアカウントから ListResourcesForWebACL への呼び出しの最大数。米国東部 (バージニア北部) (us-east-1)、米国西部 (オレゴン) (us-west-2)、欧州 (アイルランド) (eu-west-1) の任意の 1 つのリージョンで使用できます。 | 1 秒あたり 12 リクエスト | | このテーブルに異なるクォータがリストされていない 1 つのリージョンにおける、組織内のすべてのアカウントから ListResourcesForWebACL への呼び出しの最大数。 | 1 秒あたり 6 リクエスト | # AWS WAF Classic リソースのへの移行 AWS WAF **警告** AWS WAF Classic は計画的なend-of-lifeプロセスを進めています。リージョン固有のマイルストーンと日付については、 AWS Health ダッシュボードを参照してください。 **注記** これは、**AWS WAF** ドキュメントです。このバージョンは、2019 年 11 月 AWS WAF より前にルールやウェブ ACLs などのリソースを作成し AWS WAF 、最新バージョンに移行していない場合にのみ使用してください。Web ACL を移行するには、[AWS WAF Classic リソースのへの移行 AWS WAF](#waf-migrating-from-classic) を参照してください。 **の最新バージョンについては、 AWS WAF**「」を参照してください[AWS WAF](waf-chapter.md)。このセクションでは、2019 年 11 月に AWS WAF AWS WAF リリースされた AWS WAF Classic からにルールと保護パック (ウェブ ACLs) を移行するためのガイダンスを提供します。 AWS WAF Classic を使用してルールや保護パック (ウェブ ACLs) などのリソースを作成した場合は、 AWS WAF Classic を使用してリソースを操作するか、この最新バージョンに移行する必要があります。 **警告** AWS WAF クラシックサポートは 2025 年 9 月 30 日に終了します。移行作業を開始する前に、 AWS WAF 「」の「」を参照してください[AWS WAF](waf-chapter.md)。 **Topics** + [ # に移行する理由 AWS WAF ](waf-migrating-why-migrate.md) + [ # 移行に関する注意事項と制限事項 ](waf-migrating-caveats.md) + [ # 移行の仕組み ](waf-migrating-how-it-works.md) + [ # AWS WAF Classic からへの保護パック (ウェブ ACL) の移行 AWS WAF ](waf-migrating-procedure.md) # に移行する理由 AWS WAF の最新バージョン AWS WAF では、以前のバージョンよりも多くの改善が加えられていますが、慣れている概念と用語のほとんどは維持されています。最新の AWS WAFの主な変更点を次に示します。移行を続行する前に、このリストを確認し、残りの AWS WAF ガイドをよく理解してください。 + ** AWS WAF Classic のサポートは 2025 年 9 月 30 日に終了します。 ** + **AWS のマネージドルール AWS WAF** – AWS マネージドルールを通じて利用できるルールグループは、一般的なウェブ脅威に対する保護を提供します。これらのルールグループのほとんどは、に無料で含まれています AWS WAF。詳細については、[AWS マネージドルールのルールグループリスト](aws-managed-rule-groups-list.md)「」およびブログ記事[「 AWS マネージドルールの発表 AWS WAF](https://aws.amazon.com/blogs/aws/announcing-aws-managed-rules-for-aws-waf/)」を参照してください。 + **新しい AWS WAF API** – 新しい API では、単一の APIs セットを使用してすべての AWS WAF リソースを設定できます。リージョン別アプリケーションとグローバルアプリケーションを区別するために、新しい API には `scope` 設定が含まれています。API の詳細については、「[AWS WAFV2 アクション](https://docs.aws.amazon.com/waf/latest/APIReference/API_Operations_AWS_WAFV2.html)」および「[AWS WAFV2 データ型](https://docs.aws.amazon.com/waf/latest/APIReference/API_Types_AWS_WAFV2.html)」を参照してください。 APIs では、SDKs、CLIs、および AWS CloudFormation、 AWS WAF Classic は命名スキームを保持し、この最新バージョンの AWS WAF は`v2`、コンテキストに応じて、 `V2`またはで参照されます。 + **サービスクォータ (制限) の簡素化** – AWS WAF 保護パック (ウェブ ACL) ごとにより多くのルールを許可し、より長い正規表現パターンを表現できるようになりました。詳細については、「[AWS WAF クォータ](limits.md)」を参照してください。 + **コンピューティングニーズが容量制限を決定する ** – 保護パック (ウェブ ACLs) の制限は、保護パック (ウェブ ACL) 容量ユニット (WCUs) に基づくようになりました。は、必要な運用容量に従ってルールの WCUs AWS WAF を計算します。保護パック (ウェブ ACL) の合計 WCU は、すべてのルールとルールグループからの WCU の合計に等しくなります。 WCU の一般情報については、「[の AWS WAF 仕組み](how-aws-waf-works.md)」を参照してください。各ルールの WCU の使用量については、「[でのルールステートメントの使用 AWS WAF](waf-rule-statements.md)」を参照してください。 + **ドキュメントベースのルールの記述** – ルール、ルールグループ、保護パック (ウェブ ACL) を JSON 形式で記述および表現できるようになりました。個々の API コールを使用してさまざまな条件を作成し、その条件をルールに関連付ける必要がなくなりました。これにより、コードの記述方法と保守方法が大幅に簡素化されます。保護パック (ウェブ ACL) を表示しているときに、**[保護パック (ウェブ ACL) を JSON としてダウンロード]** を選択することで、コンソールから保護パック (ウェブ ACL) の JSON 形式にアクセスできます。独自のルールを作成する場合は、**[Rule JSON editor]** (ルール JSON エディタ) を選択することで、その JSON 表現にアクセスできます。 + **ルールのネストと完全な論理オペレーションのサポート** - 論理ルールステートメントとネストを使用して、複雑な結合ルールを記述できます。`[A AND NOT(B OR C)]` などのステートメントを作成できます。詳細については、「[での論理ルールステートメントの使用 AWS WAF](waf-rule-statements-logical.md)」を参照してください。 + **レートベースのルールの改善** – の最新バージョンでは AWS WAF、ルールが評価する時間枠と、ルールがリクエストを集約する方法をカスタマイズできます。多数のウェブリクエスト特性を組み合わせて集計をカスタマイズできます。さらに、最新のレートベースのルールは、トラフィックの変化により迅速に対応します。詳細については、「[でのレートベースのルールステートメントの使用 AWS WAF](waf-rule-statement-type-rate-based.md)」を参照してください。 + **IP セットに対する可変 CIDR 範囲のサポート** - IP セット指定における IP 範囲の柔軟性が向上しました。IPv4 の場合、は `/1` AWS WAF をサポートします`/32`。IPv6 の場合、は `/1` AWS WAF をサポートします`/128`。IP セットの詳細については、「[IP セット一致ルールステートメント](waf-rule-statement-type-ipset-match.md)」を参照してください。 + **連鎖可能なテキスト変換** – AWS WAF ウェブリクエストコンテンツを調べる前に、ウェブリクエストコンテンツに対して複数のテキスト変換を実行できます。詳細については、「[でのテキスト変換の使用 AWS WAF](waf-rule-statement-transformation.md)」を参照してください。 + **コンソールエクスペリエンスの向上** – 新しい AWS WAF コンソールは、ビジュアルルールビルダーとより直感的なコンソール設計を備えています。 + **Firewall Manager AWS WAF ポリシーの拡張オプション** – Firewall Manager による AWS WAF 保護パックの管理 (ウェブ ACLs) で、最初に AWS WAF 処理するルールグループのセットと、最後に AWS WAF 処理するルールグループのセットを作成できるようになりました。 AWS WAF ポリシーを適用すると、ローカルアカウントの所有者は、これら 2 つのセットの間にが AWS WAF 処理する独自のルールグループを追加できます。Firewall Manager の AWS WAF ポリシーの詳細については、「[Firewall Manager での AWS WAF ポリシーの使用](waf-policies.md)」を参照してください。 + **AWS CloudFormation はすべてのルールステートメントタイプのサポート** – AWS WAF の AWS CloudFormation は、 AWS WAF コンソールと API がサポートするすべてのルールステートメントタイプをサポートします。さらに、JSON 形式で記述したルールを YAML 形式に簡単に変換できます。 # 移行に関する注意事項と制限事項移行では保護パック (ウェブ ACL) 設定のみが処理され、保護パック (ウェブ ACL) の移行では AWS WAF 、 Classic とまったく同じようにすべての設定が引き継がれるわけではありません。一部の設定項目では、 AWS WAF (v2) で手動設定が必要です。2 つのバージョン間で正確にマッピングされない点がいくつかあります。また、 AWS WAF (v2) で機能を設定する方法を決定する必要があります。保護パック (ウェブ ACL) の AWS リソースとの関連付けなどの一部の設定は、新しいバージョンでは最初は無効になっているため、準備ができたら追加できます。次のリストでは、移行の注意事項と、対処が必要となる可能性があるステップについて説明します。この概要を使用して、移行を計画してください。後述する移行の詳細なステップでは、推奨される緩和ステップについて順を追って説明します。 + **単一アカウントの移行** – どのアカウントの AWS WAF Classic リソースも、同じアカウントの AWS WAF リソースにのみ移行できます。 + **保護パック (ウェブ ACL) 設定のみ** - 移行では、保護パック (ウェブ ACL) と、保護パック (ウェブ ACL) が使用しているリソースのみが移行されます。移行されたウェブ ACL で使用されていないルールグループや IP セットなどのリソースを移行するには、 AWS WAF (v2) でリソースを手動で作成します。 + ** AWS Marketplace マネージドルールなし** – 移行では、 AWS Marketplace 販売者からのマネージドルールは引き継がれません。一部の AWS Marketplace 販売者には、再度サブスクライブ AWS WAF できる同等のマネージドルールがあります。これを行う前に、の最新バージョンで提供されている AWS マネージドルールを確認してください AWS WAF。これらの大部分は AWS WAF ユーザーには無料です。マネージドルールの詳細については、「[でのマネージドルールグループの使用 AWS WAF](waf-managed-rule-groups.md)」を参照してください。 + **保護パック (ウェブ ACL) の関連付けなし** - 移行では、保護パック (ウェブ ACL) と保護されたリソース間の関連付けは引き継がれません。これは仕様です。本番環境のワークロードに影響を与えないようにするためのものです。すべて正しく移行されたことを検証したら、新しい保護パック (ウェブ ACL) をリソースに関連付けます。 + **ログ記録無効** - 移行された保護パック (ウェブ ACL)L のログ記録は、デフォルトで無効になっています。これは仕様です。 AWS WAF Classic からに切り替える準備ができたら、ログ記録を有効にします AWS WAF。 + ** AWS Firewall Manager ルールグループなし** – 移行では、Firewall Manager によって管理されるルールグループは処理されません。Firewall Manager によって管理されている保護パック (ウェブ ACL) を移行することはできますが、移行でルールグループは引き継がれません。このような保護パック (ウェブ ACL) には、移行ツールを使用するのではなく、Firewall Manager で新しい AWS WAF のポリシーを再作成します。 **注記** Firewall Manager が AWS WAF Classic 用に管理したルールグループは、Firewall Manager ルールグループでした。の新しいバージョンでは AWS WAF、ルールグループは AWS WAF ルールグループです。機能的には、これらは同じです。 + **AWS WAF セキュリティオートメーションの注意** — AWS WAF セキュリティオートメーションの移行を試みないでください。移行では、オートメーションにより使用される可能性がある Lambda 関数が変換されません。代わりに、最新バージョンのオートメーションのデプロイを検討してください。詳細については、「[AWS WAF セキュリティオートメーション](https://aws.amazon.com/solutions/aws-waf-security-automations/)」を参照してください。 # 移行の仕組み複数の方法を使用してACLs AWS WAF Classic をから AWS WAF v2 に移行できます。移行を完了するには、次の手順に従います。 **から v2 AWS WAF Classic AWS WAF に移行するには** 1. AWS WAF Classic ウェブ ACLs を特定します。 + AWS Health ダッシュボードでウェブ ACLs のリストを表示します。 + [AWS WAF Classic ウェブ ACL クリーンアップスクリプト]( https://github.com/aws-samples/sample-for-waf-classic-to-wafv2-migrate-and-cleanup/tree/main/scripts/waf-classic-cleanup ) を使用して、すべてのウェブ ACL とその関連付けのリストを取得します。これにより、どのウェブ ACL リソースを積極的に保護しているかを特定し、未使用のウェブ ACL を削除できます。 1. 個々のウェブ ACL: + 「[AWS WAF デベロッパーガイド](https://docs.aws.amazon.com/waf/latest/developerguide/waf-migrating-procedure.html)」の「移行プロセス」に従ってください。 + 移行ウィザードを使用してウェブ AWS WAF Classic ACL を解析し、 AWS CloudFormation テンプレートを生成します。 + 生成されたテンプレートを使用して同等の AWS WAF v2 ウェブ ACL を作成し、移行を完了します。 1. 複数の対象となるウェブ ACL: + [AWS WAF 一括移行スクリプト](https://github.com/aws-samples/sample-for-waf-classic-to-wafv2-migrate-and-cleanup/tree/main/scripts/waf-classic-migration )を使用して、複数の適格な AWS WAF Classic ウェブ ACLs。 1. によって管理ACLs の場合 AWS Firewall Manager: + Firewall Manager ポリシーは、 AWS WAF Classic ポリシーで AWS WAF Classic ウェブ ACL を使用します。 ACLs 2022 年 1 月より前に作成された Shield Advanced ポリシーの場合、Firewall Manager は AWS WAF Classic ウェブ ACLs も使用します。v2 ウェブ ACLs AWS WAF を使用するには、これらのポリシーを移行する必要があります。 [Firewall Manager での AWS WAF Classic ウェブ ACLs移行](migrate-waf-classic-fms.md) の指示に従います。 **重要** リソースに関連付ける前に、移行された各ウェブ ACL を確認して、セキュリティ要件を満たしていることを確認することをお勧めします。 # AWS WAF Classic からへの保護パック (ウェブ ACL) の移行 AWS WAF 自動移行では、 AWS WAF Classic 保護パック (ウェブ ACL) 設定のほとんどが引き継がれ、手動で処理する必要があるものが残ります。 **注記** 一部の保護設定は自動的に移行できず、 AWS WAF (v2) で手動設定が必要です。[移行に関する注意事項と制限事項](waf-migrating-caveats.md) のリストを参照してください。保護パック (ウェブ ACL) を移行するためのステップの概要を次に示します。 1. 自動移行は、 AWS WAF Classic で何も変更または削除することなく、既存の保護パック (ウェブ ACL) に関連するすべてを読み込みます。ウェブ ACL と互換性のある関連リソースの表現を作成します AWS WAF。新しい保護パック (ウェブ ACL) の CloudFormation テンプレートを生成し、Amazon S3 バケットに保存します。 1. テンプレートをにデプロイして CloudFormation、で保護パック (ウェブ ACL) と関連リソースを再作成します AWS WAF。 1. 保護パック (ウェブ ACL) を確認して手動で移行を完了し、新しい保護パック (ウェブ ACL) が最新の AWS WAFの機能を最大限に活用するようにします。 1. 保護されたリソースを新しい保護パック (ウェブ ACL) に手動で切り替えます。 **Topics** + [ # 保護パック (ウェブ ACL) の移行: 自動移行 ](waf-migrating-procedure-automatic.md) + [ # 保護パック (ウェブ ACL) の移行: 手動フォローアップ ](waf-migrating-procedure-manual-finish.md) + [ # 保護パック (ウェブ ACL) の移行: その他の考慮事項 ](waf-migrating-procedure-additional.md) + [ # 保護パック (ウェブ ACL): スイッチオーバー ](waf-migrating-procedure-switchover.md) # 保護パック (ウェブ ACL) の移行: 自動移行 **保護パック (ウェブ ACL) 設定を AWS WAF Classic からに自動的に移行するには AWS WAF** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. ** AWS WAF Classic に切り替え**を選択し、保護パック (ウェブ ACL) の設定を確認します。前のセクション「[移行に関する注意事項と制限事項](waf-migrating-caveats.md)」で説明した注意事項と制限事項を考慮して、設定をメモしておきます。 1. 上部の情報ダイアログで、「**保護パック (ウェブ ACL) を移行する**」で始まる文を見つけて、**移行ウィザード** へのリンクを選択します。移行ウィザードが起動します。情報ダイアログが表示されない場合は、 AWS WAF Classic コンソールを起動してから閉じた可能性があります。ナビゲーションバーで、**「新規に切り替える AWS WAF**」を選択し、** AWS WAF 「クラシックに切り替える**」を選択すると、情報ダイアログが再び表示されます。 1. 移行する保護パック (ウェブ ACL) を選択します。 1. **[Migration configuration]** (移行設定) では、テンプレートに使用する Amazon S3 バケットを指定します。生成する AWS CloudFormation テンプレートを保存するには、移行 API 用に適切に設定された Amazon S3 バケットが必要です。 + バケットが暗号化されている場合、暗号化は Amazon S3 (SSE-S3) キーを使用する必要があります。移行では、 AWS Key Management Service (SSE-KMS) キーを使用した暗号化はサポートされていません。 + バケット名の先頭は `aws-waf-migration-` にする必要があります。例えば、`aws-waf-migration-my-web-acl`。 + バケットは、テンプレートをデプロイするリージョンに存在する必要があります。例えば、`us-west-2` の保護パック (ウェブ ACL) の場合、`us-west-2` で Amazon S3 バケットを使用し、テンプレートスタックを `us-west-2` にデプロイする必要があります。 1. **S3 バケットポリシー**の場合、**[Auto apply the bucket policy required for migration]** (移行に必要なバケットポリシーを自動的に適用する) を選択することをお勧めします。または、自分でバケットを管理する場合は、次のバケットポリシーを手動で適用する必要があります。 + グローバル Amazon CloudFront アプリケーションの場合 (`waf`): ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "apiv2migration.waf.amazonaws.com" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::/AWSWAF//*" } ] } ``` ------ + リージョンレベルの Amazon API Gateway または Application Load Balancer アプリケーションの場合 (`waf-regional`): ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "apiv2migration.waf-regional.amazonaws.com" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::/AWSWAF//*" } ] } ``` ------ 1. **[Choose how to handle rules that cannot be migrated]** (移行できないルールの処理方法を選択してください) で、移行できないルールを除外するか、移行を停止するかを選択します。移行できないルールの詳細については、「[移行に関する注意事項と制限事項](waf-migrating-caveats.md)」を参照してください。 1. [**次へ**] を選択します。 1. ** CloudFormation テンプレートの作成** で設定を確認し、** CloudFormation テンプレートの作成を開始する** を選択して移行プロセスを開始します。保護パック (ウェブ ACL) の複雑さによっては、この処理に数分かかる場合があります。 1. ** CloudFormation スタックの作成と実行で移行を完了する**には、 AWS CloudFormation コンソールに移動してテンプレートからスタックを作成し、新しい保護パック (ウェブ ACL) とそのリソースを作成できます。これを行うには、** CloudFormation スタックの作成**を選択します。自動移行プロセスが完了したら、手動でのフォローアップステップに進む準備が整います。「[保護パック (ウェブ ACL) の移行: 手動フォローアップ](waf-migrating-procedure-manual-finish.md)」を参照してください。 # 保護パック (ウェブ ACL) の移行: 手動フォローアップ自動移行が完了したら、新しく作成した保護パック (ウェブ ACL) を確認し、移行によって引き継がれないコンポーネントを入力します。次の手順では、移行によって処理されない保護パック (ウェブ ACL) 管理の側面について説明します。リストについては、「[移行に関する注意事項と制限事項](waf-migrating-caveats.md)」を参照してください。 **基本的な移行を完了するには - 手動ステップ** 1. にサインイン AWS マネジメントコンソールし、[https://console.aws.amazon.com/wafv2/homev2](https://console.aws.amazon.com/wafv2/homev2) で AWS WAF コンソールを開きます。 1. コンソールは、の最新バージョンを自動的に使用する必要があります AWS WAF。これを確認するには、ナビゲーションペインで、** AWS WAF 「クラシックに切り替える**」オプションが表示されていることを確認します。**新しいに切り替える AWS WAF** が表示された場合は、それを選択して最新バージョンに切り替えます。 1. ナビゲーションペインで、**[保護パック (ウェブ ACL)]** を選択します。 1. **[保護パック (ウェブ ACL)]** ページで、作成したリージョンのリストで新しい保護パック (ウェブ ACL) を見つけます。保護パック (ウェブ ACL) の名前を選択して、保護パック (ウェブ ACL) の設定を表示します。 1. 以前の AWS WAF Classic ウェブ ACL に対して、新しい保護パック (ウェブ ACL) のすべての設定を確認します。デフォルトでは、ログ記録と保護されたリソースの関連付けは無効になっています。切り替えの準備ができたら有効にします。 1. AWS WAF Classic 保護パック (ウェブ ACL) にマネージドルールグループがある場合、ルールグループの包含は移行に引き継がれませんでした。マネージドルールグループを新しい保護パック (ウェブ ACL) に追加できます。で、新しいバージョンので利用可能なマネージドルールのリストなど AWS WAF、 AWS マネージドルールグループに関する情報を確認します[でのマネージドルールグループの使用 AWS WAF](waf-managed-rule-groups.md)。マネージドルールグループを追加するには、次の手順を実行します。 1. 保護パック (ウェブ ACL) 設定ページで、保護パック (ウェブ ACL) **ルール** タブを選択します。 1. **[Add rules]** (ルールの追加) を選択し、**[Add managed rule groups]** (マネージドルールグループの追加) を選択します。 1. 選択したベンダーのリストを展開し、追加するルールグループを選択します。 AWS Marketplace 販売者の場合、ルールグループにサブスクライブする必要がある場合があります。保護パック (ウェブ ACL) でのマネージドルールグループの使用の詳細については、「[でのマネージドルールグループの使用 AWS WAF](waf-managed-rule-groups.md)」および「[のルールとルールグループで保護パック (ウェブ ACLs) を使用する AWS WAF](web-acl-processing.md)」を参照してください。基本的な移行プロセスを完了したら、ニーズを見直して追加のオプションを検討することにより、新しい設定の効率が可能な限り高いことと、利用可能な最新のセキュリティオプションを使用していることを確認することをお勧めします。「[保護パック (ウェブ ACL) の移行: その他の考慮事項](waf-migrating-procedure-additional.md)」を参照してください。 # 保護パック (ウェブ ACL) の移行: その他の考慮事項新しい保護パック (ウェブ ACL) を確認し、新しいで使用可能なオプションを検討 AWS WAF して、設定ができるだけ効率的であり、利用可能な最新のセキュリティオプションを使用していることを確認します。 **その他の AWS マネージドルール** アプリケーションのセキュリティ体制を強化するために、追加の AWS マネージドルールを保護パック (ウェブ ACL) に実装することを検討してください。これらは追加料金 AWS WAF なしでに含まれます。 AWS マネージドルールには、次のタイプのルールグループがあります。 + ベースラインルールグループは、既知の不正な入力がアプリケーションに入らないようにしたり、管理ページへのアクセスを防ぐなど、さまざまな一般的な脅威に対して全般的な保護を提供します。 + ユースケース固有のルールグループは、多種多様なユースケースに対して段階的な保護を提供します。 + IP 評価レピュテーションリストは、クライアントの送信元 IP に基づく脅威インテリジェンスを提供します。詳細については、「[AWS のマネージドルール AWS WAF](aws-managed-rule-groups.md)」を参照してください。 **ルールの最適化とクリーンアップ** 古いルールを再検討し、それらを書き換えたり、古いルールを削除して最適化することを検討してください。例えば、過去に OWASP Top 10 Web Application Vulnerabilities のテクニカルペーパーの AWS CloudFormation テンプレートをデプロイしたことがある場合は、 [と新しいホワイトペーパーを使用して AWS WAF OWASP Top 10 Web Application Vulnerabilities に備え](https://aws.amazon.com/blogs/aws/prepare-for-the-owasp-top-10-web-application-vulnerabilities-using-aws-waf-and-our-new-white-paper/)てください。これを AWS マネージドルールに置き換えることを検討してください。ドキュメント内の概念は依然として適用可能であり、独自のルールの作成に役立つ場合がありますが、テンプレートによって作成されたルールは主に AWS マネージドルールに置き換えられています。 **Amazon CloudWatch メトリクスおよびアラーム** Amazon CloudWatch メトリクスに再度アクセスして、必要に応じてアラームを設定します。移行では CloudWatch アラームが引き継がれないため、メトリクス名が目的のものとは異なる可能性があります。 **アプリケーションチームとの確認** アプリケーションチームと協力して、セキュリティ体制を確認してください。アプリケーションによって頻繁に解析されるフィールドを調べ、それに応じて入力をサニタイズするルールを追加します。エッジケースをチェックし、アプリケーションのビジネスロジックがケースを処理できない場合にこれらのケースをキャッチするルールを追加します。 **切り替えの計画** アプリケーションチームと切り替えのタイミングを計画します。古い保護パック (ウェブ ACL) の関連付けから新しいものへの切り替えは、リソースが保存されているすべての領域に反映されるまで、少し時間がかかる場合があります。伝播時間は、数秒から数分までかかります。この際、一部のリクエストは古い保護パック (ウェブ ACL) で処理される一方、他のものは新しい保護パック (ウェブ ACL) で処理されます。リソースは切り替え作業を通して保護されますが、その過程中にリクエスト処理に一貫性がないことに気付く場合があります。切り替えの準備ができたら、「[保護パック (ウェブ ACL): スイッチオーバー](waf-migrating-procedure-switchover.md)」の手順に従います。 # 保護パック (ウェブ ACL): スイッチオーバー新しい保護パック (ウェブ ACL) 設定を検証したら、 AWS WAF Classic 保護パック (ウェブ ACL) の代わりに使用を開始できます。 **新しい AWS WAF 保護パックの使用を開始するには (ウェブ ACL)** 1. 「」のガイダンスに従って、 AWS WAF 保護パック (ウェブ ACL) を保護対象のリソースに関連付けます[AWS リソースとの保護の関連付けまたは関連付け解除](web-acl-associating-aws-resource.md)。これにより、古い保護パック (ウェブ ACL) からリソースの関連付けが自動的に解除されます。切り替えは、伝播するために数秒から数分までかかります。この際、一部のリクエストは古いウェブ ACL で処理される可能性がある一方、他のものは新しい保護パック (ウェブ ACL) で処理される可能性があります。リソースは切り替え作業を通して保護されますが、終了するまでリクエスト処理に一貫性がないことに気付く場合があります。 1. 「[ログ記録 AWS WAF 保護パック (ウェブ ACL) トラフィック](logging.md)」のガイダンスに従って、新しい保護パック (ウェブ ACL) のログ記録を設定します。 1. (オプション) AWS WAF Classic 保護パック (ウェブ ACL) がリソースに関連付けられなくなった場合は、 AWS WAF Classic から完全に削除することを検討してください。詳細については、「[ウェブ ACL の削除](classic-web-acl-deleting.md)」を参照してください。