【図解】仮想パッチとは？フロンティアAI時代に、パッチが間に合わない期間を守るしくみを初心者向けに解説

以前のコラムで、フロンティアAI（最先端の高性能な AI モデル）によって攻撃側が速くなる、という話を書きました。その続きとして今回取り上げるのが「仮想パッチ」です。脆弱性が見つかってから本番にパッチを当てるまでの間をどう守るのか、OWASP（Web アプリのセキュリティに取り組む非営利の団体）のガイドと各社の公式資料を読み直しながら、どこで何を止めているのかを図にしてみました。

この記事でわかること

なぜ今、仮想パッチが話題になっているのか
仮想パッチと公式パッチ（恒久パッチ）の違い
仮想パッチを置く4つの場所と、HTTPS で暗号化された通信での効き方
各社の製品に共通する考え方と、主な製品の例
入れてから外すまでの運用の流れと、つまずきやすい点

この記事について

フロンティアAIそのものと、セキュリティで気にしたい点は【コラム】フロンティアAIとは？チャットボットから「動くAI」へ、セキュリティで気にしたいことにまとめています。

記事に出てくる製品名は、しくみを説明するための例です。特定の製品を勧めるものではありません。詳しくは「主な製品の例」の注意書きを読んでください。

なぜ今「仮想パッチ」なのか

脆弱性が見つかって公開されると（多くは CVE〈共通脆弱性識別子：脆弱性ごとに付く世界共通の番号〉が付きます）、ふつうはソフトウェアのベンダーが修正プログラム（パッチ）を出し、利用者がテストしてから本番に当てます。この「公開されてからパッチが当たるまで」の間、システムは攻撃を受けうる状態のまま動いています。仮想パッチは、この期間に攻撃だけを止めておくための手段です（図1）。

図1　脆弱性の公開からパッチ適用までと、仮想パッチが受け持つ期間

この期間が改めて問題になっているのは、AI によって脆弱性の見つかり方が変わってきたからです。Palo Alto Networks の脅威調査チーム Unit 42 は2026年8月、NOVA（Network and Open-Source Vulnerability Analyzer：AI がソースコードを読み、脆弱性の発見から再現の確認、報告までを自動で行う、同社の調査システム）で、2か月の間に 3,915 件のオープンソースのプロジェクトを調べ、14,090 件の脆弱性を確認したと報告しました。そのうち 99.4% はそれまで報告されていなかったもので、公開情報と一致したのは 85 件だけだったそうです。

Unit 42 は、見つかる速さが上がるほど公開から悪用までの間隔が縮み、パッチの公開を見て攻撃コード（エクスプロイト）を作る作業も自動化できるとして、「パッチを当てるまでの猶予」がほとんどなくなったと述べています。同社は、従来のパッチを展開するまでの業界平均を 55 日としています（Verizon の DBIR〈Data Breach Investigations Report：毎年出ている情報漏えいの調査報告書〉2024 年版より）。

数字の見方

TrendAI（トレンドマイクロ）のまとめでは、DBIR 2026 年版で、侵入のきっかけとして脆弱性の悪用が 31% と初めて最も多くなったこと、CISA（米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁）の KEV カタログ（実際に悪用が確認された脆弱性の一覧）に載った脆弱性のうち、2025 年に修正し終えたのは 26% だったことが紹介されています。どれも調査ごとの数字なので、傾向をつかむ材料として見てください。

パッチをすぐ当てられない理由

「パッチが出たらすぐ当てればいい」と言えれば楽ですが、現場ではそうはいかない事情があります。OWASP や各社の資料に挙がっている理由を表にまとめました。

理由	よくある例
止められない	24時間動いている Web サービス、工場の制御システム、医療機器。再起動や停止がそのまま業務に響く
事前のテストが要る	パッチを当てて別の機能が壊れないか（デグレード）を確かめる時間と、保守時間の調整
自分では直せない	サードパーティ製品や外注で作ったアプリ。コードを直すには別の案件が必要になる
パッチがない	修正が出る前のゼロデイ（パッチがまだない脆弱性）、サポートが終わった製品（Windows Server 2012/2012 R2 は2023年10月、Windows 10 は2025年10月にサポート終了）
人手が足りない	開発者が別の案件にかかっていて、すぐには手が回らない

仮想パッチとは

