コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み

コンテナイメージのスキャン、IaCのセキュリティチェック、CI/CDへのセキュリティゲート——これらのシフトレフト（Shift Left）による対策をすべて実施していても、防ぎきれない脅威があります。コンテナが実際に稼働している「ランタイム」の瞬間に発生する攻撃です。

Teslaのクラウド環境がKubernetes侵害を受けた事例が示すように、攻撃者はアプリケーションコードのゼロデイを突いたのではなく、設定ミスのあるコンテナインフラ・露出した認証情報・不十分なランタイム制御を連鎖的に悪用しました。ワークロードは正常に稼働していましたが、その中で何が起きているかを把握できていなかったのです。

本記事では、コンテナランタイムセキュリティの本質、OSSのFalcoがどのようにリアルタイム検知を実現しているか、最新の回避攻撃（Syscall Evasion、システムコール回避）への対応、そしてSysdig SecureによるFalcoの商用拡張まで、技術的に深掘りして解説します。コンテナセキュリティの全体像については「コンテナセキュリティとは？クラウドネイティブ時代に必要な対策の全体像」をあわせてご参照ください。

コンテナランタイムセキュリティとは何か

「ランタイム」とはコンテナが稼働している瞬間のこと

コンテナのライフサイクルは「ビルド → デプロイ → 稼働（ランタイム）→ 停止・破棄」という流れで進みます。シフトレフトが対象とするのはビルド・デプロイの段階です。

ランタイムセキュリティはその後——コンテナが実際に動いている瞬間——を守る防衛線です。

コンテナランタイムの観点から整理すると、runCやcontainerd・CRI-OといったOCI（Open Container Initiative）準拠のランタイムがLinuxのcgroupsとnamespaceを活用し、各コンテナにプロセス・ネットワーク・ファイルシステムの分離を提供しています。しかしすべてのコンテナはホストOSのカーネルを共有しているため、カーネルレベルの脆弱性が悪用されれば、その分離は突破されます。

‍

ランタイムセキュリティとは、この「コンテナが動いている瞬間」に発生するあらゆる異常挙動——不審なプロセス起動・異常なファイルアクセス・想定外のネットワーク通信・権限昇格の試み——をリアルタイムで検知し、即時に封じ込める仕組みです。

なぜシフトレフトだけでは防げないのか

ビルド時スキャンが生成するCVEリストには、イメージ内に存在はするものの実際にはメモリにロードされることも実行されることもないライブラリに関する検出結果が多数含まれています。従来の脆弱性管理はすべてのCVEを同等に扱い、チームに膨大な対応コストを強いてきました。

‍

さらに根本的な問題として、ビルド時点でクリーンだったイメージも、稼働中に以下のリスクが発生します。

• レジストリ保管中に新たなゼロデイ脆弱性が公開される
• 攻撃者がコンテナに侵入後、実行時に悪意あるバイナリやツールをダウンロード・実行する（コンテナドリフト）
• KubernetesのService Accountを悪用したクラスタ内横断侵害（ラテラルムーブメント）
• AIエージェントがプロンプトインジェクションにより意図しない操作を実行する

Sysdigが提唱する555ベンチマーク（5秒以内の検知、5分以内のトリアージ、5分以内の対応）は業界最速水準の指標ですが、それでも侵害が数秒で完結するケースには「検知してから対応する」アプローチ自体が追いつかないことがあります。ランタイムで検知した瞬間、すでに認証情報が窃取されていたり横断侵害が始まっていたりするケースが現実に存在します。だからこそシフトレフト（第一の防波堤）とシールドライト、ランタイムセキュリティ（第二の防衛線）の両輪が不可欠です。

シフトレフトによるビルド時対策の詳細については「シフトレフトとは？コンテナセキュリティをCI/CDに組み込む実践ガイド」をご参照ください。

システムコール（Syscall）監視がランタイムセキュリティの核心

システムコールとは何か

プロセスがOSカーネルに対して行うすべての操作要求を「システムコール（Syscall）」と呼びます。ファイルへの読み書き・ネットワーク通信の確立・新しいプロセスの起動・メモリの確保——コンテナ内部で発生するあらゆる挙動は、最終的にシステムコールとして表れます。

