eBPFランタイムセキュリティ実践ガイド：FalcoとTetragonでLinux・Kubernetesの脅威を検知・防御する方法

はじめに：なぜeBPFベースのランタイムセキュリティが必要なのか

正直なところ、従来のLinuxセキュリティ対策――ファイアウォール、SELinux/AppArmor、ログ監視――って、「予防」と「事後分析」にはかなり優れてるんですよね。でも、攻撃がまさに進行中の瞬間にリアルタイムで検知して対処するとなると、そこには明らかな限界がありました。

コンテナ環境やKubernetesクラスタが当たり前になった今、攻撃者が侵入してからマルウェアを実行するまでの時間はわずか数分。場合によっては数秒です。この現実に対応するには、カーネルレベルでシステムコールを監視して、異常な振る舞いをリアルタイムで捉えられる仕組みが不可欠なんです。

そこで注目されているのが、eBPF（extended Berkeley Packet Filter）を活用したランタイムセキュリティ監視です。eBPFはLinuxカーネル内部でサンドボックス化されたプログラムを実行できる技術で、カーネルの再コンパイルやモジュールの追加読み込みなしに、システムコール、ネットワーク通信、ファイルアクセスといったカーネルイベントを高性能かつ低オーバーヘッドで監視できます。2025年にはeBPF Foundationがカーネルセキュリティ強化のために228,200ドルの助成金を受け取っていて、JITコンパイルされたeBPFプログラムのメモリアクセス検証や各種JITコンパイラのセキュリティ監査が着実に進んでいます。

この記事では、eBPFベースのランタイムセキュリティ監視を実現する2大ツール――FalcoとTetragon――を徹底的に比較・解説していきます。それぞれのアーキテクチャから導入方法、カスタムルール/ポリシーの作り方、そしてKubernetes環境での実践的な運用まで。現場ですぐ使える内容を目指しました。

eBPFの基礎：カーネルレベルセキュリティ監視の仕組み

eBPFアーキテクチャの概要

eBPFを理解するには、まずその動作原理を押さえておく必要があります。

eBPFプログラムはユーザースペースで作成され、カーネルに読み込まれる前にベリファイア（verifier）による安全性チェックを受けます。このベリファイアが無限ループや不正なメモリアクセスがないことを静的に検証するので、カーネルの安定性を損なうリスクが極めて低いんですね。ここがカーネルモジュールとの大きな違いです。

検証を通過したeBPFプログラムは、JITコンパイラによってネイティブマシンコードに変換され、カーネル内の各種フックポイントにアタッチされます。主なフックポイントは以下のとおりです。

• kprobes / kretprobes：カーネル関数の入口・出口にアタッチし、関数の引数や戻り値を取得
• tracepoints：カーネルに事前定義された安定的なトレースポイント
• LSM（Linux Security Module）フック：セキュリティ判断が行われるポイントにアタッチし、アクセス制御を拡張
• XDP（eXpress Data Path）：ネットワークドライバレベルでパケット処理を行う超高速フック
• cgroup フック：コントロールグループ単位でのリソース制御・監視

CO-RE（Compile Once – Run Everywhere）

eBPFの実用化における大きなブレークスルーがCO-RE技術です。

従来のeBPFプログラムはカーネルバージョンごとにコンパイルし直す必要がありました。これ、運用する側からするとかなり面倒なんですよ。でもCO-REはBTF（BPF Type Format）情報を利用して、異なるカーネルバージョン間での構造体のレイアウト差異を自動的に解決してくれます。一度コンパイルすれば複数のカーネルバージョンで動く、というわけです。

FalcoのModern eBPFドライバとTetragonはどちらもCO-RE技術を採用しており、カーネルヘッダーのインストールやドライバのビルドが不要になっています。運用チームにとっては、導入コストの大幅な削減を意味しますね。

セキュリティ監視におけるeBPFの利点

eBPFベースのセキュリティ監視が従来の手法と比べて優れている点を整理してみましょう。

