Azure Front Door を使用したエンド ツー エンド TLS

トランスポート層セキュリティ (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 オフロードもサポートされます。

エンド ツー エンド 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.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/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 ではその接続を拒否し、クライアントにエラーが表示されます。

テストなどの特定の使用例では、HTTPS 接続の失敗を解決するための回避策として、Azure Front Door で証明書のサブジェクト名のチェックを無効にすることができます。 引き続き、配信元では有効な信頼されたチェーンを持つ証明書を提示する必要がありますが、配信元のホスト名と一致する必要はないことに留意してください。

フロントエンド TLS 接続 (クライアントから Azure Front Door)

Azure Front Door カスタム ドメインでコンテンツを安全に配信するために HTTPS プロトコルを有効にするには、Azure Front Door によって管理されている証明書を使用するか、独自の証明書を使用するかを選択できます。

証明書の自動ローテーション

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

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 では、プロファイルの特定の暗号スイートの無効化または構成はサポートされていません。

次のステップ