

# コンテンツへのセキュアなアクセスの設定とアクセスの制限
<a name="SecurityAndPrivateContent"></a>

CloudFront には、コンテンツをセキュリティで保護するためのオプションが用意されています。CloudFront を使用してコンテンツへのアクセスを保護および制限する方法を次に示します。
+ HTTPS 接続を設定する
+ 特定の地理的な場所にいるユーザーがコンテンツにアクセスできないようにする
+ CloudFront の署名付き URL または署名付き Cookie を使用してコンテンツにアクセスするようにユーザーに要求する
+ 特定のコンテンツフィールドのフィールドレベルの暗号化を設定する
+ AWS WAF を使用してコンテンツへのアクセスを管理する

また、インフラストラクチャとアプリケーションに DDoS 耐性アーキテクチャを実装する必要があります。詳細については、「[AWS Best Practices for DDoS Resiliency](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/aws-best-practices-ddos-resiliency.html)」を参照してください。

詳細については、以下を参照してください。
+ [Securing your content delivery with CloudFront](https://aws.amazon.com/cloudfront/security/)
+ [SIEM on Amazon OpenSearch Service](https://github.com/aws-samples/siem-on-amazon-opensearch-service/blob/main/README.md)

**Topics**
+ [CloudFront で HTTPS を使用する](using-https.md)
+ [代替ドメイン名と HTTPS を使用する](using-https-alternate-domain-names.md)
+ [CloudFront による相互 TLS 認証 (Viewer mTLS)](mtls-authentication.md)
+ [オリジンの相互 TLS と CloudFront](origin-mtls-authentication.md)
+ [署名付き URL と署名付き Cookie を使用したプライベートコンテンツを提供する](PrivateContent.md)
+ [AWS オリジンへのアクセスを制限する](private-content-restricting-access-to-origin.md)
+ [Application Load Balancer へのアクセスを制限する](restrict-access-to-load-balancer.md)
+ [コンテンツの地理的配分を制限する](georestrictions.md)
+ [フィールドレベル暗号化を使用した機密データの保護](field-level-encryption.md)

# CloudFront で HTTPS を使用する
<a name="using-https"></a>

ビューワーによる HTTPS の使用を必須とするように CloudFront を設定して、CloudFront がビューワーと通信するときの接続を暗号化することができます。また、オリジンに HTTPS を使用するように CloudFront を設定して、CloudFront がオリジンと通信するときの接続を暗号化することも可能です。

ビューワーとの通信とオリジンとの通信の両方で HTTPS を必須とするように CloudFront を設定する場合、CloudFront がオブジェクトのリクエストを受け取るときに以下が行われます。

1. ビューワーが HTTPS リクエストを CloudFront に送信します。ここで、ビューワーと CloudFront 間で何らかの SSL/TLS ネゴシエーションが実行されます。最終的に、ビューワーはリクエストを暗号化形式で送信します。

1. CloudFront のエッジロケーションにキャッシュされたレスポンスがある場合、CloudFront はレスポンスを暗号化してビューワーに返し、ビューワーがそれを復号化します。

1. CloudFront のエッジロケーションにキャッシュされたレスポンスがない場合、CloudFront はオリジンとの SSL/TLS ネゴシエーションを実行し、ネゴシエーションが完了すると、暗号化された形式でリクエストをオリジンに転送します。

1. オリジンは、リクエストを復号化して処理し (レスポンスを生成)、レスポンスを暗号化してから、そのレスポンスを CloudFront に返します。

1. CloudFront はレスポンスを復号化してから再度暗号化し、それをビューワーに転送します。また、CloudFront はエッジロケーションにレスポンスをキャッシュして、次回リクエストされたときに使用できるようにします。

1. ビューワーは応答の暗号化を解除します。

オリジンが Amazon S3 バケット、MediaStore、または HTTP/S サーバーなどのカスタムオリジンのどちらであるかに関係なく、プロセスは基本的に同じように機能します。

**注記**  
SSL の再ネゴシエーション型攻撃を阻止するために、CloudFront はビューワーリクエストとオリジンリクエストの再ネゴシエーションをサポートしていません。

CloudFront ディストリビューションの相互認証を有効にすることもできます。詳細については、「[CloudFront による相互 TLS 認証 (Viewer mTLS)オリジンの相互 TLS と CloudFront](mtls-authentication.md)」を参照してください。

ビューワーと CloudFront との間、また CloudFront とオリジンとの間で HTTPS を要求する方法については、次のトピックを参照してください。

**Topics**
+ [ビューワーと CloudFront の間に HTTPS を要求する](using-https-viewers-to-cloudfront.md)
+ [カスタムオリジンに HTTPS を要求する](using-https-cloudfront-to-custom-origin.md)
+ [Amazon S3 オリジンに HTTPS を要求する](using-https-cloudfront-to-s3-origin.md)
+ [ビューワーと CloudFront との間でサポートされているプロトコルと暗号](secure-connections-supported-viewer-protocols-ciphers.md)
+ [CloudFront とオリジンとの間でサポートされているプロトコルと暗号](secure-connections-supported-ciphers-cloudfront-to-origin.md)

# ビューワーと CloudFront の間の通信に HTTPS を要求する
<a name="using-https-viewers-to-cloudfront"></a>

CloudFront ディストリビューション内で 1 つ以上のキャッシュ動作を設定して、ビューワーと CloudFront との通信で HTTPS を必須にできます。また、1 つ以上のキャッシュ動作で HTTP と HTTPS の両方を許可するように設定して、CloudFront における一部のオブジェクトで HTTPS を必須にすることもできます。設定手順はオブジェクト URL 内で使用しているドメイン名によって異なります。
+ CloudFront がディストリビューションに割り当てたドメイン名を使用している場合 (d111111abcdef8.cloudfront.net など)、1 つ以上のキャッシュ動作の [**ビューワープロトコルポリシー**] 設定を変更して、HTTPS 通信を必須にします。この設定で、CloudFront は SSL/TLS 証明書を提供します。

  CloudFront コンソールを使用して [**ビューワープロトコルポリシー**] の値を変更するには、このセクションで後述する手順を参照してください。

  CloudFront API を使用して `ViewerProtocolPolicy` 要素の値を変更する方法については、*Amazon CloudFront API リファレンス*の「[UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)」を参照してください。
+ 独自のドメイン名 (example.com など) を使用している場合、CloudFront のいくつかの設定を変更する必要があります。また、AWS Certificate Manager (ACM) が提供する SSL/TLS 証明書を使用するか、サードパーティー認証機関からの証明書を ACM または IAM 証明書ストアにインポートする必要があります。詳細については、「[代替ドメイン名と HTTPS を使用する](using-https-alternate-domain-names.md)」を参照してください。

**注記**  
ビューワーが CloudFront から取得するオブジェクトに関して、CloudFront がそのオブジェクトをオリジンから取得した段階で暗号化されていることを保証するには、CloudFront とオリジンとの間で必ず HTTPS を使用します。最近になって CloudFront とオリジンとの間で HTTP から HTTPS に変更した場合、CloudFront エッジロケーションのオブジェクトを無効にすることをお勧めします。CloudFront は、ビューワーが使用しているプロトコル (HTTP または HTTPS) について、CloudFront がオブジェクトを取得するのに使用したプロトコルと一致するかどうかに関係なく、オブジェクトをビューワーに返します。ディストリビューション内のオブジェクトの削除または置き換えの詳細については、「[CloudFront が配信するコンテンツを追加、削除、または置き換える](AddRemoveReplaceObjects.md)」を参照してください。

## ビューワーに HTTPS を要求する
<a name="configure-cloudfront-HTTPS-viewers"></a>

1 つ以上のキャッシュ動作でビューワーと CloudFront との間で HTTPS を必須にするには、次の手順を実行します。<a name="using-https-viewers-to-cloudfront-procedure"></a>

**ビューワーと CloudFront の間で HTTPS が必須になるよう CloudFront を設定するには**

1. AWS マネジメントコンソール にサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. CloudFront コンソールの上部のペインで、更新するディストリビューションの ID を選択します。

1. **[動作]** タブで、更新するキャッシュ動作を選択し、**[編集]** を選択します。

1. **[ビューワープロトコルポリシー]** で、次のいずれかの値を指定します。  
**Redirect HTTP to HTTPS**  
ビューワーは両方のプロトコルを使用できます。HTTP `GET` および `HEAD` リクエストは自動的に HTTPS リクエストにリダイレクトされます。CloudFront は新しい HTTPS URL とともに HTTP ステータスコード 301 (Moved Permanently) を返します。ビューワーはこの HTTPS URL を使用して CloudFront にリクエストを再送信します。  
`POST`、`PUT`、`DELETE`、`OPTIONS`、`PATCH` を HTTP 経由で HTTP から HTTPS キャッシュ動作にして HTTP 1.1 以降のリクエストプロトコルバージョンで送信すると、CloudFront はそのリクエストを HTTP ステータスコード 307 (Temporary Redirect) で HTTPS の場所にリダイレクトします。これはリクエストが同じメソッドと本文ペイロードを使用して新しい場所に再度送信されることを保証するものです。  
`POST`、`PUT`、`DELETE`、`OPTIONS`、`PATCH` のリクエストを HTTP 経由で HTTPS キャッシュ動作に HTTP 1.1 以前のリクエストプロトコルバージョンで送信すると、CloudFront は HTTP ステータスコード 403 (Forbidden) を返します。
ビューワーが作成した HTTP リクエストが HTTPS リクエストにリダイレクトされた場合、CloudFront では両方のリクエストに対する課金が発生します。HTTP リクエストの場合は、リクエストの料金と、CloudFront がビューワーに返すヘッダーの料金のみが課金されます。HTTPS リクエストの場合、リクエストの料金と、オリジンが返すヘッダーとオブジェクトの料金が課金されます。  
**HTTPS のみ**  
ビューワーは、HTTPS を使用している場合にのみ、コンテンツにアクセスできます。ビューワーが HTTPS リクエストではなく HTTP リクエストを送信した場合、CloudFront は HTTP ステータスコード 403 (Forbidden) を返し、オブジェクトは返しません。

1. **[Save changes]** (変更の保存) をクリックします。

1. ビューワーと CloudFront との間で HTTPS を必須にする追加のキャッシュ動作ごとに、ステップ 3 から 5 を繰り返します。

1. 本番環境で更新された情報を使用する前に、次を確認してください。
   + ビューワーに HTTPS の使用が必要とされるリクエストにのみ、各キャッシュ動作のパスパターンが適用されている。
   + CloudFront が評価する順番にキャッシュ動作がリストされている。詳細については、「[パスパターン](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern)」を参照してください。
   + キャッシュ動作は、リクエストを正しいオリジンにルーティングします。

# CloudFront とカスタムオリジンの間の通信に HTTPS を要求する
<a name="using-https-cloudfront-to-custom-origin"></a>

CloudFront とカスタムオリジン間の通信で HTTPS を必須にすることができます。

**注記**  
オリジンがウェブサイトエンドポイントとして設定されている Amazon S3 バケットである場合、Amazon S3 がウェブサイトエンドポイントに対して HTTPS をサポートしていないため、オリジンに HTTPS を使用するように CloudFront を設定することはできません。

CloudFront とオリジン間で HTTPS を必須にするには、このトピックの手順に従って次を実行します。

1. ディストリビューションで、[**Origin Protocol Policy**] (オリジンプロトコルポリシー) 設定を変更します。

1. オリジンサーバーに SSL/TLS 証明書をインストールします (Amazon S3 オリジン、または特定のその他の AWS オリジンを使用する場合は必要ありません)。

**Topics**
+ [カスタムオリジンに HTTPS を要求する](#using-https-cloudfront-to-origin-distribution-setting)
+ [カスタムオリジンに SSL/TLS 証明書をインストールする](#using-https-cloudfront-to-origin-certificate)

## カスタムオリジンに HTTPS を要求する
<a name="using-https-cloudfront-to-origin-distribution-setting"></a>

次の手順では、Elastic Load Balancing ロードバランサー、Amazon EC2 インスタンス、または別のカスタムオリジンとの通信で HTTPS を使用するよう CloudFront を設定する方法について説明します。CloudFront API を使用してディストリビューションを更新する方法については、*Amazon CloudFront API リファレンス*の「[UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)」を参照してください。<a name="using-https-cloudfront-to-custom-origin-procedure"></a>

**CloudFront とカスタムオリジンの間で HTTPS を必須にするよう CloudFront を設定するには**

1. AWS マネジメントコンソール にサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. CloudFront コンソールの上部のペインで、更新するディストリビューションの ID を選択します。

1. **[動作]**] タブで、更新するオリジンを選択し、**[編集]** を選択します。

1. 次の設定を更新します。  
**オリジンプロトコルポリシー**  
ディストリビューションの該当するオリジンで、[**Origin Protocol Policy**] を変更します。  
   + [**HTTPS Only (HTTPS のみ)**] - CloudFront は HTTPS のみを使ってカスタムオリジンと通信します。
   + [**Match Viewer (ビューワーに合わせる)**] - CloudFront は、ビューワーのリクエストのプロトコルに応じて HTTP または HTTPS を使用し、カスタムオリジンと通信します。例えば、[**オリジンプロトコルポリシー**] の [**Match Viewer (ビューワーに合わせる)**] を選択し、ビューワーで HTTPS を使用して CloudFront からオブジェクトをリクエストする場合は、CloudFront でも HTTPS を使用してリクエストをオリジンに転送します。

     [**Viewer Protocol Policy**] で [**Redirect HTTP to HTTPS**] または [**HTTPS Only**] を指定する場合は、[**Match Viewer**] のみを選択します。

     ビューワーが HTTP と HTTPS の両方のプロトコルを使用してリクエストを行った場合も、CloudFront がオブジェクトをキャッシュするのは 1 回だけです。  
**オリジン SSL プロトコル**  
ディストリビューションの該当するオリジンで [**Origin SSL Protocols**] を選択します。SSLv3 プロトコルは安全性が低いため、オリジンが TLSv1 以降をサポートしていない場合にのみ SSLv3 を選択することをお勧めします。TLSv1 ハンドシェイクは、SSLv3 との下位互換性と上位互換性の両方がありますが、TLSv1.1 以降は対象外です。SSLv3 を選択すると、CloudFront は SSLv3 ハンドシェイクリクエスト*のみ*を送信します。

1. **[Save changes]** (変更の保存) をクリックします。

1. CloudFront とカスタムオリジンとの間で HTTPS を必須にする追加のオリジンごとに、ステップ 3 から 5 を繰り返します。

1. 本番環境で更新された情報を使用する前に、次を確認してください。
   + ビューワーに HTTPS の使用が必要とされるリクエストにのみ、各キャッシュ動作のパスパターンが適用されている。
   + CloudFront が評価する順番にキャッシュ動作がリストされている。詳細については、「[パスパターン](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern)」を参照してください。
   + キャッシュ動作は、[**Origin Protocol Policy**] を変更したオリジンにリクエストをルーティングします。

## カスタムオリジンに SSL/TLS 証明書をインストールする
<a name="using-https-cloudfront-to-origin-certificate"></a>

SSL/TLS 証明書は、カスタムオリジンの次のソースから使用できます。
+ オリジンが Elastic Load Balancing ロードバランサーである場合は、AWS Certificate Manager (ACM) が提供する証明書を使用できます。信頼されたサードパーティー認証機関が署名して ACM にインポートされた証明書を使用することもできます。
+ Elastic Load Balancing ロードバランサー以外のオリジンの場合、信頼されたサードパーティー認証機関 (CA) (Comodo、DigiCert、Symantec など) によって署名された証明書を使用する必要があります。

オリジンから返される証明書には、次のいずれかのドメイン名が含まれている必要があります。
+ オリジンの**オリジンドメイン**フィールド (CloudFront API の `DomainName` フィールド) のドメイン名。
+ キャッシュ動作が `Host` ヘッダーをオリジンに転送するように設定されている場合は、`Host` ヘッダーのドメイン名。

CloudFront が HTTPS を使用してオリジンと通信するとき、CloudFront は証明書が信頼された認証機関によって発行されたものであることを確認します。CloudFront は Mozilla と同じ認証機関をサポートしています。最新のリストは、「[Mozilla に付属する CA 証明書一覧](https://wiki.mozilla.org/CA/Included_Certificates)」を参照してください。CloudFront とオリジンとの間の HTTPS 通信に自己署名証明書を使用することはできません。

**重要**  
失効した証明書、無効な証明書、または自己署名証明書をオリジンサーバーが返したり、間違った順番の証明書チェーンを返したりした場合、CloudFront は TCP 接続を中断し、HTTP ステータスコード 502 (Bad Gateway) を返して、`X-Cache` ヘッダーを `Error from cloudfront` に設定します。中間証明書を含む、証明書チェーンが完全でない場合も、CloudFront は TCP 接続を中断します。

# CloudFront と Amazon S3 オリジンの間の通信に HTTPS を要求する
<a name="using-https-cloudfront-to-s3-origin"></a>

オリジンが Amazon S3 バケットの場合、CloudFront との通信に HTTPS を使用するためのオプションは、バケットの使用方法によって異なります。Amazon S3 バケットがウェブサイトエンドポイントとして設定されている場合、オリジンとの通信に HTTPS を使用するように CloudFront を設定することはできません。Amazon S3 はその設定で HTTPS 接続をサポートしていないためです。

オリジンが HTTPS 通信をサポートする Amazon S3 バケットの場合、CloudFront はビューワーがリクエストを送信するのに使ったプロトコルを使用して S3 にリクエストを転送します。[プロトコル (カスタムオリジンのみ)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy) 設定のデフォルト設定は [**Match Viewer (ビューワーに合わせる)**] で、変更できません。ただし、Amazon S3 オリジンのオリジンアクセスコントロール (OAC) を有効にすると、CloudFront と Amazon S3 間で使用される通信は設定によって異なります。詳細については、「[新しいオリジンアクセスコントロールを作成する](private-content-restricting-access-to-s3.md#create-oac-overview-s3)」を参照してください。

CloudFront と Amazon S3 との間の通信で HTTPS を必須にする場合、[**ビューワープロトコルポリシー**] の値を [**Redirect HTTP to HTTPS (HTTP から HTTPS へのリダイレクト)**] または [**HTTPS Only (HTTPS のみ)**] に変更する必要があります。このセクションで後述する手順では、CloudFront コンソールを使用して [**ビューワープロトコルポリシー**] を変更する方法について説明します。CloudFront API を使用してディストリビューションの `ViewerProtocolPolicy` 要素を更新する方法については、*Amazon CloudFront API リファレンス*の「[UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)」を参照してください。

HTTPS 通信をサポートする Amazon S3 バケットで HTTPS を使用する場合、Amazon S3 では SSL/TLS 証明書を使用できるため、この通信を使用する必要はありません。

## Amazon S3 オリジンに HTTPS を要求する
<a name="configure-cloudfront-HTTPS-S3-origin"></a>

次の手順は、Amazon S3 オリジンに HTTPS を要求するように CloudFront を設定する方法を示しています。<a name="using-https-cloudfront-to-s3-origin-procedure"></a>

**Amazon S3 オリジン接続時の HTTPS を必須にするよう CloudFront を設定するには**

1. AWS マネジメントコンソール にサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. CloudFront コンソールの上部のペインで、更新するディストリビューションの ID を選択します。

1. [**Behaviors**] タブで、更新するキャッシュ動作を選択した後、[**Edit**] を選択します。

1. [**Viewer Protocol Policy**] として次のいずれかの値を指定します。  
**Redirect HTTP to HTTPS**  
ビューワーは両方のプロトコルを使用できますが、HTTP リクエストは自動的に HTTPS リクエストにリダイレクトされます。CloudFront は新しい HTTPS URL とともに HTTP ステータスコード 301 (Moved Permanently) を返します。ビューワーはこの HTTPS URL を使用して CloudFront にリクエストを再送信します。  
CloudFront は、HTTP から HTTPS に `DELETE`、`OPTIONS`、`PATCH`、`POST`、または `PUT` リクエストをリダイレクトしません。HTTPS にリダイレクトするようにキャッシュ動作を設定した場合、CloudFront は HTTP ステータスコード 403 (Forbidden) を使用してそのキャッシュ動作の HTTP `DELETE`、`OPTIONS`、`PATCH`、`POST`、または `PUT` リクエストに応答します。
ビューワーが作成した HTTP リクエストが HTTPS リクエストにリダイレクトされた場合、CloudFront では両方のリクエストに対する課金が発生します。HTTP リクエストの場合は、リクエストの料金と、CloudFront がビューワーに返すヘッダーの料金のみが課金されます。HTTPS リクエストの場合、リクエストの料金と、オリジンが返すヘッダーとオブジェクトの料金が課金されます。  
**HTTPS Only**  
ビューワーは、HTTPS を使用している場合にのみ、コンテンツにアクセスできます。ビューワーが HTTPS リクエストではなく HTTP リクエストを送信した場合、CloudFront は HTTP ステータスコード 403 (Forbidden) を返し、オブジェクトは返しません。

1. [**Yes, Edit (はい、編集します)**] を選択します。

1. ビューワーと CloudFront、および CloudFront と S3 との間で HTTPS を必須にする追加のキャッシュ動作ごとに、ステップ 3 から 5 を繰り返します。

1. 本番環境で更新された情報を使用する前に、次を確認してください。
   + ビューワーに HTTPS の使用が必要とされるリクエストにのみ、各キャッシュ動作のパスパターンが適用されている。
   + CloudFront が評価する順番にキャッシュ動作がリストされている。詳細については、「[パスパターン](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern)」を参照してください。
   + キャッシュ動作は、リクエストを正しいオリジンにルーティングします。

# ビューワーと CloudFront との間でサポートされているプロトコルと暗号
<a name="secure-connections-supported-viewer-protocols-ciphers"></a>

[ビューワーと CloudFront ディストリビューションとの間で HTTPS が必要](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy)である場合は、[セキュリティポリシー](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy)を選択する必要があります。これにより、次の設定が決定されます。
+ CloudFront でビューワーとの通信に使用する最小の SSL/TLS プロトコル。
+ ビューワーとの通信を暗号化するために CloudFront が使用できる暗号。

セキュリティポリシーを選択するには、[セキュリティポリシー (SSL/TLS の最小バージョン）](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy) に該当する値を指定します。以下の表は、各セキュリティポリシーで CloudFront が使用できるプロトコルと暗号化方式の一覧です。

ビューワーは、CloudFront との HTTPS 接続を確立するために、これらの暗号のうち少なくとも 1 つをサポートする必要があります。CloudFront は、ビューワーがサポートする暗号化方式から一覧順で暗号化方式を選択します。「[OpenSSL、s2n、および RFC の暗号名](#secure-connections-openssl-rfc-cipher-names)」も参照してください。


|  | セキュリティポリシー |  | SSLv3 | TLSv1 | TLSv1\$12016 | TLSv1.1\$12016 | TLSv1.2\$12018 | TLSv1.2\$12019 | TLSv1.2\$12021 | TLSv1.2\$12025 | TLSv1.3\$12025 | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | 
| サポートされている SSL/TLS プロトコル | 
| TLSv1.3 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLSv1.2 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| TLSv1.1 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| TLSv1 | ♦ | ♦ | ♦ |  |  |  |  |  |  | 
| SSLv3 | ♦ |  |  |  |  |  |  |  |  | 
| サポートされている TLSv1.3 暗号 | 
| TLS\$1AES\$1128\$1GCM\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1AES\$1256\$1GCM\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1CHACHA20\$1POLY1305\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | ♦ | 
| サポートされる ECDSA 暗号 | 
| ECDHE-ECDSA-AES128- GCM-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-ECDSA-AES128-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-ECDSA-AES128-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| ECDHE-ECDSA-AES256- GCM-SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-ECDSA-CHACHA20-POLY1305 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| ECDHE-ECDSA-AES256-SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-ECDSA-AES256-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| サポートされる RSA 暗号 | 
| ECDHE-RSA-AES128- GCM-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-RSA-AES128-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-RSA-AES128-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| ECDHE-RSA-AES256- GCM-SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-RSA-CHACHA20-POLY1305 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| ECDHE-RSA-AES256-SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-RSA-AES256-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| AES128-GCM-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  |  | 
| AES256-GCM-SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  |  | 
| AES128-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  |  | 
| AES256-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| AES128-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| DES-CBC3-SHA | ♦ | ♦ |  |  |  |  |  |  |  | 
| RC4-MD5 | ♦ |  |  |  |  |  |  |  |  | 

## OpenSSL、s2n、および RFC の暗号名
<a name="secure-connections-openssl-rfc-cipher-names"></a>

OpenSSL と [s2n](https://github.com/awslabs/s2n) では、TLS 標準で使用されている暗号名 ([RFC 2246](https://tools.ietf.org/html/rfc2246)、[RFC 4346](https://tools.ietf.org/html/rfc4346)、[RFC 5246](https://tools.ietf.org/html/rfc5246)、 [RFC 8446](https://tools.ietf.org/html/rfc8446)) とは異なる暗号名が使用されます。以下の表では、各暗号化方式の OpenSSL 名と s2n 名から RFC 名までを示しています。

CloudFront は、従来の鍵交換と量子安全鍵交換の両方をサポートしています。楕円曲線を使用する従来の鍵交換の場合、CloudFront は以下をサポートしています。
+ `prime256v1`
+ `X25519`
+ `secp384r1`

量子安全鍵交換の場合、CloudFront は以下のものをサポートしています。
+ `X25519MLKEM768`
+ `SecP256r1MLKEM768`
**注記**  
量子安全鍵交換は TLS 1.3 でのみサポートされています。TLS 1.2 以前のバージョンでは、量子安全鍵交換はサポートされていません。

  詳細については、以下の各トピックを参照してください。
  + [ポスト量子暗号化](https://aws.amazon.com/security/post-quantum-cryptography/)
  + [Cryptography algorithms and AWS のサービス](https://docs.aws.amazon.com/prescriptive-guidance/latest/encryption-best-practices/aws-cryptography-services.html#algorithms)
  + [Hybrid key exchange in TLS 1.3](https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/)

CloudFront の証明書要件の詳細については、「[CloudFront で SSL/TLS 証明書を使用するための要件](cnames-and-https-requirements.md)」を参照してください。


| OpenSSL および s2n の暗号名 | RFC の暗号名 | 
| --- | --- | 
| サポートされている TLSv1.3 暗号 | 
| TLS\$1AES\$1128\$1GCM\$1SHA256 | TLS\$1AES\$1128\$1GCM\$1SHA256 | 
| TLS\$1AES\$1256\$1GCM\$1SHA384 | TLS\$1AES\$1256\$1GCM\$1SHA384 | 
| TLS\$1CHACHA20\$1POLY1305\$1SHA256 | TLS\$1CHACHA20\$1POLY1305\$1SHA256 | 
| サポートされる ECDSA 暗号 | 
| ECDHE-ECDSA-AES128- GCM-SHA256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1GCM\$1SHA256 | 
| ECDHE-ECDSA-AES128-SHA256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 | 
| ECDHE-ECDSA-AES128-SHA | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| ECDHE-ECDSA-AES256- GCM-SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 | 
| ECDHE-ECDSA-CHACHA20-POLY1305 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1CHACHA20\$1POLY1305\$1SHA256 | 
| ECDHE-ECDSA-AES256-SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 | 
| ECDHE-ECDSA-AES256-SHA | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| サポートされる RSA 暗号 | 
| ECDHE-RSA-AES128- GCM-SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1SHA256 | 
| ECDHE-RSA-AES128-SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256  | 
| ECDHE-RSA-AES128-SHA | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| ECDHE-RSA-AES256- GCM-SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384  | 
| ECDHE-RSA-CHACHA20-POLY1305 | TLS\$1ECDHE\$1RSA\$1WITH\$1CHACHA20\$1POLY1305\$1SHA256 | 
| ECDHE-RSA-AES256-SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384  | 
| ECDHE-RSA-AES256-SHA | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| AES128-GCM-SHA256 | TLS\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1SHA256 | 
| AES256-GCM-SHA384 | TLS\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 | 
| AES128-SHA256 | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 | 
| AES256-SHA | TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| AES128-SHA | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| DES-CBC3-SHA  | TLS\$1RSA\$1WITH\$13DES\$1EDE\$1CBC\$1SHA  | 
| RC4-MD5 | TLS\$1RSA\$1WITH\$1RC4\$1128\$1MD5 | 

## ビューワーと CloudFront 間でサポートされている署名スキーム
<a name="secure-connections-viewer-signature-schemes"></a>

CloudFront では、ビューワーと CloudFront 間の接続について、次の署名スキームがサポートされています。


|  | セキュリティポリシー | 署名スキーム | SSLv3 | TLSv1 | TLSv1\$12016 | TLSv1.1\$12016 | TLSv1.2\$12018 | TLSv1.2\$12019 |  TLSv1.2\$12021 | TLSv1.2\$12025 | TLSv1.3\$12025 | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA224 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA224 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SECP256R1\$1SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SECP384R1\$1SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA1 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA1 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 

# CloudFront とオリジンとの間でサポートされているプロトコルと暗号
<a name="secure-connections-supported-ciphers-cloudfront-to-origin"></a>

[[CloudFront とオリジンとの間で HTTPS を必須にする](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesOriginProtocolPolicy)] を選択する場合、安全な接続に[どの SSL/TLS プロトコルを許可するか](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesOriginSSLProtocols)を決定し、次の表に示す ECDSA あるいは RSA 暗号のいずれかを使用して CloudFront からオリジンに接続できます。CloudFront がオリジンに対する HTTPS 接続を確立するには、オリジンがこれらの暗号のうち少なくとも 1 つをサポートしている必要があります。

OpenSSL と [s2n](https://github.com/awslabs/s2n) では、TLS 標準で使用されている暗号名 ([RFC 2246](https://tools.ietf.org/html/rfc2246)、[RFC 4346](https://tools.ietf.org/html/rfc4346)、[RFC 5246](https://tools.ietf.org/html/rfc5246)、 [RFC 8446](https://tools.ietf.org/html/rfc8446)) とは異なる暗号名が使用されます。次の表には、各暗号化方式の OpenSSL 名、s2n 名、および RFC 名などが示されています。

楕円曲線キー交換アルゴリズムを使用する暗号の場合、CloudFront は以下の楕円曲線をサポートします。
+ prime256v1
+ secp384r1
+ X25519


| OpenSSL および s2n の暗号名 | RFC の暗号名 | 
| --- | --- | 
| サポートされる ECDSA 暗号 | 
| ECDHE-ECDSA-AES256- GCM-SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 | 
| ECDHE-ECDSA-AES256-SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 | 
| ECDHE-ECDSA-AES256-SHA | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| ECDHE-ECDSA-AES128- GCM-SHA256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1GCM\$1SHA256 | 
| ECDHE-ECDSA-AES128-SHA256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 | 
| ECDHE-ECDSA-AES128-SHA | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| サポートされる RSA 暗号 | 
| ECDHE-RSA-AES256- GCM-SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1SHA384 | 
| ECDHE-RSA-AES256-SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA384 | 
| ECDHE-RSA-AES256-SHA | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| ECDHE-RSA-AES128- GCM-SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1SHA256 | 
| ECDHE-RSA-AES128-SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA256 | 
| ECDHE-RSA-AES128-SHA | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| AES256-SHA | TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| AES128-SHA | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| DES-CBC3-SHA | TLS\$1RSA\$1WITH\$13DES\$1EDE\$1CBC\$1SHA | 
| RC4-MD5 | TLS\$1RSA\$1WITH\$1RC4\$1128\$1MD5 | 

**CloudFront とオリジン間でサポートされている署名スキーム**

CloudFront では、CloudFront とオリジン間の接続について、次の署名スキームがサポートされています。
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA256
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA384
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA512
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA224
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA256
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA384
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA512
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA224
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PKCS1\$1SHA1
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1SHA1

# 代替ドメイン名と HTTPS を使用する
<a name="using-https-alternate-domain-names"></a>

ファイルの URL で独自ドメイン名を使用する場合 (例: `https://www.example.com/image.jpg`)、およびビューワーが HTTPS を使用する場合、次のトピックのステップを完了する必要があります。(URL でデフォルトの CloudFront ディストリビューションのドメイン名、たとえば `https://d111111abcdef8.cloudfront.net/image.jpg` を使用する場合は、代わりに「[ビューワーと CloudFront の間の通信に HTTPS を要求する](using-https-viewers-to-cloudfront.md)」のガイダンスに従います)。

**重要**  
証明書をディストリビューションに追加すると、CloudFront によりすべてのエッジロケーションに証明書が直ちに伝達されます。新しいエッジロケーションが使用可能になると、CloudFront は証明書をそのロケーションにも伝達します。CloudFront から証明書がどのエッジロケーションに伝達されるかを制限することはできません。

**Topics**
+ [CloudFront で HTTPS リクエストを処理する方法を選択する](cnames-https-dedicated-ip-or-sni.md)
+ [CloudFront で SSL/TLS 証明書を使用するための要件](cnames-and-https-requirements.md)
+ [CloudFront で SSL/TLS 証明書を使用する場合のクォータ (ビューワーと CloudFront との間の HTTPS のみ)](cnames-and-https-limits.md)
+ [代替ドメイン名と HTTPS を設定する](cnames-and-https-procedures.md)
+ [SSL/TLS RSA 証明書内のパブリックキーのサイズを確認する](cnames-and-https-size-of-public-key.md)
+ [SSL/TLS 証明書のクォータを引き上げる](increasing-the-limit-for-ssl-tls-certificates.md)
+ [SSL/TLS 証明書をローテーションする](cnames-and-https-rotate-certificates.md)
+ [カスタム SSL/TLS 証明書からデフォルト CloudFront 証明書に戻す](cnames-and-https-revert-to-cf-certificate.md)
+ [専用 IP アドレスを使用するカスタム SSL/TLS 証明書を SNI に切り替える](cnames-and-https-switch-dedicated-to-sni.md)

# CloudFront で HTTPS リクエストを処理する方法を選択する
<a name="cnames-https-dedicated-ip-or-sni"></a>

ビューワーに HTTPS とファイルの代替ドメイン名を使用させる場合、CloudFront サーバーが HTTPS リクエストを処理する方法に関する次のいずれかのオプションを選択する必要があります。
+ [Server Name Indication (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication) を使用する - 推奨
+ 各エッジロケーションの専用 IP アドレスを使用する

このセクションでは各オプションの仕組みについて説明します。

## SNI を使用して HTTPS リクエストを処理する (ほとんどのクライアントで有効)
<a name="cnames-https-sni"></a>

[Server Name Indication (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication) は、2010 年以降にリリースされたブラウザとクライアントでサポートされている TLS プロトコルを拡張したものです。SNI を使用して HTTPS リクエストに対応するように CloudFront を設定した場合、CloudFront は代替ドメイン名を各エッジロケーションの IP アドレスと関連付けます。ビューワーがコンテンツに対して HTTPS リクエストを送信すると、DNS は、正しいエッジロケーションの IP アドレスにリクエストをルーティングします。ドメイン名の IP アドレスが SSL/TLS ハンドシェイクネゴシエーション中に決定されます。IP アドレスはディストリビューション専用にはなりません。

SSL/TLS ネゴシエーションは、HTTPS 接続を確立する処理の早い段階で実行されます。リクエストがどのドメイン向けかをすぐに決定できない場合、CloudFront は接続を中断します。SNI をサポートするビューワーがコンテンツに対して HTTPS リクエストを送信すると、次のようになります。

1. ビューワーはリクエスト URL からドメイン名を自動的に取得し、TLS クライアントの hello メッセージの SNI 拡張に追加します。

1. CloudFront は、TLS クライアント hello を受け取ると、SNI 拡張のドメイン名を使用して、一致する CloudFront ディストリビューションを検索し、関連する TLS 証明書を返します。

1. ビューワーと CloudFront は、SSL/TLS ネゴシエーションを実行します。

1. CloudFront はリクエストされたコンテンツをビューワーに返します。

現在 SNI をサポートするブラウザの一覧については、Wikipedia の [Server Name Indication](https://en.wikipedia.org/wiki/Server_Name_Indication) の項目を参照してください。

SNI を使用したくても、ユーザーのブラウザの一部が SNI をサポートしていない場合は、選択肢がいくつかあります。
+ SNI ではなく専用 IP アドレスを使用して HTTPS リクエストを供給するように CloudFront を構成します。詳細については、「[専用 IP アドレスを使用して HTTPS リクエストを処理する (すべてのクライアントで有効)](#cnames-https-dedicated-ip)」を参照してください。
+ カスタム証明書の代わりに CloudFront SSL/TLS 証明書を使用してください。この場合、ファイルの URL でディストリビューションの CloudFront ドメイン名を使用する必要があります (たとえば、`https://d111111abcdef8.cloudfront.net/logo.png`)。

  デフォルトの CloudFront 証明書を使用する場合、ビューワーは SSL プロトコル TLSv1 以降をサポートする必要があります。CloudFront はデフォルトの CloudFront 証明書では SSLv3 をサポートしません。

  また、CloudFront で使用する SSL/TLS 証明書を独自証明書からデフォルトの CloudFront 証明書に変更する必要もあります。
  + ディストリビューションを使用してコンテンツを配信したことがない場合は、単に構成を変更できます。詳細については、「[ディストリビューションを更新する](HowToUpdateDistribution.md)」を参照してください。
  + ディストリビューションを使用してコンテンツを配信していた場合は、新しい CloudFront ディストリビューションを作成し、コンテンツが使用できない時間を減らすかゼロにするために、ファイルの URL を変更する必要があります。詳細については、「[カスタム SSL/TLS 証明書からデフォルト CloudFront 証明書に戻す](cnames-and-https-revert-to-cf-certificate.md)」を参照してください。
+ ユーザーが使用するブラウザを管理できる場合は、SNI をサポートするブラウザにアップグレードしてもらいます。
+ HTTPS の代わりに HTTP を使用します。

## 専用 IP アドレスを使用して HTTPS リクエストを処理する (すべてのクライアントで有効)
<a name="cnames-https-dedicated-ip"></a>

Server Name Indication (SNI) は、リクエストをドメインと関連付ける 1 つの方法です。専用 IP アドレスを使用する方法もあります。2010 年以降にリリースされたブラウザまたはクライアントにアップグレードできないユーザーが存在する場合は、専用 IP アドレスを使用して HTTPS リクエストに対応できます。現在 SNI をサポートするブラウザの一覧については、Wikipedia の [Server Name Indication](https://en.wikipedia.org/wiki/Server_Name_Indication) の項目を参照してください。

**重要**  
専用 IP アドレスを使用して HTTPS リクエストを供給するように CloudFront を構成した場合、追加の月額料金が発生します。課金は、ディストリビューションに SSL/TLS 証明書を関連付けて、ディストリビューションを有効にした時点から開始されます。CloudFront の料金の詳細については、「[Amazon CloudFront の料金](https://aws.amazon.com/cloudfront/pricing)」を参照してください。また、[Using the Same Certificate for Multiple CloudFront Distributions](cnames-and-https-limits.md#cnames-and-https-same-certificate-multiple-distributions) も参照してください。

専用 IP アドレスを使用して HTTPS リクエストに対応するように CloudFront を設定すると、CloudFront は証明書を各 CloudFront エッジロケーションの専用 IP アドレスと関連付けます。ビューワーがコンテンツに HTTPS リクエストを送信すると、次のようになります。

1. DNS は、該当するエッジロケーション内のディストリビューションの IP アドレスにリクエストをルーティングします。

1. クライアントリクエストの `ClientHello` メッセージに SNI 拡張が含まれている場合、CloudFront は、その SNI に関連付けられているディストリビューションを検索します。
   + 一致するものがあれば、CloudFront は SSL/TLS 証明書を使用してリクエストに応答します。
   + 一致するものがない場合、CloudFront は代わりに IP アドレスを使用してディストリビューションを特定し、どの SSL/TLS 証明書をビューワーに返すかを決定します。

1. ビューワーと CloudFront は SSL/TLS 証明書を使って SSL/TLS ネゴシエーションを実行します。

1. CloudFront はリクエストされたコンテンツをビューワーに返します。

この方法は、ユーザーが使用するブラウザやその他のビューワーを問わず、あらゆる HTTPS リクエストで機能します。

**注記**  
専用 IP は静的 IP ではないため、時間の経過とともに変化する可能性があります。エッジロケーションに返される IP アドレスは、[CloudFront エッジサーバーリスト](LocationsOfEdgeServers.md) の IP アドレス範囲から動的に割り当てられます。  
CloudFront エッジサーバーの IP アドレス範囲は、変わる可能性があります。IP アドレスの変更に関する通知を受け取るには、[Amazon SNS 経由で AWS パブリック IP アドレスの変更をサブスクライブ](https://aws.amazon.com/blogs/aws/subscribe-to-aws-public-ip-address-changes-via-amazon-sns/)します。

## 3 つ以上の SSL/TLS 専用 IP 証明書を使用するためのアクセス許可をリクエストする
<a name="cnames-and-https-multiple-certificates"></a>

CloudFront に 3 つ以上の SSL/TLS 専用 IP 証明書を永続的に関連付けるための許可が必要な場合は、以下の手順を実行します。HTTPS リクエストの詳細については、「[CloudFront で HTTPS リクエストを処理する方法を選択する](#cnames-https-dedicated-ip-or-sni)」を参照してください。

**注記**  
CloudFront ディストリビューションに 3 つ以上の専用 IP 証明書を使用するための手順は以下の通りです。デフォルト値は 2 です。ディストリビューションには SSL 証明書を複数バインドできないのでご注意ください。  
CloudFront ディストリビューションに関連付けることができる SSL/TLS 証明書は、一度に 1 つのみです。この数は、すべての CloudFront ディストリビューションで使用できる専用 IP SSL 証明書の合計数です。<a name="cnames-and-https-multiple-certificates-procedure"></a>

**CloudFront ディストリビューションに 3 つ以上の証明書を使用するための許可をリクエストするには**

1. [サポートセンター](https://console.aws.amazon.com/support/home?#/case/create?issueType=service-limit-increase&limitType=service-code-cloudfront-distributions)にアクセスし、サポートケースを作成します。

1. 使用するためのアクセス権限が必要な証明書の数と状況をリクエストに記載してください。できる限り早くアカウントを更新します。

1. 次の手順に進みます。

# CloudFront で SSL/TLS 証明書を使用するための要件
<a name="cnames-and-https-requirements"></a>

このトピックでは、SSL/TLS 証明書の要件について説明します。これらの要件は、特に注記がなければ、以下の両方の証明書に適用されます。
+ ビューワーと CloudFront との間で HTTPS を使用するための証明書 
+ CloudFront とオリジンとの間で HTTPS を使用するための証明書

**Topics**
+ [証明書の発行者](#https-requirements-certificate-issuer)
+ [AWS リージョン 用の AWS Certificate Manager](#https-requirements-aws-region)
+ [証明書の形式](#https-requirements-certificate-format)
+ [中間証明書](#https-requirements-intermediate-certificates)
+ [キーのタイプ](#https-requirements-key-type)
+ [プライベートキー](#https-requirements-private-key)
+ [アクセス許可](#https-requirements-permissions)
+ [証明書キーのサイズ](#https-requirements-size-of-public-key)
+ [サポートされている証明書のタイプ](#https-requirements-supported-types)
+ [証明書の有効期限切れと更新](#https-requirements-cert-expiration)
+ [CloudFront ディストリビューションと証明書のドメイン名](#https-requirements-domain-names-in-cert)
+ [SSL/TLS プロトコルの最小バージョン](#https-requirements-minimum-ssl-protocol-version)
+ [サポートされる HTTP バージョン](#https-requirements-supported-http-versions)

## 証明書の発行者
<a name="https-requirements-certificate-issuer"></a>

[AWS Certificate Manager (ACM)](https://aws.amazon.com/certificate-manager/) 発行のパブリック証明書を仕様することをお勧めします。ACM からの証明書の取得の詳細については、*[AWS Certificate Manager ユーザーガイド](https://docs.aws.amazon.com/acm/latest/userguide/)*を参照してください。CloudFront ディストリビューションで ACM 証明書を使用するには、米国東部 (バージニア北部) リージョン (`us-east-1`) の証明書をリクエスト (またはインポート) していることを確認します。

 CloudFront は Mozilla と同じ認定権限 (CA) をサポートしているため、ACM を使用しない場合は、「[Mozilla に付属する CA 証明書一覧](https://wiki.mozilla.org/CA/Included_Certificates)」の CA が発行する証明書を使用します。

CloudFront ディストリビューションに指定したオリジンによって使用される TLS 証明書も、Mozilla に付属する CA 証明書一覧に含まれる CA から発行されている必要があります。

証明書の取得とインストール方法については、使用している HTTP サーバーソフトウェアのドキュメントおよび CA のドキュメントを参照してください。

## AWS リージョン 用の AWS Certificate Manager
<a name="https-requirements-aws-region"></a>

AWS Certificate Manager (ACM) の証明書を使用して、ビューワーと CloudFront との間で HTTPS を必須にする場合は、米国東部 (バージニア北部) リージョン (`us-east-1`) の証明書をリクエスト (またはインポート) していることを確認します。

CloudFront とオリジンとの間で HTTPS を必須にする場合、オリジンとして Elastic Load Balancing のロードバランサーを使用していれば、任意の AWS リージョン で証明書をリクエストまたはインポートできます。

## 証明書の形式
<a name="https-requirements-certificate-format"></a>

公開証明書は X.509 PEM 形式で作成されている必要があります。これは、AWS Certificate Manager を使用する場合のデフォルトの形式です。

## 中間証明書
<a name="https-requirements-intermediate-certificates"></a>

サードパーティー認定権限 (CA) を使用している場合、`.pem` ファイルには、ドメインの証明書の署名者である CA の証明書から始めて、証明書チェーン内のすべての中間証明書を含めます。通常は、適切なチェーン順で中間証明書とルート証明書を並べたファイルが CA のウェブサイトに用意されています。

**重要**  
ルート証明書、信頼パス内に存在しない中間証明書、CA の公開キー証明書は含めないでください。

例を示します。

```
-----BEGIN CERTIFICATE-----
Intermediate certificate 2
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Intermediate certificate 1
-----END CERTIFICATE-----
```

## キーのタイプ
<a name="https-requirements-key-type"></a>

CloudFront は RSA および ECDSA パブリック (公開) とプライベートのキーペアをサポートします。

CloudFront は、RSA 証明書と ECDSA 証明書を使用して、ビューワーとオリジンの両方への HTTPS 接続をサポートします。[AWS Certificate Manager (ACM)](https://console.aws.amazon.com/acm) では、RSA または ECDSA 証明書をリクエストしてインポートし、CloudFront ディストリビューションに関連付けることができます。

HTTPS 接続でネゴシエートできる CloudFront でサポートされている RSA および ECDSA 暗号のリストについては、「[ビューワーと CloudFront との間でサポートされているプロトコルと暗号](secure-connections-supported-viewer-protocols-ciphers.md)」および「[CloudFront とオリジンとの間でサポートされているプロトコルと暗号](secure-connections-supported-ciphers-cloudfront-to-origin.md)」を参照してください。

## プライベートキー
<a name="https-requirements-private-key"></a>

サードパーティー認証機関 (CA) の証明書を使用している場合、以下の点に注意してください。
+ プライベートキーが証明書のパブリックキーと一致している。
+ プライベートキーは、PEM 形式でなければなりません。
+ プライベートキーはパスワードで暗号化できません。

AWS Certificate Manager (ACM) が証明書を提供した場合、ACM はプライベートキーをリリースしません。プライベートキーは、ACM に統合された AWS のサービスによる使用のために、ACM に保存されます。

## アクセス許可
<a name="https-requirements-permissions"></a>

SSL/TLS 証明書を使用およびインポートするアクセス許可が必要です。AWS Certificate Manager (ACM) を使用している場合は、AWS Identity and Access Management アクセス許可を使用して証明書へのアクセスを制限することをお勧めします。詳細については、『*AWS Certificate Manager ユーザーガイド*』の「[Identity and Access Management](https://docs.aws.amazon.com/acm/latest/userguide/security-iam.html)」を参照してください。

## 証明書キーのサイズ
<a name="https-requirements-size-of-public-key"></a>

CloudFront がサポートする証明書キーのサイズは、キーと証明書の種類によって異なります。

**RSA 証明書の場合: **  
CloudFront は、1024 ビット、2048 ビット、3072 ビット、4096 ビットの RSA キーをサポートしています。CloudFront で使用できる RSA 証明書のキーの長さは最大 4096 ビットです。  
 ACM が発行する RSA 証明書のキーの最大長は 2048 ビットであることに注意してください。3072 ビットまたは 4096 ビットの RSA 証明書を使用するには、証明書を外部から取得して ACM にインポートする必要があります。これにより、CloudFront で使用できるようになります。  
RSA キーのサイズを確認する方法については、「[SSL/TLS RSA 証明書内のパブリックキーのサイズを確認する](cnames-and-https-size-of-public-key.md)」を参照してください。

**ECDSA 証明書の場合: **  
CloudFront は、256 ビットキーをサポートしています。ACM の ECDSA 証明書を使用して、ビューワーと CloudFront との間で HTTPS を必須にするには、prime256v1 楕円曲線を使用します。

## サポートされている証明書のタイプ
<a name="https-requirements-supported-types"></a>

CloudFront は、信頼された認証機関によって発行されたすべてのタイプの証明書をサポートしています。

## 証明書の有効期限切れと更新
<a name="https-requirements-cert-expiration"></a>

サードパーティー認定権限 (CA) から取得した証明書を使用する場合、証明書の有効期限切れをモニタリングし、AWS Certificate Manager (ACM) にインポートする、または AWS Identity and Access Management 証明書ストアにアップロードする証明書を有効期限前に更新する必要があります。

**重要**  
証明書の有効期限の問題を回避するには、現在の証明書の `NotAfter` 値の少なくとも 24 時間前に証明書を更新または再インポートします。証明書の有効期限が 24 時間以内に切れる場合は、ACM に新しい証明書をリクエストするか、新しい証明書を ACM にインポートします。次に、新しい証明書を CloudFront ディストリビューションに関連付けます。  
CloudFront は、証明書の更新または再インポートの進行中に、以前の証明書を引き続き使用する場合があります。これは非同期プロセスであり、CloudFront に変更が反映されるまでに最大 24 時間かかることがあります。

ACM が提供する証明書を使用している場合は、ACM がユーザーに代わって証明書の更新を管理します。詳細については、*AWS Certificate Manager ユーザーガイド* の「[管理された更新](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html)」を参照してください。

## CloudFront ディストリビューションと証明書のドメイン名
<a name="https-requirements-domain-names-in-cert"></a>

カスタムオリジンを使用する場合、オリジンの SSL/TLS 証明書の**共通名**フィールドにドメイン名が含まれ、さらに**サブジェクト代替名**フィールドにもドメイン名がいくつか含まれることがあります。(CloudFront では証明書ドメイン名にワイルドカード文字を使用できます)。

証明書のドメイン名のうち 1 つは、オリジンドメイン名に指定したドメイン名と一致する必要があります。ドメイン名が一致しない場合、CloudFront は HTTP ステータスコード `502 (Bad Gateway)` をビューワーに返します。

**重要**  
ディストリビューションに代替ドメイン名を追加する場合、CloudFront はこの代替ドメイン名が添付した証明書の対象であることを確認します。証明書は、証明書のサブジェクト代替名 (SAN) フィールドの代替ドメイン名をカバーする必要があります。つまり、SAN フィールドは、代替ドメイン名と完全に一致するか、追加する代替ドメイン名の同じレベルにワイルドカードが含まれている必要があります。  
詳細については、「[代替ドメイン名を使用するための要件](CNAMEs.md#alternate-domain-names-requirements)」を参照してください。

## SSL/TLS プロトコルの最小バージョン
<a name="https-requirements-minimum-ssl-protocol-version"></a>

専用 IP アドレスを使用している場合、セキュリティポリシーを選ぶことでビューワーと CloudFront との間の接続に最小 SSL/TLS プロトコルバージョンを設定できます。

詳細については、トピック「[すべてのディストリビューション設定リファレンス](distribution-web-values-specify.md)」の「[セキュリティポリシー (SSL/TLS の最小バージョン）](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy)」を参照してください。

## サポートされる HTTP バージョン
<a name="https-requirements-supported-http-versions"></a>

1 つの証明書を複数の CloudFront ディストリビューションに関連付ける場合、証明書に関連付けられたすべてのディストリビューションで、[サポートされる HTTP バージョン](DownloadDistValuesGeneral.md#DownloadDistValuesSupportedHTTPVersions) に対して同じオプションを使用する必要があります。このオプションは、CloudFront ディストリビューションを作成または更新するときに指定します。

# CloudFront で SSL/TLS 証明書を使用する場合のクォータ (ビューワーと CloudFront との間の HTTPS のみ)
<a name="cnames-and-https-limits"></a>

CloudFront で SSL/TLS 証明書を使用する場合は、以下のクォータに注意してください。これらのクォータは、ビューワーと CloudFront 間の HTTPS 通信のために AWS Certificate Manager (ACM) を使ってプロビジョニングした、ACM にインポートした、または IAM 証明書ストアにアップロードした SSL/TLS 証明書のみに適用されます。

詳細については、「[SSL/TLS 証明書のクォータを引き上げる](increasing-the-limit-for-ssl-tls-certificates.md)」を参照してください。

**CloudFront ディストリビューションあたりの証明書の最大数**  
各 CloudFront ディストリビューションに関連付けることができる SSL/TLS 証明書は最大 1 個です。

**ACM へのインポートまたは IAM 証明書ストアへのアップロードが可能な証明書の最大数**  
サードパーティー認証機関から SSL/TLS 証明書を取得した場合、次のいずれかの場所に証明書を保存する必要があります。  
+ **AWS Certificate Manager** - ACM 証明書数に対する現在のクォータについては、*AWS Certificate Manager ユーザーガイド*の「[クォータ](https://docs.aws.amazon.com/acm/latest/userguide/acm-limits.html)」を参照してください。一覧表示されているクォータは、ACM を使用してプロビジョニングした証明書や ACM にインポートした証明書を含む合計です。
+ **IAM 証明書ストア** – AWS アカウントの IAM 証明書ストアにアップロードできる証明書の数の現在のクォータ (以前は制限と呼ばれていました) については、*IAM ユーザーガイド*の「[IAM および STS の制限](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-limits.html)」を参照してください。クォータの引き上げは、Service Quotas コンソールでリクエストできます。

**AWS アカウントごとの証明書の最大数 (専用 IP アドレスのみ)**  
専用 IP アドレスを使用して HTTPS リクエストを供給する場合は、以下の点に注意してください。  
+ デフォルトで、CloudFront は AWS で 2 つの証明書を使用する許可を付与します。そのうちの 1 つは日常的に使用する証明書で、もう 1 つは複数のディストリビューションのために証明書のローテーションを実行する必要がある場合の証明書です。
+ 単一の AWS アカウントに複数のカスタム SSL/TLS 証明書が必要な場合は、Service Quotas コンソールでクォータの引き上げをリクエストできます。

**複数の異なる AWS アカウントを使用して作成した CloudFront ディストリビューションに同じ証明書を使用する**  
サードパーティー CA を使用しており、異なる AWS アカウントを使用して作成された複数の CloudFront ディストリビューションで同じ証明書を使用する場合は、証明書を AWS アカウントごとに 1 回 ACM にインポートするか、IAM 証明書ストアにアップロードする必要があります。  
ACM から提供される証明書を使用している場合、別の AWS アカウントで作成された証明書を使用するように CloudFront を設定することはできません。

**CloudFront と AWS の他のサービスに同じ証明書を使用する**  
Comodo、DigiCert、または Symantec などの信頼できる認証機関から証明書を購入した場合、CloudFront と AWS の他のサービスに同じ証明書を使用できます。ACM に証明書をインポートする場合は、一度インポートするだけで複数の AWS のサービスに証明書を使用できます。  
ACM が提供した証明書を使用している場合、証明書は ACM に格納されています。

**複数の CloudFront ディストリビューションに同じ証明書を使用する**  
HTTPS リクエストに対応するために使用している一部またはすべての CloudFront ディストリビューションで同じ証明書を使用できます。次の点に注意してください。  
+ 専用 IP アドレスを使用したリクエストの処理と SNI を使用したリクエストの処理の両方に同じ証明書を使用できます。
+ 各ディストリビューションに 1 個のみ証明書を関連付けることができます。
+ 各ディストリビューションには、証明書の**共通名**フィールドまたは**サブジェクト代替名**フィールドにも表示される 1 つ以上の代替ドメイン名を含める必要があります。
+ 専用 IP アドレスを使用して HTTPS リクエストを処理し、同じ AWS アカウントを使用してすべてのディストリビューションを作成した場合は、すべてのディストリビューションに同じ証明書を使用することによってコストを大幅に削減できます。CloudFront での課金は、ディストリビューションごとではなく、証明書ごとに行われます。

  例えば、同じ AWS アカウントを使用して 3 つのディストリビューションを作成し、3 つのディストリビューションすべてに対して同じ証明書を使用するとします。専用 IP アドレスの使用に対する 1 つの料金のみが発生します。

  ただし、専用 IP アドレスを使用して HTTPS リクエストを処理していて、異なる AWS アカウントでの CloudFront ディストリビューションの作成に同じ証明書を使用している場合は、各アカウントで専用 IP アドレスの使用に対する料金が発生します。例えば、3 つの異なる AWS アカウントを使用して 3 つのディストリビューションを作成し、3 つのすべてのディストリビューションに対して同じ証明書を使用する場合、専用 IP アドレスの使用に対する料金の全額が各アカウントに請求されます。

# 代替ドメイン名と HTTPS を設定する
<a name="cnames-and-https-procedures"></a>

ファイルの URL で代替ドメイン名を使用し、ビューワーと CloudFront との間で HTTPS を使用するには、該当する手順を実行します。

**Topics**
+ [SSL/TLS 証明書を取得する](#cnames-and-https-getting-certificates)
+ [SSL/TLS 証明書をインポートする](#cnames-and-https-uploading-certificates)
+ [CloudFront ディストリビューションを更新する](#cnames-and-https-updating-cloudfront)

## SSL/TLS 証明書を取得する
<a name="cnames-and-https-getting-certificates"></a>

SSL/TLS 証明書を取得します (まだ取得していない場合)。詳細については、該当するドキュメントを参照してください。
+ AWS Certificate Manager (ACM) が提供する証明書を使用するには、[AWS Certificate Manager ユーザーガイド](https://docs.aws.amazon.com/acm/latest/userguide/)を参照してください。その後、[CloudFront ディストリビューションを更新する](#cnames-and-https-updating-cloudfront) に進みます。
**注記**  
AWS のマネージドリソースでの SSL/TLS 証明書のプロビジョニング、管理、およびデプロイには、ACM の使用をお勧めします。米国東部 (バージニア北部) リージョンで ACM 証明書をリクエストする必要があります。
+ サードパーティー認証機関 (CA) から証明書を取得するには、認証機関から提供されたドキュメントを参照してください。証明書を取得した後、次の手順に進んでください。

## SSL/TLS 証明書をインポートする
<a name="cnames-and-https-uploading-certificates"></a>

サードパーティー認証機関から証明書を取得した場合、証明書を ACM にインポートするか、IAM 証明書ストアにアップロードします。

**ACM (推奨)**  
ACM では、ACM コンソールから、またはプログラムによってサードパーティー証明書をインポートできます。ACM への証明書のインポートについては、*AWS Certificate Manager ユーザーガイド*の「[AWS Certificate Manager への証明書のインポート](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html)」を参照してください。米国東部 (バージニア北部) リージョンで証明書をインポートする必要があります。

**IAM 証明書ストア**  
(非推奨) 次の AWS CLI コマンドを使用してサードパーティー証明書を IAM 証明書ストアにアップロードします。  

```
aws iam upload-server-certificate \
        --server-certificate-name CertificateName \
        --certificate-body file://public_key_certificate_file \
        --private-key file://privatekey.pem \
        --certificate-chain file://certificate_chain_file \
        --path /cloudfront/path/
```
次の点に注意してください。  
+ **AWS アカウント** - 証明書は、CloudFront ディストリビューションを作成するために使用した AWS アカウントと同じアカウントを使用して IAM 証明書ストアにアップロードする必要があります。
+ **--path パラメータ** – 証明書を IAM にアップロードする場合、`--path` パラメータ (証明書のパス) の値が `/cloudfront/` で始まる必要があります (`/cloudfront/production/`、`/cloudfront/test/` など)。パスは / で終わる必要があります。
+ **既存の証明書** – `--server-certificate-name` および `--path` パラメータには、既存の証明書に関連付けられている値とは異なる値を指定する必要があります。
+ **CloudFront コンソールの使用** – `--server-certificate-name` で AWS CLI パラメータに指定する値 (`myServerCertificate` など) は、CloudFront コンソールの [**SSL Certificate**] (SSL 証明書) リストに表示されます。
+ **CloudFront API の使用** – AWS CLI から返される英数字の文字列 (`AS1A2M3P4L5E67SIIXR3J` など) を書き留めておきます。これは、`IAMCertificateId` エレメントに指定する値です。CLI から返される IAM ARN を書き留めておく必要はありません。
AWS CLI の詳細については、[AWS Command Line Interface ユーザーガイド](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)および [AWS CLI コマンドリファレンス](https://docs.aws.amazon.com/cli/latest/reference/)を参照してください。

## CloudFront ディストリビューションを更新する
<a name="cnames-and-https-updating-cloudfront"></a>

ディストリビューションの設定を更新するには、以下の手順を実行します。<a name="cnames-and-https-updating-cloudfront-procedure"></a>

**代替ドメイン名用に CloudFront ディストリビューションを構成するには**

1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. 更新するディストリビューションの ID を選択します。

1. [**General**] タブで、[**Edit**] を選択します。

1. 以下の値を更新します。  
**代替ドメイン名 (CNAME)**  
**[項目を追加]** を選択して、該当する代替ドメイン名を追加します。ドメイン名をコンマで区切るか、新しい行にドメイン名を 1 つずつ入力します。  
**カスタム SSL 証明書**  
ドロップダウンリストから証明書を選択します。  
100 個までの証明書がここに一覧表示されます。100 個を超える証明書があり、追加する証明書が表示されない場合には、フィールドに証明書の ARN を入力して選択できます。  
IAM 証明書ストアに証明書をアップロードしたが、一覧に表示されず、フィールドに入力しても選択できない場合には、「[SSL/TLS 証明書をインポートする](#cnames-and-https-uploading-certificates)」の手順を参照して、証明書を正しくアップロードしたかを確認します。  
SSL/TLS 証明書を CloudFront ディストリビューションに関連付けたら、すべてのディストリビューションから証明書を削除してすべてのディストリビューションがデプロイ済みになるまでは、証明書を ACM または IAM 証明書ストアから削除しないでください。

1. **[Save changes]** (変更の保存) をクリックします。

1. ビューワーと CloudFront の間で HTTPS が必須になるよう CloudFront を設定する

   1. [**Behaviors (動作)**] タブで、更新するキャッシュ動作を選択して、[**Edit (編集)**] を選択します。

   1. [**Viewer Protocol Policy**] として次のいずれかの値を指定します。  
**Redirect HTTP to HTTPS**  
ビューワーは両方のプロトコルを使用できますが、HTTP リクエストは自動的に HTTPS リクエストにリダイレクトされます。CloudFront は新しい HTTPS URL と一緒に HTTP ステータスコード `301 (Moved Permanently)` を返します。ビューワーはこの HTTPS URL を使用して CloudFront にリクエストを再送信します。  
CloudFront は、HTTP から HTTPS に `DELETE`、`OPTIONS`、`PATCH`、`POST`、または `PUT` リクエストをリダイレクトしません。HTTPS にリダイレクトするようにキャッシュ動作を設定した場合、CloudFront は HTTP ステータスコード `DELETE` を使用して、そのキャッシュ動作の HTTP リクエスト (`OPTIONS`、`PATCH`、`POST`、`PUT`、または `403 (Forbidden)`) に応答します。
ビューワーが作成した HTTP リクエストが HTTPS リクエストにリダイレクトされた場合、CloudFront では両方のリクエストに対する課金が発生します。HTTP リクエストの場合は、リクエストの料金と、CloudFront がビューワーに返すヘッダーの料金のみが課金されます。HTTPS リクエストの場合、リクエストの料金と、ファイルが返すヘッダーとオブジェクトの料金が課金されます。  
**HTTPS Only**  
ビューワーは、HTTPS を使用している場合にのみ、コンテンツにアクセスできます。ビューワーから HTTPS リクエストではなく HTTP リクエストが送信された場合、CloudFront は HTTP ステータスコード `403 (Forbidden)` を返し、ファイルは返しません。

   1. [**Yes, Edit (はい、編集します)**] を選択します。

   1. ビューワーと CloudFront との間で HTTPS を必須にする追加のキャッシュ動作ごとに、ステップ a から c を繰り返します。

1. 本番環境で更新された情報を使用する前に、次を確認してください。
   + ビューワーに HTTPS の使用が必要とされるリクエストにのみ、各キャッシュ動作のパスパターンが適用されている。
   + CloudFront が評価する順番にキャッシュ動作がリストされている。詳細については、「[パスパターン](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern)」を参照してください。
   + キャッシュ動作は、リクエストを正しいオリジンにルーティングします。

# SSL/TLS RSA 証明書内のパブリックキーのサイズを確認する
<a name="cnames-and-https-size-of-public-key"></a>

CloudFront 代替ドメイン名と HTTPS を使用する場合、SSL/TLS RSA 証明書内のパブリックキーの最大サイズは 4096 ビットです。(これはキーサイズであり、パブリックキー内の文字数ではありません)。証明書に AWS Certificate Manager を使用する場合、ACM ではこれより大きい RSA キーがサポートされますが、CloudFront ではそのキーを使用できません。

RSA パブリック (公開) キーのサイズを確認するには、次の OpenSSL コマンドを実行できます。

```
openssl x509 -in path and filename of SSL/TLS certificate -text -noout 
```

各パラメータの意味は次のとおりです。
+ `-in` は、SSL/TLS RSA 証明書のパスとファイル名を指定します。
+ `-text` によって、OpenSSL において、RSA パブリック (公開) キーの長さがビット単位で表示されます。
+ `-noout`: OpenSSL において、パブリックキーが非表示になります。

出力例:

```
Public-Key: (2048 bit)
```

# SSL/TLS 証明書のクォータを引き上げる
<a name="increasing-the-limit-for-ssl-tls-certificates"></a>

AWS Certificate Manager (ACM) にインポートしたり、AWS Identity and Access Management (IAM) にアップロードしたりできる SSL/TLS 証明書の数にはクォータがあります。専用 IP アドレスを使用して HTTPS リクエストを処理するように CloudFront を設定するときに AWS アカウントで使用できる SSL/TLS 証明書の数にもクォータがあります。ただし、これらのクォータ数を増やすようにリクエストできます。

**Topics**
+ [ACM にインポートする証明書のクォータを引き上げる](#certificates-to-import-into-acm)
+ [IAM にアップロードする証明書のクォータを引き上げる](#certificates-to-upload-into-iam)
+ [専用 IP アドレスで使用する証明書のクォータを引き上げる](#certificates-using-dedicated-ip-address)

## ACM にインポートする証明書のクォータを引き上げる
<a name="certificates-to-import-into-acm"></a>

ACM にインポートできる証明書の数のクォータについては、*AWS Certificate Manager ユーザーガイド*の「[クォータ](https://docs.aws.amazon.com/acm/latest/userguide/acm-limits.html)」を参照してください。

クォータの引き上げには、Service Quotas コンソールを使用します。詳細については、「*Service Quotas ユーザーガイド*」の「[クォータの引き上げのリクエスト](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)」を参照してください。

## IAM にアップロードする証明書のクォータを引き上げる
<a name="certificates-to-upload-into-iam"></a>

IAM にアップロードできる証明書の数のクォータについては、*IAM ユーザーガイド*の「[IAM と STS の制限](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-limits.html)」を参照してください。

クォータの引き上げには、Service Quotas コンソールを使用します。詳細については、「*Service Quotas ユーザーガイド*」の「[クォータの引き上げのリクエスト](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)」を参照してください。

## 専用 IP アドレスで使用する証明書のクォータを引き上げる
<a name="certificates-using-dedicated-ip-address"></a>

専用 IP アドレスを使用して HTTPS リクエストを処理するときに各 AWS アカウントで使用できる SSL 証明書の数のクォータについては、「[SSL 証明書のクォータ](cloudfront-limits.md#limits-ssl-certificates)」を参照してください。

クォータの引き上げには、Service Quotas コンソールを使用します。詳細については、「*Service Quotas ユーザーガイド*」の「[クォータの引き上げのリクエスト](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)」を参照してください。

# SSL/TLS 証明書をローテーションする
<a name="cnames-and-https-rotate-certificates"></a>

SSL/TLS 証明書の有効期限が近づいたら、それをローテーションしてディストリビューションのセキュリティを確保し、ビューワーへのサービス中断を回避する必要があります。ローテーションは以下の方法で行うことができます。
+ AWS Certificate Manager (ACM) が提供する SSL/TLS 証明書の場合、ローテーションする必要はありません。証明書の更新は、ACM によって*自動的に*行われます。詳細については、「*AWS Certificate Manager ユーザーガイド*」の「[Managed certificate renewal](https://docs.aws.amazon.com/acm/latest/userguide/acm-renewal.html)」を参照してください。
+ サードパーティー認証機関を利用しており、証明書を ACM にインポートした場合 (推奨) または IAM 証明書ストアにアップロードした場合、証明書の交換が必要になることがあります。

  

**重要**  
ACM では、サードパーティー認証機関から入手して ACM にインポートした証明書の更新が管理されません。
専用 IP アドレスを使用して HTTPS リクエストを処理するよう CloudFront を設定した場合、証明書をローテーションしている間、追加の証明書に対して按分された追加料金がかかる可能性があります。ディストリビューションの更新を行って、追加料金を最低限にすることをお勧めします。

## SSL/TLS 証明書をローテーションする
<a name="rotate-ssl-tls-certificate"></a>

証明書をローテーションするには、以下の手順を実行します。ビューワーは、プロセスが完了した後だけでなく、証明書を更新している間もコンテンツにアクセスし続けることができます。<a name="rotate-ssl-tls-certificates-proc"></a>

**SSL/TLS 証明書をローテーションするには**

1. [SSL/TLS 証明書のクォータを引き上げる](increasing-the-limit-for-ssl-tls-certificates.md)、追加の SSL 証明書を使用するためにアクセス権限が必要かどうかを調べます。その場合、アクセス権限をリクエストし、ステップ 2 を続ける前にアクセス権限が付与されるまで待ってください。

1. 新しい証明書を ACM にインポートするか、IAM にアップロードします。詳細については、*Amazon CloudFront 開発者ガイド*の「[SSL/TLS 証明書をインポートする](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-procedures.html#cnames-and-https-uploading-certificates)」を参照してください。

1. (IAM 証明書のみ) ディストリビューションを一度に 1 つずつ、新しい証明書を使用できるように更新します。詳細については、「[ディストリビューションを更新する](HowToUpdateDistribution.md)」を参照してください。

1. (オプション) ACM または IAM から以前の証明書を削除します。
**重要**  
すべてのディストリビューションから SSL/TLS 証明書を削除し、更新されたディストリビューションのステータスが [`Deployed`] に変わるまで、SSL/TLS 証明書を削除しないでください。

# カスタム SSL/TLS 証明書からデフォルト CloudFront 証明書に戻す
<a name="cnames-and-https-revert-to-cf-certificate"></a>

ビューワーと CloudFront との間で HTTPS を使用するように CloudFront を設定し、カスタム SSL/TLS 証明書を使用するように CloudFront を設定した場合、デフォルトの CloudFront SSL/TLS 証明書を使用するように設定を変更できます。プロセスは、コンテンツの配信にディストリビューションを使用しているかどうかによって異なります。
+ ディストリビューションを使用してコンテンツを配信したことがない場合は、単に構成を変更できます。詳細については、「[ディストリビューションを更新する](HowToUpdateDistribution.md)」を参照してください。
+ ディストリビューションを使用してコンテンツを配信していた場合は、新しい CloudFront ディストリビューションを作成し、コンテンツが使用できない時間を減らすかゼロにするために、ファイルの URL を変更する必要があります。そのためには、以下の手順を実行します。

## デフォルト CloudFront 証明書に戻す
<a name="revert-default-cloudfront-certificate"></a>

次の手順では、カスタム SSL/TLS 証明書からデフォルト CloudFront 証明書に戻す方法を示します。<a name="cnames-and-https-revert-to-cf-certificate-proc"></a>

**デフォルトの CloudFront 証明書に戻すには**

1. 適切な構成で、新しい CloudFront ディストリビューションを作成します。[**SSL 証明書**] には、[**デフォルトの CloudFront 証明書 (\$1.cloudfront.net)**] を選択します。

   詳細については、「[ディストリビューションを作成する](distribution-web-creating-console.md)」を参照してください。

1. CloudFront を使用して配信しているファイルの場合は、アプリケーションの URL を更新して、CloudFront によって新しいディストリビューションに割り当てられたドメイン名を使用します。たとえば、`https://www.example.com/images/logo.png` を `https://d111111abcdef8.cloudfront.net/images/logo.png` に変更します。

1. 独自 SSL/TLS 証明書に関連付けられているディストリビューションを削除するか、ディストリビューションを更新して [**SSL 証明書**] の値を [**デフォルトの CloudFront 証明書 (\$1.cloudfront.net)**] に変更します。詳細については、「[ディストリビューションを更新する](HowToUpdateDistribution.md)」を参照してください。
**重要**  
このステップが完了するまで、AWS は独自 SSL/TLS 証明書を使用する料金を課金し続けます。

1. (オプション) カスタム SSL/TLS 証明書を削除します。

   1. AWS CLI コマンド `list-server-certificates` を実行して、削除する証明書の証明書 ID を取得します。詳細については、*AWS CLI コマンドリファレンス*の「[list-server-certificates](https://docs.aws.amazon.com/cli/latest/reference/iam/list-server-certificates.html)」を参照してください。

   1. AWS CLI コマンド `delete-server-certificate` を実行して、証明書を削除します。詳細については、「AWS CLI コマンドリファレンス」の「[delete-server-certificate](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-server-certificate.html)」を参照してください。**

# 専用 IP アドレスを使用するカスタム SSL/TLS 証明書を SNI に切り替える
<a name="cnames-and-https-switch-dedicated-to-sni"></a>

専用 IP アドレスで独自 SSL/TLS 証明書を使用するように CloudFront を設定した場合、SNI でカスタム SSL/TLS 証明書を使用するように切り替えて、専用 IP アドレスに関連付けられた請求が発生しないように変更できます。

**重要**  
CloudFront 設定をこのように更新しても、SNI をサポートするビューワーには影響しません。ビューワーでは、変更前も変更後もコンテンツにアクセスできます。また、変更が CloudFront エッジロケーションに反映されている間もアクセスできます。SNI をサポートしていないビューワーは、変更後、コンテンツにアクセスできなくなります。詳細については、「[CloudFront で HTTPS リクエストを処理する方法を選択する](cnames-https-dedicated-ip-or-sni.md)」を参照してください。

## カスタム証明書から SNI に切り替える
<a name="cloudfront-switch-custom-cert-sni"></a>

次の手順では、専用 IP アドレスを使用するカスタム SSL/TLS 証明書を SNI に切り替える方法を示します。<a name="cnames-and-https-switch-dedicated-to-sni-proc"></a>

**独自 SSL/TLS 証明書を専用 IP アドレスから SNI に切り替えるには**

1. AWS マネジメントコンソール にサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. 表示または更新するディストリビューションの ID を選択します。

1. [**Distribution Settings**] を選択します。

1. [**General**] タブで、[**Edit**] を選択します。

1. **[カスタム SSL 証明書 – *オプション*]** で、**[レガシークライアントのサポート]** を選択解除します。

1. [**Yes, Edit (はい、編集します)**] を選択します。

# CloudFront による相互 TLS 認証 (Viewer mTLS)
<a name="mtls-authentication"></a>

相互 TLS 認証 (相互 Transport Layer Security 認証 - mTLS) は、双方向証明書ベースの認証を要求することで標準 TLS 認証を拡張するセキュリティプロトコルです。クライアントとサーバーの両方が、安全な接続を確立する前に ID を証明する必要があります。相互 TLS を使用すると、信頼される TLS 証明書を提示するクライアントのみが CloudFront ディストリビューションにアクセスできるようになります。

## 仕組み
<a name="how-mtls-works"></a>

標準の TLS ハンドシェイクでは、サーバーのみがクライアントに ID を証明する証明書を提示します。相互 TLS では、認証プロセスは双方向になります。クライアントが CloudFront ディストリビューションに接続しようとすると、CloudFront は TLS ハンドシェイク中にクライアント証明書をリクエストします。クライアントは、安全な接続を確立する前に、CloudFront が設定されたトラストストアに対して検証する有効な X.509 証明書を提示する必要があります。

CloudFront は、AWS エッジロケーションでこの証明書の検証を実行し、CloudFront のグローバルパフォーマンスの利点を維持しながら、オリジンサーバーから認証の複雑さをオフロードします。mTLS は、検証モード (すべてのクライアントが有効な証明書を提示する必要がある) またはオプションモード (提示されたときに証明書を検証するが、証明書のない接続も許可する) の 2 つのモードで設定できます。

## ユースケース
<a name="mtls-use-cases"></a>

CloudFront による相互 TLS 認証は、従来の認証方法では不足していたいくつかの重要なセキュリティシナリオに対処します。
+ **コンテンツキャッシュによるデバイス認証** - ファームウェアの更新、ゲームのダウンロード、または内部リソースへのアクセスを許可する前に、ゲームコンソール、IoT デバイス、または企業ハードウェアを認証することができます。各デバイスには、CloudFront のキャッシュ機能のメリットを享受しながら、その信頼性を証明する一意の証明書が含まれています。
+ **API-to-API 認証** - 信頼されるビジネスパートナー、支払いシステム、マイクロサービス間のマシン間通信を保護できます。証明書ベースの認証により、自動データ交換に強力な ID 検証を提供しながら、共有シークレットや API キーが不要になります。

**Topics**
+ [仕組み](#how-mtls-works)
+ [ユースケース](#mtls-use-cases)
+ [トラストストアと証明書の管理](trust-stores-certificate-management.md)
+ [CloudFront ディストリビューションの相互 TLS を有効にする](enable-mtls-distributions.md)
+ [CloudFront Connection Function を関連付ける](connection-functions.md)
+ [その他の設定](configuring-additional-settings.md)
+ [オリジンに転送されるキャッシュポリシーの mTLS ヘッダービューワー](viewer-mtls-headers.md)
+ [CloudFront 接続Connection Function と KVS を使用した取り消し](revocation-connection-function-kvs.md)
+ [接続ログを使用したオブザーバビリティ](connection-logs.md)

# トラストストアと証明書の管理
<a name="trust-stores-certificate-management"></a>

トラストストアの作成と設定は、CloudFront との相互 TLS 認証を実装するための必須要件です。トラストストアには、認証プロセス中に CloudFront がクライアント証明書を検証するために使用する認証局 (CA) の証明書が含まれています。

## トラストストアとは
<a name="what-is-trust-store"></a>

トラストストアは、相互 TLS 認証中に CloudFront がクライアント証明書を検証するために使用する CA 証明書のリポジトリです。トラストストアには、クライアント証明書を認証するための信頼チェーンを形成するルート CA 証明書と中間 CA 証明書が含まれています。

CloudFront で相互 TLS を実装する場合、トラストストアは、有効なクライアント証明書を発行するために信頼する認証局を定義します。CloudFront は、TLS ハンドシェイク中に各クライアント証明書と信頼ストアを照合します。トラストストアのいずれかの CA にチェーンされる証明書を提示するクライアントのみが、正常に認証されます。

CloudFront のトラストストアは、複数のディストリビューションに関連付けることができるアカウントレベルのリソースです。これにより、CA 証明書の管理を簡素化しながら、CloudFront のデプロイ全体で整合性のある証明書検証ポリシーを維持できます。

## 認証局のサポート
<a name="ca-support"></a>

CloudFront は、AWS プライベート認証局とサードパーティーのプライベート認証局の両方によって発行された証明書をサポートします。この柔軟性により、組織の要件に基づいて、既存の証明書インフラストラクチャを使用したり、AWS マネージド証明書サービスを活用したりできます。
+ **AWS プライベート認証局:** マネージドプライベート認証局サービスを提供する AWS プライベート CA によって発行された証明書を使用できます。この統合により、証明書のライフサイクル管理が簡素化され、他の AWS サービスとシームレスに統合できます。
+ **サードパーティーのプライベート認証局:** エンタープライズ CA や他のサードパーティーの証明書プロバイダーを含め、既存のプライベート認証局インフラストラクチャからの証明書を使用することもできます。これにより、CloudFront の mTLS 機能を追加しながら、現在の証明書管理プロセスを維持できます。

## 証明書の要件と仕様
<a name="certificate-requirements"></a>

トラストストアには、含められる CA 証明書に特定の要件があります。

### CA 証明書形式の要件
<a name="ca-cert-format-requirements"></a>
+ **形式:** PEM (Privacy Enhanced Mail) 形式
+ **コンテンツの境界:** 証明書は -----BEGIN CERTIFICATE----- と -----END CERTIFICATE----- の境界で囲まれている必要があります
+ **コメント:** 先頭に \$1 を付け、- 文字を含めることはできません
+ **改行:** 証明書間に空白行は許可されていません

### サポートされている証明書の仕様
<a name="supported-cert-specs"></a>
+ **証明書タイプ:** X.509v3
+ **パブリックキーのタイプ:**
  + RSA 2048、RSA 3072、RSA 4096
  + ECDSA: secp256r1、secp384r1
+ **署名アルゴリズム:**
  + SHA256, SHA384, SHA512 with RSA
  + SHA256, SHA384, SHA512 with EC
  + SHA256, SHA384, SHA512 with RSASSA-PSS with MGF1

### 証明書バンドル形式の例
<a name="example-cert-bundle"></a>

複数の証明書 (PEM エンコード):

```
# Root CA Certificate
-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKoK/OvD/XqiMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQwHhcNMTcwNzEyMTU0NzQ4WhcNMjcwNzEwMTU0NzQ4WjBF
MQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50
ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAuuExKvY1xzHFylsHiuowqpmzs7rEcuuylOuEszpFp+BtXh0ZuEtts9LP
-----END CERTIFICATE-----
# Intermediate CA Certificate
-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKoK/OvD/XqjMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQwHhcNMTcwNzEyMTU0NzQ4WhcNMjcwNzEwMTU0NzQ4WjBF
MQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50
ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAuuExKvY1xzHFylsHiuowqpmzs7rEcuuylOuEszpFp+BtXh0ZuEtts9LP
-----END CERTIFICATE-----
```

## トラストストアを作成する
<a name="create-trust-store"></a>

トラストストアを作成する前に、CA 証明書バンドルを PEM 形式で Amazon S3 バケットにアップロードする必要があります。証明書バンドルには、クライアント証明書の検証に必要な信頼されるルート CA 証明書と中間 CA 証明書がすべて含まれている必要があります。

CA 証明書バンドルは、トラストストアを作成するときに S3 から 1 回だけ読み取られます。今後、CA 証明書バンドルが変更される場合は、トラストストアを手動で更新する必要があります。トラストストアと S3 CA 証明書バンドル間の同期は維持されません。

### 前提条件
<a name="trust-store-prerequisites"></a>
+ Amazon S3 バケットにアップロードされた認証局 (CA) からの証明書バンドル
+ CloudFront リソースを作成するために必要なアクセス許可

### トラストストアを作成するには (コンソール)
<a name="create-trust-store-console"></a>

1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. ナビゲーションペインで **[トラストストア]** を選択します。

1. **[トラストストアを作成]** を選択します。

1. **[トラストストアの名前]** に、トラストストアの名前を入力します。

1. **[認証局 (CA) バンドル]** に、PEM 形式の CA 証明書バンドルへの Amazon S3 パスを入力します。

1. **[トラストストアを作成]** を選択します。

### トラストストアを作成するには (AWS CLI)
<a name="create-trust-store-cli"></a>

```
aws cloudfront create-trust-store \
  --name MyTrustStore \
  --certificate-authority-bundle-s3-location Bucket=my-bucket,Key=ca-bundle.pem \
  --tags Items=[{Key=Environment,Value=Production}]
```

## トラストストアをディストリビューションに関連付ける
<a name="associate-trust-store"></a>

トラストストアを作成した後、相互 TLS 認証を有効にするために CloudFront ディストリビューションに関連付ける必要があります。

### 前提条件
<a name="associate-prerequisites"></a>
+ HTTPS のみのビューワープロトコルポリシーが有効で、HTTP3 サポートが無効になっている既存の CloudFront ディストリビューション。

### トラストストアを関連付けるには (コンソール)
<a name="associate-trust-store-console"></a>

CloudFront コンソール内でトラストストアを関連付けるには、トラストストアの詳細ページから、またはディストリビューション設定ページからの 2 つの方法があります。

**トラストストアの詳細ページを介したトラストストアの関連付け:**

1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. ナビゲーションペインで **[トラストストア]** を選択します。

1. 関連付けるトラストストアの名前を選択します。

1. **[ディストリビューションに関連付ける]** を選択します。

1. 使用可能なビューワーの mTLS オプションを設定します。
   + **クライアント証明書の検証モード:** 必須モードとオプションモードから選択します。必須モードでは、すべてのクライアントが証明書を提示する必要があります。オプションモードでは、証明書を提示するクライアントは検証され、証明書を提示しないクライアントにはアクセスが許可されます。
   + **トラストストア CA 名をアドバタイズする:** TLS ハンドシェイク中にトラストストアの CA 名をクライアントにアドバタイズするかどうかを選択します。
   + **証明書の有効期限を無視する:** 有効期限が切れた証明書を使用した接続を許可するかどうかを選択します (他の検証基準も適用されます)。
   + **Connection Function:** オプションの Connection Function を関連付けて、他のカスタム条件に基づいて接続を許可/拒否できます。

1. トラストストアに関連付ける 1 つ以上のディストリビューションを選択します。ビューワー mTLS をサポートできるのは、HTTP3 が無効になっているディストリビューションと HTTPS のみのキャッシュ動作を持つディストリビューションのみです。

1. **関連付ける** を選択してください。

**ディストリビューション設定のページからのトラストストアの関連付け:**

1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. 関連付けるディストリビューションを選択します。

1. **[全般]** タブの **[設定]** コンテナで、右上の **[編集]** を選択します。

1. ページを最下部までスクロールし、**[接続]** コンテナ内で **[ビューワーの mTLS]** スイッチをオンに切り替えます。

1. 使用可能なビューワーの mTLS オプションを設定します。
   + **クライアント証明書の検証モード:** 必須モードとオプションモードから選択します。必須モードでは、すべてのクライアントが証明書を提示する必要があります。オプションモードでは、証明書を提示するクライアントは検証され、証明書を提示しないクライアントにはアクセスが許可されます。
   + **トラストストア CA 名をアドバタイズする:** TLS ハンドシェイク中にトラストストアの CA 名をクライアントにアドバタイズするかどうかを選択します。
   + **証明書の有効期限を無視する:** 有効期限が切れた証明書を使用した接続を許可するかどうかを選択します (他の検証基準も適用されます)。
   + **Connection Function:** オプションの Connection Function を関連付けて、他のカスタム条件に基づいて接続を許可/拒否できます。

1. 右下の **[変更の保存]** を選択します。

### トラストストアを関連付けるには (AWS CLI)
<a name="associate-trust-store-cli"></a>

トラストストアは、DistributionConfig.ViewerMtlsConfig プロパティを介してディストリビューションに関連付けることができます。つまり、まずディストリビューション設定を取得し、後続の UpdateDistribution リクエストで ViewerMtlsConfig を指定する必要があります。

```
// First fetch the distribution
aws cloudfront get-distribution {DISTRIBUTION_ID}

// Update the distribution config, for example:
Distribution config, file://distConf.json: 
{
  ...other fields,
  ViewerMtlsConfig: {
    Mode: 'required',
    TrustStoreConfig: {
        AdvertiseTrustStoreCaNames: false,
        IgnoreCertificateExpiry: true,
        TrustStoreId: {TRUST_STORE_ID}
    }
  }
}

aws cloudfront update-distribution \
   --id {DISTRIBUTION_ID} \
   --if-match {ETAG} \
   --distribution-config file://distConf.json
```

## トラストストアを管理する
<a name="manage-trust-stores"></a>

### トラストストアの詳細を表示する
<a name="view-trust-store-details"></a>

1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. ナビゲーションペインで **[トラストストア]** を選択します。

1. トラストストアの名前を選択して、詳細ページを表示します。

詳細ページには以下が表示されます。
+ トラストストアの名前と ID
+ CA 証明書の数
+ 作成日と最後に変更された日付
+ 関連付けられたディストリビューション
+ タグ

### トラストストアを変更する
<a name="modify-trust-store"></a>

CA 証明書バンドルを置き換えるには

1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. ナビゲーションペインで **[トラストストア]** を選択します。

1. トラストストアの名前を選択します。

1. **[アクション]**、**[編集]** の順に選択します。

1. **認証局 (CA) バンドル**の場合、更新された CA バンドル PEM ファイルの Amazon S3 の場所を入力します。

1. **[トラストストアを更新]** を選択します。

### トラストストアを削除する
<a name="delete-trust-store"></a>

**前提条件:** まず、すべての CloudFront ディストリビューションからトラストストアの関連付けを解除する必要があります。

1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. ナビゲーションペインで **[トラストストア]** を選択します。

1. トラストストアの名前を選択します。

1. **[トラストストアを削除]** を選択します。

1. [**Delete**] を選択して確定します。

### 次のステップ
<a name="trust-store-next-steps"></a>

トラストストアを作成して CloudFront ディストリビューションに関連付けると、ディストリビューションで相互 TLS 認証を有効にし、証明書ヘッダーをオリジンに転送するなどの追加設定を行うことができます。ディストリビューションで mTLS を有効にする詳細な手順については、「[CloudFront ディストリビューションの相互 TLS を有効にする](enable-mtls-distributions.md)」を参照してください。

# CloudFront ディストリビューションの相互 TLS を有効にする
<a name="enable-mtls-distributions"></a>

## 前提条件と要件
<a name="mtls-prerequisites-requirements"></a>

CloudFront の相互 TLS 検証モードでは、すべてのクライアントが TLS ハンドシェイク中に有効な証明書を提示する必要があり、有効な証明書がない接続を拒否します。CloudFront ディストリビューションで相互 TLS を有効にする前に、以下を確認してください。
+ 認証局証明書を含むトラストストアを作成した
+ トラストストアを CloudFront ディストリビューションに関連付けた
+ すべての分散キャッシュ動作が HTTPS のみのビューワープロトコルポリシーを使用していることを確認した
+ ディストリビューションが HTTP/2 を使用していることを確認した (デフォルト設定、ビューワー mTLS は HTTP/3 ではサポートされていません)

**注記**  
相互 TLS 認証には、ビューワーと CloudFront 間で HTTPS 接続が必要です。HTTP 接続をサポートするキャッシュ動作を持つディストリビューションで mTLS を有効にすることはできません。

## 相互 TLS を有効にする (コンソール)
<a name="enable-mtls-console"></a>

### 新しいディストリビューションの場合
<a name="enable-mtls-new-distributions"></a>

CloudFront コンソールで新しいディストリビューションを作成するプロセスでビューワー mTLS を設定することはできません。まず、任意の方法 (コンソール、CLI、API) でディストリビューションを作成し、ディストリビューション設定を編集して、以下の既存のディストリビューションの手順に従ってビューワー mTLS を有効にします。

### 既存のディストリビューションの場合
<a name="enable-mtls-existing-distributions"></a>

1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. ディストリビューションリストから、変更するディストリビューションを選択します。

1. すべてのキャッシュ動作についてビューワープロトコルポリシーが **[HTTP を HTTPS にリダイレクト]** または **[HTTPS のみ]** に設定されている必要があります。(**[キャッシュ動作]** タブを選択すると、HTTP プロトコルポリシーでキャッシュ動作を表示および更新できます。)

1. **[General]** (全般) タブを選択します。

1. **設定** セクションで、**編集** を選択します。

1. **[接続]** セクションで、**ビューワー相互認証 (mTLS)** を検索します。

1. **[相互認証を有効にする]** をオンに切り替えます。

1. **[クライアント証明書の検証モード]** で、**[必須]** (すべてのクライアントが証明書を提示する必要がある) または **[オプション]** (クライアントはオプションで証明書を提示できる) を選択します。

1. **[トラストストア]** で、以前に作成したトラストストアを選択します。

1. (オプション) CloudFront が TLS ハンドシェイク中に CA 名をクライアントに送信する場合は、**[トラストストア CA 名をアドバタイズ]** を切り替えます。

1. (オプション) 有効期限が切れた証明書を使用した接続を許可する場合は、**証明書の有効期限を無視**します。

1. **[Save changes]** (変更の保存) をクリックします。

## 相互 TLS を有効にする (AWS CLI)
<a name="enable-mtls-cli"></a>

### 新しいディストリビューションの場合
<a name="enable-mtls-cli-new"></a>

次の例は、mTLS 設定を含むディストリビューション設定ファイル (distribution-config.json) を作成する方法を示します。

```
{
  "CallerReference": "cli-example-1",
  "Origins": {
    "Quantity": 1,
    "Items": [
      {
        "Id": "my-origin",
        "DomainName": "example.com",
        "CustomOriginConfig": {
          "HTTPPort": 80,
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only"
        }
      }
    ]
  },
  "DefaultCacheBehavior": {
    "TargetOriginId": "my-origin",
    "ViewerProtocolPolicy": "https-only",
    "MinTTL": 0,
    "ForwardedValues": {
      "QueryString": false,
      "Cookies": {
        "Forward": "none"
      }
    }
  },
  "ViewerCertificate": {
    "CloudFrontDefaultCertificate": true
  },
  "ViewerMtlsConfig": {
    "Mode": "required", 
    "TrustStoreConfig": {
        "TrustStoreId": {TRUST_STORE_ID},
        "AdvertiseTrustStoreCaNames": true,
        "IgnoreCertificateExpiry": true
    }
  },
  "Enabled": true
}
```

次のコマンド例を使用し、mTLS を有効にしてディストリビューションを作成します。

```
aws cloudfront create-distribution --distribution-config file://distribution-config.json
```

### 既存のディストリビューションの場合
<a name="enable-mtls-cli-existing"></a>

次のコマンド例を使用し、現在のディストリビューション設定を取得します。

```
aws cloudfront get-distribution-config --id E1A2B3C4D5E6F7 --output json > dist-config.json
```

ファイルを編集して mTLS 設定を追加します。次の例のセクションをディストリビューション設定に追加します。

```
"ViewerMtlsConfig": {
    "Mode": "required", 
    "TrustStoreConfig": {
        "TrustStoreId": {TRUST_STORE_ID},
        "AdvertiseTrustStoreCaNames": true,
        "IgnoreCertificateExpiry": true
    }
}
```

ファイルから ETag フィールドを削除しますが、その値は個別に保存します。

次のコマンド例を使用し、新しい設定でディストリビューションを更新します。

```
aws cloudfront update-distribution \
    --id E1A2B3C4D5E6F7 \
    --if-match YOUR-ETAG-VALUE \
    --distribution-config file://dist-config.json
```

## ビューワープロトコルポリシー
<a name="viewer-protocol-policies"></a>

相互 TLS を使用する場合、すべてのディストリビューションキャッシュ動作を HTTPS のみのビューワープロトコルポリシーで設定する必要があります。
+ **HTTP を HTTPS にリダイレクト** - 証明書の検証を実行する前に HTTP リクエストを HTTPS にリダイレクトします。
+ **HTTPS のみ** - HTTPS リクエストのみを受け入れて証明書の検証を実行します。

**注記**  
HTTP 接続では証明書の検証を実行できないため、HTTP および HTTPS ビューワープロトコルポリシーは相互 TLS ではサポートされません。

## 次のステップ
<a name="enable-mtls-next-steps"></a>

CloudFront ディストリビューションでビューワー TLS を有効にしたら、Connection Functions を関連付けてカスタム証明書検証ロジックを実装できます。Connection Functions により、カスタム検証ルール、証明書失効チェック、ログ記録を使用して、組み込み mTLS 認証機能を拡張できます。Connection Functions の作成と関連付けの詳細については、「[CloudFront Connection Function を関連付ける](connection-functions.md)」を参照してください。

# CloudFront Connection Function を関連付ける
<a name="connection-functions"></a>

CloudFront Connection Functions により、TLS ハンドシェイク中にカスタム証明書検証ロジックを実装し、組み込みの mTLS 認証機能を拡張できます。

## Connection Functions とは
<a name="what-are-connection-functions"></a>

Connection Functions は、クライアント証明書の検証後、TLS ハンドシェイク中に実行される JavaScript 関数です。検証されたクライアント証明書は Connection Function に渡され、その時点で Connection Function はアクセスを許可するかどうかをさらに判断します。Connection Functions の詳細については、「[CloudFront Functions を使用してエッジでカスタマイズする](cloudfront-functions.md)」を参照してください。

## Connection Functions と mTLS の連携方法
<a name="how-connection-functions-work"></a>

クライアントが CloudFront ディストリビューションへの mTLS 接続を確立しようとすると、次のシーケンスが発生します。

1. クライアントが CloudFront エッジロケーションで TLS ハンドシェイクを開始します。

1. CloudFront はクライアント証明書をリクエストして受信します。

1. CloudFront は、トラストストアに対して標準証明書検証を実行します。

1. 証明書が標準検証に合格すると、CloudFront は Connection Function を呼び出します。**ViewerMtlsConfig** 内で **IgnoreCertificateExpiry** が有効になっている場合、期限切れ (ただし、他は有効) の証明書も Connection Function に渡されます。クライアント証明書が無効の場合、Connection Functions は呼び出されません。

1. Connection Function は、解析された証明書情報と接続の詳細を受け取ります。

1. 関数は、カスタムロジックに基づいて許可/拒否の決定を行います。

1. CloudFront は、お客様の決定に基づいて TLS 接続を完了または終了します。

Connection Functions は、検証モードとオプションモード (クライアントが証明書を提示する場合) の両方で呼び出されます。

## Connection Function を作成する
<a name="create-connection-function"></a>

CloudFront コンソールまたは CLI AWS を使用して Connection Functions を作成できます。

### Connection Function を作成するには (コンソール)
<a name="create-connection-function-console"></a>

1. AWS マネジメントコンソール にサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. ナビゲーションペインで、[**Functions**] (関数) を選択します。

1. **[Connection Functions]** タブを選択し、**[Connection Functions を作成]** を選択します。

1. AWS アカウント内で一意の関数名を入力します。

1. [**続行**] をクリックしてください。

1. 関数エディタで、証明書検証用の JavaScript コードを記述します。関数ハンドラーは許可または拒否のいずれかを呼び出す必要があります。

1. オプション: KeyValue ストアを Connection Function に関連付けると、失効制御を実装できます。

1. **[Save changes]** (変更の保存) をクリックします。

### Connection Function を作成するには (AWS CLI)
<a name="create-connection-function-cli"></a>

次の例は、Connection Function の作成方法を示しています。

code.js など、関数コードを個別のファイルに記述します。

```
function connectionHandler(connection) {
  connection.allow();
}
```

```
aws cloudfront create-connection-function \
  --name "certificate-validator" \
  --connection-function-config '{
      "Comment": "Client certificate validation function",
      "Runtime": "cloudfront-js-2.0"
  }' \
  --connection-function-code fileb://code.js
```

## Connection Function コードの構造
<a name="connection-function-code-structure"></a>

Connection Functions は、証明書と接続情報を含む接続オブジェクトを受信する connectionHandler 関数を実装します。関数は、接続を決定するために `connection.allow()` または `connection.deny()` を使用する必要があります。

### 基本的な Connection Function の例
<a name="basic-connection-function-example"></a>

次の例は、クライアント証明書のサブジェクトフィールドを検証するシンプルな Connection Function を示しています。

```
function connectionHandler(connection) {
    // Only process if a certificate was presented
    if (!connection.clientCertificate) {
        console.log("No certificate presented");
        connection.deny();
    }
    
    // Check the subject field for specific organization
    const subject = connection.clientCertificate.certificates.leaf.subject;
    if (!subject.includes("O=ExampleCorp")) {
        console.log("Certificate not from authorized organization");
       connection.deny();
    } else {
        // All checks passed
        console.log("Certificate validation passed");
        connection.allow();
    }
}
```

接続オブジェクトで使用できるクライアント証明書プロパティの完全な仕様は、こちらで入手できます。

```
{
  "connectionId": "Fdb-Eb7L9gVn2cFakz7wWyBJIDAD4-oNO6g8r3vXDV132BtnIVtqDA==", // Unique identifier for this TLS connection
  "clientIp": "203.0.113.42", // IP address of the connecting client (IPv4 or IPv6)
  "clientCertificate": {
    "certificates": {
      "leaf": {
        "subject": "CN=client.example.com,O=Example Corp,C=US", // Distinguished Name (DN) of the certificate holder
        "issuer": "CN=Example Corp Intermediate CA,O=Example Corp,C=US", // Distinguished Name (DN) of the certificate authority that issued this certificate
        "serialNumber": "4a:3f:5c:92:d1:e8:7b:6c", // Unique serial number assigned by the issuing CA (hexadecimal)
        "validity": {
          "notBefore": "2024-01-15T00:00:00Z", // Certificate validity start date (ISO 8601 format)
          "notAfter": "2025-01-14T23:59:59Z"   // Certificate expiration date (ISO 8601 format)
        },
        "sha256Fingerprint": "a1b2c3d4e5f6...abc123def456", // SHA-256 hash of the certificate (64 hex characters)
      },
    },
  },
}
```

## Connection Function を関連付ける
<a name="associate-connection-function-section"></a>

Connection Function を作成したらライブステージに発行し、ディストリビューションに関連付ける必要があります。

### Connection Function を発行して関連付けるには (コンソール)
<a name="publish-associate-console"></a>

1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. ナビゲーションペインで、**[関数]** を選択する

1. **[Connection Functions]** タブを選択し、Connection Functions を選択します。

1. **[発行]** を選択して、ライブステージに移動させます。

1. 発行セクションの下にある関連付けられたディストリビューションテーブルの **[関連付けを追加]** を選択します。

1. 関連付けるビューワー mTLS が有効になっているディストリビューションを選択します。

または、発行された Connection Functions をディストリビューションの詳細ページから関連付けることもできます。

1. すべてのディストリビューションが一覧表示されているコンソールのホームページに移動します。

1. 関連付けるディストリビューションを選択します。

1. **[General]** (全般) タブを選択します。

1. **設定** セクションで、**編集** を選択します。

1. **[接続]** セクションで、**ビューワー相互認証 (mTLS)** を検索します。

1. **[Connection Function]** で、関数を選択します。

1. **[Save changes]** (変更の保存) をクリックします。

### Connection Function を関連付けるには (AWS CLI)
<a name="associate-connection-function-cli"></a>

次の例は、Connection Function をディストリビューションに関連付ける方法を示します。

```
// DistributionConfig:
{
   ...other settings,
    "ConnectionFunctionAssociation": {
        "Id": "cf_30c2CV2elHwCoInb3LtcaUJkZeD"
    }
}
```

## Connection Functions のユースケース
<a name="connection-function-use-cases"></a>

Connection Functions は、いくつかの高度な mTLS ユースケースを有効にします。
+ **証明書属性の検証** - 組織単位の要件やサブジェクト代替名パターンなど、クライアント証明書の特定のフィールドを検証します。
+ **証明書失効チェック** - KeyValueStore を使用してカスタム証明書失効チェックを実装し、失効した証明書のシリアル番号を保存します。
+ **IP ベースの証明書ポリシー** - クライアントの IP アドレスまたは地理的制限に基づいて異なる証明書ポリシーを適用します。
+ **マルチテナント検証** - ホスト名または証明書属性に基づいて異なる証明書要件が適用されるテナント固有の検証ルールを実装します。

**注記**  
Connection Functions は、TLS ハンドシェイク中にクライアント接続ごとに 1 回実行されます。  
Connection Functions は接続の許可または拒否のみを行うことができ、HTTP リクエストとレスポンスを変更することはできません。  
ディストリビューションに関連付けることができるのは、ライブステージにある関数 (発行済み) のみです。  
各ディストリビューションに含めることができる Connection Function は、最大 1 つまでです。

## 次のステップ
<a name="connection-function-next-steps"></a>

Connection Function を CloudFront ディストリビューションに関連付けた後、オプションの設定で mTLS 実装の動作をカスタマイズできます。オプションのクライアント証明書検証モードなど、追加設定の詳細な手順については、「[その他の設定](configuring-additional-settings.md)」を参照してください。

# その他の設定
<a name="configuring-additional-settings"></a>

基本的な相互 TLS 認証を有効にした後、追加の設定を構成して、特定のユースケースと要件の認証動作をカスタマイズできます。

## クライアント証明書の検証オプションのモード
<a name="optional-mode"></a>

CloudFront は、提示されたクライアント証明書を検証する代替オプションのクライアント証明書検証モードを提供しますが、証明書を提示しないクライアントへのアクセスを許可します。

### オプションモードの動作
<a name="optional-mode-behavior"></a>
+ 有効な証明書を持つクライアントへの接続を許可します (無効な証明書は拒否されます)。
+ 証明書のないクライアントの接続を許可する
+ 単一のディストリビューションを通じて混合クライアント認証シナリオを許可します。

オプションモードは、mTLS 認証への段階的な移行、証明書を持つクライアントと証明書のないクライアントのサポート、レガシークライアントとの下位互換性の維持に最適です。

**注記**  
オプションモードでは、クライアントが証明書を提示しなくても Connection Functions が呼び出されます。これにより、クライアントの IP アドレスのログ記録や、証明書が提示されるかどうかに基づく異なるポリシーの適用などのカスタムロジックを実装できます。

### オプションモードを設定するには (コンソール)
<a name="configure-optional-mode-console"></a>

1. ディストリビューション設定で、**[全般]** タブに移動し、**[編集]** を選択します。

1. **[接続]** コンテナ内の **[ビューワー相互認証 (mTLS)]** セクションまでスクロールします。

1. **[クライアント証明書の検証モード]** で、**[オプション]** を選択します。

1. 変更の保存。

### オプションモードを設定するには (AWS CLI)
<a name="configure-optional-mode-cli"></a>

次の例は、オプションモードの設定方法を示しています。

```
"ViewerMtlsConfig": {
   "Mode": "optional",
   ...other settings
}
```

## 認証局のアドバタイズ
<a name="ca-advertisement"></a>

AdvertiseTrustStoreCaNames フィールドは、TLS ハンドシェイク中に CloudFront が信頼される CA 名のリストをクライアントに送信するかどうかを制御し、クライアントが該当する証明書を選択するのに役立ちます。

### CA のアドバタイズを設定するには (コンソール)
<a name="configure-ca-advertisement-console"></a>

1. ディストリビューション設定で、**[全般]** タブに移動し、**[編集]** を選択します。

1. **[接続]** コンテナ内の **[ビューワー相互認証 (mTLS)]** セクションまでスクロールします。

1. **[トラストストアの CA 名のアドバタイズ]** チェックボックスをオンまたはオフにします。

1. **[Save changes]** (変更の保存) をクリックします。

### CA アドバタイズを設定するには (AWS CLI)
<a name="configure-ca-advertisement-cli"></a>

次の例は、CA アドバタイズを有効にする方法を示しています。

```
"ViewerMtlsConfig": {
   "Mode": "required", // or "optional"
   "TrustStoreConfig": {
      "AdvertiseTrustStoreCaNames": true,
      ...other settings
   } 
}
```

## 証明書の有効期限の処理
<a name="certificate-expiration-handling"></a>

IgnoreCertificateExpiry プロパティは、CloudFront が期限切れのクライアント証明書に応答する方法を決定します。デフォルトでは、CloudFront は期限切れのクライアント証明書を拒否しますが、必要に応じて受け入れるように設定できます。これは通常、すぐに更新できない期限切れの証明書を持つデバイスに対して有効です。

### 証明書の有効期限の処理を設定するには (コンソール)
<a name="configure-expiration-console"></a>

1. ディストリビューション設定で、**[全般]** タブに移動し、**[編集]** を選択します。

1. **[接続]** コンテナの **[ビューワー相互認証 (mTLS)]** セクションまでスクロールします。

1. **[証明書の有効期限を無視]** チェックボックスを選択または選択解除します。

1. **[Save changes]** (変更の保存) をクリックします。

### 証明書の有効期限の処理を設定するには (AWS CLI)
<a name="configure-expiration-cli"></a>

次の例は、証明書の有効期限を無視する方法を示します。

```
"ViewerMtlsConfig": {
  "Mode": "required", // or "optional"
  "TrustStoreConfig": {
     "IgnoreCertificateExpiry": false,
     ...other settings
  }
}
```

**注記**  
**IgnoreCertificateExpiry** は証明書の有効期限にのみ適用されます。他のすべての証明書検証チェックは引き続き適用されます (信頼チェーン、署名の検証)。

## 次のステップ
<a name="additional-settings-next-steps"></a>

追加の設定を行った後、オリジンに証明書情報を渡すようにヘッダー転送を設定して Connection Functions と KeyValueStore を使用して証明書失効を実装し、モニタリング用の接続ログを有効にすることができます。証明書情報をオリジンに転送する方法の詳細については、[「オリジンへヘッダーを転送する](viewer-mtls-headers.md)」を参照してください。

# オリジンに転送されるキャッシュポリシーの mTLS ヘッダービューワー
<a name="viewer-mtls-headers"></a>

相互 TLS 認証を使用する場合、CloudFront はクライアント証明書から情報を抽出し、HTTP ヘッダーとしてオリジンに転送できます。これにより、オリジンサーバーは証明書の検証ロジックを実装せずに証明書の詳細にアクセスできます。

キャッシュ動作を作成するために、次のヘッダーを使用できます。


| ヘッダー名 | 説明 | 値の例 | 
| --- | --- | --- | 
| CloudFront-Viewer-Cert-Serial-Number | 証明書のシリアル番号の 16 進数表現 | 4a:3f:5c:92:d1:e8:7b:6c | 
| CloudFront-Viewer-Cert-Issuer | 発行者の識別名 (DN) の RFC2253 文字列表現 | CN=rootcamtls.com、OU=rootCA、O=mTLS、L=Seattle、ST=Washington、C=US | 
| CloudFront-Viewer-Cert-Subject | サブジェクトの識別名 (DN) の RFC2253 文字列表現 | CN=client\$1.com、OU=client-3、O=mTLS、ST=Washington、C=US | 
| CloudFront-Viewer-Cert-Present | 証明書が存在するかどうかを示す 1 (存在する) または 0 (存在しない)。この値は、必須モードでは常に 1 です。 | 1 | 
| CloudFront-Viewer-Cert-Sha256 | クライアント証明書の SHA256 ハッシュ | 01fbf94fef5569753420c349f49adbfd80af5275377816e3ab1fb371b29cb586 | 

オリジンリクエストの場合、キャッシュ動作に使用できる上記のヘッダーに加えて、2 つのヘッダーが追加されます。


| ヘッダー名 | 説明 | 値の例 | 
| --- | --- | --- | 
| CloudFront-Viewer-Cert-Validity | notBefore および notAfter date の ISO8601 形式 | CloudFront-Viewer-Cert-Validity: NotBefore=2023-09-21T01:50:17Z;NotAfter=2024-09-20T01:50:17Z | 
| CloudFront-Viewer-Cert-Pem | リーフ証明書の URL エンコードされた PEM 形式 | CloudFront-Viewer-Cert-Pem: -----BEGIN%20CERTIFICATE-----%0AMIIG<...reduced...>NmrUlw%0A-----END%20CERTIFICATE-----%0A | 

## ヘッダー転送を設定する
<a name="configure-header-forwarding"></a>

### コンソール
<a name="configure-headers-console"></a>

検証モードでは、CloudFront はすべてのビューワーリクエストに CloudFront-Viewer-Cert-\$1 ヘッダーを自動的に追加します。これらのヘッダーをオリジンに転送するには

1. メインリストのディストリビューションページから、ビューワー mTLS が有効なディストリビューションを選択し、**[動作]** タブに移動します。

1. キャッシュ動作を選択し、**[編集]** を選択します。

1. **[オリジンのリクエストポリシー]** セクションで、**[ポリシーを作成]** を選択するか、既存のポリシーを選択します。

1. オリジンリクエストポリシーに次のヘッダーが含まれていることを確認します。
   + CloudFront-Viewer-Cert-Serial-Number
   + CloudFront-Viewer-Cert-Issuer
   + CloudFront-Viewer-Cert-Subject
   + CloudFront-Viewer-Cert-Present
   + Cloudfront-Viewer-Cert-Sha256
   + CloudFront-Viewer-Cert-Validity
   + CloudFront-Viewer-Cert-Pem

1. **[作成]** (新しいポリシーの場合) または **[保存]** (既存のポリシーの場合) を選択します。

1. キャッシュ動作内のポリシーを選択し、変更を保存する

### AWS CLI を使用する
<a name="configure-headers-cli"></a>

次の例は、検証モード用の mTLS ヘッダーを含むオリジンリクエストポリシーの作成方法を示しています。

```
aws cloudfront create-origin-request-policy \
  --origin-request-policy-config '{
    "Name": "MTLSHeadersPolicy",
    "HeadersConfig": {
      "HeaderBehavior": "whitelist",
      "Headers": {
        "Quantity": 5,
        "Items": [
          "CloudFront-Viewer-Cert-Serial-Number",
          "CloudFront-Viewer-Cert-Issuer",
          "CloudFront-Viewer-Cert-Subject",
          "CloudFront-Viewer-Cert-Validity",
          "CloudFront-Viewer-Cert-Pem"
        ]
      }
    },
    "CookiesConfig": {
      "CookieBehavior": "none"
    },
    "QueryStringsConfig": {
      "QueryStringBehavior": "none"
    }
  }'
```

## ヘッダー処理に関する考慮事項
<a name="header-processing-considerations"></a>

証明書ヘッダーを使用する場合、次のベストプラクティスを検討してください。
+ **ヘッダーの検証:** オリジンの証明書ヘッダー値を追加のセキュリティ対策として検証する
+ **ヘッダーサイズの制限:** PEM 証明書ヘッダーを大きくすることができます。オリジンサーバーが処理できることを確認してください
+ **キャッシュに関する考慮事項:** キャッシュキーで証明書ヘッダーを使用すると、キャッシュのフラグメント化が進みます
+ **クロスオリジンリクエスト:** アプリケーションが CORS を使用している場合、証明書ヘッダーを許可するように設定する必要がある場合があります

## 次のステップ
<a name="headers-next-steps"></a>

ヘッダー転送を設定したら、CloudFront Connection Functions と KeyValueStore を使用して証明書失効チェックを実装できます。失効チェックの実装の詳細については、「[CloudFront 接続Connection Function と KVS を使用した取り消し](revocation-connection-function-kvs.md)」を参照してください。

# CloudFront 接続Connection Function と KVS を使用した取り消し
<a name="revocation-connection-function-kvs"></a>

CloudFront Connection Functions と KeyValueStore を組み合わせて、相互 TLS 認証に証明書失効チェックを実装できます。このアプローチは、CloudFront の組み込み証明書検証を補完するスケーラブルでリアルタイムの証明書失効メカニズムを提供します。

Connection Functions は、CloudFront エッジロケーションでの TLS 接続の確立中に実行される JavaScript 関数で、mTLS 認証用のカスタム証明書検証ロジックを実装できます。Connection Functions の詳細については、「[CloudFront Connection Function を関連付ける](connection-functions.md)」を参照してください。

## Connection Functions での証明書失効の仕組み
<a name="how-revocation-works"></a>

CloudFront の標準証明書検証は、証明書チェーン、署名、有効期限を検証しますが、組み込みの証明書失効チェックは含みません。Connection Functions を使用すると、TLS ハンドシェイク中にカスタム失効チェックを実装できます。

証明書の失効プロセスは次のように機能します。

1. 失効した証明書のシリアル番号を CloudFront KeyValueStore に保存します。

1. クライアントが証明書を提示すると、Connection Function が呼び出されます。

1. 関数は、証明書のシリアル番号と KeyValueStore を照合します。

1. シリアル番号がストアで見つかった場合、証明書は失効しています。

1. 関数は、失効した証明書の接続を拒否します。

このアプローチは、CloudFront のグローバルエッジネットワーク全体でほぼリアルタイムの失効チェックを提供します。

## 失効した証明書の KeyValueStore を設定する
<a name="setup-kvs-revoked-certs"></a>

まず、失効した証明書のシリアル番号を保存する KeyValueStore を作成します。

### KeyValueStore を作成するには (コンソール)
<a name="create-kvs-console"></a>

1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. ナビゲーションペインで、**[キーバリューストア]** を選択します。

1. **[キーバリューストアを作成]** を選択します。

1. キーバリューストアを作成の名前を入力します (revoked-certificates など)。

1. (オプション) 説明を入力します。

1. **[キーバリューストアを作成]** を選択します。

### KeyValueStore を作成するには (AWS CLI)
<a name="create-kvs-cli"></a>

次の例は、KeyValueStore を作成する方法を示します。

```
aws cloudfront create-key-value-store \
  --name "revoked-certificates" \
  --comment "Store for revoked certificate serial numbers"
```

## 失効した証明書のシリアル番号をインポートする
<a name="import-revoked-serials"></a>

KeyValueStore を作成した後、失効した証明書のシリアル番号をインポートする必要があります。

### 失効データを準備する
<a name="prepare-revocation-data"></a>

失効した証明書のシリアル番号を使用して JSON ファイルを作成します。

```
{
  "data": [
    {
      "key": "ABC123DEF456",
      "value": ""
    },
    {
      "key": "789XYZ012GHI",
      "value": ""
    }
  ]
}
```

### S3 からのインポート
<a name="import-from-s3"></a>

1. S3 バケットに JSON ファイルをアップロードする

1. ファイルを KeyValueStore にインポートします。

   ```
   aws cloudfront create-key-value-store \
     --name "revoked-certificates" \
     --import-source '{
       "SourceType": "S3",
       "SourceARN": "arn:aws:s3:::amzn-s3-demo-bucket1/revoked-serials.json"
     }'
   ```

## 失効チェックの Connection Function を作成する
<a name="create-revocation-connection-function"></a>

証明書のシリアル番号と KeyValueStore を照合する Connection Function を作成します。

### Connection Function のコード例
<a name="revocation-function-example"></a>

次の例は、証明書失効チェックを実行する Connection Function を示します。

```
import cf from 'cloudfront';

async function connectionHandler(connection) {
    const kvsHandle = cf.kvs();
    
    // Get client certificate serial number
    const clientSerialNumber = connection.clientCertificate.certificates.leaf.serialNumber;
    
    // Check if the serial number exists in the KeyValueStore
    const isRevoked = await kvsHandle.exists(clientSerialNumber.replaceAll(':', ''));
    
    if (isRevoked) {
        console.log(`Certificate ${clientSerialNumber} is revoked. Denying connection.`);
        connection.logCustomData(`REVOKED:${clientSerialNumber}`);
        connection.deny();
    } else {
        console.log(`Certificate ${clientSerialNumber} is valid. Allowing connection.`);
        connection.allow();
    }
    
}
```

### Connection Function を作成するには (AWS CLI)
<a name="create-revocation-function-cli"></a>

次の例は、Connection Function と KeyValueStore の関連付けを作成方法を示します。

```
aws cloudfront create-connection-function \
  --name "revocation-checker" \
  --connection-function-config '{
      "Comment": "Certificate revocation checking function",
      "Runtime": "cloudfront-js-2.0",
      "KeyValueStoreAssociations": {
          "Quantity": 1,
          "Items": [
              {
                  "KeyValueStoreARN": "arn:aws:cloudfront::123456789012:key-value-store/revoked-certificates"
              }
          ]
      }
  }' \
  --connection-function-code fileb://revocation-checker.js
```

## 関数をディストリビューションに関連付ける
<a name="associate-revocation-function"></a>

Connection Function を作成して公開した後、「[CloudFront Connection Function を関連付ける](connection-functions.md)」セクションの説明に従って、mTLS 対応の CloudFront ディストリビューションに関連付けます。

# 接続ログを使用したオブザーバビリティ
<a name="connection-logs"></a>

CloudFront 接続ログは相互 TLS 認証イベントを詳細に可視化するため、証明書の検証のモニタリング、接続試行の追跡、認証問題のトラブルシューティングを行うことができます。

## 接続ログとは
<a name="what-are-connection-logs"></a>

接続ログは、相互 TLS 対応ディストリビューションの TLS ハンドシェイクと証明書の検証に関する詳細情報をキャプチャします。HTTP リクエスト情報を記録する標準アクセスログとは異なり、接続ログは、以下を含む TLS 接続確立フェーズに特に重点を置いています。
+ 接続ステータス (成功/失敗)
+ クライアント証明書の詳細
+ TLS プロトコルと暗号情報
+ 接続タイミングのメトリクス
+ Connection Functions からのカスタムデータ

これらのログは、証明書ベースの認証イベントを包括的に可視化し、セキュリティのモニタリング、問題のトラブルシューティングを行い、コンプライアンス要件を満たすのに役立ちます。

## 接続ログを有効にする
<a name="enable-connection-logs"></a>

接続ログは、相互 TLS 認証が有効になっているディストリビューションでのみ利用可能です。CloudWatch Logs、Amazon Data Firehose、Amazon S3 など、複数の宛先に接続ログを送信できます。

### 前提条件
<a name="connection-logs-prerequisites"></a>

接続ログを有効にする前に
+ CloudFront ディストリビューションの相互 TLS を設定します
+ CloudFront ディストリビューションの接続ログを有効にします
+ 選択したログ記録先に必要なアクセス許可があることを確認します
+ クロスアカウント配信の場合、適切な IAM ポリシーを設定します

### 接続ログを有効にするには (コンソール)
<a name="enable-connection-logs-console"></a>

1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. ディストリビューションリストから、mTLS 対応ディストリビューションを選択します。

1. **[Logging]** (ログ) タブを選択します。

1. **[Add]** (追加) を選択します。

1. ログを受信するサービスを選択します。
   + **CloudWatch Logs**
   + **Firehose** – 
   + **Amazon S3**

1. **[送信先]** で、選択したサービスのリソースを選択します。
   + CloudWatch Logs の場合は、**[ロググループ名]** に入力します。
   + Firehose の場合、**[Firehose 配信ストリーム]** を選択します。
   + Amazon S3 の場合、**[バケット名]** を入力します (オプションでプレフィックスを使用)。

1. (オプション) 追加の設定を行います。
   + **フィールドの選択:** 含める特定のログフィールドを選択します。
   + **出力形式:** JSON、プレーン、w3c、Raw、または Parquet (S3 のみ) から選択します。
   + **フィールド区切り文字:** ログフィールドを区切る方法を指定します。

1. **[変更を保存]** を選択します。

### 接続ログを有効にするには (AWS CLI)
<a name="enable-connection-logs-cli"></a>

次の例は、CloudWatch API を使用して接続ログを有効にする方法を示します。

```
# Step 1: Create a delivery source
aws logs put-delivery-source \
  --name "cf-mtls-connection-logs" \
  --resource-arn "arn:aws:cloudfront::123456789012:distribution/E1A2B3C4D5E6F7" \
  --log-type CONNECTION_LOGS

# Step 2: Create a delivery destination
aws logs put-delivery-destination \
  --name "s3-destination" \
  --delivery-destination-configuration \
  "destinationResourceArn=arn:aws:s3:::amzn-s3-demo-bucket1"

# Step 3: Create the delivery
aws logs create-delivery \
  --delivery-source-name "cf-mtls-connection-logs" \
  --delivery-destination-arn "arn:aws:logs:us-east-1:123456789012:delivery-destination:s3-destination"
```

**注記**  
CloudWatch API を使用する場合、他のリージョンにログを配信する場合でも、米国東部 (バージニア北部) リージョン (us-east-1) を指定する必要があります。

## 接続ログのフィールド
<a name="connection-log-fields"></a>

接続ログには、各 TLS 接続試行に関する詳細情報が含まれます。


| フィールド | 説明 | 例 | 
| --- | --- | --- | 
| eventTimestamp | 接続が確立または失敗したときの ISO 8601 タイムスタンプ | 1731620046814 | 
| connectionId | TLS 接続の一意の識別子 | oLHiEKbQSn8lkvJfA3D4gFowK3\$1iZ0g4i5nMUjE1Akod8TuAzn5nzg== | 
| connectionStatus |  mTLS 接続試行のステータス。  | Success-または-Failed | 
| clientIp | 接続しているクライアントの IP アドレス | 2001:0db8:85a3:0000:0000:8a2e:0370:7334 | 
| clientPort | クライアントが使用するポート | 12137 | 
| serverIp | CloudFront エッジサーバーの IP アドレス | 99.84.71.136 | 
| distributionId | CloudFront ディストリビューション ID | E2DX1SLDPK0123 | 
| distributionTenantId | CloudFront ディストリビューションテナント ID (該当する場合) | dt\$12te1Ura9X3R2iCGNjW123 | 
| tlsProtocol | 使用されている TLS プロトコルバージョン | TLSv1.3 | 
| tlsCipher | 接続に使用される TLS 暗号スイート | TLS\$1AES\$1128\$1GCM\$1SHA256 | 
| tlsHandshakeDuration | TLS ハンドシェイクの期間 (ミリ秒単位) | 153 | 
| tlsSni | TLS ハンドシェイクからの Server Name Indication の値 | d111111abcdef8.cloudfront.net | 
| clientLeafCertSerialNumber | クライアントの証明書のシリアル番号 | 00:b1:43:ed:93:d2:d8:f3:9d | 
| clientLeafCertSubject | クライアントの証明書のサブジェクトフィールド | C=US, ST=WA, L=Seattle, O=Amazon.com, OU=CloudFront, CN=client.test.mtls.net | 
| clientLeafCertIssuer | クライアントの証明書の発行者フィールド | C=US, ST=WA, L=Seattle, O=Amazon.com, OU=CloudFront, CN=test.mtls.net | 
| clientLeafCertValidity | クライアントの証明書の有効期間 | NotBefore=2025-06-05T23:28:21Z;NotAfter=2125-05-12T23:28:21Z | 
| connectionLogCustomData | Connection Functions を介して追加されたカスタムデータ | REVOKED:00:b1:43:ed:93:d2:d8:f3:9d | 

## 接続エラーコード
<a name="connection-error-codes"></a>

```
Failed:ClientCertMaxChainDepthExceeded
Failed:ClientCertMaxSizeExceeded
Failed:ClientCertUntrusted
Failed:ClientCertNotYetValid
Failed:ClientCertExpired
Failed:ClientCertTypeUnsupported
Failed:ClientCertInvalid
Failed:ClientCertIntentInvalid
Failed:ClientCertRejected
Failed:ClientCertMissing
Failed:TcpError
Failed:TcpTimeout
Failed:ConnectionFunctionError
Failed:ConnectionFunctionDenied
Failed:Internal
Failed:UnmappedConnectionError
```

接続が失敗すると、CloudFront は特定の理由コードを記録します。


| コード | 説明 | 
| --- | --- | 
| ClientCertMaxChainDepthExceeded | 証明書チェーンの最大深度を超えました | 
| ClientCertMaxSizeExceeded | 最大証明書サイズを超えました | 
| ClientCertUntrusted | 証明書は信頼されていません | 
| ClientCertNotYetValid | 証明書はまだ有効ではありません | 
| ClientCertExpired | 証明書の有効期限が切れています | 
| ClientCertTypeUnsupported | 証明書のタイプがサポートされていません | 
| ClientCertInvalid | 証明書が無効です | 
| ClientCertIntentInvalid | 証明書のインテントが無効です | 
| ClientCertRejected | カスタム検証によって拒否された証明書 | 
| ClientCertMissing | 証明書がありません | 
| TcpError |  接続確立の試行中にエラーが発生しました  | 
| TcpTimeout |  タイムアウト期間内に接続を確立できませんでした  | 
| ConnectionFunctionError |  Connection Function の実行中に、キャッチされない例外がスローされました  | 
| 内部 |  内部サービスエラーが発生しました。  | 
| UnmappedConnectionError |  他のいずれのカテゴリにも該当しないエラーが発生しました  | 

# オリジンの相互 TLS と CloudFront
<a name="origin-mtls-authentication"></a>

相互 TLS 認証 (相互 Transport Layer Security 認証 - mTLS) は、双方向証明書ベースの認証を要求することで標準 TLS 認証を拡張するセキュリティプロトコルです。クライアントとサーバーの両方が、安全な接続を確立する前に ID を証明する必要があります。

## ビューワー mTLS とオリジン mTLS
<a name="viewer-mtls-vs-origin-mtls"></a>

相互認証 (mTLS) は、ビューワーと CloudFront ディストリビューション間 (ビューワー mTLS) または CloudFront ディストリビューションとオリジン間 (オリジン mTLS) で有効にできます。このドキュメントは、オリジン mTLS 設定に関するものです。ビューワーの mTLS 設定については、「[CloudFront による相互 TLS 認証 (Viewer mTLS)オリジンの相互 TLS と CloudFront](mtls-authentication.md)」を参照してください。

オリジンの mTLS により、CloudFront はクライアント証明書を使用してオリジンサーバーに対して自身を認証できます。オリジンの mTLS を使用すると、承認された CloudFront ディストリビューションのみがアプリケーションサーバーとの接続を確立できるようにすることができ、不正なアクセスの試みから保護できます。

**注記**  
オリジンの mTLS 接続では、CloudFront はクライアントとして機能し、TLS ハンドシェイク中にクライアント証明書をオリジンサーバーに提示します。CloudFront はクライアント証明書の有効性または失効ステータスの検証を実行しません。これはオリジンサーバーの責任です。セキュリティ要件に従って、クライアント証明書をトラストストアに対して検証し、証明書の有効期限を確認し、失効チェック (CRL や OCSP 検証など) を実行するように、オリジンインフラストラクチャを設定する必要があります。CloudFront の役割は証明書の提示に制限されており、すべての証明書検証ロジックとセキュリティポリシーはオリジンサーバーによって適用されます。

## 仕組み
<a name="how-origin-mtls-works"></a>

CloudFront とオリジン間の標準 TLS ハンドシェイクでは、オリジンサーバーのみが CloudFront に ID を証明する証明書を提示します。オリジンの mTLS では、認証プロセスは双方向になります。CloudFront がオリジンサーバーに接続しようとすると、CloudFront は TLS ハンドシェイク中にクライアント証明書を提示します。オリジンサーバーは、安全な接続を確立する前に、この証明書をトラストストアと照合して検証します。

## ユースケース
<a name="origin-mtls-use-cases"></a>

オリジンの mTLS は、従来の認証方法では運用上のオーバーヘッドが発生するいくつかの重要なセキュリティシナリオに対処します。
+ **ハイブリッドおよびマルチクラウドセキュリティ** - CloudFront と AWS の外でホストされているオリジン、または AWS 上のパブリックオリジン間の接続を保護できます。これにより、IP 許可リストまたはカスタムヘッダーソリューションを管理する必要がなくなり、AWS、オンプレミスのデータセンター、サードパーティープロバイダー間で一貫した証明書ベースの認証が提供されます。分散インフラストラクチャを運用するメディア企業、小売業者、企業は、インフラストラクチャ全体で標準化されたセキュリティコントロールを活用できます。
+ **B2B API とバックエンドのセキュリティ** - CloudFront のパフォーマンス上の利点を維持しながら、バックエンド API とマイクロサービスを直接アクセスの試みから保護できます。認証要件が厳しい SaaS プラットフォーム、支払い処理システム、エンタープライズアプリケーションでは、API リクエストが承認された CloudFront ディストリビューションからのみ送信されていることを確認し、中間者攻撃や不正アクセスの試みを防ぐことができます。

## 重要: オリジンサーバーの要件
<a name="important-origin-server-requirements"></a>

オリジンの mTLS では、相互 TLS 認証をサポートするようにオリジンサーバーを設定する必要があります。オリジンインフラストラクチャには、次の機能が必要です。
+ TLS ハンドシェイク中のクライアント証明書のリクエストと検証
+ CloudFront のクライアント証明書を発行した認証局証明書を含むトラストストアの維持
+ 相互 TLS 接続イベントのログ記録とモニタリング
+ 証明書検証ポリシーの管理と認証の失敗の処理

CloudFront はクライアント側の証明書の提示を処理しますが、オリジンサーバーにはこれらの証明書を検証し、相互 TLS 接続を管理する責任があります。CloudFront でオリジンの mTLS を有効にする前に、オリジンインフラストラクチャが正しく設定されていることを確認します。

## 開始方法
<a name="how-origin-mtls-getting-started"></a>

CloudFront でオリジンの mTLS を実装するには、AWS Certificate Manager でクライアント証明書をインポートし、相互 TLS を要求するようにオリジンサーバーを設定し、CloudFront ディストリビューションでオリジンの mTLS を有効にする必要があります。以下のセクションでは、各設定タスクの詳細な手順について説明します。

**Topics**
+ [ビューワー mTLS とオリジン mTLS](#viewer-mtls-vs-origin-mtls)
+ [仕組み](#how-origin-mtls-works)
+ [ユースケース](#origin-mtls-use-cases)
+ [重要: オリジンサーバーの要件](#important-origin-server-requirements)
+ [開始方法](#how-origin-mtls-getting-started)
+ [AWS Certificate Manager による証明書管理](origin-certificate-management-certificate-manager.md)
+ [CloudFront ディストリビューションのオリジンの相互 TLS を有効にする](origin-enable-mtls-distributions.md)
+ [オリジンの相互 TLS で CloudFront Functions を使用する](origin-mtls-cloudfront-functions.md)

# AWS Certificate Manager による証明書管理
<a name="origin-certificate-management-certificate-manager"></a>

[AWS Certificate Manager (ACM)](https://aws.amazon.com/certificate-manager/) は、オリジンの相互 TLS 認証中に CloudFront がオリジンサーバーに提示するクライアント証明書を保存します。

## 認証局のサポート
<a name="origin-ca-support"></a>

CloudFront のオリジンの mTLS では、TLS クライアント認証に拡張キー使用法 (EKU) を備えたクライアント証明書が必要です。この要件により、認証局から証明書を発行して AWS Certificate Manager にインポートする必要があります。ACM の自動証明書プロビジョニングおよび更新機能は、オリジンの mTLS クライアント証明書では使用できません。CloudFront のオリジンの mTLS は、次の 2 つのソースからのクライアント証明書をサポートしています。
+ **AWS Private Certificate Authority:** 拡張キー使用法フィールドの TLS クライアント認証を含む証明書テンプレート (EndEntityClientAuthCertificate テンプレートなど) を使用して、AWS プライベート CA から証明書を発行できます。AWS プライベート CA から証明書を発行したら、米国東部 (バージニア北部) リージョン (us-east-1) の ACM にインポートする必要があります。このアプローチにより、AWS プライベート CA のセキュリティ上の利点が得られると同時に、証明書のライフサイクル管理を制御できるようになります。
+ **サードパーティーのプライベート認証局:** 既存のプライベート認証局インフラストラクチャから証明書を発行し、ACM にインポートすることもできます。これにより、CloudFront のオリジンの mTLS 機能を活用しながら、現在の証明書管理プロセスを維持できます。証明書には、拡張キー使用法フィールドに TLS クライアント認証を含める必要があり、証明書、プライベートキー、証明書チェーンを含む PEM 形式である必要があります。

**重要**  
AWS プライベート CA とサードパーティー CA の両方について、証明書の有効期限をモニタリングし、有効期限が切れる前に更新された証明書を ACM にインポートするのはお客様の責任でｋす。ACM の自動更新機能は、オリジンの mTLS に使用されるインポートされた証明書には適用されません。

## 証明書の要件と仕様
<a name="origin-certificate-requirements"></a>

### クライアント証明書の要件
<a name="origin-ca-cert-format-requirements"></a>
+ **形式:** PEM (Privacy Enhanced Mail) 形式
+ **コンポーネント:** 証明書、秘密キー、および証明書チェーン
+ **証明書チェーンの最大深度:** 3 (リーフ証明書 \$1 中間証明書 \$1 ルート証明書)
+ **証明書チェーンの最大サイズ:** 64 KB
+ **証明書サイズ:** 96 KB を超えることはできません
+ **最大プライベートキーサイズ:** 5 KB (ACM 制限)
+ **CloudFront ディストリビューションの作成または更新 API コールごとに、追加または変更できる一意のオリジン mTLS 証明書 ARN の最大数:** 5
+ **リージョン:** 証明書は、米国東部 (バージニア北部) リージョン (us-east-1) の ACM に保存する必要があります

### サポートされている証明書の仕様
<a name="origin-supported-cert-specs"></a>
+ **証明書タイプ:** X.509v3
+ **パブリックキーアルゴリズム:**
  + RSA: 2048 ビット
  + ECDSA: P-256
+ **署名アルゴリズム:**
  + SHA256, SHA384, SHA512 with RSA
  + SHA256, SHA384, SHA512 with ECDSA
  + SHA256, SHA384, SHA512 with RSASSA-PSS with MGF1
+ **拡張キー使用法 (必須):** 証明書には、TLS クライアント認証に設定された拡張キー使用法 (EKU) 拡張機能が必要であり、mTLS の目的で承認されていることを確認する必要があります。

### サーバー証明書の要件
<a name="origin-server-certificate-requirements"></a>

オリジンサーバーは、相互 TLS ハンドシェイク中に、パブリックに信頼された認証局からの証明書を提示する必要があります。オリジンサーバー証明書の要件の詳細については、「[CloudFront で SSL/TLS 証明書を使用するための要件](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-custom-origin.html#using-https-cloudfront-to-origin-certificate)」を参照してください。

### 証明書のリクエストまたはインポート
<a name="origin-request-import-certificate"></a>

オリジンの mTLS を有効にする前に、ACM で利用可能なクライアント証明書が必要です。

#### AWS プライベート CA からの証明書のリクエストとインポート
<a name="request-certificate-aws-private-ca"></a>

前提条件:
+ AWS アカウントで設定されたプライベート認証局
+ AWS Private CA から証明書を発行するアクセス許可
+ 証明書を ACM にインポートするアクセス許可
+ ユースケースに適した `Extended key usage:TLS web client authentication` を備えた[証明書テンプレート](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html) ARN
+ OpenSSL、AWS CLI、jq (JSON の解析用) をインストールします。

##### PCA から証明書をリクエストして ACM にインポートするには (AWS CLI)
<a name="request-certificate-cli"></a>

1. 再利用しやすいように、変数にプライベート CA ARN を設定します。

   ```
   PCA_ARN="arn:aws:acm-pca:region:account:certificate-authority/12345678..."
   ```

1. OpenSSL を使用して ECDSA P-256 プライベートキー (prime256v1 曲線) と証明書署名リクエスト (CSR) を生成し、ACM インポートに必要なプライベートキーを暗号化しないままにするために -nodes フラグが使用されていることを確認します。

   ```
   openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes \
       -keyout private.key \
       -out request.csr \
       -subj "/CN=client.example.com"
   ```

1. CSR を AWS プライベート CA に送信して証明書を発行すると、新しく発行された証明書の ARN が返されます。

   ```
   CERT_ARN=$(aws acm-pca issue-certificate \
       --certificate-authority-arn "$PCA_ARN" \
       --csr fileb://request.csr \
       --signing-algorithm "SHA256WITHECDSA" \
       --validity Value=365,Type="DAYS" \
       --template-arn arn:aws:acm-pca:::template/EndEntityCertificate/V1 \
       --query 'CertificateArn' --output text)
   ```

1. リーフ証明書とチェーンの両方を返す get-certificate コマンドを使用して AWS PCA から証明書バンドルを取得し、jq を使用してそれらを個別のファイルに分離します。

   ```
   # Retrieve the full certificate bundle in JSON format
   aws acm-pca get-certificate \
       --certificate-authority-arn "$PCA_ARN" \
       --certificate-arn "$CERT_ARN" \
       --output json > full_cert.json
   
   # Split into Leaf and Chain
   jq -r '.Certificate' full_cert.json > leaf_cert.pem
   jq -r '.CertificateChain' full_cert.json > cert_chain.pem
   ```

1. CLI でバイナリファイルデータを正しく処理するには、fileb:// プロトコルを使用して、暗号化されていないプライベートキー、リーフ証明書、証明書チェーンを AWS ACM にインポートします。

   ```
   aws acm import-certificate \
       --certificate fileb://leaf_cert.pem \
       --private-key fileb://private.key \
       --certificate-chain fileb://cert_chain.pem \
       --region us-east-1 \
       --query 'CertificateArn' \
       --output text
   ```

#### サードパーティーの CA から証明書をインポートする
<a name="import-certificate-third-party-ca"></a>

前提条件:
+ 認証局からの証明書、暗号化されていないプライベートキー、証明書チェーン (PEM 形式)
+ 証明書には、TLS クライアント認証の拡張キー使用法が含まれている必要があります
+ 証明書を ACM にインポートするアクセス許可

##### ACM に証明書をインポートするには (AWS CLI)
<a name="import-certificate-cli"></a>

```
aws acm import-certificate \
  --certificate fileb://certificate.pem \
  --private-key fileb://private-key.pem \
  --certificate-chain fileb://certificate-chain.pem \
  --region us-east-1 \
  --query 'CertificateArn' \
  --output text
```

#### 次のステップ
<a name="certificate-next-steps"></a>

ACM でクライアント証明書を取得またはインポートした後、相互 TLS 認証を要求するようにオリジンサーバーを設定し、CloudFront ディストリビューションでオリジンの mTLS を有効にすることができます。CloudFront でオリジンの mTLS を有効にする手順については、次のセクション「CloudFront ディストリビューションのオリジンの相互 TLS を有効にする」を参照してください。

# CloudFront ディストリビューションのオリジンの相互 TLS を有効にする
<a name="origin-enable-mtls-distributions"></a>

AWS Certificate Manager を使用してクライアント証明書を取得し、相互 TLS を要求するようにオリジンサーバーを設定したら、CloudFront ディストリビューションでオリジンの mTLS を有効にできます。

## 前提条件と要件
<a name="origin-mtls-prerequisites-requirements"></a>

CloudFront ディストリビューションでオリジンの mTLS を有効にする前に、以下を確認してください。
+ 米国東部 (バージニア北部) リージョン (us-east-1) の AWS Certificate Manager に保存されているクライアント証明書
+ 相互 TLS 認証を要求し、クライアント証明書を検証するように設定されたオリジンサーバー
+ パブリックに信頼された認証局からの証明書を提示するオリジンサーバー
+ CloudFront ディストリビューションを変更するためのアクセス許可
+ オリジンの mTLS は、ビジネス、プレミアムプラン、または従量制料金プランでのみ使用できます。

**注記**  
オリジンの mTLS は、カスタムオリジン (AWS の外部でホストされているオリジンを含む) と、Application Load Balancer や API Gateway などの相互 TLS をサポートする AWS オリジンに対して設定できます。

**重要**  
以下の CloudFront 機能は、オリジンの mTLS ではサポートされていません。  
**gRPC トラフィック:** gRPC プロトコルは、オリジンの mTLS が有効になっているオリジンではサポートされていません
**WebSocket 接続:** WebSocket プロトコルは、オリジンの mTLS が有効になっているオリジンではサポートされていません
**VPC オリジン:** オリジンの mTLS は VPC オリジンでは使用できません
**Lambda@Edge を使用したオリジンリクエストとオリジンレスポンスのトリガー:** オリジンリクエストとオリジンレスポンスの位置にある Lambda@Edge 関数は、オリジンの mTLS ではサポートされていません
**埋め込み POP:** 埋め込み POP ではオリジンの mTLS はサポートされていません

## オリジンの mTLS を有効にする
<a name="origin-enable-mtls-per-origin"></a>

オリジンごとの設定では、同じディストリビューション内のオリジンごとに異なるクライアント証明書を指定できます。このアプローチは、オリジンごとに認証要件が異なる場合に最大限の柔軟性を提供します。

### 新しいディストリビューションの場合 (コンソール)
<a name="origin-enable-mtls-new-distributions"></a>

1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. **[ディストリビューションを作成]** を選択します。

1. 料金プランを選択します。**[ビジネス]** プラン、**[プレミアム]** プラン、**[従量制料金]** プランのいずれかを選択します (無料プランではオリジンの mTLS を利用できません)。

1. オリジン設定セクションで、オリジンタイプをその他として選択します

1. **[オリジン設定]** セクションで、**[オリジン設定のカスタマイズ]** を選択します

1. 最初のオリジン (ドメイン名、プロトコルなど) を設定します

1. オリジン設定で、**[mTLS]** を検索します。

1. **[mTLS]** をオンに切り替える

1. **[クライアント証明書]** の場合は、AWS Certificate Manager から証明書を選択します

1. (オプション) 独自のオリジンの mTLS 設定を持つオリジンを追加します

1. 残りのディストリビューション設定を完了し、**[ディストリビューションを作成する]** を選択します。

### 既存のディストリビューションの場合 (コンソール)
<a name="origin-enable-mtls-existing-distributions"></a>

1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. ディストリビューションリストから、変更するディストリビューションを選択します。(注: ディストリビューションが **[プロ、プレミアム、または従量制料金]** の料金プランになっていることを確認します。そうでない場合は、オリジンの mTLS を有効にする前に料金プランをアップグレードする必要があります)

1. **[オリジン]** タブを選択します

1. 設定するオリジンを選択し、**[編集]** を選択します

1. オリジン設定で、**[mTLS]** を検索します。

1. **[mTLS]** をオンに切り替える

1. **[クライアント証明書]** の場合は、AWS Certificate Manager から証明書を選択します。(注: EKU (拡張キー使用法) プロパティが「TLS クライアント認証」に設定されているクライアント証明書のみが一覧表示されます)

1. **[変更を保存]** を選択します。

1. 必要に応じて、追加のオリジンに対して繰り返します。

## AWS CLI を使用する
<a name="origin-enable-mtls-cli"></a>

オリジンごとの設定では、各オリジンの設定内でオリジンの mTLS 設定を指定します。

```
{
  "Origins": {
    "Quantity": 2,
    "Items": [
      {
        "Id": "origin-1",
        "DomainName": "api.example.com",
        "CustomOriginConfig": {
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only"
        },
        "OriginMtlsConfig": {
          "ClientCertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/cert-1"
        }
      },
      {
        "Id": "origin-2",
        "DomainName": "backend.example.com",
        "CustomOriginConfig": {
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only"
        },
        "OriginMtlsConfig": {
          "CertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/cert-2"
        }
      }
    ]
  }
}
```

**注記**  
サーバーがクライアント証明書を要求しない場合、CloudFront はクライアント証明書を提供しないため、接続を正常に続行できます。

## 次のステップ
<a name="origin-enable-mtls-next-steps"></a>

CloudFront ディストリビューションでオリジンの mTLS を有効にした後、CloudFront アクセスログを使用して認証イベントをモニタリングできます。

# オリジンの相互 TLS で CloudFront Functions を使用する
<a name="origin-mtls-cloudfront-functions"></a>

CloudFront Functions は、エッジでの軽量なサーバーレスコンピューティングを提供し、コンテンツ配信をカスタマイズします。CloudFront Functions でオリジンの相互 TLS を使用する場合、オリジンの選択と操作に関して注意すべき特定の動作と制限があります。

## サポートされている CloudFront Functions オペレーション
<a name="supported-cloudfront-functions-operations"></a>

CloudFront Functions は、次の方法で mTLS が有効なオリジンとやり取りできます。

### updateRequestOrigin()
<a name="update-request-origin-function"></a>

updateRequestOrigin() 関数は、mTLS が有効なオリジンを使用するときに、制限された変更をサポートしています。
+ **オリジンの mTLS のオリジン間の切り替え:** 両方のオリジンが同じ**クライアント証明書**を使用する場合、リクエストを更新して、オリジンの mTLS を使用する別のオリジンにルーティングできます。これにより、相互 TLS 認証を維持しながら、カスタムルーティングロジックを実装できます。
+ **オリジンの mTLS の無効化:** 関数で `mTLSConfig: 'off'` を設定することで、mTLS が有効なオリジンから mTLS を使用しないオリジンに切り替えることができます。これにより、リクエストの特性に基づいて相互 TLS 認証を条件付きで無効にする柔軟性が得られます。

#### 例: 同じ証明書を持つオリジンの mTLS オリジン間の切り替え
<a name="example-switching-mtls-origins"></a>

```
function handler(event) {
    var request = event.request;

    // Route to different origin based on request path
    if (request.uri.startsWith('/api/v2')) {
        request.origin = {
            domainName: 'api-v2.example.com',
            customHeaders: {},
            // Both origins must use the same certificate
        };
    }

    return request;
}
```

#### 例: 条件付きでオリジンの mTLS を無効にする
<a name="example-disabling-mtls"></a>

```
function handler(event) {
    var request = event.request;

    // Disable mTLS for specific paths
    if (request.uri.startsWith('/public')) {
        request.origin = {
            domainName: 'public-origin.example.com',
            customHeaders: {},
            mTLSConfig: 'off'
        };
    }

    return request;
}
```

## サポートされていない CloudFront Functions オペレーション
<a name="unsupported-cloudfront-functions-operations"></a>

次の CloudFront Functions オペレーションは、mTLS が有効なオリジンを一般提供でサポートしていません。

### selectRequestOriginById()
<a name="select-request-origin-by-id-function"></a>

`selectRequestOriginById()` 関数は、オリジンの mTLS が有効になっているオリジンを選択できません。この関数を使用して mTLS が有効なオリジンを選択しようとすると、検証エラーが発生します。

ユースケースでオリジンの mTLS を使用した動的オリジン選択が必要な場合は、代わりに `updateRequestOrigin()` を使用し、すべてのターゲットオリジンが同じクライアント証明書を使用していることを確認します。

### createRequestOriginGroup()
<a name="create-request-origin-group-function"></a>

`createRequestOriginGroup()` 関数は、mTLS が有効なオリジンを含むオリジングループの作成をサポートしていません。オリジンの mTLS のオリジンを持つオリジングループは、CloudFront Functions を介して動的に作成することはできません。

オリジンの mTLS でオリジンフェイルオーバー機能が必要な場合は、関数で動的に作成するのではなく、CloudFront ディストリビューション設定でオリジングループを直接設定します。

# 署名付き URL と署名付き Cookie を使用したプライベートコンテンツを提供する
<a name="PrivateContent"></a>

インターネット経由でコンテンツを配信する多くの企業が、選ばれたユーザー (料金を支払っているユーザーなど) のドキュメント、ビジネスデータ、メディアストリーム、またはコンテンツに対して、アクセスを制限する必要があると考えています。CloudFront を使用してこのプライベートコンテンツを安全に供給するには、以下の方法を使用できます。
+ 特別な CloudFront 署名付き URL または署名付き Cookie を使用してプライベートコンテンツにアクセスするようユーザーに要求します。
+ オリジンサーバー (Amazon S3 やプライベート HTTPサーバーなど) 上のコンテンツに直接アクセスするURLではなく、CloudFront の URLを使用してコンテンツにアクセスするようユーザーに要求します。CloudFront URL を要求する必要はありませんが、ユーザーが署名付き URL や署名付き Cookie で指定された制限をバイパスすることを防ぐため、この方法をお勧めします。

詳細については、「[ファイルへのアクセスを制限する](private-content-overview.md)」を参照してください。

## プライベートコンテンツを提供する方法
<a name="private-content-task-list"></a>

プライベートコンテンツを供給するように CloudFront を構成するには、以下のタスクを実行します。

1. (オプション。ただし、推奨) ユーザーが CloudFront 経由でのみコンテンツにアクセスするようにします。使用する方法は、Amazon S3 を使用するかカスタムオリジンを使用するかによって異なります。
   + **Amazon S3** – 「[Amazon S3 オリジンへのアクセスを制限する](private-content-restricting-access-to-s3.md)」を参照してください。
   + **カスタムオリジン** – 「[カスタムオリジンのファイルへのアクセスを制限する](private-content-overview.md#forward-custom-headers-restrict-access)」を参照してください。

   カスタムオリジンには、Amazon EC2、ウェブサイトエンドポイントとして設定されている Amazon S3 バケット、Elastic Load Balancing、独自の HTTP ウェブサーバーなどがあります。

1. 署名付き URL または署名付き Cookie の作成に使用する*信頼されたキーグループ*または*信頼された署名者*を指定します。信頼されたキーグループを使用することをお勧めします。詳細については、「[署名付き URL と署名付き Cookie を作成できる署名者を指定する](private-content-trusted-signers.md)」を参照してください。

1. 署名付き URL または署名付き Cookie を設定する `Set-Cookie` ヘッダーを使用した、承認されたユーザーからのリクエストに対応するアプリケーションを記述します。以下のいずれかのトピックの手順に従ってください。
   + [署名付き URL を使用する](private-content-signed-urls.md)
   + [署名付き Cookie を使用する](private-content-signed-cookies.md)

   使用する方法が明確でない場合は、「[署名付き URL を使用するか、署名付き Cookie を使用するかを決定する](private-content-choosing-signed-urls-cookies.md)」を参照してください。

**Topics**
+ [プライベートコンテンツを提供する方法](#private-content-task-list)
+ [ファイルへのアクセスを制限する](private-content-overview.md)
+ [署名付き URL と署名付き Cookie を作成できる署名者を指定する](private-content-trusted-signers.md)
+ [署名付き URL を使用するか、署名付き Cookie を使用するかを決定する](private-content-choosing-signed-urls-cookies.md)
+ [署名付き URL を使用する](private-content-signed-urls.md)
+ [署名付き Cookie を使用する](private-content-signed-cookies.md)
+ [Linux コマンドおよび OpenSSL を使用した Base64 エンコードおよび暗号化](private-content-linux-openssl.md)
+ [署名付き URL の署名を作成するためのコード例](PrivateCFSignatureCodeAndExamples.md)

# ファイルへのアクセスを制限する
<a name="private-content-overview"></a>

プライベートコンテンツへのユーザーアクセスは 2 つの方法を使用して制御可能です。
+ [CloudFront キャッシュ内のファイルへのアクセスを制限します](#private-content-overview-edge-caches)。
+ 次のいずれかを実行して、オリジン内のファイルへのアクセスを制限します。
  + [Amazon S3 バケットのオリジンアクセスコントロール (OAC) のセットアップ](private-content-restricting-access-to-s3.md)
  + [プライベート HTTP サーバー (カスタムオリジン) のカスタムヘッダーの設定](#forward-custom-headers-restrict-access)

## CloudFront キャッシュ内のファイルへのアクセスを制限する
<a name="private-content-overview-edge-caches"></a>

ユーザーがファイルにアクセスする際に、*署名付き URL* または*署名付き Cookie* の使用が求められるように CloudFront を設定することができます。次に、署名付き URL を作成して認証されたユーザーに配信するか、認証されたユーザーの署名付き Cookie を設定する `Set-Cookie` ヘッダーを送信するアプリケーションを開発します (少数のファイルへの長期的なアクセスを数人のユーザーに付与するために、署名付き URL を手動で作成することもできます)。

ファイルへのアクセスを制御するための署名付き URL または署名付き Cookie を作成するときに、次の制限を指定できます。
+ 最終日時。この日時以降、URL が有効ではなくなります。
+ (オプション) URL が有効になる日時。
+ (オプション) コンテンツへのアクセスに使用可能なコンピュータの IP アドレスまたはアドレス範囲。

署名付き URL または署名付き Cookie では、パブリックとプライベートのキーペアのプライベートキーを使用して、一部がハッシュ化され、署名が行われます。ユーザーが署名付き URL や署名付き Cookie を使用してファイルにアクセスすると、CloudFront は URL や Cookie の署名部分と無署名部分を比較します。これらが一致しない場合、CloudFront はファイルを供給しません。

URL または Cookie の署名には、RSA 2048 または ECDSA 256 プライベートキーを使用する必要があります。

## Amazon S3 バケット内のファイルへのアクセスを制限する
<a name="private-content-overview-s3"></a>

オプションで、Amazon S3 バケット内のコンテンツを保護することで、ユーザーが指定された CloudFront ディストリビューションを介してアクセスできても、Amazon S3 URL を使用して直接アクセスすることはできないように設定できます。これにより、アクセスを制限するコンテンツについては、CloudFront のバイパスと Amazon S3 URL の使用による取得を防止できます。署名付き URL を使用するためにこの手順を実行する必要はありませんが、推奨します。

CloudFront URL を使用してコンテンツにアクセスすることをユーザーに要求するには、次のタスクを実行します。
+ CloudFront に、S3 バケット内のファイルを読み取る*オリジンアクセスコントロール*アクセス許可を付与します。
+ オリジンアクセスコントロールを作成し、CloudFront ディストリビューションに関連付けます。
+ Amazon S3 URL を使用してファイルを読み取るためのアクセス許可を、他のすべてのユーザーから削除します。

詳細については、「[Amazon S3 オリジンへのアクセスを制限する](private-content-restricting-access-to-s3.md)」を参照してください。

## カスタムオリジンのファイルへのアクセスを制限する
<a name="forward-custom-headers-restrict-access"></a>

カスタムオリジンを使用する場合は、カスタムヘッダーをオプションで設定して、アクセスを制限できます。CloudFront がカスタムオリジンからファイルを取得するには、標準の HTTP (または HTTPS) リクエストを使用して CloudFront からファイルにアクセスできる必要があります。しかし、カスタムヘッダーを使用することで、コンテンツへのアクセスをさらに制限して、ユーザーが直接アクセスするのではなく CloudFront を通してのみアクセスできるようにすることができます。署名付き URL を使用するためにこの手順を実行する必要はありませんが、推奨します。

ユーザーに CloudFront を経由してコンテンツにアクセスするよう要求するには、CloudFront ディストリビューションで次の設定を変更します。

**オリジンのカスタムヘッダー**  
カスタムヘッダーがオリジンに転送されるように CloudFront を設定します。「[オリジンリクエストにカスタムヘッダーを追加するように CloudFront を設定する](add-origin-custom-headers.md#add-origin-custom-headers-configure)」を参照してください。

**ビューワープロトコルポリシー**  
ビューワーから CloudFront へのアクセス時に HTTPS の使用が求められるようにディストリビューションを設定します。「[ビューワープロトコルポリシー](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy)」を参照してください。

**オリジンプロトコルポリシー**  
CloudFront がリクエストをオリジンに転送する際にビューワーと同じプロトコルの使用が求められるように、ディストリビューションを設定します。「[プロトコル (カスタムオリジンのみ)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy)」を参照してください。

これらの変更を行った後、CloudFront で送信するように設定したカスタムヘッダーを含むリクエストのみを受け入れるように、カスタムオリジンでアプリケーションを更新します。

**ビューワープロトコルポリシー**と**オリジンプロトコルポリシー**の組み合わせにより、カスタムヘッダーが転送中に暗号化されます。ただし、定期的に以下を実行して、CloudFront がオリジンに転送するカスタムヘッダーをローテーションすることをお勧めします。

1. CloudFront ディストリビューションを更新して、カスタムオリジンへの新しいヘッダーの転送を開始します。

1. アプリケーションを更新して、リクエストが CloudFront からのものであることの確認として新しいヘッダーを受け入れます。

1. 置き換えるヘッダーが今後リクエストに含まれないようにする場合は、アプリケーションを更新して、リクエストが CloudFront からのものであることの確認として古いヘッダーを受け入れないようにします。

# 署名付き URL と署名付き Cookie を作成できる署名者を指定する
<a name="private-content-trusted-signers"></a>

**Topics**
+ [信頼されたキーグループ (推奨) と AWS アカウントのいずれかを選択する](#choosing-key-groups-or-AWS-accounts)
+ [署名者のキーペアを作成する](#private-content-creating-cloudfront-key-pairs)
+ [プライベートキーの形式を変更する (.NET および Java のみ)](#private-content-reformatting-private-key)
+ [ディストリビューションに署名者を追加する](#private-content-adding-trusted-signers)
+ [キーペアの更新](#private-content-rotating-key-pairs)

署名付き URL または署名付き Cookie を作成するには、*署名者*が必要です。署名者は、CloudFront で作成した信頼できるキーグループ、または CloudFront のキーペアが含まれる AWS アカウントのいずれかです。署名付き URL と署名付き Cookie が有効な信頼されたキーグループを使用することをお勧めします。詳細については、「[信頼されたキーグループ (推奨) と AWS アカウントのいずれかを選択する](#choosing-key-groups-or-AWS-accounts)」を参照してください。

署名者には 2 つの目的があります。
+ 署名者をディストリビューションに追加するとすぐに、ビューワーからファイルへのアクセスには、署名付き URL または署名付き Cookie の使用が CloudFront によって求められるようになります。
+ 署名付き URL または署名付き Cookie を作成するときは、署名者のキーペアのプライベートキーを使用して URL または Cookie に署名します。制限されたファイルがリクエストされると、CloudFront は URL または Cookie の署名を署名のない URL または Cookie と比較し、改ざんされていないことを確認します。CloudFront は、URL または Cookie が有効であることも確認します。たとえば、有効期限切れ日時が経過していないことを確認します。

署名者を指定するときは、署名者をキャッシュ動作に追加することにより、署名付き URL または署名付き Cookie を必要とするファイルも間接的に指定します。ディストリビューションのキャッシュ動作が 1 つしかない場合、ビューワーはディストリビューション内のファイルへのアクセスに、署名付き URL または署名付き Cookie の使用を求められます。複数のキャッシュ動作を作成して、署名者を一部のキャッシュ動作に追加し、それ以外のキャッシュ動作に追加しなかった場合、ビューワーは一部のファイルへのアクセスに、署名付き URL または署名付き Cookie の使用を求められ、その他のファイルへのアクセスには求められません。

署名付き URL または署名付き Cookie の作成を許可する署名者 (プライベートキー) を指定し、署名者を CloudFront ディストリビューションに追加するには、以下のタスクを実行します。

1. 署名者として、信頼されたキーグループを使用するか、AWS アカウントを使用するかを決定します。信頼されたキーグループを使用することをお勧めします。詳細については、「[信頼されたキーグループ (推奨) と AWS アカウントのいずれかを選択する](#choosing-key-groups-or-AWS-accounts)」を参照してください。

1. ステップ 1 で選択した署名者に対して、パブリックとプライベートのキーペアを作成します。詳細については、「[署名者のキーペアを作成する](#private-content-creating-cloudfront-key-pairs)」を参照してください。

1. 署名付き URL または署名付き Cookie の作成に .NET または Java を使用する場合は、プライベートキーの形式を変更します。詳細については、「[プライベートキーの形式を変更する (.NET および Java のみ)](#private-content-reformatting-private-key)」を参照してください。

1. 署名付き URL または署名付き Cookie を作成するディストリビューションで、署名者を指定します。詳細については、「[ディストリビューションに署名者を追加する](#private-content-adding-trusted-signers)」を参照してください。

## 信頼されたキーグループ (推奨) と AWS アカウントのいずれかを選択する
<a name="choosing-key-groups-or-AWS-accounts"></a>

署名付き URL または署名付き Cookie を使用するには、*署名者*が必要です。署名者は、CloudFront で作成した信頼されたキーグループ、または CloudFront のキーペアを含む AWS アカウントのいずれかです。以下の理由から、信頼されたキーグループを使用することをお勧めします。
+ CloudFront キーグループでは、CloudFront の署名付き URL と署名付き Cookie のパブリックキーを管理するために AWS アカウントのルートユーザーを使用する必要がありません。[AWS のベストプラクティス](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root)では、特に必要なければルートユーザーを使用しないことが推奨されています。
+ CloudFront キーグループを使用すると、CloudFront API を使用して、パブリックキー、キーグループ、および信頼された署名者を管理できます。API を使用して、キーの作成とキーの更新を自動化できます。AWS ルートユーザーを使用する場合は、AWS マネジメントコンソール を使用して CloudFront キーペアを管理する必要があるため、プロセスを自動化することはできません。
+ CloudFront API を使用してキーグループを管理できるため、AWS Identity and Access Management (IAM) の許可ポリシーを使用して、異なるユーザーに許可される操作を制限することもできます。例えば、ユーザーにパブリックキーのアップロードを許可し、削除を禁止することができます。または、ユーザーにパブリックキーの削除を許可するが、許可するのは、多要素認証の使用、特定のネットワークからのリクエストの送信、特定の日時範囲内でのリクエストの送信など、特定の条件が満たされた場合に限ることもできます。
+ CloudFront キーグループを使用すると、より多くのパブリックキーを CloudFront ディストリビューションに関連付けることができるため、パブリックキーの使用方法と管理方法をより柔軟に設定できます。デフォルトでは、最大 4 つのキーグループを 1 つのディストリビューションに関連付けることができ、キーグループには最大 5 つのパブリックキーを含めることができます。

  AWS アカウントのルートユーザーを使用して CloudFront のキーペアを管理する場合は、AWS アカウントあたり最大 2 つのアクティブな CloudFront キーペアしか使用できません。

## 署名者のキーペアを作成する
<a name="private-content-creating-cloudfront-key-pairs"></a>

CloudFront 署名付き URL または署名付き Cookie の作成に使用する各署名者には、パブリックとプライベートのキーペアが必要です。署名者はプライベートキーを使用して URL または Cookie に署名し、CloudFront はパブリックキーを使用して署名を検証します。

キーペアを作成する方法は、信頼されたキーグループを署名者として使用するか (推奨)、CloudFront のキーペアを使用するかによって異なります。詳細については、次のセクションを参照してください。作成するキーペアは、以下の要件を満たしている必要があります。
+ SSH-2 RSA 2048 または ECDSA 256 キーペアである必要があります。
+ base64 エンコードされた PEM 形式である必要があります。

アプリケーションを保護するために、キーペアを定期的に更新することをお勧めします。詳細については、「[キーペアの更新](#private-content-rotating-key-pairs)」を参照してください。

### 信頼されたキーグループのキーペアを作成する (推奨)
<a name="create-key-pair-and-key-group"></a>

信頼されたキーグループのキーペアを作成するには、以下の手順を実行します。

1. パブリックとプライベートのキーペアを作成します。

1. パブリックキーを CloudFront にアップロードします。

1. パブリックキーを CloudFront キーグループに追加します。

詳細については、次の手順を参照してください。<a name="private-content-uploading-cloudfront-public-key-procedure"></a>

**キーペアを作成するには**
**注記**  
以下の手順では、キーペアを作成する方法の一例として OpenSSL を使用します。RSA または ECDSA キーペアを作成する方法は他にも多数あります。

1. 以下のいずれかのコマンド例を実行します。
   + 以下のコマンド例では、OpenSSL を使用して 2,048 ビット長の RSA キーペアを生成し、`private_key.pem` という名前のファイルに保存します。

     ```
     openssl genrsa -out private_key.pem 2048
     ```
   + 以下のコマンド例では、OpenSSL を使用して `prime256v1` 曲線を使用する ECDSA キーペアを生成し、`private_key.pem` という名前のファイルに保存します。

     ```
     openssl ecparam -name prime256v1 -genkey -noout -out privatekey.pem
     ```

1. 生成されるファイルには、パブリックキーとプライベートキーの両方が含まれます。以下のコマンド例では、`private_key.pem` という名前のファイルからパブリックキーを抽出します。

   ```
   openssl rsa -pubout -in private_key.pem -out public_key.pem
   ```

   後で、以下の手順でパブリックキー (`public_key.pem` ファイル内) をアップロードします。

**パブリックキーを CloudFront にアップロードするには**

1. AWS マネジメントコンソール にサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. ナビゲーションメニューで、[**Public keys (パブリックキー)**] を選択します。

1. **[パブリックキーを作成]** を選択します。

1. **[パブリックキーを作成]** ウィンドウで、次の操作を行います。

   1. [**Key name (キー名)**] に、パブリックキーを識別するための名前を入力します。

   1. [**Key value (キー値)**] に、パブリックキーを貼り付けます。前の手順のステップに従った場合、パブリックキーは `public_key.pem` という名前のファイルにあります。パブリックキーの内容をコピーして貼り付けるには、以下の手順を実行します。
      + macOS または Linux コマンドラインで **cat** コマンドを次のように使用します。

        ```
        cat public_key.pem
        ```

        そのコマンドの出力をコピーして、[**Key value (キー値)**] フィールドに貼り付けます。
      + メモ帳 (Windows の場合) やテキストエディット (macOS の場合) などのプレーンテキストエディタで、`public_key.pem` ファイルを開きます。ファイルの内容をコピーし、[**Key value (キー値)**] フィールドに貼り付けます。

   1. (オプション) [**Comment (コメント)**] に、パブリックキーを説明するコメントを追加します。

   完了したら、[**Add (追加)**] を選択します。

1. パブリックキー ID を記録します。この ID は、後で署名付き URL または署名付き Cookie を作成するときに、`Key-Pair-Id` フィールドの値として使用します。

**パブリックキーをキーグループに追加するには**

1.  で CloudFront コンソールを開きます[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)

1. ナビゲーションメニューで、[**Key groups (キーグループ)**] を選択します。

1. [**Add key group (キーグループの追加)**] を選択します。

1. [**Create key group (キーグループの作成)**] ページで、以下の手順を実行します。

   1. [**Key group name (キーグループ名)**] に、キーグループを識別するための名前を入力します。

   1. (オプション) [**Comment (コメント\$1**] に、キーグループを説明するコメントを入力します。

   1. [**Public keys (パブリックキー)**] で、キーグループに追加するパブリックキーを選択してから、[**Add (追加)**] を選択します。キーグループに追加するパブリックキーごとに、このステップを繰り返します。

1. [**Create key group (キーグループの作成)**] を選択します。

1. キーグループ名を記録します。この名前は、後でキーグループを CloudFront ディストリビューションのキャッシュ動作に関連付けるときに使用します。(CloudFront API では、キーグループ ID を使用して、キーグループをキャッシュ動作に関連付けます)。

### CloudFront のキーペアを作成する (非推奨、AWS アカウントのルートユーザーが必要)
<a name="create-key-pair-aws-account"></a>

**重要**  
ここでの手順に従う代わりに、信頼されたキーグループのパブリックキーを作成することをお勧めします。署名付き URL および署名付き Cookie のパブリックキーを作成するための推奨される方法については、「[信頼されたキーグループのキーペアを作成する (推奨)](#create-key-pair-and-key-group)」を参照してください。

CloudFront のキーペアは、次の方法で作成できます。
+ AWS マネジメントコンソールでキーペアを作成し、プライベートキーをダウンロードします。後述の手順を参照してください。
+ OpenSSL などのアプリケーションを使用して RSA キーペアを作成し、パブリックキーを にアップロードしますAWS マネジメントコンソール RSA キーペアの作成の詳細については、「[信頼されたキーグループのキーペアを作成する (推奨)](#create-key-pair-and-key-group)」を参照してください。<a name="private-content-creating-cloudfront-key-pairs-procedure"></a>

**AWS マネジメントコンソール で CloudFront キーペアを作成するには**

1. AWS アカウントのルートユーザーの認証情報を使用して、AWS マネジメントコンソール にサインインします。
**重要**  
IAM ユーザーは CloudFront のキーペアを作成できません。キーペアを作成するには、ルートユーザーの認証情報を使用してサインインする必要があります。

1. アカウント名を選択してから、[**My Security Credentials (セキュリティ認証情報)**] を選択します。

1. [**CloudFront のキーペア**] を選択します。

1. 複数のキーペアが有効になっていないことを確認します。既に 2 つのキーペアが有効になっていると、キーペアを作成できません。

1. [**Create New Key Pair (新しいキーペアの作成)**] を選択します。
**注記**  
独自のキーペアを作成し、公開キーをアップロードすることもできます。CloudFront キーペアは、1024、2048、または 4096 ビットのキーをサポートします。

1. [**Create Key Pair (キーペアの作成)**] ダイアログボックスで、[**Download Private Key File (プライベートキーファイルのダウンロード)**] を選択し、ファイルをコンピュータに保存します。
**重要**  
CloudFront のキーペアのプライベートキーを安全な場所に保存し、必要な管理者だけがそのプライベートキーを読み取ることができるようにファイルのアクセス許可を設定します。別のユーザーがこのプライベートキーを取得すると、そのユーザーは有効な署名付き URL および署名付き Cookie を生成し、コンテンツをダウンロードできます。プライベートキーを再取得することはできません。したがって、プライベートキーを削除したか失った場合は、新しい CloudFront キーペアを作成する必要があります。

1. キーペアのキーペア ID を記録しておきます (AWS マネジメントコンソール では**アクセスキー ID** と呼ばれます)。この情報は、署名付き URL または署名付き Cookie を作成するときに使用します。

## プライベートキーの形式を変更する (.NET および Java のみ)
<a name="private-content-reformatting-private-key"></a>

.NET または Java を使用して署名付き URL または署名付き Cookie を作成する場合、キーペアのプライベートキーをデフォルトの PEM 形式のまま使用して署名を作成することはできません。代わりに、以下の手順を実行します。
+ **.NET Framework** – .NET Framework で使用する XML 形式にプライベートキーを変換します。いくつかのツールを利用できます。
+ **Java** – DER 形式にプライベートキーを変換します。そのための 1 つの方法は、以下の OpenSSL コマンドを使用することです。以下のコマンドで、`private_key.pem` は PEM 形式のプライベートキーを含むファイルの名前であり、`private_key.der` はコマンドの実行後に DER 形式のプライベートキーを含むファイルの名前です。

  ```
  openssl pkcs8 -topk8 -nocrypt -in private_key.pem -inform PEM -out private_key.der -outform DER
  ```

  エンコーダーが正常に機能するように、Bouncy Castle の Java 用暗号 API の JAR をプロジェクトに追加してから Bouncy Castle プロバイダーを追加します。

## ディストリビューションに署名者を追加する
<a name="private-content-adding-trusted-signers"></a>

署名者は、ディストリビューション用の署名付き URL と署名付き Cookie を作成できる、信頼されたキーグループ (推奨) または CloudFront キーペアです。署名付き URL または署名付き Cookie を CloudFront ディストリビューションで使用するには、署名者を指定する必要があります。

署名者はキャッシュ動作に関連付けられています。これにより、同じディストリビューション内で、一部のファイルに署名付き URL または署名付き Cookie を要求し、その他のファイルには要求しないということが可能になります。ディストリビューションでは、対応するキャッシュ動作に関連付けられているファイルにのみ、署名付き URL または Cookie が必要です。

同様に、署名者は、対応するキャッシュ動作に関連付けられているファイルの URL または Cookie にのみ署名できます。例えば、1 つのキャッシュ動作に対して 1 つの署名者があり、別のキャッシュ動作に対して別の署名者がある場合、どちらの署名者も、もう一方のキャッシュ動作に関連付けられたファイルに対して署名付き URL または署名付き Cookie を作成できません。

**重要**  
ディストリビューションに署名者を追加する前に、以下の手順を実行します。  
キャッシュ動作のパスパターンとキャッシュ動作のシーケンスを慎重に定義して、ユーザーにコンテンツへの意図しないアクセスを許可したり、すべてのユーザーを対象としたコンテンツへのアクセスを禁止したりしないようにします。  
たとえば、リクエストが、2 つのキャッシュ動作のパスパターンに一致したと仮定します。最初のキャッシュ動作は署名付き URL または署名付き Cookie を要求しませんが、2 番目のキャッシュ動作はこれらを要求します。ユーザーは署名付き URL または署名付き Cookie を使用せずにファイルにアクセスできます。これは、CloudFront が、最初の一致に関連付けられたキャッシュ動作を処理するためです。  
パスパターンの詳細については、「[パスパターン](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern)」を参照してください。
コンテンツの配信に既に使用しているディストリビューションの場合は、署名者を追加する前に、署名付き URL と署名付き Cookie の生成を開始する準備ができていることを確認してください。署名者を追加すると、CloudFront は有効な署名付き URL または署名付き Cookie を含まないリクエストを拒否します。

CloudFront コンソールまたは CloudFront API を使用して、署名者をディストリビューションに追加できます。

------
#### [ Console ]

以下の手順では、信頼されたキーグループを署名者として追加する方法を示します。信頼された署名者として AWS アカウントを追加することもできますが、お勧めしません。<a name="private-content-adding-trusted-signers-console-procedure"></a>

**コンソールを使用してディストリビューションに署名者を追加するには**

1. 信頼された署名者として使用するキーグループのキーグループ ID を記録します。詳細については、「[信頼されたキーグループのキーペアを作成する (推奨)](#create-key-pair-and-key-group)」を参照してください。

1.  で CloudFront コンソールを開きます[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)

1. 署名付き URL または署名付き Cookie でファイルを保護するディストリビューションを選択します。
**注記**  
新しいディストリビューションに署名者を追加するには、ディストリビューションを作成するときにステップ 6 で説明したのと同じ設定を指定します。

1. [**Behaviors**] タブを選択します。

1. 署名付き URL または署名付き Cookie で保護するファイルとパスパターンが一致するキャッシュ動作を選択し、[**Edit (編集)**] を選択します。

1. [**Edit Behavior (動作の編集)**] ページで、以下の手順を実行します。

   1. [**Restrict Viewer Access (Use Signed URLs or Signed Cookies) (ビューワーのアクセスを制限 (署名付き URL または署名付き Cookie の使用))**] で、[**はい**] を選択します。

   1. [**Trusted Key Groups or Trusted Signer (信頼されたキーグループまたは信頼された署名者)**] で、[**Trusted Key Groups (信頼されたキーグループ)**] を選択します。

   1. [**Trusted Key Groups (信頼されたキーグループ)**] で、追加するキーグループを選択し、[**Add (追加)**] を選択します。複数のキーグループを追加する場合は、この手順を繰り返します。

1. [**Yes, Edit (はい、編集する)**] を選択して、キャッシュ動作を更新します。

------
#### [ API ]

CloudFront API を使用して、信頼されたキーグループを署名者として追加できます。署名者を既存のディストリビューションまたは新しいディストリビューションに追加できます。どちらの場合も、`TrustedKeyGroups` 要素の値を指定します。

信頼された署名者として AWS アカウントを追加することもできますが、お勧めしません。

*Amazon CloudFront API リファレンス*の以下のトピックを参照してください。
+ **既存のディストリビューションを更新する** – 「[UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)」
+ **新しいディストリビューションを作成する** – 「[CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)」

------

## キーペアの更新
<a name="private-content-rotating-key-pairs"></a>

署名付き URL と署名付き Cookie のキーペアを定期的に更新 (変更) することをお勧めします。有効期限がまだ切れていない URL または Cookie を無効にすることなく、署名付き URL または署名付き Cookie の作成に使用しているキーペアを更新するには、以下のタスクを実行します。

1. 新しいキーペアを作成し、パブリックキーをキーグループに追加します。詳細については、「[信頼されたキーグループのキーペアを作成する (推奨)](#create-key-pair-and-key-group)」を参照してください。

1. 前の手順で新しいキーグループを作成した場合は、[キーグループを署名者としてディストリビューションに追加](#private-content-adding-trusted-signers)します。
**重要**  
キーグループから既存のパブリックキーを削除したり、ディストリビューションからキーグループを削除したりしないでください。新規追加のみを行ってください。

1. 新しいキーペアのプライベートキーを使用して署名を作成するようにアプリケーションを更新します。新しいプライベートキーで署名された URL または Cookie が機能することを確認します。

1. 以前のプライベートキーを使用して署名付き URL または Cookie の有効期限切れ日時が経過するまで待ちます。次に、古いパブリックキーをキーグループから削除します。ステップ 2 で新しいキーグループを作成した場合は、ディストリビューションから古いキーグループを削除します。

# 署名付き URL を使用するか、署名付き Cookie を使用するかを決定する
<a name="private-content-choosing-signed-urls-cookies"></a>

CloudFront 署名付き URL と署名付き Cookie は同じ基本的な機能を提供します。これらによって、コンテンツにアクセスできるユーザーを制御できます。CloudFront を使用してプライベートコンテンツを供給する場合に、署名付き URL と署名付き Cookie のどちらを使用するかを決定するには、以下の点を考慮します。

次のような場合は、署名付き URL を使用します。
+ 個別のファイル (アプリケーションのインストールダウンロード) へのアクセスを制限する場合。
+ ユーザーが Cookie をサポートしていないクライアント (カスタム HTTP クライアントなど) を使用している場合。

次のような場合は、署名付き Cookie を使用します。
+ 複数の制限されたファイル (HLS 形式の動画のすべてのファイルやウェブサイトの購読者の領域にあるすべてのファイルなど) へのアクセスを提供する場合。
+ 現在の URL を変更したくない場合。

現在署名付き URL を使用していない場合で、署名なし URL に次のクエリ文字列パラメータ含まれる場合、署名付き URL と署名付き Cookie のいずれも使用できません。
+ `Expires`
+ `Policy`
+ `Signature`
+ `Key-Pair-Id`

CloudFront では、これらのクエリ文字列パラメータを含む URL が署名付き URL であると見なされ、署名付き Cookie の確認は行われません。

## 署名付き URL と署名付き Cookie の両方を使用する
<a name="private-content-using-signed-urls-and-cookies"></a>

署名付き URL は署名付き Cookie よりも優先されます。署名付き URL と署名付き Cookie の両方を使用して同じファイルへのアクセスが制御されている場合に、ビューワーが署名付き URL を使用してファイルをリクエストすると、CloudFront は署名付き URL のみに基づいてビューワーにファイルを返すかどうかを決定します。

# 署名付き URL を使用する
<a name="private-content-signed-urls"></a>

署名付き URL には、有効期限切れ日時など、追加の情報も含まれており、コンテンツへのアクセスをより詳細に制御できます。この追加情報は、既定ポリシーまたはカスタムポリシーに基づくポリシーステートメントに含まれます。既定ポリシーとカスタムポリシーの違いを以下の 2 つのセクションで説明します。

**注記**  
既定ポリシーを使用して一部の署名付き URL を作成し、同じディストリビューションで、カスタムポリシーを使用して一部の署名付き URL を作成することができます。

**Topics**
+ [署名付き URL に既定ポリシーとカスタムポリシーのどちらを使用するかを決定する](#private-content-choosing-canned-custom-policy)
+ [署名付き URL の仕組み](#private-content-how-signed-urls-work)
+ [署名付き URL の有効期間を決定する](#private-content-overview-choosing-duration)
+ [CloudFront が署名付き URL の有効期限切れの日時を確認するタイミング](#private-content-check-expiration)
+ [サンプルコードおよびサードパーティーツール](#private-content-overview-sample-code)
+ [既定ポリシーを使用して署名付き URL を作成する](private-content-creating-signed-url-canned-policy.md)
+ [カスタムポリシーを使用して署名付き URL を作成する](private-content-creating-signed-url-custom-policy.md)

## 署名付き URL に既定ポリシーとカスタムポリシーのどちらを使用するかを決定する
<a name="private-content-choosing-canned-custom-policy"></a>

署名付き URL を作成する場合、URL の有効期間など、署名付き URL で制限を指定する JSON 形式のポリシーステートメントを作成します。既定ポリシーまたはカスタムポリシーのいずれかを使用できます。既定ポリシーとカスタムポリシーの比較を以下に示します。


****  

| 説明 | 既定ポリシー | カスタムポリシー | 
| --- | --- | --- | 
| ポリシーステートメントを複数のファイル用に再利用できる。ポリシーステートメントを再利用するには、`Resource` オブジェクトでワイルドカード文字を使用する必要があります。(詳しくは、「[カスタムポリシーを使用する署名付き URL のポリシーステートメントで指定する値](private-content-creating-signed-url-custom-policy.md#private-content-custom-policy-statement-values)」を参照してください)。 | いいえ | はい | 
| ユーザーがコンテンツへのアクセスを開始できる日時を指定できる。 | いいえ | はい (オプション) | 
| ユーザーがコンテンツにアクセスできなくなる日時を指定できる。 | はい | はい | 
| コンテンツにアクセスできるユーザーの IP アドレスまたは IP アドレス範囲を指定できる。 | いいえ | はい (オプション) | 
| 署名付き URL にポリシーの base64 エンコードされたバージョンが含まれているため、URL が長くなる。 | いいえ | はい | 

*既定*ポリシーを使用して署名付き URL を作成する方法については、「[既定ポリシーを使用して署名付き URL を作成する](private-content-creating-signed-url-canned-policy.md)」を参照してください。

*カスタム*ポリシーを使用して署名付き URL を作成する方法については、「[カスタムポリシーを使用して署名付き URL を作成する](private-content-creating-signed-url-custom-policy.md)」を参照してください。

## 署名付き URL の仕組み
<a name="private-content-how-signed-urls-work"></a>

署名付き URL 用の CloudFront と Amazon S3 の設定方法と、ユーザーが署名付き URL を使用してファイルをリクエストしたときの CloudFront の応答方法の概要を次に示します。

1. CloudFront ディストリビューションで、1 つ以上の信頼されたキーグループを指定します。指定したグループには、CloudFront が URL 署名の検証に使用できるパブリックキーが含まれている必要があります。対応するプライベートキーを使用して URL に署名します。

   CloudFront は、RSA 2048 および ECDSA 256 キー署名を使用した署名 URL をサポートしています。

   詳細については、「[署名付き URL と署名付き Cookie を作成できる署名者を指定する](private-content-trusted-signers.md)」を参照してください。

1. アプリケーションを開発して、ユーザーがコンテンツへのアクセス許可を持つかどうかを決定し、アプリケーションでアクセスを制限するファイルまたは部分用に署名付き URL を作成するかを決定します。詳細については、以下のトピックを参照してください。
   + [既定ポリシーを使用して署名付き URL を作成する](private-content-creating-signed-url-canned-policy.md)
   + [カスタムポリシーを使用して署名付き URL を作成する](private-content-creating-signed-url-custom-policy.md)

1. 署名付き URL を必要とするファイルをユーザーが要求します。

1. アプリケーションは、ファイルにアクセスするための資格がユーザーにあることを検証します。たとえば、ユーザーがサインインしていること、コンテンツへのアクセス料を支払っていること、他のいくつかのアクセス要件を満たしていることを検証します。

1. アプリケーションは署名付き URL を作成してエンドユーザーに返します。

1. 署名付き URL を使用すると、ユーザーはコンテンツのダウンロードやストリーミングができます。

   このステップは自動で実行されます。ユーザーは、コンテンツにアクセスする以外に、何も行う必要はありません。たとえば、ユーザーがウェブブラウザでコンテンツにアクセスすると、アプリケーションは署名付き URL をブラウザに返します。ブラウザは、直ちに、署名付き URL を使用して CloudFront エッジキャッシュ内のファイルにアクセスします。ユーザーからの介入はありません。

1. CloudFront はパブリックキーを使用して署名を検証し、URL が改ざんされていないことを確認します。署名が無効である場合、リクエストは拒否されます。

   署名が有効である場合、CloudFront は URL のポリシーステートメントを参照して (または既定ポリシーを使用している場合はポリシーステートメントを作成して)、リクエストがまだ有効であることを確認します。たとえば、URL の開始日時と終了日時を指定した場合、CloudFront は、アクセスが許可されている期間にユーザーがコンテンツへのアクセスを試みていることを確認します。

   リクエストがポリシーステートメントの要件を満たしている場合、CloudFront は標準の操作を実行します。つまり、ファイルがエッジキャッシュにすでに存在するかどうかを確認し、必要に応じてリクエストをオリジンに転送して、ファイルをユーザーに返します。

**注記**  
署名なし URL にクエリ文字列パラメータが含まれている場合は、署名する URL にそれらのパラメータを含めてください。URL への署名後にその URL にクエリ文字列を追加すると、HTTP 403 ステータスが返されます。

## 署名付き URL の有効期間を決定する
<a name="private-content-overview-choosing-duration"></a>

短期間 (おそらく数分) のみ有効な署名付き URL を使用してプライベートコンテンツを配信できます。このように短期間有効な署名付き URL は、特定の目的で、コンテンツをユーザーにオンザフライで配信する場合に適しています。たとえば、映画レンタルや音楽ダウンロードをカスタマーにオンデマンドで配信する場合に適しています。署名付き URL を短期間だけ有効にする場合、開発したアプリケーションを使用して、署名付き URL を自動生成することが必要になる場合があります。ユーザーがファイルのダウンロードまたはメディアファイルの再生を開始すると、CloudFront は、URL 内の有効期限切れ時刻と現在の時刻を比較して、URL が依然として有効かどうかを判別します。

これよりも有効期間の長い (おそらく数年間の) 署名付き URL を使用して、プライベートコンテンツを配信できます。有効期間の長い署名付き URL は、プライベートコンテンツを既知のユーザーに配信する場合に役立ちます。たとえば、事業計画を投資家に配信したり、教育資料を従業員に配信したりする場合に役立ちます。これらの長期的な署名付き URL を生成するアプリケーションを開発できます。

## CloudFront が署名付き URL の有効期限切れの日時を確認するタイミング
<a name="private-content-check-expiration"></a>

CloudFront は、HTTP リクエスト時に署名付き URL の有効期限切れ日時を確認します。有効期限切れ時刻の直前にクライアントが大きなファイルのダウンロードを開始した場合、ダウンロード中に有効期限切れ時刻が経過してもダウンロードは完了します。TCP 接続が中断し、有効期限切れ時刻が経過した後にクライアントがダウンロードを再開した場合、ダウンロードは失敗します。

クライアントが、ファイルを断片的に取得するレンジ GET を使用した場合、有効期限切れ時刻が経過した後に実行された GET リクエストは失敗します。レンジ GET の詳細については、「[CloudFront がオブジェクトの部分的リクエスト (レンジ GET) を処理する方法](RangeGETs.md)」を参照してください。

## サンプルコードおよびサードパーティーツール
<a name="private-content-overview-sample-code"></a>

署名付き URL の、ハッシュ化および署名されたパートを作成するサンプルコードについては、以下のトピックを参照してください。
+ [Perl を使用して URL 署名を作成する](CreateURLPerl.md)
+ [PHP を使用して URL 署名を作成する](CreateURL_PHP.md)
+ [C\$1 と .NET Framework を使用して URL 署名を作成する](CreateSignatureInCSharp.md)
+ [Java を使用して URL 署名を作成する](CFPrivateDistJavaDevelopment.md)

# 既定ポリシーを使用して署名付き URL を作成する
<a name="private-content-creating-signed-url-canned-policy"></a>

既定ポリシーを使用して署名付き URL を作成するには、以下の手順を実行します。<a name="private-content-creating-signed-url-canned-policy-procedure"></a>

**既定ポリシーを使用して署名付き URL を作成するには**

1. .NET または Java を使用して署名付き URL を作成しており、キーペアのプライベートキーをデフォルトの .pem 形式から .NET または Java 対応の形式に変更していない場合は、それを変換します。詳細については、「[プライベートキーの形式を変更する (.NET および Java のみ)](private-content-trusted-signers.md#private-content-reformatting-private-key)」を参照してください。

1. 以下の値を連結します。この署名付き URL の例に示す形式を使用できます。

   ```
   https://d111111abcdef8.cloudfront.net/image.jpg?color=red&size=medium&Expires=1767290400&Signature=nitfHRCrtziwO2HwPfWw~yYDhUF5EwRunQA-j19DzZrvDh6hQ73lDx~-ar3UocvvRQVw6EkC~GdpGQyyOSKQim-TxAnW7d8F5Kkai9HVx0FIu-5jcQb0UEmatEXAMPLE3ReXySpLSMj0yCd3ZAB4UcBCAqEijkytL6f3fVYNGQI6&Key-Pair-Id=K2JCJMDEHXQW5F
   ```

   すべての空白 (タブと改行文字を含む) を削除します。アプリケーションコード内の文字列にエスケープ文字を含めることが必要になる場合があります。すべての値の型は `String` です。  
**1. *ファイルのベース URL***  
ベース URL は、署名付き URL を使用しなかった場合にファイルへのアクセスに使用する CloudFront URL であり、独自のクエリ文字列パラメータを含みます (ある場合)。前の例で、ベース URL は `https://d111111abcdef8.cloudfront.net/image.jpg` です。ディストリビューション用の URL 形式の詳細については、「[CloudFront でファイルの URL 形式をカスタマイズする](LinkFormat.md)」を参照してください。  
   + 以下の CloudFront URL は、ディストリビューション内のイメージファイルの URL です (CloudFront ドメイン名を使用)。`image.jpg` は `images` ディレクトリにあります。URL 内のファイルへのパスは、HTTP サーバーまたは Amazon S3 バケットのファイルへのパスに一致する必要があります。

     `https://d111111abcdef8.cloudfront.net/images/image.jpg`
   + 以下の CloudFront URL には、クエリ文字列が含まれます。

     `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large`
   + 以下の CloudFront URL は、ディストリビューション内のイメージファイルの URL です。どちらも代替ドメイン名を使用します。2 番目にはクエリ文字列が含まれています。

     `https://www.example.com/images/image.jpg`

     `https://www.example.com/images/image.jpg?color=red`
   + 以下の CloudFront URL は、代替ドメイン名と HTTPS プロトコルを使用するディストリビューション内のイメージファイルの URL です。

     `https://www.example.com/images/image.jpg`  
** 2. `?` **  
`?` は、クエリパラメータがベース URL の後に続くことを示します。クエリパラメータを指定しない場合でも、`?` を含めます。  
以下のクエリパラメータは任意の順序で指定できます。  
**3. *クエリ文字パラメータ (ある場合*`&`**  
(オプション) 独自のクエリ文字列パラメータを入力できます。これを行うには、各パラメータ間にアンパサンド (`&`) を追加します (例: `color=red&size=medium`)。クエリ文字列パラメータは、URL 内に任意の順序で指定できます。  
クエリ文字列パラメータに `Expires`、`Signature`、または `Key-Pair-Id` という名前を付けることはできません。  
** 4.`Expires=`*Unix 時間形式 (秒単位) および協定世界時 (UTC) の日時***  
URL によるファイルへのアクセスの許可を停止する日付と時刻。  
有効期限切れ日時を Unix 時間形式 (秒単位) および協定世界時 (UTC) で指定します。例えば、このトピックの冒頭にある例に示すように、2026 年 1 月 1 日午前 10:00 UTC は Unix 時間形式で `1767290400` に変換されます。  
エポック時間を使用するには、`9223372036854775807` (2262 年 4 月 11 日金曜日の 23:47:16.854 UTC) 以前の日付に 64 ビット整数を指定します。  
  
UTC の詳細については、[RFC 3339, Date and Time on the Internet: Timestamps](https://tools.ietf.org/html/rfc3339) を参照してください。  
** 5. `&Signature=`*ハッシュ化および署名されたバージョンのポリシーステートメント***  
ハッシュ化され、署名された base64 エンコードバージョンの JSON ポリシーステートメント。詳細については、「[既定ポリシーを使用する署名付き URL の署名を作成する](#private-content-canned-policy-creating-signature)」を参照してください。  
** 6. `&Key-Pair-Id=`*署名の生成に使用しているプライベートキーに対応する CloudFront パブリックキーのパブリックキー ID***  
CloudFront パブリックキーの ID (`K2JCJMDEHXQW5F` など)。パブリックキー ID は、署名付き URL の検証に使用するパブリックキーを CloudFront に通知します。CloudFront は、署名内の情報をポリシーステートメント内の情報と比較して、URL が改ざんされていないことを確認します。  
このパブリックキーは、ディストリビューションの信頼された署名者であるキーグループに属している必要があります。詳細については、「[署名付き URL と署名付き Cookie を作成できる署名者を指定する](private-content-trusted-signers.md)」を参照してください。

## 既定ポリシーを使用する署名付き URL の署名を作成する
<a name="private-content-canned-policy-creating-signature"></a>

既定ポリシーを使用する署名付き URL の署名を作成するには、以下の手順を実行します。

**Topics**
+ [既定ポリシーを使用する署名付き URL のポリシーステートメントを作成する](#private-content-canned-policy-creating-policy-statement)
+ [既定ポリシーを使用する署名付き URL の署名を作成する](#private-content-canned-policy-signing-policy-statement)

### 既定ポリシーを使用する署名付き URL のポリシーステートメントを作成する
<a name="private-content-canned-policy-creating-policy-statement"></a>

既定ポリシーを使用して署名付き URL を作成する場合、`Signature` パラメータは、ポリシーステートメントのハッシュ化および署名されたバージョンです。カスタムポリシーを使用する署名付き URL とは異なり、既定ポリシーを使用する署名付き URL では、URL にポリシーステートメントを含めません。ポリシーステートメントを作成するには、以下の手順を実行します。<a name="private-content-canned-policy-creating-policy-statement-procedure"></a>

**既定ポリシーを使用する署名付き URL のポリシーステートメントを作成するには**

1. 以下の JSON 形式および UTF-8 文字エンコードを使用してポリシーステートメントを構築します。すべての句読点および他のリテラル値を、指定されたとおりに正確に含めます。`Resource` および `DateLessThan` パラメータの詳細については、「[既定ポリシーを使用する署名付き URL のポリシーステートメントで指定する値](#private-content-canned-policy-statement-values)」を参照してください。

   ```
   {
       "Statement": [
           {
               "Resource": "base URL or stream name",
               "Condition": {
                   "DateLessThan": {
                       "AWS:EpochTime": ending date and time in Unix time format and UTC
                   }
               }
           }
       ]
   }
   ```

1. ポリシーステートメントからすべての空白 (タブと改行文字を含む) を削除します。アプリケーションコード内の文字列にエスケープ文字を含めることが必要になる場合があります。

#### 既定ポリシーを使用する署名付き URL のポリシーステートメントで指定する値
<a name="private-content-canned-policy-statement-values"></a>

既定ポリシーのポリシーステートメントを作成する場合、以下の値を指定します。

**リソース**  
`Resource` の値は 1 つだけ指定できます。
クエリ文字列 (ある場合) が含まれるベース URL。ただし、CloudFront の `Expires`、`Signature`、および `Key-Pair-Id` パラメータが除外されます。次に例を示します。  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`  
次の点に注意してください。  
+ **プロトコル** – 値は `http://` または `https://` で始まっている必要があります。
+ **クエリ文字列パラメータ** – クエリ文字列パラメータがない場合は、疑問符を省略します。
+ **代替ドメイン名** – URL で代替ドメイン名 (CNAME) を指定する場合は、ウェブページまたはアプリケーション内のファイルを参照するときに代替ドメイン名を指定する必要があります。オブジェクトの Amazon S3 URL を指定しないでください。

**DateLessThan**  
URL の有効期限切れ日時。Unix 時間形式 (秒単位) および協定世界時 (UTC) で指定します。例えば、UTC の 2026 年 1 月 1 日午前 10 時 00 分は、Unix 時間形式の 1767290400 に変換されます。  
この値は、署名付き URL 内の `Expires` クエリ文字列パラメータの値と一致する必要があります。値を引用符で囲まないでください。  
詳細については、「[CloudFront が署名付き URL の有効期限切れの日時を確認するタイミング](private-content-signed-urls.md#private-content-check-expiration)」を参照してください。

#### 既定ポリシーを使用する署名付き URL のポリシーステートメントの例
<a name="private-content-canned-policy-creating-policy-statement-example"></a>

署名付き URL 内の既定ポリシーの以下のポリシーステートメントの例を使用すると、ユーザーは、UTC の 2026 年 1 月 1 日午前 10 時 00 分までファイル `https://d111111abcdef8.cloudfront.net/horizon.jpg` にアクセスできます。

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/horizon.jpg?size=large&license=yes",
            "Condition": {
                "DateLessThan": {
                    "AWS:EpochTime": 1767290400
                }
            }
        }
    ]
}
```

### 既定ポリシーを使用する署名付き URL の署名を作成する
<a name="private-content-canned-policy-signing-policy-statement"></a>

署名付き URL の `Signature` パラメータの値を作成するには、「[既定ポリシーを使用する署名付き URL のポリシーステートメントを作成する](#private-content-canned-policy-creating-policy-statement)」で作成したポリシーステートメントをハッシュ化して署名します。

ポリシーステートメントのハッシュ化、署名、およびエンコードを行う方法の詳細および例については、以下の各資料を参照してください。
+ [Linux コマンドおよび OpenSSL を使用した Base64 エンコードおよび暗号化](private-content-linux-openssl.md)
+ [署名付き URL の署名を作成するためのコード例](PrivateCFSignatureCodeAndExamples.md)<a name="private-content-canned-policy-creating-signature-download-procedure"></a>

**オプション 1: 既定ポリシーを使用して署名を作成するには**

1. 「[既定ポリシーを使用する署名付き URL のポリシーステートメントを作成するには](#private-content-canned-policy-creating-policy-statement-procedure)」の手順で作成したポリシーステートメントを、SHA-1 ハッシュ関数と生成した RSA または ECDSA プライベートキーを使用してハッシュ化し、署名します。空白を含まないバージョンのポリシーステートメントを使用します。

   ハッシュ関数に必要なプライベートキーには、対応するパブリックキーがディストリビューション内のアクティブな信頼されたキーグループにあるものを使用してください。
**注記**  
ポリシーステートメントをハッシュ化および署名するための方法は、プログラミング言語およびプラットフォームによって異なります。サンプルコードについては、「[署名付き URL の署名を作成するためのコード例](PrivateCFSignatureCodeAndExamples.md)」を参照してください。

1. ハッシュ化および署名された文字列から、空白 (タブや改行文字を含む) を削除します。

1. MIME base64 エンコーディングを使用して文字列を Base64 エンコードします。詳細については、*RFC 2045, MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies* の [Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) を参照してください。

1. URL クエリ文字列内の無効な文字を有効な文字で置き換えます。次の表に無効な文字と有効な文字を示します。  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-canned-policy.html)

1. 結果の値を署名付き URL の `&Signature=` の後に付加し、「[既定ポリシーを使用して署名付き URL を作成するには](#private-content-creating-signed-url-canned-policy-procedure)」に戻って、署名付き URL の各パートの連結を終了します。

# カスタムポリシーを使用して署名付き URL を作成する
<a name="private-content-creating-signed-url-custom-policy"></a>

カスタムポリシーを使用して署名付き URL を作成するには、次の手順を実行します。<a name="private-content-creating-signed-url-custom-policy-procedure"></a>

**カスタムポリシーを使用して署名付き URL を作成するには**

1. .NET または Java を使用して署名付き URL を作成しており、キーペアのプライベートキーをデフォルトの .pem 形式から .NET または Java 対応の形式に変更していない場合は、それを変換します。詳細については、「[プライベートキーの形式を変更する (.NET および Java のみ)](private-content-trusted-signers.md#private-content-reformatting-private-key)」を参照してください。

1. 以下の値を連結します。この署名付き URL の例に示す形式を使用できます。

   

   ```
   https://d111111abcdef8.cloudfront.net/image.jpg?color=red&size=medium&Policy=eyANCiAgICEXAMPLEW1lbnQiOiBbeyANCiAgICAgICJSZXNvdXJjZSI6Imh0dHA6Ly9kemJlc3FtN3VuMW0wLmNsb3VkZnJvbnQubmV0L2RlbW8ucGhwIiwgDQogICAgICAiQ29uZGl0aW9uIjp7IA0KICAgICAgICAgIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIyMDcuMTcxLjE4MC4xMDEvMzIifSwNCiAgICAgICAgICJEYXRlR3JlYXRlclRoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTI5Njg2MDE3Nn0sDQogICAgICAgICAiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjEyOTY4NjAyMjZ9DQogICAgICB9IA0KICAgfV0gDQp9DQo&Signature=nitfHRCrtziwO2HwPfWw~yYDhUF5EwRunQA-j19DzZrvDh6hQ73lDx~-ar3UocvvRQVw6EkC~GdpGQyyOSKQim-TxAnW7d8F5Kkai9HVx0FIu-5jcQb0UEmatEXAMPLE3ReXySpLSMj0yCd3ZAB4UcBCAqEijkytL6f3fVYNGQI6&Key-Pair-Id=K2JCJMDEHXQW5F
   ```

   すべての空白 (タブと改行文字を含む) を削除します。アプリケーションコード内の文字列にエスケープ文字を含めることが必要になる場合があります。すべての値の型は `String` です。  
**1. *ファイルのベース URL***  
ベース URL は、署名付き URL を使用しなかった場合にファイルへのアクセスに使用する CloudFront URL であり、独自のクエリ文字列パラメータを含みます (ある場合)。前の例で、ベース URL は `https://d111111abcdef8.cloudfront.net/image.jpg` です。ディストリビューション用の URL 形式の詳細については、「[CloudFront でファイルの URL 形式をカスタマイズする](LinkFormat.md)」を参照してください。  
以下の例は、ディストリビューションで指定する値を示しています。  
   + 以下の CloudFront URL は、ディストリビューション内のイメージファイルの URL です (CloudFront ドメイン名を使用)。`image.jpg` は `images` ディレクトリにあります。URL 内のファイルへのパスは、HTTP サーバーまたは Amazon S3 バケットのファイルへのパスに一致する必要があります。

     `https://d111111abcdef8.cloudfront.net/images/image.jpg`
   + 以下の CloudFront URL には、クエリ文字列が含まれます。

     `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large`
   + 以下の CloudFront URL は、ディストリビューション内のイメージファイルの URL です。両方の URL で代替ドメイン名が使用されており、2 番目の URL にはクエリ文字列が含まれています。

     `https://www.example.com/images/image.jpg`

     `https://www.example.com/images/image.jpg?color=red`
   + 以下の CloudFront URL は、代替ドメイン名と HTTPS プロトコルを使用するディストリビューション内のイメージファイルの URL です。

     `https://www.example.com/images/image.jpg`  
**2. `?` **  
`?` は、クエリ文字列パラメータがベース URL の後に続くことを示します。クエリパラメータを指定しない場合でも、`?` を含めます。  
以下のクエリパラメータは任意の順序で指定できます。  
**3. *クエリ文字パラメータ (ある場合*`&`**  
(オプション) 独自のクエリ文字列パラメータを入力できます。これを行うには、各パラメータ間にアンパサンド (&) を追加します (例: `color=red&size=medium`)。クエリ文字列パラメータは、URL 内に任意の順序で指定できます。  
クエリ文字列パラメータに `Policy`、`Signature`、または `Key-Pair-Id` という名前を付けることはできません。
独自のパラメータを追加する場合は、各パラメータの後に `&` を付加します (最後のパラメータにも付加します)。  
**4. `Policy=`*ポリシーステートメントの base64 エンコードバージョン***  
空白が削除されて base64 エンコードされた、JSON 形式のポリシーステートメント。詳細については、「[カスタムポリシーを使用する署名付き URL のポリシーステートメントを作成する](#private-content-custom-policy-statement)」を参照してください。  
ポリシーステートメントは、署名付き URL によってユーザーに許可されるアクセスをコントロールします。これには、ファイルの URL、有効期限切れ日時、URL が有効になる日時 (オプション)、ファイルへのアクセスが許可されている IP アドレスまたは IP アドレス範囲 (オプション) が含まれます。  
**5. `&Signature=`*ハッシュ化および署名されたバージョンのポリシーステートメント***  
ハッシュ化され、署名された base64 エンコードバージョンの JSON ポリシーステートメント。詳細については、「[カスタムポリシーを使用する署名付き URL の署名を作成する](#private-content-custom-policy-creating-signature)」を参照してください。  
**6. `&Key-Pair-Id=`*署名の生成に使用しているプライベートキーに対応する CloudFront パブリックキーのパブリックキー ID***  
CloudFront パブリックキーの ID (`K2JCJMDEHXQW5F` など)。パブリックキー ID は、署名付き URL の検証に使用するパブリックキーを CloudFront に通知します。CloudFront は、署名内の情報をポリシーステートメント内の情報と比較して、URL が改ざんされていないことを確認します。  
このパブリックキーは、ディストリビューションの信頼された署名者であるキーグループに属している必要があります。詳細については、「[署名付き URL と署名付き Cookie を作成できる署名者を指定する](private-content-trusted-signers.md)」を参照してください。

## カスタムポリシーを使用する署名付き URL のポリシーステートメントを作成する
<a name="private-content-custom-policy-statement"></a>

カスタムポリシーを使用する署名付き URL のポリシーステートメントを作成するには、以下の手順を実行します。

さまざまな方法でファイルへのアクセスを制御するポリシーステートメントの例については、「[カスタムポリシーを使用する署名付き URL のポリシーステートメントの例](#private-content-custom-policy-statement-examples)」を参照してください。<a name="private-content-custom-policy-creating-policy-procedure"></a>

**カスタムポリシーを使用する署名付き URL のポリシーステートメントを作成するには**

1. 以下の JSON 形式を使用してポリシーステートメントを構築します。小なり記号 (`<`) と大なり記号 (`>`)、およびそれらの中の説明は、独自の値に置き換えます。詳細については、「[カスタムポリシーを使用する署名付き URL のポリシーステートメントで指定する値](#private-content-custom-policy-statement-values)」を参照してください。

   ```
   {
       "Statement": [
           {
               "Resource": "<Optional but recommended: URL of the file>",
               "Condition": {
                   "DateLessThan": {
   	                "AWS:EpochTime": <Required: ending date and time in Unix time format and UTC>
                   },
                   "DateGreaterThan": {
   	                "AWS:EpochTime": <Optional: beginning date and time in Unix time format and UTC>
                   },
                   "IpAddress": {
   	                "AWS:SourceIp": "<Optional: IP address>"
                   }
               }
           }
       ]
   }
   ```

   次の点に注意してください。
   + ポリシーには、1 つのステートメントのみを含めることができます。
   + UTF-8 文字エンコードを使用します。
   + すべての句読点およびパラメータ名を、指定されたとおりに正確に含めます。パラメータ名の省略形は受け付けられません。
   + `Condition` セクションのパラメータの順序は問題ではありません。
   + `Resource`、`DateLessThan`、`DateGreaterThan`、および `IpAddress` の値については、「[カスタムポリシーを使用する署名付き URL のポリシーステートメントで指定する値](#private-content-custom-policy-statement-values)」を参照してください。

1. ポリシーステートメントからすべての空白 (タブと改行文字を含む) を削除します。アプリケーションコード内の文字列にエスケープ文字を含めることが必要になる場合があります。

1. MIME base64 エンコーディングを使用してポリシーステートメントを Base64 エンコードします。詳細については、*RFC 2045, MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies* の [Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) を参照してください。

1. URL クエリ文字列内の無効な文字を有効な文字で置き換えます。次の表に無効な文字と有効な文字を示します。  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-custom-policy.html)

1. 結果の値を署名付き URL の `Policy=` の後に付加します。

1. ポリシーステートメントのハッシュ化、署名、および base64 エンコードを行って、署名付き URL の署名を作成します。詳細については、「[カスタムポリシーを使用する署名付き URL の署名を作成する](#private-content-custom-policy-creating-signature)」を参照してください。

### カスタムポリシーを使用する署名付き URL のポリシーステートメントで指定する値
<a name="private-content-custom-policy-statement-values"></a>

カスタムポリシーのポリシーステートメントを作成する場合、以下の値を指定します。

**リソース**  
クエリ文字列 (ある場合) が含まれる URL。ただし、CloudFront の `Policy`、`Signature`、および `Key-Pair-Id` パラメータが除外されます。例えば、次のようになります。  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg\?size=large&license=yes`  
`Resource` の URL の値は 1 つだけ指定できます。  
ポリシーで、`Resource` パラメータを省略できますが、その場合、署名付き URL を持つすべてのユーザーが、署名付き URL の作成に使用するキーペアに関連付けられた*あらゆる*ディストリビューションの*すべての*ファイルにアクセスできることになります。
次の点に注意してください。  
+ **プロトコル** – 値は `http://`、`https://`、または `*://` で始まっている必要があります。
+ **クエリ文字列パラメータ** - URL にクエリ文字列パラメータがある場合は、バックスラッシュ文字 (`\`) を使用してクエリ文字列の最初の疑問符 (`?`) をエスケープします。例えば、次のようになります。

  `https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`
+ **ワイルドカード文字** – ポリシーの URL にはワイルドカード文字を使用できます。次のワイルドカード文字がサポートされています。
  + アスタリスク (`*`) は、0 個以上の文字に一致します
  + 疑問符 (`?`) は、1 つの文字に一致します

  CloudFront がポリシー内の URL を HTTP リクエスト内の URL と照合すると、ポリシー内の URL は次のように 4 つのセクション (プロトコル、ドメイン、パス、クエリ文字列) に分割されます。

  `[protocol]://[domain]/[path]\?[query string]`

  ポリシーの URL にワイルドカード文字を使用する場合、ワイルドカードマッチングはワイルドカードを含むセクションの境界内でのみ適用されます。例えば、次のようなポリシーの URL を考えてみます。

  `https://www.example.com/hello*world`

  この例では、アスタリスクワイルドカード (`*`) はパスセクション内にのみ適用されるため、URL `https://www.example.com/helloworld` や `https://www.example.com/hello-world` には一致しますが、URL `https://www.example.net/hello?world` には一致しません。

  ワイルドカードマッチングのセクションの境界には、次の例外が適用されます。
  + パスセクションの末尾にアスタリスクがある場合、クエリ文字列セクションにアスタリスクが付いていることを意味します。例えば、`http://example.com/hello*` と `http://example.com/hello*\?*` は同じです。
  + ドメインセクションの末尾にアスタリスクがある場合、パスセクションとクエリ文字列セクションの両方にアスタリスクが付いていることを意味します。例えば、`http://example.com*` と `http://example.com*/*\?*` は同じです。
  + ポリシーの URL では、プロトコルセクションを省略し、ドメインセクションをアスタリスクで始めることができます。その場合、プロトコルセクションは暗黙的にアスタリスクに設定されます。例えば、ポリシーの URL `*example.com` は `*://*example.com/` と同等です。
  + アスタリスク (`"Resource": "*"`) 単独の場合は、どの URL にも一致します。

  例えば、ポリシーの値 `https://d111111abcdef8.cloudfront.net/*game_download.zip*` は、次の URL すべてに一致します。
  + `https://d111111abcdef8.cloudfront.net/game_download.zip`
  + `https://d111111abcdef8.cloudfront.net/example_game_download.zip?license=yes`
  + `https://d111111abcdef8.cloudfront.net/test_game_download.zip?license=temp`
+ **代替ドメイン名** – ポリシーの URL で代替ドメイン名 (CNAME) を指定する場合、HTTP リクエストはウェブページまたはアプリケーション内の代替ドメイン名を使用する必要があります。ポリシーのファイルの Amazon S3 URL を指定しないでください。

**DateLessThan**  
URL の有効期限切れ日時。Unix 時間形式 (秒単位) および協定世界時 (UTC) で指定します。ポリシーでは、値を引用符で囲まないでください。UTC の詳細については、「[Date and Time on the Internet: Timestamps](https://tools.ietf.org/html/rfc3339)」を参照してください。  
たとえば、UTC の 2023 年 1 月 31 日午前 10 時 00 分は、Unix 時間形式の 1675159200 に変換されます。  
これは、`Condition` セクションにおける唯一の必須パラメータです。CloudFront では、プライベートコンテンツへの永久的なアクセスがユーザーに許可されることのないよう、この値の指定が要求されます。  
詳細については、[CloudFront が署名付き URL の有効期限切れの日時を確認するタイミング](private-content-signed-urls.md#private-content-check-expiration)を参照してください。

**DateGreaterThan (オプション)**  
オプションの URL 開始日時。Unix 時間形式 (秒単位) および協定世界時 (UTC) で指定します。ユーザーは、指定された日時が過ぎるまでファイルにアクセスできません。値を引用符で囲まないでください。

**IpAddress (オプション)**  
HTTP リクエストを実行するクライアントの IP アドレス。次の点に注意してください。  
+ ファイルへのアクセスをすべての IP アドレスに許可するには、`IpAddress` パラメータを省略します。
+ IP アドレスまたは IP アドレス範囲を 1 つ指定できます。2 つの別々の範囲のどちらかにクライアントの IP アドレスが入っている場合にアクセスを許可するようなポリシーを使用することはできません。
+ 1 つの IP アドレスからのアクセスを許可するには、以下のように指定します。

  `"`*IPv4 IP アドレス*`/32"`
+ IP アドレス範囲は標準の IPv4 CIDR 形式 (`192.0.2.0/24` など) で指定する必要があります。詳細については、「[Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan](https://tools.ietf.org/html/rfc4632)」を参照してください。
**重要**  
IPv6 形式の IP アドレス (例: 2001:0db8:85a3::8a2e:0370:7334) はサポートされていません。

  `IpAddress` を含むカスタムポリシーを使用する場合、ディストリビューションで IPv6 は有効にしません。一部のコンテンツへのアクセスを IP アドレスによって制限し、他のコンテンツで IPv6 リクエストをサポートする場合、2 つのディストリビューションを作成します。詳細については、トピック「[すべてのディストリビューション設定リファレンス](distribution-web-values-specify.md)」の「[IPv6 を有効にする (ビューワーリクエスト)](DownloadDistValuesGeneral.md#DownloadDistValuesEnableIPv6)」を参照してください。

## カスタムポリシーを使用する署名付き URL のポリシーステートメントの例
<a name="private-content-custom-policy-statement-examples"></a>

以下のポリシーステートメントの例は、特定のファイル、ディレクトリ内のすべてのファイル、またはキーペア ID に関連付けられたすべてのファイルへのアクセスを制御する方法を示しています。また、この例は、個々の IP アドレスまたは IP アドレス範囲からのアクセスを制御する方法、および指定された日時以降にユーザーが署名付き URL を使用することを禁止する方法も示しています。

これらの例のいずれかをコピーして貼り付ける場合は、すべての空白 (タブと改行文字を含む) を削除し、値を独自の値に置き換えて、右の中かっこ (`}`) の後に改行文字を含めます。

詳細については、「[カスタムポリシーを使用する署名付き URL のポリシーステートメントで指定する値](#private-content-custom-policy-statement-values)」を参照してください。

**Topics**
+ [ポリシーステートメントの例: IP アドレス範囲から 1 つのファイルにアクセスする](#private-content-custom-policy-statement-example-one-object)
+ [ポリシーステートメントの例: IP アドレス範囲からディレクトリ内のすべてのファイルにアクセスする](#private-content-custom-policy-statement-example-all-objects)
+ [ポリシーステートメントの例: キーペア ID に関連付けられたすべてのファイルに 1 つの IP アドレスからアクセスする](#private-content-custom-policy-statement-example-one-ip)

### ポリシーステートメントの例: IP アドレス範囲から 1 つのファイルにアクセスする
<a name="private-content-custom-policy-statement-example-one-object"></a>

次の署名付き URL 内のカスタムポリシーの例では、UTC の 2023 年 1 月 31 日午前 10 時 00 分まで、範囲 `192.0.2.0/24` の IP アドレスから、ユーザーがファイル `https://d111111abcdef8.cloudfront.net/game_download.zip` にアクセスできることを指定しています。

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/game_download.zip",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1675159200
                }
            }
        }
    ]
}
```

### ポリシーステートメントの例: IP アドレス範囲からディレクトリ内のすべてのファイルにアクセスする
<a name="private-content-custom-policy-statement-example-all-objects"></a>

以下のカスタムポリシーの例では、`Resource` パラメータのアスタリスクワイルドカード文字 (`*`) が示すとおり、`training` ディレクトリ内のあらゆるファイルを対象とする署名付き URL を作成できます。UTC の 2023 年 1 月 31 日午前 10 時 00 分まで、範囲 `192.0.2.0/24` の IP アドレスから、ユーザーはファイルにアクセスできます。

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/training/*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1675159200
                }
            }
        }
    ]
}
```

このポリシーを使用する各署名付き URL には、次のように、特定のファイルを識別する URL があります。

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

### ポリシーステートメントの例: キーペア ID に関連付けられたすべてのファイルに 1 つの IP アドレスからアクセスする
<a name="private-content-custom-policy-statement-example-one-ip"></a>

以下のカスタムポリシーの例では、`Resource` パラメータのアスタリスクワイルドカード文字 (`*`) が示すとおり、あらゆるディストリビューションに関連付けられたあらゆるファイルを対象とする署名付き URL を作成できます。署名付き URL には、`http://` ではなく `https://` プロトコルを使用する必要があります。ユーザーは IP アドレス `192.0.2.10/32` を使用する必要があります。(CIDR 表記の値 `192.0.2.10/32` は 1 つの IP アドレス `192.0.2.10` を参照します)。ファイルは、UTC の 2023 年 1 月 31 日午前 10 時 00 分から UTC の 2023 年 2 月 2 日午前 10 時 00 分まで使用できます。

```
{
    "Statement": [
       {
            "Resource": "https://*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.10/32"
                },
                "DateGreaterThan": {
                    "AWS:EpochTime": 1675159200
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1675332000
                }
            }
        }
    ]
}
```

このポリシーを使用する各署名付き URL には、次のように、特定の CloudFront ディストリビューション内の特定のファイルを識別する URL があります。

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

署名付き URL にはキーペア ID も含まれます。キーペア ID は、URL に指定されたディストリビューション (d111111abcdef8.cloudfront.net) 内の信頼されたキーグループに関連付けられる必要があります。

## カスタムポリシーを使用する署名付き URL の署名を作成する
<a name="private-content-custom-policy-creating-signature"></a>

カスタムポリシーを使用する署名付き URL の署名は、ハッシュ化、署名、および base64 エンコードが行われたバージョンのポリシーステートメントです。カスタムポリシーの署名を作成するには、以下の手順を実行します。

ポリシーステートメントのハッシュ化、署名、およびエンコードを行う方法の詳細および例については、以下の各資料を参照してください。
+ [Linux コマンドおよび OpenSSL を使用した Base64 エンコードおよび暗号化](private-content-linux-openssl.md)
+ [署名付き URL の署名を作成するためのコード例](PrivateCFSignatureCodeAndExamples.md)<a name="private-content-custom-policy-creating-signature-download-procedure"></a>

**オプション 1: カスタムポリシーを使用して署名を作成するには**

1. 「[カスタムポリシーを使用する署名付き URL のポリシーステートメントを作成するには](#private-content-custom-policy-creating-policy-procedure)」の手順で作成した JSON ポリシーステートメントを、SHA-1 ハッシュ関数と生成した RSA または ECDSA プライベートキーを使用してハッシュ化し、署名します。空白は含まれていないが、まだ base64 エンコードされていないバージョンのポリシーステートメントを使用します。

   ハッシュ関数に必要なプライベートキーには、対応するパブリックキーがディストリビューション内のアクティブな信頼されたキーグループにあるものを使用してください。
**注記**  
ポリシーステートメントをハッシュ化および署名するための方法は、プログラミング言語およびプラットフォームによって異なります。サンプルコードについては、「[署名付き URL の署名を作成するためのコード例](PrivateCFSignatureCodeAndExamples.md)」を参照してください。

1. ハッシュ化および署名された文字列から、空白 (タブや改行文字を含む) を削除します。

1. MIME base64 エンコーディングを使用して文字列を Base64 エンコードします。詳細については、*RFC 2045, MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies* の [Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) を参照してください。

1. URL クエリ文字列内の無効な文字を有効な文字で置き換えます。次の表に無効な文字と有効な文字を示します。  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-custom-policy.html)

1. 結果の値を署名付き URL の `&Signature=` の後に付加し、「[カスタムポリシーを使用して署名付き URL を作成するには](#private-content-creating-signed-url-custom-policy-procedure)」に戻って、署名付き URL の各パートの連結を終了します。

# 署名付き Cookie を使用する
<a name="private-content-signed-cookies"></a>

CloudFront 署名付き Cookie を使用すると、現在の URL を変更したくない場合や、複数の制限付きファイル (ウェブサイトの購読者の領域にあるすべてのファイルなど) へのアクセスを提供する場合に、誰がコンテンツにアクセスできるかを制御できます。このトピックでは、署名付き Cookie を使用する際の考慮事項と、既定ポリシーとカスタムポリシーを使用するように署名付き Cookie を設定する方法について説明します。

**Topics**
+ [署名付き Cookie に既定ポリシーを使用するか、カスタムポリシーを使用するかを決定する](#private-content-choosing-canned-custom-cookies)
+ [署名付き Cookie の仕組み](#private-content-how-signed-cookies-work)
+ [署名付き Cookie の悪用を防止する](#private-content-signed-cookie-misuse)
+ [CloudFront が署名付き Cookie の有効期限切れ日時を確認するタイミング](#private-content-check-expiration-cookie)
+ [サンプルコードおよびサードパーティーツール](#private-content-overview-sample-code-cookies)
+ [既定ポリシーを使用して署名付き Cookie を設定する](private-content-setting-signed-cookie-canned-policy.md)
+ [カスタムポリシーを使用して署名付き Cookie を設定する](private-content-setting-signed-cookie-custom-policy.md)
+ [PHP を使用して署名付き cookie を作成する](signed-cookies-PHP.md)

## 署名付き Cookie に既定ポリシーを使用するか、カスタムポリシーを使用するかを決定する
<a name="private-content-choosing-canned-custom-cookies"></a>

署名付き Cookie を作成する場合、Cookie の有効期間など、署名付き Cookie で制限を指定する JSON 形式のポリシーステートメントを作成します。既定ポリシーまたはカスタムポリシーを使用できます。次の表では、既定ポリシーとカスタムポリシーを比較しています。


****  

| 説明 | 既定ポリシー | カスタムポリシー | 
| --- | --- | --- | 
| ポリシーステートメントを複数のファイル用に再利用できる。ポリシーステートメントを再利用するには、`Resource` オブジェクトでワイルドカード文字を使用する必要があります。(詳しくは、「[署名付き Cookie のカスタムポリシーのポリシーステートメントで指定する値](private-content-setting-signed-cookie-custom-policy.md#private-content-custom-policy-statement-cookies-values)」を参照してください)。 | いいえ | はい | 
| ユーザーがコンテンツへのアクセスを開始できる日時を指定できる | いいえ | はい (オプション) | 
| ユーザーがコンテンツにアクセスできなくなる日時を指定できる | はい | はい | 
| コンテンツにアクセスできるユーザーの IP アドレスまたは IP アドレス範囲を指定できる | いいえ | はい (オプション) | 

既定ポリシーを使用して署名付き Cookie を作成する方法については、「[既定ポリシーを使用して署名付き Cookie を設定する](private-content-setting-signed-cookie-canned-policy.md)」を参照してください。

カスタムポリシーを使用して署名付き Cookie を作成する方法については、「[カスタムポリシーを使用して署名付き Cookie を設定する](private-content-setting-signed-cookie-custom-policy.md)」を参照してください。

## 署名付き Cookie の仕組み
<a name="private-content-how-signed-cookies-work"></a>

ここでは、署名付き Cookie 用に CloudFront を設定する方法と、ユーザーが署名付き Cookie を含むリクエストを送信した場合の CloudFront の応答の概要を示します。

1. CloudFront ディストリビューションで、1 つ以上の信頼されたキーグループを指定します。指定したグループには、CloudFront が URL 署名の検証に使用できるパブリックキーが含まれている必要があります。対応するプライベートキーを使用して URL に署名します。

   詳細については、「[署名付き URL と署名付き Cookie を作成できる署名者を指定する](private-content-trusted-signers.md)」を参照してください。

1. ユーザーがコンテンツにアクセスできるかどうかを判断し、アクセスできる場合は、3 つの `Set-Cookie` ヘッダーをビューワーに送信するアプリケーションを開発します (各 `Set-Cookie` ヘッダーには名前と値のペアを 1 つだけ含めることができ、CloudFront 署名付き Cookie では 3 つの名前と値のペアが必要です)。ビューワーがプライベートコンテンツをリクエストする前に、ビューワーに `Set-Cookie` ヘッダーを送信する必要があります。Cookie の有効期限を短く設定した場合、ユーザーがアクセスを続行できるように、以降のリクエストに対してさらに 3 つの `Set-Cookie` ヘッダーを送信することもできます。

   通常、CloudFront ディストリビューションには少なくとも 2 つのキャッシュ動作があります。認証を必要としないものと、認証を必要とするものです。サイトのセキュリティで保護された部分のエラーページには、ログインページへのリダイレクタまたはリンクが含まれます。

   Cookie に基づいてファイルをキャッシュするようにディストリビューションを設定している場合、CloudFront は署名付き Cookie の属性に基づいて個別のファイルをキャッシュしません。

1. ユーザーがウェブサイトにサインインし、コンテンツに対して支払いをするか、またはその他のアクセスの要件を満たします。

1. アプリケーションは、レスポンスで `Set-Cookie` ヘッダーを返し、ビューワーは名前と値のペアを格納します。

1. ユーザーがファイルをリクエストします。

   ユーザーのブラウザまたはその他のビューワーは、ステップ 4 の名前と値のペアを取得し、リクエストの `Cookie` ヘッダーに追加します。これが署名付き Cookie です。

1. CloudFront はパブリックキーを使用して、署名付き Cookie の署名を検証し、Cookie が改ざんされていないことを確認します。署名が無効である場合、リクエストは拒否されます。

   Cookie の署名が有効である場合、CloudFront は Cookie のポリシーステートメントを参照して (または既定ポリシーを使用している場合はポリシーステートメントを作成して)、リクエストがまだ有効であることを確認します。たとえば、Cookie の開始日時と終了日時が指定されていれば、CloudFront は、アクセスが許可されている期間にユーザーがコンテンツへのアクセスを試みていることを確認します。

   リクエストがポリシーステートメントの要件を満たしている場合、CloudFront は制限されていないコンテンツの場合と同様にコンテンツを供給します。つまり、ファイルがエッジキャッシュにすでに存在するかどうかを確認し、必要に応じてリクエストをオリジンに転送して、ファイルをユーザーに返します。

## 署名付き Cookie の悪用を防止する
<a name="private-content-signed-cookie-misuse"></a>

`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 の有効期限切れ日時を確認するタイミング
<a name="private-content-check-expiration-cookie"></a>

署名付き Cookie がまだ有効であるかどうかを確認するために、CloudFront は HTTP リクエスト時に、Cookie の有効期限切れ日時を確認します。有効期限切れ時刻の直前にクライアントが大きなファイルのダウンロードを開始した場合、ダウンロード中に有効期限切れ時刻が経過してもダウンロードは完了します。TCP 接続が中断し、有効期限切れ時刻が経過した後にクライアントがダウンロードを再開した場合、ダウンロードは失敗します。

クライアントが、ファイルを断片的に取得するレンジ GET を使用した場合、有効期限切れ時刻が経過した後に実行された GET リクエストは失敗します。レンジ GET の詳細については、「[CloudFront がオブジェクトの部分的リクエスト (レンジ GET) を処理する方法](RangeGETs.md)」を参照してください。

## サンプルコードおよびサードパーティーツール
<a name="private-content-overview-sample-code-cookies"></a>

プライベートコンテンツ用のサンプルコードは、署名付き URL の署名を作成する方法のみを示しています。ただし、署名付き Cookie の署名を作成するプロセスは非常によく似ており、サンプルコードの多くの部分は関連しています。詳細については、以下の各トピックを参照してください。
+ [Perl を使用して URL 署名を作成する](CreateURLPerl.md)
+ [PHP を使用して URL 署名を作成する](CreateURL_PHP.md)
+ [C\$1 と .NET Framework を使用して URL 署名を作成する](CreateSignatureInCSharp.md)
+ [Java を使用して URL 署名を作成する](CFPrivateDistJavaDevelopment.md)

# 既定ポリシーを使用して署名付き Cookie を設定する
<a name="private-content-setting-signed-cookie-canned-policy"></a>

既定ポリシーを使用して署名付き Cookie を設定するには、以下のステップを実行します。署名を作成するには、「[既定ポリシーを使用する署名付き Cookie の署名を作成する](#private-content-canned-policy-signature-cookies)」を参照してください。<a name="private-content-setting-signed-cookie-canned-policy-procedure"></a>

**既定ポリシーを使用して署名付き Cookie を設定するには**

1. .NET または Java を使用して署名付き Cookie を作成しており、キーペアのプライベートキーをデフォルトの .pem 形式から .NET または Java 対応の形式に変更していない場合は、それを変換します。詳細については、「[プライベートキーの形式を変更する (.NET および Java のみ)](private-content-trusted-signers.md#private-content-reformatting-private-key)」を参照してください。

1. 承認されたビューワーに 3 つの `Set-Cookie` ヘッダーを送信するアプリケーションをプログラムします。各 `Set-Cookie` ヘッダーには名前と値のペアを 1 つだけ含めることができ、CloudFront 署名付き Cookie では 3 つの名前と値のペアが必要であるため、3 つの `Set-Cookie` ヘッダーが必要です。名前と値のペアは、`CloudFront-Expires`、`CloudFront-Signature`、および `CloudFront-Key-Pair-Id` です。アクセスを制御するファイルに対してユーザーが最初のリクエストを行う前に、値がビューワーに存在している必要があります。
**注記**  
一般的に、`Expires` 属性と `Max-Age` 属性を除外することをお勧めします。これらの属性を除外すると、ユーザーがブラウザを閉じたときに、ブラウザで Cookie が削除されるため、ユーザーがコンテンツに不正アクセスする可能性が低くなります。詳細については、「[署名付き Cookie の悪用を防止する](private-content-signed-cookies.md#private-content-signed-cookie-misuse)」を参照してください。

   **Cookie の属性の名前では、大文字と小文字が区別されます**。

   改行は、属性を判読しやすくするためにのみ含まれています。

   ```
   Set-Cookie: 
   CloudFront-Expires=date and time in Unix time format (in seconds) and Coordinated Universal Time (UTC); 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   Set-Cookie: 
   CloudFront-Signature=hashed and signed version of the policy statement; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   Set-Cookie: 
   CloudFront-Key-Pair-Id=public key ID for the CloudFront public key whose corresponding private key you're using to generate the signature; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   ```  
**(オプション) `Domain`**  
リクエストされたファイルのドメイン名。`Domain` 属性を指定しない場合、デフォルト値は URL のドメイン名で、指定されたドメイン名にのみ適用され、サブドメインには適用されません。`Domain` 属性を指定する場合、サブドメインにも適用されます。ドメイン名の先頭のドット (例えば、`Domain=.example.com`) はオプションです。さらに、`Domain` 属性を指定する場合は、URL のドメイン名と `Domain` 属性の値が一致している必要があります。  
CloudFront がディストリビューションに割り当てたドメイン名 (d111111abcdef8.cloudfront.net など) を指定することはできますが、\$1.cloudfront.net をドメイン名として指定することはできません。  
URL で代替ドメイン名 (example.com など) を使用する場合は、`Domain` 属性を指定するかどうかにかかわらず、代替ドメイン名をディストリビューションに追加する必要があります。詳細については、トピック「[すべてのディストリビューション設定リファレンス](distribution-web-values-specify.md)」の「[代替ドメイン名 (CNAME)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME)」を参照してください。  
**(オプション) `Path`**  
リクエストされたファイルのパス。`Path` 属性を指定しない場合、デフォルト値は URL のパスです。  
**`Secure`**  
リクエストを送信する前に、ビューワーが Cookie を暗号化することを要求します。Cookie の属性を中間者攻撃から保護するために、HTTPS 接続で `Set-Cookie` ヘッダーを送信することをお勧めします。  
**`HttpOnly`**  
ブラウザ (サポートされている場合) が Cookie 値とどのようにやり取りするかを定義します。`HttpOnly` では、Cookie 値は JavaScript からアクセスできません。この予防策は、クロスサイトスクリプティング (XSS) 攻撃の軽減に役立ちます。詳細については、「[HTTP Cookie の使用](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies)」を参照してください。  
**`CloudFront-Expires`**  
有効期限切れ日時を Unix 時間形式 (秒単位) および協定世界時 (UTC) で指定します。例えば、UTC の 2026 年 1 月 1 日午前 10 時 00 分は、Unix 時間形式の 1767290400 に変換されます。  
エポック時間を使用するには、`9223372036854775807` (2262 年 4 月 11 日金曜日の 23:47:16.854 UTC) 以前の日付に 64 ビット整数を指定します。  
UTC の詳細については、*RFC 3339, Date and Time on the Internet: Timestamps* ([https://tools.ietf.org/html/rfc3339](https://tools.ietf.org/html/rfc3339)) を参照してください。  
**`CloudFront-Signature`**  
ハッシュ化され、署名された base64 エンコードバージョンの JSON ポリシーステートメント。詳細については、「[既定ポリシーを使用する署名付き Cookie の署名を作成する](#private-content-canned-policy-signature-cookies)」を参照してください。  
**`CloudFront-Key-Pair-Id`**  
CloudFront パブリックキーの ID (`K2JCJMDEHXQW5F` など)。パブリックキー ID は、署名付き URL の検証に使用するパブリックキーを CloudFront に通知します。CloudFront は、署名内の情報をポリシーステートメント内の情報と比較して、URL が改ざんされていないことを確認します。  
このパブリックキーは、ディストリビューションの信頼された署名者であるキーグループに属している必要があります。詳細については、「[署名付き URL と署名付き Cookie を作成できる署名者を指定する](private-content-trusted-signers.md)」を参照してください。

以下は、ファイルの URL のディストリビューションに関連付けられたドメイン名を使用する場合の、1 つの署名付き Cookie の `Set-Cookie` ヘッダーの例です。

```
Set-Cookie: CloudFront-Expires=1426500000; Domain=d111111abcdef8.cloudfront.net; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=yXrSIgyQoeE4FBI4eMKF6ho~CA8_; Domain=d111111abcdef8.cloudfront.net; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=d111111abcdef8.cloudfront.net; Path=/images/*; Secure; HttpOnly
```

以下は、ファイルの URL に代替ドメイン名 example.org を使用している場合の、1 つの署名付き Cookie の `Set-Cookie` ヘッダーの例です。

```
Set-Cookie: CloudFront-Expires=1426500000; Domain=example.org; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=yXrSIgyQoeE4FBI4eMKF6ho~CA8_; Domain=example.org; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=example.org; Path=/images/*; Secure; HttpOnly
```

URL で代替ドメイン名 (example.com など) を使用する場合は、`Domain` 属性を指定するかどうかにかかわらず、代替ドメイン名をディストリビューションに追加する必要があります。詳細については、トピック「[すべてのディストリビューション設定リファレンス](distribution-web-values-specify.md)」の「[代替ドメイン名 (CNAME)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME)」を参照してください。

## 既定ポリシーを使用する署名付き Cookie の署名を作成する
<a name="private-content-canned-policy-signature-cookies"></a>

既定ポリシーを使用する署名付き Cookie の署名を作成するには、次の手順を実行します。

**Topics**
+ [既定ポリシーを使用する署名付き Cookie のポリシーステートメントを作成する](#private-content-canned-policy-statement-cookies)
+ [既定ポリシーを使用する署名付き Cookie の署名を作成するためのポリシーステートメントに署名する](#private-content-canned-policy-cookies-signing-policy-statement)

### 既定ポリシーを使用する署名付き Cookie のポリシーステートメントを作成する
<a name="private-content-canned-policy-statement-cookies"></a>

既定ポリシーを使用する署名付き Cookie を設定した場合、`CloudFront-Signature` 属性は、ポリシーステートメントのハッシュ化および署名されたバージョンです。カスタムポリシーを使用する署名付き Cookie とは異なり、既定ポリシーを使用する署名付き Cookie では、`Set-Cookie` ヘッダーにポリシーステートメントを含めません。ポリシーステートメントを作成するには、以下の手順を実行します。<a name="private-content-canned-policy-statement-cookies-procedure"></a>

**既定ポリシーを使用する署名付き Cookie のポリシーステートメントを作成するには**

1. 以下の JSON 形式および UTF-8 文字エンコードを使用してポリシーステートメントを構築します。すべての句読点および他のリテラル値を、指定されたとおりに正確に含めます。`Resource` および `DateLessThan` パラメータの詳細については、「[署名付き Cookie の既定ポリシーのポリシーステートメントで指定する値](#private-content-canned-policy-statement-cookies-values)」を参照してください。

   ```
   {
       "Statement": [
           {
               "Resource": "base URL or stream name",
               "Condition": {
                   "DateLessThan": {
                       "AWS:EpochTime": ending date and time in Unix time format and UTC
                   }
               }
           }
       ]
   }
   ```

1. ポリシーステートメントからすべての空白 (タブと改行文字を含む) を削除します。アプリケーションコード内の文字列にエスケープ文字を含めることが必要になる場合があります。

#### 署名付き Cookie の既定ポリシーのポリシーステートメントで指定する値
<a name="private-content-canned-policy-statement-cookies-values"></a>

既定ポリシーのポリシーステートメントを作成する場合、以下の値を指定します。

**リソース**  
クエリ文字列 (存在する場合) を含むベース URL。以下に例を示します。  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`  
`Resource` の日付形式は 1 つだけ指定できます。  
次の点に注意してください。  
+ **プロトコル** – 値は `http://` または `https://` で始まっている必要があります。
+ **クエリ文字列パラメータ** – クエリ文字列パラメータがない場合は、疑問符を省略します。
+ **代替ドメイン名** – URL で代替ドメイン名 (CNAME) を指定する場合は、ウェブページまたはアプリケーション内のファイルを参照するときに代替ドメイン名を指定する必要があります。ファイルの Amazon S3 URL を指定しないでください。

**DateLessThan**  
URL の有効期限切れ日時。Unix 時間形式 (秒単位) および協定世界時 (UTC) で指定します。値を引用符で囲まないでください。  
たとえば、UTC の 2015 年 3 月 16 日午前 10 時 00 分は、UNIX 時間形式の 1426500000 に変換されます。  
この値は、`CloudFront-Expires` ヘッダーの `Set-Cookie` 属性の値と一致する必要があります。値を引用符で囲まないでください。  
詳細については、「[CloudFront が署名付き Cookie の有効期限切れ日時を確認するタイミング](private-content-signed-cookies.md#private-content-check-expiration-cookie)」を参照してください。

#### 既定ポリシーのポリシーステートメントの例
<a name="private-content-canned-policy-cookies-sample-policy-statement"></a>

署名付き Cookie 内で以下のポリシーステートメントの例を使用すると、ユーザーは、UTC の 2015 年 3 月 16 日午前 10 時 00 分までファイル `https://d111111abcdef8.cloudfront.net/horizon.jpg` にアクセスできます。

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/horizon.jpg?size=large&license=yes",
            "Condition": {
                "DateLessThan": {
                    "AWS:EpochTime": 1426500000
                }
            }
        }
    ]
}
```

### 既定ポリシーを使用する署名付き Cookie の署名を作成するためのポリシーステートメントに署名する
<a name="private-content-canned-policy-cookies-signing-policy-statement"></a>

`CloudFront-Signature` ヘッダーの `Set-Cookie` 属性の値を作成するには、「[既定ポリシーを使用する署名付き Cookie のポリシーステートメントを作成するには](#private-content-canned-policy-statement-cookies-procedure)」で作成したポリシーステートメントをハッシュ化して署名します。

ポリシーステートメントのハッシュ化、署名、およびエンコードを行う方法の詳細および例については、以下のトピックを参照してください。
+ [Linux コマンドおよび OpenSSL を使用した Base64 エンコードおよび暗号化](private-content-linux-openssl.md)
+ [署名付き URL の署名を作成するためのコード例](PrivateCFSignatureCodeAndExamples.md)<a name="private-content-canned-policy-cookie-creating-signature-procedure"></a>

**既定ポリシーを使用して署名付き Cookie の署名を作成するには**

1. 「[既定ポリシーを使用する署名付き Cookie のポリシーステートメントを作成するには](#private-content-canned-policy-statement-cookies-procedure)」の手順で作成したポリシーステートメントを、SHA-1 ハッシュ関数と RSA を使用してハッシュ化し、署名します。空白を含まないバージョンのポリシーステートメントを使用します。

   ハッシュ関数に必要なプライベートキーには、対応するパブリックキーがディストリビューション内のアクティブな信頼されたキーグループにあるものを使用してください。
**注記**  
ポリシーステートメントをハッシュ化および署名するための方法は、プログラミング言語およびプラットフォームによって異なります。サンプルコードについては、「[署名付き URL の署名を作成するためのコード例](PrivateCFSignatureCodeAndExamples.md)」を参照してください。

1. ハッシュ化および署名された文字列から、空白 (タブや改行文字を含む) を削除します。

1. MIME base64 エンコーディングを使用して文字列を Base64 エンコードします。詳細については、*RFC 2045, MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies* の [Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) を参照してください。

1. URL クエリ文字列内の無効な文字を有効な文字で置き換えます。次の表に無効な文字と有効な文字を示します。  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-setting-signed-cookie-canned-policy.html)

1. 結果の値を、`Set-Cookie` の名前と値のペアの `CloudFront-Signature` ヘッダーに含めます。次に、「[既定ポリシーを使用して署名付き Cookie を設定するには](#private-content-setting-signed-cookie-canned-policy-procedure)」に戻り、`Set-Cookie` の `CloudFront-Key-Pair-Id` ヘッダーを追加します。

# カスタムポリシーを使用して署名付き Cookie を設定する
<a name="private-content-setting-signed-cookie-custom-policy"></a>

カスタムポリシーを使用する署名付き Cookie を設定するには、以下の手順を実行します。<a name="private-content-setting-signed-cookie-custom-policy-procedure"></a>

**カスタムポリシーを使用して署名付き Cookie を設定するには**

1. .NET または Java を使用して署名付き URL を作成しており、キーペアのプライベートキーをデフォルトの .pem 形式から .NET または Java 対応の形式に変更していない場合は、それを変換します。詳細については、「[プライベートキーの形式を変更する (.NET および Java のみ)](private-content-trusted-signers.md#private-content-reformatting-private-key)」を参照してください。

1. 承認されたビューワーに 3 つの `Set-Cookie` ヘッダーを送信するアプリケーションをプログラムします。各 `Set-Cookie` ヘッダーには名前と値のペアを 1 つだけ含めることができ、CloudFront 署名付き Cookie では 3 つの名前と値のペアが必要であるため、3 つの `Set-Cookie` ヘッダーが必要です。名前と値のペアは、`CloudFront-Policy`、`CloudFront-Signature`、および `CloudFront-Key-Pair-Id` です。アクセスを制御するファイルに対してユーザーが最初のリクエストを行う前に、値がビューワーに存在している必要があります。
**注記**  
一般的に、`Expires` 属性と `Max-Age` 属性を除外することをお勧めします。これにより、ユーザーがブラウザを閉じたときに、ブラウザで Cookie が削除されるため、ユーザーがコンテンツに不正アクセスする可能性が低くなります。詳細については、「[署名付き Cookie の悪用を防止する](private-content-signed-cookies.md#private-content-signed-cookie-misuse)」を参照してください。

   **Cookie の属性の名前では、大文字と小文字が区別されます**。

   改行は、属性を判読しやすくするためにのみ含まれています。

   ```
   Set-Cookie: 
   CloudFront-Policy=base64 encoded version of the policy statement; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   
   Set-Cookie: 
   CloudFront-Signature=hashed and signed version of the policy statement; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   Set-Cookie: 
   CloudFront-Key-Pair-Id=public key ID for the CloudFront public key whose corresponding private key you're using to generate the signature; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   ```  
**(オプション) `Domain`**  
リクエストされたファイルのドメイン名。`Domain` 属性を指定しない場合、デフォルト値は URL のドメイン名で、指定されたドメイン名にのみ適用され、サブドメインには適用されません。`Domain` 属性を指定する場合、サブドメインにも適用されます。ドメイン名の先頭のドット (例えば、`Domain=.example.com`) はオプションです。さらに、`Domain` 属性を指定する場合は、URL のドメイン名と `Domain` 属性の値が一致している必要があります。  
CloudFront がディストリビューションに割り当てたドメイン名 (d111111abcdef8.cloudfront.net など) を指定することはできますが、\$1.cloudfront.net をドメイン名として指定することはできません。  
URL で代替ドメイン名 (example.com など) を使用する場合は、`Domain` 属性を指定するかどうかにかかわらず、代替ドメイン名をディストリビューションに追加する必要があります。詳細については、トピック「[すべてのディストリビューション設定リファレンス](distribution-web-values-specify.md)」の「[代替ドメイン名 (CNAME)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME)」を参照してください。  
**(オプション) `Path`**  
リクエストされたファイルのパス。`Path` 属性を指定しない場合、デフォルト値は URL のパスです。  
**`Secure`**  
リクエストを送信する前に、ビューワーが Cookie を暗号化することを要求します。Cookie の属性を中間者攻撃から保護するために、HTTPS 接続で `Set-Cookie` ヘッダーを送信することをお勧めします。  
**`HttpOnly`**  
ビューワーが HTTP または HTTPS リクエストでのみ Cookie を送信することを要求します。  
**`CloudFront-Policy`**  
空白が削除されて base64 エンコードされた、JSON 形式のポリシーステートメント。詳細については、「[カスタムポリシーを使用する署名付き Cookie の署名を作成する](#private-content-custom-policy-signature-cookies)」を参照してください。  
ポリシーステートメントは、署名付き Cookie によってユーザーに許可されるアクセスをコントロールします。これには、ユーザーがアクセスできるファイル、有効期限切れ日時、URL が有効になる日時 (オプション)、ファイルへのアクセスが許可されている IP アドレスまたは IP アドレス範囲 (オプション) が含まれます。  
**`CloudFront-Signature`**  
ハッシュ化され、署名された base64 エンコードバージョンの JSON ポリシーステートメント。詳細については、「[カスタムポリシーを使用する署名付き Cookie の署名を作成する](#private-content-custom-policy-signature-cookies)」を参照してください。  
**`CloudFront-Key-Pair-Id`**  
CloudFront パブリックキーの ID (`K2JCJMDEHXQW5F` など)。パブリックキー ID は、署名付き URL の検証に使用するパブリックキーを CloudFront に通知します。CloudFront は、署名内の情報をポリシーステートメント内の情報と比較して、URL が改ざんされていないことを確認します。  
このパブリックキーは、ディストリビューションの信頼された署名者であるキーグループに属している必要があります。詳細については、「[署名付き URL と署名付き Cookie を作成できる署名者を指定する](private-content-trusted-signers.md)」を参照してください。

## カスタムポリシーの `Set-Cookie` ヘッダーの例
<a name="example-set-cookie-headers-custom-policy"></a>

以下の `Set-Cookie` ヘッダーペアの例を参照してください。

代替ドメイン名 (example.org など) を URL で使用する場合は、`Domain` 属性を指定するかどうかにかかわらず、代替ドメイン名をディストリビューションに追加する必要があります。詳細については、「[すべてのディストリビューション設定リファレンス](distribution-web-values-specify.md)」トピックの「[代替ドメイン名 (CNAME)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME)」を参照してください。

**Example 例 1**  
ディストリビューションに関連するドメイン名をファイルの URL で使用している場合、1 つの署名付き Cookie で `Set-Cookie` ヘッダーを使用できます。  

```
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovL2QxMTExMTFhYmNkZWY4LmNsb3VkZnJvbnQubmV0L2dhbWVfZG93bmxvYWQuemlwIiwiQ29uZGl0aW9uIjp7IklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIxOTIuMC4yLjAvMjQifSwiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MjY1MDAwMDB9fX1dfQ__; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=dtKhpJ3aUYxqDIwepczPiDb9NXQ_; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
```

**Example 例 2**  
代替ドメイン名 (example.org) をファイルの URL で使用している場合、1 つの署名付き Cookie で `Set-Cookie` ヘッダーを使用できます。  

```
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovL2QxMTExMTFhYmNkZWY4LmNsb3VkZnJvbnQubmV0L2dhbWVfZG93bmxvYWQuemlwIiwiQ29uZGl0aW9uIjp7IklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIxOTIuMC4yLjAvMjQifSwiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MjY1MDAwMDB9fX1dfQ__; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=dtKhpJ3aUYxqDIwepczPiDb9NXQ_; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=example.org; Path=/; Secure; HttpOnly
```

**Example 例 3**  
ディストリビューションに関連するドメイン名をファイルの URL で使用している場合、1 つの署名付きリクエストで `Set-Cookie` ヘッダーペアを使用できます。  

```
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovL2QxMTExMTFhYmNkZWY4LmNsb3VkZnJvbnQubmV0L2dhbWVfZG93bmxvYWQuemlwIiwiQ29uZGl0aW9uIjp7IklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIxOTIuMC4yLjAvMjQifSwiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MjY1MDAwMDB9fX1dfQ__; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=dtKhpJ3aUYxqDIwepczPiDb9NXQ_; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=dd111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
```

**Example 例 4**  
ディストリビューションに関連付けられた代替ドメイン名をファイルの URL で使用している場合、1 つの署名付きリクエストで `Set-Cookie` ヘッダーペアを使用できます。  

```
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovL2QxMTExMTFhYmNkZWY4LmNsb3VkZnJvbnQubmV0L2dhbWVfZG93bmxvYWQuemlwIiwiQ29uZGl0aW9uIjp7IklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIxOTIuMC4yLjAvMjQifSwiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MjY1MDAwMDB9fX1dfQ__; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=dtKhpJ3aUYxqDIwepczPiDb9NXQ_; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=example.org; Path=/; Secure; HttpOnly
```

## 既定ポリシーを使用する署名付き Cookie のポリシーステートメントを作成する
<a name="private-content-custom-policy-statement-cookies"></a>

カスタムポリシーのポリシーステートメントを作成するには、以下の手順を実行します。さまざまな方法でファイルへのアクセスを制御するポリシーステートメントのいくつかの例については、「[カスタムポリシーを使用する署名付き Cookie のポリシーステートメントの例](#private-content-custom-policy-statement-signed-cookies-examples)」を参照してください。<a name="private-content-custom-policy-statement-cookies-procedure"></a>

**カスタムポリシーを使用する署名付き Cookie のポリシーステートメントを作成するには**

1. 以下の JSON 形式を使用してポリシーステートメントを構築します。

   ```
   {
       "Statement": [
           {
               "Resource": "URL of the file",
               "Condition": {
                   "DateLessThan": {
                       "AWS:EpochTime":required ending date and time in Unix time format and UTC
                   },
                   "DateGreaterThan": {
                       "AWS:EpochTime":optional beginning date and time in Unix time format and UTC
                   },
                   "IpAddress": {
                       "AWS:SourceIp": "optional IP address"
                   }
               }
           }
       ]
   }
   ```

   次の点に注意してください。
   + 1 つのステートメントのみを含めることができます。
   + UTF-8 文字エンコードを使用します。
   + すべての句読点およびパラメータ名を、指定されたとおりに正確に含めます。パラメータ名の省略形は受け付けられません。
   + `Condition` セクションのパラメータの順序は問題ではありません。
   + `Resource`、`DateLessThan`、`DateGreaterThan`、および `IpAddress` の値については、「[署名付き Cookie のカスタムポリシーのポリシーステートメントで指定する値](#private-content-custom-policy-statement-cookies-values)」を参照してください。

1. ポリシーステートメントからすべての空白 (タブと改行文字を含む) を削除します。アプリケーションコード内の文字列にエスケープ文字を含めることが必要になる場合があります。

1. MIME base64 エンコーディングを使用してポリシーステートメントを Base64 エンコードします。詳細については、*RFC 2045, MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies* の [Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) を参照してください。

1. URL クエリ文字列内の無効な文字を有効な文字で置き換えます。次の表に無効な文字と有効な文字を示します。  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-setting-signed-cookie-custom-policy.html)

1. 結果の値を、`Set-Cookie` ヘッダーの `CloudFront-Policy=` の後に含めます。

1. ポリシーステートメントのハッシュ化、署名、および base64 エンコードを行って、`Set-Cookie` 用に `CloudFront-Signature` ヘッダーの署名を作成します。詳細については、「[カスタムポリシーを使用する署名付き Cookie の署名を作成する](#private-content-custom-policy-signature-cookies)」を参照してください。

### 署名付き Cookie のカスタムポリシーのポリシーステートメントで指定する値
<a name="private-content-custom-policy-statement-cookies-values"></a>

カスタムポリシーのポリシーステートメントを作成する場合、以下の値を指定します。

**リソース**  
クエリ文字列 (存在する場合) を含むベース URL。  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`  
`Resource` パラメータを省略した場合、ユーザーは、署名付き URL の作成に使用するキーペアに関連付けられたあらゆるディストリビューションに関連付けられるすべてのファイルにアクセスできます。
`Resource` の日付形式は 1 つだけ指定できます。  
次の点に注意してください。  
+ **プロトコル** – 値は `http://` または `https://` で始まっている必要があります。
+ **クエリ文字列パラメータ** – クエリ文字列パラメータがない場合は、疑問符を省略します。
+ **ワイルドカード** – 0 個以上の文字に一致するワイルドカード文字 (\$1)、または 1 つの文字に一致するワイルドカード文字 (?) を使用できます。文字列のどこにでも含めることができます。次に例を示します。この値は、

  `https://d111111abcdef8.cloudfront.net/*game_download.zip*`

  たとえば、次のファイルを含みます。
  + `https://d111111abcdef8.cloudfront.net/game_download.zip`
  + `https://d111111abcdef8.cloudfront.net/example_game_download.zip?license=yes`
  + `https://d111111abcdef8.cloudfront.net/test_game_download.zip?license=temp`
+ **代替ドメイン名** – URL で代替ドメイン名 (CNAME) を指定する場合は、ウェブページまたはアプリケーション内のファイルを参照するときに代替ドメイン名を指定する必要があります。ファイルの Amazon S3 URL を指定しないでください。

**DateLessThan**  
URL の有効期限切れ日時。Unix 時間形式 (秒単位) および協定世界時 (UTC) で指定します。値を引用符で囲まないでください。  
たとえば、UTC の 2015 年 3 月 16 日午前 10 時 00 分は、UNIX 時間形式の 1426500000 に変換されます。  
詳細については、「[CloudFront が署名付き Cookie の有効期限切れ日時を確認するタイミング](private-content-signed-cookies.md#private-content-check-expiration-cookie)」を参照してください。

**DateGreaterThan (オプション)**  
オプションの URL 開始日時。Unix 時間形式 (秒単位) および協定世界時 (UTC) で指定します。ユーザーは、指定された日時が過ぎるまでファイルにアクセスできません。値を引用符で囲まないでください。

**IpAddress (オプション)**  
GET リクエストを実行するクライアントの IP アドレス。次の点に注意してください。  
+ ファイルへのアクセスをすべての IP アドレスに許可するには、`IpAddress` パラメータを省略します。
+ IP アドレスまたは IP アドレス範囲を 1 つ指定できます。たとえば、2 つの別々の範囲のどちらかにクライアントの IP アドレスが入っている場合にアクセスを許可するようなポリシーを設定することはできません。
+ 1 つの IP アドレスからのアクセスを許可するには、以下のように指定します。

  `"`*IPv4 IP アドレス*`/32"`
+ IP アドレス範囲は標準の IPv4 CIDR 形式 (`192.0.2.0/24` など) で指定する必要があります。詳細については、*RFC 4632, Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan* ([https://tools.ietf.org/html/rfc4632](https://tools.ietf.org/html/rfc4632)) を参照してください。
**重要**  
IPv6 形式の IP アドレス (例: 2001:0db8:85a3::8a2e:0370:7334) はサポートされていません。

  `IpAddress` を含むカスタムポリシーを使用する場合、ディストリビューションで IPv6 は有効にしません。一部のコンテンツへのアクセスを IP アドレスによって制限し、他のコンテンツで IPv6 リクエストをサポートする場合、2 つのディストリビューションを作成します。詳細については、トピック「[すべてのディストリビューション設定リファレンス](distribution-web-values-specify.md)」の「[IPv6 を有効にする (ビューワーリクエスト)](DownloadDistValuesGeneral.md#DownloadDistValuesEnableIPv6)」を参照してください。

## カスタムポリシーを使用する署名付き Cookie のポリシーステートメントの例
<a name="private-content-custom-policy-statement-signed-cookies-examples"></a>

以下のポリシーステートメントの例は、特定のファイル、ディレクトリ内のすべてのファイル、またはキーペア ID に関連付けられたすべてのファイルへのアクセスを制御する方法を示しています。また、この例は、個々の IP アドレスまたは IP アドレス範囲からのアクセスを制御する方法、および指定された日時以降にユーザーが署名付き Cookie を使用することを禁止する方法も示しています。

これらの例のいずれかをコピーして貼り付ける場合は、すべての空白 (タブと改行文字を含む) を削除し、値を独自の値で置き換え、右の中かっこ ( \$1 ) の後に改行文字を含めます。

詳細については、「[署名付き Cookie のカスタムポリシーのポリシーステートメントで指定する値](#private-content-custom-policy-statement-cookies-values)」を参照してください。

**Topics**
+ [ポリシーステートメントの例: IP アドレス範囲から 1 つのファイルにアクセスする](#private-content-custom-policy-statement-signed-cookies-example-one-object)
+ [ポリシーステートメントの例: IP アドレス範囲からディレクトリ内のすべてのファイルにアクセスする](#private-content-custom-policy-statement-signed-cookies-example-all-objects)
+ [ポリシーステートメントの例: キーペア ID に関連付けられたすべてのファイルに 1 つの IP アドレスからアクセスする](#private-content-custom-policy-statement-signed-cookies-example-one-ip)

### ポリシーステートメントの例: IP アドレス範囲から 1 つのファイルにアクセスする
<a name="private-content-custom-policy-statement-signed-cookies-example-one-object"></a>

次の署名付き Cookie 内のカスタムポリシーの例では、UTC の 2023 年 1 月 1 日午前 10 時 00 分まで、範囲 `192.0.2.0/24` の IP アドレスから、ユーザーがファイル `https://d111111abcdef8.cloudfront.net/game_download.zip` にアクセスできることを指定しています。

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/game_download.zip",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1767290400
                }
            }
        }
    ]
}
```

### ポリシーステートメントの例: IP アドレス範囲からディレクトリ内のすべてのファイルにアクセスする
<a name="private-content-custom-policy-statement-signed-cookies-example-all-objects"></a>

以下のカスタムポリシーの例では、`training` パラメータの \$1 ワイルドカード文字が示すとおり、`Resource` ディレクトリ内のあらゆるファイルを対象とする署名付き Cookie を作成できます。UTC の 2013 年 1 月 1 日午前 10 時 00 分まで、範囲 `192.0.2.0/24` の IP アドレスから、ユーザーはファイルにアクセスできます。

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/training/*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1767290400
                }
            }
        }
    ]
}
```

このポリシーを使用する各署名付き Cookie には、たとえば次のように、特定のファイルを識別するベース URL が含まれます。

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

### ポリシーステートメントの例: キーペア ID に関連付けられたすべてのファイルに 1 つの IP アドレスからアクセスする
<a name="private-content-custom-policy-statement-signed-cookies-example-one-ip"></a>

以下のカスタムポリシーの例では、`Resource` パラメータの \$1 ワイルドカード文字が示すとおり、あらゆるディストリビューションに関連付けられたあらゆるファイルを対象とする署名付き Cookie を設定できます。ユーザーは IP アドレス `192.0.2.10/32` を使用する必要があります。(CIDR 表記の値 `192.0.2.10/32` は 1 つの IP アドレス `192.0.2.10` を参照します)。ファイルは、UTC の 2013 年 1 月 1 日午前 10 時 00 分から UTC の 2013 年 1 月 2 日午前 10 時 00 分まで使用できます。

```
{
    "Statement": [
        {
            "Resource": "https://*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.10/32"
                },
                "DateGreaterThan": {
                    "AWS:EpochTime": 1767290400
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1767376800
                }
            }
        }
    ]
}
```

このポリシーを含める各署名付き Cookie には、たとえば次のように、特定の CloudFront ディストリビューション内の特定のファイルを識別するベース URL が含まれます。

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

署名付き Cookie にはキーペア ID も含まれます。キーペア ID は、ベース URL に指定されたディストリビューション (d111111abcdef8.cloudfront.net) 内の信頼されたキーグループに関連付けられる必要があります。

## カスタムポリシーを使用する署名付き Cookie の署名を作成する
<a name="private-content-custom-policy-signature-cookies"></a>

カスタムポリシーを使用する署名付き Cookie の署名は、ハッシュ化、署名、および base64 エンコードが行われたバージョンのポリシーステートメントです。

ポリシーステートメントのハッシュ化、署名、およびエンコードを行う方法の詳細および例については、以下の各資料を参照してください。
+ [Linux コマンドおよび OpenSSL を使用した Base64 エンコードおよび暗号化](private-content-linux-openssl.md)
+ [署名付き URL の署名を作成するためのコード例](PrivateCFSignatureCodeAndExamples.md)<a name="private-content-custom-policy-signature-cookies-procedure"></a>

**カスタムポリシーを使用して署名付き Cookie の署名を作成するには**

1. 「[カスタムポリシーを使用する署名付き URL のポリシーステートメントを作成するには](private-content-creating-signed-url-custom-policy.md#private-content-custom-policy-creating-policy-procedure)」の手順で作成した JSON ポリシーステートメントを、SHA-1 ハッシュ関数と RSA を使用してハッシュ化し、署名します。空白は含まれていないが、まだ base64 エンコードされていないバージョンのポリシーステートメントを使用します。

   ハッシュ関数に必要なプライベートキーには、対応するパブリックキーがディストリビューション内のアクティブな信頼されたキーグループにあるものを使用してください。
**注記**  
ポリシーステートメントをハッシュ化および署名するための方法は、プログラミング言語およびプラットフォームによって異なります。サンプルコードについては、「[署名付き URL の署名を作成するためのコード例](PrivateCFSignatureCodeAndExamples.md)」を参照してください。

1. ハッシュ化および署名された文字列から、空白 (タブや改行文字を含む) を削除します。

1. MIME base64 エンコーディングを使用して文字列を Base64 エンコードします。詳細については、*RFC 2045, MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies* の [Section 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) を参照してください。

1. URL クエリ文字列内の無効な文字を有効な文字で置き換えます。次の表に無効な文字と有効な文字を示します。  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-setting-signed-cookie-custom-policy.html)

1. 結果の値を、`Set-Cookie` の名前と値のペアの `CloudFront-Signature=` ヘッダーに含めて、「[カスタムポリシーを使用して署名付き Cookie を設定するには](#private-content-setting-signed-cookie-custom-policy-procedure)」に戻り、`Set-Cookie` の `CloudFront-Key-Pair-Id` ヘッダーを追加します。

# PHP を使用して署名付き cookie を作成する
<a name="signed-cookies-PHP"></a>

次のコード例は、動画へのリンクを作成するという点で [PHP を使用して URL 署名を作成する](CreateURL_PHP.md) の例に似ています。ただし、コード内の URL に署名する代わりに、この例では `create_signed_cookies()` 関数を使用して cookie に署名します。クライアント側のプレイヤーは、cookie を使用して CloudFront ディストリビューションへの各リクエストを認証します。

このアプローチは、HTTP ライブストリーミング (HLS) や HTTP 経由の動的アダプティブストリーミング (DASH) などのコンテンツをストリーミングする場合に便利です。この場合、クライアントはマニフェスト、セグメント、および関連する再生アセットを取得するために複数のリクエストを行う必要があります。署名付き cookie を使用することで、クライアントはセグメントごとに新しい署名付き URL を生成することなく、各リクエストを認証できます。

**注記**  
URL 署名の作成は、署名付き cookie を使用してプライベートコンテンツを提供するプロセスの一環にすぎません。詳細については、「[署名付き Cookie を使用する](private-content-signed-cookies.md)」を参照してください。



**Topics**
+ [RSA SHA-1 署名を作成する](#create-rsa-sha-1signature-cookies)
+ [署名付き cookie を作成する](#create-the-signed-cookie)
+ [完全なコード](#full-code-signed-cookies)

以下のセクションでは、コード例を個別のパートに分解します。完全な[コードサンプル](#full-code-signed-cookies)は以下にあります。

## RSA SHA-1 署名を作成する
<a name="create-rsa-sha-1signature-cookies"></a>

このコード例では、次の操作を行います。

1. 関数 `rsa_sha1_sign` は、ポリシーステートメントをハッシュ化して署名します。必要な引数は、ポリシーステートメントと、ディストリビューションの信頼されたキーグループにあるパブリックキーに対応するプライベートキーです。

1. 次に、`url_safe_base64_encode` 関数で、URL で使用可能なバージョンの署名を作成します。

   ```
   function rsa_sha1_sign($policy, $private_key_filename) {
       $signature = "";
       $fp = fopen($private_key_filename, "r");
       $priv_key = fread($fp, 8192);
       fclose($fp);
       $pkeyid = openssl_get_privatekey($priv_key);
       openssl_sign($policy, $signature, $pkeyid);
       openssl_free_key($pkeyid);
       return $signature;
   }
   
   function url_safe_base64_encode($value) {
       $encoded = base64_encode($value);
       return str_replace(
           array('+', '=', '/'),
           array('-', '_', '~'),
           $encoded);
   }
   ```

## 署名付き cookie を作成する
<a name="create-the-signed-cookie"></a>

次のコードコンストラクトは、cookie 属性として `CloudFront-Expires`、`CloudFront-Signature`、`CloudFront-Key-Pair-Id` を使用して署名付き cookie を作成します。このコードでは、カスタムポリシーを使用します。

```
function create_signed_cookies($resource, $private_key_filename, $key_pair_id, $expires, $client_ip = null) {
    $policy = array(
        'Statement' => array(
            array(
                'Resource' => $resource,
                'Condition' => array(
                    'DateLessThan' => array('AWS:EpochTime' => $expires)
                )
            )
        )
    );

    if ($client_ip) {
        $policy['Statement'][0]['Condition']['IpAddress'] = array('AWS:SourceIp' => $client_ip . '/32');
    }

    $policy = json_encode($policy);
    $encoded_policy = url_safe_base64_encode($policy);
    $signature = rsa_sha1_sign($policy, $private_key_filename);
    $encoded_signature = url_safe_base64_encode($signature);

    return array(
        'CloudFront-Policy' => $encoded_policy,
        'CloudFront-Signature' => $encoded_signature,
        'CloudFront-Key-Pair-Id' => $key_pair_id
    );
}
```

詳細については、「[カスタムポリシーを使用して署名付き Cookie を設定する](private-content-setting-signed-cookie-custom-policy.md)」を参照してください。

## 完全なコード
<a name="full-code-signed-cookies"></a>

次のコードサンプルでは、PHP で CloudFront 署名付き cookie を作成する詳細な方法を示します。完全な例については、[demo-php.zip](samples/demo-php.zip) ファイルからダウンロードできます。

次の例では、`$policy Condition` エレメントを変更して、IPv4 アドレス範囲と IPv6 アドレス範囲の両方を許可できます。例については、「Amazon Simple Storage Service ユーザーガイド」の「[IAM ポリシーでの IPv6 アドレスの使用](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ipv6-access.html#ipv6-access-iam)」を参照してください。**

```
<?php

function rsa_sha1_sign($policy, $private_key_filename) {
    $signature = "";
    $fp = fopen($private_key_filename, "r");
    $priv_key = fread($fp, 8192);
    fclose($fp);
    $pkeyid = openssl_get_privatekey($priv_key);
    openssl_sign($policy, $signature, $pkeyid);
    openssl_free_key($pkeyid);
    return $signature;
}

function url_safe_base64_encode($value) {
    $encoded = base64_encode($value);
    return str_replace(
        array('+', '=', '/'),
        array('-', '_', '~'),
        $encoded);
}

function create_signed_cookies($resource, $private_key_filename, $key_pair_id, $expires, $client_ip = null) {
    $policy = array(
        'Statement' => array(
            array(
                'Resource' => $resource,
                'Condition' => array(
                    'DateLessThan' => array('AWS:EpochTime' => $expires)
                )
            )
        )
    );

    if ($client_ip) {
        $policy['Statement'][0]['Condition']['IpAddress'] = array('AWS:SourceIp' => $client_ip . '/32');
    }

    $policy = json_encode($policy);
    $encoded_policy = url_safe_base64_encode($policy);
    $signature = rsa_sha1_sign($policy, $private_key_filename);
    $encoded_signature = url_safe_base64_encode($signature);

    return array(
        'CloudFront-Policy' => $encoded_policy,
        'CloudFront-Signature' => $encoded_signature,
        'CloudFront-Key-Pair-Id' => $key_pair_id
    );
}



$private_key_filename = '/home/test/secure/example-priv-key.pem';
$key_pair_id = 'K2JCJMDEHXQW5F';
$base_url = 'https://d1234.cloudfront.net';

$expires = time() + 3600; // 1 hour from now

// Get the viewer real IP from the x-forward-for header as $_SERVER['REMOTE_ADDR'] will return viewer facing IP. An alternative option is to use CloudFront-Viewer-Address header. Note that this header is a trusted CloudFront immutable header. Example format: IP:PORT ("CloudFront-Viewer-Address": "1.2.3.4:12345")
$client_ip = $_SERVER['HTTP_X_FORWARDED_FOR'];


// For HLS manifest and segments (using wildcard)
$hls_resource = $base_url . '/sign/*';
$signed_cookies = create_signed_cookies($hls_resource, $private_key_filename, $key_pair_id, $expires, $client_ip);

// Set the cookies
$cookie_domain = parse_url($base_url, PHP_URL_HOST);
foreach ($signed_cookies as $name => $value) {
    setcookie($name, $value, $expires, '/', $cookie_domain, true, true);
}

?>

<!DOCTYPE html>
<html>
<head>
    <title>CloudFront Signed HLS Stream with Cookies</title>
</head>
<body>
    <h1>Amazon CloudFront Signed HLS Stream with Cookies</h1>
    <h2>Expires at <?php echo gmdate('Y-m-d H:i:s T', $expires); ?> only viewable by IP <?php echo $client_ip; ?></h2>
    
    <div id='hls-video'>
        <video id="video" width="640" height="360" controls></video>
    </div>

    <script src="https://cdn.jsdelivr.net/npm/hls.js@latest"></script>
    <script>
        var video = document.getElementById('video');
        var manifestUrl = '<?php echo $base_url; ?>/sign/manifest.m3u8';
        
        if (Hls.isSupported()) {
            var hls = new Hls();
            hls.loadSource(manifestUrl);
            hls.attachMedia(video);
        }
        else if (video.canPlayType('application/vnd.apple.mpegurl')) {
            video.src = manifestUrl;
        }
    </script>
</body>
</html>
```

署名付き cookie を使用する代わりに、署名付き URL を使用できます。詳細については、「[PHP を使用して URL 署名を作成する](CreateURL_PHP.md)」を参照してください。

# Linux コマンドおよび OpenSSL を使用した Base64 エンコードおよび暗号化
<a name="private-content-linux-openssl"></a>

次の Linux コマンドラインのコマンドおよび OpenSSL を使用して、ポリシーステートメントをハッシュ化して署名します。次に、署名を base64 エンコードし、URL クエリ文字列パラメータでの無効な文字を有効な文字置き換えます。

OpenSSL の詳細については、「」にアクセスしてください[https://www.openssl.org](https://www.openssl.org)

```
cat policy | tr -d "\n" | tr -d " \t\n\r" | openssl sha1 -sign private_key.pem | openssl base64 -A | tr -- '+=/' '-_~'
```

上記のコマンドでは:
+ `cat` が `policy` ファイルを読み取ります。
+ `tr -d "\n" | tr -d " \t\n\r"` は、`cat` によって追加された空白や改行文字を削除します。
+ OpenSSL は、SHA-1 を使用してファイルをハッシュし、プライベートキーファイル `private_key.pem` を使用して署名します。プライベートキー署名は、RSA 2048 または ECDSA 256 のいずれかです。
+ OpenSSL は、ハッシュされ、署名されたポリシーステートメントを base64 でエンコードします。
+ `tr` は、URL クエリ文字列パラメータの無効な文字を有効な文字で置き換えます。

署名の作成方法を示すコード例については、「[署名付き URL の署名を作成するためのコード例](PrivateCFSignatureCodeAndExamples.md)」を参照してください。

# 署名付き URL の署名を作成するためのコード例
<a name="PrivateCFSignatureCodeAndExamples"></a>

このセクションには、署名付き URL の署名の作成方法を示す、ダウンロード可能なアプリケーションの例が含まれます。例は、Perl、PHP、C\$1、および Java で使用できます。任意の例を使用して、署名付き URL を作成できます。Perl スクリプトは Linux および macOS プラットフォームで実行されます。PHP の例は、PHP が実行されているあらゆるサーバーで動作します。C\$1 の例では、.NET Framework が使用されます。

JavaScript (Node.js) のコードサンプルについては、AWS デベロッパーブログの「[Creating Amazon CloudFront Signed URLs in Node.js](https://aws.amazon.com/blogs/developer/creating-amazon-cloudfront-signed-urls-in-node-js/)」を参照してください。

Python のコードサンプルについては、「AWS SDK for Python (Boto3) API リファレンス」の「[Generate a signed URL for Amazon CloudFront](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/cloudfront.html#examples)」と、Boto3 GitHub リポジトリにある「[こちらのサンプルコード](https://github.com/boto/boto3/blob/develop/boto3/examples/cloudfront.rst)」を参照してください。

**Topics**
+ [Perl を使用して URL 署名を作成する](CreateURLPerl.md)
+ [PHP を使用して URL 署名を作成する](CreateURL_PHP.md)
+ [C\$1 と .NET Framework を使用して URL 署名を作成する](CreateSignatureInCSharp.md)
+ [Java を使用して URL 署名を作成する](CFPrivateDistJavaDevelopment.md)

# Perl を使用して URL 署名を作成する
<a name="CreateURLPerl"></a>

このセクションには、プライベートコンテンツの署名を作成するために使用できる Linux/Mac プラットフォームの Perl スクリプトが含まれます。署名を作成するには、コマンドライン引数に CloudFront URL、署名者のプライベートキーへのパス、キー ID、および URL の有効期限切れ日付を指定して、スクリプトを実行します。このツールでは、署名付き URL のデコードを行うこともできます。

**注記**  
URL 署名の作成は、署名付き URL を使用してプライベートコンテンツを供給するためのプロセスの 1 パートにすぎません。エンドツーエンドの処理の詳細については、「[署名付き URL を使用する](private-content-signed-urls.md)」を参照してください。

**Topics**
+ [署名付き URL を作成する Perl スクリプトのソース](#CreateURLPerlScriptSource)

## 署名付き URL を作成する Perl スクリプトのソース
<a name="CreateURLPerlScriptSource"></a>

次の Perl ソースコードを使用して、CloudFront の署名付き URL を作成できます。コード内のコメントに、コマンドラインスイッチおよびこのツールの各種機能の情報が含まれています。

```
#!/usr/bin/perl -w

# Copyright 2008 Amazon Technologies, Inc.  Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License. You may obtain a copy of the License at:
#
# https://aws.amazon.com/apache2.0
#
# This file is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and limitations under the License.

=head1 cfsign.pl

cfsign.pl - A tool to generate and verify Amazon CloudFront signed URLs

=head1 SYNOPSIS

This script uses an existing RSA key pair to sign and verify Amazon CloudFront signed URLs

View the script source for details as to which CPAN packages are required beforehand. 

For help, try:

cfsign.pl --help

URL signing examples:

cfsign.pl --action encode --url https://images.my-website.com/gallery1.zip --policy sample_policy.json --private-key privkey.pem --key-pair-id mykey

cfsign.pl --action encode --url https://images.my-website.com/gallery1.zip --expires 1257439868 --private-key privkey.pem --key-pair-id mykey

URL decode example:

cfsign.pl --action decode --url "http//mydist.cloudfront.net/?Signature=AGO-PgxkYo99MkJFHvjfGXjG1QDEXeaDb4Qtzmy85wqyJjK7eKojQWa4BCRcow__&Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovLypicmFkbS5qcGciLCJDb25kaXRpb24iOnsiSXBBZGRyZXNzIjp7IkFXUzpTb3VyY2VJcCI6IjEwLjUyLjE3LjkvMCJ9LCJEYXRlR3JlYXRlclRoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTI1MjUyMDgzMH19fV19Cg__&Key-Pair-Id=mykey"


To generate an RSA key pair, you can use openssl and the following commands:

# Generate a 2048 bit key pair
openssl genrsa -out private-key.pem 2048
openssl rsa -in private-key.pem -pubout -out public-key.pem


=head1 OPTIONS

=over 8

=item B<--help>

Print a help message and exits.

=item B<--action> [action]

The action to execute.  action can be one of:

  encode - Generate a signed URL (using a canned policy or a user policy)
  decode - Decode a signed URL

=item B<--url>

The URL to en/decode

=item B<--stream>

The stream to en/decode

=item B<--private-key>

The path to your private key.

=item B<--key-pair-id>

The key pair identifier.

=item B<--policy>

The CloudFront policy document.

=item B<--expires>

The Unix epoch time when the URL is to expire. If both this option and
the --policy option are specified, --policy will be used. Otherwise, this 
option alone will use a canned policy.

=back

=cut

use strict;
use warnings;

# you might need to use CPAN to get these modules.
# run perl -MCPAN -e "install <module>" to get them.
# The openssl command line will also need to be in your $PATH.
use File::Temp qw/tempfile/;
use File::Slurp;
use Getopt::Long;
use IPC::Open2;
use MIME::Base64 qw(encode_base64 decode_base64);
use Pod::Usage;
use URI;

my $CANNED_POLICY 
    = '{"Statement":[{"Resource":"<RESOURCE>","Condition":{"DateLessThan":{"AWS:EpochTime":<EXPIRES>}}}]}';

my $POLICY_PARAM      = "Policy";
my $EXPIRES_PARAM     = "Expires";
my $SIGNATURE_PARAM   = "Signature";
my $KEY_PAIR_ID_PARAM = "Key-Pair-Id";

my $verbose = 0;
my $policy_filename = "";
my $expires_epoch = 0;
my $action = "";
my $help = 0;
my $key_pair_id = "";
my $url = "";
my $stream = "";
my $private_key_filename = "";

my $result = GetOptions("action=s"      => \$action,
                        "policy=s"      => \$policy_filename,
                        "expires=i"     => \$expires_epoch,
                        "private-key=s" => \$private_key_filename,
                        "key-pair-id=s" => \$key_pair_id,
                        "verbose"       => \$verbose,
                        "help"          => \$help,
                        "url=s"         => \$url,
                        "stream=s"      => \$stream,
                    );

if ($help or !$result) {
    pod2usage(1);
    exit;
}

if ($url eq "" and $stream eq "") {
    print STDERR "Must include a stream or a URL to encode or decode with the --stream or --url option\n";
    exit;
}

if ($url ne "" and $stream ne "") {
    print STDERR "Only one of --url and --stream may be specified\n";
    exit;
}

if ($url ne "" and !is_url_valid($url)) {
    exit;
}

if ($stream ne "") {
    exit unless is_stream_valid($stream);

    # The signing mechanism is identical, so from here on just pretend we're
    # dealing with a URL
    $url = $stream;
} 

if ($action eq "encode") {
    # The encode action will generate a private content URL given a base URL, 
    # a policy file (or an expires timestamp) and a key pair id parameter
    my $private_key;
    my $public_key;
    my $public_key_file;
    
    my $policy;
    if ($policy_filename eq "") {
        if ($expires_epoch == 0) {
            print STDERR "Must include policy filename with --policy argument or an expires" . 
                          "time using --expires\n";            
        }
        
        $policy = $CANNED_POLICY;
        $policy =~ s/<EXPIRES>/$expires_epoch/g;
        $policy =~ s/<RESOURCE>/$url/g;
    } else {
        if (! -e $policy_filename) {
            print STDERR "Policy file $policy_filename does not exist\n";
            exit;
        }
        $expires_epoch = 0; # ignore if set
        $policy = read_file($policy_filename);
    }

    if ($private_key_filename eq "") {
        print STDERR "You must specific the path to your private key file with --private-key\n";
        exit;
    }

    if (! -e $private_key_filename) {
        print STDERR "Private key file $private_key_filename does not exist\n";
        exit;
    }

    if ($key_pair_id eq "") {
        print STDERR "You must specify a key pair id with --key-pair-id\n";
        exit;
    }

    my $encoded_policy = url_safe_base64_encode($policy);
    my $signature = rsa_sha1_sign($policy, $private_key_filename);
    my $encoded_signature = url_safe_base64_encode($signature);

    my $generated_url = create_url($url, $encoded_policy, $encoded_signature, $key_pair_id, $expires_epoch);


    if ($stream ne "") {
        print "Encoded stream (for use within a swf):\n" . $generated_url . "\n";
        print "Encoded and escaped stream (for use on a webpage):\n" .  escape_url_for_webpage($generated_url) . "\n"; 
    } else {
        print "Encoded URL:\n" . $generated_url . "\n";
    }
} elsif ($action eq "decode") {
    my $decoded = decode_url($url);
    if (!$decoded) {
        print STDERR "Improperly formed URL\n";
        exit;
    }

    print_decoded_url($decoded);
} else {
    # No action specified, print help.  But only if this is run as a program (caller will be empty)
    pod2usage(1) unless caller();
}

# Decode a private content URL into its component parts
sub decode_url {
    my $url = shift;

    if ($url =~ /(.*)\?(.*)/) {
        my $base_url = $1;
        my $params = $2;

        my @unparsed_params = split(/&/, $params);
        my %params = ();
        foreach my $param (@unparsed_params) {
            my ($key, $val) = split(/=/, $param);
            $params{$key} = $val;
        }

        my $encoded_signature = "";
        if (exists $params{$SIGNATURE_PARAM}) {
            $encoded_signature = $params{"Signature"};
        } else {
            print STDERR "Missing Signature URL parameter\n";
            return 0;
        }

        my $encoded_policy = "";
        if (exists $params{$POLICY_PARAM}) {
            $encoded_policy = $params{$POLICY_PARAM};
        } else {
            if (!exists $params{$EXPIRES_PARAM}) {
                print STDERR "Either the Policy or Expires URL parameter needs to be specified\n";
                return 0;    
            }
            
            my $expires = $params{$EXPIRES_PARAM};
            
            my $policy = $CANNED_POLICY;
            $policy =~ s/<EXPIRES>/$expires/g;
            
            my $url_without_cf_params = $url;
            $url_without_cf_params =~ s/$SIGNATURE_PARAM=[^&]*&?//g;
            $url_without_cf_params =~ s/$POLICY_PARAM=[^&]*&?//g;
            $url_without_cf_params =~ s/$EXPIRES_PARAM=[^&]*&?//g;
            $url_without_cf_params =~ s/$KEY_PAIR_ID_PARAM=[^&]*&?//g;
            
            if ($url_without_cf_params =~ /(.*)\?$/) {
                $url_without_cf_params = $1;
            }
            
            $policy =~ s/<RESOURCE>/$url_without_cf_params/g;
            
            $encoded_policy = url_safe_base64_encode($policy);
        }

        my $key = "";
        if (exists $params{$KEY_PAIR_ID_PARAM}) {
            $key = $params{$KEY_PAIR_ID_PARAM};
        } else {
            print STDERR "Missing $KEY_PAIR_ID_PARAM parameter\n";
            return 0;
        }

        my $policy = url_safe_base64_decode($encoded_policy);

        my %ret = ();
        $ret{"base_url"} = $base_url;
        $ret{"policy"} = $policy;
        $ret{"key"} = $key;

        return \%ret;
    } else {
        return 0;
    }
}

# Print a decoded URL out
sub print_decoded_url {
    my $decoded = shift;

    print "Base URL: \n" . $decoded->{"base_url"} . "\n";
    print "Policy: \n" . $decoded->{"policy"} . "\n";
    print "Key: \n" . $decoded->{"key"} . "\n";
}

# Encode a string with base 64 encoding and replace some invalid URL characters
sub url_safe_base64_encode {
    my ($value) = @_;

    my $result = encode_base64($value);
    $result =~ tr|+=/|-_~|;

    return $result;
}

# Decode a string with base 64 encoding.  URL-decode the string first
# followed by reversing any special character ("+=/") translation.
sub url_safe_base64_decode {
    my ($value) = @_;

    $value =~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/eg;
    $value =~ tr|-_~|+=/|;

    my $result = decode_base64($value);

    return $result;
}

# Create a private content URL
sub create_url {
    my ($path, $policy, $signature, $key_pair_id, $expires) = @_;
    
    my $result;
    my $separator = $path =~ /\?/ ? '&' : '?';
    if ($expires) {
        $result = "$path$separator$EXPIRES_PARAM=$expires&$SIGNATURE_PARAM=$signature&$KEY_PAIR_ID_PARAM=$key_pair_id";
    } else {
        $result = "$path$separator$POLICY_PARAM=$policy&$SIGNATURE_PARAM=$signature&$KEY_PAIR_ID_PARAM=$key_pair_id";
    }
    $result =~ s/\n//g;

    return $result;
}

# Sign a document with given private key file.
# The first argument is the document to sign
# The second argument is the name of the private key file
sub rsa_sha1_sign {
    my ($to_sign, $pvkFile) = @_;
    print "openssl sha1 -sign $pvkFile $to_sign\n";

    return write_to_program($pvkFile, $to_sign);
}

# Helper function to write data to a program
sub write_to_program {
my ($keyfile, $data) = @_;
unlink "temp_policy.dat" if (-e "temp_policy.dat");
unlink "temp_sign.dat" if (-e "temp_sign.dat");

write_file("temp_policy.dat", $data);

system("openssl dgst -sha1 -sign \"$keyfile\" -out temp_sign.dat temp_policy.dat");

my $output = read_file("temp_sign.dat");

    return $output;
}

# Read a file into a string and return the string
sub read_file {
    my ($file) = @_;

    open(INFILE, "<$file") or die("Failed to open $file: $!");
    my $str = join('', <INFILE>);
    close INFILE;

    return $str;
}

sub is_url_valid {
    my ($url) = @_;

    # HTTP distributions start with http[s]:// and are the correct thing to sign
    if ($url =~ /^https?:\/\//) {
        return 1;
    } else {
        print STDERR "CloudFront requires absolute URLs for HTTP distributions\n";
        return 0;
    }
}

sub is_stream_valid {
    my ($stream) = @_;

    if ($stream =~ /^rtmp:\/\// or $stream =~ /^\/?cfx\/st/) {
        print STDERR "Streaming distributions require that only the stream name is signed.\n";
        print STDERR "The stream name is everything after, but not including, cfx/st/\n";
        return 0;
    } else {
        return 1;
    }
}

# flash requires that the query parameters in the stream name are url
# encoded when passed in through javascript, etc.  This sub handles the minimal
# required url encoding.
sub escape_url_for_webpage {
    my ($url) = @_;

    $url =~ s/\?/%3F/g;
    $url =~ s/=/%3D/g;
    $url =~ s/&/%26/g;

    return $url;
}

1;
```

# PHP を使用して URL 署名を作成する
<a name="CreateURL_PHP"></a>

PHP を実行するすべてのウェブサーバーでは、この PHP サンプルコードを使用して、CloudFront のプライベートディストリビューション用のポリシーステートメントと署名を作成できます。この完全なサンプルでは、CloudFront ストリーミングを使用してビデオストリームを再生する署名付き URL リンクが含まれた、実際に動作するウェブページを作成します。完全な例については、[demo-php.zip](samples/demo-php.zip) ファイルからダウンロードできます。

**注意事項**  
URL 署名の作成は、署名付き URL を使用してプライベートコンテンツを供給するためのプロセスの 1 パートにすぎません。プロセス全体の詳細については、「[署名付き URL を使用する](private-content-signed-urls.md)」を参照してください。
AWS SDK for PHP の `UrlSigner` クラスを使用して署名付き URL を作成することもできます。詳細については、*AWS SDK for PHP API リファレンス*の「[Class UrlSigner](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.CloudFront.UrlSigner.html)」を参照してください。

**Topics**
+ [RSA SHA-1 署名を作成する](#sample-rsa-sign)
+ [既定ポリシーを作成する](#sample-canned-policy)
+ [カスタムポリシーを作成するには](#sample-custom-policy)
+ [完全なサンプルコード](#full-example)

以下のセクションでは、コード例を個別のパートに分解します。「[完全なサンプルコード](#full-example)」は以下にあります。

## RSA SHA-1 署名を作成する
<a name="sample-rsa-sign"></a>

このコード例では、次の操作を行います。
+ 関数 `rsa_sha1_sign` は、ポリシーステートメントをハッシュ化して署名します。必要な引数は、ポリシーステートメントと、ディストリビューションの信頼されたキーグループにあるパブリックキーに対応するプライベートキーです。
+ 次に、`url_safe_base64_encode` 関数で、URL で使用可能なバージョンの署名を作成します。

```
function rsa_sha1_sign($policy, $private_key_filename) {
    $signature = "";

    // load the private key
    $fp = fopen($private_key_filename, "r");
    $priv_key = fread($fp, 8192);
    fclose($fp);
    $pkeyid = openssl_get_privatekey($priv_key);

    // compute signature
    openssl_sign($policy, $signature, $pkeyid);

    // free the key from memory
    openssl_free_key($pkeyid);

    return $signature;
}

function url_safe_base64_encode($value) {
    $encoded = base64_encode($value);
    // replace unsafe characters +, = and / with 
    // the safe characters -, _ and ~
    return str_replace(
        array('+', '=', '/'),
        array('-', '_', '~'),
        $encoded);
}
```

次のコードスニペットでは、`get_canned_policy_stream_name()` 関数と `get_custom_policy_stream_name()` 関数を使用して既定ポリシーとカスタムポリシーを作成します。CloudFront は、これらのポリシーを使用して、有効期限を指定するとともに、動画をストリーミングするための URL を作成します。

次に、既定ポリシーまたはカスタムポリシーを使用して、コンテンツへのアクセスを管理する方法を決定できます。どちらを選択するかの詳細については、「[署名付き URL に既定ポリシーとカスタムポリシーのどちらを使用するかを決定する](private-content-signed-urls.md#private-content-choosing-canned-custom-policy)」セクションを参照してください。

## 既定ポリシーを作成する
<a name="sample-canned-policy"></a>

以下のサンプルコードでは、署名用の*既定*ポリシーステートメントを作成します。

**注記**  
`$expires` 変数は、文字列ではなく整数である必要がある日時スタンプです。

```
function get_canned_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $expires) {
    // this policy is well known by CloudFront, but you still need to sign it, since it contains your parameters
    $canned_policy = '{"Statement":[{"Resource":"' . $video_path . '","Condition":{"DateLessThan":{"AWS:EpochTime":'. $expires . '}}}]}';
    // the policy contains characters that cannot be part of a URL, so we base64 encode it
    $encoded_policy = url_safe_base64_encode($canned_policy);
    // sign the original policy, not the encoded version
    $signature = rsa_sha1_sign($canned_policy, $private_key_filename);
    // make the signature safe to be included in a URL
    $encoded_signature = url_safe_base64_encode($signature);

    // combine the above into a stream name
    $stream_name = create_stream_name($video_path, null, $encoded_signature, $key_pair_id, $expires);
    // URL-encode the query string characters
    return $stream_name;
}
```

既定ポリシーの詳細については、「[既定ポリシーを使用して署名付き URL を作成する](private-content-creating-signed-url-canned-policy.md)」を参照してください。

## カスタムポリシーを作成するには
<a name="sample-custom-policy"></a>

以下のサンプルコードでは、署名用の*カスタム*ポリシーステートメントを作成します。

```
function get_custom_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $policy) {
    // the policy contains characters that cannot be part of a URL, so we base64 encode it
    $encoded_policy = url_safe_base64_encode($policy);
    // sign the original policy, not the encoded version
    $signature = rsa_sha1_sign($policy, $private_key_filename);
    // make the signature safe to be included in a URL
    $encoded_signature = url_safe_base64_encode($signature);

    // combine the above into a stream name
    $stream_name = create_stream_name($video_path, $encoded_policy, $encoded_signature, $key_pair_id, null);
    // URL-encode the query string characters
    return $stream_name;
}
```

カスタムポリシーの詳細については、「[カスタムポリシーを使用して署名付き URL を作成する](private-content-creating-signed-url-custom-policy.md)」を参照してください。

## 完全なサンプルコード
<a name="full-example"></a>

次のコードサンプルでは、PHP で CloudFront 署名付き URL を作成する詳細な方法を示します。完全な例については、[demo-php.zip](samples/demo-php.zip) ファイルからダウンロードできます。

次の例では、`$policy` `Condition` エレメントを変更して、IPv4 アドレス範囲と IPv6 アドレス範囲の両方を許可できます。例については、「Amazon Simple Storage Service ユーザーガイド」の「[IAM ポリシーでの IPv6 アドレスの使用](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ipv6-access.html#ipv6-access-iam)」を参照してください。**

```
<?php

function rsa_sha1_sign($policy, $private_key_filename) {
    $signature = "";

    // load the private key
    $fp = fopen($private_key_filename, "r");
    $priv_key = fread($fp, 8192);
    fclose($fp);
    $pkeyid = openssl_get_privatekey($priv_key);

    // compute signature
    openssl_sign($policy, $signature, $pkeyid);

    // free the key from memory
    openssl_free_key($pkeyid);

    return $signature;
}

function url_safe_base64_encode($value) {
    $encoded = base64_encode($value);
    // replace unsafe characters +, = and / with the safe characters -, _ and ~
    return str_replace(
        array('+', '=', '/'),
        array('-', '_', '~'),
        $encoded);
}

function create_stream_name($stream, $policy, $signature, $key_pair_id, $expires) {
    $result = $stream;
    // if the stream already contains query parameters, attach the new query parameters to the end
    // otherwise, add the query parameters
    $separator = strpos($stream, '?') == FALSE ? '?' : '&';
    // the presence of an expires time means we're using a canned policy
    if($expires) {
        $result .= $separator . "Expires=" . $expires . "&Signature=" . $signature . "&Key-Pair-Id=" . $key_pair_id;
    }
    // not using a canned policy, include the policy itself in the stream name
    else {
        $result .= $separator . "Policy=" . $policy . "&Signature=" . $signature . "&Key-Pair-Id=" . $key_pair_id;
    }

    // new lines would break us, so remove them
    return str_replace('\n', '', $result);
}


function get_canned_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $expires) {
    // this policy is well known by CloudFront, but you still need to sign it, since it contains your parameters
    $canned_policy = '{"Statement":[{"Resource":"' . $video_path . '","Condition":{"DateLessThan":{"AWS:EpochTime":'. $expires . '}}}]}';
    // the policy contains characters that cannot be part of a URL, so we base64 encode it
    $encoded_policy = url_safe_base64_encode($canned_policy);
    // sign the original policy, not the encoded version
    $signature = rsa_sha1_sign($canned_policy, $private_key_filename);
    // make the signature safe to be included in a URL
    $encoded_signature = url_safe_base64_encode($signature);

    // combine the above into a stream name
    $stream_name = create_stream_name($video_path, null, $encoded_signature, $key_pair_id, $expires);
    // URL-encode the query string characters
    return $stream_name;
}

function get_custom_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $policy) {
    // the policy contains characters that cannot be part of a URL, so we base64 encode it
    $encoded_policy = url_safe_base64_encode($policy);
    // sign the original policy, not the encoded version
    $signature = rsa_sha1_sign($policy, $private_key_filename);
    // make the signature safe to be included in a URL
    $encoded_signature = url_safe_base64_encode($signature);

    // combine the above into a stream name
    $stream_name = create_stream_name($video_path, $encoded_policy, $encoded_signature, $key_pair_id, null);
    // URL-encode the query string characters
    return $stream_name;
}


// Path to your private key.  Be very careful that this file is not accessible
// from the web!

$private_key_filename = '/home/test/secure/example-priv-key.pem';
$key_pair_id = 'K2JCJMDEHXQW5F';

// Make sure you have "Restrict viewer access" enabled on this path behaviour and using the above Trusted key groups (recommended).
$video_path = 'https://example.com/secure/example.mp4';

$expires = time() + 300; // 5 min from now
$canned_policy_stream_name = get_canned_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $expires);

// Get the viewer real IP from the x-forward-for header as $_SERVER['REMOTE_ADDR'] will return viewer facing IP. An alternative option is to use CloudFront-Viewer-Address header. Note that this header is a trusted CloudFront immutable header. Example format: IP:PORT ("CloudFront-Viewer-Address": "1.2.3.4:12345")
$client_ip = $_SERVER['HTTP_X_FORWARDED_FOR'];
$policy =
'{'.
    '"Statement":['.
        '{'.
            '"Resource":"'. $video_path . '",'.
            '"Condition":{'.
                '"IpAddress":{"AWS:SourceIp":"' . $client_ip . '/32"},'.
                '"DateLessThan":{"AWS:EpochTime":' . $expires . '}'.
            '}'.
        '}'.
    ']' .
    '}';
$custom_policy_stream_name = get_custom_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $policy);

?>

<html>

<head>
    <title>CloudFront</title>
</head>

<body>
    <h1>Amazon CloudFront</h1>
    <h2>Canned Policy</h2>
    <h3>Expires at <?php echo gmdate('Y-m-d H:i:s T', $expires); ?></h3>
    <br />

    <div id='canned'>The canned policy video will be here: <br>
    
        <video width="640" height="360" autoplay muted controls>
        <source src="<?php echo $canned_policy_stream_name; ?>" type="video/mp4">
        Your browser does not support the video tag.
        </video>
    </div>

    <h2>Custom Policy</h2>
    <h3>Expires at <?php echo gmdate('Y-m-d H:i:s T', $expires); ?> only viewable by IP <?php echo $client_ip; ?></h3>
    <div id='custom'>The custom policy video will be here: <br>

         <video width="640" height="360" autoplay muted controls>
         <source src="<?php echo $custom_policy_stream_name; ?>" type="video/mp4">
         Your browser does not support the video tag.
        </video>
    </div> 

</body>

</html>
```

その他の URL 署名の例については、以下のトピックを参照してください。
+ [Perl を使用して URL 署名を作成する](CreateURLPerl.md)
+ [C\$1 と .NET Framework を使用して URL 署名を作成する](CreateSignatureInCSharp.md)
+ [Java を使用して URL 署名を作成する](CFPrivateDistJavaDevelopment.md)

署名 URL を使用して署名を作成する代わりに、署名付き cookie を使用できます。詳細については、「[PHP を使用して署名付き cookie を作成する](signed-cookies-PHP.md)」を参照してください。

# C\$1 と .NET Framework を使用して URL 署名を作成する
<a name="CreateSignatureInCSharp"></a>

このセクションの C\$1 の例では、既定およびカスタムのポリシーステートメントを使用して CloudFront プライベートディストリビューションの署名を作成する方法を示すサンプルアプリケーションを実装します。これらの例には、.NET アプリケーションに便利な [AWS SDK for .NET](https://aws.amazon.com/sdkfornet) に基づくユーティリティ関数が含まれています。

SDK for .NET を使用して署名付き URL と署名付き Cookie を作成することもできます。*SDK for .NET API リファレンス*で、以下のトピックを参照してください。
+ **署名付き URL** – [AmazonCloudFrontUrlSigner](https://docs.aws.amazon.com/sdkfornet/v3/apidocs/items/CloudFront/TCloudFrontUrlSigner.html) 
+ **署名付き Cookie** – [AmazonCloudFrontCookieSigner](https://docs.aws.amazon.com/sdkfornet/v3/apidocs/items/CloudFront/TCloudFrontCookieSigner.html) 

コードをダウンロードするには、[C\$1 による署名コード](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/samples/AWS_PrivateCF_Distributions.zip)にアクセスしてください。

**注意事項**  
`AmazonCloudFrontUrlSigner` および `AmazonCloudFrontCookieSigner` クラスは別のパッケージに移動しました。使用の詳細については、「*AWS SDK for .NET (V4) デベロッパーガイド*」の「[CookieSigner と UrlSigner](https://docs.aws.amazon.com/sdk-for-net/v4/developer-guide/net-dg-v4.html#net-dg-v4-CookieSigner-UrlSigner)」を参照してください。
URL 署名の作成は、署名付き URL を使用してプライベートコンテンツを供給するためのプロセスの 1 パートにすぎません。詳細については、「[署名付き URL を使用する](private-content-signed-urls.md)」を参照してください。署名付き Cookie の使用の詳細については、「[署名付き Cookie を使用する](private-content-signed-cookies.md)」を参照してください。

## .NET Framework で RSA キーを使用する
<a name="rsa-key-sdk-net"></a>

.NET Framework で RSA キーを使用するには、AWS 提供の .pem ファイルを .NET Framework が使用する XML 形式に変換する必要があります。

変換後、RSA プライベートキーファイルの形式は以下のようになります。

**Example : XML .NET Framework 形式の RSA プライベートキー**  <a name="RSAPrivateKeyXML.NETFrameworkFormat"></a>

```
<RSAKeyValue>
  <Modulus>
    wO5IvYCP5UcoCKDo1dcspoMehWBZcyfs9QEzGi6Oe5y+ewGr1oW+vB2GPB
    ANBiVPcUHTFWhwaIBd3oglmF0lGQljP/jOfmXHUK2kUUnLnJp+oOBL2NiuFtqcW6h/L5lIpD8Yq+NRHg
    Ty4zDsyr2880MvXv88yEFURCkqEXAMPLE=
  </Modulus>
  <Exponent>AQAB</Exponent>
  <P>
    5bmKDaTz
    npENGVqz4Cea8XPH+sxt+2VaAwYnsarVUoSBeVt8WLloVuZGG9IZYmH5KteXEu7fZveYd9UEXAMPLE==
  </P>
  <Q>
    1v9l/WN1a1N3rOK4VGoCokx7kR2SyTMSbZgF9IWJNOugR/WZw7HTnjipO3c9dy1Ms9pUKwUF4
    6d7049EXAMPLE==
  </Q>
  <DP>
    RgrSKuLWXMyBH+/l1Dx/I4tXuAJIrlPyo+VmiOc7b5NzHptkSHEPfR9s1
    OK0VqjknclqCJ3Ig86OMEtEXAMPLE==
  </DP>
  <DQ>
    pjPjvSFw+RoaTu0pgCA/jwW/FGyfN6iim1RFbkT4
    z49DZb2IM885f3vf35eLTaEYRYUHQgZtChNEV0TEXAMPLE==
  </DQ>
  <InverseQ>
    nkvOJTg5QtGNgWb9i
    cVtzrL/1pFEOHbJXwEJdU99N+7sMK+1066DL/HSBUCD63qD4USpnf0myc24in0EXAMPLE==</InverseQ>
  <D>
      Bc7mp7XYHynuPZxChjWNJZIq+A73gm0ASDv6At7F8Vi9r0xUlQe/v0AQS3ycN8QlyR4XMbzMLYk
      3yjxFDXo4ZKQtOGzLGteCU2srANiLv26/imXA8FVidZftTAtLviWQZBVPTeYIA69ATUYPEq0a5u5wjGy
      UOij9OWyuEXAMPLE=
   </D>
</RSAKeyValue>
```

## C\$1 における既定ポリシーの署名方法
<a name="canned-policy-signed-url-net"></a>

以下の C\$1 コードは、以下を実行して、既定ポリシーを使用する署名付き URL を作成します。
+ ポリシーステートメントを作成する。
+ SHA1 を使用してポリシーステートメントをハッシュ化し、RSA とプライベートキー (信頼されたキーグループにあるパブリックキーに対応するもの) を使用して、結果に署名します。
+ ハッシュ化および署名されたポリシーステートメントを base64 エンコードし、特殊文字を置き換えて文字列を URL リクエストパラメータとして使用できるようにする。
+ 値を連結する。

完全な実装については、[C\$1 による署名コード](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/samples/AWS_PrivateCF_Distributions.zip)の例を参照してください。

**注記**  
CloudFront にパブリックキーをアップロードすると、`keyId` が返されます。詳細については、「![\[6\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/images/callouts/6.png)[ &Key-Pair-Id](private-content-creating-signed-url-canned-policy.md)」を参照してください。

**Example : C\$1 における既定ポリシーの署名方法**  <a name="ExampleCannedPolicySigningMethod-CSharp"></a>

```
public static string ToUrlSafeBase64String(byte[] bytes)
{
    return System.Convert.ToBase64String(bytes)
        .Replace('+', '-')
        .Replace('=', '_')
        .Replace('/', '~');
}

public static string CreateCannedPrivateURL(string urlString, 
    string durationUnits, string durationNumber, string pathToPolicyStmnt, 
    string pathToPrivateKey, string keyId)
{
    // args[] 0-thisMethod, 1-resourceUrl, 2-seconds-minutes-hours-days 
    // to expiration, 3-numberOfPreviousUnits, 4-pathToPolicyStmnt, 
    // 5-pathToPrivateKey, 6-keyId

    TimeSpan timeSpanInterval = GetDuration(durationUnits, durationNumber);

    // Create the policy statement.
    string strPolicy = CreatePolicyStatement(pathToPolicyStmnt,
        urlString, 
        DateTime.Now, 
        DateTime.Now.Add(timeSpanInterval), 
        "0.0.0.0/0");
    if ("Error!" == strPolicy) return "Invalid time frame." + 
        "Start time cannot be greater than end time.";

    // Copy the expiration time defined by policy statement.
    string strExpiration = CopyExpirationTimeFromPolicy(strPolicy);

    // Read the policy into a byte buffer.
    byte[] bufferPolicy = Encoding.ASCII.GetBytes(strPolicy);

    // Initialize the SHA1CryptoServiceProvider object and hash the policy data.
    using (SHA1CryptoServiceProvider 
        cryptoSHA1 = new SHA1CryptoServiceProvider())
    {
        bufferPolicy = cryptoSHA1.ComputeHash(bufferPolicy);

        // Initialize the RSACryptoServiceProvider object.
        RSACryptoServiceProvider providerRSA = new RSACryptoServiceProvider();
        XmlDocument xmlPrivateKey = new XmlDocument();

        // Load your private key, which you created by converting your 
        // .pem file to the XML format that the .NET framework uses.  
        // Several tools are available. 
        xmlPrivateKey.Load(pathToPrivateKey);

        // Format the RSACryptoServiceProvider providerRSA and 
        // create the signature.
        providerRSA.FromXmlString(xmlPrivateKey.InnerXml);
        RSAPKCS1SignatureFormatter rsaFormatter = 
            new RSAPKCS1SignatureFormatter(providerRSA);
        rsaFormatter.SetHashAlgorithm("SHA1");
        byte[] signedPolicyHash = rsaFormatter.CreateSignature(bufferPolicy);

        // Convert the signed policy to URL-safe base64 encoding and 
        // replace unsafe characters + = / with the safe characters - _ ~
        string strSignedPolicy = ToUrlSafeBase64String(signedPolicyHash);

        // Concatenate the URL, the timestamp, the signature, 
        // and the key pair ID to form the signed URL.
        return urlString + 
            "?Expires=" + 
            strExpiration + 
            "&Signature=" + 
            strSignedPolicy + 
            "&Key-Pair-Id=" + 
            keyId;
    }
}
```

## C\$1 におけるカスタムポリシーの署名方法
<a name="custom-policy-signed-url-net"></a>

以下の C\$1 コードは、以下の手順を実行して、カスタムポリシーを使用する署名付き URL を作成します。

1. ポリシーステートメントを作成する。

1. ポリシーステートメントを Base64 エンコードし、特殊文字を置き換えて文字列を URL リクエストパラメータとして使用できるようにする。

1. SHA1 を使用してポリシーステートメントをハッシュ化し、RSA とプライベートキー (信頼されたキーグループにあるパブリックキーに対応するもの) を使用して、結果を暗号化します。

1. ハッシュ化されたポリシーステートメントを base64 エンコードし、特殊文字を置き換えて文字列を URL リクエストパラメータとして使用できるようにする。

1. 値を連結する。

完全な実装については、[C\$1 による署名コード](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/samples/AWS_PrivateCF_Distributions.zip)の例を参照してください。

**注記**  
CloudFront にパブリックキーをアップロードすると、`keyId` が返されます。詳細については、「![\[6\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/images/callouts/6.png)[ &Key-Pair-Id](private-content-creating-signed-url-canned-policy.md)」を参照してください。

**Example : C\$1 におけるカスタムポリシーの署名方法**  <a name="ExampleCustomPolicySigningMethod-CSharp"></a>

```
public static string ToUrlSafeBase64String(byte[] bytes)
{
    return System.Convert.ToBase64String(bytes)
        .Replace('+', '-')
        .Replace('=', '_')
        .Replace('/', '~');
}

public static string CreateCustomPrivateURL(string urlString, 
    string durationUnits, string durationNumber, string startIntervalFromNow, 
    string ipaddress, string pathToPolicyStmnt, string pathToPrivateKey, 
    string keyId)
{
    // args[] 0-thisMethod, 1-resourceUrl, 2-seconds-minutes-hours-days 
    // to expiration, 3-numberOfPreviousUnits, 4-starttimeFromNow, 
    // 5-ip_address, 6-pathToPolicyStmt, 7-pathToPrivateKey, 8-keyId

    TimeSpan timeSpanInterval = GetDuration(durationUnits, durationNumber);
    TimeSpan timeSpanToStart = GetDurationByUnits(durationUnits, 
        startIntervalFromNow);
    if (null == timeSpanToStart) 
        return "Invalid duration units." + 
            "Valid options: seconds, minutes, hours, or days";
            
    string strPolicy = CreatePolicyStatement(
        pathToPolicyStmnt, urlString, DateTime.Now.Add(timeSpanToStart), 
        DateTime.Now.Add(timeSpanInterval), ipaddress);

    // Read the policy into a byte buffer.
    byte[] bufferPolicy = Encoding.ASCII.GetBytes(strPolicy);

    // Convert the policy statement to URL-safe base64 encoding and 
    // replace unsafe characters + = / with the safe characters - _ ~

    string urlSafePolicy = ToUrlSafeBase64String(bufferPolicy);

    // Initialize the SHA1CryptoServiceProvider object and hash the policy data.
    byte[] bufferPolicyHash;
    using (SHA1CryptoServiceProvider cryptoSHA1 = 
        new SHA1CryptoServiceProvider())
    {
        bufferPolicyHash = cryptoSHA1.ComputeHash(bufferPolicy);

        // Initialize the RSACryptoServiceProvider object.
        RSACryptoServiceProvider providerRSA = new RSACryptoServiceProvider();
        XmlDocument xmlPrivateKey = new XmlDocument();

        // Load your private key, which you created by converting your 
        // .pem file to the XML format that the .NET framework uses.  
        // Several tools are available. 
        xmlPrivateKey.Load(pathToPrivateKey);

        // Format the RSACryptoServiceProvider providerRSA 
        // and create the signature.
        providerRSA.FromXmlString(xmlPrivateKey.InnerXml);
        RSAPKCS1SignatureFormatter RSAFormatter = 
            new RSAPKCS1SignatureFormatter(providerRSA);
        RSAFormatter.SetHashAlgorithm("SHA1");
        byte[] signedHash = RSAFormatter.CreateSignature(bufferPolicyHash);

        // Convert the signed policy to URL-safe base64 encoding and 
        // replace unsafe characters + = / with the safe characters - _ ~
        string strSignedPolicy = ToUrlSafeBase64String(signedHash);

        return urlString + 
            "?Policy=" + 
            urlSafePolicy + 
            "&Signature=" + 
            strSignedPolicy + 
            "&Key-Pair-Id=" + 
            keyId;
    }
}
```

## 署名生成のためのユーティリティメソッド
<a name="utility-methods-signed-url"></a>

以下のメソッドは、ファイルからポリシーステートメントを取得し、署名生成の期間を解析します。

**Example : 署名生成のためのユーティリティメソッド**  <a name="UtilityMethodsForSignatureGeneration"></a>

```
public static string CreatePolicyStatement(string policyStmnt, 
   string resourceUrl, 
   DateTime startTime, 
   DateTime endTime, 
   string ipAddress)
   
{
   // Create the policy statement.
   FileStream streamPolicy = new FileStream(policyStmnt, FileMode.Open, FileAccess.Read);
   using (StreamReader reader = new StreamReader(streamPolicy))
   {
      string strPolicy = reader.ReadToEnd();

      TimeSpan startTimeSpanFromNow = (startTime - DateTime.Now);
      TimeSpan endTimeSpanFromNow = (endTime - DateTime.Now);
      TimeSpan intervalStart = 
         (DateTime.UtcNow.Add(startTimeSpanFromNow)) - 
         new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);
      TimeSpan intervalEnd = 
         (DateTime.UtcNow.Add(endTimeSpanFromNow)) - 
         new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);

      int startTimestamp = (int)intervalStart.TotalSeconds; // START_TIME
      int endTimestamp = (int)intervalEnd.TotalSeconds;  // END_TIME

      if (startTimestamp > endTimestamp)
         return "Error!";

      // Replace variables in the policy statement.
      strPolicy = strPolicy.Replace("RESOURCE", resourceUrl);
      strPolicy = strPolicy.Replace("START_TIME", startTimestamp.ToString());
      strPolicy = strPolicy.Replace("END_TIME", endTimestamp.ToString());
      strPolicy = strPolicy.Replace("IP_ADDRESS", ipAddress);
      strPolicy = strPolicy.Replace("EXPIRES", endTimestamp.ToString());
      return strPolicy;
   }   
}

public static TimeSpan GetDuration(string units, string numUnits)
{
   TimeSpan timeSpanInterval = new TimeSpan();
   switch (units)
   {
      case "seconds":
         timeSpanInterval = new TimeSpan(0, 0, 0, int.Parse(numUnits));
         break;
      case "minutes":
         timeSpanInterval = new TimeSpan(0, 0, int.Parse(numUnits), 0);
         break;
      case "hours":
         timeSpanInterval = new TimeSpan(0, int.Parse(numUnits), 0 ,0);
         break;
      case "days":
         timeSpanInterval = new TimeSpan(int.Parse(numUnits),0 ,0 ,0);
         break;
      default:
         Console.WriteLine("Invalid time units;" + 
            "use seconds, minutes, hours, or days");
         break;
   }
   return timeSpanInterval;
}

private static TimeSpan GetDurationByUnits(string durationUnits, 
   string startIntervalFromNow)
{
   switch (durationUnits)
   {
      case "seconds":
         return new TimeSpan(0, 0, int.Parse(startIntervalFromNow));
      case "minutes":
         return new TimeSpan(0, int.Parse(startIntervalFromNow), 0);
      case "hours":
         return new TimeSpan(int.Parse(startIntervalFromNow), 0, 0);
      case "days":
         return new TimeSpan(int.Parse(startIntervalFromNow), 0, 0, 0);
      default:
         return new TimeSpan(0, 0, 0, 0);
   }
}

public static string CopyExpirationTimeFromPolicy(string policyStatement)
{
   int startExpiration = policyStatement.IndexOf("EpochTime");
   string strExpirationRough = policyStatement.Substring(startExpiration + 
      "EpochTime".Length);
   char[] digits = { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9' };
         
   List<char> listDigits = new List<char>(digits);
   StringBuilder buildExpiration = new StringBuilder(20);
         
   foreach (char c in strExpirationRough)
   {
      if (listDigits.Contains(c))
         buildExpiration.Append(c);
   }
   return buildExpiration.ToString();   
}
```

関連情報
+ [Perl を使用して URL 署名を作成する](CreateURLPerl.md)
+ [PHP を使用して URL 署名を作成する](CreateURL_PHP.md)
+ [Java を使用して URL 署名を作成する](CFPrivateDistJavaDevelopment.md)

# Java を使用して URL 署名を作成する
<a name="CFPrivateDistJavaDevelopment"></a>

次のコード例に加えて、AWS SDK for Java (バージョン 1) の[`CloudFrontUrlSigner` ユーティリティクラス](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/cloudfront/CloudFrontUrlSigner.html)を使用して [CloudFront の署名付き URL](private-content-signed-urls.md) を作成することもできます。

その他の例については、「AWS SDK コードサンプルコードライブラリ」の「[AWS SDK を使用して署名付き URL と Cookie を作成する](https://docs.aws.amazon.com/code-library/latest/ug/cloudfront_example_cloudfront_CloudFrontUtilities_section.html)」を参照してください。**

**注記**  
署名付き URL の作成は、[CloudFront を使用してプライベートコンテンツを供給する](PrivateContent.md)プロセスの一部にすぎません。プロセス全体の詳細については、「[署名付き URL を使用する](private-content-signed-urls.md)」を参照してください。

以下の例は、CloudFront の署名付き URL の作成方法を示しています。

**Example Java のポリシーおよび署名暗号化メソッド**  <a name="ExampleJavaPolicyAndSignatureEncryptionMethods"></a>

```
package org.example;

import java.time.Instant;
import java.time.temporal.ChronoUnit;
import software.amazon.awssdk.services.cloudfront.CloudFrontUtilities;
import software.amazon.awssdk.services.cloudfront.model.CannedSignerRequest;
import software.amazon.awssdk.services.cloudfront.url.SignedUrl;

public class Main {

    public static void main(String[] args) throws Exception {
        CloudFrontUtilities cloudFrontUtilities = CloudFrontUtilities.create();
        Instant expirationDate = Instant.now().plus(7, ChronoUnit.DAYS);
        String resourceUrl = "https://a1b2c3d4e5f6g7.cloudfront.net";
        String keyPairId = "K1UA3WV15I7JSD";
        CannedSignerRequest cannedRequest = CannedSignerRequest.builder()
                .resourceUrl(resourceUrl)
                .privateKey(new java.io.File("/path/to/private_key.pem").toPath())
                .keyPairId(keyPairId)
                .expirationDate(expirationDate)
                .build();
        SignedUrl signedUrl = cloudFrontUtilities.getSignedUrlWithCannedPolicy(cannedRequest);
        String url = signedUrl.url();
        System.out.println(url);

    }
}
```

次の資料も参照してください:
+ [Perl を使用して URL 署名を作成する](CreateURLPerl.md)
+ [PHP を使用して URL 署名を作成する](CreateURL_PHP.md)
+ [C\$1 と .NET Framework を使用して URL 署名を作成する](CreateSignatureInCSharp.md)

# AWS オリジンへのアクセスを制限する
<a name="private-content-restricting-access-to-origin"></a>

以下の利点が得られるような方法で CloudFront Front および AWS オリジンを設定できます。
+ AWS へのアクセスを制限して、パブリックにアクセスできないようにします。
+ ビューワー (ユーザー) が、指定された CloudFront ディストリビューションを介してのみ AWS オリジン内のコンテンツにアクセスできることを確認します。これにより、ビューワーはオリジンから直接、または意図しない CloudFront ディストリビューションを介してコンテンツにアクセスできなくなります。

そのためには、認証済みリクエストを AWS オリジンに送信するように CloudFront を設定し、CloudFront からの認証済みリクエストへのアクセスのみを許可するように AWS オリジンを設定します。詳細については、互換性のある AWS オリジンのタイプに関する以下のトピックを参照してください。

**Topics**
+ [AWS Elemental MediaPackage v2 オリジンへのアクセス制限](private-content-restricting-access-to-mediapackage.md)
+ [AWS Elemental MediaStore オリジンへのアクセスを制限する](private-content-restricting-access-to-mediastore.md)
+ [AWS Lambda 関数 URL オリジンへのアクセスを制限する](private-content-restricting-access-to-lambda.md)
+ [Amazon S3 オリジンへのアクセスを制限する](private-content-restricting-access-to-s3.md)
+ [VPC オリジンを使用したアクセス制限](private-content-vpc-origins.md)

# AWS Elemental MediaPackage v2 オリジンへのアクセス制限
<a name="private-content-restricting-access-to-mediapackage"></a>

CloudFront には、MediaPackage v2 オリジンへのアクセスを制限するための*オリジンアクセスコントロール* (OAC) が用意されています。

**注記**  
CloudFront OAC は、MediaPackage v2 のみをサポートしています。MediaPackage v1 はサポートされていません。

**Topics**
+ [新しい OAC の作成](#create-oac-overview-mediapackage)
+ [オリジンアクセスコントロールの詳細設定](#oac-advanced-settings-mediapackage)

## 新しい OAC の作成
<a name="create-oac-overview-mediapackage"></a>

CloudFront で新しい OAC を設定するには、以下のトピックに示す手順を実行します。

**Topics**
+ [前提条件](#oac-prerequisites-mediapackage)
+ [MediaPackage v2 オリジンへのアクセス許可を CloudFront に付与する](#oac-permission-to-access-mediapackage)
+ [OAC の作成](#create-oac-mediapackage)

### 前提条件
<a name="oac-prerequisites-mediapackage"></a>

OAC を作成して設定する前に、MediaPackage v2 オリジンを持つ CloudFront ディストリビューションが必要です。詳細については、「[MediaStore コンテナまたは MediaPackage チャネルを使用する](DownloadDistS3AndCustomOrigins.md#concept_AWS_Media)」を参照してください。

### MediaPackage v2 オリジンへのアクセス許可を CloudFront に付与する
<a name="oac-permission-to-access-mediapackage"></a>

CloudFront ディストリビューションで OAC を作成または設定する前に、CloudFront に MediaPackage v2 オリジンへのアクセス許可があることを確認してください。これは、CloudFront ディストリビューションを作成した後で、ディストリビューション設定で MediaPackage v2 オリジンに OAC を追加する前に行います。

IAM ポリシーを使用して、CloudFront サービスプリンシパル (`cloudfront.amazonaws.com`) がオリジンにアクセスできるようにします。ポリシーの `Condition` 要素は、MediaPackage v2 オリジンを含む CloudFront ディストリビューションを対象とするリクエストに限り、MediaPackage v2 オリジンへのアクセスを CloudFront に許可します。**これは、OAC を追加する MediaPackage v2 オリジンを持つディストリビューションです。

**Example : OAC が有効になっている CloudFront ディストリビューションへの読み取り専用アクセスを許可する IAM ポリシー**  
次のポリシーは、CloudFront ディストリビューション (`E1PDK09ESKHJWT`) に MediaPackage v2 オリジンへのアクセスを許可します。オリジンは、`Resource` 要素に指定された ARN です。    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {"Service": "cloudfront.amazonaws.com"},
            "Action": "mediapackagev2:GetObject",
            "Resource": "arn:aws:mediapackagev2:us-east-1:123456789012:channelGroup/channel-group-name/channel/channel-name/originEndpoint/origin_endpoint_name",
            "Condition": {
                "StringEquals": {"AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E1PDK09ESKHJWT"}
            }
        }
    ]
}
```

**注意事項**  
MQAR 機能とオリジンアクセスコントロール (OAC) を有効にした場合は、IAM ポリシーに `mediapackagev2:GetHeadObject` アクションを追加します。MQAR では MediaPackage v2 オリジンに `HEAD` リクエストを送信するためにこのアクセス許可が必要です。MQAR の詳細については、「[Media Quality-Aware Resiliency](media-quality-score.md)」を参照してください。
MediaPackage v2 オリジンへのアクセス許可がないディストリビューションを作成した場合は、CloudFront コンソールで **[ポリシーをコピー]** を選択し、**[エンドポイントのアクセス許可を更新]** を選択できます。次に、コピーしたアクセス許可をエンドポイントにアタッチできます。詳細については、「AWS Elemental MediaPackage ユーザーガイド」の「[エンドポイントポリシーフィールド](https://docs.aws.amazon.com/mediapackage/latest/userguide/endpoints-policy.html)」を参照してください。**

### OAC の作成
<a name="create-oac-mediapackage"></a>

OAC を作成するには、AWS マネジメントコンソール、CloudFormation、AWS CLI、または CloudFront API を使用できます。

------
#### [ Console ]

**OAC を作成するには**

1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. ナビゲーションペインで、[**オリジンアクセス**] を選択します。

1. [**コントロール設定を作成**] を選択します。

1. **[新しい OAC を作成]** フォームで、次の操作を実行します。

   1. OAC の**名前**とオプションの**説明**を入力します。

   1. **[署名動作]** は、デフォルト設定の **[署名リクエスト (推奨)]** のままにすることをお勧めします。詳細については、「[オリジンアクセスコントロールの詳細設定](#oac-advanced-settings-mediapackage)」を参照してください。

1. **[オリジンタイプ]** で、**[MediaPackage V2]** を選択します。

1. **[作成]** を選択します。
**ヒント**  
OAC を作成したら、**名前**を書き留めておきます。次の手順では、この操作を行う必要があります。

**ディストリビューションの MediaPackage v2 オリジンに OAC を追加するには**

1. CloudFront コンソール ([https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)) を開きます。

1. OAC を追加する先の MediaPackage V2 オリジンがあるディストリビューションを選択し、**[オリジン]** タブを選択します。

1. OAC を追加する先の MediaPackage v2 オリジンを選択し、**[編集]** を選択します。

1. オリジンの **[Protocol]** (プロトコル) として **[HTTPS only]** (HTTPS のみ) を選択します。

1. **[オリジンアクセスコントロール]** ドロップダウンから、使用する OAC 名を選択します。

1. **[Save changes]** (変更の保存) をクリックします。

ディストリビューションは、すべての CloudFront エッジロケーションへのデプロイを開始します。エッジロケーションは、新しい設定を受け取ると、MediaPackage v2 オリジンに送信するすべてのリクエストに署名します。

------
#### [ CloudFormation ]

CloudFormation で OAC を作成するには、`AWS::CloudFront::OriginAccessControl` リソースタイプを使用します。次の例は、OAC を作成するための CloudFormation テンプレート構文を YAML 形式で示しています。

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: mediapackagev2
      SigningBehavior: always
      SigningProtocol: sigv4
```

詳細については、*AWS CloudFormation ユーザーガイド*の「[AWS::CloudFront::OriginAccessControl](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html)」を参照してください。

------
#### [ CLI ]

AWS Command Line Interface (AWS CLI) を使用してオリジンアクセスコントロールを作成するには、**aws cloudfront create-origin-access-control** コマンドを使用します。コマンドの入力パラメータは、コマンドライン入力として個別に指定せずに、入力ファイルを使用して指定できます。

**オリジンアクセスコントロール (入力ファイルを含む CLI) を作成するには**

1. 次のコマンドを使用して、`origin-access-control.yaml` という名前のファイルを作成します。このファイルには、**create-origin-access-control** コマンドのすべての入力パラメータが含まれます。

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. 先ほど作成した `origin-access-control.yaml` ファイルを開きます。ファイルを編集して OAC の名前、説明 (オプション) を追加し、`SigningBehavior` を `always` に変更します。その後、ファイルを保存します。

   その他の OAC の設定については、「[オリジンアクセスコントロールの詳細設定](#oac-advanced-settings-mediapackage)」を参照してください。

1. 次のコマンドを使用して、`origin-access-control.yaml` ファイルの入力パラメータを使用し、オリジンアクセスコントロールを作成します。

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   コマンド出力の `Id` 値を書き留めます。これは、CloudFront ディストリビューションで MediaPackage v2 オリジンに OAC を追加するために必要です。

**既存のディストリビューションで MediaPackage v2 オリジンに OAC をアタッチするには (CLI で入力ファイルを使用する場合)**

1. 以下のコマンドを使用して、OAC を追加する CloudFront ディストリビューションのディストリビューション設定を保存します。ディストリビューションには MediaPackage v2 オリジンが必要です。

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. 先ほど作成した `dist-config.yaml` という名前のファイルを開きます。ファイルを編集し、以下の変更を加えます。
   + `Origins` オブジェクトで、`OriginAccessControlId` という名前のフィールドに OAC の ID を追加します。
   + `OriginAccessIdentity` という名前のフィールドから値を削除します (存在する場合)。
   + `ETag` フィールドの名前を `IfMatch` に変更します。ただし、フィールドの値は変更しないでください。

   完了したら、ファイルを保存します。

1. オリジンアクセスコントロールを使用するようにディストリビューションを更新するには、次のコマンドを使用します。

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

ディストリビューションは、すべての CloudFront エッジロケーションへのデプロイを開始します。エッジロケーションは、新しい設定を受け取ると、MediaPackage v2 オリジンに送信するすべてのリクエストに署名します。

------
#### [ API ]

CloudFront API で OAC を作成するには、[CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html) を使用します。この API コールで指定するフィールドの詳細については、AWS SDK やその他の API クライアントの API リファレンスドキュメントを参照してください。

OAC を作成したら、以下の API コールのいずれかを使用して、OAC をディストリビューションの MediaPackage v2 オリジンにアタッチできます。
+ 既存のディストリビューションにアタッチするには、[UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) を使用します。
+ 新しいディストリビューションにアタッチするには、[CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) を使用します。

これらの API コールの両方について、`OriginAccessControlId` フィールドのオリジン内に OAC ID を指定します。これらの API コールで指定するその他フィールドの詳細については、「[すべてのディストリビューション設定リファレンス](distribution-web-values-specify.md)」と、AWS SDK またはその他 API クライアントの API リファレンスドキュメントを参照してください。

------

## オリジンアクセスコントロールの詳細設定
<a name="oac-advanced-settings-mediapackage"></a>

CloudFront OAC 機能には、特定のユースケースのみを対象とした詳細設定が含まれています。詳細設定が特に必要でない限り、推奨設定を使用してください。

OAC には、**[署名動作]** (コンソール) または `SigningBehavior` (API、CLI、CloudFormation) という名前の設定が含まれています。この設定では、次のオプションを使用できます。

**オリジンリクエストに常に署名する (推奨設定)**  
コンソールの [**Sign requests (recommended)**] (署名リクエスト (推奨))、または API、CLI、および CloudFormation の `always` という設定を使用することをお勧めします。この設定の場合、CloudFront は MediaPackage v2 オリジンに送信するすべてのリクエストに常に署名します。

**オリジンリクエストに署名しない**  
この設定は、コンソールでは [**リクエストに署名しない**]、または API、CLI、およびCloudFormation では `never` です。この設定を使用して、この OAC を使用するすべてのディストリビューションですべてのオリジンの OAC をオフにします。OAC を使用するすべてのオリジンとディストリビューションから OAC を 1 つずつ削除する場合と比べて、この設定で時間と労力を節約できます。この設定の場合、CloudFront は MediaPackage v2 オリジンに送信するいずれのリクエストにも署名しません。  
この設定を使用するには、MediaPackage v2 オリジンがパブリックにアクセス可能である必要があります。この設定を、パブリックにアクセスできない MediaPackage v2 オリジンで使用すると、CloudFront はオリジンにアクセスできません。MediaPackage v2 オリジンは CloudFront にエラーを返し、CloudFront はこれらのエラーをビューワーに渡します。詳細については、「AWS Elemental MediaPackage ユーザーガイド」の「[MediaPackage のポリシーとアクセス許可](https://docs.aws.amazon.com/mediapackage/latest/userguide/policies-permissions.html)」で MediaPackage v2 ポリシーの例を参照してください。**

**ビューワー (クライアント) の `Authorization` ヘッダーを上書きしない**  
この設定は、コンソールでは [**認可ヘッダーを上書きしない**] で、API、CLI、および CloudFormation では `no-override` です。この設定は、対応するビューワーリクエストに `Authorization` ヘッダーに含まれていない場合にのみ、CloudFront がオリジンリクエストに署名するよう指定する場合に使用します。この設定では、ビューワーリクエストが存在するが、ビューワーリクエストに `Authorization` ヘッダーが含まれていないときにオリジンリクエストに署名する (独自の `Authorization` ヘッダーを追加) ときに、CloudFront はビューワーリクエストから `Authorization` ヘッダーを渡します。  
ビューワーリクエストから `Authorization` ヘッダーを渡すには、このオリジンアクセスコントロールに関連付けられた MediaPackage v2 オリジンを使用するすべてのキャッシュ動作で、`Authorization` ヘッダーを[キャッシュポリシー](controlling-the-cache-key.md)に追加する必要があります。**

# AWS Elemental MediaStore オリジンへのアクセスを制限する
<a name="private-content-restricting-access-to-mediastore"></a>

CloudFront には、AWS Elemental MediaStore オリジンへのアクセスを制限するための*オリジンアクセスコントロール* (OAC) が用意されています。

**Topics**
+ [新しいオリジンアクセスコントロールを作成する](#create-oac-overview-mediastore)
+ [オリジンアクセスコントロールの詳細設定](#oac-advanced-settings-mediastore)

## 新しいオリジンアクセスコントロールを作成する
<a name="create-oac-overview-mediastore"></a>

次のトピックで説明されているステップを実行して、CloudFront で新しいオリジンアクセスコントロールを設定します。

**Topics**
+ [前提条件](#oac-prerequisites-mediastore)
+ [MediaStore オリジンにアクセスするアクセス許可を CloudFront に付与する](#oac-permission-to-access-mediastore)
+ [オリジンアクセスコントロールを作成する](#create-oac-mediastore)

### 前提条件
<a name="oac-prerequisites-mediastore"></a>

オリジンアクセスコントロール (OAC) を作成して設定する前に、MediaStore オリジンを持つ CloudFront ディストリビューションが必要です。

### MediaStore オリジンにアクセスするアクセス許可を CloudFront に付与する
<a name="oac-permission-to-access-mediastore"></a>

CloudFront ディストリビューションでオリジンアクセスコントロールを作成または設定する前に、CloudFront に MediaStore オリジンへのアクセス許可があることを確認してください。これは CloudFront ディストリビューションを作成した後、ディストリビューション設定で MediaStore オリジンに OAC を追加する前に行います。

MediaStore コンテナポリシーを使用して、CloudFront サービスプリンシパル (`cloudfront.amazonaws.com`) がオリジンにアクセスできるようにします。ポリシーの `Condition` 要素を使用して、MediaStore オリジンを含む CloudFront ディストリビューションに代わってリクエストが行われた場合にのみ MediaStore コンテナへのアクセスを CloudFront に許可します。これは、OAC を追加する MediaStore オリジンを持つディストリビューションです。

以下の例は、MediaStore オリジンへのアクセスを CloudFront ディストリビューションに許可する MediaStore コンテナポリシーを示しています。

**Example OAC が有効になっている CloudFront ディストリビューションへの読み取り専用アクセスを許可する MediaStore コンテナポリシー**    
****  

```
{
        "Version":"2012-10-17",		 	 	 
        "Statement": [
            {
                "Sid": "AllowCloudFrontServicePrincipalReadOnly",
                "Effect": "Allow",
                "Principal": {
                  "Service": "cloudfront.amazonaws.com"
                },
                "Action": [ 
                  "mediastore:GetObject"
                ],
                "Resource": "arn:aws:mediastore:us-east-1:111122223333:container/<container name>/*",
                "Condition": {
                    "StringEquals": {
                      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront-distribution-ID"
                    },
                    "Bool": {
                      "aws:SecureTransport": "true"
                    }
                }
            }
        ]
}
```

**Example OAC が有効になっている CloudFront ディストリビューションへの読み取りおよび書き込みアクセスを許可する MediaStore コンテナポリシー**    
****  

```
{
        "Version":"2012-10-17",		 	 	 
        "Statement": [
            {
                "Sid": "AllowCloudFrontServicePrincipalReadWrite",
                "Effect": "Allow",
                "Principal": {
                  "Service": "cloudfront.amazonaws.com"
                },
                "Action": [ 
                  "mediastore:GetObject",
                  "mediastore:PutObject"
                ],
                "Resource": "arn:aws:mediastore:us-east-1:111122223333:container/container-name/*",
                "Condition": {
                    "StringEquals": {
                      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront-distribution-ID"
                    },
                    "Bool": {
                      "aws:SecureTransport": "true"
                    }
                }
            }
        ]
}
```

**注記**  
書き込みアクセスを許可するには、**許可されている HTTP メソッド**の設定により、CloudFront ディストリビューションの動作設定に `PUT` を含める必要があります。

### オリジンアクセスコントロールを作成する
<a name="create-oac-mediastore"></a>

OAC を作成するには、AWS マネジメントコンソール、CloudFormation、AWS CLI、または CloudFront API を使用できます。

------
#### [ Console ]

**オリジンアクセスコントロールを作成するには**

1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. ナビゲーションペインで、[**オリジンアクセス**] を選択します。

1. [**コントロール設定を作成**] を選択します。

1. [**コントロール設定を作成**] フォームで、以下の操作を行います。

   1. [**詳細**] ペインに、[**名前**] と (オプションで) オリジンアクセスコントロールの [**説明**] を入力します。

   1. [**設定**] ペインでは、デフォルト設定である [**Sign requests (recommended)**] (署名リクエスト (推奨)) をそのまま使用することをお勧めします。詳細については、「[オリジンアクセスコントロールの詳細設定](#oac-advanced-settings-mediastore)」を参照してください。

1. **[Origin type]** (オリジンタイプ) ドロップダウンから [MediaStore] を選択します。

1. **[作成]** を選択します。

   OAC を作成したら、[**名前**] を書き留めておきます。次の手順では、この操作を行う必要があります。

**ディストリビューションの MediaStore オリジンにオリジンアクセスコントロールを追加するには**

1. CloudFront コンソール ([https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)) を開きます。

1. OAC を追加する先の MediaStore オリジンがあるディストリビューションを選択し、**[Origins]** (オリジン) タブを選択します。

1. OAC を追加する先の MediaStore オリジンを選択し、**[Edit]** (編集) を選択します。

1. オリジンの **[Protocol]** (プロトコル) として **[HTTPS only]** (HTTPS のみ) を選択します。

1. **[Origin access control]** (オリジンアクセスコントロール) ドロップダウンメニューから、使用する OAC を選択します。

1. **[Save changes]** (変更の保存) をクリックします。

ディストリビューションは、すべての CloudFront エッジロケーションへのデプロイを開始します。エッジロケーションは、新しい設定を受け取ると、MediaStore バケットオリジンに送信するすべてのリクエストに署名します。

------
#### [ CloudFormation ]

CloudFormation を使用してオリジンアクセスコントロール (OAC) を作成するには、`AWS::CloudFront::OriginAccessControl` リソースタイプを使用します。以下の例は、オリジンアクセスコントロールを作成するための CloudFormation テンプレート構文を YAML 形式で示しています。

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: mediastore
      SigningBehavior: always
      SigningProtocol: sigv4
```

詳細については、*AWS CloudFormation ユーザーガイド*の「[AWS::CloudFront::OriginAccessControl](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html)」を参照してください。

------
#### [ CLI ]

AWS Command Line Interface (AWS CLI) を使用してオリジンアクセスコントロールを作成するには、**aws cloudfront create-origin-access-control** コマンドを使用します。コマンドの入力パラメータは、コマンドライン入力として個別に指定せずに、入力ファイルを使用して指定できます。

**オリジンアクセスコントロール (入力ファイルを含む CLI) を作成するには**

1. 次のコマンドを使用して、`origin-access-control.yaml` という名前のファイルを作成します。このファイルには、**create-origin-access-control** コマンドのすべての入力パラメータが含まれます。

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. 先ほど作成した `origin-access-control.yaml` ファイルを開きます。ファイルを編集して OAC の名前、説明 (オプション) を追加し、`SigningBehavior` を `always` に変更します。その後、ファイルを保存します。

   その他の OAC の設定については、「[オリジンアクセスコントロールの詳細設定](#oac-advanced-settings-mediastore)」を参照してください。

1. 次のコマンドを使用して、`origin-access-control.yaml` ファイルの入力パラメータを使用し、オリジンアクセスコントロールを作成します。

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   コマンド出力の `Id` 値を書き留めます。これは、CloudFront ディストリビューションの MediaStore オリジンに OAC を追加するために必要です。

**OAC を既存のディストリビューションの MediaStore オリジンにアタッチするには (CLI で入力ファイルを使用する場合)**

1. 以下のコマンドを使用して、OAC を追加する CloudFront ディストリビューションのディストリビューション設定を保存します。ディストリビューションには MediaStoore オリジンが必要です。

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. 先ほど作成した `dist-config.yaml` という名前のファイルを開きます。ファイルを編集し、以下の変更を加えます。
   + `Origins` オブジェクトで、`OriginAccessControlId` という名前のフィールドに OAC の ID を追加します。
   + `OriginAccessIdentity` という名前のフィールドから値を削除します (存在する場合)。
   + `ETag` フィールドの名前を `IfMatch` に変更します。ただし、フィールドの値は変更しないでください。

   完了したら、ファイルを保存します。

1. オリジンアクセスコントロールを使用するようにディストリビューションを更新するには、次のコマンドを使用します。

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

ディストリビューションは、すべての CloudFront エッジロケーションへのデプロイを開始します。エッジロケーションは、新しい設定を受け取ると、MediaStore オリジンに送信するすべてのリクエストに署名します。

------
#### [ API ]

CloudFront API でオリジンアクセスコントロールを作成するには、[CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html) を使用します。この API コールで指定するフィールドの詳細については、AWS SDK やその他の API クライアントの API リファレンスドキュメントを参照してください。

オリジンアクセスコントロールを作成したら、以下の API コールのいずれかを使用して、それをディストリビューションの MediaStore オリジンにアタッチできます。
+ 既存のディストリビューションにアタッチするには、[UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) を使用します。
+ 新しいディストリビューションにアタッチするには、[CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) を使用します。

これらの API コールの両方について、`OriginAccessControlId` フィールドのオリジン内にオリジンアクセスコントロール ID を指定します。これらの API コールで指定するその他フィールドの詳細については、「[すべてのディストリビューション設定リファレンス](distribution-web-values-specify.md)」と、AWS SDK またはその他 API クライアントの API リファレンスドキュメントを参照してください。

------

## オリジンアクセスコントロールの詳細設定
<a name="oac-advanced-settings-mediastore"></a>

CloudFront オリジンアクセスコントロール機能には、特定のユースケースのみを対象とした詳細設定が含まれています。詳細設定が特に必要でない限り、推奨設定を使用してください。

オリジンアクセスコントロールには、[**署名動作**] (コンソール)、または `SigningBehavior` (API、CLI、および CloudFormation) という設定が含まれています この設定では、次のオプションを使用できます。

**オリジンリクエストに常に署名する (推奨設定)**  
コンソールの [**Sign requests (recommended)**] (署名リクエスト (推奨))、または API、CLI、および CloudFormation の `always` という設定を使用することをお勧めします。この設定の場合、CloudFront は MediaStore オリジンに送信するすべてのリクエストに常に署名します。

**オリジンリクエストに署名しない**  
この設定は、コンソールでは [**リクエストに署名しない**]、または API、CLI、およびCloudFormation では `never` です。この設定を使用して、このオリジンアクセスコントロールを使用するすべてのディストリビューションのすべてのオリジンに対して、オリジンアクセスコントロールをオフにします。これにより、オリジンアクセスコントロールを使用するすべてのオリジンとディストリビューションからコントロールを 1 つずつ削除する場合に比べて、時間と労力を節約できます。この設定の場合、CloudFront は MediaStore オリジンに送信するいずれのリクエストにも署名しません。  
この設定を使用するには、MediaStore オリジンがパブリックにアクセス可能である必要があります。パブリックにアクセスできない MediaStore オリジンでこの設定を使用すると、CloudFront はオリジンにアクセスできません。MediaStore オリジンは CloudFront にエラーを返し、CloudFront はこれらのエラーをビューワーに渡します。詳細については、コンテナポリシーの例: [HTTPS 経由のパブリック読み取りアクセス](https://docs.aws.amazon.com/mediastore/latest/ug/policies-examples-public-https.html)を参照してください。

**ビューワー (クライアント) の `Authorization` ヘッダーを上書きしない**  
この設定は、コンソールでは [**認可ヘッダーを上書きしない**] で、API、CLI、および CloudFormation では `no-override` です。この設定は、対応するビューワーリクエストに `Authorization` ヘッダーに含まれていない場合にのみ、CloudFront がオリジンリクエストに署名するよう指定する場合に使用します。この設定では、ビューワーリクエストが存在するが、ビューワーリクエストに `Authorization` ヘッダーが含まれていないときにオリジンリクエストに署名する (独自の `Authorization` ヘッダーを追加) ときに、CloudFront はビューワーリクエストから `Authorization` ヘッダーを渡します。  
ビューワーリクエストから `Authorization` ヘッダーを渡すには、このオリジンアクセスコントロールに関連付けられた MediaStore オリジンを使用するすべてのキャッシュ動作で、`Authorization` ヘッダーを[キャッシュポリシー](controlling-the-cache-key.md)に追加する必要があります。

# AWS Lambda 関数 URL オリジンへのアクセスを制限する
<a name="private-content-restricting-access-to-lambda"></a>

CloudFront には、Lambda 関数 URL オリジンへのアクセスを制限するための*オリジンアクセスコントロール* (OAC) が用意されています。

**Topics**
+ [新しい OAC を作成する](#create-oac-overview-lambda)
+ [オリジンアクセスコントロールの詳細設定](#oac-advanced-settings-lambda)
+ [テンプレートのコード例](#example-template-code-lambda-oac)

## 新しい OAC を作成する
<a name="create-oac-overview-lambda"></a>

CloudFront で新しい OAC を設定するには、以下のトピックに示す手順を実行します。

**重要**  
Lambda 関数 URL で `PUT` メソッドまたは `POST` メソッドを使用する場合、ユーザーはリクエストを CloudFront に送信するときにリクエスト本文の SHA256 を計算し、本文のペイロードハッシュ値を `x-amz-content-sha256` ヘッダーに含める必要があります。Lambda は、署名されていないペイロードをサポートしていません。

**Topics**
+ [前提条件](#oac-prerequisites-lambda)
+ [Lambda 関数 URL へのアクセス許可を CloudFront に付与する](#oac-permission-to-access-lambda)
+ [OAC を作成する](#create-oac-lambda)

### 前提条件
<a name="oac-prerequisites-lambda"></a>

OAC を作成して設定する前に、Lambda 関数 URL をオリジンとして持つ CloudFront ディストリビューションが必要です。OAC を使用するには、`AuthType` パラメータの値として `AWS_IAM` を指定する必要があります。詳細については、「[Lambda 関数 URL を使用する](DownloadDistS3AndCustomOrigins.md#concept_lambda_function_url)」を参照してください。

### Lambda 関数 URL へのアクセス許可を CloudFront に付与する
<a name="oac-permission-to-access-lambda"></a>

CloudFront ディストリビューションで OAC を作成または設定する前に、Lambda 関数 URL へのアクセス許可が CloudFront にあることを確認します。これは、CloudFront ディストリビューションを作成した後で、ディストリビューション設定で Lambda 関数 URL に OAC を追加する前に行います。

**注記**  
Lambda 関数 URL の IAM ポリシーを更新するには、AWS Command Line Interface (AWS CLI) を使用する必要があります。現時点では、Lambda コンソールでの IAM ポリシーの編集はサポートされていません。

次の AWS CLI コマンドは、CloudFront サービスプリンシパル (`cloudfront.amazonaws.com`) に Lambda 関数 URL へのアクセスを許可します。ポリシーの `Condition` 要素は、Lambda 関数 URL を含む CloudFront ディストリビューションを対象とするリクエストに限り、Lambda へのアクセス許可を CloudFront に付与します。**これは、OAC を追加する Lambda 関数 URL オリジンを持つディストリビューションです。

**Example : OAC が有効になっている CloudFront ディストリビューションへの読み取り専用アクセスを許可するようにポリシーを更新する AWS CLI コマンド**  
次の AWS CLI コマンドは、CloudFront ディストリビューション (`E1PDK09ESKHJWT`) に Lambda *`FUNCTION_URL_NAME`* へのアクセスを許可します。

```
aws lambda add-permission \
--statement-id "AllowCloudFrontServicePrincipal" \
--action "lambda:InvokeFunctionUrl" \
--principal "cloudfront.amazonaws.com" \
--source-arn "arn:aws:cloudfront::123456789012:distribution/E1PDK09ESKHJWT" \
--function-name FUNCTION_URL_NAME
```

```
aws lambda add-permission \
--statement-id "AllowCloudFrontServicePrincipalInvokeFunction" \
--action "lambda:InvokeFunction" \
--principal "cloudfront.amazonaws.com" \
--source-arn "arn:aws:cloudfront::123456789012:distribution/E1PDK09ESKHJWT" \
--function-name FUNCTION_URL_NAME
```

**注記**  
作成したディストリビューションに Lambda 関数 URL へのアクセス許可がない場合は、CloudFront コンソールで **[CLI コマンドをコピー]** を選択し、このコマンドをコマンドラインターミナルから入力できます。詳細については、「AWS Lambda デベロッパーガイド」の「[AWS のサービスへのアクセス権を関数に付与する](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html#permissions-resource-serviceinvoke)」を参照してください。**

### OAC を作成する
<a name="create-oac-lambda"></a>

OAC を作成するには、AWS マネジメントコンソール、CloudFormation、AWS CLI、または CloudFront API を使用できます。

------
#### [ Console ]

**OAC を作成するには**

1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. ナビゲーションペインで、[**オリジンアクセス**] を選択します。

1. [**コントロール設定を作成**] を選択します。

1. **[新しい OAC を作成]** フォームで、次の操作を実行します。

   1. OAC の**名前**とオプションの**説明**を入力します。

   1. **[署名動作]** は、デフォルト設定の **[署名リクエスト (推奨)]** のままにすることをお勧めします。詳細については、「[オリジンアクセスコントロールの詳細設定](#oac-advanced-settings-lambda)」を参照してください。

1. **[オリジンタイプ]** で、**[Lambda]** を選択します。

1. **[作成]** を選択します。
**ヒント**  
OAC を作成したら、**名前**を書き留めておきます。次の手順では、この操作を行う必要があります。

**ディストリビューションの Lambda 関数 URL にオリジンアクセスコントロールを追加するには**

1. CloudFront コンソール ([https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)) を開きます。

1. OAC を追加する先の Lambda 関数 URL があるディストリビューションを選択し、**[オリジン]** タブを選択します。

1. OAC を追加する先の Lambda 関数 URL を選択し、**[編集]** を選択します。

1. オリジンの **[Protocol]** (プロトコル) として **[HTTPS only]** (HTTPS のみ) を選択します。

1. **[オリジンアクセスコントロール]** ドロップダウンから、使用する OAC 名を選択します。

1. **[Save changes]** (変更の保存) をクリックします。

ディストリビューションは、すべての CloudFront エッジロケーションへのデプロイを開始します。エッジロケーションは、新しい設定を受け取ると、Lambda 関数 URL に送信するすべてのリクエストに署名します。

------
#### [ CloudFormation ]

CloudFormation で OAC を作成するには、`AWS::CloudFront::OriginAccessControl` リソースタイプを使用します。次の例は、OAC を作成するための CloudFormation テンプレート構文を YAML 形式で示しています。

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: lambda
      SigningBehavior: always
      SigningProtocol: sigv4
```

詳細については、*AWS CloudFormation ユーザーガイド*の「[AWS::CloudFront::OriginAccessControl](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html)」を参照してください。

------
#### [ CLI ]

AWS Command Line Interface (AWS CLI) を使用してオリジンアクセスコントロールを作成するには、**aws cloudfront create-origin-access-control** コマンドを使用します。コマンドの入力パラメータは、コマンドライン入力として個別に指定せずに、入力ファイルを使用して指定できます。

**オリジンアクセスコントロール (入力ファイルを含む CLI) を作成するには**

1. 次のコマンドを使用して、`origin-access-control.yaml` という名前のファイルを作成します。このファイルには、**create-origin-access-control** コマンドのすべての入力パラメータが含まれます。

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. 先ほど作成した `origin-access-control.yaml` ファイルを開きます。ファイルを編集して OAC の名前、説明 (オプション) を追加し、`SigningBehavior` を `always` に変更します。その後、ファイルを保存します。

   その他の OAC の設定については、「[オリジンアクセスコントロールの詳細設定](#oac-advanced-settings-lambda)」を参照してください。

1. 次のコマンドを使用して、`origin-access-control.yaml` ファイルの入力パラメータを使用し、オリジンアクセスコントロールを作成します。

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   コマンド出力の `Id` 値を書き留めます。これは、CloudFront ディストリビューションの Lambda 関数 URL に OAC を追加するために必要です。

**既存のディストリビューションの Lambda 関数 URL に OAC をアタッチするには (CLI で入力ファイルを使用する場合)**

1. 以下のコマンドを使用して、OAC を追加する CloudFront ディストリビューションのディストリビューション設定を保存します。ディストリビューションには、オリジンとして Lambda 関数 URL が必要です。

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. 先ほど作成した `dist-config.yaml` という名前のファイルを開きます。ファイルを編集し、以下の変更を加えます。
   + `Origins` オブジェクトで、`OriginAccessControlId` という名前のフィールドに OAC の ID を追加します。
   + `OriginAccessIdentity` という名前のフィールドから値を削除します (存在する場合)。
   + `ETag` フィールドの名前を `IfMatch` に変更します。ただし、フィールドの値は変更しないでください。

   完了したら、ファイルを保存します。

1. オリジンアクセスコントロールを使用するようにディストリビューションを更新するには、次のコマンドを使用します。

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

ディストリビューションは、すべての CloudFront エッジロケーションへのデプロイを開始します。エッジロケーションは、新しい設定を受け取ると、Lambda 関数 URL に送信するすべてのリクエストに署名します。

------
#### [ API ]

CloudFront API で OAC を作成するには、[CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html) を使用します。この API コールで指定するフィールドの詳細については、AWS SDK やその他の API クライアントの API リファレンスドキュメントを参照してください。

OAC を作成したら、以下の API コールのいずれかを使用して、ディストリビューションの Lambda 関数 URL に OAC をアタッチできます。
+ 既存のディストリビューションにアタッチするには、[UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) を使用します。
+ 新しいディストリビューションにアタッチするには、[CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) を使用します。

これらの API コールの両方について、`OriginAccessControlId` フィールドのオリジン内に OAC ID を指定します。これらの API コールで指定する他のフィールドの詳細については、AWS SDK または他の API クライアントの API リファレンスドキュメントを参照してください。

------

## オリジンアクセスコントロールの詳細設定
<a name="oac-advanced-settings-lambda"></a>

CloudFront OAC 機能には、特定のユースケースのみを対象とした詳細設定が含まれています。詳細設定が特に必要でない限り、推奨設定を使用してください。

OAC には、**[署名動作]** (コンソール) または `SigningBehavior` (API、CLI、CloudFormation) という名前の設定が含まれています。この設定では、次のオプションを使用できます。

**オリジンリクエストに常に署名する (推奨設定)**  
コンソールの [**Sign requests (recommended)**] (署名リクエスト (推奨))、または API、CLI、および CloudFormation の `always` という設定を使用することをお勧めします。この設定の場合、CloudFront は Lambda 関数 URL に送信するすべてのリクエストに常に署名します。

**オリジンリクエストに署名しない**  
この設定は、コンソールでは [**リクエストに署名しない**]、または API、CLI、およびCloudFormation では `never` です。この設定を使用して、この OAC を使用するすべてのディストリビューションですべてのオリジンの OAC をオフにします。OAC を使用するすべてのオリジンとディストリビューションから OAC を 1 つずつ削除する場合と比べて、この設定で時間と労力を節約できます。この設定の場合、CloudFront は Lambda 関数 URL に送信するいずれのリクエストにも署名しません。  
この設定を使用するには、Lambda 関数 URL がパブリックにアクセス可能である必要があります。この設定を、パブリックにアクセスできない Lambda 関数 URL で使用すると、CloudFront はオリジンにアクセスできません。Lambda 関数 URL は、CloudFront にエラーを返し、CloudFront はこれらのエラーをビューワーに渡します。詳細については、「AWS Lambda ユーザーガイド」の「[Lambda 関数 URL におけるセキュリティと認証モデル](https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html)」を参照してください。**

**ビューワー (クライアント) の `Authorization` ヘッダーを上書きしない**  
この設定は、コンソールでは [**認可ヘッダーを上書きしない**] で、API、CLI、および CloudFormation では `no-override` です。この設定は、対応するビューワーリクエストに `Authorization` ヘッダーに含まれていない場合にのみ、CloudFront がオリジンリクエストに署名するよう指定する場合に使用します。この設定では、ビューワーリクエストが存在するが、ビューワーリクエストに `Authorization` ヘッダーが含まれていないときにオリジンリクエストに署名する (独自の `Authorization` ヘッダーを追加) ときに、CloudFront はビューワーリクエストから `Authorization` ヘッダーを渡します。  
+ この設定を使用する場合は、CloudFront ディストリビューションの名前または CNAME の代わりに Lambda 関数 URL の署名バージョン 4 の署名を指定する必要があります。CloudFront がビューワーリクエストから Lambda 関数 URL に `Authorization` ヘッダーを転送すると、Lambda は Lambda URL ドメインのホストに対して署名を検証します。署名が Lambda URL ドメインに基づいていない場合、署名のホストは Lambda URL オリジンで使用するホストと一致しません。つまり、リクエストは失敗し、署名検証エラーが発生します。
+ ビューワーリクエストから `Authorization` ヘッダーを渡すには、このオリジンアクセスコントロールに関連付けられた Lambda 関数 URL を使用するすべてのキャッシュ動作で、`Authorization` ヘッダーを[キャッシュポリシー](controlling-the-cache-key.md)に追加する必要があります。**

## テンプレートのコード例
<a name="example-template-code-lambda-oac"></a>

CloudFront オリジンが OAC に関連付けられている Lambda 関数 URL である場合は、次の Python スクリプトを使用して、`POST` メソッドで Lambda 関数にファイルをアップロードできます。

このコードでは、OAC の設定時にデフォルトの署名動作を **[オリジンリクエストに常に署名する]** に設定していること、および **[認証ヘッダーを上書きしない]** 設定を選択していないことを前提としています。

この設定により、OAC は Lambda ホスト名を使用して Lambda で SigV4 認証を正しく管理できます。ペイロードに署名するには、`IAM_AUTH` タイプとして指定された、Lambda 関数 URL で認証された IAM アイデンティティからの SigV4 を使用します。

テンプレートは、クライアント側からの `POST` リクエストの x-amz-content-sha256 ヘッダーで署名付きペイロードハッシュ値を処理する方法を示しています。特に、このテンプレートはフォームデータのペイロードを管理するように設計されています。テンプレートでは、CloudFront を介して Lambda 関数 URL への安全なファイルアップロードを可能にし、AWS 認証メカニズムを使用して、認証されたリクエストのみが Lambda 関数にアクセスできるようにします。

**コードには次の機能が含まれています。**  
x-amz-content-sha256 ヘッダーにペイロードハッシュを含めるという要件に対応
SigV4 認証を使用して安全な AWS のサービス アクセスを実現
マルチパートフォームデータを使用したファイルアップロードをサポート
リクエスト例外のエラー処理に対応

```
import boto3
from botocore.auth import SigV4Auth
from botocore.awsrequest import AWSRequest
import requests
import hashlib
import os


def calculate_body_hash(body):
    return hashlib.sha256(body).hexdigest()


def sign_request(request, credentials, region, service):
    sigv4 = SigV4Auth(credentials, service, region)
    sigv4.add_auth(request)


def upload_file_to_lambda(cloudfront_url, file_path, region):
    # AWS credentials
    session = boto3.Session()
    credentials = session.get_credentials()

    # Prepare the multipart form-data
    boundary = "------------------------boundary"

    # Read file content
    with open(file_path, 'rb') as file:
        file_content = file.read()

    # Get the filename from the path
    filename = os.path.basename(file_path)

    # Prepare the multipart body
    body = (
        f'--{boundary}\r\n'
        f'Content-Disposition: form-data; name="file"; filename="{filename}"\r\n'
        f'Content-Type: application/octet-stream\r\n\r\n'
    ).encode('utf-8')
    body += file_content
    body += f'\r\n--{boundary}--\r\n'.encode('utf-8')

    # Calculate SHA256 hash of the entire body
    body_hash = calculate_body_hash(body)

    # Prepare headers
    headers = {
        'Content-Type': f'multipart/form-data; boundary={boundary}',
        'x-amz-content-sha256': body_hash
    }

    # Create the request
    request = AWSRequest(
        method='POST',
        url=cloudfront_url,
        data=body,
        headers=headers
    )

    # Sign the request
    sign_request(request, credentials, region, 'lambda')

    # Get the signed headers
    signed_headers = dict(request.headers)

    # Print request headers before sending
    print("Request Headers:")
    for header, value in signed_headers.items():
        print(f"{header}: {value}")

    try:
        # Send POST request with signed headers
        response = requests.post(
            cloudfront_url,
            data=body,
            headers=signed_headers
        )

        # Print response status and content
        print(f"\nStatus code: {response.status_code}")
        print("Response:", response.text)

        # Print response headers
        print("\nResponse Headers:")
        for header, value in response.headers.items():
            print(f"{header}: {value}")

    except requests.exceptions.RequestException as e:
        print(f"An error occurred: {e}")


# Usage
cloudfront_url = "https://d111111abcdef8.cloudfront.net"
file_path = r"filepath"
region = "us-east-1"  # example: "us-west-2"

upload_file_to_lambda(cloudfront_url, file_path, region)
```

# Amazon S3 オリジンへのアクセスを制限する
<a name="private-content-restricting-access-to-s3"></a>

CloudFront には、認証済みリクエストを Amazon S3 オリジンに送信するために、*オリジンアクセスコントロール* (OAC) と*オリジンアクセスアイデンティティ* (OAI) という 2 つの方法が用意されています。OAC は、Amazon S3 などのオリジンを保護するのに役立ちます。

以下の機能をサポートしているため、代わりに OAC を使用することを*お勧め*します。
+ すべての AWS リージョンのすべての Amazon S3 バケット (2022 年 12 月以降に開始されたオプトインリージョンを含む)
+ [AWS KMS による Amazon S3 サーバー側の暗号化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) (SSE-KMS)
+ Amazon S3 に対する動的なリクエスト (`PUT` と `DELETE`)

OAI はこれらの機能をサポートしていないか、これらのシナリオでは追加の回避策が必要です。既に OAI を使用していて、移行する場合は、「[オリジンアクセスアイデンティティ (OAI) からオリジンアクセスコントロール (OAC) への移行](#migrate-from-oai-to-oac)」を参照してください。

**注意事項**  
Amazon S3 バケットオリジンで CloudFront OAC を使用する場合は、**[Amazon S3 オブジェクト所有権]** を、新しい Amazon S3 バケットのデフォルトである **[バケット所有者の強制]** に設定する必要があります。ACL が必要な場合は、**[希望するバケット所有者]** を使用し、CloudFront 経由でアップロードされたオブジェクトの制御を維持します。
オリジンが、[ウェブサイトエンドポイント](https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteEndpoints.html)として設定されている Amazon S3 バケットである場合、CloudFront でカスタムオリジンとして設定する必要があります。つまり、OAC (または OAI) を使用することはできません。OAC は、Lambda@Edge を使用したオリジンリダイレクトをサポートしていません。

以下のトピックでは、Amazon S3 オリジンで OAC を使用する方法について説明します。

**トピック**
+ [新しいオリジンアクセスコントロールを作成する](#create-oac-overview-s3)
+ [S3 バケットに OAC がアタッチされたディストリビューションを削除する](#delete-oac-distribution-s3)
+ [オリジンアクセスアイデンティティ (OAI) からオリジンアクセスコントロール (OAC) への移行](#migrate-from-oai-to-oac)
+ [オリジンアクセスコントロールの詳細設定](#oac-advanced-settings-s3)

## 新しいオリジンアクセスコントロールを作成する
<a name="create-oac-overview-s3"></a>

次のトピックで説明されているステップを実行して、CloudFront で新しいオリジンアクセスコントロールを設定します。

**Topics**
+ [前提条件](#oac-prerequisites-s3)
+ [S3 バケットへのアクセス許可を CloudFront に付与する](#oac-permission-to-access-s3)
+ [オリジンアクセスコントロールを作成する](#create-oac-s3)

### 前提条件
<a name="oac-prerequisites-s3"></a>

オリジンアクセスコントロール (OAC) を作成して設定する前に、Amazon S3 バケットオリジンを持つ CloudFront ディストリビューションが必要です。このオリジンは、[ウェブサイトエンドポイント](https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteEndpoints.html)として設定されたバケットではなく、通常の S3 バケットである必要があります。S3 バケットオリジンを使用した CloudFront ディストリビューションのセットアップの詳細については、「[CloudFront 標準ディストリビューションの開始方法](GettingStarted.SimpleDistribution.md)」を参照してください。

**重要**  
OAC を使用して Amazon S3 オリジンを保護する場合、CloudFront と Amazon S3 間の通信は*常に* HTTPS を介して行われますが、*[常にリクエストに署名]* を選択した場合に限られます。コンソールで **[リクエストに署名 (推奨)]** を選択するか、CloudFront API、AWS CLI、または CloudFormation で [`always`] を指定する必要があります。  
**[リクエストに署名しない]** または **[認証ヘッダーを上書きしない]** オプションを選択した場合、CloudFront は次のポリシーで指定した接続プロトコルを使用します。  
[ビューワープロトコルポリシー](using-https-viewers-to-cloudfront.md) 
[オリジンプロトコルポリシー](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy) (カスタムオリジンのみ)
例えば、**[認証ヘッダーを上書きしない]** を選択し、CloudFront と Amazon S3 オリジンの間で HTTPS を使用する場合は、[ビューワープロトコルポリシー](using-https-viewers-to-cloudfront.md)に **HTTP を HTTPS にリダイレクト**または **HTTPS のみ**を使用します。

### S3 バケットへのアクセス許可を CloudFront に付与する
<a name="oac-permission-to-access-s3"></a>

オリジンアクセスコントロール (OAC) を作成したり、CloudFront ディストリビューションで設定したりする前に、CloudFront に S3 バケットオリジンへのアクセス許可があることを確認してください。これは CloudFront ディストリビューションを作成した後、ディストリビューション設定の S3 オリジンに OAC を追加する前に行います。

S3 [バケットポリシー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html)を使用して、CloudFront サービスプリンシパル (`cloudfront.amazonaws.com`) がバケットにアクセスできるようにします。ポリシーの `Condition` 要素を使用して、S3 オリジンを含む CloudFront ディストリビューションに代わってリクエストが行われた場合にのみ CloudFront がバケットにアクセスできるようにします。これは、OAC を追加する S3 オリジンを持つディストリビューションです。

バケットポリシーの追加または変更の詳細については、*Amazon S3 ユーザーガイド*の「[Amazon S3 コンソールを使用したバケットポリシーの追加](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html)」を参照してください。

以下の例は、OAC が有効になっている CloudFront ディストリビューションに S3 オリジンへのアクセスを許可する S3 バケットポリシーを示しています。

**Example OAC が有効になっている CloudFront ディストリビューションへの読み取り専用アクセスを許可する S3 バケットポリシー**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipalReadOnly",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
        }
      }
    }
  ]
}
```

**Example OAC が有効になっている CloudFront ディストリビューションへの読み取りおよび書き込みアクセスを許可する S3 バケットポリシー**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipalReadWrite",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront-distribution-ID>"
        }
      }
    }
  ]
}
```

#### SSE-KMS
<a name="oac-permissions-sse-kms"></a>

S3 バケットオリジン内のオブジェクトが [AWS Key Management Service (SSE-KMS) でのサーバー側の暗号化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html)を使用して暗号化されている場合は、CloudFront ディストリビューションに AWS KMS キーを使用するアクセス許可があることを確認する必要があります。KMS キーを使用するアクセス許可を CloudFront ディストリビューションに付与するには、[KMS キーポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)にステートメントを追加します。キーポリシーを変更する方法については、*AWS Key Management Service デベロッパーガイド*の「[キーポリシーの変更](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)」を参照してください。

**Example KMS キーポリシーステートメント**  
次の例は、OAC を使用した CloudFront ディストリビューションが SSE-KMS の KMS キーにアクセスできるようにする AWS KMS ポリシーステートメントを示しています。  

```
{
    "Sid": "AllowCloudFrontServicePrincipalSSE-KMS",
    "Effect": "Allow",
    "Principal": {
        "Service": [
            "cloudfront.amazonaws.com"
        ]
     },
    "Action": [
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:GenerateDataKey*"
    ],
    "Resource": "*",
    "Condition": {
            "StringEquals": {
                "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
            }
        }
}
```

### オリジンアクセスコントロールを作成する
<a name="create-oac-s3"></a>

オリジンアクセスコントロール (OAC) を作成するには、AWS マネジメントコンソール、CloudFormation、AWS CLI、または CloudFront API を使用します。

------
#### [ Console ]

**オリジンアクセスコントロールを作成するには**

1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. ナビゲーションペインで、[**オリジンアクセス**] を選択します。

1. [**コントロール設定を作成**] を選択します。

1. [**コントロール設定を作成**] フォームで、以下の操作を行います。

   1. [**詳細**] ペインに、[**名前**] と (オプションで) オリジンアクセスコントロールの [**説明**] を入力します。

   1. [**設定**] ペインでは、デフォルト設定である [**Sign requests (recommended)**] (署名リクエスト (推奨)) をそのまま使用することをお勧めします。詳細については、「[オリジンアクセスコントロールの詳細設定](#oac-advanced-settings-s3)」を参照してください。

1. **[Origin type]** (オリジンタイプ) ドロップダウンから [S3] を選択します。

1. **[作成]** を選択します。

   OAC を作成したら、[**名前**] を書き留めておきます。次の手順では、この操作を行う必要があります。

**ディストリビューションの S3 オリジンにオリジンアクセスコントロールを追加するには**

1. CloudFront コンソール ([https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)) を開きます。

1. OAC を追加する S3 オリジンのあるディストリビューションを選択し、[**オリジン**] タブを選択します。

1. OAC を追加する S3 オリジンを選択し、[**編集**] を選択します。

1. **[オリジンアクセス]** で、**[オリジンアクセスコントロール設定 (推奨)]** を選択します。

1. **[Origin access control]** (オリジンアクセスコントロール) ドロップダウンメニューから、使用する OAC を選択します。

1. **[Save changes]** (変更の保存) をクリックします。

ディストリビューションは、すべての CloudFront エッジロケーションへのデプロイを開始します。エッジロケーションは、新しい設定を受け取ると、S3 バケットオリジンに送信するすべてのリクエストに署名します。

------
#### [ CloudFormation ]

CloudFormation を使用してオリジンアクセスコントロール (OAC) を作成するには、`AWS::CloudFront::OriginAccessControl` リソースタイプを使用します。以下の例は、オリジンアクセスコントロールを作成するための CloudFormation テンプレート構文を YAML 形式で示しています。

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: s3
      SigningBehavior: always
      SigningProtocol: sigv4
```

詳細については、*AWS CloudFormation ユーザーガイド*の「[AWS::CloudFront::OriginAccessControl](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html)」を参照してください。

------
#### [ CLI ]

AWS Command Line Interface (AWS CLI) を使用してオリジンアクセスコントロールを作成するには、**aws cloudfront create-origin-access-control** コマンドを使用します。コマンドの入力パラメータは、コマンドライン入力として個別に指定せずに、入力ファイルを使用して指定できます。

**オリジンアクセスコントロール (入力ファイルを含む CLI) を作成するには**

1. 次のコマンドを使用して、`origin-access-control.yaml` という名前のファイルを作成します。このファイルには、**create-origin-access-control** コマンドのすべての入力パラメータが含まれます。

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. 先ほど作成した `origin-access-control.yaml` ファイルを開きます。ファイルを編集して OAC の名前、説明 (オプション) を追加し、`SigningBehavior` を `always` に変更します。その後、ファイルを保存します。

   その他の OAC の設定については、「[オリジンアクセスコントロールの詳細設定](#oac-advanced-settings-s3)」を参照してください。

1. 次のコマンドを使用して、`origin-access-control.yaml` ファイルの入力パラメータを使用し、オリジンアクセスコントロールを作成します。

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   コマンド出力の `Id` 値を書き留めます。これは、CloudFront ディストリビューションの S3 バケットオリジンに OAC を追加するために必要です。

**OAC を既存のディストリビューションの S3 バケットオリジンにアタッチするには (入力ファイルを含む CLI)**

1. 以下のコマンドを使用して、OAC を追加する CloudFront ディストリビューションのディストリビューション設定を保存します。ディストリビューションには S3 バケットオリジンが必要です。

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. 先ほど作成した `dist-config.yaml` という名前のファイルを開きます。ファイルを編集し、以下の変更を加えます。
   + `Origins` オブジェクトで、`OriginAccessControlId` という名前のフィールドに OAC の ID を追加します。
   + `OriginAccessIdentity` という名前のフィールドから値を削除します (存在する場合)。
   + `ETag` フィールドの名前を `IfMatch` に変更します。ただし、フィールドの値は変更しないでください。

   完了したら、ファイルを保存します。

1. オリジンアクセスコントロールを使用するようにディストリビューションを更新するには、次のコマンドを使用します。

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

ディストリビューションは、すべての CloudFront エッジロケーションへのデプロイを開始します。エッジロケーションは新しい設定を受け取ると、S3 バケットオリジンに送信するすべてのリクエストに署名します。

------
#### [ API ]

CloudFront API でオリジンアクセスコントロールを作成するには、[CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html) を使用します。この API コールで指定するフィールドの詳細については、AWS SDK やその他の API クライアントの API リファレンスドキュメントを参照してください。

オリジンアクセスコントロールを作成したら、次の API コールのいずれかを使用して、それをディストリビューションの S3 バケットオリジンにアタッチできます。
+ 既存のディストリビューションにアタッチするには、[UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) を使用します。
+ 新しいディストリビューションにアタッチするには、[CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) を使用します。

これらの API コールの両方について、`OriginAccessControlId` フィールドのオリジン内にオリジンアクセスコントロール ID を指定します。これらの API コールで指定するその他フィールドの詳細については、「[すべてのディストリビューション設定リファレンス](distribution-web-values-specify.md)」と、AWS SDK またはその他 API クライアントの API リファレンスドキュメントを参照してください。

------

## S3 バケットに OAC がアタッチされたディストリビューションを削除する
<a name="delete-oac-distribution-s3"></a>

S3 バケットに OAC がアタッチされたディストリビューションを削除する必要がある場合は、S3 バケットオリジンを削除する前に、ディストリビューションを削除する必要があります。または、オリジンドメイン名にリージョンを含めます。これが不可能な場合は、削除前にパブリックに切り替えることで、OAC をディストリビューションから削除できます。詳細については、「[ディストリビューションを削除する](HowToDeleteDistribution.md)」を参照してください。

## オリジンアクセスアイデンティティ (OAI) からオリジンアクセスコントロール (OAC) への移行
<a name="migrate-from-oai-to-oac"></a>

レガシーのオリジンアクセスアイデンティティ (OAI) からオリジンアクセスコントロール (OAC) に移行するには、まず S3 バケットオリジンを更新して、OAI と OAC が有効になっているディストリビューションの両方がバケットのコンテンツにアクセスできるようにします。これにより、移行中に CloudFront がバケットにアクセスできなくなる状況を回避できます。OAI と OAC が有効になっているディストリビューションの両方が S3 バケットにアクセスできるようにするには、[バケットポリシー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html)を更新し、プリンシパルの種類ごとに 1 つずつ、2 つのステートメントを含めます。

次の S3 バケットポリシー例では、OAI と OAC が有効になっているディストリビューションの両方に S3 オリジンへのアクセスを許可しています。

**Example OAC が有効になっている OAI と CloudFront ディストリビューションの読み取り専用アクセスを許可する S3 バケットポリシー**    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipalReadOnly",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<S3 bucket name>/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
                }
            }
        },
        {
            "Sid": "AllowLegacyOAIReadOnly",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<S3 bucket name>/*"
        }
    ]
}
```

S3 オリジンのバケットポリシーを更新して OAI と OAC の両方へのアクセスを許可したら、OAI の代わりに OAC を使用するようにディストリビューション設定を更新できます。詳細については、「[新しいオリジンアクセスコントロールを作成する](#create-oac-overview-s3)」を参照してください。

ディストリビューションが完全にデプロイされたら、OAI へのアクセスを許可するバケットポリシー内のステートメントを削除できます。詳しくは、「[S3 バケットへのアクセス許可を CloudFront に付与する](#oac-permission-to-access-s3)」を参照してください。

## オリジンアクセスコントロールの詳細設定
<a name="oac-advanced-settings-s3"></a>

CloudFront オリジンアクセスコントロール機能には、特定のユースケースのみを対象とした詳細設定が含まれています。詳細設定が特に必要でない限り、推奨設定を使用してください。

オリジンアクセスコントロールには、[**署名動作**] (コンソール)、または `SigningBehavior` (API、CLI、および CloudFormation) という設定が含まれています この設定では、次のオプションを使用できます。

**オリジンリクエストに常に署名する (推奨設定)**  
コンソールの [**Sign requests (recommended)**] (署名リクエスト (推奨))、または API、CLI、および CloudFormation の `always` という設定を使用することをお勧めします。この設定では、CloudFront は S3 バケットオリジンに送信するすべてのリクエストに常に署名します。

**オリジンリクエストに署名しない**  
この設定は、コンソールでは [**リクエストに署名しない**]、または API、CLI、およびCloudFormation では `never` です。この設定を使用して、このオリジンアクセスコントロールを使用するすべてのディストリビューションのすべてのオリジンに対して、オリジンアクセスコントロールをオフにします。これにより、オリジンアクセスコントロールを使用するすべてのオリジンとディストリビューションからコントロールを 1 つずつ削除する場合に比べて、時間と労力を節約できます。この設定では、CloudFront は S3 バケットオリジンに送信するリクエストには署名しません。  
この設定を使用するには、S3 バケットオリジンがパブリックにアクセス可能である必要があります。パブリックにアクセスできない S3 バケットオリジンでこの設定を使用すると、CloudFront はオリジンにアクセスできません。S3 バケットオリジンは CloudFront にエラーを返し、CloudFront はそれらのエラーをビューワーに渡します。

**ビューワー (クライアント) の `Authorization` ヘッダーを上書きしない**  
この設定は、コンソールでは [**認可ヘッダーを上書きしない**] で、API、CLI、および CloudFormation では `no-override` です。この設定は、対応するビューワーリクエストに `Authorization` ヘッダーに含まれていない場合にのみ、CloudFront がオリジンリクエストに署名するよう指定する場合に使用します。この設定では、ビューワーリクエストが存在するが、ビューワーリクエストに `Authorization` ヘッダーが含まれていないときにオリジンリクエストに署名する (独自の `Authorization` ヘッダーを追加) ときに、CloudFront はビューワーリクエストから `Authorization` ヘッダーを渡します。  
ビューワーリクエストから `Authorization` ヘッダーを渡すには、このオリジンアクセスコントロールに関連付けられた S3 バケットオリジンを使用するすべてのキャッシュ動作に対して、`Authorization` ヘッダーを[キャッシュポリシー](controlling-the-cache-key.md)に*必ず*追加する必要があります。

## オリジンアクセスアイデンティティを使用する (レガシー、非推奨)
<a name="private-content-restricting-access-to-s3-oai"></a>

### オリジンアクセスアイデンティの概要
<a name="private-content-restricting-access-to-s3-overview"></a>

CloudFront の*オリジンアクセスアイデンティティ* (OAI) は*オリジンアクセスコントロール* (OAC) と類似した機能を提供しますが、すべてのシナリオで機能するわけではありません。具体的には、OAI は以下をサポートしていません。
+ オプトインリージョンを含む、すべての AWS リージョンの Amazon S3 バケット
+ [AWS KMS による Amazon S3 サーバー側の暗号化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) (SSE-KMS)
+ Amazon S3 に対する動的なリクエスト (`PUT`、`POST`、または `DELETE`)
+ 2023 年 1 月以降に新しい AWS リージョンをリリース

**ヒント**  
代わりに OAC を使用することをお勧めします。OAC を設定するには、「[新しいオリジンアクセスコントロールを作成する](#create-oac-overview-s3)」を参照してください。OAI から OAC への移行に関する詳細については、「[オリジンアクセスアイデンティティ (OAI) からオリジンアクセスコントロール (OAC) への移行](#migrate-from-oai-to-oac)」を参照してください。

### Amazon S3 バケット内のファイルを読み取るアクセス許可をオリジンアクセスアイデンティティに付与する
<a name="private-content-granting-permissions-to-oai"></a>

CloudFront コンソールを使用して OAI を作成するか、OAI をディストリビューションに追加する場合、バケットにアクセスするための OAI の許可を与えるように Amazon S3 バケットポリシーを自動的に更新できます。あるいは、このバケットポリシーの手動での作成または更新を選択することができます。どちらの方法を使用する場合でも、アクセス許可を確認して次のことを確認する必要があります。
+ CloudFront OAI は、CloudFront 経由でリクエストしているビューワーに代わってバケット内のファイルにアクセスできます。
+ ビューワーは、Amazon S3 URL を使用して CloudFront の外のファイルにアクセスすることができません。

**重要**  
CloudFront でサポートされるすべての HTTP メソッドを受け入れて転送するように CloudFront を設定する場合は、必ず CloudFront OAI に目的のアクセス許可を付与してください。例えば、`DELETE` メソッドを使用するリクエストを受け入れて転送するように CloudFront を設定する場合、適切なファイルのみをビューワーが削除できるように、`DELETE` リクエストを適切に処理するバケットポリシーを設定してください。

#### Amazon S3 バケットポリシーを使用する
<a name="private-content-updating-s3-bucket-policies"></a>

Amazon S3 バケット内のファイルへのアクセス許可を CloudFront OAI に付与するには、次の方法でバケットポリシーを作成または更新します。
+ [Amazon S3 コンソール](https://console.aws.amazon.com/s3/home)で、Amazon S3 バケットの [**アクセス許可**] タブを使用する。
+ Amazon S3 API の [PutBucketPolicy](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketPolicy.html) を使用する。
+ [CloudFront コンソール](https://console.aws.amazon.com/cloudfront/v4/home)を使用する。CloudFront コンソールでオリジン設定に OAI を追加するときに、[**Yes, update the bucket policy**] (はい、バケットポリシーを更新します) を選択すると、ユーザーに代わってバケットポリシーを更新するように CloudFront に指示できます。

バケットポリシーを手動で更新する場合は、次の点を確認してください。
+ ポリシーで正しい OAI を `Principal` として指定します。
+ ビューワーに代わってオブジェクトにアクセスするために必要なアクセス許可を OAI に付与します。

詳細については、次のセクションを参照してください。

##### バケットポリシーで OAI を `Principal` として指定
<a name="private-content-updating-s3-bucket-policies-principal"></a>

Amazon S3 バケットポリシーで `Principal` として OAI を指定するには、OAI の ID を含む OAI の Amazon リソースネーム (ARN) を使用します。例えば、次のようになります。

```
"Principal": {
    "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
}
```

CloudFront コンソールの **[セキュリティ]**、**[オリジンアクセス]**、**[アイデンティティ (レガシー)]** で OAI ID を検索します。または、CloudFront API の [ListCloudFrontOriginAccessIdentities](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListCloudFrontOriginAccessIdentities.html) を使用します。

##### OAI にアクセス許可を付与
<a name="private-content-updating-s3-bucket-policies-permissions"></a>

Amazon S3 バケット内のオブジェクトにアクセスするためのアクセス許可を OAI に付与するには、特定の Amazon S3 API オペレーションに関連するポリシーでアクションを使用します。例えば、`s3:GetObject` アクションは、OAI がバケット内のオブジェクトを読み取ることを許可します。詳細については、次のセクションの例を参照するか、*Amazon Simple Storage Service ユーザーガイド*の「[Amazon S3 のアクション](https://docs.aws.amazon.com/AmazonS3/latest/dev/using-with-s3-actions.html)」を参照してください。

##### Amazon S3 バケットポリシーの例
<a name="private-content-updating-s3-bucket-policies-examples"></a>

以下の例は、S3 バケットへのアクセスを CloudFront OAI に許可する Amazon S3 バケットポリシーを示しています。

CloudFront コンソールの **[セキュリティ]**、**[オリジンアクセス]**、**[アイデンティティ (レガシー)]** で OAI ID を検索します。または、CloudFront API の [ListCloudFrontOriginAccessIdentities](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListCloudFrontOriginAccessIdentities.html) を使用します。

**Example OAI に読み取りアクセスを許可する Amazon S3 バケットポリシー**  
次の例では、指定されたバケット (`s3:GetObject`) 内のオブジェクトの読み取りを OAI に許可します。    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<S3 bucket name>/*"
        }
    ]
}
```

**Example OAI に読み取りおよび書き込みアクセスを許可する Amazon S3 バケットポリシー**  
次の例では、指定されたバケット (`s3:GetObject` と `s3:PutObject`) 内のオブジェクトの読み取りおよび書き込みを OAI に許可します。これにより、ビューワーは CloudFront を介して Amazon S3 バケットにファイルをアップロードできます。    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
            },
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::<S3 bucket name>/*"
        }
    ]
}
```

#### Amazon S3 オブジェクト ACL を使用する (非推奨)
<a name="private-content-updating-s3-acls"></a>

**重要**  
[Amazon S3 バケットポリシーを使用して](#private-content-updating-s3-bucket-policies) OAI へのアクセスを S3 バケットに与えることを推奨します。このセクションで説明したようにアクセスコントロールリスト (ACL) を使用できますが、お勧めしません。  
Amazon S3 では**所有権が強化されたバケット**に [S3 オブジェクトの所有権](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html)を設定することを推奨しており、すなわち、バケットとその中のオブジェクトについて ACL が無効になっているということです。この設定を [オブジェクトの所有権] に適用する場合は、バケットポリシーを使用して OAI へのアクセスを与える必要があります (前のセクションを参照)。  
次のセクションは、ACL を必要とするレガシーユースケースのみを対象としています。

Amazon S3 バケット内のファイルへのアクセス許可を CloudFront OAI に付与するには、次の方法でファイルの ACL を作成または更新します。
+ [Amazon S3 コンソール](https://console.aws.amazon.com/s3/home)で、Amazon S3 オブジェクトの [**アクセス許可**] タブを使用する。
+ Amazon S3 API の [PutObjectAcl](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObjectAcl.html) を使用する。

ACL を使用して OAI へのアクセスを許可する場合、Amazon S3 の正規ユーザー ID を使用して OAI を指定する必要があります。CloudFront コンソールでは、この ID を **[セキュリティ]**、**[オリジンアクセス]**、**[アイデンティティ (レガシー)]** で検索できます。CloudFront API を使用している場合は、OAI の作成時に返された `S3CanonicalUserId` 要素の値を使用するか、CloudFront API の [ListCloudFrontOriginAccessIdentities](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListCloudFrontOriginAccessIdentities.html) を呼び出します。

### 署名バージョン 4 の認証のみをサポートする Amazon S3 リージョンでオリジンアクセスアイデンティティを使用する
<a name="private-content-origin-access-identity-signature-version-4"></a>

新しい Amazon S3 リージョンでは、リクエストの認証用に署名バージョン 4 を使用する必要があります。(各 Amazon S3 リージョンでサポートされている署名バージョンについては、「*AWS 全般のリファレンス*」の「[Amazon Simple Storage Service エンドポイントおよびクォータ](https://docs.aws.amazon.com/general/latest/gr/s3.html)」を参照してください)。オリジンアクセスアイデンティティを使用しており、バケットが、署名バージョン 4 が必要なリージョンの 1 つにある場合、以下の点に注意してください。
+ `DELETE`、`GET`、`HEAD`、`OPTIONS`、および `PATCH` リクエストは条件なしでサポートされます。
+ `POST` リクエストはサポートされません。

# VPC オリジンを使用したアクセス制限
<a name="private-content-vpc-origins"></a>

CloudFront を使用して、仮想プライベートクラウド (VPC) のプライベートサブネットでホストされているアプリケーションからコンテンツを配信できます。プライベートサブネットの Application Load Balancer (ALB)、Network Load Balancer (NLB)、EC2 インスタンスを VPC オリジンとして使用できます。

VPC オリジンを使用する理由は以下のとおりです。
+ **セキュリティ** – VPC オリジンは、ロードバランサーと EC2 インスタンスをプライベートサブネットに配置し、CloudFront を単一のエントリポイントにすることで、アプリケーションのセキュリティ体制を強化するように設計されています。ユーザーリクエストは、プライベートで安全な接続を介して CloudFront から VPC オリジンに送信され、アプリケーションのセキュリティを強化します。
+ **管理** – VPC オリジンは、CloudFront とオリジンの間の安全な接続に必要な運用オーバーヘッドを削減します。オリジンをパブリックアクセスのないプライベートサブネットに移動できます。オリジンへのアクセスを制限するためのアクセスコントロールリスト (ACL) やその他のメカニズムを実装する必要はありません。これにより、差別化につながらない開発作業に投資する必要なく、CloudFront でウェブアプリケーションを保護できます。
+ **スケーラビリティとパフォーマンス** – VPC オリジンは、ウェブアプリケーションを保護するのに役立ちます。CloudFront でセキュリティを向上させ、ハイパフォーマンスとグローバルスケーラビリティを維持しながら、重要なビジネスアプリケーションの育成に時間を集中できます。VPC オリジンは、セキュリティ管理を合理化し、運用の複雑さを軽減するため、CloudFront をアプリケーションの単一のエントリポイントとして使用できます。

**ヒント**  
CloudFront は、組織内にあるかどうかにかかわらず、AWS アカウント間で VPC オリジンを共有できます。VPC オリジンは CloudFront コンソールから共有することも、AWS Resource Access Manager (AWS RAM) を使用することもできます。詳細については、「[CloudFront での共有リソースの使用](sharing-resources.md)」を参照してください。

## 前提条件
<a name="vpc-origin-prerequisites"></a>

CloudFront ディストリビューションの VPC オリジンを作成する前に、以下のことを完了する必要があります。

### VPC 設定
<a name="vpc-configuration"></a>

VPC オリジン用にサポートされている AWS リージョンの 1 つで、**Amazon VPC に仮想プライベートクラウド (VPC) を作成します**。VPC の作成の詳細については、「*Amazon VPC ユーザーガイド*」の「[VPC と他の VPC リソースを作成する](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html#create-vpc-and-other-resources)」を参照してください。サポートされているリージョンのリストについては「」を参照してください[VPC オリジンでサポートされている AWS リージョン](#vpc-origins-supported-regions)

VPC には以下を含めます。
+ **インターネットゲートウェイ** – VPC オリジンリソースを持つ VPC にインターネットゲートウェイを追加する必要があります。インターネットゲートウェイは VPC がインターネットからトラフィックを受信できることを示すために必要です。インターネットゲートウェイは、サブネット内のオリジンへのトラフィックのルーティングには使用されないため、ルーティングポリシーを更新する必要はありません。
+ **少なくとも 1 つの利用可能な IPv4 アドレスを持つプライベートサブネット** – CloudFront は、プライベートオリジン CloudFront リソースの定義後に CloudFront で作成したサービスマネージド Elastic Network Interface (ENI) を使用してサブネットにルーティングします。ENI 作成プロセスを成功させるには、プライベートサブネットに少なくとも 1 つの利用可能な IPv4 アドレスが必要です。IPv4 アドレスはプライベートにすることができます。追加料金はかかりません。IPv6 専用サブネットはサポートされていません。

### オリジンリソース
<a name="origin-resources"></a>

プライベートサブネットで、オリジンとして使用する Application Load Balancer、Network Load Balancer、または EC2 インスタンスを起動します。起動するリソースは、VPC オリジンとして使用する前に、完全にデプロイ済みで、[アクティブ] ステータスになっている必要があります。

**オリジンの制限**
+ Gateway Load Balancers はオリジンとして追加できません
+ デュアルスタックの Network Load Balancer はオリジンとして追加できません
+ TLS リスナーを使用する Network Load Balancer はオリジンとして追加できません
+ VPC オリジンとして使用する Network Load Balancer には、セキュリティグループをアタッチする必要があります

### セキュリティグループの設定
<a name="security-group-configuration"></a>

VPC オリジンリソース (Application Load Balancer、Network Load Balancer、または EC2 インスタンス) には、セキュリティグループがアタッチされている必要があります。VPC オリジンを作成すると、CloudFront は命名パターン `CloudFront-VPCOrigins-Service-SG` でサービスマネージドセキュリティグループを自動的に作成します。このセキュリティグループは AWS によって完全に管理されるため、編集できません。

CloudFront からのトラフィックが VPC オリジンに到達できるようにするには、オリジンリソース (ALB、NLB、または EC2 インスタンス) にアタッチされたセキュリティグループを更新して、次のいずれかの方法を使用してインバウンドトラフィックを許可します。
+ **オプション 1:** CloudFront マネージドプレフィックスリストからトラフィックを許可します。詳細については、「[CloudFront マネージドプレフィックスリストを使用](LocationsOfEdgeServers.md#managed-prefix-list)」を参照してください。これは、VPC オリジンを作成する前にも実行できます。
+ **オプション 2:** CloudFront サービスマネージドセキュリティグループ (`CloudFront-VPCOrigins-Service-SG`) からのトラフィックを許可します。これは、VPC オリジンが作成され、サービスマネージドセキュリティグループが作成された後にのみ実行できます。この設定は、トラフィックを CloudFront ディストリビューションのみに制限するため、さらに制限されます。

**重要**  
`CloudFront-VPCOrigins-Service-SG` で始まる名前で独自のセキュリティグループを作成しないでください。これは、サービスマネージドセキュリティグループ用に予約された AWS 命名パターンです。詳細については、「[セキュリティグループの作成](https://docs.aws.amazon.com/vpc/latest/userguide/creating-security-groups.html)」を参照してください。

### プロトコルと機能の制限
<a name="protocol-feature-restrictions"></a>

VPC オリジンは以下をサポートしていません。
+ WebSockets
+ gRPC トラフィック
+ Lambda@Edge を使用したオリジンリクエストとオリジンレスポンスのトリガー

## VPC オリジンを作成する (新しいディストリビューション)
<a name="new-vpc-origin"></a>

次の手順は、CloudFront コンソールで新しい CloudFront ディストリビューションの VPC オリジンを作成する方法を示しています。別の方法として、AWS CLI または AWS SDK で [CreateVpcOrigin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateVpcOrigin.html) および [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) API オペレーションを使用することもできます。

**新しい CloudFront ディストリビューションの VPC オリジンを作成するには**

1. CloudFront コンソール ([https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)) を開きます。

1. **[VPC オリジン]**、**[VPC オリジンを作成]** の順に選択します。

1. 必須フィールドに入力します。**[オリジン ARN]** で、Application Load Balancer、Network Load Balancer、または EC2 インスタンスの ARN を選択します。ARN が表示されない場合は、代わりに特定のリソースの ARN をコピーして、ここに貼り付けることができます。

1. **[VPC オリジンを作成]** を選択します。

1. VPC オリジンのステータスが **[デプロイ済み]** に変わるまで待ちます。これには最大 15 分かかることがあります。

1. **[ディストリビューション]**、**[ディストリビューションを作成]** の順に選択します。

1. **[オリジンドメイン]** で、ドロップダウンリストから VPC オリジンリソースを選択します。

   VPC オリジンが EC2 インスタンスの場合は、インスタンスの**プライベート IP DNS 名**をコピーして **[オリジンドメイン]** フィールドに貼り付けます。

1. ディストリビューションの作成を完了します。詳細については、「[コンソールに CloudFront ディストリビューションを作成する](distribution-web-creating-console.md#create-console-distribution)」を参照してください。

## VPC オリジンを作成する (既存のディストリビューション)
<a name="existing-vpc-origin"></a>

次の手順では、CloudFront コンソールで既存の CloudFront ディストリビューションの VPC オリジンを作成する方法を示します。これにより、アプリケーションの継続的な可用性を確保できます。別の方法として、AWS CLI または AWS SDK で [CreateVpcOrigin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateVpcOrigin.html) および [UpdateDistributionWithStagingConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistributionWithStagingConfig.html) API オペレーションを使用することもできます。

必要に応じて、ステージングディストリビューションを作成せずに、VPC オリジンを既存のディストリビューションに追加することもできます。

**既存の CloudFront ディストリビューションの VPC オリジンを作成するには**

1. CloudFront コンソール ([https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home)) を開きます。

1. **[VPC オリジン]**、**[VPC オリジンを作成]** の順に選択します。

1. 必須フィールドに入力します。**[オリジン ARN]** で、Application Load Balancer、Network Load Balancer、または EC2 インスタンスの ARN を選択します。ARN が表示されない場合は、代わりに特定のリソースの ARN をコピーして、ここに貼り付けることができます。

1. **[VPC オリジンを作成]** を選択します。

1. VPC オリジンのステータスが **[デプロイ済み]** に変わるまで待ちます。これには最大 15 分かかることがあります。

1. ナビゲーションペインで、**[ディストリビューション]** を選択します。

1. ディストリビューションの ID を選択します。

1. **[全般]** タブの **[継続的デプロイ]** で、**[ステージングディストリビューションを作成]** を選択します。詳細については、「[CloudFront の継続的デプロイを使用して CDN 設定の変更を安全にテストする](continuous-deployment.md)」を参照してください。

1. **[ステージングディストリビューションを作成]** ウィザードの手順に従って、ステージングディストリビューションを作成します。以下のステップを実行します。
   + **[オリジン]** で、**[オリジンを作成]** を選択します。
   + **[オリジンドメイン]** で、ドロップダウンメニューから VPC オリジンリソースを選択します。

     VPC オリジンが EC2 インスタンスの場合は、インスタンスの**プライベート IP DNS 名**をコピーして **[オリジンドメイン]** フィールドに貼り付けます。
   + **[オリジンを作成]** を選択します。

1. ステージングディストリビューションで、VPC オリジンをテストします。

1. ステージングディストリビューション設定をプライマリディストリビューションに昇格させます。詳細については、「[ステージングディストリビューション設定を昇格させる](working-with-staging-distribution-continuous-deployment-policy.md#promote-staging-distribution-configuration)」を参照してください。

1. サブネットをプライベートにして、VPC オリジンへのパブリックアクセスを削除します。これを行うと、VPC オリジンはインターネット経由で検出できなくなりますが、CloudFront は引き続きプライベートアクセスを保持します。詳細については、「*Amazon VPC ユーザーガイド*」の「[サブネットをルートテーブルに関連付けるまたは関連付けを解除する](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AssociateSubnet)」を参照してください。

## VPC オリジンを更新する
<a name="update-vpc-origin"></a>

次の手順は、CloudFront コンソールで CloudFront ディストリビューションの VPC オリジンを更新する方法を示しています。別の方法として、AWS CLI または AWS SDK で [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) および [UpdateVpcOrigin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateVpcOrigin.html) API オペレーションを使用することもできます。

**CloudFront ディストリビューションの既存の VPC オリジンを更新するには**

1. [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. ナビゲーションペインで、**[ディストリビューション]** を選択します。

1. ディストリビューションの ID を選択します。

1. [**Behaviors**] タブを選択します。

1. VPC オリジンがキャッシュ動作のデフォルトオリジンではないことを確認します。

1. [**オリジン**] タブを選択します。

1. 更新する VPC オリジンを選択し、**[削除]** を選択します。これにより、VPC オリジンとディストリビューションの関連付けが解除されます。ステップ 2～7 を繰り返して、VPC オリジンと他のディストリビューションとの関連付けを解除します。

1. **[VPC オリジン]** を選択します。

1. VPC オリジンを選択し、**[編集]** を選択します。

1. 更新を行い、**[VPC オリジンを更新]** を選択します。

1. VPC オリジンのステータスが **[デプロイ済み]** に変わるまで待ちます。これには最大 15 分かかることがあります。

1. ナビゲーションペインで、**[ディストリビューション]** を選択します。

1. ディストリビューションの ID を選択します。

1. [**オリジン**] タブを選択します。

1. **[オリジンを作成]** を選択します。

1. **[オリジンドメイン]** で、ドロップダウンメニューから VPC オリジンリソースを選択します。

   VPC オリジンが EC2 インスタンスの場合は、インスタンスの**プライベート IP DNS 名**をコピーして **[オリジンドメイン]** フィールドに貼り付けます。

1. **[オリジンを作成]** を選択します。これにより、VPC オリジンがディストリビューションに再度関連付けられます。ステップ 12～17 を繰り返して、更新した VPC オリジンを他のディストリビューションと関連付けます。

## VPC オリジンでサポートされている AWS リージョン
<a name="vpc-origins-supported-regions"></a>

現在、VPC オリジンは以下の商用 AWS リージョンでサポートされています。アベイラビリティーゾーン (AZ) の例外を注記しています。

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-vpc-origins.html)

# Application Load Balancer へのアクセスを制限する
<a name="restrict-access-to-load-balancer"></a>

Amazon CloudFront では、内部向けとインターネット向けの両方の Application Load Balancer を使用できます。VPC オリジンを使用して、CloudFront のプライベートサブネット内で内部 Application Load Balancer を使用できます。CloudFront VPC オリジンを使用すると、プライベート VPC サブネットにホストされたアプリケーションからパブリックインターネットに公開することなくコンテンツを提供できます。詳細については、「[VPC オリジンを使用したアクセス制限](private-content-vpc-origins.md)」を参照してください。

CloudFront でインターネット向け Application Load Balancer を使用している場合は、次のセキュリティ緩和策を使用することで、ユーザーが Application Load Balancer に直接アクセスできないようにし、CloudFront 経由でのみアクセスを許可できます。

1. CloudFront を設定して、Application Load Balancer に送信するリクエストにカスタム HTTP ヘッダーを追加します。

1. カスタム HTTP ヘッダーを含むリクエストだけを転送するように、Application Load Balancer を設定します。

1. このソリューションのセキュリティを向上させるためには、HTTPS が必要です。

CloudFront は、レイテンシーを削減し、分散型サービス拒否 (DDoS) 攻撃を吸収することにも役立ちます。

ユースケースで CloudFront と Application Load Balancer の両方からインターネット経由で直接ウェブアプリケーションへのデュアルアクセスが必要な場合は、次のようにウェブアプリケーション API を分割することを検討します。
+ CloudFront を経由する必要がある API。この場合、オリジンとして別のプライベート Application Load Balancer を使用することを検討します。
+ Application Load Balancer を介したアクセスを必要とする API。この場合、CloudFront をバイパスします。

または、Elastic Load Balancing のインターネット向け Application Load Balancer によって提供されるウェブアプリケーションやその他のコンテンツの場合、CloudFront はオブジェクトをキャッシュしてユーザー (ビューワー) に直接提供し、Application Load Balancer の負荷を軽減できます。インターネットに接続しているロードバランサーは、パブリックに解決可能な DNS 名を持ち、クライアントからのリクエストをインターネット経由でターゲットにルーティングします。

詳細については、以下のトピックを参照してください。これらのステップを完了すると、ユーザーは CloudFront 経由でしかApplication Load Balancer にアクセスできなくなります。

**Topics**
+ [リクエストにカスタム HTTP ヘッダーを追加するように CloudFront を設定する](#restrict-alb-add-custom-header)
+ [特定のヘッダーを含むリクエストだけを転送するように Application Load Balancer を設定する](#restrict-alb-route-based-on-header)
+ [(オプション) このソリューションのセキュリティ向上](#restrict-alb-improve-security)
+ [(オプション) CloudFront の AWS マネージドプレフィックスリストを使用してオリジンへのアクセスを制限します。](#limit-access-to-origin-using-aws-managed-prefixes)

## リクエストにカスタム HTTP ヘッダーを追加するように CloudFront を設定する
<a name="restrict-alb-add-custom-header"></a>

オリジン (この場合、Application Load Balancer) に送信するリクエストにカスタム HTTP ヘッダーを追加するように CloudFront を設定できます。

**重要**  
このユースケースは、カスタムヘッダー名と値の機密性維持を信頼しています。ヘッダー名と値が機密でない場合、他の HTTP クライアントは、Application Load Balancer に直接送信するリクエストにヘッダー名や値を含める可能性があります。これにより、リクエストをしていない時に、リクエストが CloudFront から送信されたかのように Application Load Balancer を動作させる可能性があります。これを防ぐためには、カスタムヘッダー名と値を機密にしておきます。

CloudFront コンソール、CloudFormation、または CloudFront API を使用して、オリジンリクエストにカスタム HTTP ヘッダーを追加するように CloudFront を設定できます。

**カスタム HTTP ヘッダーの追加 (CloudFront コンソール)**  
CloudFront コンソールで、**オリジン設定**の**オリジンカスタムヘッダー**設定を使用します。**[ヘッダー名]** とその **[値]** を入力します。  
本番環境では、ランダムに生成されたヘッダー名と値を使用します。ヘッダー名と値は、ユーザー名やパスワードなどと同様に、セキュリティ認証情報として取り扱います。
既存の CloudFront ディストリビューションのオリジンを作成または編集するとき、新しいディストリビューションを作成するときには、**オリジンカスタムヘッダー**設定を編集できます 。詳細については、「[ディストリビューションを更新する](HowToUpdateDistribution.md)」および「[ディストリビューションを作成する](distribution-web-creating-console.md)」を参照してください。

**カスタム HTTP ヘッダー () の追加CloudFormation**  
CloudFormation テンプレートで、次の例に示すように、`OriginCustomHeaders` プロパティを使用します。  
この例のヘッダー名と値は、デモンストレーションのためだけに使用されます。製作では、ランダムに生成された値を使用します。ヘッダー名と値は、ユーザー名やパスワードなどの安全な資格情報として扱います。

```
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  TestDistribution:
    Type: 'AWS::CloudFront::Distribution'
    Properties:
      DistributionConfig:
        Origins:
          - DomainName: app-load-balancer.example.com
            Id: Example-ALB
            CustomOriginConfig:
              OriginProtocolPolicy: https-only
              OriginSSLProtocols:
                - TLSv1.2
            OriginCustomHeaders:
               - HeaderName: X-Custom-Header
                 HeaderValue: random-value-1234567890
        Enabled: 'true'
        DefaultCacheBehavior:
          TargetOriginId: Example-ALB
          ViewerProtocolPolicy: allow-all
          CachePolicyId: 658327ea-f89d-4fab-a63d-7e88639e58f6
        PriceClass: PriceClass_All
        ViewerCertificate:
          CloudFrontDefaultCertificate: 'true'
```
詳細については、「AWS CloudFormation ユーザーガイド」の [[Origin]](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-origin.html) プロパティと [[OriginCustomHeader]](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-origincustomheader.html) プロパティを参照してください。**

**カスタム HTTP ヘッダーの追加 (CloudFront API)**  
CloudFront API で、`CustomHeaders` 内部オブジェクト`Origin`を使用します 。詳細については、『* Amazon CloudFront API リファレンス *』の[ CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)と[UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)、SDK またはその他の API クライアントのドキュメントを参照してください。

オリジンカスタムヘッダーとして指定できないヘッダー名がいくつかあります。詳細については、「[CloudFront でオリジンリクエストに追加できないカスタムヘッダー](add-origin-custom-headers.md#add-origin-custom-headers-denylist)」を参照してください。

## 特定のヘッダーを含むリクエストだけを転送するように Application Load Balancer を設定する
<a name="restrict-alb-route-based-on-header"></a>

CloudFront を設定して、Application Load Balancer に送信するリクエストにカスタム HTTP ヘッダーを追加した後 ([ 前のセクションを参照 ](#restrict-alb-add-custom-header))、このカスタムヘッダーを含むリクエストだけを転送するようにロードバランサーを設定できます。これを行うためには、新しいルールを追加し、ロードバランサーのリスナーでデフォルトルールを変更します。

**前提条件**  
次の手順を使用するためには、最低 1 つのリスナーがある Application Load Balancer が必要です。まだ作成していない場合には、Application Load Balancer のユーザーガイドで「[Application Load Balancer の作成](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html)」を参照してください。**

次の手順では、HTTPS リスナーを変更します。同じプロセスを使用して HTTP リスナーを変更できます。

**Application Load Balancer リスナーのルールの更新**

1. 新しいルールを追加します。「[ルールの追加](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-rules.html#add-rule)」の手順を使用します (ただし、以下の変更を加えます)。
   + CloudFront ディストリビューションのオリジンであるロードバランサーにルールを追加します。
   + **[条件を追加]** で、**[HTTP ヘッダー]** を選択します。CloudFront でオリジンカスタムヘッダーとして追加した HTTP ヘッダー名と値を指定します。
   + **[アクションを追加]** で、**[転送先]** を選択します。リクエストを転送するターゲットグループを選択します。

1. ロードバランサーのリスナーのデフォルトルールを編集します。「[ルールの編集](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-rules.html#edit-rule)」の手順を使用します (ただし、以下の変更を加えます)。
   + CloudFront ディストリビューションのオリジンであるロードバランサーのデフォルトルールを編集します。
   + デフォルトのアクションを削除し、**[アクションを追加]** で、**[固定レスポンスを返す]** を選択します。
   + [**応答コード**] に、**403**を入力します。
   + [**応答本文**] に、**Access denied**を入力します 。

上記の手順を完了すると、ロードバランサーリスナーは 2 つのルールを持ちます。最初のルールは、HTTP ヘッダーを含むリクエスト (CloudFront からのリクエスト) を転送します。2 番目のルールは、他のすべてのリクエスト (CloudFront 以外からのリクエスト) に対して固定レスポンスを送信します。

CloudFront ディストリビューションと Application Load Balancer にリクエストを送信することで、ソリューションが機能することを確認できます。CloudFront へのリクエストは、ウェブアプリケーションまたはコンテンツを返し、Application Load Balancer に直接送信されたリクエストは、`403`プレーンテキストメッセージが入ったレスポンスを返します`Access denied`。

## (オプション) このソリューションのセキュリティ向上
<a name="restrict-alb-improve-security"></a>

このソリューションのセキュリティ向上のために、Application Load Balancer にリクエストを送信するときに、常に HTTPS を使用するように CloudFront ディストリビューションを設定できます。このソリューションは、カスタムヘッダー名と値を機密に保つ場合に限り機能します。HTTPS を使用すると、盗聴者がヘッダー名と値を検出するのを防ぐことに役立ちます。また、ヘッダー名と値を定期的に交換することをお勧めします。

**オリジンリクエストに HTTPS を使用する**  
オリジンリクエストに HTTPS を使用するように CloudFront を設定するためには、[**オリジンプロトコルポリシー**] 設定を [**HTTPS だけ**] に設定します。この設定は、CloudFront コンソール、CloudFormation、および CloudFront API で使用できます。詳細については、「[プロトコル (カスタムオリジンのみ)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy)」を参照してください。

オリジンリクエストで HTTPS を使用するように CloudFront を設定する場合は、以下も適用されます。
+ オリジンリクエストポリシーを使用して `Host` ヘッダーをオリジンに転送するように CloudFront を設定する必要があります。[AllViewer マネージドオリジンリクエストポリシー](using-managed-origin-request-policies.md#managed-origin-request-policy-all-viewer)を使用できます。
+ [前のセクション](#restrict-alb-route-based-on-header)で示したように、Application Load Balancer に HTTPS リスナーがあることを確認します。詳細については、Application Load Balancer のユーザーガイドで「[HTTPS リスナーの作成](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)」を参照してください。**HTTPS リスナーを使用するには、Application Load Balancer にルーティングするドメイン名と一致する SSL/TLS 証明書が必要です。
+ CloudFront の SSL/TLS 証明書は、AWS Certificate Manager (ACM) の `us-east-1` AWS リージョンでのみリクエスト (またはインポート) できます。CloudFront はグローバルサービスであるため、証明書は、`us-east-1` リージョンから CloudFront ディストリビューションに関連するすべてのリージョンへと自動的に配布されます。
  + 例えば、`ap-southeast-2` リージョンに Application Load Balancer (ALB) がある場合、`ap-southeast-2` リージョン (CloudFront と ALB オリジンの間で HTTPS を使用する場合) と `us-east-1` リージョン (ビューワーと CloudFront の間で HTTPS を使用する場合) の両方で SSL/TLS 証明書を設定する必要があります。どちらの証明書も、Application Load Balancer にルーティングするドメイン名と一致する必要があります。詳細については、「[AWS リージョン 用の AWS Certificate Manager](cnames-and-https-requirements.md#https-requirements-aws-region)」を参照してください。
+ ウェブアプリケーションのエンドユーザー (*閲覧者*、または*クライアント*とも呼ばれる) が HTTPS を使用できる場合には、エンドユーザーからの HTTPS 接続を優先 (または必要とする) ように CloudFront を構成することもできます。これを行うためには、[**ビューワープロトコルポリシー**] 設定を使用します。エンドユーザを HTTP から HTTPS にリダイレクトする、またはHTTP を使用するリクエストを拒否するように設定できます。この設定は、CloudFront コンソール、CloudFormation、および CloudFront API で使用できます。詳細については、「[ビューワープロトコルポリシー](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy)」を参照してください。

**ヘッダー名と値を交換する**  
HTTPS の使用に加え、ヘッダー名と値を定期的に交換することをお勧めします。これを行うためのハイレベルな手順は次のとおりです。

1. CloudFront を設定して、Application Load Balancer に送信するリクエストに追加のカスタム HTTP ヘッダーを追加します。

1. Application Load Balancer リスナールールを更新して、この追加のカスタム HTTP ヘッダーを含むリクエストを転送します。

1. CloudFront を設定して、Application Load Balancer バランサーに送信するリクエストへの元のカスタム HTTP ヘッダー追加を停止します。

1. Application Load Balancer リスナールールを更新して、元のカスタム HTTP ヘッダーを含むリクエストの転送を停止します。

これらの手順を実行する方法の詳細については、前述のセクションを参照してください。

## (オプション) CloudFront の AWS マネージドプレフィックスリストを使用してオリジンへのアクセスを制限します。
<a name="limit-access-to-origin-using-aws-managed-prefixes"></a>

Application Load Balancer へのアクセスをさらに制限するには、サービスが AWS マネージドプレフィックスリストを使用しているときに CloudFront からのトラフィックのみを受け入れるように、Application Load Balancer に関連付けたセキュリティグループを設定します。これにより、CloudFront から発信されていないトラフィックは、ネットワーク層 (レイヤー 3) またはトランスポート層 (レイヤー 4) で Application Load Balancer に到達しないようになります。

詳細については、ブログ記事「[Amazon CloudFront の AWS マネージドプレフィックスリストを使用してオリジンへのアクセスを制限する](https://aws.amazon.com//blogs/networking-and-content-delivery/limit-access-to-your-origins-using-the-aws-managed-prefix-list-for-amazon-cloudfront/)」を参照してください。

# コンテンツの地理的配分を制限する
<a name="georestrictions"></a>

*地理的制限* (*地理的ブロック*とも呼ばれます) を使用すると、Amazon CloudFront ディストリビューションを通じて配信しているコンテンツに対して特定地域のユーザーがアクセスできないようにすることができます。地理的制限を使用するには、次の 2 つの方法があります。
+ CloudFront の地理的制限機能を使用する。ディストリビューションに関連するすべてのファイルへのアクセスを制限し、国レベルでアクセスを制限する場合は、この方法を使用します。
+ サードパーティーの位置情報サービスを使用する。ディストリビューションに関連するファイルのサブセットへのアクセスを制限する場合や、国レベルより詳細なレベルでアクセスを制限する場合は、この方法を使用します。

**Topics**
+ [CloudFront の地理的制限を使用する](#georestrictions-cloudfront)
+ [サードパーティの位置情報サービスを使用する](#georestrictions-geolocation-service)

## CloudFront の地理的制限を使用する
<a name="georestrictions-cloudfront"></a>

ユーザーがコンテンツをリクエストすると、通常 CloudFront はユーザーがいる場所に関係なくリクエストされたコンテンツを提供します。特定の国のユーザーによるコンテンツへのアクセスを回避する必要がある場合は、CloudFront の地理的制限を使用して、次のいずれかを行うことができます。
+ 承認された国の許可リストに含まれているいずれかの国にユーザーがいる場合のみ、コンテンツへのアクセス許可を付与する。
+ ユーザーが拒否リストにある禁止国にいる場合、コンテンツへのアクセスを禁止する。

例えば、コンテンツの配信が許可されていない国がリクエスト元である場合は、CloudFront の地理的制限を使用してリクエストをブロックできます。

**注記**  
CloudFront は、サードパーティーのデータベースを使用して、ユーザーがいる場所を判別します。IP アドレスと国とのマッピングの正確さは、リージョンによって異なります。最近のテストによれば、全体的な正確性は 99.8% です。CloudFront がユーザーの場所を特定できない場合、ユーザーがリクエストしたコンテンツは CloudFront から供給されます。

地理的制限は次のような仕組みになっています。

1. 仮に、コンテンツをリヒテンシュタインでのみ配信する権限を持っているとしましょう。CloudFront ディストリビューションを更新して、リヒテンシュタインのみを含む許可リストを追加します。(または、リヒテンシュタイン以外のすべての国を含む拒否リストを追加することもできます)。

1. モナコに住むユーザーからコンテンツがリクエストされた場合、DNS はそのリクエストをミラノ (イタリア) にある CloudFront エッジロケーションにルーティングします。

1. ミラノのエッジロケーションはお客さまのディストリビューションを検索し、モナコ王国のユーザーはコンテンツをダウンロードするアクセス許可がないと判断します。

1. CloudFront は HTTP ステータスコード `403 (Forbidden)` をユーザーに返します。

オプションで、ユーザーにカスタムエラーメッセージを返すよう CloudFront を設定することも、リクエストされたファイルに関するエラーレスポンスを CloudFront でキャッシュしておく時間の長さを指定することもできます。デフォルト値は 10 秒です。詳細については、「[HTTP ステータスコード別のカスタムエラーページを作成する](creating-custom-error-pages.md)」を参照してください。

地理的制限はディストリビューション全体に適用されます。コンテンツのある部分に特定の制限を適用し、コンテンツの別の部分に別の制限を適用する (または制限を適用しない) 必要がある場合は、別々の CloudFront ディストリビューションを作成するか、[サードパーティの位置情報サービスを使用する](#georestrictions-geolocation-service)必要があります。

CloudFront の[標準ログ](AccessLogs.md) (アクセスログ) を有効にすると、`sc-status` (HTTP ステータスコード) の値が `403` であるログエントリを検索することによって、CloudFront で拒否されたリクエストを特定できます。ただし、標準ログだけでは、ユーザーのいる場所に基づいて CloudFront が拒否したリクエストと、別の理由でファイルへのアクセス許可がユーザーになかったために CloudFront が拒否したリクエストとを区別することができません。Digital Element や MaxMind などサードパーティーの位置情報サービスを利用している場合は、アクセスログの `c-ip` (クライアント IP) 列にある IP アドレスに基づいてリクエストの場所を識別できます。CloudFront の標準ログの詳細については、[アクセスログ (標準ログ)](AccessLogs.md) を参照してください。

次の手順では、CloudFront コンソールを使用して、地理的制限を既存のディストリビューションに追加する方法を示します。コンソールを使用してディストリビューションを作成する方法の詳細については、「[ディストリビューションを作成する](distribution-web-creating-console.md)」を参照してください。<a name="restrictions-geo-procedure"></a>

**CloudFront ウェブディストリビューションに地理的制限を追加するには (コンソール)**

1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. ナビゲーションペインで、**[ディストリビューション]** を選択し、更新するディストリビューションを選択します。

1. **[セキュリティ]** タブを選択し、**[地理的制限]** を選択します。

1. **[編集]** を選択します。

1. 許可した国のリストを作成する場合は、**許可リスト**、またはブロックした国のリストを作成する場合は、**ブロックリスト**を作成します。

1. 目的の国をリストに追加し、**[Save changes]** (変更の保存) を選択します。

## サードパーティの位置情報サービスを使用する
<a name="georestrictions-geolocation-service"></a>

CloudFront の地理的制限機能を使用すると、特定のウェブディストリビューションで配信するすべてのファイルについて、国レベルでコンテンツの配信を制御できます。地理的制限が国境と一致していない場合や、特定のディストリビューションで配信するファイルの一部にのみアクセスを制限する必要がある場合は、CloudFront とサードパーティーの位置情報サービスを組み合わせることができます。これにより、国だけではなく、都市、郵便番号、または緯度/経度に基づいてコンテンツの制御を提供します。

サードパーティーの位置情報サービスを使用する場合は、有効期限の日時を指定できる CloudFront 署名付き URL を使用することをお勧めします。有効期限を経過すると、この URL は無効になります。さらに、オリジンとして Amazon S3 バケットを使用することをお勧めします。CloudFront [オリジンアクセスコントロール](private-content-restricting-access-to-s3.md)を使用することで、オリジンのコンテンツへのユーザーによる直接アクセスを回避できるためです。署名付き URL とオリジンアクセスコントロールの詳細については、「[署名付き URL と署名付き Cookie を使用したプライベートコンテンツを提供する](PrivateContent.md)」を参照してください。

以下のステップは、サードパーティーの位置情報サービスを使用してファイルへのアクセスを制御する方法を説明しています。

**サードパーティーの位置情報サービスを使用して CloudFront ディストリビューション内のファイルへのアクセスを制限するには**

1. 位置情報サービスのアカウントを取得します。

1. コンテンツを Amazon S3 バケットにアップロードします。

1. プライベートコンテンツを供給できるように Amazon CloudFront と Amazon S3 を設定します。詳細については、「[署名付き URL と署名付き Cookie を使用したプライベートコンテンツを提供する](PrivateContent.md)」を参照してください。

1. 以下の処理を行うようにウェブアプリケーションを記述します。
   + 各ユーザーリクエストの IP アドレスを位置情報サービスに送信します。
   + 位置情報サービスからの戻り値を評価し、ユーザーの場所が CloudFront によるコンテンツの配信先に該当するかどうかを判別します。
   + コンテンツをユーザーの場所に配信する場合、CloudFront コンテンツの署名付き URL を生成します。コンテンツをその場所に配信しない場合、HTTP ステータスコード `403 (Forbidden)` をユーザーに返します。または、カスタムエラーメッセージが返されるように CloudFront を設定することもできます。詳細については、「[HTTP ステータスコード別のカスタムエラーページを作成する](creating-custom-error-pages.md)」を参照してください。

   詳細については、使用する位置情報サービスのドキュメントを参照してください。

ウェブサーバー変数を使用すると、ウェブサイトを訪れたユーザーの IP アドレスを取得できます。次の点に注意してください。
+ ウェブサーバーがインターネットにロードバランサー経由で接続されていない場合、ウェブサーバー変数を使用してリモート IP アドレスを取得できます。ただし、この IP アドレスが必ずしもユーザーの IP アドレスであるとは限りません。ユーザーのインターネットへの接続方法によっては、プロキシサーバーの IP アドレスである可能性もあります。
+ ウェブサーバーがインターネットにロードバランサー経由で接続されている場合、ウェブサーバー変数には、ユーザーの IP アドレスではなく、ロードバランサーの IP アドレスが含まれる可能性があります。この構成では、`X-Forwarded-For` HTTP ヘッダーに含まれる最後の IP アドレスを使用することをお勧めします。通常、このヘッダーには複数の IP アドレスが含まれており、そのほとんどはプロキシまたはロードバランサーの IP アドレスです。ユーザーの地理的な場所に関連付けられている可能性が最も高い IP アドレスは、リストの最後にある IP アドレスです。

ウェブサーバーがロードバランサーに接続されていない場合は、IP アドレスのスプーフィングを回避するために、`X-Forwarded-For` ヘッダーではなくウェブサーバー変数を使用することをお勧めします。

# フィールドレベル暗号化を使用した機密データの保護
<a name="field-level-encryption"></a>

Amazon CloudFront では、HTTPS を使用して、オリジンサーバーへの安全なエンドツーエンド接続を強制できます。フィールドレベル暗号化では、セキュリティのレイヤーが追加されます。これにより、システムの処理中に特定のデータに特定のアプリケーションのみがアクセスできるように、そのデータを保護できます。

フィールドレベル暗号化により、ユーザーが機密情報をウェブサーバーに安全にアップロードできるようになります。ユーザーから提供される機密情報は、ユーザー近くのエッジで暗号化され、アプリケーションスタック全体で暗号化された状態が維持されます。この暗号化により、データを必要としており、復号するための認証情報を持つアプリケーションだけが暗号化できるようになります。

フィールドレベル暗号化を使用するには、CloudFront ディストリビューションの設定で、暗号化する POST リクエストの一連のフィールドと、それらの暗号化に使用するパブリックキーを指定します。リクエストの最大 10 個のデータフィールドを暗号化できます (フィールドレベル暗号化を使用して、リクエストのすべてのデータをまとめて暗号化することはできません。暗号化する個々のフィールドを指定する必要があります)。

フィールドレベル暗号化を含む HTTPS リクエストがオリジンに転送され、リクエストがオリジンアプリケーションまたはサブシステム全体にルーティングされても、機密データは暗号化されたままです。それにより、機密データの漏洩や偶発的な損失のリスクが軽減されます。クレジット番号へのアクセスを必要とする支払い処理システムなど、ビジネス上の理由で機密データにアクセスする必要のあるコンポーネントは、適切なプライベートキーを使用してデータを復号化し、そのデータにアクセスできます。

**注記**  
フィールドレベル暗号化を使用するには、オリジンがチャンクエンコードをサポートしている必要があります。

![\[CloudFront のフィールドレベル暗号化\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/images/fleoverview.png)


CloudFront のフィールドレベル暗号化では、非対称暗号化 (パブリックキー暗号化とも呼ばれる) が使用されます。CloudFront にパブリックキーを渡すと、指定したすべての機密データが自動的に暗号化されます。CloudFront に渡したキーは、暗号化された値の復号化には使用できません。この目的で使用できるのはプライベートキーのみです。

![\[機密データのみの暗号化\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/images/encryptedfields.png)


**Topics**
+ [フィールドレベル暗号化の概要](#field-level-encryption-overview)
+ [フィールドレベル暗号化を設定する](#field-level-encryption-setting-up)
+ [オリジンでデータフィールドを復号する](#field-level-encryption-decrypt)

## フィールドレベル暗号化の概要
<a name="field-level-encryption-overview"></a>

以下に示しているのは、フィールドレベル暗号化の設定手順の概要です。この手順の詳細については、「[フィールドレベル暗号化を設定する](#field-level-encryption-setting-up)」を参照してください。

1. **パブリックキーとプライベートキーのペアを取得する。**CloudFront でフィールドレベル暗号化を設定する前に、パブリックキーを取得して追加する必要があります。

1. **フィールドレベル暗号化のプロファイルを作成する。**CloudFront で作成するフィールドレベル暗号化のプロファイルで、暗号化するフィールドを定義します。

1. **フィールドレベル暗号化の設定を作成する。**設定では、特定のデータフィールドの暗号化に使用するプロファイル (リクエストのコンテンツタイプまたはクエリ引数に基づく) を指定します。また、さまざまなシナリオで必要なリクエスト転送動作オプションを選択することもできます。例えば、リクエスト URL のクエリ引数で指定されたプロファイル名が CloudFront に存在しない場合の動作を設定できます。

1. **キャッシュ動作にリンクする。**設定をディストリビューションのキャッシュ動作にリンクして、いつ CloudFront がデータを暗号化するかを指定します。

## フィールドレベル暗号化を設定する
<a name="field-level-encryption-setting-up"></a>

フィールドレベル暗号化を使用するには、以下の手順に従います。フィールドレベル暗号化のクォータ (以前は制限と呼ばれていました) の詳細については、「[クォータ](cloudfront-limits.md)」を参照してください。
+ [ステップ 1: RSA キーペアを作成する](#field-level-encryption-setting-up-step1)
+ [ステップ 2: パブリックキーを CloudFront に追加する](#field-level-encryption-setting-up-step2)
+ [ステップ 3: フィールドレベル暗号化のプロファイルを作成する](#field-level-encryption-setting-up-step3)
+ [ステップ 4: 設定を作成する](#field-level-encryption-setting-up-step4)
+ [ステップ 5: キャッシュ動作に設定を追加する](#field-level-encryption-setting-up-step5)

### ステップ 1: RSA キーペアを作成する
<a name="field-level-encryption-setting-up-step1"></a>

開始するには、パブリックキーとプライベートキーを含む RSA キーペアを作成する必要があります。パブリックキーにより CloudFront がデータを暗号化できるようになり、プライベートキーによりオリジンのコンポーネントが暗号化されたフィールドを復号できるようになります。OpenSSL または別のツールを使用してキーペアを作成できます。キーのサイズは 2,048 ビットであることが必要です。

たとえば、OpenSSL を使用する場合、次のコマンドを使用して 2048 ビット長のキーペアを生成し、`private_key.pem` ファイルに保存できます。

```
openssl genrsa -out private_key.pem 2048
```

生成されるファイルには、パブリックキーとプライベートキーの両方が含まれます。そのファイルからパブリックキーを抽出するには、次のコマンドを実行します。

```
openssl rsa -pubout -in private_key.pem -out public_key.pem
```

公開キーファイル (`public_key.pem`) には、次のステップで貼り付けるエンコードされたキー値が含まれています。

### ステップ 2: パブリックキーを CloudFront に追加する
<a name="field-level-encryption-setting-up-step2"></a>

RSA キーペアを取得したら、パブリックキーを CloudFront に追加します。<a name="field-level-encryption-setting-up-step2-procedure"></a>

**パブリックキーを CloudFront に追加するには (コンソール)**

1. AWS マネジメントコンソール にサインインし、[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home) で CloudFront コンソールを開きます。

1. ナビゲーションペインで、[**Public key (パブリックキー)**] を選択します。

1. [**Add public key (パブリックキーを追加)**] を選択します。

1. [**Key name (キー名)**] にキーの一意の名前を入力します。キー名にはスペースを使用できません。英数字、アンダースコア (\$1)、ハイフン (-) のみを使用できます。最大長は 128 文字です。

1. [**Key value (キー値)**] に、`-----BEGIN PUBLIC KEY-----` および `-----END PUBLIC KEY-----` 行を含む、パブリックキーのエンコードされたキー値を貼り付けます。

1. [**Comment (コメント)**] で、オプションのコメントを追加します。たとえば、パブリックキーの有効期限を含めることができます。

1. [**Add**] を選択します。

CloudFront で使用するキーを追加するには、このステップの手順を繰り返します。

### ステップ 3: フィールドレベル暗号化のプロファイルを作成する
<a name="field-level-encryption-setting-up-step3"></a>

1 つ以上のパブリックキーを CloudFront に追加した後、CloudFront にどのフィールドを暗号化するかを指示するプロファイルを作成します。<a name="field-level-encryption-setting-up-step3-procedure"></a>

**フィールドレベル暗号化のプロファイルを作成するには (コンソール)**

1. ナビゲーションペインで、[**Field-level encryption (フィールドレベル暗号化)**] を選択します。

1. [**Create profile (プロファイルの作成)**] を選択します。

1. 以下のフィールドに入力します。  
**Profile name**  
プロファイルの一意の名前を入力します。キー名にはスペースを使用できません。英数字、アンダースコア (\$1)、ハイフン (-) のみを使用できます。最大長は 128 文字です。  
**Public key name**  
ドロップダウンリストから、ステップ 2 で CloudFront に追加したパブリックキーの名前を選択します。CloudFront では、このプロファイルで指定したフィールドの暗号化に、このキーが使用されます。  
**Provider name**  
キーを識別するのに役立つフレーズ (キーペアを取得したプロバイダーなど) を入力します。この情報は、プライベートキーと共に、アプリケーションがデータフィールドを復号化するときに必要になります。プロバイダー名にはスペースを使用できません。英数字、コロン (:)、アンダースコア (\$1)、ハイフン (-) のみを使用できます。最大長は 128 文字です。  
**Field name pattern to match**  
CloudFront で暗号化するデータフィールドの名前、またはリクエスト内のデータフィールド名を識別するパターンを入力します。\$1 オプションを選択して、このキーで暗号化するすべてのフィールドを追加します。  
フィールド名パターンには、データフィールドの名前全体を入力するか (DateOfBirth など)、ワイルドカード文字 (\$1) を使用して名前の最初の部分のみを入力します (CreditCard\$1 など)。フィールド名パターンには、オプションのワイルドカード文字 (\$1) に加えて、英数字、角かっこ ([ および ])、ピリオド (.)、アンダースコア (\$1)、ハイフン (-) のみを含める必要があります。  
異なるフィールド名パターンに重複する文字を使用しないでください。たとえば、ABC \$1 というフィールド名パターンがある場合、AB \$1 という別のフィールド名パターンを追加することはできません。また、フィールド名は大文字と小文字が区別され、最大長は 128 文字です。  
**コメント**  
(オプション) このプロファイルに関するコメントを入力します。最大長は 128 文字です。

1. フィールドに入力した後、[**Create profile (プロファイルの作成)**] を選択します。

1. さらにプロファイルを追加する場合は、[**Add profile (プロファイルの追加)**] を選択します。

### ステップ 4: 設定を作成する
<a name="field-level-encryption-setting-up-step4"></a>

1 つ以上のフィールドレベル暗号化のプロファイルを作成した後、リクエストのコンテンツタイプを指定する設定を作成します。この設定には、暗号化するデータ、暗号化に使用するプロファイル、および CloudFront による暗号化の処理方法を指定するその他のオプションが含まれます。

たとえば、CloudFront がデータを暗号化できないときに、CloudFront が以下のシナリオでリクエストをブロックするかオリジンに転送するかを指定できます。
+ **リクエストのコンテンツタイプが設定にない場合** – コンテンツタイプが設定に追加されていない場合に、CloudFront がそのコンテンツタイプのリクエストをデータフィールドの暗号化なしでオリジンに転送するか、ブロックしてエラーを返すかを指定できます。
**注記**  
コンテンツタイプを設定に追加していても、そのタイプで使用するプロファイルを指定していない場合、そのコンテンツタイプのリクエストは、CloudFront により常にオリジンに転送されます。
+ **クエリ引数で指定したプロファイル名が不明な場合** – `fle-profile` クエリ引数で、ディストリビューションに存在しないプロファイル名が指定されている場合に、CloudFront がリクエストをデータフィールドの暗号化なしでオリジンに送るか、リクエストをブロックしてエラーを返すかを指定できます。

設定で、URL でクエリ引数としてプロファイルを提供するかどうかを指定して、そのクエリのコンテンツタイプにマッピングしたプロファイルを上書きすることもできます。デフォルトでは、CloudFront では、コンテンツタイプにマッピングしたプロファイル (指定してある場合) が使用されます。これにより、デフォルトで使用されるプロファイルを提供できますが、特定のリクエストに使用される別のプロファイルを指定することもできます。

たとえば、使用するクエリ引数プロファイルとして (設定で) **SampleProfile** を指定できます。さらに、`https://d1234.cloudfront.net?fle-profile=SampleProfile` の代わりに URL `https://d1234.cloudfront.net` を使用できます。これにより、CloudFront がこのリクエストに、リクエストのコンテンツタイプ用に設定したプロファイルではなく **SampleProfile** を使用できるようになります。

1 つのアカウント用に最大 10 個の設定を作成し、いずれかの設定をそのアカウントの任意のディストリビューションのキャッシュ動作に関連付けることができます。<a name="field-level-encryption-setting-up-step4-procedure"></a>

**フィールドレベル暗号化の設定を作成するには (コンソール)**

1. [**Field-level encryption (フィールドレベル暗号化)**] ページで、[**Create configuration (設定の作成)**] を選択します。

   注意: プロファイルを 1 つ以上作成していない場合、設定を作成するオプションは表示されません。

1. 以下のフィールドに入力して、使用するプロファイルを指定します (一部のフィールドは変更できません)。  
**Content type (変更不可)**  
コンテンツタイプは `application/x-www-form-urlencoded` に設定されており、変更することはできません。  
**Default profile ID (オプション)**  
ドロップダウンリストから、[**Content type (コンテンツタイプ)**] フィールドでコンテンツタイプにマッピングするプロファイルを選択します。  
**Content format (変更不可)**  
コンテンツ形式は `URLencoded` に設定されており、変更することはできません。

1. 以下のオプションに対する CloudFront のデフォルト動作を変更する場合は、該当するチェックボックスをオンにします。  
**Forward request to origin when request's content type is not configured**  
*リクエストのコンテンツタイプに使用するプロファイルを指定していないときに*、リクエストをオリジンに転送させる場合は、このチェックボックスをオンにします。  
**Override the profile for a content type with a provided query argument**  
クエリ引数で指定したプロファイルによって、*コンテンツタイプ用に指定したプロファイルを上書する*場合は、このチェックボックスをオンにします。

1. このチェックボックスをオンにして、クエリ引数によってデフォルトプロファイルが上書きされるようにした場合は、設定で以下の追加フィールドを入力する必要があります。クエリで使用するこれらのクエリ引数マッピングは最大 5 つ作成できます。  
**Query argument**  
`fle-profile` クエリ引数の URL に含める値を入力します。CloudFront は、このクエリ引数の値に関連付けられたプロファイル ID (次のフィールドで指定) をこのクエリのフィールドレベル暗号化に使用します。  
最大長は 128 文字です。値にはスペースを含めることはできません。英数字、ダッシュ (-)、ピリオド (.)、アンダースコア (\$1)、アスタリスク (\$1)、プラス記号 (\$1)、パーセント (%) のみを使用する必要があります。  
**Profile ID**  
ドロップダウンリストから、[**Query argument (クエリ引数)**] に入力した値に関連付けるプロファイルを選択します。  
**Forward request to origin when the profile specified in a query argument does not exist**  
*クエリ引数で指定したプロファイルが CloudFront で定義されていないとき*に、リクエストがオリジンに転送されるようにするには、このチェックボックスをオンにします。

### ステップ 5: キャッシュ動作に設定を追加する
<a name="field-level-encryption-setting-up-step5"></a>

フィールドレベル暗号化を使用するには、設定 ID をディストリビューション用の値として追加して、ディストリビューションのキャッシュ動作に設定をリンクします。

**重要**  
フィールドレベルの暗号化設定をキャッシュ動作にリンクするには、常に HTTPS を使用し、ビューワーからの HTTP `POST` および `PUT` リクエストを受け入れるようにディストリビューションを設定する必要があります。つまり、以下が満たされている必要があります。  
キャッシュ動作の [**ビューワープロトコルポリシーは**] が [**HTTP を HTTPS にリダイレクト**] または [**HTTPS のみ**] に設定されている必要があります。(CloudFormation または CloudFront API では、`redirect-to-https` が `ViewerProtocolPolicy` または `https-only` に設定されている必要があります)。
キャッシュ動作の [**Allowed HTTP Methods**] (許可された HTTP メソッド) が、[**GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE**] に設定されている必要があります。(CloudFormation または CloudFront API では、`AllowedMethods` が `GET`、`HEAD`、`OPTIONS`、`PUT`、`POST`、`PATCH`、`DELETE` に設定されている必要があります。これらは任意の順序で指定できます)。
オリジン設定の [**オリジンプロトコルポリシー**] が [**ビューワーに合わせる**] または [**HTTPS のみ**] に設定されている必要があります。(CloudFormation または CloudFront API では、`match-viewer` が `OriginProtocolPolicy` または `https-only` に設定されている必要があります)。

詳細については、「[すべてのディストリビューション設定リファレンス](distribution-web-values-specify.md)」を参照してください。

## オリジンでデータフィールドを復号する
<a name="field-level-encryption-decrypt"></a>

CloudFront は [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) を使用してデータフィールドを暗号化します。データはアプリケーションスタック全体で暗号化されたままであり、復号化するための認証情報のあるアプリケーションによってのみアクセスできます。

暗号化の後、暗号テキストは base64 でエンコードされます。アプリケーションがオリジンでテキストを復号化するときは、まず暗号テキストをデコードしてから、AWS Encryption SDK を使用してデータを復号化する必要があります。

以下のサンプルコードでは、アプリケーションがオリジンでデータを復号化する方法を示しています。次の点に注意してください。
+ わかりやすい例になるように、このサンプルは作業ディレクトリのファイルからパブリックキーとプライベートキー (DER 形式) を読み込みます。実際には、オフラインのハードウェアセキュリティモジュールなどの安全なオフラインの場所にプライベートキーを保存し、開発チームにパブリックキーを配布します。
+ CloudFront はデータの暗号化時に特定の情報を使用します。データの復号化には、オリジンで同じ一連のパラメータを使用する必要があります。以下に示しているのは、MasterKey の初期化時に CloudFront が使用するパラメータです。
  + PROVIDER\$1NAME: フィールドレベル暗号化のプロファイルを作成したときにこの値を指定しました。同じ値をここで使用します。
  + KEY\$1NAME: パブリックキーを CloudFront にアップロードしたときに作成し、プロファイルで指定したキー名です。同じ値をここで使用します。
  + ALGORITHM: CloudFront では暗号化アルゴリズムとして `RSA/ECB/OAEPWithSHA-256AndMGF1Padding` が使用されるため、データの復号化には同じアルゴリズムを使用する必要があります。
+ 暗号テキストを入力として以下のサンプルプログラムを実行すると、復号化されたデータがコンソールに出力されます。詳細については、[ Encryption SDK の「](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/java-example-code.html)Java サンプルコードAWS」を参照してください。

### サンプルコード
<a name="field-level-encryption-decrypt-sample"></a>

```
import java.nio.file.Files;
import java.nio.file.Paths;
import java.security.KeyFactory;
import java.security.PrivateKey;
import java.security.PublicKey;
import java.security.spec.PKCS8EncodedKeySpec;
import java.security.spec.X509EncodedKeySpec;

import org.apache.commons.codec.binary.Base64;

import com.amazonaws.encryptionsdk.AwsCrypto;
import com.amazonaws.encryptionsdk.CryptoResult;
import com.amazonaws.encryptionsdk.jce.JceMasterKey;

/**
 * Sample example of decrypting data that has been encrypted by CloudFront field-level encryption.
 */
public class DecryptExample {

    private static final String PRIVATE_KEY_FILENAME = "private_key.der";
    private static final String PUBLIC_KEY_FILENAME = "public_key.der";
    private static PublicKey publicKey;
    private static PrivateKey privateKey;

    // CloudFront uses the following values to encrypt data, and your origin must use same values to decrypt it.
    // In your own code, for PROVIDER_NAME, use the provider name that you specified when you created your field-level
    // encryption profile. This sample uses 'DEMO' for the value.
    private static final String PROVIDER_NAME = "DEMO";
    // In your own code, use the key name that you specified when you added your public key to CloudFront. This sample
    // uses 'DEMOKEY' for the key name.
    private static final String KEY_NAME = "DEMOKEY";
    // CloudFront uses this algorithm when encrypting data.
    private static final String ALGORITHM = "RSA/ECB/OAEPWithSHA-256AndMGF1Padding";

    public static void main(final String[] args) throws Exception {

        final String dataToDecrypt = args[0];

        // This sample uses files to get public and private keys.
        // In practice, you should distribute the public key and save the private key in secure storage.
        populateKeyPair();

        System.out.println(decrypt(debase64(dataToDecrypt)));
    }

    private static String decrypt(final byte[] bytesToDecrypt) throws Exception {
        // You can decrypt the stream only by using the private key.

        // 1. Instantiate the SDK
        final AwsCrypto crypto = new AwsCrypto();

        // 2. Instantiate a JCE master key
        final JceMasterKey masterKey = JceMasterKey.getInstance(
                publicKey,
                privateKey,
                PROVIDER_NAME,
                KEY_NAME,
                ALGORITHM);

        // 3. Decrypt the data
        final CryptoResult <byte[], ? > result = crypto.decryptData(masterKey, bytesToDecrypt);
        return new String(result.getResult());
    }

    // Function to decode base64 cipher text.
    private static byte[] debase64(final String value) {
        return Base64.decodeBase64(value.getBytes());
    }

    private static void populateKeyPair() throws Exception {
        final byte[] PublicKeyBytes = Files.readAllBytes(Paths.get(PUBLIC_KEY_FILENAME));
        final byte[] privateKeyBytes = Files.readAllBytes(Paths.get(PRIVATE_KEY_FILENAME));
        publicKey = KeyFactory.getInstance("RSA").generatePublic(new X509EncodedKeySpec(PublicKeyBytes));
        privateKey = KeyFactory.getInstance("RSA").generatePrivate(new PKCS8EncodedKeySpec(privateKeyBytes));
    }
}
```