

**の新しいコンソールエクスペリエンスの紹介 AWS WAF**

更新されたエクスペリエンスを使用して、コンソールの任意の場所で AWS WAF 機能にアクセスできるようになりました。詳細については、[「コンソールの使用](https://docs.aws.amazon.com/waf/latest/developerguide/working-with-console.html)」を参照してください。

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

# ACFP マネージドルールグループをウェブ ACL に追加
<a name="waf-acfp-rg-using"></a>

このセクションでは、`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\_ENCODED ペイロードタイプ** – 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 実装をデプロイする前に、トラフィックへの潜在的な影響に慣れるまで、ステージング環境またはテスト環境でテストおよびチューニングします。その後、ルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。ガイダンスについては、次のセクションを参照してください。