特許 7320572 ホスト上のコンテキスト属性の収集と処理

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-07-26

(45)【発行日】2023-08-03

(54)【発明の名称】ホスト上のコンテキスト属性の収集と処理

(51)【国際特許分類】

   G06F 16/90 20190101AFI20230727BHJP

   G06F 21/62 20130101ALI20230727BHJP

【ＦＩ】

G06F16/90

G06F21/62 318

【請求項の数】 22

【外国語出願】

(21)【出願番号】P 2021140189

(22)【出願日】2021-08-30

(62)【分割の表示】P 2019534353の分割

【原出願日】2017-12-10

(65)【公開番号】P2022003527

(43)【公開日】2022-01-11

【審査請求日】2021-09-24

(31)【優先権主張番号】201741026365

(32)【優先日】2017-07-25

(33)【優先権主張国・地域又は機関】IN

(31)【優先権主張番号】62/438,379

(32)【優先日】2016-12-22

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】15/650,294

(32)【優先日】2017-07-14

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】15/650,340

(32)【優先日】2017-07-14

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】15/796,875

(32)【優先日】2017-10-30

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】15/650,251

(32)【優先日】2017-07-14

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】511235548

【氏名又は名称】ニシラ， インコーポレイテッド

(74)【代理人】

【識別番号】100076428

【弁理士】

【氏名又は名称】大塚 康徳

(74)【代理人】

【識別番号】100115071

【弁理士】

【氏名又は名称】大塚 康弘

(74)【代理人】

【識別番号】100112508

【弁理士】

【氏名又は名称】高柳 司郎

(74)【代理人】

【識別番号】100116894

【弁理士】

【氏名又は名称】木村 秀二

(74)【代理人】

【識別番号】100130409

【弁理士】

【氏名又は名称】下山 治

(74)【代理人】

【識別番号】100177390

【弁理士】

【氏名又は名称】大出 純哉

(72)【発明者】

【氏名】グンダ， ラックスミカント， ヴィタル

(72)【発明者】

【氏名】ポッデュテューリ， ヴィニス

【審査官】齊藤 貴孝

(56)【参考文献】

【文献】米国特許出願公開第２０１５／０３８１５７８（ＵＳ，Ａ１）

【文献】特表２０１６－５２４２４８（ＪＰ，Ａ）

【文献】特表２０１６－５１４２９５（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １６／００－１６／９５８

Ｇ０６Ｆ ２１／６２

Ｇ０６Ｆ １３／００

(57)【特許請求の範囲】

【請求項1】

複数のマシンと１つ以上のサービスエンジンのセットとが動作するホストコンピュータ上でコンテキストベースのサービスをサポートする方法であって、前記方法は、
前記ホストコンピュータ上で動作するコンテキストコレクタにおいて、
マシンのセット上で動作するゲストイントロスペクション・エージェントのセットからコンテキスト属性を収集することであって、前記収集されるコンテキスト属性は前記マシンのセット上で発生するイベントに関連する、ことと、
前記サービスエンジンのセットが前記イベントに関連付けられたデータメッセージフローの処理に使用するように、前記ホストコンピュータ上で動作する前記サービスエンジンのセットに、収集されたコンテキスト属性のセットを提供することと、
前記イベントの１つのために特定のサービスエンジンのための特定のサービスルールを生成することであって、前記特定のサービスエンジンは、少なくとも１つのデータメッセージフローにおけるサービス動作を実行するために前記特定のサービスルールを使用する、こととを含む方法。

【請求項2】

請求項１に記載の方法であって、前記特定のサービスルールを生成することは、前記サービスルールを生成するように前記特定のサービスエンジンに指示することを含む、方法。

【請求項3】

請求項１に記載の方法であって、前記特定のサービスルールを生成することは、前記コンテキストコレクタにおいて前記特定のサービスルールを生成し、前記生成したサービスルールを前記特定のサービスエンジンに提供することを含む、方法。

【請求項4】

請求項１に記載の方法であって、前記収集されたコンテキスト属性のセットを提供することは、
前記サービスエンジンのセットから、データメッセージフロー識別子を受信することと、
前記データメッセージフロー識別子を、前記コンテキストコレクタによって格納された収集されたコンテキスト属性セットとマッチングすることと、
前記受信したデータメッセージフロー識別子に応じて、マッチしている前記コンテキスト属性セットを前記サービスエンジンのセットに提供することであって、各サービスエンジンは、コンテキスト属性セットを用いて、前記サービスエンジンによって処理されるデータメッセージフローで前記サービスエンジンが実行すべきサービス動作を特定するサービスルールを識別する、こととを含む、方法。

【請求項5】

請求項１に記載の方法であって、前記収集されたコンテキスト属性のセットを提供することは、前記収集されたコンテキスト属性セットをデータメッセージフロー識別子にマッピングするマッピングレコードを、前記サービスエンジンのセットに提供することであって、各サービスエンジンは、前記処理されたデータメッセージフローに関連付けられたコンテキスト属性セットを識別するために、１つ以上のマッピングレコードを用いて処理する、ことと、前記識別されたコンテキスト属性セットを用いて、前記サービスエンジンによって処理されるデータメッセージフローで前記サービスエンジンが実行すべきサービス動作を特定するサービスルールを識別することとを含む、方法。

【請求項6】

請求項１に記載の方法であって、前記イベントは新たなネットワーク接続イベントを含む、方法。

【請求項7】

請求項１に記載の方法であって、前記イベントは新たな処理イベントを含む、方法。

【請求項8】

請求項１に記載の方法であって、前記マシンのセットは２つ以上のマシンを含む、方法。

【請求項9】

請求項１に記載の方法であって、前記コンテキスト属性を収集することは、フローに関連付けられた識別子と共にコンテキスト属性セットを受信することを含む、方法。

【請求項10】

請求項１に記載の方法であって、コンテキスト属性の複数のセットのそれぞれは、レイヤ２（Ｌ２）、レイヤ３（Ｌ３）及びレイヤ４（Ｌ４）データメッセージヘッダ値以外の１つ以上の属性を含む、方法。

【請求項11】

複数のマシンと１つ以上のサービスエンジンのセットとが動作するホストコンピュータ上でコンテキストベースのサービスをサポートするコンテキストコレクタプログラムを格納する機械可読媒体であって、前記コンテキストコレクタプログラムは、
マシンのセット上で動作するゲストイントロスペクション・エージェントのセットからコンテキスト属性を収集することであって、前記収集されるコンテキスト属性は前記マシンのセット上で発生するイベントに関連する、ことと、
前記サービスエンジンのセットが処理のために受信する前記イベントに関連付けられたデータメッセージフローについて、前記ホストコンピュータ上で動作する前記サービスエンジンのセットからデータメッセージフロー識別子を受信することと、
前記受信したデータメッセージフロー識別子に応じて、前記サービスエンジンのセットが前記イベントに関連付けられたデータメッセージフローの処理に使用するように、前記ホストコンピュータ上で動作する前記サービスエンジンのセットに前記収集されたコンテキスト属性のセットを提供すること
の命令のセットを含む、機械可読媒体。

【請求項12】

請求項１１に記載の機械可読媒体であって、前記コンテキストコレクタプログラムは更に、前記イベントの１つについての特定のサービスルールを生成するように特定のサービスエンジンに指示することであって、前記特定のサービスエンジンは、少なくとも１つのデータメッセージフローにおけるサービス動作を実行するために前記特定のサービスルールを使用する、ことの命令のセットを含む、機械可読媒体。

【請求項13】

請求項１１に記載の機械可読媒体であって、前記コンテキストコレクタプログラムは更に、前記イベントの１つについての特定のサービスルールを生成し、前記特定のサービスルールを特定のサービスエンジンに提供し、前記特定のサービスエンジンは、少なくとも１つのデータメッセージフローにおけるサービス動作を実行するために前記特定のサービスルールを使用する命令のセットを含む、機械可読媒体。

【請求項14】

請求項１１に記載の機械可読媒体であって、前記収集されたコンテキスト属性のセットを提供する前記命令のセットは、
前記データメッセージフロー識別子を、前記コンテキストコレクタプログラムによって格納された収集されたコンテキスト属性セットとマッチングすることと、
前記受信したデータメッセージフロー識別子に応じて、マッチしている前記コンテキスト属性セットを前記サービスエンジンのセットに提供することであって、各サービスエンジンは、コンテキスト属性セットを用いて、前記サービスエンジンによって処理されるデータメッセージフローで前記サービスエンジンが実行すべきサービス動作を特定するサービスルールを識別する、ことの命令のセットを含む、機械可読媒体。

【請求項15】

請求項１１に記載の機械可読媒体であって、前記収集されたコンテキスト属性のセットを提供する前記命令のセットは、前記収集されたコンテキスト属性セットをデータメッセージフロー識別子にマッピングするマッピングレコードを、前記サービスエンジンのセットに提供することであって、各サービスエンジンは、前記処理されたデータメッセージフローに関連付けられたコンテキスト属性セットを識別するために、１つ以上のマッピングレコードを用いて処理する、ことと、前記識別されたコンテキスト属性セットを用いて、前記サービスエンジンによって処理されるデータメッセージフローで前記サービスエンジンが実行すべきサービス動作を特定するサービスルールを識別することの命令のセットを含む、機械可読媒体。

【請求項16】

請求項１１に記載の機械可読媒体であって、前記イベントは新たなネットワーク接続イベントを含む、機械可読媒体。

【請求項17】

請求項１１に記載の機械可読媒体であって、前記イベントは新たな処理イベントを含む、機械可読媒体。

【請求項18】

請求項１１に記載の機械可読媒体であって、前記マシンのセットは２つ以上のマシンを含む、機械可読媒体。

【請求項19】

請求項１１に記載の機械可読媒体であって、前記サービスエンジンのセットのうちの各サービスエンジンは、前記コンテキストコレクタプログラムが提供する収集されたコンテキスト属性の受信済みセットを使用して、（ｉ）特定のデータメッセージフローに適用可能なコンテキストベースのサービスルールを識別し、（ｉｉ）前記識別されたコンテキストベースのサービスルールに基づいて、前記特定のデータメッセージフローにおけるコンテキストベースのサービスを実行する、機械可読媒体。

【請求項20】

請求項１１に記載の機械可読媒体であって、コンテキスト属性の複数のセットのそれぞれは、レイヤ２（Ｌ２）、レイヤ３（Ｌ３）及びレイヤ４（Ｌ４）データメッセージヘッダ値以外の１つ以上の属性を含む、機械可読媒体。

【請求項21】

コンピュータデバイスであって、
処理ユニットのセットと、
少なくとも１つの前記処理ユニットによって実施されると、請求項１から１０のいずれか１項に記載の方法を実施するプログラムを格納する機械可読媒体と、を含むコンピュータデバイス。

【請求項22】

少なくとも１つの処理ユニットで実行されると、請求項１から１０のいずれか１項に記載の方法を実施するコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

ホスト上のコンテキスト属性の収集と処理に関する。

【背景技術】

【0002】

ミドルボックスサービスは、歴史的に、企業またはデータセンタ内のネットワークトポロジ内の１以上のポイントで実施されるハードウェアアプライアンスであった。ソフトウェア定義ネットワーキング（SDN）およびネットワーク仮想化の出現により、従来のハードウェアアプライアンスは、SDNおよびネットワーク仮想化によって提供される柔軟性および制御を利用しない。したがって、近年、ホスト上でミドルボックスサービスを提供する様々な方法が提案されている。しかしながら、これらのミドルボックスソリューションのほとんどは、ホスト上の各データメッセージフローについてキャプチャされ得るリッチコンテキストデータを利用しない。この1つの理由は、既存の技術が、コンテキスト属性のずっと小さいセットに関して定義されたサービスルールを効率的に処理するために、何千ものキャプチャされたコンテキスト属性をフィルタリングするための効率的な分散スキームを提供しないことである。

【発明の概要】

【0003】

本発明のいくつかの実施形態は、１以上のマシンを実行するホストコンピュータ上でコンテキスト属性をキャプチャし、キャプチャされたコンテキスト属性を使用してホストコンピュータ上でサービスを実行するための新規なアーキテクチャを提供する。マシンは、いくつかの実施形態では仮想マシン（VM）であり、他の実施形態ではコンテナであり、さらに他の実施形態ではVMとコンテナの混合である。

【0004】

いくつかの実施形態は、コンテキスト属性をキャプチャする必要がある各マシン上でゲストイントロスペクション（guest-introspection:GI）エージェントを実行する。各ホストコンピュータ上で１以上のマシンを実行することに加えて、これらの実施形態は、各ホストコンピュータ上でコンテキストエンジンおよび１以上の属性ベースのサービスエンジンも実行する。いくつかの実施形態では、ホスト上のマシンのGIエージェントを介して、そのホストのコンテキストエンジンは、マシン上のネットワークイベントおよび／またはプロセスイベントに関連するコンテキスト属性を収集する。以下でさらに説明するように、コンテキストエンジンは、次いで、コンテキスト属性をサービスエンジンに提供し、サービスエンジンは、これらのコンテキスト属性を使用して、マシン上で実行されるプロセスおよび／またはマシンによって送信または受信されるデータメッセージフロー上で実行するためのコンテキストベースのサービスを指定するサービスルールを識別する。

【0005】

いくつかの実施形態では、ホストのコンテキストエンジンは、様々な異なる方法を介して、そのホスト上のマシンのGIエージェントからコンテキスト属性を収集する。例えば、いくつかの実施形態では、マシン上のGIエージェントは、すべての新しいネットワーク接続イベントおよびすべての新しいプロセスイベントのために、マシンのオペレーティングシステム内の１以上のモジュール（例えば、カーネル空間モジュールまたはユーザ空間モジュール）とフック（例えば、コールバック）を登録する。

【0006】

新しいネットワーク接続イベントが発生すると、GIエージェントは、OSからコールバックを受信し、このコールバックに基づいて、ネットワークイベント識別子をコンテキストエンジンに提供する。ネットワークイベント識別子は、ネットワークイベントに関係する属性のセットを提供する。いくつかの実施形態におけるこれらのネットワークイベント属性は、要求されたネットワーク接続の5タプル識別子（すなわち、ソースポートおよびIPアドレス、宛先ポートおよびIPアドレス、ならびにプロトコル）、ネットワーク接続を要求しているプロセスのプロセス識別子、要求しているプロセスに関連するユーザ識別子、および要求しているプロセスに関連するグループ識別子（たとえば、アクティビティディレクトリ（AD）識別子）を含む。

【0007】

いくつかの実施形態では、コンテキストエンジンは、ネットワークイベントと共に受け取ったプロセス識別子（ID）に関連する追加のプロセスパラメータをOSモジュールから収集するようにGIエージェントに指示する。いくつかの実施形態におけるこれらの追加のプロセスパラメータは、プロセス名、プロセスハッシュ、コマンドラインパラメータを有するプロセスパス、プロセスネットワーク接続、プロセスロードされたモジュール、および機械の１以上のリソースのプロセス消費（たとえば、中央処理装置の消費、ネットワーク消費、およびメモリ消費）を指定する１以上のプロセス消費パラメータを含む。ネットワークイベントに関連する追加のプロセスパラメータをGIエージェントに問い合わせるためにプロセス識別子を使用する代わりに、他の実施形態のコンテキストエンジンは、GIエージェントがネットワークイベントをコンテキストエンジンに報告するときに、ワンショットでネットワークイベントに関連する全てのプロセスパラメータを受信する。

【0008】

いくつかの実施形態では、マシン上のOSは、マシン上のGIエージェントがネットワークイベントの処理を続行するように指示するまで、新しいネットワークイベントを保留する（すなわち、ネットワークイベントのためのデータメッセージの送信を開始しない）。これらの実施形態のいくつかでは、GIエージェントは、コンテキストエンジンがこのイベントに必要なすべての属性を収集した後（例えば、新しいネットワークイベントに必要なすべてのプロセスまたはネットワーク属性をコンテキストエンジンが受信したことを指定するメッセージをコンテキストエンジンから受信した後）にのみ、OSがネットワークイベントの処理を進めることを可能にする。

【0009】

いくつかの実施形態では、コンテキストエンジンは、GIエージェントから受け取るプロセスハッシュを使用して、プロセスが属するアプリケーション（すなわち、ソフトウェア製品）の名前およびバージョンを識別する。これを行うために、いくつかの実施形態では、コンテキストエンジンは、プロセスハッシュおよび関連するアプリケーション名／バージョンを保存し、GIエージェントから受信したプロセスハッシュを保存されたプロセスハッシュと比較して、一致するハッシュを識別し、次いで、一致するハッシュのアプリケーション名／バージョンを、イベントに関連するプロセスのアプリケーション名およびバージョンとして使用する。

【0010】

いくつかの実施形態では、コンテキストエンジンは、別のデバイスまたはコンピュータ上で動作することができる１以上のネットワークまたは計算マネージャ（compute manager）からプロセスハッシュおよびアプリケーション名／バージョンを取得する。他の実施形態では、コンテキストエンジンは、プロセス識別子に関連付けられたハッシュをネットワークまたは計算マネージャに提供し、次いで、ネットワークまたは計算マネージャは、このハッシュをそのプロセスハッシュ記録に一致させ、関連付けられたプロセスのアプリケーション名／バージョンをコンテキストエンジンに提供する。コンテキストエンジンが、ネットワークイベントに関連するアプリケーション名／バージョンを取得すると、コンテキストエンジンは、名前およびバージョン属性を属性ベースのサービスエンジンに提供することができ、属性ベースのサービスエンジンは、この情報（すなわち、アプリケーション名および／またはバージョン）を使用して、実施すべきサービスルールを識別することができる。

【0011】

プロセスイベントが発生すると、GIエージェントは、OSからコールバックを受信し、このコールバックに基づいて、プロセスイベント識別子をコンテキストエンジンに提供する。プロセスイベント識別子は、プロセスイベントに関する属性のセットを提供する。いくつかの実施形態では、この属性のセットは、プロセス識別子を含む。いくつかの実施形態では、この設定はまた、ユーザ識別子および／またはグループ識別子（例えば、アクティビティディレクトリ（AD）識別子）を含む。

【0012】

いくつかの実施形態では、GIエージェントは、プロセスイベントをコンテキストエンジンに報告するときに、プロセスイベントに関連するすべてのプロセスパラメータ（例えば、プロセス識別子、ユーザID、グループID、プロセス名、プロセスハッシュ、ロードされたモジュール識別子、消費パラメータなど）をコンテキストエンジンに提供する。他の実施形態では、コンテキストエンジンは、プロセスイベントと共にコンテキストエンジンが受信したプロセス識別子に関連付けられた追加のプロセスパラメータをOSモジュールから収集するようにGIエージェントに指示する。いくつかの実施形態におけるこれらの追加のプロセスパラメータは、報告されたネットワークイベントについて上述したプロセスパラメータと同じ（例えば、プロセス名、プロセスハッシュ、ロードされたモジュール識別子、消費パラメータなど）である。

【0013】

いくつかの実施形態のコンテキストエンジンは、GIエージェントから受信するコンテキスト属性を、ホスト上で実行する他のモジュールから受信するコンテキスト属性で拡張する。例えば、いくつかの実施形態では、ディープパケットインスペクション（DPI）モジュールがホスト上で実行される。コンテキストエンジンまたは別のモジュール（例えば、ファイアウォールエンジン）は、このDPIエンジンに、プロセスIDに関連付けられたデータメッセージフローのデータメッセージを検査して、プロセスIDに関連付けられたアプリケーションによってこれらのデータメッセージで送信されているトラフィックのタイプを識別するように指示する。

【0014】

識別されたトラフィックタイプアイデンティティは、今日、一般にAppIDと呼ばれている。また、現在、データメッセージフローのメッセージを分析してAppIDを生成する多数のDPIモジュールがある。いくつかの実施形態では、コンテキストエンジンは、サービスエンジンがサービスを実行するために使用することができる非常に豊富な属性のセットを生成するために、ネットワークイベントについて取得したAppIDを、このイベントについて識別する他のコンテキスト属性と組み合わせる（例えば、AppIDを収集されたコンテキスト属性に関連付けるためにイベントの5タプル識別子を使用することによって）。この属性の豊富なセットは、真のアプリケーションアイデンティティ（すなわち、アプリケーション名、アプリケーションバージョン、アプリケーショントラフィックタイプなど）を提供し、それに基づいて、サービスエンジンは、それらのサービスを実行することができる。

【0015】

また、いくつかの実施形態では、脅威検出モジュールが、コンテキストエンジンとともにホストコンピュータ上で実行される。コンテキストエンジンが、プロセスがマシン上で開始したこと、またはマシン上でデータメッセージを送信していることを指定するプロセスパラメータのセットを取得すると、いくつかの実施形態では、コンテキストエンジンは、１以上のプロセスパラメータハッシュ、アプリケーション名、アプリケーションバージョン、AppID、他のプロセスパラメータなど）を脅威検出モジュールに提供する。次いで、この脅威検出モジュールは、識別されたプロセスの脅威レベルインジケータ（例えば、低、中、高など）を生成し、この脅威レベルインジケータをコンテキストエンジンに提供する。次いで、コンテキストエンジンは、この脅威レベルインジケータを、新しいプロセスイベントまたは新しいネットワークイベントのデータメッセージに対してサービスを実行するための別のコンテキスト属性として１以上のサービスエンジンに提供し、サービスエンジンは、脅威レベルインジケータを別の属性として使用して、実施すべきサービスルールを識別することができる。

【0016】

コンテキストエンジンは、いくつかの実施形態では、プッシュモデルを使用して、収集されたコンテキスト属性をサービスエンジンに配布し、他の実施形態では、プルモデルを使用して、これらの属性をサービスエンジンに配布する。さらに他の実施形態では、コンテンツエンジンは、いくつかのサービスエンジンのためのプッシュモデルと、他のサービスエンジンのためのプルモデルとを使用する。プッシュモデルでは、コンテキストエンジンは、プロセスの識別子および／またはネットワークイベントのフロー識別子（たとえば、フローの5タプル識別子）を有するプロセスイベントまたはネットワークイベントについて収集するコンテキスト属性をサービスエンジンに配信する。いくつかの実施形態では、コンテキストエンジンは、そのサービスエンジンのサービスルールに関連するコンテキスト属性のみをサービスエンジンに配信する。

【0017】

プルモデルでは、コンテキストエンジンは、特定のプロセスまたはネットワーク接続についてコンテキストエンジンが収集したコンテキスト属性について、サービスエンジンから照会を受け取る。いくつかの実施形態では、コンテキストエンジンは、プロセスIDまたはフロー識別子（例えば、5タプル識別子）をクエリとともにサービスエンジンから受信し、受信した識別子を使用して、サービスエンジンに提供しなければならない属性セットを識別する。いくつかの実施形態では、コンテキストエンジンは、サービスエンジンに関連する属性の収集のためのサービストークン（サービスタグとも呼ばれる）を生成し、このサービストークンを別のモジュール（例えば、GIエージェントまたはホスト上の別のモジュール）に提供して、サービスエンジンに渡す（例えば、データメッセージのカプセル化ヘッダに渡す）。次に、サービスエンジンは、サービストークンを抽出し、このサービストークンをコンテキストエンジンに提供して、コンテキストエンジンがサービスエンジンに提供しなければならないコンテキスト属性を識別する。

【0018】

いくつかの実施形態におけるコンテキストエンジンは、コンテキスト属性を、そのホストコンピュータ上のいくつかのコンテキストベースのサービスエンジンに提供する。いくつかの実施形態では、コンテキストエンジンおよびサービスエンジンは、すべて、複数のVMまたはコンテナが実行されるハイパーバイザのカーネルスペース構成要素である。他の実施形態では、コンテキストエンジンおよび／または１以上のサービスエンジンは、ユーザ空間プロセスである。例えば、いくつかの実施形態における1つ以上のサービスエンジンは、サービスVM（SVM）である。

【0019】

異なる実施形態は、異なるタイプのコンテキストベースのサービスエンジンを使用する。例えば、いくつかの実施形態では、属性ベースのサービスエンジンは、（1）マシンによって送信された、またはマシンのために受信されたデータメッセージに対してコンテキストベースのファイアウォール動作を実行するファイアウォールエンジンと、（2）マシン上で開始されたプロセスに対してコンテキストベースのプロセス制御動作（例えば、プロセス評価および終了動作）を実施するプロセス制御エンジンと、（3）マシンからのデータメッセージフローを１以上の宛先／サービスノードクラスタ内の異なる宛先またはサービスノードに分配するためにコンテキストベースのロードバランシング動作を実行するロードバランシングエンジンと、（4）マシンからのデータメッセージを暗号化するための、またはマシンのために受信したデータメッセージを復号化するためのコンテキストベースの暗号化または復号化動作を実行する暗号化エンジンとを含む。

【0020】

いくつかの実施形態における別のコンテキストベースのサービスエンジンは、ディスカバリサービスエンジンである。いくつかの実施形態では、ディスカバリエンジンは、コンテキストエンジンがこれらのプロセスおよびネットワークイベントについて収集するコンテキスト属性とともに、コンテキストエンジンから新しいプロセスイベントおよび新しいネットワークイベントをキャプチャする。次いで、ディスカバリサービスエンジンは、これらのイベントおよびそれらの関連するコンテキスト属性を、ネットワーク管理者がデータセンタ内のイベントを視覚化し、データセンタ内の計算およびネットワークリソースのためのポリシーを指定することを可能にする管理レイヤを提供する１以上のネットワークマネージャ（たとえば、サーバ）に中継する。

【0021】

これらのイベントおよび属性をネットワーク管理レイヤに中継する際に、いくつかの実施形態のディスカバリモジュールは、これらのイベントおよび属性のいくつかの前処理を実行する。例えば、いくつかの実施形態では、ディスカバリモジュールは、これらのイベントおよびそれらの属性のいくつかまたはすべてを集約しながら、ネットワークまたはプロセスイベントのいくつかをフィルタリングする。また、いくつかの実施形態では、ディスカバリエンジンは、GIエージェントまたは他のモジュール（例えば、DPIエンジンまたは脅威検出エンジン）を介してプロセスまたはネットワークイベントのための追加のコンテキスト属性を収集するように、またはファイルイベントおよびシステムイベントなどの他のタイプのイベントをキャプチャするように、コンテキストエンジンに指示する。

【0022】

例えば、いくつかの実施形態では、ディスカバリエンジンは、マシン上にインストールされたアプリケーションのインベントリを構築し、このインベントリを定期的にリフレッシュするようにコンテキストエンジンに指示する。ディスカバリエンジンは、管理プレーンの要求時に、または管理プレーンまたは制御プレーンがディスカバリエンジンのために指定する動作構成に基づいて、コンテキストエンジンにそのように指示することができる。ディスカバリエンジンからの要求に応答して、いくつかの実施形態では、コンテキストエンジンは、そのホストのマシンのそれぞれの上の各GIエージェントに、マシン上のすべてのインストールされたプロセス、ならびにすべての実行中のプロセスおよびサービスをディスカバリさせる。

【0023】

インストールされたアプリケーションおよび実行中のプロセス／サービスのインベントリを構築した後、データセンタ内のホストコンピュータのディスカバリエンジンは、この情報を管理プレーン内のネットワーク／コンピューティングマネージャに提供する。いくつかの実施形態では、管理プレーンは、ホストコンピュータディスカバリエンジンおよびコンテキストエンジン以外の送信元からコンテキスト属性を収集する。たとえば、いくつかの実施形態では、管理プレーンは、１以上のサーバからの計算コンテキスト（たとえば、クラウドベンダからのクラウドコンテキスト、またはデータセンタ仮想化ソフトウェアによる計算仮想化コンテキスト）、ディレクトリサービスサーバからの識別コンテキスト、モビリティ管理サーバからのモビリティコンテキスト、DNS(ドメインネームサーバ）およびアプリケーションインベントリサーバからのエンドポイントコンテキスト、ネットワーク仮想化サーバからのネットワークコンテキスト（たとえば、仮想化ネットワークコンテキスト）を収集する。

【0024】

コンテキスト情報（例えば、ディスカバリエンジンおよびコンテキストエンジンからの情報、および／または他のコンテキストソースからの情報）を収集することによって、管理プレーンは、ネットワーク／計算管理者にユーザインターフェースを提供して、データセンタ内の計算およびネットワークリソースを視覚化することができる。さらに、収集されたコンテキスト属性は、管理プレーンが、これらの管理者がコンテキストベースのサービスルールおよび／またはポリシーを指定するために、このユーザインターフェースを介して制御を提供することを可能にする。次いで、これらのサービスルール／ポリシーは、これらのコンピュータ上のサービスエンジンがコンテキストベースのサービス操作を実行できるように、ホストコンピュータに配信される。

【0025】

先行するサマリは、本発明のいくつかの実施形態に対する簡単な導入として提供されることを意図するものである。本書面において開示される発明の主題の全ての紹介又は概要を意味するものではない。以下の詳細な説明および詳細な説明において参照される図面は、他の実施形態とサマリにおいて説明された実施形態を更に説明するであろう。従って、本書面によって説明される全ての実施形態を理解するため、サマリ、詳細な説明、図面およびクレームの十分な確認が必要である。さらに、特許請求の範囲に記載される主題は、概要、詳細な説明、および図面における例示的な詳細によって限定されるべきではない。

【図面の簡単な説明】

【0026】

本発明の新規な特徴は添付の特許請求の範囲によって明らかになる。しかしながら、説明の目的のため、本発明のいくつかの実施形態は以下の図において明らかになる。

【0027】

【図1】図1は、本発明のいくつかの実施形態のコンテキストエンジンおよびコンテキストベースのサービスエンジンを使用するホストコンピュータを示す。

【0028】

【図2】図2は、いくつかの実施形態において、データセンタにおいてコンテキストリッチ（context-rich）な属性ベースのサービスを構成し、実行するための分散アーキテクチャを確立するために使用される、ホストコンピュータのより詳細な例を示す。

【0029】

【図3】図3は、いくつかの実施形態のコンテキストエンジンによって実行されるプロセスを示す。

【0030】

【図4】図4は、いくつかの実施形態のロードバランシングルールの例を示す。

【0031】

【図5】図5は、いくつかのアプリケーションサーバ間の信頼できないウェブサーバトラフィックのいくつかの実施形態のロードバランサを示す。

【0032】

【図6】図6は、いくつかの実施形態においてロードバランサが実行するプロセスを示す。

【0033】

【図7】図7は、そのようなファイアウォールルールのいくつかの例を示す。

【0034】

【図8】図8は、いくつかの実施形態のコンテキストベースのファイアウォールルールのいくつかのより詳細な例を示す。

【0035】

【図9】、

【図10】、

【図11】、

【図12】図9～12は、ファイアウォールエンジンによる様々なコンテキストベースのファイアウォールルールの実施を示す様々な例を示す。

【0036】

【図13】図13は、コンテキストエンジンが、GIエージェントから新しいネットワーク接続イベントを受信するたびに、ユーザ識別子およびグループ識別子を収集するために実行するプロセスを示す。

【0037】

【図14】図14は、いくつかの実施形態においてファイアウォールエンジンが実行するプロセスを示す。

【0038】

【図15】図15は、そのようなコンテキストベースの暗号化ルールの例を示す。

【0039】

【図16】図16は、いくつかの実施形態の暗号器が、ホスト上のVMによって送信されたデータメッセージを暗号化するために実行するプロセスを示す。

【0040】

【図17】図17は、転送要素ポートがデータメッセージの宛先VMを実行する宛先ホスト上で受信する暗号化されたデータメッセージを、暗号化エンジンが解読するために実行するプロセスを示す。

【0041】

【図18】図18は、暗号化エンジンが、そのヘッダに鍵識別子を含む暗号化データメッセージを復号化するために実行するプロセスを示す。

【0042】

【図19】図19は、プロセス制御ルールのいくつかの例を示す。

【0043】

【図20】図20は、いくつかの実施形態においてプロセス制御エンジンが実行するプロセスを示す。

【0044】

【図21】図21は、いくつかの実施形態においてサービスエンジンがどのように管理されるかの例を示す。

【0045】

【図22】図22は、本発明のいくつかの実施形態が実装されるコンピュータシステムを概念的に示す。

【発明を実施するための形態】

【0046】

本発明の以下の詳細な説明では、本発明の多くの詳細、例、および実施例が説明され、記載される。しかしながら、本発明は、説明された実施形態に限定されず、本発明は、説明された特定の詳細および例のいくつかなしに実施されてもよいことが、当業者には明らかであり、明確であろう。

【0047】

本発明のいくつかの実施形態は、１以上のマシンを実行するホストコンピュータ上でコンテキスト属性をキャプチャし、キャプチャされたコンテキスト属性を使用してホストコンピュータ上でサービスを実行するための新規なアーキテクチャを提供する。いくつかの実施形態は、コンテキスト属性をキャプチャする必要がある各マシン上でゲストイントロスペクション（guest-introspection：GI）エージェントを実行する。各ホストコンピュータ上で１以上のマシンを実行することに加えて、これらの実施形態は、各ホストコンピュータ上でコンテキストエンジンおよび１以上の属性ベースのサービスエンジンも実行する。いくつかの実施形態では、ホスト上のマシンのGIエージェントを介して、そのホストのコンテキストエンジンは、マシン上のネットワークイベントおよび／またはプロセスイベントに関連するコンテキスト属性を収集する。次に、コンテキストエンジンは、コンテキスト属性をサービスエンジンに提供し、サービスエンジンは、これらのコンテキスト属性を使用して、マシン上で実行中のプロセスおよび／またはマシンによって送信または受信されるデータメッセージフロー上で実行するためのコンテキストベースのサービスを指定するサービスルールを識別する。

【0048】

本明細書で使用されるように、データメッセージは、ネットワークを介して送信される特定のフォーマットのビットの集合を指す。当業者は、データメッセージという用語が、本明細書では、イーサネット（登録商標）フレーム、IPパケット、TCPセグメント、UDPデータグラムなど、ネットワークを介して送信され得る様々なフォーマットされたビットの集合を指すために使用され得ることを理解するであろう。また、本明細書で使用されるように、L2、L3、L4、およびL7層（または層2、層3、層4、層7）への参照は、それぞれ、OSI (Open System Interconnection)層モデルの第2のデータリンク層、第3のネットワーク層、第4のトランスポート層、および第7のアプリケーション層への参照である。

【0049】

図1は、本発明のいくつかの実施形態のコンテキストエンジンおよびコンテキストベースのサービスエンジンを使用するホストコンピュータ100を示す。図示のように、ホストコンピュータ100は、いくつかのデータ計算ノード105、コンテキストエンジン110、いくつかのコンテキストベースのサービスエンジン130、脅威検出器132、およびディープパケットインスペクション（DPI）モジュール135を含む。コンテキストベースのサービスエンジンは、ディスカバリエンジン120、プロセス制御エンジン122、暗号化エンジン124、ロードバランサ126、およびファイアウォールエンジン128を含む。また、コンテキストベースのサービスルール記憶装置140、および属性記憶装置145も含む。

【0050】

DCNは、ホストコンピュータ100上で実行されるエンドポイント機械である。DCNは、いくつかの実施形態では仮想マシン（VM）であり、他の実施形態ではコンテナであり、さらに他の実施形態ではVMとコンテナの混合である。各DCN上で、GIエージェント150は、コンテキストエンジン110のコンテキスト属性を収集するために実行する。いくつかの実施形態では、コンテキストエンジン110は、様々な異なる方法を介して、そのホスト上のDCNのGIエージェント150からコンテキスト属性を収集する。たとえば、いくつかの実施形態では、DCN上のGIエージェントは、すべての新しいネットワーク接続イベントおよびすべての新しいプロセスイベントのために、DCNのオペレーティングシステム内の１以上のモジュール（たとえば、カーネル空間モジュールまたはユーザ空間モジュール）にフック（たとえば、コールバック）を登録する。

【0051】

新しいネットワーク接続イベントが発生すると、GIエージェント150は、そのDCNのOSからコールバックを受信し、このコールバックに基づいて、ネットワークイベント識別子をコンテキストエンジン110に提供する。ネットワークイベント識別子は、ネットワークイベントに関係する属性のセットを提供する。いくつかの実施形態におけるこれらのネットワークイベント属性は、要求されたネットワーク接続の5タプル識別子（すなわち、ソースポートおよびIPアドレス、宛先ポートおよびIPアドレス、ならびにプロトコル）、ネットワーク接続を要求しているプロセスのプロセス識別子、要求しているプロセスに関連するユーザ識別子、および要求しているプロセスに関連するグループ識別子（たとえば、アクティビティディレクトリ（AD）識別子）を含む。

【0052】

いくつかの実施形態では、コンテキストエンジンは、ネットワークイベントと共に受け取ったプロセス識別子（ID）に関連する追加のプロセスパラメータをOSモジュールから収集するようにGIエージェント150に指示する。いくつかの実施形態におけるこれらの追加のプロセスパラメータは、プロセス名、プロセスハッシュ、コマンドラインパラメータを有するプロセスパス、プロセスネットワーク接続、プロセスロードされたモジュール、および機械の１以上のリソースのプロセス消費（たとえば、中央処理装置消費、ネットワーク消費、およびメモリ消費）を指定する１以上のプロセス消費パラメータを含む。ネットワークイベントに関連する追加のプロセスパラメータについてGIエージェント150に問い合わせるためにプロセス識別子を使用する代わりに、他の実施形態のコンテキストエンジン110は、GIエージェントがネットワークイベントをコンテキストエンジンに報告するときに、ワンショットでネットワークイベントに関連する全てのプロセスパラメータを受信する。

【0053】

いくつかの実施形態におけるDCNのOSは、そのDCN上のGIエージェント150が、ネットワークイベントの処理を進めるようにDCNに指示するまで、新しいネットワークイベントを保留する（すなわち、ネットワークイベントのためのデータメッセージの送信を開始しない）。これらの実施形態のいくつかでは、GIエージェント150は、コンテキストエンジン110がこのイベントに必要なすべての属性を収集した後（例えば、新しいネットワークイベントに必要なすべてのプロセスまたはネットワーク属性をコンテキストエンジンが受信したことを指定するメッセージをコンテキストエンジンから受信した後）にのみ、OSがネットワークイベントの処理を進めることを可能にする。

【0054】

いくつかの実施形態では、コンテキストエンジン110は、GIエージェント150から受け取るプロセスハッシュを使用して、プロセスが属するアプリケーション（すなわち、ソフトウェア製品）の名前およびバージョンを識別する。これを行うために、いくつかの実施形態では、コンテキストエンジン110は、プロセスハッシュおよび関連するアプリケーション名／バージョンを保存し、GIエージェントから受信したプロセスハッシュを保存されたプロセスハッシュと比較して、一致するハッシュを識別し、次いで、一致するハッシュのアプリケーション名／バージョンを、イベントに関連するプロセスのアプリケーション名およびバージョンとして使用する。

【0055】

いくつかの実施形態では、コンテキストエンジン110は、別のデバイスまたはコンピュータ上で動作することができる１以上のネットワークまたは計算マネージャからプロセスハッシュおよびアプリケーション名／バージョンを取得する。他の実施形態では、コンテキストエンジンは、プロセス識別子に関連付けられたハッシュをネットワークまたは計算マネージャに提供し、次いで、ネットワークまたは計算マネージャは、このハッシュをそのプロセスハッシュ記録に一致させ、関連付けられたプロセスのアプリケーション名／バージョンをコンテキストエンジンに提供する。コンテキストエンジン110は、ネットワークイベントに関連するアプリケーション名／バージョンを取得すると、名前およびバージョン属性を属性ベースのサービスエンジンに提供することができ、属性ベースのサービスエンジンは、この情報（すなわち、アプリケーション名および／またはバージョン）を使用して、実施すべきサービスルールを識別することができる。

【0056】

DCN 105上でプロセスイベントが発生すると、DCNのGIエージェント150は、いくつかの実施形態では、DCNのOSからコールバックを受信し、このコールバックに基づいて、プロセスイベント識別子をコンテキストエンジン110に提供する。プロセスイベント識別子は、プロセスイベントに関する属性のセットを提供する。いくつかの実施形態では、この属性のセットは、プロセス識別子を含む。いくつかの実施形態では、この設定はまた、ユーザ識別子および／またはグループ識別子（例えば、アクティビティディレクトリ（AD）識別子）を含む。

【0057】

いくつかの実施形態では、GIエージェントは、プロセスイベントをコンテキストエンジンに報告するときに、プロセスイベントに関連するすべてのプロセスパラメータ（例えば、プロセス識別子、ユーザID、グループID、プロセス名、プロセスハッシュ、ロードされたモジュール識別子、消費パラメータなど）をコンテキストエンジンに提供する。他の実施形態では、コンテキストエンジンは、プロセスイベントと共にコンテキストエンジンが受信したプロセス識別子に関連付けられた追加のプロセスパラメータをOSモジュールから収集するようにGIエージェントに指示する。いくつかの実施形態におけるこれらの追加のプロセスパラメータは、報告されたネットワークイベントについて上述したプロセスパラメータと同じ（例えば、プロセス名、プロセスハッシュ、ロードされたモジュール識別子、消費パラメータなど）である。

【0058】

いくつかの実施形態のコンテキストエンジン110は、GIエージェント150から受信するコンテキスト属性を、ホスト上で実行する他のモジュールから受信するコンテキスト属性で拡張する。DPIモジュール135（ディープパケットインスペクタとも呼ばれる）および脅威検出器132（脅威検査モジュールとも呼ばれる）は、コンテキストエンジンがGIエージェント150から収集する属性を拡張するためのコンテキスト属性を提供する2つのそのようなモジュールである。いくつかの実施形態では、DPIモジュールは、コンテキストエンジン110または別のモジュール（例えば、ファイアウォールエンジン128）によって、プロセスIDに関連付けられたデータメッセージフローのデータメッセージを検査して、プロセスIDに関連付けられたアプリケーションによってこれらのデータメッセージで送信されているトラフィックのタイプを識別するように指示される。

【0059】

識別されたトラフィックタイプアイデンティティは、今日、一般にAppIDと呼ばれている。また、現在、データメッセージフローのメッセージを分析して、データメッセージフローのAppIDを生成する多数のDPIモジュールがある。いくつかの実施形態では、コンテキストエンジンは、ネットワークイベントのために取得したAppIDを、このイベントのために識別する他のコンテキスト属性と組み合わせて、サービスエンジンがそのサービスを実行するために使用することができる属性の非常に豊富なセットを生成する。この属性の豊富なセットは、真のアプリケーションアイデンティティ（すなわち、アプリケーション名、アプリケーションバージョン、アプリケーショントラフィックタイプなど）を提供し、それに基づいて、サービスエンジンは、それらのサービスを実行することができる。いくつかの実施形態では、コンテキストエンジン110は、ネットワークイベントの5タプル識別子を使用して、このイベントのデータメッセージフローのAppIDを、コンテキストエンジンが（例えば、データメッセージフローが発信されるDCNの）データメッセージフローに関連付けられたDCNのGIエージェントから収集するコンテキスト属性に関連付ける。

【0060】

脅威検出器132は、DCN上で実行されている特定のアプリケーションに関連する脅威レベルを指定する脅威レベルインジケータを提供する。コンテキストエンジンが、プロセスがマシン上で始動したこと、またはマシン上でデータメッセージを送信していることを指定するプロセスパラメータのセットを取得すると、いくつかの実施形態では、コンテキストエンジンは、１以上のプロセスパラメータハッシュ、アプリケーション名、アプリケーションバージョン、AppID、他のプロセスパラメータなど）を脅威検出モジュールに提供する。

【0061】

次いで、この脅威検出モジュールは、識別されたプロセスの脅威レベルインジケータ（例えば、低、中、高など）を生成し、この脅威レベルインジケータをコンテキストエンジンに提供する。いくつかの実施形態では、脅威検出器は、（1）悪い入力妥当性検査を行うかどうか、（2）暗号化されていないネットワークリンクを介して認証証明書を渡すかどうか、（3）弱いパスワードおよびアカウントポリシーを使用するかどうか、（4）構成秘密を平文で保存するかどうか、（5）ファイルを転送できるかどうか、（6）アプリケーションがマルウェアを伝播することが知られているかどうか、（7）アプリケーションが意図的に回避的であるかどうか、（8）アプリケーションが既知の脆弱性を有するかどうかなどの様々なアプリケーションの振る舞い事由に基づいて、DCN上で実行されているアプリケーションに脅威スコアを割り当てる。いくつかの実施形態では、脅威検出器は、Bit9などのサードパーティのホワイトリスティングアプリケーション（third-party whitelisting application）である。

【0062】

コンテキストエンジンは、いくつかの実施形態では、脅威検出器132によって生成された脅威レベルインジケータを、新しいプロセスイベントまたは新しいネットワークイベントのデータメッセージに対してサービスを実行するための別のコンテキスト属性として１以上のサービスエンジンに提供し、サービスエンジンは、脅威レベルインジケータを別の属性として使用して、実施すべきサービスルールを識別することができる。

【0063】

コンテキストエンジン110は、ネットワークイベントおよびプロセスイベントについて収集したコンテキスト属性を属性記憶装置145に保存する。いくつかの実施形態では、コンテキストエンジンは、１以上のネットワークイベント識別子および／またはプロセス識別子を有するコンテキスト属性の各セットを保存する。例えば、いくつかの実施形態では、コンテキストエンジン110は、プロセス識別子を用いて、またはこの識別子への参照を用いて、新しいプロセスイベントについて収集されたコンテキスト属性を保存する。次いで、コンテキストエンジンは、プロセス識別子を使用して、収集されたコンテキスト属性を、プロセスイベントのためのサービスを実行するサービスエンジン（例えば、プロセス制御エンジン122）に提供する。

【0064】

コンテキストエンジンは、いくつかの実施形態では、ネットワーク接続イベントの5タプル識別子を用いて、またはこの5タプル識別子への参照を用いて、新しいネットワーク接続イベントのために収集されたコンテキスト属性を保存する。これらの実施形態のいくつかでは、コンテキストエンジンは、このイベントの5タプル識別子とともに、ネットワークイベントのコンテキスト属性をサービスエンジンに提供する。このネットワークイベントのデータメッセージは、この5タプル識別子を使用し、したがって、サービスエンジンは、供給された5タプル識別子を使用して、データメッセージフローに関連するコンテキスト属性を識別することができる。

【0065】

コンテキストエンジンは、いくつかの実施形態では、プッシュモデルを使用して、収集されたコンテキスト属性をサービスエンジン130に配布し、他の実施形態では、このエンジンは、プルモデルを使用して、これらの属性をサービスエンジン130に配布する。さらに他の実施形態では、コンテキストエンジンは、いくつかのサービスエンジンのためのプッシュモデルと、他のサービスエンジンのためのプルモデルとを使用する。プッシュモデルでは、いくつかの実施形態におけるコンテキストエンジンは、プロセスの識別子および／またはネットワークイベントのフロー識別子（例えば、フローの5タプル識別子）を有するプロセスイベントまたはネットワークイベントについて収集するコンテキスト属性をサービスエンジンに配信する。

【0066】

いくつかの実施形態では、コンテキストエンジンは、そのサービスエンジンのサービスルールに関連するコンテキスト属性のみをサービスエンジンに配信する。言い換えると、これらの実施形態では、コンテキストエンジンは、（例えば、ネットワークイベントまたはプロセスイベントのための）収集された属性のセット内の各収集された属性を、サービスエンジンのサービスルールによって使用される属性のリストと比較し、サービスルールによって使用されない各収集された属性を破棄する。次いで、コンテキストエンジンは、エンジンのサービスルールによって使用されている（収集された属性の設定内の）収集された属性のサブ設定のみをサービスエンジンに提供する。他の実施形態では、サービスエンジンは、このフィルタリング動作を実行して、必要とされないコンテキスト属性を破棄する。

【0067】

プルモデルでは、コンテキストエンジンは、特定のプロセスまたはネットワーク接続についてコンテキストエンジンが収集したコンテキスト属性について、サービスエンジンからクエリ（照会）を受け取る。いくつかの実施形態では、コンテキストエンジンは、プロセスIDまたはフロー識別子（例えば、5タプル識別子）をクエリとともにサービスエンジンから受信し、受信した識別子を使用して、サービスエンジンに提供しなければならない属性セットを識別する。

【0068】

いくつかの実施形態では、コンテキストエンジンは、サービスエンジンに関連する属性を収集するためのサービストークン（サービスタグとも呼ばれる）を生成し、このサービストークンを別のモジュール（例えば、GIエージェントまたはホスト上の別のモジュール）に提供して、サービスエンジンに渡す（例えば、データメッセージのカプセル化ヘッダに渡す）。次に、サービスエンジンは、サービストークンを抽出し、このサービストークンをコンテキストエンジンに提供して、コンテキストエンジンがサービスエンジンに提供しなければならないコンテキスト属性を識別する。

【0069】

いくつかの実施形態では、コンテキストエンジン110およびサービスエンジン130は、図2を参照して以下でさらに説明するように、複数のVMまたはコンテナが実行されるハイパーバイザのすべてのカーネルスペース構成要素である。他の実施形態では、コンテキストエンジンおよび／または１以上のサービスエンジンは、ユーザ空間プロセスである。例えば、いくつかの実施形態における1つ以上のサービスエンジンは、サービスVM（SVM）である。いくつかの実施形態では、１以上のサービスエンジンは、DCNへのおよびDCNからのデータメッセージフローへのアクセスを受信して、これらのデータメッセージフロー上でサービスを実行するために、DCNの入口データパスおよび／または出口データパス内にある。他の実施形態では、ホスト100上の１以上の他のモジュールが、入口／出口データパスからのデータメッセージをインターセプトし、これらのメッセージを、これらのエンジンがデータメッセージに対してサービスを実行するための１以上のサービスエンジンに転送する。そのようなアプローチの1つを、図2を参照して以下に説明する。

【0070】

異なる実施形態は、異なるタイプのコンテキストベースのサービスエンジンを使用する。図1に示す例では、サービスエンジン130は、ディスカバリエンジン120、プロセス制御エンジン122、暗号化エンジン124、ロードバランサ126、およびファイアウォールエンジン128を含む。これらのサービスエンジン130の各々は、属性ベースのサービスルール記憶装置を有する。図1は、この図に示される例示を簡略化するために、これらのサービスエンジンのすべてのコンテキストベースのサービスルール記憶装置を、コンテキストベースのサービスルール記憶装置140と共に集合的に表す。

【0071】

いくつかの実施形態では、コンテキストベースのサービスルール記憶装置140内の各サービスルールは、プロセスまたはネットワークイベントのために実施すべきルールを識別するために、プロセスまたはフロー識別子とマッチングするためのルール識別子を有する。いくつかの実施形態では、コンテキストベースのサービスルール記憶装置140は、より低い優先順位のルールに一致する前に、ルールチェックがより高い優先順位のルールに一致することを保証するために、階層的な方法で定義される。また、いくつかの実施形態では、コンテキストベースサービスルール記憶装置140は、以下でさらに説明するように、任意のルールチェックのためのデフォルトアクションを指定するデフォルトルールを含む。

【0072】

ファイヤウォールエンジン128は、DCN105によって送信された、またはDCN105のために受信されたデータメッセージに対してファイアウォール動作を実行する。これらのファイアウォール動作は、コンテキストベースのサービスルール記憶装置140内のファイアウォールルールに基づいている。ファイアウォールルールのいくつかは、純粋にレイヤ2～レイヤ4属性に関して、例えば、5タプル識別子に関して定義される。他のファイアウォールルールは、アプリケーション名、アプリケーションバージョン、AppID、リソース消費、脅威レベル、ユーザID、グループIDなど、収集されたコンテキスト属性のうちの１以上を含むことができるコンテキスト属性に関して定義される。いくつかの実施形態におけるさらに他のファイアウォールルールは、L2～L4パラメータおよびコンテキスト属性の両方に関して定義される。ファイアウォールエンジン128は、コンテキスト属性を参照することによって定義されるファイアウォールルールを解決することができるので、このファイアウォールエンジンは、コンテキストベースのファイアウォールエンジンと呼ばれる。

【0073】

いくつかの実施形態では、コンテキストベースのファイアウォールエンジン128は、そのファイアウォールルールが収集されたコンテキスト属性の任意の組合せに関して識別され得るので、任意の数のコンテキスト属性に基づいてデータメッセージフローを許可、ブロック、または再ルーティングすることができる。例えば、このファイアウォールエンジンは、ユーザが看護師ユーザグループ（Nurse user group）の一部であり、1つのファイアウォールルールが、フローが看護師グループID（Nurse group ID）に関連付けられているときにデータメッセージをブロックすべきであると指定し、AppIDが、トラフィックタイプを電子メールとして識別し、アプリケーション名がChromeであるとき、crome．exeからのすべての電子メールトラフィックをブロックすることができる。同様に、コンテキストベースのファイアウォールルールは、ビデオ会議、オンラインビデオ視聴、またはソフトウェアの古いバージョンの使用に関連するデータメッセージフローをブロックすることができる。そのようなルールの例は、すべてのSkypeトラフィックをブロックし、すべてのYouTubeビデオトラフィックをブロックし、アプリケーションバージョン番号が特定のバージョン番号よりも古いときにすべてのHipChatオーディオ／ビデオ会議をブロックし、高い脅威スコアを有する任意のアプリケーションのためのデータメッセージフローをブロックするなどである。

【0074】

ロードバランシングエンジン126は、DCN105によって送信されたデータメッセージに対してロードバランシング操作を実行して、データメッセージフローを１以上の宛先／サービスノードクラスタ内の異なる宛先またはサービスノードに分配する。これらのロードバランシング動作は、コンテキストベースのサービスルール記憶装置140内のロードバランシングルールに基づいている。これらの実施形態のいくつかでは、各ロードバランシングルールは、トラフィックを分散させるための１以上のロードバランシング基準（たとえば、ラウンドロビン基準、重み付きラウンドロビン基準など）を指定することができ、各基準を特定の時間範囲に制限することができる。いくつかの実施形態では、ロードバランシング動作は、データメッセージフローの宛先ネットワークアドレス（例えば、宛先IPアドレス、宛先MACアドレスなど）を別の宛先ネットワークアドレスで置き換えることを含む。

【0075】

ロードバランシングルールのいくつかは、純粋にL2～L4属性に関して、例えば、5タプル識別子に関して定義される。他のロードバランシングルールは、アプリケーション名、アプリケーションバージョン、AppID、リソース消費、脅威レベル、ユーザID、グループIDなど、収集されたコンテキスト属性のうちの１以上を含むことができるコンテキスト属性に関して定義される。いくつかの実施形態におけるさらに他のロードバランシングルールは、L2～L4パラメータおよびコンテキスト属性の両方に関して定義される。ロードバランシングエンジン126は、コンテキスト属性を参照することによって定義されるロードバランシングルールを解決することができるので、このロードバランシングエンジンは、コンテキストベースのロードバランサと呼ばれる。

【0076】

いくつかの実施形態では、コンテキストベースのロードバランサ126は、任意の数のコンテキスト属性に基づいてデータメッセージフローを分散することができるが、これは、そのロードバランシングルールを、収集されたコンテキスト属性の任意の組合せに関して識別することができるからである。例えば、ロードバランサ126のデータ分散は、ユーザデータとアプリケーションデータの任意の組合せに基づくことができる。このようなロードバランシング動作の例は、（1）全てのロードバランシングプール上で金融部門に関連するデータメッセージフローを分配すること、（2）この部門のトラフィックを高可用性にするために、全ての金融部門のトラフィックを、この部門の1次プールがダウンしているときに別のプールにリダイレクトすること、および（3）医師のユーザグループ（Doctor's user group）に関連する全てのトラフィックを高可用性にすることを含む。いくつかの実施形態では、ロードバランシングルールは、DCN上の多くのリソースを消費するアプリケーションに、より多くのまたはより少ないリソースを提供するために、トラフィックを分散するために、収集されたリソース消費に関して定義されることも可能である。

【0077】

暗号化エンジン124は、DCN105によって送受信されるデータメッセージに対して、暗号化／復号化操作（集合的に暗号化操作と呼ばれる）を実行する。これらの暗号化動作は、コンテキストベースのサービスルール記憶装置140内の暗号化ルールに基づく。いくつかの実施形態では、これらのルールの各々は、暗号化／復号化鍵識別子を含み、暗号化エンジンは、暗号化／復号化鍵を、ホスト上の、またはホストの外部で動作する鍵マネージャから取り出すために使用することができる。各暗号化ルールはまた、いくつかの実施形態では、暗号化モジュールが実行しなければならない暗号化／復号化動作のタイプを指定する。

【0078】

各暗号化ルールは、ルール識別子も有する。いくつかの暗号化ルールでは、ルール識別子は、純粋にL2～L4属性に関して、たとえば5タプル識別子に関して定義される。他の暗号化ルールは、アプリケーション名、アプリケーションバージョン、AppID、リソース消費、脅威レベル、ユーザID、グループIDなど、収集されたコンテキスト属性のうちの１以上を含むことができるコンテキスト属性に関して定義される。いくつかの実施形態におけるさらに他の暗号化ルールは、L2～L4パラメータおよびコンテキスト属性の両方に関して定義される。暗号化エンジン124は、コンテキスト属性を参照することによって定義される暗号化ルールを解決することができるので、この暗号化エンジンは、コンテキストベースの暗号化エンジンと呼ばれる。

【0079】

いくつかの実施形態では、コンテキストベース暗号化モジュール124は、収集されたコンテキスト属性の任意の組合せに関してその暗号化ルールを識別することができるので、任意の数のコンテキスト属性に基づいてデータメッセージフローを暗号化または復号することができる。例えば、暗号化エンジン124の暗号化／復号化動作は、ユーザデータとアプリケーションデータとの任意の組み合わせに基づくことができる。そのような暗号化動作の例には、（1)Outlook (任意のマシン上で開始される）からExchangeサーバへのすべてのトラフィックを暗号化すること、（2）3層ウェブサーバ、アプリケーションサーバ、およびデータベースサーバ内のアプリケーション間のすべての通信を暗号化すること、（3)Administrators Active Directoryグループから発生するすべてのトラフィックを暗号化することなどが含まれる。

【0080】

プロセス制御エンジン122は、DCN105上で開始されたプロセスに対して、コンテキストベースのプロセス制御動作（例えば、プロセス評価および終了動作）を実施する。いくつかの実施形態では、コンテキストエンジン110は、DCNのGIエージェント150から新しいプロセスイベントを受信するときはいつでも、このプロセスイベントに関連するプロセスパラメータをプロセス制御エンジン122に提供する。次いで、このエンジンは、受け取ったプロセスパラメータのセットを使用して、そのコンテキストベースのサービスルール記憶装置140を調べて、一致するコンテキストベースのプロセス制御ルールを識別する。

【0081】

プロセス制御エンジン122は、DCNのGIエージェントにプロセスに対するプロセス制御動作の実行を指示するように、コンテキストエンジンに指示することができる。そのようなプロセス制御動作の例は、（1）特定のバージョン番号を有するテレビ会議アプリケーションを終了すること、（2）YouTubeトラフィックを表示しているブラウザを終了すること、および（3）高い脅威レベルスコアを有するアプリケーションを終了することを含む。

【0082】

ディスカバリエンジン120は、別のコンテキストベースのサービスエンジンである。いくつかの実施形態では、ディスカバリエンジン120は、コンテキストエンジンがこれらのプロセスおよびネットワークイベントについて収集するコンテキスト属性とともに、コンテキストエンジンから新しいプロセスイベントおよび新しいネットワークイベントをキャプチャする。以下でさらに説明するように、ディスカバリサービスエンジンは、次いで、これらのイベントおよびそれらの関連するコンテキスト属性を、ネットワーク管理者がデータセンタ内のイベントを視覚化し、データセンタ内の計算およびネットワークリソースのためのポリシーを指定することを可能にする管理レイヤを提供する１以上のネットワークマネージャ（たとえば、サーバ）に中継する。

【0083】

これらのイベントおよび属性をネットワーク管理レイヤに中継する際に、いくつかの実施形態のディスカバリモジュールは、これらのイベントおよび属性のいくつかの前処理を実行する。例えば、いくつかの実施形態では、ディスカバリモジュールは、これらのイベントおよびそれらの属性のいくつかまたはすべてを集約しながら、ネットワークまたはプロセスイベントのいくつかをフィルタリングする。また、いくつかの実施形態では、ディスカバリエンジン120は、GIエージェント150または他のモジュール（例えば、DPIエンジンまたは脅威検出エンジン）を介してプロセスまたはネットワークイベントのための追加のコンテキスト属性を収集するように、またはファイルイベントおよびシステムイベントなどの他のタイプのイベントをキャプチャするように、コンテキストエンジン110に指示する。

【0084】

例えば、いくつかの実施形態では、ディスカバリエンジンは、マシン上にインストールされたアプリケーションのインベントリを構築し、このインベントリを定期的にリフレッシュするようにコンテキストエンジンに指示する。ディスカバリエンジンは、管理プレーンの要求時に、または管理プレーンまたは制御プレーンがディスカバリエンジンのために指定する動作構成に基づいて、コンテキストエンジンにそのように指示することができる。ディスカバリエンジンからの要求に応答して、いくつかの実施形態では、コンテキストエンジンは、そのホストのマシンのそれぞれの上の各GIエージェントに、マシン上のすべてのインストールされたプロセス、ならびにすべての実行中のプロセスおよびサービスをディスカバリさせる。

【0085】

インストールされたアプリケーションおよび実行中のプロセス／サービスのインベントリを構築した後、データセンタ内のホストコンピュータのディスカバリエンジンは、この情報を管理プレーン内のネットワーク／計算マネージャに提供する。いくつかの実施形態では、管理プレーンは、ホストコンピュータディスカバリエンジンおよびコンテキストエンジン以外の送信元からコンテキスト属性を収集する。たとえば、いくつかの実施形態では、管理プレーンは、１以上のサーバからの計算コンテキスト（たとえば、クラウドベンダからのクラウドコンテキスト、またはデータセンタ仮想化ソフトウェアによる計算仮想化コンテキスト）、ディレクトリサービスサーバからの識別コンテキスト、モビリティ管理サーバからのモビリティコンテキスト、DNS (ドメインネームサーバ）およびアプリケーションインベントリサーバからのエンドポイントコンテキスト、ネットワークコンテキスト（たとえば、ネットワーク仮想化サーバからの仮想化ネットワークコンテキスト）を収集する。

【0086】

コンテキスト情報（例えば、ディスカバリエンジンおよびコンテキストエンジンからの情報、および／または他のコンテキストソースからの情報）を収集することによって、管理プレーンは、ネットワーク／計算管理者にユーザインターフェースを提供して、データセンタ内の計算およびネットワークリソースを視覚化することができる。さらに、収集されたコンテキスト属性は、管理プレーンが、これらの管理者がコンテキストベースのサービスルールおよび／またはポリシーを指定するために、このユーザインターフェースを介して制御を提供することを可能にする。次いで、これらのサービスルール／ポリシーは、これらのコンピュータ上のサービスエンジンがコンテキストベースのサービス操作を実行できるように、ホストコンピュータに配信される。

【0087】

上述のいくつかの実施形態では、同じサービスエンジン130（例えば、同じファイアウォールエンジン128）が、メッセージフロー識別子（例えば、5タプル識別子）に関して、またはデータメッセージフローに関連する収集されたコンテキスト属性（例えば、AppID、脅威レベル、ユーザ識別子、グループ識別子、アプリケーション名／バージョンなど）に関して定義することができるサービスルールに基づいて、同じタイプのサービス（例えば、ファイアウォールサービス）を実行する。しかし、他の実施形態では、異なるサービスエンジンが、メッセージフロー識別子（たとえば、5タプル識別子）に基づいて、およびデータメッセージフローの収集されたコンテキスト属性に基づいて、同じタイプのサービスを提供する。例えば、いくつかの実施形態は、フロー識別子に関して定義されたルールに基づいてファイアウォール動作を実行する1つのフローベースのファイアウォールエンジンと、コンテキスト属性（例えば、AppID、脅威レベル、ユーザ識別子、グループ識別子、アプリケーション名／バージョンなど）に関して定義されたルールに基づいてファイアウォール動作を実行する別のコンテキストベースのファイアウォールエンジンとを用いる。

【0088】

図2は、いくつかの実施形態において、データセンタにおいてコンテキストリッチな属性ベースのサービスを構成し、実行するための分散アーキテクチャを確立するために使用される、ホストコンピュータ200のより詳細な例を示す。このホストコンピュータ200は、コンテキストエンジン110、サービスエンジン130、脅威検出器132、DPIモジュール135、コンテキストベースのサービスルール記憶装置140、およびコンテキスト属性記憶装置145など、ホストコンピュータ100と同じ構成要素の多くを含む。図1と同様に、図2のサービスエンジン130は、ディスカバリエンジン120、プロセス制御エンジン122、暗号化エンジン124、ロードバランサ126、およびファイアウォールエンジン128を含む。

【0089】

図2では、DCNは、ハイパーバイザ上で実行されるVM205である。また、図2では、ホストコンピュータ200は、ソフトウェア転送要素210、属性マッピング記憶装置223、接続状態キャッシュ記憶装置225、MUX (マルチプレクサ）227、およびコンテキストエンジンポリシー記憶装置143を含む。いくつかの実施形態では、コンテキストエンジン110、ソフトウェア転送要素210、サービスエンジン130、コンテキストベースのサービスルール記憶装置140、接続状態キャッシュ記憶装置225、コンテキストエンジンポリシー記憶装置143、およびMUX 227は、ハイパーバイザのカーネル空間で動作する一方、VM205は、ハイパーバイザのユーザ空間で動作する。他の実施形態では、１以上のサービスエンジンは、ユーザ空間モジュールである（たとえば、サービスVMである）。

【0090】

いくつかの実施形態では、VM205は、データセンタ内のデータエンドポイントとして働く。そのようなマシンの例は、ウェブサーバ、アプリケーションサーバ、データベースサーバなどを含む。場合によっては、全てのVMは、1つのエンティティ、例えば、ホストを運営するエンティティに属する。他の場合には、ホスト200は、マルチテナント環境（例えば、マルチテナントデータセンタ）で動作し、異なるVM205は、1つのテナントまたは複数のテナントに属することができる。

【0091】

各VM 205は、コンテキストエンジン110と対話してこのエンジンにコンテキスト属性セットを提供し、このエンジンから指示およびクエリを受信するGIエージェント250を含む。GIエージェント250とコンテキストエンジン110との間の対話は、GIエージェント150とコンテキストエンジン110との間の上述の対話と同様である。しかし、図2に示すように、いくつかの実施形態では、コンテキストエンジン110とGIエージェント250との間のすべての通信は、MUX 227を介して中継される。そのようなMUXの一例は、VMware、Inc．のESXハイパーバイザのエンドポイントセキュリティ（EPSec）プラットフォームによって使用されるMUXである。

【0092】

いくつかの実施形態では、GIエージェントは、高速通信チャネル（ESXのVMCIチャネルなど）を介してMUX 227と通信する。いくつかの実施形態では、この通信チャネルは共有メモリチャネルである。上述のように、いくつかの実施形態においてGIエージェント250からコンテキストエンジン110によって収集される属性は、パラメータの豊富なグループ（例えば、レイヤ7パラメータ、プロセス識別子、ユーザ識別子、グループ識別子、プロセス名、プロセスハッシュ、ロードされたモジュール識別子、消費パラメータなど）を含む。

【0093】

図示のように、各VM 205は、いくつかの実施形態では、仮想化ネットワークインターフェースカード（VNIC）255も含む。各VNICは、そのVMとソフトウェア転送要素（SFE）210との間でメッセージを交換する役割を果たす。各VNICは、SFE 210の特定のポート260に接続する。SFE 210は、ホストの物理ネットワークインタフェースカード(NIC) (図示せず）にも接続する。いくつかの実施形態では、Vネットワークインタフェースカードは、ホストの１以上の物理NIC（PNIC）のハイパーバイザによって作成されるソフトウェア抽象化である。

【0094】

いくつかの実施形態では、SFE 210は、各VMの各VNICに対して単一のポート260を維持する。SFE 210は、（NICドライバ（図示せず）を介して）ホストPNICに接続し、発信メッセージを送信し、着信メッセージを受信する。いくつかの実施形態では、SFE 210は、PNICとの間でメッセージを送受信するためにPNICのドライバに接続するポート265を含むように定義される。SFE 210は、メッセージ処理動作を実行して、そのポートの1つで受信したメッセージをそのポートの別の1つに転送する。例えば、いくつかの実施形態では、SFEは、メッセージ内のデータ（例えば、メッセージヘッダ内のデータ）を使用して、メッセージをフローベースのルールにマッチングさせ、一致を見つけると、マッチングルールによって指定されたアクションを実行しようと試みる（例えば、メッセージを宛先VMまたはPNICに供給するようにメッセージを送信する、そのポート260または265のうちの1つにメッセージを渡す）。

【0095】

いくつかの実施形態では、SFE 210はソフトウェアスイッチであり、他の実施形態では、ソフトウェアルータまたは複合ソフトウェアスイッチ／ルータである。SFE 210は、いくつかの実施形態では、マルチホスト環境内の他のホスト上で実行されるSFEを用いて、１以上の論理転送要素（たとえば、論理スイッチまたは論理ルータ）を実装する。いくつかの実施形態における論理転送要素は、異なるホスト上で実行されるが1つの論理ネットワークに属するVMを接続するように、複数のホストにまたがることができる。

【0096】

異なる論理転送要素は、異なるユーザに対して異なる論理ネットワークを指定するように定義することができ、各論理転送要素は、複数のホスト上の複数のソフトウェア転送要素によって定義することができる。各論理転送要素は、1つの論理ネットワークのVMのトラフィックを、別の論理転送要素によってサービスされる別の論理ネットワークのVMから分離する。論理転送要素は、同じホストおよび／または異なるホスト上で実行するVMを接続することができる。いくつかの実施形態では、SFEは、データメッセージから、論理ネットワーク識別子（例えば、VNI）およびMACアドレスを抽出する。これらの実施形態におけるSFEは、抽出されたVNIを使用して論理ポートグループを識別し、次いでMACアドレスを使用してポートグループ内のポートを識別する。

【0097】

ソフトウェアスイッチ（例えば、ハイパーバイザのソフトウェアスイッチ）は、ソフトウェアで動作し、ホストのPNICへの共有アクセスをVMに提供するので、仮想スイッチと呼ばれることがある。しかしながら、本明細書では、ソフトウェアスイッチは、物理的世界のアイテムであるため、物理的スイッチと呼ばれる。この用語はまた、ソフトウェアスイッチによって提供される接続のタイプの抽象化である論理スイッチからソフトウェアスイッチを区別する。ソフトウェアスイッチから論理スイッチを作成するための様々なメカニズムがある。VXLANは、そのような論理スイッチを作成する1つの方法を提供する。VXLAN標準は、Mahalingam、Mallik; Dutt、Dinesh G.ら（2013/05/08）による、IETFの「VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks」に記載されている。

【0098】

いくつかの実施形態では、SFE 210のポートは、ポートで受信される着信メッセージおよび発信メッセージに対して特殊入出力（I／O）動作を実施する１以上のモジュールへの１以上の関数呼出しを含む。ポート260によって実施されるI／O動作の例には、米国特許第9,548,965号に記載されているARPブロードキャスト抑制動作およびDHCPブロードキャスト抑制動作が含まれる。本発明のいくつかの実施形態では、他のI／O操作（ファイアウォール動作、ロードバランシング動作、ネットワークアドレス変換動作など）をそのように実装することができる。いくつかの実施形態では、そのような関数呼び出しのスタックを実装することによって、ポートは、着信および／または発信メッセージに対する一連のI／O操作を実装することができる。また、いくつかの実施形態では、データパス内の他のモジュール（VNIC255、ポート265など）が、ポート260の代わりに、またはポート260と共に、I／O関数呼出し操作を実施する。

【0099】

いくつかの実施形態では、SFEポート260の１以上の関数呼び出しは、コンテキストベースのサービスルール記憶装置140内のコンテキストベースのサービスルールを処理する１以上のサービスエンジン130に対するものとすることができる。いくつかの実施形態における各サービスエンジン130は、それ自体のコンテキストベースのサービスルール記憶装置140、属性マッピング記憶装置223、および接続状態キャッシュ記憶装置225を有する。図2は、不必要な詳細でこの図の表示を不明瞭にしないために、全てのサービスエンジンに対して1つのコンテキストベースのサービスルール記憶装置140、属性マッピング記憶装置223、及び接続状態キャッシュ記憶装置225のみを示している。また、いくつかの実施形態では、各VMは、各サービスエンジン130のそれ自体のインスタンス（例えば、ディスカバリエンジン120、プロセス制御エンジン122、暗号化エンジン124、ロードバランサ126、およびファイアウォールエンジン128のそれ自体のインスタンス）を有する。他の実施形態では、1つのサービスエンジンは、ホスト上の複数のVM（例えば、同じ論理ネットワークのVM）のためのデータメッセージフローをサービスすることができる。

【0100】

データメッセージフローに関するそのサービス動作を実行するために、いくつかの実施形態では、サービスエンジン130は、フロー識別子（たとえば、5タプル識別子）および／またはフローの関連するコンテキスト属性セットを、そのコンテキストベースのサービスルール記憶装置140内のそのサービスルールのルール識別子に一致させようと試みる。具体的には、サービスエンジン130がデータメッセージフローに関するサービスチェック動作を実行するために、サービスエンジンを呼び出すSFEポート260は、ポートが受信するメッセージの属性のセットを供給する。いくつかの実施形態では、属性のセットは、従来の5タプル識別子などのメッセージ識別子である。いくつかの実施形態では、識別子値のうちの１以上は、論理ネットワークに対して定義される論理値とすることができる（例えば、論理アドレス空間において定義されるIPアドレスとすることができる）。他の実施形態では、識別子値のすべてが物理ドメイン内で定義される。さらに他の実施形態では、識別子値のいくつかは論理ドメインで定義され、他の識別子値は物理ドメインで定義される。

【0101】

次いで、いくつかの実施形態におけるサービスエンジンは、受信したメッセージの属性セット（例えば、メッセージの5タプル識別子）を使用して、サービスエンジンがこのフローのために属性マッピング記憶装置223に格納したコンテキスト属性セットを識別する。上述したように、コンテキストエンジン110は、いくつかの実施形態では、新しいフロー（すなわち、新しいネットワーク接続イベント）および新しいプロセスのためのコンテキスト属性を、フロー識別子（例えば、5タプル識別子）またはプロセス識別子とともに、サービスエンジン130に供給する。コンテキストエンジンポリシー記憶装置143は、コンテキストエンジン110の動作を制御するルールを含む。いくつかの実施形態では、これらのポリシーは、コンテキストエンジンに、サービスエンジンのためのルールを生成するように、またはサービスエンジンにルールを生成するように、指示する（例えば、高脅威アプリケーションがVM上で実行されるとき、同じホスト上の他のすべてのVMのための暗号化エンジンに、それらのデータメッセージトラフィックを暗号化するように指示する）。これらの実施形態におけるサービスエンジン130は、コンテキストエンジンから受け取ったコンテキスト属性を属性マッピング記憶装置223に保存する。

【0102】

いくつかの実施形態では、サービスエンジン130は、そのフローの識別子（例えば、5タプル識別子）またはそのプロセスの識別子を有する新しいフローまたは新しいプロセスごとに設定されたコンテキスト属性を、属性マッピング記憶装置に保存する。このようにして、サービスエンジンは、一致するフロー識別子を有するコンテキストレコードを求めてその属性マッピング記憶装置223を検索することによって、SFEポート260から受け取る新しいフローごとにコンテキスト属性セットを識別することができる。一致するフロー識別子を有するコンテキストレコードは、このフローについて設定されたコンテキスト属性を含む。同様に、プロセスイベントのコンテキスト属性セットを識別するために、いくつかの実施形態では、サービスエンジンは、一致するプロセス識別子を有するコンテキストレコードを求めて、その属性マッピング記憶装置223を検索する。

【0103】

上述のように、いくつかの実施形態におけるサービスエンジンのいくつかまたはすべては、新しいフローまたは新しいプロセスのためのコンテキスト属性セットをコンテキストエンジンから引き出す。例えば、いくつかの実施形態では、サービスエンジンは、SFEポート260から受け取る新しいフローの5タプル識別子をコンテキストエンジン110に供給する。次いで、このエンジン110は、その属性ストレージ145を調べて、この5タプル識別子のために格納されている属性のセットを識別し、次いで、この属性セット（または、サービスエンジンのために識別された属性セットをフィルタリングすることによって得られる属性セットのサブセット）をサービスエンジンに供給する。

【0104】

上述のように、いくつかの実施形態は、サービストークンを使用して新しいメッセージフローの属性セットを符号化することによってプルモデルを実施する。新しいネットワーク接続イベントが通知されると、いくつかの実施形態では、コンテキストエンジン110は、（1）新しいイベントのためのコンテキスト属性セットを収集し、（2）このセットをフィルタリングして、フロー上で１以上のサービスを実行するのに関連しない属性を廃棄し、（3）残りのフィルタリング属性サブセットをサービストークンと共に属性記憶装置145に保存し、（4）サービストークンをGIエージェント250に提供する。次いで、GIエージェント250は、このトークンをインバンドで（例えば、エージェントのVMが宛先に送信するデータメッセージのヘッダで）、またはアウトオブバンドで（すなわち、エージェントのVMが宛先に送信するデータメッセージとは別に）サービスエンジンに渡す。

【0105】

サービスエンジンは、SFEポート260を介して新しいフローを取得すると、このフローのサービストークンをコンテキストエンジンに供給し、コンテキストエンジンは、このサービストークンを使用して、サービスエンジンに供給するコンテキスト属性をその属性ストレージ145内で識別する。SFEポートがこのサービストークンをサービスエンジンに提供しない実施形態では、サービスエンジンは、まず、サービストークンをコンテキストエンジンに供給する前に、フローの識別子を使用してそのデータ記憶装置を検索することによってサービストークンを識別しなければならない。

【0106】

データメッセージフローに関するコンテキスト属性セットを識別した後、いくつかの実施形態では、サービスエンジン130は、コンテキストベースサービスルール記憶装置140に格納されたサービスルールに基づいて、そのサービス操作を実行する。そのサービス操作を実行するために、サービスエンジン130は、受信した属性サブセットを、サービスルールのために格納されている対応する属性セットと照合する。いくつかの実施形態では、コンテキストベースのサービスルール記憶装置140内の各サービスルールは、ルール識別子およびアクションパラメータのセットを有する。

【0107】

上述のように、いくつかの実施形態におけるサービスルールのルール識別子は、L2～L4ヘッダパラメータではない１以上のコンテキスト属性（例えば、L7パラメータ、プロセス識別子、ユーザ識別子、グループ識別子、プロセス名、プロセスハッシュ、ロードされたモジュール識別子、消費パラメータなど）に関して定義することができる。いくつかの実施形態では、ルール識別子はまた、L2～L4ヘッダパラメータを含むことができる。また、いくつかの実施形態では、ルール識別子内の１以上のパラメータを、個々の値またはワイルドカード値に関して指定することができる。また、いくつかの実施形態では、ルール識別子は、セキュリティグループ識別子、計算コンストラクト識別子、ネットワークコンストラクト識別子など、個々の値のセットまたはグループ識別子を含むことができる。

【0108】

受け取った属性セットをルールと一致させるために、サービスエンジンは、受け取った属性セットを、コンテキストベースサービスルール記憶装置140に保存されたサービスルールの関連識別子と比較する。マッチングルールを識別すると、サービスエンジン130は、マッチングルールのアクションパラメータのセットに基づいて（例えば、許可／ドロップパラメータ、ロードバランシング基準、暗号化パラメータなどに基づいて）、サービス動作（例えば、ファイヤウォール動作、ロードバランシング動作、暗号化動作、他のミドルボックスの動作など）を実行する。

【0109】

いくつかの実施形態では、コンテキストベースのサービスルール記憶装置140は、メッセージの属性サブセットが複数のルールに一致するときに、メッセージルールチェックが、より低い優先順位のルールに一致する前に、より高い優先順位のルールに一致することを保証するように、階層的な方法で定義される。また、いくつかの実施形態では、コンテキストベースのサービスルール記憶装置140は、他のサービスルールを識別することができない任意のメッセージルールチェックのためのデフォルトアクションを指定するデフォルトルールを含み、このデフォルトルールは、いくつかの実施形態では、すべての利用可能な属性のサブセットのための一致であり、サービスルールエンジンがすべての受信された属性のサブセットのための動作を返すことを保証する。いくつかの実施形態では、デフォルトルールは、サービスを指定しない。

【0110】

例えば、メッセージが2つのマシン間の1つの通信セッションに関連する1つのフローの一部である場合、複数のメッセージは、同じメッセージ識別子の属性セットを有することができる。したがって、メッセージの識別されたコンテキスト属性セットに基づいて、データメッセージをコンテキストベースのサービスルール記憶装置140内のサービスルールとマッチングした後、いくつかの実施形態のサービスエンジンは、サービスルール（またはサービスルールへの参照）を接続状態キャッシュ記憶装置225に保存し、その結果、サービスエンジンは、同じフローの後続のデータメッセージのためにこのサービスルールを後で使用することができる。

【0111】

いくつかの実施形態では、接続状態キャッシュ記憶装置225は、サービスエンジン130が異なるメッセージ識別子設定について（例えば、異なるデータメッセージフローを識別する異なる5タプル識別子について）識別するサービスルール、またはサービスルールへの参照を保存する。いくつかの実施形態では、接続状態キャッシュ記憶装置225は、一致するメッセージ識別子のセットから生成された識別子（例えば、フローの5タプル識別子および／またはフローの5タプル識別子のハッシュ値）とともに、各サービスルール、またはサービスルールへの参照を保存する。

【0112】

特定のメッセージについてコンテキストベースのサービスルール記憶装置140をチェックする前に、いくつかの実施形態のサービスルールエンジン130は、接続状態キャッシュ記憶装置225をチェックして、この記憶装置がこのメッセージのフローについてのサービスルールを以前に識別したかどうかを判定する。そうでない場合、サービスエンジン130は、メッセージフローのコンテキスト属性セットを識別し、次いで、メッセージの識別された属性セットおよび／またはその5タプル識別子と一致するサービスルールについてコンテキストベースのサービスルール記憶装置140をチェックする。接続状態データストレージが特定のメッセージのエントリを有するとき、サービスエンジンは、このサービスルールのアクションパラメータ設定に基づいてそのサービス動作を実行する。

【0113】

図2のサービスアーキテクチャでは、DPIモジュール135は、ファイアウォールエンジン128の指示でデータメッセージフローに対してディープパケット検査を実行する。具体的には、ファイアウォールエンジン128が、新しいデータメッセージフローの一部である新しいデータメッセージを受信すると、いくつかの実施形態では、ファイアウォールエンジンは、DPIモジュールに、その新しいデータメッセージと、同じフロー内の次のいくつかのデータメッセージのうちの１以上とを検査するように指示する。この検査に基づいて、DPIエンジンは、このデータメッセージフローで送信されているトラフィックのタイプ（すなわち、ワイヤ上のアプリケーション）を識別し、このトラフィックタイプのAppIDを生成し、このAppIDを属性記憶装置145に保存する。いくつかの実施形態では、コンテキスト属性セットは、フロー識別子および／またはプロセス識別子に基づいて属性記憶装置に格納される。したがって、いくつかの実施形態では、DPIエンジン135は、そのフローの5タプル識別子に基づいて、新しいデータメッセージフローのAppIDを属性記憶装置145に記憶する。

【0114】

いくつかの実施形態では、コンテキストエンジン110は、DPIエンジンがAppIDを属性ストレージ145に保存すると、新しいデータメッセージフローのAppIDをサービスエンジン130にプッシュする。他の実施形態では、コンテキストエンジン110は、サービスエンジンによってデータメッセージフローのコンテキスト属性について照会されるたびに、属性ストレージ145からAppIDをプルする。いくつかの実施形態では、コンテキストエンジン110は、フローの5タプル識別子を使用して、一致するレコード識別子およびAppIDを有する属性ストレージ145内のレコードを識別する。

【0115】

図3は、コンテキストエンジンが、新しいプロセスまたはネットワーク接続イベントについて通知されるたびに、いくつかの実施形態で実行する（110）プロセス300を示す。VM 205のGIエージェント250から、プロセス300は最初に（305で）新しいプロセスまたはネットワーク接続イベントに関する通知を受信する。次に、310で、プロセス300は、通知されたイベントに関するすべての所望のコンテキスト属性を収集する。

【0116】

上述のように、コンテキストエンジン110は、いくつかの実施形態では、報告GIエージェント250と対話して（310で）、報告されたイベントに関する追加情報を収集する。いくつかの実施形態では、GIエージェントは、VMのOSカーネル空間内のネットワークスタックおよび／または処理サブシステムと対話して、プロセスまたはネットワークイベントに関するコンテキスト属性を収集する。いくつかの実施形態では、GIエージェントはまた、コンテキスト属性を収集するためにユーザ空間プロセス（例えば、VMtool．exe）で動作するユーザ空間モジュール（例えば、ユーザモードダイナミックリンクライブラリ、DLL）からこの情報を収集する。Microsoft Windowsを使用するVMでは、いくつかの実施形態におけるGIエージェントは、Windowsフィルタリングプラットフォーム（WFP）にフックを登録してネットワークイベントを取得し、Windowsのプロセスサブシステムに登録してプロセス関連属性を収集する。いくつかの実施形態では、GIエージェントのフックは、WFPのアプリケーションレイヤエンフォースメント（ALE）層にあり、その結果、GIエージェントフックは、VM上のアプリケーションプロセスからのすべてのソケット接続要求をキャプチャすることができる。

【0117】

いくつかの実施形態では、コンテキストエンジン110は、管理プレーンまたは制御プレーンと対話してコンテキスト属性を収集し、および／または識別されたネットワークイベントまたはプロセスイベントのコンテキスト属性を識別するために調べることができる記録を受信する。これらの実施形態のいくつかでは、コンテキストエンジンは、ホストの外部で動作する管理プレーンまたは制御プレーンサーバからデータを取得するために、（そのホスト上で動作する）管理プレーンまたは制御プレーンプロキシと対話する。これらの実施形態のいくつかでは、コンテキストエンジンはカーネル空間で動作する。

【0118】

310でコンテキスト属性を収集した後、プロセスは、（315で）受信したイベントの属性または受信したイベントについて収集したコンテキスト属性を使用して、コンテキストエンジンポリシー記憶装置143内の１以上のポリシーを識別する。315で、プロセスは、収集された属性およびイベント属性に一致するポリシー識別子を有する任意のポリシーを識別する。

【0119】

次に、320で、プロセスは、315で識別されたポリシーに基づいて、１以上のサービスエンジンのコンテキスト属性マッピングレコードを生成する。識別されたポリシーのうちの１以上は、特定のプロセスまたはネットワークイベントについて、サービスエンジンの特定のセットがイベントについて（たとえば、新しいデータメッセージフローについて）通知される必要があり、各サービスエンジンが、そのイベントについてのその処理を実行するためにそのサービスエンジンに関連するコンテキスト属性のサブセットを受信することを指定することができる。いくつかの実施形態におけるこの動作は、コンテキストエンジンがその特定のサービスエンジンに提供するコンテキスト属性のサブセット内の各特定のサービスエンジンに関連しない属性を含まないコンテキストエンジンを含む。

【0120】

いくつかの実施形態では、いくつかのイベントは、１以上のサービスエンジンのために新しいサービスルールが作成されることを必要とする場合がある。例えば、高脅威アプリケーションが1つのVM上で識別されるとき、ポリシーは、そのホスト上の他のVMがそれらのデータメッセージトラフィックの暗号化を開始しなければならないことを指定することができる。いくつかのそのような実施形態では、コンテキストエンジンポリシー記憶装置143は、特定の状況下でサービスエンジンのためのサービスルールを生成するように、またはそのようなサービスルールを生成するようにサービスエンジンに指示するように、コンテキストエンジンに指示するポリシーを含む。そのような実施形態の場合、プロセス（320）は、必要に応じて、特定の状況下でサービスエンジンのサービスルールを生成するか、またはサービスエンジンにそのようなサービスルールを生成するように指示する。

【0121】

325で、プロセス300は、マッピングレコードおよび／または生成されたサービスルール／命令を１以上のサービスエンジンに配信する。上述のように、コンテキストエンジンは、プッシュモデルまたはプルモデルを使用して、そのような記録および／またはルール／命令を配信することができる。プルモデルを使用する場合、プロセス300は、いくつかの実施形態では、サービスエンジンからのクエリに応答して動作325を実行するだけでなく、このクエリに応答して動作320の一部または全部を実行する。325の後、プロセスは終了する。

【0122】

ロードバランシングエンジン126は、L2～L4パラメータに関してだけでなく、コンテキスト属性に関しても指定することができるロードバランシングルールに基づいてそのロードバランシング操作を実行する、コンテキストベースのロードバランサである。図4は、そのようなコンテキストベースのロードバランシングルールの例を示す。これらのルールは、図5に示すように、異なるホスト上の異なるウェブサーバVM505からのデータメッセージを異なるアプリケーションサーバVM510に配信するために、異なるホスト500上の異なるロードバランシングエンジン126によって独立して使用される。いくつかの実施形態では、ホスト500はホスト200と同様であり、ウェブサーバVM505およびアプリケーションサーバVM510は、図2のVM205と同様である。不必要な詳細で図を曖昧にすることを避けるために、図5に示すホスト500の唯一の構成要素は、ロードバランサ126およびウェブサーバVM505であり、ロードバランサは、ウェブサーバVM505の出口パスにサービスモジュールとして現れる。

【0123】

図5に示す例では、ロードバランサ126は、複数のホストにわたって広がり、ウェブサーバVMトラフィックをアプリケーションサーバVMにわたって均一に分散させる分散ロードバランサ（すなわち、単一の概念論理ロードバランサ）を集合的に形成する。以下でさらに説明するように、いくつかの実施形態における異なるロードバランサ126のためのロードバランシングルールのロードバランシング基準は、ウェブサーバVMトラフィックの均一な処理を保証するために同じである。ホスト500bによって示されるように、複数のウェブサーバVM505は、同じホスト500上で実行することができ、これらのウェブサーバVMのそれぞれは、異なるロードバランサ126によってサービスされる。他の実施形態では、1つのロードバランサは、同じホスト上の複数のVM（例えば、同じホスト上の同じテナントのための複数のVM）にサービスを提供することができる。また、いくつかの実施形態では、複数のアプリケーションサーバVMは、互いにおよび／またはウェブサーバVMと同じホスト上で実行することができる。

【0124】

図4～5に示す例では、ロードバランサ126は、アプリケーションサーバの仮想IP (VIP)アドレスを、宛先IPアドレスまたはDIPと呼ばれる特定のアプリケーションVMのIPアドレスに変換する宛先ネットワークアドレス変換（DNAT）を実行する。他の実施形態では、DNAT動作は、他のネットワークアドレスを変換することができ、例えば、MACアドレスを変換してMACリダイレクトを達成することができる。また、図4～5のロードバランサは、アプリケーションサーバグループ（クラスタ）のアプリケーションサーバ間でウェブサーバトラフィックを分配するが、ロードバランサは、任意のサービス／計算ノードクラスタのサービスまたは計算ノードのうちの１以上のサービスまたは計算ノードの任意のセットからのトラフィックを配信するために使用することができる。

【0125】

図4は、いくつかのロードバランシング（LB）ルールを保存するLBルール保存装置140を示しており、各LBルールは、1つのロードバランスされた計算またはサービスクラスタに関連付けられている。各ロードバランスルールは、（1）ルール識別子405、（2）ロードバランスノードグループのいくつかのノードのいくつかのIPアドレス410、および（3）各IPアドレスの重み値415を含む。各ルール識別子405は、データメッセージフローに一致するルールを識別するために使用することができる１以上のデータタプルを指定する。

【0126】

いくつかの実施形態では、ルール識別子は、ルールの関連するDCNグループのVIPアドレス（図5のアプリケーションサーバグループのVIPアドレスなど）を含むことができる。図示のように、ルール識別子は、いくつかの実施形態では、任意のL2～L4パラメータ（例えば、送信元IPアドレス、送信元ポート、宛先ポート、プロトコルなど）を含むことができる。また、図示のように、LBルールのルール識別子は、AppID、アプリケーション名、アプリケーションバージョン、ユーザID、グループID、脅威レベル、リソース消費などのコンテキスト属性を含むことができる。いくつかの実施形態では、ロードバランサは、１以上のメッセージ属性（たとえば、5タプルヘッダ値、コンテキスト属性）をルール識別子405と比較することによってLBデータ記憶装置を検索して、一致するルール識別子を有する最高優先順位のルールを識別する。

【0127】

各LBルールのIPアドレス410は、ルールに関連付けられた（例えば、ルールの識別子405で指定されたVIPアドレスに関連付けられたロードバランシングされたグループの）ロードバランシングされた計算機またはサービスグループのメンバである計算機またはサービスノードのIPアドレスである。以下でさらに説明するように、いくつかの実施形態では、これらのノードの宛先は、ロードバランサを構成するコントローラのセットによって供給される。いくつかの実施形態では、ロードバランサは、受信したデータメッセージの宛先IPアドレスをIPアドレス410のうちの1つに変換する（例えば、データメッセージに含まれるVIPをDIPに変換する）。

【0128】

いくつかの実施形態では、ロードバランサは、１以上のロードバランシング基準に基づいてそのロードバランシング動作を実行する。いくつかの実施形態のLBルールは、各ルール内で、メッセージフローがそのルールに一致するときに、ロードバランサがロードバランスされたグループのノードにわたってトラフィックをどのように分散すべきかを指定するために、そのようなLB基準を含む。図4に示す例では、ロードバランシング基準は、各ルールの重み値415によって定義される重み付きラウンドロビン方式である。具体的には、各LBルールの各IPアドレスの重み値415は、ロードバランサがトラフィックをLBノードグループのノードに分散させるための基準を提供する。

【0129】

例えば、図5のアプリケーションサーバグループは、5つのアプリケーションサーバを有する。これら5つのアプリケーションサーバ間でウェブサーバトラフィックを分配するためのロードバランシングルールが、5つのアプリケーションサーバの5つのIPアドレスに対して1、3、1、3、および2の重み値を指定すると仮定する。これらの値に基づいて、ロードバランサは、第1のフローを第1のIPアドレスに、第2のフローを第2のIPアドレスに、第5のフローを第3のIPアドレスに、第6から第8のフローを第4のIPアドレスに、第9および第10のフローを第5のIPアドレスに、という順序で、10個の新しいフローの一部であるデータメッセージを配信する。このスキームによれば、新しいフローの次のバッチの割り当ては、これらのIPアドレスを介してループバックする（例えば、第11のフローは、第1のIPアドレスに割り当てられ、以下同様である）。

【0130】

いくつかの実施形態では、LBルールの重み値は、（1）ロードバランサが、LBノードグループのノード間で分配するデータメッセージフローに関して収集し、（2）コントローラ設定に提供するLB統計に基づいて、コントローラ設定によって生成され、調整される。また、いくつかの実施形態におけるLBルールは、異なるロードバランシング基準間を適切に切り替えるために、異なる期間に有効なLBルールの異なるロードバランシング基準の期間を指定する。したがって、いくつかの実施形態では、ロードバランシングルールは、宛先ネットワークアドレスの複数の異なる設定を、アドレスの各設定がいつ有効であるかを指定する異なる時間値で指定することができる。いくつかの実施形態におけるこれらのセットの各々は、それ自体のLB基準のセット（例えば、それ自体の重み値のセット）を含むことができる。

【0131】

図6は、いくつかの実施形態においてロードバランサ126が実行するプロセス600を示す。図示のように、プロセス600は、ロードバランサがその対応するSFEポート260からデータメッセージを（605で）受信したときに開始する。このポートは、VMまたはVMからデータメッセージを受信すると、このメッセージを中継する。いくつかの実施形態では、ポートは、データメッセージまたはデータメッセージのヘッダ値への参照（例えば、データメッセージを保存するメモリ内のロケーションを識別するハンドル）をロードバランサに渡すことによって、データメッセージを中継する。

【0132】

プロセスは、接続状態キャッシュ225が、データメッセージを転送すべき宛先を識別するレコードを保存しているかどうかを（610で）判定する。上述のように、ロードバランサがLBルールを使用して新しいデータメッセージフローをロードバランスされたノードグループのノードに向けるたびに、ロードバランサは、いくつかの実施形態では、選択されたノードの物理IPアドレスを記憶するために接続状態キャッシュ225内にレコードを作成し、その結果、ロードバランサは、同じフロー内で（すなわち、同じ5タプル識別子を用いて）別のデータメッセージを受信したときに、同じフロー内で前のデータメッセージのために用いた同じノードにデータメッセージを転送することができる。接続状態キャッシュ225の使用は、ロードバランサ126がデータメッセージフローをより迅速に処理することを可能にする。いくつかの実施形態では、接続状態キャッシュ225内の各キャッシュされたレコードは、データメッセージ識別子（例えば、5タプル識別子）に関して定義されるレコード識別子を有する。これらの実施形態では、プロセスは、受信されたデータメッセージの識別子（例えば、5タプル識別子）をキャッシュされたレコードのレコード識別子と比較して、受信されたデータメッセージの識別子と一致するレコード識別子を有する任意のレコードを識別する。

【0133】

プロセス600が（610で）受信したデータメッセージのフローに関するレコードを接続状態キャッシュ225内で識別すると、プロセスは（615で）メッセージの宛先アドレス（例えば、VIPアドレス）を、接続状態キャッシュ225内のレコードに格納されている宛先アドレス（例えば、DIP）で置き換える。615において、プロセスは、アドレス変換されたデータメッセージをそのデータ経路に沿って送信する。いくつかの実施形態では、この動作は、ロードバランサがVMデータメッセージの処理を完了したことを示すために、SFEポート260（ロードバランサを呼び出してプロセス600を開始した）に通信を返すことを伴う。次いで、SFEポート260は、データメッセージをSFEへハンドオフするか、又はI／Oチェーンオペレータにおける別のサービスエンジンをコールして、データメッセージに対して別のサービスオペレーションを遂行することができる。615において、プロセス600はまた、いくつかの実施形態において、そのデータメッセージフロープロセスに関して維持する統計を更新する。615の後、プロセス600は終了する。

【0134】

プロセス600が、（610で）接続状態キャッシュ225が受信したデータメッセージのフローに関するレコードを格納していないと判定した場合、プロセス600は、（620で）このデータメッセージフローに関する１以上のコンテキスト属性を識別する。上述したように、異なる実施形態のサービスエンジンは、この動作を異なるように実行する。例えば、いくつかの実施形態では、ロードバランサ126は、受信したデータメッセージのヘッダ値（例えば、その5タプル識別子）と一致するレコード識別子を有するレコードについて、属性マッピング記憶装置223をチェックする。次に、この一致するレコードのコンテキスト属性セットを、受信したデータメッセージフローのコンテキスト属性セットとして使用する（620）。

【0135】

他の実施形態では、ロードバランサ126は、コンテキストエンジンにクエリを発行（照会）して、受信したデータメッセージのコンテキスト属性セットを取得する。このクエリを用いて、ロードバランサは、受信したメッセージのフロー識別子（例えば、5タプル識別子）またはその関連するサービストークンを供給する。次いで、コンテキストエンジンは、メッセージのフロー識別子またはその関連するサービストークンを使用して、そのコンテキスト属性記憶装置145内のコンテキスト属性のセットを識別し、次いで、上述のように、識別されたコンテキスト属性の設定をロードバランサ126に提供する。

【0136】

プロセス600は、受信したデータメッセージに関するコンテキスト属性セットを取得すると、この属性セットをメッセージの他の識別子と共に使用して、605で受信したデータメッセージに関するLBルール記憶装置140内のLBルールを（625で）識別する。例えば、いくつかの実施形態では、LBルールは、アプリケーション名、アプリケーションバージョン、ユーザID、グループID、AppID、脅威レベル、リソース消費レベルなどの１以上のコンテキスト属性とともに、5タプル属性のうちの１以上に関して定義されるルール識別子405を有する。LBルール記憶装置140内のLBルールを識別するために、いくつかの実施形態におけるプロセスは、受信されたデータメッセージのコンテキスト属性および／または他の属性（例えば、5タプル識別子）をLBルールのルール識別子（例えば、ルール識別子405）と比較して、メッセージの属性セットと一致する識別子を有する最高優先度ルールを識別する。

【0137】

いくつかの実施形態では、プロセスは、この比較動作を実行するために、異なるメッセージ属性セットを使用する。例えば、いくつかの実施形態では、メッセージ属性セットは、１以上のコンテキスト属性とともに、メッセージの宛先IPアドレス（例えば、アドレス指定されたノードグループのVIP）を含む。他の実施形態では、メッセージ属性セットは、他の5タプル識別子のうちの１以上（たとえば、送信元IP、送信元ポート、宛先ポート、およびプロトコルのうちの１以上）など、他の属性を含む。いくつかの実施形態では、メッセージ属性セットは、仮想ネットワーク識別子（VNI）、仮想分散ルータ識別子（VDRI）、論理MACアドレス、論理IPアドレスなどの論理ネットワーク識別子を含む。

【0138】

上述のように、いくつかの実施形態における各LBルールは、ロードバランシングノードグループのメンバであるノードの宛先アドレス（例えば、IPアドレス）である2つ以上の宛先アドレス（例えば、IPアドレス410）を含む。プロセスは、（630で）LBルールを識別すると、ルールの宛先アドレス（例えば、IPアドレス）の1つを選択して、メッセージ内の仮想アドレス（例えば、VIPアドレス）を置き換える。また、上述したように、いくつかの実施形態における各LBルールは、メッセージの仮想宛先識別子を置き換えるために、LBルールの宛先アドレスのうちの1つのプロセスによる選択を容易にするための1組のロードバランシング基準を保存する。いくつかの実施形態では、記憶された基準は、図4および図5を参照して上述した重みおよび／または時間値である。したがって、いくつかの実施形態では、プロセス600は、ルールに格納された選択基準に基づいて一致するルールの宛先アドレスのうちの1つを選択し、メッセージの宛先アドレスを選択された宛先アドレスに変更する。

【0139】

データメッセージの宛先アドレスを変更した後、プロセスは（630で）そのデータ経路に沿ってデータメッセージを送信する。再び、いくつかの実施形態では、この動作は、ロードバランサがVMデータメッセージの処理を完了したことを示すために、SFEポート260（ロードバランサを呼び出してプロセス600を開始した）に通信を返すことを伴う。次いで、SFEポート260は、データメッセージをSFEまたはVMへハンドオフするか、又はI／Oチェーンオペレータにおける別のサービスエンジンをコールして、データメッセージに対して別のサービスオペレーションを遂行することができる。

【0140】

630の後、プロセスは635に遷移し、接続状態キャッシュ記憶装置225において、プロセスは、605で受信されたデータメッセージと同じフローの一部であるデータメッセージを転送するために使用する、ロードバランスされたグループ内のコンピューティングノードまたはサービスノードを識別する（すなわち、ノード宛先識別子を識別する）レコードを作成する。635で、プロセス600は、メッセージがプロセス600によってアドレス指定されたノードについて維持する統計も更新する。この更新は、このノードへの新しいデータメッセージの送信を反映する。635の後、プロセスは終了する。

【0141】

LBルールのルール識別子を定義するためにコンテキスト属性を使用するので、コンテキストベースのロードバランサ126は、任意の数のコンテキスト属性に基づいてデータメッセージフローを分散することができる。上述したように、このようなロードバランシング動作の例は、（1）金融部門に関連したデータメッセージフローを全てのロードバランシングプールに分配すること、（2）この部門のトラフィックを高可用性にするために、この部門の第１プールがダウンした場合に全ての金融部門のトラフィックを別のプールへリダイレクトすること、（3）医師のユーザグループ（Doctor's user group）に関連する全てのトラフィックを高可用性にすること、及び（4）金融アプリケーションのためのデータメッセージフローを低遅延サービスノードグループのサービスノード間に分配することを含む。いくつかの実施形態では、ロードバランシングルールは、DCN上の多くのリソースを消費するアプリケーションに、より多くのまたはより少ないリソースを提供するために、トラフィックを分散するために、収集されたリソース消費に関して定義されることも可能である。

【0142】

いくつかの実施形態では、管理プレーンは、データセンタ内のホスト上のVM上で実行されているすべてのプロセスおよびサービスのインベントリを取得する。いくつかの実施形態では、ホスト200のディスカバリエンジン120は、そのホスト上で実行しているVMからこのデータを収集するのを支援する。いくつかの実施形態では、インベントリされたプロセス／サービスは、インベントリされたアプリケーションと呼ばれ、インベントリされたアプリケーションは、ネットワーク入力／出力を利用するすべてのクライアントプロセス、サービスまたはデーモン、および特定のネットワーク接続をリッスンする（すなわち、メッセージを取得する）ために登録したすべてのサーバプロセスを含む。いくつかの実施形態では、ディスカバリエンジンは、GIエージェント250およびMUX 227を使用してこのデータを収集する。

【0143】

すべてのホスト上のすべてのディスカバリエンジンによって収集されたデータに基づいて、管理サーバ（たとえば、ネットワークマネージャおよび／または計算マネージャ）は、実行中のアプリケーションのインベントリを構築する。いくつかの実施形態では、各アプリケーションは、VM205から取得されたそのファイルハッシュを、管理プレーンのアプリケーションデータ記憶装置に格納されたアプリケーションファイルのハッシュと比較することによって識別される。いくつかの実施形態における管理プレーンは、管理プレーンがスケジュールに応じてそのインベントリをリフレッシュすることができるように、ディスカバリエンジンにそれらのデータ収集を更新させる。

【0144】

次いで、いくつかの実施形態における管理プレーンは、管理者が、LBエンジン126のためのコンテキストベースのLBルールおよび／またはポリシー（ならびに他のサービスエンジン130のためのサービスルール）を作成することを可能にするためのルール作成インターフェースを提供する。ルール作成インターフェースは、管理者が、ディスカバリエンジン120によって収集されたデータ、およびコンテキストエンジン110によって、および他の管理サーバクラスタとの管理プレーンのインターフェースによって収集されたコンテキスト属性を介してインベントリされたアプリケーションに基づいて、高レベルLBポリシー（および他のサービスポリシー）を定義することを可能にする。

【0145】

高レベルのLBポリシー（および他のサービスポリシー）が管理プレーンで定義されると、管理プレーンは、これらのポリシーの一部またはすべてをホスト200上の管理プロキシ（図示せず）に直接供給し、および／またはこれらのポリシーの一部またはすべてを、コントローラのセット（たとえば、ネットワークコントローラ）を介してこれらのプロキシに間接的に供給する。いくつかの実施形態では、管理プロキシは、受け取ったポリシーをルールとしてコンテキストベースのサービスルール記憶装置140に公開する。いくつかの実施形態では、プロキシは、これらのポリシーを、コンテキストベースのサービスルール記憶装置140に公開する前に変換する。例えば、いくつかの実施形態では、ポリシーは、関連付けられたサービスノードおよび／または論理ネットワークを識別するAppliedToタプルを用いて公開される。これらの実施形態のいくつかでは、ホスト上の管理プロキシは、サービスルールとしてポリシーをサービスルール記憶装置140にプッシュする前に、各サービスポリシーからAppliedToタプルを削除する。また、上述したように、いくつかの実施形態におけるホスト200上のコンテキストエンジン110は、サービスエンジンのためのルールを生成するために、収集されたコンテキスト属性に基づいてポリシーを解決する。

【0146】

ファイアウォールエンジン128は、L2～L4パラメータに関してだけでなく、コンテキスト属性に関しても指定することができるファイアウォールルールに基づいてそのファイアウォール動作を実行する、コンテキストベースのファイアウォールエンジンである。図7は、そのようなファイアウォールルールのいくつかの例を示す。この図は、いくつかの実施形態のファイアウォールルールデータストア140を示す。図示のように、各ファイアウォールルールは、ルール識別子705およびファイアウォールアクションパラメータ710を含む。

【0147】

いくつかの実施形態では、ファイアウォールアクションパラメータ710は、許可、ドロップ、再ルーティングなど、従来のファイアウォールアクションのいずれか1つを指定することができる。各ルール識別子705は、データメッセージフローに一致するルールを識別するために使用することができる１以上のデータタプルを指定する。図示のように、ルール識別子は、いくつかの実施形態では、任意のL2～L4パラメータ（例えば、送信元IPアドレス、送信元ポート、宛先ポート、プロトコルなど）を含むことができる。これらのパラメータのうちの１以上は、仮想パラメータ（たとえば、宛先クラスタのVIP）または論理識別子（たとえば、論理ネットワーク識別子）とすることができる。

【0148】

いくつかの実施形態では、ルール識別子はまた、AppID、アプリケーション名、アプリケーションバージョン、ユーザID、グループID、脅威レベル、およびリソース消費などのコンテキスト属性を含むことができる。いくつかの実施形態では、ファイアウォールエンジンは、１以上のメッセージ属性（たとえば、5タプルヘッダ値、コンテキスト属性）をルール識別子705と比較して、一致するルール識別子を有する最高優先順位のルールを識別することによって、ファイアウォールデータ記憶装置を検索する。

【0149】

いくつかの実施形態では、異なるホスト上の異なるファイヤウォールエンジン128は、同じセットのファイヤウォールルールを実施する。例えば、いくつかの実施形態では、異なるファイヤウォールエンジン128は、1つの論理ネットワークのVMのための異なるホスト上の同じファイヤウォールルールを処理して、これらのVMによって送信または受信されるデータメッセージ上にあるレベルのセキュリティを提供する。この論理ネットワークの場合、これらのファイアウォールエンジン128は、集合的に、複数のホストにわたって広がる分散ファイアウォールエンジン（すなわち、単一の概念的論理ファイアウォールエンジン）を形成する。

【0150】

図8は、いくつかの実施形態のコンテキストベースのファイアウォールルールのいくつかのより詳細な例を示す。これらの例では、各ルールのルール識別子705は、5タプル識別子および１以上のコンテキスト属性に関して表現される。各ルールは、これらの属性の値が問題にならないことを指定するために、アスタリスクによって指定されたワイルドカード値である、その5タプル識別子内に１以上の属性を有する（すなわち、データメッセージフローは、ルールのマッチングに失敗することなく、これらの属性について任意の値を持つことができる）。

【0151】

第1のルール835は、Skypeバージョン1024からのすべてのデータメッセージフローをドロップすべきであることを指定する。このルールのためのルール識別子は、データメッセージフローのコンテキスト属性に関してのみ表現される。上述のように、また以下でさらに説明するように、ファイアウォールエンジン128は、新しいデータメッセージフローを識別するたびに、コンテキストエンジンと対話することによって、またはその属性マッピング記憶装置223内のレコードを検査することによって、フローの5タプル識別子のコンテキスト属性を指定するレコードを識別して、フローのコンテキスト属性を識別する。

【0152】

第2のルール830は、Nursesに等しいグループIDおよびYouTubeトラフィックに等しいAppIDを有するすべてのデータメッセージフローがドロップされることを指定する。このルールを実施することによって、ファイアウォールエンジン128は、そのVM 205にログインする看護師（Nurses）がYouTubeトラフィックを見ることができないことを確実にすることができる。この場合も、このルールのためのルール識別子は、データメッセージフローのコンテキスト属性に関してのみ表現される。この例では、コンテキスト属性は、グループIDおよびAppIDである。

【0153】

図9は、ファイアウォールエンジン128による第2のルール830の実施を示す例を表している。具体的には、このファイアウォールエンジン128は、ブラウザ910からの第1のデータメッセージ905が通過することを可能にする一方で、このブラウザからの第2のデータメッセージ915をブロックすることを示す。図示のように、これらのデータメッセージは両方とも、看護師（nurse）920がブラウザ上で実行した操作に関連付けられている。第1のデータメッセージフローは、看護師（Nurses）がブラウザを介して送信している電子メールに関連するので、通過することが許可される。このファイアウォールエンジン128は、メッセージがブロックされることを要求するどのファイアウォールルールとも一致しないので、このメッセージが通過することを可能にする。一方、ファイアウォールエンジン128は、YouTubeビデオを見ようとする看護師（Nurses）に関連するので、第2のデータメッセージをブロックし、このタイプのデータメッセージフローは、ルール830によって禁止される。

【0154】

図8の第3のルール825は、高脅威レベルインジケータに関連するすべてのデータメッセージフローが特定の宛先IPアドレスAに向かう場合、ブロックされるべきであることを指定する。このルールのルール識別子は、データメッセージの5タプル識別子内のコンテキスト属性（すなわち、高脅威レベルインジケータ）および1つの属性（宛先IPアドレス）に関して定義される。

【0155】

図10は、2つの段階で、ファイアウォールエンジン128によるこのルール825の実施を示す例を示す。具体的には、第1の段階1002では、ファイアウォールエンジン128は、データメッセージ1010がVM 205から、特定の宛先IPアドレスAを有する別のVM 1020（ホストの外部）に渡されることを可能にし、第2の段階1004では、アプリケーション1005がVM 205にインストールされることを示す。このアプリケーションは、脅威検出器132によって高脅威アプリケーションとして指定される。新しいデータメッセージフローがVM上で開始するときはいつでも、コンテキストエンジンは、このデータメッセージフローを高脅威レベルタグに関連付ける。したがって、第2のステージ1004では、ファイアウォールエンジン128は、このデータメッセージが高脅威レベルに関連付けられているので、VM 205から他のVM 1020へのデータメッセージ1050をブロックし、ルール815は、そのようなデータメッセージがVM 1020のIPアドレスAに送信されることを禁止する。

【0156】

図8の第4および第5のルール820および815は、医師および看護師（Doctor and Nurses）グループに関連するデータメッセージがVIPアドレスAに関連するVMにアクセスすることができるが、会計士グループに関連するデータメッセージはこれらのVMにアクセスすることができないことを指定する。第4のルールのためのルール識別子は、データメッセージの5タプル識別子における2つのコンテキスト属性（すなわち、医師および看護師グループ識別子）および1つの属性（VIP宛先アドレスA）に関して定義される。第5のルールのためのルール識別子は、データメッセージの5タプル識別子における1つのコンテキスト属性（すなわち、アカウンタントグループ識別子）および1つの属性（VIP宛先アドレスA）に関して定義される。いくつかの実施形態では、VIPアドレスは、同じ機能を実行するVMのクラスタの宛先であり、ロードバランサは、このVIPアドレスをクラスタ内のVMのうちの1つのIPアドレスに変換する。

【0157】

図11は、ファイアウォールエンジン128による第4および第5のルール820および815の実施を示す例を表している。具体的には、2人のユーザが、ターミナルサーバとして動作している1つのVMに同時にログインしていることを示している。これらのユーザのうちの1人は看護師Xであり、他のユーザは会計士（accountant ）Yである。図11はさらに、ファイアウォールエンジン128が、看護師Xのセッションからの第1のデータメッセージ1105が、宛先IPアドレスVIP Aによって識別されるVMクラスタ1150内のVMに通過することを可能にすることを示している。また、ファイアウォールエンジンが、会計士Yのセッションからの第2のデータメッセージ1110が、このVMクラスタ内のVMのいずれかに到達することを阻止することも示しているが、これは、第5のルール815が、会計士グループIDに関連付けられたデータメッセージが宛先IPアドレスVIP Aに到達することを阻止するためである。

【0158】

図11では、2つのデータメッセージは、VMに同時にログインしている2人の異なる実際のユーザのためのものである。他の場合には、1人のユーザだけが実際にVMにログオンすることができるが、管理プロセスは、ログインしたユーザによって開始されたアプリケーションのために実行されるプロセスと共にVM上で実行されることができる。管理プロセスは、ログインしたユーザとは異なるユーザコンテキストでVMで実行されるサービス／デーモンとすることができる。サービスは、一般に、admin／rootコンテキストで実行され、ログインユーザコンテキストでは実行されない。これは、非ログオンユーザコンテキストで実行されている任意のアプリケーションがネットワークリソースにアクセスすることを可能にする可能性があるので、潜在的なセキュリティホールである。したがって、単一のユーザだけがVMにログインしている場合であっても、ログインしたユーザによって開始されたアプリケーションのために実行されるプロセスに関連するデータメッセージから、バックグラウンド管理プロセスに関連するデータメッセージを異なって扱うファイアウォールルールを指定することが望ましい可能性がある。

【0159】

一例として、第6のルール810は、高セキュリティグループ内の個人によって操作されるアプリケーションに関連するプロセスのデータメッセージが、機密データを有する他のVM（この例では、これらのVMは、IPアドレスVIP Bに関連するVMのクラスタの一部である）にアクセスすることを可能にし、第7のルール805は、バックグラウンド管理プロセスに関連するデータメッセージが、そのようなVMにアクセスすることを阻止する。これは、IT担当者またはハッカーが、適切なクリアランスでユーザのログインセッションをピギーバックオフ（piggyback off）する高セキュリティVMにアクセスする管理プロセスをインストールすることによって、機密データにアクセスするためのバックドアを作成できないことを保証するのに有用である。

【0160】

図12は、ファイアウォールエンジン128による第６および第７のルール810および805の実施を示す例を表している。具体的には、これは、1つのVMから同時に発する2つのデータメッセージフローを示す。1つのデータメッセージフローはCEOに関連付けられ、別のデータメッセージフローはUtility Qと呼ばれるバックグラウンドITユーティリティプロセスに関連付けられる。図12はさらに、ファイアウォールエンジン128が、CEOのセッションからのデータメッセージ1205を、VIPアドレスBによって識別される高セキュリティクラスタ1250内のVMに渡すことを可能にすることを示している。また、第7のルール805は、管理プロセス(Utility Qプロセスなど）に関連付けられたデータメッセージがVIPアドレスBに到達するのを防止するので、Utility Qのセッションからの第2のデータメッセージ1210が高セキュリティクラスタ内のVMのいずれかに到達するのを阻止するファイアウォールエンジンも示している。

【0161】

ファイアウォールエンジンは、2つの異なるログイン／管理証明書のためにVM上で同時に実行される2つの異なるプロセスのためのデータメッセージフローを区別することができるが、これは、コンテキストエンジンが、各フローが開始するときに各データメッセージフローのためのユーザ識別子およびグループ識別子を収集し、各フローをそのユーザ識別子およびグループ識別子に関連付けるからである。図13は、コンテキストエンジンが、GIエージェントから新しいネットワーク接続イベントを受信するたびに、ユーザ識別子およびグループ識別子を収集するために実行するプロセス1300を示す。

【0162】

プロセス1300は、最初に、VM 205上のGIエージェント250から新しいネットワーク接続イベントの通知を受信する（1305）。上述のように、いくつかの実施形態におけるGIエージェントは、新しいネットワーク接続通知において、接続の5タプル識別子、ネットワーク接続を要求するプロセスの識別子、要求するプロセスに関連するユーザ識別子、および要求するプロセスに関連するグループ識別子という情報を提供する。

【0163】

次に、1310で、プロセス1300は、GIエージェントに問い合わせて、新しいネットワーク接続イベントに必要な他のコンテキスト属性を収集する。そのような追加パラメータの例は、ネットワーク接続を要求するプロセスに関連する追加パラメータを含む。1315で、プロセス1300は、１以上のコンテキスト属性レコードを１以上のサービスエンジンに公開する。いくつかの実施形態では、各サービスエンジンへの各コンテキスト属性レコードは、接続の5タプル識別子と、ユーザ識別子および／またはグループ識別子を含む１以上のコンテキスト属性のセットとを含む。次いで、サービスエンジンは、提供されたコンテキスト属性レコードをその属性マッピング記憶装置223に格納し、その結果、サービスエンジンは、これらのレコードを使用して、サービスエンジンが処理する異なるデータメッセージフローに関連するコンテキスト属性セットを識別することができる。異なるユーザアカウントのためにVM上で同時に実行される異なるプロセスのための異なるサービスルールを有するサービスエンジンである場合、コンテキスト属性セットは、ユーザ識別子またはグループ識別子を含み、これらのサービスエンジンがVMからの異なるデータメッセージフローを異なるユーザ／グループ識別子に関連付けることを可能にする。

【0164】

いくつかの実施形態では、コンテキストエンジンは、サービスエンジンのコンテキスト属性レコードに、サービスエンジンによって必要とされないコンテキスト属性を含まない。また、いくつかの実施形態では、コンテキストエンジンは、異なるサービスエンジンが異なるセットのコンテキスト属性を必要とするので、同じネットワーク接続イベントに対して異なるコンテキストエンジンに異なるコンテキスト属性レコードを提供する。上述のように、コンテキストエンジン110は、いくつかの実施形態では、新しいネットワーク接続のためのコンテキスト属性セットをサービスエンジンの一部または全部にプッシュせず、むしろこれらのサービスエンジンにこれらの属性セットをプルさせる。

【0165】

いくつかの実施形態では、コンテキストエンジンは、送信元ホスト上のデータメッセージフローを、送信元VM (すなわち、データメッセージフローの送信元であるVM）と、同じホストまたは異なる宛先ホスト上の宛先VMのコンテキスト属性と関連付けることができる。次いで、これらの実施形態におけるファイアウォールエンジン128は、そのような宛先ベースのコンテキスト属性を使用して、ファイアウォールルールを解決することができる。例えば、ファイアウォールエンジンは、特定のタイプのサーバ（例えば、Sharepointサーバ）にアドレス指定されたすべてのデータメッセージをドロップすることができる。そのような宛先ベースのルールをサポートするために、いくつかの実施形態のコンテキストエンジンは、GIエージェントに、特定のポート上の通知のために登録するプロセスを識別するように指示し、データメッセージフローの宛先として働くアプリケーションを識別するために、プロセス識別子およびハッシュとともにこの情報を使用する。異なるホスト上のコンテキストエンジンによって収集された情報は、管理プレーンによって（例えば、別個のコンピュータ上で、またはVMを実行する同じホスト上で動作する管理サーバによって）収集され、管理プレーンは、このデータを集約し、集約されたデータを他のコンテキストエンジンに配信する。次いで、ホスト上のコンテキストエンジンが分散情報を使用して、これらのホスト上のコンテキストポリシーを解決し、コンテキストベースのルールをこれらのホスト上のコンテキストベースのサービスエンジンに供給することができる。

【0166】

図14は、いくつかの実施形態においてファイアウォールエンジン128が実行するプロセス1400を示す。図示のように、プロセス1400は、ファイアウォールエンジンがその対応するSFEポート260からデータメッセージを（1405で）受信したときに開始する。このポートは、VMまたはVMからデータメッセージを受信すると、このメッセージを中継する。いくつかの実施形態では、ポートは、データメッセージまたはデータメッセージのヘッダ値への参照（例えば、データメッセージを保存するメモリ内のロケーションを識別するハンドル）をファイアウォールエンジンに渡すことによって、データメッセージを中継する。

【0167】

プロセスは、接続状態キャッシュ225が、受信したデータメッセージのメッセージフローに関するファイアウォールアクションを識別するレコードを保存しているかどうかを（1410で）判定する。上述のように、ファイアウォールエンジンが新しいデータメッセージを処理するためにファイアウォールルールを使用するたびに、ファイアウォールエンジンは、いくつかの実施形態では、実行されたファイアウォールアクションを格納するために接続状態キャッシュ225内にレコードを作成し、その結果、ファイアウォールエンジンは、同じフロー内で（すなわち、同じ5タプル識別子を用いて）別のデータメッセージを受信したときに、同じフロー内の前のデータメッセージ上で実行された同じファイアウォールアクションを実行することができる。接続状態キャッシュ225の使用は、ファイアウォールエンジン128がデータメッセージフローをより迅速に処理することを可能にする。いくつかの実施形態では、接続状態キャッシュ225内の各キャッシュされたレコードは、データメッセージ識別子（例えば、5タプル識別子）に関して定義されるレコード識別子を有する。これらの実施形態では、プロセスは、受信されたデータメッセージの識別子（例えば、5タプル識別子）をキャッシュされたレコードのレコード識別子と比較して、受信されたデータメッセージの識別子と一致するレコード識別子を有する任意のレコードを識別する。

【0168】

プロセス1400が（1410で）接続状態キャッシュ225内の受信データメッセージのフローに関するレコードを識別すると、（1415で）プロセスは、このレコードで指定されたファイアウォールアクション（たとえば、許可、ドロップ、再ルーティングなど）を実行する。ファイアウォールアクションが、データメッセージをドロップすることを必要としないと仮定すると、プロセス1400は、処理済みデータメッセージをそのデータパスに沿って送信する。いくつかの実施形態では、この動作は、ファイアウォールエンジンがVMデータメッセージの処理を完了したことを示すために、（プロセス1400を開始するためにファイアウォールエンジンを呼び出した）SFEポート260に通信を返すことを伴う。次いで、SFEポート260は、データメッセージをSFEまたはVMへハンドオフするか、又はI／Oチェーンオペレータにおける別のサービスエンジンをコールして、データメッセージに対して別のサービスオペレーションを遂行することができる。

【0169】

1415で実行されたファイアウォールアクションの結果、データメッセージがドロップされると、プロセス1400は、SFEポート260にこの動作を通知する（1415）。また、1415で実行されるファイアウォールアクションが、データメッセージを再ルーティングすることを要求する場合、プロセス1400は、この再ルーティングを実施するために、データメッセージに対してネットワークアドレス変換を実行し（1415）、次いで、データメッセージをそのデータパスに沿って送信できるように、データメッセージをSFEポートに返す（1415）。1415の後、プロセス1400は終了する。

【0170】

プロセス1400が、（1410で）接続状態キャッシュ225が受信したデータメッセージのフローに関するレコードを格納していないと判定した場合、プロセス1400は、（1420で）このデータメッセージフローに関する１以上のコンテキスト属性を識別する。上述したように、異なる実施形態のサービスエンジンは、この動作を異なるように実行する。例えば、いくつかの実施形態では、ファイアウォールエンジン128は、受信したデータメッセージのヘッダ値（例えば、その5タプル識別子）と一致するレコード識別子を有するレコードについて、属性マッピング記憶装置223をチェックする。次に、この一致するレコードのコンテキスト属性セットを、受信したデータメッセージフローのコンテキスト属性セットとして使用する（1420）。

【0171】

他の実施形態では、ファイアウォールエンジン128は、コンテキストエンジンにクエリを発行して、受信したデータメッセージのコンテキスト属性セットを取得する。このクエリを用いて、ファイアウォールエンジンは、受信したメッセージのフロー識別子（例えば、5タプル識別子）またはその関連するサービストークンを供給する。次に、コンテキストエンジンは、メッセージのフロー識別子またはそれに関連するサービストークンを使用して、前述のように、そのコンテキスト属性記憶装置145内の1組のコンテキスト属性を識別する。

【0172】

プロセス1400は、受信したデータメッセージに関するコンテキスト属性セットを取得すると、この属性セットをメッセージの他の識別子と共に使用して、1405で受信したデータメッセージに関するファイアウォールルールデータストア140内のファイアウォールルールを（1425で）識別する。例えば、いくつかの実施形態では、ファイアウォールルールは、アプリケーション名、アプリケーションバージョン、ユーザID、グループID、AppID、脅威レベル、リソース消費レベルなどの１以上のコンテキスト属性とともに、5タプル属性のうちの１以上に関して定義されるルール識別子705を有する。ファイアウォールルールデータストア140内のファイアウォールルールを識別するために、いくつかの実施形態におけるプロセスは、受信されたデータメッセージのコンテキスト属性および／または他の属性（たとえば、5タプル識別子）をファイアウォールルールのルール識別子（たとえば、ルール識別子705）と比較して、メッセージの属性セットに一致する識別子を有する最高優先順位のルールを識別する。

【0173】

いくつかの実施形態では、プロセスは、この比較動作を実行するために、異なるメッセージ属性セットを使用する。たとえば、いくつかの実施形態では、メッセージ属性セットは、１以上のコンテキスト属性とともに、他の5タプル識別子（たとえば、送信元IP、送信元ポート、宛先ポート、およびプロトコルのうちの１以上）のうちの１以上を含む。いくつかの実施形態では、メッセージ属性セットは、仮想ネットワーク識別子（VNI）、仮想分散ルータ識別子（VDRI）、論理MACアドレス、論理IPアドレスなどの論理ネットワーク識別子を含む。

【0174】

プロセスは、（1425で）ファイアウォールルールを識別した後、（1430で）受信したデータメッセージに対してこのルールのファイアウォールアクション（たとえば、許可、ドロップ、再ルーティングなど）を実行する。ファイアウォールアクションが、データメッセージをドロップすることを必要としないと仮定すると、プロセス1400は、そのデータパスに沿って処理済みデータメッセージを送信する（1430）。いくつかの実施形態では、この動作は、ファイアウォールエンジンがVMデータメッセージの処理を完了したことを示すために、（プロセス1400を開始するためにファイアウォールエンジンを呼び出した）SFEポート260に通信を返すことを伴う。次いで、SFEポート260は、データメッセージをSFEまたはVMへハンドオフするか、又はI／Oチェーンオペレータにおける別のサービスエンジンをコールして、データメッセージに対して別のサービスオペレーションを遂行することができる。

【0175】

1430で実行されたファイアウォールアクションの結果、データメッセージがドロップされると、プロセス1400は、SFEポート260にこの動作を通知する（1430）。また、1430で実行されるファイアウォールアクションが、データメッセージを再ルーティングすることを要求する場合、プロセス1400は、この再ルーティングを実施するために、データメッセージに対してネットワークアドレス変換を実行し（1430）、次いで、データメッセージをそのデータパスに沿って送信できるように、データメッセージをSFEポートに返す（1430）。

【0176】

1430でファイアウォールアクションを実行した後、プロセスは接続状態キャッシュ記憶装置225に記録を作成する（1435）。このレコードは、受信したデータメッセージのフローに対するファイアウォールアクションを識別する。いくつかの実施形態では、このレコードは、データメッセージフローの識別子（例えば、その5つのタプル識別子）を参照することによって定義されるレコード識別子を有する。1435の後、プロセスは終了する。

【0177】

上述のように、いくつかの実施形態における管理サーバは、ホスト上のVM上で実行されているすべてのプロセスおよびサービスのインベントリを取得し、リフレッシュするために、データセンタ内のホスト200上で実行されているディスカバリエンジン120と対話する。いくつかの実施形態では、管理サーバ（上記および以下で管理プレーンとも呼ばれる）は、次いで、管理者が、ファイヤウォールエンジン128のためのコンテキストベースのファイヤウォールルールおよび／またはポリシー（ならびに他のサービスエンジン130のためのサービスルール）を作成することを可能にするためのルール作成インターフェースを提供する。ルール作成インターフェースは、管理者が、ディスカバリエンジン120によって収集されたデータ、およびコンテキストエンジン110によって、および他の管理サーバクラスタとの管理プレーンのインターフェースによって収集されたコンテキスト属性を介してインベントリされたアプリケーションに基づいて、高レベルファイアウォールポリシー（および他のサービスポリシー）を定義することを可能にする。

【0178】

高レベルファイアウォールポリシー（および他のサービスポリシー）が管理プレーンで定義されると、管理プレーンは、これらのポリシーの一部または全部をホスト200上の管理プロキシ（図示せず）に直接供給し、および／またはこれらのポリシーの一部または全部を、コントローラの設定（例えば、ネットワークコントローラ）を介してこれらのプロキシに間接的に供給する。いくつかの実施形態では、管理プロキシは、受け取ったポリシーをルールとしてコンテキストベースのサービスルール記憶装置140に公開する。いくつかの実施形態では、プロキシは、これらのポリシーを、コンテキストベースのサービスルール記憶装置140に公開する前に変換する。例えば、いくつかの実施形態では、ポリシーは、関連付けられたサービスノードおよび／または論理ネットワークを識別するAppliedToタプルを用いて公開される。これらの実施形態のいくつかでは、ホスト上の管理プロキシは、サービスルールとしてポリシーをサービスルール記憶装置140にプッシュする前に、各サービスポリシーからAppliedToタプルを削除する。また、上述したように、いくつかの実施形態におけるホスト200上のコンテキストエンジン110は、サービスエンジンのためのルールを生成するために、収集されたコンテキスト属性に基づいてポリシーを解決する。

【0179】

暗号化エンジン124は、L2～L4パラメータに関してだけでなく、コンテキスト属性に関しても指定することができる暗号化ルールに基づいて、その暗号化／復号化動作を実行するコンテキストベースの暗号化器である。図15は、そのようなコンテキストベースの暗号化ルールの例を示す。これらのルールは、異なるホスト200上の異なる暗号化エンジン124によって独立して使用され、これらのホスト上のVM205によって送受信されたデータメッセージを暗号化／復号化する。このようにして、異なるホスト（例えば、1つのテナントまたは1つの論理ネットワーク）上で同じ暗号化ルールを実施する暗号化エンジン124は、複数のホストにまたがる分散暗号化エンジン（すなわち、単一の概念論理暗号化エンジン）を集合的に形成し、所望の暗号化および復号化動作のセットを一様に実行する。いくつかの実施形態では、各VM 205は、それ自体の暗号化エンジンを有するが、他の実施形態では、1つの暗号化エンジン124は、同じホスト上の複数のVM 205（例えば、同じホスト上の同じテナントのための複数のVM）をサービスすることができる。

【0180】

図15は、いくつかの暗号化ルールを保存する暗号化ルールデータストア140を示す。各暗号化ルールは、（1）ルール識別子1505、（2）暗号化タイプ識別子1510、および（3）鍵識別子1515を含む。各ルール識別子1505は、データメッセージフローに一致するルールを識別するために使用することができる１以上のデータタプルを指定する。いくつかの実施形態では、ルール識別子は、任意のL2～L4パラメータ（例えば、送信元IPアドレス、送信元ポート、宛先ポート、宛先IP、プロトコルなど）を含むことができる。いくつかの実施形態では、これらのL2～L4パラメータは、物理ドメインまたは論理ドメインで定義することができる。また、図示のように、ルール識別子は、AppID、アプリケーション名、アプリケーションバージョン、ユーザID、グループID、脅威レベル、およびリソース消費などのコンテキスト属性を含むことができる。

【0181】

いくつかの実施形態では、暗号化器124は、１以上のメッセージ属性（たとえば、5タプルヘッダ値、コンテキスト属性）をルール識別子1505と比較することによって暗号化ルールデータストア140を検索し、一致するルール識別子を有する最高優先順位のルールを識別する。また、いくつかの実施形態では、暗号化ルールデータストア140は、他のルールがデータメッセージフローに一致しない場合に使用されるデフォルトルールを有する。いくつかの実施形態では、デフォルトルールは、データメッセージフローを暗号化するためのルールが存在しないので、暗号化鍵を指定しない。また、いくつかの実施形態では、デフォルトルールが暗号化器124に返されるとき、暗号化器124は、チェックを実行しているデータメッセージフローを暗号化しない。

【0182】

各暗号化ルールの暗号化タイプ1510は、使用する暗号化／復号化のタイプを指定し、各ルールの鍵識別子1515は、暗号化／復号化に使用する鍵を識別する。いくつかの実施形態では、暗号化ルールは、鍵識別子1515のみを指定し、暗号化タイプ1510を指定しないが、これは、鍵識別子が、鍵と暗号化／復号化のタイプとの両方を識別するか、またはこれらのタイプが、そうでなければ、暗号化器において指定される（例えば、事前構成される）からである。

【0183】

次に、図16から図18を参照して、暗号化エンジン124の暗号化および復号化動作について説明する。いくつかの実施形態では、これらの実施形態は、メッセージを暗号化および復号化するために同じ鍵が使用される、またはメッセージを暗号化および復号化するために同じ鍵の転置されたバージョンが使用される対称暗号化スキームを使用するので、暗号化および復号化操作は、同じ鍵または同じ鍵の転置されたバージョンを使用する。他の実施形態は、非対称暗号化スキーム（例えば、その秘密鍵を使用する送信元暗号化器、および送信元暗号化器の公開鍵を使用する宛先暗号化器）を使用する。

【0184】

図16は、ホスト200上のVM 205によって送信されたデータメッセージを暗号化するために暗号化器124が実行するプロセス1600を示す。図示のように、プロセス1600は、暗号器124がその対応するSFEポート260からデータメッセージを（1605で）受信したときに開始する。このポートは、VMからデータメッセージを受信すると、このメッセージを中継する。いくつかの実施形態では、ポートは、データメッセージまたはデータメッセージのヘッダ値への参照（例えば、データメッセージを保存するメモリ内のロケーションを識別するハンドル）を暗号化器に渡すことによって、データメッセージを中継する。

【0185】

次に、1610で、暗号化器は、その接続状態キャッシュ225が、受信したデータメッセージのキャッシュされた暗号化レコードを保存しているかどうかを判定する。いくつかの実施形態では、いくつかの実施形態では、暗号化器がVMデータメッセージの暗号化ルールを見つけるたびに、暗号化器は、暗号化ルール、暗号化ルールへの基準、暗号化鍵、および／または暗号化鍵の識別子を接続状態キャッシュ225に保存する、キャッシュされた暗号化レコードを作成する。

【0186】

暗号化器は、同じデータメッセージフローの別のデータメッセージを受信したときに、暗号化器が、暗号化ルールデータストア140を検索して、同じフローで後に受信されるデータメッセージの暗号化ルールを識別する必要がないように、このキャッシュレコードを作成する。いくつかの実施形態では、接続状態キャッシュ225内の各キャッシュされたレコードは、データメッセージ識別子（例えば、5タプル識別子）に関して定義されるレコード識別子を有する。これらの実施形態では、プロセス1600は、受信されたデータメッセージの識別子（例えば、5タプル識別子）をキャッシュされたレコードのレコード識別子と比較して、受信されたデータメッセージの識別子と一致するレコード識別子を有する任意のレコードを識別する。

【0187】

プロセス1600が（1610で）接続状態キャッシュ225内の受信データメッセージのキャッシュされた暗号化レコードを識別すると、（1615で）プロセスは、識別された暗号化レコードによって識別された鍵を使用して、受信データメッセージを暗号化する。キャッシュされたレコードが暗号化ルールまたは暗号化ルールへの参照を含む実施形態では、プロセス1600は、保存されたまたは参照されたルールから鍵識別子を取り出し、この識別子を使用して、ホスト200上に格納された鍵データストアから、またはホスト上の鍵マネージャから、またはホストの外部で動作している鍵データストアから鍵を取り出す。同様に、キャッシュされたレコードが鍵識別子を含む実施形態では、プロセス1600は、キャッシュされたレコードから鍵識別子を取り出し、この識別子を使用して、ローカルまたはリモート鍵データストアまたは鍵マネージャから鍵を取り出す。

【0188】

いくつかの実施形態では、プロセスは、識別された暗号化鍵を使用することによって、データメッセージのペイロード（例えば、L2ペイロード）を（1615で）暗号化する一方で、ペイロードの完全性チェック値（ICV）ハッシュ、およびヘッダ値の一部または全部（例えば、物理L3およびL4ヘッダ値、および／または論理L2またはL3ヘッダ値）を生成し、その結果、メッセージの宛先は、（1）データメッセージの暗号化された部分を復号化し、（2）ICV演算に使用されたペイロードおよびヘッダ値の信頼性と完全性を検証しなければならない。

【0189】

データメッセージの一部または全部について、暗号化プロセス1600は、いくつかの実施形態では、データメッセージヘッダの一部も（1615で）暗号化する。論理ネットワークに関連付けられたマシン間で交換されるデータメッセージの場合、いくつかの実施形態は、データメッセージの物理ヘッダ値のすべてを暗号化する。これらの実施形態のいくつかは、論理ネットワーク識別子（例えば、VNI）およびペイロードに対してICV動作を実行し、その結果、宛先ホストにおける復号化器は、暗号化されたデータメッセージの信頼性および完全性を検証することができる。

【0190】

データメッセージを暗号化した後、プロセスは（1615で）、暗号化されたデータメッセージをそのデータパスに沿って送信する。いくつかの実施形態では、この動作は、（プロセス1600を開始するために暗号化器を呼び出した）SFEポート260に通信を返して、暗号化器がデータメッセージのプロセスを完了したことをポートに知らせることを伴う。次いで、SFEポート260は、データメッセージをSFE 210へハンドオフするか、又は別のI／Oチェーンオペレータをコールして、データメッセージに対して別のオペレーションを遂行することができる。1615の後、プロセス1600は終了する。

【0191】

プロセス1600が、接続状態キャッシュ225が、受信されたデータメッセージに一致するキャッシュされたレコードを保存していないと（1610で）判定した場合、プロセス1600は、このデータメッセージフローに関する１以上のコンテキスト属性を（1620で）識別する。上述したように、異なる実施形態のサービスエンジンは、この動作を異なるように実行する。例えば、いくつかの実施形態では、暗号化エンジン124は、受信したデータメッセージのヘッダ値（例えば、その5タプル識別子）と一致するレコード識別子を有するレコードについて、属性マッピング記憶装置223をチェックする。次に、この一致するレコードのコンテキスト属性セットを、受信したデータメッセージフローのコンテキスト属性セットとして使用する（1620）。

【0192】

他の実施形態では、暗号化エンジン124は、コンテキストエンジン110にクエリを発行して、受信したデータメッセージのコンテキスト属性セットを取得する。このクエリにより、暗号化エンジンは、受信したメッセージのフロー識別子（例えば、5タプル識別子）又はそれに関連したサービストークンを供給し、次いで、これを使用して、上述したように、コンテキストエンジンは、そのコンテキスト属性記憶装置145におけるコンテキスト属性のセットを識別する。

【0193】

プロセス600は、受信したデータメッセージのコンテキスト属性セットを取得すると、それ自体によって、またはメッセージの他の識別子（たとえば、5タプル識別子）とともにこの属性セットを使用して、受信したデータメッセージの属性に一致する暗号化ルールデータストア140内の暗号化ルールを（1625で）識別する。たとえば、いくつかの実施形態では、暗号化ルールは、非コンテキスト属性（たとえば、5タプル属性、論理属性など）のうちの１以上、および／またはアプリケーション名、アプリケーションバージョン、ユーザID、グループID、AppID、脅威レベル、リソース消費レベルなどの１以上のコンテキスト属性に関して定義されるルール識別子を有する。暗号化ルールデータストア140内の暗号化ルールを識別するために、いくつかの実施形態におけるプロセスは、受信されたデータメッセージのコンテキスト属性および／または他の属性（たとえば、5タプル識別子）を暗号化ルールのルール識別子（たとえば、ルール識別子1505）と比較して、メッセージの属性セットに一致する識別子を有する最高優先順位のルールを識別する。

【0194】

1625の後、プロセスは、受信したデータメッセージを暗号化すべきであることを指定する暗号化ルールを識別したかどうかを（1630で）判定する。上述のように、暗号化ルールデータストア140は、すべてのデータメッセージに一致するデフォルトの暗号化ルールを有し、他の暗号化ルールが受信されたデータメッセージに一致しないときに返される。いくつかの実施形態におけるデフォルト暗号化ルールは、受信されたデータメッセージが暗号化されるべきでないことを指定する（例えば、非暗号化動作に対応するデフォルト鍵識別子を指定する）。

【0195】

プロセス1600が（1630で）データメッセージを暗号化すべきでないと判定した場合、プロセスは（1635で）暗号化されていないメッセージをメッセージのデータパスに沿って送信する。この動作1630は、データメッセージの処理を完了したことをそのSFEポート260に通知することを伴う。1635の後、プロセスは1645に遷移し、接続状態キャッシュ記憶装置225において、受信したデータメッセージフローに対して暗号化を実行すべきでないことを示すレコードを作成する。いくつかの実施形態では、このレコードは、このフローの5タプル識別子に基づいて、接続状態キャッシュ225内でアドレス指定される。1645の後、プロセスは終了する。

【0196】

プロセスが（1630で）データメッセージを暗号化すべきであると判定した場合、プロセスは（1640で）識別されたルールから鍵識別子を取り出し、この識別子を使用して、前述のように、ローカルまたはリモートの鍵データストアまたはマネージャから鍵を取り出し、取り出された鍵で受信されたデータメッセージを暗号化する。データメッセージのこの暗号化（1640）は、前述の暗号化動作1615と同一である。例えば、上述したように、プロセス1600は、識別された暗号化鍵を使用することによりデータメッセージのペイロード（例えば、L2ペイロード）を暗号化する一方で、ペイロード及びヘッダ値の一部又は全部（例えば、物理的L3及びL4ヘッダ値、論理的L2又はL3ヘッダ値、及び／又はVNI及びVDRIのような論理的ネットワーク識別子）に対してICV動作を実行する。データメッセージの一部または全部について、暗号化プロセス1600は、いくつかの実施形態では、データメッセージのヘッダの一部または全部も（1640で）暗号化する。

【0197】

データメッセージを暗号化した後、プロセスは（1635で）、暗号化されたデータメッセージをそのデータパスに沿って送信する。この場合も、いくつかの実施形態では、この動作は、SFEポート260に通信を返して、暗号化器がデータメッセージの処理を完了したことをポートに知らせることを伴う。次いで、SFEポート260は、データメッセージをSFE 210へハンドオフするか、又は別のI／Oチェーンオペレータをコールして、データメッセージに対して別のオペレーションを遂行することができる。

【0198】

1630で識別される暗号化ルールが、イベントを動的に検出した後に動的に作成されたルールである場合、暗号化器は、データメッセージを暗号化するために使用される鍵の鍵識別子が、送信される前にデータメッセージヘッダに含まれることを（1640で）確実にしなければならない。プロセス1600は、異なる実施形態において、この目標を異なる態様で達成する。いくつかの実施形態では、プロセス1600は、呼び出したポートまたはI／Oチェーンオペレータがデータメッセージヘッダに鍵識別子を挿入できるように、鍵識別子を（呼び出した）SFEポート260に渡す（1640）。例えば、いくつかの実施形態では、1つのサービスエンジン（例えば、別のI／Oチェーンオペレータ）は、オーバーレイ論理ネットワークを確立するために使用されるトンネルヘッダでデータメッセージをカプセル化する。これらの実施形態のいくつかでは、SFEポート260は、プロセス1600から受け取った鍵識別子をこのサービスエンジンに渡し、この鍵識別子をそのヘッダに含めることができるようにする。

【0199】

他の実施形態では、プロセス1600は、鍵識別子をSFEポートに渡さず、このポートは、別のサービスエンジンに、鍵識別子をオーバーレイネットワークのトンネルヘッダにカプセル化させない。これらの実施形態のいくつかでは、SFEポート260は、単に、データメッセージが暗号化されているという指示をオーバーレイネットワークのトンネルヘッダに含むサービスエンジンを有する。これらの実施形態では、宛先DCNを有するホスト上で実行される復号器（例えば、暗号化エンジン124）は、事前構成された情報（例えば、復号化器が、送信元DCNと通信するために指定された前の鍵に基づいて、またはデータメッセージフローのヘッダ値に基づいて正しい鍵を選ぶことを可能にするホワイトボックスソリューション）に基づいて、または使用すべき適切な鍵に関する送信元ホスト上のコントローラまたはモジュールとの帯域外通信に基づいて、データメッセージを復号するために使用すべき正しい鍵を識別することができる。

【0200】

1640の後、プロセスは1645に遷移し、接続状態キャッシュ記憶装置225内で、1625で識別された暗号化ルール、この暗号化ルールへの参照、この暗号化ルールで指定された鍵識別子、および／またはこの鍵識別子によって指定された取り出された鍵を記憶するレコードを作成する。上述のように、このキャッシュされた記録は、いくつかの実施形態では、受信されたデータメッセージの識別子（例えば、5タプル識別子）を含むレコード識別子を有する。1645の後、プロセスは終了する。

【0201】

図17は、SFEポート260または265が、データメッセージの宛先VMを実行する宛先ホスト上で受信する暗号化されたデータメッセージを暗号化エンジン124が復号化するために実行するプロセス1700を示す。この暗号化エンジンは、以下では復号化器と呼ばれる。いくつかの実施形態では、復号化器は、その対応するSFEポートが復号化器を呼び出して、受信したデータメッセージが暗号化されているかどうかをチェックし、暗号化されている場合には、このメッセージを解読するときに、この動作を実行する。

【0202】

いくつかの実施形態では、SFEポートは、受信したデータメッセージが暗号化されているとSFEポートが判定したときに暗号化エンジン124を呼び出す。例えば、いくつかの実施形態では、データメッセージは、トンネルに沿って宛先ホストに送信され、このトンネルのヘッダは、データメッセージが暗号化されることを指定する識別子を有する。いくつかの実施形態では、復号化器は、受信されたデータメッセージのヘッダ値が、データメッセージを復号するための鍵を識別する鍵識別子を指定しない場合にのみ、このプロセスを実行する。ヘッダ値がそのような鍵識別子を指定する場合、復号化器は、以下で説明する図18の復号プロセス1800を使用する。

【0203】

また、いくつかの実施形態では、受信されたデータメッセージは、メッセージが暗号化されているかどうかを指定する値（例えば、ビット）を有する。この値を分析することによって、復号化器は、メッセージが暗号化されているかどうかを知る。この値が、メッセージが暗号化されていないことを指定する場合、復号化器は、暗号化されたメッセージを解読するためにプロセス1700または1800のいずれも呼び出さない。その代わりに、復号化器は、そのデータ経路に沿ってデータメッセージを送ることができることをSFEポートに通知する。

【0204】

図示のように、プロセス1700は、最初に、プロセスが受信データメッセージに適用可能な暗号化ルールを識別するために使用するメッセージ属性のセットを（1705で）識別する。異なる実施形態では、ルールを取り出すために使用されるメッセージ属性セットは、異なるものとすることができる。例えば、いくつかの実施形態では、このメッセージ属性セットは、受信されたデータメッセージの5タプル識別子を含む。いくつかの実施形態では、このメッセージ属性セットはまた、受信されたデータメッセージに関連する論理ネットワーク識別子を含む。

【0205】

1705の後、復号化器は、その暗号化状態キャッシュ225が、1705で識別されたメッセージ属性セットに関するキャッシュされた暗号化ルールを保存しているかどうかを（1710で）判定する。暗号化器と同様に、いくつかの実施形態では、暗号化器がデータメッセージの暗号化ルールを見つけるたびに、暗号化ルール、暗号化ルールへの基準、このルールの鍵識別子、またはこのルールの鍵を接続状態キャッシュ225に保存し、その結果、復号化器が、同じ識別されたメッセージ属性セットを有する別のデータメッセージを受信したとき（たとえば、元のデータメッセージと同じデータフローの一部である別のデータメッセージを受信したとき）、復号化器は、暗号化ルールデータストアを検索して、後に受信されるデータメッセージの暗号化ルールを識別する必要はない。上述のように、接続状態キャッシュ225は、いくつかの実施形態では、データメッセージの5タプル識別子に基づいて暗号化ルールを保存する。したがって、暗号化ルールデータストア140を検索する前に、いくつかの実施形態では、復号化器は、最初に、接続状態キャッシュ225が、受信されたデータメッセージのための一致するキャッシュされたレコードを保存するかどうかを判定する。

【0206】

プロセス1700が（1710で）接続状態キャッシュ225内の受信データメッセージの一致するキャッシュレコードを識別すると、プロセスは（1715で）このレコードを使用して鍵を識別し、次にこの鍵を使用して受信データメッセージの暗号化部分を復号化する。いくつかの実施形態では、キャッシュされたレコードは鍵を含むが、他の実施形態では、このレコードは、鍵識別子または鍵識別子を含むルールまたはルールへの参照を含む。後者の実施形態では、プロセスは、キャッシュされたレコード内の、または格納された、または参照されたルール内の鍵識別子を使用して、ローカルまたはリモートの鍵データストアまたはマネージャから鍵を取り出し、次いで、取り出された鍵を用いて、受信されたデータメッセージの暗号化された部分を復号化する。

【0207】

いくつかの実施形態では、（1715での）復号化動作の一部は、データメッセージヘッダおよびペイロードのICV生成ハッシュを認証することである。具体的には、受信されたデータメッセージの一部（例えば、その物理（例えば、L3またはL4）ヘッダ値、またはその論理（例えば、VNI）ヘッダ値）が、暗号器によるICV操作を介してペイロードとともにハッシュされると、復号化動作は、この部分を検証して、暗号化されたデータメッセージの真正性および完全性を検証する。

【0208】

（1715で）データメッセージを復号化した後、（1715で）プロセスは、復号化されたデータメッセージをそのデータパスに沿って送信する。いくつかの実施形態では、この動作は、SFEポート（プロセス1700を開始するために復号化器を呼び出した）に通信を返して、復号化器がデータメッセージのプロセスを完了したことをポートに知らせることを伴う。次いで、SFEポートは、データメッセージが行先VMに到達できるようにするか、又は別のI／Oチェーンオペレータをコールして、データメッセージに対して別の操作を遂行することができる。1715の後、プロセス1700は終了する。

【0209】

プロセス1700が（1710で）、接続状態キャッシュ225が1705で識別された属性セットの暗号化ルールを格納していないと判定した場合、プロセス1700は（1720で）暗号化ルールデータストア140を検索して、受信したデータメッセージの暗号化ルールを識別する。いくつかの実施形態では、宛先ホストは、暗号化されたデータメッセージを復号化するために、宛先ホストが鍵識別子、または鍵識別子を有する暗号化ルールを識別することができるデータを提供する帯域外通信を、送信元ホストから（直接に、またはコントローラ設定を介して）受信する。これらの実施形態のいくつかでは、帯域外通信は、データメッセージの識別子（例えば、5タプル識別子）を含む。

【0210】

他の実施形態では、宛先ホスト上の暗号化エンジン124は、事前構成された情報に基づいてデータメッセージを復号化するために使用すべき正しい鍵を識別する。例えば、いくつかの実施形態では、送信元ホストおよび宛先ホスト上の暗号化エンジン124は、（1）事前構成されたスキームに従って暗号化鍵をステップスルーする、または（2）データメッセージの属性（例えば、5タプル識別子）に基づいて暗号化鍵を選択する、ホワイトボックスソリューションを使用する。送信元暗号化エンジンおよび宛先暗号化エンジンが、暗号化鍵をステップスルーまたは選択するために同じスキームに従うようにすることによって、ホワイトボックススキームは、宛先ホストの暗号化器124における暗号化エンジンが、データメッセージを暗号化するために使用された送信元ホストの暗号化器124と同じ暗号化鍵を選択して、受信されたデータメッセージを復号化することができることを確実にする。

【0211】

プロセス1700が、鍵を識別する暗号化ルールを見つけることができない場合、プロセス1700は、いくつかの実施形態では、エラー処理プロセスを開始して、暗号化されたメッセージを復号化するための解読鍵の利用不可能性を解決する。いくつかの実施形態では、このエラー処理プロセスは、ネットワークエージェントにクエリを発行して、1705で識別されたメッセージ属性セットの暗号化ルールを保存しているかどうかを判定する。エージェントがそのような暗号化ルールを有する場合、エージェントはそれをプロセスに提供する（1720）。しかしながら、他の実施形態では、エラー処理プロセスは、鍵を取得するためにネットワークエージェントにコンタクトしない。代わりに、管理者が解決するために、この問題にフラグを立てるだけである。

【0212】

プロセスが（1720で）鍵識別子または鍵識別子を有する暗号化ルールを識別すると、（1725で）プロセスは、鍵識別子を使用して、ローカルまたはリモート鍵データストアまたはマネージャから鍵を取り出し、取り出された鍵を用いて受信されたデータメッセージを復号化する。いくつかの実施形態では、（1725での）解読動作の一部は、データメッセージヘッダおよびペイロードのICV生成ハッシュを認証することである。具体的には、受信されたデータメッセージの一部（例えば、その物理（例えば、L3またはL4）ヘッダ値、またはその論理（例えば、VNI）ヘッダ値）が、暗号化器によってペイロードとともにICV操作を介してハッシュされるとき、復号化動作は、この部分を検証して、暗号化されたデータメッセージの真正性および完全性を検証する。

【0213】

データメッセージを復号化した後、プロセスは（1725で）、復号化されたデータメッセージをそのデータパスに沿って送信する。いくつかの実施形態では、この動作は、SFEポート（プロセス1700を開始するために復号化器を呼び出した）に通信を返して、復号化器がデータメッセージのプロセスを完了したことをポートに知らせることを伴う。次いで、SFEポートは、データメッセージが行先VMに到達できるようにするか、又は別のI／Oチェーンオペレータをコールして、データメッセージに対して別の操作を遂行することができる。

【0214】

1725の後、プロセスは1730に遷移し、接続状態キャッシュ記憶装置225内で、1705で識別されたセットに類似するメッセージ属性セットを有するデータメッセージを復号化するために（たとえば、受信されたデータメッセージと同じフローの一部であるデータメッセージを復号化するために）使用されるべき解読鍵またはこの鍵に対する識別子を指定するレコードを作成する。いくつかの実施形態では、このレコードは、受信されたデータメッセージの5タプル識別子に基づいて、接続状態キャッシュ225内でアドレス指定される。1730の後、プロセスは終了する。

【0215】

いくつかの実施形態では、受信された暗号化されたデータメッセージのヘッダ値（例えば、トンネルヘッダ）は、データメッセージを復号するための鍵を識別する鍵識別子を保存する。次に、ホスト機器上の暗号化エンジン124は、鍵識別子によって識別された鍵を使用することによって、その復号化動作を実行する。図18は、暗号化エンジン124が、そのヘッダに鍵識別子を含む暗号化されたデータメッセージを復号化するために実行するプロセス1800を示す。いくつかの実施形態では、暗号化エンジン124内の復号化器は、その対応するSFEポート260または265が復号化器を呼び出して、受信したデータメッセージが暗号化されているかどうかをチェックし、暗号化されている場合には、このメッセージを復号化するときに、この動作を実行する。いくつかの実施形態では、復号化器は、受信されたデータメッセージのヘッダ値が、データメッセージを復号化するための鍵を識別する鍵識別子を指定する場合にのみ、このプロセスを実行する。

【0216】

示されるように、プロセス1800は、最初に、受信されたデータメッセージから鍵識別子を抽出する（1805）。次に、プロセスは、鍵識別子を使用して（1810で）、宛先ホスト上のローカル鍵データストア／マネージャまたは宛先ホスト上にないリモート鍵データストア／マネージャから鍵を取り出し、次いで、この鍵を使用して（1815で）、受信したデータメッセージを復号化する。上述したように、（1815における）復号化動作の一部は、データメッセージのペイロードを用いて暗号化された（受信データメッセージのヘッダおよびペイロードの）ICV生成ハッシュを認証することである。いくつかの実施形態では、プロセス1800は、受信されたデータメッセージと同じデータメッセージフロー内の他のデータメッセージについてこの鍵を識別する必要がないように、鍵をキャッシュデータストア225に記憶する。

【0217】

データメッセージを復号化した後、プロセスは（1820で）、復号化されたデータメッセージをそのデータパスに沿って送信する。いくつかの実施形態では、この動作は、SFEポート（プロセス1800を開始するために復号化器を呼び出した）に通信を返して、復号化器がデータメッセージのプロセスを完了したことをポートに知らせることを伴う。次いで、SFEポートは、データメッセージが行先VMに到達できるようにするか、又は別のI／Oチェーンオペレータをコールして、データメッセージに対して別の操作を遂行することができる。1820の後、プロセス1800は終了する。

【0218】

暗号化ルールのルール識別子を定義するためにコンテキスト属性を使用するので、コンテキストベース暗号器124は、任意の数のコンテキスト属性に基づいてデータメッセージフローを配信することができる。上述したように、そのような暗号化動作の例には、（1)Outlook (任意のマシン上で開始される）からExchangeサーバへのすべてのトラフィックを暗号化すること、（2）3層ウェブサーバ、アプリケーションサーバ、およびデータベースサーバ内のアプリケーション間のすべての通信を暗号化すること、（3)Administrators Active Directoryグループから発生するすべてのトラフィックを暗号化することなどが含まれる。

【0219】

上述のように、いくつかの実施形態における管理サーバは、ホスト上のVM上で実行されているすべてのプロセスおよびサービスのインベントリを取得し、リフレッシュするために、データセンタ内のホスト200上で実行されているディスカバリエンジン120と対話する。次いで、いくつかの実施形態における管理プレーンは、管理者が、暗号化エンジン124のためのコンテキストベースの暗号化ルールおよび／またはポリシー（ならびに他のサービスエンジン130のためのサービスルール）を作成することを可能にするためのルール作成インターフェースを提供する。ルール作成インターフェースは、管理者が、ディスカバリエンジン120によって収集されたデータ、およびコンテキストエンジン110によって、および他の管理サーバクラスタとの管理プレーンのインターフェースによって収集されたコンテキスト属性を介してインベントリされたアプリケーションに基づいて、高レベル暗号化ポリシー（および他のサービスポリシー）を定義することを可能にする。

【0220】

高レベル暗号化ポリシー（および他のサービスポリシー）が管理プレーンで定義されると、管理プレーンは、これらのポリシーの一部または全部をホスト200上の管理プロキシ（図示せず）に直接供給し、かつ／またはこれらのポリシーの一部または全部を、コントローラの設定（例えば、ネットワークコントローラ）を介してこれらのプロキシに間接的に供給する。いくつかの実施形態では、管理プロキシは、受け取ったポリシーをルールとしてコンテキストベースのサービスルール記憶装置140に公開する。いくつかの実施形態では、プロキシは、これらのポリシーを、コンテキストベースのサービスルール記憶装置140に公開する前に変換する。例えば、いくつかの実施形態では、ポリシーは、関連付けられたサービスノードおよび／または論理ネットワークを識別するAppliedToタプルを用いて公開される。これらの実施形態のいくつかでは、ホスト上の管理プロキシは、サービスルールとしてポリシーをサービスルール記憶装置140にプッシュする前に、各サービスポリシーからAppliedToタプルを削除する。また、上述したように、いくつかの実施形態におけるホスト200上のコンテキストエンジン110は、サービスエンジンのためのルールを生成するために、収集されたコンテキスト属性に基づいてポリシーを解決する。

【0221】

プロセス制御（PC）エンジン122は、コンテキスト属性に関して指定することができるPCルールに基づいてそのPC動作を実行するコンテキストベースのPCエンジンである。図19は、そのようなPCルールのいくつかの例を示す。この図は、いくつかの実施形態のPCルールデータストア140を示す。図示するように、各PCルールは、ルール識別子1905およびPCアクション1910を含む。いくつかの実施形態では、PCアクション1910は、（1）許可、（2）停止および不許可、または（3）停止および中断とすることができる。

【0222】

各ルール識別子1905は、データメッセージフローに一致するルールを識別するために使用することができる１以上のデータタプルを指定する。図示のように、ルール識別子は、AppID、アプリケーション名、アプリケーションバージョン、ユーザID、グループID、脅威レベル、リソース消費などのコンテキスト属性を含むことができる。いくつかの実施形態では、PCエンジンは、１以上のメッセージ属性（たとえば、コンテキスト属性）をルール識別子1905と比較することによってPCデータ記憶装置を検索して、一致するルール識別子を有する最高優先順位のルールを識別する。いくつかの実施形態では、ルール識別子1905はまた、データメッセージフローに関連するL2～L4パラメータ（例えば、5つのタプル識別子）を含むことができ、PCエンジンは、フローごとにそのPC動作を実行する。他の実施形態では、PCエンジン122は、イベントを処理するためにそのPC動作を実行するだけであり、フローごとにPC動作を実行するために、それをファイアウォールエンジン128に任せる。したがって、いくつかの実施形態では、PCエンジンのPCルールのルール識別子1905は、L2～L4パラメータを含まない。

【0223】

いくつかの実施形態では、異なるホスト上の異なるPCエンジン122が、PCルールの同じセットを実施する。例えば、いくつかの実施形態では、異なるPCエンジン122は、1つの論理ネットワークのVMに対して異なるホスト上の同じPCルールを処理して、これらのVM上で実行されるプロセス上にあるレベルのセキュリティを提供する。この論理ネットワークの場合、これらのPCエンジン122は、集合的に、複数のホストにわたって広がる分散PCエンジン（すなわち、単一の概念論理PCエンジン）を形成する。

【0224】

図19は、いくつかの実施形態のコンテキストベースのPCルールの3つの詳細な例を示す。第1のルール1920は、Skypeバージョン1024が停止され、不許可にされるべきであることを指定する。いくつかの実施形態では、PCエンジン122は、新しいプロセスイベントを識別するたびに、コンテキストエンジンと対話することによって、またはその属性マッピング記憶装置223内のレコードを検査して、プロセス識別子のコンテキスト属性を指定するレコードを識別することによって、イベントのコンテキスト属性を識別する。

【0225】

第2のルール1925は、高い脅威レベルを有するすべてのプロセスが停止され、不許可にされるべきであることを指定する。上述のように、コンテキストエンジン110またはサービスエンジン130は、脅威検出器132と対話して、プロセスに関連する脅威レベルを評価することができる。いくつかの実施形態では、脅威検出器は、コンテキストエンジン、PCエンジン、または他のサービスエンジンがいくつかのカテゴリのうちの1つに量子化する脅威スコアを生成する。例えば、いくつかの実施形態では、脅威検出器は、0から100までの脅威スコアを生成し、エンジン110または130のうちの1つは、0から33までのスコアを低い脅威レベルに指定し、34から66までのスコアを中程度の脅威レベルに指定し、67から100までのスコアを高い脅威レベルに指定する。

【0226】

第3のルール1930は、YouTubeトラフィックを生成するすべてのプロセスが停止され、中断されるべきであることを指定する。いくつかの実施形態では、このルールはPCエンジンによって実施されるが、他の実施形態では、同様のルールがファイアウォールエンジンによって実施される。ファイアウォールエンジンは、そのようなルールを実施するとき、フローごとにこのルールを実施し、そのアクションは、このフローに関連するパケットをドロップすることである。PCエンジンは、プロセスイベントをチェックするとき、または特定のフロー上でPCチェックを実行するためにSFEポート260によって呼び出されるときに、このルールを実施することができる。

【0227】

図20は、いくつかの実施形態においてPCエンジン122が実行するプロセス2000を示す。図示のように、プロセス2000は、PCエンジンがコンテキストエンジン110からプロセス識別子を受信する（2005）と開始する。コンテキストエンジンは、VM 205上のGIエージェント250からプロセス通知を受信すると、このプロセスIDを中継する。

【0228】

プロセス2000は、接続状態キャッシュ225が、受信したプロセスIDに対するPCアクションを識別する記録を保存しているかどうかを判定する（2010）。PCエンジンが新しいプロセス識別子を処理するためにPCルールを使用するたびに、いくつかの実施形態では、PCエンジンは、接続状態キャッシュ225内にレコードを作成して、実行されたPCアクションを保存し、その結果、PCエンジンは、同じプロセス識別子のより高速な処理のためにこのキャッシュに後で依存することができる。いくつかの実施形態では、接続状態キャッシュ225内のキャッシュされた各レコードは、プロセス識別子に関して定義されるレコード識別子を有する。これらの実施形態では、プロセスは、受信された識別子をキャッシュされたレコードのレコード識別子と比較して、受信されたプロセス識別子と一致するレコード識別子を有する任意のレコードを識別する。

【0229】

プロセス2000が（2010で）接続状態キャッシュ225内の受信したプロセスイベントのレコードを識別すると、プロセスは（2015で）このレコードで指定されたPCアクションを実行する。この動作が不許可または中断である場合、PCエンジンは、コンテキストエンジン110にプロセスを不許可または中断するように指示する。これを行うために、コンテキストエンジン110は、イベントを報告したGIエージェントに、プロセスを不許可または中断するように指示する。次いで、GIエージェントは、OSのプロセスサブシステムに、処理を不許可または中断するように指示する。2015の後、プロセス2000は終了する。

【0230】

プロセス2000が、接続状態キャッシュ225が受信したプロセス識別子のレコードを保存していないと（2010で）判定した場合、プロセス2000は、このプロセス識別子の１以上のコンテキスト属性を（2020で）識別する。上述したように、異なる実施形態のサービスエンジンは、この動作を異なるように実行する。いくつかの実施形態では、PCエンジンは、受信したプロセスイベントの追加のプロセス属性を収集するようにコンテキストエンジンに指示し、コンテキストエンジンは、GIエージェントと対話することによってこの情報を収集する。

【0231】

プロセス2000は、受信したデータメッセージのコンテキスト属性セットを取得すると、この属性セットを使用して、PCルールデータストア140内のPCルールを識別する（2025）。いくつかの実施形態では、PCルールは、アプリケーション名、アプリケーションバージョン、ユーザID、グループID、AppID、脅威レベル、リソース消費レベルなどの１以上のコンテキスト属性に関して定義されるルール識別子1505を有する。データストア140内のPCルールを識別するために、いくつかの実施形態におけるプロセスは、収集されたコンテキスト属性をPCルールのルール識別子（例えば、ルール識別子1905）と比較して、収集された属性セットに一致する識別子を有する最高優先順位のルールを識別する。

【0232】

プロセスは、PCルールを識別すると（2025）、受信したプロセスイベントに対してこのルールのPCアクション（例えば、許可、停止および不許可、停止および中断など）を実行する。この動作が不許可または中断である場合、PCエンジンは、コンテキストエンジン110にプロセスを不許可または中断するように指示する。これを行うために、コンテキストエンジン110は、イベントを報告したGIエージェントに、プロセスを不許可または中断するように指示する。次いで、GIエージェントは、OSのプロセスサブシステムに、処理を不許可または中断するように指示する。2030でPC動作を実行した後、プロセスは接続状態キャッシュ記憶装置225に記録を作成する（2035）。この記録は、受信したプロセスイベントのPCアクションを識別する。2035の後、プロセスは終了する。

【0233】

上述のように、いくつかの実施形態における管理サーバは、ホスト上のVM上で実行されているすべてのプロセスおよびサービスのインベントリを取得し、リフレッシュするために、データセンタ内のホスト200上で実行されているディスカバリエンジン120と対話する。次いで、いくつかの実施形態における管理プレーンは、管理者が、PCエンジン122のためのコンテキストベースのPCルールおよび／またはポリシー（ならびに他のサービスエンジン130のためのサービスルール）を作成することを可能にするためのルール作成インターフェースを提供する。ルール作成インターフェースは、管理者が、ディスカバリエンジン120によって収集されたデータ、およびコンテキストエンジン110によって、および他の管理サーバクラスタとの管理プレーンのインターフェースによって収集されたコンテキスト属性を介してインベントリされたアプリケーションに基づいて、高レベルPCポリシー（および他のサービスポリシー）を定義することを可能にする。

【0234】

高レベルPCポリシー（および他のサービスポリシー）が管理プレーンで定義されると、管理プレーンは、これらのポリシーの一部またはすべてをホスト200上の管理プロキシ（図示せず）に直接供給し、かつ／またはこれらのポリシーの一部またはすべてを、コントローラの設定（たとえば、ネットワークコントローラ）を介してこれらのプロキシに間接的に供給する。いくつかの実施形態では、管理プロキシは、受け取ったポリシーをルールとしてコンテキストベースのサービスルール記憶装置140に公開する。いくつかの実施形態では、プロキシは、これらのポリシーを、コンテキストベースのサービスルール記憶装置140に公開する前に変換する。また、上述したように、いくつかの実施形態におけるホスト200上のコンテキストエンジン110は、サービスエンジンのためのルールを生成するために、収集されたコンテキスト属性に基づいてポリシーを解決する。

【0235】

図21は、いくつかの実施形態において、サービスエンジン130がどのように管理されるかの例を示す。この図は、データセンタ内の複数のホスト200を示す。図示のように、各ホストは、いくつかのサービスエンジン130、コンテキストエンジン110、脅威検出器132、DPIモジュール135、いくつかのVM205、およびSFE 210を含む。また、サービスエンジン130、VM205、およびSFE210を管理するための1組のコントローラ2110も示されている。上述のように、いくつかの実施形態におけるコンテキストエンジン110は、ネットワーク2150を介して（例えば、ローカルエリアネットワーク、ワイドエリアネットワーク、ネットワークのネットワーク（インターネットなど）などを介して）コントローラセット内の管理サーバに渡されるコンテキスト属性を収集する。コントローラ設定は、管理者がこれらの収集されたコンテキスト属性に関してコンテキストベースのサービスルールを定義するためのユーザインタフェースを提供し、これらのポリシーを提供するためにネットワーク2150を介してホストと通信する。ホストはまた、このネットワーク2150を介して互いに通信可能に接続する。

【0236】

上述の多くの特徴及び適用例は、コンピュータで読み出し可能な記録媒体（コンピュータ可読媒体としても参照される）上に記録された命令の組として特定されるソフトウェア処理として実施され得る。これらのプログラムの命令が１つ以上の処理ユニットによって実行される場合（例えば、１つ以上のプロセッサ、プロセッサのコア、又は他の処理ユニット）、これらのプログラムの命令は、命令に示されているアクションを（複数の）処理ユニットに実行させる。コンピュータで読み出し可能なメディアの例は、これに限定されないが、ＣＤ－ＲＯＭ、フラッシュドライブ、ＲＡＭチップ、ハードドライブ、ＥＰＲＯＭ等を含む。コンピュータで読み出し可能なメディアは、キャリア波及び、無線又は有線接続を通過する電子信号を含まない。

【0237】

本明細書では、「ソフトウェア」の語は、読出専用メモリにあるファームウェア、又は磁気記録に格納されたアプリケーションを含み、プロセッサによる処理のためにメモリに読み込むことができる。また、いくつかの実施形態では、複数のソフトウェア発明は、個別のソフトウェア発明を維持する一方で、より大きなプログラムのサブ部分として実施されてもよい。いくつかの実施形態では、複数のソフトウェア発明はまた、個別のプログラムとして実施されてもよい。最後に、ここで説明されるソフトウェア発明をともに実施する個別のプログラムの任意の組み合わせは、発明の範囲内である。いくつかの実施形態では、ソフトウェアプログラムが、１以上の電子システムを動作させるためにインストールされる場合、１以上の特定の機械的実施を定義し、ソフトウェアプログラムの動作を実行する。

【0238】

図22は本発明のいくつかの実施形態が実装されるコンピュータシステム2200を概念的に示す。コンピュータシステム2200は、上述のホスト、コントローラ、およびマネージャのいずれかを実装するために使用することができる。したがって、それは、上述のプロセスのいずれかを実行するために使用することができる。このコンピュータシステムは、様々な種別の非一時的機械可読媒体、及び様々な他の種別の機械可読媒体に対するインタフェースを含む。コンピュータシステム2200は、バス2205、処理ユニット2210、システムメモリ2225、読出専用メモリ2230、永続的記憶装置2235、入力装置2240、及び出力装置2245を含む。

【0239】

バス2205は、コンピュータシステム2200の多くの内部デバイスを通信可能に接続する、全てのシステムバス、周辺バス、及びチップセットバスを集約的に表す。例えば、バス2205は、処理ユニット2210を、読出専用メモリ2230、システムメモリ2225、及び永続的記憶装置2235に通信可能に接続する。

【0240】

処理ユニット2210は、本発明の処理を実行するために、これらの様々なメモリユニットから実行する命令及び処理するデータを検索する。処理ユニットは、異なる実施形態において単一のプロセッサ又はマルチコアプロセッサであり得る。読出専用メモリ（ＲＯＭ）2230は、処理ユニット2210及びコンピュータシステムの他のモジュールによって必要とされる静的データ及び命令を記録する。永続的記憶装置2235は、一方で、読出・書込メモリデバイスである。このデバイスは、コンピュータシステム2200がオフの場合であっても命令及びデータを記録する不揮発性メモリユニットである。本発明のいくつかの実施形態は、（磁気又は光学ディスク、及び対応するディスクドライブなどの）マスストレージデバイスを永続的ストレージデバイス2235として用いる。

【0241】

他の実施形態は、（フロッピーディスク、フラッシュドライブ等のような）取り外し可能な記憶装置を永続的ストレージデバイスとして用いる。永続的ストレージデバイス2235のように、システムメモリ2225は、読出・書込メモリデバイスである。しかしながら、記憶装置2235とは異なり、システムメモリは、ランダムアクセスメモリのような揮発性の読出・書込メモリである。システムメモリは、プロセッサがランタイムにおいて必要とする、いくつかの又は全ての命令及びデータを格納し得る。いくつかの実施形態では、本発明の処理は、システムメモリ2225、永続的記憶装置2235、及び／又は読出専用メモリ2230に記録される。処理ユニット2210は、いくつかの実施形態の処理を実行するために、これらの様々なメモリユニットから実行する命令及び処理するデータを検索する。

【0242】

バス2205はまた、入力装置2240と出力装置2245に接続する。入力デバイスは、ユーザが情報を通信し、コンピュータシステムへのコマンドを選択できるようにする。入力装置2240は、アルファベット表記のキーボードとポインティングデバイス（「カーソル制御デバイス」ともいわれる）とを含む。出力装置2245は、コンピュータシステムによって生成された画像を表示する。出力装置はプリンタ、真空管（ＣＲＴ）又は液晶ディスプレイ（ＬＣＤ）などの表示装置を含む。いくつかの実施形態は、入力及び出力装置の両方として機能するタッチスクリーンのようなデバイスを含む。

【0243】

最後に、図22に示すように、バス2205はまた、コンピュータシステム2200をネットワークアダプタ（不図示）を介してネットワーク2265に接続する。このようにして、コンピュータは、（ローカルエリアネットワーク（「ＬＡＮ」）、ワイドエリアネットワーク（「ＷＡＮ」）、イントラネット、インターネットなどのネットワークのネットワーク、などのコンピュータのネットワークの一部になることができる。コンピュータシステム2200の任意又は全ての構成要素は、本発明に関連して用いられ得る。

【0244】

いくつかの実施形態は、マイクロプロセッサ、コンピュータプログラムの命令を機械で読み出し可能な又はコンピュータで読み出し可能な媒体（或いはコンピュータで読み出し可能なストレージメディア、機械で読み出し可能な媒体、又は機械で読み出し可能なストレージメディアとして参照される）に格納した、記憶装置及びメモリのような電子構成要素を含む。コンピュータで読み出し可能な媒体のいくつかの例は、ＲＡＭ、ＲＯＭ、読出専用コンパクトディスク（ＣＤ－ＲＯＭ）、記録可能コンパクトディスク（ＣＤ－Ｒ）、再書込可能コンパクトディスク（ＣＤ－ＲＷ）、読出専用デジタル多用途ディスク（例えばＤＶＤ－ＲＯＭ、デュアルレイヤＤＶＤ－ＲＯＭ）、様々な記録可能／再書込可能ＤＶＤ（ＤＶＤ－ＲＡＭ、ＤＶＤ－ＲＷ、ＤＶＤ＋ＲＷ等）、フラッシュメモリ（例えばＳＤカード、ミニＳＤカード、マイクロＳＤカード等）、磁気及び／又はソリッドステートハードドライブ、読出専用及び記録可能Ｂｌｕ－Ｒａｙ（登録商標）ディスク、超高密度光ディスク、任意の他の光又は磁気メディア、及びフロッピーディスクを含む。コンピュータ可読媒体は、少なくとも１つの処理ユニットによって実行可能であり、様々な動作を実行するための命令の組を含む、コンピュータプログラムを記録する。コンピュータプログラム又はコンピュータコードの例は、コンパイラによって生成されたような機械コードと、コンピュータ、電子構成要素、又はインタプリタを用いるマイクロプロセッサによって実行される、より高レベルなコードを含んだファイルとを含む。

【0245】

上述の説明は、ソフトウェアを実行するマイクロプロセッサ又はマルチコアプロセッサを主に参照したが、いくつかの実施形態は、特定用途向け集積回路（ＡＳＩＣ）又はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）のような、１つ以上の集積回路によって実行される。ある実施形態では、そのような集積回路は回路自体に格納された命令を実行する。

【0246】

本明細書において使用されるように、「コンピュータ」、「サーバ」、「プロセッサ」及び「メモリ」の語は、全て電子的又は他の技術的デバイスを参照する。これらの語は、人及び人のグループを含まない。本明細書の目的のため、表示及び表示するの語は電子デバイス上に表示することを意味する。本明細書において使用されるように、「コンピュータ可読媒体」、「複数のコンピュータ可読媒体」及び「機械可読媒体」の語は、全体として、コンピュータによって読み出し可能な形式の情報を記録する、有体物、物理的なオブジェクトに制限される。これらの語は、任意の無線信号、有線でダウンロードされた信号、及び任意の他のその場限りの又は一時的な信号を含まない。

【0247】

本発明は多数の特定の詳細を参照して説明されたが、当業者は、本発明が発明の思想から離れることのない他の特定の形式で実施可能であることを認識する。例えば、いくつかの図は処理を概念的に示している。これらの処理の特定の動作は、図示及び説明された正確な順序で実行されないかもしれない。特定の動作は、１つの連続する動作の流れで実行されないかもしれず、異なる特定の動作が異なる実施形態において実行され得る。更に、処理はいくつかの副処理（sub-process）を用いて、又は大きなマクロ処理の部分として実施され得る。従って、当業者は、発明が上述の詳細に限定されず、むしろ添付の請求項の範囲によって定義されることを理解する。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】