AWS WAFでのIPセットの作成と管理について

AWS WAFのIPセットとは、特定のIPアドレスやIPアドレス範囲をまとめて管理するためのリストです。

IPセット自体には、「許可する」「ブロックする」といった動作はありません。

実際の制御は、Web ACLやルールグループ内でIPセットを参照し、そのルールに設定したアクションによって行います。

たとえば、次のような用途で使われます。

管理画面にアクセスできるIPを限定したい場合、攻撃元として判明しているIPをブロックしたい場合、社内ネットワークや監視サービスのIPだけを例外扱いしたい場合などです。

AWS WAFでIPアドレスを使ったアクセス制御を行う場合、IPセットは非常に基本的で重要な機能です。

IPセットで指定できるIPアドレス

IPアドレスはCIDR形式で指定する

AWS WAFのIPセットでは、IPv4またはIPv6のIPアドレスをCIDR形式で指定します。

単一のIPv4アドレスを登録する場合は、末尾に「/32」を付けます。

単一のIPv6アドレスを登録する場合は、「/128」を付けます。

つまり、IPセットに登録する値は、単なるIPアドレス文字列ではなく、IPアドレス範囲として扱える形式で指定する必要があります。

IPv4とIPv6は分けて管理する

AWS WAFのIPセットは、IPv4用とIPv6用を分けて作成します。

たとえば、同じ「ブロック対象IPリスト」であっても、IPv4用のIPセットとIPv6用のIPセットを別々に用意するのが基本です。

IPv6に対応しているWebサイトでは、IPv4だけを制限しても、IPv6経由のアクセスが制御対象から漏れる可能性があります。

そのため、必要に応じてIPv6のIPセットも作成しておくことが重要です。

「/0」は使用できない

AWS WAFのIPセットでは、IPv4やIPv6のCIDR範囲を指定できますが、「/0」は使用できません。

すべてのIPアドレスを対象にしたい場合は、IPセットで全範囲を指定するのではなく、Web ACLのデフォルトアクションやルール条件の設計で対応します。

IPセットの作成時に決めること

スコープを選ぶ

IPセットを作成するときは、まずスコープを選びます。

CloudFrontを保護する場合は、CloudFront用のグローバルスコープで作成します。

一方、Application Load Balancer、API Gateway、AppSyncなどのリージョンリソースを保護する場合は、対象リージョンのRegionalスコープで作成します。

CloudFront用のWeb ACLでRegional用のIPセットを使うことはできません。

逆に、Regionalリソース用のWeb ACLでCloudFront用のIPセットを使うこともできません。

そのため、IPセットを作る前に、どのリソースをAWS WAFで保護するのかを明確にしておく必要があります。

IPバージョンを選ぶ

IPセットを作成するときは、IPv4用にするか、IPv6用にするかを選びます。

あとからIPv4とIPv6を混在させることはできないため、必要に応じて別々のIPセットを作成します。

たとえば、管理画面へのアクセス許可リストを作る場合でも、IPv4用とIPv6用を分けて管理します。

用途を明確にする

IPセットは、用途ごとに分けて作成すると管理しやすくなります。

たとえば、管理者アクセス許可用、恒久的なブロック用、一時的なブロック用、監視サービスの許可用などです。

すべてのIPアドレスを1つのIPセットにまとめてしまうと、後から見たときに「なぜこのIPが登録されているのか」が分かりにくくなります。

運用しやすいIPセットにするには、作成時点で用途を明確にしておくことが大切です。

IPセットの主な使い方

特定IPをブロックする

最も分かりやすい使い方は、悪質なアクセス元IPをブロックすることです。

攻撃元、スパム送信元、不審なBot、過剰アクセスを行うIPなどをIPセットに登録し、そのIPセットに一致するリクエストをブロックします。

ただし、IPアドレスは変わることがあります。

特に一時的な攻撃元IPを恒久的にブロックし続けると、後で正規ユーザーに影響する可能性もあります。

そのため、一時ブロック用と恒久ブロック用のIPセットを分けて管理するのがおすすめです。

特定IPだけを許可する

