JP2010026572A - 仮想計算機の現出方法、この方法を実行するためのプログラム、及びこの方法を実行するサーバ - Google Patents

Abstract

【課題】サーバ上で、サーバプログラム及びＡＰプログラムを動作させつつ、サーバプログラムを、ＡＰｙプログラムを介した側面攻撃から保護する。
【解決手段】サーバ１００上に第一のＶＭ１２１ａを現出させ、第一のＶＭ１２１ａ上で、ＯＳプログラム、サーバプログラムであるＡＰｘプログラム、ＡＰｙプログラムを起動させ、第一のＶＭ１２１ａをコピーして、サーバ１００上に、ＯＳプロセス１２４ｂ、ＡＰｘプロセス１２２ｂ及びＡＰｙプロセス１２３ｂを含む第二のＶＭ１２１ｂを現出させる。第１のＶＭ１２１ａ上のＡＰｙプロセス１２３ａを稼動不能にし、第二のＶＭ１２１ｂ上のＡＰｘプロセス１２２ｂを稼動不能にする。外部記憶装置２１０ａ，２１０ｂ中のＡＰｘ用ファイル２１０ａには、第一のＶＭ１２１ａからのアクセスを認め、第二のＶＭ１２１ｂからのアクセスを認めない。
【選択図】図２

Description

本発明は、複数のアプリケーションプログラムを実行するため、計算機上に仮想計算機を現出させ、該複数のアプリケーションプログラムのうちの特定のアプリケーションプログラム及びそのファイル資源を保護する技術に関する。
関する。

コンピュータには、その適用環境に応じて、様々なセキュリティ上の課題が存在する。サーバと呼ばれるコンピュータは、このコンピュータを用いる組織の業務遂行のために最も重要な機能・サービスを提供する。このようなサーバコンピュータには、アクセスする情報も重要性の高いものが多く、そのため、セキュリティに関する要求も高い。

サーバにおけるセキュリティ上の目標は、サーバのサービス機能そのものの保護、及びサービスを実現するソフトウエアであるサーバプログラムが取り扱う情報の保護である。これらの目標を阻害する脅威としては、サーバプログラム自身の脆弱性、サーバ上で同時に稼動するサーバプログラム以外のソフトウエアの脆弱性、及びサーバの運用に関する脆弱性がある。

サーバプログラムの一般的な動作は、ユーザからのサービスリクエストに対する、その内容に応じた処理の実行と、処理結果に応じたレスポンスと、である。リクエストは、ネットワークを介して、通信によってもたらされるのが普通である。ユーザは、不特定多数の場合も含めて、あらかじめ定義されており、セキュリティポリシによっては、特定のリクエストは、特定の資格を有するユーザのみに許される、ということもある。これを実現するために、サーバプログラムは、ユーザ認証を行い、適切なアクセス制御を実施することがある。

ユーザ認証やアクセス制御に欠陥があれば、もちろん、それは、サーバプログラムの脆弱性である。また、サーバプログラムの実装上の欠陥（バグ）による脆弱性もある。バッファオーバフローと呼ばれる欠陥は、しばしば発生し、不正なサーバ侵入のような重大な事故につながる危険な脆弱性としてよく知られている。

ところで、サーバコンピュータ上では、サーバプログラム以外のプログラムも同時に走行していることが多い。例えば、あるサーバプログラムが稼動しているサーバコンピュータ上で、他のサービスを実現するためのプログラムが稼動していることがある。この他のプログラムも、ネットワークを介してリクエストを受け付けている場合、この他のプログラムに脆弱性があれば、この他のプログラムも、サーバプログラムと同様に、不正なサーバ侵入の危険にさらされることになる。この他のプログラムの脆弱性のためにサーバ侵入されると、サーバプログラムが攻撃されたり、サーバプログラムが使用するファイルなどの資源に不正にアクセスされたりする事態が生じる虞がある。これは、決してまれに生ずる事態ではなく、サーバにおいてしばしば発生する、不正アクセスの代表的なシナリオとされている。

このような側面攻撃、すなわち、サーバプログラムの正式のインタフェースを使用しない攻撃に対しては、サーバプログラムが自ら実施する認証やアクセス制御などの様々なセキュリティ対策は無効である。

このような脅威を回避するために、例えば、状況はやや異なるが、以下の非特許文献１に開示されている「サーバでは不要なプログラムは極力動かさない」という、システム運用上のノウハウが知られている。

なお、以上のサーバプログラムのセキュリティ技術とは異なるが、本願の発明に関連する技術として、以下の特許文献１には、あるコンピュータ上に現出されている仮想計算機（以下、ＶＭとする）を他のコンピュータに移すＶＭマイグレーション技術が示されている。

米国特許6,795,966 「ファイアウォール構築 インターネットセキュリティ」（Ｄ．Ｂ．Ｃｈａｐｍａｎ、Ｅ．Ｄ．Ｚｗｉｃｋｙ著、歌代和正監訳、鈴木克彦訳：、オライリー・ジャパン発行、１９９６年、原著：「Ｂｕｉｌｄｉｎｇ Ｉｎｔｅｒｎｅｔ Ｆｉｒｅｗａｌｌｓ」、ＯＲｅｉｌｌｙ ＆ Ａｓｓｏｃｉａｔｅｓ， Ｉｎｃ．発行、１９９５年）、５．８．２項（ｐｐ．：１１３〜１２２）

しかしながら、上記非特許文献１に記載の技術では、サーバコンピュータ上で、サーバプログラムを除くアプリケーションプログラムの動作が極めて制限され、サーバコンピュータの利用価値を高めることができない、という問題点がある。また、上記非特許文献１に記載の技術を実際に実行することは極めて困難であるという問題点もある。

そこで、本発明は、以上の従来技術の問題点に着目し、保護の必要性の高いアプリケーションプログラムと共に、他のアプリケーションプログラムを同一コンピュータ上で動作させつつも、コンピュータのセキュリティを高めることができる技術を提供することを目的とする。

そこで、本発明では、保護の必要性の高いアプリケーションプログラムを、同時走行する他のアプリケーションプログラムの脆弱性から保護するために、他のアプリケーションプログラムの動作環境から孤立した環境で、保護対象野アプリケーションプログラムを動作させることで、上記目的を達成する。

具体的には、本発明では、
コンピュータ上に第一の仮想計算機を現出させ、該第一の仮想計算機上で、ＯＳ及び複数のＡＰプログラムを起動させて、該第一の仮想計算機上にＯＳプロセス及び複数のＡＰプロセスを展開させる。

次に、前記ＯＳプロセス及び記複数のＡＰプロセスが展開している前記第一の仮想計算機をプロセスコピーして、前記コンピュータ上に、該複数のＡＰプロセス及び該ＯＳプロセスが展開している第二の仮想計算機を現出させる。

次に、前記コンピュータの記憶装置に予め格納されていた各ＡＰ用のデータファイルのうち、特定のＡＰプロセスが利用するファイルには、前記第一の仮想計算機からのアクセスを認め、前記第二の仮想計算機からのアクセスを認めず、前記複数のＡＰプロセスのうち該特定のＡＰプロセスを除く他のＡＰプロセスが利用するファイルには、該第二の仮想計算機からのアクセスを認める入出力制御を実行する。

さらに、前記第一の仮想計算機上の前記複数のＡＰプロセスのうち、前記他のＡＰプロセスを稼動不能にすると共に、前記第二の仮想計算機上の複数のＡＰプロセスのうちの前記特定のＡＰプロセスを稼動不能にする。

以上の結果、コンピュータ上に、複数の仮想計算機が現出されるものの、このコンピュータで、実質的に稼動するＡＰプログラムは全体として増減はなく、元のままとなる。また、第一の仮想計算機上では、保護対象である特定のＡＰプロセスのみが、他のＡＰプロセスが実質的に存在しない環境で稼動し、第二の仮想計算機上では、保護対象である特定のＡＰプロセスが実質的に存在しない環境で、他のＡＰプロセスが稼動する。さらに、第二の仮想計算機から、第一の仮想計算機上の特定のＡＰプロセスが利用するファイル資源には、アクセスできない。

なお、本明細書において、プロセスとは、実行中のプログラムを示す。また、あるプログラムに関するプロセスコピーとは、このプログラムを実行するために、メモリー上に展開されているプログラム、及びプログラムの実行で作成された及び用いるためにメモリ上に展開されているデータの一式をコピーすることである。

本発明によれば、特定のＡＰプログラムと共に、他のＡＰプログラムをコンピュータ上で同時走行させつつも、特定のＡＰプログラム及びこの特定のＡＰプログラムが利用するファイル資源を、他のＡＰプログラムを介した側面攻撃から保護することができる。

以下、本発明に係るサーバの一実施形態について、図面を用いて説明する。

図１に示すように、本実施形態のサーバ１００は、サーバ本体１０１と、複数の外部記憶装置２１０，２１０ａ，２１０ｂと、表示装置２０１と、入力装置２０２とを備えている。

サーバ本体１０１は、各種演算処理を実行するＣＰＵ１１０と、ＣＰＵ１１０のワークエリアとなるメモリ１２０と、各外部記憶装置２１０，２１０ａ，２１０ｂ、表示装置２０１、入力装置２０２のインタフェースであるＩＯインタフェース１４０と、通信ネットワークＮのインタフェースであるネットワークインタフェース１５０と、可搬型ディスク記憶媒体Ｄに対してデータの記録・再生を行うディスク記録・再生装置１６０と、を備えている。

