Amazon Inspector脆弱性診断｜AWS運用で押さえる対象範囲と改善手順

Amazon Inspectorによる脆弱性診断を検討・運用し始めたものの、EC2などで「何がどこまで見えるのか」「結果をどう業務に接続するのか」が曖昧なまま、取引先や社内から説明を求められて困る場面は少なくありません。ここを放置すると、検出結果が出ても担当や期限が決まらず未対応が積み上がり、結果として「2017年3月」のMS17-010の例のように更新遅れそのものがリスクになります。Inspectorを軸に、予防（脆弱性管理）と検知・調査・ログ保全を切り分けたうえで、社内SLAや台帳・タグまで含めて運用を設計できるようにしておくことが重要です。以下では、Amazon Inspector運用の判断材料として対象範囲・検査内容・設計論点を示します。

Amazon Inspector脆弱性診断の全体像

Amazon Inspectorの役割と導入目的

Amazon Inspectorは、AWS上のEC2やコンテナ等のリソースに対して既知の脆弱性を継続的に検出し、可視化するサービスです。運用の狙いは「年1回の診断を実施した」ではなく、日々変化するクラウド環境に対して脆弱性対応を回し続ける仕組みを作ることにあります。

参照情報で繰り返し強調されているとおり、クラウドではサービス提供側ではなく利用者側の設定不備や不正変更により情報漏えい等が生じ得ます。例えば「メール転送設定に攻撃者の宛先が追加される」など、攻撃者によりクラウド設定が不正に変更されるケースがあり、意図しない変更が起きていないかの確認が重要です。Inspectorはこのうち、主にOS・パッケージの既知脆弱性という観点から、攻撃の起点を減らし、侵害手段（TTPs）を取りにくくするための基盤になります。

また、脆弱性対応は「原因を取り除くパッチ適用」が基本である一方、重要システムでは再起動等の影響が出る場合があるため、事前に何日以内に停止してパッチを当てるかといった基準設計が必要だとされています。Inspectorの継続検出を前提に、社内の意思決定（停止可否・順序）と実作業（パッチ適用・緩和策）をつなぐのが導入目的です。

Inspectorで見える問題と、別サービスで補うべき問題の線引き

Inspectorが得意なのは、既知の脆弱性（CVE等）や、設定上の露出に関連する論点を「資産単位で」整理することです。一方、参照情報にあるようなインシデント対応では、被害範囲確認・根絶・復旧のために検索機能やログを使い、侵入経路や影響範囲、攻撃者のTTPsを追跡する必要があります。これらはInspector単体では完結しません。

補完設計の要点は、「Inspectorの検出＝即インシデント」ではなく、予防の検出と、侵害時に必要な検知・調査・ログ保全を切り分け、役割と責任（誰が判断し、誰が作業するか）まで落とし込むことです。

AWSでの診断対象と検査内容

パッケージ脆弱性と設定評価の見方

パッケージ脆弱性は、対象ホスト（例：EC2）に導入されているソフトウェア情報と、公表されている脆弱性情報を突合して評価します。実務上は「脆弱性がある」だけでなく、参照情報にある脆弱性分析の考え方（情報収集→技術調査→影響範囲特定→対処方法確定）に沿って、原因を取り除く方法（パッチ）と、難しい場合の緩和策まで一体で扱う必要があります。

なお、参照情報では2017年3月にMicrosoftが「MS17-010」として公表した脆弱性が、情報公開後も未適用のまま悪用され続けた点が指摘されています。これは、脆弱性の有無だけでなく、適用状況（更新の遅れ）そのものがリスクであることを示します。Inspectorの検出結果は、こうした「未更新資産の早期特定」に使い、パッチ適用や代替策の意思決定へつなげます。

Network Reachabilityの仕組みと限界

Network Reachabilityは、VPC内の各種設定（例：ルート、セキュリティグループ等）をもとに、到達可能な経路が設定として存在するかを静的に判定する考え方です。参照情報でも、同一ネットワークセグメントでは広く通信が可能になりやすく、異なるセグメントではルータの設定（ルーティング）により到達範囲が変わると説明されています。つまり、設計上の到達性は「意図した境界が機能しているか」を点検する重要な材料になります。

