AWS WAFのウェブACLについて

AWS WAFのWeb ACL（Web Access Control List）とは、Webアプリケーションに届くHTTP/HTTPSリクエストを検査し、許可・ブロック・カウント・CAPTCHA・Challengeなどの処理を行うための設定です。

AWS WAFでは、Web ACLが防御設定の中心になります。

CloudFront、Application Load Balancer、API Gateway REST API、AWS AppSync、Amazon Cognito、AWS App Runner、AWS Amplify、AWS Verified AccessなどのリソースにWeb ACLを関連付けることで、対象リソースに届くリクエストをAWS WAFで制御できます。

簡単にいうと、Web ACLは「どのアクセスを通し、どのアクセスを止めるか」を決めるためのルールセットです。

たとえば、以下のような制御をWeb ACLで実現できます。

• 特定IPアドレスからのアクセスをブロックする
• 特定国からのアクセスを制限する
• SQLインジェクションの疑いがあるリクエストをブロックする
• クロスサイトスクリプティングの疑いがあるリクエストをブロックする
• 短時間に大量アクセスするIPを制限する
• WordPressのログイン画面への攻撃を抑制する
• Botやスクレイピングの疑いがあるアクセスにChallengeを出す
• 管理画面へのアクセスを社内IPだけに限定する

AWS公式ドキュメントでは、Web ACLは「protection pack (web ACL)」と表記されることもあります。

ただし、実務上は現在も「Web ACL」という呼び方で問題なく通じます。

Web ACLでできること

Web ACLを使うと、Webアプリケーションに対するアクセスをアプリケーション層で制御できます。

セキュリティグループがIPアドレス、ポート、プロトコルなどのネットワークレベルで通信を制御するのに対し、AWS WAFのWeb ACLはHTTPリクエストの中身を見て判断します。

たとえば、以下のような情報をもとにリクエストを判定できます。

• 送信元IPアドレス
• 国・地域
• URIパス
• クエリ文字列
• HTTPヘッダー
• User-Agent
• Cookie
• リクエスト本文
• HTTPメソッド
• レート、つまり一定時間内のリクエスト数
• 他のルールによって付与されたラベル

これにより、単なる通信許可・拒否だけでなく、Webアプリケーション特有の攻撃や不審なアクセスを検出できます。

Web ACLを関連付けられる主なAWSリソース

Web ACLは、保護したいAWSリソースに関連付けて使います。

主な関連付け対象は以下です。

対象リソース	用途
Amazon CloudFront	グローバル配信されるWebサイトやAPIの保護
Application Load Balancer	ALB配下のWebアプリケーション保護
Amazon API Gateway REST API	APIへの攻撃や過剰アクセス対策
AWS AppSync	GraphQL APIの保護
Amazon Cognito user pool	認証関連エンドポイントの保護
AWS App Runner	App Runner上のWebアプリケーション保護
AWS Amplify	Amplifyでホストするアプリケーション保護
AWS Verified Access	Verified Access経由のアクセス保護

CloudWatchは、Web ACLの通常の関連付け対象というより、AWS WAFのメトリクス確認やログ出力先として利用されます。

Web ACLで検査したリクエストのログは、CloudWatch Logs、Amazon S3、Amazon Data Firehoseなどに出力できます。

Web ACLのスコープ

Web ACLを作成するときは、Scopeを選択します。

Scopeには大きく分けて以下の2種類があります。

Scope	対象
CloudFront / Global	CloudFrontディストリビューション
Regional	ALB、API Gateway、AppSync、Cognito、App Runner、Amplify、Verified Accessなど

CloudFront用のWeb ACLはグローバル扱いです。

ただし、AWS WAF上では、CloudFront用Web ACLはUS East (N. Virginia) / us-east-1、またはコンソール上のGlobal (CloudFront)として作成・管理します。

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

たとえば、東京リージョンのALBを保護する場合は、東京リージョンでRegional Web ACLを作成します。

Web ACLの基本構成

Web ACLは、主に以下の要素で構成されます。

構成要素	内容
Name	Web ACLの名前
Scope	CloudFront用かRegional用か
Default action	どのルールにも一致しなかった場合の動作
Rules	リクエストを評価する個別ルール
Rule groups	複数ルールをまとめたグループ
Managed rule groups	AWSやベンダーが提供する管理済みルールグループ
Priority	ルールの評価順序
Rule action	ルール一致時の動作
Visibility config	CloudWatchメトリクスやサンプリング設定
Logging	WAFログの出力設定

Web ACLは、これらの設定を組み合わせて「どのようなアクセスをどの順番で評価し、どのように処理するか」を定義します。

Default actionとは

Default actionの役割

Default actionとは、Web ACL内のルールをすべて評価した結果、どのルールでも最終的な処理が決まらなかった場合に適用されるアクションです。

Default actionには、基本的に以下の2つがあります。

Default action	内容
Allow	ルールに一致しなかったリクエストを許可する
Block	ルールに一致しなかったリクエストをブロックする

一般公開サイトでは、多くの場合、Default actionをAllowにします。

つまり、基本的にはリクエストを通し、危険なリクエストだけをルールでブロックする設計です。

一方、管理画面や社内向けシステム、限定公開APIなどでは、Default actionをBlockにすることもあります。

