서명된 요청 사용

서명된 요청을 만들려면 보호하려는 콘텐츠를 기술하는 매개변수와 서명 값의 만료 시간이 포함된 문자열을 작성합니다. 그런 후 작성된 문자열을 요청에 포함합니다. Media CDN는 서명된 요청이 유효한지 확인한 후 그에 따라 작업을 수행합니다.

서명된 요청 요구사항

서명된 요청은 다음 요구사항을 충족해야 합니다.

• GET, HEAD, OPTIONS HTTP 메서드를 포함합니다. 다른 메서드는 지원되지 않습니다.

• 미래의 만료 시간을 설정합니다. 연결 해제 및 재시도와 같은 클라이언트 네트워크 조건은 물론 잠재적인 시계 동기화 차이로 인해 타임스탬프를 향후 1분 이상 또는 동영상 스트림 길이 큰 값으로 설정하는 것이 좋습니다.

• EdgeCacheKeyset에서 키 또는 보안 비밀로 확인할 수 있는 서명을 지정합니다.

POST, PUT, DELETE 요청과 같은 다른 HTTP 모듈은 서명할 수 없습니다. 사용자 대상 업로드를 위해 서명된 URL을 발급해야 하는 경우 서명된 URL을 위한 Cloud Storage 문서를 참조하세요.

보안 고려사항

Media CDN은 REQUIRE_SIGNATURES 또는 REQUIRE_TOKENS의 cdnPolicy.signedRequestMode로 구성된 경로와 일치하는 모든 요청을 검증합니다.

참고: 원본에서 요청을 검증하는 것이 가장 좋습니다. Media CDN이 서명이 필요한 경로에 대해 유효하지 않고 서명되지 않은 요청을 거부하지만 클라이언트가 원본에 직접 액세스할 수 있는 방법을 찾을 수 있습니다. 추가 검증 레이어는 콘텐츠 보호를 위한 심층 방어 방법을 제공합니다.

다음 표에서는 Media CDN이 요청을 검증하는 시나리오에 대해 설명합니다.

요청에 서명이 있음	서명이 유효한가요?	signedRequestMode	동작	응답 코드
아니요	해당 사항 없음	REQUIRE_SIGNATURES 또는 REQUIRE_TOKENS	서명 또는 토큰이 없는 요청은 서명이 유효하지 않은 것으로 취급됩니다.	HTTP 403
예	아니요	REQUIRE_SIGNATURES 또는 REQUIRE_TOKENS	만료되었거나 일치하지 않는 URL 또는 잘못된 키가 포함된 경우 서명 또는 토큰이 유효하지 않은 것으로 간주됩니다. 유효하지 않은 서명 또는 토큰은 CDN 에지에서 거부됩니다.	HTTP 403
예	예	REQUIRE_SIGNATURES 또는 REQUIRE_TOKENS	캐시의 콘텐츠 또는 원본에서 가져오기를 통해 서명 또는 토큰과 응답을 검증합니다.	HTTP 200
예	예	없음 또는 DISABLED	검증이 수행되지 않고 응답이 사용자에게 직접 제공됩니다.	HTTP 200
예	아니요	없음 또는 DISABLED	검증이 수행되지 않고 응답이 사용자에게 직접 제공됩니다.	HTTP 200

애플리케이션이 잘못된 서명을 감지하면 HTTP 403 (Forbidden) 응답 코드로 응답하는지 확인합니다. HTTP 403 응답 코드를 캐시할 수 없습니다.

주의: 애플리케이션이 캐시 가능한 응답 코드를 잘못된 요청에 보내면 유효한 향후 요청이 부당하게 거부될 수 있습니다.

서명된 요청 구성

다음 섹션에서는 서명된 요청을 구성, 서명, 검증하는 방법을 자세히 설명합니다.

키 생성

Media CDN이 요청을 서명하는 데 사용하는 키를 만듭니다.

키 세트 만들기

Media CDN이 서명된 요청에 대해 사용하는 키 세트를 만듭니다.

서명된 요청 필요

서명된 요청만 리소스에 액세스하도록 하려면 경로에 키 목록을 연결하고 signedRequestMode를 다음 중 하나로 설정합니다.

