Amazon S3 条件キーの例
アクセスポリシー言語を使用して、アクセス許可を付与するときに条件を指定できます。オプションの Condition
エレメント、または Condition
ブロックを使用して、ポリシーが有効になるときの条件を指定できます。
オブジェクトおよびバケットオペレーションに Amazon S3 条件キーを使用するポリシーについては、次の例を参照してください。条件キーの詳細については、Amazon S3 の条件キー を参照してください。ポリシーで指定できる Amazon S3 のアクション、条件キー、リソースの一覧については、Amazon S3 のアクション、リソース、条件キー を参照してください。
例 — オブジェクトオペレーションで使用できる Amazon S3 の条件キー
このセクションでは、オブジェクトオペレーションに Amazon S3 固有の条件キーを使用する方法の例を示します。ポリシーで指定できる Amazon S3 のアクション、条件キー、リソースの一覧については、Amazon S3 のアクション、リソース、条件キー を参照してください。
ここでは、PutObject オペレーションで条件キーを使用するポリシーの例をいくつか示します。PutObject オペレーションでは、アクセスコントロールリスト (ACL) に固有のヘッダーを使用して、ACL に基づいてアクセス許可を付与することができます。バケット所有者は、これらのキーを使用して条件を設定し、ユーザーがオブジェクトをアップロードする場合に特定のアクセス許可を要求することができます。また、PutObjectAcl オペレーションを使用して ACL に基づいてアクセス許可を付与することもできます。詳細については、Amazon S3 Amazon Simple Storage Service API リファレンスの PutObjectAcl を参照してください。ACL の詳細については、アクセスコントロールリスト (ACL) の概要 を参照してください。
トピック
- 例 1: バケット所有者にフルコントロールを与えることを条件として s3:PutObject のアクセス許可を付与する
- 例 2: サーバー側の暗号化を使用してオブジェクトを保存するよう要求する s3:PutObject のアクセス許可を付与する
- 例 3: 制限されているコピー元からオブジェクトをコピーする s3:PutObject のアクセス許可を付与する
- 例 4: オブジェクトの特定のバージョンに対するアクセス許可を付与する
- 例 5: オブジェクトのアップロードを特定のストレージクラスのオブジェクトに制限する
- 例 6: オブジェクトタグに基づくアクセス許可の付与
- 例 7: バケット所有者の AWS アカウント ID によるアクセスの制限
- 例 8: 最小の TLS バージョンの要求
例 1: バケット所有者にフルコントロールを与えることを条件として s3:PutObject のアクセス許可を付与する
PutObject オペレーションでは、アクセスコントロールリスト (ACL) に固有のヘッダーを使用して、ACL に基づいてアクセス許可を付与することができます。バケット所有者は、これらのキーを使用して条件を設定し、ユーザーがオブジェクトをアップロードする場合に特定のアクセス許可を要求することができます。
例えば、アカウント A がバケット所有者であり、アカウント管理者がアカウント B のユーザー Dave に対して、オブジェクトをアップロードするアクセス許可を付与するとします。デフォルトでは、Dave がアップロードするオブジェクトはアカウント B に所有されるため、アカウント A にはそれらのオブジェクトに対するアクセス許可は付与されません。ただし、バケット所有者は請求書を支払うために、Dave がアップロードするオブジェクトに対する完全なアクセス許可を必要としています。この対処方法として、アカウント A の管理者は、明示的に完全なアクセス許可を付与するか、既定 ACL を使用する ACL 固有のヘッダーをリクエストに含むことを条件として、Dave に s3:PutObject
のアクセス許可を付与できます。詳細については、Put Object を参照してください。
x−amz−full−control ヘッダーを必須にする
リクエストで、バケット所有者へのフルコントロールのアクセス許可が含まれる x-amz-full-control
ヘッダーを要求できます。以下のバケットポリシーは、s3:PutObject
条件キーを使用して、リクエストに s3:x-amz-grant-full-control
ヘッダーを含めることを条件とする x-amz-full-control
のアクセス許可をユーザー 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:::awsexamplebucket1
/*", "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:::awsexamplebucket1
/*", "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:::awsexamplebucket1
/*", "Condition": { "StringNotEquals": { "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID
" } } } ] }
AWS CLI でポリシーをテストする
2 つの AWS アカウントがある場合は、AWS Command Line Interface (AWS CLI) を使用してポリシーをテストできます。ポリシーをアタッチしたら、Dave の認証情報を使用し、次の AWS CLI put-object
コマンドを実行してアクセス許可をテストします。Dave の認証情報は、--profile
パラメータを追加して指定します。バケット所有者にフルコントロールのアクセス許可を付与するには、--grant-full-control
パラメータを追加します。AWS CLI のセットアップおよび使用の詳細については、AWS CLI を使用した Amazon S3 での開発 を参照してください。
aws s3api put-object --bucket
examplebucket
--key HappyFace.jpg --body c:\HappyFace.jpg --grant-full-control id="AccountA-CanonicalUserID
" --profile AccountBUserProfile
x−amz−acl ヘッダーを必須にする
バケット所有者にフルコントロールのアクセス許可を付与する既定 ACL が指定された x-amz-acl
ヘッダーを要求できます。リクエストに x-amz-acl
ヘッダーを含めることを義務付けるには、以下の例のように Condition
ブロックのキーと値のペアを置き換え、s3:x-amz-acl
条件キーを指定します。
"Condition": { "StringEquals": { "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
バケットからのみオブジェクトをコピーすることを許可します。 -
ソースバケットのオブジェクトのコピーを許可し、キー名のプレフィックスが public/ で始まるオブジェクト (例: sourcebucket/public/* など) のみを許可します。
-
ソースバケットの特定のオブジェクト (例: sourcebucket/example.jpg など) のコピーのみを許可します。
次のバケットポリシーでは、ユーザー (Dave) に s3:PutObject
のアクセス許可が付与されます。Dave は、リクエストに s3:x-amz-copy-source
ヘッダーを含め、ヘッダーの値でキー名のプレフィックスに /awsexamplebucket1/public/*
を指定している場合にのみ、オブジェクトをコピーすることができます。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "cross-account permission to user in your own account", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::
123456789012
:user/Dave" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1
/*" }, { "Sid": "Deny your user permission to upload object if copy source is not /bucket/folder", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::123456789012
:user/Dave" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1
/*", "Condition": { "StringNotLike": { "s3:x-amz-copy-source": "awsexamplebucket1
/public/*" } } } ] }
AWS CLI でポリシーをテストする
AWS CLI の copy-object
コマンドを使用して、アクセス許可をテストできます。--copy-source
パラメータを追加してソースを指定します。キー名のプレフィックスは、ポリシーで許可されているプレフィックスと一致する必要があります。--profile
パラメータを使用して、ユーザー Dave の認証情報を指定します。AWS CLI のセットアップの詳細については、AWS CLI を使用した Amazon S3 での開発 を参照してください。
aws s3api copy-object --bucket
awsexamplebucket1
--key HappyFace.jpg --copy-sourceexamplebucket
/public/PublicHappyFace1.jpg --profile AccountADave
特定のオブジェクトのみをコピーするアクセス許可を付与する
前述のポリシーでは、StringNotLike
条件を使用しています。特定のオブジェクトのみをコピーするアクセス許可を付与するには、条件を StringNotLike
から StringNotEquals
に変更し、次のようにオブジェクトキーを正確に指定する必要があります。
"Condition": { "StringNotEquals": { "s3:x-amz-copy-source": "
awsexamplebucket1
/public/PublicHappyFace1.jpg" } }
例 4: オブジェクトの特定のバージョンに対するアクセス許可を付与する
アカウント A が、バージョンを使用可能なバケットを所有しているとします。このバケットには、HappyFace.jpg
オブジェクトのバージョンが複数含まれています。アカウント管理者は、ユーザー Dave にオブジェクトの特定のバージョンのみを取得できるアクセス許可を付与したいと考えています。この場合、アカウント管理者は、次に示すように、条件を付けて Dave に s3:GetObjectVersion
のアクセス許可を付与できます。Condition
ブロックのキーと値のペアは、s3:VersionId
条件キーを指定します。この場合、Dave がオブジェクトを取得するには、オブジェクトのバージョン ID を正確に知っている必要があります。
詳細については、Amazon Simple Storage Service API リファレンスの GetObject を参照してください。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::
123456789012
:user/Dave" }, "Action": "s3:GetObjectVersion", "Resource": "arn:aws:s3:::examplebucketversionenabled
/HappyFace.jpg" }, { "Sid": "statement2", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::123456789012
:user/Dave" }, "Action": "s3:GetObjectVersion", "Resource": "arn:aws:s3:::examplebucketversionenabled
/HappyFace.jpg", "Condition": { "StringNotEquals": { "s3:VersionId": "AaaHbAQitwiL_h47_44lRO2DDfLlBO5e
" } } } ] }
AWS CLI でポリシーをテストする
このアクセス許可をテストするには、AWS CLI の get-object
コマンドを実行するときに、特定のオブジェクトバージョンを指定する --version-id
パラメータを使用します。コマンドは、オブジェクトを取得し、OutputFile.jpg
ファイルに保存します。
aws s3api get-object --bucket
examplebucketversionenabled
--key HappyFace.jpg OutputFile.jpg --version-idAaaHbAQitwiL_h47_44lRO2DDfLlBO5e
--profile AccountADave
例 5: オブジェクトのアップロードを特定のストレージクラスのオブジェクトに制限する
アカウント ID が 123456789012 のアカウント 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::
123456789012
:user/Dave" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET1
/*", "Condition": { "StringEquals": { "s3:x-amz-storage-class": [ "STANDARD_IA" ] } } } ] }
例 6: オブジェクトタグに基づくアクセス許可の付与
Amazon S3 のオペレーションでオブジェクトのタグの条件キーを使用する方法の例については、タグ付けとアクセスコントロールポリシー を参照してください。
例 7: バケット所有者の AWS アカウント ID によるアクセスの制限
aws:ResourceAccount
キーと s3:ResourceAccount
キーのいずれかを使用して、特定の AWS アカウント ID が所有する Amazon S3 バケットへのユーザーまたはアプリケーションのアクセスを制限する IAM または仮想プライベートクラウド (VPC) エンドポイントポリシーを記述できます。この条件キーを使用して、VPC 内のクライアントが、ユーザーが所有していないバケットにアクセスすることを制限できます。
ただし、一部の AWS サービスは AWS マネージドバケットへのアクセスに依存していることに注意してください。したがって、IAM ポリシーで aws:ResourceAccount
キーまたは s3:ResourceAccount
キーを使用することは、これらのリソースへのアクセスにも影響する可能性があります。
詳細および例については、次のリソース を参照してください。
-
AWS アカウント ガイドの指定された AWS PrivateLink のバケットへのアクセスの制限
-
Amazon ECR ガイドの Amazon ECR が使用するバケットへのアクセスを制限する
-
AWS Systems Manager ガイドの AWS が管理する Amazon S3 バケットに必要なアクセスを System Manager に提供する
-
AWS ストレージブログの Limit access to owned by specific AWS アカウント
例 8: 最小の TLS バージョンの要求
s3:TlsVersion 条件キーを使用して、単純な IAM、Virtual Private Cloud Endpoint (VPCE)、またはバケットポリシーを記述し、クライアントが使用する TLS バージョンに基づいて Amazon S3 バケットへのユーザーまたはアプリケーションのアクセスを制限できます。この条件キーを使用して、最小の TLS バージョンを必要とするポリシーを記述できます。
このバケットポリシーの例では、1.2 よりも低い TLS バージョン (1.1 や 1.0 など) のクライアントによる PutObject リクエストを拒否します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": "s3:PutObject", "Resource": [ "arn:aws:s3:::
", "arn:aws:s3:::
DOC-EXAMPLE-BUCKET1
/*" ], "Condition": { "NumericLessThan": { "s3:TlsVersion": 1.2 } } } ] }
DOC-EXAMPLE-BUCKET1
このバケットポリシー例では、1.1 よりも高い TLS バージョン (1.2、1.3 以上など) のクライアントによる PutObject リクエストを許可します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "s3:PutObject", "Resource": [ "arn:aws:s3:::
", "arn:aws:s3:::
DOC-EXAMPLE-BUCKET1
/*" ], "Condition": { "NumericGreaterThan": { "s3:TlsVersion": 1.1 } } } ] }
DOC-EXAMPLE-BUCKET1
例 — バケットオペレーションで使用できる Amazon S3 の条件キー
このセクションでは、バケットオペレーションに Amazon S3 の固有の条件キーを使用するポリシーの例を示します。
例 1: 特定のリージョンでのみバケットを作成するアクセス許可の付与
例えば、AWS アカウント の管理者がユーザー (Dave) に南米 (サンパウロ) リージョンでのみバケットを作成できる許可を付与するとします。アカウント管理者は、以下のように条件を指定して、s3:CreateBucket
のアクセス許可を付与する次のユーザーポリシーをアタッチします。Condition
ブロックのキーと値のペアは、s3:LocationConstraint
キーと、その値として sa-east-1
リージョンを指定します。
注記
この例では、バケット所有者はユーザーの 1 人にアクセス許可を付与するため、バケットポリシーまたはユーザーポリシーのどちらでも使用することができます。この例では、ユーザーポリシーを使用します。
Amazon S3 リージョンのリストについては、AWS 全般のリファレンス の「リージョンとエンドポイント」を参照してください。
{ "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
以外のリージョンでバケットを作成することを制限します。ただし、他の一部のポリシーで、このユーザーに別のリージョンでバケットを作成するアクセス許可を付与する場合があります。例えば、ユーザーがグループに属している場合、グループのアクセス許可内にいるすべてのユーザーが別のリージョンでバケットを作成できるように、ポリシーがアタッチされている場合があります。ユーザーに別のリージョンでバケットを作成するアクセス許可が付与されないように、上記のポリシーに明示的な拒否のステートメントを追加します。
Deny
ステートメントは、StringNotLike
条件を使用します。つまり、場所の制約が 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" } } } ] }
AWS CLI でポリシーをテストする
このポリシーは、次の create-bucket
AWS CLI コマンドを使用してテストできます。この例では、bucketconfig.txt
ファイルを使用して場所の制約を指定しています。Windows のファイルパスに注意してください。必要に応じて、バケットの名前とパスを更新します。--profile
パラメータを使用して、ユーザーの認証情報を指定する必要があります。AWS CLI のセットアップおよび使用の詳細については、AWS CLI を使用した Amazon S3 での開発 を参照してください。
aws s3api create-bucket --bucket
examplebucket
--profile AccountADave --create-bucket-configuration file://c:/Users/someUser/bucketconfig.txt
bucketconfig.txt
ファイルは、次のように設定を指定します。
{"LocationConstraint": "sa-east-1"}
例 2: 特定のプレフィックスを持つバケット内のオブジェクト一覧の取得
s3:prefix
条件キーを使用して、GET Bucket (ListObjects) API の応答を、特定のプレフィックスを持つキー名に制限できます。バケット所有者であれば、バケット内の特定のプレフィックスの内容に限り、コンテンツを表示することをユーザーに許可できます。この条件キーは、バケットのオブジェクトがキー名プレフィックスによって整理されている場合に便利です。Amazon S3 コンソールでは、キー名のプレフィックスを使用して、フォルダの概念を示します。フォルダの概念をサポートしているはコンソールのみです。Amazon S3 API では、バケットとオブジェクトのみがサポートされています。プレフィックスと区切り文字を使用してアクセス許可をフィルタリングする方法の詳細については、ユーザーポリシーを使用したバケットへのアクセスの制御 を参照してください。
例えば、キー名が public/object1.jpg
および public/object2.jpg
である 2 つのオブジェクトがある場合、コンソールには public
フォルダ以下のオブジェクトが表示されます。Amazon S3 APIでは、これらはプレフィックスを持つオブジェクトとして扱われ、フォルダ内のオブジェクトとしては扱われません。ただし、Amazon S3 API でこのようなプレフィックスを使用してオブジェクトのキーを管理している場合は、s3:ListBucket
のアクセス許可の条件に s3:prefix
を付けて付与することで、この特定のプレフィックスの付いたキー名の一覧を取得することができます。
この例では、バケット所有者とユーザーが属する親アカウントは同一です。したがって、バケット所有者はバケットポリシーまたはユーザーポリシーのどちらでも使用することができます。GET Bucket (ListObjects) API で使用できるその他の条件キーの詳細については、ListObjects を参照してください。
ユーザーポリシー
以下のユーザーポリシーは、ユーザーがリクエストで s3:ListBucket
およびその値に を指定することを条件として、 のアクセス許可 (prefix
バケットの GET (ListObjects)projects
を参照) を付与します。
{ "Version":"2012-10-17", "Statement":[ { "Sid":"statement1", "Effect":"Allow", "Action": "s3:ListBucket", "Resource":"arn:aws:s3:::
awsexamplebucket1
", "Condition" : { "StringEquals" : { "s3:prefix": "projects" } } }, { "Sid":"statement2", "Effect":"Deny", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::awsexamplebucket1
", "Condition" : { "StringNotEquals" : { "s3:prefix": "projects" } } } ] }
この条件では、ユーザーの取得できるリストが projects
プレフィックスの付いているオブジェクトキーに限定されます。明示的な拒否を追加すると、ユーザーに付与されている他のアクセス許可に関係なしに、他のプレフィックスが付いたキーのリストを求めるユーザーのリクエストは拒否されます。例えば、以前のユーザーポリシーの更新やバケットポリシーにより、オブジェクトキーのリストを表示するアクセス許可がユーザーに制限なく付与される場合があります。明示的な拒否が常に優先されるため、プレフィックスが projects
以外のキーの表示を求めるユーザーのリクエストは拒否されます。
バケットポリシー
上記のユーザーポリシーに Principal
エレメントを追加して、ユーザーを指定する場合は、次のようにバケットポリシーを使用できます。
{ "Version":"2012-10-17", "Statement":[ { "Sid":"statement1", "Effect":"Allow", "Principal": { "AWS": "arn:aws:iam::
123456789012
:user/bucket-owner
" }, "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::awsexamplebucket1
", "Condition" : { "StringEquals" : { "s3:prefix": "projects" } } }, { "Sid":"statement2", "Effect":"Deny", "Principal": { "AWS": "arn:aws:iam::123456789012
:user/bucket-owner
" }, "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::awsexamplebucket1
", "Condition" : { "StringNotEquals" : { "s3:prefix": "projects" } } } ] }
AWS CLI でポリシーをテストする
このポリシーは、次の list-object
AWS CLI コマンドを使用してテストできます。このコマンドでは、--profile
パラメータを使用してユーザーの認証情報を指定します。AWS CLI のセットアップおよび使用の詳細については、AWS CLI を使用した Amazon S3 での開発 を参照してください。
aws s3api list-objects --bucket
awsexamplebucket1
--prefix examplefolder --profile AccountADave
バケットがバージョニングに対応している場合、バケット内のオブジェクトのリストを表示するには、s3:ListBucket
のアクセス許可ではなく、前述のポリシーの s3:ListBucketVersions
のアクセス許可を付与する必要があります。このアクセス許可は、s3:prefix
条件キーもサポートしています。
例 3: キーの最大数の設定
s3:max-keys
条件キーを使用すると、リクエスタがバケットの GET (ListObjects) または ListObjectVersions のリクエストで返すことができるキーの最大数を設定できます。デフォルトでは、API は最大 1,000 個のキーを返します。s3:max-keys
で使用できる数値条件演算子の一覧とその例については、IAM ユーザーガイドの数値条件演算子 を参照してください。