JP5592828B2 - パッチ影響解析装置、方法及びプログラム - Google Patents

Description

本発明はパッチ影響解析に関し、特に、アプリケーション内の機能の単位でパッチ適用による影響の判定を行うことのできるパッチ影響解析装置、方法及びプログラムに関する。

企業等に設置される大量のコンピュータ装置を効率的に運用するために、コンピュータ装置に対するパッチ（ＯＳカーネル、ドライバ、共有ライブラリその他ソフトウェア等の更新ソフトウェア）管理の効率化は重要な課題である。コンピュータ装置のＯＳ（オペレーティング・システム）等のソフトウェアメーカは、定期的に自社製品向けにパッチをリリースしている。コンピュータ装置の運用者は、ソフトウェアメーカがリリースするパッチについて、管理対象の各コンピュータ装置における必要性と、適用影響や副次影響を事前に解析し、適用可否や適用時期を判断する必要があるため、これまで、このような解析・判断に要する工数が運用管理の現場で課題となっている。

このような問題を解決するために、従来からパッチの影響の解析作業を半自動化し運用者を支援する影響解析ソフトウェアが知られている（例えば、以下の非特許文献１、２参照）。特に動的相互依存性解析も含めた高度な影響解析を実現するソフトウェアが提供され始めており、その解析範囲の広さから今後有望な手段である。ここで動的相互依存性解析とは、管理対象コンピュータ装置上で動作するアプリケーションが稼働中において実際に操作したファイル、呼び出したライブラリ等を特定する情報（以下、動的相互依存性情報という）を抽出し、この抽出した動的相互依存性情報に基づいて、特定のパッチが管理対象コンピュータ装置に与える影響を解析する手法である。尚、相互依存性情報には前記動的相互依存性情報の他、運用者やソフトウェアメーカが作成する静的な相互依存性情報がある。

従来の相互依存性解析作業は、パッチ影響解析の対象となるコンピュータ装置（解析対象のコンピュータ装置）内に、パッチ影響解析に必要な情報（動的相互依存性情報）を収集するデータコレクタ（以下、ＤＣという）と呼ばれるソフトウェアをインストールしておき、各解析対象のコンピュータ装置が稼動し使用されている時に、ＤＣが動的相互依存性情報を収集する。そして、所定のタイミングにおいて、収集した動的相互依存性情報を影響解析サーバへ送信する。これを受けて、影響解析サーバ上の影響解析マネージャは、多数の解析対象のコンピュータ装置から、動的相互依存性情報を受信し、適用しようとするパッチの影響度を解析して表示する。このとき、運用者はＤＣに対して必要な設定情報（情報収集の開始・終了時間等）を指定し、影響解析サーバから解析対象のコンピュータ装置に対してこのＤＣを遠隔操作でインストールするのが一般的である。

サーバシステム(例えば、 webアプリケーションサーバ、メールサーバ等)上のソフトウェアプログラムに対し、ベンダからバグやセキュリティホールへの対策としてソフトウェア更新（パッチ）が相次いで提供される。しかしパッチ適用後、他のプログラムに新たなバグが生じるなど、管理者の予期しない副次的な影響が現れ、システム障害に陥る可能性がある。このため、管理者は副次的な影響の有無を事前試験により検証しなければならないが、サーバシステム全体の試験には膨大な工数を要してしまう。そこで、試験対象を極力絞り込むことで試験工数を削減するパッチ適用影響診断システムが用いられる。

これまで、各アプリケーションについてパッチ影響の有無を診断することで、パッチ試験対象をアプリケーション単位に絞り込み、テスト工数を削減するパッチ適用影響診断システムがある(例えば、以下の特許文献1を参照)。

特開2010-152572号公報(コンピュータ装置、情報収集方法及び情報収集プログラム)

John Dunagan, et al.,"Towards a self-managing software patching process using black-box persistent-state manifests," MSR-TR-2004-23, ftp://ftp.research.microsoft.com/pub/tr/TR-2004-23.pdf, March 2004. "Windows(登録商標) Application Compatibility", http://technet.microsoft.com/en-us/desktopdeployment/bb414773.aspx, March 2004.

しかしながら、webアプリケーションサーバ等でアプリケーションが個別機能(例えば、情報の検索、整形表示等)を実現するために、機能に対応する多数の機能モジュール(例えば、web画面生成スクリプト)等を呼び出している場合がある。この場合、アプリケーション単位の絞り込みでは、試験対象の絞り込み粒度が粗い(試験対象が一部絞り込めていない)という課題があった。

本発明の目的は、上記の従来技術の課題を解決し、パッチを適用した場合の影響をアプリケーション内の機能単位で判定するパッチ影響解析装置、方法及びプログラムを提供することにある。

上記の目的を達成するため、本発明は、試験系コンピュータ装置に対する所定のパッチの適用による、前記試験系コンピュータ装置にて実行される所定のアプリケーションに対する影響を、該所定のアプリケーション内の機能単位で前記所定のパッチの適用の前に検出するパッチ影響解析装置であって、前記試験系コンピュータ装置の稼働中の所定期間に、該試験系コンピュータ装置にて各プログラムが実行されるのに伴って発生するアクセス関係をアクセス元、アクセス先及び当該アクセスの発生時刻と対応づけて動的相互依存情報として、前記試験系コンピュータ装置より取得する動的相互依存情報取得部と、前記所定のパッチの適用による影響を判定するパッチ影響判定部とを備え、前記試験系コンピュータ装置の稼働中の前記所定期間内に、該試験系コンピュータ装置にて前記所定のアプリケーションが起動された後の所定時刻に該アプリケーション内の所定の試験操作が実行された後に前記パッチ影響判定部が、前記動的相互依存情報より、前記所定時刻の所定の近傍時刻範囲内に存在するアクセス元及びアクセス先の情報を抽出し、該アクセス元又はアクセス先のうち少なくとも一方が前記所定のパッチの適用による置換対象である場合に、前記所定の試験操作における当該アクセス関係を前記所定のパッチの適用による影響有りと判定することを特徴とする。

