署名付き Cookie を使用する
CloudFront 署名付き Cookie を使用すると、現在の URL を変更したくない場合や、複数の制限付きファイル (ウェブサイトの購読者の領域にあるすべてのファイルなど) へのアクセスを提供する場合に、誰がコンテンツにアクセスできるかを制御できます。このトピックでは、署名付き 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 つのキャッシュ動作があります。認証を必要としないものと、認証を必要とするものです。サイトのセキュリティで保護された部分のエラーページには、ログインページへのリダイレクタまたはリンクが含まれます。
Cookie に基づいてファイルをキャッシュするようにディストリビューションを設定している場合、CloudFront は署名付き Cookie の属性に基づいて個別のファイルをキャッシュしません。
-
ユーザーがウェブサイトにサインインし、コンテンツに対して支払いをするか、またはその他のアクセスの要件を満たします。
-
アプリケーションは、レスポンスで
Set-Cookie
ヘッダーを返し、ビューワーは名前と値のペアを格納します。 -
ユーザーがファイルをリクエストします。
ユーザーのブラウザまたはその他のビューワーは、ステップ 4 の名前と値のペアを取得し、リクエストの
Cookie
ヘッダーに追加します。これが署名付き Cookie です。 -
CloudFront はパブリックキーを使用して、署名付き Cookie の署名を検証し、Cookie が改ざんされていないことを確認します。署名が無効である場合、リクエストは拒否されます。
Cookie の署名が有効である場合、CloudFront は Cookie のポリシーステートメントを参照して (または既定ポリシーを使用している場合はポリシーステートメントを作成して)、リクエストがまだ有効であることを確認します。たとえば、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
属性では、ユーザーがコンテンツにアクセスできるようにする期間に基づいて、最短で適切な有効期限の時刻を指定します。
CloudFront が署名付き Cookie の有効期限切れ日時を確認するタイミング
署名付き Cookie がまだ有効であるかどうかを確認するために、CloudFront は HTTP リクエスト時に、Cookie の有効期限切れ日時を確認します。有効期限切れ時刻の直前にクライアントが大きなファイルのダウンロードを開始した場合、ダウンロード中に有効期限切れ時刻が経過してもダウンロードは完了します。TCP 接続が中断し、有効期限切れ時刻が経過した後にクライアントがダウンロードを再開した場合、ダウンロードは失敗します。
クライアントが、ファイルを断片的に取得するレンジ GET を使用した場合、有効期限切れ時刻が経過した後に実行された GET リクエストは失敗します。レンジ GET の詳細については、「CloudFront がオブジェクトの部分的リクエスト (レンジ GET) を処理する方法」を参照してください。
サンプルコードおよびサードパーティーツール
プライベートコンテンツ用のサンプルコードは、署名付き URL の署名を作成する方法のみを示しています。ただし、署名付き Cookie の署名を作成するプロセスは非常によく似ており、サンプルコードの多くの部分は関連しています。詳細については、以下のトピックを参照してください。