説明

情報処理装置、復旧装置、ディスク復旧方法

【課題】アプライアンスサーバ10のディスクを復旧させる場合に、遠隔的に、かつ、より安全に行うことができるようにすること。
【解決手段】認証クライアント30は、予めネットワークを介して第1認証鍵を取得する。アプライアンスサーバ10は、認証クライアント30から第1認証鍵に基づく認証の要求を受けると、上記第1認証鍵と、自装置内で保持する第2認証鍵とが一致するか否かに基づいて認証処理を行う。アプライアンスサーバ10は、上記認証が成功した場合にはリカバリディスク内のイメージファイルを自装置内のディスクへ書き込み、書き込みが正常に完了すると完了メッセージを認証クライアント30宛に通知する。認証クライアント30は、完了メッセージを受けると上記第1認証鍵を削除する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理装置において、例えばハードディスクを交換した場合のディスク内のデータ復旧(ディスク復旧)技術に関する。
【背景技術】
【0002】
ハードディスクなどのストレージを備えた情報処理装置においては、例えばハードディスクが故障したときには、リカバリディスクを用いてイメージファイルを交換後のハードディスクへ展開して、ハードディスクの復旧が行われる。リカバリディスクは、例えば、光ディスクなどの可搬型媒体である。このとき、情報処理装置に表示装置や入力装置が接続されている場合、上記データ復旧作業が比較的容易に行われ、それが安全に行われる。一方、情報処理装置に表示装置や入力装置が接続されていない場合には、リカバリディスクを情報処理装置に挿入したときに、ユーザは、そのリカバリディスクがその情報処理装置向けのものかどうかについての情報を、表示装置を通して視認できない。そのため、適切でないイメージファイルがハードディスクへ書き込まれてしまう可能性がある。つまり、情報処理装置に表示装置や入力装置が接続されている場合には、そうでない場合と比較してより安全にデータ復旧が行われる可能性が高い。
一方、ネットワークを介して遠隔的に情報処理装置のハードディスクのディスク復旧を行う方法も知られている。
【0003】
例えば、クライアント/サーバシステムにおけるクライアント側のハードディスク交換後にクライアントの環境を復旧するための方法として、以下の方法が知られている。すなわち、この先行技術によれば、クライアントは先ず、交換後のハードディスクのシリアルナンバーをサーバに送信する。サーバは、取得したシリアルナンバーを予め格納されている交換前のハードディスクのシリアルナンバーと比較することで、クライアントにおけるハードディスクの交換有無を判定する。ハードディスクの交換有と判定するとサーバは、選択したバックアップ内容をクライアントに転送する。その後、クライアントはハードディスクからの起動を行ってクライアントの環境を復旧する。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2002−222106号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、上述した従来の情報処理装置のディスク復旧方法では、クライアント(情報処理装置)の管理者の判断次第で同一のバックアップ内容(イメージファイルに相当)が何度でも書き込み可能である(つまり、不正コピーが可能になっている)という点で好ましくない。特に、情報処理装置がセキュリティアプライアンス等、表示装置や入力装置が接続されておらず、かつ、高度の信頼性を要する装置である場合には、遠隔的かつ安全にハードディスクの復旧作業が行われることが求められる。
【0006】
よって、本発明の1つの側面では、情報処理装置のディスクを復旧させる場合に、遠隔的に、かつ、より安全に行うことができるようにした情報処理装置、復旧装置、ディスク復旧方法を提供することを目的とする。
【課題を解決するための手段】
【0007】
第1の観点は、データを記憶するディスクを備え、復旧装置による遠隔的なディスク復旧の対象となる情報処理装置である。
この情報処理装置は、
復旧装置との間でネットワークを介して送受信を行う送受信部と、
前記復旧装置から第1認証鍵に基づく認証の要求を受けた場合に、当該第1認証鍵と、自装置内で保持する第2認証鍵とが一致するか否かに基づいて認証処理を行う認証処理部と、
前記認証処理部による認証が成功した場合にはイメージファイルを前記ディスクへ書き込み、書き込みが正常に完了すると前記送受信部を介して所定の完了メッセージを前記復旧装置宛に通知する書き込み制御部と、
を備える。
【0008】
第2の観点は、遠隔的に情報処理装置のディスク復旧を行う復旧装置である。
この復旧装置は、
前記情報処理装置および鍵供給装置との間でネットワークを介して送受信を行う送受信部と、
前記鍵供給装置から前記送受信部を介して第1認証鍵を取得する認証鍵取得部と、
前記送受信部を介して、前記情報処理装置に前記第1認証鍵に基づく認証の要求を行い、当該認証が成功したか否かの通知を前記情報処理装置から受け、前記情報処理装置におけるディスクへのイメージファイルの書き込み完了を示す完了メッセージを受けた場合に前記第1認証鍵を削除する認証処理部と、
を備える。
【0009】
第3の観点は、情報処理装置のディスク復旧を復旧装置によって行うディスク復旧方法である。
このディスク復旧方法において、
前記復旧装置は、ネットワークを介して鍵供給装置から第1認証鍵を取得し、
前記情報処理装置は、ネットワークを介して前記復旧装置から前記第1認証鍵に基づく認証の要求を受けると、該第1認証鍵と、自装置内で保持する第2認証鍵とが一致するか否かに基づいて認証処理を行い、
前記情報処理装置は、前記認証が成功した場合にはイメージファイルを自装置内のディスクへ書き込み、書き込みが正常に完了すると完了メッセージを前記復旧装置宛に通知し、
前記復旧装置は、前記完了メッセージを受けると前記第1認証鍵を削除する。
【発明の効果】
【0010】
開示の情報処理装置、復旧装置、ディスク復旧方法によれば、情報処理装置のディスクを復旧させる場合に、遠隔的に、かつ、より安全に行うことができるようになる。
【図面の簡単な説明】
【0011】
【図1】実施形態におけるシステム構成を示す図。
【図2】実施形態のアプライアンスサーバの構成を示すブロック図。
【図3】実施形態の認証クライアントの構成を示すブロック図。
【図4】実施形態のディスク復旧の準備の概要を説明するための図。
【図5】実施形態の認証クライアントにおける表示例を示す図。
【図6】実施形態のアプライアンスサーバの復旧処理を示すフローチャート。
【図7】実施形態の認証クライアントにおける表示例を示す図。
【発明を実施するための形態】
【0012】
(1)システム構成
先ず、実施形態のシステムについて図1を参照して説明する。図1は、実施形態におけるシステム構成を示す図である。このシステムは、アプライアンスサーバ10と、制御装置20と、認証クライアント30、ネットワーク中継器40とを含む。
アプライアンスサーバ10は、ネットワーク上に配置されて特定の用途のための処理を行う装置である。アプライアンスサーバ10は、特に限定するものではないが、例えば、ウェブサーバ、キャッシュサーバ、電子メールサーバ、ファイアウォールサーバ、ロードバランサなどである。制御装置20は、ネットワーク中継器40を介してアプライアンスサーバ10と通信可能である。アプライアンスサーバ10の管理者等は、制御装置20を使用してネットワーク経由でアプライアンスサーバ10にアクセスし、アプライアンスサーバ10の環境設定、状態監視を行うとともにアプライアンスサーバ10からログを取得できるようになっている。
【0013】
本実施形態において、アプライアンスサーバ10は、認証クライアント30によって遠隔的にハードディスクのデータ復旧を行う対象となる。アプライアンスサーバ10は、情報処理装置の一例である。認証クライアント30は、復旧装置の一例である。
アプライアンスサーバ10は、表示装置や入力装置が接続されていない状態でネットワーク上で運用がなされ、かつ、高度の信頼性を要する用途に使用されうる。そこで、本実施形態のシステムは、アプライアンスサーバ10内のHDD(Hard Disk Drive)が故障してディスク交換の必要が生じたときに、認証クライアント30がネットワークを介して遠隔的、かつ安全にハードディスクのデータ復旧(以下、適宜「ディスク復旧」と表記する。)を行うために構成されている。
【0014】
(2)アプライアンスサーバ10の構成
図2は、実施形態のアプライアンスサーバ10構成を示すブロック図である。
図2に示すように、アプライアンスサーバ10は、CPU(Central Processing Unit)11、チップセット12、RAM(Random Access Memory)13、BIOS−ROM14、電源供給部15、HDD16、入出力デバイス17、および、通信インタフェース18を含む。チップセット12は、アプライアンスサーバ10内の各部とデータバスおよび制御バスによって接続されている。
なお、HDD16はディスクの一例である。CPU11は、認証処理部および書き込み制御部の一例である。通信インタフェース18は、送受信部の一例である。
【0015】
CPU11は、アプライアンスサーバ10の用途に応じて設けられる各種のプログラムを実行する。また、ディスク復旧時にCPU11は、入出力デバイス17に含まれる光ディスクドライブにセットされたリカバリディスク(後述する)からプログラムあるいはファイルを読み出し、そのプログラムの実行あるいはデータ処理を行う。
RAM13は、CPU11のメインメモリである。RAM13は、CPU11が実行するプログラムやCPU11が参照するデータを一時的に格納するための揮発性記憶装置である。リカバリディスク内のイメージファイルは、ディスク復旧処理時にRAM13に展開される。
チップセット12は、CPU11と他の各部とのインタフェースのための制御回路、各部を制御するためのレジスタを含む。チップセット12は、例えば汎用インタフェースであるGPI(General Purpose Interface)に対応してよい。
BIOS−ROM14は、BIOS(Basic Input/Output System)を記憶する。BIOSは、ハードウエアとの基本的な入出力処理を行うための基本入出力システム(プログラム)である。
電源供給部15は、アプライアンスサーバ10の各部への電源を供給する。電源供給部15は、アプライアンスサーバ10の状態(例えばスリープモード等)に応じて給電を制限することがあってよい。
HDD16(以下、適宜「ハードディスク」という。)は不揮発性記憶装置であり、オペレーティングシステム(OS)やOS上で実行されるプログラムを記憶する。
【0016】
(3)認証クライアント30の構成
図3は、実施形態の認証クライアント30構成を示すブロック図である。
図3に示すように、認証クライアント30は、CPU(Central Processing Unit)31、チップセット32、RAM(Random Access Memory)33、BIOS−ROM34、電源供給部35、HDD(Hard Disk Drive)36、入出力デバイス37、通信インタフェース38、および、表示装置39を含む。チップセット32は、認証クライアント30内の各部とデータバスおよび制御バスによって接続されている。例えば、認証クライアント30は、汎用のパーソナルコンピュータであってよい。
なお、CPU31は、認証鍵取得部および認証処理部の一例である。通信インタフェース38は、送受信部の一例である。
【0017】
CPU31は、アプライアンスサーバ10のディスク復旧の準備、および、ディスク復旧に当たって、認証プログラムを実行する。この認証プログラムを実行してアプライアンスサーバ10のディスク復旧を行うために、CPU31は、後述するリカバリ認証キーを通信インタフェース38経由で取得する。CPU31は、後述するリカバリライセンス販売者のウェブサービスを受けるために、ウェブサーバから送信されるHTML(HyperText Markup Language)データを解釈して表示装置39に表示させるためのウェブブラウザを実行する。
RAM33は、CPU31のメインメモリである。RAM13は、CPU31が実行するプログラムやCPU31が参照するデータを一時的に格納するための揮発性記憶装置である。
チップセット32は、CPU31と他の各部とのインタフェースのための制御回路、各部を制御するためのレジスタを含む。チップセット32は、例えば汎用インタフェースであるGPIに対応してよい。
BIOS−ROM34は、BIOS(Basic Input/Output System)を記憶する。BIOSは、ハードウエアとの基本的な入出力処理を行うための基本入出力システム(プログラム)である。
電源供給部35は、認証クライアント30の各部への電源を供給する。電源供給部35は、認証クライアント30の状態(例えばスリープモード等)に応じて給電を制限することがあってよい。
HDD36は不揮発性記憶装置であり、オペレーティングシステム(OS)やOS上で実行されるプログラムを記憶する。
【0018】
通信インタフェース38は、インターネットあるいはLAN(Local Area Network)を介して、アプライアンスサーバ10および後述するリカバリ許可サーバと通信を行うためのインタフェース回路を含む。通信インタフェース38は、各サーバと通信可能であればよく、その通信プロトコルは問わない。
表示装置39は、例えば、マトリクス状に画素単位で配置された薄膜トランジスタを含むLCD(Liquid Cristal Display)モニタと、その薄膜トランジスタを駆動するための駆動回路とを含み、CPU31から与えられる画像データをモニタ上に表示する。
【0019】
(4)本実施形態のディスク復旧方法
次に、本実施形態のディスク復旧方法について、図4〜図7を参照して説明する。
【0020】
(4−1)復旧環境の準備
本実施形態のディスク復旧方法において、先ず、認証クライアント30による復旧環境の準備が行われる。この復旧環境の準備は、認証クライアント30が、アプライアンスサーバ10のハードディスクのデータ復旧を行うのに必要となるリカバリ認証キーを予め取得することを含む。なお、このリカバリ認証キーは、第1認証鍵の一例である。
図4は、本実施形態のディスク復旧方法において復旧環境の準備を説明するための図である。図4は、認証クライアント30が予め、外部のリカバリライセンスの販売者からリカバリ認証キーを取得する(つまり、リカバリライセンスを購入する)場合の手順を示す。なお、リカバリ認証キーは、アプライアンスサーバ10のディスク復旧を行うときに、ディスク復旧の対象となるアプライアンスサーバ10以外の装置に誤って使用されてしまうことを防止するために、ディスク復旧の対象となるアプライアンスサーバ10に固有の鍵情報となっている。そのような固有の鍵情報は例えば、ディスク復旧の対象となるアプライアンスサーバ10の固有のハードウエア情報を基に生成される。
なお、図4において、リカバリ許可サーバは、鍵供給装置の一例である。
【0021】
図4(a)において先ず、認証クライアント30を操作する管理者(リカバリライセンスの購入者)は、リカバリライセンスの販売者が運営するウェブサイト(WEBサイト)にアクセスし、所定の手続を行ってリカバリライセンス情報を購入する(ステップS1)。つまり、認証クライアント30は、リカバリライセンス情報を受信して取得する。このリカバリライセンス情報には、リカバリライセンスの販売者が運用するリカバリ許可サーバのネットワークアドレス、アクセスアカウント、ワンタイムパスワードが含まれている。
次に認証クライアント30は、リカバリライセンス情報に含まれている上記情報を元に、リカバリ許可サーバに対して認証要求を行う(ステップS2)。リカバリ許可サーバは、認証クライアント30から送信されたアクセスアカウント、ワンタイムパスワードを、自サーバで保持する情報と照合することにより認証処理を行う。その結果、認証が成功すると、リカバリ許可サーバは、認証クライアント30に対して、認証成功通知メッセージと、リカバリ認証キーとを送信する(ステップS3)。
【0022】
なお、上記ステップS2およびS3の手続きは逐次、例えば図5に表示例を示すように、認証クライアント30の表示装置39で表示されるようにすることが好ましい。この場合、CPU31は、リカバリ許可サーバとの間でなされる通信のログを一時的に格納しておき、逐次表示装置39に表示させる。これにより、認証クライアント30の管理者が認証手続の進捗状況を視覚的に確認できる。
【0023】
最後に認証クライアント30は、取得したリカバリ認証キーを認証プログラムに設定する(ステップS4)。このステップS4が完了した時点で、図4(b)に示すように、認証クライアント30は、ネットワーク中継器40を介してネットワークに接続することで(ステップS5)、アプライアンスサーバ10のディスク復旧を実行できる環境となる。
【0024】
(4−2)ディスク復旧の実行
本実施形態のディスク復旧方法では次に、アプライアンスサーバ10と認証クライアント30の間でディスク復旧を実行するが、このとき、アプライアンスサーバ10に対してリカバリディスクを使用する。リカバリディスクはCD(Compact Disc)あるいはDVD(Digital Versatile Disc)等、アプライアンスサーバ10に搭載される光ディスクドライブが読み取り可能な記録媒体であればその形態は問わない。このリカバリディスクには、以下に示す(a)〜(h)のプログラムおよびファイルが含まれる。
【0025】
(a)起動プログラム:
起動プログラムは、ブートローダやカーネルの起動、各種ドライバ、ライブラリの組み込み、ネットワークのインタフェース設定、光ディスクドライブのマウントなどを実行する。
(b)認証プログラム:
認証プログラムは、認証クライアント30からの認証要求を処理し、ディスク復旧の開始を行うプログラムである。このプログラムは、ディスク復旧の開始/終了の成功/失敗の認証結果を認証クライアント30へ返し、失敗の場合、失敗時のコードも合わせて返す。
(c)イメージ復号プログラム:
イメージ復号プログラムは、暗号化された圧縮イメージファイルをRAM13(メモリ)へ展開させるためのプログラムである。
(d)イメージ展開プログラム:
イメージ展開プログラムは、RAM13(メモリ)に展開された圧縮イメージファイルをアプライアンスサーバ10のハードディスクへ展開させるためのプログラムである。
(e)イメージ整合性チェックファイル:
イメージ整合性チェックファイルには、チェックサム値が含まれている。
(f)イメージ整合性チェックプログラム
イメージ整合性チェックプログラムは、アプライアンスサーバ10のハードディスクへのイメージファイルの展開が正常に実行できたかをチェックするためのプログラムである。
(g)終了プログラム:
終了プログラムは、認証プログラムにリカバリ完了メッセージを送信させ、認証プログラムを終了させ、アプライアンスサーバ10のシャットダウンを実行するプログラムである。
(h)イメージファイル:
イメージファイルは、ディスクイメージファイルが例えばlzopやgzipなどの所定の方式で圧縮され、かつ3DES(Triple DES(Data Encryption Standard))あるいはAES(Advanced Encryption Standard)などの共通鍵暗号方式で暗号化されたファイルである。
【0026】
以下、図6を参照してアプライアンスサーバ10のディスク復旧の実行処理について説明する。図6は、アプライアンスサーバ10のディスク復旧の実行処理において、アプライアンスサーバ10と認証クライアント30で行われる処理を示すフロー図である。なお、以下の処理において、認証クライアント30で行われる処理は、認証クライアント30のCPU31が認証プログラムを実行することで行われる処理である。
【0027】
先ず、アプライアンスサーバ10に対してリカバリディスクを挿入することにより(ステップS10のYES)、アプライアンスサーバ10のディスク復旧が開始される。なお、この時点では、認証クライアント30において認証プログラムが起動した状態としておく(ステップS20)。リカバリディスクが挿入されると、アプライアンスサーバ10のCPU11は、リカバリディスクに含まれる起動プログラムを読み出して実行する(ステップS30)。この起動プログラムが実行されると、CPU11は以下の処理を行う。
【0028】
[起動プログラムによるCPU11の処理]
・CPU11は、ブートローダやカーネルの起動、各種ドライバ、ライブラリの組み込み、ネットワークのインタフェース設定、光ディスクドライブのマウントなどを実行する。
・CPU11は、アプライアンスサーバ10のハードウエア固有の情報(ベンダー情報、BIOS版数、CPUタイプ、メモリ容量、ディスクサイズなど)を取得し、自サーバがリカバリ対象のサーバであるか確認する。起動プログラムには上記ハードウエア固有の情報が含まれており、CPU11は、このプログラム上のデータと、自サーバから読み出したデータとが一致するか否かをチェックする。そしてCPU11は、そのチェック結果に基づく確認結果コードを確認結果ファイルへ書き込む。
・CPU11は、USB(Universal Serial Bus)などの外部インタフェースが使用不可であるか否か確認する。通常BIOSの設定で外部インタフェースが使用不可となっているが、仮に使用可の状態であるとするとセキュリティ上好ましくないためである。そしてCPU11は、その確認結果に基づく確認結果コードを確認結果ファイルへ書き込む。
・CPU11は、ハードディスクのマスタブートレコードの内容をチェックし、既にディスク復旧がなされたか否かをチェックする。そしてCPU11は、そのチェック結果に基づく確認結果コードを確認結果ファイルへ書き込む。
・CPU11は、ネットワークインターフェースを起動し、DHCP(Dynamic Host Configuration Protocol)クライアント機能によってネットワークアドレスを取得する。DHCPクライアント機能でネットワークアドレスが取得できない場合には、CPU11は、リカバリディスク内に格納されている固定のネットワークアドレスを取得してもよい。
【0029】
次に、アプライアンスサーバ10のCPU11は、ディスク復旧処理にて利用する各種プログラム(認証プログラム、イメージ復号プログラム、イメージ展開プログラム、イメージ整合性チェックプログラムおよび終了プログラム)をリカバリディスクから読み出してRAM13にロードし、それらを起動し(ステップS40)、認証待ちの状態(つまり、認証クライアント30からの認証要求を待機する状態)となる。このとき、認証待ちの状態になったことをLED(Light Emitting Device)による発光、あるいはビープ音の生成などにより、視覚的あるいは聴覚的に、周囲(例えば、ディスク復旧の作業者あるいはサーバ等の管理者)に報知するように設定しておくことが好ましい。
この後、認証クライアント30は、認証プログラムの実行に伴ってアプライアンスサーバ10に対して認証要求を行う(ステップS50)。認証クライアント30は、この認証要求を、リカバリ許可サーバから予め取得したリカバリ認証キーを含むようにして行う。この認証要求が行われた後のアプライアンスサーバ10のCPU11における処理は以下のとおりである。
【0030】
[認証プログラムによるCPU11の処理]
・CPU11は、アプライアンスサーバ10のハードウエア固有の情報を元に認証キーを生成する。なお、この生成される認証キーは、第2認証鍵の一例である。認証要求において認証クライアント30から受信するリカバリ認証キーは、ハードウエア固有の情報を元に作成されたものであるが、本処理における認証キーの作成手順(ハードウエア固有の情報を元にキーを作成するときの演算式など)はそれと同一とする。すると、受信したリカバリ認証キーと、CPU11が生成した認証キーとは一致するはずであるから、この一致/不一致に基づいて認証処理を行うことができる。CPU11は、その認証結果に応じたコードを確認結果ファイルへ書き込む。
・CPU11は、これまで書き込まれた確認結果ファイルの内容をチェックして、チェック結果がNG(エラー)となるコードが書き込まれていれば、その確認結果ファイルを認証クライアント30へ送信してディスク復旧の処理を中断する。チェック結果がNG(エラー)の場合とは、以下の(E1)〜(E3)のいずれかの場合である。
【0031】
(E1)認証キーが一致しない場合(ハードウエア固有の情報に基づく認証キーが一致しないことから、アプライアンスサーバ10が適切なリカバリ対象でないと考えられる。)
(E2)USB等の外部インタフェースが使用可能状態である場合(セキュリティ上問題であるため、ディスク復旧を続行させない。)
(E3)認証クライアント30から受信したリカバリ認証キーが適切なデータでない場合
【0032】
アプライアンスサーバ10のCPU11は、認証が成功すると、その認証成功とリカバリ開始の通知を認証クライアント30に対して行う(ステップS60)。なお、認証クライアント30のCPU31は、アプライアンスサーバ10から受信した確認結果コードをチェックして、既にディスク復旧がなされたことが判明した場合には、その旨を表示装置39に表示し、ディスク復旧を継続するか否かの意思確認を管理者に促すように設定してもよい。処理を続行することを示す操作入力があった場合には、認証クライアント30は、アプライアンスサーバ10へディスク復旧の処理を継続する処理継続要求を行ってもよい。そしてアプライアンスサーバ10は、処理継続要求を受けた場合には、中断していた処理を続行する。
【0033】
次に、アプライアンスサーバ10のCPU11は、イメージ復号プログラムにより以下の処理を実行する(ステップS70)。
【0034】
[イメージ復号プログラムによるCPU11の処理]
・CPU11は、リカバリディスク内にある暗号化されたイメージファイルをRAM13(メモリ)に展開(すなわち、復号化)する(ステップS80)。この時の復号キーは、アプライアンスサーバ10のハードウエア固有の情報を元に算出するハッシュ値、あるいはアプライアンスサーバ10のハードウエア固有の情報を元に既に算出し保持している認証キー(リカバリ認証キーと同じキー)とする。また、イメージファイルの暗号化方式は問わないが、例えば3DESあるいはAESなどの共通鍵暗号方式で暗号化されている。したがって、リカバリディスク内にあるイメージファイルは、リカバリ対象となる固有のアプライアンスサーバのみが復号でき、他の装置は復号できないようになっている。
・CPU11は、リカバリディスク内にある暗号化されたイメージ整合性チェックファイルを、上記復号キーにより復号化し、イメージ整合性チェックファイル内に格納されたイメージファイルのチェックサム値を抽出する(ステップS90)。
【0035】
次に、アプライアンスサーバ10のCPU11は、イメージ展開プログラムにより、RAM13(メモリ)にある圧縮イメージファイルをハードディスクに展開(すなわち、伸長)する(ステップS100)。その後、CPU11は、イメージ整合性チェックプログラムを実行してハードディスクへのイメージファイルの展開が正常に実行できたかをチェックする。このチェックは、ハードディスクのチェックサム値を算出し、このチェックサム値と、ステップS90で得られたイメージ整合性チェックファイル内のチェックサム値とが一致するか否かに基づいて行われる、ハードディスク内のデータの検証処理である(ステップS110)。この検証処理は、イメージファイルに改竄がないか、あるいは、ハードディスクへの展開動作が正常であったかをチェックする目的で行われる。
【0036】
次に、アプライアンスサーバ10のCPU11は、終了プログラムを実行する(ステップS120)。ハードディスクのデータの検証処理の結果、ハードディスク内のデータが問題ないと判定した場合には、この終了プログラムの実行により、アプライアンスサーバ10からリカバリ完了メッセージが認証クライアント30へ送信されるとともに(ステップS130)、アプライアンスサーバ10がシャットダウンされる。
認証クライアント30において、リカバリ完了メッセージを受信すると、CPU31がリカバリ認証キーを削除する(ステップS140)。このリカバリ認証キーの削除によって、認証クライアント30の管理者によって何度もディスク復旧を行うといった、ライセンスに反した不正コピーが防止される。
【0037】
なお、図6に示した手続きは逐次、例えば図7に例示するように、認証クライアント30の表示装置39で表示されるようにすることが好ましい。この場合、CPU31は、アプライアンスサーバ10との間でなされる通信のログを一時的に格納しておき、逐次表示装置39に表示させる。これにより、認証クライアント30の管理者がディスク復旧手続の進捗状況を視覚的に確認できる。
【0038】
以上説明したように、本実施形態のディスク復旧方法によれば、認証クライアント30は、ネットワークを介してリカバリライセンスの販売者が運用するリカバリ許可サーバからリカバリ認証キーを取得する。アプライアンスサーバ10は、認証クライアント30からリカバリ認証キーに基づく認証の要求を受けると、リカバリ認証キーと、自装置内で保持あるいは生成する認証キーとが一致するか否かに基づいて認証処理を行い、認証が成功した場合にはイメージファイルを自装置内のディスクへ書き込む。認証クライアント30は、書き込みが正常に完了したことを示す完了メッセージを受けるとリカバリ認証キーを削除する。このとき、リカバリ認証キーと、アプライアンスサーバ10で保持あるいは生成される認証キーとは共に、アプライアンスサーバ10のハードウエア固有の情報に基づいた認証キーであり、この認証キーに基づいて認証処理を行うため、リカバリ対象でない別のサーバに誤ってイメージファイルを書き込むことが防止される。また、アプライアンスサーバ10が取得したリカバリ認証キーは、ディスク復旧処理が完了すると削除されるため、このリカバリ認証キーを別のサーバに使用するイメージファイルの不正コピーが防止される。そのため、本実施形態のディスク復旧方法によって、アプライアンスサーバ10に対する遠隔的なディスク復旧が安全に行われる。
【0039】
このディスク復旧方法によれば、認証クライアント30による認証要求を契機としてイメージファイルのアプライアンスサーバ10へのハードディスクへの書き込みが行われ、その書き込み完了を示す完了メッセージが認証クライアント30へ通知される。そのため、アプライアンスサーバ10に表示装置や入力装置が接続されていない場合であっても、遠隔的に書き込みの実行がされたか否か確認できる。
【0040】
また、リカバリディスクに格納されるイメージファイルは、アプライアンスサーバ10のハードウエア固有の情報を元に作成される暗号キーで予め暗号化しておき、メモリへ展開するときに、共通鍵の復号キーで復号することが好ましい。これにより、ハードウエア固有の情報が正しくなければイメージファイルはメモリに展開されないことになり、さらに安全性が向上する。
【0041】
以上、本発明の実施形態について詳細に説明したが、本発明の情報処理装置、復旧装置、ディスク復旧方法は上記実施形態に限定されず、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。例えば、図1に示したシステムにおいて、上記実施形態では、認証クライアント30がアプライアンスサーバ10のディスク復旧を行う場合について説明したが、通常時にアプライアンスサーバ10の運用を行っている制御装置20がアプライアンスサーバ10のディスク復旧を行ってもよい。
【0042】
以上の各実施形態に関し、さらに以下の付記を開示する。
【0043】
(付記1)
情報処理装置であって、
データを記憶するディスクと、
復旧装置との間でネットワークを介して送受信を行う送受信部と、
前記復旧装置から第1認証鍵に基づく認証の要求を受けた場合に、当該第1認証鍵と、自装置内で保持する第2認証鍵とが一致するか否かに基づいて認証処理を行う認証処理部と、
前記認証処理部による認証が成功した場合にはイメージファイルを前記ディスクへ書き込み、書き込みが正常に完了すると前記送受信部を介して所定の完了メッセージを前記復旧装置宛に通知する書き込み制御部と、
を備えた情報処理装置。
【0044】
(付記2)
前記書き込み制御部は、自装置のハードウエア固有の情報を元に復号鍵を生成し、暗号化された前記イメージファイルを前記復号鍵で復号した後に前記ディスクへ書き込むことを特徴とする、付記1に記載された情報処理装置。
【0045】
(付記3)
遠隔的に情報処理装置のディスク復旧を行う復旧装置であって、
前記情報処理装置および鍵供給装置との間でネットワークを介して送受信を行う送受信部と、
前記鍵供給装置から前記送受信部を介して第1認証鍵を取得する認証鍵取得部と、
前記送受信部を介して、前記情報処理装置に前記第1認証鍵に基づく認証の要求を行い、当該認証が成功したか否かの通知を前記情報処理装置から受け、前記情報処理装置におけるディスクへのイメージファイルの書き込み完了を示す完了メッセージを受けた場合に前記第1認証鍵を削除する認証処理部と、
を備えた復旧装置。
【0046】
(付記4)
情報処理装置のディスク復旧を復旧装置によって行うディスク復旧方法であって、
前記復旧装置は、ネットワークを介して鍵供給装置から第1認証鍵を取得し、
前記情報処理装置は、ネットワークを介して前記復旧装置から前記第1認証鍵に基づく認証の要求を受けると、該第1認証鍵と、自装置内で保持する第2認証鍵とが一致するか否かに基づいて認証処理を行い、
前記情報処理装置は、前記認証が成功した場合にはイメージファイルを自装置内のディスクへ書き込み、書き込みが正常に完了すると完了メッセージを前記復旧装置宛に通知し、
前記復旧装置は、前記完了メッセージを受けると前記第1認証鍵を削除する、
ことを含むディスク復旧方法。
【0047】
(付記5)
前記情報処理装置は、自装置のハードウエア固有の情報を元に復号鍵を生成し、暗号化された前記イメージファイルを前記復号鍵で復号した後に前記ディスクへ書き込むことを特徴とする、付記4に記載されたディスク復旧方法。
【符号の説明】
【0048】
10…アプライアンスサーバ
11…CPU
12…チップセット
13…RAM(メモリ)
14…BIOS−ROM
15…電源供給部
16…HDD(ハードディスク)
17…入出力デバイス
18…通信インタフェース
20…制御装置
30…認証クライアント
31…CPU
32…チップセット
33…RAM
34…BIOS−ROM
35…電源供給部
36…HDD
37…入出力デバイス
38…通信インタフェース
39…表示装置
40…ネットワーク中継器

【特許請求の範囲】
【請求項1】
情報処理装置であって、
復旧装置との間でネットワークを介して送受信を行う送受信部と、
前記復旧装置から第1認証鍵に基づく認証の要求を受けた場合に、当該第1認証鍵と、自装置内で保持する第2認証鍵とが一致するか否かに基づいて認証処理を行う認証処理部と、
前記認証処理部による認証が成功した場合にはイメージファイルを前記ディスクへ書き込み、書き込みが正常に完了すると前記送受信部を介して所定の完了メッセージを前記復旧装置宛に通知する書き込み制御部と、
を備えた情報処理装置。
【請求項2】
前記書き込み制御部は、自装置のハードウエア固有の情報を元に復号鍵を生成し、暗号化された前記イメージファイルを前記復号鍵で復号した後に前記ディスクへ書き込むことを特徴とする、請求項1に記載された情報処理装置。
【請求項3】
遠隔的に情報処理装置のディスク復旧を行う復旧装置であって、
前記情報処理装置および鍵供給装置との間でネットワークを介して送受信を行う送受信部と、
前記鍵供給装置から前記送受信部を介して第1認証鍵を取得する認証鍵取得部と、
前記送受信部を介して、前記情報処理装置に前記第1認証鍵に基づく認証の要求を行い、当該認証が成功したか否かの通知を前記情報処理装置から受け、前記情報処理装置におけるディスクへのイメージファイルの書き込み完了を示す完了メッセージを受けた場合に前記第1認証鍵を削除する認証処理部と、
を備えた復旧装置。
【請求項4】
情報処理装置のディスク復旧を復旧装置によって行うディスク復旧方法であって、
前記復旧装置は、ネットワークを介して鍵供給装置から第1認証鍵を取得し、
前記情報処理装置は、ネットワークを介して前記復旧装置から前記第1認証鍵に基づく認証の要求を受けると、該第1認証鍵と、自装置内で保持する第2認証鍵とが一致するか否かに基づいて認証処理を行い、
前記情報処理装置は、前記認証が成功した場合にはイメージファイルを自装置内のディスクへ書き込み、書き込みが正常に完了すると完了メッセージを前記復旧装置宛に通知し、
前記復旧装置は、前記完了メッセージを受けると前記第1認証鍵を削除する、
ことを含むディスク復旧方法。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate


【公開番号】特開2012−194788(P2012−194788A)
【公開日】平成24年10月11日(2012.10.11)
【国際特許分類】
【出願番号】特願2011−58294(P2011−58294)
【出願日】平成23年3月16日(2011.3.16)
【出願人】(000005223)富士通株式会社 (25,993)
【Fターム(参考)】