JP5848212B2 - リカバリシステム及びリカバリ方法 - Google Patents

Description

本発明は、パーソナルコンピュータ内のハードディスクを暗号化する情報漏えい防止システムを導入しているクライアント端末に対するリカバリ技術に関するものである。

情報システムにおける情報漏えいを防止する手段として、情報漏えい防止システムを導入してパーソナルコンピュータ（以下、ＰＣ）内の全てのハードディスク（以下、ＨＤＤ）を暗号化することで、ＨＤＤ紛失等した際でも解読不可能にするという方法がある。

しかしながら、ＨＤＤを全て暗号化するため、万一ＨＤＤ内のデータがクラッシュしてしまった場合、ＰＣが二度と起動しなくなるというリスクがある。このため、ＨＤＤのクラッシュ時にデータをリカバリする手段が必要である。

リカバリを行う方法として、クライアントＰＣの管理者がＰＣの状態を回復するためのリカバリ用のデータ（以下、リカバリデータ）などを格納したＣＤ（以下、リカバリ媒体）を用いて、障害が発生してクラッシュしたＰＣ（以下、クラッシュＰＣ）をリカバリする方法が用いられる。従来の技術としては特許文献１に記載のものがある。

特開２００６−１４６２９９号公報

従来のリカバリ方式では、リカバリ媒体を使用するユーザが正当なユーザであるか判断するための認証（以下、リカバリ認証）は存在せず、リカバリ媒体を運用により厳密に管理することで、どのクライアントＰＣに対してもリカバリすることができた。この従来のリカバリ方式は、実際に複数のクライアントＰＣにて障害が発生した場合に、柔軟に対応できるという利点がある。

しかしながら、図１０の１００１に示すように、リカバリ媒体が管理者以外の不正なユーザに流出してしまうと、悪意あるユーザによって複数のクライアントＰＣに対してリカバリすることができてしまい、機密情報が漏えいしてしまう危険があった。また、リカバリ認証に成功した上でリカバリを実行するリカバリ方式もある。しかしながら、図１０の１００２に示すように、リカバリ認証にて入力するパスワードが漏えいすると、悪意あるユーザによって複数のクライアントＰＣに対してリカバリを実行することができてしまい、クライアントＰＣ内の機密データが漏えいするという課題がある。

また、図１１に示すように、リカバリ媒体を使用するためのリカバリ認証では、クラッシュＰＣ内の認証データと、リカバリ媒体内の認証データとを用いてリカバリ認証を行うが、クラッシュＰＣ内の認証データが更新されていない場合、正当なユーザかを判断する際に不整合が生じる場合がある。例えば、過去に正当なユーザであったユーザＡが退職するなどして、ある時点から正当なユーザではなくなった場合である。この場合、ユーザＡは、従来は正当なユーザであったため、クラッシュＰＣ内には、ユーザＡに対応する認証データが保存されている。しかしながら、クラッシュＰＣ内の認証データが更新されていないため、正当なユーザではないユーザＡによるリカバリ認証が実行できてしまう。その結果、正当なユーザではないユーザＡが、リカバリを実行できてしまうという課題がある。

本発明はこのような状況に鑑みてなされたものであり、悪意あるユーザがクライアントＰＣに対してリカバリを実行することを防止することが可能なリカバリ技術を提供する。

上記課題を解決するために、本発明のある実施形態によれば、管理サーバと、クライアント端末とを備え、前記管理サーバにおいて作成したリカバリ媒体によって前記クライアント端末をリカバリするリカバリシステムが提供される。このリカバリシステムは、前記クライアント端末をリカバリする際の認証データを前記クライアント端末外の記憶装置に保存する第１の保存手段と、前記認証データを前記クライアント端末に保存する第２の保存手段と、前記クライアント端末外の記憶装置に保存された前記認証データを含むリカバリ媒体を作成する媒体作成手段と、前記クライアント端末において前記リカバリ媒体を使用する際に、前記リカバリ媒体に含まれた前記認証データと、前記クライアント端末に保存されている前記認証データとに基づいてリカバリの認証を行う認証手段と、前記クライアント端末のリカバリに使用される所定のリカバリデータを用いて前記クライアント端末をリカバリするリカバリ手段と、を備えることを特徴とする。

また、本発明の別の実施形態によれば、管理サーバと、クライアント端末とを備える情報システムにおいて、前記管理サーバにおいて作成したリカバリ媒体によって前記クライアント端末をリカバリするリカバリ方法が提供される。このリカバリ方法は、前記クライアント端末をリカバリする際の認証データを前記クライアント端末外の記憶装置に保存する第１の保存ステップと、前記認証データを前記クライアント端末に保存する第２の保存ステップと、前記クライアント端末外の記憶装置に保存された前記認証データを含むリカバリ媒体を作成する媒体作成ステップと、前記クライアント端末において前記リカバリ媒体を使用する際に、前記リカバリ媒体に含まれた前記認証データと、前記クライアント端末に保存されている前記認証データとに基づいてリカバリの認証を行う認証ステップと、前記クライアント端末のリカバリに使用される所定のリカバリデータを用いて前記クライアント端末をリカバリするリカバリステップと、を備えることを特徴とする。

本発明によれば、悪意あるユーザがクライアントＰＣに対してリカバリを実行することを防止し、その結果、情報漏えいを防ぐことが可能となる。

本発明に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、上記した以外の、課題、構成および効果は、以下の実施形態の説明により明らかにされる。

第１実施形態に係るリカバリシステムを説明するための図である。 管理サーバ及びクライアントＰＣのハードウェア構成を示す図である。 管理サーバ、クライアントＰＣ、及び、共有フォルダの具体的な構成を示す図である。 第１実施形態に係るリカバリシステムによるリカバリ媒体の作成、及び、権限の失効を説明する図である。 第１実施形態に係るリカバリシステムによる一形態の運用例を説明する図である。 第１実施形態に係るリカバリシステムにおいてリカバリを実行する際の処理を示すフローチャートである。 第１実施形態に係るリカバリシステムにおいてリカバリの失効処理を示すフローチャートである。 第２実施形態に係るリカバリシステムを説明するための図である。 第２実施形態に係るリカバリシステムによる一形態の運用例を説明する図である。 リカバリ媒体及びリカバリ認証に使用する認証情報を不正なユーザに入手された例を示す図である。 リカバリ媒体の認証データが古いために不正なユーザとなる例を示す図である。 クライアントＰＣ内のリカバリデータが破損した場合の例を示す図である。

以下、添付図面を参照しながら、本発明のリカバリシステムを実施するための形態を詳細に説明する。

＜第１実施形態＞
図１は、第１実施形態に係るリカバリシステムを説明するための図である。第１実施形態に係るリカバリシステムは、クライアントＰＣにリカバリデータを保存しておくリカバリシステム（以下、共有リカバリ方式システム）である。共有リカバリ方式システムは、同一の情報漏えい防止システムを導入しているクライアントＰＣにおいて、一つのリカバリ媒体でリカバリできる方式である。

