セキュリティサブドメイン退職者Web 担当者
退職者が立てた検証環境サブドメインの棚卸し方法｜Web 担当者向け実践手順
ドメイン番人約 4 分で読めます
目次
この記事でわかること
- 退職者が残しがちな検証環境サブドメインのパターン
- 退職後でも追跡できる棚卸し手順
- 退職時に必須のドメインチェックリスト
- 過去の退職者ぶん全件遡及するアプローチ
退職者が残しがちなサブドメイン
検証 / 開発系
staging.example.co.jpstg.example.co.jpdev.example.co.jpdevelop.example.co.jptest.example.co.jpqa.example.co.jp
個別アプリ / 試運用系
app.example.co.jpapp2.example.co.jp<個人名>.example.co.jp（命名規則違反）<プロジェクト名>.example.co.jp（プロジェクト終了済）
SaaS 試用系
*.herokuapp.comへの CNAME（Heroku 検証）*.github.ioへの CNAME（GitHub Pages で社内資料）*.netlify.app*.vercel.appへの CNAME
退職後でも追跡できる棚卸し手順
ステップ 1: CT log で全列挙
curl -s 'https://crt.sh/?q=%25.example.co.jp&output=json' \
| jq -r '.[].name_value' | sort -u
ステップ 2: 命名パターンでフィルタ
退職者がよく使う命名パターンで絞り込み:
grep -E '^(staging|stg|dev|test|qa|app[0-9]*|sandbox|preview)\.' all-subdomains.txt
ステップ 3: DNS の作成日時 / TTL を確認
DNS プロバイダ（Cloudflare / Route 53）の管理画面で「作成日時」を確認し、過去の退職者の在職期間と照らし合わせます。
ステップ 4: 元担当者を特定
- 社内 Wiki / Confluence の作成者ログ
- Git リポジトリのコミット履歴
- Slack / Teams の過去発言検索
ステップ 5: 用途を確認できなければ「dangling 確定 → 削除」
「もしかしたら誰かが使ってるかも」で残すのが最悪の選択肢です。CT log + DNS で外部から見えている以上、攻撃者は確実に把握しています。疑わしきは削除が原則。
退職時に必須のドメインチェックリスト
退職者が出る前に必ず確認する項目:
1. DNS レコードの作成履歴
退職者が在職中に追加した DNS レコード（特に CNAME）を一覧化。
2. SaaS アカウントの所有
- 個人名アカウントで契約した SaaS（GitHub / Heroku / Vercel / Netlify / AWS）
- 会社用のメールでサインアップしているか
- 共有アカウントへの移行が必要か
3. ドメインレジストラのアカウント
独立系レジストラで個人名義になっているドメインがないか。
4. SSL 証明書の自動更新責任者
acme-client / certbot の cron が個人サーバーで回っていないか。
5. 社内ツールの管理者権限
個人アカウントが Cloudflare / AWS / GCP のオーナー権限を持っていないか。
6. 古い検証環境の整理
退職前 1 ヶ月で staging / dev / test 系の整理を依頼。
過去の退職者ぶん全件遡及するアプローチ
過去 5 年ぶんの退職者がいる場合、以下の順序で遡及します:
1. CT log + DNS の現状把握
ドメイン番人の サブドメイン棚卸し 単発チェック で 30 秒で全サブドメインを列挙。dangling CNAME を flag。
2. dangling と判定されたものから即削除
過去の退職者の作品である可能性が高いので、「疑わしきは削除」で OK。
3. 応答ありで用途不明のサブドメインを部門ヒアリング
現役社員にも「これ、覚えていますか？」と確認。誰も知らなければ削除。
4. 退職時チェックリストを今後の標準に
過去の整理が一段落したら、今後同じ問題を起こさない仕組みを構築。
まずは現状を把握しましょう
ドメイン番人の サブドメイン棚卸し 単発チェック で 30 秒で確認できます。
過去の退職者ぶん全件遡及など大規模な棚卸しは、サブドメイン棚卸し＋テイクオーバーリスク診断（5 万円〜）でご相談ください。
関連記事:
総合点検は 無料のドメイン診断、SSL 単独は SSL 単発チェック をご利用ください。