自社で公開・運用しているWebサイトやWebアプリケーションを預かっていると、Log4Shellのようなゼロデイ攻撃のニュースを見るたびに「うちのWAFで、こうした未知の攻撃は防げるのだろうか」と不安になります。WAFは導入済み、あるいは導入を検討している。けれど、修正プログラムがまだ存在しない脆弱性を、既知のパターンを見張るWAFが止められるのかは、直感的には矛盾して感じられます。
ゼロデイ攻撃は修正プログラムが出る前の未知の脆弱性を突くため、既知のパターンを見張るWAFで本当に止められるのか、判断に迷いやすいところです。守れる範囲を正しく把握できないままでは、自社のリスクを正直に評価できません。
本記事では、WAFでゼロデイ攻撃を防げるのか／防げないのかという結論を先に示したうえで、WAFで防げる攻撃と防げない攻撃の切り分け、WAFが未知の攻撃に先手を打てる仕組み（検知方式と仮想パッチ）、実際の被害事例との関係、守れない部分を埋める多層防御の組み方、ゼロデイに強いWAFの選び方までを解説します。
WAFで時間を稼ぐ間に脆弱性を根本から塞ぐ手段についても、最後に紹介します。
結論を今すぐ確認したい方は、「WAFでゼロデイ攻撃は防げるのか」からご覧ください。
目次
一括ダウンロードする
WAFでゼロデイ攻撃は防げるのか
先に結論を述べると、WAF単体で、修正プログラム公開前の未知の脆弱性を突くゼロデイ攻撃を完全に防ぎきることはできません。ただし、検知方式や仮想パッチの機能によっては、未知の攻撃にも一定の先手を打てる余地があります。「防げる／防げない」のどちらか一方ではなく、条件つきで被害を抑えられるというのが実際のところです。
この歯切れの悪さには理由があります。WAF（Web Application Firewall）は、そもそも脆弱性そのものを直す対策ではないためです。情報処理推進機構（IPA）の資料は、WAFの位置づけを次のように説明しています。
WAFは、ウェブアプリケーションの脆弱性を悪用した攻撃などからウェブアプリケーションを保護するソフトウェア、またはハードウェアです。WAFは脆弱性を修正するといったウェブアプリケーションの実装面での根本的な対策ではなく、攻撃による影響を低減する対策です。
出典：Web Application Firewall（WAF）読本 改訂第2版｜情報処理推進機構（IPA）
WAFは、脆弱性を塞ぐのではなく、脆弱性が残ったまま攻撃を受けても影響を低減する役割を担います。ゼロデイ攻撃のように、まだ修正プログラムが存在しない脆弱性が相手でも、攻撃の通信を遮断できれば被害を抑えられる可能性がある一方、あらゆる未知の攻撃を確実に止められるわけではない、という理解が出発点になります。
IPAもゼロデイ攻撃について「確実に防ぐことは難しい」としたうえで、攻撃の予兆の把握や被害の早期検知に役立つ対策として、IDS/IPS・WAF・仮想パッチなどの導入を挙げています。WAFはゼロデイ攻撃への対策の選択肢に含まれますが、それ単体で万全になるものではなく、複数の対策を組み合わせる前提で位置づけられているわけです。
出典・参考資料（2件）
そもそもゼロデイ攻撃とは
ゼロデイ攻撃とは、ソフトウェアの脆弱性に対する修正プログラムが提供される前に、その脆弱性を悪用する攻撃を指します。防御側に対策の猶予が「ゼロ日」しかない状態で攻撃が始まることから、この名前で呼ばれます。IPAは次のように定義しています。
ソフトウェアの脆弱性が発見され、脆弱性の修正プログラム（パッチ）や回避策が公開される前に脆弱性を悪用したサイバー攻撃が行われることがある。これをゼロデイ攻撃と呼ぶ。多くのシステムで利用されているソフトウェアに対してゼロデイ攻撃が行われると、社会が混乱に陥るおそれがある。
出典：情報セキュリティ10大脅威 2022（解説書）｜情報処理推進機構（IPA）
修正プログラムやシグネチャ（攻撃の特徴を記したパターン）が存在しないため、既知の攻撃を前提にした対策だけでは検出しにくいのがゼロデイ攻撃の難しさです。この「既知のパターンに頼れない」という性質が、WAFで防げるかどうかを考えるうえでの鍵になります。
WAFで防げる攻撃・防げない攻撃（ゼロデイはどちら側か）
ここからは、WAFが守る範囲を整理します。WAFが保護するのは、あくまでWebアプリケーション層（レイヤー7）への攻撃です。攻撃がどの層を狙うかによって、WAFの射程に入るかどうかが分かれます。
Webアプリケーションの入力値を悪用する攻撃は、WAFの射程に入ります。代表的なものは、クロスサイトスクリプティング（XSS）、SQLインジェクション、OSコマンドインジェクション、ディレクトリトラバーサルなどです。これらの多くは、OWASPがWebアプリケーションの代表的なリスクとして挙げる「インジェクション」などに含まれます。
一方で、通信の送信元・宛先（IPアドレスやポート番号）を狙うネットワーク層の攻撃や、サーバーOS・ミドルウェアの脆弱性を突く攻撃は、WAFの守備範囲の外です。IPAもWAF・ファイアウォール（FW）・IPSの役割の違いを明確に示しています。
IPSが様々な種類の攻撃を防御できることに対して、WAFはウェブアプリケーションへの攻撃を防御できます
出典：Web Application Firewall（WAF）読本 改訂第2版｜情報処理推進機構（IPA）
この役割分担を攻撃の種類ごとに整理すると、次のようになります。
| 攻撃の種類 | SQLインジェクション | クロスサイトスクリプティング（XSS） | OSコマンドインジェクション | ディレクトリトラバーサル | ネットワーク層への攻撃（不正アクセス・ポートスキャン等） | OS・ミドルウェアの脆弱性を突く攻撃 |
|---|---|---|---|---|---|---|
| 主に狙う層 | Webアプリケーション層 | Webアプリケーション層 | Webアプリケーション層 | Webアプリケーション層 | ネットワーク層 | OS・ミドルウェア層 |
| WAFの射程 | ● | ● | ● | ● | × | × |
※一般的な守備範囲の整理です。実際の防御可否は製品の設定やチューニングによって異なります。
では、ゼロデイ攻撃はどちら側でしょうか。答えは「狙う層による」です。Webアプリケーションの脆弱性を突くゼロデイ攻撃であれば、WAFの射程に入ります。たとえば後述するMOVEit Transferのゼロデイ攻撃はSQLインジェクションを悪用したもので、Webアプリケーション層の攻撃にあたります。一方、OSやVPN製品の脆弱性を突くゼロデイ攻撃は、同じ「ゼロデイ」でもWAFの守備範囲の外になります。
自社のリスクを整理するときは、「WAFを入れたからゼロデイ対策は万全」と考えるのではなく、Webアプリケーション層は守れるが、ネットワーク層やOS・ミドルウェアは別の対策が要ると層ごとに切り分けておくと、守れている範囲と守れていない範囲を社内でも説明しやすくなります。
WAFがゼロデイに先手を打てる仕組み（検知方式と仮想パッチ）
結論で触れた「条件つきで先手を打てる」とは、具体的にどういう仕組みでしょうか。ここでは、WAFが未知の脆弱性にどう対応するのかを、検知方式と仮想パッチの2つの観点から見ていきます。
検知方式ごとのゼロデイとの相性
WAFが攻撃を見分ける方式は一つではなく、方式によって未知のゼロデイ攻撃への強さが変わります。代表的なのが、既知の攻撃パターンを基準にする「ブラックリスト」方式と、正常な通信の形を基準にする「ホワイトリスト」方式です。IPAはそれぞれの性質を次のように説明しています。
「ブラックリスト」に基づいて検査する場合、WAFは既知の攻撃からウェブアプリケーションを防御できます。「ブラックリスト」では、すでに特徴が分かっている攻撃しか検出できません。
「ホワイトリスト」に基づいて検査する場合、開発者が想定していない値または型をウェブアプリケーションが受け取ることがなくなります。
出典：Web Application Firewall（WAF）読本 改訂第2版｜情報処理推進機構（IPA）
ここに、ゼロデイ攻撃への相性がはっきり表れます。ブラックリスト（シグネチャ）方式は「特徴が分かっている攻撃しか検出できない」ため、パターンが用意される前の真に未知の攻撃には原理的に弱いといえます。対してホワイトリスト方式は、想定した正常な値や型以外を受け付けないため、攻撃手法が未知でも想定外の入力として弾ける余地があります。
近年はこれらに加え、複数の特徴から異常度を判定するスコアリングやAI・振る舞い検知を備えた製品もあり、シグネチャに依存せず未知の通信に反応しうる方向で対応範囲を広げています。
方式ごとの違いを整理すると、次のとおりです。
| 検知方式 | ブラックリスト（シグネチャ）型 | ホワイトリスト型 | スコアリング／AI・振る舞い検知 |
|---|---|---|---|
| 仕組み | 既知の攻撃パターンに一致する通信を遮断 | 想定した正常な値・型以外を許可しない | 複数の特徴から総合的に異常度を判定 |
| 未知のゼロデイへの効き方 | パターン更新前の未知の攻撃は検出しにくい | 想定外の入力を弾くため、未知の攻撃にも先制防御の余地がある | シグネチャに依存せず反応しうるが、変形した攻撃で回避される場合もある |
※方式の分類と効き方の一般的な傾向です。実際の検出力は製品や設定によって異なります。
ただし、「ホワイトリストやAIを使えば未知の攻撃を必ず防げる」とまでは言えません。WAFを自動的に回避する攻撃手法の研究も存在します。ブラックハット・アジア2022で発表された研究では、SQLインジェクションのペイロードを自動で変形させることで、複数の商用・オープンソースWAFに対して回避が成立する例が報告されています。
検知方式が高度化しても、変形された攻撃ですり抜けられる可能性は残るため、WAFを万能とみなすのは適切ではありません。自社で使う（検討する）WAFがどの方式かは、製品資料の「検知方式」「シグネチャ」「AI検知」といった記載から確認できます。
出典・参考資料（2件）
仮想パッチ（バーチャルパッチ）とは
WAFがゼロデイ対策として語られるとき、中心になるのが「仮想パッチ（バーチャルパッチ）」の考え方です。OWASPは仮想パッチを次のように定義しています。
A security policy enforcement layer which prevents the exploitation of a known vulnerability.
出典：Virtual Patching Best Practices｜OWASP
（既知の脆弱性の悪用を防ぐ、セキュリティポリシーの強制層）
仮想パッチは、アプリケーションのソースコードには手を加えず、WAFなどの手前の層で攻撃の通信を遮断することで、脆弱性が悪用されるのを防ぐ暫定的な対策です。正式な修正プログラムを適用するまでの「時間を稼ぐ」手段といえます。
この時間稼ぎが必要になるのは、修正の適用までにいくつかの工程を踏むためです。ベンダーによる修正プログラムの提供を待ち、適用前に動作検証や影響範囲の確認を行い、止められないシステムでは適用のタイミングを調整する——こうして脆弱性が公表されてから適用し終えるまでには、どうしても時間差が生じます。実際、IPAの届出分析でも、脆弱性の修正に相応の日数を要することが示されています。
脆弱性の修正に31日以上の日数を要した届出は、全体の53%にのぼります
出典：Web Application Firewall（WAF）読本 改訂第2版（2011年）｜情報処理推進機構（IPA）
この届出統計は2010年末時点の届出を2011年公表のIPA読本がまとめたものですが、修正プログラムの提供・検証・適用という工程そのものは今も変わりません。そのため、脆弱性が公表されてから実際に塞がれるまでのタイムラグは現在も残ります。その間に脆弱性を放置すれば攻撃にさらされ続けるため、WAFのルールで該当する攻撃を暫定的に遮断し、正式修正までのリスクを下げるのが仮想パッチの役割です。
ここで注意したいのは、仮想パッチが対象とするのは「既知の脆弱性」である点です。脆弱性が判明し、遮断するためのルールを書ける段階になって初めて機能します。したがって、まだ存在すら公になっていない真の未知の脆弱性まで仮想パッチが止められるわけではありません。
「ゼロデイ対策としてのWAF」とは、おおむね脆弱性が公表されてから正式修正までの期間を埋める対策だと捉えると、過度な期待も過小評価もせずに済みます。
出典・参考資料（2件）
ゼロデイ攻撃の被害事例とWAFの防御可否
ここまでの切り分けを、実際の事例に当てはめてみます。WAFの射程に入るゼロデイと、射程の外のゼロデイでは、WAFで対応できるかどうかが大きく変わります。
WAFの射程に入った例：MOVEit Transferの脆弱性（CVE-2023-34362）。ファイル転送製品MOVEit TransferのWebアプリケーションに見つかったSQLインジェクションの脆弱性で、2023年5〜6月に修正プログラム提供前から実際に悪用されました（CVSS基本値9.8）。
SQLインジェクションはWebアプリケーション層の攻撃であり、WAFの守備範囲にあたります。こうした種類のゼロデイであれば、WAFのルールによる暫定的な遮断（仮想パッチ）が有効に働く余地があります。
WAFの射程の外だった例：PrintNightmare（CVE-2021-34527）やPulse Connect Secureの脆弱性（CVE-2021-22893）。前者はWindowsの印刷スプーラー、後者はVPN製品の脆弱性で、いずれも修正プログラムが用意される前に回避策や緩和策が必要になりました。
これらはOS機能やVPN製品を狙う攻撃であり、Webアプリケーション層を守るWAFの射程には入りません。同じ「ゼロデイ」でも、WAFだけでは守れない層の攻撃があることがわかります。
冒頭で触れたLog4Shell（Apache Log4jの脆弱性、CVE-2021-44228、CVSS基本値10.0）も、この切り分けで見ておきます。Log4jはログ出力に使われるライブラリですが、攻撃者はWebアプリケーションが受け取るリクエスト（HTTPヘッダーや入力値）に細工した文字列を仕込んで悪用します。
これはWebアプリケーション層を経由する攻撃であり、WAFで該当する攻撃文字列を遮断する余地がある側に入ります。
そのため、正式な修正までの間は、WAFのルール（仮想パッチ）で該当パターンを暫定的に遮断して時間を稼ぐ対応が取れました。IPAは本件を、脆弱性の公開直後から攻撃が急増した事例として整理しています。JPCERT/CCも、実証コードの公開と国内での悪用を試みる通信を確認したと注意喚起しています。
出典・参考資料（6件）
一括ダウンロードする
WAFで守れない部分を埋める多層防御の組み方
ここまで見てきたとおり、WAFが守るのはWebアプリケーション層で、しかも未知の攻撃を完全には止めきれません。この「守れない部分」を埋めるのが、複数の対策を層状に重ねる多層防御（Defense in Depth）の考え方です。IPAもゼロデイ攻撃への対策として、単独の製品ではなく複数の対策の組み合わせを挙げています。
各対策が守る層は、それぞれ異なります。IPAはファイアウォール（FW）とWAFの違いを次のように説明しています。
FWは、通信における送信元情報と送信先情報（IPアドレスやポート番号等）を基にアクセスを制限するソフトウェア、またはハードウェアを指します。（中略）このため、FWでウェブアプリケーションの脆弱性を悪用する攻撃を防ぐことはできません
出典：Web Application Firewall（WAF）読本 改訂第2版｜情報処理推進機構（IPA）
FW・IPS・WAFに、脆弱性診断とパッチ適用を加えて役割を整理すると、どの対策が何を担うのかが見えてきます。
| 対策 | ファイアウォール（FW） | IPS（侵入防止システム） | WAF | 脆弱性診断 | 迅速なパッチ適用・運用 |
|---|---|---|---|---|---|
| 主に守る層・役割 | 送信元・宛先（IP・ポート）でアクセスを制限するネットワーク層の防御 | OSの脆弱性やファイル共有への攻撃など、幅広い種類の攻撃を防御 | Webアプリケーション層への攻撃を遮断し、仮想パッチで修正までの時間を稼ぐ | 攻撃を受ける前に自社の弱点を洗い出し、根本的に塞ぐための前提をつくる | 公開された修正プログラムを早期に適用し、脆弱性そのものを解消する |
※各対策の一般的な役割の整理です。実際の構成は自社のシステムやリスクに応じて検討してください。
ゼロデイ攻撃に備えるうえでの要点は、WAFを「時間を稼ぐ層」として位置づけ、その間に脆弱性診断とパッチ適用で根本的に脆弱性を塞ぐ流れをつくることです。WAFだけに頼ると、射程外の層の攻撃や、WAFをすり抜けた攻撃に対応できません。逆に、各層の役割を理解して組み合わせれば、どこかが突破されても別の層で被害を抑えられる可能性が高まります。
出典・参考資料（2件）
ゼロデイに強いWAFの選び方
WAFを選ぶ際、ゼロデイ攻撃への備えという観点では、次のような点を確認すると判断しやすくなります。いずれも「未知の攻撃にどれだけ早く・どれだけ柔軟に対応できるか」に関わる観点です。
- シグネチャやルールの更新の速さ：新しい攻撃手法が判明したときに、どれだけ速くシグネチャやルールへ反映されるかが、未知の攻撃への対応力を左右します。
- 仮想パッチへの対応：脆弱性が公表されてから正式修正までの間、該当する攻撃を暫定的に遮断するルールを柔軟に設定できるかどうか。時間を稼ぐ対策の中核になります。
- 最新の攻撃情報の反映（脅威インテリジェンス）：外部で観測された新しい攻撃の情報（脅威インテリジェンスと呼ばれます）を取り込み、防御ルールへ反映できる仕組みがあるか。最新の攻撃動向にどれだけ追随できるかの目安になります。
- 回避（バイパス）への耐性と運用支援：変形された攻撃で回避される可能性が残る以上、検知ルールの継続的なチューニングや、運用を支援する体制があるかも重要です。
- 誤検知と運用負荷のバランス：検知を強めると正常な通信まで遮断する誤検知が増えます。自社の運用体制で無理なく回せる検知精度とチューニングの柔軟性があるかを確認します。
これらはいずれも、WAF単体でゼロデイを完全に防ぐための条件ではなく、WAFで稼げる時間を最大化するための観点です。本記事ではWAF個別製品の比較までは扱いませんが、これらの観点は資料請求や問い合わせの際の確認項目として使えます。
そのうえで、WAFの性能だけで判断せず、次に紹介する脆弱性診断と組み合わせて初めてゼロデイ対策が成立する点を踏まえて検討すると、過不足のない構成に近づきます。
WAFで時間を稼ぐ間に、稼働中Webアプリの弱点を根本から塞ぐ
WAFはあくまで、脆弱性が残ったまま攻撃の影響を低減する「時間を稼ぐ」対策です。ゼロデイ攻撃への備えを根本から固めるには、その時間の間に、自社が公開・運用しているWebアプリケーションやAPIの弱点を洗い出し、塞いでいく必要があります。その手段として使われるのが脆弱性診断です。攻撃を受ける前に弱点を見つけておければ、修正プログラムの適用や設定変更で、脆弱性そのものを減らせます。
攻撃側も手口を速く変えてくる以上、年に一度の診断では追いつかないこともあります。稼働中のアプリケーションを継続的に検査できるツールや、新しい攻撃に追随して診断してくれるサービスを押さえておくと、WAFで稼いだ時間を根本対策につなげやすくなります。以下はご紹介する脆弱性診断サービスの比較表です。
| 脆弱性診断サービス | Aikido Security | CoWorker 脆弱性診断サービス |
|---|---|---|
| 提供形態 | ツール型（SaaS） 自動スキャンを自社で継続運用 | 受託型 専門家がAIで診断しレポート納品 |
| 主な診断メニュー | ソースコード診断（SAST） 依存ライブラリ検査（SCA） 動的診断（DAST）・クラウド設定点検（CSPM） | 静的診断（ソースコード） 動的診断（Web／API） ペネトレーションテスト |
| 主な診断対象 | ソースコード・依存ライブラリ クラウド設定・稼働中Webアプリ | Webアプリ・API ソースコード・設計書 |
| 診断の回し方 | 管理画面で常時・継続的に検査 | 四半期・月次の定期診断に対応 |
| 新しい攻撃・ゼロデイへの備え | 依存ライブラリの脆弱性を継続検査し 影響の有無を素早く把握。 修正プルリクエストを自動生成 | AI診断システム「Red Agent」で 診断を高速化し、診断の頻度を上げやすい |
| 料金の目安 | 月額5万円台〜 （年間契約・10ユーザーまで） 無料プランあり（2ユーザーまで） | ソースコード診断15万円〜 動的診断30万円〜 Webペネトレーションテスト60万円〜 |
| 提供・サポート体制 | ベルギー開発のSaaS 日本窓口のAndGoが日本語で 導入・運用を支援 | 国内企業が開発・診断 診断から修正方針の提示まで 日本語で対応 |
| 詳細情報 | 公式資料を見る | 公式資料を見る |
※料金はカタログ掲載情報・各社公式情報による目安です。最新の料金やプランは各社にご確認ください。
ここで取り上げたのは代表的な2サービスですが、脆弱性診断は対象（Webアプリ・API・ソースコード・クラウド設定など）や手法、費用相場に幅があり、自社に合う一社は要件によって変わります。診断方法や費用の目安、依頼先の選び方まで含めて幅広く見比べたい場合は、次の記事で詳しく整理しています。
脆弱性診断サービスおすすめ比較｜診断方法・費用相場・選び方を解説【無料ツールあり】
Webサービスや社内システムの脆弱性診断を検討する際、「専門家による手動診断とツールによる自動診断のどちらが自社に必要なのか」「費用が数十万円から数百万円までと幅が広く、妥当な予算が読めない」といった壁に突き当たる担当者は少なくありません。…
1. Aikido Security（株式会社AndGo）
Aikido Securityは、脆弱性診断の複数の機能を1つの管理画面にまとめたオールインワン型のSaaSです。ソースコードの静的解析（SAST）、依存関係の検査（SCA）、クラウド設定の点検（CSPM）、稼働中Webアプリの動的検査（DAST）などに対応します。開発元はベルギーのAikido Security BVで、日本では株式会社AndGoが窓口となって提供しています。
ゼロデイ対策の観点では、依存ライブラリの脆弱性を継続的に検査するSCAが役立ちます。Log4Shellのように広く使われるライブラリの脆弱性が公表された際、自社の製品がその影響を受けるかを素早く把握できるためです。検出した脆弱性には修正コードのプルリクエストを自動生成する機能があり、確認から修正までを開発の流れの中で進められます。
脆弱性は見つけるだけでなく、実際に修正までたどり着いて初めて根本対策になります。この「見つけてから直すまで」の難しさについて、Aikido Securityを日本で提供する株式会社AndGoの原氏は次のように話します。
料金はAndGo経由で月額5万円台から（年間契約・利用者10人までの場合）利用でき、2ユーザーまでの無料プランも用意されています。管理画面の操作やレポートの確認を日本語で行え、導入設定から運用の定着までをAndGoが支援します。
2. CoWorker 脆弱性診断サービス（CoWorker株式会社）
CoWorker株式会社が提供する脆弱性診断サービスは、WebアプリケーションやAPIを対象に診断を行います。ソースコードを読み取る静的診断、アクセスして解析する動的診断、擬似攻撃で侵入可否を試すペネトレーションテストの3種類をそろえています。
自社開発のAI診断システム「Red Agent」を専門家が用いて診断する体制が特徴です。
AIを活用することで診断のスピードを高め、従来は年に一度になりがちだった診断を、四半期ごとや月次といった継続的な形で回しやすくしている点が、手口が速く変わるゼロデイ攻撃への備えと噛み合います。AIが示した結果は最終的に人の目で確認するフローをとり、修正の方針まで示す形で支援します。
保険システムや医療分野のシステム開発を手がけてきた受託開発の知見をもとに、診断から修正の方針提示までを委託できるのも強みです。Webアプリケーションを自社で開発・運用しながら、専門人材が不足している企業にとって検討しやすい選択肢といえます。
診断を定期的に回す必要性が高まっている背景には、攻撃側の変化があります。サービス開発のきっかけとなった環境の変化について、CoWorker株式会社の一ノ瀬氏はこう説明します。
一方で、攻撃者側もAIを活用するようになり、新しく、しかもスピード感の早い攻撃が増えてきています。これまでは年に1回、あるいはサービスをリリースした直後にだけ脆弱性診断を行うという企業が多かったのですが、AIの発達によって攻撃側のスピードが上がっている以上、定期的に診断をしないと危険だという状況になってきました。
まとめ
WAFでゼロデイ攻撃を防げるかという問いに対する答えは、「WAF単体では未知の脆弱性を完全には止めきれないが、条件つきで先手を打てる」です。WAFが守るのはWebアプリケーション層で、ネットワーク層やOS・ミドルウェアを狙うゼロデイは守備範囲の外になります。検知方式ではホワイトリスト型やAI・振る舞い検知が未知の攻撃に反応しうる一方、変形された攻撃で回避される可能性も残ります。
現実的な備えは、WAFを「正式修正までの時間を稼ぐ層」と位置づけ、仮想パッチで暫定的に遮断しながら、ファイアウォール・IPS・脆弱性診断・迅速なパッチ適用を層状に重ねることです。そして、WAFで稼いだ時間の間に、稼働中のWebアプリケーションの弱点を脆弱性診断で洗い出し、根本から塞いでいくことが、ゼロデイ攻撃に強い状態をつくります。
守れる範囲と守れない範囲を層ごとに切り分けておけば、自社のリスクを正しく評価し、社内でも共有しやすくなります。
一括ダウンロードする
よくある質問（FAQ）
Q. ゼロデイ攻撃はWAFで完全に防げますか？
A. WAF単体で、修正プログラム公開前の未知の脆弱性を突くゼロデイ攻撃を完全に防ぎきることはできません。WAFは脆弱性そのものを直す根本対策ではなく、攻撃による影響を低減する対策だからです。ただし、ゼロデイでもWebアプリケーション層を狙う攻撃であればWAFの射程に入り、検知方式（ホワイトリスト型やAI・振る舞い検知）や仮想パッチによって一定の先手を打てる余地があります。
一方、ネットワーク層やOS・ミドルウェアを狙うゼロデイは守備範囲の外で、変形された攻撃でWAFをすり抜けられる可能性も残るため、他の対策と組み合わせる前提で考える必要があります。
Q. 無料のWAFでもゼロデイ攻撃に対策できますか？
A. 無料・低価格のWAFでも基本的な攻撃の遮断はできますが、ゼロデイ対策としての実力は価格ではなく「未知の攻撃にどれだけ早く・柔軟に対応できるか」で決まります。具体的には、新しい攻撃手法が判明したときのシグネチャやルールの更新の速さ、脆弱性公表後に暫定遮断ルールを設定できる仮想パッチへの対応、外部で観測された最新の攻撃情報を防御ルールへ反映できる仕組みがあるかが分かれ目です。
無料かどうかだけで判断せず、これらの観点を満たせるか、そして誤検知を自社の運用体制で無理なく回せるかを確認して選ぶことをおすすめします。
Q. WAFを導入した後、ゼロデイ攻撃に備えてやるべきことは何ですか？
A. WAFを導入したら、それを「正式修正までの時間を稼ぐ層」と位置づけ、稼いだ時間の間に脆弱性診断とパッチ適用で脆弱性そのものを塞ぐことが重要です。
WAFはWebアプリケーション層しか守らず、未知の攻撃を完全には止めきれないため、ファイアウォール・IPS・脆弱性診断・迅速なパッチ適用を層状に重ねる多層防御を組み、どこかが突破されても別の層で被害を抑えられる状態をつくります。
特に、自社が公開・運用しているWebアプリケーションやAPIの弱点を脆弱性診断で洗い出し、根本から塞いでいくことが、ゼロデイ攻撃に強い状態への近道になります。
Q. 自社のWebアプリケーションがゼロデイ攻撃を受けているかを確認する方法はありますか？
A. ゼロデイ攻撃は既知のパターンに頼れないため確実な特定は難しいものの、アクセスログの異常やWAF・IDS/IPSの検知ログを継続的に監視することで予兆や被害を早期に把握できます。
IPAも、ゼロデイ攻撃は確実に防ぐことが難しいとしたうえで、攻撃の予兆の把握や被害の早期検知に役立つ対策としてIDS/IPS・WAFなどの導入を挙げています。普段と異なる通信や想定外の挙動を検知できる体制を整え、疑わしい事象を確認したらJPCERT/CCなどへの相談・報告を検討するとよいでしょう。
あわせて、脆弱性診断で自社アプリの弱点を事前に把握しておくと、どこが狙われやすいかを踏まえた監視がしやすくなります。
脆弱性診断サービスの料金・資料を一括チェック
MCB FinTechカタログでは、稼働中のWebアプリやAPIの脆弱性診断・継続スキャンなど、脆弱性診断サービスの最新資料を無料で一括請求できます。診断対象・手法・料金を見比べて、自社に合う候補を効率的に絞り込めます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