OWASP の Virtual Patching Cheat Sheet では、仮想パッチを「既知の脆弱性を狙う攻撃を検知して止めるセキュリティポリシーの適用レイヤーで、脆弱なコードそのものは変えないもの」と定義しています。英語では Virtual Patching、トレンドマイクロなどは脆弱性シールド（Vulnerability Shielding）とも呼んでいます。

道路にたとえると、公式パッチは穴を舗装し直す工事、仮想パッチは穴の手前に柵を置くことです（図2）。

図2　公式パッチと仮想パッチのたとえ

実際の動きを、リクエストの流れで見ると図3のようになります。仮想パッチは、脆弱なサーバの手前（または中）で、届いた通信をルールと照らし合わせています。

図3　仮想パッチが攻撃だけを止める流れ

①〜④：ルールに一致しない普通のリクエストは、そのままサーバに届きます。
⑤〜⑦：既知の脆弱性を狙う形のリクエストはルールに一致し、仮想パッチのところで止まります。止めたことはログに残ります。

ここで押さえておきたいのは、脆弱性そのものはサーバに残ったままだという点です。OWASP も、仮想パッチが効くのは検査している通信と、ルールが見分けられる攻撃の形だけで、脆弱性はなくならないと書いています。迂回できないかをテストし、コードやベンダーの修正は並行して進める前提です。

公式パッチとの違い

比べる点	公式パッチ（恒久パッチ）	仮想パッチ
何を変えるか	脆弱なソフトウェアのコード	手前や周りの検査ルール（ソフトは変えない）
止める必要	再起動や停止、事前テストが要ることが多い	多くは止めずに入れられる
入れられる時期	ベンダーの修正と社内の手続き次第	ルールが用意できればすぐ
効き目	脆弱性そのものがなくなる	ルールに合う攻撃だけを止める。脆弱性は残る
位置づけ	根本の対策	パッチまでのつなぎ（補完的な管理策：本来の対策がすぐできないときに、代わりにリスクを下げる対策）

ルールの作り方は2通り

OWASP は仮想パッチのルールを次の2つに分けています。

許可リスト型（ポジティブモデル）：そのパラメータに来てよい値（文字の種類、長さなど）を決め、それ以外を止める。迂回されにくく、OWASP はこちらを推奨しています。
拒否リスト型（ネガティブモデル）：攻撃の形を決めて、それに合うものを止める。すぐ作れる反面、形を少し変えた攻撃に抜けられやすい。

報告に載っていた攻撃文字列だけを止めるような「その攻撃専用」のルールは、すぐ効いても長くは役に立たないので避けるよう注意されています。また OWASP は、仮想パッチが特に向いているのは SQL インジェクション（入力に SQL の命令を紛れ込ませて、データベースを不正に操作する攻撃）のような注入系の脆弱性で、それ以外の種類では十分に効かないことがあるとしています。

仮想パッチを置く4つの場所

「仮想パッチ」とひとことで言っても、止めている場所は製品によってかなり違います。大きく分けると、図4の4か所です。

図4　仮想パッチを置く4つの場所

ネットワーク（IPS・NGFW）

ネットワークの通り道に置いた IPS（Intrusion Prevention System：侵入防止システム。不正な通信を見つけて止める機器や機能）や NGFW（Next-Generation Firewall：アプリケーションの識別や IPS などを持つ次世代ファイアウォール）が、流れる通信の中身を検査し、特定の脆弱性を狙う形の通信を止めます。照合に使うのはシグネチャ（攻撃の特徴を書いたルール）で、ベンダーが配信したものを機器が自動で取り込む形が一般的です（図5）。

図5　ネットワークの仮想パッチ（IPS・NGFW）の流れ

①：ベンダーがシグネチャを配信し、IPS が取り込みます。新しい脆弱性が出ると、それに合わせたシグネチャが追加されます。
②〜④：届いた通信の中身をプロトコルに沿って読み、シグネチャと照らし合わせます。一致したら、その通信を破棄してログに残します。
⑤：一致しない通信だけが、後ろの機器に届きます。

1台で後ろにある多くのサーバや機器をまとめて守れるのが強みで、エージェントを入れられない機器、サポートが終わった機器、OT（Operational Technology：工場やプラントの設備を動かす制御系のシステム）を守る手段として使われます。逆に、その機器を通らない通信は検査できません。暗号化された通信も、復号しなければ中身は見えません（あとの「HTTPS で暗号化されていると、どこまで効くのか」で説明します）。

