JP6162611B2 - 通信制御サーバ、通信制御方法、及びプログラム - Google Patents

Description

本発明は、通信制御サーバ、通信制御方法、及びプログラムに関する。

従来から、ユーザが操作するユーザ端末と、通信対象の対象サーバと、の通信を仲介する技術が知られている。特許文献１には、ユーザＩＤとパスワードをユーザ端末から取得してログイン処理を実行し、ユーザ端末と対象サーバとの通信を中継する通信制御サーバが記載されている。更に、特許文献１には、通信制御サーバと対象サーバとの接続は、予め確立されていてもよいし、上記ログイン処理が実行された後に確立してもよいことが記載されている。

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

上記のような技術では、通信制御サーバが、対象サーバへの認証に必要な認証情報を管理することがある。この場合、第三者への漏えい及び不正アクセスを防止するために、認証情報を暗号化しておき、認証時に復号化させることが考えられる。セキュリティ面を考えると、復号化した認証情報をそのままずっと残しておくのは好ましくないが、その一方で、復号化した認証情報を認証直後に削除してしまうと、その後の通信で必要になったときにすぐに使用することができない。

本発明は上記課題に鑑みてなされたものであって、その目的は、セキュリティを担保しつつ、必要な場面で認証情報をすぐに使用することが可能な通信制御サーバ、通信制御方法、及びプログラムを提供することにある。

上記課題を解決するために、本発明に係る通信制御サーバは、ユーザが操作するユーザ端末と、通信対象の対象サーバと、の通信を仲介する通信制御サーバであって、前記対象サーバへ通信するための認証に必要な認証情報を、認証ができない状態で記憶する手段の記憶内容を取得する取得手段と、前記対象サーバへ通信する要求を前記ユーザ端末から受け付けた場合に、前記認証ができない状態の認証情報を認証ができる状態に変化させて認証を行い、その状態を保持する状態変化手段と、前記ユーザ端末と前記対象サーバとの通信が終了した場合に、前記保持されている状態を認証ができない状態に戻す終了制御手段と、を含むことを特徴とする。

本発明に係る通信制御方法は、ユーザが操作するユーザ端末と、通信対象の対象サーバと、の通信を仲介する通信制御方法であって、前記対象サーバへ通信するための認証に必要な認証情報を、認証ができない状態で記憶する手段の記憶内容を取得する取得ステップと、前記対象サーバへ通信する要求を前記ユーザ端末から受け付けた場合に、前記認証ができない状態の認証情報を認証ができる状態に変化させて認証を行い、その状態を保持する状態変化ステップと、前記ユーザ端末と前記対象サーバとの通信が終了した場合に、前記保持されている状態を認証ができない状態に戻す終了制御ステップと、を含むことを特徴とする。

本発明に係るプログラムは、ユーザが操作するユーザ端末と、通信対象の対象サーバと、の通信を仲介するコンピュータを、前記対象サーバへ通信するための認証に必要な認証情報を、認証ができない状態で記憶する手段の記憶内容を取得する取得手段、前記対象サーバへ通信する要求を前記ユーザ端末から受け付けた場合に、前記認証ができない状態の認証情報を認証ができる状態に変化させて認証を行い、その状態を保持する状態変化手段、前記ユーザ端末と前記対象サーバとの通信が終了した場合に、前記保持されている状態を認証ができない状態に戻す終了制御手段、として機能させる。

また、本発明の一態様では、認証ができない状態とは、前記認証情報が暗号化された状態であり、認証ができる状態とは、前記認証情報が復号化された状態であり、前記取得手段は、暗号化された前記認証情報を取得し、前記状態変化手段は、暗号化された前記認証情報を復号化して認証を行い、当該復号化された認証情報を記憶手段に保持し、前記終了制御手段は、前記ユーザ端末と前記対象サーバとの通信が終了した場合に、前記記憶手段に保持されている、復号化された前記認証情報を削除する、ことを特徴とする。

また、本発明の一態様では、前記ユーザ端末と前記対象サーバとの通信は、複数のコネクションを同時に確立することが可能であり、前記終了制御手段は、確立された全てのコネクションが終了した場合に、認証ができない状態に戻す、ことを特徴とする。

また、本発明の一態様では、前記通信制御サーバは、予め定められたタイミングが到来した場合に、前記ユーザにより所定のプロセスが起動しているか否かを判定することによって、前記ユーザ端末と前記対象サーバとの通信が終了したか否かを判定する判定手段を更に含むことを特徴とする。

また、本発明の一態様では、前記対象サーバは、複数のユーザによる通信が可能であり、前記状態変化手段は、前記要求をしたユーザが前記対象サーバと通信するための認証を行い、そのユーザに関連付けて認証ができる状態を保持し、前記終了制御手段は、何れかのユーザの前記ユーザ端末と前記対象サーバとの通信が終了した場合に、当該ユーザに関連付けられて保持されている状態を認証ができない状態に戻す、ことを特徴とする。

本発明によれば、セキュリティを担保しつつ、必要な場面で認証情報をすぐに使用することが可能になる。

情報処理システムの全体構成の一例を示す図である。 情報処理システムで実現される機能を示す機能ブロック図である。 コンフィグデータのデータ格納例を示す図である。 情報処理システムで実行される処理を示す図である。 情報処理システムで実行される処理を示す図である。 コンソール画面の一例を示す図である。 復号化ルーチンの一例を示す図である。 削除ルーチンの一例を示す図である。

［１．情報処理システムのハードウェア構成］
以下、本発明の実施形態の例について図面に基づき詳細に説明する。本実施形態では、本発明に係る通信制御サーバを、例えば、クラウドコンピューティングを用いた情報処理システムに適用した場合について説明する。

図１は、情報処理システムの全体構成の一例を示す図である。図１に示すように、情報処理システム１は、通信制御サーバ１０、複数のユーザ端末２０、及び複数の対象サーバ３０を含む。これら各コンピュータは、ネットワークを介してデータ送受信可能に接続されている。

通信制御サーバ１０は、ユーザ端末２０と対象サーバ３０との通信を仲介するサーバコンピュータであり、例えば、所与のプロトコル（例えば、ＳＳＨ：Secure Shell）のもとで暗号化された各種情報を送受信する。即ち、ユーザ端末２０は、通信制御サーバ１０を経由して対象サーバ３０にアクセスすることになり、対象サーバ３０と直接的にアクセスすることができないようになっている。

図１に示すように、通信制御サーバ１０は、制御部１１、記憶部１２、及び通信部１３を含む。制御部１１は、例えば、一又は複数のマイクロプロセッサを含む。制御部１１は、記憶部１２に記憶されたオペレーティングシステムやプログラムに従って各種処理を実行する。記憶部１２は、主記憶部及び補助記憶部を含む。例えば、主記憶部はＲＡＭであり、補助記憶部は、ハードディスク又はソリッドステートドライブ等である。通信部１３は、ネットワークカードを含む。通信部１３は、ネットワークを介してデータ通信を行うためのものである。

なお、通信制御サーバ１０は、コンピュータ読み取り可能な情報記憶媒体（例えば、メモリカード）に記憶されたプログラムやデータを読み出すための構成要素（例えば、メモリカードスロット）を含むようにしてもよい。また、本実施形態において、記憶部１２に記憶されるものとして説明するプログラムやデータは、通信部１３を介して外部コンピュータから記憶部１２に供給されるようにしてもよい。

ユーザ端末２０は、ユーザが操作するコンピュータであり、例えば、パーソナルコンピュータやタブレット型端末等である。なお、本実施形態では、対象サーバ３０に実行させるコマンドを入力する作業者（例えば、メンテナンスを行う特権ユーザやシステムエンジニア）が、ユーザに相当する。図１に示すように、ユーザ端末２０は、制御部２１、記憶部２２、通信部２３、操作部２４、及び表示部２５を含む。なお、制御部２１、記憶部２２、及び通信部２３のハードウェア構成は、制御部１１、記憶部１２、及び通信部１３と同様であるので説明を省略する。

操作部２４は、公知の入力デバイスであり、例えば、マウスやキーボード、タッチパネル等である。操作部２４は、ユーザによる操作内容を制御部２１に伝達する。表示部２５は、例えば、液晶表示部又は有機ＥＬ表示部等である。表示部２５は、制御部２１の指示に従って画面を表示する。

対象サーバ３０は、通信対象のサーバコンピュータである。対象サーバ３０は、複数のユーザよるアクセスが可能であり、各ユーザが入力したコマンドを実行する。図１に示すように、対象サーバ３０は、制御部３１、記憶部３２、及び通信部３３を含む。制御部３１、記憶部３２、及び通信部３３のハードウェア構成は、制御部１１、記憶部１２、及び通信部１３と略同様であるので説明を省略する。例えば、情報処理システム１の利用者が利用するアプリケーションや各種データは、各対象サーバ３０の記憶部３２で管理される。各利用者は、対象サーバ３０にアクセスして、これらアプリケーションや各種データを利用する。

情報処理システム１では、各ユーザは、いったん通信制御サーバ１０にログインし、その後に通信制御サーバ１０を介して対象サーバ３０にログインする。これは、例えば、暗号化通信では、ユーザの入力内容やコマンドの実行結果等も暗号化されているので、通信制御サーバ１０が、通信プロトコルをいったん終了して復号化を行うことで、ユーザの操作ログを確実に取得するためである。

通信制御サーバ１０は、セキュリティ担保のために、ユーザが対象サーバ３０にログインする際に必要な認証キーを暗号化した状態で管理している。ユーザが対象サーバ３０にログインする場合に、通信制御サーバ１０は、その暗号化された認証キーを復号化して認証を行う。更に、通信制御サーバ１０は、復号化した認証キーをすぐに削除せず、記憶部１２に保持しておく。

このため、その後の通信で、復号化した認証キーが必要な場面（例えば、ＳＦＴＰ（SSH File Transfer Protocol）の利用時）になったときに、すぐに使用できるようになっている。ただし、復号化した認証キーをそのままずっと残しておくとセキュリティが担保できない可能性があるので、通信制御サーバ１０は、ユーザが対象サーバ３０から完全にログアウトした場合に、復号化した認証キーを記憶部１２から削除する構成になっている。以降、当該技術の詳細について説明する。

［２．情報処理システムにおいて実現される機能］
図２は、情報処理システム１で実現される機能を示す機能ブロック図である。図２に示すように、通信制御サーバ１０では、データ記憶部１０１、第１通信制御部１０２、取得部１０３、状態変化部１０４を含む第２通信制御部１０５、判定部１０６、及び終了制御部１０７が実現される。また、ユーザ端末２０では、データ記憶部２０１及び第１通信制御部２０２が実現される。更に、対象サーバ３０では、データ記憶部３０１及び第２通信制御部３０２が実現される。

データ記憶部１０１，２０１，３０１は、それぞれ、記憶部１２，２２，３２を主として実現される。第１通信制御部１０２及び第２通信制御部１０５は、制御部１１及び通信部１３を主として実現され、取得部１０３、状態変化部１０４、判定部１０６、及び終了制御部１０７は、制御部１１を主として実現される。第１通信制御部２０２は、制御部２１及び通信部２３を主として実現され、第２通信制御部３０２は、制御部３１及び通信部３３を主として実現される。

本実施形態では、ユーザ端末２０と通信制御サーバ１０と間で第１の通信が確立された後に、通信制御サーバ１０と対象サーバ３０との間で第２の通信が確立されるので、ここでは、第１の通信及び第２の通信のそれぞれを実現するための機能について、順番に説明する。

［第１の通信］
まず、第１の通信を実現するための各機能について説明する。本実施形態では、第１の通信は、第１の暗号鍵が用いられる暗号化通信であり、例えば、ＳＳＨを用いた通信である。

ユーザ端末２０のデータ記憶部２０１は、通信制御サーバ１０と第１の通信を行うために必要な情報を記憶する。例えば、データ記憶部２０１は、通信制御サーバ１０の名称やＩＰアドレスと、通信制御サーバ１０の公開鍵と、を関連付けたknown-hostファイルや、通信制御サーバ１０への認証に必要な認証キー（証明書又は秘密鍵）を記憶する。

通信制御サーバ１０のデータ記憶部１０１は、ユーザ端末２０と第１の通信を行うために必要な情報（例えば、公開鍵や秘密鍵等の認証情報）を記憶する。例えば、通信制御サーバ１０のデータ記憶部１０１は、通信制御サーバ１０へのログインアカウントやその認証キーを記憶する。

