[レポート] AWS Fargate を含む GuardDuty ECS ランタイムモニタリングのご紹介 #AWSreInvent #SEC239

[レポート] AWS Fargate を含む GuardDuty ECS ランタイムモニタリングのご紹介 #AWSreInvent #SEC239

Clock Icon2023.12.28

こんにちは! AWS 事業本部コンサルティング部のたかくに(@takakuni_)です。

今回は、 re:Invent 2023 の Breakout セッションの 1 つ 「Introducing GuardDuty ECS Runtime Monitoring, including AWS Fargate (SEC239)」 をレポートしていきたいと思います。

セッション概要

Discover how you can benefit from fully managed runtime threat detection for Amazon ECS, including serverless container workloads running on AWS Fargate. Join AWS security and container experts to learn how GuardDuty ECS Runtime Monitoring simplifies organization-wide threat detection for Amazon ECS workloads. GuardDuty ECS Runtime Monitoring gives you visibility into on-host operating system-level activities and provides container-level context to detect and take action on threats to your Amazon ECS workloads on AWS Fargate or Amazon EC2. Don’t compromise on modern application security—get container-aware coverage for your serverless container workloads on AWS with Amazon GuardDuty.

動画

みどころ

本セッションはいくつかのパートに分かれており、各パートで見どころ盛りだくさんでした。

個人的にすごいなぁと思った部分の触りの部分をご紹介できればと思います。

セキュリティ対策の必要性と対象のペルソナ

冒頭、今回発表された機能の紹介ではなく、「なぜサーバレスコンテナでもセキュリティ対策が必要なのか」からセッションがスタートします。また、本機能はアプリケーション所有者をペルソナとして、レビュー表示しているそうです。

機能の有効化

実際にデモ形式で機能の有効化から検知までが行われます。

セッションの合間に検出まで見せれるよう、ひとまず ECS サービスを立ち上げて機能の紹介に戻ります。

ECS の紹介

ECS サービスの起動および、検知の間に ECS の紹介が始まります。

スライドにある通り、 毎週、 22.5 億以上の ECS タスクが起動しているのは圧巻ですね...

また、 「コンテナを初めて利用する顧客の 3 人に 2 人(スライドだと 65 %)がオンボーディングとメンテナンスが簡単という理由で、ECS を選択し、 大多数が Fargate を利用している。」と紹介されていました。日本のみならず、 ECS on Fargate が利用されていることは個人的に衝撃でした。(私の中では、海外は EKS on EC2 のイメージでした。)

顧客事例の紹介

Amazon そのものが我々の最大顧客の 1 つである」として、 amazon.com, Fire TV, Prime Video が ECS 上のワークロードで動いていると述べました。

多くのワークロードを ECS で動かしている部分、 Amazon が ECS への信頼度を高く評価している様子が垣間見えます。

GuardDuty の紹介

合わせて GuardDuty の紹介も行われました。

あらゆる地域、業界、規模の顧客が利用可能な多くの機能を備えたクラウドネイティブな脅威検出サービスを作りたい」をコンセプトにサービスが作られており、サービス提供開始から約 6 年の現在、どのような顧客に利用いただいているかの話が行われます。(この辺りは、GuardDuty よく使ったり、提案するなら見てみることを特にお勧めします。)

機能のキーテナント

ECS Runtime 機能の実装にあたり、開発チーム側で意識したことが紹介されます。

  • 他の検出機能と同等に有効化/無効化くらいの粒度で機能を提供する 1
  • 機械学習を利用して、一連の全体的な攻撃の流れを検出する
  • 広範囲にビジネスインパクトがエスカレーションしていく前に検出してレスポンスを返す
  • 進化し続ける顧客のコンテナワークロードに対して、一元的に可視化や脅威検出を行う

ランタイム機能の歴史に合わせて、 GuardDuty がどこをサポートしているのかマッピングされている説明もとても良かったです。

従来の検知タイプとの違い

従来提供されていた、 VPC Flowlog や DNS ログで検出されるカバレッジとどのように機能差があるのかも取り上げられていました。

図では、 C&C ホストへ接続された場合の挙動の違いになります。コンテキストの量を含め大きな違いがあることがわかります。先ほど説明していた「一連の流れ」とはこの部分を指しているようでした。

エージェント管理について

セキュリティって聞くと、「管理やセットアップが大変そうだな」や、「アプリケーションに影響ないかな」とか導入障壁がある程度存在することは既知の事実です。

このパートでは GuardDuty チームがそれらの障壁に対して、どのようにアプローチしたのかが語られていました。

あくまで GuarDuty Agent コンテナはバックエンドにイベントストリーミングする役割に留め、ルールの判定や機械学習等の計算処理はバックエンド(AWS側)で行う仕組みにすることで、サイドカーコンテナのコンピュートコストの削減やアプリケーションへの動作影響を少なくする部分はとても興味深かったです。

デモ

最後にデモ形式で、検出された結果の解説が行われていました。

繰り返しになりますが、一連の流れをもとに攻撃を理解するため、親プロセスも表示することも可能と説明されていました。

おまけ

今回、有難いことにプライベートベータに参加させていただきました。

体験後にコンセプトや使用感をフィードバックさせていただき、とても貴重な経験になりました。ありがとうございました。

まとめ

以上、「[レポート] AWS Fargate を含む GuardDuty ECS ランタイムモニタリングのご紹介」でした。

これから、ランタイム機能ガンガン使っていくなら、まずは本セッション見ていただくといいと思いました。

この記事がどなたかの参考になれば幸いです。AWS 事業本部コンサルティング部のたかくに(@takakuni_)でした!


  1. GuardDuty のログソースの 1 つで、 VPC Flowlog があります。 VPC Flowlog をログソースとするため、検査したい VPC の Flowlog を有効にすべきと思いがちですが、答えは No です。(裏で独立したデータストリームから直接取得しています。) ログソースの設定をユーザー独自で行わず、 GuardDuty の有効化/無効化のみで完結するシンプルな操作感を、ランタイム機能(サイドカーコンテナの管理も含めて)でも提供したいと言いたかったのではないかと私は妄想しています。 

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.