また本発明は、試験系コンピュータ装置に対する所定のパッチの適用による、前記試験系コンピュータ装置にて実行される所定のアプリケーションに対する影響を、該所定のアプリケーション内の機能単位で前記所定のパッチの適用の前に検出するパッチ影響解析方法であって、前記試験系コンピュータ装置の稼働中の所定期間に、該試験系コンピュータ装置にて各プログラムが実行されるのに伴って発生するアクセス関係をアクセス元、アクセス先及び当該アクセスの発生時刻と対応づけて動的相互依存情報として、前記試験系コンピュータ装置より取得する動的相互依存情報取得ステップと、前記試験系コンピュータ装置の稼働中の前記所定期間内に、該試験系コンピュータ装置にて前記所定のアプリケーションを起動した後の所定時刻に該アプリケーション内の所定の試験操作を実行する試験操作実行ステップと、前記動的相互依存情報より、前記所定時刻の所定の近傍時刻範囲内に存在するアクセス元及びアクセス先の情報を抽出し、該アクセス元又はアクセス先のうち少なくとも一方が前記所定のパッチの適用による置換対象である場合に、前記所定の試験操作における当該アクセス関係を前記所定のパッチの適用による影響有りと判定するパッチ影響判定ステップとを備えることを特徴とする。

さらに本発明は、試験系コンピュータ装置に対する所定のパッチの適用による、前記試験系コンピュータ装置にて実行される所定のアプリケーションに対する影響を、該所定のアプリケーション内の機能単位で前記所定のパッチの適用の前に検出するパッチ影響解析プログラムであって、前記試験系コンピュータ装置の稼働中の所定期間に、該試験系コンピュータ装置にて各プログラムが実行されるのに伴って発生するアクセス関係をアクセス元、アクセス先及び当該アクセスの発生時刻と対応づけて動的相互依存情報として、前記試験系コンピュータ装置より取得する動的相互依存情報取得ステップと、前記所定のパッチの適用による影響を判定するパッチ影響判定ステップとをコンピュータに実行させることで当該コンピュータをパッチ影響解析装置として機能させ、前記試験系コンピュータ装置の稼働中の前記所定期間内に、該試験系コンピュータ装置にて前記所定のアプリケーションが起動された後の所定時刻に該アプリケーション内の所定の試験操作が実行された後に前記パッチ影響判定ステップにおいて、前記動的相互依存情報より、前記所定時刻の所定の近傍時刻範囲内に存在するアクセス元及びアクセス先の情報を抽出し、該アクセス元又はアクセス先のうち少なくとも一方が前記所定のパッチの適用による置換対象である場合に、前記所定の試験操作における当該アクセス関係を前記所定のパッチの適用による影響有りと判定することを特徴とする。

本発明によれば、試験系コンピュータ装置に対してパッチを適用した場合の影響を、該試験系コンピュータ装置にて実行されるアプリケーション内で実現される機能の単位で判定することが可能となる。

本発明のシステムを示す図である。 パッチ影響解析の概要を説明する図である。 試験系コンピュータ装置との関係を含めて描いたパッチ影響解析装置の機能ブロック図である。 パッチ影響解析方法のフローチャートである。 パッチ影響判定方法のフローチャートである。 図5のフローに従って順次処理されるデータの例を示す図である。 (1)ライブラリアクセス記録部による記録の例と、(2)ファイルアクセス記録部による記録の例と、(3)パス解決部による記録の例とを示す図である。

以下、図面を参照して本発明を詳細に説明する。図1に、本発明にて想定するシステムの一例を示す。パッチ影響解析装置1は、ネットワークNを介して試験系コンピュータ装置2より必要な情報を取得して、当該試験系コンピュータ装置2における所定のパッチの適用による影響を解析する。

なお、本発明において試験系コンピュータ装置2とは、同じくネットワークN上に存在するコンピュータ装置3に対し、動作確認等を目的として用意された複製システムを言う。一般に現場で例えばサーバ等として稼働中のコンピュータ装置3で直接確認を行うのは様々な問題が生じるので、パッチ適用の影響を確認するため、試験系コンピュータ装置2で適用試験を行う。

なお、本発明はパッチ影響解析装置1と試験系コンピュータ装置2とが、図1とは異なり、ネットワークNを介してオンラインで互いにアクセス可能な状況ではない場合、すなわちオフラインの関係にある場合も適用可能である。この場合はオンラインにおいてパッチ影響解析装置1と試験系コンピュータ装置2とでやりとりするデータを、人手により物理メディアを介するなどしてやりとりすればよい。しかし、本発明は基本的には、図1のようなオンラインの場合を想定して説明するものとする。

図2は本発明におけるパッチ影響解析の概要を示す図である。パッチ影響解析装置1による解析対象である試験系コンピュータ装置2では、パッチ影響を機能モジュール単位等の、細かい粒度で確認する対象となる所定のアプリケーションA1が起動されている。例えば、試験系コンピュータ装置2がショッピング情報提供サーバとしてのコンピュータ装置3の試験用に用意された装置であって、当該アプリケーションA1は例えば、図示されているように、地図アプリケーションであってもよい。そして、アプリケーションA1内において、所定の試験操作O1を実行する。試験操作O1は例えば、図2ではクリック動作を想定した人差し指を指した手として模式的に示されているように、地図アプリケーションA1における地点登録・呼び出しなどの操作であってもよい。

試験操作O1（及びO1により生ずる動作）の例としては、以下(1)~(3)などが挙げられる。
(1)上記例のような、管理者や利用者による何らかの操作入力に応じた動作(例えば、web GUI上のクリック操作に対する新たな描画など)
(2)他のコンピュータ装置からのシグナルを受けて発動する動作(例えば、メールサーバプログラムに新たなメールが着信した場合の配信・転送動作など)
(3)定期的・自動的に発動される動作(例えば、定期的に他の装置の死活状態や、回線開通状態を監視する機能など)

このようにアプリケーションA1において所定の試験操作O1を実行することにより、一般にA1の内部処理によって、O1に対応する動作として、複数のプログラムP1、P2、P3…等が実行される。各プログラムはさらに、機能モジュール、オブジェクト、ライブラリ、設定データなど(一般にファイル)を呼び出す、あるいは読み込む。例えばプログラムP1はファイルF11及びF12を呼び出し、プログラムP2はファイルF2を呼び出し、プログラムP3はファイルF3を呼び出す等する。

本発明では、このような試験操作O1に対応する、呼び出し元プログラムすなわちアクセス元プログラム(P1乃至P3など)及び呼び出し先ファイルすなわちアクセス先ファイル(F11乃至F3など)を自動特定する。特に、一般に試験系コンピュータ装置2においては、Pa、Pb、Pc…等として図示するように、当該試験操作O1に対応するものではないアクセス元プログラムも起動され、それぞれアクセス先ファイルFa、Fb、Fc…等にアクセスしていることが通常である。本発明の自動特定は、このような試験操作O1とは無関係のアクセス元プログラム及びアクセス先ファイルを区別して行われる。当該区別には後述するように、試験操作O1の実行時刻の情報などを利用する。

パッチとは、アプリケーションにおける各機能のソースコードを修正し、再コンパイルしたものによって、修正対象機能に対応するファイルを置換するプログラムである。よって本発明では、試験操作O1に対応するアクセス元プログラム(P1乃至P3など)及びアクセス先ファイル(F11乃至F3など)を各アクセス関係として自動特定してから、当該アクセス元又はアクセス先の中にパッチによる置換対象が存在するようなアクセス関係を、当該パッチ適用による影響がありうるアクセス関係と判定する。

パッチ影響がありうると判定された試験操作O1については、実際にパッチ適用の前後の両者における試験系コンピュータ装置2において、当該アプリケーションA1内の試験操作O1を実行して両者の結果を比較し、パッチ適用により不具合等が生じていないか確認する試験が必要となる。本発明によれば、アプリケーションA1内に試験操作が例えばO1乃至O100の100種類存在したとして、そのうち当該比較確認試験を実施する必要があるものがどれであるかの前判定を下すことが可能となる。

よって、仮にアプリケーションA1の単位でパッチ適用による影響可能性ありと判定したとすれば、当該100種類の試験操作全てにつきパッチ影響調査の試験が必要となるのと比べて、試験対象の粒度を細かくして、試験工数を減少させることができる。さらに、ある試験操作O1が影響可能性ありと判定されている場合も、当該試験操作O1に伴うどのアクセス関係(アプリケーションA1の内部処理)が問題となりうるかが既に把握されているので、試験対象の粒度を一層細かくできる。このため、仮にパッチ適用により不具合等が生じた場合であっても、対応の検討をより容易に行うことができる。なお、本発明におけるこのようなパッチ適用による影響可能性の前判定は、パッチを適用する前の状態での試験系コンピュータ装置2に対して実施する。

本発明においては、試験操作O1をトリガとするか否かによらず、図2に示したような、試験系コンピュータ装置2の稼働中に発生した、各アクセス元プログラムP(P1、Pa等)と、アクセス先ファイルF(F11、Fa等)とのアクセス関係を、背景技術の項で説明した用語を借用して、動的相互依存情報と呼ぶこととする。なお、背景技術における動的相互依存情報とは、アプリケーションA1の単位での各動作を検出する情報であり、当該アプリケーションA1内での機能単位での各動作の検出は考慮されていないため、本発明の動的相互依存情報とは異なり、前述の通り粒度が粗い。本発明ではさらに、背景技術における動的相互依存情報と異なる点として、粒度を細かくする当該アクセス関係に加えてさらに、当該アクセス先ファイルFへのアクセスの発生時刻の情報を共に記録したものを、動的相互依存情報と呼ぶこととする。

なおまた、図2に示すようなアクセス関係において、各アクセス元プログラムP(P1、Pa等)とは例えばファイル等の形式のデータであり、正確には当該アクセス(呼び出し)を行う動作主体ではない。正確には、各アクセス元プログラムPを読み込んで実行する試験系コンピュータ装置2が、各アクセス元プログラムPにおける命令を実行することによって、各アクセス先ファイルF(F11、Fa等)に対するアクセスを行う動作主体となる。本発明においては説明の簡素化のために、適宜「アクセス元プログラム」や「アクセス元」などと称することとする。また本発明においては、OSやカーネル、アプリケーション、その他の個別プログラム(後述の図7の例など)を動作主体のように称する場合も、同様の理由による簡略化であって、当該OSやカーネル、アプリケーション、その他個別プログラムを実行する装置(又は当該装置内の機能ブロック)が動作主体である。

