AWS WAFの設定方法について

AWS WAFは、WebサイトやWebアプリケーションに届くHTTP/HTTPSリクエストを検査し、不審なアクセスや攻撃パターンを検知・制御するためのWeb Application Firewallです。

CloudFront、Application Load Balancer、API Gateway、AppSync、Cognito、App Runner、AmplifyなどのAWSリソースに関連付けて利用できます。

SQLインジェクション、クロスサイトスクリプティング、不審なBotアクセス、短時間の大量リクエスト、管理画面への不正アクセスなどを防ぐ目的で使われます。

AWS WAFの設定では、単にルールを追加するだけでなく、誤検知を避けながら段階的に防御を強めることが重要です。

特に本番環境では、最初からすべてのルールをブロック設定にするのではなく、まずは検知のみの状態で運用し、ログを確認しながら調整していくのが安全です。

AWS WAFの基本構成

Web ACLとは

AWS WAFでは、保護設定のまとまりをWeb ACLと呼びます。

Web ACLには、どのようなリクエストを許可するか、ブロックするか、検知だけにするかといったルールを設定します。

そして、そのWeb ACLをCloudFrontやALB、API Gatewayなどの保護対象リソースに関連付けることで、AWS WAFが有効になります。

現在のAWSコンソールでは、Web ACLに加えて「Protection pack / web ACL」という表記が使われることもあります。

基本的には、Web ACLを作成し、その中にルールを追加し、対象リソースに関連付けるという流れで考えれば問題ありません。

AWS WAFで保護できる主なリソース

AWS WAFは、さまざまなAWSサービスに適用できます。

代表的な保護対象としては、Webサイト配信に使うCloudFront、EC2やECSなどの前段に置くApplication Load Balancer、REST APIを提供するAPI Gateway、GraphQL APIのAppSync、認証基盤のCognito User Poolなどがあります。

CloudFrontに設定する場合はグローバルスコープのWeb ACLを使います。

一方、ALBやAPI Gatewayなどのリージョナルリソースに設定する場合は、対象リソースと同じリージョンでWeb ACLを作成する必要があります。

この違いは設定時に迷いやすいポイントです。

CloudFrontを守るのか、ALBやAPI Gatewayを守るのかによって、選ぶスコープやリージョンが変わります。

AWS WAF設定前に決めておくこと

どのリソースを保護するか

まず最初に、どのAWSリソースをAWS WAFで守るのかを決めます。

Webサイト全体をCloudFrontで配信している場合は、CloudFrontにAWS WAFを関連付けるのが一般的です。

ALBの背後にWebアプリケーションがある場合は、ALBにAWS WAFを関連付けます。

APIを保護したい場合は、API GatewayやALBに設定します。

どこにWAFを設置するかによって、検査できるリクエストの範囲や、WAFが認識する送信元IPが変わります。

そのため、サイト構成を確認したうえで設定場所を決めることが大切です。

何を防ぎたいか

AWS WAFのルール設計では、何を防ぎたいのかを明確にする必要があります。

一般的なWeb攻撃を防ぎたいのか、WordPressの管理画面を守りたいのか、ログイン画面への総当たり攻撃を抑えたいのか、APIの大量リクエストを制限したいのかによって、設定すべきルールは変わります。

たとえば、一般的なWebサイトであればAWS Managed Rulesを中心に設定します。

WordPressサイトであれば、WordPress向けのルールや、wp-login.php、wp-admin、xmlrpc.phpへの制御が重要になります。

APIであれば、エンドポイントごとのレート制限やリクエストボディの検査を検討する必要があります。

AWS WAFの基本的な設定手順

AWS WAFの管理画面を開く

AWSマネジメントコンソールにログインし、AWS WAFまたはWAF & Shieldを開きます。

左側のメニューからWeb ACLs、またはProtection packs / web ACLsを選択し、新しいWeb ACLを作成します。

Web ACLを作成する

Web ACLの作成画面では、名前、説明、スコープ、リージョン、関連付けるAWSリソースなどを設定します。

名前は、環境や用途が分かるように付けると管理しやすくなります。

