AWS WAFをALBに設定する方法について

AWS WAFは、Webアプリケーションへの不正アクセスや攻撃リクエストを検知・制御するためのサービスです。

ALB、つまりApplication Load BalancerにAWS WAFを関連付けることで、ALBに到達するHTTP・HTTPSリクエストを検査し、条件に応じて許可、ブロック、カウントなどの制御を行えます。

ALBにAWS WAFを設定する際は、Regional Web ACLを作成し、対象のALBに関連付けます

。CloudFrontに設定するWAFとは扱いが異なるため、まずはこの違いを理解しておくことが重要です。

AWS WAFとALBの基本的な関係

ALBにはRegional Web ACLを関連付ける

ALBにAWS WAFを設定する場合は、Regional Web ACLを使用します。

Web ACLとは、AWS WAFにおけるルールのまとまりです。

どのようなリクエストを許可するのか、どのようなリクエストをブロックするのか、どのルールに一致したリクエストを記録するのか、といった制御内容をWeb ACLに設定します。

ALBにWAFを適用する場合、このWeb ACLをALBに関連付けることで、ALBに届くリクエストをWAFで検査できるようになります。

ALBとWeb ACLは同じリージョンにする

ALBに関連付けるWeb ACLは、ALBと同じリージョンに作成する必要があります。

たとえば、ALBが東京リージョンにある場合、Web ACLも東京リージョンで作成します。

ALBが大阪リージョンにある場合は、Web ACLも大阪リージョンに作成します。

CloudFront用のAWS WAFではグローバルスコープを使用しますが、ALBの場合はリージョナルスコープを使います。この違いを混同しないように注意してください。

AWS WAFをALBに設定する全体の流れ

Web ACLを作成する

まず、AWS WAFでWeb ACLを作成します。

Web ACLには、名前、説明、対象リージョン、デフォルトアクション、ルール、メトリクス設定などを指定します。

ALBに設定する場合は、スコープとしてRegionalを選び、ALBと同じリージョンを選択します。

ルールを追加する

次に、Web ACLにルールを追加します。

AWS WAFでは、AWSが提供しているマネージドルール、自分で作成するIP制限ルール、レート制限ルール、国別制限ルール、文字列一致ルールなどを設定できます。

最初から複雑なルールを大量に入れるのではなく、まずは必要最小限の構成から始めるのがおすすめです。

Web ACLをALBに関連付ける

Web ACLを作成したら、対象のALBに関連付けます。

Web ACL作成時にALBを選択することもできますし、Web ACL作成後に関連付けることもできます。

関連付けが完了すると、ALBに届くリクエストがAWS WAFの検査対象になります。

Countモードで検証する

本番環境にAWS WAFを導入する場合、いきなりブロック設定にするのはおすすめできません。

まずはCountモードで運用し、どのようなリクエストがルールに一致するのかを確認します。

Countモードでは、ルールに一致したリクエストを記録できますが、実際にはブロックしません。

そのため、正常なユーザーを誤って遮断するリスクを抑えながら検証できます。

問題がなければBlockに切り替える

Countモードで一定期間ログを確認し、正常なアクセスが誤検知されていないことを確認したら、必要なルールから順にBlockへ切り替えます。

すべてのルールを一度にBlockへ変更するのではなく、影響が小さいものや明らかに悪意のあるリクエストを検知するものから段階的に切り替えるのが安全です。

AWS WAFで設定できる主なルール

AWS Managed Rules

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

一般的なWeb攻撃、既知の悪意ある入力、SQLインジェクション、WordPress向けの攻撃パターンなどに対応できます。

代表的なルールグループには、一般的な脆弱性対策を目的としたもの、既知の悪性入力に対応するもの、IPレピュテーションを利用するもの、SQLインジェクション対策を目的としたものなどがあります。

Rate-based rule

Rate-based ruleは、一定時間内に大量のリクエストを送ってくるアクセス元を制御するためのルールです。

たとえば、同一IPアドレスから短時間に大量のアクセスがあった場合に、CountまたはBlockするように設定できます。

ただし、AWS WAFのレート制限は、厳密にリクエスト数を完全制御する仕組みではありません。

高頻度アクセスを検知し、アプリケーションの可用性を守るための仕組みとして理解するのが適切です。

また、以前は「5分間あたり」という説明がよく使われていましたが、現在は評価ウィンドウを設定できるため、「評価ウィンドウを5分にした場合」のように表現するとより正確です。

IP制限ルール

IP制限ルールでは、特定のIPアドレスを許可したり、ブロックしたりできます。

管理画面や社内向けページを保護したい場合に有効です。

ただし、社内IPを無条件にAllowすると、そのIPからのリクエストが後続のWAFルールを通らずに許可される可能性があります。

そのため、社内IPを許可する場合は、管理画面など特定のパスに限定して使うのが安全です。

