特許 7005795 フォレンジックを提供してコンテナを管理するための方法、装置、及びシステム

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

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

(11)【特許番号】

(24)【登録日】2022-01-07

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

(54)【発明の名称】フォレンジックを提供してコンテナを管理するための方法、装置、及びシステム

(51)【国際特許分類】

   G06F 11/07 20060101AFI20220117BHJP

   G06N 3/02 20060101ALI20220117BHJP

   G06F 11/34 20060101ALI20220117BHJP

【ＦＩ】

G06F11/07 175

G06N3/02

G06F11/07 140C

G06F11/34 147

【請求項の数】 18

【外国語出願】

(21)【出願番号】P 2021000214

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

(65)【公開番号】P2021111397

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

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

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

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

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

(31)【優先権主張番号】17/134,605

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

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

(73)【特許権者】

【識別番号】501228071

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

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

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

(74)【代理人】

【識別番号】100108833

【弁理士】

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

(74)【代理人】

【識別番号】100162156

【弁理士】

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

(72)【発明者】

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

(72)【発明者】

【氏名】プラカル シャルマ

【審査官】川▲崎▼ 博章

(56)【参考文献】

【文献】特開２０１８－４９３５５（ＪＰ，Ａ）

【文献】特開２０１９－９１２３６（ＪＰ，Ａ）

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

【文献】CLANCY, T.Charles et al.，Securing Cloud Containers through Intrusion Detection and Remediation [online]，2017年08月01日，[retrieved on 2021.04.12], Retrieved from the Internet: <https://vtechworks.lib.vt.edu/bitstream/handle/10919/87730/Abed_AS_D_2017.pdf?isAllowed=y&sequence=1>

【文献】PREUVENEERS, Davy et al.，Chained anomaly detection models for federated learning: An intrusion detection case study [online]，2018年12月18日，[retrieved on 2021.04.12], Retrieved from the Internet: <URL: http://scholar.google.co.jp/scholar_url?url=https%3A%2F%2Fwww.mdpi.com%2F2076-3417%2F8%2F12%2F2663%2Fpdf&hl=ja&sa=T&oi=gga&ct=gga&cd=0&d=10511574641935885971&ei=zKJzYLSPMJLKyQSivYvgCQ&scisig=AAGBfm3niGbkVDvQbq-CifYbCduiHWkyuA&nossl=1&ws=787x399&at=Chained%20anomaly%20detection%20models%20for%20federated%20learning%3A%20An%20intrusion%20detection%20case%20study>

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

Ｇ０６Ｆ １１／０７，１１／２８－１１／３６

Ｇ０６Ｎ ３／０２，２０／００

Ｇ０６Ｆ ２１／００，２１／３０－２１／４６

Ｇ０６Ｆ ２１／１２－２１／１６

Ｇ０６Ｆ ２１／５０－２１／５７

Ｇ０６Ｆ １２／１４

Ｇ０６Ｆ ２１／１０，２１／６０－２１／８８

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

【請求項1】

１つ以上のアプリケーションコンテナに対してグローバルエンコーダ／デコーダ対を決定するための方法であって、
安定な方法で動作していることが分かっているアプリケーションコンテナのフォレンジック情報を監視することと、
前記安定な方法で動作していることが分かっているアプリケーションコンテナの監視されたフォレンジック情報に自動エンコーディングプロセスを適用して、エンコーディング時に前記フォレンジック情報の最大値を保つと共にデコーディング時に再構成エラーの最小値を有するエンコーダ／デコーダ対を決定することと、
決定された前記エンコーダ／デコーダ対を、前記安定な方法で動作していることが分かっているアプリケーションコンテナの前記監視されたフォレンジック情報に適用して、安定な方法で動作していることが分かっている前記アプリケーションコンテナに対するトレーニングフォレンジックモデルを決定することと、を備え、
前記トレーニングフォレンジックモデルは、１つ以上のコンテナのコンテナ健全性を決定するための比較の基礎として用いられる、方法。

【請求項2】

前記トレーニングフォレンジックモデルを前記アプリケーションコンテナの上位レベルの管理のために上位レベルのマネージャに伝達することを備える、請求項１に記載の方法。

【請求項3】

前記自動エンコーディングプロセスを適用する前に前記フォレンジック情報を要約することを更に備え、
前記要約することは、前記フォレンジック情報を分類すること、及び前記フォレンジック情報をタイムクォンタムによってベクトル化することのうちの少なくとも１つを備える、請求項１に記載の方法。

【請求項4】

前記トレーニングフォレンジックモデルは、前記エンコーダ／デコーダ対のエンコーディングプロセスによって決定された潜在コードを備え、前記エンコーディングプロセスはニューラルネットワークを含む、請求項１に記載の方法。

【請求項5】

コンテナネットワークの複数のアプリケーションコンテナに対してプロセスレベルのフォレンジックを提供するための方法であって、
前記複数のアプリケーションコンテナの各々に対して、
前記アプリケーションコンテナのフォレンジック情報を監視することと、
所定のエンコーダ／デコーダ対のエンコーダを用いて、監視された前記フォレンジック情報をエンコードして、前記アプリケーションコンテナの前記監視されたフォレンジック情報を表すモデルを決定することと、
前記所定のエンコーダ／デコーダ対のデコーダを用いて前記モデルをデコードして、前記フォレンジック情報の再構成された表現を決定することと、
前記フォレンジック情報の再構成された表現を前記監視されたフォレンジック情報と比較して、エラーを決定することと、
決定された前記エラーを所定の閾値と比較して前記所定の閾値を超えるエラーが存在するかどうかを決定することと、
前記所定の閾値を超えるエラーが存在しないと決定された場合、前記アプリケーションコンテナの前記監視されたフォレンジック情報を表す前記モデルを、前記複数のアプリケーションコンテナ及び前記コンテナネットワークのうちの少なくとも１つの上位レベルの管理のために用いられるように上位レベルのマネージャに伝達することと、
前記所定の閾値を超えるエラーが存在すると決定された場合、前記アプリケーションコンテナの前記監視されたフォレンジック情報を表す前記モデル及び前記アプリケーションコンテナの前記監視されたフォレンジック情報を、前記複数のアプリケーションコンテナ及び前記コンテナネットワークのうちの少なくとも１つの上位レベルの管理のために用いられるように前記上位レベルのマネージャに伝達することと、を備える方法。

【請求項6】

前記監視されたフォレンジック情報をエンコードする前に前記フォレンジック情報を要約することを更に備え、
前記要約することは、前記フォレンジック情報を分類すること、及び前記フォレンジック情報をタイムクォンタムによってベクトル化することのうちの少なくとも１つを備える、請求項５に記載の方法。

【請求項7】

前記所定のエンコーダ／デコーダ対は、安定な方法で動作していることが分かっているアプリケーションコンテナのフォレンジック情報に自動エンコーディングプロセスを適用することによって決定される、請求項５に記載の方法。

【請求項8】

前記所定の閾値を超えるエラーが存在すると決定された場合、それぞれのアプリケーションコンテナは安定な方法で動作していないと見なされる、請求項５に記載の方法。

【請求項9】

前記上位レベルのマネージャは、前記所定の閾値を超えるエラーを有すると決定された少なくとも１つのアプリケーションコンテナから伝達された受信モデル及び受信フォレンジック情報のうちの少なくとも１つを分析して、前記少なくとも１つのアプリケーションコンテナに対して過剰エラーの理由を決定する、請求項５に記載の方法。

【請求項10】

前記上位レベルのマネージャは、前記複数のアプリケーションコンテナから伝達された受信モデル及び受信フォレンジック情報のうちの少なくとも１つから、前記複数のアプリケーションコンテナの動作特性のグローバルモデルを決定する、請求項５に記載の方法。

【請求項11】

コンテナネットワークの複数のアプリケーションコンテナに対してプロセスレベルのフォレンジックを提供するための装置であって、
前記複数のアプリケーションコンテナの各々に対して、
前記アプリケーションコンテナのフォレンジック情報を監視する要約モジュールと、
所定のエンコーダ／デコーダ対のエンコーダであって、監視されたフォレンジック情報をエンコードして前記アプリケーションコンテナの監視されたフォレンジック情報を表すモデルを決定するエンコーダと、
前記所定のエンコーダ／デコーダ対のデコーダであって、前記モデルをデコードして前記フォレンジック情報の再構成された表現を決定するデコーダと、
パブリッシャー／エラーエバリュエーターモジュールと、を備え、
前記パブリッシャー／エラーエバリュエーターモジュールは、
前記フォレンジック情報の再構成された表現を前記監視されたフォレンジック情報と比較してエラーを決定し、
決定されたエラーを所定の閾値と比較して前記所定の閾値を超えるエラーが存在するかどうかを決定し、
前記エラーが前記所定の閾値未満である場合、前記アプリケーションコンテナの監視されたフォレンジック情報を表す前記モデルを、前記複数のアプリケーションコンテナ及び前記コンテナネットワークのうちの少なくとも１つの上位レベルの管理のために用いられるように上位レベルのマネージャモジュールに伝達し、
前記エラーが前記所定の閾値を超える場合、前記アプリケーションコンテナの監視されたフォレンジック情報を表す前記モデル及び前記アプリケーションコンテナの監視されたフォレンジック情報を、前記複数のアプリケーションコンテナ及び前記コンテナネットワークのうちの少なくとも１つの上位レベルの管理のために用いられるように前記上位レベルのマネージャモジュールに伝達するように構成される、装置。

【請求項12】

前記アプリケーションコンテナの監視されたフォレンジック情報及び前記アプリケーションコンテナの決定されたモデルのうちの少なくとも１つを記憶するためのストレージデバイスを更に備える、請求項１１に記載の装置。

【請求項13】

前記上位レベルのマネージャはグローバルマネージャモジュールを備え、前記グローバルマネージャモジュールは、前記複数のアプリケーションコンテナから受信したモデル及びフォレンジック情報のうちの少なくとも１つを用いて、前記コンテナネットワークの前記複数のアプリケーションコンテナの動作特性のグローバルモデルを決定する、請求項１１に記載の装置。

【請求項14】

前記上位レベルのマネージャはグローバルマネージャモジュールを備え、前記グローバルマネージャモジュールは、前記複数のアプリケーションコンテナから受信した少なくともモデル及びフォレンジック情報を用いて、前記複数のアプリケーションコンテナのうちの少なくとも１つの動作がドリフトしたかどうかを決定する、請求項１１に記載の装置。

【請求項15】

前記グローバルマネージャモジュールは、非監督ｋ平均クラスタ分析、ペアワイズ余弦類似度分析、又は他の類似度メトリックのうちの少なくとも１つを用いて、前記複数のアプリケーションコンテナのうちの少なくとも１つの動作がドリフトしたかどうかを決定する、請求項１４に記載の装置。

【請求項16】

前記上位レベルのマネージャはグローバルマネージャモジュールを備え、前記グローバルマネージャモジュールは、前記所定の閾値を超えるエラーを有すると決定された少なくとも１つのアプリケーションコンテナにおいて決定された過剰エラーの理由を、前記少なくとも１つのアプリケーションコンテナから受信したモデル及びフォレンジック情報のうちの少なくとも１つを用いて決定する、請求項１１に記載の装置。

【請求項17】

前記グローバルマネージャモジュールは、前記過剰エラーの理由が、不十分なトレーニングモデルであると決定し、少なくとも１つのトレーニングモデルの再トレーニングを生じさせる、請求項１６に記載の装置。

【請求項18】

前記少なくとも１つのトレーニングモデルは、前記監視されたフォレンジック情報のエンコーディング時に前記フォレンジック情報の最大値を保つと共にエンコードされたフォレンジック情報のデコーディング時に再構成エラーの最小値を有するエンコーダ／デコーダ対を備える、請求項１７に記載の装置。

【発明の詳細な説明】

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

【0001】

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

【技術分野】

【0002】

本原理の実施形態は、一般に、コンテナネットワークアプリケーションに関し、より具体的には、プロセスレベルのフォレンジックを提供して、例えばコンテナネットワークのアプリケーションコンテナを管理することに関する。

【背景技術】

【0003】

コンテナは、複雑なプロダクションインターネットサービスを、管理可能な（コンポーネント化された）マイクロサービスに分解するために広く利用されている。特にプロダクションマイクロサービスのスケーラブルなインスタント化に対しては、仮想アプリケーションの展開のためのコンテナ化技術の使用が驚くべき速度で成長してきている。しかし、マイクロサービスにはコンテナ間ネットワーキングが不可欠である一方で、コンテナネットワーキングの動作安定性の問題は、十分に精査されてきてはいない。例えば、インシデント検出及び損害評価を容易にするためのプロセスレベルのコンテナフォレンジックの分野でなされた仕事はそれほど多くない。

【発明の概要】

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

【0004】

特に、プロセスレベルのアクティビティフォレンジック収集は、典型的には、ＣＰＵ、ＩＯ、ネットワークトランスポート、及びデータストレージの要件を増やす。また、インデックス作成のためにフォレンジックデータをデータリポジトリにストリーミングすると、帯域幅及びストレージが消費され、そのようなワークロードの強さによりシステムコールの量が増え、フォレンジックコストが更に上がる。コンテナの並列オーケストレーションが増えるのに従って、デジタルフォレンジックのプロダクション負荷が過負荷及び飽和につながる可能性がある。

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

【0005】

例えばコンテナネットワークのアプリケーションコンテナを管理するためのプロセスレベルのフォレンジックを提供するための方法、装置、及びシステムの実施形態がここに開示される。

【0006】

いくつかの実施形態では、１つ以上のアプリケーションコンテナに対してグローバルエンコーダ／デコーダ対を決定するための方法は、安定な方法で動作していることが分かっているアプリケーションコンテナのフォレンジック情報を監視することと、安定な方法で動作していることが分かっているアプリケーションコンテナの監視されたフォレンジック情報に自動エンコーディングプロセスを適用して、エンコーディング時にフォレンジック情報の最大値を保つと共にデコーディング時に再構成エラーの最小値を有するエンコーダ／デコーダ対を決定することと、決定されたエンコーダ／デコーダ対を、安定な方法で動作していることが分かっているアプリケーションコンテナの監視されたフォレンジック情報に適用して、安定な方法で動作していることが分かっているアプリケーションコンテナに対するトレーニングフォレンジックモデルを決定することと、を含み、トレーニングフォレンジックモデルは、１つ以上のコンテナのコンテナ健全性を決定するための比較の基礎として用いられる。

【0007】

いくつかの実施形態では、アプリケーションコンテナの各々に対してそれぞれのフォレンジックモデルを決定する同様の機能を有するアプリケーションコンテナのそれぞれのフォレンジック情報への適用のためにグローバルエンコーダ／デコーダ対を決定するための方法は、安定な方法で動作していることが分かっているアプリケーションコンテナのフォレンジック情報を監視することと、安定な方法で動作していることが分かっているアプリケーションコンテナの監視されたフォレンジック情報に自動エンコーディングプロセスを適用して、エンコーディング時にフォレンジック情報の最大値を保つと共にデコーディング時に再構成エラーの最小値を有するエンコーダ／デコーダ対を決定することと、決定されたエンコーダ／デコーダ対を、安定な方法で動作していることが分かっているアプリケーションコンテナの監視されたフォレンジック情報に適用して、安定な方法で動作していることが分かっているアプリケーションコンテナに対するトレーニングフォレンジックモデルを決定することと、決定されたエンコーダ／デコーダ対を少なくとも１つの他のアプリケーションコンテナのフォレンジック情報に適用して、アプリケーションコンテナに対するそれぞれのフォレンジックモデルを決定することと、を含む。

【0008】

いくつかの実施形態では、方法は、自動エンコーディングプロセスを適用する前にフォレンジック情報を要約することを更に含み得る。いくつかの実施形態では、要約することは、フォレンジック情報を分類すること、及びフォレンジック情報をタイムクォンタム(time quantum)によってベクトル化することのうちの少なくとも１つを含み得る。

【0009】

いくつかの実施形態では、方法の自動エンコーディングプロセスは、バニラ自動エンコーディングプロセス、変分自動エンコーディングプロセス、及び時系列異常検出のための変分自動エンコーディングプロセスのうちの少なくとも１つを含み得る。

【0010】

いくつかの実施形態では、方法は、トレーニングフォレンジックモデル及びそれぞれのフォレンジックモデルのうちの少なくとも１つをアプリケーションコンテナの上位レベルの管理のために上位レベルのマネージャに伝達することを含み得る。

【0011】

いくつかの実施形態では、トレーニングフォレンジックモデル及びそれぞれのフォレンジックモデルのうちの少なくとも１つは、エンコーダ／デコーダ対のエンコーディングプロセスによって決定された潜在コード(latent code)を備え、エンコーディングプロセスはニューラルネットワークを含む。

【0012】

いくつかの実施形態では、コンテナネットワークの複数のアプリケーションコンテナに対してプロセスレベルのフォレンジックを提供するための方法は、複数のアプリケーションコンテナの各々に対して、アプリケーションコンテナのフォレンジック情報を監視することと、所定のエンコーダ／デコーダ対のエンコーダを用いて、監視されたフォレンジック情報をエンコードして、アプリケーションコンテナの監視されたフォレンジック情報を表すフォレンジックモデルを決定することと、所定のエンコーダ／デコーダ対のデコーダを用いてフォレンジックモデルをデコードして、フォレンジック情報の再構成された表現を決定することと、フォレンジック情報の再構成された表現を監視されたフォレンジック情報と比較して、エラーを決定することと、決定されたエラーを所定の閾値と比較して所定の閾値を超えるエラーが存在するかどうかを決定することと、エラーが所定の閾値未満である場合、アプリケーションコンテナの監視されたフォレンジック情報を表すフォレンジックモデルを、複数のアプリケーションコンテナ及びコンテナネットワークのうちの少なくとも１つの上位レベルの管理のために用いられるように上位レベルのマネージャに伝達することと、所定の閾値を超えるエラーが存在すると決定された場合、アプリケーションコンテナの監視されたフォレンジック情報を表すフォレンジックモデル及びアプリケーションコンテナの監視されたフォレンジック情報を、複数のアプリケーションコンテナ及びコンテナネットワークのうちの少なくとも１つの上位レベルの管理のために用いられるように上位レベルのマネージャに伝達することと、を含む。

【0013】

本原理によるいくつかの実施形態では、方法は、監視されたフォレンジック情報をエンコードする前にフォレンジック情報を要約することを更に含むことができ、要約することは、フォレンジック情報を分類すること、及びフォレンジック情報をタイムクォンタムによってベクトル化することのうちの少なくとも１つを含むことができる。

【0014】

本原理によるいくつかの実施形態では、方法の所定のエンコーダ／デコーダ対は、安定な方法で動作していることが分かっているアプリケーションコンテナのフォレンジック情報に自動エンコーディングプロセスを適用することによって決定され得る。

【0015】

本原理によるいくつかの実施形態では、アプリケーションコンテナの各々に対してそれぞれのフォレンジックモデルを決定する同様の機能を有するアプリケーションコンテナのそれぞれのフォレンジック情報への適用のためにグローバルエンコーダ／デコーダ対を決定するための装置は、安定な方法で動作していることが分かっておりアプリケーションコンテナを代表するアプリケーションコンテナのフォレンジック情報を監視する要約モジュールと、自動エンコーダモジュールと、を含む。いくつかの実施形態では、自動エンコーダモジュールは、安定な方法で動作していることが分かっているアプリケーションコンテナの監視されたフォレンジック情報に自動エンコーディングプロセスを適用して、エンコーディング時にフォレンジック情報の最大値を保つと共にデコーディング時に再構成エラーの最小値を有するエンコーダ／デコーダ対を決定し、決定されたエンコーダ／デコーダ対を、安定な方法で動作していることが分かっているアプリケーションコンテナの監視されたフォレンジック情報に適用して、安定な方法で動作していることが分かっているアプリケーションコンテナに対するトレーニングフォレンジックモデルを決定し、決定されたエンコーダ／デコーダ対を少なくとも１つの他のアプリケーションコンテナのフォレンジック情報に適用して、アプリケーションコンテナに対するそれぞれのフォレンジックモデルを決定するように構成される。

【0016】

いくつかの実施形態では、装置の要約モジュールは、更に、フォレンジック情報を分類し、フォレンジック情報をタイムクォンタムによってベクトル化する。

【0017】

本開示によるいくつかの実施形態では、コンテナネットワークの複数のアプリケーションコンテナに対してプロセスレベルのフォレンジックを提供するための装置は、複数のアプリケーションコンテナの各々に対して、アプリケーションコンテナのフォレンジック情報を監視する要約モジュールと、所定のエンコーダ／デコーダ対のエンコーダであって、監視されたフォレンジック情報をエンコードしてアプリケーションコンテナの監視されたフォレンジック情報を表すフォレンジックモデルを決定するエンコーダと、所定のエンコーダ／デコーダ対のデコーダであって、フォレンジックモデルをデコードしてフォレンジック情報の再構成された表現を決定するデコーダと、パブリッシャー／エラーエバリュエーターモジュールと、を含む。

【0018】

いくつかの実施形態では、パブリッシャー／エラーエバリュエーターモジュールは、フォレンジック情報の再構成された表現を監視されたフォレンジック情報と比較してエラーを決定し、決定されたエラーを所定の閾値と比較して所定の閾値を超えるエラーが存在するかどうかを決定し、所定の閾値を超えるエラーが存在しないと決定された場合、アプリケーションコンテナの監視されたフォレンジック情報を表すフォレンジックモデルを、複数のアプリケーションコンテナ及びコンテナネットワークのうちの少なくとも１つの上位レベルの管理のために用いられるようにグローバルマネージャモジュールに伝達し、所定の閾値を超えるエラーが存在すると決定された場合、アプリケーションコンテナの監視されたフォレンジック情報を表すフォレンジックモデル及びアプリケーションコンテナの監視されたフォレンジック情報を、複数のアプリケーションコンテナ及びコンテナネットワークのうちの少なくとも１つの上位レベルの管理のために用いられるようにグローバルマネージャモジュールに伝達するように構成される。

【0019】

いくつかの実施形態では、装置は、アプリケーションコンテナの監視されたフォレンジック情報、アプリケーションコンテナの再構成されたフォレンジック情報、及び決定されたフォレンジックモデル表現のうちの少なくとも１つを記憶するためのストレージデバイスを更に含み得る。

【0020】

いくつかの実施形態では、装置は、複数のアプリケーションコンテナから受信した少なくともフォレンジックモデル及びフォレンジック情報を用いて、コンテナネットワークの複数のアプリケーションコンテナの動作特性のグローバルモデルを決定するグローバルマネージャモジュールを更に含み得る。いくつかの実施形態では、グローバルマネージャモジュールは、複数のアプリケーションコンテナから受信した少なくともフォレンジックモデル及びフォレンジック情報を用いて、複数のアプリケーションコンテナのうちの少なくとも１つの動作がドリフトしたかどうかを決定し、非監督ｋ平均クラスタ分析(unsupervised k-means cluster analysis)、ペアワイズ余弦類似度分析(pairwise cosine similarity analysis)、又は他の類似度メトリック(similarity metrics)のうちの少なくとも１つを適用して、複数のアプリケーションコンテナのうちの少なくとも１つの動作がドリフトしたかどうかを決定する。

【0021】

いくつかの実施形態では、グローバルマネージャモジュールは、所定の閾値を超えるエラーを有すると決定された少なくとも１つのアプリケーションコンテナにおいて決定された過剰エラーの理由を、少なくとも１つのアプリケーションコンテナから受信したフォレンジックモデル及びフォレンジック情報のうちの少なくとも１つを用いて決定する。いくつかの実施形態では、グローバルマネージャモジュールは、過剰エラーの理由が、不十分なトレーニングモデルであると決定し、少なくとも１つのトレーニングモデルの再トレーニングを生じさせることができ、これは、監視されたフォレンジック情報のエンコーディング時にフォレンジック情報の最大値を保つと共にエンコードされたフォレンジック情報のデコーディング時に再構成エラーの最小値を有するエンコーダ／デコーダ対を含み得る。

【0022】

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

【図面の簡単な説明】

【0023】

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

【0024】

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

【0025】

【図2A】図２Ａは本原理の一実施形態によるアプリケーションコンテナモデルトレーニングサービスを提供する図１のコンテナフォレンジックシステム１００等の本原理のコンテナフォレンジックシステムの一実施形態の機能ブロック図を示す。

【0026】

【図2B】図２Ｂは本原理の一実施形態による図１の自動エンコーダ１１０等の本原理の自動エンコーダの動作の機能ブロック図を示す。

【0027】

【図3】図３は本原理の一実施形態によるアプリケーションコンテナへのサービスとして提供されている本原理のコンテナフォレンジックシステムの高レベルの機能図を示す。

【0028】

【図4】図４は本原理の一実施形態により１つ以上のアプリケーションコンテナに対してグローバルエンコーダ／デコーダ対を決定するための方法のフローチャートを示す。

【0029】

【図5】図５は本原理の一実施形態によるコンテナネットワークの複数のアプリケーションコンテナに対してプロセスレベルのフォレンジックを提供するための方法のフローチャートを示す。

【0030】

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

【0031】

【図7】図７は図１のコンテナフォレンジックシステム等の本原理によるコンテナフォレンジックシステムの実施形態が適用され得るネットワークの高レベルのブロック図を示す。

【0032】

【図8A】図８Ａは本原理の一実施形態による３つの異なるシステムコール負荷についての本原理のコンテナフォレンジックシステムとの対比におけるナイーブ(naive)フォレンジック監視システムのためのフォレンジック情報を記憶するためのホスト／ＣＰＵへのシステムコストのグラフ表示を示す。

【0033】

【図8B】図８Ｂは本原理の一実施形態による３つの異なるシステムコール負荷についての本原理のコンテナフォレンジックシステムとの対比におけるナイーブフォレンジック監視システム用ストレージのためにフォレンジック情報を伝送するためのホスト／ＣＰＵへのシステムコストのグラフ表示を示す。

【0034】

【図8C】図８Ｃは本原理の一実施形態による３つの異なるシステムコール負荷についての本原理のコンテナフォレンジックシステムとの対比におけるナイーブフォレンジックアプリケーションのためにフォレンジック情報を記憶するためのデータストレージ消費コストのグラフ表示を示す。

【0035】

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

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

【0036】

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

【0037】

本原理の実施形態は、コンテナネットワークに対する動作安定性のコンテナごとのモデルが決定される深層学習方法を備える。いくつかの実施形態では、コンテナフォレンジックがキャッシュされ、一定の間隔で評価されて、アプリケーションが既知の安定な方法で動作しているかどうかを決定し、例えば、コンテナ健全性を決定する。本原理の実施形態によれば、少なくとも１つのアプリケーションコンテナの安定な動作は、ここでは、少なくとも１つ以上のアプリケーションコンテナの所望の動作又は結果として定義され得る。本原理の実施形態によれば、コンテナ健全性は、ここでは、コンテナの動作状態、例えば、コンテナのサービスがどのように実行されているか及び／又はコンテナがマルウェアを含む疑いがあるか否かとして定義され得る。また、いくつかの実施形態では、「コンテナ健全性」という語句は、コンテナのサービスの準備状況を含み得る。

【0038】

いくつかの実施形態では、安定及び不安定な状態を報告する能力を維持しつつ、地上システムに送信されているフォレンジックデータの量を減らすために、連合ロギングアプローチ(federated logging approach)が本原理のコンテナフォレンジックシステムによって利用され得る。いくつかの実施形態では、グローバル分析が地上で行われ得るように全てのコンテナにそのフォレンジックをプッシュさせる代わりに、各コンテナは、それがどのようにふるまっているかのモデルを構築し、それが正常なパターンでふるまっているかどうかを決定し、次いで、フォレンジックデータをグローバルマネージャに伝達する代わりに、モデルのみがグローバルマネージャによってプッシュ又はプルされ得る。従って、ローカルチェックはコンテナレベルで行われ、何が送信されたのか（モデル、フォレンジック、又はその両方）に関する決定はコンテナレベルでなされ得る。

【0039】

いくつかの実施形態では、管理レイヤーは、多数のコンテナからのデータを活用して、コンテナが安定なときにモデルがどのように見えるのかを決定することができる。管理レイヤーは、次いで、安定なモデルの外に何かがある場合を検出し、コンテナが行うことの多くの態様を記録及び分析して更なる分析に供することができる。管理レイヤーは、アプリケーションコンテナが不安定な方法で動作していられる理由を決定し修正しようとするために、是正処置がとられるようにし得る。例えば、いくつかの実施形態では、管理レイヤーは、モデル若しくは決定されたエンコーダ／デコーダ対の再トレーニング又はアプリケーションコンテナの修復を生じさせることができる（以下でより詳細に説明される）。

【0040】

いくつかの実施形態では、任意の所与のコンテナからのモデル又はフォレンジック情報の送信に関する決定は、コンテナレベル、管理レベル、又はその両方（プッシュ又はプル）でなされ得る。例えば、グローバルな視点から、同じアプリケーションを実行しているいくつかのコンテナが標準外でふるまっている場合、ローカルレイヤーからは、その時点では何もパブリッシュする必要はない（例えば、以前すでに５回パブリッシュされており、何も変わっていない場合）。代わりに、単にモデルをパブリッシュするために、管理レイヤーによって決定がなされ得る。従って、管理レベルは、情報自体の評価に基づいて、コンテナレベルからの情報をプッシュし、あるいは例えばコンテナ又はストレージデバイスから情報をプルすることができる。いくつかの実施形態では、モデル及びフォレンジック情報のパブリケーションは、コンテナセキュリティシステムを利用するシステムのタイプに特有のポリシーに従って行うこともできる。いくつかの実施形態では、認証イベント、トリガーされたイベント、及びコンテナのユーザに関する情報も、モデルとともにパブリッシュされ得る。

【0041】

図１は、本原理の一実施形態によるコンテナネットワーク（図示せず）のアプリケーションコンテナにおいて適用され得るコンテナフォレンジックシステム（ＣＦＳ）１００の高レベルのブロック図を示す。図１のコンテナフォレンジックシステム（ＣＦＳ）１００は、複数のアプリケーションコンテナ１５０_１～１５０_Ｎ（アプリケーションコンテナ１５０と総称する）のうちの少なくとも１つに適用され得る。図１の実施形態では、アプリケーションコンテナ１５０の各々は、例示的に、随意的な要約モジュール１０５、自動エンコーダモジュール１１０、及びパブリッシャー／エラーエバリュエーターモジュール１２０を備える。図１のコンテナフォレンジックシステム１００は、更に、例示的に、グローバルマネージャモジュール１３０及びストレージデバイス１４０を含み、これらは、図１の実施形態では、アプリケーションコンテナ１５０の外側に例示的に示されている。図１に更に示すように、図１のコンテナフォレンジックシステム１００等の本原理のコンテナフォレンジックシステムの実施形態は、本原理に従ってコンピューティングデバイス６００を介して実装され得る（以下でより詳細に説明される）。図１のコンテナフォレンジック１００の実施形態では、パブリッシャー／エラーエバリュエーターモジュール１２０は単一のコンポーネントとして示されているが、本原理のパブリッシャー／エラーエバリュエーターモジュールは、複数の別個のコンポーネントを備えることができる。

【0042】

図１のコンテナフォレンジックシステム１００の実施形態では、アプリケーションコンテナ１５０は、随意的な要約モジュール１０５、自動エンコーダモジュール１１０、及びパブリッシャー／エラーエバリュエーターモジュール１２０を備えているものとして示されているが、代替的又は追加的に、いくつかの実施形態では、随意的な要約モジュール１０５、自動エンコーダモジュール１１０、及びパブリッシャー／エラーエバリュエーターモジュール１２０を含む本原理のコンテナフォレンジックシステムは、各アプリケーションコンテナ１５０の外部に設けられたそれぞれのサービス／モジュールを備えることができ、図１に示すように各アプリケーションコンテナ１５０内に存在する必要はない。即ち、本原理のコンテナフォレンジックシステムのいくつかの実施形態では、少なくとも随意的な要約モジュール１０５、自動エンコーダモジュール１１０、及びパブリッシャー／エラーエバリュエーターモジュール１２０は、各アプリケーションコンテナ１５０の外部に設けられたサービス／モジュールであることができ、各アプリケーションコンテナ１５０内に存在する必要はない。いくつかの実施形態では、随意的な要約モジュール１０５、自動エンコーダモジュール１１０、パブリッシャー／エラーエバリュエーターモジュール１２０、グローバルマネージャモジュール１３０、及びストレージデバイス１４０を含む図１のコンテナフォレンジックシステム１００等の本原理のコンテナフォレンジックシステムは、サービスとしてアプリケーションコンテナに提供され得る（以下で更に詳細に説明される）。

【0043】

