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

Abstract

【課題】システム異常の危険性を早期に検出することを課題とする。
【解決手段】監視センタは、電子機器より受信した構成情報を記憶する記憶部と、電子機器が第１の状態であることを示す構成情報を記憶する第１のリストとを有する。監視センタは、電子機器の構成情報を受信した場合に、記憶部に基づいて当該構成情報が先に受信した構成情報と異なるか判定し、異なる場合には、第１のリストに記憶された構成情報と同一であるかを判定する。監視センタは、第１のリストに記憶された構成情報と同一であると判定された場合に、当該構成情報に対応する電子機器を、記憶部から検出する。
【選択図】図４

Description

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

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

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

特開２００９−２３０４５７号公報

"Systemwalker IT Change Manager V14g 製品カタログ"、［online］、2013年3月19日検索、インターネット＜URL：http://systemwalker.fujitsu.com/jp/catalog/pdf/changemanager/changemanager-p.pdf＞

しかしながら、上記技術では、ブラックリストに構成情報が新たに登録された場合に、当該構成情報を有するシステムの検出にタイムラグや見落としが発生し、システム異常の危険性を早期に検出できないという問題がある。

例えば、保守センタは、ホワイトリストに登録されていた構成情報にセキュリティホールなどが発見された場合、当該構成情報をホワイトリストからブラックリストに移動させる。その後、保守センタは、当該構成情報を有するシステムから構成情報を新たに受信するまで、当該システムに対する障害の危険性を検出できない。

また、保守センタは、処理負荷の軽減等から、システムから受信した構成情報が前回受信した構成情報から変更されている場合に、各リストとの比較を行うことも考えられる。この場合、保守センタは、ブラックリストに新たに登録された構成情報を有するシステムにおいて構成情報の変更が行われるまで、当該システムから受信した構成情報に対してリストとの比較を行わない。したがって、保守センタは、当該システムの構成情報が変更されるまで、当該システムに対する障害の危険性を検出できない。

１つの側面では、システム異常の危険性を早期に検出することができる管理装置、管理方法及び管理プログラムを提供することを目的とする。

第１の案では、管理装置は、電子機器より受信した構成情報を記憶する記憶部と、前記電子機器が第１の状態であることを示す構成情報を記憶する第１のリストとを有する。管理装置は、前記電子機器の構成情報を受信した場合に、前記記憶部に基づいて当該構成情報が先に受信した構成情報と異なるか判定し、異なる場合には、前記第１のリストに記憶された構成情報と同一であるかを判定する判定部を有する。管理装置は、前記判定部によって前記第１のリストに記憶された構成情報と同一であると判定された場合に、当該構成情報に対応する電子機器を、前記記憶部から検出する検出部を有する。

本願の１実施形態では、システム異常の危険性を早期に検出することができる。

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

以下に、本願の開示する管理装置、管理方法及び管理プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

［全体構成］
図１は、実施例の監視システムの一例を示す説明図である。図１に示す監視システム１は、複数の顧客システム２と、監視センタ３と、製造者側装置１００と、保守端末４００とを有する。監視センタ３は、例えば、遠隔地にある複数の顧客システム２の状態をリモート監視する。監視センタ３は、図４に記載するように、サーバ４と、データベース（以下、単にＤＢと称する場合がある）装置５と、障害監視装置６とを有する。各顧客システム２は、監視センタ３が監視対象とする顧客のシステムである。

また、監視センタ３と各顧客システム２とは、インターネットなどの社外ネットワーク２００を介して接続される。同様に、監視センタ３と製造者側装置１００とは、インターネットなどの社外ネットワーク２００を介して接続される。なお、製造者側装置１００は、顧客システムを構成する電子機器の製造元であり、各電子機器のセキュリティホール等が発見された場合に、該当する構成情報等を監視センタ３に通知する。

