JP5955165B2 - 管理装置、管理方法及び管理プログラム - Google Patents

Description

本発明は、管理装置、管理方法及び管理プログラムに関する。

顧客システムの保守及び運用を監視する監視システムでは、顧客システムの障害発生時に、障害内容に加えて、メッセージやログ情報等の付帯情報を保守センタに通知する。保守センタは、付帯情報に基づき障害内容に対するトラブルシューティングで障害の早期解決を図る。

また、保守センタでは、例えば、ハードウェア出荷やソフトウェア商品化等のタイミングで、製造者側で保証する正常なシステム構成を登録したホワイトリストや、例えば、製造者側で把握している障害のシステム構成を登録したブラックリストを管理している。そして、保守センタでは、ホワイトリストやブラックリストを参照し、顧客システムから収集したシステム構成と比較することで障害の有無を判定する。

特表２００７−５０６１８７号公報 特開２００８−２９３０３３号公報 特開２００８−１３５００４号公報 特表２００４−５１３４１２号公報

しかしながら、各顧客システムのシステム構成や障害内容等のデータ量は膨大であり、そもそも、障害の事例も障害の発生回数や時間の経過に応じて日々変動する。例えば、ホワイトリストやブラックリストに存在しない事例も多く、事例の発生回数や時間経過の変化に応じてリストの内容を動的に変更するのは困難である。

一つの側面では、事例回数の変化や時間の経過に応じてリストの内容を動的に変更できる管理装置、管理方法及び管理プログラムを提供することを目的とする。

一つの案の管理装置では、電子機器の構成情報を定期的に受信する受信部と、前記構成情報を時間情報と対応付けて記憶する記憶部とを有する。更に、管理装置は、第１の状態を示す構成情報を記憶する第１のリストと、前記第１の状態ではない第２の状態を示す構成情報を記憶する第２のリストとを有する。更に、管理装置は、前記第１の状態または第２の状態のいずれであるか不明である第３の状態を示す構成情報を記憶する第３のリストと、前記構成情報毎に、前記第１の状態を示す事例の発生回数を記憶する事例リストとを有する。更に、管理装置は、前記記憶部に記憶された構成情報および時間情報と、前記事例リストに記憶された構成情報および発生回数とに基づき、前記第１のリストと前記第２のリストとの間、前記第２のリストと前記第３のリストとの間、または、前記第３のリストと前記第１のリストとの間で、前記構成情報を移動してリストを更新する更新部を有する。

開示の態様では、事例回数の変化や時間の経過に応じてリストの内容を動的に変更できる。

図１は、実施例の監視システムの一例を示す説明図である。 図２は、構成情報の一例を示す説明図である。 図３は、ビッグＤＢのテーブル構成の一例を模式化した説明図である。 図４は、蓄積ＤＢのテーブル構成の一例を示す説明図である。 図５は、サーバ内のＣＰＵで実行する障害判定プロセスの一例を示す説明図である。 図６は、サーバ内のＣＰＵで実行するリスト更新プロセスの一例を示す説明図である。 図７は、構成変更チェック処理に関わるサーバ内のＣＰＵの処理動作の一例を示すフローチャートである。 図８は、障害判定処理に関わるサーバ内のＣＰＵの処理動作の一例を示すフローチャートである。 図９は、アンノウンリスト判定処理に関わるサーバ内のＣＰＵの処理動作の一例を示すフローチャートである。 図１０は、イエローリスト判定処理に関わるサーバ内のＣＰＵの処理動作の一例を示すフローチャートである。 図１１は、ベリファイドリスト判定処理に関わるサーバ内のＣＰＵの処理動作の一例を示すフローチャートである。 図１２は、管理プログラムを実行する情報処理装置を示す説明図である。

以下、図面に基づいて、本願の開示する管理装置、管理方法及び管理プログラムの実施例を詳細に説明する。尚、本実施例により、開示技術が限定されるものではない。また、以下に示す各実施例は、矛盾を起こさない範囲で適宜組み合わせても良い。

図１は、実施例の監視システムの一例を示す説明図である。図１に示す監視システム１は、複数の顧客システム２と、監視センタ３とを有する。監視センタ３は、例えば、遠隔地にある複数の顧客システム２の状態をリモート監視する。監視センタ３は、サーバ４と、データベース（以下、単にＤＢと称する）装置５と、障害監視装置６とを有する。

顧客システム２は、例えば、コンピュータ装置等の電子機器で構成し、通信インタフェース（以下、単にＩＦと称する）１１と、表示部１２と、操作部１３と、ＴＰＭ（Trusted Platform Module）チップ１４とを有する。更に、顧客システム２は、ＨＤＤ(Hard Disk Drive)１５と、ＲＡＭ(Random Access Memory)１６と、ＣＰＵ(Control Processing Unit)１７と、バス１８とを有する。通信ＩＦ１１は、サーバ４との間の通信を司るＩＦである。表示部１２は、各種情報を表示する出力ＩＦである。操作部１３は、各種情報を入力する入力ＩＦである。ＨＤＤ１５は、各種情報を記憶する不揮発性の記憶領域である。ＲＡＭ１６は、各種情報を記憶する揮発性の記憶領域である。ＣＰＵ１７は、顧客システム２全体を制御する。バス１８は、通信ＩＦ１１、表示部１２、操作部１３、ＴＰＭチップ１４、ＨＤＤ１５、ＲＡＭ１６及びＣＰＵ１７間でデータを伝送する伝送経路である。

ここで、ＴＰＭチップの特徴について説明する。ＴＰＭチップは、ＴＣＧ（Trusted Computing Group）技術を採用したチップである。近年、インターネットに接続されるデバイスには、常にセキュリティの脅威に曝され、ウィルス、スパイウェア、その他、悪質なスクリプト、不正アクセス等で、プラットフォームを構成するソフトウェア構造に予期せぬ改変が加えられるリスクがある。ＴＣＧでは、プラットフォームの信頼性を保証することで安全なコンピューティング環境を実現している。尚、プラットフォームとは、例えば、ハードウェア、ＯＳ（Operating System）やアプリケーション等である。例えば、ソフトウェアの改竄という脅威に対しては、従来のソフトウェアのみに依存したセキュリティ対策には限界がある。そこで、ＴＣＧでは、プラットフォーム内にＴＰＭチップを埋め込み、かかるＴＰＭチップを信頼のルートとして、改竄が困難な信頼性の高いコンピューティング環境を構築している。更に、ＴＣＧでは、ＴＰＭチップを利用して、ハードウェアベースでのデータや証明書の保護、安全な暗号化処理を実現している。

ＴＰＭチップは、耐タンパー性を備えたチップであって、電子機器から取り外しができないように、電子機器の主要な構成部位、例えば、マザーボード等に物理的に搭載されるものである。また、ＴＰＭチップの機能には、ＲＳＡ（Rivest Shamir Adleman）の秘密鍵及び公開鍵のペアの生成・保管の機能や、ＲＳＡ秘密鍵による署名、暗号化や復号の機能がある。また、ＴＰＭチップの機能には、ＳＨＡ−１（Secure Hash Algorithm １）のハッシュ値を演算する機能や、電子機器の環境情報を保持する機能等がある。

また、ＴＣＧでは、上位のアプリケーションやライブラリからハードウェア・デバイスであるＴＰＭチップを利用するため、ソフトウェア・スタックとソフトウェアインターフェースとを規定している。ソフトウェア・スタックは、ＴＳＳ（TCG Software Stack）と呼ばれ、リソースが制限されるＴＰＭチップの機能を保管するソフトウェアモジュールから構成されている。また、電子機器内のＣＰＵのアプリケーションは、ＴＳＳの提供するインタフェースを利用して、ＴＰＭチップの機能にアクセスするものである。

また、ＴＰＭチップは、電子機器のＣＰＵが起動した時点で、ＢＩＯＳ（Basic Input/Output System）、ＯＳｌｏａｄｅｒ、ＯＳカーネルへのブートプロセスでのソフトウェアコードを取得する。ＴＰＭチップは、取得されたソフトウェアコードをハッシュ化してソフト構成のハッシュ値を得る。そして、ＴＰＭチップは、そのソフト構成のハッシュ値をＴＰＭチップ内部のレジスタに登録する。また、ＴＰＭチップは、電子機器のハードウェア構成の情報を取得し、ハードウェア構成の情報をハッシュ化してハード構成のハッシュ値を得る。そして、ＴＰＭチップは、そのハード構成のハッシュ値をＴＰＭチップ内部のレジスタに登録する。つまり、ＴＰＭチップでは、電子機器のソフト構成のハッシュ値及びハード構成のハッシュ値をレジスタ内に登録する。

図２は、構成情報の一例を示す説明図である。図２に示すソフトウェア情報、ソフトウェア設定値、ＯＳ情報及びＯＳ設定値等は、顧客システム２のソフトウェアコードである。ハードウェア情報は、顧客システム２のハードウェア情報である。ＴＰＭチップ１４は、ソフトウェア情報をハッシュ化してハッシュ値Ａ１を得る。ＴＰＭチップ１４は、ソフトウェア設定値をハッシュ化してハッシュ値Ａ２を得る。ＴＰＭチップ１４は、ＯＳ情報をハッシュ化してハッシュ値Ａ３を得る。ＴＰＭチップ１４は、ＯＳ設定値をハッシュ化してハッシュ値Ａ４を得る。ＴＰＭチップ１４は、ハードウェア情報をハッシュ化してハッシュ値Ａ５を得る。更に、ＴＰＭチップ１４は、ソフトウェア情報のハッシュ値Ａ１、ソフトウェア設定値のハッシュ値Ａ２、ＯＳ情報のハッシュ値Ａ３、ＯＳ設定値のハッシュ値Ａ４、ハードウェア情報のハッシュ値Ａ５をハッシュ化して代表ハッシュ値Ａを得る。構成情報は、ソフト構成のハッシュ値Ａ１，Ａ２，Ａ３，Ａ４及び／又はハード構成のハッシュ値Ａ５と、代表ハッシュ値Ａとを有する。

次に、サーバ４は、例えば、コンピュータ装置で構成し、通信ＩＦ２１と、表示部２２と、操作部２３と、ＴＰＭチップ２４と、ＨＤＤ２５と、ＲＡＭ２６と、ＣＰＵ２７と、バス２８とを有する。サーバ４側のＴＰＭチップ２４は、顧客システム２側のＴＰＭチップ１４でハッシュ値を採取する際のルールをハッシュ化及び署名付与して管理することで、ハッシュ値採取の正当性を担保するものである。しかも、ＴＰＭチップ２４は、必要に応じて、現時点でのルール及び署名をチェックすることで、ルールの非改竄性を証明する。その結果、ＴＰＭチップ１４は、ＴＰＭチップ２４側で非改竄性が証明されたルールを参照しながら運用することでハッシュ値を採取する際のルールに改竄がないことを保証する。しかも、顧客システム２に派遣された監視センタ３内の作業者が勝手に改竄していないことも保証できる。

ＤＢ装置５は、比較ＤＢ３０と、蓄積ＤＢ４０とを有する。比較ＤＢ３０は、顧客システム２の構成変更、障害や正常等の判定に使用するリスト等を格納している。比較ＤＢ３０には、ホワイトリスト３１と、ブラックリスト３２と、イエローリスト３３と、ベリファイドリスト３４と、アンノウンリスト３５と、ビッグＤＢ３６とが格納してある。

ホワイトリスト３１には、例えば、ハード出荷、ソフト商品化、パッチ提供等のタイミングで製造者側が保証した組合せ可能の正常なシステム構成の構成情報が登録してある。尚、ホワイトリスト３１内に登録した構成情報は、システム構成のソフト構成及びハード構成に対応したハッシュ値を含む。サーバ４は、ホワイトリスト３１を参照して顧客システム２側のシステム構成が正常状態のシステム構成であるか否かを判定する。

ブラックリスト３２には、例えば、製造者側で検証済みの障害事例のシステム構成に対応した構成情報が登録してある。尚、ブラックリスト３２内に登録した構成情報は、システム構成のソフト構成及びハード構成に対応したハッシュ値を含む。サーバ４は、ブラックリスト３２を参照して顧客システム２側のシステム構成が障害事例のシステム構成であるか否かを判定する。尚、検証済みの障害事例には、検証済みの障害が発生する虞が大の事例も含めても良い。

イエローリスト３３には、ブラックリスト３２には該当しないものの、原因不明で未検証の障害事例のシステム構成に対応した構成情報が登録してある。尚、イエローリスト３３に登録した構成情報は、システム構成のソフト構成及びハード構成に対応したハッシュ値を含む。サーバ４は、イエローリスト３３を参照して顧客システム２側のシステム構成が原因不明の障害事例のシステム構成であるか否かを判定する。尚、原因不明の障害事例には、原因不明の障害が発生する虞が大の事例も含めても良い。また、第１のリストの一例として、例えば、イエローリスト３３がある。

ベリファイドリスト３４は、運用の中で検証済みのシステム構成に対応した構成情報が登録してある。尚、ベリファイドリスト３４内に登録した構成情報は、システム構成のソフト構成及びハード構成に対応したハッシュ値を含む。サーバ４は、ベリファイドリスト３４を参照して顧客システム２側のシステム構成が検証済みの正常状態のシステム構成であるか否かを判定する。また、第２のリストの一例として、例えば、ベリファイドリスト３４がある。

