WAFとは？Webアプリケーションファイアウォールの仕組み・選び方・導入手順をわかりやすく解説

Webサービスへの攻撃は年々巧妙になっています。IPAの調査によると、2023年に報告されたWebアプリケーションへの攻撃のうち、SQLインジェクションやXSSといったアプリケーション層の攻撃が全体の約60%を占めているとされています。通常のファイアウォールや侵入検知システムだけでは、これらのアプリケーション層の攻撃を遮断するのは難しいのが現実です。

「WAFという言葉は聞いたことがあるけれど、何がどう違うのかよくわからない」「自社に必要なのかどうか判断できない」という情シス担当者の方も少なくないでしょう。

この記事では、WAF（Webアプリケーションファイアウォール）の仕組みから種類・選び方・導入手順まで、現場で使えるレベルで丁寧に解説します。クラウド型とオンプレ型の違い、無料・低コストの選択肢なども取り上げていますので、予算が限られた中小企業の情シスの方にも参考にしていただける内容です。

WAFとは？Webアプリケーションファイアウォールの基本

WAF（Web Application Firewall）は、Webアプリケーションへの通信を監視・フィルタリングし、アプリケーション層の攻撃を検出・ブロックするセキュリティ装置（またはソフトウェア・クラウドサービス）です。

通常のファイアウォールとの違い

通常のファイアウォールは、送信元・宛先IPアドレスやポート番号といった「ネットワーク層」の情報をもとに通信を制御します。一方、WAFはHTTPリクエストの中身——URLパラメータ、リクエストボディ、ヘッダー情報など——を解析し、アプリケーションレベルの不審なパターンを検出します。

簡単に言うと、通常のファイアウォールは「誰が来ているか」を見るのに対し、WAFは「何を持ってきているか」を見るイメージです。

なぜWAFが必要なのか

現代のWebアプリケーションは複雑で、開発段階でセキュリティの脆弱性をゼロにすることは現実的ではありません。特に中小企業では、脆弱性診断や都度の修正に割ける工数が限られています。WAFを導入することで、既知の攻撃パターンを「仮想パッチ（Virtual Patching）」として塞ぎ、根本修正の時間的猶予を確保できます。

2023年のIPA「情報セキュリティ10大脅威」でも、Webアプリケーションの脆弱性を突いた攻撃は上位に挙げられており、Webサービスを公開している企業にとって対策は避けられないテーマになっています。

WAFが防ぐ攻撃の種類

1. SQLインジェクション

データベースへのクエリに悪意のあるSQL文を混入させる攻撃です。たとえばログインフォームに ' OR '1'='1 のような文字列を入力し、認証を回避したり、データベースの内容を丸ごと抜き取ったりします。個人情報漏洩インシデントの主要な原因のひとつで、WAFはこうした特徴的なSQL構文をリクエスト内で検出してブロックします。

2. クロスサイトスクリプティング（XSS）

Webページに不正なJavaScriptを埋め込み、閲覧したユーザーのブラウザ上でスクリプトを実行させる攻撃です。セッションクッキーの窃取や、フィッシングページへの誘導などに悪用されます。WAFは <script> タグや javascript: プロトコルなどの典型的なパターンを検知します。

3. DDoS攻撃の緩和

大量のリクエストを送りつけてサーバーを過負荷状態にする攻撃です。WAFはリクエストレートの異常検知や、特定IPからの大量アクセスの一時ブロックによって、アプリケーション層でのDoS/DDoS被害を軽減します。ただし、大規模なネットワーク帯域を消費するDDoSには、CDN連携が必要なケースも多いです。

4. ゼロデイ攻撃への対応

まだ公式パッチが存在しない脆弱性を突く「ゼロデイ攻撃」に対して、WAFのふるまい検知や機械学習ベースの異常検知が有効に機能することがあります。シグネチャが更新されるまでの間、既知の攻撃パターンに似た動きを持つ未知の攻撃も検出できるケースがあります。

WAFの仕組み：リクエストをどう判定するか

WAFがどうやって「正常なリクエスト」と「攻撃らしいリクエスト」を区別するか、その判定ロジックを理解しておくと、導入後のチューニングにも役立ちます。

シグネチャベース vs 機械学習ベース

・シグネチャベース: 既知の攻撃パターン（シグネチャ）のデータベースと照合する方式。精度が高くFalse Positiveが少ないが、未知の攻撃には対応できない。
・機械学習ベース: 通常のアクセスパターンを学習し、統計的に異常なリクエストを検知する方式。新しい攻撃にも対応できるが、学習初期はFalse Positiveが発生しやすい。
・ハイブリッド方式: 多くの商用WAFはシグネチャ＋機械学習を組み合わせ、精度と柔軟性を両立している。