Geo match rule

Geo match ruleは、アクセス元の国や地域を条件にしてリクエストを制御するルールです。

日本向けサービスで海外アクセスがほとんど不要な場合、国外からのアクセスをCountまたはBlockする設計が考えられます。

ただし、海外在住のユーザー、海外出張中の社員、検索エンジン、監視サービス、外部SaaS、Webhookなどを巻き込む可能性があります。

そのため、最初はBlockではなくCountで検証することが重要です。

文字列一致や正規表現によるルール

AWS WAFでは、URIパス、クエリ文字列、ヘッダー、Cookie、リクエストボディなどを条件にしてルールを作成できます。

たとえば、特定の管理画面パスへのアクセスを制限したり、特定のUser-Agentを持つリクエストを制御したりできます。

柔軟な制御ができる一方で、条件を複雑にしすぎると運用が難しくなるため、最初はシンプルなルールから始めるのがおすすめです。

ALB向けAWS WAFでおすすめの初期構成

基本はDefault actionをAllowにする

一般公開されているWebサイトやWebアプリケーションに後からAWS WAFを導入する場合、基本的にはDefault actionをAllowにする構成が多いです。

これは、明確に危険なリクエストだけをルールで検知し、それ以外の通常アクセスは許可する考え方です。

ただし、管理画面専用のALBや社内システム、限定公開APIなどでは、Default actionをBlockにして、必要な通信だけをAllowする設計もあります。

最初はAWS Managed RulesをCountで導入する

初期導入では、AWS Managed RulesをいきなりBlockにするのではなく、Countで運用するのがおすすめです。

特に、一般的な攻撃対策ルールやSQLインジェクション対策ルールは、アプリケーションの仕様によっては正常なフォーム送信やAPIリクエストを検知することがあります。

まずはCountで検知状況を確認し、問題がないルールからBlockに切り替えると安全です。

Rate-based ruleも最初はCountで確認する

Rate-based ruleも、最初はCountで設定するのがおすすめです。

アクセスの多いWebサイト、API、検索機能、管理画面、クローラー流入が多いサイトでは、正常なアクセスでも短時間に多くのリクエストが発生する場合があります。

ログを確認しながら、適切なレート制限値を調整してください。

明確な悪性IPはBlockしてよい

すでに攻撃元として判明しているIPアドレスや、明らかに不要なアクセス元がある場合は、IP setを使ってBlockすることもできます。

ただし、IPアドレスは変わることがあるため、IPブロックだけに頼るのではなく、Managed RulesやRate-based ruleと組み合わせて運用するのが現実的です。

AWS WAF導入時に注意すべきポイント

いきなりBlockにしない

AWS WAF導入時に最も避けたいのは、正常なユーザーを誤ってブロックしてしまうことです。

問い合わせフォーム、ログインフォーム、検索機能、管理画面、ファイルアップロード、決済処理、Webhook、API通信などは、WAFルールに引っかかる可能性があります。

本番環境では、まずCountで検証し、ログを確認してからBlockへ移行するのが基本です。

ALBではリクエストボディ検査サイズに注意する

ALBに関連付けたAWS WAFでは、リクエストボディの検査サイズに上限があります。

特にALBの場合、WAFが検査できるリクエストボディサイズには制限があるため、大きなJSON、長いフォーム入力、ファイルアップロードなどを扱うアプリケーションでは注意が必要です。

WAFはすべてのリクエスト内容を無制限に検査できるわけではありません。

大きなリクエストボディを扱う場合は、WAFの検査範囲とアプリケーション側のバリデーションを組み合わせて考える必要があります。

社内IPのAllowは慎重に設計する

社内IPや監視サービスのIPをAllowする設計はよくあります。

しかし、無条件でAllowすると、その通信が後続のWAFルールによる検査を受けずに通過する可能性があります。

そのため、社内IPを許可する場合は、全体を無条件に許可するのではなく、管理画面や特定のパスだけを対象にするのが安全です。

Webhookや外部サービスをブロックしないようにする

決済サービス、メール配信サービス、CRM、MAツール、チャットツール、ECプラットフォームなどを利用している場合、外部サービスからWebhookが送信されることがあります。

WAF設定によってこれらのWebhookをブロックすると、決済完了通知、注文通知、会員登録処理、メール配信連携などに影響が出る可能性があります。

WAF導入前に、外部サービスからの通信経路や対象URLを整理しておくと安心です。

WordPressではadmin-ajax.phpに注意する

WordPressサイトにAWS WAFを設定する場合、wp-login.phpやxmlrpc.phpへの対策は有効です。

一方で、管理画面全体を単純にIP制限すると、フロント側の機能に影響する場合があります。

特にWordPressでは、管理画面配下の一部ファイルがフロント側の機能で使われることがあります。

