< 一覧に戻る

コンテナエスケープを検知・防止する方法

現代のアプリケーションはコンテナ上に構築されており、企業は重要な生成AIワークロードの実行にもコンテナを活用しています。そのため、セキュリティチームはコンテナエスケープとは何か、そしてそれをどのように軽減すべきかを理解しておく必要があります。

Published Date: Jul 07, 2026
この記事の内容
This is the block containing the component that will be injected inside the Rich Text. You can hide this block if you want.
Hassaan qaiser bKfkhVRAJTQ unsplash

なぜコンテナエスケープは重大なセキュリティ問題なのか?

クラウドにおけるコンテナの利用は拡大を続けています。2025年のCNCF調査によると、本番環境のアプリケーションにコンテナを利用している組織は約56%に達し、2023年の41%から増加しました。多くのユーザーはKubernetesと組み合わせてコンテナをデプロイしており、66%の組織が生成AIワークロード向けにKubernetesを活用しています。

コンテナの普及が進む中、脅威アクターがそれを標的にするのは驚くことではありません。例えば、2025年にはruncの3件の脆弱性が公開され、攻撃者はこれを利用してホストシステムへのroot権限を取得できる状態になっていました。

仮想マシン(VM)とは異なり、コンテナはホストのカーネルを共有しています。これによりコンテナは軽量になり、短命なワークロードに適していますが、同時にカーネルレベルのエクスプロイトに対して脆弱にもなります。

悪意のあるアクターが利用できるコンテナへの攻撃の一つが、コンテナエスケープと呼ばれるものです。ここでは、コンテナエスケープとは何かを掘り下げ、その検知方法と防止方法について解説します。

コンテナエスケープとは?

コンテナエスケープとは、脅威アクターが脆弱性、設定ミス、または権限を利用して単一のコンテナから脱出し、ホストや他のコンテナのリソースへ不正にアクセスすることを指します。

コンテナとVMは、いずれもワークロードをホストサーバーから分離しますが、VMがハードウェアレベルの分離を提供するのに対し、コンテナが提供するのはアプリケーションレベルの分離のみです。

通常、コンテナが侵害されても、攻撃者がアクセスできるのはその単一のコンテナ内のリソースに限られます。しかし、コンテナエスケープが発生すると、攻撃者はサーバー全体、あるいはそれ以上の範囲にまでアクセスできる可能性があります。

コンテナエスケープは、脅威アクターがアプリケーションの脆弱性、盗んだ認証情報、またはサプライチェーン攻撃を利用してコンテナへの最初のアクセスを獲得することから始まります。そこから、コンテナやコンテナランタイムにある過剰な権限、脆弱性、設定ミスを特定し、脱出を試みます。

例えば、CVE-2025-31133は、runcがmaskedPaths機能を実装する方法に存在する脆弱性であり、攻撃者が任意のホストパスをマウントし、重要なファイルに書き込むことを可能にする可能性があります。

脅威アクターがコンテナからのエスケープに成功すると、ホストの侵害、クラスターの乗っ取り、機密データへのアクセス、そしてサーバーやインフラ内での横方向への移動といった攻撃を実行できるようになります。

よく見られる6つのコンテナエスケープ手法

脅威アクターがコンテナエスケープを試みる際の手法は数多く存在します。よく見られるコンテナエスケープの手法には、以下のようなものがあります。

  • 過剰なケーパビリティ:これは、プロセスが実行できるアクションを定義する、昇格されたLinuxケーパビリティをコンテナで実行できるようにすることを指します。例えば以下のようなものがあります。
    • SYS_ADMIN:ファイルシステムのマウントを許可し、実質的にホストへのroot権限を与えてしまいます。
    • SYS_PTRACE:デバッグ用にptrace()の使用を許可しますが、プロセスインジェクションに利用される可能性があります。
    • SYS_MODULE:プロセスによるカーネルモジュールのロード・アンロードを許可し、セキュリティの回避や悪意のあるカーネルモジュールの注入に利用される可能性があります。
  • 特権コンテナ:特権コンテナはroot権限とホストデバイスへのアクセス権を持ちます。コンテナに--privilegedフラグが設定されている場合、そのコンテナは実質的にホスト上でrootとなります。また、KubernetesのセキュリティコンテキストでallowPrivilegeEscalationの設定を誤ると、プロセスがより多くの権限を取得できてしまいます。
  • ホストファイルシステムのマウント:不適切なマウントやdocker.sockの悪用により、攻撃者はホストのファイルを改変したり、ホストへエスケープしたり、マルウェアをインストールしたりして、ホスト全体を完全に乗っ取ることができます。
  • カーネルの脆弱性:攻撃者はLinuxカーネルの脆弱性を悪用して、ネームスペースによる分離から脱出します。例としては、Dirty Pipe、Dirty Cow、OverlayFSの脆弱性などが挙げられます。
  • コンテナランタイムの脆弱性:攻撃者は、runc、containerd、Dockerなどにある脆弱性を利用して、root権限を取得したり、悪意のあるコードを実行したり、コンテナの分離から脱出したりします。
  • コンテナランタイムAPIの悪用:攻撃者は、適切なアクセス制御が欠けていたり、暗号化されていない通信を使用していたりする、インターネットに公開されたDocker APIやKubernetes Kubelet APIを見つけ出します。

コンテナエスケープを検知する方法

脆弱性や設定ミスに対する静的スキャンといった従来のセキュリティ対策は、セキュリティ体制の観点から依然として重要です。しかし、こうした対策は、絶えず起動・停止される一時的なワークロードの保護には不向きです。

コンテナエスケープを検知するには、コンテナランタイムセキュリティを用いて、不審または異常な動作をリアルタイムで監視し、迅速に対応する必要があります。コンテナセキュリティツールが注視すべき具体的な動作には、予期しないシステムコール、ファイルアクセス、プロセスなどが含まれます。

目標は、開発環境でのSYS_ADMINの使用ではなく、本番環境でコンテナがAppArmorを無効化しようとするといった、予期しない動作を検知することです。

その動作が無害なものなのか、それともコンテナエスケープの試みを示すものなのかを判断するためには、動作に関するコンテキストを把握することが重要です。通常のコンテナの動作は、アプリケーションに関連したシステムコールが中心です。

一方、不審なシステムコールの動作には以下のようなものがあります。

  • Nsenter:ホスト上の別のプロセスとして、ネームスペース内でコマンドを実行します。
  • unshareおよびsetns:新しいネームスペースを作成する、または既存のネームスペースに参加します。
  • chmod:ファイルのアクセス権限を変更します。
  • mountおよびumount:ファイルシステムをマウントまたは解除します。
  • pivot_root:ルートファイルシステムを変更します。

その他の予期しない動作としては、コンテナが/procや/sys、/var/lib/kubelet、/etc/shadow、/rootといった機密性の高いhostPathへアクセスを試みるケースが挙げられます。SYS_ADMIN、SYS_MODULE、SYS_PTRACEといったケーパビリティの取得を試みるプロセスにも注意が必要です。

その他に監視すべき動作としては、コンピューティングリソース使用量の増加、外部へのネットワーク接続、予期しないパッケージのインストール、予期しないシェルの起動などがあります。

アラートを受け取った後、コンテナの不審なアクティビティを調査する際は、以下の6つのステップに従いましょう。

  1. 不審なプロセスを監視・特定する。
  2. プロセスツリーを追跡する。
  3. ネームスペースの変更を確認する。
  4. コンテナのマウント状況を確認する。
  5. ホストへの変更がないか分析する。
  6. 侵害されたコンテナを一時停止または停止する。

コンテナエスケープを防止する方法

設定ミスや脆弱性が見逃されてしまった場合に、どのような動作を監視すべきかを理解したところで、次はコンテナエスケープを防止するためのベストプラクティスを導入する必要があります。

1. 強固なアクセス制御を導入する

root権限の存在は、厳密に管理された数少ないケースのみに限定しましょう。ほとんどのユーザーは、コンテナをrootや特権モードで実行する必要はありません。

最小権限の原則(PoLP)を導入し、不要なケーパビリティをすべて削除(--cap-drop all)した上で、必要なケーパビリティのみを再度追加することで、攻撃対象領域を限定し、権限昇格の試みを減らしましょう。

Kubernetesでは、セキュリティコンテキストでrunAsUserを設定し、ユーザーネームスペースを有効化し、allowPrivilegeEscalationフラグを無効にしましょう。Dockerでは、--security-opt=no-new-privilegesを使用し、Dockerfile内でUserを有効にしましょう。

アクセス制御を導入し、それを徹底するだけで、コンテナエスケープにつながる多くの攻撃ベクトルを制限できます。

2. 多層防御のセキュリティ戦略を導入する

強固なセキュリティを実現するには、悪意のあるアクターから機密データやユーザーを保護するために、複数のツール、戦術、技術を組み合わせる必要があることが多くあります。

まずは、安全なコンテナオーケストレーション戦略を設計することから始めましょう。コンテナをどの程度分離すべきかを決定する、安全なコンテナランタイムを使用する、サードパーティ製プラグインの採用について検討するといったことがポイントになります。

そこから、以下の導入を検討しましょう。

  • アドミッションコントローラー:Kubernetes APIサーバーへのリクエストを評価し、ポッドセキュリティポリシーを適用するなどして、セキュリティを強化します。
  • AppArmor:カスタマイズ可能なプロファイルを使用することで、コンテナ内のケーパビリティを制限できます。
  • Seccomp:seccompプロファイルを使って定義することで、コンテナ内で実行可能なアクションを制限できます。
  • SELinux:ラベリングを通じてホストリソースへのアクセスに関するポリシーを適用する、柔軟な強制アクセス制御を提供します。
  • ネットワークセグメンテーション:ネットワークをより小さなセグメントに分割することで横方向への移動を制限し、Network Policiesを使ってコンテナ間通信をきめ細かく制御します。
  • Kubernetes Podセキュリティ標準ポリシーレベルを使用して、privileged(特権)からbaseline(基準)、restricted(制限)まで、コンテナのポリシーを定義します。

