Verschlüsselte SQL-Backups nach Serververlust wiederherstellen

Eine Backupdatei kann intakt und auf einem Ersatzserver trotzdem unbrauchbar sein. Liegt der private Schlüssel des benötigten Zertifikats ausschließlich auf der ausgefallenen Instanz, genügt das Kopieren der Datei nicht. Der Wiederherstellungsplan muss auch die kryptografischen Voraussetzungen abdecken.

Den tatsächlichen Schutz bestimmen

Unterscheiden Sie ausdrückliche Backupverschlüsselung und Transparent Data Encryption. Die erste verwendet den konfigurierten Backup-Encryptor. TDE schützt die Datenbank über einen Datenbankschlüssel, dessen Schutz auch beim Verschieben oder Wiederherstellen verfügbar sein muss. Eine Wiederherstellungskette kann beide Funktionen betreffen.

Bei zertifikatsbasiertem Schutz inventarisieren Sie Zertifikate in master und speichern Thumbprints bei den Backupinformationen. Die Abfrage ist ein Ausgangspunkt und beweist nicht, dass jedes Zertifikat für jede Sicherung benötigt wird.

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

Ordnen Sie den Encryptor anhand tatsächlicher Backup- oder Restore-Metadaten zu. Der freundliche Zertifikatsname darf zwischen Servern abweichen; die kryptografische Identität ist entscheidend. Bei asymmetrischen Schlüsseln oder externem Schlüsselmanagement benötigen Sie stattdessen dessen dokumentierten Wiederherstellungsweg.

Gehen Sie nicht davon aus, dass die Sicherung der Benutzerdatenbank alle Voraussetzungen zur eigenen Entschlüsselung enthält. Die Zielinstanz benötigt den passenden Schutz und Zugriff auf das private Schlüsselmaterial, bevor sie die verschlüsselte Wiederherstellung durchführen kann.

Zertifikat und privaten Schlüssel exportieren

Die Vorlage exportiert ein bereits vorhandenes Zertifikat namens BackupRecoveryDemo. Ersetzen Sie Namen, Pfade und Geheimnis durch vorgesehene Werte. Das Verzeichnis muss existieren und für den SQL-Server-Dienst zugänglich sein. Der Befehl richtet keine Backupverschlüsselung ein.

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'
);

Die .cer-Datei allein reicht nicht, wenn die Wiederherstellung den privaten Schlüssel benötigt. Bewahren Sie die verschlüsselte Schlüsseldatei und ihr Exportpasswort über kontrollierte, unabhängige Wiederherstellungswege auf. Das einzige Passwort in derselben geschützten Datenbank zu speichern erzeugt eine zirkuläre Abhängigkeit.

Die Importvorlage läuft auf der Zielinstanz in master. Sie setzt einen vorhandenen, für den berechtigten Operator nutzbaren Database Master Key voraus. Fehlt dieser, bereiten Sie ihn bewusst vor, statt einen vorhandenen Hauptschlüssel blind zu ersetzen.

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'
);

Das Exportpasswort entschlüsselt die private Datei beim Import. Es ist weder das SQL-Anmeldepasswort noch zwingend das Passwort des Ziel-Master-Keys. Unterscheiden Sie die Geheimnisse im Ablaufplan, damit ihre Rolle im Notfall klar bleibt.

Prüfen Sie nach dem Import Thumbprint und Verfügbarkeit des privaten Schlüssels. Entfernen Sie temporäre Arbeitskopien nach dem vorgesehenen Verfahren und erhalten Sie die dauerhaften Wiederherstellungskopien. Echte Schlüssel und Passwörter gehören nicht in Tickets oder Quellcode.

Einen unabhängigen Wiederherstellungsweg testen

Eine Probe auf der ursprünglichen Instanz kann nur deshalb funktionieren, weil das Zertifikat schon vorhanden ist. Verwenden Sie eine isolierte Ersatzinstanz mit bekanntem Schlüsselbestand. Stellen Sie die benötigte Voll-, Differenz- und Logfolge bis zum gewünschten Punkt wieder her und prüfen Sie anschließend Datenbankkonsistenz und grundlegende Anwendungsfunktionen.

Dokumentieren Sie Dateien, Thumbprints, Geheimnisabruf, Rechte des Operators, Dauer und erreichten Wiederherstellungspunkt. RESTORE VERIFYONLY liefert nützliche Hinweise zur Sicherung, ersetzt aber keine vollständig wiederhergestellte und verwendbare Datenbank.

Eine Schlüsselrotation beseitigt nicht die Abhängigkeit alter Backups. Bewahren Sie bisherige Schutzschlüssel so lange auf, wie eine benötigte Wiederherstellungskette sie verlangt. Eine neue Vollsicherung unter neuem Zertifikat ändert keine alten Dateien und bereits vorhandenen Logs.

Testen Sie auch den Ausfall der Geheimnisablage, ein fehlendes Exportpasswort und die Durchführung durch einen anderen berechtigten Mitarbeiter. Prüfen Sie dabei, ob dieser die richtigen Dateien eindeutig identifizieren kann, ohne Wissen des ursprünglichen Administrators vorauszusetzen. Entscheidend ist ein rekonstruierbarer Entschlüsselungsweg, wenn Server und lokaler Zustand verloren sind.

Technische Referenzen: Microsoft Learn: BACKUP CERTIFICATE · Microsoft Learn: Backup encryption · Microsoft Learn: Moving a TDE database.