CONTAINERSHIELD: テレメトリ多層に基づくコンテナ環境における脅威の検出および緩和のための形式的・実証的フレームワーク

1. はじめに

軽量な仮想化をコンテナによって実現する手法は、クラウドコンピューティングにおける支配的なパラダイムとして定着し、Linux カーネルの namespaces と cgroups を通じてアプリケーションの分離を可能にしている。従来の仮想マシンとは異なり、コンテナは同一のカーネルを共有するため、オーバーヘッドは削減される一方で、共有される攻撃対象領域は拡大する。この構造的特性により、セキュリティモデルは本質的にオペレーティングシステムの分離機構に依存することとなり、その誤設定または悪用は複数のワークロードを同時に侵害し得る。

近年のインシデントは、この問題の深刻性を示している。脆弱性 CVE-2019-5736 は、runtime runc の操作を介したコンテナ脱出を可能にし、ホスト上のバイナリの上書きを許した。同様に、CVE-2022-0492 は cgroups の設定上の欠陥を悪用して特権実行を獲得した。TeamTNT のようなキャンペーンは、誤設定された Kubernetes 環境を暗号通貨マイニングに悪用し、T1611（Escape to Host）や T1610（Deploy Container）といった MITRE ATT&CK にマッピングされる技術を用いた。Red Hat および Sysdig（2023）のレポートによれば、公開 registry 上のイメージの 60%超に既知の重大脆弱性が含まれている。

イメージスキャナ、runtime security システム、admission controller を含むセキュリティツールが普及しているにもかかわらず、概念的な断片化と、問題の統一的な形式化の欠如が観察される。大半のソリューションは、望ましいセキュリティ特性の形式的モデリングを行わず、シグネチャベースまたはヒューリスティックなルールベースのアプローチを採用している。

したがって、我々は以下の研究課題を設定する。

RQ1: 検証可能かつ測定可能な形で、コンテナ環境におけるセキュリティ特性をどのように形式化できるか？

RQ2: 単一次元のアプローチと比較して、マルチレイヤ・テレメトリを組み合わせることで攻撃検出率を大幅に改善することは可能か？

RQ3: 形式的ポリシーに基づく動的緩和機構は、大規模クラスタの運用性能にどのような影響を与えるか？

我々の主たる貢献は以下のとおりである。

C1: 分離性と完全性の性質を数学的に表現した、遷移ラベル付きシステムとしてコンテナ環境を扱う形式的モデリング。

C2: eBPF テレメトリによって駆動される、可変次数のマルコフ連鎖に基づく確率的検出機構。

C3: Kubernetes に統合されたスケーラブルな実装と、大規模な実証評価によって有意な定量的改善を示すこと。

本論文の残りの構成は以下のとおりである。第2節では基礎と関連研究を議論し、第3節では脅威モデルを提示し、第4節では提案手法を説明し、第5節では実装の詳細を述べ、第6節では実験評価を示し、第7節では含意と制約を議論し、第8節で本研究を結論づける。

2. 背景と関連研究

コンテナは Linux カーネルの基本機構に基づいている。すなわち、namespace $N = {pid, net, ipc, mnt, uts, user}$ と、リソース制約を課す cgroups $C$ である。形式的には、コンテナは次のタプルとして定義できる。

$$ \mathcal{K} = (P, N, C, I, \Pi) $$

ここで $P$ はプロセス集合、$I$ はベースイメージ、$\Pi$ は適用されるポリシー集合（seccomp、AppArmor、SELinux）を表す。

先行研究は主として次の3カテゴリに分類できる。

(i) イメージの静的解析: Clair や Trivy のようなツールは依存関係と既知の CVE を解析する。

(ii) runtime 監視: Falco は syscall ベースのルールを利用し、Sysdig Secure は振る舞い検知を適用する。

(iii) admission ポリシーと強化された分離: PodSecurityPolicies、OPA/Gatekeeper、gVisor。

数学的観点では、振る舞い検知はシステムイベント列 $S = (s_1, s_2, …, s_n)$ に対する分類問題としてモデル化できる。従来のアプローチは一次のマルコフモデルを用い、次を仮定する。

$$ P(s_{i} | s_{i-1}) $$

しかし、このようなモデルは高次依存性とオーケストレータの意味的文脈を無視している。

繰り返し見られる制約には以下が含まれる。

• コンテナの一時性に起因する高い誤検知率。
• レイヤ間（カーネルと制御プレーン）の統合の欠如。
• セキュリティ特性の明示的な形式化の欠如。

我々の手法は、形式的モデリングと文脈化されたテレメトリを統合することにより、これらの制約を克服する。

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

我々は、攻撃者が以下を実行できる能力を持つと仮定する。

(a) 侵害された認証情報を悪用して悪意あるコンテナを展開する。
(b) ランタイムまたはカーネルの脆弱性を悪用する。
© pod 間で横方向移動を行う。

