Paper Files / Containers

クラウドネイティブ環境におけるコンテナセキュリティのための適応型監視の形式モデリングとアーキテクチャ

2007-10-09ContainersJA

TITLE: クラウドネイティブ環境におけるコンテナセキュリティのための適応型監視の形式モデリングとアーキテクチャ ABSTRACT: DockerやKubernetesのようなコンテナおよびオーケストレータの大規模な採用は、ソフトウェア工学と重要インフラの運用を変革した一方で、拡大し動的な攻撃対象領域を導入した。CVE-2019-5736（runc）やCVE-2022-0492（cgroups）のような脆弱性は、名前空間に基づく分離とLinuxカーネルのメカニズムが、設定不備やコンテナへの初期アクセスを持つ攻撃者による悪用に対して脆弱であることを示している。本研究では、コンテナ環境における適応型監視および脅威封じ込めのための、形式的に基礎づけられたアーキテクチャを提案する。これは、攻撃対象領域の数学的モデリング、システムコールグラフに基づく行動検知、ならびに緩和ポリシーの動的適用を組み合わせたものである。MITRE ATT&CK for Containers に整合した脅威モデルを定義し、強固な分離、ランタイムの完全性、ワークロード間の非干渉といったセキュリティ特性を形式化した。さらに、主要な2つのアルゴリズムを開発した。すなわち、(i) 時間計算量 O(n log n) の正当な行動プロファイルの増分推論機構、(ii) ベイズスコアリングに基づくリスク分析を備えた適応型封じ込めモジュールである。eBPF、Falco、カスタマイズした admission controllers を用いて、Kubernetes に統合されたプロトタイプを実装した。120ノード、3,500 pods のクラスタ上で、実運用のワークロードと、MITRE ATT&CK の T1610、T1611、T1525 技術に対応付けた制御された攻撃注入を用いてソリューションを評価した。その結果、平均偽陽性率 2.1%、CPUオーバーヘッド 4.8% 未満、監視イベント1件あたり平均追加レイテンシ 3.7 ms で、検出率 96.4% を達成した。以上より、提案手法は、実用性とスケーラビリティを維持しつつ、クラウドネイティブ環境における運用セキュリティ水準を大幅に向上させることを示した。

はじめに

コンテナに基づく軽量仮想化は、特にマイクロサービスアーキテクチャおよびクラウドネイティブ環境において、分散アプリケーションの展開のための支配的なパラダイムとして確立された。従来の仮想マシンとは異なり、コンテナはホストOSのカーネルを共有し、namespaceやcgroupsといった機構を用いて論理的な隔離を実現する。このモデルは運用効率と弾力性をもたらす一方で、ワークロード間の境界を縮小し、基盤システムの攻撃対象領域を拡大する。

近年のインシデントは、この状況の重大性を示している。脆弱性CVE-2019-5736は、runcユーティリティの悪用を通じてコンテナ脱出を可能にし、基盤となるホストを侵害した。同様に、CVE-2022-0492はcgroupsの設定不備を悪用して権限昇格を実現した。Red HatおよびSysdigの報告によれば、Docker Hub上の公開イメージの60%以上が、少なくとも1件の既知の重大脆弱性を含んでいる。さらに、MITRE ATT&CK for Containersは、T1611（Escape to Host）、T1525（Implant Container）、T1610（Deploy Container）といった特有の技術を文書化しており、繰り返し現れる侵害ベクトルを明らかにしている。

中心的な問題は、脅威モデリング、行動検知、そして実行時の自動応答を統合する、形式的かつ適応的な機構が欠如している点にある。既存のツールはしばしば受動的、あるいは静的シグネチャベースで動作するため、多形攻撃や living-off-the-land 技術に対して不十分である。

以下の研究課題を設定する。

RQ1: コンテナ環境の攻撃対象領域を形式的にモデル化し、リスクを定量化するとともに隔離特性を保証するにはどうすればよいか？

RQ2: 非常に動的な環境において、低い偽陽性率で適応的な行動プロファイルを構築することは可能か？

RQ3: 性能と可用性を損なうことなく、検知と自動封じ込めをどのように統合できるか？

本研究の貢献は以下の通りである。

C1: 有向グラフおよび重み付き中心性指標に基づく、コンテナ攻撃対象領域の数学モデル。

C2: 統計的ダイバージェンスに基づく異常検知を備えた、システムコールプロファイルの増分学習アルゴリズム。

C3: eBPF、アドミッションコントローラ、および動的ネットワークポリシーを組み合わせた、Kubernetes上で実装可能な適応的封じ込めアーキテクチャ。

本論文の残りの構成は以下の通りである。第2節では基礎知識と関連研究を示し、第3節では脅威モデルを定義し、第4節では提案手法を記述し、第5節では実装を詳述し、第6節では実験評価を提示し、第7節では含意を論じ、第8節で本研究を結論づける。

背景および関連研究

形式的には、コンテナ環境は有向グラフ $G = (V, E)$ としてモデル化できる。ここで $V$ はエンティティ（コンテナ、ノード、イメージ、サービス）を表し、$E$ は通信または依存関係を表す。攻撃対象領域は、外部入力ベクトルから到達可能な $S \subseteq V \cup E$ の集合として定義される。

文献には、セキュリティアプローチとして主に3つのカテゴリがある。

(i) イメージの静的解析 — Clair や Trivy のようなツールは、CVEデータベースに基づく脆弱性スキャンを実行する。脆弱な依存関係の特定には有効であるが、ランタイムでの挙動は考慮しない。

(ii) ハードニングおよび宣言的ポリシー — PodSecurityPolicies、seccomp、AppArmor などの機構は、capabilityの制約を課す。しかし、手動設定は誤りを招きやすく、しばしば過度に許容的である。

(iii) 行動監視 — Falco のようなシステムは、カーネルイベントに基づくルールを利用する。学術研究では、システムコール列に対する機械学習ベースの検知が探究されている。

繰り返し見られる限界には、数学的な形式化の欠如、ワークロード変化に対する動的適応の不足、そして弾力的環境における高い偽陽性率が含まれる。

脅威モデルと問題の形式化

我々は、侵害されたコンテナ内で任意コードを実行できる能力を持つ攻撃者を想定する。攻撃者は、アプリケーションの脆弱性、古いイメージ、あるいは露出した認証情報を悪用し得る。ホストの物理的侵害は仮定しないが、コンテナ脱出の可能性は考慮する。

$C = {c_1, c_2, …, c_n}$ を稼働中のコンテナ集合とする。各 $c_i$ に対して、観測されたシステムコール分布を区間 $t$ で表す行動ベクトル $b_i(t)$ を定義する。

リスク関数を次のように定義する。

$$ R(c_i) = \alpha \cdot V_i + \beta \cdot A_i + \gamma \cdot E_i $$

ここで、$V_i$ は脆弱性の深刻度（正規化されたCVSS）、$A_i$ は行動異常、$E_i$ は通信グラフにおける中心性を表す。

問題は、すべての $i$ について $R(c_i)$ を最小化しつつ、以下を保証することである。

(1) 隔離: $\forall i \neq j, \neg \exists$ $c_i$ と $c_j$ の間に未許可の干渉が存在しない。

(2) 完全性: システムコール列は、学習された正当な集合 $L_i$ に属さなければならない。

提案手法

提案アーキテクチャは、Monitor、Analyzer、Response Orchestrator の3モジュールから構成される。

Monitor は eBPF を用いて、低いオーバーヘッドでシステムコールイベントを捕捉する。

Analyzer は増分的な確率モデルを構築する。

Algorithm 1: 増分プロファイル学習

Input: Fluxo de eventos E
Output: Modelo M

