Amazon Inspector入門 EC2・コンテナの脆弱性スキャンを自動化するセキュリティ評価ガイド

「EC2インスタンスにパッチが当たっていないかもしれない」「ECRにプッシュしたコンテナイメージに既知の脆弱性が混入していないか」——クラウド環境が広がるほど、こうした不安は膨らむ一方です。

オンプレ環境であれば、Nessusやデータセンター側の定期スキャンで脆弱性を検出し、Excelの管理台帳と照合しながら手動でパッチを当てていた方も多いでしょう。スキャン対象のサーバーは固定的で、台数もある程度管理できていました。

しかしクラウドでは、オートスケーリングでEC2インスタンスが増減し、CI/CDパイプラインでコンテナイメージが日々更新されます。手動スキャンでは追いつけない規模と速度になるのが現実です。

この記事では、AWSの脆弱性管理サービス「Amazon Inspector」について、オンプレの脆弱性スキャンとの違いを交えながら、有効化から検出結果の活用方法まで解説します。

なぜクラウドで脆弱性スキャンの自動化が必要なのか

オンプレ環境での脆弱性管理は、以下のような流れが一般的でした。

1. 四半期ごとにNessusやOpenVASでネットワークスキャンを実行
2. 検出されたCVEをExcelの管理台帳に記録
3. サーバー担当者がパッチ適用計画を立てて、メンテナンス窓で手動適用
4. 適用後に再スキャンして是正を確認

このサイクルでも、サーバー台数が固定的で変更頻度が低い環境では十分機能していました。しかし、クラウドではこの前提が成り立ちません。

・インスタンスの動的な増減: オートスケーリングで起動したEC2が、スキャン対象リストに含まれていないことがある
・コンテナイメージの頻繁な更新: CI/CDで1日に何度もイメージがビルドされ、そのたびに新しい脆弱性が混入する可能性がある
・AWS Lambda関数のパッケージ依存: サーバーレスであっても、ランタイムやライブラリの脆弱性は存在する

Amazon Inspectorは、これらの課題を「エージェントレス＋自動・継続スキャン」で解決するマネージドサービスです。オンプレでいえば、Nessus＋資産管理＋パッチ管理を統合し、新しいサーバーが追加されるたびに自動でスキャン対象に組み込んでくれるイメージが近いでしょう。

Amazon Inspectorの基本と有効化手順

1. Amazon Inspectorの仕組みを理解する

Amazon Inspector（現行版はv2）は、以下の3つのスキャン対象をカバーしています。

・Amazon EC2インスタンス: AWS Systems Manager（SSM）エージェント経由でOS・ソフトウェアパッケージの脆弱性を検出
・Amazon ECRコンテナイメージ: ECRにプッシュされたイメージを自動スキャンし、ベースイメージやパッケージの脆弱性を検出
・AWS Lambda関数: 関数コードのパッケージ依存関係に含まれる脆弱性を検出

オンプレのスキャナーとの最大の違いは、「継続的かつ自動的にスキャンが実行される」点です。従来のように「スキャンを手動で実行→結果を確認」という運用は不要で、新しいCVEが公開されると、Inspector側で自動的にすべての管理対象を再評価してくれます。

もうひとつの重要な特徴は、エージェントの導入が不要（EC2の場合はSSMエージェントを利用）であることです。Amazon Linux 2、Amazon Linux 2023、Ubuntu、Windows Serverなど主要なAMIにはSSMエージェントがプリインストールされているため、多くの場合は追加インストール作業なしでスキャンを開始できます。

2. Amazon Inspectorを有効化する

マネジメントコンソールでの手順は以下の通りです。

1. AWSマネジメントコンソールで「Inspector」を検索して開く
2. 初回アクセス時に「使用を開始」画面が表示される
3. スキャン対象を選択する。「Amazon EC2スキャン」「Amazon ECRスキャン」「AWS Lambdaスキャン」の3つをすべて有効にするのが推奨
4. 「Inspector をアクティブ化」をクリック

有効化すると、そのリージョン内のEC2インスタンス、ECRリポジトリ、Lambda関数が自動的にスキャン対象として登録されます。新しくインスタンスを起動したり、ECRにイメージをプッシュしたりするたびに、自動でスキャンが走ります。

AWS CLIで有効化する場合はこちらです。

# AWS CLI: Amazon Inspectorを有効化（全スキャンタイプ）
aws inspector2 enable \
  --resource-types EC2 ECR LAMBDA \
  --region ap-northeast-1

3. EC2スキャンの前提条件を確認する

EC2の脆弱性スキャンが動作するには、以下の条件が揃っている必要があります。