• 低オーバーヘッド：カーネル内で直接フィルタリングを行うため、ユーザースペースへの不要なデータ転送がなく、通常1%未満のCPUオーバーヘッドで動作
• カーネル改変不要：カスタムカーネルモジュールの開発・メンテナンスが不要
• 安全性：ベリファイアによる静的検証でカーネルパニックのリスクを排除
• 柔軟性：監視対象やフィルタリングロジックを動的に変更可能
• コンテナ対応：KubernetesのメタデータとPod名、Namespace、ラベルを自動的に関連付け可能

Falco：CNCFのランタイムセキュリティ標準

Falcoとは

Falcoは、Sysdig社が開発しCNCF（Cloud Native Computing Foundation）に寄贈されたオープンソースのランタイムセキュリティツールです。2024年にCNCFのGraduated（卒業）プロジェクトとなり、クラウドネイティブセキュリティの事実上の標準として広く採用されています。

個人的に、Falcoの一番の魅力はルールの書きやすさだと思っています。システムコールを中心に、Kubernetesの監査ログ、クラウドプロバイダのイベントなどを監視して、ルールベースで異常な振る舞いを検知してアラートを発報する仕組みです。

Falcoのドライバアーキテクチャ

Falco 0.38.0以降、3種類のドライバから選択できます。

• Modern eBPF（推奨・デフォルト）：CO-RE技術によりFalcoバイナリに組み込まれ、追加のビルドやダウンロード不要。カーネル5.8以上が必要
• eBPFプローブ：従来型のeBPFドライバ。カーネルヘッダーとclang/llvmが必要
• カーネルモジュール（kmod）：従来型のカーネルモジュール。古いカーネルでも動作するが、セキュリティリスクが高い

実運用では特別な理由がない限りModern eBPFドライバ一択です。CO-RE対応のカーネル（5.8以上+BTF情報付き）であれば、インストールするだけですぐ動きます。

Falcoのインストールと初期設定

Linuxホストへのインストール（Debian/Ubuntu）

# GPGキーとリポジトリの追加
curl -fsSL https://falco.org/repo/falcosecurity-packages.asc | \
  sudo gpg --dearmor -o /usr/share/keyrings/falco-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/falco-archive-keyring.gpg] \
  https://download.falco.org/packages/deb stable main" | \
  sudo tee /etc/apt/sources.list.d/falcosecurity.list

# インストールと起動
sudo apt-get update && sudo apt-get install -y falco
sudo systemctl enable falco && sudo systemctl start falco

# ステータス確認
sudo systemctl status falco
sudo falco --version

RHEL/CentOS/AlmaLinuxへのインストール

# リポジトリの追加
sudo rpm --import https://falco.org/repo/falcosecurity-packages.asc
sudo curl -fsSL -o /etc/yum.repos.d/falcosecurity.repo \
  https://falco.org/repo/falcosecurity-rpm.repo

# インストールと起動
sudo dnf install -y falco
sudo systemctl enable falco && sudo systemctl start falco

Kubernetesクラスタへのデプロイ

# Helmリポジトリの追加
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

# Falcoのインストール（Modern eBPFドライバ使用）
kubectl create namespace falco
helm install falco falcosecurity/falco \
  --namespace falco \
  --set driver.kind=modern_bpf \
  --set falcosidekick.enabled=true \
  --set collectors.kubernetes.enabled=true

# Podの確認
kubectl get pods -n falco

Falcoルールの基本構造と作成方法

Falcoのルールはyaml形式で定義され、list（値のリスト）、macro（再利用可能な条件式）、rule（検知ルール本体）の3要素で構成されます。ルールのconditionにはSysdigフィルタ構文が使われていて、システムコールの引数やプロセス情報、コンテナ情報を条件として指定できます。

では、具体的なルール例を見ていきましょう。

機密ファイルアクセスの検知

# /etc/falco/rules.d/custom-file-monitoring.yaml