フォーム、予約機能、絞り込み検索、カート機能、会員機能などを使っている場合は、WAF導入後に動作確認を行う必要があります。

ログとメトリクスの設定

WAFログは必ず有効化する

AWS WAFを本番環境で運用するなら、ログの有効化は非常に重要です。

ログを有効化しておくことで、どのリクエストがどのルールに一致したのか、どのIPからアクセスがあったのか、どのパスで検知が発生しているのかを確認できます。

ログがないと、誤検知が発生した場合や、正常なアクセスがブロックされた場合に原因を調査しにくくなります。

ログ出力先を選ぶ

AWS WAFのログ出力先には、CloudWatch Logs、Amazon S3、Amazon Data Firehoseなどがあります。

初期導入ではCloudWatch Logsが扱いやすいです。

画面上で確認しやすく、導入直後の調査にも向いています。

長期保存や大量ログの分析を行う場合は、Amazon S3に保存し、必要に応じてAthenaなどで分析する構成も有効です。

外部のSIEMやログ分析基盤に連携したい場合は、Amazon Data Firehoseを使う構成が選択肢になります。

個人情報や認証情報の扱いに注意する

WAFログには、リクエストに含まれる情報が記録される場合があります。

Authorizationヘッダー、Cookie、APIキー、クエリ文字列、フォーム入力内容などに個人情報や認証情報が含まれる可能性がある場合は、ログ出力時のマスキング設定を検討してください。

ログはセキュリティ調査に役立つ一方で、扱いを誤ると情報漏えいリスクにもつながります。

CloudWatchメトリクスを確認する

AWS WAFでは、許可されたリクエスト、ブロックされたリクエスト、Countされたリクエストなどをメトリクスで確認できます。

導入初期は、特にCountされたリクエストの内容を確認することが重要です。

特定のルールだけ異常に検知が多くないか、特定のパスで誤検知が発生していないか、特定のIPやUser-Agentに偏っていないかを確認します。

WAFルールの評価順序

優先度の低い番号から評価される

AWS WAFのルールは、設定した優先度に従って評価されます。

基本的には、優先度の数字が小さいルールから順に評価されます。

そのため、どのルールを先に評価するかは非常に重要です。

例外ルールは慎重に上位へ配置する

特定のIPやパスを許可する例外ルールを上位に置くことはよくあります。

ただし、Allowルールに一致すると、その時点でリクエストが許可される場合があります。

そのため、上位に置くAllowルールは慎重に設計する必要があります。

たとえば、社内IPを全体に対してAllowするのではなく、管理画面へのアクセスに限定してAllowするなど、条件を絞ると安全です。

ブロックルールの順番も整理する

明確に拒否したいIP、管理画面保護、レート制限、IPレピュテーション、Managed Rulesというように、ルールの役割ごとに順番を整理しておくと運用しやすくなります。

ルールが増えるほど、どのルールでブロックされたのかを調査する機会も増えます。

後から見ても分かりやすいルール名やメトリクス名を付けておくことも大切です。

WCUと料金の注意点

WCUとは何か

AWS WAFには、WCUという考え方があります。

WCUは、Web ACL内のルールやルールグループが消費する処理容量のようなものです。

AWS Managed Rulesを複数追加したり、複雑な条件を持つカスタムルールを設定したりすると、WCUの使用量が増えます。

ルールを入れすぎない

セキュリティを強化したいからといって、関連しそうなManaged Rulesをすべて入れればよいわけではありません。

不要なルールを入れすぎると、WCUや料金が増えるだけでなく、誤検知の調査も難しくなります。

まずはアプリケーションの構成やリスクに合ったルールから導入し、必要に応じて追加していくのがおすすめです。

料金とログコストも確認する

AWS WAFでは、Web ACL、ルール、リクエスト数、Bot ControlやCAPTCHAなどの追加機能、ログ保存などによって費用が発生します。

また、WAFログをCloudWatch LogsやS3に保存する場合、ログ量に応じた料金も考慮する必要があります。

アクセス数が多いサイトでは、WAF本体の料金だけでなく、ログ保存や分析コストも含めて設計してください。

用途別の設定パターン

一般的なコーポレートサイトの場合

一般的なコーポレートサイトでは、AWS Managed Rulesを中心に構成するのがおすすめです。

まずは、一般的な脆弱性対策、既知の悪性入力対策、IPレピュテーション、レート制限などをCountで導入します。

問い合わせフォームや資料請求フォームがある場合は、フォーム送信がWAFに誤検知されないかを必ず確認してください。

WordPressサイトの場合

WordPressサイトでは、ログイン画面やXML-RPCへの攻撃が多くなりやすいため、wp-login.phpやxmlrpc.phpへの対策を検討します。

WordPress向けのManaged Rulesも選択肢になります。

