개요

오리진 클로킹은 웹 애플리케이션의 공격 표면을 줄이는 것을 목표로 하는 일련의 기법입니다. 모범 사례는 DDoS 공격 및 원치 않는 봇에 대한 보호와 같은 보안 제어가 적용되는 웹 애플리케이션에 대한 단일 진입점으로 CloudFront를 사용하는 것입니다. 오리진 클로킹은 방화벽 규칙을 사용하여 CloudFront 진입점에서 오지 않는 트래픽을 차단함으로써 악의적인 공격자가 CloudFront와 CloudFront의 보안 제어를 우회하여 오리진을 직접 공격하는 것을 방지합니다. 오리진 클로킹은 OSI 모델의 여러 계층에서 구현될 수 있습니다.

네트워크 계층

오리진에서 인바운드 네트워크 액세스를 제어할 수 있는 경우 제한을 추가하여 CloudFront 네트워크에서 들어오는 트래픽만 허용합니다.

오리진이 EC2 인스턴스, Application Load Balancer 또는 Network Load Balancer인 경우 오리진을 VPC의 프라이빗 서브넷에 보관하고 CloudFront의 VPC 오리진 기능을 활용할 수 있습니다. 이를 통해 자체 AWS 계정에서 VPC 오리진으로 구성된 CloudFront 배포에 대한 액세스만 제한할 수 있습니다.

VPC 오리진

이러한 리소스를 퍼블릭 서브넷(예: 여러 CDN에서 ALB에 액세스할 수 있음)에 배치해야 하거나 CloudFront의 VPC 오리진에서 지원하지 않는 오리진 유형을 사용하는 경우 보안 그룹을 통해 CloudFront에 대한 액세스를 제한할 수 있습니다. 오리진을 보안 그룹에 연결하고, 여기에 Amazon CloudFront용 AWS 관리형 접두사 목록을 추가해야 합니다.

오리진이 온프레미스에 있는 경우 CloudFront의 오리진 기반 IP 주소를 나열하도록 허용하여 CloudFront에 대한 액세스를 제한할 수 있습니다. 이 주소는 서비스 필드의 CLOUDFRONT_ORIGIN_FACING 값을 기준으로 필터링하면 이 IP 목록에서 찾을 수 있습니다. 이 접근 방식에서는 ACL을 업데이트하려면 IP 변경 사항을 구독해야 합니다. 서드 파티 방화벽을 사용하여 온프레미스 웹 서버에 오리진 클로킹을 구현하는 방법을 알아보려면 이 블로그 게시물을 확인하세요. 인터넷으로부터 격리하려면 Direct Connect 연결에서 퍼블릭 가상 인터페이스를 사용하여 온프레미스 인프라와 AWS 간에 AWS Direct Connect를 설정하는 것을 고려해 보세요.

네트워크 계층에서의 액세스 제어는 시작점이지만 충분하지 않을 수 있습니다. 예를 들어, 누군가 온프레미스에서 오리진 도메인 이름을 발견하면 자체 AWS 계정에 CloudFront 배포를 생성하고 자체 배포를 우회할 수 있습니다. 또 다른 예로, VPC 오리진 기능을 사용할 때는 오리진을 AWS 계정의 VPC 오리진으로 구성된 모든 CloudFront 배포에 액세스하는 대신 오리진을 AWS 계정의 특정 CloudFront 배포로 제한할 수도 있습니다. 이 경우 애플리케이션 계층 액세스 제어를 통한 하드닝을 고려하세요.

애플리케이션 계층

오리진 액세스 제어

CloudFront의 기능인 오리진 액세스 제어(OAC)를 사용하면 일부 유형의 오리진을 CloudFront에 매우 간단하게 잠글 수 있습니다. 오리진 액세스 제어(OAC)는 IAM 정책을 기반으로 AWS Signature Version 4 알고리즘(sigv4)을 사용하여 기본적으로 특정 유형의 오리진에 대한 요청에 서명합니다. 현재 OAC는 S3, MediaStore, MediaPackage, Lambda 함수 URL 및 S3 Object Lambda와 호환됩니다. OAC를 S3와 함께 사용하면 S3 버킷 정책에 따라 CloudFront에 독점적으로 액세스하여 S3 버킷을 비공개로 유지할 수 있습니다.

OAC에서 오리진 유형을 지원하지 않는 경우 엣지 함수를 사용하여 오리진에 대한 요청에 서명할 수 있습니다. 예시 구현은 다음 블로그에 설명되어 있습니다.

공유 보안 암호 키를 기반으로 한 액세스 제어

오리진에서 요청 서명을 지원하지 않거나 애플리케이션에 이 수준의 액세스 제어가 필요하다고 생각하지 않는 경우, 오리진에 공유 암호가 포함된 사용자 지정 헤더를 전송하도록 CloudFront를 구성할 수 있습니다. 그러면 오리진에서 이를 검증하여 요청을 처리할 수 있습니다. 다음 예시 구현을 살펴보세요.

  • ALB 기반 오리진. ALB 규칙을 사용하거나 ALB가 이미 AWS WAF WebACL과 연결되어 있는 경우 AWS WAF 규칙을 사용하여 ALB 기반 오리진의 보안 헤더를 검증할 수 있습니다.
  • API Gateway 기반 오리진. API 키를 사용하여 API Gateway에서 보안 헤더를 검증할 수 있습니다.
  • NGINX 기반 오리진. CloudFront에서 값이 abc123인 사용자 지정 헤더 X-CloudFront를 전송한다고 가정하면, /etc/nginx/nginx.conf Nginx 구성 파일의 서버 태그에 다음 코드를 추가하여 Nginx 기반 웹 서버(클라우드 기반 또는 온프레미스 기반)에서 보안 헤더를 검증할 수 있습니다.

    if ($http_x_cloudfront != "abc123") {
        return 403;
    }
  • Apache 기반 오리진. CloudFront에서 값이 abc123인 사용자 지정 헤더 X-CloudFront를 전송한다고 가정하면, httpd.conf 구성 파일(및 사용되는 경우 ssl.conf 파일)에 다음 코드를 추가하여 Apache 기반 웹 서버(클라우드 기반 또는 온프레미스 기반)에서 보안 헤더를 검증할 수 있습니다.

    RewriteEngine On
    RewriteCond %{HTTP:x-cloudfront} !^abc123$ [NC]
    RewriteRule ^ - [F]

모든 경우에 이 공유된 보안 암호를 정기적으로 교체하여 보안 암호 유출 위험을 줄이는 것이 좋습니다. 위에서 공유한 샘플 구현에서 API Gateway와 ALB를 사용한 구현에는 모두 보안 암호 교체 자동화가 포함되어 있습니다.

이 페이지의 내용이 도움이 되었나요?

 피드백