アンノウンリスト３５は、ホワイトリスト３１、ブラックリスト３２、イエローリスト３３及びベリファイドリスト３４の何れにも該当しない、未知のシステム構成に対応した構成情報が登録してある。また、第３のリストの一例として、例えば、アンノウンリスト３５がある。

図３は、ビッグＤＢ３６のテーブル構成の一例を示す説明図である。図３に示すビッグＤＢ３６には、各顧客システム２から収集した構成情報３６Ａを、その顧客システム２を識別するシステムＩＤ３６Ｂ及び、当該構成情報３６Ａを収集した日付等の時間情報３６Ｃを対応付けたビッグデータが記憶してある。記憶部の一例としては、例えば、ビッグＤＢ３６がある。

蓄積ＤＢ４０は、各顧客システム２から収集した構成情報を顧客システム２毎に順次記憶したＤＢである。図４は、蓄積ＤＢ４０のテーブル構成の一例を示す説明図である。図４に示す蓄積ＤＢ４０は、日付４１と、システムＩＤ４２と、ロケーションＩＤ４３と、代表ハッシュ値４４と、ハッシュ値４５とを対応付けて記憶する。日付４１は、例えば、サーバ４側で顧客システム２から構成情報を収集した日付である。システムＩＤ４２は、構成情報の送信元である顧客システム２を識別するＩＤである。ロケーションＩＤ４３は、送信元の顧客システム２の設置場所を示すＩＤである。代表ハッシュ値４４は、構成情報内の代表ハッシュ値である。ハッシュ値４５は、構成情報内のソフト構成及びハード構成のハッシュ値である。

障害監視装置６は、障害の事例情報をサーバ４に報知する装置である。尚、障害の事例情報には、障害内容と、例えば、障害のシステム構成に対応したソフト構成及び／又はハード構成のハッシュ値とを含む。

顧客システム２のＣＰＵ１７は、ＴＰＭチップ１４で得た構成情報をサーバ４側のＴＰＭチップ２４の公開鍵を認証局から取得し、取得された公開鍵を使用して構成情報を暗号化する。更に、ＣＰＵ１７は、通信ＩＦ１１を通じて暗号化した構成情報をサーバ４に伝送する。更に、サーバ４のＣＰＵ２７は、通信ＩＦ２１を通じて、顧客システム２から構成情報を受信する。そして、サーバ４内のＴＰＭチップ２４は、自分が保有する秘密鍵で受信した顧客システム２の構成情報を復号する。尚、顧客システム２は、サーバ４に対して構成情報の他に、顧客システム２を識別するシステムＩＤやロケーションＩＤ等の情報も伝送するものである。

図５は、サーバ４内のＣＰＵ２７で実行する障害判定プロセスの一例を示す説明図である。ＣＰＵ２７は、ＨＤＤ２５に格納された障害判定プログラムを読み出し、障害判定プログラムに基づき障害判定プロセスを実行して構成情報収集部５１、構成変更判定部５２、構成変更報知部５３、障害判定部５４、障害報知部５５を機能として実行する。構成情報収集部５１は、ＴＰＭチップ２４で復号した顧客システム２の構成情報を収集する。構成情報収集部５１は、収集した構成情報３６Ａを顧客システム２のシステムＩＤ３６Ｂ及び取得日（時間情報）３６Ｃに対応付けてビッグＤＢ３６に記憶する。

構成変更判定部５２は、代表ハッシュ比較部５２Ａを有する。代表ハッシュ比較部５２Ａは、蓄積ＤＢ４０を参照し、復号した構成情報内の代表ハッシュ値と同一のシステムＩＤ４２、かつ、同一の代表ハッシュ値４４があるか否かを判定する。

構成変更判定部５２は、代表ハッシュ比較部５２Ａの比較結果に基づき、蓄積ＤＢ４０を参照し、該当代表ハッシュ値と同一のシステムＩＤ４２、かつ、同一の代表ハッシュ値がある場合、今回の構成情報に関わる顧客システム２の構成変更なしと判定する。構成変更判定部５２は、代表ハッシュ比較部５２Ａの比較結果に基づき、蓄積ＤＢ４０を参照し、該当代表ハッシュ値と同一のシステムＩＤ４２、かつ、同一の代表ハッシュ値がない場合、今回の構成情報に関わる顧客システム２の構成変更ありと判定する。

構成変更報知部５３は、構成変更ありの場合、構成変更ありを表示部２２で報知出力する。サーバ４の管理者は、表示部２２上で当該顧客システムの構成変更を認識できる。

障害判定部５４は、ハッシュ比較部５４Ａを有する。ハッシュ比較部５４Ａは、比較ＤＢ３０を参照し、復号した構成情報内のハッシュ値と同一のハッシュ値があるか否かを判定する。障害判定部５４は、ハッシュ比較部５４Ａを通じて構成情報内のハッシュ値がホワイトリスト３１内にあるか否かを判定し、ハッシュ値がホワイトリスト３１内にある場合、顧客システム２が正常状態のシステム構成と判定する。障害判定部５４は、ハッシュ比較部５４Ａを通じて構成情報内のハッシュ値がブラックリスト３２内にあるか否かを判定し、ハッシュ値がブラックリスト３２内にある場合、顧客システム２が障害事例のシステム構成と判定する。障害判定部５４は、ハッシュ比較部５４Ａを通じて構成情報内のハッシュ値がイエローリスト３３内にあるか否かを判定し、ハッシュ値がイエローリスト３３内にある場合、顧客システム２が原因不明の障害事例のシステム構成と判定する。

障害判定部５４は、ハッシュ比較部５４Ａを通じて構成情報内のハッシュ値がベリファイドリスト３４内にあるか否かを判定し、ハッシュ値がベリファイドリスト３４内にある場合、顧客システム２が検証済みの正常状態のシステム構成と判定する。障害判定部５４は、構成情報内のハッシュ値がホワイトリスト３１、ブラックリスト３２、イエローリスト３３、ベリファイドリスト３４の何れにもない場合、この構成情報を未知のシステム構成と判定する。

障害判定部５４は、構成情報内のハッシュ値が未知のシステム構成と判定すると、構成情報をアンノウンリスト３５内に登録する。

また、障害報知部５５は、障害判定部５４が検証済みの障害事例のシステム構成と判定した場合、表示部２２上にブラック警告を報知出力する。また、障害報知部５５は、障害判定部５４が原因不明の障害事例のシステム構成と判定した場合、表示部２２上にイエロー警告を報知出力する。

図６は、サーバ４内のＣＰＵ２７で実行するリスト更新プロセスの一例を示す説明図である。ＣＰＵ２７は、ＨＤＤ２５に格納されたリスト更新プログラムを読み出し、リスト更新プログラムに基づきリスト更新プロセスを実行してリスト更新部６１、障害情報取得部６２及び条件ポリシ管理部６３を機能として実行する。

障害情報取得部６２は、障害監視装置６からの障害事例情報を取得する。リスト更新部６１は、障害事例情報内の構成情報に該当する構成情報がアンノウンリスト３５内にある場合、構成情報毎に事例数をカウントし、事例数を事例リスト３５Ａに記憶する。リスト更新部６１は、障害事例情報内の構成情報に該当する構成情報がベリファイドリスト３４内にある場合、構成情報毎に事例数をカウントし、事例数を事例リスト３４Ａに記憶する。リスト更新部６１は、障害事例情報内の構成情報に該当する構成情報がイエローリスト３３内にある場合、構成情報毎に事例数をカウントし、事例数を事例リスト３３Ａに記憶する。

リスト更新部６１は、更新部の一例であって、アンノウン判定部６１Ａと、ベリファイド判定部６１Ｂと、イエロー判定部６１Ｃとを有する。アンノウン判定部６１Ａは、アンノウンリスト３５内の事例リスト３５Ａを参照し、アンノウンリスト３５内の構成情報がベリファイドリスト３４に移行する条件を満たしたか否かを判定する。アンノウン判定部６１Ａは、アンノウンリスト３５内の構成情報がベリファイドリスト３４に移行する条件を満たした場合、該当構成情報をアンノウンリスト３５から削除して、ベリファイドリスト３４に登録する。尚、アンノウンリスト３５からベリファイドリスト３４に移行する条件は、アンノウンリスト３５内の構成情報の障害事例の事例数（発生回数）が所定期間内に第２の規定回数未満の場合である。

アンノウン判定部６１Ａは、アンノウンリスト３５内の事例リスト３５Ａを参照し、アンノウンリスト３５内の構成情報がイエローリスト３３に移行する条件を満たしたか否かを判定する。アンノウン判定部６１Ａは、アンノウンリスト３５内の構成情報がイエローリスト３３に移行する条件を満たした場合、該当構成情報をアンノウンリスト３５から削除して、イエローリスト３３に登録する。尚、アンノウンリスト３５からイエローリスト３３に移行する条件は、アンノウンリスト３５内の構成情報の障害事例の事例数（発生回数）が所定期間内に第１の規定回数を超えた場合である。第１の規定回数は、第２の規定回数以上である。第１の規定回数は、例えば、所定期間内に、アンノウンリスト３５に登録した同一構成情報の全件数に対する当該構成情報の障害事例の事例数の割合が２０％相当の回数である。

ベリファイド判定部６１Ｂは、ベリファイドリスト３４内の事例リスト３４Ａを参照し、ベリファイドリスト３４内の構成情報がイエローリスト３３に移行する条件を満たしたか否かを判定する。ベリファイド判定部６１Ｂは、ベリファイドリスト３４内の構成情報がイエローリスト３３に移行する条件を満たした場合、該当構成情報をベリファイドリスト３４から削除して、イエローリスト３３に登録する。尚、ベリファイドリスト３４からイエローリスト３３に移行する条件は、ベリファイドリスト３４内の構成情報の障害事例の事例数（発生回数）が所定期間内に第１の規定回数を超えた場合である。

イエロー判定部６１Ｃは、イエローリスト３３内の事例リスト３３Ａを参照し、イエローリスト３３内の構成情報がベリファイドリスト３４に移行する条件を満たしたか否かを判定する。イエロー判定部６１Ｃは、イエローリスト３３内の構成情報がベリファイドリスト３４に移行する条件を満たした場合、該当構成情報をイエローリスト３３から削除して、ベリファイドリスト３４に登録する。尚、イエローリスト３３からベリファイドリスト３４に移行する条件は、イエローリスト３３内の構成情報の障害事例の事例数（発生回数）が所定期間内に第２の規定回数未満の場合である。

イエロー判定部６１Ｃは、イエローリスト３３内の事例リスト３３Ａを参照し、イエローリスト３３内の構成情報がブラックリスト３２に移行する条件を満たしたか否かを判定する。イエロー判定部６１Ｃは、イエローリスト３３内の構成情報がブラックリスト３２に移行する条件を満たした場合、該当構成情報をイエローリスト３３から削除して、ブラックリスト３２に登録する。尚、イエローリスト３３からブラックリスト３２に移行する条件は、イエローリスト３３内の構成情報の障害事例の事例数（発生回数）が所定期間内に第３の規定回数を超えた場合である。第３の規定回数は、第１の規定回数よりも大である。

条件ポリシ管理部６３は、アンノウンリスト３５、イエローリスト３３及びベリファイドリスト３４間で構成情報が移行する条件を管理するものである。

次に本実施例の監視システム１の動作について説明する。図７は、構成変更チェック処理に関わるサーバ４内のＣＰＵ２７の処理動作の一例を示すフローチャートである。図７に示す構成変更チェック処理は、顧客システム２から収集した構成情報内の代表ハッシュ値に基づき、当該顧客システム２の構成変更の有無をチェックする処理である。図７においてＣＰＵ２７内の構成情報収集部５１は、顧客システム２から構成情報を収集したか否かを判定する（ステップＳ１１）。構成情報収集部５１は、構成情報を収集した場合（ステップＳ１１肯定）、構成情報から代表ハッシュ値を取得する（ステップＳ１２）。

代表ハッシュ比較部５２Ａは、取得した代表ハッシュ値と同一のシステムＩＤ、かつ、同一の代表ハッシュ値が蓄積ＤＢ４０内にあるか否かを判定する（ステップＳ１３）。構成変更判定部５２は、同一のシステムＩＤ、かつ、同一の代表ハッシュ値がある場合（ステップＳ１３肯定）、当該代表ハッシュ値に関わるシステム構成の構成変更なしと判定する（ステップＳ１４）。更に、構成変更判定部５２は、当該システム構成の構成変更なしと判定した場合、当該顧客システム２の構成情報を蓄積ＤＢ４０内に登録し（ステップＳ１５）、図７に示す処理動作を終了する。

また、代表ハッシュ比較部５２Ａは、取得した代表ハッシュ値と同一のシステムＩＤ、かつ、同一の代表ハッシュ値が蓄積ＤＢ４０内にない場合（ステップＳ１３否定）、当該システム構成の構成変更ありと判定する（ステップＳ１６）。そして、構成変更報知部５３は、システム構成の構成変更ありと判定した場合、構成変更ありを表示部２２に報知出力し（ステップＳ１７）、当該システム構成の構成情報を蓄積ＤＢ４０に登録すべく、ステップＳ１５に移行する。その結果、サーバ４の管理者は、例えば、表示部２２の報知内容を見て構成変更ありを認識できる。

また、構成情報取得部５１は、構成情報を取得しなかった場合（ステップＳ１１否定）、図７に示す処理動作を終了する。