また、監視センタ３と各保守端末４００とは、イントラネットなどの社内ネットワーク３００を介して接続される。なお、保守端末４００は、各顧客システム２等を保守する保守者が使用する端末や監視センタ３で顧客システム２を監視する監視者が使用する端末である。

［顧客システムの構成］
図２は、顧客システムの構成を示すブロック図である。例えば、顧客システム２は、コンピュータ装置等の電子機器で構成される。図２に示すように、顧客システム２は、通信インタフェース（以下、単にＩＦと称する場合がある）１１と、表示部１２と、操作部１３と、ＴＰＭ（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）、ＯＳｌｏａｄｅｒ、ＯＳカーネルへのブートプロセスでのソフトウェアコードを取得する。ＴＰＭチップ１４は、取得されたソフトウェアコードをハッシュ化してソフト構成のハッシュ値を得る。そして、ＴＰＭチップ１４は、そのソフト構成のハッシュ値をＴＰＭチップ１４内部のレジスタに登録する。また、ＴＰＭチップ１４は、電子機器のハードウェア構成の情報を取得し、ハードウェア構成の情報をハッシュ化してハード構成のハッシュ値を得る。そして、ＴＰＭチップ１４は、そのハード構成のハッシュ値をＴＰＭチップ１４内部のレジスタに登録する。つまり、ＴＰＭチップ１４では、電子機器のソフト構成のハッシュ値及びハード構成のハッシュ値をレジスタ内に登録する。

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

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

［監視センタの構成］
図４は、監視センタが有する各装置の構成を示すブロック図である。図４に示すように、監視センタ３は、サーバ４と、ＤＢ装置５と、障害監視装置６とを有する。

（サーバの構成）
サーバ４は、例えば、コンピュータ装置などである。図４に示すように、サーバ４は、通信ＩＦ２１と、表示部２２と、操作部２３と、ＴＰＭチップ２４と、ＨＤＤ２５と、ＲＡＭ２６と、ＣＰＵ２７と、バス２８とを有する。

通信ＩＦ２１は、顧客システム２との間の通信を司るＩＦである。表示部２２は、各種情報を表示する出力ＩＦである。操作部２３は、各種情報を入力する入力ＩＦである。ＨＤＤ２５は、各種情報を記憶する不揮発性の記憶領域である。ＲＡＭ２６は、各種情報を記憶する揮発性の記憶領域である。ＣＰＵ２７は、サーバ４全体を制御する。バス２８は、通信ＩＦ２１、表示部２２、操作部２３、ＴＰＭチップ２４、ＨＤＤ２５、ＲＡＭ２６、ＣＰＵ２７の間でデータを伝送する伝送経路である。

サーバ４側のＴＰＭチップ２４は、顧客システム２側のＴＰＭチップ１４がハッシュ値を採取する際のルールをハッシュ化及び署名付与して管理することで、ハッシュ値採取の正当性を担保するものである。しかも、ＴＰＭチップ２４は、必要に応じて、現時点でのルール及び署名をチェックすることで、ルールの非改竄性を証明する。その結果、ＴＰＭチップ１４は、ＴＰＭチップ２４側で非改竄性が証明されたルールを参照しながら運用することでハッシュ値を採取する際のルールに改竄がないことを保証する。顧客システム２に派遣された監視センタ３内の作業者が勝手に改竄していないことも保証できる。

また、ＴＰＭチップ２４は、顧客システム２から送信された、暗号化された構成情報などが受信した場合に、当該構成情報等を復号する。そして、ＴＰＭチップ２４は、復号して得られた構成情報等をＣＰＵ２７に出力する。

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

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

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

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

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

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

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

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

（障害監視装置の構成）
障害監視装置６は、障害の事例情報をサーバ４に報知するサーバ装置である。尚、障害の事例情報には、障害内容と、例えば、障害のシステム構成に対応したソフト構成及び／又はハード構成のハッシュ値とを含む。この障害監視装置６は、一般的なサーバ装置と同様の構成を有するので、ここでは詳細な説明は省略する。もっとも、障害監視装置６の構成が一般的なサーバ装置の構成に限定されるものではなく、顧客システム２やサーバ４と同様、ＴＰＭチップを用いて障害の事例情報をサーバ４に報知することもできる。

