Amazon CloudFront 오리진 액세스 제어(OAC)로 S3 오리진 보호하기

Amazon CloudFront는 애플리케이션, 웹 사이트, 비디오, API를 전 세계 시청자에게 밀리초 단위로 안전하게 제공하는 글로벌 콘텐츠 전송 네트워크입니다. CloudFront를 사용하면 고객은 다양한 유형의 오리진 서비스에 자신의 사용 사례에 맞게 액세스할 수 있습니다. 고객이 채택하는 사용하기 적합한 아키텍처 중 하나는 Amazon S3를 웹 사이트와 비디오와 같은 콘텐츠를 호스팅하는 원본으로 사용하고 CloudFront를 사용하여 시청자에게 전달하는 것입니다. 현재 이 아키텍처를 사용할 경우 고객은 CloudFront의 오리진 액세스 ID(OAI)를 활용하여 CloudFront를 통해서만 S3 오리진 접근을 허용하도록 하여 S3 오리진을 보호합니다.

오리진 액세스 제어(OAC)

OAI는 CloudFront에서 S3 오리진에 접근하는 안전한 방법을 제공하지만 세분화된 정책 구성, AWS Signature Version 4(SigV4)가 요구되고 POST method를 사용하는 HTTP/HTTPS 요청, AWS KMS를 사용한 서버 측 암호화(SSE-KMS)를 적용을 지원하지 않는 등의 제한 사항이 있습니다. 보안을 강화하고 심화된 기능 통합을 위해 지정된 배포에만 접근을 허용함으로써 S3 오리진을 보호하는 새로운 기능인 오리진 액세스 제어(OAC)를 소개합니다. OAC는 IAM 서비스 보안 주체를 사용하여 S3 오리진을 인증하는 AWS 모범 사례를 기반으로 합니다. OAI와 비교하여 OAC가 제공하는 주목할 만한 개선 사항 중 일부는 다음과 같습니다.

보안 – OAC는 단기 자격 증명, 빈번한 자격 증명 교체 및 리소스 기반 정책과 같은 향상된 보안 방식으로 구현됩니다. 배포의 보안 태세를 강화하고 혼동된 대리자 문제와 같은 공격에 대해 보다 나은 보호를 제공합니다.
포괄적인 HTTP 메서드 지원 – OAC는 GET, PUT, POST, PATCH, DELETE, OPTIONS 및 HEAD를 지원합니다.
SSE-KMS – OAC는 SSE-KMS로 암호화된 S3 객체 다운로드 및 업로드를 지원합니다.
모든 AWS 리전에서 S3 접근 – OAC는 기존 리전과 향후 추가될 모든 리전을 포함한 모든 AWS 리전에서 S3에 접근하는 것을 지원합니다. 반면 OAI는 기존 AWS 리전과 2022년 12월 이전에 출시된 리전에서만 지원됩니다.

OAC를 사용할 때 일반적인 요청 및 응답 워크플로는 다음과 같습니다. 1. 클라이언트는 HTTP 또는 HTTPS 요청을 CloudFront로 보냅니다. 2. CloudFront 엣지 로케이션은 요청을 수신합니다. 요청 객체가 아직 캐시되지 않은 경우 CloudFront는 OAC 서명 프로토콜(현재 SigV4 지원)을 사용하여 요청에 서명합니다. 3. S3 오리진은 요청을 인증, 승인 또는 거부합니다. OAC를 구성할 때 “Do not sign requests(요청 서명 안 함)”, “Sign requests(서명 요청)” 및 서명은 하지만 “Do not override authorization header(승인 헤더 재정의 안 함)” (그림 1) 세 개 중 하나를 선택할 수 있습니다. 다음은 각 서명 동작 옵션에 대한 OAC의 예상 동작에 대해 알아보겠습니다.

그림 1. OAC 서명 동작 옵션

“Sign requests(서명 요청)” 옵션

“서명 요청” 옵션을 구성하면 CloudFront IAM 서비스 보안 주체가 각 요청에 SigV4로 서명합니다. 그러면 서명과 추가 데이터가 포함되어 S3 오리진으로 전송될 Authorization 헤더를 만듭니다. S3 오리진이 이 요청을 받으면 동일한 단계를 수행하여 받은 요청에 대한 서명을 계산하고 계산된 서명을 CloudFront로부터 받은 서명과 비교합니다. 서명이 일치하면 요청이 처리되고 서명이 일치하지 않으면 요청이 거부됩니다.
“서명 요청” 옵션을 사용하면 CloudFront는 수신 요청에 클라이언트 응용 프로그램에서 서명한 Authorization 헤더가 이미 있는 경우에도 항상 클라이언트로부터 받은 요청에 서명합니다. 이 경우 CloudFront는 클라이언트의 Authorization 헤더를 삭제하고 CloudFront의 자격 증명으로 다시 서명하여 S3 오리진으로 보낼 새 Authorization 헤더를 생성합니다.
CloudFront는 항상 들어오는 요청에 서명하기 때문에 대부분의 고객은 “서명 요청” 옵션을 사용하여 애플리케이션이 항상 작동하도록 하는 것이 좋습니다. 또한 CloudFront가 요청에 서명하면 클라이언트와 CloudFront 간에 전송되는 데이터의 양이 줄어들어 애플리케이션의 성능이 향상됩니다.

“Do not override authorization header(승인 헤더 재정의 안 함)” 옵션

클라이언트 애플리케이션이 요청에 서명할 수 있고 다양한 캐시 동작, 파일 디렉터리, HTTP 메서드, 엣지 컴퓨터 호출과 같은 속성을 기반으로 클라이언트 서명 및 CloudFront 서명 인증 헤더 간 전환이 포함되는 사용 사례의 경우 “서명 요청”을 선택 후 “승인 헤더 재정의 안 함” 하위 옵션을 사용할 수 있습니다. 예를 들어 S3 업로드 권한을 클라이언트 애플리케이션으로 제한하고 S3 다운로드 권한을 CloudFront에 할당하려는 경우 이 옵션을 활성화할 수 있습니다. 이 예에서는 S3 버킷 정책을 그에 따라 구성해야 클라이언트의 승인만 업로드를 수행할 수 있습니다.
또한 CloudFront에서는 헤더를 명시적으로 오리진으로 전달할 수 있도록 허용해야 하므로 클라이언트 Authorization 헤더를 오리진으로 전달하기 위해 캐시 정책에서 Authorization 헤더를 허용해야 합니다. “승인 헤더 재정의 안 함” 하위 옵션은 활성화되고 클라이언트의 Authorization 헤더는 허용되지 않는 경우 CloudFront는 클라이언트의 Authorization 헤더를 삭제하고 CloudFront의 자격 증명으로 다시 서명하여 Authorization 헤더를 생성 후 S3 오리진으로 요청을 보냅니다.

“Do not sign requests(요청 서명 안 함)” 옵션

“요청 서명 안 함” 옵션은 CloudFront가 S3 오리진으로부터 받은 어떠한 요청에도 서명하지 않도록 합니다. 클라이언트 애플리케이션이 항상 요청에 서명하거나 S3 버킷이 퍼블릭인 경우(모범 사례가 아님) 이 옵션을 선택할 수 있습니다. “요청 서명 안 함” 옵션은 오리진 액세스 제어를 사용하지 않는 것과 동일합니다. 이 옵션은 다수의 CloudFront 배포에 대한 OAC 서명 동작 옵션을 변경하려는 경우 유용합니다. 예를 들어, 이전에 “서명 요청”을 사용하여 OAC를 구성했고 100개의 오리진과 연결된 경우입니다. 이제 클라이언트가 요청에 서명하도록 하려면 100개 오리진에 대한 OAC 연결을 수동으로 변경하는 대신 바로 이 OAC의 구성을 “요청에 서명하지 않음”으로 변경하면 됩니다. 그러면 CloudFront는 100개 오리진에 대한 서명 요청을 중지합니다.
이제 각 옵션에 대한 OAC의 서명 동작에 대해 알아보았습니다. 이제 OAC를 구성할 수 있는 방법을 살펴보겠습니다. 또한 OAC와 함께 작동하도록 KMS 정책을 구성할 수 있는 방법에 대해서도 알아보겠습니다.

새 CloudFront 배포 생성 시 OAC 구성

AWS Management Console에 로그인한 다음 https://console.thinkwithwp.com/cloudfront/v3/home 에서 CloudFront 콘솔을 엽니다.
배포 생성(Create Distribution)을 선택합니다.
원본(Origin) 구성의 원본 도메인(Origin domain) 드롭다운 목록에서 S3 오리진을 선택합니다.
오리진 요청 시 원본 도메인 이름에 추가할 원본 경로(origin path)를 선택적으로 구성할 수 있습니다.
현재 원본 구성을 고유하게 식별하는 이름을 입력합니다.
원본 액세스 제어 설정을 선택합니다. (그림 2)

그림 2. 배포 생성 시 원본 액세스 구성

기존 원본 액세스 제어를 선택하거나 세 가지 서명 동작 옵션 중 하나를 사용하여 새 제어 설정을 생성할 수 있습니다. (그림 1)
나머지 설정을 구성하는 방법에 대한 자세한 방법은 여기를 참조하시기 바랍니다.
모든 구성 설정을 완료하고 페이지 하단에서 원본 생성(Create distribution)을 선택합니다.
배포가 완료되면 S3 버킷 정책을 업데이트해야 합니다. 배포 세부 정보 페이지에
제공된 정책 설명을 참조할 수 있습니다. (그림 3)
제공된 정책에는 S3에서 객체를 읽을 수 있는 권한만 포함되어 있습니다. S3에 객체를 업로드하려면 “s3:PutObject“에 대한 권한을 추가하여 정책을 업데이트해야 합니다.

그림 3. 배포 세부 정보 페이지

기존 CloudFront 배포를 업데이트할 때 OAC 구성

AWS Management Console에 로그인한 다음 https://console.thinkwithwp.com/cloudfront/v3/home에서 CloudFront 콘솔을 엽니다.
목록에서 변경할 배포를 선택합니다.
원본(Origins) 탭을 선택하고 오리진 액세스 제어(OAC) 설정과 연결할 S3 오리진을 선택합니다.
오리진이 S3 버킷 액세스를 사용하지 않는 경우 “공개”로 표시됩니다. 오리진이 이미 OAI를 사용 중인 경우 “Legacy access identifies” 표시됩니다. OAC를 사용하려면 “원본 액세스 제어 설정”을 선택하고 기존 원본 액세스 제어를 선택하거나 세 가지 서명 동작 옵션 중 하나를 사용하여 새 제어 설정을 만듭니다.

그림 4. 기존 배포 업데이트

CloudFront IAM 서비스 보안 주체와 배포 리소스가 S3 버킷에 액세스할 수 있도록 하려면 S3 정책을 업데이트해야 합니다. 배포가 생성된 후에만 정책을 업데이트할 수 있는 배포 생성 시 원본 액세스를 구성하는 것과 달리 배포 업데이트 시 서비스 다운타임을 없애기 위해 OAI와 OAC 모두에 대한 액세스를 허용하도록 정책을 업데이트하여 오리진 구성을 저장하는 것이 좋습니다. 다음은 OAI 와 OAC 모두에 대한 액세스를 허용하는 샘플 정책입니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipalReadOnly",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::ACCOUNT_ID:distribution/DISTRIBUTION_ID"
        }
    }
  },
  {
    "Sid": "AllowLegacyOAIReadOnly",
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity EH1HDMB1FH2TC"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
    }
  ]
}

배포를 생성할 때 OAC 구성과 마찬가지로 CloudFront에서 제공하는 정책에는 S3에서 객체를 읽을 수 있는 권한만 포함됩니다. S3에 객체를 업로드하려면 “s3:PutObject“에 대한 권한을 추가하여 정책을 업데이트해야 합니다.
페이지 하단 변경 사항 저장(Save)을 선택합니다.

