원본 액세스 ID를 사용하여 Amazon S3 콘텐츠에 대한 액세스 제한 - Amazon CloudFront

원본 액세스 ID를 사용하여 Amazon S3 콘텐츠에 대한 액세스 제한

Amazon S3 버킷에서 제공하는 콘텐츠에 대한 액세스를 제한하려면 다음 단계를 수행하세요.

  1. 원본 액세스 ID(OAI)라는 특수 CloudFront 사용자를 만들어 배포와 연결합니다.

  2. CloudFront에서 OAI를 사용하여 버킷의 파일을 액세스해 사용자에게 제공할 수 있도록 S3 버킷 권한을 구성합니다. 사용자가 S3 버킷에 대한 직접 URL을 사용하여 파일에 액세스할 수 없도록 해야 합니다.

이 단계를 수행하면 사용자가 S3 버킷에서 직접 액세스하지 않고 CloudFront를 통해서만 파일에 액세스할 수 있습니다.

일반적으로 Amazon S3 버킷을 CloudFront 배포의 오리진으로 사용하는 경우 모든 사용자에게 해당 버킷의 파일에 액세스하도록 허용하거나 액세스를 제한할 수 있습니다. 예를 들어, CloudFront 서명된 URL 또는 서명된 쿠키를 사용해 액세스를 제한하는 경우 사용자가 단순히 파일에 대한 직접 Amazon S3 URL을 사용하여 파일을 보는 것도 원치 않을 것입니다. 대신, 보호가 작동하도록 CloudFront URL을 사용해야만 파일에 액세스하도록 허용할 수 있습니다. 서명된 URL 및 서명된 쿠키 사용에 대한 자세한 내용은 서명된 URL과 서명된 쿠키를 사용하여 프라이빗 콘텐츠 제공 단원을 참조하세요.

이 주제는 OAI를 설정하고 S3 파일에 대한 액세스를 안전하게 유지하기 위한 권한을 부여하는 방법을 자세히 설명합니다.

중요

웹 사이트 엔드포인트로 구성된 Amazon S3 버킷을 사용하는 경우 CloudFront를 사용자 지정 오리진으로 사용하여 버킷을 설정해야 합니다. 이 주제에서 설명하는 원본 액세스 ID 기능은 사용할 수 없습니다. 그러나, 사용자 지정 헤더를 설정하고 해당 헤더가 필요하도록 오리진을 구성하여 사용자 지정 오리진의 콘텐츠에 대한 액세스를 제한할 수 있습니다. 자세한 내용은 사용자 지정 오리진의 파일에 대한 액세스 제한 단원을 참조하세요.

OAI 설정 개요

Amazon S3 버킷을 CloudFront 배포의 오리진으로 처음 설정하면 모든 사용자에게 버킷의 파일에 대한 권한을 부여하게 됩니다. 이렇게 하면 누구나 CloudFront 또는 Amazon S3 URL을 통해 파일에 액세스할 수 있습니다. CloudFront는 Amazon S3 URL을 공개하지 않지만, 애플리케이션이 Amazon S3에서 직접 객체를 제공하거나 누군가가 Amazon S3의 특정 파일에 대한 직접 링크를 제공하는 경우 사용자가 해당 URL을 가지게 될 수 있습니다.

CloudFront 서명된 URL 또는 서명된 쿠키를 사용하여 Amazon S3 버킷의 파일에 대한 액세스를 제한하는 경우에는 Amazon S3 URL로 Amazon S3 파일에 액세스하는 사용자도 차단하는 것이 좋습니다. 사용자가 Amazon S3에서 직접 파일에 액세스하는 경우 CloudFront 서명된 URL 또는 서명된 쿠키를 통한 제어를 우회하게 됩니다. 여기에는 사용자가 더 이상 콘텐츠에 액세스할 수 없는 날짜 및 시간에 대한 제어와 콘텐츠에 액세스하는 데 사용할 수 있는 IP 주소에 대한 제어가 포함됩니다. 또한 사용자가 CloudFront를 통해서도 파일에 액세스하고 직접 Amazon S3 URL을 통해서도 액세스하는 경우 CloudFront 액세스 로그가 불완전하여 유용성이 떨어집니다.

URL 서명 여부와 관계없이 오직 CloudFront URL로만 파일에 액세스할 수 있게 하려면 다음 작업을 수행하세요.

  1. 특별한 CloudFront 사용자인 원본 액세스 ID를 만들고 배포와 연결합니다. 원본 액세스 ID를 오리진과 연결하여 Amazon S3 콘텐츠 중 일부 또는 전부를 보호할 수 있습니다. 또한 원본 액세스 ID를 만들고 배포를 생성한 후 배포에 추가할 수 있습니다. 자세한 내용은 CloudFront OAI 생성 및 배포에 추가 단원을 참조하십시오.

  2. 원본 액세스 ID만 읽기 권한(또는 읽기 및 다운로드 권한)을 가지도록 Amazon S3 버킷 또는 버킷의 파일에 대한 권한을 변경합니다. 사용자가 CloudFront를 통해 Amazon S3 파일에 액세스할 때, CloudFront 원본 액세스 ID가 사용자를 대신해 파일을 가져옵니다. 사용자가 Amazon S3 URL을 사용하여 직접 파일을 요청하면 액세스가 거부됩니다. Amazon S3 버킷에 있는 파일에 액세스할 수 있는 권한이 원본 액세스 ID에는 있지만 사용자에게는 없습니다. 자세한 내용은 OAI에 Amazon S3 버킷 내 파일 읽기 권한 부여 단원을 참조하십시오.

CloudFront OAI 생성 및 배포에 추가

AWS 계정 하나는 최대 100개의 CloudFront 원본 액세스 ID(OAI)를 가질 수 있습니다. 그러나 OAI 하나를 원하는 수만큼의 배포에 추가할 수 있기 때문에 보통 하나면 충분합니다.

OAI를 만들지 않은 상태에서 배포를 만들 때 배포에 OAI를 추가해야 한다면 CloudFront 콘솔 또는 CloudFront API를 사용하여 OAI를 만들고 추가할 수 있습니다.

참고

OAI를 만들려면 CloudFront 콘솔 또는 CloudFront API 버전 2009-09-09 이상을 사용해야 합니다.

OAI 생성 및 배포에 추가

배포를 생성할 때 OAI를 만들지 않은 경우 다음 작업을 수행합니다.

CloudFront 콘솔을 사용하여 CloudFront OAI를 생성하려면

  1. AWS Management Console에 로그인하여 https://console.aws.amazon.com/cloudfront/에서 CloudFront 콘솔을 엽니다.

  2. S3 오리진이 있는 배포의 ID를 선택합니다.

  3. Origins and Origin Groups(오리진 및 오리진 그룹) 탭을 선택합니다.

  4. 오리진 옆의 확인란을 선택한 다음 Edit(편집)을 선택합니다.

  5. Restrict Bucket Access(버킷 액세스 제한)에서 를 선택합니다.

  6. 사용할 OAI가 이미 있는 경우 Use an Existing Identity(기존 자격 증명 사용)를 선택합니다. 그런 다음 Your Identities(사용자 자격 증명) 목록에서 OAI를 선택합니다.

    참고

    OAI가 이미 있는 경우 이것을 재사용하여 유지 관리를 간소화하는 것이 좋습니다.

    OAI를 만들려면 Create a New Identity(새 자격 증명 만들기)를 선택합니다. Comment(설명) 필드의 버킷 이름을 사용자 지정 설명으로 바꿀 수 있습니다.

  7. CloudFront가 오리진 도메인 이름(Origin Domain Name)에 지정된 Amazon S3 버킷의 파일에 대한 읽기 권한을 자동으로 OAI에 부여하도록 하려면 예, 버킷 정책을 업데이트합니다.(Yes, Update Bucket Policy)를 선택합니다.

    중요

    예, 버킷 정책을 업데이트합니다.(Yes, Update Bucket Policy)를 선택하면 CloudFront는 버킷 권한을 업데이트하여 지정된 OAI에 버킷 파일 읽기 권한을 부여합니다. 그러나 CloudFront가 기존 권한을 제거하지는 않습니다. 현재 Amazon S3 URL을 통해 버킷 파일에 액세스할 수 있는 사용자는 CloudFront에서 버킷 권한을 업데이트한 후에도 동일한 권한을 가집니다. 기존 버킷 권한을 확인 또는 제거하려면 Amazon S3에서 제공하는 메서드를 사용하세요.

    Amazon S3 버킷의 권한을 수동으로 업데이트하려면 아니요, 권한을 업데이트하겠습니다(No, I Will Update Permissions)를 선택합니다. 자세한 내용은 OAI에 Amazon S3 버킷 내 파일 읽기 권한 부여 단원을 참조하세요.

  8. 예, 편집합니다를 선택합니다.

  9. 오리진이 여러 개 있을 경우 이 절차를 반복하여 각 오리진에 대한 OAI를 추가합니다.

CloudFront API를 사용하여 OAI 생성

원본 액세스 ID가 이미 있어서 새로 만들지 않고 기존 ID를 재사용하려는 경우, CloudFront API를 사용하여 배포에 OAI 추가 단원으로 건너뛰세요.

CloudFront API를 사용하여 CloudFront OAI를 생성하려면 POST Origin Access Identity API 작업을 사용합니다. 응답에는 새 OAI에 대한 IdS3CanonicalUserId가 포함됩니다. 프로세스 후반에 이러한 값을 사용할 것이므로 기록해 두십시오.

  • Id 요소Id 요소의 값을 사용하여 OAI를 배포와 연결합니다.

  • S3CanonicalUserId 요소 – Amazon S3 객체 ACL을 사용하여 OAI에 Amazon S3 객체에 대한 액세스 권한을 부여할 때 S3CanonicalUserId 요소의 값을 사용합니다.

자세한 내용은 Amazon CloudFront API 참조CreateCloudFrontOriginAccessIdentity를 참조하세요.

CloudFront API를 사용하여 배포에 OAI 추가

CloudFront API를 사용하여 CloudFront OAI를 기존 배포에 추가하거나 OAI를 포함하는 새로운 배포를 만들 수 있습니다. 두 경우 모두 OriginAccessIdentity 요소를 포함합니다. 이 요소는 OAI를 만든 후 Id API 작업에서 반환된 POST Origin Access Identity 요소 값을 포함합니다. OriginAccessIdentity 요소를 한 개 이상의 오리진에 추가할 수 있습니다.

Amazon CloudFront API 참조에서 다음 주제를 참조하세요.

OAI에 Amazon S3 버킷 내 파일 읽기 권한 부여

배포를 만들거나 업데이트할 때 원본 액세스 ID(OAI)를 추가하고 Amazon S3 버킷 정책을 자동으로 업데이트하여 버킷에 액세스할 수 있는 권한을 OAI에 부여합니다. 또는 버킷 정책을 수동으로 생성 또는 업데이트하거나 버킷의 개별 파일에 대한 액세스를 제어하는 객체 ACL을 사용할 수 있습니다.

어떤 방법을 사용하든 권한을 검토하여 다음 사항을 확인하십시오.

  • CloudFront를 통해 파일을 요청하는 최종 사용자를 대신하여 CloudFront OAI가 버킷의 파일에 액세스할 수 있습니다.

  • 최종 사용자는 Amazon S3 URL을 사용하여 CloudFront 외부의 파일에 액세스할 수 없습니다.

중요

CloudFront가 지원하는 모든 HTTP 메서드를 수락하고 전달하도록 CloudFront를 구성하는 경우 CloudFront OAI에 원하는 권한을 부여해야 합니다. 예를 들어 DELETE 메서드를 사용하는 요청을 수락하고 전달하도록 CloudFront를 구성하는 경우, 삭제해도 되는 파일만 최종 사용자가 삭제할 수 있도록 DELETE 요청을 적절히 처리할 수 있는 버킷 정책 또는 객체 ACL을 구성합니다.

