Amazon CloudFrontのセキュリティとプライベートコンテンツ

CloudFrontの保護は、一つの機能だけで実現するものではありません。通信経路をTLSで暗号化し、DDoSや不正なHTTPリクエストを緩和し、オリジンへの直接アクセスを防ぎ、必要な利用者だけに非公開コンテンツを配信する制御を組み合わせます。

たとえば、会員向けの設計素材サイトをCloudFrontから配信する場合、利用者とのHTTPS接続、WAFのルール、S3バケットへのアクセス許可、素材ごとの有効期限付き配信はそれぞれ別の役割を持ちます。どの経路を誰が通り、どの条件でコンテンツに到達できるかを分けて考えましょう。

TLSで保護する通信区間

CloudFrontの通信は、次の二つの区間に分けて設定します。

通信区間	設定と確認事項
ビューワーからCloudFront	https://<distribution-domain>.cloudfront.net ではCloudFrontの標準ドメイン用証明書を利用できる。独自ドメインをHTTPSで配信するには、そのドメインをディストリビューションに関連付け、対応する証明書を設定する
CloudFrontからオリジン	オリジンプロトコルポリシーでHTTPまたはHTTPSを選ぶ。HTTPSでは、オリジンがCloudFrontの検証条件を満たす証明書を提示し、証明書名や有効期限、信頼できる証明書チェーンを確認できる状態にする

独自ドメイン用にAWS Certificate Manager（ACM）の証明書を使う場合、その証明書は**米国東部（バージニア北部、us-east-1）**で発行またはインポートしてCloudFrontに関連付けます。CloudFrontがグローバルに配信するサービスであることと、証明書をどのリージョンに置くかは別の論点です。

片方の区間をHTTPSにしただけでは、もう片方も暗号化されるとは限りません。利用者からCloudFrontまでをHTTPSにしても、CloudFrontからオリジンへの接続をHTTPに設定していれば、その区間は暗号化されません。保護したい両方の区間に対し、プロトコルポリシーと証明書をそれぞれ確認してください。

DDoS緩和、Web要求の検査、地域制限

CloudFrontで使う防御機能は、それぞれ異なる種類のリスクを扱います。

AWS ShieldでDDoS攻撃を緩和する

AWS Shieldは、分散サービス妨害（DDoS）攻撃からAWS上のアプリケーションを保護するサービスです。Shield StandardはCloudFrontを含む対象サービスに対する標準的なDDoS保護を提供します。より高度な緩和機能、攻撃の可視性、専門的なサポートなどが必要な場合はShield Advancedを検討します。

ShieldはDDoS緩和を担い、個々のHTTPリクエストの内容をアプリケーションのルールで許可・拒否する機能とは役割が異なります。

AWS WAFでHTTP／HTTPSリクエストを制御する

AWS WAFは、HTTP／HTTPSリクエストをルールに照らして評価します。AWS管理ルールグループや独自ルールを使い、Web攻撃パターン、送信元IPアドレス、国、URIパス、リクエスト頻度などに基づいて許可、遮断、カウントできます。CloudFrontディストリビューションに関連付けるWeb ACLはグローバルスコープとして管理し、作成時は米国東部（バージニア北部、us-east-1）を選びます。

IPアドレスやCIDR範囲を基準にアクセスを許可・拒否する場合は、WAFのIP setとルールを使えます。特定のヘッダーやパス、一定時間内の要求数などを条件に加えたいときもWAFが適しています。

CloudFrontの地理的制限で国単位の可否を決める

CloudFrontの**地理的制限（geographic restriction）**では、要求元の国を基準にディストリビューションへの配信を許可または拒否できます。国単位の制御なので、特定のIPアドレスやCIDR範囲を指定する機能ではありません。IP単位やHTTPリクエストの細かな条件が必要ならWAFを使います。WAFのルールでも国を条件にできますが、CloudFrontの地理的制限は国単位の配信制御をディストリビューション設定として行う方法です。

