はじめに

前回（第1回）では、Sysdigで検知したイベントをJP1に取り込み、既存の運用基盤に統合できることを確認しました。これにより、コンテナ環境で発生した脅威やポリシー違反を、従来のシステム監視と同じフローで扱える基盤が整いました。しかし、実際のインシデント対応では「検知できること」だけでは不十分です。特にコンテナ環境では、コンテナが短命で自動的に作り替えられるため、インシデント発生直後の"隔離"や"保全"が極めて重要になります。
そこで本記事（第2回）では、Sysdigで検知したインシデントをJP1が受け取り、Illumioによって該当コンテナ・仮想マシンをネットワーク隔離し、さらにインシデント検知時のコンテナ情報を保全する、という一連の仕組みの実現に挑戦していきます。 今回はあくまで構成の紹介が中心で、実際の環境構築の様子や検証結果は第3回以降で詳しく扱う予定です。

背景と課題

コンテナ環境においては、インシデント発生後の対応が従来のサーバ環境とは大きく異なります。これはコンテナという仕組みそのものが、動的で短命であることが理由です。

コンテナ環境特有の課題

• 動的なコンテナライフサイクル
  Pod（コンテナ）の再起動や再スケジューリングが頻繁に発生する特徴があります。
• 証拠が失われやすい
  コンテナのファイルシステムは揮発性が高く、状態がほとんど残りません。ログやコンテナ内部の証跡が消えると、障害発生時の原因分析が困難になります。
• 攻撃者による横展開リスク
  ネットワーク上で他のPod（コンテナ）にアクセスされると、クラスター全体へ影響が拡大します。

このような環境では、インシデントの検知はできても原因分析に必要な情報が残らないという課題が発生します。 そのため、インシデント対応においては隔離しつつ状態を保全するというアプローチが重要になります。

本構成で実現したい仕組み

今回の構成は、Sysdig がインシデントを検知した時に「Sysdig→JP1→Illumio」 という流れで「隔離と保全の自動化」の実現を目指そうという取り組みです。

• Sysdig：不審なふるまいの検知、攻撃当時のPod（コンテナ）周辺の挙動を保存
• JP1：イベント判断＋自動アクション
• Illumio：ネットワーク隔離

このように複数の運用・セキュリティツールを連携させることで、発見から対応までの時間を最小化し、被害拡大防止と分析準備を同時に行うという実践的なセキュリティ運用を目指します。

Illumioのご紹介

Sysdigでインシデントを検知し、JP1でイベントを受け取った後、実際に「隔離」を実行するためには、ネットワークレベルで通信を制御できる仕組みが必要です。そこで本構成では、Illumio（イルミオ） を隔離の実行基盤として採用します。

Illumioとは

Illumioは、ゼロトラストセグメンテーションを実現するセキュリティプラットフォームで、ワークロードやアプリケーションをネットワークレベルで安全に分離・制御するための機能を備えています。

1. Illumioでできること
   • 通信の可視化
     サーバ、コンテナ（Pod）、Namespace、ノード、外部サービスなどのIT資産間で行われる通信の向き、使用されているプロトコルやポート情報をリアルタイムに可視化し、リスクの高い通信を直感的に把握できます。
   • 通信制御（セグメンテーション）
     可視化した情報をもとに、通信の許可または拒否ルールに基づいて通信制御ができます。 IT資産をIPアドレスではなく、アプリ名、役割、環境（開発/本番）、ロケーションなどのラベルを利用して制御できるため、環境変更に強く、運用負荷も大幅に下げることができます。
2. Illumioの強み
   
   1. ネットワーク変更不要の導入性
      IllumioはOS標準ファイアウォール（iptables、Windows Filtering Platformなど）を利用して通信制御を行います。 ネットワーク機器の設定変更や経路変更が不要で、非インライン構成のため導入しやすいという強みがあります、通信制御の性能影響やIllumioの障害影響もないため、障害時の通信断リスクもありません。
   2. ハイブリッド環境を一元管理可能
      サーバ、クラウド、コンテナ、エンドポイントなど、あらゆる環境を1つのプラットフォームで管理ができます。複数環境を扱う場合でも、統一されたポリシー体系で運用が可能です。
   3. ラテラルムーブメント（横展開）の阻止に特化
      攻撃者が横移動する際に使われやすいプロトコルを可視化し、最小限に抑えることで、攻撃者の侵入発生時の拡大を防ぐことができます。また、必要最小限の通信だけを許可する仕組みにより、侵害が発生しても被害範囲を局所化できます。
   4. 大規模環境における長期の運用実績
      国際的な金融機関などの高安定性を求められる環境において、大規模な環境での長期の運用実績が多数あります。シンプルで既存環境への影響が殆どない製品設計が、大規模環境へ容易に導入可能にしています。

今回ご紹介する構成において、Illumioがあることで、「Sysdigが見つけた問題を、JP1が判断し、Illumioが止める」というセキュリティ運用フローの実現が可能です。これにより、被害の拡大防止と同時に、後続の「保全」（コンテナ削除防止）を安全に実行するための基盤が整います。

連携構成の全体像

Sysdig×JP1×Illumio連携全体構成図

各コンポーネントの役割

	分類	コンポーネント	役割
（1）	Sysdig	Sysdig GUI	Sysdig の管理・分析基盤。 エージェントから送られる検知データを基に検知状況の可視化や、 セキュリティポリシーの配布などが可能。
（2）		Sysdig Host Shield	Sysdig のホストエージェント。 ホスト上のイベント・メトリクス収集を行う。
（3）		Sysdig Agent Pod	Kubernetes/OpenShift 環境で動作する Sysdig のコンテナ型エージェント。
（4）	JP1	JP1/IM（JP1/Integrated Management3）	JP1 のイベント統合管理機能を担う。 イベント発生時の通知、監視ルールの適用、自動アクションの実行などが可能で、 運用管理の中核となる。
（5）		JP1/Base	JP1 製品の基盤となる機能を提供。各種ログを JP1 イベント形式へ変換し、 JP1/IM へ転送する役割を持つ。
（6）		Syslog	各種ログを標準形式で収集・転送するための仕組み。 多くの監視・運用システムと連携可能。
（7）	Illumio	Illumio PCE	Illumio の管理機能。各サーバやワークロードにインストールされた Illumio の VEN から 送られてくるネットワーク通信の情報を収集し、その情報を基にネットワーク全体の通信状況を把握。
（8）		Illumio VEN	各ホストに導入するエージェント。通信可視化とマイクロセグメンテーションを実行する。
（9）		Illumio C-VEN	コンテナ化された Illumio エージェント。ノードレベル及び Pod でセキュリティポリシーを適用。
（10）		Illumio Kubelink	各クラスターで単一の Pod として実行され、Pod、Service、Namespace などの K8s データを Illumio PCE と同期。
（11）	OpenShift	Master Node（Control Plane）	クラスター全体の制御・管理を行うノード。
（12）		Worker Node（Compute）	実際に Pod（コンテナ）が動作するノード。
（13）		Red Hat Enterprise Linux Core OS（RHEL Core OS）	OpenShift に最適化された、ノード実行用専用の OS。
（14）		Pod	1つ以上のコンテナで構成される、デプロイ最小単位。

インシデント対応フロー

検知から隔離までの流れとしては

1. Sysdigが不審な挙動を検知
2. Sysdigが検知したイベントをJP1が取得
3. JP1の自動アクションによりIllumioを呼び出し、該当のワークロードをネットワーク隔離
4. 対象がコンテナの場合は、該当のコンテナの情報が削除されないように保全

インシデント対応フロー図

自動隔離に必要な仕組み

• Sysdigで検知したイベントをJP1が取得する方法
  （第1回掲載記事にてご紹介、検証済み）
• JP1からIllumio を呼び出してネットワーク隔離を行う仕組み
  JP1を司令塔として、API経由でIllumioによる隔離（マイクロセグメンテーション）を実行します。
  • JP1の自動アクション
    JP1 IMが特定のSysdigアラートを受信した際に、あらかじめ登録しておいた自動アクション（コマンドの実行）を起動します。
  • 隔離コマンドの実行
    実行されるコマンドの中で、Illumio PCEのREST APIを呼び出します。 Illumio PCEから各ノードのVENへ命令が飛び、対象の通信が即座にブロックされます。
• Pod保護を行う方法
  Kubernetes/OpenShift側で特定のPod（コンテナ）の削除を防止する機能は、今調査している限りでは見つかっていません。そのため、運用として意図的なPod（コンテナ）削除はしないようにしたうえで、攻撃を受けたPod（コンテナ）の情報や、攻撃を受けた当時の状態を証拠として保存することが重要だと考えています。そしてそれらはSysdigで実現が可能と考えています。
  • Activity Audit
    ユーザーやコンテナが実行した操作の履歴を確認できる機能です。 記録される主な情報
    
    • コマンド実行履歴
    • ネットワーク接続履歴
    • Kubernetesの exec / attach の操作
    • ユーザー操作によるファイルアクセスや変更
  • Capture（Sysdig Inspect）
    システムコールレベルの動作を丸ごと記録し、後から詳細解析できる機能です。 記録される主な情報
    
    • システムコール（プロセス・ネットワーク・ファイル操作など OS レベルの全動作）
    • 攻撃やインシデント発生時の前後数秒〜数分の詳細な痕跡

まとめ

今回の記事では、Sysdig・JP1・Illumio を組み合わせることで、仮想マシン環境とコンテナ環境の双方に対応した「検知→隔離→保全」というセキュリティ運用フローの全体構成をご紹介しました。

本構成のメリット

1. インシデント対応の迅速化
   Sysdig が不審な挙動を検知すると、JP1 がイベントを受け取り、Illumio の隔離アクションを自動で実施します。
   • 初期対応の自動化
   • 被害の横展開防止
   • 人手が介入する前に安全状態へ移行
   という流れが実現でき、検知から隔離までの時間を大幅に短縮できます。
2. 証拠保全による原因分析の精度向上
   特に動的なコンテナ環境においては、インシデント発生時の状態を残すことが、原因調査の精度向上に直結します。
3. 既存の運用基盤（JP1）を活用した自動化
   本構成の大きな特徴は、新しいセキュリティ運用を、既存の運用基盤の延長で実現できることです。社内運用チームの負担を増やさずにモダンなインシデント対応を取り入れることが可能となります。

※本記事の内容は特定の検証環境に基づくものであり、記載された手順や構成による動作を保証するものではありません。実際の環境で適用する際は、十分な検証を行ったうえでご利用ください。

今後の連載計画

連載計画は以下になります。
【今回】第2回：自動アクションの検証と、コンテナ・仮想マシン環境のセキュリティ強化を実現する環境構成をご紹介します。 第3回以降：第2回でご紹介する構成について、実際の検証の様子を随時お届けします。

担当者紹介