図１に示すように、第１実施形態に係るリカバリシステムは、管理サーバ１０１と、クライアントＰＣ（クライアント端末）１０２と、共有フォルダ１０３とを備える情報システムで構成されており、管理サーバ１０１と、クライアントＰＣ１０２と、共有フォルダ１０３とは、ネットワークを介して接続されている。

図２は、管理サーバ１０１及びクライアントＰＣ１０２のハードウェア構成を示す図である。管理サーバ１０１及びクライアントＰＣ１０２は、パーソナルコンピュータやワークステーションなどの情報処理装置によって構成されている。管理サーバ１０１及びクライアントＰＣ１０２は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などの中央演算処理装置２０１と、メモリ２０２と、ハードディスク（記憶装置）２０３と、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭなどのコンピュータ読み取り可能な記録媒体に対する読み込み及び書き込みが可能な記録媒体用装置（ドライブ）２０４と、キーボードなどの入力装置２０５と、ディスプレイなどの出力装置２０６とを備えている。

なお、以下で説明する管理サーバ１０１、クライアントＰＣ１０２、及び、共有フォルダ１０３の具体的な構成（図３及び図８に示す処理部）は、実施形態の機能を実現するソフトウェアのプログラムコードで実現してもよい。すなわち、所定のプログラムがプログラムコードとしてメモリ２０２に格納され、中央演算処理装置２０１が各プログラムコードを実行することによって実現できる。

共有フォルダ１０３は、ネットワーク上にある記憶装置である。なお、共有フォルダ１０３は、管理サーバ１０１のハードディスク２０３において設定された共有フォルダとしてもよい。また、共有フォルダ１０３は、ネットワーク上の別の情報処理装置の記憶装置としてもよい。すなわち、共有フォルダ１０３は、クライアントＰＣ１０２以外のネットワーク上の記憶装置に設けられていればよい。

図３は、管理サーバ１０１、クライアントＰＣ１０２、及び、共有フォルダ１０３の具体的な構成を示す図である。管理サーバ１０１は、媒体作成部３０１と、リカバリユーザ管理部３０２と、認証データ管理部３０３と、ハードディスク２０３に格納されたデータベース（ＤＢ）３０４とを備える。

媒体作成部３０１は、クライアントＰＣ１０２で使用するコンピュータ読み取り可能な記録媒体を作成するための処理部であり、記録媒体用装置２０４を用いて所定のデータが格納された記録媒体を作成する。媒体作成部３０１は、情報漏えい防止システムをインストールするためのパッケージ（以下、インストール媒体）、及び、クライアントＰＣ１０２のリカバリに使用されるリカバリ媒体を作成する。

リカバリユーザ管理部３０２は、リカバリユーザの情報を管理するためのものであり、データベース３０４に対するリカバリユーザの情報の登録処理、更新処理、削除処理などを実行する処理部である。ここで、「リカバリユーザ」とは、クライアントＰＣ１０２をリカバリできる権限を有するユーザを意味する。リカバリユーザの情報としては、リカバリユーザのＩＤやパスワードなどの、リカバリユーザの認証に必要な情報である。これにより、データベース３０４に登録されたリカバリユーザのみが、媒体作成部３０１によってリカバリ媒体を作成できることになる。

認証データ管理部３０３は、認証データを管理するものであり、認証データ登録部３０５と、認証データ送信部３０６とを備える。ここで、「認証データ」とは、クライアントＰＣ１０２においてリカバリを実行する際に用いられるデータである。共有リカバリ方式システムにおける認証データは、作成したインストール媒体を識別するための媒体識別情報（以下、媒体識別ＩＤ）と、クライアントＰＣ１０２においてリカバリを実行する際の有効／無効を示すリカバリ識別情報（以下、リカバリ識別ＩＤ）とを含む。

認証データ登録部３０５は、データベース３０４に対する認証データの登録処理、更新処理、削除処理などを実行する処理部である。したがって、認証データ登録部３０５によって、媒体識別ＩＤと、リカバリ識別ＩＤとがデータベース３０４に登録される。認証データ送信部３０６は、認証データ登録部３０５によって登録された認証データを共有フォルダ１０３に自動的に保存する処理部である。

データベース３０４は、上述したリカバリユーザ及び認証データを管理するためのデータベースである。例えば、データベース３０４は、リカバリユーザを管理するテーブル、及び、認証データを管理するテーブルを備える。これら情報は必ずしもテーブルによるデータ構造で表現されていなくても良く、リスト、ＤＢ、キュー等のデータ構造やそれ以外で表現されていても良い。

また、クライアントＰＣ１０２は、認証データ更新部３０７を備える。認証データ更新部３０７は、共有フォルダ１０３において更新された認証データをクライアントＰＣ１０２のローカルのハードディスク２０３に保存する処理部である。さらに、共有フォルダ１０３を備える情報処理装置（管理サーバ１０１あるいは別の情報処理装置）には、共有フォルダ１０３の認証データが更新されたかを監視するためのエージェント（ソフトウェア）３０８が組み込まれている。なお、エージェント３０８は、共有フォルダ１０３の認証データの更新を検知した場合、認証データをクライアントＰＣ１０２に配信するように構成してもよい。

次に、図１を用いて、本実施形態の共有リカバリ方式システムの処理の流れについて説明する。
まず、管理サーバ１０１において、ユーザが、インストール媒体１２１の作成を実行する（１１１）。そして、媒体作成部３０１によって、情報漏えい防止システムをインストールするためのインストール媒体１２１が作成される（１１２）。インストール媒体１２１には、作成したインストール媒体を識別するための媒体識別ＩＤ１２２が含まれる。媒体識別ＩＤ１２２は、入力装置２０５による入力で設定されてもよいし、乱数などによって自動的に設定されてもよい。また、媒体識別ＩＤ１２２は、インストール媒体１２１を使用する部署名（グループ情報）などの情報と対応付けて設定されてもよい。なお、媒体識別ＩＤ１２２が部署名に紐付けられている場合、インストール媒体１２１には、媒体識別ＩＤ１２２と部署名とを紐づけた情報が格納される。

次に、管理サーバ１０１において、リカバリユーザの登録を行う（１１３）。この際、リカバリユーザ管理部３０２によって、リカバリユーザのＩＤ及びパスワードなどがデータベース３０４に登録される。次に、管理サーバ１０１において、認証データ１２３の登録を行う。この際、認証データ登録部３０５によって、図１の（１１２）において設定された媒体識別ＩＤ１２２と、リカバリ識別ＩＤとを含む認証データ１２３がデータベース３０４に登録される（１１４）。

次に、認証データ送信部３０６によって、認証データ１２３の保存を実行する（１１５）。認証データ送信部３０６は、認証データ登録部３０５によってデータベース３０４に登録された認証データ１２３を共有フォルダ１０３に自動的に保存する。

