はじめに

第1回では、最初のステップとしてSysdigで検知したセキュリティイベントを JP1へ連携するための基礎構成を構築しました。また、第2回では、今回目指している構成のゴールとして、「Sysdig → JP1 → Illumio → OpenShift」という一連の「自動隔離までの全体構成案」のご紹介をしました。複数の製品を跨いで隔離まで到達させるイメージをつかむことを目的に、構成図やフローを含めて全体像を整理しています。
そして今回の第3回では、前回ご紹介した構成案のうち、仮想マシン環境における「Sysdig → JP1 → Illumio」の連携の実現に挑戦していきます。Sysdigの強みを発揮できる場としてコンテナ環境の検証は重要ですが、実運用においては依然として物理・仮想サーバの占める割合が大きく、仮想マシン（VM）を対象とした自動隔離を実現できることは非常に重要な要素となります。そこで自動隔離構成の実現に向けての第一歩として、今回は、VMを対象にした自動隔離構成の実現に挑戦します。本検証の目的は、JP1の自動アクション機能を利用してIllumio APIを呼び出し、対象のVMをネットワーク隔離できることを確認することです。

第1回目記事からの構成変更点

今回の検証から、第1回で採用していたSysdigとJP1の連携方式を見直し、よりシンプルで直接的な構成へと変更しています。第1回では、監視対象にインストールしているSysdig Host Shieldがローカルログとして出力する「host-shield.log」の内容をWindowsイベントログへ転送し、そのイベントをJP1のイベントログトラップ機能を利用してJP1イベントとして監視することで、Sysdig→JP1の連携を実現していました。この方式は Windows 標準のログ機能を活用できる一方で、ログ転送設定が必要となり、SysdigのログがJP1に取り込まれるまでにWindowsイベントログを経由する、本来不要なフローを含む内容となっていました。
今回の検証から、この部分を見直し、Sysdig Host Shieldが出力するログファイルの内容をJP1のログファイルトラップ機能によって直接監視し、JP1イベントへ変換する構成へ変更しています。これにより、Windowsイベントログを中継する必要がなくなり、Sysdig→JP1間の連携フローが大幅に簡素化され、汎用的な構成に更新しました。

連携構成の全体像

< Sysdig×JP1×Illumio連携全体構成図（VM抜粋版）> 

前回掲載した自動隔離の全体構成図のうち、今回の検証範囲である仮想マシン環境での自動隔離構成案のみ抜粋したものです。

 

< 各コンポーネントについて> 

	分類	コンポーネント	役割
(1)	Sysdig	Sysdig GUI	Sysdig の管理・分析基盤。 エージェントから送られる検知データを基に検知状況の可視化や、 セキュリティポリシーの配布などが可能。
(2)		Sysdig Host Shield	Sysdig のホストエージェント。 ホスト上のイベント・メトリクス収集を行う。
(3)	JP1	JP1/IM （JP1/Integrated Management 3）	JP1 のイベント統合管理機能を担う。 イベント発生時の通知、監視ルールの適用、 自動アクションの実行などが可能で、 運用管理の中核となる。
(4)		JP1/Base	JP1 製品の基盤となる機能を提供。 各種ログを JP1 イベント形式へ変換し、 JP1/IM へ転送する役割を持つ。
(5)	Illumio	Illumio PCE	Illumio 全体の集中管理および制御を担う中核コンポーネント。 各 Workload に導入された VEN からシステム情報や通信フローデータを受け取り、 それらを基に Workload 単位のセキュリティポリシーを計算・管理する。 生成されたポリシーは PCE から各 VEN に配布され、 ホスト上で通信制御として適用される。
(6)		Illumio VEN	各ホストに導入するエージェントコンポーネント。 トラフィックフローの収集とレポートを行い、 PCE から配布されるセキュリティポリシーを OS のファイアウォールに適用する。

 

検証内容

今回の検証は、Sysdig×JP1×Illumioの連携構成を検証環境で確認し、以下の目的を達成することを目指します。

< 目的> 

Sysdigで検知したイベントにより、JP1の自動アクションの実行でIllumio APIを呼び出して対象の仮想マシンのネットワーク隔離が自動で行われること。

隔離の方式としては、Illumioが管理するWorkload（VM）に付与されているラベル（Label）を付け替えることで通信ポリシーを切り替え、ネットワークを遮断する仕組みを採用しています。

検証環境の概要

今回の検証では、第1回目の記事でご紹介したSysdigとJP1の連携検証時に使用した環境を活用します。環境の詳細内容は下記に整理したのでご参照ください。

〇Windows環境

• WindowsServer 2022
• Sysdig Host Shield
• Prometheus Bundle
• JP1/Base
• Illumio VEN

〇JP1サーバ

• Windows Server 2022 Datacenter
• JP1/Integrated Management 3
• JP1/Base

Illumio側での事前設定・情報取得

Sysdigが検知→ JP1がイベントを受信→自動アクション実行→ Illumio APIで対象VMを隔離、という流れを成立させるために、Illumio側ではラベル・ポリシー・API利用設定を事前に構成します。

 

1．【Illumio管理画面】隔離用ラベル（Clean / Dirty）の作成

Illumioの「Label Settings」から、検証用に以下の2種類のラベルを作成します。今回は検証用として「Clean」と「Dirty」というラベル名を設定しました。

① Clean：通常状態のVMに付与するラベル
② Dirty：隔離対象とするためのラベル

2.【Illumio管理画面】 ポリシーの作成

次に、Illumioポリシーで通信制御を定義します。 Clean ⇄ Cleanの通信は許可し、Dirtyラベルが付与されたWorkloadはすべての通信が遮断されるよう、Illumio ポリシーを構成します。
作成したポリシーは以下の3つです。

① Clean ↔ Clean の通信を許可するポリシー

② Dirty → 全Workload への通信を遮断するポリシー

③ 全Workload → Dirty の通信を遮断するポリシー

※「全Workload」とは、Cleanラベルが付与されたWorkload、およびDirty ラベルが付与されたWorkloadの両方を含む表現です。

これらのポリシーを利用することで、Dirtyラベルが付与された瞬間に、その仮想マシンは入出力の通信が遮断され、実質的に隔離されます。

3. Illumio API利用の準備

仮想マシンのラベルをAPI経由で変更するため、Illumio側のAPI情報を取得します。

（1） 【Illumio管理画面】APIキーの取得

Illumio ConsoleのService AccountからAPIキー（Authentication Username / Secret）を取得します。後続のPowerShell（curl コマンド）で利用します。

（2） 【Illumio管理画面】組織 IDの確認

APIエンドポイントで必要となるMy Organization IDを「My Profile」から確認します。

（3） 【Illumio管理画面】Clean/Dirty ラベルの UUID 取得

ラベルごとのUUID（Illumio API のエンドポイント）が必要なので、API等を用いてLabelのUUIDを取得します。

JP1自動アクションスクリプト設定概要

JP1では、Sysdigから連携されたイベントをトリガーとして、PowerShellスクリプトを実行することでIllumio API を呼び出し、対象のWorkloadに付与されているラベルを変更するという自動アクションを設定します。

1．スクリプト設定内容

実行させるPowerShellスクリプト内に、事前に取得したAPIキーや組織ID、ラベルのUUIDなどの情報を定義情報に書き換えることで完成させます。本スクリプトでは、主に以下の処理を行っています。

• Illumio APIを利用し、対象となるWorkloadの情報を取得
• 現在付与されているラベルを確認
• 通常状態を示すCleanラベルを解除
• 隔離状態を示すDirtyラベルを付与
• ラベル変更をIllumioに反映することで、事前に定義したポリシーを発動

これにより、セキュリティイベントをトリガーとして、対象Workloadのネットワーク隔離を自動的に実行する構成を実現しています。

　

2．自動アクション機能設定

トリガーとするイベント条件として、イベントの発生元ホスト名、プロダクト名、およびログメッセージを設定しました。
条件に該当するイベントが発生した際に実行する内容として、Illumio APIを呼び出し、ネットワーク隔離を行うスクリプトを指定しました。

 

検証結果

1. Sysdigが検知したセキュリティイベントをJP1/IMが取得できることの確認。

結果：
Sysdig がinfoレベルのセキュリティイベントとして検知し、Sysdig GUIへ通知した旨が記録されたログをJP1/IMで取得し、JP1/IM - Viewに正常に出力されることを確認しました。

〇Sysdig GUI画面