Web・API（WAF・WAAP）

Web サーバや API の手前にリバースプロキシ（サーバの代わりに通信を受け取り、後ろのサーバへ中継するしくみ）として置いた WAF（Web Application Firewall：Web アプリへの攻撃を止めるファイアウォール）で止める方法です。WAAP（Web Application and API Protection）は、WAF に API の保護、ボット対策、DDoS 対策（大量の通信を送りつけてサービスを止める攻撃への対策）を加えたものを指す呼び方です。

WAF は、ふだんから SQL インジェクションやクロスサイトスクリプティング（Web ページに不正なスクリプトを埋め込む攻撃）などをまとめて防ぐルールで動いています。仮想パッチとして使うときは、それに加えて「今回見つかった弱点」に合わせたルールを足します。OWASP の例では、あるページのパラメータに SQL インジェクションの脆弱性が見つかったとき、そのページのそのパラメータには数字だけを許すルールを WAF に入れて、アプリを直すまでの間を守っています（図6）。

図6　WAF に「弱点に合わせたルール」を足して守る流れ

①〜②：セキュリティ担当が弱点の場所（どのページの、どのパラメータか）を確かめ、そこに合わせたルールを WAF に足します。アプリには手を入れません。
③〜④：クライアントの HTTPS 接続は、サーバではなく WAF が受けます。WAF がサーバの証明書を持ち、TLS（HTTPS の暗号化のしくみ）を終端（そこで暗号を終わらせること）して中身を取り出します。
⑤〜⑥：足したルールに合わない（id に数字以外が入っている）ので、WAF がエラーを返し、脆弱なアプリには届きません。
⑦〜⑩：ルールに合う普通のリクエストは、そのままサーバへ転送されます。

ここで大事なのは、ルールを弱点の場所に合わせて絞ることです。図6のように「来てよい値」を決めるルールは、攻撃の形を少し変えられても抜けられにくく、普通の利用も止めにくくなります。API なら、API の定義（OpenAPI：API の仕様を書くための標準の形式）から来てよいリクエストを決めることもできます。DAST（Dynamic Application Security Testing：動いている Web アプリに外から攻撃を試して脆弱性を探すツール）の結果を取り込み、見つかった弱点に合わせたルールを作る機能を持つ製品もあります。リバースプロキシの位置づけは【図解】フォワードプロキシとリバースプロキシの違いとは？で説明しています。

ホスト（エージェント）

サーバや端末に入れたエージェント（そのマシンの上で動き、管理サーバの指示で保護を行うソフト）が、そのマシンの上で攻撃を止めます。製品によってやり方が違い、大きく2つのタイプがあります（図7）。

図7　ホストの仮想パッチ（エージェント）の流れ

①〜③（ホスト型 IPS）：管理サーバが IPS のルールを配り、エージェントがそのマシンに届いた通信を検査して、攻撃に一致したものを破棄します。ネットワークの IPS と同じことを、守るマシンの上でしているイメージです。トレンドマイクロの Server & Workload Protection などがこのタイプです。
④〜⑥（メモリで守るタイプ）：管理サーバが弱点（CVE）ごとの保護の設定を配り、エージェントが脆弱なアプリのメモリに保護を入れます。アプリのファイルや設定は書き換えません。保護を始めたことは、管理サーバに記録されます。
⑦〜⑧：弱点を突く入力が来ても、アプリは保護された経路（弱点の処理）へ進めず、攻撃が成り立ちません。通信の中身を照合するのではなく、アプリが動く場所で弱点への道をふさいでいる点が、ホスト型 IPS との違いです。Vicarius の vShield がこのタイプで、同社は、各 CVE が使うメモリ上や実行ファイル上の経路を特定してふさぐと説明しています（細かいしくみは公開されていません）。

ネットワークの構成に関係なく、そのマシン自身を守れるのが利点です。その代わり、エージェントを入れられる OS やアプリでないと使えず、台数分の導入と管理が要ります。

アプリ内部（RASP）

RASP（Runtime Application Self-Protection：アプリが動いている実行環境の中に組み込み、アプリ自身が攻撃を止めるしくみ）は、WAF のようにサーバの手前に置く別の機器ではありません。Java なら JVM（Java のプログラムを動かす実行環境）に、RASP のモジュール（エージェント）を起動時に読み込ませ、アプリと同じ JVM の中で動かします（図8）。.NET など、ほかの実行環境に対応した製品もあります。

