JP2009037478A - 情報通信方法 - Google Patents

Abstract

【課題】トンネル接続を経て、ウェブクライアントからウェブサーバへのアクセスを可能にする。
【解決手段】外部プロキシサーバ１０５と複数の内部プロキシサーバ２０５，３０５とでトンネル接続確立後、ウェブクライアント１１１が、外部プロキシサーバ１０５に接続してＨＴＴＰリクエストを送信する工程と、外部プロキシサーバ１０５が、受信したＨＴＴＰリクエストをトンネル接続を経由して内部プロキシサーバ２０５等に送信する工程と、内部プロキシサーバ２０５等が、受信したＨＴＴＰリクエストをウェブサーバ２１１に送信する工程と、ウェブサーバ２１１が、内部プロキシサーバ２０５等にＨＴＴＰレスポンスを返信する工程と、内部プロキシサーバ２０５等が、外部プロキシサーバ１０５にＨＴＴＰレスポンスを返信する工程と、外部プロキシサーバ１０５が、ウェブクライアント１１１にＨＴＴＰレスポンスを返信する工程とからなる。
【選択図】図１

Description

本発明は、ファイアウォール外部に外部プロキシサーバとウェブクライアントとを設置し、複数のファイアウォール内部にそれぞれ内部プロキシサーバとウェブサーバとを設置した情報通信システムにおける情報通信方法に関する。

近年、家庭電化製品やオフィス機器等の各種の電子機器に組み込まれたものも含めて、ＰＣ（パーソナルコンピュータ）に代表されるような各種のコンピュータ装置の高機能化に伴い、これらを所有するエンドユーザに対するサポート業務がより重要になってきている。機器のメインテナンス等のサポートを行うために、従来はＰＣ等をサポートセンターに持ち込むか、或いはサポートスタッフをＰＣ等の設置場所に派遣するなどの必要があり、非常にコストがかかっているのが現状であった。この問題を解決する方法として、インターネット等の通信ネットワーク接続を利用して、サポートセンターのオペレータがＰＣ等にリモートアクセスを行ってサポートを行う方式が考えられている。

一方、近年のブロードバンド通信の普及により、一般家庭や各企業においてインターネットへ安価に常時接続を行うことが可能となっている。インターネットにおいては、ネットワーク越しのＰＣ等への不正アクセスやＤｏＳ（Ｄｅｎｉａｌ ｏｆ Ｓｅｒｖｉｃｅ ａｔｔａｃｋ）／ｐｉｎｇ／ＲＩＰ（Ｒｏｕｔｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）攻撃等のセキュリティの問題が存在している。そのため、インターネット接続に使用されるいわゆるブロードバンドルータ等の機材においては、ＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）機能やファイアウォール機能を持つものが一般的に普及している。

ＮＡＴ機能は、家庭内もしくは企業内でのみ通信できるプライベートＩＰアドレスとインターネット上で通信できるユニークなグローバルＩＰアドレスとを変換する機能であり、またファイアウォール機能は、インターネットと内部ネットワークとの間で特定の通信のみを許可する機能である。どちらの機能も、内部ネットワークからインターネットに向けて発生した正当な通信は許可するが、インターネット側から内部ネットワークに向けて発生した通信は、予め設定されている通信以外は不正なものとして遮断する、という動作を行うもので、インターネット接続に使用されるブロードバンドルータ等の機材ではそのような機能が一般的である。

このような背景から、リモート操作を受けるコンピュータからのコール信号に基づきサポート対象のコンピュータを特定して遠隔操作等を行うリモート操作方法及びそのシステムが提供されている。

また、クライアント側コンピュータから一旦ＷＷＷサーバに接続させることでクライアント側コンピュータのＩＰアドレスを特定して、クライアント側コンピュータを遠隔操作するサポートシステムも提供されている（例えば、特許文献１参照）。

特許文献１に記載のリモートアクセスシステムは、通信ネットワークに接続されたユーザ側ＰＣをサポートセンターのオペレータ端末からの遠隔操作によって維持・管理するシステムであって、不特定多数のユーザ側ＰＣと、ユーザ側ＰＣからの接続要求によりユーザ側ＰＣとサポートセンター間のコネクションを確立しコネクションの内部でトンネル接続を行うことでオペレータ端末からユーザ側ＰＣを遠隔操作可能にするサポートセンタサーバと、ユーザ側ＰＣを遠隔操作するＷｅｂブラウザを備えたオペレータ端末とで構成され、ユーザ側ＰＣはトンネル接続によりオペレータ端末からの遠隔操作を受け付けるリモートアクセス用Ｗｅｂサーバと、オペレータ端末からの遠隔操作によりユーザ側ＰＣの維持・管理を行うためのリモートサポートアプリケーションとを備えた構成となっている。
特開２００５−２６８５６号公報

ファイアウォール内の情報を取得する方法としては、ファイアウォールの設定で特定の外部からのアクセスを許可する方法と、上記特許文献１にもあるように、ファイアウォール内に通信をトンネルするソフトを実行し、ファイアウォール内とファイアウォール外のプライベートネットワークを仮想的に接続するＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）の方法とがある。

しかし、ファイアウォールの設定で特定の外部からのアクセスを許可する方法の場合、外部にアクセス方法を教える必要がある。この場合、通常のＨＴＴＰプロキシサーバは、ファイアウォールの内側から外側のウェブサイトにアクセスできるが、外側からファイアウォール内部のウェブサイトの情報を取得することが出来ないといった問題があった。また、ＶＰＮの方法では、ＶＰＮをファイアウォール外のネットワークに合わせる必要がある。

本発明はかかる問題点を解決すべく創案されたもので、その目的は、ファイアウォール外部に外部プロキシサーバ（本体）とウェブクライアント（端末）とを配置し、複数のファイアウォール内部にそれぞれ内部プロキシサーバ（出島）とウェブサーバ（ターゲット）とを設置して、トンネル接続を確立させて、ウェブクライアント（端末）からウェブサーバ（ターゲット）へのアクセスを可能にすることで、オープンポートの情報を外部に示す必要がなく、安全性の高い情報通信方法を提供することになる。

上記課題を解決するため、本発明の情報通信方法は、ファイアウォール外部に外部プロキシサーバとウェブクライアントとを設置し、複数のファイアウォール内部にそれぞれ内部プロキシサーバとウェブサーバとを設置した情報通信システムにおける情報通信方法であって、前記外部プロキシサーバと前記内部プロキシサーバとの間でトンネル接続を確立させる第1工程と、トンネル接続確立後、前記ウェブクライアントが、利用者の操作に応じて、前記外部プロキシサーバに接続し、ＨＴＴＰリクエストを送信する第２工程と、前記外部プロキシサーバが、前記ウェブクライアントからのＨＴＴＰリクエストを受信し、前記トンネル接続を経由して前記内部プロキシサーバに送信する第３工程と、前記内部プロキシサーバが、前記外部プロキシサーバからのＨＴＴＰリクエストを受信し、前記ウェブサーバに送信する第４工程と、前記ウェブサーバが、前記内部プロキシサーバに前記ＨＴＴＰリクエストに応じたＨＴＴＰレスポンスを返信する第５工程と、前記内部プロキシサーバが、前記外部プロキシサーバに前記ＨＴＴＰレスポンスを返信する第６工程と、前記外部プロキシサーバが、前記ウェブクライアントにＨＴＴＰレスポンスを返信する第７工程と、を備えていることを特徴としている。

本発明によれば、ファイアウォール外部に設置された外部プロキシサーバと、ファイアウォール内部に設置された内部プロキシサーバとでトンネル接続を確立しているので、ファイアウォールの特定ポートを開く方法と比較し、オープンポートの情報を外部に示す必要がなく安全性が向上する。また、ファイアウォール内部の内部プロキシサーバからファイアウォール外部の外部プロキシサーバに対してトンネル接続を確立することで、不特定のクライアントからアクセスを遮断する効果がある。さらに、情報提供側が内部プロキシサーバを管理して、内部プロキシサーバを停止することによって、外部からのアクセスを完全に遮断することができる。

また、本発明の情報通信方法によれば、前記複数の内部プロキシサーバのそれぞれには、予め接続を許可する前記ウェブサーバのアドレスが記録されており、前記第４工程では、トンネル接続を経由して前記外部プロキシサーバから受信したＨＴＴＰリクエストのアドレスが、内部に記録されている前記許可するアドレスと一致した場合のみ、一致したアドレスのウェブサーバに前記ＨＴＴＰリクエストを送信する構成とすることができる。この構成によれば、接続を許可するアドレスの情報を内部プロキシサーバに持ち、それ以外は拒否することにより、外部から不必要なサーバにアクセスされることを防ぐことができる。

また、本発明の情報通信方法によれば、前記複数の内部プロキシサーバのそれぞれには、予め接続を禁止する前記ウェブサーバのアドレスが記録されており、前記第４工程では、トンネル接続を経由して前記外部プロキシサーバから受信したＨＴＴＰリクエストのアドレスが、内部に記録されている前記禁止するアドレスと一致した場合には、ウェブサーバへの送信を行わない構成とすることができる。この構成によれば、監視対象のウェブサーバが多数あった場合、アクセスを禁止するアドレスのみを設定すればよいので設定が容易となる。

また、本発明の情報通信方法によれば、前記複数の内部プロキシサーバのそれぞれには、予め送信を禁止または許可する前記ウェブサーバのアドレスを示す特定のパターンが記録されており、前記第４工程では、トンネル接続を経由して前記外部プロキシサーバから受信したＨＴＴＰリクエストのアドレスのパターンが、内部に記録されている前記禁止または許可するアドレスのパターンと一致した場合に、一致したパターンのアドレスのウェブサーバへの送信を禁止または許可する構成とすることができる。この構成によれば、複数のアドレスに関して、まとめて許可または禁止を設定できるので、設定が容易になる。

また、本発明の情報通信方法によれば、前記複数の内部プロキシサーバのそれぞれは、正規の切断操作以外でトンネル接続が切断されたことを検出する工程を備え、トンネル接続が正規の切断操作以外で切断されたことを検出した場合には、再度、トンネル接続の確立を試す構成とすることができる。通常、インターネット上の接続は保証されない。また、外部ファイアウォールや外部プロキシサーバ側などで不測の問題が発生した場合、トンネル接続が切断される場合がある。このとき自動的に再接続を行うことにより、安定した通信路を維持することができる。

また、本発明の情報通信方法によれば、前記複数の内部プロキシサーバのそれぞれには、トンネル接続開始時刻とトンネル接続切断時刻の情報が記録されており、前記第１工程では、前記トンネル接続開始時刻になると前記外部プロキシサーバとのトンネル接続を確立し、前記トンネル接続切断時刻になると前記トンネル接続を切断する構成とすることができる。この構成によれば、内部プロキシサーバに記録されている特定の時間のみ接続することが可能となり、外部からの不正アクセスの可能性を減らすことができる。

また、本発明の情報通信方法によれば、前記第３工程では、前記外部プロキシサーバが、ウェブクライアントからのＨＴＴＰリクエストを暗号化し、暗号化したＨＴＴＰリクエストを前記内部プロキシサーバに送信し、前記第４工程では、前記内部プロキシサーバが、受信したＨＴＴＰリクエストを復号し、復号したＨＴＴＰリクエストをウェブサーバに送信し、前記第５工程では、前記内部プロキシサーバが、ウェブサーバからのＨＴＴＰレスポンスを暗号化し、暗号化したＨＴＴＰレスポンスを前記外部プロキシサーバに送信し、前記第６工程では、前記外部プロキシサーバが、暗号化されている前記ＨＴＴＰレスポンスを復号し、復号したＨＴＴＰレスポンスを前記ウェブクライアントに送信する構成とすることができる。この構成によれば、外部プロキシサーバと内部プロキシサーバとの間で相互に暗号化と復号化を行うので、外部プロキシサーバや内部プロキシサーバのなりすましを防止することができる。

また、本発明の情報通信方法によれば、前記複数の内部プロキシサーバのそれぞれは、前記外部プロキシサーバの識別子に対応する鍵を予め保持し、前記第１工程では、前記内部プロキシサーバが、トンネル接続を確立するとき、前記外部プロキシサーバから当該外部プロキシサーバの識別子に対応する鍵を受信し、受信した鍵と予め保持している鍵とを比較し、比較の結果が一致した場合にトンネル接続の確立を許可する構成とすることができる。この構成によれば、外部プロキシサーバのなりすましを防止することができる。すなわち、悪意を持った者が、何らかの手段で外部プロキシサーバのアドレスに、不正な外部プロキシサーバを構築した場合、内部プロキシサーバはそれと知らずにアクセスし、ファイアウォール内部の情報を漏洩させてしまう恐れがあるが、本発明によれば、そのような情報漏洩を回避することができる。

また、本発明の情報通信方法によれば、前記外部プロキシサーバは、接続を要求する前記複数の内部プロキシサーバのそれぞれの識別子に対応する鍵を予め保持し、前記第１工程では、前記外部プロキシサーバが、トンネル接続を確立するとき、前記内部プロキシサーバから当該内部プロキシサーバの識別子に対応する鍵を受信し、受信した鍵と予め保持している鍵とを比較し、比較の結果が一致した場合に、トンネル接続の確立を許可する構成とすることができる。この構成によれば、内部プロキシサーバのなりすましを防止することができる。すなわち、悪意を持った者が、内部プロキシサーバを作成し、不正に外部プロキシサーバに接続しようとした場合、外部プロキシサーバはそれと知らずに接続を許可し、不正確な情報にアクセスしてしまう恐れがあるが、本発明によれば、このような不正確なアクセスを回避することができる。

また、本発明の情報通信方法によれば、前記外部プロキシサーバは、ウェブクライアントからのＨＴＴＰリクエストを解析し、ＨＴＴＰリクエストの一部分を前記ファイアウォール内部のアドレス指定として用いる構成とすることができる。この構成によれば、ウェブクライアントのプロキシ設定機能によって外部プロキシサーバを設定する場合、通常、１つの外部プロキシサーバしか設定できないが、本発明によれば、クライアントのプロキシ設定に依存することなく、複数の外部プロキシサーバを選択することが可能となる
また、本発明の情報通信方法によれば、プロキシサーバ（内部プロキシサーバ及び外部プロキシサーバ）は、ウェブサーバから受信したＨＴＴＰレスポンスを解析し、ＨＴＴＰレスポンス中のハイパーリンク部分に、前記ウェブサーバのアドレスを追加する構成とすることができる。この構成によれば、ウェブクライアント上で、ＨＴＴＰレスポンス中のハイパーリンクをクリックして、外部プロキシサーバ経由でアクセスすることが可能になり、ユーザの操作性が向上する。

また、本発明の情報通信方法によれば、プロキシサーバ（内部プロキシサーバ及び外部プロキシサーバ）は、ウェブサーバで生成された暗号化されたＨＴＴＰレスポンスを復号する復号鍵と、ＨＴＴＰレスポンスを暗号化する第１暗号化鍵とを保持し、前記ウェブクライアントは、前記プロキシサーバにおいて第１暗号化鍵で暗号化されたＨＴＴＰレスポンスを復号する第２復号鍵を保持し、前記ウェブサーバからＨＴＴＰレスポンスを受信した場合、当該ＨＴＴＰレスポンスを前記復号鍵で復号し、復号後のＨＴＴＰレスポンス内のハイパーリンクを改変させた後、前記第１暗号化鍵にて暗号化してウェブクライアントに送信する工程と、前記ウェブサーバが、受信したＨＴＴＰレスポンスを前記第２復号鍵にて復号し、表示する工程と、を備える構成とすることができる。この構成によれば、ＳＳＬ(Secire Socket Layer)などで暗号化されたレスポンスの場合、内容が暗号化されているため改変ができないが、復号鍵をプロキシサーバに登録することにより、一旦復号して平文にする。この状態では、ＨＴＴＰレスポンス中のハイパーリンクを改変することが可能となり、ユーザの操作性が向上する。そして、改変後のＨＴＴＰレスポンスを再度暗号化してウェブクライアントに送信することにより、安全性も確保される。