- list: sensitive_file_paths
  items:
    - /etc/shadow
    - /etc/passwd
    - /etc/sudoers
    - /etc/sudoers.d
    - /root/.ssh/authorized_keys
    - /root/.bash_history

- macro: sensitive_files
  condition: fd.name in (sensitive_file_paths)

- macro: allowed_sensitive_readers
  condition: >
    proc.name in (sshd, sudo, su, passwd, login, cron)

- rule: 機密ファイルへの不正アクセス検知
  desc: >
    コンテナ内または許可されていないプロセスによる
    機密システムファイルの読み取りを検知
  condition: >
    sensitive_files and open_read
    and not allowed_sensitive_readers
    and container
  output: >
    機密ファイルが読み取られました
    (file=%fd.name user=%user.name process=%proc.name
     container=%container.name image=%container.image.repository
     namespace=%k8s.ns.name pod=%k8s.pod.name)
  priority: WARNING
  tags: [filesystem, mitre_credential_access]

コンテナ内でのシェル起動検知

これは実際の運用でかなり役に立つルールです。コンテナ内で誰かがシェルを起動したら、ほぼ確実に「何かおかしいことが起きている」サインですからね。

# コンテナ内でインタラクティブシェルが起動された場合のルール
- rule: コンテナ内シェル起動検知
  desc: コンテナ内でbash/sh等のシェルが起動されたことを検知
  condition: >
    spawned_process
    and container
    and proc.name in (bash, sh, zsh, dash, ksh)
    and proc.tty != 0
  output: >
    コンテナ内でシェルが起動されました
    (user=%user.name shell=%proc.name container=%container.name
     image=%container.image.repository namespace=%k8s.ns.name
     pod=%k8s.pod.name)
  priority: NOTICE
  tags: [container, shell, mitre_execution]

暗号通貨マイニングプロセスの検知

- list: crypto_mining_binaries
  items:
    - xmrig
    - minerd
    - cpuminer
    - cgminer
    - bfgminer
    - ethminer
    - nbminer

- list: crypto_mining_pools
  items:
    - pool.minexmr.com
    - xmrpool.eu
    - pool.hashvault.pro
    - gulf.moneroocean.stream

- rule: 暗号通貨マイニング検知
  desc: >
    暗号通貨マイニングバイナリの実行または
    マイニングプールへの通信を検知
  condition: >
    (spawned_process and proc.name in (crypto_mining_binaries))
    or (evt.type in (connect, sendto)
        and fd.sip.name in (crypto_mining_pools))
  output: >
    暗号通貨マイニングの疑いがあります
    (process=%proc.name connection=%fd.name
     container=%container.name namespace=%k8s.ns.name
     pod=%k8s.pod.name)
  priority: CRITICAL
  tags: [cryptomining, mitre_resource_hijacking]

権限昇格の検知

- rule: 権限昇格の試行検知
  desc: >
    setuidシステムコールによるUID 0（root）への
    権限昇格の試行を検知
  condition: >
    evt.type in (setuid, setreuid, setresuid)
    and evt.arg.uid = 0
    and user.uid != 0
    and not proc.name in (sudo, su, sshd, login, cron)
  output: >
    権限昇格が試行されました
    (process=%proc.name original_uid=%user.uid
     container=%container.name namespace=%k8s.ns.name)
  priority: CRITICAL
  tags: [privilege_escalation, mitre_privilege_escalation]

ルールの検証とテスト

ルールを書いたら、必ずテストしてから本番に適用しましょう。これ、意外と省略しがちなステップなんですが、本番で誤検知の嵐になってから後悔するよりずっとマシです。

# カスタムルールの構文検証
sudo falco -r /etc/falco/rules.d/custom-file-monitoring.yaml --validate

# ドライラン（実際にはアラートを発報せず動作確認）
sudo falco -r /etc/falco/rules.d/custom-file-monitoring.yaml --dry-run

# 特定ルールのみを有効にしてテスト
sudo falco -r /etc/falco/rules.d/custom-file-monitoring.yaml \
  -T "機密ファイルへの不正アクセス検知"