今回の検証では、監視対象の仮想マシン上でユーザーの生成/削除動作を行うことで、意図的にSysdigでセキュリティイベントを検知させることが確認できたため、こちらのイベント（User Account Created）を検証内で利用しました。

〇Sysdig Host Shieldで出力されるログ

{"time":"2026-03-30T12:50:30.232099+09:00","level":"INFO","message":"2026-03-30
03:50:24.928, 29812.29000, Information, endpoint:cm_collector_endpoint:441: Sent msgtype=14
(POLICY_EYENTS) len=795 to collector at host=ingest.ou1.sysdig.com
port=6443","group":"agent-runtime"}

Sysdigでセキュリティイベントを検知すると、Sysdig Agent（Sysdig Host Shield）をインストールしている仮想マシンのローカルログに、上記ログが出力されます。これは、検知したイベントの内容にかかわらず、何かしらのセキュリティイベントを検知し、Sysdig Agent（Sysdig Host Shield）がSaaS上のSysdig GUIへ通信を行った旨を表しています。今回の検証では、このログの内容をJP1に連携しました。 

〇JP1/IM - Viewの[イベントコンソール]画面

[イベントコンソール]画面にてSysdig Host Shieldで出力されたログをJP1イベントとして通知されていることを確認できました。

〇JP1/IM - Viewの[イベント詳細]画面

JP1/IM - Viewの[イベント詳細]画面からSysdig Host Shieldで出力されたログの内容が確認できました。

 

2. Sysdigが検知したセキュリティイベントをトリガーに、JP1の自動アクション機能が実行され、Illumioによるネットワーク隔離が行われることの確認。

結果：
Sysdig が検知したセキュリティイベントをトリガーに、JP1の自動アクション機能の実行によるIllumio APIの呼び出しによって、セキュリティイベントの発生元仮想マシンがネットワーク隔離されることを確認しました。

〇IllumioPCE画面

対象の仮想マシンに「Dirty」ラベルが付与されていることが確認できました。

〇疎通確認

対象の仮想マシンに対するPing通信を試みたところ、Ping通信が届かないことも確認できました。

まとめ

今回の検証では、Sysdig での検知を起点として、JP1の自動アクションから Illumio APIを呼び出し、仮想マシン（VM）のネットワーク隔離を実行する一連の流れを確認しました。手動操作を介さず、製品連携によってセキュリティイベントの検知から隔離まで到達できることを確認できた点は、本構成の有効性を確認するうえで一定の成果が得られたと考えています。
一方で、本検証はあくまで検証環境を前提としたものであり、完全な自動化や実運用を見据えた検証という観点では、いくつかの課題も見えてきました。
一つ目は、セキュリティイベントが発生した Workload の特定方法です。
今回の検証では、対象となる仮想マシンのホスト名をスクリプト内で固定値として指定しましたが、実運用ではSysdigからJP1に連携されるイベントログの内容をもとに、該当するホスト名や Workload 情報を動的に取得する仕組みが必要になります。
二つ目は、セキュリティイベントの取り扱い方法についてです。現状、Sysdig Host Shieldがローカルに出力するログには、検知したイベントの詳細やアラートレベルにかかわらず、「何らかのセキュリティイベントを検知し、SaaSに通信した」という情報のみが記録されます。これは、検知内容の詳細は SaaS上のSysdig GUI 側で確認することを前提とした設計思想によるものです。そのため、今回の構成のようにローカルログのみをJP1のトリガーとして利用した場合、検知内容の重要度にかかわらず Illumio API が呼び出され、ネットワーク隔離が実行されてしまう可能性があります。実運用を想定する場合には、Sysdig SaaS側の検知内容やアラートレベルをどのように連携・判定に活用するかを整理し、隔離対象とすべきイベントを適切に絞り込む仕組みを検討する必要があります。
これらの課題を段階的に整理していくことで、より実践的な自動隔離基盤に近づけていけると考えています。今後は上記の課題についての回避策についても検討していきたいと思います。

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

今後の連載計画

連載計画は以下になります。 【今回】第3回：仮想マシン環境での自動隔離構成の検証の様子をご紹介しました。
第4回以降：第3回で出てきた課題の回避策についての検討やコンテナ環境の構築・検証の様子を随時お届けします。

担当者紹介