・SSMエージェントがインストール・稼働していること: Amazon Linux系やWindows Serverはプリインストール済み。CentOSやRHELを自前でセットアップしている場合は手動インストールが必要
・SSMマネージドインスタンスとして登録されていること: EC2にAmazonSSMManagedInstanceCoreポリシーを含むIAMロールがアタッチされていること
・アウトバウンド通信が可能であること: SSMエンドポイントへの443ポート通信が必要。プライベートサブネットの場合はVPCエンドポイント（ssm、ssmmessages、ec2messages）を作成する

確認用のAWS CLIコマンドを紹介します。

# SSMマネージドインスタンスの一覧を確認
aws ssm describe-instance-information \
  --query "InstanceInformationList[*].[InstanceId,PingStatus,PlatformName]" \
  --output table \
  --region ap-northeast-1

# Inspectorのスキャン対象カバレッジを確認
aws inspector2 list-coverage \
  --filter-criteria '{"resourceType":[{"comparison":"EQUALS","value":"AWS_EC2_INSTANCE"}]}' \
  --region ap-northeast-1

PingStatusが「Online」、Inspectorのカバレッジステータスが「ACTIVE」であれば、正常にスキャンが動作しています。

料金の仕組み

Amazon Inspectorはスキャン対象の種類と数量に応じた従量課金です（2026年4月時点、東京リージョン）。

たとえば、EC2を10台、ECRイメージを50個、Lambda関数を20個運用している環境では、月額コストは以下のようになります。

・EC2: $1.2512 × 10 = 約$12.5/月
・ECR初回: $0.09 × 50 = $4.5（初回のみ）
・ECR再スキャン: $0.01 × 50 = $0.5/月
・Lambda: $0.30 × 20 = $6.0/月

合計で月額約$19程度です。オンプレでNessusのライセンス（年間数十万〜数百万円）を支払っていたことを考えると、かなりの低コストで継続的な脆弱性管理が実現できます。

なお、Inspectorを初めて有効化した場合は15日間の無料トライアルが適用されます。無料期間中にダッシュボードでスキャン結果と推定月額コストを確認できるので、本番導入前の検証に活用してください。

応用・実務Tips

1. 検出結果の重大度でトリアージを行う

Inspectorの検出結果（Finding）には、以下の重大度が付与されます。

・Critical: リモートからの任意コード実行が可能な脆弱性。即日対応が必要
・High: 権限昇格やデータ漏洩につながる脆弱性。1週間以内の対応を推奨
・Medium: 限定的な条件で悪用可能な脆弱性。パッチサイクルで対応
・Low/Informational: 直接的な脅威は低い。次回メンテナンスで対応

Inspectorは独自のリスクスコア（Inspector Score）を算出しており、CVSSの基本スコアだけでなく、ネットワーク到達可能性（インターネットに面しているか）やエクスプロイトの公開状況も加味して重大度を判定します。

オンプレではCVSSスコアだけを見て対応優先度を決めていた方も多いと思いますが、Inspectorのスコアは「実際に攻撃される可能性」をより正確に反映しているため、トリアージの精度が上がります。

2. Security Hubとの連携で一元管理する

Amazon InspectorはAWS Security Hubと自動的に統合できます。Security Hubを有効にしていれば、Inspectorの検出結果がAWSFBP（AWS Foundational Security Best Practices）の一部として自動的に集約されます。

# AWS CLI: Security HubでInspectorの検出結果を確認
aws securityhub get-findings \
  --filters '{"ProductName":[{"Value":"Inspector","Comparison":"EQUALS"}],"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"}]}' \
  --query "Findings[*].[Title,Severity.Label,Resources[0].Id]" \
  --output table \
  --region ap-northeast-1

GuardDuty（脅威検知）、Config（設定変更追跡）、Inspector（脆弱性スキャン）の3つの検出結果をSecurity Hubに集約すると、セキュリティ運用の全体像を一画面で把握できます。Security Hubの詳しい使い方は「AWS Security Hub入門」の記事で解説しています。

3. EventBridgeでCritical検出時に自動通知する

CriticalやHighの脆弱性が検出されたときに、Slackやメールでリアルタイムに通知する仕組みを構築しましょう。Amazon EventBridgeとAmazon SNSを組み合わせれば、数分で設定できます。

# AWS CLI: EventBridgeルールの作成（Inspector Critical検出時）
aws events put-rule \
  --name "inspector-critical-findings" \
  --event-pattern '{
    "source": ["aws.inspector2"],
    "detail-type": ["Inspector2 Finding"],
    "detail": {
      "severity": ["CRITICAL"]
    }
  }' \
  --region ap-northeast-1

# SNSトピックをターゲットに設定
aws events put-targets \
  --rule "inspector-critical-findings" \
  --targets "Id"="1","Arn"="arn:aws:sns:ap-northeast-1:123456789012:security-alerts" \
  --region ap-northeast-1

