こんにちは。
カスタマーサクセス部の山本です。😺
Re:Invent のセッション動画を、少しずつ観ています。
感想や内容をブログ記事に書くことで、誰かの役に立てればと思います。
業務で ECS (Elastic Container Service) を使ったワークロードを扱うことが多いので、２回目の今回も ECS のセッションです。
- セッション名：AWS re:Invent 2024 - Securing Amazon ECS workloads with AWS Signer and Amazon GuardDuty (SVS342)
- 概要
- 登壇者
- セッションの内容
- 私の感想
- 余談
セッション名：AWS re:Invent 2024 - Securing Amazon ECS workloads with AWS Signer and Amazon GuardDuty (SVS342)
コンテナのセキュリティの課題に焦点を当て、これをCI/CDパイプラインで自動化する方法を紹介します。
コンテナは以下のような特徴があります。
- スケーラブルで短命
- コンテナ種ごとに異なる種類のアプリケーションを含んでいる
- 不安定なソースから取得されることがある
これらは特有のセキュリティ課題をもたらします。
1 に関しては、コンテナはスケーラブルなので、もし脆弱性があると、その影響が大きくなる可能性があります。また、コンテナの寿命が短いため、問題が発生したときに対象のコンテナを見つけたり、ログなどを追跡するのが難しいと思います。
2 に関しては、さまざまなコンテナが持つソフトウェアの脆弱性をすべて確認し対処するのは大変に思います。
3 に関しては、使用しているコンテナイメージが正しいものであるか、または改ざんされていないかを確認するのが大変に思います。
といったところでしょうか。
これらを踏まえて、Amazon ECSのワークロードにおける一般的なセキュリティ問題を解決する3つの方法を探ります。
また、解決方法を CI/CD パイプラインに組み込み、自動化していきます。
概要
CI/CDパイプラインで行う３つのセキュリティチェックは以下のようです。
- コンテナにインストールしているソフトウェアに脆弱性があるかのチェック（Amazon Inspector）。コンテナをコンテナリポジトリ（ECR）に格納するときに、Amazon InspectorのAPIを使って、コンテナ内のソフトウェア依存関係（Software Bill of Materials）を調べ、テキストファイルとしてS3に出力します。またソフトウェアの脆弱性検査の結果・解消方法を Inspector の画面で確認します。
- デプロイしようとしているコンテナイメージが改ざんされていないかのチェック（AWS Signer）。コンテナリポジトリ（ECR）に格納したコンテナイメージが信頼できるものであることを確認するために、Amazon Signer を使用してデプロイ時に確認します。
- デプロイ後、動作中のコンテナが異常な動作をしていないかのチェック（Amazon GuardDuty）。デプロイ後、動作中のコンテナに異常がある場合に GuardDuty が検知します。
パイプラインのイメージ：
- イメージをリポジトリ（ECR）に格納する際に、ソフトウェアの脆弱性をチェックし解消（Amazon Inspector）
- リポジトリ（ECR）からイメージを使って環境に配置（デプロイ）する際に、改ざんの有無をチェックし、改ざんがあったら止める（AWS Signer）
- 環境に配置（デプロイ）したコンテナが異常な動作をしていないかチェック（Amazon GuardDuty）※パイプラインに含まないので、スライドには記載なし
という感じですね。同じことを２回書いてしまった気もします。
脆弱性と改ざん検知は、環境に配置（デプロイ）する前にチェックできるのが良いなと思います。コンテナの利点だと思います。
GuardDuty のランタイム監視については、ECSタスクにサイドカーコンテナを配置することになります。それにも関わらず、有効化のチェックを入れるだけで良く、CPU やメモリの考慮が不要なところが魅力です。
なお、このセッションのソースコードが公開されていないため、実際に自分のワークロードに適用する際には、多少調査が必要になるかもしれません。
私も実際に試してみたいと思っているので、その際には記事を書く予定です。
本記事では、ドキュメントのリンクを掲載するに留める予定です。
以下にドキュメントがまとまっています。
プレゼン中のソースコードは、探したもののプライベートリポジトリのようで非公開のようでした。
登壇者
- Mai Nishitani
- Solutions Architect at Amazon Web Services
- Sai Kumar Samala
- Solutions Architect at Amazon Web Services
Mai さんが冒頭のアイスブレイクで「ブレイクダンス」と「ブレイクダウン」で言葉遊びしているのが面白いと思いました。
セッションの内容
1. イメージをリポジトリ（ECR）に格納する際に、ソフトウェアの脆弱性をチェックし解消（Amazon Inspector）
10年以上前、病院でシステム管理者をしていたとき、WannaCryという脆弱性への対応に苦労した経験から、コンテナイメージの管理も同様に困難であると述べています。特に、コンテナイメージ内のソフトウェアコンポーネントやそれに関連する脆弱性の把握は難しく、コンプライアンス要件も考慮する必要があります。 Amazon Inspectorを利用することで、Amazon ECRに保存されているコンテナイメージの脆弱性をリアルタイムでスキャンし、リスクスコアに基づいて優先順位をつけて対処できます。また、AWSの組織全体で一括で有効化でき、SBOM（ソフトウェア部品表）の管理も可能です。Amazon Inspectorは、CI/CDツールと統合して、自動化された脆弱性管理を実現します。 デモでは、AWS CodeBuildとCodePipelineを使用して、コンテナイメージをスキャンし、SBOMファイルと脆弱性リストを生成するプロセスを紹介しています。SBOM（ソフトウェア部品表）は、JSONファイルとしてAmazon S3に保存されます。脆弱性リストは Inspector のコンソールから確認ができます。これにより、ソフトウェアコンポーネントや脆弱性の詳細を把握し、適切な対策を講じることができます。
buildspec.yml
SBOM（ソフトウェア部品表）ファイルを JSON Visualizer で確認：
Inspector の脆弱性リストの画面：
2. リポジトリ（ECR）からイメージを使って環境に配置（デプロイ）する際に、改ざんの有無をチェックし、改ざんがあったら止める（AWS Signer）
パブリックレジストリからコンテナイメージをダウンロードする際のセキュリティについて述べています。特に、信頼できるソースからのイメージであることを確認するために、コンテナイメージの署名と検証が重要であると述べています。署名と検証は、NotaryとNotationという2つの主要なコンポーネントが使用され、これによりコンテナイメージのダイジェストが改ざんされていないことを確認できます。 AWS Signerを使用することで、署名と検証のライフサイクルを管理し、コンテナイメージの信頼性を確保できます。デモでは、AWS SignerをCI/CDパイプラインに組み込む方法を紹介しています。
- コンテナイメージをビルドしてリポジトリ（ECR） に格納する際に使用する CodeBuild の buildspec.yml に署名プロセスを追加
- コンテナをデプロイする deploy.yml に検証プロセスを追加
という流れです。
NotaryとNotation：
AWS Signer：
署名プロセス：
検証プロセス：
コンテナイメージをビルドしてリポジトリ（ECR） に格納する際に使用する CodeBuild の buildspec.yml に署名プロセスを追加：
コンテナをデプロイする deploy.yml に検証プロセスを追加：
3. 環境に配置（デプロイ）したコンテナが異常な動作をしていないかチェック（Amazon GuardDuty）
ECS on EC2
ECS on Fargate
Amazon GuardDutyは、AWS環境内での脅威を検出するサービスです。脅威検出インテリジェンスを使用して、潜在的な脅威を特定し優先順位を付けます。GuardDutyは、ECS タスクのランタイム監視を提供しています。
GuardDutyは、単に孤立したイベントだけでなく、攻撃チェーン全体を検出します。脅威がシステム全体に拡大する前に早期に検出・対応できます。GuardDutyのECSランタイムモニタリングでは、ファイルアクセス、プロセス実行、ネットワーク接続などのランタイムイベントを監視し、セキュリティ脅威の兆候を示す可能性のあるイベントを検出します。マルウェア感染や暗号通貨のマイニングを検出できます。また、コンテナランタイムのドリフト（例：コンテナ内で新しいライブラリが作成または変更されること）を検出できます。これは、ライブラリの変更がCI/CDパイプラインを通じて行われるべきであるという考えに基づいています。
GuardDutyは、軽量でフルマネージドなセキュリティエージェントを使用して、個々のコンテナのランタイム動作を監視します。
AWS Organizationsを使用している場合、組織レベルでGuardDutyのECSランタイムモニタリングを有効化することで、すべてのECSクラスターで自動的に有効になります。
デプロイメントについては、EC2インスタンスではGuardDutyエージェントを手動でデプロイしVPCエンドポイントを作成する必要があります。AWS Fargateではエージェントがサイドカーコンテナとして自動的にデプロイされ、VPCエンドポイントも自動で設定されます。
GuardDutyは簡単にセットアップでき、特定のコンテナが脅威を持っているかどうかを迅速に検出するための情報を提供します。
Securityhub とも統合できます。
AWS Fargateではエージェントがサイドカーコンテナとして自動的にデプロイされる：
検出結果画面：
まとめ
CI/CDパイプラインを通じて・・・
- Amazon Inspectorを使用した脆弱性管理を拡張できます。
- AWS Signerを利用することで、コンテナイメージが信頼できるソースから来ており、改ざんされていないことを確認できます。
- Amazon GuardDutyを使用して、ECSワークロード全体でランタイムセキュリティを拡張できます。
私の感想
Amazon Inspectorを使用した脆弱性管理については、ECR 上で「拡張スキャン」を有効にすることで手軽に実施できると思います。
拡張スキャンに関しては弊社のブログ記事もあります。よければ参照ください。
ECRのイメージスキャンはどちらのタイプを選ぶべきなのか - サーバーワークスエンジニアブログ
本セッションではパイプラインで Inspector の API を使用し、SBOM（ソフトウェア部品表）を S3 バケットに出力していました。
徹底した脆弱性管理や、素早い対応が必要な時にはこちらも検討すると良いと思いました。
AWS Signer を使用したイメージダイジェストの署名・検証プロセスについては、知らなかったので、検証してみようと思いました。
GuardDuty のランタイム監視については、Fargate であればチェックを入れるだけで良いので、有効にしておくのが良いかなと思いました。
資料は全体的に以下にあるようです。リポジトリは公開されていないようです。
serverlessland.com
余談
会社の登山部で、武甲山に登りました。
針葉樹林は冬でも元気なので、なんか好きです。笑
