V2 서명 프로세스

중요: 이 페이지에서는 V2 서명 프로세스와 관련된 기존 자료를 다룹니다. 사용자는 V4 서명 프로세스를 대신 사용하는 것이 좋습니다.

이 페이지에서는 버킷 및 객체의 쿼리 문자열 인증용 메커니즘인 V2 서명 프로세스로 작업할 때 서명된 URL을 간략하게 설명합니다. 서명된 URL을 가진 사람은 누구나 사용자 계정 유무에 관계없이 제한된 시간 동안 읽기 또는 쓰기 액세스 권한을 부여받습니다.

중요: 서명된 URL은 XML API 엔드포인트를 통해 Cloud Storage의 리소스에 액세스하는 데만 사용할 수 있습니다.

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

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

StringToSign = HTTP_Verb + "\n" +
               Content_MD5 + "\n" +
               Content_Type + "\n" +
               Expires + "\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 헤더를 동일한 값으로 설정하여 제공해야 합니다.
Expires	1388534400	필수 항목입니다. 서명이 만료되는 시점의 타임스탬프(Unix epoch 1970년 1월 1일 00:00:00 UTC 이후 시간을 초로 표시)입니다. 서버는 이 타임스탬프가 경과한 후 수신된 모든 요청과 서명된 URL 생성에 사용된 키가 순환된 후 수신된 모든 요청을 거부합니다. 보안 및 V4 서명 프로세스와의 호환성을 위해 Expires를 미래의 최대 1주일(604,800초)로 설정해야 합니다.
Canonicalized_Extension_Headers	x-goog-acl:public-read\nx-goog-meta-foo:bar,baz\n	필요에 따라 사용합니다. 서버는 클라이언트가 서명된 URL을 사용하여 요청에 일치하는 값을 제공하는지 확인합니다. 서명용 정규 헤더를 만드는 방법에 대한 자세한 내용은 정규 확장 헤더를 참조하세요.
Canonicalized_Resource	/bucket/objectname	필수 항목입니다. URL에서 주소를 지정하는 리소스입니다. 자세한 내용은 정규 리소스를 참조하세요.

참고: response-content-disposition 및 response-content-type과 같은 쿼리 문자열 매개변수는 서명을 통해 확인되지 않습니다. 응답에서 Content-Disposition 또는 Content-Type을 강제 적용하려면 객체 메타데이터에서 이러한 매개변수를 설정합니다.

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

프로그램을 사용하여 서명된 URL을 만들 때 프로그램 내에서 또는 App Engine의 서비스 계정 사용자 인증 정보를 사용하는 App Engine ID 서비스를 사용하여 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. 모든 커스텀 헤더를 연결합니다.

중요: 쿼리 문자열의 정규 확장 헤더 부분을 작성할 때 헤더 이름과 헤더 값을 모두 사용해야 합니다. 헤더 이름과 값을 구분하는 콜론 주위의 공백을 삭제해야 합니다. 예를 들어 콜론 다음에 있는 공백을 삭제하지 않고 커스텀 헤더 x-goog-acl: private을 사용하면 사용자가 계산한 요청 서명이 Cloud Storage에서 계산한 서명과 일치하지 않으므로 403 Forbidden 오류가 반환됩니다.

정규 리소스

프로그램을 사용하여 서명된 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와 같은 쿼리 문자열 매개변수를 포함해서는 안 됩니다.