ランタイムセキュリティと Falco を使い始める

本文の内容は、2026年9月17日に Víctor Jiménez Cerrada が投稿したブログ (https://www.sysdig.com/blog/intro-runtime-security-falco) を元に日本語に翻訳・再構成した内容となっております。

‍ランタイムセキュリティは、ポスチャーの隙間を埋める最後の防衛線として機能します。

インターネットに公開された Web アプリケーションを想像してみてください。攻撃者はソフトウェアのバグを利用して初期アクセスを獲得し、そこからラテラルムーブメントと権限昇格を重ねて、クラウドインフラストラクチャーの残りの部分にまで到達するかもしれません。あるいは、資格情報の窃取について考えてみましょう。ある開発者が、息子のために Minecraft の MOD をダウンロードしようと業務用のノート PC を使いました。しかし実際にダウンロードしたのはマルウェアで、クラウドの資格情報を盗み出してしまいました。こうなると、攻撃者は正面玄関から堂々と侵入できてしまいます。

ポスチャーはベストプラクティスを強制するうえで役立ちますが、進行中の脅威に対しては目が見えません。そこでランタイムセキュリティが力を発揮します。

ここではランタイムセキュリティについて簡単にご紹介し、Falco がどのように魔法を披露するのか、そして Falco を使い始めるのがいかに簡単かを見ていきます。

ランタイムセキュリティとは？

ランタイムセキュリティとは、ワークロードが実行状態に入った後にそれを保護することです。ポスチャーでは検知できないセキュリティリスクを補うセーフティネットとして機能します。対象には次のようなものが含まれます。

• ゼロデイ脆弱性、つまりソフトウェアの作成者がこれまで把握していなかった問題。
• 権限昇格の試み。
• 不規則な挙動やリソースリークを引き起こすバグ。

ランタイムセキュリティのソフトウェアはアンチウイルスに似た働きをします。システム内で起きていることをすべて観察し、疑わしいアクティビティが発生したときにアラームを発します。

攻撃者は、まだ公にされていないソフトウェアの脆弱性を悪用して、コンテナへの初期アクセスを獲得できます。そしてそこから設定ミスを利用してラテラルムーブメントを行い、権限を昇格させていきます。既知の脆弱性の緩和とコンプライアンスだけに頼っていると、こうした攻撃に対して無防備になります。さらに詳しく知りたい方は、同様のシナリオを扱った「クラウドにおけるラテラルムーブメント：脆弱なコンテナから侵入する」をご覧ください。

Falco のようなランタイムセキュリティツールは、コンテナ上の疑わしいネットワーク接続やクラウドアカウント内の疑わしい挙動を検知し、アラートを発して攻撃を封じ込める機会をもたらします。また Falco は各アラートにクラウドネイティブなコンテキストを付加するため、アラートの発生源を特定し、複数のアラートを相関させて攻撃の範囲を把握するのに役立ちます。

私たちは、攻撃を支援し、高速化し、カスタマイズするために AI が使われていることを確認しています。ランタイムはかつてないほど予測が困難になっており、ポスチャーとベストプラクティスだけでは不十分です。セーフティネットとして、堅実なランタイムセキュリティが必要です。

クラウドとコンテナのためのランタイムセキュリティ

クラウドネイティブなワークロードは動き続ける部品の集合体であり、そのすべてを可視化するのは困難です。

ここでは主要な構成要素と、それぞれにランタイムセキュリティを実装する方法を見ていきます。

コンテナワークロードは次の要素で構成されます。

• コンテナ：サンドボックス内で実行される、あなたのワークロードです。
• コンテナランタイム：サーバー上でコンテナを実行し、ホストのリソースとのインターフェースとなるプロセスです。例： containerd、CRI-O、podman、Docker。
• オーケストレーター：サーバーのクラスター全体にコンテナをデプロイし、管理するツール群です。例： Kubernetes、OpenShift、Docker Swarm。
• ノード：クラスターを構成し、その各コンポーネントをホストするサーバー群です。

クラウドワークロードにはコンテナが含まれることもありますが、それ以外にも次のものが含まれます。

• サーバー：好きなソフトウェアを何でも実行できる、昔ながらの仮想マシンです。例： AWS EC2、GCP Compute Engine。
• サーバーレスワークロード：下位のサーバーを管理することなくソフトウェアを実行できるサービスです。例： Lambda 関数、AWS Fargate、Google Cloud Run。
• マネージドサービス：データベース、ストレージ、ファイアウォール、ネットワーキング、メッセージキューなど、設定して利用はするものの低レベルでは管理しないサービスです。

そして特筆すべきは、これらすべてのサービスの設定とアクセス管理です。多くの場合、これらはそれ自体で 2 つの独立した領域を成しています。

クラウドネイティブ環境のランタイムセキュリティを実装するには、次の手段を組み合わせて使えます。

• クラスターのノードやコンピュートユニット上に配置するエージェント。システムコールを読み取るためのカーネルインストルメンテーションや、オーケストレーターの API を通じてログを取得するなど、複数の手法を組み合わせてシステム内で起きていることをすべて追跡します。
• カーネルインストルメンテーションが利用できないサーバーレスワークロード上のサイドカー。ptrace や LD_PRELOAD といった代替手段が使えます。
• クラウドプロバイダーの API を通じて監査ログを取得するエージェントレスサービス。API を使って、アカウントの隔離やワークロードの停止といった対応アクションを実行することもできます。

Falco は、クラウドとコンテナのランタイムセキュリティ用 OSS ツールとして最も広く使われています。そのため、そのエコシステムには上記すべてを実装するためのツールが揃っています。

Falco の仕組み

Falco は、ホスト、コンテナ、Kubernetes、クラウド環境にまたがってランタイムセキュリティを提供するクラウドネイティブセキュリティツールです。

Falco は複数のソースからイベントを分析することで深い可視性をもたらします。一方ではホストシステムからカーネルのシステムコールを取得し、もう一方では Falco プラグイン経由でイベントを受け取ります。このプラグインは Kubernetes、クラウドプロバイダー、さらには GitLab、Box、Salesforce といった SaaS サービスの監査ログにも接続できます。登録済みプラグインの一覧をご確認ください。

同様に重要なのは、Falco が検知結果にコンテキストを付加することです。これにより DevOps、セキュリティ、クラウドの各チームは、誰が何をどこで行ったのかを正確に理解できます。このコンテキストは、セキュリティイベントの範囲を把握しようとするときに鍵となります。

Falco の検知能力は、エコシステム内の他のツールで補完できます。

Falco は標準では限られた数のチャネルにしかアラートを送信できません。Falcosidekick は Falco のアラートチャネルを拡張し、Slack のような広く使われているチャットサービス、Prometheus のようなオブザーバビリティツール、Pagerduty のようなアラートシステムなどに対応させます。

また、Stratoshark を使えばイベントを探索でき、Wireshark ベースのインターフェースでデスクトップから操作できます。

Falco のアーキテクチャ

内部的には、Falco は複数のレベルで動作します。

• Falco バイナリはユーザースペースで動作し、ドライバーやプラグインからの情報を解析し、ルールを評価してアラートを出力します。
• ドライバーはホストからシステムコールを収集します。カーネルモジュール（デフォルト）と eBPF プローブはカーネルレベルで動作し、起きていることをすべて把握できます。一方、ユーザースペースインストルメンテーションはより少ない権限で動作できますが、可視性は限定されます。
• 最後に、設定が Falco の動作方法、どのルールを適用するか、いつアラートを発するかを定義します。

Falco のルール

Falco はイベントをルールに照らして評価し、condition が満たされた場合にそのイベントを疑わしいと判断します。

たとえば、コンテナ内で bash が起動するのは通常ではありません。次のルールはそうしたイベントにフラグを立てます。condition が proc.name が bash であるプロセスを探している点に注目してください。

- rule: Detect bash in a container
  desc: You shouldn't have a shell run in a container
  condition: container.id != host and proc.name = bash
  output: Bash ran inside a container (user=%user.name command=%proc.cmdline %container.info)
  priority: INFO

このルールがイベントを検知すると、output プロパティで定義されたメッセージが返されます。

20:07:06.837415779: Notice A shell was spawned in a container with an attached terminal (user=root container=1dab04047700 shell=bash parent=runc cmdline=bash terminal=34816 container_id=1dab04047700 image=docker.io/falcosecurity/falco) container=1dab04047700

これで完了です。平易な言葉を使うだけで、ランタイムのコンテナアクティビティを可視化し、潜在的なセキュリティイベントを検知できます。

Falco のルールについてさらに知りたい方は、ドキュメントのルールの項をご覧ください。

Falco は堅実なプロジェクト

「よし、わかった、Falco は素晴らしい」という声が聞こえてきます。「でも、このプロジェクトはどれくらい堅実なの？」

これは妥当な疑問です。結局のところ、あるソリューションに本格的に取り組んだ後で、短期間のうちに別のものへ移行したいと思う人はいません。そこで、状況を正しく捉えるために、興味深い事実をいくつかご紹介します。

Falco の採用は伸び続けており、2024 年の Cloud Native Computing Foundation®（CNCF）からのグラデュエーションによって、この傾向はさらに加速しました。たとえば、Falco の GitHub リポジトリをフォローしているユーザー数は、インキュベーション時から 4 倍に増え、そのペースを保っています。

採用はあらゆる場面に広がっており、Falco はいまや公式の CKS 試験のカリキュラムの一部になっています。

そして私たちにとって何よりうれしいのは、Gartner に評価されたことです。Gartner のアナリストは、Falco を使用する理由の一つとして「Falco は、Kubernetes のコンテキスト認識を伴って、アプリケーションのデプロイメントにおける異常な挙動の検知を可能にする」と述べています。[1]

Falco は活発なコミュニティを持つ強力なプロジェクトであり、ランタイムのコンテナセキュリティのニーズに対する有力な候補として検討すべきです。

Falco をはじめる最初のステップ

Linux マシンへの Falco のインストールはかなり簡単です。要約すると、カーネルモジュールをインストールし、リポジトリを設定し、（Debian 系ホストであれば）apt-get でバイナリをインストールするだけです。

ただしクラウドネイティブな世界では、ベアメタルへのインストールは行わず、代わりにコンテナを使っている可能性が高いでしょう。

ここでは、Kubernetes のパッケージマネージャーである Helm を使って Kubernetes クラスターに Falco をインストールする方法と、利用可能なルールをカスタマイズする方法を見ていきます。

待ってください、これをテストする Kubernetes クラスターがありません！

ご心配なく。しっかりカバーします。

Minikube のインストール手順に従えば、数分でシングルノードの Kubernetes クラスターが手に入ります。

Minikube は次のコマンドで起動してください。

$ minikube start

そして、正常に起動したことを確認するために簡単なテストを行います。

$ minikube kubectl -- get nodes
NAME       STATUS   ROLES                  AGE     VERSION
minikube   Ready    control-plane,master   6m18s   v1.22.2

ここからは kubectl クライアントがローカルにインストールされている前提とし、minikube を前置せずに kubectl get nodes を実行できるものとします。コマンドを簡略化するためのエイリアスの作成方法については、minikube kubectl のドキュメントをご確認ください。あるいは、こちらからご自身のマシンに kubectl をインストールしてください。

Helm で Falco を Kubernetes にデプロイする

そのためには、Helm がインストールされていることを確認してください。

Falco のインストールには、コミュニティがサポートするチャートを使用します。

まず、falcosecurity のチャートリポジトリを追加して更新します。

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

それでは、helm install コマンドを使って Falco をインストールしましょう。

helm install --set tty=true falco falcosecurity/falco

警告：本番環境では --set tty=false を使用しないでください。ここでは例を簡潔にし、この後すぐに出力を得るために使用していますが、これは標準出力のバッファリングを上書きし、深刻なパフォーマンス問題を引き起こします。これはサービス全般に共通する挙動で、そもそも標準出力はログ記録のためのものです。本番環境では、バッファリングを行わずアラートを即座に出力する他の出力チャネルや Falcosidekick を使用することになります。  

コンテナが起動するまで数秒待ってから、Falco の Pod を特定し、そのコンテナのログを確認しましょう。

$ kubectl get pods
`NAME READY STATUS RESTARTS AGE
`falco-467d7 1/1 Running 0 4m13s
$ kubectl logs falco-467d7
…
Wed Nov 3 15:05:17 2021: Falco initialized with configuration file /etc/falco/falco.yaml
Wed Nov 3 15:05:17 2021: Loading rules from file /etc/falco/falco_rules.yaml:
Wed Nov 3 15:05:17 2021: Loading rules from file /etc/falco/falco_rules.local.yaml:
Wed Nov 3 15:05:17 2021: Starting internal webserver, listening on port 8765
…

Falco が正常にデプロイされたようです！

Falco を実際に試してみる

Falco がデプロイされて動作するようになったので、疑わしいアクティビティを検知できるかどうか見てみましょう。

コンテナは対話的にアクセスされることを想定していないため、コンテナが侵害されていることを示す最大の危険信号の一つが、ターミナルシェルの起動です。これが起こる正当な理由もありますが、通常はトラブルシューティング作業に限られます。

Falco には、こうしたシナリオを検知するためのルールがデフォルトで有効な状態で同梱されています。今回該当するルールは「Terminal shell in container」です。

先ほどデプロイしたのと同じ falco Pod を使って、その中でいくつかコマンドを実行してみましょう。

$ kubectl exec -it falco-4gsbr -- /bin/sh
root@falco-4gsbr:/#

これはデプロイ済みの他のどの Pod でも動作しますが、ここではクラスターに確実に存在することがわかっている Falco の Pod を使っています😉。

ここで Falco のログを確認すると、警告が表示されます。

$ kubectl logs falco-4gsbr
…
Triggered rules by rule name:
16:37:58.199209616: Notice A shell was spawned in a container with an attached terminal (user=root user_loginuid=-1 k8s.ns=default k8s.pod=falco-4gsbr container=b1cfe2fbfcdd shell=bash parent=runc cmdline=bash terminal=34816 container_id=b1cfe2fbfcdd image=falcosecurity/falco) k8s.ns=default k8s.pod=falco-4gsbr container=b1cfe2fbfcdd
…

イベントが発生した Pod とネームスペースについて、Falco がコンテキスト情報を提供している点に注目してください（k8s.ns=default k8s.pod=falco-4gsbr container=b1cfe2fbfcdd）。

次のステップ

Falco が動作するようになったので、ここからは楽しみがたくさん待っています。

次のリソースで旅を続けましょう。

• こちらのウェビナー：Getting started with container runtime security using Falco。
• Falco コミュニティが運営するハンズオンラボ。
• Sysdig による Runtime Security and Falco 101 コース。
• こちらの Falco ワークショップ、そしてこちらも。

Falco プラグインの統合を試すこともできます。

• Gitlab、Box、Salesforce といった SaaS サービス。
• Bitcoin のアクティビティを追跡する。
• ペットの見守りを実装する。
• あるいは、登録済みプラグインの一覧をご確認ください。

その他の Falco プロジェクトにも触れてみましょう。

• イベントを転送するために Falcosidekick をセットアップする。
• 5 分で始める Stratoshark を試す。

そして、Falco プロジェクトに参加したい場合は次のとおりです。

• Falco.org から始めてください。
• GitHub の Falco プロジェクトをご覧ください。
• Falco コミュニティに参加してください。
• Falco Slack でメンテナーに会いましょう。
• Twitter で @falco_org をフォローしてください。

まとめ

Falco は、コンテナ、Kubernetes、クラウドにランタイムセキュリティを実装するための堅実なオープンソースソリューションです。

Falco のクラウドネイティブな設計により、最新のアプリケーション環境で発生するセキュリティイベントを迅速かつ効果的に解決するために必要なコンテキストが得られます。

[1] Gartner, "Open-Source Options for Threat Detection and Incident Response", Anna Belak and Eric Ahlm, 1 December 2020.

‍

‍

Sysdig Secure は、すぐに使えるルールや他のオープンソースプロジェクトによって Falco を拡張し、Kubernetes セキュリティの運用と管理をさらに容易にします。

今すぐデモをご依頼ください！