ユーザ端末２０の第１通信制御部２０２は、通信制御サーバ１０との間で第１の通信（例えば、ＳＳＨ）を確立する。通信制御サーバ１０の第１通信制御部１０２は、ユーザ端末２０との間で、第１の通信を確立する。本実施形態では、通信制御サーバ１０の第１通信制御部１０２は、ＳＳＨデーモンに相当し、ユーザ端末２０の第１通信制御部２０２は、ＳＳＨクライアントに相当する。

通信制御サーバ１０の第１通信制御部１０２と、ユーザ端末２０の第１通信制御部２０２と、の間で暗号化通信を行う方法は、プロトコル（ここでは、ＳＳＨ）で規定されている方法に従って実行される。例えば、ユーザがＳＳＨを利用して通信制御サーバ１０にログインするためには、下記に説明するように、ＳＳＨで規定されたホスト認証とユーザ認証とが行われる。

ホスト認証は、通信制御サーバ１０が本当にユーザのログインしたいサーバであるかどうかを確認するために行われる。例えば、ユーザ端末２０の第１通信制御部２０２は、known-hostファイルに格納された公開鍵と、通信制御サーバ１０の第１通信制御部１０２から送られてくる公開鍵と、を照合することによって、ホスト認証を行う。

ユーザ認証は、ユーザが通信制御サーバ１０にログインできるかどうかを確認するためのものである。ここでは、公開鍵認証方式が用いられる場合を説明するが、パスワード認証方式等の他の方式が用いられてもよい。例えば、ユーザが通信制御サーバ１０へのログインアカウントを入力すると、通信制御サーバ１０の第１通信制御部１０２とユーザ端末２０の第１通信制御部２０２との間で電子署名方式やチャレンジアンドレスポンス方式等を用いて、ユーザ端末２０が正当な認証キーを保有していることが検証される。ユーザ端末２０が正当な認証キーを保有していることが確認された場合、通信制御サーバ１０の第１通信制御部１０２は、ユーザによるログインを許可し、第１の通信が確立する。なお、ユーザ認証では、認証キーのファイルにパスフレーズが設定されていたり認証エージェントが用いられたりするようにしてもよい。

［第２の通信］
次に、第２の通信を実現するための各機能について説明する。ここでは、第２の通信は、第１の暗号鍵とは異なる第２の暗号鍵が用いられる第２の暗号化通信であり、例えば、ＳＳＨを用いた通信である。本実施形態では、第１の通信と第２の通信は、接続元と接続先の組み合わせだけではなく、それぞれの通信で用いられる鍵が異なっている。

通信制御サーバ１０のデータ記憶部１０１は、各対象サーバ３０へ通信するための認証に必要な認証キーを、暗号化した状態で記憶する。暗号化方式自体は、公知の種々の暗号化アルゴリズムを適用可能であり、例えば、ＲＣ４（ＡＲＣＦＯＵＲ）により暗号化される。なお、本実施形態における認証キーの発行方法は、公知の種々の鍵生成方法を適用可能であり、例えば、ssh-keygenコマンド等を実行することで発行されるようにしてもよい。

また、データ記憶部１０１は、対象サーバ３０ごとに、その対象サーバ３０への認証時に使用すべき認証キーを識別するためのコンフィグデータを記憶する。図３は、コンフィグデータのデータ格納例を示す図である。図３に示すように、コンフィグデータには、各対象サーバ３０を識別する情報（例えば、ＩＰアドレスやホスト名）と、その対象サーバ３０への接続時に必要な認証キーを識別する情報（例えば、復号化した認証キーの格納場所）と、が関連付けられている。ここでは、対象サーバ３０ごとに、復号化した認証キーが格納されるディレクトリ及びそのファイル名が、コンフィグデータに定義されている。図３に示す「~」（チルダ）は、ホームディレクトリを示している。

なお、暗号化された認証キーは、復号化された認証キーと同じディレクトリに格納されていてもよいし、別のディレクトリであってもよい。更に、暗号化された認証キーは、通信制御サーバ１０以外のサーバで管理されているようにしてもよい。

また、通信制御サーバ１０のデータ記憶部１０１に記憶されるデータは、上記の例に限られない。例えば、データ記憶部１０１は、全ユーザを識別するデータ（例えば、ユーザのリスト）を記憶していてもよい。他にも例えば、各ユーザがアクセス可能な対象サーバ３０を定義したデータを記憶するようにしてもよい。このデータには、通信制御サーバ１０へのログインアカウントと、そのログインアカウントのユーザがアクセス可能な対象サーバ３０を識別する情報と、その対象サーバ３０へのログインアカウントと、その対象サーバ３０への認証時に必要な認証キーを識別する情報と、が関連付けられている。また例えば、通信制御サーバ１０が暗号化通信を行う際に用いられる各種情報（例えば、公開鍵や秘密鍵等の認証情報やknown-hostファイル等）が記録されているようにしてもよいし、ユーザの操作ログを蓄積したデータ等が記録されているようにしてもよい。

各対象サーバ３０のデータ記憶部３０１は、当該対象サーバ３０が通信制御サーバ１０と第２の通信を行うために必要な情報（例えば、公開鍵や秘密鍵等の認証情報）を記憶する。例えば、各対象サーバ３０のデータ記憶部３０１は、当該対象サーバ３０へのログインアカウントやその認証キーを記憶する。

取得部１０３は、対象サーバ３０へ通信するための認証に必要な認証情報（例えば、認証キー）を、認証ができない状態（以降、使用不可状態という。）で記憶するデータ記憶部１０１の記憶内容を取得する。使用不可状態とは、認証で認証情報が使用できない状態（認証が成功しない状態）であり、例えば、認証情報が暗号化された状態である。本実施形態では、取得部１０３は、暗号化された認証キーを取得することになる。

状態変化部１０４は、対象サーバ３０へ通信する要求（アクセス要求）をユーザ端末２０から受け付けた場合に、使用不可状態の認証情報を認証ができる状態（以降、使用可能状態という。）に変化させて認証を行い、その状態を保持する。使用可能状態とは、認証で使用できる状態（認証が成功する状態）であり、例えば、認証情報が復号化された状態である。

本実施形態では、状態変化部１０４は、暗号化された認証キーを復号化して認証を行い、復号化された認証キーをデータ記憶部１０１に保持する。例えば、状態変化部１０４は、コンフィグデータを参照して、ユーザがアクセス要求をした対象サーバ３０の認証キーを特定する。そして、状態変化部１０４は、その認証キー（暗号化された状態の認証キー）を、所定の復号化鍵で復号化する。なお、復号化鍵は、データ記憶部１０１に記憶されていてもよいし、外部のサーバで管理されており、認証時に状態変化部１０４が取得するようにしてもよい。また例えば、復号化鍵は、それ自体のデータが存在してもよいし、モジュールに埋め込まれた状態（即ち、ソースコードに記述された状態）であってもよい。

本実施形態では、複数のユーザが存在するので、状態変化部１０４は、アクセス要求をしたユーザが対象サーバ３０と通信するための認証を行い、そのユーザに関連付けて使用可能状態（即ち、復号化された認証キー）を保持する。ここでは、コンフィグデータに、保存先のディレクトリが定められているため、状態変化部１０４は、復号化した認証キーを、コンフィグデータに定義されたディレクトリ（例えば、「/home/ユーザ名/.ssh/」のディレクトリ）に格納する。なお、「/home/ユーザ名」は、アクセス要求をしたユーザのホームディレクトリである。

第１の通信と同様、第２の通信を確立する方法自体は、公知の種々の手法を適用可能である。即ち、ここではＳＳＨで定められた手順に沿って、通信制御サーバ１０の状態変化部１０４と、対象サーバ３０の第２通信制御部２０２と、の間でホスト認証及びユーザ認証が実行されることにより、第２の通信が確立される。ホスト認証及びユーザ認証の方法は、先述した方法と同様である。

状態変化部１０４による認証が成功すると、通信制御サーバ１０の第２通信制御部１０５は、対象サーバ３０との間で、第２の通信を行う。一方、対象サーバ３０の第２通信制御部３０２は、通信制御サーバ１０との間で、第２の通信を行う。本実施形態では、通信制御サーバ１０の第２通信制御部１０５は、ＳＳＨクライアントに相当し、対象サーバ３０の第２通信制御部３０２は、ＳＳＨデーモンに相当する。

第２の通信の確立後、第２通信制御部１０５は、所定のタイミングで、復号化した認証キーを使用する。例えば、第２通信制御部１０５は、所定のプロトコル（例えば、ＳＦＴＰ）の通信時や新たにコネクションを生成する場合に、復号化した認証キーを使って対象サーバ３０との認証を行う。別の言い方をすれば、対象サーバ３０にログイン済みのユーザが所定のコマンド（例えば、ＳＦＴＰコマンド）を入力した場合に、状態変化部１０４は、そのユーザに対応するディレクトリに格納されている、復号化した認証キーを使う。

なお、第２通信制御部１０５は、上記説明した場合以外にも、復号化された認証キーを参照するようにしてもよく、予め定められた条件のもとで参照するようにすればよい。例えば、第２通信制御部１０５は、あるＳＳＨクライアントにおいて、復号化された認証キーを定期的に又は所定のイベントの発生時に参照するようにしてもよい。より具体的には、悪意のある第三者による盗聴などを防止するために、ＳＳＨの通信中で使用されるサーバ鍵が所定時間ごと（例えば、１時間ごと）に作成される場合には、第２通信制御部１０５は、対象サーバ３０への初期接続及びサーバ鍵の再作成の際に、復号化された認証キーを読み込み、これを元にサーバ鍵が作成されるようにしてもよい。即ち、もし仮に、ＳＳＨの通信中に認証キーがなくなると、所定時間ごとに作成するサーバ鍵を作成できなくなりＳＳＨ通信が切断されてしまうので、第２通信制御部１０５は、ＳＳＨの通信中に、復号化された認証キーを削除せずに上記ディレクトリ内に保持するようにしている。

また、本実施形態では、ユーザ端末２０と対象サーバ３０との通信は、複数のコネクション（仮想通信路）を同時に確立することが可能である。例えば、通信制御サーバ１０においては、確立されたコネクションの数だけ、その通信をするためのプロセス（例えば、ＳＳＨプロセス）が起動している。第２通信制御部１０５は、ユーザが所定のコマンド（例えば、logout又はexitコマンド）を入力した場合に、そのコマンドで指示されたコネクションを終了（開放）する。この場合、終了したコネクションに対応するプロセスも終了することになる。

判定部１０６は、通信制御サーバ１０の通信状況を参照して、ユーザ端末２０と対象サーバ３０との通信が終了したか否かを判定する。例えば、判定部１０６は、予め定められたタイミングが到来した場合に、ユーザにより所定のプロセス（例えば、ＳＳＨプロセス）が起動しているか否かを判定する。即ち、判定部１０６は、通信制御サーバ１０で起動しているプロセスを参照することによって、ユーザごとに、そのユーザのユーザ端末２０と対象サーバ３０との通信が終了したか否かを判定する。

より具体的には、判定部１０６は、データ記憶部１０１を参照して、判定対象となるユーザを特定する。判定部１０６の判定対象となるユーザは、全ユーザであってもよいし、特定のユーザは除外されるようにしてもよい。判定部１０６は、所定のコマンド（例えば、「ps aux|grep ssh」）を実行して、各ユーザが起動させたプロセスを参照する。そして、判定部１０６は、対象サーバ３０に接続していることを示す所定のプロセス（例えば、ｓｓｈプロセス）が起動していない場合に、そのユーザの通信が終了したと判定する。

ここでは、対象サーバ３０に対して複数のコネクションを確立することができるので、判定部１０６は、ユーザごとに、全てのコネクションが終了したか否かを判定することになる。例えば、ｓｓｈプロセスが一つでも存在すれば、判定部１０６は、通信が終了したとは判定せず、ｓｓｈプロセスが一つも存在しなければ、判定部１０６は、通信が終了したと判定する。

なお、判定部１０６が所定のプロセスが起動しているか否かを判定する方法は、上記の例に限られない。例えば、全てのプロセスを詳細に表示させるための「ps aux」コマンドではなく詳細は表示させない「ps ax」コマンドを実行してもよい。判定部１０６は、ＯＳのプロセステーブルを参照し、ユーザが所定のプロセス（例えば、ＳＳＨクライアント）を起動しているか否かを判定すればよい。他にも例えば、判定部１０６は、プロセスの起動時間を参照することで、所定のプロセスが起動しているか否かを判定するようにしてもよい。より具体的には、判定部１０６は、「現在時刻−プロセスの起動時間」と、「ユーザからアクセスを受け付けた時刻」と、を比較することで、所定のプロセスが起動しているか否かを判定するようにしてもよい。この場合、通信制御サーバ１０は、ユーザからアクセスを受け付けると、その時刻がデータ記憶部１０１に記録されるものとする。なお、プロセスの起動時間は、「ps」コマンド等で取得されるようにすればよい。他にも、判定部１０６は、起動してから一定時間が経過したプロセスについては、起動していないものとみなすようにしてもよい。また、上記では、所定のプロセスの一例としてｓｓｈに関するプロセスを説明したが、ユーザ端末２０と対象サーバ３０との通信を行うために起動するプロセスであればよい。例えば、対象サーバ３０ではサーバ・プロセスが起動しているので、判定部１０６は、そのサーバ・プロセスに対応するクライアント・プロセスが起動しているか否かを判定すればよい。

