JP2009508261A - リモートリソースとの安全な対話型接続の生成 - Google Patents

Abstract

本発明の実装形態は、接続設定の段階で初期にクライアントおよびサーバを認証することによって少なくとも一部、クライアントとサーバとの間の安全な接続を効率的に確立する。サーバとの接続を開始するクライアントは、クライアントで有効化された安全な通信プロトコルを識別し、クライアントがサーバに送信する接続要求内でこれらのプロトコルを識別する。サーバは、メッセージを処理し、サーバが接続に適切と見なす通信プロトコルを用いて応答する。次いで、クライアントおよびサーバは、適切な認証情報を交換し、次いで、選択された通信プロトコルを実現する接続セッションを確立し、ネゴシエートされた通信プロトコルを使用してメッセージを暗号化する。追加の実装形態は、必ずしもほとんどの接続リソースオーバヘッドを再コミットする必要もなく仮想インターネットプロトコルアドレスのうしろで切断された接続を再確立することに関する。

Description

本発明は、リモートリソースとの安全な対話型接続の生成に関し、より詳細には、消失された安全な接続の整合性のある再確立を可能にするリモートリソースとの安全な対話型接続の生成に関する。

コンピュータ化されたシステムの需要が高まると同時に、大小のネットワークの両方でコンピュータシステムのファイルおよび処理リソースを分散する必要性がある。概して、コンピュータシステムおよび関連の装置は、例えば、個人電子メッセージを交換する、商品を販売する、アカウント情報を提供するなどの様々な理由のためにネットワークを介して情報を伝達する。しかし、コンピュータシステムおよびそれらの関連のアプリケーションがますます高度になるにつれて、ネットワーク上でデータおよびリソース（例えば、「装置」、「アプリケーション」、または「アプリケーションコンポーネント」）を共有することに関連した課題も増大している。

ネットワーク内でリソースを分散するいくつかの現在の方法は集中型コンピューティングのシナリオを含み、局部的にインストールされたそれらのリソースを持たない１つまたは複数のクライアントとリソースを共有する集中ネットワークサーバを必要としうる。この種の機能のために使用されているこのようなプロトコルの１つがリモートデスクトッププロトコル（Ｒｅｍｏｔｅ Ｄｅｓｋｔｏｐ Ｐｒｏｔｏｃｏｌ）（「ＲＤＰ」）である。リモートデスクトッププロトコルを用いて集中ネットワークサーバは、ネットワーク上の他のクライアントと対象となるデータおよびリソースを共有することができる。次いで、場合によってクライアントは、まさにそれらのリソースが局部的にインストールされているかのようにそれらのリソースと対話（例えば、マウスおよびキーボードのイベント（ｅｖｅｎｔ）を送信することなど）を可能にすることができる。理想的には、クライアントコンピュータシステムとネットワークサーバとの間のこの対話は、クライアントコンピュータシステムがそれ自体のインストールされたリソースを用いて局部的にデータを処理しているかのようにシームレスに生じる。

ユーザが集中サーバとの接続を開始するとき、ユーザのクライアントコンピュータシステムは、ユーザが最終的にサーバコンピュータシステムにログインすることになる一連のプロトコル交換を開始する。この交換の集合の一部が、ほとんどの種類の安全なネットワーク接続に固有である標準的接続の「ハンドシェイク（ｈａｎｄｓｈａｋｅ）」のオーバヘッドである。このオーバヘッドのほとんどは、ユーザが個人の資格証明（例えば、ユーザ名およびパスワード）を用いて認証する機会をこれまでに有する前にクライアントコンピュータシステムと集中サーバとの間で初期の接続を設定することの一部である。例えば、場合によっては、ユーザにログイン画面が提示される前に集中サーバでクライアントログインの一部として行う１６個もの異なる交換がありうる。その結果、典型的には集中サーバおよびクライアントコンピュータシステムは、ユーザが実際に認証する前でさえユーザの接続セッションを生成するためにかなりの量の接続処理リソースを使用する。

ユーザ認証でのこの相対的遅延は、クライアント／サーバの対話に対するいくつかの異なる問題をもたらす。具体的には、この種の接続設定の問題のうちの１つは、権限のあるユーザだけが結局は完全に認証されることになりうる場合でも、誰でもサーバへの接続を開始することができることである。この初期の接続のオーバヘッドは、悪質なエージェントが集中サーバを過負荷にし、侵害するつもりで複数の接続要求を開始するときなど、ある種のサービス拒否（「ＤＯＳ」）攻撃に対する集中サーバに関する潜在的責任を生成しうる。

これらなどの接続シナリオに伴う他の潜在的問題は、クライアントおよびサーバが接続を切断されるときに問題が生じる。具体的には、元の接続設定が維持されていても典型的にはほとんどなく、クライアントコンピュータシステムおよびサーバは接続を再確立する必要があり、それは再び以前に設定されたオーバヘッドシーケンスをリスタートすることを意味する。これは、無線接続などの変動する強度の接続を使用するクライアントコンピュータシステムに伴う問題を生じさせる可能性があり、クライアントコンピュータシステムの望ましいシームレスな経験を阻害する。

これはまた、クライアントコンピュータシステムがサーバファーム（ｓｅｒｖｅｒ ｆａｒｍ）を介して集中サーバに接続されている状態で問題が生じる。例えば、組織が負荷分散の課題を共有するために一群のサーバ（すなわち、「サーバファーム」）を構成することができるが、同時に単一の仮想インターネットプロトコルのアドレス（「ＶＩＰ」）を介してアドレス可能である。しかし、クライアントコンピュータシステムがサーバファームから接続を切断する場合、クライアントコンピュータシステムは、クライアントコンピュータシステムとの接続を処理しているサーバファーム内のサーバに関する特定のネットワークアドレスではなくＶＩＰだけを認識している。したがって、クライアントコンピュータシステムは、ある問題なしに以前に確立された通信設定を使用して集中サーバと自動的に再接続することができず、典型的には通信を継続するために通常の接続プロトコル交換のすべてをリスタートする必要がある。

したがって、現在の接続開始プロトコルには解決されるべきいくつかの問題があり、具体的には集中型コンピューティング環境を扱う問題である。

本発明の実装形態は、以前に可能であったものより安全に安全なクライアントサーバ通信で資格証明情報を確立するように構成されるシステム、方法、およびコンピュータプログラム製品を備える当技術分野で１つまたは複数の問題を解決する。具体的には、本発明の実装形態は、サーバがかなりの量の接続リソースを割り当てる必要がない時点で認証情報の交換を行う。さらに、本発明の実装形態は、典型的な１対１のクライアント／サーバ接続であろうと、クライアントと仮想ＩＰアドレスのうしろにある複数のサーバのサーバファームとの間であろうと消失された安全な接続の整合性のある再確立を可能にするように容易に構成されることができる。

例えば、接続プロセスで比較的初期にクライアントコンピュータシステムとの安全な接続を生成するネットワークサーバの観点からの方法は、ネットワークサーバで１つまたは複数のリモートサーバリソースと通信するためにリモートクライアントから接続要求を受信することを含むことができる。概して、接続要求は、リモートクライアントが有効化される複数の安全な通信プロトコルを示す。その方法は接続応答をリモートクライアントに送信することを含み、この場合、接続応答は複数の安全な通信プロトコルのうちの好ましい安全な通信プロトコルを示す。さらに、その方法は、好ましい安全な通信プロトコルの使用およびリモートクライアントとの認証証明書の交換を確認し、好ましい安全な通信プロトコルによりリモートクライアントのリモートクライアントリソースとデータを通信することを含むことができる。

ネットワークサーバとの安全な接続を生成するクライアントコンピュータシステムの観点からの方法は、クライアントコンピュータシステムで複数の安全な通信プロトコル能力を識別することを含むことができる。その方法は、複数の安全な通信プロトコル能力のうちの好ましい１つをネットワークサーバとネゴシエートすることを含むことができる。したがって、クライアントおよびネットワークサーバは、相互に好ましい安全な通信プロトコルを識別する。

さらに、その方法は、好ましい安全な通信プロトコルを使用してネットワークサーバのリモートサーバリソースと認証情報を通信することを含み、それによってそれぞれの識別情報を確認することができる。概して、クライアントはそれ自体の認証情報を送信することができ、クライアントはサーバから認証証明書を受信する。サーバ証明書は、自己署名証明書、相互にインストールされた証明書、またはリモート証明機関から受信された証明書のうちのいずれか１つを備えることができる。その方法は、好ましい安全な通信プロトコルを使用して通信された１つまたは複数の初期のデータパケットを用いてネットワークサーバの識別情報を確認することをさらに含むことができる。

この要約は、下記の発明を実施するための最良の形態でさらに説明されている概念の選択を簡略化した形で紹介するために提供されている。この要約は、特許請求された主題の重要な特徴または不可欠な特徴を識別するものでもなく、特許請求された主題の範囲を決定する助けとして使用されるものでもない。

本発明の追加の特徴および利点が下記の説明で記載され、一部はその説明から明らかであり、または本発明の実施によって知られたりすることができる。本発明の特徴および利点は、添付の特許請求の範囲で具体的に指摘される装置および組合せにより理解され得られることができる。本発明のこれらの特徴および他の特徴は、下記の説明および添付の特許請求の範囲からより完全に明らかになり、以降に記載される本発明の実施によって知られることができる。

本発明の上記で列挙された利点および特徴ならびに他の利点および特徴が得られることができる方法を説明するために、上記で簡単に説明された本発明のより具体的な説明が、添付図面に示されているその特定の実施形態を参照することによってレンダリングされる。これらの図面が本発明の典型的な実施形態だけを示し、したがってその範囲を限定していると見なされるべきではないことを理解して、本発明が、添付図面の使用により追加の特異性および詳細を用いて記載され説明される。

本発明の実装形態は、以前に可能であったものより安全に安全なクライアントサーバ通信で資格証明情報を確立するように構成されるシステム、方法、およびコンピュータプログラム製品にまで及ぶ。具体的には、本発明の実装形態は、サーバがかなりの量の接続リソースを割り当てる必要がない時点で認証情報の交換を行う。さらに、本発明の実装形態は、典型的な１対１のクライアント／サーバ接続であってもクライアントと仮想ＩＰアドレスのうしろの複数のサーバのサーバファームとの間であっても、消失された安全な接続の整合性のある再確立を可能にするように容易に構成されることができる。

したがって、下記の明細書および特許請求の範囲からより完全に理解されるように、これらの原理の少なくとも１つの利点は、リモートクライアントおよびネットワークサーバが、必ずしもクライアントまたはコンピュータをある種のＤＯＳ攻撃にさらすことなく安全なネットワーク接続を確立することができることである。例えば、クライアントコンピュータシステムおよびネットワークサーバは、接続セッションを生成した後ではなく要求メッセージおよび応答メッセージの初期の集合内などの対話型ログオン接続シーケンスで初期にセキュリティ情報および資格証明情報を交換することができる。さらに、本発明の実装形態は、ネゴシエートされた安全な通信プロトコルを用いてその後に通信するときに、要求メッセージおよび応答メッセージがクライアントおよびサーバで確認されるようにする。したがって、クライアントおよびサーバは、認証情報を初期に提供しない、または接続生成の確認段階のうちの１つまたは複数を失敗する資格のない要求エンティティに重要なリソースを割り当てることを避けることができる。

例えば、図１Ａは、本発明の実装形態によるクライアントコンピュータシステムとネットワークサーバとの間のセキュリティネゴシエーションの総括的な概略図を示す。図示されるように、クライアント１００はリモートクライアントアプリケーション１０５を含む。概して、リモートクライアントアプリケーション（本明細書では「リモートリソース」、または「リモートクライアントリソース」とも呼ばれる）は、他のリモートアプリケーションまたは関連のコンポーネント（例えば、リモートサーバアプリケーション１４０）に接続し、データを共有することできるアプリケーションまたは関連のコンポーネントである。例えば、１つの実装形態では、リモートクライアントアプリケーション１０５は、安全な接続セッションを確立した後にネットワークサーバでＭＩＣＲＯＳＯＦＴ ＴＥＲＭＩＮＡＬ ＳＥＲＶＩＣＥ（マイクロソフトターミナルサービス）のアプリケーションと最終的に接続するためにリモートデスクトッププロトコル（「ＲＤＰ」）を使用するＭＩＣＲＯＳＯＦ ＴＴＥＲＭＩＮＡＬ ＳＥＲＶＩＣＥのクライアントである。そのような場合にはリモートクライアントリソースは、あるアプリケーション機能（例えば、ワードプロセッシング、スプレッドシートなど）を提供するためにサーバリソースにアクセスすることができ、次いで、そのアプリケーション機能はクライアントコンピュータシステム１００の表示画面（図示せず）に表示される。

図１Ａは、リモートクライアントアプリケーション１０５が、以降でより詳細に議論されるセキュリティオプションコンポーネント１２０ならびに資格証明マネジャ１０９および証明書ストア１１０と通信していることを示す。概して、セキュリティオプションコンポーネント１２０は、クライアントコンピュータシステム１００で有効化される（例えば、インストールされる、アクティブである）安全な通信プロトコルのすべてのリスト（例えば、システム構成表）である。この安全な通信プロトコルのリストは、任意の数の既知で利用可能なこの種のプロトコルを含むことができる。それにもかかわらず、図１Ａは、クライアント１００でのセキュリティオプション１２０が、例えば、セキュアソケットレイヤ（「ＳＳＬ」）コンポーネント１３０および「Ｃｒｅｄ−ＳＳＰ」（「Ｃｒｅｄｅｎｔｉａｌ−Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ（資格証明セキュリティサービスプロバイダ）」、「Ｃｒｅｄｅｎｔｉａｌ−Ｓｅｃｕｒｉｔｙ Ｓｕｐｐｏｒｔ Ｐｒｏｖｉｄｅｒ（資格証明セキュリティサポートプロバイダ）」としても知られる）コンポーネント１３５を備える。Ｃｒｅｄ−ＳＳＰコンポーネント１３５は、ＳＳＬ、ＷＩＮＤＯＷＳ（登録商標） ＮＴ ＬＡＮマネジャ（「ＮＴＬＭ」）、およびケルベロス認証プロトコルなどの他の安全な通信プロトコルの態様と共に結合している比較的新しいＷＩＮＤＯＷＳ（登録商標）セキュリティサービスプロバイダ（「ＳＳＰ」）である。図示されていないが、クライアント１００はレガシＲＤＰセキュリティインフラストラクチャ（Ｌｅｇａｃｙ ＲＤＰ ｓｅｃｕｒｉｔｙ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）を使用するように構成されることもできる。

