JP4736370B2 - ホスティング環境構築方法および計算機システム - Google Patents

Description

本発明は、データセンターや企業内の計算センターなどで、業務システムのホスティング環境を構築するプロビジョニング技術に属する。

近年、データセンターや企業内の計算センターなどへ業務システムを集中配置し、計算機リソースを有効活用しようとする動きがある。これまでの業務システムは、固定的に計算機リソースを割り付けて構築されることが多かったが、必要な計算機リソース量を必要な期間だけ割り付けて業務システムを構築することで、より少ない計算機リソースで複数の業務システムを効率よく稼働させようとするものである。前記を実現するためには、ある計算機リソース上に任意の業務システムを低コストで構築するための技術が必要となり、例えば、特開２００３−２１６５９３号公報（特許文献１）のように、多種多量のサーバ（業務システムや業務システムをホスティングする環境）を一括して導入する方法が考えられている。特許文献１によれば、ネットワークブート手段を具備する複数の計算機リソースは、起動時に、業務システム構築に必要なプログラムと設定情報（以降、ブートイメージと呼ぶ）を集中管理サーバ及びストレージサーバから取得する。これにより、複数の計算機リソースへの個々の設定作業を一括して行うことができる。

しかし、上記のような従来技術では、悪意を持って不正なブートイメージを送り込まれた場合に、不正な業務システムやホスティング環境が構築され、セキュリティの観点でデータセンターや企業内の計算センターを守る手段がないという問題がある。例えば、ブートイメージにハッキング用のプログラムが仕込まれていた場合は、企業の存亡に関わる甚大な被害が予想される。この問題を解決する方法としては、例えば、特開２００３−１２２５８８号公報（特許文献２）があり、ブートイメージ（特許文献２内の記述ではソフトウェア）に電子署名を付与しておき、ブート時（特許文献２内の記述では起動時）に電子署名を検証することで、不正なブートイメージでシステムを起動することを阻止できる。

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

しかし、特開２００３−１２２５８８号公報（特許文献２）の方法では、ブートイメージのサイズが大きい場合に、電子署名を検証する処理に時間がかかってしまうという問題がある。電子署名の付与、及び、検証の対象が、ソフトウェアのパッチやデバイスドライバなど、比較的ファイルのサイズが小さいものであれば、電子署名の検証処理時間は十分に無視できると考えられるが、多種多量のサーバ（業務システムや業務システムをホスティングする環境）を一括して導入するといった場面では、その際に用いられるブートイメージはOSやミドルウェアを含んだサイズの大きいものになることがあり、その場合、その電子署名の検証処理の時間は無視できないものとなる。

また、上記場面で、ブートイメージの単位で電子署名技術を使用すると、電子署名の検証処理を省略するか、省略しないかの二者択一の選択しかできず、電子署名の検証は省略したくないが、ブート時間を短縮させたいといったニーズに対応できないという問題がある。

本発明の目的は、計算機リソースに対してネットワークブートなどの技術を使ってブートイメージをロードさせて業務システムやそのホスティング環境を構築する方法において、安全かつ高速にホスティング環境を構築する方法を提供することにある。

本発明は、例えば非対称鍵（公開鍵と秘密鍵）方式のような電子署名及びその検証技術を用いる。まず、計算機リソースのＢＩＯＳ ＲＯＭに公開鍵を格納しておく。そして、この公開鍵に対応する秘密鍵を使ってブートイメージに電子署名を付与しておく。計算機リソースがブート処理を始める直前に、ブートイメージを読み込んで、前述の計算機リソース内の公開鍵を使って電子署名を検証する。検証処理が成功した場合はブート処理を行い、検証処理が失敗した場合はブート処理を行わないようにする。

ブートイメージのサイズが大きい場合には、ブートイメージをサイズの小さな断片に分割し、それぞれの断片に電子署名を付与しておき、ブート処理時にブートイメージの断片の読み込む際に、それぞれの断片に付与された電子署名を検証する。ブート処理の途中で電子署名の検証処理が失敗した断片が存在した場合にはブート処理を中断するようにする。しかし、すべての断片について電子署名の検証処理を行うと検証処理の合計時間が短縮できない場合があるため、断片に重要度情報を付与し、ブート指示時に与えられる重要度指示情報に従って、ある重要度以上の断片のみ電子署名の検証処理を行うようにする。

さらに、複数の計算機リソースに対して同じブートイメージをロードさせてブートさせる場合は、計算機リソース毎に電子署名の検証を行う断片を、例えば重要度情報に従って区別し、同時にブートさせる計算機リソース間で同時並行的に署名検証を行うようにする。

本発明のホスティング環境構築方法では、電子署名が付与されたブートイメージを計算機リソース側で検証しながらロードさせてブートさせる場合に、セキュリティを維持しつつ、より高速にホスティング環境を構築できるようになる。

以下に、本発明の実施の形態を説明する。

以下、本発明によるホスティング環境構築方法の実施例１について図１〜図８を参照して詳細に説明する。以下に説明する本発明の実施例１は、計算機リソースがブート処理を始める直前に、ブートイメージを読み込んで、計算機リソース内の公開鍵を使って電子署名を検証する方法において、ブートイメージのサイズが大きく、電子署名の検証に時間がかかるという問題を解決するために、ブートイメージをいくつかの断片に分割し、それぞれの断片に電子署名を付与しておき、ブート処理の際には断片ごとに署名検証処理を行って、検証が失敗する断片が見つかった時点でブート処理を中断する方法の例である。なお、非対称鍵のペア（公開鍵と秘密鍵のペア）はあらかじめ用意されており、また、公開鍵は計算機リソースのＢＩＯＳロム内に、秘密鍵は集中管理サーバに、それぞれ格納されているものとする。

図１は、本発明におけるホスティング環境構築方法を実現する集中管理サーバの構成と機能ブロック、及び、前記集中管理サーバによって制御される計算機リソースの構成と機能ブロック、及び、ブートイメージを格納・管理するブートイメージ管理ストレージの構成と機能ブロックの一例である。

図１において、１０１は集中管理サーバであり、ＣＰＵ１０２、メインメモリ１０３、ＮＩＣ（ネットワークインタフェース）１０４、ＨＢＡ（ストレージ用ホストバスアダプタ）１０５、キーボードやモニタなどの入出力装置１０６、ＨＤＤ（ハードディスク）１０７、を備えた計算機である。また、集中管理サーバ１０１のメインメモリ１０３には、ブートイメージに対する電子署名を生成するための署名手段１０８と、ブートイメージと計算機リソースを指定して、ホスティング環境の構築を指示するブート指示手段１０９が読み込まれており、入出力装置１０６によって、動作を指示できるようになっている。また、ＨＤＤ１０７には、公開鍵に対応する秘密鍵を格納した鍵管理テーブル１１０と、計算機リソースと公開鍵の対応関係を格納した鍵配置テーブル１１１と、ブートイメージの断片の格納場所と、そのブートイメージの断片に対してどの秘密鍵で電子署名したかという情報と、そのブートイメージの断片の署名検証処理の優先度情報を格納したブートイメージ管理テーブル１１２と、が保持されている。

また、１２１は、ブートイメージを管理するストレージであり、複数のＨＤＤをひとつのボリュームとして扱って入出力の制御を行うコントローラ１２１と、ストレージを構成するＨＤＤ１２３と、で構成される。また、ブートイメージ管理ストレージ１２１のＨＤＤ１２３には、ブートイメージ（の断片）１２４と、そのブートイメージの断片に対する電子署名１２５と、そのブートイメージの断片の署名検証処理の優先度情報１２６と、が組になって、複数格納されている。

また、１３１は、計算機リソースであり、ＣＰＵ１３２と、メインメモリ１３３と、ＮＩＣ１３４と、ＨＢＡ１２５とＢＩＯＳロム１３６を備える計算機である。ＢＩＯＳロム１３６には、システムＢＩＯＳ１３７と、ファームウェア１３８が格納されている。ファームウェアとしては、公開鍵１３９と、署名検証手段１４０と、各種ドライバ１４１（ＮＩＣドライバ、ＨＢＡドライバなど）が格納されている。また、ホスティング環境の構築処理が完了した後には、システムＢＩＯＳ１３７のブート処理によって読み込まれたブートデータ１４２がメインメモリ１３３に格納される。

また、１５１はＬＡＮ（ローカルエリアネットワーク）であり、集中管理サーバ１０１と計算機リソース１３１の間で情報のやり取りを行う際に使用する。集中管理サーバ１０１と計算機リソース１３１の間のアクセスはＮＩＣ１０４、ＮＩＣ１３４を経由して行われる。

また、１６１はＳＡＮ（ストレージエリアネットワーク）であり、集中管理サーバ１０１とブートイメージ管理ストレージ１２１の間、及び、計算機リソース１３１とブートイメージ管理ストレージ１２１の間の情報のやり取りを行う際に使用する。集中管理サーバ１０１とブートイメージ管理ストレージ１２１の間、及び、計算機リソース１３１とブートイメージ管理ストレージ１２１の間のアクセスは、ＨＢＡ１０５、ＨＢＡ１２５とコントローラ１２２を経由して行われる。

本実施例では、集中管理サーバ１０１のブート指示手段１０９からの指示により、計算機リソース１３１がブート処理を開始し、指定されたブートイメージを読み込んで起動することで、所望のホスティング環境が構築できるものとしている。

図２は、鍵管理テーブル１１０の一例である。このテーブルは、計算機リソース１３１のＢＩＯＳロム１３６に格納された公開鍵に対応した秘密鍵を格納するためのテーブルであり、公開鍵ＩＤ２０１と秘密鍵ＩＤ２０２と秘密鍵２０３で構成される。

図２の２１１は、公開鍵ＩＤ２０１が「ＰＫｅｙＩＤ＿００１」の公開鍵に対応する秘密鍵ＩＤ２０２は「ＳＫｅｙＩＤ＿００１」であり、秘密鍵２０３の値が「ＳＫｅｙ＿００１」であることを示している。

