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

# はじめに
:::note warn
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 の責任範囲、水色がユーザの責任範囲となっています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3570843/9655bb6c-80cb-5360-eeba-dfc5aaea02ba.png)


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3570843/06da0de9-92b4-8ea0-88fe-4af2da6b2e27.png)

https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/bestpracticesguide/security-shared.html

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

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

![スクリーンショット 2024-03-15 22.00.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3570843/ee71e28f-41d8-cfbc-d9bc-5fec6b942936.png)


https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/bestpracticesguide/security-runtime.html

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

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

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

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



https://sysdig.jp/blog/what-is-container-security/

# 目次
- ベストプラクティスの最新アップデート
- GuardDuty ECS Runtime Monitoring とは
- サービスの特徴
- さいごに

# ベストプラクティスの最新アップデート
英語版の公式ドキュメントを見ていたところ、**GuardDuty Runtime Monitoring の利用がRecommendations に追加されている**ことを発見しました！みなさん知っていましたか？


![スクリーンショット 2024-03-16 9.13.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3570843/d00aa335-9b75-50c7-e6ba-e57339ca6684.png)

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-runtime.html

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

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

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

## 参考情報
【公式】日本語ブログでの紹介記事

https://aws.amazon.com/jp/blogs/news/introducing-amazon-guardduty-ecs-runtime-monitoring-including-aws-fargate/

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

https://www.youtube.com/watch?v=nuMOaQctNgE&embeds_referring_euri=https%3A%2F%2Fengineers.fenrir-inc.com%2F&source_ve_path=Mjg2NjY&feature=emb_logo

# サービスの特徴
## 嬉しい点
- ランタイムセキュリティの観点で**サードパーティーソリューションの代替案**となります。
:::note warn
- GuardDuty ECS Runtime Monitoring は脅威検知のみです。自動でタスクの停止を行いたい場合はEventBridgeなどを用いて別途検討が必要となります。
（例）脅威検知後にECS タスクの自動停止の自動化などが想定されます。
> ECS タスクの自動停止をやってみた例が公開されています。
参考：Amazon GuardDuty ECS Runtime Monitoringで脅威を検出したECSタスクを自動停止してみた
https://dev.classmethod.jp/articles/guardduty-ecs-runtime-monitoring-stop-task/

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

https://docs.aws.amazon.com/guardduty/latest/ug/findings-runtime-monitoring.html

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

![スクリーンショット 2024-03-16 8.26.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3570843/30e50a9d-fc3a-7264-f01e-1a1fec8875a2.png)

https://www.youtube.com/watch?v=nuMOaQctNgE

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

- **東京リージョン、大阪リージョン共に利用可能**です。
:::note 
東京リージョンGA から約1週間後に大阪リージョンでもGA。
東京リージョンが2023/11/26、大阪リージョンが2023/12/6GA。
:::

https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/doc-history.html

## 注意点
- Runtime Monitoring を有効にした場合、**アカウント内の全てのクラスタで有効化**されます。
:::note 
タグの設定によりクラスタ単位で無効にすることが可能です。
「GuardDutyManaged=false」
:::

https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/managing-gdu-agent-ecs-automated.html

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

https://aws.amazon.com/jp/guardduty/faqs/

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

https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/how-runtime-monitoring-works-ecs-fargate.html

- **CodePipeline、Step Functions、Batch 経由で起動されるタスクは非対応**です。
> とくにCodePipeline 経由でデプロイする方が少なくないと思ってます。この辺のサポートはニーズが高そうですね。



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

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

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

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