Posso recuperare un certificato TDE ripristinando il database MASTER?


10

(Per fortuna, al momento non siamo in questa situazione, stiamo solo programmando in anticipo per vedere quali sarebbero le nostre opzioni se mai si verificasse.)

Per un database crittografato con Transparent Date Encryption (TDE), una copia del backup del database è irrecuperabile a meno che non si disponga di un backup del certificato utilizzato per crittografarlo.

E se non lo avessi? Ci sono altre opzioni?

In caso di un errore totale del server, il ripristino di un backup del database MASTER su nuovo hardware ripristinerebbe anche il certificato?

Risposte:


9

Poiché TDE si basa su un certificato memorizzato nel master (che viene utilizzato per crittografare la chiave di crittografia del database), ciò funzionerebbe solo se fosse possibile ripristinare il database master su un altro server in modo tale da poter decrittografare il certificato.

Questa è la gerarchia di crittografia TDE:

  1. Chiave master del servizio (protetta da Windows; legata alle credenziali dell'account del servizio e una chiave del computer)
  2. Chiave master del database (in questo caso, quella per il database master)
  3. Certificato
  4. Chiave di crittografia TDE

I primi tre elementi sono memorizzati nel database principale e possono essere sottoposti a backup di tutti. Il quarto è archiviato (crittografato dal certificato n. 3) nell'intestazione del database crittografato.

Pertanto, in uno scenario di errore, è necessario ripristinare una quantità sufficiente della gerarchia di crittografia per consentire la lettura della chiave TDE. SQL Server crea la chiave master del servizio al momento dell'installazione; pertanto, mentre il ripristino del database master in un'altra istanza ripristinerà anche gli elementi 2 e 3, le chiavi necessarie per decrittografarli non saranno presenti. Risultato: dati illeggibili.

Le due opzioni migliori sono ripristinare il certificato (n. 3) da un backup (una buona opzione se il master non può essere ripristinato per qualsiasi motivo) o ripristinare il database master e la relativa chiave master (n. 2) da un backup. Il ripristino della chiave principale può essere un'opzione migliore se si dispone di molti certificati / chiavi protetti da questa chiave e è necessario renderli tutti accessibili contemporaneamente. Ciò comporta le stesse precauzioni normalmente associate al ripristino del database principale (regole di confronto, accessi, nomi di database e percorsi dei file, ecc.)

In generale, consiglierei di ripristinare il master solo in uno scenario di recupero. Per uno scenario di migrazione / ridimensionamento (come l'utilizzo di gruppi di disponibilità / mirroring con un database crittografato con TDE), è meglio eseguire il backup / ripristino del certificato (n. 3) in modo che sia crittografato utilizzando le chiavi master univoche per ogni istanza che si sta spostando per. Sarà necessario includere la chiave privata con il backup del certificato.

In ogni caso, dovrai eseguire backup di chiavi / certificati, quindi proteggili bene e conservali in posizioni ridondanti e sicure. Semplicemente avere un backup di master non ti farà uscire da un disastro di TDE; avrai bisogno di un backup di almeno una chiave o certificato.


Quindi, come è possibile ripristinare il certificato su un altro server senza ripristinare anche SMK (1) o master db DMK (2)? Si "collega" a SMK / DMK da quel nuovo server?
BradC,

Ah, penso di averlo capito: quando esporti il ​​certificato, stai esplicitamente fornendo una chiave per l'esportazione, che sostituisce la dipendenza da SMK / DMK dal server originale. Al momento dell'importazione sul nuovo server, si trasferisce quindi la dipendenza sull'SMK / DMK del nuovo server. Suona bene?
BradC,

Sì, è praticamente esattamente. Quando si esporta o importa un certificato, è necessario fornire una password utilizzata per crittografare / decrittografare il backup. Quando si ripristina il backup, il certificato viene importato e nuovamente crittografato con il DMK del server di destinazione.
db2,

5

1.Se si desidera ripristinare un backup crittografato su un altro server come al solito, si verifica il seguente errore

 Cannot find server certificate with thumbprint …...

2.Trova il nome del certificato: in questo esempio vestacert

   SELECT  * FROM   sys.certificates

3. Eseguire il backup del certificato dal server di origine (Server crittografato di origine):

BACKUP CERTIFICATE vestacert
TO FILE = 'c:\Backup\certificate_TDE_Test_Certificate.cer'
WITH PRIVATE KEY
(FILE = 'c:\Backup\certificate_TDE_Test_Key.pvk',
ENCRYPTION BY PASSWORD = 'Password12#')

4.Creare il nuovo Master Cert sul server UAT se non esiste già

USE master GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'D1ffPa$$w0rd'

5. Ripristinare certificati di backup nel server UAT (UATserver)

CREATE CERTIFICATE vestacert2
FROM FILE = 'C:\tmp\certificate_TDE_Test_Certificate.cer'     
WITH PRIVATE KEY (FILE = 'C:\tmp\LCMS\certificate_TDE_Test_Key.pvk', 
DECRYPTION BY PASSWORD = 'Passsword12#')

6.Dopo questo passaggio il ripristino del backup non presenta alcun errore e tutti i dati sono stati leggibili.

7.Ma la cosa divertente è che la semplice rimozione della crittografia, l'esecuzione di un nuovo backup e il ripristino sul server finale (Final Server) non funziona e genera il seguente errore Il file "mydb_log" non è stato inizializzato correttamente. Esaminare i log degli errori per ulteriori dettagli.

8.Il modo corretto di rimuovere la crittografia da UAT è rimuovere tutti i segni come sotto passo dopo passo e dal basso verso l'alto

    USE master
    ALTER DATABASE mydb SET ENCRYPTION OFF
    USE mydb
    DROP DATABASE ENCRYPTION KEY 
    USE master
    DROP CERTIFICATE vestacert2 
    DROP MASTER KEY

9.Ora creare un nuovo backup dal server UAT e ripristinarlo sul server finale

buon articolo: http://sqlserverzest.com/2013/10/03/sql-server-restoring-a-tde-encrypted-database-to-a-different-server/


1
Il ripristino del registro non riesce perché il file di registro ha ancora contenuti crittografati. Dopo aver disabilitato, passare alla modalità Semplice, eseguire un back per troncare il registro e POI di nuovo il backup.
IDisposibile il

0

Se il sistema si arresta in modo anomalo e diventa inutilizzabile, è possibile creare un nuovo sistema e ripristinare il database principale su quello esistente per recuperare il certificato TDE purché si utilizzi lo stesso account di servizio sul nuovo sistema. È quindi necessario riavviare il sistema per correggere la crittografia della chiave master del servizio mediante la chiave del computer locale. Successivamente, dovresti essere in grado di eseguire il backup del certificato TDE o ripristinare il database utente e accedere ai dati. La chiave master del servizio è protetta dall'API Data Protection del server Windows in due modi, innanzitutto utilizzando la chiave del computer locale specifica per il sistema e in secondo luogo utilizzando l'account del servizio del motore di database. Poiché non si avrà più la chiave del computer locale del sistema originale a causa di un arresto anomalo del sistema, è necessario utilizzare lo stesso account di servizio. Il backup del certificato TDE viene eseguito con il database, ma inaccessibile fino al completamento della gerarchia di crittografia.

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.