Amazon Web Services ブログ

AWS がネットワークスキャンのガイドラインを導入

本ブログは 2025 年 11 月 25 日に公開された AWS Blog “Introducing guidelines for network scanning” を翻訳したものです。

Amazon Web Services (AWS) は、お客様のワークロードを対象としたネットワークスキャンのガイドラインを導入します。ガイドラインに準拠したスキャナーは、より正確なデータを収集でき、不正利用として報告されることも最小限に抑えられます。さらに、すべての人にとってのインターネットのセキュリティ向上にも貢献できます。

ネットワークスキャンは、現代の IT 環境で用いられる手法です。正当なセキュリティ目的で使われることもあれば、悪意のある活動に悪用されることもあります。正当な用途としては、組織がネットワークスキャンを実施して、資産の正確なインベントリを維持し、セキュリティ設定を検証します。また、対応が必要な潜在的な脆弱性や古いバージョンのソフトウェアを特定します。セキュリティチーム、システム管理者、認可を受けたサードパーティのセキュリティ研究者にとって、スキャンはセキュリティポスチャのデータを収集するための標準的なツールの 1 つです。一方で、スキャンは脅威アクターも実行しており、システムの列挙、弱点の発見、攻撃に向けた情報収集に利用されています。正当なスキャン活動と潜在的に有害な偵察を見分けることは、セキュリティ運用における絶え間ない課題です。

スキャンによって特定のシステムでソフトウェアの脆弱性が見つかる場合、そのスキャナーが善意に基づいてスキャンしていることが特に重要です。ソフトウェアの脆弱性が脅威アクターに発見され、攻撃に悪用されると、組織の IT システムへの不正アクセスにつながるおそれがあります。組織は、ランサムウェア、データ窃取、運用上の問題、規制上の罰則から自らを守るため、ソフトウェアの脆弱性を効果的に管理する必要があります。その一方で、NIST National Vulnerability Database のデータが示すとおり、既知の脆弱性の数は過去 10 年間、年率 21% のペースで急速に増加しています。

こうした状況を踏まえ、ネットワークスキャナーには、スキャンの実施と収集したセキュリティデータの管理を慎重に行うことが求められます。セキュリティデータに関心を持つ関係者はさまざまで、グループごとにデータの使い方も異なります。セキュリティデータが脅威アクターに発見されて悪用されると、システムの侵害、ランサムウェア、サービス拒否によって、システム所有者に業務の混乱やコストが生じる可能性があります。エネルギー、製造、ヘルスケア、政府、教育、金融、運輸の各分野で重要なサービスを提供するデータセンターやネットワークに接続されたソフトウェアワークロードは、指数関数的に増加しています。そのため、セキュリティデータが悪意のある者の手に渡った場合、現実世界に重大な影響を及ぼすおそれがあります。

複数の関係者

セキュリティデータには複数の関係者が利害を持っています。少なくとも次のようなグループが挙げられます。

  • 組織は、資産を保護するため、資産インベントリを把握し、脆弱性に迅速にパッチを適用したいと考えています。
  • プログラム監査人は、組織がインフラストラクチャを管理するための堅牢な統制を整備している証拠を求めています。
  • サイバー保険会社は、組織のセキュリティポスチャのリスク評価を求めています。
  • デューデリジェンスを実施する投資家は、組織のサイバーリスクプロファイルを把握したいと考えています。
  • セキュリティ研究者は、リスクを特定して組織に通知し、対策を促したいと考えています。
  • 脅威アクターは、不正アクセスを目的として、パッチが適用されていない脆弱性や弱点を悪用しようとしています。

セキュリティデータは機密性が高いため、利害が対立する関係者が入り組んだ複雑なエコシステムが形成されています。組織はその中で、関係者ごとに異なるレベルのデータアクセスを維持しなければなりません。

ガイドラインを導入する理由

ここまで、ネットワークスキャンの正当な用途と悪意のある用途、そしてスキャン結果のデータに関心を持つさまざまな関係者について説明しました。AWS がこのガイドラインを導入する理由は、AWS のネットワークとお客様を保護する必要があり、同時にこれらの関係者を見分けるのが難しいためです。インターネットでネットワークスキャナーを識別するための単一の標準は存在しません。そのため、システム所有者や防御担当者は、誰がシステムをスキャンしているのかを把握できていないことが少なくありません。これらのさまざまな関係者の識別は、各システム所有者が個別に管理する必要があります。ネットワークスキャナーは、逆引き DNS、カスタムユーザーエージェント、専用のネットワーク範囲など、独自の方法で自らの身元を示す場合があります。悪意のあるアクターであれば、識別そのものを回避しようとすることもあります。このように識別方法がまちまちなため、システム所有者がネットワークスキャンを実行している関係者の動機を把握するのは困難です。

この課題に対処するため、AWS はネットワークスキャンに関する行動ガイドラインを導入します。AWS はすべてのお客様にネットワークセキュリティを提供することを目指しており、このガイドラインを満たさない不正なスキャンを排除することを目標としています。広範囲にネットワークスキャンを行う関係者は、このガイドラインに従うことで、AWS の IP 空間からより信頼性の高いデータを取得できます。また、AWS でワークロードを運用する組織は、リスク管理においてより高い確実性を得られます。

