セキュリティ対策
クラウドストレージの公開設定ミス — 「ブロック有効」は穴が無いことを意味しない
オブジェクトストレージからの情報漏えいは、侵入ではなく設定で起きます。Amazon S3 のパブリックアクセスブロックは4つの独立した設定からなり、公式ドキュメントは『ブロックは既存のポリシーやACLを書き換えない』と明記しています。つまりブロックは穴を塞ぐのではなく覆っているだけ。外した瞬間に公開が復活する構造と、アカウント単位で効かせる理由、そして自分のバケットを確認する手順を解説します。
オブジェクトストレージからの情報漏えいは、たいてい侵入されて起きるのではありません。誰も破っていない、鍵も盗まれていない、ログにも不審な痕跡がない——設定がそうなっていただけです。
なぜ「侵入されていないのに漏れる」のか
侵入型
脆弱性や認証情報 → 侵入 → 持ち出し
パッチ・認証・監視のどこかで止まる余地がある
設定型（バケット公開）
URLを知っている（または推測できる） → そのまま取得
認証を通っていないのではなく、認証が要らない状態になっている
設定型が厄介なのは、アクセスが「不正」に見えないことです。攻撃者は正規の公開エンドポイントに正規のGETを送っているだけなので、侵入検知にもログの異常にも現れにくい。公開ディレクトリに置いてはいけないもの と同じ構図が、サーバーの外——ストレージ側で起きています。
4つの設定は「4つとも別のもの」
Amazon S3 のブロックパブリックアクセスは独立した4つの設定で、任意の組み合わせで適用できます。名前が似ているので1つにまとめて考えられがちですが、止める対象が違います。
- BlockPublicAcls
- 公開ACLを新しく付けようとする操作を失敗させる（
PutBucketAcl／PutObjectAcl／公開ACL付きのPutObject）。既存のポリシーやACLは変更しないので、いま付いている公開ACLはそのまま残る - IgnorePublicAcls
- バケットと配下オブジェクトの公開ACLをすべて無視する。公開ACL付きの
PutObject自体は通す（BlockPublicAcls との違いはここ）。既存ACLは消えず、新しい公開ACLが付くことも防がない - BlockPublicPolicy
- 公開を許すバケットポリシーの設定を拒否する（
PutBucketPolicy等）。既存のポリシーには影響しない - RestrictPublicBuckets
- 公開ポリシーを持つバケットへのアクセスを、AWSのサービスプリンシパルと所有アカウント内の認可済み利用者だけに制限する。サービスプリンシパル以外のクロスアカウントアクセスを遮断する（特定アカウントへの非公開な委譲も含めて）
4つに共通する、最も見落とされる性質
上の4項目すべてに「既存のポリシーやACLは変更しない」と書かれていることに注目してください。公式ドキュメントはこれを明示的にまとめています——「ブロックパブリックアクセスの設定は既存のポリシーやACLを変更しない。したがって、ブロック設定を外すと、公開ポリシーやACLを持つバケットやオブジェクトは再び公開される」。
つまりブロックを掛けた時点では、危険は消えていません。覆いを被せただけで、下にある穴はそのままです。誰かが調査のために一時的に外す、別アカウントへ複製する、Terraform の差分で戻る——そのどれでも公開は復活します。「ブロックが有効か」ではなく「ブロックを外しても公開されないか」を状態の定義にしてください。
「公開」の定義は、直感より広い
自分では公開していないつもりでも、S3の判定では公開になることがあります。
公開と判定されるもの
・ACLが AllUsers または AuthenticatedUsers に権限を与えている——後者は「AWSアカウントを持つ全員」であって自社の人ではありません
・バケットポリシーが、ワイルドカードやポリシー変数を含む値で主体を指定している
・aws:SourceIp の範囲が広すぎる（IPv4で /8 より広い、IPv6で /32 より広い。プライベート範囲は除く）
S3はまず「公開」と仮定してから、非公開と言えるかを判定します。曖昧なら公開側に倒れます。
非公開と判定されるもの
プリンシパル／CIDR／aws:SourceArn／aws:SourceVpc／aws:SourceVpce／aws:SourceOwner／aws:SourceAccount などを、ワイルドカードを含まない固定値で限定しているポリシー。
公式の例では、aws:SourceVpc を vpc-* にすると公開、vpc-91237329 のような固定値にすると非公開になります。「絞ったつもり」と「固定値で絞った」の差がそのまま判定を分けます。
掛ける場所を間違えない — アカウント単位が正解
公式ドキュメントは BlockPublicPolicy について、アカウント単位で適用することを推奨しています。理由が本質的です——バケットポリシーは、そのバケットのブロック設定を変更する権限をユーザーに与えうるからです。
バケット単位だけ
バケットポリシーを変更できる人 → ブロック設定を無効化するポリシーを差し込める → 公開できてしまう
アカウント単位
バケットポリシーを書き換えても、S3が公開ポリシーをブロックする
なお、アクセスポイント／バケット／アカウントで設定が食い違う場合、S3は最も制限の強い組み合わせを適用します。厳しい側に倒れるので、上位で締めておけば下位で緩められません。これは最小権限の考え方をストレージに適用したものです。
確認と是正の順番
まず「何が公開になっているか」を見る（消す前に）
いきなりブロックを掛けると、公開が止まった代わりに、何が公開されていたのかが分からなくなります。BlockPublicAcls の説明にあるとおり、この設定は「公開を防ぎつつ、既存のポリシーやACLを監査・調整できるようにする」ためのものです。AWSには IAM Access Analyzer for S3 があり、公開または共有されているバケットを、その根拠（どのACL／ポリシーが原因か）とともに一覧できます。まずここで棚卸しをしてください。
アカウント単位で4設定すべてを有効にする
公式は「アカウントのブロックパブリックアクセス4設定をすべて有効にすること」を推奨しています（各バケットでも4つとも有効にすることが Security Hub のベストプラクティス管理項目 S3.8 に対応）。ただし適用前に、公開を必要とする用途がないか確認してください。静的サイトのホスティングのように公開が要件の場合は、個別に調整します。
覆いの下の穴を実際に消す（ここが本番）
ブロックは既存の公開ポリシー・公開ACLを消しません。手順1で洗い出した公開ACLとポリシー文を、実際に削除・修正します。 ここまでやって初めて「ブロックを外しても公開されない」状態になります。多くの現場が手順2で終わってしまう——それがこの記事の要点です。
公開が要件のバケットは「置くもの」で守る
どうしても公開が必要なバケットは、公開されても困らないものだけを置く単位に分けます。同じバケットにバックアップやダンプ、顧客名簿を同居させない。何を置くかで爆発半径が決まります——サーバー側での同じ考え方は レンタルサーバーで .env を公開しないための配置と設定 にまとめています。
ファイル名に頼らない
「URLを知らなければ取れない」は防御ではありません（推測可能な識別子と同じ問題です）。推測されにくい名前は保険であって、アクセス制御の代わりにはなりません。 一時的な共有が必要なら、期限付きの署名URLのように時間で切れる仕組みを使い、公開設定そのものは閉じたままにします。
当サイトの視点：設定の事故は「監査できる形」にして初めて減る
バケットの公開事故が繰り返される理由は、担当者の不注意ではなく状態が見えないことにあります。ファイルの権限やサーバーの設定と違い、ストレージの公開状態はポリシー・ACL・アカウント設定・アクセスポイントの4層の合成結果で、どこか1つを見ても分かりません。当サイトの立場は、こういう領域では人間の注意力ではなく、合成結果を機械に評価させること——ブロック設定を上位（アカウント）で締めて下位で緩められなくし、公開判定を出す仕組みで定期的に棚卸しする。「気をつける」を対策と呼ばないのは、依存パッケージでもストレージでも同じです（osv-scannerの導入と使い方）。
出典（一次情報）
- Amazon Web Services「Blocking public access to your Amazon S3 storage」（Amazon S3 ユーザーガイド） — docs.aws.amazon.com（本記事の4設定の挙動、「ブロックは既存のポリシー・ACLを変更しない」、「公開」の判定基準、アカウント単位推奨の理由は、いずれもこの文書の記述にもとづきます）
次に読む
- 配置：公開ディレクトリに置いてはいけないもの / レンタルサーバーで .env を公開しないための配置と設定
- 鍵の扱い：.envとAPIキーの基礎 / SSH鍵と最小権限
- 棚卸し：資産棚卸しチェックリスト
- 同じ「設定で漏れる」型：サブドメイン乗っ取り（dangling DNS）
よくある質問
Qパブリックアクセスブロックを有効にすれば、もう安全ですか？
「今は外から見えない」状態にはなりますが、危険が消えたわけではありません。AWSの公式ドキュメントは「ブロックパブリックアクセスの設定は既存のポリシーやACLを変更しない。したがってブロック設定を外すと、公開ポリシーやACLを持つバケットやオブジェクトは再び公開される」と明記しています。ブロックは穴を塞ぐのではなく覆っているだけです。目指すべきは「ブロックが有効」ではなく「ブロックを外しても公開されない」状態——つまり公開ポリシーとACL自体を消しておくことです。
Q設定はバケット単位とアカウント単位のどちらに掛けるべきですか？
アカウント単位です。公式ドキュメントは BlockPublicPolicy について「バケットポリシーは、そのバケットのブロック設定を変更する権限をユーザーに与えうる。したがってバケットポリシーを変更できるユーザーは、ブロック設定を無効化するポリシーを差し込める。アカウント全体で有効にしていれば、ユーザーがバケットポリシーを変えてもS3は公開ポリシーをブロックする」と説明しています。バケット単位の設定は、バケットポリシーを触れる人が外せてしまいます。
Q「公開」とは具体的にどういう状態ですか？
直感より広い定義です。ACLでは AllUsers または AuthenticatedUsers という定義済みグループに権限を与えていれば公開扱いになります（AuthenticatedUsers は『AWSアカウントを持つ全員』であって自社の人だけではありません）。バケットポリシーでは、S3はまず公開と仮定してから非公開かを判定します。ワイルドカードやポリシー変数を含まない固定値で主体やIP範囲などを限定して初めて非公開になります。さらに aws:SourceIp で範囲が広すぎる場合（IPv4で /8 より広いなど）も公開と評価されます。
Q新しく作ったバケットは既定で安全ですか？
公式ドキュメントは「既定では、新しいバケット・アクセスポイント・オブジェクトは公開アクセスを許可しない。ただし利用者はバケットポリシー、アクセスポイントポリシー、オブジェクトの権限を変更して公開アクセスを許可できる」としています。つまり既定は安全側ですが、事故の大半は『既定を誰かが意図的に、あるいは一時的な作業のために外した』ところで起きます。既定に頼るのではなく、外せない仕組み（アカウント単位のブロック）と、外れていないかを見る仕組みの両方が要ります。