結論：パッチ先送りは「業務を守る判断」ではなく「最大の侵入経路を開け続ける判断」である

VPN機器のパッチ適用が、「再起動で業務が止まる」「設定が壊れたら戻せない」「分かる担当がいない」という理由で先送りされる。だが警察庁が2026年4月に公表した統計では、ランサムウェアの感染経路は6割以上がVPN機器の脆弱性を突いた攻撃であり、パッチの先送りは、攻撃者が最も多く使う入口を自ら開け続けることを意味する。この失敗の本質は技術ではなく、「短い停止を受け入れる判断を誰も下せない」という意思決定の構造にある。

  • 警察庁統計（2026年4月公表）では、都内のランサムウェア被害は68件で過去最多、感染経路は6割以上がVPN機器の脆弱性を突いた攻撃、被害の過半数を中小企業が占める。
  • 先送りは怠慢ではなく、「確実に見える小さな停止」と「確率的で見えない大きな侵害」を天秤にかけた結果起きる、構造的な判断の歪みである。
  • 「再起動」「設定破損」「担当不在」には、それぞれ事前承認ルール・切り戻し手順・役割の明文化という対処がある。
  • 対処の骨格は、外部に面した機器の棚卸し→重要度判定→パッチ判断ルール（即時・計画・代替策）の三段階である。
  • 計画適用を成立させるのは、年間カレンダーで予約された「メンテナンス窓」である。窓がない組織では、すべてのパッチが「いつかやる」に分類される。

この連載「セキュリティ対策の失敗図鑑」は、対策が技術ではなく組織の意思決定でつまずく構造を一回ごとに分解している。第3回の本稿が扱うのは、製品を入れたのに運用が回らない失敗（第1回EDRを入れて「対策済み」と思い込む失敗）でも、リスク認知そのものが歪む失敗（第6回「うちは狙われない」という正常性バイアスの失敗）でもなく、リスクを認知していながらパッチ適用という行動だけが先送りされる意思決定構造である。外部公開システムの棚卸し手順自体はVPN認証回避の脆弱性への注意喚起と外部公開システムの棚卸しが詳しいが、本稿はその前段の「なぜ手順が実行されないのか」から出発し、先送りを断ち切る判断ルールとメンテナンス窓の作り方までを扱う。

なぜパッチは先送りされるのか——三つの「もっともらしい理由」を分解する

「再起動で業務が止まる」——停止コストは見えるが、侵害コストは見えない

VPN機器のファームウェア更新には再起動が伴うことが多く、その間はリモート接続や拠点間通信が止まる。この停止の影響は、誰の業務が止まり、どの顧客対応が遅れるかまで具体的に想像できる。一方、パッチを当てないことのコストは確率的で、明日問題が起きるとは限らない。確実に発生する小さな停止と、いつ起きるか分からない大きな侵害を天秤にかけると、人は前者を避ける方向に判断を寄せる。

こうして「今週は繁忙期だから」「月末処理が終わってから」が積み重なり、公表済みの脆弱性が長期間放置される。これは担当者の怠慢ではなく、停止コストだけが可視化された組織で起きる、ある意味で合理的な——しかし誤った——判断である。だからこそ対処は「意識向上」ではなく、判断の天秤そのものを作り替えることになる。

「設定が壊れるのが怖い」——切り戻し手順がないから踏み切れない

VPN機器の設定は、構築時の担当者やベンダーが作り込んだまま文書化されていないことが多い。更新で設定が初期化されたり挙動が変わったりしたとき、元に戻せる自信がなければ、更新は「触らぬ神に祟りなし」の対象になる。恐怖の正体は更新作業の難しさではなく、設定のバックアップと切り戻し手順が存在しないことである。

逆に言えば、更新前に設定をエクスポートし、戻せなかった場合の手順と判断期限を決めておけば、この恐怖の大半は解消できる。しかも放置期間が延びるほど一度に跨ぐバージョン差が大きくなり、さらに更新が怖くなる。先送りは先送り自体を強化する悪循環を持っている。

「担当がいない」——保守契約と社内責任の空白

