WAFとは?Webサイトを守る仕組みと導入の判断基準

読了時間: 約10分

WAFとは?Webサイトを守る仕組みと導入の判断基準

WAF(Web Application Firewall/ワフ)とは、Webサイトと閲覧者のあいだでやり取りされる通信の中身を検査し、SQLインジェクションなどの攻撃とみなした通信を遮断する仕組みです。ただし、WAFは脆弱性そのものを直す対策ではなく、攻撃による影響を小さくする「保険的な対策」です。

導入すべきかどうかは、「サイトの脆弱性をすぐに直せない事情があるか」「サイトで個人情報や決済を扱っているか」「WAFを運用する体制を用意できるか」の3点で判断するのが現実的です。この記事では、IPA(情報処理推進機構)が公開している「Web Application Firewall 読本」と補足資料をもとに、WAFの仕組み、種類ごとの違い、防げる攻撃・防げない攻撃、導入の判断基準を順に解説します。

WAFとは?Webアプリケーションを攻撃から守る仕組み

WAFは、Webアプリケーションの脆弱性を悪用した攻撃から、Webアプリケーションを保護するソフトウェアまたはハードウェアです。IPAの「Web Application Firewall 読本」では、WAFは脆弱性を修正する根本的な対策ではなく、攻撃による影響を低減する対策と位置づけられています。

ここでいう「Webアプリケーション」とは、お問い合わせフォーム、会員ログイン、商品検索、WordPressなどのCMSのように、閲覧者の入力を受け取って処理する仕組みのことです。こうした部分にプログラム上の欠陥(脆弱性)があると、外部から不正な命令を送り込まれ、情報漏えいや改ざんにつながるおそれがあります。

WAF読本では、WAFに期待できる効果として次の3つを挙げています。

  • 脆弱性を悪用した攻撃からWebアプリケーションを防御する
  • 脆弱性を悪用した攻撃を検出する
  • 複数のWebアプリケーションへの攻撃をまとめて防御する
WAFが閲覧者とWebサイトの間で通信を検査し攻撃を遮断する仕組みの図

信を検査し攻撃を遮断する仕組みの図]

ファイアウォール(FW)・IPSとの違い

WAFは名前に「ファイアウォール」と付いていますが、一般的なファイアウォール(FW)とは守る対象が異なります。FWは送信元・送信先のIPアドレスやポート番号をもとにアクセスを制限する仕組みです。しかし、企業のWebサイトは誰でも閲覧できるように公開しているため、FWではWebアプリケーションへの攻撃を止められません。

IPS(侵入防止システム)は、OSやファイル共有サービスなどさまざまな機器への攻撃を検査します。WAFはWebアプリケーションへの通信に特化しており、攻撃パターンを定義した「ブラックリスト」に加えて、正常な通信を定義した「ホワイトリスト」による検査もできる点が特徴です。

仕組み主に見ているもの得意なこと苦手なこと
ファイアウォール(FW)IPアドレス・ポート番号公開不要なサービスへのアクセスを遮断する公開しているWebサイトへの攻撃は止められない
IPSさまざまな機器への通信の中身OSやファイル共有サービスなどへの攻撃を防ぐWebアプリケーション固有の通信の細かな検査
WAFWebアプリケーションへの通信(HTTP/HTTPS)の中身SQLインジェクションなどWebアプリケーションへの攻撃を防ぐWeb以外の通信、アプリの仕様上の欠陥

出典:IPA「Web Application Firewall 読本 改訂第2版」2.2節をもとに作成

WAFはどうやって攻撃を見分けているのか

WAFは、あらかじめ設定された「検出パターン(シグネチャ)」と通信の中身を機械的に照らし合わせ、攻撃とみなした通信を遮断したり記録したりします。人が目で判断するわけではないため、判定が実態とずれることがあります。

このずれには2種類あります。正常な通信を攻撃と判定してしまう「偽陽性(誤検知)」と、攻撃を見逃してしまう「偽陰性(検知漏れ)」です。WAF読本では、ベンダーが提供するブラックリストの検出パターンをすべて有効にすると誤検知が起こる可能性があること、自由入力の多いフォームでは正常な入力を定義しにくくホワイトリストで攻撃を検知できない場合があることが説明されています。

中小企業のサイトで実際に起こりやすいのは、誤検知によってお問い合わせフォームの送信や管理画面での記事保存が止まるケースです。WAFを有効にしたあとに「フォームが送れない」「更新ボタンを押すとエラーになる」といった症状が出た場合は、WAFのログを確認する必要があります。

WAFの種類:クラウド型・ホスト型・アプライアンス型の違い

