はじめに

2024/3/15時点の情報を元に執筆した記事です。

NTTデータの西川です。
普段は公共部門の技術集約組織でクラウドの導入支援に従事しています。

みなさんはECS を普段利用していますか？AWS でコンテナを利用する際に、ECS on Fargate の組み合わせを採用するケースが少なくないと思います。

ECS on EC2 ではなく、ECS on Fargate を採用する理由の1つとして、AWS の責任共有モデルに従ったセキュリティ観点のメリットが挙げられます。具体的にはパッチ適用、サーバのスケーリングなどがAWS の責任範囲となるため、データプレーンにおけるホストの管理負荷が軽減できます。

データプレーン：コンテナを稼働させる環境。Fargate やEC2 が該当します。
コントロールプレーン：コンテナを管理する環境。ECS やEKS が該当します。

参考までに責任共有モデルを見てみましょう。
1つ目の画像がECS on EC2、2つ目の画像がECS on Fargate における責任共有モデルです。
後者のECS on Fargate がユーザ側の責任箇所が少ないことがわかります。
※オレンジ色がAWS の責任範囲、水色がユーザの責任範囲となっています。

ユーザ側の管理負荷が少ないことで定評があるECS on Fargate ですが、日本語版のECS ランタイムセキュリティに関するベストプラクティスを見てみると以下の記載があります。

Recommendations
ランタイムセキュリティにサードパーティーソリューションを使用する。
※ECS ランタイムセキュリティに関するベストプラクティスより抜粋。

ランタイムセキュリティはコンテナの実行環境のふるまいを監視し、異常なふるまいを検知した際に通知や停止を行うことを指します。

AWS 公式のベストプラクティスとしてランタイムセキュリティとしてサードパーティーソリューションの導入が推奨されています。

本ブログでは、ECS ランタイムセキュリティに関するベストプラクティスのアップデートを発見したので、おそらく最速でレポートします！

【補足】
コンテナランタイム：コンテナランタイムは、コンテナを実際に実行するサーバ上のプロセスです。ランタイムソフトウェアが最新のものであり、既知のセキュリティ脆弱性に対してパッチが適用されていることを確認する必要があります。
引用元：コンテナセキュリティとは？（Sysdig Blog）

ベストプラクティスの最新アップデート

英語版の公式ドキュメントを見ていたところ、GuardDuty Runtime Monitoring の利用がRecommendations に追加されていることを発見しました！みなさん知っていましたか？

上記の情報は日本語版のドキュメントには反映されていません。（2024/3/15時点）
最新状況の確認には、英語版の確認が必須だと再認識しました。

Amazon GuardDuty ECS Runtime Monitoring とは

ざっくり言うと、マネージドなサーバレスコンテナのための脅威検出サービスです。これまでEKS やEC2 のみ利用可能であったGuardDuty Runtime Monitoring が、2023/11/26からECS でも利用可能となりました。GuardDuty ECS Runtime Monitoring はOS レベルの監視および分析を行い、潜在的な脅威検出のサポートに役立ちます。

GuardDuty EC2 Runtime Monitoringはプレビューリリースです。

参考情報

【公式】日本語ブログでの紹介記事

【公式】Youtube（re:Invent 2023 のセッション）

サービスの特徴

嬉しい点

ランタイムセキュリティの観点でサードパーティーソリューションの代替案となります。

GuardDuty ECS Runtime Monitoring は脅威検知のみです。自動でタスクの停止を行いたい場合はEventBridgeなどを用いて別途検討が必要となります。
（例）脅威検知後にECS タスクの自動停止の自動化などが想定されます。

ECS タスクの自動停止をやってみた例が公開されています。
参考：Amazon GuardDuty ECS Runtime Monitoringで脅威を検出したECSタスクを自動停止してみた
https://dev.classmethod.jp/articles/guardduty-ecs-runtime-monitoring-stop-task/

ランタイムセキュリティ以外の観点でサードパーティーソリューションが不要かどうかは別途検討が必要となります。
（例）ネットワークのふるまい検知などが想定されます。

３１種類の脅威検知に対応しています。

（例）マルウェア感染、マイニング、ランタイムドリフト、コンテナエスケープ、リモートコード実行、防御回避など
引用元：Introducing GuardDuty ECS Runtime Monitoring, including AWS Fargate (SEC239)

不審なアクティビティのプロセスID が分かります。
脆弱性があるコンテナイメージが特定できます。
GuardDuty の検出結果をSecurity Hub やDetective などと連携可能です。
東京リージョン、大阪リージョン共に利用可能です。

東京リージョンGA から約1週間後に大阪リージョンでもGA。
東京リージョンが2023/11/26、大阪リージョンが2023/12/6GA。

注意点

Runtime Monitoring を有効にした場合、アカウント内の全てのクラスタで有効化されます。

タグの設定によりクラスタ単位で無効にすることが可能です。
「GuardDutyManaged=false」

GuardDutyはリージョンサービスのため、正確にはアカウント内で有効化したリージョン内の全てのクラスタで有効化されます。
参考：GuardDuty は、リージョン別またはグローバルのどちらのサービスですか?

Runtime Monitoring 有効化前にタスクが実行状態になっている場合は、再起動が必要となります。

CodePipeline、Step Functions、Batch 経由で起動されるタスクは非対応です。

とくにCodePipeline 経由でデプロイする方が少なくないと思ってます。この辺のサポートはニーズが高そうですね。

さいごに

これまでEKS やEC2 のみ利用可能であったGuardDuty Runtime Monitoring が
「ECS で利用可能」＆「AWS 公式のベストプラクティスのドキュメントで推奨」となりました。

これからECS に関するランタイムセキュリティの検討を行う必要がある方は是非参考にしてみてください！

個人的にはGuardDuty ECS Runtime Monitoring の運用面のベストプラクティスが気になるところです。これからAWS公式情報やコミュニティなどできっと出てくると思うので、注目していこうと思います。

最新状況については公開情報をご確認ください。
※ 本ブログに記載した内容は個人の見解であり、所属する会社、組織とは関係ありません。

【ECS on Fargate】最速レポート!?ランタイムセキュリティに関するベストプラクティスのアップデート