たとえば、本番用、ステージング用、CloudFront用、API用などが分かる命名にしておくと、後から見直すときに便利です。

保護対象リソースを関連付ける

次に、Web ACLをどのリソースに関連付けるかを選択します。

CloudFrontを保護する場合はCloudFrontディストリビューションを選びます。

ALBを保護する場合は対象のApplication Load Balancerを選択します。API Gatewayを保護する場合は、対象のAPIステージに関連付けます。

1つのAWSリソースに関連付けられるWeb ACLは基本的に1つです。

一方で、1つのWeb ACLを複数のリソースに関連付けることはできます。

ただし、CloudFront用のWeb ACLとリージョナルリソース用のWeb ACLはスコープが異なるため、同じWeb ACLで混在させることはできません。

AWS Managed Rulesを設定する

AWS Managed Rulesとは

AWS Managed Rulesは、AWSが管理しているルールグループです。

一般的な攻撃パターンや既知の悪性入力、不審なIPアドレス、SQLインジェクション、WordPress特有の攻撃などに対応するルールが用意されています。

自分で細かい攻撃パターンをすべて定義しなくても、基本的な防御を始められる点が大きなメリットです。

最初に入れたい代表的なルール

一般的なWebサイトであれば、まずはCommon Rule Set、Known Bad Inputs、SQLi Rule Set、Amazon IP Reputation Listなどを検討します。

Common Rule Setは、一般的なWebアプリケーション攻撃に対応する基本的なルールです。

Known Bad Inputsは、既知の悪性パターンを検知するためのルールです。

SQLi Rule Setは、SQLインジェクション対策に使います。

Amazon IP Reputation Listは、AWSが把握している評判の悪いIPアドレスからのアクセスを検知・制御するために使います。

WordPressサイトであれば、WordPress向けのManaged Rule Groupも検討するとよいでしょう。

初期設定ではCountで検証する

AWS Managed Rulesを本番環境に入れる場合、最初からすべてをBlockにするのはおすすめしません。

正常なユーザーのリクエストや、フォーム送信、検索、管理画面操作、API通信などが誤って攻撃と判定される可能性があるためです。

特にCMS、ECサイト、会員サイト、APIを持つWebサービスでは、誤検知が業務影響につながることがあります。

そのため、初期導入ではルールをCountに設定し、実際のトラフィックでどのルールにどの程度マッチするかを確認します。

問題がないことを確認したうえで、段階的にBlockへ移行するのが安全です。

カスタムルールの設定

管理画面へのアクセス制限

AWS WAFでは、管理画面へのアクセスを特定IPだけに制限することができます。

WordPressのwp-adminやwp-login.php、自社CMSの管理画面、社内用管理パネルなどは攻撃対象になりやすいため、可能であればIP制限を設定するのがおすすめです。

ただし、社内IPを単純にAllowするルールを上位に置く場合は注意が必要です。

AWS WAFでは、Allowにマッチすると後続のルール評価が止まるため、その後のManaged Rulesによる検査が行われなくなる可能性があります。

そのため、実務では「管理画面パスに対して、信頼済みIP以外をブロックする」という設計のほうが安全な場合があります。

この方法であれば、信頼済みIPからのアクセスは管理画面に到達できますが、後続のルールによる検査も継続しやすくなります。

レートベースルールの設定

レートベースルールは、一定時間内に同じ送信元から大量のリクエストが来た場合に、CountやBlockなどのアクションを実行するルールです。

ログイン画面、検索画面、問い合わせフォーム、APIエンドポイントなど、短時間に大量アクセスされると困る箇所に有効です。

以前は「5分間で何回」という説明をされることが多いですが、現在のAWS WAFでは評価ウィンドウを1分、2分、5分、10分から選択できます。

デフォルトは5分ですが、ログイン攻撃やAPI連打のように短時間の挙動を見たい場合は、1分や2分の評価ウィンドウを検討することもあります。

レート制限のしきい値は、サイト規模や通常時のアクセス量によって大きく変わります。

小規模なコーポレートサイトと、アクセス数の多いメディアサイトやECサイトでは適切なしきい値が異なります。

