JP2018514956A - データをルーティングするために証明書データを使用する装置と方法 - Google Patents

Abstract

ネットワークを介してデータをルーティングする方法は、複数のノードを有しているローカルネットワーク内の少なくとも１つのノードにアクセスするクライアントノードからセッションリクエストを受信する。また本方法は、クライアント証明書（例えば、公知の標準、例えば「Ｘ５０９標準」によって少なくとも部分的に仕様が定められているディジタル証明書）をクライアントノードから受信する。クライアント証明書は、クライアントノードからパケットを受信する少なくとも１つのノードを指定するクライアント情報を有している。次に、本方法はクライアント証明書を使用して、認証プロセスを実行する。認証プロセスによってクライアントノードが認証された場合、本方法は、データパケットをクライアントノードから、クライアント証明書におけるクライアント情報によって指定された通りに、ローカルネットワーク内の少なくとも１つのノードにルーティングする。

Description

関連出願
本願は、２０１４年９月２６日に出願された米国特許出願第１４／４９７，９５４号、発明の名称「ネットワークパケットフローコントローラ（ＮＥＴＷＯＲＫ ＰＡＣＫＥＴ ＦＬＯＷ ＣＯＮＴＲＯＬＬＥＲ）」、代理人整理番号４０９４／１００１、発明者Ｍｅｌａｍｐｙ、Ｂａｊ、Ｋａｐｌａｎ、Ｋｕｍａｒ、Ｐｅｎｆｉｅｌｄ及びＴｉｍｍｏｎｓ、に関連するものであり、その開示内容全体は参照により本願に組み込まれる。

本願は、また、２０１４年１２月８日に出願された米国特許出願第１４／５６２，９１７号、発明の名称「ステートレスなネットワークにおけるステートフルなロードバランシング（ＳＴＡＴＥＦＵＬ ＬＯＡＤ ＢＡＬＡＮＣＩＮＧ ＩＮ Ａ ＳＴＡＴＥＬＥＳＳ ＮＥＴＷＯＲＫ）」、代理人整理番号４０９４／１００２、発明者Ｔｉｍｍｏｎｓ、Ｂａｊ、Ｋａｐｌａｎ、Ｍｅｌａｍｐｙ、Ｋｕｍａｒ及びＰｅｎｆｉｅｌｄ、に関連するものであり、その開示内容全体は参照により本願に組み込まれる。

本ＰＣＴ出願は、２０１５年３月１７日に出願された米国特許出願第１４／６６０，５００号、発明の名称「データをルーティングするために証明書データを使用する装置と方法（ＡＰＰＡＲＡＴＵＳ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＵＳＩＮＧ ＣＥＲＴＩＦＩＣＡＴＥ ＤＡＴＡ ＴＯ ＲＯＵＴＥ ＤＡＴＡ）」、代理人整理番号４０９４／１００５、発明者Ｋｕｍａｒ、Ｔｉｍｍｏｎｓ及びＭｅＬａｍｐｙ、の優先権を主張するものであり、その開示内容全体は参照により本願に組み込まれる。

技術分野
本発明は、一般的には、ネットワークデバイスに関し、より詳細には、ネットワークルーティングデバイスについてのセキュリティに関する。

インターネットプロトコル（「ＩＰ」）は、データメッセージ（「データグラム」）を、インターネットに接続されているネットワークデバイス間で転送するためのデファクトスタンダードとして使用されている。そのために、ＩＰは、一連のインターネットデバイスを介して、例えばルータ及びスイッチを介して、データグラムを１つ又は複数のデータパケットの形態で供給する。各パケットは、２つの主要部分、即ち、（１）伝送される情報（例えばテキストデータ、グラフィックデータ、オーディオデータ又はビデオデータ）を有しているペイロード、並びに、（２）（１つ又は複数の）パケットを受信するネットワークデバイス（「宛先デバイス」）のアドレス、パケットを送信するネットワークデバイス（「起源デバイス」）の識別子及びパケットをルーティングするためのその他のデータを有している、「ＩＰヘッダ」として公知であるヘッダ。従って、多くの人々は、パケットを一般郵便／ファーストクラスメール（ｆｉｒｓｔ ｃｌａｓｓ ｍａｉｌ）を使用する慣例の伝統的な手紙を例にして説明している。つまり、手紙は、ペイロードとして機能し、また差出人住所及び宛先住所が示されている封書は、ＩＰヘッダとして機能する。

ハッカーは、第三者のインターネットデバイス、例えばデータセンタ内のアプリケーションサービスにアクセスして、違法な操作を行うことを頻繁に試みている。そのような違反行為によって大量のデータが漏洩する可能性がある。データの漏洩によって詐欺行為が蔓延し、その被害額は数十億ドルにも達する。

種々の実施の形態の概要
本発明の１つの実施の形態によれば、ネットワークを介してデータをルーティングする方法は、複数のノードを有しているローカルネットワーク内の少なくとも１つのノードにアクセスするクライアントノードからセッションリクエストを受信する。また本方法は、クライアント証明書（例えば、公知の標準、例えば「Ｘ５０９標準」によって少なくとも部分的に仕様が定められているディジタル証明書）をクライアントノードから受信する。クライアント証明書は、クライアントノードからパケットを受信する少なくとも１つのノードを指定するクライアント情報を有している。次に、本方法は、クライアント証明書を使用して、認証プロセスを実行する。認証プロセスによってクライアントノードが認証された場合には、本方法は、データパケットをクライアントノードから、クライアント証明書におけるクライアント情報によって指定された通りに、ローカルネットワーク内の少なくとも１つのノードにルーティングする。

認証プロセスによって、クライアントノードを認証できない場合には、本方法はクライアントノードを拒絶することができる。例えば、本方法は、クライアントノードのパケットが、ローカルネットワーク内のその他のノードにアクセスすることを効率的にブロックすることができる（即ち、本方法はクライアントノードから受信するパケットを単純に転送するものではない）。

図示の実施の形態は、データパケットを受信する、ローカルネットワーク内の少なくとも１つのノードの識別子を求めるためのクライアント情報を使用してデータパケットをルーティングする。従って、ルーティングが行われるということは、クライアントノードに少なくとも１つのノードへのアクセスが許可されたとみなすことができる。

とりわけ、クライアント情報は、ａ）クライアントノードを識別する識別情報、ｂ）ローカルネットワーク内の少なくとも１つのノードにアクセスする際にクライアントノードに一連の特権を与えるポリシー情報、又はクライアント情報及びポリシー情報の両方を含むことができる。従って、識別情報及びポリシー情報の一方又は両方によって指定された通りに、データパケットをルーティングすることができる。

ローカルネットワーク（例えばローカルエリアネットワーク）は、セッションリクエストを受信する、クライアント証明書を受信する、クライアント情報を検索する、及び／又は、データパケットをルーティングするエッジルータを有することができる。ローカルネットワークは、その他の複数のノードを含むこともできる。例えば、少なくとも１つのノードは、アプリケーションサーバを含むことができる。

ルーティングによって形成された仮想コネクションは、種々異なるアプローチを使用することができる。例えば、仮想コネクションは、セッションリクエストを受信するローカルネットワークの受信ノードと、ローカルネットワーク内の少なくとも１つのノードと、の間の静的なコネクションを維持することができる。この静的なコネクションは、ローカルネットワーク内にのみ存在している。そのケースにおいては、ルーティングは、クライアントからのデータパケットの、静的なコネクションに沿ったルーティングを含むことができる。従って、そのような実施の形態においては、周知のハンドシェイクプロセスが、セッション中に、クライアントノードと、ローカルネットワーク内の少なくとも１つのノードとの間で実施されることは期待されない。

しかしながら、その他の実施の形態は、上述の静的なコネクションを使用しなくてもよい。例えば、本方法は、証明書を受信する前に、クライアントノードと少なくとも１つのノードとの間の最初のハンドシェイクプロセスを許可することができ、また、認証プロセスによってクライアントノードが認証された場合には、クライアントノードと少なくとも１つのノードとの間の最後のハンドシェイクプロセスの完了を許可することができる。

とりわけ、認証プロセスは、ゲストユーザのためのログインＩＤ及びパスワードを受信することができ、またそのログインＩＤ及びパスワードがローカルネットワーク内のアクセスに対して有効であることを確認することができる。幾つかの実施の形態は、クライアントノードデバイスを識別するクライアントデバイス識別子（例えばクライアントデバイスのＭＡＣアドレス）を求めることができ、また、認証プロセスを実行するためにクライアントデバイス識別子及びクライアント証明書を使用することができる。

別の実施の形態によれば、ネットワークを介して受信したデータをルーティングするためのネットワークルーティングデバイスは、ａ）複数のノードを有しているローカルネットワーク内の少なくとも１つのノードにアクセスするクライアントノードからのセッションリクエスト、及び、ｂ）クライアントノードからのクライアント証明書を受信するためのインタフェースを有している。クライアント証明書は、クライアントノードからパケットを受信する少なくとも１つのノードを指定するクライアント情報を有している。ネットワークルーティングデバイスは、クライアント証明書からクライアント情報を検索し、且つ、クライアント情報を使用して認証プロセスを実行するように構成されており、また、適切に作用するようにインタフェースに接続されている、オーセンティケータも有している。更に、ネットワークルーティングデバイスは、認証プロセスによってクライアントノードが認証されたか否かをオーセンティケータから求めるように構成されており、且つ、適切に作用するようにオーセンティケータに接続されている、ルータも有している。従って、ルータは、クライアントノードが認証された場合には、クライアント証明書におけるクライアント情報によって指定された通りに、データパケットをクライアントノードからローカルネットワーク内の少なくとも１つのノードにルーティングするように構成されている。

更に別の実施の形態によれば、ネットワークを介するデータのルーティング方法は、複数のノードを有しているローカルネットワーク内の少なくとも１つのノードにアクセスするクライアントノードからセッションリクエストを受信し、また、クライアントノードからクライアント証明書を受信する。クライアント証明書は、クライアントノードからパケットを受信する少なくとも１つのノードを指定するクライアント情報を有している。本方法は、クライアント証明書からクライアント情報を検索し、また、クライアント証明書におけるクライアント情報に基づいて、少なくとも１つのノードへの少なくとも制限的なアクセスを容易にする。

本発明の図示の実施の形態は、コンピュータ使用可能の媒体と、その媒体上のコンピュータ可読プログラムコードと、を有しているコンピュータプログラム製品として実現される。コンピュータ可読コードを、従来のプロセスに従ってコンピュータシステムによって読み出して利用することができる。

当業者であれば、以下に簡単に説明している図面と関連させて説明を行う、「図示の実施の形態の説明」の項から、本発明の種々の実施の形態の利点がより十分に明らかになる。

本発明の図示の実施の形態を使用することができる、仮想の従来技術のネットワークを概略的に示す。 本発明の図示の実施の形態によって使用することができる、従来技術のメッセージのフラグメンテーションを概略的に示す。 本発明の図示の実施の形態を実現することができる、一般的な従来技術のインターネットを概略的に示す。 本発明の図示の実施の形態を実現することができる、より特定のタイプのインターネットを概略的に示す。 本発明の図示の実施の形態に従って構成されているエッジルータの種々の部分を概略的に示す。 本発明の図示の実施の形態による、サーバへのアクセスのプロセスを示す。 本発明の図示の実施の形態に従って作成された、ディジタル証明書の一例を示す。 本発明の図示の実施の形態に従って作成された、ディジタル証明書の一例を示す。

図示の実施の形態においては、ネットワークデバイスは、遠方のクライアントから到来するデータメッセージを、クライアントのディジタル証明書内のクライアント固有情報に基づいて局所的にルーティングする。そのために、クライアントのディジタル証明書は、付加的な情報、例えばクライアントの識別子を識別する情報と、ルーティングネットワークデバイスのローカルネットワーク内の特定のデバイスにアクセスする際の、その固有のクライアントのポリシー／許可と、を有している。

従って、クライアントの検証／認証後に、ネットワークデバイスは、クライアントパケットを自身のローカルネットワーク（例えば自身のローカルエリアネットワーク）内で、クライアントディジタル証明書におけるクライアント情報に応じてルーティングする。従って、クライアントは、ディジタル証明書におけるクライアント情報によって指定された通りに、事前に選択されたネットワークデバイスにのみアクセスすることができる。更に、クライアントは、クライアント証明書内のポリシー情報に基づいて、それらの事前に選択されたネットワークデバイスに対する特定の特権だけを有することができる。図示の実施の形態を下記において詳述する。

ネットワーク
図示の実施の形態は、好適には、従来のコンピュータネットワークにおいて実施されている。特に、ネットワークは、少なくとも２つのノードと、ノード間の少なくとも１つのリンクと、を含んでいる。ノードは、（ホスト又はデバイスと称する場合もある）コンピューティングデバイス及びルータを含むことができる。コンピュータには、パーソナルコンピュータ、スマートフォン、テレビジョン・セットトップボックス、現金自動預け払い機（ＡＴＭ）、並びに、プロセッサ及びネットワークインタフェースを含んでいるその他の多くのタイプの装置が含まれる。リンクは、ノードペア間の有線式及び無線式のコネクションを含んでいる。更に、ノード及び／又はリンクを、完全にソフトウェアとして実施することができ、例えば仮想マシン、ソフトウェア定義ネットワーク（ＳＤＮ：Ｓｏｆｔｗａｒｅ Ｄｅｆｉｎｅｄ Ｎｅｔｗｏｒｋ）において、また、ネットワーク機能の仮想化（ＮＦＶ：Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）を使用して実施することができる。多くのネットワークは、スイッチを含んでおり、それらのスイッチの大部分は、この議論に関してトランスペアレント（透過性）である。しかしながら、幾つかのスイッチは、ルーティング機能も実施する。ここでの議論に関して、そのようなルーティングスイッチはルータとみなされる。ルータについては下記において説明する。

ノードを、１つ又は複数のその他のノードと、それぞれ個別のリンクを介して直接的に接続することができる。例えば、図１には、ノードＡがリンク１を介してノードＢに直接的に接続されていることが概略的に示されている。所定のネットワークにおいて（例えば、ローカルエリアネットワーク内では）、各ノードは、データの送信及び受信を容易にするためのユニークなネットワークアドレスを有している。ネットワークは、ネットワークのアドレッシングスキームに従ってネットワーク内でアドレッシング可能な全てのノードと、ネットワークのアドレッシングスキームに従って通信を行うためにノードを相互接続する全てのリンクと、を含んでいる。例えば、図１においては、ノードＡ、ノードＢ、ノードＣ〜ノードＦ及び全てのリンク１〜８が一緒になって１つのネットワーク１００を形成している。簡略化のために、ネットワークを、１つのクラウドとして、又は、１つのクラウド内に含まれるものとして示すことができる。しかしながら、クラウドは存在しないということが、複数のノード及び複数のリンクの集合体はネットワークではないということを意味しているわけではない。例えば、複数の比較的小さいネットワークから１つのネットワークを形成することができる。

各ノードは、ネットワークを介してその他のノードとの通信を開始することができ、また各ノードは、ネットワークを介してその他のノードによって開始された通信を受信することができる。例えば、ノードは、直接的に接続されているノード（隣接ノード）に、その隣接ノードと相互接続されているリンクを介してデータ（メッセージ）を送信することによって、そのデータ（メッセージ）を伝送／転送／送信することができる。メッセージは、送信ノードのネットワークアドレス（「送信元アドレス」）と、意図されている受信ノードのネットワークアドレス（「宛先アドレス」）と、を含んでいる。送信ノードは、メッセージを非隣接ノードに、１つ又は複数のその他の介在ノードを介して送信することができる。例えば、ノードＤは、ノードＦにノードＢを介してメッセージを送信することができる。周知のネットワーキングプロトコルを使用して、送信元ノードと宛先ノードとの間に存在する（１つ又は複数の）ノードは、メッセージがその宛先ノードに到達するまで、メッセージを転送する。従って、適切に動作するために、ネットワークプロトコルは、各ノードによる、そのネットワーク内の非隣接ノードのネットワークアドレスの学習又は発見を実現する。

ノードは、プロトコルに従って、例えば公知のインターネットプロトコル（ＩＰ：Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）及び伝送制御プロトコル（ＴＣＰ：Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）に従って、ネットワークを介して通信を行う。プロトコルは、典型的には、例えば周知の７層オープンシステム接続（ＯＳＩ：Ｏｐｅｎ Ｓｙｓｔｅｍ Ｉｎｔｅｒｃｏｎｎｅｃｔ）モデルに従って、階層化されたソフトウェアコンポーネント及び／又はハードウェアコンポーネントによって実施されている。一例として、ＩＰはＯＳＩのレイヤ３（ネットワーク層）で機能し、その一方、ＴＣＰは大部分がＯＳＩのレイヤ４（トランスポート層）で機能する。各層は、論理的な機能を実施し、また自身より下位の層を抽象化し、従って下位層の詳細を隠す。

例えば、レイヤ３は、レイヤ２（データリンク層）が１つの大きいメッセージを１回の伝送で処理できない場合には、そのメッセージの、複数のより小さいパケットへのフラグメント化を実施することができる。図２には、複数の部分２０２、２０４、２０６、２０８、２１０及び２１２に分割された大きいメッセージ２００が概略的に示されている。この場合、各部分２０２〜２１２を、パケット２１４によって例示されている個別のパケットとして送信することができる。各パケットは、ペイロード２１６によって例示されているペイロード（本体）部分と、参照番号２１８によって例示されているヘッダ部分と、を含んでいる。ヘッダ部分２１８は、（１）パケットのその宛先へのルーティング、（２）メッセージのパケットの再組み立て、及び、（３）プロトコルに従って提供されるその他の機能、のために必要とされる又は望まれる情報、例えばパケットの送信元アドレス、宛先アドレス及びパケットシーケンス番号を含んでいる。幾つかのケースにおいては、例えばペイロード又はパケット全体のチェックサムを実施するために、ペイロードにトレーラ部分も付加されている。メッセージの全てのパケットが同一の経路に沿って送信される必要はない。つまり、それらのパケットの共通の宛先への経路において同一のノードを通過する必要はない。ＩＰパケットは、正式にはＩＰデータグラムと称されるが、それらは一般的には単純にパケットと称されていることを言及しておく。

その他の幾つかのプロトコルも、データの複数のパケットへのフラグメント化を実施する。例えば、ＴＣＰは、データの複数のセグメントへのフラグメント化を実施する。セグメントは、正式には、ＴＣＰプロトコルデータユニット（ＰＤＵ：Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）と称される。それにもかかわらず、一般的には、ＰＤＵ及びデータグラムを表す際に、またイーサネットフレームを表す際にパケットという用語が用いられている。

プロトコルの多くは、上位の階層のプロトコルのパケットのカプセル化を実施する。例えば、ＩＰは、ＩＰパケットを生成するために、ＴＣＰパケットにＩＰヘッダを付加することによって、ＴＣＰパケットのカプセル化を実施する。従って、下位の階層において送信されたパケットは、パケット内のパケットから成るものであると考えられる。通常の場合、あるプロトコルに従って動作するコンポーネントは、同一のプロトコルに従って動作する別のコンポーネント、典型的には別のノード内の別のコンポーネントによって生成されたヘッダ及び／又はトレーラ内の情報しか検査又は変更しない。つまり、一般的には、あるプロトコルに従って動作するコンポーネントは、その他のプロトコルによって生成されたパケットの部分を検査又は変更しない。

階層プロトコルによって提供される抽象化の別の例では、幾つかの層がアドレスを変換する。幾つかの層は、層固有のアドレッシングスキームを含んでいる。例えば、リンクの各端部は、実際の（例えば電子的な）インタフェース又は仮想のインタフェース、例えばイーサネットインタフェースを介してノードに接続されている。レイヤ２（データリンク層）では、各インタフェースがアドレスを、例えばメディアアクセスコントロール（ＭＡＣ：Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスを有している。その一方で、ＩＰを使用するレイヤ３では、各インタフェースが、又は少なくとも各ノードがＩＰアドレスを有している。レイヤ３は、ＩＰアドレスをＭＡＣアドレスに変換する。

典型的に、ルータは２つ又はそれ以上の個別のネットワーク、若しくは、単一のネットワークの２つ又はそれ以上のサブネットワーク（サブネット）を相互接続するノードとして機能する。これによって、「複数のネットワークから成る１つのネットワーク」（即ち、１つのインターネット）が形成される。従って、ルータは、少なくとも２つのインタフェースを有しており、各インタフェースは、図３に例示されているように、ルータを異なるネットワークに接続する。ルータは、一方のインタフェースを介して一方のネットワークからパケットを受信すると、自身のルーティングテーブルに記憶されている情報を使用して、そのパケットを他方のインタフェースを介して他方のネットワークに向ける。ルーティングテーブルは、ネットワークとネクストホップとの関連性を含んでいる。それらの関連性は、最終的な宛先への経路上のネクストホップを表している特定のルータにパケットを送信することによって、特定の宛先に最適に到達できることをルータに知らせる。例えば、第１のルータ３００が自身の第１のインタフェース３０４を介して、第１のネットワーク３０２からパケットを受信し、且つ、そのパケットの宛先が第３のネットワーク３０６内のあるノードに指定されている場合には、第１のルータ３００は、自身のルーティングテーブルを参照して、自身の第２のインタフェース３０８を介して第２のネットワーク３１０にパケットを転送する。続けて、第２のネットワーク３１０は、パケットを第３のネットワーク３０６に転送する。ネクストホップの関連性を、最終的な宛先への出力（出口）インタフェースとしてルーティングテーブルに示すこともできる。

大規模な組織、例えば大企業、商用データセンタ及び電気通信事業者は、内部トラフィックの送信のために、階層構造のルータのセットを使用することが多い。例えば、１つ又は複数のゲートウェイルータによって、各組織のネットワークと、１つ又は複数のインターネットサービスプロバイダ（ＩＳＰ：Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）と、を相互接続することができる。またＩＳＰは、自身の顧客のゲートウェイ間のトラフィックの送信のために階層構造のルータを使用して、その他のＩＳＰとの相互接続及びインターネットバックボーンにおけるコアルータとの相互接続を実現する。

ルータは、その主たる転送の判断に関して、レイヤ３ＩＰパケットにおける情報、特に宛先ＩＰアドレスを基礎としているので、レイヤ３デバイスとみなされる。従来のルータは、パケットが運ぶ実際のデータコンテンツ（即ち、カプセル化されたペイロード）を参照しない。その代わりにルータは、単に、転送の判断を行うためのレイヤ３アドレスと、オプションとして、サービス品質（ＱｏＳ：Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）要求のようなヒントに関するヘッダにおけるその他の情報と、だけを見る。パケットが転送されると、従来のルータは、パケットに関する履歴情報を保持しない。しかしながら、ルータがそのように構成されている場合であっても、統計的なデータを生成するために転送活動を収集することはできる。

従って、ＩＰネットワークは、特にこの履歴情報を保持しないことから、「ステートレスな」ネットワークとみなされる。例えば、ＩＰネットワークは一般的に、各リクエストを、以前のいずれのリクエストにも関係しない独立したトランザクションとして処理する。従って、ルータは、先行のパケットをどのように処理したかを顧みずに、パケットをルーティングすることができる。例えば、ＩＰネットワークは、典型的に、新規に加わった通信パートナの状態又はセッション情報を記憶しない。例えば、ネットワークの一部が使用できない中間トランザクションになった場合には、リソースを再割り当てする必要はないか、又は、さもなければ、ネットワークの状態を固定する必要はない。その代わりに、パケットをネットワーク内のその他のノードに沿ってルーティングすることができる。

上記において述べたように、ルータは、一方のインタフェースを介して一方のネットワークからパケットを受信すると、自身のルーティングテーブルを使用して、そのパケットを他方のネットワークに向ける。表１には、基本的なＩＰルーティングテーブルから一般的に見て取れる情報が列挙されている。

ルーティングテーブルを、例えばシステム管理者によって手動で埋めることができるか、又は、ルータによって動的に埋めることができる。ルータは、その他のルータと情報を交換するためにルーティングプロトコルを使用し、またそれによって、周囲のネットワーク又はインターネットのトポロジを動的に学習する。例えば、ルータは、自身の存在を（１つ又は複数の）ネットワークに通知する。より詳細には、ルータは、自身がパケットを転送できるＩＰアドレスの範囲をネットワークに通知する。隣接するルータは、その情報を用いて自身のルーティングテーブルを更新し、また第１のルータの（１つ又は複数のネットワーク）へとパケットを転送する自身の能力をブロードキャストする。この情報は、必要に応じて、ネットワーク内のより遠隔のルータに拡散される。動的なルーティングによって、ルータは、ネットワーク又はインターネット内の変化に、例えば増大したネットワークの輻輳、新たなルータのインターネットへの追加、及び、ルータ又はリンクのエラーに反応することができる。

従って、ルーティングテーブルは、パケットを各宛先へとルーティングするための一連の規則を提供する。パケットが到着すると、ルータは、パケットの内容を検査し、例えばそのパケットの宛先アドレスを検査し、ルーティングテーブルにおける最適な規則を発見する。その規則は、事実上、パケットを転送するためにどのインタフェースが使用されるかをルータに知らせ、またそのパケットの最終的な宛先ＩＰアドレスへの経路上においてそのパケットが転送されるノードのＩＰアドレスも知らせる。

ホップ・バイ・ホップ方式のルーティングでは、各ルーティングテーブルには、到達可能な全ての宛先に関して、その宛先への経路に沿った次ノード、即ちネクストホップのアドレスが記載されている。ルーティングテーブルに矛盾がない場合を想定すれば、ネットワーク内のいずれかの場所にパケットを送信するには、パケットをその宛先の各ネクストホップへとリレーする各ルータの単純なアルゴリズムで十分である。ホップ・バイ・ホップ方式は、ＩＰインターネットワーク層及びＯＳＩネットワーク層の基本的な特性を表している。

従って、各ルータのルーティングテーブルは、通常の場合、パケットを、そのパケットの宛先の「比較的近くに位置する」別のルータに転送するのに十分な情報しか含んでいないので、パケットが常にその宛先へと送信されることは保証していない。ある意味において、少なくとも大部分のパケットが最終的にその宛先へと到達することを目的として、パケットは、一連のルータを辿って、各ルータにおいてその時点での最新の規則を使用して、次にどのルータを辿るかを決定することによって、自身の宛先までの自身の経路を発見している。

例えば、ルータが輻輳した場合、又は、リンクに障害が発生した場合、規則は１つのパケットの連続する２つのホップ間で、又は、１つのメッセージの連続する２つのパケット間で変化する可能性があることを言及しておく。従って、１つのメッセージの２つのパケットが異なる経路を辿る可能性があり、それどころか順番通りに到着しない可能性がある。換言すれば、パケットが送信元ノード又は起源ノードから送信される場合には、ネットワークがステートレスであることから、送信元ノードとパケットの宛先ノードとの間でパケットが取ることになる、事前に規定された経路は一般的に存在しない。その代わりに、典型的には、パケットが種々のルータを通過するときに、経路が動的に求められる。これは「自然なルーティング」と称することができる。つまり、パケットがインターネットを通過するときに、経路が動的に求められる。

自然なルーティングが長年にわたり上手く機能しているにもかかわらず、この自然なルーティングは欠点を有している。例えば、１つのセッションの各パケットが異なる経路に沿って伝播する可能性があり、また異なるルータのセットを通過する可能性があるので、セッションに関するメトリックを収集することは困難である。セッションのパケットに適用することができるセキュリティ機能を広範囲にわたり分散させなければならず、また、そのようなセキュリティ機能が全てのパケットに適用されないリスクも考えられる。更に、セッションへの攻撃が多くの場所から開始される可能性がある。

通常の場合、宛先ノードから再び送信元ノードへと送信されるパケットは、送信元ノードから宛先ノードへと送信されたパケットとは異なる経路を辿る可能性があることを言及しておく。

多くの状況において、クライアントコンピュータノード（「クライアント」）は、サーバコンピュータノード（「サーバ」）とセッションを確立し、またクライアントとサーバは、そのセッション内でパケットを交換する。例えば、ブラウザを実行しているクライアントは、従来のプロセスを使用して、ウェブサーバとのセッションを確立することができる。クライアントは、ウェブページをリクエストするために１つ又は複数のパケットを送信することができ、またウェブサーバは、ウェブページのコンテンツを含んでいる１つ又は複数のパケットでもって応答することができる。幾つかのタイプのセッションでは、パケットの往復的な交換を複数回のサイクルにわたり継続することができる。幾つかのタイプのセッションでは、パケットを２つのノード間で非同期的に送信することができる。下記において説明するように、周知のプロトコル、例えばセキュア・ソケット・レイヤ・プロトコル（「ＳＳＬ」：Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ Ｐｒｏｔｏｃｏｌ）又はトランスポート・レイヤ・セキュリティ・プロトコル（「ＴＬＳ」：Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ Ｐｒｏｔｏｃｏｌ）を使用して、インターネットを介するセキュアなセッションを提供するために、このハンドシェイクを実施することができる。