図3に、本発明のパッチ影響解析装置1の機能ブロック図を、解析対象の試験系コンピュータ装置2との関係を含めて示す。パッチ影響解析装置1は、動的相互依存情報取得部3、試験操作実行部4、パッチ影響判定部5及び解析結果表示部6を備える。動的相互依存情報取得部3はライブラリアクセス取得部31及びファイルアクセス取得部32を含む。パッチ影響判定部5はフィルタ処理部51を含む。

試験系コンピュータ装置2は動的相互依存情報記録部20及び試験系側試験操作実行部7を備える。動的相互依存情報記録部20はライブラリアクセス記録部21及びファイルアクセス記録部22を含む。パッチ影響解析装置1と試験系コンピュータ装置2とは、図1で説明したように、ネットワークを介してオンラインでデータのやりとりが可能であるものとする。ネットワーク上試験操作実行端末8は、当該ネットワーク上に存在する。

なお、試験操作実行部4が試験系コンピュータ装置2に対して実行する後述の各種の処理と同様の処理を、試験操作実行部4に代えて、試験系側試験操作実行部7又はネットワーク上試験操作実行端末8によって実行してもよい。本発明においては特にオンラインの場合など、基本的には説明の簡略化のために試験操作実行部4による処理として説明を行うこととするが、各処理の実行は適宜、試験系側試験操作実行部7又はネットワーク上試験操作実行端末8に代理させてもよい。なおまた試験操作実行部4にて処理を実行する場合は、運用者などが試験系コンピュータ装置2が物理的に存在する箇所に出かけるなどの必要なく、パッチ影響解析装置1によって一元管理を行えるという点で好ましい。

図4に、本発明のパッチ影響解析方法のフローチャートを示し、各ステップの説明と共に、図3の各機能ブロックの説明を行う。ステップS1では、試験系コンピュータ装置2において、動的相互依存情報の記録を開始する。ステップS1の実施の前提として、ステップS0では、試験系コンピュータ装置2を起動して稼働させておく。当該起動はネットワークを介して試験操作実行部4によって行ってもよい。

ステップS1ではこのように試験系コンピュータ装置2を起動させた後、試験操作実行部4が試験系コンピュータ装置2において、背景技術の項で前述のDC(データコレクタ)に相当するソフトウェアを起動させることで、該装置2の一部を、動的相互依存情報記録部20として機能するようにさせる。当該記録の詳細については、後述の動的相互依存情報取得部3の説明の際に併せて説明するが、前述のDCよりもさらに粒度の高い記録が可能である。

ステップS1以降、動的相互依存情報記録部20によって、試験系コンピュータ装置2において実行されるプログラムと各プログラムの呼び出したファイル等が、時刻情報と共に動的相互依存情報として記録されるようになる。

ステップS2では、稼働中の試験系コンピュータ装置2に対して、試験操作実行部4がまず解析対象の所定のアプリケーションを起動させた後の所定時刻に、当該アプリケーション内の所定の試験動作を実行させる。アプリケーション及び試験動作については、図2のA1及びO1として説明した通りである。当該所定時刻の情報は、パッチ影響解析装置1において保持しておき、パッチ影響の解析に利用する。

ステップS3では、試験操作実行部4が、試験系コンピュータ装置2において動的相互依存情報の記録を終了させる。すなわち、動的相互依存情報記録部20の記録を終了させる。ステップS4では、動的相互依存情報記録部20による記録を用いて、パッチ影響解析装置1がパッチ影響の判定を行う。

なお、ステップS2の試験動作実施時刻と共に、ステップS1の記録開始時刻及びステップS3の記録終了時刻も予め所定の時刻を定めておき、所定期間に渡って記録を行うようにしてよい。

図5は、パッチ影響判定方法のフローチャートであり、図4のステップS4の詳細を示すものである。ステップS41では、動的相互依存情報取得部30が、動的相互依存情報記録部20にて記録された動的相互依存情報を取得する。

図6に、図5のフローに従って順次処理されるデータの例を示す。当該データの例は、試験系コンピュータ装置2のOSがUNIX(登録商標)系のOSである場合を想定した例であるが、その他のOSであっても同様の情報を取得できる。動的相互依存情報の例を、図6の(1)に示す。(1)では各行(a)乃至(m)に個々の動的相互依存情報が示されている。なお、当該(a)乃至(m)は各行の識別用に付してあり、1行目は凡例である。フォーマットは共通であり、例えば(e)の行には次のように表示されている。
2010-07-01 20:00.01 /usr/sbin/httpd /lib/libresolv.so

上記フォーマットは、「アクセス発生日時」、「アクセス元プログラムファイル」及び「アクセス先ファイル」を順次並べたものとなっている。各項目は次の通りである。
「アクセス発生日時」：2010年7月1日 20時0分1秒
なお、アクセス発生日時については例えばミリ秒、マイクロ秒単位などのように、より細かく記録されてもよい。
「アクセス元ファイル」：ディレクトリ「/usr/sbin/」に存在する「httpd」プログラムファイル(httpサービス提供のプログラムファイル)
「アクセス先ファイル」：ディレクトリ「/lib/」に存在する「libresolv.so」ファイル(名前解決用の共有ライブラリのファイル)

上記のような動的相互依存情報は、前述の通り図4のステップS1乃至S3で動的相互依存情報記録部20が記録した後に、当該記録を当該ステップS41にて動的相互依存情報取得部30が取得する。ここで、動的相互依存情報記録部20による記録は、例えば次のようにして行うことができる。すなわち、試験系コンピュータ装置2において実行されているOSの中核プログラムであるカーネルの動作(カーネルを実行することによる当該装置2の動作、以下同じ)を追跡する、カーネルトレースのプログラムを実行することで、動的相互依存情報記録部20を試験系コンピュータ装置2内に構成する。