最初はCountで状況を確認し、通常ユーザーや検索エンジン、監視ツールに影響が出ない範囲で調整しましょう。

国別アクセス制限

AWS WAFでは、アクセス元の国に基づいてリクエストを制御できます。

日本国内向けのサービスで海外からのアクセスが不要な場合、国別ブロックを設定することがあります。

ただし、国別制限は慎重に扱うべきです。

海外在住の日本人ユーザー、海外出張中の顧客、海外拠点の社内ユーザー、検索エンジンBot、広告審査Bot、SNSクローラー、外部監視サービスなどが影響を受ける可能性があります。

そのため、いきなり海外アクセスをすべてブロックするのではなく、まずはCountで国別アクセス状況を確認するのがおすすめです。

必要に応じて、サイト全体ではなく管理画面や一部APIだけに国別制限を適用する方法もあります。

User-Agentによる制御

User-Agentを条件にして、不審なクローラーや攻撃ツールらしいアクセスを制御することもできます。

たとえば、自動スクリプトや脆弱性スキャンツールに見られるUser-Agentを検知し、CountまたはBlockする方法があります。

ただし、User-Agentは簡単に偽装できます。そのため、User-Agentだけで強いブロックを行うのではなく、アクセス先のパス、リクエストメソッド、アクセス頻度などと組み合わせて判断するほうが安全です。

ルールの優先順位

ルールは上から順に評価される

AWS WAFでは、Web ACL内のルールは優先順位に従って評価されます。

そのため、どのルールを上に置くかは非常に重要です。

特にBlockやAllowのような終了アクションにマッチすると、後続ルールの評価が止まる場合があります。

たとえば、信頼済みIPを広くAllowするルールを最上位に置くと、そのIPからのリクエストはManaged Rulesで検査されずに通過してしまう可能性があります。

これは一見便利ですが、セキュリティ上の抜け道になる場合があります。

優先順位の考え方

基本的には、明確にブロックすべき条件を上位に置き、一般的な検知ルールやManaged Rulesをその後に配置する構成が分かりやすいです。

管理画面への不正アクセス制限、緊急で遮断したいIP、ログインやAPIへのレート制限などは上位に配置します。

その後にAWS Managed Rulesを置き、最後にデフォルトアクションとしてAllowを設定する構成が一般的です。

ただし、サイトによって最適な順番は変わります。

重要なのは、Allowルールを広く使いすぎないこと、Blockルールの影響範囲を把握すること、Countで検証してから本格的にBlockへ移行することです。

ログの設定

AWS WAFではログ確認が必須

AWS WAFを設定したら、ログを有効化することを強くおすすめします。

ログがないと、どのルールにマッチしたのか、なぜブロックされたのか、正常ユーザーが影響を受けていないかを確認できません。

WAFは一度設定して終わりではなく、ログを見ながら調整する前提のサービスです。

ログの出力先

AWS WAFのログは、CloudWatch Logs、Amazon S3、Amazon Data Firehoseなどに出力できます。

すぐに確認したい場合はCloudWatch Logsが便利です。

長期保存やAthenaによる分析を行いたい場合はS3が向いています。

SIEM連携や外部分析基盤に送る場合はAmazon Data Firehoseを使うことがあります。

S3にAWS WAFログを直接出力する場合、バケット名に一定の命名条件がある点にも注意が必要です。

ログ出力先の制約は設定時に確認しておきましょう。

ログで確認すべき項目

ログでは、ブロックされたリクエストだけでなく、Countされたリクエストも確認することが重要です。

どのIPからアクセスが来ているか、どの国からのアクセスが多いか、どのURIが狙われているか、どのルールに多くマッチしているかを確認します。

特に本番導入直後は、ログイン画面、問い合わせフォーム、購入フロー、管理画面、APIエンドポイントなどで正常なリクエストが誤検知されていないかを重点的に見ます。

誤検知への対応

誤検知が起こりやすいケース

AWS WAFでは、正常なリクエストが攻撃として検知されることがあります。