また、本発明の情報通信方法によれば、前記外部プロキシサーバは、前記ファイアウォール内部に設置されたウェブサーバのアドレスを格納した転送先情報テーブルと、前記内部プロキシサーバとは別の通常プロキシサーバのアドレスとを保持し、前記第３工程では、ＨＴＴＰリクエストを受信した場合に、ＨＴＴＰリクエストの内容と前記転送先情報テーブルの内容とを比較することで、前記内部プロキシサーバに送信するか、前記通常プロキシサーバに送信するかを決定する構成とすることができる。この構成によれば、ファイアウォール内部のウェブサーバ（ターゲット）にアクセスする業務と、それ以外へアクセスする業務とを、ウェブクライアントのプロキシ設定を切り変えずに同時に行うことができる。

本発明によれば、ファイアウォール外部に設置された外部プロキシサーバと、複数のファイアウォール内部にそれぞれ設置された内部プロキシサーバとでトンネル接続を確立しているので、ファイアウォールの特定ポートを開く方法と比較し、オープンポートの情報を外部に示す必要がなく安全性を向上させることができる。また、ファイアウォール内部の内部プロキシサーバからファイアウォール外部の外部プロキシサーバに対してトンネル接続を確立することで、不特定のクライアントからアクセスを遮断することができる。さらに、情報提供側が内部プロキシサーバを管理することにより、内部プロキシサーバを停止することによって、外部からのアクセスを完全に遮断することができる。

以下、本発明の実施の形態について、図面を参照して説明する。

図１は、本発明の情報通信方法を実施するための通信システムのハードウェア構成例を示すブロック図である。

この通信システムは、各ファイアウォール１００Ａ，１００Ｂの外部に外部プロキシサーバ１０５と複数のウェブクライアント１１１，１１２，・・・とが設置され、ファイアウォール１００Ａの内部に内部プロキシサーバ２０５と複数のウェブサーバ２１１，２１２，・・・とが設置され、ファイアウォール１００Ｂの内部に内部プロキシサーバ３０５と複数のウェブサーバ３１１，３１２，・・・とが設置された構成となっている。そして、外部プロキシサーバ１０５と各ウェブクライアント１１１，１１２，・・・とはイーサネット（登録商標）１０６によって接続され、内部プロキシサーバ２０５と各ウェブサーバ２１１，２１２，・・・とはイーサネット２０６によって接続され、内部プロキシサーバ３０５と各ウェブサーバ３１１，３１２，・・・とはイーサネット３０６によって接続されている。

本実施形態では、外部プロキシサーバ１０５が、２台のファイアウォール１００Ａ，１００Ｂを介して２台の内部プロキシサーバ２０５，３０５とそれぞれ接続された構成としているが、外部プロキシサーバ１０５に接続されるファイアウォールの数及び内部プロキシサーバの数は２台に限定されるものではなく、３台以上であってもよい。

各ウェブサーバ２１１，２１２，・・・，３１１，３１２，・・・は、一般的にはウェブクライアント１１１，１１２，・・・からのＨＴＴＰリクエストを待ち受け、ＨＴＴＰリクエストを受信した場合は、ＨＴＴＰリクエストに対応したＨＴＴＰレスポンスを、ＨＴＴＰリクエストを送信してきたウェブクライアント１１１，１１２，・・・に返す。本システムでは、各内部プロキシサーバ２０５，３０５からウェブサーバ２１１，２１２，・・・にＨＴＴＰリクエストが送信される。

利用者はウェブクライアント１１１，１１２，・・・を操作して、ＨＴＴＰリクエストを送信する。一般的なウェブクライアントは、ウェブサーバに対してＨＴＴＰリクエストを送信し、ウェブサーバからのＨＴＴＰレスポンスを受信して表示する。一方、本システムでは、ウェブクライアント１１１，１１２，・・・は、外部プロキシサーバ１０５に対してＨＴＴＰリクエストを送信し、外部プロキシサーバ１０５からＨＴＴＰレスポンスを受信して表示する。

各内部プロキシサーバ２０５，３０５は、起動後、外部プロキシサーバ１０５に接続して、トンネル接続を確立し、外部プロキシサーバ１０５からのＨＴＴＰリクエストを待ち受ける。そして、トンネル接続を経て外部プロキシサーバ１０５より送信されてきたＨＴＴＰリクエストを受信すると、そのＨＴＴＰリクエストに対応したウェブサーバにＨＴＴＰリクエストを送信する。そして後、ウェブサーバからのＨＴＴＰレスポンスを、トンネル接続を経て外部プロキシサーバ１０５に送信する。

各ファイアウォール１００Ａ，１００Ｂは、一般にファイアウォール内部から外部への接続を許可し、外部から内部への接続を許可しない。

外部プロキシサーバ１０５は、起動後、各内部プロキシサーバ２０５，３０５からのトンネル接続要求を待ち受ける。そして、各内部プロキシサーバ２０５，３０５から各ファイアウォール１００Ａ，１００Ｂを経てトンネル接続要求があれば、トンネル接続を確立する。また、外部プロキシサーバ１０５は、各ウェブクライアント１１１，１１２，・・・からのＨＴＴＰリクエストを待ち受ける。そして、任意のウェブクライアント１１１，１１２，・・・から送信されてきたＨＴＴＰリクエストを受信すると、トンネル接続を経て、各内部プロキシサーバ２０５，３０５に受信したＨＴＴＰリクエストを送信する。また、各内部プロキシサーバ２０５，３０５からＨＴＴＰレスポンスを受信すると、先にＨＴＴＰリクエストを送信してきたウェブクライアントにそのＨＴＴＰリスポンスを送信する。

次に、上記構成の通信システムを用いた本実施形態の情報通信方法の実施例について説明する。

＜実施例＞
本実施例は、本実施形態の情報通信方法の最も基本的な処理を示した実施例であり、図２は、本実施例の情報通信方法を説明するためのフローチャートである。以下、この図２に示すフローチャートを参照して本実施例の基本的な通信方法の処理手順を説明する。ただし、ここではファイアウォール１００Ａ内部との通信を例に挙げて説明する。

まず、外部プロキシサーバ１０５を起動し（ステップＳ２０１）、次に、ファイアウォール１００Ａ内部の内部プロキシサーバ２０５を起動し（ステップＳ２０２）、さらにファイアウォール１００Ｂ内部の内部プロキシサーバ３０５を起動する（ステップＳ２０４）。

次に、各内部プロキシサーバ２０５，３０５は、外部プロキシサーバ１０５に対してトンネル接続の要求を行う（ステップＳ２０３，ステップＳ２０５）。外部プロキシサーバ１０５は、この要求に従い、内部プロキシサーバ２０５，３０５からのトンネル接続の確立を行う（ステップＳ２０６）。

次に、外部プロキシサーバ１０５は、任意のウェブクライアント１１１，１１２，・・・からのＨＴＴＰリクエストの待ち受けを開始する（ステップＳ２０７）。リクエストとは、ＵＲＬアドレスを加工して選択することを示している。

一方、利用者によって例えばウェブクライアント１１１が起動されると（ステップＳ２０８）、ウェブクライアント１１１は、利用者の操作に応じて、ＨＴＴＰリクエストを外部プロキシサーバ１０５に送信する（ステップＳ２０９）。

外部プロキシサーバ１０５は、ウェブクライアント１１１からのＨＴＴＰリクエストを受信すると、受信したＨＴＴＰリクエストに応じて内部プロキシサーバを選択する（ステップＳ２１０）。ここでは、ファイアウォール１００Ａ内部の内部プロキシサーバ２０５を選択したものとする。そして、受信したＨＴＴＰリクエストを、トンネル接続を経て選択した内部プロキシサーバ２０５に送信する（ステップＳ２１１）。ただし、このＨＴＴＰリクエストに対応するウェブサーバ（例えば、ウェブサーバ２１１）はすでに起動されているものとする（ステップＳ２１３）。

内部プロキシサーバ２０５は、外部プロキシサーバ１０５からのＨＴＴＰリクエストを受信すると、該当するウェブサーバ２１１にそのＨＴＴＰリクエストを送信する（ステップＳ２１２）。ウェブサーバ２１１は、内部プロキシサーバ２０５から送信されてきたＨＴＴＰリクエストを受信し（ステップＳ２１４）、受信したＨＴＴＰリクエストに応じたＨＴＴＰレスポンスを、内部プロキシサーバ２０５に送信する（ステップＳ２１５）。

内部プロキシサーバ２０５は、ウェブサーバ２１１からのＨＴＴＰレスポンスを受信し、外部プロキシサーバ１０５に送信する（ステップＳ２１６）。

外部プロキシサーバ１０５は、内部プロキシサーバ２０５からのＨＴＴＰレスポンスを受信し、先にＨＴＴＰリクエストを送信してきたウェブクライアント１１１に送信する（ステップＳ２１７）。

ウェブクライアント１１１は、外部プロキシサーバ１０５からのＨＴＴＰレスポンスを受信し（ステップＳ２１８）、受信したＨＴＴＰレスポンスを表示する（ステップＳ２１９）。この後、次のＨＴＴＰリクエストがある場合には、ステップＳ２０９に戻る（ステップＳ２２０）。

＜応用例１＞
本応用例１は、図１に示す通信システムの各内部プロキシサーバ２０５，３０５に、予め接続を許可するウェブサーバのアドレスを登録し、トンネル接続を経由して外部プロキシサーバ１０５から受信したＨＴＴＰリクエストのアドレスが、内部に登録されている接続許可アドレスと一致した場合のみ、一致したアドレスのウェブサーバにＨＴＴＰリクエストを送信するように構成した応用例であり、情報通信方法の基本動作は上記実施例と同様である。

すなわち、上記実施例では、各内部プロキシサーバ２０５，３０５は、外部プロキシサーバ１０５から受信したＨＴＴＰリクエストを無条件で該当するウェブサーバに送信していたが（図２のステップＳ２１２）、本応用例１では、ＨＴＴＰリクエストを受信した段階で、まずそのＨＴＴＰリクエストに含まれているアドレスを確認し、内部に登録されている接続許可アドレスと一致した場合のみ、一致したアドレスのウェブサーバにＨＴＴＰリクエストを送信し、一致しない場合には、送信を禁止する構成としている。すなわち、図２のステップＳ２１２を実施する前段階で、この判断ステップをまず実施することになる。

ここで、内部プロキシサーバ２０５を例に挙げて具体的に説明する。内部プロキシサーバ２０５にイーサネット２０６を介して例えば５台のウェブサーバ２１１，２１２，２１３，２１４，２１５が接続されているものとし、ウェブサーバ２１１のアドレスを「ａａａａ」、ウェブサーバ２１２のアドレスを「ｂｂｂｂ」、ウェブサーバ２１３のアドレスを「ｃｃｃｃ」、ウェブサーバ２１４のアドレスを「ｄｄｄｄ」、ウェブサーバ２１５のアドレスを「ｅｅｅｅ」とする。そして、内部プロキシサーバ２０５には、このうち接続を許可するアドレスとして、図３に示すように、２台のウェブサーバ２１１，２１３のアドレス「ａａａａ」，「ｃｃｃｃ」が登録されているものとする。

ここで、ウェブクライアント１１１から外部プロキシサーバ１０５に対して、ウェブサーバ２１１へのＨＴＴＰリクエストが送信されてきたとすると、外部プロキシサーバ１０５は、このＨＴＴＰリクエストを内部プロキシサーバ２０５に送信する。このとき、内部プロキシサーバ２０５は、送信されてきたＨＴＴＰリクエストに含まれているウェブサーバのアドレス「ａａａａ」を取得し、内部に登録されているアドレスと比較する。比較の結果、この場合には一致するので、受信したＨＴＴＰリクエストを該当するウェブサーバ２１１に送信する。

一方、ウェブクライアント１１１から外部プロキシサーバ１０５に対して、ウェブサーバ２１２へのＨＴＴＰリクエストが送信されてきたとすると、外部プロキシサーバ１０５は、このＨＴＴＰリクエストを内部プロキシサーバ２０５に送信する。このとき、内部プロキシサーバ２０５は、送信されてきたＨＴＴＰリクエストに含まれているウェブサーバのアドレス「ｂｂｂｂ」を取得し、内部に登録されているアドレスと比較する。比較の結果、この場合には一致しないので、受信したＨＴＴＰリクエストをウェブサーバ２１２に送信することなく、処理を終了する。

このように、本応用例１の構成によれば、接続を許可するアドレスの情報を内部プロキシサーバ２０５に登録し、この登録されているアドレス以外のアドレスに対してＨＴＴＰリクエストが送信されてきた場合には、その受け付けを拒否することにより、外部から不必要なウェブサーバ（接続されたくないウェブサーバ）に不測にアクセスされてしまうことを防ぐことができる。

＜応用例２＞
本応用例２は、図１に示す通信システムの各内部プロキシサーバ２０５，３０５に、予め接続を禁止するウェブサーバのアドレスを登録し、トンネル接続を経由して外部プロキシサーバ１０５から受信したＨＴＴＰリクエストのアドレスが、内部に登録されている接続禁止アドレスと一致した場合には、その一致したアドレスのウェブサーバにＨＴＴＰリクエストを送信することを禁止するように構成した応用例であり、情報通信方法の基本動作は上記実施例と同様である。

すなわち、上記実施例では、各内部プロキシサーバ２０５，３０５は、外部プロキシサーバ１０５から受信したＨＴＴＰリクエストを無条件で該当するウェブサーバに送信していたが（図２のステップＳ２１２）、本応用例２では、ＨＴＴＰリクエストを受信した段階で、まずそのＨＴＴＰリクエストに含まれているアドレスを確認し、内部に登録されている接続禁止アドレスと一致した場合には、その一致したアドレスのウェブサーバに対するＨＴＴＰリクエストの送信を禁止し、一致しない場合にのみ送信を許可する構成としている。すなわち、図２のステップＳ２１０を実施する前段階で、この判断ステップをまず実施することになる。

ここで、内部プロキシサーバ２０５を例に挙げて具体的に説明する。内部プロキシサーバ２０５にイーサネット２０６を介して例えば５台のウェブサーバ２１１，２１２，２１３，２１４，２１５が接続されているものとし、ウェブサーバ２１１のアドレスを「ａａａａ」、ウェブサーバ２１２のアドレスを「ｂｂｂｂ」、ウェブサーバ２１３のアドレスを「ｃｃｃｃ」、ウェブサーバ２１４のアドレスを「ｄｄｄｄ」、ウェブサーバ２１５のアドレスを「ｅｅｅｅ」とする。そして、内部プロキシサーバ２０５には、このうち接続を禁止するアドレスとして、図４に示すように、３台のウェブサーバ２１２，２１４，２１５のアドレス「ｂｂｂｂ」，「ｄｄｄｄ」，「ｅｅｅｅ」が登録されているものとする。