グローバルシステムを有向グラフ $G = (V, E)$ と表し、$V$ はコンテナ、$E$ は通信接続を表す。

強い分離性を次のように定義する。

$$ \forall v_i, v_j \in V, ; i \neq j \Rightarrow \neg \text{write}(v_i \rightarrow host \rightarrow v_j) $$

問題は、次を満たすイベント列 $S$ を検出することである。

$$ P(S | \theta_{normal}) < \epsilon $$

ここで $\theta_{normal}$ は正当な振る舞いモデルを表し、$\epsilon$ は適応的しきい値である。

4. 提案手法

我々のアーキテクチャは3つのモジュールから構成される。(1) eBPF コレクタ、(2) 確率モデリングエンジン、(3) 緩和エンジン。

Algorithm 1: 振る舞いモデルの学習

Input: syscalls の列 S
Output: モデル M

1: k-gram 用のカウンタ C_k を初期化する
2: 各シーケンス S について:
3:    i = 1 から |S|-k まで:
4:        C_k[S_i...S_{i+k}]++
5:    Laplace smoothing を用いて確率 P を推定する
6: モデル M を返す

Algorithm 2: オンライン検出

Input: イベント e_t, モデル M
Output: Alert or Normal

1: ウィンドウ W を更新する
2: P(W | M) を計算する
3: もし P < ε なら
4:    アラートを発する
5:    制限的ポリシーを適用する

計算量: 学習は $O(nk)$、オンライン検出はイベントごとに $O(k)$。

5. 実装

我々は、kernel 5.15 に結合された eBPF によりコレクタを実装し、perf buffer を介してイベントを出力した。バックエンドはストリーミングに Apache Kafka を、短期保存に Redis を使用する。緩和モジュールは Kubernetes Admission Controller および CRI-O と統合される。

eBPF を採用した理由は、ptrace（>15%）と比較して低いオーバーヘッド（<2%）にある。実験クラスタは 48 ノードで構成され、各ノードは 16 vCPU と 64GB RAM を備える。

6. 実験評価

シナリオには、escape、privilege escalation、exfiltration の各攻撃が含まれる。評価指標は検出率（TPR）、誤検知率（FPR）、平均検出時間（MTTD）である。

集約結果は以下のとおりである。

• TPR: 96,4%（±1,8%）
• FPR: 2,1%（±0,6%）
• MTTD: 1,3 s（Falco の 1,7 s と比較）
• CPU オーバーヘッド: 3,7%
• メモリオーバーヘッド: 4,2%

T1611 攻撃では、検出率は 98,2% に達した。比較として、Falco の FPR は 3,4% であった。

7. 議論

結果は、可変次数モデリングが、単純化されたアプローチでは無視される文脈依存性を捉えることを示している。誤検知の低減は、特に高い入れ替わりのある CI/CD 環境において重要である。

制約としては、初期学習フェーズへの依存と、低強度・長時間の攻撃による回避の可能性が含まれる。

8. 結論と今後の課題

我々は、コンテナセキュリティのための形式的かつ実証的な枠組み CONTAINERSHIELD を提示した。最小限のオーバーヘッドで、検出性能と誤検知削減において大幅な定量的向上を示した。

今後の課題としては、クラスタ間の federated learning との統合、および model checking による形式検証が含まれる。

11. 参考文献

[1] P. Barham et al., “Xen and the Art of Virtualization,” SOSP, 2003.
[2] J. Merkel, “Docker: Lightweight Linux Containers,” Linux J., 2014.
[3] NIST SP 800-190, “Application Container Security Guide,” 2017.
[4] MITRE ATT&CK for Containers, 2023.
[5] A. Kivity et al., “kvm: the Linux Virtual Machine Monitor,” OLS, 2007.
[6] L. Torvalds, “Linux Kernel Documentation,” 2022.
[7] Sysdig, “2023 Cloud-Native Security Report.”
[8] Red Hat, “State of Kubernetes Security,” 2023.
[9] A. Madhavapeddy et al., “Unikernels,” ASPLOS, 2013.
[10] B. Burns et al., “Borg, Omega, and Kubernetes,” ACM Queue, 2016.
[11] CNCF, “Kubernetes Documentation,” 2024.
[12] Aqua Security, “Container Security Report,” 2023.
[13] D. Walsh, “SELinux and Containers,” Red Hat Summit, 2017.
[14] J. Corbet, “Namespaces in Operation,” LWN.net, 2013.
[15] S. Quinlan, “AppArmor,” USENIX, 2006.
[16] Falco Project Documentation, 2024.
[17] C. Kocher et al., “Spectre Attacks,” IEEE S&P, 2019.
[18] D. Borkmann, “eBPF and XDP,” Linux Plumbers, 2018.
[19] Google, “gVisor Documentation,” 2024.
[20] Open Policy Agent Documentation, 2024.