たとえば、問い合わせフォームにHTMLタグや記号が多く含まれる場合、CMSの記事投稿でコード断片を入力する場合、検索フォームにSQL風の文字列が入る場合、大きなJSONをAPIに送信する場合などです。

ECサイトでは、住所入力、クーポン入力、レビュー投稿、決済関連の通信などが誤検知の確認対象になります。

会員サイトでは、ログイン、会員登録、プロフィール更新、パスワード変更などを確認する必要があります。

個別ルールを調整する

誤検知が発生した場合、Managed Rule Group全体を無効化するのではなく、原因となっている個別ルールを調整するのが基本です。

特定のルールだけCountにする、特定パスだけ対象外にする、特定条件のときだけ検査対象から外すなどの調整を行います。

特に、フォームやCMS投稿画面など、正常な入力でも攻撃に似た文字列が入りやすい箇所では、スコープを絞った調整が必要です。

スコープダウンで対象範囲を絞る

スコープダウンを使うと、特定のパスだけにルールを適用したり、逆に特定のパスをルール対象から外したりできます。

たとえば、ログイン画面だけにレート制限を適用する、管理画面だけに国別制限を適用する、問い合わせフォームだけ特定ルールをCountにする、といった調整が可能です。

サイト全体に強いルールを適用すると影響が大きくなりやすいため、必要な範囲に絞ってルールを適用することが重要です。

IP制限で注意すべきこと

AWS WAFが見ているIPを確認する

IP制限、国別制限、レート制限を設定する場合、AWS WAFがどのIPアドレスを見ているかを確認する必要があります。

通常はリクエストの送信元IPを見ますが、外部CDN、プロキシ、ロードバランサーなどを経由している構成では、本来のユーザーIPではなく、手前のプロキシやCDNのIPとして認識される場合があります。

この状態でIP制限やレート制限を設定すると、意図した制御にならない可能性があります。

特に多段構成のWebサイトでは、WAFログを確認し、実際にどのIPが記録されているかを見てからルールを設計する必要があります。

X-Forwarded-Forの扱い

構成によっては、X-Forwarded-Forなどのヘッダーに含まれるIPアドレスを使って制御することがあります。

ただし、ヘッダーは経路や設定によって扱いが変わるため、信頼できるプロキシやCDNを経由していることを前提に設計する必要があります。

単純にヘッダーの値だけを信頼すると、偽装されたIPをもとに判断してしまうリスクがあります。

リクエストボディ検査の注意点

検査できるサイズには上限がある

AWS WAFでは、リクエストボディを検査できますが、検査できるサイズには上限があります。

ALBやAppSyncでは検査できるボディサイズに固定の上限があります。

CloudFront、API Gateway、Cognito、App Runner、Verified Accessなどでは、デフォルトの検査サイズがあり、設定によって拡張できる場合があります。

ファイルアップロード、大きなJSON、長文フォーム、リッチテキスト投稿などを扱うサイトでは、WAFがどこまで検査しているのかを理解しておく必要があります。

大きなPOSTリクエストは慎重に扱う

大きなリクエストボディを扱うサービスでは、WAFの検査範囲を超える部分が発生する可能性があります。

そのため、アップロード機能やAPIの大きなPOSTリクエストに対しては、AWS WAFだけに依存せず、アプリケーション側でもバリデーションや認証・認可を適切に行う必要があります。

CloudFrontでAWS WAFを使う場合の注意点

オリジン直アクセスを防ぐ

CloudFrontにAWS WAFを設定している場合でも、ALBやS3、EC2などのオリジンに直接アクセスできる状態だと、攻撃者がCloudFrontとAWS WAFを迂回できる可能性があります。

そのため、CloudFrontでAWS WAFを使う場合は、オリジン直アクセスを防ぐ設計も重要です。

ALBであれば、CloudFrontからのアクセスだけを許可するようにセキュリティグループを設計します。

S3であれば、Origin Access Controlを使い、CloudFront経由でのみアクセスできるようにします。

独自のオリジンを使う場合は、CloudFrontから送るカスタムヘッダーをオリジン側で検証する方法もあります。