要件	主に使う機能
国単位で配信を許可・拒否する	CloudFrontの地理的制限
IPアドレス、URI、HTTPヘッダー、レートなどで要求を検査する	AWS WAF
DDoS攻撃を緩和する	AWS Shield

これらは併用できます。たとえば国単位の制限をCloudFrontで行い、許可された国からの要求についてWAFでIPやリクエスト内容を検査し、ShieldでDDoSへの保護を行う構成が考えられます。

S3オリジンを非公開にする

S3をCloudFrontのオリジンにする場合、利用者がS3のURLへ直接アクセスできる状態では、CloudFrontのキャッシュやアクセス制御を迂回できます。S3バケットを非公開に保ち、CloudFrontディストリビューション経由の要求だけに必要な権限を与えます。

現在の新規構成では、**OAC（Origin Access Control、オリジンアクセスコントロール）**を使う方法が推奨されます。CloudFrontのオリジン設定にOACを関連付け、S3バケットポリシーではCloudFrontのサービスプリンシパル（cloudfront.amazonaws.com）を許可します。さらにAWS:SourceArn条件で対象のディストリビューションARNを指定し、許可する範囲を限定します。すべてのCloudFrontディストリビューションに対してバケットを開くのではなく、必要なディストリビューションと操作だけを許可してください。

S3オブジェクトがAWS KMSのSSE-KMSで暗号化されている場合は、S3バケットポリシーだけでなく、KMSキーのポリシーでもCloudFrontからの復号に必要な権限を許可します。CloudFront経由の書き込みなど、読み取り以外の操作を許す設計では、ビヘイビア、S3ポリシー、KMSキーの権限を合わせて必要最小限に絞ります。

既存のディストリビューションには、旧方式の**OAI（Origin Access Identity、オリジンアクセスアイデンティティ）**が設定されていることがあります。OAIはS3オリジンへのアクセス元を限定する従来方式ですが、SSE-KMS暗号化オブジェクトや書き込み系メソッドなどに対応できない制約があります。新規設計ではOACを選び、既存OAIの移行時はバケットポリシーや暗号化設定を合わせて見直します。

ALBなどのカスタムオリジンを保護する

ALBやEC2上のWebサーバーなどをオリジンにする場合、CloudFrontのオリジン設定にカスタムオリジンヘッダーを登録できます。CloudFrontがオリジンへ要求を送る際にヘッダーを付与し、ALBのリスナールールやアプリケーション側で期待する名前と値を持つ要求だけを処理するよう構成します。

たとえば、CloudFrontからX-Edge-Route: assets-gateway-74mQというヘッダーを付け、ALBでその値を持つ要求だけを素材配信用ターゲットへ転送する方法があります。ヘッダー名と値は独自に定め、CloudFrontからオリジンへの通信もHTTPSにします。

このヘッダーはオリジンへ届く要求を識別する補助策です。利用者の本人確認やアプリケーション認可を置き換えるものではありません。また、オリジンへ直接接続できる公開経路があれば、別のルールや設定ミスを通じて迂回される可能性があります。ALBのセキュリティグループやネットワーク設定で到達元を限定できる場合はそれも組み合わせ、ヘッダー値を安全に管理・更新してください。

署名付きURLと署名付きCookie

CloudFrontの署名付きURLと署名付きCookieは、認証済みの利用者へ非公開コンテンツを一時的に配信するときに使います。アプリケーションは信頼された署名者の秘密鍵を使ってアクセス条件に署名し、CloudFrontはエッジで対応する公開鍵を使って署名と条件を検証します。条件を満たさなければ、キャッシュに対象コンテンツが存在していてもCloudFrontは要求を拒否します。

新しい構成では**信頼されたキーグループ（trusted key group）**に公開鍵を登録する方式を使えます。秘密鍵はアプリケーションの保護された環境で管理し、ブラウザーなどのクライアントに渡しません。対象コンテンツを配信するビヘイビアには、署名を必須にする設定と信頼するキーグループを関連付けます。