この場合、明示的に許可した条件に一致するリクエストだけをAllowし、それ以外はすべてブロックします。

Default actionをAllowにするケース

一般的なWebサイトでは、Default actionをAllowにすることが多いです。

たとえば、以下のようなサイトです。

• コーポレートサイト
• メディアサイト
• ECサイト
• LP
• SaaSの一般公開ページ
• ブログ
• WordPressサイト
• 会員制サービスの公開ページ

この場合、基本方針は以下のようになります。

通常のアクセスは許可する
明らかに危険なアクセスだけをブロックする
不審なアクセスはCountやChallengeで様子を見る

Default actionをBlockにするケース

Default actionをBlockにするのは、アクセス元を厳しく限定したい場合です。

たとえば、以下のようなケースです。

• 管理画面
• 社内ツール
• 検証環境
• 限定公開API
• 特定取引先向けAPI
• 社内IPまたはVPN経由のみ許可したいシステム

この場合、基本方針は以下です。

原則すべてブロックする
許可したIPや条件に一致するリクエストだけを通す

ホワイトリスト型の強い防御ができますが、IPアドレス変更やVPN障害があると正規ユーザーもアクセスできなくなる可能性があります。

そのため、運用体制も含めて設計する必要があります。

Ruleとは

Ruleの役割

Ruleとは、Web ACLの中でリクエストを判定するための条件と、その条件に一致したときのアクションを定義するものです。

AWS WAFのRuleは、単独のAWSリソースとして独立して存在するものではありません。

Web ACLまたはRule groupの中に定義されます。

たとえば、以下のようなルールを作成できます。

条件: URIパスが /wp-login.php で、同一IPから短時間に大量アクセスがある
アクション: Block

または、以下のようなルールも作成できます。

条件: 送信元IPが自社オフィスIPに一致する
アクション: Allow

このように、Ruleは「何を検査するか」と「一致したらどうするか」を決める設定です。

Ruleで指定できる主な条件

AWS WAFのRuleでは、さまざまな条件を指定できます。

条件	例
IP address	特定IPやCIDRからのアクセスを制御
Geo match	特定国・地域からのアクセスを制御
URI path	/admin や /wp-login.php へのアクセスを制御
Query string	クエリ文字列に不審な値があるか検査
Header	User-AgentやRefererなどを検査
Cookie	Cookieの値をもとに判定
Body	フォーム本文やJSON本文を検査
HTTP method	GET、POST、PUTなどを条件にする
Size constraint	リクエストサイズを条件にする
Regex match	正規表現でパターン判定する
SQLi match	SQLインジェクションらしい入力を検査
XSS match	XSSらしい入力を検査
Rate-based	一定時間内のリクエスト数で判定
Label match	他のルールが付与したラベルで判定

これらを組み合わせることで、単純なIP制限から高度な攻撃検知まで対応できます。

Rule actionとは

Rule actionの種類

Rule actionとは、ルールに一致したリクエストに対してAWS WAFが実行する動作です。

主なアクションは以下です。

アクション	内容
Allow	リクエストを許可する
Block	リクエストをブロックする
Count	許可・ブロックせず、カウントだけする
CAPTCHA	ユーザーにCAPTCHAを要求する
Challenge	ブラウザ検証などのチャレンジを行う

終了アクションと非終了アクション

AWS WAFでは、アクションによってルール評価が終了するものと、次のルール評価に進むものがあります。

アクション	評価の扱い
Allow	終了アクション
Block	終了アクション
Count	非終了アクション
CAPTCHA	トークン状態により終了または非終了
Challenge	トークン状態により終了または非終了

AllowやBlockが適用されると、その時点でWeb ACLの評価は終了します。

一方、Countはリクエストを止めずに記録だけを行い、次のルール評価に進みます。

そのため、新しいルールを本番環境に導入するときは、最初にCountで様子を見るのが安全です。

CAPTCHAやChallengeは少し特殊です。

リクエストに有効なトークンがない場合は、ユーザーにCAPTCHAやChallengeを提示し、評価が終了することがあります。

一方、有効なトークンがある場合は、Countに近い非終了アクションとして扱われ、後続のルール評価に進むことがあります。

ルールの評価順序

Priorityの考え方

Web ACL内のルールにはPriorityがあります。

AWS WAFは、Priorityの数値が小さいルールから順番に評価します。

たとえば、以下のような順番です。

Priority	ルール	アクション
0	自社IPを許可	Allow
10	悪質IPをブロック	Block
20	AWS Managed Rules Common Rule Set	BlockまたはCount
30	SQLi対策ルール	BlockまたはCount
40	レートベースルール	Block
Default	どのルールにも一致しない	Allow

Priority 0のルールが最初に評価され、次にPriority 10、Priority 20と続きます。

評価順序が重要な理由

AWS WAFでは、ルールの順番によって結果が変わることがあります。

たとえば、自社IPを許可するルールを最初に置いた場合、自社IPからのリクエストはAllowされ、その時点で評価が終了します。
つまり、後続のManaged Rulesには評価されません。

一方、自社IP許可ルールをManaged Rulesの後ろに置いた場合、自社IPからの正常な管理作業がManaged Rulesで誤検知され、ブロックされる可能性があります。

そのため、以下のようなルールは順序を慎重に設計する必要があります。

