이 페이지에서는 서명된 URL의 개요와 Cloud CDN에서 서명된 쿠키를 사용하는 방법을 설명합니다. 서명된 URL은 사용자가 Google 계정을 가지고 있는지 여부에 관계없이 URL을 통해 모든 사용자에게 제한된 리소스 액세스 권한을 제공합니다.
서명된 URL은 요청을 수행하는 데 필요한 제한된 권한과 시간을 제공하는 URL입니다. 서명된 URL은 쿼리 문자열에 인증 정보가 포함되어 있어 사용자 인증 정보가 없는 사용자도 리소스에 대한 특정 작업을 수행할 수 있습니다. 서명된 URL을 생성할 때는 URL과 연결된 요청을 수행하기에 충분한 권한이 있어야 하는 사용자 또는 서비스 계정을 지정합니다.
서명된 URL을 생성하면 서명된 URL을 소유한 모든 사람이 이를 사용하여 지정된 기간 내에 객체 읽기와 같은 지정된 작업을 수행할 수 있습니다.
서명된 URL은 선택사항인 URLPrefix 파라미터도 지원하므로 공통 프리픽스를 기반으로 여러 URL에 대한 액세스를 제공할 수 있습니다.
특정 URL 프리픽스에 대한 액세스 범위를 지정하려면 서명된 쿠키를 사용하는 것이 좋습니다.
시작하기 전에
서명된 URL을 사용하기 전에 다음을 수행합니다.
Cloud CDN이 사용 설정되어 있는지 확인합니다. 자세한 내용은 Cloud CDN 사용을 참고하세요. Cloud CDN을 사용 설정하기 전에 백엔드에서 서명된 URL을 구성할 수 있습니다. 하지만 Cloud CDN을 사용 설정할 때까지 효과는 없습니다.
필요한 경우 Google Cloud CLI를 최신 버전으로 업데이트합니다.
gcloud components update
개요는 서명된 URL 및 서명된 쿠키 개요를 참고하세요.
서명된 요청 키 구성
서명된 URL 또는 서명된 쿠키의 키를 만들려면 다음 섹션에 설명된 여러 단계가 필요합니다.
보안 고려사항
Cloud CDN은 다음 상황에서 요청 유효성을 검사하지 않습니다.
- 요청이 서명되지 않았습니다.
- 요청의 백엔드 서비스나 백엔드 버킷에 Cloud CDN이 사용 설정되어 있지 않습니다.
서명된 요청은 응답을 제공하기 전에 항상 원본에서 검증되어야 합니다. 원본은 서명된 콘텐츠와 서명되지 않은 콘텐츠의 혼합을 제공하는 데 사용될 수 있고 클라이언트가 원본에 직접 액세스할 수도 있기 때문입니다.
- Cloud CDN은
Signature쿼리 파라미터 또는Cloud-CDN-CookieHTTP 쿠키가 없는 요청을 차단하지 않습니다. 유효하지 않거나 잘못된 형식의 요청 파라미터가 있는 요청을 거부합니다. - 애플리케이션이 잘못된 서명을 감지하면
HTTP 403 (Unauthorized)응답 코드로 응답하는지 확인합니다.HTTP 403응답 코드를 캐시할 수 없습니다. - 서명된 요청과 서명되지 않은 요청에 대한 응답은 별도로 캐시되므로 유효한 서명된 요청에 대한 성공적인 응답은 서명되지 않은 요청을 제공하는 데 사용되지 않습니다.
- 애플리케이션이 캐시 가능한 응답 코드를 잘못된 요청에 보내면 유효한 향후 요청이 부당하게 거부될 수 있습니다.
Cloud Storage 백엔드의 경우 공개 액세스를 삭제해야 Cloud Storage에서 유효한 서명이 없는 요청을 거부할 수 있습니다.
다음 표에는 동작이 요약되어 있습니다.
| 요청에 서명이 있음 | 캐시 적중 | 동작 |
|---|---|---|
| 아니요 | 아니요 | 백엔드 원본으로 전달합니다. |
| 아니요 | 예 | 캐시에서 제공합니다. |
| 예 | 아니요 | 서명 유효성을 검사합니다. 유효하면 백엔드 원본으로 전달합니다. |
| 예 | 예 | 서명 유효성을 검사합니다. 유효하면 캐시에서 제공합니다. |
서명된 요청 키 만들기
Cloud CDN이 사용 설정된 백엔드 서비스, 백엔드 버킷 또는 둘 다에 하나 이상의 키를 만들어 Cloud CDN 서명된 URL 및 서명된 쿠키에 대한 지원을 사용 설정합니다.
각 백엔드 서비스 또는 백엔드 버킷에 대해 보안 요구 사항에 따라 키를 만들고 삭제할 수 있습니다. 각 백엔드에는 한 번에 키를 최대 3개까지 구성할 수 있습니다. 가장 오래된 키를 삭제하고 새 키를 추가하고 URL 또는 쿠키에 서명할 때 새 키를 사용하여 키를 주기적으로 순환하는 것이 좋습니다.
각 키 집합은 상호 독립적이므로 여러 백엔드 서비스와 백엔드 버킷에서 동일한 키 이름을 사용할 수 있습니다. 키 이름은 최대 63자까지 구성될 수 있습니다. 키 이름을 지정하려면 A~Z, a~z, 0~9, _(밑줄), -(하이픈) 문자를 사용합니다.
사용자 키 중 하나를 가진 사람이 Cloud CDN에서 키가 삭제될 때까지 Cloud CDN이 수락하는 서명된 URL 또는 서명된 쿠키를 만들 수 있으므로 키를 만들 때 보안에 주의해야 합니다. 키는 서명된 URL 또는 서명된 쿠키를 생성하는 컴퓨터에 저장됩니다. 또한 Cloud CDN은 요청 서명을 확인하기 위해 키를 저장합니다.
키를 비밀로 유지하기 위해 키 값은 API 요청에 대한 응답에 포함되지 않습니다. 키를 분실한 경우 새 키를 만들어야 합니다.
서명된 요청 키를 만들려면 다음 단계를 따르세요.
콘솔
- Google Cloud 콘솔에서 Cloud CDN 페이지로 이동합니다.
- 키를 추가할 원본 이름을 클릭합니다.
- 원본 세부정보 페이지에서 수정 버튼을 클릭합니다.
- 원본 기본사항 섹션에서 다음을 클릭하여 호스트 및 경로 규칙 섹션을 엽니다.
- 호스트 및 경로 규칙 섹션에서 다음을 클릭하여 캐시 성능 섹션을 엽니다.
- 제한된 콘텐츠 섹션에서 서명된 URL 및 서명된 쿠키를 사용하여 액세스 제한을 선택합니다.
서명 키 추가를 클릭합니다.
- 새 서명 키의 고유한 이름을 지정합니다.
키 생성 방법 섹션에서 자동 생성을 선택합니다. 또는 직접 입력을 클릭한 다음 서명 키 값을 지정합니다.
이전 옵션의 경우 자동으로 생성된 서명 키 값을 서명된 URL 만들기에 사용할 수 있는 비공개 파일에 복사합니다.
완료를 클릭합니다.
캐시 항목 최대 기간 섹션에서 값을 입력한 후 시간 단위를 선택합니다.
완료를 클릭합니다.
gcloud
gcloud 명령줄 도구는 지정한 로컬 파일에서 키를 읽습니다. 무작위도가 높은 임의의 128비트를 생성하고 base64로 인코딩한 후 문자 +를 -로 대체하고 문자 /를 _로 대체하여 키 파일을 만들어야 합니다. 자세한 내용은 RFC 4648을 참고하세요.
키의 무작위도를 높이는 것이 매우 중요합니다. UNIX 계열 시스템에서는 다음 명령어를 사용하여 무작위도가 높은 임의의 키를 생성하고 키 파일에 저장할 수 있습니다.
head -c 16 /dev/urandom | base64 | tr +/ -_ > KEY_FILE_NAME
백엔드 서비스에 키를 추가하려면 다음 안내를 따르세요.
gcloud compute backend-services \ add-signed-url-key BACKEND_NAME \ --key-name KEY_NAME \ --key-file KEY_FILE_NAME
백엔드 버킷에 키를 추가하려면 다음 안내를 따르세요.
gcloud compute backend-buckets \ add-signed-url-key BACKEND_NAME \ --key-name KEY_NAME \ --key-file KEY_FILE_NAME
Cloud Storage 권한 구성
Cloud Storage를 사용하면서 객체를 읽을 수 있는 사용자를 제한한 경우 Cloud CDN 서비스 계정을 Cloud Storage ACL에 추가하여 객체를 읽을 수 있는 권한을 Cloud CDN에 부여해야 합니다.
서비스 계정을 만들 필요가 없습니다. 서비스 계정은 키를 프로젝트의 백엔드 버킷에 처음 추가할 때 자동으로 생성됩니다.
다음 명령어를 실행하기 전에 프로젝트의 백엔드 버킷에 키를 최소 1개 이상 추가합니다. 그렇지 않으면 프로젝트에 키를 1개 이상 추가할 때까지 Cloud CDN 캐시 채우기 서비스 계정이 생성되지 않으므로 오류가 발생하고 명령어는 실패합니다.
gcloud storage buckets add-iam-policy-binding gs://BUCKET \ --member=serviceAccount:service-PROJECT_NUMBER@cloud-cdn-fill.iam.gserviceaccount.com \ --role=roles/storage.objectViewer
PROJECT_NUMBER를 프로젝트 번호로, BUCKET을 스토리지 버킷으로 바꿉니다.
Cloud CDN 서비스 계정 service-PROJECT_NUMBER@cloud-cdn-fill.iam.gserviceaccount.com은 프로젝트의 서비스 계정 목록에 표시되지 않습니다. 이는 프로젝트가 아닌 Cloud CDN이 Cloud CDN 서비스 계정을 소유하기 때문입니다.
프로젝트 번호에 대한 자세한 내용은 Google Cloud 콘솔 도움말 문서의 프로젝트 ID 및 프로젝트 번호 찾기를 참고하세요.
최대 캐시 시간 맞춤설정
Cloud CDN은 백엔드의 Cache-Control 헤더에 관계없이 서명된 요청에 대한 응답을 캐시합니다. 유효성을 다시 검사하지 않고 응답을 캐시할 수 있는 최대 시간은 signed-url-cache-max-age 플래그를 통해 설정됩니다. 이 플래그의 기본값은 1시간이고 여기에 표시된 대로 이 플래그를 수정할 수 있습니다.
백엔드 서비스 또는 백엔드 버킷의 최대 캐시 시간을 설정하려면 다음 명령어 중 하나를 실행합니다.
gcloud compute backend-services update BACKEND_NAME \ --signed-url-cache-max-age MAX_AGE
gcloud compute backend-buckets update BACKEND_NAME \ --signed-url-cache-max-age MAX_AGE
서명된 요청 키 이름 나열
백엔드 서비스 또는 백엔드 버킷의 키를 나열하려면 다음 명령어 중 하나를 실행합니다.
gcloud compute backend-services describe BACKEND_NAME
gcloud compute backend-buckets describe BACKEND_NAME
서명된 요청 키 삭제
특정 키로 서명된 URL을 더 이상 허용하지 않으려면 다음 명령어 중 하나를 실행하여 백엔드 서비스나 백엔드 버킷에서 해당 키를 삭제합니다.
gcloud compute backend-services \ delete-signed-url-key BACKEND_NAME --key-name KEY_NAME
gcloud compute backend-buckets \ delete-signed-url-key BACKEND_NAME --key-name KEY_NAME
URL 서명
마지막 단계는 URL에 서명하고 이를 배포하는 것입니다. gcloud compute sign-url 명령어를 사용하거나 직접 작성한 코드를 사용하여 URL에 서명할 수 있습니다.
다수의 서명된 URL이 필요한 경우 커스텀 코드를 사용하는 것이 좋습니다.
서명된 URL 만들기
gcloud compute sign-url 명령어를 사용하여 서명된 URL을 만들려면 다음 안내를 따르세요. 이 단계에서는 이미 키를 생성했다고 가정합니다.
콘솔
Google Cloud 콘솔을 사용하여 서명된 URL을 만들 수 없습니다. Google Cloud CLI를 사용하거나 다음 예시를 사용하여 커스텀 코드를 작성할 수 있습니다.
gcloud
Google Cloud CLI에는 URL 서명을 위한 명령어가 포함되어 있습니다. 이 명령어는 코드 직접 작성 섹션에 설명된 알고리즘을 구현합니다.
gcloud compute sign-url \ "URL" \ --key-name KEY_NAME \ --key-file KEY_FILE_NAME \ --expires-in TIME_UNTIL_EXPIRATION \ [--validate]
이 명령어는 KEY_FILE_NAME에서 base64url로 인코딩된 키 값을 읽고 디코딩한 후 지정된 URL의 GET 또는 HEAD 요청에 사용할 수 있는 서명된 URL을 출력합니다.
예를 들면 다음과 같습니다.
gcloud compute sign-url \ "https://example.com/media/video.mp4" \ --key-name my-test-key \ --expires-in 30m \ --key-file sign-url-key-file
URL은 경로 구성요소가 있는 유효한 URL이어야 합니다. 예를 들어 http://example.com는 유효하지 않지만 https://example.com/ 및 https://example.com/whatever는 모두 유효한 URL입니다.
선택적 --validate 플래그를 지정하면 이 명령어는 결과 URL과 함께 HEAD 요청을 보내고 HTTP 응답 코드를 인쇄합니다. 서명된 URL이 올바르면 응답 코드는 백엔드에서 보낸 결과 코드와 동일합니다. 응답 코드가 동일하지 않으면 지정된 파일의 콘텐츠와 KEY_NAME을 다시 확인하고 TIME_UNTIL_EXPIRATION 값이 최소한 몇 초 이상으로 되어 있는지 확인해야 합니다.
--validate 플래그를 지정하지 않으면 다음이 확인되지 않습니다.
- 입력
- 생성된 URL
- 생성되고 서명된 URL
프로그래매틱 방식으로 서명된 URL 만들기
다음 코드 샘플은 서명된 URL을 프로그래매틱 방식으로 만드는 방법을 보여줍니다.