WAFは提供形態によって、クラウド型・ホスト型・アプライアンス型の3種類に大別されます。IPAの補足資料「Web Application Firewall(WAF)の導入に向けた検討項目」(2019年3月)では、それぞれ「サービス型(クラウドサービス型)」「ソフトウェア型」「アプライアンス型」と呼んでいます。本記事のホスト型は、IPA資料のソフトウェア型(Webサーバーにインストールするタイプ)を指します。

種類仕組み主なメリット主なデメリット
クラウド型(サービス型)外部のWAF事業者のサーバーを経由させて通信を検査する導入までの期間が短い。シグネチャ更新などの保守を自社で行う必要がない。一般的に初期費用が安価調整できる範囲が事業者のサービス内容に左右される。事業者側の障害の影響を受けることがある。通信量や対象URLが多いと割高になる場合がある
ホスト型(ソフトウェア型)自社のWebサーバーにWAFソフトウェアを導入して検査する専用機器が不要。ネットワーク構成の変更が不要。検知条件を自社に合わせて設定できるサーバーの処理性能に影響する可能性がある。アップデートや設定見直し、検知内容の確認を自社で行う必要がある
アプライアンス型専用機器をネットワーク内に設置し、Webサーバーへの通信を通過させて検査するWebサーバーに負荷をかけない。アクセス数に応じて性能を選べる。設定の自由度が高い一般的に調達費用が高い。ネットワーク構成の変更が必要。運用を自社で担う必要がある

出典:IPA「Web Application Firewall(WAF)の導入に向けた検討項目」表1-1・表1-2をもとに作成

クラウド型・ホスト型・アプライアンス型WAFの設置場所の違い

同資料では、導入の負担を比べると「初期費用」「環境整備の手間」「運用開始までの期間」はクラウド型が最も小さく、アプライアンス型が最も大きい傾向があるとしています。一方で「設定の自由度」はホスト型・アプライアンス型のほうが高く、クラウド型は低いと整理されています。いずれも一般的な傾向であり、製品やサービス内容、ネットワーク環境によって異なる点には注意が必要です。

レンタルサーバーの「WAF機能」はどれに当たる?

中小企業のWebサイトでよく使われるレンタルサーバーには、WAFを標準機能として提供している事業者が増えていると、IPAの補足資料(2019年3月)でも触れられています。IPAの「ECサイト構築・運用セキュリティガイドライン」(2023年3月)でも、レンタルサーバーに標準搭載され、オン/オフの簡単な操作で使えるWAFが選択肢の一つとして紹介されています。

ただし同ガイドラインは、検知ルールが事業者側で決められているWAFは自社サイト向けの細かな調整ができないため誤検知が起こりやすいこと、共用サーバーでは自社向けのチューニングができないことも考慮点として挙げています。まずは契約中のサーバーにWAF機能があるか、有効になっているか、ログを見られるかを確認しましょう。サーバー選びや設定全般は「サーバーのセキュリティ対策」で解説しています。

WAFで防げる攻撃・防げない攻撃

WAFが得意なのは、Webアプリケーションの脆弱性を狙ったHTTP/HTTPS通信の攻撃です。逆に、Web以外の経路からの攻撃や、通信の形だけでは正常と区別できない攻撃は防げません。「WAFを入れたから安全」とは言えない理由がここにあります。

WAFで防御が期待できる攻撃

IPAの資料で、WAFによる防御の効果が挙げられている主な攻撃は次のとおりです。

  • SQLインジェクション:入力欄に不正な命令を紛れ込ませ、データベースを不正に操作する攻撃
  • クロスサイト・スクリプティング(XSS):Webページに不正なスクリプトを埋め込み、閲覧者のブラウザで実行させる攻撃
  • 既知の脆弱性を狙った攻撃:攻撃に対応したシグネチャがWAFに提供されている場合
  • ボットネットからのDDoS攻撃等:IPAのECサイト向けガイドラインでWAFの効果として挙げられています(対応範囲は製品・サービスによって異なります)
  • CSRF(クロスサイト・リクエスト・フォージェリ):WAF読本では、リクエストの正当性を確認する機能を持つWAFで防御できる場合があると説明されています

WAFでは防げない(防ぎにくい)攻撃

一方、IPAの資料では次のような攻撃はWAFで防げない、または検知できない場合があると明記されています。

  • Web以外の通信を使った攻撃:一般的なWAFが監視するのはHTTPとHTTPSのみで、SSHによるサーバーへの不正アクセスやFTPを使った不正なファイルアップロードは検知できません
  • Webアプリケーションの仕様上の欠陥を突く攻撃:たとえば、特定の利用者だけに許可すべき機能を他の利用者も使えてしまう「認可制御の不備」は、通信自体が正常に見えるため防げません
  • シグネチャが未提供の新しい攻撃:新しい脆弱性に対応した検出パターンがベンダーから提供されるまでは検知できない場合があります
  • 正規の操作を自動で繰り返す攻撃:クレジットカード番号を総当たりで割り出す「クレジットマスター攻撃」のような攻撃は遮断できないとされています
  • ネットワークやOS、ミドルウェアへの攻撃:Webアプリケーションの脆弱性を悪用しない攻撃は対象外です

同じ理屈で、漏えいしたIDとパスワードを使った正規の手順でのログインも、通信の形だけでは攻撃と見分けにくくなります。管理画面の二段階認証やログイン制限といった対策は、WAFとは別に必要です。詳しくは「不正アクセス対策の基本」をご覧ください。

IPAはWAFを「保険的対策」と位置づけている

IPAの補足資料では、「WAFを導入すれば、すべての攻撃を防御できる」という認識は誤りであると明記されています。そのうえでIPAは、WAFを脆弱性による被害の緩和策と位置づけ、脆弱性が見つかった場合はソフトウェアの修正などの根本的解決と、WAF導入などの保険的対策の両面から検討することを推奨しています。

事例で見るWAFの効果:Apache Struts2の脆弱性(S2-045)

WAFが特に力を発揮するのは、脆弱性が公表されてから修正が終わるまでの「すき間」の時間です。IPAの補足資料では、2017年に報告されたApache Struts2の脆弱性(S2-045)が例として紹介されています。

同資料によると、日本時間の3月6日に脆弱性が報告されてから、攻撃の実証コード(PoC)が確認されるまで12時間程度で、国内で実際に被害が発生したのは3月8日17時ごろとされています。一方、複数のWAFベンダーは3月7日中に攻撃を遮断できるシグネチャをリリースしていたことが確認されています。

ソフトウェアの更新を公開当日中に済ませることは、多くの組織にとって現実的ではありません。IPAは、WAFを導入し適切に運用していれば、このような場面で被害を水際で食い止められる可能性があるとしています。

WAF導入の判断基準:自社に必要かを見極める3つの視点

WAFを入れるべきかどうかは、「WAFが効果を発揮しやすい状況にあるか」「どの種類なら無理なく運用できるか」「費用対効果が見合うか」の順に考えると整理しやすくなります。

視点1:WAFが有効な状況に当てはまるか

WAF読本では、WAFの導入が有効な状況として次の3つを挙げています。

状況中小企業での具体例
(a) 直接管理できないWebアプリケーションをまとめて守りたい複数の制作会社が作ったサイトや、グループ会社のサイトを一括で管理している
(b) 脆弱性の修正が難しい制作会社が廃業・撤退していて改修を頼めない。使っているソフトの修正版が出ていない、またはサポートが終了している
(c) 攻撃をすぐに防ぐ必要があるすでに攻撃を受けており、原因調査と修正が終わるまでサイトを止められない

※中小企業での具体例は、WAF読本の説明をもとに当社が想定したものです。

このほか、IPAの「ECサイト構築・運用セキュリティガイドライン」(2023年3月)では、自社で構築したECサイトについて、脆弱性への対応やセキュリティ対策の実装までに時間がかかる場合の応急処置としてWAFの導入を「推奨」としています。会員情報や決済を扱うサイトは、WAFを積極的に検討すべき対象といえます。

視点2:どの種類なら運用を続けられるか

IPAの補足資料では、WAFの種類を選ぶ観点として次の3つを挙げています。

  1. 運用開始までの期間と導入に必要な費用:被害が出てから急いで導入するなら、期間の短さが優先されます
  2. WAFの設定自由度:独自の機能が多いサイトでは、誤検知を減らすために検知対象を細かく調整できる必要があります
  3. 導入後の運用業務:シグネチャの更新、正常に動いているかの確認、検知ログの確認などを誰が担うかを考えます

同資料の選択例では、「至急導入したい」「社内で設定を検討できない」「ネットワーク構成を変更できない」「検知結果を確認・調査できない」といった項目が多い組織にはサービス型(クラウド型)が適していると整理されています。社内にWebやネットワークの担当者が少ない中小企業では、まずクラウド型か、レンタルサーバーの標準WAFから検討するのが現実的です。

WAFの種類を選ぶための簡易チェック表

視点3:導入費用と運用費用を合わせて見積もる

WAF読本では、WAFの費用を「導入費用」と「運用費用」に分けて考えるよう求めています。導入費用には製品価格や設定・動作検証の人件費、運用費用には保守費用やログ確認・検出パターン更新などの人件費が含まれます。

具体的な金額は、製品・サービスの種類、通信量、対象URLの数、契約内容によって大きく変わるため、本記事では相場を示しません。複数の事業者から、初期費用と月額費用、誤検知が起きたときの対応範囲を含めた見積もりを取って比較してください。IPAは、WAFの費用と効果を、脆弱性の修正(Webアプリケーションの改修)など他の施策と比べて判断するよう示しています。