# Falcoログの確認
sudo journalctl -u falco -f

Tetragon：Kubernetes-nativeなセキュリティ可観測性と強制

Tetragonとは

TetragonはCiliumプロジェクトのサブプロジェクトとして開発された、eBPFベースのセキュリティ可観測性・ランタイム強制ツールです。CNCFのIncubatingプロジェクトで、Kubernetesとの深い統合が最大の特徴になっています。

ここで重要なのが、FalcoとTetragonの根本的な違いです。Falcoが「検知とアラート」に特化しているのに対し、Tetragonは「検知＋強制（Enforcement）」をカーネル内で直接実行できます。つまり、悪意のあるプロセスを検知するだけじゃなく、即座にSIGKILLで強制終了させられるんです。これ、実は相当大きな差です。

Tetragonのアーキテクチャ

Tetragonのアーキテクチャは以下の要素で構成されています。

• Tetragonエージェント：各ノード上でDaemonSetとして動作し、eBPFプログラムをカーネルにロード
• TracingPolicy CRD：Kubernetes Custom Resource Definitionとして監視ポリシーを定義
• gRPCエクスポーター：検知イベントをgRPC経由で外部システムに送信
• tetra CLI：コマンドラインからイベントの確認やポリシーの管理を実行

注目すべきは、Tetragonがフィルタリングをカーネル内で行うという設計です。ユーザースペースに大量のイベントを転送してからフィルタリングするのではなく、eBPFプログラム内で条件に合致するイベントだけを選択的にユーザースペースに通知します。高スループット環境でも性能への影響を最小限に抑えられるのは、この設計のおかげですね。

Tetragonのインストール

Kubernetesクラスタへのデプロイ

# Helmリポジトリの追加
helm repo add cilium https://helm.cilium.io
helm repo update

# Tetragonのインストール
kubectl create namespace tetragon
helm install tetragon cilium/tetragon \
  --namespace tetragon \
  --set tetragon.enableProcessCred=true \
  --set tetragon.enableProcessNs=true \
  --set tetragon.export.stdout.enabled=true

# 動作確認
kubectl get pods -n tetragon
kubectl logs -n tetragon ds/tetragon -c export-stdout -f

スタンドアロン（非Kubernetes）環境へのインストール

# バイナリのダウンロードとインストール
curl -LO https://github.com/cilium/tetragon/releases/latest/download/tetragon-linux-amd64.tar.gz
tar xzf tetragon-linux-amd64.tar.gz
sudo install tetragon /usr/local/bin/
sudo install tetra /usr/local/bin/

# systemdサービスとして設定
sudo mkdir -p /etc/tetragon/tetragon.conf.d
sudo tee /etc/systemd/system/tetragon.service <<'EOF'
[Unit]
Description=Tetragon eBPF Security Agent
After=network.target

[Service]
ExecStart=/usr/local/bin/tetragon \
  --export-filename /var/log/tetragon/tetragon.log \
  --btf /sys/kernel/btf/vmlinux
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable tetragon && sudo systemctl start tetragon

TracingPolicy：Tetragonの心臓部

TracingPolicyはTetragonの最も強力な機能です。Kubernetes CRDとして定義され、カーネル関数やシステムコールに対する監視・フィルタリング・強制アクションを宣言的に記述できます。

さっそく、いくつかの実践的なポリシー例を見ていきましょう。

機密ファイルアクセスの監視

# sensitive-file-access.yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: sensitive-file-access
spec:
  kprobes:
    - call: "security_file_open"
      syscall: false
      args:
        - index: 0
          type: "file"
      selectors:
        - matchArgs:
            - index: 0
              operator: "Prefix"
              values:
                - "/etc/shadow"
                - "/etc/passwd"
                - "/etc/sudoers"
                - "/root/.ssh/"
          matchActions:
            - action: Post

# ポリシーの適用
kubectl apply -f sensitive-file-access.yaml

# イベントの確認（tetra CLI使用）
kubectl exec -n tetragon ds/tetragon -c tetragon -- \
  tetra getevents -o compact

# 特定Namespaceのイベントのみフィルタ
kubectl exec -n tetragon ds/tetragon -c tetragon -- \
  tetra getevents --namespace default -o compact

コンテナエスケープの検知と防止

コンテナエスケープは、Kubernetes環境における最も深刻な脅威の一つです。Tetragonなら検知と同時にプロセスを即座に止められます。

# container-escape-prevention.yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: container-escape-prevention
spec:
  kprobes:
    - call: "sys_setns"
      syscall: true
      args:
        - index: 0
          type: "int"
        - index: 1
          type: "int"
      selectors:
        - matchNamespaces:
            - namespace: Pid
              operator: NotIn
              values:
                - "host_pid_ns"
          matchActions:
            - action: Sigkill
            - action: Post

不正プロセスの実行防止

# block-suspicious-binaries.yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-suspicious-binaries
spec:
  kprobes:
    - call: "sys_execve"
      syscall: true
      args:
        - index: 0
          type: "string"
      selectors:
        - matchArgs:
            - index: 0
              operator: "Equal"
              values:
                - "/usr/bin/xmrig"
                - "/tmp/miner"
                - "/usr/bin/ncat"
                - "/usr/bin/socat"
          matchActions:
            - action: Sigkill

ネットワーク接続の監視

# network-monitoring.yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: network-connection-monitor
spec:
  kprobes:
    - call: "tcp_connect"
      syscall: false
      args:
        - index: 0
          type: "sock"
      selectors:
        - matchArgs:
            - index: 0
              operator: "DAddr"
              values:
                - "0.0.0.0/0"
          matchActions:
            - action: Post
          matchNamespaces:
            - namespace: Net
              operator: NotIn
              values:
                - "host_network"

FalcoとTetragonの詳細比較

機能比較マトリクス

両ツールは補完的な性格を持っていますが、用途に応じた適切な選択が大事です。以下の比較表をざっと見てみてください。

比較項目	Falco	Tetragon
CNCFステータス	Graduated（卒業）	Incubating
主な用途	ルールベースの異常検知	セキュリティ可観測性＋ランタイム強制
ドライバ	Modern eBPF / eBPF / kmod	eBPF（CO-RE/BTF必須）
強制機能	なし（検知のみ）	あり（Sigkill、Override等）
ポリシー形式	Falcoルール（独自DSL）	TracingPolicy（Kubernetes CRD）
Kubernetes統合	対応（メタデータ取得）	ネイティブ（CRD、ラベル、Namespace対応）
非Kubernetes環境	良好なサポート	対応（スタンドアロンモード）
アラート連携	Falcosidekick経由で多数対応	JSON、gRPC、Prometheus
コミュニティ	大規模・成熟	急成長中
性能オーバーヘッド	低い（1-3%程度）	非常に低い（1%未満）

選択指針

では、どちらを選べばいいのか。ケースごとに整理してみます。

• 検知のみが目的で、豊富なアラート連携が欲しい場合：Falcoが最適です。Falcosidekickを通じて、Slack、PagerDuty、Elasticsearch、Splunk、Datadog、AWS Security Hubなど30以上のバックエンドにアラートを送信できます
• リアルタイムの強制（プロセスの即座の終了）が必要な場合：Tetragonが唯一の選択肢です。検知と同時にSIGKILLでプロセスを強制終了できるため、暗号通貨マイニングやコンテナエスケープをリアルタイムで阻止できます
• Kubernetesネイティブな運用を重視する場合：TetragonのTracingPolicy CRDはKubernetesのエコシステムに自然に統合されます。GitOpsワークフローとの親和性も高いです
• 非Kubernetes環境（ベアメタル、VM）が主な対象の場合：Falcoは従来からLinuxホスト上での動作に最適化されており、systemdサービスとしての運用実績が豊富です
• 両方の特性が欲しい場合：実は併用するアーキテクチャも十分アリです。Falcoで広範な異常検知を行い、Tetragonで重要度の高い脅威に対するリアルタイム強制を実施する――という多層防御アプローチですね

