WSUS後継問題の見落とし 潜む更新管理のリスクと解決策

「WSUS の後継」を考えると見えてくる別の課題

3月に公開した前回記事「WSUS新規開発終了へ Heimdalパッチ・脆弱性管理でできること」では、想像以上に多くの方から反応やお問い合わせをいただきました。

前回は Intune など Microsoft 純正ツールからサードパーティ製パッチ管理ソリューションまで、WSUS の代替策を幅広く整理しました。
その中で、WSUS代替を検討する企業が見落としがちなのが「サードパーティ製アプリケーションのパッチ管理」という課題です。

“パッチ管理” と一口に言っても、OSのセキュリティパッチだけでなく、Zoom・Teams・Chrome・FireFoxなど日常業務で欠かせないアプリケーションの管理も重要な要素です。
しかし、IntuneなどのMicrosoft製ツールは基本的にMicrosoft製品の管理に特化しており、サードパーティ製アプリの管理には追加の仕組みが必要になります。
つまり、OSはしっかり管理されているのに、毎日使っているアプリケーションには古い脆弱性が残り続ける可能性があるのです。

そこで今回は、WSUS代替を検討する際にぜひ一緒に考えていただきたい「サードパーティ製アプリケーションのパッチ管理」について、実際のセキュリティリスク事例とともにご紹介していきます。

3つの事例から見る適用遅延リスク

社内ポリシーでWindows Updateを自動化しOSを常に最新に保っているのに、なぜセキュリティインシデントは起こり続けるのでしょうか?
実は、侵入を許してしまう隙間の多くはOSの外側、つまり私たちが日常的に使っているアプリケーションの脆弱性に潜んでいます。
脆弱性が公開され修正バージョンがリリースされても、実際にアプリケーションをバージョンアップするまでの「更新の隙間」を狙われ、深刻な被害につながることも少なくありません。
ここでは、アプリケーションの更新遅れが引き起こすセキュリティリスクを、3つのケースで振り返ります。

Zoom(CVE-2020-6110)

リモート会議が爆発的に増えていた 2020 年 春、Zoom クライアント(v4.6.10 以前)のチャット機能に致命的な欠陥が見つかりました1
それは、攻撃者が悪意のあるチャットメッセージを1通送るだけで、受信した人のパソコンに勝手にファイルを書き込むことができる欠陥でした。
パソコンを再起動したり特定のファイルを開いたりすると、攻撃者の仕込んだプログラムが自動的に実行されてしまう——そんな “パストラバーサル” といわれる脆弱性です。

脆弱性は 2 件ありました2

CVECVSS悪用される機能攻撃リスクのポイント
CVE-2020-61099.8GIFアニメーションチャットで送られたGIFファイルが自動的に展開される際、パソコンの重要な場所に悪意のあるファイルを置かれてしまう
CVE-2020-61108.8コード共有機能プログラムコードを共有する機能を悪用して、実行可能なプログラムを送り込まれる

どちらも Windows / macOS / Linux 共通で、CVSS スコアは 9.8 と 8.8。チャット経由で社外 PC にまで届く点が脅威でした。

Zoomは問題発覚後速やかに対応し、2020 年 4 月 21 日に修正版(v4.6.12)を公開、同月末には v5.0 への強制アップデートも実施しました3
しかし、組織全体でのパッチ適用完了まで時間がかかることが多く、攻撃者にとって長期間悪用可能な状態が続くリスクがありました。

WinRAR(CVE-2023-38831)

2023 年 10 月 18 日、Google の Threat Analysis Group(TAG)が「国家系ハッカーを含む複数の攻撃グループが悪用中」と警告したゼロデイ攻撃が CVE-2023-38831 です4
対象は Windows 定番の圧縮・解凍ソフト WinRAR(v6.23 未満)。恐ろしいのは、ZIPファイルを開いて画像をダブルクリックするという日常操作が、攻撃者にコード実行のチャンスを与えてしまう点でした5

技術的には、ZIPファイル内に

  • 無害なファイル mugai.jpg
  • まったく同じ名前のフォルダー mugai.jpg(中に実行ファイルを格納)

を同梱する “同名フォルダー” トリックで、
画像ファイルを開こうとクリックしたつもりが、同名フォルダーの中の実行ファイルが実行されてしまうという、WinRARの処理の隙を突いた仕組みです。