図8　RASP はどこにあるのか（WAF との置き場所の違い）

RASP のモジュールは、データベースへの問い合わせ、OS コマンドの実行、ファイルの読み書きといった危ない処理の入口にフック（処理の途中に割り込んで中身を確かめる仕掛け）を入れます。アプリがその処理を呼ぶと、実行する直前に RASP が中身を確かめます。SQL インジェクションを例に、流れを追うと図9のようになります。

図9　RASP が SQL インジェクションを止める流れ

①：JVM が起動するときに RASP のモジュールが読み込まれ、危ない処理の入口にフックを入れます。
②〜⑥：普通の入力（id=123）では、組み立てた SQL 文の中で入力は「値」のままです。RASP は問題なしと判断し、アプリはそのまま DB に問い合わせます。
⑦〜⑩：攻撃の入力（id=123 OR 1=1）では、入力の一部が SQL 文の「条件（命令）」として働き、文の意味が変わってしまいます。RASP は DB に送る直前のこの状態を見て、攻撃と判断します。判定のしかたは製品で違いますが、考え方はこのとおりです。
⑪〜⑫：RASP が処理を止め、アプリはエラーを返します。DB には届きません。

WAF と RASP の違いを表にすると、次のようになります。WAF が見ているのは、届いたリクエストの文字の並び（id=123 OR 1=1 という文字列）だけで、それがアプリの中でどう使われるかまでは分かりません。RASP は、入力が実際に SQL 文に組み込まれたあとの姿を見て判断できます。

比べる点	WAF	RASP
置く場所	サーバの手前の別の機器（リバースプロキシ）	サーバの中。アプリと同じ JVM などの実行環境
見ているもの	届いたリクエストの文字（URL・パラメータ・ヘッダなど）	DB やコマンドに渡す直前の処理と、そこに入った入力
判断のしかた	文字がルール（攻撃の形や許す値）に合うか	入力によって処理の意味が変わったか
入れるもの	機器やクラウドサービス。アプリは変えない	実行環境にモジュールを読み込む。アプリのコードは変えない

実際に何が起きるかを見て判断できるので、精度を上げやすいのが RASP の長所です。ただし、言語やフレームワークごとにモジュールが要ること、アクセス権の不備（他人のデータを ID だけ変えて読めてしまう、など）や業務の流れを悪用する攻撃は、処理としては正常に見えるので止めにくいことに注意が必要です。導入はまず監視モードで始め、様子を見てから止める範囲を広げるのが一般的です。

HTTPS で暗号化されていると、どこまで効くのか

いまの Web の通信は、ほとんどが HTTPS で暗号化されています。仮想パッチは通信の中身を見て判断するので、暗号化された中身を見られるかどうかで、効き目が大きく変わります。場所ごとに整理すると図10のようになります。

図10　HTTPS の通信で、どこなら中身が見えるか

復号しない IPS・FW：見えるのは、宛先の IP アドレスとポート、接続先のサーバ名など、暗号化されていない一部だけです。HTTPS の中に入った Web アプリへの攻撃は、シグネチャがあっても照合できません。Fortinet の資料でも、証明書の検査だけ（certificate inspection）では SSL/TLS の層までしか見ず、暗号化された中身をすべて検査するには通信を復号する deep inspection が要るとしています。
復号する FW：外から社内のサーバへ来る通信なら、守るサーバの証明書と秘密鍵を FW に入れて復号し、検査できます。Palo Alto の SSL Inbound Inspection（外から来る SSL/TLS 通信を復号して検査する機能）がこれで、FW がクライアントとサーバの間に入り、2つのセッションに分けて中継します。ただし、クライアント証明書で認証する通信や、証明書を固定する（ピンニング）アプリの通信など、復号できないものもあります。
WAF：図6のとおり、TLS を WAF で終端するので、中身を見て判断できます。
ホスト・RASP：RASP はアプリの中で、復号されたあとの値を扱うので、HTTPS かどうかに左右されません。ホスト型 IPS が暗号化通信をどこまで検査できるかは製品によって違うので、製品の資料で確かめてください。

まとめると、HTTPS で公開している Web アプリを守る目的なら、復号しないネットワークの IPS だけでは効果は限られます。その場合は、WAF で TLS を終端するか、FW で受信方向の復号を設定するか、ホストや RASP で守るかを組み合わせて考えることになります。

