re:Invent 2024: AWSによるECSワークロードのセキュリティ強化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Securing Amazon ECS workloads with AWS Signer and Amazon GuardDuty (SVS342)
この動画では、Amazon ECSのセキュリティベストプラクティスについて、3つの重要な観点から解説しています。1つ目は、Amazon Inspectorを用いたコンテナイメージの脆弱性検出と管理の自動化です。2つ目は、AWS Signerを活用したコンテナイメージの署名と検証による信頼性の確保です。3つ目は、Amazon GuardDuty ECS Runtime Monitoringによるランタイムセキュリティの実現です。特に、AWS Fargateを使用する場合、GuardDuty AgentがSidecarコンテナとして自動的にデプロイされ、Command and Control攻撃などの脅威を検出できる点が注目です。これらの機能をCI/CDパイプラインに組み込むことで、スケーラブルなセキュリティ管理を実現できます。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon ECSのセキュリティベストプラクティス：本日の講演概要
私はMaiと申します。オーストラリアから来ました。オーストラリアとオリンピックを組み合わせると何が出てくるでしょうか？そう、ブレイクダンスです。今日はブレイクダンスを見たい方いらっしゃいますか？冗談です。冗談はさておき、本日は私と共同発表者のSaiが、Amazon ECSのベストプラクティスについてお話しさせていただきます。ECSのセキュリティベストプラクティスを分かりやすく解説し、CI/CDパイプラインを通じて自動化する方法をご紹介します。これにより、皆様の作業負担を軽減することができます。
ありがとうございます、Mai。皆様、こんにちは。私はソリューションアーキテクトとして、日々お客様とコンテナソリューションの設計に携わっており、どのようなアーキテクチャでもセキュリティは最重要な議題となっています。コンテナには独特のセキュリティ課題があるとおっしゃるお客様もいらっしゃいます。本日は、コンテナがもたらす特有のセキュリティ課題と、私たちが解決しようとしている3つの一般的なポイントについて探っていきます。これらのセキュリティ問題をどのように解決するのか、詳しく見ていきましょう。
コンテナのセキュリティ課題：スケーラビリティと多様性
まず、コンテナのセキュリティ課題についてお話しします。コンテナはスケーラブルであることは皆様ご存知の通りです。私たちは多くのコンテナをデプロイし、トラフィックに応じてスケールアウトやスケールインを行うため、常に多数のコンテナが稼働しています。コンテナは一時的な性質上、短命です。そのため、コンテナ内で発生している可能性のあるセキュリティ脅威を特定することは非常に困難です。なぜなら、その時にはもう存在していないからです。また、コンテナは多様です。単一の環境で多くのコンテナが稼働していますが、同じアプリケーションを実行しているとは限りません。フロントエンドアプリケーション、バックエンドアプリケーションなど、様々なものがあり、単一環境で稼働する異なるタイプのアプリケーションすべてに同じセキュリティ対策が適しているとは限りません。
現在、環境でGolden Imageを使用している方はどのくらいいらっしゃいますか？コンテナに関しては、パブリックソースからDockerイメージを取得することもあります。安全でないソースからイメージが取得される可能性もあり、専門知識の不足、アクセスレベルの制限、コンテナの可視性の欠如により、完全な可視性を得ることができません。なぜなら、コンテナの役割は、起動してタスクを実行し、終了することだからです。コンテナのパフォーマンスを正確に理解するためには、過去に何が起こったかを把握するために、ロギングやその他の可観測性ツールを実装する必要があります。
コンテナはスケーラブルで、短命で、多様で、安全でないソースから取得される可能性があるため、これらすべての特徴が、どの環境でも実装可能な独特のセキュリティ課題をもたらします。本日は、Amazon ECSワークロードにおける3つの一般的なセキュリティの課題を解決していきます。脆弱性の検出と解決を自動化していますか？コンテナイメージが改ざんされていないことをどのように確認していますか？ランタイムの脅威も検出・防止していますか？
Amazon ECSとAWS Fargateの概要：サーバーレスコンピューティングの利点
セキュリティの詳細に入る前に、Amazon ECSについて簡単におさらいしましょう。Amazon Elastic Container Serviceは、クラウドでコンテナアプリケーションのデプロイ、管理、スケーリングを支援する、フルマネージド型のコンテナオーケストレーションサービスです。AWS Fargateと呼ばれるエンタープライズグレードのサーバーレスコンピューティングを提供しています。お客様はEC2インスタンス上にコンテナをデプロイすることも、Amazon ECS Anywhereを使用して自社所有のハードウェア上にデプロイすることもできます。Amazon ECSはシンプルでありながら、非常にパワフルなサービスです。
Amazon ECSは長年提供されているサービスで、週に24億以上のAmazon ECSタスクが起動されており、新規のコンテナユーザーの65%以上がAmazon ECSを使用しています。その大半がAWS Fargate上でワークロードを実行しています。皆さんの中で、すべてのワークロードでAWS Fargateを完全に使用している方は何人いらっしゃいますか？もう一つ重要な点として、Amazon ECSはAmazon Prime Day 2024で7,720万以上のタスクを起動しました。このことからも、シンプルで簡単なデプロイを維持しながら、いかに大規模にスケールできるかがお分かりいただけると思います。
AWS Fargateについても簡単におさらいしましょう。AWS Fargateはコンテナ向けのサーバーレスコンピュートで、設計上の分離性とセキュリティを提供します。初期費用は不要で、実行中または使用中のリソースに対してのみ料金が発生します。また、コスト効率の良いワークロードと節約のために、Fargate SpotやAWS Gravitonを使用することもできます。
それでは、AWS Fargateのセキュリティについて話しましょう。Fargateを使用する場合、 アップグレードやパッチ適用が必要なコンテナホストは存在しません。また、クラスターキャパシティの管理も必要ないため、Auto Scaling Groupを作成したり、コンテナを実行するためにどのインスタンスタイプを起動すべきか心配したりする必要もありません。分離による改善されたセキュリティとは、AWS Fargateを使用する際、Amazon ECS上の各タスクが別個のカーネルで実行されることを意味します。
右側にご覧いただけるように、AWS Fargateの責任共有モデルでは、お客様の責任範囲は、お客様データ、アプリケーション、IAM（Identity and Access Management）、そしてネットワークアクセスとファイアウォールの設定のみとなっています。AWS Fargateを使用することで、分離されたコンピュート、専用のENI、専用のストレージ、アプリケーションにスコープされた認証情報、そして常にパッチが適用されたインフラストラクチャを手に入れることができます。このように、Fargateが自動的にセキュリティ機能の一部をAmazon ECSにもたらしていることが分かりました。では、コンテナについて詳しく見ていきましょう。
コンテナイメージのセキュリティ強化：Amazon ECRとAmazon Inspectorの活用
コンテナイメージから始まり、コンテナ、そしてAmazon ECSタスクへと進む、シールドライト戦略について見ていきましょう。コンテナイメージに関して、フルマネージドのコンテナレジストリサービスであるAmazon ECR（Elastic Container Registry）を使用している場合、イミュータブルタグを有効にすることができます。イミュータブルタグを有効にすることで、そのレジストリ内のDockerイメージのイメージタグの上書きや削除を防ぐことができます。これにより、環境で実行されているコンテナイメージを簡単に参照でき、イメージが悪意のあるタグや意図しない変更で改ざんされていないことを確認できます。
Amazon ECRは基本スキャンと拡張スキャンの両方を提供しており、本日はそれについて詳しく説明していきます。イメージの署名も重要で、Dockerイメージが改ざんされていないことを確認するのに役立ちます。署名されたイメージのみが環境にデプロイされ、署名されていない場合は自動的に拒否されます。ソフトウェアバージョンの一貫性は最近追加された新機能の1つです。ECS Deployment ControllerでAmazon ECSサービスを使用している場合、ソフトウェアバージョンの一貫性はデフォルトで確保されています。これにより、新しいデプロイメントが異なるイメージタグを参照している場合でも、デプロイメントのライフサイクルを通じて同じイメージダイジェストがデプロイされることが保証されます。
次に、コンテナについて見ていきましょう。コンテナでは、常にno privilegeモードを使用します。AWS Fargateを使用している場合、no privilegeモードのみがサポートされています。no privilegeモードを使用することで、コンテナがコンテナホストにアクセスすることを許可しません。AWS Fargateではそれは不可能ですが、EC2起動タイプを使用している場合は、no privilegeモードを使用することで、コンテナがコンテナホストにアクセスして変更を加えることができなくなり、そのホスト上で実行されている他のすべてのコンテナに影響が及ばないようにします。適切な場所では非rootユーザーと読み取り専用ファイルシステムを使用し、ランタイムモニタリングを実装してください。
Amazon ECSタスクでは、インバウンドとアウトバウンドの両方のルールを持つセキュリティグループを付加して管理できるため、Amazon ECSタスクがアクセスする必要のあるエンドポイントを制御できます。Secretsを使用し、特に環境変数には機密情報をプレーンテキストで保存しないでください。機密情報がある場合は、その特定の領域でSecretsを使用してください。また、タスクロールとタスク実行ロールがあり、これにより特定のアプリケーションが定義されたAWSサービスにのみアクセスできるようになります。例えば、Amazon S3にアクセスする必要があるアプリケーションの場合、タスクIAMロールを使用することで、そのアプリケーションはS3の特定のバケット、あるいはそのバケット内の特定のオブジェクトにのみアクセスできるようになります。
先ほど話したように、コンテナは短命であるため、実行中のコンテナのパフォーマンスを把握することは非常に重要です。そのため、コンテナログが確実に実装されているようにしてください。
スケーラブルな脆弱性管理：Amazon InspectorとSBOMの実装
それでは、コンテナイメージについて詳しく見ていきましょう。ここからは、コンテナイメージのセキュリティ脆弱性の実装と自動化について深く掘り下げていくMaiにバトンタッチします。 ありがとうございます、Sai。では、なぜスケーラブルな脆弱性管理が必要なのか、お話ししていきましょう。10年以上前を振り返ると、私は大規模な病院のシステム管理者として働いていました。それはちょうどWannaCryという脆弱性が問題になっていた時期でした。システム管理者として、オンプレミスの仮想マシンやワークステーションに確実にパッチを適用する任務を担っていました。ワークステーションの問題は、ネットワーク接続が断続的だったことです。仮想マシンのパッチ適用は自動化できましたが、病院中に散らばったワークステーションを探し回らなければなりませんでした。ワークステーションを見つけても、パッチ適用が完了するまでそこに立って待っていなければならず、とてもスケーラブルな脆弱性管理とは言えませんでした。パッチ適用の完了まで数週間もかかってしまいました。
2024年の現在に目を向けると、仮想マシンはコンテナイメージに置き換わっています。最新のコンテナイメージに含まれるすべてのソフトウェアコンポーネントを即座に把握できる人はどれくらいいるでしょうか？ほとんどいないでしょう。 それらのソフトウェアコンポーネントに関連する可能性のある脆弱性についてはどうでしょうか？ビジネスが拡大するにつれて、管理すべきコンテナイメージの数は増えていきます。そのため、コンテナイメージとそれに潜在する脆弱性の管理は非常に煩雑になってきます。 また、公共部門や金融サービス分野で働いている場合は、コンプライアンス要件にも注意を払う必要があります。グローバルに事業を展開する場合は、各地域の法令遵守要件にも対応しなければなりません。
手作業のプロセスについて言えば、これらの脆弱性への対応をどのように迅速に行えばよいのでしょうか？検出された脆弱性に対するアラートを有効にしていたとしても、それらをどのように管理していけばよいのでしょうか？アラート疲れを経験している可能性もあります。 ここで役立つのがAmazon Inspectorです。InspectorはAWSのネイティブセキュリティツールで、Amazon Elastic Container Registryに保存されているコンテナイメージの潜在的な脆弱性をスキャンする機能を提供します。また、AWS Lambda関数やAmazon EC2インスタンスとも連携し、リアルタイムでスキャンを実行します。修正が必要な脆弱性の優先順位付けについては、Inspector Risk Scoreを参照することで、迅速な対応が可能です。
何より素晴らしいのは、InspectorをAWS Organization内のすべてのAWSアカウントで、たった1クリックで有効にできることです。そして重要なのは、SBOM（Software Bill of Materials）です。ソフトウェア部品表リストを一元管理できるため、DevOpsチームとセキュリティチームの双方にとって朗報です。Amazon Inspector APIエンドポイントを使用してワークフローを自動化できるほか、イベントハブサービスであるAmazon EventBridgeとの統合も可能です。AWS Lambda関数を使用して脆弱性を自動的に修正することもできます。また、AWS Security Hubとの統合により、すべてのアラートを1か所で管理できます。
Software Bill of Materials（SBOM）について詳しく見ていきましょう。 SBOMは基本的に、ソフトウェアの依存関係やライブラリを含むネスト化されたリストです。SBOMは単一のリソースに対してエクスポートすることも、複数のAWSアカウントにまたがる多数のリソースに対してエクスポートすることも可能です。さらに、スキャニングと統合することもできます。
Amazon Inspectorを使用すると、オペレーティングシステムや各種プログラミング言語のスキャンを無料で統合できます。さらに素晴らしいことに、標準的なSQLクエリツールであるAmazon Athenaや、結果を可視化するためのAmazon QuickSightなどのネイティブな分析サービスを使用して、さらなる分析を行うことができます。それでは、Amazon InspectorがどのようにCI/CDツールと連携するのか見ていきましょう。
GitHubやTeamCity、Jenkinsをお使いの方は、すでにCI/CDツールをお持ちですが、そこにAmazon Inspectorを統合することができます。これらのツールを使用していない場合でも、InspectorのSBOMジェネレータAPIを使用して、独自のカスタムオーケストレーションツールを作成できます。さらに、Inspectorのscan-on-pushや継続的スキャンなどの機能を使用して、ゼロデイ脆弱性に対する最新の状態を維持することができます。
InspectorのSBOMをCI/CDパイプラインに統合した場合の流れをご説明しましょう。まず、コードベースが格納されているGitリポジトリから始まります。 AWS CodeBuildがコンテナイメージをパッケージ化し、Amazon ECSワークロードにプッシュされる前に、Amazon Inspectorがそのコンテナイメージをスキャンし、SBOM JSONファイルを生成して、ソフトウェアコンポーネントに関連する脆弱性をチェックします。その後、コンテナイメージをAmazon ECRに保存してから、最終的にAWS FargateのAmazon ECSにプッシュされます。このプロセス全体は、AWS CodePipelineがオーケストレーションを管理します。
デモでこの動作を確認してみましょう。まずAWS CodeBuildのコンソールでビルドプロファイルを確認します。build spec.yamlを開いて、 SBOMファイルを生成するためのInspectorビルドコマンドを追加します。脆弱性リストも含めて保存した後、AWS CodePipelineに移動してパイプラインをトリガーします。これでコードパイプラインに入りました。正常な結果を待ちます。パイプラインが緑色になって完了したら、ビルドログを確認して、「SBOM」と「Inspector」という単語を検索します。
ログの中に「SBOM」と「Inspector」が表示されているはずです。これは、Inspectorが起動し、コンテナイメージのすべてのソフトウェアコンポーネント、依存関係、および脆弱性のスキャンを開始したことを示しています。次に、出力されたJSONファイルの実際の内容を確認してみましょう。JSONファイルが保存されているAmazon S3に移動します。JSONビジュアライザーを使用して内容を表示すると、すでに117個のコンポーネントが確認できます。
メタデータを見ると、ソフトウェアコンポーネントの説明が表示され、Debianをベースに構築されているため、多数のDebianライブラリが確認できます。 Log4jなどの特定のソフトウェアコンポーネントを探している場合、このツールは特に役立ちます。では、検出された脆弱性を見てみましょう。このイメージに対して2つの脆弱性が特定され、説明、ベクトル、Inspector Risk Score、重要度が表示されています。この情報は、ビジネスにとって重要な事項の優先順位付けに役立ちます。アドバイザリーURLをクリックすると、より詳細な情報が表示され、推奨事項や次のステップも確認できます。
これがJSONファイルを通じて脆弱性を確認する方法の一つです。もう一つの方法として、AWSコンソールからInspectorにアクセスして脆弱性を確認することもできます。選択肢は複数あるということですね。
Critical Findingsページでは、ECRに保存されている複数のコンテナイメージから検出された4つのクリティカルな発見事項を確認できます。一番上にあるSpring Frameworkの脆弱性を詳しく見てみましょう。CVEの詳細、先ほど説明したInspector Risk Score、次のステップ、影響を受けるリソース、そしてパッケージ情報が表示されます。ここまでで見てきたのは、CI/CDパイプラインにAmazon Inspectorを組み込んで、SBOMに含まれるソフトウェアコンポーネントとそれに関連する脆弱性を正確に把握する方法でした。
コンテナイメージの署名と検証：AWS Signerの導入
パブリックレジストリからコンテナイメージをダウンロードした経験がある方はどれくらいいらっしゃいますか？かなりの方がいらっしゃいますね。こんなシナリオを考えてみてください。上司から「明日の業務終了までにWordPressサイトを立ち上げてほしい」と言われたとします。そこで「これはコンテナで実行するのに最適なケースだ。特にAWS Fargateを使用したAmazon ECSなら」と考えます。ITプロフェッショナルなら誰もが最初にすることは何でしょう？そう、Googleで検索することです。「WordPressコンテナイメージ」で検索し、見つけたイメージを使って、期限までにWordPressサイトを立ち上げようと必死に作業を始めます。
このとき、そのコンテナイメージが信頼できるソースから来ているのか、脆弱性を含んでいないかを考える余裕はないでしょう。これはセキュリティやコンプライアンスチームにとって一般的な懸念事項であり、だからこそ彼らと良好な関係を築くべきなのです。冗談はさておき、これは組織のセキュリティに影響を与える可能性があるため、実際に重要な問題です。同様に、DevOpsチーム（あなた自身がDevOpsの一員でない限り）も懸念を抱くでしょう。なぜなら、問題が発生した場合、時間外に呼び出されて対応するのは彼らだからです。
では、コンテナイメージが信頼できるソースから来ていることをどのように確認できるのでしょうか？ その答えは、署名と検証です。コンテナイメージに署名し検証することで、それらが信頼できるソースから来ており、改ざんされていないことを確認できます。これは業界標準の手法です。信頼できるソースとは、組織の独自のプライベートGitリポジトリやCI/CDパイプライン以外の外部から来るものは、すべて信頼できないソースとみなすということです。
コンテナイメージの署名と検証に関する次のステップについて説明する前に、 まずコンテナイメージ自体について説明しましょう。コンテナイメージには、コンテンツのダイジェストが含まれており、 それはマニフェストと呼ばれるJSONファイルに格納されています。ダイジェストは、ハッシュのような暗号化アルゴリズムを適用して生成される、キーがなければ読み取れない安全な文字列です。ハッシュングでは、SHA-256という暗号化アルゴリズムを使用します。512ビットのデータ文字列にSHA-256を適用して暗号化すると、256ビットの文字列が生成されます。この安全な文字列は常に固定長となります。
コンテナイメージには、コンテナレイヤーがあり、各レイヤーには独自のダイジェストがあります。コンテナイメージやレイヤーのどの部分が変更されても、それは新しいオブジェクトとなります。 これはコンテナイメージマニフェストの例です。ご覧のように、トップレイヤーにダイジェストがあります。
それぞれの異なるレイヤーには独自のダイジェストがあります。誰かがコンテナイメージを改ざんすると、そのダイジェストが変更されます。署名と検証を行うには、2つの主要なコンポーネントがあります。1つ目はNotaryです。 これは署名と検証のハードウェアコンポーネントを担当し、もう1つはNotationで、これはCNCFのオープンソースツールの一部として、署名と検証のソフトウェアコンポーネントを担当します。これらのコンポーネントが連携して、エンドツーエンドの署名と検証プロセスを実現します。
署名プロセスがどのようなものか見てみましょう。 まずコンテナイメージから始まり、最初のステップはハッシュ化で、これによりダイジェストが生成されます。2番目のステップは、それを秘密鍵で暗号化することです。これは単純な2段階のプロセスで、署名とコンテナイメージが生成され、コンテナレジストリに保存されます。では、検証についてはどうでしょうか？ 署名を行う場合は、必ず検証も必要です。最初のステップは、レジストリに保存された署名付きのコンテナイメージをダウンロードすることです。次に、その署名から関連する公開鍵を抽出する必要があります。公開鍵を抽出すると、それは秘密鍵に対応しますが、この公開鍵によってマニフェストファイルを復号化できます。その後、マニフェスト（またはマニフェストに含まれるダイジェスト）とダウンロードしたイメージのダイジェストを比較します。これらが一致すれば、コンテナイメージが変更されていないことを意味します。
皆さんはきっとメモを取っていたと思いますが、今からこれを全員に実装してもらいます。冗談ですよ。 でも、このプロセスの各ステップを実行しようとすると、かなり大変だということはお分かりいただけると思います。さらに、管理が必要なPublic KeyとPrivate Keyのことを考えると、本当に難しくなってきます。そこで役立つのがAWS Signerです。AWS Signerは署名と検証のライフサイクルの各ステップをサポートしてくれます。さらに素晴らしいことに、Public KeyとPrivate Keyを一元管理し、署名をAmazon ECR内のコンテナイメージと一緒に保存できます。これはセキュリティチームとDevOpsチームの双方にとって朗報です。
CI/CDパイプラインにAWS Signerを組み込むと、このような形になります。 先ほど、Amazon InspectorがSBOMファイルと脆弱性リストを生成する最初の部分をご覧いただきました。次は赤い四角で囲まれた部分を見ていきましょう。ここにAWS Signerがあり、Amazon ECSにデプロイする前にコンテナイメージの署名と検証を行います。署名がないか、検証できない場合は、パイプライン全体が失敗し、Amazon ECSまで到達することはありません。
では、この一連の流れのデモをご覧いただきましょう。AWS Signerのコンソールで、 署名プロファイルを作成します。プロファイル名を設定し、コンテナレジストリ用のNotationを選択します。先ほどNotationが重要な要素だとお話ししましたが、これから何度も目にすることになります。このプロファイルを保存したら、そのARNを私のbuild.yamlプロファイルに組み込みます。 プライベートGitリポジトリに移動して、buildspec.yamlを編集し、 ビルドコマンドを追加していきます。ここでもNotationについての記述が多く出てきます。 各ステップでNotationが重要な役割を果たすことは既にお話ししましたが、AWS Signerプロファイルを使用して署名プロセスを進めていきます。また、このプロセスではPublic Keyも使用されることにお気づきかと思います。
ご覧の通り、Public Keyの使用についても言及されています。コンテナイメージの署名を実際にトリガーするためのポストビルドも忘れずに追加します。これを追加してファイルをコミットしたら、次は検証が必要です。
では、検証を進めていきましょう。deploy.yamlに移動して、同様のステップを追加します。 NotationとAWS Extensionsを使用して検証プロセスを支援し、ここでもAWS Signerとプロファイルを使用して検証を行います。Public Keyの使用とTrustポリシーについても言及されています。 デプロイ前にコンテナイメージとそれに関連する署名の検証プロセスを追加することも忘れてはいけません。これは非常に重要なステップです。
それが完了したら、このファイルをGitに再度コミットします。 そうすると、私のGitリポジトリがAWS CodePipelineと連携しているため、自動的にパイプラインがトリガーされます。 パイプラインが緑色になったら、まずはビルドログを確認していきましょう。ここでは、コンテナイメージが正常に署名されたことを確認します。 では、ビルドログを見てみましょう。真実の瞬間です。コンテナイメージが正常に署名されたと表示されています。素晴らしい、これがステップ1です。
次にステップ2の検証に移ります。デプロイログを確認して、実際にコンテナイメージの検証が行われたかを見てみましょう。 そして、コンテナイメージに関連付けられた署名の検証が正常に完了したことが確認できました。AWS Signerに移動して、 署名ジョブの履歴情報を確認することもできます。 はい、正常に完了しており、CodeBuildがこれをリクエストしたことが分かります。これは私たちが期待していた通りです。
ランタイムセキュリティの強化：Amazon GuardDuty ECS Runtime Monitoringの活用
今回のエンドツーエンドのデモでは、AWS Signerを署名と検証のプロセスに組み込んで、コンテナが信頼できるソースから来ていて改ざんされていないことを確認する方法をご覧いただきました。また、デモの前半では、Amazon Inspectorを使用して潜在的な脆弱性を含むSBOMファイルを生成し、スケーラブルな脆弱性管理を実現する方法もご覧いただきました。さて、ここで質問ですが、暗号通貨を購入したことがある方はいらっしゃいますか？はい。例えば、あなたがコンテナを実行している時に、攻撃者がコンテナを乗っ取って暗号通貨マイニングファームを実行しているとしましょう。これは望ましくない状況で、早期に検出できなければ、セキュリティ面でもコスト面でも組織に深刻な影響を及ぼす可能性があります。では、このような脅威がコンテナ環境やランタイム環境で発生していることを、どのように検知できるのでしょうか？ここからは、Saiに説明を譲りたいと思います。
ありがとうございます、Mai。ここまでコンテナイメージのセキュリティ、イメージの署名、イメージのスキャンについて説明してきました。そして、コンテナが実行状態になった今、コンテナのランタイムセキュリティについて説明しましょう。ここで重要になるのがAmazon GuardDutyです。 Amazon GuardDutyは、機械学習、異常検知、統合された脅威インテリジェンスを使用して、AWSの環境における潜在的な脅威を特定し、優先順位付けを行う脅威検知サービスです。現在、ECSクラスターでGuardDutyを使用している方はいらっしゃいますか？ありがとうございます。 Amazon GuardDutyは、サーバーレスコンテナ向けに特別に設計された、フルマネージド型のランタイム脅威検知サービスであるECSランタイムモニタリングを提供しています。
その主要な利点の1つは、組織がサーバーレスコンテナワークロードのセキュリティ対策を実装する際に直面する複雑さを解消できることです。GuardDutyは、高度な機械学習を使用して、個々の独立したイベントだけでなく、イベントの連鎖全体を検知することができます。 さらに、GuardDutyは脅威を早期に検知して対応することができ、 より広範なシステムに拡大する前に対処することで、システムのセキュリティを維持し、セキュリティ上の脅威に優先順位をつけることができます。
Amazon GuardDuty ECS Runtime Monitoringは、ファイルアクセス、プロセス実行、ネットワーク接続など、セキュリティ上の脅威を示す可能性のあるランタイムイベントを検出するのに役立ちます。数百の脅威ベクトルと指標をチェックし、30種類以上の異なるFindingを生成できます。例えば、マルウェア感染、暗号通貨マイニング、Container runtime driftなどを検出できます。Container runtime driftについて言えば、コンテナの実行中に新しいライブラリが作成されたり変更されたりした場合、それがContainer runtime driftに該当します。コンテナへの変更は、ベストプラクティスとして常にCI/CDパイプラインを通じて行うべきです。コンテナの実行中に何か変更が発生した場合、Amazon GuardDuty ECS Runtime Monitoringがそれを検出し、Remote code executionやDefense evasionなど、他の多くのFindingタイプも検出します。
Amazon GuardDuty ECS Runtime Monitoringは、強化された脅威検出機能を提供し、セキュリティエンジニアがコンテナの問題を特定し、修復手順を実装するのに役立つ詳細な情報を提供します。例えば、リソースがCommand and control（C&C）ホストに接続した場合を検出できます。これは、サイバー攻撃者がネットワーク上の侵害されたデバイスを制御するために使用するサーバーやコンピューターシステムのことを指します。Findingには、影響を受けたコンテナ、Dockerイメージ、SHA-256ハッシュ、クラスター名、Namespace、親プロセス、実行パス、プロセスIDなど、包括的な情報が含まれます。コンテナはスケーラブルであるため、多数のコンテナを扱う場合、どの特定のコンテナにセキュリティ上の脅威があるかを特定することが重要です。GuardDutyは、正確なFindingタイプと早期の侵害検出でこれを可能にします。
GuardDutyは、軽量で完全マネージド型のセキュリティエージェントを使用して、個々のコンテナのランタイム動作に関する可視性を高めます。複数のECSクラスターを持つAWS Organizationsを使用しているお客様にとって、各クラスターでGuardDutyを有効にすることは課題となる可能性があります。しかし、Organization levelでGuardDuty ECS Runtime Monitoringを有効にすることで、ワンクリックでそのOrganization内のすべてのECSクラスターに対して自動的に有効にすることができます。ランタイムエージェントは完全マネージド型であるため、パッチ適用やセキュリティ確保の心配がなく、新しいタスクは常に最新のパッチが適用されたECSエージェントランタイムモニタリングエージェントを使用します。
すべての分析はバックエンドで実行されるため、タスクのパフォーマンスの問題を心配する必要はありません。つまり、タスク定義でGuardDuty用に追加のCPUやメモリユニットを割り当てる必要がなく、アプリケーションのリソース要件に完全に集中できます。さらに、Runtime monitoringのカバレッジがあるすべてのクラスターを表示できるコンソールがあります。数千のクラスターがある場合でも、どのクラスターでECS Runtime Monitoringが有効になっているかを簡単に確認でき、DevOpsエンジニアにモニタリングステータスの包括的な概要を提供します。
一方、Amazon EC2インスタンスを使用する場合、GuardDuty Agentは手動でデプロイするか、AMIにベイクするか、GuardDutyが提供するAWS Systems Manager Documentを使用してデプロイすることができます。GuardDuty AgentはEC2インスタンス内でDaemon setとしてデプロイされます。Daemon setとしてデプロイされると、VPCエンドポイントを設定する必要があります。これらのエンドポイントは、Amazon EC2インスタンスのランタイムイベントを受信するのに役立ちます。
AWS Fargateでは、このプロセスがより簡単になります。Amazon GuardDutyコンソールに移動し、Runtime Monitoring とGuardDuty Agent Managementを有効にするだけです。ECS FargateのAgent Managementをコンソールで有効にすると、 GuardDuty AgentのDockerイメージがAmazon ECRから自動的にプルされ、タスクと一緒にSidecarコンテナとしてデプロイされます。 タスクに追加のCPUやメモリユニットを割り当てる必要はなく、新しいタスクがデプロイされるたびに、Amazon ECRからECS Agent Runtime Monitoringのアップグレード版やパッチ適用済みバージョンがプルされます。 さらに、ECS Fargateを使用する際には、すべてのVPCエンドポイントが自動的に設定されるため、手動で作成する必要がありません。これらのVPCエンドポイントは、特定のタスクからランタイムイベントを受信するために使用されます。
ここまでGuardDutyとそのFinding、そしてAWS FargateでのAmazon GuardDuty Runtime Monitoring Agentを使用したECSランタイムモニタリングの簡単なデプロイについて説明してきましたが、次は実際にどのように動作するのかデモンストレーションを行いましょう。 GuardDutyコンソールに移動します。GuardDutyコンソールでは、 サマリーページが表示されます。左側のメニューからRuntime Monitoringをクリックし、Amazon GuardDutyでRuntime Monitoringを有効にします。 ここではAWS Fargate ECSのみが表示されています。これを有効にすると、ECS Fargate用の自動エージェント設定がセットアップされます。 これが有効になると、Amazon ECSで起動されるすべてのFargateタスクに、Amazon GuardDuty AgentがSidecarコンテナとしてデプロイされます。
ECSコンソールに移動すると、retail-store-ECS-clusterという1つのクラスターがあります。 frontendという名前の使用予定のタスク定義をお見せしましょう。クラスターとタスク定義が用意できたので、 タスクを開始しましょう。run-task APIコールを使用してAWS CLIコマンドを実行します。 先ほどお見せしたfrontendタスク定義を使用して、retail-store-ECS-clusterでFargateローンチタイプでタスクを実行します。Enterキーを押すと、まもなくFargateタスクが実行状態になります。
ECSコンソールに移動し、クラスターページでタスクが開始されたことを確認しましょう。Tasksタブを見ると、1つのタスクが実行中であることがわかります。 そのタスクをクリックすると、2つのコンテナが実行状態であることがわかります。 ご覧の通り、私のアプリケーションはfrontendアプリだけですが、AWS GuardDuty Agentという別のSidecarコンテナも実行されています。これは、Amazon GuardDutyコンソールでAutomated GuardDuty Agent Deploymentを有効にしたため、タスクと一緒に自動的にデプロイされたものです。多数のデプロイメントでは、毎回GuardDutyエージェントの最新のDockerイメージがプルされるため、パッチ適用やセキュリティの心配がありません。そのため、これをマネージドGuardDutyエージェントと呼んでいます。
GuardDutyコンソールに移動してFindingを確認してみましょう。サマリーページには既に1つのFindingが表示されており、重要度が高いことがわかります。 View all findingsをクリックすると、C&C活動であることがわかります。そのFindingタイプをクリックすると、より詳細な情報が表示されます。
既知のCommand and Controlサーバーに関連付けられたドメイン名に対してプロセスがクエリを実行しているという説明が表示されています。概要ページでは、リージョン、アカウントID、そして影響を受けているリソース（この場合はECSクラスター）を確認できます。クラスター名とタスクの詳細、特にタスクIDが表示されています。また、使用されたタスク定義とLaunch Typeも確認できます。Containersセクションでは、使用されているコンテナランタイム、コンテナ名、そしてこのアプリケーションで使用された特定のコンテナイメージが表示されています。
Actionsセクションでは、このコンテナで実際に何が起きているのかを確認できます。DNSリクエストが表示され、その特定のドメインを作成していることがわかります。プロセスの詳細とランタイムの詳細では、curlが使用されていることがわかります。実行可能ファイルのパス（usr/bin/curl）、プロセスID、そしてどのユーザーがそのコマンドを実行しているかも確認できます。これらの情報により、セキュリティエンジニアは、どのコンテナに問題があるのか、どのDockerイメージが使用されているのか、正しいタスク定義を使用していたのか、イメージダイジェストは何か、SHA-256は何かを簡単に確認することができます。これらの情報は、セキュリティエンジニアの調査に非常に役立ちます。
AWSのドキュメントに戻って、ランタイムモニタリングの検出タイプをいくつか見てみましょう。先ほどAmazon GuardDutyで検出したC&Cアクティビティの検出タイプをクリックすると、コンテナが既知のCommand and Controlサーバーに関連付けられたドメイン名にクエリを実行しているという、その特定の検出タイプに関する詳細情報を得ることができます。また、そのドキュメントには対処方法の推奨事項も記載されています。これまで、Amazon GuardDuty Runtime Monitoringのセットアップの簡単さ、AWS FargateでのAmazon GuardDuty Agentの導入の容易さ、そして特定のコンテナに問題があることをセキュリティエンジニアが素早く特定するのに役立つAmazon GuardDutyの検出タイプについて説明してきました。
まとめると、CI/CDパイプラインを使用して脆弱性管理をスケールアウトするためにAmazon Inspectorを使用できます。AWS Signerを使用して、コンテナイメージが信頼できるソースからのものであり、改ざんされていないことを確認できます。そして最後に、Amazon GuardDutyを使用してECSワークロード全体のランタイムセキュリティをスケールアウトすることができます。ECSのベストプラクティスについてさらに詳しく知るには、このQRコードをスキャンしてください。ECSベストプラクティスのホワイトペーパーや、Well-Architected Amazon ECS Custom Lensを実行することができます。また、AWS SignerとAmazon Inspector for ECSワークショップを使用して独自のデモを構築することもできます。ご視聴ありがとうございました。セッションのアンケートへのご協力をお願いします。私たちを見かけた際は、最高のブレイクダンスを披露してください。それでは、Amazon ECSで安全な構築を心がけてください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion