V2 署名プロセス

このページでは、V2 署名プロセスを使用する際の署名付き URL の概要について説明します。V2 署名プロセスは、バケットとオブジェクトに対するクエリ文字列認証のメカニズムです。署名付き URL は、時間制限のある読み取りや書き込みのアクセス権を、Google アカウントを持っているかどうかにかかわらず、URL を知っている全員に許可するための手段です。

署名が必要な文字列のコンポーネント

プログラムを使用して署名付き 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 に指定されるリソースです。詳細は、正規化されたリソースをご覧ください。

App Engine App Identity サービスを使用した文字列の署名

プログラムを使用して署名付き URL を作成する場合、プログラムで文字列を署名するか、App Engine Identity サービスを使用して、Google 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-keyx-goog-encryption-key-sha256 ヘッダーがあれば削除します。これらのヘッダーには、署名対象文字列に含めてはならない機密情報が含まれています。ただし、これらのヘッダーは、生成された署名付き URL を使用するすべてのリクエストで引き続き使用する必要があります。

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

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

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

  7. 各カスタム ヘッダーに改行(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 などのクエリ文字列パラメータは含めないでください。