CloudFront OAC용 SSE-KMS 활성화

AWS Well-Architected 는 전송 중 데이터와 저장된 데이터를 보호하는 것을 권장합니다. OAI를 사용하는 경우 데이터는 이미 전송 중에 보호되며, Amazon S3 관리형 키를 사용한 서버 측 암호화(SSE-S3)를 사용하여 저장된 데이터를 보호할 수 있습니다. 조직에서 S3 버킷에 저장된 콘텐츠를 암호화하는 데 AWS Key Management Service에 저장된 KMS 키를 사용한 서버 측 암호화(SSE-KMS)를 사용해야 하는 경우라면 이제 OAC를 사용하여 SSE-KMS로 암호화된 S3 객체에 액세스하는 것이 가능합니다. 이를 위해 CloudFront IAM 서비스 보안 주체가 KMS 키에 액세스할 수 있도록 KMS 정책을 구성해야 합니다. aws:SourceArn 조건을 추가하면 특정 CloudFront 배포만 해당 키 정책을 사용하여 SSE-KMS 암호화 객체에 액세스할 수 있습니다. 아래 구성 단계를 참고하시기 바랍니다.

AWS Management Console에 로그인하고 https://console.thinkwithwp.com/kms 에서 AWS Key Management Service(AWS KMS)콘솔을 엽니다.
S3 오리진 콘텐츠를 암호화하는 데 사용되는 고객 관리형 키를 선택합니다.
키 정책 탭을 선택합니다.
CloudFront 서비스 보안 주체가 액세스할 수 있도록 KMS 키 정책을 업데이트합니다.

{
  "Sid": "Allow use of the key",
  "Effect": "Allow",
  "Principal": {
    "Service": [
      "cloudfront.amazonaws.com"
    ]
  },
  "Action": [
    "kms:Decrypt",
    "kms:Encrypt",
    "kms:GenerateDataKey*"
  ],
  "Resource": "*",
  "Condition":{
    "StringEquals":{
      "aws:SourceArn": "arn:aws:cloudfront::ACCOUNT_ID:distribution/DISTRIBUTION_ID"
    }
  }
}

OAC로 마이그레이션해야 합니까?

OAI 로 구성된 CloudFront 배포가 이미 있는 경우 OAI에서 OAC로 마이그레이션해야 하는지 여부를 고민할 수 있습니다. 최신 보안 모범 사례 및 추가 기능을 위해 OAC를 사용하는 것이 좋지만 CloudFront는 새로운 OAC와 기존 OAI를 모두 지원합니다. CloudFront 배포가 OAI를 사용하도록 구성되어 있더라도 몇 번만 클릭하면 OAC로 손쉽게 마이그레이션할 수 있습니다. OAI를 사용하는 모든 배포는 정상적으로 동작하고 새 배포에 OAI를 계속 사용할 수 있습니다. 향후 추가될 리전에 대한 제한 사항은 CloudFront 오리진 액세스 마이그레이션 설명서를 참조하십시오.

이제 오리진 액세스 제어(OAC) 를 사용할 수 있습니다.

CloudFront 오리진 액세스 제어는 이제 AWS 중국 리전을 제외한 전 세계에서 사용할 수 있습니다. CloudFront 콘솔, API, SDK 또는 CLI를 통해 OAC 사용을 시작할 수 있습니다. OAC를 사용하기 위한 추가 비용은 없습니다. OAC를 구성하는 방법에 대해 알아보려면 CloudFront 오리진 액세스 제어 설명서를 참조하십시오. CloudFront를 시작하려면 CloudFront 제품 페이지를 방문하십시오.

이 글은 AWS Networking & Content Delivery 블로그의 Amazon CloudFront introduces Origin Access Control (OAC)을 기반으로 정유진 AWS 솔루션즈 아키텍트가 한국어로 번역 및 편집하였습니다.

Amazon Web Services 한국 블로그