• REQUIRE_SIGNATURES: 토큰을 사용하지 않는 서명된 요청의 경우

• REQUIRE_TOKENS: 토큰을 사용하는 서명된 요청의 경우

경로에 서명된 요청을 사용 설정하면 모든 요청이 서명되었거나 토큰을 포함해야 합니다. 유효한 서명이 없는 요청(예: 유효하지 않은 키 이름, 만료된 서명 또는 토큰, 일치하지 않는 서명 등)은 실패합니다.

EdgeCacheKeyset는 키 순환에 허용할 여러 키를 포함할 수 있습니다. 나열된 키로 서명된 유효한 요청이 수락되고 키가 순서대로 시도됩니다. 키 순환에 대한 자세한 내용은 보안 비밀 순환을 참조하세요.

signedRequestMode가 REQUIRE_SIGNATURES 또는 REQUIRE_TOKENS로 설정되었으면 Media CDN이 캐시 적중과 캐시 부적중을 모두 검증합니다. 여기에는 원본에 대한 모든 요청이 포함됩니다.

다음은 지정된 PathMatcher(경로)에서 서명된 요청을 강제 적용하는 Media CDN 구성의 예시입니다.

gcloud edge-cache services describe prod-media-service

결과:

...
  routeAction:
    cdnPolicy:
      cacheMode: CACHE_ALL_STATIC
      signedRequestMode: REQUIRE_SIGNATURES
      signedRequestKeyset: prod-vod-keyset

서명된 요청에 대해 토큰을 만드는 방법은 토큰 생성을 참조하세요.

요청 서명을 사용 중지하려면 signedRequestMode를 DISABLED로 설정하고 signedRequestKeyset에 대한 참조를 삭제합니다.

원본에서 요청 검증

경로가 REQUIRE_SIGNATURES의 서명 모드로 구성되었을 때 Media CDN은 모든 일치하는 요청에 유효한 서명이 포함되었는지 검증합니다. 서명 부족은 이러한 경로에 대해 유효하지 않은 서명으로 취급됩니다.

서명이 잘못 구성되고 사용자가 원본에 직접 액세스하려고 시도하는 경우를 방지하기 위해서는 요청이 원본에서도 서명되어 있는지 검증하는 것이 좋습니다. 콘텐츠 보호에 대한 심층 방어 접근 방법은 라이선스 및 유료 콘텐츠에 대한 무단 액세스 및 다운로드를 방지하는 데 도움이 됩니다.

서명이 쿼리 매개변수의 일부이거나 URL 경로 구성요소로 포함된 URL 기반 서명 메서드의 경우 요청이 원본에 전송되기 전에 서명 및 관련 매개변수가 URL에서 삭제됩니다. 이렇게 하면 원본이 요청을 처리할 때 서명이 라우팅 문제를 일으키지 않도록 방지됩니다. 이러한 요청을 검증하기 위해서는 서명된 구성요소를 삭제하기 전 원본(서명된) 클라이언트 요청 URL이 포함된 x-client-request-url 요청 헤더를 조사할 수 있습니다.

참고: Cloud Storage를 사용 중이고 allUsers(공개 액세스) 권한을 삭제한 경우 Cloud Storage는 사용자를 대신한 인증되지 않은 공개 액세스를 거부합니다.

원본에서 요청을 검증하려면 요청 서명 엔드포인트의 일부와 동일한 검증 코드를 사용해서 키 불일치 문제와 키 순환으로 인한 문제를 해결하는 데 도움을 얻을 수 있습니다.

키 순환

권장사항에 따라 Media CDN에서 사용되는 보안 비밀을 정기적으로 순환 또는 업데이트하는 것이 좋습니다. 30일~60일마다 키를 순환하는 것이 좋지만 엄격하게 요구되지는 않습니다.

다음 단계

• 로그 전반의 필터링 및 쿼리 방법을 포함하여 Media CDN 로그를 사용 설정 및 액세스하는 방법을 자세히 알아보려면 Logging을 참조하세요.

• Media CDN 및 비공개 Cloud Storage 버킷을 구성하려면 원본 연결 및 보호를 참조하세요.