WAFとは？ わかりやすく10分で解説

WAF（Web Application Firewall）は、Webアプリケーションを狙う攻撃を、HTTP/HTTPSの内容まで見て検知・遮断する防御機構です。ファイアウォールだけでは止めにくい攻撃への防御線として機能しますが、WAFを置いただけで脆弱性が消えるわけではありません。アプリケーションの修正、認証設計、監視と合わせて使う前提で導入する必要があります。

WAFとは何か

WAFは、Webアプリケーションに届くHTTP/HTTPSリクエストとレスポンスを解析し、ルールに基づいて通過・遮断・記録を行う仕組みです。URL、ヘッダー、Cookie、パラメータ、ボディなどを見て、不審なパターンや既知の攻撃シグネチャに一致する通信を止めます。主な保護対象は、公開Webサイト、会員サイト、EC、業務アプリ、APIです。

WAFの基本的な役割

WAFが担うのは、Webアプリケーションの手前でリクエスト単位の判定を行い、攻撃の成立を妨げることです。代表例として、SQLインジェクション、クロスサイトスクリプティング、ディレクトリトラバーサル、既知の不正入力パターンへの対処が挙げられます。検知ログが残るため、どのURLや機能が狙われているのかを把握しやすい点も利点です。

ネットワークファイアウォールやIDS/IPSとの違い

ネットワークファイアウォールは、主にIPアドレス、ポート、プロトコル単位で通信を制御します。IDSやIPSは不審な通信の兆候を検知・遮断します。一方、WAFはアプリケーション層でHTTP/HTTPSの内容を見て判断するため、Web入力を悪用する攻撃に寄せた制御ができます。置き換えではなく、役割分担で使う対策です。

どこに置かれるのか

WAFはWebアプリケーションの前段に置かれることが多く、構成上はリバースプロキシサーバーに近い形で動作する製品もあります。導入形態はクラウド型、アプライアンス型、ソフトウェア型などに分かれますが、どの方式でも「守る対象」「TLS終端の位置」「ログの保管先」を先に決めておかないと、後で設計がぶれやすくなります。

WAFで守れる範囲

WAFは万能ではありません。止めやすい攻撃と、アプリケーション側の対策が主軸になる攻撃を分けて考える必要があります。

WAFが止めやすい攻撃

WAFが比較的対処しやすいのは、HTTPリクエストの中に不自然なパターンが現れやすい攻撃です。たとえば、SQL文の断片を混ぜる入力、<script>のような不審な出力誘導、想定外のファイル参照、既知の攻撃シグネチャへの一致などは、ルールベースでも見つけやすい部類に入ります。公開フォーム、検索機能、ログイン画面、アップロード機能のように外部入力を多く受ける箇所では、WAFが前段の防御線として効きやすくなります。

WAFだけでは足りない攻撃

クロスサイトリクエストフォージェリのように、見た目は正規のリクエストに近い攻撃は、WAFだけで防ぎ切れません。CSRFトークンの検証、SameSite属性の設定、状態変更リクエストの設計見直しなど、アプリケーション側の対策が主軸になります。同様に、認可不備、業務ロジックの欠陥、漏えいした認証情報の悪用、セッション管理の不備も、WAF単体で解決できる領域ではありません。

脆弱性対策との関係

WAFは、脆弱性を修正する製品ではありません。アプリケーションに欠陥が残っている状況で、被害を抑えたり、暫定的な防御線を追加したりする用途では役立ちますが、恒久対策は入力検証、出力エスケープ、認証認可の見直し、ライブラリ更新などで進めます。WAFを入れたことで改修を後回しにすると、例外設定だけが増えて守りが弱くなります。

導入形態と配置の考え方

製品選定では、機能表だけで決めるより、どこに置くか、誰が運用するか、どの単位で守るかを先に固めた方が失敗しにくくなります。

クラウド型WAF

クラウド型は、導入までの時間を短くしやすく、トラフィック増加への追従もしやすい構成です。CDNやDNS切り替えと組み合わせて使う製品も多く、公開サイトの前段に置きやすい反面、ログの保管場所、障害時の切り分け、証明書運用、データの通過経路は事前確認が欠かせません。海外リージョンをまたぐ構成では、法務や社内規程との整合も見ておく必要があります。

オンプレミス型・アプライアンス型WAF

