不正配信の防止

このページでは、Media CDN がコンテンツの不正配信の防止に役立つように用意するオプションについて簡単に説明します。

Media CDN には、コンテンツの不正配信を防ぐための次のオプションがあります。

• トークン（推奨アプローチ）: Media CDN はトークンを使用してコンテンツの保護に役立てます。

  トークンは、署名付き Cookie、クエリ パラメータを含む URI、パス コンポーネントなどの署名付きリクエストの交換媒体です。視聴者から提示された有効なトークンは、コンテンツへのアクセスの認証に使用されます。トークンが無効またはトークンがない閲覧者は、コンテンツにアクセスできません。

  シングル トークン認証またはデュアル トークン認証の使用を選択できます。デュアル トークン認証にはトークンが必要です。

  デュアル トークン認証を使用する場合、Media CDN は短期トークンと長期トークンの 2 つのトークンを使用します。

  トークンには次のような利点があるため、新しい統合にはトークンを使用することをおすすめします。

  • Google 以外のコンテンツ配信ネットワーク（CDN）との互換性を確保する。
  • パスのみの署名をサポート。
  • 複数のヘッダーの署名を有効にします。
  • きめ細かいアクセス制御と取り消しを提供します。
  • 不正使用されたトークンの影響が最小限に抑えられる。
  • 任意のデータとセッション ID を埋め込むことができます。

• 署名: Media CDN は、コンテンツを保護するために単一の署名を使用します。署名によって、ホストとプロトコルを含む完全な URL 署名を実行できます。

両方のオプションを併用すると、コンテンツを保護できます。

デュアル トークン認証の仕組み

デュアルトークン認証では、2 つのトークンを使用してコンテンツに対するリクエストを認証します。1 つは再生開始用の短期トークン、もう 1 つは再生セッションの残り用の長期トークンです。

デュアル トークン認証を使用するには、ユーザー エージェントに短期トークンを発行するようにアプリケーション サーバーを構成します。次に、短期トークンに応答するように Media CDN を構成します。選択したクエリ パラメータにトークンを配置することも、Cookie にトークンを配置することもできます。詳細については、デュアル トークン認証を使用するをご覧ください。

アプリケーション サーバーによって生成される短期トークンは、プライマリ マニフェスト（ミューバリアント プレイリストと呼ばれることもあります）の保護に役立ちます。署名付きリクエストの有効期限は、プライマリ マニフェストをリクエストするのに十分な長さですが、マニフェストに含まれているすべてのコンテンツを見るには不十分です。

Media CDN が認証済みの短期トークンのリクエストを受信すると、署名付きの長期トークンを生成します。トークンは、単一名のクエリ パラメータまたは Cookie で使用できます。長期トークンは省略なしのプログラムの表示をサポートします。Media CDN によって生成された署名付き長期トークンは、EdgeCacheKeyset リソースに関連付けられた Google が管理する鍵で署名された Ed25519 署名を使用します。

短期と長期のトークンの有効期限をカスタマイズできます。ベスト プラクティスとして、アプリケーション サーバーで生成される短期トークンの有効期限を 1 分に構成することをおすすめします。Media CDN が生成する長期トークンの有効期限は、コンテンツの長さより長い期間（最大 1 日）に設定する必要があります。

デュアル トークン認証のリクエスト フロー

リクエスト フローは次のとおりです。

1. 閲覧者は、表示する媒体のメタデータをアプリケーション サーバーにリクエストします。アプリケーション サーバーは、短期トークンで署名されたプライマリ マニフェストの URI を返します。

2. プレーヤー アプリケーションが、Media CDN にプライマリ マニフェストをリクエストします。リクエストには、単一名のクエリ パラメータ形式の URI クエリ パラメータの値として、短期トークンが含まれています。

3. Media CDN は、短期トークンとトークンの署名パラメータを検証します。

   1. トークンが有効な場合、Media CDN は長期署名トークンを生成します。Media CDN がトークンを返すには、Set-Cookie ヘッダー内か、トークンを含むようにプライマリ マニフェストのマニフェストとセグメントの URI を変更します。
   2. トークンが有効でない場合、Media CDN は HTTP 403 Forbidden レスポンスを返します。

4. プレーヤー アプリケーションは、Media CDN からプライマリ マニフェストを受け取ってから、プライマリ マニフェストで参照されているメディア プレイリストまたはメディア セグメントをリクエストします。リクエストには、署名付き Cookie または URI パラメータとして長期トークンを含める必要があります。

5. Media CDN が長期署名トークンを検証します。

   1. 特定のリクエストで長期トークンが有効な場合、Media CDN はリクエストされたコンテンツを配信します。
   2. 長期トークンが有効ではない場合（期限切れトークンまたは無効なパスのいずれかによって）、Media CDN は HTTP 403 Forbidden レスポンスを返します。

6. 媒体の再生が完了するか、長期署名が期限切れになるまで、このプロセスが繰り返されます。

デュアル トークン署名付きリクエストでサポートされているトークンの形式

Media CDN デュアル トークン署名付きリクエストは、トークンの種類に応じて複数の形式をサポートします。

短期署名付きリクエスト

短期署名付きリクエストの場合、Media CDN はデフォルトで Ed25519 署名で署名されたトークンをサポートします。既存のアプリケーション コードとその他の CDN との互換性のために、対称鍵ハッシュベースのメッセージ認証コード（HMAC）を使用することもできます。

HMAC を使用するには、Secret Manager を使用して HMAC シークレットを保存します。次に、Media CDN サービス アカウントに、保存されたシークレットにアクセスするためのアクセス権を付与します。ベスト プラクティスとして、セキュリティとパフォーマンスのために Ed25519 署名による非対称署名を使用することをおすすめします。

