メニュー
Amazon Simple Storage Service
開発者ガイド (API バージョン 2006-03-01)

ポリシーでの条件の指定

アクセスポリシー言語では、アクセス許可を付与するときの条件を指定することができます。Condition エレメント (または Condition ブロック) を使用すると、ポリシーを実行するタイミングの条件を指定できます。Condition エレメント (オプション) に、ブール演算子 (等しい、未満など) を使用する演算式を構築し、リクエストの値に対する条件を適合させます。たとえば、オブジェクトをアップロードするアクセス許可を付与する場合、バケットの所有者は以下のように StringEquals 条件を追加して、オブジェクトをパブリックに読み取り可能にするよう要求することができます。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": [ "arn:aws:s3:::examplebucket/*" ], "Condition": { "StringEquals": { "s3:x-amz-acl": [ "public-read" ] } } } ] }

Condition ブロックは、指定されたキーと値のペア "s3:x-amz-acl":["public-read"] に適用される StringEquals 条件を指定します。条件式で使用できる事前に定義された一連のキーがあります。この例では、s3:x-amz-acl 条件キーを使用しています。この条件では、public-read の値が指定された x-amz-acl ヘッダーをすべての PUT Object リクエストに含めることがユーザーに求められます。

アクセスポリシー言語での条件の指定の詳細については、IAM ユーザーガイド の「条件」を参照してください。

次のトピックでは、AWS 全体および Amazon S3 固有の条件キーと、ポリシーの例を示します。

使用できる条件キー

Amazon S3 のアクセスポリシーで条件を指定するときに使用できる事前に定義されたキーは、次のように分類できます。

  • AWS 全体を対象とするキー – AWS には、よく使用される一連のキーが用意されています。これらのキーは、ポリシーをサポートするすべての AWS サービスでサポートされます。すべてのサービスに共通のこれらのキーは、AWS 全体のキーと呼ばれ、プレフィックス aws: を使用します。AWS 全体のキーのリストについては、IAM ユーザーガイドの「条件に利用可能なキー」を参照してください。また、Amazon S3 に固有のキーがあり、これらのキーではプレフィックス s3: が使用されます。Amazon S3 固有のキーについては、次の箇条書きで説明します。

     

    新しい条件キー aws:sourceVpce および aws:sourceVpc は、VPC エンドポイント用のバケットポリシーで使用されます。これらの条件キーの使用例については、「Amazon S3 の VPC エンドポイント用のバケットポリシーの例」を参照してください。

    以下のバケットポリシー例は、リクエストが指定された範囲の IP アドレス (192.168.143.*、ただし 192.168.143.188 を除く) から発信される場合に、認証ユーザーに s3:GetObject アクションを使用する権限を付与します。条件ブロックの IpAddressNotIpAddress は条件であり、それぞれの条件では評価されるキーと値のペアが指定されています。この例の両方のキーと値のペアでは、AWS 全体のキー aws:SourceIp を使用します。

    注記

    条件で指定されている IPAddressNotIpAddress のキー値は、RFC 4632 の CIDR 表記を使用していることに注意してください。詳細については、「http://www.rfc-editor.org/rfc/rfc4632.txt」を参照してください。

    { "Version": "2012-10-17", "Id": "S3PolicyId1", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": "*", "Action":["s3:GetObject"] , "Resource": "arn:aws:s3:::examplebucket/*", "Condition" : { "IpAddress" : { "aws:SourceIp": "192.168.143.0/24" }, "NotIpAddress" : { "aws:SourceIp": "192.168.143.188/32" } } } ] }
  • Amazon S3 固有のキー – AWS 全体のキーに加えて、以下の条件キーは Amazon S3 固有のアクセス許可を付与するコンテキストでのみ適用できます。これらの Amazon S3 固有のキーは、プレフィックス s3: を使用します。

    • s3:x-amz-acl

    • s3:x-amz-copy-source

    • s3:x-amz-metadata-directive

    • s3:x-amz-server-side-encryption

    • s3:VersionId

    • s3:LocationConstraint

    • s3:delimiter

    • s3:max-keys

    • s3:prefix

    • s3:x-amz-server-side-encryption-aws-kms-key-id

    • s3:ExistingObjectTag/<tag-key>

      オブジェクトタグ関連の条件キーを使用するポリシーの例については、「オブジェクトのタグ付けとアクセスコントロールポリシー」を参照してください。

    • s3:RequestObjectTagKeys

    • s3:RequestObjectTag/<tag-key>

     

    たとえば、以下のバケットポリシーは、オブジェクトをパブリックに読み取り可能にする x-amz-acl ヘッダーがリクエストに含まれている場合に、2 つの AWS アカウントに s3:PutObject のアクセス許可を付与します。

    { "Version":"2012-10-17", "Statement": [ { "Sid":"AddCannedAcl", "Effect":"Allow", "Principal": { "AWS": ["arn:aws:iam::account1-ID:root","arn:aws:iam::account2-ID:root"] }, "Action":["s3:PutObject"], "Resource": ["arn:aws:s3:::examplebucket/*"], "Condition": { "StringEquals": { "s3:x-amz-acl":["public-read"] } } } ] }

    Condition ブロックでは、StringEquals 条件を使用し、キーと値のペアとして "s3:x-amz-acl":["public-read" を評価に使用できます。このキーと値のペアで、s3:x-amz-acl は、「s3:」というプレフィックスが示すとおり Amazon S3 固有のキーです。

重要

すべての条件が、すべてのアクションに対して意味を成すわけではありません。たとえば、Amazon S3 のアクセス許可 s3:CreateBucket を付与するポリシーに s3:LocationConstraint 条件を含めることには意味がありますが、s3:GetObject のアクセス許可に対しては意味がありません。Amazon S3 では、Amazon S3 固有の条件も含めて、このタイプの意味的エラーをテストすることができます。ただし、IAM ユーザーを対象とするポリシーを作成するときに、意味的に無効な Amazon S3 条件が含まれていても、エラーは報告されません。これは、IAM が Amazon S3 条件を検証できないためです。

以下のセクションでは、バケットやオブジェクトのオペレーションに対して条件付きのアクセス許可を付与する条件キーについて説明します。さらに、Amazon S3 署名バージョン 4 認証に関連する条件キーもあります。詳細については、Amazon Simple Storage Service API Referenceの「Amazon S3 Signature Version 4 Authentication Specific Policy Keys」を参照してください。

オブジェクトオペレーションで使用できる Amazon S3 の条件キー

次の表は、どの Amazon S3 アクションにどの Amazon S3 条件を使用できるかを示しています。表に続いて、ポリシーの例を紹介します。次の表に記載されている Amazon S3 固有の条件キーについて、次の点に注意してください。

  • 条件キーの名前の前には、プレフィックス「s3:」が付いています。たとえば、s3:x-amz-acl と指定します。

  • それぞれの条件キーは、その条件を設定できる API でサポートされている同じ名前のリクエストヘッダーに対応します。つまり、これらの条件キーによって、同じ名前のリクエストヘッダーの動作が決定づけられます。(例:

    • アクセス許可 s3:PutObject に対して条件付きのアクセス許可を付与する条件キー s3:x-amz-acl は、PUT Object API でサポートされている x-amz-acl リクエストヘッダーの動作を定義します。

    • また、アクセス許可 s3:GetObjectVersion に対して条件付きのアクセス許可を付与する条件キー s3:VersionId は、GET Object リクエストで設定する versionId クエリパラメータの動作を定義します。

アクセス許可 適用できる条件キー (またはキーワード) 説明

s3:PutObject

  • s3:x-amz-acl (既定 ACL のアクセス許可)

  • s3:x-amz-grant-permission (明示的なアクセス許可)、permission の例:

    read, write,​ read-acp,​ write​-acp,​ ​full​-control

PUT Object オペレーションでは、アクセスコントロールリスト (ACL) 固有のヘッダーを使用して、ACL ベースのアクセス許可を付与することができます。バケット所有者は、これらのキーを使用して条件を設定し、ユーザーがオブジェクトをアップロードする場合に特定のアクセス許可を要求することができます。

ポリシーの例については、「例 1: バケット所有者にフルコントロールを与えることを条件として s3:PutObject のアクセス許可を付与する」を参照してください。

ACL の詳細については、「アクセスコントロールリスト (ACL) の概要」を参照してください。

s3:x-amz-copy-source

オブジェクトをコピーするには PUT Object API (「PUT Object」を参照) を使用します。コピー元を指定するには x-amz-copy-source ヘッダーを使用します。バケット所有者は、このキーを使用して、コピー元を特定のバケット、バケット内の特定のフォルダ、またはバケット内の特定のオブジェクトに限定できます。

ポリシーの例については、「例 3: 制限されているコピー元からオブジェクトをコピーする s3:PutObject のアクセス許可を付与する」を参照してください。

s3:x-amz-server-side-encryption

オブジェクトのアップロード時に、x-amz-server-side-encryption ヘッダーを使用して、オブジェクトを暗号化して保存するよう Amazon S3 にリクエストできます。暗号化には、AWS Key Management Service (AWS KMS) または Amazon S3 で管理されるエンベロープ暗号化キーを使用します (「サーバー側の暗号化を使用したデータの保護」を参照)。

s3:PutObject のアクセス許可を付与するとき、バケット所有者はこのキーを使用して条件を追加し、ユーザーが必ずリクエスト内でこのヘッダーを指定するよう要求することができます。バケット所有者は、このような条件付きのアクセス許可を付与することにより、ユーザーがアップロードするオブジェクトを保存時に暗号化できます。

ポリシーの例については、「例 1: バケット所有者にフルコントロールを与えることを条件として s3:PutObject のアクセス許可を付与する」を参照してください。

s3:x-amz-server-side-encryption-aws-kms-key-id

オブジェクトをアップロードするときに、x-amz-server-side-encryption-aws-kms-key-id ヘッダーを使用して、保存時に指定した AWS KMS キーを使用してオブジェクトの暗号化を Amazon S3 にリクエストすることができます (AWS KMS で管理されたキーによるサーバー側の暗号化 (SSE-KMS) を使用したデータの保護を参照)。

s3:PutObject にアクセス許可を付与する場合に、バケット所有者はこのキーを使用して条件を追加し、オブジェクトの暗号化に使用する AWS KMS キーの ID を指定値のみに制限できます。

バケット所有者は、このような条件付きのアクセス許可を付与することにより、ユーザーがアップロードするオブジェクトを保存時に特定のキーを使用して暗号化できます。

ポリシーで指定する AWS KMS キーには必ず次の形式を使用します。

arn:aws:kms:region:acct-id:key/key-id

s3:x-amz-metadata-directive

PUT Object API を使用してオブジェクトをコピーする場合 (「PUT Object」を参照)、オプションとして x-amz-metadata-directive ヘッダーを追加し、オブジェクトのメタデータをソースオブジェクトからコピーするか、リクエストで指定されているメタデータで置き換えるかを指定できます。

バケット所有者は、このキーを使用して条件を追加し、オブジェクトのアップロード時の動作を指定できます。

有効な値: COPY | REPLACE. デフォルト: COPY

s3:x-amz-storage-class

デフォルトでは s3:PutObjectSTANDARD ストレージクラスを使用してオブジェクトを保存しますが、x-amz-storage-class リクエストヘッダーを使用して異なるストレージクラスを指定することもできます。

s3:PutObject にアクセス許可を付与する場合に、s3:x-amz-storage-class 条件キーを使用してアップロードされたオブジェクトを保存する際に使用するストレージクラスを制限できます。ストレージクラスの詳細については、「ストレージクラス」を参照してください。

ポリシーの例については、「例 5: オブジェクトのアップロードを特定のストレージクラスのオブジェクトに制限する」を参照してください。

有効な値: STANDARD | STANDARD_IA | REDUCED_REDUNDANCY. デフォルト: STANDARD

  • s3:RequestObjectTagKeys

  • s3:RequestObjectTag/<tag-key>

この条件キーを使用して、リクエストで許可されるオブジェクトタグを制限することで、s3:PutObject アクションのアクセス許可を制限できます。これらの条件キーの使用例については、「オブジェクトのタグ付けとアクセスコントロールポリシー」を参照してください。

s3:PutObjectAcl

  • s3:x-amz-acl (既定 ACL のアクセス許可)

  • s3:x-amz-grant-permission (明示的なアクセス許可)、permission の例:

    read, write,​ read-acp,​ write​-acp,​ ​grant-full​-control

PUT Object ACL API は、指定されたオブジェクトのアクセスコントロールリスト (ACL) を設定します。オペレーションは、ACL の関連ヘッダーをサポートしています。このアクセス許可を付与するとき、バケット所有者は、これらのキーを使用して条件を追加し、特定のアクセス許可を要求することができます。ACL の詳細については、「アクセスコントロールリスト (ACL) の概要」を参照してください。

たとえば、バケット所有者は、オブジェクトを所有しているのが誰かに関係なく、オブジェクトに対するコントロールを維持する場合があります。そのような場合、バケット所有者はこれらのキーのうちの 1 つを使用して条件を追加し、バケット所有者に対する特定のアクセス許可を含めるようユーザーに要求できます。

s3:ExistingObjectTag/<tag-key>

この条件キーを使用して、s3:PutObjectAcl アクションのアクセス許可の対象を、特定のタグキーと値を持つオブジェクトに限定できます。例については、「オブジェクトのタグ付けとアクセスコントロールポリシー」を参照してください。

s3:PutObjectTagging

  • s3:RequestObjectTagKeys

  • s3:RequestObjectTag/<tag-key>

この条件キーを使用して、リクエストで許可されるオブジェクトタグを制限することで、s3:PutObjectTagging アクションのアクセス許可を制限できます。これらの条件キーの使用例については、「オブジェクトのタグ付けとアクセスコントロールポリシー」を参照してください。

s3:ExistingObjectTag/<tag-key>

この条件キーを使用して、アクセス許可の対象を特定のタグキーと値を持つオブジェクトに限定できます。例については、「オブジェクトのタグ付けとアクセスコントロールポリシー」を参照してください。

s3:PutObjectVersionTagging

  • s3:RequestObjectTagKeys

  • s3:RequestObjectTag/<tag-key>

この条件キーを使用して、リクエストで許可されるオブジェクトタグを制限することで、s3:PutObjectVersionTagging アクションのアクセス許可を制限できます。これらの条件キーの使用例については、「オブジェクトのタグ付けとアクセスコントロールポリシー」を参照してください。

s3:VersionId

この条件キーを使用して、s3:PutObjectVersionTagging アクションのアクセス許可の対象を特定のオブジェクトバージョンに限定できます。ポリシーの例については、「例 4: オブジェクトの特定のバージョンに対するアクセス許可を付与する」を参照してください。

s3:ExistingObjectTag/<tag-key>

この条件キーを使用して、アクセス許可の対象を特定のタグキーと値を持つオブジェクトに限定できます。例については、「オブジェクトのタグ付けとアクセスコントロールポリシー」を参照してください。

s3:GetObjectVersion

s3:VersionId

この Amazon S3 のアクセス許可により、一連の Amazon S3 API オペレーションを実行することができます (「オブジェクトオペレーションに対する Amazon S3 のアクセス許可」を参照)。バケットがバージョニングに対応している場合は、データを取得するオブジェクトのバージョンを指定できます。

このキーを使用して条件を追加すると、バケット所有者は、ユーザーがアクセスできるデータをオブジェクトの特定のバージョンのみに制限できます。ポリシーの例については、「例 4: オブジェクトの特定のバージョンに対するアクセス許可を付与する」を参照してください。

s3:ExistingObjectTag/<tag-key>

この条件キーを使用して、アクセス許可の対象を特定のタグキーと値を持つオブジェクトに限定できます。例については、「オブジェクトのタグ付けとアクセスコントロールポリシー」を参照してください。

s3:GetObject

s3:ExistingObjectTag/<tag-key>

この条件キーを使用して、アクセス許可の対象を特定のタグキーと値を持つオブジェクトに限定できます。例については、「オブジェクトのタグ付けとアクセスコントロールポリシー」を参照してください。

s3:GetObjectAcl

s3:ExistingObjectTag/<tag-key>

この条件キーを使用して、アクセス許可の対象を特定のタグキーと値を持つオブジェクトに限定できます。例については、「オブジェクトのタグ付けとアクセスコントロールポリシー」を参照してください。

s3:GetObjectVersionAcl

s3:VersionId

GET Object acl API を使用して、特定のオブジェクトバージョンのアクセスコントロールリスト (ACL) を取得できます。ユーザーには、s3:GetObjectVersionAcl アクションのアクセス許可が必要です。バケットがバージョニングに対応している場合、この Amazon S3 アクセス許可を使用して、オブジェクトの特定のバージョンの ACL を取得できます。

バケット所有者は、このキーを使用して条件を追加し、ユーザーがアクセスできるのをオブジェクトの特定のバージョンのみに制限できます。

s3:ExistingObjectTag/<tag-key>

この条件キーを使用して、アクセス許可の対象を特定のタグキーと値を持つオブジェクトに限定できます。例については、「オブジェクトのタグ付けとアクセスコントロールポリシー」を参照してください。

s3:PutObjectVersionAcl

s3:VersionId

バケットがバージョニングに対応している場合は、PUT Object acl リクエストでオブジェクトのバージョンを指定し、特定のオブジェクトバージョンの ACL を設定できます。バケット所有者はこの条件を使用して、ユーザーが ACL を設定できるオブジェクトを特定のバージョンのみに制限できます。

  • s3:x-amz-acl (既定 ACL のアクセス許可)

  • s3:x-amz-grant-permission (明示的なアクセス許可)、permission の例:

    read, write,​ read-acp,​ write​-acp,​ ​grant-full​-control

バケットがバージョニングに対応している場合、この Amazon S3 アクセス許可でオブジェクトの特定のバージョンの ACL を設定できます。

これらの条件キーの説明については、この表の s3:PutObjectACL のアクセス許可を参照してください。

s3:ExistingObjectTag/<tag-key>

この条件キーを使用して、アクセス許可の対象を特定のタグキーと値を持つオブジェクトに限定できます。例については、「オブジェクトのタグ付けとアクセスコントロールポリシー」を参照してください。

s3:DeleteObjectVersion

s3:VersionId

バケットがバージョニングに対応している場合、この Amazon S3 アクセス許可を使用して、オブジェクトの特定のバージョンを削除できます。

バケット所有者は、このキーを使用して条件を追加し、ユーザーが削除できるオブジェクトを特定のバージョンのみに制限できます。

この条件キーの使用例については、「例 4: オブジェクトの特定のバージョンに対するアクセス許可を付与する」を参照してください。この例では、s3:GetObjectVersion アクションを許可します。条件キーの使用方法に注目してください。

s3:DeleteObjectTagging

s3:ExistingObjectTag/<tag-key>

この条件キーを使用して、アクセス許可の対象を特定のタグキーと値を持つオブジェクトに限定できます。例については、「オブジェクトのタグ付けとアクセスコントロールポリシー」を参照してください。

s3:DeleteObjectVersionTagging

s3:ExistingObjectTag/<tag-key>

この条件キーを使用して、アクセス許可の対象を特定のタグキーと値を持つオブジェクトに限定できます。例については、「オブジェクトのタグ付けとアクセスコントロールポリシー」を参照してください。

s3:VersionId

この条件キーを使用して、s3:DeleteObjectVersionTagging アクションのアクセス許可の対象を特定のオブジェクトバージョンに限定できます。ポリシーの例については、「例 4: オブジェクトの特定のバージョンに対するアクセス許可を付与する」を参照してください。

s3:GetObjectTagging

s3:ExistingObjectTag/<tag-key>

この条件キーを使用して、アクセス許可の対象を特定のタグキーと値を持つオブジェクトに限定できます。例については、「オブジェクトのタグ付けとアクセスコントロールポリシー」を参照してください。

s3:GetObjectVersionTagging

s3:ExistingObjectTag/<tag-key>

この条件キーを使用して、アクセス許可の対象を特定のタグキーと値を持つオブジェクトに限定できます。例については、「オブジェクトのタグ付けとアクセスコントロールポリシー」を参照してください。

s3:VersionId

この条件キーを使用して、s3:GetObjectVersionTagging アクションのアクセス許可の対象を特定のオブジェクトバージョンに限定できます。ポリシーの例については、「例 4: オブジェクトの特定のバージョンに対するアクセス許可を付与する」を参照してください。

例 1: バケット所有者にフルコントロールを与えることを条件として s3:PutObject のアクセス許可を付与する

たとえば、アカウント A がバケットの所有者であり、アカウント管理者がアカウント B のユーザー Dave に対して、オブジェクトをアップロードするアクセス許可を付与するとします。デフォルトでは、Dave がアップロードするオブジェクトはアカウント B に所有されるため、アカウント A にはそれらのオブジェクトに対するアクセス許可は付与されません。しかし、バケットの所有者は請求書を支払うために、Dave がアップロードするオブジェクトに対する完全なアクセス許可を必要としています。この対処方法として、アカウント A の管理者は、明示的に完全なアクセス許可を付与するか、既定 ACL を使用する ACL 固有のヘッダーをリクエストに含むことを条件として、Dave に s3:PutObject のアクセス許可を付与できます (「PUT Object」を参照)。

  • バケット所有者にフルコントロールのアクセス許可を付与する x-amz-full-control ヘッダーをリクエストに含める.

    以下のバケットポリシーは、s3:x-amz-grant-full-control 条件キーを使用して、リクエストに x-amz-full-control ヘッダーを含めることを条件とする s3:PutObject のアクセス許可をユーザー Dave に付与します。

    { "Version": "2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::AccountB-ID:user/Dave" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::examplebucket/*", "Condition": { "StringEquals": { "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID" } } } ] }

    注記

    この例では、クロスアカウントのアクセス許可を付与しています。ただし、アクセス許可の被付与者の Dave がバケットの所有者である AWS アカウントに属している場合、アップロードするオブジェクトの所有者は Dave が属する親アカウントになるため、この条件付きアクセス許可は不要になります。

    前述のバケットポリシーでは、アカウント B のユーザー Dave に条件付きのアクセス許可が付与されます。ただし、このポリシーが有効であっても、Dave が他のポリシーに従って、条件なしで同じアクセス許可を取得する場合があります。たとえば、Dave が属するグループに、条件なしで s3:PutObject のアクセス許可が付与される場合があります。このようなアクセス許可の抜け穴を避けるには、明示的な拒否を追加して、より厳格なアクセスポリシーを記述する必要があります。次の例では、バケット所有者に完全なアクセス許可を付与するヘッダーをリクエストに含めない場合、Dave に対してアップロードのアクセス許可を明示的に拒否します。明示的な拒否は、付与されている他のアクセス許可に常に優先されます。修正されたアクセスポリシーの例を以下に示します。

    { "Version": "2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::AccountB-ID:user/AccountBadmin" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::examplebucket/*", "Condition": { "StringEquals": { "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID" } } }, { "Sid": "statement2", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::AccountB-ID:user/AccountBadmin" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::examplebucket/*", "Condition": { "StringNotEquals": { "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID" } } } ] }

    2 つの AWS アカウントがある場合は、AWS Command Line Interface (AWS CLI) を使用してポリシーをテストできます。ポリシーをアタッチしたら、Dave の認証情報を使用し、次の AWS CLI put-object コマンドを実行してアクセス許可をテストします。Dave の認証情報は、--profile パラメータを追加して指定します。バケット所有者にフルコントロールのアクセス許可を付与するには、--grant-full-control パラメータを追加します。AWS CLI のセットアップおよび使用の詳細については、「チュートリアル例のツールのセットアップ」を参照してください。

    aws s3api put-object --bucket examplebucket --key HappyFace.jpg --body c:\HappyFace.jpg --grant-full-control id="AccountA-CanonicalUserID" --profile AccountBUserProfile
  • バケット所有者にフルコントロールのアクセス許可を付与する既定 ACL が指定された x-amz-acl ヘッダーを要求する

    リクエストに x-amz-acl ヘッダーを含めることを要求するには、以下のように Condition ブロックのキーと値のペアを置き換え、s3:x-amz-acl 条件キーを指定します。

    "Condition": { "StringNotEquals": { "s3:x-amz-acl": "bucket-owner-full-control" }

    AWS CLI を使用してアクセス許可をテストするには、--acl パラメータを指定します。これにより、AWS CLI は送信するリクエストに x-amz-acl ヘッダーを追加します。

    aws s3api put-object --bucket examplebucket --key HappyFace.jpg --body c:\HappyFace.jpg --acl "bucket-owner-full-control" --profile AccountBadmin

例 2: サーバー側の暗号化を使用してオブジェクトを保存するよう要求する s3:PutObject のアクセス許可を付与する

アカウント A がバケットの所有者であるとします。アカウント管理者は、アカウント A のユーザー Jane にオブジェクトをアップロードするアクセス許可を付与するとします。ただし、必ずサーバー側の暗号化をリクエストすることを条件とします。これにより、Amazon S3 でオブジェクトが暗号化されて保存されます。この場合、アカウント A の管理者は、以下のように s3:x-amz-server-side-encryption 条件キーを使用することができます。Condition ブロックのキーと値のペアは、s3:x-amz-server-side-encryption キーを指定します。

"Condition": { "StringNotEquals": { "s3:x-amz-server-side-encryption": "AES256" }

AWS CLI を使用してアクセス許可をテストする場合は、--server-side-encryption パラメータを使用して、必須パラメータを追加する必要があります。

aws s3api put-object --bucket example1bucket --key HappyFace.jpg --body c:\HappyFace.jpg --server-side-encryption "AES256" --profile AccountBadmin

例 3: 制限されているコピー元からオブジェクトをコピーする s3:PutObject のアクセス許可を付与する

PUT Object リクエストでは、ソースオブジェクトを指定すると、コピーオペレーションを実行できます (「PUT Object - Copy」を参照)。したがって、バケット所有者は限定されたソースからのみオブジェクトをコピーできるアクセス許可をユーザーに付与できます。(例:

  • sourcebucket バケットからのみオブジェクトをコピーすることを許可します。

  • sourcebucket バケットから、キー名のプレフィックスが public/ で始まるオブジェクト (sourcebucket/public/* など) のみコピーすることを許可します。

  • sourcebucket から特定のオブジェクト (sourcebucket/example.jpg など) のみコピーすることを許可します。

以下のバケットポリシーは、リクエストに s3:x-amz-copy-source ヘッダーを含め、ヘッダーの値が /examplebucket/public/* キー名のプレフィックスを指定するという条件が満たされる場合にのみ、オブジェクトをコピーできる s3:PutObject のアクセス許可をユーザー Dave に付与します。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "cross-account permission to user in your own account", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::AccountA-ID:user/Dave" }, "Action": ["s3:PutObject"], "Resource": "arn:aws:s3:::examplebucket/*" }, { "Sid": "Deny your user permission to upload object if copy source is not /bucket/folder", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::AccountA-ID:user/Dave" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::examplebucket/*", "Condition": { "StringNotLike": { "s3:x-amz-copy-source": "examplebucket/public/*" } } } ] }

AWS CLI の copy-object コマンドを使用して、アクセス許可をテストできます。--copy-source パラメータを追加してソースを指定します。キー名のプレフィックスは、ポリシーで許可されているプレフィックスと一致する必要があります。--profile パラメータを使用して、ユーザー Dave の認証情報を指定します。AWS CLI のセットアップの詳細については、「チュートリアル例のツールのセットアップ」を参照してください。

aws s3api copy-object --bucket examplebucket --key HappyFace.jpg --copy-source examplebucket/public/PublicHappyFace1.jpg --profile AccountADave

前述のポリシーでは、StringNotLike 条件が使用されています。特定のオブジェクトのみをコピーするアクセス許可を付与するには、条件を StringNotLike から StringNotEquals に変更し、次のようにオブジェクトキーを正確に指定する必要があります。

"Condition": { "StringNotEquals": { "s3:x-amz-copy-source": "examplebucket/public/PublicHappyFace1.jpg" } }

例 4: オブジェクトの特定のバージョンに対するアクセス許可を付与する

アカウント A が、バージョンを使用可能なバケットを所有しているとします。このバケットには、HappyFace.jpg オブジェクトのバージョンが複数含まれています。アカウント管理者は、ユーザー (Dave) にオブジェクトの特定のバージョンのみを取得できるアクセス許可を付与したいと考えています。この場合、アカウント管理者は、次に示すように、条件を付けて Dave に s3:GetObjectVersion のアクセス許可を付与できます。Condition ブロックのキーと値のペアは、s3:VersionId 条件キーを指定します。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::AccountA-ID:user/Dave" }, "Action": ["s3:GetObjectVersion"], "Resource": "arn:aws:s3:::examplebucketversionenabled/HappyFace.jpg" }, { "Sid": "statement2", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::AccountA-ID:user/Dave" }, "Action": ["s3:GetObjectVersion"], "Resource": "arn:aws:s3:::examplebucketversionenabled/HappyFace.jpg", "Condition": { "StringNotEquals": { "s3:VersionId": "AaaHbAQitwiL_h47_44lRO2DDfLlBO5e" } } } ] }

この場合、Dave がオブジェクトを取得するには、オブジェクトのバージョン ID を正確に知っている必要があります。

このアクセス許可をテストするには、AWS CLI の get-object コマンドを実行するときに、特定のオブジェクトバージョンを指定する --version-id パラメータを使用します。コマンドは、オブジェクトを取得し、OutputFile.jpg ファイルに保存します。

aws s3api get-object --bucket examplebucketversionenabled --key HappyFace.jpg OutputFile.jpg --version-id AaaHbAQitwiL_h47_44lRO2DDfLlBO5e --profile AccountADave

例 5: オブジェクトのアップロードを特定のストレージクラスのオブジェクトに制限する

アカウント A がバケットの所有者であるとします。アカウント管理者は、アカウント A のユーザーである Dave に対して、STANDARD_IA ストレージクラスに保存されているバケットにのみオブジェクトのアップロードを許可するとします。この場合、次のバケットポリシー例に示すように、アカウント A の管理者は s3:x-amz-storage-class 条件キーを使用できます。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::AccountA-ID:user/Dave" }, "Action": "s3:PutObject", "Resource": [ "arn:aws:s3:::examplebucket/*" ], "Condition": { "StringEquals": { "s3:x-amz-storage-class": [ "STANDARD_IA" ] } } } ] }

バケットオペレーションで使用できる Amazon S3 の条件キー

次の表に、ポリシーで付与できるバケットオペレーション固有のアクセス許可と、それぞれのアクセス許可で条件を指定するのに使用できるキーのリストを示します。

アクセス許可 適用できる条件キー 説明

s3:CreateBucket

  • s3:x-amz-acl (既定 ACL のアクセス許可)

  • s3:x-amz-grant-permission (明示的なアクセス許可)、permission の例:

    read, write,​ read-acp,​ write​-acp,​ ​full​-control

Create Bucket API (「PUT Bucket」を参照) は、ACL 固有のヘッダーをサポートしています。これらの条件キーを使用すると、これらのヘッダーをリクエストで設定して、特定のアクセス許可を付与するようユーザーに求めることができます。

s3:LocationConstraint

この条件キーを使用すると、バケットの作成先を特定の AWS リージョンに制限できます。ポリシーの例については、「例 1: 特定のリージョンでのみバケットの作成をユーザーに許可する」を参照してください。

s3:ListBucket

s3:prefix

この条件キーを使用すると、Get Bucket (List Objects) API (「GET Bucket (List Objects)」を参照) のレスポンスを特定のプレフィックスを持つキー名に制限できます。

Get Bucket (List Objects) API は、指定したバケットのオブジェクトキーのリストを返します。この API は prefix ヘッダーをサポートしているので、指定されたプレフィックスの付いたオブジェクトキーのみを取得できます。この条件キーは、prefix ヘッダーに関連しています。

たとえば、Amazon S3 コンソールは、キー名のプレフィックスを使用するフォルダの概念をサポートしています。そのため、キー名が public/object1.jpg および public/object2.jpg である 2 つのオブジェクトがある場合、コンソールには public フォルダ以下のオブジェクトが表示されます。このようなプレフィックスを使用してオブジェクトキーを管理している場合は、特定のプレフィックスの付いたキー名のリストを取得できる、条件付きのアクセス許可 s3:ListBucket を付与できます。

ポリシーの例については、「例 2: 特定のプレフィックスに基づいてバケット内のオブジェクトのリストを取得することを許可する 」を参照してください。

s3:delimiter

プレフィックスと区切り記号を使用してオブジェクトキー名を管理している場合は、この条件キーを使用して、Get Bucket (List Objects) リクエストで delimiter パラメータを指定するようユーザーに求めることができます。この場合、Amazon S3 が返すレスポンスは、共通のプレフィックスでグループ化されたオブジェクトキーのリストです。プレフィックスと区切り記号の使用例については、「Get Bucket (List Objects)」を参照してください。

s3:max-keys

この条件を使用すれば、max-keys パラメータを指定するようユーザーに要求して、Get Bucket (List Objects) リクエストに対するレスポンスで Amazon S3 が返すキーの数を制限できます。デフォルトでは、API は最大 1,000 個のキー名を返します。

使用できる数値条件のリストについては、IAM ユーザーガイドの 「数値条件演算子」を参照してください。

s3:ListBucketVersions

s3:prefix

バケットがバージョニングに対応している場合は、GET Bucket Object versions API (「GET Bucket Object versions」を参照) を使用して、オブジェクトのすべてのバージョンのメタデータを取得できます。この API では、バケット所有者は、ポリシーで s3:ListBucketVersions のアクセス許可を付与する必要があります。

この条件キーを使用すると、リクエストで prefix パラメータに特定の値を指定するようユーザーに要求することで、API のレスポンスを特定のプレフィックスの付いたキー名のみに制限できます。

たとえば、Amazon S3 コンソールは、キー名のプレフィックスを使用するフォルダの概念をサポートしています。キー名が public/object1.jpg および public/object2.jpg である 2 つのオブジェクトがある場合、コンソールには public フォルダ以下のオブジェクトが表示されます。このようなプレフィックスを使用してオブジェクトキーを管理している場合は、特定のプレフィックスの付いたキー名のリストを取得できる、条件付きのアクセス許可 s3:ListBucket を付与できます。

ポリシーの例については、「例 2: 特定のプレフィックスに基づいてバケット内のオブジェクトのリストを取得することを許可する 」を参照してください。

s3:delimiter

プレフィックスと区切り記号を使用してオブジェクトキー名を管理している場合は、この条件キーを使用して、GET Bucket Object versions リクエストで delimiter パラメータを指定するようユーザーに求めることができます。この場合、Amazon S3 が返すレスポンスは、共通のプレフィックスでグループ化されたオブジェクトキーのリストです。

s3:max-keys

この条件を使用すると、max-keys パラメータを指定するようユーザーに要求することで、GET Bucket Object バージョンのリクエストに応じて Amazon S3 が返すキーの数を制限できます。デフォルトでは、API は最大 1,000 個のキー名を返します。使用できる数値条件のリストについては、IAM ユーザーガイドの 「数値条件演算子」を参照してください。

s3:PutBucketAcl

  • s3:x-amz-acl (既定 ACL のアクセス許可)

  • s3:x-amz-grant-permission (明示的なアクセス許可)、permission の例:

    read, write,​ read-acp,​ write​-acp,​ ​full​-control

PUT Bucket acl API (「PUT Bucket」を参照) は、ACL 固有のヘッダーをサポートしています。これらの条件キーを使用して、リクエストでこれらのヘッダーを設定するようユーザーに要求することができます。

例 1: 特定のリージョンでのみバケットの作成をユーザーに許可する

AWS アカウントの管理者が、南米 (サンパウロ) リージョンでのみバケットを作成するアクセス許可をユーザー (Dave) に付与するとします。アカウント管理者は、以下のように条件を指定して、s3:CreateBucket のアクセス許可を付与する次のユーザーポリシーをアタッチします。Condition ブロックのキーと値のペアは、s3:LocationConstraint キーおよびその値として sa-east-1 リージョンを指定します。

注記

この例では、バケット所有者はユーザーの 1 人にアクセス許可を付与するため、バケットポリシーまたはユーザーポリシーのどちらでも使用することができます。この例では、ユーザーポリシーを使用します。

Amazon S3 リージョンのリストについては、アマゾン ウェブ サービス全般のリファレンスの「リージョンとエンドポイント」を参照してください。

{ "Version":"2012-10-17", "Statement":[ { "Sid":"statement1", "Effect":"Allow", "Action":[ "s3:CreateBucket" ], "Resource":[ "arn:aws:s3:::*" ], "Condition": { "StringLike": { "s3:LocationConstraint": "sa-east-1" } } } ] }

このポリシーは、ユーザーが sa-east-1 以外のリージョンでバケットを作成することを制限します。ただし、他のポリシーによって、別のリージョンでバケットを作成するアクセス許可が付与される場合があります。たとえば、ユーザーがグループに属しており、そのグループにアタッチされているポリシーでは、グループ内のすべてのユーザーに別のリージョンでバケットを作成するアクセス許可を付与する場合があります。別のリージョンでバケットを作成するアクセス許可をユーザーに付与しないように、このポリシーに明示的な拒否のステートメントを追加します。

{ "Version":"2012-10-17", "Statement":[ { "Sid":"statement1", "Effect":"Allow", "Action":[ "s3:CreateBucket" ], "Resource":[ "arn:aws:s3:::*" ], "Condition": { "StringLike": { "s3:LocationConstraint": "sa-east-1" } } }, { "Sid":"statement2", "Effect":"Deny", "Action":[ "s3:CreateBucket" ], "Resource":[ "arn:aws:s3:::*" ], "Condition": { "StringNotLike": { "s3:LocationConstraint": "sa-east-1" } } } ] }

Deny ステートメントは、StringNotLike 条件を使用します。つまり、場所の制約が「sa-east-1」でない場合、バケットの作成リクエストは拒否されます。明示的な拒否を使用すれば、どのようなアクセス権限が付与されている場合でも、ユーザーは別のリージョンでバケットを作成できなくなります。

このポリシーは、次の AWS CLI コマンド create-bucket を使用してテストできます。この例では、bucketconfig.txt ファイルを使用して場所の制約を指定しています。Windows のファイルパスに注意してください。必要に応じて、バケットの名前とパスを更新します。--profile パラメータを使用して、ユーザーの認証情報を指定する必要があります。AWS CLI のセットアップおよび使用の詳細については、「チュートリアル例のツールのセットアップ」を参照してください。

aws s3api create-bucket --bucket examplebucket --profile AccountADave --create-bucket-configuration file://c:/Users/someUser/bucketconfig.txt

bucketconfig.txt ファイルは、次のように設定を指定します。

{"LocationConstraint": "sa-east-1"}

例 2: 特定のプレフィックスに基づいてバケット内のオブジェクトのリストを取得することを許可する

バケット所有者は、バケット内の特定のフォルダに限り、コンテンツを表示することをユーザーに許可できます。これは、バケット内のオブジェクトがキー名プレフィックスで整理されている場合に便利です。Amazon S3 コンソールは、このプレフィックスを使用してフォルダ階層を表示します (フォルダの概念をサポートしているのはコンソールのみです。Amazon S3 API は、バケットとオブジェクトのみをサポートしています)。

この例では、バケット所有者とユーザーが属する親アカウントは同一です。したがって、バケット所有者はバケットポリシーまたはユーザーポリシーのどちらでも使用することができます。最初に、ユーザーポリシーの使用例を示します。

以下のユーザーポリシーは、ユーザーがリクエストで prefix およびその値 projects を指定することを条件として、s3:ListBucket のアクセス許可を付与します (「GET Bucket (List Objects)」を参照)。

{ "Version":"2012-10-17", "Statement":[ { "Sid":"statement1", "Effect":"Allow", "Action":[ "s3:ListBucket" ], "Resource":[ "arn:aws:s3:::examplebucket" ], "Condition" : { "StringEquals" : { "s3:prefix": "projects" } } }, { "Sid":"statement2", "Effect":"Deny", "Action":[ "s3:ListBucket" ], "Resource":[ "arn:aws:s3:::examplebucket" ], "Condition" : { "StringNotEquals" : { "s3:prefix": "projects" } } } ] }

この条件では、ユーザーの取得できるリストが projects プレフィックスの付いているオブジェクトキーに限定されます。明示的な拒否を追加すると、ユーザーに付与されている他のアクセス許可に関係なしに、他のプレフィックスが付いたキーのリストを求めるユーザーのリクエストは拒否されます。たとえば、以前のユーザーポリシーの更新やバケットポリシーにより、オブジェクトキーのリストを取得するアクセス許可がユーザーに制限なく付与される場合があります。ただし、明示的な拒否は常に優先されるため、project プレフィックス以外のキーのリストを求めるユーザーのリクエストは拒否されます。

前述のポリシーは、ユーザーポリシーです。ポリシーに Principal エレメントを追加して、ユーザーを指定する場合は、次のようにバケットポリシーを使用できます。

{ "Version":"2012-10-17", "Statement":[ { "Sid":"statement1", "Effect":"Allow", "Principal": { "AWS": "arn:aws:iam::BucketOwner-accountID:user/user-name" }, "Action":[ "s3:ListBucket" ], "Resource":[ "arn:aws:s3:::examplebucket" ], "Condition" : { "StringEquals" : { "s3:prefix": "examplefolder" } } }, { "Sid":"statement2", "Effect":"Deny", "Principal": { "AWS": "arn:aws:iam::BucketOwner-AccountID:user/user-name" }, "Action":[ "s3:ListBucket" ], "Resource":[ "arn:aws:s3:::examplebucket" ], "Condition" : { "StringNotEquals" : { "s3:prefix": "examplefolder" } } } ] }

このポリシーは、次の AWS CLI コマンド list-object を使用してテストできます。このコマンドでは、--profile パラメータを使用してユーザーの認証情報を指定します。AWS CLI のセットアップおよび使用の詳細については、「チュートリアル例のツールのセットアップ」を参照してください。

aws s3api list-objects --bucket examplebucket --prefix examplefolder --profile AccountADave

バケットがバージョニングに対応している場合、バケット内のオブジェクトのリストを取得するには、s3:ListBucket のアクセス許可ではなく、前述のポリシーで s3:ListBucketVersions のアクセス許可を付与する必要があります。このアクセス許可は、s3:prefix 条件キーもサポートしています。