図３は、鍵配置テーブル１１１の一例である。このテーブルは、どの計算機リソース１３１にどの公開鍵１３９が格納されているかを保持するテーブルであり、計算機リソースＩＤ３０１と公開鍵ＩＤ３０２で構成される。

図３の３１１は、計算機リソースＩＤ３０１が「ＲＥＳ＿００１」の計算機リソース１３１のＢＩＯＳロム１３６に格納されている公開鍵のＩＤは「ＰＫｅｙＩＤ＿００１」であることを示している。

図４は、ブートイメージ管理テーブル１１２の一例である。このテーブルは、ブートイメージの格納位置とブートイメージに対してどの秘密鍵で電子署名したかという情報、および、電子署名の格納位置と、そのブートイメージの断片毎の署名検証の優先度情報を保持するためのテーブルであり、ブートイメージＩＤ４０１と、ブートイメージ位置４０２と、秘密鍵ＩＤ４０３と、電子署名位置４０４と、優先度情報位置４０５で構成される。

図４の４１１は、ブートイメージＩＤ４０１が「ＢＯＯＴ＿００１」のブートイメージは「／ＢＯＯＴ＿００１／ｂｏｏｔ」というブートイメージ位置に格納されており、秘密鍵ＩＤ４０３は「ＳＫｅｙＩＤ＿００１」の秘密鍵で署名されており、その電子署名は「／ＢＯＯＴ＿００１／ｓｉｇｎａｔｕｒｅ」という電子署名位置に格納されており、そのブートイメージの断片毎の署名処理の優先度は「／ＢＯＯＴ＿００１／ｐｒｉｏｒｉｔｙ」という優先度情報位置に格納されていることを示している。

図５は、ブートイメージ１２４と電子署名１２５と優先度１２６を格納するブートイメージ管理ストレージ１２１のディレクトリ構造の一例である。ルートディレクトリ「／」の配下には、ブートイメージＩＤ毎のディレクトリがあり、さらにその配下には、ブートイメージ用ディレクトリ５１１と電子署名用ディレクトリ５１２と優先度情報用ディレクトリ５１３がある。５１１〜５１３それぞれのディレクトリには、断片化されたブートイメージファイル（５２１〜５２３）、断片化されたブートイメージファイルに対する電子署名ファイル（５２４〜５２６）、断片化されたブートイメージファイルに対する電子署名検証処理の優先度を保持するファイル（５２７〜５２９）が格納されている。優先度の値はそのファイルに格納されている（５３１〜５３３）。

図５の例では、ブートイメージＩＤが「ＢＯＯＴ＿００１」のブートイメージファイル（断片）は「００１．ｄａｔ」５２１〜「００３．ｄａｔ」５２３であり、「００１．ｄａｔ」５２１に対する電子署名ファイルは「００１．ｓｉｇｎ」５２４であり、「００１．ｄａｔ」５２１に対する電子署名検証処理の優先度は「００１．ｉｎｆｏ」に格納されており、その値は「１」５３１であることを表している。

なお、ブートイメージ管理ストレージ１２１には複数のＨＤＤ１２３が存在するが、コントローラ１２２によって単一ボリュームに見えるものとする。

図６は、署名手段１０８の処理の流れを説明するフローチャートである。以下、図６のフローチャートを参照しながら、ブートイメージを断片に分割し、それぞれの断片に電子署名を付与し、電子署名検証処理の優先度を付与する処理の流れを説明する。

まず、集中管理サーバ１０１の入出力装置１０６から入力されたブートイメージＩＤ４０１と秘密鍵ＩＤ４０３を取得する（ステップ６０１）。次に、鍵管理テーブル１１０を参照し、秘密鍵ＩＤ２０２に対応する秘密鍵２０３をメモリに読み込む（ステップ６０２）．次に、ブートイメージ管理ストレージ１２１のブートイメージＨＤＤ１２３からブートイメージ１２４を読み込み，所定のサイズに分割する（ステップ６０３）。次に、ステップ６０３で分割したブートイメージの断片に対する電子署名をそれぞれ作成し，ブートイメージＨＤＤ１２３に格納する（ステップ６０４）。次に、ステップ６０３で分割したブートイメージの断片に対して優先度の値をそれぞれ付与し、ブートイメージＨＤＤ１２３に格納する（ステップ６０５）。なお、優先度の値は、利用者が指定しても良いが、指定されない場合は、例えば「１」〜「３」などのように、ある範囲の値をそれぞれの断片に均等に割り振るのでもよい。本実施例では、優先度「１」が最も優先度の高いものとする。優先度の値は、その断片に含まれるファイルの種類やアクセス頻度、関数の種類や呼び出し回数、またデータの種類やアクセス頻度、等の情報に基づいて設定することも可能である。このような情報に基づいた優先度の指標付けにより、セキュリティレベルを維持しながら、ブートイメージの署名検証を高速化することができる。

図７は、ブート指示手段１０９とシステムＢＩＯＳ１３７と署名検証手段１４０によって、ブート指示を受けてからホスティング環境ができあがるまでの処理の流れを説明するフローチャートである。以下、図７のフローチャートを参照しながら詳細に説明する。

