はじめに

AWS ECS Fargate は、タスク単位で分離された環境でコンテナを実行するサーバーレスなコンテナ基盤です。ホストの管理は AWS が担い、タスクごとに独立した実行環境が割り当てられるため、基盤やタスク間の分離という点では堅牢な構成になっています。

ただし、この分離はあくまで「基盤・タスク間」の分離であり、タスク内で動くアプリケーションそのものを守るものではありません。アプリケーションの脆弱性を突かれれば、コンテナ内に侵入され、不審なプロセスが起動したり、想定外のファイルが作成されたりする可能性はあります。イメージのスキャンやネットワークの制御といった事前の対策を講じていても、こうした「侵入された後」の挙動を完全に防ぎきることは難しく、Fargate 環境でも実行時（ランタイム）の脅威検知と保護は必要になります。

Sysdig Secure は、ホストや Kubernetes 環境では以前から、ランタイムで脅威イベントが検知された際に、プロセスやコンテナを kill する自動対応（レスポンスアクション）を提供してきましたが、2026年6月にリリースされたエージェントの新バージョンにて、ECS Fargate でも自動対応がサポートされました。

本記事では、ECS Fargate 環境で自動対応（Process Kill / Container Kill）の挙動を検証した結果をもとに、仕様や使い分け、注意事項等をまとめます。

Sysdig Serverless Agent v6.3.0 で追加された Process / Container Kill

Serverless Agent v6.3.0（2026年6月18日リリース）では、Workload / Malware ポリシーに対して、ECS Fargate 上での Process Kill / Container Kill アクションがサポートされました。従来は、検知を起点に ECS タスクを停止するなどの処理を自前で実装する構成が必要でしたが、このアップデートにより、脅威検知を起点とした対処を Sysdig 側のアクションで完結できます。

利用できる kill 系のアクションは次の 2 つです。

  • Process Kill: 対象プロセスに SIGKILL を送り、即座に終了します。
  • Container Kill: コンテナを内部のすべてのプロセスごと即座に終了します。

例えば、攻撃者が脆弱性を突いて ECS Fargate タスクに侵入した後、IMDS から AWS 認証情報にアクセスしたり、外部の攻撃者サーバーとリバースシェルを確立した際に、そのプロセスやコンテナを自動で kill することができるようになりました。

参考：Response Actions

検証

検証環境

  • 実行基盤: ECS on Fargate
  • Serverless Agent: 6.3.0
    • サイドカーありの構成
  • 検証対象ポリシー: Workload ポリシー（特定ファイルの読み取りで発火するルール）

Kill 後の挙動に関わる前提として、今回は次の構成で検証しています。

  • ECS サービスの desiredCount は 1
  • ECS タスク定義内で、検知を発生させるアプリコンテナは containerDefinitions で “essential”: true に設定

Sysdig ランタイムポリシーのアクションは「検知のみ」→「Process Kill」→「Container Kill」→「両方」と段階的に切り替え、同じ検知に対して挙動がどう変わるかを確認しました。

なお、Stop / Pause はポリシー UI 上では選択できるものの、ECS Fargate では応答アクションとして機能しません。ホスト/Kubernetes 環境向けのアクションとなっています。

また、コンテナを kill すると証跡が失われることから、Capture 機能も有効化しています。今回は詳細は割愛しますが、検知イベントの前後のシステムコール等の挙動を記録して、後からフォレンジック解析できるようにする機能です。

Process Kill の挙動

Process Kill を有効にして検知させると、Sysdig の Event には Capture に加えて process killed（successful）のアクションが記録されました。

実際に停止したのは検知の原因となったプロセスだけです。今回のアプリはワーカープロセスがファイルを読み込んで検知に至りましたが、停止したのはそのワーカー 1 つのみで、アプリのマスタープロセスがすぐに新しいワーカーを再生成しました。コンテナ（ECS タスク）は再起動されず、アプリケーションもそのまま応答を返し続け、人手の介入なしに復旧しています。

Process Kill は、問題のあるプロセスだけを止めるアクションです。その後、アプリが復旧するか・コンテナが稼働し続けるかどうかは、kill されたプロセスがプロセスツリーのどこに位置するかで決まります。コンテナは、ランタイムが監視する root プロセス（ENTRYPOINT から起動したメインプロセス）が終了すると停止します。そのため、末端の子プロセスを止めるだけであればコンテナは生存しますが、検知されたプロセスがそのコンテナのメイン（root）プロセスだった場合は、Process Kill でもコンテナごと終了し、実質的に Container Kill と同じ影響になります。とくに、マスター/ワーカーのような多段構成を持たず、アプリ本体が単一プロセスで動くコンテナでは、この状況が起こり得ます。

Container Kill の挙動

Container Kill を有効にして検知させると、Event には Capture に加えて container killed（successful）のアクションが記録されました。