図７に示す構成変更チェック処理のＣＰＵ２７は、顧客システム２から構成情報内の代表ハッシュ値を取得すると、この代表ハッシュ値と同一のシステムＩＤ、かつ、同一の代表ハッシュ値が蓄積ＤＢ４０内にあるか否かを判定する。ＣＰＵ２７は、同一システムＩＤ、かつ、同一の代表ハッシュ値が蓄積ＤＢ４０内にある場合、顧客システム２のシステム構成に構成変更なしと判定する。

また、ＣＰＵ２７は、取得した代表ハッシュ値と同一のシステムＩＤ、かつ、同一の代表ハッシュ値が蓄積ＤＢ４０内にない場合、顧客システム２のシステム構成の構成変更ありと判定し、構成変更ありを報知出力する。その結果、サーバ４の管理者は、報知内容に基づき、顧客システム２のシステム構成の構成変更ありを認識できる。

図８は、障害判定処理に関わるサーバ４内のＣＰＵ２７の処理動作の一例を示すフローチャートである。図８に示す報知処理は、障害判定部５４の判定結果に応じて障害有無を報知する処理である。図８において構成情報収集部５１は、顧客システム２から構成情報を収集したか否かを判定する（ステップＳ２１）。構成情報収集部５１は、構成情報を収集した場合（ステップＳ２１肯定）、構成情報内のソフト構成及びハード構成のハッシュ値を取得する（ステップＳ２２）。障害判定部５４は、取得したハッシュ値がホワイトリスト３１内にあるか否かを判定する（ステップＳ２３）。

障害判定部５４は、ハッシュ値がホワイトリスト３１内にある場合（ステップＳ２３肯定）、システム構成が正常状態であるため、図８に示す処理動作を終了する。また、障害判定部５４は、ハッシュ値がホワイトリスト３１内にない場合（ステップＳ２３否定）、ハッシュ値がベリファイドリスト３４内にあるか否かを判定する（ステップＳ２４）。障害判定部５４は、ハッシュ値がベリファイドリスト３４内にある場合（ステップＳ２４肯定）、システム構成が検証済みの正常状態であるため、図８に示す処理動作を終了する。

障害判定部５４は、取得したハッシュ値がイエローリスト３３内にあるか否かを判定する（ステップＳ２５）。障害判定部５４は、ハッシュ値がイエローリスト３３内にある場合（ステップＳ２５肯定）、システム構成が原因不明の障害事例であるため、障害報知部５５を通じてイエロー警告を報知出力し（ステップＳ２６）、図８に示す処理動作を終了する。尚、サーバ４の管理者は、イエロー警告に応じて顧客システム２のシステム構成が原因不明の障害事例と認識できる。

また、障害判定部５４は、ハッシュ値がイエローリスト３３内にない場合（ステップＳ２５否定）、ハッシュ値がブラックリスト３２内にあるか否かを判定する（ステップＳ２７）。障害判定部５４は、ハッシュ値がブラックリスト３２内にある場合（ステップＳ２７肯定）、システム構成が検証済みの障害事例であるため、障害報知部５５を通じてブラック警告を報知出力し（ステップＳ２８）、図８に示す処理動作を終了する。尚、サーバ４の管理者は、ブラック警告に応じて顧客システム２のシステム構成が検証済みの障害事例と認識できる。

また、障害判定部５４は、ハッシュ値がブラックリスト３２内にない場合（ステップＳ２７否定）、ステップＳ２１で取得した構成情報をアンノウンリスト３５に登録し（ステップＳ２９）、図８に示す処理動作を終了する。

図８に示す報知処理のＣＰＵ２７は、顧客システム２から収集した構成情報内のハッシュ値がホワイトリスト３１内にある場合、顧客システム２のシステム構成が正常状態と判定する。

ＣＰＵ２７は、顧客システム２から収集した構成情報内のハッシュ値がベリファイドリスト３４内にある場合、顧客システム２のシステム構成が検証済みの正常状態と判定する。

ＣＰＵ２７は、顧客システム２から収集した構成情報内のハッシュ値がイエローリスト３３内にある場合、顧客システム２のシステム構成が原因不明の障害事例と判定し、イエロー警告を報知出力する。その結果、サーバ４の管理者は、イエロー警告に基づき、顧客システムのシステム構成が原因不明の障害事例と認識できる。

ＣＰＵ２７は、顧客システム２から収集した構成情報内のハッシュ値がブラックリスト３２内にある場合、顧客システム２のシステム構成が検証済みの障害事例と判定し、ブラック警告を報知出力する。その結果、サーバ４の管理者は、ブラック警告に基づき、顧客システムのシステム構成が障害事例と認識できる。

図９は、アンノウンリスト判定処理に関わるサーバ４内のＣＰＵ２７の処理動作の一例を示すフローチャートである。図９に示すアンノウンリスト判定処理は、移行条件に応じて、アンノウンリスト３５内に登録された構成情報を削除してイエローリスト３３又はベリファイドリスト３４に登録する処理である。

図９においてＣＰＵ２７内のアンノウン判定部６１Ａは、アンノウンリスト３５内の構成情報の事例回数が所定期間内に第１の規定回数を超えたか否かを判定する（ステップＳ３１）。アンノウン判定部６１Ａは、構成情報の事例回数が所定期間内に第１の規定回数を超えた場合（ステップＳ３１肯定）、該当構成情報をアンノウンリスト３５から削除してイエローリスト３３内に登録し（ステップＳ３２）、図９に示す処理動作を終了する。

アンノウン判定部６１Ａは、構成情報の事例回数が所定期間内に第１の規定回数を超えなかった場合（ステップＳ３１否定）、アンノウンリスト３５内の構成情報の事例回数が所定期間内に第２の規定回数未満であるか否かを判定する（ステップＳ３３）。アンノウン判定部６１Ａは、構成情報の事例回数が所定期間内に第２の規定回数未満の場合（ステップＳ３３肯定）、該当構成情報をアンノウンリスト３５から削除してベリファイドリスト３４内に登録し（ステップＳ３４）、図９に示す処理動作を終了する。

アンノウン判定部６１Ａは、構成情報の事例回数が所定期間内に第２の規定回数未満でない場合（ステップＳ３３否定）、図９に示す処理動作を終了する。

図９に示すアンノウンリスト判定処理のＣＰＵ２７は、アンノウンリスト３５内の構成情報の事例回数が所定期間内に第１の規定回数を超えた場合、該当構成情報をアンノウンリスト３５から削除してイエローリスト３３内に登録する。その結果、アンノウンリスト３５とイエローリスト３３との間で構成情報を動的に移行できる。