一方で、静的解析のため、以下は直接は分かりません。

したがって、到達性の指摘を受けた場合は「設定上の露出」なのか「実通信として成立している」なのかを分け、必要に応じてログ・監視側（例：不審サインイン、リソース変更、アクセス痕跡の追跡）と組み合わせて判断します。

外部公開ありでも即時対応が必要なケースと経過観察でよいケースの分け方

外部公開（到達可能）な資産で脆弱性が出た場合でも、すべてを同じ速度で直すと運用が破綻します。参照情報が示すインシデント対応の発想（侵害手段の削減、被害拡大の防止）に沿って、まずは「攻撃者が使いやすい入口」を優先します。

判断を曖昧にしないため、資産の重要度は参照情報のとおりC（機密性）/I（完全性）/A（可用性）で整理し、「停止してパッチ適用が可能な期限」を事前に設計しておくことが現実的です。

Amazon Inspector導入前の設計

アカウントとリージョンの整理方針

Inspectorを実務で機能させるには、まず「どこまでを見ているか」を説明できる状態が必要です。特にクラウドでは、攻撃者が侵害したアカウントを悪用してリソースを不正操作した痕跡がないか、またクラウド環境（設定）の変更有無（例：意図しないメール転送設定の追加など）を確認する必要がある、と参照情報でも述べられています。したがって、アカウント・リージョンに管理の空白を作らない方針が前提になります。

この段階で「脆弱性管理（Inspector）」と「設定変更や操作痕跡の確認（監査・ログ）」は別物であることも併記し、どのデータで説明責任を果たすかを切り分けます。

IAMとタグ設計の前提を固める

運用で詰まりやすいのは、検出結果そのものよりも「誰が責任を持って直すか」が曖昧な状態です。そのために、導入前の前提として、権限と識別のルールを固めます。

参照情報が示すとおり、脆弱性対応ではパッチ適用に伴う停止・再起動が問題になります。IAM・タグの設計は、その調整を迅速化するための情報基盤（誰に連絡し、どのルールで止めるか）として位置付けます。

OwnerタグがないEC2をどう扱うか：検出後に止まらない管理台帳の作り方

Owner不明のEC2が残ると、検出後に意思決定が止まり、結果として脆弱性が放置されます。参照情報でも、侵害時には被害範囲確認や根絶・復旧を行うために担当間連携が必要であり、状況が後手に回ること自体が問題とされています。したがって、Ownerタグ欠落は「運用停止の原因」として先に潰します。

責任追及ではなく、修正完了まで進めることを目的に、Owner不明の状態を「例外」ではなく「是正対象」として運用設計に組み込みます。

Amazon Inspectorの設定と実行

有効化とサービスリンクロールの確認

Inspectorを有効化すると、サービス連携のためのAWSServiceRoleForAmazonInspector2（サービスリンクロール）が作成され、必要な情報収集ができる前提が整います。実務では「有効化したつもりでも収集できていない」状態が最も危険なので、初期確認を手順化しておきます。

参照情報にある「設定上の不備を作らない」「人的ミスが起きる前提で監査する」という考え方に沿い、ロールと有効化状態の確認も定例点検に含めると説明責任を果たしやすくなります。

EC2へのエージェント導入と対象設計

EC2の内部情報（パッケージ等）を精度高く扱うには、管理系の仕組みが前提になります。参照情報では、侵害時に「どの端末が何台動いているか」を一覧化し、影響範囲を特定する重要性が述べられており、平時から資産の把握が重要です。Inspectorの対象設計でも、資産把握（どのEC2を対象にするか、例外は何か）を明確化します。

また、侵害拡大を防ぐ観点では、RAT等のマルウェアや攻撃者が利用する正規ツールが問題になることが参照情報に示されています。Inspectorはこれ自体を検知・阻止する製品ではないため、対象設計の段階で「脆弱性管理」と「EDR等の監視・隔離」の役割分担を明確化しておくと、運用が分断されにくくなります。

評価テンプレートと実行方法を決める

