はじめに

Amazon Inspector（以下 Inspector）は、Amazon EBSやAWS Lambdaなどに対する脆弱性スキャンを行い、セキュリティリスクの早期発見と対応を支援してくれるサービスです。しかし、単に導入するだけで十分な運用は実現できません。スキャンモードの選択、そしてスキャン結果を組織としてどのように扱っていくかといった運用設計まで含めて考える必要があります。特に、どのスキャンモードを使うべきか、どのようにガバナンスを効かせていくかは、セキュリティレベルだけでなく、現場の運用負荷やコストとも密接に関わってきます。本記事では、Inspectorのスキャンモードの違いや適切な使い分け方、そして組織内でのガバナンスの取り方について、パターンごとに考えていきます。

スキャンモードをどのように使い分けるのか

Inspectorには、EBSボリュームにAWS Systems Manager Agent（以下 SSM Agent）を導入する方式と、EBSスナップショットベースでスキャンを行う方式があります。それぞれ特徴が異なるため、環境に応じて適切に選択することが求められます。

エージェントモード

エージェントモードは、EC2インスタンスにSSM Agentを導入したうえで、OSやパッケージ、サービスなどの内部情報にアクセスして脆弱性診断を行う方式です。CISベンチマークスキャンにも対応しています。

デフォルトのスキャン間隔は、短くすることはできませんが、State Managerの設定により延長することが可能です。デフォルトのスキャン間隔は以下の通りです。

Linux：30分に1回
Windows：6時間に1回

これらのデフォルト間隔は、SSMコンソールからState Managerを選び、以下のドキュメント名で対象OSに応じた設定を変更できます。

Linux用: InspectorInventoryCollection-do-not-delete
Windows用: InvokeInspectorSsmPlugin-do-not-delete

スキャンの対象範囲も柔軟に設定でき、Deep Inspectionではデフォルトのパスに加えて、カスタムパスを指定することでも可能です。

また、Inspectorの設定で特定のインスタンスに InspectorEc2Exclusion というタグを付与すれば、そのインスタンスはスキャン対象から除外することができます。さらに、スキャン対象のEBSボリュームがKMS暗号化されている場合、ボリュームのKMSキーに同様のタグを付与することで、エージェントレススキャンでも除外可能です。

ただし、エージェントモードの導入には現場の事情により、導入が難しいケースも少なくありません。たとえば、SSM Agentがバックグラウンドで動作することにより、CPUやメモリなどのリソース使用率がわずかに上昇することがあるため、導入が敬遠されることもあります。

また、社内ポリシーやセキュリティ統制の都合によって、勝手にAgentを導入してはいけないという制約がある場合もあります。委託先が構築したインフラや、管理対象が明確に分かれている環境では、「SSM Agentを入れることで境界があいまいになる」という理由で導入が認められないこともあります。さらに、情報システム部門がAMIやOS構成を統制している企業では、現場が独自にSSM Agentをインストールすること自体が難しいこともあります。

このような背景を考慮すると、すべてのEC2インスタンスに対してエージェントモードを適用するのは理想ではあっても、現実的に運用するためには柔軟な選択が必要になります。

ハイブリッドモード（エージェントモード + エージェントレスモード）

一方、エージェントレススキャンは、EC2インスタンスにSSM Agentを導入しなくてもスキャンを実施できる方式です。Inspectorが対象インスタンスのEBSボリュームを自動的にスナップショットし、そのスナップショットを分析することで脆弱性を検知します。つまり、インスタンス内部にアクセスすることなく、ボリュームの中身を読み取るかたちで診断を実現しています。

この方式では、対象インスタンスに対して最小限の事前設定だけでスキャンが可能であり、SSM Agentの有無にかかわらず導入できる点が大きなメリットです。特に、セキュリティポリシー上、Agentの導入が難しいインスタンスや、管理外の資産（たとえば委託先が構築した環境など）にもスキャン対象を広げられるという点で有用です。