複数の外部記憶装置２１０，２１０ａ，２１０ｂのうち、第三の外部記憶装置２１０には、コンピュータとしてのサーバ１００上に仮想計算機（以下、ＶＭ）を現出させて、これを管理するためのＶＭモニタプログラム２１１と、サーバプログラムとしてのアプリケーション（以下、ＡＰｘとする）プログラム２１２と、他のアプリケーション（以下、ＡＰｙとする）プログラム２１３と、オペレーションシステム（以下、ＯＳとする）プログラム２１４とが格納されている。また、第一の外部記憶装置２１０ａには、ＡＰｘプログラム２１２の実行で取り扱うデータがＡＰｘ用データファイル２２２として格納され、第二の外部記憶装置２１０ｂには、ＡＰｙプログラム２１２の実行で取り扱うデータがＡＰｙ用データファイル２２３として格納されている。これらのプログラム２１１〜２１４やデータファイル２２２，２２３は、いずれも、可搬型ディスク記憶媒体Ｄに記憶されていたものをディスク記録・再生装置１６０で再生し、外部記憶装置２１０，２１０ａ，２１０ｂに格納したものである。なお、各プログラムやデータファイルは、以上のように、可搬型ディスク記憶媒体Ｄで提供されてもよいが、通信ネットワークＮで提供されてもよい。また、ここでは、複数の外部記憶装置２１０，２１０ａ，２１０ｂがサーバ本体１０１に対して外付けされている形態をとっているが、複数の外部記憶装置２１０，２１０ａ，２１０ｂがサーバ本体１０１に内蔵されていてもよいことは言うまでもない。

ＣＰＵ１１０は、機能的に、ＶＭの現出及びこれの管理等を行うＶＭモニタ部１１１を有している。このＶＭモニタ部１１１は、ＶＭ１２１ａを現出させて、これを起動させるＶＭイニシャライザ１１２と、ＶＭ１２１ａ，１２１１ｂの稼動を管理するＶＭディスパチャ１１３と、ＶＭ１２１ａをコピーして新たなＶＭ１２１ｂを生成するマイグレーションマネジャ１１４と、ＶＭ１２１ａ，１２１ｂ上で動作するＡＰプロセス１２２ｂ，１２３ａを稼動不能にするＡＰセパレータ１１５と、ＶＭ１２１ａ，１２１ｂの入出力を制御するＶＭ・ＩＯマネジャ１１６と、ＶＭ１２１ａ，１２１ｂのネットワーク通信を制御するＶルータ１１７と、を有している。なお、以上のＶＭモニタ部１１１は、外部記憶装置２１０に格納されているＶＭモニタプログラム２１１をＣＰＵ１１０が実行することで機能する。

ここで、ＶＭモニタ部１１１の各部１１２〜１１７の機能について、図２を用いて、さらに説明する。

ＶＭモニタ部１１１は、サーバ１００のＣＰＵ１１０とメモリ１２０との複合体１３０上で機能する。このＶＭモニタ部１１１のＶＭイニシャライザ１１２は、複合体であるＣＰＵ・メモリ１３０上に、第一のＶＭ１２１ａを現出させる。この第一のＶＭ１２１ａは、仮想外部記憶装置１２６ａと、この仮想外部記憶装置１２６ａのインタフェースである仮想ＩＯインタフェース１２５ａと、仮想通信ネットワーク１２８ａと、この仮想通信ネットワーク１２８ａのインタフェースである仮想ネットワークインタフェース１２７ａとを有している。さらに、この第一のＶＭ１２１ａは、ＯＳプログラム２１４を起動させてＯＳプロセス１２４ａを生成すると共に、各ＡＰプログラム２１２，２１３を起動させてＡＰプロセス１２２ａ，１２３ａを生成する。

マイグレーションマネジャ１１４は、ＡＰプロセス１２２ａ，１２３ａやＯＳプロセス１２４ａ等を含む第一のＶＭ１２１ａのプロセスコピーして、ＣＰＵ・メモリ１３０上に、第二のＶＭ１２１ｂを現出させる。なお、ＡＰプロセスやＯＳプロセス等のソフトウェアを除くハードウェア部分のみを模擬したものをＶＭと呼び、ＡＰプロセスやＯＳプロセス等のソフトウェア部分とハードウェア部分とをまとめたもの異なる名称で呼ぶことがあるが、ここでは、両者を区別することなく、単にＶＭ（仮想計算機）と呼ぶ。但し、以下において、ＶＭが、ハードウェア部分のみならずソフトウェア部分を含む場合には、ＡＰプロセスやＯＳプロセス等を含むＶＭ、又はＡＰプロセス等を含むＶＭ等と表現することにする。この第二のＶＭ１２１ｂも、第一のＶＭ１２１ａと同様に、ＡＰプロセス１２２ｂ，１２３ｂと、ＯＳプロセス１２４ｂと、仮想ＩＯインタフェース１２５ｂと、仮想外部記憶装置１２６ｂと、仮想ネットワークインタフェース１２７ａと、仮想通信ネットワーク１２８ａと、を有している。

各ＶＭ１２１ａ，１２１ｂ上の各ＯＳプロセス１２４ａ，１２４ｂは、各仮想ＩＯインタフェース１２５ａ，１２５ｂや各仮想ネットワークインタフェース１２７ａ，１２７ｂを、実インタフェースと同様の手順で処理することにより、入出力処理を処理することでできる。

ＶＭディスパチャ１１３は、ＶＭ管理テーブル１３３を参照して、各ＶＭ１２１ａ，１２１ｂの稼動を管理する。このＶＭ管理テーブル１３３は、図７に示すように、各ＶＭ毎に存在し、各ＶＭ管理テーブル１３３ａ，１３３ｂには、ＶＭのＩＤが格納されるＶＭ・ＩＤ領域、利用メモリ範囲等の各種管理情報が格納される管理情報領域とがある。また、ＶＭディスパチャ１１３は、現ＶＭ ＩＤ領域１３４を管理し、いずれかのＶＭ１２１ａ，１２１ｂが入出力動作を行った際、この現ＶＭ ＩＤ領域１３４に入出力動作を行ったＶＭのＩＤを入力する。なお、各ＶＭ管理テーブル１３３は、ＶＭが現出される際に作成される。すなわち、第１のＶＭ管理テーブル１３３ａは、第一のＶＭ１２１ａがＶＭイニシャライザ１１２により現出される際に、このＶＭイニシャライザ１１２により作成される。また、第２のＶＭ管理テーブル１３３ｂは、第二のＶＭ１２１ｂがマイグレーションマネジャ１１４により現出される際に、このマイグレーションマネジャ１１４により作成される。

ＡＰセパレータ１１５は、第一のＶＭ１２１ａ上でＡＰｙプロセス１２３ａを稼動不能にして、サーバプロセスであるＡＰｘプロセス１２２ａからこれを分離すると共に、第二のＶＭ１２１ｂ上でサーバプロセスであるＡＰｘプロセス１２２ｂを稼動不能にして、ＡＰｙプロセス１２３ｂからこれを分離する。

Ｖ・ＩＯマネジャ１１６は、各ＶＭ１２１ａ，１２１ｂからの入出力要求を適宜解釈して、実ＩＯインタフェース１４０を介して、複数の実外部記憶装置２１０，２１０ａ，２１０ｂ、表示装置２０１、入力装置２０２に対する入力処理又は出力処理を実行する。

Ｖルータ１１７は、各ＶＭ１２１ａ，１２１ｂからの通信パケットを、実ネットワークインタフェース１５０を介して、実通信ネットワークＮに送出する一方で、実通信ネットワークＮからの通信パケットを実ネットワークインタフェース１５０を介して受信し、これをいずれかのＶＭ１２１ａ，１２１ｂへルーティングする。すなわち、Ｖルータは、各ＶＭ１２１ａ，１２１ｂによるネットワーク通信を制御する。

次に、図９に示すフローチャートに従って、ＶＭモニタ部１１１が起動してから、サーバプログラムであるＡＰｘプログラム２１２の動作及びこのＡＰｘプログラム２１２が取り扱うデータの保護状態に移行するまでの処理内容について説明する。

ＶＭモニタ部１１１が起動すると、図３に示すように、このＶＭモニタ部１１１のＶＭイニシャライザ１１２が複合体であるＣＰＵ・メモリ１３０上に第一のＶＭ１２１ａを現出する。そして、第１のＶＭ１２１ａは、ＯＳプログラム２１４を読み込んで、これを動作させて、第１のＶＭ１２１ａ内にＯＳプロセス１２４ａを形成する。さらに、第１のＶＭ１２１ａは、各ＡＰプログラム２１２，２１３を読み込んで、これを動作させて、第１のＶＭ１２１ａ内にＡＰプロセス１２２ａ，１２３ａを形成する（Ｓ１０）。なお、ＶＭイニシャライザ１１２は、第一のＶＭ１２１ａの現出過程で、前述したように、図７に示す第一のＶＭ管理テーブル１３３ａを作成する。

次に、マイグレーションマネジャ１１４が、ＯＳプロセス１２４ａ及び各ＡＰプロセス１２２ａ，１２３ａを含む第一のＶＭ１２１ａのスナップショットデータを作成し、このデータをスナップショットファイル２１５として、複数の外部記憶装置のうち、例えば、第三の外部記憶装置２１０に格納する（Ｓ１１）。続いて、マイグレーションマネジャ１１４は、図４に示すように、スナップショットデータをＣＰＵ・メモリ１３０上にリストアし、このＣＰＵ・メモリ１３０上に第二のＶＭ１２１ｂを現出させる（Ｓ１２）。すなわち、マイグレーションマネジャ１１４は、ＣＰＵ・メモリ１３０上の第一のＶＭ１２１ａのプロセスコピーを、同じＣＰＵ・メモリ１３０上に、第二のＶＭ１２１ｂとして展開する。この第二のＶＭ１２１ｂは、前述したように、第一のＶＭ１２１ａと同様に、ＡＰプロセス１２２ｂ，１２３ｂと、ＯＳプロセス１２４ｂと、仮想ＩＯインタフェース１２５ｂと、仮想外部記憶装置１２６ｂと、仮想ネットワークインタフェース１２７ａと、仮想通信ネットワーク１２８ａと、を有している。なお、マイグレーションマネジャ１１４は、第二のＶＭ１２１ｂの現出過程で、前述したように、図６に示す第二のＶＭ管理テーブル１３３ｂを作成する。