WAF導入後に必要な運用

WAFは「入れたら終わり」ではありません。IPAの補足資料では、導入後の運用業務として次の5つを挙げています。

  1. 初期設定・動作検証(サイトの閲覧やフォーム送信に支障が出ていないか)
  2. 日常的な正常性確認
  3. 故障時の対応
  4. 設定内容の見直し・修正
  5. 検知ログの確認(誤検知・検知漏れがないか)

クラウド型ではこのうち多くを事業者が担いますが、誤検知でフォームが止まった場合に「誰が気づき、誰に連絡して、どう解除するか」は自社側で決めておく必要があります。また、ベンダーが公開するシグネチャを使い続けるにはWAFのサポートが継続していることが前提です。契約更新やサポート期限も管理対象に含めましょう。

サイトをリニューアルしたり、フォームや会員機能を追加したりしたときも、WAFの設定見直しが必要になることがあります。IPAのECサイト向けガイドラインでも、サイトのリニューアルやカスタマイズの状況に応じて検知ルールを定期的に見直すよう求めています。

WAFを入れるべきか
迷っている方へ

久留米市・福岡市で
Webサイトの保守・セキュリティ点検をお考えの方に
無料相談を実施しています。

  • サーバー・WAF設定の確認
  • 必要な対策の整理
  • 費用目安のご提示

WAFと合わせて行うべき対策

WAFは被害を緩和するための対策であり、根本的な対策と組み合わせて初めて効果を発揮します。IPAの「安全なウェブサイトの運用管理に向けての20ヶ条」でも、WAFなどによる不正通信の検知・遮断は20項目のうちの1つにすぎません。

  • ソフトウェアの更新:CMS、プラグイン、サーバーソフトウェアの脆弱性を修正版で解消する(WordPressの場合は「WordPressのセキュリティ対策」を参照)
  • 脆弱性診断:自社サイトにどんな弱点があるのかを把握し、WAFで守れない欠陥を見つける(「Webサイトの脆弱性診断とは」を参照)
  • 不正ログイン対策:管理画面の二段階認証やアクセス制限を設定する
  • 通信の暗号化:サイト全体をHTTPS化する(「SSL(HTTPS化)とは」を参照)
  • 改ざんの監視とバックアップ:被害に早く気づき、元の状態に戻せるようにする

Webサイトのセキュリティ対策の全体像は「Webサイトのセキュリティ対策とは?中小企業向け完全ガイド」でまとめています。

まとめ:WAFは「すぐ直せない弱点」を守る保険として検討する

  • WAFは、Webサイトへの通信の中身を検査して攻撃を遮断する仕組みで、脆弱性を直す根本対策ではなく、被害を緩和する保険的対策です。
  • 種類はクラウド型・ホスト型・アプライアンス型の3つ。運用体制が限られる中小企業では、クラウド型やレンタルサーバーの標準WAFが現実的な選択肢です。
  • SQLインジェクションやXSSなどの攻撃には効果が期待できますが、Web以外の通信を使った攻撃や仕様上の欠陥を突く攻撃は防げません。
  • 導入は「脆弱性をすぐ直せない事情があるか」「個人情報や決済を扱うか」「運用を続けられるか」で判断し、導入費用と運用費用を合わせて見積もりましょう。

参考資料・出典

※各資料の内容は、本記事執筆時点(【確認日を挿入】)で確認したものです。

【免責を挿入:本記事は一般的な情報提供を目的としたもので、個別のサイト環境での安全性を保証するものではありません。導入・設定の判断は、サイトの構成や契約内容を確認のうえ、専門家にご相談ください。】

WAFやサーバー設定に不安がある方は、まず現状確認から


「WAFが有効になっているかわからない」「フォームが止まってWAFを切ったままになっている」といったお悩みはありませんか。アイエムワークスでは、久留米・福岡を中心に、Webサイトの保守とセキュリティ点検のご相談を無料で承っています。サーバーの設定状況を確認し、必要な対策を優先順位をつけてご提案します。

よくある質問

お問い合わせフォームやCMSを使っているなら、WAFの有無を一度確認する価値はあります。特に、制作会社に改修を頼めない、CMSやプラグインを長く更新できていないなど、脆弱性をすぐに直せない事情がある場合は有効です。まずは契約中のレンタルサーバーに標準のWAF機能があるか、有効になっているかを確認しましょう。

この記事の筆者

代表取締役ひろさん

28歳でWeb業界に入り、20年以上にわたって企画・ディレクション・デザイン・開発を一貫して手がける。現在は代表取締役として現場に立ち続けながら、SEOの知見を活かしたコンテンツ発信にも取り組む。このブログでは、ビジネスの現場で役立つ視点や経験を、実務者の目線で綴っていく。