トランスポート層セキュリティ (TLS) (以前の Secure Sockets Layer (SSL)) は、Web サーバーとクライアント間 (Web ブラウザーなど) に暗号化されたリンクを確立するための標準的なセキュリティ テクノロジです。 このリンクにより、サーバーとクライアント間で渡されるすべてのデータがプライベートで暗号化されたままになります。
セキュリティまたはコンプライアンスの要件を満たすために、Azure Front Door ではエンド ツー エンド TLS 暗号化がサポートされています。 Front Door の TLS/SSL オフロードでは、TLS 接続を終了し、Azure Front Door でトラフィックを復号化し、トラフィックを再暗号化してから配信元に転送します。 配信元への接続で配信元のパブリック IP アドレスを使用する場合は、Azure Front Door の転送プロトコルとして HTTPS を構成することをお勧めします。 転送プロトコルとして HTTPS を使用すると、クライアントから配信元への要求の処理全体に対してエンド ツー エンドの TLS 暗号化を適用できます。 Private Link 機能を使用する Azure Front Door Premium を備えたプライベートの配信元をデプロイする場合は、TLS/SSL オフロードもサポートされます。
この記事では、Azure Front Door と TLS 接続の連携方法について説明します。 独自のカスタム ドメインで TLS 証明書を使用する方法の詳細については、「カスタム ドメインの HTTPS」を参照してください。 独自のカスタム ドメインで TLS 証明書を構成する方法については、「Azure portal を使用して Azure Front Door でカスタム ドメインを構成する」を参照してください。
エンド ツー エンド TLS 暗号化
エンド ツー エンド TLS を使用すると、配信元への転送中に機密データをセキュリティで保護しながら、グローバル負荷分散やキャッシュなどの Azure Front Door の機能を利用できます。 また、URL ベースのルーティング、TCP 分割、クライアントに最も近いエッジ ロケーションでのキャッシュ、エッジでの HTTP 要求のカスタマイズなどの機能もあります。
Azure Front Door では、エッジで TLS セッションをオフロードし、クライアント要求を復号化します。 次に、構成済みのルーティング規則を適用して、配信元グループ内の適切な配信元に要求をルーティングします。 その後、配信元への新しい TLS 接続が開始され、配信元に要求を送信する前に、配信元の証明書を使用してすべてのデータが再暗号化されます。 配信元からの応答は、同じプロセスで暗号化されてエンド ユーザーに返されます。 エンド ツー エンド TLS を有効にするには、転送プロトコルとして HTTPS を使用するように Azure Front Door を構成します。
サポートされている TLS バージョン
Azure Front Door では、TLS バージョン 1.2 と 1.3 の 2 つのバージョンの TLS プロトコルがサポートされています。 2019 年 9 月以降に作成されたすべての Azure Front Door プロファイルでは、TLS 1.3 が有効になっている既定の最小値として TLS 1.2 が使用されます。 現在、Azure Front Door では、クライアント/相互認証 (mTLS) はサポートされていません。
重要
2025 年 3 月 1 日以降、新しい Azure Front Door プロファイルでは TLS 1.0 と 1.1 は使用できません。
Azure Front Door Standard と Premium では、定義済みの TLS ポリシーを構成するか、組織のセキュリティニーズに基づいて TLS 暗号スイートを選択できます。 詳細については、「 Azure Front Door TLS ポリシー 」を参照し、 Front oor カスタム ドメインで TLS ポリシーを構成します。
Azure Front Door クラシックと Microsoft CDN クラシックの場合、Azure Portal または Azure REST API を使用して、カスタム ドメインの HTTPS 設定で Azure Front Door の最小 TLS バージョンを構成できます。 TLS バージョン 1.2 以降では、ネゴシエーションは TLS 1.3 と TLS 1.2 の確立を試みます。 Azure Front Door では、配信元への TLS トラフィックを開始すると、配信元が確実かつ一貫して受け入れることができる最適な TLS バージョンのネゴシエーションを試行します。 配信元接続でサポートされている TLS バージョンは、TLS 1.2 と TLS 1.3 です。 必要に応じて暗号スイートをカスタマイズする場合 は、Front Door クラシック と Microsoft CDN クラシック を Azure Front Door Standard および Premium に移行します。
注
- TLS 1.3 を有効にしたクライアントでは、TLS 1.3 を使用して Azure Front Door で要求を正常に行うために、Secp384r1、Secp256r1、Secp521 など、Microsoft SDL 準拠の EC 曲線のいずれかをサポートする必要があります。
- TLS ハンドシェイクの待機時間が長くなるのを避けるため、クライアントは要求時にこれらの曲線のいずれかを優先的に使用することをお勧めします。これは、サポートされている EC 曲線をネゴシエートするのに複数のラウンドトリップが必要となる可能性があるためです。
サポートされている証明書
TLS/SSL 証明書を作成する場合は、Microsoft の信頼された CA リストの一部である許可された証明機関 (CA) を使用した完全な証明書チェーンを作成する必要があります。 許可されていない CA を使用すると、要求が拒否されます。
内部 CA からの証明書または自己署名証明書は許可されません。
オンライン証明書ステータス プロトコル (OCSP) ステープリング
Azure Front Door では OCSP ステープリングが既定でサポートされており、構成は不要です。
配信元 TLS 接続 (Azure Front Door から配信元)
HTTPS 接続の場合、Azure Front Door では、サブジェクト名が配信元の "ホスト名" と一致する、有効な証明機関 (CA) からの証明書を提示することを配信元に要求します。 たとえば、配信元のホスト名が myapp-centralus.contoso.net に設定されており、TLS ハンドシェイク中に配信元によって提示された証明書のサブジェクト名に myapp-centralus.contoso.net も *.contoso.net も含まれていない場合、Azure Front Door ではその接続を拒否し、クライアントにエラーが表示されます。
注
証明書には、リーフ証明書と中間証明書が存在する完全な証明書チェーンが必要です。 ルート CA は、Microsoft の信頼された CA のリストに含まれている必要があります。 完全なチェーンのない証明書が提示された場合、その証明書を含む要求が期待どおりに動作することは保証されません。
テストなどの特定のユース ケースでは、失敗した HTTPS 接続を解決するための回避策として、Azure Front Door の証明書サブジェクト名チェックを無効にすることができます。 配信元は、有効な信頼できるチェーンを持つ証明書を提示する必要がありますが、配信元のホスト名と一致する必要はありません。
Azure Front Door Standard と Premium では、証明書のサブジェクト名のチェックを無効にするように配信元を構成できます。
Azure Front Door (クラシック) では、Azure portal の Azure Front Door 設定を変更することで、証明書のサブジェクト名のチェックを無効にすることができます。 Azure Front Door API のバックエンド プールの設定を使用して、チェックを構成することもできます。
注
セキュリティの観点から、Microsoft では証明書のサブジェクト名のチェックを無効にすることを推奨していません。
フロントエンド TLS 接続 (クライアントから Azure Front Door)
Azure Front Door カスタム ドメインでコンテンツを安全に配信するために HTTPS プロトコルを有効にするには、Azure Front Door によって管理されている証明書を使用するか、独自の証明書を使用するかを選択できます。
詳細については、「カスタム ドメインの HTTPS」を参照してください。
Azure Front Door のマネージド証明書では、DigiCert を介して標準の TLS/SSL 証明書が提供され、Azure Front Door の Key Vault に格納されます。
独自の証明書を使用することを選択した場合は、サポートされている CA からの証明書をオンボードできます。これは標準の TLS 証明書、Extended Validation 証明書、ワイルドカード証明書のいずれでもかまいません。 自己署名証明書はサポートされていません。 カスタム ドメインに対する HTTPS の有効化の方法を説明します。
証明書の自動ローテーション
Azure Front Door マネージド証明書では、証明書は Azure Front Door によって管理され、90 日の有効期間内に自動ローテーションされます。 Azure Front Door の Standard/Premium マネージド証明書では、証明書は Azure Front Door によって管理され、45 日の有効期間内に自動ローテーションされます。 Azure Front Door マネージド証明書を使用していて、証明書の有効期限まで 60 日未満、また Standard/Premium SKU の場合 30 日未満の場合、サポート チケットを提出してください。
独自のカスタム TLS/SSL 証明書の場合:
証明書の新しいバージョンがキー コンテナーで使用できる場合に、証明書を自動的に最新バージョンにローテーションするには、シークレット バージョンを "最新" に設定します。 カスタム証明書の場合、証明書の有効期限に関係なく、3 から 4 日以内に新しいバージョンの証明書に自動ローテーションされます。
特定のバージョンが選択されている場合、自動ローテーションはサポートされません。 証明書をローテーションするには、新しいバージョンを手動で再選択する必要があります。 新しいバージョンの証明書またはシークレットがデプロイされるまで、最大で 24 時間かかります。
注
ドメイン CNAME レコードが Front Door エンドポイントを直接指しているか Traffic Manager エンドポイントを間接的に指している場合、Azure Front Door (Standard および Premium) マネージド証明書は自動的にローテーションされます。 それ以外の場合は、ドメインの所有権を再検証して証明書をローテーションする必要があります。
Front Door のサービス プリンシパルには、キー ボールトへのアクセス権が必要です。 証明書のサブジェクト名またはサブジェクト代替名 (SAN) が変更されていない限り、Azure Front Door による、更新された証明書ロールアウト処理によって運用環境のダウン タイムが発生することはありません。
サポート対象の暗号スイート
TLS 1.2/1.3 では、次の暗号スイートがサポートされています。
- TLS_AES_256_GCM_SHA384 (TLS 1.3 のみ)
- TLS_AES_128_GCM_SHA256 (TLS 1.3 のみ)
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
注
古い TLS バージョンと脆弱な暗号はサポートされなくなりました。
TLS ポリシーを使用して、特定の暗号スイートを構成します。 Azure Front Door Standard と Premium には、TLS ポリシーを制御するための 2 つのメカニズムが用意されています。定義済みのポリシーまたは独自のニーズに応じてカスタム ポリシーを使用できます。 詳細については、「 Front Door カスタム ドメインで TLS ポリシーを構成する」を参照してください。
注
Windows 10 以降に関しては、より良いセキュリティのために 1 つまたは両方の ECDHE_GCM 暗号スイートを有効化することを推奨します。 Windows 8.1、8、7 は、これらの ECDHE_GCM 暗号スイートと互換性がありません。 これらのオペレーティング システムとの互換性のために、ECDHE_CBC および DHE 暗号スイートが提供されています。