Falcoによるコンテナランタイムセキュリティ監視の本番導入｜ルール調整と誤検知抑制フロー

なぜ今、Falcoがコンテナ監視の現場で選ばれるのか

コンテナワークロードが本番環境の主役になるにつれ、「何かおかしいことが起きているとき、それをリアルタイムで検知できるか」という問いへの答えが求められるようになりました。イメージスキャンやポリシーエンジンは「デプロイ前の静的防御」ですが、実行中のコンテナが予期しない挙動をとった場合には機能しません。そこで注目されるのが、カーネルシステムコールレベルでコンテナの振る舞いを監視するFalco（CNCF Graduated Project）です。

Falcoは2026年現在、CNCF のGraduatedプロジェクトとして安定版をリリースし続けており、Kubernetes環境での採用事例は大きく増えています。一方で「導入してみたら誤検知が多くて運用が回らなくなった」「デフォルトルールの意味が理解できず調整できない」という声も現場では聞かれます。本記事では、導入手順だけでなく、本番稼働に至るまでのルール調整と誤検知抑制のフローを実務ベースで整理します。

Falcoのアーキテクチャと2026年時点の動作モード

Falcoはカーネルイベントを取得するドライバー層と、取得したイベントをルールセットと照合するエンジン層の2層構成です。ドライバーには従来のカーネルモジュール（kmod）、eBPFプローブ（旧来のbpfドライバー）、そして現在推奨されている「Modern eBPF」の3種があります。

2026年時点の主流は Modern eBPF です。カーネル 5.8 以上であれば追加モジュールのコンパイル不要で動作し、ランタイム時のカーネルヘッダーも不要になりました。RHELやUbuntu 22.04以降のディストリビューションで利用できる環境が広がっており、運用コストの観点からも kmod よりも Modern eBPF が選ばれるケースが増えています。Falco 0.38 以降ではHelmチャートのデフォルトドライバーも Modern eBPF に切り替わっています。

アーキテクチャを理解しておくことは、誤検知調整の際に「どのシステムコールが問題のトリガーになっているか」を読み解くうえで不可欠です。

Kubernetes環境へのFalcoインストール手順（Helm使用）

本番Kubernetes環境への導入には、公式Helmチャートを使う方法が最もメンテナビリティに優れています。以下の手順を参考にしてください。

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

helm install falco falcosecurity/falco \
  --namespace falco \
  --create-namespace \
  --set driver.kind=modern_ebpf \
  --set falcosidekick.enabled=true \
  --set falcosidekick.webui.enabled=true

falcosidekickは、Falcoのアラートイベントを Slack・PagerDuty・Elasticsearch など多様なバックエンドへ転送するコンポーネントです。本番環境では必ず組み合わせて導入することを推奨します。Falco単体では標準出力へのロギングしかできないため、アラートの見落としが発生しやすくなります。

インストール後、DaemonSetのPodが全ノードでRunningになっていることを確認します。

kubectl get pods -n falco -o wide

各Podのログに Falco initialized. Ready to catch syscall events が出力されれば、監視は開始されています。

ルール調整のフロー：誤検知を根本から減らす考え方

Falcoのデフォルトルールセットは汎用的に設計されているため、特定のワークロード（CIランナー・特権コンテナを使う監視エージェントなど）で大量の誤検知が発生するのは珍しくありません。誤検知を「アラートをミュートする」だけで対処すると、将来の真の脅威も見逃すリスクがあります。正しいアプローチは「なぜそのイベントが検知されたかを理解し、正当な操作を明示的に除外する」ことです。

Falcoのルールはfalco_rules.yamlと、ユーザーが上書きするfalco_rules.local.yamlの2ファイルで管理されます。デフォルトルールを直接編集するのではなく、local側でマクロやリストを上書きするのが基本です。

代表的な調整例として、Write below etcルール（/etc配下への書き込み検知）に自社の設定管理ツールを除外する場合を見てみましょう。

# falco_rules.local.yaml
- list: write_etc_allowed_processes
  items: [ansible-playbook, puppet, chef-client]
  override:
    items: append

- macro: write_etc_common
  condition: >
    (write_etc_allowed_processes) and
    not proc.name in (write_etc_allowed_processes)
  override:
    condition: append

override: items: appendは Falco 0.35 以降で導入されたマージ構文です。既存リストを置換せずに追記できるため、アップグレード時にカスタマイズが失われるリスクを低減できます。古いappend: true構文は非推奨となっているため、既存設定がある場合は移行を検討してください。

誤検知の調査と除外ルール作成の実践的な手順

誤検知が疑われるアラートを受け取った際の調査手順は以下のように進めます。

• アラートの詳細フィールドを確認する：proc.name（プロセス名）、container.image.repository（コンテナイメージ）、fd.name（対象ファイル/ソケット）、user.name などのフィールドを参照します。
• どのルールが発火したかを特定する：アラートのruleフィールドにルール名が入っています。そのルール定義をfalco_rules.yamlで検索し、条件式を読みます。
• 除外条件を最小スコープで記述する：「このイメージのこのプロセスがこのパスに書く場合のみ除外する」という粒度にします。広すぎる除外はルールを形骸化させます。
• ドライランで除外条件を検証する：falco --dry-run や falcoctl rule validate でルールファイルの構文チェックをしてから反映します。

Helmでの運用では、カスタムルールを ConfigMap として管理し、values.yamlのcustomRulesセクションで参照する構成が推奨されます。これによりGitOpsフローに乗せることができ、変更履歴の追跡が容易になります。

# values.yaml の customRules セクション例
customRules:
  my-custom-rules.yaml: |-
    - list: write_etc_allowed_processes
      items: [ansible-playbook]
      override:
        items: append

検証・切り戻しと運用上の注意点

ルール変更後の検証には、Falcoが提供するテストツールfalco-event-generatorが有効です。意図的に問題のある操作（例：シェルのスポーン、機密ファイルの読み取り）を実行し、期待するアラートが発火するかを確認します。

kubectl run event-generator \
  --image=falcosecurity/event-generator \
  --restart=Never \
  -- run syscall

除外条件を追加した場合は「除外対象のプロセスでアラートが出なくなること」と「除外対象外のプロセスでは引き続きアラートが出ること」の両面を確認します。片方だけでは過除外・過検知の見落としが発生します。

切り戻しはHelmのrollback機能で対応できます。

helm rollback falco 1 -n falco

本番運用上の注意点として以下の点を押さえておく必要があります。

• eBPFのCPUオーバーヘッド：高トラフィックなノードでは Modern eBPF であっても数%のCPU増加が観測されることがあります。導入前に負荷試験環境でベースライン計測を行うことを推奨します。
• ルールの肥大化防止：除外ルールが積み重なると、ルールセット全体の意味が把握しにくくなります。四半期ごとに不要な除外条件を棚卸しする運用ルールを設けると良いでしょう。
• Falcoのバージョンアップ対応：デフォルトルールはFalcoのマイナーバージョンアップで変更される場合があります。falcoctl artifact list でルールバージョンを確認し、変更差分を把握したうえでアップグレードします。
• アラートの優先度設計：FalcoのアラートにはCRITICALからDEBUGまで優先度があります。最初から全優先度を通知対象にすると運用担当者がアラート疲れを起こします。初期はWARNING以上のみ通知し、安定してからNOTICEに広げる段階的な展開が実態として多く見られます。

Falcoは「入れたら終わり」ではなく、ワークロードの変化に合わせてルールを継続的に育てるものです。その前提でGitOpsフローへの組み込みと定期レビューの体制を整えることが、本番稼働を長期的に維持する鍵になります。