署名付き URL

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

署名付き URL を使用すべき場合

シナリオによっては、ユーザーの Google アカウントによって Cloud Storage へのアクセスを制御することが望ましくなく、むしろアプリケーション固有のロジックを使ってアクセスを制御したい場合があります。このような場合には、一般にユーザーに署名付き URL を提供し、ユーザーにそのリソースについて期間限定で読み取り、書き込み、削除のアクセス権を与えることで対処します。URL が期限切れになるまで、URL を知っている人であれば誰でもそのリソースにアクセスできます。有効期限は、署名するクエリ文字列中で指定します。

再開可能なアップロードでの署名付き URL の使用

ユーザーが、アクセス制御されたバケットにリソースをアップロード(書き込み)するだけの場合は、Cloud Storage の再開可能なアップロード機能を使って、1 つの署名付き URL のみを要求するようにできます。この署名付き URL は、最初の POST リクエストに含まれ、その間データは実際にはアップロードされません。セッション URI が最初の POST リクエストから返され、以降の PUT リクエストで使用してデータをアップロードできます。セッション URI は事実上の認証トークンであるため、PUT リクエストを署名する必要はありません。POST リクエストは、サーバーから実行でき、クライアントが署名付き URL や Google アカウントを使用する必要はありません。

再開可能なアップロードは、それが開始されるリージョンに固定されます。たとえば、再開可能なアップロード URL を米国で作成し、アジアにあるクライアントに渡した場合でも、アップロードは米国を介して実行されます。再開可能なアップロードを、それが開始されたのとは違うリージョンで実行すると、アップロードに時間がかかる場合があります。これを避けるには、最初の POST リクエストをサーバーで作成して署名し、署名付き URL をクライアントに渡して、アップロードがクライアントのロケーションから開始されるようにします。アップロードが開始されたら、クライアントは得られたセッション URI を通常通り使用して、署名が不要な PUT リクエストを発行できます。

Compute Engine インスタンスを、再開可能なアップロードを開始するために Cloud Storage への POST を行うプロセスとともに使用する場合は、Compute Engine インスタンスを Cloud Storage バケットと同じロケーションで使用する必要があります。次に geo 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 Object のドキュメントを確認してください。

Content_MD5 rmYdCNHKFXam78uCt7xQLw== (省略可)Base64 による MD5 ダイジェストの値。これを文字列中で指定する場合、クライアント(通常はブラウザ)は、そのリクエスト中で、この HTTP ヘッダーにこれと同じ値を指定する必要があります。
Content_Type text/plain 必要に応じて指定content-type を指定する場合、クライアント(ブラウザ)は、この HTTP ヘッダーを同じ値に設定する必要があります。
Expiration 1388534400 必須。これは署名の有効期限が切れるタイムスタンプです(1970 年 1 月 1 日の 00:00:00 UTC の UNIX エポックからの時間を秒数で表します)。サーバーはこのタイムスタンプ後に受信したリクエストを拒否します。
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() を使用して、作成した文字列のバイトを署名し、署名付き URL を組み立てるときに必要な Signature を指定します。

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

他の言語でのサポートについては、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 などのクエリ文字列パラメータは含めないでください。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

ご不明な点がありましたら、Google のサポートページをご覧ください。