ACL のポリシーの例 - Amazon Simple Storage Service

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 のセットアップおよび使用の詳細については、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

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 条件を検証できないため、エラーは報告されません。