Puis-je récupérer un certificat TDE en restaurant la base de données MASTER?

(Heureusement, nous ne sommes pas actuellement dans cette situation, nous planifions juste à l'avance pour voir quelles seraient nos options si jamais cela se produisait.)

Pour une base de données chiffrée avec Transparent Date Encryption (TDE), une copie de la sauvegarde de la base de données est irrécupérable, sauf si vous disposez d'une sauvegarde du certificat utilisé pour la chiffrer.

Et si vous n'en avez pas? Y a-t-il des options supplémentaires?

En cas de panne totale du serveur, la restauration d'une sauvegarde de la base de données MASTER sur un nouveau matériel restaurerait-elle également le certificat?

Étant donné que TDE repose sur un certificat stocké dans master (qui est utilisé pour crypter la clé de cryptage de la base de données), cela ne fonctionnerait que si vous pouviez restaurer la base de données master sur un autre serveur de manière à ce que le certificat puisse être décrypté.

Voici la hiérarchie de chiffrement TDE:

1. Clé principale de service (protégée par Windows; liée aux informations d'identification du compte de service et à une clé d'ordinateur)
2. Clé principale de la base de données (dans ce cas, celle de la base de données principale)
3. Certificat
4. Clé de chiffrement TDE

Les trois premiers éléments sont stockés dans la base de données principale et peuvent tous être sauvegardés. Le quatrième est stocké (crypté par le certificat de # 3) dans l'en-tête de la base de données cryptée.

Ainsi, dans un scénario d'échec, vous devrez restaurer suffisamment la hiérarchie de chiffrement pour vous permettre de lire la clé TDE. SQL Server crée la clé principale du service lors de l'installation; ainsi, tout en restaurant la base de données principale sur une autre instance restaurera également les éléments 2 et 3, la ou les clés nécessaires pour les déchiffrer ne seront pas présentes. Résultat: données illisibles.

Les deux meilleures options sont soit de restaurer le certificat (# 3) à partir d'une sauvegarde (une bonne option si le maître ne peut pas être restauré pour une raison quelconque), soit de restaurer votre base de données master et sa clé principale (# 2) à partir d'une sauvegarde. La restauration de la clé principale peut être une meilleure option si vous avez beaucoup de certificats / clés protégés par cette clé et devez les rendre tous accessibles en même temps. Cela s'accompagne des mêmes précautions normalement associées à la restauration de la base de données master (classements, connexions, noms de base de données et chemins d'accès aux fichiers, etc.)

En règle générale, je ne recommanderais que la restauration du maître dans un scénario de récupération. Pour un scénario de migration / évolutivité (comme l'utilisation de groupes de disponibilité / mise en miroir avec une base de données chiffrée TDE), il est préférable de sauvegarder / restaurer le certificat (# 3) afin qu'il soit chiffré à l'aide des clés principales uniques à chaque instance qu'il déplace à. Vous devrez inclure la clé privée avec la sauvegarde du certificat.

Dans tous les cas, vous devrez effectuer des sauvegardes de clés / certificats, alors gardez-les bien et stockez-les dans des emplacements redondants et sécurisés. Le simple fait d'avoir une sauvegarde du maître ne vous sortira pas d'une catastrophe TDE; vous allez avoir besoin d'une sauvegarde d'au moins une clé ou un certificat.

1.Si vous souhaitez restaurer une sauvegarde chiffrée sur un autre serveur comme d'habitude, vous rencontrez l'erreur suivante

 Cannot find server certificate with thumbprint …...

2.Trouvez le nom du cert: dans cet exemple vestacert

   SELECT  * FROM   sys.certificates

3. sauvegarder le certificat à partir du serveur source (Source encryptedserver):

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.Créez un nouveau Master Cert sur le serveur UAT s'il n'existe pas déjà

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

5. restaurer les certificats de sauvegarde dans le serveur 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.Après cette étape, la restauration de la sauvegarde ne comporte aucune erreur et toutes les données étaient lisibles.

7.Mais ce qui est drôle, c'est que supprimer le chiffrement simplement et prendre une nouvelle sauvegarde et la restaurer sur le serveur final (Final Server) ne fonctionne pas et donne l'erreur suivante Le fichier "mydb_log" n'a pas pu s'initialiser correctement. Examinez les journaux d'erreurs pour plus de détails.

8.La bonne façon de supprimer le cryptage de l'UAT est de supprimer tous les signes comme ci-dessous étape par étape et de bas en haut

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

9.Maintenant, créez une nouvelle sauvegarde à partir du serveur UAT et restaurez-la sur le serveur final

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

Si votre système se bloque et devient inutilisable, vous pouvez créer un nouveau système et restaurer la base de données master sur l'existant pour récupérer le certificat TDE tant que vous utilisez le même compte de service sur le nouveau système. Vous devez ensuite redémarrer le système pour corriger le chiffrement de la clé principale du service par la clé de l'ordinateur local. Après cela, vous devriez pouvoir sauvegarder le certificat TDE ou restaurer la base de données utilisateur et accéder aux données. La clé principale de service est protégée par l'API de protection des données du serveur Windows de deux manières, d'abord à l'aide de la clé d'ordinateur locale qui est spécifique au système et ensuite à l'aide du compte de service du moteur de base de données. Étant donné que vous n'aurez plus la clé de l'ordinateur local du système d'origine en raison d'une panne du système, vous devez utiliser le même compte de service. Le certificat TDE est sauvegardé avec la base de données, mais inaccessible jusqu'à ce que la hiérarchie de chiffrement soit terminée.