11 passaggi per proteggere SQL nel 2023

Sia che tu stia utilizzando SQL Server di Microsoft (presto in esecuzione su Linux) o l'open source MySQL, devi bloccare i tuoi database per mantenere i tuoi dati privati e sicuri. Questi 11 passaggi ti guideranno attraverso alcuni dei principi di base della sicurezza del database e come implementarli. In combinazione con una configurazione avanzata del server Web, un server di database sicuro impedirà a un'applicazione di diventare un punto di ingresso nella rete e impedirà che i dati finiscano su Internet. Quando si esegue il provisioning di un nuovo server SQL, ricordarsi di tenere conto della sicurezza fin dall'inizio; Dovrebbe essere una parte del processo regolare, non qualcosa di applicato retroattivamente, poiché alcune misure di sicurezza chiave richiedono modifiche fondamentali alla configurazione per i server di database e le applicazioni installati in modo non sicuro.

1. Isolare il server di database

I server di database di produzione devono essere isolati il più possibile da altre applicazioni e servizi. I server DB dedicati hanno un ingombro e quindi una superficie di attacco più piccoli e non c'è bisogno di preoccuparsi di risorse in conflitto o traffico in conflitto. I sistemi operativi devono essere snelli, con solo i servizi necessari installati e in esecuzione. Non installare altre applicazioni a meno che non siano richieste dal server di database.

A seconda delle dimensioni dell'ambiente, è consigliabile inserire il server SQL in un segmento di rete con restrizioni/VLAN in modo che solo il traffico autorizzato possa passare. In genere, solo un server applicazioni o un server Web comunica direttamente con il database, quindi è possibile adottare criteri di rete piuttosto restrittivi per prevenire connessioni illecite. Questo dovrebbe essere ovvio, ma non dovresti mai aprire il tuo server di database su Internet sulle porte 1433/1434 (MSSQL) e 3306/3307 (MySQL).

2. Personalizza l'installazione del DB

Sia MSSQL che MySQL offrono tonnellate di funzionalità aggiuntive, la maggior parte delle quali probabilmente non ti servirà per nessuna istanza particolare. Rimuovendo i pezzi che non ti servono, riduci le possibili incursioni per lo sfruttamento. Se vuoi mantenere una funzionalità con cui giocare che non stai ancora utilizzando, fallo in un ambiente di test o di sviluppo: meglio mantenere la produzione bloccata il più possibile, soprattutto prima di determinare quali effetti un nuovo modulo potrebbe avere sul tuo ambiente.

3. Mantienilo aggiornato

Sia MSSQL che MySQL vengono regolarmente patchati, quindi assicurati di mantenere aggiornata la tua versione. La maggior parte delle vulnerabilità che vengono sfruttate sono note da oltre un anno, quindi l'installazione tempestiva delle patch di sicurezza può prevenire la maggior parte degli attacchi semplicemente sigillando questi difetti. Avere un programma e un protocollo di patch regolari può aiutare a implementare gli aggiornamenti in un ambiente di test in modo che eventuali effetti negativi possano essere scoperti senza interrompere la produzione. Molti negozi non hanno questo lusso e volano per i pantaloni, installando gli aggiornamenti direttamente in produzione e sperando per il meglio. Di solito questo funziona, fortunatamente, ma quando non funziona, può andare male rapidamente, quindi almeno comprendi le opzioni e la procedura di rollback, nonché esattamente cosa sta cambiando la patch.

4. Limitare i processi DB

L'utente con cui viene eseguito il servizio di database determina l'accesso dei processi di database al resto del server, inclusi il file system, la capacità di eseguire programmi e così via. Come con la maggior parte delle applicazioni Linux, MySQL verrà in genere eseguito con un account utente mysql dedicato con autorizzazioni minime per il resto del server. Puoi verificarlo con un semplice comando ps e assicurarti che MySQL non sia stato configurato per l'esecuzione come root, cosa che accade sicuramente, soprattutto in circostanze estreme, ad esempio la risoluzione di un'interruzione, e quindi non viene riconfigurato una volta che la crisi è stata evitata.

Ma nelle installazioni di Windows, MSSQL viene spesso eseguito come sistema locale o come account amministratore, consentendo processi di database, comprese le stored procedure e le interfacce della shell dei comandi come xp_cmdshell, l'accesso completo. Idealmente, MSSQL dovrebbe essere eseguito come un account locale dedicato, non amministratore con privilegi minimi. Le procedure guidate di installazione di MS più recenti possono persino automatizzare questo passaggio per te, quindi se stai installando un nuovo server, assicurati di configurare questa opzione. Anche altri servizi SQL, ad esempio SQL Agent, devono essere eseguiti come account locali con restrizioni, con autorizzazioni concesse in base alle esigenze, ad esempio per una directory di backup.

Se non si esegue questo passaggio, un server di database compromesso può compromettere il resto del computer e infiltrarsi nella rete.

5. Limitare il traffico SQL

Come accennato nel primo passaggio, i server di database in genere dispongono solo di un altro server (o più) che si connettono ad esso. In questo caso, l'accesso al server sulle porte del database dovrebbe essere bloccato in qualsiasi altro luogo. Consentendo solo il traffico SQL da e verso gli indirizzi IP designati, puoi essere sicuro che un attore malintenzionato o un client infetto all'interno del firewall non colpisca il tuo server. In alcuni casi, i client dovranno connettersi direttamente al server di database stesso, ad esempio con un'applicazione front-end thick client. La stessa logica si applica qui, limitando quelle connessioni SQL agli IP specifici (o almeno al segmento IP) che ne hanno bisogno. Poiché si tratta di endpoint, assicurati di proteggerli correttamente, poiché il malware può eseguire la scansione e attaccare i server SQL. Puoi gestire questo con iptables su Linux, il firewall di Windows o, preferibilmente, un dispositivo firewall dedicato.

6. Utilizzare il privilegio minimo durante l'assegnazione delle autorizzazioni

Gli utenti del database, come gli utenti di qualsiasi sistema, dovrebbero avere solo l'accesso di cui hanno bisogno per svolgere i loro compiti, noto anche come principio del privilegio minimo. Se possibile, stai lontano dalle concessioni "TUTTE" in MySQL e dall'appartenenza al ruolo sysadmin in MSSQL. Prendere in considerazione la possibilità di concedere l'accesso in lettura alle viste anziché direttamente alle tabelle, per proteggere i campi sensibili, se necessario. Le stored procedure, i piani di manutenzione e altre attività automatizzate devono essere eseguite come utenti dedicati con il set di autorizzazioni appropriato. Questa misura impedisce a qualsiasi parte del server del database, o a qualsiasi utente malintenzionato o compromesso, di distruggere l'intero sistema. Spesso le istruzioni dell'applicazione richiedono che tu metta i loro utenti in un ruolo di amministratore con accesso completo. Questo è contrario alle procedure consigliate generali e in genere rappresenta una programmazione sciatta, che richiede più accesso del dovuto, o il desiderio di rimuovere la sicurezza dalle considerazioni di supporto, nessuna delle quali ha in mente l'interesse dei dati, quindi considerare sempre in che modo l'implementazione degli account dell'applicazione può influire sulla resilienza complessiva.

7. Imposta una password amministratore complessa

In MSSQL, l'account sa viene utilizzato ogni volta che viene selezionata l'autenticazione in modalità mista. Microsoft consiglia di utilizzare l'autenticazione integrata di Windows, ma molte applicazioni richiedono la modalità mista per supportare gli utenti del database e le stringhe di connessione. Se l'autenticazione in modalità mista è abilitata, assicurarsi di proteggere l'account sa con una password complessa per evitare che venga forzata con la forza bruta.

Allo stesso modo, l'utente root per MySQL dovrebbe avere una password complessa. Se qualcuno sta scansionando il tuo server di database, la prima cosa che farà è provare ad accedere come account amministratore predefinito, quindi il mancato blocco può comportare la compromissione totale del sistema.

8. Controllare gli accessi al DB

Parte della registrazione e del monitoraggio complessivi dovrebbe includere il controllo degli accessi per il database SQL. Per lo meno, questi record si riveleranno utili in situazioni forensi, ma se monitorati regolarmente o addirittura integrati in un sistema di notifica automatizzato, gli accessi ripetuti non riusciti possono avvisare di attacchi e altri problemi prima che diventino critici, consentendo di disabilitare gli utenti compromessi o modificare le loro password, mentre la registrazione degli accessi riusciti tiene traccia di quali amministratori, Gli utenti e le applicazioni si sono collegati, facilitando la risoluzione dei problemi e la gestione delle modifiche.

9. Proteggi i tuoi backup

Indovina un po'? I backup hanno gli stessi dati dei database di produzione e devono essere protetti con la stessa cura del server stesso. Ciò può significare bloccare le directory di backup, limitare l'accesso al server o allo storage che ospita i dati, la sicurezza fisica dei supporti rimovibili, l'accesso alla rete ai backup e verificare chi ha accesso per eseguire e accedere ai backup. Non dimenticare che i backup fanno parte del tuo ecosistema di dati quando si tratta di sicurezza, altrimenti qualcuno potrebbe semplicemente passare attraverso la finestra aperta per aggirare la porta barricata.

10. Proteggersi dall'iniezione SQL

Quando un'applicazione Web accetta l'input dell'utente e lo invia al database, i dati non disinfettati possono "iniettare" codice dannoso nel server ed eseguire attività non autorizzate, incluso l'accesso completo alla shell, a seconda della configurazione del server. Chiamato SQL injection, ci sono diversi modi per mitigare questi attacchi, incluso il passaggio 6 sopra, limitando la capacità degli utenti di eseguire attività non autorizzate, ma in realtà c'è solo un modo per prevenirli, ed è quello di utilizzare stored procedure invece di query SQL dirette per l'interazione con le webapp.

Le stored procedure accettano solo parametri prestabiliti e possono eseguire solo funzioni molto specifiche, quindi impediscono l'inserimento di dati in una query SQL non elaborata. Questa è la best practice da molti anni ormai, ma molte applicazioni di produzione eseguono ancora codice con vulnerabilità SQL, una delle vulnerabilità più comunemente sfruttate su Internet.

11. Visibilità continua

Installare e configurare tutto in modo sicuro può farti risparmiare un sacco di problemi su tutta la linea. Tuttavia, l'unico modo per garantire che il sistema di database rimanga sicuro consiste nell'avere una visibilità costante sullo stato di configurazione, con l'esecuzione di test in base a una policy creata dall'utente. In questo modo, riceverai una notifica quando qualcosa cambia, ad esempio un nuovo utente db aggiunto come amministratore di sistema o a cui vengono dati i db_owner permessi. Senza qualcosa del genere, stai essenzialmente indovinando che nulla è cambiato dall'ultimo controllo, o anche se vuoi essere sicuro, devi raccogliere manualmente le tue informazioni di configurazione, il che richiede tempo e in definitiva inutile, poiché eseguire lo stesso controllo in futuro richiederebbe una replica di tale sforzo. UpGuard offre una visibilità continua sui sistemi di database SQL, nonché sul resto dei server e dei dispositivi di rete.