V2 署名プロセス

重要: このページでは、V2 署名プロセスに関連する従来の資料について説明します。ただし、V4 署名プロセスを使用することをおすすめします。

このページでは、V2 署名プロセスを使用する際の署名付き URL の概要について説明します。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 Object のドキュメントを確認してください。
Content_MD5	rmYdCNHKFXam78uCt7xQLw==	（省略可）Base64 による MD5 ダイジェストの値。これを文字列中で指定する場合、クライアント（通常はブラウザ）は、そのリクエスト中で、この HTTP ヘッダーにこれと同じ値を指定する必要があります。
Content_Type	text/plain	必要に応じて指定。content-type を指定する場合、クライアント（ブラウザ）は、この HTTP ヘッダーを同じ値に設定する必要があります。
Expires	1388534400	必須。これは署名の有効期限が切れるタイムスタンプです（1970 年 1 月 1 日の 00:00:00 UTC の UNIX エポックからの時間を秒数で表します）。サーバーは、このタイムスタンプの後に受信したリクエストと、署名付き 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 App Identity サービスを使用した文字列の署名

プログラムを使用して署名付き URL を作成する場合、プログラムで文字列を署名するか、App Engine Identity サービスを使用して、App Engine アプリケーションで署名します。後者の場合、App Engine のサービス アカウントの認証情報を使用します。たとえば、Python App Identity API を使用して、次のことが可能です。

• google.appengine.api.app_identity.sign_blob() を使用して、作成した文字列のバイトに署名する。Signature は、署名付き URL を組み立てるときに必要になります。

• google.appengine.api.app_identity.get_service_account_name() を使用してサービス アカウント名を取得する。サービス アカウント名 GoogleAccessId は、署名付き URL を組み立てるときに必要になります。

他の言語でのサポートについては、App Identity API for Java の概要、App Identity API for PHP の概要、App Identity Go の関数をご覧ください。

App Identity サービスは、blob を署名するときに秘密鍵をローテーションします。App Identity サービスで生成された署名付き URL は、少なくとも 1 時間有効であり、リソースへの短時間のアクセスに最適です。

正規化された拡張ヘッダー

プログラムを使用して署名付き URL を作成する場合、メッセージの正規化された拡張ヘッダー部分を作成するには、x-goog- で始まるすべての拡張（カスタム）ヘッダーを結合します。ただし、単純に結合することはできません。ヘッダーを作成するときには、次のアルゴリズムにご注意ください。

1. カスタム ヘッダーの名前をすべて小文字にします。

2. すべてのカスタム ヘッダーを、コードポイント値による辞書的な並べ替えを使用して、ヘッダー名の順に並べ替えます。

3. x-goog-encryption-key と x-goog-encryption-key-sha256 ヘッダーがあれば削除します。これらのヘッダーには、署名対象文字列に含めてはならない機密情報が含まれています。ただし、これらのヘッダーは、生成された署名付き URL を使用するすべてのリクエストで引き続き使用する必要があります。

4. 重複したヘッダー名は、値をカンマで区切ってリストすることで 1 つのヘッダー名にします。値と値の間に空白文字がなく、カンマ区切りのリストの順番がリクエストに表示されるヘッダーの順番と同じであることを確認してください。詳細については、RFC 7230 のセクション 3.2 を参照してください。

5. 折りたたみ空白文字や改行（CRLF または LF）はすべて単一の空白文字に置き換えます。折りたたみ空白文字の詳細については、RFC 7230 のセクション 3.2.4 をご覧ください。

6. ヘッダー名の後のコロンの前後に空白文字があれば削除します。

7. 各カスタム ヘッダーに改行（U+000A）を追加します。

8. すべてのカスタム ヘッダーを結合します。

重要: クエリ文字列の正規化された拡張ヘッダー部分を作成する際には、ヘッダー名とヘッダー値の両方を使用する必要があります。ヘッダー名と値を区切るコロンの前後の空白文字は必ず削除してください。たとえば、コロンの後の空白文字を削除せずにカスタム ヘッダー x-goog-acl: private を使用すると、403 Forbidden エラーが返されます。これは、計算したリクエスト署名が、Cloud Storage によって計算される署名と一致しないためです。

正規化されたリソース

プログラムを使用して署名付き 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 などのクエリ文字列パラメータは含めないでください。