AWS Organizations における Amazon Inspector 抑制ルールのベストプラクティス

本ブログは 2024 年 11 月 5 日に公開された AWS Blog「Amazon Inspector suppression rules best practices for AWS Organizations」を翻訳したものです。原文公開後のサービスアップデートを訳注として補足しています。

脆弱性管理は、ネットワーク、アプリケーション、インフラストラクチャのセキュリティに不可欠な要素であり、その目的は、機密データやインフラストラクチャが意図せずアクセスされたり露出したりすることから組織を保護することです。脆弱性管理の一環として、組織は通常、どの脆弱性が最大のリスクをもたらすかを判断するためのリスク評価を実施し、ビジネス目標や全体的な戦略への影響を評価し、関連する規制要件を精査します。

この記事では、AWS Organizations 内のアカウント全体で脆弱性に適切な優先順位を付けるための仕組みの使い方を説明します。お客様の環境における Amazon Inspector の検出結果にリスクベースで優先順位を付けられるよう、リソースにタグを適用する方法を紹介します。また、重要度の低い検出結果を大規模に抑制するための、Amazon Inspector の抑制ルールの活用に関するベストプラクティスも解説します。さらに、継続的な脆弱性管理の文化を醸成するための取り組みについても取り上げます。

Amazon Inspector による脆弱性管理

Amazon Inspector は、Amazon Web Services (AWS) のワークロードに対して、ソフトウェアの脆弱性や意図しないネットワークへの露出を継続的にスキャンする脆弱性管理サービスです。Amazon Inspector は、実行中の Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、Amazon Elastic Container Registry (Amazon ECR) 内のコンテナイメージ、および AWS Lambda 関数を自動的に検出してスキャンします。

Amazon Inspector は、ソフトウェアの脆弱性や意図しないネットワークへの露出を発見すると、検出結果を作成します。検出結果は、脆弱性を説明し、影響を受けるリソースを特定し、脆弱性の重要度を評価して、修復のガイダンスを提供します。Amazon Inspector で抑制ルールを作成すると、重要度の低い検出結果を抑制し、優先度の高い検出結果に集中できます。

AWS Organizations における脆弱性管理のベストプラクティス

AWS Organizations の組織内で数千件におよぶ脆弱性の検出結果に対処しやすくするために、このセクションで説明するベストプラクティスの活用をお勧めします。

ベストプラクティス 1: 委任管理者を設定する

Amazon Inspector を使用すると、組織内の複数の AWS アカウントの脆弱性スキャンを管理できます。そのためには、AWS Organizations の管理アカウントが、いずれかのアカウントを Amazon Inspector の委任管理者アカウントとして指定する必要があります。委任管理者アカウントは、Amazon Inspector のデプロイを一元的に制御できるため、AWS Organizations 内の複数のアカウント全体で、セキュリティモニタリングタスクをより効率的かつ効果的に管理できます。これらのタスクには、メンバーアカウントのスキャンのアクティブ化や非アクティブ化、AWS リージョンごとの検出結果の集約、組織全体の集約された検出結果データの表示、抑制ルールの作成と管理が含まれます。

Amazon Inspector はリージョンごとのサービスであるため、Amazon Inspector を使用する各 AWS リージョンで、委任管理者の指定、メンバーアカウントの追加、スキャンタイプのアクティブ化を行う必要があります。委任管理者アカウントを設定する際は、以下の点に注意してください。

• 委任管理者は、組織内のアカウントの Center for Internet Security (CIS) スキャン設定を作成および管理できます。ただし、メンバーアカウントが作成したスキャン設定は対象外です。
• マルチアカウント設定では、組織全体のスキャンモード設定を行えるのは委任管理者のみです。
• Amazon Inspector を使用すると、組織全体の Amazon EC2 インスタンスに対して、OS レベルの CIS 設定ベンチマークに基づいたオンデマンドかつ対象を絞った評価を実行できます。

