署名付き URL と署名付き Cookie の概要

Cloud CDN の署名付き URL と署名付き Cookie を使用すると、リクエストを承認する必要がある場合でも、Google Cloud のグローバルに分散されたキャッシュからレスポンスを提供できます。

Cloud CDN の署名付き URL と署名付き Cookie の目的は似ています。どちらも、キャッシュに保存されているコンテンツへのアクセスを制御します。Google Cloud のグローバルに分散されたキャッシュからコンテンツを配信する場合、署名付き URL と署名付き Cookie のどちらを使用するかを決定するには、次のユースケースを比較検討してください。

署名付き URL

署名付き URL は、リクエスト時における制限付きの権限と有効期限が設定された URL です。

ユースケース

シナリオ: Google アカウントがなくてもユーザーに Cloud CDN コンテンツへのアクセスを許可すると同時に、アプリケーション固有のロジックを使ってアクセスを制御したい場合があります。

このような場合の標準的な対処法は、ユーザーに署名付き URL を提供することです。署名付き URL によって、該当するリソースに対する期間限定の読み取りアクセス権がユーザーに付与されます。署名付き URL を作成するときに、有効期限を指定します。URL が期限切れになるまで、または URL の署名に使われた鍵がローテーションされるまで、その URL を知っていれば誰でもそのリソースにアクセスできます。

署名付き URL は、次の場合に使用します。

  • インストール用のダウンロード ファイルなど、個々のファイルへのアクセスを制限する必要がある。

  • ユーザーが、Cookie をサポートしていないクライアント アプリケーションを使用している。

署名付き URL の仕組み

署名付き URL を使用すると、限定公開リソースへの一時的なアクセス権を、追加の承認なしでクライアントに付与できます。そのためには、強いランダム性を持つ鍵を生成し、その鍵でリクエストの特定の要素をハッシュして暗号署名を付加します。

提供した署名付き URL がリクエストで使用されると、そのリクエストは、要求対象のコンテンツを取得することが承認されていると見なされます。有効なサービス向けの不適切な署名を持つリクエストが Cloud CDN で受信されると、そのリクエストは拒否され、それがバックエンドに渡されて処理されることはありません。

一般的に、署名付き URL は入手した人が誰でも使用できます。ただし通常は、署名付き URL はそれを渡されたクライアントのみが使用するように意図されています。その URL が別のクライアントで使われるというリスクを軽減する目的で、署名付き URL は指定の時間が経過すると無効になります。署名付き URL が共有されるリスクを最小限に抑えるには、URL がすぐに無効になるように有効期限を設定します。

URL に署名を付加する方法

URL に署名を付加できるようにするには、暗号鍵をバックエンド サービスやバックエンド バケットに対して作成します。次に、Google Cloud CLI または独自のコードを使用して URL に署名を付加し、暗号的にハッシュします。

署名付き URL の処理

バックエンドで署名付き URL を処理できる場合、署名付き URL を含むリクエストに対し、Cloud CDN は特別な処理を行います。具体的には、Signature クエリ パラメータを含むリクエストは署名付きと見なされます。このようなリクエストを受信すると、Cloud CDN は次のことを検証します。

  1. HTTP メソッドが GET、HEAD、OPTIONS、または TRACE であること。
  2. Expires パラメータが将来の時刻に設定されていること。
  3. リクエストの署名が、指定された鍵を使って計算された署名と一致すること。

これらの検査のいずれかが失敗すると、403 Forbidden レスポンスが返されます。それ以外の場合は、リクエストがバックエンドに転送されるか、キャッシュからコンテンツが返されます。（OPTIONS リクエストと TRACE リクエストは常にバックエンドに直接プロキシされ、キャッシュからは配信されません。）同じベース URL（Expires パラメータの前の部分）に関するすべての有効な署名付きリクエストに、同じキャッシュ エントリが使用されます。署名付きリクエストと署名なしのリクエストの両方のレスポンスに同じキャッシュ エントリが使用されることはありません。キャッシュに保存されたレスポンスは、ユーザーが設定した有効期限を経過するまでキャッシュから提供されます。

署名付きリクエストを必要とするコンテンツが、Cache-Control ヘッダーでキャッシュ不可と指定される場合がよくあります。このようなオブジェクトを、バックエンドを変更せずに Cloud CDN で処理できるようにする目的で、Cloud CDN は有効な署名付き URL を含むリクエストに対するレスポンスで、Cache-Control ヘッダーを無視します。そのコンテンツはキャッシュ可能として扱われ、Cloud CDN 設定で指定された max-age パラメータが使われます。返されるレスポンスでは、バックエンドで生成された Cache-Control ヘッダーが維持されます。

必要に応じて、Google Cloud CLI から返された URL、またはカスタムコードによって生成された URL を配布できます。HTTPS URL だけに署名することをおすすめします。HTTPS は、セキュリティに優れたトランスポート手段であり、署名付き URL の署名部分が傍受されるのを防止できるからです。同様に、署名付き URL を配布するときは、TLS / HTTPS などのセキュアなトランスポート プロトコルを使用してください。

署名済み Cookie

署名付き Cookie とは、制限付きの権限と期間で一連のファイルをリクエストできるようにするための Cookie です。

ユースケース

署名付き Cookie は、次の場合に使用します。

  • 複数の制限されたファイルへのアクセスを許可する必要がある。

  • 現在の URL の変更を避ける必要がある。

  • コンテンツへのアクセス承認を更新するたびに URL を更新しなくても済むようにする必要がある。

HLS と DASH を使用したメディア ストリーミング

HTTP Live Streaming（HLS）プロトコルまたは Dynamic Adaptive Streaming over HTTP（DASH）プロトコルを使用して動画と音声のコンテンツを配信する場合、通常は、動画セグメントへの URL と音声セグメントへの URL が一覧表示されたマニフェストを生成します。クライアントに複数の異なるエンコード（コーデック、ビットレート、解像度）を提供する目的で、各セグメントの複数のインスタンスを用意することがあります。

Cloud CDN の署名付き URL を使用して、それぞれの URL に署名を付加し、アクセスを承認することもできますが、ユーザーごとに考えられるすべての組み合わせを動的に生成するのはかなりの負担です。また、送信元への負荷を増し、アプリケーションを複雑化させることにもなります。

署名付き Cookie は、この問題に対処するように意図されています。ポリシー（URL 接頭辞と有効期限日）に一致するあらゆるコンテンツへのアクセスを許可する署名付き Cookie をユーザーに提供すれば、メディア マニフェストを個別に生成または署名付けする必要がなくなります。また、ネイティブ アプリケーションのページ ナビゲーションに対する JavaScript fetch() API や他のバックグラウンド メカニズムによって、ユーザー アクセスを定期的に更新できます。ユーザー アクセスを更新できるので、有効期間を短くして、保護されたコンテンツを複数ユーザー間で共有しにくくすることもできます。

さまざまなブラウザ クライアントや他の HTTP 対応クライアント（Google の ExoPlayer や iOS の AVPlayer など）で、ユーザーにこれらの Cookie を発行できます。

バイナリ ダウンロード（ゲーム）

メディア ストリーミングと同じように、ゲーム クライアントにダウンロードを提供する場合は、ギガバイト規模のパッチやゲームデータを小さなチャンクに分割して、きめ細かいキャッシュ、無効化、同時実行をサポートできます。

これらのチャンクは通常、マニフェストに一覧表示されます。署名付き Cookie を使用すると、マニフェストに変更を加えることなく、こうしたダウンロードへのアクセスを認証済みユーザーに許可できます。さらに、（署名付き URL の場合と同じく）Cloud CDN のキャッシュの利点を活用できます。

署名付き Cookie の仕組み

署名付き Cookie を構成して発行するには、3 つの手順が必要です。

  • 所定のバックエンド サービスの署名鍵を作成します。
  • 許可対象の URL 接頭辞、有効期限、鍵名、暗号署名からなる Cookie 値を作成します。
  • その Cookie をアプリケーション コード内で発行します。

リクエストに署名付き Cookie が含まれている場合、Cloud CDN はその Cookie を検証します。

Cloud Storage バケットを使用する場合、署名付き Cookie 制御をユーザーが回避することを防止できます。それには、allUsers ロールを削除し、バケットに対する読み取りアクセス権を Cloud CDN サービス アカウントに付与して、基礎となるバケットへのアクセスを制約します。

同様に、仮想マシン（VM）インスタンスでも、処理する署名付きリクエストごとに署名を検証する必要があります。

注意点と制限事項

  • 署名付き Cookie に必要な同意とプライバシーのコンプライアンスについては、お客様が単独で責任を負うものとします。署名付き Cookie は、Google ではなくお客様が発行して管理します。

  • 署名付き URL と署名付き Cookie の両方を使って同じ一連のファイルへのアクセスを制御する場合、閲覧者が署名付き URL を使用してファイルをリクエストすると、Cloud CDN は署名付き URL だけに基づいて、閲覧者にファイルを返すかどうかを判断します。URL に署名が付いてない場合にのみ、Cloud CDN は署名付き Cookie を考慮します。

  • 署名付きリクエストに対応するようサービスを構成した場合、URL にクエリ パラメータとして Signature が含まれていると、Cloud CDN はその URL を署名付き URL として解釈しようとします。署名付き URL として意図されていない URL を Cloud CDN が署名付き URL として扱おうとすると、おそらくその URL は有効な署名付き URL ではなく、Cloud CDN に拒否されます。

  • ブラウザやその他のクライアントは通常、RFC 6265 に従って、Cookie にサイズ（Cookie あたり 4 KB）と合計数（ドメインあたり 50）の上限を適用します。それぞれのドメインから送信される Cookie の合計ペイロードを考慮してください。

  • Cloud CDN の上限と制約事項（たとえばバックエンドごとに最大 3 つの署名付きリクエスト鍵の上限）が適用されます。

  • 署名付きリクエストには、既存の Cloud CDN リクエストとは別途料金が発生することはありません。ただし、有効期限切れや無効な署名が原因で失敗した（拒否された）リクエストにも、キャッシュの検索料金が請求されます。

次のステップ