ネットワーク層の防御は整っていても、OpenSSLやcurlといったパッケージに新しいCVE(共通脆弱性識別子)が公開されると、パッチを当てるまでの間は攻撃リスクが残り続けます。特に複数のAZにEC2が分散し、Auto Scalingで台数が増減する環境では、手動でのパッチ状況管理は現実的ではありません。
AWS Inspector v2は、EC2へのエージェントインストールなしに、SSM Agentを介してCVEを自動スキャンするサービスです。スキャン結果は深刻度スコアとともに表示され、SSMパッチマネージャーと組み合わせることで「検出→修正」のフローを自動化できます。
この記事では、Inspector v2の有効化からEC2スキャンの設定、検出結果の読み方、SSMパッチマネージャーとの連携設計まで実践的に解説します。
動作確認環境: Amazon Linux 2023(EC2)、AWS CLI v2.17以降、AWS Systems Manager Agent 3.3以降
この記事のポイント
・Inspector v2はSSM Agent経由でEC2のCVEをエージェントレスでスキャンできる
・aws inspector2コマンドで有効化からスキャン結果取得まで操作できる
・CVSSスコアと「exploitability」の組み合わせで修正優先度を判断する
・SSMパッチマネージャーと組み合わせることで検出から修正まで自動化できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
AWSインフラでなぜ継続的脆弱性スキャンが必要なのか
EC2を稼働させ続けると、その間にLinuxカーネルやOpenSSL、curlなどのパッケージに新しいCVEが発見されます。たとえば2023年に発見されたCVE-2023-38545(curlのヒープバッファオーバーフロー)は、多くのAmazon Linux 2インスタンスに搭載されたcurlに影響し、CVSSスコア9.8のCRITICALに分類されました。こうした脆弱性はインスタンスを新規起動した直後には問題がなくても、数ヶ月後には状況が一変することがあります。特に次のようなケースでは手動管理が追いつかなくなりやすく、自動スキャンの設計が欠かせません。
・複数AZに分散したEC2が増えた場合: インスタンス数が増えるとパッチ状況の管理が属人化しやすく、担当者が変わった時に見落としが発生しやすい
・Auto Scalingで動的に起動するEC2がある場合: 古いAMIをベースにしたLaunch Templateからインスタンスが起動するたびに、既知の脆弱性を持ち込む可能性がある
・複数チームが異なるAMIを使っている場合: ベースAMIのパッチ適用状況がチームによってバラバラになり、組織全体の脆弱性把握が困難になる
セキュリティグループとWAFはネットワーク層での防御ですが、OSレベルのCVEパッチを当てない限り、攻撃者がサービスの脆弱性を突ける状態が続きます。Inspector v2はこの問題を継続的・自動的なスキャンで解決します。
AWS環境でのLinuxサーバー運用を体系的に習得したい方は、Amazon Linux × AWSの実践的な使い方もあわせてご確認ください。
AWS Inspector v2の基本設計(スキャン対象・動作原理)
Inspector v2は2021年リリースのInspector(v1)の後継サービスで、設計思想が大きく変わっています。v1が「定期的なスキャン」と「専用エージェントの手動インストール」を必要としていたのに対し、v2は「イベント駆動型スキャン」と「SSM Agentによるエージェントレス設計」が特徴です。・スキャン対象: EC2インスタンス(OSパッケージのCVE)・ECRコンテナイメージ・Lambda関数の依存パッケージ
・エージェントレス設計: EC2への専用エージェントのインストールは不要。SSM Agentがバージョン3.3以降であれば即日スキャン対象になる
・スキャンのタイミング: EC2起動時・SSMインベントリ更新時・新しいCVEが公開されたタイミングで自動スキャンが実行される。定期ポーリングではなくイベント駆動のため、新規CVE公開から数時間以内に影響を受けるEC2が検出される
・スキャンの種類: ソフトウェア脆弱性スキャン(CVEデータベース照合)とネットワーク到達性スキャン(インターネットから到達可能なポートの確認)
| 比較項目 | Inspector v1 | Inspector v2 |
|---|---|---|
| スキャン対象 | EC2のみ | EC2・ECR・Lambda |
| エージェント | 専用エージェント必須 | SSM Agentで動作 |
| スキャントリガー | 定期実行(スケジュール型) | イベント駆動(CVE公開・起動時) |
| マルチアカウント | 非対応 | Organizationsで一元管理可 |
| EOL | 2024年3月に終了 | 現行サービス |
Inspector v2を有効化してEC2スキャンを設定する手順
1. 前提条件を確認する(SSM Agentとインスタンスプロファイル)
EC2でInspector v2のソフトウェア脆弱性スキャンを有効にするには、次の2つを満たす必要があります。・SSM Agent 3.3.380.0以降がEC2にインストールされていること
・インスタンスプロファイルにSSM権限(AmazonSSMManagedInstanceCoreまたは同等の権限)が付与されていること
Amazon Linux 2023のEC2では、SSM Agentはデフォルトでインストールされています。バージョンを確認するには次のコマンドを実行します。
# EC2上でSSM Agentのバージョンを確認する [ec2-user@ip-10-0-10-45 ~]$ amazon-ssm-agent -version SSM Agent version: 3.3.587.0 GoVersion: go1.21.5 OS: linux OS Version: 4.14.355-268.575.amzn2023.x86_64 # バージョンが古い場合はアップデートする(Amazon Linux 2023) [ec2-user@ip-10-0-10-45 ~]$ sudo dnf update amazon-ssm-agent -y
# インスタンスプロファイルのARNを確認する aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f11111 --query 'Reservations[0].Instances[0].IamInstanceProfile.Arn' # 出力例(ロール名にSSMが含まれていることを確認する) "arn:aws:iam::123456789012:instance-profile/AmazonSSMRoleForEC2"
2. Inspector v2を有効化する
Inspector v2の有効化はアカウント単位で行います。AWS CLIから有効化する場合はaws inspector2 enableを使います。# Inspector v2を有効化する(EC2とECRを対象にする場合) aws inspector2 enable --resource-types EC2 ECR # 出力例(statusがACTIVATEDになれば有効化完了) { "accounts": [ { "accountId": "123456789012", "resourceStatus": { "ec2": "ACTIVATED", "ecr": "ACTIVATED", "lambda": "DISABLING" }, "status": "ACTIVATED" } ], "failedAccounts": [] } # 有効化の状態を確認する aws inspector2 batch-get-account-status --account-ids 123456789012 --query 'accounts[0].resourceState' # 出力例 { "ec2": { "status": "ENABLED", "statusCode": "ENABLING" }, "ecr": { "status": "ENABLED", "statusCode": "ENABLING" } }
statusCodeがENABLINGからENABLEDに変わったことを確認してから次のステップに進んでください。3. スキャン対象のEC2を確認する
有効化後、SSM Agentが動作しているEC2が自動的にスキャン対象として登録されます。カバレッジ状況はlist-coverageコマンドで確認できます。# Inspector v2のスキャン対象EC2を一覧表示する aws inspector2 list-coverage --filter-criteria '{"resourceType":[{"comparison":"EQUALS","value":"AWS_EC2_INSTANCE"}]}' --query 'coveredResources[*].[resourceId,scanStatus.statusCode,resourceMetadata.ec2.platform]' --output table # 出力例 ------------------------------------------------------------ | ListCoverage | +-----------------------+----------+---------------------+ | i-0a1b2c3d4e5f11111 | ACTIVE | AMAZON_LINUX_2023 | | i-0a1b2c3d4e5f22222 | ACTIVE | AMAZON_LINUX_2023 | | i-0a1b2c3d4e5f33333 | INACTIVE| AMAZON_LINUX_2 | +-----------------------+----------+---------------------+ # INACTIVEの場合は詳細な理由を確認する aws inspector2 list-coverage --filter-criteria '{"resourceType":[{"comparison":"EQUALS","value":"AWS_EC2_INSTANCE"}]}' --query 'coveredResources[?scanStatus.statusCode==`INACTIVE`].[resourceId,scanStatus.reason]' --output table
ACTIVEのEC2は数分以内にスキャンが開始されます。INACTIVEの場合は前提条件(SSM Agentのバージョンまたはインスタンスプロファイル)を確認してください。スキャン結果(検出内容)の読み方と深刻度判断
4. 検出結果を取得する
# 深刻度CRITICALのEC2脆弱性を取得する aws inspector2 list-findings --filter-criteria '{"severity":[{"comparison":"EQUALS","value":"CRITICAL"}],"resourceType":[{"comparison":"EQUALS","value":"AWS_EC2_INSTANCE"}]}' --query 'findings[*].[title,inspectorScore,packageVulnerabilityDetails.cvss[0].score,resourcesAffected[0].ec2Instance.instanceId]' --output table --max-results 10 # 出力例 ------------------------------------------------------------------------------------ | ListFindings | +-------------------------------------------+--------+-------+---------------------+ | CVE-2023-38545 in curl-minimal | 9.8 | 9.8 | i-0a1b2c111111 | | CVE-2024-3094 in xz-utils | 10.0 | 10.0 | i-0a1b2c111111 | | CVE-2023-44487 in libnghttp2 | 9.8 | 7.5 | i-0a1b2c222222 | +-------------------------------------------+--------+-------+---------------------+ # 実際に攻撃に悪用されているCVEを特定する(exploitAvailable=YES) aws inspector2 list-findings --filter-criteria '{"exploitAvailable":[{"comparison":"EQUALS","value":"YES"}],"resourceType":[{"comparison":"EQUALS","value":"AWS_EC2_INSTANCE"}]}' --query 'findings[*].[title,severity,inspectorScore,packageVulnerabilityDetails.vulnerablePackages[0].name]' --output table --max-results 5
5. Inspector v2スコアの読み方と修正優先度の判断
inspectorScoreはCVSSスコアに「実際の攻撃悪用実績(exploitability)」を加味したAWS独自のスコアです。CVSSスコアだけで優先度を判断するより実態に即した評価ができます。| Inspector v2スコア | 深刻度 | 対応優先度の目安 |
|---|---|---|
| 9.0~10.0 | CRITICAL | 即時対応(24時間以内) |
| 7.0~8.9 | HIGH | 優先対応(1週間以内) |
| 4.0~6.9 | MEDIUM | 計画的対応(次のパッチサイクル) |
| 0.1~3.9 | LOW | 任意対応(リスク評価後に判断) |
exploitAvailableがYES(実際の攻撃で悪用されている)のCVEは、CVSSスコアが中程度でも即時対応を優先してください。スコアは理論的な深刻度を示しますが、実攻撃への露出リスクは別の指標になります。たとえばCVE-2023-44487(HTTP/2 Rapid Reset Attack)はNVDのCVSSスコアは7.5(HIGH)ですが、実際に大規模なDDoS攻撃に悪用されたため、CVSSスコアだけで判断するよりも迅速な対応が必要でした。
SSMパッチマネージャーと連携した修正フロー設計
6. パッチベースラインを確認する
SSMパッチマネージャーは、Inspector v2が検出したCVEに対応するパッケージを自動適用するための仕組みです。まずデフォルトのパッチベースラインを確認します。# Amazon Linux 2023用のデフォルトパッチベースラインを確認する aws ssm describe-default-patch-baseline --operating-system AMAZON_LINUX_2023 # 出力例(抜粋) { "BaselineId": "pb-0c3b6a8a6a9a1b2c3", "Name": "AWS-AmazonLinux2023DefaultPatchBaseline", "OperatingSystem": "AMAZON_LINUX_2023", "ApprovalRules": { "PatchRules": [ { "PatchFilterGroup": { "PatchFilters": [ {"Key": "CLASSIFICATION", "Values": ["Security"]}, {"Key": "SEVERITY", "Values": ["Critical", "Important"]} ] }, "ApproveAfterDays": 0 } ] } }
7. Inspector v2の検出結果に基づいてパッチを適用する
Inspector v2で脆弱なパッケージが検出されたEC2に対して、SSMのRun Commandでパッチを適用します。# 特定のインスタンスにパッチを適用する(Run Command) aws ssm send-command --document-name "AWS-RunPatchBaseline" --document-version "1" --targets '[{"Key":"InstanceIds","Values":["i-0a1b2c3d4e5f11111","i-0a1b2c3d4e5f22222"]}]' --parameters '{"Operation":["Install"]}' --timeout-seconds 600 # コマンド実行状況を確認する(コマンドIDは前のコマンドの出力から取得) aws ssm list-command-invocations --command-id "a1b2c3d4-e5f6-7890-abcd-ef1234567890" --details --query 'CommandInvocations[*].[InstanceId,StatusDetails]' --output table # 出力例(Successになっていればパッチ適用完了) ---------------------------------------- | ListCommandInvocations | +-----------------------+-----------+ | i-0a1b2c3d4e5f11111 | Success | | i-0a1b2c3d4e5f22222 | Success | +-----------------------+-----------+ # マルチAZの全インスタンスに一括適用する場合はタグを使う aws ssm send-command --document-name "AWS-RunPatchBaseline" --targets '[{"Key":"tag:Environment","Values":["production"]}]' --parameters '{"Operation":["Install"]}' --timeout-seconds 600
AWS環境でのLinuxサーバー構築・運用スキルを体系的に学びたい方は、Amazon Linux × AWSの実践的な使い方からはじめるのがおすすめです。
Inspector v2が動かないときのトラブルシュート
カバレッジがINACTIVEになる(スキャン対象に登録されない)
最も多い原因はSSM Agentのバージョン不足、またはインスタンスプロファイルの権限不足です。・SSM Agentが古い: Amazon Linux 2でSSM Agentのバージョンが3.3.380.0未満の場合、Inspector v2のスキャン対象外になる。
sudo yum update amazon-ssm-agent -y(AL2)またはsudo dnf update amazon-ssm-agent -y(AL2023)でアップデートする・インスタンスプロファイル未設定: AmazonSSMManagedInstanceCoreポリシーを持つロールがアタッチされていないと、SSMインベントリの収集自体が動かないためスキャン対象外になる
・SSM Agentが停止している:
systemctl status amazon-ssm-agentでエージェントの稼働状態を確認する# カバレッジがINACTIVEなEC2の理由コードを確認する aws inspector2 list-coverage --filter-criteria '{"resourceType":[{"comparison":"EQUALS","value":"AWS_EC2_INSTANCE"}]}' --query 'coveredResources[?scanStatus.statusCode==`INACTIVE`].[resourceId,scanStatus.reason]' --output table # 出力例(reasonを見て対処する) --------------------------------------------------- | ListCoverage | +-----------------------+-------------------------+ | i-0a1b2c3d4e5f33333 | SSM_UNMANAGED | +-----------------------+-------------------------+ # SSM_UNMANAGED: インスタンスプロファイル未設定またはSSM Agentが停止中 # UNSUPPORTED_OS: Inspector v2が対応していないOSバージョン(Amazon Linux 1など)
検出結果が0件になる
正常にスキャンが動いており、かつ脆弱なパッケージが存在しない場合は0件が正常な結果です。ただし次の点も確認してください。・有効化直後でスキャンがまだ完了していない: 有効化後、最初のスキャン完了には5~15分かかることがある。
aws inspector2 get-findings-statisticsでスキャン統計を確認する・フィルタ条件が厳しすぎる:
list-findingsにフィルタを付けていない状態でもう一度実行して、全件を確認する・ネットワーク到達性スキャンのみ有効になっている:
batch-get-account-statusでスキャンタイプが正しく設定されていることを確認する本記事のまとめ
| やりたいこと | コマンド |
|---|---|
| Inspector v2を有効化する | aws inspector2 enable --resource-types EC2 ECR |
| 有効化状態を確認する | aws inspector2 batch-get-account-status --account-ids アカウントID |
| スキャン対象EC2の一覧を確認する | aws inspector2 list-coverage --filter-criteria '{"resourceType":[{"comparison":"EQUALS","value":"AWS_EC2_INSTANCE"}]}' |
| CRITICAL脆弱性を取得する | aws inspector2 list-findings --filter-criteria '{"severity":[{"comparison":"EQUALS","value":"CRITICAL"}]}' |
| 攻撃悪用済みCVEを絞り込む | aws inspector2 list-findings --filter-criteria '{"exploitAvailable":[{"comparison":"EQUALS","value":"YES"}]}' |
| パッチを適用する(Run Command) | aws ssm send-command --document-name "AWS-RunPatchBaseline" --targets '[{"Key":"InstanceIds","Values":["インスタンスID"]}]' --parameters '{"Operation":["Install"]}' |
| デフォルトパッチベースラインを確認する | aws ssm describe-default-patch-baseline --operating-system AMAZON_LINUX_2023 |
exploitAvailableフィールドを活用してCRITICALと実攻撃悪用中のCVEを優先的に対処し、SSMパッチマネージャーのRun CommandでEC2全体にパッチを一括適用する流れが実運用の標準設計です。VPC設計やAmazon Linux環境でのサーバー運用を体系的に習得したい方は、Amazon Linux × AWSの実践的な使い方からはじめるのがおすすめです。
Inspector v2でスキャンを自動化するには、AWS基盤の「型」が必要です
Inspector v2を正しく動かすには、SSM AgentとインスタンスプロファイルのIAM設計、パッチマネージャーとの連携設計など、AWS基盤全体の理解が必要です。断片的な知識の寄せ集めではなく、現場で実際に使われる設計パターンを一度体系的に身につけることで、安全なクラウド基盤が構築できるようになります。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:AWS KMSでEC2・RDS・S3の暗号化基盤を設計する方法|CMK設計・キーポリシー・データキー階層の実践パターン
- この記事の属するカテゴリ:AWS(Amazon Linux)へ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます