WAFとは何か？

WAF（Web Application Firewall）は、HTTP/HTTPS の通信内容を見て、Webアプリケーション向けの攻撃をブロックする防火壁です。

ネットワークのファイアウォールが「どのIP・ポートへ通信できるか」を見るのに対し、WAFは URL・ヘッダー・リクエストボディなど、アプリケーション層（L7）の内容 をルールで評価します。

この記事の結論

• WAFは 本番トラフィックの入口 に置き、既知の攻撃パターンやボットなどを ルールベースで遮断 するための仕組み
• アプリの脆弱性そのものを直す道具ではない（防御の1層として使う）
• いきなり BLOCK ではなく、COUNT で観測してから適用 するのが安全
• AWS では CloudFront / ALB / API Gateway に AWS WAF を付与するのが典型
• まずは IP Reputation + Core rule set + Known bad inputs を基本セットにし、スタックに応じて追加する

運用の詳細は次の記事へ：

• AWS WAF マネージドルール運用: COUNT モードから本番適用まで
• SIEM on OpenSearch へ WAF ログを取り込む実践手順

WAFが守るもの・守れないもの

守りやすいもの（代表的な脅威）

守りにくいもの（WAFだけでは不十分）

WAFは 多層防御の1層 です。アプリ側の入力検証、認可設計、依存ライブラリの更新などと併用します（Webアプリ脆弱性診断の Shift Left 実践ガイド も参照）。

ネットワークFW・CDN・WAFの違い

CDNとWAFは 併用 されることが多いです。CDNで入口を集約し、その手前または同じ経路にWAFを置く構成が一般的です。

WAFの動き（ざっくり）

ルールの代表的なアクション

本番導入時は、いきなり BLOCK ではなく COUNT で誤検知を確認 してから BLOCK に昇格させるのが定石です（COUNT モード運用）。

AWS WAF ではどこに付けるか

AWS WAF は単体で動くのではなく、保護対象リソースにアタッチ して使います。

入口の責務全体（ALB / CloudFront / WAF の関係）は Apache / Nginx は必要？ でも触れています。

ルールの種類

1. マネージドルール

クラウド事業者やベンダーが用意した 既知攻撃向けルール群 です。AWS では AWS Managed Rules（例: Core rule set、Known bad inputs）が代表例です。

• メリット: すぐ導入できる、CVE系の既知パターンをカバーしやすい
• 注意: 誤検知があり得るので COUNT 期間が必要

2. カスタムルール

自社の要件に合わせて作るルールです。

• 特定パス（/admin）へのアクセス制限
• 特定国・IPレンジのブロック
• レートベースルール（同一IPからの過剰リクエスト）

3. ルールグループ

複数ルールをまとめた単位です。Web ACL にルールグループを追加して、評価順序と優先度を管理します。

AWS WAF では WCU（Web ACL Capacity） という容量上限があり、ルールを増やすほど消費します。追加前に見積もりが必要です（WCU の整理）。

AWS WAF の推奨ルール構成

ここでは AWS Managed Rules を中心に、実務でよく使う推奨構成を整理します。
いずれも導入直後は COUNT で観測し、誤検知がなければ BLOCK に昇格させます（COUNT モード運用）。

基本セット（まず入れる）

多くの Web サイト / API で、最初に検討するのは次の3つです。

合計 WCU: 925（1500 上限のうち約6割）。この時点でも十分な入口防御の土台になります。

スタック・用途に応じて追加するルール

基本セットに加えて、環境に合うものだけ足します。

「全部 ON」はおすすめしません。使っている OS・言語・フレームワークに関係するものだけ 足すのが現実的です。

カスタムルールとして足すとよいもの

マネージドルールだけでは足りない部分は、カスタムルールで補います。

レートベースルールは ログイン API・検索 API・POST 系 に優先して入れる価値が高いです。

推奨するルール評価順（上から評価）

AWS WAF では 優先度の小さい番号ほど先に評価 されます。典型例は次の順です。

