Amazon S3의 액세스 거부(403 Forbidden) 오류 문제 해결

Amazon S3의 액세스 거부(403 Forbidden) 오류 문제 해결 (Troubleshoot access denied (403 Forbidden) errors in Amazon S3)

액세스 거부(HTTP 403 Forbidden) 오류는 AWS가 인가 요청을 명시적으로 또는 암시적으로 거부할 때 나타나요.

출처: 문서

본문

  • 명시적 거부(explicit denial) 는 정책에 특정 AWS 작업에 대한 Deny 문이 있을 때 발생해요.
  • 암시적 거부(implicit denial) 는 적용되는 Deny 문이 없고 적용되는 Allow 문도 없을 때 발생해요.

AWS Identity and Access Management(IAM) 정책은 기본적으로 IAM 보안 주체를 암시적으로 거부하므로, 정책은 보안 주체가 작업을 수행하도록 명시적으로 허용해야 해요. 그렇지 않으면 정책이 접근을 암시적으로 거부해요. 자세한 내용은 IAM User Guide의 명시적 거부와 암시적 거부의 차이를 참고하세요. 접근 요청이 허용되는지 거부되는지 판단하는 정책 평가 로직에 대한 정보는 IAM User Guide의 정책 평가 로직을 참고하세요.

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

다음 주제들은 Amazon S3에서 액세스 거부 오류의 가장 흔한 원인을 다뤄요.

참고 — 액세스 거부(HTTP 403 Forbidden) 오류의 경우, 요청이 버킷 소유자의 개별 AWS 계정이나 버킷 소유자의 AWS 조직 밖에서 시작됐다면 Amazon S3는 버킷 소유자에게 요금을 부과하지 않아요.

액세스 거부 메시지 예시와 문제 해결 방법

Amazon S3는 이제 동일한 AWS 계정이나 AWS Organizations의 동일한 조직 내 리소스에 대한 요청에 대해 액세스 거부(HTTP 403 Forbidden) 오류에 추가 컨텍스트를 포함해요. 이 컨텍스트에는 접근을 거부한 정책의 유형, 거부 이유, 리소스에 접근을 요청한 IAM 사용자나 역할에 대한 정보가 포함돼요.

이 추가 컨텍스트를 통해 접근 문제를 해결하고, 액세스 거부 오류의 근본 원인을 파악하고, 관련 정책을 업데이트해 잘못된 접근 제어를 고칠 수 있어요. 이 추가 컨텍스트는 AWS CloudTrail 로그에서도 확인할 수 있어요. 동일 계정 또는 동일 조직 요청에 대한 강화된 액세스 거부 오류 메시지는 AWS GovCloud(US) 리전과 중국 리전을 포함한 모든 AWS 리전에서 사용할 수 있어요.

명시적 거부의 경우 오류 메시지에는 요청을 거부한 특정 정책의 Amazon 리소스 이름(ARN)도 포함돼요. 이 정책 ARN으로 거부 원인이 된 정확한 정책을 빠르게 찾아 그 정책으로 직접 이동해 필요한 변경을 할 수 있어요. 오류 메시지에는 서비스 제어 정책(SCP), 리소스 제어 정책(RCP), 자격 증명 기반 정책, 세션 정책, 권한 경계의 정책 ARN이 포함돼요.

대부분의 액세스 거부 오류 메시지는 User user-arn is not authorized to perform action on "resource-arn" because context 형식으로 나타나요. 이 예시에서 user-arn은 접근을 받지 못하는 사용자의 ARN이고, action은 정책이 거부하는 서비스 작업이며, resource-arn은 정책이 적용되는 리소스의 ARN이에요. context 필드는 왜 정책이 접근을 거부했는지 설명하는 정책 유형에 대한 추가 컨텍스트를 나타내요.

정책에 Deny 문이 있어서 정책이 접근을 명시적으로 거부하면, 액세스 거부 오류 메시지에는 with an explicit deny in a type policy라는 구절과 요청을 거부한 특정 정책의 ARN이 포함돼요. 정책이 접근을 암시적으로 거부하면, 액세스 거부 오류 메시지에는 because no type policy allows the action action이라는 구절이 포함돼요.

중요 — 강화된 액세스 거부 메시지는 동일 계정 요청이나 AWS Organizations의 동일 조직 내 요청에만 반환돼요. 같은 조직 밖의 계정 간 요청은 일반적인 Access Denied 메시지를 반환해요.

계정 간 접근 요청이 허용되는지 거부되는지 판단하는 정책 평가 로직에 대한 정보는 IAM User Guide의 계정 간 정책 평가 로직을 참고하세요. 계정 간 접근을 부여하는 방법을 보여주는 연습은 예제 2: 버킷 소유자가 계정 간 버킷 권한 부여하기를 참고하세요.

AWS Organizations의 동일 조직 내 요청의 경우:

  • 가상 사설 클라우드(VPC) 엔드포인트 정책 때문에 거부가 발생하면 강화된 액세스 거부 메시지가 반환되지 않아요.
  • 버킷 소유자와 호출자 계정이 둘 다 AWS Organizations의 같은 조직에 속하면 강화된 액세스 거부 메시지가 제공돼요. S3 Object Ownership 버킷 소유자 선호(Bucket owner preferred) 또는 객체 작성자(Object writer) 설정으로 구성된 버킷이 다른 계정이 소유한 객체를 포함할 수는 있지만, 객체 소유권은 강화된 액세스 거부 메시지에 영향을 주지 않아요. 버킷 소유자와 호출자가 같은 조직에 있는 한, 특정 객체를 누가 소유했는지와 관계없이 모든 객체 요청에 대해 강화된 액세스 거부 메시지가 반환돼요. Object Ownership 설정과 구성에 대한 정보는 버킷의 객체 소유권 제어와 ACL 비활성화를 참고하세요.
  • 디렉터리 버킷에 대한 요청에는 강화된 액세스 거부 오류 메시지가 반환되지 않아요. 디렉터리 버킷 요청은 일반적인 Access Denied 메시지를 반환해요.
  • 같은 정책 유형의 여러 정책이 인가 요청을 거부하면, 액세스 거부 오류 메시지는 정책 수를 지정하지 않아요.
  • 명시적 거부의 경우 오류 메시지에는 요청을 거부한 특정 정책의 ARN이 포함돼요. 이는 서비스 제어 정책(SCP), 리소스 제어 정책(RCP), 자격 증명 기반 정책, 세션 정책, 권한 경계에 적용돼요.
  • 여러 정책 유형이 인가 요청을 거부하면, 오류 메시지에는 그 정책 유형 중 하나만 포함돼요.
  • 여러 가지 이유로 접근 요청이 거부되면, 오류 메시지에는 거부 이유 중 하나만 포함돼요.

다음 예시는 다양한 유형의 액세스 거부 오류 메시지 형식과 각 메시지 유형의 문제 해결 방법을 보여줘요.

차단된 암호화 유형(Blocked Encryption Type)으로 인한 액세스 거부

일반용 버킷에서 사용할 수 있는 서버 측 암호화 유형을 제한하려면 버킷의 기본 암호화 구성을 업데이트해 SSE-C 쓰기 요청을 차단할 수 있어요. 이 버킷 수준 구성은 SSE-C를 지정하는 객체 업로드 요청을 차단해요. 버킷에 대해 SSE-C가 차단되면 SSE-C 암호화를 지정하는 모든 PutObject, CopyObject, PostObject, 멀티파트 업로드 또는 복제 요청이 HTTP 403 AccessDenied 오류로 거부돼요.

이 설정은 PutBucketEncryption API의 파라미터이며, s3:PutEncryptionConfiguration 권한이 있으면 S3 콘솔, AWS CLI, AWS SDK로도 업데이트할 수 있어요. 유효한 값은 SSE-C(일반용 버킷에 대해 SSE-C 암호화 차단)와 NONE(버킷에 대한 쓰기에서 SSE-C 사용 허용)이에요.

예를 들어 BlockedEncryptionTypes 설정이 SSE-C를 지정하는 쓰기 요청을 차단해서 PutObject 요청이 거부되면 다음 메시지를 받아요.

An error occurred (AccessDenied) when calling the PutObject operation:   
User: arn:aws:iam::123456789012:user/MaryMajor  is not   
authorized to perform: s3:PutObject on resource:   
"arn:aws:s3:::amzn-s3-demo-bucket1/object-name" because this   
bucket has blocked upload requests that specify   
Server Side Encryption with Customer provided keys (SSE-C).   
Please specify a different server-side encryption type

이 설정에 대한 자세한 내용은 일반용 버킷에 대해 SSE-C 차단 또는 해제를 참고하세요.

리소스 제어 정책으로 인한 액세스 거부 – 명시적 거부

리소스 제어 정책(RCP)에서 작업에 대한 명시적 Deny 문이 있는지 확인하세요. 오류 메시지에는 정책 ARN이 포함되므로, 이를 사용해 요청을 거부한 정책을 찾아 직접 이동할 수 있어요. 다음 예시에서 작업은 s3:GetObject예요.

Deny 문을 제거해 RCP를 업데이트하세요. 자세한 내용은 AWS Organizations User Guide의 리소스 제어 정책(RCP) 업데이트를 참고하세요.

An error occurred (AccessDenied) when calling the GetObject operation: 
User: arn:aws:iam::777788889999:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" 
with an explicit deny in a resource control policy, with policy ARN: 
arn:aws:organizations::777788889999:policy/o-exampleorgid/resource_control_policy/p-examplepolicyid

서비스 제어 정책으로 인한 액세스 거부 – 암시적 거부

서비스 제어 정책(SCP)에서 작업에 대한 Allow 문이 없는지 확인하세요. 다음 예시에서 작업은 s3:GetObject예요.

Allow 문을 추가해 SCP를 업데이트하세요. 자세한 내용은 AWS Organizations User Guide의 SCP 업데이트를 참고하세요.

User: arn:aws:iam::777788889999:user/MaryMajor is not authorized to perform:
s3:GetObject because no service control policy allows the s3:GetObject action

서비스 제어 정책으로 인한 액세스 거부 – 명시적 거부

서비스 제어 정책(SCP)에서 작업에 대한 명시적 Deny 문이 있는지 확인하세요. 오류 메시지에는 정책 ARN이 포함되므로, 이를 사용해 요청을 거부한 정책을 찾아 직접 이동할 수 있어요. 다음 예시에서 작업은 s3:GetObject예요.

사용자에게 필요한 접근을 허용하도록 Deny 문을 변경해 SCP를 업데이트하세요. 방법의 예시는 GitHub의 서비스 제어 정책 예시를 참고하세요. SCP 업데이트에 대한 자세한 내용은 AWS Organizations User Guide의 SCP 업데이트를 참고하세요.

User: arn:aws:iam::777788889999:user/MaryMajor is not authorized to perform: 
s3:GetObject with an explicit deny in a service control policy, with policy ARN: 
arn:aws:organizations::777788889999:policy/o-exampleorgid/service_control_policy/p-examplepolicyid

VPC 엔드포인트 정책으로 인한 액세스 거부 – 암시적 거부

가상 사설 클라우드(VPC) 엔드포인트 정책에서 작업에 대한 Allow 문이 없는지 확인하세요. 다음 예시에서 작업은 s3:GetObject예요.

Allow 문을 추가해 VPC 엔드포인트 정책을 업데이트하세요. 자세한 내용은 AWS PrivateLink Guide의 VPC 엔드포인트 정책 업데이트를 참고하세요.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject because no VPC endpoint policy allows the s3:GetObject action

VPC 엔드포인트 정책으로 인한 액세스 거부 – 명시적 거부

가상 사설 클라우드(VPC) 엔드포인트 정책에서 작업에 대한 명시적 Deny 문이 있는지 확인하세요. 다음 예시에서 작업은 s3:GetObject예요.

사용자에게 필요한 접근을 허용하도록 Deny 문을 변경해 VPC 엔드포인트 정책을 업데이트하세요. 예를 들어 조건 연산자 StringNotEquals와 함께 aws:PrincipalAccount 조건 키를 사용하도록 Deny 문을 업데이트해 특정 보안 주체에게 접근을 허용할 수 있어요(예시 7: Deny 문에서 특정 보안 주체 제외 참고). VPC 엔드포인트 정책 업데이트에 대한 자세한 내용은 AWS PrivateLink Guide의 VPC 엔드포인트 정책 업데이트를 참고하세요.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with 
an explicit deny in a VPC endpoint policy

권한 경계로 인한 액세스 거부 – 암시적 거부

권한 경계에서 작업에 대한 Allow 문이 없는지 확인하세요. 다음 예시에서 작업은 s3:GetObject예요.

IAM 정책에 Allow 문을 추가해 권한 경계를 업데이트하세요. 자세한 내용은 IAM User Guide의 IAM 엔터티용 권한 경계와 IAM 정책 편집을 참고하세요.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" 
because no permissions boundary allows the s3:GetObject action

권한 경계로 인한 액세스 거부 – 명시적 거부

권한 경계에서 작업에 대한 명시적 Deny 문이 있는지 확인하세요. 오류 메시지에는 정책 ARN이 포함되므로, 이를 사용해 요청을 거부한 정책을 찾아 직접 이동할 수 있어요. 다음 예시에서 작업은 s3:GetObject예요.

사용자에게 필요한 접근을 허용하도록 IAM 정책의 Deny 문을 변경해 권한 경계를 업데이트하세요. 예를 들어 조건 연산자 StringNotEquals와 함께 aws:PrincipalAccount 조건 키를 사용하도록 Deny 문을 업데이트해 특정 보안 주체에게 접근을 허용할 수 있어요(IAM User Guide의 aws:PrincipalAccount 참고). 자세한 내용은 IAM User Guide의 IAM 엔터티용 권한 경계와 IAM 정책 편집을 참고하세요.

User: arn:aws:iam::777788889999:user/MaryMajor is not authorized to perform: 
s3:GetObject with an explicit deny in a permissions boundary, with policy ARN: 
arn:aws:iam::777788889999:policy/ExamplePermissionsBoundaryPolicy

세션 정책으로 인한 액세스 거부 – 암시적 거부

세션 정책에서 작업에 대한 Allow 문이 없는지 확인하세요. 다음 예시에서 작업은 s3:GetObject예요.

Allow 문을 추가해 세션 정책을 업데이트하세요. 자세한 내용은 IAM User Guide의 세션 정책과 IAM 정책 편집을 참고하세요.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject because no session policy allows the s3:GetObject action

세션 정책으로 인한 액세스 거부 – 명시적 거부

세션 정책에서 작업에 대한 명시적 Deny 문이 있는지 확인하세요. 오류 메시지에는 정책 ARN이 포함되므로, 이를 사용해 요청을 거부한 정책을 찾아 직접 이동할 수 있어요. 다음 예시에서 작업은 s3:GetObject예요.

사용자에게 필요한 접근을 허용하도록 Deny 문을 변경해 세션 정책을 업데이트하세요. 예를 들어 조건 연산자 StringNotEquals와 함께 aws:PrincipalAccount 조건 키를 사용하도록 Deny 문을 업데이트해 특정 보안 주체에게 접근을 허용할 수 있어요(예시 7: Deny 문에서 특정 보안 주체 제외 참고). 세션 정책 업데이트에 대한 자세한 내용은 IAM User Guide의 세션 정책과 IAM 정책 편집을 참고하세요.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with 
an explicit deny in a session policy, with policy ARN: 
arn:aws:iam::123456789012:policy/ExampleSessionPolicy

리소스 기반 정책으로 인한 액세스 거부 – 암시적 거부

참고 — 리소스 기반 정책이란 버킷 정책과 액세스 포인트 정책 같은 정책을 말해요.

리소스 기반 정책에서 작업에 대한 Allow 문이 없는지 확인하세요. 또한 IgnorePublicAcls S3 Block Public Access 설정이 버킷, 액세스 포인트 또는 계정 수준에서 적용됐는지도 확인하세요. 다음 예시에서 작업은 s3:GetObject예요.

Allow 문을 추가해 정책을 업데이트하세요. 자세한 내용은 IAM User Guide의 리소스 기반 정책과 IAM 정책 편집을 참고하세요.

버킷, 액세스 포인트 또는 계정의 IgnorePublicAcls 공개 액세스 차단 설정을 조정해야 할 수도 있어요. 자세한 내용은 Block Public Access 설정으로 인한 액세스 거부와 S3 버킷용 block public access 설정 구성을 참고하세요.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject because no resource-based policy allows the s3:GetObject action

리소스 기반 정책으로 인한 액세스 거부 – 명시적 거부

참고 — 리소스 기반 정책이란 버킷 정책과 액세스 포인트 정책 같은 정책을 말해요.

리소스 기반 정책에서 작업에 대한 명시적 Deny 문이 있는지 확인하세요. 또한 RestrictPublicBuckets S3 Block Public Access 설정이 버킷, 액세스 포인트 또는 계정 수준에서 적용됐는지도 확인하세요. 다음 예시에서 작업은 s3:GetObject예요.

사용자에게 필요한 접근을 허용하도록 Deny 문을 변경해 정책을 업데이트하세요. 예를 들어 조건 연산자 StringNotEquals와 함께 aws:PrincipalAccount 조건 키를 사용하도록 Deny 문을 업데이트해 특정 보안 주체에게 접근을 허용할 수 있어요(예시 7: Deny 문에서 특정 보안 주체 제외 참고). 리소스 기반 정책 업데이트에 대한 자세한 내용은 IAM User Guide의 리소스 기반 정책과 IAM 정책 편집을 참고하세요.

버킷, 액세스 포인트 또는 계정의 RestrictPublicBuckets 공개 액세스 차단 설정을 조정해야 할 수도 있어요. 자세한 내용은 Block Public Access 설정으로 인한 액세스 거부와 S3 버킷용 block public access 설정 구성을 참고하세요.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with 
an explicit deny in a resource-based policy

자격 증명 기반 정책으로 인한 액세스 거부 – 암시적 거부

자격 증명에 연결된 자격 증명 기반 정책에서 작업에 대한 Allow 문이 없는지 확인하세요. 다음 예시에서 작업은 s3:GetObject이고 자격 증명은 IAM 사용자 MaryMajor예요.

Allow 문을 추가해 정책을 업데이트하세요. 자세한 내용은 IAM User Guide의 자격 증명 기반 정책과 IAM 정책 편집을 참고하세요.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject because no identity-based policy allows the s3:GetObject action

자격 증명 기반 정책으로 인한 액세스 거부 – 명시적 거부

자격 증명에 연결된 자격 증명 기반 정책에서 작업에 대한 명시적 Deny 문이 있는지 확인하세요. 오류 메시지에는 정책 ARN이 포함되므로, 이를 사용해 요청을 거부한 정책을 찾아 직접 이동할 수 있어요. 다음 예시에서 작업은 s3:GetObject이고 자격 증명은 IAM 사용자 MaryMajor예요.