ここで、ウェブクライアント１１１から外部プロキシサーバ１０５に対して、ウェブサーバ２１１（アドレス「ａａａａ」）へのＨＴＴＰリクエストが送信されてきたとすると、外部プロキシサーバ１０５は、このＨＴＴＰリクエストを内部プロキシサーバ２０５に送信する。このとき、内部プロキシサーバ２０５は、送信されてきたＨＴＴＰリクエストに含まれているウェブサーバのアドレス「ａａａａ」を取得し、内部に登録されているアドレスと比較する。比較の結果、この場合には禁止アドレスと一致しないので、受信したＨＴＴＰリクエストを該当するウェブサーバ２１１に送信する。

一方、ウェブクライアント１１１から外部プロキシサーバ１０５に対して、ウェブサーバ２１２（アドレス「ｂｂｂｂ」）へのＨＴＴＰリクエストが送信されてきたとすると、外部プロキシサーバ１０５は、このＨＴＴＰリクエストを内部プロキシサーバ２０５に送信する。このとき、内部プロキシサーバ２０５は、送信されてきたＨＴＴＰリクエストに含まれているウェブサーバのアドレス「ｂｂｂｂ」を取得し、内部に登録されているアドレスと比較する。比較の結果、この場合には禁止アドレスと一致するので、受信したＨＴＴＰリクエストをウェブサーバ２１２に送信することなく、処理を終了する。

このように、本応用例２の構成によれば、接続を禁止するアドレスの情報を内部プロキシサーバ２０５に登録し、この登録されているアドレスに対してＨＴＴＰリクエストが送信されてきた場合には、その受け付けを拒否することにより、外部から不必要なウェブサーバ（接続されたくないウェブサーバ）に不測にアクセスされてしまうことを防ぐことができる。

＜応用例３＞
本応用例３は、図１に示す通信システムの各内部プロキシサーバ２０５，３０５に、予め送信を禁止または許可するウェブサーバのアドレスを示す特定のパターンを登録し、トンネル接続を経由して外部プロキシサーバ１０５から受信したＨＴＴＰリクエストのアドレスのパターンが、内部に登録されている特定のパターンと一致した場合には、その一致したアドレスのウェブサーバに対してＨＴＴＰリクエストの送信を禁止または許可（送信）するように構成した応用例であり、情報通信方法の基本動作は上記実施例と同様である。

すなわち、上記実施例では、各内部プロキシサーバ２０５，３０５は、外部プロキシサーバ１０５から受信したＨＴＴＰリクエストを無条件で該当するウェブサーバに送信していたが（図２のステップＳ２１２）、本応用例３では、ＨＴＴＰリクエストを受信した段階で、まずそのＨＴＴＰリクエストに含まれているアドレスのパターンを確認し、内部に登録されている特定のパターンと一致した場合に、その一致したアドレスのウェブサーバに対するＨＴＴＰリクエストの送信を禁止または許可（送信）する構成としている。すなわち、図２のステップＳ２１０を実施する前段階で、この判断ステップをまず実施することになる。

具体的に説明すると、ウェブサーバのアドレスを示す特定のパターンとして、例えば設定ファイルに、「www.sharp.co.jp/path/to/data enable」が登録されている場合には、この「www.sharp.co.jp/path/to/data enable」へのアクセスを許可する。一方、設定ファイルに、「server.sharp.co.jp/path/to/page disable」が登録されている場合には、この「server.sharp.co.jp/path/to/page disable」へのアクセスを禁止する。

このように、本応用例３によれば、ウェブサーバの複数のアドレスに関して、まとめて許可または禁止を設定できるので、設定が容易になる。

＜応用例４＞
本応用例４では、各内部プロキシサーバ２０５，３０５は、正規の切断操作以外でトンネル接続が切断されたことを検出する検出工程を備えている。そして、トンネル接続が正規の切断操作以外で切断されたことを検出した場合には、再度、トンネル接続の確立を試す構成とした応用例である。

通常、インターネット上の接続は保証されない。また、ファイアウォール１００Ａ，１００Ｂの外部側や外部プロキシサーバ１０５などで不測の問題が発生した場合、トンネル接続が切断される場合がある。このとき、内部プロキシサーバ２０５，３０５が自動的に再接続を行う構成とすることで、安定した通信路を維持することが可能となる。

ここで、正規の切断操作について説明する。正規の切断操作では、オペレータが内部プロキシサーバ２０５，３０５を操作して、切断要求を外部プロキシサーバ１０５に送信する。外部プロキシサーバ２０５は、切断要求を受信すると、内部プロキシサーバ２０５，３０５に承認応答を送信して、トンネル接続を切断する。一方、内部プロキシサーバ２０５，３０５は、承認応答を受信すると、トンネル接続を切断する。以上の手順で切断された場合が正規の切断操作である。

次に、正規外の切断操作について説明する。外部プロキシサーバ１０５は、内部プロキシサーバ２０５，３０５に対して、通信可能かどうかを判定するための存在確認要求を一定間隔で送信する。内部プロキシサーバ２０５，３０５は、存在確認要求を受信るすと、応答を外部プロキシサーバ１０５に送信する。外部プロキシサーバ１０５は、内部プロキシサーバ２０５，３０５からの応答を一定時間待ち、予め決められた時間内に応答がなければ内部プロキシサーバ２０５とのトンネル接続を切断する。一方、内部プロキシサーバ２０５，３０５は、外部プロキシサーバ１０５からの存在確認要求が前記一定間隔より長い一定期間以上無ければ、トンネル接続を切断する。以上の手順で切断された場合が正規外の切断操作である。

＜応用例５＞
本応用例５は、図１に示す通信システムの各内部プロキシサーバ２０５，３０５に、予めトンネル接続の開始時刻と切断時刻の情報を登録し、その開始時刻から切断時刻までの間だけ、トンネル接続を確立するように構成した応用例であり、トンネル接続確立後の情報通信方法は、上記実施例の基本動作と同様である。

すなわち、上記実施例では、内部プロキシサーバ２０５，３０５は、起動後、無条件で外部プロキシサーバ１０５にトンネル接続要求を送信し、トンネル接続を確立する構成としている（図２のステップＳ２０３，ステップＳ２０５）。また、説明は省略しているが、内部プロキシサーバ２０５，３０５の電源がオフされるとき、トンネル接続を遮断する構成としている。これに対し、本応用例５では、内部プロキシサーバ２０５，３０５を起動した段階で、まず内部に登録されているトンネル接続の開始時刻及び切断時刻と現在時刻とを比較し、現在時刻が開始時刻から切断時刻の間である場合には、図２のステップＳ２０３，ステップＳ２０５を実施し、現在時刻が開始時刻から切断時刻の間でない場合には、外部プロキシサーバ１０５に対してトンネル接続要求を送信せず（すなわち、開始時刻になるまでトンネル接続要求を送信せず）、トンネル接続を確立しない構成としている。すなわち、図２のステップＳ２０３，ステップＳ２０５を実施する前段階で、トンネル接続確立のための上記判断ステップをまず実施することになる。

ここで、内部プロキシサーバ２０５を例に挙げて具体的に説明する。内部プロキシサーバ２０５に、例えば図５に示すように、トンネル接続の開始時刻として「０７：００（午前７時００分）」、トンネル接続の切断時刻として「２０：００（午後８時００分）」の情報が登録されているものとする。

ここで、内部プロキシサーバ２０５が、０９：００（午前９時００分）に起動されたとすると（図２のステップＳ２０２）、内部プロキシサーバ２０５は、まず起動時の時刻「０９：００」と内部に登録されている開始時刻「０７：００」及び切断時刻「２０：００」とを比較する。比較の結果、この場合には、起動時刻「０９：００」が開始時刻「０７：００」から切断時刻「２０：００」までの間に入っているので、内部プロキシサーバ２０５は、図２のステップＳ２０３の処理を実行し、外部プロセスサーバ１０５にトンネル接続要求を送信して、トンネル接続を確立する。

一方、内部プロキシサーバ２０５が、０６：００（午前６時００分）に起動されたとすると（図２のステップＳ２０２）、内部プロキシサーバ２０５は、まず起動時の時刻「０６：００」と内部に登録されている開始時刻「０７：００」及び切断時刻「２０：００」とを比較する。比較の結果、この場合には、起動時刻「０６：００」が開始時刻「０７：００」から切断時刻「２０：００」までの間に入っていないので、内部プロキシサーバ２０５は、図２のステップＳ２０３の処理は実行せず、外部プロセスサーバ１０５にトンネル接続要求を送信しない。この後、内部プロキシサーバ２０５は、図示しない時計手段による現在時刻の計時を監視し、現在時刻が開始時刻「０９：００」になると、図２のステップＳ２０３の処理を実行し、外部プロセスサーバ１０５にトンネル接続要求を送信して、トンネル接続を確立する。

また、内部プロキシサーバ２０５は、トンネル接続確立後も時計手段による現在時刻の計時を監視し、現在時刻が切断時刻になると、トンネル接続を遮断する。

このように、本応用例５の構成によれば、内部プロキシサーバ２０５に登録されている特定の時間帯のみ外部プロキシサーバ１０５との間でトンネル接続を確立することが可能となり、外部からの不正アクセスの可能性を減らすことができる。

＜応用例６＞
本応用例６は、図２のステップＳ２１１の処理を実施するときに、外部プロキシサーバ１０５が、任意のウェブクライアントから受信したＨＴＴＰリクエストを暗号化し、暗号化したＨＴＴＰリクエストを内部プロキシサーバ２０５，３０５に送信する一方、図２のステップＳ２１４の処理を実施するとき、内部プロキシサーバ２０５，３０５が、受信したＨＴＴＰリクエストを復号し、復号したＨＴＴＰリクエストを該当するウェブサーバに送信する構成としている。また、図２のステップＳ２１６の処理を実施するとき、内部プロキシサーバ２０５，３０５が、ウェブサーバからのＨＴＴＰレスポンスを暗号化し、暗号化したＨＴＴＰレスポンスを外部プロキシサーバ１０５に送信する一方、図２のステップＳ２１７の処理を実施するとき、外部プロキシサーバ１０５が、暗号化されているＨＴＴＰレスポンスを復号し、復号したＨＴＴＰレスポンスを該当するウェブクライアントに送信する構成としている。

このように、本応用例６によれば、外部プロキシサーバ１０５と内部プロキシサーバ２０５，３０５との間で相互に暗号化と復号化とを行うので、外部プロキシサーバや内部プロキシサーバのなりすましを防止することができる。

＜応用例７＞
本応用例７では、各内部プロキシサーバ２０５，３０５は、外部プロキシサーバ１０５の識別子に対応する鍵を予め保持する構成とする。そして、図２のステップＳ２０３，ステップＳ２０５において、内部プロキシサーバ２０５，３０５がトンネル接続を確立するとき、外部プロキシサーバ１０５から当該外部プロキシサーバの識別子に対応する鍵を受信し、受信した鍵と予め保持している鍵とを比較し、比較の結果が一致した場合にトンネル接続の確立を行う構成とする。

このように、本応用例７によれば、外部プロキシサーバ１０５のなりすましを防止することができる。すなわち、悪意を持った者が、何らかの手段で外部プロキシサーバのアドレスに、不正な外部プロキシサーバを構築した場合、従来の通信システムでは、内部プロキシサーバはそれと知らずにアクセスし、ファイアウォール内部の情報を漏洩させてしまう恐れがあるが、本応用例７によれば、鍵の一致を確認した後、トンネル接続を確立するため、そのような情報漏洩を回避することができる。

＜応用例８＞
本応用例８では、外部プロキシサーバ１０５は、トンネル接続を要求する各内部プロキシサーバ２０５，３０５の識別子に対応する鍵を予め保持する構成とする。そして、図２のステップＳ２０６において、外部プロキシサーバ１０５がトンネル接続を確立するとき、内部プロキシサーバ２０５，３０５から当該内部プロキシサーバ２０５，３０５の識別子に対応する鍵を受信し、受信した鍵と予め保持している鍵とを比較し、比較の結果が一致した場合に、トンネル接続の確立を行う構成とする。

このように、本応用例８によれば、内部プロキシサーバ２０５，３０５のなりすましを防止することができる。すなわち、悪意を持った者が、内部プロキシサーバを作成し、不正に外部プロキシサーバに接続しようとした場合、従来の通信システムでは、外部プロキシサーバはそれと知らずに接続を許可し、不正確な情報にアクセスしてしまう恐れがあるが、本応用例８によれば、鍵の一致を確認した後、トンネル接続を確立するため、このような不正確なアクセスを回避することができる。また、上記応用例７と本応用例８とを組み合わせることによって、情報漏洩や不正確な情報へのアクセスをより確実に防止することが可能となる。

＜応用例９＞
本応用例９では、外部プロキシサーバ１０５は、ウェブクライアントからのＨＴＴＰリクエストを解析し、ＨＴＴＰリクエストの一部分をファイアウォール１００Ａ，１００Ｂ内部のアドレス指定として用いる応用例である。より具体的には、内部プロキシサーバ２０５，３０５及び外部プロキシサーバ１０５は、ウェブサーバから受信したＨＴＴＰレスポンスを解析し、ＨＴＴＰレスポンス中のハイパーリンク部分に、ウェブサーバのアドレスを追加する応用例である。

図６は、本応用例９の情報通信方法を説明するためのフローチャートである。以下、この図６に示すフローチャートを参照して本応用例９の通信方法の処理手順を説明する。

初期状態は、図２におけるトンネル接続確立の状態（ステップＳ２０７）とする。

まず、任意のウェブクライアントより、ＨＴＴＰリクエスト「ここでは、（webserver.customr.co.jp/path/to/data.html）」を外部プロキシサーバ１０５及び内部プロキシサーバ２０５に送信する（ステップＳ３０１）。なお、以下の説明では、外部プロキシサーバ１０５及び内部プロキシサーバ２０５，３０５を区別することなく、単に「プロキシサーバ」と称することとする。

プロキシサーバは、ウェブクライアントからのＨＴＴＰリクエストを受信し、受信したＨＴＴＰリクエストを、アドレス情報（webserver.customer.co.jp）とそれ以降のＨＴＴＰリクエスト本体（path/to/data.html）とに分離し（ステップＳ３０２）、アドレス情報(webserver.customer.co.jp)によって示されるウェブサーバに向けて、ＨＴＴＰリクエスト本体を送信する（ステップＳ３０３）。

ターゲットであるウェブサーバは、プロキシサーバから送信されてきたＨＴＴＰリクエスト本体を受信し（ステップＳ３０４）、ＨＴＴＰリクエストに応じたＨＴＴＰレスポンスを生成し、プロキシサーバへ送信する（ステップＳ３０５）。

プロキシサーバは、ウェブサーバから送信されてきたＨＴＴＰレスポンスを受信し（ステップＳ３０６）、受信したＨＴＴＰレスポンス中のハイパーリンク部分に、ステップＳ３０２で取得したウェブサーバのアドレスを挿入する。ここでは、
＜a href="path/to/data.html"＞…＜/a＞
を
＜a href="webserver.customer.co.jp/path/to/data.html"＞...＜/a＞
に置き換えて、ウェブクライアントに送信する（ステップＳ３０７）。

ウェブクライアントは、プロキシサーバから送信されてきたＨＴＴＰレスポンスを受信し、表示する（ステップＳ３０８）。

ウェブクライアントのプロキシ設定機能によって外部プロキシサーバを設定する場合、通常、１つの外部プロキシサーバしか設定できないが、本応用例９によれば、クライアントのプロキシ設定に依存することなく、複数の外部プロキシサーバを選択することが可能となる。また、ウェブクライアント上で、ＨＴＴＰレスポンス中のハイパーリンクをクリックして、外部プロキシサーバ経由でアクセスすることが可能になり、ユーザの操作性を向上させることが可能となる。

