マネージドサービス部 佐竹です。
本日は AWS WAF を基礎から学び直してみようというブログになっています。対象読者は「AWS WAF を今から使ってみよう」と考えはじめた方に向けて「わかりやすく」記載しています。
はじめに
ウェブサイトやウェブサービスを運営している皆様、セキュリティ対策は行われているでしょうか？
インターネット上で「サービスを公開しはじめる」ということは、常に様々なサイバー攻撃の脅威に晒される状況になるということです。
そこで今回は、ウェブアプリケーションを守るために重要となる防御壁、「WAF（Web Application Firewall）」について記載していきます。
なぜ WAF が重要なのか？
ブログ記事の本編に入る前に、まず WAF がなぜ重要なのか、そのポイントを3つに絞ってご紹介します。
1. ウェブサイトを狙った攻撃に特化した防御装置
WAF は、一般的なファイアウォールが防ぎきれない、ウェブアプリケーションの脆弱性を狙った攻撃*1を検知し、ブロックすることに特化したセキュリティ対策です。
最近は「アタックサーフェス」という用語も定着してきたように思いますが、代表的なアタックサーフェスとして、ウェブサイトや API のエンドポイントがあげられます。それらを「門」とすると、それを守るための WAF は言わば「門番」のような存在です。
2. 不正アクセスやサービス停止攻撃（DDoS）にも有効
WAF は、アプリケーション層への不正なリクエストをフィルタリングすることで、不正ログイン試行や悪意のあるボットによる自動化された攻撃を防ぐのに役立ちます。
また、大量のアクセスでサービスをダウンさせようとする DDoS 攻撃に対しても、特定の攻撃パターンを識別して遮断するなど、一定の効果を発揮します*2。
3. 「多層防御」の要として導入が進んでいる
サイバー攻撃は日々巧妙化しており、単一のセキュリティ対策だけでは不十分です。よって、ファイアウォールや IDS/IPS （不正侵入検知・防御システム）などと組み合わせ、複数の防御層で守る「多層防御」の考え方が不可欠です。AWS のサービスでは、Amazon GuardDuty や AWS Security Hub、Amazon Inspector 等と組み合わせて対応することが多くなってきています。
その中でも WAF は、ウェブアプリケーションの通信内容（HTTP/HTTPS）を直接検査して防御する重要な役割を担っており、近年、特にクラウド環境でも導入が急速に進んでいます。
AWS WAF の優位性
WAF は大規模な初期導入コストが発生することが多かったのですが、AWS では個別のロードバランサー毎に低コストで導入が可能な AWS WAF を2015年10月に発表しました。
AWS では AWS WAF を利用することで、WAF を個別のワークロードごとに低コストで始められるようになっています。
AWS WAF のバージョンに関する補足
現在 AWS WAF のバージョンは「v2」です。以前の AWS WAF Classic のサポートは 2025年9月30日に終了しますため、本ブログにおいても AWS WAF は v2 を前提として記載します。
AWS WAF の基本動作
ということで、ここから AWS WAF を使うにあたって最初に覚えておきたいポイントをわかりやすく解説していきます。
通信の評価と「アクション」
AWS WAF は、ウェブサイトへのアクセス（HTTP/HTTPSリクエスト）を受け取ると、「交通整理員」のように設定されたルールに基づいて通信を仕分けて評価します。先の門番の例でいうと、リクエストに対して「検問を行う」ということです。
その仕分けと評価時に、AWS WAF が取る「アクション」は以下の4通りです。
- 許可 (Allow):
- 安全と判断された通信を通し、WAF の保護対象リソースへアクセスすることを許します。「どうぞ、お通りください」ということです。
- ブロック (Block):
- 「不正・危険」と判断された通信を遮断します。リソースへのアクセスは拒否されます。「ストップ、通っちゃだめ」ということです。
- カウント (Count):
- 通信は通しますが、「怪しい通信が来ていた」という記録がされます。新しいルールが問題ないか試す「偵察モード」のように使えます。
- CAPTCHA / チャレンジ (Challenge):
- 人間かボットかを確認する「追加検査」を行います。ボットによる自動攻撃を防ぐのに役立ちます。
この4つのうち、メインは最初の3つの「許可 (Allow)、ブロック (Block)、カウント (Count)」です。頭文字を取って「ABC (Allow/Block/Count)」とすると覚えやすいです。この3つは WAF の理解において大前提になるため、しっかり覚えましょう。
さて、これらのアクションにおいて非常に重要なのが、各アクションには「評価を終了させる（Terminating）」ものと「評価を継続する（Non-terminating）」ものの2種類がある、という点です。先の3つの「ABC」についてどっちがどっちなのか、記載します。
評価を終了させる (Terminating) アクション: Allow, Block
許可 (Allow) と ブロック (Block) は、評価を終了させるアクション、「終了アクション」です。
ルールに合致してこれらのアクションが実行されると、その時点でリクエストの「許可かブロックか」が最終決定され、それ以降の優先度が高いルール（数値が大きいルール）の評価は一切行われません*3。「通行許可」または「通行禁止」の最終判断が下され、その時点で手続きが完了します。
評価を継続する (Non-terminating) アクション: Count
一方、カウント (Count) は評価を継続するアクション、「非終了アクション」です。
ルールに合致しても、リクエストをカウントするだけで、「許可かブロックか」の最終判断は下しません。次の優先度のルールへと進み、そのまま次の評価が続行されます。
検問で例えると「要注意人物として記録は取ったけども、まだ通してよいかの最終判断は下していない」状態で、次のチェックポイントに進ませるようなイメージです。
まず「Allow/Block が評価を終了させ、Count は評価を継続させる」という基本をしっかり押さえましょう。この「評価を終了させるか否か」の違いが、後述するルールの優先度やデフォルトアクションの挙動を理解する鍵となります。
AWS WAF の主要コンポーネント
続いて、AWS WAF 実装の理解に不可欠なコンポーネントの説明に移ります。コンポーネントとしては、4つ覚えておく必要があります。
AWS WAF を設計＆設定するには、いくつかの「部品」を組み合わせ、それらを「1つの箱に入れる」イメージを持つと分かりやすいです。各部品が箱の中でそれぞれに動作し、「門番」としての役割を全うします。
1. Web ACL (ウェブアクセスコントロールリスト)
これが AWS WAF の基礎コンポーネントであり、様々なセキュリティポリシーを収納していく「1つの箱」です。
どの AWS リソース（ウェブサイトや API など）を守るか、どんな「ルール」（部品）を使って守るか、そしてルールに当てはまらない通信をどう扱うか（デフォルトアクション）という、全体の方針を決定します。デフォルトアクションは「Allow, Block」のどちらかです。
2. ルール (Rules)
ルールは、部品そのものであり、具体的な「指示」や「検査項目」です。
「どんな通信を検査するか（条件）」と「条件に合致した場合どうするか（アクション）」のセットで作成され、これが実際に不正なアクセスを検知・防御するための具体的な指示書になります。直接 Web ACL に追加することも、後述の「ルールグループ」としてまとめて利用することも可能です。
IAM で例えると、IAM ポリシーを「インラインポリシー」で記載することも「カスタマー管理ポリシー」として記載して個別に使いまわすこともできるということです。
3. ルールグループ (Rule groups)
名前の通り、各ルールをひとまとめに束ねてグループを作成したものです。
自分でルールを作ってまとめることもできますが、特に便利なのは AWS や各セキュリティベンダーが用意した「マネージドルールグループ」です。これは、よくある攻撃パターンに対応した指示書があらかじめセットになった、「専門家おすすめの部品セット」であり、適切に利用することで構築の手間を大幅に削減できます。
特に AWS が管理しているルールグループを「AWS マネージドルール」と言い、以下にまとまっています。
4. WCU (Web ACL Capacity Units)
Web ACL がどれほど「複雑」か、あるいは「処理能力を必要とするか」を示す数値が WCU です。高性能な部品（複雑なルール）ほど多くのWCUを消費します。
特に AWS WAF の無料利用枠は、この WCU の合計が1500までと定められています。もし 1500 WCU を超えると、超えた分に対して料金が発生します。そのため、特にコストを抑えたい場合は、この数値を意識してルール（部品）を選択することが重要になります。
なお、2023年4月にアップデートがあり現在 WCU は 5,000 まで設定が可能となっています。
利用料金について
本ブログでは技術に焦点を当てるため、利用料については詳しく触れないこととします。詳細は以下の AWS 料金ページを確認してください。
ルールで設定できる条件の例
WAF がどのような通信をブロックできるのかイメージを持っていただけるよう、以下に例を記載します。ルールでは、具体的に以下のような点で通信をチェックできます*4。
- どこから来たか？：IPアドレス、国
- 何をしに来たか？：リクエストの中身に特定の文字列やパターンはないか？正規表現が利用可能
- 荷物（データ）は大きすぎないか？：リクエストのサイズ
- 怪しい道具（コード）を持っていないか？：SQLインジェクションやクロスサイトスクリプティングの兆候はないか？
これらの条件を組み合わせて、「怪しげな通信」を定義し、ルールという部品を作り上げます。
AWS WAF を図で理解する
ここまでの用語説明の振り返り
まずはここまで説明してきた内容を振り返ります。
- 通信を仕分けて評価を下すのが「アクション」で、代表アクションが「ABC (Allow/Block/Count)」
- アクションは「終了アクション」と「非終了アクション」に分かれる
- 終了アクションは「Allow, Block」の2つで、その場で最終決定がされる
- 「Count」は非終了アクションで評価が継続する
- Web ACL が AWS WAF の基礎コンポーネントで、「部品」を入れる「箱」
- Web ACL を各種 AWS サービスに紐づけて利用する
- Web ACL には Allow か Block かの「デフォルトアクション」が必須
- ルールが「部品」で、ルールグループはそれを束ねたもの
- AWS やセキュリティベンダーの用意したマネージドルールグループが利用できる
- WCU (Web ACL Capacity Units) という独自のユニットで管理され 1,500 までが無料の範囲
ここから先を読み進めるにあたってこれらが前提となるため、しっかりと振り返りの内容を理解ください。
理解を深めるための AWS WAF の構成図
さらに理解を深めるために、図で見ていきましょう。なお本構成図は「Security Automations for AWS WAF > Implementation Guide > Architecture overview」を参考にしました。
Web ACL を作成する
まず AWS WAF を構築するとき、最初に部品を入れる「箱」である Web ACL を作成します。最初はルールが何もないため「空」です。なお空の状態では 0 WCU になります。
そして、Web ACL には「デフォルトアクション」が必要です。今回は「許可 (Allow)」をデフォルトアクションとして選択しています。
もしこの空の状態の WAF にリクエストを投げ込むと、デフォルトアクションの「許可 (Allow)」に到達し、WAF は素通りとなります。
デフォルトアクションに関する補足事項
AWS WAF の基本として、まずはデフォルトアクションを「Allow」に設定し、必要なブロックルール（例えばマネージドルールグループなど）を追加していく方法が分かりやすいでしょう。つまり「ほとんど全てのユーザーは通過させる」という前提の設定です。
デフォルトアクションを「Block」とするということは「ほとんど全てのユーザーは通過させない」という前提になります。実際に運用した経験からも言えるのですが、この設定は通常の Web サイトでは一般的ではなく、運用の手間も増えます。
なお、デフォルトアクションのそれぞれの違いは以下のドキュメントにも説明があります。
Web ACL にルールグループを追加していく
「部品」であるルールグループを「箱」となる Web ACL へ追加していきます。
各ルールグループには「アクション」が必要です*5。「Allowed List」というルールグループには終了アクションである「許可 (Allow)」を設定しました。
このようにして、ルールグループを Web ACL という箱へどんどんと追加していきます。終了アクションが「ブロック (Block)」となるものもそれぞれ追加したのが上図です。
なお、本来ルールグループを追加するごとに WCU が加算されていきますが、少々見栄えが煩雑になるため図には記載しておりません。
さて、このようにルールグループを追加すると、完成したように見えます。見えますが、この状態では「どの順序でルールグループが評価されて行くのか」がわかりません。
優先度を理解する
ここで先ほど記載した「優先度」の話です。図では左端に優先度を記載し、上のルールグループから順に評価がされることを示しています。
Web ACL に追加されたルールやルールグループは、設定された「優先度（Priority）」という数値が小さい順に評価されて行きます。このため、ルールグループを設定するときは必ず「優先度」も設定*6します。
WCU を含めたルールグループの選択とこの優先度の設計が WAF 設計における肝といって良いでしょう。
優先度と終了アクションの関係を理解する
そして優先度に関連し、「Terminating/Non-terminating」の知識が WAF の設計ではこれまた非常に重要となります。
先の通り AWS WAF は、リクエストが来ると優先度の低い順に（図でいう上から順に）ルールグループをチェックしていきます。そして、途中でルールに合致した場合、そのルールのアクションを確認します。もしアクションが「許可 (Allow)」または「ブロック (Block)」（終了アクション）であれば、その時点で評価は完全に終了します。それ以降の優先度のルールはチェックされません。
ですが、もしアクションが「カウント (Count)」（非終了アクション）であれば、カウント処理を行った上で、評価は次の優先度のルールへと続行されます。
具体例として、「Allowed List」に企業のグローバル IP アドレスを登録しておいた場合、その条件に合致すれば終了アクションで即時「許可」されます。後続のルールグループを通過することはありません。
もう1つ例を出しましょう。「Allowed List」「Denied List」以外を全て「カウント（伝わり易く口頭で"カウントモード"と言うことがあります）」とした場合を考えます。
図のルールグループの下3つは「終了アクション」ではないため、「Allowed List」「Denied List」をリクエストが通過した後は、各ルールグループのルールに条件が合致したとしても、それ以降の優先度のルールでチェックが継続されます。そして、デフォルトアクションまでたどり着くことになり「許可」されます。
先の説明でカウントを「新しいルールが問題ないか試す「偵察モード」のように使えます。」と記載していたのはこのことを示しています。
新しいルールグループを本番環境にデプロイする時、最初から「ブロック」で運用しはじめてしまうと、思わぬ誤ブロック（誤検知）をしてしまう場合があるため、一定期間ブロックモードで運用し、ログ解析等を実施してからブロックモードに変更する、という順序でリリースがされることがあります。
なお関連して、以前「カウントモードのログの分析方法」についてブログを記載しておりますので、合わせてご紹介します。
このように、Allow か Block のアクションが実行された時点で評価が打ち切られること、そして Count は評価を止めずに次のルールに進むということを理解しておきましょう。
AWS WAF で保護できるリソースと設定ルール
さて、AWS WAF は Web ACL という「門番」を作った後、リソースに紐づけてはじめて効果を発揮します。現時点で設定(保護)が可能な AWS サービスは以下の通りです。
- Amazon CloudFront distribution
- Amazon API Gateway REST API
- Application Load Balancer
- AWS AppSync GraphQL API
- Amazon Cognito user pool
- AWS App Runner service
- AWS Verified Access instance
- AWS Amplify
そして設定におけるルールも押さえておきましょう。
You can associate each AWS resource with only one web ACL. The relationship between web ACL and AWS resources is one-to-many.
(日本語訳) 各 AWS リソースは 1 つのウェブ ACL のみに関連付けることができます。ウェブ ACL と AWS リソースの関係は 1 対多です。
https://docs.aws.amazon.com/waf/latest/developerguide/how-aws-waf-works-resources.html
one-to-many は設計において大きなポイントです。つまり、1つの AWS WAF (Web ACL) に、多数の AWS リソースをアタッチすることができるため、具体的には10個の ALB が全て同じ AWS WAF の Web ACL に紐付けされている、という構成も可能です。
ですが、逆はできません。1つの ALB に 2つの Web ACL を紐づけることはできず、そのように設定すると「後から設定した Web ACL」が関連リソース奪い取ってしまいます。
また、CloudFront 用に作成された Web ACL はそれ専用であり、他の種類のリソース（ALB や API Gateway など）には同時に紐付けられないという制限があります。これは、CloudFront が「グローバル」なサービスであるのに対し、ALB や API Gateway などは特定の地域（リージョン）内で動作する「リージョナル」なサービスだからです。
画像の通り、構築前に適切なリージョンを選択してから Web ACL を作成しますが、CloudFront の場合はここで選択を間違わないようにしましょう*7。
まとめ
本ブログは AWS WAF を基礎から学ぶ初学者向けにできるだけわかりやすく、各コンポーネントや用語、仕様について記載しました。
以下は、AWS WAF の図の例と、途中で記載したまとめの再掲です。
- 通信を仕分けて評価を下すのが「アクション」で、代表アクションが「ABC (Allow/Block/Count)」
- アクションは「終了アクション」と「非終了アクション」に分かれる
- 終了アクションは「Allow, Block」の2つで、その場で最終決定がされる
- 「Count」は非終了アクションで評価が継続する
- Web ACL が AWS WAF の基礎コンポーネントで、「部品」を入れる「箱」
- Web ACL を各種 AWS サービスに紐づけて利用する
- Web ACL には Allow か Block かの「デフォルトアクション」が必須
- ルールが「部品」で、ルールグループはそれを束ねたもの
- AWS やセキュリティベンダーの用意したマネージドルールグループが利用できる
- WCU (Web ACL Capacity Units) という独自のユニットで管理され 1,500 までが無料の範囲
また、設計においては、WCU を含めたルールグループの選択、そして各ルールグループの優先度と終了アクションの関係を理解することが重要とも記載しました。Web ACL と AWS リソースとの紐付けにおいては、対応している保護可能なリソースと one-to-many の関係があるのもポイントです。
少々長くなってしまいましたが、本ブログで AWS WAF の基本が少しでも理解頂ければ嬉しく思います。
では、またお会いしましょう。
*1:例えば、個人情報を盗み出す SQL インジェクションと言われる攻撃や、サイトを改ざんするクロスサイトスクリプティングなど
*2:あくまで一定の効果を発揮するのに留まります。DDoS 攻撃に対して完全回答が可能ではない点に念のため注意してください
*3:優先度については後述します
*4:参考 URL https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html
*5:ルールグループ内にあるルールごとに個別のアクション設定も可能
*6:ルールグループの優先度を後から変更し、評価順を入れ替えることも可能です
*7:CloudFront 用なのに Web ACL を Tokyo Region に作ってしまっていて、紐付けができなくて気付くというミスはやらかしがちです。Web ACL から作り直しなので、最初から全てやり直しになります
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。
