ガイドSC

IT資産台帳・ASM・シャドーITと残存CNAME

公開: 2026-09-26更新: 2026-09-26
公開資産の発見、DNSとクラウドの照合、放置されたCNAMEからのサブドメイン乗っ取り、停止と復旧条件を学ぶ。

企業の公開サイトは正常でも、試験環境preview.corp.exampleのCNAMEが削除済みクラウドサービスを指したままなら、第三者に利用される可能性があります。さらに、部署が申請せず公開したdev.corp.exampleが資産台帳にありません。IT資産管理、外部公開資産の発見、ASM、シャドーIT、残存CNAMEを一つの棚卸しで読み、何が本当に乗っ取られたのかまで証拠で判定します。

読む順序は、用語→実際の構成と処理→記録の照合→異常の成立条件→変更・復旧→短答演習です。以下の組織、アドレス、時刻、識別子、ログは教材用の架空例です。観測できた事実と、追加調査が必要な推論を分けて読みます。

1. 用語をこの事案の判断に結び付ける

用語

意味とこの事案での判断の限界

IT資産管理

機器、仮想資源、ドメイン、クラウド、ソフトウェア、管理主体とライフサイクルを記録し更新すること。台帳の行があるだけでは実物が稼働中とは限らない。

ASM

Attack Surface Management。攻撃者から到達可能な資産・サービスを発見・評価・是正する継続的な活動。この例では外部公開面に注目し、内部台帳とのずれを調べる。

外部公開資産

インターネットから名前解決や接続ができるホスト、API、CDN、管理画面等。DNSに名前があるだけでサービス稼働を断定せず、IPv4/IPv6と複数経路を確認する。

シャドーIT

部署が中央の管理・承認を通さず導入した資産。業務上必要な場合もあるため、見つけ次第削除するのでなく責任者、データ、認証、更新経路を確かめる。

A / AAAA

名前からIPv4/IPv6アドレスへ対応付けるDNSレコード。古いIPは別の利用者へ再割当てされ得るが、A/AAAAが残るだけで乗っ取り確定ではない。

CNAME

別のDNS名へのエイリアス。preview.corp.exampleからold-project.vendor.exampleへ向ける。参照先のサービス実体と、その名前を誰が再登録できるかを別に確認する。

残存・dangling DNS

サービスを削除した後もDNS参照を残した状態。参照先が再利用可能な事業者であればサブドメイン乗っ取りの入口になり得る。全ての残存レコードが直ちに悪用可能ではない。

サブドメインテイクオーバー

第三者が参照先のサービス名やカスタムドメインを取得し、当社のサブドメイン経由で自分の内容を配信すること。成立にはサービス事業者側の割当規則や所有確認を満たす必要がある。

2. 構成と判断する位置

corp.exampleの公開DNSには、shop.corp.example→203.0.113.20、dev.corp.example→198.51.100.19、preview.corp.example CNAME old-project.vendor.exampleがあります。shopは正式な販売サイト、devは部署が独自に作った公開検証環境、previewは終了したキャンペーン用です。

架空の事業者vendor.exampleは、old-projectというサービス名を削除後に別契約者へ再割当てでき、当社ドメインの所有確認が不十分な設定だったとします。この再割当て規則は教材上の前提で、実際の事業者では保護方法が異なります。

公開DNSと三つの資産DNSの名前と、管理者が把握する実体のずれを示す。利用者公開DNS公開先1234外部利用者corp.exampleshopdevpreview
公開DNSと三つの資産
  1. 1. 名前を照会
  2. 2. A: 正式サイト
  3. 3. A: 台帳にない
  4. 4. CNAME: 参照先確認

DNSの名前と、管理者が把握する実体のずれを示す。

図のpreviewはDNS上の参照であり、現時点で攻撃者がサービスを取得したことまで表しません。devは実際に外部公開されている一方、台帳にないことが問題です。shopも台帳にあるだけで設定・公開範囲が正しいとは限りません。

3. 正常時の処理と管理

  1. 登録ドメイン、委任DNS、公開ゾーン、証明書、クラウド契約、FW・ロードバランサの設定を、責任者を付けて台帳へ登録する。

  2. 外部から名前解決と接続を定期的に観測し、A/AAAA/CNAME、ポート、HTTP Host、TLS証明書、応答内容を収集する。観測日時とDNS TTLを記録する。

  3. 観測された名前とIPをDNS管理者、クラウド資産、台帳、事業部の申請記録へ突き合わせ、台帳外のdevと参照先不在のpreviewを調査対象にする。

  4. サービス終了時は、DNSを先に撤去するか新しい管理済み先へ切り替え、キャッシュ残存・トラフィックを確認してから事業者側の名前を解放する。

  5. 定期的な再照合で、新規公開・所有者不明・期限切れ・第三者サービスの再割当てを検出し、削除または管理下へ移す。

資産のライフサイクルには作成、変更、所有者移転、廃止があり、廃止時だけDNSを忘れると残存名が生じます。DNS担当とクラウド担当が別なら、リソース削除チケットにDNSレコードの撤去確認を必須項目として結び付けます。TTL期間内のキャッシュを考慮して、切替と削除の順序も決めます。

4. 設定・記録のフィールドを読む

項目

読み方と注意点

fqdn / zone

shop、dev、previewの完全修飾名と権威DNSを記録。別ゾーンへ委任していれば親ゾーンだけの検索では漏れる。

A / AAAA / CNAME

A/AAAAはアドレス、CNAMEは別名。CNAME先の名前解決に失敗しても、一時障害・非公開・削除のどれかは別に確認する。

TTL / observed_at

キャッシュの有効時間と観測時刻。DNS変更直後に旧応答が残るため、異なるリゾルバや権威サーバの結果を区別する。

HTTP Host / TLS SNI

共有IPのサービス選択に影響する。IPへ直接接続しただけでは対象サブドメインへの応答を確認できない。

cloud_resource / owner

参照先サービスの実在、契約主体、カスタムドメイン登録、担当者を照合。DNS応答だけでは誰が運用するか不明。

first_seen / last_seen

外部観測の開始・最終時刻。見えない日があるだけでは削除済みとは限らず、到達制限や一時障害もある。

cert / content

証明書やページ本文は補助証拠。証明書の発行やHTTPS成功だけで会社の承認や所有権を証明しない。

次は架空の外部観測、DNS、クラウド台帳を時刻で合わせた例です。実際の乗っ取り可否は事業者の所有確認・再割当て条件を調べる必要があります。

text
09:00 dns preview.corp.example CNAME
  old-project.vendor.example ttl=300
09:01 vendor_inventory name=old-project state=deleted
  deleted_at=2026-09-20 owner=campaign-team
09:02 asm dev.corp.example A=198.51.100.19
  tcp443=open title=Dev Console asset_id=none
09:03 asm shop.corp.example A=203.0.113.20
  tcp443=open owner=sales-team
10:15 browser preview.corp.example status=200
  page_title=Campaign Preview source=unknown

09:00〜09:01でpreviewの残存CNAMEと参照先削除は分かります。10:15の200は内容の提供者が誰かを示しません。旧サービスの復活、キャッシュ、事業者のエラーページ、第三者の再取得を切り分け、同時刻のDNS、事業者の登録監査、HTML内容、証明書、接続先を保存します。devの443は台帳外公開の証拠ですが、ただちに侵害された証拠ではありません。

5. 異常が成立する条件と証拠

状態・攻撃

成立条件、証拠、対策の位置

残存CNAME

DNSが削除済みの再利用可能なサービス名を指し、事業者が第三者へ割当てを許すと成立し得る。CNAMEが残るだけでは攻撃者が取得したとは言えない。

第三者の再登録

攻撃者が同じサービス名を取得し、所有確認の弱い条件でpreview.corp.exampleを結び付ける必要がある。事業者側の監査と実ページ内容を確認する。

正規ドメインの悪用

攻撃者の内容が当社サブドメインで配信されるとフィッシングやCookie受信のリスクがある。CookieのDomain属性とスコープ、送信状況を別に調査する。

シャドーITの露出

devの管理画面が認証弱化、未更新、テストデータを持つ場合に影響が増える。443が開いている事実だけではデータ漏えいを証明しない。

旧IPの再割当て

A/AAAAが解放したIPを指し続けると別契約者へ到達し得る。クラウドの割当記録と現接続先を確認する。

