このページは Cloud Translation API によって翻訳されました。

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

署名付きリクエストを作成するには、保護するコンテンツと署名付き値の有効期限を記述するパラメータを含む文字列を作成します。作成した文字列をリクエストに含めます。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 バケットを構成するには、送信元の接続とシールドをご覧ください。