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

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

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

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

GET、HEAD、または OPTIONS HTTP メソッドがある。他のメソッドはサポートされていません。
有効期限を将来の日付に設定する。クロック同期の違いと、クライアントネットワークの状態（切断や再試行など）があるため、タイムスタンプは今後 1 分以内か、動画ストリーム以上の長さのいずれか大きい方に設定することをおすすめします。
EdgeCacheKeyset 内の鍵またはシークレットによって検証できる署名を含める。

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

セキュリティ上の考慮事項

Media CDN は、REQUIRE_SIGNATURES または REQUIRE_TOKENS の cdnPolicy.signedRequestMode で構成されたルートと一致するすべてのリクエストを検証します。

次の表に、Media CDN がリクエストを検証するシナリオを示します。

リクエストに署名があるか	署名は有効か	signedRequestMode	動作	レスポンスコード
×	なし	`REQUIRE_SIGNATURES` または `REQUIRE_TOKENS`	署名またはトークンのないリクエストは、署名が無効として扱われます。	`HTTP 403`
はい	×	`REQUIRE_SIGNATURES` または `REQUIRE_TOKENS`	署名またはトークンは、有効期限が切れているか、URL が一致しない、または鍵が正しくない場合、無効と見なされます。無効な署名やトークンは CDN エッジで拒否されます。	`HTTP 403`
はい	はい	`REQUIRE_SIGNATURES` または `REQUIRE_TOKENS`	署名またはトークンと、キャッシュからのコンテンツまたは送信元からの取得を含むレスポンスを検証します。	`HTTP 200`
はい	はい	なし、または `DISABLED`	検証は実行されず、レスポンスがユーザーに直接返されます。	`HTTP 200`
はい	×	なし、または `DISABLED`	検証は実行されず、レスポンスがユーザーに直接返されます。	`HTTP 200`

アプリケーションが無効な署名を検出した場合は、必ずアプリケーションが HTTP 403 (Forbidden) レスポンスコードを使って応答するようにしてください。HTTP 403 レスポンスコードはキャッシュに保存できません。

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

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

キーを生成

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 から削除されます。これにより、送信元がリクエストを処理するときに、署名によってルーティングの問題が起こるのを防ぐことができます。これらのリクエストを検証するには、署名付きコンポーネントを削除する前に、元の（署名付き）クライアントリクエスト URL を含む x-client-request-url リクエストヘッダーを調べます。

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

鍵のローテーション

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

次のステップ

ログ全体のフィルタやクエリを行う方法など、Media CDN ログを有効にしてアクセスする方法については、ロギングをご覧ください。
Media CDN とプライベート Cloud Storage バケットを構成するには、Origin の接続とシールドをご覧ください。