CTO室の岩本 (@iwamot) です。
ENECHANGEでは、Amazon ECRの拡張スキャンを全社的に導入しました。OSパッケージの脆弱性のみが対象となる基本スキャンと違い、プログラミング言語パッケージも対象となります。
導入の狙いは、セキュリティの強化と開発者体験の向上です。古いバージョンのOSやプログラミング言語が使われつづけると、安全性だけでなく開発者のモチベーションまで低下してしまいかねません。
ただし実際に導入してみると、始める前に知っておきたかったポイントがありました。
この記事では、これからECRの拡張スキャンを使う方に向けて、とくに押さえておきたい2つの設定を紹介します。
1. Amazon InspectorではなくAmazon ECRから有効化すべし
ECRの拡張スキャンにはAmazon Inspectorが使われますが、有効化する方法によって設定内容が大きく変わります。これが1つめのポイントです。
Inspectorをアクティブ化すると過剰な設定になりがち
まず、シンプルにInspectorをアクティブ化するとどうなるか見てみましょう。
下図のようにECRの拡張スキャンは有効になるものの、Amazon EC2やAWS Lambdaのスキャンまで有効になってしまいます。ECRの拡張スキャンのみ必要な場合、この方法は避けるべきです。
さらに、ECRでは全リポジトリが連続スキャンの対象となってしまいます。既存のイメージが意図せずスキャンの対象となり、大量のイメージを保持している環境では利用料金が跳ね上がりかねません。
ECRのスキャン設定から有効化すれば十分
そうではなく、ECRのスキャン設定で拡張スキャンを有効化することをおすすめします。最初はリポジトリを絞って、プッシュ時の脆弱性検出を試せば十分でしょう。
Inspectorによるスキャンがすべて無効化された状態から始めれば、ECRの拡張スキャンだけが有効になります。
以上のようにプッシュ時の拡張スキャンだけを有効化し、様子を見ながら対象を拡げていくのがおすすめです。
2. 通知をカスタマイズして見やすくすべし
せっかく拡張スキャンを有効にしたのであれば、検出結果を通知したいところです。
ENECHANGEでは、Amazon EventBridgeに送信されるイベントをAmazon Q Developer in chat applications（旧称：AWS Chatbot）経由でSlackに通知することにしました。よくある構成です。
しかしデフォルトのままだと、通知内容が分かりづらくて実用的ではありません。
特につらいのは、イメージタグと脆弱性が含まれていない点です。それぞれがぱっと分からないと、対応の勘所がつかみにくくなります。
そこで、EventBridgeの入力トランスフォーマーを使って通知内容をカスタマイズすることにしました。送信されるイベントの詳細は「Amazon Inspector 検出結果イベントスキーマの例」に書かれています。
具体的なカスタマイズ内容は下記のとおりです。
入力パス
{ "account": "$.account", "detailType": "$.detail-type", "findingArn": "$.detail.findingArn", "imageHash": "$.detail.resources[0].details.awsEcrContainerImage.imageHash", "imageTag": "$.detail.resources[0].details.awsEcrContainerImage.imageTags[0]", "pushedAt": "$.detail.resources[0].details.awsEcrContainerImage.pushedAt", "region": "$.region", "repositoryName": "$.detail.resources[0].details.awsEcrContainerImage.repositoryName", "title": "$.detail.title" }
入力テンプレート
{"content":{"description":"<findingArn>\n\n*Image:* <repositoryName>:<imageTag>\n*Vulnerability:* <title>","textType":"client-markdown","title":":warning: <detailType> | <region> | Account: <account>"},"metadata":{"threadId":"<imageHash>|<pushedAt>"},"source":"custom","version":"1.0"}
これにより、下記の項目が通知に含まれるようになりました。
- Inspectorの検出結果ARN (
<findingArn>) - イメージタグ (
<repositoryName>:<imageTag>) - 検出された脆弱性 (
<title>)
また、同じイメージの検出結果がスレッドにまとまるようにスレッドIDを調整しています (<imageHash>|<pushedAt>)。
以上が、2つめの設定ポイントです。カスタマイズにより通知が見やすくなりました。
拡張スキャン導入の効果
以上の工夫により、ENECHANGEではクリティカルな脆弱性に対応できるようになりました。
下記は実際におこなった対応の一例です。ベースイメージのアップデートにより脆弱性を解消しています。
アプリケーションのDockerイメージ
-FROM ruby:3.2.2-slim-bullseye +FROM ruby:3.4.1-slim-bookworm
ログ集約基盤のDockerイメージ
-FROM public.ecr.aws/aws-observability/aws-for-fluent-bit:2.28.0 +FROM public.ecr.aws/aws-observability/aws-for-fluent-bit:2.32.5
工夫しながらECRの拡張スキャンを導入したことで、セキュリティがスムーズに強化できるようになったと手応えを感じています。
まとめ
Amazon ECRの拡張スキャンは、セキュリティを強化するうえで有用です。
ただし、現時点で快適に運用するには今回ご紹介したような工夫が必要となります。
- Amazon InspectorではなくAmazon ECRから有効化すべし
- 通知をカスタマイズして見やすくすべし
以上、導入を検討している方の参考になれば幸いです。