ただし、プラグインやテーマによって通信内容が異なるため、WAF導入後は管理画面、フォーム、検索、カート、会員機能などを一通り確認することが重要です。

APIサーバーの場合

APIサーバーでは、JSONリクエストや認証ヘッダー、Webhook、外部サービス連携に注意が必要です。

SQLインジェクション対策やレート制限は有効ですが、正常なAPIリクエストが誤検知される可能性もあります。

APIごとにアクセス量やリクエスト内容が異なるため、パス単位でレート制限や除外条件を検討すると運用しやすくなります。

管理画面を保護する場合

管理画面を保護したい場合は、パス条件とIP条件を組み合わせるのが有効です。

たとえば、管理画面へのアクセスは社内IPやVPN経由のみに限定し、それ以外はブロックする設計が考えられます。

ただし、管理画面だけでなくフロント側から利用されるパスが含まれていないか、事前に確認してください。

本番導入前のチェックポイント

リージョンを確認する

ALBとWeb ACLが同じリージョンにあるかを確認します。

CloudFront用のWeb ACLと混同していないかも確認してください。

主要なアクセス経路を整理する

ユーザーアクセス、管理者アクセス、監視サービス、外部SaaS、Webhook、決済サービス、検索エンジンなど、どのようなアクセスがALBに届くのかを整理します。

この整理が不十分だと、WAF導入後に必要な通信を誤ってブロックしてしまう可能性があります。

Countで検証する期間を設ける

本番導入では、Countで検証する期間を設けることが重要です。

少なくとも、通常時のアクセス、キャンペーン時のアクセス、問い合わせフォーム送信、管理画面操作、決済処理、Webhook受信などを確認できる期間はCountで様子を見ると安全です。

ログとメトリクスを確認する

WAFを関連付けただけで終わらせず、ログとメトリクスを確認します。

どのルールがどの程度検知しているか、正常アクセスが含まれていないか、特定のパスやIPに偏りがないかを確認してください。

Blockへの切り替えは段階的に行う

問題がなさそうなルールから順にBlockへ切り替えます。

特に、影響範囲が大きいManaged RulesやSQLインジェクション対策ルールは慎重に切り替えるべきです。

切り替え後も、しばらくはログを重点的に確認してください。

よくある失敗例

Managed RulesをいきなりBlockにする

最も多い失敗のひとつが、AWS Managed RulesをいきなりBlockにしてしまうことです。

アプリケーションによっては、正常なリクエストが攻撃パターンに近い形で検知されることがあります。

特に、問い合わせフォーム、検索機能、管理画面、API、ファイルアップロード、決済処理などは注意が必要です。

ALBとWeb ACLのリージョンを間違える

ALBに関連付けるWeb ACLはRegionalです。

ALBと異なるリージョンにWeb ACLを作成していると、対象ALBに関連付けられません。

CloudFront用のWeb ACLとはスコープが異なるため、設定時に確認してください。

社内IPを無条件でAllowする

社内IPを上位ルールで無条件にAllowすると、そのIPからのリクエストが後続のWAFルールによる検査を受けずに許可される可能性があります。

社内IPのAllowは便利ですが、対象パスを限定するなど、設計を慎重に行う必要があります。

Webhookをブロックする

外部サービスからのWebhookをWAFでブロックしてしまうと、システム連携に影響します。

決済完了通知、注文通知、メール配信連携、チャット通知、CRM連携などが止まる可能性があります。

WAF導入前に、外部サービスからの通信を洗い出しておきましょう。

ログを有効化していない

WAFログを有効化していないと、ブロックや誤検知が発生した際に原因を調査できません。

本番環境でAWS WAFを使う場合は、ログを有効化し、少なくとも導入初期はこまめに確認することが重要です。

まとめ

AWS WAFをALBに設定するには、ALBと同じリージョンにRegional Web ACLを作成し、そのWeb ACLをALBに関連付けます。

設定自体は難しくありませんが、本番運用ではルール設計と検証が非常に重要です。

特に重要なのは、最初からBlockにしないことです。

まずはCountモードで検知状況を確認し、正常なアクセスが誤検知されていないことを確認してから、段階的にBlockへ切り替えるのが安全です。

また、ALBではリクエストボディ検査サイズに制限があるため、大きなリクエストを扱うアプリケーションでは、WAFだけでなくアプリケーション側の入力検証や認証、レート制限なども組み合わせて対策する必要があります。

AWS WAFは、適切に設計すればALB配下のWebアプリケーションを保護する強力な仕組みです。

一方で、設定を誤ると正常なユーザーや外部サービスをブロックしてしまうリスクもあります。

導入時は、Web ACLのリージョン、ルールの評価順序、Countモードでの検証、ログの有効化、Webhookや管理画面への影響を確認しながら、段階的に運用を始めるのがおすすめです。

以上、AWS WAFをALBに設定する方法についてでした。

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