【テクニカル・上級編】コンテナのログ監視と異常検知(Falcoの活用) – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

コンテナの「心臓」を撃ち抜く前に：Falcoによるランタイム防御の深淵

多くのエンジニアが「コンテナはイミュータブル（不変）である」という教条に安住している。しかし、現実のインシデント現場では、一度入り込まれたコンテナは「攻撃者の拠点」へと瞬時に変貌する。脆弱なアプリケーションのコードが、メモリ保護機構（ASLR等）をバイパスされ、攻撃者がシェルを奪取したその瞬間、コンテナの壁は無力化されるのだ。

本稿では、Sysdigが開発したオープンソースのランタイムセキュリティツール「Falco」を軸に、コンテナの「行動」をどう監視し、いかにして実戦レベルの異常検知を設計すべきかを論じる。

—

1. Falcoの核心：カーネルイベントの「視覚化」

Falcoの凄みは、eBPF（Extended Berkeley Packet Filter）を介して、OSカーネルのシステムコールを直接フックできる点にある。アプリケーションレベルのログ（syslogやstdout）は、攻撃者が権限を取得した時点で容易に改ざん・消去される。しかし、カーネルレベルのイベントは隠蔽が極めて困難だ。

攻撃者が execve システムコールを呼び出してシェルを起動しようとした瞬間、あるいは openat で /etc/shadow を読み取ろうとした瞬間に、Falcoはそれを捕らえる。これは単なるログ監視ではない。「実行されるべきではない挙動」を物理的に断つためのセンサーだ。

2. 現場で機能するFalcoルール設計の「作法」

デフォルトのルールセットは強力だが、そのままではノイズの海に溺れる。実務で重視すべきは、コンテナの「標準的動作」の定義だ。以下は、コンテナ内での予期せぬシェル実行を検知する設定例である。

# Falcoルール定義例: コンテナ内でのインタラクティブシェルの起動を検知
- rule: Unexpected Shell in Container
  desc: コンテナ内でシェルが実行された場合に通知する（デプロイ後、想定外の事態）
  condition: >
    spawned_process and container and
    proc.name in (bash, sh, zsh, ksh) and
    container.id != host
  output: >
    異常なシェル実行を検知 (user=%user.name container=%container.id
    image=%container.image.repository command=%proc.cmdline)
  priority: CRITICAL
  tags: [container, mitre_execution]

監査の観点：なぜ「優先度(Priority)」を絞るのか

現場のインシデントハンドラーは、一日千件の通知を受け取ると麻痺する。我々が守るべきは「システム全体の整合性」だ。CRITICAL なアラートは、即座にPagerDutyやWebhook経由でSOC（Security Operation Center）へ飛ばし、それ以外の低優先度アラートはSIEMで相関分析を行う、という明確なトリアージ基準を設ける必要がある。

3. 深層防御：メモリ挙動とシステムコールの相関

真の脅威者は、シェルを起動せずともメモリ上でペイロードを実行する（Fileless Malware）。ここを検知するには、mmap や mprotect といったシステムコールの頻度を監視するルールを組み込む必要がある。

特に、書き込み可能かつ実行可能（PROT_WRITE | PROT_EXEC）なメモリ領域を確保する挙動は、シェルコードの実行を強く示唆する。Falcoの最新のeBPFプローブを活用し、以下のようなシグナルを監視対象に加えるべきだ。

memfd_create: 匿名ファイルをメモリ上に作成し、そこにバイナリを展開する手法。
ptrace: 実行中のプロセスに介入し、コードを注入する挙動。

4. 次世代の防衛：耐量子とガードレイルの先へ

現在、我々が直面しているのは、生成AIのプロンプトインジェクションや、LLMを介したコード生成に伴う「意図しない脆弱性の混入」だ。Falcoのログは、CI/CDパイプラインにフィードバックされなければならない。

例えば、Falcoが「本番環境で不審な通信（connect syscall）が発生した」と検知した場合、そのコンテナを隔離するだけでなく、当該コンテナを生成したソースコードのコミットハッシュまで追跡する自動化フローを構築すべきである。

結論：要塞化は静的な作業ではない

コンテナの要塞化とは、Dockerfileに USER を指定することや、不要なパッケージを削ぎ落とすこと（Minimal Base Image）だけではない。「何が起きているか」をカーネルの深部で解像度高く捉え、異常を即座に「遮断」できるアーキテクチャこそが、現代のセキュリティアーキテクトに求められる防衛線だ。

Falcoは、ただの監視ツールではない。それは、攻撃者がコンテナの壁を突破しようとした際、その足元を掬うための「最後の防衛層」である。まずは、あなたの環境の syscall を眺めることから始めてほしい。そこに、システムの真実が隠されているはずだ。