実践：多層防御アーキテクチャの構築

FalcoとTetragonの併用構成

本番環境では、FalcoとTetragonを組み合わせた多層防御が効果的です。以下に、Kubernetesクラスタでの併用構成例を示します。

# falco-values.yaml（Helm用カスタム値）
driver:
  kind: modern_bpf

falcosidekick:
  enabled: true
  config:
    slack:
      webhookurl: "https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
      minimumpriority: "warning"
    elasticsearch:
      hostport: "https://elasticsearch.monitoring:9200"
      index: "falco-alerts"
      minimumpriority: "notice"
    prometheus:
      enabled: true

collectors:
  kubernetes:
    enabled: true

resources:
  requests:
    cpu: 200m
    memory: 512Mi
  limits:
    cpu: 1000m
    memory: 1024Mi

customRules:
  custom-rules.yaml: |-
    - rule: コンテナ内シェル起動
      desc: コンテナ内でのシェル起動を検知
      condition: >
        spawned_process and container
        and proc.name in (bash, sh, zsh)
        and proc.tty != 0
      output: >
        シェル起動検知 (user=%user.name shell=%proc.name
        container=%container.name ns=%k8s.ns.name
        pod=%k8s.pod.name)
      priority: WARNING
      tags: [container, shell]

# tetragon-enforcement.yaml
# 暗号通貨マイニングと不正ツールを即座にブロック
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: runtime-enforcement
spec:
  kprobes:
    - call: "sys_execve"
      syscall: true
      args:
        - index: 0
          type: "string"
      selectors:
        # 暗号通貨マイニングの防止
        - matchArgs:
            - index: 0
              operator: "Equal"
              values:
                - "/usr/bin/xmrig"
                - "/usr/local/bin/xmrig"
                - "/tmp/xmrig"
          matchActions:
            - action: Sigkill
        # リバースシェルツールのブロック
        - matchArgs:
            - index: 0
              operator: "Equal"
              values:
                - "/usr/bin/ncat"
                - "/usr/bin/nc.openbsd"
          matchActions:
            - action: Sigkill

アラート統合パイプラインの構築

検知イベントを効果的に処理するためのアラートパイプラインを構築しましょう。Falcosidekickを中心に、各種バックエンドへの連携を設定します。

# Falcosidekickの詳細設定
# falcosidekick-config.yaml
config:
  # Slack通知
  slack:
    webhookurl: "${SLACK_WEBHOOK_URL}"
    channel: "#security-alerts"
    username: "Falco"
    minimumpriority: "warning"
    messageformat: |
      *{{ .Priority }}* - {{ .Rule }}
      {{ .Output }}
      Namespace: {{ index .OutputFields "k8s.ns.name" }}
      Pod: {{ index .OutputFields "k8s.pod.name" }}

  # Prometheusメトリクス
  prometheus:
    extralabels: "environment:production,cluster:main"

  # Elasticsearch（ログ蓄積・分析用）
  elasticsearch:
    hostport: "https://elasticsearch:9200"
    index: "falco-alerts"
    type: "_doc"
    minimumpriority: "notice"
    mutualtls: false
    checkcert: true
    username: "${ES_USERNAME}"
    password: "${ES_PASSWORD}"

Prometheusによるメトリクス監視

# tetragon-servicemonitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: tetragon-metrics
  namespace: tetragon
  labels:
    app: tetragon
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: tetragon
  endpoints:
    - port: metrics
      interval: 30s
      path: /metrics

# Grafanaダッシュボード用のPrometheusクエリ例

# Tetragonが検知したプロセス実行イベント数（過去1時間）
rate(tetragon_events_total{event_type="process_exec"}[1h])

# Falcoアラートの優先度別カウント
sum by (priority) (rate(falco_events{source="syscall"}[5m]))

# ポリシー違反によるプロセス強制終了数
sum(rate(tetragon_policy_events_total{action="sigkill"}[1h]))

