Wann muss ich den Service Master Key sichern?


14

Ich lese eine Dokumentation und ein Whitepaper über transparente Datenverschlüsselung. In einigen Dokumentationen wird auch das Sichern des Service-Hauptschlüssels erwähnt (zur Verdeutlichung spreche ich nicht über den Datenbank-Hauptschlüssel). Ich verstehe nur nicht genau, warum dies erforderlich ist, da ich eine Datenbank mit TDE-Verschlüsselung von Server A (Sicherung) auf Server B (Wiederherstellung) ohne Verwendung eines Diensthauptschlüssels sichern / wiederherstellen konnte.

In welchem ​​Szenario muss ich den Service Master Key wiederherstellen?


Sind Sie sicher, dass Sie die Verschlüsselung für Ihre Datenbank aktiviert haben? Haben Sie auch die Datenbanksicherung erstellt, nachdem TDE aktiviert wurde?
Thomas Stringer

Ja, habe ich. Ich brauchte das Zertifikat und den Schlüssel, um es auf Server B wiederherzustellen. (Ich habe ein Backup des Zertifikats und des Schlüssels erstellt.) In BI wurde jedoch ein neuer Hauptschlüssel erstellt (der nicht von Server A wiederhergestellt wurde), und meine Datenbank konnte wiederhergestellt werden.
gsharp

Wenn Sie das TDE-Zertifikat und den privaten Schlüssel auf Server B wiederhergestellt haben, sollte es in der Lage sein, die TDE-Datenbank zu entschlüsseln. Können Sie auf das Dokument verweisen, in dem Sie die Anforderungen für SMK gelesen haben? Vielleicht ist etwas nuancierter ...
Remus Rusanu

Ich bin mit @RemusRusanu einverstanden. Das Zertifikat ist das, was die Verschlüsselung antreibt. Was den Service-Hauptschlüssel angeht, so ist es nur eine allgemeine bewährte Verwaltungspraxis, dies für DR zu sichern (etwas, das ursprünglich hätte getan werden müssen), glaube ich.
Thomas Stringer

1
@gsharp: Damit wird dokumentiert, wie das SMK gesichert wird. Ich war an einer Dokumentation interessiert, die erklärt, warum die SMK-Sicherung für die Übertragung einer TDE-verschlüsselten Datenbank erforderlich ist.
Remus Rusanu

Antworten:


6

Wenn Sie über den SQL-Dienst-Hauptschlüssel sprechen, müssen Sie ihn in seltenen Fällen wirklich wiederherstellen.

Ich denke an ein paar Szenarien, in denen Sie das SMK wiederherstellen müssen ...

  1. Irgendwie wurde es beschädigt.

  2. Sie bauen Ihren SQL Server neu auf und planen, jede Datenbank einschließlich der Systemdatenbanken aus einer Sicherung wiederherzustellen. In der Regel müssen Sie in diesem Fall möglicherweise auch das SMK nicht wiederherstellen, wenn Sie dasselbe SQL-Dienstkonto und Kennwort verwenden.

In TDE müssen Sie das SMK nicht wiederherstellen. Wie jeder sagte, brauchen Sie nur das Zertifikat und den privaten Schlüssel. Sie müssen nicht denselben Datenbankhauptschlüssel haben, auch wenn Sie das Zertifikat aus einer Sicherungskopie erstellen, wird es vom DMK des Zielcomputers verschlüsselt.


2

Wenn Sie eine TDE-Datenbank in eine neue Instanz verschieben, müssen Sie sicherstellen, dass sich das richtige Zertifikat (oder der richtige asymmetrische Schlüssel) auch in der Zieldatenbank befindet master. Wenn Sie dies nicht tun, erhalten Sie folgende Fehlermeldung:

Meldung 33111, Ebene 16, Status 3, Zeile 2 Serverzertifikat mit Fingerabdruck "0xA085414434DB4A36B29 .................." kann nicht gefunden werden.

Es ist nicht der Service-Hauptschlüssel, der mit der TDE-fähigen Datenbanksicherung verschoben werden muss, sondern das Zertifikat. Angenommen , Sie haben Ihr DEK (Datenbank-Verschlüsselungsschlüssel) mit einem Zertifikat mit dem masterNamen MyTDECert erstellt . Ohne dieses Zertifikat auf Ihrer Zielinstanz können Sie Ihre Datenbank nicht wiederherstellen.


Ja das ist klar Meine Frage ist eher, warum (oder zu welchem ​​Zweck) eine Sicherungskopie des Diensthauptschlüssels erstellt werden muss. Siehe technet.microsoft.com/en-us/library/aa337561
gsharp

-1

Ein Fall, in dem Sie das SMK sichern und wiederherstellen müssen, ist das Aktualisieren einer Replikationstopologie.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.