사용자에게 필요한 접근을 허용하도록 Deny 문을 변경해 정책을 업데이트하세요. 예를 들어 조건 연산자 StringNotEquals와 함께 aws:PrincipalAccount 조건 키를 사용하도록 Deny 문을 업데이트해 특정 보안 주체에게 접근을 허용할 수 있어요(IAM User Guide의 aws:PrincipalAccount 참고). 자세한 내용은 IAM User Guide의 자격 증명 기반 정책과 IAM 정책 편집을 참고하세요.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with 
an explicit deny in an identity-based policy, with policy ARN: 
arn:aws:iam::123456789012:policy/ExampleIdentityBasedPolicy

Block Public Access 설정으로 인한 액세스 거부

Amazon S3 Block Public Access 기능은 Amazon S3 리소스에 대한 공개 접근을 관리하도록 액세스 포인트, 버킷, 계정에 설정을 제공해요. Amazon S3가 "공개"를 어떻게 정의하는지에 대한 자세한 내용은 "공개"의 의미를 참고하세요.

기본적으로 새 버킷, 액세스 포인트, 객체는 공개 접근을 허용하지 않아요. 하지만 사용자가 버킷 정책, 액세스 포인트 정책, IAM 사용자 정책, 객체 권한 또는 접근 제어 목록(ACL)을 수정해 공개 접근을 허용할 수 있어요. S3 Block Public Access 설정은 이러한 정책, 권한, ACL을 재정의해요. 2023년 4월부터 모든 Block Public Access 설정은 새 버킷에 기본적으로 활성화돼요.

Amazon S3가 버킷이나 객체에 대한 접근 요청을 받으면 버킷이나 버킷 소유자 계정에 적용된 block public access 설정이 있는지 판단해요. 요청이 액세스 포인트를 통해 이루어졌다면 Amazon S3는 액세스 포인트의 block public access 설정도 확인해요. 요청된 접근을 금지하는 기존 block public access 설정이 있으면 Amazon S3는 요청을 거부해요.

Amazon S3 Block Public Access는 네 가지 설정을 제공해요. 이 설정들은 서로 독립적이며 어떤 조합으로든 사용할 수 있어요. 각 설정은 액세스 포인트, 버킷 또는 전체 AWS 계정에 적용할 수 있어요. 액세스 포인트, 버킷, 계정의 block public access 설정이 다르면 Amazon S3는 액세스 포인트, 버킷, 계정 설정의 가장 제한적인 조합을 적용해요.

Amazon S3가 어떤 작업이 block public access 설정에 의해 금지되는지 평가할 때, 액세스 포인트, 버킷 또는 계정 설정을 위반하는 요청을 거부해요.

Amazon S3 Block Public Access가 제공하는 네 가지 설정은 다음과 같아요.

  • BlockPublicAcls — 이 설정은 PutBucketAcl, PutObjectAcl, PutObject, CreateBucket, CopyObject, POST Object 요청에 적용돼요. BlockPublicAcls 설정은 다음 동작을 일으켜요.
    • 지정된 접근 제어 목록(ACL)이 공개이면 PutBucketAcl과 PutObjectAcl 호출이 실패해요.
    • 요청에 공개 ACL이 포함되면 PutObject 호출이 실패해요.
    • 이 설정이 계정에 적용되면, 요청에 공개 ACL이 포함될 때 CreateBucket 호출이 HTTP 400(Bad Request) 응답으로 실패해요.

예를 들어 BlockPublicAcls 설정 때문에 CopyObject 요청이 거부되면 다음 메시지를 받아요.

An error occurred (AccessDenied) when calling the CopyObject operation: 
User: arn:aws:sts::123456789012:user/MaryMajor is not authorized to 
perform: s3:CopyObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" 
because public ACLs are prevented by the BlockPublicAcls setting in S3 Block Public Access.
  • IgnorePublicAcls — IgnorePublicAcls 설정은 Amazon S3가 버킷과 그 안의 객체에 대한 모든 공개 ACL을 무시하게 해요. 요청의 권한이 공개 ACL로만 부여되면 IgnorePublicAcls 설정이 요청을 거부해요.

IgnorePublicAcls 설정으로 인한 거부는 모두 암시적이에요. 예를 들어 IgnorePublicAcls가 공개 ACL 때문에 GetObject 요청을 거부하면 다음 메시지를 받아요.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject because no resource-based policy allows the s3:GetObject action
  • BlockPublicPolicy — 이 설정은 PutBucketPolicy와 PutAccessPointPolicy 요청에 적용돼요.
    • 버킷에 BlockPublicPolicy를 설정하면, 지정된 버킷 정책이 공개 접근을 허용할 때 Amazon S3가 PutBucketPolicy 호출을 거부해요. 이 설정은 또한 지정된 정책이 공개 접근을 허용할 때 버킷의 모든 동일 계정 액세스 포인트에 대한 PutAccessPointPolicy 호출도 거부해요.
    • 액세스 포인트에 BlockPublicPolicy를 설정하면, 지정된 정책(액세스 포인트 또는 기본 버킷의)이 공개 접근을 허용할 때 Amazon S3가 액세스 포인트를 통해 이루어지는 PutAccessPointPolicy와 PutBucketPolicy 호출을 거부해요.

예를 들어 BlockPublicPolicy 설정 때문에 PutBucketPolicy 요청이 거부되면 다음 메시지를 받아요.

An error occurred (AccessDenied) when calling the PutBucketPolicy operation: 
User: arn:aws:sts::123456789012:user/MaryMajor is not authorized to 
perform: s3:PutBucketPolicy on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" 
because public policies are prevented by the BlockPublicPolicy setting in S3 Block Public Access.
  • RestrictPublicBuckets — RestrictPublicBuckets 설정은 공개 정책이 있는 액세스 포인트나 버킷에 대한 접근을 AWS 서비스 보안 주체와 버킷 소유자 계정 및 액세스 포인트 소유자 계정 내의 인가된 사용자로만 제한해요. 이 설정은 계정 내 사용자가 액세스 포인트나 버킷을 관리하는 것은 허용하면서도 액세스 포인트나 버킷에 대한 모든 계정 간 접근(AWS 서비스 보안 주체 제외)을 차단해요. 이 설정은 모든 익명(또는 서명되지 않은) 호출도 거부해요.

RestrictPublicBuckets 설정으로 인한 거부는 모두 명시적이에요. 예를 들어 RestrictPublicBuckets가 공개 버킷이나 액세스 포인트 정책 때문에 GetObject 요청을 거부하면 다음 메시지를 받아요.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with 
an explicit deny in a resource-based policy