次に、クライアントＰＣ１０２において、インストール媒体１２１によって情報漏えい防止システムがインストールされる（１１６）。この際、クライアントＰＣ１０２には、インストール媒体１２１によってリカバリデータ１２４も格納される。ここで、「リカバリデータ」とは、クライアントＰＣ１０２においてリカバリを実行する際に使用されるデータであり、クライアントＰＣ１０２の状態を回復するためのデータである。リカバリデータは、例えば、ブートローダ、アカウント情報（認証ＩＤ及びパスワード）、及び、ポリシーなどである。さらに、クライアントＰＣ１０２には、インストール媒体１２１に格納された媒体識別ＩＤ１２２も格納される。したがって、インストール媒体１２１によってインストールを実行する際に、媒体識別ＩＤ１２２及びリカバリデータ１２４がクライアントＰＣ１０２に格納される。

次に、インストール媒体１２１によるイントールを実行した後、クライアントＰＣ１０２を起動すると、認証データ更新部３０７によって、クライアントＰＣ１０２に認証データ１２３が保存される（１１７）。例えば、認証データ更新部３０７は、インストール時に格納された媒体識別ＩＤ１２２を用いて、共有フォルダ１０３に格納された認証データ１２３の中からクライアントＰＣ１０２に対応する認証データ１２３を自動的に取得することができる。なお、エージェント３０８が、共有フォルダ１０３の認証データ１２３の更新を検知して、認証データ１２３を自動的にクライアントＰＣ１０２に配信してもよい。このとき、クライアントＰＣ１０２の起動の有無にかかわらず認証データ１２３は送信される。この場合、認証データ更新部３０７が、認証データ１２３を受信して、クライアントＰＣ１０２に認証データ１２３を保存する。

上述したように、例えば、認証データ更新部３０７は、インストール媒体１２１によるインストール後の再起動時に自動的に共有フォルダ１０３内にある認証データ１２３をダウンロードし、ローカルのハードディスク２０３に保存する。また、認証データ更新部３０７は、クライアントＰＣ１０２の起動時に共有フォルダ１０３の認証データ１２３の更新を確認し、認証データ１２３を自動的に取得し、即座にローカルの認証データ１２３を更新するようにしてもよい。クライアントＰＣ１０２が起動していない状態で共有フォルダ１０３の認証データ１２３が更新された場合は、クライアントＰＣ１０２の次回起動時に、認証データ更新部３０７が自動的に認証データ１２３をダウンロードしてもよい。

なお、上記動作に関しては、クライアントＰＣ１０２ではユーザによる特別な操作などは行わず、認証データ更新部３０７が、自動的に上記動作を行い、認証データ１２３を更新する。認証データ更新部３０７は、認証データ１２３の未更新を防止するために、クライアントＰＣ１０２の起動時以外に定期的な間隔およびリカバリ媒体によるリカバリ時において共有フォルダ１０３から認証データ１２３をダウンロードするようにしてもよい。

また、共有リカバリ方式システムにおけるリカバリ認証は、１つのリカバリ媒体を複数のクライアントＰＣ１０２に対して使用できるため、上述の課題として挙げたパスワードが漏えいした場合の対処として、パスワードによる認証ではなく、チャレンジ・レスポンスによる管理サーバ１０１とクライアントＰＣ１０２との間のやりとりが必要な認証方法を採用している。

上記より、管理サーバ１０１で認証データ１２３が更新された場合、最新の認証データ１２３が共有フォルダ１０３に送信される。また、クライアントＰＣ１０２の認証データ更新部３０７は、（１）クライアントＰＣ１０２の起動時に自ら認証データ１２３を取得する場合、（２）クライアントＰＣ１０２の起動中に共有フォルダ１０３から配信された認証データ１２３を受信する場合、（３）共有フォルダ１０３から認証データ１２３の配信はないが定期的に認証データ１２３を取得する場合、（４）リカバリ媒体によるクライアントＰＣ１０２の起動時に認証データ１２３を取得する場合の４パターンの少なくとも１つの取得方法によって、クライアントＰＣ１０２内の認証データ１２３を最新の状態に保つことが可能である。

図４は、情報漏えい防止システムを導入した環境において共有リカバリ方式システムによるリカバリ媒体の作成、及び、権限の失効を説明する図である。

まず、リカバリユーザが、管理サーバ１０１においてリカバリ媒体４１１の作成を実行する（４０１）。この際、媒体作成部３０１は、データベース３０４に登録されているリカバリユーザの情報を用いて、リカバリ媒体４１１を作成しようとするユーザに対する認証を実行する。そして、正当なリカバリユーザである場合は、媒体作成部３０１によってリカバリ媒体４１１が作成される（４０２）。

なお、媒体作成部３０１によりリカバリ媒体４１１を作成する際、リカバリ媒体４１１には、リカバリユーザのＩＤ及びパスワードと、認証データ（クライアントＰＣ１０２においてリカバリを実行する際の有効／無効を示すリカバリ識別ＩＤと、インストール媒体１２１を識別するための媒体識別ＩＤ１２２）１２３とが格納される。

このように、リカバリ媒体４１１にリカバリユーザのＩＤ及びパスワードを格納しておくことにより、リカバリを実行するユーザが不当なユーザの場合、クライアントＰＣ１０２においてリカバリを実行できないように制御することが可能となる。また、リカバリ媒体４１１に認証データ１２３を格納しておくことにより、リカバリ媒体４１１が不正にコピーされた場合でも、そのリカバリ媒体４１１でクライアントＰＣ１０２においてリカバリが実行できないように制御することが可能となる。

クライアントＰＣ１０２におけるリカバリを制御する手法としては、リカバリユーザの権限を失効させる処理と、認証データ１２３を更新する処理とがある。以下では、それぞれの処理について説明する。

リカバリユーザの権限を失効させる場合、リカバリユーザ管理部３０２によって、データベース３０４に登録されているリカバリユーザのＩＤやパスワードなどの情報を失効させる（例えば、削除する）（４０３）。これにより、登録されていないユーザは、媒体作成部３０１によってリカバリ媒体４１１を作成できなくなる（４０４）。

また、認証データ１２３を更新する場合、認証データ登録部３０５によって、管理サーバ１０１内のデータベース３０４の認証データ１２３のリカバリ識別ＩＤの設定を「無効」に設定する（４０５）。ここで、管理サーバ１０１の認証データ１２３のリカバリ識別ＩＤが更新されると、認証データ送信部３０６が、更新された認証データ１２３を自動的に共有フォルダ１０３に送信して保存する（４０６）。続いて、共有フォルダ１０３に保存された認証データ１２３が、クライアントＰＣ１０２の認証データ更新部３０７によって、クライアントＰＣ１０２に自動的に保存され、クライアントＰＣ１０２内の認証データ１２３が更新される（４０７）。このように認証データ１２３のリカバリ識別ＩＤを更新することによって、リカバリ媒体４１１によるリカバリを失効させて、リカバリ媒体４１１自体を使用できないようにすることが可能となる。

