はじめに
こんにちは、山本です。
近年開発されている Web アプリケーションでは、ユーザー認証が実施されることが基本的なアーキテクチャになってきているかと思います。 Web アプリケーションの開発経験が浅い私にとって、 Amazon CloudFront などの CDN をユーザーと Web アプリケーションの間に挟むというユーザー体験の向上によく使われている「アーキテクチャの改善方法」の中でどのように認証ヘッダーなどの情報を渡すような設定をしているのかあまり理解できていませんでした。
この度、そのような設定方法について理解する機会がありましたので今回はAmazon CloudFront(以降では CloudFront と称します)での設定方法に着目して当ブログで紹介します。
認証ヘッダーと CloudFront のデフォルト動作
基本的にユーザー認証が必要な API や Web アプリケーションでは、認証ヘッダー( Authorization ヘッダー)を用いてトークンやベーシック認証情報をクライアント側から Web サーバー側に送信します。
しかし、CloudFront を コンテンツ配信ネットワーク(CDNサービス) としてアーキテクチャに適用すると CloudFront のデフォルトの設定ではオリジン( Web サーバーや API )に認証ヘッダーを転送してくれません。
デフォルトで設定されていない理由は、個人的にはCloudFront のログやキャッシュキーに誤って機密性の高いトークンや API キーを扱わないことや、キャッシュ効率自体を上げるためなのではないかと認識しているので「セキュリティ保護されているなぁ」と感心していましたが、当然このままではオリジンが認証ヘッダーに基づいてレスポンスを変える場合、何かしらの方法で明示的にヘッダーについて設定しないとCloudFrontの挙動がおかしなことになってしまう可能性があります。
認証ヘッダーに関する設定方法 2 パターン (抜粋)
前述したようなユーザー個々の情報を認証する場合は CloudFront でのオリジンリクエストポリシー設定で認証ヘッダーが付与されたクライアントからのリクエストを制御することでCloudFrontが正しく認証ヘッダーの情報をオリジンに転送してくれます。(後述)
しかし、似たような方法ですが全く異なる性質を持った認証ヘッダーに関する設定もありますのでそちらについても紹介します。
※他にもヘッダーを扱う設定が存在しますが、当ブログでは上記二種類を取り上げます。
オリジンリクエストポリシーを使用する方法
前述でもありましたが、この方法では CloudFront でのオリジンリクエストポリシー設定で認証ヘッダーが付与されたクライアントからのリクエストを制御することでCloudFrontが正しく認証ヘッダーの情報をオリジンに転送を行うという形式をとります。
また、キャッシュキー( CloudFront で管理するオリジンからのキャッシュ情報)にも認証情報を含める必要がある場合は、キャッシュポリシー 側でホワイトリスト指定が必要になります。
オリジンリクエストポリシーを適切に定義することで CloudFront はクライアントからのリクエストに含まれた認証ヘッダーをオリジンに適切に送信します。
この方法は、クライアントからのリクエストに認証ヘッダーが含まれているので、個別トークンでの認証をオリジンで正しく行うことができます。
つまり、アプリのユーザー一人一人に対して認証ヘッダーを使用して認証を行うことができ、CloudFront ではエンドユーザーからの認証情報を通過させるという特性を持ちます。
カスタムヘッダーを使用するパターン
この方法では、 CloudFront のビヘイビア設定にて「Origin Custom Header」を追加します。
(例)
Header name: Authorization Value: Basic ZGFwczpwYXNzd29yZA==
具体的には、オリジンリクエストポリシーを使用するのパターンとは異なりクライアント側に認証ヘッダーを任せず、クライアントからのリクエストに対してCloudFrontが常に一定の認証情報を付与するという方式をとっています。
上図の通り、各ユーザが異なるトークンを持っているわけではないのでユーザー認証をするための仕組みではありませんが、カスタムヘッダーを定義しておくことで第三者の悪意あるユーザーがCloudFrontのキャッシュコンテンツではなくオリジンであるWebサーバーに直接アクセスされることを防止することができます。
パターン比較表
| 比較項目 | カスタムヘッダー方式 | オリジンリクエストポリシー方式 |
|---|---|---|
| 認証情報の出所 | CloudFront が固定値を付与 | クライアントが送信 |
| 認証方法 | 固定値による認証（例：Basic 認証、API キー） | 動的なトークン認証（例：Bearer トークン、JWT） |
| CloudFront の設定 | Origin Custom Headers に追加（オリジン設定） | オリジンリクエストポリシーで認証ヘッダーを許可 |
| セキュリティ管理 | 認証情報は CloudFront 側に固定 | ユーザーごとの認証に対応可能 |
おわりに
いかがでしたでしょうか、当ブログでは認証ヘッダーの使用例の少しややこしい部分について紹介しました。
上記のように CloudFront では、ユーザーごとのトークン認証やオリジンコンテンツへのアクセスを防御するためのカスタムヘッダーなど要件によってヘッダーの設定方法もさまざま存在しています。
今回紹介したクライアントからオリジンへのリクエスト時に適用するヘッダーの実装方法の他にも、CloudFrontからクライアントへのレスポンス時のヘッダーを制御するパターンなども存在するので是非調べてみてください。
また、CloudFront などの CDN サービスをインフラストラクチャに追加する際には必ず認証ヘッダーなどの仕組みに触れることがあるかと思いますので、参考になれば幸いです。
山本 竜也 (記事一覧)
2025年度新入社員です！AWSについてはほぼ未経験なのでたくさんアウトプットできるよう頑張ります✨
