## この記事でわかること

- AWS S3 特有のテイクオーバーパターン
- バケット削除済 CNAME を検出する具体手順
- 是正の 3 ステップ
- CloudFront / Route 53 を使う際の注意

## AWS S3 のテイクオーバーが成立する条件

![S3 の dangling 状態](/blog/aws-s3-subdomain-takeover/state.svg)

### 危険な状態

```
static.example.co.jp  CNAME  static.example.co.jp.s3-website-ap-northeast-1.amazonaws.com
                              ↑ S3 バケット削除済 = 攻撃者が同名で作成可能
```

S3 では **バケット名がグローバルで一意**で、**削除されたバケット名は誰でも再作成可能**です。同じバケット名で再作成して Static Website Hosting を有効化すれば、御社のドメイン経由で攻撃者のコンテンツが配信されます。

### 攻撃成立のパターン

1. 御社が `static.example.co.jp` 名の S3 バケットで静的サイトを公開
2. CloudFront 移行や CDN 変更で S3 バケットを削除
3. しかし `static.example.co.jp` の CNAME はそのまま残置
4. 攻撃者が S3 で `static.example.co.jp` 名のバケットを新規作成
5. Static Website Hosting を有効化、悪意あるコンテンツを配置
6. 御社のドメインで攻撃者のコンテンツが配信される

## 自社で確認する手順

### 1. CNAME が S3 パターンに向いているか確認

```bash
dig +short CNAME static.example.co.jp
# → *.s3-website-*.amazonaws.com.
# → *.s3.amazonaws.com.
# → *.s3-*.amazonaws.com.
# のいずれかが返れば対象
```

### 2. バケットが存在するか確認

```bash
curl -sI https://static.example.co.jp/
```

以下のいずれかが返れば **dangling 確定**:
- `404 NoSuchBucket`
- `Code: NoSuchBucket` を含む XML

### 3. バケット名解放状況の確認

AWS CLI で同名バケットを試しに作成しようとして「BucketAlreadyExists」が返れば誰かが占有済（要確認）、「成功」なら占有可能 = 危険。

```bash
aws s3 mb s3://static.example.co.jp --region ap-northeast-1 --dryrun
```

## 是正の 3 ステップ

![S3 dangling の是正フロー](/blog/aws-s3-subdomain-takeover/remediation.svg)

### ステップ 1: 即座に DNS から CNAME を削除

最優先。

### ステップ 2: 自社でバケット名を占有

将来また使う可能性がある名前は、自社の AWS アカウントでバケットを作成して占有します。Static Website Hosting を有効化する必要はなく、空のプライベートバケットで OK。

```bash
aws s3 mb s3://static.example.co.jp --region ap-northeast-1
aws s3api put-public-access-block \
  --bucket static.example.co.jp \
  --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
```

### ステップ 3: CloudFront + Route 53 + OAC への移行（中長期）

将来的に S3 を直接 CNAME で公開する方式は**廃止**するのが安全です。代わりに:

- CloudFront を前段に置き、Origin Access Control（OAC）で S3 へのアクセスを CloudFront 経由のみに限定
- Route 53 で ALIAS レコードを CloudFront に向け、CNAME ではなく ALIAS に
- バケット名と DNS 名を一致させない設計にする

## CloudFront / Route 53 を使う際の注意

| 観点 | 注意点 |
|---|---|
| Route 53 ALIAS | ALIAS の宛先 CloudFront ディストリビューションが削除済の場合も dangling になる |
| CloudFront 削除 | ディストリビューション削除前に Route 53 ALIAS 削除をセット |
| 旧設定の残骸 | S3 直 CNAME の設定が残っていないか定期点検 |

## 検出を自動化する

ドメイン番人の [サブドメイン棚卸し 単発チェック](/subdomain/check) では `*.amazonaws.com` 系の dangling CNAME を自動検出します。

## まずは現状を把握しましょう

棚卸しと是正の支援は [サブドメイン棚卸し＋テイクオーバーリスク診断](/contact)（5 万円〜）でご相談ください。

関連記事:
- [サブドメインテイクオーバーとは？仕組みと EC・スタートアップ・制作会社への影響](/blog/subdomain-takeover-toha)
- [dangling CNAME のリスクと検出方法](/blog/dangling-cname-risk)
- [GitHub Pages のサブドメインテイクオーバー対策](/blog/github-pages-subdomain-takeover)
- [Heroku のサブドメインテイクオーバー対策](/blog/heroku-subdomain-takeover)

総合点検は [無料のドメイン診断](/diagnose)、SSL 単独は [SSL 単発チェック](/ssl/check) をご利用ください。