Media CDN サービス アカウントは Media CDN プロジェクトによって所有されており、プロジェクトのサービス アカウントのリストには表示されません。サービス アカウントは、明示的に許可するプロジェクトの Media CDN リソースにのみアクセス権を付与します。

サービス アカウントは次の形式です。

service-PROJECT_NUMBER@gcp-sa-mediaedgefill.iam.gserviceaccount.com

PROJECT_NUMBER はプロジェクト番号です。

サービスの Media CDN サービス アカウントを有効にするには、EdgeCacheOrigin などの Media CDN リソースを少なくとも 1 つ生成します。

長期署名付きリクエスト

長期署名付きリクエストの場合、Media CDN は Ed25519 署名を使用します。これは、EdgeCacheKeyset リソースに関連付けられた Google が管理する鍵で署名されます。

Media CDN は、長期トークンに対して単一のトークン形式をサポートしています。これは、HLS ストリーム用の単一名のクエリ パラメータまたは Cookie で使用できます。

署名付きリクエストの仕組み

署名付きリクエストでは、署名またはトークンを使用して、すべての閲覧者のコンテンツへのアクセスが認証されていることを検証します。Media CDN を構成して、アクセスの対象範囲を次のいずれかにできます。

• 期間限定の正確な URI または URI 接頭辞
• 特定のクライアント
• トークンを使用した署名付きリクエストの場合、ワイルドカードを含む 5 つまでのパス

署名付きリクエストを使用するには、署名と署名の検証のための鍵を生成します。次に、ルートを構成します。これにより、コンテンツの種類、クライアント属性、更新頻度要件に基づいて動作を最適化できます。署名付きリクエストをルートごとに適用できるため、特定のエンドポイントの保護に役立ちます。

各 Media CDN サービスは複数の鍵のコレクションを使用できます。鍵のコレクションはキーセットとしても知られています。キーセットによって、中断することなく鍵をローテーションして秘密鍵をご自身のインフラにわたって配布できます。

Media CDN を構成して、署名付きリクエストまたはトークンのいずれかを使用すると、コンテンツの保護に役立ちます。

トークンを使用した署名付きリクエストの場合、トークンは次のいずれかに配置できます。

• 選択したクエリ パラメータ内
• Cookie 内

詳細については、トークンを生成するをご覧ください。

署名を使用した署名付きリクエストの場合は、次のいずれかの形式を使用できます。

• クエリ パラメータを含む正確な URI: 正確な URI で URLPrefix を指定し、同じクエリ パラメータを複数の URI に追加します。
• クエリ パラメータを含む URI 接頭辞: URI 接頭辞で URLPrefix を指定し、同じクエリ パラメータを複数の URI に追加します。
• パス コンポーネント: パス コンポーネントを指定すると、相対マニフェスト URI が署名付き URI コンポーネントを継承できます。
• 署名付き Cookie: Cookie に URI 接頭辞を指定します。これにより、指定した接頭辞への任意の URI にアクセスできるようになります。

詳細については、署名を生成するをご覧ください。

考慮事項

以降のセクションでは、コンテンツの不正な配信を防ぐために考慮すべきさまざまな要因について説明します。

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

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

リクエストはオリジンで検証することをおすすめします。Media CDN は、署名が必要なルートの無効なリクエストと署名なしのリクエストを拒否しますが、クライアントが送信元に直接アクセスする方法を見つける可能性があります。追加の検証レイヤを使用すると、コンテンツを保護するための多層防御アプローチを実現できます。

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

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

アプリケーションがキャッシュ可能なステータス コードを無効なリクエストに送信すると、今後、有効なリクエストが誤って拒否される可能性があります。

URI の上限

最近のほとんどの HTTP クライアントでは、8,000 文字までの URI がサポートされます。ただし、一部のレガシー デバイスまたはニッチデバイスには、より厳しい上限がある場合があります。一般に、署名付き URI はリクエスト URI に約 125 文字追加します。これには次のものがあります。

• すべてのフィールド名が使用されている場合、各フィールド（Expires= や KeyName= など）について約 67 文字。
• Unix タイムスタンプの場合は 10 文字
• KeyName の場合、5 文字
• base64 でエンコードされた Signature 値の場合、43 文字

ベスト プラクティスとして、クエリ パラメータをトークンとして使用して、URI を 2,000 文字未満にすることをおすすめします。URI を短くすると、デバイスが切り捨てられた URI を Media CDN に送信するのを防ぐことができます。

従来の動画ストリーミング デバイス

従来の動画ストリーミング デバイスでは、マニフェストやメディア セグメント リクエストへの Cookie の添を完全にはサポートしていない場合があります。HTTP Cookie の処理に関する既知の問題がデバイスにある場合、署名付きリクエストとデュアルトークン交換にクエリ パラメータを使用するように Media CDN を構成します。

同意とプライバシーのコンプライアンス

Cookie を使用して短期トークンを交換する場合、必要な同意とプライバシーのコンプライアンスについては、お客様が単独で責任を負うものとします。デュアルトークン署名付きリクエストを使用するように Media CDN が構成されている場合、Google は長期トークンに使用される Cookie を発行、管理します。

課金

Secret Manager の課金の仕組みの詳細については、価格をご覧ください。

シークレットの Media CDN 取得は内部でキャッシュに保存されるため、Secret Manager からのシークレット取得の速度が大幅に低下します。取得の速度が低下すると、Secret Manager が監視し、課金するアクセスの速度も大幅に低下します。

Media CDN でのシークレット キャッシュの詳細については、鍵の概要をご覧ください。