この記事は、Ateam Finergy Inc. × Ateam Wellness Inc. Advent Calendar 2023の11日目の記事です。
はじめに
私の担当しているサービスにて脆弱性検知・管理の仕組みとしてAmazon Inspector V2を導入しました。
実際に導入して得た知見などを共有します。
Amazon Inspector V2とは
公式ドキュメントによると以下のように記載されております。
Amazon Inspector は、AWSのワークロードにおけるソフトウェアの脆弱性やネットワークへの意図しない公開がないか継続的にスキャンする脆弱性管理サービスです。Amazon Inspector は、実行中の Amazon EC2 インスタンスと Amazon Elastic Container Registry (Amazon ECR) 内のコンテナイメージとAWS Lambda機能を自動的に検出してスキャンし、既知のソフトウェアの脆弱性やネットワークへの意図しない公開がないかスキャンします
Amazon Inspectorでは以下のものに対してのスキャンを実施できます。
- 実行中のEC2インスタンス
- Amazon Elastic Container Registry内のコンテナイメージ
- AWS Lambda
サービスへの導入の背景
私の担当しているサービスは複数のシステムに分かれており、それぞれの依存ライブラリのアップデートが多数発生し、優先順位付けが難しい状態になっておりました。
優先順位付けの1つの判断材料としてライブラリのアップデートに対して脆弱性の修正が含まれるものであるかどうかを定めました。
Amazon Inspector V2を選んだ理由
アプリケーションの依存ライブラリの脆弱性検知の仕組みは様々存在しておりますが、以下の点においてAmazon Inspector V2を選択しました。
- サービスで動いているシステムがほぼAWSで稼働していること
- Inspectorを有効化するのみで検知でき、導入コストが少ないこと
- 15日間の無料トライアルが存在し、コスト面での影響を把握してから本導入できること
導入までに実際にやったこと
EC2
EC2インスタンスのスキャンを行うためには以下の条件を満たす必要があります。
- サポートされているOSであること
- Amazon EC2 Systems Manager (SSM) のマネージドインスタンスであること
- AmazonSSMManagedInstanceCoreを許可ポリシーを持つIAMロールがEC2インスタンスにアタッチされていること
- インスタンスにSSM Agentがインストールされていること
担当する事業のEC2インスタンスではすでに条件を満たしていたため、有効化するのみで利用開始できました。
ECR
ECRのコンテナイメージをスキャンするためには以下の条件を満たす必要があります。
- サポートされているOSであること
こちらの現在使っているDockerイメージがサポートされているOSであったため、有効化することで利用開始できました。
導入後に行ったこと
Amazon InspectorではCVSSなどのデータをもとに、5段階の重要度レベルに分けて脆弱性の結果を表示してくれます。
| スコア | 格付け |
|---|---|
| 0 | Informational |
| 0.1–3.9 | Low |
| 4.0–6.9 | Medium |
| 7.0–8.9 | High |
| 9.0–10.0 | Critical |
この重要度の結果をもとにCriticalであるものは最優先で対応、Highのものも優先的に対応するようにしています。
対応については、EC2やECRの場合でもアップデートを実施するのみです。
導入後に役にたった事例
Inspectorは脆弱性を検知して対応していく上で便利なツールではですが、それ以外にSBOMの生成ツールとしても利用できます。
CVE-2023-38545 の対応の際に大変役に立ちました。
こちらはcurl及びlibcurlでの脆弱性があると報告されたものです。
XやGitHubにて事前に脆弱性に対する修正が公開されると共有されておりました。
発表前の時点では脆弱性の詳細等が不明であったため、弊社内での事前にサービスでの利用箇所とアップデート計画を立てる必要ありました。
Amazon Inspector による SBOM のエクスポート - Amazon Inspector
その際にInspectorでSBOMをエクスポートし、SBOMを調査することでcurlがインストールされているシステムと現在のバージョンをすぐさまリストアップできました。
また、脆弱性の修正パッケージのアップデート実施後に再度SBOMを出力し、調査することですべてのシステムにおいて脆弱性の影響のないバージョンになっていることを確認できました。
今後のアップデートに期待したこと
対応履歴や対応状況の可視化したい
現状、対応履歴等を記載できず、検知結果を見るか検出を抑制しかできません。
脆弱性の対応については、簡単にアップデートできないものも存在し、影響範囲調査などを行うため、対応に時間がかります。
そうなると対応ステータスなどを管理する必要がありますが、その機能を有していないため、チケット管理ツールなどに転記した上で管理しています。
同一の脆弱性のマージ
ECRの検知ではイメージごとに脆弱性の検知が行われて検出結果が表示されます。
まだ未対応の脆弱性があった場合に、新しいコンテナイメージをプッシュした場合に既存のイメージとは別に脆弱性検知されてしまいます。
こちらはアップデート後も脆弱性があることを検知できており、正しい挙動ではありますが、脆弱性の数がイメージの数の分だけカウントされてしまったりします。
同じものをまとめたり、ECRのリポジトリとして見た場合に1つの残存する脆弱性として把握したい場合があります。
SBOMの検索機能
ツールの仕様上、先程のCurlの脆弱性のように事前に共有されたものやゼロデイの脆弱性に対しては検知ができません。
curlの例ではSBOMを出力して対応しましたが、コンソール上にて、ツール名で検索できると便利です。
検索結果として、インストールされているEC2インスタンスやコンテナイメージが一覧表示されると検知できていないものに対しても対応がしやすそうです。
今後対応していきたいこと
Amazon InspectorのスキャンはECRにプッシュ後、実行されておりましたが、CI/CDにも組み込めるようになりました。
CI／CDに組み込むことでDevSecOpsを実施したり、脆弱性が追加されたコンテナをデプロイしないようにしていくことができます。
より早い段階でも検知として利用していきたいと考えています。
最後に
定期的なスキャンとアップデートでシステムのセキュリティを担保していくことができます。
様々なツールが存在しますが、条件がそろえばAmazon Inspector V2は有効な手段となります。
ぜひ使ってみてください。