セキュリティと可観測性（Observability）の融合は、2026年のクラウドネイティブアーキテクチャにおける最重要トレンドの一つである。従来は別々のツールチェーンで運用されていた両領域が、eBPFとOpenTelemetryを基盤として統合されつつある。本稿では、ランタイムセキュリティと可観測性パイプラインを統合するための設計指針を解説する。

融合の背景 ── なぜ今、統合が求められるのか

従来のセキュリティ運用は、SIEM（Security Information and Event Management）を中心としたログ収集・分析が主流だった。一方、可観測性チームはメトリクス・トレース・ログの「三本柱」を別系統で管理していた。この分断がもたらす問題は、インシデント発生時の対応遅延である。セキュリティアラートが発生しても、該当システムのパフォーマンス状況やトレース情報との相関分析に時間を要していた。

Dell'Oro Groupの2026年予測によれば、次世代SIEMはSIEM、SOAR、XDR、可観測性、CNAPP（Cloud-Native Application Protection Platform）を単一のサービス提供型コントロールプレーンに統合する方向に向かう。単一のSaaSプラットフォームでログ、テレメトリ、クラウドデータを取り込み、AIアシスト調査を実行し、SASE/SSE、WAF、エンドポイント、オンプレミス・クラウド制御をまたいでレスポンスをオーケストレートする構成が標準化しつつある。

eBPFが実現するランタイムセキュリティ

eBPF（extended Berkeley Packet Filter）は、カーネルを改変することなくシステムコール、ネットワークトラフィック、アプリケーション挙動を監視できる技術である。eBPF Foundationの2025年レビューによれば、eBPFはインフラチームにとって信頼できる基盤となり、L7ネットワーキング、ランタイムセキュリティ、LLM可観測性、FinOpsまで幅広い領域をカバーしている。

ランタイム検知の主要ツールとして、CiliumプロジェクトのTetragonが注目を集めている。TetragonはKubernetes環境に対応したセキュリティ可観測性・ランタイム強制ツールであり、eBPFレイヤーで直接ポリシー適用とフィルタリングを実行する。これにより、観測オーバーヘッドの削減、任意プロセスの追跡、リアルタイムポリシー強制が可能となる。

一方、eBPFを悪用した脅威も出現している。BPFDoorは本番Linuxシステムで観測された初のeBPFバックドアであり、カーネルエクスプロイトではなく正規のフックを制御用に転用した事例である。Aqua SecurityのTraceeやRed CanaryのeBPFmonは、eBPF自体を監視し、未承認のプログラムやマップをリアルタイムでフラグする防御アプローチを採用している。

OpenTelemetryによる統一テレメトリ基盤

OpenTelemetry（OTel）は2025年に大きく成熟し、メトリクス、ログ、トレースに加えてプロファイルまでをカバーする統一テレメトリ基盤として定着した。CNCFの事例報告によれば、企業内のチームがベンダー中立で一貫性のあるテレメトリ収集を求める中、OpenTelemetryのAPI、セマンティック規約、Collectorが連携してその要求に応えている。

Datadog Observability PipelinesはOTel Collectorをログソースとしてサポートし、OTelでテレメトリデータをインストルメント・収集した後、任意の宛先へ処理・ルーティングできる構成を可能にした。Google Cloudも2025年9月にネイティブOTLPインジェストを採用し、すべてのテレメトリタイプでOpenTelemetryを第一級市民として扱う戦略を明確にした。

2026年に向けては、Kubernetesテレメトリの第一級インジェストレイヤーとしてOTelを推進するプロジェクトが増加すると予測されている。特にデータベースやGenAIワークロード向けのセマンティック規約拡張が注目される。

統合アーキテクチャの設計パターン

セキュリティと可観測性を統合する具体的なアーキテクチャパターンを以下に示す。

パターン1：eBPFエージェント統合型。Tetragon、Falco、Traceeなどのランタイムセキュリティツールが生成するイベントを、OpenTelemetry CollectorのReceiverとして取り込む。セキュリティイベントにトレースIDを付与することで、該当リクエストの全体像を即座に把握できる。

パターン2：Observabilityパイプライン中継型。すべてのテレメトリをDatadog Observability PipelinesやCribl Streamなどのパイプラインに集約し、セキュリティ用（SIEM）と可観測性用（APM/Monitoring）に分岐・変換・ルーティングする。パイプライン上でサンプリングや機密データマスキングを適用することで、コスト最適化とコンプライアンスを両立できる。

パターン3：CNAPP統合型。Wiz、Orca Security、Sysdigなどのコード・クラウド・ランタイムをカバーするプラットフォームを導入し、セキュリティコンテキストを可観測性ダッシュボードに統合表示する。Dynatraceはこのアプローチを「クラウドセキュリティと可観測性コンテキストの革新」と位置付けている。

ラテラルムーブメント検知の実装

攻撃者が初期侵入後に内部ネットワークを横断する「ラテラルムーブメント」の検知は、セキュリティ可観測性統合の重要なユースケースである。User Behavior Analytics（UBA）によるラテラルムーブメント検知は、「正常」なランタイム挙動を学習したAIモデルがプロセス実行、API呼び出し、ネットワークフローの逸脱を検出するアプローチで実現される。

具体的な検知シグナルとしては、通常アクセスしないノードへのSSH接続、サービスアカウントの異常なAPI呼び出しパターン、Pod間の予期しないネットワークトラフィック（Network Policy違反の検知）、権限昇格の試行（securityContext変更、hostPIDマウント等）が挙げられる。これらのシグナルをトレースIDと紐付けることで、攻撃経路の可視化と影響範囲の特定が迅速化される。

FAQ

セキュリティと可観測性の統合で最初に導入すべきツールは？

eBPFベースのランタイム検知ツール（Tetragon、Falco等）とOpenTelemetry Collectorの組み合わせが基本となる。既存のSIEMがある場合はパイプライン経由で連携する。

OpenTelemetryはセキュリティテレメトリに対応していますか？

OTel自体はセキュリティ専用プロトコルではないが、セキュリティイベントをログやスパンとして取り込むことは可能である。セマンティック規約の拡張が進行中である。

ラテラルムーブメント検知に必要なデータソースは？

ネットワークフローデータ（eBPFまたはCNI）、Kubernetesイベント、認証ログ、プロセス実行履歴が基本となる。これらをトレースIDで相関付けることが重要である。

CNAPPと可観測性ツールの使い分けは？

CNAPPはセキュリティ態勢管理とコンプライアンス、可観測性ツールはパフォーマンス監視とトラブルシューティングが主用途である。統合ダッシュボードで両方のコンテキストを参照できる構成が理想的である。

参考文献