Panoramica della protezione di MySQL

Non c'è modo di indorare la pillola: ci sono utenti malintenzionati che possono eseguire facilmente la scansione dell'intera rete internet in pochi minuti e crackare le password in pochi secondi. Sebbene a volte sia necessario lasciare un database accessibile tramite una rete IP pubblica, questo rende il database esponenzialmente più vulnerabile. Un modo per ridurre i rischi di IP pubblico è limitare l'accesso al database a un insieme limitato di indirizzi IP.

Detto ciò, la soluzione migliore è consentire solo l'accesso all'interno di un virtual private cloud (VPC) e consentire solo le connessioni degli operatori all'interno di un bastion host. In Google Cloud, questa soluzione è chiamata IP privato. Se l'istanza MySQL è accessibile solo all'interno di un VPC, un utente malintenzionato dovrà innanzitutto violare il VPC prima di tentare di violare l'istanza.

Ogni versione secondaria di MySQL ha note di rilascio che contengono quasi invariabilmente una sezione relativa agli aggiornamenti della sicurezza. Se la tua istanza ha più versioni non aggiornate, esistono diverse versioni delle correzioni di sicurezza di cui il tuo database non dispone.

Oltre a risolvere i problemi di sicurezza nel tempo, MySQL introduce periodicamente anche diverse funzionalità di sicurezza completamente nuove. Ad esempio, MySQL 8.0 ha introdotto molti modi per rafforzare gli schemi e gli utenti MySQL, come ruoli, monitoraggio degli accessi non riusciti e generazioni di password casuali.

Supponiamo che tu stia lavorando in un bar e che voglia eseguire alcune query in modo da connetterti a MySQL tramite la rete Wi-Fi gratuita del negozio. Se non hai utilizzato TLS (Transport Layer Security), stai effettivamente divulgando il tuo nome utente e la tua password tramite TCP (Transmission Control Protocol, uno dei principali protocolli internet). Applica TLS sull'istanza MySQL per preparare il tuo latte macchiato senza preoccuparti che altri clienti ti stiano spiando nella rete.

SQL injection

Spesso non è il database, ma l'applicazione ad essere più vulnerabile a un attacco. Molte applicazioni sono state vittime di attacchi di SQL injection, nei quali un utente malintenzionato inserisce un input dannoso che la tua applicazione considera come un'istruzione SQL valida. La migliore protezione contro questi attacchi è utilizzare istruzioni preparate durante la creazione di istruzioni SQL, invece di concatenare l'input utente con istruzioni SQL.

Secret nel tuo repository

Innumerevoli database sono stati violati a causa di uno sviluppatore che ha inavvertitamente eseguito il push del suo nome utente e della sua password nel repository del codice sorgente. Utilizza piuttosto uno strumento come Secret Manager di Google Cloud, che gestisce tutti i tipi di secret, inclusa la password del database.

Password di logging

Infine, utilizza gli strumenti di filtro del framework di logging per filtrare la password del database dai log dell'applicazione. Alcuni esempi sono i Log4j Filters o Rails ParameterFilter, ma la maggior parte dei framework di logging dovrebbe avere un equivalente. In caso contrario, dovrai assicurarti che i log delle applicazioni siano protetti per proteggere il database.

Valuta la possibilità di utilizzare la convalida delle password per assicurarti che tutte le password del database siano sufficientemente complesse. Le password delle applicazioni devono essere lunghe, complesse e sottoposte a rotazione di frequente. I Secret Manager sono particolarmente utili per non dover memorizzare password complesse e che cambiano spesso. 