プロセスがseccompやAppArmorを無効化しようとしているのを検知するだけでも、コンテナを注意深く監視したり隔離したりするなど、さらなる対応を行うに十分な不審な兆候となります。

3. 脆弱性管理を徹底する

脆弱性管理を導入することは、多くのコンテナエスケープを防ぐ上で大いに役立ちます。存在するすべての重大な脆弱性に対応する必要はありません。代わりに、本番環境に影響を与える可能性のあるものに焦点を当てましょう。

例えば、runcのようなオーケストレーションツールに定期的にパッチを適用・更新することで、CVE-2025-31133、CVE-2025-52565、CVE-2025-52881を防ぐことができます。これらの脆弱性は、悪意のあるアクターがマウントを攻撃することを可能にするものです。

ただし、コンテナランタイムとしてruncの代わりにcontainerdやDockerを使用している場合、これらの脆弱性は認識しておくべきものではあるものの、必ずしも過度に心配する必要はありません。文脈に応じたリスク情報を含む脆弱性管理を行うことで、どこに力を注ぐべきかを判断しやすくなります。

4. コンテナイメージを強化し、スキャンする

コンテナイメージの脆弱性は、常に存在するセキュリティリスクです。イメージを常に最新の状態に保ち、安全性を確保し、正しく構成しておくことが重要です。

コンテナスキャンは、イメージが新しいコンテナの作成に使用される前に、既知の脆弱性や設定ミスを検知するのに役立ちます。また、コンテナエスケープを可能にしてしまう脆弱性や設定ミスを発見するために、ホストのオペレーティングシステムもスキャンすべきです。

スキャンと併せて、ソフトウェア部品表(SBOM)を使用し、コンテナイメージで使用されているすべてのコンポーネントと依存関係を把握しましょう。これは、脆弱性管理の迅速化にもつながります。

ユーザーがrootや特権モードで実行できないことを確認するため、イメージの構成を定期的に見直しましょう。また、イメージの出所を保証するために、暗号学的ハッシュを用いてコンテナイメージに署名しましょう。

5. hostPathマウントを制限する

hostPathボリュームをコンテナにマウントすると、ホストのファイルシステムへの無制限のアクセスが可能になり、攻撃者はこれを利用して機密ファイルにアクセスし、改変することができます。

通常のストレージにはPersistentVolumes(PV)やConfigMapsを使用してhostPathマウントを制限することで、この攻撃ベクトルを回避しましょう。鍵やパスワードなどの機密データには、Kubernetes Secretsを使用しましょう。

PodSecurityPolicyを使用し、allowedHostPaths: []によってhostPathの使用を制限しましょう。その他のセキュリティ対策としては、オープンポリシーエージェント(OPA)を使ってhostPathボリュームをブロックし、PoLPを適用することが挙げられます。

6. ランタイムセキュリティと監視を活用する

静的スキャンはコンテナやイメージの既知の脆弱性を発見するのに役立ちますが、コンテナランタイムの監視は、潜在的なコンテナエスケープの試みを検知する上で不可欠です。

ランタイム監視には、カーネルのテレメトリを分析し、不審または異常な動作を探すことが含まれます。例えば、オープンソースの脅威監視エンジンであるFalcoを使用すれば、SYS_ADMINケーパビリティのようなシステムコールを悪用しようとする動きなど、コンテナエスケープが検知された際にアラートを生成できます。

不変であるはずのクラウドワークロードは、ランタイム中に変化するはずがないため、変化があればコンテナドリフトの可能性を示す兆候となります。Falcoのようなセキュリティ監視ツールを使ってドリフトを検知し、コンテナが新しいバイナリを実行した場合にアラートを生成しましょう。

ファイル整合性監視(FIM)を導入し、重要なファイル、ファイルシステム、データベースなどへの変更が発生した際に検知できるようにしましょう。

Sysdigでクラウドワークロードを保護する

本番環境にコンテナを増やすほど、悪意のあるアクターがそれをシステムへの最初の侵入経路として狙う可能性が高まります。

機密データを保護し、コンプライアンスを維持し、攻撃対象領域を減らすためには、コンテナのアクティビティに対する深い可視性を持つことが重要です。

Sysdig CNAPPを使えば、すべてのクラウド資産を保護する包括的なクラウドセキュリティソリューションを手に入れることができます。Sysdigは、事業のスピードを落とすことなく、クラウドの脅威を迅速に検知・対応することを支援します。

FAQs

セキュリティ専門家とともに、
クラウドを防御する正しい方法を試してみよう