ACL(액세스 제어 목록) 개요 - Amazon Simple Storage Service

ACL(액세스 제어 목록) 개요

Amazon S3 ACL(액세스 제어 목록)로 버킷과 객체에 대한 액세스를 관리합니다. 각 버킷과 객체마다 하위 리소스로서 연결되어 있는 ACL이 있습니다. ACL은 액세스를 허용할 AWS 계정이나 그룹과 액세스 유형을 정의합니다. 리소스에 대한 요청을 수신하면, Amazon S3는 해당 ACL을 확인해 요청자가 필요한 액세스 권한을 보유하고 있는지 판단합니다.

S3 객체 소유권은 버킷에 업로드되는 객체의 소유권을 제어하고 ACL을 비활성화 또는 활성화하는 데 사용할 수 있는 Amazon S3 버킷 수준 설정입니다. 기본적으로 객체 소유권은 버킷 소유자 적용 설정으로 설정되며 모든 ACL이 비활성화되어 있습니다. ACL이 비활성화되면 버킷 소유자는 버킷의 모든 객체를 소유하고 액세스 관리 정책을 사용하여 객체에 대한 액세스를 독점적으로 관리합니다.

Amazon S3의 최신 사용 사례 대부분은 더 이상 ACL을 사용할 필요가 없습니다. 각 객체에 대해 액세스를 개별적으로 제어할 필요가 있는 드문 상황을 제외하고는 ACL을 비활성화한 채로 두는 것이 좋습니다. ACL을 비활성화하면 누가 객체를 버킷에 업로드했는지에 관계없이 정책을 사용하여 버킷의 모든 객체에 대한 액세스를 제어할 수 있습니다. 자세한 내용은 객체 소유권 제어 및 버킷에 대해 ACL 사용 중지 단원을 참조하십시오.

중요

버킷이 S3 객체 소유권에 대해 버킷 소유자 적용 설정을 사용하는 경우 정책을 사용하여 버킷과 버킷의 객체에 대한 액세스 권한을 부여해야 합니다. 버킷 소유자 적용 설정이 활성화된 상태에서 액세스 제어 목록(ACL) 설정 또는 ACL 업데이트 요청은 실패하고 AccessControlListNotSupported 오류 코드를 반환합니다. ACL 읽기 요청은 계속 지원됩니다.

버킷이나 객체를 생성하면 Amazon S3는 리소스에 대한 모든 권한을 리소스 소유자에게 부여하는 기본 ACL을 생성합니다. 이 정보는 다음 샘플 버킷 ACL(기본 객체 ACL도 동일한 구조)에 표시됩니다.

<?xml version="1.0" encoding="UTF-8"?> <AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <Owner> <ID>*** Owner-Canonical-User-ID ***</ID> <DisplayName>owner-display-name</DisplayName> </Owner> <AccessControlList> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Canonical User"> <ID>*** Owner-Canonical-User-ID ***</ID> <DisplayName>display-name</DisplayName> </Grantee> <Permission>FULL_CONTROL</Permission> </Grant> </AccessControlList> </AccessControlPolicy>

샘플 ACL에는 AWS 계정 정식 사용자 ID로 소유자를 식별하는 Owner 요소가 포함되어 있습니다. 정식 사용자 ID를 찾는 방법에 대한 자세한 내용은 AWS 계정 정식 사용자 ID 찾기을 참조하십시오. Grant 요소는 피부여자(AWS 계정 또는 미리 정의된 그룹)와 부여된 권한을 식별합니다. 이 기본 ACL에는 소유자에 대해 한 개의 Grant 요소가 있습니다. 각각 피부여자와 권한을 식별하는 Grant 요소를 추가해 권한을 부여합니다.

참고

ACL은 최고 100개의 권한을 부여할 수 있습니다.

피부여자란?

피부여자는 AWS 계정 또는 미리 정의된 Amazon S3 그룹 중 하나가 될 수 있습니다. AWS 계정의 이메일 주소나 정식 사용자 ID로 권한을 부여합니다. 단, 권한 요청에 이메일 주소를 적은 경우, Amazon S3에서 해당 계정의 정식 사용자 ID를 찾아서 ACL에 추가합니다. 결과 ACL에는 항상 AWS 계정의 이메일 주소가 아닌 AWS 계정의 정식 사용자 ID가 포함됩니다.

액세스 권한을 부여할 때 type="value" 쌍으로 각 피부여자를 지정합니다. 여기서 type은 다음 중 하나입니다.

  • id – 지정된 값이 AWS 계정의 정식 사용자 ID인 경우

  • uri – 미리 정의된 그룹에 권한을 부여하는 경우

  • emailAddress – 지정된 값이 AWS 계정의 이메일 주소인 경우

중요

피부여자를 지정하기 위해 이메일 주소를 사용하는 것은 다음 AWS 리전에서만 지원됩니다.

  • 미국 동부(버지니아 북부)

  • 미국 서부(캘리포니아 북부)

  • 미국 서부(오리건)

  • 아시아 태평양(싱가포르)

  • 아시아 태평양(시드니)

  • 아시아 태평양(도쿄)

  • 유럽(아일랜드)

  • 남아메리카(상파울루)

모든 Amazon S3 지원 리전 및 엔드포인트 목록은 Amazon Web Services 일반 참조에서 리전 및 엔드포인트를 참조하십시오.

예: 이메일 주소

예를 들어 다음 x-amz-grant-read 헤더는 이메일 주소로 식별된 AWS 계정에 객체 데이터와 메타데이터를 읽을 수 있는 권한을 부여합니다.

x-amz-grant-read: emailAddress="xyz@example.com", emailAddress="abc@example.com"
주의

다른 AWS 계정에 본인의 리소스 액세스를 허용하는 경우, AWS 계정이 자신의 계정에 속한 사용자에게 그 권한을 위임할 수도 있다는 사실을 염두에 두어야 합니다. 이것을 교차 계정 액세스라고 합니다. 교차 계정 액세스를 사용하는 자세한 방법은 IAM 사용 설명서에서 역할을 만들어 IAM 사용자에게 권한 위임 단원을 참조하십시오.

AWS 계정 정식 사용자 ID 찾기

정식 사용자 ID는 AWS 계정과 연결되어 있습니다. 이 ID는 다음과 같은 긴 문자열입니다.

79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be

계정의 표준 사용자 ID를 찾는 방법에 대한 자세한 내용은 AWS 계정 관리 참조 안내서의 AWS 계정의 표준 사용자 ID 찾기를 참조하세요.

AWS 계정에서 액세스 권한을 보유한 버킷이나 객체의 ACL을 확인해 AWS 계정의 정식 사용자 ID를 찾을 수도 있습니다. 권한 요청에 따라 개별 AWS 계정에 권한이 부여될 때, 권한 항목이 계정 정식 사용자 ID와 함께 ACL에 추가됩니다.

참고

버킷을 공개하면(권장하지 않음) 인증되지 않은 모든 사용자들이 그 버킷에 객체를 업로드할 수 있습니다. 이러한 익명의 사용자에게는 AWS 계정이 없습니다. 익명의 사용자가 귀하의 버킷에 객체를 업로드하면 Amazon S3는 ACL의 객체 소유자로서 특별한 정식 사용자 ID(65a011a29cdf8ec533ec3d1ccaae921c)를 추가합니다. 자세한 내용은 Amazon S3 버킷 및 객체 소유권 단원을 참조하십시오.

Amazon S3의 미리 정의된 그룹

Amazon S3에는 여러 개의 미리 정의된 그룹이 있습니다. 그룹에 계정 액세스를 허용하려면 정식 사용자 ID 대신 Amazon S3 URI 하나를 지정합니다. Amazon S3는 다음과 같은 미리 정의된 그룹을 제공합니다.

  • 인증된 사용자 그룹(Authenticated Users group)http://acs.amazonaws.com/groups/global/AuthenticatedUsers로 표시.

    이 그룹은 모든 AWS 계정에 있습니다. 이 그룹에 대한 액세스 권한은 모든 AWS 계정에 리소스 액세스를 허용합니다. 단, 모든 요청에는 서명을(인증) 해야 합니다.

    주의

    인증된 사용자 그룹에 액세스 권한을 부여하면 AWS 인증을 받은 전 세계 사용자가 리소스에 액세스할 수 있습니다.

  • 전체 사용자 그룹(All Users group)http://acs.amazonaws.com/groups/global/AllUsers로 표시.

    이 그룹의 액세스 권한으로 전 세계 누구나 리소스에 액세스할 수 있습니다. 요청에 서명을 할 수도(인증) 있고 하지 않을(익명) 수도 있습니다. 서명되지 않은 요청은 요청에 인증 헤더를 생략합니다.

    주의

    전체 사용자 그룹(All Users group) WRITE, WRITE_ACP 또는 FULL_CONTROL 권한을 부여하지 않는 것이 좋습니다. 예를 들어, WRITE 권한은 비소유자가 기존 객체를 덮어쓰거나 삭제하도록 허용하지 않지만, 여전히 WRITE 권한은 요금 청구를 받는 버킷에 모든 사람이 객체를 저장할 수 있도록 허용합니다. 이러한 권한에 대한 자세한 내용은 다음 부여할 수 있는 권한 단원을 참조하십시오.

  • 로그 전달 그룹(Log Delivery group)http://acs.amazonaws.com/groups/s3/LogDelivery로 표시.

    버킷 내 WRITE 권한으로 이 그룹은 버킷에 서버 액세스 로그를 쓸 수 있습니다(서버 액세스 로깅을 사용한 요청 로깅 참조).

참고

ACL을 사용하는 경우, 피부여자는 AWS 계정이나 미리 정의된 Amazon S3 그룹 중 하나가 됩니다. 하지만, IAM 사용자는 피부여자가 될 수 없습니다. AWS 사용자 및 IAM 내 권한에 대한 자세한 내용은 AWS Identity and Access Management 사용을 참조하십시오.

부여할 수 있는 권한

다음 표에는 ACL에서 Amazon S3가 지원하는 권한 목록이 나와 있습니다. ACL 권한 집합은 객체 ACL 및 버킷 ACL과 동일합니다. 단, 상황에 따라 이 ACL 권한(버킷 ACL이나 객체 ACL) 은 특정 버킷이나 객체 작업에 대한 권한을 부여하기도 합니다. 표에는 권한 목록이 나열되어 있으며 객체 및 버킷에 따른 권한에 대한 설명이 수록되어 있습니다.

Amazon S3 콘솔의 ACL 권한에 대한 자세한 내용은 ACL 구성 단원을 참조하십시오.

권한 버킷에 대한 권한을 부여하는 경우 객체에 대한 권한을 부여하는 경우
READ 피부여자에게 버킷의 객체 목록 생성을 허용합니다 피부여자에게 객체 데이터와 그 메타데이터를 읽도록 허용합니다
WRITE 피부여자가 버킷에서 새 객체를 생성할 수 있습니다. 기존 객체의 버킷 및 객체 소유자는 해당 객체의 삭제 및 덮어쓰기도 허용합니다. 해당 사항 없음
READ_ACP 피부여자에게 버킷 ACL 읽기를 허용합니다 피부여자에게 객체 ACL 읽기를 허용합니다
WRITE_ACP 피부여자에게 해당 버킷에 대한 ACL 쓰기를 허용합니다 피부여자에게 해당 객체에 대한 ACL 쓰기를 허용합니다
FULL_CONTROL 피부여자에게 버킷에 대한 READWRITEREAD_ACP 및 WRITE_ACP 권한 허용 피부여자에게 버킷에 대한 READREAD_ACP 및 WRITE_ACP 권한 허용
주의

S3 버킷과 객체에 액세스 권한을 부여할 때 주의하십시오. 예를 들어, 버킷에 WRITE 액세스 권한을 부여하면 피부여자가 버킷에서 객체를 생성할 수 있습니다. 권한을 부여하기 전에 이 ACL(액세스 제어 목록) 개요 섹션 전체를 잘 읽으시기 바랍니다.

ACL 권한과 액세스 정책 권한의 매핑

앞의 표에서와 같이, ACL은 액세스 정책에서 설정할 수 있는 권한 수와 비교해 유한한 권한 집합만 허용합니다(Amazon S3의 정책 작업 참조). 이러한 권한은 각각 한 개 이상의 Amazon S3 작업을 허용합니다.

다음 표는 각 ACL 권한이 어떻게 해당 액세스 정책 권한에 매핑되는지 보여줍니다. 보시다시피 액세스 정책은 ACL보다 많은 권한을 허용합니다. 주로 ACL을 사용하여 파일 시스템 권한과 유사한 기본 읽기/쓰기 권한을 부여합니다. ACL을 사용하는 경우에 대한 자세한 내용은 Amazon S3의 ID 및 액세스 관리을 참조하십시오.

Amazon S3 콘솔의 ACL 권한에 대한 자세한 내용은 ACL 구성 단원을 참조하십시오.

ACL 권한 버킷에 대한 ACL 권한 부여 시 해당 액세스 정책 권한 객체에 대한 ACL 권한 부여 시 해당 액세스 정책 권한
READ s3:ListBucket, s3:ListBucketVersionss3:ListBucketMultipartUploads s3:GetObjects3:GetObjectVersion
WRITE

s3:PutObject

버킷 소유자는 버킷의 모든 객체를 생성, 덮어쓰기 및 삭제할 수 있으며 객체 소유자는 객체에 대해 FULL_CONTROL을(를) 소유합니다.

또한, 피부여자가 버킷 소유자인 경우 버킷 ACL의 WRITE 권한을 부여해 해당 버킷의 어떤 버전에서든 s3:DeleteObjectVersion 작업의 수행할 수 있습니다.

해당 사항 없음
READ_ACP s3:GetBucketAcl s3:GetObjectAcls3:GetObjectVersionAcl
WRITE_ACP s3:PutBucketAcl s3:PutObjectAcls3:PutObjectVersionAcl
FULL_CONTROL READ, WRITE, READ_ACP, WRITE_ACP ACL 권한을 부여하는 것과 동일합니다. 따라서, 이 ACL 권한은 해당 액세스 정책 권한의 조합과 매핑됩니다. READ, READ_ACP, WRITE_ACP 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이 필요합니다.

ACL 관련 헤더를 포함하는 정책 예는 버킷 소유자가 전체 권한을 가져오도록 요구하는 조건으로 s3:PutObject 권한 부여을 참조하십시오. Amazon S3에 사용되는 조건 키의 전체 목록은 서비스 승인 참조에서 Amazon S3에 사용되는 작업, 리소스 및 조건 키를 참조하세요.

S3 리소스 유형별 S3 API 작업 권한에 대한 자세한 내용은 Amazon S3 API 작업에 필요한 권한 섹션을 참조하세요.

일반적인 Amazon S3 요청에 대한 aclRequired 값

인증을 위해 ACL이 필요한 Amazon S3 요청을 식별하려면, Amazon S3 서버 액세스 로그 또는 aclRequired 내의 AWS CloudTrail 값을 사용하면 됩니다. CloudTrail 또는 Amazon S3 서버 액세스 로그에 표시되는 aclRequired 값은 호출된 작업과 요청자, 객체 소유자 및 버킷 소유자에 대한 특정 정보에 따라 달라집니다. ACL이 필요하지 않았거나, bucket-owner-full-control 미리 제공된 ACL을 설정하고 있거나, 버킷 정책에 의해 요청이 허용되는 경우, Amazon S3 서버 액세스 로그에서 aclRequired 값 문자열은 "-"이며 CloudTrail에는 표시되지 않습니다.

다음 테이블에는 다양한 Amazon S3 API 작업에 대해 CloudTrail 또는 Amazon S3 서버 액세스 로그에서 예상되는 aclRequired 값이 나열되어 있습니다. 이 정보를 사용하여 어떤 Amazon S3 작업이 권한 부여를 위해 ACL에 의존하는지 파악할 수 있습니다. 다음 테이블에서 A, B, C는 요청자, 객체 소유자, 버킷 소유자와 연관된 서로 다른 계정을 나타냅니다. 별표(*)가 있는 항목은 계정 A, B 또는 C 중 하나를 나타냅니다.

참고

다음 테이블의 PutObject 작업은 달리 명시되지 않는 한, ACL이 bucket-owner-full-control ACL이 아닌 한, ACL을 설정하지 않은 요청을 나타냅니다. aclRequired에 대한 null 값은 AWS CloudTrail 로그에 aclRequired가 없음을 나타냅니다.

다음 테이블은 CloudTrail의 aclRequired 값을 보여줍니다.

작업 이름 요청자 객체 소유자 버킷 소유자 버킷 정책으로 액세스 권한 부여 aclRequired 이유
GetObject A A A [Yes] 또는 [No] null 동일한 계정 액세스
GetObject A B A [Yes] 또는 [No] 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 [Yes] 또는 [No] null 동일한 계정 액세스
PutObject A 해당 사항 없음 B null 버킷 정책에 의해 부여된 크로스 계정 액세스
PutObject A 해당 사항 없음 B 아니요 ACL에 의존하는 크로스 계정 액세스
ACL 포함된 PutObject(bucket-owner-full-control 제외) * 해당 사항 없음 * [Yes] 또는 [No] 요청 권한 부여 ACL
ListObjects A 해당 사항 없음 A [Yes] 또는 [No] null 동일한 계정 액세스
ListObjects A 해당 사항 없음 B null 버킷 정책에 의해 부여된 크로스 계정 액세스
ListObjects A 해당 사항 없음 B 아니요 ACL에 의존하는 크로스 계정 액세스
DeleteObject A 해당 사항 없음 A [Yes] 또는 [No] null 동일한 계정 액세스
DeleteObject A 해당 사항 없음 B null 버킷 정책에 의해 부여된 크로스 계정 액세스
DeleteObject A 해당 사항 없음 B 아니요 ACL에 의존하는 크로스 계정 액세스
PutObjectAcl * * * [Yes] 또는 [No] 요청 권한 부여 ACL
PutBucketAcl * 해당 사항 없음 * [Yes] 또는 [No] 요청 권한 부여 ACL

참고

다음 테이블의 REST.PUT.OBJECT 작업은 달리 명시되지 않는 한, ACL이 bucket-owner-full-control ACL이 아닌 한, ACL을 설정하지 않은 요청을 나타냅니다. aclRequired 값 문자열이 "-"인 경우 Amazon S3 서버 액세스 로그에서 null 값을 나타냅니다.

다음 테이블은 Amazon S3 서버 액세스 로그의 aclRequired 값을 보여줍니다.

작업 이름 요청자 객체 소유자 버킷 소유자 버킷 정책으로 액세스 권한 부여 aclRequired 이유
REST.GET.OBJECT A A A [Yes] 또는 [No] - 동일한 계정 액세스
REST.GET.OBJECT A B A [Yes] 또는 [No] - 버킷 소유자에게 적용된 동일 계정 액세스
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 [Yes] 또는 [No] - 동일한 계정 액세스
REST.PUT.OBJECT A 해당 사항 없음 B - 버킷 정책에 의해 부여된 크로스 계정 액세스
REST.PUT.OBJECT A 해당 사항 없음 B 아니요 ACL에 의존하는 크로스 계정 액세스
ACL 포함된 REST.PUT.OBJECT(bucket-owner-full-control 제외) * 해당 사항 없음 * [Yes] 또는 [No] 요청 권한 부여 ACL
REST.GET.BUCKET A 해당 사항 없음 A [Yes] 또는 [No] - 동일한 계정 액세스
REST.GET.BUCKET A 해당 사항 없음 B - 버킷 정책에 의해 부여된 크로스 계정 액세스
REST.GET.BUCKET A 해당 사항 없음 B 아니요 ACL에 의존하는 크로스 계정 액세스
REST.DELETE.OBJECT A 해당 사항 없음 A [Yes] 또는 [No] - 동일한 계정 액세스
REST.DELETE.OBJECT A 해당 사항 없음 B - 버킷 정책에 의해 부여된 크로스 계정 액세스
REST.DELETE.OBJECT A 해당 사항 없음 B 아니요 ACL에 의존하는 크로스 계정 액세스
REST.PUT.ACL * * * [Yes] 또는 [No] 요청 권한 부여 ACL

샘플 ACL

다음 샘플 버킷 ACL은 리소스 소유자와 권한 부여 집합을 식별합니다. 해당 형식은 Amazon S3 REST API에서 ACL의 XML 표시입니다. 버킷 소유자는 리소스의 FULL_CONTROL을 보유합니다. 또한, ACL은 이전 섹션에서 다룬 2가지 사전 정의된 Amazon S3 그룹과 정식 사용자 ID로 식별되는 2가지 AWS 계정에 리소스에 대한 권한을 부여하는 방법을 보여 줍니다.

<?xml version="1.0" encoding="UTF-8"?> <AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <Owner> <ID>Owner-canonical-user-ID</ID> <DisplayName>display-name</DisplayName> </Owner> <AccessControlList> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser"> <ID>Owner-canonical-user-ID</ID> <DisplayName>display-name</DisplayName> </Grantee> <Permission>FULL_CONTROL</Permission> </Grant> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser"> <ID>user1-canonical-user-ID</ID> <DisplayName>display-name</DisplayName> </Grantee> <Permission>WRITE</Permission> </Grant> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser"> <ID>user2-canonical-user-ID</ID> <DisplayName>display-name</DisplayName> </Grantee> <Permission>READ</Permission> </Grant> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group"> <URI>http://acs.amazonaws.com/groups/global/AllUsers</URI> </Grantee> <Permission>READ</Permission> </Grant> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group"> <URI>http://acs.amazonaws.com/groups/s3/LogDelivery</URI> </Grantee> <Permission>WRITE</Permission> </Grant> </AccessControlList> </AccessControlPolicy>

미리 제공된 ACL

Amazon S3는 미리 제공된 ACL이라고 하는 사전 정의된 권한 부여 집합을 지원합니다. 미리 제공된 각 ACL에는 사전정의된 피부여자와 권한 집합이 있습니다. 다음 표에는 미리 제공된 ACL 집합과 그에 연결된 사전정의된 권한 부여 목록이 있습니다.

미리 제공된 ACL 적용 대상 ACL에 추가된 권한
private 버킷과 객체 소유자는 FULL_CONTROL을 가집니다. 다른 누구도 액세스 권한이 없습니다(기본).
public-read 버킷과 객체 소유자는 FULL_CONTROL을 가집니다. AllUsers 그룹은(피부여자란? 참조) READ 액세스 권한을 가집니다.
public-read-write 버킷과 객체 소유자는 FULL_CONTROL을 가집니다. AllUsers 그룹은 READWRITE에 대한 액세스 권한을 가집니다. 버킷에 이를 허용하는 것은 일반적으로 권장하지 않습니다.
aws-exec-read 버킷과 객체 소유자는 FULL_CONTROL을 가집니다. Amazon EC2는 Amazon S3에서 Amazon Machine Image(AMI) 번들을 GET하기 위해 READ 액세스 권한을 가져옵니다.
authenticated-read 버킷과 객체 소유자는 FULL_CONTROL을 가집니다. AuthenticatedUsers 그룹은 READ 액세스 권한을 가집니다.
bucket-owner-read 객체 객체 소유자는 FULL_CONTROL을 가집니다. 버킷 소유자는 READ 액세스 권한을 가집니다. 버킷 생성 시 미리 제공된 이 ACL을 지정하면 Amazon S3는 이를 무시합니다.
bucket-owner-full-control 객체 객체 소유자와 버킷 소유자 모두 객체에 대해 FULL_CONTROL을 가집니다. 버킷 생성 시 미리 제공된 이 ACL을 지정하면 Amazon S3는 이를 무시합니다.
log-delivery-write 버킷 LogDelivery 그룹은 버킷에 대해 WRITEREAD_ACP 권한을 가집니다. 로그에 대한 자세한 내용은 서버 액세스 로깅을 사용한 요청 로깅 단원을 참조하십시오.
참고

이러한 미리 제공된 ACL은 요청에 하나만 지정할 수 있습니다.

x-amz-acl 요청 헤더를 사용하여 요청에 미리 제공된 ACL을 지정합니다. Amazon S3에서 미리 제공된 ACL이 포함된 요청을 수신하면, 사전 정의된 권한을 리소스 ACL에 추가합니다.