Cloud Service
Amazon Inspector
EC2やコンテナイメージ、Lambda関数を継続的にスキャンし、既知の脆弱性と意図しない公開を自動検出する脆弱性管理サービス
- 1.EC2インスタンス、ECRのコンテナイメージ、Lambda関数を対象に既知の脆弱性を自動でスキャンする
- 2.有効化するだけで継続スキャンが始まり、新たな脆弱性情報の公開時にも自動で再評価される
- 3.検出結果は文脈を加味したリスクスコアで優先順位付けされ、Security HubやEventBridgeに連携できる
Amazon Inspector は、EC2 インスタンス、Amazon ECR のコンテナイメージ、AWS Lambda 関数を対象に、既知のソフトウェア脆弱性や意図しないネットワーク到達性を自動的に検出するマネージド型の脆弱性管理サービスです。対象を有効化するだけで継続的なスキャンが始まり、検出結果には文脈を考慮したリスクスコアが付与されます。
解決する課題
クラウド上では、OS パッケージやアプリケーションライブラリ、コンテナイメージに含まれるソフトウェアに、後から新たな脆弱性(CVE)が公開されることが日常的に起こります。これらを把握するには、対象資産を棚卸しし、ソフトウェア部品表を取得し、脆弱性データベースと突き合わせる作業を継続的に行う必要があります。手作業や個別ツールでこれを維持するのは負荷が高く、スキャン漏れや情報の陳腐化が生じがちです。
また、検出された脆弱性が大量にある場合、すべてに同じ優先度で対応するのは現実的ではありません。Amazon Inspector は、対象資産の自動検出から脆弱性のスキャン、新しい脆弱性公開時の自動再評価までをマネージドに提供し、さらに到達性やエクスプロイトの有無といった文脈を加味したスコアで優先順位付けを支援します。これにより、利用者は本当に対応すべき脆弱性へ集中できます。
主要概念と用語
- 検出結果(Finding): Inspector が脆弱性や問題を検出した際に生成するレコード。対象資産、該当する CVE、重大度、リスクスコア、修正情報などを含む。
- カバレッジ(Coverage): スキャン対象としてどの資産が捕捉されているかという状態。有効化対象のうち、実際にスキャンできているリソースの範囲を表す。
- スキャンタイプ: 対象に応じた評価の種類。OS やアプリケーションのパッケージ脆弱性を見るスキャンと、ネットワークの到達性を評価するスキャンがある。
- Inspector スコア: 共通脆弱性評価システム(CVSS)の基本スコアに、ネットワーク到達性やエクスプロイトの存在などの環境的な文脈を加味して算出される独自のリスク指標。
- SBOM(ソフトウェア部品表): 資産に含まれるソフトウェアコンポーネントの一覧。Inspector はこれを基に脆弱性データと突き合わせる。
- SSM エージェント連携: EC2 のパッケージ脆弱性スキャンで利用される仕組み。AWS Systems Manager を通じてインベントリ情報を収集する方式が中心となる。
- 抑制ルール(Suppression rule): 既知で対応不要と判断した検出結果を自動的に抑制し、ノイズを減らすためのフィルター設定。
- 委任管理者アカウント: AWS Organizations 連携時に、組織全体の Inspector を統括するために指定するアカウント。
仕様・制限・クォータ
Amazon Inspector はリージョンごとに有効化するサービスであり、監視対象のリージョンそれぞれで設定します。有効化はスキャンタイプ単位で行え、EC2 スキャン、ECR イメージスキャン、Lambda 関数スキャンを必要に応じて選択できます。EC2 のパッケージ脆弱性スキャンでは、エージェントベースの方式とエージェントレスの方式が用意されており、対象や構成に応じて使い分けられます。
ECR のイメージスキャンには、プッシュ時にスキャンする方式と、継続的にスキャンする方式があります。継続スキャンには再評価を行う有効期間の考え方があり、検出結果の保持にも一定の期間が設けられています。アカウントあたりの抑制ルール数などにはサービスクォータが設定されています。具体的な保持期間やクォータの上限値、対応する OS・ランタイムの範囲は変動しうるため、最新の公式ドキュメントとサービスクォータの値を確認してください。
内部の仕組み
Amazon Inspector は、有効化されたスキャンタイプに応じて対象資産を自動的に検出し、ソフトウェアコンポーネントの情報を収集します。EC2 のパッケージスキャンでは、AWS Systems Manager のインベントリやエージェントレスの仕組みを通じてインストール済みパッケージの情報を取得します。ECR ではイメージのレイヤーを解析し、Lambda では関数コードと依存パッケージを評価します。
収集したコンポーネント情報は、Inspector が参照する脆弱性データベースと突き合わせて評価されます。新しい CVE 情報が公開されると、既存の対象についても自動的に再評価が行われ、新たに該当する脆弱性があれば検出結果が生成されます。各検出結果には CVSS を基に環境的文脈を加味した Inspector スコアが付与されます。生成された検出結果は Inspector のコンソールで確認できるほか、AWS Security Hub に集約され、Amazon EventBridge にも送信されて後段の自動化につなげられます。
設計パターン / ベストプラクティス
代表的な構成は、AWS Organizations と連携し、委任管理者アカウントから組織全体の Inspector を一元管理するパターンです。新規アカウントを自動的にスキャン対象に含める設定にしておくと、アカウント追加時の有効化漏れを防げます。CI/CD パイプラインでは、ECR へのイメージプッシュ時スキャンを組み込み、重大な脆弱性を含むイメージのデプロイを抑止する運用が有効です。
検出結果は Security Hub に集約して横断的に管理し、EventBridge ルールで受け取って Amazon SNS による通知や AWS Lambda、AWS Step Functions による自動対応へつなげます。誤検知や対応不要と判断した検出結果には抑制ルールを適用し、優先度の高いものに集中できるようにします。修正はパッチ適用やベースイメージの更新で行い、Systems Manager のパッチ管理と組み合わせると修復まで一貫して回せます。
個別アカウントごとに運用するのではなく、Organizations の委任管理者アカウントへ集約することで、有効化状態とカバレッジの管理、検出結果の確認を一元化できます。自動有効化設定と併用すると、アカウント追加時もスキャン漏れが起きにくくなります。
運用・監視
日々の運用では、生成された検出結果を Inspector スコアと重大度に応じてトリアージし、優先度の高いものから対応します。Inspector スコアはネットワーク到達性やエクスプロイトの有無を加味するため、単純な CVSS よりも実環境のリスクに沿った優先順位付けができます。カバレッジを定期的に確認し、スキャン対象から外れている資産がないかを点検することも重要です。
修正後は再スキャンや自動再評価によって該当の検出結果が解消されることを確認します。繰り返し発生する既知の検出結果には抑制ルールを適用してノイズを抑え、アラート疲れを防ぎます。検出結果は Security Hub や SIEM に集約し、他のシグナルと相関させて全体像を把握します。組織全体での有効化状況と各リージョンの設定状態も定期的に点検します。
コスト
Amazon Inspector の料金は、スキャンの対象量に基づく従量課金が基本です。EC2 インスタンスのスキャン数、ECR でスキャンしたイメージ数、Lambda 関数のスキャン数などに応じて課金され、対象資産が増えるほどコストも増加します。継続スキャンによる再評価や、新しい脆弱性公開時の自動再評価も対象量に含まれます。
有効化するスキャンタイプや対象資産の数が増えると、その分の料金が加算されます。ECR の継続スキャンとプッシュ時スキャンでは課金の考え方が異なる場合があるため、必要な範囲を見極めて設定してください。具体的な単価は変動しうるため、最新の料金ページで確認してください。
新規利用者向けには一定期間の無料トライアルが提供されることが一般的で、有効化前に推定コストを把握する手段も用意されています。これらを活用し、本格運用前にコスト感を確認すると安全です。
セキュリティ
Amazon Inspector は脆弱性の検出に特化したサービスであり、対象資産の構成を直接変更することは基本的にありません。EC2 のスキャンでは Systems Manager 連携やエージェントレスの仕組みを利用するため、対象インスタンスに必要な権限設定や、エージェント方式を使う場合のエージェント稼働状態の管理が前提になります。検出結果や設定へのアクセスは AWS IAM のポリシーで制御し、最小権限の原則に沿って設計します。
検出結果には脆弱性の所在という機微な情報が含まれるため、Security Hub や EventBridge、S3 へエクスポートする際は出力先の保護、暗号化、アクセス制御を適切に行います。Inspector は検知だけでなく、修正・再評価までを含めた脆弱性管理プロセスの一要素として位置づけ、他のセキュリティサービスと組み合わせて多層防御を構成することが重要です。
Well-Architected の観点
セキュリティの柱の観点では、Amazon Inspector は資産の脆弱性を継続的に検出し、攻撃対象領域の把握とリスクの早期発見に寄与します。文脈を加味したスコアによる優先順位付けは、限られたリソースを重大なリスクへ集中させる助けになります。検出から通知、修正までを自動化することで、対応までの時間を短縮し、人手による運用負荷を下げられます。
組織全体での一元的な有効化とカバレッジ管理、検出結果の集約は、ガバナンスとセキュリティ態勢の可視化につながります。CI/CD への組み込みにより、脆弱なイメージのデプロイを未然に防ぐシフトレフトな運用を実現でき、運用上の優秀性にも貢献します。
試験で問われるポイント
- Amazon Inspector の対象は EC2、ECR のコンテナイメージ、Lambda 関数であり、既知の脆弱性(CVE)を自動スキャンすること。
- 有効化するだけで継続スキャンが始まり、新しい脆弱性公開時にも自動で再評価される点。
- EC2 スキャンは Systems Manager 連携またはエージェントレスで行い、検出結果には文脈を加味した Inspector スコアが付くこと。
- 検出結果は Security Hub に集約され、EventBridge 経由で SNS 通知や Lambda による自動対応に連携できること。
- リージョン単位で有効化し、Organizations の委任管理者でマルチアカウントを一括管理できること。
- 脆弱性検出(Inspector)と、脅威検知(GuardDuty)、構成評価(Config)の役割の違い。
関連サービス・比較
Amazon GuardDuty は、各種ログを継続分析して不正アクセスや侵害の兆候という脅威そのものを検知するサービスです。これに対し Amazon Inspector は、資産に含まれる既知の脆弱性を見つけ出す脆弱性管理サービスであり、見るべき対象と目的が異なります。実環境では両者を組み合わせ、入口の脆弱性管理と稼働中の脅威検知を両面でカバーするのが一般的です。
| 観点 | Inspector | GuardDuty |
|---|---|---|
| 主な役割 | 資産の脆弱性スキャン | ログ分析による脅威検知 |
| 対象 | EC2やコンテナイメージ、Lambda | アカウントやネットワークの活動 |
| 入力 | パッケージ情報やSBOM | VPCフローログやDNSログなど |
| 出力 | 脆弱性の検出結果とスコア | 脅威の検出結果(Finding) |
| 位置づけ | 予防的な脆弱性管理 | 発見的な脅威検知 |
ハンズオン / CLI例
次の例は、現在のリージョンで Amazon Inspector を有効化し、有効化状態とカバレッジ、検出結果の状況を確認するものです。
# EC2・ECR・Lambda のスキャンを有効化
aws inspector2 enable \
--resource-types EC2 ECR LAMBDA
# アカウントごとの有効化状態を確認
aws inspector2 batch-get-account-status
# スキャン対象として捕捉されているリソースのカバレッジを確認
aws inspector2 list-coverage
# 重大度が高い検出結果を抽出して確認
aws inspector2 list-findings \
--filter-criteria '{"severity":[{"comparison":"EQUALS","value":"HIGH"}]}'
AWS Service
Amazon Inspectorを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
セキュリティ・ID
比較で見る軸
クラウド: AWS / カテゴリ: セキュリティ・ID / 難易度: intermediate
導入後に効く点
有効化するだけで継続スキャンが始まり、新たな脆弱性情報の公開時にも自動で再評価される
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- AWS
- カテゴリ
- セキュリティ・ID
- 難易度
- intermediate
- 関連資格
- SCS-C02 / SOA-C02
- 設計柱
- security
判断チェックリスト
- 自社の用途が「セキュリティ・ID / security」に近いか確認する。
- 強みである「EC2インスタンス、ECRのコンテナイメージ、Lambda関数を対象に既知の脆弱性を自動でスキャンする」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。