이 설정들에 대한 자세한 내용은 Block public access 설정을 참고하세요. 이 설정들을 검토하고 업데이트하려면 Block public access 구성을 참고하세요.

Requester Pays 설정으로 인한 액세스 거부

접근하려는 Amazon S3 버킷에 Requester Pays 기능이 활성화돼 있으면, 그 버킷에 요청할 때 올바른 요청 파라미터를 전달하고 있는지 확인해야 해요. Amazon S3의 Requester Pays 기능은 버킷 소유자 대신 요청자가 버킷의 객체에 접근하기 위한 데이터 전송 및 요청 비용을 지불하게 해요. 버킷에 Requester Pays가 활성화되면 다른 AWS 계정이 만든 요청에 대해 버킷 소유자에게 요금이 부과되지 않아요.

필요한 파라미터 없이 Requester Pays가 활성화된 버킷에 요청하면 액세스 거부(403 Forbidden) 오류를 받아요. Requester Pays가 활성화된 버킷의 객체에 접근하려면 다음을 수행해야 해요.

  • AWS CLI로 요청할 때 --request-payer requester 파라미터를 포함해야 해요. 예를 들어 s3://amzn-s3-demo-bucket/object.txt S3 버킷에 있는 키 object.txt 객체를 로컬 머신의 위치로 복사하려면, 이 버킷에 Requester Pays가 활성화돼 있다면 --request-payer requester 파라미터도 전달해야 해요.
aws s3 cp s3://amzn-s3-demo-bucket/object.txt /local/path \
--request-payer requester
  • AWS SDK로 프로그래밍 방식 요청을 할 때 x-amz-request-payer 헤더를 requester 값으로 설정해요. 예시는 Requester Pays 버킷에서 객체 다운로드를 참고하세요.
  • 요청하는 IAM 사용자나 역할이 s3:GetObject와 s3:ListBucket 권한 같은 Requester Pays 버킷에 접근하는 데 필요한 권한을 가지고 있는지 확인하세요.

--request-payer requester 파라미터를 포함하거나 x-amz-request-payer 헤더를 설정하면, 요청자인 내가 Requester Pays가 활성화된 버킷의 객체에 접근하는 데 따르는 비용을 지불하겠다고 Amazon S3에 알리는 거예요. 이렇게 하면 액세스 거부(403 Forbidden) 오류가 방지돼요.

버킷 정책과 IAM 정책

버킷 수준 작업

버킷 정책이 없으면 버킷은 버킷 소유자 계정의 모든 AWS Identity and Access Management(IAM) 자격 증명의 요청을 암시적으로 허용해요. 또한 다른 계정의 다른 IAM 자격 증명과 익명(서명되지 않은) 요청은 암시적으로 거부해요. 하지만 IAM 사용자 정책이 없으면 요청자(AWS 계정 루트 사용자가 아닌 경우)는 어떤 요청도 할 수 없게 암시적으로 거부돼요. 이 평가 로직에 대한 자세한 내용은 IAM User Guide의 계정 내에서 요청이 거부되는지 허용되는지 결정을 참고하세요.

객체 수준 작업

객체가 버킷 소유 계정의 소유라면, 버킷 정책과 IAM 사용자 정책은 객체 수준 작업에서도 버킷 수준 작업과 같은 방식으로 작동해요. 예를 들어 버킷 정책이 없으면 버킷은 버킷 소유자 계정의 모든 IAM 자격 증명의 객체 요청을 암시적으로 허용해요. 또한 다른 계정의 다른 IAM 자격 증명과 익명(서명되지 않은) 요청의 객체 요청은 암시적으로 거부해요. 하지만 IAM 사용자 정책이 없으면 요청자(AWS 계정 루트 사용자가 아닌 경우)는 어떤 객체 요청도 할 수 없게 암시적으로 거부돼요.

객체가 외부 계정의 소유라면, 객체에 대한 접근은 객체 접근 제어 목록(ACL)으로만 부여할 수 있어요. 버킷 정책과 IAM 사용자 정책은 객체 요청을 거부하는 데는 여전히 사용할 수 있어요.

따라서 버킷 정책이나 IAM 사용자 정책이 액세스 거부(403 Forbidden) 오류를 일으키지 않도록 다음 요구 사항을 충족하는지 확인하세요.

  • 동일 계정 접근 — 권한을 부여하려는 요청자에 대해 버킷 정책이나 IAM 사용자 정책에 명시적 Deny 문이 없어야 해요. 버킷 정책과 IAM 사용자 정책만으로 권한을 부여하려면 이 정책 중 하나에 명시적 Allow 문이 최소 하나는 있어야 해요.
  • 계정 간 접근 — 권한을 부여하려는 요청자에 대해 버킷 정책이나 IAM 사용자 정책에 명시적 Deny 문이 없어야 해요. 버킷 정책과 IAM 사용자 정책만으로 계정 간 권한을 부여하려면, 버킷 정책과 요청자의 IAM 사용자 정책 둘 다 명시적 Allow 문을 포함하는지 확인하세요.

참고 — 버킷 정책의 Allow 문은 같은 버킷 소유 계정이 소유한 객체에만 적용돼요. 하지만 버킷 정책의 Deny 문은 객체 소유권과 관계없이 모든 객체에 적용돼요.

버킷 정책 검토 또는 편집

참고 — 버킷 정책을 보려면 s3:GetBucketPolicy 권한이 있어야 해요. 버킷 정책을 편집하려면 s3:PutBucketPolicy 권한이 있어야 해요.

  1. AWS Management Console에 로그인하고 Amazon S3 콘솔을 엽니다.
  2. 왼쪽 탐색 창에서 버킷(Buckets) 을 선택해요.
  3. 버킷(Buckets) 목록에서 버킷 정책을 보거나 편집할 버킷의 이름을 선택해요.
  4. 권한(Permissions) 탭을 선택해요.
  5. 버킷 정책(Bucket policy) 아래에서 편집(Edit) 을 선택해요. 버킷 정책 편집(Edit bucket policy) 페이지가 나타나요.

AWS Command Line Interface(AWS CLI)로 버킷 정책을 검토하려면 get-bucket-policy 명령을 사용하세요. 버킷 정책을 편집하려면 put-bucket-policy 명령을 사용하세요.

참고 — 잘못된 버킷 정책 때문에 버킷에서 잠겨 버리면 AWS 계정 루트 사용자 자격 증명으로 AWS Management Console에 로그인하세요. 버킷에 다시 접근하려면 AWS 계정 루트 사용자 자격 증명으로 잘못된 버킷 정책을 삭제해야 해요.