ネットワークスキャンがこのガイドラインに沿って管理されれば、システム所有者は防御を強化し、デジタルエコシステム全体の可視性を高めることができます。例えば、Amazon Inspector は、このガイドラインに準拠しながら、ソフトウェアの脆弱性を検出し、修復作業の優先順位付けを行えます。同様に、AWS Marketplace のパートナーも、このガイドラインに従ってインターネット全体のシグナルを収集し、組織がサイバーリスクを把握し、管理できるよう支援しています。

「組織が自らのセキュリティポスチャとサードパーティのセキュリティポスチャをデータに基づいて明確に可視化できれば、より迅速かつ的確な意思決定を行い、エコシステム全体のサイバーリスクを低減できます」 – Bitsight CTO、Dave Casion 氏

もちろん、セキュリティは協力して取り組むことでより効果を発揮します。AWS のお客様は、不正なスキャンを Trust & Safety Center に報告できます。報告の際は、種類として [Network Activity] > [Port Scanning and Intrusion Attempts] (ネットワークアクティビティ > ポートスキャンと侵入の試み) を選択してください。それぞれの報告が、セキュリティデータの悪用に対する全体的な保護の強化につながります。

訳注: 2026 年 10 月時点の報告フォームでは選択肢が原文の記載と異なり、[Port Scanning and Intrusion Attempts] という項目はありません。[AWS] (AWS が所有するリソース) と [Network Activity] (ネットワークアクティビティ) を選択した後、[Type of abuse] (不正使用の種類) で、不正なスキャンの報告には [Port scanning] (ポートスキャン) を選択します。ログイン試行や脆弱性の悪用など侵入の試みを伴う場合は [Intrusion attempts (ssh, FTP, etc.)] (侵入の試み (ssh、FTP など))、HTTP のクローリングやボットによるアクセスの場合は [Web crawling, scraping, and bots] (ウェブクローリング、スクレイピング、ボット) も該当します。

ガイドライン

正当なネットワークスキャナーが脅威アクターとの違いを明確に示せるよう、AWS はお客様のワークロードをスキャンする際のガイダンスを次のとおり提供します。このネットワークスキャンに関するガイダンスは、ペネトレーションテストと脆弱性の報告に関するポリシーを補完するものです。AWS は、このガイドラインに準拠していないと見られるトラフィックを制限またはブロックする権利を留保します。このガイドラインに準拠したスキャナーは、次のプラクティスに従います。

観察のみ

  • 検出したエンドポイント上のリソースやデータを作成、変更、削除しようとする操作は一切行いません。
  • 対象システムの完全性を尊重します。スキャンによってシステムの機能を低下させたり、システム設定を変更したりしません。
  • 変更を伴わないスキャンの例は次のとおりです。
    • TCP ハンドシェイクの開始と完了
    • SSH サービスからのバナーの取得

識別可能

  • スキャン活動の送信元を公開し、透明性を確保します。
  • スキャン活動の真正性を確認できる検証可能なプロセスを実装します。
  • 識別可能なスキャンの例は次のとおりです。
    • スキャン元 IP の逆引き DNS ルックアップのサポート (自組織のパブリック DNS ゾーンのいずれかに属する名前を返す)
    • リクエストの種類 (サービスの存在確認、脆弱性チェックなど) ごとに整理したスキャン用 IP 範囲の公開
    • HTTP スキャンの場合は、ユーザーエージェント文字列への意味のある情報 (自組織のパブリック DNS ゾーン内の名前、オプトアウト用の URL など) の記載

協調的

  • 対象システムへの影響を最小限に抑えるため、スキャンレートを制限します。
  • 検証済みのリソース所有者がスキャン活動の停止を要求できるよう、オプトアウトの仕組みを提供します。
  • 妥当な期間内にオプトアウトの要求に従います。
  • 協調的なスキャンの例は次のとおりです。
    • 宛先サービスごとに、スキャンを 1 秒あたり 1 サービストランザクションまでに制限
    • robots.txt や security.txt など、サイト所有者の意図を表すための業界標準で示されたサイト設定の尊重

機密保持

  • SOC2 などの業界標準の認証に示されるような、安全なインフラストラクチャとデータ取り扱いのプラクティスを維持します。
  • 収集したスキャンデータに対して、認証されていないアクセスや権限のないアクセスが発生しないようにします。
  • ユーザーの識別と検証のプロセスを実装します。

AWS が公開しているガイダンスの全文をご覧ください。

今後の展望

このガイダンスに従うネットワークスキャナーが増えれば、システム所有者は機密性、完全性、可用性に対するリスクを低減できます。正当なネットワークスキャナーは、自らの意図を明確に示し、可視性の質も向上させます。ネットワークを取り巻く状況は絶えず変化しているため、AWS は、このガイダンスが技術的な統制とともに今後も進化していくと考えています。AWS とインターネット全体のセキュリティポスチャを継続的に改善していくため、お客様、システム所有者、ネットワークスキャナーをはじめとする皆様からのご意見をお待ちしています。

この記事に関するフィードバックがある場合は、AWS サポートにお問い合わせください。

Stephen Goodman

Stephen Goodman

Stephen は、Amazon active defense のシニアマネージャーとして、AWS のお客様とインターネットを脅威アクターから守るためのデータ駆動型プログラムを主導しています。

本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。