【入門編】コンテナランタイムのセキュリティイベントログ分析 (Falco等) – インシデントレスポンス & フォレンジック（DFIR）防御ガイド

こんにちは！日々の開発やインフラの管理、本当にお疲れ様です。

最近、あちこちの現場で「コンテナ」という言葉を聞くようになりましたよね。DockerやKubernetesを使ってアプリケーションをサクッと動かすのは、今の開発スタイルではすっかり当たり前になりました。

でも、ちょっと立ち止まって考えてみてください。
「コンテナの中って、ぶっちゃけどんな風に守られているか知っていますか？」
「もし、見知らぬ泥棒がコンテナの中にこっそり入り込んだら、どうやって気づけばいいでしょうか？」

今回は、コンテナのセキュリティ監視で大活躍するツール「Falco（ファルコ）」を取り上げます。難しそうなシステムコールやログ分析の世界を、身近な「お家の防犯」に例えながら、一緒に優しく紐解いていきましょう！一歩ずつ対策を学んでいけば、決して怖くありませんよ。

—

1. コンテナのセキュリティって、お家に例えるとどういうこと？

まずは、コンテナの仕組みを身近なものに例えてみますね。

従来のサーバーは、一軒家の大きなガレージのようなものです。家全体（OS）の鍵をしっかり閉めていれば、簡単には侵入されません。
一方、現代のコンテナ技術は、「同じ敷地内に建てられた、たくさんのカプセルホテル（あるいはシェアハウスの個室）」のようなイメージです。壁やドアで区切られてはいますが、水道や電気の根っこ（ホストOSのカーネル）はみんなで共有しています。

もし、あるカプセルホテルの中で、宿泊客がこっそり壁をドリルで穴あけし始めたらどうでしょう？管理人はすぐに気づいて止めに入りたいですよね。

この「壁をドリルで穴あけする音」や「勝手に立ち入り禁止の部屋の鍵を開けようとする音」を、OSのシステムコールというレベルで聞き耳を立てて監視してくれるのが、オープンソースのセキュリティツールFalcoなんです。

—

2. 攻撃者はコンテナの中で何をする？（リアルな侵入シナリオ）

泥棒（攻撃者）は、アプリケーションのちょっとした隙（脆弱性）を突いてコンテナの中に侵入してきます。侵入したあと、彼らが真っ先にやりたがる定番の行動がこれです。

1. 「お邪魔します！」とシェル（命令を打ち込む黒い画面）を起動する
2. パスワードが書いてある大事なファイル（/etc/shadowなど）をこっそり覗き見る
3. 外部の悪いサーバーから怪しいプログラムをダウンロードして実行する

これらはすべて、OSに対する「システムコール（ファイルを開いて！」「新しいプログラムを動かして！」というOSへの要求）」という共通の足音を残します。Falcoは、この足音をリアルタイムで聞き分けて、「おい、今変な音がしたぞ！」と警報を鳴らしてくれる番犬のような存在です。

—

3. Falcoのルールを書こう！身近な防犯カメラの設定

それでは、実際にFalcoがどんな風に不審な動きを見つけているのか、設定ファイル（ルール）を覗いてみましょう。

防犯カメラに「夜間に玄関の窓ガラスが割れる音を検知したらアラートを鳴らす」という設定をするように、Falcoにも「コンテナの中でターミナル（シェル）が起動されたら教えて！」というルールを教えてあげる必要があります。

以下は、実際に使われるFalcoルールの分かりやすいサンプルです。

- rule: コンテナ内でのシェル起動を検知
  desc: セキュリティ上、コンテナ内で対話型のシェル（bashやshなど）が起動されることは通常ありません。不審な侵入の兆候として検知します。
  condition: >
    spawned_process and
    container and
    container.id != host and
    proc.name in (bash, sh, zsh)
  output: >
    【警告】コンテナ内でシェルが起動されました！ 
    (ユーザー=%user.name コマンド=%proc.cmdline コンテナ名=%container.name)
  priority: WARNING
  tags: [container, shell, mitre_execution]

