特許 6994123 コンテナネットワークのためのセキュリティ

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

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

(11)【特許番号】

(24)【登録日】2021-12-14

(45)【発行日】2022-01-14

(54)【発明の名称】コンテナネットワークのためのセキュリティ

(51)【国際特許分類】

   G06F 21/60 20130101AFI20220106BHJP

【ＦＩ】

G06F21/60 360

【請求項の数】 20

【外国語出願】

(21)【出願番号】P 2021000209

(22)【出願日】2021-01-04

(65)【公開番号】P2021111396

(43)【公開日】2021-08-02

【審査請求日】2021-01-29

(31)【優先権主張番号】62/956,408

(32)【優先日】2020-01-02

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

(31)【優先権主張番号】17/125,551

(32)【優先日】2020-12-17

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

(73)【特許権者】

【識別番号】501228071

【氏名又は名称】エスアールアイ インターナショナル

【氏名又は名称原語表記】ＳＲＩ Ｉｎｔｅｒｎａｔｉｏｎａｌ

【住所又は居所原語表記】３３３ Ｒａｖｅｎｓｗｏｏｄ Ａｖｅｎｕｅ， Ｍｅｎｌｏ Ｐａｒｋ， Ｃａｌｉｆｏｒｎｉａ ９４０２５， Ｕ．Ｓ．Ａ．

(74)【代理人】

【識別番号】100108833

【弁理士】

【氏名又は名称】早川 裕司

(74)【代理人】

【識別番号】100162156

【弁理士】

【氏名又は名称】村雨 圭介

(72)【発明者】

【氏名】フィリップ エー． ポラス

(72)【発明者】

【氏名】ビノッド イェグネスワラン

(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】

前記ポリシー外アクセス試行を受け入れるためのそれぞれの通信ポリシーの追加、及び少なくとも１つの未使用ポリシーの削除のうちの少なくとも１つを生じさせることを備える、請求項１９に記載の方法。

【発明の詳細な説明】

【関連出願との相互参照】

【0001】

この出願は、２０２０年１月２日に出願された米国仮特許出願番号６２／９５６，４０８の利益及び優先権を主張し、その全体が参照によりここに組み込まれる。

【政府陳述】

【0002】

本発明は、全米科学財団によって授与された認可番号１５１４５０３の下で米国政府の支援を受けてなされた。米国政府はこの発明において一定の権利を有する。

【技術分野】

【0003】

本原理の実施形態は、一般に、コンテナネットワークアプリケーションに関し、より具体的には、コンテナネットワークにセキュリティを提供することに関する。

【背景技術】

【0004】

コンテナは、複雑なプロダクションインターネットサービスを、管理可能な（コンポーネント化された）マイクロサービスに分解するために広く利用されている。特にプロダクションマイクロサービスのスケーラブルなインスタント化に対しては、仮想アプリケーションの展開のためのコンテナ化技術の使用が驚くべき速度で成長してきている。しかし、マイクロサービスにはコンテナ間ネットワーキングが不可欠である一方で、コンテナネットワーキングのロバスト性の問題は、セキュリティの観点からは十分に精査されてきてはいない。発生する１つの重大な問題は、コンテナ化された環境が、攻撃され破壊されたネットワーク暴露マイクロサービスをホストするときに、コンテナ化された環境がセキュリティ隔離を実施し得る範囲である。

【発明の概要】

【発明が解決しようとする課題】

【0005】

実質上、任意のアプリケーションがほぼ乗っ取られ、次いで他のコンテナ又はホストオペレーティングシステム（ＯＳ）を攻撃するために破壊され得る。コンテナは、仮想マシン（ＶＭｓ）よりも少ないアプリケーション隔離を提供する。１つのセキュリティアプローチは、ＩＰテーブルベースのファイアウォールを用いることであったが、これは手動でしかもエラーが発生しやすいアプローチであり、オーバーヘッドが高い。

【課題を解決するための手段】

【0006】

コンテナネットワークにセキュリティを提供するための方法、装置、及びシステムの実施形態がここに開示される。

【0007】

本原理によるいくつかの実施形態では、複数のコンテナを有するコンテナネットワークにセキュリティを提供するための方法は、コンテナネットワークの複数のコンテナの各々に対してネットワークスタックを確立することと、アクティブなコンテナからネットワーク及びポリシー情報を決定することと、決定されたネットワーク及びポリシー情報から学習された複数のコンテナに対する一連の所定のコンテナ間依存関係に基づいて、コンテナネットワークにおけるコンテナアクセスを、複数のコンテナのうちそれぞれの通信に関連するコンテナのみに限定されるように構成することと、コンテナネットワークにおけるコンテナ間トラフィックが、発信元コンテナから宛先コンテナにのみポイントツーポイントで向けられ、ピアコンテナに対するコンテナ間トラフィックの暴露が妨げられるようにコンテナ間トラフィックを構成することと、を含む。

【0008】

いくつかの実施形態では、方法は、複数のコンテナの各々に対してコンテナ間依存関係を決定することを含み得る。いくつかの実施形態では、コンテナ間依存関係を学習することは、各それぞれのコンテナに関連付けられたネットワーク情報を識別するアドレス解決プロトコル(Address Resolution Protocol)（ＡＲＰ）要求を用いることを含み得る。そのような実施形態では、方法は、それぞれのＡＲＰ要求を満たす前に発信元コンテナがコンテナネットワークにおいて宛先コンテナへの依存関係を有していることを検証することを含み得る。

【0009】

本原理によるいくつかの実施形態では、コンテナネットワークにセキュリティを提供するためのシステムは、コンテナネットワークの複数のコンテナの各々に対してネットワークスタックを確立すると共にアクティブなコンテナからネットワーク及びポリシー情報を決定するように構成されたグローバルマネージャと、決定されたネットワーク及びポリシー情報から学習された複数のコンテナに対する一連の所定のコンテナ間依存関係に基づいて、コンテナネットワークにおけるコンテナアクセスを、複数のコンテナのうちそれぞれの通信に関連するコンテナのみに限定するように構成された少なくとも１つのネットワーク可視化サービスと、ピアコンテナに対するコンテナ間トラフィックの暴露が妨げられるようにコンテナネットワークにおけるコンテナ間トラフィックを発信元コンテナから宛先コンテナにポイントツーポイントで向けるように構成された少なくとも１つのトラフィック可視化サービスと、を含む。

【0010】

本原理によるいくつかの実施形態では、複数のコンテナを有するコンテナネットワークにセキュリティを提供するための方法は、コンテナネットワークにおけるトラフィックを監視し、コンテナトラフィックのネットワークログを生成することと、ネットワークログからコンテナネットワークのネットワーク及びポリシー情報を決定することと、決定されたネットワーク及びポリシー情報から複数のコンテナに対して最も特権の少ない通信ポリシーを決定することと、決定された最も特権の少ない通信ポリシーに基づいて、コンテナネットワークにおけるコンテナアクセスを、複数のコンテナのうちそれぞれの通信に関連するコンテナのみに限定されるように構成することと、コンテナネットワークにおけるコンテナ間トラフィックが、発信元コンテナから少なくとも１つの宛先コンテナにのみポイントツーポイントで向けられ、ピアコンテナに対するコンテナ間トラフィックの暴露が妨げられるようにコンテナ間トラフィックを構成することと、を含む。

【0011】

本原理による他の実施形態及び更なる実施形態が以下で説明される。

【図面の簡単な説明】

【0012】

本原理の上述した特徴が詳細に理解され得るように、上記で簡単に要約した本原理のより具体的な説明が実施形態を参照することによりなされることがあり、実施形態のいくつかは添付図面に示される。但し、添付図面は、本原理による典型的な実施形態を示すものに過ぎず、従って、本原理が他の同様に有効な実施形態を受け入れる場合があることからも、これらの図面は、本原理の範囲を限定するものと解釈すべきではない。

【0013】

【図1】図１は本原理の一実施形態によるコンテナセキュリティシステムの高レベルのブロック図を示す。

【0014】

【図2】図２は本原理の一実施形態によるコンテナセキュリティシステムの機能アーキテクチャの高レベルの図を示す。

【0015】

【図3】図３は本原理の一実施形態によるコンテナ間依存関係を抽出するためのアルゴリズムを示す。

【0016】

【図4A】図４Ａは本原理の一実施形態によるコンテナ認識ネットワーク隔離を実装するための高レベルの例示的ワークフロー図４００を示す。

【0017】

【図4B】図４Ｂは、本原理の一実施形態による、各ホストされたコンテナに対してネットワークインタフェース属性をキャプチャするコンテナネットワークマップ並びにコンテナ間のリンク及び依存関係を示すコンテナ間依存関係マップを示す。

【0018】

【図5A】図５ＡはＬｉｎｕｘ(登録商標)カーネル内で実行される従来技術のパケット処理シーケンスの概要を示す。

【0019】

【図5B】図５Ｂは本原理の一実施形態によるエンドツーエンド直接パケット転送プロセスの高レベルの機能ブロック図を示す。

【0020】

【図6】図６はセキュリティ攻撃が行われている従来技術のＫｕｂｅｒｎｅｔｅｓ環境の高レベルのブロック図を示す。

【0021】

【図7A】図７Ａは隣のコンテナを探っている図６のＫｕｂｅｒｎｅｔｅｓ環境の攻撃者によって収集されたコンテナネットワークのコンテナからのパケットデータを示す。

【0022】

【図7B】図７Ｂは攻撃者によって図６のネットワークに入れられた偽のＡＲＰ応答の一例を示す。

【0023】

【図7C】図７Ｃは図６のネットワークにおいて攻撃者によって監視されているＮｇｉｎｘ－ＵｓｅｒとＲｅｓｉ－Ｕｓｅｒの間のトラフィックの一例を示す。

【0024】

【図7D】図７Ｄは攻撃者によって図６のＮｇｉｎｘ－Ｕｓｅｒに注入された偽造パケットの一例を示す。

【0025】

【図8】図８は本原理の一実施形態によるネットワーク隔離から生じるパケットデータの図を示す。

【0026】

【図9A】図９Ａは攻撃者が本原理のエンドツーエンド転送なしに図６のなりすましされたターゲットコンテナを調べることができるトラフィックの一例を示すパケットデータを示す。

【0027】

【図9B】図９Ｂは攻撃者がいかに本原理のエンドツーエンド転送を伴う応答トラフィックを調べることができないのかを例示するパケットデータを示す。

【0028】

【図10A】図１０Ａは従来のセキュリティアーキテクチャを有するコンテナネットワークのコンテナへの攻撃者によるＲＳＴパケットの注入を示すパケットデータを示す。

【0029】

【図10B】図１０Ｂは攻撃者によるコンテナへのＲＳＴパケットの注入がＮｇｉｎｘ－Ｕｓｅｒの視点からどのようにしてセッション終了を引き起こすのかを示すパケットデータを示す。

【0030】

【図10C】図１０Ｃは本原理の一実施形態による発信元検証を実装しているコンテナセキュリティシステムにＲＳＴパケットを注入するための攻撃者の試みに関連するパケットデータを示す。

【0031】

【図10D】図１０Ｄは本原理の一実施形態による発信元検証を実装しているコンテナネットワークにＲＳＴパケットを注入するための図１１Ｃの攻撃者の試みがどのようにして本原理の実施形態により阻止されるのかを示すパケットデータを示す。

【0032】

【図11】図１１は、本原理の実施形態による、ｉｐｔａｂｌｅｓベースのアクセス制御ネットワークとコンテナセキュリティシステムを用いて制御されるネットワークとの両方に対するホスト内のセキュリティポリシー数の増大に従うコンテナ間スループット変動のグラフ表示を示す。

【0033】

【図12A】図１２Ａは本原理の一実施形態によるコンテナネットワークのホスト内のサービスの異なる組み合わせに対するコンテナ間待ち時間測定値のグラフ表示を示す。

【0034】

【図12B】図１２Ｂは本原理の実施形態によるホスト全体にわたる本原理のコンテナセキュリティシステムのサービスの異なる組み合わせに対するコンテナ間待ち時間測定値のグラフ表示を示す。

【0035】

【図13】図１３は本原理によりコンテナネットワークにセキュリティを提供するための方法のフローチャートを示す。

【0036】

【図14】図１４は本原理によるコンテナセキュリティシステムの実施形態での使用に適したコンピューティングデバイスの高レベルのブロック図を示す。

【0037】

【図15】図１５は、図１のコンテナセキュリティシステム等の本原理によるコンテナセキュリティシステムの実施形態が適用され得るネットワークの高レベルのブロック図を示す。

【0038】

【図16】図１６は本原理の一実施形態による複数のコンテナを有するコンテナネットワークに対して最も特権の少ないセキュリティを提供するための方法のフローチャートを示す。

【0039】

理解を容易にするために、可能な場合、同一の参照番号を用いて複数の図に共通である同一の要素を指定した。図は一定の縮尺で描かれておらず、明瞭さのために簡略化されていることがある。１つの実施形態の要素及び特徴は、更なる列挙なしに他の実施形態に有益に組み込まれてよいことが意図されている。

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

【0040】

本原理の実施形態は、一般に、コンテナネットワークにセキュリティを提供するための方法、装置、及びシステムに関する。本原理の概念は、種々の修正及び代替形態の影響を受けやすい一方で、その具体的な実施形態は、例として図面に示され、以下で詳細に説明される。本原理の概念を開示された特定の形態に限定する意図はないことが理解されるべきである。むしろ、その意図は、本原理及び添付の請求項と一致する全ての修正、均等なもの、及び代替案を網羅することである。例えば、本原理の実施形態は、主に具体的なコンテナアプリケーション及びコンテナネットワークに関して説明されるが、そのような教示は限定的であると考えられるべきではない。本原理による実施形態は、実質的に任意のコンテナアプリケーション及びコンテナネットワークで機能することができる。

【0041】

本原理の実施形態は、新しいコンテナネットワークスタックを提供する。いくつかの実施形態では、本原理のアーキテクチャは、コンテナごとにコンテナネットワークスタックをインスタンス化し、隔離、能力効率、及び各コンテナに対して最も特権の少ないネットワークアクセスを実装するきめの細かいネットワークセキュリティポリシー仕様を提供する。本原理の実施形態は、ホストされるコンテナの数が増加するのに従いネットワークポリシールール管理においてより良いネットワークポリシースケーラビリティを提供する他、コンテナが動的にインスタンス化及び削除されるのに従いコンテナエコシステムのより卓越した動的制御を提供する。

【0042】

本原理の実施形態は、マネージャとコンテナごとのネットワークスタックとを備える。マネージャは、アクティブなコンテナからネットワーク及びポリシー情報を決定し／求め、いくつかの実施形態では、セキュリティ実施ネットワークスタックを各コンテナに展開する。次いで、ネットワークスタックにおいて、全てのセキュリティ実施が、２つの主要なセキュリティサービス、即ちネットワーク可視化サービス及びトラフィック可視化サービスを通して行われる。一連のコンテナ間依存関係に基づいて、ネットワーク可視化サービスはコンテナ発見プロセスを仲介し、所与の依存関係マップに無関係と見なされるコンテナ及びホストへのアクセスをフィルタで除去する。即ち、少なくともいくつかの実施形態では、ネットワーク可視化サービスは、コンテナアプリケーションごとに可視ネットワークトポロジ全般に関してきめの細かい制御を提供する。トラフィック可視化サービスは、コンテナと他のピアコンテナの間のネットワークトラフィックを制御する一方で、トラフィックの発信元を検証する。即ち、少なくともいくつかの実施形態では、トラフィック可視化サービスは、コンテナ間トラフィックをポイントツーポイントで安全に隔離及び転送し、このトラフィックの他のピアコンテナへの暴露を防ぐ。本原理のそのような実施形態は、送り手と受け手の間のネットワーク通信も隔離する効率的な転送メカニズムを介して、トラフィックがコンテナ間で流れることを可能にする。コンテナ環境に変化があった場合、マネージャは、サービスを中断することなく各コンテナのネットワークスタックを動的に更新する。

【0043】

本原理の実施形態は、以下の少なくとも１つ又は任意の組み合わせを含むがこれに限定されない設計上の考慮を定義することによって、従来技術の欠陥を克服する。

【0044】

Ｒ１：コンテナ認識最小特権通信の実施。コンテナの接続性は、そのコンテナ自身とシステム又はサービスを構成するために通信が必要なコンテナとの間の相互依存関係の関数であり得る。

【0045】

Ｒ２：スケーラブルできめの細かいネットワークポリシー表現。コンテナネットワーク内のネットワークポリシーの表現及び実施の性能は、最新のホストコンテナトポロジのダイナミズム及びサイズに良好に対応し得る。

【0046】

Ｒ３：コンテナ内通信全般に関するポリシー制御。ゲートウェイインタフェースは外部ネットワークとの通信で重要な役割を果たす一方で、ネットワークスタックは、ゲートウェイインタフェースの直接アクセスをフィルタで除去して、ホストネームスペースの悪用を防ぐことができる。

【0047】

Ｒ４：ネットワーク特権コンテナのためのポリシーの実施。ネットワークポリシーの実施により、ホストインタフェースへの直接アクセスのためのホストネットワークネームスペースを共有しているネットワーク特権可能コンテナ全般に関してきめの細かいアクセス制御が可能になる。

【0048】

Ｒ５：権限のない盗聴及びなりすましの防止。通信仲介は、第三者パケットへのアクセス（即ち、盗聴）及び誤ったパケットヘッダの生成を防ぐことができる（アドレス解決プロトコル（ＡＲＰ）のなりすまし及びローカルコンテナ間のトラフィック注入の両方を防ぐ）。

【0049】

Ｒ６：任意のコンテナトポロジに良好に対応する競争力のある性能。ネットワークスタックは、コンテナネットワークを保護ししつつ、低遅延で高スループットの通信をもたらすことができる。

【0050】

図１は、本原理の実施形態によるコンテナセキュリティシステム（ＣＳＳ）１００の高レベルのブロック図を示す。図１のコンテナセキュリティシステム（ＣＳＳ）１００は、例示的には、複数のネットワークスタック１１０_１～１１０_Ｎ（集合的にはネットワークスタック１１０）と、コンテナネットワーク（図示せず）の各コンテナに対する少なくとも１つのネットワークスタックと、グローバルマネージャ１２０と、を備える。図１のコンテナセキュリティシステム１００の実施形態では、各ネットワークスタック１１０は、以下でより詳細に説明されるネットワーク可視化サービス／モジュール（ＮＶＳ）１３０及びトラフィック可視化サービス／モジュール（ＵＶＳ）１４０を含む／設けられている。図１のコンテナセキュリティシステム１００の実施形態では、各ネットワークスタック１１０は、ＮＶＳ１３０及びＴＶＳ１４０を備えるものとして示されているが、代替的又は追加的に、本原理のコンテナセキュリティシステムのいくつかの実施形態では、ＮＶＳ１３０及び／又はＴＶＳ１４０は、各ネットワークスタック１１０の外部に設けられたサービス／モジュールである可能性があり、図１に示すように各ネットワークスタック１１０内に存在する必要はない。例えば、図２は本原理のコンテナセキュリティシステムのアーキテクチャを示しており、このアーキテクチャにおいては、ＮＶＳ１３０及び／又はＴＶＳ１４０は各ネットワークスタック１１０の外部に設けられている、（以下でより詳細に説明する）。図１に示すように、図１のコンテナセキュリティシステム１００等の本原理のコンテナセキュリティシステムの実施形態は、本原理によりコンピューティングデバイス１４００内に実装することができる（図１４を参照して以下でより詳細に説明する）。

【0051】

いくつかの実施形態では、グローバルマネージャ１２０は、２つの論理部分、即ち、コンテナ収集部分１２２及びネットワークスタック管理部分１２４を備える。コンテナ収集に対して、グローバルマネージャ１２０は、例えば、Ｄｏｃｋｅｒエンジン及びＫｕｂｅｒｎｅｔｅｓマネージャ（図２を参照してより詳細に説明する）から、アクティブなコンテナの属性（例えば、ＮｅｔｗｏｒｋＳｅｔｔｉｎｇｓ）を定期的にキャプチャする。明示的なコンテナ間依存関係に関して、いくつかの実施形態では、グローバルマネージャ１２０は、具体的なキーワード（例えば、Ｄｏｃｋｅｒプラットフォームが提供する「リンク(link)」及び「依存する(depends on)」）を利用する。Ｋｕｂｅｒｎｅｔｅｓの場合、グローバルマネージャ１２０はコンテナ間依存関係を明示的に定義する方法を有していないので、グローバルマネージャ１２０は、Ｋｕｂｅｒｎｅｔｅｓ要素（例えば、コンテナ）のアイデンティティを特定するために用いられるラベルを利用して、明示的なコンテナ間依存関係（例えば、「ラベル：依存関係：サービス」）を定義する。セキュリティポリシーに関して、グローバルマネージャ１２０は、ホスト内のｉｐｔａｂｌｅからだけでなく、各コンテナのラベルに基づく「進入(ingress)」及び「退出(egress)」キーワードを用いて、そのようなポリシーを抽出する。次いで、新しいコンテナが作成されると、グローバルマネージャ１２０は、各コンテナに対して特有の新しい管理スレッドをローンチし、管理スレッドは、そのコンテナに対してフィルタリングされたマップを伴うそのコンテナのためのセキュリティ実施ネットワークスタックを個別にインストールし、それを管理する。いくつかの実施形態では、インストール中に、管理スレッドは、Ｂｅｒｋｌｅｙ Ｐａｃｋｅｔ Ｆｉｌｔｅｒ（ＢＰＦ）コンパイラコレクションのツールキットを用いる。

【0052】

いくつかの実施形態では、図１のコンテナセキュリティシステム１００における各コンテナのためのネットワークスタック１１０は、Ｌｉｎｕｘ(登録商標)カーネル上の拡張Ｂｅｒｋｌｅｙ Ｐａｃｋｅｔ Ｆｉｌｔｅｒ（ｅＢＰＦ）及びエクスプレスデータパス(express data path)（ＸＤＰ）を用いて実装することができ、ネットワークスタックにおけるセキュリティサービスは、ＸＤＰによって提供されるｘｄｐ ｍｄ構造の生の着信パケットを検査する。いくつかの実施形態では、検査中に、２つのハッシュマップ（即ち、コンテナネットワークマップ及びコンテナ間依存関係マップ）が読み出され、これらのマップは、ＢＰＦシステムコールを用いて、グローバルマネージャ１２０の対応する管理スレッド内のマップと同期される。次いで、いくつかの実施形態では、３つのタイプのＸＤＰアクションを用いることができ、即ち、「ＸＤＰ ＴＸ」はパケットを着信コンテナ（直接ＡＲＰハンドラ）に送り返し、「ＸＤＰ ＲＥＤＩＲＥＣＴ」はパケットを宛先の送信キューに注入し（エンドツーエンド直接転送）、「ＸＤＰ ＤＲＯＰ」はパケットをドロップする。

【0053】

上述したように、本原理の実施形態は、非集中型でコンテナごとのネットワークスタックを実装し、このネットワークスタックにおいては、コンテナのパケットがコンテナネットワークに届けられる前にセキュリティ実施が生じる。このような実施形態は、各コンテナから来るネットワークトラフィック全般に対して個別の制御を提供する。例えば、図２は、図１のコンテナセキュリティシステム１００等の本原理のコンテナセキュリティシステムの機能アーキテクチャの高レベルの図を示す。図２のコンテナセキュリティシステムのアーキテクチャの実施形態は、コンテナネットワーク（図示せず）のコンテナ１１０間の通信及びコンテナ１１０とホストコンテナ２９０の間の通信を保護するために提供される本原理のコンテナセキュリティシステムによって提供されるセキュリティサービス２００として例示的に示されている。図２のコンテナセキュリティのアーキテクチャは、例示的に、各コンテナ２１０のためのネットワークスタック１１０と、コンテナネットワークのグローバルビューを維持するグローバルマネージャ１２０と、コンテナの到達可能性を制御するネットワーク可視化サービス２３０、無関係なトラフィックをコンテナから隠しつつコンテナ間トラフィックを制御するトラフィック可視化サービス２４０、及び可視化マップ２５０を提供するセキュリティサービス２００と、を備える。更に、図２は、例示的に、２つのホストコンテナ２９０を備え、それらの各々は、ｉｐｔａｂｌｅｓ２９２及びそれぞれのＶｉｒｔｕａｌ Ｅｔｈｅｒｎｅｔｓ（ｖｅｔｈｓ）２９４を含む。ブリッジ２９６は、ホスト２９０間の相互通信を提供する。

【0054】

図２の実施形態では、ネットワークスタック１１０は、セキュリティサービス２００を介するいくつかの実施形態では、対応するコンテナのためにコンテナネットワークマップ２５２を維持し、このコンテナは、ピア依存関係を有する全ての到達可能なコンテナのネットワーク情報（例えば、マイクロサービス構成マップ）と、依存するコンテナのセキュリティポリシーを含むコンテナ間依存関係マップ２５４と、を含む。パケットがネットワークスタック１１０に到着すると、コンテナセキュリティサービス２００を介したネットワーク可視化サービス２３０は、いくつかの実施形態では、コンテナネットワークマップ２５２に基づいてアドレス解決プロトコル（ＡＲＰ）要求に対処することによって、無関係なコンテナの任意の発見プロセスを積極的にフィルタリングし（Ｒ１、Ｒ５）、コンテナ間依存関係マップ２５４において特定されたセキュリティポリシーに従ってコンテナ間の通信を制限する（Ｒ１）。図２の実施形態では、直接ＡＲＰハンドラ２３２は、目下のコンテナの依存関係マップ（以下でより詳細に説明する）に関係しない不必要なコンテナ発見をフィルタで除去する。但し、直接ＡＲＰハンドラ２３２は、依存するコンテナ間の悪意のあるアクセスには対処しない。そこで、コンテナの到達可能性を更に制限するために、第２のネットワーク可視化コンポーネント２３４が、コンテナ認識ネットワーク隔離（以下でより詳細に説明する）を実装する。また、図２の実施形態では、ネットワーク可視化サービス２３０の特別なＩＰハンドラ２３１が、コンテナセキュリティサービス２００を介して、特別なＩＰアドレス（例えば、ゲートウェイＩＰアドレス）への不正アクセスを制限する（Ｒ３）。

【0055】

図２の実施形態では、トラフィック可視化サービス２４０は、コンテナセキュリティサービス２００を介して、コンテナ間で安全なパケット転送を行う。トラフィック可視化サービス２４０は、先ず、発信元検証２４２を介してコンテナのアイデンティティでパケットを検証する（Ｒ４～５）。次いで、トラフィック可視化サービス２４０は、直接転送２４４（以下でより詳細に説明する）を介して、発信元コンテナから宛先コンテナにそれらのインタフェースアドレスを用いてパケットを直接渡す。直接パケット転送はネットワークインタフェースレベルで行われるので、パケットはコンテナネットワークを通過させられることはなく（Ｒ５～６）、不正なネットワークトラフィック暴露の可能性が排除される（ネットワーク特権コンテナに対しても）（Ｒ４）。

【0056】

図２を再び参照すると、いくつかの実施形態では、交差ホストコンテナ間通信のために、専用ネットワークスタック２５５が、各ノードの外部インタフェースで利用される。コンテナ２１０のためのネットワークスタック１１０とは異なり、専用ネットワークスタック２５５は、各ノードに展開された全てのコンテナのためにコンテナネットワークマップを維持する。パケットが各コンテナのネットワークスタックに入るときに全てのセキュリティ決定は既になされているので、単純で安全な転送が外部インタフェースから宛先コンテナに行われる。ホスト（ノード）間の物理リンクはコンテナセキュリティシステムの範囲を超えており、従って既存のオーバーレイネットワーク（例えば、ＩＰＳｅｃを介したＷｅａｖｅネットワーク）を利用する。また、いくつかの実施形態では、本原理のコンテナセキュリティシステムは、外部ネットワークからのインバウンドトラフィックを取り扱うためのコンテナプラットフォームの既存メカニズムを保持している。

【0057】

図２の実施形態では、グローバルマネージャ１２０は２つの主要な役割を果たし、即ち、グローバルマネージャ１２０は、コンテナプラットフォームから全てのアクティブなコンテナのネットワーク情報を収集し、アクティブなコンテナに展開されたネットワークスタックを管理する。いくつかの実施形態では、コンテナ収集のために、グローバルマネージャ１２０は、先ず、各コンテナのセキュリティ評価のために２つのハッシュマップ（即ち、全てのコンテナのグローバルコンテナネットワークマップ２５２及びコンテナ間依存関係マップ２５４）を維持する。いくつかの実施形態では、図２に示すように、図１及び２のコンテナセキュリティシステム１００等の本原理のコンテナセキュリティシステムは、Ｄｏｃｋｅｒ又はＫｕｂｅｒｎｅｔｅｓ等のコンテナプラットフォーム２６０を用いて、全てのコンテナのためにネットワーク情報（例えば、コンテナＩＤ、コンテナネットワーク－マイクロサービスのアイデンティティ、コンテナセット－具体的な機能のためのコンテナセットのアイデンティティ、ホスト側のネットワークインタフェース、並びにＩＰ及びＭＡＣアドレス）を読み出すと共に、読み出された情報及びそれらの進入／退出セキュリティーポリシーに基づいてコンテナ間の依存関係を抽出することによって、コンテナ間依存関係マップを構築する。また、コンテナは動的にスピンアップ及びスピンダウンされ得るので、グローバルマネージャ１２０は、マップを更新するためにネットワーク情報を定期的に読み出す。いくつかの実施形態では、ポーリングベースのメカニズムが選択されて、所要の修正なしに既展開のコンテナ環境と統合され得る透過的で互換性のある解決策を提供する。

【0058】

いくつかの実施形態では、本原理のコンテナセキュリティシステムは、コンテナ間の依存関係を自動的に抽出する。これを行うために、コンテナネットワークモデルが定義され、このモデルにおいては、マイクロサービスグループは１つ以上のコンテナセットで構成され、各コンテナセットは、同じ役割を果たす１つ以上のコンテナを有する（スケーリング及び負荷バランシングのため）。各コンテナセットは、他のコンテナセットと通信するために内部サービスポートを暴露する一方、マイクロサービスは、外界からのアクセスをいくつかの内部サービスポートにリダイレクトするために、グローバルサービスポートを暴露する。このような実施形態では、暗黙的なコンテナ間依存関係に対して、コンテナ間通信において４つの制約が存在し得る。即ち、（１）同じコンテナセットを伴うコンテナに相互接続性が与えられ、（２）異なるコンテナセットにおけるコンテナが内部サービスポートを介して通信し（構成によって明示的に暴露される）、（３）関係のないコンテナは、グローバルサービスポートを介して互いに通信してよく、（４）他の全ての通信はデフォルトでドロップされる。

【0059】

本原理のコンテナセキュリティシステムのいくつかの実施形態では、コンテナ間依存関係は、図３のアルゴリズム３００を用いて抽出することができる。図３のアルゴリズム３００においては、先ず、オペレータ指定ポリシーが用いられて、コンテナネットワークにおける各コンテナの進入及び退出ポリシーを交差させることによって初期の依存関係マップを作成し、これは、最も特権の少ない接続ポリシーを表す。次に、アルゴリズム３００は、制約に基づいて、暗黙的に依存するコンテナを見つける。同じコンテナセット（即ち、制約１）のコンテナに対して、グローバルマネージャ１２０は、アルゴリズム３００に従って、コンテナを明示的に依存するコンテナとして依存関係マップに追加する。同じマイクロサービスグループ（制約２）内の異なるコンテナセットに属するコンテナは、各コンテナの退出ポリシーを他のコンテナセットの内部サービスポートと交差させることによって、マップに追加される。最後に、交差マイクロサービスグループ通信（制約３）に対して、グローバルマネージャ１２０は、アルゴリズム３００に従って、各コンテナの退出ポリシーをそれぞれのグローバルサービスポートと交差させることによって、他のマイクロサービスに対する代表的なＩＰアドレス（マイクロサービスにアクセスするための仮想ＩＰアドレス）をマップに追加する。最終的に、アルゴリズム３００は、全てのコンテナに対してコンテナ間依存関係マップを集約する。

【0060】

いくつかの実施形態では、本原理によるコンテナセキュリティシステムは、コンテナ間依存関係ポリシー及びネットワークポリシーを発見することができる。例えば、通信を最小限の必要なアクセスに制限する適切なネットワークポリシーなしではコンテナネットワークを安全にすることができないので、いくつかの実施形態では、図１及び２のグローバルマネージャ１２０等の本原理のグローバルマネージャは、コンテナオペレータによって明示的に定義されていないコンテナ間依存関係を発見することが可能である。例えば、コンテナ間トラフィックのフロー制御中に、本原理のグローバルマネージャは、トラフィックを監視し、コンテナとの間のネットワークアクセスをキャプチャするネットワークログを作成することができる。同時に、グローバルマネージャは、作成されたログをコンテナ間依存関係マップと比較して、コンテナのログ情報を３つのケース、即ち、正当なアクセス、ポリシーの欠落、及び過剰なポリシーに分類することができる。サブジェクト通信に対して、観察されたコンテナの対が事前計算されたコンテナ間依存関係マップ内にない場合、本原理のグローバルマネージャは、ネットワークポリシーが欠落しているか、あるいはアクセスが無効であると見なすことができる。いくつかの実施形態では、次いで、本原理のグローバルマネージャは、例えばネットワークオペレータに伝達事項が送られるようにして、具体的なネットワークポリシーのレビューにより、現在のネットワークポリシーにはまだ存在していない識別されたフロー／アクセスに権限を与えるために新しいネットワークポリシーが作成されるべきかどうかを決定することができる。代替的又は追加的に、いくつかの実施形態では、本原理のグローバルマネージャは、例えばいくつかの実施形態では同じ試行の頻度に基づいて、追加の繰り返しアクセス試行を行うために追加のネットワークポリシーが追加されるべきかどうかを自動的に決定するように構成され得る。

【0061】

同様に、いくつかの実施形態では、グローバルマネージャは、フローが遭遇していないネットワークポリシーを識別することができる。このようなインスタンスは、コンテナネットワークの動作に不要なフローを有効にするポリシーのオーバースペックを代表し得る。これらのインスタンスにおいては、次いで、本原理のグローバルマネージャは、例えばネットワークオペレータに伝達事項が送られるようにして、具体的なネットワークポリシーのレビューにより、既に存在しているが使われてはいないネットワークポリシーが削除されるべきかどうかを決定することができる。代替的又は追加的に、いくつかの実施形態では、本原理のグローバルマネージャは、例えばいくつかの実施形態ではポリシーが使われてからどれくらい経つのかに基づいて、ネットワークポリシーが削除されるべきかどうかを自動的に決定するように構成され得る。

【0062】

上述したように、いくつかの実施形態では、本原理のグローバルマネージャは、コンテナネットワークにおいてコンテナのトラフィックを監視し、コンテナとの間のネットワークアクセスをキャプチャするネットワークログを生成することができる。このような実施形態では、グローバルマネージャは、ネットワークログからコンテナネットワークのネットワーク及びポリシー情報を決定することができ、また、決定されたネットワーク及びポリシー情報から複数のコンテナに対して最も特権の少ない通信ポリシーを決定することができる。即ち、いくつかの実施形態では、本原理のグローバルマネージャは、コンテナネットワークのコンテナが、それぞれのジョブファンクションを行うために必要な最小レベルのアクセス／許可を与えられるセキュリティ概念を決定することが可能である。次いで、グローバルマネージャは、決定された最も特権の少ない通信ポリシーに基づいて、コンテナネットワークにおけるコンテナアクセスを、複数のコンテナのうちそれぞれの通信に関連するコンテナのみに限定されるように構成することができる。グローバルマネージャは、更に、コンテナネットワークにおけるコンテナ間トラフィックが、発信元コンテナから少なくとも１つの宛先コンテナにのみポイントツーポイントで向けられ、ピアコンテナに対するコンテナ間トラフィックの暴露が妨げられるようにコンテナ間トラフィックを構成することとができる。

【0063】

図１６は、複数のコンテナを有するコンテナネットワークに対して最も特権の少ないセキュリティを提供するための方法１６００のフローチャートを示す。方法１６００は１６０２で開始することができ、その間、コンテナネットワークにおけるトラフィックが監視され、コンテナトラフィックのネットワークログが生成される。方法１６００は１６０４に進むことができる。

【0064】

１６０４で、コンテナネットワークのネットワーク及びポリシー情報がネットワークログから決定される。方法１６００は１６０６に進むことができる。

【0065】

１６０６で、決定されたネットワーク及びポリシー情報から、複数のコンテナに対して最も特権の少ない通信ポリシーが決定される。方法１６００は１６０８に進むことができる。

【0066】

１６０８で、コンテナネットワークにおけるコンテナアクセスは、決定された最も特権の少ない通信ポリシーに基づいて、複数のコンテナのうちそれぞれの通信に関連するコンテナのみに限定されるように構成される。方法１６００は１６１０に進むことができる。

【0067】

１６１０で、コンテナネットワークにおけるコンテナ間トラフィックは、コンテナ間トラフィックが、発信元コンテナから少なくとも１つの宛先コンテナにのみポイントツーポイントで向けられ、ピアコンテナに対するコンテナ間トラフィックの暴露が妨げられるように構成される。方法１６００は終了され得る。

【0068】

本原理による実施形態及び少なくとも図２の実施形態を参照する実施形態では、上述したように、グローバルマネージャ１２０は、各コンテナに対してネットワークスタック１１０を維持する。新たに生成されたコンテナに対しては、グローバルマネージャ１２０は、コンテナネットワーク２５２及びコンテナ間依存関係マップ２５４を用いて、インタフェースでのネットワークスタック１１０をインストールする。マップサイズに関しては、各コンテナは、依存する隣のコンテナと通信するためにネットワーク情報の一部のみを必要とする一方で、グローバルマネージャ１２０は、展開された全てのコンテナのネットワーク情報全体を維持する。従って、セキュリティサービスのサイズを最適化するために、いくつかの実施形態では、本原理のコンテナセキュリティシステムは、コンテナごとに無関係な情報をフィルタリングする。グローバルマネージャ１２０はまた、コンテナ間依存関係の変化検出を行い、対応するコンテナのネットワークスタックマップを自動的に更新する。

【0069】

上述したように、ネットワーク可視化サービス２３０は、コンテナ間及びコンテナと外部ホストとの間の不必要な接続を制限する。いくつかの実施形態では、コンテナ間ネットワーキングに対して、発見は、他のコンテナ通信ターゲットを識別するための最初のステップである。いくつかの実施形態では、コンテナは、ＡＲＰ要求を用いて、ターゲットコンテナの必要なネットワーク情報（即ち、ＭＡＣアドレス）を識別することができる。ネットワーク可視化サービス２３０の直接ＡＲＰハンドラ２３２は、目下のコンテナの依存関係マップに関係しない不要なコンテナ発見をフィルタで除去する。コンテナがＡＲＰ要求を送信すると、直接ＡＲＰハンドラ２３２は、要求がブロードキャストされる前に要求を傍受し、発信元コンテナが宛先コンテナとの依存関係を有していることを検証する。いくつかの実施形態では、分析は、コンテナ間依存関係マップ２５４を用いて行われる。アクセス可能な場合、直接ＡＲＰハンドラ２３２は、コンテナネットワークマップにおける宛先コンテナの所与のＭＡＣアドレスでＡＲＰ応答を生成し、その応答を発信元コンテナに返送する。それ以外の場合、直接ＡＲＰハンドラ２３２は単に要求をドロップする。

【0070】

直接ＡＲＰハンドラ２３２は、コンテナが無制限のトポロジ発見を行うことを防止するが、対象範囲はコンテナレベルの隔離に限定される。直接ＡＲＰハンドラ２３２は、依存するコンテナ間の悪意のあるアクセスには対処しない。そこで、コンテナの到達可能性を更に制限するために、第２のネットワーク可視化コンポーネント２３４がコンテナ認識ネットワーク隔離を実装する。

【0071】

図４Ａは、本原理の一実施形態によるコンテナ認識ネットワーク隔離を実装するための高レベルの例示的ワークフロー図４００を示す。図４Ａのワークフロー図４００は、ＷｅｂＡｐｐコンテナとＤａｔａｂａｓｅコンテナの間の相互依存関係を示す。即ち、図４Ａの実施形態では、ＷｅｂＡｐｐコンテナは、図４Ｂに示されるコンテナネットワークのＤａｔａｂａｓｅコンテナのサービスにアクセスする。

【0072】

即ち、図４Ｂに示すように、本原理のコンテナセキュリティシステムは、各ホストコンテナに対してネットワークインタフェース属性をキャプチャするコンテナネットワークマップ４０２と、コンテナ間のリンク及び依存関係を示すコンテナ間依存関係マップ４０４と、を計算する。例えば、図４Ｂの実施形態に示すように、例えばコンテナネットワーク４０８のオペレータ４０６は、コマンドをグローバルマネージャ４２０に伝達して、グローバルマネージャ４２０に、コンテナネットワークマップ４０２及びコンテナ間依存関係マップ４０４のうちの少なくとも１つを計算／更新させることができる。図４Ｂにも示すように、いくつかの実施形態では、グローバルマネージャ４２０は、コンテナネットワークマップ４０２及びコンテナ間依存関係マップ４０４のうちの少なくとも１つを定期的に計算／更新するように構成され得る。

【0073】

図４Ａを再び参照すると、ＷｅｂＡｐｐのネットワークスタックは、ＷｅｂＡｐｐ自体のためのコンテナネットワークマップ４０２及びコンテナ間依存関係マップ４０４のみを含む。ＷｅｂＡｐｐのパケットを仲介する際、本原理のコンテナセキュリティシステムは、先ずステップ１でＷｅｂＡｐｐからの着信パケットを傍受することができる。次いで、本原理のコンテナセキュリティシステムは、宛先ＩＰアドレスをキーとして用いてコンテナ間依存関係マップを調べることによって、ＷｅｂＡｐｐと宛先の間の依存関係をチェックすることができる。即ち、ステップ２において、いくつかの実施形態では、本原理のコンテナセキュリティシステムは、Ｈａｓｈマップルックアップを行うことができる。マップにポリシーが存在する場合、ＷｅｂＡｐｐは宛先、この場合にはＤａｔａｂａｓｅとの依存関係を有していると結論付けることができる。データベースコンテナのポリシーに一致する場合には接続が許可され、一致しない場合にはドロップされる。即ち、ステップ３において、本原理のコンテナセキュリティシステムはポリシーマッチングを行うことができる。

【0074】

本原理のいくつかの実施形態は順次マッチングを採用するが、代替的又は追加的に、他のマッチングアルゴリズム（ブルームフィルタ等）が本原理に従って実装され得る。上記の実施形態は、ｉｐｔａｂｌｅｓで生じるようにマッチセットがホストグローバル固有ではなくコンテナ固有であるので、合理化されたコンテナごとのポリシー仕様と最小化されたポリシー実施性能への影響との両方を提供する。更に、ｉｐｔａｂｌｅｓは静的ポリシーに依存するが、本原理のコンテナ認識ネットワーク隔離は、サービスを中断することなく動的に変化するコンテナネットワーク環境についての最新情報を維持する依存関係マップに基づく動的ポリシーを通して実装される。

【0075】

図２に関して上述したように、ネットワーク可視化サービス２３０の特別なＩＰハンドラ２３１は、直接ホストアクセスをフィルタリングする。ネットワーク接続が非ローカルコンテナアドレスを対象とする場合、そのアドレスは、そのネットワークのゲートウェイＭＡＣアドレスと実際の宛先のＩＰアドレスとを含む。図１のコンテナセキュリティシステム１００等の本原理のコンテナセキュリティシステムのネットワーク可視化サービス２３０のＩＰハンドラ２３１は、いくつかの実施形態では、ＩＰアドレス及びＭＡＣアドレスの両方がゲートウェイに属するかどうかをチェックすることによって、任意の直接ホストアクセスをブロックする。尚、これらのゲートウェイはホストネットワークに接続されているので、ネットワークフローは、代替的に、他のコンテナネットワークのゲートウェイにアクセスする場合がある。結果として、本原理のいくつかの実施形態では、ＩＰハンドラ２３１はまた、着信パケットのＩＰアドレス及びＭＡＣアドレスを全てのゲートウェイ情報と比較することによって、権限を与えられていないホストアクセスをフィルタリングする。

【0076】

Ｋｕｂｅｒｎｅｔｅｓ環境においては、追加の特別なサービスＩＰアドレスが存在する。サービスＩＰアドレスは、実際のコンテナへのリダイレクトに用いられる仮想ＩＰアドレスである。但し、これらのＩＰアドレスはコンテナネットワークに属していないので、外部ＩＰアドレスとみなすことができる。従って、本原理のいくつかの実施形態では、｛サービスＩＰアドレス、ポート｝及び｛対応するコンテナＩＰアドレス、ポート｝のそれぞれの対が、Ｋｕｂｅｒｎｅｔｅｓによって管理されるｉｐｔａｂｌｅｓのＮＡＴテーブルから追加的に抽出され、サービスマップが本原理の各ネットワークスタックにおいて維持される。次いで、コンテナがサービスＩＰアドレス及びサービスポートを有するパケットを送信すると、ネットワーク可視化サービス２３０の特別なＩＰハンドラ２３１は、サービスマップに従ってサービスＩＰアドレス及びポートを実際のコンテナＩＰアドレス及びポートに上書きする。単一のサービスにマッピングされた複数のコンテナがある場合、発信元ＩＰアドレス及びポートのハッシュに基づいてコンテナが選択される。結果として、全てのコンテナ間通信は、コンテナネットワーク内に存在しているＩＰアドレスを用いて行われ得る。

【0077】

図５Ａは、Ｌｉｎｕｘ(登録商標)カーネル内で実行される従来技術のパケット処理シーケンスの概要を示す。図５Ａの実施形態では、パケットがインタフェースに到着すると、パケットは先ず進入トラフィック制御に届けられる。続いて、パケットは実際のネットワークスタックを通過し、フィルタチェックを通って処理されると、最終的にアプリケーションに届けられる。アプリケーションがパケットを送信すると、パケットは逆にインタフェースに届けられる。トラフィック可視性を制御するためには、どこでパケットをフィルタリングするのか及びどこでパケットをキャプチャするのかの両方を考慮する必要がある。最初の疑問（即ち、どこでパケットをフィルタリングするのか）の答えはネットワークスタック内である。ネットワークトラフィックは、例えば、ネットワークスタックにあるＮｅｔｆｉｌｔｅｒを用いてフィルタリングすることができる。Ｎｅｔｆｉｌｔｅｒは、ネットワークレイヤーを横切る複数のマッチテーブル（例えば、Ｌ２トラフィックに対するｅｂｔａｂｌｅｓ及びＬ３／Ｌ４トラフィックに対するはｉｐｔａｂｌｅｓ）により構成される。従って、セキュリティポリシー（例えば、ＤＲＯＰ）は、各レイヤーで対応するマッチテーブルにそれらセキュリティポリシーを追加することによって、ネットワークトラフィックに適用され得る。セキュリティポリシーに違反するパケットは既にネットワークスタックにおいて処理されているので、アプリケーションはそれらを受け取らない。

【0078】

第２の疑問（即ち、どこでパケットをキャプチャするのか）に対する答えは、進入及び退出のトラフィック制御にある。ネットワークトラフィックがキャプチャされると、パケットキャプチャツール（例えば、ｔｃｐｄｕｍｐ）が用いられる。このようなツールは、内部でＢｅｒｋｅｌｅｙ Ｐａｃｋｅｔ Ｆｉｌｔｅｒ（ＢＰＦ）フィルタを作成し、それらをトラフィック制御に注入する。ＢＰＦフィルタを用いて、ネットワークトラフィックのクローンが作成され、選択的に読み出される。従って、ｎｅｔｆｉｌｔｅｒによってドロップされたパケットであっても、それらパケットを監視することができる。図５Ａに示されるようなＬｉｎｕｘ(登録商標)カーネル内で行われる従来技術のパケット処理シーケンス及び他のネットワークスタック機能の欠陥は、全てのセキュリティ実施とパケット転送とがパケットヘッダ情報に頼っていることを含む。従って、悪意のあるコンテナは、ターゲットコンテナのアイデンティティと一致するパケットを提出することができてしまう。そうすることで、悪意のあるコンテナは、ターゲットコンテナのトラフィックを自身にリダイレクトすることができてしまう（例えば、ＡＲＰなりすまし攻撃）。また、悪意のあるコンテナは、通過するトラフィックを修正し（例えば、Ｍａｎ－Ｉｎ－ｔｈｅ－Ｍｉｄｄｌｅ攻撃）、あるいは偽造されたパケットを注入して別のコンテナが存在するセッションを混乱させること（例えば、ＴＣＰ ＲＳＴ攻撃）ができてしまう。

【0079】

上述の欠陥を防ぐために、本原理の実施形態は、コンテナ間トラフィックの発信元検証を行う。図１のコンテナセキュリティシステム１００等の本原理のいくつかの実施形態では、本原理の各コンテナのネットワークスタックは、対応するコンテナのコンテナ情報（即ち、ＩＰアドレス及びＭＡＣアドレス）を静的に含む。いくつかの実施形態では、トラフィック可視化サービス２４０等の本原理のトラフィック可視化サービスは、着信トラフィックのパケットヘッダ情報をネットワークスタックに埋め込まれたコンテナ情報と比較することによって、着信トラフィックを検証する。パケット情報がコンテナ情報と一致しない場合、着信トラフィックはなりすましされたと見なされ、トラフィックは即座にドロップされる。代替的又は付加的に、本原理のいくつかの実施形態では、着信パケットのカーネルメタデータ（例えば、進入ネットワークインタフェースインデックス）を活用して、コンテナ間トラフィックの発信元検証を行う。本原理のそのような実施形態では、トラフィック可視化サービス２４０等の本原理のトラフィック可視化サービスは、パケットヘッダ情報だけでなくメタデータもコンテナの情報と比較することによって、着信トラフィックを検証する。パケット情報及び／又はメタデータがコンテナ情報と一致しない場合、着信トラフィックはなりすましされたと見なされ、トラフィックは即座にドロップされる。

【0080】

発信元検証の有効性は、その忠実度に由来して、着信パケットの起点を検証する。結果として、本原理の実施形態は、コンテナ環境における混乱及びなりすましの脅威の範囲を効果的に排除する。図５Ａの従来技術のパケット処理シーケンス等の既存の解決策は、パケットヘッダ情報を介して着信パケットがどこから来るのかを観察することに限定される。図５Ａに示すように、従来技術のネットワークスタックは、フィルタ位置がキャプチャ点の後ろにあるので、他のコンテナからのコンテナ間トラフィックの暴露を防ぐことができない。従って、悪意のあるコンテナが、ターゲットコンテナのトラフィックを自身にリダイレクトする能力を有する場合、悪意のあるコンテナは制限なしにトラフィックを監視することができてしまう。更に、ネットワーク特権コンテナは、全てのコンテナネットワークの完全な可視化を伴う。上述したように、そのような欠陥に対処するために、本原理の実施形態は、エンドツーエンドの直接転送コンポーネントを提供することによって、最も特権の少ないトラフィックの暴露を実装する。

【0081】

図５Ｂは、本原理の一実施形態によるエンドツーエンド直接パケット転送プロセスを含むコンテナネットワーク５５０の高レベルの機能ブロック図を示す。いくつかの実施形態では、本原理の図５Ｂのプロセスは、元のネットワークスタックだけでなく、ブリッジインタフェースもバイパスすることによって、他のコンテナに対するコンテナ内トラフィックの暴露をバイパスするために実装され、このようにしてピアコンテナによる傍受を防いでいる。図５Ｂの実施形態では、図１のコンテナセキュリティシステム１００等の本原理のコンテナセキュリティシステムが、コンテナから着信ネットワーク接続を受け取ると、コンテナセキュリティシステムは、コンテナネットワークマップから宛先のインタフェース情報を読み出す。宛先が同じノード内のコンテナである場合、コンテナセキュリティシステムは、パケットストリームを宛先コンテナに注入する。例えば、図５Ｂの実施形態では、本原理のコンテナセキュリティサービス５００は、コンテナＡ５０２及びコンテナＢ５０４の各々に実装されている。図５Ａにおける通信プロトコルとは対照的に、図５Ｂの実施形態では、コンテナＡ５０２からコンテナＢ５０４への通信は、コンテナＡのホスト側インタフェース５１２を用いてコンテナＢのホスト側インタフェース５１４へは完了せず、代わりに、本原理のコンテナセキュリティサービス５００によって、コンテナＡ５０２の内部インタフェース５１６からコンテナＢ５０４の内部インタフェース５１８へ直接転送される。本原理によれば、いくつかの実施形態では、コンテナＡ５０２及びコンテナＢ５０４のうちの少なくとも１つからの通信の宛先が別のノードのコンテナである場合、パケットは、本原理のサービス５００によって、ホストの外部インタフェース（図示せず）に注入される。ターゲットノードで外部インタフェースのネットワークスタックがパケットを受信すると、ネットワークスタックは、パケットストリームを宛先コンテナに直接注入する。本原理によるこのトラフィックフローの隔離は、トラフィックの暴露及び他のコンテナによる注入の両方を防ぎ、ネットワーク特権のコンテナが第三者のトラフィックフローを調べることさえ防ぐ。

【0082】

図６は、セキュリティ攻撃が行われている従来技術のＫｕｂｅｒｎｅｔｅｓ環境の高レベルのブロック図を示す。図６のＫｕｂｅｒｎｅｔｅｓ環境では、２つの独立したサービスが共通のマイクロサービスと共に展開される。図６では、一方は正当なユーザに対するサービスとして実装されており、他方はゲストユーザに対するサービスである。図６のＫｕｂｅｒｎｅｔｅｓ環境では、ＤｏｃｋｅｒＨｕｂから読み出されたＮｇｉｎｘ及びＲｅｄｉｓコンテナイメージが用いられる。図６のＫｕｂｅｒｎｅｔｅｓ環境では、１つのサービスからの危うくされたコンテナは、一連のネットワーク攻撃を行って、ピアサービスにおける他のコンテナ間の通信を乗っ取る。このシナリオでは、攻撃者はウェブアプリケーションの脆弱性を悪用することによって、公開されているＮｇｉｎｘサーバに潜入した後、正当なユーザ要求を偽造する。次いで、攻撃者は、静的にコンパイルされた攻撃バイナリを／ｔｍｐディレクトリにダウンロードすることができ、このディレクトリは、全てのプロセスに対するグローバルな読み取り及び書き込み許可を有する。

【0083】

図６のＫｕｂｅｒｎｅｔｅｓ環境では、攻撃者は３つのネットワークベースの攻撃を利用してＮｇｉｎｘ－Ｇｕｅｓｔコンテナを危うくし、ｍａｎ－ｉｎ－ｔｈｅ－ｍｉｄｄｌｅ攻撃を首尾よく実行する。最初のステップでは、攻撃者はＡＲＰベースのスキャンを通してネットワーク周辺のアクティブなコンテナを発見する。図６のＫｕｂｅｒｎｅｔｅｓ環境では、全てのコンテナはオーバーレイネットワークに接続されており、ＡＲＰパケットはｉｐｔａｂｌｅｓによってフィルタリングされないので、攻撃者はコンテナのネットワーク情報を容易に収集することができる。

【0084】

例えば、図７Ａは、隣のコンテナ（即ち、Ｎｇｉｎｘ－Ｇｕｅｓｔのビュー）を探っている図６のＫｕｂｅｒｎｅｔｅｓ環境の攻撃者によってコンテナから収集されたネットワーク情報を示す。図６のＫｕｂｅｒｎｅｔｅｓ環境では、攻撃者は次いで偽のＡＲＰ応答をネットワークに注入して、Ｎｇｉｎｘ－ＵｓｅｒコンテナとＲｅｄｉｓ－Ｕｓｅｒコンテナの間の全てのトラフィックにＮｇｉｎｘ－Ｇｕｅｓｔを通過させることができる。例えば、図７Ｂは、攻撃者によって図６のネットワークに入れられた偽のＡＲＰ応答の一例を示す。即ち、図７Ｂでは、Ｎｇｉｎｘ－ＵｓｅｒのＡＲＰテーブルにおけるＲｅｄｉｓ－ＵｓｅｒのＭＡＣアドレスが、Ｎｇｉｎｘ－ＧｕｅｓｔのＭａｃアドレスに置き換えられていることが分かる。次いで、攻撃者は、Ｎｇｉｎｘ－ＵｓｅｒとＲｅｄｉｓ－Ｕｓｅｒの間の全てのトラフィックを監視することが可能である。例えば、図７Ｃは、図６のネットワークにおいて攻撃者によって監視されているＮｇｉｎｘ－ＵｓｅｒとＲｅｄｉｓ－Ｕｓｅｒの間のトラフィックの一例を示す。

【0085】

図６のＫｕｂｅｒｎｅｔｅｓ環境では、攻撃者は、正当なユーザに対する応答を偽造されたコンテンツに置き換えることが可能である。例えば、攻撃者は、Ｒｅｄｉｓ－Ｕｓｅｒから届けられたパケットを内部的にドロップすることができ、偽造されたコンテンツを有する新たなパケットを注入することができる。次いで、Ｎｇｉｎｘ－Ｕｓｅｒは、元のコンテンツの代わりに偽造されたコンテンツを処理し、結果をユーザに返す。例えば、図７Ｄは、攻撃者によって図６のＮｇｉｎｘ－Ｕｓｅｒに注入された偽造パケットの一例を示す。結局、ユーザは、攻撃者が意図したとおりに偽造されたコンテンツを受け取る。

【0086】

危うくされたコンテナが、図７Ａに示すように、ピア発見を行って他のコンテナを探し出すために用いられる場合、現在のコンテナネットワークスタックは、攻撃者が、制限なしに全ての隣接コンテナを発見することを可能にしてしまっている。また、Ｋｕｂｅｒｎｅｔｅｓ環境におけるＷｅａｖｅオーバーレイネットワークは、コンテナが単一のスイッチにおいて論理的に探し出されるのに従って、コンテナが他のノードにおいて全てのコンテナを発見することを可能にしてしまっている。

【0087】

図６及び図７Ａ～７Ｄの従来技術のＫｕｂｅｒｎｅｔｅｓ環境とは対照的に、図８は、本原理の一実施形態によるネットワーク隔離から生じるパケットデータの図を示す。本原理の直接ＡＲＰハンドラ及びコンテナ認識ネットワーク隔離アーキテクチャは、各コンテナの依存関係に基づいて各コンテナの到達可能性を低下させる（Ｒ１）。図８のネットワーク情報に示されているように、本原理のアーキテクチャの結果として、感染したコンテナ（即ち、図６のＮｇｉｎｘ－Ｇｕｅｓｔ）は、１つの依存するコンテナのみを有し、コンテナは、そのゲートウェイ及び上記依存するコンテナのみを監視する。

【0088】

例えば、図９Ａは、攻撃者が本原理のエンドツーエンド転送なしに図６のなりすましされたターゲットコンテナを調べることができるトラフィックの一例を示す。即ち、図９Ａに示すように、危うくされたコンテナは、ターゲットコンテナのネットワークトラフィックを傍受することが可能である場合がある。更に、攻撃者が「ネットワーク特権」コンテナを危うくすると、攻撃者は全てのネットワークトラフィックへのアクセスを制限なしで提供される。

【0089】

対照的に、図９Ｂは、攻撃者がいかに本原理のエンドツーエンド転送を伴う応答トラフィックを調べることができないのかを例示するパケットデータを示す。図９Ｂに示すように、本原理に従って直接転送が適用される場合、所与のインタフェースから唯一の可視トラフィックは、コンテナ自体を伴うトラフィックである（Ｒ４～５）。違いを強調するために、図９Ｂでは、発信元から宛先へのトラフィックフローが意図的に可視化されている。結果として、攻撃者は発信元から宛先へのフローを観察することはできるが、攻撃者は、逆方向のトラフィックを観察することはできない。本原理によるエンドツーエンド転送が全てのトラフィックに完全に適用されている場合、攻撃者はそれらの間のトラフィックを調べることはできない。

【0090】

ネットワークベースの攻撃は、悪意のあるパケットをターゲットコンテナに送るために、なりすましパケット注入技術にしばしば頼る。図１のコンテナセキュリティシステム１００等の本原理のコンテナセキュリティシステムは、明示的な発信元検証を行うことによってこれらの攻撃を防ぐ。前もって設定された原理の実施形態の利点を更に説明するために、図１０Ａ～１０Ｄは、別の攻撃シナリオから生じるパケットデータ、具体的には攻撃者及び被害者の視点からのケースの前後を示す。図１０Ａは、従来のセキュリティアーキテクチャを有するコンテナネットワークのコンテナへの攻撃者によるＲＳＴパケットの注入を示すパケットデータを示す。図１０Ａのコンテナネットワークでは、発信元検証はＩＰレベルでのみ有効であり、攻撃者は、本原理の発信元検証なしでＡＲＰなりすまし攻撃を行うことができる。図１０Ａに示すように、攻撃者はＮｇｉｎｘ－Ｕｓｅｒになりすまし、Ｎｇｉｎｘ－Ｕｓｅｒのトラフィックを受けとる。更に、攻撃者はＲＳＴパケットを注入して、Ｎｇｉｎｘ－Ｕｓｅｒのセッションを終了させる。図１０Ｂは、攻撃者によるコンテナへのＲＳＴパケットの注入がＮｇｉｎｘ－Ｕｓｅｒの視点からどのようにしてセッション終了を引き起こすのかを示す。即ち、図１０Ｂに示すように、攻撃者がＲＳＴパケットを注入するとすぐに、Ｎｇｉｎｘ－Ｕｓｅｒは注入されたＲＳＴパケットを受け取り（ＲＳＴパケットの受信時間を参照）、Ｎｇｉｎｘ－Ｕｓｅｒのセッションを即座に終了させる。

【0091】

従来のコンテナネットワークアーキテクチャのそのような欠陥は、本原理の明示的な発信元検証によって取り除くことができる。例えば、図１０Ｃは、本原理の一実施形態による発信元検証を実装しているコンテナセキュリティシステムにＲＳＴパケットを注入するための攻撃者の試みに関連するパケットデータを示す。攻撃者は、図１０Ｃに示すように、ＲＳＴパケットを注入しようとするが、ＲＳＴパケットは、本原理の発信元検証の実装によって拒絶され（図１０Ｄに示すように）、ＲＳＴパケットがＮｇｉｎｘ-Ｕｓｅｒに到達するのが防止される（Ｒ５）。

【0092】

本発明者らは、本原理のコンテナセキュリティシステムの実装がＫｕｂｅｒｎｅｔｅｓ環境にどのように影響したのかを評価するために、Ｗｅａｖｅオーバーレイネットワークを有するＫｕｂｅｒｎｅｔｅｓ環境を構築した。構築されたＫｕｂｅｒｎｅｔｅｓ環境では、１つのシステムがＫｕｂｅｒｎｅｔｅｓマスターノードとしての役割を果たし、他の２つのシステムがコンテナホスティングノードとして機能した。各システムは、Ｉｎｔｅｌ Ｘｅｏｎ Ｅ５－２６３０ｖ４ ＣＰＵ、６４ ＧＢのＲＡＭ、及びＩｎｔｅｌ １０Ｇｂｐｓ ＮＩＣで構成された。ラウンドトリップ待ち時間及びＴＣＰストリームスループットを測定するために、ｎｅｔｐｅｒｆ及びｉｐｅｒｆをそれぞれ用いた。

【0093】

前述したように、図１のコンテナセキュリティシステム１００等の本原理のコンテナセキュリティシステムの実施形態は、コンテナプラットフォームからコンテナ情報を定期的に読み出し、新たなコンテナにクエリを行う。新たなコンテナが検出されると、コンテナセキュリティシステムは、新たらコンテナごとにネットワークスタックを確立／展開する。本原理により新たなネットワークスタックを確立／展開するための時間の長さを調査するために、本発明者らは、１００個のコンテナを作成するための展開時間を測定した。実験において、本発明者らは、各コンテナのネットワークスタックのコンパイルを実行するのに平均２．６７秒かかったと決定した。本発明者らは、コンテナがコンテナ自身のサービスを初期化する（即ち、リポジトリからのコンテナイメージをプルし、コンテナ隔離を構成し、サービスを開始する）のに数秒かかるので、そのような展開時間は無視し得るものと判断した。

【0094】

図１１は、ｉｐｔａｂｌｅｓベースのアクセス制御ネットワークと図１のコンテナセキュリティシステム（ＳＣＣ）等の本原理のコンテナセキュリティシステムを用いて制御されるネットワークとの両方に対するホスト内のセキュリティポリシー数の増大に従うコンテナ間スループット変動のグラフ表示を示す。ｉｐｔａｂｌｅｓの場合との公正な比較のために、本原理のコンテナセキュリティシステムを用いて制御されるネットワークのオーバーヘッドが決定される場合と同数のポリシーが各コンテナに対して定義される。ｉｐｔａｂｌｅｓの場合、全てのコンテナに対するセキュリティポリシーは、ホストカーネルにおいて集合的に維持される。従って、パケットがコンテナから到着すると、ｉｐｔａｂｌｅｓは先ず対応するコンテナに対するポリシーを調べ、着信パケットでそれらを個別に検査する。また、ｉｐｔａｂｌｅｓは一般的なアクセス制御用に設計されているので、ｉｐｔａｂｌｅｓは、多数のフィールド一致（少なくとも、各ポリシーに対する発信元及び宛先のＩＰアドレス及びポート）を必要とする。結果として、図１１に示すように、スループットは１００ポリシーで２３．３％、５００ポリシーで６４．０％低下した。この傾向は、コンテナネットワークに対する現在のポリシー実施アプローチでの根本的なスケーリングの課題を提示する。

【0095】

対照的に、図１１に示すように、本原理のコンテナセキュリティシステム（ＣＳＳ）に起因するスループットの低下は、ポリシーの数が増えるのに従ってほとんど目立たなくなった（５００ポリシーで３．２％）（Ｒ２）。このような性能の獲得は、コンテナ環境用に最適化された本原理のマッチングプロセスから生じており、これは、具体的な宛先に対するハッシュベースのポリシールックアップと、単一フィールドのマッチング（即ち、宛先ポートのマッチング）と、からなる。尚、本原理のコンテナセキュリティシステムのネットワークスタックは、それぞれのコンテナに特有のセキュリティポリシーのみを維持するので、従来技術の場合のように発信元ＩＰアドレス及びポートを一致させる必要はない。

【0096】

図１２Ａは、ホスト内における本原理のコンテナセキュリティシステムのサービスの異なる組み合わせに対するコンテナ間待ち時間測定値のグラフ表示を示す。即ち、図１２Ａは、単一ノード内の４つのテストケースのラウンドトリップ待ち時間比較を提供する。図１２Ａでは、ベースケースは、セキュリティサービスなしで相互作用した２つのコンテナのデフォルト構成に対する待ち時間測定値を提供し、これらは、ＴＣＰパケット及びＵＤＰパケットに対してそれぞれ２１．６μｓ及び１８．２μｓであった。本原理のコンテナセキュリティシステムのネットワーク可視化サービスが適用されたとき、コンテナ間の到達可能性チェックを得るために追加的なパケット処理を必要とする新たに適用されたセキュリティ機能に起因して、待ち時間は５．７％及び９．３％だけわずかに増加した。本原理のコンテナセキュリティシステムのトラフィック可視化サービスが適用されたとき、既存のコンテナネットワークをバイパスしつつ、安全な転送によってコンテナ間トラフィックが宛先コンテナに直接送り込まれるので、全体的な待ち時間は２６．３％と大幅に改善された。最後に、本原理のコンテナセキュリティシステムの全てのセキュリティ機能が完全に適用された場合、ＴＣＰパケット及びＵＤＰパケットについて、ベースケースに対して２３．０％及び２５．４％の全体的な性能向上が観察された（Ｒ６）。これらの待ち時間の改善を言い換えれば、１２．９％のホスト間スループットの向上であった。

【0097】

図１２Ｂは、ホスト全体にわたる本原理のコンテナセキュリティシステムのサービスの異なる組み合わせに対するコンテナ間待ち時間測定値のグラフ表示を示す。図１２Ｂに示すように、図１２Ａのホスト内測定値と比較して、ホスト間の物理リンクトラバーサル及びトンネリングオーバーヘッドにより、全体的な待ち時間が大幅に増大し、従って、ベースケースの待ち時間は、ＴＣＰパケット及びＵＤＰパケットに対してそれぞれ１００．１μｓ及び９１．５μｓになった。また、ネットワークへの影響を前提として、本原理のネットワーク可視化サービスに起因するオーバーヘッドは減少した（１％未満）。本原理のトラフィック可視化サービスでは、本原理の安全な転送が外部インタフェースを介して発信元コンテナから宛先コンテナにネットワークパケットを直接渡すので、待ち時間は平均で２１．３％減少した。最後に、本原理の全てのセキュリティサービスが適用された場合、待ち時間は１７．７％減少し、これはベースケースと比較して大幅な改善である（Ｒ６）。これらの待ち時間の改善を言い換えれば、１２．９％のホスト間スループットの向上であった。

【0098】

図１３は、本原理によりコンテナネットワークにセキュリティを提供するための方法１３００のフローチャートを示す。方法１３００は、１３０２で開始し、その間、コンテナネットワークの複数のコンテナの各々に対してネットワークスタックが確立される。方法１３００は１３０３に進むことができる。

【0099】

１３０３で、ネットワーク及びポリシー情報が、アクティブなコンテナから決定される。方法１３００は１３０４に進むことができる。

【0100】

１３０４で、決定されたネットワーク情報から学習された複数のコンテナに対する一連の所定のコンテナ間依存関係に基づいて、複数のコンテナのうちそれぞれの通信に関連しないコンテナへのアクセスが、拒否されない場合には、少なくとも限定される。方法１３００は１３０６に進むことができる。

【0101】

１３０６で、コンテナ間トラフィックは、ピアコンテナに対するコンテナ間トラフィックの暴露が防止されるように、ポイントツーポイントで発信元コンテナから宛先コンテナに直接供給されるよう構成される。方法１３００は終了され得る。

【0102】

図１に示すように、図１のコンテナセキュリティシステム１００等の本原理のコンテナセキュリティシステムの実施形態は、本原理に従ってコンピューティングデバイス１４００に実装することができる。即ち、いくつかの実施形態では、ネットワークパケット、通信内容、データ等は、例えば、コンピューティングデバイス１４００に関連する任意の入力／出力手段を介して、コンピューティングデバイス１４００を用いて、コンテナ及びコンテナセキュリティシステム１００のコンポーネントに対して又はそれらとの間で通信することができる。本原理によるコンテナセキュリティシステムに関連するデータは、ディスプレイ、プリンタ、又は任意の他の形態の出力デバイス等のコンピューティングデバイス１４００の出力デバイスを用いてユーザに提示することができる。

【0103】

例えば、図１４は、図１のコンテナセキュリティシステム１００等の本原理によるコンテナセキュリティシステムの実施形態での使用に適したコンピューティングデバイス１４００の高レベルのブロック図を示す。いくつかの実施形態では、コンピューティングデバイス１４００は、種々の実施形態において、プロセッサ実行可能な実行可能プログラム命令１４２２（例えば、１つ以上のプロセッサ９１０によって実行可能なプログラム命令）として本原理の方法を実装するように構成され得る。

【0104】

図１４の実施形態では、コンピューティングデバイス１４００は、入力／出力（Ｉ／Ｏ）インタフェース１４３０を介してシステムメモリ１４２０に結合された１つ以上のプロセッサ１４１０ａ～１４１０ｎを含む。コンピューティングデバイス１４００は、Ｉ／Ｏインタフェース１４３０に結合されたネットワークインタフェース１４４０と、カーソル制御デバイス１４６０、キーボード１４７０、及び１つ以上のディスプレイ１４８０等の１つ以上の入力／出力デバイス１４５０と、を更に含む。種々の実施形態では、ユーザインタフェースが生成され、ディスプレイ１４８０上に表示され得る。場合によっては、実施形態が、コンピューティングデバイス１４００の単一のインスタンスを用いて実装され得る一方で、他の実施形態では、複数のそのようなシステム、又はコンピューティングデバイス１４００を構成する複数のノードが、種々の実施形態の異なる部分又はインスタンスをホストするように構成され得ることが意図されている。例えば、１つの実施形態では、いくつかの要素は、他の要素を実装しているノードとは異なるコンピューティングデバイス１４００の１つ以上のノードを介して実装され得る。別の例では、複数のノードが、コンピューティングデバイス９００を分散型に実装してよい。

【0105】

異なる実施形態では、コンピューティングデバイス１４００は、種々のタイプのデバイスの何れかであることができ、これらは、限定されないが、パーソナルコンピュータシステム、デスクトップコンピュータ、ラップトップ、ノートブック、タブレット又はネットブックコンピュータ、メインフレームコンピュータシステム、ハンドヘルドコンピュータ、ワークステーション、ネットワークコンピュータ、カメラ、セットトップボックス、モバイルデバイス、コンシューマデバイス、ビデオゲームコンソール、ハンドヘルドビデオゲームデバイス、アプリケーションサーバ、ストレージデバイスや、スイッチ、モデム、又はルータ等の周辺デバイス、あるいは一般的な任意のタイプのコンピューティング又は電子デバイスを含む。

【0106】

種々の実施形態では、コンピューティングデバイス１４００は、１つのプロセッサ１４１０を含むユニプロセッサシステム、又はいくつかのプロセッサ１４１０（例えば、２つ、４つ、８つ、又は別の適切な数）を含むマルチプロセッサシステムであり得る。プロセッサ１４１０は、命令を実行可能な任意の適切なプロセッサであり得る。例えば、種々の実施形態では、プロセッサ１４１０は、種々の命令セットアーキテクチャ（ＩＳＡｓ）のいずれかを実装している汎用プロセッサ又は組み込み型プロセッサであり得る。マルチプロセッサシステムにおいては、プロセッサ１４１０の各々は、通常は同じＩＳＡを実装していてよいが、必ずしもそうである必要はない。

【0107】

システムメモリ１４２０は、プロセッサ１４１０によってアクセス可能なプログラム命令１４２２及び／又はデータ１４３２を記憶するように構成され得る。種々の実施形態では、システムメモリ１４２０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、同期ダイナミックＲＡＭ（ＳＤＲＡＭ）、不揮発性／フラッシュ型メモリ、又は他のタイプのメモリ等の任意の適切なメモリ技術を用いて実装され得る。図示の実施形態では、上述した実施形態の要素のいずれかを実装するプログラム命令及びデータは、システムメモリ１４２０内に記憶され得る。他の実施形態では、プログラム命令及び／又はデータは、異なるタイプのコンピュータアクセス可能媒体上で、あるいはシステムメモリ１４２０又はコンピューティングデバイス１４００とは別個の同様の媒体上で受信、送信、又は記憶され得る。

【0108】

１つの実施形態では、Ｉ／Ｏインタフェース１４３０は、プロセッサ１４１０、システムメモリ１４２０、及びデバイス内の任意の周辺デバイスの間でＩ／Ｏトラフィックを連携させるように構成することができ、これらは、ネットワークインタフェース１４４０又は入力／出力デバイス１４５０等の他の周辺インタフェースを含む。いくつかの実施形態では、Ｉ／Ｏインタフェース１４３０は、任意の必要なプロトコル、タイミング、又は他のデータ変換を実行して、１つのコンポーネント（例えば、システムメモリ１４２０）からのデータ信号を別のコンポーネント（例えば、プロセッサ１４１０）による使用に適したフォーマットに変換することができる。いくつかの実施形態では、Ｉ／Ｏインタフェース１４３０は、例えば、周辺コンポーネント相互接続(Peripheral Component Interconnect)（ＰＣＩ）バス規格又はユニバーサルシリアルバス(Universal Serial Bus)（ＵＳＢ）規格の変形等の種々タイプの周辺バスを通して加えられたデバイスのためのサポートを含み得る。いくつかの実施形態では、Ｉ／Ｏインタフェース１４３０の機能は、例えば、ノースブリッジ及びサウスブリッジ等の２つ以上の別個のコンポーネントに分割され得る。また、いくつかの実施形態では、システムメモリ１４２０へのインタフェース等のＩ／Ｏインタフェース１４３０の機能のいくつか又は全ては、プロセッサ１４１０に直接組み込まれ得る。

【0109】

ネットワークインタフェース１４４０は、コンピューティングデバイス１４００とネットワーク（例えば、ネットワーク１４９０）に加えられた１つ以上の外部システム等の他のデバイスとの間又はコンピューティングデバイス１４００のノード間でデータが交換可能になるように構成され得る。種々の実施形態では、ネットワーク１４９０は１つ以上のネットワークを含むことができ、これらは、限定されないが、ローカルエリアネットワーク（ＬＡＮｓ）（例えば、イーサネット又は企業ネットワーク）、ワイドエリアネットワーク（ＷＡＮｓ）（例えば、インターネット）、ワイヤレスデータネットワーク、他の電子データネットワーク、又はそれらの何らかの組み合わせを含む。種々の実施形態では、ネットワークインタフェース１４４０は、任意の適切なタイプのイーサネットネットワーク等の有線又は無線の一般的なデータネットワークを介して、例えば、デジタルファイバ通信ネットワークを介して、Ｆｉｂｅｒ Ｃｈａｎｎｅｌ Ｓａｎｓ等のストレージエリアネットワークを介して、あるいは他の適切なタイプのネットワーク及び／又はプロトコルを介して、通信をサポートすることができる。

【0110】

入力／出力デバイス１４５０は、いくつかの実施形態では、１つ以上のディスプレイ端末、キーボード、キーパッド、タッチパッド、走査デバイス、音声又は光認識デバイス、あるいは１つ以上のコンピュータシステムによりデータを入力し又はデータにアクセスするのに適した任意の他のデバイスを含み得る。複数の入力／出力デバイス１４５０が、コンピュータシステム内に存在することができ、又はコンピューティングデバイス１４００の種々のノード上に分散させることができる。いくつかの実施形態では、同様の入力／出力デバイスは、コンピューティングデバイス１４００から分離することができ、ネットワークインタフェース１４４０を介する等、有線又は無線接続を通してコンピューティングデバイス１４００の１つ以上のノードと相互作用することができる。

【0111】

当業者は、コンピューティングデバイス１４００が単なる例示であり、実施形態の範囲を限定することを意図していないことを理解するはずである。特に、コンピュータシステム及びデバイスは、種々の実施形態で示した機能を実行することができるハードウェア又はソフトウェアの任意の組み合わせを含むことができ、これらは、コンピュータ、ネットワークデバイス、インターネットアプライアンス、ＰＤＡｓ、無線電話、ページャ等を含む。コンピューティングデバイス１４００はまた、図示されていない他のデバイスに接続することができ、あるいはその代わりに、スタンドアロンシステムとして動作することができる。また、図示されたコンポーネントによって提供される機能は、いくつかの実施形態では、より少ないコンポーネントにおいて組み合わせることができ、あるいは追加のコンポーネント内に分散させることができる。同様に、いくつかの実施形態では、図示されたコンポーネントのいくつかの機能は提供されなくてよく、及び／又は他の追加の機能が利用可能であり得る。

【0112】

コンピューティングデバイス１４００は、Ｗｉ－Ｆｉ、Ｂｌｕｅｔｏｏｔｈ．ＲＴＭ．（及び／又は短距離でデータを交換するための他の規格は短波長無線伝送を用いるプロトコルを含む）、ＵＳＢ、イーサネット、セルラー、超音波ローカルエリア通信プロトコル等の種々のコンピュータ通信プロトコルに基づいて他のコンピューティングデバイスと通信することができる。コンピューティングデバイス１４００は、ウェブブラウザを更に含み得る。

【0113】

コンピューティングデバイス１４００は汎用コンピュータとして示されているが、コンピューティングデバイス１４００は、種々の特殊化された制御機能を実行するようにプログラムされ、本原理に従って特殊化された具体的なコンピュータとしての機能を果たすように構成され、実施形態は、例えば、特定用途向け集積回路（ＡＳＩＣ）としてハードウェアに実装される。従って、ここで説明されるプロセスステップは、ソフトウェア、ハードウェア、又はそれらの組み合わせによって同等に実行されるものとして広く解釈されることが意図されている。

【0114】

図１５は、ネットワークの高レベルのブロック図を示しており、このネットワークにおいては、図１のコンテナセキュリティシステム１００等の本原理によるコンテナセキュリティシステムの実施形態が適用され得る。図１５のネットワーク環境１５００は、例示的に、ユーザドメインサーバ／コンピューティングデバイス１５０４を含むユーザドメイン１５０２を備える。図１５のネットワーク環境１５００は、コンピュータネットワーク１５０６と、クラウドサーバ／コンピューティングデバイス１５１２を含むクラウド環境１５１０と、を更に備える。

【0115】

図１５のネットワーク環境１５００において、図１のシステム１００等の本原理によるコンテナセキュリティのためのシステムは、ユーザドメインサーバ／コンピューティングデバイス１５０４、コンピュータネットワーク１５０６、及びクラウドサーバ／コンピューティングデバイス１５１２のうちの少なくとも１つに含まれ得る。即ち、いくつかの実施形態では、ユーザは、ローカルサーバ／コンピューティングデバイス（例えば、ユーザドメインサーバ／コンピューティングデバイス１５０４）を用いて、本原理によるコンテナセキュリティを提供することができる。

【0116】

いくつかの実施形態では、ユーザは、コンピュータネットワーク１５０６においてコンテナセキュリティのためのシステムを実装して、本原理によるコンテナセキュリティを提供することができる。代替的又は追加的に、いくつかの実施形態では、ユーザは、クラウド環境１５１０のクラウドサーバ／コンピューティングデバイス１５１２においてコンテナセキュリティのためのシステムを実装して、本原理によるコンテナセキュリティを提供することができる。例えば、いくつかの実施形態では、クラウド環境１５１０の処理能力及びストレージ能力を生かすために、クラウド環境１５１０において本原理の処理機能を実行することが有利であり得る。

【0117】

本原理によるいくつかの実施形態では、コンテナネットワークにおいてコンテナセキュリティを提供するためのシステムは、単一及び／又は複数のロケーション／サーバ／コンピュータに配置して、ここで説明した本原理によるシステムの機能の全部又は一部を実行することができる。例えば、いくつかの実施形態では、コンテナネットワークのコンテナ１１０は、ユーザドメイン１５０２、コンピュータネットワーク環境１５０６、及びクラウド環境１５１０のうちの１つ以上に配置することができ、グローバルマネージャ１２０等の本原理の少なくとも１つのグローバルマネージャは、ローカル又はリモートのいずれかで上述した機能を提供するために、ユーザドメイン１５０２、コンピュータネットワーク環境１５０６、及びクラウド環境１５１０のうちの少なくとも１つに配置することができる。

【0118】

いくつかの実施形態では、本原理のコンテナセキュリティは、例えばソフトウェアを介したサービスとして提供され得る。そのような実施形態では、本原理のソフトウェアは、ユーザドメインサーバ／コンピューティングデバイス１５０４、コンピュータネットワーク１５０６、及びクラウドサーバ／コンピューティングデバイス１５１２のうちの少なくとも１つに存在し得る。更には、いくつかの実施形態では、本原理の実施形態を提供するためのソフトウェアは、ユーザドメインサーバ／コンピューティングデバイス１５０４、コンピュータネットワーク１５０６、及びクラウドサーバ／コンピューティングデバイス１５１２における任意のコンピューティングデバイスでコンピューティングデバイスによって実行され得る非一時的コンピュータ可読媒体を介して提供され得る。

【0119】

当業者はまた、種々のアイテムが使用中にメモリ又はストレージに記憶されているように示されている一方で、これらのアイテム又はそれらの一部は、メモリ管理及びデータ完全性の目的でメモリと他のストレージデバイスの間で転送され得ることを理解するはずである。代替的に、他の実施形態では、ソフトウェアコンポーネントのいくつか又は全ては、別のデバイス上のメモリ内で実行され、コンピュータ間通信を介して図示のコンピュータシステムと通信することができる。システムコンポーネント又はデータ構造の一部又は全ては、適切なドライブによって読み取られるように、コンピュータアクセス可能な媒体又は携帯アーティクル上に記憶することができ（例えば、命令又は構造化データとして）、その種々の例は上述されている。いくつかの実施形態では、コンピューティングデバイス１４００とは別個のコンピュータアクセス可能媒体に記憶された命令は、伝送媒体を介して、あるいはネットワーク及び／又は無線リンク等の伝送媒体を介して伝えられる電気信号、電磁信号、又はデジタル信号等の信号を介してコンピューティングデバイス１４００に送信され得る。種々の実施形態は、コンピュータアクセス可能な媒体上で又は通信媒体を介して前述の説明に従って実装される命令及び／又はデータを受信し、送信し、又は記憶することを更に含み得る。一般に、コンピュータアクセス可能媒体は、磁気又は光学媒体等の記憶媒体又はメモリ媒体、例えばディスク又はＤＶＤ／ＣＤ－ＲＯＭ、あるいはＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭ等の揮発性媒体又は不揮発性媒体を含み得る。

【0120】

ここで説明される方法及びプロセスは、種々の実施形態において、ソフトウェア、ハードウェア、又はそれらの組み合わせにおいて実装されてよい。また、方法の順序は変更することができ、種々の要素が追加され、並べ替えられ、結合され、省略され、又はさもなければ修正され得る。ここで説明される全ての例は、非限定的な方法で提示されている。本開示の利益を享受する当業者に明らかであろうように、種々の修正及び変更がなされ得る。実施形態による具現化が、特定の実施形態に関連して説明されてきた。これらの実施形態は、例示的であることを意図するものであり、限定するものではない。多くの変形、修正、追加、及び改良が可能である。従って、単一のインスタンスとしてここで説明されるコンポーネントに対して、複数のインスタンスが提供され得る。種々のコンポーネント、動作、及びデータストア間の境界は多少は任意的であり、特定の動作が具体的な例示的構成に関連して示されている。機能の他の割り当てが想定されており、これらは以下の特許請求の範囲に含まれ得る。構成例において個別のコンポーネントとして提示された構造及び機能は、組み合わせた構造又はコンポーネントとして実装され得る。これらの及び他の変形、修正、追加、及び改良は、以下の特許請求の範囲で定義されるような実施形態の範囲内に含まれ得る。

【0121】

前述の説明では、本開示のより完全な理解を提供するために、多数の具体的詳細、例、及びシナリオが述べられている。しかし、本開示の実施形態は、そのような具体的詳細なしで実施され得ることが理解されるはずである。更に、そのような例及びシナリオは、説明のために提供されており、開示を限定することは全く意図されていない。当業者は、含まれる説明を参照して、必要以上の実験なしに適切な機能を実装することが可能なはずである。

【0122】

本明細書において「一実施形態」等への言及は、説明された実施形態が特定の特徴、構造、又は特性を含み得るが、全ての実施形態が必ずしもその特定の特徴、構造、又は特性を含まなくてもよいことを示す。そのような語句は、必ずしも同じ実施形態を参照しているとは限らない。更に、特定の特徴、構造、又は特性が実施形態に関連して説明される場合、明示的に示されているかどうかを問わず、他の実施形態に関連してそのような特徴、構造、又は特性に影響を与えることは、当業者の知識の範囲内であると考えられる。

【0123】

本開示による実施形態は、ハードウェア、ファームウェア、ソフトウェア、又はそれらの任意の組み合わせにおいて実装され得る。ソフトウェアとして提供される場合、本原理の実施形態は、ローカルユーザ環境におけるコンピューティングデバイス、インターネット環境におけるコンピューティングデバイス、及びクラウド環境におけるコンピューティングデバイス等のコンピューティングデバイスの少なくとも１つに存在し得る。実施形態はまた、１つ以上の機械可読媒体を用いて記憶された命令として実装することができ、それらは、１つ以上のプロセッサによって読み取られ、実行されてよい。機械可読媒体は、機械（例えば、コンピューティングデバイス、又は１つ以上のコンピューティングデバイス上で実行される「仮想マシン」）によって可読な形態で情報を記憶し又は送信するための任意のメカニズムを含み得る。例えば、機械可読媒体は、任意の適切な形態の揮発性又は不揮発性メモリを含み得る。

【0124】

ここで定義されるモジュール、データ構造等は、議論を容易にするためにそのようなものと定義されており、任意の具体的な実装の詳細が必要であることを暗示することを意図するものではない。例えば、説明されたモジュール及び／又はデータ構造は、どれも組み合わされ得るし、あるいは特定の設計又は実装によって必要とされ得るようなサブモジュール、サブプロセス、又はコンピュータコード若しくはデータの他のユニットに分割され得る。

【0125】

図面では、説明を容易にするために、概略要素の具体的な配置又は順序が示され得る。しかし、そのような要素の具体的な順序又は配置は、全ての実施形態において処理の特定の順序若しくはシーケンス又はプロセスの分離が必要であると暗示することを意味するものではない。一般に、命令ブロック又はモジュールを表すために用いられる概略要素は、任意の適切な形態の機械可読命令を用いて実装することができ、そのような各命令は、任意の適切なプログラミング言語、ライブラリ、アプリケーションプログラミングインタフェース（ＡＰＩ）、及び／又は他のソフトウェア開発ツール若しくはフレームワークを用いて実装され得る。同様に、データ又は情報を表すために用いられる概略要素は、任意の適切な電子的配置又はデータ構造を用いて実装され得る。更に、要素間のいくつかの接続、関係、又は関連は、開示を曖昧にしないように、簡略化されている可能性があり、あるいは図面に示されていない可能性がある。

【0126】

本開示は、例示的であるとみなされるべきであり、また性質を制限するものではないと見なされるべきであり、本開示のガイドライン内に入る全ての変更及び修正は保護されることが望まれる。

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図5A】

【図5B】

【図6】

【図7A】

【図7B】

【図7C】

【図7D】

【図8】

【図9A】

【図9B】

【図10A】

【図10B】

【図10C】

【図10D】

【図11】

【図12A】

【図12B】

【図13】

【図14】

【図15】

【図16】