ブログ

HOME Developer Square ブログ検知から対応をシームレスに！ Sysdigの新機能「Response Action」でインシデント対応を迅速化

2025

08月

29日

OpenShift SCSK技術者ブログ Sysdig Secure Sysdigの新機能コンテナ・セキュリティ

検知から対応をシームレスに！ Sysdigの新機能「Response Action」でインシデント対応を迅速化

こんにちは！ Sysdigブログ第31回は、技術担当の鳥飼がお届けします。

近年、サイバー攻撃はますます高速化しており、インシデント発生時の初動対応が被害の大きさを左右します。検知はできても、その後の対応に時間がかかっていませんか？
本記事では、そんな課題を解決するSysdigの新機能「Response Action」をご紹介します。
検知、調査、そして「封じ込め」までを、いかに迅速かつ安全に行えるようになるのか、ぜひご覧ください。

加速するサイバー攻撃と「封じ込め」の重要性

自動化技術の進化により、サイバー攻撃者がシステムに侵入してから攻撃を完了するまでの時間は劇的に短縮されています。そのため防御側には、インシデントを「検知」し、「調査」し、そして被害を拡大させないために「封じ込め」るまでの一連の対応を、いかに素早く行うかが求められています。
Sysdigは、カーネルレベルの深い可視性により、コンテナ環境での不審な振る舞いをリアルタイムに「検知」し、詳細な記録から迅速な「調査」を可能にする、強力なプラットフォームです。
しかし、最後のステップである「封じ込め」には、ある課題がありました。

自動対応のジレンマ：システムの可用性 vs 迅速な封じ込め

Sysdigには、検知ルールに基づいてプロセスを自動で停止させるなど、脅威を自動で封じ込める機能が備わっています。これは非常に強力ですが、一方でリスクも伴います。
振る舞い検知の性質上、正常なアプリケーションの挙動を「悪意あるもの」と誤検知してしまう可能性はゼロではありません。もし、重要なプロセスを自動で停止させてしまえば、サービス全体が停止してしまう恐れがあります。
この「システムの可用性を損なうリスク」があるため、自動での封じ込め機能の導入をためらうケースも少なくありませんでした。

人の判断を介在させる最適解「Response Action」

このジレンマを解決するのが、新機能「Response Action」です。 Response Actionは、担当者がSysdigの画面でインシデント内容を確認した後、自らの判断でコンテナの停止やファイルの隔離といったアクションを手動で実行できる機能です。

Response Actionのメリット

安全な運用: 担当者が「本当に危険なアクティビティか」を判断してから対応するため、誤検知によるサービス影響を防ぎます。
迅速な対応: インシデントを確認したその画面から直接アクションが可能なため、別ツールへの切り替えやコマンド実行の手間なく、迅速に脅威を封じ込めます。

これにより、システムの可用性を維持しながら、脅威への対応速度を向上させるという、理想的なインシデントレスポンスを実現します。

それでは、Response Actionの具体的な設定方法と使い方を見ていきましょう。

用意するもの

Kubernetes環境 (今回はOpenShift v4.12で検証しました。)
Sysdig Secureライセンス
Helm v3.10以上

Response Actionの有効化

1.values.sysdig.yamlに以下の記述を追加します。
※Host Shieldが13.9.0以上となるよう、shieldチャートを利用してください。

.yaml
features:
  respond:
    response_actions:
      enabled: true

◇参考：
https://github.com/sysdiglabs/charts/blob/main/charts/shield/values.yaml

2.Sysdig Shieldをインストールまたはアップグレードし、エージェントが起動していることを確認します。

$ helm repo add sysdig https://charts.sysdig.com
$ helm repo update
$ helm upgrade --install sysdig-agent --namespace sysdig-agent --create-namespace --values values.sysdig.yaml sysdig/shield

$ oc get po -n sysdig-agent
NAME                                    READY   STATUS    RESTARTS   AGE
sysdig-shield-cluster-cc6d94f6c-4jkkq   1/1     Running   0          2m16s
sysdig-shield-cluster-cc6d94f6c-zchsw   1/1     Running   0          2m16s
sysdig-shield-host-2q8fm                1/1     Running   0          2m15s
sysdig-shield-host-bmlgj                1/1     Running   0          2m16s
sysdig-shield-host-lr65g                1/1     Running   0          2m15s
sysdig-shield-host-mzbph                1/1     Running   0          2m15s
sysdig-shield-host-np77h                1/1     Running   0          2m15s
sysdig-shield-host-pj4lf                1/1     Running   0          2m16s
sysdig-shield-host-qcfbp                1/1     Running   0          2m15s
sysdig-shield-host-skzw6                1/1     Running   0          2m16s

Response Actionを試してみよう!

1.Admin、Advanced UserまたはTeam Managerでログインし、[ Policies > Threat Detection > Runtime Policies ]にて、Sysdig Runtime Notable EventsがONになっていることを確認します。

2.テスト用のhttpd PODを起動し、シェルに侵入。任意のログを削除します。

shell
$ oc run httpd --image=httpd -it -- bash
root@httpd:/usr/local/apache2# rm /var/log/dpkg.log

3.[ Threats > Events ]にて、"Clear Log Activities"イベントが上がっていることを確認し、クリックします。

4."Respond"をクリックすると、実行可能なアクションが選択できます。

5.今回は"Kill Container"を選択してみましょう。

6.Response History より、"Kill Container"に成功したことがわかります。

7.コンテナプラットフォーム側でも確認してみましょう。

PODのdescribeを確認すると、Killされ、コンテナが再度立ち上がったことが確認できます。

$ oc describe po httpd
Events:
  Type     Reason          Age                 From               Message
  ----     ------          ----                ----               -------
  Normal   Scheduled       6m5s                default-scheduler  Successfully assigned default/httpd to ip-10-0-224-187.us-east-2.compute.internal
  Normal   AddedInterface  6m3s                multus             Add eth0 [10.131.2.18/23] from ovn-kubernetes
  Normal   Pulled          6m                  kubelet            Successfully pulled image "httpd" in 3.263931841s (3.263949386s including waiting)
  Normal   Pulling         46s (x2 over 6m3s)  kubelet            Pulling image "httpd"
  Warning  KillContainer   46s                                    Sysdig killed container httpd (id: 11c636404851) after a User request
  Normal   Created         45s (x2 over 6m)    kubelet            Created container httpd
  Normal   Started         45s (x2 over 6m)    kubelet            Started container httpd
  Normal   Pulled          45s                 kubelet            Successfully pulled image "httpd" in 376.952768ms (376.963307ms including waiting)

Response Actionの動作を確認することができました。