サブドメインも外部攻撃面の一部

外部攻撃面には、代表ドメインだけでなく、 その配下のサブドメイン(FQDN)も含まれます。 www.example.co.jpmail.example.co.jp のほか、 過去のプロジェクトで作った stg.example.co.jpapi.example.co.jp も、DNS で公開されていれば第三者が名前を知る手段があります。

社内では「本番以外は忘れがち」「担当者が退職した」という理由で説明が途切れやすい一方、 インターネット上では生きている URL・応答するサービスとして残り続けます。

よく問題になるパターン

サンプル報告書(架空)では、公開情報から 9 件の FQDN を確認し(F-04)、 api.example.co.jp を非本番・API 系の優先棚卸し候補として挙げ、 crt.sh 由来の名前が代表ドメイン用証明書の SAN に含まれないケース(F-17・F-18)も示しています。 体裁の参考は報告書サンプルをご覧ください。

なぜ「社内では使っていない」のに危ないか

社内担当者がブックマークしていなくても、攻撃者やボットは 辞書的なサブドメイン名の列挙公開インデックス(証明書ログ等)からホスト名を集めます。 応答が返れば、本番より緩い設定の環境がそのまま入口になりうる、という点が分かりやすい典型です。

典型例は次のとおりです。

「本番サイトは安全」だけでは説明が足りず、 サブドメイン全体の地図があると優先順位を話しやすくなります。

外部攻撃面レビューで「見る」こと(例)

観点 確認する内容(例)
列挙 公開 DNS・crt.sh 等から得られる FQDN 一覧(契約スコープ内)
生存確認 HTTP / HTTPS 応答の有無、リダイレクト、タイトル・サーバヘッダの手がかり
命名ルール stg / dev / test 等のパターンに該当するホスト
優先度 管理系・非本番・高リスク応答の有無を踏まえた棚卸し候補の整理

目的は「全部潰せ」ではなく、 第三者から見えている名前と、先に説明・確認すべき入口を 報告書にまとめることです。 全ポートスキャンやログイン突破は別契約・別スコープであることが多いです。

棚卸しの進め方(御社側の作業イメージ)

DNS レコードの削除やサーバー停止は、通常御社・インフラベンダーの作業です。 レビュー結果をもとに、次のような台帳づくりを進める組織が多いです。

  1. 一覧化 — 報告書の FQDN リストを起点に、用途・担当・本番/非本番を記入
  2. 要否判断 — まだ必要か、VPN 内に移せるか、DNS 削除で足りるか
  3. ルール化 — 新規サブドメイン発行時の承認・命名規則・定期見直し(年次など)
  4. 再確認 — 次回の攻撃面レビューで「消えたか」「新しく増えていないか」を比較

サンプル報告書の推奨アクションにも、 「サブドメイン棚卸しを年次で実施し、不要な DNS レコードを削除する」とあります。

含まないこと(よくある誤解)

調査データは閉域環境内で扱います

調査結果の記録は当社事業所内の閉域環境でのみ保管・処理します。 公開 DNS や Web への問い合わせは発生しますが、 御社データを当社クラウドや第三者 SaaS に載せる運用は行いません。 報告書は基本メールで納品し、調査画面のログインはお渡ししません。

関連する読み物

御社ドメインのサブドメイン一覧を事実ベースで整理する場合は お問い合わせください。