Condividi tramite

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 - Il server flessibile applica 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 è stato creato 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 record TLS mostra e lo show dell'handshake TLS. Il record show fornisce la sicurezza dell'associazione. L'handshake show 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 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 chiave cambiano in base alla suite di crittografia selezionata. Affinché il client e il server accettino una chiave crittografica, devono ricevere la parte o condividere tra loro.
  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 chiave. In questo modo, il cliente sa che sono autenticati.
  5. Dopo che il client riceve correttamente i dati e quindi genera la propria condivisione di chiavi, 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 della chiave, abilita la crittografia e invia un Finished messaggio. Questo messaggio è 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 Finished messaggio.
  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 in tutto il mondo mantengono le linee guida per TLS per quanto riguarda la sicurezza di rete. Nell'Stati Uniti, queste organizzazioni includono il Dipartimento della Salute e dei Servizi Umani e il National Institute of Standards and Technology. 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 quando stabiliscono una connessione sicura per selezionare una versione comune di TLS e una suite di crittografia.

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.

Nota

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 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. È possibile aggiornare il parametro del require_secure_transport server a OFF. È anche possibile impostare la versione di TLS impostando ssl_min_protocol_version e ssl_max_protocol_version i 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 common name (CN) del certificato client presentato con l'utente del database richiesto.

Al momento, Database di Azure per PostgreSQL - Server flessibile non supporta:

Nota

Microsoft ha apportato modifiche ca radice per vari servizi di Azure, tra cui Database di Azure per PostgreSQL - Server flessibile. 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 SSL del server Database di Azure per PostgreSQL flessibile 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 il openssl comando direttamente:

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 tls più recente e sicura per la protezione della connettività dal client a Database di Azure per PostgreSQL - Server flessibile, impostare su ssl_min_protocol_version 1.3. Questa impostazione richiede ai client che si connettono al server flessibile Database di Azure per PostgreSQL di usare questa versione del protocollo solo 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 sappia. Tutte le opzioni SSL comportano un sovraccarico sotto forma di crittografia e scambio di chiavi, quindi viene effettuato 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 importanti sono:

  • ssl: connettersi 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 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 uguale al nome host nel certificato.

  • sslmode: se è necessaria la crittografia e si vuole che la connessione non riesca se non può essere crittografata, impostare sslmode=require. Questa impostazione garantisce che il server sia configurato per accettare connessioni SSL per questo indirizzo host/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 viene usata.
    allow La crittografia viene usata se le impostazioni del server richiedono o lo applicano.
    prefer La crittografia viene usata se le impostazioni del server lo consentono.
    require La crittografia viene usata. 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 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 /defaultdir/postgresql.crt, , /defaultdir/postgresql.pk8e /defaultdir/root.crt, rispettivamente, dove defaultdir si trova ${user.home}/.postgresql/ nei sistemi nix e %appdata%/postgresql/ in Windows.

Le autorità di certificazione sono le istituzioni responsabili del rilascio dei certificati. Un'autorità di certificazione attendibile è un'entità autorizzata 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 prevedono un set di CA attendibili.

L'uso verify-ca e verify-full sslmode le impostazioni di configurazione possono anche essere note come aggiunta di certificati. 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 verify-ca e verify-full sslmode le impostazioni di configurazione, 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 si usa l'impostazione sslmode=verify-full , potrebbero verificarsi 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 sslrootcert parametro . In alternativa, impostare la PGSSLROOTCERT variabile di ambiente 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 aggiunta di certificati

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 verify-ca e verify-full sslmode impostazioni di configurazione (ovvero l'aggiunta di certificati), è fondamentale che la connettività interrotta accetti tre certificati CA radice:

Al momento, Database di Azure per PostgreSQL - Il server flessibile 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 dal client per testare la psql 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 accedervi 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 ssl_is_used() funzione per determinare se viene usato SSL. La funzione restituisce t se la connessione usa SSL. In caso contrario, viene restituito f.

Pacchetti di crittografia

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 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 TLS 1.2 non possono essere negoziati con connessioni TLS 1.3 e viceversa.

Al momento, Database di Azure per PostgreSQL - Server flessibile 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à della versione del protocollo TLS/SSL consiste nell'identificare i messaggi di errore visualizzati dall'utente o dagli utenti quando tentano di accedere al server flessibile Database di Azure per PostgreSQL con crittografia TLS dal client. A seconda dell'applicazione e della piattaforma, i messaggi di errore potrebbero essere diversi. In molti casi, puntano al problema sottostante.

  2. Per essere certi della compatibilità della versione del protocollo TLS/SSL, controllare la configurazione TLS/SSL 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 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, che sono 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 si usano sslmode=verify-full o sslmode=verify-ca impostazioni, potrebbero verificarsi errori di connessione con certificati CA radice con certificati con firma incrociata 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 sslrootcert parametro . In alternativa, impostare la PGSSLROOTCERT variabile di ambiente sul percorso locale in cui viene inserito il certificato CA radice Microsoft RSA 2017, dal valore predefinito di %APPDATA%\postgresql\root.crt.

Contenuto correlato