Nessun risultato. Prova con un altro termine.
Guide
Notizie
Software
Tutorial
  • Lezione 44 di 58
  • livello intermedio
Indice lezioni

Criptare le comunicazioni tra i nodi del cluster

Mettere in sicurezza le comunicazioni tra i nodi di uno stesso cluster MySQL, cifrando i messaggi scambiati: ecco alcuni accorgimenti utili.
Mettere in sicurezza le comunicazioni tra i nodi di uno stesso cluster MySQL, cifrando i messaggi scambiati: ecco alcuni accorgimenti utili.
Link copiato negli appunti

Gli esempi che abbiamo visto finora consideravano la comunicazione tra server senza preoccuparsi della relativa sicurezza, aspetto che necessita di debita considerazione.

Nella lezione relativa alle repliche semplici abbiamo visto come utilizzare dei tunnel SSH per ottenere una comunicazione privata tra le macchine attive nella replica. Benché questa tecnica sia applicabile teoricamente anche al caso dei cluster Galera, la sua applicazione reale è resa difficoltosa dalla necessità di conoscere preventivamente gli indirizzi IP dei singoli nodi. Ma come abbiamo visto, un cluster può essere composto anche da un numero consistente di macchine.

L'alternativa quindi è utilizzare la comunicazione protetta da certificati SSL. MySQL supporta tale funzionalità su tre diversi tipi di comunicazioni: comunicazioni tra server e client, trasferimenti SST di cui abbiamo visto il significato nella lezione precedente, e trasferimenti di dati replica durante il funzionamento del cluster. In ognuno di questi utilizzi dovremo fare i conti con tre diversi certificati:

  • certificato CA, cioè quello dell'autorità che ha firmato il certificato (nei nostri esempi, cacert.pem);
  • cert, cioè il certificato pubblico (cert.pem);
  • key, cioè la chiave privata del certificato che serve ad eseguire le operazioni di criptaggio e decriptaggio(key.pem),

Per utilizzare i certificati SSL nella replica dei dati all'interno del cluster, è necessario impostare le seguenti opzioni all'interno della direttiva wsrep_provider_options, come visto in precedenza:

socket.ssl_key=/path/key.pem;
socket.ssl_cert=/path/cert.pem;
socket.ssl_ca=/path/cacert.pem

Questa impostazione deve essere applicata a tutti i nodi presenti nel cluster per essere valida, perché l'intero cluster deve essere coerente nel sistema utilizzato per la replica. Allo stesso modo è necessario applicare a tutti i nodi la stessa impostazione per i trasferimenti SST. Le possibilità che abbiamo, se vogliamo usare il criptaggio dei dati con certificati SSL, sono xtrabackup come metodo di trasferimento fisico e mysqldump come metodo logico.

Per xtrabackup è sufficiente aggiungere una sezione [sst] al file di configurazione di MySQL, indicando queste opzioni:

encrypt = 3
tca = /path/cacert.pem
tkey = /path/key.pem
tcert = /path/cert.pem

I certificati indicati possono essere gli stessi utilizzati per la replica dei dati all'interno del cluster (scelta consigliata) oppure no, ma in questo caso l'intero set deve essere utilizzato tale e quale su ogni macchina del cluster. Inoltre, il metodo SST deve essere impostato tramite la direttiva wsrep_sst_method (come visto nella lezione precedente) su xtrabackup-v2 e non xtrabackup, proprio per poter utilizzare i certificati SSL altrimenti non supportati.

L'utilizzo di mysqldump, invece, necessita degli stessi passaggi richiesti per attivare il criptaggio dei dati tra client e server e cioè aggiungere il riferimento ai certificati nelle sezioni [mysqld] e [client]:

[mysqld]
ssl-ca = /path/cacert.pem
ssl-key = /path/key.pem
ssl-cert = /path/cert.pem
# MySQL Client Configuration
[client]
ssl-ca = /path/cacert.pem
ssl-key = /path/key.pem
ssl-cert = /path/cert.pem

Infine è necessario impostare l'utente utilizzato per la replica, quello specificato con la direttiva wsrep_sst_auth, in modo che sia richiesto l'utilizzo dei certificati ssl.

Se il cluster inizialmente non prevedeva l'utilizzo di certificati, come negli esempi delle lezioni passate, e questi sono stati aggiunti in un secondo momento, è necessario riavviare l'intero cluster.

Ti consigliamo anche