アプリケーションのパッチを永久に排除するには【トゥモロー・ネット テックブログ】

重大なアプリケーションの脆弱性は依然として増加傾向

企業は、Windows デスクトップアプリケーションのアップデートを管理することに関して頭を悩ませています。脆弱性の増加に伴って、アプリケーションの更新はこれまで以上に頻繁に行われています。The Stack のレポートによると、重大な脆弱性が前年比 59%増という大幅な増加を記録した 2022 年に続き、2023 年には脆弱性の数が 64%も増加しました（Google、2024 年）。サイバー犯罪集団は、脆弱なアプリケーションを持つ企業をかつてないほど巧妙にターゲットにし、公開から悪用されるまでの日数は平均で7日以内となっています。

実際、NCC Group のデータによると、2023 年 9 月だけで 514 件のランサムウェア攻撃があり、これまでの最高であった 2023 年 7 月の 502 件を上回りました。 Gartner® Accelerate Windows and Third-Party Application Patching によると、「14日以内にパッチが適用されたデバイスは60%未満で、ほとんどの組織では90%のパッチ適用が完了するまでに 30日以上かかっている」と推定しています。一方、 ベンダー側は、脆弱性に迅速にパッチを適用することで対応しています。PC World のレポートによると、Google は更新頻度を高め、毎週マイナーアップデートをリリースしています。

顧客がサイバー犯罪集団の先を越すには、ベンダーがアプリケーションのパッチを迅速に提供する必要がありますが、InfoSecInstitute によると、ITチームが脆弱性のあるアプリケーションのパッチをリリースするのには平均で 38 日もかかることがわかっています。また、大規模な悪用につながる脆弱性がニュースで報じられた場合、通常 38 日よりも早くパッチが適用されます。しかしこれは、脆弱性について大きく報じない限り対策まで時間がかかってしまうことを示す一例です。

とはいえ、企業の IT チームには、Windows デスクトップ環境全体にリリースされた個々のパッチを管理する人材も時間もないことは明らかです。注目度の高い脆弱性のパッチ適用に全力を注いでいる間にも、環境内のマシンには脆弱性を持つ他のアプリケーションが無数に存在しています。例えば4 人のチームが 1,000個のアプリケーションを使用している場合、そのうちのわずか 2％のアプリケーションにアップデートが適用されたとしても 、チームがタイムリーに検査、パッケージ化、展開することは不可能です。知らず知らずのうちに、企業資産や顧客データを危険にさらしている可能性があります。

IT 部門はアプリケーション更新の作業負荷にいかに対処すべきか？

膨大な量のアプリケーション更新を管理することは、エンタープライズアーキテクトにとって非常に難しい問題です。企業はアプリケーションの自動更新を有効にして、アプリケーションが自動的に更新されるようにしているのでしょうか？最も簡単な方法のように思えるかもしれませんが、実はアプリケーションによっては自動更新機能すらありません。自動更新機能があるアプリケーションのうち、いくつのアプリケーションに自動更新を許可しますか？ほんの一握りのビジネスクリティカルなアプリケーションだけでしょうか？その他のアプリケーションはどうしますか？このトピックに関しては、考慮すべき領域が非常に多くあります。本来はどのアプリケーションにも脆弱性が存在する可能性があるので、すべてのアプリケーションを常に最新の状態に保つ必要があります。exe や msi、あるいは特定のレイヤー化技術など、従来のインストールパッケージを使用していると、アプリケーションのファイルやコンポーネントが、マシンやネットワーク上で公開され、サイバー犯罪者に悪用される可能性があります。

昨年のLog4Shellの脆弱性が良い例です。一見すると、EUCエンジニアは「そんな名前のものは展開していないので問題ない」と考えるかもしれません。しかし、多くのベンダーがログ記録のために log4j2 を製品に組み込んでいます。では1,000個のアプリケーションがある場合、それらがlog4j2を使用しているかどうかをどのように判断すればよいでしょうか。最終的に、企業内のどのアプリケーションでlog4j2を使用しているかが判明したとしても、脆弱性を軽減するために、いかに迅速にパッチを適用することができるでしょうか？

