まず結論
EC2 の脆弱性を継続的に見たいなら、Amazon Inspector は有力な選択肢です。Inspector は、EC2 インスタンス上のソフトウェア脆弱性や、外部から到達可能なネットワーク経路などを評価します。
ただし、Inspector を GuardDuty や Security Hub と混同すると設計が雑になります。Inspector は「脆弱性や露出を見つける」サービスであり、GuardDuty のように不審な挙動を検知するサービスではありません。
この記事では、Amazon Inspector を EC2 の脆弱性管理で使うときの基本を整理します。
Inspector が見るもの
Amazon Inspector は、EC2 やコンテナイメージ、Lambda 関数などを対象にした脆弱性管理サービスです。ここでは EC2 に絞ります。
EC2 では主に次のような観点を見ます。
| 観点 | 内容 |
|---|---|
| ソフトウェア脆弱性 | OS パッケージやアプリケーションライブラリに関連する CVE |
| ネットワーク到達性 | インターネットなど外部から到達可能な経路 |
| 重要度 | CVSS、悪用可能性、影響範囲などを踏まえた優先度 |
| 対象リソース | どの EC2 インスタンスに問題があるか |
たとえば、ある EC2 に古い OpenSSL パッケージが残っていて既知 CVE に該当する場合、Inspector は検出結果として提示します。運用チームはそれを見て、パッチ適用、AMI 更新、インスタンス置き換えなどを判断します。
GuardDuty とは役割が違う
Inspector と GuardDuty はどちらもセキュリティ系サービスですが、見ているものが違います。
| サービス | 主な役割 | 見るもの |
|---|---|---|
| Amazon Inspector | 脆弱性管理 | CVE、露出、対象リソース |
| Amazon GuardDuty | 脅威検知 | 不審な API 呼び出し、通信、挙動 |
| AWS Security Hub | 集約と基準チェック | 複数サービスの Findings、セキュリティ標準 |
Inspector は「穴があるか」を見ます。GuardDuty は「怪しい動きがあるか」を見ます。Security Hub は、それらの Findings を集約し、基準に照らして見やすくします。
この切り分けをしないと、「GuardDuty を入れているから脆弱性管理もできている」といった危ない誤解が生まれます。できていません。役割が違います。
Inspector を入れるだけでは終わらない
Inspector を有効化すると Findings は出ます。しかし、Findings が出ることと、脆弱性管理が回ることは別です。
最低限、次の運用を決める必要があります。
- Critical / High の Findings を誰が見るのか
- パッチ適用までの SLA をどうするのか
- 本番 EC2 と検証 EC2 で優先度を変えるのか
- Auto Scaling Group 配下の EC2 は AMI 更新で直すのか
- 例外承認をどこに記録するのか
- Security Hub やチケットシステムにどう流すのか
たとえば、Auto Scaling Group で管理している EC2 に SSH して手作業でパッチを当てるのは、だいたい筋が悪いです。次の起動で古い AMI に戻るなら、直した気分だけが残ります。AMI やイメージパイプライン側を更新するべきです。
よくある失敗パターン
Inspector 導入時によくある失敗は、検出結果を出すところで満足することです。
| 失敗 | 何がまずいか |
|---|---|
| Findings を見ない | 検出しても修正されない |
| 重要度だけで判断する | インターネット露出や業務影響を見落とす |
| 手作業パッチだけで対応する | AMI や IaC に修正が戻らない |
| GuardDuty と混同する | 脆弱性管理と脅威検知の責任分界が曖昧になる |
| Security Hub に流して終わる | 集約しても所有者がいなければ動かない |
セキュリティサービスは有効化ボタンを押した瞬間に勝つわけではありません。Findings を誰が、どの期限で、どの方法で潰すのかを決めて初めて運用になります。
実務での最小構成
最初から巨大なセキュリティ運用を作る必要はありません。まずは小さく回る形にします。
- Inspector を有効化する
- 対象アカウントと対象リージョンを明確にする
- Critical / High の Findings を日次で確認する
- EC2 の所有者タグを整備する
- 修正方法を「手作業」ではなく AMI / IaC / パイプラインに戻す
- Security Hub に集約する場合も、担当チームと SLA を決める
タグは地味ですが重要です。Owner や Service がない EC2 は、脆弱性が出ても誰に直してもらうのか分かりません。セキュリティ以前に台帳が死んでいます。
まとめ
Amazon Inspector は、EC2 の脆弱性や意図しない露出を継続的に見つけるためのサービスです。GuardDuty や Security Hub と役割を分けて理解する必要があります。
- Inspector は CVE やネットワーク到達性を見る
- GuardDuty は不審な挙動を検知する
- Security Hub は Findings を集約する
- Findings を誰が直すのか決めないと運用にならない
- EC2 の修正は AMI、IaC、パイプラインへ戻すべき
Inspector は「入れて終わり」ではありません。Findings を修正する流れまで設計して、ようやく脆弱性管理として機能します。