AWS WAF におけるインテリジェントな脅威を軽減するためのベストプラクティス

JavaScript とモバイルアプリケーション統合 SDK を実装する – アプリケーション統合を実装して、可能な限り最も効果的な方法で ACFP、ATP、または Bot Control 機能のすべて有効にします。マネージドルールグループは、SDK が提供するトークンを使用して、セッションレベルで正規のクライアントトラフィックを望ましくないトラフィックから分離させます。アプリケーション統合 SDK は、これらのトークンが常に利用可能であることを確実にします。詳細については、以下を参照してください。

クライアントにチャレンジを実装したり、JavaScript の場合は CAPTCHA パズルがエンドユーザーに提示される方法をカスタマイズしたりするために、統合を使用します。詳細については、「AWS WAF でのクライアントアプリケーション統合」を参照してください。

JavaScript API を使用して CAPTCHA パズルをカスタマイズし、保護パック (ウェブ ACL) の任意の場所で CAPTCHA ルールアクションを使用する場合は、クライアントでの AWS WAF CAPTCHA レスポンスの処理に関するガイダンスに従ってください (AWS WAF からの CAPTCHA レスポンスの処理)。このガイダンスは、ACFP マネージドルールグループや Bot Control マネージドルールグループのターゲットを絞った保護レベルなど、CAPTCHA アクションを使用するすべてのルールに適用されます。

ACFP、ATP、および Bot Control ルールグループに送信するリクエストを制限する – インテリジェントな脅威の軽減の AWS マネージドルールルールグループの使用には、追加料金がかかります。ACFP ルールグループは、指定したアカウント登録エンドポイントと作成エンドポイントに対するリクエストを検査します。ATP ルールグループは、指定したログインエンドポイントに対するリクエストを検査します。Bot Control ルールグループは、保護パック (ウェブ ACL) 評価で、到達するすべてのリクエストを検査します。

これらのルールグループの使用を減らすため、以下のアプローチを検討してください。

料金の詳細については、「AWS WAF の料金表」を参照してください。

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 の概要」および「AWS Shield Advanced および AWS WAF によるアプリケーションレイヤー (レイヤー 7) の保護」を参照してください。

分散型サービス拒否 (DDoS) の防止の詳細については、「DDoS 対策ルールグループ」および「分散型サービス拒否 (DDoS) の防止」を参照してください。

通常のウェブトラフィック中に DDoS 対策ルールグループと Bot Control ルールグループのターゲットを絞った保護レベルを有効にする – これらのルールカテゴリには、通常のトラフィックのベースラインを確立する時間が必要です。

通常のウェブトラフィック中に Bot Control ルールグループのターゲットを絞った保護レベルを有効にする – ターゲットを絞った保護レベルのルールの一部では、通常のトラフィックパターンのベースラインを確立してからでないと、不規則なトラフィックパターンや悪意のあるトラフィックパターンに対する認識と対応が行えません。例えば、TGT_ML_* ルールのウォームアップには最大 24 時間かかります。

攻撃を受けていないときにこれらの保護を追加し、ルールが適切に対応することを期待する前に、トラフィックパターンのベースラインを確立するための猶予時間を与えます。攻撃中にこれらのルールを追加する場合は、カウントモードで DDoS 対策ルールグループを有効にする必要があります。攻撃が収まった後、ベースラインを確立するまでにかかる時間は通常の 2 倍から 3 倍になります。これは、攻撃トラフィックによって歪みが生じるためです。ルールとルールのウォームアップに必要な時間に関する詳細については、「ルールの一覧」を参照してください。

分散型サービス拒否 (DDoS) からの保護には、Shield Advanced のアプリケーションレイヤー DDoS 自動緩和を使用する – インテリジェントな脅威の軽減ルールグループは DDoS 保護を提供しません。ACFP は、アプリケーションのサインアップページに対するアカウントの不正な作成の試みから保護します。ATP は、ログインページに対するアカウント乗っ取りの試みを防ぎます。Bot Control は、トークンとクライアントセッションに対する動的なレート制限を使用して、人間のようなアクセスパターンを実施することに重点を置いています。

アプリケーションレイヤー DDoS 自動緩和を有効にした Shield Advanced を使用すると、Shield Advanced が、ユーザーに代わってカスタム AWS WAF 緩和策を作成、評価、およびデプロイすることによって、検出された DDoS 攻撃に自動的に対応します。Shield Advanced の詳細については、「AWS Shield Advanced の概要」および「AWS Shield Advanced および AWS WAF によるアプリケーションレイヤー (レイヤー 7) の保護」を参照してください。

DDoS 対策ルールグループのベースラインを確立するときに本番トラフィック負荷を使用する – 人工テストトラフィックを使用して他のルールグループをテストするのが一般的です。ただし、DDoS 対策ルールグループのベースラインをテストして確立する場合は、本番環境の負荷を反映するトラフィックフローを使用することをお勧めします。一般的なトラフィックを使用して DDoS 対策ベースラインを確立することは、ルールグループが本番環境で有効になっているときにリソースを保護する最善の方法です。

トークン処理を調整および設定する – 最高のユーザーエクスペリエンスが得られるように、保護パック (ウェブ ACL) のトークン処理を調整します。

任意のホスト仕様を持つリクエストを拒否する – ウェブリクエストの Host ヘッダーがターゲットリソースに一致することを必須とするように保護対象リソースを設定します。ホストについて、1 つの値、または特定の値セット (myExampleHost.com および www.myExampleHost.com など) を受け入れることはできますが、任意の値は受け入れないでください。

CloudFront ディストリビューションのオリジンである Application Load Balancer については、適切なトークン処理のために CloudFront と AWS WAF を設定する – 保護パック (ウェブ ACL) を Application Load Balancer に関連付け、その Application Load Balancer を CloudFront ディストリビューションのオリジンとしてデプロイする場合は、「CloudFront からの Application Load Balancers に必要な設定」を参照してください。

デプロイ前にテストして調整する – 保護パック (ウェブ ACL) に変更を実装する前に、本ガイドのテストおよび調整手順に従って、期待通りの動作が得られることを確認してください。これらの有料機能を使用する場合は特に重要です。一般的なガイダンスについては、「AWS WAF 保護のテストとチューニング」を参照してください。有料マネージドルールグループ固有の情報については、「ACFP のテストとデプロイ」、「ATP のテストとデプロイ」、「AWS WAF Bot Control のテストとデプロイ」を参照してください。