Restaurer les sauvegardes SQL chiffrées après une panne

Une sauvegarde intacte peut être inutilisable sur un serveur de remplacement. Si la clé privée du certificat nécessaire n'existe que sur l'instance perdue, copier le fichier ne suffit pas. Le plan de reprise doit inclure le matériel cryptographique et une méthode testée pour l'utiliser ailleurs.

Identifier la protection réelle

Distinguez chiffrement explicite des sauvegardes et Transparent Data Encryption. Le premier utilise l'encrypteur configuré pour la sauvegarde. TDE protège la base via une clé de chiffrement dont le protecteur doit être disponible lors du déplacement ou de la restauration. Une chaîne peut dépendre des deux mécanismes.

Pour une protection par certificat, inventoriez les certificats de master et associez leurs empreintes aux sauvegardes. Cette requête est un point de départ, pas une preuve que chaque certificat est nécessaire à chaque fichier.

USE master;
SELECT name, thumbprint, expiry_date,
       pvt_key_encryption_type_desc
FROM sys.certificates
WHERE name NOT LIKE '##%'
ORDER BY name;

Faites la correspondance avec les métadonnées réelles de sauvegarde ou de restauration. Le nom lisible peut varier entre serveurs ; l'identité cryptographique doit correspondre. Avec une clé asymétrique ou un fournisseur externe, suivez son chemin de reprise documenté plutôt que la recette de fichiers ci-dessous.

Ne supposez pas que la sauvegarde de la base utilisateur contient tout pour amorcer son propre déchiffrement. La destination doit disposer du protecteur et de l'accès à sa clé privée avant la restauration chiffrée.

Exporter le certificat avec sa clé privée

Le modèle concerne un certificat existant nommé BackupRecoveryDemo. Remplacez nom, chemins et secret. Le répertoire doit exister et être accessible au service SQL Server. Ce script ne crée pas d'encrypteur et ne modifie aucun job.

USE master;
BACKUP CERTIFICATE [BackupRecoveryDemo]
TO FILE = 'D:\KeyExport\BackupRecoveryDemo.cer'
WITH PRIVATE KEY
(
    FILE = 'D:\KeyExport\BackupRecoveryDemo.pvk',
    ENCRYPTION BY PASSWORD = 'REPLACE_WITH_A_UNIQUE_SECRET'
);

Le fichier .cer seul ne suffit pas lorsqu'une clé privée est nécessaire. Conservez la clé privée chiffrée et son mot de passe par des canaux de reprise contrôlés et indépendants. Stocker l'unique mot de passe dans la base que cette même clé protège crée une dépendance circulaire.

Le modèle d'import s'exécute dans master sur la destination. Il suppose une clé principale de base déjà présente et utilisable par l'opérateur autorisé. Préparez explicitement ce prérequis s'il manque, sans remplacer aveuglément une clé existante.

USE master;
CREATE CERTIFICATE [BackupRecoveryDemo]
FROM FILE = 'D:\KeyImport\BackupRecoveryDemo.cer'
WITH PRIVATE KEY
(
    FILE = 'D:\KeyImport\BackupRecoveryDemo.pvk',
    DECRYPTION BY PASSWORD = 'REPLACE_WITH_A_UNIQUE_SECRET'
);

Le mot de passe d'export déchiffre le fichier privé lors de l'import. Ce n'est ni le mot de passe de connexion SQL ni nécessairement celui de la clé principale cible. Distinguez ces secrets dans la procédure.

Après import, vérifiez empreinte et disponibilité de la clé privée. Supprimez les copies de travail selon la procédure tout en conservant les copies durables de reprise. Ne placez pas les vrais secrets dans tickets, dépôt de code ou transcriptions partagées.

Tester sans dépendre de l'ancienne instance

Une répétition sur le serveur d'origine peut réussir simplement parce que le certificat y existe. Utilisez une instance isolée dont l'inventaire est connu. Restaurez la chaîne complète, différentielle et journal nécessaire jusqu'au point souhaité, puis effectuez contrôles de cohérence et essais applicatifs.

Notez fichiers, empreintes, récupération des secrets, permissions, durée et point obtenu. RESTORE VERIFYONLY apporte une information utile, mais ne remplace pas une restauration terminée et une base exploitable.

La rotation ne supprime pas la nécessité de déchiffrer les anciennes sauvegardes conservées. Gardez les anciens protecteurs tant qu'une chaîne requise en dépend. Une nouvelle sauvegarde complète sous un nouveau certificat ne réécrit pas les anciens fichiers ni les journaux existants.

Testez aussi indisponibilité du stockage de secrets, mot de passe manquant et reprise par un autre opérateur autorisé. Vérifiez que les fichiers nécessaires sont identifiables sans mémoire personnelle de l'administrateur initial. L'objectif est de reconstruire tout le chemin de déchiffrement lorsque le serveur et son état local ont disparu.

Références techniques: Microsoft Learn: BACKUP CERTIFICATE · Microsoft Learn: Backup encryption · Microsoft Learn: Moving a TDE database.