動作モード（検出モード vs ブロックモード）

WAFには大きく2つの動作モードがあります。

・検出モード（Detect / Monitor Mode）: 攻撃と判定されるリクエストを記録するが、通信はブロックせずに通す。導入初期のチューニング期間に使う。
・ブロックモード（Block / Prevention Mode）: 攻撃と判定されるリクエストを実際に遮断する。本番環境での保護を目的とした通常運用時のモード。

いきなりブロックモードで動かすと、正常なアクセスまでブロックしてしまう「誤検知（False Positive）」が起きる可能性があります。まず検出モードで様子を見てから、段階的にブロックモードへ移行するのが現場での定石です。

コードブロック：nginx + ModSecurityのルール例

オープンソースのWAFエンジン「ModSecurity」をnginxと組み合わせた設定例です。

# nginx.conf に ModSecurity モジュールを読み込む
load_module modules/ngx_http_modsecurity_module.so;

# 仮想ホスト設定（/etc/nginx/sites-available/default）
server {
    listen 80;
    server_name example.com;

    # ModSecurity を有効化（検出モード: Off=無効, On=ブロック, DetectionOnly=検出のみ）
    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsecurity/modsecurity.conf;

    # OWASP CRS（Core Rule Set）のメインルールを読み込む
    # /etc/modsecurity.d/owasp-crs/crs-setup.conf
    # /etc/modsecurity.d/owasp-crs/rules/*.conf
}

# modsecurity.conf の主要設定
SecRuleEngine DetectionOnly     # まず検出モードで稼働（本番移行後は On に変更）
SecRequestBodyAccess On         # リクエストボディも検査対象に含める
SecAuditLog /var/log/modsec_audit.log  # 検出ログの出力先
SecAuditLogParts ABIJDEFHZ      # ログに含める情報の種類

WAFの種類と比較

WAFには大きく3つの提供形態があり、それぞれメリット・デメリットが異なります。自社の規模・予算・運用体制に合わせて選択することが重要です。

中小企業向けWAF選び方ガイド

「WAFが必要なのはわかったけれど、どれを選べばいいか判断できない」という方のために、選定の基準をまとめました。

WAF選定チェックリスト

・Webサービスの公開規模: 月間PV・ユーザー数・扱う情報の機密度を確認する。個人情報・決済情報を扱うなら特に優先度を上げる。
・既存インフラとの相性: AWS上で動いているならAWS WAFが連携しやすい。オンプレのWebサーバーならModSecurityが低コスト。
・運用できる人員: 専任のセキュリティ担当がいない場合は、シグネチャ自動更新のクラウド型を優先する。
・予算感: まず無料枠（Cloudflareの無料プラン等）で試し、効果を確認してから有料プランへ移行するアプローチも現実的。
・False Positiveへの許容度: ECサイトなど正常なトラフィックが多様な場合は、誤検知に強い製品または手動チューニングの工数を確保できるかを確認する。
・コンプライアンス要件: PCI DSSの対象事業者はWAF導入が要件に含まれるため、認定済みの製品・サービスを選ぶ必要がある。

無料・低コストの選択肢

・Cloudflare 無料プラン: DNSをCloudflare経由にするだけで基本的なWAFルールが適用される。中小企業の入門として最も手軽。
・ModSecurity + OWASP CRS: オープンソースのWAFエンジン。Apache/nginxに組み込み可能。無料だがチューニングに知識が必要。
・AWS WAF: AWSのロードバランサー（ALB）やCloudFrontと組み合わせて使う。リクエスト数ベースの従量課金で月数千円〜から利用可能。

WAF導入の手順

WAFを「入れるだけ」にしてはいけません。正しい手順で導入・運用しないと、正常なアクセスをブロックしたり、逆に攻撃を見落としたりするリスクがあります。

1. 要件定義

まず以下の点を整理します。

・保護対象のWebアプリケーションの洗い出し: どのURLが公開されているか、外部からどんな入力が可能かを把握する。
・扱うデータの種類と機密度: 個人情報・決済情報を含む場合は要件が厳しくなる。
・既存のセキュリティ対策との棲み分け: IDS/IPSや通常のファイアウォールとの役割分担を明確にする。
・導入形態の選定: クラウド型・アプライアンス型・ソフトウェア型のどれが自社に合うか判断する。

2. 試験運用（検出モード）

いきなりブロックモードで動かすのは危険です。最初は必ず検出モード（Detection Only）で運用を開始します。

・期間の目安: 最低2〜4週間、可能なら1〜2ヶ月。
・ログの確認: WAFが「攻撃」と判定しているリクエストを毎日確認し、正常なアクセスが含まれていないかチェックする。
・トラフィックパターンの把握: 自社の正常なアクセスパターンを記録し、チューニングの基準にする。

3. チューニング

検出モードで収集したログをもとに、ルールを調整します。

・False Positiveの排除: 正常なアクセスがブロックされるルールは例外設定（ホワイトリスト）を追加する。
・False Negativeの補完: 攻撃が素通りしているパターンがあれば、カスタムルールを追加する。
・アプリケーション固有のルール: 特定のURLパラメータに特殊文字を使うフォームがある場合は、そのパスのみルールを緩和する。

チューニングには専門知識が必要で、ここが中小企業にとって最も難しいポイントです。初期設定はベンダーのサポートや専門家に依頼することも検討しましょう。

4. 本番適用

チューニングが完了したら、ブロックモードへ切り替えます。

# ModSecurity: 検出モード → ブロックモードへの切り替え
# /etc/nginx/modsecurity/modsecurity.conf を編集

# 変更前（検出のみ）
SecRuleEngine DetectionOnly

# 変更後（ブロック有効）
SecRuleEngine On

# nginx を再起動して設定を反映
sudo systemctl reload nginx

# ブロックモード移行後、最初の24時間はログを重点監視
tail -f /var/log/modsec_audit.log | grep "id" | grep "Anomaly Score"

ブロックモードへの移行後も、ログの定期確認は継続します。特に、アプリケーションをアップデートした際はWAFのルールとの相性を再確認することが重要です。

よくある誤解とFAQ

Q. WAFを入れれば完全に安全になりますか？

A. WAFは重要な防御層のひとつですが、WAFだけでセキュリティが完結するわけではありません。アプリケーション内部のロジック上の脆弱性（認証バイパスや権限昇格など）はWAFでは防げないケースがあります。定期的な脆弱性診断・コードレビュー・適切なアクセス制御との組み合わせが必要です。

Q. WAFとIPSはどう違うのですか？

A. IPS（侵入防止システム）はネットワーク層（L3〜L4）の不審な通信パターンを検知してブロックするのに対し、WAFはHTTPというアプリケーション層（L7）のプロトコルを深く解析します。Webアプリケーション特有の攻撃にはWAFが有効で、両者は相補的な関係にあります。

Q. クラウド型WAFに通信を通すと、機密情報が外部に漏れませんか？

A. クラウド型WAFはHTTPS通信を一旦復号して検査するため、理論的にはプロバイダに内容が見える状態になります。金融機関・医療・官公庁など高い機密性が求められる環境では、オンプレミス型のWAFを選ぶか、データの取り扱いポリシーと契約内容を十分に確認した上で導入判断をする必要があります。

Q. WAFのシグネチャはどのくらいの頻度で更新すればよいですか？

A. クラウド型WAFはプロバイダが自動更新してくれるため、ユーザー側での作業は基本不要です。ソフトウェア型（ModSecurity等）を自己管理している場合は、OWASP CRSのリリースに合わせて定期的にアップデートすることを推奨します。新たな脆弱性が公表された際には、緊急アップデートが提供されることもあるため、ベンダーの通知を購読しておくと安心です。

Q. WAFは中小企業でも本当に必要ですか？

A. 「うちは小さい会社だから狙われない」という考え方は危険です。近年の攻撃の多くは標的型ではなく、自動化ツールでインターネット全体をスキャンして脆弱性のあるサイトを無差別に狙います。ECサイト・予約フォーム・会員サービスなど、外部からの入力を受け付けるWebアプリケーションがある企業は、規模を問わずWAFの導入を検討する価値があります。Cloudflareの無料プランなど、低コストから始められる選択肢もあります。

本記事のまとめ

WAF（Webアプリケーションファイアウォール）について、基本から実践まで解説しました。

・WAFとは: HTTPリクエストの内容を解析し、SQLインジェクション・XSS・DDoSなどアプリケーション層の攻撃を防ぐセキュリティ機能。
・3つの形態: クラウド型（手軽・低コスト）・アプライアンス型（高性能・高コスト）・ソフトウェア型（無料・要チューニング）から自社に合うものを選ぶ。
・導入ステップ: 要件定義 → 検出モードで試験運用 → ログを見てチューニング → ブロックモードへ移行、という段階的な進め方が安全。
・WAFは万能ではない: 定期的な脆弱性診断・適切な認証設計と組み合わせて、多層防御を構築することが重要。

「まずどこから始めればいいかわからない」という方は、Cloudflareの無料プランを試してみるところから始めるのが現実的です。徐々に理解を深めながら、自社のWebサービスに合った保護体制を整えていきましょう。

Linuxサーバー側のファイアウォール設定については、姉妹サイトLinuxMaster.JPで詳しく解説しています。サーバー全体のセキュリティ強化を考えている方はあわせてご覧ください。