一方で、ネットワークの仮想パッチが役に立たないわけではありません。社内のファイル共有や OT の制御用プロトコルなど、暗号化していないことが多い通信や、エージェントを入れられない機器への攻撃は、ネットワークの IPS で止められます。何の通信を守りたいのかを先に決めてから、置き場所を選ぶのがよいと思います。

復号するときの注意

復号すると、FW や WAF にサーバの秘密鍵を置くことになります。鍵の管理、復号による処理の負荷、復号した中身がログに残らないかといった点も、あわせて設計が必要です。

4つの場所の比較

場所	見ているもの	HTTPS の中身	向いている場面	苦手なこと
① ネットワーク	通信の中身	復号を設定したときだけ	まとめて守りたい。エージェントを入れられない機器・OT	経路の外の通信、復号しない暗号化通信
② Web・API	HTTP のリクエスト	見える（TLS を終端）	公開している Web サイトや API	HTTP 以外の通信。正しい形をした不正なリクエスト
③ ホスト	OS・プロセス・メモリの動き	製品による	サーバや端末そのものを守りたい	エージェントを入れられない機器
④ アプリ内部	実行直前の処理	見える（復号後の値）	自社で持つ Java や .NET などのアプリ	対応していない言語。アクセス権や業務ロジックの不備

各社の製品に共通する考え方

各社の資料を並べて読むと、言い方は違っても、似た考え方が2つ見えてきます。

1. 見つけてから当てるまでの輪を速く回す

1つ目は、脆弱性を見つけてから、ルールにして、対象に当て、結果を見張るまでの流れを、できるだけ速く回そうとしている点です（図11）。

図11　仮想パッチの輪（見つける → 調べる → ルールにする → 配る・当てる → 見張る・外す）

Palo Alto Networks は、Unit 42 の NOVA が見つけた脆弱性から仮想パッチの候補も作り、新しい脆弱性への保護を数時間で配信するとしています。
VMware は、脆弱性スキャンで見つかったワークロードにタグを付け、タグに合わせて IPS のポリシーを自動で当てる使い方を紹介しています。
TXOne Networks は、AI でルールを学習・調整し、ポリシーを展開する手間を 9 割以上減らして、数週間かかっていた作業を数時間にするとしています。

どこまで自動で進めるかは製品と運用で違います。Fortinet も、ほとんどの組織はルールを見直してテストしてから止める設定にしている、と書いています。

2. 入口・内部・アプリの中で重ねる

2つ目は、1か所だけに頼らず、何か所かで重ねて止める考え方です（図12）。

図12　入口（North-South）・内部（East-West）・アプリの中（In-App）で重ねる

North-South（入口：外部と内部の間を行き来する通信）：インターネットから入ってくる通信を、WAF や NGFW で止めます。
East-West（内部の横移動：内部のサーバどうしの通信）：中に入られたあと、別のサーバへ広がる攻撃を止めます。VMware の vDefend は、各ワークロードの仮想 NIC（仮想マシンのネットワークの差し口）で通信を検査する分散型の IDS/IPS（IDS は侵入を検知するだけ、IPS は検知して止める）です。
In-App（アプリの中）：入口をすり抜けた攻撃を、アプリの中の RASP で止めます。WAF を最初の防御、RASP を最後の防御と位置づける説明もあります。

主な製品の例

製品名についての注意（免責）

この節に出てくる製品名・機能名と説明は、各社が公開しているドキュメントやブログを、2026年10月時点で筆者が読んでまとめたものです。特定の製品を勧めたり、性能や効果を保証したりするものではありません。「数時間で配信」「手間を 9 割以上削減」などの数字は各社の説明で、どの環境でもそうなるとは限りません。

製品の仕様、対応範囲、名称、提供状況は変わることがあり、記事の内容が実際と違っている可能性もあります。導入や比較を検討するときは、必ずメーカーの最新のドキュメントを確認し、メーカーや販売代理店に問い合わせたうえで、自社の環境で検証してください。

各社が仮想パッチとして出している製品を、図4の4つの場所に当てはめると図13のようになります。

図13　主な製品と、仮想パッチを置く場所

会社	製品・機能	場所	特徴（各社の公開資料より）
Palo Alto Networks	Frontier Virtual Patching（PAN-OS 12.2）	ネットワーク	NGFW で、パッチが出る前の脆弱性も含めて数時間で保護を配信するとしている。新しい検知エンジン「vaulted protection」（パッチが出る前の脆弱性を安全に保護するための仕組みとしている）を使う。PAN-OS（同社のファイアウォールの OS）のアップグレードと自動のコンテンツ更新で使える
TrendAI （トレンドマイクロ）	TrendAI Vision One（Network Security の TippingPoint TXE、Server & Workload Protection、Endpoint Security）	ネットワークホスト	ZDI（Zero Day Initiative：同社が運営する、ベンダーを問わない脆弱性の報奨金プログラム）の情報をもとに IPS のフィルタを配る。ホスト型 IPS は再起動もコード変更もなしで当てられる
Fortinet	FortiGate の IPS、FortiWeb、FortiGate Rugged	ネットワーク Web・OT	IPS と WAF のルールで止める。OT 向けの堅牢化モデルにも IPS を載せている
VMware by Broadcom	vDefend 分散 IDPS、Avi WAF	内部・Web	各ワークロードの仮想 NIC で検査し、横の移動を止める。Avi WAF は DAST（Qualys、OWASP ZAP）の結果を取り込んでポリシーを作れる
TXOne Networks	Edge（vEdgeIPS Pro）	OT	フェイルセーフ設計（セキュリティ機器が生産の通信を妨げないようにする設計）のインライン IPS。2026年9月に仮想アプライアンス版の vEdgeIPS Pro を追加した
Vicarius	vRx（vShield）	ホスト	アプリのメモリ空間を包んで攻撃の経路をふさぐ。パッチを当てて確認が済むと保護を外す
Waratek	Waratek RASP（IAST+RASP）	アプリ内部	JVM の中で危ない処理を止める。コード変更・再起動なしで仮想パッチを当てられる。IAST（Interactive Application Security Testing：テスト中のアプリの中で動き、脆弱性を見つけるツール）も持つ

入れてから外すまでの運用

仮想パッチは、入れたら終わりではありません。OWASP は、インシデント対応と同じ考え方で、準備・特定・分析・仮想パッチの作成・実装とテスト・回復とフォローアップの順に進めることを勧めています。担当者と機器のやり取りで見ると、図14のようになります。

図14　仮想パッチを入れてから外すまでの流れ

手順	誰が・どこで	何をするか
①	情報源 → セキュリティ担当	ベンダーの通知や公開情報で脆弱性を知る。自社の診断で見つかることもある
②	セキュリティ担当	影響するバージョン、問題が起きる設定、攻撃の例（PoC：脆弱性を実際に突けることを示すコード）を確かめる
③	セキュリティ担当	ルールを作り、CVE 番号やルール ID をチケットに記録する
④〜⑤	仮想パッチ	まず「ログのみ（検知のみ）」で入れ、普段の通信が引っかからないかを見る
⑥	仮想パッチ	誤検知がないのを確かめてから、遮断モードに切り替える
⑦	セキュリティ担当 → 仮想パッチ	形を変えた攻撃や別の経路で迂回できないかを再テストする。抜けられたら②に戻る
⑧〜⑨	業務システム（システム担当）	恒久パッチを当て、脆弱性が直ったことを確かめる
⑩	セキュリティ担当 → 仮想パッチ	ルールを外し、記録を残す

⑩については、OWASP の中で、ログが取れて便利なので仮想パッチを残しておく人も多い、と紹介されています。外すか残すかは、ルールの数と性能への影響を見て決めればよいと思います。

事前にやっておくこと

OWASP は、インシデントが起きてから WAF の導入を提案しても遅いので、平時に準備しておくよう書いています。

使っている製品のベンダーの脆弱性通知に登録しておく。
仮想パッチを急いで入れるときの承認手順と、元に戻す条件を決めておく。
仮想パッチに使う機器やソフトを、あらかじめ置いておく。
ルール ID、時刻、対象、結果をログに残す。パスワードやカード番号などの機微な値は、ログから外すか伏せる。

つまずきやすい点