• 自社IPやVPN出口IPのAllowルール
• 悪質IPのBlockルール
• 管理画面へのアクセス制限
• Managed Rule Group
• Countで検証したいルール
• Rate-based rule
• Bot対策ルール

Rule groupとは

Rule groupの役割

Rule groupとは、複数のRuleをまとめたものです。

同じルール群を複数のWeb ACLで使い回したい場合や、管理しやすくしたい場合に利用します。

たとえば、以下のような共通ルールをRule groupにまとめられます。

• 社内IP許可
• 悪質IPブロック
• 特定User-Agentブロック
• 管理画面アクセス制限
• 共通のレート制限
• 共通のSQLi / XSS対策

複数サービスで同じセキュリティポリシーを使いたい場合、Rule groupを使うと管理が楽になります。

Rule groupの種類

Rule groupには、主に以下の種類があります。

種類	内容
自作Rule group	自分で作成・管理するルールグループ
AWS Managed Rules	AWSが提供・管理するルールグループ
Marketplace managed rule groups	サードパーティが提供するルールグループ

自作Rule groupは、社内共通ルールを再利用したい場合に便利です。

AWS Managed Rulesは、AWSが一般的な攻撃パターンに対応するために提供している管理済みルールです。

自分で細かく攻撃パターンを定義しなくても、代表的なWeb攻撃への対策を導入できます。

AWS Managed Rulesとは

AWS Managed Rulesの概要

AWS Managed Rulesは、AWSが提供・保守するマネージドルールグループです。

SQLインジェクション、XSS、既知の悪意ある入力、低レピュテーションIP、匿名IP、Bot、WordPress向け攻撃など、さまざまな脅威に対応するルールグループが用意されています。

Managed Rulesを使うメリットは、攻撃パターンの定義やメンテナンスをすべて自分で行わなくても、一定水準の防御を導入できる点です。

代表的なAWS Managed Rules

代表的なAWS Managed Rulesには、以下のようなものがあります。

ルールグループ	主な目的
AWSManagedRulesCommonRuleSet	一般的なWeb攻撃対策
AWSManagedRulesKnownBadInputsRuleSet	既知の悪意ある入力パターン対策
AWSManagedRulesSQLiRuleSet	SQLインジェクション対策
AWSManagedRulesAmazonIpReputationList	AWSが管理する低レピュテーションIP対策
AWSManagedRulesAnonymousIpList	VPN、プロキシ、匿名化ネットワーク対策
AWSManagedRulesBotControlRuleSet	Bot対策
AWSManagedRulesAdminProtectionRuleSet	管理画面系パスの保護
AWSManagedRulesLinuxRuleSet	Linux固有の攻撃パターン対策
AWSManagedRulesPHPRuleSet	PHPアプリ向け攻撃パターン対策
AWSManagedRulesWordPressRuleSet	WordPress向け攻撃パターン対策

すべてのルールグループを入れればよいわけではありません。

アプリケーションの技術スタックや公開範囲に合わせて、必要なものを選ぶことが重要です。

たとえば、WordPressを使っていないサイトにWordPress向けルールを入れても効果は限定的です。

PHPを使っていないアプリケーションにPHP向けルールを入れる必要性も高くありません。

Managed Rule GroupのOverride

Overrideとは

Managed Rule Groupを使う場合、ルールグループ全体、または個別ルールの動作を上書きできます。

これをOverrideと呼びます。

たとえば、AWSManagedRulesCommonRuleSetの中に複数のルールが含まれている場合、そのうち特定のルールだけをCountに変更できます。

Overrideが必要になるケース

Managed Rulesは便利ですが、すべてのアプリケーションに完全に合うとは限りません。

たとえば、以下のようなケースでは誤検知が起きることがあります。

• 検索フォームに特殊な文字列が入力される
• 管理画面でHTMLを投稿する
• WYSIWYGエディタを使っている
• JSON APIで複雑な文字列を送信する
• クエリパラメータにSQL風の文字列が含まれる
• CMS管理画面でスクリプト風の内容を扱う

このような場合、ルールグループ全体を無効にするのではなく、誤検知している個別ルールだけをCountにする、または除外条件を追加するのが現実的です。

実務でのOverride運用

実務では、以下の流れで調整するのが安全です。

1. Managed Rule GroupをCountで導入する
2. WAFログを確認する
3. 誤検知がないルールをBlockに変更する
4. 誤検知がある個別ルールはCountのままにする
5. 必要に応じて除外条件を追加する
6. 本番リリース後も定期的にログを確認する

いきなりすべてをBlockにすると、正常なユーザーや管理者の操作まで止めてしまうリスクがあります。

Countモードとは

Countモードの役割

Countモードは、ルールに一致したリクエストをブロックせず、検出だけを行う設定です。

AWS WAFの導入時には、Countモードが非常に重要です。

Countモードを使うことで、以下を確認できます。

• どのルールがどれくらい反応しているか
• 正常ユーザーが誤検知されていないか
• フォーム送信がブロック対象になっていないか
• API通信が誤検知されていないか
• 管理画面の操作に影響がないか
• ECサイトの購入フローに影響がないか
• 検索機能や投稿機能が誤検知されていないか

いきなりBlockにしないほうがよい理由

AWS Managed Rulesは強力ですが、アプリケーションの仕様によっては正常なリクエストを攻撃と判断することがあります。

