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

• 명시적 거부는 정책에 특정 AWS 작업에 대한 Deny 문이 포함되어 있을 때 발생합니다.

• 적용 가능한 Deny 문이 없고 적용 가능한 Allow 문도 없다면 암시적 거부가 발생합니다.

• 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 access control lists (ACLs) are blocked by the BlockPublicAcls block 
  public access setting.

• IgnorePublicAcls - IgnorePublicAcls 설정을 사용하면 Amazon S3가 버킷의 모든 퍼블릭 ACL 및 거기에 포함된 모든 객체를 무시합니다. 퍼블릭 ACL에서만 요청 권한을 부여한 경우 IgnorePublicAcls 설정이 요청을 거부합니다.

  IgnorePublicAcls 설정으로 인한 모든 거부는 묵시적입니다. 예를 들어 퍼블릭 ACL로 인해 IgnorePublicAcls가 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를 설정하면 지정된 버킷 정책이 퍼블릭 액세스를 허용하는 경우 PutBucketPolicy에 대한 직접 호출을 Amazon S3가 거부합니다. 또한 이 설정을 사용하면 지정된 버킷 정책이 퍼블릭 액세스를 허용하는 경우, 버킷의 동일한 계정 액세스 포인트 모두에 PutAccessPointPolicy에 대한 직접 호출을 Amazon S3가 거부합니다.

  액세스 포인트에 BlockPublicPolicy를 설정하면 지정된 정책(액세스 포인트 또는 기본 버킷)이 퍼블릭 액세스를 허용하는 경우, 액세스 포인트를 통해 이루어지는 PutAccessPointPolicy 및 PutBucketPolicy에 대한 직접 호출을 Amazon S3가 거부합니다.

  예를 들어, 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 blocked by the BlockPublicPolicy block public 
  access setting.

• 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

• 동일 계정 액세스의 경우 버킷 정책 또는 IAM 사용자 정책 내에 권한을 부여하려는 요청자에 대한 명시적인 Deny 명령문이 없어야 합니다. 버킷 정책과 IAM 사용자 정책만 사용하여 권한을 부여하려면 이러한 정책 중 하나에 명시적인 Allow 명령문이 하나 이상 있어야 합니다.

• 크로스 계정 액세스의 경우 버킷 정책 또는 IAM 사용자 정책 내에 권한을 부여하려는 요청자에 대한 명시적인 Deny 명령문이 없어야 합니다. 버킷 정책과 IAM 사용자 정책만 사용하여 크로스 계정 권한을 부여하려면 요청자의 버킷 정책과 IAM 사용자 정책 모두에 명시적인 Allow 명령문을 포함해야 합니다.

• 요청자를 식별합니다. 서명되지 않은 요청인 경우 IAM 사용자 정책이 없는 익명 요청입니다. 미리 서명된 URL을 사용하는 요청인 경우 사용자 정책은 요청에 서명한 IAM 사용자 또는 역할에 대한 정책과 동일합니다.

• 올바른 IAM 사용자 또는 역할을 사용하고 있는지 확인합니다. AWS Management Console 오른쪽 상단을 확인하거나 aws sts get-caller-identity 명령을 사용하여 IAM 사용자 또는 역할을 확인할 수 있습니다.

• 요청을 수행하는 IAM 사용자 또는 역할과 관련된 IAM 정책을 확인합니다. 다음 방법 중 하나를 사용할 수 있습니다.

  • IAM 정책 시뮬레이터로 IAM 정책을 테스트합니다.

  • 다양한 IAM 정책 유형을 검토합니다.

• 필요한 경우 IAM 사용자 정책을 편집합니다.

• 액세스를 명시적으로 거부하거나 허용하는 다음 정책의 예시를 검토합니다.

  • 명시적 허용 IAM 정책: IAM: 프로그래밍 방식rhk 콘솔에서 여러 서비스에 대한 액세스 허용 및 거부

  • 명시적 허용 버킷 정책: 여러 계정에 객체를 업로드하거나 퍼블릭 액세스에 객체 ACL을 퍼블릭 설정할 수 있는 권한 부여

  • 명시적 거부 IAM 사용자 정책: AWS: 요청된 AWS 리전에 따라 AWS에 대한 액세스 거부

  • 명시적 거부 버킷 정책: 버킷에 작성되는 모든 객체에 SSE-KMS 요구

