不良該非判定手法
【課題】ＡＰＩに不良が発生した場合にユーザシステムが発生条件を知らなくても不良の該非判定を実施できるようにする。
【解決手段】プログラムの提供するＡＰＩに不良が発覚した場合に、暗号化した設定ファイルを前記プログラムのユーザが使用する計算機に配布し、前記ユーザが設定ファイルを前記プログラムに読込ませる指示を行い、前記プログラムが前記ＡＰＩのバイトコードにログ取得処理を埋め込むことで、前記ユーザが作成する情報処理システムにおいて前記ＡＰＩを使用しているか否かを判定する。また、呼び出し回数、呼び出しトレース取得処理を同時に前記ＡＰＩのバイトコードに埋め込むことで前記ユーザが前記情報処理システムへの影響を判断するための情報を出力し、ユーザはその情報を見て修正版の適用判断を行う。
【解決手段】プログラムの提供するＡＰＩに不良が発覚した場合に、暗号化した設定ファイルを前記プログラムのユーザが使用する計算機に配布し、前記ユーザが設定ファイルを前記プログラムに読込ませる指示を行い、前記プログラムが前記ＡＰＩのバイトコードにログ取得処理を埋め込むことで、前記ユーザが作成する情報処理システムにおいて前記ＡＰＩを使用しているか否かを判定する。また、呼び出し回数、呼び出しトレース取得処理を同時に前記ＡＰＩのバイトコードに埋め込むことで前記ユーザが前記情報処理システムへの影響を判断するための情報を出力し、ユーザはその情報を見て修正版の適用判断を行う。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システムを構成するプログラムの提供するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｔｅｒｆａｃｅ）に不良が判明した時に、情報処理システムが当該不良の影響を受けるか否かを判定する技術に関する。
【背景技術】
【０００２】
従来、プログラムの提供するＡＰＩに不良が存在することが判明した場合、プログラムの提供者は不良を修正した修正版を発行して、プログラムのユーザに提供し、修正版を適用するよう呼びかけている。プログラムのユーザである情報処理システムの開発者は自システムプログラムが不良に該当しているか非該当にがいとうしているかを判定し、該当している場合は修正版を適用し、予防保守を行っている。プログラム不良の該非判定を行い、予防保守を行うような技術は特許文献１で公開されている。特許文献１のような技術では、プログラムの提供元はプログラムの障害情報が蓄積されたデータベースを有しており、当該データベースが更新された場合にユーザの有する情報処理システムに対して該非判定を行うための確認プログラムを配布する。ユーザの有する情報処理システムは当該プログラムを実行することで自システムの構成ハードウェア、ソフトウェアで障害が発生するか否かを判定する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−１４１８７
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ユーザの有する情報処理システム（ユーザシステムと省略する）が自システムで不良ＡＰＩを使用しているか否かはシステムを構成するアプリケーションプログラムのソースコードが不良ＡＰＩを使用して実装されているか否かを調査する。しかし、プログラムの提供するＡＰＩの不良がセキュリティに関わる問題であった場合、セキュリティ攻撃の手法を公開することになるため、不良ＡＰＩや不良の発生条件といった詳細情報をプログラムのユーザに提供できない。そのため、ユーザシステムが自システムで不良ＡＰＩを使用しているかが分からず、修正版の適用判断ができない。
【０００５】
ユーザシステムを構成するプログラムのソースコードを所持していなくても該非判定を行い、また、情報処理システムは様々なプログラム部品を使用して実装されており、ユーザシステムは必ずしも自システムを構成する全てのプログラムのソースコードを所持していない。そのため、自システムで不良ＡＰＩを使用しているかが不明な場合がある。
【０００６】
本発明の目的は、プログラムの提供するＡＰＩに不良が判明した時に、ユーザシステムで発生条件を知らなくても、ユーザシステムの該非判定を行えるようにすることである。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、本発明では不良ＡＰＩを含むプログラムの提供元が不良の概要情報と不良ＡＰＩの詳細情報を暗号化した判定用設定ファイルとをネットワークを介してユーザシステムに提供し、ユーザシステムに判定用設定ファイルをＡＰＩの提供元であるプログラムに読み込ませ、プログラムはファイルを復号化して不良情報を読み取り、プログラム実行時に不良ＡＰＩを含むクラスが主記憶装置上にロードされるタイミングで主記憶装置上の不良ＡＰＩのバイトコードを書き換え、該非判定のためのログ情報を取得する処理を埋め込み、ユーザシステムが処理を実行して不良ＡＰＩが実行された時に取得したログ情報をユーザシステムに判定結果ログとしてファイル形式で提供し、ユーザシステムは判定結果ログファイルを参照して自システムへの影響を確認し、プログラムの修正版適用を判断する。
【発明の効果】
【０００８】
ＡＰＩを提供するプログラムを使用している情報処理システムにて、ＡＰＩに不良が発生した場合にユーザシステムが発生条件を知らなくても不良の該非判定を実施することが可能となる。
【図面の簡単な説明】
【０００９】
【図１】本実施形態における装置構成を示す構成図の一例である。
【図２】本実施形態における不良の該非判定を行う処理の流れを示す説明図である。
【図３】本実施形態におけるプログラム提供元からユーザに通知される不良情報の一例を示す説明図である。
【図４】本実施形態における判定用設定ファイルの一例を示す説明図である。
【図５】本実施形態における判定ログ保存テーブルの一例を示す説明図である。
【図６】本実施形態におけるトレース保存テーブルの一例を示す説明図である。
【図７】本実施形態における判定結果ログファイルの一例を示す説明図である。
【図８】本実施形態における非セキュリティ問題の不良ＡＰＩのバイトコード書換後のコードイメージの一例を示す説明図である。
【図９】本実施形態におけるセキュリティ問題の不良ＡＰＩのバイトコード書換後のコードイメージの一例を示す説明図である。
【図１０】本実施形態における情報発信処理時の流れを示すフローチャートである。
【図１１】本実施形態における判定モード処理時の流れを示すフローチャートである。
【図１２】本実施形態におけるクラスロード処理の流れを示すフローチャートである。
【図１３】本実施形態における不良ＡＰＩに判定処理コードを埋め込む処理の流れを示すフローチャートである。
【発明を実施するための形態】
【実施例１】
【００１０】
以下、本発明を実施するための形態（以下「実施形態」という）について、図面を参照して説明する。
【００１１】
図１は本実施形態における情報処理システムの装置構成の概要を示す説明図である。図１に示すように本実施形態ではプログラム提供元の計算機１０とユーザが使用する計算機１２０がネットワーク１１を通じて接続される。プログラム提供元の計算機１０はユーザが使用する計算機１２０に対して不良ＡＰＩの情報を情報発信する。ユーザの計算機１２０は複数存在してもよい。
【００１２】
プログラム提供元の計算機１０は、通信アダプタ５０、ＣＰＵ３０、入力装置４０、出力装置２０、補助記憶装置９０および主記憶装置６０を備え、バス１００を介して互いに接続される。通信アダプタ５０を利用してユーザが使用する計算機１２０へ接続し、判定用設定ファイル４００と不良情報３００とを送信する。
【００１３】
ユーザが使用する計算機１２０は、通信アダプタ５１、ＣＰＵ３１、入力装置４１、出力装置２１、補助記憶装置９１および主記憶装置１４０とを備え、バス１０１を介して互いに接続される。通信アダプタ５１を使用してプログラム提供元の計算機１０と通信を行う。
【００１４】
出力装置２０はプログラム提供元の計算機１０から出力される情報を表示する。
各処理部は、プログラムやオブジェクト、もしくは同等の機能を有するハードウェアで実現できる。本実施例は、各処理部がプログラムで実現された一例を示している。
【００１５】
ＣＰＵ３０は主記憶装置６０に記憶された各種処理部を実行することによって各種処理を実行する。入力装置４０はプログラム提供元の計算機１０に必要な情報および指示の入力に使用する。
【００１６】
通信アダプタ５０はネットワーク１１を介して通信アダプタ５１と通信する。
主記憶装置６０はファイル暗号化処理部７０と情報発信処理部８０を含む。プログラム提供元の計算機１０は主記憶装置６０上でユーザの計算機１０へ判定用設定ファイル４００と不良情報３００を送信するための処理を行う。
【００１７】
ファイル暗号化処理部７０は判定用設定ファイル４００を生成し、セキュリティ問題が含まれる場合には判定用設定ファイル４００を暗号化する。情報発信処理部８０はプログラム提供元の計算機１０からユーザの計算機１２０へ不良情報３００と判定用設定ファイル４００を送信する。補助記憶装置９０はプログラム提供元の計算機１０上でプログラム及びプログラムの実行に必要なデータを格納する。判定用設定ファイル４００は補助記憶装置９０に含まれる。
【００１８】
出力装置２１はユーザの計算機１２０から出力される情報を表示する。ＣＰＵ３１は主記憶装置６１に記憶された各種プログラムを実行することによって各種処理を実行する。入力装置４１はユーザの計算機１０に必要な情報および指示の入力に使用する。通信アダプタ５１はネットワーク１１を介して通信アダプタ５０と通信する。主記憶装置６１はプログラム実行処理部１５０を含む。不良の該非判定のための処理は主記憶装置６１上で行われる。
【００１９】
プログラム実行処理部１５０はクラスロード処理部１５１、バイトコード書換部１５２、該当バージョン判定部１５３、ファイル復号化処理部１５４、ログ出力処理部１５５、ユーザ処理部１５６、バイトコード格納部１７０を含む。クラスロード処理部１５１はＡＰＩ処理部１６１が必要とするクラスをバイトコード格納部１７０へ読み込む。読み込む際、該当バージョン判定部１５３を呼び出し、不良の該当バージョン判定を行い、該当し、かつロード対象クラスが不良ＡＰＩを含む場合はバイトコード書換部を呼び出し、ロード対象クラスのバイトコードを書き換える。
【００２０】
バイトコード書換部１５２はバイトコード格納部１７０に読み込まれたＡＰＩ１６０に判定フラグ処理部１６２を埋め込む。さらに、不良がセキュリティ問題でない場合は、呼出回数カウント部１６３、トレース取得部１６４、不良箇所実行回数カウント部１６５を埋め込む。
【００２１】
該当バージョン判定部１５３はユーザの計算機１２０上で動作するプログラムが不良が存在するバージョンに該当しているか判定する。ファイル復号化処理部１５４は判定用設定ファイル４００が暗号化されている場合、復号化処理を行う。ログ出力処理部１５５は判定結果ログファイル７００を出力する。ユーザ処理部１５６はＡＰＩ処理部１６１を使用してユーザプログラムの実行処理を行う。ＡＰＩ処理部１６１はユーザプログラムの実行処理を行う。判定フラグ処理部１６２は不良ＡＰＩが実行された時に判定ログ保存テーブル５００に該当フラグを保存する。呼出回数カウント部１６３は不良ＡＰＩが実行された回数を判定ログ保存テーブル５００に保存する。
【００２２】
トレース取得部１６４は不良ＡＰＩが実行された時のスレッドスタックトレースを取得し、トレース保存テーブル６００に保存する。不良箇所実行回数カウント部１６５は不良ＡＰＩの不良箇所が実行された回数をカウントし、判定ログ保存テーブル５００に保存する。
【００２３】
バイトコード格納部１７０はＡＰＩ１６０を含む。クラスロード処理部１５１によってロードされたＡＰＩを格納する。不良情報３００は不良の概要を含み、情報発信処理部８０によってプログラム提供元からユーザへ送付される。判定用設定ファイル４００は不良ＡＰＩの詳細情報を格納する。プログラム実行処理部１５０がプログラムを実行する際に読み取る。
【００２４】
判定ログ保存テーブル５００は判定フラグ処理部１６２、呼出回数カウント部１６３、不良箇所実行回数カウント部１６５で取得したログ情報を保存する。トレース保存テーブル６００はトレース取得部１６４で取得したログ情報を保存する。判定結果ログファイル７００は判定ログ保存テーブル５００、トレース保存テーブル６００に保存された情報を格納する。
【００２５】
図２は本実施形態における不良の該非判定を行う処理の流れの一例を示す説明図である。まず、プログラム提供元２００は判定用設定ファイル４００と不良情報３００をユーザが使用する計算機２１０へ送付する（２０１）。次に、ユーザが使用する計算機２１０はプログラム実行処理部１５０を判定モードで起動する（２１１）。判定モードで起動されるとプログラム実行処理部１５０は起動時に判定用設定ファイル４００を読み込む（２２１）。読み込みが終わると該当バージョン判定部１５３が、不良に該当するバージョン、オプション設定となっているか判定する（２２２）。判定が終わるとプログラム実行処理部１５０はユーザが使用する計算機２１０へ起動完了した旨を通知する（２２３）。起動完了の通知を受けるとユーザ２１０はアプリケーション処理を実行する（２１２）。
【００２６】
アプリケーション処理の実行によりクラスをロードする必要が生じるとプログラム実行処理部１５０はクラスロード処理を行う（２２４）。クラスロード処理ではプログラム実行処理部１５０は不良ＡＰＩのバイトコードへログ取得処理を埋め込む（２２５）。アプリケーション処理実行２１２により、ログ取得処理を埋め込んだＡＰＩが実行されるとログが取得される（２２６）。アプリケーション処理実行が終わるとユーザが使用する計算機２１０はプログラム実行処理部に対してログ出力要求を行う（２１３）。
【００２７】
ユーザが使用する計算機２１０からログ出力要求を受け取るとプログラム実行処理部１５０は判定結果ログファイル７００を出力する（２２７）。ログ出力が終わるとプログラム実行処理部１５０はユーザが使用する計算機２１０へログ出力の終了を通知する（２２８）。ログ出力終了を通知されるとユーザが使用する計算機２１０は判定結果ログファイル７００を確認する（２１４）。ユーザが使用する計算機２１０はログから修正版を適用するかしないか判断する（２１５）。修正版を適用すると判断した場合はユーザが使用する計算機２１０はプログラム提供元２００へ修正版の提供を要求する（２１６）。ユーザが使用する計算機２１０から修正版要求を受けるとプログラム提供元２００はユーザが使用する計算機２１０へ修正版を提供する（２０２）。修正版を提供されたらユーザが使用する計算機２１０は修正版を適用する（２１７）。以上で不良の該非判定は完了する（２１８）。
【００２８】
図３は本実施形態におけるプログラム提供元からユーザに通知される不良情報３００の一例を示す説明図である。ユーザは、ユーザが使用する計算機２１０より、判定結果ログファイル７００と不良情報３００の情報を元に自システムでの不良の影響度を判定する。不良情報３００は修正ＩＤ３１０、現象３２０、発生条件３３０、該当バージョン３４０、修正バージョン３５０を含む。修正ＩＤ３１０は不良を識別するためのＩＤを表示する。ＩＤは不良毎に固有の値を有する。
【００２９】
現象３２０は不良が発生した場合の現象を表示する。３２０Ａでは詳細な現象を表示する。発生条件３３０は不良の発生条件を表示する。３３０Ａは不良に該当するオプション設定を表示した例、３３０Ｂは不良を含むＡＰＩを表示した例である。セキュリティ問題の場合は非公開となる。該当バージョン３４０は不良が存在するプログラムのバージョン情報を表示する。３４０Ａは該当バージョンの表示例である。修正バージョン３５０は不良が修正されたプログラムのバージョン情報を表示する。３５０Ａは修正バージョンの表示例である。
【００３０】
図４は本実施形態における判定用設定ファイル４００の一例を示す説明図である。判定用設定ファイル４００は不良の該当するバージョンや不良の存在するＡＰＩの情報が記載されており、プログラム実行処理部１５０が不良の該非判定のためのログ出力処理をどのクラスのどのＡＰＩに埋め込むかを判断するのに用いる。
【００３１】
判定用設定ファイル４００は修正ＩＤ４１０、該当ＶＲＳ４２０、該当オプション４３０、該当ＡＰＩ４４０、不良箇所のインデックス４５０、セキュリティ４６０を含む。判定用設定ファイル４４０はプログラム実行処理部１５０が判定モードで起動した時にプログラム実行処理部１５０によって読み込まれ、不良ＡＰＩのバイトコードに該非判定のためのログ取得処理を埋め込むために使用される。修正ＩＤ４１０は不良の識別ＩＤ情報である。該当ＶＲＳ４２０は不良に該当するプログラムのバージョン情報である。該当バージョン判定部１５３によってプログラムのバージョンが該当バージョンであるか判定するために使用される。該当オプション４３０は不良に該当するオプション設定の情報である。該当バージョン判定部１５３によって不良に該当するオプションがプログラムに設定されているか判定するために使用される。
【００３２】
該当ＡＰＩ４４０は不良を含むＡＰＩの情報である。クラスロード処理部１５１がクラスをロードする時にロード対象クラスが不良ＡＰＩを含むか判定するために使用される。不良箇所のインデックス４５０は不良ＡＰＩのバイトコード中の不良箇所のインデックスである。バイトコード書換部１５２は不良箇所のインデックス４５０から不良ＡＰＩの不良箇所を特定し、不良箇所実行回数カウント部を不良ＡＰＩのバイトコードに埋め込む。セキュリティ４６０は不良がセキュリティ問題であるか否かを示し、判定ログ保存テーブル５００のセキュリティフラグ５２０に読み込まれる。
【００３３】
図５は本実施形態における判定ログ保存テーブル５００の一例を示す説明図である。判定ログ保存テーブル５００はプログラム実行中にプログラム実行処理部１５０が不良APIの実行状況を保存しておくテーブルである。判定ログ保存テーブル５００は主記憶装置１４０上に存在し、ログ出力処理部１５５が判定結果ログファイル７００を出力する際に参照される。
【００３４】
判定ログ保存テーブル５００は修正ＩＤ５１０、セキュリティフラグ５２０、コード書換フラグ５３０、判定フラグ５４０、ＡＰＩ呼出回数５５０、不良箇所実行回数５６０を含む。修正ＩＤ５１０は不良を識別するＩＤである。セキュリティフラグ５２０は修正ＩＤ５１０の不良がセキュリティ問題であるか否かを表す。「Ｙ」であればセキュリティ問題であることを表し、「Ｎ」であればセキュリティ問題ではないことを表す。バイトコード書換部１５２が不良ＡＰＩに呼出回数カウント部１６３、トレース取得部１６４、不良箇所実行回数カウント部１６５を埋め込むか否かを判定するのに用いる。
【００３５】
コード書換フラグ５３０はクラスロード処理部１５１が修正ＩＤ５１０の不良ＡＰＩのバイトコード書換処理をバイトコード書換処理部１５２に行わせるか否かを表す。「Ｙ」であればバイトコード書換を行い、「Ｎ」であればバイトコード書換を行わない。コード変換フラグは該当バージョン判定部１５３によって更新され、プログラムが修正ＩＤ５１０の該当バージョンであり、かつ該当オプションである場合のみ「Ｙ」となる。
【００３６】
判定フラグ５４０はプログラムが修正ＩＤ５１０の不良に該当しているかどうかを表す。「Ｙ」であれば不良に該当していることを表し、「Ｎ」であれば不良に該当していないことを表す。判定フラグ処理部１６２によって更新され、ユーザ処理部１５６によって不良ＡＰＩが実行された場合のみ「Ｙ」となる。ＡＰＩ呼出回数５５０は修正ＩＤ５１０の不良ＡＰＩがプログラム実行中に何回呼び出されたかを表す。呼出回数カウント部１６３によって更新される。不良箇所実行回数５６０は修正ＩＤ５１０の不良ＡＰＩのバイトコードのうち、不良箇所が何回実行されたかを表す。不良箇所実行回数カウント部によって更新される。
【００３７】
図６は本実施形態におけるトレース保存テーブル６００の一例を示す説明図である。トレース保存テーブル６００はプログラム実行中にトレース取得部１６４が取得した不良ＡＰＩの呼び出しトレースを保存するテーブルである。トレース保存テーブル６００は主記憶装置１４０上に存在し、ログ出力処理部１５５が判定結果ログファイル７００を出力する際に参照される。修正ＩＤ６１０と呼び出しトレース６２０を含む。修正ＩＤ６１０は不良を識別するＩＤである。呼び出しトレース６２０は不良ＡＰＩが呼び出された時のスタックトレースを表す。トレース取得部１６４によって更新される。
【００３８】
図７は本実施形態における判定結果ログファイル７００の一例を示す説明図である。判定結果ログファイル７００は不良の該非判定結果を出力したログファイルである。半知恵結果ログファイル７００をユーザが参照し、修正版の適用判断を行う。判定結果ログファイル７００は修正ＩＤ７１０、判定７２０、API呼び出し回数７３０、不良箇所実行回数７４０、呼び出しトレース７５０を含む。判定結果ログファイル７００はログ出力処理部１５５によって出力される。
【００３９】
修正ＩＤ７１０は不良を識別するＩＤである。判定ログ保存テーブル５００の修正ＩＤ５１０の値が出力される。判定７２０は修正ＩＤ７１０の不良に該当するか否かを表し、判定ログ保存テーブル５００の判定フラグ５４０の値が反映される。具体的には判定フラグ５４０が「Ｙ」であれば、判定７２０は「該当」となり、判定フラグ５４０が「Ｎ」であれば判定７２０は「非該当」となる。ＡＰＩ呼び出し回数７３０は修正ＩＤ７１０の不良ＡＰＩがプログラム実行中に何回呼び出されたかを表す。判定ログ保存テーブル５００のＡＰＩ呼び出し回数５５０の値が出力される。
【００４０】
不良箇所実行回数７４０は修正ＩＤ７１０の不良ＡＰＩがプログラム実行中に何回呼び出されたかを表す。判定ログ保存テーブル５００の不良箇所実行回数５６０の値が出力される。呼び出しトレース７５０は不良ＡＰＩが呼び出された時のスタックトレースを表す。トレース保存テーブル６００の呼び出しトレース６１０の内容が出力される。７６０、７７０、７８０はトレースを表している。７８０のＡＰＩから７７０のＡＰＩ、７７０のＡＰＩから７６０のＡＰＩが呼び出されていることを表す。
【００４１】
図８は本実施形態における非セキュリティ問題の不良ＡＰＩのメモリ上でのコードイメージ８００の一例を示す説明図である。判定ログ保存テーブル５００のセキュリティフラグ５２０がＮであり、コード書換フラグがYとなる不良に対して、バイトコード書換部１５２がバイトコード書換を行ったクラスのソースコードのイメージである。
【００４２】
非セキュリティ問題のコードイメージ８００では不良ＡＰＩを含むクラスのイメージを表している。一行目ではクラス名が記述されており（ステップ８１０）、２行目では不良ＡＰＩの名称が宣言されている（ステップ８２０）。不良ＡＰＩのコードの先頭からは順に判定フラグ処理部１６２（ステップ８３０）、呼び出し回数カウント部１６３（ステップ８４０）、トレース取得部１６４が埋め込まれる。If文８６０は条件分岐を表しており、条件文がtrueの場合のみ括弧内の処理が実行される。不良箇所（ステップ８８０）の直前に不良箇所実行回数カウント部１６５が埋め込まれる（ステップ８７０）。
【００４３】
図９は本実施形態におけるセキュリティ問題の不良APIのメモリ上でのコードイメージ９００の一例を示す説明図である。判定ログ保存テーブル５００のセキュリティフラグ５２０がＹであり、コード書換フラグがYとなる不良に対して、バイトコード書換部１５２がバイトコード書換を行ったクラスのソースコードのイメージである。
【００４４】
セキュリティ問題のコードイメージ９００では不良ＡＰＩを含むクラスのイメージを表している。一行目ではクラス名が記述されており（ステップ８１０）、２行目では不良ＡＰＩの名称が宣言されている（ステップ８２０）。不良ＡＰＩのコードの先頭には判定フラグ処理部１６２が埋め込まれる（ステップ８３０）。
【００４５】
図１０は本実施形態における情報発信処理時のフローチャート１０００である。プログラム提供元の計算機１０がユーザの計算機１２０へ判定用設定ファイル４００と不良情報３００を送信する際の流れを示したものである。情報発信処理１０００は図２でプログラム提供元２００によって実行される処理２０１の詳細である。情報発信処理１０００を行う時はまずファイル暗号化処理部７０が判定用設定ファイル４００を作成する(ステップ１０１０）。次に、判定用設定ファイル４００がセキュリティ問題を含むか判定する（ステップ１０２０）。具体的には判定用設定ファイル４００のセキュリティ４６０を確認し、「Ｙ」の不良が存在するか判定する。セキュリティ問題を含む場合はファイル暗号化処理部７０が判定用設定ファイル４００を暗号化し（ステップ１０３０）、セキュリティ問題を含まない場合は暗号化を行わない。最後に判定用設定ファイル４００と不良情報３００をユーザへ発信する。判定用設定ファイル４００を暗号化することでユーザから読み取れないようにし、ユーザにセキュリティ問題の発生条件を知られないという目的を達成する。
【００４６】
図１１は本実施形態における判定モード処理時のフローチャートである。ユーザが不良の該非判定を行う際にプログラム実行処理部１５０が実行する処理を説明した図である。
【００４７】
判定モード処理１１００は図２でユーザ２１０がプログラム実行処理部１５０に対して要求する処理である。プログラム実行処理部１５０を判定モードで起動するとまずファイル復号化処理部１５４が判定用設定ファイル４００を読み込む（ステップ１１１０）。ファイル復号化処理部１５４は判定用設定ファイル４００が暗号化されているかを判断し（ステップ１１２０）、暗号化されていれば復号化する（ステップ１１３０）。次に判定ログ保存テーブル５００のセキュリティフラグ５２０を設定する（ステップ１１４０）。具体的には判定用設定ファイル４００のセキュリティ４６０の値を各修正ＩＤ毎にセキュリティフラグ５２０に設定する。セキュリティフラグ５２０を設定すると、該当バージョン判定部１５３が該当するバージョンかを判定する（ステップ１１５０）。該当しないバージョンである場合は該当バージョン判定部１５３は判定ログ保存テーブル５００のコード書換フラグ５３０を「Ｎ」に設定する。次に、該当するオプションが設定されているかを判定する（ステップ１１６０）。ただし、１１５０で該当するバージョンでないと判定された場合はオプションの判定（ステップ１１６０）は行わない。該当するオプションが設定されていない場合は該当バージョン判定部１５３は判定ログ保存テーブル５００のコード書換フラグ５３０を「Ｎ」に設定する。
【００４８】
次に、ユーザ処理部１５６がアプリケーション操作を開始する（ステップ１１８０）。アプリケーション操作によってクラスロードが必要になると、クラスロード処理部１５１がクラスロード処理を行う（ステップ１１９０）。クラスロード処理１１９０では不良ＡＰＩにログ取得処理が埋め込まれる。詳細は図１２で説明する。クラスロード処理１１９０が終わるとＡＰＩ処理部１６１によってＡＰＩが実行される（ステップ１１０１）。ＡＰＩ実行時に不良ＡＰＩに埋め込まれたログ取得処理によってログ取得が実行される。全てのアプリケーション操作が終了する（ステップ１１０２）と、ログ出力処理部１５５が判定結果ログファイル７００を出力する。具体的には判定ログ保存テーブル５００とトレース保存テーブル６００に取得された情報を判定結果ログファイル７００に出力する。判定結果ログファイル７００の出力が終了すると判定モードでの処理が終了する。
【００４９】
図１２は本実施形態におけるクラスロード処理１１９０のフローチャートである。プログラム実行処理部１５０でプログラム実行中に新たなクラスロードが必要になった際に実施される処理を示した図である。クラスロード処理１１９０はアプリケーション実行時に必要となったクラスをロードし、不良ＡＰＩのバイトコードを書き換える処理であり、図１１に示す判定モード処理１１００で呼び出される。
【００５０】
クラスロード処理部１５１はまずロード対象クラスをバイトコード格納部１７０に読み込む（ステップ１２００）。次にロード対象クラスが不良ＡＰＩを含むかを確認する(ステップ１２１０）。具体的には判定用設定ファイル４００の該当ＡＰＩ４４０に記載されたＡＰＩをロード対象クラスが含むかを確認する。含まない場合はクラスロード処理を終了する。不良ＡＰＩを含む場合は次に判定ログ保存テーブル５００のコード書換フラグ５３０を確認し（ステップ１２２０）、フラグが「Ｎ」であれば、クラスロード処理を終了する。「Ｙ」であれば不良ＡＰＩに判定処理コードを埋め込む処理（ステップ１２３０）を行う。埋め込みが終了するとクラスロード処理を終了する。
【００５１】
図１３は本実施形態における不良ＡＰＩに判定処理コードを埋め込む処理１２３０のフローチャートである。不良ＡＰＩにログ取得処理を埋め込む処理であり、これにより不良ＡＰＩがＡＰＩ処理部１６１によって実行されるとログが取得できる。不良ＡＰＩに判定処理コードを埋め込む処理１２３０は図１２に示すクラスロード処理１１９０から呼び出される。
【００５２】
まず、バイトコード書換部１５２が不良ＡＰＩの先頭に判定フラグ処理部１６２を埋め込む（ステップ１３００）。これにより、ＡＰＩ処理部１６１によって不良ＡＰＩが実行されると判定ログ保存テーブル５００の判定フラグ５４０が「Ｙ」に更新される。
【００５３】
次に、判定ログ保存テーブル５００のセキュリティフラグ５２０を確認し、不良ＡＰＩがセキュリティ不良のＡＰＩであるか判定する（ステップ１３１０）。セキュリティ問題である場合は不良ＡＰＩに判定処理コードを埋め込む処理を終了する。セキュリティ問題でない場合は続いて呼出回数カウント処理部を埋め込む（ステップ１３２０）。これにより、ＡＰＩ処理部１６１によって不良ＡＰＩが実行されると判定ログ保存テーブル５００のＡＰＩ呼び出し回数５５０がインクリメントされる。
【００５４】
続いて、バイトコード書換部１５２は不良ＡＰＩにトレース取得処理部１６４を埋め込む（ステップ１３３０）。ＡＰＩ処理部１６１によって不良ＡＰＩが実行されるとトレース取得処理部１６４によって呼び出し時のスタックトレースが取得され、トレース保存テーブル６００の呼び出しトレース６２０に保存される。
【００５５】
以上の処理が終わると最後にバイトコード書換部は判定用設定ファイル４００の不良箇所のインデックス４５０の箇所に不良箇所実行回数カウント部１６３を埋め込む（ステップ１３４０）。ＡＰＩ処理部１６１によって不良ＡＰＩが実行され、かつ不良箇所が実行されると、判定ログ保存テーブル４００の不良箇所実行回数５６０の値がインクリメントされる。
【００５６】
本実施形態は、単純に不良ＡＰＩが使用されただけでは問題とならず、タイミングの問題であればＡＰＩの実行回数が多いか少ないかが重要となる。また、メモリリークの不良のように複数回実行されることで問題が顕在化する場合があるため、そのような場合は不良ＡＰＩの不良箇所を実行した回数が重要となる。また、不良ＡＰＩの呼び出し箇所が特定できれば不良ＡＰＩを呼び出さないようにコード修正するなどの回避が可能になる。また、呼び出し箇所の処理の重要性から不良がシステムに与える影響を判断できる。また、ユーザが自システムを構成するプログラムのソースコードを所持していない場合も該非判定が可能になる。また、不良ＡＰＩの実行回数、呼び出しトレースを取得することにより、不良がシステムに与える影響をユーザが確認することができる。
【符号の説明】
【００５７】
１０ プログラム提供元の計算機
１１ ネットワーク
２０ 出力装置
２１ 出力装置
３０ ＣＰＵ
３１ ＣＰＵ
４０ 入力装置
４１ 入力装置
５０ 通信アダプタ
５１ 通信アダプタ
６０ 主記憶装置
７０ ファイル暗号化処理部
８０ 情報発信処理部
９０ 補助記憶装置
９１ 補助記憶装置
１００ バス
１０１ バス
１２０ ユーザの計算機
１４０ 主記憶装置
１５０ プログラム実行処理部
１５１ クラスロード処理部
１５２ バイトコード書換部
１５３ 該当バージョン判定部
１５４ ファイル復号化処理部
１５５ ログ出力処理部
１５６ ユーザ処理部
１６０ ＡＰＩ
１６１ ＡＰＩ処理部
１６２ 判定フラグ処理部
１６３ 呼出回数カウント部
１６４ トレース取得部
１６５ 不良箇所実行回数カウント部
１７０ バイトコード格納部
３００ 不良情報
４００ 判定用設定ファイル
５００ 判定ログ保存テーブル
６００ トレース保存テーブル
７００ 判定結果ログファイル
【技術分野】
【０００１】
本発明は、情報処理システムを構成するプログラムの提供するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｔｅｒｆａｃｅ）に不良が判明した時に、情報処理システムが当該不良の影響を受けるか否かを判定する技術に関する。
【背景技術】
【０００２】
従来、プログラムの提供するＡＰＩに不良が存在することが判明した場合、プログラムの提供者は不良を修正した修正版を発行して、プログラムのユーザに提供し、修正版を適用するよう呼びかけている。プログラムのユーザである情報処理システムの開発者は自システムプログラムが不良に該当しているか非該当にがいとうしているかを判定し、該当している場合は修正版を適用し、予防保守を行っている。プログラム不良の該非判定を行い、予防保守を行うような技術は特許文献１で公開されている。特許文献１のような技術では、プログラムの提供元はプログラムの障害情報が蓄積されたデータベースを有しており、当該データベースが更新された場合にユーザの有する情報処理システムに対して該非判定を行うための確認プログラムを配布する。ユーザの有する情報処理システムは当該プログラムを実行することで自システムの構成ハードウェア、ソフトウェアで障害が発生するか否かを判定する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−１４１８７
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ユーザの有する情報処理システム（ユーザシステムと省略する）が自システムで不良ＡＰＩを使用しているか否かはシステムを構成するアプリケーションプログラムのソースコードが不良ＡＰＩを使用して実装されているか否かを調査する。しかし、プログラムの提供するＡＰＩの不良がセキュリティに関わる問題であった場合、セキュリティ攻撃の手法を公開することになるため、不良ＡＰＩや不良の発生条件といった詳細情報をプログラムのユーザに提供できない。そのため、ユーザシステムが自システムで不良ＡＰＩを使用しているかが分からず、修正版の適用判断ができない。
【０００５】
ユーザシステムを構成するプログラムのソースコードを所持していなくても該非判定を行い、また、情報処理システムは様々なプログラム部品を使用して実装されており、ユーザシステムは必ずしも自システムを構成する全てのプログラムのソースコードを所持していない。そのため、自システムで不良ＡＰＩを使用しているかが不明な場合がある。
【０００６】
本発明の目的は、プログラムの提供するＡＰＩに不良が判明した時に、ユーザシステムで発生条件を知らなくても、ユーザシステムの該非判定を行えるようにすることである。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、本発明では不良ＡＰＩを含むプログラムの提供元が不良の概要情報と不良ＡＰＩの詳細情報を暗号化した判定用設定ファイルとをネットワークを介してユーザシステムに提供し、ユーザシステムに判定用設定ファイルをＡＰＩの提供元であるプログラムに読み込ませ、プログラムはファイルを復号化して不良情報を読み取り、プログラム実行時に不良ＡＰＩを含むクラスが主記憶装置上にロードされるタイミングで主記憶装置上の不良ＡＰＩのバイトコードを書き換え、該非判定のためのログ情報を取得する処理を埋め込み、ユーザシステムが処理を実行して不良ＡＰＩが実行された時に取得したログ情報をユーザシステムに判定結果ログとしてファイル形式で提供し、ユーザシステムは判定結果ログファイルを参照して自システムへの影響を確認し、プログラムの修正版適用を判断する。
【発明の効果】
【０００８】
ＡＰＩを提供するプログラムを使用している情報処理システムにて、ＡＰＩに不良が発生した場合にユーザシステムが発生条件を知らなくても不良の該非判定を実施することが可能となる。
【図面の簡単な説明】
【０００９】
【図１】本実施形態における装置構成を示す構成図の一例である。
【図２】本実施形態における不良の該非判定を行う処理の流れを示す説明図である。
【図３】本実施形態におけるプログラム提供元からユーザに通知される不良情報の一例を示す説明図である。
【図４】本実施形態における判定用設定ファイルの一例を示す説明図である。
【図５】本実施形態における判定ログ保存テーブルの一例を示す説明図である。
【図６】本実施形態におけるトレース保存テーブルの一例を示す説明図である。
【図７】本実施形態における判定結果ログファイルの一例を示す説明図である。
【図８】本実施形態における非セキュリティ問題の不良ＡＰＩのバイトコード書換後のコードイメージの一例を示す説明図である。
【図９】本実施形態におけるセキュリティ問題の不良ＡＰＩのバイトコード書換後のコードイメージの一例を示す説明図である。
【図１０】本実施形態における情報発信処理時の流れを示すフローチャートである。
【図１１】本実施形態における判定モード処理時の流れを示すフローチャートである。
【図１２】本実施形態におけるクラスロード処理の流れを示すフローチャートである。
【図１３】本実施形態における不良ＡＰＩに判定処理コードを埋め込む処理の流れを示すフローチャートである。
【発明を実施するための形態】
【実施例１】
【００１０】
以下、本発明を実施するための形態（以下「実施形態」という）について、図面を参照して説明する。
【００１１】
図１は本実施形態における情報処理システムの装置構成の概要を示す説明図である。図１に示すように本実施形態ではプログラム提供元の計算機１０とユーザが使用する計算機１２０がネットワーク１１を通じて接続される。プログラム提供元の計算機１０はユーザが使用する計算機１２０に対して不良ＡＰＩの情報を情報発信する。ユーザの計算機１２０は複数存在してもよい。
【００１２】
プログラム提供元の計算機１０は、通信アダプタ５０、ＣＰＵ３０、入力装置４０、出力装置２０、補助記憶装置９０および主記憶装置６０を備え、バス１００を介して互いに接続される。通信アダプタ５０を利用してユーザが使用する計算機１２０へ接続し、判定用設定ファイル４００と不良情報３００とを送信する。
【００１３】
ユーザが使用する計算機１２０は、通信アダプタ５１、ＣＰＵ３１、入力装置４１、出力装置２１、補助記憶装置９１および主記憶装置１４０とを備え、バス１０１を介して互いに接続される。通信アダプタ５１を使用してプログラム提供元の計算機１０と通信を行う。
【００１４】
出力装置２０はプログラム提供元の計算機１０から出力される情報を表示する。
各処理部は、プログラムやオブジェクト、もしくは同等の機能を有するハードウェアで実現できる。本実施例は、各処理部がプログラムで実現された一例を示している。
【００１５】
ＣＰＵ３０は主記憶装置６０に記憶された各種処理部を実行することによって各種処理を実行する。入力装置４０はプログラム提供元の計算機１０に必要な情報および指示の入力に使用する。
【００１６】
通信アダプタ５０はネットワーク１１を介して通信アダプタ５１と通信する。
主記憶装置６０はファイル暗号化処理部７０と情報発信処理部８０を含む。プログラム提供元の計算機１０は主記憶装置６０上でユーザの計算機１０へ判定用設定ファイル４００と不良情報３００を送信するための処理を行う。
【００１７】
ファイル暗号化処理部７０は判定用設定ファイル４００を生成し、セキュリティ問題が含まれる場合には判定用設定ファイル４００を暗号化する。情報発信処理部８０はプログラム提供元の計算機１０からユーザの計算機１２０へ不良情報３００と判定用設定ファイル４００を送信する。補助記憶装置９０はプログラム提供元の計算機１０上でプログラム及びプログラムの実行に必要なデータを格納する。判定用設定ファイル４００は補助記憶装置９０に含まれる。
【００１８】
出力装置２１はユーザの計算機１２０から出力される情報を表示する。ＣＰＵ３１は主記憶装置６１に記憶された各種プログラムを実行することによって各種処理を実行する。入力装置４１はユーザの計算機１０に必要な情報および指示の入力に使用する。通信アダプタ５１はネットワーク１１を介して通信アダプタ５０と通信する。主記憶装置６１はプログラム実行処理部１５０を含む。不良の該非判定のための処理は主記憶装置６１上で行われる。
【００１９】
プログラム実行処理部１５０はクラスロード処理部１５１、バイトコード書換部１５２、該当バージョン判定部１５３、ファイル復号化処理部１５４、ログ出力処理部１５５、ユーザ処理部１５６、バイトコード格納部１７０を含む。クラスロード処理部１５１はＡＰＩ処理部１６１が必要とするクラスをバイトコード格納部１７０へ読み込む。読み込む際、該当バージョン判定部１５３を呼び出し、不良の該当バージョン判定を行い、該当し、かつロード対象クラスが不良ＡＰＩを含む場合はバイトコード書換部を呼び出し、ロード対象クラスのバイトコードを書き換える。
【００２０】
バイトコード書換部１５２はバイトコード格納部１７０に読み込まれたＡＰＩ１６０に判定フラグ処理部１６２を埋め込む。さらに、不良がセキュリティ問題でない場合は、呼出回数カウント部１６３、トレース取得部１６４、不良箇所実行回数カウント部１６５を埋め込む。
【００２１】
該当バージョン判定部１５３はユーザの計算機１２０上で動作するプログラムが不良が存在するバージョンに該当しているか判定する。ファイル復号化処理部１５４は判定用設定ファイル４００が暗号化されている場合、復号化処理を行う。ログ出力処理部１５５は判定結果ログファイル７００を出力する。ユーザ処理部１５６はＡＰＩ処理部１６１を使用してユーザプログラムの実行処理を行う。ＡＰＩ処理部１６１はユーザプログラムの実行処理を行う。判定フラグ処理部１６２は不良ＡＰＩが実行された時に判定ログ保存テーブル５００に該当フラグを保存する。呼出回数カウント部１６３は不良ＡＰＩが実行された回数を判定ログ保存テーブル５００に保存する。
【００２２】
トレース取得部１６４は不良ＡＰＩが実行された時のスレッドスタックトレースを取得し、トレース保存テーブル６００に保存する。不良箇所実行回数カウント部１６５は不良ＡＰＩの不良箇所が実行された回数をカウントし、判定ログ保存テーブル５００に保存する。
【００２３】
バイトコード格納部１７０はＡＰＩ１６０を含む。クラスロード処理部１５１によってロードされたＡＰＩを格納する。不良情報３００は不良の概要を含み、情報発信処理部８０によってプログラム提供元からユーザへ送付される。判定用設定ファイル４００は不良ＡＰＩの詳細情報を格納する。プログラム実行処理部１５０がプログラムを実行する際に読み取る。
【００２４】
判定ログ保存テーブル５００は判定フラグ処理部１６２、呼出回数カウント部１６３、不良箇所実行回数カウント部１６５で取得したログ情報を保存する。トレース保存テーブル６００はトレース取得部１６４で取得したログ情報を保存する。判定結果ログファイル７００は判定ログ保存テーブル５００、トレース保存テーブル６００に保存された情報を格納する。
【００２５】
図２は本実施形態における不良の該非判定を行う処理の流れの一例を示す説明図である。まず、プログラム提供元２００は判定用設定ファイル４００と不良情報３００をユーザが使用する計算機２１０へ送付する（２０１）。次に、ユーザが使用する計算機２１０はプログラム実行処理部１５０を判定モードで起動する（２１１）。判定モードで起動されるとプログラム実行処理部１５０は起動時に判定用設定ファイル４００を読み込む（２２１）。読み込みが終わると該当バージョン判定部１５３が、不良に該当するバージョン、オプション設定となっているか判定する（２２２）。判定が終わるとプログラム実行処理部１５０はユーザが使用する計算機２１０へ起動完了した旨を通知する（２２３）。起動完了の通知を受けるとユーザ２１０はアプリケーション処理を実行する（２１２）。
【００２６】
アプリケーション処理の実行によりクラスをロードする必要が生じるとプログラム実行処理部１５０はクラスロード処理を行う（２２４）。クラスロード処理ではプログラム実行処理部１５０は不良ＡＰＩのバイトコードへログ取得処理を埋め込む（２２５）。アプリケーション処理実行２１２により、ログ取得処理を埋め込んだＡＰＩが実行されるとログが取得される（２２６）。アプリケーション処理実行が終わるとユーザが使用する計算機２１０はプログラム実行処理部に対してログ出力要求を行う（２１３）。
【００２７】
ユーザが使用する計算機２１０からログ出力要求を受け取るとプログラム実行処理部１５０は判定結果ログファイル７００を出力する（２２７）。ログ出力が終わるとプログラム実行処理部１５０はユーザが使用する計算機２１０へログ出力の終了を通知する（２２８）。ログ出力終了を通知されるとユーザが使用する計算機２１０は判定結果ログファイル７００を確認する（２１４）。ユーザが使用する計算機２１０はログから修正版を適用するかしないか判断する（２１５）。修正版を適用すると判断した場合はユーザが使用する計算機２１０はプログラム提供元２００へ修正版の提供を要求する（２１６）。ユーザが使用する計算機２１０から修正版要求を受けるとプログラム提供元２００はユーザが使用する計算機２１０へ修正版を提供する（２０２）。修正版を提供されたらユーザが使用する計算機２１０は修正版を適用する（２１７）。以上で不良の該非判定は完了する（２１８）。
【００２８】
図３は本実施形態におけるプログラム提供元からユーザに通知される不良情報３００の一例を示す説明図である。ユーザは、ユーザが使用する計算機２１０より、判定結果ログファイル７００と不良情報３００の情報を元に自システムでの不良の影響度を判定する。不良情報３００は修正ＩＤ３１０、現象３２０、発生条件３３０、該当バージョン３４０、修正バージョン３５０を含む。修正ＩＤ３１０は不良を識別するためのＩＤを表示する。ＩＤは不良毎に固有の値を有する。
【００２９】
現象３２０は不良が発生した場合の現象を表示する。３２０Ａでは詳細な現象を表示する。発生条件３３０は不良の発生条件を表示する。３３０Ａは不良に該当するオプション設定を表示した例、３３０Ｂは不良を含むＡＰＩを表示した例である。セキュリティ問題の場合は非公開となる。該当バージョン３４０は不良が存在するプログラムのバージョン情報を表示する。３４０Ａは該当バージョンの表示例である。修正バージョン３５０は不良が修正されたプログラムのバージョン情報を表示する。３５０Ａは修正バージョンの表示例である。
【００３０】
図４は本実施形態における判定用設定ファイル４００の一例を示す説明図である。判定用設定ファイル４００は不良の該当するバージョンや不良の存在するＡＰＩの情報が記載されており、プログラム実行処理部１５０が不良の該非判定のためのログ出力処理をどのクラスのどのＡＰＩに埋め込むかを判断するのに用いる。
【００３１】
判定用設定ファイル４００は修正ＩＤ４１０、該当ＶＲＳ４２０、該当オプション４３０、該当ＡＰＩ４４０、不良箇所のインデックス４５０、セキュリティ４６０を含む。判定用設定ファイル４４０はプログラム実行処理部１５０が判定モードで起動した時にプログラム実行処理部１５０によって読み込まれ、不良ＡＰＩのバイトコードに該非判定のためのログ取得処理を埋め込むために使用される。修正ＩＤ４１０は不良の識別ＩＤ情報である。該当ＶＲＳ４２０は不良に該当するプログラムのバージョン情報である。該当バージョン判定部１５３によってプログラムのバージョンが該当バージョンであるか判定するために使用される。該当オプション４３０は不良に該当するオプション設定の情報である。該当バージョン判定部１５３によって不良に該当するオプションがプログラムに設定されているか判定するために使用される。
【００３２】
該当ＡＰＩ４４０は不良を含むＡＰＩの情報である。クラスロード処理部１５１がクラスをロードする時にロード対象クラスが不良ＡＰＩを含むか判定するために使用される。不良箇所のインデックス４５０は不良ＡＰＩのバイトコード中の不良箇所のインデックスである。バイトコード書換部１５２は不良箇所のインデックス４５０から不良ＡＰＩの不良箇所を特定し、不良箇所実行回数カウント部を不良ＡＰＩのバイトコードに埋め込む。セキュリティ４６０は不良がセキュリティ問題であるか否かを示し、判定ログ保存テーブル５００のセキュリティフラグ５２０に読み込まれる。
【００３３】
図５は本実施形態における判定ログ保存テーブル５００の一例を示す説明図である。判定ログ保存テーブル５００はプログラム実行中にプログラム実行処理部１５０が不良APIの実行状況を保存しておくテーブルである。判定ログ保存テーブル５００は主記憶装置１４０上に存在し、ログ出力処理部１５５が判定結果ログファイル７００を出力する際に参照される。
【００３４】
判定ログ保存テーブル５００は修正ＩＤ５１０、セキュリティフラグ５２０、コード書換フラグ５３０、判定フラグ５４０、ＡＰＩ呼出回数５５０、不良箇所実行回数５６０を含む。修正ＩＤ５１０は不良を識別するＩＤである。セキュリティフラグ５２０は修正ＩＤ５１０の不良がセキュリティ問題であるか否かを表す。「Ｙ」であればセキュリティ問題であることを表し、「Ｎ」であればセキュリティ問題ではないことを表す。バイトコード書換部１５２が不良ＡＰＩに呼出回数カウント部１６３、トレース取得部１６４、不良箇所実行回数カウント部１６５を埋め込むか否かを判定するのに用いる。
【００３５】
コード書換フラグ５３０はクラスロード処理部１５１が修正ＩＤ５１０の不良ＡＰＩのバイトコード書換処理をバイトコード書換処理部１５２に行わせるか否かを表す。「Ｙ」であればバイトコード書換を行い、「Ｎ」であればバイトコード書換を行わない。コード変換フラグは該当バージョン判定部１５３によって更新され、プログラムが修正ＩＤ５１０の該当バージョンであり、かつ該当オプションである場合のみ「Ｙ」となる。
【００３６】
判定フラグ５４０はプログラムが修正ＩＤ５１０の不良に該当しているかどうかを表す。「Ｙ」であれば不良に該当していることを表し、「Ｎ」であれば不良に該当していないことを表す。判定フラグ処理部１６２によって更新され、ユーザ処理部１５６によって不良ＡＰＩが実行された場合のみ「Ｙ」となる。ＡＰＩ呼出回数５５０は修正ＩＤ５１０の不良ＡＰＩがプログラム実行中に何回呼び出されたかを表す。呼出回数カウント部１６３によって更新される。不良箇所実行回数５６０は修正ＩＤ５１０の不良ＡＰＩのバイトコードのうち、不良箇所が何回実行されたかを表す。不良箇所実行回数カウント部によって更新される。
【００３７】
図６は本実施形態におけるトレース保存テーブル６００の一例を示す説明図である。トレース保存テーブル６００はプログラム実行中にトレース取得部１６４が取得した不良ＡＰＩの呼び出しトレースを保存するテーブルである。トレース保存テーブル６００は主記憶装置１４０上に存在し、ログ出力処理部１５５が判定結果ログファイル７００を出力する際に参照される。修正ＩＤ６１０と呼び出しトレース６２０を含む。修正ＩＤ６１０は不良を識別するＩＤである。呼び出しトレース６２０は不良ＡＰＩが呼び出された時のスタックトレースを表す。トレース取得部１６４によって更新される。
【００３８】
図７は本実施形態における判定結果ログファイル７００の一例を示す説明図である。判定結果ログファイル７００は不良の該非判定結果を出力したログファイルである。半知恵結果ログファイル７００をユーザが参照し、修正版の適用判断を行う。判定結果ログファイル７００は修正ＩＤ７１０、判定７２０、API呼び出し回数７３０、不良箇所実行回数７４０、呼び出しトレース７５０を含む。判定結果ログファイル７００はログ出力処理部１５５によって出力される。
【００３９】
修正ＩＤ７１０は不良を識別するＩＤである。判定ログ保存テーブル５００の修正ＩＤ５１０の値が出力される。判定７２０は修正ＩＤ７１０の不良に該当するか否かを表し、判定ログ保存テーブル５００の判定フラグ５４０の値が反映される。具体的には判定フラグ５４０が「Ｙ」であれば、判定７２０は「該当」となり、判定フラグ５４０が「Ｎ」であれば判定７２０は「非該当」となる。ＡＰＩ呼び出し回数７３０は修正ＩＤ７１０の不良ＡＰＩがプログラム実行中に何回呼び出されたかを表す。判定ログ保存テーブル５００のＡＰＩ呼び出し回数５５０の値が出力される。
【００４０】
不良箇所実行回数７４０は修正ＩＤ７１０の不良ＡＰＩがプログラム実行中に何回呼び出されたかを表す。判定ログ保存テーブル５００の不良箇所実行回数５６０の値が出力される。呼び出しトレース７５０は不良ＡＰＩが呼び出された時のスタックトレースを表す。トレース保存テーブル６００の呼び出しトレース６１０の内容が出力される。７６０、７７０、７８０はトレースを表している。７８０のＡＰＩから７７０のＡＰＩ、７７０のＡＰＩから７６０のＡＰＩが呼び出されていることを表す。
【００４１】
図８は本実施形態における非セキュリティ問題の不良ＡＰＩのメモリ上でのコードイメージ８００の一例を示す説明図である。判定ログ保存テーブル５００のセキュリティフラグ５２０がＮであり、コード書換フラグがYとなる不良に対して、バイトコード書換部１５２がバイトコード書換を行ったクラスのソースコードのイメージである。
【００４２】
非セキュリティ問題のコードイメージ８００では不良ＡＰＩを含むクラスのイメージを表している。一行目ではクラス名が記述されており（ステップ８１０）、２行目では不良ＡＰＩの名称が宣言されている（ステップ８２０）。不良ＡＰＩのコードの先頭からは順に判定フラグ処理部１６２（ステップ８３０）、呼び出し回数カウント部１６３（ステップ８４０）、トレース取得部１６４が埋め込まれる。If文８６０は条件分岐を表しており、条件文がtrueの場合のみ括弧内の処理が実行される。不良箇所（ステップ８８０）の直前に不良箇所実行回数カウント部１６５が埋め込まれる（ステップ８７０）。
【００４３】
図９は本実施形態におけるセキュリティ問題の不良APIのメモリ上でのコードイメージ９００の一例を示す説明図である。判定ログ保存テーブル５００のセキュリティフラグ５２０がＹであり、コード書換フラグがYとなる不良に対して、バイトコード書換部１５２がバイトコード書換を行ったクラスのソースコードのイメージである。
【００４４】
セキュリティ問題のコードイメージ９００では不良ＡＰＩを含むクラスのイメージを表している。一行目ではクラス名が記述されており（ステップ８１０）、２行目では不良ＡＰＩの名称が宣言されている（ステップ８２０）。不良ＡＰＩのコードの先頭には判定フラグ処理部１６２が埋め込まれる（ステップ８３０）。
【００４５】
図１０は本実施形態における情報発信処理時のフローチャート１０００である。プログラム提供元の計算機１０がユーザの計算機１２０へ判定用設定ファイル４００と不良情報３００を送信する際の流れを示したものである。情報発信処理１０００は図２でプログラム提供元２００によって実行される処理２０１の詳細である。情報発信処理１０００を行う時はまずファイル暗号化処理部７０が判定用設定ファイル４００を作成する(ステップ１０１０）。次に、判定用設定ファイル４００がセキュリティ問題を含むか判定する（ステップ１０２０）。具体的には判定用設定ファイル４００のセキュリティ４６０を確認し、「Ｙ」の不良が存在するか判定する。セキュリティ問題を含む場合はファイル暗号化処理部７０が判定用設定ファイル４００を暗号化し（ステップ１０３０）、セキュリティ問題を含まない場合は暗号化を行わない。最後に判定用設定ファイル４００と不良情報３００をユーザへ発信する。判定用設定ファイル４００を暗号化することでユーザから読み取れないようにし、ユーザにセキュリティ問題の発生条件を知られないという目的を達成する。
【００４６】
図１１は本実施形態における判定モード処理時のフローチャートである。ユーザが不良の該非判定を行う際にプログラム実行処理部１５０が実行する処理を説明した図である。
【００４７】
判定モード処理１１００は図２でユーザ２１０がプログラム実行処理部１５０に対して要求する処理である。プログラム実行処理部１５０を判定モードで起動するとまずファイル復号化処理部１５４が判定用設定ファイル４００を読み込む（ステップ１１１０）。ファイル復号化処理部１５４は判定用設定ファイル４００が暗号化されているかを判断し（ステップ１１２０）、暗号化されていれば復号化する（ステップ１１３０）。次に判定ログ保存テーブル５００のセキュリティフラグ５２０を設定する（ステップ１１４０）。具体的には判定用設定ファイル４００のセキュリティ４６０の値を各修正ＩＤ毎にセキュリティフラグ５２０に設定する。セキュリティフラグ５２０を設定すると、該当バージョン判定部１５３が該当するバージョンかを判定する（ステップ１１５０）。該当しないバージョンである場合は該当バージョン判定部１５３は判定ログ保存テーブル５００のコード書換フラグ５３０を「Ｎ」に設定する。次に、該当するオプションが設定されているかを判定する（ステップ１１６０）。ただし、１１５０で該当するバージョンでないと判定された場合はオプションの判定（ステップ１１６０）は行わない。該当するオプションが設定されていない場合は該当バージョン判定部１５３は判定ログ保存テーブル５００のコード書換フラグ５３０を「Ｎ」に設定する。
【００４８】
次に、ユーザ処理部１５６がアプリケーション操作を開始する（ステップ１１８０）。アプリケーション操作によってクラスロードが必要になると、クラスロード処理部１５１がクラスロード処理を行う（ステップ１１９０）。クラスロード処理１１９０では不良ＡＰＩにログ取得処理が埋め込まれる。詳細は図１２で説明する。クラスロード処理１１９０が終わるとＡＰＩ処理部１６１によってＡＰＩが実行される（ステップ１１０１）。ＡＰＩ実行時に不良ＡＰＩに埋め込まれたログ取得処理によってログ取得が実行される。全てのアプリケーション操作が終了する（ステップ１１０２）と、ログ出力処理部１５５が判定結果ログファイル７００を出力する。具体的には判定ログ保存テーブル５００とトレース保存テーブル６００に取得された情報を判定結果ログファイル７００に出力する。判定結果ログファイル７００の出力が終了すると判定モードでの処理が終了する。
【００４９】
図１２は本実施形態におけるクラスロード処理１１９０のフローチャートである。プログラム実行処理部１５０でプログラム実行中に新たなクラスロードが必要になった際に実施される処理を示した図である。クラスロード処理１１９０はアプリケーション実行時に必要となったクラスをロードし、不良ＡＰＩのバイトコードを書き換える処理であり、図１１に示す判定モード処理１１００で呼び出される。
【００５０】
クラスロード処理部１５１はまずロード対象クラスをバイトコード格納部１７０に読み込む（ステップ１２００）。次にロード対象クラスが不良ＡＰＩを含むかを確認する(ステップ１２１０）。具体的には判定用設定ファイル４００の該当ＡＰＩ４４０に記載されたＡＰＩをロード対象クラスが含むかを確認する。含まない場合はクラスロード処理を終了する。不良ＡＰＩを含む場合は次に判定ログ保存テーブル５００のコード書換フラグ５３０を確認し（ステップ１２２０）、フラグが「Ｎ」であれば、クラスロード処理を終了する。「Ｙ」であれば不良ＡＰＩに判定処理コードを埋め込む処理（ステップ１２３０）を行う。埋め込みが終了するとクラスロード処理を終了する。
【００５１】
図１３は本実施形態における不良ＡＰＩに判定処理コードを埋め込む処理１２３０のフローチャートである。不良ＡＰＩにログ取得処理を埋め込む処理であり、これにより不良ＡＰＩがＡＰＩ処理部１６１によって実行されるとログが取得できる。不良ＡＰＩに判定処理コードを埋め込む処理１２３０は図１２に示すクラスロード処理１１９０から呼び出される。
【００５２】
まず、バイトコード書換部１５２が不良ＡＰＩの先頭に判定フラグ処理部１６２を埋め込む（ステップ１３００）。これにより、ＡＰＩ処理部１６１によって不良ＡＰＩが実行されると判定ログ保存テーブル５００の判定フラグ５４０が「Ｙ」に更新される。
【００５３】
次に、判定ログ保存テーブル５００のセキュリティフラグ５２０を確認し、不良ＡＰＩがセキュリティ不良のＡＰＩであるか判定する（ステップ１３１０）。セキュリティ問題である場合は不良ＡＰＩに判定処理コードを埋め込む処理を終了する。セキュリティ問題でない場合は続いて呼出回数カウント処理部を埋め込む（ステップ１３２０）。これにより、ＡＰＩ処理部１６１によって不良ＡＰＩが実行されると判定ログ保存テーブル５００のＡＰＩ呼び出し回数５５０がインクリメントされる。
【００５４】
続いて、バイトコード書換部１５２は不良ＡＰＩにトレース取得処理部１６４を埋め込む（ステップ１３３０）。ＡＰＩ処理部１６１によって不良ＡＰＩが実行されるとトレース取得処理部１６４によって呼び出し時のスタックトレースが取得され、トレース保存テーブル６００の呼び出しトレース６２０に保存される。
【００５５】
以上の処理が終わると最後にバイトコード書換部は判定用設定ファイル４００の不良箇所のインデックス４５０の箇所に不良箇所実行回数カウント部１６３を埋め込む（ステップ１３４０）。ＡＰＩ処理部１６１によって不良ＡＰＩが実行され、かつ不良箇所が実行されると、判定ログ保存テーブル４００の不良箇所実行回数５６０の値がインクリメントされる。
【００５６】
本実施形態は、単純に不良ＡＰＩが使用されただけでは問題とならず、タイミングの問題であればＡＰＩの実行回数が多いか少ないかが重要となる。また、メモリリークの不良のように複数回実行されることで問題が顕在化する場合があるため、そのような場合は不良ＡＰＩの不良箇所を実行した回数が重要となる。また、不良ＡＰＩの呼び出し箇所が特定できれば不良ＡＰＩを呼び出さないようにコード修正するなどの回避が可能になる。また、呼び出し箇所の処理の重要性から不良がシステムに与える影響を判断できる。また、ユーザが自システムを構成するプログラムのソースコードを所持していない場合も該非判定が可能になる。また、不良ＡＰＩの実行回数、呼び出しトレースを取得することにより、不良がシステムに与える影響をユーザが確認することができる。
【符号の説明】
【００５７】
１０ プログラム提供元の計算機
１１ ネットワーク
２０ 出力装置
２１ 出力装置
３０ ＣＰＵ
３１ ＣＰＵ
４０ 入力装置
４１ 入力装置
５０ 通信アダプタ
５１ 通信アダプタ
６０ 主記憶装置
７０ ファイル暗号化処理部
８０ 情報発信処理部
９０ 補助記憶装置
９１ 補助記憶装置
１００ バス
１０１ バス
１２０ ユーザの計算機
１４０ 主記憶装置
１５０ プログラム実行処理部
１５１ クラスロード処理部
１５２ バイトコード書換部
１５３ 該当バージョン判定部
１５４ ファイル復号化処理部
１５５ ログ出力処理部
１５６ ユーザ処理部
１６０ ＡＰＩ
１６１ ＡＰＩ処理部
１６２ 判定フラグ処理部
１６３ 呼出回数カウント部
１６４ トレース取得部
１６５ 不良箇所実行回数カウント部
１７０ バイトコード格納部
３００ 不良情報
４００ 判定用設定ファイル
５００ 判定ログ保存テーブル
６００ トレース保存テーブル
７００ 判定結果ログファイル
【特許請求の範囲】
【請求項１】
プログラムと前記プログラム上で実行されるアプリケーションを格納する記憶装置を備えた情報処理装置における不良該非判定手法おいて、
前記プログラムの提供するアプリケーション・インタフェース（以下、ＡＰＩと略）に不良を検出した場合に、暗号化した設定ファイルを含む前記プログラムを配布し、前記設定ファイルを前記プログラムに読み込ませて、前記プログラムがメモリ上の前記ＡＰＩのバイトコードにログ取得処理を埋め込むことで前記作成された情報処理システムにて使用しているか否かを判定し、
前記ＡＰＩを使用しているか否かの判定は前記プログラム上で前記アプリケーションを実行することで判定し、
前記ＡＰＩを使用している場合は前記ＡＰＩの呼び出し回数、呼び出しトレースをログ出力することにより前記ユーザが前記情報処理システムへの影響を判断できるように出力することを特徴とする不良該非判定手法。
【請求項１】
プログラムと前記プログラム上で実行されるアプリケーションを格納する記憶装置を備えた情報処理装置における不良該非判定手法おいて、
前記プログラムの提供するアプリケーション・インタフェース（以下、ＡＰＩと略）に不良を検出した場合に、暗号化した設定ファイルを含む前記プログラムを配布し、前記設定ファイルを前記プログラムに読み込ませて、前記プログラムがメモリ上の前記ＡＰＩのバイトコードにログ取得処理を埋め込むことで前記作成された情報処理システムにて使用しているか否かを判定し、
前記ＡＰＩを使用しているか否かの判定は前記プログラム上で前記アプリケーションを実行することで判定し、
前記ＡＰＩを使用している場合は前記ＡＰＩの呼び出し回数、呼び出しトレースをログ出力することにより前記ユーザが前記情報処理システムへの影響を判断できるように出力することを特徴とする不良該非判定手法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１３−３００３１（Ｐ２０１３−３００３１Ａ）
【公開日】平成２５年２月７日（２０１３．２．７）
【国際特許分類】
【出願番号】特願２０１１−１６６１８５（Ｐ２０１１−１６６１８５）
【出願日】平成２３年７月２９日（２０１１．７．２９）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２５年２月７日（２０１３．２．７）
【国際特許分類】
【出願日】平成２３年７月２９日（２０１１．７．２９）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]