• 許可リストを最優先 にすると、誤検知の影響を局所化しやすい
• レート制限はマネージドルールより前 に置くと、スキャン流量を先に落とせる
• デフォルトアクション は多くの場合 ALLOW（個別ルールで BLOCK）が運用しやすい

用途別のおすすめ構成例

一般的な Web/API（Linux + RDB）

1. Amazon IP Reputation List
2. Core rule set
3. Known bad inputs
4. SQLi rule set
5. Linux rule set
6. レートベースルール（ログイン・書き込み API）

合計 WCU 目安: 約 1365（上限 1500 以内に収まる典型例）

静的サイト + CloudFront

1. Amazon IP Reputation List
2. Core rule set
3. Known bad inputs
4. Anonymous IP List（必要なら COUNT で試す）

管理画面がなければ Admin Protection は省略できます。

API Gateway のみ（認証付き JSON API）

1. Amazon IP Reputation List
2. Core rule set
3. Known bad inputs
4. レートベースルール（/login /token など）

PHP / WordPress 向けルールは通常不要です。

入れない・慎重にすべきパターン

• 初日から全ルールを BLOCK 本番障害の原因になる。必ず COUNT 期間を設ける

• Anonymous IP List を無条件 BLOCK 正規ユーザーの VPN 利用で弾かれることがある

• Bot Control を理由なく全 API に適用 コストと誤検知のトレードオフが大きい。ボット問題が顕在化してから検討

• WCU を見ずにルールを追加 1500 を超えると追加料金。追加前に合計 WCU を計算する

導入の進め方（推奨）

1. 基本セット3つを COUNT で投入
2. WAF ログを S3 / CloudWatch Logs に出力
3. 1〜2週間、URI・User-Agent・誤検知を確認
4. 問題なければ基本セットを BLOCK に昇格
5. スタックに応じたルールを 1グループずつ COUNT → BLOCK
6. レートベース・Geo などカスタムルールを追加

ルール単位の昇格手順と WCU 表の詳細は マネージドルール運用記事 を参照してください。

WAFログをなぜ見るか

WAFを入れただけでは終わりではありません。何をブロックしたか・何を通したか をログで確認しないと、次の判断ができません。

• 誤検知（正常ユーザーをブロック）の検出
• 攻撃トレンドの把握
• ルール調整の根拠

ログの集約・可視化は SIEM への WAF ログ取り込み を参照。

導入時によくある誤解

• 「WAFを入れたら安全」 WAFは既知パターンや入口制御に強いが、アプリの設計ミスは別途直す必要がある

• 「BLOCK ルールを全部 ON にすればよい」 誤検知で本番障害になりうる。COUNT → 評価 → BLOCK の順が安全

• 「CDN があれば WAF 不要」 CDNは配信最適化が主目的。攻撃遮断は WAF の役割

• 「Shield があれば WAF 不要」 Shield は DDoS 対策が中心。SQLi や XSS などアプリ層の攻撃は WAF の領域

最低限の導入チェックリスト

1. 保護対象（CloudFront / ALB / API Gateway）を決める
2. マネージドルールを COUNT で投入する
3. WAF ログを S3 などに出力する
4. 1〜2週間、誤検知とヒット傾向を確認する
5. 問題なければ必要なルールだけ BLOCK に昇格する
6. 監視・アラートと SIEM 連携を整える

まとめ

WAFは Webアプリケーションの入口で HTTP を中身まで見て遮断する L7 防火壁 です。
ネットワークFWやCDN、DDoS対策と役割が違うので、入口の多層防御の1ピース として位置づけます。

AWS 環境では CloudFront や ALB に AWS WAF を付け、IP Reputation + Core rule set + Known bad inputs を土台に、COUNT で観測してから BLOCK する運用が現実的です。ルール運用とログ分析は、それぞれ次の記事で深掘りできます。

• AWS WAF マネージドルール運用: COUNT モードから本番適用まで
• SIEM on OpenSearch へ WAF ログを取り込む実践手順