Implicazioni sulla sicurezza del ripristino di un backup da una fonte sconosciuta?

Scenario : ti viene consegnato un backup del database e ti viene detto di ripristinarlo su un server (che sta già ospitando altri database), ma non ti vengono fornite informazioni utili su ciò che il backup contiene o sull'origine della fiducia.

Domanda 1 : Quali sono le potenziali implicazioni del ripristino di un backup che potrebbe essere dannoso?

Domanda 2 : cosa puoi fare per proteggere il tuo server / i dati in altri database dall'impatto del ripristino di un backup potenzialmente dannoso? RESTORE VERIFYONLYsembrerebbe essere un buon primo passo. La risposta definitiva è probabilmente "ripristinare il database in una VM sandbox senza accesso al mondo esterno", ma supponiamo che l'opzione non sia disponibile. Cos'altro si dovrebbe fare in questa situazione?

Un database può contenere codice dannoso, possibilmente una procedura che cambierà una password per il login "sa" o eliminerà ogni database. Tuttavia, l'unico modo in cui posso vedere che causare un problema è che un individuo ripristini il database e quindi esegua manualmente qualsiasi codice all'interno di quel database. Non verrebbe eseguito in alcun modo automatizzato.

Non esiste alcuna impostazione che può essere applicata all'interno di un database in modo che SQL Server esegua automaticamente alcuni bit di codice all'interno del database al momento del ripristino su un server. Se così fosse, mi aspetterei che Microsoft perderebbe la certificazione Common Criteria per il prodotto. Questo è un grande bug per avermi permesso in un DBMS.

Ci sono alcuni passaggi di prevenzione che potresti fare.

1. Assicurarsi che nessuno, tranne un amministratore di sistema, abbia accesso al database ripristinato.
2. Mettere il db in modalità utente singolo al termine del ripristino.
3. Controllare il codice all'interno di tutte le procedure e funzioni memorizzate e trigger all'interno di questo database.
4. Eseguire un checkdb dbcc per assicurarsi che non vi siano problemi di integrità.
5. Controllare gli utenti che avevano accesso al database e rimuoverli tutti.
6. Inizia a consentire l'accesso, molto limitato a oggetti specifici controllati da te.

Come ha detto Shawn, il codice non verrà eseguito da solo a meno che una procedura memorizzata che sembra vbalid non abbia un dirigente di un altro codice dannoso. Questo è il motivo per controllare il codice all'interno di ognuno di essi prima di metterlo in modalità multiutente.

Sto raggiungendo qui, ma riesco a pensare ad almeno uno scenario pericoloso: se ripristini un database che ha un filetable , quei file sono ora sulla tua rete per impostazione predefinita (e specificamente, su SQL Server). È possibile ripristinare un virus.

Che da solo non farà nulla, ovviamente - il virus non diventa improvvisamente senziente - ma se i tuoi utenti provano ad accedere al file, potrebbero essere infetti. (Ehi, ho detto che stavo raggiungendo.) Sto immaginando uno scenario in cui un hacker esterno vuole ottenere malware alla porta, e quindi invia un'email a Bob nella contabilità dicendo: "Ecco il file: \ sqlserver \ filetableshare \ myvirus.exe "- a quel punto è passato oltre i firewall senza essere rilevato, e ora siamo passati ai tuoi strumenti interni antivirus e antimalware.

RESTORE VERIFYONLY sembrerebbe essere un buon primo passo. La risposta definitiva è probabilmente "ripristinare il database in una VM sandbox senza accesso al mondo esterno", ma supponiamo che l'opzione non sia disponibile. Cos'altro si dovrebbe fare in questa situazione?

Ripristina verifica solo l'integrità del database. NON ti dirà se il backup include codice dannoso o meno RESTORE VERIFYONLY non tenta di verificare la struttura dei dati contenuti nei volumi di backup. È altamente poco gradito il fatto che se il backup proviene dall'azienda in cui si lavora potrebbe essere dannoso, ma se proviene da terze parti è necessario fare attenzione come indicato da Shawn.

La documentazione di Microsoft Online dice questo

• Per motivi di sicurezza, si consiglia di non collegare o ripristinare database da fonti sconosciute o non attendibili. Tali database potrebbero contenere codice dannoso che potrebbe eseguire codice Transact-SQL non intenzionale o causare errori modificando lo schema o la struttura fisica del database. Prima di utilizzare un database da un'origine sconosciuta o non attendibile, eseguire DBCC CHECKDB sul database su un server di non produzione ed esaminare anche il codice, ad esempio procedure memorizzate o altro codice definito dall'utente, nel database.

La domanda si concentra principalmente su un backup contenente malware, ma è anche possibile ottenere comportamenti indesiderati e potenzialmente dannosi dall'operazione di ripristino stessa.

In passato ho scoperto accidentalmente che è possibile arrestare in modo anomalo SQL Server tentando di ripristinare un file di backup corrotto che fa sì che SQL Server tenti di leggere oltre la fine del file di backup e si blocchi. Non sono sicuro di quali versioni siano sensibili o esattamente cosa è necessario per riprodurre il problema. Ho documentato alcuni dettagli limitati qui quando ho riscontrato questo problema alcuni anni fa.

Che rischio c'è di ripristinare un database sconosciuto da una fonte sconosciuta? Nessuna.

Qual è il rischio di consentire a un'applicazione sconosciuta di connettersi utilizzando un account sysadmin per connettersi a quel database e avviare l'esecuzione del codice? MOLTE! Se l'account dell'applicazione ha solo diritti all'interno del database e non ha accesso a livello di server, non c'è nulla che possa realmente fare al di fuori del database. Questo in sostanza si riduce all'avvio di una corretta configurazione del framework di sicurezza sul server.

Ti viene consegnato un backup del database e ti viene detto di ripristinarlo su un server (che sta già ospitando altri database), ma non ti vengono fornite informazioni utili su cosa contiene il backup o se l'origine dovrebbe essere attendibile.

Bello. Richiedete una dichiarazione scritta firmata da chiunque vi stia dicendo di accettare la piena responsabilità delle conseguenze. Se non sono disposti a farlo, dovresti testare l'installazione in una sandbox dopo aver esaminato il file di backup (se possibile) ed esaminare attentamente tutte le tabelle, le procedure, ecc. Se qualcosa ha un odore divertente in qualsiasi momento, non metterlo su il sistema di produzione. Anche allora, dovresti chiarire (al tuo capo e ai suoi superiori) che non ti sei mai fidato del backup e lo stai facendo solo su ordini diretti.

Se non firmano una simile dichiarazione, avvisa i loro superiori prima di fare qualsiasi cosa. In qualità di professionista, è tuo dovere proteggere il tuo sistema il più possibile, indipendentemente da ciò che un ingannevole superiore può ordinarti di fare. Potresti essere licenziato, ma puoi tenere la testa alta e sapere di aver fatto la cosa giusta.

Non ci sono molti pericoli per dire, a parte alcuni di vasta portata suggeriti qui. Come accennato, è difficile disporre di elementi con esecuzione automatica in un backup del database stesso. Ha bisogno di una sorta di meccanismo di innesco esterno.

Ottieni un vecchio laptop / desktop e una versione di valutazione del tuo software di database (SQLExpress) se la licenza è un problema. Copia il file di backup sul computer, scollega la rete / wireless ed esegui il ripristino. Quindi inizia a scavare. Prenditi tutto il tempo necessario, perché ci sono molti posti che le cose possono nascondere, molte delle quali sono già coperte da altri post in questa discussione.

La tua integrità DBA e il miglioramento del tuo ambiente di produzione sono più importanti di qualsiasi ordine dato da un superiore.