Amazon CloudFront
開発者ガイド (API バージョン 2016-09-29)

CloudFront とカスタムオリジンとの間の通信に HTTPS を必須にする

CloudFront とカスタムオリジン間の通信に HTTPS を必須にする場合、CloudFront がディストリビューションに割り当てたドメイン名 (d111111abcdef8.cloudfront.net など) を使用しているか、独自の代替ドメイン名 (example.com など) を使用しているかによって、実行するステップは異なります。

注記

Amazon S3 バケットをオリジンとして使用し、バケットをウェブサイトエンドポイントとして設定する場合、このセクションのガイダンスに従ってください。それ以外の場合は、HTTPS で Amazon S3 バケットを使用するために、「CloudFront と Amazon S3 オリジンとの間の通信で HTTPS を必須にする」を参照してください。

デフォルトの CloudFront ドメイン名を使用する

CloudFront によってオブジェクトの URL でディストリビューションに割り当てられたドメイン名 (https://d111111abcdef8.cloudfront.net/logo.jpg など) を使用している場合、このトピックの手順に従って HTTPS を必須にすることができます。

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

  • カスタムオリジンサーバーに SSL/TLS 証明書をインストールします (Amazon S3 オリジンを使用する場合は必要ありません)。

代替ドメイン名を使用する

ディストリビューションでデフォルトのドメイン名を使用する代わりに、example.com のような扱いやすい代替ドメイン名を追加できます。

代替ドメイン名を使用するときに通信に HTTPS を必須にするには、「代替ドメイン名と HTTPS の使用」の手順とガイダンスに従ってください。

CloudFront 設定を変更する

次の手順では、Elastic Load Balancing ロードバランサー、Amazon EC2 インスタンス、または他のカスタムオリジンとの通信で HTTPS を使用するために CloudFront を設定する方法について説明します。CloudFront API を使用してウェブディストリビューションを更新する方法については、Amazon CloudFront API リファレンス の「UpdateDistribution」を参照してください。

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

  1. AWS マネジメントコンソール にサインインし、https://console.aws.amazon.com/cloudfront/ にある、CloudFront コンソールを開きます。

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

  3. [Origins] タブで、更新するオリジンを選択し、[Edit] を選択します。

  4. 次の設定を更新します。

    オリジンプロトコルポリシー

    ディストリビューションの該当するオリジンで、[Origin Protocol Policy] を変更します。

    • [HTTPS Only] – CloudFront は HTTPS のみを使ってカスタムオリジンと通信します。

    • [Match Viewer] – CloudFront は、ビューワーのリクエストのプロトコルに応じて HTTP または HTTPS を使用し、カスタムオリジンと通信します。たとえば、[Origin Protocol Policy] の [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と TLSv1.2にはありません。この場合、openssl は SSLv3ハンドシェイクのみを送信します。

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

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

  7. 本番環境で更新された情報を使用する前に、次を確認してください。

    • ビューワーに HTTPS の使用が必要とされるリクエストにのみ、各キャッシュ動作のパスパターンが適用されている。

    • CloudFront が評価する順番にキャッシュ動作がリストされている。詳細については、「パスパターン」を参照してください。

    • キャッシュ動作は、[Origin Protocol Policy] を変更したオリジンにリクエストをルーティングします。

カスタムオリジンサーバーに SSL/TLS 証明書をインストールする

SSL/TLS 証明書は、カスタムオリジンの次のソースから使用できます。

  • オリジンが Elastic Load Balancing ロードバランサーの場合、AWS Certificate Manager (ACM) が提供する証明書を使用できます。信頼されたサードパーティー認証機関が署名して ACM にインポートされた証明書を使用することもできます。

  • ELB ロードバランサー以外のオリジンの場合、信頼されたサードパーティー認証機関 (CA) (Comodo、DigiCert、Symantec など) によって署名された証明書を使用する必要があります。

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

重要

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

オリジンから返された証明書は、ディストリビューションの対応するオリジンに対して [オリジンドメイン名] に指定したドメインを対象としている必要があります。さらに、Host ヘッダーをオリジンに転送するように CloudFront を設定した場合、オリジンは Host ヘッダーのドメインに一致する証明書で応答する必要があります。

RSA および ECDSA 暗号について

通信接続の暗号化強度は、オリジンサーバーの証明書で選択するキーのサイズとアルゴリズムの強度に依存します。カスタムオリジンの接続に CloudFront がサポートする 2 つのオプションは、RSA と楕円曲線 DSA (ECDSA) です。

CloudFront でサポートされている RSA および ECDSA 暗号のリストは、「CloudFront とオリジン間の通信用にサポートされる SSL/TLS プロトコール」を参照してください。

RSA 暗号のしくみ

CloudFront およびオリジンサーバーは通常、SSL/TLS の終了に RSA 2048 ビット対称キーを使用します。RSA アルゴリズムは、桁数が大きい 2 つの素数の積にパブリックキーを作成するために別の数字が追加されたものを使用します。プライベートキーは関連する数字です。RSA の強度は、キーの解読には桁数が大きい 2 つの素数の積を因数分解することを必要とすることを仮定とした困難度に依存しています。ただし、より高速なコンピューター計算により暗号の解読がより簡単になったことで、コンピューターテクノロジーの向上が RSA アルゴリズムの効果の低下につながっています。

引き続き RSA を使用しながら暗号化の強度を維持するには、RSA キーのサイズを増加することが 1 つのオプションです。ただし、より桁数が大きいキーを使用することは暗号化におけるコンピューティングのコストを増加するため、この方法は簡単なスケーラブルではありません。

ECDSA 暗号のしくみ

代わりに、ECDSA 証明書を使用することもできます。ECDSA は、RSA よりも比較的複雑で解決がより困難な数理問題に基づいた安全性を提供しています。これは、ECDSA 暗号を解読するには、より多くのコンピューティング処理時間を要することを意味しています。ECDSA は、楕円曲線離散対数問題 (ECDLP) とも呼ばれる既知の計算式である、ランダムな楕円曲線の離散対数の計算求めることは困難であるという根拠に基づいて構築されています。つまり、これは、より大きなキーサイズの RSA の使用と同等のセキュリティにより短いキーの長さを使用できることを意味しています。

より優れたセキュリティの提供に加えて、ECDSA のより小さなキーの使用はアルゴリズムの高速なコンピューティング、より小規模のデジタル証明書、SSL/TLS ハンドシェイク時に送信するビット数の減少を可能にします。その結果、小規模なキーは、オリジンサーバーの SSL/TLS を終了するデジタル証明書の作成と署名にかかる時間を削減します。したがって、より小規模なキーサイズを使用することは、暗号化に必要なコンピューターサイクルを減少することでスループットを向上し、他の作業の処理にサーバーのリソースを解放することができます。

RSA あるいは ECDSA 暗号の選択

2048 ビット RSA に対する 256 ビット ECDSA (nistp256) などで比較のために当社が実行したサンプルテストでは、nistp256 オプションは 2048 ビット RSA よりも 95% 高速であり、3072 ビット RSA と同じセキュリティ強度を提供することが示されました。

CloudFront は引き続き SSL/TLS 接続に RSA をサポートしています。ただしオリジンサーバーの SSL/TLS 認証の現行の暗号化における強度について懸念がある場合には、ECDSA はより良いオプションです。ECDSA のデジタル証明書を有効化する労力と ECDSA がもたらすセキュリティの利点を比較することは、決定するために検討すべき要点です。より強度な暗号化が可能になることに加えて、オリジンサーバーで ECDSA を使用するときの暗号化の計算処理コストの減少もさらなる利点です。

ECDSA 暗号の使用

CloudFront とオリジン間の通信で ECDSA を使用するには、次を実行します。

  1. サポートされているいずれかの曲線 (prime256v1 あるいは secp384r1) を使用して、プライベートキーを生成します。

  2. 信頼される認証機関で、X.509 PEM 形式の ECDSA デジタル証明書を生成します。

  3. ECDSA 証明書を選択するようにオリジンを設定します。

ECDSA の使用は CloudFront コンソールあるいは API の設定変更を必要とせず、また追加料金は発生しません。