このようなカーネルトレースのプログラムは、ソフトウェア開発におけるデバッグ等の目的で提供されており、一般に利用可能である。そして、当該試験系コンピュータ装置2にて実行されるカーネルの全動作のうち、本発明におけるパッチ影響判断に必要な情報に関連する動作の発生タイミング、すなわち前述のアクセス関係の発生タイミングを検出するプローブとして、例えば以下のようなものを利用すればよい。

例えば、共有ライブラリのロード(読み込み)を検出するプローブを利用して、動的相互依存情報記録部20内にライブラリアクセス記録部21を構成することができる。UNIX(登録商標)系のOSであれば、例えばdlopen()関数の呼び出しを検出する。当該プローブの出力例を図7の(1)に示す。(1)では1行目がプローブ出力項目の凡例であり、順に、dlopen()関数によってライブラリを呼び出した呼び出し元プログラム、当該プログラムにOSが付与したPID(プロセスID)、dlopen()関数が当該呼び出しに従ってロードしたライブラリのフルパス名、ロードの際のフラグ情報、となっている。

例えば図7の(1)の2行目の例では、PID=12929を付与されたexpectプログラムが、ライブラリ"/usr/lib/libexpect5.43.so"を、フラグO_RDONLYすなわち、読み込みのみで開く(当該ライブラリに書き込む等して変更は加えない)、によってロードしたことが出力として得られている。なお、(1)には示していないが、各呼び出しの発生時刻の情報もタイムスタンプとして得られる。

また同様に、ファイルアクセスを検出するプローブを利用して、動的相互依存情報記録部20内にファイルアクセス記録部22を構成することができる。UNIX(登録商標)系のOSであれば、例えばopen()関数の呼び出しを検出する。当該プローブの出力例を(1)と同様の形式にて、図7の(2)に示す。すなわち、(2)では、open()関数を呼び出してファイルにアクセスを行ったアクセス元プログラム、当該プログラムにOSが付与したPID、open()関数が当該呼び出しに従ってアクセスしたファイルのフルパス名、ロードの際のフラグ情報が示されている。(2)には示していないが、各呼び出しの発生時刻の情報もタイムスタンプとして得られる。

さらに、以上のライブラリアクセス記録部21及びファイルアクセス記録部22の記録において、呼び出し元プログラムのフルパスを解決するための補助的な役割を果たすパス解決部23を、同様にして動的相互依存情報記録部20内に構成することができる。(ここでパス解決部23を利用するのは、上記の例のライブラリアクセス記録部21及びファイルアクセス記録部22では、呼び出し先ライブラリ及びファイルのフルパスしか解決されていないためである。)

すなわち、UNIX(登録商標)系のOSであれば、例えばexec()関数又はfork()関数の呼び出しを検出するプローブによって、パス解決部23を構成する。exec()関数による当該プローブの出力例を図7の(3)に示す。当該例に示されているように、PIDと起動されたプログラム(すなわち呼び出し元となるプログラム)のフルパスとの対応が得られる。よって、ライブラリアクセス記録部21及びファイルアクセス記録部22におけるPIDに対応する呼び出し元プログラムのフルパスを解決することができる。

以上のように、動的相互依存情報記録部20の各部が連係して記録した動的相互依存情報を、図5のステップS41において動的相互依存情報取得部3が取得する。上記の例であれば、ライブラリアクセス記録部21及びパス解決部23による記録を、ライブラリアクセス取得部31が取得し、ファイルアクセス記録部22及びパス解決部23による記録を、ファイルアクセス取得部32が取得する。

このようにして、図6の(1)のような動的相互依存情報が取得される。すなわち、アクセス発生時刻と、アクセス元及びアクセス先を試験系コンピュータ装置2におけるファイルシステムのフルパスで特定した情報が取得される。なお、図6の(1)では例えば(e)や(f)はライブラリアクセス取得部31が取得したデータであり、例えば(g)はファイルアクセス取得部32が取得したデータである。

なお、以上の例は、UNIX(登録商標)系のOSにおけるシステムコールを利用してライブラリアクセス取得部31(ライブラリアクセス記録部21及びパス解決部23)とファイルアクセス取得部32(ファイルアクセス記録部22及びパス解決部23)を実現する例であったが、ウィンドウズ(登録商標)等、その他のOSであっても各OSに対応するカーネルトレースを利用した類似の手法により、同様の情報を取得する各取得部31及び32を実現できる。例えば仮に、パス解決部23の補助が呼び出し先のフルパス解決に対して必要となるようなOSであっても、同様にして実現できる。

本発明においてアプリケーション内の機能単位でパッチ影響についての判定を下すためには、原則的には以上のような各種OSにおけるシステムコールを利用した各取得部31及び32を用いればよい。しかし特例的に、所定のアプリケーションが例えばjava(登録商標)等の特定のプラットホームを利用するものであり、当該プラットホーム内でのアクセス関係を特定するためには、システムコールの利用のみでは特定できない場合もある。このような場合に、パッチが当該プラットホーム内の機能構成単位で適用されていると、システムコールのみを利用した各取得部31及び32では粒度が不足することとなる。

この場合、ファイルアクセス取得部32やライブラリアクセス取得部31内でさらに、当該プラットホームにおけるアクセス関係を特定する必要があるが、一般に利用可能な当該プラットホームにおけるデバッグ用のアクセス関係追跡プログラムを用いることで、OSにおけるシステムコールの場合と同様にアクセス関係を特定できるので、詳細な説明は省略する。