권한 확인을 위한 팁

요청자가 Amazon S3 작업을 수행할 올바른 권한을 가지고 있는지 확인하려면 다음을 시도해 보세요.

  1. 요청자를 식별해요. 서명되지 않은 요청이라면 IAM 사용자 정책이 없는 익명 요청이에요. 사전 서명된 URL을 사용하는 요청이라면 사용자 정책은 요청에 서명한 IAM 사용자나 역할의 정책과 같아요.
  2. 올바른 IAM 사용자나 역할을 사용하고 있는지 확인해요. 콘솔 탐색 막대를 확인하거나 aws sts get-caller-identity 명령으로 IAM 사용자나 역할을 확인할 수 있어요.
  3. IAM 사용자나 역할과 관련된 IAM 정책을 확인해요. 다음 방법 중 하나를 사용할 수 있어요.
  4. 접근을 명시적으로 거부하거나 허용하는 정책의 다음 예시를 검토해요.

Amazon S3 ACL 설정

ACL 설정을 확인할 때 먼저 Object Ownership 설정을 검토해 버킷에서 ACL이 활성화됐는지 확인하세요. ACL 권한은 권한을 부여하는 데만 사용할 수 있고 요청을 거부하는 데는 사용할 수 없다는 점을 알아두세요. 또한 ACL은 버킷 정책이나 IAM 사용자 정책의 명시적 거부로 거부된 요청자에게 접근을 부여하는 데도 사용할 수 없어요.

Object Ownership 설정이 버킷 소유자 적용(Bucket owner enforced)인 경우

Bucket owner enforced 설정이 활성화되면 이 설정이 버킷과 객체에 적용되는 모든 ACL을 비활성화하므로 ACL 설정이 액세스 거부(403 Forbidden) 오류를 일으킬 가능성이 없어요. Bucket owner enforced는 Amazon S3 버킷의 기본(그리고 권장) 설정이에요.

Object Ownership 설정이 버킷 소유자 선호(Bucket owner preferred) 또는 객체 작성자(Object writer)인 경우

ACL 권한은 Bucket owner preferred 설정이나 Object writer 설정에서도 여전히 유효해요. ACL에는 버킷 ACL과 객체 ACL 두 종류가 있어요. 이 두 유형의 차이점은 ACL 권한과 접근 정책 권한의 매핑을 참고하세요.

거부된 요청의 작업에 따라 버킷이나 객체의 ACL 권한을 확인하세요.

  • Amazon S3가 LIST, PUT 객체, GetBucketAcl 또는 PutBucketAcl 요청을 거부했다면 버킷의 ACL 권한을 검토하세요.
  • Amazon S3가 S3 객체에 대한 GET 요청이나 PutObjectAcl 요청을 거부했다면 객체의 ACL 권한을 검토하세요.

참고 — 버킷 ACL 설정으로는 GET 객체 권한을 부여할 수 없어요.

중요 — 객체를 소유한 계정이 버킷을 소유한 계정과 다르면, 객체에 대한 접근은 버킷 정책으로 제어되지 않아요.

계정 간 객체 소유권 중 GET 객체 요청의 액세스 거부(403 Forbidden) 오류 문제 해결

객체 소유자를 판단하려면 버킷의 Object Ownership 설정을 검토하세요. 객체 ACL에 접근할 수 있다면 객체 소유자 계정도 확인할 수 있어요(객체 소유자 계정을 보려면 Amazon S3 콘솔에서 객체 ACL 설정을 검토하세요). 또는 GetObjectAcl 요청을 만들어 객체 소유자의 정규 ID를 찾아 객체 소유자 계정을 확인할 수도 있어요. 기본적으로 ACL은 GET 요청에 대해 객체 소유자 계정에 명시적 허용 권한을 부여해요.

객체 소유자가 버킷 소유자와 다르다는 걸 확인한 다음, 사용 사례와 접근 수준에 따라 다음 방법 중 하나를 선택해 액세스 거부(403 Forbidden) 오류를 해결하세요.

  • ACL 비활성화(권장) — 이 방법은 모든 객체에 적용되며 버킷 소유자가 수행할 수 있어요. 이 방법은 자동으로 버킷 소유자에게 버킷의 모든 객체에 대한 소유권과 전체 제어를 부여해요. 이 방법을 구현하기 전에 ACL 비활성화 전제 조건을 확인하세요. 버킷을 Bucket owner enforced(권장) 모드로 설정하는 방법은 기존 버킷에서 Object Ownership 설정을 참고하세요.
  • 객체 소유자를 버킷 소유자로 변경 — 이 방법은 개별 객체에 적용할 수 있지만, 객체 소유자(또는 적절한 권한을 가진 사용자)만 객체의 소유권을 변경할 수 있어요. 추가 PUT 비용이 발생할 수 있어요(자세한 내용은 Amazon S3 요금 참고). 이 방법은 버킷 소유자에게 객체의 전체 소유권을 부여해 버킷 소유자가 버킷 정책을 통해 객체 접근을 제어할 수 있게 해요.
    • 객체의 소유권을 변경하려면 다음 중 하나를 수행해요.
      • 버킷 소유자(나)는 객체를 버킷으로 다시 복사할 수 있어요.
      • 버킷의 Object Ownership 설정을 Bucket owner preferred로 변경할 수 있어요. 버저닝이 비활성화되면 버킷의 객체가 덮어써져요. 버저닝이 활성화되면 같은 객체의 중복 버전이 버킷에 나타나는데, 버킷 소유자가 수명 주기 규칙으로 만료되게 설정할 수 있어요. Object Ownership 설정 변경 방법은 기존 버킷에서 Object Ownership 설정을 참고하세요.
      • 참고 — Object Ownership 설정을 Bucket owner preferred로 업데이트하면, 이 설정은 버킷에 새로 업로드되는 객체에만 적용돼요.
      • 객체 소유자가 bucket-owner-full-control 캐닝 객체 ACL로 객체를 다시 업로드하게 할 수 있어요.
      • 참고 — 계정 간 업로드의 경우 버킷 정책에서 bucket-owner-full-control 캐닝 객체 ACL을 요구할 수도 있어요. 예제 버킷 정책은 버킷 소유자가 전체 제어를 하도록 보장하면서 객체 업로드를 위한 계정 간 권한 부여를 참고하세요.
  • 객체 작성자를 객체 소유자로 유지 — 이 방법은 객체 소유자를 변경하지 않지만 객체에 개별적으로 접근을 부여할 수 있게 해줘요. 객체에 접근을 부여하려면 그 객체에 대한 PutObjectAcl 권한이 있어야 해요. 그런 다음 액세스 거부(403 Forbidden) 오류를 고치려면 객체의 ACL에서 요청자를 그 객체에 접근할 수 있는 수혜자(grantee)로 추가해요. 자세한 내용은 ACL 구성을 참고하세요.

S3 Block Public Access 설정

실패한 요청이 공개 접근이나 공개 정책과 관련돼 있다면 계정, 버킷 또는 액세스 포인트의 S3 Block Public Access 설정을 확인하세요. S3 Block Public Access 설정과 관련된 액세스 거부 오류 문제 해결에 대한 자세한 내용은 Block Public Access 설정으로 인한 액세스 거부를 참고하세요.

Amazon S3 암호화 설정

Amazon S3는 버킷에서 서버 측 암호화를 지원해요. 서버 측 암호화는 데이터를 받는 애플리케이션이나 서비스가 대상에서 데이터를 암호화하는 것이에요. Amazon S3는 AWS 데이터 센터의 디스크에 쓸 때 객체 수준에서 데이터를 암호화하고, 접근할 때 복호화해 줘요.

기본적으로 Amazon S3는 이제 Amazon S3 관리 키(SSE-S3)를 사용한 서버 측 암호화를 Amazon S3의 모든 버킷에 대한 기본 암호화 수준으로 적용해요. Amazon S3는 객체를 업로드할 때 서버 측 암호화 방법을 지정할 수도 있게 해줘요.

버킷의 서버 측 암호화 상태와 암호화 설정 검토

  1. AWS Management Console에 로그인하고 Amazon S3 콘솔을 엽니다.
  2. 왼쪽 탐색 창에서 버킷(Buckets) 을 선택해요.
  3. 버킷(Buckets) 목록에서 암호화 설정을 확인할 버킷을 선택해요.
  4. 속성(Properties) 탭을 선택해요.
  5. 기본 암호화(Default encryption) 섹션까지 스크롤하고 암호화 유형(Encryption type) 설정을 확인해요.

AWS CLI로 암호화 설정을 확인하려면 get-bucket-encryption 명령을 사용하세요.

객체의 암호화 상태 확인

  1. AWS Management Console에 로그인하고 Amazon S3 콘솔을 엽니다.
  2. 왼쪽 탐색 창에서 버킷(Buckets) 을 선택해요.
  3. 버킷(Buckets) 목록에서 객체가 들어 있는 버킷의 이름을 선택해요.
  4. 객체(Objects) 목록에서 암호화를 추가하거나 변경할 객체의 이름을 선택해요. 객체의 세부 정보 페이지가 나타나요.
  5. 서버 측 암호화 설정(Server-side encryption settings) 섹션까지 스크롤해 객체의 서버 측 암호화 설정을 확인해요.

AWS CLI로 객체 암호화 상태를 확인하려면 head-object 명령을 사용하세요.

암호화 및 권한 요구 사항

Amazon S3는 세 가지 유형의 서버 측 암호화를 지원해요.

  • Amazon S3 관리 키를 사용한 서버 측 암호화(SSE-S3)
  • AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)
  • 고객 제공 키를 사용한 서버 측 암호화(SSE-C)

암호화 설정에 따라 다음 권한 요구 사항이 충족되는지 확인하세요.

  • SSE-S3 — 추가 권한이 필요 없어요.
  • SSE-KMS(고객 관리 키 포함) — 객체를 업로드하려면 AWS KMS 키에 대한 kms:GenerateDataKey 권한이 필요해요. 객체를 다운로드하고 객체의 멀티파트 업로드를 수행하려면 KMS 키에 대한 kms:Decrypt 권한이 필요해요.
  • SSE-KMS(AWS 관리 키 포함) — 요청자는 aws/s3 KMS 키를 소유한 계정과 같은 계정이어야 해요. 요청자는 또한 객체에 접근할 올바른 Amazon S3 권한을 가지고 있어야 해요.
  • SSE-C(고객 제공 키 포함) — 추가 권한이 필요 없어요. 버킷 정책을 구성해 버킷의 객체에 대해 고객 제공 암호화 키를 사용한 서버 측 암호화를 요구하고 제한할 수 있어요.

객체가 고객 관리 키로 암호화된 경우, KMS 키 정책이 kms:GenerateDataKey 또는 kms:Decrypt 작업을 수행할 수 있게 해주는지 확인하세요. KMS 키 정책 확인 방법은 AWS Key Management Service Developer Guide의 키 정책 보기를 참고하세요.

S3 Object Lock 설정

버킷에 S3 Object Lock이 활성화돼 있고 객체가 보존(retention) 기간이나 법적 보존(legal hold)으로 보호되는데 객체를 삭제하려고 하면, Amazon S3는 삭제를 시도한 방식에 따라 다음 응답 중 하나를 반환해요.

  • 영구 DELETE 요청 — 영구 DELETE 요청(버전 ID를 지정하는 요청)을 발행했다면 Amazon S3는 객체를 삭제하려 할 때 액세스 거부(403 Forbidden) 오류를 반환해요.
  • 단순 DELETE 요청 — 단순 DELETE 요청(버전 ID를 지정하지 않는 요청)을 발행했다면 Amazon S3는 200 OK 응답을 반환하고 버킷에 삭제 마커(delete marker)를 삽입해요. 그 마커는 새 ID를 가진 객체의 현재 버전이 돼요.

버킷에 Object Lock이 활성화돼 있는지 확인

  1. AWS Management Console에 로그인하고 Amazon S3 콘솔을 엽니다.
  2. 왼쪽 탐색 창에서 버킷(Buckets) 을 선택해요.
  3. 버킷(Buckets) 목록에서 검토할 버킷의 이름을 선택해요.
  4. 속성(Properties) 탭을 선택해요.
  5. Object Lock 섹션까지 스크롤해 Object Lock 설정이 활성화(Enabled) 인지 비활성화(Disabled) 인지 확인해요.

객체가 보존 기간이나 법적 보존으로 보호되는지 확인하려면 객체의 잠금 정보를 확인하세요.

객체가 보존 기간이나 법적 보존으로 보호되는 경우 다음을 확인하세요.

  • 객체 버전이 준수(compliance) 보존 모드로 보호되면 영구 삭제할 방법이 없어요. AWS 계정 루트 사용자를 포함한 어떤 요청자의 영구 DELETE 요청도 액세스 거부(403 Forbidden) 오류로 이어져요. 또한 준수 보존 모드로 보호되는 객체에 대해 DELETE 요청을 제출하면 Amazon S3가 객체의 삭제 마커를 만든다는 점도 알아두세요.
  • 객체 버전이 거버넌스(governance) 보존 모드로 보호되고 있고 s3:BypassGovernanceRetention 권한이 있다면 보호를 우회하고 버전을 영구 삭제할 수 있어요. 자세한 내용은 거버넌스 모드 우회를 참고하세요.
  • 객체 버전이 법적 보존으로 보호되면 영구 DELETE 요청이 액세스 거부(403 Forbidden) 오류로 이어질 수 있어요. 객체 버전을 영구 삭제하려면 객체 버전의 법적 보존을 제거해야 해요. 법적 보존을 제거하려면 s3:PutObjectLegalHold 권한이 있어야 해요. 법적 보존 제거에 대한 자세한 내용은 S3 Object Lock 구성을 참고하세요.

VPC 엔드포인트 정책

가상 사설 클라우드(VPC) 엔드포인트로 Amazon S3에 접근하고 있다면, VPC 엔드포인트 정책이 내 Amazon S3 리소스에 접근하는 것을 차단하지 않는지 확인하세요. 기본적으로 VPC 엔드포인트 정책은 Amazon S3에 대한 모든 요청을 허용해요. 특정 요청을 제한하도록 VPC 엔드포인트 정책을 구성할 수도 있어요. VPC 엔드포인트 정책 확인 방법은 다음 리소스를 참고하세요.

AWS Organizations 정책

내 AWS 계정이 조직에 속해 있다면 AWS Organizations 정책이 Amazon S3 리소스에 접근하는 것을 차단할 수 있어요. 기본적으로 AWS Organizations 정책은 Amazon S3에 대한 어떤 요청도 차단하지 않아요. 하지만 AWS Organizations 정책이 S3 버킷에 대한 접근을 차단하도록 구성되지 않았는지 확인하세요. AWS Organizations 정책 확인 방법은 다음 리소스를 참고하세요.

또한 멤버 계정의 버킷 정책을 잘못 구성해 모든 사용자가 S3 버킷에 접근하지 못하게 막았다면, IAM에서 멤버 계정의 권한 있는 세션(privileged session)을 시작해 버킷을 잠금 해제할 수 있어요. 권한 있는 세션을 시작한 뒤 잘못 구성된 버킷 정책을 삭제해 버킷에 다시 접근할 수 있어요. 자세한 내용은 AWS Identity and Access Management User Guide의 AWS Organizations 멤버 계정에서 권한 있는 작업 수행을 참고하세요.

CloudFront 배포 접근

CloudFront로 S3 정적 웹사이트에 접근하려 할 때 액세스 거부(403 Forbidden) 오류를 받으면 다음 일반적인 문제를 확인하세요.

  • 올바른 오리진 도메인 이름 형식을 사용하고 있나요? REST API 엔드포인트가 아니라 S3 웹사이트 엔드포인트 형식(bucket-name.s3-website-region.amazonaws.com)을 사용하고 있는지 확인하세요.
  • 버킷에서 정적 웹사이트 호스팅이 활성화됐는지 확인하세요.
  • 버킷 정책이 CloudFront 접근을 허용하나요? 버킷 정책에 CloudFront 배포의 Origin Access Identity(OAI)나 Origin Access Control(OAC)에 대한 권한이 포함되도록 하세요.
  • 정책에 필요한 s3:GetObject 권한이 포함됐는지 확인하세요.

오류 페이지 설정과 프로토콜 설정을 포함한 추가 문제 해결 단계와 구성은 AWS re:Post Knowledge Center의 CloudFront 배포의 오리진으로 Amazon S3 웹사이트 엔드포인트를 사용할 때 "403 access denied" 오류가 발생하는 이유는 무엇인가요?를 참고하세요.

참고 — 이 오류는 S3에 직접 접근할 때 받을 수 있는 403 오류와 달라요. CloudFront 관련 문제라면 CloudFront 배포 설정과 S3 구성을 둘 다 확인해야 해요.

액세스 포인트 설정

Amazon S3 액세스 포인트를 통해 요청하면서 액세스 거부(403 Forbidden) 오류를 받으면 다음을 확인해야 할 수 있어요.

  • 액세스 포인트의 구성
  • 액세스 포인트에 사용되는 IAM 사용자 정책
  • 계정 간 액세스 포인트를 관리하거나 구성하는 데 사용되는 버킷 정책

액세스 포인트 구성과 정책

액세스 포인트를 만들 때 네트워크 오리진으로 인터넷(Internet) 또는 VPC 를 지정할 수 있어요. 네트워크 오리진이 VPC 전용으로 설정되면 Amazon S3는 지정된 VPC에서 시작되지 않는 액세스 포인트에 대한 모든 요청을 거부해요. 액세스 포인트의 네트워크 오리진을 확인하려면 가상 사설 클라우드로 제한된 액세스 포인트 만들기를 참고하세요.

액세스 포인트로 버킷이나 계정 수준의 Block Public Access 설정과 비슷하게 작동하는 사용자 지정 Block Public Access 설정을 구성할 수도 있어요. 사용자 지정 Block Public Access 설정을 확인하려면 일반용 버킷의 액세스 포인트에 대한 공개 접근 관리를 참고하세요.

액세스 포인트를 사용해 Amazon S3에 성공적으로 요청하려면 요청자가 필요한 IAM 권한을 가지고 있는지 확인하세요. 자세한 내용은 액세스 포인트 사용을 위한 IAM 정책 구성을 참고하세요.

요청이 계정 간 액세스 포인트와 관련된 경우, 버킷 소유자가 액세스 포인트의 요청을 인가하도록 버킷 정책을 업데이트했는지 확인하세요. 자세한 내용은 계정 간 액세스 포인트에 대한 권한 부여를 참고하세요.

이 주제의 모든 항목을 확인한 후에도 액세스 거부(403 Forbidden) 오류가 계속되면, Amazon S3 요청 ID를 검색해 추가 지침을 위해 Support에 문의하세요.

추가 리소스

액세스 거부(403 Forbidden) 오류에 대한 추가 지침은 다음 리소스를 확인할 수 있어요.

더 알아보기 (Learn more)