Share via

Proteggere la connettività con TLS e SSL in Database di Azure per PostgreSQL - Server flessibile

  • Articolo

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

Database di Azure per PostgreSQL server flessibile impone la connessione delle applicazioni client a Database di Azure per PostgreSQL server flessibile 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 creato da Netscape Communications Corp. Secure Sockets Layer mostra e lo ha regolarmente sostituito, tuttavia i termini SSL o SSL/TLS sono ancora talvolta usati in modo intercambiabile. TLS è costituito da due livelli: il record TLS mostra e lo show dell'handshake TLS. Il record show offre la sicurezza dell'associazione, mentre lo show dell'handshake consente al server e al cliente di affermarsi l'uno all'altro e di coordinare le valutazioni della crittografia e le chiavi crittografiche prima che vengano scambiate informazioni.

Diagramma che mostra la tipica sequenza di handshake TLS 1.2.

Il diagramma precedente mostra la tipica sequenza di handshake TLS 1.2, costituita da quanto segue:

  1. Il client inizia inviando un messaggio denominato ClientHello, che esprime essenzialmente la volontà di comunicare tramite TLS 1.2 con un set di pacchetti di crittografia supportati dal client
  2. Il server riceve le risposte e con un serverHello che accetta la comunicazione con il client tramite TLS 1.2 usando una suite di crittografia specifica
  3. Insieme a tale condivisione chiave, il server invia la condivisione della chiave. Le specifiche di questa condivisione chiave cambiano in base alla suite di crittografia selezionata. Il dettaglio importante da notare è che per il client e il server accettare una chiave crittografica, devono ricevere la parte dell'altro o condividere.
  4. Il server invia il certificato (firmato dalla CA) e una firma in parti di ClientHello e ServerHello, inclusa la condivisione della chiave, in modo che il client sappia che sono autenticati.
  5. Dopo che il client riceve correttamente i dati indicati in precedenza e quindi genera la propria condivisione di chiavi, la combina con la condivisione chiave server e quindi genera le chiavi di crittografia per la sessione.
  6. Come passaggi finali, il client invia al server la condivisione della chiave, abilita la crittografia e invia un messaggio Completato (che è un hash di una trascrizione di ciò che è successo finora). Il server esegue la stessa operazione: combina le condivisioni chiave per ottenere la chiave e invia il proprio messaggio Completato.
  7. In quel momento i dati dell'applicazione possono essere inviati crittografati sulla connessione.

Catene di certificati

Una catena di certificati è un elenco ordinato di certificati, che contiene certificati SSL/TLS e autorità di certificazione (CA), che consente al ricevitore di verificare che il mittente e tutte le CA siano attendibili. La catena o il percorso inizia con il certificato SSL/TLS e ogni certificato nella catena è firmato dall'entità identificata dal certificato successivo nella catena. La catena termina con un certificato CA radice. Il certificato CA radice è sempre firmato dall'autorità di certificazione (CA) stessa. Le firme di tutti i certificati nella catena devono essere verificate fino al certificato CA radice. Qualsiasi certificato che si trova tra il certificato SSL/TLS e il certificato CA radice nella catena viene chiamato certificato intermedio.

Versioni di TLS

Esistono diverse entità governative in tutto il mondo che mantengono le linee guida per TLS in relazione alla sicurezza di rete, tra cui il Dipartimento della salute e i servizi umani (HHS) o il National Institute of Standards and Technology (NIST) nel Stati Uniti. Il livello di sicurezza fornito da TLS è più interessato dalla versione del protocollo TLS e dalle suite di crittografia supportate. Una suite di crittografia è un set di algoritmi, tra cui una crittografia, un algoritmo di scambio di chiavi e un algoritmo hash, che vengono usati insieme per stabilire una connessione TLS sicura. La maggior parte dei client e dei server TLS supporta più alternative, quindi devono negoziare quando stabiliscono una connessione sicura per selezionare una versione e una suite di crittografia TLS comuni.

Database di Azure per PostgreSQL supporta TLS versione 1.2 e successive. 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 precedenti del protocollo TLS, ad esempio TLS 1.0 e TLS 1.1, vengono negate per impostazione predefinita.

Nota

I certificati SSL e TLS certificano che la connessione è protetta con protocolli di crittografia all'avanguardia. Crittografando la connessione in transito, si impedisce l'accesso non autorizzato ai dati durante il transito. Per questo motivo è consigliabile usare le versioni più recenti di TLS per crittografare le connessioni a Database di Azure per PostgreSQL server flessibile.
Anche se non è consigliabile, se necessario, è possibile disabilitare TLS\SSL per le connessioni a Database di Azure per PostgreSQL server flessibile aggiornando il parametro del server require_secure_transport su OFF. È anche possibile impostare la versione tls impostando ssl_min_protocol_version e ssl_max_protocol_version parametri del server.

L'autenticazione del certificato viene eseguita usando i certificati client SSL per l'autenticazione. In questo scenario, il server PostgreSQL confronta l'attributo CN (common name) del certificato client presentato, rispetto all'utente del database richiesto. Database di Azure per PostgreSQL server flessibile non supporta attualmente l'autenticazione basata su certificati SSL.

Nota

Database di Azure per PostgreSQL: al momento il server flessibile non supporta i certificati SSL\TLS personalizzati.

Per determinare lo stato corrente della connessione TLS\SSL, è possibile caricare l'estensione sslinfo e quindi chiamare la ssl_is_used() funzione per determinare se viene usato SSL. La funzione restituisce t se la connessione usa SSL; in caso contrario, restituisce f. È anche possibile raccogliere tutte le informazioni sull'utilizzo SSL dell'istanza del server flessibile Database di Azure per PostgreSQL tramite 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 , ad esempio:

openssl s_client -connect localhost:5432 -starttls postgres

Questo comando stampa numerose informazioni sul protocollo di basso livello, tra cui la versione TLS, la crittografia e così via. È necessario usare l'opzione -starttls postgres oppure questo comando segnala che non è in uso ALCUN SSL. L'uso di questo comando richiede almeno OpenSSL 1.1.1.

Nota

Per applicare la versione più recente di TLS più sicura per la protezione della connettività dal client al server flessibile Database di Azure per PostgreSQL impostare ssl_min_protocol_version su 1.3. Ciò richiederebbe ai client che si connettono all'istanza del server flessibile di Database di Azure per PostgreSQL di usare questa versione del protocollo solo per comunicare in modo sicuro. Tuttavia, i client meno recenti, poiché non supportano questa versione, potrebbero non essere in grado di comunicare con il server.

Configurazione di SSL nel client

Per impostazione predefinita, PostgreSQL non esegue alcuna verifica del certificato del server. Ciò significa che è possibile eseguire lo spoofing dell'identità del server (ad esempio modificando un record DNS o prendendo l'indirizzo IP del server) senza che il client sappia. Tutte le opzioni SSL comportano un sovraccarico sotto forma di crittografia e scambio di chiavi, quindi c'è un compromesso che deve essere fatto tra prestazioni e sicurezza. Per evitare lo spoofing, è necessario usare la verifica del certificato SSL nel client. Esistono molti parametri di connessione per la configurazione del client per SSL. Alcuni aspetti importanti sono:

  1. ssl. Connessione tramite SSL. Questa proprietà non richiede un valore associato. La semplice presenza di essa specifica una connessione SSL. Tuttavia, per la compatibilità con le versioni future, è preferibile usare il valore "true". In questa modalità, quando si stabilisce una connessione SSL, il driver client convalida l'identità del server impedendo attacchi "man in the middle". A tale scopo, verificare che il certificato del server sia firmato da un'autorità attendibile e che l'host a cui ci si connette sia uguale al nome host nel certificato.
  2. sslmode. Se è necessaria la crittografia e si vuole che la connessione non riesca se non può essere crittografata, impostare sslmode=require. Ciò garantisce che il server sia configurato per accettare connessioni SSL per questo indirizzo Host/IP e che il server riconosca il certificato client. In altre parole, se il server non accetta connessioni SSL o il certificato client non viene riconosciuto, la connessione avrà esito negativo. Tabella seguente elencare i valori per questa impostazione:
SSL Mode (Modalità SSL) Spiegazione
disable La crittografia non viene usata
allow La crittografia viene usata se le impostazioni del server f richiedono\imponino
Preferire La crittografia viene usata se le impostazioni del server lo consentono
require Viene usata la crittografia. Ciò garantisce che il server sia configurato per accettare connessioni SSL per questo indirizzo IP host e che il server riconosca il certificato client.
verify-ca Viene usata la crittografia. Verificare inoltre la firma del certificato del server in base al certificato archiviato nel client
verify-full Viene usata la crittografia. Verificare inoltre la firma del certificato del server e il nome host sul certificato archiviato nel client

La modalità sslmode predefinita usata è diversa tra i client basati su libpq (ad esempio psql) e JDBC. Per impostazione predefinita , i client basati su libpq preferiscono e i client JDBC vengono predefinito per la verifica completa.

  1. sslcert, sslkey e sslrootcert. Questi parametri possono eseguire l'override del percorso predefinito del certificato client, della chiave client PKCS-8 e del certificato radice. Queste impostazioni predefinite sono /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8 e /defaultdir/root.crt rispettivamente dove defaultdir è ${user.home}/.postgresql/ in *nix systems e %appdata%/postgresql/ in Windows.

