署名付きリクエストを使用する

署名付きリクエストを作成するには、保護するコンテンツと署名付き値の有効期限を表すパラメータを含む文字列を作成します。作成した文字列をリクエストに含めます。 Media CDN は、署名付きリクエストが有効であることを確認してから処理を行います。

署名付きリクエストの要件

署名付きリクエストは次の要件を満たしている必要があります。

  • GET、HEAD、OPTIONS の HTTP メソッドを使用する。他のメソッドはサポートされていません。

  • 有効期限が将来に設定されている。クロック同期の違いと、クライアント ネットワークの状態（切断や再試行など）があるため、タイムスタンプは今後 1 分以内か、動画ストリーム以上の長さのいずれか大きい方に設定することをおすすめします。

  • EdgeCacheKeyset の鍵またはシークレットで検証できる署名がある。

POST、PUT、DELETE リクエストなど、他の HTTP メソッドに署名することはできません。ユーザー向けのアップロードに署名付き URL を発行する必要がある場合は、 署名付き URL に関する Cloud Storage のドキュメントをご覧ください。

署名付きリクエストを構成する

以降のセクションでは、署名付きリクエストを構成、署名、検証する方法について説明します。

キーを生成

Media CDN がリクエストの署名に使用する鍵を作成します。

鍵セットを作成する

Media CDN が署名付きリクエストに使用する 鍵セットを作成します。

署名付きリクエストを必須にする

署名付きリクエストのみがリソースにアクセスできるようにするには、鍵のリストをルートにアタッチし、signedRequestMode を次のいずれかに設定します。

  • トークンを使用しない署名付きリクエストの場合は REQUIRE_SIGNATURES。

  • トークンを使用した署名付きリクエストの場合は　REQUIRE_TOKENS。

ルートで署名付きリクエストを有効にすると、すべてのリクエストが署名されるか、トークンが提示されます。有効な署名がないリクエスト（無効な鍵名、署名またはトークンの有効期限切れ、署名の不一致など）は失敗します。

EdgeCacheKeyset には、鍵のローテーションを可能にするために複数の鍵を含めることができます。リストされている鍵で署名された有効なリクエストは受け入れられ、鍵は順番に試行されます。鍵のローテーションの詳細については、シークレットのローテーション をご覧ください。

signedRequestMode が REQUIRE_SIGNATURES または REQUIRE_TOKENS に設定されている場合、Media CDN はキャッシュ ヒットとキャッシュミスを検証します。これには、送信元へのすべてのリクエストが含まれます。

以下に、特定の PathMatcher（ルート）で署名付きリクエストを強制する Media CDN 構成の例を示します。

gcloud edge-cache services describe prod-media-service
出力: 
...
  routeAction:
    cdnPolicy:
      cacheMode: CACHE_ALL_STATIC
      signedRequestMode: REQUIRE_SIGNATURES
      signedRequestKeyset: prod-vod-keyset

署名付きリクエストのトークンを作成する方法については、トークン を生成するをご覧ください。

リクエストの署名を無効にするには、signedRequestMode を DISABLED に設定し、signedRequestKeyset への参照を削除します。

送信元でリクエストを検証する

ルートが REQUIRE_SIGNATURES の署名モードで構成されている場合、Media CDN は、一致するすべてのリクエストに有効な署名があることを検証します。署名がない場合は、これらのルートに対して無効な署名として扱われます。

署名が誤って構成されている場合や、ユーザーが送信元に直接アクセスしようとする場合を防ぐため、送信元でもリクエストが署名されていることを検証することをおすすめします。コンテンツ保護に対する多層防御のアプローチは、ライセンス供与された有料コンテンツへの不正アクセスやダウンロードを防ぐのに役立ちます。

URL ベースの署名メソッドの場合、署名がクエリ パラメータの一部であるか、URL パス コンポーネントとして埋め込まれている場合、署名と関連パラメータは、リクエストが送信元に送信される前に URL から削除されます。これにより、送信元がリクエストを処理する際に、署名を原因とするルーティング問題の発生を防ぎます。これらのリクエストを検証するには、x-client-request-url リクエスト ヘッダーを調べます。このヘッダーには、署名付きコンポーネントが削除される前の元の（署名付き）クライアント リクエスト URL が含まれています。

送信元でリクエストを検証するには、リクエスト署名エンドポイントの一部として同じ検証コードを使用します。これにより、鍵の不一致や鍵のローテーションによる問題を軽減できます。

鍵のローテーション

Media CDN で使用されるシークレットは、定期的にローテーションまたは更新することをおすすめします。鍵は 30 ～ 60 日ごとにローテーションすることをおすすめしますが、必須ではありません。

次のステップ

  • ログのフィルタリングとクエリの方法など、Media CDN ログを有効にしてアクセスする方法については、 ロギングをご覧ください。

  • Media CDN と プライベート Cloud Storage バケットを構成するには、 送信元の接続とシールドをご覧ください。