「Webサイトのセキュリティ対策」と聞いて、真っ先に思い浮かぶのはファイアウォール（FW）でしょう。しかし、情報処理安全確保支援士（SC）を目指すあなたや企業のセキュリティ担当者なら、「ファイアウォールだけではWebサイトを守れない」という事実を知っておく必要があります。
昨今のサイバー攻撃の多くは、ファイアウォールが許可している「正規の通信経路」を通ってやってきます。頑丈な城門（FW）を築いても、商人の荷物に紛れ込んだ毒（SQLインジェクションなど）は見過ごされてしまうのです。そこで必要となるのが、荷物の中身を検査する検問官、すなわちWAF（Web Application Firewall）です。
本記事では、SC試験の午後問題で頻出のキーテクノロジーであるWAFについて、以下の要素を徹底解説します。
- 従来のFWやIPSとの決定的な違い（レイヤー視点）
- WAFの検知ロジックと具体的な防御対象
- クラウド型、ゲートウェイ型などの導入形態とネットワーク構成
- 実務で最も頭を悩ませる「誤検知（False Positive）」への対応
- 試験で使える記述テクニック
技術的な仕組みを丁寧に紐解きながら、合格に必要な知識レベルへと引き上げていきます。
1. なぜFWだけでは守れないのか？セキュリティの「階層」を理解する
セキュリティ対策を理解する上で最も重要なのは、「OSI参照モデルのどの層（レイヤー）を守る機器なのか」という視点です。FWとWAFは、守備範囲が明確に異なります。
従来のファイアウォール（FW）の限界：L3/L4の監視
従来のファイアウォール（パケットフィルタリング型）は、主に**ネットワーク層（L3）とトランスポート層（L4）**で動作します。FWがチェックするのは、パケットのヘッダ情報、つまり「通信の宛先と送信元」です。
FWが確認する項目は以下の通りです。
- 送信元IPアドレス：許可されたIPからのアクセスか？
- 宛先ポート番号：Webサーバーのポート（80/443）へのアクセスか？
- プロトコル：TCPかUDPか？
これを現実世界に例えるなら、「マンションのオートロック」です。住人や許可された訪問者（許可されたIPアドレス）であればドアを開けますし、宅配便（ポート80番）も通します。しかし、「宅配便の段ボールの中に何が入っているか」までは確認しません。
攻撃者が「正規のWebアクセス（ポート80番へのHTTP通信）」に見せかけて攻撃コードを送信した場合、FWはそれを「許可されたポートへの通信」として通過させてしまいます。これがFWの限界です。
WAFの守備範囲：L7（アプリケーション層）の監視
一方、WAFはアプリケーション層（L7）で動作します。FWが通した通信パケットを組み立て直し、HTTP/HTTPS通信の中身（ペイロード）を詳細に検査します。
WAFが検査する具体的な項目は以下の通りです。
- URLパラメータ：
http://example.com/search?q=...のqの値に不審な記号が含まれていないか？ - HTTPヘッダ：User-AgentやCookieに変な文字列が埋め込まれていないか？
- POSTデータ：ログインフォームに入力されたIDやパスワード欄にSQL文が入っていないか？
先ほどの例で言えば、WAFは「空港の手荷物検査場（X線検査）」です。パスポート（IPアドレス）が正しくても、カバンの中（HTTPデータの中身）に危険物（攻撃コード）が入っていれば、その場で没収・遮断します。
Webアプリケーションの脆弱性を突く攻撃（SQLインジェクションやクロスサイトスクリプティングなど）は、すべてこの「データの中身」に潜んでいます。だからこそ、Webサイトの保護にはWAFが不可欠なのです。
2. WAF、IPS、NGFW… 似た者同士の完全比較
SC試験では、「この攻撃を防ぐにはどの機器が適切か」を選ぶ問題が出ます。FWとWAFだけでなく、IPS（侵入防御システム）やNGFW（次世代ファイアウォール）との違いも整理しておきましょう。
| 機器・技術 | 主な監視レイヤー | 得意な防御対象 | 苦手な防御対象 | 特徴 |
|---|---|---|---|---|
| FW (Firewall) | L3/L4 | ポートスキャン、非許可IPからのアクセス | アプリケーション攻撃全般 | ネットワークの関所。最低限必須。 |
| IDS/IPS | L3~L7 | OS・ミドルウェアの既知の脆弱性（バッファオーバーフロー等）、ワーム | Webアプリ固有の複雑なロジック攻撃、難読化された攻撃 | パケットの特徴パターン（シグネチャ）で検知。Web特化ではない。 |
| WAF | L7 (Web特化) | SQLインジェクション、XSS、ディレクトリトラバーサル | OSレベルの攻撃、プロトコルレベルの攻撃 | HTTP/HTTPSを解釈し、中身を精査する。 |
| NGFW | L3~L7 | アプリケーションの可視化（SNS禁止など）、IPS機能の統合 | WAFレベルの詳細な入力値検査 | FWにアプリ識別機能を追加したもの。WAFの完全な代用にはならないことが多い。 |
特にIPSとWAFの違いに注意
IPSもL7まで見ることができますが、IPSはあくまで「OSやミドルウェア（ApacheやIISなど）の脆弱性」を突く攻撃パターンの検知が得意です。一方、WAFは「Webアプリケーションそのもの（皆さんが書いたPHPやJavaのコード）」の脆弱性を守ることに特化しています。
例えば、「ショッピングサイトの買い物かごの数量をマイナスにして合計金額を減らす」といった論理的な不正操作や、複雑にエンコード（難読化）されたSQLインジェクションなどは、HTTPの文脈を理解できるWAFでなければ防げないケースが多いのです。
IPSは主にネットワークやOSレベルの攻撃を広く監視するのに対し、WAFはWebアプリケーションという特定の層に特化した防御を行います。この役割分担を理解することが、適切なセキュリティ対策の設計には不可欠です。
3. WAFの検知メカニズムと防御できる攻撃
WAFが具体的にどのように攻撃を見つけ出しているのか、そのロジックを深掘りします。ここは記述試験で「検知の仕組み」を問われた際の解答の引き出しになります。
3つの主要な検知方式
1. シグネチャマッチング（パターンマッチング）
最も基本となる方式です。「攻撃の特徴的な文字列パターン」を登録したデータベース（シグネチャ）と通信内容を照合します。
ブラックリスト方式
「既知の攻撃パターン」を定義し、それに一致したら拒否します。例えば、<script>、UNION SELECT、/etc/passwdといった文字列が含まれていたらブロックします。
メリットは設定が比較的容易なこと。デメリットは未知の攻撃（ゼロデイ攻撃）は防げないことです。
ホワイトリスト方式
「許可する正常なパターン」のみを定義し、それ以外をすべて拒否します。例えば、「郵便番号欄は数字7桁のみ許可」「ID欄は英数字のみ8文字以内」と定義します。
メリットは未知の攻撃でも定義外なら防げるため、非常に堅牢なこと。デメリットはWebアプリの仕様変更のたびに設定変更が必要で、運用負荷が極めて高いことです。
2. アノマリ検知（振る舞い検知）
プロトコルの仕様違反や、通常とは異なる統計的な異常を検知します。
プロトコル違反の検知
HTTPのRFC仕様に準拠していないリクエスト（極端に長いヘッダ、不正な文字コードなど）を弾きます。
流量制限
短時間に大量のリクエスト（DoS攻撃的な挙動）があった場合に遮断します。これにより、特定のIPアドレスからの過剰なアクセスを防ぐことができます。
3. レピュテーション（評判）ベース
IPアドレスやドメインの「評判」情報を利用します。過去に攻撃元として観測されたIPアドレスや、匿名プロキシ、Torの出口ノードなどからのアクセスを自動的にブロックします。
この方式により、既知の攻撃元からのアクセスを事前に防ぐことができ、セキュリティレベルを大幅に向上させることが可能です。
WAFが鉄壁の守りを見せる攻撃例
SQLインジェクション
攻撃者は入力フォームに ' OR '1'='1 などのSQL文を注入し、データベースを不正操作しようとします。WAFは、SQLキーワード（SELECT、UNION、DROP）や記号（'、--）の組み合わせを検知し、DBサーバーにリクエストが届く前に遮断します。
この攻撃が成功すると、データベース内の全情報が漏洩したり、データが改ざん・削除されたりする可能性があります。WAFはこのような深刻な被害を未然に防ぐ重要な役割を果たします。
クロスサイトスクリプティング（XSS）
掲示板などに悪意あるスクリプト <script>alert(document.cookie)</script> を書き込もうとする行為です。WAFはHTMLタグやJavaScriptのイベントハンドラ（onmouseover等）を検出し、無害化（サニタイジング）するか、リクエスト自体を破棄します。
XSS攻撃が成功すると、ユーザーのセッション情報やクッキーが盗まれ、なりすましログインなどの被害につながります。
ディレクトリトラバーサル
../../../../etc/passwd のように、相対パスを使って公開ディレクトリ外のファイルにアクセスしようとする攻撃です。WAFは ../ というパターンの連続や、システムファイルへのパスを監視しています。
この攻撃により、本来アクセスできないはずの設定ファイルやパスワードファイルが閲覧されるリスクがあります。
OSコマンドインジェクション
|（パイプ）や ;（セミコロン）を使って、サーバーOSのコマンドを実行させようとする攻撃です。WAFはコマンド実行に関連する特殊文字やコマンド名（cat、ls、cmd.exe）を検知します。
成功すると、サーバー内のファイル操作やシステム情報の取得、さらには完全なサーバー乗っ取りにつながる可能性がある非常に危険な攻撃です。
4. ネットワーク構成図で見るWAFの配置（午後試験対策）
午後試験では、ネットワーク構成図を見て「WAFをどこに配置すべきか」「この構成での課題は何か」を答える問題が出ます。代表的な導入形態（デプロイメントモデル）を理解しましょう。
1. ゲートウェイ型（リバースプロキシ型）
Webサーバーの前段に、専用のハードウェアまたは仮想アプライアンスとして設置する、最も伝統的な構成です。
仕組み
クライアントからの通信をWAFが代理で受け取り（リバースプロキシ）、検査後に安全な通信だけをWebサーバーへ転送します。外部からはWAFのIPアドレスしか見えないため、Webサーバーの存在を隠蔽する効果もあります。
メリット
詳細な設定が可能です。Webサーバー側の負荷を軽減できます（SSLオフロード機能など）。企業の内部ネットワークに設置するため、通信内容を完全にコントロールできます。
デメリット
導入コストが高いです。WAFが故障するとWebサイト全体が止まる（単一障害点となる）ため、冗長化が必須です。機器の保守やシグネチャ更新などの運用管理が必要です。
ネットワーク設定
DNSのAレコードをWAFのVIP（仮想IP）に向ける必要があります。これにより、すべての外部アクセスが必ずWAFを経由するようになります。
2. ホスト型（ソフトウェア型）
WebサーバーそのものにWAFソフトをインストールする方式です（例：Apacheのモジュール mod_security など）。
メリット
ネットワーク構成の変更が不要です。サーバー台数が少なければ安価に導入できます。外部機器を追加しないため、物理的なスペースも不要です。
デメリット
Webサーバーのリソース（CPU/メモリ）を消費するため、性能影響が出やすいです。OSやミドルウェアのバージョン依存があり、アップデート時に互換性問題が発生する可能性があります。複数台のWebサーバーがある場合、すべてに個別にインストール・設定が必要で管理が煩雑です。
3. クラウド型（SaaS型 WAF）
近年、最も主流になりつつある形態です（例：AWS WAF、Akamai、Cloudflareなど）。DNS設定を変更し、トラフィックをクラウド事業者のセンターを経由させます。
メリット
機器購入不要で初期費用が安いです。導入が早く、数時間から数日で稼働開始できます。DDoS対策やCDN機能を兼ね備えていることが多く、サイトの高速化にも寄与します。シグネチャの更新をベンダーに任せられるため、運用負荷が低いです。
デメリット
従量課金でランニングコストが増える場合があります。ログの保存期間や設定の柔軟性に制限がある場合があります。クラウド事業者への依存度が高まり、障害時に自社での対応が困難です。
【重要】クラウドWAF利用時の「バイパス（迂回）攻撃」対策
SC試験で頻出の論点です。クラウドWAFを導入しても、攻撃者が「Webサーバー（オリジン）のグローバルIPアドレス」を直接指定してアクセスしてきた場合、WAFを経由しないため防御できません。
これを防ぐにはどうすればよいでしょうか？
解答例
Webサーバー側のFW設定で、受信許可する送信元IPアドレスを「クラウドWAFのIPアドレス範囲」のみに限定します。これにより、WAFを経由しないアクセスはすべてファイアウォールでブロックされます。
この設定記述は、午後試験の鉄板解答パターンのため、必ず暗記しておきましょう。具体的には、Webサーバーのiptablesやセキュリティグループの設定で、クラウドWAFベンダーが公開しているIPアドレスリストのみを許可リストに登録します。
5. SSL/TLS暗号化とWAFの「見えない壁」問題
現代のWebサイトは、ほぼ全てHTTPS（SSL/TLS）で暗号化されています。通信経路が暗号化されているということは、途中にあるWAFもパケットの中身（攻撃コード）を読めないということを意味します。中身が見えなければ、WAFはただの土管です。
解決策：SSLオフロード（SSL終端）
WAFが本来の役割を果たすためには、暗号化されたデータを一度「復号」する必要があります。
WAFで復号する
WAFにWebサーバーの「秘密鍵」と「サーバー証明書」をインストールします。クライアントとのSSL通信はWAFで終端（復号）し、検査を行います。WAFから背後のWebサーバーへは、平文（HTTP）で送るか、再度暗号化（Re-encryption）して送ります。
試験でのポイント
「WAFで検査を行うために必要な設定は何か？」という問いには、「WAFに秘密鍵と証明書をインポートする」と答えます。
「WAFからWebサーバーへの通信をHTTPにするリスクは？」という問いには、「内部ネットワーク（LAN）内での盗聴リスクを考慮する必要がある」と答えます。
内部ネットワークが完全に信頼できる環境であれば平文での通信も許容されますが、セグメント分離が不十分な場合や、内部にも攻撃者が侵入している可能性を考慮すると、WAF-Webサーバー間も暗号化することが望ましいです。
証明書管理の注意点
WAFにサーバー証明書をインストールするということは、秘密鍵という極めて重要な情報をWAF上で管理することを意味します。秘密鍵が漏洩すると、なりすましサイトの構築や通信の復号化が可能になるため、アクセス制御や監査ログの管理を厳格に行う必要があります。
また、証明書の有効期限管理も重要です。証明書が期限切れになると、ユーザーにセキュリティ警告が表示され、サービスの信頼性が損なわれます。自動更新の仕組みを導入するか、期限管理の運用フローを確立しておくべきです。
6. 実務の泥沼：「誤検知（False Positive）」との戦い
WAFを導入してスイッチをONにすれば、翌日から安全になる…わけではありません。セキュリティエンジニアを最も苦しめるのが「誤検知（False Positive）」です。
誤検知とは？
正常なユーザーの通信を、WAFが「攻撃だ」と勘違いしてブロックしてしまう現象です。
例1：旅行ブログでの投稿エラー
旅行ブログの記事投稿で「1 or 2 days trip」と入力したら、SQLインジェクションの OR 句と判定されて投稿エラーになりました。
例2：住所入力でのエラー
住所入力で「千代田区1-1」と入れたら、コマンド実行のハイフンと判定されました。
ECサイトでこれが発生すると、ユーザーは買い物ができず、売上機会の損失（カゴ落ち）に直結します。「セキュリティを高めた結果、店が閉まってしまった」のでは本末転倒です。
誤検知が発生する理由
WAFのシグネチャは、攻撃パターンを広くカバーするために、ある程度「曖昧な」マッチングを行います。例えば、ORという単語が含まれているだけで反応してしまうようなルールでは、日常的な英文でも誤検知が発生します。
また、Webアプリケーションの仕様は千差万別です。あるサイトでは正常な入力パターンが、別のサイトでは攻撃とみなされるケースもあります。そのため、WAFの設定は個別のWebアプリケーションに合わせてチューニングする必要があります。
導入プロセスの正解（試験記述用）
誤検知を防ぐため、WAFは以下のステップで慎重に導入します。
ステップ1：モニタリングモード（検知モード）で運用開始
最初は通信を遮断せず、「ログ出力のみ」行います。ユーザーへの影響はありません。この期間中、実際のトラフィックに対してWAFがどのように反応するかを観察します。
ステップ2：ログ分析とチューニング
ログを確認し、正常な通信なのに攻撃と判定されているものを探します。それらを「除外設定（ホワイトリストへの登録）」に追加します。通常、数週間から1ヶ月程度のログ分析期間が必要です。
ステップ3：段階的なブロッキングモードへの移行
誤検知が十分に減ったことを確認してから、実際に防御機能を有効化します。最初は重要度の低いページやAPIから適用し、問題がなければ徐々に全体に展開していきます。
ステップ4：継続的な運用とメンテナンス
Webアプリの改修や新商品の追加などで新しい通信パターンが発生すると、また誤検知が起きる可能性があります。WAFの運用は「導入して終わり」ではなく、永続的なチューニング作業なのです。
定期的なログレビューや、アプリケーション変更時のWAF設定見直しを運用フローに組み込むことが重要です。
誤検知と検知漏れのバランス
セキュリティ対策には常にトレードオフがあります。誤検知を減らそうとしてルールを緩めすぎると、本物の攻撃を見逃す「検知漏れ（False Negative）」が増加します。逆に、検知漏れを恐れてルールを厳しくしすぎると、誤検知が多発してユーザビリティが損なわれます。
この両者のバランスをどこに設定するかは、サイトの性質（ECサイトか社内システムか）、扱うデータの機密性、ユーザー層などによって異なります。リスク評価を行った上で、組織として許容できるレベルを決定する必要があります。
7. 情報処理安全確保支援士試験（SC）対策：合格へのキラーフレーズ
最後に、WAFに関する問題が出題された際に、加点をもらうためのポイントをまとめます。
午前II問題のポイント
WAFの防御対象
SQLインジェクション、XSSなどがメインです。ワームやウイルスそのものの検知はアンチウイルスやIDSの役割です。
検知場所
アプリケーション層（L7）で動作します。
ブラックリストとホワイトリスト
ホワイトリストの方が安全ですが運用が困難です。ブラックリストは運用しやすいですが未知の攻撃に弱いです。
FWとの違い
FWはL3/L4で動作し、IPアドレスやポート番号を見ます。WAFはL7で動作し、HTTPの中身を詳細に検査します。
午後記述問題のポイント（記述例）
WAF導入の際に考慮すべき、SSL通信に関する設定は？
暗号化された通信内容を検査するため、WAFにWebサーバの秘密鍵を登録し、SSL通信を復号できるようにする。（63文字）
クラウドWAFを導入したが、攻撃を防げないケースがある。どのような場合か？
攻撃者がDNSを経由せず、WebサーバのIPアドレスを直接指定してアクセスしてきた場合。（43文字）
上記の対策は？
WebサーバのFWで、クラウドWAFからの通信のみを許可し、それ以外のインターネットからの通信を遮断する。（51文字）
WAFを導入直後に遮断モードにするとどのような問題が起きるか？
正常な通信を攻撃と誤認する誤検知が発生し、Webサイトのサービス利用に支障が出る可能性がある。（46文字）
WAFでSSL通信を復号した後、Webサーバへ平文で転送する場合のリスクは？
内部ネットワークで通信が盗聴され、機密情報が漏洩するリスクがある。（35文字）
SQLインジェクション対策として、WAF以外に開発時に実施すべき対策は？
プレースホルダを使用したパラメータ化クエリを実装し、入力値をSQL文として解釈させない。（47文字）
これらの記述例は、実際の試験で高得点を狙うための模範解答です。文字数も適切で、採点者が求めるキーワードを含んでいます。
【演習】WAFとファイアウォールの違い 理解度チェックテスト（全10問）
本記事で解説したWAFとファイアウォールの違い、導入形態、運用のポイントについて、正しく理解できていますか？ 「なんとなくわかったつもり」になっていないか、実践形式のクイズで確認してみましょう。
この演習問題では、SC試験の午前・午後問題で頻出の論点を厳選しています。選択肢をクリックすると、その場で正解と詳細な解説が表示されます。間違えた問題は解説を読み込み、知識を確実に定着させてください。
8. まとめ：WAFは「銀の弾丸」ではないが「必須の盾」
今回の解説で、WAFの役割と仕組み、そしてFWとの違いが明確になったはずです。
重要ポイントの再確認
- FWは「住所」を見て門を開ける（L3/L4）
- WAFは「中身」を見て危険物を探す（L7）
- WAFはSQLインジェクションやXSSなど、Webアプリ特有の攻撃に強い
- 導入時はSSL復号と、誤検知対策のチューニングが必須
- 運用時は継続的なログ監視とルール調整が不可欠
「WAFを入れたから完璧」ではありません。WAFはあくまで、脆弱性修正が完了するまでの「保険」や、修正困難なレガシーシステムを守る「盾」としての役割が強いツールです。根本的な対策は、「脆弱性のないセキュアなコードを書くこと（セキュアプログラミング）」に他なりません。
しかし、人間がコードを書く以上、脆弱性をゼロにすることは不可能です。だからこそ、多層防御（Defense in Depth）の一環として、WAFの重要性は今後も増し続けるでしょう。
多層防御の考え方
セキュリティ対策は単一の技術に依存すべきではありません。FW、IPS、WAF、アンチウイルス、ログ監視、アクセス制御など、複数の防御層を組み合わせることで、一つの対策が突破されても他の層で攻撃を食い止めることができます。
WAFは、この多層防御の中でも特にWebアプリケーション層を守る重要な位置を占めています。しかし、WAFだけに頼るのではなく、開発段階でのセキュアコーディング、定期的な脆弱性診断、迅速なパッチ適用など、総合的なセキュリティ戦略が必要です。
実務での活用シーン
WAFは以下のような場面で特に有効です。
- レガシーシステムで、ソースコード修正が困難な場合の暫定対策
- 新たに発見された脆弱性に対する緊急的な防御措置（仮想パッチ）
- 外部委託先が開発したシステムで、内部構造の把握が困難な場合
- EC サイトなど、常に攻撃対象となるWebサービスの恒久的な防御層
これらの場面では、WAFは極めて有効な防御手段となります。ただし、WAFがあるからといって脆弱性の修正を怠ってはいけません。WAFはあくまで「時間稼ぎ」のためのツールであり、根本的な脆弱性の修正は必ず実施すべきです。
Next Action for You
過去問チェック
情報処理安全確保支援士試験 平成29年度秋期 午後1 問2 を見てみてください。クラウド型WAFの導入と運用に関する良問です。本記事の内容がそのまま解答につながることを実感できるはずです。
実機確認
もしAWSのアカウントを持っていれば、AWS WAFの管理画面を覗いてみてください。「SQL injection match conditions」などの設定項目を見るだけで、具体的なイメージが掴めます。無料枠や低コストで試せるので、実際に触ってみるのが一番の学習です。
学習リソース
IPAが公開している「安全なWebサイトの作り方」や、OWASP Top 10（Webアプリケーションの脆弱性トップ10）も合わせて学習することで、WAFが防御する攻撃の全体像がより深く理解できます。
実践的な演習
可能であれば、脆弱性が意図的に作り込まれた学習用Webアプリケーション（DVWA: Damn Vulnerable Web Applicationなど）を使って、実際に攻撃を試し、WAFがどのように防御するかを体験してみてください。座学だけでは得られない実践的な知識が身につきます。
SC試験合格に向けて、WAFの理解は避けて通れない重要テーマです。本記事で学んだ内容を基に、過去問演習や実機操作を通じて、確実に知識を定着させてください。