Le autorità di certificazione sono le istituzioni responsabili del rilascio dei certificati. Un'autorità di certificazione attendibile è un'entità che ha diritto a verificare che qualcuno sia chi dice 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 vengono forniti con un set di ca attendibili.

Nota

L'uso di verify-ca e delle impostazioni di configurazione sslmode verify-full può essere noto anche come aggiunta 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. Importante da ricordare, potrebbe essere necessario aggiornare periodicamente i certificati archiviati dal client quando le autorità di certificazione cambiano o scadono sui certificati del server PostgreSQL. Per determinare se si stanno aggiungendo CA, vedere Aggiunta di certificati e servizi di Azure.

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

Nota

Per i client che usano le impostazioni di configurazione verify-ca e verify-full sslmode, ad esempio l'aggiunta di certificati, devono accettare entrambi i certificati CA radice:

Download dei certificati CA radice e aggiornamento dei client dell'applicazione negli scenari di aggiunta di certificati

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

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

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

Informazioni dettagliate sull'aggiornamento degli archivi certificati delle applicazioni client con nuovi certificati CA radice sono state documentate in questo documento di procedura.

Importante

Alcune delle librerie client Postgres, mentre si usano sslmode=verify-full , possono verificarsi errori di connessione con certificati CA radice con certificati con firma incrociata con certificati intermedi, generando percorsi di attendibilità alternativi. In questo caso, è consigliabile specificare in modo esplicito il parametro sslrootcert , illustrato in precedenza o impostare la variabile di ambiente PGSSLROOTCERT sul percorso locale in cui viene inserito il certificato CA radice MICROSOFT RSA 2017, dal valore predefinito %APPDATA%\postgresql\root.crt.

Eseguire la lettura di repliche con scenari di aggiunta di certificati

Con la migrazione della CA radice a Microsoft RSA Root Certificate Authority 2017 , è possibile che le repliche appena create siano in un certificato CA radice più recente rispetto al server primario creato in precedenza. Pertanto, per i client che usano le impostazioni di configurazione verify-ca e verify-full sslmode, ovvero l'aggiunta di certificati, è fondamentale per la connettività interrotta per accettare entrambi i certificati CA radice:

Nota

Database di Azure per PostgreSQL: il server flessibile non supporta attualmente l'autenticazione basata su certificati.

Test dei certificati client connettendosi con psql negli scenari di aggiunta del certificato

È possibile usare la riga di comando psql dal client per testare la connettività al server negli scenari di aggiunta del certificato, come illustrato nell'esempio seguente:


$ 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, è possibile seguire la documentazione di psql.

Test della Connessione ivity SSL/TLS

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

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

È anche 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, restituisce f.

Suite di cifratura

Una suite di cifratura è un insieme di algoritmi crittografici. I protocolli TLS/SSL usano gli algoritmi di un pacchetto di crittografia per creare chiavi e crittografare informazioni. Una suite 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 è costituita da diversi componenti chiave:

  • Protocollo (ovvero TLS 1.2 o TLS 1.3)
  • Algoritmo di scambio di chiavi o contratto
  • Algoritmo di firma digitale (autenticazione)
  • Algoritmo di crittografia bulk
  • Algoritmo del codice di autenticazione dei messaggi (MAC)

Versioni diverse di SSL/TLS supportano suite di crittografia diverse. I pacchetti di crittografia TLS 1.2 non possono essere negoziati con connessioni TLS 1.3 e viceversa. A partire da questa volta Database di Azure per PostgreSQL server flessibile supporta molte suite di crittografia con versione del protocollo TLS 1.2 che rientrano nella categoria HIGH:!aNULL.

Risoluzione degli errori di connettività SSL\TLS

  1. Il primo passaggio per risolvere i problemi di compatibilità della versione del protocollo SSL/TLS consiste nell'identificare i messaggi di errore visualizzati dall'utente o dagli utenti durante il tentativo di accedere al server flessibile Database di Azure per PostgreSQL - Server flessibile nella crittografia TLS dal client. A seconda dell'applicazione e della piattaforma, i messaggi di errore potrebbero essere diversi, ma in molti casi puntano al problema sottostante.
  2. Per essere certi della compatibilità della versione del protocollo SSL/TLS, è necessario controllare la configurazione SSL/TLS del server di database e del client dell'applicazione per assicurarsi che supportino versioni compatibili e pacchetti di crittografia.
  3. Analizzare eventuali discrepanze o lacune tra il server di database e le versioni SSL/TLS del client e i pacchetti di crittografia e 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 SSL/TLS specifiche nel server o nel client a seconda dei requisiti di sicurezza e compatibilità, ad esempio disabilitando TLS 1.0 e TLS 1.1, considerati non sicuri e deprecati e abilitando TLS 1.2 e TLS 1.3, che sono più sicuri e moderni.

Contenuto correlato