WAF（Web Application Firewall）は、HTTPやHTTPSの通信を解釈し、Webアプリケーション特有の攻撃パターン（SQLインジェクション、XSS、SSRF、ファイル取り込みなど）をリクエスト単位で検査・遮断するセキュリティ機器・サービスの総称です。オープンソースのModSecurity（2002年公開）が普及の口火を切り、現代ではCloudflare、AWS WAF、Akamai、Imperva、Azure Front Doorといったクラウドサービス型WAFが主流になっています。アプリ側の脆弱性修正には時間が掛かるという現実を踏まえ、前段で広く面を守る「仮想パッチ」の役割を担うインフラとして、現代のWebセキュリティに欠かせない存在です。
この記事の目次
- リクエストごとに署名と振る舞いを見る
- ModSecurityから巨大クラウドWAFへ
- 誤検知を抑える運用とチューニング
- FW・IPS・RASPとの違い
- まとめ
リクエストごとに署名と振る舞いを見る
WAFはHTTP/HTTPSリクエストを終端し、本体の解釈に渡す前にメソッド・URL・ヘッダ・クエリ・ボディを一括検査します。中核となるのがシグネチャ（既知攻撃パターン）の検出で、SQLインジェクションの典型構文、XSSのスクリプトタグ、コマンド注入、パストラバーサル、SSRF、デシリアライズ脆弱性などのパターンを多数登録したルールセットが用意されています。OWASP CRS（Core Rule Set）はその代表で、ModSecurityや各社製品で広く採用されています。
シグネチャだけでは未知の手口や巧妙な変種を取り逃すため、現代のWAFはIPレピュテーション、Bot識別、JavaScriptチャレンジ、機械学習による異常検知などを組み合わせます。TorやデータセンタIP帯、過去に攻撃を行った発信元を低スコア化、正規ブラウザ特有のJS実行能力をテストして自動化スクリプトを区別、通常の利用者像から逸脱したリクエスト頻度・パラメータを異常として浮かび上がらせる、といった多面的な判定を行います。ルールごとに「検知のみ」「警告」「ブロック」「CAPTCHA」「Challenge」など段階的なアクションを設定できる柔軟さも特徴です。
ModSecurityから巨大クラウドWAFへ
WAFの普及はオープンソースのModSecurityによって本格化しました。2002年にIvan Ristic氏がApache用のモジュールとして公開し、後にTrustwave・SpiderLabsが主導する形で改良が続けられ、Apache、Nginx、IISで動作する事実上の標準WAFとなりました。ルールセットとしてはOWASP ModSecurity Core Rule Set（CRS）が整備され、無償で高品質な防御ルールが手に入る環境が育ちました。オンプレ・自社運用の世界では今も基幹となっています。
2010年代以降はクラウドWAFが主流となり、Cloudflare、AWS WAF、Akamai Kona、Imperva、Fastly、Azure Front Doorなどが市場を二分しています。これらはCDNとの統合、Bot管理、DDoS防御、API保護、Workersのようなエッジ実行環境と組み合わせ、「Webアプリへの全入口を1か所で守る」エッジセキュリティ基盤として進化しました。近年はAPI仕様（OpenAPI）に基づく検証、GraphQLの構造化検査、機械学習による不正Bot識別など、従来のシグネチャの域を超えた高度な機能を備える方向に発展しています。
誤検知を抑える運用とチューニング
WAFはルール基盤の宿命として、誤検知（False Positive）と検知漏れ（False Negative）の両方に注意が必要です。本番投入の前段では、まず一定期間ブロックを行わず警告のみで稼働させる「学習モード」で運用し、正規アクセスのうちどれが誤検知されているかを徹底的に洗い出します。管理画面、決済処理、PDFアップロードなど特性の違うパスごとに閾値・除外ルールを調整するのが、現実的な運用作法です。
信頼できる外部サービス（決済代行、メールベンダー、検索クローラ）からのアクセスは、IPやUser-Agent、署名ヘッダで明示的に除外し、ログはSIEMに送ってインシデント横断で分析します。重要なのは、WAFを「アプリ修正を不要にする魔法の盾」と捉えないことです。WAFは攻撃の窓口を狭める仮想パッチであり、アプリ側のセキュアコーディング・最新化と組み合わせて初めて十分な強度を発揮します。「WAFで時間を稼ぎつつ根本修正を急ぐ」という運用思想を、設計と組織の両面に染み込ませることが鍵になります。
FW・IPS・RASPとの違い
WAFはネットワークファイアウォール（FW）や侵入防止システム（IPS）と混同されがちですが、層が異なります。従来型FWはL3/L4のIPアドレスやポート番号に基づく通過可否判定を行い、HTTPの中身は基本的に見ません。IPSはL3〜L7にまたがる汎用的な攻撃検知を行いますが、Webアプリ特有の文脈解釈は不得意です。WAFはL7のHTTP/HTTPSに特化し、URLやパラメータ、ボディの意味を踏まえてWebアプリ攻撃を捌くため、「アプリの目の前に置く専門の門番」という位置付けになります。
RASP（Runtime Application Self-Protection）はアプリ実行環境の内側に組み込まれ、実際のメソッド呼び出しやSQLクエリ生成のタイミングで攻撃を検知・遮断する仕組みです。WAFが「外から見える挙動を文字列パターンで判定する」のに対し、RASPは「内側の意味のある操作」で判定するため、誤検知が少なくゼロデイにも強い一方、アプリへの組み込みやエージェント管理が必要です。Bot管理製品は、Botのライフサイクル全体（クレデンシャルスタッフィング、スクレイピング、在庫狙いなど）に特化しており、WAFと併用してアプリ前段の防御を多層化する構成が現代の主流になっています。
まとめ
WAFは2002年のModSecurity以来、Webアプリ前面で攻撃を弾き続けるエッジセキュリティの主力です。OWASP CRSとクラウドWAF、Bot管理、API保護を組み合わせ、誤検知を地道に潰しつつアプリ側の修正と二段で運用すれば、SQLインジェクションやXSSのような古典攻撃から最新のBot脅威まで広く受け止められます。「アプリの修正を待つ間に攻撃面を狭める仮想パッチ」と捉えることが、効果を最大化する近道です。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント