JP7157238B2 - Ｓｄｄｃにおけるマルチセグメントアプリケーションを定義する階層型ａｐｉ - Google Patents

Description

本発明は、方法、機械可読媒体、コンピュータデバイス及びシステムに関する。

エンタープライズデータセンタでは、ファイアウォールは、該ファイアウォール上で実行されるアプリケーションのネットワーク形成とセキュリティの本質であった。それは、それぞれがサービスの使用が許可されたホスト及び／またはネットワークのリストを有し、ホストまたは他のレイヤ３で使用可能なポート番号またはＩＰアドレスに適用されるルールを提供する、アクセス制御リスト（ＡＣＬ）に端を発する。ＡＣＬの後、マクロ・セグメンテーションは、ホスト上で実行されるすべてのアプリケーションにＩＰベースの実施を提供するようになった。これにより、企業管理者は、ＶＬＡＮに基づいてワークロードを保護するためのきめ細かなレベルの制御が可能になった。

ネットワーク仮想化では、マイクロ・セグメンテーションにより、Ｌ４－Ｌ７ネットワークサービスと属性とに基づいて、データセンタ内のホスト間に分散したファイアウォールルールを実施する機能が提供されるため、ネットワークとセキュリティの領域を一変させた。トランスポート層でディープ・パケット・イントロスペクションを実行する能力を備え、Ｗｅｂアプリケーションフィルタリング、Ｖｅｒｂベースのファイアウォール、ＵＲＬフィルタリングを含む新しいファイアウォールがある。

図１は、マイクロ・セグメント化されたアプリケーションのファイアウォール制御を指定するための、現在のワークフローを示している。図示されるように、管理者はまず（１０５で）、どのアプリケーションを保護したいかのインテントを定義する必要がある。当該インテントに基づいて、管理者は（１１０で）、ドメインとグループを作成して、アプリケーションの各コンポーネントの境界を定義する必要がある。グループが作成されると、管理者は（１１５で）、通信プロファイルに基づいて、これらのコンポーネントが互いに通信可能となる方法を定義する。

プロファイルおよびグループが作成された後、１２０で、ソフトウェア定義データセンタ（ＳＤＤＣ）ネットワークマネージャ１５０に結果のポリシーが発行される。ポリシーの発行後、管理者は、該管理者が制御するデータセンタのすべてのインスタンスについてネットワークマネージャにログインし、ドメインとグループの作成で指定されたグループ化基準に基づいて、（１２５で）ネットワーク及びセキュリティグループを作成する必要がある。当該基準は、論理スイッチポート、タグ、またはＶＭ／コンテナ名に基づき得る。

管理者は、１２５におけるネットワーク及びセキュリティグループを作成する際に当該基準にマッチするよう、対応するタグを適用してワークロードＶＭ／コンテナを手動で管理する（１３０）必要がある。タグが基準にマッチすると、（１３５で）通信プロファイルで定義されたファイアウォールルールが各ＶＭに適用される。

このアプローチにはいくつかの欠点がある。例えば、グループ化基準（タグ、ＶＭ名等）の管理は、手動で面倒である。これは、当該管理が複数の環境（例えば、開発、ステージング、及び生産）にわたって繰り返されなければならないため、特に問題である。さらに、アプリケーションの検出と分類は、管理上のオーバーヘッドであり、しばしばエラーを起こしやすい。このアプローチは、保護されているエンティティが本質的に一時的なものである場合、動的ワークロード（コンテナ等）環境に対してもスケーラブルではない。

いくつかの実施形態は、マルチセグメントアプリケーションのアプリケーションセグメントがどのように定義または変更されるべきか、及びこれらのセグメント間の通信プロファイルがどのように定義または変更されるべきかを表現するアプリケーションベースのマニフェストを使用することにより、マルチセグメントアプリケーションをデプロイ及び制御するための簡略化されたメカニズムを提供する。いくつかの実施形態では、これらのマニフェストはアプリケーション固有のものである。また、いくつかの実施形態では、ソフトウェア定義データセンタ（ＳＤＤＣ）内のデプロイメントマネージャがこれらのマニフェストをテンプレートとして管理者に提供し、管理者は、データセンタ内にマルチセグメントアプリケーションをデプロイする際に、これらのテンプレートを使用してそのインテントを表現することができる。アプリケーションベースのマニフェストは、ＳＤＤＣにおいて以前にデプロイされたマルチセグメントアプリケーションの制御にも使用できる。このようなマニフェストを使用することにより、管理者は、エンドポイント及びネットワーク属性に基づいてきめ細かなマイクロ・セグメンテーションルールを管理することができる。

マルチセグメントアプリケーションは、複数のアプリケーションセグメントを含むアプリケーションである。いくつかの実施形態では、１以上のアプリケーションセグメントのそれぞれは、マルチセグメントアプリケーションの他のアプリケーションセグメントのメモリ空間と独立した、独自のメモリ空間で実行されるスタンドアロンアプリケーションである。いくつかの実施形態では、マルチセグメントアプリケーションの異なるアプリケーションセグメントは、異なるマシン（例えば、異なるＶＭまたはコンテナ）によって実装される。

いくつかの実施形態では、アプリケーションマニフェストは、マニフェストを実装した後に定義されてもよいし、以前に定義されてもよい、マルチセグメントアプリケーションの構文表現を含む。いくつかの実施形態におけるアプリケーションマニフェストは、（１）１以上のアプリケーションセグメント、及び（２）それらに関連する１以上のポリシーを定義または変更する２以上のコマンドを含む階層型ＡＰＩである。アプリケーションマニフェストは、異なるコマンドを他のコマンドの下に入れ子にすることができるので、階層型ＡＰＩである。例えば、アプリケーションの１つのグループの定義は、グループ内の特定のアプリケーションを実装するための特定のマシン（例えば、特定のＶＭ）の定義を含むことができる。いくつかの実施形態では、アプリケーションマニフェストは、管理者の要件に基づいてアプリケーションをモデル化する能力だけでなく、周知のアプリケーションとその依存関係をカプセル化する、事前定義されたテンプレートとして管理者に提供される。

いくつかの実施形態では、マニフェストは宣言型言語で定義される。いくつかの実施形態では、ＳＤＤＣ内のマニフェスト処理フレームワークは、（１）マニフェスト内で定義されたマルチセグメントアプリケーションのアプリケーションセグメントをデプロイ及び構成するようにＳＤＤＣ内のコンピュートマネージャに指示し、（２）マニフェストによって指定されたアプリケーションセグメント間及びアプリケーションセグメントと他のアプリケーションとの間の通信プロファイルを実装するためのネットワーク転送及びサービスルールを定義及びデプロイするようにＳＤＤＣ内のネットワークマネージャに指示する、いくつかのコマンドにマニフェストをパースする。

ある実施形態では、アプリケーションセグメントは、ＳＤＤＣ内のホストコンピュータ上で、及び／またはスタンドアロンコンピュータとして実行されるＶＭまたはコンテナとしてデプロイされる。同様に、ある実施形態におけるネットワーク転送及びサービスルールは、ソフトウェア転送要素（例えば、ソフトウェアスイッチ及びルータ）とソフトウェアミドルボックスサービスＶＭ（例えば、ＳＤＤＣ内のホストコンピュータ上で実行されるサービスコンテナ及び／またはサービスモジュール）とによって処理される。これらの転送及び／またはサービスルールは、いくつかの実施形態では、ＳＤＤＣにおけるハードウェア転送要素（例えば、トップオブラックスイッチ）、独立型ハードウェアまたはソフトウェアゲートウェイ、及び／または独立型ミドルボックスアプライアンス上にも構成される。

本発明のいくつかの実施形態は、ＳＤＤＣにおいてマルチセグメントアプリケーションをデプロイするための方法を提供する。方法は、最初に、マルチセグメントアプリケーションの複数のアプリケーションセグメントを定義するための複数の操作要求を宣言フォーマットで指定する、階層型ＡＰＩコマンドを受信する。当該方法は、ＡＰＩコマンドをパースしてアプリケーションセグメントを識別する。パースされたＡＰＩコマンドに基づいて、方法は、複数のアプリケーションセグメントのデプロイに必要なソフトウェア定義（ＳＤ）リソースと、これらのセグメント間の転送及びサービス操作をデプロイする。

いくつかの実施形態では、方法が使用するデプロイメントプロセスは、第２のリソースが依存する任意の第１のＳＤリソースが、当該第２のリソースよりも先にデプロイされることを保証する。いくつかの実施形態では、第２のＳＤリソースが第１のＳＤリソースの子である場合、第２のＳＤリソースは第１のＳＤリソースに依存する。代替的に、または付随的に、いくつかの実施形態では、第２のＳＤリソースが第１のＳＤリソースに何らかの動作上の依存性を有する場合、第２のＳＤリソースは第１のＳＤリソースに依存することも可能である。

いくつかの実施形態では、方法は、各セットが１つのリソースレベルで１以上のＳＤリソースを有する、複数のＳＤリソースのセットを識別することにより、ＡＰＩコマンドをパースする。いくつかの実施形態におけるデプロイは、より低いリソースレベルでＳＤリソースをデプロイする前に、より高いリソースレベルで識別されたＳＤリソースセットをデプロイする。階層型ＡＰＩコマンドで指定可能なＳＤリソースの例には、アプリケーションセグメントを実装するためのＳＤコンピュート要素（例えば、ＶＭまたはコンテナ）、アプリケーションセグメントに関連するデータメッセージを転送するための転送ルールを実装するためのＳＤ転送要素（例えば、管理されたソフトウェアスイッチ及びルータ、該管理されたソフトウェアスイッチ及びルータによって実装される論理スイッチ及びルータ等）、及びアプリケーションセグメントに関連するデータメッセージにサービスを実行するためのサービスルールを実施するためのＳＤサービスミドルボックスモジュール（例えば、ファイアウォール操作、ロードバランシング操作、ネットワークアドレス変換操作、暗号化操作、侵入検知操作、侵入防御操作等のミドルボックスサービス操作を実行するサービスＶＭまたはモジュール）が含まれる。

ある実施形態では、ＡＰＩ処理システムがＡＰＩコマンドを処理する。このコマンドは、以前にデプロイされたＳＤリソースを更新するための一連のパラメータを含むことができる。この場合、ＡＰＩ処理システムは、パースされたＡＰＩコマンドで指定された一連のパラメータを使用して、マルチセグメントアプリケーションに対して先にデプロイされたＳＤリソースを更新することで、マルチセグメントアプリケーションをデプロイする。このような場合、ＡＰＩコマンドには、新しいＳＤリソースを定義する一連のパラメータが含まれる。このような場合、ＡＰＩ処理システムは、パースされたＡＰＩコマンドで指定された一連のパラメータに基づいてＳＤリソースをデプロイすることによって、ＳＤリソースをデプロイする。

いくつかの実施形態では、階層型ＡＰＩコマンドが１つのアトミックユニットとして処理される。従って、ＡＰＩ処理システムは、階層型ＡＰＩコマンド内の識別されたＳＤリソースがデプロイ可能であるか否かを判断する。もしそうであれば、ＡＰＩ処理システムは、ＡＰＩコマンドが正常に処理されたという確認を、階層型ＡＰＩコマンドを生成したソースに送信する。そうでなければ、ＡＰＩコマンド内の１以上のＳＤリソースがデプロイ可能でない場合、ＡＰＩ処理システムは、ＡＰＩコマンドが正常に処理されていないというメッセージを、階層型ＡＰＩコマンドを生成したソースに送信する。

いくつかの実施形態は、データコンピュートエンドポイントからのコンテキストをネットワークに結び付けることによって、次世代のマイクロ・セグメンテーションのための道を開く。エンドポイントベースのコンテキストは、ファイルハッシュ、パブリッシャ情報、ライセンス、プロセス情報等のアプリケーション固有の属性だけでなく、ユーザＩＤにも関連し得る。いくつかの実施形態では、コンテキスト情報は、（例えば、仮想化されたネットワーク装置を介して）ＳＤＤＣに配置されたディストリビュータにデプロイされる、アプリケーションベースのファイアウォールによって使用される。アプリケーションベースのファイアウォールをコモディティ化する最大の課題の１つは、このような複雑なファイアウォールの消費モデルであり、これはエンドポイント内では何千ものプロセスが、データセンタ内では何百万ものプロセスが実行され得るからである。しかしながら、アプリケーションマニフェストを使用することにより、いくつかの実施形態は、きめ細かなコンテキストベースのルールを作成し、これらのルールを管理する非常に困難なタスクを管理することを管理者に可能ならしめる新規なアプローチを提供する。

前述の概要は、本発明のいくつかの実施形態の簡単な紹介として役立つことを意図している。これは、本文書に開示されたすべての発明主題の紹介または概略であることを意味するものではない。以下の詳細な説明及び当該詳細な説明で参照される図面は、概要で説明された実施形態、並びに他の実施形態をさらに説明する。従って、本文書により説明されるすべての実施形態を理解するために、概要、詳細な説明、図面、及び特許請求の範囲の完全な検討が必要である。また請求される主題は、概要、詳細な説明、及び図面における例示的な詳細によって限定されるべきではない。

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

図１は、マイクロ・セグメント化されたアプリケーションのファイアウォール制御を指定するための現在のワークフローを示している。 図２は、ＳＤＤＣでテナント管理者から受信したアプリケーションマニフェストを処理するマニフェスト処理フレームワークを示している。 図３は、マニフェスト処理フレームワークの構成要素の操作を示すプロセスを示している。 、 、 、 、 図４Ａ～Ｅは、Ｓｌａｃｋと呼ばれるマルチセグメントアプリケーションを定義するアプリケーションマニフェストの例を示している。 図５は、Ｓｌａｃｋの例を示している。 図６は、図５に示したアプリケーションのデータモデルを示している。 図７は、マニフェストテンプレートに基づいてマルチセグメントアプリケーションを定義及びデプロイするための例示的なフローを表したプロセスを示している。 図８は、いくつかの実施形態のためのこの新しい分類エンジンのアーキテクチャを示している。 図９は、本発明のいくつかの実施形態のＡＰＩ処理システムの一例を示している。 図１０は、いくつかの実施形態が、どのようにコンテキストベースのファイアウォールルールをホストコンピュータで実施するかを示している。 図１１は、データセンタ内のマルチセグメントアプリケーションのデプロイメントについて学習するためのデータ収集の例を示している。 図１２は、本発明のいくつかの実施形態が実装されるコンピュータシステムを概念的に示している。

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

いくつかの実施形態は、マルチセグメントアプリケーションをデプロイ及び制御し、マルチセグメントアプリケーションのセグメント間の通信プロファイルを定義するための単純化されたメカニズムを提供する、新規なアプリケーションベースのマニフェストを提供する。マルチセグメントアプリケーションは、複数のアプリケーションセグメントを含むアプリケーションである。いくつかの実施形態では、各アプリケーションセグメントは、マルチセグメントアプリケーションの任意の他のアプリケーションセグメントのメモリ空間から分離された、固有のメモリ空間で実行されるスタンドアロンアプリケーションであってよい。いくつかの実施形態では、マルチセグメントアプリケーションの異なるアプリケーションセグメントは、異なるマシン（例えば、異なるＶＭまたはコンテナ）によって実装される。

いくつかの実施形態では、ソフトウェア定義データセンタ（ＳＤＤＣ）内のデプロイメントマネージャが、これらのマニフェストをテンプレートとして管理者に提供する。管理者は、これらのテンプレートを使用して、データセンタにマルチセグメントアプリケーションをデプロイする際のインテントを示すことができる。アプリケーションベースのマニフェストは、ＳＤＤＣにおいて以前にデプロイされたマルチセグメントアプリケーションの制御にも使用できる。このようなマニフェストを使用することにより、管理者は、エンドポイント及びネットワーク属性に基づいてきめ細かなマイクロ・セグメンテーションルールを管理することができる。

本文書では、データメッセージは、ネットワークを介して送信される特定のフォーマットのビットのコレクションを参照する。本明細書において、データメッセージという文言が、イーサネットフレーム、ＩＰパケット、ＴＣＰセグメント、ＵＤＰデータグラム等、ネットワークを介して送信され得る種々のフォーマットのビット集合を参照するために用いられ得ることは、当業者により理解されるであろう。また、本文書で用いられるように、Ｌ２、Ｌ３、Ｌ４、及びＬ７レイヤ（またはレイヤ２、レイヤ３、レイヤ４、及びレイヤ７）への参照は、それぞれ、ＯＳＩ(Open System Interconnection)レイヤモデルの第２層のデータリンク層、第３層のネットワーク層、第４層のトランスポート層、及び第７層のアプリケーション層への参照である。

図２は、ＳＤＤＣにおいてテナント管理者から受信したアプリケーションマニフェストを処理するマニフェスト処理フレームワーク２００を示している。当該処理に基づいて、フレームワーク２００は、ＳＤＤＣ内のコンピュートマネージャ及びネットワークマネージャと対話しすることで、マルチセグメントアプリケーションをデプロイし、ＳＤＤＣ内の転送及びサービス要素を構成し、該アプリケーションのセグメント間、及びこれらのセグメントとＳＤＤＣの内部及び外部の他のアプリケーション及びデバイスとの間で、所望の通信ルールを設定する。いくつかの実施形態では、アプリケーションマニフェストはまた、以前にデプロイされたマルチセグメントアプリケーション、及び／または以前にデプロイされたセグメントのための以前に構成された通信プロファイルを調整するための要求を含むことができる。

図示されるように、マニフェストフレームワークは、パーサ２０５、制約チェッカ２１０、ソータ２２０、オーケストレータ２３０、いくつかのルール及びポリシーストレージ２１５、２２５、及び２３５を含む。これら構成要素の操作は、当該構成要素がアプリケーションマニフェストのために実行するプロセス３００を示した図３を参照して説明される。図示されるように、プロセス３００は、マニフェスト処理フレームワーク２００が（３０５で）管理者のマシン２６０から（例えば、アプリケーションマニフェストを指定するために管理者によって使用されるＶＭ、コンテナ、またはスタンドアロンコンピュータから）アプリケーションマニフェストを受信した際に開始する。上述し、以下でさらに説明するように、いくつかの実施形態では管理者は、マニフェスト２５５を指定するために、マニフェストフレームワークによって提供されるアプリケーションマニフェストテンプレートを使用することができる。

いくつかの実施形態において、アプリケーションマニフェスト２５５は、マルチセグメントアプリケーションの構文表現を含む。いくつかの実施形態のアプリケーションマニフェストは、（１）１以上のアプリケーションセグメント、及び（２）各アプリケーションセグメントと、別のアプリケーションセグメントまたはＳＤＤＣの内部または外部の別のアプリケーション／マシンとの間の１以上の通信プロファイルを定義または修正する、２以上のコマンドを含む階層型ＡＰＩである。

アプリケーションマニフェストは、異なるコマンドを他のコマンドの下に入れ子にすることができる階層型ＡＰＩであるため、例えば、ドメイン定義はアプリケーションセグメントグループ定義を含むことができ、その順番にアプリケーションセグメントを実装するための１以上のマシン（例えば、特定のＶＭまたはコンテナ）の１以上の定義を含むことができる。いくつかの実施形態では、マニフェストは宣言型言語で定義される。例えば、マニフェストはある実施形態ではJavascript Object Notation（ＪＳＯＮ）フォーマットで書かれるが、他の実施形態ではＸＭＬ(Extensible Markup Language)フォーマットのような他の階層型フォーマットで表現され得る。

アプリケーションマニフェスト２５５を受信した後、フレームワーク２００のパーサ２０５は、マニフェストに含まれるいくつかの異なる要求（コマンド）を（３１０で）識別する。たとえば、典型的な３層アプリケーションでは、マニフェストはＷｅｂサーバ、アプリケーションサーバ、データベースサーバのデプロイメントを指定できる。このような状況では、パーサはマニフェストを１以上のコマンドの３つのセットにパースし、各セットは、１つの層のデプロイメント（例えばＷｅｂサーバ、アプリサーバ、またはデータベースサーバのデプロイメント）に関連付けられる。ある実施形態では、パーサは、マニフェストから入力ＡＰＩツリーを生成する。入力ＡＰＩツリーは、マニフェストの異なる部分間の親子関係を表す。

パーサがマニフェストをいくつかの個別の要求に分割した後、制約チェッカ２１０は、個別の要求のいずれかが、その制約ストレージ２１５に格納されたポリシー制約に違反するか否かを（３１５で）判定する。もしそうであれば、フレームワークは管理者にエラーを返す。そうではない場合、ソータ２２０は、これらの要求を実装するためのソートされた順序を（３２０で）識別する。このソートされた順序を識別するために、いくつかの実施形態では、ソータは、マニフェストで識別された各ＳＤリソースをそのタイプに従って識別するタイプ固有マップを構築する。これを行うために、いくつかの実施形態では、ソータは、パーサによってマニフェストから構築された入力ＡＰＩツリーの幅優先探索を実行し、リソースタイプに基づいて入力を異なるバケットに分類し、分類された入力をタイプ固有マップに格納する。

タイプ固有マップ内の各キーはリソースタイプであり、各キーの値は入力ＡＰＩツリー内の特定のタイプのすべてのリソースのリストである。各ノード要素は、その親とともに格納される。要約すると、入力ＡＰＩツリーはリソースタイプ、例えば、１つのバケット内のすべての領域、別のバケット内のすべてのグループ等に基づいて分類される。タイプ固有マップを生成した後、ソータは入力ＡＰＩツリーにＳＤリソースを永続化するための実行順序を定義する。ある実施形態では、実行順序は、リソースタイプの事前定義された順序付きリストである。当該リストは、入力ツリー内のリソースを永続化する順序を規定する。新たな型がシステムに導入された場合、実行順序は、該新たな要素の順序を含むように動的に更新される。例えば、いくつかの実施形態におけるサンプル実行順序は、（１）領域、（２）グループ、及び（３）通信マップであってよい。つまり、最初に領域、次にグループ、次に通信マップを作成する必要がある。

次に、ソータはサービスプロバイダレジストリを使用して、構成されたＡＰＩツリー内のＳＤリソースを永続化する。サービスプロバイダレジストリは、コールバックハンドラへのリソースタイプのマップである。コールバックハンドラは、システム内のタイプごとに登録される。コールバックハンドラの責任は、登録されたタイプを永続化することである。以下にさらに説明されるように、コールバックハンドラは、いくつかの実施形態においてデプロイメントプラグインにより実装される。デプロイメントプラグインは、ＡＰＩ処理システムに接続して、受信されたＡＰＩによって要求された変更の永続化、及び永続化された変更のデプロイを処理するモジュールである。

ソータが呼び出し順序を識別し、当該順序に基づいてコールバックハンドラを呼び出してデプロイメントデータを１以上の構成データベースに永続化させると、オーケストレータ２３０は１以上のネットワーク、コンピュート、及び／またはサービスマネージャ２４０と（３２５で）相互作用し、構成データベースに永続化された構成データに基づいてＳＤリソース２５０をデプロイする。いくつかの実施形態では、オーケストレータ２３０は、構成データベースにデータを永続化するためのコールバックハンドラも実装されたデプロイメントプラグインによって実装される。

また、いくつかの実施形態では、ＳＤＤＣリソースマネージャ２４０は、１以上のＳＤＤＣリソースコントローラ２４５を使用して、マルチセグメントアプリケーション及びそれに関連する通信プロファイルをＳＤＤＣリソース２５０にデプロイする。このようなリソースの例は、ホストコンピュータ、ＶＭ、コンテナ、ソフトウェア及びハードウェア転送要素、ソフトウェア及びハードウェアミドルボックスサービス要素等を含む。リソースマネージャ及びコントローラ２４０及び２４５は、（１）マニフェストで定義されたマルチセグメントアプリケーションのアプリケーションセグメントをデプロイ及び構成するコンピュートマネージャ及びコントローラと、（２）マニフェストで指定されたアプリケーションセグメントの通信プロファイルを実装するためのネットワーク転送及びサービスルールを定義及びデプロイするネットワークマネージャ及びコントローラとを含む。

ある実施形態では、アプリケーションセグメントはホストコンピュータ上で実行するＶＭまたはコンテナとして、及び／またはスタンドアロンコンピュータとして、ＳＤＤＣにデプロイされる。同様に、いくつかの実施形態におけるネットワーク転送及びサービスルールは、ソフトウェア転送要素（例えば、ソフトウェアスイッチ及びルータ）と、ＳＤＤＣ内のホストコンピュータ上で実行するソフトウェアミドルボックスサービスＶＭ、サービスコンテナ及び／またはサービスモジュールによって処理される。これらの転送及び／またはサービスルールは、いくつかの実施形態では、ＳＤＤＣ内の、ハードウェア転送要素（例えば、トップオブラックスイッチ）、スタンドアロンハードウェアまたはソフトウェアゲートウェイ、及び／または独立型ミドルボックスアプライアンスにおいても構成される。

図４は、Ｓｌａｃｋと呼ばれるマルチセグメントアプリケーションを定義するアプリケーションマニフェストの例を示している。この例のアプリケーションマニフェストは、マニフェスト処理フレームワークに送信する実際のアプリケーションマニフェストを定義するために使用され得る、階層型ＡＰＩテンプレート４００である。このようなテンプレートは、マルチセグメントアプリケーションをデプロイするためにしばしば順番に呼び出される、共通のセットを指定するメカニズムを提供する。テンプレートＡＰＩを利用することで、管理者は一連のＡＰＩを最初から定義することなく、共通の要求セットをデプロイできる。

マニフェストテンプレート４００から実際のマルチセグメントアプリケーションマニフェストを指定するには、いくつかの実施形態では、管理者は、マニフェストになるテンプレートのコピーにおいて、プレースホルダフィールドと呼ばれる限られた数のフィールドを修正するだけでよい。この観点から、テンプレートＡＰＩは、ブランクフィールドまたはプレースホルダを有する、（１以上のリソースに関しての）１以上の要求セットである。プレースホルダアプリケーション名、アプリケーション識別子（App_ID）、プロセス名、プロセスハッシュ、ユーザ識別子、またはマルチセグメントアプリケーションテンプレートで用いられるその他のキー値ペアの例。一部の実施形態では、管理者は、実際のマニフェストになるテンプレートのコピーの他の構成要素（例えば、セグメントの追加、通信ルールの追加または削除、通信ルールパラメータの変更等）も変更できる。

いくつかの実施形態において、ＡＰＩテンプレートは管理されたリソースである。このことは、プレースホルダのリスト及びＡＰＩオブジェクトであるボディにより表される。図４のＡＰＩテンプレート４００は、Ｓｌａｃｋアプリケーションをデプロイするためのものである。図５は、Ｓｌａｃｋアプリケーション５００の例示的なデプロイメントを示している。このアプリケーションは、図６に図式されたデータモデルを有する。アプリケーション５００及びデータモデル６００の両方は、アプリケーションマニフェスト４００の部分をさらに説明するために、以下でさらに説明される。

アプリケーションマニフェスト４００は、ツリーフォーマットと同等の階層型ＪＳＯＮフォーマットである。ツリーの各ノードは、ＳＤＤＣリソースに対応しており、該ノードのリソースタイプを記述するフィールドを有する。各ノードは、親子関係を示すノードのすべての子を保持する特別なプロパティを有する。子ノードは、順番に複数の子を有することができ、これは任意の深さに行くことができる。従って、各ノードは、（ツリー内の非リーフノードと同様に）同時に親及び子になり得る。

図４において、各ノードは、ノードのタイプを記述するプロパティ「resource_type」を有する。いくつかの実施形態におけるタイプの例は、Infra、Tenant、Domain、Group、CommunicationMap、CommunicationEntry等を含む。これらはすべて、データセンタ内の異なるタイプのリソースである。１つのノードは、該ノードのすべての子を保持するプロパティ「children」を有することもできる。例えば図４において、タイプDomain４１０のノードはタイプInfra４０５の子であり、「Group」及び「CommunicationMap」である２つの異なるタイプの子４１５～４５０を有する。いくつかの実施形態において、TenantはマルチテナントＳＤＤＣにおけるテナントを参照し、Domainはテナント下のワークロードであり、CommunicationMapはセキュリティポリシーであり、CommunicationEntryはセキュリティポリシー下のルールである。

いくつかの実施形態では、各ＳＤリソースは、すべての分類上の親が含まれる、ルートからの一意のパスで識別され得る。例えば、/VMwareは、テナントＶＭｗａｒｅに関連付けられているすべてのリソースを指定する。path/VMware/domains/Outlookは、テナントＶＭｗａｒｅのすべてのＯｕｔｌｏｏｋワークロードを指定する。パス/VMware/domains/Outlook/communication-maps/web-profileは、テナントＶＭｗａｒｅのＯｕｔｌｏｏｋワークロードのｗｅｂプロファイルを指定する。パス/vmware/domains/Outlook/communicationmaps/web-profile/communication-entries/open-browser-accessは、テナントＶＭｗａｒｅのＯｕｔｌｏｏｋワークロードのオープンブラウザアクセスを指定する。より一般的には、セキュリティポリシーのパスのフォーマットは/＜tenant-name＞/domains/＜workload-name＞/communication-maps/＜security-policyname＞/communication-entries/＜rule-name＞のように指定できる。

図４に示されるように、このマニフェストテンプレート４００は、プレースホルダーリスト４０４と共に名前４０２とテンプレートの説明４０３を提供する、テンプレートヘッダ４０１を含む。マニフェストテンプレート４００は、１１の要求４０５～４８０も含む。要求４０５は、Infraと呼ばれる構成を作成するためのものである。この構成は、要求４０５～４５０によって定義される８つの子を有する。要求４１０は、slack_appという領域を定義する。

要求４１５～４４５は、slack_appマルチセグメントアプリケーションの７つのアプリケーションセグメントを定義する。これら７つのセグメントが、図５に示されている。図示されるように、これら７つのセグメントは、（要求４１５によって定義される）ｓｌａｃｋ共有５１５、（要求４２０によって定義される）ｓｌａｃｋベース５２０、（要求４２５によって定義される）ｓｌａｃｋコール５２５、（要求４３０によって定義される）ｓｌａｃｋ編集５３０、（要求４３５によって定義される）ｓｌａｃｋダウンロード５３５、（要求４４０によって定義される）ｓｌａｃｋアップロード５４０、及び（要求４４５によって定義される）ｓｌａｃｋファイル転送５４５を含む。各セグメントについての各要求４１５～４４５は、当該セグメントが、当該セグメントの名前（識別子）と等しく設定されたキーでタグ付けされたＶＭによって実装されることを指定する。

図５及び図６は、これらのセグメント間の通信がｓｌａｃｋベース５２０を通ることを示している。このように、要求４５０は、ｓｌａｃｋベース５２０と他のセグメント５１５及び５２５～５４５のそれぞれとの間のデータメッセージ交換に関する６つの通信ルール（即ち、通信エントリ）に関して、これらのセグメント間の通信プロファイル（すなわち、通信マップ）を定義する。いくつかの実施形態では、これらの６つの通信規則は、データプレーン内のファイアウォールルールによって実装される。図５はまた、いくつかの実施形態において、通信ルール（例えば、ファイアウォールルール）は、ａｐｐＩＤ、プロセス名等、任意の数の異なるコンテキスト属性に基づき得ることを示している。

図示されるように、各通信エントリは、データメッセージのソース（例えば、ソースグループ）、データメッセージの宛先（例えば、宛先グループ）、通信が許可されるか拒否されるかを指定するアクション、及びデータメッセージによって使用されるサービス、ポート及び／またはプロトコルのセットで表現される。通信マップはまた、図５に示されるアクティブディレクトリサービス５９０とｓｌａｃｋベースがどのように通信するかを指定するルール４８０（即ち、通信エントリ）を定義する。いくつかの実施形態では、これらの通信エントリ４５５～４８０は、Ｓｌａｃｋの異なるセグメント間、及び他のマシン（ＳＤＤＣの内部または外部）とこれらのセグメントとの間の通信を制御するために、マニフェスト処理フレームワークによってファイアウォールルールに変換される。

ある実施形態では、テンプレートは、ＧＥＴ、ＰＡＴＣＨ、ＤＥＬＥＴＥ、及びＰＯＳＴコマンドを通じて管理することができる。例えばある実施形態では、GET/policy/templatesは、データベース内のテンプレート識別子のリストを返す。いくつかの実施形態では、GET /policy/templates/＜template-id＞は、特定のテンプレート識別子のためのテンプレートを返す。また、いくつかの実施形態では、テンプレートＪＳＯＮ定義に続くPATCH /policy/templatesは、新しいテンプレートを作成する。いくつかの実施形態では、DELETE /policy/templates/＜template-id＞は、特定のテンプレート識別子が与えられたテンプレートを削除する。

いくつかの実施形態では、POST /policy/templates/＜template-id＞?action=deployは、テンプレートＡＰＩに基づいて階層型ＡＰＩを定義して起動するために規定される。このコマンドは、特定のテンプレート識別子＜template-id＞が与えられたテンプレートをデプロイする。テンプレート内のプレースホルダの値を提供する引数は、ＰＯＳＴリクエストのボディに渡される。プレースホルダ引数を伴うＰＯＳＴコマンドに応答して、いくつかの実施形態では、マニフェスト処理フレームワークのテンプレートマネージャは、識別されたテンプレートをフェッチし、階層型ＡＰＩを定義するためにプレースホルダ値を表す引数を適用し、そして階層型ＡＰＩ内の要求された各操作を識別するための１以上の要求オブジェクトを作成する。このようなテンプレートマネージャについては、以下でさらに説明する。

要するに、マニフェストテンプレート４００は、マルチセグメントアプリケーションを定義するプロセスのセットと、推奨される通信プロファイルのセットとを指定する。これらの定義は、管理者の要件に基づいて管理者が変更できる。つまり、管理者は、これを環境においてを逐語的に使用するか、またはデータセンタで必要と判断された修正を行うかの選択肢を持っている。このＳｌａｃｋ用のサンプルアプリケーションマニフェストは、業界全体の標準として公開することができ、このアプリケーションのデプロイメントやマイクロ・セグメンテーションをより容易にすることができる。

図７は、マニフェストテンプレートに基づいてマルチセグメントアプリケーションを定義及びデプロイするための例示的なフローを表すプロセス７００を示している。図示されるように、プロセス７００は、最初にアプリケーションマニフェストテンプレートのリストを（７０５で）提供する。いくつかの実施形態におけるマニフェストテンプレートは、最も一般的に使用されるマルチセグメントアプリケーションのためのテンプレートである。いくつかの実施形態では、マニフェストテンプレートは、オープンソースであり、コミュニティが主導しているため、これらのアプリケーションの露出度及び精度が高くなる。

次に、７１０で、管理者は、提供されたマニフェストテンプレートのリストから１つのマニフェストテンプレートを選択する。選択されたテンプレートは、管理者がデプロイを所望するマルチセグメントアプリケーション用である。７１５で、管理者は、自身のインテントに基づいてマニフェストを確認する。選択したマニフェストは、テンプレートの発行者によって定義されたデフォルトの構成を使用して、コンピュート、ネットワーク、及びセキュリティのインテントを示す。管理者は、デフォルト設定を受け入れるか、所望のインテントと一致するように変更することができる。

７２０で、管理者は、マニフェストをマニフェスト処理フレームワークに提出して、処理とデプロイメントを行う。マニフェストがフレームワークに公開されると、フレームワークは、マニフェストで指定されたコンピュート、ネットワーク及び／またはサービスリソースを（７２５で）デプロイする。７２５の後、プロセス７００は終了する。

いくつかの実施形態では、フレームワークは、デプロイメント環境から異なるタイプのコンテキスト属性（既存または新たなワークロードで使用されるもの等）を収集し、マニフェスト内の通信エントリの定義に際してこれらの属性を使用者に使用可能ならしめる、ミドルボックスサービスである新しい分類エンジンを使用する。図８は、いくつかの実施形態のためのこの新しい分類エンジンのアーキテクチャを示している。

ＶＭ上で実行されるアプリケーションは、本質的に一時的なものではない。管理者がアプリケーションをインストールすると、通常、これらのアプリケーションは長時間実行される。これは、通常、ＶＭ及びベアメタルサーバに適用される。いくつかの実施形態では、ホストコンピュータ上で実行されているハイパーバイザ上で実行されるコンテキストエンジンは、ゲストＶＭ上で実行中のプロセスのリストを、ＳＤＤＣ管理プレーンに定期的に送信する。アプリケーション発見エンジン８０５は、この情報を受信し、アプリケーション情報及び関連する仮想マシンについての視覚化を提供する。

いくつかの実施形態では、この情報は連続的にポーリングされず、プロセスは自動化されない。従って、いくつかの実施形態では、管理プレーン上の新しい分類垂直は、ＶＭ上で実行中／インストール済みプロセスのリストを検出し、プロセス情報に基づいてそれらにタグを付けるための周期的な同期動作を内部的に実行する。インベントリ垂直８１０は、システム内のＶＭのリストを取得し、内部でセキュリティグループを作成し、これらのＶＭのアプリケーション発見を可能にする。ＶＭで実行されているアプリケーション／プロセスのリストが識別されると、ＶＭにプロセスのタグが付けられる。グルーピング／タグ付けマネージャ８１５は、分類エンジン８００のためのセキュリティグループ及び他のタグ付けデータを収集し、一方、ファイアウォールマネージャ８２０は、デプロイされたファイアウォールから、及びデプロイされたファイアウォールのためのコンテキストデータを収集する。収集されたタグに基づいて、アプリケーションレベルで作成されたポリシーからのインテントは、これらのプロセスのセキュリティグループと通信プロファイルを決定する。

図９は、本発明のいくつかの実施形態のＡＰＩ処理システム９００の一例を示している。このＡＰＩ処理システム９００は、いくつかの実施形態のマニフェスト処理フレームワーク２００を実装する。このシステムでは、各テナントは、別々の環境と見なすことができる１以上のＳＤＤＣインスタンス９０５を含む、ＳＤＤＣクラスタ９０２を作成できる。図示されるように、いくつかの実施形態では、各ＳＤＤＣインスタンス９０５は、ＡＰＩゲートウェイ９２０、ＡＰＩプロセッサ９２５、コンピュートマネージャ９１０、ネットワークマネージャ９１５、コントローラ９４０、テンプレートマネージャ９２７、ポリシーチェッカ９２３、設定データストレージ９３５、及びいくつかのデプロイメントプラグイン９３０を含む。

いくつかの実施形態において、これらの構成要素の２つ以上は、１以上のデータセンタ内の２以上のマシン（例えば、ＶＭ、コンテナ、スタンドアロンサーバ等）において実行され、ネットワークを介して互いに通信する。これらの実施形態または他の実施形態では、各ＳＤＤＣインスタンスは、負荷を分散し、高可用性を実現するために、これらの各構成要素の複数のインスタンスを含む。

コンピュートマネージャ９１０は、ワークロードマシン（例えば、ワークロードＶＭまたはコンテナ）をデプロイして管理する。一方、ネットワークマネージャ９１５は、ネットワークリソース（例えば、ソフトウェアスイッチ及びルータ）及びミドルボックスサービスリソース（例えば、サービスＶＭ及びモジュール）をデータセンタにデプロイする。いくつかの実施形態では、コンピュート及びネットワークマネージャ９１０及び９１５は、１以上のコントローラ９４０を使用して、１以上の構成データストレージ９３５に格納されている構成データを、ホストコンピュータ、転送要素（例えば、ホストコンピュータ上で実行中のソフトウェアスイッチ及びルータ、またはスタンドアロンのスイッチ及びルータ）、サービスマシン（例えば、サービスＶＭ、サービスコンテナ、他のサービスもジュール、及びスタンドアロンサービスアプライアンス）、及びＳＤＤＣ内の他のリソースに配布する。

ＡＰＩゲートウェイ９２０は、ＵＲＬパターンに基づいて、すべてのＡＰＩコマンドをＡＰＩサービスモジュール９２５、または場合によってはＵＩマネージャ９２２にリダイレクトする。ＵＩマネージャ９２２は、グラフィカルユーザインタフェースを介して受信されるＡＰＩコマンドを処理し、これらのコマンドをＡＰＩプロセッサ９２５に指示する。ＡＰＩプロセッサ９２５は、受信されたアプリケーションマニフェストの一部である異なる要求が構成データストレージ９３５に永続化され、正しい順序でデプロイされることを確実にするために、図２及び３に示されるプロセスを実行する。ＡＰＩプロセッサ９２５は、データストレージ９３２に格納するユーザの所望の状態を所有する。いくつかの実施形態では、ＡＰＩプロセッサ９２５は、ＶＭまたはコンテナとして実行される。

図示されるように、いくつかの実施形態では、ＡＰＩプロセッサ９２５は、ＳＤＤＣリソースのマルチセグメントアプリケーション構成を指定するいくつかのマニフェストテンプレート９２９にアクセスできる、テンプレートマネージャ９２７を使用する。テンプレートマネージャ９２７を介して、ユーザは、完成したマニフェストを生成するために、（例えば、ＡＰＩコマンドを介して）テンプレートを選択し、修正することができる。そしてこの完成したマニフェストに基づいて、ＡＰＩプロセッサ９２５は、以前にデプロイされた一連のＳＤＤＣリソースをデプロイまたは更新して、以前にデプロイされたマルチセグメントアプリケーションをデプロイまたは調整できる。

受信したマニフェスト内の要求、または要求された入力を有するマニフェストテンプレートの読み出しによって完成したマニフェストに基づいて、リソースをデプロイするか、以前にデプロイされたリソースを更新するために、いくつかの実施形態では、ＡＰＩプロセッサ９２５は、マニフェストを１つ以上の要求にパースし、ポリシーチェックエンジン９２３を使用して各要求を検証する（即ち、各要求がポリシーストレージ９２４に格納されており、要求で参照されたリソースに適用可能なポリシーで指定された制約を満たすかどうかを指定する）。

いくつかの実施形態では、ポリシーストレージ９２４の各ポリシーは、（１）ポリシーが適用される１以上のデータセンタリソースのセットを指定するターゲットと、（２）指定されたリソースセットに対する操作の制約を指定する式とを含む。いくつかの実施形態では、ポリシーは宣言フォーマットで表現される。故に、マニフェスト内の要求ごとに、ポリシーエンジンは、選択された要求のリソースの属性のセットをポリシーのターゲットと比較して、ポリシーがリソースに適用可能か否かを判断する。１つの適用可能なポリシーを特定した後、ポリシーチェックエンジンは、特定されたポリシーの式が、選択されたリクエストを拒否するか許可するかを要求する制約を指定しているか否かを判断する。

デプロイメントプラグイン９３０を介して、ＡＰＩプロセッサ９２５は、構成データベース９３５のＡＰＩコール内のＳＤリソースデータを永続化する。いくつかの実施形態では、デプロイメントプラグイン９３０は、ＶＭまたはコンテナとして実行される。各プラグイン９３０は、１以上のＳＤリソースタイプをデプロイする実行能力を有する。そのようなタイプの例には、データコンピュートノード（例えば、ＶＭまたはコンテナのようなコンピュートマシン）、分散ファイアウォールルール、エッジファイアウォールルール、Ｌ２及びＬ３転送要素（ソフトウェアスイッチ予備ルータ）、セキュリティグループ、ＶＰＮサービス、ＤＨＣＰサービス、ＤＮＳサービス、ロードバランシングサービス等が含まれる。

これらのサービスをデプロイするために、プラグイン９３０は、コンピュートマネージャ９１０及びネットワークマネージャ９１５と相互作用し、これらは、順番に、１以上のコントローラ９４０と相互作用する。これらのマネージャ及びコントローラを介して、プラグイン９３０は、これらのコンピュータ及びデバイスに所望のＳＤリソースをデプロイするように指示するために、永続的データベース９３５からの構成データをＳＤＤＣ内のホストコンピュータ及びスタンドアロンネットワーク／サービスデバイスに分配する。

いくつかの実施形態では、ＳＤＤＣインスタンスごとに１つの所望の状態およびオーケストレーションサービス（即ち、ＡＰＩ処理モジュール）が存在する。これは、いくつかの実施形態ではコンテナまたはＶＭの形態でデプロイされる、利用可能性の高いサービスである。このサービスは、ユーザのインテントを受け入れ、異なるサービス間でオーケストレーションを実行する。またこのサービスは、ポリシーをプッシュダウンする必要がある実施ポイント（コンピュート及びネットワークマネージャ）の詳細を所有している。

デプロイメントプラグイン９３０は、インテントの実現を提供する。上述したように、いくつかの実施形態では、これらのプラグインのそれぞれは、別個のコンテナまたはＶＭで実行される別個のサービスとしてデプロイされる。いくつかの実施形態では、いくつかのサービスは、単一のコンテナ内に一緒にパッケージ化されるが、設計及び通信の観点では別個のサービスとして実行される。オーケストレーションは所望の状態サービスによって実行されるため、いくつかの実施形態における各プラグインサービスは、起動されるであろうREST APIエンドポイントのセットを公開する。また、いくつかの実施形態では、所望の状態サービスは、異なるサービスにわたって実現されたリソースの状態を返す共通サービスとして働く。これは、いくつかの実施形態では、実現された状態データがプラグインサービスによってデータストア内で更新される場合であっても同様である。

従って、マニフェストの実行は、一挙に所望の状態を生成することになる。システムがインテント全体を検証して永続化できる場合、マニフェストのソースに通知が送信される（例えば、http status code 200 OKが返される）。インテントが作成されると、通知が生成される。これらの通知は、デプロイプラグインによって非同期に消費される。次に、デプロイメントプラグインは、当該インテントを実現することを処理する。ステータスＡＰＩを使用して、システムから実現状況を問い合わせることができる。

いくつかの実施形態では、ＡＰＩ処理システム９００は、階層的にインテントをクエリする能力をユーザに提供する。例えば、いくつかの実施形態では、システムは、一挙にインテント全体を読み取ることを促進するＧＥＴ ＡＰＩを提供する。専用のフラグはＵＲＬパラメータに渡され、階層的にＧＥＴを要求する。パラメータが渡されない場合、一部の実施形態におけるＧＥＴは、通常のＧＥＴとして機能し、単一のリソースが返される。いくつかの実施形態では、階層型ＧＥＴは、ツリー全体またはツリーの部分に対して機能することができ、即ち、階層型ＧＥＴは、ツリー内の任意のレベルから機能することができるため、階層が取得されるノードを指定することができる。

階層型ＧＥＴの別の態様は、いくつかの実施形態におけるフィルタリングである。これらの実施形態において、管理者は、インテントツリーをフィルタして、自分の関心があるタイプのみを閲覧することができる。当該フィルタリングは、単純なタイプベースのフィルタリングであってよく、例えば、管理者は、「Domain」タイプのインテント階層をＧＥＴと言うことができる。高度なフィルタリングメカニズムでは、ユーザは、機能に基づいて意図を取得することを選択することができ、例えば、管理者は、ファイアウォール機能に関連するインテント階層において、すべてのリソースをＧＥＴと言うことができる。

いくつかの実施形態において、ユーザは階層型ＧＥＴを実行し、それを階層型ＰＯＳＴでクラブすることができる。いくつかの実施形態では、管理者は、インテント階層を取得し、それを修正してＰＯＳＴすることができる。これにより、「インポート／エクスポート」のユースケースが有効になる。いくつかの実施形態では、管理者は、マニフェストを取得し、それを格納することもできる。その後、管理者は、以前に取得したインテントを復元できる。

図１０は、いくつかの実施形態がどのように、コンテキストベースのファイアウォールルールをホストコンピュータで実施するかを示している。いくつかの実施形態では、ＳＤＤＣは、ホストコンピュータ上でそのようなコンテキストベースのルールを定義して実施することによって、その所望のセグメンテーション通信プロファイルを達成する。上述したように、マニフェスト処理フレームワークは、マニフェスト内で定義された通信プロファイルールを変換し、それをネットワーク管理層（即ち、ネットワークマネージャクラスタ）がアプリケーションに必要なマイクロ・セグメンテーションを達成するために処理できるルールにコンバートする。

図１０は、グループ化プロバイダを使用して、マニフェストで定義されたこれらのアプリケーションセグメントを、プロセス名／ハッシュに基づいてセキュリティグループにマッピングする一連のルールを受信するネットワーク管理クラスタを示している。ネットワーク管理クラスタは、マニフェストで定義された通信プロファイルに基づいて、これらのプロセスベースのグループに一致する、変換されたファイアウォールルールも受信する。処理ベースのグループ及びファイアウォールルールが作成されると、マネージャクラスタ１００５のファイアウォールマネージャ１０１０は、ルールをＳＤＤＣ内のホストコンピュータ及び他の実施ノードに分配する。

ファイル、モジュール、及び他のプロセスデータをネットワークイベントにマップするため、いくつかの実施形態は、マシン１０１５（例えば、ホストＶＭ及びコンテナ）上で実行されるゲストイントロスペクション（ＧＩ）エージェント１０２０を通じて捕捉されたコンテキストデータを用いる。いくつかの実施形態では、ＧＩエージェント１０２０は、任意のゲストネットワーク接続及びファイルアクセス、並びにその関連プロセスコンテキストを捕捉する。いくつかの実施形態では、すべてのネットワーク接続及びファイルアクセスは、このエージェントによって傍受され、ホスト上で実行されるコンテキストサービスエンジン１０３０に送られる。Ｖｍｗａｒｅ社によって提供されるＥＳＸハイパーバイザでは、コンテキストデータは、Ｍｕｘ １０２５と呼ばれるハイパーバイザコンポーネントを介して、ＧＩエージェントからホストコンピュータ上で実行されるコンテキストエンジンにネットワークイベント及びファイルイベントを送信するための導管として機能するコンテキストエンジン１０３０に送られる。この情報を使用して、コンテキストエンジンは、ゲストＶＭによって開始される、ユーザ、ソースＩＰアドレス、ソースポート、プロトコル、及びプロセス情報についての情報を含むコンテキストテーブル１０３５を更新する。

その後、データコンピュートマシン１０１５がネットワークコネクションを行うと、ホストコンピュータ上で実行するファイアウォールモジュール１０４０は、発信パケットを検査し、コンテキストテーブルからのパケットフローにコンテキスト情報を関連付け、ファイアウォールテーブル内のルールと一致させることによって、プロセスレベルで有効なファイアウォールルールを実施する。ＶＭ上で実行されているプロセスのこのレベルのきめ細かな制御は、管理者が環境にインストールされている未承認のソフトウェア／アプリケーションを検出し、さらにシステム内で実行されている悪意のあるプロセスをブロックすることに役立つ。有効なルールの実現は、ネットワーク管理クラスタに返送され、管理者にデプロイされたアプリケーションのステータスと有効なルールを提供する。コンテキストベースのファイアウォール及び他のミドルボックスサービスエンジンは、２０１８－０１８１４２３として公開された米国特許出願第１５／６５０，２５１号にさらに記載されており、参照により本明細書に組み込まれる。

いくつかの実施形態では、マニフェスト処理フレームワークは、インテントベースの学習エンジンを有する。ゲストマシン（例えば、ゲストＶＭまたはコンテナ）にインストールされたＧＩエージェントを使用して、マニフェスト処理フレームワークは、検出されたネットワークアクティビティに関与するプロセスだけでなく、インストールされたバイナリ、及びこれらのアクティビティに関連するファイル属性も識別することができる。最も一般的な属性には、ファイルハッシュ、パブリッシャ情報、インストールパス、証明書等が含まれる。いくつかの実施形態では、これらの識別されたプロセス及び他の属性は、新しいマルチセグメントアプリケーションテンプレートを生成するために、デプロイメント環境から（例えば、ホストコンピュータから）収集され、学習エンジンによって解析される。収集されて解析されたデータは、一部の管理者が一般的にどのようにマルチセグメントアプリケーション（例えば、新しいマルチセグメントアプリケーション）をデプロイするかを示す。いくつかの実施形態では、学習エンジンは、収集されたデータから共通のデプロイメント属性を判別し、その解析に基づいて、新しいマルチセグメントマニフェストテンプレートを推奨する。

上述したように、ＧＩエージェントによって捕捉されたネットワークイベント及びファイルイベントは、コンテキストテーブルに格納される。ここから、図１１に示されるように、マニフェスト処理フレームワークは、これらの捕捉されたイベントに関するデータを収集することができる。いくつかの実施形態では、このデータは、収集時間とアプリケーションワークロードに応じて非常に大きくなり得るため、別個のサーバクラスタまたはアプライアンスのセットで収集される。この情報は、ホスト内の各ＶＭで見られるすべてのプロセスについて、ホストレベルで格納される。

いくつかの実施形態では、収集されたネットワーク及びファイルイベントデータは、その後、ＶＭ内のプロセスレベルで適切なセグメンテーションを得るためにカスタマイズされたアプリケーションテンプレートを生成するために、集約されてモデル化される。ネットワークイベントごとに、ＧＩ エージェントは、対応するプロセス、ソケット、接続レート、接続のタイプを取得できる。いくつかの実施形態におけるフレームワークは、そのインスタンスでプロセスによって使用されるライブラリと、プロセスによってアクセスされるファイルとを照会するために確立された通信チャネルを有する。

このデータは、ラウンドトリップ時間、一日の時間、及び他のプロセスとの相関関係に加えて、いくつかの実施形態では、教師なしまたは半教師付き機械学習モデルを訓練するために使用される。いくつかの実施形態は、プロセス情報を識別するために１クラスサポートベクタマシン（ＳＶＭ）分類機を使用する。ＳＶＭモジュールは、「正常」なデータが多く、異常を検出する必要があるケースが少ないシナリオで有用である。

１クラスＳＶＭは、新規性検出のための決定関数を学習する教師なしアルゴリズムであり、新しいデータをトレーニングセットと類似または異なるものとして分類する。ＳＶＭは、分類タスクに使用することができる教師付き学習モデルである。典型的には、ＳＶＭには、ｎ－ｄ空間にマッピングすることができるラベル付けされたデータが与えられる。異なるカテゴリは、明確なギャップによって分割され、ＳＶＭは可能な限り広いカテゴリを見つける。新しいデータサンプルは、ギャップのどの側に入るかに基づいて、１つのカテゴリに属するように分類される。一部の実施形態は、見られた新しいデータに基づいて情報を分類または処理し、管理者がネットワークを保護するために必要とする適切なアプリケーションテンプレートのセットを推奨する。このモデルを使用して、いくつかの実施形態は、実行中のアプリケーション及びそれらに対応するプロセスを予測することができる。このようにすることで、モデルは新しいアプリケーションの識別に役立ち、アプリケーションを保護するために適切なアプリケーションテンプレートを推奨する。

上述の実施形態は、いくつかの利点を提供する。それらは、階層型ＡＰＩデータモデルを介してマルチセグメントアプリケーションをデプロイする、インテントベースのＡＰＩ処理システムを提供しており、ユーザはこれらのリソースの永続化や実現の仕組みを気にすることなく、それらのインテント（例えば、複数のアプリケーションセグメントやそれらの間の通信プロファイル）を指定することができる。いくつかの実施形態では、インテントベースのＡＰＩシステムは、単純化された階層型データモデルを参照する単純な宣言型言語を使用することにより、階層型ＡＰＩコマンドを定義することをユーザに可能ならしめる。各階層型ＡＰＩコマンドは、以前のＡＰＩコマンドで特定のＳＤリソースを他のリソースよりも先に作成する必要はなく、ＳＤＤＣ内の複数のリソースレベルで複数のＳＤリソースを定義できる。実際、いくつかの実施形態では、１つの階層型コマンドは、ＳＤＤＣの（例えば、マルチテナントＳＤＤＣの）１つのユーザ（例えば、１つのテナント）のすべてのＳＤリソースの定義に使用することができる。

いくつかの実施形態のマニフェスト処理フレームワークは、データモデルの階層を活用して、単一のＡＰＩ呼び出しで階層の一部または全体を受け入れ、検証し、実現するためのプロセスを提供する。このシステムは、データモデルの固有の知識を利用して、依存性を識別し、インテントの永続化と実現の両方のために、基盤となるサービスを正しい順序で呼び出す。また、すべての永続化は、単一のトランザクションで行われるため、インテント全体がアトミックユニットとして受け入れられるようになる。

受信したマニフェストで定義されたマルチセグメントアプリケーションがデプロイ可能であると、マニフェスト処理フレームワークが決定すると、いくつかの実施形態では、ＡＰＩシステムは非同期プロセスを使用して、管理者からのさらなる入力なしに、適切な順序でリソースを自動的にデプロイする。このプロセスは、１以上のネットワーク、サービス、またはコンピュートマネージャと連携して、デプロイされたリソースに適した作業指示に基づいて、１以上のネットワーク、サービス、またはコンピュートリソースをデプロイまたは更新する。

上記の機能及びアプリケーションの多くは、コンピュータ読み取り可能な記録媒体（コンピュータ可読媒体とも呼ばれる）に記録された一連の命令として指定されるソフトウェアプロセスとして実装される。これらの命令が１以上の処理ユニット（例えば、１以上のプロセッサ、プロセッサコア、または他の処理ユニット）によって実行される場合、それらは、命令に示された動作を該処理ユニットに実行させる。コンピュータ可読媒体の例としては、ＣＤ－ＲＯＭ、フラッシュドライブ、ＲＡＭチップ、ハードドライブ、ＥＰＲＯＭ等を含むが、これらに限定されない。コンピュータ可読媒体は、無線または有線接続を介して通過する搬送波および電気信号を含まない。

本明細書では、「ソフトウェア」という文言は、読み取り専用メモリに常駐するファームウェア、またはプロセッサによって処理するためにメモリに読み取ることができる磁気記憶装置に格納されたアプリケーションを含むことを意味する。またいくつかの実施形態では、複数のソフトウェア発明は、別個のソフトウェア発明を残しながら、より大きなプログラムのサブパーツとして実装され得る。いくつかの実施形態では、複数のソフトウェア発明は、別個のプログラムとしても実装され得る。最後に、ここに記載されるソフトウェア発明を一緒に実装する別個のプログラムの任意の組合せは、本発明の範囲内にある。いくつかの実施形態では、ソフトウェアプログラムは、１以上の電子システム上で動作するようにインストールされた場合、当該ソフトウェアプログラムの動作を実行し実行する１以上の特定のマシン実装を定義する。

図１２は、本発明のいくつかの実施形態が実装されるコンピュータシステム１２００を概念的に示している。コンピュータシステム１２００は、上述のホスト、コントローラ、及びマネージャのいずれかを実装するために使用することができる。このように、それは、上述のプロセスのいずれかを実行するために使用することができる。このコンピュータシステムは、様々なタイプの非一時的な機械可読媒体と、様々な他のタイプの機械可読媒体のためのインタフェースと、を含む。コンピュータシステム１２００は、バス１２０５、処理部１２１０、システムメモリ１２２５、読み取り専用メモリ１２３０、恒久記憶装置１２３５、入力デバイス１２４０、及び出力デバイス１２４５を含む。

バス１２０５は、コンピュータシステム１２００の多数の内部デバイスを通信可能に接続する、すべてのシステムバス、周辺バス、及びチップセットバスを集合的に表す。例えば、バス１２０５は、処理部１２１０を読み取り専用メモリ１２３０、システムメモリ１２２５、及び恒久記憶装置１２３５と通信可能に接続する。

これらの様々なメモリユニットから、本発明のプロセスを実行するために、処理部１２１０は実行すべき命令および処理すべきデータを取得する。処理部は、様々な実施形態において、単一プロセッサまたはマルチコアプロセッサであってもよい。読み取り専用メモリ（ＲＯＭ）１２３０は、処理部１２１０及びコンピュータシステムの他のモジュールによって必要とされる、静的データ及び命令を格納する。一方、恒久記憶装置１２３５は、読み書き可能な記憶デバイスである。当該デバイスは、コンピュータシステム１２００がオフのときでも、命令及びデータを格納する不揮発性メモリユニットである。本発明のいくつかの実施形態は、恒久記憶装置１２３５として大容量記憶装置（磁気または光ディスク、及びそれら対応するディスクドライブ等）を使用する。

他の実施形態は、恒久記憶装置として、取り外し可能な記憶装置（フロッピーディスク、フラッシュドライブ等）を使用する。恒久記憶装置１２３５と同様に、システムメモリ１２２５は、読み書き可能な記憶デバイスである。しかしながら、記憶装置１２３５とは異なり、システムメモリは、ランダムアクセスメモリのような揮発性の読み取り／書き込みメモリである。システムメモリは、実行時にプロセッサが必要とする、命令及びデータの一部を格納する。いくつかの実施形態では、本発明のプロセスは、システムメモリ１２２５、恒久記憶装置１２３５、及び／または読み取り専用メモリ１２３０に格納される。これらの様々なメモリユニットから、いくつかの実施形態のプロセスを実行するために、処理部１２１０は実行すべき命令及び処理すべきデータを取得する。

また、バス１２０５は、入力デバイス１２４０及び出力デバイス１２４５に接続する。入力デバイスは、ユーザがコンピュータシステムに情報を伝達したり、コマンドを選択したりすることを可能にする。入力デバイス１２４０は、英数字キーボード及びポインティングデバイス（「カーソル制御デバイス」とも呼ばれる）を含む。出力デバイス１２４５は、コンピュータシステムによって生成された画像を表示する。出力デバイスは、プリンタと、陰極線管（ＣＲＴ）ディスプレイまたは液晶ディスプレイ（ＬＣＤ）等の表示装置とを含む。一部の実施形態は、入力デバイス及び出力デバイスの両方として機能するタッチスクリーン等の装置を含む。

最後に、図１２に示されるように、バス１２０５はまた、ネットワークアダプタ（不図示）を介してコンピュータシステム１２００をネットワーク１２６５に結合する。このようにすることで、コンピュータは、コンピュータのネットワーク（ローカルエリアネットワーク（「ＬＡＮ」）、ワイドエリアネットワーク（「ＷＡＮ」）、またはイントラネット等）、またはネットワークのネットワーク（インターネット等）の一部であってもよい。コンピュータシステム１２００の任意のまたはすべての構成要素は、本発明と併せて使用されてよい。

いくつかの実施形態は、（コンピュータ読み取り可能な記録媒体、機械可読媒体、または機械読み取り可能な記録媒体と代替的に呼ばれる）機械読み取りまたはコンピュータ読み取りが可能な媒体に、コンピュータプログラム命令を格納する、マイクロプロセッサ、ストレージ及びメモリ等の電子部品を含む。このようなコンピュータ可読媒体のいくつかの例としては、ＲＡＭ、ＲＯＭ、読み取り専用コンパクトディスク（ＣＤ－ＲＯＭ）、記録可能コンパクトディスク（ＣＤ－Ｒ）、書き換え可能コンパクトディスク（ＣＤ－ＲＷ）、読取り専用デジタル汎用ディスク（例えば、ＤＶＤ－ＲＯＭ、二層ＤＶＤ－ＲＯＭ）、様々な記録可能／書き換え可能ＤＶＤ（例えば、ＤＶＤ－ＲＡＭ、ＤＶＤ－ＲＷ、ＤＶＤ＋ＲＷ等）、フラッシュメモリ（例えば、ＳＤカード、ｍｉｎｉＳＤカード、ｍｉｃｒｏＳＤカード等）、磁気及び／またはソリッドステートハードドライブ、読み取り専用及び記録可能なブルーレイ（登録商標）ディスク、超密度光ディスク、任意の他の光または磁気媒体、及びフロッピーディスクが含まれる。コンピュータ可読媒体は、少なくとも１つの処理ユニットによって実行可能であり、様々な動作を実行するための命令のセットを含むコンピュータプログラムを記憶してもよい。コンピュータプログラムまたはコンピュータコードの例には、コンパイラによって生成されるようなマシンコード、及びインタープリタを使用してコンピュータ、電子コンポーネント、またはマイクロプロセッサによって実行される高レベルコードを含むファイルが含まれる。

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

本明細書で用いられる「コンピュータ」、「サーバ」、「プロセッサ」、及び「メモリ」との文言はすべて、電子デバイスまたは他の技術的デバイスを指す。これらの文言は、人間または人間のグループを除外する。本明細書の目的のために、「ディスプレイ」または「表示」との文言は、電子デバイス上に表示することを意味する。本明細書で使用されるように、「コンピュータ可読媒体」、「コンピュータ可読媒体」、及び「機械可読媒体」との文言は、コンピュータによって読み取り可能な形式で情報を格納する、有形の物理的オブジェクトに完全に限定される。これらの文言は、任意の無線信号、有線ダウンロード信号、及び任意の他の刹那的または一時的な信号を除外する。

本発明を多数の特定の詳細を参照して説明してきたが、本発明の精神から逸脱することなく、他の特定の形態で本発明を実施であることは、当業者に理解されよう。従って、当業者は、本発明が前述の例示的な詳細によって限定されるべきではなく、添付の特許請求の範囲によって定義されるべきであることを理解するであろう。

Claims (18)

1. ソフトウェア定義データセンタ（ＳＤＤＣ）においてマルチセグメントアプリケーションをデプロイする方法であって、
   ２以上のアプリケーションセグメントのセットを指定し、該アプリケーションセグメントに関連付けられたデータメッセージフローを制御するルールのセットを定義する階層型ＡＰＩコマンドを受信し、
   前記階層型ＡＰＩコマンドを、デプロイする前記アプリケーションセグメントのセットと前記ルールのセットとを指定する複数の要求にパースし、
   前記階層型ＡＰＩコマンドのパースにより得られた前記複数の要求に基づいて、前記アプリケーションセグメントのセットを実装するために前記ＳＤＤＣ内のマシンのセットをデプロイし、前記アプリケーションセグメントに関連付けられた前記データメッセージフローを制御するために前記ＳＤＤＣ内のネットワーク要素のセットに前記ルールのセットを提供する
   ことを特徴とする方法。
2. 前記ネットワーク要素は、前記アプリケーションセグメント間、及び他のマシンと前記アプリケーションセグメントとの間でデータメッセージを転送するための、管理された転送要素を含むことを特徴とする請求項１に記載の方法。
3. 前記ネットワーク要素は、前記アプリケーションセグメントに送られた、または前記アプリケーションセグメントから送られたデータメッセージに対してミドルボックスサービス操作を実行するためのミドルボックスサービス要素を含むことを特徴とする請求項１に記載の方法。
4. 前記ミドルボックスサービス要素は、ホストコンピュータにおいて実行されるミドルボックスサービスマシンを含むことを特徴とする請求項３に記載の方法。
5. 前記ミドルボックスサービス要素は、ホストコンピュータにおいて実行されるミドルボックスサービスフィルタを含むことを特徴とする請求項３に記載の方法。
6. 前記ミドルボックスサービス操作は、ファイアウォール操作、ロードバランシング操作、ネットワークアドレス変換操作、暗号化操作、侵入検出操作、及び侵入防止操作のうちの少なくとも１つを含むことを特徴とする請求項３に記載の方法。
7. 前記ミドルボックスサービス要素は、ファイアウォールモジュールまたはデバイスを含むことを特徴とする請求項３に記載の方法。
8. 前記マルチセグメントアプリケーションは、前記階層型ＡＰＩコマンドで定義された少なくとも３つのアプリケーションセグメントを有することを特徴とする請求項１に記載の方法。
9. 前記マルチセグメントアプリケーションは、前記階層型ＡＰＩコマンドで定義された５以上のアプリケーションセグメントを有することを特徴とする請求項１に記載の方法。
10. 前記デプロイされたマシンのセットは、仮想マシンを含むことを特徴とする請求項１に記載の方法。
11. 前記デプロイされたマシンのセットは、コンテナを含むことを特徴とする請求項１に記載の方法。
12. 前記階層型ＡＰＩコマンドのパースにより得られた前記複数の要求は、以前にデプロイされたマルチセグメントアプリケーションを更新するパラメータのセットを含み、
    前記マシンのセットのデプロイは、前記階層型ＡＰＩコマンドのパースにより得られた前記複数の要求において指定された前記パラメータのセットに基づく、前記以前にデプロイされたマルチセグメントアプリケーションの更新を含むことを特徴とする請求項１に記載の方法。
13. 前記階層型ＡＰＩコマンドのパースにより得られた前記複数の要求は、以前に提供されたルールのセットを更新するパラメータのセットを含み、
    前記ルールのセットの提供は、前記階層型ＡＰＩコマンドのパースにより得られた前記複数の要求において指定される前記パラメータのセットに基づく、前記以前に提供されたルールのセットの更新を含むことを特徴とする請求項１に記載の方法。
14. ルールの少なくとも１つのサブセットは、アプリケーションセグメント間のデータメッセージフローに関連することを特徴とする請求項１に記載の方法。
15. ルールの少なくとも１つのサブセットは、前記マルチセグメントアプリケーション以外のアプリケーションから前記アプリケーションセグメントに送られたデータメッセージフローに関連することを特徴とする請求項１に記載の方法。
16. ルールの少なくとも１つのサブセットは、前記アプリケーションセグメントから前記マルチセグメントアプリケーション以外のアプリケーションに送られたデータメッセージフローに関連することを特徴とする請求項１に記載の方法。
17. 少なくとも１つの処理ユニットによって実行された場合に、請求項１乃至１６のいずれか１項に記載の、ソフトウェア定義データセンタ（ＳＤＤＣ）においてマルチセグメントアプリケーションをデプロイする方法を実装するコンピュータプログラム。
18. 処理ユニットのセットと、
    前記処理ユニットによって実装された場合に、請求項１乃至１６のいずれか１項に記載の、ソフトウェア定義データセンタ（ＳＤＤＣ）においてマルチセグメントアプリケーションをデプロイする方法を実装するプログラムを格納した機械可読媒体と、
    を有することを特徴とするコンピュータデバイス。

Images