ACL のポリシーの例
バケットポリシーで条件キーを使用して、Amazon S3 へのアクセスをコントロールできます。
トピック
バケット所有者にフルコントロールを与えることを条件として 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 のセットアップと使用の詳細については、「Amazon S3 API リファレンス」の「Developing with Amazon S3 using the AWS CLI」を参照してください。
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
x-amz-acl ヘッダーの条件を使用した s3:PutObject アクセス許可の付与
以下のバケットポリシーは、オブジェクトをパブリックに読み取り可能にする x-amz-acl
ヘッダーがリクエストに含まれている場合に、2 つの AWS アカウントに s3:PutObject
の許可を付与します。Condition
ブロックでは、StringEquals
条件を使用し、キーと値のペアとして "s3:x-amz-acl":["public-read"]
を評価に使用できます。このキーと値のペアで、s3:x-amz-acl
は、「s3:
」というプレフィックスが示すとおり Amazon S3 固有のキーです。
{ "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:::awsexamplebucket1
/*"], "Condition": { "StringEquals": { "s3:x-amz-acl":["public-read"] } } } ] }
重要
すべての条件が、すべてのアクションに対して意味を成すわけではありません。例えば、Amazon S3 の s3:CreateBucket
のアクセス許可を付与するポリシーに条件として s3:LocationConstraint
を含めることは理にかなっています。ただし、この条件を s3:GetObject
のアクセス許可を付与するポリシーに含めることは意味がありません。Amazon S3 では、このような Amazon S3 固有の条件を含むセマンティックエラーをテストすることができます。ただし、IAM ユーザーまたはロールのポリシーを作成し、意味的に無効な Amazon S3 条件を含めても、IAM は Amazon S3 条件を検証できないため、エラーは報告されません。