ATP のテストとデプロイ - AWS WAF、AWS Firewall Manager、および AWS Shield Advanced

ATP のテストとデプロイ

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

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

注記

AWS マネージドルールは、一般的なウェブの脅威からユーザーを保護するように設計されています。ドキュメントに従って使用した場合、AWS マネージドルールのルールグループはアプリケーションに別のセキュリティレイヤーを追加します。ただし、AWS マネージドルールのルールグループは、選択した AWS リソースに伴うセキュリティ責任に代わるものではありません。AWS のリソースが適切に保護されるようにするには、「責任共有モデル」を参照してください。

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

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

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

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

AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) の実装を設定およびテストするには

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      • ユーザー: WAF_TEST_CREDENTIAL@wafexample.com

      • パスワード: 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 を使用」を参照してください。