서명된 URL

이 페이지는 버킷과 객체에 대한 쿼리 문자열 인증 메커니즘인 서명된 URL을 간략히 설명합니다. 서명된 URL을 가진 사람은 누구나 Google 계정이 있는지 여부에 관계없이 제한된 시간 동안 읽기 또는 쓰기 권한을 부여 받습니다. 서명된 URL을 만드는 방법에 대해서는 gsutil을 사용하여 서명된 URL 만들기프로그램으로 서명된 URL 만들기를 참조하세요. 버킷과 객체에 대한 액세스를 제어하는 다른 방법에 대해서는 액세스제어 개요를 참조하세요.

서명된 URL을 사용해야 하는 경우

일부의 경우에는 사용자가 Google 계정이 없어도 Cloud Storage에 액세스할 수 있도록 허용하지만 애플리케이션 특정 로직을 사용하여 액세스를 제어하길 원할 수 있습니다. 이 사용 사례를 처리하는 일반적인 방법은 서명된 URL을 사용자에게 제공하여 제한된 시간 동안 해당 리소스에 대한 읽기, 쓰기, 삭제 액세스 권한을 부여하는 것입니다. URL을 아는 사람은 누구나 URL이 만료될 때까지 리소스에 액세스할 수 있습니다. 서명할 쿼리 문자열에서 만료 시간을 지정합니다.

재개 가능한 업로드로 서명된 URL 사용

사용자가 액세스가 제어된 버킷에만 리소스를 업로드하는(쓰는) 경우, Cloud Storage의 재개 가능한 업로드 기능을 사용하여 서명된 URL 하나만 요구할 수 있습니다. 이 서명된 URL은 실제로 데이터가 업로드되지 않는 초기 POST 요청에 포함됩니다. 세션 URI가 초기 POST 요청에서 반환되며, 후속 PUT 요청에서 이 URI를 사용하여 데이터를 업로드할 수 있습니다. 세션 URI는 사실상 인증 토큰이므로, PUT 요청에 서명할 필요가 없습니다. POST 요청은 서버에서 수행될 수 있으므로, 클라이언트가 서명 URL이나 Google 계정을 사용할 필요가 없습니다.

재개 가능한 업로드는 업로드가 시작되는 지역에 고정됩니다. 예를 들어, 미국에서 재개 가능한 업로드 URL을 만들어 아시아 지역의 고객에게 제공하는 경우 업로드는 여전히 미국을 통과합니다. 시작되지 않은 지역에서 재개 가능한 업로드를 수행하면 업로드 속도가 느려질 수 있습니다. 업로드가 클라이언트 소재 위치에서 시작되도록 서버에서 초기 POST 요청을 작성하고 서명한 후 서명된 URL을 클라이언트에 제공하여 이 문제를 방지할 수 있습니다. 시작되면 클라이언트는 정상적으로 결과 세션 URI를 사용하여 서명할 필요가 없는 PUT 요청을 만들 수 있습니다.

Compute Engine 인스턴스를 Cloud Storage에 POST하여 재개 가능한 업로드를 시작하는 프로세스와 함께 사용하는 경우에는 Compute Engine 인스턴스를 Cloud Storage 버킷과 동일한 위치에서 사용해야 합니다. 그런 다음에 지역 IP 서비스를 사용하여 고객 요청 경로를 지정하는 Compute Engine 지역을 선택할 수 있습니다. 이렇게 하면 트래픽을 지역에 맞게 현지화할 수 있습니다.

서명이 필요한 문자열 구성요소

프로그램을 사용하여 서명된 URL 생성 시 프로그램에서 서명될 문자열이 작성됩니다. 이 문자열은 프로그램에서 다음과 같이 정의되어야 합니다.

StringToSign = HTTP_Verb + "\n" +
               Content_MD5 + "\n" +
               Content_Type + "\n" +
               Expiration + "\n" +
               Canonicalized_Extension_Headers +
               Canonicalized_Resource

이 구조의 구성요소는 다음 표에 설명되어 있습니다.

문자열 구성요소 설명
HTTP_Verb GET 필수 항목입니다. 서명된 URL과 함께 사용할 HTTP 동사입니다.

참고: 위에서 언급한 경우를 제외하고 HTTP 동사 POST는 서명된 URL 문자열에서 지원되지 않습니다. POST를 사용하여 버킷에 업로드할 수 있는 객체 특성을 지정하는 서명된 정책 문서를 정의할 수 있습니다. POST 객체 문서에서 자세히 알아보세요.

