読者です 読者をやめる 読者になる 読者になる

CloudFrontでコンテンツ配信 (署名付きCookie)

AWS

先日投稿した記事では署名付きURLでのアクセス制御について書きましたが、今回は署名付きCookieを使用してのアクセス制御についてです。

norikone.hatenablog.com

署名付きURLと署名付きCookieのどっちを使えばいいの?

署名付きURLを使用するケース

  • 個別のファイルそれぞれに対してアクセスの制御をする場合
  • RTMPでコンテンツを配信する場合 (署名付きCookieではサポートされていないみたいです)
  • ユーザ側がCookieに対応していない場合

署名付きCookieを使用するケース

  • サイト全体の認証など、複数のオブジェクトに対してアクセスの制御をする場合
  • 使用しているURLを変更したくない場合

署名付きURLでは個別のオブジェクトそれぞれにアクセス制御をする必要があるので、各オブジェクトにアクセスしようとするリクエストのたびに対応する署名付きURLを作成する必要がありました。
署名付きCookieを使用することによって、アプリケーション側で認証したユーザに対して複数のオブジェクトへアクセス可能にすることができます。
例えば、認証済みユーザならWebサイト内の全てのコンテンツにアクセス可能、といったことができるようになります。

署名付きCookieを取得してオブジェクトにアクセスするまでの流れ

  1. ユーザが、コンテンツにアクセスしていいかどうかの判断を行うサーバに署名付きCookieを要求
  2. ログイン認証などによりそのユーザに対してコンテンツにアクセスする許可が降りた場合、サーバ側で署名付きCookieを作成しレスポンスに付加
  3. ユーザは取得した署名付きCookieでCloudFrontにオブジェクトを要求
  4. CloudFront側で有効な署名だと判断したときのみユーザにオブジェクトを配信

大まかな流れは署名付きURLの場合とあまり変わりませんね。

署名付きCookie発行の流れ

  1. ポリシーの作成 (JSON)
  2. ポリシーに署名
  3. 署名されたポリシーをBase64エンコード

1. ポリシーの作成 (JSON)

ポリシーとは、署名したCookieでできることを制限するもので、JSONで記載します。
例えば特定のオブジェクトのみアクセス可能にしたり、Cookieの有効期間を指定して期限切れであればアクセスを拒否したりできます。

2. ポリシーに署名

CloudFrontでは、署名にRSAキーペアを使用します。
1.で作成したポリシーをハッシュ化し、キーペアの秘密鍵で署名します。
これによって、署名したCookieが改ざんされているかどうかのチェックができます。

3. 署名されたポリシーをBase64エンコード

2.で署名されたポリシーをBase64エンコードします。

署名付きCookieは、以下の3つのペアで構成されています。

  • CloudFront-Signature
    • 上記「署名処理の流れ」で作成した、署名されたポリシーをBase64エンコードしたものです。
  • CloudFront-Policy
  • CloudFront-Key-Pair-Id
    • RSAキーペアのIDです。

これらをSet-Cookieヘッダに含めてレスポンスを返せば終了です。

署名付きCookieを取得してからオブジェクトにアクセスするまで

ユーザが署名付きCookieを保持した状態でオブジェクトを要求すると、CloudFrontが署名が有効かどうかをチェックします。
もし無効な署名であればアクセスを拒否します。
署名が有効であった場合は、CookieのポリシーステートメントCookieの有効期間などを確認して、リクエストが有効かどうかをチェックします。
有効であればユーザにオブジェクトを配信します。

おわり

以上、署名付きCookieでのアクセス制御の大まかな流れでした。
PHPで適当にコードを書いたので、気が向いたらアップします(逃避)。