本原理の少なくともいくつかの実施形態によれば、アプリケーションコンテナフォレンジック情報／データは、いくつかの実施形態では、少なくともコンテナレベルで一定の間隔（例えば、タイムクォンタム(time quantum)）で監視／収集されて、アプリケーションコンテナに対して安定な挙動のモデルを決定し、決定されたモデルを用いて、アプリケーションコンテナが既知の安定な方法で動作しているかどうかを決定することができる。本原理の実施形態によれば、フォレンジック情報／データは、限定はされないが、反復可能なアプリケーションコンテナであって、標準化され得ると共に動作機能／特性の後続の反復と比較され得るアプリケーションコンテナの実質的に任意の動作機能／特性を含むことができる。例えば、いくつかの実施形態では、フォレンジック情報は、システムコール(syscalls)情報、コンテナリソース利用情報、プロセスアクティビティ情報、ファイルアクセス情報、ネットワークアクティビティ情報、ユーザアイデンティティ管理、直接アクセスイベント、ファイル属性イベント、システム構成イベント、入出力制御（ＩＯＣＴＬ）使用法等のうちの少なくとも１つを含み得る。更に、フォレンジック情報は、ＶＡＲログ及びＡｐａｃｈｅ２．ログ等のアプリケーション特有のログプロダクションを含み得る。そのような実施形態では、Ａｐａｃｈｅが安定な方法で動作しているかどうかを決定するために、例えばエラーログでの挙動のパターンが監視され得る。また、いくつかの実施形態では、ファイアウォールルールポリシー違反等が、フォレンジック情報としてベクトル化され実装され得る。

【0044】

図２Ａは、本原理の一実施形態による同様の機能を有する又は同様の種類のアプリケーションコンテナのためのアプリケーションコンテナモデルトレーニングサービスを提供する図１のコンテナフォレンジックシステム１００等の本原理のコンテナフォレンジックシステムの一実施形態の機能ブロック図を示す。図２Ａに示すように、複数のアプリケーションコンテナのフォレンジック情報が閾値内で類似するような同様の機能を有する又は同様の種類の複数のアプリケーションコンテナに対して、それぞれの随意的な要約モジュール１０５は、安定な方法で動作していることが分かっている少なくとも１つの関連するアプリケーションコンテナ１５０のフォレンジック情報２０５を監視することができる。本原理の実施形態によれば、少なくとも１つのアプリケーションコンテナの安定な動作は、ここでは、少なくとも１つ以上のアプリケーションコンテナの所望の動作又は結果として定義され得る。

【0045】

図２Ａの実施形態では、少なくとも１つの安定な動作中アプリケーションコンテナからのフォレンジック情報２０５は、随意的な要約モジュール１０５によって分類され得る。いくつかの実施形態では、要約モジュール１０５は、分類されたフォレンジック情報を、いくつかの実施形態ではタイムクォンタムによってベクトル化することもできる。本原理のいくつかの実施形態では、フォレンジック情報は、実質的に任意のフォレンジック特性を介して分類及びベクトル化され得る。例えば、いくつかの実施形態では、随意的な要約モジュール１０５は、フォレンジック情報をタイプによりカテゴリ別に区分することができ、各タイプのフォレンジック情報は、カテゴリごとにカウントされ得る。代替的又は追加的に、いくつかの実施形態では、それぞれ単一シーケンスのフォレンジック情報を調べる代わりに、ｎグラムシーケンスのフォレンジック情報（即ち、システムコール）が生成されて、ｎグラムシーケンスをカウントすることによってフォレンジック情報を分類及びベクトル化することができる。代替的又は追加的に、いくつかの実施形態では、例えばそれぞれのアプリケーションコンテナの動作特徴のエラー又は成功等のフォレンジック情報のメタデータがカウントされて、フォレンジック情報を分類及びベクトル化することができる。代替的又は追加的に、例えばシステムコール中にアクセスされたファイル及びディレクトリの例えば数の引数が組み込まれて、それぞれのアプリケーションコンテナのフォレンジック情報を分類及びベクトル化することができる。本原理の実施形態によれば、それぞれのアプリケーションコンテナのフォレンジック情報の監視／収集は、タイムクォンタムごとに行われ得る。このようなタイムクォンタムは、実験的に及び反復を介して決定されて、本原理のコンテナフォレンジックシステムに最良の性能をもたらすタイムクォンタムを決定することができる。例えば、いくつかの実施形態では、本原理のタイムクォンタムは、アプリケーションフォレンジックイベントの量及びキャッシュ／ストレージサイズに応じて調整を受けてよい構成可能パラメータである観測間隔として定義される。いくつかの実施形態では、アプリケーションがよりアクティブであるほど、タイムクォンタムが増大させられるのに従って、タイムクォンタムが課し得るストレージ及び要約のコストが大きくなる。タイムクォンタムはまた、不安定性を報告する際に本原理のコンテナフォレンジックシステムの応答性に影響を与え得る。本原理のいくつかの実施形態では、タイムクォンタム長は１分以下に限定されてきた。

【0046】

上記説明は、フォレンジック情報がどのように分類及び／又はベクトル化され得るのかのいくつかの例を提供するが、上記説明及び例は、限定的であると見なされるべきではない。フォレンジック情報は、フォレンジック情報を分類及び／又はベクトル化するための任意の既知の又は未発見の方法及び／又はプロセスによって分類及び／又はベクトル化することができ、これらは本原理の実施形態において実装され得る。更には、図２Ａの実施形態では、安定な方法で動作していることが分かっているアプリケーションコンテナ１５０からのフォレンジック情報が要約モジュール１０５によって分類及びベクトル化されるが、いくつかの代替的実施形態では、フォレンジック情報は、本原理の随意的な要約モジュール１０５によって要約されることなく、自動エンコーダモジュール１１０によって受信され得る。

【0047】

図２Ａの実施形態では、自動エンコーダモジュール１１０は、例えば随意的な要約モジュール１０５からの安定な方法で動作しているアプリケーションコンテナのフォレンジック情報を用いてエンコーダ２６２／デコーダ２６２対を決定して、アプリケーションコンテナが本原理に従って安定な方法で動作しているかどうかの決定において用いられ得るそれぞれのフォレンジックモデルを決定する。即ち、図２Ａの実施形態では、自動エンコーディングプロセスは、自動エンコーダモジュール１１０によって、安定な方法で動作しているアプリケーションコンテナのフォレンジック情報に適用される。図２Ａの実施形態の自動エンコーダモジュール１１０は、エンコーディング時にフォレンジック情報の最大値を保つと共にデコーディング時に再構成エラーの最小値を有するエンコーダ２６２／デコーダ２６４対を決定する。決定されたエンコーダ２６２／デコーダ２６４対は、例えばいくつかの実施形態では、図１のパブリッシャー／エラーエバリュエーターモジュール１２０等の本原理のパブリッシャー／エラーエバリュエーターモジュールによって、アプリケーションコンテナの動作の安定性を検出するために用いられるように同様の種類及び／又は機能の少なくとも全てのアプリケーションコンテナに伝達され得る（以下でより詳細に説明される）。図２Ａの上記プロセスは、それぞれ同様の種類及び／又は機能の全ての異なるタイプのアプリケーションコンテナに対してエンコーダ／デコーダ対を決定するために適用され得る。

【0048】

エンコーダ２６２／デコーダ２６４対を決定する際に、自動エンコーダモジュール１１０は、フォレンジック情報が受信された安定に動作しているアプリケーションコンテナに対して、フォレンジックトレーニングモデルＭ_Ｔを決定することができる。即ち、本原理によれば、自動エンコーディングプロセスは、安定に動作しているアプリケーションコンテナのフォレンジック情報を表すフォレンジックトレーニングモデルＭ_Ｔを決定するために実装され得る。いくつかの実施形態では、トレーニングモデルＭ_Ｔは、図２Ｂにおいてより詳細に説明されるように、エンコーダ２６２によって潜在コードとして決定される。フォレンジックトレーニングモデルＭ_Ｔは、本原理のグローバルマネージャモジュール等の上位レベルのマネージャに伝達されて、例えばコンテナネットワークのアプリケーションコンテナの高レベルの管理に用いられ得る。上述のようなトレーニング手順は、安定な方法で動作していることが分かっていない他のアプリケーションコンテナに適用されて、アプリケーションコンテナの各々に対してそれぞれのフォレンジック動作モデルを決定することができ、それぞれのフォレンジック動作モデルは、いくつかの実施形態ではグローバルマネージャモジュールによって、フォレンジックトレーニングモデルＭ_Ｔと比較され得る（以下でより詳細に説明される）。

