JP2004528609A - フィルタリングのなされたアプリケーション間通信 - 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