Amazon S3のアクセス制御・暗号化・データ保護

S3のデータ保護を構成する要素

Amazon S3のセキュリティは、アクセスを許可する相手と操作を決める認可、オブジェクトを読み取れる人を限定する暗号化、誤操作や規制に備えて変更・削除を防ぐデータ保護に分けて考えます。ブラウザーから利用する場合は、別オリジンからの通信を制御するCORSも関係します。

アクセス制御はポリシーで行い、暗号化はデータの保存・通信経路を保護し、バージョニングやObject Lockは履歴保持・改変防止を担います。これらは互いの代替ではありません。たとえば、バージョニングは暗号化を行わず、暗号化を有効にしても不適切なアクセス許可は防げません。

IAMポリシーとバケットポリシー

S3へのリクエストは、誰が（プリンシパル）、何を（リソース）、どの操作で（アクション）行うかを照合して認可されます。

• IAMポリシーはIAMユーザーやロールなど、主体に付与します。アプリケーションの実行ロールに必要なS3権限を与えるときに使います。
• バケットポリシーはバケットに付けるリソースベースポリシーです。別アカウントの主体や、送信元IP・VPCエンドポイントなどの条件を含む許可・拒否を記述できます。
• アクセスを許可する設定があっても、適用されるポリシーの明示的な拒否や組織の制御などがあれば、リクエストは拒否されます。必要な権限を複数のポリシー間で確認します。

ポリシーのActionとResourceは、対象APIがバケット操作かオブジェクト操作かに合わせます。たとえば、s3:ListBucketはバケットARN、s3:GetObjectはオブジェクトARNが対象です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/ReportReader" },
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::research-archive-482"
    },
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/ReportReader" },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::research-archive-482/reports/*"
    }
  ]
}