ＣＰＵ２７は、アンノウンリスト３５内の構成情報の事例回数が所定期間内に第２の規定回数未満の場合、該当構成情報をアンノウンリスト３５から削除してベリファイドリスト３４内に登録する。その結果、アンノウンリスト３５とベリファイドリスト３４との間で構成情報を動的に移行できる。

図１０は、イエローリスト判定処理に関わるサーバ４内のＣＰＵ２７の処理動作の一例を示すフローチャートである。図１０に示すイエローリスト判定処理は、移行条件に応じて、イエローリスト３３内に登録された構成情報を削除してベリファイドリスト３４又はブラックリスト３２に登録する処理である。

図１０においてＣＰＵ２７内のイエロー判定部６１Ｃは、イエローリスト３３内の構成情報の事例回数が所定期間内に第３の規定回数を超えたか否かを判定する（ステップＳ４１）。イエロー判定部６１Ｃは、構成情報の事例回数が所定期間内に第３の規定回数を超えた場合（ステップＳ４１肯定）、該当構成情報をイエローリスト３３から削除してブラックリスト３２内に登録し（ステップＳ４２）、図１０に示す処理動作を終了する。

また、イエロー判定部６１Ｃは、構成情報の事例回数が所定期間内に第３の規定回数を超えなかった場合（ステップＳ４１否定）、イエローリスト３３内の構成情報の事例回数が所定期間内に第２の規定回数未満であるか否かを判定する（ステップＳ４３）。イエロー判定部６１Ｃは、構成情報の事例回数が所定期間内に第２の規定回数未満の場合（ステップＳ４３肯定）、該当構成情報をイエローリスト３３から削除してベリファイドリスト３４内に登録し（ステップＳ４４）、図１０に示す処理動作を終了する。

イエロー判定部６１Ｃは、構成情報の事例回数が所定期間内に第２の規定回数未満でない場合（ステップＳ４３否定）、図１０に示す処理動作を終了する。

図１０に示すイエローリスト判定処理のＣＰＵ２７は、イエローリスト３３内の構成情報の事例回数が所定期間内に第２の規定回数未満の場合、該当構成情報をイエローリスト３３から削除してベリファイドリスト３４内に登録する。その結果、ベリファイドリスト３４とイエローリスト３３との間で構成情報を動的に移行できる。

ＣＰＵ２７は、イエローリスト３３内の構成情報の事例回数が所定期間内に第３の規定回数を超えた場合、該当構成情報をイエローリスト３３から削除してブラックリスト３２内に登録する。その結果、ブラックリスト３２とイエローリスト３３との間で構成情報を動的に移行できる。

図１１は、ベリファイドリスト判定処理に関わるサーバ４内のＣＰＵ２７の処理動作の一例を示すフローチャートである。図１１に示すベリファイドリスト判定処理は、所定条件に応じて、ベリファイドリスト３４内に登録された構成情報を削除してイエローリスト３３内に登録する処理である。

図１１においてＣＰＵ２７内のベリファイド判定部６１Ｂは、ベリファイドリスト３４内の構成情報の事例回数が所定期間内に第１の規定回数を超えたか否かを判定する（ステップＳ５１）。ベリファイド判定部６１Ｂは、構成情報の事例回数が所定期間内に第１の規定回数を超えた場合（ステップＳ５１肯定）、該当構成情報をベリファイドリスト３４から削除してイエローリスト３３内に登録し（ステップＳ５２）、図１１に示す処理動作を終了する。

ベリファイド判定部６１Ｂは、構成情報の事例回数が所定期間内に第１の規定回数を超えなかった場合（ステップＳ５１否定）、図１１に示す処理動作を終了する。

図１１に示すベリファイドリスト判定処理のＣＰＵ２７は、ベリファイドリスト３４内の構成情報の事例回数が所定期間内に第１の規定回数を超えた場合、該当構成情報をベリファイドリスト３４から削除してイエローリスト３３内に登録する。その結果、ベリファイドリスト３４とイエローリスト３３との間で構成情報を動的に移行できる。

実施例では、顧客システム２側のシステム構成、例えば、ソフト構成及びハード構成毎のハッシュ値を含む構成情報を定期的に収集し、顧客システム２毎の構成情報を蓄積ＤＢ４０に蓄積した。その結果、サーバ４は、蓄積ＤＢ４０を参照して、顧客システム２毎のシステム構成を時系列に把握できる。

実施例では、顧客システム２側のシステム構成として、ソフト構成及びハード構成のハッシュ値を含む構成情報をサーバ４に伝送したので、システム構成のデータ量は必要最小限の固定長のデータ量で済むため、その通信経路の使用帯域を小さくできる。

実施例では、顧客システム２側の構成変更の有無を構成情報内の代表ハッシュ値で蓄積ＤＢ４０を参照してチェックする。その結果、顧客システム２の構成変更の有無を高速にチェックできる。

実施例では、顧客システム２のシステム構成に対応したハッシュ値と各リスト内に登録済みのハッシュ値とを比較して障害内容を検知する。その結果、障害発生の事前予測や、障害発生後の早期解決を実現できる。

実施例のサーバ４は、顧客システム２から収集した構成情報内のハッシュ値がイエローリスト３３内にある場合、顧客システム２が原因不明の障害事例に関わるシステム構成と判定する。その結果、サーバ４は、顧客システム２が原因不明の障害に関わるシステム構成と識別する。

実施例のサーバ４は、顧客システム２から収集した構成情報内のハッシュ値がベリファイドリスト３４内にある場合、顧客システム２が検証済みの正常状態のシステム構成と判定する。その結果、サーバ４は、顧客システム２が検証済みの正常状態のシステム構成と識別する。

実施例のサーバ４は、蓄積ＤＢ４０に記憶された顧客システム２の前回の構成情報と、収集した今回の構成情報とを代表ハッシュ値で比較して構成変更の有無を確認できる。しかも、サーバ４は、今回の構成変更で障害が発生したことが確認できた場合、前回の構成情報に戻すことで、障害の早期復旧を図ることができる。

実施例では、顧客システム２側のＴＰＭチップ１４及びサーバ４側のＴＰＭチップ２４が使用するハッシュ値の採取ルール及び暗号化ルールは、国際公開標準仕様に準拠しているため、その証拠性も高く、第三者が自律的に検証できる。

実施例のＣＰＵ２７は、ビッグＤＢ３６に記憶された構成情報３６Ａ及び時間情報３６Ｃと、事例リスト内の構成情報３６Ａ毎の障害事例の事例回数とに基づき、アンノウンリスト３５、イエローリスト３３及びベリファイドリスト３４の間で構成情報を移行する。その結果、ＣＰＵ２７は、アンノウンリスト３５、イエローリスト３３及びベリファイドリスト３４の間で構成情報を移動して動的にリスト更新できる。