署名付きURL：個別のファイルを許可する

署名付きURLは、特定のファイルやオブジェクトにアクセスするためのURLに署名情報を加える方式です。ディストリビューションのドメイン名とパスに加えて、署名者を識別するキーID、署名、有効条件がURLに含まれます。標準的なポリシーでは期限を設定し、独自のカスタムポリシーでは対象パスや有効期間などを細かく指定できます。

たとえば、利用者が購入した個別の製図データを数十分だけダウンロードできるようにする場合に向いています。URLそのものが一時的なアクセス資格情報になるため、HTTPSで渡し、漏えい時の影響を抑えるため有効期間を必要な長さに限定します。期限を過ぎた署名付きURLは利用できません。

署名付きCookie：複数ファイルに共通条件を適用する

署名付きCookieは、対象ドメインへの複数の要求にブラウザーがCookieを添付し、共通のポリシーを適用する方式です。アプリケーションは利用者に署名付きCookieを設定してから保護対象コンテンツへ案内し、CloudFrontは各要求を受け取るたびにエッジで署名とポリシーを検証します。

ポリシーでは対象URLの範囲と有効期限を設定できます。カスタムポリシーでは開始時刻や要求元IPアドレス範囲などの条件も指定できます。たとえば、会員向け講座の複数の動画・字幕・サムネイルへ同じ期間だけアクセスさせる場合は、ファイルごとにURLを発行せずに保護対象をまとめられます。Cookieを事前に設定するため、URLを変えずにその後の要求を保護できる点も利点です。

比較	署名付きURL	署名付きCookie
主な対象	個別のファイルやオブジェクト	複数のファイルや共通のパス範囲
利用者への配布	署名情報を含むURLを渡す	先に署名付きCookieを設定する
URL	署名や期限に関する情報がURLに含まれる	URLを変えずにCookieでアクセス条件を渡せる
適した例	個別ダウンロードへの期限付きリンク	会員ページ内の動画や関連アセット一式

署名付きURLとCookieはCloudFrontのコンテンツアクセスを条件付きにする仕組みで、アプリケーションのログイン認証そのものではありません。まずアプリケーションが利用者を認証し、その利用者に必要な範囲と期限だけを含む署名を発行します。IPアドレス条件は利用者のネットワーク変更やプロキシの利用で要求が拒否されることがあるため、実際の配信要件に合わせて使います。

試験での選択ポイント

• 利用者からCloudFront、CloudFrontからオリジンの両方を暗号化する：それぞれの通信区間にHTTPSと証明書を設定する。独自ドメイン用のCloudFront証明書をACMから使う場合はus-east-1に置く。
• DDoS攻撃への保護を選ぶ：標準のDDoS保護はShield Standard、高度な保護や支援が必要ならShield Advancedを検討する。
• HTTPリクエストを条件で許可・拒否する：AWS WAFでIP、国、URI、ヘッダー、レートなどのルールを設定する。
• 国単位で配信可否を制御する：CloudFrontの地理的制限を使う。特定IPやリクエスト属性まで調べる要件ではWAFを使う。
• S3を直接公開せずCloudFrontから配信する：OAC、対象ディストリビューションを指定したバケットポリシー、必要に応じてKMSキーの許可を設定する。
• ALBなどのオリジンをCloudFront経由に限定する：カスタムオリジンヘッダーの検証に加えて、ネットワーク上の到達元も可能な範囲で制限する。
• 利用者に個別ファイルを期間限定で渡す：署名付きURLを使う。複数の関連ファイルをまとめて許可する場合は署名付きCookieを使う。

公式ドキュメント

• CloudFrontとHTTPSの利用
• CloudFrontでACM証明書を使用するリージョン要件
• CloudFrontでのAWS WAF利用
• CloudFrontの地理的制限
• AWS Shieldの機能
• OACでS3オリジンへのアクセスを制限する
• 署名付きURL
• 署名付きCookie