La protezione dei tuoi dati è una delle attività più importanti a cui dovremmo dare la priorità. L'emergere di normative che richiedono la conformità alla sicurezza come GDPR, HIPAA, PCI DSS o PHI richiede che i tuoi dati vengano archiviati in modo sicuro o trasmessi via cavo.
In ClusterControl, apprezziamo l'importanza della sicurezza e offriamo una serie di funzionalità per proteggere l'accesso al database e ai dati archiviati. Uno di questi è la protezione dei backup del database, sia a riposo che in transito. In transito è quando il backup viene trasferito tramite Internet o rete dall'origine alla sua destinazione, mentre inattivo è quando i dati vengono archiviati su una memoria permanente. In questo blog ti mostreremo come utilizzare ClusterControl per crittografare i dati di backup inattivi e in transito.
Crittografia in transito
Quando si gestiscono i backup tramite ClusterControl, l'utilizzo di mysqldump o Percona Xtrabackup/Mariabackup viene gestito per impostazione predefinita senza crittografia quando trasmessi via cavo. Tuttavia, l'utilizzo di TLS/SSL per la crittografia della trasmissione dei dati è supportato da MySQL/MariaDB/Percona Server, così come Percona Xtrabackup che offre opzioni SSL quando si richiama il comando.
ClusterControl abilita SSL per impostazione predefinita quando si distribuisce un cluster, ma non ha il controllo per passare istantaneamente e rendere i dati crittografati via cavo durante la creazione del backup. Puoi consultare i nostri blog precedenti per l'approccio manuale utilizzando ClusterControl durante la creazione del tuo cluster o utilizzando il vecchio metodo per impostare manualmente TLS/SSL in MySQL.
In ClusterControl, quando si distribuisce un cluster, è possibile controllare la scheda di sicurezza o questa icona 
.
Facendo clic su Il pulsante 
ti consentirà di sostituire il certificato attualmente utilizzato o distribuito da ClusterControl durante la distribuzione del tuo nuovo provisioning grappolo. Puoi controllare questo blog "Aggiornato:diventa un DBA ClusterControl - Gestione delle chiavi SSL e crittografia dei dati MySQL in transito" per il quale abbiamo mostrato come gestiamo le chiavi. Fondamentalmente, puoi passare attraverso la navigazione sul lato sinistro di ClusterControl e fare clic su "Gestione chiavi".
Di seguito è riportato un esempio di gestione delle chiavi in cui è possibile creare e importare le chiavi esistenti.
Quando crei un backup usando mysqldump come backup logico, per crittografare i tuoi dati, assicurati di avere le tue opzioni SSL impostate di conseguenza.
Cosa c'è dopo?
Dal momento che abbiamo i nostri certificati creati, dobbiamo abilitare e configurare SSL di conseguenza. Per garantire ciò, puoi controllare tramite ClusterControl o il prompt dei comandi mysql. Vedi le immagini sotto:
oppure puoi controllare anche nella scheda Performance e fare clic su Variabili DB come mostrato di seguito:
Tieni presente che potrebbe essere necessario del tempo per compilare in Performance -> Variabili DB. Quindi, se vuoi controllare manualmente, puoi usare il prompt dei comandi di mysql proprio come di seguito:
La definizione di ssl_cipher può aggiungere un ulteriore rafforzamento della sicurezza. C'è un elenco di suite di crittografia se esegui SHOW GLOBAL STATUS LIKE 'Ssl_cipher_list'\G o controlla qui. Una suite di crittografia è una combinazione di algoritmi di autenticazione, crittografia e codice di autenticazione del messaggio (MAC). Questi vengono utilizzati durante la negoziazione delle impostazioni di sicurezza per una connessione TLS/SSL e per il trasferimento sicuro dei dati.
Poiché ClusterControl eseguirà mysqldump localmente in quell'host, aggiungendo i seguenti parametri (vedi sotto) nel tuo file di configurazione MySQL (/etc/my.cnf, /etc/mysql/my.cnf, /usr/etc/my.cnf, ~ /.my.cnf) crittograferà tutte le azioni per il dump SQL. Vedi sotto:
[mysqldump]
socket=/var/lib/mysql/mysql.sock
max_allowed_packet = 512M
host=127.0.0.1
ssl-cert=/var/lib/mysql/client-cert.pem
ssl-key=/var/lib/mysql/client-key.pemPuoi provare a monitorare utilizzando tcpdump e puoi vedere di seguito rispetto a un livello non crittografato o crittografato utilizzando TLS.
Con TLS/SSL:
Senza TLS/SSL:
Quando si utilizza Percona XtraBackup o Mariabackup in ClusterControl, non è disponibile il supporto TLS/SSL a partire da questo momento in cui il backup viene trasmesso sulla rete. Utilizza socat che fondamentalmente apre una porta in un altro nodo come mezzo di comunicazione.
ad es.
[21:24:46]: 192.168.10.20: Launching ( ulimit -n 256000 && LC_ALL=C /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --galera-info --parallel 1 --stream=xbstream --no-timestamp | gzip -6 - | socat - TCP4:192.168.10.200:9999 ) 2>&1.
[21:24:46]: 192.168.10.20: The xtrabackup version is 2.4.12 / 2004012.
[21:24:46]: 192.168.10.20:3306: Checking xtrabackup version.
[21:24:46]: 192.168.10.20: Streaming backup to 192.168.10.200
[21:24:46]: 192.168.10.200: Netcat started, error log is in '192.168.10.200:/tmp/netcat.log'.
[21:24:43]: 192.168.10.200: Starting socat -u tcp-listen:9999,reuseaddr stdout > /home/vagrant/backups/BACKUP-71/backup-full-2018-11-12_132443.xbstream.gz 2>/tmp/netcat.log.Se hai bisogno di un livello sicuro durante il trasporto, puoi farlo manualmente usando le opzioni --ssl* durante l'invocazione del comando. Consulta qui il manuale Percona XtraBackup per maggiori informazioni. Ti consigliamo comunque di ottenere il tuo certificato/chiave da un'autorità di certificazione registrata.
In alternativa, utilizzando ClusterControl, puoi crittografare i tuoi dati prima di inviarli tramite la rete, i pacchetti inviati non sono dati grezzi ma crittografati. Anche se la crittografia si basa su a riposo, ne parleremo nella prossima sezione.
Crittografia a riposo
In ClusterControl, durante la creazione del backup, hai la possibilità di crittografare i tuoi dati. Vedi sotto:
Una volta crittografato, ClusterControl utilizzerà "Advance Encryption Standard" AES-256-CBC. Vedi il registro di esempio di seguito:
[22:12:49]: 192.168.10.30: Launching ( ulimit -n 256000 && LC_ALL=C /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --galera-info --parallel 1 --stream=xbstream --no-timestamp | gzip -6 - | openssl enc -aes-256-cbc -pass file:/var/tmp/cmon-002471-32758-24c456ca6b087837.tmp | socat - TCP4:192.168.10.200:9999 ) 2>&1.Se stai archiviando il backup nel cloud, ad esempio con AWS S3, S3 offre tre diverse modalità di crittografia lato server (SSE). Questi sono SSE-S3, SSE-C o SSE-KMS. Amazon ha ottime funzionalità SSE da offrire che gestiscono la crittografia dei dati inattivi. Puoi iniziare qui che affronta il modo in cui S3 utilizza AWS KMS. Se stai spostando il backup su un volume o su uno storage basato su blocchi, AWS dispone anche della crittografia EBS che utilizza AWS KMS. Puoi controllare qui per maggiori informazioni al riguardo.
Microsoft Azure ha funzionalità interessanti anche per la gestione dei dati inattivi. Consulta la pagina "Crittografia del servizio di archiviazione di Azure per i dati inattivi". Azure gestisce le chiavi nel proprio Azure Key Vault, come AWS KMS. Per la crittografia di Google per i dati inattivi, puoi controllare qui.
Quando si archiviano i backup dei dati in locale, è possibile utilizzare LUKS (Linux Unified Key Setup) con una combinazione di crypt o dmcrypt. Non ne parlerò in questo blog, ma questa è una buona fonte da consultare:MySQL Encryption at Rest – Part 1 (LUKS). Per ulteriori informazioni sulla crittografia del disco, questa pagina ArchLinux "Crittografia del disco" è un'ottima fonte per iniziare.
Ancora più importante, mentre i tuoi dati sono stati crittografati a riposo e in transito, verifica sempre che il tuo backup funzioni. Un backup che non è stato testato non è un backup se non funziona quando è necessario il ripristino. Anche la memorizzazione del backup mentre è crittografata deve essere decifrata senza problemi, quindi le tue chiavi devono essere archiviate in modo privato e nel modo più sicuro possibile. Inoltre, l'aggiunta della crittografia ai tuoi dati, come la crittografia InnoDB o SST (per Galera), aggiunge maggiore sicurezza, ma non li tratteremo in questo blog.
Conclusione
La crittografia dei dati di backup inattivi e in transito sono componenti vitali per la conformità a PHI, HIPAA, PCI DSS o GDPR, per garantire che i dati sensibili trasmessi via cavo o salvati su disco non siano leggibili da qualsiasi utente o applicazione senza una chiave valida. Alcune normative di conformità come PCI DSS e HIPAA richiedono che i dati inattivi siano crittografati durante l'intero ciclo di vita dei dati.
Qui mostriamo come ClusterControl offre queste opzioni all'utente finale. Tuttavia, la conformità è un compito enorme, che tocca molte aree diverse. Anche i regolamenti vengono aggiornati su base frequente e anche i processi/gli strumenti devono essere aggiornati di conseguenza. Miglioriamo continuamente diverse aree in ClusterControl per facilitare la conformità. Ci piacerebbe sentire i tuoi pensieri su questo e su come possiamo migliorare.