Content_MD5 rmYdCNHKFXam78uCt7xQLw== 선택 항목입니다. Base64의 MD5 다이제스트 값입니다. 이 값을 문자열에 제공하는 경우, 클라이언트(일반적으로 브라우저)는 요청에 이와 동일한 값과 함께 이 HTTP 헤더를 제공해야 합니다.
Content_Type text/plain 필요에 따라 사용합니다. content-type을 제공하는 경우, 클라이언트(브라우저)는 이 HTTP 헤더를 동일한 값으로 설정하여 제공해야 합니다.
Expiration 1388534400 필수 항목입니다. 서명이 만료되는 시점의 타임스탬프(Unix 이폭 1970년 1월 1일 00:00:00 UTC 이후 시간을 초로 표시)입니다. 이 타임스탬프가 지나면 서버는 수신된 모든 요청을 거부합니다.
Canonicalized_Extension_Headers x-goog-acl:public-read\nx-goog-meta-foo:bar,baz\n 필요에 따라 사용합니다. 서버는 클라이언트가 서명된 URL을 사용하여 요청에 일치하는 값을 제공하는지 확인합니다. 서명용 정식 헤더를 만드는 방법에 대한 자세한 내용은 정식 확장 헤더를 참조하세요.
Canonicalized_Resource /bucket/objectname 필수 항목입니다. URL에서 주소를 지정하는 리소스입니다. 자세한 내용은 정식 리소스를 참조하세요.

App Engine 앱 ID 서비스로 문자열 서명

프로그램을 사용하여 서명된 URL 생성 시 프로그램 내에서 또는 App Engine의 서비스 계정 사용자 인증 정보를 사용하는 App Engine ID 서비스를 사용하여 Google App Engine 애플리케이션 내 다른 곳에서 문자열에 서명할 수 있습니다. 예를 들어 Python 앱 ID API를 사용하면 다음을 수행할 수 있습니다.

  • google.appengine.api.app_identity.sign_blob()를 사용하여 서명된 URL을 어셈블하는 경우 필요한 Signature를 제공하는 작성된 문자열의 바이트에 서명합니다.

  • google.appengine.api.app_identity.get_service_account_name()을 사용하여 서명된 URL을 어셈블하는 경우 필요한 GoogleAccessId의 서비스 계정 이름을 검색합니다.

다른 언어 지원에 대해서는 자바용 앱 ID API 개요, PHP용 앱 ID API 개요, 앱 ID Go 함수를 참조하세요.

blob에 서명 시 앱 ID 서비스는 개인 키를 순환시킵니다. 앱 ID 서비스에서 생성된 서명된 URL은 최소 1시간 동안 유효하며 리소스에 대한 단기간 액세스에 가장 적합합니다.

정식 확장 헤더

프로그램을 사용하여 서명된 URL 생성x-goog-로 시작되는 모든 확장(커스텀) 헤더를 연결하여 메시지의 정식 확장 헤더 부분을 작성합니다. 그러나 간단한 연결은 수행할 수 없습니다. 헤더 생성 시 다음 알고리즘에 유의하세요.

  1. 모든 커스텀 헤더 이름을 소문자로 만듭니다.

  2. 코드 포인트 값을 기준으로 한 사전식 정렬을 사용하여 헤더 이름별로 모든 커스텀 헤더를 정렬합니다.

  3. x-goog-encryption-key 헤더와 x-goog-encryption-key-sha256 헤더가 있으면 삭제합니다. 이들 헤더에는 string-to-sign에 포함되어서는 안 되는 민감한 정보가 있지만 생성된 서명된 URL을 사용하는 요청에는 이들 헤더를 계속 사용해야 합니다.

  4. 쉼표로 구분된 값 목록으로 하나의 헤더 이름을 만들어 중복된 헤더 이름을 제거합니다. 값 사이에 공백이 없고 쉼표로 구분된 목록의 순서가 요청에 헤더가 나타나는 순서와 일치하는지 확인합니다. 자세한 내용은 RFC 7230 섹션 3.2를 참조하세요.

  5. 접을 수 있는 공백이나 줄바꿈(CRLF 또는 LF)을 단일 공백으로 바꿉니다. 접을 수 있는 공백에 대한 자세한 내용은 RFC 7230, 섹션 3.2.4를 참조하세요.

  6. 헤더 이름 다음에 표시되는 콜론 주위의 공백을 삭제합니다.

  7. 각 커스텀 헤더에 줄바꿈 '\n'(U+000A)을 추가합니다.

  8. 모든 커스텀 헤더를 연결합니다.

정식 리소스

프로그램을 사용하여 서명된 URL 생성 시 요청이 작동하는 리소스 경로(버킷, 객체, 하위 리소스)를 연결하여 메시지의 정규화된 리소스 부분을 작성합니다. 리소스 생성 시 다음 사항을 유의하세요.

  • 정식 리소스는 호스트 이름 뒤에 오는 모든 항목입니다. 예를 들어, Cloud Storage URL이 https://storage.googleapis.com/example-bucket/cat-pics/tabby.jpeg인 경우 정식 리소스는 /example-bucket/cat-pics/tabby.jpeg입니다.

  • 요청의 범위가 ?cors와 같은 하위 리소스로 지정된 경우, 물음표를 포함하여 이 하위 리소스를 문자열 끝에 추가합니다.

  • 글자 그대로 HTTP 요청 경로를 복사해야 합니다. 즉, 생성하는 문자열에 모든 URL 인코딩(백분율 기호)을 포함해야 합니다. 또한 하위 리소스를 지정하는 쿼리 문자열 매개변수(예: cors)만 포함해야 합니다. ?prefix, ?max-keys, ?marker, ?delimiter와 같은 쿼리 문자열 매개변수를 포함하면 안 됩니다.

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

도움이 필요하시나요? 지원 페이지를 방문하세요.