攻撃の流れは次のように推移しました。

  • 2023 年 4 月ごろ:早期悪用が始動 – 金融トレーダー向けフォーラムで偽装 ZIP が流通 6
  • 2023 年 8 月 2 日:WinRAR 6.23 を公開 – 脆弱性を修正した公式パッチが登場 7
  • 2023 年 10 月 18 日:Google TAG が再警告 – 「パッチは出たが、多くのユーザーがいまだ脆弱」

密かに悪用が始まってからパッチ公開まで約 3 か月。その後も”適用の遅れ”を狙う攻撃が続き、まさに ゼロデイ が Nデイ(エヌデイ) に姿を変えて攻撃が継続する典型例となりました。

Adobe Acrobat / Reader (CVE-2023-26369)

2023 年 9 月、Adobeが「限定的ながらすでに悪用を確認」と緊急警告を発したのがCVE-2023-26369です8
この脆弱性の恐ろしさは、PDFファイルを開くという日常的な動作だけで攻撃が成立してしまう点にあります。

技術的には「out-of-bounds write(境界外書き込み)」と呼ばれる脆弱性です。
悪意のあるPDFファイル内に埋め込まれた特殊なTrueTypeフォントが引き金となり、ファイルを開いた瞬間に、プログラムが想定していないメモリ領域まで攻撃者の任意データが上書きされ、結果として任意コードの実行が可能になってしまうのです。

PDFファイルは 請求書、契約書、プレゼン資料──取引先から送られてきたいつものような文書に見えるため、ユーザーは「いつものようにPDFを確認しただけ」で感染に気付かない恐れもあります。

Adobe は 2023 年 9 月 12 日に緊急パッチを公開しましたが9、企業現場では様々な運用上の事情からか、公開直後に全端末へ適用できないケースもあったとみられます。


これら 3 件に共通するのは、「修正パッチそのものは極めて早く提供されていた」 という点です。

  • Zoom と Adobe Acrobat / Reader は、脆弱性の公表と同時に公式アップデートが入手可能
  • WinRAR も、脆弱性が広く報じられた 2023 年 8 月時点では修正版 v6.23 が既にダウンロード可能

それにもかかわらず、パッチが「利用できる」ことと「実際に全端末へ適用される」ことのあいだには大きな隔たりがあります。
このギャップがある限り、パッチは公開直後から“適用可能”な状態であっても、実際に当たるまでの期間は大きなリスクを抱えたままになります。
ゼロデイ が Nデイ(エヌデイ) へと形を変え、攻撃者に繰り返し利用される余地が残るのはこのためです。

なぜパッチは当たらない?──“仕組み”が生む4つの空白ポイント

なぜ「利用できる」パッチが「実際に適用される」まで時間がかかるのでしょうか?
それは現在のパッチ管理の仕組み自体が、構造的に”遅れやすい”特徴を持っているからです。
ここでは “パッチが当たりにくい構造” を 4 つの観点から見ていきます。

更新チャネルの分断──OS とアプリは別ルート

まず第一に挙げられるのが、OSとアプリで更新経路が完全に別々になっているという点です。
WindowsのOSやOffice製品にはWSUSやIntuneなどの配信基盤がありますが、ChromeやZoom、Adobe Acrobatといったサードパーティ製アプリの多くはそれぞれのアップデーターに任されています。
この二重構造により「OS は最新でもアプリが1つ古い」状態が常態化します。
管理部門から “どの端末に何のバージョンが残っているか” が見えないと、緊急パッチが出ても初動が遅れがちです。

“ユーザー任せ”文化──自動更新を信用しすぎる

多くの企業では「Chrome も Zoom も勝手にアップデートするはず」 という前提で運用しています。
しかし現実には

  • テザリング接続時に自動更新を止めるポリシー
  • 社内アプリとの互換性テストが済むまでアップデート禁止のレジストリ設定
  • ユーザーが手動で “後で通知” を押し続ける

といった「想定外の停止要因」が常に存在し、“勝手に最新” は幻想になりがちです。

社外端末と帯域制限──“戻ってくるまで保留” 問題

更新配信の多くは、社内ネットワークに接続していることを前提としています。
しかし、現在ではテレワーク端末・出張用ノートPC・外部委託先のPCなど、社外に常駐するデバイスが当たり前のように業務に参加しています。
これらの端末は、「社内に戻ってくるまでアップデートが保留される」という構造になっていることも珍しくありません。