その他の一般的な攻撃ベクトルには、共通の共有ランタイム、フレームワーク、プラットフォームが含まれます。Libwebpは最近、Google が深刻度10段階中10という稀な脆弱性を修正したことで話題になりました。Libwebpは、いくつかのアプリケーションで使用されている一般的なライブラリです。多くのアプリケーションにブラウザが埋め込まれているため、このようなライブラリが組織内で使用されていることに気づかないかもしれません。また、.NET 開発者に人気のあるDevExpressにも、脆弱性がいくつか見つかりました。そのコンポーネントはエンタープライズアプリケーションで使用されている可能性がありますが、使用されていることに気づかない場合があります。ベンダーはパッチをリリースしても、詳細を調べない限り、パッチの重要性に気づかない可能性があります。

つまり、本来はアプリケーションの更新を常に受け入れるべきなのです。しかし必要なすべての更新をパッケージ化して展開するのに十分な人員がいないことが課題なのです。また、環境に導入されているすべてのアプリケーションと、それらが活用する可能性のあるものとないものについて、詳しく知るための十分なリソースがないことも確かです。企業のチームが、すべてのアプリケーションの更新やベンダーのアドバイスを把握し続けることは不可能です。また、情報セキュリティチームも、環境に展開されているアプリケーションにどのような一般的なライブラリやプラットフォームが組み込まれているかを知らない可能性があります。自動更新を許可することは、サイバー攻撃などのリスクに備えるひとつの手段なのです。

App-V の終焉に対する真に長期的な解決策

マイクロソフトのApp-V に依存していた金融機関にとって、Numecentのテクノロジーは App-V のサポート終了に対応するための将来を見据えた複数の選択肢（英語版）を提供します。クラウドベースのコンテナ管理プラットフォームである Cloudpager は、既存の App-V パッケージをサポートし、App-V のサポート期間（2026 年 4 月頃）を超えて稼働するよう自動的に最適化します。これにより、既存のパッケージの寿命を延ばすと同時に、その過程で最新のコンテナ・オーケストレーション機能を即座に得ることができます。

自動最適化はCloudpager の全顧客が利用可能ですが、多くの顧客は新しいソリューションを導入する際に、アプリケーション仮想化に対して全く新しいアプローチを取る場合が多いです。App-V でパッケージ化できるアプリケーションはすべて Cloudpaging で仮想化できます。もちろん、アプリケーションの再パッケージ化を待つのではなく、Cloudpagerの優れた点は、再パッケージ化を行っている間も、既存のApp-Vパッケージを最適化またはネイティブ形式で継続的に展開できることです。これにより、ソリューション間の移行中に最新のアプリケーションコンテナ管理機能を即座に利用することができます。

アプリケーションのパッチ適用とは、更新によるマシンの故障リスクより安全性を重視するということ

どんなアプリケーションの更新でも、一部（またはすべて）のマシンで何かが壊れ、ビジネスに重大な支障が生じる可能性があります。さらに、ベンダーのサプライチェーンプロセスに左右されることになります。自動更新を受け入れていると、マシンがコンプライアンスに準拠しているかどうか、正常にアップデートされているかどうか、ほとんどわからないこともあります。サードパーティの製品を使ってアプリケーションパッチが利用可能な段階になったときに適用する場合でも、そのツールに左右されることになります。このアプローチでは、exeやmsiなどの古いパッケージ形式の問題がしばしば発生し、アプリケーションの競合、アンインストールの失敗、インストールエラー、マシン単位のインストールによるセキュリティリスク（ネットワーク上で実行されているすべてのユーザーとプロセスにアプリケーションコンポーネントが公開される）などの問題が発生します。

従来の導入ツールではエンタープライズ規模のアプリケーションのパッチ適用に対応できない

