AWS Inspector v2でEC2の脆弱性スキャンを設計する方法|CVE自動検出とSSMパッチ連携の実践手順

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)AWS(Amazon Linux) > AWS Inspector v2でEC2の脆弱性スキャンを設計する方法|CVE自動検出とSSMパッチ連携の実践手順
「EC2を立ち上げてセキュリティグループとWAFを設定すれば安全だと思っていたら、OS上の脆弱なパッケージがそのまま放置されていた」——AWSに移行したLinuxエンジニアがよく直面する問題です。
ネットワーク層の防御は整っていても、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パッチマネージャーと組み合わせることで検出から修正まで自動化できる


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

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月に終了 現行サービス
v1は2024年3月にEOLを迎えているため、まだv1を利用中の方はv2への移行が必要です。v2は無効化して再有効化しない限り、スキャンが継続して実行され続ける点も重要です。

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

インスタンスプロファイルの確認はAWS CLI側から行うこともできます。

# インスタンスプロファイルのARNを確認する aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f11111 --query 'Reservations[0].Instances[0].IamInstanceProfile.Arn' # 出力例(ロール名にSSMが含まれていることを確認する) "arn:aws:iam::123456789012:instance-profile/AmazonSSMRoleForEC2"

インスタンスプロファイルが未設定の場合は、コンソールの「EC2 → インスタンス → セキュリティ → IAMロールを変更」から、AmazonSSMManagedInstanceCoreポリシーを持つロールをアタッチしてください。

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" } }

有効化後、スキャンが開始されるまで数分かかります。statusCodeENABLINGから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 任意対応(リスク評価後に判断)
重要な判断軸として、exploitAvailableYES(実際の攻撃で悪用されている)の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 } ] } }

デフォルトのベースラインはセキュリティ分類の「Critical」と「Important」のパッチを即日承認する設定になっています。Inspector v2でCRITICAL・HIGHと判定された脆弱性の多くはこのベースラインでカバーされますが、組織のポリシーに合わせてカスタムベースラインを作成することもできます。

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

パッチ適用後、Inspector v2の次のスキャンサイクル(数分以内)で同じCVEが検出されなくなれば修正完了です。マルチAZ構成で複数のインスタンスが存在する場合は、タグを使ってまとめて適用すると効率的です。

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
AWS Inspector v2は、EC2のCVE管理を「手動確認」から「自動スキャン+優先度付き検出」へ移行するための重要な設計パターンです。SSM Agentの前提条件を満たせばエージェントのインストールなしに有効化でき、マルチAZ構成のすべてのインスタンスが即座にスキャン対象になります。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日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。