社内ネットワーク、VPN、管理者IPなど、特定のIPアドレスだけを許可したい場合にもIPセットを使えます。

たとえば、社内IPだけが管理画面にアクセスできるようにしたい場合、許可対象のIPをIPセットに登録し、それ以外のIPをブロックするルールを作成します。

このとき、単純に「許可IPをAllowする」設計にすると、後続のセキュリティルールを通過してしまう場合があります。

そのため、管理画面のIP制限では、「管理画面にアクセスしてきたリクエストのうち、許可IPセットに含まれていないものをブロックする」という設計の方が安全なケースが多いです。

管理画面を保護する

WordPressやCMSの管理画面を保護する場合、IPセットは非常に有効です。

たとえば、ログインページや管理画面のURLに対して、許可されたIP以外のアクセスをブロックすることで、不正ログイン試行や総当たり攻撃のリスクを下げられます。

特に、管理画面がインターネットに公開されているサイトでは、IP制限は基本的な防御策のひとつです。

監視サービスや外部ツールを例外扱いする

Webサイトの監視サービス、広告効果測定ツール、外部診断ツールなどを利用している場合、それらのIPアドレスを例外として扱いたい場面があります。

AWS WAFのルールによって正規の監視アクセスがブロックされると、誤検知やアラートの原因になります。

そのため、信頼できるサービスのIPをIPセットで管理し、必要に応じて除外条件として使うことがあります。

IPセットをWeb ACLで使う仕組み

IPセットだけでは制御は行われない

IPセットを作成しただけでは、リクエストは許可もブロックもされません。

IPセットはあくまでIPアドレスのリストです。

実際にアクセス制御を行うには、Web ACLやルールグループ内のルールからIPセットを参照する必要があります。

そして、そのルールに対して、許可、ブロック、カウント、CAPTCHA、Challengeなどのアクションを設定します。

ルールアクションで挙動が決まる

同じIPセットでも、ルールアクションによって意味が変わります。

ブロックアクションを設定すれば、IPセットに一致したリクエストはブロックされます。

許可アクションを設定すれば、IPセットに一致したリクエストは許可されます。

カウントアクションを設定すれば、実際にはブロックせず、ログやメトリクスで検知だけを行えます。

本番環境で新しいIP制限を導入する場合は、最初からブロックするのではなく、まずカウントで影響を確認するのが安全です。

ルールの優先順位に注意する

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

許可やブロックのような終端アクションに一致すると、後続ルールの評価が行われない設計になる場合があります。

そのため、許可IPを早い優先順位で単純にAllowしてしまうと、後続のManaged RulesやSQLインジェクション対策、XSS対策などを通過してしまう可能性があります。

管理者IPであっても完全に無条件で許可するのではなく、どの条件に対して例外扱いするのかを慎重に設計することが重要です。

IPセットの上限と注意点

1つのIPセットに登録できる数

AWS WAFでは、1つのIPセットに最大10,000件のCIDRアドレスまたはCIDR範囲を登録できます。

この上限は大きいですが、何でも1つのIPセットにまとめればよいわけではありません。

用途別、環境別、IPv4・IPv6別に分けることで、後から管理しやすくなります。

分けすぎにも注意する

IPセットを用途ごとに分けることは大切ですが、分けすぎるとWeb ACL側の参照数の上限に近づく可能性があります。

AWS WAFでは、Web ACL内で参照できるIPセット、正規表現パターンセット、ルールグループなどの参照ステートメント数にも上限があります。

そのため、IPセットは細かくしすぎず、運用しやすさと上限のバランスを考えて設計します。

WCUにも注意する

IPセットを参照するルールは、通常は軽量です。

ただし、転送IPヘッダーを使い、ヘッダー内の複数IPを対象にする設定を行う場合は、WCUの消費が増えることがあります。

単純な送信元IPのブロックや許可であれば比較的シンプルですが、X-Forwarded-Forなどを使った高度な判定を行う場合は、WCUの消費も確認しておく必要があります。

CloudFront用IPセットの注意点

CloudFront用はグローバルスコープで作成する

