Condividi tramite

Proteggere la connettività con TLS e SSL nel server flessibile di Database di Azure per PostgreSQL

SI APPLICA A: Database di Azure per PostgreSQL - Server flessibile

Il server flessibile di Database di Azure per PostgreSQL impone la connessione delle applicazioni client al server flessibile di Database di Azure per PostgreSQL tramite Transport Layer Security (TLS). TLS è un protocollo standard del settore che garantisce connessioni di rete crittografate tra il server di database e le applicazioni client. TLS è un protocollo aggiornato di Secure Sockets Layer (SSL).

Che cos'è TLS?

TLS è stato creato a partire dal protocollo SSL di Netscape e lo ha sostituito regolarmente. I termini SSL o TLS/SSL sono ancora talvolta usati in modo intercambiabile. TLS è costituito da due livelli: il contenuto del record TLS e il contenuto dell'handshake TLS. Il contenuto del record fornisce la sicurezza dell'associazione. Il contenuto dell'handshake consente al server e al cliente di autenticarsi reciprocamente e di coordinare le valutazioni di crittografia e le chiavi di crittografia prima che avvenga qualsiasi scambio di informazioni.

Diagramma che mostra la tipica sequenza di handshake TLS 1.2.

Il diagramma precedente mostra una tipica sequenza di handshake TLS 1.2, costituita da questi passaggi:

  1. Il client inizia inviando un messaggio denominato ClientHello che esprime la volontà di comunicare tramite TLS 1.2 con un set di suite di crittografia supportate dal client.
  2. Il server riceve il messaggio, risponde con ServerHelloe accetta di comunicare con il client tramite TLS 1.2 usando una particolare suite di crittografia.
  3. Il server invia anche la condivisione della chiave. Le specifiche di questa condivisione di chiave variano in base alla suite di crittografia selezionata. Affinché il client e il server possano concordare una chiave crittografica, è necessario che ricevano ciascuno la parte dell'altro.
  4. Il server invia il certificato (firmato dall'autorità di certificazione [CA]) e una firma in parti di ClientHello e ServerHello. Include anche la condivisione di chiave. In questo modo, il client ha la certezza dell'autenticità dell'altra parte.
  5. Dopo che il client riceve correttamente i dati e quindi genera la propria condivisione di chiave, la combina con la condivisione della chiave server per generare le chiavi di crittografia per la sessione.
  6. Il client invia al server la condivisione di chiave, abilita la crittografia e invia un messaggio Finished. Questo messaggio è un hash di una trascrizione quanto svoltosi finora. Il server esegue la stessa operazione. Combina le condivisioni di chiave per ottenere la chiave e invia il proprio messaggio Finished.
  7. Ora i dati dell'applicazione possono essere inviati crittografati nella connessione.

Catene di certificati

Una catena di certificati è un elenco ordinato di certificati che contengono un certificato TLS/SSL e certificati CA. Consentono al ricevitore di verificare che il mittente e tutte le CA siano attendibili. La catena o il percorso inizia con il certificato TLS/SSL. Ogni certificato nella catena è firmato dall'entità identificata dal certificato successivo nella catena.

La catena termina con un certificato della CA radice. Questo certificato è sempre firmato dalla CA stessa. Le firme di tutti i certificati nella catena devono essere verificate fino al certificato della CA radice.

Qualsiasi certificato che si trova tra il certificato TLS/SSL e il certificato CA radice nella catena è denominato certificato intermedio.

Versioni di TLS

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.

Una suite di crittografia è un set di algoritmi che includono una crittografia, un algoritmo di scambio di chiavi e un algoritmo hash. Vengono usati insieme per stabilire una connessione TLS sicura. La maggior parte dei client e dei server TLS supporta più alternative. Devono negoziare, al momento della creazione di una connessione sicura, per selezionare una versione TLS e una suite di cifratura comuni.

Database di Azure per PostgreSQL supporta la versione 1.2 e successive di TLS. In RFC 8996, la 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 precedenti del protocollo TLS, ad esempio TLS 1.0 e TLS 1.1, verranno rifiutate per impostazione predefinita.

IETF ha rilasciato la specifica TLS 1.3 in RFC 8446 nell'agosto 2018 e TLS 1.3 è ora la versione TLS più comune e consigliata in uso. TLS 1.3 è più veloce e più sicura di TLS 1.2.

Annotazioni

I certificati SSL e TLS certificano che la connessione è protetta con protocolli di crittografia all'avanguardia. Crittografando la connessione durante la trasmissione, si impedisce l'accesso non autorizzato ai dati durante il transito. È consigliabile usare le versioni più recenti di TLS per crittografare le connessioni al server flessibile di Database di Azure per PostgreSQL.

Anche se non è consigliabile, se necessario, è possibile disabilitare TLS\SSL per le connessioni al server flessibile di Database di Azure per PostgreSQL. È possibile aggiornare il parametro del server require_secure_transport a OFF. È anche possibile impostare la versione di TLS impostando i parametri del server ssl_min_protocol_version e ssl_max_protocol_version.

L'autenticazione del certificato viene eseguita usando i certificati client SSL per l'autenticazione. In questo scenario, il server PostgreSQL confronta l'attributo nome comune del certificato client presentato con l'utente del database richiesto.

Al momento, il server flessibile di Database di Azure per PostgreSQL non supporta:

Annotazioni

Microsoft ha apportato modifiche CA radice per vari servizi di Azure, incluso il server flessibile di Database di Azure per PostgreSQL. Per altre informazioni, vedere Modifiche al certificato TLS di Azure e la sezione Configurare SSL nel client.

Per determinare lo stato corrente della connessione TLS\SSL, è possibile caricare l'estensione sslinfo e quindi chiamare la funzione ssl_is_used() per determinare se viene usato SSL. La funzione restituisce t se la connessione usa SSL. In caso contrario, viene restituito f. È anche possibile raccogliere tutte le informazioni sull'utilizzo di SSL del server flessibile di Database di Azure per PostgreSQL in base a processo, client e applicazione usando la query seguente:

SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
   FROM pg_stat_ssl
   JOIN pg_stat_activity
   ON pg_stat_ssl.pid = pg_stat_activity.pid
   ORDER BY ssl;

Per i test, è anche possibile usare direttamente il comando openssl:

openssl s_client -starttls postgres -showcerts -connect <your-postgresql-server-name>:5432

Questo comando stampa informazioni di protocollo di basso livello, ad esempio la versione e la crittografia TLS. È necessario usare l'opzione -starttls postgres. In caso contrario, questo comando segnala che non è in uso alcun protocollo SSL. L'uso di questo comando richiede almeno OpenSSL 1.1.1.

Per applicare la versione più recente e sicura di TLS per proteggere la connettività dal client al server flessibile di Azure Database per PostgreSQL, impostare ssl_min_protocol_version su 1.3. Questa impostazione richiede ai client che si connettono al server flessibile di Database di Azure per PostgreSQL di usare solo questa versione del protocollo per comunicare in modo sicuro. I client meno recenti potrebbero non essere in grado di comunicare con il server perché non supportano questa versione.

Configurare SSL nel client

Per impostazione predefinita, PostgreSQL non esegue alcuna verifica del certificato del server. Per questo motivo, è possibile eseguire lo spoofing dell'identità del server (ad esempio, modificando un record DNS o acquisendo l'indirizzo IP del server) senza che il client ne sia a conoscenza. Tutte le opzioni SSL comportano un certo sovraccarico dovuto alla crittografia e allo scambio di chiavi, quindi si rende necessario un compromesso tra prestazioni e sicurezza.

