WAFとは何か？ 「通信の中身」を検査するファイアウォールの仕組み

WebサイトやAPIは、利用者に広く使ってもらうために、インターネットに公開されています。しかし、一般のユーザーがいつでもアクセスできるということは、同時にサイバー攻撃者からも自由に通信を送り込めるということを意味します。

しかも厄介なことに、Webアプリケーションを狙うサイバー攻撃の多くは、一般ユーザーがページを閲覧する時と全く同じ「HTTP」や「HTTPS」という標準的な通信プロトコルを使って送り込まれます。

問い合わせフォーム、ログイン画面、ECサイトの決済ページ、システム連携用のAPI、こうした対象に送られてくる「Web通信の中身」をひとつずつ検査し、悪意あるデータや攻撃命令が入っていないかをチェックして遮断するのが「WAF（Web Application Firewall）」です。

この節では、セキュリティ対策の基幹であるWAFの役割や仕組み、一般的なファイアウォールとの違い、そして「何が守れて、何が守れないのか」という運用の注意点までを分かりやすく解説します。

WAFはWeb通信の「何」を見ているのか

ブラウザーやアプリからWebサイトへアクセスすると、裏側では「HTTPリクエスト」と呼ばれるデータが送信されています。HTTPリクエストには、開きたいページのURLを含め、以下のような多様な情報が含まれています。

• アクセス先のURLやパラメータ
• ブラウザーやOS情報などのHTTPヘッダー
• ログイン状態などを保持するクッキー（Cookie）
• 問い合わせフォームや入力欄に書き込まれたテキストデータ

WAFは、これらの送信データの中身をリアルタイムで監視し、あらかじめ登録された「攻撃のパターン（ルール）」と照らし合わせます。もし入力データの中にデータベースを不正操作する怪しい命令や、悪意あるプログラムが紛れ込んでいれば、WAFがそれを検知して通信を遮断（Block）したり、追加の確認（Challenge）を実行することもあります。

そこでは、誰がアクセスしてきたか（IPアドレスや送信元）を確認するだけでなく、通信データの中身を検査し、「Webサイトに対して何を行おうとしているか」を判断します。それがWAFの重大な役割です。

出典： Cloudflare Docs: Web Application Firewall

ネットワークファイアウォールとWAFの違い

WAFにも、名前に「ファイアウォール」が付いているため、WAFもファイアウォールの一種には違いありません。しかし、単に「ファイアウォール」と呼ばれることの多い従来からある「ネットワークファイアウォール」と「WAF」とでは、守る場所と役割が全く異なります。

• ネットワークファイアウォール
  • IPアドレスや通信ポート（扉番号）を見て、「どの送信元からの通信か」、「どの扉を使って入ろうとしているか」を確認し、制限する
• WAF（Web Application Firewall）
  • 通ることを許可されたWeb通信（80番や443番ポート）のパケットの中身を開けて検査し、アプリケーション層への攻撃を防ぐ

企業の事業所などの建物への入場にたとえるなら、ネットワークファイアウォールは「敷地に入ろうとする車両や歩行者をチェックする門番」のようなもの。一方のWAFは、「建物に入った後、目的の部署の部屋に入る前に持ち物や申請書の中身を精査する検査員」のようなものだと考えられるでしょう。

どちらか一方があれば良いというものではなく、役割が異なる二重の防御として機能するものなのです。

WAFで守れる攻撃

WAFが特に絶大な効果を発揮するのは、Webアプリケーションの脆弱性（プログラムの隙）を狙う典型的なサイバー攻撃です。以下のようなものが含まれます。

• SQLインジェクション： ユーザー情報の入力欄などを通じてデータベースへ不正な命令を送り、データを漏洩させたり、改ざんしたりする攻撃
• クロスサイトスクリプティング（XSS）： ページ内に悪意あるスクリプトを埋め込み、閲覧者のブラウザー上で不正実行させる攻撃
• 既知の脆弱性を狙う攻撃： WordPressやCMS、ライブラリの公知の脆弱性を狙った不審なアクセス
• 特定の管理画面やパスへの不正アクセス： 通常はアクセスしない階層への不審なリクエスト

Cloudflare WAFに代表される現代のクラウド型WAFでは、セキュリティベンダーが常に最新の攻撃パターンを更新し、提供してくれる「Managed Rules（管理型ルール）」が用意されています。自社でゼロからルールを書かなくても、導入した瞬間から世界中の最新脅威に対応できるという大きなメリットがあります。

出典： Cloudflare Docs: Managed Rules

出典： AWS Managed Rules for AWS WAF

WAFでは守れないもの

このように、非常に頼もしいWAFではありますが、それでも「これさえ入れればセキュリティは完璧」という魔法のツールではありません。以下のように、WAFでは解決できない問題もあります。

• Webアプリ自体の設計ミス： URLのID部分を手動で変更すると他人のマイページが見えてしまうようなロジックの不備
• 社内のID、パスワードの管理不備や使い回し
• 退職者や外部委託先のアカウント権限の放置
• CMSやライブラリの更新を怠ったことによる根本的な脆弱性
• 社内PCのマルウェア感染

WAFが監視しているのは、あくまで「外部から届く通信データ」です。正当なログイン手続きを経て行われる不正操作や、アプリケーション自体のロジックの不備による不正アクセスまでは防ぐことができません。

WAFはWebアプリの改修や脆弱性対応（アップデート）を不要にするものではなく、あくまでアプリの修正対応が完了するまでの間、危険な通信を入口で食い止めるための「防波堤」として位置づけるべきでしょう。

