JP2006050191A - ネットワークシステム、内部サーバ、端末装置、プログラム、およびパケット中継方法 - Google Patents

Abstract

【課題】社内ネットワーク１とインターネット２との間に接続されたファイヤウォール１０を介して、インターネット２上の端末装置５０と社内ネットワーク１上の業務サーバ４０とが通信を行うネットワークシステムにおいてセキュリティの向上を図る。
【解決手段】ネットワークシステムにおいて、業務サーバ４０から内部サーバ３０が受信した端末装置５０向けのパケットに絶対アドレス情報が含まれている場合、内部サーバ３０はその絶対アドレス情報をＧＷサーバ２０経由に変更した後、そのパケットに対して端末装置５０のみ復号可能な暗号化を行い、その暗号化済みパケットをファイヤウォール１０を介してＧＷサーバ２０へ送信する。ＧＷサーバ２０は、内部サーバ３０で暗号化されたパケットを受信し、その暗号化済みパケットを復号化せずにそのまま端末装置５０に向けて送信する。
【選択図】図１

Description

本発明は、外部ネットワークと内部ネットワークとの間に接続されたファイヤウォールを介して、外部ネットワーク上の端末装置と内部ネットワーク上のアプリケーションサーバとが通信を行うネットワークシステムに関する。

インターネット環境の普及に伴い、自社の内部ネットワークをインターネット等の外部ネットワークに接続し、企業間でデータの授受を電子メールや、Ｗｅｂ（ＨＴＴＰ）で行う企業が増加している。

また、無線ＬＡＮやＰＨＳなど、インターネット等の外部ネットワークに対するモバイルアクセスの環境も急速に整いつつある。

そのような環境の中で、社員が外出先から自社の内部ネットワークにアクセスしたいという要求が出てきた。従来は、これを解決する手段として企業側にダイヤルアップの設備を用意していた。しかし、速度が遅いこと、コストがかかることから、最近では、インターネットなどから、ＶＰＮ、ＳＳＬ−ＶＰＮ（reverse proxy）などと呼ばれる技術を利用して接続するようになってきている。

ＶＰＮ（Virtual Private Network）とは、共有ネットワーク(インターネット）上にプライベートネットワークを構築する技術であり、例えば、インターネットで接続されたＡ拠点とＢ拠点の間に、暗号化されたチャネルを確保することであたかも専用線で接続されているような状況を作り出す技術のことである。この技術の応用によって、個人のクライアントＰＣをインターネットに接続し、企業側のファイヤウォールのＤＭＺに設置されたＶＰＮ装置にアクセスすると、個人のクライアントＰＣとＶＰＮ装置間が暗号化されたプロトコルで通信することで、安全にそのクライアントＰＣがあたかも企業内のネットワークに接続されているように使用することができるようになる。但し、企業側にはＶＰＮ装置（サーバ）が、クライアントＰＣ側にはクライアントソフトウェアが必要となる。

ＳＳＬ−ＶＰＮは、更に簡易に社内のリソースにアクセスするために、クライアントＰＣに特別なクライアントソフトウェアをインストールすることなしにＶＰＮと似た機能を提供しようとするものであり、社内のデータにアクセスするために、クライアントＰＣに通常は予めインストールされているＷＥＢブラウザを利用する。したがって、データアクセスの方法が、ＷＥＢブラウザでアクセス可能な範囲に限られてしまうことになるが、最近では様々な社内アプリケーションがＷＥＢベースで実現されてきていることから、実用上はそれほど問題にならないことが多く、特に最近注目されている。また、一旦接続されると直接社内ネットワークに接続したのと同じことができるＶＰＮとは異なり、接続しても予め定められたＷＥＢサーバにしかアクセスできないように設定できるため、セキュリティの観点からも好まれる傾向にある。

一方、社内ネットワークはインターネット等からの攻撃から守るため、外部ネットワークとはファイヤウォールを介して接続するのが一般的である。ファイヤウォールでは、インターネット側と社内ネットワーク側で、どのようなパケットを通すのかを細かく指定でき、社内ネットワーク側からインターネット側には、ＨＴＴＰやＨＴＴＰＳなどの一般的なプロトコルは許可し、インターネット側から社内ネットワーク側へは何も通さないように設定されるのが一般的である。

しかしながら、ＶＰＮやＳＳＬ−ＶＰＮのいずれの技術も、インターネット側から社内ネットワーク側にアクセスするための技術であるため、インターネット側から社内ネットワーク側方向へのアクセスを許容するようにファイヤウォールの設定を変更することが必須となる。この設定の変更はセキュリティ上の脅威となり得るとの懸念から、企業にとっては許容できないと判断される場合も多々存在する。

これに対して、特許文献１（製品名：ＳＷＡＮＳｔｏｒ（登録商標））のようなアクセス方式が考案された。この発明では、社内ネットワーク内の内部サーバとインターネットもしくはファイヤウォールのＤＭＺ上に置かれた外部サーバとの二つで構成され、接続リクエストは必ず内部サーバ側から外部サーバ側に出すことで、ファイヤウォールは通常の設定をなんら変更することなく接続することが可能となるものである。すなわち、内部サーバから外部サーバへ定期的に接続リクエストを出し続けることで、擬似的に継続して接続している状態を作り出すのである。

したがって、インターネット上のユーザが外部サーバに接続し、社内サーバへの接続の要求を送ると、外部サーバは内部サーバからの接続要求に対する応答として、社外のユーザからのリクエストを内部サーバに送付することになる。

内部サーバは社内ネット上に設置されているので、社内のサーバへは普通にアクセス可能であり、そこに接続し、返された結果を外部サーバへ送り、結果として外部サーバは社外のユーザに内部のデータを応答することで、社外ユーザが社内サーバへアクセスすることができるというものである。

さらに、ユーザのクライアントＰＣと外部サーバ間、外部サーバと内部サーバ間は、それぞれＳＳＬ（Secure Socket Layer）と呼ばれる暗号化プロトコルによって暗号化して通信するため、通信経路上も安全にデータが転送することができ、これによって、ファイヤウォールの設定を変更することなしに、社外の社員が社内のサーバに安全にアクセスする方法が提供されることとなった。

ところで、このような方法では、社内サーバから返されるデータ内に「特定のサーバを識別するための絶対アドレス情報」が含まれていると、問題が発生する。

すなわち、内部データから返されたデータ内に"http://intra.foo.var.co.jp/index.htm"というような特定の社内サーバを識別するようなアドレス情報が含まれている時、そのアドレス情報をユーザが選択すると、当然ながらインターネットから社内サーバは直接アクセスすることができないため、Ｗｅｂブラウザ上には「サーバが参照できない」、というエラーが表示されるという問題が発生することになる。

これに対しては、絶対アドレスの変換という処理が既に考案されている。すなわち、外部に転送する際のデータ内に絶対アドレス情報が含まれる際には、その絶対アドレス情報を外部サーバを経由するようなアドレス情報に変換するのである。例えば、外部サーバのアドレスが、"https://outside.abc.net"であったとすると、上記のアドレスを"https://outside.abc.net/intra.php?="http://intra.foo.var.co.jp/index.htm"というように変更する。このように変更すると、外部サーバがそのリクエストを受付け、さらに引数で指定されたアドレスは社内サーバへのものであると解釈して、社内サーバへ接続要求を出すのである。

特開２００２−１４０２３９号公報

しかしながら、このような手法をもってしても、さらに以下のような問題が生じる。

すなわち、上記方法では外部サーバと内部サーバ、外部サーバとクライアントはそれぞれＳＳＬで接続されているが、内部サーバから外部サーバへ送られたデータは外部サーバで一旦復号され、それが外部サーバで再暗号化されてクライアントへ送付される。したがって、外部サーバ上には、一瞬ではあるが非暗号化データが存在することになる。

このように、外部サーバ上に非暗号化データが存在すると、例えば、外部サーバが、独立したサービスプロバイダが運営するサービスサイト上で運営され、複数の企業の内部サーバがその外部サーバを共有して使うような運用の形態をとる場合、そのサービスサイト上で、複数の企業の暗号化されていない社外秘データがたとえ一瞬にしても残ることとなる。これはセキュリティの観点からは、データの漏洩に対する安全性が、運営会社の管理に委ねられることとなるため、好ましくない状況が生じてしまうことになる。

本発明は、上記のようなファイヤウォールの設定変更をしなくても外部ネットワークからアクセス可能なデータアクセス方式において、外部サーバ上においても、外部ネットワークと内部ネットワークとの間でやり取りされるデータが暗号化されていない状態で残らないようなデータのアクセス方法を提供することを一つの目的とする。

本発明に係るネットワークシステムは、外部ネットワークと内部ネットワークとの間に接続されるファイヤウォールと、外部ネットワーク上に存在する端末装置と、内部ネットワーク上に存在し、端末装置の要求に応じて所望のデータを端末装置に提供するアプリケーションサーバと、ファイヤウォールのＤＭＺ上もしくは外部ネットワーク上に存在し、端末装置からのアプリケーションサーバへの接続要求を受け付け、端末装置とアプリケーションサーバとの間の通信を中継する外部サーバと、内部ネットワーク上に存在し、外部サーバとアプリケーションサーバとの間の通信を中継する内部サーバと、を含み、外部サーバと内部サーバとは、ファイヤウォールのアクセス制限の設定により、内部サーバから外部サーバへの接続要求に基づき確立されたセッションでのみ通信が許可され、外部サーバは、内部サーバからの接続要求に対する応答として端末装置からのアプリケーションサーバへの接続要求を中継するネットワークシステムにおいて、内部サーバは、端末装置向けのパケットをアプリケーションサーバから受信する受信手段と、受信したパケットに対して端末装置のみ復号可能な暗号化を行う暗号化手段と、暗号化されたパケットをファイヤウォールを介して外部サーバへ送信する送信手段と、を備え、外部サーバは、内部サーバで暗号化されたパケットを受信する受信手段と、受信した暗号化済みパケットを復号化せずにそのまま端末装置に向けて送信する送信手段と、を備えることを特徴とする。

本発明によれば、内部サーバは受信した端末装置向けのパケットに対してその端末装置のみ復号可能な暗号化を行い、その暗号化済みパケットをファイヤウォールを介して外部サーバへ送信する。外部サーバは、内部サーバで暗号化されたパケットを受信し、その暗号化済みパケットを復号化せずにそのまま端末装置に向けて送信する。よって、ファイヤウォールのＤＭＺ上もしくは外部ネットワーク上に存在し、不特定多数のユーザがアクセスしうる外部サーバにおいて、内部ネットワークからのパケットが不用意に復号化されずに外部ネットワーク上の端末装置まで到達するため、外部サーバで一旦パケットの復号化を行う場合よりもセキュリティの向上を図ることができる。

本発明に係るネットワークシステムの一つの態様によれば、内部サーバは、受信手段で受信したパケットに内部ネットワーク上に存在するいずれかの通信装置にアクセスするための絶対アドレス情報が含まれているか否かを判定する判定手段と、絶対アドレス情報が含まれている場合、その絶対アドレス情報を外部サーバ経由に変更する変更手段と、を備え、暗号化手段は、絶対アドレス情報が含まれている場合、絶対アドレス情報を変更したパケットに対して受信先の端末装置のみ復号可能な暗号化を行う。

本発明よれば、内部サーバが、受信したパケットに内部ネットワーク上に存在するいずれかの通信装置にアクセスするための絶対アドレス情報が含まれている場合に、その絶対アドレス情報を外部サーバ経由に変更した後、そのパケットを暗号化して外部サーバへ送信する。よって、外部ネットワーク上の端末装置が、社内ネットワークからのパケットを受信し、そのパケットに含まれる絶対アドレス情報に基づいて、内部ネットワーク上に存在するいずれかの通信装置にアクセスする場合、端末装置はその通信装置に外部サーバ経由でアクセスするため、直接内部ネットワーク上のその通信装置に端末装置がアクセスすることで、ファイヤウォールの設定内容等によってアクセスを拒否されることを防止することができる。

本発明に係るネットワークシステムの一つの態様によれば、端末装置は、アプリケーションサーバが送信したパケットを受信する受信手段と、受信手段で受信したパケットに内部ネットワーク上に存在するいずれかの通信装置にアクセスするための絶対アドレス情報が含まれているか否かを判定する判定手段と、絶対アドレス情報が含まれている場合、その絶対アドレス情報を外部サーバ経由に変更する変更手段と、を備えることを特徴とする。

本発明によれば、内部ネットワーク上のいずれかの通信装置にアクセスするための絶対アドレス情報を含むパケットを端末装置が受信した場合に、端末装置がその絶対アドレス情報を外部サーバ経由に変更する。これにより、外部ネットワーク上の端末装置が、社内ネットワークからのパケットを受信し、そのパケットに含まれる絶対アドレス情報に基づいて、内部ネットワーク上に存在するいずれかの通信装置にアクセスする場合、端末装置はその通信装置に外部サーバ経由でアクセスする。よって、端末装置が直接内部ネットワーク上のその通信装置にアクセスすることで、ファイヤウォールの設定内容等によってアクセスを拒否されることを防止することができる。

本発明に係る第１の実施の形態（以下、実施形態１とする）について、以下図面を用いて説明する。

図１は、実施形態１におけるネットワークシステムのネットワーク構成を示す図である。実施形態１におけるネットワークシステムは、ファイヤウォール１０を中心として、社内ネットワーク１、インターネット２、ＤＭＺ（非武装地帯）３の、３つのネットワークを含み構成され、本システムは、主にインターネット２上の端末装置５０から社内ネットワーク１上の業務サーバ４０にアクセスして、端末装置５０が業務サーバ４０から所望のサービスを受けるためのシステムである。

図１において、社内ネットワーク１は、特定のユーザのみアクセス可能な内部ネットワークであり、インターネット２は、不特定多数のユーザがアクセス可能な外部ネットワークである。そして、ＤＭＺ３は、社内ネットワーク１からもインターネット２からも隔離され、社内ネットワーク１とインターネット２との間の通信を中継するネットワークである。

ファイヤウォール１０は、社内ネットワーク１やインターネット２から送信される他のネットワークに対する接続要求パケットをすべて捕捉し、恣意的にそのパケットを通過させたり禁止したりすることによって、必要なサービスだけをユーザーに提供しつつ、セキュリティを確保する装置である。実施形態１におけるファイヤウォール１０は、社内ネットワーク１から外側のネットワーク（ＤＭＺ３、インターネット２）への接続要求パケットの場合、使用するプロトコルがＨＴＴＰとＨＴＴＰＳであれば許可し、外側のネットワークから社内ネットワーク１への接続要求パケットの場合はすべてのプロトコルに対して禁止するように設定する。

ＧＷ（Getway）サーバ２０は、ＤＭＺ３上に設置され、インターネット２上の端末装置５０から社内ネットワーク１向けのパケットを受け付け、社内ネットワーク１へ転送し、さらに社内ネットワーク１から端末装置５０向けのパケットを受け付け、インターネット２へ転送する中継装置である。なお、ＧＷサーバ２０は、実施形態１ではＤＭＺ３に設置する例を示すが、社内ネットワーク１以外の例えばインターネット２上に設置しても構わない。

内部サーバ３０は、社内ネットワーク１上に設置され、インターネット２上の端末装置５０からの社内ネットワーク１向けのパケットを、ファイヤウォール１０を介してＧＷサーバ２０から受信して、そのパケットを端末装置５０により指定された業務サーバ４０に転送し、さらにその業務サーバ４０から端末装置５０向けのパケットを受け付け、ファイヤウォール１０を介してＧＷサーバ２０に転送する中継装置である。

業務サーバ４０は、端末装置５０等にＷｅｂベースの所望のサービスを提供するアプリケーションサーバである。

端末装置５０は、一般的なパーソナルコンピュータであり、無線や有線を介してインターネット２に接続されるクライアント端末である。

ＤＢサーバ６０は、業務サーバ４０が提供するサービスにおいて、補足的な役割をする通信装置の一つであり、例えば、業務サーバ４０が提供するＷｅｂ画面上に表示される参照先アドレスを有し、端末装置５０がその参照先アドレスにアクセスしてきた際に、追加のデータを端末装置５０に提供するサーバである。

このように構成されたネットワークシステムにおいて、インターネット上の端末装置５０が社内ネットワーク上の業務サーバ４０にアクセスする場合、端末装置５０は、ＧＷサーバ２０・内部サーバ３０を介して業務サーバ４０と通信を行う。

しかし、上述のとおり、ファイヤウォール１０の設定により、ＧＷサーバ２０から内部サーバ３０への接続要求パケットの送信は禁止されているため、ＧＷサーバ２０が端末装置５０から業務サーバ４０への接続要求を受け付けた場合に、まずＧＷサーバ２０が中継先の内部サーバ３０とのセッションを確立すべく、内部サーバ３０に対して接続要求パケットを送信したとしても、ファイヤウォール１０でそのパケットは破棄されてしまう。よって、このままでは端末装置５０は業務サーバ４０とは通信を行うことができない。

そこで、実施形態１では、ＧＷサーバ２０と内部サーバ３０との間のセッションが、内部サーバ３０からの接続要求によって常に維持されるようにＧＷサーバ２０と内部サーバ３０とを構成し、擬似的にＧＷサーバ２０からの接続要求パケットを内部サーバ３０が受信できるようにする。なお、ファイヤウォール１０の設定を変更することなく、擬似的にＧＷサーバ２０からの接続要求パケットを内部サーバ３０が受信できるようにする技術は、例えば特許文献１に記載された技術を用いて実現すればよい。

ただ、このように構成されたネットワークシステムにおいて、端末装置５０からの要求に応じて業務サーバ４０が提供するパケットに、社内ネットワーク上に存在するＤＢサーバ６０等のいずれかの通信装置にアクセスするための絶対アドレス情報が含まれている場合、その絶対アドレス情報に基づいて、端末装置５０が社内ネットワーク１上の通信装置に直接アクセスしようとしても、上記ファイヤウォール１０の設定により、その通信装置への接続は拒否されてしまう。

このような事態を避けるために従来の技術では、パケットに絶対アドレス情報が含まれている場合、端末装置５０と業務サーバ４０との通信を中継するＧＷサーバ２０において、その絶対アドレス情報をＧＷサーバ２０経由の絶対アドレス情報に書き替え、端末装置５０が直接絶対アドレス情報に示された参照先の通信装置へ接続を試みることを防止していた。

しかし上記方法では、内部サーバ３０からＧＷサーバ２０へ送られたパケットが、たとえ内部サーバ３０等において暗号化されたとしても、インターネット上の不特定多数のユーザの端末装置がアクセスしうるＤＭＺ上に存在するＧＷサーバ２０において一旦復号されてしまうため、セキュリティ上の問題が生じる恐れがある。

そこで、実施形態１では、絶対アドレス情報の変更を内部サーバ３０で行い、さらに内部サーバ３０では、パケットを端末装置５０のみで復号可能な暗号化を行う。具体的には、内部サーバ３０と端末装置５０が、ＧＷサーバ２０を経由して接続されている通信経路上に、擬似的に内部サーバ３０と端末装置５０が直接ＳＳＬで接続されるように各装置において処理を行う。これにより、ＧＷサーバ２０において、絶対アドレス情報の変更のためにパケットを復号化する必要がなくなり、セキュリティの向上を図ることができる。

以下、インターネット２上の端末装置５０が、社内ネットワーク１上の業務サーバ４０と通信を行う手順を、図２を用いてさらに詳しく説明する。なお、実施形態１では、各装置をネットワーク上で一意に識別するための識別情報として、ＵＲＬを用いる。具体的には、ＧＷサーバ２０のＵＲＬは、https://gw.foo.net、内部サーバ３０のＵＲＬは、https://srv.bar.co.jp、業務サーバ４０のＵＲＬは、http://intra.abc.bar.co.jpとする。

図２において、まず端末装置５０は、業務サーバ４０と通信を開始するために、ＧＷサーバ２０に対して接続要求パケットを送信する（Ｓ１０１）。接続要求パケットには、接続先の業務サーバを識別するために、ＵＲＬ情報としてhttps://gw.foo.net/http://intra.abc.bar.co.jpが示される。

ＧＷサーバ２０は、インターネット２上の端末装置５０からの接続要求パケットの受信をするために待機している。そして、端末装置５０からの接続要求パケットを受け取った場合、ＧＷサーバ２０はそのパケットに示されるＵＲＬ情報の自分自身のアドレス以下、すなわちこの例の場合は、https://gw.foo.net以下に示されたhttp://intra.abc.bar.co.jpを参照して、この業務サーバ４０に対する内部サーバ３０のアドレスを特定する（Ｓ１０２）。内部サーバ３０のアドレス特定は、例えば次に示すようなルールに従い行えばよい。すなわち、ドメイン名"bar.co.jp"に特定のホスト名"srv"を連結したもの"srv.bar.co.jp"を内部サーバ３０のアドレスとして特定する。または、予めＧＷサーバ２０上のデータベースに、各業務サーバに対する内部サーバのアドレスをそれぞれ関連づけて登録しておき、その都度データベースを参照することで接続先の業務サーバに対する内部サーバのアドレスを特定してもよい。このようにして内部サーバ３０のアドレスを特定した後、ＧＷサーバ２０はその内部サーバ３０に対してＳＳＬサイト証明書を要求する（Ｓ１０３）。

ＳＳＬサイト証明書を要求された内部サーバ３０は、自身のＳＳＬサイト証明書をＧＷサーバ２０に送信する（Ｓ１０４）。なお、内部サーバ３０のＳＳＬサイト証明書をＧＷサーバ２０のメモリに予め登録しておくことで、その都度ＧＷサーバ２０が、特定した内部サーバに対してＳＳＬサイト証明書を要求しないように構成してもよい。なお、ＳＳＬサイト証明書には、対象となるサーバのURL情報が埋め込まれており、SSL証明書内のURL情報と、端末装置５０が接続しているURLが一致しているかどうかを、端末装置５０で検査されることになる。そこで、ここで用いるＳＳＬ証明書には、予めＧＷサーバ２０のURL情報が埋め込まれたものとする（但し、このサイト証明書に対する秘密鍵は、実際に暗号化処理を行う内部サーバ３０のみで管理されることとする）。こうすることで、端末装置５０が接続しているのはＧＷサーバ２０であるから、端末装置で行われるURLの検査にパスさせることができる。

続いて、ＧＷサーバ２０は、受信した内部サーバ３０のＳＳＬサイト証明書を端末装置５０に送信する（Ｓ１０５）。

端末装置５０は、受信したＳＳＬサイト証明書を用いて、従来のＳＳＬと同様のプロトコル手順を踏み、鍵交換情報を生成し（Ｓ１０６）、その鍵交換情報をＧＷサーバ２０に送信する（Ｓ１０７）。

鍵交換情報を受信したＧＷサーバ２０は、その鍵交換情報とＳ１０１において受信したＵＲＬ情報を内部サーバ３０に送信する（Ｓ１０８）。

それらの情報を受信した内部サーバ３０は、自身のＳＳＬサイト証明書と受信した鍵交換情報とを用いて共通鍵を生成する（Ｓ１０９）。端末装置５０も内部サーバ３０と同様な手順により、ＳＳＬサイト証明書と鍵交換情報とを用いて共通鍵を生成する（Ｓ１０９’）。以降、端末装置５０と内部サーバ３０とは、この共通鍵を使用してお互いに暗号化されたパケットの送受信を行う。

そして、内部サーバ３０は、受信したＵＲＬ情報に示された業務サーバ４０のアドレス"http://intra.abc.bar.co.jp"に対して接続要求パケットを送信する（Ｓ１１０）。この接続要求パケットに基づき、内部サーバ３０と業務サーバ４０との間にセッションが確立され、業務サーバ４０が端末装置５０から要求のあったデータを含むパケットを内部サーバ３０に送信する（Ｓ１１１）。

そのパケットを受信した内部サーバ３０は、そのパケットに含まれるＨＴＭＬ表現データの中に、絶対アドレス情報が含まれているか否かを判定する（Ｓ１１２）。絶対アドレス情報が含まれている場合には、さらにその絶対アドレス情報に示された参照先（アクセス先）のＵＲＬが社内ネットワークのものかどうかを判定する（Ｓ１１３）。判定の結果、絶対アドレス情報が含まれている場合には、その絶対アドレス情報をＧＷサーバ経由となるように変更する（Ｓ１１４）。具体的には、例えばＨＴＭＬ表現データの中に含まれている絶対アドレス情報が"http://intra2.abc.bar.co.jp/public/index.htm"であった場合、内部サーバ３０は、参照先のＵＲＬが社内ネットワークのものであるかどうかをサーバ名のドメインを比較することで判定し、そのＵＲＬが社内ネットワークのものであった場合には、そのＵＲＬの先頭に内部サーバが現在接続しているＧＷサーバのＵＲＬ"https://gw.foo.net"を連結し、"https://gw.foo.net/http://intra2.abc.bar.co.jp/public/index.htm "という絶対アドレス情報に変更する。このように絶対アドレス情報を変更することで、端末装置５０が直接社内ネットワークのアドレスに対してアクセスせず、ＧＷサーバ２０経由でアクセスするため、インターネット２上に存在する端末装置５０から社内ネットワーク１へアクセスできないという不具合を解消することができる。

続いて、内部サーバ３０は、業務サーバ４０から受信したパケットに参照先が社内ネットワークのものである絶対アドレス情報が含まれている場合には、その絶対アドレス情報が変更されたパケットをＳ１０９で生成した共通鍵を用いて暗号化し（Ｓ１１５）、ＧＷサーバ２０に暗号化されたパケットを送信する（Ｓ１１６）。なお、図２では示していないが、参照先が社内ネットワークである絶対アドレス情報がパケットに含まれてない場合には、内部サーバ３０は業務サーバ４０から受信したそのパケットをそのまま暗号化してＧＷサーバ２０に送信する。

続いてＧＷサーバ２０は、受信したパケットを復号化せずそのままそのパケットを端末装置５０に送信する（Ｓ１１７）。端末装置５０は、受信したパケットを、Ｓ１０９’で生成した共通鍵を用いて復号化し結果をＷｅｂブラウザ上に表示する（Ｓ１１８）。

以上、実施形態１によれば、例えば、業務サーバ４０から提供されたＨＴＭＬ文書に埋め込まれている絶対アドレス情報の参照先が社内ネットワーク上のアドレスであったとしも、ＧＷサーバ２０経由のアドレス情報に変更されるため、端末装置５０が直接社内ネットワークにアクセスすることで、そのアクセスが拒否されることを防止することができる。

また、業務サーバ４０と端末装置５０との間でやり取りされるパケットは、内部サーバ３０と端末装置５０との間で生成された共通鍵で暗号化されるため、内部サーバ３０と端末装置５０との間でパケットの中継を行うＧＷサーバ２０では復号化されない。よって、不特定多数のユーザがアクセスしうるＧＷサーバ２０上に不用意に暗号化されていないデータが存在しないため、セキュリティの向上を図ることができる。

さらに、実施形態１のように、内部サーバ側で絶対アドレス情報の変更を行う場合、端末装置側では特に特別なソフトウェアを導入する必要がないため、端末装置側での設定作業等の手間を低減することができる。

ただ、絶対アドレス情報の変更は、内部サーバ側ではなく端末装置側で行っても構わない。この場合、多数の端末装置が存在する場合でも、各端末装置側でそれぞれ絶対アドレス情報の変更処理が行われるため、内部サーバの処理負担を低減することができる。

そこで、以下、本発明の第２の実施の形態（以下、実施形態２とする）として、端末装置側で絶対アドレス情報の変更を行う場合について、図面を用いて説明する。

実施形態２では、端末装置５０に組み込まれたＷｅｂブラウザに予め機能を追加するか、もしくは特別なＨｅｌｐｅｒプログラム（指定されたｍｉｍｅタイプのデータを処理するプログラム）を予め端末装置５０のメモリに記憶しておき、その都度端末装置５０に搭載したＣＰＵがそのプログラムを読み出すことで、端末装置５０側で絶対アドレス情報の変更処理を行う。

ここで、実施形態２においてインターネット２上の端末装置５０が、社内ネットワーク１上の業務サーバ４０と通信を行う手順を、図３を用いて説明する。なお、Ｓ２０１〜Ｓ２１１までは実施形態１におけるＳ１０１〜Ｓ１１１と同様な手順であるため簡単に説明し、Ｓ２１２以降について詳しく説明する。

まず端末装置５０は、業務サーバ４０と通信を開始するために、ＧＷサーバ２０に対して接続要求パケットを送信する（Ｓ２０１）。ＧＷサーバ２０は端末装置５０から接続要求パケットを受信し、そのパケットに示されるＵＲＬ情報の自分自身のアドレス以下を参照して、この業務サーバ４０に対する内部サーバ３０のアドレスを特定する（Ｓ２０２）。さらにＧＷサーバ２０は特定した内部サーバ３０に対してＳＳＬサイト証明書を要求する（Ｓ２０３）。ＳＳＬサイト証明書を要求された内部サーバ３０は、自身のＳＳＬサイト証明書をＧＷサーバ２０に送信する（Ｓ２０４）。

続いて、ＧＷサーバ２０は、受信した内部サーバ３０のＳＳＬサイト証明書を端末装置５０に送信する（Ｓ２０５）。端末装置５０は、受信したＳＳＬサイト証明書を用いて鍵交換情報を生成し（Ｓ２０６）、その鍵交換情報をＧＷサーバ２０に送信する（Ｓ２０７）。鍵交換情報を受信したＧＷサーバ２０は、その鍵交換情報とＳ２０１において受信したＵＲＬ情報を内部サーバ３０に送信する（Ｓ２０８）。

それらの情報を受信した内部サーバ３０は、自身のＳＳＬサイト証明書と受信した鍵交換情報とを用いて共通鍵を生成する（Ｓ２０９）。端末装置５０も内部サーバ３０と同様な手順により、ＳＳＬサイト証明書と鍵交換情報とを用いて共通鍵を生成する（Ｓ２０９’）。そして、内部サーバ３０は、受信したＵＲＬ情報に示された業務サーバ４０のアドレス"http://intra.abc.bar.co.jp"に対して接続要求パケットを送信する（Ｓ２１０）。この接続要求パケットに基づき、内部サーバ３０と業務サーバ４０との間にセッションが確立され、業務サーバ４０が端末装置５０から要求のあったデータを含むパケットを内部サーバ３０に送信する（Ｓ２１１）。

さらに内部サーバ３０は、端末装置５０により要求のあったデータを含むパケットを業務サーバ４０から受信した後、その受信したパケットのデータ部分に所定のｍｉｍｅタイプ、例えば"application/x-special-ssl-vpn"を付与し（Ｓ２１２）、そのパケットをＳ２０９で生成した共通鍵で暗号化する（Ｓ２１３）。そして、暗号化されたパケットをＧＷサーバ２０に送信する（Ｓ２１４）。ＧＷサーバ２０は、内部サーバ３０からファイヤウォール１０を介して受信したパケットを復号化せず、そのままそのパケットを端末装置５０に送信する（Ｓ２１５）。

端末装置５０は、受信したパケットをＳ２０９’で生成した共通鍵で復号化し（Ｓ２１６）、さらにパケットに付与されたｍｉｍｅタイプを参照して、そのｍｉｍｅタイプに応じたＨｅｌｐｅｒアプリケーションを起動し、絶対アドレス情報の変更を行う（Ｓ２１７）。

Ｈｅｌｐｅｒアプリケーションによる絶対アドレス情報の変更は、例えば、次のように行う。

すなわち絶対アドレス情報が"http://intra2.abc.bar.co.jp/public/index.htm"の場合、まずそのＵＲＬが社内ネットワーク１上に存在するＵＲＬかどうかを、最初に接続しようとしているサーバ名のドメインと社内ネットワーク１のドメインとを比較することで判定し、社内ネットワーク１上に存在するＵＲＬであった場合に、そのＵＲＬの先頭に端末装置５０が現在接続しているＧＷサーバ２０のＵＲＬ"https://gw.foo.net"を連結して、"https://gw.foo.net/http://intra2.abc.bar.co.jp/public/index.htm "という絶対アドレス情報に変更する。

そして、このように絶対アドレス情報を変更した後のＨＴＭＬデータをＷｅｂブラウザ上に表示する（Ｓ２１８）。なお、図３では示していないが、参照先が社内ネットワークの絶対アドレス情報がパケットに含まれてない場合には、端末装置５０はＨｅｌｐｅｒアプリケーションを起動せずに受信したパケットに含まれるＨＴＭＬデータをそのままＷｅｂブラウザ上に表示すればよい。

以上、実施形態２によれば、ユーザがブラウザ上に表示された絶対アドレス情報に対応するアドレスを指定して、そのアドレスに対して接続要求を行った場合にも、ＧＷサーバ経由で接続されるため、直接社内ネットワークに接続要求することによって接続が拒否されることを防止することができる。

また、実施形態２でも実施形態１と同様に業務サーバ４０と端末装置５０との間でやり取りされるパケットは、内部サーバ３０と端末装置５０との間で生成された共通鍵で暗号化されるため、内部サーバ３０と端末装置５０との間でパケットの中継を行うＧＷサーバ２０では復号化されない。よって、不特定多数のユーザがアクセスしうるＧＷサーバ２０上に不用意に暗号化されていないデータが存在しないため、セキュリティの向上を図ることができる。

なお、実施形態１もしくは２において、端末装置５０がＧＷサーバ２０を経由して社内ネットワーク１に接続する際に、ユーザ認証を行う必要が有れば、端末装置５０がＧＷサーバ２０に対して接続要求パケットを送信した際に、ＧＷサーバ２０がその端末装置５０に対してユーザＩＤやパスワードといったユーザ情報を要求し、ユーザ認証を行えばよい。またユーザ認証は、ＧＷサーバ２０で行わず、ＧＷサーバ２０から内部サーバ３０にユーザ情報を転送し、内部サーバ３０においてＬＤＡＰなどを用いて行っても構わない。さらにユーザ認証は、ユーザＩＤとパスワードではなく、公開鍵暗号化方式での証明書の認証により行ってもよい。

また、実施形態１および２では、図１に示すように１台のファイヤウォール１０でＤＭＺを構築する例を示したが、ファイヤウォールは１台の場合に限らず、例えば図４に示すように２台のファイヤウォールを用いてＤＭＺを構築する場合にも適用可能である。

実施形態１および２におけるネットワークシステムのネットワーク構成を示す図である。 実施形態１において、インターネットの端末装置が社内ネットワーク上の業務サーバと通信を行う手順を示す図である。 実施形態２において、インターネットの端末装置が社内ネットワーク上の業務サーバと通信を行う手順を示す図である。 実施形態１および２でのネットワークシステムにおいて適用可能なネットワーク構成の一例を示す図である。

符号の説明

１ 社内ネットワーク、２ インターネット、３ ＤＭＺ、１０ ファイヤウォール、２０ ＧＷサーバ、３０ 内部サーバ、４０ 業務サーバ、５０ 端末装置、６０ ＤＢサーバ。

Claims (9)

1. 外部ネットワークと内部ネットワークとの間に接続されるファイヤウォールと、
   外部ネットワーク上に存在する端末装置と、
   内部ネットワーク上に存在し、端末装置の要求に応じて所望のデータを端末装置に提供するアプリケーションサーバと、
   ファイヤウォールのＤＭＺ上もしくは外部ネットワーク上に存在し、端末装置からのアプリケーションサーバへの接続要求を受け付け、端末装置とアプリケーションサーバとの間の通信を中継する外部サーバと、
   内部ネットワーク上に存在し、外部サーバとアプリケーションサーバとの間の通信を中継する内部サーバと、
   を含み、
   外部サーバと内部サーバとは、ファイヤウォールのアクセス制限の設定により、内部サーバから外部サーバへの接続要求に基づき確立されたセッションでのみ通信が許可され、外部サーバは、内部サーバからの接続要求に対する応答として端末装置からのアプリケーションサーバへの接続要求を中継するネットワークシステムにおいて、
   内部サーバは、
   端末装置向けのパケットをアプリケーションサーバから受信する受信手段と、
   受信したパケットに対して端末装置のみ復号可能な暗号化を行う暗号化手段と、
   暗号化されたパケットをファイヤウォールを介して外部サーバへ送信する送信手段と、
   を備え、
   外部サーバは、
   内部サーバで暗号化されたパケットを受信する受信手段と、
   受信した暗号化済みパケットを復号化せずにそのまま端末装置に向けて送信する送信手段と、
   を備えることを特徴とするネットワークシステム。
2. 請求項１に記載のネットワークシステムにおいて、
   内部サーバは、
   受信手段で受信したパケットに内部ネットワーク上に存在するいずれかの通信装置にアクセスするための絶対アドレス情報が含まれているか否かを判定する判定手段と、
   絶対アドレス情報が含まれている場合、その絶対アドレス情報を外部サーバ経由に変更する変更手段と、
   を備え、
   暗号化手段は、絶対アドレス情報が含まれている場合、絶対アドレス情報を変更したパケットに対して受信先の端末装置のみ復号可能な暗号化を行うことを特徴とするネットワークシステム。
3. 請求項１に記載のネットワークシステムにおいて、
   端末装置は、
   アプリケーションサーバが送信したパケットを受信する受信手段と、
   受信手段で受信したパケットに内部ネットワーク上に存在するいずれかの通信装置にアクセスするための絶対アドレス情報が含まれているか否かを判定する判定手段と、
   絶対アドレス情報が含まれている場合、その絶対アドレス情報を外部サーバ経由に変更する変更手段と、
   を備えることを特徴とするネットワークシステム。
4. 外部ネットワークと内部ネットワークとの間に接続されるファイヤウォールを介して、ファイヤウォールのＤＭＺ上もしくは外部ネットワーク上に存在する外部サーバと通信を行う内部ネットワーク上に存在する内部サーバであって、外部サーバとはファイヤウォールのアクセス制限の設定により、自身から外部サーバへの接続要求に基づき確立されたセッションでのみ通信が許可され、自身から外部サーバへの接続要求に対する応答として、外部ネットワーク上の端末装置から外部サーバ経由で中継される内部ネットワーク上のアプリケーションサーバへの接続要求をアプリケーションサーバへ中継する内部サーバにおいて、
   外部ネットワーク上の端末装置向けのパケットをアプリケーションサーバから受信する受信手段と、
   受信したパケットに対して受信先の端末装置のみ復号可能な暗号化を行う暗号化手段と、
   暗号化されたパケットを中継先の外部サーバへ送信する送信手段と、
   を備えることを特徴とする内部サーバ。
5. 請求項４に記載の内部サーバにおいて、
   受信手段で受信したパケットに内部ネットワーク上のいずれかの通信装置にアクセスするための絶対アドレス情報が含まれているか否かを判定する判定手段と、
   絶対アドレス情報が含まれている場合、その絶対アドレス情報を外部サーバ経由に変更する変更手段と、
   を備え、
   暗号化手段は、絶対アドレス情報が含まれている場合、絶対アドレス情報を変更したパケットに対して受信先の端末装置のみ復号可能な暗号化を行うことを特徴とする内部サーバ。
6. 外部ネットワークと内部ネットワークとの間に接続されるファイヤウォールと、内部ネットワーク上に存在し、外部ネットワークからの要求に応じて所望のデータを提供するアプリケーションサーバと、ファイヤウォールのＤＭＺ上もしくは外部ネットワーク上に存在し、外部ネットワークからのアプリケーションサーバへの接続要求を受け付け、アプリケーションサーバとの通信を中継する外部サーバと、内部ネットワーク上に存在し、外部サーバとアプリケーションサーバとの間の通信を中継する内部サーバと、を含み、外部サーバと内部サーバとは、ファイヤウォールのアクセス制限の設定により、内部サーバから外部サーバへの接続要求に基づき確立されたセッションでのみ通信が許可され、外部サーバは、内部サーバからの接続要求に対する応答として外部ネットワークからのアプリケーションサーバへの接続要求を中継するネットワークシステムにおける外部ネットワーク上で、アプリケーションサーバから所望のデータの提供を受ける端末装置であって、
   アプリケーションサーバが送信したパケットを受信する受信手段と、
   受信手段で受信したパケットに内部ネットワーク上に存在するいずれかの通信装置にアクセスするための絶対アドレス情報が含まれているか否かを判定する判定手段と、
   絶対アドレス情報が含まれている場合、その絶対アドレス情報を外部サーバ経由に変更する変更手段と、
   を備えることを特徴とする端末装置。
7. 外部ネットワークと内部ネットワークとの間に接続されるファイヤウォールを介して、ファイヤウォールのＤＭＺ上もしくは外部ネットワーク上に存在する外部サーバと通信を行う内部ネットワーク上に存在する内部サーバであって、外部サーバとはファイヤウォールのアクセス制限の設定により、自身から外部サーバへの接続要求に基づき確立されたセッションでのみ通信が許可され、自身から外部サーバへの接続要求に対する応答として、外部ネットワーク上の端末装置から外部サーバ経由で中継される内部ネットワーク上のアプリケーションサーバへの接続要求をアプリケーションサーバへ中継する内部サーバを、コンピュータを用いて制御するためのプログラムであって、
   外部ネットワーク上の端末装置向けのパケットをアプリケーションサーバから受信する受信ステップと、
   受信したパケットに内部ネットワーク上のいずれかの通信装置にアクセスするための絶対アドレス情報が含まれているか否かを判定する判定ステップと、
   絶対アドレス情報が含まれている場合、その絶対アドレス情報を外部サーバ経由に変更する変更ステップと、
   受信したパケットに対して、絶対アドレス情報が含まれている場合は絶対アドレス情報を変更した後、絶対アドレス情報が含まれていない場合はそのまま、端末装置のみ復号可能な暗号化を行う暗号化ステップと、
   暗号化されたパケットを中継先の外部サーバへ送信する送信ステップと、
   を実行させるように、コンピュータを用いて内部サーバを制御するためのプログラム。
8. 外部ネットワークと内部ネットワークとの間に接続されるファイヤウォールと、内部ネットワーク上に存在し、外部ネットワークからの要求に応じて所望のデータを提供するアプリケーションサーバと、ファイヤウォールのＤＭＺ上もしくは外部ネットワーク上に存在し、外部ネットワークからのアプリケーションサーバへの接続要求を受け付け、アプリケーションサーバとの通信を中継する外部サーバと、内部ネットワーク上に存在し、外部サーバとアプリケーションサーバとの間の通信を中継する内部サーバと、を含み、外部サーバと内部サーバとは、ファイヤウォールのアクセス制限の設定により、内部サーバから外部サーバへの接続要求に基づき確立されたセッションでのみ通信が許可され、外部サーバは、内部サーバからの接続要求に対する応答として外部ネットワークからのアプリケーションサーバへの接続要求を中継するネットワークシステムにおける外部ネットワーク上で、アプリケーションサーバから所望のデータの提供を受ける端末装置を、コンピュータを用いて制御するためのプログラムであって、
   アプリケーションサーバが送信したパケットを受信する受信ステップと、
   受信したパケットに内部ネットワーク上に存在するいずれかの通信装置にアクセスするための絶対アドレス情報が含まれているか否かを判定する判定ステップと、
   絶対アドレス情報が含まれている場合、その絶対アドレス情報を外部サーバ経由に変更する変更ステップと、
   を実行させるように、コンピュータを用いて端末装置を制御するためのプログラム。
9. 外部ネットワークと内部ネットワークとの間に接続されるファイヤウォールと、
   外部ネットワーク上に存在する端末装置と、
   内部ネットワーク上に存在し、端末装置の要求に応じて所望のデータを端末装置に提供するアプリケーションサーバと、
   ファイヤウォールのＤＭＺ上もしくは外部ネットワーク上に存在し、端末装置からのアプリケーションサーバへの接続要求を受け付け、端末装置とアプリケーションサーバとの間の通信を中継する外部サーバと、
   内部ネットワーク上に存在し、外部サーバとアプリケーションサーバとの間の通信を中継する内部サーバと、
   を含み、
   外部サーバと内部サーバとは、ファイヤウォールのアクセス制限の設定により、内部サーバから外部サーバへの接続要求に基づき確立されたセッションでのみ通信が許可され、外部サーバは、内部サーバからの接続要求に対する応答として端末装置からのアプリケーションサーバへの接続要求を中継するネットワークシステム上において、パケットの中継処理を行うためのパケット中継方法であって、
   内部サーバが、端末装置向けのパケットをアプリケーションサーバから受信する受信工程と、
   内部サーバが、受信ステップで受信したパケットに内部ネットワーク上に存在するいずれかの通信装置にアクセスするための絶対アドレス情報が含まれているか否かを判定する判定工程と、
   絶対アドレス情報が含まれている場合、内部サーバがその絶対アドレス情報を外部サーバ経由に変更する変更工程と、
   受信したパケットに対して、絶対アドレス情報が含まれている場合は絶対アドレス情報を変更した後、絶対アドレス情報が含まれていない場合はそのまま、端末装置のみ復号可能な暗号化を行う暗号化工程と、
   内部サーバが、暗号化されたパケットをファイヤウォールを介して外部サーバへ送信する送信工程と、
   外部サーバが、内部サーバで暗号化されたパケットを受信する受信工程と、
   外部サーバが、受信した暗号化済みパケットを復号化せずにそのまま端末装置に向けて送信する送信工程と、
   を含むパケット中継方法。

Images