［サーバの処理］
次に、サーバ４のＣＰＵ２７が実行する各プロセスについて説明する。ここでは、障害判定プロセス、リスト更新プロセス、リスト判定プロセスについて説明する。

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

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

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

構成変更報知部５３は、構成変更ありの場合、構成変更ありを表示部２２で報知出力する。サーバ４の管理者は、表示部２２上で当該顧客システムの構成変更を認識できる。また、構成変更報知部５３は、構成変更が発生したことと、構成変更が発生した顧客システム２と特定する情報とを、他のプロセス等に通知する。

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

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

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

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

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

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

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

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

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

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

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

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

また、リスト更新部６１は、製造者側装置１００からセキュリティホールなど危険情報が発見された構成情報の通知を受信した場合に、該当する構成情報がホワイトリスト３１に登録されているか否かを判定する。そして、リスト更新部６１は、該当する構成情報がホワイトリスト３１に登録されている場合には、当該構成情報をブラックリスト３１またはイエローリスト３３に移動させる。そして、リスト更新部６１は、例えば、移動させた構成情報と、当該構成情報を有するシステムのシステムＩＤとを後述するリスト判定部７１等に通知する。

一例として、リスト更新部６１は、発見された危険情報の危険性が高い場合には、ブラックリスト３２に移動させ、危険性が低い場合には、イエローリスト３３に移動させる。なお、危険性が高いとは、例えば早期のアップデートが推奨されている場合や発見されたセキュリティホールを利用するウィルス等による被害が既に報告されている場合などが該当する。また、危険性が低いとは、例えば発見されてからの日数が短い場合や発見されたセキュリティホールを利用するウィルスの除去方法が公開されている場合などが該当する。

（リスト判定プロセス）
図９は、サーバ内のＣＰＵで実行するリスト判定プロセスの一例を示す説明図である。ＣＰＵ２７は、ＨＤＤ２５に格納されたリスト判定プログラムを読み出し、リスト判定プログラムに基づきリスト判定プロセスを実行してリスト判定部７１を機能として実行する。

リスト判定部７１は、判定部の一例であって、移動検知部７１ａと危険通知部７１ｂとを有する。移動検知部７１ａは、ホワイトリスト３１からブラックリスト３２またはイエローリスト３３への構成情報の移動を検知する。

例えば、移動検知部７１ａは、リスト更新部６１から移動が発生したことと、移動した構成情報とを取得した場合に、移動が発生したと検知し、ブラックリスト３２またはイエローリスト３３を参照して、移動した構成情報を特定する。また、移動検知部７１ａは、ホワイトリスト３１、ブラックリスト３２、イエローリスト３３各々を監視して、移動を検知することもできる。

より詳細な例としては、移動検知部７１ａは、各リストへのファイルアクセスコマンドを監視することで、リストの更新を検知する。このとき、ＴＰＭチップ２４は、ウォッチャーとして機能する移動検知部７１ａの動作を保証する。このようにすることで、移動検知部７１ａは、不正なアクセスコマンドを検知対象から除外し、正常なアクセスコマンドを検知することができる。

危険通知部７１ｂは、リスト判定部７１によって検出された構成情報を有する電子機器に対して、蓄積ＤＢ４０に記憶される当該電子機器の構成情報を順次参照して、ホワイトリスト３１に該当する構成情報を検出し、検出した構成情報を保守端末４００に通知する。例えば、危険通知部７１ｂは、ブラックリスト３２またはイエローリスト３３へ移動されたハッシュ値を有する顧客システム２のシステムＩＤをキーにして、蓄積ＤＢ４０に記憶されるハッシュ値を新しい方から順に参照する。