こちらはコンテナが内部のプロセスごと即座に終了します。検証環境ではアプリコンテナが essential だったため、コンテナの終了に伴い ECS タスク全体が停止しました（停止理由は Essential container in task exited）。Process Kill と異なり、コンテナがまるごと破棄されるため、コンテナ内の一時的な状態（メモリ・ローカルに書かれたファイルなど）は失われます。

両方のアクションを有効にした場合

Container Kill と Process Kill の両方を同じルールに設定した場合、どちらか一方が優先されるのではなく、両方のアクションが同時に実行されました（Event にも container killed と process killed の両方が successful で記録）。

ただし最終的な結果を決めるのは Container Kill です。コンテナごと終了してしまうため、Process Kill の成否にかかわらず、観測される挙動は「タスクが停止して作り直される」というものになります。

Kill 後の ECS サービス / アプリケーションの復旧

  • Process Kill: 今回の検証環境では、ECS タスクは生存したままでした。また、アプリのマスタープロセスが停止されたワーカーを再生成し、そのまま応答を返し続けました。
  • Container Kill（および両方有効時）: 今回の検証環境では、アプリコンテナは essential かつ ECS サービス配下で desiredCount を設定していたため、コンテナ停止に伴ってタスク全体が停止し、ECS サービスが新しいタスクを起動しました。

なお、いずれの Kill も待機せず即時に終了させるため、対象が処理中だったリクエストや確立済みの接続は失われます（クライアントは再接続が必要になります）。

復旧しないケースおよび注意点

プロセス復旧やタスク再作成は Sysdig の機能ではなく、アプリおよび ECS 側の挙動である点に注意が必要です。前提が異なれば復旧の挙動も変わります。

  • 非 essential なコンテナ（サイドカー等）の場合、そのコンテナが停止してもタスク自体は動き続け、タスクが入れ替わるまでコンテナは欠けたままになります。
  • run-task による単発実行やスケジュールタスクなど、ECS サービス配下でないタスクは、Kill されても再起動されません。
  • ワーカーを再生成する仕組みを持たないアプリでは、Process Kill で停止したプロセスは復帰しません。
  • 検知の原因（脆弱なアプリや侵害された起動処理など）が解消されないままだと、作り直された新しいタスクでも同じ検知・Kill が発火し、Kill と再作成が繰り返される可能性があります。可用性とコストの両面でリスクになります。

更に、ECS タスク復旧後のサービス復旧については、タスクが再作成されても瞬時にリクエストを捌けるようになるわけではない点に注意が必要です。ALB 配下では、新しいタスクがヘルスチェックを通るまでトラフィックは流れないため、desiredCount=1 だとその間は応答できない時間が生じます。復旧を速くしたい・中断を避けたい場合は、ヘルスチェックやデプロイ設定（desiredCount を増やす冗長化を含む）の調整も検討する必要があります。

Process / Container Kill の使い分け

Process Kill

侵入後に起動した単発の不審プロセス（リバースシェル、マイナー、不審なバイナリ実行など）を狙って止め、アプリは動かし続けたい可用性優先の場面に適します。
ただし、可用性を維持できるのは、あくまで侵入後に起動された子プロセスや不審プロセスを封じ込める場合です。アプリのメイン（root）プロセスや正規の稼働プロセス自体が対象になると、コンテナごと停止したり処理が止まったりして、可用性に影響が生じる点は注意が必要です。

また、kill されるのは対象のプロセスだけで、コンテナはそのまま残ります。そのため、ディスクに書かれたファイルなどの痕跡や悪用された原因が残っていると、同じ検知が再発することがあります。さらに、侵害が兄弟・子プロセスまで広がっている場合、それらは kill 対象外です。

Container Kill

コンテナごと破棄してクリーンな状態で再作成できるため、確実な封じ込めが必要な場面に適します。一方で、Process kill より復旧に時間がかかり、サービスの一時中断を伴う可能性があります。

運用上の注意

前提として、Process Kill / Container Kill は Serverless Agent 6.3.0 以上でサポートされている機能のため、既に Sysdig Serverless Agent をご利用中の場合は、6.3.0 以上のエージェントをデプロイした上でご利用ください。イメージタグに latest を使っている場合、6.3.0 以上を確実に動かすには、バージョンを明示するか、タスクの再デプロイが必要です。

自動 kill は誤検知時にアプリケーションへ影響するため、本番環境では最初は検知時のアクションは Capture （と必要に応じて通知）のみで運用を開始し、誤検知があればチューニングを行った上で、誤検知率の低いルールのみ自動対応を有効化する進め方をおすすめします。

おわりに

本記事では、Sysdig Serverless Agent 6.3.0 で追加された ECS Fargate 向けの Process / Container Kill による自動対応を取り上げました。強力な自動対応が ECS Fargate でもネイティブにサポートされ、人手を介さずに速やかに攻撃への対処を行えるようになりました。

弊社の Sysdig 運用サービスにおいても、この機能をご利用いただけます。ECS Fargate で稼働中のアプリケーションの脅威への対策に不安がある、自社での運用が難しい、といった課題がございましたら、ぜひお気軽にご相談ください。