< back to blog

AWS/GCP 標準ツールでは守れない?Falco を超える Sysdig Secure によるセキュリティの新常識

Reiko Nishii
AWS/GCP 標準ツールでは守れない?Falco を超える Sysdig Secure によるセキュリティの新常識
Published by:
Reiko Nishii
@
AWS/GCP 標準ツールでは守れない?Falco を超える Sysdig Secure によるセキュリティの新常識
Published:
February 24, 2026
シスディグによるファルコフィード

Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。

さらに詳しく

現代のクラウドネイティブ環境において、SREやPlatformエンジニアが直面する最も高度な脅威の一つが「システムコール回避(Syscall Evasion)」です。

本稿では、攻撃者がどのようにしてセキュリティツールの監視を潜り抜けるのか、その手法と実例を解説し、なぜAWS/GCPの標準ツールやOSSのFalcoだけでは不十分なのか、そしてSysdig Secureがなぜ不可欠なのかを解説します。

あなたが前提としている「監視」は、すでに攻撃者に織り込まれている

「AWS GuardDutyを入れているから安心だ」「GCP Security Command Centerでログは取っている」 もしあなたがそう考えているなら、それは攻撃者にとって絶好の「死角」となります。

近年のマルウェアは、OSの標準的な監視窓口である libc や、従来のシステムコール・フックを巧妙にバイパスします。クラウドプロバイダーが提供するログベースの監視や、サンプリングされたメトリクスでは、「実行中のコンテナ内部で何が起きているか」をリアルタイムに、かつ詳細に把握することは不可能です。

システムコール回避攻撃の実態

通常、Runtime SecurityツールはLinuxカーネルの「システムコール(Syscall)」を監視することで、プロセスの挙動(ファイルへの書き込み、ネットワーク接続など)を検知します。しかし、攻撃者はこの「ゲートキーパー」をバイパスする手法を開発しています。

主な攻撃手法

具体的なマルウェア・攻撃事例

監視ツール/オブザーバビリティツールにおける検知性の比較

SREやエンジニアが日常的に利用するセキュリティツールやオブザーバビリティツールは、それぞれ監視できるレイヤーと検知可能な範囲が大きく異なります。まず、AWS GuardDutyやGCP Security Command Centerは、主にクラウドAPIやネットワークログといったインフラレイヤーを中心に監視する設計となっており、クラウドリソースの異常な操作や通信の兆候を把握するには有効です。しかし、コンテナ内部や実行時の挙動といった低レイヤーの詳細な活動までは可視化できません。

一方、OpenTelemetryやPrometheusなどのオブザーバビリティツールは、メトリクスやトレースを通じてシステムのパフォーマンスや可用性の把握に優れています。ただし、これらは本質的に運用監視を目的としたツールであり、攻撃者による回避行動や不審なプロセスの詳細な検知には適しておらず、異常が発生した場合でも「負荷の増加」などの間接的な兆候としてしか認識できないケースが多くなります。

Falco(OSS)は、eBPFやシステムコールを活用してカーネルレベルの挙動を監視できるため、ランタイムセキュリティの観点では高い検知能力を持ちます。ファイル操作やプロセス実行などの不審な挙動を詳細に把握できる点は大きな強みです。ただし、io_uringのような新しいカーネル機構への対応にはカスタムルールや継続的なチューニングが必要となり、ルール設計次第ではシステムコール回避攻撃にバイパスされるリスクも残ります。また、事後分析の面では基本的にログベースの調査に依存することになります。

これに対し、Sysdig SecureはDeep Kernel、Cloud、Applicationの各レイヤーを横断して監視を行う多層的なアプローチを採用しています。io_uringに対しても標準で検知・防御が可能であり、単なるログ監視にとどまらず、実行コンテキストを含めた挙動の相関分析によってシステムコール回避のような高度な攻撃にも対応できます。さらに、SCAPファイルによる完全なアクティビティ記録を取得できるため、インシデント発生後もコンテナ内部の挙動を詳細に再現・分析することが可能です。

このように比較すると、クラウド標準ツールはインフラ視点の可視化、オブザーバビリティツールは運用指標の把握、Falcoはカーネルレベルの検知に強みを持つ一方で、回避攻撃や短命なコンテナ環境における完全な可視性と防御までを一貫して実現できるのは、カーネルからクラウド、アプリケーションまでを統合的に監視・分析できるプラットフォームに限られます。SREの観点では、「どのレイヤーまで見えているのか」がそのままインシデント対応の精度と速度を左右する重要な判断軸となります。

ツール別の限界

AWS / GCPの標準ツールは、インフラレイヤーにおける不審な挙動(IP変更、異常なAPIコールなど)の監視には有効ですが、コンテナ内部で進行する回避攻撃の検知まではカバーしていません。

オブザーバビリティツールは可用性やパフォーマンスの把握に強みを持つ一方で、意図的に隠蔽された悪意ある挙動の検知には適していません。

Falco(OSS)は高い検知能力を持つ一方で、io_uringなど新しいカーネル機構への継続的な対応、数万台規模のコンテナ環境におけるルールの設計・管理、ならびに攻撃検知後のプロセス停止といった能動的対応の実装・運用には課題があります。

回避攻撃を前提に、なぜ Sysdig Secure が選ばれるのか

Sysdig Secureは、Falcoの生みの親が開発した商用プラットフォームであり、次の3点において圧倒的な優位性があります。

回避攻撃に対する「絶対的な可視性」

Sysdigは最新のLinuxカーネル技術に深くコミットしており、io_uring を介した攻撃を標準で検知するルールをいち早く実装しました。システムコールを単に「見る」だけでなく、その前後関係やパラメータ、実行コンテキストをeBPFを通じて深く分析するため、回避策が通用しません。

「検知」にとどまらない「阻止(Response)」へ

OSSのFalcoが「何かが起きた」と知らせるだけなのに対し、Sysdig Secureは以下の即時対応が可能です。

  • Drift Control: 実行中のコンテナに新しく持ち込まれたバイナリの実行を即座にブロック。
  • Process Termination: 異常なシステムコールパターンを検知した瞬間にプロセスをキル。

インシデントを「完全に巻き戻せる」

攻撃者がシステムコールを回避して痕跡を消そうとしても、Sysdigはシステム全体の活動をSCAPファイルとしてキャプチャ(録画)できます。これにより、攻撃者がどのファイルを書き換え、どのC&Cサーバーと通信したのかを、コマンド一つ、引数レベルで事後解析できます。これは、SRE にとってインシデント対応をブラックボックス化させないための前提条件です。

まとめ:SREとプラットフォームエンジニアへの提言

クラウドネイティブなインフラを構築・運用する立場として、「カーネルレベルでの不可視性」は最大のリスクです。標準のモニタリングツールで安心している間に、攻撃者はシステムコールを迂回してルート権限を奪取しているかもしれません。

Sysdig Secure を導入することは、単なるツール選定ではなく、「見えない脅威を可視化し、確実に阻止する」という防御戦略の確立そのものです。

About the author

Monitoring
Security for AI
Open Source

セキュリティの専門家と一緒に、クラウド防御の最適な方法を探索しよう