‍

アプリケーションのログやネットワークメタデータは攻撃の「結果」しか見えませんが、システムコールを監視すれば攻撃の「行為そのもの」をカーネルレベルでリアルタイムに捕捉できます。これがコンテナランタイムセキュリティにおいてシステムコール監視が最重要視される理由です。

システムコール回避攻撃（Syscall Evasion）——「見えない」攻撃の台頭

従来のランタイムセキュリティツールはシステムコールの監視を前提として設計されています。しかし近年、この前提を突く「Syscall Evasion（システムコール回避攻撃）」が急増しています。

最も注目すべき手法がio_uringの悪用です。io_uringはLinuxカーネルに組み込まれた非同期I/O機構で、本来はディスク・ネットワーク操作を高速化するために設計されました。しかし攻撃者はio_uringを通じて従来のSyscall監視フックをバイパスし、ファイルアクセスやネットワーク通信を「見えない」形で実行できることが実証されています。2025年にはio_uringを活用したPoC（概念実証）ルートキットが公開され、CrowdStrike・Tetragon・Falco（OSS版）が検知できないことが示されました。

他の主な回避手法としては以下が挙げられます。

• Direct Syscall / libcバイパス：標準Cライブラリ（libc）を経由せずにカーネルに直接Syscallを発行することで、libcフックベースの監視を回避する
• vDSOハイジャック：カーネルがユーザー空間にマップする仮想動的共有オブジェクト（vDSO）を悪用し、Syscall監視を欺く
• Living-off-the-land（LotL）：zshなどOSに標準搭載されたツールを悪用し、不審なバイナリのダウンロードを避けることで検知を困難にする
  
  

「標準的なツールでは見えない攻撃が存在する」ことを前提に、カーネルレベルでの深い可視化を持つツールを選択することが重要です。

AIワークロード環境でのSyscall Evasionリスクについては「AIワークロードのコンテナセキュリティ｜LLM・GPU環境を守る新しい視点」でも解説しています。

Falcoとは何か——OSSランタイムセキュリティの業界標準

FalcoがCNCFで果たす役割

Falcoは、CNCF（Cloud Native Computing Foundation）がホストするオープンソースのランタイムセキュリティプロジェクトです。元々Sysdigが開発し、2018年にCNCFに寄贈されました。現在はKubernetesと並ぶCNCFの主要プロジェクトとして、コンテナランタイムセキュリティのデファクトスタンダードとなっています。

関連するお知らせ：Cloud Native Computing Foundation (CNCF) がFalcoを『卒業』プロジェクトに認定

Falcoの核心はLinuxのシステムコールをリアルタイムで監視し、定義済みのルール（Falco Rules）に基づいて異常な挙動を即座に検知する点にあります。クラウドプロバイダーが提供するログベースの監視やサンプリングされたメトリクスとは根本的に異なり、Falcoはカーネルレベルで発生するすべての挙動を逃さず捕捉します。

Falcoのルールエンジンの仕組み

Falco Rulesは「condition（検知条件）」と「output（アラート出力）」で構成されたYAML形式のルールセットです。conditionはコンテナ内のプロセス・ファイル・ネットワークに関するシステムコールのフィルタリング条件を定義し、条件に合致した場合にoutputに指定したフォーマットでアラートが出力されます。

代表的なFalcoルールの例を挙げます。

• コンテナ内でbash・shが起動された：正規のアプリケーションコンテナではシェルが起動することはないため、攻撃者のインタラクティブシェル取得の試みとして検知
• 想定外のIPアドレスへのアウトバウンド通信：コンテナが既知のエンドポイント以外に通信を確立した場合、C&Cサーバーへの接続として検知
• privilegedコンテナからのホストファイルシステムへのアクセス：コンテナエスケープの試みとして検知
• 本番コンテナへの新規バイナリのダウンロード・実行：コンテナドリフトとして検知

