메뉴
Amazon Simple Storage Service
개발자 안내서 (API Version 2006-03-01)

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

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

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

Copy
<?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 요소가 포함됩니다. Grant 요소는 피부여자(AWS 계정 또는 미리 정의된 그룹)와 부여된 권한을 식별합니다. 이 기본 ACL에는 소유자에 대해 한 개의 Grant 요소가 있습니다. 각각 피부여자와 권한을 식별하는 Grant 요소를 추가해 권한을 부여합니다.

참고

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

피부여자란?

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

중요

2014/12/8 이후 생성된 모든 AWS 리전에 대해서는 피부여자 지정 시 이메일 주소를 사용할 수 없습니다. 다음 리전은 2014년 12월 8일 이후에 생성되었습니다. 미국 동부(오하이오), 캐나다(중부), 아시아 태평양(뭄바이), 아시아 태평양(서울), EU(프랑크푸르트), EU(런던), 중국(베이징) 및 AWS GovCloud (US) 리전.

AWS 계정 정식 사용자 ID 찾기

정식 사용자 ID는 AWS 계정과 연결되어 있습니다. AWS 계정의 루트 자격 증명을 사용하여 AWS Management Console에 로그인한 경우에만 정식 사용자 ID를 가져올 수 있습니다. 다른 자격 증명은 사용할 수 없습니다. 예를 들어 이 ID를 가져오기 위해 IAM 사용자 또는 연합된 사용자 자격 증명을 사용할 수 없습니다. 보안 자격 증명에 대한 자세한 내용은 보안 자격 증명을 얻는 방법을 참조하십시오.

AWS 계정의 정식 사용자 ID를 찾으려면

  1. https://aws.amazon.com/console에서 AWS Management Console에 로그인합니다. 이때 AWS 루트 자격 증명을 사용합니다(IAM 또는 연합된 사용자 자격 증명을 사용해서는 안 됩니다).

  2. 보안 자격 증명을 참조하십시오.

  3. [Account Identifiers] 섹션에서 AWS 계정과 연결된 정식 사용자 ID를 찾습니다.

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

Amazon S3의 미리 정의된 그룹

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

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

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

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

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

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

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

참고

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

참고

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

부여할 수 있는 권한

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

권한 버킷에 대한 권한을 부여하는 경우 객체에 대한 권한을 부여하는 경우
READ 피부여자에게 버킷의 객체 목록 생성을 허용합니다 피부여자에게 객체 데이터와 그 메타데이터를 읽도록 허용합니다
WRITE 피부여자에게 버킷에 속한 객체의 생성, 덮어쓰기, 삭제를 허용합니다 해당 사항 없음
READ_ACP 피부여자에게 버킷 ACL 읽기를 허용합니다 피부여자에게 객체 ACL 읽기를 허용합니다
WRITE_ACP 피부여자에게 해당 버킷에 대한 ACL 쓰기를 허용합니다 피부여자에게 해당 객체에 대한 ACL 쓰기를 허용합니다
FULL_CONTROL 피부여자에게 버킷에 대한 WRITE, READ, READ_ACP, WRITE_ACP 권한을 허용합니다. 피부여자에게 객체에 대한 읽기, 쓰기, READ_ACP, WRITE_ACP 권한을 허용합니다

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

앞의 표에서와 같이, ACL은 액세스 정책에서 설정할 수 있는 권한 수와 비교해 유한한 권한 집합만 허용합니다(정책에서 권한 지정 참조). 이러한 권한은 각각 한 개 이상의 Amazon S3 작업을 허용합니다. 다음 표는 각 ACL 권한이 어떻게 해당 액세스 정책 권한과 매핑되는지 보여 줍니다. 표에 나타난 바와 같이, 액세스 정책은 ACL보다 더 많은 권한을 허용하며 ACL로 파일 시스템 권한과 유사한 기본적인 읽기/쓰기 권한을 주로 부여합니다. ACL을 사용하는 경우에 대한 자세한 내용은 제공되는 액세스 정책 옵션 사용 지침을 참조하십시오.

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

s3:PutObjects3:DeleteObject.

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

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

샘플 ACL

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

Copy
<?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 머신 이미지(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에 추가합니다.

ACL 지정 방법

Amazon S3 API로 버킷이나 객체 생성 시 ACL을 설정할 수 있습니다. Amazon S3는 기존 버킷이나 객체에 ACL을 설정하는 API도 제공합니다. 이러한 API는 다음과 같은 ACL 설정 메서드를 제공합니다.

  • 요청 헤더를 사용한 ACL 설정 - 리소스(버킷이나 객체) 생성 요청 전송 시, 요청 헤더로 ACL을 설정합니다. 이러한 헤더를 사용하여 미리 제공된 ACL을 지정하거나 권한을 명시적으로 지정(명시적으로 피부여자와 권한을 식별)할 수 있습니다.

  • 요청 본문을 사용한 ACL 설정 - 기존 리소스에 대한 ACL 설정 요청을 전송 시, 요청 헤더나 본문에 ACL을 설정할 수 있습니다.

자세한 내용은 ACL 관리를 참조하십시오.