☰

S3 버킷에 대한 도메인 액세스가 거부되었습니다.

tag-icon • tag-icon domain-name-system amazon-web-services amazon-s3 dns-zone dns-hosting
S3 버킷에 대한 도메인 액세스가 거부되었습니다.

안녕하세요. 내 도메인에서 AccessDenied를 수신하는 데 문제가 있습니다.

내 사이트를 AWS S3 버킷에 업로드하고 공개하고 정적 페이지를 생성하지만 domain.com/mypage를 통해 액세스하면 AccessDenied가 발생합니다.

aws mydomain.s3.amazonaws.com/mypage에서는 정상적으로 작동합니다.

내 도메인 DNS는 다음과 같이 설정됩니다.

;; ANSWER SECTION:
mydomain.com. 2101 IN CNAME mydomain.s3.amazonaws.com.
mydomain.s3.amazonaws.com. 41342 IN CNAME s3-1-w.amazonaws.com.
s3-1-w.amazonaws.com.   219 IN  CNAME   s3-w.us-east-1.amazonaws.com.
s3-w.us-east-1.amazonaws.com. 3 IN  A   52.217.69.36

이 문제를 해결하기 위한 조언이 있나요?

답변1

이것은Amazon 지원 문서에서:

간단한 설명:

액세스 거부 오류를 해결하려면 배포의 원본 도메인 이름이 S3 웹 사이트 엔드포인트인지 S3 REST API 엔드포인트인지 확인하세요. 엔드포인트 유형을 결정하려면 다음 단계를 따르세요.

  1. CloudFront 콘솔을 엽니다.
  2. CloudFront 배포를 선택한 다음 배포 설정을 선택합니다.
  3. 오리진 및 오리진 그룹 탭을 선택합니다.
  4. 오리진 및 오리진 그룹 탭을 선택합니다.

원본 도메인 이름 및 경로 아래에서 도메인 이름을 검토한 후 도메인 이름 형식에 따라 엔드포인트 유형을 결정합니다.

REST API 엔드포인트는 다음 형식을 사용합니다.

DOC-EXAMPLE-BUCKET.s3.amazonaws.com

메모: Amazon S3 버킷 이름 지정 규칙을 따라야 합니다.

웹사이트 엔드포인트는 다음 형식을 사용합니다.

DOC-EXAMPLE-BUCKET.s3-website-us-east-1.amazonaws.com

메모: AWS 리전에 따라 엔드포인트 형식은 대시 형식(s3-website-Region) 또는 점 형식(s3-website.Region)을 사용할 수 있습니다.

배포가 REST API 엔드포인트를 사용하는 경우 S3 REST API 엔드포인트를 CloudFront 배포의 오리진으로 사용하고 있습니다를 참조하세요.403 액세스 거부 오류가 발생하는 이유는 무엇입니까?

배포가 웹 사이트 엔드포인트를 사용하는 경우 액세스 거부 오류를 방지하려면 다음 요구 사항을 확인하십시오.

  1. 버킷의 객체는 공개적으로 액세스할 수 있어야 합니다.
  2. 버킷의 객체는 AWS Key Management Service(AWS KMS)로 암호화할 수 없습니다.
  3. 버킷 정책은 s3:GetObject에 대한 액세스를 허용해야 합니다.
  4. 버킷 정책이 퍼블릭 읽기 액세스 권한을 부여하는 경우 버킷을 소유한 AWS 계정은 객체도 소유해야 합니다. 5.요청된 객체가 버킷에 존재해야 합니다.
  5. 버킷에서 Amazon S3 퍼블릭 액세스 차단을 비활성화해야 합니다.
  6. 요청자 지불이 활성화된 경우 요청에는 request-payer 매개변수가 포함되어야 합니다.
  7. Referer 헤더를 사용하여 CloudFront에서 S3 오리진으로의 액세스를 제한하는 경우 사용자 지정 헤더를 검토하십시오.

메모: 공개를 허용하지 않으려면(익명의) S3 객체에 액세스한 다음 S3 REST API 엔드포인트를 배포 원본으로 사용하도록 구성을 변경합니다. 그런 다음 원본 액세스 ID(OAI)를 사용하여 액세스를 제한하도록 배포 및 S3 버킷을 구성합니다. 지침은 CloudFront를 사용하여 Amazon S3에서 호스팅되는 정적 웹 사이트를 제공하려면 어떻게 해야 합니까?에서 REST API 엔드포인트를 OAI에 의해 액세스가 제한된 오리진으로 사용을 참조하십시오.

해결

버킷의 객체는 공개적으로 액세스할 수 있어야 합니다.

웹사이트 엔드포인트를 사용한 배포는 공개적으로 액세스 가능한 콘텐츠만 지원합니다. S3 버킷의 객체에 공개적으로 액세스할 수 있는지 확인하려면 웹 브라우저에서 객체의 URL을 엽니다. 또는 URL에서 컬 명령을 실행할 수 있습니다.

다음은 S3 객체의 URL 예시입니다.

http://DOC-EXAMPLE-BUCKET.s3-website-us-east-1.amazonaws.com/index.html

웹 브라우저 또는 컬 명령이 액세스 거부 오류를 반환하는 경우 객체에 공개적으로 액세스할 수 없습니다.

다음 방법 중 하나로 객체에 대한 공개 읽기 액세스를 허용합니다.

  1. 버킷의 모든 객체에 대한 퍼블릭 읽기 액세스를 허용하는 버킷 정책을 생성합니다.
  2. Amazon S3 콘솔을 사용하여 객체에 대한 퍼블릭 읽기 액세스를 허용합니다.
  3. 버킷의 객체는 AWS KMS로 암호화될 수 없습니다.
  4. CloudFront 배포는 AWS KMS로 암호화된 객체를 지원하지 않습니다. 배포를 사용하여 제공하려는 S3 객체에서 KMS 암호화를 제거해야 합니다.

메모: AWS KMS 암호화를 사용하는 대신 AES-256을 사용하여 객체를 암호화합니다.

버킷의 객체가 KMS로 암호화되었는지 확인하려면 다음 방법 중 하나를 사용하십시오.

Amazon S3 콘솔을 사용하여 객체의 속성을 봅니다. 암호화 대화 상자를 검토합니다. AWS-KMS를 선택한 경우 객체는 KMS로 암호화됩니다. AWS 명령줄 인터페이스(AWS CLI)를 사용하여 head-object 명령을 실행합니다. 명령이 ServerSideEncryption을 aws:kms로 반환하면 객체는 KMS로 암호화됩니다. 참고: AWS CLI 명령을 실행할 때 오류가 발생하면 최신 버전의 AWS CLI를 사용하고 있는지 확인하십시오. Amazon S3 콘솔을 사용하여 객체의 암호화 설정을 변경하려면 S3 객체에 암호화를 추가하려면 어떻게 해야 합니까?를 참조하십시오.

다음을 사용하여 객체의 암호화 설정을 변경하려면AWS CLI, 먼저 객체의 버킷에 기본 암호화가 없는지 확인하세요. 버킷에 기본 암호화가 없으면 다음 명령을 실행하여 객체 자체를 복사하여 객체의 암호화를 제거합니다.

aws s3 cp s3://DOC-EXAMPLE-BUCKET/index.html s3://DOC-EXAMPLE-BUCKET/index.html

경고: 객체 자체를 복사하면 스토리지 클래스 및
웹 사이트 리디렉션 위치에 대한 설정이 제거됩니다. 새 객체에서 이러한 설정을 유지하려면 복사 요청에 Storage-class 또는 website-redirect-location 값을 명시적으로 지정해야 합니다.

버킷 정책은 s3:GetObject에 대한 액세스를 허용해야 합니다. S3 웹 사이트 엔드포인트와 함께 배포를 사용하려면 버킷 정책에 s3:GetObject 작업에 대한 공개 읽기 액세스를 차단하는 거부 문이 없어야 합니다.

버킷 정책에 s3:GetObject에 대한 명시적 허용 문이 있더라도 충돌하는 명시적 거부 문이 없는지 확인하세요. 명시적인 거부 문은 항상 명시적인 허용 문보다 우선합니다.

s3:GetObject에 대한 버킷 정책을 검토하려면 다음 단계를 따르세요.

  1. Amazon S3 콘솔에서 S3 버킷을 엽니다.

  2. 권한 탭을 선택합니다.

  3. 버킷 정책을 선택합니다.

  4. "Action": "s3:GetObject" 또는 "Action": "s3:*"이 포함된 문에 대한 버킷 정책을 검토합니다.

다음 예제 정책에는 s3:GetObject에 대한 공개 액세스를 위한 명시적 허용 문이 포함되어 있습니다. 그러나 요청이 특정 Amazon Virtual Private Cloud(Amazon VPC)에서 오는 경우를 제외하고 액세스를 차단하는 s3:GetObject에 대한 명시적 거부 문도 있습니다.

{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Sid": "Allow-OAI-Access-To-Bucket",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity EAF5XXXXXXXXX"
            },
            "Action": "s3:GetObject",
            "Resource": [
                "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
            ]
        },
        {
            "Sid": "Allow-Public-Access-To-Bucket",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": [
                "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
            ]
        },
        {
            "Sid": "Access-to-specific-VPCE-only",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": [
                "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
            ],
            "Condition": {
                "StringNotEquals": {
                    "aws:sourceVpce": "vpce-1a2b3c4d"
                }
            }
        }
    ]
  }
  1. s3:GetObject에 대한 공개 읽기 액세스를 차단하는 명령문을 제거하거나 편집하려면 버킷 정책을 수정하십시오.

메모: CloudFront는 오류 캐싱 최소 TTL에 지정된 시간 동안 액세스 거부 오류 결과를 캐시합니다. 기본값은 1분입니다. 버킷 정책에서 거부 문을 제거한 후 배포에서 무효화를 실행하여 캐시에서 객체를 제거할 수 있습니다.

버킷 정책이 퍼블릭 읽기 액세스 권한을 부여하는 경우 버킷을 소유한 AWS 계정은 객체도 소유해야 합니다. 버킷 정책에서 객체에 대한 퍼블릭 읽기 액세스를 허용하려면 버킷을 소유한 AWS 계정이 객체도 소유해야 합니다. 버킷 또는 객체는 해당 버킷 또는 객체를 생성한 AWS Identity and Access Management(IAM) 자격 증명의 계정이 소유합니다.

메모: 객체 소유권 요구 사항은 버킷 정책에 의해 부여된 퍼블릭 읽기 액세스에 적용됩니다. 객체의 ACL(액세스 제어 목록)에 의해 부여된 공개 읽기 액세스에는 적용되지 않습니다.

버킷과 객체의 소유자가 동일한지 확인하려면 다음 단계를 따르세요.

  1. 버킷 소유자의 S3 정식 ID를 얻으려면 다음 AWS CLI 명령을 실행하십시오.
aws s3api list-buckets --query Owner.ID
  1. 객체 소유자의 S3 정식 ID를 얻으려면 다음 명령을 실행하십시오.

참고: 이 예에서는 단일 개체를 보여 주지만 list 명령을 사용하여 여러 개체를 확인할 수 있습니다.

aws s3api list-objects --bucket DOC-EXAMPLE-BUCKET --prefix index.html
  1. 정식 ID가 일치하지 않으면 버킷과 객체의 소유자가 다른 것입니다.

참고: Amazon S3 콘솔을 사용하여 버킷 및 객체 소유자를 확인할 수도 있습니다. 소유자는 해당 버킷 또는 객체의 권한 탭에서 찾을 수 있습니다.

객체 소유자를 버킷 소유자로 변경하려면 다음 단계를 따르세요.

  1. 객체 소유자의 계정에서 다음 명령을 실행하여 객체에 할당된 ACL 권한을 검색합니다.
aws s3api get-object-acl --bucket DOC-EXAMPLE-BUCKET --key object-name
  1. 객체에 버킷 소유자 전체 제어 ACL 권한이 있는 경우 3단계로 건너뜁니다. 객체에 bucket-owner-full-control ACL 권한이 없으면 객체 소유자의 계정에서 다음 명령을 실행합니다.
aws s3api put-object-acl --bucket DOC-EXAMPLE-BUCKET --key object-name --acl bucket-owner-full-control
  1. 버킷 소유자의 계정에서 다음 명령을 실행하여 객체 자체를 복사하여 객체의 소유자를 변경합니다.
aws s3 cp s3://DOC-EXAMPLE-BUCKET/index.html s3://DOC-EXAMPLE-BUCKET/index.html

요청된 객체가 버킷에 있어야 합니다.사용자에게 s3:ListBucket 권한이 없으면 사용자에게 404 찾을 수 없음 오류 대신 누락된 객체에 대한 액세스 거부 오류가 표시됩니다. head-object AWS CLI 명령을 실행하여 버킷에 객체가 있는지 확인합니다.

메모: CloudFront로 전송된 객체 요청이 S3 객체 이름과 정확히 일치하는지 확인합니다. S3 객체 이름은 대소문자를 구분합니다. 요청에 올바른 객체 이름이 없으면 Amazon S3는 객체가 누락된 것처럼 응답합니다. CloudFront가 Amazon S3에서 요청하는 객체를 식별하려면 서버 액세스 로깅을 사용하십시오.

객체가 버킷에 있으면 액세스 거부 오류가 발생하지 않습니다. 404 찾을 수 없음 오류 마스킹. 액세스 거부 오류를 해결하려면 다른 구성 요구 사항을 확인하세요.

객체가 버킷에 없으면 액세스 거부 오류는 다음과 같습니다. 404 찾을 수 없음 오류 마스킹. 누락된 개체와 관련된 문제를 해결합니다.

메모: 공개 s3:ListBucket 액세스를 활성화하는 것은 보안 모범 사례가 아닙니다. 퍼블릭 s3:ListBucket 액세스를 활성화하면 사용자가 버킷의 모든 객체를 보고 나열할 수 있습니다. 이렇게 하면 사용자에게 객체를 다운로드할 수 있는 권한이 없더라도 객체 메타데이터 세부 정보(예: 키 및 크기)가 사용자에게 노출됩니다.

버킷에서 Amazon S3 퍼블릭 액세스 차단을 비활성화해야 합니다.버킷에 Amazon S3 퍼블릭 액세스 차단 설정이 적용되지 않았는지 확인합니다. 이러한 설정은 공개 읽기 액세스를 허용하는 권한을 재정의할 수 있습니다. Amazon S3 퍼블릭 액세스 차단 설정은 개별 버킷 또는 AWS 계정에 적용될 수 있습니다.

요청자 지불이 활성화된 경우 요청에 request-payer 매개변수가 포함되어야 합니다. 버킷에서 요청자 지불이 활성화된 경우 버킷에 대한 익명 액세스가 허용되지 않습니다. 다른 계정의 사용자는 버킷에 요청을 보낼 때 request-payer 매개변수를 지정해야 합니다. 그렇지 않으면 해당 사용자에게 액세스 거부 오류가 발생합니다.

Referer 헤더를 사용하여 CloudFront에서 S3 오리진으로의 액세스를 제한하는 경우 사용자 지정 헤더를 검토하십시오. Referer 헤더를 사용하여 CloudFront에서 S3 웹 사이트 엔드포인트 오리진으로의 액세스를 제한하는 경우 비밀 값 또는 토큰 세트를 확인하십시오. S3 버킷 정책에 대해 그런 다음 비밀 값 또는 토큰이 CloudFront 원본 사용자 지정 헤더의 값과 일치하는지 확인합니다.

버킷 정책에서 명시적인 거부 문을 사용하는 경우 Referer 헤더를 기반으로 액세스 권한을 부여하는 허용 문도 있는지 확인하세요. 명시적인 거부 문만으로는 액세스 권한을 부여할 수 없습니다.

예를 들어, 다음 버킷 정책은 요청에 문자열이 포함된 경우 S3 오리진에 대한 액세스 권한을 부여합니다. "aws:리퍼러":"MY_SECRET_TOKEN_CONFIGURED_ON_CLOUDFRONT_ORIGIN_CUSTOM_HEADER":

{
  "Version":"2012-10-17",
  "Id":"http referer policy example",
  "Statement":[
    {
      "Sid":"Allow get requests originating from my CloudFront with referer header",
      "Effect":"Allow",
      "Principal":"*",
      "Action":"s3:GetObject",
      "Resource":"arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
      "Condition":{
        "StringLike":{"aws:Referer":"MY_SECRET_TOKEN_CONFIGURED_ON_CLOUDFRONT_ORIGIN_CUSTOM_HEADER"}
      }
    }
  ]
}

이 예제 버킷 정책에서 CloudFront 원본 사용자 지정 헤더는 다음과 같아야 합니다.

  • 머리글: 추천인
  • 값:MY_SECRET_TOKEN_CONFIGURED_ON_CLOUDFRONT_ORIGIN_CUSTOM_HEADER

메모: 예제 버킷 정책은 Principal이 와일드카드 값("Principal":"*")이기 때문에 버킷에 대한 퍼블릭(익명) 액세스 권한을 부여합니다. 그러나 조건문으로 인해 요청에 Referer 헤더가 포함되어 있고 헤더 값이 버킷 정책의 값과 일치하는 경우에만 S3 오리진에 대한 액세스가 허용됩니다.

관련 정보