「脆弱性スキャンを始めたら、大量の通知で運用がパンクした」

これは、多くのエンジニアが一度は通る道です。Amazon Inspector は、EC2やコンテナ、Lambdaの脆弱性を自動で検出し続けますが、その真価は単に「見つけること」ではなく、「運用を自動化し、判断のノイズを減らすこと（トリアージの効率化）」にあります。

今回は、Amazon Inspector の挙動の正体と、実運用で役立つ設計のツボを整理しました。

1. Amazon Inspector の正体：攻撃検証ではなく「事実把握」

Amazon Inspector は、AWSリソース上で稼働するソフトウェアに含まれる既知の脆弱性（CVE）を継続的に検出するマネージド脆弱性管理サービスです。

ここで最も重要なのは、Amazon Inspector は「実際に攻撃が可能か」を判断するペネトレーションテストツールではないという点です。あくまで「脆弱性が存在するか」という事実を、AWS内部の視点から報告するサービスであることを理解しておく必要があります。

2. スキャンの仕組み：エージェントベースとエージェントレススキャンの「二段構え」

特にEC2のスキャンにおいては、エージェントベースとエージェントレススキャンの仕組みを正しく理解することが、設計の鍵となります。

スキャン方式 仕組み メリット 物理的制約・注意点
エージェントベース SSM Agent経由でOS内部情報を収集 リアルタイム性が高い エージェントの常駐が必要
エージェントレススキャン EBSスナップショットを外側から解析 サーバーの負荷がゼロ 合計1,200GB以下、ボリューム数8個未満、対応FS（ext3, ext4, xfs等）の制約

内部から詳細を拾う「エージェントベース」と、外部から非侵入で解析する「エージェントレススキャン」。これらを組み合わせることで、管理外のインスタンスも含めた網羅的な脆弱性管理が可能になります。

「スキャンされない」トラブルの事前回避

エージェントレススキャンは便利ですが、EBSをカスタマー管理キー（KMS）で暗号化している場合、Amazon Inspector のサービスリンクロールに復号権限（kms:Decrypt）を与えていないとスキャンは失敗します。

「設定したのに検出結果（Finding）が出ない」という原因不明のトラブル対応こそが運用を疲弊させる要因です。KMSの権限を正しく設計しておくことが、安定した運用の第一歩です。

3. 「危険度」を正しく評価する：Amazon Inspector スコア

※検出結果（Finding）一覧画面：数百件並ぶ「Critical」や「High」の文字に圧倒されますが、重要なのはここからどう「今すぐ直すべきもの」を絞り込むかです。Amazon Inspector は各脆弱性に対し、文脈を加味した独自のスコアリングを行います。

Amazon Inspector は、単にCVEをリストアップするだけでなく、ネットワーク構成等を分析してリスクを再評価します。

  • 文脈によるリスク判断

VPCの設定やセキュリティグループの構成情報を分析し、「外部から到達可能か（Network Reachability）」を12時間に1回判定します。これにより、ベースとなるCVSSスコアから、環境に最適化された「Amazon Inspector スコア」へと自動的に調整されます。

※脆弱性の概要だけでなく、右側の詳細パネルには「修正済みバージョン」や、その脆弱性がネットワーク的に「到達可能か」というインテリジェンスが表示されます。この情報が、無駄な調査時間を削減する鍵となります。

  • トリアージの効率化

「重大な脆弱性があるが、外部から遮断されている」リソースの優先度を下げるなど、エンジニアが「今すぐ直すべきもの」を正しく判断できる仕組みが備わっています。

4. 「疲弊しない」ための自動化フローと通知設計

Amazon Inspector は「回すもの」ではなく、「勝手に回り続けるもの」です。通知で疲弊しないために、以下のようなフィルタリング設計を導入するのが実務の定石です。

※ 一例ですが、すべての検出結果を通知すると運用負荷が高まるため、EventBridgeを活用して『SeverityがHIGH以上のもの』など、すぐに対応が必要なものだけをフィルタリングし、低・中優先度のものはAWS Security Hubに集約させ、ダッシュボードでの定期的なモニタリングや網羅的なリスク分析に回すという運用設計にすることで、アラート疲労を防ぎつつ継続的なセキュリティ管理が可能になります。

運用負荷を下げる通知フィルタリング案

「全ての検出結果（Finding）」を通知すると、運用負荷が高まりますので、Amazon EventBridge を活用し、以下の条件でフィルタリングを行います。

  • 重要度による絞り込み： Severity が HIGH または CRITICAL のものに限定。
  • 未対応のものに限定： 状態が ACTIVE かつ、まだ調査が始まっていない firstObservedAt（初回検知）のタイミングのみ通知。
  • 抑制ルール（Suppression rules）の活用： 開発環境や、パッチも代替の回避策（ワークアラウンド）も存在せず、存在しないことが判明している特定パッケージ等は、Amazon Inspector 側で「抑制ルール」を設定します。これにより『対応不要な検出結果』をビューから隠し、Security Hubや運用者に流れるノイズを自動的に排除します。

※実際の抑制ルール設定画面： この例では、重要度の低い「Low」「Informational」を抑制するだけで、163件ものノイズを自動的に排除しています。画面を確認するたびに「重要度の低いアラート」を見るストレスから解放される、最も効果的な設定です。

5. SBOM（ソフトウェア部品構成表）：構成証明とガバナンス

Amazon Inspector は、現在の脆弱性を出すだけでなく、SBOM の出力にも対応しています。

継続スキャンがあるのに、なぜ別途 SBOM を管理するのか？

Amazon Inspector 自身は常に最新のCVEと照合し続けていますが、SBOMをS3等にエクスポートしておくことには、スキャンとは別の価値があります。

  • 特定時点の構成証明： 監査や規制対応において「○月○日時点で稼働していたソフトウェアの一覧」を公式な証跡として提示できます。
  • サプライチェーンの透明性： 自社開発したコンテナやパッケージを他社へ提供する際、信頼性の証明としてSBOMを添付することが可能です。
  • 将来のゼロデイ発生時の初動： 新たな脆弱性が発見された際、当時の稼働状況を遡って「どのシステムに影響があったか」を迅速に特定するためのガバナンス資料として機能します。

まとめ：Amazon Inspector は「人の判断」を減らすために使う

Amazon Inspector を導入するゴールは、脆弱性をゼロにすることではなく、「判断のコストを最小化すること」にあります。

  • 修正はしない： 診断のみを行い、実際の修正（yum update等）は人間または他の自動化ツールが行います。
  • Amazon Security Hub との連携： Amazon Inspector は「検出担当」、Amazon Security Hub は「集約・評価担当」として役割を分担させ、運用者は Amazon Security Hub の画面のみを注視する体制を構築します。