サブドメインのセキュリティリスク|漏洩を防ぐための対策
サブドメインの調べ方、セキュリティリスク、漏洩を防ぐための対策を解説。意図せず公開された開発環境や管理画面が攻撃の入り口になることも。
サブドメインは便利ですが、適切に管理しないとセキュリティリスクになります。この記事では、サブドメインの調べ方とセキュリティ対策を解説します。
サブドメインとは
サブドメインは、メインドメインの前に追加される文字列です。
blog.example.com ← blogがサブドメイン
shop.example.com ← shopがサブドメイン
dev.example.com ← devがサブドメイン
よくある用途
| サブドメイン | 用途 |
|---|---|
| www | Webサイト本体 |
| blog | ブログ |
| shop | ECサイト |
| api | API サーバー |
| dev, staging | 開発・テスト環境 |
| admin | 管理画面 |
| メールサーバー |
サブドメインのセキュリティリスク
1. 意図せず公開された環境
開発環境やステージング環境が外部からアクセス可能になっているケースは非常に多いです。
リスク:
- テストデータの漏洩
- 脆弱なコードへのアクセス
- 認証がない管理機能
2. 放置されたサブドメイン
使わなくなったサブドメインが削除されずに残っている状態は危険です。
リスク:
- サブドメインテイクオーバー攻撃
- 古いソフトウェアの脆弱性
- フィッシングサイトへの悪用
3. サブドメインテイクオーバー
DNSレコードが外部サービス(AWS、Heroku等)を指しているが、そのサービスでアカウントが削除された場合、第三者がそのサブドメインを乗っ取れる可能性があります。
staging.example.com CNAME xxx.herokuapp.com
↓
Herokuでxxx.herokuapp.comが未使用
↓
攻撃者がHerokuでxxx.herokuapp.comを取得
↓
staging.example.comを乗っ取り
サブドメインの調べ方
1. Certificate Transparency(証明書透明性)
SSL証明書の発行ログから、サブドメインを発見できます。
crt.sh を使用:
https://crt.sh/?q=%.example.com
2. DNSブルートフォース
一般的なサブドメイン名を総当たりで検索します。
# subfinderを使用
subfinder -d example.com
# amassを使用
amass enum -d example.com
3. Google検索
site:*.example.com -site:www.example.com
4. RiskLensで自動検出
RiskLensでドメインを診断すると、Certificate Transparencyログから公開されているサブドメインを自動で検出します。
サブドメインのセキュリティ対策
対策1: サブドメインの棚卸し
定期的にすべてのサブドメインを把握し、必要性を確認します。
| サブドメイン | 用途 | 担当者 | 必要性 | 対応 |
|---|---|---|---|---|
| dev.example.com | 開発環境 | 田中 | 必要 | アクセス制限 |
| old.example.com | 旧サイト | 不明 | 不要 | 削除 |
対策2: 不要なサブドメインの削除
使用していないサブドメインは、DNSレコードごと削除します。
# 削除前にレコードを確認
dig any old.example.com
# DNSレコードを削除
# (各DNSサービスの管理画面から)
対策3: アクセス制限
開発環境や管理画面には、以下の制限を設けます。
IP制限:
# Nginx設定例
location / {
allow 192.168.1.0/24;
allow 10.0.0.0/8;
deny all;
}
Basic認証:
location / {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
}
VPN必須: 開発環境へのアクセスはVPN経由のみに制限
対策4: サブドメインテイクオーバー対策
外部サービスを使う場合:
- サービス解約時はDNSレコードも削除
- CNAMEの向き先が有効か定期確認
検知方法:
# CNAMEの向き先が有効か確認
dig CNAME staging.example.com
# 向き先のサービスが応答するか確認
curl -I https://staging.example.com
対策5: ワイルドカード証明書の適切な管理
ワイルドカード証明書(*.example.com)を使用している場合、すべてのサブドメインで同じ証明書が使われます。
注意点:
- 証明書が漏洩すると全サブドメインに影響
- 証明書の管理を厳格に
対策6: 監視の自動化
RiskLensを使って、サブドメインの変化を自動監視できます。
- 新しいサブドメインの検出
- 放置されたサブドメインの警告
- SSL証明書の期限監視
開発環境を安全に公開する方法
テストや確認のために開発環境を一時的に公開する必要がある場合:
方法1: 一時的なURLを使用
# ngrokを使用
ngrok http 3000
# Cloudflare Tunnelを使用
cloudflared tunnel --url http://localhost:3000
方法2: 認証を必須にする
// Next.js Middleware例
export function middleware(request) {
const basicAuth = request.headers.get('authorization');
if (!basicAuth) {
return new Response('Authentication required', {
status: 401,
headers: { 'WWW-Authenticate': 'Basic realm="Staging"' },
});
}
// 認証チェック...
}
方法3: 時間制限付きアクセス
一定時間後に自動でアクセスを遮断する仕組みを導入。
チェックリスト
- すべてのサブドメインを把握している
- 不要なサブドメインを削除した
- 開発環境にアクセス制限を設けている
- CNAMEの向き先が有効か確認した
- ワイルドカード証明書を適切に管理している
- 定期的にサブドメインを監視している
まとめ
| リスク | 対策 |
|---|---|
| 意図せぬ公開 | アクセス制限 |
| 放置 | 定期棚卸しと削除 |
| テイクオーバー | DNS管理の徹底 |
サブドメインは「見えない攻撃対象」になりやすいです。RiskLensで定期的にサブドメインをスキャンし、リスクを把握しましょう。