翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
署名付き Cookie の使用
CloudFront 署名付き Cookie を使用すると、現在の URLs を変更しない場合や、ウェブサイトのサブスクライバーの領域にあるすべてのファイルなど、複数の制限付きファイルへのアクセスを提供する場合に、コンテンツにアクセスできるユーザーを制御できます。このトピックでは、署名付き Cookie を使用する際の考慮事項と、既定ポリシーとカスタムポリシーを使用するように署名付き Cookie を設定する方法について説明します。
トピック
署名付き Cookie の既定ポリシーとカスタムポリシーの選択
署名付き Cookie を作成する場合、Cookie の有効期間など、署名付き Cookie で制限を指定する JSON 形式のポリシーステートメントを作成します。既定ポリシーまたはカスタムポリシーを使用できます。次の表では、既定ポリシーとカスタムポリシーを比較しています。
説明 | 既定ポリシー | カスタムポリシー |
---|---|---|
ポリシーステートメントを複数のファイル用に再利用できる。ポリシーステートメントを再利用するには、 |
いいえ |
はい |
ユーザーがコンテンツへのアクセスを開始できる日時を指定できる |
いいえ |
はい (オプション) |
ユーザーがコンテンツにアクセスできなくなる日時を指定できる |
はい |
はい |
コンテンツにアクセスできるユーザーの IP アドレスまたは IP アドレス範囲を指定できる |
いいえ |
はい (オプション) |
既定ポリシーを使用して署名付き Cookie を作成する方法については、「既定ポリシーを使用する署名付き Cookie の設定」を参照してください。
カスタムポリシーを使用して署名付き Cookie を作成する方法については、「カスタムポリシーを使用する署名付き Cookie の設定」を参照してください。
署名付き Cookie の仕組み
署名付き Cookie CloudFront の の設定方法と、ユーザーが署名付き Cookie を含むリクエストを送信したときの の CloudFront 応答の概要を次に示します。
-
CloudFront ディストリビューションで、1 つ以上の信頼されたキーグループを指定します。このグループには、 CloudFront が URL 署名の検証に使用できるパブリックキーが含まれています。対応するプライベートキーを使用して URL に署名します。
詳細については、「署名付き URL と署名付き Cookie を作成できる署名者の指定」を参照してください。
-
ユーザーがコンテンツにアクセスできるかどうかを判断し、アクセスできる場合は、3 つの
Set-Cookie
ヘッダーをビューワーに送信するアプリケーションを開発します (各Set-Cookie
ヘッダーには名前と値のペアを 1 つだけ含めることができ、 CloudFront 署名付き Cookie には 3 つの名前と値のペアが必要です)。ビューワーがプライベートコンテンツをリクエストする前に、ビューワーにSet-Cookie
ヘッダーを送信する必要があります。Cookie の有効期限を短く設定した場合、ユーザーがアクセスを続行できるように、以降のリクエストに対してさらに 3 つのSet-Cookie
ヘッダーを送信することもできます。通常、 CloudFront ディストリビューションには少なくとも 2 つのキャッシュ動作があります。1 つは認証を必要としない動作で、もう 1 つは認証を必要としない動作です。サイトのセキュリティで保護された部分のエラーページには、ログインページへのリダイレクタまたはリンクが含まれます。
Cookie に基づいてファイルをキャッシュするようにディストリビューションを設定する場合、署名 CloudFront 付き Cookie の属性に基づいて個別のファイルをキャッシュしないでください。
-
ユーザーがウェブサイトにサインインし、コンテンツに対して支払いをするか、またはその他のアクセスの要件を満たします。
-
アプリケーションは、レスポンスで
Set-Cookie
ヘッダーを返し、ビューワーは名前と値のペアを格納します。 -
ユーザーがファイルをリクエストします。
ユーザーのブラウザまたはその他のビューワーは、ステップ 4 の名前と値のペアを取得し、リクエストの
Cookie
ヘッダーに追加します。これが署名付き Cookie です。 -
CloudFront はパブリックキーを使用して、署名付き Cookie の署名を検証し、Cookie が改ざんされていないことを確認します。署名が無効である場合、リクエストは拒否されます。
Cookie 内の署名が有効な場合、 は Cookie 内のポリシーステートメント CloudFront を確認し (既定ポリシーを使用している場合はポリシーステートメントを作成します)、リクエストがまだ有効であることを確認します。例えば、Cookie の開始日時と終了日時を指定した場合、 は、アクセスを許可する期間中にユーザーがコンテンツにアクセスしようとしている CloudFront ことを確認します。
リクエストがポリシーステートメントの要件を満たしている場合、 は制限されていないコンテンツと同様にコンテンツ CloudFront を提供し、ファイルがエッジキャッシュにすでに存在するかどうかを判断し、必要に応じてリクエストをオリジンに転送して、そのファイルをユーザーに返します。
署名付き Cookie の悪用の防止
Set-Cookie
ヘッダーで Domain
パラメータを指定する場合、同一ルートドメイン名を使用するユーザーによる潜在的なアクセスを低減できる、最も厳密な値を指定します。たとえば、apex.example.com は、特に example.com を制御しない場合は、example.com よりも優先されます。これによって、ユーザーが example.com のコンテンツにアクセスすることを防止できます。
この種類の攻撃を防ぐには、以下の作業を行います。
-
Expires
ヘッダーでセッション Cookie が作成されるように、Max-Age
およびSet-Cookie
Cookie 属性を除外します。セッション Cookie は、ユーザーがブラウザを閉じたときに自動的に削除されるため、ユーザーがコンテンツに不正アクセスする可能性が低くなります。 -
ビューワーがリクエストに Cookie を含める場合に Cookie が暗号化されるように、
Secure
属性を含めます。 -
可能な場合、カスタムポリシーを使用してビューワーの IP アドレスを含めます。
-
CloudFront-Expires
属性では、ユーザーがコンテンツにアクセスできるようにする期間に基づいて、最短で適切な有効期限の時刻を指定します。
は署名付き Cookie の有効期限日時をいつ CloudFront 確認しますか?
署名付き Cookie がまだ有効かどうかを判断するために、 は HTTP リクエスト時に Cookie の有効期限日時 CloudFront を確認します。有効期限切れ時刻の直前にクライアントが大きなファイルのダウンロードを開始した場合、ダウンロード中に有効期限切れ時刻が経過してもダウンロードは完了します。TCP 接続が中断し、有効期限切れ時刻が経過した後にクライアントがダウンロードを再開した場合、ダウンロードは失敗します。
クライアントが、ファイルを断片的に取得するレンジ GET を使用した場合、有効期限切れ時刻が経過した後に実行された GET リクエストは失敗します。レンジ GET の詳細については、「がオブジェクトの部分リクエスト CloudFront を処理する方法 (範囲 GETs)」を参照してください。
サンプルコードおよびサードパーティーツール
プライベートコンテンツ用のサンプルコードは、署名付き URL の署名を作成する方法のみを示しています。ただし、署名付き Cookie の署名を作成するプロセスは非常によく似ており、サンプルコードの多くの部分は関連しています。詳細については、以下のトピックを参照してください。