AWS WAFのWeb ACLとルール設計

AWS WAFは、WebアプリケーションやAPIに届くHTTP／HTTPSリクエストを検査するマネージド型のWebアプリケーションファイアウォールです。SQLインジェクションやクロスサイトスクリプティング（XSS）などの一般的なWeb攻撃、不審なボットのアクセス、過剰なリクエストを検出し、条件に応じて許可、遮断、記録できます。

ネットワークファイアウォールがIPアドレス、ポート、プロトコルなどを扱うのに対し、WAFはURIパス、クエリ文字列、HTTPメソッド、ヘッダー、リクエスト本文など、Webリクエストの内容を判定条件にできます。VPCを流れるあらゆるパケットを制御するものではなく、AWS WAFがサポートするリソースに関連付けて使います。

Web ACLでリクエストを評価する

Web ACL（Web Access Control List）は、保護対象に適用するルールとデフォルトアクションをまとめた設定です。対応するAWSリソースへ関連付けると、そのリソースに届くリクエストがWeb ACLで評価されます。ルールは設定した優先度（数値の小さい順）に確認されます。AWSの新しいコンソールやドキュメントでは、Web ACLをprotection packと表記する場合があります。

判定の仕組みを読むときは、「条件に一致したらすべてそこで終了」と覚えないようにします。AllowやBlockのように評価を終了するアクションと、Countのように記録して次のルールへ進むアクションがあります。CAPTCHAとChallengeは有効なトークンの有無などによって処理が変わります。どのルールでも評価を終了しなければ、Web ACLのデフォルトアクションが適用されます。

たとえば、会員向けの画像配信APIで、既知の攻撃シグネチャをマネージドルールで調べた後、特定の国からのアクセスを制限し、残ったリクエストを許可する構成を考えます。最初のルールをCountにすれば評価は次へ進みます。後続ルールでBlockが実行された場合はそこで終了し、どのルールも終了アクションを実行しなければデフォルトアクションに到達します。

Web ACLのルール

Web ACLには、AWSやセキュリティベンダーが提供するマネージドルールグループと、利用者が条件を組み立てるカスタムルールを追加できます。一般的な脅威を広くカバーするルールと、アプリケーション固有の制御を組み合わせて使います。

マネージドルールグループ

マネージドルールグループは、よく使われる脅威や攻撃パターンに対応するルールのセットです。AWSが提供するAWS Managed Rulesのほか、AWS Marketplaceを通じてセキュリティベンダーが提供するグループも選べます。攻撃パターンやボットの識別方法が更新されるグループでは、その更新を取り込んで運用負荷を抑えられます。

グループ内の個々のルールを無効化したり、そのルールのアクションを上書きしたりできる場合があります。アプリケーションの正常なリクエストに誤って一致する誤検知が見つかったら、ルール全体を外す前に、どのルールが一致したかをログやメトリクスで調べます。特定ルールをCountへ変更する、対象ルールを除外するなどの調整を行い、保護範囲を不用意に失わないようにします。グループごとのカスタマイズ可否は提供元の仕様を確認してください。

カスタムルール

カスタムルールは、アプリケーションの利用条件や独自の脅威モデルに合わせて作ります。たとえば、保守用APIへのアクセス元CIDRを限定する、特定の地域からのアクセスを制限する、専用ヘッダーの有無を確認するといった用途があります。

一つのルールに複数の条件を含めることもできます。条件をAND／OR／NOTで組み合わせ、どのリクエストを対象にするかを具体化します。汎用的な攻撃シグネチャはマネージドルールグループを利用し、業務固有の条件はカスタムルールにする、という役割分担が基本です。

リクエストのどの部分を条件にできるか

ルールの条件は、大きく次の観点に分けられます。

判定対象	条件の例	主な使いどころ
送信元	IPアドレス、CIDR範囲、地理的位置	管理用画面の接続元制限、特定地域からのアクセス制御
HTTPリクエスト要素	URIパス、クエリ文字列、ヘッダー、HTTPメソッド、リクエスト本文	特定のAPIパスやメソッド、パラメーターの形式を検査
要素の大きさや文字列	サイズ制約、文字列一致、正規表現	想定外に大きい値や特定パターンを検出
攻撃シグネチャ	SQLインジェクション、XSSなどのパターン	よく知られたWeb攻撃を検出
リクエスト頻度	集約条件ごとのリクエスト数	ブルートフォースや過剰なアクセスの抑制

本文やヘッダーなど一部の要素には検査可能なサイズ上限があります。本文全体を常に無制限に検査できるわけではなく、関連付けるリソースによって検査できる上限や追加料金の条件が異なる場合があります。必要な要素がWAFでどこまで評価されるか、対象リソースのドキュメントで確認します。

レートベースルール

レートベースルールは、一定の時間窓内に届くリクエストを指定した条件で集約し、しきい値を超えた場合にアクションを適用します。集約の基準として、送信元IPアドレスや転送されたIPアドレス、カスタムキーなどを選べます。代表的な使い方は、同じ送信元からログインAPIへ短時間に多数の試行があった場合に、一時的にそのリクエストを制限することです。

評価時間窓は60秒、120秒、300秒、600秒から選べ、既定値は300秒（5分）です。AWS WAFは約10秒ごとに直近の時間窓を確認します。そのため、レート制限は「設定値を一度超えた瞬間に必ず遮断する」厳密なトランザクションカウンターではなく、超過検知や制限の反映には揺らぎがあります。必要な応答時間と誤検知の許容度に合わせて時間窓を選びます。