Falco Rulesはカスタマイズ可能です。環境固有の正常な挙動（例：特定のコンテナが定期的に外部APIを呼び出す）をホワイトリスト化することで、ノイズを削減し検知精度を高めることができます。

OSS版Falcoが抱える現実的な課題

Falcoはランタイムセキュリティの標準ツールとして非常に強力ですが、組織規模での運用には現実的な課題があります。

• YAML管理の複雑化：コンテナ数・サービス数が増えるほどルールのメンテナンス工数が増大し、誤検知のチューニングに多くの時間が費やされる
• io_uringへの対応遅延：最新のSyscall Evasion攻撃手法に対して、OSS版のルール更新が後手に回るケースがある
• アラートのノイズ問題：デフォルトルールのままでは膨大な数のアラートが発生し、SREチームがアラート疲れに陥るリスクがある
• 自動応答機能の欠如：不審な挙動を検知しても自動でコンテナを隔離・プロセスを停止する機能は標準では提供されておらず、別途実装が必要

SREチームがOSS版Falcoだけで大規模な本番環境を運用するには、相当なエンジニアリング工数とFalcoルールの深い知識が求められます。

eBPFがランタイムセキュリティを変えた理由

eBPFとは何か

eBPF（extended Berkeley Packet Filter）は、Linuxカーネル内で安全にプログラムを実行できる革新的な仕組みです。カーネルのソースコードを変更したり、危険なカーネルモジュールをロードしたりすることなく、システムコール・ネットワークパケット・プロセスの挙動をカーネルレベルでリアルタイムにトレースできます。

‍

従来のカーネルモジュールベースの監視手法と比較したeBPFの優位性は3点です。第1に、カーネル内で直接動作するため処理オーバーヘッドが最小限に抑えられます。第2に、eBPFプログラムはカーネルにロードされる前に安全性が検証されるため、カーネルクラッシュのリスクが大幅に低減されます。第3に、io_uringを含む広範なカーネルイベントを捕捉できるため、システムコール回避攻撃への対応できます。

eBPFによってできること・注意すべき点

eBPFを活用したランタイムセキュリティツールは以下を実現します。

• io_uringを含む広範なシステムコールの捕捉：従来の監視フックをバイパスする攻撃手法にも対応
• コンテナ・プロセス・ネットワークの完全なトレース：「どのコンテナの・どのプロセスが・どのファイルを触り・どの通信を行ったか」をワークロード単位で把握
• 最小オーバーヘッド：本番環境のパフォーマンスへの影響を抑えながらカーネルレベルの可視性を実現

一方で注意すべき点もあります。eBPF自体も実装品質によって見落としが生じる可能性があります。深い可視化を実現するためには、eBPFドライバーの設計と継続的なメンテナンスの品質が問われます。Sysdigは長年にわたりeBPFの実装に投資しており、io_uringなどの最新の回避攻撃にも対応した深いカーネル可視化を提供しています。

ランタイムセキュリティで検知できる主な攻撃パターン

実際の本番環境でランタイムセキュリティが検知する攻撃パターンを整理します。これらはShift Leftだけでは対応できない、ランタイム固有のリスクです。

コンテナドリフト（Drift Detection）

イミュータブルなコンテナの原則は「デプロイ後は変更なし」です。本番コンテナに本来存在しないはずのバイナリが実行された状態を「コンテナドリフト」と呼びます。攻撃者がコンテナに侵入した後、curlやwgetを使って攻撃ツールをダウンロード・実行するパターンが典型例です。

‍

コンテナドリフトの検知はランタイムセキュリティの最も基本的かつ効果的な機能です。デプロイ時のイメージから逸脱した挙動を即時に検知し、自動的にそのバイナリの実行をブロックすることで、侵害の連鎖を早期に断ち切ります。

C&Cサーバーへの不審な通信

コンテナへの侵害後、攻撃者は外部のCommand & Control（C&C）サーバーへの通信チャネルを確立しようとします。正規のアプリケーションが通信するエンドポイントは事前に把握できるため、想定外のIPアドレス・ドメインへのアウトバウンド通信はFalcoルールで即座に検知できます。

権限昇格・横断侵害（ラテラルムーブメント）

privilegedモードで起動したコンテナからのホストファイルシステムへのアクセス・Kubernetes APIへの不審な呼び出し・ServiceAccountトークンを悪用したクラスタ内横断——これらはコンテナ侵害後の典型的な攻撃連鎖です。ランタイムセキュリティはシステムコールレベルでこれらの試みを捕捉し、被害が拡大する前にアラートと自動応答を実行します。

AIワークロード特有のランタイムリスク

LLMコンテナ内での異常なAPIコール・想定外のファイルアクセス・AIエージェントのプロセスが予期しないバイナリを実行した場合も、システムコールレベルで検知できます。「正常な推論処理のシステムコールパターン」をベースラインとして定義し、逸脱を検知する設計が特に有効です。

AIワークロード固有のランタイムリスクの詳細については「AIワークロードのコンテナセキュリティ｜LLM・GPU環境を守る新しい視点」をご参照ください。

Sysdig Secure：FalcoをCNAPPへと発展させた商用プラットフォーム

Sysdig SecureはOSS Falcoの開発元として、FalcoのランタイムセキュリティエンジンをコアとしつつCWPPおよびCNAPPの機能群を統合した商用プラットフォームです。OSS版Falcoとの差分は以下の4点に集約されます。

1.io_uring対応：Syscall EvasionをカバーするeBPFドライバー

SysdigはeBPFドライバーの深い実装投資により、io_uringを悪用したSyscall Evasion攻撃に対応しています。OSS版のFalcoでは検知できないケースがある最新の回避手法にも、Sysdig独自のDeep Kernel可視化で対処します。eBPFベースのインストルメンテーションはシステムコール・プロセス・ファイルアクセス・ネットワークアクティビティを最小限のオーバーヘッドで監視します。

2. Runtime Insightsによるノイズ削減と脆弱性優先度の精度向上

Sysdig SecureのRuntime Insightsは、本番環境で「実際に動いているパッケージ」の情報をイメージスキャン結果と掛け合わせます。ディスク上に存在はするがメモリにロードされることのないライブラリ・到達不能なコードパスのCVEを自動的に優先度を下げることで、脆弱性アラートのノイズを最大98%削減できます。これにより「Critical件数1,000件」が「対応必須10〜20件」に絞り込まれ、SREチームは本当に危険なリスクに集中できます。

3.自動応答：検知から封じ込めまでの時間を短縮

OSS版Falcoは検知とアラートに特化していますが、Sysdig Secureは検知後の自動応答機能を統合しています。

• Drift Control：本番コンテナへの不審なバイナリの実行を自動ブロック
• プロセス強制終了：C&C通信を確立しようとするプロセスを自動停止
• ネットワーク遮断：侵害されたコンテナのネットワークアクセスを即座に遮断
• フォレンジック証跡の自動保全：コンテナが破棄される前にSCAPキャプチャでシステムコールレベルの証跡を保存

4.Falco Feedsとフォレンジック機能

Sysdig TRT（Threat Research Team）が継続的に分析する最新脅威インテリジェンスは、Falco Feedsとして自動配信されます。LLMjacking・io_uring悪用・新しいコンテナエスケープ手法に対応したFalcoルールが常に最新状態に保たれるため、セキュリティチームが個別にルールをメンテナンスする工数を大幅に削減できます。

フォレンジック面では、コンテナが破棄された後も「いつ・どのプロセスが・何をしたか」を事後的に再現できるSCAPキャプチャ機能が、インシデント調査を「数時間から数分」に短縮します。ビルド時のSBOM・署名・来歴情報と組み合わせることで、ランタイムの検出結果を特定のイメージ・レイヤー・ソースコンポーネントまで遡って追跡できます。

5.Sysdig Sage™によるAI支援

Sysdig Sage™は検知されたインシデントの深刻度判定・根本原因の特定・対応手順の提案をAIが自動サポートします。複雑なシステムコールのトレースを手動解析することなく、重大インシデントへの対応に集中できる環境を提供します。

