Crittografia TLS con Frontdoor di Azure

Transport Layer Security (TLS), noto in precedenza come SSL (Secure Sockets Layer), è la tecnologia di sicurezza standard per stabilire un collegamento crittografato tra un server Web e un client, come un Web browser. Questo collegamento garantisce che tutti i dati trasmessi tra il server e il client rimangano privati e criptati.

Per soddisfare i requisiti di sicurezza o conformità, Frontdoor di Azure supporta la crittografia TLS end-to-end. L'offload TLS/SSL di Frontdoor termina la connessione TLS, decrittografa il traffico in Frontdoor di Azure e crittografa nuovamente il traffico prima di inoltrarlo all'origine. Quando le connessioni all'origine usano l'indirizzo IP pubblico dell'origine, è consigliabile configurare HTTPS come protocollo di inoltro in Frontdoor di Azure. Usando HTTPS come protocollo di inoltro, è possibile applicare la crittografia TLS end-to-end per l'intera elaborazione della richiesta dal client all'origine. L'offload TLS/SSL è supportato anche se si distribuisce un'origine privata con Frontdoor di Azure Premium usando la funzionalità collegamento privato.

Criptazione end-to-end con TLS

La crittografia TLS end-to-end protegge i dati sensibili durante il transito verso l'origine e ti permette di beneficiare di funzionalità di Frontdoor di Azure come il bilanciamento globale del carico e la cache. Alcune delle funzionalità includono anche il routing basato su URL, la suddivisione TCP, la memorizzazione nella cache nella posizione perimetrale più vicina ai client e la personalizzazione delle richieste HTTP nella rete perimetrale.

Frontdoor di Azure esegue l'offload delle sessioni TLS ai margini e decrittografa le richieste client. Applica quindi le regole di routing configurate per instradare le richieste all'origine appropriata nel gruppo di origine. Frontdoor di Azure avvia quindi una nuova connessione TLS all'origine e crittografa nuovamente tutti i dati usando il certificato dell'origine prima di trasmettere la richiesta all'origine. Qualsiasi risposta dall'origine viene crittografata attraverso lo stesso processo di ritorno all'utente finale. È possibile configurare Frontdoor di Azure per l'uso di HTTPS come protocollo di inoltro per abilitare TLS end-to-end.

Versioni di TLS supportate

Frontdoor di Azure supporta due versioni del protocollo TLS: TLS versioni 1.2 e 1.3. Tutti i profili frontdoor di Azure creati dopo settembre 2019 usano TLS 1.2 come minimo predefinito con TLS 1.3 abilitato. Attualmente Frontdoor di Azure non supporta l'autenticazione client/reciproca (mTLS).

Per Frontdoor di Azure Standard e Premium, puoi configurare una policy TLS predefinita oppure scegliere la suite di cifrari TLS in base alle esigenze di sicurezza della tua organizzazione. Per maggiori informazioni, consulta Configura una policy Frontdoor di Azure TLS.

Per Frontdoor di Azure classic e Microsoft CDN classic, puoi configurare la versione minima TLS in Frontdoor di Azure nelle impostazioni HTTPS del dominio personalizzato usando il portale Azure o l'API Azure REST. Per una versione minima TLS 1.2, il processo di negoziazione tenta di stabilire TLS 1.3 e poi TLS 1.2. Quando Frontdoor di Azure avvia traffico TLS verso l'origine, cerca di negoziare la migliore versione TLS che l'origine possa accettare in modo affidabile e costante. Le versioni TLS supportate per le connessioni di origine sono TLS 1.2 e TLS 1.3. Se vuoi personalizzare la suite cifraria, migra Front Door classic e Microsoft CDN classic su Frontdoor di Azure standard e premium.

Certificati supportati

Quando si crea il certificato TLS/SSL, è necessario creare una catena di certificati completa con un'autorità di certificazione (CA) consentita che fa parte dell'elenco ca attendibile Microsoft. Se usi una CA non consentita, Frontdoor di Azure rifiuta la tua richiesta.

I certificati provenienti da autorità di certificazione interne o certificati autofirmati non sono consentiti.

