Wie überprüfe ich, ob die Verschlüsselung des Datenbankhauptschlüssels gültig ist?

Ich habe ein Szenario, in dem ich eine Datenbank von einem Server auf einen anderen wiederherstelle. Auf dem Quellserver wird der Datenbankhauptschlüssel (DMK) sowohl mit einem Kennwort als auch mit dem Diensthauptschlüssel (SMK) verschlüsselt. Wenn ich es auf dem neuen Server wiederherstelle, wird in der Zeile sys.key_encryptionsweiterhin angezeigt, dass es vom SMK verschlüsselt wurde. Dies ist jedoch nicht der Fall, da die SMKs zwischen den beiden Servern nicht übereinstimmen. Gibt es eine programmgesteuerte Möglichkeit, um zu überprüfen, ob das DMK tatsächlich mit dem SMK dieses Servers verschlüsselt ist ?

Um programmgesteuert festzustellen, ob das aktuelle SMK zum Schutz des DMK verwendet wurde, sollten Sie einfach einen Vorgang versuchen können, für den das DMK erforderlich wäre. Eine solche Operation müsste zuerst das DMK entschlüsseln, um es zu verwenden. Angenommen, Sie haben das DMK nicht explizit geöffnet (unter Verwendung des beim Erstellen angegebenen Kennworts), erfordert das Entschlüsseln des DMK das SMK. Wenn das aktuelle SMK nicht das richtige SMK ist, wird das DMK nicht automatisch entschlüsselt und der Vorgang schlägt fehl. Damit:

• Wenn Sie ein Zertifikat haben, das garantiert in der wiederherzustellenden Datenbank vorhanden ist, versuchen Sie es:

  SELECT SIGNBYCERT( CERT_ID( '{certificate_name}' ), 'test' );

  Das sollte einen nicht- NULLVARBINARY-Wert zurückgeben. Wenn der Rückgabewert ist NULL, muss das DMK neu generiert werden (gemäß den nachstehenden Anweisungen).

• Wenn in der wiederherzustellenden Datenbank garantiert kein Zertifikat vorhanden ist, versuchen Sie, eines zu erstellen. Wenn das SMK zum automatischen Entschlüsseln des DMK verwendet werden kann, wird das Zertifikat erstellt, andernfalls schlägt der Vorgang fehl:

  BEGIN TRY
    CREATE CERTIFICATE [TestCert] WITH SUBJECT = 'yadda yadda yadda';
    DROP CERTIFICATE [TestCert];
    PRINT 'All good, yo!';
  END TRY
  BEGIN CATCH
    PRINT ERROR_MESSAGE();
  END CATCH;

Da Sie jedoch gerade eine Datenbank wiederhergestellt haben, die von einer anderen Instanz stammt, und das SMK dieser anderen Instanz nicht in der neuen Instanz wiederhergestellt haben, können Sie davon ausgehen, dass die Antwort lautet: "Nein, das DMK ist nicht mit dem SMK dieses Servers verschlüsselt ."

Dies ist ein erwartetes Szenario, für dessen Behebung die folgenden Schritte erforderlich sind:

USE [newly_restored_db];
OPEN MASTER KEY DECRYPTION BY PASSWORD = '{password}'; -- password used to protect DMK
ALTER MASTER KEY REGENERATE WITH ENCRYPTION BY PASSWORD = '{password}';
CLOSE MASTER KEY;

Die MSDN-Seite für CREATE MASTER KEYStatus (Hervorhebung hinzugefügt):

Bei SQL Server und Parallel Data Warehouse wird der Hauptschlüssel normalerweise durch den Diensthauptschlüssel und mindestens ein Kennwort geschützt. Wenn die Datenbank physisch auf einen anderen Server verschoben wird (Protokollversand, Wiederherstellung der Sicherung usw.), enthält die Datenbank eine Kopie des Hauptschlüssels, der mit dem ursprünglichen Dienst-Hauptschlüssel des Servers verschlüsselt wurde (es sei denn, diese Verschlüsselung wurde explizit mit ALTER entfernt MASTER KEY DDL) und eine Kopie davon, die mit jedem Kennwort verschlüsselt ist, das entweder bei CREATE MASTER KEY- oder nachfolgenden ALTER MASTER KEY DDL-Vorgängen angegeben wurde. Um den Hauptschlüssel wiederherzustellen und alle Daten, die mit dem Hauptschlüssel als Stamm in der Schlüsselhierarchie verschlüsselt wurden, nachdem die Datenbank verschoben wurde, muss der Benutzer entweder die Anweisung OPEN MASTER KEY mit einer der folgenden Anweisungen verwenden die Kennwörter, die zum Schutz des Hauptschlüssels verwendet werdenStellen Sie eine Sicherung des Hauptschlüssels oder eine Sicherung des ursprünglichen Diensthauptschlüssels auf dem neuen Server wieder her.

Die MSDN-Seite für OPEN MASTER KEYStatus:

Wenn eine Datenbank zum ersten Mal an eine neue Instanz von SQL Server angehängt oder wiederhergestellt wird, ist eine Kopie des Datenbankhauptschlüssels (verschlüsselt mit dem Diensthauptschlüssel) noch nicht auf dem Server gespeichert. Sie müssen die Anweisung OPEN MASTER KEY verwenden , um den Datenbankhauptschlüssel (DMK) zu entschlüsseln. Sobald das DMK entschlüsselt wurde, haben Sie die Möglichkeit, die automatische Entschlüsselung in Zukunft zu aktivieren, indem Sie die Anweisung ALTER MASTER KEY REGENERATE verwenden , um dem Server eine Kopie des DMK bereitzustellen , die mit dem Service Master Key (SMK) verschlüsselt ist. Wenn eine Datenbank von einer früheren Version aktualisiert wurde, sollte das DMK neu generiert werden, um den neueren AES-Algorithmus zu verwenden. Weitere Informationen zum Regenerieren des DMK finden Sie unter ALTER MASTER KEY (Transact-SQL).. Die Zeit, die erforderlich ist, um den DMK-Schlüssel für das Upgrade auf AES neu zu generieren, hängt von der Anzahl der vom DMK geschützten Objekte ab. Das Regenerieren des DMK-Schlüssels für ein Upgrade auf AES ist nur einmal erforderlich und hat keine Auswirkungen auf zukünftige Regenerierungen im Rahmen einer Schlüsselrotationsstrategie.

Auf der MSDN-Seite für ALTER MASTER KEY heißt es:

Mit der Option REGENERATE werden der Datenbankhauptschlüssel und alle von ihm geschützten Schlüssel neu erstellt. Die Schlüssel werden zuerst mit dem alten Hauptschlüssel entschlüsselt und dann mit dem neuen Hauptschlüssel verschlüsselt. Dieser ressourcenintensive Vorgang sollte während eines Zeitraums mit geringer Nachfrage geplant werden, es sei denn, der Hauptschlüssel wurde kompromittiert.