残念ながら、従来の導入ツールは、クラウドでホストされている仮想デスクトップからリモートの物理エンドポイントまで、あらゆるものが含まれるエンタープライズ規模のアプリケーションのパッチ適用には対応していません。これらのツールは本来、企業ネットワーク上のデバイスを管理するために設計されました。クライアントデバイス上で仮想プライベートネットワーク（VPN）と共にこれらのツールを使い続けている組織もありますが、これは理想的とは程遠く、ネットワークの飽和によって従業員がネットワークの切断を経験すると、フラストレーションの原因となり得ます。アプリケーションは、従業員が VPN に接続した直後（多くの場合、朝のログインの集中）に 導入される傾向があるため、VPN 経由で頻繁にアプリケーションのアップデートを導入することは避けることをお勧めします。

幸いなことに、クラウドネイティブで、ファイアウォール構成を最小限に抑えながら、あらゆるデバイス、あらゆるネットワークにアプリケーションを展開するのに最適な、最新の導入ソリューションが次々と登場しています。しかし、最新の導入ソリューションがすべて同じというわけではありません。柔軟なスケールや、場所を問わずあらゆるデバイスにアプリケーションを展開できるといったクラウドの利点と引き換えに、パフォーマンスが低下する場合があります。ソリューションによっては、アプリケーションの展開に 30 分から 24 時間かかるものもあります。これは、アプリケーションの更新を展開する際には好ましくなく、ビジネスクリティカルなアプリケーションにパッチを適用する場合は、絶対に受け入れられません。

コンテナでアプリケーションをあらかじめ保護

企業はデスクトップのセキュリティを、これまでとは違った視点から見る必要があります。IT チームは、Windows OSのパッチ管理に多くの時間と労力を費やしています。プロセスレベルでの最小権限アクセス管理、セキュリティ評価のための初期スキャンと機械学習のためのサンドボックスプロセス、Configuration Manager や Intune のような既存ツールへの特定のアプリケーションの自動発行、パスワード管理などを確立するための高度なセキュリティツールはたくさんあります。しかし、個々のアプリケーションやアプリケーション資産の全体像は、見過ごされがちです。

アプリケーションは、企業の業務効率と従業員のデジタル体験に欠かせない要素です。最新の Windows OSを搭載した高性能なデスクトップをユーザーに提供しても、アプリケーションがなければ、生産性は向上しません。アップデートによってアプリケーションが壊れると、それらのアプリケーションに依存している従業員の生産性が低下します。IT 部門が何時間も何日もかけて適切に実行されていないアプリケーションのパッチ適用をロールバックしている間、従業員は仕事を進めることができません。サポートチームや現場の技術者が、アプリケーションの問題を特定できないためにデスクトップの再イメージングを行っている場合、従業員の生産性は高まりません。システム停止を引き起こす可能性があるのは、新しいアプリケーションの導入やアップデートの導入だけではありません。アプリケーションのパッケージ化が不十分だと、Windowsの腐敗、アプリケーションの競合、アプリケーションのアンインストールの失敗、アプリケーションの起動時間やログインの遅延によるユーザーエクスペリエンスの低下につながる可能性があります。

アプリケーションの問題を特定して修復するのは難しく、選択したIT サービス管理製品で正確に追跡できない可能性があります。現在のアプリケーション管理ツールや方法にどれだけの時間と費用をかけているかを、大幅に過小評価している可能性があります。多くの企業にとって、これらの問題は千差万別です。コンテナは、アプリケーションが悪意のあるユーザーやプロセスにさらされるのを防いだり、アプリケーションの問題を処理したりするための最良のソリューションです。

コンテナ内でアプリケーションを実行すると、コンテナセッション内のアプリケーショ ンやユーザープロセスが実行できることを詳細に制御できます。たとえば、コンテナ空間で実行中のユーザーやプロセスが、コンテナ内のデータをローカルマシンやコンテナ外にコピーするのを防ぐことができます。

コンテナは、小さな単独の仮想マシンのように設計されています。要するに、すでに使っているサンドボックス技術のようなものですが、より俊敏で、すべてのアプリケーションを包含します。デスクトップ上で実行されている単独のVM のように動作することで、アプリケーションが他のアプリケーションに必要なファイルを削除したり、削除後にファイルが残ったり、 アプリケーションの競合が発生したり、インストール関連の再起動が発生したり、他のアプリケーションパッケージ形式で発生するその他の多くの一般的な問題が発生したりすることがなくなります。

Dockerなどの一般的なコンテナ形式を使用したことがあれば、堅牢で拡張性の高い体験を提供するという点で、コンテナがいかに強力であるかをすでにご存知でしょう。Dockerを使えば、新しいユーザーがオンラインになったときの需要に合わせて、追加のアプリケーションサービスをシームレスに拡張できます。これが可能なのは、コンテナが軽量でポータブルだからです。Dockerコンテナにより、企業のインフラチームは、新しいホストの構築、新しいデータベースインスタンスの構築、新しい仮想マシンの構築などの時代遅れのニーズから脱却することができるようになりました。

コンテナは Windowsデスクトップにも拡張性と移植性の利点をもたらします。デスクトップチームはコンテナを使うことで、どのWindows デスクトップにもすべてのアプリケーションを動的に展開することができます。デスクトップアプリケーション用のコンテナも、IT 部門がアプリケーションの更新を迅速に展開したり、アプリケーションの更新を一瞬で以前の状態にロールバックしたりすることを可能にすることで、柔軟性と回復力も提供します。

Docker のもう一つの利点は、利用可能なコマンドの包括的なリストを使用した、コンテナの作成、更新、管理を自動化が簡単に実行できるところです。もしデスクトップアプリケーションに同じような自動化プロセスを導入できれば、アプリケーションの更新が利用可能になると同時に処理できるようになり、更新の所要時間が 38 日から 1～2 日に短縮されます。もちろん、考慮すべきもう1つの側面は、コンテナオーケストレーションです。誰かがオンデマンドでコマンドを実行してコンテナを管理・更新することは現実的ではありません。アプリケーション管理を容易にするコンテナオーケストレーション製品は、いかなるIT 管理者にとっても利点が多い製品と言えます。

コンテナによるモダナイゼーションでアプリケーションのパッチ適用を排除

ますます頻繁になるアプリケーションの更新に対して企業は積極的に対策を講じる必要があります。アプリケーションをコンテナ化し、プロセスを自動化することで、企業のセキュリティを確保することが、これからの主流となっていくでしょう。そうです、アプリケーションのパッチ適用を完全に廃止する時が来たのです。

コンテナは、従来のexeやmsiパッケージよりも、不良パッケージやパッチ適用の失敗による中断の可能性を減らすように設計されているため、タイムリーなアプリケーション更新に適しています。また、以前の状態に迅速にロールバックできるため、不良パッチによるダウンタイムを最小限に抑えることができます。

コンテナオーケストレーションは、コンテナを迅速に展開できるため、最新かつ最適な管理方法でもあります。一方、他の最新の展開ソリューションでは、従来のパッケージタイプの処理方法や、展開プロセスを管理に必要なタイミング間隔が原因で速度が低下します。Windows 11の登場が目前に迫っている今、今後のアプリケーションの扱い方を検討する時期がきています。これまで同様、アプリケーションのパッチで対応を続けますか？それとも、コンテナを採用しますか？今が決断の時です。

製品についてより詳しく知りたい方は、下記より是非お問合せください。
https://www.tomorrow-net.co.jp/contact/

本ブログは下記の英語ブログの抄訳です。
https://www.numecent.com/2024/06/20/eliminate-application-patching-for-good/

関連記事

銀行、金融機関がNumecent を採用する理由
なぜWindows 11 の普及が遅れているのか？
Windows デスクトップ向けクラウドネイティブ・アプリケーションコンテナ管理プラットフォーム Numecent Cloudpager
パッケージ化が複雑なアプリケーションを Cloudpagingでパッケージ化する方法
Windows 11のマイグレーションを成功に導くためには？

この記事の筆者