ＣＰＵ２７は、アンノウンリスト３５に記憶された構成情報に関わる障害事例の事例回数が所定期間内に第１の規定回数を超えた場合、当該構成情報を当該アンノウンリスト３５から削除してイエローリスト３３に格納する。その結果、アンノウンリスト３５に登録された構成情報をイエローリスト３３に移動して動的にリスト更新できる。

ＣＰＵ２７は、アンノウンリスト３５に記憶された構成情報に関わる障害事例の事例回数が所定期間内に第２の規定回数未満である場合、当該構成情報を当該アンノウンリスト３５から削除してベリファイドリスト３４に格納する。その結果、アンノウンリスト３５に登録された構成情報をベリファイドリスト３４に移動して動的にリスト更新できる。

ＣＰＵ２７は、ベリファイドリスト３４に記憶された構成情報に関わる障害事例の事例回数が所定期間内に第１の規定回数を超えた場合、当該構成情報を当該ベリファイドリスト３４から削除してイエローリスト３３に格納する。その結果、ベリファイドリスト３４に登録された構成情報をイエローリスト３３に移動して動的にリスト更新できる。

ＣＰＵ２７は、イエローリスト３３に記憶された構成情報に関わる障害事例の事例回数が所定期間内に第２の規定回数未満である場合、当該構成情報を当該イエローリスト３３から削除してベリファイドリスト３４に格納する。その結果、イエローリスト３３に登録された構成情報をベリファイドリスト３４に移動して動的にリスト更新できる。

実施例のＣＰＵ２７は、顧客システム２から受信した構成情報と、イエローリスト３３に記憶された構成情報とを比較し、当該構成情報を送信した電子機器で原因不明の障害が発生するおそれがあるか否かを判定する。

実施例のＣＰＵ２７は、受信した構成情報が、蓄積ＤＢ４０に記憶された前回の構成情報と異なる場合に、当該構成情報と、比較ＤＢ３０内に登録された構成情報とを比較する。

また、サーバ４は、パッチに対応したハッシュ値をホワイトリスト３１に登録しておき、顧客システム２から収集した構成情報内にホワイトリスト３１に登録したパッチのハッシュ値があるか否かを判定しても良い。この場合、サーバ４は、顧客システム２毎のパッチ適用の有無を確認できる。

サーバ４は、例えば、顧客システム２に対するパッチ適用前の構成情報と、パッチ適用後の構成情報を収集し、パッチ適用前の構成情報とパッチ適用後の構成情報とを比較してパッチ適用の有無を確認できる。しかも、サーバ４は、パッチ適用前の構成情報を把握している為、ロールバックで元のシステム構成にも戻すことができる。

サーバ４は、例えば、保守作業完了後のシステム構成のホワイトリスト３１を登録しておき、顧客システム２から収集した構成情報内のハッシュ値がホワイトリスト３１内にあるか否かを判定する。その結果、サーバ４は、顧客システム２毎に保守作業の完了有無を確認できる。

尚、上記実施例では、顧客システム２のシステム構成としてハード構成及びソフト構成等を含めたが、ハード部品交換時のソフト版数の変更作業では、２つの組合せが正しく維持されることを証明するために組合せのハッシュ値を採取しても良い。

上記実施例の障害判定部５４では、各リスト３１〜３５内に登録する構成情報がハッシュ値であるため、ハッシュ値でシステム構成の状態を判定したが、各リスト３１〜３５内に代表ハッシュ値が登録されている場合、代表ハッシュ値で状態を判定しても良い。

上記実施例では、顧客システム２の電子機器の一例としてコンピュータ装置を例示した。電子機器は、例えば、サーバ、プリンタ、ネットワーク機器、外部ストレージ、携帯電話、スマートフォン、冷蔵庫、洗濯機、テレビ、ステレオコンポ、医療機器や工作機器等であっても良い。

上記実施例のイエローリスト３３には、障害事例のシステム構成に対応した構成情報を登録するようにしたが、この際、その障害事例の障害状況に対応した危険度毎に構成情報をイエローリスト３３内に登録しても良い。尚、障害状況に対応した危険度とは、例えば、障害事例による障害が及ぼす影響範囲や被害額の大小に応じた複数段のランクである。この際、障害判定部５４は、受信した構成情報がイエローリスト３３内の危険度毎にハッシュ値があるか否かを夫々判定し、当該ハッシュ値が該当する危険度に対応したイエロー警告を報知出力する。その結果、サーバ４の管理者は、危険度に対応した障害事例を認識できる。

また、図示した各部の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

更に、各装置で行われる各種処理機能は、ＣＰＵ（Central Processing Unit）（又はＭＰＵ（Micro Processing Unit）、ＭＣＵ（Micro Controller Unit）等のマイクロ・コンピュータ）上で、その全部又は任意の一部を実行するようにしても良い。また、各種処理機能は、ＣＰＵ（又はＭＰＵ、ＭＣＵ等のマイクロ・コンピュータ）で解析実行するプログラム上、又はワイヤードロジックによるハードウェア上で、その全部又は任意の一部を実行するようにしても良いことは言うまでもない。

ところで、本実施例で説明した各種の処理は、予め用意されたプログラムを情報処理装置で実行することで実現できる。そこで、以下では、上記実施例と同様の機能を有するプログラムを実行する情報処理装置の一例を説明する。図１２は、管理プログラムを実行する情報処理装置を示す説明図である。

図１２に示す管理プログラムを実行する情報処理装置１００では、ＲＯＭ１１０、ＲＡＭ１２０、ＨＤＤ１３０と、プロセッサ１４０、操作部１５０、表示部１６０及び通信部１７０を有する。

そして、ＲＯＭ１１０には、上記実施例と同様の機能を発揮する管理プログラムが予め記憶されている。尚、ＲＯＭ１１０ではなく、図示せぬドライブで読取可能な記録媒体に管理プログラムが記録されていても良い。また、記録媒体としては、例えば、ＣＤ−ＲＯＭ、ＤＶＤディスク、ＵＳＢメモリ、ＳＤカード等の可搬型記録媒体、フラッシュメモリ等の半導体メモリ等でも良い。管理プログラムとしては、図１２に示すように、受信プログラム１１０Ａ及び更新プログラム１１０Ｂである。尚、プログラム１１０Ａ及び１１０Ｂについては、適宜統合又は分散しても良い。

そして、プロセッサ１４０は、これらのプログラム１１０Ａ及び１１０ＢをＲＯＭ１１０から読み出し、これら読み出された各プログラムを実行する。そして、プロセッサ１４０は、図１２に示すように、各プログラム１１０Ａ及び１１０Ｂを、受信プロセス１４０Ａ及び更新プロセス１４０Ｂとして機能する。

