「設定は開放、でも本当に届くの？」をSecurity Hub Network Scanningで5パターン検証してみた

この記事は「2026 Japan AWS Jr. Champions 真夏のQiitaリレー」の21日目の記事となります。
過去の投稿（リンク集）・ 昨日の記事は以下リンクからご覧ください。

はじめに

こんにちは、株式会社日本オープンシステムズの 崎田 です。
ふだんはAWSを触っていますが、ネットワークまわりはまだ勉強中の身です。
間違っている部分があれば、やさしく指摘してもらえると助かります。

セキュリティグループやネットワークACLを見直していると、ふと不安になります。
「この設定で、実際のところ外から届くんだっけ？」
塞いだつもりでも思わぬ経路で届くかもしれないし、開いて見えても中で何も動いていなければ入れない。設定を読むだけでは、本当に到達できるかは意外と分かりません。

2026年7月にリリースされた AWS Security Hub の Network Scanning は、この「設定と現実のズレ」を、実際に外からノックして確かめる機能です。気になって5パターンで検証しました。有効化は簡単でしたが、肝心の結果が最初は出ず、原因を直すまでに手こずったので、その過程も正直に書きます。

Network Scanning とは

公式ドキュメントの説明はこうです。

Network Scanning は Security Hub のオプトイン機能であり、クラウドリソースでアクティブなネットワーク到達可能性テストを実行します。コントロールプレーン分析では、セキュリティグループ、ネットワークアクセスコントロールリスト (NACLs)、ルートテーブルを評価して、到達可能なものを決定します。ネットワークスキャンは、実際に到達可能なものを検出することでさらに進みます。アカウントの外部からリソースを調べて、開いているポートと実行中のサービスを特定します。

私の理解で噛み砕くと、AWSが自分のリソースに外からドアをノックしに来てくれる機能です。従来のチェック（Inspectorなど）が設定を読んで「到達しうる」と判定するのに対し、こちらは実際にTCP接続して「本当に届くか」を確かめます。従来は「道が通っているか」、Network Scanning は「実際に入れるか」を見るわけです。

到達したポートごとに検出結果（finding）が作られ、ポート番号やHTTPの Server ヘッダーなど、実際に触った証拠が残ります。料金は追加でかからず、基本プラン（有効化時に選ぶ Essential）に含まれます。

検証の狙いと5パターン

「設定では危険に見えるが実際は届かない」構成と、「見落としがちだが実際は届く」構成をわざと作って比べます。

#	構成	実際に外から届く？	狙い
1	SG開放＋Web稼働(80)	届く	ベースライン
2	SG開放＋OSファイアウォールで80遮断	届かない	設定だけでは見抜けない
3	SG開放＋サービス未起動	届かない	ポートは開くが応答なし
4	SG開放＋NACLで80遮断	届かない	AWSの多層防御
5	8888番だけ開放＋Web稼働	届く	非標準ポートは拾われる？

主役はパターン2と3です。「設定監査だけでは足りない」を実証できるかがポイントです。

検証環境

CloudFormation で、パブリックサブネットにEC2を5台立てました。各サーバーにはWebサーバー（nginx）を用意し、遮断の仕方だけを変えています。たとえばパターン2は、nginx を動かしたままOS側のファイアウォールで80を落とします。なお、公開IPの持たせ方で後々つまずくのですが、それは後述します。

dnf install -y nginx iptables
systemctl enable --now nginx
iptables -I INPUT -p tcp --dport 80 -j DROP   # SGは開いたままOSで遮断

まず自分で答え合わせ

Network Scanning を見る前に、CloudShell から各IPへ curl して、実際の到達性を確認しておきます。

curl -s -m 5 -o /dev/null http://<P1のEIP>:80   && echo "P1 到達" || echo "P1 不達"
curl -s -m 5 -o /dev/null http://<P5のEIP>:8888 && echo "P5 到達" || echo "P5 不達"
# P2〜P4 も同様に 80 番へ

P1 到達 / P2 不達 / P3 不達 / P4 不達 / P5 到達

実際に届くのはパターン1と5だけ。これを基準に、Network Scanning の判定と突き合わせます。

コントロールプレーン分析は現実とズレる