AWS WAFをCloudFrontに付けただけで安心するのではなく、オリジンが直接攻撃されない構成になっているかを確認しましょう。

用途別のおすすめ設定

一般的なコーポレートサイト

一般的なコーポレートサイトでは、AWS Managed Rulesを中心に導入し、管理画面や問い合わせフォームを重点的に保護する構成がおすすめです。

まずはCommon Rule Set、Known Bad Inputs、SQLi Rule Set、Amazon IP Reputation ListなどをCountで導入します。

問い合わせフォームや資料請求フォームがある場合は、誤検知が起きていないかを確認します。

管理画面がある場合は、信頼済みIP以外からのアクセスをブロックするルールを追加します。

全体への大量アクセス対策として、レートベースルールも検討するとよいでしょう。

WordPressサイト

WordPressサイトでは、wp-login.php、wp-admin、xmlrpc.phpへの対策が重要です。

wp-adminは信頼済みIP以外をブロックする構成が有効です。

wp-login.phpにはレート制限を設定し、ログイン試行が異常に多いIPを検知・ブロックできるようにします。

xmlrpc.phpを使っていない場合は、ブロックを検討してもよいでしょう。

AWS Managed Rulesでは、Common Rule Set、Known Bad Inputs、SQLi Rule Setに加えて、WordPress向けのルールグループも候補になります。

ただし、プラグインや管理画面操作で誤検知が起きる可能性があるため、最初はCountで確認することが大切です。

API

APIでは、エンドポイントごとにルールを分けるのが重要です。

ログイン、会員登録、パスワードリセット、検索、決済、投稿、コメントなど、攻撃や悪用の対象になりやすいエンドポイントに対して、個別にレート制限を設計します。

APIでは、正常なクライアントが高頻度でアクセスする場合もあるため、単純なIP単位の制限だけでは不十分な場合があります。

認証状態、APIキー、Cookie、Authorizationヘッダー、パスごとの通常アクセス量を確認しながら調整しましょう。

ECサイト

ECサイトでは、セキュリティと売上機会のバランスが重要です。

ログイン、会員登録、商品検索、カート追加、購入手続き、決済、クーポン入力、レビュー投稿、問い合わせフォームなど、ユーザー行動に直結する機能が多いため、誤検知が売上に影響する可能性があります。

そのため、ECサイトでは特にCountでの検証期間を設け、購入フローや決済連携に影響がないかを丁寧に確認する必要があります。

Bot対策やスクレイピング対策を強化する場合も、検索エンジンや広告審査、価格比較サービスなどへの影響を確認しましょう。

AWS WAFの料金で注意すること

基本料金の考え方

AWS WAFでは、Web ACL、ルール、リクエスト数などに応じて料金が発生します。

小規模サイトであれば大きな費用になりにくいケースもありますが、アクセス数が多いサイトや、多数のルールを設定するサイトでは費用が増える可能性があります。

追加料金が発生しやすい機能

Bot Control、Fraud Control、CAPTCHA、Challenge、Marketplaceのマネージドルール、ログ保存、大きなリクエストボディ検査などは、追加料金に注意が必要です。

特にBot Controlは便利ですが、トラフィック量によっては費用が大きくなることがあります。

導入前に料金ページを確認し、想定リクエスト数をもとに概算費用を把握しておくと安心です。

AWS WAF運用の流れ

初期導入時

初期導入時は、Web ACLを作成し、保護対象リソースに関連付け、AWS Managed Rulesと必要なカスタムルールを追加します。

この段階では、Managed Rulesやレート制限の多くをCountに設定し、実際のトラフィックを観察します。

ログを有効化し、どのルールがどのリクエストにマッチしているかを確認できる状態にしておきます。

検証期間

導入後の数日から1〜2週間程度は、ログを確認しながら誤検知の有無を見ます。

問い合わせフォーム、ログイン、会員登録、購入、決済、管理画面、APIなど、重要な機能が問題なく使えているかを確認します。

正常なアクセスがCountされている場合は、そのルールをすぐにBlockにせず、除外やスコープダウンを検討します。

本格運用