そして、危険通知部７１ｂは、当該システムＩＤに対応するハッシュ値が検出されると、各リストを参照し、当該ハッシュ値がいずれのリストに登録されているかを判定する。続いて、危険通知部７１ｂは、当該ハッシュ値がホワイトリスト３１に登録されている場合には、当該ハッシュ値とシステムＩＤとを保守端末４００に通知する。

一方、危険通知部７１ｂは、当該ハッシュ値がホワイトリスト３１以外のリストに登録されている場合には、再度蓄積ＤＢ４０を参照し、次に新しいハッシュ値を検索する。これ以降は、危険通知部７１ｂは、ホワイトリスト３１に登録されているのが検索できるまで、同様の処理を繰り返す。

ここで、危険通知部７１ｂは、当該ハッシュ値の移動先がブラックリスト３２かイエローリスト３３かによって、報知する内容を変更することもできる。具体的には、危険通知部７１ｂは、移動先がブラックリスト３２の場合には、危険性が高いことから、緊急を要するメッセージを送信する。例えば、危険通知部７１ｂは、製造者側装置１００から対処方法等を取得し、対処方法を保守端末４００に通知する。別例としては、危険通知部７１ｂは、原因がセキュリティホールなどでパッチ等が公開されている場合には、当該パッチを該当システムに送信してもよい。

また、当該ハッシュ値の移動先がイエローリスト３３の場合には、危険性が高いが対処方法が確立していないことが考えられる。このため、危険通知部７１ｂは、原因不明のため、ホワイトリスト３１に登録できる状態に戻すことを促すメッセージや放置しておくことの危険性を示すメッセージを送信する。別例としては、危険通知部７１ｂは、同じようにイエローリスト３３に登録された他システムが実際に対処した方法を、各システムの保守者等から取得して通知することもできる。

なお、ここで示したメッセージはあくまで例示であり、これに限定されるものではない。例えば、ブラックリスト３２またはイエローリスト３３に移動する原因の内容に基づいて、変更することもできる。一例を挙げると、危険通知部７１ｂは、該当する電子機器が当該システムでの使用頻度が高い場合には、緊急を要するメッセージを通知することもできる。また、危険通知部７１ｂは、該当する電子機器が他のシステムで利用される汎用性の高い電子機器である場合には、緊急を要するメッセージを通知することもできる。

また、ここでは、危険通知部７１ｂが、ブラックリスト３２またはイエローリスト３３へ移動した構成情報を有する顧客システム２について、当該システムの以前の構成情報でホワイトリスト３１に登録される構成情報を検索したが、これに限定されるものではない。例えば、危険通知部７１ｂは、ベリファイドリスト３４やアンノウンリスト３５から検索するようにしてもよい。

［処理動作］
続いて、上述した各プロセスで実行される処理動作について説明する。ここでは、構成変更チェック処理、障害判定処理、アンノウンリスト判定処理、イエローリスト判定処理、ベリファイドリスト判定処理、リスト判定処理、危険報知処理について説明する。

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

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

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

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

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

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

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

続いて、障害判定部５４は、蓄積ＤＢ４０を参照して前回取得されたハッシュ値を抽出し、今回取得されたハッシュ値と比較して、変更があるか否かを判定する（ステップＳ２２）。そして、障害判定部５４は、変更があると判定した場合（ステップＳ２２肯定）、取得したハッシュ値がホワイトリスト３１内にあるか否かを判定する（ステップＳ２３）。なお、障害判定部５４は、変更がないと判定した場合（ステップＳ２２否定）、構成が変更されていないことから障害判定済みと判定し、図１１に示す処理動作を終了する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（リスト判定処理）
図１５は、リスト判定処理に関わるサーバ４内のＣＰＵ２７の処理動作の一例を示すフローチャートである。図１５に示すリスト判定処理は、所定の条件に応じて、ブラックリスト３２へ構成情報を新規追加する処理である。また、リスト判定処理は、所定の条件に応じて、ホワイトリスト３１に登録される構成情報をブラックリスト３２またはイエローリスト３３へ移動させる処理である。