Se una persona (e non un'applicazione) utilizza un utente del database, segui gli standard del NIST e dai la priorità assoluta alla lunghezza. Le date di scadenza delle password e i requisiti delle password eccessivamente complessi portano spesso gli utenti a delegare le loro memorie a file di testo non crittografato e note adesive, che minano l'intero scopo di queste regole. 

In alternativa, meglio ancora, prendi in considerazione l'utilizzo dell'autenticazione IAM per gli utenti che non si servono delle applicazioni. L'autenticazione IAM delega la creazione della connessione all'offerta IAM di Google Cloud, il che significa che il rischio è ridotto solo all'utente IAM, invece che all'utente IAM e all'utente database.

Infine, MySQL esegue l'hashing, non il valore sale, per la password del database. Ciò significa che gli utenti con la stessa password avranno stringhe di autenticazione identiche, rendendo facile crackare le password inefficaci tramite un attacco alla tabella arcobaleno. Nota che i due utenti MySQL seguenti hanno lo stesso valore authentication_string.

Ti consigliamo di impostare il flag default_authentication_plugin su caching_sha2_password. In questo modo ti assicuri che due utenti con la stessa password avranno un hash diverso. Osserva come i due utenti hanno valori authentication_string diversi nell'esempio seguente.

Limitare l'accesso non significa solo garantire l'accesso dall'esterno; significa anche controllare regolarmente l'accesso dall'interno.

Controlla la tua applicazione: se legge solo dalle tabelle relative a fatturazione, prodotto e clienti, ha davvero bisogno di accedere a tutto il resto? Lasciare l'accesso root disponibile al database significa che un utente malintenzionato può causare gravi danni al tuo database. Pensa invece a tutti i requisiti della tua istanza, elenca i privilegi necessari e crea un utente database per ognuno. Se un utente malintenzionato viola il tuo database in base a uno di questi utenti, avrai limitato l'ambito del danno.

Controlla gli utenti: quanti utenti del tuo database hanno davvero bisogno di privilegi amministrativi sulle tue istanze? Quanti di questi utenti sono ancora nella tua organizzazione o sono inattivi o associati a progetti inattivi? I token di accesso possono presentare fughe e la minaccia interna è una costante preoccupazione per la maggior parte dei sistemi. Assicurarti di avere il minor numero possibile di utenti può aiutare la tua istanza a proteggersi da questo tipo di problemi.

Controlla l'"admin": ti consigliamo di rimuovere o rinominare gli utenti come "root" o "admin". Si tratta di bersagli facili per gli utenti malintenzionati e, se non esistono, il sistema è ancora più difficile da violare. Si tratta della cosiddetta sicurezza tramite segretezza che, anche se non deve essere la prima linea di difesa, può aggiungere un sottile livello di sicurezza al tuo database MySQL.

I backup regolari dei dati e i piani di recupero dati verificabili sono fondamentali per una gestione di database efficace. Tuttavia, anche con i normali backup, puoi comunque perdere tutti i dati scritti dopo l'ultimo backup. Uno dei vantaggi dell'ecosistema MySQL è il recupero point-in-time (PITR), che consente di recuperare i dati in qualsiasi momento. Per rendere possibile il PITR, abilita i log binari sulle tue istanze Cloud SQL per MySQL.

Se hai seguito i passaggi precedenti, è tutto ben preparato e protetto. Detto questo, nessuna progettazione di sicurezza sarebbe completa senza una vigilanza continua, ovvero il controllo del database. Il plug-in di audit Cloud SQL per MySQL ti aiuta a tenere traccia di comportamenti insoliti in caso di violazione.

Dopo aver implementato quanto sopra, hai reso molto più difficile qualsiasi percorso verso una violazione del database per un utente malintenzionato. Un utente malintenzionato dovrebbe violare la tua applicazione e sperare che l'utente del database dell'applicazione disponga di privilegi sufficienti per l'attacco oppure dovrebbe violare il tuo VPC, trovare un nome utente esistente, crackare la password e sperare che l'utente disponga di privilegi sufficienti per eseguire l'attacco. Nel frattempo, puoi visualizzare i log del database MySQL o gli audit log per monitorare eventuali comportamenti abituali sul database e reagire di conseguenza.

Questo è il significato di "security by design". Gli utenti malintenzionati continueranno a cercare modi per sfruttare le macchine. Ecco perché è importante progettare il tuo sistema con il maggior numero possibile di livelli di protezione per mantenere il database protetto.