다음을 참조하십시오.

  • 객체 ACL보다 Amazon S3 버킷 정책을 업데이트하는 것이 더 쉽습니다. 권한을 업데이트하지 않고도 파일을 버킷에 추가할 수 있기 때문입니다. 그러나 각 개별 파일에 권한을 부여하기 때문에 ACL은 더 세부적인 제어가 가능합니다.

  • 기본적으로 Amazon S3 버킷과 그 안에 있는 모든 파일은 비공개입니다. 버킷을 만든 AWS 계정만 안에 있는 파일을 읽거나 쓸 수 있는 권한이 있습니다.

  • 다른 AWS 계정이 버킷에 파일을 업로드하는 경우, 그 계정이 해당 파일의 소유자가 됩니다. 버킷 정책은 버킷 소유자가 소유한 파일에만 적용됩니다. 즉, 다른 계정에서 내 버킷에 파일을 업로드하는 경우 내가 OAI에 대해 생성한 버킷 정책은 해당 파일에 대해 평가되지 않습니다. 이 경우 객체 ACL을 사용하여 OAI에 권한을 부여합니다.

  • OAI를 기존 배포에 추가하는 경우, 파일을 CloudFront 외부에 공개적으로 이용할 수 없도록 버킷 정책 또는 객체 ACL을 수정해야 합니다.

  • 하나 이상의 안전한 관리자 계정에 권한을 추가로 부여하여 Amazon S3 버킷의 콘텐츠를 계속 업데이트할 수 있습니다.

중요

Amazon S3 권한에 대한 변경 사항을 저장한 후 변경 사항이 적용되기까지 약간 지연될 수 있습니다. 변경 사항이 적용되기 전에 버킷의 파일에 액세스하려 하면 “권한 거부” 오류가 발생할 수 있습니다.

Amazon S3 버킷 정책 사용

다음과 같은 방법으로 버킷 정책을 만들거나 업데이트하여 Amazon S3 버킷의 파일에 대한 액세스 권한을 CloudFront OAI에 부여할 수 있습니다.

  • Amazon S3 콘솔에서 Amazon S3 버킷의 권한(Permissions) 탭 사용

  • Amazon S3 API에서 PutBucketPolicy 사용

  • CloudFront 콘솔 사용 OAI를 CloudFront 콘솔의 오리진 설정에 추가할 때 예, 버킷 정책을 업데이트합니다.(Yes, Update Bucket Policy)를 선택하여 사용자를 대신해 버킷 정책을 업데이트하도록 CloudFront에 지시할 수 있습니다.

버킷 정책을 수동으로 업데이트하는 경우 다음 사항을 확인하십시오.

  • 정책에서 올바른 OAI를 Principal로 지정합니다.

  • 최종 사용자를 대신해 객체에 액세스하는 데 필요한 권한을 OAI에 부여합니다.

자세한 내용은 다음 단원을 참조하십시오.

OAI를 Principal로 지정

Amazon S3 버킷 정책에서 OAI를 Principal로 지정하려면 OAI ID가 포함된 OAI의 Amazon 리소스 이름(ARN)을 사용합니다. 예:

"Principal": { "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity EH1HDMB1FH2TC" }

앞의 예제를 사용하려면 EH1HDMB1FH2TC를 OAI의 ID로 대체합니다. OAI의 ID를 찾으려면 CloudFront 콘솔에서 원본 액세스 ID 페이지를 참조하거나 CloudFront API에서 ListCloudFrontOriginAccessIdentities를 사용합니다.

Amazon S3 정식 ID를 사용하여 OAI를 Principal로 지정할 수도 있습니다. 예:

"Principal": { "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" }

앞의 예제를 사용하려면 79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be를 OAI의 정식 ID로 대체합니다. OAI의 ID를 찾는 것과 동일한 방법으로 OAI의 정식 ID를 찾을 수 있습니다.

참고

OAI의 ARN을 사용하여 Principal로 지정할 때의 한 가지 장점은 버킷 정책이 누가 액세스 권한을 부여하는지 쉽게 이해할 수 있다는 것입니다. Amazon S3 정식 ID는 CloudFront OAI뿐 아니라 여러 종류의 AWS 자격 증명을 나타낼 수 있으며 정식 ID가 참조하는 자격 증명을 확인하기가 어려울 수 있습니다. OAI의 ARN을 사용하면 버킷 정책을 보다 쉽게 이해할 수 있습니다.

또한 버킷 정책에서 OAI의 정식 ID를 사용하는 경우 AWS는 이 정식 ID를 OAI의 ARN으로 대체합니다. 즉, OAI의 정식 ID를 지정하는 정책을 작성한 후 나중에 동일한 정책을 보면, 이 정식 ID가 해당 ARN으로 대체되었음을 확인할 수 있습니다. 이러한 이유로 OAI의 ARN을 사용하여 정책을 작성하는 것이 합리적일 수 있습니다.