ＨＤＤ１３０は、第１のリスト１３０Ａと、第２のリスト１３０Ｂと、第３のリスト１３０Ｃとが格納してある。第１のリスト１３０Ａは、電子機器の構成情報の内、第１の状態を示す構成情報を記憶する。第２のリスト１３０Ｂは、第１の状態ではない第２の状態を示す構成情報を記憶する。第３のリスト１３０Ｃは、前記第１の状態または第２の状態のいずれであるか不明である第３の状態を示す構成情報を記憶する。

プロセッサ１４０は、電子機器の構成情報を定期的に受信する。更に、プロセッサ１４０は、受信した構成情報を時間情報と対応付けて記憶部に記憶する。更に、プロセッサ１４０は、構成情報毎に、第１の状態を示す事例の発生回数を事例リストに記憶する。プロセッサ１４０は、ＨＤＤ１３０内の構成情報及び時間情報と、事例リスト内の構成情報の発生回数とに基づき、第１のリストと第２のリストとの間、第２のリストと第３のリストとの間や、第３のリストと第１のリストとの間で、構成情報を移動してリストを更新する。その結果、事例回数の変化や時間の経過に応じてリストの内容を動的に変更できる。

２ 顧客システム
４ サーバ
５ ＤＢ装置
１４ ＴＰＭチップ
２４ ＴＰＭチップ
２７ ＣＰＵ
３３ イエローリスト
３４ ベリファイドリスト
３５ アンノウンリスト
３６ ビッグＤＢ
４０ 蓄積ＤＢ
５２ 構成変更判定部
５２Ａ 代表ハッシュ比較部
５３ 構成変更報知部
５４ 障害判定部
５４Ａ ハッシュ比較部
５５ 障害報知部
６１ リスト更新部
６１Ａ アンノウン判定部
６１Ｂ ベリファイド判定部
６１Ｃ イエロー判定部

Claims (12)

1. 電子機器の構成情報を定期的に受信する受信部と、
   前記構成情報を時間情報と対応付けて記憶する記憶部と、
   第１の状態を示す構成情報を記憶する第１のリストと、
   前記第１の状態ではない第２の状態を示す構成情報を記憶する第２のリストと、
   前記第１の状態または第２の状態のいずれであるか不明である第３の状態を示す構成情報を記憶する第３のリストと、
   前記構成情報毎に、前記第１の状態を示す障害事例の発生回数を記憶する事例リストと、
   前記記憶部に記憶された構成情報および時間情報と、前記事例リストに記憶された構成情報および発生回数とに基づき、前記第１のリストと前記第２のリストとの間、前記第２のリストと前記第３のリストとの間、または、前記第３のリストと前記第１のリストとの間で、前記構成情報を移動してリストを更新する更新部と
   を有することを特徴とする管理装置。
2. 前記更新部は、
   前記第３のリストに記憶された前記構成情報に関わる前記発生回数が所定期間内に第１の規定回数を超えた場合、当該構成情報を当該第３のリストから削除して前記第１のリストに格納することを特徴とする請求項１に記載の管理装置。
3. 前記更新部は、
   前記第３のリストに記憶された前記構成情報に関わる前記発生回数が所定期間内に第２の規定回数未満である場合、当該構成情報を当該第３のリストから削除して前記第２のリストに格納することを特徴とする請求項１または２に記載の管理装置。
4. 前記更新部は、
   前記第２のリストに記憶された前記構成情報に関わる前記発生回数が所定期間内に第１の規定回数を超えた場合、当該構成情報を当該第２のリストから削除して前記第１のリストに格納することを特徴とする請求項１〜３のいずれか一つに記載の管理装置。
5. 前記更新部は、
   前記第１のリストに記憶された前記構成情報に関わる前記発生回数が所定期間内に第２の規定回数未満である場合、当該構成情報を当該第１のリストから削除して前記第２のリストに格納することを特徴とする請求項１〜４のいずれか一つに記載の管理装置。
6. 前記更新部は、
   前記受信部で受信した前記構成情報に関わる障害事例の危険度毎に、当該構成情報を前記第１のリストに格納することを特徴とする請求項１〜５のいずれか一つに記載の管理装置。
7. 前記受信部によって受信した構成情報と、前記第１のリストに記憶された構成情報とを比較し、当該構成情報を送信した電子機器で前記第１の状態を示す障害状態が発生するおそれがあるか否かを判定する判定部をさらに備えたことを特徴とする請求項１〜６のいずれか一つに記載の管理装置。
8. 前記判定部は、
   前記受信部によって受信した構成情報が、前記記憶部に記憶された前回の構成情報と異なる場合に、当該構成情報と前記第１のリストに記憶された構成情報とを比較することを特徴とする請求項７に記載の管理装置。
9. 前記記憶部は、
   前記構成情報に対応付けて当該構成情報の代表値をさらに記憶し、
   前記判定部は、
   前記受信部によって受信した構成情報の代表値が、前記記憶部に記憶された前回の代表値と異なる場合に、当該構成情報と前記第１のリストに記憶された構成情報とを比較することを特徴とする請求項８に記載の管理装置。
10. 前記受信部は、
    各電子機器に搭載された耐タンパー性を持つチップによって収集され、第三者装置によって承認された当該電子機器の構成情報を受信することを特徴とする請求項１〜９のいずれか一つに記載の管理装置。
11. 情報処理装置は、
    電子機器の構成情報を定期的に受信し、
    受信した前記構成情報を時間情報と対応付けて記憶部に記憶し、
    前記構成情報毎に、第１の状態を示す障害事例の発生回数を事例リストに記憶し、
    前記記憶部に記憶された構成情報および時間情報と、前記事例リストに記憶された構成情報および発生回数とに基づき、前記第１の状態を示す構成情報を記憶する第１のリストと前記第１の状態ではない第２の状態を示す構成情報を記憶する第２のリストとの間、前記第２のリストと前記第１の状態または第２の状態のいずれであるか不明である第３の状態を示す構成情報を記憶する第３のリストとの間、または、前記第３のリストと前記第１のリストとの間で、前記構成情報を移動してリストを更新する
    各処理を実行することを特徴とする管理方法。
12. 情報処理装置のプロセッサに、
    電子機器の構成情報を定期的に受信し、
    受信した前記構成情報を時間情報と対応付けて記憶部に記憶し、
    前記構成情報毎に、第１の状態を示す障害事例の発生回数を事例リストに記憶し、
    前記記憶部に記憶された構成情報および時間情報と、前記事例リストに記憶された構成情報および発生回数とに基づき、前記第１の状態を示す構成情報を記憶する第１のリストと前記第１の状態ではない第２の状態を示す構成情報を記憶する第２のリストとの間、前記第２のリストと前記第１の状態または第２の状態のいずれであるか不明である第３の状態を示す構成情報を記憶する第３のリストとの間、または、前記第３のリストと前記第１のリストとの間で、前記構成情報を移動してリストを更新する
    各処理を実行させることを特徴とする管理プログラム。

Images