re:Invent 2024: CIパイプラインのコンテナセキュリティ体系化 - EC2 Image Builder活用事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Build trust in your CI/CD pipeline: Codify container security at scale (SEC216)
この動画では、CIパイプラインにおけるコンテナセキュリティの体系化について、大手ベッティング企業の事例を交えながら解説しています。Amazon EC2 Image BuilderでGolden Imageを作成し、Amazon ECRで保管、Amazon Inspectorでスキャンするという基本的なフローに加え、Amazon Q Developerを活用したコード品質の向上、Software Bill of Materials（SBOM）による脆弱性管理、Amazon GuardDutyによる実行時の脅威検出など、開発から運用までの包括的なセキュリティ対策を紹介しています。特に、Java 1.6で書かれた時価約100万ドル/時の収益を生むPricing Engineのモダナイゼーション事例は、レガシーシステムのセキュアな移行方法として参考になる内容となっています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Scott WardとAlex Goffによる自己紹介とセッション概要
SEC216: CIパイプラインにおける信頼性の構築とコンテナセキュリティの大規模な体系化についてご紹介させていただきます。まずは自己紹介からはじめましょう。皆様、こんにちは。私はScott Wardと申します。GuardDuty、Inspector、Security Hub、Macie Detective、Security Lakeなどのセキュリティサービスを開発しているセキュリティサービスプロダクトチームのPrincipal Solutions Architectとして働いています。私の仕事は、お客様がサービスの仕組みを理解し、自社の環境に最適な形でサービスを導入する方法を見出すお手伝いをすることです。これは多くの場合、運用化に関する議論へと発展します。また、プロダクトマネージャーやエンジニアリングチームと協力して、何を開発すべきか、そしてリリース時にお客様にとって本当に役立つものになるかを確認する仕事もしています。
私はAlex Goffと申します。UKおよびアイルランドのセキュリティリードを務めています。Professional Services（ProServ）に所属しており、小売、通信、メディアエンターテインメント、公共セクターなど、多様な業種のお客様と仕事をしています。 こちらが本日のアジェンダです。お客様の事例を通じて、直面した課題や、ソフトウェア開発ライフサイクルについての考え方、そして開発、デプロイ、運用の各段階について説明し、最後にまとめで締めくくります。
グローバルベッティング企業の事例：Golden Image Factoryの構築
最近私が担当したお客様の一つは、大手グローバルベッティング・ゲーミング企業でした。このお客様は複数のアカウントとビジネスユニットを持ち、それぞれが異なるレベルのセキュリティ成熟度を持っていました。企業として、適切な基盤で再構築する方法を理解したいと考え、新しいビジネスユニット、つまり集中ITファンクションを構築することを決定しました。この中央機能の目的は、新しいAWS Landing Zoneから始めて、適切なセキュリティ機能と基盤を確実に整備することでした。クラウドチームはこれまでの経験からAWSに精通しており、その知識を活かして適切なセキュリティコントロールを基盤から組み込みたいと考えていました。
企業として、コンテナを使用することを決定しており、その方向に進みたいと考えていました。クラウドチームとして、コンプライアンスに準拠したコンテナを強制し、アプリケーションチームが社内のセキュリティ基準を満たすワークロードを実行できるようにしたいと考えていました。その一環として、Golden Image Factoryを作成したいと考えていました。ちょっとお聞きしたいのですが - Golden Imageについてご存知の方は手を挙げていただけますか？そして、パイプラインや企業の一部としてGolden Imageを定期的に使用している方は、そのまま手を挙げたままにしていただけますか。
Golden Imageという考え方は新しいものではありません。基本的に、適切なセキュリティコントロールが施された計算ワークロードを作成するメカニズムを検討しています。Windows 2000を使用していた時代には、Windows 2000のCDを取り、インストールし、次にハードニングCDを使用してサービスをロックダウンし、アンチウイルスをインストールするなどの作業を行っていました。基本的には同じ原則があります - サニタイズされ、適切なコントロール、パッチ、適切な機能が無効化されたイメージを作成するメカニズムが必要で、これにより最小限のセキュリティフットプリントを確保できます。
お客様が直面していた課題についてですが、このグローバルなベッティング・ゲーミング企業が新しいAWS Landing Zoneに移行しようとしていた最初のワークロードは、Pricing Engineでした。このPricing Engineは、彼らのビジネスの中核を担っており、毎時約100万ドルの収益を生み出していました。世界中に約15億件の価格更新を配信していたため、このアプリケーションの可用性確保が重要な要素でした。Java 1.6で書かれており、最も古いアプリケーションの1つでした - 現在はJava 23が出ているので、17バージョンも遅れていたことになります。ビジネスの中核を担うアプリケーションだったため、モダナイゼーションが必要だと認識していました。最小限の影響とダウンタイムで、デプロイと更新を確実に行いながら、信頼性を確保し、社内基準を満たす高品質かつセキュアな状態を維持する必要がありました。
セキュリティを容易にしたいと考えていたため、アプリケーションチームからその負担を取り除きたいと考えていました。Golden Imageを作成し、基盤を構築するための一元管理された機能を提供するメカニズムが必要だと認識していました。
Amazon EC2 Image BuilderとInspectorを活用したコンテナセキュリティ
そこで彼らが構築したのが、この解決策です。その中心にあるのが、Amazon EC2 Image Builderです。これは、カスタマイズされた安全で最新のサーバーイメージの作成、管理、デプロイを自動化するのに役立つAWSのフルマネージドサービスです。EC2 Image Builderという名前ですが、実際にはコンテナイメージも扱えます。彼らが構築したのは、EventBridgeを通じて週次スケジュールで実行されるImage Builderでした。週次の開始時にImage Builderが実行され、新しいGolden Imageを生成し、それをAmazon Elastic Container Registry (ECR)内に保存します。ECRにプッシュすることでInspectorスキャンがトリガーされ、脆弱性がないことが保証されるというメリットがあります。この詳細については、後ほどScottが説明します。
アプリケーション開発について考えると、3つのフェーズがあります。最初に、実際にコードを書く「Write」フェーズがあります。アプリケーションチームとして、何を書いて構築するかを決定し、書いているものが安全であることを確認します。コードを書いてアーティファクトを構築する際、アプリケーションに安全でないコードを導入してしまうリスクがあります。書き終えたら、次は「Deploy」フェーズで、ビルドアーティファクトを環境にデプロイします。この段階では、環境にプッシュするものに脆弱性がなく、新たなセキュリティ上の懸念を引き起こさないことを確認する必要があります。
3番目は「Run」フェーズで、実際に本番環境で動作しているものを評価し、デプロイ以降に顕在化した脆弱性や脅威、実行中のワークロードの一部として認識し対処する必要があるものを確認します。CI/CDを扱っているため、これは再び「Write」に戻る循環的なアプローチとなります。この説明について、私は「Write」の部分に焦点を当て、ScottがDeployとRunのフェーズについて説明します。
コードを書く際には、5つの重要な領域またはフェーズを考慮する必要があります。誰かが変更を依頼してきた時、まず最初に必要なのはコードベースの機能を理解することです。変更を加えるべき場所、どのファイルを、どのソースコードを修正する必要があるのか、十分に理解できているでしょうか？第二のポイントは、実際に何を変更する必要があるかを判断することです。コードベースが何をしようとしているのかを理解できたら、そのビジネス価値を追加するために何を変更すべきでしょうか？第三のポイントは、セキュリティ上の懸念事項とコードがセキュリティのベストプラクティスに従っているかどうかを検討することです。4番目はテストケースの作成に関するもので、5番目はドキュメンテーションに焦点を当てています。
私のお客様は Amazon Q Developer を使用していませんでしたが、 前のスライドで示したこれらのことを達成する何らかの仕組みを求めていました。その時点で Amazon Q Developer が利用可能であれば、役立っていたかもしれません。ソフトウェア開発のための生成AI駆動システムとして、開発者やITプロフェッショナルが安全で、スケーラブルで、高可用性のアプリケーションを構築・管理するのを支援します。Java 1.6からのアップデートやその最新化方法の検討など、コードの作成、デバッグ、テスト、最適化、アップグレードをより迅速に行うことができます。これは17年間のAWS経験に基づいて構築され、AWS専門知識で訓練されており、最新で参照可能な高品質な情報とともに、AWSでのアプリケーション開発に関する質問に答える準備ができています。では、これをこのスライドに当てはめるとどうなるでしょうか？
Qの一部として、Amazon Qがコードベースの機能を実際に説明できる機能があります。これらは Amazon Q Developer 内に存在する仕組みです - コードがあってそれをどのように修正すべきかわからない場合、Amazon Qが修正方法に関する推奨事項を提供します。Q内には、コードベース全体のコードを確認し、評価して推奨事項を提示するプロジェクトスキャンを実行できる仕組みがあります。Qにはユニットテストを作成する機能があるので、自分でユニットテストを作成できる仕組みがあり、最後にドキュメント作成機能があります - Readmeファイルを生成する仕組みがあります。コードベース全体の機能をまとめたReadmeファイルを作成するよう依頼でき、それを美しく整形することができます。
CI/CDパイプラインにおけるセキュリティの実装
これはセキュリティに関する話なので、プロジェクトスキャンとセキュリティを確認するQの要素に焦点を当てていきます。ここから実際のデモに移って、本当に期待通りに動作するかどうかを確認してみましょう。 うまくいくか見てみましょう。 ここにあるのは非常に基本的な簡単なソリューションです。Qがどのように機能するかを示すためのテストコードを作成したかったので、実際にQを使ってこれを構築しました。最初は比較的シンプルに始まりました。Pythonは私の好みの言語なので、Python スクリプトを実行するDockerfileを作成したいと考え、基本的にDockerfileの作成をQに依頼したところ、これを組み立ててくれました。
最新バージョンのPythonをプルダウンし、 基本的なライブラリをセットアップし、準備のためにpipインストールを実行します。その後、実際に何ができるかを考え、SQS Queueからデータを読み取り、それをS3 BucketにプッシュするためのPythonスクリプトを書くように依頼しました。フルーツをテーマにすると伝えたところ、このフルーツプロセッサーを作成してくれました。次に、テストできるようにCloudFormationテンプレートの作成を依頼しました。SQS Queue、ECS、S3 BucketをデプロイするためのCloudFormationを作成してくれました。最後に、SQS QueueにランダムなJSON文字列を生成してプッシュするために、このLambda generatorが必要でした。
プロジェクトスキャンを実行するために、すでにAmazon Qをインストールしています。VS Codeを使用していますので、Amazon Qをクリックして「run project scan」を実行します。これにより、ソースコード、CloudFormationファイル、Pythonスクリプトなど、コードベース内のすべてのファイルを確認し、改善が必要かもしれない箇所を見つけ出します。私は意図的にハッシュ関数を実装しました。コードの生成過程で、フルーツに関するJSONファイルを生成し、最後にハッシュ関数を生成します。私は少し古い考え方なので、使用したハッシュ関数はMD5です。ここで、MD5が最も安全なハッシュメカニズムではないかもしれないと指摘されました。私はMD5が好きですが、他の選択肢についてはよく知りませんでした。
できることの1つは、説明を求めることです。これは先ほどのスライドで説明したように、コードベースや問題点が理解できない場合は、Qに説明を求めることができるということです。「なぜこれが良くないのか説明して」と尋ねたところ、MD5ハッシュアルゴリズムの使用に関する問題点を説明してくれました。MD5には脆弱性があり、衝突攻撃を受けやすいとのことです。
そして、コードの修正方法に関する推奨事項を提供してくれました。MD5の代わりにSHA-256を使用することを提案しています。代替案の提案と説明を行ってくれます。私の視点からすると、これでコードを改善する方法が分かりました。MD5で十分だと思っていましたが、ハッシュ関数として最適で安全なメカニズムではないことが分かり、Amazon Qがより良い方法を提案してくれました。
元に戻りましょう。これでAmazon Qを使用してコード作成時にセキュリティを組み込む能力を向上させ、左シフトして適切なコントロールを確実に実装する方法が分かりました。次は、Amazon EC2 Image Builderを使用してイメージをビルドする方法を見ていきましょう。 Image Builderは基本的で、その名の通りの機能を提供します。ベースイメージから始めて、それをカスタマイズします。内部では、AWS Task Orchestrator and Executorがこれらを調整し、すべてを結びつけてイメージを適切に構成できるようにします。その後、ハードニングスクリプトを実装したり、Dockerコンテナ内の特定の機能を無効にするスクリプトを適用したりしてセキュリティを確保できます。イメージが期待通りに機能するかテストすることもできます。これを実行すると、Image Builderはアカウント内にリソースをデプロイし、すべてが正しく機能することを確認します。最後に、すべてが整ったら、そのイメージをAmazon ECRにプッシュします。
EC2 Image Builderをより詳しく見ていくと、レシピという概念があります。Image BuilderはAMIやコンテナのレシピを作成できます。これらのレシピは、ベースイメージから始まります。これは、社内の他のメンバーや自分が以前に作成した管理イメージかもしれませんし、AWSが提供するイメージかもしれません。ECRからイメージを取得することもできます。先ほどの顧客のケースを考えると、ゴールデンイメージとコンテナを作成し、中央リポジトリに配置するメカニズムがあります。その後、アプリケーションチームはAmazon EC2 Image Builderを使用して、そのベースイメージを取得し、ビジネスワークロードに必要なソフトウェアを適用できます。Docker Hubから直接取得することもでき、完了するとECRにプッシュされます。
お客様の事例では、EC2 Image BuilderからDocker Hubへプルする機能は使用せず、ECRを通じて行いました。このメカニズムの利点の1つは、ECRにイメージをプルする際に、Amazon Inspectorでスキャンできることです。現在、ECRはDocker Hub、GitHub Container Registry、GitLab Container Registry、Microsoft Azure Container Registryなどの認証が必要なリポジトリからイメージをプルすることができます。また、Amazon ECR Public、Kubernetes Registryなどの認証不要なレジストリからもプルすることが可能です。
デプロイ側に目を向けて、パイプラインの基本について説明しましょう。これを考える際、環境にプッシュしたいアーティファクトがあります。パイプラインを使用する場合、適切なコントロールが整っていることを理解することが重要です。開発者が本番環境にログインして誤って環境に影響を与えないように注意を払っているかもしれませんが、一方で過度に許可された機能を持つパイプラインを持っているかもしれません。パイプラインには必要な機能のみを与え、不要なアクセス権を付与しないようにする必要があります。
例えば、AWSエステートにプッシュしてIAMユーザーを作成する完全な管理者権限を与えるべきではありません。パイプラインに実際に与えたい権限について考える必要があります。Pipeline Detective Controlsは、パイプラインが期待通りに動作しているかを確認するためのモニタリングを理解することです。何かが間違った方法で動作した場合、誤ったバージョンのコードがプッシュされたり、何らかの形で失敗したりした場合、それをどのように知ることができるでしょうか？
インシデント対応については、夜間に自動的に実行されるパイプラインを運用している場合を考えてみましょう。何か問題が発生した場合、どのように知ることができますか？誰かが呼び出されるのでしょうか？期待通りにデプロイされなかった場合に通知を受けるメカニズムはありますか？パッチレベルについても考えてください。AMIやコンテナに適切なパッチレベルとソフトウェアバージョンを確保する一方で、Jenkinsサーバーについてはどうでしょうか？これらのパイプラインリソースのパッチ適用をどのように確実に行いますか？自前のインフラを運用する代わりに、GitLabやAWS CodeBuild、AWS CodePipelineなどのマネージドサービスの利用を検討することもできます。
データ保護に関しては、アプリケーションチームやビルダーがパイプラインを使用する際に、本番データや本番情報、PII（個人識別情報）データを含むログを書き込まないようにするためにどのようなメカニズムを実装していますか？パイプラインの観点からデータ保護を確実に管理するためにどのような対策を講じていますか？最後に、人的な操作について考えてみましょう。誰がパイプラインを実行できるのか、どのような操作が可能なのかを考えてください。適切な変更要求がある場合にのみ実行できるようなコントロールは整っていますか？開発環境で作業しようとしているときに、誤って本番環境にデプロイしてしまうことを防ぐコントロールは実装されていますか？
Amazon InspectorとSBOMを活用したコンテナ脆弱性管理
先ほどAlexが、あるお客様の事例について説明しました。そのお客様は、Amazon EC2 Image Builderを使用してコンテナイメージを構築し、それらをAmazon ECRに保存し、Amazon Inspectorを使用してスキャンを行っていました。これから、そのInspectorの部分と、コンテナ化されたワークロードのデプロイと実行に関する他の側面について、より詳しく掘り下げていきたいと思います。コンテナイメージの脆弱性スキャンが必要な理由はいくつかあります。コンテナ環境にコードをデプロイする際、多くの場合、追加のライブラリがそのパッケージの一部として含まれています。コードパッケージの一部として含まれるすべてのライブラリに脆弱性がないことを確認するか、それらの脆弱性について把握しておく必要があります。
Alexが先ほど触れたように、お客様はサードパーティのコンテナリポジトリやコンテナイメージを自社のリポジトリに取り込んでいます。これらは信頼できないソースからのものなので、それらのコンテナイメージも脆弱性についてスキャンする必要があります。そのような特定のイメージに関連するリスクを理解し、リスクに対処するか除去することが重要です。さらに、Dockerコンテナ自体の設定を確認する必要があります。認証情報が埋め込まれていないか、コンテナが安全でない設定で実行されるように構成されていないかなどを確認します。
先ほどのソリューションで触れたように、このお客様はAmazon Inspectorを使用しています。皆さんのために説明しますと、InspectorはAWSの継続的な脆弱性評価サービスです。Amazon EC2インスタンスの脆弱性スキャン、Lambda関数（Lambda関数に付属するライブラリと実際に書いたコード両方）のスキャン、そしてコンテナイメージのスキャンに焦点を当てています。コンテナイメージについては、2つの異なる方法でスキャンを行います：コンテナリポジトリサービスであるAmazon ECRに保存されているコンテナイメージのスキャンと、CI/CDパイプラインの一部としてコンテナイメージをより直接的にスキャンする機能です。 これがECRスキャン機能です。基本的なスキャン機能は、ECRが提供する無料サービスで、オープンソースのClairを使用してコンテナイメージのOSパッケージマネージャーをスキャンします。Enhanced ScanningはInspectorが提供するコンテナスキャン機能です。
Inspectorでは、オペレーティングシステム全体とファイルシステムの残りの部分をスキャンします。OSパッケージマネージャーの脆弱性を確認し、さらに10種類のプログラミング言語をサポートしています。これにより、コンテナイメージ全体に存在する可能性のある脆弱性を持つ追加のライブラリを特定することができます。
Amazon Elastic Container Registry (ECR)に関しては、 選択できるスキャンオプションがいくつかあります。1つは「プッシュ時のスキャン」で、コンテナイメージをECRにプッシュした直後に、Inspectorがスキャンを実行し、そのコンテナイメージで発見された脆弱性に関する結果を報告します。また、継続的スキャンを選択することもできます。最新の状態を維持したい場合や、そのコンテナイメージをリポジトリに長期間保存し、コンテナ環境の公開と実行に継続的に使用する予定がある場合、Inspectorの脆弱性データベースが更新されるたびに継続的なスキャンが実行されます。
継続的なスキャンに関しては、実際にどのくらいの頻度や期間で継続的にスキャンを行うかについて、いくつかの設定オプションがあります。これは、イメージが最初にリポジトリにプッシュされた日付、あるいはコンテナ環境で実際に使用するために最後にプルされた日付に基づいて設定できます。この継続的なスキャンは、最短14日間から、イメージの存続期間全体まで設定可能です。コンテナイメージのライフサイクルや、イメージの有効期間に関して様々な考え方を持つお客様がいらっしゃいますので、これらの設定オプションは多様なユースケースに対応できるようになっています。
ECRについて最後に強調したいのは、Inspectorがコンテナイメージで検出した脆弱性に関する全ての発見事項がInspectorで確認できるということです。これらはコンソールやAPIを通じて、あるいはAmazon EventBridgeを通じて確認できますが、ECRでも全ての発見事項を確認することができます。つまり、これらのコンテナイメージをプッシュする開発者たちは、脆弱性情報以外の多くの情報が含まれているInspectorへのアクセス権を付与される必要がないということです。開発者はECRにアクセスし、コンソールで自分のコンテナイメージと脆弱性を確認したり、APIを呼び出して自分のコンテナイメージに存在する脆弱性の情報を取得したりすることができます。これは開発者にとって非常に便利な機能です。
InspectorとECRのコンテナイメージスキャンに関するフローは次のようになっています。左側にコンテナイメージがあり、それをAmazon ECRにプッシュします。 その後、Inspectorが有効になっていれば、ECRサービスがAmazon EventBridgeにメッセージを送信し、新しいコンテナイメージがリポジトリにプッシュされたことを通知します。 これがAmazon Inspectorのサービスアカウントによって検知され、Inspectorサービスがそのコンテナイメージのコピーを取得して脆弱性スキャンを実行します。各レイヤーを分析し、全ての脆弱性を報告します。
Inspectorは2つのものを生成します。1つは、コンソールで確認できる実際の発見事項そのものです。もう1つは、それらの発見事項のコピーをAmazon EventBridgeに送信します。また、Inspectorは各スキャンの終了時にスキャンステータスメッセージを生成し、重要度レベル（クリティカル、高、中、低）ごとに発見された脆弱性の数を要約して提供します。脆弱性が見つからなかった場合は、単にスキャンが完了したことを示すメッセージが送信されます。これらはAmazon EventBridgeに送信されるため、EventBridgeを設定することで、20以上のAWSサービスや一部のサードパーティエンドポイントなど、様々なターゲットにその情報を転送できます。
このフローで重要なポイントは、括弧内のすべてが AWSによって管理されているということです。InspectorのECRスキャン機能を有効にすると、新しいコンテナイメージをプッシュする際に、これらすべてがシームレスに連携して動作します。実際には、イメージを作成してECRにプッシュし、EventBridgeから出力されるメッセージをどのように活用するかを決めるだけでよいのです。これから、このフローを活用してコンテナイメージの可視性を高め、より良く管理するための方法をいくつかご紹介していきます。
これは先ほどAlexが説明した顧客の例に戻りますが、この顧客はAmazon EC2 Image Builderを使用してコンテナイメージを作成し、それらをECRに保存し、Inspectorを使用してこれらのGolden Imageをスキャンしています。この顧客は、Inspectorで生成され利用可能な情報に依存しており、新しいGolden Imageが作成される際に生成される脆弱性を確認していました。
顧客はその情報を基に、どのようなアクションを取るべきか、あるいはGolden Imageに導入された脆弱性を修正して再度デプロイする必要があるかどうかを、環境での使用とスキャンを許可する前に判断することができました。また顧客は、Amazon EventBridgeとそのメッセージを使用してターゲットにルーティングし、より event-driven なワークフローを実現することで、検出結果に基づいてアラートを発生させたり、スキャンステータス自体に基づいてアクション（コンテナイメージがスキャンされ、脆弱性が存在することを確認する）を実行したりすることができました。
これを踏まえて、デプロイメントパイプラインでの活用例についてお話ししたいと思います。この例では、AWS CodePipelineで基本的なパイプラインを作成しています。ソースステージ、ビルドステージ、脆弱性評価ステージ、そしてデプロイステージがあります。この例では、ユーザーがDockerfileやその他の必要なアーティファクトやコードを含むコードリポジトリにgit pushを行います。このコードリポジトリへのプッシュにより、更新メッセージが生成され、パイプラインのソースステージがトリガーされます。そしてリポジトリからすべてのアーティファクトを取得してソースフェーズを開始し、その後ビルドフェーズを開始します。
ビルドフェーズでは、Dockerfileの定義とリポジトリに存在するすべてのアーティファクトに基づいて、そのコンテナイメージをビルドすることに焦点を当てています。ビルドが完了すると、そのイメージをAmazon Elastic Container Registry（ECR）にプッシュします。次に、コンテナ脆弱性評価ステージを使用してSimple Notification Serviceにメッセージを送信します。このメッセージにはパイプライン自体の基本情報が含まれており、承認フェーズであるため、そのSNSトピックの先に小さなLambda関数を配置します。この情報をDynamoDBに保存することで、このパイプラインのインスタンスとパイプラインのこの特定の部分に固有のメッセージを送り返すことができます。
同時に、先ほど説明したステップも実行されています。Amazon InspectorはECRリポジトリに新しいイメージがあることを通知されます。そしてスキャンを実行し、スキャン完了メッセージを送信します。今回は、コンテナイメージを検証するためにそのスキャン完了メッセージに注目しています。EventBridgeメッセージのターゲットとなるLambda関数があり、これらのスキャンイベントメッセージを受信します。このLambda関数には、Inspectorが提供する各重要度レベルのしきい値が環境変数として設定されています。Critical、High、Medium、Lowの重要度レベルに対してしきい値を定義でき、Lambda関数はこれらのしきい値をスキャンステータスメッセージで生成されたカウントと比較し、しきい値を超えるものは拒否とみなします。
その後、DynamoDBからその特定のPipelineに関する情報を取得し、設定されたしきい値を超えているかどうかに基づいて、承認または拒否のメッセージを送り返します。拒否された場合、Pipelineは停止し、その拒否されたPipelineを解決するのは開発者の責任となります。承認された場合、この例ではデプロイフェーズに進みますが、実際にはテスト環境やプリプロダクション環境、本番環境など、ワークロードに最適な次のフェーズに進むことができます。これは、Amazon ECRをリポジトリとして使用しながら、フィードバックの仕組みを組み込み、そのイメージが実際に使用できるかどうかを制御する方法です。
また、CI/CD PipelineのスキャンにInspectorを活用できることについても触れました。ECRを使用せず、他のリポジトリをコンテナイメージの保存に使用している顧客や、リポジトリに格納する前の段階で、ビルド直後にコンテナイメージの良し悪しを知りたいと考える顧客もいます。この機能のために、私たちは人気のCI/CDソリューション向けにネイティブプラグインを開発しました。現在、Amazon CodeCatalyst、GitHub Actions、Jenkins、TeamCity用のプラグインを提供しており、これらのデプロイツールにインストールしてPipelineに追加することができます。このプラグインは、コンテナイメージに関する情報をInspector APIに送信し、その情報を取得して返す作業を自動的に処理するため、リポジトリにチェックインすることなく、コンテナイメージのビルド直後にプログラムによる判断をPipeline内で直接行うことができます。これは、コンテナイメージのSoftware Bill of Materials（部品表）を生成するジェネレーターを使用して実現しています。コンテナイメージをビルドした直後に、そのイメージの場所を入力としてジェネレーターが実行され、SBOMが作成されてエンドポイントに送信されます。これらのネイティブプラグインは、コンテナイメージのSBOMジェネレーターを呼び出して送信するという一連の作業を全て自動的に処理します。
注意すべき点がいくつかあります：CI/CDソリューションはどこでも実行できます。AWSで実行する必要はなく、他のクラウドプロバイダーやオンプレミスで実行することもできます。CI/CD SBOMジェネレーターを実行し、Amazon Inspector APIを呼び出せる環境であれば十分です。ここで紹介したCI/CDツールを使用していない場合でも、これらのフェーズを連携させることで、他のCI/CDツールに組み込むことができます。また、ローカルの開発デスクトップからジェネレーターを呼び出し、SBOMをInspector APIに送信して結果を取得することも可能です。
他のユースケースでAmazon Inspectorを使用していない場合でも、この機能を利用するためにInspectorを有効にする必要はありません。Inspector APIにデータを送信するだけで機能します。そのAPIの使用に対して課金は発生しますが、この機能を使用するためにInspectorサービスを実際に有効にする必要はありません。多くの顧客は、コンテナイメージの実行に不要なものを全て取り除いてサイズを縮小する作業を行っています。この機能は、Scratch、Distroless、Chainguardコンテナイメージをサポートしています。また、Dockerfileや設定をスキャンして、コンテナイメージ定義に埋め込まれた認証情報や、コンテナがrootとして実行されるように設定されているケース（これによりコンテナエスケープやインフラストラクチャの他の部分との予期せぬ相互作用のリスクが生じる可能性があります）などを特定することもできます。
本番環境でのコンテナセキュリティ維持：脆弱性対応と脅威検出
オーケストレーションの観点から、具体的な流れを見ていきましょう。パイプラインがあり、そこまでにコンテナイメージをビルドしたと仮定します。つまり、Inspectorのソフトウェアビルドオブマテリアルジェネレーターを呼び出す最終的なコンテナイメージができているということです。これはCycloneDX形式でSBOMを生成します。これはソフトウェアビルドオブマテリアルを表現するための業界標準の一つです。そのCycloneDX形式のファイルはInspectorのscan SBOM API に送信され、Inspectorの検出結果と、利用可能なアウトプットが返されます。これらの結果は、CI/CDパイプラインの一部としてプログラム的に利用でき、発見された脆弱性の数の要約リストや、詳細なリストに基づいて判断を下すことができます。管理方法に応じて使い分けることができます。
現在、独自のユーティリティやプロセスでビルドオブマテリアルを生成している場合でも、CycloneDX形式で生成していれば、それをInspector APIに送信して評価を受けることができます。私たちのジェネレーターを使用する必要はなく、CycloneDX形式であれば問題ありません。ソフトウェアビルドオブマテリアルについて多く話してきましたが、コンテナ化されたパイプラインの中でビルドオブマテリアルを活用できる他の領域についてもお話ししたいと思います。ソフトウェアビルドオブマテリアルは、ここ数年、お客様がワークロードのサプライチェーンセキュリティ全体を強化しようと取り組む中で、大きな注目を集めています。
ソフトウェアビルドオブマテリアルは、特定のコンテナイメージを構成するすべての異なるコンポーネントのレシピまたはインベントリリストに他なりません。オペレーティングシステムパッケージ、アプリケーション固有のパッケージや設定、ベンダーやライセンス情報などの情報が含まれており、これらはすべて機械可読な形式で生成されるため、後で保存、解釈、クエリを実行することができます。これは製造業時代のビルドオブマテリアルの概念から来ています。自動車メーカーを例に考えてみましょう - 今でも同じことをしています。多くの異なるサプライヤーからの部品を使用して車を製造し、出荷しています。そのビルドオブマテリアルを使用して、製造ラインのどの車にどのサプライヤーの部品が使用されているかを記録し、製造ライン上や、リコール時の欠陥を追跡できるようにしています。どの車にどのサプライヤーの部品が使用されているかを特定し、部品の修理や交換を調整するために誰と協力する必要があるかを把握できます。
ビルドオブマテリアルは他の分野で長年使用されてきた概念であり、現在ではそのコンセプトをソフトウェアにも適用しています。
私たちはSBOMを使用して脆弱性を特定する方法について説明してきましたが、多くの組織では、環境にデプロイされるアプリケーションで使用できるソフトウェアに関する要件も持っています。報告された脆弱性がなくても、セキュリティリスクとして特定のソフトウェアの使用を好まない場合もあります。また、ライセンス要件により、特定のソフトウェアの使用が許可されていない場合もあります。パイプラインでは、本番環境に移行する前に、ビルドオブマテリアルを組織のソフトウェア使用要件やライセンスコンプライアンスに照らしてスキャンすることができます。
もう1つの興味深い活用方法は、ベースラインの確立です。コンテナイメージをビルドした後、Software Bill of Materials（部品表）を生成して、そのコンテナイメージに含まれるすべてのコンポーネントの完全な一覧を作成できます。これを参照ポイントとして保存したり、Dockerイメージ自体に対するアテステーション（証明）として添付したりすることができます。後でそのコンテナバージョンを調査する必要が生じた際に、インベントリを確認し、そのコンテナイメージに何が含まれているかを確認するために使用できます。また、コンテナイメージのバージョン間の差分を比較することもでき、新しいイメージで意図した通りのバージョンの置き換えや修正が行われているかを確認したり、コンテナイメージの全体的な変更を把握したりすることができます。
これまで、ソフトウェアやコンテナイメージの作成、そしてデプロイ時のセキュリティ確保について詳しく説明してきました。しかし、これらのコンテナイメージが本番環境で実行されている場合、特に大規模なワークロードの一部として、あるいは他のリソースと連携している場合、セキュリティを維持するための計画を立てることも同様に重要です。 脆弱性に関しては、新しいものが日々報告されています。今日デプロイしたものが脆弱性のない状態、あるいは許容可能なレベルの脆弱性であったとしても、明日もそうであるとは限りません。これまでクリーンだったソフトウェアに、突然脆弱性が報告されるという事態に直面するかもしれません。
ワークロードの実行中、コンテナイメージを実行しているリソース自体、コンテナイメージ、または関連するアカウントに対して、様々な脅威が発生する可能性があります。これらの脅威に対処するための計画を持つことが重要です。 先ほど述べたように、Amazon InspectorはAWS上のコンテナイメージとEC2インスタンス（多くの場合コンテナイメージを実行している）の両方に対して継続的な評価機能を備えています。異なる脆弱性管理ツールを使用している場合でも、脆弱性への対処や本番環境での問題への対応に関するこの考え方は同様に適用されます。最も重要な最初のステップは、特定された脆弱性の所有権を割り当てることです。集中管理されたセキュリティチームがいるかもしれませんが、通常、彼らは脆弱性の修正を担当するわけではありません。ほとんどの場合、脆弱性は、その脆弱性の影響を受けるリソースやコンテナイメージを所有するチームに割り当てられます。なぜなら、そのチームが変更をどのように実装するか、またワークロード全体への影響をどのように評価するかを最もよく理解しているからです。
そのチームは脆弱性を評価し、問題とその修正方法の両方を確実に理解した上で、必要なパッチ適用を進めます。これらの変更は、先ほど説明したのと同じパイプラインプロセスを通じて、適切な環境にデプロイされます。
このプロセスは循環的なものです。時間の経過とともに新しい脆弱性が報告され、評価と修正が必要になる可能性があるためです。明確に定義されたプロセスと強力な所有権を持ち、これらの問題に時間をかけて対処できる能力を持つことが重要です。一部の顧客は、利用可能な最新のソフトウェアバージョンに基づいてコンテナイメージを継続的にビルドするという積極的なアプローチを取っています。機能を検証するためのテストを実装し、定期的に更新されたコンテナイメージをデプロイすることで、脆弱性への露出時間を最小限に抑えたり、脆弱性が本番環境に到達することを防いだりしています。
コンテナ化されたコードは、より広範なワークロードやAWSサービスの集合の一部となることがあり、本番環境や非本番環境の両方でこれらのサービスやリソースに対する脅威が発生する可能性があります。コンテナに関しては、信頼できないソースからのプルによって、コンテナイメージ上で悪意のあるファイルが実行される可能性があります。悪意のあるコードの実行や、不正なドメインへのクエリなどの問題に直面するかもしれません。また、コンテナが予期しないライブラリをロードしたり、リバースシェルを作成したりするような異常な動作を示すこともあります。コンテナは静的で特定のタスクを実行するように設計されているため、コンテナイメージの変更は対応が必要な潜在的な脅威を示す明確な指標となります。
AWS環境における脅威検出にはさまざまなソリューションがあります。Amazon GuardDutyは、AWS環境、データ、およびAWSアカウントのためのネイティブな脅威検出サービスです。コンテナ固有の保護については、いくつかの機能を提供しています。ランタイムモニタリングは、EC2インスタンスにセキュリティエージェントをデプロイし、OSとコンテナの両方のオペレーティングシステムレベルのコマンドを監視して、この情報をGuardDutyに送信し、脅威の相関分析とレポートを行います。EKS保護は、EKS上で実行されるKubernetesワークロードに焦点を当て、CloudTrailデータと同様の監査ログ情報を消費して、Kubernetes環境に対する潜在的な脅威を特定します。
EC2 Malware Protectionは、EC2インスタンスのマルウェアスキャンを実行でき、コンテナを認識する機能を持っており、特定のコンテナで検出されたマルウェアに関する詳細な情報を提供します。これには、ECSやEKSクラスター、タスク、Podとの関連付けも含まれます。GuardDutyはまた、CloudTrailデータを通じて一般的なAWSアカウントの相互作用を監視し、潜在的な脅威に関する洞察を提供します。GuardDutyの追加機能には、データイベントを監視するS3保護、オブジェクトをスキャンするS3マルウェア保護、悪意のある相互作用を特定するLambda保護、不審なログインを検出するRDS保護が含まれます。 ここで一旦立ち止まって、お客様と一緒に重要なポイントを確認し、本日のまとめに入りたいと思います。
まとめと参考資料：コンテナセキュリティのベストプラクティス
Alexが示した顧客デプロイメントの例をより広い視点で見ると、複数のリージョンや複数のアカウントにまたがって活動する複数の開発チームが見えてきます。これらの開発チームはそれぞれ独自のアカウントで活動し、ソフトウェアを構築し、すべての準備を整えています。彼らは集中管理された共有サービスアカウントを使用して、Amazon ECRにコンテナイメージを保存し、集中管理されたAmazon Inspectorでスキャンを実行しています。ECRを使用してパブリックコンテナイメージからプルスルーを行い、コンテナイメージの一貫したスキャンを実行し、これらのゴールデンイメージを生成およびプルするための一貫したリポジトリを維持しています。
彼らは、脅威と脆弱性を最小限に抑えるように設定されたセキュアなパイプラインを実装し、スキャン機能を活用しています。また、環境全体のセキュリティを監視し確保するために、さまざまなAWSサービスを使用しています。 ソフトウェアを開発する際は、そのソフトウェアに対して適切な可視性を確保することが重要です。Amazon Q Developerはセキュリティチェックを実行するための優れたツールであり、EC2 Image BuilderはEC2とコンテナイメージの両方に必要なゴールデンイメージを構築するための重要なサービスです。
ソフトウェアのデプロイに関して、パイプラインのセキュリティは非常に重要です。先ほど説明したベストプラクティスに従って、パイプラインの安全性を確保してください。自動化を活用して、パイプライン内でコンテナイメージのビルドとセキュリティチェックを実行しましょう。Amazon Inspectorは、コンテナイメージの脆弱性評価を支援する重要なサービスです。ソフトウェアの実行時には、本番環境でデプロイされたソフトウェアに関連して発生する脆弱性や脅威を監視することが大切です。対応・修復計画を用意し、担当者が割り当てられた際に問題に対処できるプロセスを確立しておく必要があります。Amazon InspectorとGuardDutyは、これらのセキュリティ目標の達成を支援する重要なサービスです。
参考資料をご紹介します。一番上のブログには、先ほど説明したECRパイプラインスキャンの例が詳しく記載されています。完全にデプロイ可能なCloudFormationテンプレートが含まれており、これを使用してソリューションを自分でデプロイし、仕組みを理解することができます。また、Amazon Q Developer、EC2 Image Builder、InspectorのCI/CD機能に関する重要なリファレンスガイド、そしてCI/CDパイプラインの各段階におけるセキュリティに関するAWSホワイトペーパーも用意されています。
月曜日ということで、re:Inventではまだまだたくさんのイベントが開催されています。これらは本日の内容と関連性のある追加セッションですが、重複する内容ではありません。この分野についてさらに深く学びたい方は、これらのセッションをスケジュールに追加することをお勧めします。セキュリティの専門家の方々には、6月中旬にPhiladelphiaで開催されるAWS re:Inforceカンファレンスもお勧めです。AWSとセキュリティについてさらに詳しく学ぶことができます。
今夜は皆様にお時間をいただき、ありがとうございました。皆様にお会いできて光栄でしたし、Alexと一緒にこのプレゼンテーションを準備し、皆様にお届けできたことを大変嬉しく思います。モバイルアププでぜひアンケートにご回答ください。良かった点、改善点など、皆様のご意見をお聞かせいただき、今後もお客様により良い価値を提供できるよう努めてまいります。ありがとうございました。Alexとともにサイドエリアにて質問をお受けいたしますので、よろしくお願いいたします。皆様、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion