AWS re:Post을(를) 사용하면 다음에 동의하게 됩니다. AWS re:Post 이용 약관
AWS re:Postre:Post

S3 REST API 엔드포인트를 내 CloudFront 배포의 오리진으로 사용하고 있습니다. 403 Access Denied 오류가 발생하는 이유는 무엇인가요?

8분 분량
0

내 Amazon CloudFront 배포의 오리진으로 Amazon Simple Storage Service(S3) 버킷을 사용하고 있습니다. S3 REST API 엔드포인트를 오리진 도메인 이름으로 사용하고 있습니다. CloudFront가 Amazon S3에서 403 Access Denied 오류를 반환합니다.

간략한 설명

Access Denied 오류를 해결하려면 배포의 오리진 도메인 이름이 S3 웹 사이트 엔드포인트인지 S3 REST API 엔드포인트인지 확인하세요. 다음 단계에 따라 엔드포인트 유형을 찾으세요.

1.    CloudFront 콘솔을 엽니다.

2.    CloudFront 배포를 선택합니다. 그런 다음 배포 설정을 선택합니다.

3.    오리진 및 오리진 그룹 탭을 선택합니다.

4.    오리진 도메인 이름 및 경로에서 도메인 이름을 검토하세요. 그런 다음 도메인 이름의 형식을 기반으로 엔드포인트 유형을 결정합니다. REST API 엔드포인트는 다음 형식을 사용합니다.

DOC-EXAMPLE-BUCKET.s3.region.amazonaws.com
DOC-EXAMPLE-BUCKET.s3.amazonaws.com

중요: bucket-name.s3.amazonaws.com 형식은 2019년 이후에 출시된 리전에서는 사용할 수 없습니다. 정적 웹 사이트 엔드포인트는 다음 형식을 사용합니다.

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

배포에서 S3 정적 웹 사이트 엔드포인트를 사용하는 경우 403 Access Denied 오류가 발생할 수 있습니다. 자세한 내용을 보려면 CloudFront 배포의 오리진으로 S3 웹 사이트 엔드포인트를 사용하고 있습니다. 403 Access Denied 오류가 발생하는 이유는 무엇인가요?를 참조하세요.

배포에서 REST API 엔드포인트를 사용하는 경우 구성이 다음 요구 사항을 충족하는지 확인하여 Access Denied 오류를 방지하세요.

  • 오리진 액세스 제어(OAC) 또는 오리진 액세스 ID(OAI)를 구성하지 않는 경우 객체에 공개적으로 액세스할 수 있어야 합니다. 또는 AWS 서명 버전 4로 객체를 요청해야 합니다.
  • S3 버킷에 AWS Key Management Service(AWS KMS)로 암호화된 객체가 포함된 경우 OAI 대신 OAC를 사용해야 합니다.
  • S3 버킷 정책은 s3:GetObject에 대한 액세스를 허용해야 합니다.
  • 버킷 정책에서 액세스를 허용하는 경우 S3 버킷을 소유한 AWS 계정이 객체도 소유해야 합니다.
  • 요청된 객체는 S3 버킷에 있어야 합니다.
  • 클라이언트가 배포의 루트를 요청하는 경우 기본 루트 객체를 정의해야 합니다.
  • OAI를 구성한 경우 S3 버킷 정책에 OAI를 포함해야 합니다.
  • OAC를 구성한 경우 CloudFront 서비스 보안 주체가 S3 버킷 정책에 포함되어야 합니다. OAI를 구성한 경우 S3 버킷 정책에 OAI를 포함해야 합니다.
  • OAC 또는 OAI를 구성하지 않는 경우 버킷에서 Amazon S3 퍼블릭 액세스 차단을 꺼야 합니다.

해결 방법

OAC 또는 OAI를 구성하지 않는 경우 AWS Signature Version 4에서 객체를 공개적으로 액세스할 수 있거나 요청해야 합니다.

S3 버킷의 객체에 공개적으로 액세스할 수 있는지 확인하려면 웹 브라우저에서 S3 객체의 URL을 엽니다. 또는 URL에서 curl 명령을 실행합니다.

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

https://DOC-EXAMPLE-BUCKET.s3.amazonaws.com/index.html

웹 브라우저 또는 curl 명령에서 Access Denied 오류가 반환되는 경우 해당 객체는 공개적으로 액세스할 수 없습니다. 객체에 공개적으로 액세스할 수 없는 경우 다음 구성 중 하나를 사용합니다.

AWS Key Management Service(AWS SSE-KMS)로 암호화된 객체

s3 버킷에 AWS Key Management Service(AWS SSE-KMS)로 암호화된 객체가 포함된 경우 OAI 대신 OAC를 사용해야 합니다.

OAC를 설정하여 AWS KMS로 암호화된 객체를 CloudFront에서 제공할 수 있습니다. 이렇게 하려면 CloudFront 서비스 보안 주체에게 키 사용 권한을 부여하는 명령문을 AWS KMS 키 정책에 추가합니다. OAC를 설정하지 않고 AWS KMS로 암호화된 객체를 서비스하려면, Lambda@Edge를 사용하여 S3 버킷에서 암호화된 AWS KMS 키를 제공합니다.

다음 방법 중 하나를 사용하여 버킷의 객체가 AWS KMS로 암호화되었는지 확인합니다.

  • Amazon S3 콘솔을 사용하여 객체의 속성을 볼 수 있습니다. 암호화 대화 상자를 검토합니다. AWS KMS를 선택한 경우 객체는 AWS KMS로 암호화됩니다.
  • AWS Command Line Interface(AWS CLI)를 사용하여 head-object 명령을 실행합니다. 명령이 서버 측 암호화를 aws:kms로 반환하면 객체는 AWS KMS로 암호화됩니다. AWS CLI 명령을 실행할 때 오류가 발생하는 경우, ](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-troubleshooting.html#general-latest)최신 버전의 AWS CLI를 사용하고 있는지 확인[하세요.
    참고: OAI는 AWS KMS로 암호화된 객체 제공을 지원하지 않습니다.

S3 버킷 정책은 s3:GetObject에 대한 액세스를 허용해야 합니다.

S3 REST API 엔드포인트와 함께 배포를 사용하려면 버킷 정책에서 s3:GetObject를 퍼블릭 사용자 또는 CloudFront의 OAI에 허용해야 합니다. 버킷 정책에 s3:GetObject에 대한 명시적 허용문이 있더라도 명시적 거부문이 충돌하지 않는지 확인하세요. 명시적 거부문은 항상 명시적 허용문보다 우선합니다.

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

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

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

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

4.    버킷 정책에서 "Action": "s3:GetObject" 또는 **"Action": "s3:*"**가 포함된 명령문을 검토합니다. 아래 예제 정책에는 CloudFront OAC에 s3:GetObject에 대한 액세스 권한을 부여하는 허용문이 포함되어 있습니다. 또한 s3:GetObject에 대한 CloudFront OAI 액세스 권한을 부여하는 문과 s3:GetObject에 대한 공용 액세스 권한을 부여하는 허용문이 포함되어 있습니다. 하지만 특정 Amazon Virtual Private Cloud(Amazon VPC)에서 요청하지 않는 한 s3:GetObject에는 액세스를 차단하는 명시적 거부문이 있습니다.

{
  "Version": "2012-10-17",
  "Id":
    "PolicyForCloudFrontPrivateContent",
  "Statement": [{
      "Sid": "Allow-OAC-Access-To-Bucket",
        "Effect": "Allow",
        "Principal":
    {
            "Service": "cloudfront.amazonaws.com"
        },
        "Action": "s3:GetObject",

    "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
        "Condition": {
            "StringEquals": {

    "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/EDFDVBD6EXAMPLE"
            }
        }
      },

    {
      "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"
        }
      }
    }
  ]
}

5.    버킷 정책을 수정하여 s3:GetObject에 대한 CloudFront OAI 액세스 또는 퍼블릭 액세스를 차단하는 문을 제거하거나 편집합니다.

참고: CloudFront는 Access Denied 오류의 결과를 최대 5분 동안 캐시합니다. 버킷 정책에서 deny 문을 제거한 후 배포에서 무효화를 실행하여 캐시에서 객체를 제거할 수 있습니다.

S3 버킷 및 객체 소유권

외부 계정 또는 서비스에 버킷 정책을 적용하려면 버킷을 소유한 AWS 계정이 객체도 소유해야 합니다. 버킷 또는 객체는 버킷 또는 객체를 생성한 AWS Identity and Access Management(IAM) ID 계정이 소유합니다.

참고: 객체 소유권 요구 사항은 버킷 정책에서 부여한 액세스에 적용됩니다. 객체의 액세스 제어 목록(ACL)에서 부여한 액세스에는 적용되지 않습니다.

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

1.    이 AWS CLI 명령을 실행하여 버킷 소유자의 S3 표준 ID를 가져옵니다.

aws s3api list-buckets --query Owner.ID

2.다음 명령을 실행하여 객체 소유자의 S3 정식 ID를 가져옵니다.

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

aws s3api list-objects --bucket DOC-EXAMPLE-BUCKET --prefix index.html

3.    정식 ID가 일치하지 않으면 버킷과 객체의 소유자가 다른 것입니다.

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

다음 단계에 따라 객체 소유자를 버킷 소유자로 변경합니다.

1.    객체 소유자의 AWS 계정에서 다음 명령을 실행하여 객체에 할당된 액세스 제어 목록(ACL) 권한을 검색합니다.

aws s3api get-object-acl --bucket DOC-EXAMPLE-BUCKET --key object-name

2.    객체에 버킷 소유자 전체 제어 ACL 권한이 있는 경우 3단계로 건너뛰세요. 객체에 버킷 소유자 전체 제어 ACL 권한이 없는 경우 객체 소유자 계정에서 다음 명령을 실행하세요.

aws s3api put-object-acl --bucket DOC-EXAMPLE-BUCKET
    --key object-name --acl bucket-owner-full-control

3.    버킷 소유자 계정에서 다음 명령을 실행하여 객체 자체를 복사하여 객체 소유자를 변경합니다.

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

참고: 예제 명령의 --storage-class 값을 사용 사례에 해당하는 스토리지 클래스로 변경해야 합니다.

요청된 객체는 버킷에 있어야 합니다.

사용자에게 s3:ListBucket 권한이 없는 경우 누락된 객체에 대해 404 Not Found 오류 대신 Access Denied 오류가 발생합니다. head-object AWS CLI 명령을 실행하여 버킷에 객체가 있는지 확인합니다.

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

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

객체가 버킷에 없는 경우 Access Denied 오류는 404 Not Found 오류를 마스킹하는 것입니다. 누락된 객체와 관련된 문제를 해결합니다.

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

클라이언트가 배포의 루트를 요청하는 경우 기본 루트 객체를 정의해야 합니다.

배포에 기본 루트 객체가 정의되어 있지 않고 요청자에게 s3:ListBucket 액세스 권한이 없는 경우 요청자는 Access Denied 오류를 받게 됩니다. 요청자가 배포의 루트를 요청할 때 404 Not Found 오류 대신 이 오류가 발생합니다.

기본 루트 객체를 정의하려면 기본 루트 객체 지정을 참조합니다.

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

OAC 또는 OAI에 대한 권한

OAC를 구성한 경우 S3 버킷 정책에 CloudFront 서비스 보안 주체가 포함되어야 합니다. OAI를 구성한 경우 OAI가 s3 버킷 정책에 포함되어야 합니다.

버킷 정책에서 OAI를 허용하는지 확인하려면 Amazon S3 콘솔에서 S3 버킷을 여세요. 그런 다음 권한 탭을 선택하고 버킷 정책을 검토합니다. 아래 예제 정책에서 첫 번째 명령문은 OAC가 구성된 경우 CloudFront 서비스 보안 주체에 대한 허용문입니다. 두 번째 명령문은 OAI에 대한 허용문입니다.

{
      "Sid": "Allow-OAC-Access-To-Bucket",
        "Effect": "Allow",
        "Principal": {

    "Service": "cloudfront.amazonaws.com"
        },
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",

    "Condition": {
            "StringEquals": {
                "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/EDFDVBD6EXAMPLE"

    }
     }
      },

{
  "Sid": "1",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin
    Access Identity EAF5XXXXXXXXX"
  },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
}

CloudFront 콘솔을 사용하여 버킷 정책을 업데이트하려면 다음 단계를 따르세요.

1.    CloudFront 콘솔을 열고 배포를 선택합니다.

2.    오리진 및 오리진 그룹 탭을 선택합니다.

3.    S3 오리진을 선택한 다음 편집을 선택합니다.

4.    버킷 액세스 제한에서 예를 선택합니다.

5.    오리진 액세스 ID에서 기존 ID를 선택하거나 새 ID를 생성합니다.

6.    버킷에 읽기 권한 부여에 대해 예, 버킷 정책 업데이트를 선택합니다.

7.    예, 편집을 선택합니다.

OAC 또는 OAI 없이 배포를 위한 퍼블릭 액세스 허용

배포에서 OAC 또는 OAI를 사용하지 않고 AWS Signature Version 4에서 객체를 요청하지 않는 경우 객체에 대한 퍼블릭 액세스를 허용해야 합니다. REST API 엔드포인트가 있는 배포는 공개적으로 읽을 수 있는 객체만 지원하기 때문입니다. 이 경우 버킷에 Amazon S3 퍼블릭 액세스 차단 설정이 적용되지 않았는지 확인해야 합니다. 이러한 설정은 공개 읽기 액세스를 허용하는 권한을 무시합니다. Amazon S3 퍼블릭 액세스 차단 설정은 개별 버킷 또는 AWS 계정에 적용할 수 있습니다.

관련 정보

오리진의 오류 응답 문제 해결

Amazon S3의 403 Access Denied 오류 문제를 해결하려면 어떻게 해야 하나요?

주제
네트워킹 및 콘텐츠 전송
태그
Amazon CloudFront
언어
한국어
AWS 공식
AWS 공식업데이트됨 일 년 전
댓글 없음

관련 콘텐츠