特に以下のようなサイトでは注意が必要です。

• WordPressなどのCMS
• ECサイト
• 会員サイト
• 掲示板
• フォームが多いサイト
• HTML入力を許可する管理画面
• JSON API
• 検索機能があるサイト
• 外部サービス連携が多いサイト

いきなりBlockにすると、問い合わせフォームが送信できない、購入処理が失敗する、管理画面で保存できない、API連携が失敗する、といった問題が起きる可能性があります。

そのため、まずはCountで導入し、ログを確認してからBlockへ移行するのが安全です。

WCUとは

WCUの意味

WCU（Web ACL Capacity Unit）とは、AWS WAFのルールやWeb ACLが消費する処理キャパシティを表す単位です。

AWS WAFでは、ルールの種類によって必要なWCUが異なります。

たとえば、単純なIP一致ルールは比較的少ないWCUで済みます。

一方、正規表現、SQLインジェクション検査、XSS検査、リクエスト本文検査などは、より多くのWCUを消費します。

WCUで注意すべきポイント

Web ACLにはWCUの上限があります。

実務上、特に重要なのは以下です。

項目	内容
基本料金に含まれるWCU	1,500 WCUまで
1,500 WCU超過	追加料金が発生
Web ACLの最大WCU	5,000 WCU
Rule groupの最大WCU	5,000 WCU

Managed Rule Groupを複数追加すると、WCUの合計が大きくなります。

「念のため全部入れる」という設計にすると、WCUが増え、コストや管理負荷も増える可能性があります。

そのため、アプリケーションに必要なルールを選定することが重要です。

Rate-based ruleとは

Rate-based ruleの概要

Rate-based ruleとは、一定時間内に同じ条件で届いたリクエスト数をもとに制御するルールです。

たとえば、以下のような制御ができます。

同一IPから5分間に500回以上アクセスがあった場合にBlockする

また、対象を特定のパスに限定することもできます。

/wp-login.php に対して、同一IPから5分間に20回以上アクセスがあった場合にBlockする

Rate-based ruleの主な用途

Rate-based ruleは、以下のような対策に有効です。

• ログイン試行の連続アクセス対策
• パスワードリスト攻撃の抑制
• フォームスパム対策
• APIへの過剰アクセス対策
• スクレイピング対策
• 短時間に集中する不審アクセスの抑制
• DDoS的なアクセス集中の緩和

Rate-based ruleの注意点

Rate-based ruleは便利ですが、厳密なAPIレートリミッターではありません。

高頻度リクエストを緩和するための仕組みであり、「1分あたり必ず何回まで」といった厳密な利用回数制御を目的とする場合は、API Gatewayの使用量プラン、アプリケーション側の制御、認証基盤側の制限なども併用する必要があります。

また、AWS WAFのクォータとして、Rate-based ruleには以下のような制限があります。

項目	内容
Web ACLあたりのRate-based rule数	最大10個
Rule groupあたりのRate-based rule数	最大4個
設定可能な最小リクエストレート	10

リクエスト本文検査の注意点

本文検査は可能だが上限がある

AWS WAFでは、リクエスト本文を検査できます。

そのため、フォーム送信内容やJSON本文に含まれるSQLインジェクション、XSS、既知の悪意ある入力などを検出できます。

ただし、AWS WAFで検査できるリクエスト本文サイズには上限があります。

対象リソース	本文検査サイズ
Application Load Balancer	8KB固定
AWS AppSync	8KB固定
CloudFront	デフォルト16KB、最大64KB
API Gateway	デフォルト16KB、最大64KB
Amazon Cognito	デフォルト16KB、最大64KB
AWS App Runner	デフォルト16KB、最大64KB
AWS Verified Access	デフォルト16KB、最大64KB

大きなJSON、ファイルアップロード、大容量フォーム送信などでは、WAFが本文全体を検査できない場合があります。

大きなリクエストを扱う場合の注意点

大きなリクエスト本文を扱うアプリケーションでは、WAFだけに依存しない設計が必要です。

たとえば、以下のような対策を組み合わせます。

• アプリケーション側で入力検証を行う
• ファイルアップロードの拡張子やMIMEタイプを制限する
• アップロードサイズを制限する
• 認証済みユーザーのみにアップロードを許可する
• S3の署名付きURLなどを使ってアップロード経路を分離する
• API側でスキーマバリデーションを行う

AWS WAFは有効な防御層ですが、アプリケーション側のバリデーションを代替するものではありません。

Web ACLのログ

WAFログで確認できること

Web ACLでは、リクエストのログを出力できます。

WAFログを有効化すると、以下のような情報を確認できます。

• リクエスト時刻
• 送信元IPアドレス
• 対象URI
• HTTPメソッド
• User-Agent
• マッチしたルール
• 適用されたアクション
• ルールグループ名
• ラベル情報
• ブロックされた理由
• Countされた理由

ログを確認することで、AWS WAFがどのように動作しているかを把握できます。

ログ出力先

AWS WAFのログ出力先としては、主に以下を利用できます。

出力先	用途
Amazon CloudWatch Logs	すぐにログ確認・検索したい場合
Amazon S3	長期保存や分析基盤連携
Amazon Data Firehose	S3、OpenSearch、外部分析基盤などへの配送

