Oggi la sicurezza è fondamentale in tutto l'IT. Di tanto in tanto sentiamo di attacchi ransomware o fughe di dati che hanno origine in database o infrastrutture IT non protetti. Potresti chiederti:quali sono le migliori pratiche nell'architettura dell'ambiente MySQL in modo da poterti sentire al sicuro con i tuoi dati? Se è così, questo blog è per te. Tieni presente che non tratteremo completamente l'argomento:questo si adatterebbe più a un whitepaper che a un blog. Faremo del nostro meglio per menzionare gli aspetti più importanti della protezione del database MySQL. L'idea alla base di questo blog è che il lettore sappia ciò che non sa e aiuti a identificare gli argomenti e le parole chiave per ulteriori ricerche. Lo illustreremo con schermate del nostro prodotto, ClusterControl, che viene fornito con una vasta gamma di funzionalità, incluse alcune relative alla sicurezza del database.
Rete
Prima di tutto, dobbiamo distribuire MySQL da qualche parte. Che si tratti di istanza standalone, replica asincrona di replica primaria o di una delle topologie di replica sincrona più avanzate come Galera o InnoDB Cluster. Non importa cosa sia, deve essere protetto a livello di rete. Il database contiene i dati, che, abbastanza comunemente, sono la risorsa più preziosa di un'intera organizzazione.
Protezione dell'accesso
Le istanze del database non dovrebbero mai trovarsi sulla rete pubblica. I segmenti di rete in cui sono configurati i database dovrebbero essere accessibili solo da un numero limitato di altre reti. La regola pratica è:un determinato nodo dovrebbe essere in grado di accedere alla rete di database? Se la risposta è no, le reti dovrebbero essere separate.
Ovviamente, tutto dipende dall'esatta configurazione ma nei casi più comuni, dove si hanno livelli di applicazione, proxy, cache e database, la configurazione più tipica sarebbe che solo il proxy dovrebbe essere in grado per accedere alla banca dati. Tutte le altre entità devono essere configurate in modo che accedano al database solo tramite il livello proxy. Questo design è buono in molti modi. Oltre alla maggiore sicurezza, aiuta anche a nascondere la complessità del livello di database dall'applicazione.
Il livello proxy dovrebbe seguire la topologia del database e dovrebbe gestire gli errori del nodo del database e le modifiche alla topologia. L'applicazione, che si connette al livello proxy, dovrebbe sempre essere in grado di raggiungere un nodo di database funzionante rilevante per il tipo di richiesta. Lo stesso vale per il livello della cache. Può essere implementato nel livello proxy, alcuni proxy come ProxySQL consentono richieste cache all'interno del proxy, ma se si tratta di un livello separato costruito attorno, ad esempio, memcache o Redis, dovrebbe sempre raggiungere il database tramite il livello proxy.
L'altro tipo di nodi che potrebbe richiedere l'accesso diretto al livello del database sono i nodi di gestione, quelli utilizzati dai team operativi per gestire i database. Il motivo è semplice:alcune attività di manutenzione possono richiedere l'accesso diretto ai database. Potrebbero essere script di automazione delle attività, playbook Ansible in rotazione nell'intero parco database o altre attività. In tal caso, ovviamente, dovrebbero essere messe in atto misure di sicurezza per garantire che solo le persone che hanno accesso possano accedere a tale nodo di gestione.
Un altro possibile tipo di nodi (sebbene i nodi di gestione possano essere utilizzati anche per questo) che potrebbero richiedere l'accesso al database sono i nodi coinvolti nella raccolta delle metriche e nella loro presentazione agli utenti - stiamo parlando di monitoraggio e attività di avviso.
VPN
Per qualsiasi tipo di livello di database che si estende su più data center, dovresti considerare l'utilizzo di una VPN per connetterli. Le connessioni aperte e non crittografate sulla rete WAN sono qualcosa che non dovrebbe mai accadere. Anche l'impostazione della crittografia SSL non è l'opzione migliore in quanto richiederebbe l'apertura dell'accesso tra il livello del database e la WAN:le connessioni SSL tra i nodi del database richiedono che siano in grado di connettersi direttamente. La VPN risolve questo problema aggiungendo un intermediario che crea un modo sicuro per connettere i segmenti della rete a livello di database.
VPN dovrebbe anche essere obbligatoria per qualsiasi tipo di accesso utente alla rete dell'organizzazione poiché implementa una connettività sicura tra una workstation e la rete di produzione.
Firewall
Naturalmente, mentre proteggiamo la rete, dovremmo considerare l'utilizzo del firewall. In generale, ogni nodo del database dovrebbe ricevere solo connessioni da un insieme definito di origini:nomi host e porte. Anche i segmenti di rete “richiesti” non dovrebbero avere pieno accesso alla rete del database ma solo alle porte richieste. Se il proxy deve solo connettersi alla porta del database, non vi è alcun motivo per poter accedere a qualsiasi altra porta sui nodi del database. Tieni inoltre presente che non dovresti utilizzare le porte predefinite. È, ovviamente, sicurezza per oscurità, dopotutto la porta è aperta da qualche parte, ma aiuta a gestire almeno alcune delle intrusioni di sicurezza che utilizzano script automatizzati. Non impedirà a qualcuno che è determinato di ottenere l'accesso, ma potrebbe rallentarlo (se associato al rilevamento della scansione delle porte e alle misure anti-scansione) impedendo il successo degli attacchi automatici.
Sicurezza database
La rete è la prima linea di difesa, ci sono altre misure di sicurezza e buone pratiche che puoi utilizzare per migliorare ulteriormente la tua sicurezza. Alcuni di essi possono essere implementati sul database stesso.
Utenti e host
I database stessi possono essere utilizzati per implementare il controllo degli accessi e le restrizioni. Per cominciare, puoi implementare il controllo dell'accesso basato su host, impedendo a host diversi dal breve elenco di nodi di accedere al database. Ovviamente, se hai utilizzato un firewall per limitare l'accesso, questo potrebbe sembrare un duplicato, ma è comunque una buona idea limitare l'accesso al database stesso:non si sa mai quando, per errore, un firewall verrà disabilitato. In tal caso hai ancora un secondo livello di protezione.
Quello che vuoi implementare qui è un elenco di utenti e host del database che possono accedere al database. Molto probabilmente ciò che dovresti avere è uno o più utenti concessi l'accesso da host situati nel livello proxy. La quantità di controllo dell'accesso dettagliato che potresti avere dipende dal sistema di database di cui disponi. MySQL, ad esempio, non consente un controllo dettagliato sulle maschere di rete:utilizza solo /32, /24, /16 o /8. In PostgreSQL, invece, puoi usare qualsiasi tipo di maschera di rete.
Concessioni
Se questo è ciò che consente il tuo database, ciascuno degli utenti dovrebbe avere un insieme definito di sovvenzioni, assicurandosi che i privilegi assegnati loro siano il minimo richiesto all'utente per eseguire le azioni che deve fare . I sistemi di database possono avere diversi set di privilegi e diversi livelli di essi. In genere abbiamo diversi livelli di privilegi - globali, che interessano l'intero server del database, livello di schema - un dato utente può avere privilegi diversi assegnati a schemi diversi. Puoi avere privilegi su una tabella o anche a livello di colonna. Come accennato in precedenza, l'obiettivo è creare l'insieme minimo di privilegi per ogni utente. Probabilmente vorrai avere almeno un utente con privilegi elevati:verrebbe utilizzato per gestire il database. Tale utente dovrebbe essere strettamente limitato quando si tratta di connettività. Non dovrebbe (e in effetti nessuno degli utenti non dovrebbe) essere autorizzato a connettersi da qualsiasi posizione:dovrebbe essere un localhost o un particolare nodo di gestione, dedicato all'esecuzione di operazioni sul database.
Gestione password
Ogni utente nel database dovrebbe avere una password definita. Questo è un gioco da ragazzi. La password deve essere memorizzata sotto forma di hash. Dovresti assicurarti che per memorizzare le password stai utilizzando l'algoritmo hash più sicuro che il tuo database ha da offrire. Le password non dovrebbero essere facili da indovinare né dovrebbero essere vulnerabili all'attacco del dizionario. Alcuni sistemi di database, come MySQL, ti consentono di definire con precisione i requisiti che le tue password devono soddisfare per poter essere utilizzate. Lettere minuscole e maiuscole, numeri, caratteri speciali, lunghezza della password:tutto è importante e se puoi applicare alcune politiche sulla sicurezza della password, dovresti farlo. Un altro bit importante è la rotazione delle password. Le password non devono essere create una volta per tutta la durata del database, è necessario disporre di una politica di rotazione delle password. Ancora una volta, alcuni dei sistemi di database possono imporre questo per te. L'utente amministrativo potrebbe essere in grado di creare nuovi account utente con la rotazione delle password imposta. Potrebbe anche essere in grado di imporre la rotazione delle password per un determinato utente.
Registri di controllo
Alcuni dei sistemi di database offrono registri di controllo:l'idea è quella di raccogliere quante più informazioni possibili sull'attività nel database. Chi e quando ha fatto cosa? Quale query è stata eseguita, da chi? Chi ha tentato di accedere ma non è riuscito? Da quale host? Idealmente, i registri contenenti tali informazioni sarebbero archiviati al di fuori dei nodi del database. Puoi trasmetterli in streaming al tuo server di registro centrale per la custodia, l'ulteriore elaborazione e migliori capacità di ricerca.
Sicurezza SQL
Abbiamo menzionato utenti e host, ma l'attacco può avvenire anche da una fonte diversa. Se la tua applicazione non è protetta correttamente e l'input non è convalidato correttamente, potresti dover affrontare attacchi provenienti dal tuo sito web. Stiamo parlando di SQL injection. In tal caso i firewall non sono molto utili dato che la query ha avuto origine da una fonte valida (il tuo server web e quindi il nodo proxy). L'assegnazione di sovvenzioni può effettivamente aiutare a prevenire alcuni di questi tipi di attacchi, ma non è una soluzione ideale:dopotutto la tua applicazione, nella maggior parte dei casi, avrà bisogno di un utente che possa rimuovere o modificare il contenuto del database. Tale utente, se sfruttato, può essere utilizzato per fare del male. Esistono diversi modi in cui puoi provare a contrastare il trattamento.
Firewall SQL
Il modo più semplice per farlo è implementare il firewall SQL. Può essere realizzato su diversi livelli e in diversi luoghi. Una delle opzioni è utilizzare i bilanciatori di carico per questo. Alcuni di loro sono dotati di questa funzionalità almeno facilmente realizzabile se non già implementata. L'idea alla base è quella di creare un elenco di query eseguite dall'applicazione e quindi configurare il proxy in modo che passi solo questo tipo di traffico. Non è l'ideale in quanto dovrai mantenerlo nel tempo, aggiungendo nuove query e rimuovendo quelle vecchie che non vengono più utilizzate. D'altra parte, un tale insieme di regole impedirà a qualsiasi query non autorizzata di raggiungere il database.
Rilevamento iniezione SQL
Un'altra opzione possibile sarebbe implementare il rilevamento dell'iniezione SQL nel livello proxy. Esistono un paio di soluzioni, tra cui ProxySQL, che possono essere configurate per tentare di rilevare l'iniezione SQL nel traffico che le attraversa. Ovviamente, tutto si basa sull'euristica, quindi potrebbe risultare in falsi positivi, ma può essere una buona aggiunta al firewall SQL.
In passato abbiamo discusso di come implementare il firewall SQL e il rilevamento SQL injection utilizzando ProxySQL, un loadbalancer che può essere distribuito da ClusterControl:
https://diversealnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-one
https://diversealnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-two
Sicurezza dei dati
Infine, la sicurezza dei dati. Abbiamo discusso finora di come si può rafforzare il database, come limitare l'accesso ad esso e come prevenire diversi tipi di attacchi provenienti dall'applicazione stessa. Dovremmo comunque considerare la protezione dei dati stessi. Questo può avere diversi livelli. Sicurezza fisica:se possiedi il data center, assicurati che sia adeguatamente bloccato. Se utilizzi ISP esterni o provider cloud, assicurati che dispongano di protocolli di sicurezza adeguati quando si tratta di accedere all'hardware. Quindi abbiamo un server, VM o comunque che stai utilizzando. I dati si trovano su disco, archiviati localmente sul server. I dati vengono trasferiti tra l'applicazione, il proxy e il database. I dati vengono trasferiti tra i nodi del database mediante la replica. I dati vengono archiviati fuori sede come backup. Questi dati dovrebbero essere protetti.
Backup
I backup dovrebbero essere sempre crittografati. La chiave di crittografia deve essere conservata con cura e ruotata regolarmente.
Dati in transito
I dati trasferiti devono essere crittografati. Assicurati di aver configurato la tua applicazione, il livello proxy e il database per utilizzare SSL o TSL. Ogni mezzo per trasferire i dati tra i nodi del database dovrebbe anche essere protetto e crittografato. L'obiettivo è rendere inutile qualsiasi tipo di sniffing di rete.
Dati inattivi
Infine, i dati stessi, archiviati nel nodo del database. Dovrebbe anche essere crittografato. Ci sono un paio di metodi che puoi usare quando ti avvicini a questo argomento. Innanzitutto, la crittografia a livello di host. Il volume su cui il database ha la sua directory dei dati può essere crittografato (e decrittografato all'avvio). I database tendono anche a essere dotati di funzionalità di crittografia. Ciò che può essere crittografato dipende dalla soluzione esatta e dal tipo e versione del database, ma in alcuni casi le opzioni sono piuttosto ampie. Crittografia tablespace, crittografia dei registri, a volte anche crittografia delle strutture in memoria. Se lo fai correttamente, l'accesso al nodo del database non sarà sufficiente per accedere ai dati.
Conclusione
Come accennato in precedenza, questo blog non vuole essere una guida pratica alla sicurezza del database, ma abbiamo toccato la maggior parte degli aspetti che dovresti considerare durante l'architettura del tuo ambiente di database e speriamo troverai utile questa guida.
