ASMの仕組み：IPスキャンだけでは見えない攻撃面をどう発見するか
要旨
ASM（Attack Surface Management）は、登録されたIPアドレスを定期的にポートスキャンするだけの仕組みではない。既知のドメイン、IPレンジ、ASN、組織名などを起点に、DNS、証明書、WHOIS/RDAP、HTTPレスポンス、クラウドやCDNとの関係をたどり、「自社に関係しそうな外部公開資産」を増やしていく仕組みなのだ。
そのうえで、IPとポートに対するネットワーク観測、TLSハンドシェイク、ホスト名を指定したHTTP通信を組み合わせる。発見した対象を所有資産、委託先、依存先、候補、誤検知に分類し、変化を継続監視して初めてASMになる。
CDNやCloud WAFが一般化した現在、Web資産をIPアドレスだけで識別する価値は限定的である。同じ共有IPに多数のホスト名が収容され、接続時のTLS SNIとHTTP Hostによって異なるサービスへ到達するためだ。Webの観測単位は、実務上 scheme://hostname:port と考えたほうがよい。
ただし、IPスキャンが不要になったわけではない。SSH、RDP、VPN、SMTP、データベースなどの非HTTPサービス、意図せず公開された管理ポート、CDNを迂回できるオリジンIPを見つけるには、IPとポートの観測が欠かせない。ASMの価値はIPかドメインのどちらかではなく、複数の観測面を同じ資産グラフへ結び付けるところにあるのだ。
ASMを一つの「スキャン」と考えると分かりにくい
ASMは、次の五つの処理を繰り返すシステムとして捉えると分かりやすい。
| 処理 | 主な入力 | 得たい結果 |
|---|---|---|
| 1. シード登録 | ドメイン、IPレンジ、ASN、組織名、既知ホスト | 探索の起点 |
| 2. 関係探索 | DNS、証明書、登録情報、HTML、リダイレクト、共有属性 | 未知の資産候補 |
| 3. 外部観測 | ポート接続、プロトコル固有通信、TLS、HTTP | 現在の公開状態 |
| 4. 帰属判定 | シードとの関係、複数の証拠、人手の確認 | 所有、依存、候補、除外 |
| 5. 継続監視 | 前回との差分、初回・最終観測時刻 | 新規公開、消滅、設定変化、リスク変化 |
Microsoft Defender EASMは、ドメイン、IPブロック、ホスト、連絡先、ASN、WHOIS組織をシードとして取り込み、関連するインフラを再帰的に探索すると説明している。関係が十分に強いものは確認済みインベントリへ入り、確度が足りないものは候補や要調査として残る。つまり、ASMの難所は「応答を取れるか」だけではなく、「その応答を自社の責任範囲へ入れてよいか」なのだ。1
1. シードから資産候補を広げる
最初に必要なのは、組織に確実に属する少数の起点である。代表ドメインだけを登録することもできるが、それだけでは買収会社、旧ブランド、別管理のクラウド環境、IP直公開の機器を落としやすい。
代表的なシードは次のとおりである。
- ルートドメインと既知のサブドメイン
- 保有または割り当て済みのIPレンジ
- ASN
- 法人名、ブランド名、WHOIS/RDAP上の組織名
- 証明書に現れる組織名や既知の証明書
- クラウドアカウント、既知のストレージ名、既知のSaaSテナント
探索エンジンは、A/AAAA/CNAME/MX/NSなどのDNS関係、証明書のSAN、リダイレクト先、HTMLやJavaScript内の参照先、同じ登録情報、同じネットワークといった手掛かりをたどる。ただし、証拠が一つ一致しただけで所有を断定してはいけない。
たとえば、同じCDNのIPに解決されることは所有関係の証拠になりにくい。共通の分析タグ、委託先のネームサーバ、同じ証明書も、それぞれ単独では誤帰属を起こし得る。関係探索は資産候補を増やす装置であり、所有を自動的に証明する装置ではないのだ。
2. IPとポートから、公開サービスを探す
IPスキャンは、指定したIPアドレスのポートへTCPやUDPで通信し、応答するサービスを探す。開放ポートを見つけた後は、SSH、SMTP、DNS、NTP、TLS、HTTPなど、推定したプロトコルに応じた問い合わせを送り、バナーや設定情報を収集する。
Shodanは、インターネットへ直接接続された機器へ問い合わせ、公開情報を収集すると説明している。中心となるデータは、サービスが返したソフトウェア情報、対応機能、歓迎メッセージなどのバナーである。Shodanの通常検索は直近30日以内の最新バナーを扱い、同社はインターネット全体を少なくとも週1回クロールするとしている。23
Censysも、TCPを基本に一部UDPやQUICを使い、200を超えるL7プロトコルを検出すると説明している。想定外のポートで別プロトコルが返れば、応答を見て適切なハンドシェイクをやり直す。これは「22番はSSH、443番はHTTPS」と固定的に決め打ちするより深い観測である。4
IP起点が今も強い領域は次のとおりである。
- SSH、RDP、VPN、FTP、SMTP、DNS、NTP、SNMP
- データベース、検索基盤、メッセージング基盤
- ネットワーク機器、IoT、OT、管理インターフェース
- 443以外で待ち受けるHTTPS管理画面やAPI
- DNSに登録されていない一時環境やIP直公開サービス
- CDN/WAFを迂回して到達できるオリジン
ここでは、IPとポートの組み合わせ自体が資産の重要な観測単位になる。
3. CDN/WAF配下では、IP単体の意味が変わる
CloudflareでDNSレコードをプロキシすると、利用者のDNS問い合わせにはオリジンではなくCloudflareのAnycast IPが返る。このIPレンジはプロキシ対象のホスト名で共有される。したがって、見えているIPをそのまま個別企業のサーバとみなすことはできない。56
共有IPへホスト名なしで接続しても、得られるのは次のような情報に偏る。
- CDN事業者のネットワークと公開ポート
- CDN側のデフォルト証明書またはTLS設定
- デフォルトのエラーページ
- CDN共通のHTTPヘッダー
- 403、404、421など、名前が一致しない場合の応答
これは無価値ではないが、背後のアプリケーションを十分に表していない。Cloudflare自身も、プロキシ前段をPCIスキャナで検査すると、別顧客向けの待受けを含むポートが開いて見える場合があり、その通信が顧客オリジンへ届くとは限らないと説明している。7
一方、HTTPSで対象ホスト名を指定すると、TLS SNIとHTTP Hostにより、その名前に対応する証明書、WAFポリシー、ルーティング、コンテンツへ到達できる。同じIPでもホスト名が異なれば、観測対象は別のWeb資産なのだ。
Web ASMでは、少なくとも次を一組として記録する必要がある。
scheme + hostname + port
https://app.example.jp:443
https://api.example.jp:443
http://legacy.example.jp:8080
接続時の解決先IPも重要だが、それはWeb資産の識別子そのものというより、その時点の配信経路や基盤属性になる。
4. 名前付きHTTP観測で、アプリケーションの外形を取る
ホスト名を発見しただけでは、その名前が現在何を提供しているかは分からない。ASMは、TLSハンドシェイクやHTTP GETなどを実行し、外部クライアントから見える挙動を記録する。
観測できる代表例は次のとおりである。
| 層 | 観測例 |
|---|---|
| DNS | 現在の解決先、CNAME、メール・ネームサーバ関係 |
| TLS | 証明書、SAN、有効期限、プロトコル、暗号設定、SNI別の差 |
| HTTP | ステータス、ヘッダー、Cookie、タイトル、本文、favicon、リダイレクト |
| アプリケーション | ログイン画面、管理画面、製品指紋、公開ディレクトリ、特定パス |
| 配信基盤 | CDN、WAF、ロードバランサ、ホスティング事業者 |
Censysは、IPで識別するHostとは別に、ホスト名とポートで識別するWeb Propertyを提供している。Web PropertyはDNSで名前を解決してスキャンされ、特定IPに固定されない。HTTP本文、リダイレクト、/login や /admin などルート以外のパス、HTTP上で動くアプリケーション固有情報を扱う。2026年8月2日時点のCensys資料では、Web Propertyは日次で更新されるとしている。8910
BinaryEdgeのWeb v2スキャナも、実行例でGET、Hostヘッダー、URL、レスポンス本文、リダイレクトを記録する。設定項目にはHTTPメソッド、パス、Hostヘッダー、カスタムヘッダーがある。Shodan以外のインターネット観測サービスでも、Webの価値を得るためにアプリケーション層の通信を行う設計が確認できるのだ。1112
5. 観測結果へ脆弱性とリスクを付ける
バナー、製品指紋、証明書、HTTP応答を得た後、ASMは設定不備や脆弱性情報を付与する。ただし、「CVEが表示された」と「対象で脆弱性が再現された」は別である。
Shodanは脆弱性情報をverifiedとunverifiedに分けている。unverifiedは、観測した製品名やバージョンなどのメタデータから関連付けたもので、誤検知があり得る。verifiedは追加確認により検証されたものだが、Shodan自身もすべての脆弱性を検証できるわけではないとしている。13
ASMの画面では、少なくとも次を分けて読む必要がある。
- 実際に観測した事実：ポート、証明書、ヘッダー、本文、交渉結果
- 観測からの推定：製品名、バージョン、CDN/WAF、所有関係
- データベース照合：CPEやバージョンに対応するCVE
- 検証結果：追加プローブにより条件成立を確認したもの
- 業務判断：自社所有か、重要か、対応が必要か
推定と実証が同じ「脆弱性」欄へ平らに並ぶと、修正担当者は無駄な確認に追われる。PoCでは検出件数より、根拠フィールドと確度を追跡できるかを見るべきなのだ。
「パッシブASM」という言葉が曖昧になる理由
ASM事業者自身が対象へ通信せず、ShodanやCensysなどから既存の観測結果を取得することはできる。この収集経路だけを見れば、そのASM事業者にとってはパッシブである。
しかし、元データは第三者が対象へTCP接続、TLSハンドシェイク、HTTP要求、プロトコル固有プローブを送って作った可能性がある。したがって、「ASM製品が自らスキャンしない」と「利用データがアクティブスキャン由来ではない」は同じではない。
実務では、パッシブかアクティブかという一語ではなく、次を分けて確認したほうがよい。
| 確認点 | 質問例 |
|---|---|
| データ生成主体 | 自社スキャナ、提携先、公開データのどれか |
| 対象への通信 | TCP/UDP、TLS、HTTP、特定パス、検証プローブを送るか |
| 観測単位 | IP:portか、hostname:portか、URLか |
| 追加確認 | 顧客資産に対してオンデマンド再スキャンするか |
| 侵入性 | 認証試行、状態変更、exploit検証を行うか |
| 識別方法 | 送信元IP、User-Agent、逆引き名、opt-out手段はあるか |
GETであっても対象へ要求を送ればアクティブな観測である。ただし、GETと侵入的な脆弱性検証、認証試行、状態変更を同じ強さの「アクティブスキャン」と扱うのも粗すぎる。通信の有無と、通信が対象へ与える深度・影響は別軸で評価する必要がある。
IPスキャンの価値は低下したのか
Web資産に限れば、「IPアドレスだけを全ポート走査し、443番のデフォルト応答だけを見る」方式の情報価値は下がっている。共有CDN/WAF、仮想ホスト、マネージドホスティングが増え、企業固有のアプリケーションと共有基盤を分離しにくいためである。
しかし、ASM全体ではIPスキャンの価値は残る。理由は三つある。
非HTTPサービスはIP側から見つかる
SSH、RDP、VPN、SMTP、DNS、データベースなどは、一般的なWeb CDN/WAFを経由しない。ホスト名の候補を先に知っているとも限らない。IPレンジとポートから探すほうが自然である。
オリジン露出は別の名前やポートに現れる
Cloudflareは、DNS-onlyレコードがプロキシ対象サイトと同じオリジンIPを指すと、そのIPが露出すると注意している。メールや検証用サブドメイン、過去の構成、別ポートの管理画面が手掛かりになるため、名前付きWeb観測だけでは足りない。14
IPは関係グラフの重要な中継点である
あるホスト名がどのIPへ解決され、同じIPに何があり、どのASNやクラウドに属し、いつ変化したかは帰属判定に役立つ。共有基盤では弱い証拠だが、専有IPや保有レンジでは強い証拠になり得る。
結論は「IPスキャンは古い」ではない。IP単独でWebアプリケーションを代表させるモデルが足りないのだ。
ASM製品を評価する質問
製品資料で「継続的に攻撃面を発見」「攻撃者視点で可視化」と書かれていても、観測の仕組みは同じとは限らない。PoCでは次を確認する。
| 評価領域 | 確認事項 |
|---|---|
| シード | ドメイン、IPレンジ、ASN、組織名、クラウドを何から開始できるか |
| 再帰探索 | どの関係を何段までたどり、候補の根拠を表示するか |
| 帰属 | 所有、依存、候補、誤検知を分け、人が修正できるか |
| IP観測 | TCP/UDP、非標準ポート、非HTTPプロトコルをどこまで扱うか |
| Web観測 | SNIとHostを指定し、hostname:port単位で取得するか |
| HTTP深度 | ルート以外のパス、リダイレクト、本文、favicon、JavaScriptを扱うか |
| CDN/WAF | 共有IPを企業固有資産として過大計上しないか |
| 脆弱性 | 観測、推定、CVE照合、検証済みを区別するか |
| 鮮度 | 発見、再観測、差分通知の頻度と時刻を示すか |
| 安全性 | 送信元、User-Agent、レート、禁止操作、opt-outを説明できるか |
| データ源 | 自社観測と第三者データを区別し、生成過程を説明できるか |
特に、CDN配下の自社Webサイトと、DNS-onlyで露出したオリジン、同一組織のVPN、委託先に置かれたキャンペーンサイトをテスト対象にすると、製品の得意不得意が見えやすい。
まとめ
ASMは、単なるポートスキャナでも、DNS台帳でも、脆弱性スキャナでもない。既知のシードから関係を広げ、複数の方法で外部から観測し、帰属と確度を付け、変化を追う仕組みである。
現代のWeb資産では、IPアドレスだけではCDN/WAFの共有基盤しか見えない場合がある。実際のサービスを観測するには、ホスト名、SNI、Host、ポート、HTTPパスを含む名前付きの通信が必要になる。一方、非HTTPサービスやオリジン露出を拾うにはIPスキャンが必要である。
したがって、よいASMは「IPかドメインか」を選ばない。IP、DNS、証明書、TLS、HTTP、登録情報、過去と現在の差分を同じ関係グラフへ載せ、それぞれの観測が何を証明し、何を証明しないかを残す。そこまでできて、ようやく外から見た攻撃面が運用可能なインベントリになるのだ。