終了制御部１０７は、ユーザ端末２０と対象サーバ３０との通信が終了した場合に、保持されている使用可能状態を使用不可状態に戻す。使用可能状態に戻すとは、使用可能状態を解除して、使用不可状態のみの状態にすることであり、本実施形態では、終了制御部１０７は、データ記憶部１０１に保持されている、復号化された認証キーを削除する。

また、対象サーバ３０に対して複数のコネクションを確立することができるので、終了制御部１０７は、対象サーバ３０との間で確立された全てのコネクションが終了した場合に使用不可状態に戻すことになる。更に、対象サーバ３０には複数のユーザが通信可能なので、終了制御部１０７は、何れかのユーザのユーザ端末２０と対象サーバ３０との通信が終了した場合に、当該ユーザに関連付けられて保持されている使用可能状態を使用不可状態に戻すことになる。

［３．実施形態において実行される処理］
図４及び図５は、情報処理システム１で実行される処理を示す図である。図４及び図５に示す処理は、制御部１１，２１，３１が、それぞれ記憶部１２，２２，３２に記憶されたプログラムに従って動作することにより実行される。なお、下記に説明する処理が実行されるにあたり、通信制御サーバ１０及び対象サーバ３０では、ＳＳＨデーモンが起動しているものとする。

図４に示すように、まず、ユーザ端末２０において、ユーザが操作部２４から所定の操作を行うと、制御部２１は、通信制御サーバ１０への接続要求を送信する（Ｓ１）。例えば、ユーザが通信制御サーバ１０のホスト名やＩＰアドレスを指定すると、制御部２１は、その指定内容に従い、通信制御サーバ１０に対して接続要求を送信する。

通信制御サーバ１０が接続要求を受信すると、通信制御サーバ１０とユーザ端末２０との間で認証（ホスト認証及びユーザ認証）が実行される（Ｓ２）。Ｓ２における認証では、例えば、ユーザ端末２０の記憶部２２に記憶された認証キーが使用される。認証が成功すると、通信制御サーバ１０とユーザ端末２０との間の通信が確立され、ユーザ端末２０においては、制御部２１は、表示部２５にコンソール画面を表示させる（Ｓ３）。

図６は、コンソール画面の一例を示す図である。図６に示すように、本実施形態では、コンソール画面４０は、通信制御サーバ１０のＳＳＨコンソールである。このコンソール画面４０が表示されると、ユーザによる通信制御サーバ１０へのログインが完了したことになる。ただし、この状態では、対象サーバ３０へのログインは、まだ完了していない。例えば、コンソール画面４０において、ユーザが、アクセスしたい対象サーバ３０を識別する情報（例えば、ＩＰアドレス）やその対象サーバ３０にログインするためログインアカウントを指定して所定のコマンドを入力すると、通信制御サーバ１０において、ＳＳＨクライアントが立ちあがる。

制御部２１は、ユーザが指定した対象サーバ３０のＩＰアドレスやログインアカウントを、通信制御サーバ１０に送信する（Ｓ４）。即ち、制御部２１は、ユーザが指定した対象サーバ３０へのアクセス要求を行う。

通信制御サーバ１０においては、ユーザが指定した対象サーバ３０のＩＰアドレスやログインアカウントを受信すると、制御部１１は、そのユーザがその対象サーバにアクセス可能か否かを判定する（Ｓ５）。アクセスできないと判定された場合（Ｓ５；Ｎ）、Ｓ３の処理に戻り、再度入力が待ち受けられる。一方、アクセス可能であると判定された場合（Ｓ５；Ｙ）、制御部１１は、復号化ルーチンを実行する（Ｓ６）。

図７は、復号化ルーチンの一例を示す図である。図７に示すように、制御部１１は、記憶部１２に記憶されたコンフィグデータを参照する（Ｓ３０）。Ｓ３０においては、制御部１１は、ユーザが指定した対象サーバ３０の認証キーのファイル名及びそれが格納されるディレクトリを特定する。

制御部１１は、復号化された認証キーが既に存在するか否かを判定する（Ｓ３１）。Ｓ３１においては、制御部１１は、ユーザが指定した対象サーバ３０の認証キーのファイル名を特定し、そのファイルが上記ディレクトリに存在するか否かを判定する。

復号化された認証キーが既に存在すると判定された場合（Ｓ３１；Ｙ）、復号化ルーチンは終了する。この場合、暗号化された認証キーを復号化する処理を実行する必要がないので、以降のＳ３２〜Ｓ３４の処理は実行されない。

一方、復号化された認証キーがないと判定された場合（Ｓ３１；Ｎ）、制御部１１は、暗号化された認証キーを記憶部１２から読み出す（Ｓ３２）。Ｓ３２においては、制御部１１は、ユーザが指定した対象サーバ３０に関連付けられた、暗号化された認証キーを記憶部１２から読み出すことになる。

制御部１１は、所定の復号化鍵を使って、暗号化された認証キーを復号化する（Ｓ３３）。Ｓ３３においては、制御部１１は、暗号化された認証キーを、所定のパスワードを使って復号化する。

制御部１１は、復号化した認証キーを所定のディレクトリに格納し（Ｓ３４）、復号化ルーチンは終了する。Ｓ３４においては、制御部１１は、コンフィグデータを参照して、復号化した認証キーを格納すべきディレクトリを特定する。そして、制御部１１は、そのディレクトリに、復号化した認証キーを格納する。図３に示すデータ格納例の場合、制御部１１は、暗号化された認証キーのファイル名に「.pem」の拡張子が付与されたファイルを格納することになる。

図４に戻り、所定のディレクトリに格納されている復号化された認証キーに基づいて、通信制御サーバ１０と対象サーバ３０との間で、認証（ホスト認証及びユーザ認証）が行われる（Ｓ７）。認証が成功すると、通信制御サーバ１０を経由した対象サーバ３０へのログインが完了して、コンソール画面４０において、ユーザが対象サーバ３０に対するコマンドを入力可能な状態となる。