バケットARNはarn:aws:s3:::バケット名、オブジェクトARNはarn:aws:s3:::バケット名/キーです。ListBucketはオブジェクトキーではなくバケットに対する操作なので、バケット名/*を指定しても対象が一致しません。反対にGetObjectなどはオブジェクトに対する操作なので、オブジェクトARNを指定します。許可対象のプリンシパルには、実際に利用するAWSアカウントのIAMロールなどを指定してください。

送信元IPを限定する場合は、バケットポリシーの条件キー（たとえばaws:SourceIp）を使って条件を表現できます。条件設計を誤ると、AWSサービス経由のアクセスまで拒否することがあるため、許可したい経路と例外条件を確認します。

ACLとオブジェクト所有権

アクセスコントロールリスト（ACL）は、バケットまたはオブジェクトごとにAWSアカウントや定義済みグループへ権限を付ける古くからの仕組みです。ACLの権限にはREAD、WRITE、READ_ACP、WRITE_ACP、FULL_CONTROLがあり、IAMポリシーのような柔軟な条件式を記述するものではありません。

現在のS3では、一般的なユースケースの多くでACLは不要です。新しい汎用バケットではBucket owner enforcedがObject Ownershipの既定値で、ACLが無効になり、バケット所有者がオブジェクトを所有します。この構成ではアクセス許可をポリシーで管理します。ACLの設定や更新を伴うリクエストはAccessControlListNotSupportedエラーとなる場合があります（ACLの読み取りは可能です）。

特定オブジェクトごとにACLを使う必要がある既存システムなど、明確な要件がある場合は、Object Ownership設定でACLを有効にする選択肢があります。新規設計では、まずIAMポリシー、バケットポリシーやアクセスポイントポリシーで要件を表現できるか検討してください。

アクセスポイント

S3アクセスポイントは、バケットなどのデータソースに結び付く名前付きネットワークエンドポイントです。用途ごとに異なるポリシーやネットワーク制御を適用できるため、同じバケットのデータを複数のアプリケーションや利用者に安全に提供しやすくなります。

たとえば、社内の集計処理には読み取り専用アクセスポイントを用意し、別のデータ取込アプリケーションには特定のVPCからのみPUTできるアクセスポイントを用意できます。バケットに付与したポリシーとアクセスポイントのポリシーは連携して評価されます。アクセスポイントポリシーを設定しただけで、バケットポリシーなど他の認可制御を無視できるわけではありません。

アクセスポイントは主にオブジェクト操作に使うもので、バケットの作成・削除などすべてのS3操作を置き換えるものではありません。各アクセスポイントにはARNがあり、ポリシーやAPIリクエストでリソースを指定できます。

S3 Object Lambda

S3 Object Lambdaは、アクセスポイントを通るGET・LIST・HEADリクエストの応答にLambda関数を適用し、データや一覧、メタデータを返却時に加工する機能です。用途に応じて、機密情報を伏せる、画像を変換する、一覧に表示する項目を調整するといった処理を行い、用途ごとの派生コピーを保存せずに済む場合があります。

処理では、アプリケーションがObject Lambdaアクセスポイントへ要求を送り、関連付けられたLambda関数が標準のサポーティングアクセスポイント経由で元データへアクセスします。関数が加工した応答がアプリケーションに返されます。Object LambdaはすべてのS3 APIを任意に加工するものではなく、対象となるリクエスト種別やLambda関数の実装・権限を設計する必要があります。

提供状況に注意： 2025年11月7日以降、S3 Object Lambdaは、すでに利用中の顧客と一部のAWSパートナーネットワークパートナーに限定して提供されています。そのため、新規採用を前提に設計する前に、利用資格と現行のAWS案内を確認してください。既存利用環境の理解や試験範囲の用語としては、アクセスポイントとLambdaによる取得時加工という役割を押さえます。

署名付きURL

**署名付きURL（presigned URL）**は、S3へのアクセス権を持つIAM主体が作成し、オブジェクトへの操作を一定期間だけ第三者に委譲するURLです。URLを受け取った利用者は、自身のAWS認証情報を持たなくても、指定されたHTTPメソッドでアクセスできます。代表例はGETによるダウンロードとPUTによるアップロードです。

URLの発行者が必要なS3権限を持つことが前提で、URLには対象バケット・オブジェクト、操作、期限が署名されます。AWS Signature Version 4形式のクエリには、一般にX-Amz-Credential、X-Amz-Algorithm、X-Amz-Signature、X-Amz-Date、X-Amz-Expiresなどが含まれ、セッショントークンを含む場合もあります。署名付きURLは認証情報そのものではありませんが、所持者が使える bearer token と同様に慎重に扱います。

有効期限は発行時に指定できますが、URLの有効期間は署名に使った認証情報の有効期間を超えられません。一時認証情報で生成したURLは、URLに指定した期限より先にロールセッションなどが切れると、その時点で使用できなくなります。IAMユーザーの認証情報を使ったSignature Version 4の署名付きURLは最長7日間です。

URLが漏えいすれば、期限内に第三者が指定操作を実行できる可能性があります。また同じURLを期限内に複数回利用でき、PUTの場合は同じキーに既存オブジェクトがあれば置き換わり得ます。漏えいを前提に短い期限、限定されたキーと操作、必要に応じてバケットポリシーによる送信元制限などを組み合わせます。送信元IPなどの制限は、URLに独立したIP許可リストを書き込むのではなく、ポリシーの条件で要求を評価します。

CORS（Cross-Origin Resource Sharing）

CORSは、あるオリジンで読み込まれたブラウザーアプリケーションが、別のオリジンにあるリソースへアクセスするときのブラウザー側制約を調整する仕組みです。たとえば、フロントエンドをapp.example.netで配信し、画像を別のS3エンドポイントから取得する場合、S3バケットに許可するオリジンやHTTPメソッドを設定します。

CORS設定では、許可するオリジン（AllowedOrigins）、メソッド（AllowedMethods）、必要なリクエストヘッダー（AllowedHeaders）、ブラウザー側に公開する応答ヘッダー（ExposeHeaders）、プリフライト結果のキャッシュ時間などを定めます。ブラウザーは必要に応じてOPTIONSによるプリフライトを送り、S3から返るCORS応答を確認します。

CORSは認可ポリシーではありません。CORSでオリジンを許可しても、その利用者にS3の読み取り・書き込み権限が自動で付与されるわけではありません。IAMポリシー、バケットポリシー、ACL（有効な場合）などの権限評価は引き続き行われます。逆に、S3の権限が正しくても、ブラウザーが必要なCORS応答を得られなければ、ブラウザーアプリケーションからのクロスオリジン利用はブロックされます。

保存データの暗号化

S3の暗号化は、ネットワーク転送中の保護と、保存時の暗号化に分けて考えます。S3への通信にはTLS（HTTPS）を使用し、保存時はサーバー側暗号化（SSE）またはクライアント側暗号化を選びます。

サーバー側暗号化（SSE）

SSEではS3が受信したデータを保存時に暗号化し、許可された取得リクエストに応じて復号します。現在、S3は2023年1月5日以降、すべての新規オブジェクトをSSE-S3で自動的に暗号化します。追加料金や性能影響なく適用される基準の暗号化であり、古い説明のように暗号化ヘッダーを付けないと暗号化されないわけではありません。別の方式を必要とする場合は、PUT時に指定するか、バケットの既定暗号化を設定します。バケットの既定暗号化を変更しても、既存オブジェクトの暗号化方式は遡って変更されません。

方式	鍵の管理	選択する主な理由・注意点
SSE-S3	S3が鍵を管理	S3の標準的なサーバー側暗号化。利用者がKMSキーを管理する必要がない
SSE-KMS	AWS KMSのキー（AWS管理キーまたはカスタマー管理キー）	キー利用権限をIAM・キーポリシーと連携し、監査や鍵のライフサイクルを制御する。KMS権限・料金・リクエスト上限を考慮する
DSSE-KMS	KMSキーを用いた二重レイヤーのサーバー側暗号化	二重暗号化レイヤーが必要な要件向け。SSE-KMSと同様にKMS権限や料金を考慮する
SSE-C	顧客が用意・保持する鍵素材	S3は受け取った鍵を用いて暗号化・復号するが、鍵素材を永続保管しない。各要求で鍵情報を安全に提供する必要がある

SSE-KMSでは、AWS管理のaws/s3キーまたはカスタマー管理キーを使用できます。カスタマー管理キーではキーポリシーやIAM権限、無効化・ローテーションなどをより細かく管理できます。KMSキーは対象バケットと同じリージョンに必要です。アップロードには通常kms:GenerateDataKey、ダウンロードにはkms:Decryptなどの権限が関係し、マルチパートアップロードでは追加の権限要件にも注意します。SSE-KMSとDSSE-KMSではAWS KMSの利用料金が発生します。

SSE-Cはクライアント側で暗号化してから送信する方式ではありません。S3サーバー側が顧客提供鍵を使って暗号化・復号し、利用者は鍵の安全な保管やリクエストごとの提供を管理します。対して**クライアント側暗号化（CSE）**では、アプリケーションやSDKがS3へ送る前に暗号化します。S3には暗号文が渡され、S3はデータの暗号化・復号に関与しません。鍵の保護、復旧、ローテーションはクライアント側の責任です。

Object Lockとリーガルホールド

S3 Object Lockは、オブジェクトをWORM（Write Once, Read Many）モデルで保護し、オブジェクトの特定バージョンを削除や変更から守る機能です。バケットでS3 Versioningが有効である必要があります。ロックされているのは対象バージョンであり、同じキーに新しいバージョンが作られること自体や、削除マーカーの追加まで必ず防ぐわけではありません。

**保持期間（retention period）**は、バージョンを保護する期限を指定します。2つの保持モードがあります。

• ガバナンスモード（Governance）：通常の利用者による削除・保持設定の変更を防ぎます。特別なs3:BypassGovernanceRetention権限を持つ利用者は、バイパスを明示した要求で保護を回避できる場合があります。
• コンプライアンスモード（Compliance）：保持期間中は、ルートユーザーを含めて誰も保護中のバージョンを削除できず、保持期間を短縮・解除できません。規制要件など、より強い不変性が必要なケースで用います。

保持期間が経過した時点でロック状態は解除されますが、オブジェクトが自動削除されるわけではありません。削除を実行するには別途権限が必要です。ロック中に通常のDELETE（バージョンIDを指定しない削除）を行うと、新しい削除マーカーが現在のバージョンとして追加され得ます。一方、保護中のバージョンIDを指定して永久削除するリクエストは拒否されます。

**リーガルホールド（legal hold）**は、終了期限を持たず、明示的に解除するまで対象バージョンを保護します。保持期間とは独立しているため、保持期間が満了してもリーガルホールドが有効なら保護は続きます。リーガルホールドを解除しても保持期間が残っていれば保護されます。監査終了時期が決まっていないデータなどに適しています。

S3 Glacier Vault Lockとの違い

S3 Glacierストレージクラス（S3 Glacier Instant Retrieval、Flexible Retrieval、Deep Archive）は、S3バケット内のオブジェクトに適用するストレージクラスです。これらのオブジェクトを保護する機能はS3 Object Lockです。一方、Vault Lockは、独立したVaultベースのAmazon S3 GlacierサービスにおけるVault Lockポリシーの仕組みです。このVaultベースのサービスは新規顧客を受け付けておらず、既存利用者向けに提供されています。「S3 Glacier」という名前だけで両者を混同しないようにします。

バージョニングと削除マーカー

S3バージョニングはバケット単位で有効化し、同じオブジェクトキーの複数バージョンを保持します。バージョニングを有効にした後、同じキーにPUTすると、既存のオブジェクトを単純に置き換えるのではなく、新しいバージョンIDのオブジェクトが作られます。各バージョンは差分ではなく、独立したオブジェクトとして保存されるため、保存容量や料金もバージョンごとに考慮します。

バージョニング有効時にバージョンIDを指定せずDELETEすると、データの全バージョンが消えるのではなく、削除マーカーが追加されます。削除マーカーが最新バージョンになることで、通常のキー参照ではオブジェクトが削除されたように見えます。削除マーカーを削除すると、その前にあったバージョンが再び最新として表示されます。

オブジェクトを完全に削除するには、対象のバージョンIDを指定してそのバージョンを削除します。誤操作でバージョニング自体を止めないよう、バケットの状態が有効（Enabled）か停止（Suspended）かも確認します。一度有効にしたバケットは未バージョニング状態へ戻せず、停止状態でも既存バージョンは残ります。バージョニング有効化前から存在したオブジェクトは、当初nullバージョンIDを持ちます。

関連トピック

• S3のアクセス制御と共有パターン
• S3の転送時・保管時の暗号化
• S3のバージョニング・ライフサイクル・レプリケーション
• AWS KMSのキー管理

公式ドキュメント

• S3のアクセス制御
• S3 ACLの概要とObject Ownership
• S3アクセスポイント
• S3 Object Lambdaの提供状況と仕組み
• 署名付きURLによるオブジェクトのダウンロードとアップロード
• S3のCORS設定
• S3の暗号化
• S3 Object Lock
• S3バージョニング
• Amazon S3 Glacier Vault Lock（既存のVaultベースサービス）