Per evitare lo spoofing, è necessario usare la verifica del certificato SSL nel client.

Esistono molti parametri di connessione per configurare il client per SSL. Alcuni tra i più importanti sono:

  • ssl: Connettere tramite SSL. Questa proprietà non richiede un valore associato. La sua semplice presenza specifica una connessione SSL. Per la compatibilità con le versioni future, il valore true è preferibile. In questa modalità, quando si stabilisce una connessione SSL, il driver del client convalida l'identità del server per impedire attacchi "man in the middle". Verifica che il certificato del server sia firmato da un'autorità attendibile e che l'host a cui ci si connette sia lo stesso del nome host nel certificato.

  • sslmode: se si necessita di crittografia e si vuole che la connessione venga interrotta se non può essere crittografata, impostare sslmode=require. Questa impostazione garantisce che il server sia configurato per accettare le connessioni SSL per questo host o indirizzo IP e che il server riconosca il certificato client. Se il server non accetta connessioni SSL o il certificato client non viene riconosciuto, la connessione non riesce. Nella tabella seguente sono elencati i valori per questa impostazione:

    SSL Mode (Modalità SSL) Spiegazione
    disable La crittografia non è usata.
    allow La crittografia viene usata se le impostazioni del server la richiedono o la impongono.
    prefer La crittografia viene usata se le impostazioni del server lo consentono.
    require La crittografia viene usata. Ciò garantisce che il server sia configurato per accettare le connessioni SSL per questo host o indirizzo IP e che il server riconosca il certificato client.
    verify-ca La crittografia viene usata. Verificare la firma del certificato del server rispetto al certificato archiviato nel client.
    verify-full La crittografia viene usata. Verificare la firma del certificato del server e il nome host rispetto al certificato archiviato nel client.

    La modalità predefinita sslmode usata è diversa tra i client basati su libpq (ad esempio psql) e JDBC. Per impostazione predefinita, i client basati su libpq sono prefer. Per impostazione predefinita, i client JDBC sono verify-full.

  • sslcert, sslkeye sslrootcert: questi parametri possono eseguire l'override del percorso predefinito del certificato client, della chiave client PKCS-8 e del certificato radice. Per impostazione predefinita, i valori sono /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8 e /defaultdir/root.crt rispettivamente, mentre defaultdir corrisponde a ${user.home}/.postgresql/ nei sistemi *nix e a %appdata%/postgresql/ su Windows.

