La sicurezza dei dati è una priorità assoluta in questi giorni. A volte è imposto da normative esterne come PCI-DSS o HIPAA, a volte è perché tieni ai dati dei tuoi clienti e alla tua reputazione. Ci sono numerosi aspetti della sicurezza che devi tenere a mente:accesso alla rete, sicurezza del sistema operativo, sovvenzioni, crittografia e così via. In questo post del blog, ti forniremo 10 suggerimenti su cosa guardare quando proteggi la tua configurazione MySQL o MariaDB.
1. Rimuovere gli utenti senza password
MySQL veniva fornito con una serie di utenti pre-creati, alcuni dei quali possono connettersi al database senza una password o, peggio ancora, utenti anonimi. Questo è cambiato in MySQL 5.7 che, per impostazione predefinita, viene fornito solo con un account root che utilizza la password scelta al momento dell'installazione. Tuttavia, ci sono installazioni MySQL che sono state aggiornate dalle versioni precedenti e queste installazioni mantengono gli utenti legacy. Inoltre, MariaDB 10.2 su Centos 7 include utenti anonimi:
MariaDB [(none)]> select user, host, password from mysql.user where user like '';
+------+-----------------------+----------+
| user | host | password |
+------+-----------------------+----------+
| | localhost | |
| | localhost.localdomain | |
+------+-----------------------+----------+
2 rows in set (0.00 sec)Come puoi vedere, quelli sono limitati solo all'accesso da localhost ma, a prescindere, non vuoi avere utenti del genere. Sebbene i loro privilegi siano limitati, possono comunque eseguire alcuni comandi che potrebbero mostrare maggiori informazioni sul database, ad esempio, la versione potrebbe aiutare a identificare ulteriori vettori di attacco.
[[email protected] ~]# mysql -uanonymous_user
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 19
Server version: 10.2.11-MariaDB MariaDB Server
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> SHOW GRANTS\G
*************************** 1. row ***************************
Grants for @localhost: GRANT USAGE ON *.* TO ''@'localhost'
1 row in set (0.00 sec)
MariaDB [(none)]> \s
--------------
mysql Ver 15.1 Distrib 10.2.11-MariaDB, for Linux (x86_64) using readline 5.1
Connection id: 19
Current database:
Current user: [email protected]
SSL: Not in use
Current pager: stdout
Using outfile: ''
Using delimiter: ;
Server: MariaDB
Server version: 10.2.11-MariaDB MariaDB Server
Protocol version: 10
Connection: Localhost via UNIX socket
Server characterset: latin1
Db characterset: latin1
Client characterset: utf8
Conn. characterset: utf8
UNIX socket: /var/lib/mysql/mysql.sock
Uptime: 12 min 14 sec
Threads: 7 Questions: 36 Slow queries: 0 Opens: 17 Flush tables: 1 Open tables: 11 Queries per second avg: 0.049
--------------Tieni presente che gli utenti con password molto semplici sono insicuri quasi quanto gli utenti senza password. Password come "password" o "qwerty" non sono molto utili.
2. Accesso remoto stretto
Prima di tutto, l'accesso remoto per i superutenti - questo viene gestito per impostazione predefinita quando si installa l'ultimo MySQL (5.7) o MariaDB (10.2) - è disponibile solo l'accesso locale. Tuttavia, è abbastanza comune vedere i superutenti disponibili per vari motivi. Il più comune, probabilmente perché il database è gestito da persone che vogliono semplificare il proprio lavoro, quindi aggiungerebbero l'accesso remoto ai propri database. Questo non è un buon approccio in quanto l'accesso remoto semplifica lo sfruttamento di potenziali (o verificate) vulnerabilità di sicurezza in MySQL:non è necessario ottenere prima una connessione all'host.
Un altro passaggio:assicurati che ogni utente possa connettersi a MySQL solo da host specifici. Puoi sempre definire più voci per lo stesso utente ([email protected], [email protected]), questo dovrebbe aiutare a ridurre la necessità di caratteri jolly ([email protected]'%').
3. Rimuovere il database di prova
Il database di test, per impostazione predefinita, è disponibile per tutti gli utenti, in particolare per gli utenti anonimi. Tali utenti possono creare tabelle e scrivere su di esse. Questo può potenzialmente diventare un problema di per sé:qualsiasi scrittura aggiungerebbe un sovraccarico e ridurrebbe le prestazioni del database. Attualmente, dopo l'installazione predefinita, solo MariaDB 10.2 su Centos 7 ne risente:Oracle MySQL 5.7 e Percona Server 5.7 non hanno lo schema "test" disponibile.
[[email protected] ~]# mysql -uanonymous_user
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 13
Server version: 10.2.11-MariaDB MariaDB Server
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> SHOW GRANTS\G
*************************** 1. row ***************************
Grants for @localhost: GRANT USAGE ON *.* TO ''@'localhost'
1 row in set (0.00 sec)
MariaDB [(none)]> USE test;
Database changed
MariaDB [test]> CREATE TABLE testtable (a INT);
Query OK, 0 rows affected (0.01 sec)
MariaDB [test]> INSERT INTO testtable VALUES (1), (2), (3);
Query OK, 3 rows affected (0.01 sec)
Records: 3 Duplicates: 0 Warnings: 0
MariaDB [test]> SELECT * FROM testtable;
+------+
| a |
+------+
| 1 |
| 2 |
| 3 |
+------+
3 rows in set (0.00 sec)Naturalmente, può ancora accadere che il tuo MySQL 5.7 sia stato aggiornato da versioni precedenti in cui lo schema "test" non è stato rimosso:dovresti occupartene e verificare di averlo creato.
4. Offuscare l'accesso a MySQL
È noto che MySQL gira sulla porta 3306 e il suo superutente è chiamato "root". Per rendere le cose più difficili, è abbastanza semplice cambiarlo. In una certa misura, questo è un esempio di sicurezza attraverso l'oscurità, ma potrebbe almeno fermare i tentativi automatizzati di ottenere l'accesso all'utente "root". Per cambiare la porta, devi modificare my.cnf e impostare la variabile "port" su un altro valore. Per quanto riguarda gli utenti, dopo aver installato MySQL, dovresti creare un nuovo superutente (GRANT ALL … WITH GRANT OPTION) e quindi rimuovere gli account "[email protected]" esistenti.
5. Sicurezza della rete
Idealmente, MySQL non sarebbe disponibile attraverso la rete e tutte le connessioni sarebbero gestite localmente, attraverso il socket Unix. In alcune configurazioni, questo è possibile - in tal caso puoi aggiungere la variabile "skip-networking" in my.cnf. Ciò impedirà a MySQL di utilizzare qualsiasi comunicazione TCP/IP, solo il socket Unix sarebbe disponibile su Linux (named pipe e memoria condivisa su host Windows).
La maggior parte delle volte, tuttavia, una sicurezza così rigida non è fattibile. In tal caso è necessario trovare un'altra soluzione. Innanzitutto, puoi utilizzare il firewall per consentire il traffico solo da host specifici al server MySQL. Ad esempio, gli host delle applicazioni (anche se dovrebbero essere d'accordo con il raggiungimento di MySQL tramite proxy), il livello proxy e forse un server di gestione. Probabilmente altri host nella tua rete non hanno bisogno dell'accesso diretto al server MySQL. Ciò limiterà le possibilità di attacco al tuo database, nel caso in cui alcuni host nella tua rete venissero compromessi.
Se si utilizzano proxy che consentono la corrispondenza di espressioni regolari per le query, è possibile utilizzarli per analizzare il traffico SQL e bloccare le query sospette. Molto probabilmente gli host dell'applicazione non dovrebbero eseguire "DELETE * FROM your_table;" regolarmente. Se è necessario rimuovere alcuni dati, può essere eseguito manualmente, localmente, sull'istanza MySQL. Puoi creare tali regole usando qualcosa come ProxySQL:blocca, riscrivi, reindirizza tali query. MaxScale ti offre anche un'opzione per bloccare le query basate su espressioni regolari.
6. Plugin di controllo
Se sei interessato a raccogliere dati su chi ha eseguito cosa e quando, sono disponibili diversi plugin di audit per MySQL. Se utilizzi MySQL Enterprise, puoi utilizzare MySQL Enterprise Audit, che è un'estensione di MySQL Enterprise. Percona e MariaDB hanno anche la propria versione dei plugin di audit. Infine, il plug-in McAfee per MySQL può essere utilizzato anche con diverse versioni di MySQL. In generale, questi plugin raccolgono più o meno gli stessi dati:eventi di connessione e disconnessione, query eseguite, tabelle a cui si accede. Tutto ciò contiene informazioni su quale utente ha partecipato a tale evento, da quale host si è registrato, quando è successo e così via. L'output può essere XML o JSON, quindi è molto più semplice analizzarlo rispetto all'analisi del contenuto generale del registro (anche se i dati sono piuttosto simili). Tale output può anche essere inviato a syslog e, inoltre, a una sorta di server di log per l'elaborazione e l'analisi.
7. Disattiva LOAD DATA LOCAL INFILE
Se sia il server che il client sono in grado di eseguire LOAD DATA LOCAL INFILE, un client sarà in grado di caricare i dati da un file locale su un server MySQL remoto. Questo, potenzialmente, può aiutare a leggere i file a cui il client ha accesso, ad esempio, su un server delle applicazioni, è possibile accedere a qualsiasi file a cui ha accesso il server HTTP. Per evitarlo, devi impostare local-infile=0 in my.cnf
8. Privilegi dei file
Devi tenere a mente che la sicurezza di MySQL dipende anche dalla configurazione del sistema operativo. MySQL memorizza i dati sotto forma di file. Il server MySQL scrive molte informazioni nei log. A volte queste informazioni contengono dati, ad esempio registro delle query lente, registro generale o registro binario. È necessario assicurarsi che queste informazioni siano sicure e accessibili solo agli utenti che devono accedervi. In genere significa che solo il root e l'utente con i cui diritti MySQL è in esecuzione dovrebbero avere accesso a tutti i file relativi a MySQL. Il più delle volte è un utente dedicato chiamato "mysql". Dovresti controllare i file di configurazione di MySQL e tutti i log generati da MySQL e verificare che non siano leggibili da altri utenti.
9. SSL e crittografia dei dati in transito
Impedire alle persone di accedere ai file di configurazione e di registro è una cosa. L'altro problema è assicurarsi che i dati vengano trasferiti in modo sicuro sulla rete. Ad eccezione delle configurazioni in cui tutti i client sono locali e utilizzano il socket Unix per accedere a MySQL, nella maggior parte dei casi, i dati che formano un set di risultati per una query, lasciano il server e vengono trasferiti al client tramite la rete. I dati possono anche essere trasferiti tra server MySQL, ad esempio tramite la replica MySQL standard o all'interno di un cluster Galera. Il traffico di rete può essere annusato e, attraverso questi mezzi, i tuoi dati sarebbero esposti.
Per evitare che ciò accada, è possibile utilizzare SSL per crittografare il traffico, sia lato server che lato client. È possibile creare una connessione SSL tra un client e un server MySQL. Puoi anche creare una connessione SSL tra il tuo master e i tuoi slave, o tra i nodi di un cluster Galera. Ciò garantirà che tutti i dati trasferiti siano al sicuro e non possano essere rilevati da un utente malintenzionato che ha ottenuto l'accesso alla tua rete.
La documentazione MySQL spiega in dettaglio come impostare la crittografia SSL. Se lo trovi troppo ingombrante, ClusterControl può aiutarti a distribuire un ambiente sicuro per la replica MySQL o il cluster Galera in un paio di clic:
10. Crittografia dei dati inattivi
La protezione dei dati in transito utilizzando la crittografia SSL risolve solo parzialmente il problema. È necessario prendersi cura anche dei dati a riposo, tutti i dati archiviati nel database. La crittografia dei dati inattivi può anche essere un requisito per normative di sicurezza come HIPAA o PCI DSS. Tale crittografia può essere implementata su più livelli:puoi crittografare l'intero disco su cui sono archiviati i file. Puoi crittografare solo il database MySQL tramite le funzionalità disponibili nelle ultime versioni di MySQL o MariaDB. La crittografia può essere implementata anche nell'applicazione, in modo da crittografare i dati prima di archiviarli nel database. Ogni opzione ha i suoi pro e contro:la crittografia del disco può aiutare solo quando i dischi vengono rubati fisicamente, ma i file non verrebbero crittografati su un server di database in esecuzione. La crittografia del database MySQL risolve questo problema, ma non può impedire l'accesso ai dati quando l'account root è compromesso. La crittografia a livello di applicazione è la più flessibile e sicura, ma poi perdi la potenza di SQL:è piuttosto difficile utilizzare colonne crittografate nelle clausole WHERE o JOIN.
Tutte le versioni di MySQL forniscono una sorta di crittografia dei dati inattivi. MySQL di Oracle utilizza Transparent Data Encryption per crittografare i tablespace InnoDB. Questo è disponibile nell'offerta commerciale MySQL Enterprise. Fornisce un'opzione per crittografare i tablespace InnoDB, altri file che memorizzano anche dati in qualche forma (ad esempio, log binari, log generale, log di query lente) non sono crittografati. Ciò consente alla toolchain (MySQL Enterprise Backup ma anche xtrabackup, mysqldump, mysqlbinlog) di funzionare correttamente con tale configurazione.
A partire da MySQL 5.7.11, la versione community di MySQL ha anche il supporto per la crittografia del tablespace InnoDB. La principale differenza rispetto all'offerta aziendale è il modo in cui le chiavi vengono archiviate:le chiavi non si trovano in un deposito sicuro, necessario per la conformità normativa. Ciò significa che a partire da Percona Server 5.7.11 è anche possibile crittografare il tablespace InnoDB. Nel Percona Server 5.7.20, pubblicato di recente, è stato aggiunto il supporto per la crittografia dei log binari. È anche possibile integrarsi con il server Hashicorp Vault tramite un plug-in keyring_vault, abbinando (e persino estendendo la crittografia dei log binari) alle funzionalità disponibili nell'edizione MySQL Enterprise di Oracle.
MariaDB ha aggiunto il supporto per la crittografia dei dati in 10.1.3 - è un'implementazione separata e migliorata. Ti dà la possibilità non solo di crittografare i tablespace InnoDB, ma anche i file di registro InnoDB. Di conseguenza, i dati sono più sicuri ma alcuni strumenti non funzioneranno in tale configurazione. Xtrabackup non funzionerà con i log di ripristino crittografati:MariaDB ha creato un fork, MariaDB Backup, che aggiunge il supporto per la crittografia di MariaDB. Ci sono anche problemi con mysqlbinlog.
Indipendentemente dal tipo di MySQL che utilizzi, purché sia una versione recente, avresti opzioni per implementare la crittografia dei dati inattivi tramite il server del database, assicurandoti che i tuoi dati siano ulteriormente protetti.
Proteggere MySQL o MariaDB non è banale, ma speriamo che questi 10 suggerimenti ti aiutino lungo il percorso.
Riepilogo
Nel panorama odierno, la sicurezza dei dati è una priorità assoluta per ogni amministratore di database. Che la tua motivazione sia la conformità ai requisiti normativi o la protezione dei tuoi clienti e della reputazione della tua azienda, questi dieci suggerimenti per proteggere i tuoi database MySQL e MariaDB ti aiuteranno a proteggere ulteriormente la tua infrastruttura e a darti tranquillità.
Ci sono numerose misure da considerare per garantire la sicurezza dell'infrastruttura del database. In questo post, abbiamo trattato i fondamenti come la crittografia dei dati, i controlli dell'accesso alla rete, l'autenticazione e i privilegi degli utenti, la sicurezza del sistema operativo e altro ancora.
Il software di automazione della gestione del database, come ClusterControl, può essere un ottimo strumento per aiutare le tue attività di sicurezza del database in generale. Se stai cercando un'immersione più approfondita in ogni passaggio che devi compiere per proteggere i tuoi database MySQL, assicurati di controllare la Parte 1 e la Parte 2 della nostra serie su Come proteggere MySQL. Per rimanere informato su altre best practice per la gestione del database, seguici su Twitter, LinkedIn e iscriviti alla nostra newsletter per gli aggiornamenti.