検証期間で問題がないルールから、段階的にBlockへ移行します。

すべてのルールを一度にBlockへ変更するのではなく、影響範囲の小さいものから順番に切り替えるのが安全です。

変更後もログを確認し、正常ユーザーへの影響がないかを見ます。

継続的な見直し

AWS WAFは一度設定したら終わりではありません。

新しいフォームを追加したとき、APIを変更したとき、CMSやプラグインを更新したとき、キャンペーンでアクセスが急増するときなどは、WAFルールの影響を確認する必要があります。

また、攻撃傾向やBotの挙動は変化するため、定期的にログを確認し、ルールやしきい値を見直しましょう。

AWS WAF設定でよくある失敗

最初からすべてBlockにする

最も多い失敗は、Managed Rulesを追加してすぐにすべてBlockにしてしまうことです。

これにより、正常なフォーム送信や管理画面操作、API通信、購入フローがブロックされる可能性があります。

本番環境では、まずCountで検証し、問題ないルールからBlockに移行するのが基本です。

ログを有効化していない

ログを有効化していないと、ブロックの原因が分かりません。

ユーザーから「フォームが送信できない」「ログインできない」と問い合わせが来ても、どのルールが原因なのか調査できなくなります。

AWS WAFを導入するなら、ログ設定は必須と考えたほうがよいです。

Allowルールを広く使いすぎる

信頼済みIPや特定条件をAllowするルールは便利ですが、広く使いすぎると後続の検査を回避してしまう可能性があります。

特に、社内IPを全面的にAllowするような設定は慎重に扱うべきです。

必要なパスや条件に絞って許可・ブロックを設計しましょう。

レート制限のしきい値が低すぎる

レート制限のしきい値が低すぎると、正常なユーザーまで制限される可能性があります。

企業ネットワークやNAT環境では、複数ユーザーが同じIPからアクセスしているように見えることがあります。

そのため、単純にIP単位で厳しい制限をかけると、社内ユーザーや大規模組織のユーザーに影響する場合があります。

オリジン直アクセスを放置する

CloudFrontにAWS WAFを設定していても、ALBやS3などのオリジンに直接アクセスできる状態では、WAFを迂回される可能性があります。

CloudFront構成では、オリジン直アクセスを防ぐ設計まで含めて確認することが重要です。

AWS WAFだけに頼らないことも重要

WAFは脆弱性修正の代替ではない

AWS WAFは攻撃を緩和するための重要な仕組みですが、アプリケーション側の脆弱性修正を不要にするものではありません。

SQLインジェクション対策であれば、アプリケーション側でパラメータ化クエリを使う必要があります。

XSS対策であれば、出力エスケープや入力値検証が必要です。

認証・認可、CSRF対策、セッション管理、依存ライブラリの更新なども引き続き重要です。

AWS WAFは防御層のひとつとして考え、アプリケーション、インフラ、監視、ログ分析と組み合わせて運用しましょう。

まとめ

AWS WAFの設定では、Web ACLを作成し、CloudFrontやALB、API Gatewayなどの保護対象リソースに関連付け、AWS Managed Rulesやカスタムルールを追加していきます。

基本的な流れは、AWS Managed RulesをCountで導入し、ログを確認しながら誤検知を調整し、問題のないルールから段階的にBlockへ移行するというものです。

特に重要なのは、最初から強いブロック設定にしないことです。

正常なユーザーや検索エンジン、広告審査、外部サービス、APIクライアントに影響が出ないよう、ログを見ながら慎重に調整する必要があります。

また、管理画面へのIP制限、ログインやAPIへのレート制限、CloudFront利用時のオリジン直アクセス対策、WAFが見ているIPの確認、リクエストボディ検査の制限、料金面の確認も重要です。

AWS WAFは、設定して終わりのサービスではありません。

サイトやアプリケーションの変更、アクセス状況、攻撃傾向に合わせて継続的に見直すことで、正常なユーザー体験を保ちながら、Webアプリケーションの防御力を高めることができます。

以上、AWS WAFの設定方法についてでした。

最後までお読みいただき、ありがとうございました。