セッションは、その通常の意味を有している。つまり、セッションとは、プロトコルに従って一方のノードから他方のノードへと送信される、各パケットが関連付けられている複数のパケットである。セッションは、そのセッションを開始する先行パケット（又は最初のパケット）と、そのセッションの１つ又は複数の後続パケットと、を含むものと考えられる。セッションには、明確な開始及び明確な終了が存在する。例えば、ＴＣＰセッションは、ＳＹＮパケットによって開始される。幾つかのケースにおいては、１つの所定のパケット又は一連のパケットによって、終了を規定することができる。例えば、ＴＣＰセッションを、ＦＩＮ交換によって又はＲＳＴによって終了させることができる。その他のケースにおいては、少なくとも事前に規定された長さの時間（タイムアウト時間）にわたり、ノード間で通信が行われないことによって終了を規定することができる。例えば、ＴＣＰセッションを、所定のタイムアウト期間後に終了させることができる。幾つかのセッションは、一方のノードから他方のノードへと送信されるパケットしか含んでいない。その他のセッションは、ウェブクライアントとサーバとのインタラクションの例のように、応答パケットを含んでいる。１つのセッションは、プロトコルに従った、何サイクルもの往復的な通信又は非同期的な通信を含むことができるが、しかしながら、１つのセッションの全てのパケットは、ノードの同一のクライアントとサーバのペア間で交換される。ここでは、セッションを一連のパケット（パケットシリーズ）とも称する。

単一ＩＰアドレスを有しているコンピュータは、種々のサービス、例えばＷｅｂサービス、Ｅメールサービス及びファイル転送（ＦＴＰ：Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）サービスを提供することができる。一般的に、各サービスには、コンピュータ上でユニークである、０〜６５，５３５の範囲のポート番号が割り当てられている。従って、サービスは、ノードのＩＰアドレスとサービスのポート番号との組み合わせによって規定されている。この組み合わせは、コンピュータが接続されているネットワーク内でユニークであり、またインターネット内でもユニークであることが多いことを言及しておく。同様に、単一のノードにおいて多数のクライアントを実行することができる。従って、サービスをリクエストするクライアントには、そのクライアントのノードにおけるユニークなポート番号が割り当てられているので、サービスからの戻りパケットを、リクエストを行ったクライアント宛てに一意に送ることができる。

ソケットという用語は、ＩＰアドレスとポート番号との組み合わせを意味している。従って、各サービスは、ネットワーク固有の、またインターネット固有であることも多いサービスソケットを有しており、サービスをリクエストするクライアントには、ネットワーク固有の、またインターネット固有である場合もあるクライアントソケットが割り当てられている。ところによっては、送信元クライアント及び宛先サービスという用語は、サービスをリクエストするためにパケットを送信するクライアント及びリクエストされているサービスをそれぞれ表す際に使用される。

ネットワークのセキュリティ及び制御
上記において述べたように、ハッカーは、ネットワーク内のノードへの承認されていないアクセスを得ることを頻繁に試みている。実際のところ、ハッカーの中にはネットワークに正当にアクセスする者もおり、そのようなハッカーは、故意にアクセスする場合よりもネットワークデバイスの操作に関してより高い自主性を有している。そのような認証されたケースは、破局的な結果をもたらす虞がある。図４には、ハッカーがローカルネットワーク内のノードへのアクセスを得ることを試みる可能性がある、より特定のタイプのネットワークが概略的に示されている。図示されているように、ネットワークは、クライアントノード／デバイス４００（単純に「クライアント４００」と表されている）、例えばクライアントコンピュータを含んでおり、このクライアント４００は、インターネット４０４を介してローカルネットワーク内の複数のアプリケーションサーバ（全体として「アプリケーションサーバ４０２」と表されている）のうちの１つにアクセスすることを試みる。例示を目的として、ローカルネットワークは、従来のデータセンタ内のローカルエリアネットワークである。勿論、当業者であれば、データセンタ及びアプリケーションサーバ４０２についての考察は単なる例であって、その他のトポロジ又はその他のネットワーク装置が本発明の図示の実施の形態を実践できることが分かる。

従って、ローカルネットワーク又はこの例ではデータセンタは、上述の複数のアプリケーションサーバ４０２を有しており、それらのアプリケーションサーバ４０２により、遠方のノード／ネットワークデバイスに、例えばクライアント４００に情報が提供される。この例では、データセンタは、「Ｎ」個のアプリケーションサーバ４０２を有しており、この数Ｎは、数ダース、数百又は数千の実際の及び／又は仮想のサーバを表すことができる。とりわけ、アプリケーションサーバ４０２は、種々の小売店、インターネットサービス、ソーシャルメディアサイト、アプリケーションサービスプロバイダ等のためのウェブサーバとして機能することができる。

この実施の形態におけるデータセンタは、遠方のノード（例えばクライアント４００）とデータセンタ内のノードとの間でデータを受信及び転送するための１つ又は複数のエッジノード（この例においては「エッジルータ４０６」と表されている）を有するように構成されている。換言すれば、エッジルータ４０６は、ローカルネットワークと、インターネット４０４又はその他の（例えばワイドエリアネットワークを形成している）近接ネットワークにおける遠方のデバイスと、の間のデータトラフィックを管理する。

そのために、ローカルネットワークは、データセンタ内のネットワークトラフィックを受信及び転送するための複数の付加的なノード／ネットワークデバイス、例えばルータ及びスイッチ（ここでは全体として「ルータ４０８」と表されている）も有している。図示の実施の形態においては、エッジルータ４０６及びその他のローカルネットワークルータ４０８は、レイヤ３プロトコルを使用して、例えばＩＰプロトコルを使用して、パケットを、エッジルータ４０６及びアプリケーションサーバ４０２に伝送するか、又は、エッジルータ４０６及びアプリケーションサーバ４０２から受信する。エッジルータ４０６は、インターネット４０４及びそのインターネットサービスプロバイダ（ＩＳＰ）との直接的で物理的なリンクを有していることも多いが、幾つかの実施の形態では、エッジルータ４０６とインターネット４０４との間に、その他のデバイスが物理的に配置されている場合もあることを言及しておく。

図５には、エッジルータ４０６と、ネットワークへのトラフィック及びネットワークからのトラフィックを管理するための、エッジルータ４０６の幾つかの内部コンポーネントと、が概略的に示されている。図示されているように、エッジルータ４０６は、その他のネットワークデバイス、例えば自身が属するデータセンタ内のルータ４０８及び自身が属するローカルネットワーク外のデバイス、例えばインターネット４０４上のデバイス（例えばクライアント４００）に接続するためのインタフェース５００を有している。インタフェース５００は、データパケットの受信又は伝送のため、若しくは受信及び伝送の両方のための、１つ又は複数の物理的な又は仮想のインタフェースを含むことができる。

相応にして、エッジルータ４０６は、本発明の種々の実施の形態によって規定された上述のやり方で、データパケットをルーティングするための、ローカルルーティング装置（ここでは単に「ルータ５０２」と表されている）も有している。特に、下記において図６を参照しながらより詳細に説明するように、ルータ５０２は、クライアントのディジタル証明書内に存在しているクライアント情報に依存して、データパケットのルーティングを制御する。実際には、下記において説明するように、種々の実施の形態は、クライアント４００が適切に認証されない限りは、クライアントデータパケットをルーティングしない。従って、エッジルータ４０６は、クライアント４００の識別子を検証するためのオーセンティケータ５０４も有している。図示の実施の形態は、当業者には公知の種々のやり方のうちのいずれかによって、例えばハードウェア、ソフトウェア、ファームウェア又は当業者には公知のその他の手段として、ルータ５０２、オーセンティケータ５０４及び（１つ又は複数の）インタフェース５００を実現することができる。勿論、それらの実現形態は、それらの所望の機能に一致すべきである。それらの実施については、下記において図６を参照しながら説明する。

それらの各エッジルータコンポーネントを、当業者にとって適切であると考えられる種々のやり方のうちのいずれかによって、相互に接続することができる。図５には、そのようなコネクションが、参照番号５０６が付されている単純なバスとして概略的に示されている。勿論、当業者であれば、エッジルータ４０６の種々の実施の形態が、同様のバス設計に限定されるものではないことが分かる。

上記において述べたように、ハッカーは、データセンタ内のアプリケーションサーバ４０２へのアクセスを試みる可能性がある。それらのハッカーによるアクセスの試みは、ローカルネットワークの外側から開始されるか、又は（例えばゲストアクセスを使用して、例えばログインＩＤ及びパスワードを使用して）ネットワーク内から開始されると考えられる。上記において述べたように、ハッカーの中には、アプリケーションサーバ４０２へのセキュアコネクションを実現する特権を、合法に又は違法に取得できる者もおり、それによって、アプリケーションサーバ４０２が悪用される。ロバストなセキュリティ対策が採られていなければ、そのようなハッカーは、重大な問題を引き起こす可能性がある。図示の実施の形態は、複数あるアプリケーションサーバ４０２のうちのいずれかへのアクセスを試みる認証されたクライアント４００に対して、更に制限を課すことによって、そのようなリスクを緩和する。そのために、図６には、本発明の図示の実施の形態による、そのようなセキュリティ対策を提供するプロセスが示されている。このプロセスは、（１つ又は複数の）サーバにアクセスするために通常使用される、より長いプロセスに比べて大幅に簡略化されている。従って、このプロセスは、当業者が使用する見込みが高いその他のステップを、例えば更なる検証ステップを含むことができる。更に、幾つかのステップを、図示されている順序とは異なる順序で実施することができるか、又は、同時に実施することができる。従って、当業者であれば、このプロセスを適宜変更することができる。

図６は、周知のトランスポート・レイヤ・セキュリティ（「ＴＬＳ」）プロトコルを使用する種々の実施の形態を説明するものである。実際のところ、図６のプロセスは、今日使用されているＴＬＳハンドシェイク相互認証プロセスの大部分と広範にわたり協働する。勿論、当業者であれば、ＴＬＳについての考察は単なる例であって、本発明の全ての実施の形態を制限することを意図するものではないことが分かる。従って、図示の実施の形態は、ネットワークを介する、例えばインターネット４０４を介するセキュアコネクションを提供するように構成されている、その他の公知のセキュリティプロトコル及び暗号化プロトコルに適用される。

プロセスは、ステップ６００において開始され、このステップ６００では、エッジルータ４０６が周知の「Ｈｅｌｌｏ」メッセージをクライアント４００から受信する。従って、このメッセージには、種々のデータが付随しており、例えばＳＳＬのヴァージョン、サポートしている暗号、セッション固有のデータ等が付随している。エッジルータ４０６は、自身の固有の「Ｈｅｌｌｏ」メッセージでクライアント４００に応答し、類似のデータをクライアント４００に送信する（ステップ６０２）。例えば、クライアント４００へのＳＳＬのヴァージョン、サポートしている暗号、セッション固有のデータ等に加えて、このＨｅｌｌｏメッセージは、サーバ証明書、（クライアント証明書を実際に要求する）相互認証リクエストも含んでおり、またオプションとして鍵交換も含んでいる。この時点において、認証が開始され、従って、最初のハンドシェイクプロセスとみなせるプロセスが完了する。

エッジルータ４０６からＨｅｌｌｏメッセージを受信すると、クライアント４００は、より多くのデータを、例えばクライアント証明書をエッジルータ４０６に転送する（ステップ６０４）。ＴＬＳによって規定されているように、このクライアント証明書は、好適には先ず「クリアな」フォーマットで送信される（即ち暗号化は行われない）。プロセスのこの時点において、エッジルータ４０６は、クライアント証明書が最初に認証／検証されたと判断することができる。認証／検証された場合、認証プロセスが継続される。認証／検証されなかった場合、クライアント４００からの全ての伝送をブロックすることによって、プロセスを終了することができる。

この時点において検証が行われる場合、オーセンティケータ５０４は、ＴＬＳによって規定されているような従来のやり方で、ハンドシェイクプロセスを継続する。例えば、クライアント鍵交換（セッションに関するプリマスタシークレット（ｐｒｅｍａｓｔｅｒ ｓｅｃｒｅｔ）、サーバ公開鍵によって暗号化されている）の後に、続いてクライアント４００は、自身のクライアント証明書検証（「ＣＣＶ」：Ｃｌｉｅｎｔ Ｃｅｒｔｉｆｉｃａｔｅ Ｖｅｒｉｆｙ）メッセージを送信し、エッジルータ４０６に対して、クライアント４００がクライアント証明書における公開鍵に対応する秘密鍵を所有していることを証明することができる。そのために、クライアント４００は、クライアントのＨｅｌｌｏメッセージからＣＣＶメッセージまでの間に、２つのデバイス間で送信又は受信された全てのＴＬＳハンドシェイクメッセージ（但しＣＣＶメッセージは除く）のハッシングによってＣＣＶメッセージを生成する。

エッジルータ４０６は、Ｈｅｌｌｏメッセージの同一のセットに対してハッシュを再計算するために、公開鍵を使用してＣＣＶメッセージの署名を検証する。当業者には公知のように、このことは、秘密鍵が、対応する公開鍵を用いて検証することができる署名を生成することができる唯一の鍵であることから実現可能である。

プロセスのこの時点において、クライアント４００からのデータパケットは、エッジルータ４０６を通過せず、それゆえ、ローカルネットワーク内のその他のいずれかのデバイス又はノードに向かっていない。このケースにおいては、エッジルータ４０６は、好適には、このクライアント４００からの全てのパケットについての中継局として機能する。例えば、エッジルータ４０６は、（１つ又は複数の）アプリケーションサーバ４０２との静的なＴＬＳコネクションを有することができる。それによって、指定された通りに認証及びルーティングが行われるまでは、いずれのデータパケットもＴＬＳコネクションを介してアプリケーションサーバ４０２に到達することはできない。

しかしながら、その他の実施の形態では、クライアント４００から１つ又は複数の限定的なパケットを、例えばＨｅｌｌｏメッセージを転送することができる。このことは、勿論、認証プロセスのフローに依存する。例えば、クリアなクライアント証明書を受信すると、エッジルータ４０６は、先ずクライアント証明書を検証することができ（例えば、とりわけ署名を確認することができ）、またＨｅｌｌｏメッセージを複数あるアプリケーションサーバ４０２のうちの１つ又は複数へと伝送することができる。この実施の形態においては、それにもかかわらず、エッジルータ４０６は、最終的な検証認証ステップが終了するまで（例えば鍵交換及びクライアント証明書検証プロセス後まで）は、クライアント４００からの相当数のデータパケットをルーティングしない。

認証プロセスが完了すると、最終的なハンドシェイクプロセスを終了することができる。特に、プロセスは、オーセンティケータ５０４がクライアント４００を認証したか否かを確認する（ステップ６０６）。オーセンティケータ５０４がクライアント４００を認証できなかった場合には、このセッションにおいて、エッジルータ４０６は、後続のデータパケットがこのエッジルータ４０６のインタフェース５００を介して、データセンタ内のその他のいずれかのデバイスへと伝送されることをブロックする（ステップ６０８）。

それとは異なり、オーセンティケータ５０４によるクライアント４００の認証が成功した場合には、プロセスはステップ６１０及び６１２に進み継続される。特に、ステップ６１０においては、エッジルータ４０６が、クライアント証明書における情報を使用してクライアントデータパケットをルーティングし、またステップ６１２においては、受信ノード／アプリケーションサーバ４０２が、クライアント証明書に由来するポリシーを適切に適用する。

特に、セッションのリクエストに先行して、ローカルネットワークに関連付けられたエンティティは、認証局と共に、クライアント証明書をクライアント４００に対して発行する。図７Ａ及び図７Ｂには、本発明の図示の実施の形態に従い構成されているクライアント証明書の一例が概略的に示されている。証明書は、必須の標準、例えば広範に使用されているＸ．５０９標準に準拠する、従来の証明書における情報と大部分が同一の周知の情報を有している。例えば、証明書はとりわけ、ヴァージョン番号、シリアル番号、アルゴリズムＩＤ、発行者名、有効期限及びサブジェクト（主体者）公開鍵情報を有している。

しかしながら、それらの目的のために使用されるその他の証明書とは異なり、このクライアント証明書は、ローカルネットワーク内でクライアントデータパケットをルーティングするための付加的なクライアント情報も含んでいる。特に、図７Ａに示されているように、クライアント証明書は、クライアント４００及びクライアント４００の制御について認証された人間の詳細を識別するサブジェクト行（ｓｕｂｊｅｃｔ ｌｉｎｅ）を有している。図７Ａではサブジェクト行に明示的に下線を引いているが、多くの実施の形態では、この情報に下線が引かれることは求められないことを言及しておく。その代わりに、図７Ａでは単に強調を目的として、この行に下線が引かれている。図７Ｂにおいても同様に、単に強調を目的として、テキスト（ポリシー情報、下記において説明する）に下線が引かれている。

とりわけ、この例におけるサブジェクト行は、クライアント４００の国、州及びオフィス名、並びに、特定のユーザの職務上の所属部署、氏名及びＥメールアドレスを含んでいる。このケースにおいては、ユーザは、Ｊｏｈｎ Ｓｍｉｔｈであり、Ｅメールアドレスｓｍｉｔｈ＠１２８ｔｅｃｈｎｏｌｏｇｙ．ｃｏｍを有している。Ｓｍｉｔｈ氏は、アメリカ合衆国のマサチューセッツにある１２８Ｔｅｃｈｎｏｌｏｇｙのオフィスに在籍しており、また、技術部（Ｅｎｇｉｎｅｅｒｉｎｇ Ｄｅｐａｒｔｍｅｎｔ）に所属している。ここでは、このサブジェクト情報を「識別情報」と表すことができ、この情報によって、クライアントノード４００及びこのクライアントノード４００の使用について認証された人間が識別される。確かに、当業者であれば、より多くの識別情報又はより少ない識別情報、若しくは異なる情報を含ませることができる。例えば、識別情報は、付加的又は択一的に、都市情報又は市町村情報、郵便番号情報、電話情報、２人以上の人間の情報、２個所以上のオフィス又は部署、クライアントデバイスの種類（例えばタブレット、パーソナルコンピュータ、ルータ等）、若しくは、特定の用途にとって有用なその他の種類の情報を含むことができる。