＜応用例１０＞
本応用例１０では、プロキシサーバ（内部プロキシサーバ及び外部プロキシサーバ）は、ウェブサーバで生成され暗号化されたＨＴＴＰレスポンスを復号する第１復号鍵と、ＨＴＴＰレスポンスを暗号化する第１暗号化鍵とを保持し、ウェブクライアントは、プロキシサーバにおいて第１暗号化鍵で暗号化されたＨＴＴＰレスポンスを復号する第２復号鍵を保持する構成としている。そして、ウェブサーバからＨＴＴＰレスポンスを受信した場合、プロキシサーバは、当該ＨＴＴＰレスポンスを第１復号鍵で復号し、復号後のＨＴＴＰレスポンス内のハイパーリンクを改変させた後、第１暗号化鍵にて暗号化してウェブクライアントに送信する一方、ウェブサーバが、受信したＨＴＴＰレスポンスを第２復号鍵にて復号し、表示する構成としている。

図７は、本応用例１０の情報通信方法を説明するためのフローチャートである。以下、この図７に示すフローチャートを参照して本応用例９の通信方法の処理手順を説明する。

初期状態は、図２におけるトンネル接続確立の状態（ステップＳ２０７）とする。

まず、任意のウェブクライアントより、ＨＴＴＰリクエスト(ここでは、（webserver.customr.co.jp/path/to/data.html）)をプロキシサーバに送信する（ステップＳ４０１）。このとき、ウェブクライアントは、送信時にＨＴＴＰリクエストを暗号化鍵1で暗号化する（ステップＳ４０２）。

プロキシサーバは、ウェブクライアントからの暗号化されたＨＴＴＰリクエストを受信すると、受信したＨＴＴＰリクエストを、暗号化鍵1に対応する復号鍵1によって復号し、復号したＨＴＴＰリクエストを、アドレス情報（webserver.customer.co.jp）とそれ以降のＨＴＴＰリクエスト本体（path/to/data.html）とに分離する（ステップＳ４０３）。そして、アドレス情報（webserver.customer.co.jp）によって示されるウェブクライアント（ターゲット）に向けて、ＨＴＴＰリクエスト本体を送信する（ステップＳ４０４）。このとき、プロキシサーバは、送信時に暗号化鍵２でＨＴＴＰリクエスト本体を暗号化する（ステップＳ４０５）。

ターゲットであるウェブサーバは、プロキシサーバから送信されてきたＨＴＴＰリクエスト本体を受信し、暗号化鍵２に対応する復号鍵２によって復号する（ステップＳ４０６）。そして、復号したＨＴＴＰリクエストに応じたＨＴＴＰレスポンスを生成して、プロキシサーバに送信する（ステップＳ４０７）。その際、ウェブサーバは、暗号化鍵３によってＨＴＴＰレスポンスを暗号化する（ステップＳ４０８）。

プロキシサーバは、ウェブサーバから送信されてきたＨＴＴＰレスポンスを受信し、受信したＨＴＴＰレスポンスを暗号化鍵３に対応する復号鍵３によって復号する（ステップＳ４０９）。そして、復号したＨＴＴＰレスポンス中のハイパーリンク部分に、ステップＳ４０３で取得したウェブサーバのアドレスを挿入する。ここでは、
＜a href="path/to/data.html"＞...＜/a＞
を
＜a href="webserver.customer.co.jp/path/to/data.html"＞...＜/a＞
に置き換えて、ウェブクライアントに送信する（ステップＳ４１０）。その際、プロキシサーバは、送信時に暗号化鍵４によって暗号化する（ステップＳ４１１）。

ウェブクライアントは、プロキシサーバから送信されてきたＨＴＴＰレスポンスを受信すると、暗号化鍵４に対応する復号鍵４によって復号し、表示する（ステップＳ４１２）。

本応用例１０によれば、ＳＳＬ（Secire Socket Layer）などで暗号化されたレスポンスの場合、内容が暗号化されているため改変ができないが、復号鍵をプロキシサーバに登録することにより、一旦復号して平文にする。この状態では、ＨＴＴＰレスポンス中のハイパーリンクを改変することが可能となり、ユーザの操作性が向上する。そして、改変後のＨＴＴＰレスポンスを再度暗号化してウェブクライアントに送信することにより、安全性が確保されることになる。

＜応用例１１＞
本応用例１１では、外部プロキシサーバ１０５は、前記ファイアウォール内部に設置されたウェブサーバ２１１，２１２，・・・，３１１，３１２，・・・のアドレスを格納した転送先情報テーブル１０８（図８参照）と、内部プロキシサーバ２０５とは別の通常プロキシサーバのアドレスとを保持し、任意のウェブクライアントからＨＴＴＰリクエストを受信した場合に、ＨＴＴＰリクエストの内容と転送先情報テーブルの内容とを比較することで、内部プロキシサーバに送信するか、通常プロキシサーバに送信するかを決定する構成としている。

すなわち、図１のシステム構成では、外部プロキシサーバ１０５と内部プロキシサーバ２０５とが１対２対応となっているが、本応用例１１では、図８に示すように、外部プロキシサーバ１０５に対して、内部プロキシサーバ２０５，３０５以外に通常プロキシサーバ４０５も接続され、この通常プロキシサーバ４０５に通常ウェブサーバ４１１が接続された構成となっている。

外部プロキシサーバ１０５が保持する転送先情報テーブル１０８には、例えば図９に示すようなアドレスデータが格納されている。ここで、「host-1.local.domain.jp」がウェブサーバ（ターゲット１）２１１のアドレスであり、「host-2.local.domain.jp」がウェブサーバ（ターゲット２）２１２のアドレスであり、「host-3.local.domain.jp」がウェブサーバ（ターゲット３）３１１のアドレスであり、「host-4.local.domain.jp」がウェブサーバ（ターゲット４）３１２のアドレスであるとすると、外部プロキシサーバ１０５は、ＨＴＴＰリクエストのアドレスと転送先情報テーブル１０８の内容とを比較し、転送先情報テーブル１０８内にＨＴＴＰリクエスト先アドレスと一致するアドレスがあれば、内部プロキシサーバ２０５にリクエストを送信する。一方、転送先情報テーブル１０８内にＨＴＴＰリクエスト先アドレスと一致するアドレスがなければ、通常プロキシサーバ３０５にリクエストを送信する。

このように、本応用例１１によれば、ファイアウォール内部のウェブサーバ（ターゲット）にアクセスする業務と、それ以外へアクセスする業務とを、ウェブクライアントのプロキシ設定を切り変えずに同時に行うことができる。

本発明の情報通信方法を実施するための通信システムのハードウェア構成例を示すブロック図である。 本発明の基本となる情報通信方法を説明するためのフローチャートである。 応用例１に対応した接続許可テーブルの構成例を示す説明図である。 応用例２に対応した接続禁止テーブルの構成例を示す説明図である。 応用例５に対応した接続の開始時刻と切断時刻の登録テーブルを示す説明図である。 応用例９の情報通信方法を説明するためのフローチャートである。 応用例１０の情報通信方法を説明するためのフローチャートである。 応用例１１に対応した情報通信方法を実施するための通信システムのハードウェア構成例を示すブロック図である。 応用例１１に対応した転送先情報テーブルの構成例を示す説明図である。

符号の説明

１００Ａ，１００Ｂ ファイアウォール
１０５ 外部プロキシサーバ
１０６ イーサネット
１０８ 転送先情報テーブル
１１１，１１２，・・・ ウェブクライアント
２０５ 内部プロキシサーバ
２０６ イーサネット
２１１，２１２，３１１，３１２，・・・ ウェブサーバ
３０５ 内部プロキシサーバ
３０６ イーサネット
４０５ 通常プロキシサーバ
４１１，・・・ 通常ウェブサーバ

Claims (13)