図５に移り、ユーザ端末２０においては、制御部２１は、ユーザによるコマンドの入力を受け付ける（Ｓ８）。ユーザは、操作部２４を用いてコンソール画面４０からコマンドを入力する。

ユーザがＳＳＨクライアントの終了を入力した場合（Ｓ８；終了）、ユーザ端末２０におけるＳＳＨクライアントが終了し、Ｓ１の処理に戻る。この場合、所定のログアウト処理が実行され、ユーザは、通信制御サーバ１０と対象サーバ３０の両方からログアウトする。この場合、ユーザ端末２０及び通信制御サーバ１０の第１の通信と、通信制御サーバ１０及び対象サーバ３０の第２の通信と、の両方が終了し、コネクションが開放される。

ユーザが対象サーバ３０からのログアウト指示を入力した場合（Ｓ８；ログアウト）、対象サーバ３０からログアウトし、Ｓ３の処理に戻る。この場合、所定のログアウト処理が実行され、通信制御サーバ１０及び対象サーバ３０の第２の通信が終了し、コネクションが開放される。この状態では、ユーザは、対象サーバ３０からログアウトするため、通信制御サーバ１０にのみログインしている状態となる。

ユーザが他のコマンドを入力した場合（Ｓ８；その他）、制御部２１は、コンソール画面４０における入力内容を通信制御サーバ１０に送信する（Ｓ９）。Ｓ９においては、制御部２１は、ユーザが操作部２４を用いて入力したコマンドやファイル名等の記号列を、記憶部２２に記憶された暗号化のための鍵（公開鍵や共通鍵）を用いて暗号化して送信する。

通信制御サーバ１０においては、入力内容を受信すると、制御部１１は、それを復号化して操作ログを記録する（Ｓ１０）。Ｓ１０においては、制御部１１は、記憶部１２に記憶された復号化のための鍵（秘密鍵や共通鍵）を用いて、ユーザ端末２０から受信した情報を復号化する。制御部１１は、ユーザのログインアカウント、ユーザが入力したコマンドやファイル名等の記号列、アクセス先の対象サーバ３０の名称やＩＰアドレス、及び現在の日時に関する情報を、記憶部１２に操作ログデータとして格納する。

制御部１１は、復号化ルーチンを実行する必要があるか否かを判定する（Ｓ１１）。Ｓ１１においては、制御部１１は、ユーザが所定のコマンドを入力したか否かを判定する。例えば、制御部１１は、ＳＦＴＰで対象サーバ３０に接続するか否かを判定したり、別コネクションの生成指示を受け付けたか否かを判定したりする。

復号化ルーチンを実行する必要があると判定された場合（Ｓ１１；Ｙ）、制御部１１は、図７に示す復号化ルーチンを実行する（Ｓ１２）。その後、所定のディレクトリに格納されている復号化された認証キーに基づいて、通信制御サーバ１０と対象サーバ３０との間で、認証（ホスト認証及びユーザ認証）が行われ（Ｓ１３）、Ｓ１２の処理に移行する。

一方、復号化ルーチンを実行する必要がない場合（Ｓ１１；Ｎ）、制御部１１は、ユーザの入力内容を暗号化して対象サーバ３０に送信する（Ｓ１４）。Ｓ１４においては、制御部１１は、記憶部１２に記憶された暗号化のための鍵（公開鍵や共通鍵）を用いて、ユーザが入力したコマンド等を暗号化する。

対象サーバ３０においては、入力内容を受信すると、制御部３１は、それを復号化し、コマンドの実行及び実行結果の送信を行う（Ｓ１５）。制御部３１は、記憶部３２に記憶された復号化のための鍵（秘密鍵や共通鍵）を用いて、通信制御サーバ１０から受信した情報を復号化する。そして、制御部３１は、復号化されたコマンドを実行する。また、制御部３１は、コマンドの実行結果を示す情報を生成して、記憶部３２に記憶された暗号化のための鍵（公開鍵や共通鍵）を用いて、コマンドの実行結果を暗号化する。

通信制御サーバ１０においては、コマンドの実行結果を受信すると、制御部１１は、それを復号化して操作ログとして記録し、それを暗号化してユーザ端末２０に送信する（Ｓ１６）。Ｓ１６においては、制御部１１は、記憶部１２に記憶された復号化のための鍵（秘密鍵や共通鍵）を用いて、対象サーバ３０から受信した情報を復号化して、それを操作ログに記録する。そして、制御部１１は、記憶部１２に記憶された暗号化のための鍵（公開鍵や共通鍵）を用いて、コマンドの実行結果を暗号化して送信する。

ユーザ端末２０においては、コマンドの実行結果を受信すると、制御部２１は、それを復号化して、コンソール画面４０に表示させ（Ｓ１７）、Ｓ８の処理に戻る。Ｓ１７においては、制御部２１は、記憶部２２に記憶された復号化のための鍵（秘密鍵や共通鍵）を用いて、コマンドの実行結果を復号化する。以降、ユーザによるコマンドの入力及びそのコマンドの実行が繰り返される。

一方、通信制御サーバ１０においては、制御部１１は、所定の判定タイミングが到来したか否かを判定する（Ｓ１８）。判定タイミングは、続くＳ１９の削除ルーチンを実行すべきタイミングであり、定期的（例えば、５分間隔）に訪れるものとする。判定タイミングが到来したと判定された場合（Ｓ１８；Ｙ）、制御部１１は、削除ルーチンを実行する（Ｓ１９）。

図８は、削除ルーチンの一例を示す図である。図８に示すように、制御部１１は、記憶部１２を参照して、全ユーザを特定する（Ｓ４０）。例えば、ユーザのリストが記憶部１２に記憶されているものとする。制御部１１は、そのリストを参照することで、全ユーザを特定する。

制御部１１は、判定対象のユーザを選出し、対象サーバ３０との全コネクションが終了しているか否かを判定する（Ｓ４１）。Ｓ４１においては、制御部１１は、所定のコマンドを実行して、判定対象のユーザが起動しているプロセスを参照する。そして、制御部１１は、所定のプロセス（例えば、ｓｓｈプロセス）が存在するか否かを判定することによって、全コネクションが終了しているか否かを判定する。なお、制御部１１がｓｓｈプロセスがあるか否かを判定する際に、文字列一致の判定処理のためにｓｓｈｄプロセスの存在が検出される可能性があるが、これは判定対象から除外するものとする。

全コネクションが終了していると判定された場合（Ｓ４１；Ｙ）、制御部１１は、判定対象のユーザに対応するディレクトリから、復号化された認証キーを削除する（Ｓ４２）。Ｓ４２においては、制御部１１は、「/home/判定対象のユーザ名/.ssh/」のディレクトリに存在する認証キーのファイルを削除する。

一方、コネクションが存在していると判定された場合（Ｓ４１；Ｎ）、Ｓ４２の処理は実行されない。この場合、制御部１１は、復号化された認証キーを削除せず、所定のディレクトリに保持したままにする。

制御部１１は、判定対象の全ユーザについて処理をしたか否かを判定する（Ｓ４３）。まだ判定していないユーザがいる場合（Ｓ４３；Ｎ）、Ｓ４１に戻り、制御部１１は、次のユーザを判定対象として選出する。一方、全てのユーザについて処理をしたと判定された場合（Ｓ４３；Ｙ）、削除ルーチンは終了する。

以上説明した情報処理システム１によれば、対象サーバ３０との通信が確立している間のみ、復号化した認証キーを所定ディレクトリに保持するため、セキュリティを担保しつつ、必要な場面で認証キーをすぐに使用することができる。例えば、ＳＳＨを確立した直後に、復号化した認証キーを削除してしまうと、その後のＳＦＴＰのサーバ接続が失敗することがあるが、復号化した認証キーを残しておくことで、確実にＳＦＴＰサーバ接続を行うことができる。また、復号化した認証キーを残しておくことで、暗号化された認証キーをいちいち復号化する必要がないため、認証後の通信における通信制御サーバの処理負荷を軽減することが可能になる。

また、ユーザが対象サーバ３０にアクセスして作業を行う場合には、複数のコネクションを同時に確立することが多いため、これらの全コネクションが終了した場合に復号化した認証キーを削除することで、接続中のコネクションが残っているにも関わらず、復号化した認証キーが無くなってしまうことを防止することができる。

また、予め定められたタイミングが到来した場合に、所定のプロセスが存在するか否かを判定することで、比較的簡易な処理により、通信が終了したか否かを判定することができる。

また、ユーザごとに、復号化した認証キーを保持しておいて、通信が終了したユーザの認証キーを削除するので、あるユーザの通信が終了していないにも関わらず、他のユーザの通信終了のために、復号化した認証キーが無くなってしまうことを防止することができる。

［４．変形例］
なお、本発明は、以上に説明した実施の形態に限定されるものではない。本発明の趣旨を逸脱しない範囲で、適宜変更可能である。

例えば、予め定められたタイミングが到来した場合に削除ルーチンが実行される場合を説明したが、対象サーバ３０への通信が終了したか否かを、通信制御サーバ１０が常に監視しているようにしてもよい。

また例えば、対象サーバ３０への認証キーは、対象サーバ３０のログインアカウントごとに異なっていてもよいし、共通のものを使用してもよい。同様に、対象サーバ３０の認証キーは、通信制御サーバ１０のログインアカウントごとに異なっていてもよいし、共通のものを使用してもよい。更に、認証キーの復号化に必要な復号化鍵は、認証キーごとに異なっていてもよいし、共通のものを使用してもよい。

また例えば、状態変化部１０４が、暗号化された認証キーを復号化した場合に、暗号化された認証キーのファイルはそのまま残しておいてもよいし、いったん削除してもよい。いったん削除する場合には、復号化した認証キーが削除される場合に、認証キーが暗号化されて元の格納場所に格納されるものとする。

また例えば、使用不可状態の一例として暗号化を挙げたが、認証で使用できない状態であればよく、認証キーのファイルにアクセスできないようにする（アクセス権限を付与しない）ことが使用不可状態に相当するようにしてもよい。同様に、使用可能状態の一例として復号化を挙げたが、認証で使用できる状態であればよく、認証キーのファイルにアクセスできるようにする（アクセス権限を付与する）ことが使用可能状態に相当するようにしてもよい。

また例えば、認証情報の一例として認証キーを例に挙げたが、認証情報は、認証時に用いられる情報であればよく、これに限られない。例えば、パスワード認証が行われる場合には、パスワードが認証情報に相当するようにしてもよい。

また例えば、ユーザがアクセス先の対象サーバ３０を指定する方法は、コンソール画面４０からＩＰアドレス等を直接入力する方法に限られない。例えば、通信制御サーバ１０は、ユーザがアクセス可能な対象サーバ３０の一覧を作成してユーザ端末２０に送信し、ユーザ端末２０において選択された対象サーバ３０を取得するようにしてもよい。その場合、判定部１０６は、その一覧を作成してユーザ端末２０に送信するためのプロセスが起動しているか否かを判定することで、通信が終了したか否かを判定するようにしてもよい。

また例えば、サーバコンピュータがユーザのコマンドを実行する場合を説明したが、ユーザのコマンドを実行するのは、例えば、ネットワーク機器であってもよい。即ち、ネットワーク機器が、対象サーバに相当するようにしてもよい。

また例えば、通信プロトコルの一例としてＳＳＨを説明したが、ＳＳＨだけではなく、他の種々のプロトコルによる通信が適用可能である。例えば、ＴＥＬＮＥＴ、ＦＴＰ、ＳＣＰ、ＳＦＴＰ、ＲＤＰ、ＨＴＴＰ、又はＨＴＴＰＳにより通信が行われるようにしてもよい。また例えば、上記においては、本発明に関る通信制御サーバを、クラウドコンピューティングを利用した情報処理システムに適用する例を説明したが、本発明に関る通信制御サーバは、ユーザがサーバにリモートアクセスする種々のシステムに適用可能である。

１ 情報処理システム、１０ 通信制御サーバ、１１，２１，３１ 制御部、１２，２２，３２ 記憶部、１３，２３，３３ 通信部、２０ ユーザ端末、２４ 操作部、２５ 表示部、３０ 対象サーバ、４０ コンソール画面、１０１ データ記憶部、１０２ 第１通信制御部、１０３ 取得部、１０４ 状態変化部、１０５ 第２通信制御部、１０６ 判定部、１０７ 終了制御部、２０１ データ記憶部、２０２ 第１通信制御部、３０１ データ記憶部、３０２ 第２通信制御部。

Claims (8)