訳注: 2025 年 11 月より、AWS Organizations の Amazon Inspector ポリシーによる組織全体の管理がサポートされました。このポリシーを使用すると、組織内の全アカウント (新規追加アカウントを含む)、組織単位 (OU)、または個別のアカウントに対してスキャンタイプを自動的に有効化し、メンバーアカウントによる意図しない変更を防止できます。本文の委任管理者による管理と併用でき、ポリシーがスキャンタイプの有効化を制御し、委任管理者はスキャンモードなどの詳細設定を引き続き管理します。

ベストプラクティス 2: 抑制ルールで検出結果を大規模に管理する

すべてのアカウントの検出結果には、個別の共通脆弱性識別子 (CVE) や Amazon リソースネーム (ARN) が数千件含まれている可能性があります。そのため、適切な抑制ルールを使ってこれらの検出結果を大規模に管理することが、脆弱性管理を成功させる鍵となります。

抑制ルールとは、フィルター属性と値のペアで構成される条件のセットで、指定した条件に一致する新しい検出結果を自動的にアーカイブすることで、検出結果をフィルタリングするために使用します。抑制ルールを作成して、対応する予定のない脆弱性を除外することで、最も重要な検出結果に優先順位を付けることができます。抑制ルールは検出結果自体に影響を与えず、Amazon Inspector による検出結果の生成を妨げることもありません。抑制ルールは検出結果のリストをフィルタリングするためだけに使用されます。これにより、検出結果の確認と優先順位付けが容易になります。

抑制ルールで使用できる便利なフィルターには、[リソースタグ]、[リソースタイプ]、[重要度]、[脆弱性 ID]、[Amazon Inspector スコア] があります。例えば、重要度レベル (Critical、High、Medium、Low、Informational、Untriaged) に基づいて検出結果を分類できます。Amazon Inspector が各検出結果の重要度をどのように決定するかについては、「Amazon Inspector の検出結果の重要度レベルについて」を参照してください。

Amazon Inspector では、脆弱性、アカウント、インスタンスなどのさまざまなカテゴリで検出結果を絞り込んで確認できます。Amazon Inspector の [すべての検出結果] ページで CVE ID を選択すると、図 1 に示すように、影響を受けるリソースと個々の AWS アカウント ID の詳細を表示できます。これは、抑制ルールで使用するフィルター条件を選択する際に役立ちます。

図 1: Amazon Inspector の検出結果と重要度レベル

抑制ルールは組織レベルで管理します。設定したルールはすべてのメンバーアカウントに適用されます。Amazon Inspector が抑制ルールに一致する新しい検出結果を生成すると、その検出結果のステータスは自動的に [抑制済み] に設定されます。抑制ルールの条件に一致する検出結果は、デフォルトでは検出結果のリストに表示されません。そのため、抑制された検出結果はサービスクォータに影響しません。メンバーアカウントは、委任管理者から抑制ルールを継承します。委任管理者アカウントで作成できる抑制ルールはリージョンあたり 500 ルールで、これは引き上げられない上限 (ハードリミット) です。

組織内のメンバーアカウントは、抑制ルールを作成または管理できないことに注意してください。抑制ルールを作成および管理できるのは、スタンドアロンアカウントと Amazon Inspector の委任管理者のみです。したがって、組織内に自身の抑制ルールを個別に管理する必要があるメンバーアカウントがある場合は、そのアカウントの所有者が自分のアカウントで Amazon Inspector を個別にアクティブ化する必要があります。

ベストプラクティス 3: Amazon Inspector スコアに基づいて検出結果を抑制する

対応に割ける時間は限られており、特に大規模な組織ではセキュリティ脆弱性の検出結果の量が膨大になる可能性があります。そのため、組織に最大のリスクをもたらす脆弱性を迅速に特定して対応できる仕組みが必要です。

検出結果を抑制する手軽なアプローチの 1 つは、Amazon Inspector スコアを使用することです。Amazon Inspector は、脆弱性に対する National Vulnerability Database (NVD) の共通脆弱性評価システム (CVSS) 基本スコアを構成するセキュリティメトリクスを検査し、お客様のコンピューティング環境に応じて調整したうえで、脆弱性の重要度を反映した 1～10 の数値スコアを生成します。

NVD/CVSS スコアは、攻撃の複雑さ、悪用コードの成熟度、必要な権限などのセキュリティメトリクスを組み合わせたものですが、リスクの尺度ではありません。

検出結果を過度に抑制しないよう注意してください。検出結果を過度に抑制すると、対策されていないセキュリティリスクにアプリケーションやシステムを意図せずさらしてしまう可能性があります。抑制ルールを適用する際は、慎重かつ節度あるアプローチを維持することが重要です。各検出結果の実際のリスクプロファイルを継続的に可視化しておくことは、プロアクティブで包括的な脆弱性管理に不可欠です。

ベストプラクティス 4: タグを使用してリスクベースの優先順位付けを可能にする

スケーラブルな脆弱性管理ソリューションを実現するには、アカウント横断でリソースに適切にタグを付ける戦略を持つことが重要です。

脆弱性に優先順位を付けるには、まず各リソースのリスクレベルを理解して評価し、適切にタグを付けられるようにする必要があります。適切なタグ付けにより、リスクベースの優先順位付けが可能になります。つまり、検出結果を評価する際に、リソースのリスクレベル、脆弱性の重要度、組織の環境に対する脆弱性の影響などの要素を考慮することで、重大な脆弱性に最初に集中できます。これは当たり前の推奨事項のように思えるかもしれませんが、その重要性は決して見過ごせません。クラウドでは、構築したすべてのものを把握し、保護する必要があります。潜在的なセキュリティイベントの影響とリスク経路を理解するために、資産のマッピングでは、資産間の関係性も併せて洗い出す必要があります。

クラウドリソースの問題を修復する際の優先度は、リソースの露出レベルによって決まります。一般的に、パブリックサブネット内のリソースはプライベートサブネット内のリソースよりも優先すべきです。同様に、本番環境で実行されているリソースは、開発環境やテスト環境のリソースよりも優先すべきです。

優先順位付けは、ファイアウォールルール、AWS Identity and Access Management (IAM) ポリシー、サービスコントロールポリシー、セキュリティグループなどの要素にも左右されます。さまざまなポートやプロトコルを通じてインターネットに広く公開されているリソースは、厳格なアクセス制限があるリソースと比べて、サービス拒否 (DoS)、分散型サービス拒否 (DDoS)、スプーフィング、マルウェア、ランサムウェアなどの問題が発生する可能性が高くなります。

ベストプラクティス 5: 適切なリソースタグに基づいて抑制ルールを作成する

複雑なマルチアカウント環境では、リソース ID、サブネット ID、VPC ID を使用して抑制ルールを一元管理することは困難な場合があります。これらの値は個々のアカウントに固有であり、新しいデプロイや変更に伴って時間とともに変化するためです。その結果、抑制ルールを最新の状態に保つことが難しくなります。ここでは、タグに基づくリスクベースの優先順位付け (ベストプラクティス 4) と Amazon Inspector スコアを活用して、検出結果を効果的に管理し、優先順位を付け、追跡する方法を説明します。

以下は、脆弱性管理を目的として組織内の AWS クラウドリソース全体で使用できる、タグ付け戦略の推奨例です。

EnvironmentName, RiskExposureScore

このタグ付け戦略により、環境全体で抑制ルールを通じた優先順位付けを行い、対応を後回しにする、あるいは対応対象外とすべき検出結果を除外し、優先度の高い検出結果に集中できます。また、リスク要因が異なる環境ごとに、個別のルールを作成することもできます。例えば、リスク露出レベルが低く、非本番環境にあり、重要度レベルが Informational、Untriaged、Low、または Medium であるリソースの検出結果を抑制するといったことが考えられます。さらに、レポートの作成やエクスポート時に [リソースタグ] フィールドを活用して、想定内の検出結果を除外することもできます。