次に、Ｖ・ＩＯマネジャ１１６は、図５に示すように、第１のＶＭ１２１ａから第一の記憶装置２１０ａ内のＡＰｘプロセス用データファイル２２２にアクセスできるようにする一方で、第１のＶＭ１２１ａから第二の記憶装置２１０ｂ内のＡＰｙプロセス用データファイル２２３にアクセスできないように、アクセス制御の設定処理を行う。具体的に、Ｖ・ＩＯマネジャ１１６は、第一の記憶装置２１０ａ内のＡＰｘプロセス用データファイル２２２の実アドレスと第一のＶＭ１２１ａ内の仮想外部記憶装置１２６ａの同ファイルの仮想アドレスとのマッピング等を行う（Ｓ１３）。このアクセス制御の設定処理が終了すると、以降、このＶ・ＩＯマネジャ１１６により、第１のＶＭ１２１ａから第一の記憶装置２１０ａ内のＡＰｘプロセス用データファイル２２２にアクセスできる一方で、第１のＶＭ１２１ａから第二の記憶装置２１０ｂ内のＡＰｙプロセス用データファイル２２３にアクセスできないように、アクセス制御が実行される。

以上のアクセス制御の設定処理が終了すると、ＡＰセパレータ１１５は、第一のＶＭ１２１ａ上のＡＰｙプロセス１２３ｂを稼動不能にする、つまり、ＡＰｙプログラム２１３の実行を停止、又はこれを実行できない状態にする（Ｓ１４）。特定のプログラムの実行を停止する方法としては、例えば、停止するためのインタフェースを利用する方法がある。この方法としては、いささか乱暴ではあるが、Ｕｎｉｘ（米国での登録商標）では、Killコマンドにより該当するプロセスを強制終了する方法等である。また、実行プライオリティを下げる方法もある。また、特定のプログラムを実行できない状態にする方法としては、例えば、特定のプログラムの稼動が外部からのリクエストメッセージの受信を契機とする場合、このリクエストメッセージを受信できないようにする方法がある。

以上のステップ１３及びステップ１４の処理と並行して、又は前後して、ステップ１５及びステップ１６が実行される。

ステップ１５では、Ｖ・ＩＯマネジャ１１６が、第２のＶＭ１２１ｂから第二の記憶装置２１０ｂ内のＡＰｙプロセス用データファイル２２３にアクセスできるようにする一方で、第２のＶＭ１２１ｂから第一の記憶装置２１０ａ内のＡＰｘプロセス用データファイル２２２にアクセスできないように、アクセス制御の設定処理を行う。具体的には、前述のステップ１３での処理と基本的に同様に、Ｖ・ＩＯマネジャ１１６は、第二の記憶装置２１０ｂ内のＡＰｙプロセス用データファイル２２３の実アドレスと第二のＶＭ１２１ｂ内の仮想外部記憶装置１２６ｂの同ファイルの仮想アドレスとのマッピングを行う。以降、このＶ・ＩＯマネジャ１１６により、第２のＶＭ１２１ｂから第二の記憶装置２１０ｂ内のＡＰｙプロセス用データファイル２２３にアクセスできる一方で、第２のＶＭ１２１ｂから第一の記憶装置２１０ａ内のＡＰｘプロセス用データファイル２２２にアクセスできないように、アクセス制御が実行される。

ステップ１６では、ＡＰセパレータ１１５が、第二のＶＭ１２１ｂ上のＡＰｘプロセス１２３ａを稼動不能にする、つまり、ＡＰｘプログラム２１３の実行を停止、又はこれを実行できない状態にする。

以上で、サーバプログラムであるＡＰｘプログラム２１２の動作及びこのＡＰｘプログラム２１２が取り扱うデータの保護状態への移行が終了する。

次に、以上の処理による効果について説明する。

仮に、ＡＰｙプログラム２１３が外部からの脅威に対する脆弱性があり、第二のＶＭ１２１ｂ上のＡＰｙプロセス１２３ｂが何らかの手段により、図５に示すように、悪性ウィルス１２９に侵されたとする。

この悪性ウィルス１２９は、何らかの手段でいずれかの外部記憶装置２１０，２１０a，２１０ｂへアクセスを試みる。しかしながら、この悪性ウィルス１２９は、第二のＶＭ１２１ｂ上のＡＰｙプロセス１２３ｂ中に存在し、この第二のＶＭ１２１ｂから外部記憶装置へのアクセスに関して、Ｖ・ＩＯマネジャ１１６により、前述したアクセス制御がなされるため、この悪性ウィルス１２９は、第一の外部記憶装置２１０ａ内のＡＰｘ用ファイル２２２へはアクセスできない。よって、サーバプログラムであるＡＰｘプログラム２１２の資源であるＡＰｘ用ファイル２２２は、この悪性ウィルス１２９に侵されずに済む。

以上のように、本実施形態では、一つのコンピュータ上でサーバプログラムであるＡＰｘプログラム２１２及び他のＡＰｙプログラム２１２を動作させているものの、サーバプログラムであるＡＰｘプログラム２１２の動作環境やこのプログラム２１２のファイル資源へのアクセス環境が、他のＡＰｙプログラム２１３の動作環境やこのＡＰｙプログラム２１３のファイル資源へのアクセス環境から孤立しているため、サーバプログラムであるＡＰｘプログラム２１２やその資源であるＡＰｘ用ファイル２２２が悪性ウィルス１２９に侵される可能性を最小限に抑えることができる。すなわち、保護対象外のＡＰｙプログラム２１３に対する側面攻撃から、サーバプログラムであるＡＰｘプログラム２１２やその資源であるＡＰｘ用ファイル２２２を保護することができる。

ところで、本実施形態では、各ＶＭ１２１ａ，１２１ｂからの実外部記憶装置２１０，２１０ａ，２１０ｂへのアクセス制御をＶ・ＩＯマネジャ１１６により行っているが、各ＶＭ１２１ａ，１２１ｂのＯＳプロセス１２４ａ，１２４ｂで行うことも可能である。しかし、ＯＳは、様々な機能を持ち、実装も巨大である。そのため、設定したアクセス制御だけで攻撃が確実に阻止できることを保証するのは一般に困難である。例えば、ＯＳは、プロセス間の仮想メモリの共用や、プロセス間の通信手段などを提供しているが、このような豊かな機能が悪性ウィルス１２９に悪用されないとは限らない。

一方、ＶＭモニタ部１１１のＶ・ＩＯマネジャ１１６によってアクセス制御する場合、ＶＭモニタ部１１１がＶＭに提供する機能はハードウエアの模擬だけであり、侵入プログラムからアクセスする手段がほとんどない。そのため、ＶＭモニタ部１１１のＶ・ＩＯマネジャ１１６よるアクセス制御は、ＯＳによるアクセス制御より、セキュリティのレベルが遥かに高いと言える。

また、本実施形態では、一旦、一つのＶＭを現出し、このＶＭ上で複数のＡＰプログラムを動作させた状態で、これをプロセスコピーして、新たなＶＭを現出することで、図５に示すような保護状態を創出しているが、直ちに、複数のＶＭを現出し、複数のＶＭのうちのいずれかに、ＡＰプログラムの実行を割り当てることも可能である。しかしながら、この方法では、コンピュータ上で実行予定の全てのＡＰプログラムを予め詳細に調べ、計画的にＡＰプログラムを選択して、いずれかのＶＭに実行を割り当てる必要がある。このように、ＡＰプログラムのセキュリティや実行重要度等を詳細に調べること等を前提として、サーバを運用することは現実には非常に難しい。また、サーバシステム構成が頻繁に変更される場合には、そのたびに実行計画を入念にチェックするのは骨の折れる作業である。

一方、本実施形態では、以上のような手順を踏んで、図５に示すような保護状態を創出しているため、起動前のＡＰプログラムの緻密な調査が不要になる上に、どのＡＰプログラムを保護対象にするかをＡＰプログラムの起動後に決めることができるので、少ない作業負荷で且つ容易に保護状態を創出することができる。

本実施形態では、以上のように、一つのコンピュータ上で、オリジナルＶＭと、そのコピーであるコピーＶＭを現出しているが、このようなことは従来技術では基本的に考えられない。これは、少なくとも、これまでのところ、このようなコンピュータの運用形態にメリットが見出せないことの他に、以下の二つの課題が存在するからである。

一つは、二つのＶＭ上のそれぞれに同じＡＰプロセスが存在することで、各ＡＰプロセスが同じ実ファイル資源にアクセスすることになり、両者からのアクセスの調停が極めて難しいという課題である。この課題に関して、本実施形態では、オリジナルＶＭをコピーしてコピーＶＭを創出しているものの、オリジナルＶＭとコピーＶＭとに同じＡＰプロセスが存在しないように、一方のＶＭに存在すべきＡＰプロセスに関しては、他方のＶＭにおいて稼動不能にする共に、Ｖ・ＩＯマネジャ１１６により二つのＶＭからのファイル資源へのアクセスを調整することで解決している。

他の一つは、二つのＶＭが同じネットワークアドレスを持つため、これらのＶＭを現出しているコンピュータに向けられたパケットを、二つのＶＭに対して、どのようにルーティングするかという課題である。