Le autorità di certificazione sono le istituzioni responsabili per il rilascio dei certificati. Un'autorità di certificazione attendibile è un'entità autorizzata a verificare che qualcuno sia realmente chi dichiara di essere. Affinché questo modello funzioni, tutti i partecipanti devono accettare un set di CA attendibili. Tutti i sistemi operativi e la maggior parte dei Web browser prevedono un set di CA attendibili.

L'utilizzo delle impostazioni di configurazione verify-ca e verify-fullsslmode può anche essere noto come associazione del certificato. In questo caso, i certificati CA radice nel server PostgreSQL devono corrispondere alla firma del certificato e anche al nome host rispetto al certificato nel client.

Potrebbe essere necessario aggiornare periodicamente i certificati archiviati dal client quando le CA cambiano o scadono nei certificati del server PostgreSQL. Per determinare se si stanno aggiungendo CA, vedere Aggiunta di certificati e servizi di Azure.

Per altre informazioni sulla configurazione di SSL\TLS nel client, vedere la documentazione di PostgreSQL.

Per i client che usano le impostazioni di configurazione verify-ca e verify-fullsslmode (ovvero l'aggiunta di certificati) devono distribuire tre certificati CA radice negli archivi certificati client:

Scaricare i certificati CA radice e aggiornare i client dell'applicazione negli scenari di aggiunta di certificati

Per aggiornare le applicazioni client negli scenari di aggiunta di certificati, è possibile scaricare i certificati:

Per importare i certificati negli archivi certificati client, potrebbe essere necessario convertire i file con estensione .crt del certificato in formato .pem dopo aver scaricato i file di certificato dagli URI precedenti. È possibile usare l'utilità OpenSSL per eseguire queste conversioni di file:

openssl x509 -inform DER -in certificate.crt -out certificate.pem -outform PEM

Le informazioni sull'aggiornamento degli archivi certificati delle applicazioni client con nuovi certificati CA radice sono documentate in Aggiornare i certificati TLS client per i client dell'applicazione.

Importante

Alcune delle librerie client Postgres, mentre l'impostazione sslmode=verify-full è in uso, potrebbero riscontrare errori di connessione con certificati CA radice firmati con certificati intermedi. Il risultato è percorsi di attendibilità alternativi. In questo caso, è consigliabile specificare in modo esplicito il parametro sslrootcert. In alternativa, impostare la variabile di ambiente PGSSLROOTCERT su un percorso locale in cui viene inserito il certificato CA radice Microsoft RSA 2017, dal valore predefinito di %APPDATA%\postgresql\root.crt.

Repliche in lettura con scenari di associazione del certificato

Con la migrazione della CA radice a Microsoft RSA Root CA 2017, è possibile che le repliche appena create siano in un certificato CA radice più recente rispetto al server primario creato in precedenza. Per i client che usano le impostazioni di configurazione verify-ca e verify-fullsslmode (ovvero l'aggiunta di certificati), è fondamentale che la connettività interrotta accetti tre certificati CA radice:

Al momento, il server flessibile di Database di Azure per PostgreSQL non supporta l'autenticazione basata su certificati.

Testare i certificati client connettendosi con psql negli scenari di aggiunta di certificati

È possibile usare la riga di comando psql dal client per testare la connettività al server negli scenari di aggiunta del certificato:


$ psql "host=hostname.postgres.database.azure.com port=5432 user=myuser dbname=mydatabase sslmode=verify-full sslcert=client.crt sslkey=client.key sslrootcert=ca.crt"

Per altre informazioni sui parametri SSL e certificato, vedere la documentazione di psql.

Testare la connettività TLS/SSL

Prima di provare ad accedere al server abilitato per SSL da un'applicazione client, assicurarsi di potervi accedere tramite psql. Se è stata stabilita una connessione SSL, verrà visualizzato un output simile all'esempio seguente:

psql (14.5)connessione SSL (protocollo: TLSv1.2, crittografia: ECDHE-RSA-AES256-GCM-SHA384, bit: 256, compressione: off)tipo "help" per assistenza.

È anche possibile caricare l'estensione sslinfo e quindi chiamare la funzione ssl_is_used() per determinare se SSL sia in uso. La funzione restituisce t se la connessione usa SSL. In caso contrario, viene restituito f.

Pacchetti di crittografia

Una suite di crittografia è un set di algoritmi crittografici. I protocolli TLS/SSL usano algoritmi di una suite di crittografia per creare chiavi e crittografare le informazioni.

Una pacchetto di crittografia viene visualizzata come una lunga stringa di informazioni apparentemente casuali, ma ogni segmento di tale stringa contiene informazioni essenziali. In genere, questa stringa di dati include diversi componenti chiave:

  • Protocollo (ovvero TLS 1.2 o TLS 1.3)
  • Algoritmo di scambio delle chiavi o contratto
  • Algoritmo di firma digitale (autenticazione)
  • Algoritmo di crittografia di massa
  • Algoritmo di Message Authentication Code (MAC)

Versioni diverse di TLS/SSL supportano suite di crittografia diverse. I pacchetti di crittografia di TLS 1.2 non possono essere negoziati con connessioni TLS 1.3 e viceversa.

Al momento, il server flessibile di Database di Azure per PostgreSQL supporta molte suite di crittografia con la versione del protocollo TLS 1.2 che rientra nella categoria HIGH:!aNULL .

Risolvere gli errori di connettività TLS/SSL

  1. Il primo passaggio per risolvere i problemi di compatibilità delle versioni del protocollo TLS/SSL consiste nell'identificare i messaggi di errore visualizzati dagli utenti durante il tentativo di accesso a Database di Azure per PostgreSQL - Server flessibile nella crittografia TLS dal client. A seconda dell'applicazione e della piattaforma, i messaggi di errore potrebbero differire. In molti casi, indicano chiaramente il problema sottostante.

  2. Per essere certi della compatibilità della versione del protocollo TLS/SSL, è necessario controllare la configurazione TLS/SSL del server di database e del client dell'applicazione per assicurarsi che supportino le versioni compatibili e i pacchetti di crittografia.

  3. Analizzare eventuali discrepanze o lacune tra il server di database e le versioni TLS/SSL del client e i pacchetti di crittografia. Provare a risolverli abilitando o disabilitando determinate opzioni, aggiornando o eseguendo il downgrade del software o modificando certificati o chiavi. Ad esempio, potrebbe essere necessario abilitare o disabilitare versioni TLS/SSL specifiche nel server o nel client, a seconda dei requisiti di sicurezza e compatibilità. Ad esempio, potrebbe essere necessario disabilitare TLS 1.0 e TLS 1.1, considerati non sicuri e deprecati, e abilitare TLS 1.2 e TLS 1.3, più sicuri e moderni.

  4. Il certificato più recente rilasciato con Microsoft RSA Root CA 2017 ha un livello intermedio nella catena con firma incrociata da Digicert Global Root G2 CA. Alcune delle librerie client Postgres, mentre le impostazioni sslmode=verify-full o sslmode=verify-ca sono in uso, potrebbero riscontrare errori di connessione con certificati CA radice firmati con certificati intermedi. Il risultato è percorsi di attendibilità alternativi.

    Per risolvere questi problemi, aggiungere tutti e tre i certificati necessari all'archivio certificati client o specificare in modo esplicito il parametro sslrootcert. In alternativa, impostare la variabile di ambiente PGSSLROOTCERT al percorso locale in cui viene inserito il certificato CA radice Microsoft RSA 2017, dal valore predefinito di %APPDATA%\postgresql\root.crt.

Contenuti correlati