図１５に示すように、リスト更新部６１は、製造者側装置１００等からリストへの登録要求を受信すると、当該要求がブラックリスト３２への新規登録か否かを判定する（ステップＳ６１）。そして、リスト更新部６１は、ブラックリスト３２への新規登録である場合（ステップＳ６１肯定）、当該要求とともに受信した構成情報をブラックリスト３２へ登録する（ステップＳ６２）。

一方、リスト更新部６１は、リストへの登録要求がブラックリスト３２への新規登録ではないと判定した場合（ステップＳ６２否定）、ホワイトリスト３１から他リストへの移動要求か否かを判定する（ステップＳ６３）。

そして、リスト更新部６１は、ホワイトリスト３１から他リストへの移動要求であると判定した場合（ステップＳ６３肯定）、ホワイトリスト３１に登録されている該当構成情報を、当該要求で指定されるブラックリスト３２またはイエローリスト３３に登録する（ステップＳ６４）。なお、リスト更新部６１は、ホワイトリスト３１から他リストへの移動要求でないと判定した場合（ステップＳ６３否定）、処理を終了する。

（危険報知処理）
図１６は、危険報知処理に関わるサーバ４内のＣＰＵ２７の処理動作の一例を示すフローチャートである。図１６に示す危険報知処理は、ホワイトリスト３１に登録される構成情報がブラックリスト３２またはイエローリスト３３へ移動したことを検知した場合に、警告メッセージ等を表示部２２に報知する処理である。

図１６に示すように、危険通知部７１ｂは、移動検知部７１ａによってリストの更新があったことが検知されると（ステップＳ７１肯定）、新たに登録された構成情報を有する顧客システム２を抽出する（ステップＳ７２）。具体的には、危険通知部７１ｂは、ホワイトリスト３１に登録される構成情報がブラックリスト３２またはイエローリスト３３へ移動したことを検知された場合に、蓄積ＤＢ４０等を参照して、当該移動した構成情報を有する顧客システム２を特定する。

続いて、危険通知部７１ｂは、抽出した顧客システム２の前回受信時の構成情報を蓄積ＤＢ４０から抽出して、抽出した構成情報がいずれのリストに登録されているかを判定するリスト判定を実行する（ステップＳ７３）。

その後、危険通知部７１ｂは、当該構成情報がイエローリスト３３またはブラックリスト３２以外のリストに登録されていると判定した場合（ステップＳ７４肯定）、当該構成情報を有する顧客システムをビックＤＢ３６から抽出する（ステップＳ７５）。その後、危険通知部７１ｂは、抽出された顧客システムに、警告メッセージ等を表示部２２に報知する（ステップＳ７６）。すなわち、構成変更を行っていないにも関らず、構成情報がホワイトリスト３１からイエローリスト３３またはブラックリスト３２へ移動した各顧客システム２に、セキュリティ低下を知らせる。

一方、危険通知部７１ｂは、当該構成情報がイエローリスト３３またはブラックリスト３２以外のリストに登録されていないと判定した場合（ステップＳ７４否定）、蓄積ＤＢ４０を参照して、さらに１つ前の次に新しい構成情報を抽出する（ステップＳ７７）。その後、危険通知部７１ｂは、ステップＳ７４に戻って以降の処理を繰り返す。

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

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

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

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

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

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

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

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

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

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

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

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

また、実施例１では、ホワイトリスト３１からブラックリスト３２またはイエローリスト３３へ移動した構成情報を有する顧客システム２を検出することができるので、セキュリティの低下などシステム異常の危険性を早期に検出することができる。また、危険性について早期に対処することができ、セキュリティが低下する期間を最低限に抑えることができる。