• Amazon S3에서 LIST, PUT 객체, GetBucketAcl 또는 PutBucketAcl 요청을 거부한 경우 버킷에 대한 ACL 권한을 검토하세요.

  참고

  버킷 ACL 설정으로는 GET 객체 권한을 부여할 수 없습니다.

• Amazon S3가 S3 객체에 대한 GET 요청 또는 PutObjectAcl 요청을 거부한 경우 해당 객체에 대한 ACL 권한을 검토하세요.

  중요

  객체를 소유한 계정이 버킷을 소유한 계정과 다른 경우 객체에 대한 액세스는 버킷 정책으로 제어되지 않습니다.

• ACL 비활성화(권장) - 이 방법은 모든 객체에 적용되며 버킷 소유자가 수행할 수 있습니다. 이 방법은 버킷 소유자에게 버킷의 모든 객체에 대한 소유권과 완전한 제어 권한을 자동으로 부여합니다. 이 방법을 구현하기 전에 ACL 사용 중지를 위한 사전 조건을 확인하세요. 버킷을 버킷 소유자 적용(권장) 모드로 설정하는 방법에 대한 자세한 내용은 기존 버킷에 대한 객체 소유권 설정을 참조하세요.

  중요

  액세스 거부(403 금지) 오류를 방지하려면 ACL을 비활성화하기 전에 반드시 ACL 권한을 버킷 정책으로 마이그레이션해야 합니다. 자세한 내용은 ACL 권한에서 마이그레이션하기 위한 버킷 정책 예시를 참조하세요.

• 객체 소유자를 버킷 소유자로 변경 - 이 방법은 개별 객체에 적용할 수 있지만 객체 소유자(또는 적절한 권한이 있는 사용자)만 객체 소유권을 변경할 수 있습니다. 추가 PUT 요금이 적용될 수 있습니다. (자세한 내용은 Amazon S3 요금을 참조하세요.) 이 방법은 버킷 소유자에게 객체의 전체 소유권을 부여하여 버킷 소유자가 버킷 정책을 통해 객체에 대한 액세스를 제어할 수 있도록 합니다.

  객체 소유권을 변경하려면 다음 중 하나를 수행합니다.

  • 사용자(버킷 소유자)는 객체를 다시 버킷에 복사할 수 있습니다.

  • 사용자는 버킷의 객체 소유권 설정을 버킷 소유자 선호로 변경할 수 있습니다. 버전 관리가 비활성화된 경우 버킷의 객체를 덮어씁니다. 버전 관리가 활성화된 경우 동일한 객체의 중복 버전이 버킷에 표시되며, 버킷 소유자는 만료되도록 수명 주기 규칙을 설정할 수 있습니다. 객체 소유권 설정을 변경하는 자세한 방법은 기존 버킷에 대한 객체 소유권 설정 섹션을 참조하세요.

    참고

    객체 소유권 설정을 버킷 소유자 선호로 업데이트하면 해당 설정은 버킷에 업로드되는 신규 객체에만 적용됩니다.

  • 객체 소유자가 bucket-owner-full-control 미리 제공된 객체 ACL을 사용하여 객체를 다시 업로드하도록 할 수 있습니다.

  참고

  크로스 계정 업로드의 경우 버킷 정책에 bucket-owner-full-control 미리 제공된 객체 ACL을 요구할 수도 있습니다. 예시 버킷 정책은 버킷 소유자가 완벽하게 제어할 수 있도록 보증하면서 객체에 업로드하는 크로스 계정 권한 부여를 참조하세요.

• 객체 라이터를 객체 소유자로 유지 - 이 방법을 사용하면 객체 소유자를 변경하지 않지만 객체에 개별적으로 액세스 권한을 부여할 수 있습니다. 객체에 대한 액세스 권한을 부여하려면 객체에 대한 PutObjectAcl 권한이 있어야 합니다. 그런 다음 액세스 거부(403 금지) 오류를 수정하려면 요청자를 객체 ACL에 있는 객체에 액세스할 수 있는 피부여자로 추가하세요. 자세한 내용은 ACL 구성 단원을 참조하십시오.

• Amazon S3 관리형 키를 사용한 서버 측 암호화(SSE-S3)

• AWS Key Management Service(AWS KMS) 키(SSE-KMS)를 사용한 서버 측 암호화

• 고객 제공 키를 사용한 서버 측 암호화(SSE-C)

• SSE-S3 - 추가 권한이 필요하지 않습니다.

• SSE-KMS(고객 관리형 키 사용) - 객체를 업로드하려면 AWS KMS key에 대한 kms:GenerateDataKey 권한이 필요합니다. 객체를 다운로드하고 객체의 멀티파트 업로드를 수행하려면 KMS 키에 대한 kms:Decrypt 권한이 필요합니다.

• SSE-KMS(AWS 관리형 키 사용) - 요청자는 aws/s3 KMS 키를 소유한 계정과 동일한 계정을 사용해야 합니다. 또한 요청자는 객체에 액세스할 수 있는 올바른 Amazon S3 권한을 가지고 있어야 합니다.

• SSE-C(고객 제공 키 사용) - 추가 권한이 필요하지 않습니다. 버킷의 객체에 고객 제공 암호화 키를 사용하여 서버 측 암호화를 요구하고 제한하도록 버킷 정책을 구성할 수 있습니다.

• 객체 버전이 규정 준수 보존 모드로 보호되는 경우 영구적으로 삭제할 방법이 없습니다. AWS 계정 루트 사용자를 포함하여 요청자가 영구적 DELETE 요청을 수행하면 액세스 거부(403 금지) 오류가 발생합니다. 또한 규정 준수 보존 모드로 보호되는 객체에 대해 DELETE 요청을 제출하면 Amazon S3는 해당 객체에 삭제 마커를 생성한다는 점을 유의하시기 바랍니다.

• 객체 버전이 거버넌스 보존 모드로 보호되고 사용자에게 s3:BypassGovernanceRetention 권한이 있는 경우 보호를 우회하고 버전을 영구적으로 삭제할 수 있습니다. 자세한 내용은 거버넌스 모드 우회를 참조하세요.

• 객체 버전이 법적 보존으로 보호되는 경우 영구 DELETE 요청으로 인해 액세스 거부(403 금지) 오류가 발생할 수 있습니다. 객체 버전을 영구적으로 삭제하려면 객체 버전에 대한 법적 보존를 제거해야 합니다. 법적 보존을 제거하려면 s3:PutObjectLegalHold 권한이 있어야 합니다. 보존을 제거하는 방법에 대한 자세한 내용은 S3 객체 잠금 구성 섹션을 참조하세요.

• 액세스 포인트의 구성

• 액세스 포인트에 사용되는 IAM 사용자 정책

• 크로스 계정 액세스 포인트를 관리하거나 구성하는 데 사용되는 버킷 정책

액세스 포인트 구성 및 정책

• 액세스 포인트를 만들 때 인터넷 또는 VPC를 네트워크 오리진으로 지정할 수 있습니다. 네트워크 오리진이 VPC로만 설정된 경우 Amazon S3는 지정된 VPC에서 시작되지 않은 액세스 포인트에 대한 모든 요청을 거부합니다. 액세스 포인트의 네트워크 오리진을 확인하려면 Virtual Private Cloud(VPC)로 제한된 액세스 포인트 생성 섹션을 참조하세요.

• 액세스 포인트를 사용하여 사용자 지정 퍼블릭 액세스 차단 설정을 구성할 수도 있습니다. 이 설정은 버킷 또는 계정 수준의 퍼블릭 액세스 차단 설정과 유사하게 작동합니다. 사용자 지정 퍼블릭 액세스 차단 설정을 확인하려면 액세스 포인트에 대한 퍼블릭 액세스 관리 섹션을 참조하세요.

• 액세스 포인트를 사용하여 Amazon S3에 성공적으로 요청하려면 요청자에게 필요한 IAM 권한이 있는지 확인하세요. 자세한 내용은 액세스 포인트를 사용하도록 IAM 정책 구성 단원을 참조하십시오.

• 요청에 크로스 계정 액세스 포인트가 포함된 경우, 버킷 소유자가 액세스 포인트에서 온 요청을 승인하도록 버킷 정책을 업데이트했는지 확인하세요. 자세한 내용은 크로스 계정 액세스 포인트에 대한 권한 부여 단원을 참조하십시오.