Amazon Inspectorは、AWS上の対象リソースを継続的に調べ、ソフトウェアの脆弱性や意図しないネットワーク露出を検出する脆弱性管理サービスです。
Amazon GuardDutyは不審な活動の検出、AWS Security Hubは複数のセキュリティ情報の集約と優先順位付けを担うため、三つのサービスは競合するものではなく役割が異なります。
この記事では、Amazon Inspectorの対象範囲、三つのサービスの使い分け、導入後に検出結果を修正へつなげる流れを整理します。
Amazon Inspectorの役割
脆弱性とは、ソフトウェアや構成に含まれ、攻撃や情報漏えいにつながるおそれがある弱点です。
Amazon Inspectorを有効にすると、対象となるリソースを検出してスキャンし、問題を検出結果（Finding）として示します。
検出結果には、影響を受けるリソース、問題の種類、重要度、修正の可否など、対応順を決めるための情報が含まれます。
CVEは公開された脆弱性を識別するための共通番号であり、同じ問題を製品名や表記の違いに左右されず追跡するために使います。
主な対象リソース
| 対象 | 主に確認する内容 | 運用上の注意 |
|---|---|---|
| Amazon EC2 | OSやアプリケーションパッケージの脆弱性、ネットワーク到達可能性 | SSM Agentを使う方式と、条件を満たすインスタンスをEBSスナップショットで調べるエージェントレス方式があります。 |
| Amazon ECR | プライベートリポジトリに保存したコンテナイメージ内のパッケージ脆弱性 | 走査対象はECSやEKSの実行環境そのものではなく、基本的にECR内のコンテナイメージです。 |
| AWS Lambda | 関数とレイヤーに含まれる依存パッケージの脆弱性 | 標準スキャンに加え、対応範囲ではコードスキャンを選択できます。 |
この違いを理解せずに「AWS上のすべてを検査するサービス」と捉えると、対象外のリソースや未設定のスキャン種別を見落とします。
旧Amazon Inspector Classicの手順は使わない
専用エージェントの導入、評価ターゲットや評価テンプレートの作成、start-assessment-runによる定期実行は、旧Amazon Inspector Classicを前提とした手順です。
現行のAmazon Inspectorでは、必要なスキャン種別を有効にし、対象リソースのカバレッジと継続的に作成される検出結果を管理します。
古いブログやサンプルコードを参照するときは、AWS CLIのサービス名がinspectorになっていないか、評価テンプレートを使っていないかを確認してください。
GuardDutyとSecurity Hubとの違い
三つのサービスは、それぞれ「弱点があるか」「不審な活動が起きているか」「複数の情報をどこで整理するか」という別の問いに答えます。
| サービス | 答える問い | 主な入力 | 主な結果 |
|---|---|---|---|
| Amazon Inspector | 対象リソースに既知の脆弱性や意図しない露出があるか | リソース情報、ソフトウェア情報、ネットワーク到達可能性 | 脆弱性や到達可能性の検出結果 |
| Amazon GuardDuty | AWS環境で不審または悪意のある活動が起きているか | CloudTrail管理イベント、VPCフローログ、DNSログなど | 脅威の兆候を示す検出結果 |
| AWS Security Hub | 複数のセキュリティ情報をどう集約し、優先順位を付けるか | Inspector、GuardDuty、構成チェックなどのセキュリティ情報 | 統合された可視化、関連付けられたリスク、対応ワークフロー |
Amazon Inspectorだけでは、認証情報の悪用や不審なAPI操作などの実行時の脅威を網羅できません。
一方、GuardDutyはインストール済みパッケージの既知脆弱性を棚卸しするサービスではなく、Security Hubも脆弱なパッケージを修正するサービスではありません。
したがって、Inspectorで弱点を見つけ、GuardDutyで脅威の兆候を捉え、Security Hubで情報をまとめて対応を管理する使い分けが基本です。
Amazon Inspectorを導入する手順
- 対象を決める
利用中のAWSアカウントとリージョンを洗い出し、EC2、ECR、Lambdaのどれをスキャンするか決めます。 - サービスを有効にする
AWSマネジメントコンソールでAmazon Inspectorを有効にし、必要なスキャン種別が有効になっていることを確認します。 - カバレッジを確認する
対象リソースが実際に検出されているか、未管理や未対応などの状態が残っていないかを確認します。 - 検出結果の担当を決める
重要度ごとの確認期限、修正担当、例外を認める条件、再確認の方法を決めます。 - 通知と集約先を整える
必要に応じてSecurity HubやEventBridgeと連携し、検出から担当者への通知までを一つの流れにします。
有効化だけで運用は完成しないため、最初の検出結果が出る前に、誰が何を判断して修正するかを決めておく必要があります。
導入時の確認項目
- 本番環境だけでなく、開発環境と検証環境も対象に含めたか
- 利用するすべてのリージョンで設定とカバレッジを確認したか
- ECRの拡張スキャン範囲と再スキャン方針が要件に合っているか
- EC2がエージェント方式またはエージェントレス方式の条件を満たしているか
- 修正できない検出結果に、理由、責任者、見直し期限を残す仕組みがあるか
検出結果を修正につなげる運用
検出件数だけを追うと、対応すべき問題と保留できる問題の区別がつかず、一覧が増え続けます。
検出結果ごとに、次の順序で状況を確認します。
- 対象リソースを特定する
本番、検証、廃止予定など、業務上の役割を確認します。 - 脆弱性の内容を読む
重要度、修正版の有無、悪用可能性に関する情報を確認します。 - 露出と影響を評価する
外部から到達できるか、重要なデータや機能を扱うかを確認します。 - 対応を割り当てる
更新、構成変更、利用停止、期限付きの例外など、具体的な処置と担当者を決めます。 - 修正後に再確認する
検出結果の状態だけでなく、対象リソースのカバレッジが継続していることも確認します。
たとえば、使われていない検証用イメージの重大な脆弱性と、外部公開された本番EC2の高い脆弱性が同時に見つかった場合、重要度の表示だけでは対応順を決められません。
リソースの用途、到達可能性、修正版の有無を合わせて判断すれば、事業への影響が大きい問題から担当者を割り当てられます。
CI/CDに組み込むときの考え方
CI/CDパイプラインの基本に脆弱性スキャンを加える目的は、既知の問題をデプロイ前に見つけ、修正の手戻りを小さくすることです。
現行のAmazon Inspectorでコンテナイメージを事前に確認する場合は、対応するプラグイン、Amazon Inspector SBOM Generator、Amazon Inspector Scan APIを使う方式を検討します。
旧版の評価実行コマンドを呼び出す構成や、「検出結果が一件でもあれば失敗」とする単純な条件は避け、停止対象の重要度、例外の期限、承認者をリポジトリ側の運用規則として定めます。
デプロイ前の検査と稼働後の継続スキャンは代替関係ではなく、新しい脆弱性情報が公開された後も対象を見直すために併用します。
Amazon Inspector運用の要点
- Inspectorは脆弱性管理、GuardDutyは脅威検知、Security Hubは情報の集約と優先順位付けに使います。
- 現行版では、EC2、ECR内のコンテナイメージ、Lambdaを対象に、必要なスキャン種別とカバレッジを管理します。
- 旧Amazon Inspector Classicのエージェント、評価テンプレート、評価実行コマンドは現行手順へ持ち込まないようにします。
- 検出結果は重要度だけで並べず、用途、露出、修正可能性、事業への影響を合わせて判断します。
- 通知より先に、修正担当、期限、例外、再確認の手順を決めます。
対象範囲と対応責任を明確にし、検出から修正確認までを定例の運用に組み込むことで、Amazon Inspectorの結果を実際のリスク低減につなげられます。
この記事に関連する株式会社greedenの取り組み
脆弱性を見つけるだけでなく、担当者が対応を続けられる運用設計まで整えることが、安全なAWS活用につながります。株式会社greedenは、要件整理からAWSを含むWebシステム開発、保守と改善まで一貫して支援します。