また、ホワイトリスト３１からブラックリスト３２へ移動した構成情報を有する顧客システム２に対して、ホワイトリスト３１の構成情報や既に確立されている対処方法を通知することができる。また、ホワイトリスト３１からイエローリスト３３へ移動した構成情報を有する顧客システム２に対して、他の顧客が実行した対処方法を通知することができる。

したがって、ホワイトリスト３１、アンノウンリスト３５、ベリファイドリスト３４に該当している構成情報がブラックリスト３２やイエローリスト３３に変更されることになった場合に、その構成情報をもつ顧客を特定してブラックリスト３２等に該当することを回避する指示を出力することができる。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。

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

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

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

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

また、上記実施例では、構成情報の移動を検知した場合に、移動した構成情報を有する顧客システムを特定する例を説明したが、これに限定されるものではない。例えば、監視センタ３側では、顧客システム２から構成情報を受信し、その構成情報がブラックリスト３２またはイエローリスト３３に登録されているか否かを判定する。そして、監視センタ３側では、受信した構成情報がブラックリスト３２またはイエローリスト３３に登録されている場合に、当該構成情報を有する顧客システム２を特定することもできる。

また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

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

Claims (6)

1. 電子機器より受信した構成情報を記憶する記憶部と、
   前記電子機器が第１の状態であることを示す構成情報を記憶する第１のリストと、
   前記電子機器の構成情報を受信した場合に、前記記憶部に基づいて当該構成情報が先に受信した構成情報と異なるか判定し、異なる場合には、前記第１のリストに記憶された構成情報と同一であるかを判定する判定部と、
   前記判定部によって前記第１のリストに記憶された構成情報と同一であると判定された場合に、当該構成情報に対応する電子機器を、前記記憶部から検出する検出部と
   を有することを特徴とする管理装置。
2. 前記記憶部は、前記電子機器の構成情報を時系列で記憶し、
   前記検出部によって検出された電子機器に対して、前記記憶部に記憶される当該電子機器の構成情報を順次参照して、前記電子機器が第２の状態であることを示す構成情報を記憶する第２のリストに該当する構成情報を検出し、検出した構成情報を当該電子機器の保守端末に通知する情報通知部をさらに有することを特徴とする請求項１に記載の管理装置。
3. 前記第１のリストが示す前記電子機器の状態の程度に応じて、前記検出部によって検出された前記電子機器の保守端末に通知する、前記状態に対応する対処内容を変更して通知する対処通知部をさらに有することを特徴とする請求項１または２に記載の管理装置。
4. 前記対処通知部は、前記第１のリストが示す前記電子機器の状態が当該電子機器の製造者で検証済みである場合には、当該状態を解消できる対処方法を前記電子機器の保守端末に通知し、前記第１のリストが示す前記電子機器の状態が原因不明で未検証である場合には、当該状態に対して実施された実績のある対処方法を前記電子機器の保守端末に通知することを特徴とする請求項３に記載の管理装置。
5. コンピュータが、
   電子機器の構成情報を受信した場合に、前記電子機器の構成情報を記憶部に基づいて当該構成情報が先に受信した構成情報と異なるか判定し、異なる場合には、前記電子機器が第１の状態であることを示す構成情報を記憶する第１のリストに記憶された構成情報と同一であるかを判定し、
   前記第１のリストに記憶された構成情報と同一であると判定された場合に、当該構成情報に対応する電子機器を、前記記憶部から検出する
   処理を実行することを特徴とする管理方法。
6. コンピュータに、
   電子機器の構成情報を受信した場合に、前記電子機器の構成情報を記憶部に基づいて当該構成情報が先に受信した構成情報と異なるか判定し、異なる場合には、前記電子機器が第１の状態であることを示す構成情報を記憶する第１のリストに記憶された構成情報と同一であるかを判定し、
   前記第１のリストに記憶された構成情報と同一であると判定された場合に、当該構成情報に対応する電子機器を、前記記憶部から検出する
   処理を実行させることを特徴とする管理プログラム。

Images