Mysql
 sql >> Database >  >> RDS >> Mysql

Come proteggere il cluster Galera - 8 suggerimenti

In quanto sistema di database distribuito, Galera Cluster richiede misure di sicurezza aggiuntive rispetto a un database centralizzato. I dati sono distribuiti su più server o forse anche data center. Con una significativa comunicazione di dati che avviene tra i nodi, può esserci un'esposizione significativa se non vengono adottate le misure di sicurezza appropriate.

In questo post del blog, esamineremo alcuni suggerimenti su come proteggere il nostro Cluster Galera. Tieni presente che questo blog si basa sul nostro precedente post sul blog - Come proteggere i database open source con ClusterControl.

Gruppo firewall e sicurezza

Le seguenti porte sono molto importanti per un Cluster Galera:

  • 3306 - MySQL
  • 4567 - Comunicazione e replica Galera
  • 4568 - Galera IST
  • 4444 - Galera SST

Dalla rete esterna, si consiglia di aprire l'accesso solo alla porta MySQL 3306. Le altre tre porte possono essere chiuse dalla rete esterna e consentono loro solo l'accesso interno tra i nodi Galera. Se stai eseguendo un proxy inverso seduto davanti ai nodi Galera, ad esempio HAProxy, puoi bloccare la porta MySQL dall'accesso pubblico. Assicurarsi inoltre che la porta di monitoraggio per lo script di monitoraggio HAProxy sia aperta. La porta predefinita è 9200 sul nodo Galera.

Il diagramma seguente illustra la nostra configurazione di esempio su un cluster Galera a tre nodi, con un HAProxy rivolto verso la rete pubblica con le relative porte:

Sulla base del diagramma precedente, i comandi di iptables per i nodi del database sono:

$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 3306 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 4444 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dports 4567:4568 -j ACCEPT
$ iptables -A INPUT -p tcp -s 10.0.0.0/24 --dport 9200 -j ACCEPT

Durante il bilanciamento del carico:

$ iptables -A INPUT -p tcp --dport 3307 -j ACCEPT

Assicurati di terminare le regole del firewall con Nega tutto, in modo che sia consentito solo il traffico definito nelle regole di eccezione. Puoi essere più severo ed estendere i comandi per seguire la tua politica di sicurezza, ad esempio aggiungendo l'interfaccia di rete, l'indirizzo di destinazione, l'indirizzo di origine, lo stato della connessione e altro.

Crittografia client-server MySQL

MySQL supporta la crittografia tra il client e il server. Per prima cosa dobbiamo generare il certificato. Una volta configurato, puoi imporre agli account utente di specificare determinate opzioni per la connessione con la crittografia a un server MySQL.

I passaggi richiedono di:

  1. Crea una chiave per l'autorità di certificazione (ca-key.pem)
  2. Genera un certificato CA autofirmato (ca-cert.pem)
  3. Crea una chiave per il certificato del server (server-key.pem)
  4. Genera un certificato per il server e firmalo con ca-key.pem (server-cert.pem)
  5. Crea una chiave per il certificato client (client-key.pem)
  6. Genera un certificato per il client e firmalo con ca-key.pem (client-cert.pem)

Fai sempre attenzione con la chiave privata della CA (ca-key.pem):chiunque abbia accesso ad essa può utilizzarla per generare certificati client o server aggiuntivi che saranno accettati come legittimi quando la verifica della CA è abilitata. La conclusione è che tutte le chiavi devono essere mantenute discrete.

È quindi possibile aggiungere le variabili relative a SSL nella direttiva [mysqld], ad esempio:

ssl-ca=/etc/ssl/mysql/ca-cert.pem
ssl-cert=/etc/ssl/mysql/server-cert.pem
ssl-key=/etc/ssl/mysql/server-key.pem

Riavvia il server MySQL per caricare le modifiche. Quindi crea un utente con l'istruzione REQUIRE SSL, ad esempio:

mysql> GRANT ALL PRIVILEGES ON db1.* TO 'dbuser'@'192.168.1.100' IDENTIFIED BY 'mySecr3t' REQUIRE SSL;

L'utente creato con REQUIRE SSL verrà obbligato a connettersi con i file SSL client corretti (client-cert.pem, client-key.pem e ca-cert.pem).

Con ClusterControl, la crittografia SSL client-server può essere facilmente abilitata dall'interfaccia utente, utilizzando la funzione "Crea crittografia SSL".

Crittografia Galleria

Abilitare la crittografia per Galera significa che anche IST sarà crittografato perché la comunicazione avviene tramite lo stesso socket. SST, invece, deve essere configurato separatamente come mostrato nella sezione successiva. Tutti i nodi nel cluster devono essere abilitati con la crittografia SSL e non puoi avere una combinazione di nodi in cui alcuni hanno abilitato la crittografia SSL e altri no. Il momento migliore per configurarlo è quando si configura un nuovo cluster. Tuttavia, se è necessario aggiungerlo a un sistema di produzione in esecuzione, sfortunatamente sarà necessario riavviare il cluster e si verificheranno tempi di inattività.

Tutti i nodi Galera nel cluster devono utilizzare la stessa chiave, certificato e CA (opzionale). È inoltre possibile utilizzare la stessa chiave e certificato creati per la crittografia client-server MySQL o generare un nuovo set solo per questo scopo. Per attivare la crittografia all'interno di Galera, è necessario aggiungere l'opzione e il valore in wsrep_provider_options all'interno del file di configurazione MySQL su ciascun nodo Galera. Ad esempio, considera la seguente riga esistente per il nostro nodo Galera:

wsrep_provider_options = "gcache.size=512M; gmcast.segment=0;"

Aggiungi le relative variabili all'interno della virgoletta, delimitate da un punto e virgola:

wsrep_provider_options = "gcache.size=512M; gmcast.segment=0; socket.ssl_cert=/etc/mysql/cert.pem; socket.ssl_key=/etc/mysql/key.pem;"

Per ulteriori informazioni sui parametri relativi a SSL di Galera, vedere qui. Eseguire questa modifica su tutti i nodi. Quindi, arresta il cluster (un nodo alla volta) e avvia il bootstrap dall'ultimo nodo che si è arrestato. Puoi verificare se SSL è stato caricato correttamente esaminando il log degli errori di MySQL:

2018-01-19T01:15:30.155211Z 0 [Note] WSREP: gcomm: connecting to group 'my_wsrep_cluster', peer '192.168.10.61:,192.168.10.62:,192.168.10.63:'
2018-01-19T01:15:30.159654Z 0 [Note] WSREP: SSL handshake successful, remote endpoint ssl://192.168.10.62:53024 local endpoint ssl://192.168.10.62:4567 cipher: AES128-SHA compression:

Con ClusterControl, la crittografia Galera Replication può essere facilmente abilitata utilizzando la funzione "Crea crittografia Galera SSL".

Crittografia SST

Quando l'SST si verifica senza crittografia, la comunicazione dei dati viene esposta mentre il processo SST è in corso. SST è un processo completo di sincronizzazione dei dati da un donatore a un nodo joiner. Se un utente malintenzionato fosse in grado di "vedere" l'intera trasmissione dei dati, la persona otterrebbe un'istantanea completa del tuo database.

SST con crittografia è supportato solo per i metodi mysqldump e xtrabackup-v2. Per mysqldump, all'utente deve essere concesso "REQUIRE SSL" su tutti i nodi e la configurazione è simile alla crittografia SSL client-server MySQL standard (come descritto nella sezione precedente). Una volta attivata la crittografia client-server, crea un nuovo utente SST con SSL applicato:

mysql> GRANT ALL ON *.* TO 'sst_user'@'%' IDENTIFIED BY 'mypassword' REQUIRE SSL;

Per rsync, ti consigliamo di utilizzare galera-secure-rsync, uno script SST rsync protetto da SSL drop-in per Galera Cluster. Funziona quasi esattamente come wsrep_sst_rsync tranne per il fatto che protegge le comunicazioni effettive con SSL utilizzando socat. Genera la chiave client/server e i file di certificato richiesti, copiali su tutti i nodi e specifica "secure_rsync" come metodo SST all'interno del file di configurazione MySQL per attivarlo:

wsrep_sst_method=secure_rsync

Per xtrabackup, le seguenti opzioni di configurazione devono essere abilitate all'interno del file di configurazione MySQL nella direttiva [sst]:

[sst]
encrypt=4
ssl-ca=/path/to/ca-cert.pem
ssl-cert=/path/to/server-cert.pem
ssl-key=/path/to/server-key.pem

Il riavvio del database non è necessario. Se questo nodo viene selezionato da Galera come donatore, queste opzioni di configurazione verranno raccolte automaticamente quando Galera avvierà l'SST.

SELinux

Security-Enhanced Linux (SELinux) è un meccanismo di controllo degli accessi implementato nel kernel. Senza SELinux, per controllare l'accesso degli utenti ai file vengono utilizzati solo i metodi tradizionali di controllo degli accessi come i permessi dei file o ACL.

Per impostazione predefinita, con la modalità di esecuzione rigorosa abilitata, tutto viene negato e l'amministratore deve apportare una serie di criteri di eccezione agli elementi del sistema richiesti per funzionare. La disabilitazione completa di SELinux è diventata una pratica comune scadente per molte installazioni basate su RedHat al giorno d'oggi.

A seconda dei carichi di lavoro, dei modelli di utilizzo e dei processi, il modo migliore è creare il proprio modulo di policy SELinux su misura per il proprio ambiente. Quello che devi davvero fare è impostare SELinux in modalità permissiva (registrazione solo senza forzare) e attivare eventi che possono verificarsi su un nodo Galera per SELinux da registrare. Più è esteso, meglio è. Esempi di eventi come:

  • Nodo iniziale come donatore o partecipante
  • Riavvia il nodo per attivare IST
  • Utilizza diversi metodi SST
  • Esegui il backup e ripristina i database MySQL utilizzando mysqldump o xtrabackup
  • Abilita e disabilita i log binari

Un esempio è che se il nodo Galera è monitorato da ClusterControl e la funzione di monitoraggio delle query è abilitata, ClusterControl abiliterà/disabilita la variabile del registro delle query lente per acquisire le query a esecuzione lenta. Pertanto, vedrai il seguente rifiuto in audit.log:

$ grep -e denied audit/audit.log | grep -i mysql
type=AVC msg=audit(1516835039.802:37680): avc:  denied  { open } for  pid=71222 comm="mysqld" path="/var/log/mysql/mysql-slow.log" dev="dm-0" ino=35479360 scontext=system_u:system_r:mysqld_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file

L'idea è di consentire a tutti i possibili rifiuti di essere registrati nel registro di controllo, che in seguito può essere utilizzato per generare il modulo della politica utilizzando audit2allow prima di caricarlo in SELinux. Codership lo ha trattato in dettaglio nella pagina della documentazione, Configurazione di SELinux.

Account e privilegi SST

SST è un processo di sincronizzazione iniziale eseguito da Galera. Porta un nodo joiner aggiornato con il resto dei membri del cluster. Il processo fondamentalmente esporta i dati dal nodo donatore e li ripristina sul nodo joiner, prima che il joiner possa recuperare le restanti transazioni dalla coda (ovvero quelle avvenute durante il processo di sincronizzazione). Sono supportati tre metodi SST:

  • mysqldump
  • risincronizzazione
  • xtrabackup (o xtrabackup-v2)

Per l'utilizzo di mysqldump SST, sono richiesti i seguenti privilegi:

  • SELEZIONA, MOSTRA VISUALIZZA, TRIGGER, BLOCCA TABELLE, RICARICA, FILE

Non andremo oltre con mysqldump perché probabilmente non è usato spesso in produzione come metodo SST. Inoltre, è una procedura di blocco sul donatore. Rsync è solitamente una seconda scelta preferita dopo xtrabackup a causa di tempi di sincronizzazione più rapidi e meno soggetti a errori rispetto a mysqldump. L'autenticazione SST viene ignorata con rsync, quindi puoi saltare la configurazione dei privilegi dell'account SST se rsync è il metodo SST scelto.

Insieme a xtrabackup, sono consigliati i seguenti privilegi per le procedure di backup e ripristino standard basate sulla pagina della documentazione di Xtrabackup:

  • CREATE, CREATE TABLESPACE, EVENT, INSERT, LOCK TABLE, PROCESS, RELOAD, REPLICATION CLIENT, SELECT, SHOW VIEW, SUPER

Tuttavia, per l'utilizzo di SST di xtrabackup, contano solo i seguenti privilegi:

  • PROCESSO, RICARICA, REPLICA CLIENTE

Pertanto, l'istruzione GRANT per SST può essere ridotta a icona come:

mysql> GRANT PROCESS,RELOAD,REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost' IDENTIFIED BY '[email protected]@sTr0nG%%P4ssW0rD';

Quindi, configura wsrep_sst_auth di conseguenza all'interno del file di configurazione di MySQL:

wsrep_sst_auth = sstuser:[email protected]@sTr0nG%%P4ssW0rD

Concedi solo all'utente SST per localhost e usa una password complessa. Evitare di utilizzare l'utente root come account SST, perché esporrebbe la password di root all'interno del file di configurazione sotto questa variabile. Inoltre, la modifica o il ripristino della password di root di MySQL interromperebbe l'SST in futuro.

Rafforzamento della sicurezza di MySQL

Galera Cluster è un plug-in di replica multi-master per il motore di archiviazione InnoDB, che funziona su fork MySQL e MariaDB. Pertanto, le raccomandazioni standard per il rafforzamento della sicurezza di MySQL/MariaDB/InnoDB si applicano anche a Galera Cluster.

Questo argomento è stato trattato in numerosi post sul blog. Abbiamo anche trattato questo argomento nei seguenti post del blog:

  • Dieci suggerimenti su come ottenere la sicurezza MySQL e MariaDB
  • Suggerimenti e trucchi per ClusterControl:proteggere l'installazione di MySQL
  • Come proteggere i database open source con ClusterControl

I post del blog sopra riassumono la necessità di crittografare i dati inattivi e in transito, avere plug-in di controllo, linee guida generali sulla sicurezza, best practice per la sicurezza della rete e così via.

Utilizza un sistema di bilanciamento del carico

Esistono numerosi bilanciatori del carico del database (proxy inverso) che possono essere utilizzati insieme a Galera - HAProxy, ProxySQL e MariaDB MaxScale per nominarne alcuni. Puoi configurare un sistema di bilanciamento del carico per controllare l'accesso ai tuoi nodi Galera. È un ottimo modo per distribuire il carico di lavoro del database tra le istanze del database, oltre a limitare l'accesso, ad esempio, se si desidera portare offline un nodo per la manutenzione o se si desidera limitare il numero di connessioni aperte sui nodi Galera. Il sistema di bilanciamento del carico dovrebbe essere in grado di accodare le connessioni e quindi fornire una protezione da sovraccarico ai server di database.

ProxySQL, un potente proxy inverso del database che comprende MySQL e MariaDB, può essere esteso con molte utili funzioni di sicurezza come il firewall delle query, per bloccare le query dannose dal server del database. Il motore delle regole di query può anche essere utilizzato per riscrivere query errate in qualcosa di migliore/più sicuro o reindirizzarle a un altro server che può assorbire il carico senza influire su nessuno dei nodi Galera. MariaDB MaxScale è anche in grado di bloccare le query basate su espressioni regolari con il suo filtro Database Firewall.

Un altro vantaggio di avere un sistema di bilanciamento del carico per il tuo cluster Galera è la possibilità di ospitare un servizio dati senza esporre il livello del database alla rete pubblica. Il server proxy può essere utilizzato come bastion host per accedere ai nodi del database in una rete privata. Avendo il cluster di database isolato dal mondo esterno, hai rimosso uno degli importanti vettori di attacco.

Questo è tutto. Rimani sempre al sicuro e protetto.