まず、集中管理サーバ１０１の入出力装置１０６から入力されたブートイメージＩＤ４０１と、計算機リソースＩＤ３０１と、電子署名検証処理の優先度と、を取得する（ステップ７０１）。このとき、複数の計算機リソース１３１に同一のブートイメージをロードさせてブートさせるよう指示された場合は、複数の計算機リソースＩＤを取得する。

次に、取得した計算機リソースＩＤ３０１とブートイメージＩＤ４０１と優先度とをテーブルの形で、メインメモリ１０３に格納する（ステップ７０２）。

ステップ７０２によって作成されたブート指示テーブル１１３の例を図８に示す。このテーブルは、計算機リソースＩＤ３０１とブートイメージＩＤ４０１と優先度指定８０１とブート成否８０２で構成される。図８の例では、ステップ７０１でブートイメージＩＤ４０１が「ＢＯＯＴ＿００１」のブートイメージを計算機リソースＩＤ３０１が「ＲＥＳ＿００１」〜「ＲＥＳ＿００５」の５台にロードさせてブートさせる場合の例で、ブート処理時に署名検証処理を行うブートイメージの断片は「３以下」のものと指定された場合の例である。ステップ７０２の時点では、ブート成否８０２は全て空欄となっているものとする。ブート成否８０２への値の格納はステップ７０５で行われる（詳細は後述）。

次に、ステップ７０１で指定された計算機リソースＩＤ３０１に対応する計算機リソース全てに対して、Ｗａｋｅ ＵｐパケットをＮＩＣ１０４経由で送信する（ステップ７０３）。計算機リソース１３１は、ＮＩＣ１３４経由で、ステップ７０３のＷａｋｅ Ｕｐパケットを受信し、システムＢＩＯＳ１３７のＷａｋｅ Ｕｐ Ｏｎ ＬＡＮ機能でブート処理を開始する（ステップ７１１）。ここで、複数の計算機リソースが同時並行的にブート処理を開始する。なお、Ｗａｋｅ Ｕｐ Ｏｎ ＬＡＮ機能とは、ある特定のパケットを受信したときに計算機をアクティブにさせることができる機能であり、広く利用されている技術である。

次に、システムＢＩＯＳ１３７は、ファームウェアに格納されたネットワークドライバ１４１を読み込み、ＮＩＣ１３４経由で集中管理サーバ１０１のメインメモリ１０３から自分の計算機リソースＩＤに対応するブートイメージＩＤを取得し、ブートイメージ管理テーブル１１２からブートイメージ位置４０２と電子署名位置４０４と優先度情報位置４０５を読み込む（ステップ４０５）．例えば、自分の計算機リソースＩＤが「ＲＥＳ＿００１」であった場合、図８の８１１からブートイメージＩＤ４０１「ＢＯＯＴ＿００１」を取得し、ブートイメージ管理テーブル１１２から「ＢＯＯＴ＿００１」に対応するブートイメージ位置「／ＢＯＯＴ＿００１／ｂｏｏｔ」を取得する。電子署名位置４０４と優先度情報位置４０５についても、同様に取得する。

次に、ＨＢＡドライバ１４１を読み込み、ＨＢＡ１２５経由でブートイメージ管理ストレージ１２１にアクセスし、ブートイメージの全ての断片を処理していない場合は（条件分岐７１３）、ブートイメージの断片（５２１など）と電子署名（５２４など）と優先度（５３１など）を読み込む（ステップ７１４）。

次に、ステップ７１４で読み込んだ優先度の値と、ステップ７０２で作成したテーブル（図８）の優先度指定の値を比較し、その断片が電子署名検証処理の対象かどうか判断する（条件分岐７１５）。条件分岐７１５で検証処理の対象であると判断された場合は、ステップ７２１へ進み、そうでない場合は、電子署名検証処理をスキップしてステップ７１７へ進んでブート処理を行う。

署名検証手段１４０は、ファームウェア１３８から公開鍵１３９を読み込む（ステップ９１１）。次に、ブートイメージのダイジェスト値を生成する（ステップ７２２）。次に、ステップ７２１で読み込んだ公開鍵１３９を用いて電子署名１２５を復号化する（ステップ７２３）。ステップ７２２で生成したダイジェスト値とステップ７２３で復号化した値を比較する（ステップ７２４）。一致した場合は、一致したことをシステムＢＩＯＳへ通知し、一致しなかった場合は、一致しなかったことをシステムＢＩＯＳへ通知する（ステップ７２５）。

ステップ７１６では、ステップ７２５からの通知を受け取り、署名検証が成功したかどうか判断する。署名検証が成功した場合は、ステップ７１７へ進み、ブート処理を行う。署名検証が失敗した場合は、ステップ７１８へ進み、ブートを中断したことをブート指示手段１０９に通知する。

ステップ７１４〜ステップ７１７は、条件分岐７１３により、ブートイメージの断片を全て処理するまで繰り返され、署名検証対象の断片が全て署名検証に成功した場合は、無事にブート処理が完了したことになる。その場合は、ステップ７１９で、ブートを完了したことをブート指示手段１０９に通知する。

