# アクセスコントロールリスト (ACL) の概要 Amazon S3 のアクセスコントロールリスト (ACL) では、バケットとオブジェクトへのアクセスを管理できます。各バケットとオブジェクトには、サブリソースとして ACL がアタッチされています。これにより、アクセスが許可される AWS アカウントまたはグループと、アクセスの種類が定義されます。リソースに対するリクエストを受け取ると、Amazon S3 は該当する ACL を確認して、リクエスタに必要なアクセス許可があることを確かめます。 S3 オブジェクト所有権は、Amazon S3 バケットレベルの設定で、バケットにアップロードされる新しいオブジェクト所有権を制御し、ACL を無効にするのに使用できます。デフォルトでは、オブジェクト所有権はバケット所有者の強制設定に設定され、すべての ACL は無効になります。ACL を無効にすると、バケット所有者はバケット内のすべてのオブジェクトを所有し、アクセス管理ポリシーのみを使用してデータへのアクセスを管理します。 Amazon S3 の最新のユースケースの大部分では ACL を使用する必要がなくなっています。オブジェクトごとに個別にアクセスを制御する必要がある状況を除き、ACL は無効にしておくことをお勧めします。ACL を無効にすると、誰がオブジェクトをバケットにアップロードしたかに関係なく、ポリシーを使用してバケット内のすべてのオブジェクトへのアクセスを制御できます。詳細については、「[オブジェクトの所有権の制御とバケットの ACL の無効化。](about-object-ownership.md)」を参照してください。 **重要** 汎用バケットで S3 のオブジェクト所有者に [バケット所有者の強制] 設定を使用する場合は、ポリシーを使用して汎用バケットとその中のオブジェクトへのアクセスを許可する必要があります。バケット所有者強制設定が有効になっている場合、アクセスコントロールリスト (ACL) の設定または ACL の更新は失敗し、`AccessControlListNotSupported` エラーコードが返されます。ACL の読み取り要求は引き続きサポートされています。 バケットまたはオブジェクトを作成すると、Amazon S3 はリソースのフルコントロールをリソースの所有者に付与するデフォルトの ACL を作成します。これを、以下のバケット ACL のサンプルで示します (デフォルトのオブジェクト ACL は同じ構造です)。 **Example** ``` 1. 2. 3. 4. *** Owner-Canonical-User-ID *** 5. 6. 7. 8. 10. *** Owner-Canonical-User-ID *** 11. 12. FULL_CONTROL 13. 14. 15. ``` サンプル ACL には、`Owner` の正規ユーザー ID を通じて所有者を識別する AWS アカウント エレメントが含まれています。正規ユーザー ID を見つける手順については、「[AWS アカウントの正規ユーザー ID の検索](#finding-canonical-id)」を参照してください。`Grant` エレメントは、被付与者 (AWS アカウント またはあらかじめ定義されたグループ) と付与されたアクセス許可を識別します。このデフォルトの ACL には、所有者に対する 1 つの `Grant` エレメントがあります。`Grant` エレメントを追加してアクセス許可を付与します。各許可は被付与者とアクセス許可を識別します。 **注記** 1 つの ACL には最大 100 個の許可を指定することができます。 **Topics** + [被付与者とは](#specifying-grantee) + [付与できるアクセス許可](#permissions) + [一般的な Amazon S3 リクエストの `aclRequired` 値](#aclrequired-s3) + [サンプル ACL](#sample-acl) + [既定 ACL](#canned-acl) ## 被付与者とは アクセス権限を付与する場合は、各被付与者を `type="value"` のペアとして指定します。`type` は以下のいずれかです。 + `id` – 指定された値が AWS アカウントの正規ユーザー ID である場合 + `uri` - 事前定義されたグループにアクセス許可を付与する場合 **警告** 他の AWS アカウントに自分のリソースへのアクセスを許可した場合、その AWS アカウントはアカウント内のユーザーに許可を委任できることに注意してください。これは*クロスアカウントアクセス*と呼ばれています。クロスアカウントアクセスの使用については、「[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)」の「*IAM ユーザーにアクセス許可を委任するロールの作成*」を参照してください。 ### AWS アカウントの正規ユーザー ID の検索 正規ユーザー ID は、AWS アカウントに関連付けられています。この ID は、次のような長い文字列です。 `79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be` アカウントの正規ユーザー ID を検索する方法については、「**AWS Account Management リファレンスガイド」の「[AWS アカウント の正規ユーザー ID を検索する](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html#FindCanonicalId)」を参照してください。 また、AWS アカウントがアクセス許可を持つバケットまたはオブジェクトの ACL を読み取って、AWS アカウントの正規ユーザー ID を検索することもできます。許可リクエストによって個別の AWS アカウントに許可が付与された場合、ACL にはアカウントの正規ユーザー ID が含まれた許可エントリが追加されます。 **注記** バケットをパブリックにした場合 (非推奨)、認証されていないどのユーザーもバケットにオブジェクトをアップロードできます。これらの匿名ユーザーは AWS アカウントを持っていません。匿名ユーザーがバケットにオブジェクトをアップロードすると、Amazon S3 によって特殊な正規ユーザー ID (`65a011a29cdf8ec533ec3d1ccaae921c`) がそのオブジェクトの所有者として ACL で追加されます。詳細については、「[Amazon S3 のバケットとオブジェクトの所有権](access-policy-language-overview.md#about-resource-owner)」を参照してください。 ### Amazon S3 の事前定義済みのグループ Amazon S3 には、事前定義済みの一連のグループがあります。グループにアカウントアクセスを許可するときは、正規ユーザー ID の代わりに Amazon S3 のいずれかの URI を指定します。Amazon S3 には、以下の事前に定義されたグループが用意されています。 + ****Authenticated Users グループ**** – `http://acs.amazonaws.com/groups/global/AuthenticatedUsers` で表されます。 このグループはすべて AWS アカウントを表しています。**このグループへのアクセス許可により、AWS アカウント がリソースにアクセスできます。**ただし、すべてのリクエストは署名(認証)されている必要があります。 **警告** **Authenticated Users グループ**にアクセスを許可すると、世界中の認証された AWS ユーザーがリソースにアクセスできます。 + ****All Users グループ**** – `http://acs.amazonaws.com/groups/global/AllUsers` で表されます。 **このグループへのアクセス許可により、世界中の誰でもリソースにアクセスすることが許可されます。**リクエストは署名(認証)済み、または署名なし(匿名)とすることができます。署名なしのリクエストでは、リクエストの Authentication ヘッダーが省略されます。 **警告** **All Users グループ**には、`WRITE`、`WRITE_ACP`、または `FULL_CONTROL` アクセス許可を一切付与しないことを強くお勧めします。例えば、`WRITE` アクセス許可は所有者以外のユーザーが既存のオブジェクトを上書きまたは削除することを許可しませんが、`WRITE` アクセス許可はすべてのユーザーがバケットにオブジェクトを格納することを許可し、この料金はお客様に請求されます。これらのアクセス許可の詳細については、次のセクション [付与できるアクセス許可](#permissions) を参照してください。 + ****Log Delivery グループ**** – `http://acs.amazonaws.com/groups/s3/LogDelivery` で表されます。 バケットに対する `WRITE` アクセス許可により、このグループはサーバーアクセスログ (「[サーバーアクセスログによるリクエストのログ記録](ServerLogs.md)」を参照) をバケットに書き込むことができます。 **注記** ACL を使用する場合、被付与者は AWS アカウントまたは事前定義済みのいずれかの Amazon S3 グループです。被付与者を IAM ユーザーとすることはできません。IAM 内の AWS ユーザーおよびアクセス許可の詳細については、「[AWS Identity and Access Management の使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/)」を参照してください。 ## 付与できるアクセス許可 以下の表に、Amazon S3 の ACL でサポートされている一連のアクセス許可を示します。ACL アクセス許可のセットは、オブジェクト ACL とバケット ACL で同じです。ただし、コンテキスト (バケット ACL かオブジェクト ACL か) に応じて、これらの ACL アクセス許可は特定のバケットまたはオブジェクトオペレーションのためのアクセス許可を付与します。この表では、アクセス許可の一覧と、オブジェクトとバケットにおけるその意味について説明しています。 Amazon S3 コンソールでの ACL アクセス権限の詳細については、「[ACL の設定](managing-acls.md)」を参照してください。 | アクセス許可 | バケット上で付与された場合 | オブジェクト上で付与された場合 | | --- | --- | --- | | READ | 被付与者がバケット内のオブジェクトをリストすることを許可します | 被付与者がオブジェクトデータとそのメタデータを読み込むことを許可します | | WRITE | 被付与者がバケット内に新しいオブジェクトを作成できるようにします。既存のオブジェクトのバケット所有者およびオブジェクト所有者には、これらのオブジェクトの削除と上書きも許可します。 | 該当しません | | READ\$1ACP | 被付与者がバケット ACL を読み込むことを許可します | 被付与者がオブジェクト ACL を読み込むことを許可します | | WRITE\$1ACP | 被付与者が該当するバケットの ACL を書き込むことを許可します | 被付与者が該当するオブジェクトの ACL を書き込むことを許可します | | FULL\$1CONTROL | バケットに対する READ、WRITE、READ\$1ACP、WRITE\$1ACP のアクセス許可を被付与者に付与します | オブジェクトに対する READ、READ\$1ACP、WRITE\$1ACP のアクセス許可を被付与者に付与します | **警告** S3 バケットとオブジェクトにアクセス許可を付与するときは注意が必要です。例えば、あるバケットに対する `WRITE` のアクセス権を付与すると、被付与者はそのバケットにオブジェクトを作成できます。アクセス許可を付与する前に、「[アクセスコントロールリスト (ACL) の概要](#acl-overview)」セクション全体を読むことを強くお勧めします。 ### ACL アクセス許可とアクセスポリシーのアクセス許可のマッピング 前の表に示したように、ACL で使用できるアクセス許可のセットは、アクセスポリシーで設定できるアクセス許可に比べると限定されています (「[Amazon S3 のポリシーアクション](security_iam_service-with-iam.md#security_iam_service-with-iam-id-based-policies-actions)」を参照してください)。これらのアクセス許可はそれぞれ、Amazon S3 の 1 つ以上のオペレーションを許可します。 次の表は、ACL アクセス権限のそれぞれが、対応するアクセスポリシーのアクセス許可にどのようにマッピングされるかを示します。ご覧のように、アクセスポリシーでは ACL よりも多くのアクセス許可が付与されています。ACL は主に、ファイルシステムのアクセス許可と同様に、基本的な読み取り/書き込みアクセス許可を付与するために使用されます。ACL の使用が適している場合の詳細については、[Amazon S3 用 Identity and Access Management](security-iam.md) を参照してください。 Amazon S3 コンソールでの ACL アクセス権限の詳細については、[ACL の設定](managing-acls.md) を参照してください。 | ACL アクセス許可 | ACL アクセス許可がバケットに付与される場合の、対応するアクセスポリシーのアクセス許可 | ACL アクセス許可がオブジェクトに付与される場合の、対応するアクセスポリシーのアクセス許可 | | --- | --- | --- | | READ | s3:ListBucket、s3:ListBucketVersions、および s3:ListBucketMultipartUploads | s3:GetObject および s3:GetObjectVersion | | WRITE | `s3:PutObject` バケット所有者は、バケット内の任意のオブジェクトを作成、上書き、削除でき、オブジェクト所有者はそのオブジェクトに対する `FULL_CONTROL` を有します。 さらに、被付与者がバケット所有者であるときは、バケットの ACL で `WRITE` アクセス許可を付与すると、そのバケット内の任意のバージョンに対して `s3:DeleteObjectVersion` アクションを実行できるようになります。 | 該当しません | | READ\$1ACP | s3:GetBucketAcl | s3:GetObjectAcl および s3:GetObjectVersionAcl | | WRITE\$1ACP | s3:PutBucketAcl | s3:PutObjectAcl および s3:PutObjectVersionAcl | | FULL\$1CONTROL | これは、READ、WRITE、READ\$1ACP、および WRITE\$1ACP ACL アクセス許可を付与するのと同等です。したがって、この ACL アクセス許可は、対応するアクセスポリシーのアクセス許可の組み合わせにマッピングされます。 | これは、READ、READ\$1ACP、および WRITE\$1ACP ACL アクセス許可を付与するのと同等です。したがって、この ACL アクセス許可は、対応するアクセスポリシーのアクセス許可の組み合わせにマッピングされます。 | ### 条件キー アクセスポリシー権限を付与する場合、条件キーを使用して、バケットポリシーを使用するオブジェクトの ACL の値を制限できます。以下のコンテキストキーは ACL に対応しています。これらのコンテキストキーを使用して、リクエストで特定の ACL の使用を強制することができます。 + `s3:x-amz-grant-read` ‐ 読み取りアクセスが必要です。 + `s3:x-amz-grant-write` ‐ 書き込みアクセスが必要です。 + `s3:x-amz-grant-read-acp` ‐ バケットの ACL への読み取りアクセスが必要です。 + `s3:x-amz-grant-write-acp` ‐ バケットの ACL への書き込みアクセスが必要です。 + `s3:x-amz-grant-full-control` ‐ フルコントロールが必要です。 + `s3:x-amz-acl` ‐ が必要です。[既定 ACL](#canned-acl) ACL 固有のヘッダーを含むポリシーの例については、「[バケット所有者にフルコントロールを与えることを条件として s3:PutObject のアクセス許可を付与する](example-bucket-policies-condition-keys.md#grant-putobject-conditionally-1)」を参照してください。Amazon S3 固有の条件キーの完全なリストについては、「サービス認可リファレンス」の「[Actions, resources, and condition keys for Amazon S3](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html)」を参照してください。** S3 リソースタイプ別の S3 API オペレーションへのアクセス許可の詳細については、「[Amazon S3 API オペレーションに必要なアクセス許可](using-with-s3-policy-actions.md)」を参照してください。 ## 一般的な Amazon S3 リクエストの `aclRequired` 値 承認に ACL を必要とした Amazon S3 リクエストを特定するには、Amazon S3 サーバーアクセスログまたは AWS CloudTrail の `aclRequired` 値を使用できます。CloudTrail または Amazon S3 サーバーアクセスログに表示される `aclRequired` 値は、呼び出されたオペレーションと、リクエスター、オブジェクト所有者、バケット所有者に関する特定の情報によって異なります。ACL が不要であったか、`bucket-owner-full-control` の既定 ACL を設定するか、リクエストがバケットポリシーで許可されている場合、`aclRequired` 値の文字列は Amazon S3 サーバーアクセスログでは「`-`」となり、CloudTrail では存在しません。 以下の表は、さまざまな Amazon S3 API オペレーションに対して CloudTrail または Amazon S3 サーバーアクセスログで期待される `aclRequired` 値を示しています。この情報から、どの Amazon S3 オペレーションが承認に関して ACL に依存しているかを理解できます。以下の表で、A、B、C は、リクエスター、オブジェクト所有者、バケット所有者と関連する各アカウントを表しています。アスタリスク (\$1) が付いているエントリは、A、B、C のうち、任意のアカウントを示します。 **注記** 次の表の `PutObject` オペレーションは、特に明記しない限り、ACL を設定しないリクエストを示します。ただし、ACL が `bucket-owner-full-control` ACL である場合を除きます。`aclRequired` の値が NULL の場合、`aclRequired` は AWS CloudTrail ログに存在しないことを示します。 次の表は、CloudTrail の `aclRequired` 値を示しています。 | オペレーション名 | リクエスタ | オブジェクト所有者 | バケット所有者 | バケットポリシーはアクセスを許可する | `aclRequired` 値 | Reason | | --- | --- | --- | --- | --- | --- | --- | | GetObject | A | A | A | はい/いいえ | null | 同一アカウントアクセス | | GetObject | A | B | A | はい/いいえ | null | 同一アカウントアクセス (バケット所有者の強制による) | | GetObject | A | A | B | はい | null | クロスアカウントアクセスがバケットポリシーで許可される | | GetObject | A | A | B | いいえ | あり | クロスアカウントアクセスは ACL に依存する | | GetObject | A | A | B | はい | null | クロスアカウントアクセスがバケットポリシーで許可される | | GetObject | A | B | B | いいえ | あり | クロスアカウントアクセスは ACL に依存する | | GetObject | A | B | C | はい | null | クロスアカウントアクセスがバケットポリシーで許可される | | GetObject | A | B | C | いいえ | あり | クロスアカウントアクセスは ACL に依存する | | PutObject | A | 該当しない | A | はい/いいえ | null | 同一アカウントアクセス | | PutObject | A | 該当しない | B | はい | null | クロスアカウントアクセスがバケットポリシーで許可される | | PutObject | A | 該当しない | B | いいえ | あり | クロスアカウントアクセスは ACL に依存する | | ACL による PutObject (bucket-owner-full-control を除く) | \$1 | 該当しない | \$1 | はい/いいえ | はい | リクエストは ACL を許可する | | ListObjects | A | 該当しない | A | はい/いいえ | null | 同一アカウントアクセス | | ListObjects | A | 該当しない | B | はい | null | クロスアカウントアクセスがバケットポリシーで許可される | | ListObjects | A | 該当しない | B | いいえ | あり | クロスアカウントアクセスは ACL に依存する | | DeleteObject | A | 該当しない | A | はい/いいえ | null | 同一アカウントアクセス | | DeleteObject | A | 該当しない | B | はい | null | クロスアカウントアクセスがバケットポリシーで許可される | | DeleteObject | A | 該当しない | B | いいえ | あり | クロスアカウントアクセスは ACL に依存する | | PutObjectAcl | \$1 | \$1 | \$1 | はい/いいえ | はい | リクエストは ACL を許可する | | PutBucketAcl | \$1 | 該当しない | \$1 | はい/いいえ | はい | リクエストは ACL を許可する | **注記** 次の表の `REST.PUT.OBJECT` オペレーションは、特に明記しない限り、ACL を設定しないリクエストを示します。ただし、ACL が `bucket-owner-full-control` ACL である場合を除きます。`aclRequired` 値の文字列「`-`」は、Amazon S3 サーバーアクセスログの NULL 値を示します。 次の表は、Amazon S3 サーバーアクセスログの `aclRequired` 値を示しています。 | オペレーション名 | リクエスタ | オブジェクト所有者 | バケット所有者 | バケットポリシーはアクセスを許可する | `aclRequired` 値 | Reason | | --- | --- | --- | --- | --- | --- | --- | | REST.GET.OBJECT | A | A | A | はい/いいえ | - | 同一アカウントアクセス | | REST.GET.OBJECT | A | B | A | はい/いいえ | - | 同一アカウントアクセス (バケット所有者の強制による) | | REST.GET.OBJECT | A | A | B | はい | - | クロスアカウントアクセスがバケットポリシーで許可される | | REST.GET.OBJECT | A | A | B | いいえ | あり | クロスアカウントアクセスは ACL に依存する | | REST.GET.OBJECT | A | B | B | はい | - | クロスアカウントアクセスがバケットポリシーで許可される | | REST.GET.OBJECT | A | B | B | いいえ | あり | クロスアカウントアクセスは ACL に依存する | | REST.GET.OBJECT | A | B | C | はい | - | クロスアカウントアクセスがバケットポリシーで許可される | | REST.GET.OBJECT | A | B | C | いいえ | あり | クロスアカウントアクセスは ACL に依存する | | REST.PUT.OBJECT | A | 該当しない | A | はい/いいえ | - | 同一アカウントアクセス | | REST.PUT.OBJECT | A | 該当しない | B | はい | - | クロスアカウントアクセスがバケットポリシーで許可される | | REST.PUT.OBJECT | A | 該当しない | B | いいえ | あり | クロスアカウントアクセスは ACL に依存する | | ACL による REST.PUT.OBJECT (bucket-owner-full-control を除く) | \$1 | 該当しない | \$1 | はい/いいえ | はい | リクエストは ACL を許可する | | REST.GET.BUCKET | A | 該当しない | A | はい/いいえ | - | 同一アカウントアクセス | | REST.GET.BUCKET | A | 該当しない | B | はい | - | クロスアカウントアクセスがバケットポリシーで許可される | | REST.GET.BUCKET | A | 該当しない | B | いいえ | あり | クロスアカウントアクセスは ACL に依存する | | REST.DELETE.OBJECT | A | 該当しない | A | はい/いいえ | - | 同一アカウントアクセス | | REST.DELETE.OBJECT | A | 該当しない | B | はい | - | クロスアカウントアクセスがバケットポリシーで許可される | | REST.DELETE.OBJECT | A | 該当しない | B | いいえ | あり | クロスアカウントアクセスは ACL に依存する | | REST.PUT.ACL | \$1 | \$1 | \$1 | はい/いいえ | はい | リクエストは ACL を許可する | ## サンプル ACL バケットの以下のサンプル ACL は、リソース所有者と一連の許可を識別します。形式は Amazon S3 REST API の ACL の XML 表現です。バケット所有者はリソースに対する `FULL_CONTROL` が許可されます。また、この ACL には、正規ユーザー ID で示されている 2 つの AWS アカウントと、前のセクションで説明した事前定義済みの 2 つの Amazon S3 グループに対して、リソースへの許可がどのように付与されるかが示されています。 **Example** ``` 1. 2. 3. 4. Owner-canonical-user-ID 5. 6. 7. 8. 9. Owner-canonical-user-ID 10. 11. FULL_CONTROL 12. 13. 14. 15. 16. user1-canonical-user-ID 17. 18. WRITE 19. 20. 21. 22. 23. user2-canonical-user-ID 24. 25. READ 26. 27. 28. 29. 30. http://acs.amazonaws.com/groups/global/AllUsers 31. 32. READ 33. 34. 35. 36. http://acs.amazonaws.com/groups/s3/LogDelivery 37. 38. WRITE 39. 40. 41. 42. ``` ## 既定 ACL Amazon S3 では、*既定 ACL* と呼ばれる事前定義済みの一連の許可がサポートされています。各既定 ACL には、あらかじめ定義された一連の被付与者とアクセス権限が含まれています。以下の表に、一連の既定 ACL と、関連するあらかじめ定義された許可を示します。 | 既定 ACL | Applies to | ACL に追加されるアクセス許可 | | --- | --- | --- | | private | バケットとオブジェクト | 所有者は FULL\$1CONTROL を取得します。他のユーザーにはアクセス許可は付与されません (デフォルト)。 | | public-read | バケットとオブジェクト | 所有者は FULL\$1CONTROL を取得します。AllUsers グループ ([被付与者とは](#specifying-grantee) を参照) は READ アクセス許可を取得します。 | | public-read-write | バケットとオブジェクト | 所有者は FULL\$1CONTROL を取得します。AllUsers グループは READ および WRITE アクセス許可を取得します。通常、これをバケットで付与することはお勧めしません。 | | aws-exec-read | バケットとオブジェクト | 所有者は FULL\$1CONTROL を取得します。Amazon EC2 には、Amazon S3 から Amazon マシンイメージ (AMI) バンドルを READ するための GET アクセスが許可されます。 | | authenticated-read | バケットとオブジェクト | 所有者は FULL\$1CONTROL を取得します。AuthenticatedUsers グループは READ アクセス許可を取得します。 | | bucket-owner-read | オブジェクト | オブジェクト所有者は FULL\$1CONTROL を取得します。バケット所有者は READ を取得します。バケットの作成時にこの既定 ACL を指定しても、Amazon S3 には無視されます。 | | bucket-owner-full-control | オブジェクト | オブジェクト所有者とバケット所有者はオブジェクトに対する FULL\$1CONTROL を取得します。バケットの作成時にこの既定 ACL を指定しても、Amazon S3 には無視されます。 | | log-delivery-write | バケット | LogDelivery グループはバケットに対する WRITE および READ\$1ACP アクセス許可を取得します。ログの詳細については、[サーバーアクセスログによるリクエストのログ記録](ServerLogs.md) を参照してください。 | **注記** リクエストではこれらの既定 ACL を 1 つのみ指定できます。 `x-amz-acl` リクエストヘッダーを使用して、リクエストに既定 ACL を指定します。Amazon S3 が既定 ACL を含むリクエストを受信すると、あらかじめ定義された許可がリソースの ACL に追加されます。