Condividi tramite

Transport Layer Security (TLS) nei database di Azure per PostgreSQL

Database di Azure per PostgreSQL richiede che tutte le connessioni client usino Transport Layer Security (TLS), un protocollo standard del settore che crittografa le comunicazioni tra il server 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 convalida il certificato TLS del server emesso da un'autorità di certificazione (CA) in una catena di CA avviate da una CA radice attendibile.
  • Negoziazione di una suite di crittografia sicura tra server e client.

Certificati radice fidati e rotazione dei certificati

Importante

Microsoft ha avviato una rotazione dei certificati TLS per Database di Azure per PostgreSQL per aggiornare i certificati CA intermedi e la catena di certificati risultante. L'Autorità di certificazione radice rimane invariata.

Se la configurazione client usa le configurazioni consigliate per TLS, non è necessario eseguire alcuna azione.

Pianificazione della rotazione dei certificati

  • Le aree di Azure Stati Uniti centro-occidentali, Asia orientale e Regno Unito meridionale hanno avviato la rotazione dei certificati TLS il 11 novembre 2025.
  • A partire dal 19 gennaio 2026, questa rotazione dei certificati è pianificata per estendersi a tutte le aree rimanenti (eccetto la Cina), inclusa Azure Government.
  • Dopo il Festival della Primavera (Cinese Nuovo Anno) 2026, anche le regioni della Cina subiranno una rotazione del certificato che include una modifica a una delle CA radice.

CA radice utilizzate da Azure Database per PostgreSQL

L'autorità di certificazione radice è l'autorità di primo livello nella catena di certificazione. Azure Database per PostgreSQL attualmente utilizza certificati a doppia firma rilasciati da un'autorità di certificazione intermedia (ICA) ancorata dalle seguenti CA radice:

Attualmente le aree della Cina usano le ca seguenti:

CA intermedie

Database di Azure per PostgreSQL utilizza le autorità di certificazione intermedie (ICA) per rilasciare i certificati del server. Per mantenere la sicurezza, Microsoft ruota periodicamente questi ICA e i certificati del server rilasciati. Queste rotazioni sono routine e non vengono annunciate in anticipo.

La rotazione attuale delle CA intermedie per DigiCert Global Root CA (vedere Rotazione dei certificati) è stata avviata nel novembre 2023 ed è prevista per essere completata nel primo trimestre del 2024. Se sono state seguite le procedure consigliate, questa modifica non richiede modifiche nell'ambiente.

Catena CA precedente

Non usare CA intermedie o certificati server nel tuo archivio radice attendibile.

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

Nuova catena di autorità di certificazione (CA)

Non usare CA intermedie o certificati server nel tuo 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 server

Repliche in lettura

La migrazione della CA radice da DigiCert Global Root CA a DigiCert Global Root G2 non viene completata in tutte le aree. Pertanto, è possibile che le repliche di lettura appena create usino un certificato CA radice più recente rispetto al server primario. È necessario aggiungere DigiCert Global Root CA nell'archivio attendibile delle repliche in lettura.

Catene di certificati

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

Riduzione degli errori di connessione

L'uso delle configurazioni TLS consigliate consente di ridurre il rischio di errori di connessione dovuti a rotazioni dei certificati o modifiche nelle ca intermedie. In particolare, evitare di considerare attendibili ca intermedie o singoli certificati server. 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 server 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 parametro del ssl_min_protocol_version server 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 del ssl_min_protocol_version server 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.
  • Assicurarsi che l'archivio radice attendibile contenga il certificato CA radice attualmente usato da Database di Azure per PostgreSQL:

Non usare le configurazioni seguenti:

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

Configurazioni non supportate; non usare

Azure PostgreSQL non annuncia le modifiche alle modifiche intermedie della CA o alle rotazioni dei singoli certificati del server. Di conseguenza, le configurazioni seguenti non sono supportate quando si usano sslmode le impostazioni verify-ca o verify-all:

  • Uso di certificati di autorità di certificazione intermedi nell'archivio di fiducia.
  • Utilizzando il pinning dei certificati, come l'uso di certificati server individuali nel tuo archivio attendibile.

Attenzione

Le applicazioni non riescono a connettersi ai server di database senza alcun avviso ogni volta che Microsoft modifica le CA intermedie della catena di certificati o ruota il certificato server.

Problemi di aggiunta del certificato

Annotazioni

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 usare mai il pinning dei certificati nelle applicazioni perché impedisce la rotazione dei certificati, ad esempio la modifica attuale del certificato delle CA intermedie. Se non sai cos'è il pinning del certificato, è improbabile che tu lo stia usando. Per verificare il certificate pinning:

  • Genera l'elenco dei certificati presenti nel tuo archivio radice attendibile.
  • Si utilizza il pinning dei certificati se sono presenti certificati CA intermedi o singoli certificati del server PostgreSQL nel tuo archivio radice attendibile.
  • Per rimuovere il pinning dei certificati, rimuovere tutti i certificati dall'archivio radice attendibile e aggiungere i certificati CA radice 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 Database di Azure per PostgreSQL. La comprensione di queste considerazioni consente di prendere decisioni informate sull'implementazione di TLS nell'ambiente in uso.

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.

Database di Azure per PostgreSQL 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 è consigliabile, se necessario, è possibile disabilitare TLS per le connessioni al database di Azure per PostgreSQL. È possibile aggiornare il parametro del server require_secure_transport 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 parametro del ssl_min_protocol_version server su TLSv1.3. Non impostare il parametro del ssl_max_protocol_version server.

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 server TLS supporta più suite di crittografia e talvolta più versioni TLS. Durante la creazione della connessione, il client e il server 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 Database di Azure per PostgreSQL

Al momento, Database di Azure per PostgreSQL non implementa le funzionalità TLS seguenti:

  • Autenticazione client basata su certificati TLS tramite TLS con autenticazione reciproca (mTLS).
  • Certificati server personalizzati (porta i tuoi certificati TLS).

Contenuti correlati

  • Last updated on