【0049】

例えば、図２Ｂは、図１の自動エンコーダ１１０（例えば、図２Ａのエンコーダ２６２／デコーダ２６４対）等の本原理の自動エンコーダの動作の機能ブロック図を示す。いくつかの実施形態では、自動エンコーダは、少なくとも処理されるべきフォレンジック情報に頼ることができ、いくつかの実施形態では、バニラ自動エンコーダ、変分自動エンコーダ、及び時系列異常検出のための変分自動エンコーダのうちの少なくとも１つを含むことができる。図２Ｂに示すように、自動エンコーダ１１０への入力は、対象アプリケーションコンテナの安定な動作状態を表すフォレンジック情報からなり得る。いくつかの実施形態では、エンコーダ２６２は、畳み込みニューラルネットワーク(convolutional neural network)（ＣＮＮ）又は長短期記憶(long short-term memory)（ＬＳＴＭ）等のニューラルネットワークを実装して、受信した代表的なデータ（例えば、フォレンジック情報）をデータ２５５の表現、いくつかの実施形態ではデータの圧縮表現に変換することができる。エンコーダ２６２とデコーダ２６４の間の潜在空間において、データ２５５の表現は、潜在コード２６０へと更に処理され、これは、安定に動作しているアプリケーションコンテナ（図示せず）の安定な動作特徴（即ち、フォレンジック情報）のデータ表現の最も効率的な表現である。自動エンコーダへの入力が、安定な方法で動作していることが分かっているアプリケーションコンテナのフォレンジックを含む実施形態においては、潜在コードは、上述したトレーニングモデルＭ_Ｔとして定義される。次いで、潜在コード２６０は、デコーダ２６４によって処理されて（即ち、ニューラルネットワークを用いて処理されて）、入力データの再構成された表現２６５を決定することができる。決定されたトレーニングモデルＭ_Ｔは、例えばいくつかの実施形態では、図１のパブリッシャー／エラーエバリュエーターモジュール１２０等の本原理のパブリッシャー／エラーエバリュエーターモジュールによって、例えばコンテナネットワークの少なくとも１つのアプリケーションコンテナの上位レベルの管理を行うための本原理のグローバルマネージャモジュール１３０等のグローバルマネージャに伝達され得る。本原理のいくつかの実施形態では、決定されたトレーニングモデルＭ_Ｔは、例えばいくつかの実施形態では図１のパブリッシャー／エラーエバリュエーターモジュール１２０等の本原理のパブリッシャー／エラーエバリュエーターモジュールによって、例えば他のアプリケーションコンテナの他のフォレンジックモデルとの比較における使用のためにコンテナネットワークの全てのアプリケーションコンテナに伝達されて、他のアプリケーションコンテナの少なくとも１つの動作が安定な方法で動作しているかどうかを決定する（以下でより詳細に説明される）。

【0050】

図３は、本原理の実施形態によるアプリケーションコンテナ３５０へのサービスとして提供されている本原理のコンテナフォレンジックシステム３００の高レベルの機能図を示す。図３のコンテナフォレンジックシステム３００は、例示的に、図３の実施形態では以前に決定されたエンコーダ２６２／デコーダ２６４対として表される自動エンコーダモジュール３１０と、パブリッシャー／エラーエバリュエーターモジュール３２０と、を備える。図３のコンテナフォレンジックシステム３００は、本原理の随意的な要約モジュールがなくても本原理の実施形態が実装され得ることを説明するために、本原理の要約モジュールなしで示されている。そのような実施形態では、フォレンジック情報は、要約されることなく本原理の自動エンコーダモジュールによって受信され得るし、あるいは別個のサービスによって要約され得る。

【0051】

図３のコンテナフォレンジックシステム３００においては、アプリケーションコンテナ３５０等のアプリケーションコンテナのトレーニング後又は通常の動作中に、アプリケーションコンテナ３５０の動作を表すフォレンジック情報３０２は、例えば図２Ａに示されるようなトレーニングプロセス中に決定されたエンコーダ２６２／デコーダ２６４対のエンコーダ２６２によってエンコードされる。エンコーダ２６２は、フォレンジック情報を、アプリケーションコンテナ３５０の動作特性のフォレンジック情報を表す潜在コード３６０へと処理する。本原理によるいくつかの実施形態では、決定された潜在コード３６０は、図３のアプリケーションコンテナ３５０の動作特性を表すそれぞれの動作モデルＭ_Ｏとして定義され得る。エンコーダ２６２によって決定された動作モデルＭ_Ｏは、例えばパブリッシャー／エラーエバリュエーターモジュール３２０によって、本原理に従って上位レベルの管理機能を実行するためのグローバル管理モジュール３３０に伝達され得る（以下でより詳細に説明される）。

【0052】

図３のコンテナフォレンジックシステム３００において、デコーダ２６４は、潜在コード３６０を処理して、入力フォレンジック情報の再構成された表現３６５を決定する。図３の実施形態では、パブリッシャー／エラーエバリュエーターモジュール３２０は、入力フォレンジック情報の再構成された表現３６５を入力フォレンジック情報と比較して、閾値ｒを超えるエラーｅが存在するかどうかを決定する。即ち、エンコーダ２６２／デコーダ２６４対は、安定に動作しているアプリケーションコンテナのフォレンジック情報を用いて決定されたので、対象アプリケーションコンテナのフォレンジック情報が、閾値内で、安定に動作しているアプリケーションコンテナのフォレンジック情報と一致し／十分に近い場合、エンコーダ２６２がアプリケーションコンテナ３５０のフォレンジック情報をエンコードし、デコーダ２６４がアプリケーションコンテナ３５０のフォレンジック情報をデコードすると、パブリッシャー／エラーエバリュエーターモジュール３２０は、閾値ｒを超えるエラーｅが入力フォレンジック情報の再構成された表現３６５と入力フォレンジック情報との間に存在していないと決定することになる。次いで、それぞれのアプリケーションコンテナ３５０は、安定な方法で動作していると見なされ得る。一方、対象アプリケーションコンテナのフォレンジック情報が、閾値内で、安定に動作しているアプリケーションコンテナのフォレンジック情報と一致しておらず／十分に近くない場合、エンコーダ２６２がアプリケーションコンテナ３５０のフォレンジック情報をエンコードし、デコーダ２６４がアプリケーションコンテナ３５０のフォレンジック情報をデコードすると、パブリッシャー／エラーエバリュエーターモジュール３２０は、閾値ｒを超えるエラーｅが入力フォレンジック情報の再構成された表現３６５と入力フォレンジック情報との間に存在していると決定することになる。次いで、それぞれのアプリケーションコンテナ３５０は、安定な方法で動作していないと見なされ得る。

【0053】

本原理の閾値ｒはいくつかの要因に依存している可能性があり、これらの要因は、限定はされないが、フォレンジック情報がアプリケーションコンテナから監視／収集されるタイムクォンタム、アプリケーションコンテナのタイプ及び機能、アプリケーションコンテナの数、それぞれのアプリケーションコンテナによって実行されるプロセスの数、評価されているフォレンジック情報の数及びタイプ等を含む。いくつかの実施形態では、本原理の閾値ｒは、少なくとも先験的且つ実験的に決定され得る。例えば、１つの実施形態では、再構成エラーは、最後のトレーニング反復で複数の反復／サンプルについて監視することができ、平均及び標準偏差は、それら全てのエラーに対して計算することができる。次いで、閾値が（計算された平均＋＜一定の定数）×計算された標準偏差）として設定され得る。代替的又は追加的に、いくつかの実施形態では、エンコーダ／デコーダ対をトレーニングデータでトレーニングすることができ、次いで、いくつかの制限された数の新たなサンプルに対して、新たな（クリーンな）データで評価を行うことができる。サンプルが新しい（且つエンコーダ／デコーダ対が確率的である）ので、再構成エラーはより高くなる。次いで、観測された再構成エラーの平均として閾値が設定され得る。

【0054】