1. ファイアウォール外部に外部プロキシサーバとウェブクライアントとを設置し、複数のファイアウォール内部にそれぞれ内部プロキシサーバとウェブサーバとを設置した情報通信システムにおける情報通信方法であって、
   前記外部プロキシサーバと前記内部プロキシサーバとの間でトンネル接続を確立させる第1工程と、
   トンネル接続確立後、前記ウェブクライアントが、利用者の操作に応じて、前記外部プロキシサーバに接続し、ＨＴＴＰリクエストを送信する第２工程と、
   前記外部プロキシサーバが、前記ウェブクライアントからのＨＴＴＰリクエストを受信し、受信したＨＴＴＰリクエストに応じて内部プロキシサーバを選択し、前記トンネル接続を経由して前記選択した内部プロキシサーバに送信する第３工程と、
   前記内部プロキシサーバが、前記外部プロキシサーバからのＨＴＴＰリクエストを受信し、前記ウェブサーバに送信する第４工程と、
   前記ウェブサーバが、前記内部プロキシサーバに前記ＨＴＴＰリクエストに応じたＨＴＴＰレスポンスを返信する第５工程と、
   前記内部プロキシサーバが、前記外部プロキシサーバに前記ＨＴＴＰレスポンスを返信する第６工程と、
   前記外部プロキシサーバが、前記ウェブクライアントにＨＴＴＰレスポンスを返信する第７工程と、を備えていることを特徴とする情報通信方法。
2. 請求項１に記載の情報通信方法において、
   前記複数の内部プロキシサーバのそれぞれには、予め接続を許可する前記ウェブサーバのアドレスが記録されており、
   前記第４工程では、トンネル接続を経由して前記外部プロキシサーバから受信したＨＴＴＰリクエストのアドレスが、内部に記録されている前記許可するアドレスと一致した場合のみ、一致したアドレスのウェブサーバに前記ＨＴＴＰリクエストを送信することを特徴とする請求項１に記載の情報通信方法。
3. 請求項１または請求項２に記載の情報通信方法において、
   前記複数の内部プロキシサーバのそれぞれには、予め接続を禁止する前記ウェブサーバのアドレスが記録されており、
   前記第４工程では、トンネル接続を経由して前記外部プロキシサーバから受信したＨＴＴＰリクエストのアドレスが、内部に記録されている前記禁止するアドレスと一致した場合には、ウェブサーバへの送信を行わないことを特徴とする情報通信方法。
4. 請求項１ないし請求項３のいずれか１項に記載の情報通信方法において、
   前記複数の内部プロキシサーバのそれぞれには、予め送信を禁止または許可する前記ウェブサーバのアドレスを示す特定のパターンが記録されており、
   前記第４工程では、トンネル接続を経由して前記外部プロキシサーバから受信したＨＴＴＰリクエストのアドレスのパターンが、内部に記録されている前記禁止または許可するアドレスのパターンと一致した場合に、一致したパターンのアドレスのウェブサーバへの送信を禁止または許可することを特徴とする情報通信方法。
5. 請求項１ないし請求項４のいずれか１項に記載の情報通信方法において、
   前記複数の内部プロキシサーバのそれぞれは、正規の切断操作以外でトンネル接続が切断されたことを検出する工程を備え、
   トンネル接続が正規の切断操作以外で切断されたことを検出した場合には、再度、トンネル接続の確立を試すことを特徴とする情報通信方法。
6. 請求項１ないし請求項５のいずれか１項に記載の情報通信方法において、
   前記複数の内部プロキシサーバのそれぞれには、トンネル接続開始時刻とトンネル接続切断時刻の情報が記録されており、
   前記第１工程では、前記トンネル接続開始時刻になると前記外部プロキシサーバとのトンネル接続を確立し、前記トンネル接続切断時刻になると前記トンネル接続を切断することを特徴とする情報通信方法。
7. 請求項１ないし請求項６のいずれか１項に記載の情報通信方法において、
   前記第３工程では、前記外部プロキシサーバが、ウェブクライアントからのＨＴＴＰリクエストを暗号化し、暗号化したＨＴＴＰリクエストを前記内部プロキシサーバに送信し、
   前記第４工程では、前記内部プロキシサーバが、受信したＨＴＴＰリクエストを復号し、復号したＨＴＴＰリクエストをウェブサーバに送信し、
   前記第５工程では、前記内部プロキシサーバが、ウェブサーバからのＨＴＴＰレスポンスを暗号化し、暗号化したＨＴＴＰレスポンスを前記外部プロキシサーバに送信し、
   前記第６工程では、前記外部プロキシサーバが、暗号化されている前記ＨＴＴＰレスポンスを復号し、復号したＨＴＴＰレスポンスを前記ウェブクライアントに送信することを特徴とする情報通信方法。
8. 請求項１ないし請求項７のいずれか１項に記載の情報通信方法において、
   前記複数の内部プロキシサーバのそれぞれは、前記外部プロキシサーバの識別子に対応する鍵を予め保持し、
   前記第１工程では、前記内部プロキシサーバが、トンネル接続を確立するとき、前記外部プロキシサーバから当該外部プロキシサーバの識別子に対応する鍵を受信し、受信した鍵と予め保持している鍵とを比較し、比較の結果が一致した場合にトンネル接続の確立を許可することを特徴とする情報通信方法。
9. 請求項１ないし請求項８のいずれか１項に記載の情報通信方法において、
   前記外部プロキシサーバは、接続を要求する前記複数の内部プロキシサーバのそれぞれの識別子に対応する鍵を予め保持し、
   前記第１工程では、前記外部プロキシサーバが、トンネル接続を確立するとき、前記内部プロキシサーバから当該内部プロキシサーバの識別子に対応する鍵を受信し、受信した鍵と予め保持している鍵とを比較し、比較の結果が一致した場合に、トンネル接続の確立を許可することを特徴とする情報通信方法。
10. 請求項１ないし請求項９のいずれか１項に記載の情報通信方法において、
    前記外部プロキシサーバは、ウェブクライアントからのＨＴＴＰリクエストを解析し、ＨＴＴＰリクエストの一部分を前記ファイアウォール内部のアドレス指定として用いることを特徴とする情報通信方法。
11. 請求項１０に記載の情報通信方法において、
    前記プロキシサーバは、ウェブサーバから受信したＨＴＴＰレスポンスを解析し、ＨＴＴＰレスポンス中のハイパーリンク部分に、前記ウェブサーバのアドレスを追加することを特徴とする情報通信方法。
12. 請求項１１に記載の情報通信方法において、
    前記プロキシサーバは、ウェブサーバで生成された暗号化されたＨＴＴＰレスポンスを復号する復号鍵と、ＨＴＴＰレスポンスを暗号化する第１暗号化鍵とを保持し、
    前記ウェブクライアントは、前記プロキシサーバにおいて第１暗号化鍵で暗号化されたＨＴＴＰレスポンスを復号する第１復号鍵を保持し、
    前記ウェブサーバからＨＴＴＰレスポンスを受信した場合、当該ＨＴＴＰレスポンスを前記復号鍵で復号し、復号後のＨＴＴＰレスポンス内のハイパーリンクを改変させた後、前記第１暗号化鍵にて暗号化してウェブクライアントに送信する工程と、
    前記ウェブサーバが、受信したＨＴＴＰレスポンスを前記第２復号鍵にて復号し、表示する工程と、を備えることを特徴とする情報通信方法。
13. 請求項１ないし請求項１２のいずれか１項に記載の情報通信方法において、
    前記外部プロキシサーバは、前記ファイアウォール内部に設置されたウェブサーバのアドレスを格納した転送先情報テーブルと、前記内部プロキシサーバとは別の通常プロキシサーバのアドレスとを保持し、
    前記第３工程では、ＨＴＴＰリクエストを受信した場合に、ＨＴＴＰリクエストの内容と前記転送先情報テーブルの内容とを比較することで、前記内部プロキシサーバに送信するか、前記通常プロキシサーバに送信するかを決定することを特徴とする情報通信方法。

Images