本番環境での運用ベストプラクティス

段階的な導入アプローチ

eBPFベースのセキュリティ監視を本番環境に導入する際は、いきなり全部入りで突っ込むのではなく、段階的に進めることを強くお勧めします。筆者もこのアプローチで何度も助けられました。

1. Phase 1：可観測性の確立（1-2週間）
   • Falcoをデフォルトルールセットで導入
   • Tetragonをアクションなし（Postのみ）で導入
   • 通常のワークロードパターンをベースライン化
   • 誤検知の特定とルールのチューニング
2. Phase 2：カスタムルール/ポリシーの追加（2-4週間）
   • 組織固有のセキュリティ要件に基づくカスタムルールの作成
   • MITRE ATT&CKフレームワークに基づく脅威カバレッジの評価
   • Falcosidekickによるアラート連携の設定
3. Phase 3：ランタイム強制の有効化（段階的）
   • Tetragonの強制ポリシーを、最も確信度の高い脅威から有効化
   • 暗号通貨マイニングの阻止から開始（誤検知リスクが低いので安心）
   • 強制アクションの影響をモニタリングしながら段階的に拡大
4. Phase 4：継続的改善（継続）
   • 新しい脅威インテリジェンスに基づくルール/ポリシーの更新
   • インシデント対応演習による検知能力の検証
   • パフォーマンスメトリクスの定期的なレビュー

パフォーマンスチューニング

eBPFベースの監視ツールは低オーバーヘッドとはいえ、高スループット環境ではチューニングが必要になることがあります。特にイベント量が多い環境では、バッファサイズやレート制限の調整が欠かせません。

# Falcoのパフォーマンスチューニング
# /etc/falco/falco.yaml

# Modern eBPFドライバの設定
engine:
  kind: modern_ebpf
  modern_ebpf:
    # バッファサイズ（高スループット環境では増加）
    buf_size_preset: 4
    # CPU数に応じたリングバッファの数
    cpus_for_each_buffer: 2

# 出力のレート制限（アラートストームの防止）
outputs:
  rate: 100
  max_burst: 200

# 高ボリュームイベントの除外
syscall_event_drops:
  max_burst: 10
  actions:
    - log
    - alert

# Tetragonのパフォーマンスチューニング
# Helm values
tetragon:
  # リングバッファサイズ（ページ数）
  exportAllowList: |
    {"event_set": ["PROCESS_EXEC", "PROCESS_EXIT", "PROCESS_KPROBE"]}

  # リソース制限
  resources:
    requests:
      cpu: 100m
      memory: 256Mi
    limits:
      cpu: 500m
      memory: 512Mi

誤検知の管理

ランタイムセキュリティ監視で最も重要かつ地道な作業が誤検知の管理です。ここを怠ると、アラート疲れでチームが本当に重要なアラートを見逃すようになってしまいます。Falcoではexceptionsフィールド、TetragonではmatchActions/matchArgsのnot演算子を活用しましょう。

# Falcoでの誤検知除外例
- rule: コンテナ内シェル起動検知
  desc: コンテナ内でのシェル起動を検知（CI/CDパイプライン除外）
  condition: >
    spawned_process and container
    and proc.name in (bash, sh, zsh)
    and proc.tty != 0
  exceptions:
    # CI/CDランナーを除外
    - name: ci_cd_runners
      fields: [container.image.repository]
      comps: [in]
      values:
        - [["gitlab/gitlab-runner", "github/actions-runner",
            "jenkins/inbound-agent"]]
    # 特定Namespaceを除外
    - name: allowed_namespaces
      fields: [k8s.ns.name]
      comps: [in]
      values:
        - [["ci-cd", "build-system"]]
  output: >
    シェル起動検知 (user=%user.name shell=%proc.name
    container=%container.name ns=%k8s.ns.name)
  priority: WARNING

セキュリティイベントの調査ワークフロー

アラートが飛んできてからの調査ワークフローも、事前に整備しておくことが重要です。いざという時に「何からやればいいんだっけ？」とならないよう、スクリプト化しておくのがベストですね。