強く設定すれば良いわけでもない： WAFの「誤検知」との付き合い方

WAFを運用する上で最も注意しなければならないのが「誤検知（False Positive）」です。誤検知とは、攻撃ではない正当なユーザーからのアクセスを、WAFが誤って攻撃だと判断して遮断してしまう現象を指します。

例えば、ECサイトの複雑な商品検索、問い合わせフォームでの長文入力、あるいは開発者向けのAPI通信などでは、攻撃を意図していない文字列の中に、たまたま攻撃と認知されやすい記号や特殊なコードが含まれることがあります。安全性を高めようとしてWAFの判定ルールを極端に厳しくしすぎると、商品の購入や問い合わせ、といった通常のユーザーの通信まで弾いてしまい、ビジネス上の大きな「機会損失」につながることになりかねません。

それを防ぐためには、WAFの運用は、「いったん設定したら終わり」にしないことが重要です。以下のような手順による、慎重な運用が求められます。

1. 設定、導入
2. ログの監視（アクセス状況の確認）
3. 誤検知の確認、例外ルールの調整
4. 本格的な遮断（Block）運用へ移行

WAFは単に強くすればよい、というものではなく、正当な利用を妨害することなく、攻撃だけを的確に抑えるよう、チューニングを重ねていくものなのです。

他社WAFとの違いと選定のポイント

WAFはCloudflareだけでなく、各社から提供されています。各社WAFの特徴をざっとまとめておきましょう。

• Cloudflare WAF： CDN、DDoS対策、Bot対策などと統合されており、Web通信の最前線（エッジ）で一括して防御しやすい
• AWS WAF： Amazon CloudFrontやAPI Gateway、ALB(Application Load Balancer)など、AWS環境との親和性が高く組み込みやすい
• Azure WAF: Azure Front DoorやApplication Gatewayへ配置して、AzureのWebアプリと組み合わせやすい
• Google Cloud Armor： WAFとDDoS対策を提供し、Google Cloudだけでなくハイブリッドやマルチクラウド構成も対象にできる
• Akamai App & API Protector： WAF、API保護、Bot対策、L7 DDoS防御などを統合して扱える

選定にあたって重要なのは、どのWAFが最も強力か、という単純な比較ではありません。自社のWebシステムがどこのサーバーに置いてあり、誰が運用やログ確認を担当するのか、といったことまでを含めた全体構成に適合したものを選ぶことが重要です。

出典： AWS WAF

出典： Microsoft Azure WAF

出典： Google Cloud Armor

出典： Akamai App & API Protector

DOMOの視点

製品を選ぶ前に、守るべき入口を整理する

DOMOとしてWAFの導入を検討する際、最初から特定の製品やセキュリティルールを提案することはありません。まずはじめに、お客様のWebサイトにおける「入口」を整理します。それには、以下のようなものが考えられます。

• 公開ページ（トップや記事など）： 誰でもスムーズにアクセスできることが最優先
• 問い合わせ、採用フォーム： 不自然な入力値や連続投稿を警戒
• ログイン画面： 攻撃内容だけでなく、アクセス試行の回数（Rate Limiting）も注視
• CMS管理画面： WAF以前に、アクセスできるIPやメンバーを制限
• API： 通信内容の検査に加え、認証や利用頻度の制御を組み合わせる

すべてのページに対して、一様に厳しいWAFルールを適用するのではなく、「誰が、どの程度の頻度でアクセスするのが自然か」という入口ごとの性質や、正常な利用範囲を定義することから始めます。

WAFを導入しただけで満足するのではなく、正当なユーザーにストレスを与えず、不審な通信だけを的確に抑えられているかを、運用を通じて確認し続けることが不可欠です。WAFは単なるセキュリティ製品ではなく、Webの健全な入口設計を継続的に実現するための強力な手段なのです。

まとめ

WAFは、WebサイトやAPIに届く通信データを検査し、アプリケーションの脆弱性を狙うサイバー攻撃を入口で食い止める仕組みです。 IPアドレスだけでなく、受信データに含まれる文字やコードといった、Web通信の中身を検査し、ルールと照合して危険な攻撃を検出します。

導入に当たっては、万能ではないことを理解することが大切です。アプリの設計ミスやアカウント管理不備は、WAFでは防げないため、脆弱性修正や運用管理と併用することが重要です。

また、ルールを厳しくしすぎると起こりがちな誤検知を防ぐ調整が不可欠となります。ログを確認しながら正当なアクセスを守るチューニングを継続しなければなりません。

覚えておきたい用語

• WAF（Web Application Firewall）： WebサイトやAPIへの通信データを検査し、アプリケーションの脆弱性を狙う攻撃を遮断する仕組み
• SQL Injection： 入力欄などを悪用してデータベースへ不正な命令を実行させ、データを操作、窃取する攻撃
• XSS（クロスサイトスクリプティング）： Webページ上に悪意あるスクリプトを埋め込み、ユーザーのブラウザー上で不正なコードを実行させる攻撃
• Managed Rules： セキュリティベンダーが作成・更新する、最新の攻撃に対応した管理型のWAFルールセット
• Custom Rules： 自社のWebサイトやAPIの条件に合わせて個別に作成する防御ルール
• 誤検知（False Positive）： 正当なユーザーのアクセスを、WAFが誤って攻撃と判断してしまい、結果としてブロックしてしまうこと
• Rate Limiting：　一定時間内のアクセス回数に上限を設け、過剰なキー入力や連続処理を制限する仕組み
• Bot対策： アクセスしてきたのが人間か自動プログラム（Bot）かを判別し、悪性Botを制限する仕組み