なお、上述のように、インストール媒体１２１に、媒体識別ＩＤ１２２と部署名とを紐づけた情報を格納していた場合には、図４の（４０１）及び（４０２）の段階において、クライアントＰＣ１０２の利用者から部署名を聞き、部署名と紐づけられた媒体識別ＩＤをリカバリ媒体４１１へ格納してもよい。この場合、部署ごとにリカバリ媒体４１１を管理し、部署毎に共通の認証データ１２３が使用できる。これにより、同じ部署のクライアントＰＣ１０２については同一のリカバリ媒体４１１を使用することが可能になる。

図５は、共有リカバリ方式システムによる一形態の運用例を説明する図である。図５の運用例では、管理サーバ１０１、クライアントＰＣ１０２Ａ、クライアントＰＣ１０２Ｂ、共有フォルダ１０３がそれぞれネットワーク経由で接続されている。クライアントＰＣ１０２Ａ及びクライアントＰＣ１０２Ｂは、同一部署のクライアントＰＣであるとする。また、クライアントＰＣ１０２Ａ及びクライアントＰＣ１０２Ｂには、情報漏えい防止システムが導入済みであり、同一のインストール媒体によって情報漏えい防止システムがインストールされているとする。

例えば、管理者Ａが、クライアントＰＣ１０２Ａ及びクライアントＰＣ１０２Ｂに対してリカバリを実行しようとする場合、管理者Ａがリカバリユーザとして登録される。管理者Ａをリカバリユーザとしてデータベース３０４に登録した後、管理サーバ１０１内のデータベース３０４に認証データ１２３が登録される。次に、認証データ１２３は、共有フォルダ１０３に保存され、その後、認証データ１２３が、クライアントＰＣ１０２Ａ及びクライアントＰＣ１０２Ｂのローカルのハードディスク２０３に保存される。

クライアントＰＣ１０２Ａがクラッシュした場合、管理者Ａは、管理サーバ１０１の媒体作成部３０１を用いてリカバリ媒体４１１を作成する。このとき、リカバリ媒体４１１には、リカバリユーザのＩＤ及びパスワードと、認証データ（媒体識別ＩＤ及びリカバリ識別ＩＤ）１２３が格納される。なお、インストール媒体１２１に、媒体識別ＩＤと部署名とを紐づけた情報を格納していた場合には、クライアントＰＣ（例えば、１０２Ａ）の利用者（ユーザＡ）より部署名を聞き、部署名と紐づけられた媒体識別ＩＤをリカバリ媒体４１１へ格納してもよい。

作成したリカバリ媒体４１１でクライアントＰＣ１０２Ａをリカバリしようと試みた場合、クライアントＰＣ１０２Ａにて管理者Ａが正当なリカバリユーザであるかを確認するために、認証処理が実行される。リカバリ媒体４１１は、ブートディスクであり、認証プログラム（認証手段）と、リカバリデータ１２４を用いてクライアントＰＣ１０２Ａをリカバリ（回復）するためのリカバリプログラム（リカバリ手段）と備える。

例えば、認証プログラムが起動した際に、リカバリユーザのＩＤ及びパスワードの入力が要求される。まず、入力したリカバリユーザのＩＤと、リカバリ媒体４１１内のリカバリユーザのＩＤ、そしてクライアントＰＣ１０２Ａ内のリカバリデータ１２４のアカウント情報の認証ＩＤを比較する認証処理が実行される。次に、入力されたリカバリユーザのパスワードと、クライアントＰＣ１０２Ａ内のリカバリデータ１２４のアカウント情報のパスワードと比較する認証処理が実行される。リカバリ媒体４１１内のリカバリユーザのパスワードとも比較する認証処理を実行してもよい。

また、認証プログラムによって、リカバリ媒体４１１の認証データと、共有フォルダ１０３から送信されてクライアントＰＣ１０２Ａ内に保存されている認証データ１２３とを比較する認証処理が実行される。すなわち、クライアントＰＣ１０２Ａ内に保存されている媒体識別ＩＤと、リカバリ媒体４１１の媒体識別ＩＤとが一致し、且つ、クライアントＰＣ１０２Ａ内に保存されているリカバリ認証ＩＤが有効になっているかを判定する。この条件が一致した場合には、リカバリ媒体４１１によるリカバリが正当であると判定される。

上記の認証によってリカバリ媒体４１１によるリカバリが正当であると判定された場合、リカバリプログラムによって、クライアントＰＣ１０２Ａ内に格納されているリカバリデータ１２４を用いてクライアントＰＣ１０２Ａのリカバリが実行される。このとき、リカバリ媒体４１１に、部署名と紐づけられた媒体識別ＩＤが格納されている場合は、同一部署内のクライアントＰＣ１０２Ｂがクラッシュした場合でも、同一のリカバリ媒体４１１を用いて管理者Ａはリカバリを実行することができる。

ここで、管理者Ａをリカバリユーザとしての権限を失効させたい場合、管理者Ｂは、リカバリユーザ管理部３０２によって、データベース３０４における管理者Ａのリカバリユーザの情報を失効させる。これにより、管理者Ａは、リカバリ媒体４１１を管理サーバ１０１において作成できなくなる。

また、リカバリ媒体４１１自体の有効性を失効させたい場合、管理者Ａあるいは管理者Ｂは、認証データ管理部３０３の認証データ登録部３０５によって、データベース３０４のリカバリ識別ＩＤを「無効」に更新する。更新された認証データ１２３は、共有フォルダ１０３の認証データ１２３に自動的に反映される。さらに、共有フォルダ１０３の認証データ１２３は、自動的にクライアントＰＣ１０２Ａ及び１０２Ｂのローカルのハードディスク２０３に保存される。更新後、管理者Ａが、作成したリカバリ媒体４１１によって、クライアントＰＣ１０２Ａのリカバリを実行しようと試みても、クライアントＰＣ１０２Ａの認証データ１２３内のリカバリ識別ＩＤが「無効」となっているので、リカバリは実行できない。このように、リカバリ識別ＩＤを更新することで、リカバリ媒体４１１そのものを使用不可能にすることができる。したがって、作成したリカバリ媒体４１１の有効／無効を制御することが可能になる。

図６は、共有リカバリ方式システムにおいてリカバリを実行する際の処理を示すフローチャートである。図６にて、破線は、管理サーバ１０１またはクライアントＰＣ１０２における自動処理を示し、実線は、ユーザの手動による作業を含む処理である。

ステップ６０１において、管理サーバ１０１でリカバリユーザの登録を行う。この際、リカバリユーザ管理部３０２によって、リカバリユーザのＩＤ及びパスワードなどがデータベース３０４に登録される。

