ATP のテストとデプロイ

このセクションでは、 AWS WAF サイトにおける不正防止アカウント乗っ取り防止 (ATP) 実装の設定とテストに関する一般的なガイダンスを提供します。実行する具体的なステップは、ニーズ、リソース、および受け取るウェブリクエストによって異なります。

この情報は、AWS WAF 保護機能のテストと調整 で提供されているテストおよび調整に関する一般情報とは別です。

注記

AWS マネージドルールは、一般的な Web の脅威からユーザーを保護するように設計されています。マニュアルに従って使用すると、 AWS マネージドルールルールグループはアプリケーションのセキュリティをさらに強化します。ただし、 AWS マネージドルールルールグループは、 AWS 選択したリソースによって決定されるセキュリティ責任の代わりとなるものではありません。責任共有モデルを参照して、 AWS 内のリソースが適切に保護されていることを確認してください。

本番稼働トラフィックのリスク

本番稼働トラフィックに ATP 実装をデプロイする前に、トラフィックへの潜在的な影響に慣れるまで、ステージング環境またはテスト環境でテストおよびチューニングします。その後、ルールを有効にする前に、本番稼働用トラフィックでカウントモードでルールをテストしてチューニングします。

AWS WAF ATP 構成の検証に使用できるテスト認証情報を提供します。次の手順では、ATP マネージドルールグループを使用するようにテストウェブ ACL を設定し、ルールグループによって追加されたラベルをキャプチャするルールを設定してから、これらのテスト認証情報を使用してログイン試行を実行します。ウェブ ACL がログイン試行を適切に管理していることを確認するには、ログイン試行の Amazon CloudWatch メトリックスを確認します。

このガイダンスは、 AWS WAF ウェブ ACL、ルール、およびルールグループを作成および管理する方法を一般的に認識しているユーザーを対象としています。これらのトピックは、このガイドの前のセクションでカバーされています。

AWS WAF 不正防止アカウント乗っ取り防止 (ATP) の実装を設定してテストするには

これらのステップを最初にテスト環境で実行し、次に本番環境で実行します。

1. AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) マネージドルールグループをカウントモードで追加します。

   注記

   このマネージドルールグループを使用する場合、追加料金が請求されます。詳細については、「AWS WAF の料金」を参照してください。

   AWS AWSManagedRulesATPRuleSetマネージドルールルールグループを新規または既存のウェブ ACL に追加し、現在のウェブ ACL の動作が変更されないように設定します。このルールグループのルールとラベルの詳細については、「AWS WAF 不正防止アカウント乗っ取り防止 (ATP) ルールグループ」を参照してください。

   • マネージドルールグループを追加する際には、それを編集し、次の手順を実行します。

     • [Rule group configuration] (ルールグループを設定) ペインで、アプリケーションのログインページの詳細を入力します。ATP ルールグループは、この情報を使用してサインインアクティビティをモニタリングします。詳細については、「ATP マネージドルールグループをウェブ ACL に追加」を参照してください。

     • [Rules] (ルール) ペインで、[Override all rule actions] (すべてのルールアクションをオーバーライド) ドロップダウンを開いて、[Count] を選択します。この設定では、 AWS WAF は、ルールグループ内のすべてのルールに対してリクエストを評価し、その結果の一致のみをカウントしつつ、引き続きリクエストにラベルを追加します。詳細については、「ルールグループ内のルールアクションのオーバーライド」を参照してください。

       このオーバーライドにより、ATP マネージドルールの影響をモニタリングして、例外 (内部のユースケースの例外など) を追加するかどうか判断できます。

   • ウェブ ACL の既存のルールの後に評価されるように、ルールグループを配置します。優先順位の設定の数値は、既に使用しているルールまたはルールグループよりも高くなります。詳細については、「ウェブ ACL でのルールおよびルールグループの処理順序」を参照してください。

     これにより、現在のトラフィックの処理が中断されることはありません。例えば、SQL インジェクションやクロスサイトスクリプティングなどの悪意のあるトラフィックを検出するルールがある場合、そのルールは引き続き検出し、それをログに記録します。または、既知の悪意のないトラフィックを許可するルールがある場合、ATP マネージドルールグループによってブロックされるようにすることなく、そのトラフィックを許可し続けることができます。テストおよびチューニングのアクティビティ中に、処理順序を調整することもできます。

2. ウェブ ACL のサンプリング、ログ記録、およびメトリクスの有効化

   必要に応じて、ウェブ ACL のロギングを設定し、サンプリングと Amazon CloudWatch メトリクスを有効にします。これらの可視化ツールを使用して ATP マネージドルールグループとトラフィックとのインタラクションをモニタリングできます。

   • ログ記録の設定と使用については、「AWS WAF ウェブ ACL トラフィックのロギング」を参照してください。

   • Amazon CloudWatch メトリックスについて詳しくは、を参照してくださいAmazon によるモニタリング CloudWatch。

   • ウェブリクエストサンプリングの詳細については、「ウェブリクエストのサンプルの表示」を参照してください。

