モニタリングとチューニング

このセクションでは、 AWS WAF 保護機能を監視および調整する方法について説明します。

注記

このセクションのガイダンスに従うには、ウェブ ACL、ルール、 AWS WAF ルールグループなどの保護を作成および管理する方法を一般的に理解している必要があります。この情報は、このガイドの前のセクションで説明しています。

ウェブトラフィックとルールの一致をモニタリングして、ウェブ ACL の動作を確認します。問題が見つかった場合は、ルールを調整して修正し、モニタリングして調整を確認します。

ウェブ ACL が必要に応じてウェブトラフィックを管理するまで、次の手順を繰り返します。

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

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

   トラフィックがフローしていることと、テストルールで一致するリクエストが検出されていることを確認します。

   テストしている保護については、次の情報を参照してください。

   • ログ — 以下はウェブリクエストに一致するルールに関するアクセス情報です。

     • ルール - Count アクションがあるウェブ ACL のルールは、nonTerminatingMatchingRules にリストされます。Allow または Block を持つルールは、terminatingRule として一覧表示されます。CAPTCHA または Challenge を持つルールは、終了する場合と終了しない場合があり、そのためにルール一致の結果に応じて、2 つのカテゴリのいずれかに一覧表示されます。

     • ルールグループ - ルールグループは ruleGroupId フィールドで識別され、そのルールに一致するルールはスタンドアロンルールと同様に分類されます。

     • ラベル - ルールがリクエストに適用したラベルが Labels フィールドに一覧表示されます。

     詳細については、「ログフィールド」を参照してください。

   • Amazon CloudWatch メトリックス — ウェブ ACL リクエストの評価では、以下のメトリックスにアクセスできます。

     • ルール — メトリックスはルールアクションごとにグループ化されます。たとえば、Countモードでルールをテストすると、一致したルールがウェブ ACL Count のメトリクスとして一覧表示されます。

     • ルールグループ — ルールグループのメトリックは、ルールグループメトリックの下に一覧表示されます。

     • 別のアカウントが所有するルールグループ — ルールグループメトリックは通常、ルールグループの所有者にのみ表示されます。ただし、ルールのルールアクションをオーバーライドすると、そのルールのメトリックがウェブ ACL メトリクスの下に一覧表示されます。さらに、ルールグループによって追加されたラベルはウェブ ACL メトリクスに一覧表示されます。

       このカテゴリのルールグループはAWS のマネージドルール AWS WAFAWS Marketplace マネージドルールグループ、他のサービスによって提供されるルールグループ、、別のアカウントと共有されているルールグループです。

     • ラベル-評価中にウェブリクエストに追加されたラベルは、ウェブ ACL ラベルメトリックスに一覧表示されます。自分のルールやルールグループによって追加されたのか、別のアカウントが所有するルールグループのルールによって追加されたのかに関係なく、すべてのラベルのメトリックスにアクセスできます。

     詳細については、「ウェブ ACL のメトリクスの表示」を参照してください。

   • ウェブ ACL トラフィック概要ダッシュボード — AWS WAF コンソールのウェブ ACL のページに移動して [トラフィック概要] タブを開くと、ウェブ ACL が評価したウェブトラフィックの概要にアクセスできます。

     トラフィック概要ダッシュボードには、 AWS WAF アプリケーションのウェブトラフィックを評価する際に収集される Amazon CloudWatch メトリックスの概要がほぼリアルタイムで表示されます。

     詳細については、「ウェブ ACL トラフィック概要ダッシュボード」を参照してください。

   • ウェブリクエストのサンプル — ウェブリクエストのサンプルと一致するルールのアクセス情報。サンプル情報では、ウェブ ACL 内のルールのメトリクス名で一致するルールを識別します。ルールグループの場合、メトリックはルールグループ参照ステートメントを識別します。ルールグループ内のルールの場合、サンプルは RuleWithinRuleGroup の一致ルール名をリストします。

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

