【AWS re:Invent 2024】サプライチェーンアタック対策のワークショップに参加してみた

こんにちは、カスタマーサクセス部カスタマーサクセス2課の畑野です。最近の趣味はドライフラワー作りです。初となるre:Invent参加の様子をお届けします。

会場の広さに圧倒され、初日からSo Excited!でした。この記事では私が参加したワークショップをご紹介します。参加したセッションはSEC311 | Secure containers from supply chain attacksです。

テーブルを挟んで知らない人と討論するかと思いきや、もくもく会でした。ただ、不明点や相談したいことがあれば、話しかけて問題解決することが出来たので、ワークショップはこういうのがいいですね。

内容はコンテナのサプライチェーンアタック対策をCodePipeline, CodeBuild, Amazon Inspector SBOM Generator, AWS Signerで行うというものです。具体的なことは後述します。

ワークショップ中は実際に脆弱性を含ませた状態で意図してデプロイを失敗させるプロセスまで試せましたが、時間切れにより修正を行うところまでは出来ませんでした。

サプライチェーンアタックの増加

まず初めにSonatype社のレポートによると、2015年から2021にかけて、サプライチェーンアタックが増えており、特に2020年から2021年は650%の増加にもなるようです。

主な原因はOSSのパッチ未適用等のセキュリティホールを突いた攻撃のようです。特に近年は顕著に増加傾向にあるようなのでセキュリティ対策の一環として取り組む必要があると感じました。

大まかな対策の流れです。ワークショップ用に元々用意されているCodePipelineにSBOMとぜい弱性レポートを作成するステージを追加するというものです。

S3バケット上のコードを修正する。バケット内のコンテナ構成ファイルを何でもいいので修正し、アップロードすることでデプロイが始まる仕組となっていました。EventBridgeを使っていそうです。
Software Bill of Materials (SBOM)とぜい弱性レポートの生成 Amazon InspectorでSBOMとぜい弱性レポートを出力します。 SBOMにコンテナの構成要素（ミドルウェアのバージョン等）が含まれるため、おそらくレポートのCVSSをしきい値として評価していると考えられます。しきい値以下の場合はイメージ作成を失敗させます。 SBOMを元にしたレポートの評価はLambdaで実装しているようでした。 www.meti.go.jp
コンテナイメージの作成問題なければコンテナイメージを作成し、ECRに保存します。
AWS Signerによるコンテナイメージの署名コンテナイメージ作成元を証明するため、AWS Signerでイメージに署名します。署名することで、署名後の改ざんを防止します。SBOM自体にも署名を行っているかまでは確認出来ませんでした。SBOM自体が改ざんされていたら、構成情報が偽造されている可能性があり、構成情報を信用することが出来ません。
最後にAmazon ECSへコンテナをデプロイする。

4.で作成したコンテナイメージをECSへデプロイして完了です。