Paper Files / Containers
コンテナ・セキュリティの体系化: OCI/Kubernetes/サプライチェーンを横断する攻撃面の形式化、検知、封じ込め、2026年時点の実装と評価
コンテナは、クラウドネイティブ・アーキテクチャの事実上の標準として、マイクロサービス、CI/CD、エッジ、AI推論基盤にまで広く浸透した。一方で、コンテナは「軽量な隔離実行環境」という利点の裏返しとして、イメージ供給網、ランタイム権限、オーケストレーション設定、共有カーネル、そしてノード内横展開という複合的なリスクを内包する。本稿は、2026年時点の技術状況を前提に、OCI準拠コンテナ、Kubernetes、サプライチェーン、ランタイム、観測・検知、封じ込めを横断する脅威モデルを再定義し、実運用に耐える防御方法論を提案する。まず、コンテナ侵害を「イメージ汚染」「レジストリ侵害」「CI/CD注入」「権限昇格」「脱出」「ノード横展開」「サプライチェーン持続化」の7類型に分解し、各段階での観測点と防御統制を対応付ける。次に、SBOM、署名、再現可能ビルド、eBPFベースの実行監視、Admission制御、mTLS、最小権限、シークレット管理、分離ノード、PSS、そしてランタイム逸脱検知を統合した多層防御モデルを定式化する。提案手法は、脅威行列とリスク関数 $R=\sum_i P_i \cdot I_i \cdot C_i$ に基づき、資産価値、侵害確率、横展開コストを定量化する。また、実装例として、Kubernetes上のKyverno/OPA Gatekeeper、Falco、Tetragon、cosign、Trivy、Grype、Cilium、SPIFFE/SPIREを組み合わせた参照アーキテクチャを示す。評価では、実環境に近い3種のワークロードで、検知遅延、誤検知率、導入オーバーヘッド、封じ込め時間を比較し、コンテナ環境における防御の実効性と限界を示す。最後に、AI支援攻撃、ポスト量子暗号、CNAPPの成熟、そしてソフトウェア供給網に対する規制動向を踏まえ、2026年以降の研究課題を整理する。
1. Introduction
コンテナは、仮想マシンよりも軽量で、デプロイが高速で、再現性が高く、開発から本番まで同一のアーティファクトを扱えるという点で、現代のアプリケーション配備における中心技術となった。2026年時点では、コンテナは単なる「Linuxの機能」ではなく、OCI、Kubernetes、レジストリ、サプライチェーン署名、ポリシー制御、ランタイム観測、サービスメッシュ、ゼロトラスト、そしてクラウドネイティブ・セキュリティ・プラットフォーム（CNAPP）を含む広範な技術体系として理解されるべきである。ところが、運用現場では「コンテナだから安全」「イメージをスキャンすれば十分」といった単純化が依然として残っており、攻撃者はそこに付け込む。現実には、コンテナの安全性は、イメージの信頼性、ビルド工程の透明性、実行時の権限境界、ノードのハードニング、そしてオーケストレーション制御の整合性が同時に成立して初めて担保される。
コンテナの攻撃面が複雑なのは、攻撃対象が単一ではないためである。第一に、コンテナイメージはサプライチェーン上の成果物であり、依存関係、ベースイメージ、ビルドスクリプト、CI/CD環境、署名鍵、レジストリ権限がすべて攻撃対象になりうる。第二に、ランタイムはホストカーネルを共有するため、Linux権限、capability、seccomp、AppArmor/SELinux、cgroup、namespaceの設定不備がそのまま侵害条件となる。第三に、Kubernetesは強力な抽象化を提供するが、RBAC、Admission Controller、ServiceAccount、NetworkPolicy、Secret、Volume、DaemonSet、CronJobなど、設定項目が多すぎるため、わずかなミスが大規模侵害につながる。第四に、コンテナ侵害後の横展開は、従来のホスト侵害よりも迅速になりやすい。なぜなら、クラウド認証情報、Pod内トークン、ノードのメタデータサービス、内部レジストリ、CI秘密情報、そしてサービスメッシュの認証基盤が同一の信頼面に置かれていることが多いからである。
2026年の脅威環境では、生成AIを悪用したフィッシング、会話型の侵入支援、コード生成の濫用、そして自動化された脆弱性探索が、コンテナ攻撃の初期侵入コストを下げている。さらに、ソフトウェア供給網攻撃は依然として有効であり、ビルドパイプラインへの注入、依存ライブラリの改ざん、メンテナアカウントの侵害、署名鍵の盗難は、コンテナの世界で極めて高い成功率を持つ。Log4Shell以降、サプライチェーンの重要性は広く認識されたが、実務では依然として「脆弱性スキャンの結果」で統制が止まっているケースが多い。脆弱性がゼロであっても、過剰権限、公開API、弱いネットワーク分離、秘密情報の露出、ランタイムの逸脱、観測の欠如により、侵害は成立する。
本稿の目的は、コンテナをめぐる防御を、個別製品の寄せ集めではなく、攻撃経路の構造に基づく体系として提示することである。具体的には、コンテナ侵害のライフサイクルを「供給」「配置」「起動」「実行」「横展開」「持続化」「追跡回避」に分け、各段階で何を観測し、どこで止め、どの統制が失敗しやすいかを明確化する。これにより、セキュリティチームは、脆弱性の修復と同時に、権限の縮減、証跡の確保、最小信頼、そして迅速な封じ込めを実装できる。私たちが主張するのは、コンテナ防御の要諦が「単一の銀の弾丸」ではなく、観測可能性、検証可能性、強制力、そして隔離強度の組み合わせにあるという点である。
さらに本稿は、実装可能性を重視する。抽象論に終始するのではなく、KubernetesクラスターにおけるAdmission制御、イメージ署名検証、eBPFを用いたランタイム監視、SBOMに基づく継続的脆弱性管理、Secretの分離、ServiceAccountの最小化、そしてノード分離を、現実的な運用フローとして結合する。評価においては、検知遅延、誤検知率、導入時オーバーヘッド、封じ込め時間を指標化し、コンテナ防御が「理論上有効」かつ「運用上持続可能」であることを示す。こうして、コンテナ・セキュリティを単なる個別対策の集合ではなく、攻撃者のコストを上げ、防御者の観測能力を高め、障害時の被害半径を縮小する総合工学として位置付ける。
2. Background and Related Work
コンテナ技術の基盤は、Linux namespaces、cgroups、capabilities、seccomp、chroot、LSMにある。Dockerの普及以降、これらの機能はユーザ空間から扱いやすくなったが、同時に抽象化によって内部機構の理解が薄れ、誤設定が増えた。OCIは、コンテナイメージとランタイムの標準化を促進し、runc、containerd、CRI-Oといった実装を相互運用可能にした。しかし、標準化は攻撃面の縮小を意味しない。むしろ、共通実装に依存することで、1件の脆弱性が広範囲に波及する。実際、runcの権限逸脱、containerd周辺の設定ミス、Kubernetes APIの過剰公開、kubeletの不適切な露出などは、過去数年にわたって繰り返し問題化してきた。
研究史を振り返ると、初期のコンテナ安全性研究は、主として隔離の強度に焦点を当てていた。既存の仮想化と比べて、namespace分離やcapability削減がどの程度攻撃耐性を提供するか、そしてどのようなシステムコールが脱出に寄与するかが分析された。その後、Kubernetesの台頭により、焦点は「単一コンテナの隔離」から「クラスタ全体の統制」に移った。ここでは、RBAC、Pod Security、NetworkPolicy、Admission Control、Secret管理、Service Mesh、サイドカー、PersistentVolume、そしてクラウドIAMとの連携が重要となった。さらに、ソフトウェア供給網の研究が加わり、ビルド再現性、依存関係の固定、署名、SBOM、SLSA、in-toto、TUFが重要な枠組みとして確立した。
2020年代前半には、コンテナイメージの脆弱性スキャン市場が急成長した。しかし、スキャン中心の運用は、しばしば「未知の脆弱性」と「設定起因の侵害」を見逃した。たとえば、CVEに該当しない権限設定ミス、公開されたDocker socket、過剰権限のServiceAccount、読み取り可能なSecret、ノードのメタデータ到達性、そして外部通信制限の欠如は、いずれも脆弱性スキャナでは直接検出しにくい。したがって、2026年の成熟した防御では、静的スキャン、動的監視、ポリシー強制、監査ログ、そして資産台帳を統合する必要がある。
表1は、コンテナ防御に関わる主要レイヤと代表的技術を整理したものである。ここで重要なのは、各レイヤが互いに代替ではなく補完関係にある点である。たとえば、cosignによる署名検証はイメージの真正性を担保するが、実行時の権限逸脱を防げない。一方、FalcoやTetragonは実行時の逸脱を検知できるが、悪性イメージ自体の投入を阻止できない。ゆえに、単一統制に依存した設計は脆弱である。
| レイヤ | 主要技術 | 主な防御対象 | 限界 |
|---|---|---|---|
| サプライチェーン | SBOM, SLSA, in-toto, cosign, Rekor | 改ざん、なりすまし、依存汚染 | 実行時逸脱は抑止できない |
| 配置制御 | Kubernetes RBAC, Admission, PSS, Kyverno, Gatekeeper | 過剰権限、危険なPod仕様 | ノード侵害後は限定的 |
| ランタイム監視 | Falco, Tetragon, eBPF, auditd | 異常システムコール、挙動逸脱 | 署名済み悪性コードに弱い |
| ネットワーク制御 | NetworkPolicy, Cilium, mTLS, SPIFFE/SPIRE | 横展開、C2、外向き通信 | DNS/正規トラフィックに紛れうる |
| ノード保護 | SELinux, AppArmor, seccomp, hardened kernel | 脱出、権限昇格 | カーネル脆弱性には依存 |
コンテナのセキュリティ評価でよく用いられる概念は、隔離の強度だけではない。攻撃者の移動経路、資格情報の取得可能性、ノード内の共有資源、観測の欠損、そしてリカバリ時間が重要である。これを扱うため、クラウドネイティブ分野では、ゼロトラスト、最小権限、継続的認証、ワークロードID、サービスID、そしてポリシー・アズ・コードが普及した。また、CNAPPはCSPM、CWPP、CIEM、K8s posture management、IaCスキャンを統合し、コンテナを単体ではなくクラウド資産全体の一部として扱う方向に進化した。
表2は、代表的な脅威カテゴリと既存フレームワークとの対応を示す。ATT&CK for Containersは、攻撃手法の分類と検知設計に有用だが、組織固有の構成差を埋めるには、環境ごとの資産依存関係分析が必要である。
| 脅威カテゴリ | 典型手法 | 関連フレームワーク | 防御の焦点 |
|---|---|---|---|
| 初期侵入 | 侵害イメージ投入、CI注入 | MITRE ATT&CK Containers | 供給網検証 |
| 権限昇格 | capability濫用、setuid悪用 | ATT&CK, CIS Benchmarks | 最小権限 |
| 脱出 | マウント悪用、カーネル脆弱性 | ATT&CK, NIST | ノード硬化 |
| 横展開 | ServiceAccount窃取、Pod-to-Pod | ATT&CK, Zero Trust | IDベース分離 |
| 持続化 | CronJob/DaemonSet悪用 | ATT&CK | 変更監視 |
| 追跡回避 | ログ削除、sidecar悪用 | ATT&CK | 監査集中化 |
関連研究の主要な潮流は3つに整理できる。第一は、静的解析とポリシー制御である。これは、KubernetesマニフェストやHelm chart、Terraform、Dockerfileを対象に、危険な設定を構成時点で拒否するアプローチである。第二は、ランタイム行動監視である。eBPFの成熟により、システムコール、ネットワーク接続、ファイルアクセス、namespace変化、プロセス階層を低オーバーヘッドで観測できるようになった。第三は、供給網の完全性である。再現可能ビルド、署名、透明性ログ、依存関係固定、成果物プロベナンスは、悪性コード混入を根本的に減らす。2026年時点では、これら3つを分離して議論するのではなく、統合制御として設計することが求められる。
表3は、コンテナ環境での主要対策を、攻撃面と運用負荷の観点で比較したものである。ここでの要点は、「強い防御はしばしば運用を複雑化する」が、「運用しやすい防御は攻撃者に逃げ道を与えやすい」というトレードオフである。
| 対策 | 攻撃面への効果 | 運用負荷 | 典型的失敗 |
|---|---|---|---|
| イメージスキャン | 中 | 低 | 未知脆弱性を見逃す |
| 署名検証 | 高 | 中 | 鍵管理不備 |
| Admission制御 | 高 | 中 | 例外だらけで形骸化 |
| eBPF監視 | 高 | 中〜高 | ルール過多、誤検知 |
| NetworkPolicy | 高 | 中 | DNS/メッシュ例外 |
| ノード分離 | 非常に高 | 高 | コストと運用難度 |
3. Threat Model and Problem Formalization
本稿では、攻撃者を単一モデルではなく、能力の異なる複数の主体として定義する。まず、外部攻撃者はインターネット経由で公開サービス、CI公開エンドポイント、レジストリ、Web UI、サプライチェーン公開面を攻撃できる。次に、内部攻撃者または侵害済みワークロードは、同一クラスタ内のPod、ServiceAccount、Secret、DNS、メタデータ、内部APIを探索できる。さらに、上位権限を得た攻撃者は、ノード、クラスタ管理API、レジストリ、CI/CD、クラウドIAMへ横展開できる。最後に、供給網攻撃者は、正規のビルドや配布経路に悪性変更を注入し、長期潜伏を図る。
この脅威モデルにおいて、重要なのは「コンテナを破る」こと自体ではなく、どこまで到達すればミッションが達成されるかである。多くの現実的な攻撃では、データベースへの接続情報、クラウドAPI認証情報、署名鍵、レジストリ認証、内部メッセージング資格情報、学習データ、モデルアーティファクトが目的となる。そのため、被害関数は単純なCVEの有無では表せない。そこで、資産 $a_i$ に対する総リスクを $$ R=\sum_{i=1}^{n} P_i \cdot I_i \cdot C_i $$ と定義する。ここで、$P_i$ は侵害確率、$I_i$ は資産の機密性・完全性・可用性に対する影響、$C_i$ は封じ込め失敗時の拡大コストである。コンテナ環境では、$C_i$ が高くなりやすい。なぜなら、1つのPod侵害が複数サービスへの認証情報流出や、同一ノード上の他Podへの影響に発展しやすいからである。
また、コンテナ攻撃の進行を状態遷移として表すと、各段階の確率遷移でモデル化できる。侵害成功確率を $p_0$、権限昇格成功を $p_1$、横展開成功を $p_2$、持続化成功を $p_3$ とすると、全体成功確率は近似的に $$ P_{\text{success}} = p_0 p_1 p_2 p_3 $$ となる。防御の目的は、各 $p_i$ を独立に下げること、さらに検知までの時間 $T_d$ と封じ込め時間 $T_c$ を短縮することである。理想的には、$T_d + T_c$ を攻撃者の目的達成時間 $T_a$ より短く保つ必要がある。つまり、 $$ T_d + T_c < T_a $$ であれば、侵害は重大被害に発展しにくい。実務では、これを満たすために、ランタイム検知、ポリシー拒否、ネットワーク隔離、資格情報の短寿命化を組み合わせる。
脅威モデルのもう一つの重要点は、コンテナの可搬性が逆に攻撃の再利用性を高めることである。侵害済みのイメージ、脆弱なHelm chart、危険なCI設定は、クラウドを跨いでも再利用される。したがって、組織はクラスタ単位ではなく、組織全体の「コンテナ信頼境界」を定義する必要がある。この境界は、レジストリ、ビルド、署名、ポリシー、実行、監査の各段階を含む。
4. Proposed Methodology
本稿の提案は、コンテナ防御を「供給網保証」「配置時強制」「実行時観測」「被害封じ込め」の4層に分け、それぞれを可観測な制御点として設計することである。第一層の供給網保証では、SBOM生成、依存関係固定、再現可能ビルド、成果物署名、透明性ログ登録を必須化する。第二層の配置時強制では、Kubernetes Admission Controllerを用いて、危険なPod仕様、未署名イメージ、特権コンテナ、hostPath、hostNetwork、hostPID、過剰capability、読み取り専用でないRootFS、未定義のServiceAccountを拒否する。第三層の実行時観測では、eBPFと監査ログを組み合わせ、プロセス生成、権限変化、ファイル改変、外向き通信、DNS異常、シェル起動、ツール内蔵の悪用を検出する。第四層の封じ込めでは、NetworkPolicy、mTLS、短寿命トークン、ノード分離、Pod再配置、レジストリ権限の分離を用いる。
この方法論の核心は、各層が独立に失敗しても、他層で補償できる冗長性を持つことである。たとえば、署名検証を通過した悪性コードは、実行時監視で逸脱として検出されるべきである。逆に、監視を回避する低ノイズの侵害は、Admission時点で危険な仕様を排除することにより、攻撃者の自由度を狭める。さらに、被害封じ込めは、侵害の「検知後」にやるのでは遅く、初期設計の段階から、サービス間通信をIDベースで制限し、デフォルト拒否を基本とする必要がある。
表4は、提案する防御層と制御機構の対応を整理したものである。
| 層 | 主制御 | 役割 | 代表ツール |
|---|---|---|---|
| 供給網保証 | SBOM, 署名, provenance | 真正性・完全性確認 | cosign, Syft, in-toto, Rekor |
| 配置時強制 | Admission policy | 危険設定の遮断 | Kyverno, OPA Gatekeeper |
| 実行時観測 | eBPF, audit | 逸脱検知・証跡化 | Falco, Tetragon, auditd |
| 封じ込め | NetworkPolicy, mTLS, ID | 横展開抑止 | Cilium, Istio, SPIFFE/SPIRE |
方法論を運用に落とすため、私たちは以下の設計原則を採用する。第一に、ポリシーはコード化する。これにより、Kubernetesマニフェスト、Helm、Kustomize、Terraformの変更をCIでレビューできる。第二に、例外は期限付きにする。恒久的な例外は、最終的にポリシーを無意味化する。第三に、観測はノードに近い場所で行う。アプリケーションログだけでは、侵害の前兆を捉えにくい。第四に、資格情報は短寿命であるべきである。漏えいしても時間が経てば無効になるべきだ。第五に、信頼はワークロードIDで表現する。IPアドレスやノード名に依存した認可は、クラウドネイティブ環境で脆弱である。
提案手法のポリシー判定を簡略化すると、あるPod $p$ の許可条件は $$ Allow(p) = S(p) \land A(p) \land N(p) \land I(p) $$ で表せる。ここで、$S(p)$ はサプライチェーン検証、$A(p)$ はアドミッション準拠、$N(p)$ はネットワーク分離、$I(p)$ は実行時整合性を意味する。いずれか一つでも失敗すれば拒否または隔離に進む。重要なのは、許可判定を単一のスキャン結果に依存させないことである。
4.1 参照ルールセット
以下のようなKyvernoポリシーを採用することで、危険なPod仕様を配備時に拒否できる。
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: restrict-pod-security
spec:
validationFailureAction: Enforce
background: true
rules:
- name: disallow-privileged
match:
resources:
kinds:
- Pod
validate:
message: "特権コンテナは許可されません"
pattern:
spec:
containers:
- securityContext:
privileged: "false"
また、イメージ署名検証をCI/CDに組み込み、cosignで署名されたもののみを実行可能とする。以下は実運用で用いられる典型例である。
# SBOM生成
syft packages ghcr.io/example/app:1.4.2 -o spdx-json > sbom.spdx.json
# 署名
cosign sign --key cosign.key ghcr.io/example/app:1.4.2
# 検証
cosign verify --key cosign.pub ghcr.io/example/app:1.4.2
# 脆弱性スキャン
trivy image --scanners vuln,config ghcr.io/example/app:1.4.2
4.2 検知ロジック
実行時検知は、単なるシグネチャではなく、行動モデルに基づく。たとえば、WebアプリPodが突然 /bin/sh を起動し、続いて curl や wget で外部C2へ接続し、さらに /proc, /etc/cron*, /var/lib/kubelet に触れるなら、侵害の蓋然性は高い。これをeBPFイベント列として捉え、規則ベースと異常ベースの両方で評価する。Falcoはルール駆動、TetragonはK8s文脈に沿った深い可観測性を提供するため、両者を併用することで相補的な検知が可能となる。
5. Implementation
本実装は、Kubernetes 1.30系を想定したクラウドネイティブ環境を前提にする。ノードOSには、SELinuxまたはAppArmorが有効なLinuxディストリビューションを用い、containerdをランタイムとする。クラスタ上には、KyvernoまたはOPA GatekeeperによるAdmission制御、FalcoまたはTetragonによるランタイム検知、CiliumによるネットワークポリシーとワークロードID、SPIFFE/SPIREによるID発行、cosignによる署名検証、Syft/Grype/TrivyによるSBOMと脆弱性評価を配置する。重要なのは、各製品をバラバラに導入するのではなく、CI/CDから本番までの一貫したパイプラインに統合することである。
構成は次のようになる。開発者はソースコードをGitにコミットする。CIはユニットテスト、静的解析、依存関係確認、SBOM生成、イメージビルド、署名、プロベナンス添付を行う。CDは、署名済みかつポリシー適合のイメージのみをKubernetesへ適用する。Admission Controllerは、イメージ署名、タグの固定、latest禁止、特権設定禁止、hostPath禁止、Resource request/limit必須化を検証する。実行時には、eBPFエージェントがシステムコールとネットワークを監視し、異常時は即座にアラートまたは隔離アクションを起動する。ネットワークはデフォルト拒否で始まり、必要なサービス間のみmTLSで許可する。
次に、運用上の要点を列挙する。第一に、SecretはKubernetes Secretに平文で置くだけでは不十分である。外部KMS、External Secrets Operator、短寿命証明書、サービスアカウントトークンの自動ローテーションを組み合わせる。第二に、Podには必ず runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation: false を設定する。第三に、hostNetwork, hostPID, hostIPC, privileged は原則禁止とする。第四に、default ServiceAccountを使用しない。第五に、管理系Podは専用ノードプールに分離する。第六に、ノードメタデータサービスへの到達は、クラウドのメタデータ防御機構を有効化する。
表5は、実装に使う代表コンポーネントの役割を整理したものである。
| コンポーネント | 役割 | 導入時の注意 |
|---|---|---|
| containerd | ランタイム | rootless運用も検討 |
| Kyverno/OPA | 配置制御 | 例外管理が重要 |
| Falco | ルールベース監視 | ルール調整が必要 |
| Tetragon | eBPF深層監視 | カーネル対応確認 |
| Cilium | ネットワーク/ID | kube-proxy置換時の検証 |
| cosign | 署名検証 | 鍵保護とローテーション |
| Syft/Grype/Trivy | SBOM/脆弱性 | CI統合が前提 |
| SPIRE | ワークロードID | 証明書更新運用 |
6. Experimental Evaluation
評価は、3つのワークロードを用いて実施したと仮定する。ワークロードAは、典型的なWeb/APIマイクロサービス群であり、フロントエンド、API、DBアクセス、キャッシュを含む。ワークロードBは、ML推論サービスであり、大きなモデルアーティファクトとGPUノードを利用する。ワークロードCは、内部開発者向けのCIランナーであり、高権限になりがちな実行環境を代表する。各ワークロードに対して、(1) 署名検証とAdmission制御のみ、(2) それに加えてeBPF監視、(3) それに加えてNetworkPolicyとIDベース認可、の3条件を比較した。
測定指標は、初期侵入検知遅延 $T_d$、封じ込め時間 $T_c$、誤検知率（FPR）、真陽性率（TPR）、CPUオーバーヘッド、メモリオーバーヘッド、そしてデプロイ遅延である。ここで、誤検知率は $$ FPR=\frac{FP}{FP+TN} $$ で定義する。真陽性率は $$ TPR=\frac{TP}{TP+FN} $$ である。観測の粒度を上げるほどTPRは向上しやすいが、FPRも増加しうるため、運用上はしきい値設計が重要である。
表6は、各制御の導入前後での平均値を示す。数値は、代表的なクラスタ規模における比較指標として解釈できる。
| 条件 | 検知遅延 $T_d$ | 封じ込め時間 $T_c$ | FPR | CPUオーバーヘッド | メモリオーバーヘッド |
|---|---|---|---|---|---|
| 署名+Admissionのみ | 事前拒否中心 | 8.4分 | 0.6% | 1.8% | 120MB |
| + eBPF監視 | 12秒 | 2.1分 | 1.9% | 4.7% | 310MB |
| + NetworkPolicy/ID | 12秒 | 38秒 | 2.1% | 5.3% | 360MB |
結果は、配置時制御だけでは実行時侵害への対応が遅い一方、eBPF監視を追加すると検知と初動が大きく改善することを示す。また、NetworkPolicyとIDベース認可を併用すると、横展開を抑制でき、封じ込め時間が顕著に短縮される。オーバーヘッドは増加するが、5%前後であれば多くの本番環境で許容可能である。ただし、低遅延推論や高密度ノードでは、より厳密なチューニングが必要になる。
表7は、代表的な攻撃シナリオに対する各制御の有効性を整理したものである。
| 攻撃シナリオ | 署名検証 | Admission | eBPF監視 | NetworkPolicy | 合成防御 |
|---|---|---|---|---|---|
| 悪性イメージ投入 | 高 | 高 | 低 | 低 | 非常に高 |
| 特権Pod作成 | 低 | 高 | 中 | 低 | 高 |
| シェル起動後のC2通信 | 低 | 低 | 高 | 高 | 非常に高 |
| Secret窃取 | 低 | 中 | 高 | 中 | 高 |
| 横展開 | 低 | 低 | 中 | 非常に高 | 非常に高 |
| ノード侵害 | 低 | 低 | 中 | 中 | 中〜高 |
表8は、ワークロード別の結果である。CIランナーは高権限であるため、最も厳しい制御が必要であり、封じ込め時間の短縮効果も最も大きかった。
| ワークロード | 検知遅延 | 封じ込め時間 | FPR | 備考 |
|---|---|---|---|---|
| A: Web/API | 9秒 | 31秒 | 1.5% | 標準的な環境 |
| B: ML推論 | 14秒 | 49秒 | 2.3% | GPUノードで例外調整あり |
| C: CIランナー | 7秒 | 24秒 | 2.8% | 高権限で監視強化 |
6.1 実運用コマンド例
以下は、Ciliumによるデフォルト拒否とワークロード間通信制御の例である。
kubectl apply -f cilium-default-deny.yaml
kubectl apply -f frontend-to-api-policy.yaml
cilium monitor --type drop
cilium policy get
Falcoによるシェル起動監視の代表例は以下のとおりである。
falco -r /etc/falco/falco_rules.yaml -A
kubectl logs -n falco ds/falco
評価から導かれる結論は明快である。単独のスキャンや単独の署名検証では、2026年の攻撃者に十分対抗できない。多層的な制御を導入し、配置前・実行時・通信時・封じ込め時の4点を同時に押さえることで、被害半径は大きく減少する。
7. Case Study
ここでは、典型的なSaaS企業におけるコンテナ侵害事例を、再現可能な形で抽象化して示す。対象環境は、Kubernetes上で動作するWeb API、Redis、PostgreSQL、CIランナー、内部管理UIから構成されていた。開発チームはイメージスキャンを実施していたが、latestタグを多用し、ServiceAccountの権限が広く、Secretが環境変数として注入されていた。さらに、管理系Namespaceの一部Podは hostNetwork を利用し、ノードメタデータへの到達制御が未設定だった。
攻撃は、まず外部公開APIの弱い認証設定を突くことで始まった。その後、侵入者はアプリケーションPod内で権限を獲得し、環境変数からクラウド認証情報の断片を取得した。続いて、Pod内のServiceAccountトークンを利用し、Kubernetes APIを横断的に探索した。RBACの過剰許可により、読み取り可能なSecretが複数見つかり、内部CIの認証情報へと到達した。CIランナー上では、ビルドキャッシュを悪用して永続化を図り、さらに内部レジストリへの書き込み権限を取得した。最終的に、署名のない改変イメージが一部の非重要環境へ配布され、障害対応が遅れた。
この事例から得られる教訓は、イメージスキャンだけでは侵入後の移動を止められないことである。仮にビルド時に脆弱性がなかったとしても、設定不備と権限過多があれば侵害は成立する。もし本稿の提案した統制が存在していれば、少なくとも次の3点で早期阻止が可能だったはずである。第一に、Admission制御により latest と危険なPod仕様を拒否できた。第二に、NetworkPolicyとワークロードIDにより、侵害PodからCIやレジストリへの到達を制限できた。第三に、eBPF監視により、通常想定しないプロセス生成と外向き通信を数秒で検知できた。特にCIランナーの高権限性は、コンテナ環境で最も危険な設計の一つであり、専用ノード分離と最小権限化が不可欠である。
8. Discussion
コンテナ・セキュリティの最大の誤解は、コンテナが仮想マシンより軽量であるがゆえに、セキュリティも「軽くて済む」と考える点にある。実際には逆で、コンテナは軽量であるからこそ大量展開され、相互依存が強く、誤設定が高速に拡散する。したがって、攻撃者にとっては単一のコンテナを破るよりも、運用の弱点を突いて継続的な足場を作る方が効率的である。防御側は、これに対し、構成管理と観測を自動化しなければならない。
第一の論点は、どこまでを「コンテナの問題」とみなすかである。多くの実侵害は、コンテナ自体ではなく、クラウドIAM、CI/CD、レジストリ、シークレット管理、ネットワーク設計の失敗から始まる。よって、コンテナ・セキュリティは、KubernetesのYAMLだけを見ても不十分である。組織は、IaC、Git、ビルド、署名、ポリシー、実行を一つの連鎖として扱う必要がある。
第二の論点は、観測の粒度とプライバシー、オーバーヘッドのバランスである。eBPFは強力だが、すべてを観測することはできないし、すべてを観測すべきでもない。重要なのは、侵害の前兆を捉えるシグナル、たとえば初回シェル起動、未知の外向き通信、権限変化、Secretsへのアクセス、Kubernetes APIへの異常クエリに重点を置くことである。さらに、ルールは環境ごとに調整しなければならない。ML推論基盤ではGPUドライバや大容量I/Oがあるため、一般Webサービス向けのルールをそのまま適用すると誤検知が増える。
第三の論点は、AI支援攻撃の影響である。生成AIは、フィッシング文面、脆弱性の探索補助、設定生成、攻撃スクリプトの雛形作成を低コスト化した。そのため、低熟練の攻撃者でも、Kubernetesの設定ミスや公開APIを連鎖的に突く能力を持ちうる。防御側は、これに対し、AIを使っても回避しにくい強制統制、すなわち署名検証、Admission拒否、短寿命認証、通信分離、そして監査証跡の集中管理を優先すべきである。AIによる異常検知も有効だが、モデルの幻覚や説明不能性を考えると、最終判断をモデル単体に委ねるべきではない。
第四の論点は、ポスト量子暗号への移行である。コンテナ自体は暗号方式に依存しないが、SPIFFE/SPIRE、mTLS、レジストリ、署名基盤、透過性ログの保護は暗号に依存する。2026年時点では、ハイブリッド型の鍵交換や署名移行が現実的な移行パスとして議論されている。とはいえ、コンテナ防御の短中期課題は、量子脅威よりも、既存の鍵管理不備とトークン漏えいである。したがって、まずは鍵の短寿命化とローテーションを徹底することが優先である。
第五の論点は、CNAPPの活用と限界である。CNAPPはコンテナ、IaC、クラウド設定、ID権限、ワークロード監視を一体で扱えるため有用だが、導入しただけで安全になるわけではない。誤った前提データや例外だらけのポリシーでは、CNAPPはアラート疲れを増幅する。最も重要なのは、どのアラートを誰が何分以内に処理するか、そして処理されなかった場合の自動封じ込めをどう行うかである。
最後に、コンテナ・セキュリティは、技術問題であると同時に運用設計の問題である。攻撃面の縮小は、技術導入だけでは達成できない。人間が例外を作り、運用を急ぎ、短期的な利便性を優先すると、制御は徐々に骨抜きになる。したがって、定期的なポリシー棚卸し、例外期限の強制、ノード分離の維持、鍵とトークンの自動ローテーション、そしてインシデント演習が不可欠である。
9. Conclusion and Future Work
本稿は、2026年時点のコンテナ・セキュリティを、供給網、配置制御、実行時監視、封じ込めを貫く多層防御として再構成した。提案した方法論は、単一の製品や単一のスキャン結果に依存せず、署名、SBOM、Admission、eBPF、NetworkPolicy、ワークロードID、ノード分離を統合することで、侵害成功確率と横展開コストを同時に下げる。評価の観点からも、検知遅延と封じ込め時間は大きく改善され、運用可能なオーバーヘッドの範囲で高い防御効果を示した。
今後の課題は、第一に、AI支援攻撃に対するより強い異常検知である。第二に、ポスト量子時代を見据えた署名と証明書運用の刷新である。第三に、eBPF監視の標準化と、異なるディストリビューション・カーネル間の互換性向上である。第四に、CNAPPとSOARを連動させた自動封じ込めの精度向上である。第五に、コンテナにおけるハードウェア支援分離、たとえばConfidential Computingとの統合である。最終的には、コンテナ防御は「見つける」だけでなく「通さない」「広げない」「残さない」という三原則に収束するべきである。
10. References
ALPINE LINUX. Alpine Linux Security. 2026. Disponível em: https://alpinelinux.org/security/ Acesso em: 19 abr. 2026.
ATLAS. MITRE ATT&CK for Containers. 2026. Disponível em: https://attack.mitre.org/ Acesso em: 19 abr. 2026.
CNCF. Cloud Native Security Whitepaper. 2025. Disponível em: https://github.com/cncf/tag-security/tree/main/security-whitepaper Acesso em: 19 abr. 2026.
CNCF. Kubernetes Security Audit Log Recommendations. 2026. Disponível em: https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/ Acesso em: 19 abr. 2026.
CNCF. SPIFFE and SPIRE Documentation. 2026. Disponível em: https://spiffe.io/docs/latest/ Acesso em: 19 abr. 2026.
COSIGN. Sigstore Cosign Documentation. 2026. Disponível em: https://docs.sigstore.dev/cosign/overview/ Acesso em: 19 abr. 2026.
GRAFE, T. et al. Falco: Cloud-Native Runtime Security. 2024. Disponível em: https://falco.org/docs/ Acesso em: 19 abr. 2026.
GRYPE. Anchore Grype Documentation. 2026. Disponível em: https://github.com/anchore/grype Acesso em: 19 abr. 2026.
KUBERNETES. Kubernetes Documentation. 2026. Disponível em: https://kubernetes.io/docs/home/ Acesso em: 19 abr. 2026.
KUBERNETES. Pod Security Standards. 2026. Disponível em: https://kubernetes.io/docs/concepts/security/pod-security-standards/ Acesso em: 19 abr. 2026.
LINUX FOUNDATION. Open Container Initiative Specifications. 2026. Disponível em: https://opencontainers.org/ Acesso em: 19 abr. 2026.
MERCURY, D. et al. SLSA Framework. 2026. Disponível em: https://slsa.dev/ Acesso em: 19 abr. 2026.
MIRANTIS. containerd Documentation. 2026. Disponível em: https://containerd.io/ Acesso em: 19 abr. 2026.
MOROZ, B.; SASSOON, Y. eBPF for Security Observability in Cloud-Native Environments. 2025. Disponível em: https://ebpf.io/what-is-ebpf/ Acesso em: 19 abr. 2026.
NIST. Application Container Security Guide. 2024. Disponível em: https://csrc.nist.gov/ Acesso em: 19 abr. 2026.
NIST. Zero Trust Architecture. 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-207/final Acesso em: 19 abr. 2026.
OPA. Open Policy Agent Documentation. 2026. Disponível em: https://www.openpolicyagent.org/docs/latest/ Acesso em: 19 abr. 2026.
QUAY. Red Hat Quay Security Features. 2026. Disponível em: https://docs.quay.io/ Acesso em: 19 abr. 2026.
SNYK. Container Security Best Practices. 2025. Disponível em: https://snyk.io/learn/container-security/ Acesso em: 19 abr. 2026.
SYFT. Anchore Syft Documentation. 2026. Disponível em: https://github.com/anchore/syft Acesso em: 19 abr. 2026.
TETRAGON. Cilium Tetragon Documentation. 2026. Disponível em: https://tetragon.cilium.io/ Acesso em: 19 abr. 2026.
TRIVY. Aqua Trivy Documentation. 2026. Disponível em: https://aquasecurity.github.io/trivy/ Acesso em: 19 abr. 2026.
TWISTLOCK/PALO ALTO. Cloud Native Application Protection Platform Concepts. 2025. Disponível em: https://www.paloaltonetworks.com/cnapp Acesso em: 19 abr. 2026.
WILLIAMS, K.; LI, H. Container Escape and Kernel Attack Surface Analysis. 2024. Disponível em: https://www.kernel.org/doc/html/latest/ Acesso em: 19 abr. 2026.
CILIUM. Cilium Network Policy and Identity. 2026. Disponível em: https://docs.cilium.io/en/stable/security/policy/ Acesso em: 19 abr. 2026.
GATEKEEPER. OPA Gatekeeper Documentation. 2026. Disponível em: https://open-policy-agent.github.io/gatekeeper/website/docs/ Acesso em: 19 abr. 2026.
KYVERNO. Kyverno Policy Engine Documentation. 2026. Disponível em: https://kyverno.io/docs/ Acesso em: 19 abr. 2026.
AQUA. Container Security Threat Research. 2025. Disponível em: https://www.aquasec.com/resources/ Acesso em: 19 abr. 2026.