ただし、スナップショットベースのスキャンであるため、継続的なリアルタイムスキャンというよりは、ある時点での静的スキャンに近い形になります。

料金はエージェントモードに比べてやや高めですが、導入の手軽さと適用可能な範囲の広さを考えると、導入ハードルが高い環境への有効な選択肢です。

aws.amazon.com

使い分け方

エージェントモードとエージェントレスモードは、それぞれ異なる特性を持っています。そのため、どちらか一方をすべてに適用しようとするのではなく、環境や制約、セキュリティ要件に応じて適切に使い分けることが重要です。以下は、現実的な判断基準の例です。

エージェントモードを優先する場面

セキュリティポリシーでCISベンチマークスキャンが求められている場合
長期的に稼働するインスタンスで、継続的な脆弱性のモニタリングが必要な場合
SSM Agentがすでに導入されている、あるいは自動で導入できる運用が整っている場合
SSM Agentによるリソース消費が問題とならない場合

エージェントレスモードを選択する場面

運用中のインスタンスにSSM Agentの導入が現実的に難しい場合
社内または委託先のポリシーにより、SSM Agentの導入が禁止・制限されている場合
SSM Agentがもたらすリソース消費をできるだけ避けたい場合

Inspectorの導入・運用においては、完璧な構成を最初から目指すよりも、制約の中で最大限セキュリティカバレッジを高める戦略を取ることが大切です。そのためには、環境ごとにスキャン方式を選択し、最終的には組織全体のリスクの可視化を実現していく必要があります。

パターンごとに考えるガバナンス強化方法

全アカウントに対して一貫したセキュリティ管理を行う

セキュリティの統制を最優先したい場合、CCoEが全てのメンバーアカウントにおけるInspectorの検知を把握し、メンバーアカウントで作業しているチームと共同で改善を進める運用が必要になります。この運用では、全体のセキュリティレベルを一貫して高く保つことができ、対応漏れや属人化のリスクを最小限に抑えることが可能です。この運用を実現するためには、監査アカウントでInspectorを有効化してメンバーアカウントの検知を監査アカウントのInspectorに集約させる必要があります。監査アカウントから全てのアカウントの検知を徹底的に管理することができます。

ただし、CCoEにかかる負荷は非常に大きくなります。すべてのアカウントの状況を監視し、継続的に改善するには相応の人員と時間が求められます。特に、各チームのエンジニアが他の業務と並行して動いているような現場では、検知から改善までを密に連携して進めるのは現実的に難しい場面もあります。なので、この運用はアカウント数が多くない組織で有効に働くケースが多いと言えます。

CCoEと現場で役割を分担しながら対応を進める

この運用では、CCoEはセキュリティ監査や検知の見える化に注力し、対応そのものは各メンバーアカウントに任せる形を取ります。具体的には、「全アカウントに対して一貫したセキュリティ管理を行う」運用と同じように監査アカウントでInspectorを有効化してメンバーアカウントの検知を監査アカウントのInspectorに集約させます。ただ、Inspectorによって検知された脆弱性への対応はメンバーアカウントで作業しているエンジニアに任せます。 CCoEは、メンバーアカウントで作業しているエンジニアが脆弱性に対応しやすいように検知内容をBacklogやJiraなどのチケット管理ツールに連携させることで、対応プロセスの可視化やトラッキングが可能になります。

メンバーアカウント主導でセキュリティを維持する柔軟な運用

セキュリティ対応を現場の裁量に任せたい場合には、CCoEがInspectorの利用ガイドラインや活用方針を整備し、定期的なアナウンスや勉強会などを通じて認知を広めるモデルが考えられます。実際のスキャンの有効化や検知への対応は各アカウントのエンジニアに委ねられるため、現場のスピード感や柔軟性を損なわずに運用できます。

ただし、このモデルではチームごとに対応方針が異なる可能性があり、セキュリティの品質が属人的になりやすくなります。特に、組織としての責任を問われるような場面では、十分な記録やエビデンスを残しておく必要があります。