서명된 URL 및 서명된 쿠키 개요

Cloud CDN 서명된 URL 및 서명된 쿠키를 사용하면 승인 요청이 필요한 경우에도 Google Cloud의 글로벌 분산 캐시에서 응답을 제공할 수 있습니다.

Cloud CDN 서명된 URL과 서명된 쿠키는 모두 캐시된 콘텐츠에 대한 액세스를 제어합니다. Google Cloud의 글로벌 분산 캐시에서 콘텐츠를 제공하고자 하고 서명된 URL 또는 서명된 쿠키 중에서 결정하려면 다음 사용 사례 비교를 고려하세요.

서명된 URL

서명된 URL은 요청을 수행하는 데 필요한 제한된 권한과 시간을 제공하는 URL입니다.

사용 사례

일부 시나리오에서 Cloud CDN 콘텐츠에 액세스하기 위해 사용자에게 Google 계정을 요구하지 않으면서 애플리케이션별 로직을 사용하여 액세스를 제어하고자 하려는 경우가 있습니다.

이 사용 사례를 해결하는 일반적인 방법은 제한된 시간 동안 사용자에게 해당 리소스에 대한 읽기 액세스 권한을 부여하는 서명된 URL을 제공하는 것입니다. 서명된 URL을 만들 때 만료 시간을 지정합니다. URL을 아는 사람은 누구나 URL 만료 시간에 도달하거나 URL 서명에 사용된 키가 순환될 때까지 리소스에 액세스할 수 있습니다.

다음과 같은 경우 서명된 URL을 사용합니다.

  • 설치 다운로드와 같은 개별 파일에 대한 액세스를 제한해야 합니다.

  • 사용자가 쿠키를 지원하지 않는 클라이언트 애플리케이션을 사용 중입니다.

서명된 URL 작동 방식

서명된 URL을 사용하면 클라이언트가 추가 승인을 거치지 않고도 비공개 리소스에 임시로 액세스할 수 있습니다. 이를 위해 요청의 특정 요소를 사용자가 생성한 강력한 임의 키로 해시하고 암호화 서명합니다.

요청이 사용자가 제공한 서명된 URL을 사용하는 경우 요청은 요청 콘텐츠를 수신하도록 승인된 요청으로 간주됩니다. Cloud CDN이 사용 가능한 서비스에 대해 잘못된 서명이 포함된 요청을 수신하면 이 요청은 거부되고 백엔드로 전송되어 처리되지 않습니다.

일반적으로 서명된 URL을 가지고 있는 누구나 서명된 URL을 사용할 수 있습니다. 그러나 일반적으로 서명된 URL은 대개 URL이 제공된 클라이언트에서만 사용됩니다. 다른 클라이언트가 이 URL을 사용할 위험을 완화하기 위해 서명된 URL은 사용자가 선택한 시간에 만료됩니다. 서명된 URL이 공유되는 위험을 최소화하려면 가능한 한 빨리 만료되도록 설정하는 것이 좋습니다.

URL에 서명하는 방법

URL에 서명하기 전에 백엔드 서비스, 백엔드 버킷 또는 이 두 가지 모두에 암호화 키를 한 개 이상 만듭니다. 그런 다음 gcloud 명령줄 도구 또는 자체 코드를 사용하여 URL에 서명하고 암호화 해시합니다.

서명된 URL 처리

백엔드에서 서명된 URL을 처리하도록 설정된 경우 Cloud CDN은 서명된 URL이 있는 요청에 특수 처리를 제공합니다. 특히 Signature 쿼리 매개변수가 있는 요청은 서명된 것으로 간주됩니다. 이러한 요청을 받으면 Cloud CDN은 다음 사항을 확인합니다.

  1. HTTP 메서드가 GET 또는 HEAD입니다.
  2. Expires 매개변수가 미래의 시간으로 설정되었습니다.
  3. 요청의 서명이 명명된 키를 사용하여 계산된 서명과 일치합니다.