例えば、javaを利用する場合、前述のopen()プローブを利用すれば、アクセス先としてjarファイル(javaにおける複数のclassファイルをまとめた統合ファイル)単位での特定は可能となる。しかしパッチがjarファイル内のクラス単位で適用される場合、jarファイル単位での特定は粒度不足である。この場合、ファイルアクセス取得部32内でさらに、アクセス先の統合ファイル内でのアクセス関係を取得すればよい。

図6の(1)の(l)は上記のような例を示している。すなわち以下のように、前述の(e)の例と同様な項目に追加して、さらに細部項目まで特定する例である。
「アクセス発生日時」：2010年7月1日 20時0分6秒
「アクセス元プログラム」：「/usr/bin/java」
「アクセス先ファイル(ここでは統合されたjarファイル)」：「/openjdk/test.jar」

そして、以上の原則項目に加え、以下の追加情報としての特例項目がある。
「アクセス先クラス名」：「main()」
すなわち、「test.jar」ファイル内の「main()」クラスのファイルのみがアクセスを受け、その他のクラスファイルはアクセスを受けていない。

なお、java以外にも、OSのシステムコール利用のみではパッチ影響解析に粒度が不足する場合は、ライブラリアクセス取得部31であってもファイルアクセス取得部32であっても、同様にしてアクセス関係を細部まで追跡すればよい。

すなわち、アクセス先ファイルがパッケージ化される等で複数の個別ファイルを含む統合ファイルである場合に、当該統合ファイル内でアクセス対象となった個別ファイルを(アクセス対象とはならなかった個別ファイルと区別して)アクセス時刻と共に取得する統合ファイル内アクセス取得部(図3には不図示)を動的相互依存情報取得部3内に設けることで、細部までアクセス関係を追跡することができる。当該追跡は、統合ファイルがライブラリアクセス取得部31の取得するライブラリファイルである場合にも、ファイルアクセス取得部32で取得する通常のファイルである場合にも行うことができる。

図5に戻り、以上のようにステップS41で動的相互依存情報を取得すると、次にステップS42では、パッチ影響判定部51が動的相互依存情報の解析を行う。当該解析とは、図6の(1)に(a)乃至(m)のような例を示している動的相互依存情報の中から、図4のステップS2における所定の試験操作に応答して発生した項目を検出するための解析である。当該解析の各実施形態について以下説明する。

最も基本的な実施形態では、ステップS2における所定の試験操作が実行された所定時刻の所定範囲内の近傍において発生した動的相互依存情報を、試験操作に応答するものであると判断する。図6の(1)の例で、例えば試験操作実行の所定時刻が2010年7月1日 20時0分1秒であるとし、所定時刻範囲として例えば同年同日の20時0分1秒から20時0分10秒までの範囲内を用いるとする。この場合、例示されているアクセス関係の中であれば(1)の(a)乃至(m)の合計13個の中から、試験操作に応答するアクセス関係として(e)乃至(m)の9個に限定される。

追加実施形態では、上記所定時刻範囲の外部にも存在する動的相互依存情報のアクセス関係と同一のアクセス関係が、当該所定時刻範囲の内部に存在する場合、さらに当該アクセス関係を削除して限定する。上記の例であれば、所定時刻範囲の外部に存在するアクセス関係(a)乃至(d)は、所定時刻範囲の内部にもアクセス関係(h)乃至(k)として存在するので、基本的な実施形態の結果から追加で当該(h)乃至(k)を除外することにより、試験操作に応答するアクセス関係を(e)乃至(g)と(l)及び(m)の合計5個に限定する。

なお、当該追加実施形態におけるアクセス関係の同一については、アクセス元及びアクセス先の両者の同一によって判断する。図6の(1)の例では、アクセス先については「…」等として記載を省略しているが、(a)と(h)、(b)と(i)、(c)と(j)及び(d)と(k)が同一のアクセス関係となっている。

当該追加実施形態は、所定時刻範囲の外部にも存在するアクセス関係は、試験操作とは無関係の一般的なものである可能性が高いとして除外するフィルタリングを施す実施形態であり、パッチ影響判定部5内のフィルタリング処理部51によって実行される。

以上、ステップS42を終えると、ステップS43では、パッチ影響判定部5がパッチ内容を解析する。パッチ内容の解析とは、各パッチに対して、各パッチが置換するファイル等をリストアップすることであり、一般にパッチ作成者が記述するマニフェスト情報を参照すること等で当該解析が可能となる。

図6の(2)にパッチ内容の解析例を示す。各パッチにはIDとして001、002、003、010、020等が付与され、パッチ名、ベンダ名及び各パッチの置換対象ファイルの情報がパッチ内容となっている。パッチ001はカーネルに対するパッチで、フルパスで特定されるファイル「/boot/grub.conf」を置換する。パッチ002は名前解決ライブラリに対するパッチであり、フルパスで特定されるファイル「/lib/libresolv.so」及び「/etc/ld.so.conf」を置換する。ベンダ名は001、002共通でredhat(登録商標)となっている。またパッチ010はフルパスで特定されるファイル「/usr/bin/java」を置換し、パッチ020はフルパスで特定されるファイル「/usr/sbin/httpd」を置換する。

なお、ステップS43はステップS44の前であれば任意の時点で実行することができる。例えばステップS40乃至S42の間のいずれかの箇所で実行してもよい。

以上、ステップS43を終えると、ステップS44では、パッチ影響判定部5が、ステップS42で解析した各アクセス関係が、ステップS43で解析した各パッチの適用によって影響を受けうるかの判定を行う。以下(A)〜(C)の場合に、当該パッチ適用により影響がありうると判定する。

(A)当該パッチが、当該アクセス関係におけるアクセス元プログラムのファイルを置換・修正するパッチである場合
(B)当該パッチが、当該アクセス関係におけるアクセス先ライブラリ又はアクセス先ファイルを置換・修正するパッチである場合
(C)当該パッチが、前述のjarファイル内のクラスファイルのように、当該アクセス関係におけるアクセス先ライブラリ又はアクセス先ファイルを構成する部分要素のファイルを置換・修正するパッチである場合

以上(A)〜(C)はすなわち、当該パッチが当該アクセス関係におけるアクセス元又はアクセス先のうち少なくとも一方のファイルを置換・修正する場合に、当該パッチの適用によって当該アクセス関係が影響を受けうる、と判定するものである。

図6の(3)に、(1)(2)の例に対応するパッチ影響判定の例を示す。影響がありうると判定されたアクセス関係は(1)に示すのと同様の(e)、(f)、(g)、(l)及び(m)であり、順次(1)と同様にアクセス発生日時、アクセス元ファイル、アクセス先ファイルが示され、さらに影響し得るパッチIDが示されている。なお、パッチ影響判定の際はアクセス発生日時の情報は必ずしも必要ないが、(3)では(1)との共通性を示すために補助的に当該情報も示している。

(3)では影響し得るパッチIDを、アクセス元ファイルに対して影響し得るパッチ、アクセス先ファイルに対して影響し得るパッチ、の順に示している。アクセス元に対する影響を有するパッチはIDの頭に「P」を付与して、アクセス先への影響を有するパッチと区別して示している。

(3)では例えばアクセス関係(e)に対しては、パッチ020がアクセス元ファイル「/usr/sbin/httpd」を置換し、パッチ002がアクセス先ファイル「/usr/lib/libresolve.so」を置換するので、影響し得るパッチIDの欄には「P020, 002」と示されている。アクセス関係(f)に対しては、パッチ020がアクセス元ファイル「/usr/sbin/httpd」を置換し、アクセス先ファイル「/lib/libcrypt.so」を置換するパッチは見つからなかったので、影響し得るパッチIDの欄には「P020, null」(nullは影響の有るパッチが無い場合を示す)と示されている。

さらに、アクセス関係(g)に対しては、パッチ020がアクセス元ファイル「/usr/sbin/httpd」を置換し、(2)には不図示のパッチ005及び006がアクセス先ファイル「/var/html/index.php」を置換するので、影響し得るパッチIDの欄には「P020, 005, 006」と示されている。アクセス関係(l)及び(m)についても以上と同様に、影響し得るパッチIDが特定されている。

以上、図5の各ステップを説明した。本発明においては、解析結果表示部6を用いて解析結果すなわち図6の(3)を表示することができる。さらに解析結果表示部6では、当該解析(最終)結果のみでなく、解析途中の結果も表示することができる。すなわち、図5の各ステップにおいて処理されるデータ、つまり図6の上記(3)の他に(1)及び(2)のようなデータや、図4の各ステップにおいて記録されその後に取得されるデータ、つまり図7の(1)〜(3)のようなデータも表示することができる。

当該表示に際しては、パッチ影響解析装置1を利用する管理者等の表示要求に応じて、任意の所望の項目を表示する。当該表示に関しては、GUI(グラフィカルユーザインタフェース)やCLI(コマンドラインインタフェース)など、種々の周知の手法を利用することができる。

なお、本発明は、図4及び図5の各ステップをコンピュータに実行させることで、当該コンピュータを図3に記載のパッチ影響解析装置1として機能させるパッチ影響解析プログラムとして実施することもできる。当該コンピュータは当該プログラムを読み込んで、上記各ステップを実行するパッチ影響解析装置1として機能する。

なおまた、本発明は基本的には、パッチ影響解析装置1と試験系コンピュータ装置2とがオンラインでデータのやりとりが可能であるものとして説明した。オフラインの場合は、データ授受などを適宜代用手段にて実施すればよい。すなわち、オフラインの場合、図4のステップS1乃至S3はパッチ影響解析装置1の備える試験操作実行部4から実行することはできない。よってこの場合は特に、試験系側試験操作実行部7が同様の処理を実行すればよい。あるいは、運用者などが手動で、又は試験系コンピュータ装置2にアクセス可能であればネットワーク上試験操作実行端末8によって、試験系コンピュータ装置2に同様の処理を実行させてもよい。

さらにオフラインの場合は、図4のステップS4でのデータ授受(動的相互依存情報及び、パッチ影響解析装置1側で保持されていない場合には試験操作実行の所定時刻の情報)を前述の通り物理メディア等を介して手動などで行うことにより、図5の各ステップをオンラインの場合と同様に実施することができる。

以上、本発明によれば、試験系コンピュータ装置に対してパッチを適用した場合の影響を、該試験系コンピュータ装置にて実行されるアプリケーション内で実現される機能の単位で判定することが可能となる。

1…パッチ影響解析装置、3…動的相互依存情報取得部、4…試験操作実行部、5…パッチ影響判定部、6…解析結果表示部、31…ライブラリアクセス取得部、32…ファイルアクセス取得部、51…フィルタ処理部

Claims (8)