情シス専任者がいない、あるいは一人情シスの企業では、VPN機器は「導入したベンダーが見てくれているはず」と思われがちである。だが保守契約の中身を確認すると、対象はハードウェア故障対応のみで、ファームウェア更新や脆弱性対応は含まれていない、ということが珍しくない。社内は「ベンダーの仕事」と思い、ベンダーは「契約外」と認識している。誰の仕事でもないタスクは、誰も実行しない。脆弱性対応には、情報を受け取る役、自社機器が該当するか確かめて適用可否を判断する役、実際に作業する役の三つがあり、この三役が決まっていないことが先送りの第三の構造であり、機器の存在自体が忘れられる温床にもなる。

データが示す帰結：侵入経路の最大派閥はVPN機器の脆弱性である

警察庁が2026年4月9日に公表した2025年のサイバー犯罪統計では、都内のランサムウェア被害は68件で過去最多を記録した。注目すべきは感染経路の内訳で、6割以上がVPN機器の脆弱性を突いた攻撃である。巧妙なフィッシングメールでも未知の攻撃手法でもなく、外部に面した機器の「直されていない既知の穴」が最大の入口になっている。さらに同統計では被害の過半数を中小企業が占める。攻撃者は企業の規模や知名度ではなく、パッチが当たっていない機器を機械的に探して侵入してくる。

裏返せば、VPN機器のパッチ適用は最も費用対効果の高い対策の一つである。中小企業のランサムウェア対策はVPN・リモートワーク経路から見直すで整理したとおり、高価な製品の導入より先に、入口となる経路の手当てが来る。また対象は法人向けのVPN専用機に限らない。NEC Aterm WGシリーズ脆弱性と中小企業ネットワークの対応指針で扱ったように、家庭向けルーターを拠点で業務利用しているケースでは、脆弱性公表時の対応がさらに漏れやすい。

先送りの帰結を停止時間で考えると判断は明確になる。パッチ適用で止まるのは事前に調整された短い時間だが、侵入を許せば全システムが復旧と調査が終わるまで計画外に止まり続ける。「業務が止まるから当てない」という判断は、避けようとした停止の比ではない停止を引き寄せる。

先送りを断ち切る実務手順：棚卸し→重要度判定→判断ルール

手順1：外部に面した機器を棚卸しする

まず「外部に面した機器が何台あり、誰が管理しているか」を一覧にする。対象はVPN機器、ルーター、ファイアウォール、リモートデスクトップの入口、外部公開しているWebサーバや管理画面である。台帳の最低限の項目は、機器名・型番、ファームウェアのバージョン、設置場所、管理責任者、保守契約の範囲、最終更新日。最も重要なのは項目の網羅性ではなく、台帳の所有者を一人決めることである。所有者のいない台帳は作った瞬間から古び、忘れられた機器が再び生まれる。

手順2：機器ごとに重要度を判定する

すべての機器を同じ優先度で扱おうとすると、結局どれも進まない。判定軸は、外部から直接到達できるか、侵入された場合に社内のどこまで到達できるか、止めた場合の業務影響はどの程度か、の三つで足りる。外部に直接面し社内全体への入口になるVPN機器は、ほぼ例外なく最上位に置かれる。この判定があるからこそ、次の判断ルールで「どの機器なら即時に止めてでも当てるか」を事前に決められる。

手順3：パッチ判断ルールを「即時・計画・代替策」の三区分で決める

脆弱性情報が出るたびにゼロから議論していては、判断は毎回「とりあえず様子見」に流れる。平時に次の三区分を決めておく。

区分発動する条件対応の内容業務停止との折り合い
即時適用悪用確認済み、または公的機関の注意喚起に自社の機器・バージョンが該当業務調整より適用を優先し、臨時の停止時間を確保して当てる「この条件なら止めてよい」と経営層が事前承認し、都度の稟議をなくす
計画適用該当はするが悪用未確認で、深刻度が中程度にとどまる次回のメンテナンス窓で適用する定例の窓に乗せるため調整コストが小さい
代替策即時も計画も間に合わない、または保守切れ等で更新が当面できない該当機能の無効化、アクセス元の制限、監視強化、機器更改の計画化「当てない」ではなく「塞ぎ方を変える」判断として記録に残す

この三区分の効用は、「業務が止まるから」の位置づけを変えることにある。基準が事前にあれば、業務影響は「即時適用を覆す拒否権」ではなく「計画適用の日程をどう組むか」という調整事項に変わる。判断の場と基準がないことこそが先送りの正体である。

メンテナンス窓の作り方——「いつかやる」を「この日にやる」へ変える

計画適用の受け皿になるのがメンテナンス窓である。要点は四つ。第一に、四半期に一度など定例の枠を年初に年間カレンダーへ確保し、業務部門へ先に通知する。「繁忙期だから」という衝突は枠を決めた時点で解消されている。第二に、設定のバックアップ→更新→動作確認→問題時の切り戻し、という手順書を機器ごとに用意し、窓の中の作業を定型化する。第三に、「いつまでに正常確認できなければ戻す」という判断期限を決めておく。第四に、窓を使わなかった場合も「適用すべきものがなかった」のか「あったのに見送った」のかを区別して記録し、先送りの再発を可視化する。

点検チェックリスト：自社の「先送り構造」を確認する

以下に一つでも「いいえ」があれば、パッチが先送りされる構造が自社に残っている。

  • 外部に面した機器の台帳があり、台帳の所有者（責任者）が決まっているか。
  • 各機器のファームウェアのバージョンと最終更新日を即答できるか。
  • 保守契約にファームウェア更新・脆弱性対応の作業が含まれるか、契約書で確認したか。
  • 脆弱性情報を受け取る担当と、判断する担当、作業する担当が決まっているか。
  • 即時・計画・代替策の判断基準が文書化され、即時適用時の業務停止を経営層が事前承認しているか。
  • メンテナンス窓が年間カレンダーで確保され、業務部門に周知されているか。
  • 設定のバックアップと切り戻し手順が文書化され、一度は実際に試したか。
  • 保守切れ・更新提供が終了した機器が放置されていないか（更改計画があるか）。

台帳づくりと判断基準の文書化は自社で着手できる。一方、「存在を忘れていた機器」や「外部からどう見えているか」は、内側からの点検では原理的に見つけにくい。攻撃者と同じ視点で自社の入口を洗い出す脆弱性診断を組み合わせると、棚卸しの漏れそのものを潰せる。

関連記事

よくある質問

Q1. パッチ適用で本当に業務が止まる場合は、どう判断すればよいか。

止めるかどうかを都度議論するのではなく、止める条件を事前に決めておくのが答えである。悪用が確認された脆弱性や公的機関の注意喚起に自社機器が該当する場合は即時適用、それ以外は次のメンテナンス窓で計画適用と区分する。即時適用時の短い停止は経営層が事前承認し、現場が稟議で止まらないようにする。侵入を許した場合の停止は、計画停止とは比較にならない規模になる。

Q2. 設定が壊れて戻せなくなるのが怖い。何を準備すれば更新に踏み切れるか。

準備は三つである。更新前に設定をエクスポートして保管すること、旧バージョンと設定へ戻す切り戻し手順を機器ごとに文書化すること、「いつまでに正常確認できなければ戻す」という判断期限を決めておくことである。この三つが揃えば、更新は「失敗できない賭け」ではなく「戻れる作業」に変わる。放置が長引くほど一度に跨ぐバージョン差は大きくなり、かえって危険になる。

Q3. 情シス担当がいない会社では、誰がパッチ適用を担えばよいか。

まず保守契約を確認し、ファームウェア更新と脆弱性対応が契約範囲に入っているかを確かめる。入っていなければ、契約の拡張か外部のセキュリティ事業者への委託を検討する。社内側にも、脆弱性情報を受け取りベンダーへ対応を指示する窓口役は最低一人必要である。「ベンダーが見てくれているはず」という思い込みと「契約外」という認識の空白こそが、先送りの典型的な温床になる。

Q4. すべての脆弱性に即時対応するのは現実的に無理ではないか。

そのとおりで、全件即時対応は前提にしなくてよい。だからこそ機器の重要度判定と、即時・計画・代替策の三区分が要る。外部に直接面し悪用が確認されているものだけを即時とし、それ以外は定例のメンテナンス窓に乗せれば対応負荷は平準化できる。適用できない機器には機能の無効化やアクセス元制限などの代替策を講じ、「塞ぎ方を変えた」という記録を残すことが重要である。

VPN機器のパッチ先送りは、台帳・判断基準・メンテナンス窓という三つの仕組みで断ち切れる。自社の外部に面した機器がいま何台あり、どこに直されていない穴が残っているかを攻撃者の視点で確かめたい場合は、無料相談から、脆弱性診断と攻撃面の棚卸しについて現状の機器構成を持ち込んで相談していただきたい。

出典