コンピュータの中には、特定のＡＰプログラムのみを実行するものがあり、このようなコンピュータでは、ネットワーク通信を行う必要がないことがある。しかしながら、本実施形態のように、サーバとしての役目を担うコンピュータの場合には、クライアントからのリクエストに応える必要性から、ネットワーク通信の実行は必須である。

そこで、次に、本実施形態のサーバ１００でのネットワーク通信について説明する。

図６は、図５に示す状態と同じ保護状態を示している。この状態において、ＯＳプロセス１２４ａとＯＳプロセス１２４ｂは、それぞれ、ＩＰアドレス２１ａ，２１ｂを持っている。しかしながら、ＯＳプロセス１２４ｂは、ＯＳプロセス１２４ａのプロセスコピーであるから、ＯＳプロセス１２４ａのＩＰアドレス２１ａとＯＳプロセス１２４ｂのＩＰアドレス２１ｂとは同じＩＰアドレスである。このため、前述したように、外部からこのサーバ１００に送られてきたパケットを、二つのＶＭ１２１ａ，１２１ｂに対して、どのようにルーティングして、二つのＶＭ１２１ａ，１２１ｂのうち一方にのみ存在する目的のＡＰプロセスに確実に受け渡すのか、という課題が生じる。

ところで、今日の代表的な通信プロトコルであるＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet Protocol）やＵＤＰ（User Datagram Protocol）／ＩＰには、通信ポートの概念が存在し、ＯＳプロセスは、このＴＣＰ／ＩＰ又はＵＤＰ／ＩＰに従ってネットワーク通信をする場合、ＡＰプロセス毎にポートＩＤを設定する。そこで、本実施形態では、このポートＩＤを利用して、外部からサーバ１００に送られてきたパケットを、二つのＶＭ１２１ａ，１２１ｂのいずれか一方にのみ存在する目的のＡＰプロセスに確実に受け渡すようにしている。

ここで、ＴＣＰ／ＩＰパケット及びＵＤＰ／ＩＰパケットの構造について、図１２を用いて説明する。

ＩＰパケット１０は、ヘッダ１１とペイロードとを有している。ＩＰヘッダ１１には、発信元ＩＰアドレス１２及び宛先ＩＰアドレス１３が収められている。また、ペイロードには、ＴＣＰパケット１４が収められている。このＴＣＰパケット１４も、ヘッダ１５とペイロードとを有している。ＴＣＰヘッダ１５には、発信元ポートＩＤ１６、宛先ポートＩＤ１７、さらに、ＳＹＮ、ＡＣＫ、ＲＳＴ、ＦＩＮなどを示すプロトコル制御フラグ１８が収められている。また、このＴＣＰパケット１４のペイロードには、アプリケーションデータ１９が収められている。

また、ＵＤＰ／ＩＰパケットの場合、ＵＤＰパケットは、前述のＴＣＰパケットと同様に、ＩＰパケットのペイロードに収められている。このＵＤＰパケットは、ＴＣＰパケットと同様、このＵＤＰパケットのヘッダ中に、発信元ポートＩＤ１６及び宛先ポートＩＤ１７が存在する。但し、ＵＤＰは、ＴＣＰと異なり、コネクションレスで、送達確認等を行わない関係上、ＵＤＰヘッダ中には、ＴＣＰヘッダ１５中のプロトコル制御フラグ１８は存在しない。

サーバ１００が、上記ＴＣＰ／ＩＰやＵＤＰ／ＩＰでネットワーク通信する場合、ＯＳプロセスは、各ＡＰプロセスに対して、ＡＰプロセスがサーバとして機能する、つまりリクエストを受ける側として機能するときのサーバ機能用ポートと、ＡＰプロセスがクライアントとして機能する、つまりリクエストを発信する側として機能するときのクライアント機能用ポートと、を設定する。

ここで、第一のＶＭ１２１ａ上のＯＳプロセス１２４ａは、第一のＶＭ１２１ａ上のＡＰｘプロセス１２２ａに対して、サーバ機能用ポート２２ｓとして「ｓ」を設定し、クライアント機能用ポート２２ｃとして「ｐ」を設定したとする。また、第二のＶＭ１２１ｂ上のＯＳプロセス１２４ｂは、第二のＶＭ１２１ｂ上のＡＰｙプロセス１２３ｂに対して、サーバ機能用ポート２３ｓとして「ｔ」を設定し、クライアント機能用ポート２３ｃとして「ｑ」を設定したとする。

サーバ機能用ポートＩＤは、サービス毎に予め定めたれている。このため、提供するサービスが異なるＡＰｘプロセス１２２ａのサーバ機能用ポート「ｓ」２２ｓと、ＡＰｙプロセス１２３ｂのサーバ機能用ポート「ｔ」２３ｓとが同一ＩＤになることはない。よって、各ＡＰプロセス１２２ａ，１２３ｂがサーバとして機能する場合には、外部からのパケットを二つのＶＭ１２１ａ，１２１ｂのそれぞれにルーティングすれば、このパケットの宛先ポートＩＤ（サーバ機能用ポート）が示すＡＰプロセスに、このパケットを確実に受け渡すことができる。

一方、クライアント機能用ポートＩＤは、ＡＰプロセスにより指定された後、この指定に従ってＯＳプロセスにより設定されることもあれば、ＯＳプロセス自身により指定・設定がされることもある。仮に、一つのＯＳプロセス上に複数のＡＰプロセスが存在する場合、各ＡＰプロセスに対するクライアント機能用ポートのＩＤは同一になることはない。しかしながら、本実施形態のように、二つのＶＭ１２１ａ，１２１ｂが存在し、それぞれに、ＯＳプロセス１２４ａ，１２４ｂ及びＡＰプロセス１２２ａ，１２３ｂが存在する場合、一方のＶＭ１２１ａ上のＡＰｘプロセス１２２ａに対するクライアント機能用ポート「ｐ」２２ｃと、他方のＶＭ１２１ｂ上のＡＰｙプロセス１２３ｂに対するクライアント機能用ポート「ｑ」２３ｃとが、同一ＩＤになる可能性を秘めている。よって、各ＡＰプロセス１２２ａ，１２３ｂがクライアントとして機能する場合には、二つのＶＭ１２１ａ，１２１ｂとのうちのいずれか一方がこのパケットの受取り先ＶＭであると特定しない限り、外部からのパケット中に含まれている宛先ポートＩＤ（クライアント機能用ポート）だけでは、目的のＡＰプロセスに、このパケットを確実に受け渡すことができない。そこで、本実施形態では、このような場合、二つのＶＭ１２１ａ，１２１ｂのうち、いずれか一方のＶＭのみと対応付けられた代理ポートＩＤという概念を導入して、Ｖルータ１１７により、代理ポートＩＤを管理させて、二つのＶＭ１２１ａ，１２１ｂのうち、適切なＶＭに外部からのパケットをルーティングし、目的のＡＰプロセスに、このパケットを確実に受け渡すようにしている。

以下、Ｖルータ１１７での具体的な処理について、図１０及び図１１に示すフローチャートを用いて、以下で説明する。

まず、図１０のフローチャートを用いて、Ｖルータ１１７によるパケット送出時の処理について説明する。

Ｖルータ１１７は、いずれかのＶＭ１２１ａ，１２２ｂからパケットが送出され、これを受け取ると、ＶＭディスパチャ１１３の管理下にある現ＶＭ ＩＤフィールド１３４を参照して、このパケットを送出したＶＭのＩＤを取得する（Ｓ２０）。なお、ＶＭディスパチャ１１３は、図７に示す各ＶＭ管理テーブル１３３ａ，１３３ｂのそれぞれのＶＭ・ＩＤ領域に格納されているＩＤのうちから、入出力処理を行ったＶＭのＩＤを選択して、これを現ＶＭ ＩＤフィールド１３４に格納する。

次に、Ｖルータ１１７は、いずれかのＶＭ１２１ａ，１２２ｂから受け取ったパケットを参照して、このパケット内に格納されている発信元ポートＩＤを取得する（Ｓ２１）。そして、この発信元ポートＩＤがクライアント機能用ポートとして定められている多数のＩＤのうちのいずれかであるか否かを判断する（Ｓ２２）。この発信元ポートＩＤがクライアント機能用ポートとして定められているＩＤではない、つまりサーバ機能用ポートとして定められているＩＤであると判断すると、ステップ２９に進んで、ＶＭから受け取ったパケットを実ネットワークインタフェース１５０を介して、通信ネットワークＮへ送出する。一方、Ｖルータ１１７は、この発信元ポートＩＤがクライアント機能用ポートとして定められているＩＤであると判断すると、ＶＭ通信制御テーブル１３７中で空きレコードを選択し、この空きレコードに、ステップ２１で取得した発信元ポートＩＤを格納する（Ｓ２３）。

ここで、ＶＭ通信制御テーブル１３７の構成について、図８を用いて説明する。

このＶＭ通信制御テーブル１３７は、通信パケットが示す実際のポートＩＤが格納される原ポートＩＤ領域１３７ａと、代理ポートＩＤが格納される代理ポートＩＤ領域１３７ｂと、通信パケットが送出されたＶＭのＩＤが格納されるＶＭ ＩＤ領域１３７ｃと、通信パケットがＴＣＰに準拠するものであるかＵＤＰに準拠するものであるかを示すＴＣＰ/ＵＤＰ区別領域１３７ｄと、当該レコードが空いているか否かを示す空きフラグ領域１３７ｅとを有している。

前述のステップ２３において、Ｖルータ１１７は、まず、ＶＭ通信制御テーブル１３７の空きフラグ領域１３７ｅを参照して、ここに「１（格納済み）」が格納されているか、「０「空き」」が格納されているかで、ＶＭ通信制御テーブル１３７中から空きレコードを選択する。そして、この空きレコード中の空きフラグ領域１３７ｅに、「１（格納済み）」を格納して、このレコードを確保してから、このレコードの原ポートＩＤ領域１３７に、ステップ２１で取得した発信元ポートＩＤを格納する。

Ｖルータ１１７は、次に、ステップ２２で格納した発信元ポートＩＤが、既に使用されているか否かを判断する（Ｓ２４）。この判断は、ＶＭ通信制御テーブル１３７の代理ポートＩＤ領域１３７ｂを探索することで判断できる。例えば、ＶＭ通信制御テーブル１３７を代理ポートＩＤに関するハッシュテーブルとして構成するならば、発信元ポートＩＤ「ｐ」に対するシノニムを探索すればよい。

Ｖルータ１１７は、ステップ２４で、発信元ポートＩＤが既に使用されていると判断すると、予め定められている多数のクライアント機能用ポートのうちから一つの未使用ポートのＩＤを選択し、これを代理ポートＩＤとして、ステップ２３で確保したレコードの代理ポートＩＤ領域１３７ｂに格納する（Ｓ２５）。この際、Ｖルータ１１７は、予め定められている多数のクライアント機能用ポートであって、未使用ポートのうちから、ランダムに一つ選択してもよいし、所定の指針に基づいて一つ選択してもよい。続いて、Ｖルータ１１７は、パケット中の発信元ポートＩＤを、この代理ポートＩＤに書き換える（Ｓ２６）。

例えば、いずれかのＶＭ１２１ａ，１２２ｂからパケットを受け取った時点で、既に、図８に示すように、レコード１３７ｘの原ポートＩＤ領域１３７ａにポートＩＤ「ｐ」が格納されおり、このパケットに関して、ステップ２１で取得した発信元ポートＩＤが「ｐ」である場合、Ｖルータ１１７は、ステップ２３で、例えば、空きレコード１３７ｙの原ポートＩＤ領域１３７ａに、発信元ポートＩＤ「ｐ」を格納する。続いて、ステップ２４では、このパケットの発信元ポートＩＤ「ｐ」は、レコード１３７ｘで既に使用済みであると判断して、ステップ２５において、未使用ポートのＩＤ、例えば、「ｑ」を、レコード１３７ｙの代理ポートＩＤ領域１３７ｂに格納する。そして、ステップ２６において、パケット中の発信元ポートＩＤ「ｐ」を代理ポートＩＤ「ｑ」に書き換える。

一方、Ｖルータ１１７は、ステップ２４で、発信元ポートＩＤが未だ使用されていないと判断すると、この発信元ポートＩＤを、ステップ２３で確保したレコードの代理ポートＩＤ領域１３７ｂに格納する（Ｓ２７）。

例えば、いずれかのＶＭ１２１ａ，１２２ｂからパケットを受け取った時点で、レコード１３７ｘが空きレコードで、いずれのレコードの原ポートＩＤ領域１３７ａにも発信元ポートＩＤ「ｐ」が格納されておらず、このパケットに関して、ステップ２１で取得した発信元ポートＩＤが「ｐ」である場合、Ｖルータ１１７は、ステップ２３で、例えば、空きレコード１３７ｙの原ポートＩＤ領域１３７ａに、発信元ポートＩＤ「ｐ」を格納する。続いて、ステップ２４では、このパケットの発信元ポートＩＤ「ｐ」は未使用であると判断して、ステップ２７において、この発信元ポートＩＤ「ｐ」を、レコード１３７ｘの代理ポートＩＤ領域１３７ｂに格納する。

ステップ２６又はステップ２７の処理が終了すると、Ｖルータ１１７は、ステップ２３で確保したレコードに、ＶＭ ＩＤ及びＴＣＰ/ＵＤＰの区分を格納する（Ｓ２８）。なお、ここで格納されるＶＭ ＩＤは、ステップ２０で取得したＶＭ ＩＤである。また、ＴＣＰ/ＵＤＰの区分は、ステップ２１で、パケットから発信元ポートＩＤの取得に伴い、このパケットの制御フラグ１８（図１２に示す）有無等から判断されたＴＣＰ/ＵＤＰの区分である。

最後に、Ｖルータ１１７は、いずれかのＶＭ１２１ａ，１２２ｂから受け取ったパケット、又はこのパケット中の発信元ポートＩＤのみを書き換えたパケットを、実ネットワークインタフェース１５０を介して、ネットワークＮへ送出する。

なお、以上では、パケット発信元ＶＭのＩＤを取得してから（Ｓ２０）、パケットの発信元ポートＩＤを取得し（Ｓ２１）、この発信元ポートＩＤがクライアント機能用ポートのＩＤであるか否かを判断しているが（Ｓ２２）、先に、パケットの発信元ポートＩＤを取得し、この発信元ポートＩＤがクライアント機能用ポートのＩＤであるか否かを判断してから、パケット発信元ＶＭのＩＤを取得するようにしてもよい。

まず、図１１のフローチャートを用いて、Ｖルータ１１７によるパケット受信時の処理について説明する。

実ネットワークインタフェース１５０が通信ネットワークからパケットを受信すると、Ｖルータ１１７はこのパケットを受け取る。そして、このパケットのＩＰアドレスがＶＭのＩＰアドレスである場合、以下の処理を実行する。

Ｖルータ１１７は、まず、受け取ったパケットから宛先ポートＩＤを取得する（Ｓ３０）。

次に、Ｖルータ１１７は、ＶＭ通信制御テーブル１３７の全レコードの代理ポートＩＤ領域１３７ｂから、ステップ３０で取得した宛先ポートＩＤを検索し（Ｓ３１）、この宛先ポートＩＤがＶＭ通信制御テーブル１３７の代理ポートＩＤ領域１３７ｂにあるか否かを判断する（Ｓ３２）。

Ｖルータ１１７は、この宛先ポートＩＤがあると判断すると、この宛先ポートＩＤが格納されているレコードの原ポートＩＤ領域１３７ａから、ポートＩＤを取得し、このパケットの宛先ポートＩＤを、取得したポートＩＤに書き換える（Ｓ３３）。なお、代理ポートＩＤ領域１３７ｂに格納されているポートＩＤと、原ポートＩＤ領域１３７ａに格納されているポートＩＤとが同一である場合があるが、この場合、パケットの宛先ポートＩＤを、取得したポートＩＤに書き換えてもよいし、書き換えなくてもよい。

続いて、Ｖルータ１１７は、ステップ３４でポートＩＤを取得したレコードのＶＭ ＩＤ領域１３７ｃからＶＭ ＩＤを取得し、このＶＭ ＩＤが示すＶＭへ、ステップ３４で書き直したパケットをルーティングする（Ｓ３４）。このルーティングは、Ｖルータ１１７が、ＶＭ ＩＤに対応するＶＭの仮想ネットワークインタフェースがアクセスするメモリに、ステップ３４で書き直したパケットを格納した後、このＶＭの仮想ネットワークから仮想ネットワークインタフェースに対して割り込みを模擬させることにより、実行される。

パケットのルーティングが終了すると、所定時間経過後に、ステップ３３で原ポートＩＤを取得したレコードを解放して（Ｓ３５）、パケット受信時の処理を終了する。なお、ステップ３５において、パケットのルーティングが終了してから、所定時間経過後に、該当レコードを解放するのは、外部から当該サーバ１００のいずれかのＶＭに対してデータを送信する際、このデータの量が多く、このデータを複数のパケットに分けて送信することがあることから、これらの複数のパケットを該当レコードを参照してルーティングするためである。

例えば、ステップ３０で受け取ったパケット中の宛先ポートＩＤが「ｑ」であり、この時点で、図８に示すように、ＶＭ通信制御テーブル１３７のレコード１３７ｙの代理ポートＩＤ領域１３７ｂに代理ポートＩＤ「ｑ」が格納されている場合には、Ｖルータ１１７は、ステップ３２で、パケット中の宛先ポートＩＤ「ｑ」がＶＭ通信制御テーブル１３７中にあると判断する。そして、Ｖルータ１１７は、ステップ３３で、レコード１３７ｙの原ポートＩＤ領域１３７ａから、ポートＩＤ「ｐ」を取得し、このパケットの宛先ポートＩＤを、取得したポートＩＤ「ｐ」に書き換え、ステップ３４で、レコード１３７ｙのＶＭ ＩＤ領域１３７ｃに格納されているＶＭ ＩＤ「０２」に、宛先ポートＩＤを書き換えたパケットをルーティングする。

ところで、ステップ３２の判断で、パケット中に含まれている宛先ポートＩＤがＶＭ通信制御テーブル１３７のいずれかの代理ポートＩＤ領域１３７ｂにあるということは、以前に、いずれかのＶＭ１２１ａ，１２１ｂ上のＡＰプロセス１２２ａ，１２３ｂが、クライアントとして機能し、外部に対して何らかのサービスのリクエストパケットを送出し、このリクエストパケットに対するレスポンスパケットが外部から戻ってきたことを意味する。この際、外部に送出したリクエストパケット中の発信元ポートＩＤは、代理ポートＩＤであるため、外部からのレスポンスパケット中の宛先ポートＩＤも代理ポートＩＤである。そこで、Ｖルータ１１７は、レスポンスパケットを受け取ると、ステップ３３で、このレスポンスパケット中の宛先ポートＩＤを、リクエストパッケットの当初の発信元ポートＩＤに書き換え、ステップ３４で、この書き換え後のレスポンスパケットを該当ＶＭへルーティングしている。