DNS変更権限の侵害

攻撃者が権威DNSを変更できる場合は残存CNAMEと別の経路。レジストラ・DNS管理の監査、MFA、承認を確認する。

TLS証明書がpreview.corp.exampleに有効であっても、会社が配信を承認した証拠にはなりません。事業者の検証手順や攻撃者が支配するサービスによっては証明書を取得できる場合があります。HttpOnly Cookieでも、広いDomain属性で当該サブドメイン宛てに送られるなら、サーバ側が受け取る点を確認します。

6. 調査で結論を強くする順序

判定段階

必要な証拠と結論の上限

存在を発見

権威DNS、外部リゾルバ、IPv4/IPv6、CT、クラウドAPIを組み合わせる。見つかった名前の全てが自社管理とは限らない。

所有者を確定

ゾーン管理者、請求・契約、リソースID、部署の申請記録と照合。ページのロゴだけでは所有権を判断しない。

再取得可能性を評価

事業者のカスタムドメイン検証と削除後の再割当て規則を調べる。単なるNXDOMAINや404は乗っ取り可否の証拠として足りない。

乗っ取りを確認

第三者の登録監査、内容変更時刻、接続先、証明書、HTTP応答を揃える。安全な検証では自社の権限ある資産に限定する。

被害を確認

アクセス、Cookie送信、フォーム入力、OAuth redirect_uri、メール等の設定を調査。ページ表示だけで認証情報窃取を断定しない。

復旧を確認

権威DNSから旧参照を消し、TTL後の複数地点で不達または正規先への到達を確認し、危険な認証・Cookie設定も点検する。

DNSのCNAMEは『別名をどの名前へ向けるか』を示すだけです。CNAME先のクラウドリソースが既にないか、同名の新規登録が可能か、カスタムドメインの所有検証があるかはDNS標準から決まりません。調査票ではDNS事実、クラウド事実、第三者が操作できる範囲を三列に分けます。

外部観測でdev.corp.exampleを見つけた場合、管理画面が公開されていても即座に遮断すると業務部門の検証や連携が止まることがあります。まず責任者とデータの有無を特定し、緊急のアクセス制限・認証強化を行い、正式資産へ移管するか廃止するかを承認者と決めます。漏えいの調査はアクセス・操作・外向き通信を確認して別に行います。

残存名の影響はWebページの表示だけではありません。認証Cookieが親ドメイン全体へ送られるか、アプリがOAuthの戻り先として許可しているか、CORSで当該オリジンを信頼しているか、メールやリンクで使われていないかを確認します。『古いサイトだから重要でない』という判断は、他システムからの信頼関係を見落とします。

7. 変更・障害・例外運用

運用場面

崩れやすい条件と確認

新規公開

申請時にFQDN、IP、クラウド契約、責任者、データ分類、期限、監視を登録し、外部観測で実際の公開を確認する。

サービス移設

旧・新のDNSと証明書、TTL、CDN、IPv6、リダイレクトを同時に管理。旧先を消す前に参照を撤去する。

サービス廃止

利用者・外部連携の停止を確認し、DNSレコード、クラウド資源、証明書、認証設定の参照を順に片付ける。

担当者退職

個人アカウントだけで管理する資産を避け、組織の契約・権限へ移管する。請求が続く資産とDNSを棚卸しする。

外部観測の誤検出

CDN共有IPや古いCT記録、キャッシュ、WAFの応答を所有者確定の証拠にしない。権威情報と実設定を確認する。

ASMを定期スキャンの一覧表だけにしないことが重要です。新規発見→責任者照合→優先評価→是正→再観測までの担当と期限を設定します。観測できない管理専用経路や内部資産は別の台帳・発見手段で管理します。

8. 封じ込めと復旧条件

残存CNAMEの調査と復旧DNS変更と被害調査を並行して行う。1証拠保全2参照停止3影響調査4復旧確認
残存CNAMEの調査と復旧
  1. 1. 証拠保全：対応 DNSと応答を保存／確認する証跡 時刻と接続先
  2. 2. 参照停止：対応 旧CNAMEを撤去／確認する証跡 権威DNSの変更
  3. 3. 影響調査：対応 信頼設定を確認／確認する証跡 Cookieと認証ログ
  4. 4. 復旧確認：対応 複数地点で再照会／確認する証跡 TTL後の結果