現行のInspectorは、継続評価（イベントに応じた再評価）を前提に運用を組み立てます。重要なのは「検出の頻度」よりも、参照情報が述べる脆弱性対応の要点である、脆弱性が公開されたらパッチが提供されることが多い、ただし再起動が必要な場合がある、だからこそ重要システムでは何日以内に停止して適用するか基準を設計する、という一連をワークフロー化することです。

ここまでを「個人の判断」ではなく運用基準として固定し、インシデント時に後追いで整備する事態を避けます。

評価結果を運用に結びつける

重要度と外部公開リスクを読み解く

Inspectorの結果は、脆弱性の深刻度だけでなく、環境条件（外部到達性等）とあわせて優先度を決めるために使います。参照情報が示すとおり、脆弱性対応の重要度は情報セキュリティの3要素であるC（機密性）/I（完全性）/A（可用性）に照らして決めるべきで、「直さないとどの程度の情報資産が危険にさらされるか」「完全性がどこまで損なわれ得るか」「どの程度の時間停止できるか」を検討して決定するとされています。

「外部公開だから即座に全停止」でも「スコアが高いから何でも即対応」でもなく、C/I/Aと停止可能時間をセットで扱うことで、経営・業務への説明可能性が上がります。

Systems Managerでパッチ対応をつなぐ

Inspectorの価値は、検出した脆弱性を修正（パッチ適用）や緩和策に確実につなげることで初めて発揮されます。参照情報でも、脆弱性対応は「確定した対策を実施する」段階が重要であり、パッチ適用の際に再起動が必要な場合があるため、重要システムでは停止計画を含めた基準設計が必要とされています。

修正の自動化を進めるほど、例外の管理（止められない、適用できない）が重要になります。例外を放置せず、緩和策と期限をセットで管理することが、コンプライアンス説明の土台になります。

Auto Scaling配下のEC2で手作業修正を避け、AMIとIaCへ戻す判断基準

Auto Scaling配下で稼働するEC2は、個体への手作業修正を行うほど、構成の乖離が生まれやすくなります。参照情報が述べる「網羅性を重んじるあまり本来の対応が後手に回るのは本末転倒」という注意にも通じ、緊急時ほど恒久対応へ早く戻す判断が必要です。

脆弱性対応は「直したつもり」が最も危険です。個体修正を例外にし、原則としてコード・イメージへ戻して全体を揃える運用が、監査・説明責任の観点でも合理的です。

AWS脆弱性管理の運用設計

Security HubやGuardDutyとの役割分担

AWS運用では、予防・検知・調査の機能を分離し、成果物（何を根拠に説明するか）を揃えることが重要です。参照情報にあるとおり、インシデントではログ等から侵入経路や影響範囲、TTPsを把握し、長期保管により発覚時期から遡って調査できるようにする必要があります。Inspectorはその中で「脆弱性という入口を減らす」役割に集中させます。

多層防御の設計では、「検出して終わり」ではなく、検知した事実をもとに誰が何をするか（隔離、通信制限、復旧）まで定義しておくことが重要です。

マルチアカウント統合管理の要点

マルチアカウントでは、各担当がバラバラに運用すると、抜け漏れが必ず出ます。参照情報が述べる「攻撃者によりクラウド上のリソースに対して不正操作を行った痕跡がないか確認する」には、対象範囲の網羅が前提になります。Inspectorについても、統合管理の要点は「全アカウントを同じ運用基準で回す」ことです。

Inspectorの検出結果は、統合ビューで「どこに未対応が残っているか」を説明する材料になりますが、それを支えるのはタグ・台帳・ログという運用基盤です。

Critical・High検出時に誰が何日以内に動くかを決める社内SLA設計

社内SLAは「速さ」だけでなく「止め方」まで決める必要があります。参照情報では、重要システムについて何日以内にシステムを停止し、パッチを適用するかといった具体的な対応基準をあらかじめ設計すること、また重要度はC/I/Aに照らして決めるべきことが述べられています。

そのため、Critical/Highのような区分を社内で使う場合は、単に日数を置くだけでなく、停止可否・緩和策・エスカレーションをセットにします。

この設計により、脆弱性対応を「担当者の頑張り」から「統制された業務プロセス」へ引き上げられます。

よくある質問