CloudFrontをAWS WAFで保護する場合、IPセットはCloudFront用のグローバルスコープで作成します。

RegionalスコープのIPセットは、CloudFront用Web ACLでは使えません。

CloudFront、ALB、API Gatewayなど、保護対象によって必要なスコープが異なるため、作成時に間違えないように注意しましょう。

CLIやAPIではus-east-1を指定する

CloudFrontスコープのAWS WAFリソースをCLI、API、SDKで操作する場合は、us-east-1を指定する必要があります。

これは、CloudFrontがグローバルサービスであり、AWS WAFのCloudFrontスコープの操作がus-east-1で扱われるためです。

一方、ALBやAPI GatewayなどのRegionalリソースを保護する場合は、対象リソースが存在するリージョンを指定します。

転送IPヘッダーを使う場合の注意点

通常は送信元IPを見て判定する

AWS WAFのIPセットマッチでは、通常、Webリクエストの送信元IPを見て判定します。

しかし、CloudFront、ALB、別のCDN、リバースプロキシなどを経由している場合、AWS WAFから見える送信元IPが実際のユーザーIPではなく、プロキシや中継サーバーのIPになることがあります。

このような構成では、X-Forwarded-Forなどの転送IPヘッダーを使う設定が必要になる場合があります。

ヘッダーは信頼できる構成で使う

X-Forwarded-Forなどのヘッダーは、構成によっては外部から偽装される可能性があります。

そのため、転送IPヘッダーを使う場合は、信頼できるプロキシやCDNがヘッダーを付与・上書きしているかを確認する必要があります。

外部から直接アクセスできる構成で、リクエストヘッダーをそのまま信頼すると、攻撃者が任意のIPをヘッダーに入れて制限を回避する可能性があります。

ヘッダーが存在しない場合の挙動

転送IPヘッダーを使うルールでは、指定したヘッダーがリクエストに存在しない場合、そのルールは適用されません。

この場合、ルールアクションもfallback behaviorも適用されません。

一方、ヘッダー自体は存在するものの、IPアドレスとして不正な値が入っている場合は、設定したfallback behaviorに従って、マッチ扱いまたは非マッチ扱いになります。

FIRST・LAST・ANYの選択

転送IPヘッダーを使う場合、ヘッダー内のどのIPアドレスを見るかを選べます。

FIRSTは最初のIP、LASTは最後のIP、ANYは複数のIPを対象にします。

一般的に、X-Forwarded-Forでは左側に元のクライアントIPが入ることが多いですが、実際の挙動はプロキシやCDNの構成によって変わります。

そのため、どれを選ぶべきかは、インフラ構成とヘッダーの付与ルールを確認したうえで決める必要があります。

IPセットの更新と管理

更新時は全体リストを渡す考え方が重要

AWS WAFのIPセットを更新する場合、差分追加だけを行うというより、更新後のアドレス一覧を指定する考え方が重要です。

既存のIPアドレスを残したい場合は、既存のアドレスも含めたうえで更新する必要があります。

追加したいIPだけを指定して更新すると、既存の登録内容を意図せず消してしまう可能性があります。

LockTokenを使って更新する

AWS WAF v2では、IPセットを更新する際にLockTokenを使います。

LockTokenは、複数の更新が同時に行われた場合の競合を防ぐための仕組みです。

更新前に現在のIPセット情報を取得し、そのときに得られるLockTokenを使って更新します。

IPセット名は変更できない

IPセット名は、作成後に変更できません。

そのため、最初に命名ルールを決めておくことが大切です。

環境、用途、スコープ、IPバージョンが分かる名前にしておくと、後から管理しやすくなります。

たとえば、本番環境用なのか、ステージング環境用なのか、管理者許可リストなのか、ブロックリストなのか、IPv4用なのかIPv6用なのかが分かる名前にしておくとよいでしょう。

IPセット運用のベストプラクティス

用途別にIPセットを分ける

IPセットは、用途ごとに分けると運用しやすくなります。

たとえば、管理者許可用、一時ブロック用、恒久ブロック用、監視サービス許可用などに分けます。

