はじめに

本シリーズでは、Sysdig・JP1・Illumio の3製品を連携し、セキュリティイベント検知を起点とした自動隔離の実現を目指した検証を行っています。
前回の記事では、仮想マシンを対象に、Sysdig Host Shieldの検知をJP1のトリガーとし、Illumio APIによってネットワーク隔離を実行できることを確認しました。一方で検証を進める中で、実運用を想定した場合の課題も明らかになりました。Sysdig Agent のローカルログは、その設計上「セキュリティイベントを検知し、SaaSへ送信した」という事実のみを出力し、検知内容の詳細や重要度はSaaS側での確認が前提となっています。このため、ローカルログのみを判定材料として自動隔離を行うと、イベントの重要度にかかわらず隔離が実行され、過検知・過剰隔離につながる懸念があります。
そこで本記事では、前回の検証で浮き彫りになったこの課題に対する整理と解決に向けた検討内容について紹介します。

前回検証で顕在化した課題の整理

前回の検証では、Sysdig Host Shieldが出力するローカルログを JP1 で監視し、セキュリティイベント検知をトリガーとして Illumio API を呼び出す構成を採用しました。この構成により、仮想マシンを対象として検知からネットワーク隔離までの一連の流れが成立すること自体は確認できました。
しかし、検証を進める中で、Sysdigの検知イベントの扱い方に関して課題が明確になりました。
Sysdig Host Shieldのローカルログには、検知内容の詳細や重要度は出力されず、「何らかのセキュリティイベントを検知し、SaaS側へ送信した」という情報にとどまります。このローカルログのみをJP1のトリガーとして利用した場合、以下のような情報を判別できません。

• 検知ルールの種類
• イベントの重要度（High / Low など）
• 調査目的の検知・誤検知か、実際の脅威か

その結果、軽微なイベントや確認目的の検知であっても隔離が実行され、過検知・過剰隔離につながる可能性が高いという点が、実運用を想定した場合の大きな懸念点となりました。この課題を解消するためには、ローカルログに依存しない設計を検討する必要があります。

課題解消案の紹介

前章で整理した通り、Sysdig Agentのローカルログを起点とした場合、イベントの詳細や重要度を判別できず、過検知・過剰隔離につながる点が大きな課題となります。この課題に対しては、大きく以下の2つのアプローチが考えられます。

１． Sysdig Automations機能の活用

1つ目は、Sysdig Secureが提供するAutomations機能を活用するアプローチです。
Automationsは、Sysdig SaaS上で検知する怪しいふるまいや脆弱性といった様々なセキュリティイベントに対して、条件に応じたアクションを自動実行するワークフロー機能です。フィルタや条件分岐が柔軟で、Slackやメール、Webhook等への通知や、クラウド・コンテナ環境へのレスポンスアクションも可能です。
この機能を活用することで、「どのイベントを隔離対象とするか」をSysdig SaaS側で事前に定義し、不要なイベントを排除した上で外部連携に渡すことが可能になります。

＜メリット＞

• SaaS側でフィルタリング済みのため、過検知を抑制できる
• 条件分岐が柔軟で、運用ルールを集約可能
• Sysdig Secure一つで完結

＜留意点＞

一方で、Sysdig Secure（およびAutomations）はクラウドネイティブ／コンテナ環境を前提とした機能設計となっており、多数のアクションが、「Kubernetes」「コンテナ」「Cloudリソース」を直接対象としています。そのため、Windows 環境を対象とした制御では適用範囲が限定されます。

 

２． Sysdig SaaSとJP1の直接連携（API / SDK活用）

2つ目は、Sysdig SaaSが保持するイベント情報をAPI経由で直接取得し、JP1へ連携するアプローチです。従来のようにローカルログに依存せず、SaaS側で解析済みのイベント情報を直接利用することで、より精度の高い制御が可能となります。

＜Sysdig SaaS×JP1の直接連携構成イメージ図＞

API経由でSysdig SaaSからイベントを取得することで、検知イベント名や発生ホストなどの詳細情報をもとに、「特定イベントのみ対象」といった粒度の高い制御が可能になります。これにより、過検知や過剰隔離を抑えつつ、実運用に耐えうる自動隔離を実現できるのではないかと考えています。
また、SaaS側で解析された情報を活用できるため検知精度が向上するほか、スクリプトによる柔軟な条件分岐やデータ整形が可能であり、既存のJP1運用にそのまま組み込める点も大きなメリットです。一方で、本方式ではSysdig SaaSへ定期的にイベント情報を取得しにいく構成となるため、完全なリアルタイム制御にはならない点は考慮が必要です。

 

まとめ

本記事では、前回検証で顕在化した「ローカルログ依存による過検知・過剰隔離」の課題に対し、「Sysdig Automationsの活用」と「Sysdig SaaSとJP1の直接連携」という2つの解決アプローチを紹介しました。
Automations は、Sysdig 単体で完結した自動化を実現できる一方で、Windows 環境や既存運用との適合性に課題があります。一方、Sysdig SaaS と JP1 の連携方式は、実装の自由度が高く、既存の運用基盤を活かしながら精度の高い自動隔離を実現できる点が大きな強みです。
特に後者のアプローチでは、Sysdig SaaSが持つ詳細なイベント情報を活用することで、単純な検知トリガーではなく、「検知内容に応じた制御」を前提とした自動化が可能となり、実運用を見据えた設計に近づけることができました。一方で、定期的に情報を取得する構成となるため、リアルタイム性には一定の制約がある点についても考慮が必要です。

比較観点	Sysdig Automations機能	Sysdig SaaS ＋ JP1 連携方式
リアルタイム性	〇	△ スクリプトの実行で定期的に情報を取得していく構成のためリアルタイム性には欠けるものの、タスクスケジューラでの実行の場合は、最短1分間隔で取得可能
検知イベントの粒度・詳細取得	〇	〇
条件分岐の柔軟性	〇	〇
既存運用への組み込みやすさ	△ Sysdig Secureで完結する仕組みであり、 既存の監視製品との連携は前提とされていないため、新たに導入する場合は運用負荷が発生する	〇

それぞれ強みが異なるため目的に応じて適したユースケースが異なると考えています。
Automationsは、Sysdig単体で完結するリアルタイム性の高い自動化に適しており、特にコンテナやクラウドネイティブ環境においては有効な選択肢となります。これに対し、Sysdig SaaSとJP1を連携する方式は、検知内容や発生元ホストといった詳細情報をもとに柔軟な制御が可能なだけでなく、既存のJP1運用に組み込める点が大きな強みです。既存の監視運用フローに組み込みながら、他システムとの連携や運用ポリシーに応じた制御を行いたい場合には、本アプローチがより適していると考えます。
このように、それぞれに適した利用シナリオは異なるものの、本検証においては既存のJP1運用をベースに、他製品との連携まで含めた自動化を実現していきたい思いもあるため、Sysdig SaaSとJP1の直接連携方式を利用した改修を検討していきます。

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

今後の連載計画

連載計画は以下になります。
【今回】第4回：連携検証で顕在化した課題とその解消方法の検討についてご紹介しました。 第5回以降：コンテナ環境の構築・検証およびSysdigとの連携についての様子を随時お届けします。

担当者紹介