ブート指示手段１０９は、ステップ７０４によって、システムＢＩＯＳからのブート成否を受け取り、ブート中断が通知された場合は、ステップ７０１で取得した全てのブート対象の計算機リソースに対して、ブート中断指示を送信する。つまり、ブート対象の計算機リソースのうち、一つでも署名検証が失敗した場合は、全ての計算機リソースのブート処理を中止する。

ステップ７０４によって、ブート完了の通知を受けた場合は、その計算機リソースがブートに成功したことをステップ７０２で作成したテーブルのブート成否８０２に書き込む（ステップ７０５）。図８の例では、これまでに、８１１、８１２、８１４のブートが完了したことを表している。

ステップ７０２で作成したテーブルのブート成否８０２が全て「ＹＥＳ」になった時点で、全ての計算機リソースのブート処理が完了したことになるので、ブートが完了した旨を入出力装置１０６経由でユーザに通知する。

なお、ステップ７０１において、ユーザが集中管理サーバ１０１に対して入出力装置１０６を用いて実行を指示するように説明したが、集中管理サーバ１０１がスケジュール管理機能を具備している場合には、タイマーによる実行制御を行うのでも良い。

ステップ７０１で、ブートイメージの各断片に付与された優先度の値が「１」〜「３」であり、ブート処理時に署名検証処理を行うブートイメージの断片は「３以下」のものと指定された場合は、全ての前記断片について、署名検証処理を行うことになる。また、ブート処理時に署名検証処理を行うブートイメージの断片は「１以下」のものと指定された場合は、ブートイメージの各断片に付与された優先度の値が「１」の前記断片についてのみ、署名検証処理を行うことになる。さらに、ブート処理時に署名検証処理を行うブートイメージの断片は「０以下」のものと指定された場合は、署名検証処理は行わないことになる。このように、ブート処理時に署名検証処理を行うブートイメージの断片を優先度という形で指定することで、電子署名の検証を全て省略したくはないが、ブート時間はいくらか短縮させたいといったニーズに対応できるようになる。

また、ステップ７０１で、集中管理サーバ１０１の入出力装置１０６から入力されたブートイメージＩＤ４０１と、計算機リソースＩＤ３０１と、電子署名検証処理の優先度と、を取得するが、複数の計算機リソース１３１毎に署名検証処理の優先度情報を個別に指示される場合、すなわち、計算機リソースＩＤ「ＲＥＳ＿００１」に対しては優先度「３」、計算機リソースＩＤ「ＲＥＳ＿００２」に対しては優先度「１」、のように、指示される場合がある。この場合は、複数の計算機リソースで同じ断片の電子署名検証処理を重複して行わないことになり、つまり、ある断片の電子署名検証処理は、いずれかの計算機リソースでのみ行われることになる。計算機リソースのブート処理は同時並行的に処理できるので、全体のブート処理時間を短縮することができるようになる。また、各断片の署名検証処理の計算機リソース割り当ては、例えば、優先度「１」の断片が複数あり、かつ検証可能な計算機リソースが複数ある場合は、それぞれの計算機リソースに署名検証の負荷が平準化されるように割り当てて処理し、その後、同様の方法で優先度「２」の断片の署名検証処理をすることができる。

本実施例では、ブートイメージをいくつかの断片に分割し、それぞれの断片に電子署名を付与し、さらに、電子署名を検証する優先度を付与して、ブート指示として優先度を指定することで、電子署名を検証する断片の数を減らす方法を説明した。これは、すべての断片について電子署名の検証を行うと、断片に分割したことによって、分割しない場合よりも時間がかかってしまうという問題に対応するものである。本実施例の方法によれば、例えば、セキュリティ強度を重視する場合は、全ての断片に対して署名検証処理を行うように優先度を指定すればよいし、ブート処理の時間短縮を重視する場合は、優先度の低い断片の署名検証処理は省略されるように、優先度を指定すればよい。セキュリティ強度とブート処理の時間はトレードオフの関係になり、本発明は、利用者の優先度指定によって、その度合いを制御できるようにしている。

図１２は、本実施例では、集中管理サーバ１０１とブートイメージ管理ストレージ１２１の間、及び、計算機リソース１３１とブートイメージ管理ストレージ１２１の間のアクセスは、ＨＢＡ１０５、ＨＢＡ１２５とコントローラ１２２を経由して行われるとしたが、ＨＢＡを用いずにＮＩＣを用いて行う場合の構成を示した図である。図１２において、１２０１はファイルサーバであり、ＨＢＡ１２０２とＮＩＣ１２０３を備える計算機である。この構成では、集中管理サーバ１０１とブートイメージ管理ストレージ１２１の間のアクセスはＮＩＣ１０４とＬＡＮ１５１とＮＩＣ１２０３とＨＢＡ１２０２とＳＡＮ１６１とコントローラ１２２とを経由して行われる。また、計算機リソース１３１とブートイメージ管理ストレージ１２１の間のアクセスはＮＩＣ１３４とＬＡＮ１５１とＮＩＣ１２０３とＨＢＡ１２０２とＳＡＮ１６１とコントローラ１２２とを経由して行われる。