이러한 검사 중 하나라도 실패하면 403 Forbidden 응답이 제공됩니다. 그렇지 않으면 요청은 백엔드로 프록시 처리되거나 캐시에서 제공됩니다. 특정 기본 URL(Expires 매개변수의 앞부분)의 모든 유효한 서명된 요청은 동일한 캐시 항목을 공유합니다. 서명된 요청의 응답과 서명되지 않은 요청의 응답은 캐시 항목을 공유하지 않습니다. 응답은 사용자가 설정한 만료 시간까지 캐시되고 제공됩니다.

서명된 요청이 필요한 콘텐츠는 Cache-Control 헤더를 사용하여 캐시할 수 없음으로 표시되는 경우가 많습니다. 백엔드를 변경하지 않고 이러한 객체를 Cloud CDN과 호환되도록 만들기 위해 Cloud CDN은 유효한 서명된 URL이 있는 요청에 응답할 때 Cache-Control 헤더를 재정의합니다. Cloud CDN은 콘텐츠를 캐시 가능한 콘텐츠로 처리하고 Cloud CDN 구성에 설정된 max-age 매개변수를 사용합니다. 제공되는 응답에는 백엔드가 생성한 Cache-Control 헤더가 여전히 있습니다.

gcloud 명령줄 도구에서 반환되거나 커스텀 코드로 생성된 URL은 필요에 따라 배포할 수 있습니다. HTTPS는 서명된 URL의 서명 구성요소를 가로채지 못하게 막는 안전한 전송을 제공하므로 HTTPS URL만 서명하는 것이 좋습니다. 마찬가지로 TLS/HTTPS와 같은 보안 전송 프로토콜을 통해 서명된 URL을 배포해야 합니다.

서명된 쿠키

서명된 쿠키는 파일 집합 요청을 위해 제한된 권한과 시간을 제공하는 쿠키입니다.

사용 사례

다음과 같은 경우 서명된 쿠키를 사용합니다.

  • 여러 개의 제한된 파일에 대한 액세스 권한을 제공해야 하는 경우

  • 현재 URL을 변경하지 않으려는 경우

  • 콘텐츠 액세스를 위해 승인을 새로고칠 때마다 URL을 업데이트하지 않으려는 경우

HLS 및 DASH를 사용한 미디어 스트리밍

HTTP 실시간 스트리밍(HLS) 또는 HTTP 동적 적응형 스트리밍(DASH) 프로토콜을 사용하여 동영상 및 오디오 콘텐츠를 제공하는 경우 일반적으로 동영상 및 오디오 세그먼트에 대한 URL 목록이 포함된 매니페스트를 생성합니다. 클라이언트에 다양한 인코딩(코덱, 비트 전송률, 해상도)을 제공하기 위해 각 세그먼트의 인스턴스가 여러 개 있을 수 있습니다.

Cloud CDN의 서명된 URL을 사용하여 이러한 각 URL의 액세스를 서명하고 승인할 수 있지만 사용자별로 가능한 모든 조합을 동적으로 생성하는 것은 부담스럽고 원본 부하와 애플리케이션 복잡성을 증가시킵니다.

서명된 쿠키는이 문제를 해결하기 위해 설계되었습니다. 미디어 매니페스트를 개별적으로 생성하거나 서명할 필요 없이 정책(URL 프리픽스 및 만료일)과 일치하는 모든 콘텐츠에 액세스할 수 있도록 승인하는 서명된 쿠키를 사용자에게 제공할 수 있습니다. 페이지 탐색 또는 네이티브 애플리케이션의 기타 백그라운드 메커니즘에서 JavaScript fetch() API를 통해 사용자 액세스를 주기적으로 새로고칠 수 있습니다. 또한 사용자 액세스를 새로고치는 기능을 통해 짧은 만료 시간을 사용할 수 있으므로 사용자가 보호되는 콘텐츠를 공유하기가 더 어려워집니다.

이러한 쿠키를 여러 브라우저 클라이언트 및 기타 HTTP 지원 클라이언트(예를 들어 Google의 ExoPlayer, iOS의 AVPlayer)가 있는 사용자에게 보낼 수 있습니다.

바이너리 다운로드(게임)

미디어 스트리밍과 마찬가지로, 게임 클라이언트 다운로드를 제공하는 경우 대용량 멀티 기가바이트 패치 또는 게임 데이터를 더 작은 단위로 분할하여 세분화된 캐싱, 무효화, 동시 실행을 지원할 수 있습니다.

이러한 단위는 일반적으로 매니페스트에 나열됩니다. 서명된 쿠키를 사용하면 매니페스트를 수정하지 않고, 또한 서명된 URL과 마찬가지로 Cloud CDN 캐싱의 이점을 버리지 않으면서 인증된 사용자에게만 다운로드에 대한 액세스 권한을 승인할 수 있습니다.

서명된 쿠키의 작동 방식

서명된 쿠키를 구성하고 발급하려면 다음 3단계를 따라야 합니다.

  • 지정된 백엔드 서비스의 서명 키 만들기
  • 허용된 URL 프리픽스, 만료, 키 이름, 암호화 서명을 사용하여 쿠키 값 생성
  • 애플리케이션 코드에서 쿠키 발급

Cloud CDN은 요청에 포함된 서명된 쿠키의 유효성을 검사합니다.

Cloud Storage 버킷을 사용할 때 사용자가 서명된 쿠키 제어를 우회하지 못하도록 방지할 수 있습니다. 이렇게 하려면 allUsers 역할을 삭제하고 Cloud CDN 서비스 계정에 버킷에 대한 읽기 액세스 권한을 부여하여 기본 버킷에 대한 액세스를 제한합니다.

마찬가지로, 가상 머신(VM) 인스턴스는 인스턴스가 제공하는 모든 서명된 요청에서 서명을 검증해야 합니다.

주의사항 및 제한사항

  • 서명된 쿠키에 필요한 모든 동의 및 개인정보 보호 규정 준수에 대한 책임은 전적으로 귀하에게 있습니다. 서명된 쿠키는 Google이 아닌 귀하가 발급하고 관리합니다.

  • 서명된 URL과 서명된 쿠키를 모두 사용하여 동일한 파일에 대한 액세스를 제어하고, 뷰어가 서명된 URL을 사용하여 파일을 요청하는 경우 Cloud CDN은 서명된 URL만을 기준으로 뷰어에게 파일을 반환할지 여부를 결정합니다. Cloud CDN은 URL이 서명되지 않은 경우에만 서명된 쿠키를 고려합니다.

  • 서명된 요청에 대해 서비스를 구성했고 URL에 Signature가 쿼리 매개변수로 포함되는 경우 Cloud CDN은 URL을 서명된 URL로 해석하려고 시도합니다. Cloud CDN이 의도하지 않은 URL을 서명된 URL로 취급하려고 시도할 경우 대부분 URL이 유효한 서명된 URL이 아니므로 Cloud CDN에서 거부됩니다.

  • 브라우저 및 기타 클라이언트는 일반적으로 RFC 6265에 따라 쿠키 크기(쿠키당 4KB)와 도메인당 총 수(50개)를 제한합니다. 도메인에서 전송된 총 쿠키 페이로드를 고려하세요.

  • 백엔드당 최대 3개의 서명된 요청 키를 포함하여 Cloud CDN 한도 및 제한사항이 적용됩니다.

  • 서명된 요청은 기존 Cloud CDN 요청과 다르게 청구되지 않습니다. 하지만 만료되거나 기타 유효하지 않은 서명과 같이 실패한(거부된) 요청에는 여전히 캐시 조회 비용이 발생합니다.

다음 단계

  • 특정 URL에 대한 사용자 액세스 범위를 지정하려면 서명된 URL 사용을 참조하세요.
  • 특정 URL 프리픽스에 대한 사용자 액세스 범위를 지정하려면 서명된 쿠키 사용을 참조하세요.