ログ量が多いサイトでは、ログ保存コストも無視できません。

そのため、必要に応じてログフィルタリング、保持期間の設定、S3ライフサイクルポリシーなどを検討します。

ログ確認が重要な理由

WAFは設定して終わりではありません。

ログを見ながら継続的に調整することで、防御効果を高められます。

特に以下の観点で確認します。

• 誤検知が起きていないか
• 正常なフォーム送信が止まっていないか
• 管理画面操作がブロックされていないか
• 攻撃が多いURIはどこか
• どの国・IPから攻撃が多いか
• どのManaged Ruleが多く反応しているか
• レート制限のしきい値は適切か
• Botやスクレイピングの傾向はあるか

ECサイトや問い合わせフォームでは、誤検知が売上やCVRに影響する可能性があります。

Webマーケティングの観点でも、WAFログとコンバージョンデータをあわせて確認することが重要です。

Web ACLの料金

主な料金要素

AWS WAFの料金は、主に以下の要素で発生します。

料金要素	内容
Web ACL	作成したWeb ACLごとの料金
ルール	Web ACL内のルールごとの料金
リクエスト数	Web ACLで処理されたWebリクエスト数
Rule group	自作またはManaged Rule Groupの利用
Managed Rule Group	AWS Managed RulesやMarketplaceルール
WCU超過	1,500 WCUを超えた場合の追加料金
CAPTCHA / Challenge	利用回数に応じた料金
Bot Control	Bot Control利用時の追加料金
Fraud Control	Fraud Control利用時の追加料金
ログ	CloudWatch Logs、S3、Firehoseなどの料金

Allow、Block、Countといった標準アクション自体に追加料金はありません。

一方で、CAPTCHA、Challenge、Bot Control、Fraud Control、1,500 WCU超過、ログ保存などは追加コストの要因になります。

料金設計で注意すべきポイント

AWS WAFのコストを見積もるときは、以下を確認します。

• Web ACLをいくつ作成するか
• Web ACL内にルールをいくつ設定するか
• どのManaged Rule Groupを使うか
• 月間リクエスト数はどれくらいか
• Bot ControlやFraud Controlを使うか
• CAPTCHAやChallengeをどれくらい使うか
• WCUが1,500を超えるか
• WAFログをどこに、どれくらい保存するか

アクセス数が多いWebサイトでは、リクエスト数による料金とログ保存料金が大きくなることがあります。

また、Bot Controlなどの高度な機能は便利ですが、追加料金が発生するため、費用対効果を見ながら導入することが大切です。

Web ACLの設計パターン

基本防御型

一般的なWebサイトでは、以下のような構成が考えられます。

Default action: Allow

Rules:
1. AWSManagedRulesAmazonIpReputationList
2. AWSManagedRulesCommonRuleSet
3. AWSManagedRulesKnownBadInputsRuleSet
4. AWSManagedRulesSQLiRuleSet
5. Rate-based rule

この構成では、通常のアクセスを許可しながら、一般的な攻撃パターンや不審なIP、過剰アクセスを抑制します。

最初はManaged RulesをCountで導入し、ログを確認してからBlockに切り替えるのが安全です。

WordPress保護型

WordPressサイトでは、以下のような構成が考えられます。

Default action: Allow

Rules:
1. 自社IPまたは管理者IPをAllow
2. 悪質IPをBlock
3. AWSManagedRulesAmazonIpReputationList
4. AWSManagedRulesCommonRuleSet
5. AWSManagedRulesKnownBadInputsRuleSet
6. AWSManagedRulesSQLiRuleSet
7. AWSManagedRulesWordPressRuleSet
8. /wp-login.php へのRate-based rule
9. /xmlrpc.php のBlock

WordPressでは、特に以下のパスが攻撃対象になりやすいです。

• /wp-login.php
• /wp-admin
• /xmlrpc.php

不要な/xmlrpc.phpはブロックし、ログイン画面にはレート制限やIP制限を検討するとよいでしょう。

API保護型

API GatewayやALB配下のAPIを保護する場合は、以下のような構成が考えられます。

Default action: Allow

Rules:
1. 許可するHTTPメソッドを制限
2. 不審IPをBlock
3. SQLi / XSS対策
4. JSON本文の検査
5. APIパスごとのRate-based rule
6. Botやスクレイピング対策

APIでは、Webページとは違う観点が重要です。

たとえば、以下を確認します。

• GET、POST、PUT、DELETEなどのメソッド制御
• 認証ヘッダーの有無
• JSON本文のサイズ
• APIごとのリクエスト頻度
• 異常なUser-Agent
• 特定エンドポイントへの集中アクセス

厳密なAPI利用制限が必要な場合は、AWS WAFだけでなく、API Gatewayの使用量プランやアプリケーション側の認可・レート制限も併用します。

ホワイトリスト型

管理画面や社内向けシステムでは、Default actionをBlockにするホワイトリスト型も有効です。

Default action: Block

Rules:
1. 社内IPをAllow
2. VPN出口IPをAllow
3. 特定取引先IPをAllow

この構成では、許可されたアクセス元以外はすべてブロックされます。

攻撃面を大きく減らせますが、以下の点に注意が必要です。

• 社内IPが変わったときの更新手順
• VPN障害時の代替アクセス手段
• 管理者が出張先からアクセスする場合の対応
• 取引先IP変更時の連絡フロー
• 緊急時の一時許可ルール

セキュリティは強くなりますが、運用ミスによって正規ユーザーが締め出されるリスクもあります。

Web ACL導入の流れ

Step 1. 保護対象を決める

まず、どのリソースをAWS WAFで保護するか決めます。

候補は以下です。

• CloudFront
• Application Load Balancer
• API Gateway REST API
• AWS AppSync
• Amazon Cognito
• AWS App Runner
• AWS Amplify
• AWS Verified Access

Webサイト全体をCloudFrontで配信している場合は、CloudFrontにWeb ACLを関連付ける構成がよく使われます。

ALBに直接アクセスされる構成であれば、ALBにWeb ACLを関連付けることもあります。

ただし、CloudFrontを使っている場合は、オリジン直アクセスを防ぐ設計もあわせて検討します。

Step 2. Scopeを選ぶ

次に、Web ACLのScopeを選びます。

CloudFrontを守るなら、CloudFront / Global用のWeb ACLを作成します。

ALBやAPI Gatewayなどを守るなら、対象リソースと同じリージョンでRegional Web ACLを作成します。

Step 3. Default actionを決める

一般公開サイトなら、基本的にはDefault actionをAllowにすることが多いです。

Default action: Allow

管理画面や限定APIなら、Default actionをBlockにする構成も検討します。

Default action: Block

どちらを選ぶかは、サイトの公開範囲と運用方針によって変わります。

Step 4. Managed RulesをCountで導入する

最初は、代表的なAWS Managed RulesをCountで導入します。

例として、以下のようなルールグループが候補になります。

AWSManagedRulesAmazonIpReputationList
AWSManagedRulesCommonRuleSet
AWSManagedRulesKnownBadInputsRuleSet
AWSManagedRulesSQLiRuleSet

WordPressサイトなら、以下も検討します。

AWSManagedRulesWordPressRuleSet

ただし、すべてをいきなりBlockにするのではなく、まずはCountでログを確認します。

Step 5. Rate-based ruleを追加する

次に、過剰アクセスが問題になりやすい箇所にRate-based ruleを設定します。

代表的な対象は以下です。

• ログイン画面
• 会員登録フォーム
• 問い合わせフォーム
• 検索機能
• APIエンドポイント
• WordPressの/wp-login.php
• WordPressの/xmlrpc.php

たとえば、以下のような設計が考えられます。

/wp-login.php に対して、同一IPから5分間に20回以上アクセスがあればBlock

ただし、しきい値が低すぎると正規ユーザーも影響を受ける可能性があります。ログを見ながら調整することが重要です。

Step 6. ログを確認する

Countで導入した後は、WAFログを確認します。

特に以下を見ます。

• 正常アクセスがCountされていないか
• 問い合わせフォーム送信に影響がないか
• ECサイトの購入フローに影響がないか
• ログイン処理が誤検知されていないか
• 管理画面操作が誤検知されていないか
• API連携が誤検知されていないか
• 特定のManaged Ruleだけ反応しすぎていないか

問題がなければ、対象ルールをBlockに変更します。

Step 7. 誤検知を調整する

誤検知がある場合は、以下の方法で調整します。

• 個別ルールをCountに変更する
• 特定パスだけ除外する
• 特定IPだけ除外する
• 特定ヘッダーを持つリクエストを除外する
• Managed Rule GroupのOverrideを使う
• ルールのPriorityを変更する
• Rate-based ruleのしきい値を上げる

重要なのは、誤検知があるからといってルール全体を安易に無効化しないことです。

可能であれば、影響のある条件だけを狭く除外します。

Step 8. Blockへ移行する

Countで問題がないことを確認できたルールから、段階的にBlockへ移行します。

おすすめの流れは以下です。

1. IP Reputation系をBlock
2. Known Bad InputsをBlock
3. SQLi系をBlock
4. Common Rule Setを一部Block
5. 誤検知があるルールだけCount継続
6. Rate-based ruleを慎重にBlock
7. Bot対策やChallengeを必要に応じて導入

一度にすべてをBlockにするのではなく、段階的に変更することで障害リスクを抑えられます。

Step 9. 定期的に見直す

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

以下のタイミングで見直すとよいです。

• 新機能をリリースしたとき
• フォームやAPIを追加したとき
• CMSを更新したとき
• キャンペーンを実施するとき
• アクセス数が急増したとき
• 攻撃が増えたとき
• 誤検知が発生したとき
• AWS Managed Rulesが更新されたとき

Webアプリケーションの仕様が変われば、適切なWAF設定も変わります。

Web ACLとCloudFrontの関係

CloudFrontにWeb ACLを設定するメリット

CloudFrontにWeb ACLを関連付けると、エッジ側でリクエストを検査できます。

これには以下のメリットがあります。

• オリジンに到達する前に攻撃を止められる
• ALBやEC2の負荷を減らせる
• グローバル配信の入口で一元的に防御できる
• 静的サイト、SPA、WordPress、APIをまとめて守りやすい
• 複数リージョンのオリジンをCloudFront側でまとめて保護しやすい

CloudFrontを使っているWebサイトでは、まずCloudFrontにWAFを適用する構成がよく採用されます。

オリジン直アクセスに注意する