#!/bin/bash
# security-investigation.sh
# セキュリティアラート調査用スクリプト

POD_NAME=$1
NAMESPACE=$2

echo "=== Pod情報 ==="
kubectl describe pod "$POD_NAME" -n "$NAMESPACE"

echo "=== 最新のTetragonイベント ==="
kubectl exec -n tetragon ds/tetragon -c tetragon -- \
  tetra getevents --namespace "$NAMESPACE" \
  --pod "$POD_NAME" -o json | jq '.' | tail -50

echo "=== Falcoアラート（Elasticsearch検索） ==="
curl -s "https://elasticsearch:9200/falco-alerts/_search" \
  -H 'Content-Type: application/json' \
  -d "{
    \"query\": {
      \"bool\": {
        \"must\": [
          {\"match\": {\"output_fields.k8s.pod.name\": \"$POD_NAME\"}},
          {\"match\": {\"output_fields.k8s.ns.name\": \"$NAMESPACE\"}},
          {\"range\": {\"@timestamp\": {\"gte\": \"now-1h\"}}}
        ]
      }
    },
    \"sort\": [{\"@timestamp\": \"desc\"}],
    \"size\": 20
  }" | jq '.hits.hits[]._source'

echo "=== Podのネットワーク接続 ==="
kubectl exec "$POD_NAME" -n "$NAMESPACE" -- \
  cat /proc/net/tcp 2>/dev/null || echo "接続情報の取得に失敗"

今後の展望：eBPFセキュリティの未来

BPF-LSMの進化

BPF-LSM（BPF Linux Security Module）は、eBPFプログラムをLSMフックにアタッチすることで、SELinuxやAppArmorのような静的なポリシーではなく、動的かつプログラマブルなセキュリティポリシーを実現する技術です。Tetragonは既にBPF-LSMフックの一部を活用しており、今後さらに多くのLSMフックがサポートされることで、より精密なアクセス制御が可能になるでしょう。

ハードウェア支援によるeBPF安全性の向上

SafeBPFのようなプロジェクトでは、Intel MPK（Memory Protection Keys）やArmのメモリドメインを活用して、eBPFプログラムのメモリアクセスをハードウェアレベルで制限する研究が進んでいます。約4%のオーバーヘッドで、eBPFプログラムが意図しないメモリ領域にアクセスすることを防止できるとのこと。eBPF自体の安全性がさらに一段上がることになります。

SBOM統合とサプライチェーンセキュリティ

eBPFベースのセキュリティ監視とSBOM（Software Bill of Materials）を統合する動きも進んでいます。コンテナイメージに含まれるソフトウェアコンポーネントの情報とランタイムの振る舞いを関連付けることで、既知の脆弱性を持つコンポーネントが実際に実行された場合にのみアラートを発報する。そういった、より精度の高い脅威検知が現実のものになりつつあります。

まとめ

eBPFベースのランタイムセキュリティ監視は、現代のLinux・Kubernetesセキュリティにおいて、もはや「あると便利」ではなく「なくてはならない」技術になっています。

この記事で取り上げたFalcoとTetragonは、それぞれ異なる強みを持つ補完的なツールです。

• Falcoは成熟したエコシステムと豊富なルールライブラリを持ち、広範な異常検知とアラート連携に優れています
• TetragonはKubernetesネイティブな設計とランタイム強制機能を持ち、検知と同時にリアルタイムで脅威を阻止できます
• 両者の併用により、「広く検知し、重要な脅威は即座にブロックする」という多層防御アーキテクチャを実現できます

導入にあたっては、段階的なアプローチを取り、まず可観測性を確立してからランタイム強制へと進むこと。これが成功の鍵です。誤検知の管理を怠らず、組織のセキュリティ要件と運用能力に合わせてチューニングを続けていけば、eBPFベースのセキュリティ監視はあなたの環境における最も効果的な防御レイヤーの一つになるはずです。