先に要点
- S3 公開バケットによる機密情報漏洩 は、世界中で繰り返し発生している AWS の代表的事故。配信したいから Public にする 発想を捨て、CloudFront + OAC で配信、S3 はプライベートのまま を標準にする。
- OAC(Origin Access Control) は 2022 年に登場した新方式で、旧 OAI(Origin Access Identity) の事実上の後継。「SSE-KMS で暗号化した S3 オブジェクトを CloudFront から読める」 「すべての AWS リージョン対応」 など、OAI ではできなかったケースをカバー。新規は OAC 一択。
- 移行手順は ① CloudFront のオリジンに OAC を作成 → ② S3 バケットポリシーを CloudFront ARN 許可へ書き換え → ③ Block Public Access が ON のままを確認 → ④ 旧 OAI を解除 の4ステップ。本番では 段階的に切り替える のが安全。
- 「 設定変更ミスで公開状態にしてしまった」 を防ぐため、AWS Config / GuardDuty / Macie / S3 Storage Lens のような検知の仕組みを必ず併用する。「人間が見張る」 ではなく 設定が逸脱したら通知される 状態を作る。
- 「 どうしても直接公開が必要」 な極めて限定されたケース(オープンデータ公開、検証用など)では、バケット名を推測されにくくする」 「アクセスログを必ず取る」 `Block Public Access の 「BucketPublicReadAccess」 だけ部分解除する など、最小範囲の例外運用にとどめる。
「S3 をパブリック公開にしたら、機密ファイルが世界中で見られていた」 ── これは AWS 利用企業で繰り返し発生してきた事故で、「Capital One、Verizon、Booz Allen Hamilton」 などの大手も過去にやっています。
「S3 を公開にしたら漏れた」 と聞くと、「そんなミスをするのは特別なケース」 と感じるかもしれません。しかし、動作確認のため一時的に Public にして戻し忘れた」 他人が書いたバケットポリシーで 「Principal: "*"」 が混ざっていた」 古い記事のコピペで OAI 設定をした結果、ブロックパブリックアクセスを外した など、設計を間違えれば誰でも踏む 構造的な事故です。
この記事では、「なぜ事故が起きるのか」 を整理しつつ、現代の標準である CloudFront + OAC 構成 への移行手順と、再発防止に効く監視設計を実務目線で解説します。
なぜ S3 公開バケット事故は繰り返されるのか
S3 公開事故の構造的な原因を3つに分けます。
① 公開と非公開の境界が分かりにくい
S3 のアクセス制御は バケットポリシー / ACL / Block Public Access / IAM ポリシー の 4層 が絡む。「どれか1つでも公開になっていれば公開」 で、設定が複数交差した結果、意図せず公開状態になる パターンが多い。
② 古い情報・古いベストプラクティスが残っている
「 S3 で静的サイト配信するには Public にする」 という古い記事が、検索しても上位に残り続けている。「今は OAC で安全に配信できる」 という知識が共有されておらず、新人ほど古い手順に従ってしまう。
③ 一度公開すると即時にスキャンされる
「 公開された途端、世界中のスキャナがバケット名を総当たり」。「数時間 Public にしただけで全部ダウンロードされた」 事例も実在。「 戻し忘れ」 が即座に被害に直結する設計。
安全な構成 — CloudFront + OAC が現代の標準
「S3 のコンテンツを世界に届けたい」 という要件への現代の答えは S3 はプライベートのまま、CloudFront + OAC を経由する です。
CloudFront + OAC の標準形を組むだけで、「誤公開事故」 を 設計レベルで排除 できます。
OAC とは — 旧 OAI との違い
「 OAC」 と 「OAI」 はどちらも 「CloudFront 経由でだけ S3 を読める」 仕組みですが、現在は OAC が標準で、OAI は 既存運用のためにだけ残されている過去技術 です。
| 項目 | OAC (現行) | OAI (旧方式) |
|---|---|---|
| 登場時期 | 2022年8月 | 2009年頃から |
| SSE-KMS 対応 | ○ 対応 | × 非対応(Bucket Key 必須など制約) |
| 全リージョン対応 | ○ 全リージョン | △ 一部新リージョンで使えない |
| 署名方式 | SigV4(現代の AWS 標準) | SigV2 ベース |
| 新規利用 | ○ 推奨 | × 非推奨(「移行を計画する」 と AWS 公式が明言) |
| S3 バケットポリシーの形 | 「 Principal: cloudfront.amazonaws.com」 + Condition で CloudFront ARN | 「 Principal: CloudFront OAI の Canonical ID」 |
新規プロジェクトはすべて OAC で、既存の OAI 運用も 計画的に OAC へ移行 するのが推奨です。
OAI から OAC への移行手順
既に OAI で運用しているバケットを安全に OAC に切り替える手順を整理します。本番では 一気に切り替えず、検証 → 並行 → 切替 → クリーンアップ の段階を踏むのが安全です。
設計レベルで事故を防ぐ仕組み
「 人間が頑張って防ぐ」 では再発します。仕組みで防ぎましょう。
アカウントレベル Block Public Access
「 アカウント全体で公開バケットを禁止」 する設定。「どんなにポリシーで Public にしようとしてもアカウント側で拒否」 になる。この設定を ON にしておく だけで、誤公開のかなりの割合が物理的に不可能になる。
AWS Config + Conformance Pack
「 s3-bucket-public-read-prohibited」 「s3-bucket-public-write-prohibited」 「s3-bucket-server-side-encryption-enabled」 などのルールを 常時評価。「違反バケットが出たら即通知」 する仕組みを組む。
Amazon Macie で機密データ自動検出
「 PII / クレカ番号 / 認証情報」 などを S3 オブジェクトから自動検出。「気付かないうちに機密データが S3 に置かれた」 を発見できる。検出時に CloudWatch Events で通知 → Lambda で隔離まで自動化できる。
アクセスログとアラート
「 S3 サーバーアクセスログ」 と 「CloudTrail データイベント」 の両方を有効化。「 異常な外部 IP からの大量 GET」 をしきい値超えで通知する。事故が起きたとき、「いつ・誰が・何を読んだか」 を追えるのが復旧コストを下げる。
どうしても直接公開が必要な場合
「 完全にオープンデータとして配布したい」 「公開を前提とした検証バケット」 のように、「Public 配信が要件」 のケースもゼロではありません。その場合の最小範囲の例外運用を整理します。
バケットは公開専用で物理分離
「 公開バケット」 と 「内部バケット」 を 完全に別アカウント or 別バケット に分ける。「同じバケットの一部だけ公開」 を避ける。「公開バケットに機密が混ざる」 事故を構造的に防ぐ。
バケット名を推測されにくくする
「 company-public-data」 のような推測しやすい名前は避ける。「org-prefix-purpose-uuid」 のような 16桁以上のランダム文字列入りで、スキャナの当てずっぽうから守る。
必ずアクセスログを取る
「 想定外の地域から大量にアクセスされていないか」 「想定外のファイルが読まれていないか」 を 週次でレビューする運用 を入れる。「公開だから見られて当然」 で放置しない。
部分的な Block Public Access 設定
「 BlockPublicAcls」 「BlockPublicPolicy」 の 2項目だけ ON にして、「今のバケットポリシーで指定した公開だけは許す」 「今後の Public ACL 追加は禁止」 のような 部分解除を使う。完全解除は避ける。
S3 公開設定と OAC に関するよくある質問
Q. CloudFront + OAC に移行するのが面倒なんですが、本当に必要?
A. 必要です が、いきなり全バケットを移行する必要はありません。新規バケットは必ず OAC」 `既存は影響度の高いものから順に移行 でかまいません。「公開 = 事故リスク」 と捉え、「移行コスト < 想定される事故損失」 で判断します。事故 1 件で会社の信頼が傷つくのが S3 公開事故の特徴です。
Q. OAI のままでも動いているなら放置でいいですか?
A. 動くが推奨されない です。AWS 公式が 「新規は OAC を使え、既存は移行を計画せよ」 と明言しており、将来的に OAI が EOL になる可能性 があります。「SSE-KMS 暗号化と組み合わせたい」 「新リージョンを使いたい」 と分かった時点で OAC 移行は必須になります。
Q. アカウントレベル Block Public Access を ON にしても大丈夫?
A. 多くの組織で大丈夫です。ただし、「本当に公開で運用しているバケットが既にある場合」 はそれが落ちます。導入前に 既存の公開バケットを棚卸し → CloudFront + OAC へ移行 → アカウントレベル ON の順で進めるのが安全。「本番アカウントは ON、検証用は ON にしない」 のような分離もよく行われます。
Q. CloudFront 経由でも 「署名付き URL / Cookie」 で限定配信できる?
A. できます。「OAC で S3 を秘匿 + CloudFront 署名付き URL/Cookie で配信」 が 有料コンテンツ / 動画配信 / 社内資料の限定共有 の標準パターン。「期限付きで読める URL を発行」 「Cookie で複数ファイルへのアクセスを許可」 のいずれも可能。CloudFront 入門 で署名付き URL の概要を扱っています。
Q. 旧 OAI を消したら、別の CloudFront ディストリビューションで使っていたものまで壊れますか?
A. 使い回している場合は壊れます。OAI を消す前に どのディストリビューションで参照されているか を必ず棚卸しします。AWS マネジメントコンソールの OAI 一覧で 「関連するディストリビューション」 が確認できます。「使ってないことを確認してから削除」 が鉄則。
Q. KMS で暗号化した S3 オブジェクトを CloudFront 経由で配信したい場合は?
A. OAC が必須です。OAI は SSE-KMS で暗号化したオブジェクトを 読めません(回避策として 「Bucket Key を有効化 + SSE-S3 互換動作にする」 などはありますが煩雑)。OAC なら 「SSE-KMS のままで CloudFront が読める」 ので、暗号化要件が厳しい組織ほど OAC への移行価値が高い。
Q. Macie や Config は料金が高いと聞きました
A. 規模次第 です。Macie はスキャン対象のオブジェクト数で課金されるため、機密データが含まれるバケットだけスキャン対象にする で抑えられます。Config も 「必要なルールだけ評価」 で抑制可能。全部入れて高くなった → 全部切る ではなく、「本番アカウントだけ重要なルールを有効化」 から始めるのが現実的です。
まとめ
S3 公開バケット事故は、「 設計レベルで起こりうる仕組み」 のまま運用しているから繰り返される 問題です。「気をつけて使う」 ではなく、CloudFront + OAC + アカウントレベル Block Public Access + Config / Macie の組み合わせで そもそも公開しようとしても公開できない 状態を作ることが本質的な対策になります。
旧 OAI を使っている既存運用も、「SSE-KMS 対応」 「新リージョン対応」 のためにいずれ OAC に移行が必要です。段階的な手順 を踏めば本番影響を最小限に抑えられるので、「次の運用改善」 のタイミングで計画的に進めるのが安全です。