WAFの導入は、遮断せず記録するだけの状態で本番の通信を見て、誤検知を直してから遮断へ移す順番で進めます。
今日やることは、止まると困るWebの機能を書き出すことです。問い合わせフォーム、資料請求、カタログのダウンロード、採用応募、サイトの管理画面、外部サービスとの連携を並べ、担当者の名前を横に書きます。この一覧が、後の確認の対象になります。
WAFの仕組みと製品の型はWAFの製品比較の解説に任せ、ここでは入れる順番だけを扱います。Webサイトのセキュリティ対策の一覧もあわせて見てください。
なぜいきなり遮断しないのか？
WAFは攻撃だけを止めるとは限らず、正常な通信を止めることがあるからです。
IPAのWAF読本 改訂第2版は、正常な通信を不正と判定する誤りを「偽陽性」と呼び、発生すると利用者がサービスを使えなくなる可能性があると説明しています。同じ資料は、テスト環境の確認だけでは利用者のあらゆる通信を想定できたとは言い切れないとして、すぐに対処が必要な場合を除き、必ずテスト運用期間を設けるよう示しています。
製品側の案内も同じ向きです。
- AWS WAFの文書は、テスト環境で調整した後、本番の通信にカウントモードで当てて調整し、それから有効にするよう案内しています
- Azure WAFの文書は、新しく入れたWAFを短い期間だけ検知モードで動かし、ログを見て例外などを整えてから防止モードへ移すよう案内しています
呼び名は製品ごとに違います。通過処理、カウント、検知モード、ログモードなどです。契約前に「遮断せず記録だけする動かし方があるか」と「ルールごとに切り替えられるか」を確かめます。製品を絞るときは、WAFの製品比較表で仕様を並べます。
導入は何をどの順番で進める？
遮断に切り替えるまでの流れは、次の5段階です。
| 段階 |
やること |
終わりの目安 |
| 1 準備 |
守るサイトと止めてはいけない通信を決める |
一覧と担当者がそろう |
| 2 事前確認 |
テスト環境で画面とフォームを一通り操作する |
主な操作が遮断されない |
| 3 検知運用 |
本番で記録だけ動かし、ログを読む |
主な業務の通信が一通り流れる |
| 4 調整 |
誤検知をルールと項目に絞って除外する |
同じ誤検知が再発しない |
| 5 遮断 |
影響を見ながらルールを遮断へ移す |
戻す手順を試してある |
IPAの読本には、IPA自身がModSecurityを入れた事例が載っています。導入判断から運用開始まで約2か月かかったと書かれています。読本は2009〜2010年のログを扱った時期の資料なので、製品の画面や機能は今と違います。期間は一つの事例として読み、段取りの考え方を使ってください。
段階1：止めてはいけない通信を決める
守る範囲を決めるときは、URLだけでなく通信の中身まで考えます。IPAの読本も、防御したい攻撃と保護したいアプリを洗い出すよう示しています。
たとえば、部品メーカーの問い合わせフォームなら、本文に型番や規格の記号、英語の仕様文、ハイフンや引用符の混じった文字列が入ります。図面のファイルを添付する欄があれば、大きなデータも流れます。こうした普段の入力を、確認に使う見本として用意します。
大きな添付を受けるサイトでは、検査の上限も確かめます。Cloudflareの文書によると、マネージドルールが検査するリクエスト本文には上限があり、Freeプランでは1MBです。上限を超えた部分は十分に分析されない場合があると書かれています。上限の値は製品ごとに違うので、見積もりの段階で聞きます。
段階2：テスト環境で画面を操作する
IPAの読本は、確認方法の一つとして、ブラウザで全てのリンクをたどり、遮断されないことを確かめる方法を挙げています。業者に導入を頼むなら、この検証を相談するよう書いています。
フォームは表示で終わらせず、送信まで行います。確認メールの到着、管理画面への保存、担当者への通知まで見ます。営業の人に普段の問い合わせ文を出してもらうと、記号や長文の見本がそろいます。
段階3：本番で記録だけ動かす
ログを読む頻度は先に決めます。IPAの読本は、偽陽性の有無を見たい場合に、数時間おきや1日1回といった短い間隔での確認を例に挙げています。
検知運用の日数を公式に定めた数字は見当たりません。Azureの文書も「短い期間」と書くだけです。私たちは、日数ではなく流れた通信で判断するのが筋だと考えます。月末にだけ動く受注データの連携、四半期に一度の取引先向け更新がある会社なら、それが一度通るまで待ちます。
誤検知が出たら、どう直す？
WAF全体を切らず、該当の通信に絞って直します。
Azureのトラブル対応の文書は、OWASPのルールは初期状態で厳しく作られていて、除外やカスタムルールの設定は通常のことだと説明しています。そのうえで、ログから該当のリクエストを探し、ルールと項目を特定する流れを示しています。
直すときの順番は次のとおりです。
- 問い合わせの日時や画面から、ログの該当行を探す
- 発動したルールの番号と、引っかかった項目を確かめる
- 本当に正規の通信かを、業務の担当者と確かめる
- その項目とルールだけを除外する
- 同じ操作をやり直し、ログと実際の送信結果を見る
除外を広げすぎない
除外した項目は検査されなくなります。Azureの文書も、特定の項目と関係するルールに絞るよう示しています。フォーム全体やサイト全体を対象から外すと、誤検知は消えても守りが薄くなります。
AWS WAFのテストの手順にも、誤検知を起こす通信を条件で分けて評価の対象から外す方法が載っています。自社で設定しない場合は、委託先に「どのルールを、どの項目について除外したか」を記録として残してもらいます。後で見直すときの手がかりになります。
遮断へはどう切り替える？
全ルールを一度に切り替えず、影響の大きな攻撃を防ぐものから移すと、問題の切り分けがしやすくなります。
IPAの事例は、全ルールを適用すると誤検知の可能性が高いと考え、影響が深刻なSQLインジェクションの検出パターンだけを有効にしました。動的な通信が多いAPIの部分は、検査の対象から外しています。何を守らなかったかを決めて記録している点が、参考になります。
切り替えの日は、次を用意します。
- 営業と総務に切り替えの日時を伝え、問い合わせが届かないときの連絡先を決める
- 元に戻す手順と権限を確かめ、夜間や休日に誰が判断するかを決める
- 切り替えの直後にフォームから1通送り、受信まで見る
- 電話番号やメールの窓口をエラー画面に載せ、遮断された人の行き場を作る
エラー画面の窓口は見落としやすい項目です。誤検知で止められた見込み客が、その場で別の手段を取れるようにします。受けた人がWAFの担当へ回す手順も決めておきます。
入れた後は誰が何を見る？
入れて終わりにすると、誤検知にも攻撃の変化にも気づけません。IPAの読本は、定期的なログの確認、検出パターンの更新、WAFの更新の適用を運用の仕事に挙げ、偽陽性の発生を前提に定期的な訓練を勧めています。商用のWAFは保守契約を結ぶ必要があるとも書いています。
情シス兼任の担当者だけで回らないなら、運用の代行が付く型を選ぶ、委託先の報告を月1回受けるなど、最初から人の手当てを決めます。クラウド型でも、誤検知かどうかを業務の目で判断する役目は自社に残ります。
WAFで足りない部分
- 脆弱性そのものは消えません。IPAはWAFを根本対策ではなく、影響を減らす運用面の対策としています
- 情報セキュリティ10大脅威 2026の組織編では「システムの脆弱性を悪用した攻撃」が4位です。脆弱性診断サービスの比較で、弱点を調べる手段もあわせて検討します
- 書き換えに気づく仕組みは別に要ります。Web改ざん検知の製品比較で、検査の間隔や通知の方法を見ます
サイトの更新や委託先との分担が決まっていない場合は、CMSと委託先で確かめる点を先に片づけると、WAFの担当も決めやすくなります。大量の通信でサイトが止まった場合の動き方は、DDoS攻撃を受けたときの初動にまとめました。サーバーの中を守るソフトは役割が別なので、サーバー向けセキュリティソフトの選び方で扱っています。
