みなさん、こんにちは！ SCSKの鳥飼です。

SCSK技術者によるSysdigブログ、第36回はSysdig BootCampでも発表したSysdig Secureの新機能、Automationをご紹介します。

「Kubernetes環境でのセキュリティインシデント対応を自動化したいが、どう設定すればいいかわからない......」とお悩みの方にぴったりの内容です。

【🎯この記事のポイント】

• セキュリティ人材の不足と攻撃の高速化により、**運用の自動化（SOAR）**は必須となっている
• SysdigのAutomation機能により、複雑な条件分岐を含む柔軟なインシデント対応が可能になった

【セキュリティ運用における課題】

昨今、セキュリティ人材の不足が深刻な課題となっています。経済産業省のデータによると、日本国内だけでも約11万人のアセットが不足していると言われています。
一方で、AIの普及によりサイバー攻撃は高度化・高速化しています。ある調査では、攻撃者がサーバー内に侵入してから目的を遂行するまでの時間は、わずか数分にまで短縮されているというデータもあります。
このような状況下で、押し寄せるすべてのアラートを人が1つずつ確認し、手動で対応することはもはや物理的に不可能になりつつあります。

【いま求められるSOARの考え方】

この課題を解決するために注目されているのが、ガートナーが提唱したSOAR（Security Orchestration, Automation and Response）です。

• Security Orchestration（オーケストレーション）: 複数の脅威情報やアラートを集約・分析し、判断を支援
• Automation and Response（自動化と対応）: 事前に定義したワークフローに沿って自動で処理を実行

確実性の高いタスクは自動化し、人間は人間にしかできない高度な判断に集中することがSOARのゴールです。

【Sysdigにおける検知と対応の進化】

Sysdigでは、これまでも検知後のアクション機能を提供してきましたが、今回登場したAutomation機能により、その柔軟性が飛躍的に向上しました。

1. Policy Actions（従来の自動アクション）
   ポリシー違反検知時に「プロセス停止」や「コンテナ停止」を即座に実行。シンプルですが、一律の対応になるため「誤検知でサービスが止まる」リスクがありました。
2. Response Actions（手動アクション）
   管理者がUI上で検知アラートを確認し、手動でアクションを実行。確実ですが、対応までのタイムラグが生じ、攻撃の影響が拡大する恐れがあります。
3. Automation（新機能：柔軟な自動ワークフロー）
   検知した振る舞いや脆弱性をトリガーに、条件分岐を含むワークフローを自動実行。「特定のNamespaceのみ隔離する」「ログを取得してから再起動する」といった柔軟な運用が可能になります。

【Automation機能を使ってみた！】

今回はOpenShift環境を利用し、「マルウェア混入」をトリガーに「ネットワーク隔離」「ログ取得」「ロールアウト（正常状態への復旧）」を一気通貫で自動実行させる設定をご紹介します。

○前提条件

• Sysdig Secureアカウントを有していること
• 対象環境にSysdig Shieldがデプロイされていること
• S3バケット連携をしていること(ログ保存用)

○手順

① ポリシーの作成

まず、トリガーとなるマルウェア検知ポリシーを作成します。設定の詳細は、以前のブログを参考にしてください。
https://www.scsk.jp/sp/sysdig/blog/scsk/scsksysdigfalco.html

②ワークフローの作成

1. 右上の "New Automation" ボタンをクリックし、"Runtime Events" を選択します。
2. Condition 1（条件）に、Policy Name in <手順1で作成したポリシー名> を設定します。

③ワークフローの設定

ここからがAutomationの真骨頂です。

Condition1の下部にある "TRUE"を押下し、"Response Action"を選択します。
Response Action1には、"Isolate Network"を選択します。

Response Action 1の下部にある "SUCCESS"を押下し、"Response Action"を選択します。
Response Action2には、"Get Logs" さらに、Inputに "Previous Execution"を選択します。

Response Action2の下部にある "SUCCESS"を押下し、Response Action3には"Rollout Restart"を選択します。

ワークフローの設定はこれで完了です。右上のSaveを押下してワークフローを保存します。

【実行テスト：マルウェアを注入してみる】

① 実際にOpenShift上でマルウェアを模したファイルを配置し、動作を確認します。

$ oc create deploy nginx --image nginx
$ oc get po
NAME                    READY   STATUS    RESTARTS   AGE
nginx-76d6c9b8c-5tdj4   1/1     Running   0          4s
$ oc exec -it nginx-76d6c9b8c-5tdj4 -- bash
root@nginx-76d6c9b8c-5tdj4:/# curl -OL https://github.com/sysdig/TR-Blogs/raw/main/elf_eicar
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 15968  100 15968    0     0  61804      0 --:--:-- --:--:-- --:--:-- 61804
root@nginx-76d6c9b8c-5tdj4:/# chmod +x elf_eicar
root@nginx-76d6c9b8c-5tdj4:/# ./elf_eicar
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

【結果の確認】

Automation画面の Executionsタブを確認すると、設定したワークフローがすべて成功していることがわかります。
また、 [ Threats > Events ]では、マルウェアが作成したポリシーによって検知されていることがわかります。

また、実行結果も確認しましょう。

◇Isolate Network
$ oc get networkpolicy
NAME                           POD-SELECTOR   AGE
sysdig-response-2edd21ae69b9   app=nginx      19s
sysdig-response-79a41275c6cd   app=nginx      20s

◇Get Logs @S3バケット
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2026/02/19 10:03:51 [notice] 1#1: using the "epoll" event method
2026/02/19 10:03:51 [notice] 1#1: nginx/1.29.5
2026/02/19 10:03:51 [notice] 1#1: built by gcc 14.2.0 (Debian 14.2.0-19) 
2026/02/19 10:03:51 [notice] 1#1: OS: Linux 4.18.0-372.49.1.el8_6.x86_64
2026/02/19 10:03:51 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2026/02/19 10:03:51 [notice] 1#1: start worker processes
2026/02/19 10:03:51 [notice] 1#1: start worker process 29
2026/02/19 10:03:51 [notice] 1#1: start worker process 30
2026/02/19 10:03:51 [notice] 1#1: start worker process 31
```


◇Rollout Restart
$oc get events
```
5m42s       Warning   RolloutRestart                               deployment/nginx                                  Sysdig Kubernetes action 'ROLLOUT_RESTART' performed on 'deployment' nginx executing an Automation
```

ワークフローの実行により、各リソースが作成されていることがわかりました。

【まとめ】

今回は、Sysdigの新機能 Automation を紹介しました。 複雑なKubernetes環境において、検知後の一次対応を自動化することは、セキュリティレベルの向上だけでなく、運用担当者の負荷軽減に直結します。
まずは誤検知の少ない明らかな攻撃に対するアクションから自動化を始めてみてはいかがでしょうか。 Sysdigを活用して、よりセキュアでスマートなコンテナ運用を目指しましょう！

担当者紹介

担当者名

鳥飼

コメント

Sysdigを中心にコンテナ、Kubernetes、クラウド領域の業務に従事しています。

保有資格

Certified Kubernetes Administrator