ステップ６１０は、好適には、ローカルネットワーク内でクライアントパケットをルーティングするために、この識別情報を使用する。例えば、この識別情報プロファイルを有しているクライアント４００は、アプリケーションサーバ２にのみアクセスすることができ、従って、ローカルネットワーク内のその他のアプリケーションサーバ４０２にはアクセスできない。従って、エッジルータ４０６のルータ５０２は、クライアント４００からのデータパケットをアプリケーションサーバ２に転送／ルーティングするが、その他のアプリケーションサーバ４０２には転送／ルーティングしない。別の例として、この識別情報プロファイルを有しているクライアント４００は、アプリケーションサーバ１及びアプリケーションサーバ２にのみアクセスすることができるか、又は、ローカルネットワーク内の１つのアプリケーションサーバを除いた全てのアプリケーションサーバ４０２にアクセスすることができる。更に別の例として、クライアント４００は、ネットワーク上の全てのアプリケーションサーバ４０２にアクセスすることができる。

クライアント４００に対して許可されるアクセスは自由裁量である。例えば、データセンタは、数百、数千又は数百万のクライアント４００と、アクセスについての合意を別個に結ぶことができる。ネットワーク管理者又はその他の類似の権限者は、特定の各クライアント４００に対してアクセスルーティングを適用するためにエッジルータ４０６をプログラムすることができる。

図示の実施の形態においては、クライアント証明書は、仮想の又は実際のデバイスに固有のものである。従って、この例では、単一のユーザが、そのユーザがセッションを開始するために使用するマシンに依存して、異なるアプリケーションサーバ４０２に対する異なるアクセス権を有することができる。Ｊｏｈｎ Ｓｍｉｔｈ氏は、例えば、自身のラップトップコンピュータを使用する場合には、ローカルネットワーク内の１つのアプリケーションサーバ４０２（例えばアプリケーションサーバ１）に対するアクセス権を有することができ、また、自身のデスクトップコンピュータを使用する場合には、ローカルネットワーク内の別のアプリケーションサーバ４０２（例えばアプリケーションサーバ２）に対する別のアクセス権を有することができる。しかしながら、その他の実施の形態では、そのようなことは要求されない。

証明書は、別の機能性に関する、又は、上記のルーティング機能性及び／又は検証機能性を強化するための、その他の種類のクライアント情報も有することができる。このケースにおいては、クライアント証明書は、クライアント４００がローカルネットワーク内の（１つ又は複数の）ノードにアクセスする際に所定の一連の特権を有することを許可するポリシー情報も有している。特に、この例において、図７Ｂには、このポリシー情報が「Ｘ．５０９ｖ３ Ｃｅｒｔｉｆｉｃａｔｅ Ｐｏｌｉｃｉｅｓ」と表されており、また、複数のポリシーが、つまりＰｏｌｉｃｙ：１．２．３．４．５及びＰｏｌｉｃｙ：１．２．３．４．６が挙げられている。

ローカルネットワーク内のロジック（例えばアプリケーションサーバ４０２）は、それらの列挙されたポリシーを、クライアント４００に対する特定の権限に変換する。それらのポリシーを任意のやり方で強制／実現することができる。特に、幾つかの実施の形態においては、ポリシーは、（認証後に）最初のデータパケットと共にアプリケーションサーバ４０２に転送される。従って、受信アプリケーションサーバ４０２におけるロジックは、所定のクライアント４００に関するポリシーを読み出して実現する。

当業者であれば、広範な種々の使用に関して、証明書のポリシー行を使用することができる。例えば、第１のポリシーは、このクライアント４００がアプリケーションサーバ１の技術部セクションにのみアクセスできることを指定することができ、またその一方で、第２のポリシーは、このクライアント４００が１２８Ｔｅｃｈｎｏｌｏｇｙの顧客のただ１つのセットの技術部にアクセスできることを指定することができる。

別の例として、アプリケーションサーバ４０２は、大規模な食品雑貨店チェーンであってよく、またクライアント４００は、食品雑貨店チェーンにサービスを提供する製品納入業者であってよい。そのようなケースでは、第１のポリシーは、製品納入業者がそのアプリケーションサーバ４０２の製品セクションにのみアクセスできることを指定することができ、またその一方で、第２のポリシーは、この特定のクライアント４００が計画されている製品販売に関するデータにのみアクセスできることを表すことができる。従って、このクライアント４００は、食品雑貨店のその他の製品納入業者に関する納入業者データ、顧客リスト、食品雑貨店チェーンの内部会計部門情報等にアクセスすることはできない。更なる権限は見込まれない又は許可されない。当業者であれば、広範な多岐にわたる許可／ポリシーのうちのいずれかを指定することができ、従って、上記に挙げた許可／ポリシーは、単に種々の実施の形態の一例に過ぎない。ネットワーク管理者又はローカルネットワーク内のその他の権限者は、必要に応じてポリシーを設定、変更及び終了することができる。更に、証明書は、２つより少ない数（例えば０又は１）のポリシーを有することができるか、又は、必要であれば３つ以上のポリシーを有することもできる。

代替的な実施の形態においては、オーセンティケータ５０４は、認証プロセスの一部としてクライアント情報を使用する典型的な認証プロセスとは異なる認証プロセスを実施することができる。同様に、幾つかの実施の形態は、識別情報及びポリシー情報の両情報を使用して、エッジルータ４０６はクライアント４００のデータパケットをどこにルーティングすべきかを指定することができる。例えば、ポリシー情報は、午前８時から午後５時までの間は、アプリケーションサーバ１がクライアント４００からパケットを受信でき、その他の時間では、アプリケーションサーバ２がクライアント４００からパケットを受信できることを指定することができる。

更に幾つかの実施の形態は、ポリシー情報のみを使用して、アプリケーションサーバ４０２にデータをルーティングすることができる。即ち、ポリシー情報は、固有にルーティング情報を有することができる。例えば、第１のポリシーは、まさにこのクライアント４００がアクセスすることができるアプリケーションサーバ４０２を、例えばアプリケーションサーバ１を精確に指定することができる。

当業者であれば、このルーティング及びポリシーの適用は、ネットワークレベルで行われることが分かる。種々の実施の形態は、更に、より高いレベル（例えばアプリケーションレベル）のセキュリティ対策を、例えばプロセスの幾つかの時点におけるアクセスに対するログイン識別子及びパスワードの要求をより一層維持する。しかしながら、その他の実施の形態では、そのようなステップは要求されない。

クライアント証明書を、種々の従来のやり方のうちのいずれかによってインストールすることができる。例えば、クライアント証明書を、コンフィギュレーションプロファイル及びｉＯＳデバイスのモバイルデバイス管理（ＭＤＭ：Ｍｏｂｉｌｅ Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ）能力を使用して、無線通信を経由して、ｉＯＳデバイスにインストールすることができる。更に、クライアント証明書を、Ｅメールの添付ファイルとして、証明書のＰＫＣＳ１２ヴァージョンを送信することによって、ｉＯＳデバイスにインストールすることができる。クライアント証明書を、Ｅメールの添付ファイルとして、クライアント証明書のＰＫＣＳ１２ヴァージョンを送信することによって、又は、アンドロイド固有のモバイル管理製品を介して、手動でアンドロイドデバイスにインストールすることができる。確かに、図面にはそれらのインストール方法が示されているが、種々の実施の形態を制限することは意図されていない。当業者であれば、クライアント証明書をインストールするためにその他の方法を使用することができる。

ローカルネットワークは、ローカルネットワーク内のノードへのアクセスが試みられる度に、ログを取ることができる。従って、システムは、ステートフルな情報を維持することができる。つまり、システムは、全ての試み、識別子及びその他の関連するデータを記録することができる。このシステムは、上記において参照した、本願に組み込まれる特許明細書に記載されているような、ステートレスなパケットを基礎とするシステムにおいて状態情報を使用するシステムと共に使用される場合には、特に効果的である。従って、それらのシステムを、ローカルネットワークをより効果的に維持し、またネットワークアクセスを制御するために、図示の実施の形態と統合することができる。

図示の実施の形態は、ゲストインタフェース（「ゲストユーザ」）を介してローカルネットワークにアクセスするデバイス／ユーザにも適用される。特に、多くのゲストインタフェースには、有線又は無線のコネクションを使用してローカルネットワークに接続するために、８０２．１Ｘプロトコルが実装されている。認証は、そのような種々のプロトコルのうちのいずれかに、例えばＥＡＰ−ＴＬＳ又はＥＡＰ−ＴＴＳに準拠することができる。当業者には公知の広く使用されているアクセス技術によって、ゲストユーザにはログインＩＤ及びパスワード情報が提供される。例えば、ローカルネットワークは、ゲストユーザにログインＩＤ「Ｇｕｅｓｔ」及びパスワード「ＮｅｔｗｏｒｋＸ」を提供することができる。従って、ゲストユーザは、ログインＩＤ及びパスワードを要求する単純なインタフェースを介して、ローカルネットワークに単純にログインする。セキュリティ対策が採られていない場合、ゲストは、ネットワーク上のリソースに広範にアクセスすることができる。

図示の実施の形態は、ネットワークレベルのセキュリティを提供することによって、これを制御する。このケースにおいては、上記において述べたその他の実施の形態と同様に、ローカルネットワーク又はその他の実体が、特定のゲスト証明書を、例えば上記において述べたような、また図７Ａ及び図７Ｂに示されているようなゲスト証明書を、ゲストユーザに交付する。上述のように、このゲスト証明書は、ゲストユーザ固有の情報を有しており、また、ゲストユーザによるローカルネットワークへのアクセス及びローカルネットワークの使用を効果的に制限する。より詳細には、図示の実施の形態において、ゲスト証明書は、ゲストユーザの詳細を識別する１つ又は複数のサブジェクト行、及び、ゲストユーザがローカルネットワーク内の（１つ又は複数の）ノードにアクセスする際に所定の一連の特権を有することを許可するポリシー情報も含んでいる。従って、上記においてクライアント４００について説明したことと同様に、ゲストユーザのアクセスは、それら２つのフィールド、即ちデバイスアクセス及びポリシーの両方によって制限される。

また図示の実施の形態は、ゲストユーザのデバイスのＭＡＣアドレス（即ち、クライアントデバイス識別子として使用されるアドレス）を、証明書に関連付ける。従って、ゲストユーザがローカルネットワークにログインした後に、エッジルータ４０６又は類似のノードは、ゲスト証明書のレコード及びゲストユーザのデバイスのＭＡＣアドレスを維持する。特に、幾つかの実施の形態においては、エッジルータ４０６は、ゲストユーザの特定の（１つ又は複数の）パケット（例えば最初のパケット）のレイヤ２ヘッダから、ＭＡＣアドレスを取得することができる。

ゲストユーザがローカルネットワークからログオフし、その後、再びログインする場合、エッジルータ４０６又は類似のノードは、アクセスを試みるデバイスのＭＡＣアドレス及び証明書を、自身のローカルメモリに記憶されているＭＡＣアドレス及び証明書と比較することができる。それらが合致した場合、エッジルータ４０６は、更なるアクセスを許可する。しかしながら、それらが合致しなかった場合、エッジルータ４０６は、更なるネットワークアクセスを阻止する。後者のケースにおいては、ゲストユーザは、新たなログインＩＤ及びパスワードの取得、又は、新たなゲスト証明書又はオリジナルのゲスト証明書を用いた新たなデバイスの登録を要求することができる。

従って、この実施の形態においては、ゲストユーザによるローカルネットワークの使用及びローカルネットワークへのアクセスの制御に加えて、ゲスト証明書は、ローカルネットワークにアクセスして、ローカルネットワークとのセッションを開始するゲストユーザの認証を支援する。換言すれば、ゲスト証明書は、更に、ゲストユーザが正当なゲストであることを保証する。実際のところ、この実施の形態及びその他の実施の形態は、ローカルネットワークにアクセスするその他の種類のユーザにも適用される。従って、種々の実施の形態は、ローカルネットワークへのアクセスの上述の様式に制限されるものではない。

従って、種々の実施の形態は、証明書ベースの攻撃に関する検出技術を向上させ、また、それらの攻撃の影響を緩和する（理想的にはそのような攻撃を停止させる）。エッジルータ４０６によって実現される場合には、そのような攻撃をネットワーク内の初期のポイントで（例えば、パケットがアプリケーションサーバ４０２に到達する前）緩和する又は停止させることができる。従って、そのような実施の形態は、ネットワークレベルでクライアント／ユーザの証明書を検査及び実施することができ、また、不正なログインの試みを積極的に抑制することができる。アプリケーションサーバ４０２の保護に加えて、種々の実施の形態は、コアネットワークを攻撃から保護しつつ、コアネットワークトラフィックを大幅に低減する。

本発明の種々の実施の形態を、少なくとも部分的に、任意の慣例のコンピュータプログラム言語で実現することができる。例えば、幾つかの実施の形態を、手続き型プログラミング言語（例えば「Ｃ」）、又は、オブジェクト指向プログラミング言語（例えば「Ｃ＋＋」）で実現することができる。本発明のその他の実施の形態を、事前構成されたスタンドアローン型のハードウェア要素及び／又は事前プログラミングされたハードウェア要素（例えば特定用途向け集積回路、ＦＰＧＡ及びディジタル・シグナル・プロセッサ）として、又はその他の関連するコンポーネントとして実現することができる。

１つの代替的な実施の形態においては、開示した装置及び方法（例えば上述の種々のフローチャートを参照されたい）を、コンピュータシステムを用いて使用するためのコンピュータプログラム製品として実現することができる。そのような実施の形態は、実体のある非一時的な媒体、例えばコンピュータ可読媒体（例えば、ディスケット（登録商標）、ＣＤ−ＲＯＭ、ＲＯＭ又は固定ディスク）に記憶されている一連のコンピュータ命令を含むことができる。一連のコンピュータ命令は、本明細書においてシステムに関して上述した機能性の全て又は一部を実施することができる。

当業者であれば、そのようなコンピュータ命令を、多くのコンピュータアーキテクチャ又はオペレーティングシステムを用いて使用するために、多数のプログラミング言語で書けることが分かる。更に、そのような命令を、任意のメモリデバイスに、例えば半導体デバイス、磁気デバイス、光学デバイス又はその他のメモリデバイスに記憶することができ、また、任意の通信技術を使用して、例えば光学伝送技術、赤外線伝送技術、マイクロ波伝送技術又はその他の伝送技術を使用して伝送することができる。

この他、そのようなコンピュータプログラム製品を、リムーバブル媒体として、印刷された文書又は電子文書と共に配布することができ（例えば市販ソフトウェア）、コンピュータシステムに（例えばシステムＲＯＭ又は固定ディスクに）プリロードすることができるか、若しくは、ネットワーク（例えばインターネット又はワールド・ワイド・ウェブ）を介してサーバ又は電子掲示板から配布することができる。実際には、幾つかの実施の形態を、ＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）モデル又はクラウドコンピューティングモデルとして実現することができる。勿論、本発明の幾つかの実施の形態を、ソフトウェア（例えばコンピュータプログラム製品）とハードウェアの組み合わせとして実現することができる。本発明の更に別の実施の形態は、完全にハードウェアとして、又は完全にソフトウェアとして実現される。

上記においては、本発明の種々の実施例を説明したが、当業者であれば、本発明の真の精神から逸脱することなく、本発明の幾つかの利点を達成する種々の変更を行えることが分かる。

Claims (39)

1. ネットワークを介してデータをルーティングする方法において、
   該方法は、
   複数のノードを有しているローカルネットワーク内の少なくとも１つのノードにアクセスするクライアントノードからセッションリクエストを受信するステップと、
   前記クライアントノードからパケットを受信する少なくとも１つのノードを指定するクライアント情報を有しているクライアント証明書を、前記クライアントノードから受信するステップと、
   前記クライアント証明書を使用して、認証プロセスを実行するステップと、
   前記クライアント証明書から前記クライアント情報を検索するステップと、
   前記認証プロセスによって前記クライアントノードが認証された場合には、前記クライアントノードから受信したデータパケットを、前記クライアント証明書における前記クライアント情報によって指定された通りに、前記ローカルネットワーク内の少なくとも１つのノードにルーティングするステップと、
   を有していることを特徴とする、方法。
2. 前記認証プロセスによって前記クライアントノードが認証されなかった場合には、前記クライアントノードを拒否するステップを更に有している、
   請求項１に記載の方法。
3. 前記拒否は、前記クライアントノードのパケットの、前記ローカルネットワーク内のその他のノードへのアクセスの遮断を含んでいる、
   請求項２に記載の方法。
4. 前記クライアント情報は、前記クライアントノードを識別する識別情報を含んでいる、
   請求項１に記載の方法。
5. データパケットのルーティングは、
   前記クライアントノードから前記データパケットを受信する前記ローカルネットワーク内の前記少なくとも１つのノードの識別子を求めるための、前記クライアント情報の使用と、
   前記クライアントノードから、識別された前記少なくとも１つのノードへのデータパケットのルーティングと、
   を含んでいる、
   請求項１に記載の方法。
6. 認証された場合には、ルーティングは、前記クライアントノードによる前記少なくとも１つのノードへのアクセスを許可し、
   前記クライアント情報は、前記ローカルネットワーク内の前記少なくとも１つのノードにアクセスする際に前記クライアントノードに対して一連の特権を与えるポリシー情報を含んでいる、
   請求項５に記載の方法。
7. 前記クライアント情報は、
   ａ）前記クライアントノードを識別する識別情報、又は、
   ｂ）前記ローカルネットワーク内の前記少なくとも１つのノードにアクセスする際に前記クライアントノードに対して一連の特権を与えるポリシー情報、又は、
   ｃ）前記（ａ）及び前記（ｂ）の両方、
   を含んでいる、
   請求項１に記載の方法。
8. データパケットのルーティングは、識別情報及び前記ポリシー情報の一方又は両方によって指定された通りのデータパケットのルーティングを含んでいる、
   請求項７に記載の方法。
9. 前記ローカルネットワークは、セッションリクエストの受信、クライアント証明書の受信、検索及びルーティングのうちの少なくとも１つを実行するエッジルータを含んでいる、
   請求項１に記載の方法。
10. 前記少なくとも１つのノードは、アプリケーションサーバを有しており、
    前記ローカルネットワークには、ローカルエリアネットワークが含まれる、
    請求項１に記載の方法。
11. 前記ローカルネットワーク内の受信ノードは、前記セッションリクエストを受信し、
    前記方法は、前記受信ノードと、前記ローカルネットワーク内の前記少なくとも１つのノードと、の間に静的なコネクションを維持するステップを、更に有しており、
    ルーティングは、前記静的なコネクションに沿った、前記クライアントからのデータパケットのルーティングを含んでいる、
    請求項１に記載の方法。
12. 前記セッション中に、前記クライアントノードと、前記ローカルネットワーク内の前記少なくとも１つのノードと、の間でハンドシェイクプロセスは実施されない、
    請求項１１に記載の方法。
13. 前記証明書を受信する前に、前記クライアントノードと前記少なくとも１つのノードとの間での、最初のハンドシェイクプロセスを許可するステップと、
    前記認証プロセスによって前記クライアントノードが認証された場合には、前記クライアントノードと少なくとも１つのノードとの間での、最後のハンドシェイクプロセスの完了を許可するステップと、
    を更に有している、
    請求項１に記載の方法。
14. 認証プロセスの実行は、ゲストユーザのためのログインＩＤ及びパスワードの受信と、前記ログインＩＤ及び前記パスワードが前記ローカルネットワーク内のアクセスに対して有効であることの確認と、を含んでいる、
    請求項１に記載の方法。
15. クライアントノードデバイスを識別するクライアントデバイス識別子を求めるステップと、
    前記クライアントデバイス識別子及び前記クライアント証明書を使用して、前記認証プロセスを実行するステップと、
    を更に有している、
    請求項１４に記載の方法。
16. 前記クライアントデバイス識別子は、ＭＡＣアドレスを含んでいる、
    請求項１５に記載の方法。
17. ネットワークを介して受信したデータをルーティングするネットワークルーティングデバイスにおいて、
    該ネットワークデバイスは、
    ａ）複数のノードを有しているローカルネットワーク内の少なくとも１つのノードにアクセスするクライアントノードからのセッションリクエストと、ｂ）前記クライアントノードからパケットを受信する少なくとも１つのノードを指定するクライアント情報を有している、前記クライアントノードからのクライアント証明書と、を受信するインタフェースと、
    適切に作用するように前記インタフェースに接続されており、且つ、前記クライアント証明書を検索し、前記クライアント証明書を使用して認証プロセスを実行するように構成されているオーセンティケータと、
    適切に作用するように前記オーセンティケータに接続されており、且つ、前記認証プロセスによって前記クライアントノードは認証されたか否かを前記オーセンティケータから求めるように構成されているルータと、
    を含んでおり、
    前記ルータは、更に、前記クライアントノードが認証された場合には、前記クライアントノードから受信したデータパケットを、前記クライアント証明書における前記クライアント情報によって指定された通りに、前記ローカルネットワーク内の少なくとも１つのノードにルーティングするように構成されている、
    ネットワークルーティングデバイス。
18. 前記クライアント情報は、前記クライアントノードを識別する識別情報を含んでいる、
    請求項１７に記載のネットワークルーティングデバイス。
19. 前記ルータは、前記クライアントノードから前記データパケットを受信する前記ローカルネットワーク内の前記少なくとも１つのノードの識別子を求めるために前記クライアント情報を使用するように構成されており、
    前記ルータは、更に、クライアントデータパケットを前記クライアントノードから、識別された前記少なくとも１つのノードにルーティングするように構成されている、
    請求項１７に記載のネットワークルーティングデバイス。
20. 前記ルータは、認証された場合には、前記クライアントノードによる前記少なくとも１つのノードへのアクセスを許可するように構成されており、
    前記クライアント情報は、前記ローカルネットワーク内の前記少なくとも１つのノードにアクセスする際に前記クライアントノードに対して一連の特権を与えるポリシー情報を含んでいる、
    請求項１９に記載のネットワークルーティングデバイス。
21. 前記クライアント情報は、
    ａ）前記クライアントノードを識別する識別情報、又は、
    ｂ）前記ローカルネットワーク内の前記少なくとも１つのノードにアクセスする際に前記クライアントノードに対して一連の特権を与えるポリシー情報、又は、
    ｃ）前記（ａ）及び前記（ｂ）の両方、
    を含んでいる、
    請求項１７に記載のネットワークルーティングデバイス。
22. 前記ルータは、識別情報及び前記ポリシー情報の一方又は両方によって指定された通りにデータパケットをルーティングするように構成されている、
    請求項２１に記載のネットワークルーティングデバイス。
23. 前記ルータは、前記ローカルネットワークのためのエッジルータとして構成されている、
    請求項１７に記載のネットワークデバイス。
24. ネットワークを介してデータをルーティングするための、コンピュータシステムにおいて使用されるコンピュータプログラム製品において、
    前記コンピュータプログラム製品は、有形の非一時的なコンピュータ使用可能媒体と、該媒体におけるコンピュータ可読プログラムコードと、を有しており、
    該コンピュータ可読プログラムコードは、
    複数のノードを有しているローカルネットワーク内の少なくとも１つのノードにアクセスするクライアントノードからセッションリクエストを受信するためのプログラムコードと、
    前記クライアントノードからパケットを受信する少なくとも１つのノードを指定するクライアント情報を有しているクライアント証明書を、前記クライアントノードから受信するためのプログラムコードと、
    前記クライアント証明書を使用して、認証プロセスを実行するためのプログラムコードと、
    前記クライアント証明書から前記クライアント情報を検索するためのプログラムコードと、
    前記認証プロセスによって前記クライアントノードが認証された場合には、前記クライアント証明書における前記クライアント情報によって指定された通りに、前記ローカルネットワーク内の少なくとも１つのノードに、前記クライアントノードから受信したデータパケットをルーティングするためのプログラムコードと、
    を含んでいる、コンピュータプログラム製品。
25. 前記認証プロセスによって前記クライアントノードを認証できなかった場合には、前記クライアントノードを拒否するためのプログラムコードを更に含んでいる、
    請求項２４に記載のコンピュータプログラム製品。
26. 前記拒否するためのプログラムコードは、前記クライアントノードのパケットの、前記ローカルネットワーク内のその他のノードへのアクセスを遮断するためのプログラムコードを含んでいる、
    請求項２５に記載のコンピュータプログラム製品。
27. 前記クライアント情報は、前記クライアントノードを識別する識別情報を含んでいる、
    請求項２４に記載のコンピュータプログラム製品。
28. 前記データパケットをルーティングするためのプログラムコードは、
    前記クライアントノードから前記データパケットを受信する前記ローカルネットワーク内の前記少なくとも１つのノードの識別子を求めるために前記クライアント情報を使用するためのプログラムコードと、
    前記クライアントノードから、識別された前記少なくとも１つのノードにデータパケットをルーティングするためのプログラムコードと、
    を含んでいる、
    請求項２４に記載のコンピュータプログラム製品。
29. 前記ルーティングするためのプログラムコードによって、認証された場合には、前記クライアントノードによる前記少なくとも１つのノードへのアクセスが許可され、
    前記クライアント情報は、前記ローカルネットワーク内の前記少なくとも１つのノードにアクセスする際に前記クライアントノードに対して一連の特権を与えるポリシー情報を含んでいる、
    請求項２８に記載のコンピュータプログラム製品。
30. 前記クライアント情報は、
    ａ）前記クライアントノードを識別する識別情報、又は、
    ｂ）前記ローカルネットワーク内の前記少なくとも１つのノードにアクセスする際に前記クライアントノードに対して一連の特権を与えるポリシー情報、又は、
    ｃ）前記（ａ）及び前記（ｂ）の両方、
    を含んでいる、
    請求項２４に記載のコンピュータプログラム製品。
31. 前記データパケットをルーティングするためのプログラムコードは、識別情報及び前記ポリシー情報の一方又は両方によって指定された通りにデータパケットをルーティングするためのプログラムコードを含んでいる、
    請求項３０に記載のコンピュータプログラム製品。
32. 前記ローカルネットワークは、前記セッションリクエストを受信するためのプログラムコード、前記クライアント証明書を受信するためのプログラムコード、前記検索するためのプログラムコード及び前記ルーティングするためのプログラムコードのうちの少なくとも１つを実行するエッジルータを含んでいる、
    請求項２４に記載のコンピュータプログラム製品。
33. 前記少なくとも１つのノードは、アプリケーションサーバを有しており、
    前記ローカルネットワークには、ローカルエリアネットワークが含まれる、
    請求項２４に記載のコンピュータプログラム製品。
34. 前記ローカルネットワーク内の受信ノードは、前記セッションリクエストを受信し、
    前記コンピュータプログラム製品は、前記受信ノードと、前記ローカルネットワーク内の前記少なくとも１つのノードと、の間に静的なコネクションを維持するためのプログラムコードを更に含んでおり、
    前記ルーティングするためのプログラムコードは、前記静的なコネクションに沿って、前記クライアントからのデータパケットをルーティングするためのプログラムコードを含んでいる、
    請求項２４に記載のコンピュータプログラム製品。
35. 前記セッション中に、前記クライアントノードと、前記ローカルネットワーク内の前記少なくとも１つのノードと、の間でハンドシェイクプロセスは実施されない、
    請求項３４に記載のコンピュータプログラム製品。
36. 前記証明書を受信する前に、前記クライアントノードと前記少なくとも１つのノードとの間での、最初のハンドシェイクプロセスを許可するためのプログラムコードと、
    前記認証プロセスによって前記クライアントノードが認証された場合には、前記クライアントノードと少なくとも１つのノードとの間での、最後のハンドシェイクプロセスの完了を許可するためのプログラムコードと、
    を更に含んでいる、
    請求項２４に記載のコンピュータプログラム製品。
37. ネットワークを介してデータをルーティングする方法において、
    該方法は、
    複数のノードを有しているローカルネットワーク内の少なくとも１つのノードにアクセスするクライアントノードからセッションリクエストを受信するステップと、
    前記クライアントノードからパケットを受信する少なくとも１つのノードを指定するクライアント情報を有しているクライアント証明書を、前記クライアントノードから受信するステップと、
    前記クライアント証明書から前記クライアント情報を検索するステップと、
    前記クライアント証明書における前記クライアント情報に基づいて、前記少なくとも１つのノードへの少なくとも制限的なアクセスを容易にするステップと、
    を有していることを特徴とする、方法。
38. 前記クライアント情報は、ポリシー情報を含んでいる、
    請求項３７に記載の方法。
39. 前記少なくとも１つのノードは、関連付けられた一連のアクセス特権を有しており、
    少なくとも制限的なアクセスを容易にすることは、前記クライアントノードに、前記関連付けられた一連のアクセス特権のうちの少なくとも１つを許可することを含んでいる、
    請求項３８に記載の方法。

Images