S3のアクセス制御と共有パターン

二層の許可モデル

S3 へのアクセスはざっくり 「誰が（プリンシパル）」「何に（リソース）」「どの操作を（アクション）」 で整理できます。

• IAM（ユーザーやロール、場合によっては ID 連携ユーザー） に付ける IAM ポリシー … AWS アカウント内の主体への許可。
• バケット（および必要に応じてオブジェクト） に付ける バケットポリシー … リソース側から見た許可。別アカウントのプリンシパルや、特定条件付きの公開もここで表現しやすいです。

実際のリクエストは 両方を満たし、かつ明示的な拒否がない など、IAM の評価ロジックに従います。試験では「バケットポリシーで許可しても IAM で拒否されている」といった組み合わせがよく出ます。

ACL

アクセスコントロールリスト（ACL） はバケット／オブジェクト単位の共有表現です。オブジェクト所有者がアップロード主体のアカウントになるケースなど、クロスアカウントでオブジェクト単位の読み取りを調整するときに登場します。一方で AWS は新規の利用について S3 をポリシーのみで管理する方向 を推奨しており、設計ではまず IAM／バケットポリシーで足りるかを検討するのが無難です。

アクセスポイント

S3 アクセスポイントは、同じバケットに対して 用途別のエンドポイント を切り出し、それぞれに 専用のポリシー を適用する仕組みです。分析用アプリケーション用、特定 VPC からのみ、といった 接続元や利用シナリオごとの最小権限 を分けやすくなります。

ブロックパブリックアクセス

意図しない公開を防ぐため、パブリックアクセスのブロック をアカウント／バケット単位で設定できます。静的ウェブサイトのように 意図的に読み取りを公開する 場合は、この設定とバケットポリシー／オブジェクト ACL の組み合わせを矛盾なく設計する必要があります。

事前署名付き URL

認証済みの主体（IAM など）が 一定時間だけ有効な URL を生成し、それをブラウザや外部システムに渡すと、受け取った相手はその間だけ GET や PUT など許可された操作ができます。ダウンロード販売、一時的なアップロード窓口、モバイルアプリへの配布 などで使われます。有効期限や許可アクションは生成時に決まります。

クロスアカウント共有の考え方

別アカウントからアクセスさせる典型的な方法は次のようなイメージです。

• バケット側ポリシーで相手アカウントのロールやユーザーを Principal に指定する。
• アップロード側にバケット所有者への bucket-owner-full-control 付与 など、オブジェクトの所有権・読み取りを揃えるための設定を組み合わせる（要件による）。
• 長期的な連携では AssumeRole でクロスアカウントロールを渡す。

試験では「バケットは B アカウントだがオブジェクト所有者は A のまま」「B が一覧や削除ができない」といった 所有者とポリシーのズレ がテーマになることがあります。

オブジェクト所有権（Bucket owner enforced）

Object Ownership を Bucket owner enforced にすると、ACL が無効化され、バケット所有者がオブジェクトを一元的に管理しやすくなります。クロスアカウントアップロードで「オブジェクト ACL に bucket-owner-full-control がないと所有者がずれる」問題を防ぐ文脈とセットで出ます。

CloudFront との関係（OAC）

S3 をオリジンにする CloudFront では、OAI（Origin Access Identity） から OAC（Origin Access Control） への移行が資料で説明されることがあります。バケットポリシーで CloudFront からのみ GetObject を許可し、直接 S3 URL では読めない構成が試験に出ます（詳細は CloudFront のトピックと公式ドキュメントへ）。

公式ドキュメント（深掘り）

• Identity and access management in Amazon S3
• Prerequisites for disabling ACLs