Amazon Inspectorだけで脆弱性対策は十分ですか？

十分ではありません。Inspectorは既知の脆弱性を中心に入口を減らす用途に強い一方、参照情報が求めるインシデント対応（被害範囲確認、根絶・復旧、IoC/TTPs収集、ログ追跡）を単体で完結させるものではありません。

したがって、Inspectorは「脆弱性管理の柱」として位置付けつつ、検知・調査・ログ保全の仕組みと合わせて運用設計する必要があります。

Network Reachabilityは実通信も確認しますか？

確認しません。参照情報にあるとおり、ネットワークスキャナ（例：nmapのようなスキャン）は時間がかかったり、セキュリティ機器の警告を引き起こす可能性があり、関係部門との調整が必要になることがあります。InspectorのNetwork Reachabilityはそうした「実スキャン」とは異なり、VPC設定を読み取って静的に到達性を推定するため、実通信による負荷や影響を前提にしません。

ただし静的解析のため、OS内部の設定や実際の待受、通信ログの事実確認は別途必要です。到達性の指摘が出た場合は、業務影響と調整コストも踏まえ、実スキャンやログ確認をどの範囲で行うかを決めます。

一部のEC2だけ対象外にできますか？

可能ですが、対象外は統制上の例外です。参照情報でも「人的ミスによって問題が生じ得る前提で、適宜監査していくのがよい」とされており、除外を増やすほど監査の重要性が上がります。

「とりあえず除外」は、監査・説明責任の観点で最も問題化しやすいため、例外管理として扱います。

本番EC2で実行すると性能影響はありますか？

静的解析の機能（Network Reachability）自体は、参照情報で触れられているような実スキャン（nmap等）とは異なり、ネットワークへのパケット送信を前提にしないため、ネットワーク負荷やセキュリティ機器の警告といった影響を起こしにくい設計です。

一方で、性能影響の説明責任としては「影響が小さい」だけでなく、「何が起きたら影響とみなすか」「インシデント時にどう通信制限するか」まで用意しておくと実務で強くなります。参照情報では、被害拡大防止のためにインバウンド・アウトバウンド両方の全遮断を検討し、業務影響が大きい場合は必要通信先だけ許可する（許可リスト）運用が述べられています。Inspectorは診断であり遮断機能ではありませんが、検出結果を受けて「どの通信を止めるか」を判断できるよう、平時から許可リスト・調整手順を整えておくと、本番影響を最小化しながら対処を進めやすくなります。

Amazon Inspectorへの対応で次にすべきこと

Amazon Inspectorは、EC2やコンテナ等の既知脆弱性を継続的に可視化し、未更新資産を早期に特定する「予防」の基盤として整理できます。一方で、Inspector単体で検知・調査・ログ保全まで完結しないため、Network Reachabilityの限界も踏まえ、役割分担を前提に運用設計へ落とし込むことが重要です。実務の判断軸は、検出の深刻度だけでなくC/I/Aと外部到達性を合わせ、重要システムでは「何日以内に停止してパッチ適用するか」を含めて社内SLAとして決める点にあります。次アクションとして、まずはアカウント・リージョンの対象範囲、Ownerタグと台帳の整備、有効化とAWSServiceRoleForAmazonInspector2の点検を揃え、検出から対処までの担当・承認・エスカレーションを明文化してください。個別の停止判断や例外（緩和策・期限）の妥当性は業務要件に依存するため、必要に応じて情報システム・セキュリティ担当や専門家と相談しながら設計するのが安全です。

Baseconnect株式会社
サイト運営会社

本メディアは、「企業が経営リスクを正しく知り、素早く動けるように」という想いから、Baseconnect株式会社が運営しています。

当社は、日本最大級の法人データベース「Musubu」において国内1200万件超の企業情報を掲げ、企業の変化の兆しを捉える情報基盤を整備しています。

加えて、与信管理・コンプライアンスチェック・法人確認を支援する「Riskdog」では、年間20億件のリスク情報をAI処理、日々4000以上のニュース媒体を自動取得、1.8億件のデータベース等を活用し、取引先の倒産・不正等の兆候の早期把握を支援しています。

運営会社情報ページへ