OAI에 권한 부여

OAI에 Amazon S3 버킷의 객체에 액세스할 수 있는 권한을 부여하려면 정책에서 특정 Amazon S3 API 작업과 관련된 키워드를 사용합니다. 예를 들어 s3:GetObject 권한을 통해 OAI가 버킷의 객체를 읽을 수 있습니다. 자세한 내용은 다음 단원의 예제를 참조하거나 Amazon Simple Storage Service 개발자 안내서정책에서 권한 지정을 참조하세요.

Amazon S3 버킷 정책 예제

다음 예제에서는 CloudFront OAI에 액세스 권한을 부여하는 Amazon S3 버킷 정책을 보여줍니다. 이러한 예제를 사용하려면

예 OAI에 읽기 액세스 권한을 부여하는 Amazon S3 버킷 정책

다음 예제에서는 OAI가 지정된 버킷(s3:GetObject)의 객체를 읽을 수 있도록 허용합니다.

{ "Version": "2012-10-17", "Id": "PolicyForCloudFrontPrivateContent", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity EH1HDMB1FH2TC" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::awsexamplebucket/*" } ] }

예 OAI에 읽기 및 쓰기 액세스 권한을 부여하는 Amazon S3 버킷 정책

다음 예제에서는 OAI가 지정된 버킷(s3:GetObjects3:PutObject)의 객체를 읽고 쓸 수 있도록 허용합니다. 이렇게 하면 최종 사용자가 CloudFront를 통해 Amazon S3 버킷에 파일을 업로드할 수 있습니다.

{ "Version": "2012-10-17", "Id": "PolicyForCloudFrontPrivateContent", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity EH1HDMB1FH2TC" }, "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": "arn:aws:s3:::aws-example-bucket/*" } ] }

Amazon S3 객체 ACL 업데이트

다음과 같은 방법으로 파일의 ACL을 만들거나 업데이트하여 Amazon S3 버킷의 파일에 대한 액세스 권한을 CloudFront OAI에 부여할 수 있습니다.

ACL을 사용하여 OAI에 액세스 권한을 부여하는 경우 Amazon S3 정식 사용자 ID를 사용하여 OAI를 지정해야 합니다. 이는 CloudFront 콘솔의 원본 액세스 ID 페이지에 있는 Amazon S3 정식 사용자 ID 값입니다. CloudFront API를 사용하는 경우, OAI를 만들 때 반환된 S3CanonicalUserId 요소의 값을 사용하거나 CloudFront API에서 ListCloudFrontOriginAccessIdentities를 호출합니다.

Amazon S3 객체 ACL에 대한 자세한 내용은 Amazon Simple Storage Service 개발자 안내서ACL을 사용한 액세스 관리를 참조하세요.

서명 버전 4 인증만 지원하는 Amazon S3 리전에서 OAI 사용

새 Amazon S3 리전에서는 인증된 요청에 대해 서명 버전 4를 사용해야 합니다. 각 Amazon S3 리전에서 지원되는 서명 버전은 Amazon Web Services 일반 참조리전 및 엔드포인트 주제에 있는 Amazon Simple Storage Service(S3)를 참조하세요. 그러나 원본 액세스 ID를 만들어 이를 CloudFront 배포에 추가하는 경우, CloudFront는 일반적으로 Amazon S3 버킷 파일 요청에 대한 인증에 서명 버전 4를 사용합니다. 원본 액세스 ID를 사용 중인데 해당 버킷이 인증에 대해 서명 버전 4를 요구하는 리전에 속하는 경우 다음에 유의해야 합니다.

  • DELETE, GET, HEAD, OPTIONSPATCH 요청은 자격과 관계없이 지원됩니다.

  • PUT 요청을 CloudFront에 제출하여 Amazon S3 버킷에 파일을 업로드하려면 x-amz-content-sha256 헤더를 요청에 추가해야 하고, 헤더 값에 요청 본문의 SHA256 해시가 포함되어야 합니다. 자세한 내용은 Amazon Simple Storage Service API 참조일반 요청 헤더 페이지에서 x-amz-content-sha256 헤더에 대한 설명서를 참조하세요.

  • POST 요청은 지원되지 않습니다.