이 페이지에서는 서명된 쿠키의 개요와 Cloud CDN에서 서명된 쿠키를 사용하는 방법을 설명합니다. 서명된 쿠키는 사용자에게 Google 계정이 있는지 여부와 관계없이 파일 집합에 대한 시간이 제한된 리소스 액세스 권한을 제공합니다.
서명된 쿠키는 서명된 URL의 대안입니다. 서명된 쿠키는 애플리케이션에서 각 사용자당 수십 또는 수백 개의 URL을 개별적으로 서명하기가 현실적으로 어려운 경우 액세스를 보호합니다.
서명된 쿠키를 사용하여 다음을 수행할 수 있습니다.
- 각 URL에 서명하는 대신 사용자를 승인하고 보호된 콘텐츠에 액세스하기 위한 시간이 제한된 토큰을 제공합니다.
- 사용자의 액세스 범위를 특정 URL 프리픽스(예:
https://media.example.com/videos/
)로 지정하고 승인된 사용자에게 해당 URL 프리픽스 내의 보호된 콘텐츠에 한해 액세스 권한을 부여합니다. - URL 및 미디어 매니페스트를 변경하지 않고 패키징 파이프라인을 간소화하고 캐시 저장 가능성을 개선합니다.
대신 특정 URL에 대한 액세스 범위를 지정하려면 서명된 URL을 사용하는 것이 좋습니다.
시작하기 전에
서명된 쿠키를 사용하기 전에 다음을 수행합니다.
Cloud CDN이 사용 설정되어 있는지 확인합니다. 자세한 내용은 Cloud CDN 사용을 참조하세요. Cloud CDN을 사용 설정하기 전에 백엔드에서 서명된 쿠키를 구성할 수 있습니다. 하지만 Cloud CDN을 사용 설정할 때까지 효과는 없습니다.
필요한 경우 Google Cloud CLI를 최신 버전으로 업데이트합니다.
gcloud components update
개요는 서명된 URL 및 서명된 쿠키 개요를 참조하세요.
서명된 요청 키 구성
서명된 URL 또는 서명된 쿠키의 키를 만들려면 다음 섹션에 설명된 여러 단계가 필요합니다.
보안 고려사항
Cloud CDN은 다음 상황에서 요청 유효성을 검사하지 않습니다.
- 요청이 서명되지 않았습니다.
- 요청의 백엔드 서비스나 백엔드 버킷에 Cloud CDN이 사용 설정되어 있지 않습니다.
서명된 요청은 응답을 제공하기 전에 항상 원본에서 검증되어야 합니다. 원본은 서명된 콘텐츠와 서명되지 않은 콘텐츠의 혼합을 제공하는 데 사용될 수 있고 클라이언트가 원본에 직접 액세스할 수도 있기 때문입니다.
- Cloud CDN은
Signature
쿼리 매개변수 또는Cloud-CDN-Cookie
HTTP 쿠키가 없는 요청을 차단하지 않습니다. 유효하지 않거나 잘못된 형식의 요청 매개변수가 있는 요청을 거부합니다. - 애플리케이션이 잘못된 서명을 감지하면
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 캐시 채우기 서비스 계정이 생성되지 않으므로 오류가 발생하고 명령어는 실패합니다. PROJECT_NUM
을 프로젝트 번호로, BUCKET
을 스토리지 버킷으로 바꿉니다.
gsutil iam ch \ serviceAccount:service-PROJECT_NUM@cloud-cdn-fill.iam.gserviceaccount.com:objectViewer \ gs://BUCKET
Cloud CDN 서비스 계정 service-PROJECT_NUM@cloud-cdn-fill.iam.gserviceaccount.com
은 프로젝트의 서비스 계정 목록에 표시되지 않습니다. 이는 프로젝트가 아닌 Cloud CDN이 Cloud CDN 서비스 계정을 소유하기 때문입니다.
프로젝트 번호에 대한 자세한 내용은 Google Cloud Console 도움말 문서의 프로젝트 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에 사용되는 쿼리 매개변수와 유사한 일련의 key-value
쌍(:
문자로 구분됨)입니다.
예시는 사용자에게 쿠키 발급을 참조하세요.
정책은 요청이 유효한 매개변수를 나타냅니다. 정책은 Cloud CDN이 각 요청에서 유효성을 검사하는 해시 기반 메시지 인증 코드(HMAC)를 통해 서명됩니다.
정책 형식 및 필드 정의
다음 순서로 네 가지 필수 필드를 정의해야 합니다.
URLPrefix
Expires
KeyName
Signature
서명된 쿠키 정책의 key-value
쌍은 대소문자를 구분합니다.
URLPrefix
URLPrefix
는 서명이 유효해야 하는 모든 경로를 포함하는 URL 보안 base64 인코딩 URL 프리픽스를 나타냅니다.
URLPrefix
는 스킴(http://
또는 https://
), FQDN, 선택적 경로를 인코딩합니다. /
로 경로를 종료하는 것은 선택사항이지만 권장됩니다. 프리픽스는 ?
또는 #
과 같은 쿼리 매개변수 또는 프래그먼트를 포함해서는 안 됩니다.
예를 들어 https://media.example.com/videos
는 요청을 다음 두 가지 모두와 일치시킵니다.
https://media.example.com/videos?video_id=138183&user_id=138138
https://media.example.com/videos/137138595?quality=low
프리픽스의 경로는 엄격히 디렉터리 경로로 사용되지 않고 텍스트 하위 문자열로 사용됩니다.
예를 들어 https://example.com/data
프리픽스는 다음 두 가지 모두에 대한 액세스 권한을 부여합니다.
/data/file1
/database
이러한 실수를 방지하려면 다음에 액세스 권한을 부여하기 위해 https://media.example.com/videos/123
와 같은 부분 파일 이름으로 프리픽스를 의도적으로 종료하지 않는 한 /
로 모든 프리픽스를 종료하는 것이 좋습니다.
/videos/123_chunk1
/videos/123_chunk2
/videos/123_chunkN
요청된 URL이 URLPrefix
와 일치하지 않으면 Cloud CDN이 요청을 거부하고 클라이언트에 HTTP 403
오류를 반환합니다.
만료
Expires
는 Unix 타임스탬프(1970년 1월 1일 이후의 초 수)여야 합니다.
KeyName
KeyName
은 백엔드 버킷 또는 백엔드 서비스에 대해 생성 된 키의 키 이름입니다. 키 이름은 대소문자를 구분합니다.
서명
Signature
는 쿠키 정책을 구성하는 필드의 URL 보안 base64 인코딩 HMAC-SHA-1 서명입니다. 이는 각 요청에서 검증됩니다. 서명이 잘못된 요청은 HTTP 403
오류와 함께 거부됩니다.
프로그래매틱 방식으로 서명된 쿠키 만들기
다음 코드 샘플은 서명된 쿠키를 프로그래매틱 방식으로 만드는 방법을 보여줍니다.
Go
자바
Python
서명된 쿠키 검증
서명된 쿠키의 유효성을 검사하는 프로세스는 기본적으로 서명된 쿠키를 생성하는 프로세스와 동일합니다. 예를 들어 다음과 같은 서명된 쿠키 헤더의 유효성을 검사한다고 가정해 보겠습니다.
Cookie: Cloud-CDN-Cookie=URLPrefix=URL_PREFIX:Expires=EXPIRATION:KeyName=KEY_NAME:Signature=SIGNATURE; Domain=media.example.com; Path=/; Expires=Tue, 20 Aug 2019 02:26:49 GMT; HttpOnly
KEY_NAME
이라는 보안 비밀 키를 사용하여 독립적으로 서명을 생성하고 SIGNATURE
와 일치하는지 검증할 수 있습니다.
사용자에게 쿠키 발급
애플리케이션은 올바르게 서명된 정책이 포함된 단일 HTTP 쿠키를 생성하고 각 사용자(클라이언트)에게 발급해야 합니다.
애플리케이션 코드에 HMAC-SHA-1 서명자를 만듭니다.
선택한 키를 사용하여 정책에 서명하고
mySigningKey
와 같이 백엔드에 추가한 키 이름을 기록합니다.다음 형식으로 쿠키 정책을 만듭니다. 이때 이름과 값은 모두 대소문자를 구분합니다.
Name: Cloud-CDN-Cookie Value: URLPrefix=$BASE64URLECNODEDURLORPREFIX:Expires=$TIMESTAMP:KeyName=$KEYNAME:Signature=$BASE64URLENCODEDHMAC
예시
Set-Cookie
헤더:Set-Cookie: Cloud-CDN-Cookie=URLPrefix=aHR0cHM6Ly9tZWRpYS5leGFtcGxlLmNvbS92aWRlb3Mv:Expires=1566268009:KeyName=mySigningKey:Signature=0W2xlMlQykL2TG59UZnnHzkxoaw=; Domain=media.example.com; Path=/; Expires=Tue, 20 Aug 2019 02:26:49 GMT; HttpOnly
쿠키의
Domain
및Path
속성은 클라이언트가 Cloud CDN에 쿠키를 보낼지 여부를 결정합니다.
권장사항 및 요구사항
보호된 콘텐츠를 제공하려는 도메인 및 경로 프리픽스와 일치하는
Domain
및Path
속성을 명시적으로 설정합니다. 이는 쿠키가 발급된 도메인 및 경로와 다를 수 있습니다(example.com
과media.example.com
또는/browse
와/videos
).동일한
Domain
및Path
에 대해 지정된 이름의 쿠키가 하나만 있어야 합니다.충돌하는 쿠키를 발급하지 마세요. 충돌하는 쿠키가 발급되면 다른 브라우저 세션(창 또는 탭)의 콘텐츠 액세스가 차단될 수 있습니다.
해당하는 경우
Secure
및HttpOnly
플래그를 설정합니다.Secure
는 쿠키가 HTTPS 연결을 통해서만 전송되도록 합니다.HttpOnly
는 자바스크립트에서 쿠키를 사용할 수 없도록 합니다.Expires
및Max-Age
쿠키 속성은 선택사항입니다. 이를 생략하면 브라우저 세션(탭, 창)이 있는 동안 쿠키가 존재합니다.캐시 채우기 또는 캐시 부적중의 경우 서명된 쿠키가 백엔드 서비스에 정의된 원본으로 전달됩니다. 콘텐츠를 제공하기 전에 각 요청에서 서명된 쿠키 값을 검증해야 합니다.