S3 のアクセス制御：バケットポリシーと ACL

S3には、複数のアクセス制御機構があります。IAMポリシー（アイデンティティベースで、プリンシパルが実行できる操作を制御）、バケットポリシー（バケットに設定するリソースベースのJSONポリシー）、アクセスコントロールリスト（ACL）（オブジェクトまたはバケット単位で許可を付与するレガシー機能）、そしてS3 Block Public Access（他のポリシーに関係なくパブリックアクセスをブロックする、アカウントまたはバケットレベルの上書き設定）です。現在のほとんどのユースケースでは、ACLはレガシーと見なされており、バケットポリシーとBlock Public Accessの併用が推奨されます。

バケットポリシーは、S3 バケットに直接アタッチする JSON ドキュメントです。どのプリンシパル（IAM ユーザー、ロール、AWS アカウント、サービス、または一般公開ユーザー）が、どのリソース（バケットおよび特定のキープレフィックス）に対して、どのアクションを実行できるかを指定します。バケットポリシーでは IAM ロールを必要とせずにクロスアカウントアクセスをサポートできます。たとえば、別の AWS アカウントの IAM ロールに対して、バケットポリシー内で直接、特定のオブジェクトへの読み取りアクセスを付与できます。各バケットには 1 つのポリシーを設定でき、最大サイズは 20 KB です。

静的ウェブサイトのアセットや公開データセットなどのパブリックコンテンツを提供するには、バケットポリシーを使用してオブジェクトを一般公開で読み取り可能にできます。まずバケットレベルでBlock Public Access を無効化し、次に Principal: '*' と Action: s3:GetObject を含むバケットポリシーステートメントを追加します。Block Public Access 設定の無効化とバケットポリシーでの Allow は両方とも必要です。どちらか一方だけを有効にしても機能しません。意図的にすべてのオブジェクトを公開したい場合を除き、Resource はバケット全体ではなく特定のプレフィックスに限定してください。

S3 Block Public Accessは、バケットポリシーと ACL を上書きする 4 つの設定を備えた安全策です。BlockPublicAcls（パブリック ACL を設定するリクエストを拒否）、IgnorePublicAcls（既存のパブリック ACL を無視）、BlockPublicPolicy（パブリックアクセスを付与するバケットポリシーを拒否）、RestrictPublicBuckets（パブリックポリシーに基づいてアクセスを制限）があります。4 つの設定はすべてデフォルトで有効です。アカウントレベルでも Block Public Access を有効にでき、個々のバケット設定にかかわらずすべてのバケットでパブリックアクセスをブロックします。これは意図しない一般公開を防ぐのに最適です。

S3 ACLは、IAM より前から存在する、元来のアクセス制御メカニズムです。ACL は、AWS アカウントまたは定義済みグループ（すべてのユーザー、認証済み AWS ユーザー、ログ配信）に、定義済みのアクセス許可（READ、WRITE、FULL_CONTROL）を付与します。ACL はバケットレベルまたは個々のオブジェクトレベルで適用できます。現在 AWS は、ACL を無効化し（S3 の「Bucket Owner Enforced」設定により、バケット所有者がすべてのオブジェクトを所有し、ACL は無効になります）、代わりにバケットポリシーと IAM を使用することを推奨しています。ACL はレガシー概念として、現在も SAA-C03 試験で出題されます。

CloudFront 経由で S3 コンテンツを配信する場合、バケットはプライベートに保ちつつ、CloudFront からはオブジェクトを取得できるようにする必要があります。Origin Access Control（OAC）を使用してください。これは Origin Access Identity（OAI）の最新の後継機能です。OAC は CloudFront アイデンティティを作成し、バケットポリシーでそのアイデンティティに s3:GetObject 権限を付与します。このとき Block Public Access は有効のままにします。これにより、ユーザーは CloudFront（キャッシュ、WAF、HTTPS のため）を経由する必要があり、バケットへ直接アクセスできなくなります。これは SAA-C03 試験でよく扱われる、安全なアーキテクチャパターンです。