1. ユーザが操作するユーザ端末と、通信対象の対象サーバと、の通信を仲介する通信制御サーバであって、
   前記対象サーバへ通信するための認証に必要な認証情報を、認証ができない状態で記憶する手段の記憶内容を取得する取得手段と、
   前記対象サーバへ通信する要求を前記ユーザ端末から受け付けた場合に、前記認証ができない状態の認証情報を認証ができる状態に変化させて認証を行い、その状態を保持する状態変化手段と、
   前記ユーザ端末と前記対象サーバとの通信が終了した場合に、前記保持されている状態を認証ができない状態に戻す終了制御手段と、
   を含み、
   前記ユーザ端末と前記対象サーバとの通信は、複数のコネクションを同時に確立することが可能であり、
   前記終了制御手段は、確立された全てのコネクションが終了した場合に、認証ができない状態に戻す、
   ことを特徴とする通信制御サーバ。
2. ユーザが操作するユーザ端末と、通信対象の対象サーバと、の通信を仲介する通信制御サーバであって、
   前記対象サーバへ通信するための認証に必要な認証情報を、認証ができない状態で記憶する手段の記憶内容を取得する取得手段と、
   前記対象サーバへ通信する要求を前記ユーザ端末から受け付けた場合に、前記認証ができない状態の認証情報を認証ができる状態に変化させて認証を行い、その状態を保持する状態変化手段と、
   前記ユーザ端末と前記対象サーバとの通信が終了した場合に、前記保持されている状態を認証ができない状態に戻す終了制御手段と、
   予め定められたタイミングが到来した場合に、前記ユーザにより所定のプロセスが起動しているか否かを判定することによって、前記ユーザ端末と前記対象サーバとの通信が終了したか否かを判定する判定手段と、
   を含むことを特徴とする通信制御サーバ。
3. 認証ができない状態とは、前記認証情報が暗号化された状態であり、認証ができる状態とは、前記認証情報が復号化された状態であり、
   前記取得手段は、暗号化された前記認証情報を取得し、
   前記状態変化手段は、暗号化された前記認証情報を復号化して認証を行い、当該復号化された認証情報を記憶手段に保持し、
   前記終了制御手段は、前記ユーザ端末と前記対象サーバとの通信が終了した場合に、前記記憶手段に保持されている、復号化された前記認証情報を削除する、
   ことを特徴とする請求項１又は２に記載の通信制御サーバ。
4. 前記対象サーバは、複数のユーザによる通信が可能であり、
   前記状態変化手段は、前記要求をしたユーザが前記対象サーバと通信するための認証を行い、そのユーザに関連付けて認証ができる状態を保持し、
   前記終了制御手段は、何れかのユーザの前記ユーザ端末と前記対象サーバとの通信が終了した場合に、当該ユーザに関連付けられて保持されている状態を認証ができない状態に戻す、
   ことを特徴とする請求項１〜３の何れか一項に記載の通信制御サーバ。
5. ユーザが操作するユーザ端末と、通信対象の対象サーバと、の通信を仲介する通信制御方法であって、
   前記対象サーバへ通信するための認証に必要な認証情報を、認証ができない状態で記憶する手段の記憶内容を取得する取得ステップと、
   前記対象サーバへ通信する要求を前記ユーザ端末から受け付けた場合に、前記認証ができない状態の認証情報を認証ができる状態に変化させて認証を行い、その状態を保持する状態変化ステップと、
   前記ユーザ端末と前記対象サーバとの通信が終了した場合に、前記保持されている状態を認証ができない状態に戻す終了制御ステップと、
   を含み、
   前記ユーザ端末と前記対象サーバとの通信は、複数のコネクションを同時に確立することが可能であり、
   前記終了制御ステップは、確立された全てのコネクションが終了した場合に、認証ができない状態に戻す、
   ことを特徴とする通信制御方法。
6. ユーザが操作するユーザ端末と、通信対象の対象サーバと、の通信を仲介する通信制御方法であって、
   前記対象サーバへ通信するための認証に必要な認証情報を、認証ができない状態で記憶する手段の記憶内容を取得する取得ステップと、
   前記対象サーバへ通信する要求を前記ユーザ端末から受け付けた場合に、前記認証ができない状態の認証情報を認証ができる状態に変化させて認証を行い、その状態を保持する状態変化ステップと、
   前記ユーザ端末と前記対象サーバとの通信が終了した場合に、前記保持されている状態を認証ができない状態に戻す終了制御ステップと、
   予め定められたタイミングが到来した場合に、前記ユーザにより所定のプロセスが起動しているか否かを判定することによって、前記ユーザ端末と前記対象サーバとの通信が終了したか否かを判定する判定ステップと、
   を含むことを特徴とする通信制御方法。
7. ユーザが操作するユーザ端末と、通信対象の対象サーバと、の通信を仲介するコンピュータを、
   前記対象サーバへ通信するための認証に必要な認証情報を、認証ができない状態で記憶する手段の記憶内容を取得する取得手段、
   前記対象サーバへ通信する要求を前記ユーザ端末から受け付けた場合に、前記認証ができない状態の認証情報を認証ができる状態に変化させて認証を行い、その状態を保持する状態変化手段、
   前記ユーザ端末と前記対象サーバとの通信が終了した場合に、前記保持されている状態を認証ができない状態に戻す終了制御手段、
   として機能させるためのプログラムであって、
   前記ユーザ端末と前記対象サーバとの通信は、複数のコネクションを同時に確立することが可能であり、
   前記終了制御手段は、確立された全てのコネクションが終了した場合に、認証ができない状態に戻す、
   ことを特徴とするプログラム。
8. ユーザが操作するユーザ端末と、通信対象の対象サーバと、の通信を仲介するコンピュータを、
   前記対象サーバへ通信するための認証に必要な認証情報を、認証ができない状態で記憶する手段の記憶内容を取得する取得手段、
   前記対象サーバへ通信する要求を前記ユーザ端末から受け付けた場合に、前記認証ができない状態の認証情報を認証ができる状態に変化させて認証を行い、その状態を保持する状態変化手段、
   前記ユーザ端末と前記対象サーバとの通信が終了した場合に、前記保持されている状態を認証ができない状態に戻す終了制御手段、
   予め定められたタイミングが到来した場合に、前記ユーザにより所定のプロセスが起動しているか否かを判定することによって、前記ユーザ端末と前記対象サーバとの通信が終了したか否かを判定する判定手段、
   として機能させるためのプログラム。

Images