Sysdig SecureのCWPP・CNAPP機能の全体像については「コンテナセキュリティとは？クラウドネイティブ時代に必要な対策の全体像」のSysdig Secureセクションをご参照ください。

ランタイムセキュリティの運用設計：SREが押さえるべきポイント

正常な挙動のベースライン定義

効果的なランタイムセキュリティの前提は、「何が正常か」を定義することです。各コンテナ・各サービスにおける正常なシステムコールパターン・通信先・プロセス起動のプロファイルをあらかじめ把握しておくことで、逸脱を「異常」として精度高く検知できます。新しいサービスを本番投入する際には、プロファイリング期間を設けてベースラインを確立することが推奨されます。

アラートレベルの設計とオンコール連携

すべてのFalcoアラートをオンコールに飛ばすことはSREチームのアラート疲れを引き起こします。深刻度に応じた3段階の設計が効果的です。

• Critical（即時対応）：コンテナエスケープの試み・権限昇格・C&C通信の確立——PagerDutyなどで即時ページング
• Warning（翌営業日対応）：想定外のネットワーク通信・ドリフト検知——Slackチャンネルへの通知
• Info（記録のみ）：正常範囲内の軽微な逸脱——ダッシュボードへの記録のみ

自動応答（Drift Controlによるバイナリブロック・ネットワーク遮断）との組み合わせにより、オンコール前に初動対応を自動化することでMTTRを大幅に短縮できます。

アラート設計の詳細については「SREのアラート疲れを終わらせる：Critical脆弱性50件から本当に直すべきリスクを特定する方法」をご参照ください。

ランタイムインサイト（Runtime Insights）をシフトレフトにフィードバックする「閉じたループ」

ランタイムセキュリティとシフトレフトは別々に機能するのではなく、フィードバックループを形成することで真の価値を発揮します。本番環境で「実際に動いているパッケージ」の情報をCI/CDパイプラインのイメージスキャンにフィードバックすることで、スキャン結果の優先度精度が飛躍的に向上します。「ビルド時にシグナルを取り、ランタイムで検証し、次のビルドに反映する」という継続的な信頼のループが、コンテナセキュリティを本当に機能させます。

‍

このフィードバックループの具体的な実装については「シフトレフトとは？コンテナセキュリティをCI/CDに組み込む実践ガイド」をご参照ください。

まとめ｜「見えない」を「見える」にすることがランタイムセキュリティの本質

コンテナランタイムセキュリティとは、コンテナが稼働している瞬間に発生するあらゆる脅威をカーネルレベルで可視化し、リアルタイムに検知・封じ込める仕組みです。本記事のポイントを整理します。

• シフトレフト（ビルド時対策）だけでは防げないランタイム攻撃が現実に存在する
• システムコール監視がランタイムセキュリティの核心であり、FalcoはそのOSSデファクトスタンダード
• io_uringを悪用したSyscall Evasionなど、標準ツールでは「見えない」攻撃への対応にはeBPFの深い実装が必要
• OSS版FalcoはSREの運用現場では管理コスト・ノイズ問題・自動応答の欠如という課題がある
• Sysdig Secureはio_uring対応・98%ノイズ削減・自動応答・フォレンジック・AI支援を統合し、FalcoをCNAPPレベルに発展させたプラットフォーム

「見えないものは守れない」——この原則の下、システムコールレベルの深い可視化を起点としたランタイムセキュリティの構築が、クラウドネイティブ時代の防御の要です。

関連記事

• コンテナセキュリティとは？クラウドネイティブ時代に必要な対策の全体像
• シフトレフトとは？コンテナセキュリティをCI/CDに組み込む実践ガイド
• AIワークロードのコンテナセキュリティ｜LLM・GPU環境を守る新しい視点
• SREのアラート疲れを終わらせる：Critical脆弱性50件から本当に直すべきリスクを特定する方法
• AWS/GCP標準ツールでは守れない？Falcoを超えるSysdig Secureによるセキュリティの新常識
• CDR（Cloud Detection and Response）とは｜クラウドを守るリアルタイム防御とSysdigのアプローチ

‍