Il traffico di rete è crittografato quando si scrivono backup remoti utilizzando TDE di SQL Server?


9

Dicono che non esiste una "domanda stupida", quindi ecco:

Comprendo che SQL Server Transparent Data Encryption (TDE) crittografa i dati inattivi, in modo che i file di database (.mdf) e i file di backup (.bak) siano crittografati nel caso in cui qualcuno dovesse entrare nel tuo archivio e rubare quei file. Capisco anche che i dati vengono decodificati quando letti dal disco in modo che non vengano crittografati nella memoria (in movimento). Pertanto, i dati richiesti da un utente che esegue una query remota (selezionare * da SensitiveData) non saranno crittografati quando si viaggia in rete e quindi vulnerabili all'intercettazione.

Quindi, supponendo che tutto quanto sopra sia corretto, ecco la mia stupida domanda: se la mia istanza di SQL Server si trova sul computer A e i miei backup del database TDE sono cancellati per l'archiviazione sul computer remoto B, i dati dell'operazione di backup sono crittografati mentre viaggia da computer A da scrivere sul disco sul computer B? Presumo che debba essere (perché suppongo che l'operazione di crittografia avvenga prima sul computer A), ma non riesco a trovare conferma di ciò in nessuno dei documenti Microsoft o sui blog. E allo stesso modo, durante un'operazione di ripristino - qualcuno avrebbe intercettato i dati trasferiti dal disco sul computer B per ripristinare il database sul computer A - avrebbero trovato quei dati in movimento crittografati?


2
È davvero una bella domanda
Shanky,

Risposte:


7

Sì, i backup vengono crittografati durante lo spostamento in rete perché i dati TDE sono crittografati su disco e l'operazione di backup non li decodifica mai .

Miti di backup di Paul Randal :

Mito 30-09) i backup leggono i dati attraverso il pool di buffer

No. Il sottosistema di backup apre i propri canali ai file del database per evitare l'hit di prestazioni di dover leggere tutto nella memoria di SQL Server e tornare al dispositivo di backup (e anche svuotare efficacemente il pool di buffer nel processo). Se si richiede il controllo del checksum della pagina, utilizza una piccola porzione di memoria.

Se le pagine fossero caricate nel pool di buffer (lo spazio di memoria "normale" che SQL utilizza per memorizzare nella tabella del database e indicizzare i dati), dovrebbero essere decifrati. Ma i backup non lo fanno, ma scaricano semplicemente "estensioni" crittografate non elaborate (blocchi contigui di 8 pagine) nella destinazione di backup.

Sono stato in grado di ottenere la conferma da Paul Randal che il suo commento sopra è ancora rilevante per TDE :

Funziona esattamente allo stesso modo. Il pool di buffer esegue la crittografia, quindi aggiunge un checksum di pagina prima di scrivere una pagina sul disco. I backup non vengono mai letti attraverso il pool di buffer. Quindi sì, un backup del database TDE contiene ancora la crittografia. I checksum della pagina sono convalidati, ma per codice di backup, non per codice pool di buffer.

In altre parole, se hai abilitato CHECKSUM su un database, questi vengono aggiunti (durante le normali operazioni di scrittura SQL) dopo che si verifica la crittografia. Ciò significa che il processo di backup può leggere l'estensione raw (crittografata), convalidare il checksum e scrivere il backup, il tutto senza decrittografare i dati.

Questo è quasi certamente il motivo per cui (prima di SQL 2016), abilitare la compressione del backup su database con TDE non aveva fatto nulla, poiché i dati crittografati non erano molto comprimibili :

Questo perché quando si eseguono i backup di un database crittografato TDE, le pagine del database non vengono decodificate durante il backup. Viene eseguito il backup nello stesso stato crittografato in cui si trovano normalmente, quindi compresso . Per sua natura, i dati crittografati sono davvero unici, quindi la compressione dei dati non fa molto bene ai dati crittografati.

Per un'operazione di ripristino, si applica lo stesso principio. Il backup crittografato rimane crittografato attraverso la rete e viene scritto sul disco del server di ripristino nel loro stato ancora crittografato. Vengono decrittografati solo quando il database viene caricato in memoria dopo il completamento del ripristino.


3

... i dati dell'operazione di backup sono crittografati mentre viaggiano dal computer A per essere scritti sul disco sul computer B?

Sì, viene decrittografato quando entra nel pool buffer e crittografato quando esce. In questa situazione, poiché stiamo scrivendo su disco, viene prima crittografato e poi scritto. Poiché le scritture stanno attraversando la rete, i dati stessi sono crittografati, ma non lo sono le altre parti del traffico di rete.

... durante un'operazione di ripristino ... troverebbero quei dati in movimento crittografati?

Sì, poiché lo stesso vale sopra ma in ordine inverso. I dati sono stati crittografati su disco, vengono letti e trasferiti nello stato crittografato. Quindi arriva all'istanza e viene caricato nel pool di buffer dove non è crittografato come un passaggio lungo la strada.


1
Penso che sia corretto, ma non sono sicuro che sia corretto per i motivi che dici. Ho pensato che un BACKUP invierà EXTENTS di database non elaborati (non pagine) su disco, evitando quindi il passaggio di decodifica quando vengono caricati in memoria. Potrei sbagliarmi, ma sto cercando documentazione ora.
BradC,

1
Trovato, vedi il mito di Paul Randal 30-09 : "Il sottosistema di backup apre i propri canali ai file del database per evitare il colpo di prestazione di dover leggere tutto nella memoria di SQL Server e tornare al dispositivo di backup". Non menziona specificamente TDE, ma se il processo di backup è il proprio canale, sembrerebbe uno spreco decifrare solo per ricodificare immediatamente. Potrebbe anche convalidare CHECKSUMS e / o applicare la compressione senza decrittografare, se abilitati.
BradC,

@BradC Non stavo dicendo che il backup stesso avrebbe funzionato in questo modo, ma come il processo di crittografia / decrittografia avrebbe funzionato con i dati a riposo. Se è ambiguo, lo cambierò, tuttavia non sto dicendo che sia così che funziona un backup proprio quando e dove avviene la crittografia / decrittografia.
Sean Gallardy,

Ma se il processo di backup non utilizza il pool di buffer, il tuo ragionamento non è corretto, anche se la conclusione (i pacchetti di backup sono crittografati) è corretta per un motivo diverso.
BradC,

@BradC No, il ragionamento è che è già scritto su disco, quindi è già crittografato ... Non sono sicuro di come sto ottenendo che sto affermando che un backup viene decrittografato e quindi nuovamente crittografato passando attraverso la BP. Ho pensato che fosse abbastanza semplice dire che era già crittografato, quindi copiare su un altro disco o copiarlo da un altro disco non lo decodifica ... Non sono sicuro di come lo stia confondendo.
Sean Gallardy,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.