本実施例（図１）では、ブートイメージ１２４と電子署名１２５と優先度情報１２６を管理ストレージにて管理し、ＨＢＡ１２５経由でブート処理（いわゆるＳＡＮブート）を行うように説明したが、図１３に示すように、ファイルサーバ１２０１を用いることで、ＮＩＣ１３４経由のブート処理（いわゆるＬＡＮブート）を行うこともできる。

以下、本発明によるシステム動的構成変更方法の実施例２について、主に図９〜図１１を参照して詳細に説明する。以下に説明する本発明の実施例２は、ホスティング環境を構築する際に、ブート処理の最中に動的に電子署名を付与する方法である。

図９は、実施例２における、ホスティング環境構築方法を実現する集中管理サーバの構成と機能ブロック、及び、前記集中管理サーバによって制御される計算機リソースの構成と機能ブロック、及び、ブートイメージを格納・管理するブートイメージ管理ストレージの構成と機能ブロックの一例である。実施例１の説明で使用した図１との違いは、署名手段９０１、鍵管理テーブル１１０、鍵配置テーブル１１１、ブートイメージ管理テーブル１１２をブートイメージ管理ストレージ１２１に備えるようにした（集中管理サーバ１０１から移動した）点である。なお、鍵管理テーブル１１０、鍵配置テーブル１１１、ブートイメージ管理テーブル１１２の構造及び保持するデータは実施例１と同じである。

図１０は、ブート指示手段１０９とシステムＢＩＯＳ１３７と署名検証手段１４０によって、ブート指示を受けてからホスティング環境ができあがるまでの処理の流れを説明するフローチャートである。実施例１の説明で使用した図７との違いは、ステップ１００１とステップ１００２とステップ１００３である。

実施例１のステップ７０１では、ブートイメージの断片に対する電子署名位置４０４を読み込んでいたが、実施例２のステップ１００１では、電子署名位置４０４は読み込まない。また、実施例１のステップ７１４では、ブートイメージの断片に対する電子署名を読み込んでいたが、実施例２のステップ１００２では、電子署名は読み込まない。これらの相違は、実施例２では、ステップ１００１の時点では、電子署名はまだ作成されていないためである。

また、実施例２では、ステップ１００３が新たに加えられており、ここで、署名手段９０１に対して電子署名の作成を行う。すなわち、ステップ７１５で電子署名の検証処理の対象であると判定されたブートイメージの断片についてのみ、その時点で電子署名の付与を署名手段９０１に依頼することで、予め電子署名を付与する必要もなく、また、必要最小限のコストで、セキュリティを確保できる。

図１１は、署名手段９０１の処理の流れを説明するフローチャートである。以下、図１１のフローチャートを参照しながら、ブートイメージの断片に対する電子署名を作成し、呼び出し元に返すまでの処理の流れを説明する。

まず、ブートイメージＩＤ４０１と断片ファイル名（５２１〜５２３のいずれか）と計算機リソースＩＤ３０１を呼び出し元から受け取る（ステップ１１０１）。次に、鍵は一テーブル１１１を参照し、計算機リソースＩＤ３０１に対応する公開鍵ＩＤ３０２を取得する（ステップ１１０２）。次に、鍵管理テーブル１１０を参照し、公開鍵ＩＤ３０２に対応する秘密鍵２０３を取得する（ステップ１１０３）。次に、ブートイメージ管理ストレージ１２１のブートイメージＨＤＤ１２３からブートイメージ１２４の断片ファイル（５２１〜５２３のいずれか指定されたもの）を読み込み，電子署名を作成し，呼び出し元に返す（ステップ１１０４）。

本実施例は、実施例１のように、ブートイメージの断片に対してあらかじめ電子署名を付与せず、ホスティング環境を構築する際に、その時点で動的に電子署名を付与する方法の例である。実施例１において、計算機リソースが保持する公開鍵が計算機リソース毎に異なる場合には、公開鍵の数だけ、電子署名をあらかじめ付与し、ブートイメージ管理ストレージ１２１に保持しておかなければならないが、こうすることで、例えば計算機リソースが保持する公開鍵が計算機リソース毎に異なる場合にも容易に対応できる。

なお、集中管理サーバ１０１とブートイメージ管理ストレージ１２１の間のアクセスをＮＩＣ１０４、ＬＡＮ１５１を経由させて行う場合は、実施例１の図１２のように、ファイルサーバ１２０１を配置すればよい。ファイルサーバ１２０１を用いることで、実施例１で説明した別形態と同様に、ＮＩＣ１３４経由のブート処理（いわゆるＬＡＮブート）を行うことができる。

本発明は、データセンターや企業内の計算センターなどにおいて、業務システムを稼働させるためのホスティング環境を安全かつ高速に構築する際に利用できる。

本発明の実施例１におけるホスティング環境構築方法を実現する集中管理サーバの構成と機能ブロック、及び、前記集中管理サーバによって制御される計算機リソースの構成と機能ブロック、及び、ブートイメージを格納・管理するブートイメージ管理ストレージの構成と機能ブロックの一例である。 鍵管理テーブル１１０の一例である。 鍵配置テーブル１１１の一例である。 ブートイメージ管理テーブル１１２の一例である。 ブートイメージ１２４と電子署名１２５と優先度１２６を格納するブートイメージ管理ストレージ１２１のディレクトリ構造の一例である。 本発明の実施例１における署名手段１０８の処理の流れを説明するフローチャートである。 本発明の実施例１におけるブート指示手段１０９とシステムＢＩＯＳ１３７と署名検証手段１４０によって、ブート指示を受けてからホスティング環境ができあがるまでの処理の流れを説明するフローチャートである。 ブート指示テーブル１１３の一例である。 本発明の実施例２におけるホスティング環境構築方法を実現する集中管理サーバの構成と機能ブロック、及び、前記集中管理サーバによって制御される計算機リソースの構成と機能ブロック、及び、ブートイメージを格納・管理するブートイメージ管理ストレージの構成と機能ブロックの一例である。 本発明の実施例２におけるブート指示手段１０９とシステムＢＩＯＳ１３７と署名検証手段１４０によって、ブート指示を受けてからホスティング環境ができあがるまでの処理の流れを説明するフローチャートである。 本発明の実施例２における署名手段９０１の処理の流れを説明するフローチャートである。 本発明の実施例１、実施例２におけるＬＡＮブート処理を行う機能ブロックの一例である。

符号の説明

１０１…集中管理サーバ、１２１…ブートイメージ管理ストレージ、１３１…計算機リソース、１０８…署名手段、１０９…ブート指示手段、１１０…鍵管理テーブル、１１１…鍵配置テーブル、１１２…ブートイメージ管理テーブル、１１３…ブート指示テーブル、１２４…ブートイメージ、１２５…電子署名、１３７…システムＢＩＯＳ、１３９…公開鍵、１４０…署名検証手段。

Claims (6)

1. 複数の計算機リソースと、前記複数の計算機リソースにローディングさせるブートイメージを格納したブートイメージ管理ストレージと、前記ブートイメージを前記複数の計算機リソースにローディングさせる管理計算機とが互いに通信可能な計算機システムにおいて、前記管理計算機の指示により、前記ブートイメージを、前記複数の計算機リソースにローディングさせてブートさせることにより同一のホスティング環境を前記複数の計算機リソースに構築するホスティング環境構築方法であって、
   前記管理計算機は、
   予め、前記ブートイメージを複数の断片に分割し、前記計算機リソースに備えられたＲＯＭ部に記憶された公開鍵に対応する秘密鍵を用いて、前記ブートイメージの断片に対して電子署名を付与してブートイメージ管理ストレージに格納し、
   ローディングさせるブートイメージの識別情報とともに、前記複数の計算機リソースにブート指示を送信し、
   前記複数の計算機リソースは、
   前記管理計算機からの前記ブート指示の受領に応じて、前記識別情報で指定されたブートイメージの断片を順次、前記ブートイメージ格納ストレージから読み込み、
   各計算機リソースに備えられた前記ＲＯＭ部に記憶された公開鍵を用いて、前記ブートイメージの断片に付与されている電子署名の検証処理を実行して前記ブートイメージの断片が有効か無効かを判断し、
   前記ブートイメージの断片が無効であった場合には、前記管理計算機に検証処理が失敗したことを通知し、
   前記管理計算機は、前記複数の計算機リソースのうちのひとつから前記検証の失敗を受領すると、ブート指示を送信した他の全ての計算機リソースに対してブート中止指示を送
   信する
   ことを特徴とするホスティング環境構築方法。
2. 複数の計算機リソースと、前記複数の計算機リソースにローディングさせるブートイメージを格納したブートイメージ管理ストレージと、前記ブートイメージを前記複数の計算機リソースにローディングさせる管理計算機とが互いに通信可能な計算機システムにおいて、前記管理計算機の指示により、前記ブートイメージを、前記複数の計算機リソースにローディングさせてブートさせることにより同一のホスティング環境を前記複数の計算機リソースに構築するホスティング環境構築方法であって、
   前記管理計算機は、
   予め、前記ブートイメージを複数の断片に分割してブート管理ストレージに格納し、
   ローディングさせるブートイメージの識別情報と共に前記複数の計算機リソースにブート指示を送信し、
   前記複数の計算機リソースは、
   前記管理計算機からの前記ブート指示の受領に応じて、ローディングするブートイメージの断片に対する電子署名の生成処理を要求するメッセージと、当該計算機リソースの識別子とローディングするブートイメージの断片の識別子をブートイメージ管理ストレージに対して送信し、
   前記ブートイメージ管理ストレージは、
   前記ブートイメージ管理ストレージが備える鍵管理テーブルから前記計算機リソースの識別子に対応する秘密鍵を特定し、前記秘密鍵を用いて前記ブートイメージの断片の識別子が示すブートイメージの断片に対して電子署名を生成し、受領した前記メッセージの送信元の前記計算機リソースに電子署名を送信し、
   前記計算機リソースは、各前記計算機リソースに備えられたＲＯＭ部に格納された署名検証部によって、受け取った電子署名の検証処理を実行し、
   検証処理が失敗した場合には、前記管理計算機に検証処理が失敗したことを通知し、
   前記管理計算機は、前記複数の計算機リソースの１つから前記検証処理の失敗を受領すると、ブート指示を送信した他の全ての前記計算機リソースに対してブート中止指示を送信する
   ことを特徴とするホスティング環境構築方法。
3. 請求項１または２に記載のホスティング環境構築方法であって、
   前記ブートイメージ管理ストレージは、更に、分割されたブートイメージの断片毎に優先度情報を有し、
   前記管理計算機は、更に電子署名の検証処理の対象とするかどうかの優先度ともに、前記複数の計算機リソースにブート指示を送信し、
   前記計算機リソースは、前記ブート指示と共に送信された前記優先度と前記ブートイメージの断片に対応する前記優先度情報との比較に基づいて、電子署名の検証を行うかどうか判断する
   ことを特徴とするホスティング環境構築方法。
4. 請求項３に記載のホスティング環境構築方法であって、
   前記管理計算機は、ブート指示と共に送信する前記優先度を、前記複数の計算機リソース毎に指定する
   ことを特徴とするホスティング環境構築方法。
5. 複数の計算機リソースと、前記複数の計算機リソースにローディングさせるブートイメージを格納したブートイメージ管理ストレージと、前記ブートイメージを前記複数の計算機リソースにローディングさせる管理計算機とが互いに通信可能な計算機システムにおいて、前記管理計算機の指示により、前記ブートイメージを、前記複数の計算機リソースにローディングさせてブートさせることにより同一のホスティング環境を前記複数の計算機リソースに構築する計算機システムであって、
   前記管理計算機は、
   予め、前記ブートイメージを複数の断片に分割し、前記計算機リソースに備えられたＲＯＭ部に記憶された公開鍵に対応する秘密鍵を用いて、前記ブートイメージの断片に対して電子署名を付与してブートイメージ管理ストレージに格納し、
   ローディングさせるブートイメージの識別情報とともに、前記複数の計算機リソースにブート指示を送信し、
   前記複数の計算機リソースは、
   前記管理計算機からの前記ブート指示の受領に応じて、前記識別情報で指定されたブートイメージの断片を順次、前記ブートイメージ格納ストレージから読み込み、
   各計算機リソースに備えられた前記ＲＯＭ部に記憶された公開鍵を用いて、
   前記ブートイメージの断片に付与されている電子署名の検証処理を実行して前記ブートイメージの断片が有効か無効かを判断し、
   前記ブートイメージの断片が無効であった場合には、前記管理計算機に検証処理が失敗したことを通知し、
   前記管理計算機は、前記複数の計算機リソースのうちのひとつから前記検証の失敗を受領すると、ブート指示を送信した他の全ての計算機リソースに対してブート中止指示を送信する
   ことを特徴とする計算機システム。
6. 複数の計算機リソースと、前記複数の計算機リソースにローディングさせるブートイメージを格納したブートイメージ管理ストレージと、前記ブートイメージを前記複数の計算機リソースにローディングさせる管理計算機とが互いに通信可能な計算機システムにおいて、前記管理計算機の指示により、前記ブートイメージを、前記複数の計算機リソースにローディングさせてブートさせることにより同一のホスティング環境を前記複数の計算機リソースに構築する計算機システムであって、
   前記管理計算機は、
   予め、前記ブートイメージを複数の断片に分割してブート管理ストレージに格納し、
   ローディングさせるブートイメージの識別情報と共に前記複数の計算機リソースにブート指示を送信し、
   前記複数の計算機リソースは、
   前記管理計算機からの前記ブート指示の受領に応じて、ローディングするブートイメージの断片に対する電子署名の生成処理を要求するメッセージと、当該計算機リソースの識別子とローディングするブートイメージの断片の識別子をブートイメージ管理ストレージに対して送信し、
   前記ブートイメージ管理ストレージは、
   前記ブートイメージ管理ストレージが備える鍵管理テーブルから前記計算機リソースの識別子に対応する秘密鍵を特定し、前記秘密鍵を用いて前記ブートイメージの断片の識別子が示すブートイメージの断片に対して電子署名を生成し、受領した前記メッセージの送信元の前記計算機リソースに電子署名を送信し、
   前記計算機リソースは、各前記計算機リソースに備えられたＲＯＭ部に格納された署名検証部によって、受け取った電子署名の検証処理を実行し、
   検証処理が失敗した場合には、前記管理計算機に検証処理が失敗したことを通知し、
   前記管理計算機は、前記複数の計算機リソースの１つから前記検証処理の失敗を受領すると、ブート指示を送信した他の全ての前記計算機リソースに対してブート中止指示を送信する
   ことを特徴とする計算機システム。

Images