Associazione Protocollo di stato del certificato online (OCSP)

Frontdoor di Azure supporta di default la graffetta OCSP e non richiede alcuna configurazione.

Connessione TLS di origine (Frontdoor di Azure all'origine)

Per le connessioni HTTPS, Frontdoor di Azure si aspetta che la tua origine presenti un certificato di un'autorità certificatrice valida (CA) con un nome di oggetto che corrisponda al nome host di origine. Ad esempio, se imposti il tuo nome host di origine su myapp-centralus.contoso.net ma il certificato che il tuo origin presenta durante la stretta TLS non viene incluso myapp-centralus.contoso.net o *.contoso.net nel nome dell'oggetto, Frontdoor di Azure rifiuta la connessione e il client vede un errore.

In alcuni casi d'uso, come i test, puoi disabilitare i controlli del nome del soggetto dei certificati per Frontdoor di Azure come soluzione alternativa per risolvere connessioni HTTPS fallimentari. L'origine deve comunque presentare un certificato con una catena attendibile valida, ma non deve corrispondere al nome host di origine.

Connessione TLS front-end (da client a Frontdoor di Azure)

Per abilitare il protocollo HTTPS per la consegna sicura di contenuti su un dominio personalizzato Frontdoor di Azure, usa o un certificato gestito da Frontdoor di Azure oppure un certificato personale.

Autorotazione del certificato

Per l'opzione certificato gestito Frontdoor di Azure Standard/Premium, Frontdoor di Azure gestisce i certificati e li ruota automaticamente entro 45 giorni dalla scadenza. Per l'opzione di certificato gestito Frontdoor di Azure Classic e Rete CDN di Azure Classic, Frontdoor di Azure gestisce i certificati e li ruota automaticamente entro 90 giorni dalla scadenza. Se stai usando il certificato gestito Classic Tier e vedi che la data di scadenza del certificato è meno di 60 giorni o 30 giorni per il livello Standard/Premium, apri un ticket di supporto.

Per il proprio certificato TLS/SSL personalizzato:

1. Imposta la versione segreta su Ultima affinché il certificato ruoti automaticamente all'ultima versione quando una versione più recente del certificato è disponibile nel tuo caveau delle chiavi. Per i certificati personalizzati, il certificato si autorota entro 3-4 giorni con una versione più recente del certificato, indipendentemente dal tempo di scadenza del certificato.

2. Se selezioni una versione specifica, l'autorotazione non è supportata. Devi riselezionare manualmente la nuova versione per ruotare il certificato. Ci vogliono fino a 24 ore per il dispiegamento della nuova versione del certificato o del segreto.

   Nota

   Frontdoor di Azure Standard e Premium ruotano automaticamente i certificati gestiti solo quando il dominio CNAME personalizzato punta direttamente all'endpoint di Frontdoor di Azure. Per configurazioni indirette CNAME, usa un certificato bring-your-own, poiché Frontdoor di Azure tenta la validazione del dominio tramite validazione token basata su file quando il traffico raggiunge Frontdoor di Azure, ma la validazione con successo non è garantita.

   L'entità servizio per Frontdoor deve avere accesso a Key Vault. L'aggiornamento dell'operazione di rollout del certificato da parte di Frontdoor di Azure non causa tempi di inattività in produzione, purché il nome del soggetto o il nome alternativo dell'oggetto (SAN) per il certificato non sia cambiato.

Pacchetti di crittografia supportati

Per TLS 1.2 e 1.3, Frontdoor di Azure supporta le seguenti suite di cifratura:

• TLS_AES_256_GCM_SHA384 (solo TLS 1.3)
• TLS_AES_128_GCM_SHA256 (solo 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

Usare i criteri TLS per configurare pacchetti di crittografia specifici. Frontdoor di Azure Standard e Premium offrono due meccanismi per il controllo dei criteri TLS: è possibile usare un criterio predefinito o un criterio personalizzato in base alle proprie esigenze. Per maggiori informazioni, consulta Configura una policy Frontdoor di Azure TLS.

Contenuti correlati