3. ウェブ ACL をリソースに関連付ける

   ウェブ ACL がテストリソースに関連付けられていない場合は、関連付けます。詳細については、「ウェブ ACL とリソースの関連付けまたは関連付け解除 AWS」を参照してください。

4. トラフィックと ATP ルールの一致をモニタリングする

   通常のトラフィックがフローしていることと、ATP マネージドルールグループのルールが一致するウェブリクエストにラベルを追加していることを確認します。ログにはラベルが表示され、Amazon CloudWatch メトリクスでは ATP とラベルのメトリックスを確認できます。ログでは、ルールグループでカウントするようにオーバーライドしたルールが、カウントに設定された action と、オーバーライドした設定済のルールアクションを示す overriddenAction とともに、ruleGroupList に表示されます。

5. ルールグループの認証情報チェック機能をテストする

   テスト用の侵害された認証情報を使用してログインを試行し、ルールグループが想定どおりに照合することを確認します。

   1. AWS WAF 以下のテスト認証情報ペアを使用して、保護対象リソースのログインページにログインします。

      • ユーザー: [e-mail]

      • パスワード: WAF_TEST_CREDENTIAL_PASSWORD

      これらのテスト認証情報は侵害された認証情報として分類され、ATP マネージドルールグループはログインリクエストに awswaf:managed:aws:atp:signal:credential_compromised ラベル (ログでの確認が可能) を追加します。

   2. ウェブ ACL ログで、テストログインウェブリクエストのログエントリの labels フィールドで awswaf:managed:aws:atp:signal:credential_compromised ラベルを探します。ログ作成の詳細については、「AWS WAF ウェブ ACL トラフィックのロギング」を参照してください。

   侵害された認証情報をルールグループが想定どおりにキャプチャすることを検証したら、保護されたリソースに必要な実装を設定するステップを実行できます。

6. CloudFront ディストリビューションの場合は、ルールグループのログイン障害管理をテストしてください。

   1. ATP ルールグループに設定した応答の失敗基準それぞれに対してテストを実行します。テストとテストの間は 10 分以上あけてください。

      単一の失敗基準をテストするには、その条件で失敗するログイン試行を応答内で特定します。次に、単一のクライアント IP アドレスからの失敗したログイン試行を、10 分以内に少なくとも 10 回実行します。

      最初の 6 回の試行が失敗した後、ボリューメトリックが失敗したログインルールが、残りのログイン試行に対する一致、ラベル付け、およびカウントを開始します。レイテンシーにより、ルールで最初の 1 回または 2 回が見逃される可能性があります。

   2. ウェブ ACL ログで、テストログインウェブリクエストのログエントリの labels フィールドで awswaf:managed:aws:atp:aggregate:volumetric:ip:failed_login_response:high ラベルを探します。ログ作成の詳細については、「AWS WAF ウェブ ACL トラフィックのロギング」を参照してください。

   これらのテストでは、失敗したログイン回数がルール VolumetricIpFailedLoginResponseHigh のしきい値を超えているかどうかをチェックして、失敗基準が応答に一致しているかどうかを検証します。しきい値に達した後も同じ IP アドレスからログインリクエストを送信し続けると、失敗率がしきい値を下回るまでルールによる一致が継続されます。しきい値を超えている間、ルールは IP アドレスからの成功したログインと失敗したログインの両方に一致させます。

7. ATP ウェブリクエストの処理をカスタマイズする

   必要に応じて、リクエストを明示的に許可またはブロックする独自のルールを追加して、ATP ルールがそのリクエストを処理する方法を変更します。

   例えば、ATP ラベルを使用して、リクエストを許可またはブロックしたり、リクエスト処理をカスタマイズしたりできます。ATP マネージドルールグループの後にラベル一致ルールを追加して、適用する処理のためにラベル付きリクエストをフィルタリングできます。テスト後、関連する ATP ルールをカウントモードで維持し、カスタムルールでリクエストの処理に関する決定を維持します。例については、「ATP の例: 認証情報の不足および侵害された認証情報のカスタム処理」を参照してください。

8. テストルールを削除し、ATP マネージドルールグループ設定を有効にする

   状況によっては、一部の ATP ルールをカウントモードのままにすると判断していた可能性もあります。ルールグループ内で設定したとおりに実行するルールについては、ウェブ ACL ルールグループ設定でカウントモードを無効にします。テストが終了したら、テストラベル一致ルールを削除することもできます。

9. モニタリングおよびチューニング

   ウェブリクエストが希望どおりに処理されていることを確認するには、使用することを希望する ATP 機能を有効にした後、トラフィックを注意深くモニタリングします。ルールグループに対するルールカウントの上書きと独自のルールを使用して、必要に応じて動作を調整します。

ATP ルールグループの実装をテストした後で、まだテストしていない場合は、検出機能を強化するために AWS WAF JavaScript SDK をブラウザのログインページに組み込むことを強くお勧めします。 AWS WAF iOS デバイスと Android デバイスを統合するためのモバイル SDK も提供しています。統合 SDK の詳細については、「AWS WAF クライアントアプリケーション統合」を参照してください。このレコメンデーションについては、「ATP でアプリケーション統合 SDK を使用する理由」を参照してください。