説明のために、コンポーネント１２５、１３０、および１３５は、ＭＩＣＲＯＳＯＦＴのオペレーティングシステム環境内で使用されることが知られている安全な通信プロトコル（またはインフラストラクチャ、例えばレガシＲＤＰ）として示されているが、この説明内で概説される原理は、特定の種類の安全な通信プロトコルに限定されるものでもなく、特定のオペレーティングシステム環境またはアプリケーションに限定されるものでもないことが理解されよう。つまり、本明細書で説明される原理は、他の関連の安全なクライアント／サーバまたは共有アプリケーション、および対応する通信プロトコルに容易に適用されることができ、他の任意のオペレーティングシステム環境内で容易に実現されることができる。したがって、ＭＩＣＲＯＳＯＦＴオペレーティング環境内で一般に使用される名前に対する特定の詳説は、記述的便宜のために主としてなされている。

いずれにしても図１Ａは、リモートクライアントアプリケーション１０５が認証インターフェース１０３を介してクライアント資格証明（例えば、ユーザ名およびパスワード１０７）を受信することができる。例えば、あるユーザ入力からリモートクライアントアプリケーション１０５を開始する要求を受信すると、またはコンピュータ開始時などで汎用のログイン要求を受信すると、クライアント１００はユーザに認証インターフェース１０３を提供する。認証インターフェース１０３は、ユーザにユーザ名およびパスワード、スマートカード、または他の何らかの認証情報などのものを提供することを求める。次いで、ユーザによって供給されるこのクライアント認証情報および他のクライアント認証情報は、例えば資格証明マネジャ１０９内に格納されることができる。他の種類のクライアント認証情報は、スマートカードおよび個人識別番号（「ＰＩＮ」）１１１などのものを含むことができる。

場合によっては、クライアント１００は、クライアント証明書ストア１１０内に格納されるクライアント証明書１１３の形で認証情報を有することもできる。しかし、より典型的には（認証オブジェクトとしての）証明書は、以降でより詳細に議論されるようにサーバ１５０によって使用されることになる。概して、ある入力形式から生成され、証明書ストア内に格納され、ユーザまたはコンピュータシステムを識別するために最終的に使用されることができる多くの異なる種類のセキュリティ証明書がある。場合によっては、証明書は暗号鍵を提供するためのプレースホルダ（ｐｌａｃｅｈｏｌｄｅｒ）だけであってよい。それにもかかわらず、いくつかの種類の証明書は「自己署名証明書」を含み、自己署名証明書は基本的に、作成者によって署名されるが必ずしも第三者によって保証されないデジタル署名である。

他の種類の証明書は、ユーザがサーバにアクセスし、ユーザが生成した好ましい証明書を手動でインストールする場合などの手動でインストールされた証明書を含む。他の種類の証明書は、ユーザが、認定された認証機関によって保証されているデジタル署名など、第三者証明書サーバ保証インフラストラクチャを介して受信する証明書を含む。いずれにしても任意のまたはすべてのこれらの種類の証明書は、いつでも証明書ストア１１０（またはストア１５５）で格納されることができる。それにもかかわらず、図１Ａは、証明書ストア１１０が証明書１１３を保持することを示し、以降でより詳説されるように証明書ストア１１０は、サーバ１５０から送信されるサーバ証明書１１７（例えば、図１Ｂ〜１Ｃ）を最終的に保持することになる。

リモートクライアントアプリケーション１０５でのユーザが、サーバ１５０との安全な対話型ログオン接続を開始することを望むとき、まずクライアントアプリケーション１０５は内部のセキュリティ検出を実行することができる。例えば、クライアントアプリケーション１０５は、セキュリティオプションコンポーネント１２０内で利用可能な有効化された安全な通信プロトコルのそれぞれを識別することができる。次いで、クライアントアプリケーション１０５は、少なくともコンポーネント１２５、１３０、および１３５があり、それぞれは安全なネットワーク通信で使用されていることを識別することができる。クライアントアプリケーション１０５は、それがある種の環境内で使用することを好みうるレガシＲＤＰインフラストラクチャなどの既存のセキュリティインフラストラクチャも検出することができる。

次いで、リモートクライアントアプリケーション１０５は、識別された様々な安全な通信プロトコル（すなわち、１２５、１３０、１３５など）または関連のセキュリティインフラストラクチャのそれぞれを示す接続要求メッセージ１３７を用意する。接続要求メッセージ１３７が、対話型ログオンで一般に行なわれるように特定のリソースへのアクセスを要求しない汎用の接続要求であってよいことは明白である。しかし、本発明の原理は、サーバ１５０で特定のリソースを対象とするログオン接続要求に適用されることもできることが理解されよう。それにもかかわらず、接続要求１３７は、識別された様々な安全な通信プロトコルを含むように拡張されている少なくとも１つの実装形態での「Ｘ２２４」接続要求メッセージであってよい（すなわち、「クライアント能力」）。次いで、リモートクライアントアプリケーション１０５は、ネットワークを介して最終的に接続要求１３７をリモートサーバアプリケーション１４０に送信する。

代替の実装形態ではクライアント１００は、Ｘ２２４接続要求メッセージを用意せず、むしろＳＳＬを使用してメッセージ１３７をサーバ側のＣｒｅｄ−ＳＳＰ１７５に直接送信する。次いで、サーバ１５０は、メッセージ１３７の初期の１つまたは複数のパケット内のＳＳＬおよびＣｒｅｄ−ＳＳＰの指標を識別する。場合によっては、これによってクライアント１００およびサーバ１５０は、Ｘ２２４接続要求および応答メッセージを生成することに本来なら関連した一部のオーバヘッドなしにセキュリティネゴシエーションの段階をより迅速に完了することを可能にすることができる。

いずれにしても、メッセージ１３７がＸ２２４または他の関連の方法を使用して送信されると仮定すると、リモートサーバアプリケーション１４０はメッセージ１３７を受信し処理する。次いで、サーバ１５０は、クライアント１００によって提案された安全な通信能力を識別し、安全な通信プロトコル（またはセキュリティインフラストラクチャ）の適切な選択を決定する。例えば、図１Ａは、アプリケーション１４０の決定モジュール１４５を介してサーバ１５０は、サーバ１５０が、ＳＳＬコンポーネント、１７０および／またはＣｒｅｄ−ＳＳＰコンポーネント１７５のうちのいずれかを用いても有効化されることを識別することを示す。図示されていないが、サーバ１５０はレガシＲＤＰセキュリティインフラストラクチャを用いて有効化されることもできる。１つの実装形態では決定モジュール１４５は、クライアント側のコンポーネント１２０といくつかの点で類似しているサーバ側のセキュリティオプションコンポーネント（例えば、コンポーネント１６０）を見ることによって特定の安全な通信プロトコルを使用することを決定する。もちろん、サーバ１５０は、クライアント１００と共に存在しているものよりも少ないまたは多い数の安全な通信プロトコルを用いて有効化されることができる。そのような場合には決定モジュール１４５は、クライアント１００と共通であるそれらの通信プロトコルを識別し、好ましい通信プロトコル（またはインフラストラクチャ）を選ぶことができる。

決定モジュール１４５は、限定されないがシステム設定、ネットワーク管理者の設定もしくは他のユーザの設定、および／または他のネットワーク状態を含む任意の数の要因に基づいてこの決定を行うことができる。しかし、図１Ａは、リモートサーバアプリケーション１４０がＣｒｅｄ−ＳＳＰの安全な通信プロトコル１３９を使用して通信することを決定することを示す。具体的には図１Ａは、リモートサーバアプリケーション１４０は、サーバ１５０がＣｒｅｄ−ＳＳＰ（クライアント１００およびサーバ１５０それぞれでコンポーネント１３５および１７５）を使用して通信するように望むという指標を含む接続応答メッセージ１３９を用意することを示す。１つの実装形態（例えば、メッセージ１３７がＸ２２４接続メッセージである）では、接続応答メッセージ１３９もＸ２２４形式の接続応答メッセージである。次いで、サーバ１５０はメッセージ１３９をクライアント１００に送信し、クライアント１００によりメッセージを受信すると要求された接続の初期のセキュリティネゴシエーションの段階を完了する。

メッセージ１３９が好ましい安全な通信プロトコルの指標を含まない場合、クライアント１００は、サーバ１５０が以前に説明されたセキュリティネゴシエーションの段階を実行することができないより古いサーバであることを識別することができる。そのような場合にはクライアント１００は、接続を単に切断する、追加動作のためにユーザにプロンプトを出す、またはクライアント１００が、サーバ１５０が理解しうることを知っているデフォルトのセキュリティ通信プロトコルに合わせることができる。他の決定と同様に、このデフォルト設定は、ユーザ、ネットワーク管理者、または他のシステム全体のデフォルト設定のうちのいずれかに基づいていてよい。１つの実装形態では、安全な通信プロトコル設定の指標なしに接続応答メッセージ１３９を受信するとリモートクライアントアプリケーション１０５は、ＲＤＰ通信プロトコルにデフォルト設定する。

以前に説明されたセキュリティネゴシエーションの段階を完了した後、図１Ｂは、クライアントコンピュータシステム１００およびサーバ１５０が安全な通信チャネルを設定することができることを示す。この特定の場合では、クライアント１００およびサーバ１５０は、互いに対話するためにそれらのそれぞれの通信スタックのセキュリティ層内のそれぞれの「Ｃｒｅｄ−ＳＳＰ」コンポーネントを使用して安全な通信チャネルを開始する。これは、クライアント１００でのＣｒｅｄ−ＳＳＰコンポーネント１３５が、サーバ１５０でのＣｒｅｄ−ＳＳＰコンポーネント１７５と通信していることを意味する（例えば、図１Ｂで破線の両方向の矢印によって示されるように）。例えば、図１Ｂは、リモートクライアントアプリケーション１０５がメッセージ１６７をリモートサーバリソース（すなわち、リモートサーバアプリケーション１４０）に送信されるように用意することを示す。この場合にはメッセージ１６７は、使用すべき安全なチャネルのうちの１つまたは複数の提案（例えば、チャネル１６３）を含む。次いで、サーバ１００は、メッセージ１６７を検討し、どの提案されたチャネルを使用すべきかを決定する。次いで、サーバ１００は、クライアント１００によって提案されたチャネルのうちの１つ（例えば、チャネル１６３）の使用を確認する確認メッセージ１６９を送信する。

また、クライアント１００およびサーバ１５０は、ネゴシエートされた安全なチャネル（この場合ではチャネル１６３）の設定を最終的に承認するために認証情報を交換する。例えば、図１Ｂは、クライアント１００がクライアント認証情報１６８もサーバ１５０に送信し（メッセージ１６７と同時に、またはその後すぐに）、サーバ１５０はサーバ認証情報１７１を用いて応答することを示す。クライアント認証情報は、ユーザ名およびパスワード１０７、スマートカードおよびＰＩＮ１１１、ならびに場合によっては、さらにクライアント証明書１１３などの多種多様の認証機構を含むことができる。

対照的にサーバ認証情報１７１は、例えば、具体的に選択されたサーバ証明書ならびにケルベロス認証プロトコルのアカウント資格証明および／またはチケット（ｔｉｃｋｅｔ）などの多種多様の認証機構を含むこともできる。サーバ１５０では決定モジュール１４５は、どの利用可能なサーバ証明書が使用するべきかを決定することができる。１つの実装形態では決定モジュール１４５は、サーバ管理者選択の証明書を選び、次いで、サーバ１５０のシステム設定が証明書に関する設定を示すかどうかを知るためにチェックするように構成されている。サーバ管理者もサーバ１５０も証明書設定を示さなかった場合、決定モジュール１４５は、サーバ１４５にメッセージ１７１のために自己署名証明書を自動生成させることができる。いずれにしても、リモートサーバアプリケーション１４５はメッセージ１７１を用意し、選択されたセキュリティコンポーネント（すなわち、Ｃｒｅｄ−ＳＳＰ１７５）は決定されたサーバ証明書をメッセージ１７１に挿入することができる。次いで、サーバ１５０は、ネゴシエートされた安全なチャネル（例えば１６３）を介してメッセージ１７１を送信し、クライアント側の証明書ストア１１０内にサーバ証明書１１７のコピーを入れる。

クライアントによってまたはサーバによって送信された認証情報が受信側によって拒否される場合がありうることが理解されよう。受信側による無効の決定、認証情報上のタイムスタンプの期限切れ、識別情報と初期の接続設定メッセージ１３７、１３９内などで提供された情報との間の不一致を含むこの種の拒否に関する何らかの理由がありうる。このような状態では、対応する受信アプリケーション（例えば、それぞれ１０５、１４０）によって使用されるセキュリティコンポーネント（例えば、Ｃｒｅｄ−ＳＳＰ１３５、１７５）は、拒否に関する理由に基づいて特定の動作を行うように構成されることができる。例えば、決定モジュール１１５または決定モジュール１４５は、その構成設定を調べ、新しい証明書を要求し、接続を切断し、追加動作のためにユーザにプロンプトするなどを行うことができる。場合によっては、適切な動作は、どのようにアプリケーションがその種の問題を処理するように構成されているかを決定するデフォルトのシステム設定またはユーザ設定に依存することができる。

いずれにしても、クライアント１００およびサーバ１５０が安全なチャネル設定を完了する（すなわち、安全なチャネルをネゴシエートし、認証情報を送信し、受信し、受け入れる）と、クライアント１００およびサーバ１５０はユーザ接続セッションを確立し、データパケットを送信し始めることができる（例えば、図１Ｃ）。その結果、図１Ａおよび１Ｂは、クライアント１００およびサーバ１５０が、所与のユーザ接続セッションを確立する前に互いに認証することを示す。この初期の認証は、広範囲の利点を提供することができ、そのうちの少なくともいくつかはＤＯＳ攻撃を軽減するために使用されることができる。例えば、クライアントから受信された接続要求メッセージ（例えば、１３７、１６７、１６８）の初期の集合が適切なクライアント認証情報、またはクライアントのセキュリティ能力の指標を含まない場合、サーバ１５０は、接続要求を単に切断するように構成され、したがっていかなる接続処理オーバヘッドをコミットすることを避けることができる。

安全なチャネルを設定するためにこれらの初期の接続要求、応答に加えて図１Ｃは、クライアント１００およびサーバ１５０がシステムのセキュリティ能力を増大する追加のメッセージを送信することができることを示す。例えば、クライアント１００およびサーバ１５０は、セキュリティプロトコルでの選択を確認し、ユーザ接続セッション中にデータパケットの初期の集合を交換するときに互いにさらに認証することができる。具体的には図１Ｃは、クライアントアプリケーション１０５が、リモートアプリケーションプロトコル（例えば、ＲＤＰ）によりフォーマット化されたデータを含み、クライアント１００がリモートサーバアプリケーション１４０によって処理させるつもりであるメッセージ１７７を用意することを示す。図１Ｃは、メッセージ１７７は、初期の認証で選択されたセキュリティプロトコルが、実際にクライアントおよびサーバが選択しようとしたものであり、他のパーティによって改ざんされなかったことを確認するそれに添付されたメッセージ１３７および／または１３９のうちのいずれかを含むこともできることも示す。

メッセージ１７７を受信するとリモートサーバアプリケーション１４０は、対応するデータを処理し始めることができる。しかし、いくつかの実装形態ではリモートサーバアプリケーション１４０は、任意の添付メッセージが、サーバ１５０が予期するものと合致することを確認するまでメッセージ１７７のデータを処理し始めない。それにもかかわらず、図１Ｃは、メッセージ１７７を処理するとリモートサーバアプリケーション１４０が、リモートアプリケーションプロトコル（例えば、ＲＤＰ）のデータパケットとしてフォーマット化もされる応答メッセージ１７９を用意することを示す。さらに、図１Ｃは、メッセージ１７９は、セキュリティプロトコルをネゴシエートするときにサーバ１５０によって提案された能力を確認する方法として、それに添付されるメッセージ１３７および／または１３９のうちのいずれかを同様に含むことができることを示す。次いで、サーバ１５０はメッセージ１７９をクライアント１００に送信する。

受信するとリモートクライアントアプリケーション１０５は、メッセージ１７９内に含まれるデータを処理する。しかし、代替の実装形態では、上述のように、まずリモートクライアントアプリケーション１０５は、メッセージ１７９内に含まれる情報（例えば、添付メッセージまたは他）が、データを処理する前にクライアント１００が予期しているものであることを検証することができる。予期された情報が見当たらない場合、クライアント１００は、接続を切断する、追加の動作のためにユーザにプロンプトを出す、および／または新しい接続要求を送信することができる。同様に、メッセージ１７９内に含まれた情報が予期されているものと何らかの点で異なる場合、クライアント１００は、接続を切断する、修正をサーバに要求する、または単に初期からやり直し、新しい接続要求を行うことができる（例えば、図１Ａ）。

クライアント１００およびサーバ１５０が安全な通信チャネルを適切にネゴシエートし設定し、ネゴシエートされたプロトコルを確認し、それらのそれぞれの識別情報を確認したと仮定すると、対応するアプリケーション１０５および１４０は、選択された安全な通信プロトコルを使用して通信し続けることができる。例えば、クライアント１００でのアプリケーション１０５は、マウスまたはキーボードコマンドなどのユーザ選択イベントを受信し、フォーマット化（例えば、ＲＤＰ）し、送信することができ、リモートサーバアプリケーション１４０は、それらのイベントを処理し、対応する応答データを安全なチャネル１６３を介してクライアント１００に送信することができる。この通信は、無期限に、またはいずれかの当事者がチャネル１６３を意図的にもしくは偶然に閉じるまで行うことができる。したがって、下記の表は、上記のテキストで説明されたようにこの初期の設定プロセスの実装形態を簡単に概説する。

本発明の１つの実装形態ではクライアント１００は、資格証明または他の認証情報のためにユーザに再びプロンプトする必要もなくユーザ接続セッションをリスタートすることもできる。具体的には、クライアント１００が切断後に接続をリスタートする（自動のまたは手動の再接続によるなど）場合、クライアント１００は、その以前に有効な接続コンテキスト（ｃｏｎｔｅｘｔ）（すなわち、ユーザ資格証明コンテキストまたはハンドル（ｈａｎｄｌｅ））をリスタートする再接続要求を単にサブミット（ｓｕｂｍｉｔ）することができる。概して、接続コンテキスト（例えば、１１１、図１Ｄ）は、安全な通信プロトコルでの選択と共にサーバ１５０に以前に伝えられたクライアント認証情報（例えば、１６８）などのクライアント接続設定情報、ならびにクライアントおよびサーバが互いに容易に識別することができる他の任意の適切な設定を含む。上述のように、典型的にはこれは、ユーザ名およびパスワード、および／またはスマートカードおよびＰＩＮ認証コンポーネントを含む。したがって、接続が切断し、接続コンテキストが依然として有効である（すなわち、期限が切れていないまたは変更されていない）とき、クライアント１００は、認証情報のためにユーザにプロンプトすることなしにその接続コンテキストをサーバ１５０に再サブミットし、クライアント１００およびサーバ１５０が接続を切断した時点でネゴシエートされたチャネル１６３を介して通信し続けることができる。

しかし、今説明されたような再接続は、単一のＩＰアドレスのうしろにある負荷分散のために構成された一群のサーバなどのサーバファームに関してより複雑でありうる。例えば、図１Ｄに示されるように、サーバ１４８、１４９、１５０、および１５１のサーバファーム１８０はそれぞれが、同一のＩＰアドレス（すなわち、仮想ＩＰアドレス１９０（「ＶＩＰ１９０」））を介してリモートクライアントコンピュータに対してアドレス可能である。概して、ＶＩＰは、他のエッジサーバ（ｅｄｇｅ ｓｅｒｖｅｒ）によって、またはサーバファーム内の各サーバの構成によってさえ供給される。あるいは、サーバファーム１８０内の各サーバは、同一のＶＩＰの異なる態様を処理するように構成され、サーバファーム内の他のサーバにパケットをさらに中継しルーティングする。それにもかかわらず、サーバのすべてがＶＩＰを介して接続負荷の一部を共有することができるが、所与の時点でのいずれか１つのサーバだけが他のコンピュータ（例えば、クライアント１００）との特定のセッションを処理することができることになる。

接続責任の情報が適切に処理されることを保証するために図１Ｄは、各サーバ１４８、１４９、１５０、および１５１が対応する「セッションディレクトリエージェント」１８３、１８５、１８７、および１８９を有し、セッションディレクトリエージェントが、対応するセッションディレクトリエージェントがインストールされている各サーバで接続セッションを常に把握していることを示す。例えば、所与の接続を処理するサーバは、クライアント１００に関して上述されたように、ユーザ認証情報を含む接続しているクライアントに関する所与の接続コンテキストに基づいて１つまたは複数の接続セッションも有することになる。対応するセッションディレクトリエージェントを介してサーバおよび中央セッションディレクトリエージェントサーバ１５３は、サーバファーム（例えば、ＶＩＰ１９０のうしろのサーバファーム１８０）内の他のサーバによって提供されるすべてのセッションの位置のディレクトリリスト（ｄｉｒｅｃｔｏｒｙ ｌｉｓｔｉｎｇ）も有することになる。つまり、１つのサーバもサーバファームにより提供されるすべての接続に対してユーザセッションのすべてを通常有しないが、サーバが適切な情報（すなわち、所与のクライアントコンテキストに対応するセッション）を有しない接続をその情報を有するファーム内のサーバに正常に参照することができることになる。

したがって、例えば図１Ｄは、クライアント１００が、クライアント１００またはサーバ１５０が偶然に接続を切断した後のある時点などで再接続メッセージ１９３を用意し、ＶＩＰ１９０を介してこのメッセージを送信することを示す。図１Ｄは、メッセージ１９３が、サーバ１５０の名前および／またはネットワークアドレスを含むクッキー（ｃｏｏｋｉｅ）などの前の接続情報および／またはあるユーザ情報を含むことを示す。概して、ＶＩＰ管理インフラストラクチャ（例えば、サーバ１５３を介して）は、含まれる前の接続情報を認識し、したがってメッセージ１９３をサーバ１５０に適切にルーティングすることができる。次いで、サーバ１５０は、クライアント１００との安全なチャネルを確立し、サーバ１５０が前の接続に関する接続コンテキスト１１１を提供していることをセッションディレクトリエージェント１８７（またはセッションディレクトリサーバ１５３）を介して確認し、次いで前の接続セッションを再確立することができる。

自動再接続が生じない場合には、プロセスは、再接続メッセージ１９３が十分なサーバ識別情報を含むことができないので少し異なってよい。したがって、例えば、再接続メッセージ１９３が最初にサーバ１４８に到達する可能性があり、この場合にはサーバ１４８は前の接続を提供していない。それにもかかわらず、安全なチャネルを設定するとサーバ１４８は、セッションディレクトリエージェント１８３を介して、またはセッションディレクトリサーバ１５３を参照することによって、サーバ１４８がセッション１９１を使用して接続するために適切な情報を有していないことを決定するのに十分なメッセージ１９３を処理することができる。つまり、サーバ１４８は、メッセージ１９３内でユーザの識別もしくはサーバの識別を認識しない、またはサーバ１４８が前の接続に関する接続コンテキストを有しないことを識別する。

そのような処理ではセッションディレクトリエージェント１８３は、セッションディレクトリサーバ１５３と通信し、サーバ１５０がこのユーザセッションに関する記録を有することをサーバ１４８に示す（すなわち、コンテキスト１１１を介して）。したがって、サーバ１４８は、接続が利用可能ではないことを示す応答メッセージ１９５を用意し、接続がサーバ１５０によって処理されることができることをさらに示す。次いで、クライアント１００は、メッセージ１９５を受信し処理し、新しい再接続メッセージ１９７をさらに用意する。さらに、クライアント１００は、前の接続情報を付加し、この時点でサーバ１５０の使用を明らかにする（例えば、サーバ名および／またはネットワークアドレスなど）。

したがって、図１Ｄに示されるように、再接続要求メッセージ１９７は、ＶＩＰ１９０を介してサーバ１５０に適切にルーティングされる。例えば、インターネットおよびサーバファーム１８０とインターフェースするエッジサーバは、サーバ１５０に対する変更された要求を識別し、接続要求メッセージ１９７をサーバ１５０に転送する。サーバ１５０が接続要求１９７を受信するとき、サーバ１５０は、セッションディレクトリエージェント１８７が接続コンテキスト１１１に関する記録を有するかどうかを知るためにメッセージを処理し始める。セッションディレクトリエージェント１８７がコンテキスト１１１に関する記録を有するので、サーバ１５０は適切な再接続メッセージ（すなわち、メッセージ１９９）を用いて応答する。この簡単な交換のシーケンスは、クライアント１００とサーバ１５０との間で以前にネゴシエートされた通信チャネル１６３を再確立し、それによってクライアントおよびサーバは、新しい接続セッションを開始するためにリソースを再割当する必要もなく以前のように通信し続けることができる。

したがって、図１Ａから１Ｄまでは、安全な接続を生成するときに比較的初期に接続シーケンスを認証するためにいくつかの概略図およびコンポーネントを提供する。具体的には図１Ａから１Ｄまでは、どのように安全な接続が、安全な接続要求の第１のいくつかのデータパケット内で確立されることができるか、およびクライアントとサーバとの間のいくつかの確認層を提供するなどの方法で示す。したがって、クライアントおよびサーバの両方が偽りの接続に貴重なリソースをコミットすることを避けることができ、そうでない場合にはＤＯＳ攻撃を成功させることになりうる。

本発明の実装形態は、所望の結果を達成する方法で行為のシーケンス（および／または１つまたは複数の非機能的行為を備える機能ステップ）に関して説明されることもできる。例えば、図２は、安全な接続を開始するためにクライアント１００およびサーバ１５０のそれぞれの観点からの方法での行為の流れ図を示す。図２に示される行為は、図１Ａ〜１Ｄに示される概略図を参照して下記で説明される。

例えば、図２は、クライアント１００の観点からの方法が、複数の安全な通信プロトコルを識別する行為２００を備えることを示す。行為２００は、クライアントコンピュータシステムで複数の安全な通信プロトコル能力を識別することを含む。例えば、図１Ａに示されるように、決定モジュール１１５を介してリモートクライアントアプリケーション１０５は、コンポーネント１２５、１３０、および１３５が有効であることを識別し、安全な通信プロトコルがクライアント１００で有効化される。

さらに、図２は、クライアント１００の観点からの方法が、好ましい安全な通信プロトコルをネットワークサーバとネゴシエートする行為２１０を備えることを示す。行為２１０は、相互に好ましい安全な通信プロトコルが識別されるように複数の安全な通信プロトコル能力のうちの好ましい１つをネットワークサーバとネゴシエートすることを含む。例えば、クライアントアプリケーション１０５は、メッセージ１３７を用意し、サーバ１５０に送信する行為を実行し、この場合、メッセージ１３７は、安全な接続要求を含み、プロトコル１２５、１３０、および１３５が接続のために利用可能であることをさらに示す。

したがって、図２は、サーバ１５０の観点からの方法が、セキュリティ能力を識別する接続要求を受信する行為２２０を備えることを示す。行為２２０は、ネットワークサーバで１つまたは複数のリモートサーバリソースと通信するためにリモートクライアントから接続要求を受信することを含み、接続要求は、リモートクライアントが有効化される複数の安全な通信プロトコルを示す。例えば、図１Ａに示されるように、サーバアプリケーション１４０は、メッセージ１３７を受信し、処理すると、クライアント１００が「ＳＳＬ」および／または「Ｃｒｅｄ−ＳＳＰ」通信機構のうちのいずれかが可能であることを識別する。

さらに、図２は、サーバ１５０の観点からの方法が、好ましい安全な通信プロトコルを示す接続応答を送信する行為２３０を備えることを示す。行為２３０は、リモートクライアントに接続応答を送信することを含み、接続応答は、複数の安全な通信プロトコルのうちの好ましい安全な通信プロトコルを示す。例えば、図１Ａに示されるように、サーバアプリケーション１４０は、それがクライアント１００から示されるものと同一の有効化されたセキュリティオプションを有することを決定する。したがって、サーバアプリケーション１４０は、好ましい安全な通信プロトコル（この場合には、任意の数の設定またはシステム設定に基づいたグループからの「Ｃｒｅｄ−ＳＳＰ」１７５）を決定する。次いで、サーバアプリケーション１４０は、接続応答メッセージ１３９を用意しクライアント１００に送信し、この場合、メッセージ１３９はＣｒｅｄ−ＳＳＰを使用するための設定を示す。１つの実装形態ではこれは、行為２１０でクライアント１００によって設けられたセキュリティネゴシエーションの初期の段階を完了する。

したがって、図２は、クライアント１００の観点からの方法が、認証証明書をリモートサーバリソースと交換する行為２４０を備えることを示す。行為２４０は、好ましい安全な通信プロトコルを使用して認証情報をネットワークサーバのリモートサーバリソースと交換することを含み、この場合、サーバ認証情報は、自己署名証明書、手動でインストールされた証明書、またはリモート証明機関から受信された証明書のうちのいずれか１つを備える。例えば、図１Ｂに示されるように、リモートクライアントアプリケーション１０５は、１つまたは複数の適切なクライアント認証情報コンポーネント（例えば、ユーザ名およびパスワード１０７、スマートカードおよびＰＩＮ１１１、または証明書ストア１１０内のクライアント証明書１１３）を識別し、メッセージ１３７を介して選択された認証情報をリモートサーバアップリケーション１４０に送信する。応答ではリモートクライアントアプリケーションは、メッセージ１７１を介してサーバ１５０からサーバ証明書１１７を受信する。

図２は、サーバ１５０の観点からの方法が、好ましい安全な通信プロトコルの使用を確認する行為２５０を備えることをさらに示す。行為２５０は、初期のデータパケットをリモートクライアントコンピュータシステムと交換することにより好ましい安全な通信プロトコルの使用を確認することを含む。例えば、図１Ｃは、サーバアプリケーション１４０がメッセージ１７９を送信するとき、サーバ１５０はまた、以前に送信されたメッセージ１３７および１３９のコピーを含むこと、またはメッセージ１３９内で以前に宣言された設定を繰り返していることなどによって確認メッセージをクライアント１００に付加することを示す。

さらに、図２は、サーバ１５０の観点からの方法が、リモートクライアントリソースとデータを通信する行為２６０を備えることを示す。行為２６０は、好ましい安全な通信プロトコルによりリモートクライアントのリモートクライアントリソースとデータを通信することを含む。例えば、図１Ｃに示されるように、サーバアプリケーション１４０は、ネゴシエートされた通信チャネル１６３を介してメッセージ１７７（例えば、ＲＤＰデータパケット）を受信し、メッセージ１７９（例えば、メッセージ１７７に応答するＲＤＰデータパケット）または他の任意のデータ通信をリモートアプリケーション１０５に送信する。

したがって、図２は、クライアント１００の観点からの方法が、好ましい安全な通信プロトコルの使用を確認する行為２７０を備えることも示す。行為２７０は、１つまたは複数の初期のデータパケットを用いてネットワークサーバの識別情報を確認することを含む。例えば、リモートクライアントアプリケーションは、リモートアプリケーションプロトコルを介してメッセージ１７９（例えば、ＲＤＰを使用して用意されたメッセージ）を受信し、この場合、メッセージ１７９は、以前に送信されたメッセージ１３７および／または１３９のコピーなどのサーバ１５０からのある予期された情報を含む。したがって、メッセージ１７９は、クライアント１００を用いて選択され合意された安全な通信プロトコルの使用を確認する。

したがって、本明細書で説明された概略図および方法は、安全な通信チャネルおよび接続セッションを生成するために、ならびに接続プロセスで初期にそれらの安全な通信チャネルおよびセッションを認証するためにいくつかのコンポーネントおよび機構を提供する。具体的には本発明の実装形態は、対話型ログオンおよびリモートリソース通信で以前に利用可能であったものより高いレベルのセキュリティを提供することができる。例えば、クライアントおよびサーバは、接続プロセスで初期に互いに認証し、したがって、予期された時点でこの種の認証情報を提供しないものに接続セッションを割り当てることを避けることができる。さらに、クライアントおよびサーバは、クライアントのおよび／またはサーバのそれぞれの識別情報の追加の保証を提供するために接続シーケンス内の任意の数の時点で以前送信されたメッセージおよび／または設定を付加することができる。

本発明の実施形態は、下記でより詳細に議論されるように様々なコンピュータハードウェアを含む特殊用途のコンピュータまたは汎用コンピュータを備えることができる。具体的には、本発明の範囲内の実施形態は、コンピュータ実行可能命令またはその上に格納されたデータ構造を含むまたは有するコンピュータ可読メディアも含む。この種のコンピュータ可読メディアは、汎用コンピュータまたは特殊用途のコンピュータによってアクセスされることができる任意の利用可能なメディアであってよい。例として、限定されないがこの種のコンピュータ可読メディアは、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、もしくは他の光ディスク記憶装置、磁気ディスク記憶装置もしくは他の磁気記憶装置、またはコンピュータ実行可能命令もしくはデータ構造の形で所望のプログラムコード手段を含むもしくは格納するために使用されることができ、汎用コンピュータもしくは特殊用途のコンピュータによってアクセスされることができる他の任意のメディアを備えることができる。

情報が、ネットワークまたは他の通信接続（有線の、無線の、または有線もしく無線の組合せのいずれか）を介してコンピュータに転送されるまたは提供されるとき、コンピュータはコンピュータ可読メディアとして接続を適切に見る。したがって、任意のこの種の接続はコンピュータ可読メディアと適切に呼ばれる。上記の組合せもコンピュータ可読メディアの範囲内に含まれるべきである。

コンピュータ実行可能命令は、例えば汎用コンピュータ、特殊用途のコンピュータ、または特殊用途の処理装置にある機能または一群の機能を実行させる命令およびデータを備える。主題が、構造的特徴および／または方法論的行為に特定の言語で説明されているが、添付の特許請求の範囲で定義された主題は上述の特定の特徴または行為に必ずしも限定されるものではないことが理解されよう。むしろ、上述の特定の特徴および行為は、特許請求の範囲を実現する例示的な形として開示されている。

本発明は、その精神または不可欠な特徴から逸脱することなく他の特定の形で具現化されることができる。説明された実施形態は、あらゆる点で限定ではなく例示としてだけ見なされるべきである。したがって、本発明の範囲は、前述の説明によってではなく添付の特許請求の範囲によって示される。特許請求の範囲の均等物の意味および範囲内で生じるすべての変更はそれらの範囲内に包含されるべきである。

本発明の実装形態によるクライアントコンピュータシステムとネットワークサーバとの間のセキュリティネゴシエーションの総括的な概略図である。 本発明の実装形態によるクライアントコンピュータシステムおよびネットワークサーバが、安全なチャネルをネゴシエートし、安全なチャネルを最終的に確立するために認証情報を交換する図１Ａの概略図である。 本発明の実装形態によるクライアントコンピュータシステムおよびネットワークサーバが、それらのセキュリティプロトコル能力および／または選択を確認する方法でデータを交換する図１Ａ〜１Ｂの概略図である。 図１Ａ〜１Ｃに示されるネットワークサーバがサーバファームの一部である場合、ならびにクライアントコンピュータシステムおよびネットワークサーバが、接続が除去された後に再接続しようとする場合での本発明の実装形態による他の概略図である。 本発明の実装形態による安全なネットワーク接続を開始するためのクライアントコンピュータシステムおよびネットワークサーバの観点からの流れ図である。

Claims (20)

1. サーバが安全な接続を介してクライアントコンピュータシステムとデータを通信するコンピュータ化されたシステム内の前記サーバで、接続プロセスで比較的初期に前記クライアントコンピュータシステムから前記接続を開始するユーザを認証することによって前記安全な接続を生成する方法であって、
   サーバの１つまたは複数のリモートサーバリソースと通信するためにクライアントコンピュータシステムから接続要求を受信するステップであって、前記接続要求は前記クライアントコンピュータシステムが有効化される複数の安全な通信プロトコルを示す、受信するステップと、
   接続応答を前記クライアントコンピュータシステムに送信するステップであって、前記接続応答は前記複数の安全な通信プロトコルのうちの好ましい安全な通信プロトコルを示す、送信するステップと、
   安全なチャネル設定で前記クライアントコンピュータシステムとのデータ交換により前記好ましい安全な通信プロトコルの使用を確認するステップと、
   前記好ましい安全な通信プロトコルにより前記クライアントコンピュータシステムのクライアントアプリケーションプログラムとデータを通信するステップと
   を有することを特徴とする方法。
2. 前記複数の安全な通信プロトコルは、ＲＤＰ、ＳＳＬ、ＮＴＬＭ、ケルベロスセキュリティプロトコル、またはその組合せのうちの少なくとも１つを含むことを特徴とする請求項１に記載の方法。
3. 前記クライアントコンピュータシステムからの前記接続要求は、前記クライアントコンピュータシステムが有効化される前記複数の安全な通信プロトコルを含むように拡張されたＸ２２４接続要求であり、前記接続応答は、前記好ましい安全な通信プロトコルを含むように拡張されたＸ２２４接続応答であることを特徴とする請求項１に記載の方法。
4. 前記クライアントコンピュータシステムによって示された前記複数の安全な通信プロトコルのうちの少なくとも１つと同一である前記サーバでの１つまたは複数の安全な通信プロトコルを識別するステップをさらに有することを特徴とする請求項１に記載の方法。
5. 前記サーバでの前記１つまたは複数の安全な通信プロトコルのうちの１つが、サーバシステム設定に基づいて可能とされることを決定するステップをさらに有することを特徴とする請求項４に記載の方法。
6. 証明書ストア内の複数のサーバ証明書を識別するステップと、
   前記クライアントコンピュータシステムに送信するために前記複数のサーバ証明書のうちの好ましい１つを決定するステップと
   をさらに有することを特徴とする請求項１に記載の方法。
7. 前記好ましいサーバ証明書は、ユーザによって明確に選択された証明書、サーバシステムポリシにより構成された証明書、または自己署名サーバ証明書のうちのいずれかであることを特徴とする請求項６に記載の方法。
8. クライアントコンピュータシステムの認証情報を受信するステップと、
   前記クライアントコンピュータシステムに関する接続コンテキストの一部として前記認証情報を格納するステップと
   をさらに有することを特徴とする請求項１に記載の方法。
9. 前記クライアントコンピュータシステムの認証情報が無効であることを決定するステップをさらに備え、前記ステップは、
   （ｉ）前記クライアントコンピュータシステムの認証情報内のタイムスタンプが期限切れになっていることを識別するステップと、
   （ｉｉ）予期した認証情報を含んでいなかった１つまたは複数のメッセージが、前記クライアントコンピュータシステムから受信されていることを識別するステップと、
   （ｉｉｉ）受信した認証証明書が、前記クライアントコンピュータシステムからの前記接続要求に関連した予期した認証証明書と合致しないことを識別するステップと
   のうちの１つまたは複数を有することを特徴とする請求項８に記載の方法。
10. ＶＩＰアドレスを対象とする異なる接続要求を受信するステップをさらに有し、前記異なる接続要求は前の接続に関する接続情報を含むことを特徴とする請求項１に記載の方法。
11. 前記前の接続のために識別された接続コンテキストが前記サーバで保存されていることを識別するステップと、
    前記要求された異なる接続を可能にするステップと
    をさらに有することを特徴とする請求項１０に記載の方法。
12. 前記前の接続に関する接続コンテキストが異なるサーバで保存されていることを識別するステップと、
    応答メッセージを前記クライアントコンピュータシステムに送信するステップであって、前記応答メッセージは、前記異なるサーバが前記異なる接続要求にとって適切なサーバであることを示す、送信するステップと
    をさらに有することを特徴とする請求項１０に記載の方法。
13. 前記サーバが前記クライアントコンピュータシステムに対する前記好ましい安全な通信プロトコルのその選択を確認するように、前記初期の接続要求に関する前記クライアントコンピュータシステムから以前に受信された１つまたは複数のメッセージを前記サーバによって用意された送信メッセージに付加するステップをさらに有することを特徴とする請求項１に記載の方法。
14. 安全な接続を介してサーバとデータを通信するように構成されたクライアントコンピュータシステムで、接続プロセスで比較的初期に認証することによって前記サーバとの前記安全な接続を生成する方法であって、
    クライアントコンピュータシステムで複数の安全な通信プロトコル能力を識別するステップと、
    相互に好ましい安全な通信プロトコルが識別されるように前記複数の安全な通信プロトコル能力のうちの好ましい１つをサーバとネゴシエートするステップと、
    前記好ましい安全な通信プロトコルを使用して認証情報を前記サーバと交換するステップであって、前記サーバからの認証情報は、自己署名証明書、相互にインストールされた証明書、またはリモート証明機関から受信された証明書のうちのいずれか１つを備える、交換するステップと、
    前記サーバとのネゴシエーション中に伝達される１つまたは複数の初期のデータパケットを用いて前記サーバとネゴシエートされる前記安全な通信プロトコルの使用を確認するステップと
    を有することを特徴とする方法。
15. 前記複数の安全な通信プロトコルのうちの好ましい１つをネゴシエートする前記ステップは、
    前記クライアントコンピュータシステムで識別された前記１つまたは複数の安全な通信プロトコルの指標を含む接続要求メッセージを送信するステップと、
    前記安全な通信プロトコルのうちの前記相互に好ましい１つを識別する前記サーバからの応答を受信するステップと
    をさらに有することを特徴とする請求項１４に記載の方法。
16. 前記サーバとネゴシエートされた前記安全な通信プロトコルの前記使用を確認する前記ステップは、
    前記サーバから１つまたは複数の初期のデータパケットを受信するステップと、
    前記１つまたは複数の初期のデータパケットのうちのいずれかに付加される、前記サーバと以前に交換された情報を識別するステップと
    を有することを特徴とする請求項１４に記載の方法。
17. 前記クライアントコンピュータシステムで接続コンテキスト内に前記サーバから受信された前記サーバ証明書を格納するステップをさらに有することを特徴とする請求項１４に記載の方法。
18. 前記サーバとの接続が失敗したことを識別するステップと、
    再接続要求メッセージを前記サーバに関する仮想ＩＰアドレスに送信するステップであって、前記再接続要求メッセージは前記接続コンテキスト内に格納された少なくともいくつかの情報を含む、送信するステップと
    をさらに有することを特徴とする請求項１７に記載の方法。
19. 前記サーバに関する前記仮想ＩＰアドレスから接続拒否メッセージを受信するステップであって、前記接続拒否メッセージは、前記サーバに関するサーバ名およびネットワークアドレスのうちの少なくとも１つを含む、受信するステップと、
    新しい再接続要求メッセージを前記サーバに関する前記仮想ＩＰアドレスに送信するステップであって、前記新しい再接続要求メッセージは、前記サーバに関する前記サーバ名およびネットワークアドレスのうちの前記少なくとも１つを含む、送信するステップと、
    前記接続コンテキストにより前記サーバとの前記接続を再確立するステップと
    をさらに有することを特徴とする請求項１７に記載の方法。
20. サーバが安全な接続を介してクライアントコンピュータシステムとデータを通信するコンピュータ化されたシステム内の前記サーバで、実行時に前記サーバでの１つまたは複数のプロセッサに接続プロセスで比較的初期に前記クライアントコンピュータシステムを認証することによって前記安全な接続を生成する方法を実行させるコンピュータ実行可能命令を有するコンピュータプログラム製品であって、
    サーバの１つまたは複数のリモートサーバリソースと通信するためにクライアントコンピュータシステムから接続要求を受信する手段であって、前記接続要求は、前記クライアントコンピュータシステムが有効化される複数の安全な通信プロトコルを示す、受信する手段と、
    接続応答を前記クライアントコンピュータシステムに送信する手段であって、前記接続応答は前記複数の安全な通信プロトコルのうちの好ましい安全な通信プロトコルを示す、送信する手段と、
    安全なチャネル設定で前記クライアントコンピュータシステムとのデータ交換により前記好ましい安全な通信プロトコルの使用を確認する手段と、
    前記好ましい安全な通信プロトコルにより前記クライアントコンピュータシステムのクライアントアプリケーションプログラムとデータを通信する手段と
    を備えたことを特徴とするコンピュータプログラム製品。

Images