クロスプラットフォームへの対応困難

一部の開発チームではmacOS、業務システムの一部ではUbuntuが使われるようになり、管理すべきOSが複数化しています。
しかし、既存の更新管理ツールは Windowsを前提とした仕組みに偏っており、macOSやLinuxに対応できていないケースが多いのが実情です。
パッチ適用が「できない / していない」OSがあるというだけで、組織全体のセキュリティ強度は一気に下がります。


これらの要因に共通するのは、「誰かが悪いのではなく、仕組みそのものが”遅れを生む”ようにできている」という点です。

  • パッチが出てもバラバラな経路で届く
  • 届いても更新が実行される保証がない
  • 実行されても社外端末には反映されない
  • 反映されたとしても対応できないOSが残る

では、この構造的な問題をどう解決するか。
ここからは「パッチ適用を仕組みに変える」という根本的なアプローチについて見ていきます。

あなたの組織はどのレベル? ── パッチ管理成熟度で現状把握

前章で解決策の方向性を見てきましたが、具体的な対策を選ぶ前には、自社がどの立ち位置にいるのかを客観的に把握することが欠かせません。
パッチ管理の運用レベルは、そのまま組織のサイバーセキュリティ成熟度を映し出す鏡です。
以下の4つのレベルのうち、あなたの組織が最も近いのはどれでしょうか? じっくりと読み進めながら、自社の現状と照らし合わせてみてください。

レベル1:個人依存レベル

  • OSやアプリケーションの更新は、基本的に各ユーザーの判断に委ねている
  • 情報システム部門は、社内のPCにどんなサードパーティ製アプリがインストールされているかを正確に把握できていない
  • 脆弱性のニュースが出ても、「各自で対応してください」と呼びかける以上の具体的な対策は打てていない

レベル2:場当たり対応レベル

  • Windows UpdateはWSUS等で管理しているが、それ以外の管理は手つかず
  • WinRARやAcrobatなど、世間で大きな脆弱性が話題になった時だけ、慌てて手動で対象PCを調査し、個別に対応を依頼している
  • テレワーク中のPCや、開発部門が使うmacOS・Linuxは「管理対象外」として扱われることが多く、セキュリティホールになりがち

レベル3:部分的自動化レベル

  • OSのパッチ管理は、Intuneなどの仕組みで自動化されている
  • Adobe製品など、一部の主要なアプリについては専用の管理ツールで更新している
  • しかし、OSとアプリで管理ツールがバラバラなため、全体の脆弱性状況を横断して把握できず、レポート作成にも手間がかかる

レベル4:統合管理レベル

  • OSもサードパーティ製アプリも、WindowsもmacOSも、単一のコンソールで脆弱性を一元的に可視化・管理できている
  • 社内・社外の場所を問わず、あらかじめ定義したポリシーに基づいてパッチが自動で適用され、その結果もリアルタイムで把握できる
  • 監査に必要な「いつ、どの端末に、どのパッチが適用されたか」という証跡レポートも、いつでも数クリックで確認できる

もし、あなたの組織がレベル3以下に当てはまるなら、注意が必要です。
管理ツールが分断されていたり、手作業での対応が残っていたりする状態は、まさに第2章で見たような「パッチがあるのに適用が間に合わない」というインシデントの温床となります。

「自動で守る」という選択肢──パッチ適用を仕組みに変える

更新が間に合わずに被害が出てしまうという問題は、努力や注意だけではなかなか解決できません。
そこで浮かび上がってくる選択肢が「パッチ適用そのものを仕組みにしてしまう」という考え方です。
たとえば、Heimdal パッチ・脆弱性管理では、更新を自動で配信・適用できるように設計されています。手作業を可能な限りなくし、更新の「空白」をシステムで埋める構成です。
ここでは、その具体的な仕組みをいくつか紹介してみます。

OSもアプリも、ひとつのルールで更新する

Heimdalでは、WindowsやmacOS、UbuntuといったOSに加えて、業務でよく使われるアプリ(Chrome、Zoom、Adobe Acrobat/Reader など)も更新の対象になります。
対象アプリは350種類以上(2025年6月時点)あり、まとめてスキャン・適用が可能です。
つまり、これまで別々に管理されていたOSとサードパーティアプリの更新を、一つの画面で確認・管理することが可能になります。