以下の表では、Prod、Dev、Sandbox という 3 つの主要なアカウント区分を持つ AWS クラウド環境の例を示しています。想定されるリスク、露出レベル、ワークロードの重要性に基づいて、異なる重要度レベルの検出結果を抑制しています。この例では、RiskExposureScore の 1、2、3 をそれぞれ低、中、高に相当するものとして使用しています。つまり、RiskExposureScore 1 は、機密性が低い、またはインターネットへの露出がほとんどないワークロードに使用します。一方 RiskExposureScore 3 は、機密性が高い、または重要なワークロードのうち、インターネットに露出している、保護が不十分である、あるいは設定やサイバーハイジーン (cyber hygiene) の不備によりセキュリティリスクが高い可能性があるものに使用します。

この例では、Prod および Dev アカウントのリソースについては重要度が High または Critical である脆弱性の検出結果を残す一方で、その他のリソースについてはリスク露出レベルに応じて異なる抑制ルールを定義しています。また、Sandbox アカウントには重要なワークロードがないため、脆弱性の検出結果の大部分を抑制するようにしています。この例をモデルとして、環境全体で抑制ルールを設定し、ニーズに応じて脆弱性の検出結果に優先順位を付けることができます。さらに、修復作業を進めながら抑制ルールを見直し、修正、再評価できることも覚えておいてください。これらを継続的なプロセスとして行うことがベストプラクティスです。

ベストプラクティス 6: Amazon Inspector を AWS Security Hub と統合する

Amazon Inspector を AWS Security Hub と統合すると、Amazon Inspector から Security Hub に検出結果を送信できます。Security Hub は、これらの検出結果をお客様のセキュリティポスチャの分析に含めることができます。抑制ルールに一致する Amazon Inspector の検出結果は自動的に抑制され、Security Hub コンソールには表示されません。

訳注: 本記事の AWS Security Hub は、2025 年に AWS Security Hub CSPM (Cloud Security Posture Management) へ名称変更されたサービスを指します。現在「AWS Security Hub」は、リスクの優先順位付けなどの機能を備えた別の新サービスの名称として使われているため、コンソールやドキュメントを参照する際はご注意ください。

ベストプラクティス 7: 抑制ルールを定期的に再評価する

セキュリティポスチャを最新に保ち、健全なクラウド環境を維持する鍵は、脅威の状況の変化に合わせて脆弱性管理のアプローチを見直し、適応させ続けることです。ここでは、重点的に取り組むべきプラクティスをいくつか紹介します。

• 脆弱性の検出結果を抑制しているルールを定期的に見直し、再評価してください。脆弱性と脅威は常に進化しているため、以前に抑制したものを再度有効にする必要が生じるかもしれません。
• 脆弱性管理を静的な手順ではなく、継続的で反復的なプロセスとして捉えてください。新たなリスクにリアルタイムで対処するために、セキュリティコントロールを定期的に評価し、更新し、適応させてください。
• 初期の修復だけでなく、継続的なモニタリングと対応も重視してください。脆弱性はライフサイクル全体を通じて包括的に対処する必要があります。
• セキュリティを意識し、迅速に対応する文化を組織全体で醸成してください。全員が継続的に脆弱性の特定と軽減に取り組むことが求められます。
• 脆弱性管理プログラムが、関連するコンプライアンス要件や規制要件 (例えば PCI-DSS、HIPAA、NIST CSF) に準拠していることを確認してください。

まとめ

この記事では、抑制ルールを使用し、リスクベースの優先順位付けを適用することで、組織の AWS インフラストラクチャ全体で Amazon Inspector の検出結果に大規模かつ効果的に優先順位を付ける方法を紹介しました。また、Amazon Inspector の検出結果の修復に優先順位を付けるための効果的な戦略として、リソースのタグ付けを活用する方法についても説明しました。Amazon Inspector に関連するその他のブログ記事については、Amazon Web Services ブログの Amazon Inspector カテゴリを参照してください。