例えばパブリッシャー／エラーエバリュエーターモジュール３２０によって閾値ｒを超えるエラーが存在しないと決定されるインスタンスにおいては、パブリッシャー／エラーエバリュエーターモジュール３２０は、それぞれのアプリケーションコンテナ３５０の動作特性を表す決定された動作モデルＭ_Ｏを、アプリケーションコンテナの上位レベルの管理における使用のためにグローバルマネージャモジュール３３０に伝達することができる（以下でより詳細に説明される）。例えばパブリッシャー／エラーエバリュエーターモジュール３２０によって閾値ｒを超えるエラーｅが存在すると決定されるインスタンスにおいては、パブリッシャー／エラーエバリュエーターモジュール３２０は、それぞれのアプリケーションコンテナ３５０の動作特性を表す決定された動作モデルＭ_Ｏ、及びアプリケーションコンテナ３５０の生のフォレンジック情報を、アプリケーションコンテナの上位レベルの管理における使用のためにグローバルマネージャモジュール３３０に伝達することができる（以下でより詳細に説明される）。いくつかの実施形態では、パブリッシャー／エラーエバリュエーターモジュール３２０は、それぞれのアプリケーションコンテナ３５０の動作特性を表す決定された動作モデルＭ_Ｏ、及びアプリケーションコンテナ３５０の生のフォレンジック情報を、可能性のある後での使用のためにストレージデバイス３４０に伝達することができる。例えば、いくつかの実施形態では、グローバル管理モジュール１３０は、アプリケーションコンテナ及びコンテナネットワークの上位レベルの管理での使用のために、ストレージデバイス３４０から生のフォレンジック情報を要求することができる。

【0055】

代替的又は追加的に、本原理のいくつかの実施形態では、アプリケーションコンテナ３５０のフォレンジック情報から決定された潜在コード３６０であって、動作モデルＭ_Ｏとして定義された潜在コード３６０は、例えばパブリッシャー／エラーエバリュエーターモジュール３２０によって、既知の安定に動作しているアプリケーションコンテナのフォレンジック情報から以前に決定されたトレーニングモデルＭ_Ｔと比較されて、アプリケーションコンテナ３５０が安定な方法で動作しているか否かを決定することができる。例えば、そのような実施形態では、潜在コード動作モデルＭ_Ｏは、以前に決定された潜在コードトレーニングモデルＭ_Ｔと比較されて、動作モデルＭ_ＯとトレーニングモデルＭ_Ｔの間のエラーｅが閾値ｒを超えているかどうかを決定することができる。いくつかの実施形態では、動作モデルＭ_Ｏ及びトレーニングモデルＭ_Ｔは、余弦類似度等の類似度メトリック等を用いて比較され得る。典型的には、潜在的コードトレーニングモデルＭ_Ｔからの任意の偏差は、大きな再構成エラーを誘発する。

【0056】

そのような実施形態では、例えばパブリッシャー／エラーエバリュエーターモジュール３２０によって、閾値ｒを超えるエラーｅがそれぞれのアプリケーションコンテナ３５０の動作モデルＭ_Ｏと安定に動作しているアプリケーションコンテナの以前に決定された潜在コードトレーニングモデルＭ_Ｔとの間に存在していないと決定された場合、それぞれのアプリケーションコンテナ３５０は、安定な方法で動作していると見なすことができ、それぞれのアプリケーションコンテナ３５０の動作特性を表す決定された動作モデルＭ_Ｏは、アプリケーションコンテナの上位レベルの管理での使用のためにグローバルマネージャモジュール３３０に伝達され得る（以下でより詳細に説明される）。一方、例えばパブリッシャー／エラーエバリュエーターモジュール３２０によって、閾値ｒを超えるエラーｅがそれぞれのアプリケーションコンテナ３５０の動作モデルＭ_Ｏと安定に動作しているアプリケーションコンテナの以前に決定された潜在コードトレーニングモデルＭ_Ｔとの間に存在していると決定された場合、それぞれのアプリケーションコンテナ３５０は、安定な方法で動作していないと見なすことができ、それぞれのアプリケーションコンテナ３５０の動作特性を表す決定された動作モデルＭ_Ｏは、アプリケーションコンテナ３５０の生の監視／収集されたフォレンジック情報と共に、アプリケーションコンテナの上位レベルの管理での使用のためにグローバルマネージャモジュール３３０に伝達され得る（以下でより詳細に説明される）。

【0057】

図１のグローバルマネージャモジュール１３０及び図３のグローバルマネージャモジュール３３０等の本原理のグローバルマネージャモジュールは、例えばコンテナネットワークの複数のアプリケーションコンテナの各々から情報を受信することが可能である。例えば、図２Ａのトレーニング実施形態を参照すると、本原理のグローバルモジュールは、安定な方法で動作していることが分かっているアプリケーションコンテナに対して決定された少なくともトレーニングモデルＭ_Ｔを受信することが可能である。図３の実施形態を参照すると、本原理のグローバルモジュールは、それぞれのアプリケーションコンテナのフォレンジック情報及びそれぞれのアプリケーションコンテナのそれぞれの動作モデルＭ_Ｏを受信することが可能である。グローバルマネージャモジュールは、受信した情報を用いて、例えばコンテナネットワークの複数のアプリケーションコンテナの上位レベルの管理を行うことができる。

【0058】

例えば、いくつかの実施形態では、本原理のグローバルマネージャモジュールは、少なくともアプリケーションコンテナの動作モデルＭ_Ｏと安定な方法で動作していることが分かっているアプリケーションコンテナに対して決定されたトレーニングモデルＭ_Ｔとから、コンテナネットワーク及びアプリケーションコンテナの安定動作のグローバルモデルを決定することができる。いくつかの実施形態では、本原理のグローバルマネージャモジュールは、アプリケーションコンテナの動作モデルＭ_Ｏを少なくとも１つのピアアプリケーションコンテナの受信動作モデルＭ_Ｏと比較することによって、アプリケーションコンテナの動作にエラーｅが存在するかどうかを決定することができる。そのような実施形態では、グローバルマネージャモジュールは、モデル間のエラーｅを所定の閾値ｒと比較して、それぞれのアプリケーションコンテナが許容範囲外で動作しているかどうかを決定することができる。いくつかの実施形態では、所定の閾値ｒは、図３を参照して上述したのと同じ閾値ｒとすることができ、あるいは代替的には、グローバルマネージャモジュール１３０は、エラーｅを異なる所定の閾値ｒと比較することができる。例えば、いくつかの実施形態では、グローバルマネージャモジュールは、コンテナネットワークのアプリケーションコンテナのグローバルビューに基づいて、エラーｅを所定の閾値ｒと比較することができる。エラーｅが閾値ｒを超えている場合には、グローバルマネージャモジュールは、管理レベルでフォレンジックを実行することができる。例えば、そのような実施形態では、グローバルマネージャは、閾値を超えるエラーを呈するアプリケーションコンテナの動作がドリフトしたかどうかを決定することができる。そのような実施形態では、グローバルモジュールは、少なくともそれぞれのアプリケーションコンテナからフォレンジック情報を要求することができる。少なくともそれぞれのアプリケーションコンテナからのフォレンジック情報を有することで、及びいくつかの実施形態ではいくつかのピアアプリケーションコンテナからのフォレンジック情報を有することで、グローバル管理モジュールは、非監督ｋ平均クラスタ分析、ペアワイズ余弦類似度分析、又は他の類似度メトリックのうちの少なくとも１つに従ってコンテナドリフトを決定することができる。本原理のグローバルマネージャは、ピアソンの相関(Pearson’s correlation)、余弦類似度、ジャッカード類似度(Jaccard similarity)、ユークリッド距離及びマンハッタン距離のような距離メトリック等の他の分析メトリック等を実行して、グローバルマネージャモデルに伝達されたフォレンジック情報及びモデルを用いることによって、アプリケーションコンテナが非標準的な方法で動作しているかどうかを決定することができる。

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

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

【0086】

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

【0087】

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

【0088】

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

【0089】

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

【0090】

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

【0091】

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

【0092】

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

【0093】

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

【0094】

本原理のコンテナフォレンジックシステムの実施形態は、少なくとも、本原理のコンテナフォレンジックシステムにおいては、アプリケーションコンテナの安定な動作の決定された期間中は、決定されたそれぞれのフォレンジックモデルのみが上位レベルのマネージャに伝達され、不安定な動作の期間中にのみ、それぞれのアプリケーションコンテナのフォレンジック情報が上位レベルのマネージャに伝達されるので、フォレンジック情報を収集し、収集された全てのフォレンジック情報をマネージャに伝達する典型的なナイーブフォレンジック監視システムに対して、多くの利点を提供する。例えば、図８Ａ、図８Ｂ、及び図８Ｃは、本原理のコンテナフォレンジックシステム（ＣＦＳ）の実施形態のいくつかの利点を示す。

