はじめに

DX開発事業部 深川です

今回は、Google Cloud の Cloud CDN を使って、特定の認証済みユーザーだけに有料動画や機密ファイルなどのコンテンツを安全に配信するための強力な機能、「署名付きCookie（Signed Cookies）」について調べたのでこちらで記載します。

「URLを1つずつ暗号化する『署名付きURL』は知っているけど、Cookie版はどう使い分けるの？」という方向けに、仕組みから実装の流れまでをまとめました。

署名付きCookieとは？（署名付きURLとの違い）

Cloud CDN（およびLoad Balancing）には、未認証のアクセスからバックエンド（Cloud Storageやカスタムオリジン）を守るために、2つのアクセス制御メカニズムが用意されています。

①. 署名付きURL (Signed URLs)

②. 署名付きCookie (Signed Cookies)

最大の使い分けのポイントは、「アクセスさせたいファイルの数」です。

比較項目 署名付きURL 署名付きCookie
対象 単一のファイル（単一のURL） 複数のファイル、または特定のパス配下すべて
仕組み URLのクエリパラメータに署名情報を付与 HTTPのSet-Cookieヘッダーに署名情報を付与
主なユースケース 1つのPDFのダウンロード、特定の1本の動画再生 HLS/DASH形式の動画配信（プレイリストと大量のセグメントファイル）、Webサイト全体の制限

💡 なぜ動画配信でCookieが有利なのか？
HLS形式の動画配信では、1つの再生用インデックスファイル（.m3u8）から、数百〜数千の細切れになった動画データ（.tsファイル）が読み込まれます。署名付きURLだと、この大量のファイルすべてのURLに署名を仕込む必要がありますが、署名付きCookieなら「このディレクトリ配下は一括許可」という設定ができるため、実装が圧倒的に楽になります。

署名付きCookieの仕組み（アーキテクチャ）

署名付きCookieが機能する大まかな流れは以下の通りです。

  1. ユーザー認証: クライアント（ブラウザやアプリ）が、あなたのWebアプリケーションにログインします。
  2. Cookieの発行: アプリケーション側で「このユーザーは動画視聴権限がある」と判断したら、Cloud CDNが認識できる特定のフォーマット（署名付き）でCookieを生成し、Set-Cookieでクライアントに返します。
  3. コンテンツ要求: クライアントがCloud CDN（ロードバランサ）経由で動画ファイル（例: /premium/video.m3u8）をリクエストします。この時、ブラウザは自動的にCookieを送信します。
  4. CDNでの検証: Cloud CDNのエッジサーバーが、事前に登録された「秘密鍵」を使ってCookieの署名を検証します。
    ・ 有効な場合: キャッシュがあればキャッシュから、なければバックエンドからコンテンツを返します。
    ・ 無効・期限切れの場合: 403 Forbidden を返し、アクセスをブロックします。

実装に必要な3つのステップ

実際にこれを導入する場合の手順の概要です。

1. Cloud CDN（ロードバランサ）に署名鍵を登録する

まずは、Google Cloud側で署名の検証に使う鍵（キーペア）を作成し、バックエンドサービスに登録します。

 

<br /># 1. ランダムな暗号鍵（秘密鍵）を生成
head -c 16 /dev/urandom | base64 | tr '+/' '-_' > site-key.txt

# 2. ロードバランサのバックエンドサービスに鍵を登録
gcloud compute backend-services add-signed-url-key BACKEND_SERVICE_NAME \
--key-name=my-cookie-key \
--key-file=site-key.txt

 

2. アプリケーションで署名付きCookieを生成する
ユーザーがログインした際、バックエンドのアプリケーション（Node.js, Go, Pythonなど）で、CDNが指定する形式のCookie値を計算して発行します。

Cookieには主に以下の情報（ポリシー）を含めます：
・ URLPrefix: アクセスを許可するパス（例: https://media.example.com/premium/）
・ Expires: Cookieの有効期限（Unixタイムスタンプ）
・ KeyName: Google Cloudに登録した鍵の名前（例: my-cookie-key）
・ Signature: 上記の項目を秘密鍵でハッシュ（HMAC-SHA1）化した署名

これらを Cloud-CDN-Cookie という名前のCookie（または個別の3つのCookie）としてクライアントにセットします。

3. CDN側で「署名付きCookieの要求」を有効化する

Google Cloudコンソール、またはgcloudコマンドで、対象のバックエンドサービスに対して「署名付きURL/Cookieの要求」を有効（Enable）に切り替えます。これで、正しいCookieを持っていないリクエストはすべてCDNの玄関口で弾かれるようになります。

実務でハマりがちな注意ポイント

・ SameSite属性とクロスドメインの壁
Webアプリのドメイン（app.example.com）と、CDNのドメイン（media.example.com）が異なる場合、サードパーティCookieの制限に引っかかる可能性があります。ドメインを統一するか、SameSite=None; Secure の設定を適切に行う必要があります。
・ URLPrefixの末尾の「/」
ポリシーで指定するURL前方一致のプレフィックス（URLPrefix）の末尾に / を付け忘れると、意図しないパスまで許可されてしまう（例: /premium-content も許可されてしまう）ことがあるので、厳密に設計しましょう。
・ キャッシュの分離
署名付きCookieを使用する場合、CDNはデフォルトで「署名が正しいか」を検証しますが、キャッシュ自体は全ユーザーで共有されます（URLが同じなら同じキャッシュを返す）。もしユーザーごとに完全に返すコンテンツを変えたい場合は、キャッシュキーの設定に注意が必要です。

まとめ

Cloud CDN の署名付きCookieは、「大量のファイルを、特定のユーザーにだけ、安全かつ高速に配信したい」というユースケース（特に動画配信や有料アセット配布）において最強の味方になります。

実装には「鍵の管理」や「Cookie のドメイン設計」など少しコツが必要ですが、一度組んでしまえばインフラレベルで強固なアクセス制限をかけられます。ぜひ試してみてください！

・参考にした公式ドキュメント: Google Cloud CDN – 署名付き Cookie の使用