Azure Front Door での TLS 暗号化について

重要

TLS 1.0 と 1.1 のサポートは、2025 年 3 月 1 日に廃止される予定です。

トランスポート層セキュリティ (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 プロトコルの 4 つのバージョン (TLS バージョン 1.0、1.1、1.2、1.3) がサポートされています。 2019 年 9 月以降に作成されたすべての Azure Front Door プロファイルでは、TLS 1.3 が有効になっている既定の最小値として TLS 1.2 が使用されますが、TLS 1.0 と TLS 1.1 は下位互換性のために引き続きサポートされています。 TLS 1.0 と 1.1 のサポートは、2025 年 3 月 1 日に廃止される予定です。

TLS 1.2 をサポートしている Azure Front Door は RFC 5246 でクライアント/相互認証を導入していますが、現在、Azure Front Door ではクライアント/相互認証 (mTLS) は、まだサポートされていません。

Azure portal またはAzure REST API を使用して、カスタム ドメインの HTTPS 設定で Azure Front Door に TLS の最小バージョンを構成できます。 現時点では、1.0 と 1.2 のどちらかを選択できます。 そのため、TLS 1.2 を最小バージョンとして指定すると、Azure Front Door がクライアントから受け入れる TLS の最小許容バージョンが制御されます。 最小 TLS バージョン 1.2 では、ネゴシエーションにより TLS 1.3 と TLS 1.2 の確立が試行されますが、最小 TLS バージョン 1.0 では 4 つのバージョンすべてが試行されます。 Azure Front Door では、配信元への TLS トラフィックを開始すると、配信元が確実かつ一貫して受け入れることができる最適な TLS バージョンのネゴシエーションを試行します。 配信元接続でサポートされている TLS バージョンは、TLS 1.0、TLS 1.1、TLS 1.2、TLS 1.3 です。 TLS 1.0 と 1.1 のサポートは、2025 年 3 月 1 日に廃止される予定です。

Note

• TLS 1.3 を有効にしたクライアントでは、TLS 1.3 を使用して Azure Front Door で要求を正常に行うために、Secp384r1、Secp256r1、Secp521 など、Microsoft SDL 準拠の EC 曲線のいずれかをサポートする必要があります。
• サポートされている EC 曲線をネゴシエートするために複数のラウンド トリップが発生する原因となる TLS ハンドシェイクの待ち時間の増加を回避するために、クライアントでは要求時にこれらの曲線のいずれかを優先曲線として使用することをお勧めします。

サポートされている証明書

TLS/SSL 証明書を作成する場合は、Microsoft の信頼された CA リストの一部である許可された証明機関 (CA) を使用した完全な証明書チェーンを作成する必要があります。 許可されていない CA を使用すると、要求が拒否されます。

内部 CA からの証明書または自己署名証明書は許可されません。

オンライン証明書状態プロトコル (OCSP) ステープリング

Azure Front Door では OCSP ステープリングが既定でサポートされており、構成は不要です。

配信元 TLS 接続 (Azure Front Door から配信元)

HTTPS 接続の場合、Azure Front Door では、サブジェクト名が配信元の "ホスト名" と一致する、有効な証明機関 (CA) からの証明書を提示することを配信元に要求します。 たとえば、配信元のホスト名が myapp-centralus.contosonews.net に設定されており、TLS ハンドシェイク中に配信元によって提示された証明書のサブジェクト名に myapp-centralus.contosonews.net も *.contosonews.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 のバックエンド プールの設定を使用して、チェックを構成することもできます。

Note

セキュリティの観点から、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 証明書の場合:

1. キー コンテナーで新しいバージョンの証明書が利用可能になったときに、証明書を最新バージョンに自動的にローテーションするには、シークレットのバージョンを "Latest" に設定します。 カスタム証明書の場合、証明書の有効期限に関係なく、3 から 4 日以内に新しいバージョンの証明書に自動ローテーションされます。

2. 特定のバージョンが選択されている場合、自動ローテーションはサポートされません。 証明書をローテーションするには、新しいバージョンを手動で再選択する必要があります。 新しいバージョンの証明書またはシークレットがデプロイされるまで、最大で 24 時間かかります。

   Note

   ドメイン 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

注意

Windows 10 以降に関しては、より良いセキュリティのために 1 つまたは両方の ECDHE_GCM 暗号スイートを有効化することを推奨します。 Windows 8.1、8、7 は、これらの ECDHE_GCM 暗号スイートと互換性がありません。 これらのオペレーティング システムとの互換性のために、ECDHE_CBC および DHE 暗号スイートが提供されています。

TLS1.0 および 1.1 が有効になっているカスタム ドメインを使用している場合は、次の暗号スイートがサポートされます。

• TLS_AES_256_GCM_SHA384 (TLS 1.3 のみ)
• TLS_AES_128_GCM_SHA256 (TLS 1.3 のみ)
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Azure Front Door では、プロファイルの特定の暗号スイートの無効化または構成はサポートされていません。

次のステップ

• Azure Front Door のカスタム ドメインについて理解します。
• Azure portal を使用して Azure Front Door でカスタム ドメインを構成します。
• Azure Front Door を使用したエンド ツー エンド TLS について説明します。

• Azure Front Door のカスタム ドメインを構成します。
• カスタム ドメインの HTTPS を有効します。