CloudFrontにWAFを設定しても、ALBやEC2などのオリジンに直接アクセスできる構成だと、WAFを迂回される可能性があります。

そのため、CloudFrontを使う場合は、オリジン側でも以下のような対策を検討します。

• ALBのセキュリティグループでCloudFrontからのアクセスに限定する
• CloudFrontからのカスタムヘッダーをオリジン側で検証する
• S3オリジンではOrigin Access Controlを使う
• オリジンのパブリック公開範囲を最小化する
• CloudFront経由以外のアクセスを遮断する

AWS WAFは強力ですが、設置場所を誤ると期待した防御効果を得られません。

Web ACLとセキュリティグループの違い

AWS WAFのWeb ACLとセキュリティグループは、どちらもアクセス制御に関係しますが、役割が異なります。

項目	Web ACL	セキュリティグループ
サービス	AWS WAF	Amazon EC2 / VPC関連
主なレイヤー	アプリケーション層
主な対象	HTTP/HTTPSリクエスト
制御内容	URI、ヘッダー、Cookie、本文、攻撃パターン
例	SQLiをブロック、特定パスを制限
目的	Web攻撃対策
代表的な用途	Webアプリケーション保護

セキュリティグループは、主にIPアドレス、ポート、プロトコル単位で通信を制御します。

項目	セキュリティグループ
主なレイヤー	ネットワーク層・トランスポート層
主な対象	EC2、ALB、RDSなど
制御内容	IP、ポート、プロトコル
例	443番ポートのみ許可
目的	ネットワークアクセス制御

たとえば、セキュリティグループでは「443番ポートへのアクセスを許可する」ことはできます。

しかし、「クエリ文字列にSQLインジェクションらしい文字列がある場合にブロックする」といった制御はできません。

このようなHTTPリクエストの中身を見た制御を行うのが、AWS WAFのWeb ACLです。

Web ACLで防ぎやすい攻撃

Web ACLは、以下のような脅威に対して有効です。

SQLインジェクション

SQLインジェクションは、入力値にSQL文を混ぜてデータベースを不正操作しようとする攻撃です。

AWS WAFでは、SQLi match statementやAWSManagedRulesSQLiRuleSetを使うことで、SQLインジェクションの疑いがあるリクエストを検出できます。

クロスサイトスクリプティング

クロスサイトスクリプティング、いわゆるXSSは、入力欄などにスクリプトを混入させる攻撃です。

AWS WAFでは、XSS match statementやCommon Rule Setなどを使って、XSSの疑いがあるリクエストを検出できます。

既知の悪意ある入力

攻撃でよく使われる文字列やパターンを検出できます。

AWSManagedRulesKnownBadInputsRuleSetを利用すると、既知の悪意ある入力パターンへの対策を導入できます。

悪質IPからのアクセス

AWSManagedRulesAmazonIpReputationListなどを使うと、AWSが管理する低レピュテーションIPからのアクセスを制御できます。

また、自社で管理するIP setを使えば、特定IPのブロックや許可も可能です。

匿名IPやプロキシ経由のアクセス

AWSManagedRulesAnonymousIpListを使うと、VPN、プロキシ、Torノード、ホスティングプロバイダーなど、匿名性の高いアクセス元を検出できます。

ただし、VPN利用者や海外ユーザーに影響が出る可能性があるため、導入時はCountで確認するのが安全です。

過剰アクセス

Rate-based ruleを使うことで、同一IPなどからの短時間の大量アクセスを制御できます。

ログイン試行、フォーム連投、API連打、スクレイピングなどの抑制に役立ちます。

Botアクセス

Bot ControlやChallengeを使うことで、一部のBotや自動化アクセスに対策できます。

ただし、すべてのBotを完全に防げるわけではありません。

検索エンジン、監視ツール、広告クローラー、外部連携サービスなど、許可すべきBotも存在するため、ログを見ながら調整する必要があります。

Web ACLだけでは防ぎにくいもの

AWS WAFは有効なセキュリティ対策ですが、万能ではありません。

以下のような問題は、Web ACLだけでは防ぎにくいです。

認証後の不正操作

正規アカウントでログインしたユーザーが不正操作を行う場合、リクエスト自体は正常に見えることがあります。

このようなケースでは、アプリケーション側の認可制御、操作ログ、異常検知が必要です。

認可設計の不備

たとえば、他人のユーザーIDをURLに指定すると情報が見えてしまうような脆弱性は、WAFだけでは根本的に防げません。

アプリケーション側で、ユーザーごとのアクセス権限を正しくチェックする必要があります。

ビジネスロジック攻撃

クーポンの不正利用、ポイントの不正取得、在庫の買い占め、紹介制度の悪用などは、通常のHTTPリクエストとして送られることがあります。

このような攻撃には、アプリケーション側のロジック制御、不正検知、利用制限などが必要です。

盗まれた正規アカウントによる操作

ID・パスワードが漏えいしている場合、攻撃者は正規ユーザーとしてログインできます。

WAFだけで完全に防ぐのは難しいため、多要素認証、ログイン通知、異常ログイン検知、パスワードリセットなどの対策が必要です。

アプリケーション内部の脆弱性

AWS WAFは攻撃リクエストを検出・遮断する防御層ですが、アプリケーションの脆弱性そのものを修正するものではありません。