一方、ステップ３２で、パケット中に含まれている宛先ポートＩＤがＶＭ通信制御テーブル１３７のいずれの代理ポートＩＤ領域１３７ｂにもないと判断された場合、このパケットは、クライアントとして機能していないＡＰプロセス１２２ａ，１２３ｂに対するものであると言える。言い換えると、このパケットは、サーバとして機能しているＡＰプロセス１２２ａ，１２３ｂに対するものであると言える。したがって、このパケット中に含まれている宛先ポートＩＤは、予め定められた多数のサーバ機能用ポートＩＤのうちの一つである。前述したように、第一のＶＭ１２１ａ上のＡＰｘプロセス１２２ａのサーバ機能用ポートのＩＤと、第二のＶＭ１２１ｂ上のＡＰｙプロセス１２３ｂのサーバ機能用ポートのＩＤとは、同一になることはない。このため、このパケットを二つのＶＭ１２１ａ，１２１ｂのそれぞれにルーティングすれば、このパケットの宛先ポートＩＤ（サーバ機能用ポート）が示すＡＰプロセスに、このパケットを確実に受け渡すことができる。

そこで、Ｖルータ１１７は、ステップ３２で、パケット中に含まれている宛先ポートＩＤがＶＭ通信制御テーブル１３７のいずれの代理ポートＩＤ領域１３７ｂにもないと判断した場合、このパケットをまず第一のＶＭ１２１ａへルーティングする（Ｓ３６）。そして、Ｖルータ１１７は、このルーティングが成功あるか否かを判断する（Ｓ３７）。

いずれかのＶＭ１２１ａ，１２１ｂと外部とがＴＣＰに従って通信している場合、適切なパケットを受け取った側は、このパケットの送信側に対してＡＣＫを返すので、パケットがルーティングされたＶＭからＡＣＫが返ってきた場合には、このルーティングが成功したことになる。一方、このパケットがルーティングされたＶＭから、所定時間経過しても、ＡＣＫが返ってこない場合には、このルーティングが失敗したことになる。また、ＵＤＰでは、前述したように、送達確認を行わないので、仮に、パケットのルーティングが成功した場合でも、このパケットがルーティングされたＶＭからＡＣＫ等が返ってくることはない。Ｖルータ１１７は、ステップ３７において、パケットがルーティングされたＶＭから所定時間以内にＡＣＫが返ってこない場合には、このパケットがＴＣＰに従うものであろうが、ＵＤＰに従うものであろうが、一律に失敗と判断し、所定時間以内にＡＣＫが返ってきた場合にのみ、成功と判断する。

Ｖルータ１１７により、ルーティングが成功したと判断された場合、二つのＶＭ１２１ａ，１２１ｂのいずれか一方にのみ存在する目的のＡＰプロセスに、このパケットが受け渡されたことになるので、パケット受信時の処理を終了する。

一方、Ｖルータ１１７は、ステップ３７で、ルーティングが失敗したと判断すると、このパケットを第二のＶＭ１２１ｂへルーティングする（Ｓ３８）。このパケットがＴＣＰに従ったものである場合、ステップ３６での第一のＶＭ１２１ａへのルーティングが失敗であれば、このステップ３８での第二のＶＭ１２１ｂへのルーティングは成功することになる。また、このパケットがＵＤＰに従ったものである場合、ステップ３７において、パケットがルーティングされたＶＭから所定時間以内にＡＣＫが返ってこない場合には、このパケットがＴＣＰに従うものであろうが、ＵＤＰに従うものであろうが、一律に失敗と判断するので、結果として、第一のＶＭ１２１ａにも、第二のＶＭ１２１ｂにも、このパケットをルーティングすることになる。このように、二つのＶＭ１２１ａ，１２１ｂのそれぞれに、このパケットをルーティングすることにより、このパケットは、二つのＶＭ１２１ａ，１２１ｂのいずれか一方にのみ存在する目的のＡＰプロセスに受け渡されたことになる。

よって、Ｖルータ１１７は、ステップ３８で、このパケットを第二のＶＭ１２１ｂにルーティングした場合も、パケット受信時の処理を終了する。

なお、目的のＡＰプロセスが存在しないＶＭに送られたパケットは、このＶＭ内で送り先が存在しないので、このＶＭにおいて、破棄されることになる。

以上のように、本実施形態では、二つのＶＭが同じネットワークアドレスを持つものの、パケット中に含まれている通信ポートを利用し、さらに、代理ポートという概念を導入して、ネットワーク通信を実現している。

なお、以上の実施形態では、Ｖ・ＩＯマネジャ１１６により、保護対象外のＡＰｙプロセス１２３ｂから保護対象のＡＰｘ用ファイル２２２へのアクセスを禁止すると共に、保護対象のＡＰｘ用ファイル２２２とその他のＡＰｙ用ファイル２２３とを異なる実外部記憶装置２１０ａ，２１０ｂに格納することにより、保護対象のＡＰｘ用ファイル２２２をソフトウェア的にもハードウェア的には孤立させることで、この保護対象のＡＰｘ用ファイル２２２の保護を図っている。しかしながら、システム設計指針が、保護対象のＡＰｘ用ファイル２２２をソフトウェア的に保護できれば十分であるとするならば、保護対象のＡＰｘ用ファイル２２２とその他のＡＰｙ用ファイル２２３とを異なる実外部記憶装置２１０ａ，２１０ｂに格納しなくてもよい。

また、以上の実施形態では、外部からのパケットを受信し、このパケット中の宛先ポートＩＤが代理ポート領域にない場合（図１１中のＳ３２）、受信パケットを第一のＶＭ１２１ａへルーティングした後（Ｓ３６）、このルーティングが失敗したと判断したときに限り（Ｓ３７）、受信パケットを第二のＶＭ１２１ｂへルーティングしているが（Ｓ３８）、ルーティングが成功したか失敗したかの判断を行わず、受信パケットを第一のＶＭ１２１ａ及び第二のＶＭ１２１ｂのそれぞれにルーティングするようにしてもよい。

また、以上の実施形態では、保護対象外のＡＰプログラムが一つの例を示しているが、保護対象外のＡＰプログラムが多数存在する場合でも、第二のＶＭ１２１ｂ上で、保護対象外の多数のＡＰプログラムを動作させることで、保護すべきサーバプログラムであるＡＰｘプログラム２１２、及びこのプログラム２１２のファイル資源を、保護対象外の複数のＡＰプログラムに対する側面攻撃から保護することができる。

さらに、以上の実施形態では、保護すべきＡＰプログラムが一つの例を示しているが、保護すべきＡＰプログラムが複数存在する場合でも、保護すべきＡＰプログラム毎にＶＭを設けて、保護すべきＡＰプログラムのそれぞれを他のＡＰプログラムの動作環境から孤立させることで、保護すべきＡＰプログラムのそれぞれを、他のＡＰプログラムに対する側面攻撃から保護することができる。

本発明に係る一実施形態におけるサーバのハードウェア構成図である。 本発明に係る一実施形態におけるサーバの機能構成図である。 本発明に係る一実施形態における、サーバプログラムの保護状態への移行過程（その１）でのサーバの機能構成図である。 本発明に係る一実施形態における、サーバプログラムの保護状態への移行過程（その２）でのサーバの機能構成図である。 本発明に係る一実施形態におけるサーバプログラムの保護状態への移行過程（その３）でのサーバの機能構成図である。 本発明に係る一実施形態におけるサーバプログラムの保護状態での通信制御を説明するための、サーバの機能構成図である。 本発明に係る一実施形態におけるＶＭ管理テーブルのデータ構成を示す説明図である。 本発明に係る一実施形態におけるＶＭ通信制御テーブルのデータ構成を示す説明図である。 本発明に係る一実施形態におけるサーバプログラムの保護状態への移行処理を示すフローチャートである。 本発明に係る一実施形態における保護状態におけるパケット送出時の処理を示すフローチャートである。 本発明に係る一実施形態における保護状態におけるパケット受信時の処理を示すフローチャートである。 ＴＣＰ（ＵＤＰ）／ＩＰパケットの構成を示す説明図である。

符号の説明

１００…サーバ、１０１…サーバ本体、１１０…ＣＰＵ、１１１…ＶＭＭ、１１２…ＶＭイニシャライザ、１１３…ＶＭディスパチャ、１１４…マイグレーションマネジャ、１１５…ＡＰセパレータ、１１６…Ｖ・ＩＯマネジャ、１１６…Ｖルータ、１２０…メモリ、１２１ａ…第一のＶＭ、１２１ｂ…第二のＶＭ、１２２ａ，１２２ｂ…ＡＰｘプロセス、１２３ａ，１２３ｂ…ＡＰｙプロセス、１２４ａ，１２４ｂ…ＯＳプロセス、１２５ａ，１２５ｂ…仮想ＩＯインタフェース、１２６ａ，１２６ｂ…仮想外部記憶装置、１２７ａ，１２７ｂ…仮想ネットワークインタフェース、１３０…ＣＰＵ・メモリ、１３３…ＶＭ管理テーブル、１３４…現ＶＭ ＩＤ領域、１３７…ＶＭ通信制御テーブル、１４０…ＩＤインタフェース、１５０…ネットワークインタフェース、１６０…ディスク記録・再生装置、２０１…表示装置、２０２…入力装置、２１０…第三の外部記憶装置、２１０ａ…第一の外部記憶装置、２１０ｂ…第二の外部記憶装置、２１１…ＶＭＭプログラム、２１２…ＡＰｘプログラム、２１３…ＡＰｙプログラム、２１４…ＯＳプログラム

Claims (11)

1. オペレーティングシステム（以下、ＯＳとする）プログラム、及び特に保護すべき特定のアプリケーションプログラムを含む複数のアプリケーション（以下、ＡＰとする）プログラムを実行するため、記憶装置を備えたコンピュータ上に、仮想計算機を現出させる仮想計算機プログラムにおいて、
   前記コンピュータ上に第一の仮想計算機を現出させ、該第一の仮想計算機上で、前記ＯＳプログラム及び前記複数のＡＰプログラムを起動させて、該第一の仮想計算機上にＯＳプロセス及び複数のＡＰプロセスを展開させる第一の仮想計算機現出ステップと、
   前記ＯＳプロセス及び記複数のＡＰプロセスが展開している前記第一の仮想計算機をプロセスコピーして、前記コンピュータ上に、該複数のＡＰプロセス及び該ＯＳプロセスが展開している第二の仮想計算機を現出させる第二の仮想計算機現出ステップと、
   前記記憶装置に予め格納されていた各ＡＰ用のデータファイルのうち、特定のＡＰプロセスが利用するファイルには、前記第一の仮想計算機からのアクセスを認め、前記第二の仮想計算機からのアクセスを認めず、前記複数のＡＰプロセスのうち該特定のＡＰプロセスを除く他のＡＰプロセスが利用するファイルには、該第二の仮想計算機からのアクセスを認める入出力制御ステップと、
   前記第一の仮想計算機上の前記複数のＡＰプロセスのうち、前記他のＡＰプロセスを稼動不能にすると共に、前記第二の仮想計算機上の複数のＡＰプロセスのうちの前記特定のＡＰプロセスを稼動不能にするＡＰセパレーションステップと、
   を前記コンピュータに実行させることを特徴とする仮想計算機プログラム。
2. 請求項１に記載の仮想計算機プログラムにおいて、
   前記入出力制御ステップでは、
   前記記憶装置に格納されているファイルのうち、前記他のＡＰプロセスが利用するファイルには、前記第一の仮想計算機からのアクセスを認めない、
   ことを特徴とする仮想計算機プログラム。
3. 請求項１及び２のいずれか一項に記載の仮想計算機プログラムにおいて、
   前記第一の仮想計算機及び前記第二の仮想計算機が、宛先ポートＩＤ及び発信元ポートＩＤが格納されているＩＰ（Internet Protocol）パケットを用いて、前記実ネットワークインタフェースを介して、外部と通信するための通信制御ステップを、前記コンピュータに実行させ、
   前記通信制御ステップでは、
   前記実ネットワークインタフェースが受信した前記ＩＰパケットから宛先ポートＩＤを取得する宛先ポートＩＤ取得ステップと、
   前記宛先ポートＩＤ取得ステップで取得された前記宛先ポートＩＤが、予め定められた複数のサーバ機能用ポートＩＤのうちの一つであるか否かを判断する宛先ポートＩＤ判断ステップと、
   前記宛先ポートＩＤ判断ステップで、前記宛先ポートＩＤが前記予め定められた複数のサーバ機能用ポートＩＤのうちの一つであると判断された場合、前記第一の仮想計算機と前記第二の仮想計算機とのそれぞれに、前記ＩＰパケットをルーティングする、又は、該第一の仮想計算機と該第二の仮想計算機とのうち、一方の仮想計算機へ前記ＩＰパケットをルーティングした後、該ルーティングが成功したか否かを判断して、該ルーティングが成功しなかったと判断した場合に、他方の仮想計算機へ該ＩＰパケットをルーティングするルーティングステップと、
   前記第一の仮想計算機と前記第二の仮想計算機とのうち、いずれかの仮想計算機から外部へ送出するＩＰパケットを受信すると、該ＩＰパケットを前記実ネットワークインタフェースを介して、外部へ送出するパケット送出ステップと、
   を前記コンピュータに実行させることを特徴とする仮想計算機プログラム。
4. 請求項３に記載の仮想計算機プログラムにおいて、
   前記通信制御ステップでは、
   前記第一の仮想計算機と前記第二の仮想計算機とのうち、いずれかの仮想計算機から外部へ送出するＩＰパケットを受信すると、該ＩＰパケットから発信元ポートＩＤを取得する発信元ポートＩＤ取得ステップと、
   前記発信元ポートＩＤ取得ステップで取得された前記発信元ポートＩＤが、予め定められた複数のサーバ機能用ポートＩＤのうちの一つであるか否かを判断する発信元ポートＩＤ判断ステップと、
   を前記コンピュータに実行させ、
   前記パケット送出ステップでは、前記発信元ポートＩＤ判断ステップで、前記発信元ポートＩＤが前記予め定められた複数のサーバ機能用ポートＩＤのうちの一つであると判断された場合、前記いずれかの仮想計算機から受信した前記ＩＰパケットを前記実ネットワークインタフェースを介して、外部へ送出する、
   ことを特徴とする仮想計算機プログラム。
5. 請求項４に記載の仮想計算機プログラムにおいて、
   前記いずれかの仮想計算機から受信した前記ＩＰパケット中の発信元ポートＩＤが格納される原ポートＩＤ領域と、該原ポートＩＤに格納されたポートＩＤの代理ポートＩＤが格納される代理ポートＩＤ領域と、該ＩＰパケットを送出した仮想計算機のＩＤが格納される仮想計算機ＩＤ領域とを有するテーブルを、前記コンピュータのメモリ上に、予め設定させておき、
   前記通信制御ステップでは、
   前記いずれかの仮想計算機から外部へ送出するＩＰパケットを受信した場合、
   前記発信元ポートＩＤ判断ステップでは、前記発信元ポートＩＤが前記予め定められた複数のサーバ機能用ポートＩＤのうちの一つではなく、予め定められた複数のクライアント機能用ポートＩＤのうちの一つであるか否かを判断し、
   前記発信元ポートＩＤ判断ステップで、前記発信元ポートＩＤが前記予め定められた複数のクライアント機能用ポートＩＤのうちの一つであると判断された場合、前記テーブル中の空きレコードであって、前記原ポートＩＤ領域に該発信元ポートＩＤを原ポートＩＤとして格納する原ポートＩＤ格納ステップと、
   前記発信元ポートＩＤが前記テーブル中の前記代理ポートＩＤ領域に既に格納されているか否かを判断する判断ステップと、
   前記判断ステップで、前記発信元ポートＩＤが前記代理ポートＩＤ領域に既に格納されていないと判断された場合には、前記原ポートＩＤと関連付けて、該発信元ポートＩＤを代理ポートＩＤとして前記代理ポートＩＤ領域に格納する第一の代理ポートＩＤ格納ステップと、
   前記判断ステップで、前記発信元ポートＩＤが前記代理ポートＩＤ領域に既に格納されていると判断された場合には、前記予め定められた複数のクライアント機能用ポートＩＤのうちから未格納ポートＩＤを代理ポートＩＤとして、前記代理ポートＩＤ領域に前記原ポートＩＤと関連付けて格納する第ニの代理ポートＩＤ格納ステップと、
   前記第二の代理ポートＩＤ格納ステップで、前記未格納ポートＩＤが前記代理ポートＩＤとして格納されると、前記ＩＰパケット中の前記発信元ポートＩＤを該代理ポートＩＤに書き換える発信元ポートＩＤ書換えステップと、
   前記ＩＰパケットを送出した前記いずれかの仮想計算機のＩＤを、前記原ポートＩＤと関連付けて前記仮想計算機ＩＤ領域に格納する仮想計算機ＩＤ格納ステップと、
   を前記コンピュータに実行させ、
   前記パケット送出ステップでは、前記第一の代理ポートＩＤ格納ステップで、前記発信元ポートＩＤが前記代理ポートとして格納された場合には、前記いずれかの仮想計算機から送出された前記ＩＰパケットを外部へ送出し、前記第二の代理ポートＩＤ格納ステップで、前記未格納ポートＩＤが前記代理ポートＩＤとして格納された場合には、前記発信元ポートＩＤ書換えステップで前記発信元ポートＩＤが書換えられた前記ＩＰパケットを外部へ送出し、
   前記実ネットワークインタフェースが外部からＩＰパケットを受信した場合、
   前記宛先ポートＩＤ判断ステップでは、前記宛先ポートＩＤ取得ステップで取得された前記宛先ポートＩＤが、前記予め定められた複数のサーバ機能用ポートＩＤのうちの一つではなく、前記テーブルの前記代理ポートＩＤ領域に格納されたポートＩＤであるか否かを判断し、
   前記宛先ポートＩＤ判断ステップで、前記宛先ポートＩＤ取得ステップで取得された前記宛先ポートＩＤが、前記テーブルの前記代理ポートＩＤ領域に格納されたポートＩＤであると判断されると、外部から受信した前記ＩＤパケット中の宛先ポートＩＤを、該テーブル中で該代理ポートＩＤ領域に格納された該ポートＩＤと関連付けられている前記原ポートＩＤに書換える宛先ポートＩＤ書換えステップと、
   前記宛先ポートＩＤが書換えられた前記ＩＤパケットを、前記テーブル中で前記代理ポート領域に格納された前記ポートＩＤと関連付けられている仮想計算機ＩＤが示す仮想計算機へルーティングするルーティングステップと、
   を前記コンピュータに実行させることを特徴とする仮想計算機プログラム。
6. オペレーティングシステム（以下、ＯＳとする）プログラム、及び特に保護すべき特定のアプリケーションプログラムを含む複数のアプリケーション（以下、ＡＰとする）プログラムを実行するため、記憶装置を備えたコンピュータ上に、仮想計算機を現出させる仮想計算機の現出方法において、
   前記コンピュータ上に第一の仮想計算機を現出させ、該第一の仮想計算機上で、前記ＯＳプログラム及び前記複数のＡＰプログラムを起動させて、該第一の仮想計算機上にＯＳプロセス及び複数のＡＰプロセスを展開させる第一の仮想計算機現出ステップと、
   前記ＯＳプロセス及び記複数のＡＰプロセスが展開している前記第一の仮想計算機をプロセスコピーして、前記コンピュータ上に、該複数のＡＰプロセス及び該ＯＳプロセスが展開している第二の仮想計算機を現出させる第二の仮想計算機現出ステップと、
   前記記憶装置に予め格納されていた各ＡＰ用のデータファイルのうち、特定のＡＰプロセスが利用するファイルには、前記第一の仮想計算機からのアクセスを認め、前記第二の仮想計算機からのアクセスを認めず、前記複数のＡＰプロセスのうち該特定のＡＰプロセスを除く他のＡＰプロセスが利用するファイルには、該第二の仮想計算機からのアクセスを認める入出力制御ステップと、
   前記第一の仮想計算機上の前記複数のＡＰプロセスのうち、前記他のＡＰプロセスを稼動不能にすると共に、前記第二の仮想計算機上の複数のＡＰプロセスのうちの前記特定のＡＰプロセスを稼動不能にするＡＰセパレーションステップと、
   を前記コンピュータが実行することを特徴とする仮想計算機の現出方法。
7. 請求項６に記載の仮想計算機の現出方法において、
   前記入出力制御ステップでは、
   前記記憶装置に格納されているファイルのうち、前記他のＡＰプロセスが利用するファイルには、前記第一の仮想計算機からのアクセスを認めない、
   ことを特徴とする仮想計算機の現出方法。
8. 演算装置とメモリと外部記憶装置と外部とネットワーク通信するためのネットワークインタフェースとを備え、オペレーティングシステム（以下、ＯＳとする）、サーバプログラム及び１以上のアプリケーション（以下、ＡＰとする）プログラムを実行するために、仮想計算機を現出させるサーバにおいて、
   前記演算装置及び前記メモリ上に、第一の仮想計算機を現出させ、該第一の仮想計算機上で、前記ＯＳプログラム及び前記サーバプログラムを起動させて、該第一の仮想計算機上に、ＯＳプロセス及びサーバプロセスを展開させる第一の仮想計算機現出手段と、
   前記演算装置及び前記メモリ上に、第二の仮想計算機を現出させ、該第二の計算機上で、前記ＯＳプログラム及び前記１以上のＡＰプログラムを起動させて、該第二の計算機上に、ＯＳプロセス及び１以上のＡＰプロセスを展開させる第二の仮想計算機現出手段と、
   前記外部記憶装置に予め格納されていたデータファイルのうち、前記サーバプロセスが利用するファイルには、前記第一の仮想計算機からのアクセスを認め、前記第二の仮想計算機からのアクセスを認めず、前記１以上のＡＰプロセスが利用するファイルには、該第二の仮想計算機からのアクセスを認める入出力制御手段と、
   前記第一の仮想計算機及び前記第二の仮想計算機が、宛先ポートＩＤ及び発信元ポートＩＤが格納されているＩＰ（Internet Protocol）パケットを用いて、前記ネットワークインタフェースを介して、外部と通信するための通信制御手段と、
   を備え、
   前記通信制御手段は、
   外部から前記ネットワークインタフェースが受信した前記ＩＰパケットから宛先ポートＩＤを取得する宛先ポートＩＤ手段と、
   前記宛先ポートＩＤ取得手段で取得した前記宛先ポートＩＤが、予め定められた複数のサーバ機能用ポートＩＤのうちの一つであるか否かを判断する宛先ポートＩＤ判断手段と、
   前記宛先ポートＩＤ判断手段で、前記宛先ポートＩＤが前記予め定められた複数のサーバ機能用ポートＩＤのうちの一つであると判断された場合、前記第一の仮想計算機と前記第二の仮想計算機とのそれぞれに、前記ＩＰパケットをルーティングする、又は、該第一の仮想計算機と該第二の仮想計算機とのうち、一方の仮想計算機へ前記ＩＰパケットをルーティングした後、該ルーティングが成功したか否かを判断して、該ルーティングが成功しなかったと判断した場合に、他方の仮想計算機へ該ＩＰパケットをルーティングするルーティング手段と、
   前記第一の仮想計算機と前記第二の仮想計算機とのうち、いずれかの仮想計算機から外部へ送出するＩＰパケットを受信すると、該ＩＰパケットを前記ネットワークインタフェースを介して、外部へ送出するパケット送出手段と、
   を有することを特徴とするサーバ。
9. 請求項８に記載のサーバにおいて、
   前記入出力制御手段は、
   前記外部記憶装置に格納されているファイルのうち、前記１以上のＡＰプロセスが利用するファイルには、前記第一の仮想計算機からのアクセスを認めない、
   ことを特徴とするサーバ。
10. 請求項８及び９のいずれか一項に記載のサーバにおいて、
    物理的に互いに独立している複数の外部記憶装置を備え、
    前記サーバプロセスが利用するファイルと、前記１以上のＡＰプロセスが利用するファイルとは、前記複数の外部記憶装置のうちの互いに異なる外部記憶装置に格納されている、
    ことを特徴とするサーバ。
11. 請求項８から１０のいずれか一項に記載のサーバにおいて、
    前記第一の仮想計算機と前記第二の仮想計算機とのうち、いずれかの仮想計算機から受信したＩＰパケット中の発信元ポートＩＤが格納される原ポートＩＤ領域と、該原ポートＩＤに格納されたポートＩＤの代理ポートＩＤが格納される代理ポートＩＤ領域と、該ＩＰパケットを送出した仮想計算機のＩＤが格納される仮想計算機ＩＤ領域とを有するテーブルを、メモリ上に設定するテーブル設定手段を備え、
    前記通信制御手段は、前記いずれかの仮想計算機から外部へ送出するＩＰパケットを受信した際の手段として、
    前記外部へ送出するＩＰパケットから発信元ポートＩＤを取得する発信元ポートＩＤ取得手段と、
    前記発信元ポートＩＤ取得手段で取得した前記発信元ポートＩＤが、予め定められた複数のサーバ機能用ポートＩＤのうちの一つであるか、該予め定められた複数のサーバ機能用ポートＩＤのうちの一つではなく、予め定められた複数のクライアント機能用ポートＩＤのうちの一つであるかを判断する発信元ポートＩＤ判断ステップと、
    前記発信元ポートＩＤ判断手段で、前記発信元ポートＩＤが前記予め定められた複数のクライアント機能用ポートＩＤのうちの一つであると判断した場合、前記テーブル中の空きレコードであって、前記原ポートＩＤ領域に該発信元ポートＩＤを原ポートＩＤとして格納する原ポートＩＤ格納手段と、
    前記発信元ポートＩＤが前記テーブル中の前記代理ポートＩＤ領域に既に格納されているか否かを判断する判断手段と、
    前記判断手段で、前記発信元ポートＩＤが前記代理ポートＩＤ領域に既に格納されていないと判断した場合には、前記原ポートＩＤと関連付けて、該発信元ポートＩＤを代理ポートＩＤとして前記代理ポートＩＤ領域に格納する第一の代理ポートＩＤ格納手段と、
    前記判断手段で、前記発信元ポートＩＤが前記代理ポートＩＤ領域に既に格納されていると判断した場合には、前記予め定められた複数のクライアント機能用ポートＩＤのうちから未格納ポートＩＤを代理ポートＩＤとして、前記代理ポートＩＤ領域に前記原ポートＩＤと関連付けて格納する第ニの代理ポートＩＤ格納手段と、
    前記第二の代理ポートＩＤ格納手段で、前記未格納ポートＩＤが前記代理ポートＩＤとして格納されると、前記ＩＰパケット中の前記発信元ポートＩＤを該代理ポートＩＤに書き換える発信元ポートＩＤ書換え手段と、
    前記ＩＰパケットを送出した前記いずれかの仮想計算機のＩＤを、前記原ポートＩＤと関連付けて前記仮想計算機ＩＤ領域に格納する仮想計算機ＩＤ格納ステップと、
    を有し、
    前記パケット送出手段は、前記第一の代理ポートＩＤ格納手段で、前記発信元ポートＩＤが前記代理ポートとして格納された場合には、前記いずれかの仮想計算機から送出された前記ＩＰパケットを外部へ送出し、前記第二の代理ポートＩＤ格納手段で、前記未格納ポートＩＤが前記代理ポートＩＤとして格納された場合には、前記発信元ポートＩＤ書換え手段で前記発信元ポートＩＤが書換えられた前記ＩＰパケットを外部へ送出し、
    前記通信制御手段は、前記いずれかの仮想計算機から外部へ送出するＩＰパケットを受信した際、
    前記宛先ポートＩＤ判断手段が、前記宛先ポートＩＤ取得手段で取得した前記宛先ポートＩＤが、前記予め定められた複数のサーバ機能用ポートＩＤのうちの一つではなく、前記テーブルの前記代理ポートＩＤ領域に格納されたポートＩＤであるか否かを判断し、
    前記宛先ポートＩＤ判断手段で、前記宛先ポートＩＤ取得ステップで取得された前記宛先ポートＩＤが、前記テーブルの前記代理ポートＩＤ領域に格納されたポートＩＤであると判断されると、外部から受信した前記ＩＤパケット中の宛先ポートＩＤを、該テーブル中で該代理ポートＩＤ領域に格納された該ポートＩＤと関連付けられている原ポートＩＤに書換える宛先ポートＩＤ書換え手段と、
    前記宛先ポートＩＤが書換えられた前記ＩＤパケットを、前記テーブル中で前記代理ポート領域に格納された前記ポートＩＤと関連付けられている仮想計算機ＩＤが示す仮想計算機へルーティングするルーティング手段と、
    を有する、
    ことを特徴とするサーバ。

Images