次に、ステップ６０２において、管理サーバ１０１で認証データ１２３の登録を行う。この際、認証データ登録部３０５によって、認証データ（媒体識別ＩＤ及びリカバリ識別ＩＤ）１２３がデータベース３０４に登録される。次に、ステップ６０３において、認証データ送信部３０６によって、データベース３０４に登録された認証データ１２３が共有フォルダ１０３に自動的に保存される。

次に、ステップ６０４において、クライアントＰＣ１０２を起動すると、認証データ更新部３０７によって、クライアントＰＣ１０２に認証データ１２３が保存される。なお、認証データ更新部３０７は、クライアントＰＣ１０２の起動時以外に定期的な間隔で共有フォルダ１０３から認証データをダウンロードして保存する。

次に、ステップ６０５において、リカバリユーザである管理者が、クライアントＰＣ１０２のユーザから部署名を聞く。そして、ステップ６０６において、管理者が、部署名を指定し、これにより、媒体作成部３０１によってリカバリ媒体４１１が作成される。この際、リカバリ媒体４１１には、リカバリユーザのＩＤ及びパスワードと、部署名と紐づけられた媒体識別ＩＤと、リカバリ識別ＩＤとが格納される。

次に、ステップ６０７において、管理者が、リカバリ媒体４１１を用いてクライアントＰＣ１０２においてリカバリを実行する。リカバリの実行を試みると、ステップ６０８において、管理者が正当なリカバリユーザであるかを確認するために、リカバリユーザのＩＤとパスワードを入力させる。入力させたリカバリユーザのＩＤと、リカバリ媒体４１１内のリカバリユーザのＩＤと、そしてクライアントＰＣ１０２Ａ内のリカバリデータ１２４のアカウント情報（認証ＩＤ）とを比較して認証処理が実行される。リカバリユーザのＩＤが一致していた場合、入力させたリカバリユーザのパスワードと、クライアントＰＣ１０２Ａ内のリカバリデータ１２４のアカウント情報（パスワード）とを比較して認証処理が実行される。認証処理の結果、正当なリカバリユーザの場合はステップ６１０に進む。一方、そうでない場合は、ステップ６０９に進んでリカバリを実行することが不可能になる。

ステップ６１０に進んだ場合、正当なリカバリ媒体４１１であるかを判定する。すなわち、認証プログラムによって、リカバリ媒体４１１の認証データと、クライアントＰＣ１０２Ａ内に保存されている認証データ１２３とを比較する認証処理が実行される。ここで、クライアントＰＣ１０２内に保存されている媒体識別ＩＤと、リカバリ媒体４１１の媒体識別ＩＤとが一致し、且つ、クライアントＰＣ１０２内に保存されているリカバリ認証ＩＤが有効になっている場合には、リカバリ媒体４１１によるリカバリが正当であるとして、ステップ６１１に進む。ステップ６１１では、リカバリプログラムによって、リカバリデータ１２４を用いてクライアントＰＣ１０２のリカバリが実行される。一方、ステップ６１０で正当でないと判定された場合は、ステップ６１２に進んでリカバリを実行することが不可能になる。

図７は、共有リカバリ方式システムにおいてリカバリの失効処理を示すフローチャートである。図７にて、破線は、管理サーバ１０１またはクライアントＰＣ１０２における自動処理を示し、実線は、ユーザの手動による作業を含む処理である。

まず、ステップ７０１において、管理者はリカバリユーザの失効を行うか、あるいは、リカバリ識別ＩＤの失効を行うかを決定する。リカバリ識別ＩＤの失効を行う場合は、ステップ７０２に進み、リカバリユーザの失効を行う場合は、ステップ７０３に進む。

ステップ７０３に進んだ場合、リカバリユーザ管理部３０２によって、データベース３０４における管理者のリカバリユーザの情報を失効させる。これにより、ステップ７０４のように、失効されたリカバリユーザは、リカバリ媒体４１１を管理サーバ１０１において作成できなくなる。

ステップ７０２に進んだ場合、管理者は、データベース３０４のリカバリ識別ＩＤの失効を実行する。次に、ステップ７０５において、認証データ管理部３０３の認証データ登録部３０５によって、データベース３０４のリカバリ識別ＩＤが「無効」に更新される。次に、ステップ７０６において、認証データ送信部３０６によって、共有フォルダ１０３の認証データ１２３が自動的に更新される。さらに、ステップ７０７において、認証データ更新部３０７によって、クライアントＰＣ１０２の認証データ１２３が更新される。なお、認証データ更新部３０７は、クライアントＰＣ１０２の起動時、及び、定期的な間隔で、共有フォルダ１０３から認証データ１２３をダウンロードして更新する。

次に、ステップ７０８において、管理者が、リカバリ媒体４１１を用いてクライアントＰＣ１０２においてリカバリを実行する。リカバリの実行を試みると、ステップ７０９において、管理者が正当なリカバリユーザであるかを確認するために、リカバリユーザのＩＤとパスワードを入力させる。入力させたリカバリユーザのＩＤと、リカバリ媒体４１１内のリカバリユーザのＩＤと、そしてクライアントＰＣ１０２内のリカバリデータ１２４のアカウント情報（認証ＩＤ）とを比較する認証処理が実行される。これらのリカバリユーザのＩＤが一致していた場合は、入力させたリカバリユーザのパスワードと、クライアントＰＣ１０２内のリカバリデータ１２４のアカウント情報（パスワード）とを比較する認証処理が実行される。認証処理の結果、正当なリカバリユーザの場合はステップ７１１に進む。一方、そうでない場合は、ステップ７１０に進んでリカバリを実行することが不可能になる。

ステップ７１１に進んだ場合、正当なリカバリ媒体４１１であるかを判定する。すなわち、リカバリ媒体４１１の認証データと、クライアントＰＣ１０２内に保存されている認証データ１２３とを比較して認証を行う。ここで、クライアントＰＣ１０２内に保存されている媒体識別ＩＤと、リカバリ媒体４１１の媒体識別ＩＤとが一致し、且つ、クライアントＰＣ１０２内に保存されているリカバリ認証ＩＤが有効になっている場合には、正当なリカバリ媒体であるとしてステップ７１１に進み、クライアントＰＣ１０２のリカバリが実行される。この例では、認証データ１２３のリカバリ認証ＩＤが「無効」に更新されているため、ステップ７１３に進んでリカバリを実行することが不可能になる。このように、リカバリ識別ＩＤを更新することで、作成したリカバリ媒体４１１の有効／無効を制御することが可能になる。この処理は、リカバリ媒体４１１が紛失して、リカバリ媒体４１１自体を失効させたい場合に有益である。

なお、認証データ１２３にリカバリユーザのＩＤとパスワードを含めるようにして、この認証データ１２３によってリカバリユーザの失効を制御してもよい。この場合、管理サーバ１０１において、データベース３０４に登録されているリカバリユーザのＩＤやパスワードなどの情報を失効させる（例えば、削除する）と、その情報が共有フォルダ１０３の認証データ１２３に反映され、最終的に、クライアントＰＣ１０２Ａ内に保存されている認証データ１２３に反映される。この構成では、ステップ７０９において、入力させたリカバリユーザのＩＤと、クライアントＰＣ１０２Ａ内に保存されている認証データ１２３のリカバリユーザのＩＤとの比較処理も実行される。この場合、リカバリユーザの失効後では、クライアントＰＣ１０２Ａ内に保存されている認証データ１２３のリカバリユーザのＩＤ及びパスワードが失効（削除）されているため、認証処理で失敗し、ステップ７１０に進むことになる。このように、認証データ１２３によってリカバリユーザの失効を制御することも可能である。

＜第２実施形態＞
図８は、第２実施形態に係るリカバリシステムを説明するための図である。第２実施形態に係るリカバリシステムは、クライアントＰＣ外にリカバリデータを保存しておくリカバリシステム（以下、端末固有リカバリ方式）である。端末固有リカバリ方式システムは、情報漏えい防止システムを導入しているクライアントＰＣにおいて、そのクライアントＰＣ専用のリカバリ媒体を作成してリカバリできる方式である。

図８の例では、管理サーバ８０１、クライアントＰＣ８０２、共有フォルダ８０３がそれぞれネットワーク経由で接続されている。管理サーバ８０１及びクライアントＰＣ８０２のハードウェアの構成は図２と同様であるため、説明を省略する。以下では、管理サーバ８０１とクライアントＰＣ８０２の構成については、第１実施形態と異なる部分について説明する。

まず、クライアントＰＣ８０２は、識別情報生成部８３１と、リカバリ情報ファイル送信部８３２とを備える。識別情報生成部８３１は、インストール媒体８２１によってクライアントＰＣ８０２でインストールが実行された場合に、クライアントＰＣ８０２の端末を識別するための端末識別情報（以下、端末固有ＩＤ）を生成する。端末固有ＩＤは、乱数などによって自動的に生成されてもよいし、ユーザからの入力によって設定されてもよい。

リカバリ情報ファイル送信部８３２は、リカバリ情報ファイル８２４を共有フォルダに送信する。ここで、「リカバリ情報ファイル」とは、リカバリデータ８２５と認証データ８２３とを含むものである。リカバリデータ８２５は、第１実施形態と同様の内容である。一方、第２実施形態では、認証データ８２３は、端末固有ＩＤと媒体識別ＩＤとを含むものである。

インストール媒体８２１には、媒体識別ＩＤ８２２が含まれる。インストール媒体８２１によって情報漏えい防止システムがクライアントＰＣ８０２にインストールされると、クライアントＰＣ８０２には、媒体識別ＩＤ８２２とリカバリデータ８２５が格納される。そして、識別情報生成部８３１が、端末固有ＩＤを生成してクライアントＰＣ８０２内のローカルに保存する。これにより、認証データ８２３とリカバリデータ８２５が、クライアントＰＣ８０２内に保存されることになる。リカバリ情報ファイル送信部８３２は、リカバリ情報ファイル８２４（すなわち、認証データ８２３とリカバリデータ８２５）を共有フォルダ８０３に送信する。

管理サーバ８０１は、リカバリ情報ファイル取得部８３３を備える。リカバリ情報ファイル取得部８３３は、共有フォルダ８０３にアクセスしてリカバリ情報ファイル８２４を取得するものである。なお、リカバリ情報ファイル取得部８３３で取得されたリカバリ情報ファイル８２４は、媒体作成部３０１によってリカバリ媒体を作成する際に用いられる。

次に、インストール媒体８２１によって情報漏えい防止システムをクライアントＰＣ８０２にインストールするまでの処理の流れを説明する。

端末固有リカバリ方式システムにおいて、管理サーバ８０１でインストール媒体８２１を作成するまでの処理は共有リカバリ方式システムと同じである。すなわち、まず、管理サーバ８０１において、ユーザが、インストール媒体８２１の作成を実行する（８１１）。そして、媒体作成部３０１によって、情報漏えい防止システムをインストールするためのインストール媒体８２１が作成される（６１２）。インストール媒体８２１には、インストール媒体８２１を識別するための媒体識別ＩＤ８２２が含まれる。

次に、クライアントＰＣ８０２において、インストール媒体８２１によって情報漏えい防止システムがインストールされる（８１３）。この際、クライアントＰＣ８０２では、識別情報生成部８３１によって端末固有ＩＤが生成される。そして、クライアントＰＣ８０２には、端末固有ＩＤ及び媒体識別ＩＤ８２２が認証データ８２３として保存される。また、インストール媒体８２１によってリカバリデータ８２５も格納される。そして、クライアントＰＣ８０２において、リカバリ情報ファイル送信部８３２によって、リカバリ情報ファイル８２４が共有フォルダ８０３に送信される（８１４）。

リカバリユーザが、リカバリ媒体を作成して、リカバリを実行する場合は以下の処理の流れとなる。まず、リカバリユーザが、管理サーバ８０１においてリカバリ媒体を作成する場合、媒体作成部３０１は、リカバリ情報ファイル取得部８３３によって取得されたリカバリ情報ファイル８２４を用いてリカバリ媒体を作成する。本実施形態のリカバリ媒体には、リカバリユーザのＩＤ及びパスワードと、リカバリ情報ファイル（リカバリデータ８２５、認証データ８２３（媒体識別ＩＤ８２２及び端末固有ＩＤ））８２４とが格納される。

クライアントＰＣ８０２に対してリカバリ媒体を使用してリカバリを実行する際に、リカバリ媒体内とクライアントＰＣ８０２内の媒体識別ＩＤ及び端末固有ＩＤが同一かどうかを判定し、同一であれば、パスワード情報を用いたリカバリ認証を実行する。リカバリ認証を実行する前に、媒体識別ＩＤ及び端末固有ＩＤを判定することで、使用するリカバリ媒体がそのクライアントＰＣ８０２専用であるかどうかを確認する。もし、そのクライアントＰＣ８０２専用でないリカバリ媒体を使用しようとしていた場合は、この判定によって、誤ったリカバリ媒体を使用しようとしていることが分かる。

また、端末固有リカバリ方式システムでのリカバリ媒体には、リカバリデータ８２５を内包しているため、クライアントＰＣ８０２内のリカバリデータ８２５が損壊している状態であっても、リカバリを実行することが可能である。

図９は、端末固有リカバリ方式システムによる一形態の運用例を説明する図である。図９の運用例では、管理サーバ８０１、クライアントＰＣ８０２Ａ、クライアントＰＣ８０２Ｂ、共有フォルダ８０３がそれぞれネットワーク経由で接続されている。