2. 誤検知に対処するための緩和を構成する

   ルールが、本来は一致しないはずのウェブリクエストに一致して、誤検出を発生させていると判断した場合、次のオプションを使用してウェブ ACL 保護を調整して緩和できます。

   ルールの検査基準の修正

   自分のルールについては、多くの場合、ウェブリクエストを検査するために使用する設定を調整する必要があります。例としては、正規表現パターンセット内の仕様の変更、検査前にリクエストコンポーネントに適用するテキスト変換の調整、転送 IP アドレスへの切り替えなどがあります。「ルールステートメントの基本」にある問題の原因となっているルールタイプのガイダンスを参照してください。

   より複雑な問題の修正

   制御しない検査基準や複雑なルールについては、要求を明示的に許可またはブロックするルールを追加したり、問題のあるルールによる評価から要求を排除したりするなど、その他の変更が必要になることがあります。管理ルールグループでは、通常、このタイプの緩和策が必要ですが、他のルールも可能です。例としては、レートベースのルールステートメントと SQL インジェクション攻撃ルールステートメントなどがあります。

   誤検出を軽減するために行う方法は、ユースケースによって異なります。一般的なアプローチは以下のとおりです。

   • 緩和ルールの追加：新しいルールの前に実行され、誤検出の原因となっているリクエストを明示的に許可するルールを追加します。ウェブ ACL でのルールの評価順序の詳細については、「ウェブ ACL でのルールおよびルールグループの処理順序」を参照してください。

     この方法では、許可されたリクエストは保護されたリソースに送信されるため、評価のために新しいルールに到達することはありません。新しいルールが有料管理ルールグループである場合、このアプローチはルールグループの使用コストを抑えるのにも役立ちます。

   • 緩和ルールで論理ルールを追加する：論理ルールステートメントを使用して、新しいルールと誤検出を除外するルールを組み合わせます。詳細については、論理ルールステートメント を参照してください。

     たとえば、リクエストのカテゴリに対して誤検出を生成する SQL インジェクションアタック match ステートメントを追加するとします。これらの要求に一致するルールを作成し、論理ルールステートメントを使用してルールを組み合わせて、両方が誤検出条件に一致せず、SQL インジェクション攻撃条件に一致するリクエストに対してのみ一致するようにします。

   • スコープダウンステートメントを追加する：レートベースのステートメントおよび管理ルールグループ参照ステートメントの場合、メインステートメント内にスコープダウンステートメントを追加して、誤検出の原因となるリクエストを評価から除外します。

     スコープダウンステートメントと一致しないリクエストは、ルールグループまたはレートベースの評価に到達することはありません。スコープダウンステートメントの詳細については、「スコープダウンステートメント」を参照してください。例については、ボット管理から IP 範囲を除外するを参照してください。

   • ラベルマッチルールを追加する— ラベリングを使用するルールグループでは、問題のあるルールがリクエストに適用されているラベルを特定します。ルールグループのルールをまだカウントモードに設定していない場合は、最初にカウントモードに設定する必要がある場合があります。問題のあるルールによって追加されているラベルと一致するラベル一致ルールを、ルールグループの後に実行するように追加します。ラベル一致ルールでは、ブロックするリクエストから許可するリクエストをフィルタリングできます。

     この方法を使用する場合、テストが終了したら、問題のあるルールをルールグループ内でカウントモードで保持し、カスタムラベルマッチルールをそのまま維持します。ラベル一致ステートメントの詳細については、「ラベル一致ルールステートメント」を参照してください。例については、「特定のブロックされたボットを許可する」および「ATP の例: 認証情報の不足および侵害された認証情報のカスタム処理」を参照してください。

   • マネージドルールグループのバージョンの変更— バージョン対応管理ルールグループの場合、使用しているバージョンを変更します。たとえば、正常に使用していた最後の静的バージョンに戻すことができます。

     これは通常、一時的な修正です。テスト環境またはステージング環境で最新バージョンのテストを継続している間、またはプロバイダーから互換性が高いバージョンを待っている間に、本番トラフィックのバージョンを変更する場合があるかもしれません。マネージドルールグループの詳細については、「マネージドルールグループ」を参照してください。

新しいルールが必要なリクエストと一致していることに納得できたら、テストの次の段階に進み、この手順を繰り返します。テストと調整の最終段階は、本番稼働環境で実行します。