Paper Files / Containers
タイトル: クラウドネイティブ環境におけるコンテナセキュリティのための形式モデリングと適応型監視アーキテクチャ
タイトル: クラウドネイティブ環境におけるコンテナセキュリティのための形式モデリングと適応型監視アーキテクチャ 要旨: Docker や Kubernetes のようなコンテナおよびオーケストレータの大規模な採用は、ソフトウェア工学と重要インフラの運用を変革した一方で、拡大し動的に変化する攻撃対象領域をもたらした。CVE-2019-5736(runc)や CVE-2022-0492(cgroups)などの脆弱性は、名前空間および Linux カーネルの機構に基づく分離が、初期アクセスを得た攻撃者によって不適切に設定または悪用された場合に脆弱であることを示している。本研究では、コンテナ環境における適応型監視と脅威封じ込めのための、形式的に基礎づけられたアーキテクチャを提案する。これは、攻撃対象領域の数学的モデリング、システムコールグラフに基づく行動検知、ならびに緩和ポリシーの動的適用を組み合わせたものである。我々は MITRE ATT&CK for Containers に整合した脅威モデルを定義し、強固な分離、ランタイムの完全性、ワークロード間の非干渉といったセキュリティ特性を形式化した。さらに、主として二つのアルゴリズムを開発した。(i) 計算量 O(n log n) の、正当な行動プロファイルを増分的に推定する機構、(ii) ベイズスコアリングに基づくリスク分析を備えた適応型封じ込めモジュールである。我々は、eBPF、Falco、およびカスタム admission controller を用いて Kubernetes に統合したプロトタイプを実装した。120 ノード、3,500 pod のクラスタ上で、実際のワークロードと、MITRE ATT&CK の T1610、T1611、T1525 に対応付けられた攻撃の制御された注入を用いてソリューションを評価した。その結果、検知率 96.4%、平均偽陽性率 2.1%、CPU オーバーヘッド 4.8% 未満、監視イベントごとの平均追加遅延 3.7 ms を示した。以上より、提案手法は実運用可能性とスケーラビリティを維持しつつ、クラウドネイティブ環境における運用セキュリティの水準を大幅に向上させることが確認された。
- はじめに
コンテナに基づく軽量仮想化は、分散アプリケーションの展開における支配的なパラダイムとして確立され、とりわけマイクロサービス・アーキテクチャおよびクラウドネイティブ環境において広く採用されている。従来の仮想マシンとは異なり、コンテナはホストOSのカーネルを共有し、namespace や cgroup などの機構を用いて論理的な隔離を提供する。このモデルは運用効率と弾力性をもたらす一方で、ワークロード間の境界を低減し、基盤システムの攻撃面を拡大する。
近年のインシデントは、この状況の重大性を示している。脆弱性 CVE-2019-5736 は、runc ユーティリティの悪用を通じてコンテナ・エスケープを可能にし、基盤となるホストを侵害した。同様に、CVE-2022-0492 は cgroup の設定不備を悪用して高権限を取得した。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
計算量: バランス木構造の維持により $O(n \log n)$。
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 runtime 上でシステムを実装した。監視は libbpf ライブラリを用いた eBPF により実施した。動的ルールは、Go で実装したカスタム admission controller を通じて適用した。
このアーキテクチャは処理をノード間に分散し、中央ボトルネックを回避する。メトリクス集約には Redis を、可観測性には Prometheus を用いた。
- 実験評価
実験環境は 120 ノード(Intel Xeon 32 cores、128 GB RAM)で構成した。3,500 個の pod を、ベンチマーク・ワークロード(nginx、Redis、TensorFlow Serving)とともに実行した。
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.