オンプレミス型やアプライアンス型は、自社のネットワークや既存機器との連携を細かく設計しやすい方式です。反面、冗長化、性能見積もり、機器更改、保守期限の管理まで自社で背負う範囲が広がります。暗号化通信の終端位置やバックエンドとの接続方式まで含めて設計しないと、思ったほど柔軟に運用できないことがあります。

守る単位を先に決める

WAFは「会社全体に一つ入れれば終わり」という製品ではありません。Webサイト単位で守るのか、アプリケーション単位で守るのか、API群まで含めるのかで、必要な性能もルールの粒度も変わります。見積もり段階で対象ドメイン、アプリ数、ピーク時のリクエスト数、ファイルアップロードの有無、TLS終端の位置を洗い出しておくと、導入後の想定違いを減らせます。

WAFの設定と運用

WAFは、導入直後から最適な検知精度になるわけではありません。正規通信を止めない状態を維持しながら、検知精度を上げていく運用が前提になります。

最初は検知モードから始める

導入直後に全面遮断へ切り替えると、正規のフォーム送信や検索機能まで止めることがあります。まずは検知中心でログを集め、どのURLで、どのパラメータが、どのルールに引っかかるのかを確認したうえで、遮断対象を絞っていく進め方の方が安全です。特に、文字種が多い検索画面、自由入力欄、ファイルアップロードは誤判定が出やすいため、早い段階で重点確認した方がよい箇所です。

ログ監視とチューニングを続ける

WAF運用の中心はログです。攻撃と思われる通信が本当に悪性なのか、正規利用なのにルールへ触れただけなのかを見分けながら、ルール調整と例外設定を進めます。例外を広く取りすぎると攻撃も通しやすくなるため、対象URL、対象パラメータ、HTTPメソッドなど、必要最小限の条件で切り分ける姿勢が求められます。

アプリ変更時にWAFも見直す

アプリケーションの仕様が変われば、受け付ける入力値や通信パターンも変わります。新しいフォーム、検索条件、アップロード形式、APIエンドポイントを追加したのにWAF設定だけ古いままだと、誤検知が増えるか、逆に見るべき通信を見逃します。リリース手順の中にWAF設定確認を組み込んでおくと、変更後の事故を減らしやすくなります。

WAF運用で起こりやすい課題

偽陽性と偽陰性

偽陽性は正規通信を誤って攻撃と判定する状態、偽陰性は本来止めたい攻撃を通してしまう状態です。WAF運用ではどちらもゼロにはなりません。偽陽性が増えると業務影響が出て、偽陰性が増えると防御線としての価値が落ちます。ログ確認、ルール更新、アプリ側の入力制御改善を繰り返しながら、どちらに偏っているかを点検します。

性能とTLS終端

WAFはHTTP/HTTPSの中身を見て判断するため、通信量が増えるほど負荷が上がります。画像配信や大容量アップロード、APIの高頻度呼び出しがある環境では、スループットだけでなくTLS復号と再暗号化の負荷も見積もらないと、ボトルネックになりかねません。ピーク時の遅延、ログ出力量、バックエンドへの影響まで含めて確認します。

例外設定の積み上がり

WAF運用が長くなると、誤検知対応のための例外が増えやすくなります。理由の分からない例外が積み上がると、どこが本当に守れていて、どこが開いているのかを誰も説明できなくなります。例外には期限、対象範囲、設定理由を残し、定期的に棚卸しする運用を組んでおく方が管理しやすくなります。

API時代のWAFの考え方

API中心のアプリケーションでは、JSONボディ、トークン認証、機械対機械通信が増えるため、従来のWeb画面向け設定だけでは足りません。API向けのスキーマ検証、認証認可、レート制御、監査ログ整備と合わせてWAFを考える必要があります。WAFは前段の防御線として役立ちますが、API保護の全体を一台で完結させるものではありません。

結論

WAFは、Webアプリケーションを狙う攻撃に対して、HTTP/HTTPSレベルで前段防御を行う製品です。特に、公開Webサイトや外部入力の多い機能では、被害を抑える現実的な防御線になります。ただし、脆弱性修正や認可設計の代わりにはならないため、アプリケーション側の改修、監視、変更管理と組み合わせて運用する必要があります。製品比較に入る前に、守る対象、止めたい攻撃、運用担当、ログ確認の流れを言語化しておくと、導入後の失敗を減らしやすくなります。

よくある質問（FAQ）