別の AWS アカウントに S3 バケットへのアクセスを付与する方法は 2 つあります。方法 1 — バケットポリシー: 外部アカウントの ARN を Principal とし、必要な S3 アクションを指定したステートメントを追加します。外部アカウントの IAM ユーザーやロールには、S3 を呼び出すための IAM 権限も必要であり、さらにバケットポリシーによる Allow も必要です。方法 2 — 信頼ポリシーを持つ IAM ロール: 自身のアカウントに、外部アカウントを信頼するロールを作成します。外部アカウントのアイデンティティはそのロールを引き受け、バケットに対する権限を取得します。読み取り専用のシナリオではバケットポリシーのほうが簡単であり、運用上のアクセスにはロールが適しています。

Cross-Origin Resource Sharing（CORS）を使用すると、あるドメインでホストされているウェブアプリケーションが、別のドメインにある S3 バケットへ JavaScript の fetch リクエストを実行できます。CORS 設定がない場合、ブラウザはセキュリティ上の理由からこれらのリクエストをブロックします。バケットには、許可するオリジン、HTTP メソッド、ヘッダーを指定した CORS 設定を追加します。CORS は、example.com でホストされた React SPA が S3 バケット URL から画像やファイルを直接取得する場合によく必要になります。

事前署名 URLは、バケットやオブジェクトの権限を変更せずに、プライベートな S3 オブジェクトへの期限付きアクセス（GET または PUT）を付与します。この URL には認証情報と有効期限が埋め込まれており、URL を持つ人は有効期限までオブジェクトにアクセスできます。事前署名 URL は、アプリ内の認証済みユーザーにプライベートファイルをダウンロードさせる、クライアントがバックエンドを経由せず S3 へ直接アップロードできるようにする、レポートを一時的に共有するといった用途で使用します。有効期限は 1 秒から 7 日間まで設定できます（STS 一時認証情報を使用する場合、最大 12 時間です）。

バケットポリシー条件を使用して、コンテキストに基づくセキュリティを追加します。一般的なパターンは次のとおりです。aws:SourceIp はアクセスを特定の IP 範囲（例: VPC エンドポイントや社内ネットワーク）に制限します。aws:SecureTransport: true は HTTP 経由のリクエストを拒否して HTTPS を強制します。これは機密データを保存するすべてのバケットにおけるベストプラクティスです。s3:x-amz-server-side-encryption は、サーバー側暗号化を使用してオブジェクトをアップロードすることを必須にします。aws:PrincipalOrgID は、自身の AWS Organization 内のプリンシパルにアクセスを制限し、外部アカウントへのデータ持ち出しを防止します。

デフォルトでは、プライベートサブネット内の EC2 インスタンスは、インターネット経由（NAT ゲートウェイ経由）で S3 にアクセスします。このため NAT コストが発生し、トラフィックがパブリックインターネットに公開されます。S3 Gateway Endpointsは、NAT ゲートウェイを使用せず、追加料金なしで VPC 内から S3 へのプライベート接続を提供します。Gateway Endpoint をルートテーブルに追加すると、S3 宛てのトラフィックは自動的に AWS のプライベートネットワーク経由でルーティングされます。また、aws:SourceVpce を使用するバケットポリシー条件を追加して、エンドポイント経由のリクエストのみにアクセスを制限することもできます。

このレッスンで学んだ AWS Solutions Architect（SAA-C03）の概念について理解度を確認しましょう。

このレッスンでは、バケットポリシーは S3 へのクロスアカウントアクセスおよびサービスアクセスを制御するリソースベースの JSON ドキュメントであること、S3 Block Public Access は意図しない一般公開を防ぐ安全な上書き機能であること、そして事前署名 URL、VPC エンドポイント、CORS 設定はそれぞれ特定のアクセスパターンに安全に対応することを学びました。次は、S3 バージョニング、MFA Delete、レプリケーションについて学びます。