リモートアクセス装置、リモートアクセスプログラム、リモートアクセス方法及びリモートアクセスシステム
【課題】ＵＲＬが動的に生成される場合であっても、ＵＲＬの書き換えをせずにアクセスを可能とし、且つ簡易な方法で、隔離ネットワーク内のサーバにアクセスを行なう。
【解決手段】
所定の通信プロトコルに基づいてデータ通信を行うユーザエージェントからのデータを受信可能な状態にする受信設定部５０と、ユーザエージェントのプロキシ設定とは異なる他のプロキシ設定を作成し、ユーザエージェントに他のプロキシ設定を参照させるためのユーザエージェント管理部５４と、接続サーバから、利用者ごとにアクセスが許可されているＵＲＬを含むアクセス許可リストをダウンロードし、保持するアクセス管理部５２と、
利用者の操作に基づいて生成された通信要求に含まれた接続先がアクセス許可リストに含まれているか否かを判断し、接続先がアクセス許可リストに含まれる場合は、要求を内部サーバに送信するアクセス制御部５３とを備える。
【解決手段】
所定の通信プロトコルに基づいてデータ通信を行うユーザエージェントからのデータを受信可能な状態にする受信設定部５０と、ユーザエージェントのプロキシ設定とは異なる他のプロキシ設定を作成し、ユーザエージェントに他のプロキシ設定を参照させるためのユーザエージェント管理部５４と、接続サーバから、利用者ごとにアクセスが許可されているＵＲＬを含むアクセス許可リストをダウンロードし、保持するアクセス管理部５２と、
利用者の操作に基づいて生成された通信要求に含まれた接続先がアクセス許可リストに含まれているか否かを判断し、接続先がアクセス許可リストに含まれる場合は、要求を内部サーバに送信するアクセス制御部５３とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットに接続したクライアント装置から、隔離ネットワークで稼働するサーバに対するアクセスを提供するリモートアクセス装置、リモートアクセスプログラム、リモートアクセス方法及びリモートアクセスシステムに関する。
【背景技術】
【０００２】
従来より、企業内イントラネットなどの隔離ネットワークからインターネットを経由してＷｅｂサーバ群に対して選択的にアクセスするリモートアクセス技術が知られている。
【０００３】
このようなリモートアクセス技術として、例えば特許文献１に示すようなリバースプロキシサーバ方式がある。この方式では、隔離ネットワークとインターネットの境界にリバースプロキシサーバを設置し、クライアントＰＣはインターネットを経由してリバースプロキシサーバのＵＲＬにアクセスする。隔離ネットワークの管理者は、インターネットを介してアクセスを許すＷＥＢサーバをリバースプロキシサーバに登録する。リバースプロキシサーバへの登録は、インターネットを介してアクセスを許可するＷＥＢサーバのＵＲＬと、それをリバースプロキシサーバ経由でアクセスするためのリバースプロキシサーバのＵＲＬの対によって行う。リバースプロキシサーバは、クライアントＰＣからのＨＴＴＰ要求を、隔離ネットワークで稼働するＷＥＢサーバに転送し、そのＷＥＢサーバによるＨＴＴＰ応答を、クライアントＰＣに転送する。リバースプロキシサーバとクライアントＰＣの間はＨＴＴＰＳを用いて暗号化通信を使用することにより、インターネットを使用して安全に通信する。
【０００４】
また、他の従来のリモートアクセス技術として、特許文献２に記載されているようなＶＰＮ接続方式がある。このＶＰＮ接続方式では、隔離ネットワークとインターネットの境界にＶＰＮルータを設置し、クライアントＰＣにはＶＰＮクライアントをインストールして、ＶＰＮルータとＶＰＮクライアントの間で（インターネットを介して）仮想的なネットワークを構成することにより、隔離ネットワークの一部にクライアントＰＣを接続したのと同じ状態を実現する。
【０００５】
ＶＰＮクライアントは、クライアントＰＣからＷＥＢサーバ宛てのＨＴＴＰ要求となるＩＰデータグラムを暗号化して別のＩＰデータグラムまたはＴＣＰストリームとしてインターネット経由でＶＰＮルータに送信する。ＶＰＮルータは受け取ったＩＰデータグラムまたはＴＣＰストリームからＷＥＢサーバ宛てのＩＰデータグラムを取り出し、それをＷＥＢサーバに送信する。ＷＥＢサーバからのＨＴＴＰ応答は、これとは逆の経路によってクライアントＰＣに送信される。
【０００６】
また、他の従来のリモートアクセス技術として、ＴＣＰトンネル方式がある。このＴＣＰトンネル方式では、隔離ネットワークとインターネットの境界にトンネリングサーバを設置し、クライアントＰＣでトンネリングクライアントを稼働させることで、トンネリングクライアントとトンネリングサーバ間のＴＣＰストリームを使用して、クライアントＰＣからのＨＴＴＰ要求および隔離ネットワークで稼働するＷＥＢサーバからのＨＴＴＰ応答を相互に転送する。
【０００７】
クライアントＰＣが、自ノード内で稼働するトンネリングソフトウェアが提供するサービスポートに対してＨＴＴＰ要求を送信すると、トンネリングクライアントは、そのＨＴＴＰ要求のＴＣＰストリームの内容を暗号化し、別のＴＣＰストリームによってトンネリングサーバ宛てに送信する。トンネリングサーバは、トンネリングクライアントからの通信を受けて、その内容を復号し、別のＴＣＰストリームによってＷＥＢサーバに転送する。
【特許文献１】特開２００４−２９５１６６号公報
【特許文献２】特開２００２−２３２４６０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、特許文献１に記載されたリバースプロキシサーバ方式では、以下のような問題があった。
リバースプロキシサーバ方式では、ＷＥＢサーバのＵＲＬを公開せず、クライアントＰＣはリバースプロキシサーバが提供するＵＲＬにアクセスする。リバースプロキシサーバは、そのクライアントＰＣからのＨＴＴＰ要求を、ＷＥＢサーバに転送する。例えば、リバースプロキシサーバのＵＲＬが、「http://reverse.proxy.server/path1」であり、ＷｅｂサーバのＵＲＬが「http://a.server/path2」である場合、クライアントＰＣは、http://reverse.proxy.server/path1に対するＨＴＴＰ要求を送信する。リバースプロキシサーバは、このＨＴＴＰ要求をhttp://a.server/path2宛てに送信する。逆に、ＷＥＢサーバからのＨＴＴＰ応答にＷＥＢサーバのホスト名を含んだＵＲＬがあるとき、リバースプロキシサーバはそれをリバースプロキシサーバのＵＲＬに書き換える。クライアントＰＣは、隔離ネットワーク上のホスト名を含むhttp://a.server/path2のようなＵＲＬを受け取とっても、そのＵＲＬにはアクセスできないからである。
【０００９】
しかし現在のＷｅｂサーバでは、動的にＵＲＬを変える場合などに、ＨＴＴＰ応答にJavaScript（登録商標）プログラムを含め、このJavaScript（登録商標）プログラムの実行によりＵＲＬを生成する方法が一般的に行なわれている。この場合、JavaScript（登録商標）プログラムはＨＴＴＰ応答を受け取ったクライアントＰＣ上のＷｅｂブラウザで実行されるので、当該ＨＴＴＰ応答を転送するリバースプロキシサーバではＵＲＬを書換えることができず、利用者はＷｅｂサーバにアクセスすることができないという問題があった。仮に、利用者がインターネット経由でリバースプロキシサーバを介してアクセスすることを可能とするには、Ｗｅｂサーバ上のJavaScript（登録商標）プログラムを変更しなければならず、運用時の負荷が増える。また、このＷｅｂサーバが第３者から提供されている製品であった場合は、そもそもそのような変更ができない場合がある。
【００１０】
また、特許文献２に記載されたＶＰＮ接続方式では、以下のような問題があった。
クライアントＰＣにＶＰＮクライアントをインストールし、ＶＰＮルータとの接続設定を予め行っておく必要があり、設定が面倒であるという問題があった。また、ネットワーク環境によっては、クライアントＰＣ自身が別の隔離ネットワークに接続していて、プロキシサーバを介してインターネットに接続する場合もあるが、そのようにクライアントＰＣがプロキシサーバを介してインターネットに接続している場合、プロキシサーバはアプリケーションゲートウェイ（ＨＴＴＰゲートウェイ）として動作するため、ＶＰＮプロトコルを処理できず、したがってＶＰＮクライアントはＶＰＮルータと通信できないという問題があった。
【００１１】
さらに、ＶＰＮクライアントおよびＶＰＮルータはネットワーク層の転送機構であるため、ＵＲＬ単位で選択的にアクセスを許可したり、利用者ごとにアクセスを許可するＵＲＬを設定したりする等の、ネットワーク層より上位の階層でのみ制御可能な処理を行うには、ＶＰＮルータとＷＥＢサーバの間に別途ファイアーウォールなどのセキュリティ装置を設置しなければならず、ハードウェアの設置の手間がかかるという問題があった。
【００１２】
さらに、ＶＰＮクライアントの稼働中は、クライアントＰＣから送信されるＩＰデータグラムのデフォルト経路がこのＶＰＮクライアントによって実装される仮想インタフェースとなっており、すべてのＩＰデータグラムは隔離ネットワークに転送される。このため、ＶＰＮクライアント稼働中は、クライアントＰＣからインターネットで稼働するＷＥＢサーバに直接アクセスすることができないという問題があった。
【００１３】
また、ＴＣＰトンネル方式では、以下の問題があった。
ＴＣＰトンネル方式では、クライアントＰＣがプロキシサーバを介してトンネリングサーバに接続する場合、プロキシサーバの一般的な設定では、ＨＴＴＰＳ以外の暗号化されたＴＣＰストリームの中継は許可せず、したがってクライアントＰＣはトンネリングサーバにアクセスができないという問題があった。
【００１４】
また、クライアントＰＣがプロキシサーバを介さず直接インターネットに接続する場合でも、クライアントＰＣ上で稼働するＷＥＢブラウザは、http://127.0.0.1/pathまたはhttp://localhost/pathという形式のＵＲＬを使用してトンネリングクライアントに対してＨＴＴＰ要求を送信するため、リバースプロキシサーバ方式と同様に、ＷｅｂサーバへのアクセスにはＵＲＬ書換えが必要となってしまい、運用時の負荷の増加またはアクセスができないという問題があった。
【００１５】
そこで、本発明は、ＵＲＬが動的に生成される場合であっても、ＵＲＬの書き換えをせずにアクセスを可能とし、且つクライアントソフトのインストール等をすることなしに簡易な方法で、隔離ネットワーク内のサーバにアクセスを行なわせるリモートアクセス装置を提供することを目的とする。
【課題を解決するための手段】
【００１６】
本発明のリモートアクセス装置は、ネットワーク及び非武装地帯に設置された接続サーバを通じて内部サーバへのアクセスを行うものであって、所定の通信プロトコルに基づいてデータ通信を行うユーザエージェントからのデータを受信可能な状態にする受信設定手段と、
前記ユーザエージェントのプロキシ設定とは異なる他のプロキシ設定を作成し、 前記ユーザエージェントに前記他のプロキシ設定を参照させるためのユーザエージェント管理手段と、前記接続サーバから、利用者ごとにアクセスが許可されているＵＲＬを含むアクセス許可リストをダウンロードし、保持するアクセス管理手段と、前記利用者の操作に基づいて生成された通信要求に含まれた接続先が前記アクセス許可リストに含まれているか否かを判断し、前記接続先が前記アクセス許可リストに含まれる場合は、前記要求を前記内部サーバに送信するアクセス制御手段とを備えることを特徴とする。
【００１７】
また、本発明のリモートアクセス装置は、さらに、前記受信設定手段が、使用されていないポートを検索し、検索の結果見つかった、使用されていないポートを使用してユーザエージェントからのデータを受信可能な状態にすることを特徴とする。
【００１８】
また、本発明のリモートアクセス装置は、前記アクセス管理手段が、利用者の認証情報を前記接続サーバに送信し、前記接続サーバによる認証がされた場合、前記アクセス許可リストをダウンロードすることを特徴とする。
【００１９】
また、本発明のリモートアクセス装置は、前記アクセス制御手段が、前記接続サーバとの通信をＨＴＴＰＳで行うことを特徴とする。
【００２０】
また、本発明のリモートアクセス装置は、前記他のプロキシ設定において、前記ユーザエージェントが使用するＩＰアドレスがループバックアドレスにされていることを特徴とする。
【発明の効果】
【００２１】
本発明によれば、アクセス許可リストを使用して通信要求の接続先を、接続サーバを経由して接続される内部サーバと、それ以外のインターネット等のネットワーク上のサーバ、のいずれかへ切り替えることが可能であるため、リモートアクセス装置は、どちらのサーバにもアクセスすることができるという効果がある。
【００２２】
また、本発明によれば、クライアントＰＣと接続サーバ間の通信はＨＴＴＰＳを用いるので、リモートアクセス装置がプロキシサーバ（一般的な設定ではＨＴＴＰＳ以外の暗号化通信を中継しない）を介してインターネットに接続している場合にも利用できるという効果がある。
【００２３】
また、本発明によれば、ＶＰＮのようなネットワーク層でのデータ送受信ではなく、アプリケーション層でＨＴＴＰ通信の転送を行なうため、ＶＰＮクライアントをインストールしなくてよい。また、本発明によれば、設定管理部は動作のための設定を自動で行なうので、手動による設定の手間も不要となるという効果がある。
【図面の簡単な説明】
【００２４】
【図１】本発明の実施形態であるリモートアクセスシステムの構成を示す図である。
【図２】本発明の実施形態の通信処理部の構成を示す図である。
【図３】本発明の実施形態のアクセス許可リストを示す図である。
【図４】本発明の実施形態の処理の流れを示すフローチャートである。
【図５】本発明の実施形態におけるプロキシ設定の変更前の例と変更後の例を示す図である。
【発明を実施するための形態】
【００２５】
以下、本発明の実施形態について、図面を参照して詳細に説明する。
図１は、本発明の実施形態であるリモートアクセスシステムの全体構成を示す。リモートアクセスシステム１００は、クライアントＰＣ１と、プロキシサーバ２と、ネットワーク３と、ファイアーウォール１１と、接続サーバ１２と、ファイアーウォール２１と、Ｗｅｂサーバ２２、２３とから構成されている。
【００２６】
クライアントＰＣ１は、プロキシサーバ２を経由して、ネットワーク３、例えばインターネットに接続されており、利用者の操作に応じてＷｅｂサーバ２２、２３にアクセスを行う汎用コンピュータである。クライアントＰＣ１は、通信処理部３１とＷｅｂブラウザ３２を含む。利用者は、クライアントＰＣ１を操作して、Ｗｅｂブラウザ３２を通じてＷｅｂサーバ２２、２３に接続を行う。クライアントＰＣ１は、例えば利用者が自宅や外出先で利用するパーソナルコンピュータであってもよいし、携帯電話や携帯情報端末であってもよい。
【００２７】
Ｗｅｂブラウザ３２は、所定のプロトコルを用いてネットワークを通じてデータの送受信するユーザエージェントの一例であり、後述するプロキシ設定にしたがってＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ
Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）通信又はＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）で暗号化されたいわゆるＨＴＴＰＳ通信を行う。なお、本実施形態ではＷｅｂブラウザ３２を用いて説明するが、他の通信プロトコルを用いたユーザエージェントであってもよい。
【００２８】
通信処理部３１は、クライアントＰＣ１の未使用のＴＣＰポートを使用して、接続サーバ１２を介して、Ｗｅｂブラウザ３２との間でＨＴＴＰ通信を行なう。ＨＴＴＰ通信に際して、通信処理部３１は、後述するように、Ｗｅｂブラウザ３２がＨＴＴＰ要求を通信処理部３１に送信するようにするためのプロキシ設定（プロキシ設定２）を作成し、Ｗｅｂブラウザ３２の起動時に、Ｗｅｂブラウザ３２がプロキシ設定２を参照するようにするとともに、自身はもとのプロキシ設定（プロキシ設定１）を参照して、ＨＴＴＰ通信を行う。通信処理部３１は、利用者が必要なファイルをダウンロードして導入されてもよいし、ＵＳＢメモリ等の記録媒体をクライアントＰＣ１に接続することによって導入されてもよい。なお、通信処理部３１は、接続サーバのＵＲＬをあらかじめ記憶しているか、もしくは利用者が適宜設定する。
【００２９】
ネットワーク３は、例えば、インターネットおよびそれにダイアルアップ又は光ファイバー等で接続するための公衆網である。
【００３０】
接続サーバ１２は、ファイアーウォール１１を経由してネットワーク３に接続されており、アクセス許可リスト１３に基づいて、クライアントＰＣ１からのアクセスを許可する。アクセス許可リスト１３は、接続サーバ１２の図示しない記憶装置に記録され、必要に応じて参照される。接続サーバ１２及びファイアーウォール１１は、隔離ネットワーク４２とネットワーク３との境界に位置する非武装地帯４１（ＤＭＺ：ＤｅＭｉｌｉｔａｒｉｚｅｄ Ｚｏｎｅ）に設置されている。
【００３１】
接続サーバ１２は、クライアントＰＣ１からＷｅｂサーバ２２、２３へのＨＴＴＰ要求を受け付けると、その要求の先であるＷｅｂサーバがその利用者によるアクセスが許可されたものであるかどうかを判断する。そのアクセスが許可されている場合にのみ、接続サーバ１２はＷｅｂサーバ２２、２３へＨＴＴＰ要求を送信する。また、接続サーバ１２は、送信したＨＴＴＰ要求に対するＷｅｂサーバ２２，２３からの処理結果を受けて、これをクライアントＰＣ１へ応答を行う。
【００３２】
非武装地帯４１は、ネットワーク３と隔離ネットワーク４２とを中継するネットワークセグメントである。非武装地帯４１は、ファイアーウォール１１及び２１によって、ネットワーク３からも隔離ネットワーク４２からも独立している。この非武装地帯４１は、外部のネットワーク３から不正なアクセスを遮断する目的で設けられているものである。
【００３３】
Ｗｅｂサーバ２２、２３は、ファイアーウォール２１を介して接続サーバ１２及びファイアーウォール１１に接続されており、クライアントＰＣ１からのＨＴＴＰまたはＨＴＴＰＳでの要求に基づき、必要な処理を実行し、その結果をクライアントＰＣ１に返す。Ｗｅｂサーバ２２、２３及びファイアーウォール２１は、共に隔離ネットワーク４２の内部に設置されている。隔離ネットワーク４２は、例えば、企業内に構築されるネットワークであって、ＬＡＮやＷＡＮ等で構成されている。
【００３４】
図２に、クライアントＰＣ１の通信処理部３１のモジュール構成を示す。通信処理部３１は、設定管理部５１と、アクセス管理部５２と、アクセス制御部５３の各モジュールから構成されている。
【００３５】
設定管理部５１は、Ｗｅｂブラウザ３２がＨＴＴＰ要求を通信処理部３１に送信するようにするためのプロキシ設定を作成し、Ｗｅｂブラウザ３２の起動時にＷｅｂブラウザ３２がそのプロキシ設定を参照するようにするユーザエージェント管理部５４と、通信処理部３１がそのＨＴＴＰ要求を受信可能な状態にする受信設定部５０からなる。アクセス管理部５２は、接続サーバ１２から、利用者ごとにアクセスが許可されているＵＲＬを含むアクセス許可リスト１３をダウンロードし、これを保持・管理している。アクセス制御部５３は、利用者の操作に基づいて生成されたＨＴＴＰ要求に含まれた接続先のＵＲＬがアクセス許可リスト１３に含まれているか否かを判断し、接続先ＵＲＬがアクセス許可リスト１３に含まれる場合は、ＨＴＴＰ要求を前記内部サーバに送信する。
【００３６】
図３に、接続サーバ１２が保持しているアクセス許可リスト１３の一例を示す。図２のアクセス許可リスト１３において、例えば、利用者ＩＤが「aaaaa1」である利用者に対して、「http://web1.service1.net:8080/path1.html」及び「http://web1.service2.net:8080/dir1/」へのアクセスが許可される。同様に、利用者ＩＤが「bbbbb1」である利用者に対しては、「http://web1.service1.net:8080/path1.html」へのアクセスが許可される。同様に、利用者ＩＤが「bbbbb2」である利用者に対して、「http://web1.service1.net:8080/path1.html」及び「http://web1.service3.net:8080/dir1」へのアクセスが許可される。
【００３７】
図４は、本実施形態のリモートアクセスシステム１００の動作を説明するフローチャートである。まず、利用者が、クライアントＰＣ１において通信処理部３１を起動する。通信処理部３１は、利用者がクライアントＰＣ１に接続されたディスプレイ上のアイコンをクリックして起動しても良いし、利用者がＵＳＢメモリ等の記録媒体をクライアントＰＣ１に接続することよって起動しても良い。
【００３８】
ステップ４０１において通信処理部３１が起動すると、ステップ４０２において、通信処理部３１は、利用者に認証情報、例えばＩＤ及びパスワードの入力を要求する。利用者は、ＩＤおよびパスワードを入力する。通信処理部３１は入力された認証情報を、接続サーバ１２に送信する。
【００３９】
ステップ４２０において、接続サーバ１２は、認証情報を受信すると認証を行い、認証結果を通信処理部３１に送信する。
【００４０】
ステップ４０３において、通信処理部３１は、認証結果が適正であったか否かの判断を行い、認証結果が適正ではなかった場合は、エラーを通知して処理を終了する。一方、認証結果が適正であった場合には、処理はステップ４０４に進む。
【００４１】
ステップ４０４において、通信処理部３１の受信設定部５０は未使用のＴＣＰポートを検索し、そのポートとＩＰアドレスを用いて、通信処理部３１がＷｅｂブラウザ３２からの通信要求を受信可能な状態にする。ＩＰアドレスは、通信処理部３１が稼動するクライアントＰＣ１に割り当てられたＩＰアドレスか、自分自身を表す仮想的なＩＰアドレス（ループバックアドレス）を用いることができる。
セキュリティ上、他のコンピュータからの通信要求を受信できないループバックアドレスを用いるのが望ましい。したがって以降はループバックアドレスを使用するものとして説明する。
【００４２】
ステップ４０６において、通信処理部３１のユーザエージェント管理部５４は、Ｗｅｂブラウザ３２がＨＴＴＰ要求を通信処理部３１に送信するようにするためのプロキシ設定を作成する。具体的には、ユーザエージェント管理部５４は、ステップ４０４でＷｅｂブラウザ３２からの通信要求を受信可能な状態にするのに用いた値（未使用のＴＣＰポート番号とループバックアドレス）を使って、図５（ｂ）に示すプロキシ設定２を作成する。ここでは、使用するプロキシのＩＰアドレスを「127.0.0.1」に設定し、ポート番号をｎｎｎｎに設定する。「127.0.0.1」は、IPv4におけるループバックアドレスであり、ｎｎｎｎはステップ４０４で見つかった未使用のＴＣＰポートの番号である。
【００４３】
後述するように、通信処理部３１はＷｅｂブラウザ３２を起動する際に、起動時パラメタにより、Ｗｅｂブラウザ３２が上記作成したプロキシ設定２を参照するようにする。これにより、従来、Ｗｅｂブラウザ３２はプロキシサーバ「proxy.tokyobbb.co.jp」の８０８０番ポートを使用してＨＴＴＰ通信を行なっていたが、代わって、ｎｎｎｎ番ポートを使用して、通信処理部３１を通じてすべてのＨＴＴＰ通信を行うようになる。すなわち、Ｗｅｂブラウザ３２に対しては、通信処理部３１がプロキシサーバとして動作することになる。
【００４４】
なお、本実施形態では、プロキシ設定２のＩＰアドレスを「127.0.0.1」に設定したが、「localhost」であってもよいし、IPv6においては「::1」(0:0:0:0:0:0:0:1)としてもよい。また、ＯＳによって他のループバックアドレスが定められているのであれば、その値であってもよい。
【００４５】
ステップ４０７において、通信処理部３１のアクセス管理部５２は、さらに、接続サーバ１２からアクセス許可リスト１３をダウンロードする。このとき、接続サーバ１２によって認証された利用者のみに関するアクセス許可リストがダウンロードされる。例えば、図３に示すように、利用者ＩＤが「aaaaa1」である利用者に対して、「http://web1.service1.net:8080/path1.html」及び「http://web1.service2.net:8080/dir1/」というＵＲＬがダウンロードされる。
【００４６】
ステップ４０８において、通信処理部３１のユーザエージェント管理部５４はＷｅｂブラウザ３２を起動する。このとき起動時パラメタを与えることにより、Ｗｅｂブラウザ３２がプロキシ設定１に代わりプロキシ設定２を参照するようにする。Ｗｅｂブラウザ３２は、利用者の処理に応じて、ＨＴＴＰ要求を通信処理部３１に送信する。このＨＴＴＰ要求は、その利用者の利用者ＩＤを含む。
【００４７】
ステップ４０９において、通信処理部３１のアクセス制御部５３は、Ｗｅｂブラウザ３２からＨＴＴＰ要求を受け取ると、ステップ４１０において、ダウンロードしたアクセス許可リスト１３を参照し、そのＨＴＴＰ要求に含まれる接続先ＵＲＬがダウンロードしたアクセス許可リスト１３に含まれているか否かを判断する。
【００４８】
図３を参照しながら具体例を挙げると、利用者ＩＤが「aaaaa1」であるとき、ＨＴＴＰ要求に含まれた接続先ＵＲＬが「http://web1.service1.net:8080/path1.html」であるときは、アクセス許可リスト１３に含まれていると判断する。
【００４９】
このとき、アクセス許可リストのＵＲＬとＨＴＴＰ要求に含まれるＵＲＬを頭から比較し、前者が後者に含まれる関係にあれば（完全一致を含む）、アクセス許可リストに含まれると判断する。
【００５０】
具体的には、利用者ＩＤが「aaaaa1」であるとき、ＨＴＴＰ要求に含まれた接続先ＵＲＬが「http://web1.service1.net:8080/dir1/path2.html」であるときは、図３によれば、アクセス許可リスト１３に含まれていると判断する。これは、「http://web1.service1.net:8080/dir1」の部分が一致しているため、それ以降の値が何であってもそのＵＲＬはアクセス許可リスト１３にあるものと判断する。
【００５１】
他の具体例として、利用者ＩＤが「bbbbb2」であるとき、ＨＴＴＰ要求に含まれた接続先ＵＲＬが「http://web1.service1.net:8080/path1.html」であるときは、図３によれば、アクセス許可リスト１３に含まれていると判断する。一方、ＨＴＴＰ要求に含まれた接続先ＵＲＬが「http://web1.service1.net:8080/path2.html」や「http://web1.service1.net:8080/dir1/path1.html」は、アクセス許可リスト１３にないものと判断する。なお、アクセス許可リストのＵＲＬがファイル名まで指定してある場合は、完全一致の場合のみアクセス許可リストに含まれると判断することとなる。
【００５２】
なお、Ｗｅｂブラウザ３２は、隔離ネットワーク４２内で稼働するＷｅｂサーバ２２，２３のＵＲＬに対してそのままアクセスすることができる。すなわち、Ｗｅｂサーバ２２、２３がJavaScript（登録商標）などのスクリプトエンジンによりＵＲＬがクライアントＰＣ１上で生成されるようなサービスを提供する場合であっても、Ｗｅｂサーバ側を修正することなく利用者がアクセスすることができる。
【００５３】
ステップ４１０において、通信処理部３１のアクセス制御部５３は、ＨＴＴＰ要求に含まれる接続先ＵＲＬがアクセス許可リスト１３に含まれる場合は、ステップ４１２において当該ＨＴＴＰ要求をＨＴＴＰＳプロトコルにより暗号化し、接続サーバ１２にアクセスし、ＨＴＴＰ要求および利用者ＩＤを接続サーバに送信する。
【００５４】
一方、ステップ４１０において、ＨＴＴＰ要求の接続先ＵＲＬがアクセス許可リスト１３に含まれない場合、ステップ４１１において、通信処理部はＨＴＴＰ要求をそのまま、ＨＴＴＰ要求に含まれる接続先ＵＲＬへ送信する。このとき、送信されるＨＴＴＰ要求には、利用者ＩＤは含まれない。
【００５５】
ステップ４２１において、接続サーバ１２は、通信処理部から暗号化されたＨＴＴＰ要求を受信すると、これを復号し、ステップ４２２において、そこに含まれる利用者ＩＤによってアクセス許可リストを検索・参照し、ステップ４１０と同様の方法でＨＴＴＰ要求に含まれる接続先ＵＲＬがアクセス許可リストにあるか否かを判断する。
【００５６】
ステップ４２２において、ＨＴＴＰ要求に利用者ＩＤが含まれない場合、または利用者ＩＤがアクセス許可リスト１３にない場合、不正なＨＴＴＰ要求としてアクセスできない旨を通信処理部３１に返す。
【００５７】
ステップ４２２において、利用者ＩＤがアクセス許可リスト１３にある場合、ステップ４２４において、接続サーバ１２は、当該ＨＴＴＰ要求を、当該ＨＴＴＰ要求に含まれる接続先ＵＲＬ、すなわちＷｅｂサーバ２２又は２３に送信する。従って、クライアントＰＣ１から送信されたＨＴＴＰ要求は、通信処理部３１、ネットワーク３、非武装地帯４１、ファイアーウォール２１、Ｗｅｂサーバ２２又は２３に送信される。受信されたＨＴＴＰ要求に対して、Ｗｅｂサーバ２２又は２３から処理結果が、ファイアーウォール２１、非武装地帯４１、ネットワーク３を通じて通信処理部３１に返される。
【００５８】
以上述べたように、本発明によれば、Ｗｅｂブラウザは、隔離ネットワーク内で稼働するＷｅｂサーバのＵＲＬに対してそのままアクセスすることができる。すなわち、ＷｅｂサーバがJavaScript（登録商標）などのスクリプトエンジンによりＵＲＬがクライアントＰＣ上で生成されるようなサービスを提供する場合であっても、Ｗｅｂサーバ側を修正することなく利用者がアクセスすることができる。
【００５９】
また、本発明によれば、アクセス許可リストを使用してＨＴＴＰ要求の送信先を、接続サーバを経由して接続されるＷｅｂサーバと、それ以外のインターネット等のネットワーク上のＷｅｂサーバ、のいずれかへ切り替えることが可能であるため、クライアントＰＣは、どちらのＷｅｂサーバにもアクセスすることができる。
【００６０】
また、本発明によれば、通信処理部と接続サーバ間の通信はＨＴＴＰＳを用いるので、クライアントＰＣがプロキシサーバを介してインターネットに接続している場合にも利用できる。
【００６１】
また、本発明によれば、ＶＰＮのようなネットワーク層でのデータ送受信ではなく、アプリケーション層でＨＴＴＰ通信の転送を行なうため、ＶＰＮクライアントのようなプログラムをクライアントＰＣにインストールしなくてよい。すなわち、本発明は通信制御部に該当する実行ファイル及び必要なライブラリ類をクライアントＰＣに配置して実行するだけでよい。従って、利用者が管理者権限を持たない場合であっても、本発明を利用することができる。また、本発明では、通信処理部は動作のための設定を自動で行なうので、手動による設定の手間も不要となる。
【００６２】
上述の実施形態は一例であり、本発明の実施形態はこれに限定されない。例えばプロキシ設定１のプロキシサーバがJavaScript（登録商標）プログラムとして設定されていてもよい。また、プロキシサーバ２がない環境でも本発明は実施可能である。その場合、プロキシ設定１にはプロキシサーバに関する値は設定されておらず、プロキシ設定１を参照する通信処理部３１は直接ネットワーク３に接続する。
【００６３】
また、通信処理部３１とＷｅｂブラウザ３２が別のコンピュータにあってもよい。この場合、Ｗｅｂブラウザ３２を実行するコンピュータに通信管理部３１のユーザエージェント管理部５４の機能を導入する。
【００６４】
図４のステップ４０４で受信設定部５０は、それが稼働するクライアントＰＣに割り当てられたＩＰアドレス（１９２．６８.０．１等）と空きＴＣＰポートを用いて通信要求の受信設定を行い、その値をＷｅｂブラウザのコンピュータ上のユーザエージェント管理部５４に送信する。ユーザエージェント管理部５４はそれを用いてプロキシ設定２を作成するとともに、Ｗｅｂブラウザ３２の起動時、起動時パラメタにより、Ｗｅｂブラウザ３２がプロキシ設定２を参照するようにする。
【符号の説明】
【００６５】
１ クライアントＰＣ（リモートアクセス装置）
１２ 接続サーバ
１３ アクセス許可リスト
３１ 通信処理部
３２ Ｗｅｂブラウザ
５０ 受信設定部
５１ 設定管理部
５２ アクセス管理部
５３ アクセス制御部
５４ ユーザエージェント管理部
【技術分野】
【０００１】
本発明は、インターネットに接続したクライアント装置から、隔離ネットワークで稼働するサーバに対するアクセスを提供するリモートアクセス装置、リモートアクセスプログラム、リモートアクセス方法及びリモートアクセスシステムに関する。
【背景技術】
【０００２】
従来より、企業内イントラネットなどの隔離ネットワークからインターネットを経由してＷｅｂサーバ群に対して選択的にアクセスするリモートアクセス技術が知られている。
【０００３】
このようなリモートアクセス技術として、例えば特許文献１に示すようなリバースプロキシサーバ方式がある。この方式では、隔離ネットワークとインターネットの境界にリバースプロキシサーバを設置し、クライアントＰＣはインターネットを経由してリバースプロキシサーバのＵＲＬにアクセスする。隔離ネットワークの管理者は、インターネットを介してアクセスを許すＷＥＢサーバをリバースプロキシサーバに登録する。リバースプロキシサーバへの登録は、インターネットを介してアクセスを許可するＷＥＢサーバのＵＲＬと、それをリバースプロキシサーバ経由でアクセスするためのリバースプロキシサーバのＵＲＬの対によって行う。リバースプロキシサーバは、クライアントＰＣからのＨＴＴＰ要求を、隔離ネットワークで稼働するＷＥＢサーバに転送し、そのＷＥＢサーバによるＨＴＴＰ応答を、クライアントＰＣに転送する。リバースプロキシサーバとクライアントＰＣの間はＨＴＴＰＳを用いて暗号化通信を使用することにより、インターネットを使用して安全に通信する。
【０００４】
また、他の従来のリモートアクセス技術として、特許文献２に記載されているようなＶＰＮ接続方式がある。このＶＰＮ接続方式では、隔離ネットワークとインターネットの境界にＶＰＮルータを設置し、クライアントＰＣにはＶＰＮクライアントをインストールして、ＶＰＮルータとＶＰＮクライアントの間で（インターネットを介して）仮想的なネットワークを構成することにより、隔離ネットワークの一部にクライアントＰＣを接続したのと同じ状態を実現する。
【０００５】
ＶＰＮクライアントは、クライアントＰＣからＷＥＢサーバ宛てのＨＴＴＰ要求となるＩＰデータグラムを暗号化して別のＩＰデータグラムまたはＴＣＰストリームとしてインターネット経由でＶＰＮルータに送信する。ＶＰＮルータは受け取ったＩＰデータグラムまたはＴＣＰストリームからＷＥＢサーバ宛てのＩＰデータグラムを取り出し、それをＷＥＢサーバに送信する。ＷＥＢサーバからのＨＴＴＰ応答は、これとは逆の経路によってクライアントＰＣに送信される。
【０００６】
また、他の従来のリモートアクセス技術として、ＴＣＰトンネル方式がある。このＴＣＰトンネル方式では、隔離ネットワークとインターネットの境界にトンネリングサーバを設置し、クライアントＰＣでトンネリングクライアントを稼働させることで、トンネリングクライアントとトンネリングサーバ間のＴＣＰストリームを使用して、クライアントＰＣからのＨＴＴＰ要求および隔離ネットワークで稼働するＷＥＢサーバからのＨＴＴＰ応答を相互に転送する。
【０００７】
クライアントＰＣが、自ノード内で稼働するトンネリングソフトウェアが提供するサービスポートに対してＨＴＴＰ要求を送信すると、トンネリングクライアントは、そのＨＴＴＰ要求のＴＣＰストリームの内容を暗号化し、別のＴＣＰストリームによってトンネリングサーバ宛てに送信する。トンネリングサーバは、トンネリングクライアントからの通信を受けて、その内容を復号し、別のＴＣＰストリームによってＷＥＢサーバに転送する。
【特許文献１】特開２００４−２９５１６６号公報
【特許文献２】特開２００２−２３２４６０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、特許文献１に記載されたリバースプロキシサーバ方式では、以下のような問題があった。
リバースプロキシサーバ方式では、ＷＥＢサーバのＵＲＬを公開せず、クライアントＰＣはリバースプロキシサーバが提供するＵＲＬにアクセスする。リバースプロキシサーバは、そのクライアントＰＣからのＨＴＴＰ要求を、ＷＥＢサーバに転送する。例えば、リバースプロキシサーバのＵＲＬが、「http://reverse.proxy.server/path1」であり、ＷｅｂサーバのＵＲＬが「http://a.server/path2」である場合、クライアントＰＣは、http://reverse.proxy.server/path1に対するＨＴＴＰ要求を送信する。リバースプロキシサーバは、このＨＴＴＰ要求をhttp://a.server/path2宛てに送信する。逆に、ＷＥＢサーバからのＨＴＴＰ応答にＷＥＢサーバのホスト名を含んだＵＲＬがあるとき、リバースプロキシサーバはそれをリバースプロキシサーバのＵＲＬに書き換える。クライアントＰＣは、隔離ネットワーク上のホスト名を含むhttp://a.server/path2のようなＵＲＬを受け取とっても、そのＵＲＬにはアクセスできないからである。
【０００９】
しかし現在のＷｅｂサーバでは、動的にＵＲＬを変える場合などに、ＨＴＴＰ応答にJavaScript（登録商標）プログラムを含め、このJavaScript（登録商標）プログラムの実行によりＵＲＬを生成する方法が一般的に行なわれている。この場合、JavaScript（登録商標）プログラムはＨＴＴＰ応答を受け取ったクライアントＰＣ上のＷｅｂブラウザで実行されるので、当該ＨＴＴＰ応答を転送するリバースプロキシサーバではＵＲＬを書換えることができず、利用者はＷｅｂサーバにアクセスすることができないという問題があった。仮に、利用者がインターネット経由でリバースプロキシサーバを介してアクセスすることを可能とするには、Ｗｅｂサーバ上のJavaScript（登録商標）プログラムを変更しなければならず、運用時の負荷が増える。また、このＷｅｂサーバが第３者から提供されている製品であった場合は、そもそもそのような変更ができない場合がある。
【００１０】
また、特許文献２に記載されたＶＰＮ接続方式では、以下のような問題があった。
クライアントＰＣにＶＰＮクライアントをインストールし、ＶＰＮルータとの接続設定を予め行っておく必要があり、設定が面倒であるという問題があった。また、ネットワーク環境によっては、クライアントＰＣ自身が別の隔離ネットワークに接続していて、プロキシサーバを介してインターネットに接続する場合もあるが、そのようにクライアントＰＣがプロキシサーバを介してインターネットに接続している場合、プロキシサーバはアプリケーションゲートウェイ（ＨＴＴＰゲートウェイ）として動作するため、ＶＰＮプロトコルを処理できず、したがってＶＰＮクライアントはＶＰＮルータと通信できないという問題があった。
【００１１】
さらに、ＶＰＮクライアントおよびＶＰＮルータはネットワーク層の転送機構であるため、ＵＲＬ単位で選択的にアクセスを許可したり、利用者ごとにアクセスを許可するＵＲＬを設定したりする等の、ネットワーク層より上位の階層でのみ制御可能な処理を行うには、ＶＰＮルータとＷＥＢサーバの間に別途ファイアーウォールなどのセキュリティ装置を設置しなければならず、ハードウェアの設置の手間がかかるという問題があった。
【００１２】
さらに、ＶＰＮクライアントの稼働中は、クライアントＰＣから送信されるＩＰデータグラムのデフォルト経路がこのＶＰＮクライアントによって実装される仮想インタフェースとなっており、すべてのＩＰデータグラムは隔離ネットワークに転送される。このため、ＶＰＮクライアント稼働中は、クライアントＰＣからインターネットで稼働するＷＥＢサーバに直接アクセスすることができないという問題があった。
【００１３】
また、ＴＣＰトンネル方式では、以下の問題があった。
ＴＣＰトンネル方式では、クライアントＰＣがプロキシサーバを介してトンネリングサーバに接続する場合、プロキシサーバの一般的な設定では、ＨＴＴＰＳ以外の暗号化されたＴＣＰストリームの中継は許可せず、したがってクライアントＰＣはトンネリングサーバにアクセスができないという問題があった。
【００１４】
また、クライアントＰＣがプロキシサーバを介さず直接インターネットに接続する場合でも、クライアントＰＣ上で稼働するＷＥＢブラウザは、http://127.0.0.1/pathまたはhttp://localhost/pathという形式のＵＲＬを使用してトンネリングクライアントに対してＨＴＴＰ要求を送信するため、リバースプロキシサーバ方式と同様に、ＷｅｂサーバへのアクセスにはＵＲＬ書換えが必要となってしまい、運用時の負荷の増加またはアクセスができないという問題があった。
【００１５】
そこで、本発明は、ＵＲＬが動的に生成される場合であっても、ＵＲＬの書き換えをせずにアクセスを可能とし、且つクライアントソフトのインストール等をすることなしに簡易な方法で、隔離ネットワーク内のサーバにアクセスを行なわせるリモートアクセス装置を提供することを目的とする。
【課題を解決するための手段】
【００１６】
本発明のリモートアクセス装置は、ネットワーク及び非武装地帯に設置された接続サーバを通じて内部サーバへのアクセスを行うものであって、所定の通信プロトコルに基づいてデータ通信を行うユーザエージェントからのデータを受信可能な状態にする受信設定手段と、
前記ユーザエージェントのプロキシ設定とは異なる他のプロキシ設定を作成し、 前記ユーザエージェントに前記他のプロキシ設定を参照させるためのユーザエージェント管理手段と、前記接続サーバから、利用者ごとにアクセスが許可されているＵＲＬを含むアクセス許可リストをダウンロードし、保持するアクセス管理手段と、前記利用者の操作に基づいて生成された通信要求に含まれた接続先が前記アクセス許可リストに含まれているか否かを判断し、前記接続先が前記アクセス許可リストに含まれる場合は、前記要求を前記内部サーバに送信するアクセス制御手段とを備えることを特徴とする。
【００１７】
また、本発明のリモートアクセス装置は、さらに、前記受信設定手段が、使用されていないポートを検索し、検索の結果見つかった、使用されていないポートを使用してユーザエージェントからのデータを受信可能な状態にすることを特徴とする。
【００１８】
また、本発明のリモートアクセス装置は、前記アクセス管理手段が、利用者の認証情報を前記接続サーバに送信し、前記接続サーバによる認証がされた場合、前記アクセス許可リストをダウンロードすることを特徴とする。
【００１９】
また、本発明のリモートアクセス装置は、前記アクセス制御手段が、前記接続サーバとの通信をＨＴＴＰＳで行うことを特徴とする。
【００２０】
また、本発明のリモートアクセス装置は、前記他のプロキシ設定において、前記ユーザエージェントが使用するＩＰアドレスがループバックアドレスにされていることを特徴とする。
【発明の効果】
【００２１】
本発明によれば、アクセス許可リストを使用して通信要求の接続先を、接続サーバを経由して接続される内部サーバと、それ以外のインターネット等のネットワーク上のサーバ、のいずれかへ切り替えることが可能であるため、リモートアクセス装置は、どちらのサーバにもアクセスすることができるという効果がある。
【００２２】
また、本発明によれば、クライアントＰＣと接続サーバ間の通信はＨＴＴＰＳを用いるので、リモートアクセス装置がプロキシサーバ（一般的な設定ではＨＴＴＰＳ以外の暗号化通信を中継しない）を介してインターネットに接続している場合にも利用できるという効果がある。
【００２３】
また、本発明によれば、ＶＰＮのようなネットワーク層でのデータ送受信ではなく、アプリケーション層でＨＴＴＰ通信の転送を行なうため、ＶＰＮクライアントをインストールしなくてよい。また、本発明によれば、設定管理部は動作のための設定を自動で行なうので、手動による設定の手間も不要となるという効果がある。
【図面の簡単な説明】
【００２４】
【図１】本発明の実施形態であるリモートアクセスシステムの構成を示す図である。
【図２】本発明の実施形態の通信処理部の構成を示す図である。
【図３】本発明の実施形態のアクセス許可リストを示す図である。
【図４】本発明の実施形態の処理の流れを示すフローチャートである。
【図５】本発明の実施形態におけるプロキシ設定の変更前の例と変更後の例を示す図である。
【発明を実施するための形態】
【００２５】
以下、本発明の実施形態について、図面を参照して詳細に説明する。
図１は、本発明の実施形態であるリモートアクセスシステムの全体構成を示す。リモートアクセスシステム１００は、クライアントＰＣ１と、プロキシサーバ２と、ネットワーク３と、ファイアーウォール１１と、接続サーバ１２と、ファイアーウォール２１と、Ｗｅｂサーバ２２、２３とから構成されている。
【００２６】
クライアントＰＣ１は、プロキシサーバ２を経由して、ネットワーク３、例えばインターネットに接続されており、利用者の操作に応じてＷｅｂサーバ２２、２３にアクセスを行う汎用コンピュータである。クライアントＰＣ１は、通信処理部３１とＷｅｂブラウザ３２を含む。利用者は、クライアントＰＣ１を操作して、Ｗｅｂブラウザ３２を通じてＷｅｂサーバ２２、２３に接続を行う。クライアントＰＣ１は、例えば利用者が自宅や外出先で利用するパーソナルコンピュータであってもよいし、携帯電話や携帯情報端末であってもよい。
【００２７】
Ｗｅｂブラウザ３２は、所定のプロトコルを用いてネットワークを通じてデータの送受信するユーザエージェントの一例であり、後述するプロキシ設定にしたがってＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ
Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）通信又はＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）で暗号化されたいわゆるＨＴＴＰＳ通信を行う。なお、本実施形態ではＷｅｂブラウザ３２を用いて説明するが、他の通信プロトコルを用いたユーザエージェントであってもよい。
【００２８】
通信処理部３１は、クライアントＰＣ１の未使用のＴＣＰポートを使用して、接続サーバ１２を介して、Ｗｅｂブラウザ３２との間でＨＴＴＰ通信を行なう。ＨＴＴＰ通信に際して、通信処理部３１は、後述するように、Ｗｅｂブラウザ３２がＨＴＴＰ要求を通信処理部３１に送信するようにするためのプロキシ設定（プロキシ設定２）を作成し、Ｗｅｂブラウザ３２の起動時に、Ｗｅｂブラウザ３２がプロキシ設定２を参照するようにするとともに、自身はもとのプロキシ設定（プロキシ設定１）を参照して、ＨＴＴＰ通信を行う。通信処理部３１は、利用者が必要なファイルをダウンロードして導入されてもよいし、ＵＳＢメモリ等の記録媒体をクライアントＰＣ１に接続することによって導入されてもよい。なお、通信処理部３１は、接続サーバのＵＲＬをあらかじめ記憶しているか、もしくは利用者が適宜設定する。
【００２９】
ネットワーク３は、例えば、インターネットおよびそれにダイアルアップ又は光ファイバー等で接続するための公衆網である。
【００３０】
接続サーバ１２は、ファイアーウォール１１を経由してネットワーク３に接続されており、アクセス許可リスト１３に基づいて、クライアントＰＣ１からのアクセスを許可する。アクセス許可リスト１３は、接続サーバ１２の図示しない記憶装置に記録され、必要に応じて参照される。接続サーバ１２及びファイアーウォール１１は、隔離ネットワーク４２とネットワーク３との境界に位置する非武装地帯４１（ＤＭＺ：ＤｅＭｉｌｉｔａｒｉｚｅｄ Ｚｏｎｅ）に設置されている。
【００３１】
接続サーバ１２は、クライアントＰＣ１からＷｅｂサーバ２２、２３へのＨＴＴＰ要求を受け付けると、その要求の先であるＷｅｂサーバがその利用者によるアクセスが許可されたものであるかどうかを判断する。そのアクセスが許可されている場合にのみ、接続サーバ１２はＷｅｂサーバ２２、２３へＨＴＴＰ要求を送信する。また、接続サーバ１２は、送信したＨＴＴＰ要求に対するＷｅｂサーバ２２，２３からの処理結果を受けて、これをクライアントＰＣ１へ応答を行う。
【００３２】
非武装地帯４１は、ネットワーク３と隔離ネットワーク４２とを中継するネットワークセグメントである。非武装地帯４１は、ファイアーウォール１１及び２１によって、ネットワーク３からも隔離ネットワーク４２からも独立している。この非武装地帯４１は、外部のネットワーク３から不正なアクセスを遮断する目的で設けられているものである。
【００３３】
Ｗｅｂサーバ２２、２３は、ファイアーウォール２１を介して接続サーバ１２及びファイアーウォール１１に接続されており、クライアントＰＣ１からのＨＴＴＰまたはＨＴＴＰＳでの要求に基づき、必要な処理を実行し、その結果をクライアントＰＣ１に返す。Ｗｅｂサーバ２２、２３及びファイアーウォール２１は、共に隔離ネットワーク４２の内部に設置されている。隔離ネットワーク４２は、例えば、企業内に構築されるネットワークであって、ＬＡＮやＷＡＮ等で構成されている。
【００３４】
図２に、クライアントＰＣ１の通信処理部３１のモジュール構成を示す。通信処理部３１は、設定管理部５１と、アクセス管理部５２と、アクセス制御部５３の各モジュールから構成されている。
【００３５】
設定管理部５１は、Ｗｅｂブラウザ３２がＨＴＴＰ要求を通信処理部３１に送信するようにするためのプロキシ設定を作成し、Ｗｅｂブラウザ３２の起動時にＷｅｂブラウザ３２がそのプロキシ設定を参照するようにするユーザエージェント管理部５４と、通信処理部３１がそのＨＴＴＰ要求を受信可能な状態にする受信設定部５０からなる。アクセス管理部５２は、接続サーバ１２から、利用者ごとにアクセスが許可されているＵＲＬを含むアクセス許可リスト１３をダウンロードし、これを保持・管理している。アクセス制御部５３は、利用者の操作に基づいて生成されたＨＴＴＰ要求に含まれた接続先のＵＲＬがアクセス許可リスト１３に含まれているか否かを判断し、接続先ＵＲＬがアクセス許可リスト１３に含まれる場合は、ＨＴＴＰ要求を前記内部サーバに送信する。
【００３６】
図３に、接続サーバ１２が保持しているアクセス許可リスト１３の一例を示す。図２のアクセス許可リスト１３において、例えば、利用者ＩＤが「aaaaa1」である利用者に対して、「http://web1.service1.net:8080/path1.html」及び「http://web1.service2.net:8080/dir1/」へのアクセスが許可される。同様に、利用者ＩＤが「bbbbb1」である利用者に対しては、「http://web1.service1.net:8080/path1.html」へのアクセスが許可される。同様に、利用者ＩＤが「bbbbb2」である利用者に対して、「http://web1.service1.net:8080/path1.html」及び「http://web1.service3.net:8080/dir1」へのアクセスが許可される。
【００３７】
図４は、本実施形態のリモートアクセスシステム１００の動作を説明するフローチャートである。まず、利用者が、クライアントＰＣ１において通信処理部３１を起動する。通信処理部３１は、利用者がクライアントＰＣ１に接続されたディスプレイ上のアイコンをクリックして起動しても良いし、利用者がＵＳＢメモリ等の記録媒体をクライアントＰＣ１に接続することよって起動しても良い。
【００３８】
ステップ４０１において通信処理部３１が起動すると、ステップ４０２において、通信処理部３１は、利用者に認証情報、例えばＩＤ及びパスワードの入力を要求する。利用者は、ＩＤおよびパスワードを入力する。通信処理部３１は入力された認証情報を、接続サーバ１２に送信する。
【００３９】
ステップ４２０において、接続サーバ１２は、認証情報を受信すると認証を行い、認証結果を通信処理部３１に送信する。
【００４０】
ステップ４０３において、通信処理部３１は、認証結果が適正であったか否かの判断を行い、認証結果が適正ではなかった場合は、エラーを通知して処理を終了する。一方、認証結果が適正であった場合には、処理はステップ４０４に進む。
【００４１】
ステップ４０４において、通信処理部３１の受信設定部５０は未使用のＴＣＰポートを検索し、そのポートとＩＰアドレスを用いて、通信処理部３１がＷｅｂブラウザ３２からの通信要求を受信可能な状態にする。ＩＰアドレスは、通信処理部３１が稼動するクライアントＰＣ１に割り当てられたＩＰアドレスか、自分自身を表す仮想的なＩＰアドレス（ループバックアドレス）を用いることができる。
セキュリティ上、他のコンピュータからの通信要求を受信できないループバックアドレスを用いるのが望ましい。したがって以降はループバックアドレスを使用するものとして説明する。
【００４２】
ステップ４０６において、通信処理部３１のユーザエージェント管理部５４は、Ｗｅｂブラウザ３２がＨＴＴＰ要求を通信処理部３１に送信するようにするためのプロキシ設定を作成する。具体的には、ユーザエージェント管理部５４は、ステップ４０４でＷｅｂブラウザ３２からの通信要求を受信可能な状態にするのに用いた値（未使用のＴＣＰポート番号とループバックアドレス）を使って、図５（ｂ）に示すプロキシ設定２を作成する。ここでは、使用するプロキシのＩＰアドレスを「127.0.0.1」に設定し、ポート番号をｎｎｎｎに設定する。「127.0.0.1」は、IPv4におけるループバックアドレスであり、ｎｎｎｎはステップ４０４で見つかった未使用のＴＣＰポートの番号である。
【００４３】
後述するように、通信処理部３１はＷｅｂブラウザ３２を起動する際に、起動時パラメタにより、Ｗｅｂブラウザ３２が上記作成したプロキシ設定２を参照するようにする。これにより、従来、Ｗｅｂブラウザ３２はプロキシサーバ「proxy.tokyobbb.co.jp」の８０８０番ポートを使用してＨＴＴＰ通信を行なっていたが、代わって、ｎｎｎｎ番ポートを使用して、通信処理部３１を通じてすべてのＨＴＴＰ通信を行うようになる。すなわち、Ｗｅｂブラウザ３２に対しては、通信処理部３１がプロキシサーバとして動作することになる。
【００４４】
なお、本実施形態では、プロキシ設定２のＩＰアドレスを「127.0.0.1」に設定したが、「localhost」であってもよいし、IPv6においては「::1」(0:0:0:0:0:0:0:1)としてもよい。また、ＯＳによって他のループバックアドレスが定められているのであれば、その値であってもよい。
【００４５】
ステップ４０７において、通信処理部３１のアクセス管理部５２は、さらに、接続サーバ１２からアクセス許可リスト１３をダウンロードする。このとき、接続サーバ１２によって認証された利用者のみに関するアクセス許可リストがダウンロードされる。例えば、図３に示すように、利用者ＩＤが「aaaaa1」である利用者に対して、「http://web1.service1.net:8080/path1.html」及び「http://web1.service2.net:8080/dir1/」というＵＲＬがダウンロードされる。
【００４６】
ステップ４０８において、通信処理部３１のユーザエージェント管理部５４はＷｅｂブラウザ３２を起動する。このとき起動時パラメタを与えることにより、Ｗｅｂブラウザ３２がプロキシ設定１に代わりプロキシ設定２を参照するようにする。Ｗｅｂブラウザ３２は、利用者の処理に応じて、ＨＴＴＰ要求を通信処理部３１に送信する。このＨＴＴＰ要求は、その利用者の利用者ＩＤを含む。
【００４７】
ステップ４０９において、通信処理部３１のアクセス制御部５３は、Ｗｅｂブラウザ３２からＨＴＴＰ要求を受け取ると、ステップ４１０において、ダウンロードしたアクセス許可リスト１３を参照し、そのＨＴＴＰ要求に含まれる接続先ＵＲＬがダウンロードしたアクセス許可リスト１３に含まれているか否かを判断する。
【００４８】
図３を参照しながら具体例を挙げると、利用者ＩＤが「aaaaa1」であるとき、ＨＴＴＰ要求に含まれた接続先ＵＲＬが「http://web1.service1.net:8080/path1.html」であるときは、アクセス許可リスト１３に含まれていると判断する。
【００４９】
このとき、アクセス許可リストのＵＲＬとＨＴＴＰ要求に含まれるＵＲＬを頭から比較し、前者が後者に含まれる関係にあれば（完全一致を含む）、アクセス許可リストに含まれると判断する。
【００５０】
具体的には、利用者ＩＤが「aaaaa1」であるとき、ＨＴＴＰ要求に含まれた接続先ＵＲＬが「http://web1.service1.net:8080/dir1/path2.html」であるときは、図３によれば、アクセス許可リスト１３に含まれていると判断する。これは、「http://web1.service1.net:8080/dir1」の部分が一致しているため、それ以降の値が何であってもそのＵＲＬはアクセス許可リスト１３にあるものと判断する。
【００５１】
他の具体例として、利用者ＩＤが「bbbbb2」であるとき、ＨＴＴＰ要求に含まれた接続先ＵＲＬが「http://web1.service1.net:8080/path1.html」であるときは、図３によれば、アクセス許可リスト１３に含まれていると判断する。一方、ＨＴＴＰ要求に含まれた接続先ＵＲＬが「http://web1.service1.net:8080/path2.html」や「http://web1.service1.net:8080/dir1/path1.html」は、アクセス許可リスト１３にないものと判断する。なお、アクセス許可リストのＵＲＬがファイル名まで指定してある場合は、完全一致の場合のみアクセス許可リストに含まれると判断することとなる。
【００５２】
なお、Ｗｅｂブラウザ３２は、隔離ネットワーク４２内で稼働するＷｅｂサーバ２２，２３のＵＲＬに対してそのままアクセスすることができる。すなわち、Ｗｅｂサーバ２２、２３がJavaScript（登録商標）などのスクリプトエンジンによりＵＲＬがクライアントＰＣ１上で生成されるようなサービスを提供する場合であっても、Ｗｅｂサーバ側を修正することなく利用者がアクセスすることができる。
【００５３】
ステップ４１０において、通信処理部３１のアクセス制御部５３は、ＨＴＴＰ要求に含まれる接続先ＵＲＬがアクセス許可リスト１３に含まれる場合は、ステップ４１２において当該ＨＴＴＰ要求をＨＴＴＰＳプロトコルにより暗号化し、接続サーバ１２にアクセスし、ＨＴＴＰ要求および利用者ＩＤを接続サーバに送信する。
【００５４】
一方、ステップ４１０において、ＨＴＴＰ要求の接続先ＵＲＬがアクセス許可リスト１３に含まれない場合、ステップ４１１において、通信処理部はＨＴＴＰ要求をそのまま、ＨＴＴＰ要求に含まれる接続先ＵＲＬへ送信する。このとき、送信されるＨＴＴＰ要求には、利用者ＩＤは含まれない。
【００５５】
ステップ４２１において、接続サーバ１２は、通信処理部から暗号化されたＨＴＴＰ要求を受信すると、これを復号し、ステップ４２２において、そこに含まれる利用者ＩＤによってアクセス許可リストを検索・参照し、ステップ４１０と同様の方法でＨＴＴＰ要求に含まれる接続先ＵＲＬがアクセス許可リストにあるか否かを判断する。
【００５６】
ステップ４２２において、ＨＴＴＰ要求に利用者ＩＤが含まれない場合、または利用者ＩＤがアクセス許可リスト１３にない場合、不正なＨＴＴＰ要求としてアクセスできない旨を通信処理部３１に返す。
【００５７】
ステップ４２２において、利用者ＩＤがアクセス許可リスト１３にある場合、ステップ４２４において、接続サーバ１２は、当該ＨＴＴＰ要求を、当該ＨＴＴＰ要求に含まれる接続先ＵＲＬ、すなわちＷｅｂサーバ２２又は２３に送信する。従って、クライアントＰＣ１から送信されたＨＴＴＰ要求は、通信処理部３１、ネットワーク３、非武装地帯４１、ファイアーウォール２１、Ｗｅｂサーバ２２又は２３に送信される。受信されたＨＴＴＰ要求に対して、Ｗｅｂサーバ２２又は２３から処理結果が、ファイアーウォール２１、非武装地帯４１、ネットワーク３を通じて通信処理部３１に返される。
【００５８】
以上述べたように、本発明によれば、Ｗｅｂブラウザは、隔離ネットワーク内で稼働するＷｅｂサーバのＵＲＬに対してそのままアクセスすることができる。すなわち、ＷｅｂサーバがJavaScript（登録商標）などのスクリプトエンジンによりＵＲＬがクライアントＰＣ上で生成されるようなサービスを提供する場合であっても、Ｗｅｂサーバ側を修正することなく利用者がアクセスすることができる。
【００５９】
また、本発明によれば、アクセス許可リストを使用してＨＴＴＰ要求の送信先を、接続サーバを経由して接続されるＷｅｂサーバと、それ以外のインターネット等のネットワーク上のＷｅｂサーバ、のいずれかへ切り替えることが可能であるため、クライアントＰＣは、どちらのＷｅｂサーバにもアクセスすることができる。
【００６０】
また、本発明によれば、通信処理部と接続サーバ間の通信はＨＴＴＰＳを用いるので、クライアントＰＣがプロキシサーバを介してインターネットに接続している場合にも利用できる。
【００６１】
また、本発明によれば、ＶＰＮのようなネットワーク層でのデータ送受信ではなく、アプリケーション層でＨＴＴＰ通信の転送を行なうため、ＶＰＮクライアントのようなプログラムをクライアントＰＣにインストールしなくてよい。すなわち、本発明は通信制御部に該当する実行ファイル及び必要なライブラリ類をクライアントＰＣに配置して実行するだけでよい。従って、利用者が管理者権限を持たない場合であっても、本発明を利用することができる。また、本発明では、通信処理部は動作のための設定を自動で行なうので、手動による設定の手間も不要となる。
【００６２】
上述の実施形態は一例であり、本発明の実施形態はこれに限定されない。例えばプロキシ設定１のプロキシサーバがJavaScript（登録商標）プログラムとして設定されていてもよい。また、プロキシサーバ２がない環境でも本発明は実施可能である。その場合、プロキシ設定１にはプロキシサーバに関する値は設定されておらず、プロキシ設定１を参照する通信処理部３１は直接ネットワーク３に接続する。
【００６３】
また、通信処理部３１とＷｅｂブラウザ３２が別のコンピュータにあってもよい。この場合、Ｗｅｂブラウザ３２を実行するコンピュータに通信管理部３１のユーザエージェント管理部５４の機能を導入する。
【００６４】
図４のステップ４０４で受信設定部５０は、それが稼働するクライアントＰＣに割り当てられたＩＰアドレス（１９２．６８.０．１等）と空きＴＣＰポートを用いて通信要求の受信設定を行い、その値をＷｅｂブラウザのコンピュータ上のユーザエージェント管理部５４に送信する。ユーザエージェント管理部５４はそれを用いてプロキシ設定２を作成するとともに、Ｗｅｂブラウザ３２の起動時、起動時パラメタにより、Ｗｅｂブラウザ３２がプロキシ設定２を参照するようにする。
【符号の説明】
【００６５】
１ クライアントＰＣ（リモートアクセス装置）
１２ 接続サーバ
１３ アクセス許可リスト
３１ 通信処理部
３２ Ｗｅｂブラウザ
５０ 受信設定部
５１ 設定管理部
５２ アクセス管理部
５３ アクセス制御部
５４ ユーザエージェント管理部
【特許請求の範囲】
【請求項１】
ネットワーク及び非武装地帯に設置された接続サーバを通じて内部サーバへのアクセスを行うリモートアクセス装置であって、
所定の通信プロトコルに基づいてデータ通信を行うユーザエージェントからのデータを受信可能な状態にする受信設定手段と、
前記ユーザエージェントのプロキシ設定とは異なる他のプロキシ設定を作成し、前記ユーザエージェントに前記他のプロキシ設定を参照させるためのユーザエージェント管理手段と、
前記接続サーバから、利用者ごとにアクセスが許可されているＵＲＬを含むアクセス許可リストをダウンロードし、保持するアクセス管理手段と、
前記利用者の操作に基づいて生成された通信要求に含まれた接続先が前記アクセス許可リストに含まれているか否かを判断し、前記接続先が前記アクセス許可リストに含まれる場合は、前記要求を前記内部サーバに送信するアクセス制御手段と
を備えることを特徴とするリモートアクセス装置。
【請求項２】
前記受信設定手段は、使用されていないポートを検索し、検索の結果見つかった使用されていないポートを使用してユーザエージェントからのデータを受信可能な状態にすることを特徴とする請求項１記載のリモートアクセス装置。
【請求項３】
前記アクセス管理手段は、利用者の認証情報を前記接続サーバに送信し、前記接続サーバによる認証がされた場合、前記アクセス許可リストをダウンロードすることを特徴とする請求項１又は２記載のリモートアクセス装置。
【請求項４】
前記アクセス制御手段は、前記接続サーバとの通信をＨＴＴＰＳで行うことを特徴とする請求項１から３記載のリモートアクセス装置。
【請求項５】
前記他のプロキシ設定において、前記ユーザエージェントがプロキシサーバとして使用するＩＰアドレスがループバックアドレスにされていることを特徴とする請求項１〜４のいずれかに記載のリモートアクセス装置。
【請求項６】
ネットワーク及び非武装地帯に設置された接続サーバを通じて内部サーバへのアクセスを行うリモートアクセスプログラムであって、
所定の通信プロトコルに基づいてデータ通信を行うユーザエージェントからのデータを受信可能な状態にする受信設定手段と、
前記ユーザエージェントのプロキシ設定とは異なる他のプロキシ設定を作成し、前記ユーザエージェントに前記他のプロキシ設定を参照させるためのユーザエージェント管理手段と、
前記接続サーバから、利用者ごとにアクセスが許可されているＵＲＬを含むアクセス許可リストをダウンロードし、保持するアクセス管理手段と、
前記利用者の操作に基づいて生成された通信要求に含まれた接続先が前記アクセス許可リストに含まれているか否かを判断し、前記接続先が前記アクセス許可リストに含まれる場合は、前記要求を前記内部サーバに送信するアクセス制御手段と
を備えることを特徴とするリモートアクセスプログラム。
【請求項７】
ネットワーク及び非武装地帯に設置された接続サーバを通じて内部サーバへのアクセスを行うリモートアクセス方法であって、
所定の通信プロトコルに基づいてデータ通信を行うユーザエージェントからのデータを受信可能な状態にする受信設定工程と、
前記ユーザエージェントのプロキシ設定とは異なる他のプロキシ設定を作成し、前記ユーザエージェントに前記他のプロキシ設定を参照させるためのユーザエージェント管理工程と、
前記接続サーバから、利用者ごとにアクセスが許可されているＵＲＬを含むアクセス許可リストをダウンロードし、保持するアクセス管理工程と、
前記利用者の操作に基づいて生成された通信要求に含まれた接続先が前記アクセス許可リストに含まれているか否かを判断し、前記接続先が前記アクセス許可リストに含まれる場合は、前記要求を前記内部サーバに送信するアクセス制御工程と
を備えることを特徴とするリモートアクセス方法。
【請求項８】
クライアントからネットワーク及び非武装地帯に設置された接続サーバを通じて、隔離ネットワークに設置された内部サーバへのアクセスを行うリモートアクセスシステムであって、
前記クライアントは、
所定の通信プロトコルに基づいてデータ通信を行うユーザエージェントからのデータを受信可能な状態にする受信設定手段と、
前記ユーザエージェントのプロキシ設定とは異なる他のプロキシ設定を作成し、前記ユーザエージェントに前記他のプロキシ設定を参照させるためのユーザエージェント管理手段と、
前記接続サーバから、利用者ごとにアクセスが許可されているＵＲＬを含むアクセス許可リストをダウンロードし、保持するアクセス管理手段と、
前記利用者の操作に基づいて生成された通信要求に含まれた接続先が前記アクセス許可リストに含まれているか否かを判断し、前記接続先が前記アクセス許可リストに含まれる場合は、前記要求を前記内部サーバに送信するアクセス制御手段を備え、
前記接続サーバは、
前記アクセス許可リストを保持し、前記クライアントの要求に応じて利用者ごとに前記アクセス許可リストを前記クライアントに送信する手段を備え、
前記接続先が前記アクセス許可リストに含まれる場合に送信された前記クライアントからの通信要求を、前記接続サーバに保持された前記アクセス許可リストに基づいて、前記内部サーバに送信することを特徴とするリモートアクセスシステム。
【請求項１】
ネットワーク及び非武装地帯に設置された接続サーバを通じて内部サーバへのアクセスを行うリモートアクセス装置であって、
所定の通信プロトコルに基づいてデータ通信を行うユーザエージェントからのデータを受信可能な状態にする受信設定手段と、
前記ユーザエージェントのプロキシ設定とは異なる他のプロキシ設定を作成し、前記ユーザエージェントに前記他のプロキシ設定を参照させるためのユーザエージェント管理手段と、
前記接続サーバから、利用者ごとにアクセスが許可されているＵＲＬを含むアクセス許可リストをダウンロードし、保持するアクセス管理手段と、
前記利用者の操作に基づいて生成された通信要求に含まれた接続先が前記アクセス許可リストに含まれているか否かを判断し、前記接続先が前記アクセス許可リストに含まれる場合は、前記要求を前記内部サーバに送信するアクセス制御手段と
を備えることを特徴とするリモートアクセス装置。
【請求項２】
前記受信設定手段は、使用されていないポートを検索し、検索の結果見つかった使用されていないポートを使用してユーザエージェントからのデータを受信可能な状態にすることを特徴とする請求項１記載のリモートアクセス装置。
【請求項３】
前記アクセス管理手段は、利用者の認証情報を前記接続サーバに送信し、前記接続サーバによる認証がされた場合、前記アクセス許可リストをダウンロードすることを特徴とする請求項１又は２記載のリモートアクセス装置。
【請求項４】
前記アクセス制御手段は、前記接続サーバとの通信をＨＴＴＰＳで行うことを特徴とする請求項１から３記載のリモートアクセス装置。
【請求項５】
前記他のプロキシ設定において、前記ユーザエージェントがプロキシサーバとして使用するＩＰアドレスがループバックアドレスにされていることを特徴とする請求項１〜４のいずれかに記載のリモートアクセス装置。
【請求項６】
ネットワーク及び非武装地帯に設置された接続サーバを通じて内部サーバへのアクセスを行うリモートアクセスプログラムであって、
所定の通信プロトコルに基づいてデータ通信を行うユーザエージェントからのデータを受信可能な状態にする受信設定手段と、
前記ユーザエージェントのプロキシ設定とは異なる他のプロキシ設定を作成し、前記ユーザエージェントに前記他のプロキシ設定を参照させるためのユーザエージェント管理手段と、
前記接続サーバから、利用者ごとにアクセスが許可されているＵＲＬを含むアクセス許可リストをダウンロードし、保持するアクセス管理手段と、
前記利用者の操作に基づいて生成された通信要求に含まれた接続先が前記アクセス許可リストに含まれているか否かを判断し、前記接続先が前記アクセス許可リストに含まれる場合は、前記要求を前記内部サーバに送信するアクセス制御手段と
を備えることを特徴とするリモートアクセスプログラム。
【請求項７】
ネットワーク及び非武装地帯に設置された接続サーバを通じて内部サーバへのアクセスを行うリモートアクセス方法であって、
所定の通信プロトコルに基づいてデータ通信を行うユーザエージェントからのデータを受信可能な状態にする受信設定工程と、
前記ユーザエージェントのプロキシ設定とは異なる他のプロキシ設定を作成し、前記ユーザエージェントに前記他のプロキシ設定を参照させるためのユーザエージェント管理工程と、
前記接続サーバから、利用者ごとにアクセスが許可されているＵＲＬを含むアクセス許可リストをダウンロードし、保持するアクセス管理工程と、
前記利用者の操作に基づいて生成された通信要求に含まれた接続先が前記アクセス許可リストに含まれているか否かを判断し、前記接続先が前記アクセス許可リストに含まれる場合は、前記要求を前記内部サーバに送信するアクセス制御工程と
を備えることを特徴とするリモートアクセス方法。
【請求項８】
クライアントからネットワーク及び非武装地帯に設置された接続サーバを通じて、隔離ネットワークに設置された内部サーバへのアクセスを行うリモートアクセスシステムであって、
前記クライアントは、
所定の通信プロトコルに基づいてデータ通信を行うユーザエージェントからのデータを受信可能な状態にする受信設定手段と、
前記ユーザエージェントのプロキシ設定とは異なる他のプロキシ設定を作成し、前記ユーザエージェントに前記他のプロキシ設定を参照させるためのユーザエージェント管理手段と、
前記接続サーバから、利用者ごとにアクセスが許可されているＵＲＬを含むアクセス許可リストをダウンロードし、保持するアクセス管理手段と、
前記利用者の操作に基づいて生成された通信要求に含まれた接続先が前記アクセス許可リストに含まれているか否かを判断し、前記接続先が前記アクセス許可リストに含まれる場合は、前記要求を前記内部サーバに送信するアクセス制御手段を備え、
前記接続サーバは、
前記アクセス許可リストを保持し、前記クライアントの要求に応じて利用者ごとに前記アクセス許可リストを前記クライアントに送信する手段を備え、
前記接続先が前記アクセス許可リストに含まれる場合に送信された前記クライアントからの通信要求を、前記接続サーバに保持された前記アクセス許可リストに基づいて、前記内部サーバに送信することを特徴とするリモートアクセスシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２０１１−１００２０７（Ｐ２０１１−１００２０７Ａ）
【公開日】平成２３年５月１９日（２０１１．５．１９）
【国際特許分類】
【出願番号】特願２００９−２５３２１４（Ｐ２００９−２５３２１４）
【出願日】平成２１年１１月４日（２００９．１１．４）
【出願人】（５９１０３０２３７）日本ユニシス株式会社 (38)
【Ｆターム（参考）】
【公開日】平成２３年５月１９日（２０１１．５．１９）
【国際特許分類】
【出願日】平成２１年１１月４日（２００９．１１．４）
【出願人】（５９１０３０２３７）日本ユニシス株式会社 (38)
【Ｆターム（参考）】
[ Back to top ]