有効化するとまず、コントロールプレーン分析による検出が出ました。代表は Amazon Inspector の「ネットワーク到達可能性」で、これは SG やルートの設定を解析して「経路上は外から到達しうる」と判定する機能です（実際にノックはしません）。これがパターン2・3まで「到達できる」と判定します。とくにパターン3は中で何も動いていないのに、です。設定上の経路が開いていればそう見えてしまう。一方でパターン4（NACL遮断）は検出なし。NACLも設定なので経路解析が見抜きます。

「道が通っているか」は分かっても「本当に応答があるか」までは分からない。ここを実際に確かめるのが Network Scanning です。

つまずき、自動割り当てIPだと結果が出ない

コントロールプレーン分析の検出は約12時間で出たのに、肝心の Network Scanning は24時間経っても1件も出ません。原因は、最初は EIP を付けず、自動割り当ての公開IPのままEC2を立てていたことでした。

対象リソース一覧にはEC2（パブリックIP）も載っているので、本来は拾われるはずです。

クラウドプロバイダー	リソースタイプ
AWS	EC2 インスタンス (パブリック IP を使用)
AWS	Elastic IP (EIP)

それでも私の環境では出ず、全台にEIPを付けたら解決しました。自動割り当てIPは変わりうるので、固定IPのEIPのほうが安定してスキャン対象と認識されるのだと思います。EC2で試すなら最初からEIPが確実で、検出はEIP側に出ます。

Network Scanning 本体の結果

EIP付与から初回検出まで約35分。新しい対象ができると直後に叩きに来ます。出たのはパターン1だけで、証拠もしっかり入っていました。

"port_scan_result_list": [
  {
    "http_response": {
      "http_headers": [ { "name": "Server", "value": "nginx/1.30.4" } ]
    },
    "port_info": { "port": 80, "protocol_name": "tcp" },
    "status": "Open",
    "svc_name": "smb"
  }
]

Server: nginx/1.30.4 で実際に応答が返ったと分かります。ただし svc_name は smb と誤り。サービス名は参考程度に見て、証拠（ヘッダー等）で判断するのが良さそうです。

パターン	構成	実際に外から届く？	コントロールプレーン分析（Inspector等）	Network Scanning
1	SG開放＋Web稼働(80)	届く	到達可	検出あり（80/nginx）
2	SG開放＋OSで80遮断	届かない	到達可（誤検出）	検出なし （正しい）
3	SG開放＋サービス未起動	届かない	到達可（誤検出）	検出なし （正しい）
4	SG開放＋NACLで80遮断	届かない	検出なし	検出なし （正しい）
5	8888だけ開放＋Web稼働	届く	到達可	検出なし （見落とし）

結果はきれいに割れました。コントロールプレーン分析が誤検出したパターン2・3を、Network Scanning は正しく検出しませんでした。実際にノックして返事が無かったからです。

一方でパターン5（8888番）は、手元の curl では届くのに検出されませんでした。理由は公式の「Scan traffic」にあります。

Scans use TCP only (no UDP) and scan a well-known subset of TCP ports. The exact list of ports might evolve over time.

「よく知られたポートの一部」しか叩かず、非標準の8888は対象外だったようです（対象ポートを増やす設定もありません）。「検出が無い＝安全」ではないということです。ちなみにこの8888は、コントロールプレーン分析（Inspector）が拾っていました。片方の死角を、もう片方が補う関係です。

まとめ

一番刺さったのは「設定を読むだけのチェックは、意外と簡単にだまされる」ことでした。中身が空のパターン3すら「到達できる」と言われたのは、正直驚きました。

ただ Network Scanning も万能ではなく、8888のような非標準ポートは見落とすことがあります。設定監査と実スキャンは、互いの弱点を補い合う関係だと感じました。そして今回の学びの大半は、機能そのものより「自動割り当てIPで詰まってEIPで解決した」つまずきの方にありました。

同じモヤモヤを抱えている人は、小さく1台立てて試してみると、きっと何か発見があります。この記事が、その一歩を踏み出すきっかけや、どこかの誰かの参考になればうれしいです。

参考リンク

• Network Scanning in Security Hub（公式ドキュメント）: https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-v2-network-scanning.html