まず、管理者が、管理サーバ８０１においてインストール媒体Ａ８２１を作成し、クライアントＰＣ８０２Ａ及びクライアントＰＣ８０２Ｂに対して情報漏えい防止システムのインストールを実行する。クライアントＰＣ８０２Ａに対してインストール媒体Ａ８２１でインストールする際には、端末固有ＩＤ＿Ａが生成され、クライアントＰＣ８０２Ｂに対してインストール媒体Ａ８２１でインストールする際には、端末固有ＩＤ＿Ｂが生成される。クライアントＰＣ８０２Ａ及びクライアントＰＣ８０２Ｂの各々から、リカバリデータ８２５と認証データ（端末固有ＩＤ及び媒体識別ＩＤ）８２３とを含むリカバリ情報ファイル８２４が、共有フォルダ８０３にアップロードされる。この時に、認証データ８２３は、クライアントＰＣ８０２Ａ及びクライアントＰＣ８０２Ｂの各々にも保存されている。

その後、クライアントＰＣ８０２Ａ及びクライアントＰＣ８０２Ｂを運用中に、ＰＣがクラッシュするなどして障害が発生した場合を想定する。この場合に、管理者は、クライアントＰＣ８０２Ａ専用のリカバリ媒体として、共有フォルダ８０３にアップロードしているリカバリ情報ファイル８２４を含むリカバリ媒体Ａ９０１を作成する。そして、リカバリ媒体Ａ９０１によって障害が発生したクライアントＰＣ８０２Ａを起動する。

リカバリ媒体Ａ９０１は、上述したように、認証プログラムとリカバリプログラムとを備える。したがって、この認証プログラムによって、認証データの比較を行うことができる。この際、リカバリ媒体Ａ９０１の中の媒体識別ＩＤと、クライアントＰＣ８０２Ａ内に格納している媒体識別ＩＤを取り出して、これらが同一であるか判定する。次に、リカバリ媒体Ａ９０１の中の端末固有ＩＤと、クライアントＰＣ８０２Ａ内に格納している端末固有ＩＤとを取り出して、これが同一であるか判定する。この例では、双方の端末固有ＩＤは共に端末固有ＩＤ＿Ａであるため、同一であるとみなされる。この２つの認証が成功した後、パスワード情報を用いたリカバリ認証を実行する。リカバリ認証には、パスワードによる認証方式と、共有リカバリ方式と同じチャレンジ・レスポンスによる認証方式があり、リカバリ時に選択することが可能である。

上述の認証によってリカバリが正当であると判定された場合、リカバリプログラムによって、リカバリ媒体Ａ９０１に含まれたリカバリデータを用いてクライアントＰＣ８０２Ａのリカバリが実行される。これにより、障害が発生したクライアントＰＣ８０２Ａを正常状態に復旧することができる。

もし、障害が発生したクライアントＰＣ８０２Ａに対して、リカバリ媒体Ｂ９０２を使用しようとすると、次の通りになる。まず、クライアントＰＣ８０２Ａ内の媒体識別ＩＤと、リカバリ媒体Ｂ９０２内の媒体識別ＩＤとを取り出して比較する。双方の媒体識別ＩＤは同一である。次に、クライアントＰＣ８０２Ａ内の端末固有ＩＤと、リカバリ媒体Ｂ９０２内の端末固有ＩＤとを取り出して比較する。クライアントＰＣ８０２Ａの端末固有ＩＤは、「端末固有ＩＤ＿Ａ」であり、リカバリ媒体Ｂ９０２内の端末固有ＩＤは、「端末固有ＩＤ＿Ｂ」であるので、端末固有ＩＤは異なり、クライアントＰＣ８０２Ａに対してリカバリ媒体Ｂ９０２は使用できないと判定される。このように、クライアントＰＣ８０２Ａ、８０２Ｂ毎にリカバリ媒体９０１、９０２を作成することによって、対象となるクライアントＰＣ以外のクライアントＰＣにリカバリ媒体が使用されるのを防ぐことができる。

また、図１２に示すように、クライアントＰＣ内のリカバリデータを用いてリカバリを行う場合に、クライアントＰＣがクラッシュしていると、このリカバリデータも壊れている場合がある。第２実施形態の端末固有リカバリ方式システムでは、リカバリ媒体Ａ９０１がリカバリデータを内包しているため、クライアントＰＣ８０２Ａ内のリカバリデータ８２５が損壊している状態であっても、リカバリ媒体Ａ９０１に格納されているリカバリデータを用いてリカバリを実行することが可能である。

以上のように、第１実施形態の共有リカバリ方式システムでは、管理サーバ１０１に登録された認証データ１２３を共有フォルダ１０３に保存し、続いて、その認証データ１２３がクライアントＰＣ１０２に保存される。リカバリ媒体４１１内の認証データと、クライアントＰＣ１０２の認証データ１２３を比較することにより、リカバリの認証を行うことができる。この構成によれば、最新の認証データ１２３でリカバリを実行するための認証を行うことが可能になる。これにより、悪意あるユーザがクライアントＰＣに対してリカバリを実行することを防止しつつ、認証データが古いために過去のユーザのリカバリが成功してしまうという課題も解決することができる。また、同一のインストール媒体をインストールしたクライアントＰＣは、一つのリカバリ媒体にてリカバリを実行することができる。

また、第２実施形態の端末固有リカバリ方式システムでは、クライアントＰＣ８０２のリカバリ情報ファイル８２４を共有フォルダ１０３に保存し、そのリカバリ情報ファイル８２４を用いてリカバリ媒体が作成される。この構成によれば、クライアントＰＣ毎にそのクライアントＰＣ専用のリカバリ媒体を作成して、リカバリ認証を実行することができる。さらに、本方式ではリカバリ媒体内にリカバリデータを内包しているため、クライアントＰＣ内のリカバリデータが破壊されている場合でも、それとは関係なしにリカバリを実行できる。

＜変形例＞
本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、共有リカバリ方式システムと端末固有リカバリ方式システムの両方を採用して、リカバリシステムを構成することが可能である。この場合、共有リカバリ方式システムでリカバリが失敗した場合（例えば、リカバリデータが破損しているなど）、端末固有リカバリ方式システムを実行して、クライアントＰＣをリカバリするという運用が可能である。これにより、よりセキュアで、且つ障害発生時に柔軟に対応可能なリカバリシステムを運用することが可能となる。

上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、各実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
例えば、リカバリ媒体には、少なくとも認証データが含まれていればよく、リカバリユーザのＩＤ及びパスワードを含まない構成も可能である。この場合、リカバリ媒体によってクライアントＰＣをリカバリする際、認証データによる認証処理が実行された後に、リカバリが実行される。

また、本分野にスキルのある者には、本発明を実施するのに相応しいハードウェア、ソフトウェア、およびファームウエアの多数の組み合わせがあることが解るであろう。例えば、本実施形態に記載の機能を実現するプログラムコードは、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａ（登録商標）等の広範囲のプログラムまたはスクリプト言語で実装できる。

１０１、８０１ ：管理サーバ
１０２、８０２ ：クライアントＰＣ
１０３、８０３ ：共有フォルダ
２０１ ：中央演算処理装置
２０２ ：メモリ
２０３ ：ハードディスク
２０４ ：記録媒体用装置
２０５ ：入力装置
２０６ ：出力装置
３０１ ：媒体作成部
３０２ ：リカバリユーザ管理部
３０３ ：認証データ管理部
３０４ ：データベース
３０５ ：認証データ登録部
３０６ ：認証データ送信部
３０７ ：認証データ更新部
３０８ ：エージェント
８３１ ：識別情報生成部
８３２ ：リカバリ情報ファイル送信部
８３３ ：リカバリ情報ファイル取得部

Claims (8)

1. 管理サーバと、クライアント端末とを備え、前記管理サーバにおいて作成したリカバリ媒体によって前記クライアント端末をリカバリするリカバリシステムであって、
   前記クライアント端末をリカバリする際の認証データを前記クライアント端末外の記憶装置に保存する第１の保存手段と、
   前記認証データを前記クライアント端末に保存する第２の保存手段と、
   前記クライアント端末外の記憶装置に保存された前記認証データを含むリカバリ媒体を作成する媒体作成手段と、
   前記クライアント端末において前記リカバリ媒体を使用する際に、前記リカバリ媒体に含まれた前記認証データと、前記クライアント端末に保存されている前記認証データとに基づいてリカバリの認証を行う認証手段と、
   前記クライアント端末のリカバリに使用される所定のリカバリデータを用いて前記クライアント端末をリカバリするリカバリ手段と、
   を備えることを特徴とするリカバリシステム。
2. 請求項１に記載のリカバリシステムにおいて、
   前記認証データは、前記クライアント端末に所定のシステムをインストールする際に使用されたインストール媒体を識別する媒体識別情報と、前記リカバリ媒体の有効性を示すリカバリ識別情報と、を含み、
   前記媒体識別情報及び前記リカバリデータは、前記インストール媒体によって前記所定のシステムを前記クライアント端末にインストールする際に前記クライアント端末に格納され、
   前記管理サーバが、前記第１の保存手段として、前記認証データを格納するデータベースと、前記管理サーバから前記クライアント端末外の記憶装置に前記認証データを送信する認証データ送信部を備え、
   前記クライアント端末が、前記第２の保存手段として、前記クライアント端末外の記憶装置から前記認証データを取得して、前記クライアント端末に前記認証データを保存する認証データ更新部を備え、
   前記認証手段は、前記リカバリ媒体に含まれた前記媒体識別情報と、前記クライアント端末に保存されている前記媒体識別情報とが一致し、且つ、前記クライアント端末に保存されている前記リカバリ識別情報が有効であることを示す場合に、前記リカバリ媒体によるリカバリが正当であると判定し、
   前記リカバリ手段は、前記認証手段によってリカバリが正当であると判定された場合、前記クライアント端末に格納された前記リカバリデータを用いてリカバリを実行することを特徴とするリカバリシステム。
3. 請求項２に記載のリカバリシステムにおいて、
   前記認証データ更新部が、前記クライアント端末の起動時、及び、所定の間隔の少なくとも一方のタイミングで、前記クライアント端末外の記憶装置から前記認証データを取得して、前記クライアント端末の前記認証データを更新することを特徴とするリカバリシステム。
4. 請求項２又は３に記載のリカバリシステムにおいて、
   前記管理サーバは、前記認証データを前記データベースに登録するための認証データ登録部とを更に備え、
   前記認証データ送信部は、前記認証データ登録部によって前記データベースに対して前記認証データの登録処理、変更処理、削除処理のいずれかが行われた場合に、前記管理サーバから前記クライアント端末外の記憶装置に前記認証データを送信することを特徴とするリカバリシステム。
5. 請求項２乃至４のいずれか一項に記載のリカバリシステムにおいて、
   前記管理サーバは、前記クライアント端末においてリカバリを実行するユーザの認証情報を前記データベースに登録するリカバリユーザ管理部を更に備え、
   前記媒体作成手段は、前記データベースに前記ユーザの認証情報がないユーザが前記リカバリ媒体の作成を実行しようとした場合、前記リカバリ媒体の作成を実行しないことを特徴とするリカバリシステム。
6. 請求項１乃至５のいずれか一項に記載のリカバリシステムにおいて、
   前記認証データは、前記クライアント端末に所定のシステムをインストールする際に使用されたインストール媒体を識別する媒体識別情報と、前記クライアント端末を識別する端末識別情報と、を含み、
   前記媒体識別情報及び前記リカバリデータは、前記インストール媒体によって前記所定のシステムを前記クライアント端末にインストールする際に前記クライアント端末に格納され、
   前記クライアント端末が、前記第２の保存手段として、前記インストール媒体によってインストールされる際に前記端末識別情報を生成して保存する識別情報生成部を備え、
   前記クライアント端末が、前記第１の保存手段として、前記認証データを前記リカバリデータとともに、前記クライアント端末から前記クライアント端末外の記憶装置に送信するリカバリ情報ファイル送信部を備え、
   前記媒体作成手段が、前記クライアント端末外の記憶装置に保存されている前記認証データ及び前記リカバリデータを含む前記リカバリ媒体を作成し、
   前記認証手段は、前記リカバリ媒体に含まれた前記媒体識別情報と、前記クライアント端末に保存されている前記媒体識別情報とが一致し、且つ、前記リカバリ媒体に含まれた前記端末識別情報と、前記クライアント端末に保存されている前記端末識別情報とが一致する場合に、前記リカバリ媒体によるリカバリが正当であると判定し、
   前記リカバリ手段は、前記認証手段によってリカバリが正当であると判定された場合、前記リカバリ媒体に含まれた前記リカバリデータを用いてリカバリを実行することを特徴とするリカバリシステム。
7. 請求項１乃至６のいずれか一項に記載のリカバリシステムにおいて、
   前記リカバリ媒体は、前記クライアント端末においてリカバリを実行するユーザの認証情報を更に含み、
   前記認証手段は、前記ユーザの認証情報による認証が更に成功した場合に、前記リカバリ媒体によるリカバリが正当であると判定することを特徴とするリカバリシステム。
8. 管理サーバと、クライアント端末とを備える情報システムにおいて、前記管理サーバにおいて作成したリカバリ媒体によって前記クライアント端末をリカバリするリカバリ方法であって、
   前記クライアント端末をリカバリする際の認証データを前記クライアント端末外の記憶装置に保存する第１の保存ステップと、
   前記認証データを前記クライアント端末に保存する第２の保存ステップと、
   前記クライアント端末外の記憶装置に保存された前記認証データを含むリカバリ媒体を作成する媒体作成ステップと、
   前記クライアント端末において前記リカバリ媒体を使用する際に、前記リカバリ媒体に含まれた前記認証データと、前記クライアント端末に保存されている前記認証データとに基づいてリカバリの認証を行う認証ステップと、
   前記クライアント端末のリカバリに使用される所定のリカバリデータを用いて前記クライアント端末をリカバリするリカバリステップと、
   を備えることを特徴とするリカバリ方法。

Images