脆弱性診断、セキュアコーディング、依存ライブラリの更新、パッチ適用なども必要です。

Web ACL導入時のチェックリスト

基本設定のチェック

Web ACLを導入するときは、以下を確認します。

チェック項目	確認内容
保護対象	CloudFront、ALB、API Gatewayなどが正しいか
Scope	CloudFront用かRegional用か
リージョン	Regionalの場合、対象リソースと同じリージョンか
Default action	Allow / Blockの方針が適切か
Priority	ルール順序に矛盾がないか
WCU	1,500 WCU超過や上限に注意しているか
ログ	WAFログを有効化しているか
メトリクス	CloudWatchで確認できるか

ルール設計のチェック

ルール設計では、以下を確認します。

チェック項目	確認内容
Managed Rules	必要なルールグループだけ選んでいるか
Count検証	いきなりBlockにしていないか
誤検知対応	Overrideや除外条件を設計しているか
Rate-based rule	しきい値が低すぎないか
IP制限	管理画面や限定APIに適用しているか
Bot対策	正常なBotまで止めていないか
本文検査	検査サイズ上限を理解しているか

運用面のチェック

運用では、以下を確認します。

チェック項目	確認内容
ログ監視	定期的にWAFログを確認しているか
誤検知対応フロー	ブロック事故時の対応手順があるか
ルール更新	アプリ改修時にWAF設定も見直しているか
コスト確認	リクエスト数、WCU、ログ料金を確認しているか
オリジン保護	CloudFrontを迂回されない構成か
緊急対応	一時的なAllow / Count変更手順があるか

AWS WAFのWeb ACLを設計する際の注意点

最初からBlockしすぎない

AWS WAF導入時によくある失敗は、Managed Rulesを一気にBlockで有効化してしまうことです。

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

まずはCountで導入し、ログを確認してから段階的にBlockへ移行しましょう。

ルールの順番を慎重に決める

AWS WAFはPriority順にルールを評価します。

そのため、ルールの順番を間違えると、意図しないアクセスが許可されたり、逆に正常アクセスがブロックされたりします。

特に、自社IPのAllowルール、悪質IPのBlockルール、Managed Rules、Rate-based ruleの順番は慎重に設計する必要があります。

管理画面と一般ページを分けて考える

一般公開ページと管理画面では、防御方針が異なります。

一般公開ページでは、通常アクセスを許可しながら攻撃だけをブロックする構成が多いです。

一方、管理画面では、IP制限やVPN制限などを使ってアクセス元を絞るほうが安全です。

WAFログを必ず確認する

AWS WAFは、設定して終わりではありません。

ログを確認しながら、以下を継続的に見直します。

• どのルールが反応しているか
• 誤検知はないか
• 攻撃対象になっているパスはどこか
• レート制限のしきい値は適切か
• Bot対策が正常ユーザーに影響していないか
• コストが想定内か

WAFだけに依存しない

AWS WAFは強力な防御層ですが、アプリケーションのセキュリティ設計を代替するものではありません。

以下の対策も組み合わせる必要があります。

• 認証・認可の適切な実装
• 入力値バリデーション
• SQLインジェクション対策
• XSS対策
• CSRF対策
• 多要素認証
• セキュリティグループ
• CloudFrontのオリジン保護
• ログ監視
• 脆弱性診断
• ライブラリ更新
• バックアップ
• インシデント対応手順

まとめ

AWS WAFのWeb ACLは、Webアプリケーションに届くHTTP/HTTPSリクエストを検査し、許可・ブロック・カウント・CAPTCHA・Challengeなどの処理を行うための中心的な設定です。

CloudFront、ALB、API Gateway、AppSync、Cognito、App Runner、Amplify、Verified Accessなどに関連付けることで、WebアプリケーションやAPIをさまざまな攻撃から保護できます。

Web ACLを理解するうえで重要なのは、以下のポイントです。

• Web ACLはAWS WAFの防御ポリシーの入れ物
• ルールはPriorityの小さい順に評価される
• AllowやBlockは評価を終了する
• Countは検出のみで、後続ルールの評価に進む
• CAPTCHAやChallengeはトークン状態によって挙動が変わる
• Default actionは、どのルールでも処理が決まらなかった場合に適用される
• Managed Rulesを使うと一般的な攻撃対策を導入しやすい
• ただし、誤検知を避けるため最初はCountで検証する
• WCU、本文検査サイズ、料金、ログコストにも注意する
• Rate-based ruleは厳密なレートリミッターではなく、過剰アクセス緩和の仕組み
• Web ACLだけでなく、認証・認可・ネットワーク制御・ログ監視と組み合わせることが重要

実務では、まず以下の流れで導入すると安全です。

1. 保護対象を決める
2. Scopeを選ぶ
3. Default actionを決める
4. Managed RulesをCountで導入する
5. WAFログを確認する
6. 誤検知を調整する
7. 問題ないルールからBlockへ移行する
8. 定期的に見直す

AWS WAFのWeb ACLは、単にルールを追加するだけの機能ではありません。

Webアプリケーションの構成、アクセス傾向、管理画面の有無、APIの性質、運用体制、コストを踏まえて設計することで、より効果的なセキュリティ対策になります。

以上、AWS WAFのウェブACLについてでした。

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