タイミングは自由に決められる

「自動で当てる」と聞くと、すぐに全部当たってしまうのでは?と不安になる方もいるかもしれません。
Heimdalではそのあたりも柔軟で、「公開当日」「数日遅らせて」「指定の曜日に」など、アプリごとに適用タイミングを設定できます。
週末に当てたい、一部だけ先にテストしたい、といった運用にも対応できますし、万一不具合があったときには元のバージョンに戻すこともできます。

ネットにつながっていればどこでも適用される

テレワークや出張先の端末にパッチが当たらない、という問題もよくあります。
Heimdalはクラウド型のSaaSサービスなので、社内ネットワークに戻らなくても、インターネットにさえつながっていれば更新が適用されます。
専用サーバーやVPNを用意する必要はなく、社外のPCにも同じようにパッチを届けることができます。

ダッシュボードで“ちゃんと当たってる”か分かる

仕組み化すると、逆に「本当に当たったのか?」が見えづらくなることもあります。
Heimdalでは、Webブラウザーのダッシュボードから、未適用のパッチや適用履歴が端末ごとに確認でき、必要ならCSV形式で出力もできます。
またHeimdalで管理するアプリのバージョン適用履歴だけではなく、デバイスにインストールされている全てのサードパーティアプリケーション情報を一覧で確認することもできます。


手間を省く、という意味での自動化ももちろんありますが、それ以上に「遅れないようにする」ための自動化の仕組みです。
気づかないうちに攻撃の入り口が残っていたという事態を防ぐために、パッチ適用を「人に依存する運用」から「仕組みによる自動化」へ移行する考え方は、これからのセキュリティ対策の標準となるでしょう。

改善点を具体化する──チェックリストの活用

ここまで読んできて、「うちもパッチ運用に隙間があるかも…」と感じた方もいらっしゃるかもしれません。
先ほどは「あなたの組織はどのレベル? ── パッチ管理成熟度で現状把握」で自社のレベルをご確認いただきましたが、さらに具体的に「どの工程で何が足りていないのか」を詳しく洗い出してみることをお勧めします。

「パッチ管理プロセスチェックリスト」で体系的に現状確認

「パッチ管理プロセスチェックリスト」 は、企業のパッチ管理体制を以下 4 つのフェーズ・合計 25 項目でチェックできるチェックリストです。

  • 準備・計画フェーズ
  • パッチ実装プロセス
  • 展開・運用
  • 事後プロセス

このチェックリストを使うことで、「なんとなく大丈夫」だと思っていた管理体制の具体的な弱点が明確になり、優先して取り組むべき改善点が見えてきます。

▶ 「パッチ管理プロセスチェックリスト」無料ダウンロード

体系的な改善の第一歩として、ぜひチェックリストをご活用ください。

本記事はここまでとなります。
もし気になった点やご質問などあれば、お気軽にお問い合わせください。

  1. Zoom Client < 4.6.12 パストラバーサル | Tenable® , The Hacker News ↩︎
  2. NVD – CVE-2020-6109 , NVD – CVE-2020-6110 ↩︎
  3. Update Your Zoom Rooms for Security Enhancements & GCM Encryption Readiness | Zoom ↩︎
  4. Government-backed actors exploiting WinRAR vulnerability ↩︎
  5. NVD – CVE-2023-38831 , WinRAR < 6.23 RCE | Tenable® ↩︎
  6. CVE-2023-38831 zero-Day vulnerability in WinRAR | Group-IB Blog ↩︎
  7. WinRAR News: WinRAR 6.23 final released ↩︎
  8. NVD – CVE-2023-26369 , CVE-2023-26369: One-click PDF exploits , 0-days In-the-Wild ↩︎
  9. Adobe セキュリティ速報 , Acrobat-Acrobat Reader Release Notes ↩︎

こんな記事も読まれています

最新記事

おすすめ記事

  1. 特権アカウント管理の方法:パスワードを通知するか隠すか / 操作記録は必要か [PAM/PASM]

  2. ntopngによるマルウェア・ボットネット・ランサムウェアの発見と追跡

  3. 不正アクセスされていない?認証エラーログを可視化(平常時の確認) ~ syslog-ng Store Box (SSB)でリモートアクセスログを調査(その12)~

製品カテゴリー

その他の情報

TOP