Il database è uno degli elementi più importanti di un'infrastruttura informatica perché al suo interno vengono normalmente conservate informazioni fondamentali per il funzionamento dell'azienda. Clienti, ordini, fatture, documenti, credenziali, informazioni commerciali e dati relativi ai processi interni possono essere gestiti quotidianamente attraverso uno o più database. Per questo motivo la sicurezza del database non può essere considerata un aspetto secondario, soprattutto quando il sistema è collegato a un gestionale, a un sito web o a un'applicazione utilizzata da più dipendenti.
Proteggere un database non significa semplicemente impostare una password complessa. La sicurezza deve essere costruita su più livelli, partendo dalla posizione del database all'interno della rete fino ad arrivare alla gestione degli utenti, ai permessi, alla protezione delle connessioni, agli aggiornamenti e ai sistemi di backup. Un database correttamente configurato deve infatti essere accessibile ai sistemi che ne hanno realmente bisogno, ma difficilmente raggiungibile da soggetti non autorizzati.
Dove dovrebbe trovarsi un database
Uno dei primi aspetti da valutare riguarda la rete. Un database aziendale non dovrebbe essere esposto direttamente a Internet se non esiste una precisa esigenza tecnica. Se, ad esempio, un'applicazione web deve comunicare con MySQL o MariaDB, è preferibile che il database sia collocato in una rete interna o in una subnet dedicata e che il firewall permetta le connessioni solamente dal server autorizzato.
Questa configurazione riduce notevolmente la superficie di attacco. Un database che non può essere raggiunto direttamente dall'esterno è già più difficile da attaccare rispetto a un servizio esposto pubblicamente. La sicurezza della rete diventa quindi il primo livello di protezione, prima ancora di arrivare alla configurazione del database.
In un'infrastruttura aziendale più strutturata è possibile separare server applicativi, database, dispositivi degli utenti e altri servizi attraverso VLAN e subnet differenti, definendo poi regole firewall che consentano solamente il traffico necessario.
Gestire correttamente utenti e privilegi
Un altro punto fondamentale riguarda gli account che possono accedere al database. Un errore abbastanza comune consiste nell'utilizzare un unico account con privilegi amministrativi per tutte le applicazioni e per tutte le operazioni. Questa configurazione può sembrare comoda, ma rappresenta un rischio importante perché la compromissione dell'applicazione potrebbe trasformarsi automaticamente nella compromissione dell'intero database.
È molto più sicuro creare account differenti e assegnare a ciascuno solamente i privilegi necessari. Un'applicazione che deve leggere e modificare alcune tabelle non dovrebbe avere automaticamente la possibilità di eliminare database, creare nuovi utenti o modificare qualsiasi elemento dell'istanza.
Questo principio, chiamato least privilege, è particolarmente importante perché permette di limitare le conseguenze di un eventuale errore o attacco. Se un account applicativo viene compromesso, l'attaccante eredita solamente i privilegi assegnati a quell'account e non necessariamente il controllo completo del database.
La sicurezza dipende anche dall'applicazione
Il database non può essere protetto senza considerare il software che lo utilizza. Un'applicazione PHP, ad esempio, comunica normalmente con MySQL attraverso query SQL che possono contenere dati inseriti dall'utente. Se queste informazioni vengono inserite direttamente all'interno delle query attraverso concatenazioni di stringhe, si può creare una vulnerabilità di SQL Injection.
La soluzione consiste nell'utilizzare query parametrizzate e prepared statement, mantenendo separati il codice SQL e i valori ricevuti dall'utente. Con PHP e PDO questo approccio è facilmente implementabile e permette di evitare che un valore fornito dall'esterno venga interpretato come parte della sintassi SQL.
La sicurezza dell'applicazione deve però comprendere anche la validazione degli input, la gestione corretta degli errori e il controllo degli accessi. Non è sufficiente proteggere il database se l'applicazione che lo utilizza permette a un utente non autorizzato di accedere a dati che non dovrebbe vedere.
Proteggere le credenziali di accesso
Le credenziali del database rappresentano un altro elemento estremamente delicato. Una password inserita direttamente nel codice sorgente, lasciata all'interno di un repository o conservata in un file accessibile dal web server può diventare un punto di ingresso molto pericoloso.
In un'applicazione PHP è preferibile mantenere le informazioni sensibili in configurazioni protette o attraverso variabili d'ambiente e assicurarsi che tali file non siano accessibili tramite una richiesta HTTP. Anche le copie del progetto e i backup devono essere controllati attentamente, perché potrebbero contenere username, password o altri dati utilizzati per la connessione.
La gestione delle credenziali dovrebbe inoltre prevedere password uniche e sufficientemente complesse, evitando di utilizzare la stessa password per database, server, pannelli amministrativi e altri servizi.
Cifrare le comunicazioni con il database
Quando applicazione e database si trovano su server differenti, è importante proteggere anche la comunicazione tra i due sistemi. Una connessione non cifrata potrebbe permettere, in determinate condizioni, di intercettare informazioni trasmesse sulla rete.
L'utilizzo di TLS consente di cifrare il traffico tra client e server database, proteggendo le informazioni durante il trasferimento. Questo aspetto diventa particolarmente importante nelle infrastrutture distribuite, negli ambienti cloud e nei sistemi in cui il database non si trova direttamente sulla stessa macchina dell'applicazione.
La cifratura deve comunque essere configurata correttamente, verificando certificati, autenticazione e protocolli supportati. Attivare semplicemente una connessione cifrata senza controllare la configurazione non garantisce automaticamente il livello di sicurezza desiderato.
Aggiornare il database è una misura di sicurezza
Anche il software che gestisce il database deve essere mantenuto aggiornato. MySQL, MariaDB, PostgreSQL e gli altri sistemi di gestione dei database ricevono periodicamente aggiornamenti che possono correggere vulnerabilità, problemi di stabilità e malfunzionamenti.
Rimandare indefinitamente gli aggiornamenti significa mantenere un sistema potenzialmente esposto a problemi già conosciuti. Allo stesso tempo, in un ambiente aziendale non è consigliabile aggiornare direttamente un database di produzione senza aver verificato la compatibilità con le applicazioni che lo utilizzano.
È quindi preferibile testare gli aggiornamenti in un ambiente separato e successivamente pianificare l'intervento in produzione, prevedendo anche una procedura di rollback nel caso qualcosa non funzioni correttamente.
Backup e sicurezza dei dati
La protezione del database non riguarda solamente gli attacchi informatici. Un errore umano, un guasto hardware, un problema software o un attacco ransomware possono rendere indisponibili o danneggiare i dati.
Per questo il database deve essere inserito all'interno di una strategia di backup aziendale. Non è sufficiente creare una copia occasionale dei dati, perché bisogna stabilire con quale frequenza effettuare il backup, quanto tempo conservarlo e soprattutto dove archiviarlo.
Un aspetto spesso sottovalutato è il test del ripristino. Un backup può sembrare perfettamente funzionante ma risultare inutilizzabile quando serve realmente. Per questo è importante eseguire periodicamente un restore di prova e verificare che database, tabelle e dati possano essere recuperati correttamente.
Le copie devono inoltre essere protette dall'accesso non autorizzato. Se un attaccante riesce a compromettere contemporaneamente database e backup, la possibilità di recuperare rapidamente l'infrastruttura può ridursi drasticamente.
Monitorare quello che succede nel database
La sicurezza non termina con la configurazione iniziale. Un database aziendale deve essere monitorato nel tempo per individuare comportamenti anomali.
Un improvviso aumento delle connessioni, un numero insolito di query, un consumo elevato di CPU o disco oppure una grande quantità di modifiche ai dati possono indicare un problema tecnico oppure un'attività sospetta.
I log del database possono fornire informazioni importanti per ricostruire ciò che è accaduto. Integrando questi dati con i log dell'applicazione e del server è possibile avere una visione più completa dell'infrastruttura e individuare più facilmente eventuali anomalie.
Il monitoraggio diventa particolarmente importante quando il database supporta servizi essenziali per l'azienda, perché permette di intervenire prima che un problema provochi un'interruzione significativa.
Errori e informazioni sensibili
Un altro aspetto importante riguarda gli errori mostrati dall'applicazione. Durante lo sviluppo può essere utile visualizzare il messaggio completo restituito da MySQL o dal sistema di gestione del database, ma in produzione questa pratica può rivelare informazioni tecniche che non dovrebbero essere disponibili agli utenti.
Un errore SQL potrebbe mostrare il nome di una tabella, una colonna, una query o una parte della struttura interna dell'applicazione. Queste informazioni possono essere utilizzate per comprendere meglio il funzionamento del sistema.
È quindi preferibile registrare gli errori nei log del server e mostrare all'utente un messaggio generico, mantenendo le informazioni tecniche disponibili solamente agli amministratori e agli sviluppatori autorizzati.
La sicurezza del database è un processo continuo
Un database sicuro non è semplicemente un database al quale nessuno può accedere. Deve essere un sistema nel quale gli accessi necessari sono consentiti e quelli non necessari vengono impediti, i dati vengono protetti durante il trasferimento, gli account dispongono solamente dei privilegi indispensabili e le informazioni possono essere recuperate in caso di incidente.
Questo significa che la sicurezza deve essere verificata periodicamente. Quando viene aggiunto un nuovo utente, installato un nuovo gestionale, modificata una rete o introdotta una nuova applicazione, anche la configurazione del database potrebbe dover essere aggiornata.
Per un'azienda, quindi, proteggere il database significa considerarlo parte integrante dell'intera infrastruttura IT e non come un semplice componente tecnico utilizzato dall'applicazione.
Proteggere il database significa proteggere i dati aziendali
La sicurezza di un database nasce dall'integrazione di diversi livelli: rete, firewall, autenticazione, privilegi, applicazione, cifratura, aggiornamenti, backup e monitoraggio. Nessuno di questi elementi, preso singolarmente, è sufficiente a garantire una protezione completa.
In ALLIT, la gestione della sicurezza di un database può essere affrontata analizzando l'intero ambiente nel quale il sistema opera, verificando come vengono gestiti gli accessi, quali applicazioni possono collegarsi, quali dati vengono conservati e come vengono effettuati backup e ripristini.
Un database aziendale deve essere progettato per mantenere nel tempo tre caratteristiche fondamentali: riservatezza, integrità e disponibilità dei dati. Proteggerlo significa quindi non soltanto impedire un accesso non autorizzato, ma fare in modo che le informazioni rimangano corrette, disponibili e recuperabili anche quando l'infrastruttura deve affrontare un guasto, un errore umano o un tentativo di attacco.
