WAF（Web Application Firewall／ワフ）とは、WebサイトやWebアプリケーションへの通信（HTTP／HTTPS）を検査し、SQLインジェクションやクロスサイトスクリプティング（XSS）といったWebアプリの脆弱性を突く攻撃を検知・遮断するためのセキュリティ製品です。ファイアウォールやIPSとは守る「層」が違い、アプリケーション層（OSI参照モデルのレイヤ7）に特化して働きます。
「WAFを入れれば安全」と語られがちですが、実際には得意なことと不得意なことがはっきり分かれます。この記事では、情シスの担当者がWAFの導入や運用を判断する際に押さえておきたい基礎を、公式資料を踏まえて整理します。
- WAFの定義と、ファイアウォール・IPSとの守備範囲の違い
- 検知方式（シグネチャ型／アノマリ型、ブラックリスト／ホワイトリスト）
- 製品タイプ（アプライアンス／ソフトウェア／クラウド）の選び方
- 導入前に情シスが押さえるべき運用上の注意点（誤検知・チューニング・限界）
WAFとは何か（1文で言うと）
WAFとは、Webアプリケーションに対する通信の中身を検査し、攻撃とみなしたリクエストを遮断（またはログ記録）する仕組みです。Webサーバの手前に置かれ、利用者からのリクエストとサーバからのレスポンスを通過させながら、あらかじめ定めたルールに照らして「これは攻撃パターンだ」と判断したものをブロックします。
IPA（情報処理推進機構）は「Web Application Firewall 読本」で、WAFを「ウェブアプリケーションの脆弱性を悪用した攻撃からウェブアプリケーションを保護するツール」と位置づけています。つまりWAFは、アプリ側に残る脆弱性を「外側から」覆い隠す緩衝材として機能します。
ファイアウォール・IPSとの違いは？
答え：守る層が違います。従来型ファイアウォールはIPアドレスやポート番号（レイヤ3～4）で通信を制御し、IPS／IDSはネットワーク全体の既知攻撃を検知します。一方WAFはHTTPリクエストの中身（URLパラメータ、フォーム入力、Cookieなど）まで見て、Webアプリ特有の攻撃を判定します。「80番ポートは開けておくが、その中を流れる悪意あるリクエストは止めたい」という、通常のファイアウォールでは手が届かない領域を担うのがWAFです。
| 対策 | 主に見る層 | 得意な攻撃 |
|---|---|---|
| ファイアウォール | IP・ポート（L3～4） | 不要な通信のブロック |
| IPS／IDS | ネットワーク全般 | 既知のネットワーク攻撃・マルウェア通信 |
| WAF | アプリケーション（L7） | SQLi・XSSなどWebアプリの脆弱性攻撃 |
なぜWAFが重要なのか
Webアプリケーションは、外部に公開されている以上つねに攻撃にさらされます。SQLインジェクションによる情報漏えいや、XSSを使った利用者への攻撃は、いまも実被害が絶えません。理想はアプリ側の脆弱性をすべて修正することですが、現実には次のような事情でそれが難しい場面があります。
- 脆弱性が見つかっても、改修に時間・予算・テスト工数がかかる
- 外部委託や既製パッケージで、ソースコードに手を入れられない
- すでに稼働中で、止められない・すぐ直せないシステムがある
こうした「直したいがすぐには直せない」期間の暫定的な防御として、WAFは現実的な選択肢になります。脆弱性そのものは残っていても、それを突くリクエストを入口で止められれば、被害を抑えられるという発想です。
WAFの仕組み・種類
検知方式：シグネチャ型とアノマリ型
WAFが「攻撃かどうか」を判断する方法は、大きく2つに分かれます。
- シグネチャ型（ブラックリスト型）：既知の攻撃パターン（文字列や正規表現）と一致するリクエストを弾く方式。既知攻撃に強い反面、パターンにない未知の攻撃は見逃しやすく、シグネチャの更新が欠かせません。
- アノマリ型（ホワイトリスト型／振る舞い型）：正常な通信の基準を定め、そこから大きく外れたリクエストを異常として扱う方式。未知の攻撃にも対応しうる反面、正常な通信の定義がずれると誤検知（正規利用者のブロック）が起きやすくなります。
実際の製品は、この両者を組み合わせて精度を高めているものが一般的です。防御ルールの土台としては、OWASPが公開する「OWASP Core Rule Set（CRS）」が広く使われています。
提供形態：アプライアンス／ソフトウェア／クラウド
IPAの整理を踏まえると、WAFの提供形態は次の3タイプに大別できます。
| タイプ | 概要 | 向いているケース |
|---|---|---|
| アプライアンス型 | 専用機器をネットワークに設置 | 大規模・自社データセンター運用、細かな制御が必要 |
| ソフトウェア型 | Webサーバ等にソフトを導入 | 既存サーバに組み込みたい、機器を増やしたくない |
| クラウド（サービス）型 | DNSを切り替え、事業者のWAFを経由 | 短期間で導入したい、運用を任せたい中小規模 |
近年はクラウド型が導入のハードルの低さから広く使われています。CDNとセットで提供されることも多く、DDoS対策と一体で検討されるケースも増えています。
情シスの実務での扱い（導入・運用の注意点）
ここが本題です。WAFは導入して終わりではなく、むしろ運用してからが本番です。現場でつまずきやすいポイントを挙げます。
WAFは脆弱性対策の「代わり」にはならない
WAFはあくまで攻撃を入口で緩和する仕組みであって、アプリの脆弱性そのものを消すわけではありません。導入後も、脆弱性の修正計画は別途進める前提で捉えるべきです。WAFを理由に改修を無期限に先送りすると、WAFのルールをかいくぐる攻撃が現れたときに一気に無防備になります。「時間を稼ぐための盾」と位置づけるのが健全です。
誤検知（フォールスポジティブ）との付き合い方
WAFの運用でもっとも悩ましいのが誤検知です。正規の利用者や業務システムの通信を「攻撃」と誤判定してブロックしてしまうと、問い合わせ対応や業務停止に直結します。導入直後はいきなり遮断せず、まず「検知のみ（ログ記録）モード」で一定期間ようすを見て、自社の正常な通信を学習・チューニングしてから遮断へ切り替える、という段階的な進め方が定石です。
正直なところ、限られた人員でこのチューニングとログ確認を続けるのは負担が大きく、「入れたはいいが誤検知が怖くて実質ログ監視モードのまま」という現場も珍しくありません。だからこそ、運用を誰がどこまで見るのか（自社かベンダーか）を導入前に決めておくことが、製品選び以上に重要になります。
HTTPS通信の復号（可視化）が前提になる
通信が暗号化（HTTPS）されていると、WAFは中身を検査するために一度復号する必要があります。証明書の管理や、復号にともなう性能・プライバシーの考慮も設計段階で押さえておきましょう。
導入前に参照したい公的資料
製品選定や検討項目の洗い出しには、まずIPAの公式資料に目を通すのが近道です。自前で長大なチェックリストを作る前に、以下を土台にすると検討の抜け漏れを減らせます。
- IPA「Web Application Firewall 読本」：WAFの定義・機能・導入運用の基礎を網羅
- IPA「Web Application Firewallの導入に向けた検討項目」：製品タイプの選択基準と体制面の論点
あわせて、Webアプリ自体の脆弱性を減らす取り組み（安全な設計・実装、定期的な脆弱性診断）と、担当者・開発委託先への地道な啓発も欠かせません。WAFは多層防御の一枚であって、単独の切り札ではないという前提を社内で共有しておくとよいでしょう。
関連用語
WAFを理解するうえで、あわせて押さえておきたい関連の考え方・用語です。
- ゼロトラストとは？：「境界の内側は安全」を前提としない設計思想。WAFのような入口対策と、内部を信用しない考え方は補完関係にあります。
- EDRとは？：端末側の検知・対応。WAFがWebの入口を守るのに対し、EDRは端末での不審な挙動を捉えます。
- DDoS攻撃とアクセス集中の違い：クラウド型WAFはDDoS対策と一体で提供されることが多く、あわせて検討されます。
まとめ
- WAFはWebアプリ層（L7）に特化した防御で、SQLインジェクションやXSSなど、通常のファイアウォールでは防げないWebアプリ特有の攻撃を入口で遮断する。
- 検知方式（シグネチャ／アノマリ）と提供形態（アプライアンス／ソフト／クラウド）で特徴が分かれる。近年は導入が容易なクラウド型が主流。
- WAFは脆弱性修正の代わりにはならず、誤検知対策と運用体制がカギ。「時間を稼ぐ盾」と位置づけ、多層防御の一枚として捉えるのが実務的。
出典
- IPA「Web Application Firewall 読本」 https://www.ipa.go.jp/archive/security/vuln/waf.html
- IPA「Web Application Firewallの導入に向けた検討項目」（WAF読本補足資料） https://www.ipa.go.jp/archive/files/000072484.pdf
- OWASP Core Rule Set（CRS） https://owasp.org/www-project-modsecurity-core-rule-set/
