Transport Layer Security (TLS) in Azure HorizonDB (anteprima)

Azure HorizonDB richiede che tutte le connessioni client usino Transport Layer Security (TLS), un protocollo standard del settore che crittografa le comunicazioni tra il cluster di database e le applicazioni client. TLS sostituisce il protocollo SSL precedente, con solo le versioni TLS 1.2 e 1.3 riconosciute come sicure. L'integrità della sicurezza TLS si basa su tre pilastri:

  • Uso solo di TLS versione 1.2 o 1.3.
  • Il client valida il certificato TLS del cluster emesso da un'autorità di certificazione (CA) in una catena di CA che inizia con una CA radice attendibile.
  • Negoziazione di una suite di crittografia sicura tra cluster e client.

Certificati radice attendibili e rotazione dei certificati

Autorità di certificazione radice utilizzate da Azure HorizonDB

Le autorità di certificazione radice sono le autorità di primo livello della catena di certificati. Azure HorizonDB attualmente utilizza certificati a doppia firma rilasciati da un'autorità di certificazione intermedia (ICA) facente capo alle seguenti CA radice:

Attualmente le aree della Cina usano le ca seguenti:

Autorità di certificazione intermedie

Azure HorizonDB usa autorità di certificazione intermedie (ICA) per rilasciare certificati cluster. Per garantire la sicurezza, Microsoft ruota periodicamente questi ICA e i certificati del cluster che emettono. Queste rotazioni sono routine e non vengono annunciate in anticipo.

L'attuale rotazione degli ICA per DigiCert Global Root CA (vedi Rotazione dei certificati) è iniziata a novembre 2025 e dovrebbe essere completata nel primo trimestre del 2026. Se sono state seguite le procedure consigliate, questa modifica non richiede modifiche nell'ambiente.

Catena di autorità di certificazione precedente

Non usare le autorità di certificazione intermedie o i certificati del cluster nell'archivio radice attendibile.

  • DigiCert Global Root G2
    • Microsoft Azure RSA TLS Issuing CA 03 / 04 / 07 / 08
      • Certificato del cluster

Nuova catena di autorità di certificazione (CA)

Non usare le autorità di certificazione intermedie o i certificati del cluster nell'archivio radice attendibile.

  • DigiCert Global Root G2
    • Microsoft TLS RSA Root G2
      • Microsoft TLS G2 RSA CA OCSP 02 / 04 / 06 / 08 / 10 / 12 / 14 / 16
        • Certificato del cluster

Repliche in lettura

La migrazione dell'autorità di certificazione radice da DigiCert Global Root CA a DigiCert Global Root G2 non è stata completata in tutte le regioni. Pertanto, è possibile che le repliche di lettura appena create usino un certificato dell’autorità di certificazione radice più recente rispetto al server primario. È necessario aggiungere DigiCert Global Root CA all'archivio attendibile delle repliche in lettura.

Catene di certificati

Una catena di certificati è una sequenza gerarchica di certificati rilasciati dalle autorità di certificazione attendibili. La catena inizia dalla CA principale, che rilascia certificati per le autorità di certificazione intermedie (ICA). Gli ICA possono rilasciare certificati per gli ICA subordinati. L'ICA più bassa della catena rilascia singoli certificati del cluster. Per stabilire la catena di attendibilità, si verifica ogni certificato nella catena fino al certificato radice dell'Autorità di Certificazione (CA).

Ridurre gli errori di connessione

L'uso delle configurazioni TLS consigliate consente di ridurre il rischio di errori di connessione dovuti alle rotazioni dei certificati o alle modifiche nelle autorità di certificazione intermedie. In particolare, evitare di considerare attendibili le autorità di certificazione intermedie o i singoli certificati del cluster. Queste procedure possono causare problemi di connessione imprevisti quando Microsoft aggiorna la catena di certificati.

Importante

Microsoft annuncia in anticipo le modifiche apportate alle CA radice per preparare le applicazioni client. Tuttavia, le rotazioni dei certificati del cluster e le modifiche apportate alle ca intermedie sono routine e non vengono annunciate.

Attenzione

L'uso di configurazioni non supportate (client) causa errori di connessione imprevisti.

Configurazione ottimale

  • Applicare la versione TLS più recente e sicura impostando il ssl_min_protocol_version parametro su TLSv1.3.
  • Usare sslmode=verify-all per le connessioni PostgreSQL per garantire la verifica completa del certificato e del nome host. A seconda della configurazione DNS con endpoint privati o integrazione di rete virtuale, verify-all potrebbe non essere possibile. Pertanto, è possibile usare verify-ca invece .
  • Mantenere sempre il set completo di certificati radice di Azure nell'archivio radice attendibile.

Configurazione ottimale

  • Impostare il parametro ssl_min_protocol_version su TLSv1.3. Se è necessario supportare TLS 1.2, non impostare la versione minima.
  • Usare sslmode=verify-all o sslmode=verify-ca per le connessioni PostgreSQL per garantire la verifica completa o parziale del certificato.
  • Verificare che l'archivio radice attendibile contenga il certificato CA radice attualmente utilizzato da Azure HorizonDB:

Non usare le configurazioni seguenti:

  • Disabilitare TLS impostando require_secure_transport su OFF e impostando il lato cliente su sslmode=disable.
  • Utilizzare le impostazioni sslmode lato client disable, allow, prefer o require che possono rendere l'app vulnerabile agli attacchi man-in-the-middle.

Configurazioni non supportate; non usare

Azure PostgreSQL non comunica modifiche relative ai cambiamenti della CA intermedia o alle rotazioni dei singoli certificati del cluster. Di conseguenza, le configurazioni seguenti non sono supportate quando si usano sslmode le impostazioni verify-ca o verify-all:

  • Uso di certificati CA intermedi nell'archivio attendibile.
  • Uso dell'associazione dei certificati, ad esempio uso di certificati cluster singoli nell'archivio attendibile.

Attenzione

Le applicazioni non riescono a connettersi al cluster di database senza alcun avviso ogni volta che Microsoft modifica le ca intermedie della catena di certificati o ruota il certificato del cluster.

Problemi di associazione dei certificati

Note

Le rotazioni dei certificati non influiscono su di te se non usi le impostazioni sslmode=verify-full o sslmode=verify-ca nella stringa di connessione dell'applicazione client. Pertanto, non è necessario seguire i passaggi descritti in questa sezione.

Non utilizzare mai l'associazione dei certificati nelle applicazioni perché impedisce la rotazione dei certificati, ad esempio la modifica del certificato corrente delle CA intermedie. Se non si conosce l'associazioni dei certificati, è improbabile che sia in uso. Per verificare la presenza dell'associazione dei certificati:

  • Generare l'elenco dei certificati presenti nell'archivio radice attendibile.
  • Si usa l'associazione dei certificati se sono presenti certificati CA intermedi o singoli certificati del cluster PostgreSQL nell'archivio radice attendibile.
  • Per rimuovere l'associazione dei certificati, rimuovere tutti i certificati dall'archivio radice attendibile e aggiungere i certificati radice CA consigliati.

Se si verificano problemi a causa del certificato intermedio anche dopo aver seguito questi passaggi, contattare il supporto tecnico Microsoft. Includere ICA Rotation 2026 nel titolo.

Altre considerazioni per TLS

Oltre alla configurazione e alla gestione dei certificati TLS di base, diversi altri fattori influenzano la sicurezza e il comportamento delle connessioni crittografate a Azure HorizonDB. La comprensione di queste considerazioni consente di prendere decisioni informate sull'implementazione di TLS nell'ambiente in uso.

Importante

Azure HorizonDB non supporta l'autenticazione del certificato client TLS (TLS reciproco). Non includere i parametri del certificato client (sslcert, sslkey) nelle stringhe di connessione perché non sono supportati e potrebbero causare problemi di connessione.

Versioni TLS non sicure e sicure

Diverse entità governative a livello globale mantengono linee guida per TLS in materia di sicurezza di rete. Negli Stati Uniti, queste organizzazioni includono il Dipartimento della salute e dei servizi umani e l'Istituto nazionale di standard e tecnologia. Il livello di sicurezza fornito da TLS è più interessato dalla versione del protocollo TLS e dai pacchetti di crittografia supportati.

Azure HorizonDB supporta TLS versioni 1.2 e 1.3. In RFC 8996, Internet Engineering Task Force (IETF) indica in modo esplicito che TLS 1.0 e TLS 1.1 non devono essere usati. Entrambi i protocolli sono stati deprecati entro la fine del 2019. Tutte le connessioni in ingresso che usano versioni non sicure precedenti del protocollo TLS, ad esempio TLS 1.0 e TLS 1.1, vengono negate per impostazione predefinita.

IETF ha rilasciato la specifica TLS 1.3 in RFC 8446 nell'agosto 2018 e TLS 1.3 è la versione consigliata perché è più veloce e più sicuro di TLS 1.2.

Anche se non è necessario, se necessario, è possibile disabilitare TLS per le connessioni al Azure HorizonDB. È possibile aggiornare il require_secure_transport parametro a OFF.

Importante

Usare la versione più recente di TLS 1.3 per crittografare le connessioni al database. È possibile specificare la versione minima di TLS impostando il ssl_min_protocol_version parametro su TLSv1.3. Non impostare il ssl_max_protocol_version parametro .

Pacchetti di crittografia

Una suite di crittografia è un set di algoritmi che includono una crittografia, un algoritmo di scambio di chiavi e un algoritmo hash. Usarli insieme al certificato TLS e alla versione TLS per stabilire una connessione TLS sicura. La maggior parte dei client e dei cluster TLS supporta più suite di crittografia e talvolta più versioni DI TLS. Durante la creazione della connessione, il client e il cluster negoziano la versione e la suite di crittografia TLS da usare tramite un handshake. Durante questo handshake, si verificano i passaggi seguenti:

  • Il client invia un elenco di pacchetti di crittografia accettabili.
  • Il server seleziona la suite di crittografia migliore dall'elenco e informa il client della scelta.

Funzionalità TLS non disponibili in Azure HorizonDB

Al momento, Azure HorizonDB non implementa le funzionalità TLS seguenti:

  • Autenticazione client basata su certificati TLS tramite TLS con autenticazione reciproca (mTLS).
  • Certificati personalizzati per il cluster (certificati TLS forniti dall'utente).

Contenuti correlati

  • Last updated on