この設定のポイントを優しく解説！

condition: の部分が防犯カメラの条件設定です。「コンテナの中で（container）」かつ「プログラムの名前が bash や sh だった場合（proc.name in ...）」という条件にピタリと一致したとき、作動します。
output: の部分は、警報が鳴ったときにどんなメッセージをSlackやログに飛ばすかのテンプレートです。「誰が」「どんなコマンドを打ったか」が一目でわかるようになっています。
priority: WARNING は、緊急度の高さを示しています。お家の例えで言うなら、窓ガラスが割れたレベルの危険度です。

—

4. ログを正規化してSOC（監視センター）で活用する

Falcoが「ピーッ！」と警報を鳴らしてくれたら、次はそれを私たちが普段見るセキュリティ監視センター（SOC）の画面や、ログ分析基盤（ElasticsearchやDatadogなど）に綺麗に届けてあげる必要があります。これを「ログの正規化」と呼びます。

様々な場所から飛んでくるバラバラな形のログを、綺麗に整理整頓してあげる作業です。

例えば、JSONという形式に整えてあげると、機械がとても読み取りやすくなります。以下のサンプルコードを見てみてください。

{
  "timestamp": "202X-10-25T14:32:10Z",
  "security_tool": "Falco",
  "rule_name": "コンテナ内でのシェル起動を検知",
  "severity": "WARNING",
  "target_container": {
    "id": "a1b2c3d4e5f6",
    "name": "web-frontend-pod-xyz",
    "image": "nginx:latest"
  },
  "process_details": {
    "user": "root",
    "command": "/bin/bash",
    "parent_process": "nginx"
  },
  "message": "【警告】コンテナ内でシェルが起動されました！ (ユーザー=root コマンド=/bin/bash コンテナ名=web-frontend-pod-xyz)"
}

このように、誰が読んでもいつ・どこで・何が起きたのかが綺麗に整理されたログを用意しておけば、インシデントが発生したときも「あ、あのコンテナが危ない！」と秒速で気づくことができるようになります。

—

5. 現場のプロからのアドバイス：誤検知とどう付き合うか？

最後に、現場で実際にFalcoを導入したエンジニアが必ず直面する「あるある話」を一つ。

それは、「最初は警報が鳴りすぎて心が折れそうになる問題」です。

セキュリティのルールを厳しくしすぎると、正当なアプリのアップデートや、開発者さんがメンテナンスで行った正当な操作まで「不審者だ！」と誤検知してしまい、Slackが警報だらけになってしまいます。これでは本当に危ないときに見落としてしまいますよね。

だからこそ、導入の初期段階では次のようなステップを踏むのが大成功のコツです。

1. まずは「通知のみ（Notice/Warning）」のモードで様子見する
いきなり自動でコンテナを止めるような設定（ブロック）はせず、まずは静かにログを溜めて、自社のシステムが普段どんな動きをしているかを観察します。
2. よくある正当な動きを例外リスト（ホワイトリスト）に登録する
「このバッチ処理だけは、定期的に特定のスクリプトを動かす仕様だから除外しよう」といったチューニングを少しずつ行います。
3. 精度が上がってきたら本格的なブロックや即時対応へステップアップ！

—

おわりに

いかがでしたでしょうか？
「コンテナランタイムのセキュリティイベントログ分析」と言われると、なんだか宇宙語のように難しく聞こえますが、要するに「みんなで使っているカプセルホテルの廊下に防犯カメラを置いて、不審な物音をいち早くキャッチする仕組み」のことなんです。

セキュリティは、最初から完璧を目指す必要はありません。「まずはコンテナの中のシェル起動だけでもログに残してみようかな」という小さな一歩が、あなたのお仕事のシステムを、そして大切なデータを守る強力な盾になります。

一歩ずつ、安心して学んでいきましょう！それでは、また次回のブログでお会いしましょう。