DNS変更と被害調査を並行して行う。

DNSの撤去で新規の名前解決は止められますが、TTL内のキャッシュや既に収集された認証情報には別の対応が必要です。図の影響調査はDNS変更と並行して進めます。

  1. previewの権威DNS応答、各地点の応答、参照先事業者のリソース監査、HTML・証明書を時刻付きで保全する。第三者のサービスへ侵入して確認しない。

  2. 残存CNAMEを削除するか管理済みの正規先へ切り替える。必要なら事業者へ不正登録の停止を依頼する。

  3. CookieのDomain属性、OAuth戻り先、CORS許可、外部リンク、認証情報入力の痕跡を調べ、危険な信頼関係と資格情報を修正する。

  4. devは責任者、データ、認証、更新状況を特定し、不要なら段階的に閉鎖、必要なら正式資産として管理へ移す。

  5. TTLを越えた後に権威DNSと複数地点から再照会し、IPv4/IPv6・HTTPS・外部監視で旧先へ届かないことを確認する。廃止手順と台帳更新を完了する。

乗っ取りが確認された場合、DNSだけ直してもフィッシングで入力された資格情報や長寿命トークンは残ります。対象者への通知、資格情報失効、セッション調査を業務影響と合わせて判断します。

9. 科目B（午後）の解答手順

構成図では『DNS名→レコード→参照先サービス→そのサービスを誰が登録できるか』を順に追います。設問が台帳漏れを問うなら発見と所有者の確認、乗っ取りを問うなら再割当て条件、復旧を問うならDNS撤去と既存の認証影響まで答えます。

  • DNS残存と第三者取得を区別する。

  • A/AAAAとCNAMEの参照先を分ける。

  • 外部観測と内部の管理台帳を照合する。

  • DNS修正後のキャッシュと信頼設定を確認する。

10. 短答演習

演習1：残存CNAME

条件：previewが削除済みのold-projectを指す。

質問：直ちに乗っ取り確定か。

解答：確定しない。事業者の再割当てとドメイン検証を確認する。

誤答の理由：残存レコードだけで第三者の取得を断定している。

演習2：台帳外dev

条件：devの443が応答し台帳にない。

質問：何を最初に確認するか。

解答：契約・部署の責任者、公開目的、扱うデータ、認証を確認する。

誤答の理由：所有者不明のまま安全・危険を決めている。

演習3：HTTPS成功

条件：previewへHTTPS接続でき証明書が有効。

質問：正規運用と断定できるか。

解答：できない。参照先の契約主体と承認記録が必要。

誤答の理由：TLS証明書を社内の承認証明にしている。

演習4：404

条件：CNAME先が404を返す。

質問：安全と断定できるか。

解答：できない。事業者のエラーページや再取得可能性を調べる。

誤答の理由：現時点の応答を将来の割当規則と混同している。

演習5：DNS削除

条件：previewのCNAMEを削除した。

質問：復旧完了か。

解答：TTL後の再照会とCookie・OAuth等の信頼設定、既存被害を確認する。

誤答の理由：DNS更新だけで既に起きた認証影響まで消えたと考える。

演習6：外部スキャン

条件：外部からdevが一時見えなくなった。

質問：廃止済みか。

解答：不明。権威DNS、クラウド資源、FWや一時障害を確認する。

誤答の理由：一地点の観測欠落を実体の削除とみなしている。

11. 一次資料

CISA：資産可視性と脆弱性検出

Microsoft：残存DNSとサブドメイン乗っ取り

RFC 1034：CNAMEの役割

CISA：ランサムウェア対策における資産管理

この記事についてAIに深掘り質問する

ChatGPT、Claude、Perplexityにこの記事を参照させ、要点の確認や疑問点を自由に質問できます。

次におすすめの学習

資格学習

SCの学習画面へ

編集・検証について

編集・検証：IT資格ラボ編集部

IPAが公開する試験要綱・シラバス・過去問題と、各技術の公式資料を優先して内容を確認しています。制度変更や誤りを確認した場合は、記事を見直して更新します。

編集方針・情報源・訂正方針を見る
この記事を共有する
すべての学習ガイド・記事一覧へ戻る