CloudFrontの署名付きURLと署名付きCookieによるプライベートコンテンツ配信

概要

Amazon CloudFrontを使用してプライベートコンテンツを配信する場合、アクセス制御の仕組みを正しく理解することが重要です。CloudFrontのアクセス制御には大きく分けて2つの観点があります。1つは「オリジン（S3など）への直接アクセスを防ぐ」仕組み（OAC/OAI）、もう1つは「CloudFront経由のコンテンツ配信を特定のユーザーに限定する」仕組み（署名付きURL/署名付きCookie）です。

本記事では後者の「署名付きURL」と「署名付きCookie」に焦点を当て、それぞれの特徴、使い分け、キーグループの設定方法、そしてOAC/OAIとの違いについて解説します。

この記事のメリット

• 署名付きURLと署名付きCookieの違いと使い分けを理解できる
• キーグループ（推奨）とルートユーザーキーペア（非推奨）の違いを把握できる
• 規定ポリシーとカスタムポリシーの機能差を整理できる
• OAC/OAIとの役割の違いを明確に区別できる
• SCS試験のCloudFrontプライベートコンテンツ配信に関する問いに正確に答えられるようになる

技術解説

CloudFrontのアクセス制御の全体像

CloudFrontでプライベートコンテンツを安全に配信するには、以下の2つの仕組みを組み合わせます。

OAC/OAIは「S3バケットを直接参照できないようにする」ための仕組みであり、署名付きURL/署名付きCookieは「CloudFrontからコンテンツを取得できるユーザーを制限する」ための仕組みです。両者を組み合わせることで、オリジンへの直接アクセスとCloudFront経由の不正アクセスの両方を防止できます。

署名付きURLと署名付きCookieの仕組み

署名付きURLと署名付きCookieはどちらも、CloudFrontが配信するコンテンツへのアクセスを制限する仕組みです。アプリケーションがユーザーの認証を行い、認証済みユーザーに対して署名付きURLまたは署名付きCookieを発行します。CloudFrontはリクエスト受信時に署名を検証し、有効な場合のみコンテンツを返します。

署名にはRSA 2048ビットまたはECDSA 256ビットの秘密鍵を使用します。

sequenceDiagram
    participant User as ユーザー
    participant App as アプリケーション
    participant CF as CloudFront
    participant S3 as S3（オリジン）

    User->>App: 1. 認証リクエスト
    App->>App: 2. ユーザー認証とアクセス権の確認
    App->>User: 3. 署名付きURLまたは署名付きCookieを返却
    User->>CF: 4. 署名付きURLまたはCookie付きでリクエスト
    CF->>CF: 5. 公開鍵で署名を検証
    CF->>CF: 6. ポリシーステートメントの確認（有効期限 IP制限等）
    CF->>S3: 7. オリジンからコンテンツを取得（キャッシュがない場合）
    CF->>User: 8. コンテンツを返却

署名付きURLと署名付きCookieの使い分け

署名付きCookieを使用する場合、アプリケーションは以下の3つのSet-Cookieヘッダーをビューワーに送信します。

• CloudFront-Policy: ポリシーステートメント（Base64エンコード）
• CloudFront-Signature: 署名
• CloudFront-Key-Pair-Id: 署名に使用した公開鍵のID

規定ポリシーとカスタムポリシー

署名付きURLと署名付きCookieでは、アクセス条件を定義するポリシーとして「規定ポリシー（Canned Policy）」と「カスタムポリシー（Custom Policy）」を選択できます。

規定ポリシーは単純な有効期限のみの制御で済む場合に使用します。IPアドレス制限やアクセス開始日時の指定が必要な場合はカスタムポリシーを使用します。

キーグループとルートユーザーキーペアの比較

署名付きURLや署名付きCookieの署名に使用する鍵の管理方法として、「キーグループ（推奨）」と「AWSアカウントのルートユーザーによるCloudFrontキーペア（非推奨）」の2つがあります。

キーグループを使用する場合の手順は以下の通りです。

1. RSA 2048ビットまたはECDSA 256ビットのキーペアを生成する
2. 公開鍵をCloudFrontにアップロードする
3. 公開鍵をキーグループに追加する
4. ディストリビューションのキャッシュビヘイビアに信頼されたキーグループとして設定する

OAC/OAIとの違い（まとめ）

試験対策として、署名付きURL/CookieとOAC/OAIの役割の違いを明確にしておくことが重要です。

有効期限切れ時の挙動

署名付きURLや署名付きCookieの有効期限は、CloudFrontがHTTPリクエストを受信した時点で確認されます。

• ダウンロードが有効期限前に開始され、期限後に完了した場合: ダウンロードは成功する
• TCP接続が切断され、有効期限後に再開しようとした場合: ダウンロードは失敗する
• Range GETリクエストの場合: 有効期限後の個々のGETリクエストは失敗する

実践

ここでは、CloudFrontのキーグループを作成し、ディストリビューションのキャッシュビヘイビアに署名付きURL/Cookieの制限を設定する手順を解説します。署名付きURLの生成にはAWS CLIを使用します。

前提条件

• リージョン: ap-northeast-1（東京）（ただしCloudFrontはグローバルサービスです）
• S3バケットが作成済みで、テスト用のファイルがアップロードされている状態
• CloudFrontディストリビューションが作成済みで、S3バケットをオリジンとして設定済みの状態

作成するリソース一覧

手順1: キーペアの生成

ローカル環境でRSA 2048ビットのキーペアを生成します。

openssl genrsa -out private_key.pem 2048

openssl genrsa -out private_key.pem 2048

公開鍵を抽出します。

openssl rsa -pubout -in private_key.pem -out public_key.pem

openssl rsa -pubout -in private_key.pem -out public_key.pem

秘密鍵（private_key.pem）は署名付きURLの生成に使用するため、安全な場所に保管します。

手順2: 公開鍵のアップロード

• AWSマネジメントコンソールにログインし、上部の検索バーに CloudFront と入力し、表示された「CloudFront」を選択します。
• 左側ナビゲーションの「パブリックキー」を選択します。
• 「パブリックキーを作成」をクリックします。
• 以下の内容を入力します。
• 名前: my-signed-url-key
• キー値: public_key.pem の内容をテキストエディタで開き、-----BEGIN PUBLIC KEY----- から -----END PUBLIC KEY----- までを含む全体をコピーして貼り付けます
• コメント: 任意（例: 署名付きURL検証用）

• 「パブリックキーを作成」をクリックします。
• 作成された公開鍵のIDを控えておきます（署名付きURL生成時に使用します）。

手順3: キーグループの作成

• 左側ナビゲーションの「キーグループ」を選択します。
• 「キーグループを作成」をクリックします。
• 以下の内容を入力します。
• 名前: my-key-group
• コメント: 任意（例: 署名付きURL用キーグループ）
• パブリックキー: 手順2で作成した my-signed-url-key を選択して追加します
• 「キーグループを作成」をクリックします。

手順4: ディストリビューションのビヘイビアにキーグループを設定

• 左側ナビゲーションの「ディストリビューション」を選択します。
• 対象のディストリビューションを選択します。
• 「ビヘイビア」タブを選択します。
• 対象のビヘイビア（例: デフォルト *）を選択し、「編集」をクリックします。
• 「ビューワーのアクセスを制限する」で「Yes」を選択します。
• 「信頼された認可タイプ」で「Trusted key groups」を選択します。
• 「信頼されたキーグループの追加」で手順3で作成した my-key-group を選択します。

• 「変更を保存」をクリックします。
• ディストリビューションのステータスが「デプロイ済み」になるまで待ちます。

手順5: 署名なしでのアクセス確認

ビヘイビアの設定変更がデプロイされた後、署名なしでコンテンツにアクセスしてみます。

curl -I https://<ディストリビューションドメイン名>/test-file.txt

curl -I https://<ディストリビューションドメイン名>/test-file.txt

署名付きURLが必要な状態になっているため、以下のようにHTTP 403エラーが返されます。

HTTP/2 403

HTTP/2 403

手順6: 署名付きURLの生成とアクセス確認

AWS CLIの aws cloudfront sign コマンドで署名付きURLを生成します。--date-less-than には有効期限を指定します。

aws cloudfront sign \
    --url "https://<ディストリビューションドメイン名>/test-file.txt" \
    --key-pair-id <手順2で控えた公開鍵のID> \
    --private-key file://private_key.pem \
    --date-less-than "2026-12-31T00:00:00Z"

aws cloudfront sign \
    --url "https://<ディストリビューションドメイン名>/test-file.txt" \
    --key-pair-id <手順2で控えた公開鍵のID> \
    --private-key file://private_key.pem \
    --date-less-than "2026-12-31T00:00:00Z"

署名付きURLが出力されます。このURLにアクセスします。

curl "出力された署名付きURL"

curl "出力された署名付きURL"

ファイルの内容が正常に返されることを確認します。

手順7: 有効期限切れの署名付きURLの確認

有効期限を過去の日時に設定した署名付きURLを生成し、アクセスが拒否されることを確認します。

aws cloudfront sign \
    --url "https://<ディストリビューションドメイン名>/test-file.txt" \
    --key-pair-id <手順2で控えた公開鍵のID> \
    --private-key file://private_key.pem \
    --date-less-than "2020-01-01T00:00:00Z"

aws cloudfront sign \
    --url "https://<ディストリビューションドメイン名>/test-file.txt" \
    --key-pair-id <手順2で控えた公開鍵のID> \
    --private-key file://private_key.pem \
    --date-less-than "2020-01-01T00:00:00Z"

curl -I "出力された署名付きURL"

curl -I "出力された署名付きURL"

有効期限が過去のため、HTTP 403エラーが返されることを確認します。

まとめ

CloudFrontでプライベートコンテンツを安全に配信するには、目的に応じた仕組みを正しく選択する必要があります。

署名の鍵管理には、CloudFront APIで管理でき、IAMによるアクセス制御が可能な「キーグループ」の使用が推奨されます。ルートユーザーによるCloudFrontキーペアの作成は、AWSのセキュリティベストプラクティスに反するため非推奨です。

SCS試験では、OAC/OAIと署名付きURL/Cookieの役割が混同しやすい選択肢が出題されます。OAC/OAIはオリジンの保護、署名付きURL/Cookieはビューワーへの配信制御という役割の違いを正確に把握しておくことが重要です。

参照先

• 署名付き URL と署名付き Cookie を使用したプライベートコンテンツの提供 – Amazon CloudFront
• 署名付き URL の使用 – Amazon CloudFront
• 署名付き Cookie の使用 – Amazon CloudFront
• 署名付き URL と署名付き Cookie の署名者の指定 – Amazon CloudFront
• Amazon S3 オリジンへのアクセスの制限 – Amazon CloudFront