これにより、IPアドレスを追加・削除するときに、目的を判断しやすくなります。

一時ブロックIPは定期的に見直す

攻撃対応で急いでIPをブロックすると、そのまま放置されがちです。

しかし、IPアドレスは再割り当てされることがあり、長期間ブロックし続けると、将来的に正規ユーザーを誤ってブロックする可能性があります。

一時ブロック用のIPセットには、追加理由、追加日、見直し期限を記録しておくと安全です。

変更履歴を残す

AWS WAFのIPセットだけで、IPごとの追加理由や担当者、期限を詳細に管理するのは難しい場合があります。

そのため、別途スプレッドシート、チケット、IaC管理、運用台帳などで変更履歴を残すのがおすすめです。

特に本番環境では、「誰が」「いつ」「なぜ」IPを追加・削除したのかを追える状態にしておくことが重要です。

最初はCountで影響を確認する

新しいIP制限を本番環境に入れる場合、最初からBlockにするのはリスクがあります。

まずCountでルールを動かし、ログを確認して、正規ユーザーが対象になっていないかを確認します。

問題がないことを確認してからBlockに切り替えると、誤ブロックを防ぎやすくなります。

WAFログで検証する

IPセットを使ったルールが正しく動作しているかは、WAFログで確認します。

どのIPがどのルールに一致したのか、想定外のユーザーがブロックされていないか、転送IPヘッダーの値が正しく使われているかを確認します。

特に、管理画面のIP制限や問い合わせフォームのブロック設定では、誤判定が業務や売上に影響する可能性があるため、ログ確認は必須です。

よくあるミス

IPセットを作っただけでブロックできると思っている

IPセットはあくまでIPアドレスのリストです。

Web ACLのルールから参照し、ルールアクションを設定しなければ、アクセス制御は行われません。

CloudFront用とRegional用を間違える

CloudFront用のWeb ACLでは、CloudFrontスコープのIPセットが必要です。

ALBやAPI GatewayなどのRegionalリソースでは、対象リージョンのRegionalスコープのIPセットが必要です。

スコープを間違えると、目的のWeb ACLでIPセットを参照できません。

IPv6を考慮していない

IPv4だけをブロックしても、IPv6経由のアクセスは制御できない場合があります。

サイトやインフラがIPv6に対応している場合は、IPv6用のIPセットも検討しましょう。

転送IPヘッダーを安易に信頼している

X-Forwarded-Forなどの転送IPヘッダーは便利ですが、信頼できる構成でなければ偽装される可能性があります。

どのサービスがヘッダーを付与しているのか、外部から直接ヘッダーを指定できない構成になっているのかを確認する必要があります。

Allowルールを強くしすぎる

特定IPを早い優先順位でAllowすると、そのリクエストが後続のセキュリティルールを通らない場合があります。

管理者IPや社内IPであっても、無条件にすべて許可する設計が本当に適切かを確認することが大切です。

AWS WAFのIPセット管理で重要なポイント

AWS WAFのIPセットは、IPアドレスを使ったアクセス制御を効率よく行うための重要な機能です。

ただし、IPセットを作成するだけでは制御は行われません。

Web ACLやルールグループ内のルールからIPセットを参照し、ルールアクションを設定することで、はじめて許可やブロックが行われます。

正しく運用するためには、スコープ、IPバージョン、CIDR形式、ルール優先順位、転送IPヘッダー、WAFログ、上限、WCUを理解しておく必要があります。

特に本番環境では、いきなりBlockにするのではなく、まずCountで影響を確認し、ログを見ながら段階的に適用するのが安全です。

また、IPアドレスは時間とともに変わる可能性があるため、一時ブロックと恒久ブロックを分け、変更履歴や追加理由を管理することも重要です。

AWS WAFのIPセットはシンプルな機能ですが、設計を誤ると、正規ユーザーをブロックしたり、逆に制限が効いていなかったりする可能性があります。

実務では、IPセット単体ではなく、Web ACL全体のルール設計、ログ確認、運用フローまで含めて管理することが大切です。

以上、AWS WAFでのIPセットの作成と管理についてでした。

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