つまずき	何が起きるか	対策
いきなり遮断する	正常な通信や、OT の独自プロトコルの通信まで止めてしまう	ログのみで始め、誤検知を見てから切り替える。止めたルールだけをすぐ無効にできるようにしておく
恒久策のつもりで放置する	パッチが当たらないまま残り、ルールも古くなる	パッチまでのつなぎと決め、チケットで期限と担当を管理する
シグネチャを更新しない	新しい形の攻撃を見逃す	自動更新を有効にし、重要な CVE が対象に入っているか確かめる
広すぎる・狭すぎるルール	広すぎると誤検知と性能低下、攻撃文字列だけの狭いルールは抜けられやすい	CVE と対象の機器・ポート・パラメータに合わせて作る
検査しない経路がある	復号していない HTTPS や、仮想パッチを通らない経路から攻撃される	経路を洗い出し、必要なら復号、WAF、ホスト側の対策を組み合わせる

まとめ

仮想パッチは、脆弱なソフトは変えずに、その手前や周りで攻撃だけを止め、恒久パッチまでの時間を稼ぐための手段です。置く場所ごとの特徴を表にまとめます。

場所	主な仕組み	こんなときに
① ネットワーク	IPS・NGFW のシグネチャ	多くの機器をまとめて守りたい。OT やサポート切れの機器がある。HTTPS を守るなら復号とセットで
② Web・API	WAF・WAAP のルール	インターネットに公開している Web サイトや API を守りたい
③ ホスト	エージェント（ホスト型 IPS、メモリ保護）	サーバや端末そのものを守りたい
④ アプリ内部	RASP	自社で持つアプリを、実行直前で守りたい

どの場所でも、脆弱性そのものは残っています。ログのみで始めて遮断に切り替え、迂回できないかを確かめ、恒久パッチを当てたら外す、という流れまで含めて運用を決めておくことが大切です。

動画で解説この記事の内容を、図解の動画でも説明しています

このページのまま再生できますYouTubeで開く ›

参考にした資料

この記事は、次の資料で内容を確かめて書きました。製品名や対応範囲は変わることがあるので、最新の情報はリンク先とメーカーへの問い合わせで確かめてください。

Virtual Patching – OWASP Cheat Sheet Series（OWASP）：仮想パッチの定義、すぐ直せない理由、許可リスト型と拒否リスト型、ログのみでのテスト、運用の6つの段階
The Frontier AI Vulnerability Burst: Industrializing Autonomous Zero-Day Discovery in Open-Source Software（Palo Alto Networks Unit 42）：NOVA の調査件数と、パッチまでの猶予が縮んでいるという見方
Redefining Network Security for the Frontier AI Era（Palo Alto Networks）：Frontier Virtual Patching と PAN-OS 12.2、パッチ展開の業界平均 55 日
SSL Inbound Inspection（Palo Alto Networks）：受信方向の復号にはサーバの証明書と秘密鍵が要ること、復号できないセッション
Security 101: Virtual Patching（TrendAI）：脆弱性シールドという呼び方、DBIR と KEV の数字、Vision One の仮想パッチの製品構成
Virtual Patching for IT and OT: How to Secure Systems without Downtime（Fortinet）：公式パッチとの違い、IT と OT での使いどころ、つまずきやすい点
Why you should use SSL inspection（Fortinet）：certificate inspection と deep inspection の違い
Virtual Patching: Guarding Against a Tsunami of AI-discovered Exploits with vDefend and Avi（VMware）：分散 IDPS による East-West の仮想パッチ、Avi WAF と DAST 結果の取り込み
TXOne Networks Launches AI-Driven Edge Release, Bringing Zero-Disruption OT Protection to Virtual Infrastructure（TXOne Networks）：vEdgeIPS Pro とフェイルセーフ設計、ルール学習による展開の短縮
vShield – Patchless Protection・Virtual patching or a vendor patch? Choosing a remediation path in vRx（Vicarius）：メモリレベルの保護と、パッチ適用後に外す流れ
GRC Outlook Names Waratek AI-Generated Vulnerabilities Solution Provider of the Year 2026（Waratek）：JVM での RASP と、コード変更なしの仮想パッチ
A Detailed guide on Runtime Application Self Protection (RASP) Security・What is Web Application and API Protection (WAAP)（Levo.ai）：RASP のしくみと苦手なこと、WAAP の構成要素と TLS の終端

あとがき

調べてみると、仮想パッチという同じ言葉でも、IPS のシグネチャ、WAF のルール、ホストのメモリ保護、アプリの中の RASP と、止めている場所がかなり違いました。とくに HTTPS の通信では、どこで暗号がほどけるかによって効き目が大きく変わります。製品を比べるときは、まず「どの場所で、何を見て止めるのか」と「暗号化された中身を見られるのか」を確かめると整理しやすいと思います。