1. 試験系コンピュータ装置に対する所定のパッチの適用による、前記試験系コンピュータ装置にて実行される所定のアプリケーションに対する影響を、該所定のアプリケーション内の複数のプログラムの各々に対応した機能単位で前記所定のパッチの適用の前に検出するパッチ影響解析装置であって、
   前記試験系コンピュータ装置の稼働中の所定期間に、該試験系コンピュータ装置にて各プログラムが実行されるのに伴って発生するアクセス関係をアクセス元、アクセス先及び当該アクセスの発生時刻と対応づけて動的相互依存情報として、前記試験系コンピュータ装置より取得する動的相互依存情報取得部と、
   前記所定のパッチの適用による影響を判定するパッチ影響判定部とを備え、
   前記試験系コンピュータ装置の稼働中の前記所定期間内に、該試験系コンピュータ装置にて前記所定のアプリケーションが起動された後の所定時刻に該アプリケーション内の所定の試験操作が実行された後に前記パッチ影響判定部が、前記動的相互依存情報より、前記所定時刻の所定の近傍時刻範囲内に存在するアクセス元及びアクセス先の情報を抽出し、該アクセス元又はアクセス先のうち少なくとも一方が前記所定のパッチの適用による置換対象である場合に、前記所定の試験操作における当該アクセス関係を前記所定のパッチの適用による影響有りと判定することを特徴とするパッチ影響解析装置。
2. 前記動的相互依存情報取得部が、前記アクセス関係の一種として、アクセス元プログラム、アクセス先ライブラリ及び前記発生時刻を対応づけて前記動的相互依存情報として取得するライブラリアクセス取得部を含むことを特徴とする請求項1に記載のパッチ影響解析装置。
3. 前記動的相互依存情報取得部が、前記アクセス関係の一種として、アクセス元プログラム、アクセス先ファイル及び前記発生時刻を対応づけて前記動的相互依存情報として取得するファイルアクセス取得部を含むことを特徴とする請求項1または2に記載のパッチ影響解析装置。
4. 前記パッチ影響判定部がさらに、前記所定の近傍時刻範囲内に存在するアクセス元及びアクセス先のペアのうち、前記所定の近傍時刻範囲外にも存在するアクセス元及びアクセス先のペアを除外するフィルタ処理部を含み、該フィルタ処理部を通過したペアにおけるアクセス元又はアクセス先のうち少なくとも一方が前記所定のパッチの適用による置換対象である場合に、前記所定の試験操作における当該アクセス関係を前記所定のパッチの適用による影響有りと判定することを特徴とする請求項1ないし3のいずれかに記載のパッチ影響解析装置。
5. 前記動的相互依存情報と、前記所定のパッチの情報と、前記パッチ影響判定部により判定されたパッチ影響の有無の情報とを対応づけて解析結果として表示する解析結果表示部をさらに備えることを特徴とする請求項1ないし4のいずれかに記載のパッチ影響解析装置。
6. 前記動的相互依存情報取得部が、前記動的相互依存情報におけるアクセス元及びアクセス先を前記試験系コンピュータ装置のファイルシステムにおけるフルパスで特定して前記動的相互依存情報として取得する請求項1ないし5のいずれかに記載のパッチ影響解析装置。
7. 試験系コンピュータ装置に対する所定のパッチの適用による、前記試験系コンピュータ装置にて実行される所定のアプリケーションに対する影響を、該所定のアプリケーション内の複数のプログラムの各々に対応した機能単位で前記所定のパッチの適用の前に検出するパッチ影響解析方法であって、
   前記試験系コンピュータ装置の稼働中の所定期間に、該試験系コンピュータ装置にて各プログラムが実行されるのに伴って発生するアクセス関係をアクセス元、アクセス先及び当該アクセスの発生時刻と対応づけて動的相互依存情報として、前記試験系コンピュータ装置より取得する動的相互依存情報取得ステップと、
   前記試験系コンピュータ装置の稼働中の前記所定期間内に、該試験系コンピュータ装置にて前記所定のアプリケーションを起動した後の所定時刻に該アプリケーション内の所定の試験操作を実行する試験操作実行ステップと、
   前記動的相互依存情報より、前記所定時刻の所定の近傍時刻範囲内に存在するアクセス元及びアクセス先の情報を抽出し、該アクセス元又はアクセス先のうち少なくとも一方が前記所定のパッチの適用による置換対象である場合に、前記所定の試験操作における当該アクセス関係を前記所定のパッチの適用による影響有りと判定するパッチ影響判定ステップとを備えることを特徴とするパッチ影響解析方法。
8. 試験系コンピュータ装置に対する所定のパッチの適用による、前記試験系コンピュータ装置にて実行される所定のアプリケーションに対する影響を、該所定のアプリケーション内の複数のプログラムの各々に対応した機能単位で前記所定のパッチの適用の前に検出するパッチ影響解析プログラムであって、
   前記試験系コンピュータ装置の稼働中の所定期間に、該試験系コンピュータ装置にて各プログラムが実行されるのに伴って発生するアクセス関係をアクセス元、アクセス先及び当該アクセスの発生時刻と対応づけて動的相互依存情報として、前記試験系コンピュータ装置より取得する動的相互依存情報取得ステップと、
   前記所定のパッチの適用による影響を判定するパッチ影響判定ステップとをコンピュータに実行させることで当該コンピュータをパッチ影響解析装置として機能させ、
   前記試験系コンピュータ装置の稼働中の前記所定期間内に、該試験系コンピュータ装置にて前記所定のアプリケーションが起動された後の所定時刻に該アプリケーション内の所定の試験操作が実行された後に前記パッチ影響判定ステップにおいて、前記動的相互依存情報より、前記所定時刻の所定の近傍時刻範囲内に存在するアクセス元及びアクセス先の情報を抽出し、該アクセス元又はアクセス先のうち少なくとも一方が前記所定のパッチの適用による置換対象である場合に、前記所定の試験操作における当該アクセス関係を前記所定のパッチの適用による影響有りと判定することを特徴とするパッチ影響解析プログラム。