送信元IPごとの集約だけを使う場合、攻撃元がIPアドレスを頻繁に変えると、各アドレスのリクエストがしきい値未満に分散することがあります。利用可能な場合は、URIパスやヘッダーなどのカスタム集約キー、IPセット、認証・アプリケーション側のレート制御も合わせて設計します。レートベースルールはブルートフォースや一部の過剰アクセスへの緩和策であり、分散型サービス妨害（DDoS）対策すべてを単独で担うものではありません。

アクションの違い

ルールアクションは、リクエストへの処理と後続ルールの評価に影響します。実運用へ適用する前に、ログとCountアクションで一致状況を把握する方法が有効です。

アクション	動作	評価の考え方
Allow	リクエストを許可する	Web ACLのルール評価を終了する
Block	リクエストを拒否する	Web ACLのルール評価を終了する
Count	リクエストを記録し、カウントする	通常は次のルールへ評価を続ける
CAPTCHA	トークン状態を確認し、必要に応じてCAPTCHAを要求する	有効なトークンがない場合などは評価を終了し、条件を満たせば後続へ進む
Challenge	トークン状態を確認するためブラウザへチャレンジを行う	有効なトークンがない場合などは評価を終了し、条件を満たせば後続へ進む

CAPTCHAとChallengeは、「すべての人間かボットかを完全に判別する」機能ではありません。ブラウザがチャレンジに応答できるかを調べ、トークンを使って以降のリクエストを評価する仕組みです。トークンの免疫時間や、アプリケーションの利用者に求める操作を含めて適切に設定します。モバイルアプリや機械間通信など、ブラウザのチャレンジを完了できないクライアントへの影響も考慮します。CAPTCHA／Challengeを利用できるリソースやクライアントには条件があるため、対象リソースでのサポート状況をAWS WAFの公式ドキュメントで確認してください。

初めて適用するルールや誤検知の可能性があるルールは、まずCountで観測する方法が一般的です。一致ログを調べて正常なリクエストが含まれていないか確認し、必要なら条件や除外ルールを調整してからBlockなどへ切り替えます。Countは保護の代わりに通信を遮断するアクションではないため、すでに攻撃が確認されている場合は適切な遮断策も併用します。

AWS WAFを関連付けられるリソース

AWS WAFは、対応するAWSリソースにWeb ACLを関連付けて保護します。主な関連付け先には、Amazon CloudFrontディストリビューション、Application Load Balancer、Amazon API GatewayのREST API、AWS AppSync GraphQL API、Amazon Cognitoユーザープール、AWS App Runnerサービス、AWS Verified Accessインスタンス、AWS Amplifyアプリ、Amazon Bedrock AgentCore Gatewayなどがあります。対応範囲は更新されることがあるため、設計時にはAWS WAFの最新の対応リソース一覧を確認してください。

Web ACLはCloudFrontスコープとリージョナルスコープに分かれます。CloudFrontディストリビューション用のWeb ACLはCloudFrontスコープで作成し、リージョナルスコープは対応するリージョナルリソースに使います。CloudFrontスコープのWeb ACLを管理するときは、AWS WAFのコントロールプレーン上で米国東部（バージニア北部）リージョンを選ぶ必要があります。リージョナルリソースにCloudFrontスコープのWeb ACLを付けることはできず、その逆もできません。

API Gatewayについては、API種別を確認します。WAFの対応対象として問われるのはREST APIであり、API GatewayのすべてのAPI種別へ一律に関連付けられるわけではありません。WAFを使いたいからといって「API Gateway」とだけ判断せず、REST APIかHTTP APIかなど、対象の種類を要件で確認します。

クォータと料金

Web ACL数、ルール数、ルールグループ数、Web ACLの容量（WCU）などにはクォータがあります。AWS公式の現行クォータ表では、Web ACL（protection pack）はアカウント・リージョンあたり既定100個、ルールグループもアカウント・リージョンあたり既定100個です。これらは引き上げを申請できます。クォータはサービス更新で変わることがあるため、設計時には利用リージョンとCloudFrontスコープを含めてAWS WAFのクォータおよびService Quotasを確認してください。

料金はWeb ACL、ルール、検査するリクエスト数、オプション機能やマネージドルールグループなどに応じて発生します。固定額を前提にせず、見積もり時点のAWS WAF料金ページで課金単位と追加料金を確認します。

DVA試験での選び方

• WebリクエストのURI、ヘッダー、クエリ、本文や既知のWeb攻撃を評価したいならAWS WAFを選びます。
• 一般的な攻撃への対策を早く取り入れる場合は、AWSまたはMarketplaceのマネージドルールグループを検討します。アプリケーション固有のIP、地域、リクエスト要素の条件にはカスタムルールを使います。
• 特定IPのアクセスを制御するときは、IPセットとルール条件を使います。地理条件を使う場合はGeo matchを使います。
• 特定送信元からの頻繁なアクセスを制限する場合は、集約条件と時間窓を設定したレートベースルールを検討します。ただし、IPが分散・変化する攻撃への完全な対策とはみなしません。
• 誤検知のリスクがある新しいルールはCountで観測し、一致したリクエストをログなどで確認してから遮断へ移行します。
• Web ACLは対象の対応リソースへ関連付ける必要があります。CloudFront用とリージョナル用のスコープを混同せず、対象APIやサービスの種類も確認します。
• Web ACLやルール数の上限と料金は固定値で暗記せず、導入時の公式クォータと料金を参照します。

公式ドキュメント

• AWS WAFとは
• AWS WAFの仕組み
• Web ACLルールの評価順序
• ルールアクション
• AWS Managed Rulesルールグループ
• レートベースルール
• RateBasedStatement APIリファレンス（評価時間窓）
• AWS WAFの対応リソースへの関連付け
• AWS WAFのクォータ
• AWS WAFの料金
• AWSのファイアウォールとトラフィック制御
• API Gatewayの高度な機能