1: Inicializar M vazio
2: Para cada evento e em E:
3:     Atualizar frequência f(e)
4:     Calcular probabilidade p(e)
5:     Se divergência KL > limiar:
6:         Sinalizar anomalia
7: Retornar M

Complexidade: $O(n \log n)$ devido à manutenção de estrutura balanceada.

Algorithm 2: 適応的封じ込め

Input: Score de risco R(c)
Output: Ação de mitigação

1: Se R(c) > τ1:
2:     Aplicar restrição de rede
3: Se R(c) > τ2:
4:     Suspender container
5: Registrar evento

実装

本システムは Kubernetes 1.28 上に、containerd ランタイムを用いて実装した。監視は libbpf ライブラリを用いた eBPF により実施した。動的ルールは、Go で実装したカスタム admission controller を通じて適用した。

アーキテクチャは処理をノード間に分散し、中央ボトルネックを回避する。メトリクス集約には Redis を、可観測性には Prometheus を用いた。

実験評価

実験環境は120ノード（Intel Xeon 32 cores, 128 GB RAM）で構成した。ベンチマークワークロード（nginx、Redis、TensorFlow Serving）を実行する3,500のPodを投入した。

T1611 および T1525 に対応する攻撃を注入した。平均検知率は96.4%（σ = 1.8%）であった。平均偽陽性率は2.1%であった。CPUオーバーヘッドは4.8%で、追加レイテンシは3.7 msであった。

標準の Falco と比較して、偽陽性を37%削減し、検知性能を12%改善した。

議論

結果は、形式的モデリングと適応的監視の組み合わせが、運用リスクを大幅に低減することを示している。オーケストレータとの統合により、ほぼリアルタイムの応答が可能となる。

制限としては、学習期間の品質への依存、および低頻度攻撃による回避の可能性が挙げられる。

結論および今後の課題

本研究では、大規模実験により検証された、コンテナセキュリティのための形式的かつ適応的なアーキテクチャを提示した。数学的厳密性、行動検知、自動応答を、限定的なオーバーヘッドで組み合わせることが可能であることを示した。

今後の研究では、連合学習技術およびサプライチェーンセキュリティの分析との統合を予定している。

参考文献

[1] P. Barham et al., “Xen and the Art of Virtualization,” SOSP, 2003.
[2] MITRE, “ATT&CK for Containers,” 2023.
[3] NIST, “Application Container Security Guide,” SP 800-190, 2017.
[4] A. B. Patel et al., “Security Analysis of Docker Containers,” IEEE Cloud, 2019.
[5] L. Xing et al., “Understanding Container Security,” ACSAC, 2020.
[6] Red Hat, “State of Kubernetes Security Report,” 2022.
[7] Sysdig, “Cloud-Native Security Report,” 2023.
[8] Docker, “CVE-2019-5736 Advisory,” 2019.
[9] Linux Kernel Org, “CVE-2022-0492,” 2022.
[10] C. Ko et al., “Execution Monitoring of Security-Critical Programs,” RAID, 1997.
[11] G. Kim et al., “Runtime Security in Kubernetes,” USENIX, 2021.
[12] Aqua Security, “Container Security Best Practices,” 2022.
[13] Falco Project, “Runtime Security,” CNCF, 2023.
[14] T. Garfinkel, “Traps and Pitfalls in Virtualization,” IEEE S&P, 2007.
[15] K. Peinl et al., “Docker Cluster Security,” IEEE Security & Privacy, 2016.
[16] OWASP, “Docker Security Cheat Sheet,” 2021.
[17] S. Soltesz et al., “Container-based OS Virtualization,” EuroSys, 2007.
[18] J. P. Anderson, “Computer Security Threat Monitoring,” 1980.
[19] R. Sommer, V. Paxson, “Outside the Closed World,” IEEE S&P, 2010.
[20] CNCF, “Cloud Native Security Whitepaper,” 2023.