オンプレでNessusのスキャン結果をメールで受け取っていた運用に近い感覚ですが、Inspectorの場合は新しいCVEが公開された時点で再評価→即通知なので、四半期スキャンとは比較にならないスピード感です。

4. ECRイメージのスキャンをCI/CDに組み込む

Inspectorを有効にしておけば、ECRにイメージをプッシュした時点で自動スキャンが実行されます。CI/CDパイプラインに「スキャン結果の確認」ステップを追加すれば、脆弱性のあるイメージがデプロイされるのを防げます。

# AWS CLI: ECRイメージのスキャン結果を確認
aws inspector2 list-findings \
  --filter-criteria '{
    "ecrImageRepositoryName":[{"comparison":"EQUALS","value":"my-app"}],
    "ecrImageTags":[{"comparison":"EQUALS","value":"latest"}],
    "severity":[{"comparison":"EQUALS","value":"CRITICAL"}]
  }' \
  --query "findings[*].[title,severity,inspectorScore]" \
  --output table \
  --region ap-northeast-1

Criticalの検出結果が0件であればデプロイを続行、1件でもあればパイプラインを停止してアラートを出す。この仕組みを入れるだけで、本番環境に脆弱なコンテナが入り込むリスクを大幅に下げられます。

セキュリティの基礎理論やゼロトラストの考え方について体系的に学びたい方は、姉妹サイトのSecurityMasters.TOKYOもあわせてご覧ください。

よくあるトラブルと対処法

EC2がスキャン対象に表示されない

Inspectorを有効にしたのにEC2インスタンスがカバレッジに表示されない場合、原因はほぼSSMの設定不備です。

・確認ポイント1: SSMエージェントが稼働しているか（systemctl status amazon-ssm-agent で確認）
・確認ポイント2: EC2のIAMロールにAmazonSSMManagedInstanceCoreポリシーがアタッチされているか
・確認ポイント3: VPCからSSMエンドポイントへの通信が許可されているか（プライベートサブネットの場合はVPCエンドポイントが必要）

特に見落としやすいのが、NATゲートウェイを使わずにプライベートサブネットで運用しているケースです。SSMはHTTPS（443）でAWSのエンドポイントに接続するため、アウトバウンド通信経路がないとSSMエージェントが通信できず、Inspectorのスキャン対象に含まれません。

検出結果が大量すぎて対応しきれない

Inspectorを初めて有効化すると、何百件もの検出結果が一気に表示されて面食らうことがあります。すべてに即座に対応する必要はありません。以下の優先順位で対応してください。

1. Criticalかつネットワーク到達可能: インターネットに面したEC2のCritical脆弱性は最優先で対応
2. Highかつ既知のエクスプロイト: 攻撃コードが公開されているHighは、Criticalに準じて対応
3. Critical/Highだがネットワーク到達不可: プライベートサブネットのインスタンスは、パッチサイクルに組み込んで計画的に対応
4. Medium以下: 定期パッチ適用で段階的に解消

Inspectorのダッシュボードには「ネットワーク到達可能性」のフィルタがあるので、まずは外部からアクセス可能なリソースのCritical/Highだけを絞り込んで対応するのが実務的です。

サプレッションルールで誤検知・許容リスクを管理する

検証環境で意図的に古いパッケージを使っている場合や、業務上パッチ適用が難しい脆弱性がある場合は、サプレッション（抑制）ルールを設定して検出結果を非表示にできます。

# AWS CLI: サプレッションルールの作成例
# 特定のCVEをdev環境のインスタンスに限定して抑制
aws inspector2 create-filter \
  --name "suppress-dev-known-issue" \
  --action SUPPRESS \
  --filter-criteria '{
    "vulnerabilityId":[{"comparison":"EQUALS","value":"CVE-2024-XXXXX"}],
    "resourceTags":[{"comparison":"EQUALS","key":"Environment","value":"dev"}]
  }' \
  --region ap-northeast-1

ただし、サプレッションルールの乱用は禁物です。抑制した脆弱性は定期的に見直し、本当に許容できるリスクかどうかを再評価してください。

本記事のまとめ

クラウド環境のセキュリティは「設定して終わり」ではなく、脆弱性が日々発見される中で継続的にモニタリングする仕組みが欠かせません。

まずはInspectorの15日間無料トライアルで有効化して、自社環境のEC2にどんな脆弱性が潜んでいるかを確認してみてください。検出結果をSecurity Hubに集約すれば、IAM（権限管理）・CloudTrail（監査ログ）・Config（設定変更）と合わせたセキュリティ運用の全体像が見えてきます。