日差しが照り付ける暑い夏、みなさんいかがお過ごしでしょうか。
今回は2025-output-lab-containersで得た知見を記録しようと思います。

2025-output-lab-containersとは、2025 Japan AWS Jr. Championsで立ち上がった学習コミュニティの一つです。参加者は、週に2回、コンテナ技術をテーマにもくもく会を実施しています。一人ではなかなか進まない学習も、同志がいれば頑張れますね！

私は、担当しているシステムのホストサーバで専用の不正検知ソフトウェアを導入しているものの、AWSマネージドのインフラストラクチャで動作するECS Fargateの不正検知対策ってどうするの？という疑問から、ECS Fargateのセキュリティ対策についてまとめてみました。

はじめに

みなさん、AWSのECS Fargate使っていますでしょうか。

AWSのコンテナ向けサーバレスコンピューティングサービス「AWS Fargate」。
ホスト管理の必要なくコンテナを動かすことができ、非常に便利なサービスです。

ただし！、サーバレスならセキュリティ対策のユーザ責任も"レス"になるのでは？とお思いの方、残念ですがサーバレスのAWS Fargate環境にもユーザが対策を講じなければいけないセキュリティの責任範囲が存在します。
https://www.trendmicro.com/ja_jp/business/campaigns/aws/column/aws-fargate-202312-01.html

ECS FargateとAWS責任共有モデル

AWSには責任共有モデルという考え方があります。

「クラウド上のシステムやデータの“セキュリティや運用管理”は、どこまでAWSが責任を持ち、どこから先はユーザが責任を持つのか」という役割分担を示した考え方です。

今回は、公式ドキュメントを参照し、ECS FargateにおけるAWS責任共有モデルを以下のように整理してみました。
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/security-shared-model.html

「サーバレス」とはいいつつも、ユーザ責任の項目が結構ありますね...。
金融系システムを担当する私にとって、セキュリティは最重要項目です。
みなさんも、言葉に惑わされず、しっかりとしたセキュリティ対策が必要であることをご認識いただければと思います。（自戒）

（ご参考）
ちなみに、公式ドキュメントではこのようなイメージで、AWS側とユーザ側の責任分界が示されています。

GuardDuty Runtime Monitoringとは

全体像を掴んだところで、ECS Fargateの具体的なセキュリティ対策を考えてみましょう。

Fargate環境のセキュリティを考えるうえで、真っ先に議論のテーブルに上がるものの一つがAmazon GuardDuty Runtime Monitoringです。

改めて、GuardDuty Runtime Monitoringとは、ECS Fargateで動作するコンテナの実行中の挙動を監視し、マルウェアの実行や不審なプロセス、認証情報の窃取など、リアルタイムで「脅威検知」できるAWSマネージドサービスです。

実際にRuntime Monitoringが脅威検知できる主な項目は以下です。

通常ではないネットワークトラフィック
→コンテナからの予期しないアウトバウンド接続。
ポートスキャン活動
→コンテナが他のシステムやサービスのポートをスキャン。
既知の悪意のあるIPまたはドメインへのアクセス
→コンテナが既知の悪意あるIPやドメインと通信。
予期せぬデータ量やパターン
→データ転送量やパターンの大幅な変化。
疑わしいファイルやプロセスの活動
→コンテナ内での通常ではないファイルの変更やプロセスの実行。
異常なユーザー行動
→コンテナ内からの通常ではないログインパターンや特権昇格試み。
侵害されたコンテナイメージ
→既知の脆弱性がある、または悪意のあるコンテナイメージの使用。
暗号通貨マイニング
→CPUまたはGPU使用率の予期しない急増。
コマンド＆コントロール（C&C）通信
→既知のC&C通信プロトコルに一致するトラフィックパターン。
リバースシェルまたは不正なリモートアクセス
→リバースシェルの作成や不正なリモートアクセス試みの兆候。

沢山のセキュリティ脅威に対応してくれてますね！さすがAWS！

ちなみに、冒頭、AWSマネージドのインフラストラクチャで動作するECS Fargateの不正検知対策ってどうするの？の回答になりますが、Runtime Monitoringがまさにその回答でした。Runtime Monitoringの仕組みとしては以下のようで、GuardDutyのセキュリティエージェントコンテナがサイドカーとして起動するようです。

GuardDuty Runtime Monitoringを採用する前に注意点

上記をお読みいただき、セキュリティ対策のためにRuntime Monitoringを使用しようと思った方々、ありがとうございます。

ただし、GuardDuty Runtime Monitoringを導入すれば「すべての脅威が自動的に防げる」というわけではありません。最後に、利用前に必ず知っておきたいポイントをまとめました。

検知＝防御ではない

サービス紹介でさらっと流しましたが、GuardDuty Runtime Monitoringは「脅威検知」が主な役割です。上記のように不審な挙動をリアルタイムで通知してくれますが、その場で攻撃を自動で遮断したり、コンテナを隔離したりする機能はありません。

実際の運用では、GuardDutyのアラートを受けてインシデント対応フロー（例：自動隔離など）を組み合わせて初めて有効なセキュリティ対策となります。

設定ミスや静的脆弱性はカバー外

GuardDutyは「実行時の不審挙動」を監視しますが、例えば下記のようなものは検知対象外です。

▲セキュリティグループの過剰な許可設定
▲S3バケットのパブリック公開
▲コンテナイメージ自体の脆弱性

これらはAWS Config、Security Hub、イメージスキャンなど他サービスでの対策が必要です。

他のコンテナセキュリティ製品との比較

コンテナのランタイムセキュリティ対策にはAWS純正以外にも多くの商用製品があります。たとえば、

■Prisma Cloud（Palo Alto Networks）
■Aqua Security
■Sysdig Secure
■Trend Micro Cloud One – Container Security など

これら商用製品は「脅威検知」だけでなく、自動隔離・遮断・システムコールレベルでの詳細監視やポリシーによる実行制御など、さらに高度な機能を持つものもあります。

GuardDuty Runtime MonitoringはAWSサービスとの親和性や運用の簡便さが強みですが、
より厳格な制御や他クラウドとの統合が求められる場合は、商用製品の導入も検討する必要があるかと思います。

デリバリー・コスト比較も忘れずに！Runtime Monitoringはポチポチ数回の操作で有効化が可能です。また、GuardDutyでは30 日間無料トライアルの期間中、GuardDuty コンソールまたは API オペレーションを使用して、GuardDuty の 1 日の平均使用コストを推定できます。
https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/runtime-monitoring-configuration.html
https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/monitoring_costs.html

まとめ

最後に、結局伝えたいことして、AWS Fargateのセキュリティは、

責任共有モデルを正しく理解し、
GuardDuty Runtime MonitoringなどのAWSマネージドサービスや商用セキュリティ製品、他AWSサービスを組み合わせて多層防御を実施することがポイントです。（根本の考え方はホストと変わらない！）

みなさんも、自社の要件やリスクに合わせて最適なセキュリティ設計を進めてみてください！

本記事がどなたかのご参考になれば幸いです。