【0095】

図８Ａは、３つの異なるシステムコール負荷についての図１のコンテナフォレンジックシステム１００等の本原理のコンテナフォレンジックシステム（ＣＦＳ）との対比におけるナイーブフォレンジック監視システムのためのフォレンジック情報を記憶するホスト／ＣＰＵへのシステムコストのグラフ表示を示す。図８Ａでは、１時間あたりのＣＰＵサイクルでタイムクォンタムあたり４００、８００、及び１２００のシステムコール負荷に対して３０秒のタイムクォンタムを有するアプリケーションコンテナのフォレンジック情報を記憶するためのＣＰＵコストが監視される。図８Ａに示すように、３０秒のタイムクォンタムあたり４００システムコールのシステムコール負荷に対して、アプリケーションコンテナのフォレンジック情報を記憶するためのホスト／ＣＰＵへのナイーブフォレンジック監視システムのコストは、１１４．５ビリオン（Ｂ）サイクルであり、これに対して、フォレンジック情報を記憶するためのホスト／ＣＰＵへの本原理のコンテナフォレンジックシステムのコストは、４０．５Ｂである。図８Ａに示すように、３０秒のタイムクォンタムあたり８００システムコールのシステムコール負荷に対して、アプリケーションコンテナのフォレンジック情報を記憶するためのホスト／ＣＰＵへのナイーブフォレンジック監視システムのコストは、１８４Ｂであり、これに対して、フォレンジック情報を記憶するためのホスト／ＣＰＵへの本原理のコンテナフォレンジックシステムのコストは、５９Ｂである。図８Ａに更に示すように、３０秒のタイムクォンタムあたり１２００システムコールのシステムコール負荷に対して、アプリケーションコンテナのフォレンジック情報を記憶するためのホスト／ＣＰＵへのナイーブフォレンジック監視システムのコストは、２３５Ｂであり、これに対して、フォレンジック情報を記憶するためのホスト／ＣＰＵへの本原理のコンテナフォレンジックシステムのコストは、７３Ｂである。図８Ａに示すように、アプリケーションコンテナのフォレンジック情報を記憶することに関連するＣＰＵコストは、本原理のコンテナフォレンジックシステムに対しては、全てのシステムコール負荷にわたりナイーブフォレンジック監視システムと比較してはるかに少ない。また、本原理のコンテナフォレンジックシステムは、アプリケーションコンテナがいつ安定に動作しているのかを決定し得るという追加の利点を有する。ナイーブフォレンジック監視システムには、そのような機能はない。

【0096】

図８Ｂは、３つの異なるシステムコール負荷についての図１のコンテナフォレンジックシステム１００等の本原理のコンテナフォレンジックシステムとの対比におけるナイーブフォレンジック監視システム用ストレージのためにフォレンジック情報を伝送するホスト／ＣＰＵへのシステムコストのグラフ表示を示す。図８Ｂでは、４００、８００、及び１２００のシステムコール負荷に対して３０秒のタイムクォンタムでのフォレンジック情報（Ｆ又はＭ）の送信のための毎秒バイト伝送速度が監視される。図８Ｂに示すように、３０秒のタイムクォンタムあたり４００システムコールのシステムコール負荷に対して、ストレージのためにアプリケーションコンテナのフォレンジック情報を伝送するためのホスト／ＣＰＵへのナイーブフォレンジック監視システムのコストは、７６Ｋｂｐｓであり、これに対して、ストレージのためにアプリケーションコンテナのフォレンジック情報を伝送するためのホスト／ＣＰＵへの本原理のコンテナフォレンジックシステムのコストは、６０Ｂｐｓである。図８Ｂに示すように、３０秒のタイムクォンタムあたり８００システムコールのシステムコール負荷に対して、ストレージのためにアプリケーションコンテナのフォレンジック情報を伝送するためのホスト／ＣＰＵへのナイーブフォレンジック監視システムのコストは、１５３Ｋｂｐｓであり、これに対して、ストレージのためにフォレンジック情報を伝送するためのホスト／ＣＰＵへの本原理のコンテナフォレンジックシステムのコストは、６１Ｂｐｓである。図８Ｂに更に示すように、３０秒のタイムクォンタムあたり１２００システムコールのシステムコール負荷に対して、ストレージのためにアプリケーションコンテナのフォレンジック情報を伝送するためのホスト／ＣＰＵへのナイーブフォレンジック監視システムのコストは、２２７Ｋｂｐｓであり、これに対して、ストレージのためにフォレンジック情報を伝送するためのホスト／ＣＰＵへの本原理のコンテナフォレンジックシステムのコストは、６１Ｂｐｓである。図８Ｂに示すように、ストレージのためにアプリケーションコンテナのフォレンジック情報を伝送することに関連するＣＰＵコストは、本原理のコンテナフォレンジックシステムに対しては、全てのシステムコール負荷にわたりナイーブフォレンジック監視システムと比較してはるかに少ない。

【0097】

図８Ｃは、３つの異なるシステムコール負荷についての図１のコンテナフォレンジックシステム１００等の本原理のコンテナフォレンジックシステムとの対比におけるナイーブフォレンジックアプリケーションのためにフォレンジック情報を記憶するためのデータストレージ消費コストのグラフ表示を示す。図８Ｃでは、１時間あたりのデータストレージ消費でタイムクォンタムあたり４００、８００、及び１２００のシステムコール負荷に対して３０秒のタイムクォンタムを有するアプリケーションコンテナのフォレンジック情報を記憶するためのデータストレージ消費コストが監視される。図８Ｃに示すように、３０秒のタイムクォンタムあたり４００システムコールのシステムコール負荷に対して、アプリケーションコンテナのフォレンジック情報を記憶するためのナイーブフォレンジック監視システムのデータ消費コストは、９６ＭＢｓであり、これに対して、フォレンジック情報を記憶するための本原理のコンテナフォレンジックシステムのデータ消費コストは、２３３ＫＢｓである。図８Ｃに示すように、３０秒のタイムクォンタムあたり８００システムコールのシステムコール負荷に対して、アプリケーションコンテナのフォレンジック情報を記憶するためのナイーブフォレンジック監視システムのデータ消費コストは、１９２ＭＢｓであり、これに対して、フォレンジック情報を記憶するための本原理のコンテナフォレンジックシステムのデータ消費コストは、２３０ＫＢｓである。図８Ｃに更に示すように、３０秒のタイムクォンタムあたり１２００システムコールのシステムコール負荷に対して、アプリケーションコンテナのフォレンジック情報を記憶するためのナイーブフォレンジック監視システムのデータ消費コストは、２８８．６Ｍｂｓであり、これに対して、フォレンジック情報を記憶するための本原理のコンテナフォレンジックシステムのデータ消費コストは、１９０ＫＢｓである。図８Ｃに示すように、アプリケーションコンテナのフォレンジック情報を記憶することに関連するデータ消費コストは、本原理のコンテナフォレンジックシステムに対しては、全てのシステムコール負荷にわたりナイーブフォレンジック監視システムと比較してはるかに少ない。

【0098】

本原理の実施形態は、コンテナがペイロードとして利用される小型衛星アプリケーション（例えば、ＣｕｂｅＳａｔｓ）におけるようなシステムにおいて適用することができる。このタイプの環境では、アプリケーションが何をしているのかを追跡することができるように、本原理に従ってフォレンジックを維持する必要がある場合があり、例えば、アプリケーションが乗っ取られたかどうか、アプリケーションがどのように乗っ取られたのか、エラーがあったかどうか、問題又は認証イベントが生じた後にアプリケーションが何をしたか（アドミニストレイターにとって有益なデータである場合がある）である。このタイプの情報を追跡する必要がある（例えば、システムコール、ネットワーキング動作、及びそれらの記録を監視する必要がある）。

【0099】

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

【0100】

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

【0101】

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

【0102】

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

【0103】

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

【0104】

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

【0105】

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

【0106】

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

【図1】

【図2A】

【図2B】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8A】

【図8B】

【図8C】