Puis-je récupérer un certificat TDE en restaurant la base de données MASTER?
10
(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:
Clé principale de service (protégée par Windows; liée aux informations d'identification du compte de service et à une clé d'ordinateur)
Clé principale de la base de données (dans ce cas, celle de la base de données principale)
Certificat
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.
Hmm, alors comment se fait-il que nous puissions restaurer le certificat sur un autre serveur sans restaurer également le SMK (1) ou le master db DMK (2)? S'attache-t-il au SMK / DMK à partir de ce nouveau serveur?
BradC
Ah, je pense que je comprends: lorsque vous exportez le certificat, vous fournissez explicitement une clé pour l'exportation, qui remplace la dépendance du SMK / DMK du serveur d'origine. Lors de l'importation sur le nouveau serveur, vous transférez ensuite la dépendance sur le SMK / DMK du nouveau serveur. Est-ce que ça sonne bien?
BradC
Ouais, c'est à peu près exactement ça. Lorsque vous exportez ou importez un certificat, vous devez fournir un mot de passe utilisé pour crypter / décrypter la sauvegarde. Lorsque vous restaurez la sauvegarde, le certificat est importé et rechiffré avec le DMK du serveur de destination.
db2
5
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 vestacertTOFILE='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 GOCREATE MASTER KEY ENCRYPTION BY PASSWORD ='D1ffPa$$w0rd'
5. restaurer les certificats de sauvegarde dans le serveur UAT (UATserver)
CREATE CERTIFICATE vestacert2FROMFILE='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 masterALTERDATABASE mydb SET ENCRYPTION OFFUSE mydbDROPDATABASE ENCRYPTION KEYUSE masterDROP CERTIFICATE vestacert2 DROP MASTER KEY
9.Maintenant, créez une nouvelle sauvegarde à partir du serveur UAT et restaurez-la sur le serveur final
La restauration du journal échoue car le fichier journal contient toujours un contenu chiffré. Après la désactivation, passez en mode simple, faites un retour pour tronquer le journal et PUIS sauvegarder à nouveau.
IDisposable
0
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.
1.Si vous souhaitez restaurer une sauvegarde chiffrée sur un autre serveur comme d'habitude, vous rencontrez l'erreur suivante
2.Trouvez le nom du cert: dans cet exemple vestacert
3. sauvegarder le certificat à partir du serveur source (Source encryptedserver):
4.Créez un nouveau Master Cert sur le serveur UAT s'il n'existe pas déjà
5. restaurer les certificats de sauvegarde dans le serveur UAT (UATserver)
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
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/
la source
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.
la source