Verfügbarkeitsgruppen eignen sich hervorragend für Hochverfügbarkeits-/Disaster-Recovery-Lösungen, und ich bin mir sicher, dass andere DBAs mir zustimmen werden. Es wird jedoch Zeiten geben, in denen wir bestimmte Vorsichtsmaßnahmen und zusätzliche Schritte sorgfältig abwägen müssen, um unerwünschte Überraschungen zu vermeiden. Beispielsweise wird jede sekundäre Replik aus irgendeinem Grund zur aktuellen primären Replik, und unser Ziel ist es, dies zu verhindern.
Es gibt zwei Verschlüsselungsoptionen, die von SQL bereitgestellt werden:sql tde vs. immer verschlüsselt. In diesem Artikel zeige ich ein Szenario, bei dem der DBA besonders auf Details achten muss. Wie der Titel schon sagt, führt es Sie durch den richtigen Umgang mit der Datenverschlüsselung in Datenbanken, die Teil der Einrichtung der AlwaysOn-Verfügbarkeitsgruppe sind.
Erste Überlegungen
Ich werde Transparent Data Encryption (TDE) als Technologie verwenden, um meinen Fall aufzubauen. Sie gilt für alle unterstützten Versionen von SQL Server. Es ist wichtig zu erwähnen, dass diese Funktion nur in den folgenden SQL Server-Editionen verfügbar ist:
- SQL Server 2019 Evaluierung, Standard, Entwickler, Unternehmen
- SQL Server 2017-Evaluierung, Entwickler, Unternehmen
- SQL Server 2016-Evaluierung, Entwickler, Unternehmen
- SQL Server 2014-Evaluierung, Entwickler, Unternehmen
- SQL Server 2012-Evaluierung, Entwickler, Unternehmen
- SQL Server 2008R2 Datacenter, Evaluierung, Entwickler, Unternehmen
- SQL Server 2008 Evaluierung, Entwickler, Unternehmen
Sehen wir uns an, wie wir TDE (Transparent Data Encryption) in SQL Server Standard Edition verwenden können. Zunächst müssen wir einen DMK (Database Master Key) erstellen, um die Daten zu verschlüsseln. Dann erstellen wir ein Zertifikat und einen Schlüssel, um die Daten beim Zugriff entschlüsseln zu können. Vergessen Sie nicht, das Zertifikat zu sichern und schließlich die Verschlüsselung zu aktivieren.
Hinweis: Die TDE-Funktion wird in SQL Server Express Edition nicht unterstützt.
In diesem Beitrag werden die Schritte zum Erstellen einer Verfügbarkeitsgruppe nicht behandelt, und ich verlasse mich auf die bereits zu Testzwecken erstellte. Weitere Informationen zum Bereitstellen von SQL Server AlwaysOn-Verfügbarkeitsgruppen unter Linux finden Sie hier.
Die Umgebung ist Windows-basiert, aber die Prinzipien sind sehr ähnlich, wenn Sie verschiedene Plattformen verwenden (z. B. SQL Server unter Linux oder Azure SQL Managed Instances).
Was ist temporäre Datenverschlüsselung
Der Hauptgrund, warum wir TDE verwenden, ist die Sicherheit von Daten und Protokolldateien für Ihre SQL-Datenbank. Um zu verhindern, dass Ihre persönlichen Daten gestohlen werden, ist es eine gute Idee, sie zu verteidigen, außerdem ist dieser Verschlüsselungsprozess sehr einfach. Bevor die Seite auf die Festplatte geschrieben wird, werden Dateien auf Seitenebene verschlüsselt. Jedes Mal, wenn Sie auf Ihre Daten zugreifen möchten, werden diese entschlüsselt. Nach der TDE-Implementierung benötigen Sie ein bestimmtes Zertifikat und einen Schlüssel, um die Datenbank wiederherzustellen oder anzuhängen. Das ist ein Verschlüsselungsalgorithmus.
Microsoft Beispiel einer SQL Server-Verfügbarkeitsgruppe
Meine Test-Verfügbarkeitsgruppe besteht aus 2 Replikaten, jedes in einer eigenen VM. Hier sind die grundlegenden Eigenschaften:
Wie Sie sehen können, gibt es nichts Besonderes, nur ein paar Replikate im synchronen Commit-Modus und im manuellen Failover-Modus.
Der folgende Screenshot zeigt eine Datenbank namens „test“. Es wird der SQL Server AlwaysOn-Verfügbarkeitsgruppe hinzugefügt und befindet sich im synchronisierten Zustand.
So aktivieren Sie TDE in SQL Server
Hier sind die Schritte zum Aktivieren von SQL Server TDE für die „Test“-Datenbank. Hinweis :Wir führen die folgenden Schritte im aktuellen primären Replikat aus.
Schritt 1
Erstellen Sie einen Hauptschlüssel in der Hauptdatenbank.
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
Schritt 2
Erstellen Sie ein durch den Hauptschlüssel geschütztes Zertifikat.
CREATE CERTIFICATE TestCertificate WITH SUBJECT = 'My test Certificate';Schritt 3
Erstellen Sie den Datenbankverschlüsselungsschlüssel (DEK) und schützen Sie ihn mit dem in Schritt 2 erstellten Zertifikat.
USE test;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TestCertificate;
Schritt 4
Stellen Sie die „test“-Datenbank so ein, dass sie Verschlüsselung verwendet.
ALTER DATABASE test
SET ENCRYPTION ON;
Wie überprüfe ich, ob TDE aktiviert ist?
Wenn Sie fertig sind, müssen Sie bestätigen, dass die transparente Datenverschlüsselung in SQL Server für die „Test“-Datenbank aktiviert ist.
In den Datenbankeigenschaften gehen Sie zu den Optionen Seite. Achten Sie dort auf den Zustand Bereich unten im Fenster. Die Verschlüsselung aktiviert Der Wert muss Wahr sein .
Sie können auch den folgenden TSQL-Code ausführen, um dies zu bestätigen:
SELECT name,is_encrypted
FROM sys.databases
WHERE name = 'test'
Schlüsselverwaltungs- und Zertifizierungsproblem
Hinweis: Seien Sie nicht überrascht, wenn Sie herausfinden, dass tempdb ebenfalls verschlüsselt ist. Dies liegt daran, dass in tempdb alle Arten von Operationen stattfinden (z. B. Sortieren, Hash-Joins usw.), wobei die Daten aus allen Datenbanken verwendet werden. Wenn also mindestens eine Benutzerdatenbank verschlüsselt ist, werden möglicherweise Vorgänge aus dieser bestimmten Datenbank in tempdb übertragen, die diese Daten an die Benutzerdatenbank zurückgeben muss. Daher würde das Zurücksenden unverschlüsselter Daten das Problem darstellen.
Sie können mehr über die Sicherungsverschlüsselung in SQL Server lesen, um die Sicherheit Ihrer Datenbank zu verbessern.
Sie können den folgenden TSQL-Code verwenden, um zu bestätigen, dass ein Datenbank-Hauptschlüssel für die „Test“-Datenbank vorhanden ist, die durch das Zertifikat verschlüsselt ist (wie in Schritt 3 ausgeführt):
SELECT
DB_NAME(database_id) AS DB,
create_date,
key_algorithm,
key_length,
encryptor_thumbprint,
encryptor_type
FROM sys.dm_database_encryption_keys
WHERE DB_NAME(database_id) = 'test'
Soweit so gut, zumindest für die Primary Replica. Aber was passiert, wenn wir die sys.databases abfragen Systemansicht, um den Verschlüsselungsstatus der „Test“-Datenbank im sekundären Replikat zu bestätigen?
Die Verfügbarkeitsgruppe repliziert alles, was mit der Datenbank zu tun hat, von einem Replikat zum anderen. Das sekundäre Replikat gibt jedoch eindeutig an, dass es nicht verschlüsselt ist.
Lassen Sie uns unsere sekundäre Replik auf Hinweise darauf überprüfen:
Der Status der Datenbank ist „Nicht synchronisiert/verdächtig“ – sieht überhaupt nicht gut aus. Nachdem ich jedoch das Fehlerprotokoll des sekundären Replikats überprüft habe, sehe ich Folgendes:
2021-04-10 00:40:55.940 spid39s Error: 33111, Severity: 16, State: 3.
2021-04-10 00:40:55.940 spid39s Cannot find server certificate with thumbprint '0xDF36E3D052086AA05BBB1C64A72A2CAB5A98F240'.
2021-04-10 00:40:55.950 spid39s Error: 33111, Severity: 16, State: 3.
2021-04-10 00:40:55.950 spid39s Cannot find server certificate with thumbprint '0xDF36E3D052086AA05BBB1C64A72A2CAB5A98F240'.
2021-04-10 00:40:55.950 spid39s Always On Availability Groups data movement for database 'test' has been suspended for the following reason: "system" (Source ID 2; Source string: 'SUSPEND_FROM_REDO'). To resume data movement on the database, you will need to resume the database manually. For information about how to resume an availability database, see SQL Server Books Online.
2021-04-10 00:40:55.950 spid39s Error: 3313, Severity: 21, State: 2.
2021-04-10 00:40:55.950 spid39s During redoing of a logged operation in database 'test', an error occurred at log record ID (34:743:1). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.
Das Hauptproblem besteht darin, dass das Zertifikat, das zum Verschlüsseln des Datenbankverschlüsselungsschlüssels der „Test“-Datenbank (Schritt 3) verwendet wird, nicht im sekundären Replikat vorhanden ist.
Warum?
Weil Verfügbarkeitsgruppen keine Daten aus Systemdatenbanken replizieren. Das fehlende Serverzertifikat befindet sich in der Hauptdatenbank des primären Replikats.
Überprüfen und Einrichten des TDE-Zertifikats in SQL Server
Lassen Sie uns eine Sicherung des Serverzertifikats in der Hauptdatenbank des primären Replikats erstellen. Stellen wir es dann in der Master-Datenbank des sekundären Replikats wieder her.
Verwenden Sie den folgenden TSQL-Code, um die Sicherung aus dem aktuellen primären Replikat zu generieren, das die „test“-Datenbank mit aktiviertem TDE enthält:
USE master;
GO
BACKUP CERTIFICATE TestCertificate
TO FILE = 'C:\temp\TestCertificate.cer'
WITH PRIVATE KEY (file='C:\temp\TestCertificate.pvk',
ENCRYPTION BY PASSWORD='<YourStrongPasswordHere>');
Bevor Sie versuchen, das Zertifikat im sekundären Replikat wiederherzustellen, überprüfen Sie zunächst, ob der Datenbank-Hauptschlüssel in der Master-Datenbank vorhanden ist. Wenn nicht, erstellen Sie es genau wie in Schritt 1.
Verwenden Sie den folgenden TSQL-Code, um das Zertifikat im sekundären Replikat wiederherzustellen. Hinweis :Stellen Sie sicher, dass Sie zuerst die .cer- und .pvk-Dateien in das Zielverzeichnis kopieren.
USE master;
GO
CREATE CERTIFICATE TestCertificate
FROM FILE = 'C:\temp\TestCertificate.cer'
WITH PRIVATE KEY (
FILE = N'C:\temp\TestCertificate.pvk',
DECRYPTION BY PASSWORD = '<YourStrongPasswordHere>'
);
Daher bleibt der Zustand der „test“-Datenbank auch nach der Wiederherstellung des Zertifikats im sekundären Replikat unverändert:
Da die Datenbewegung für die „test“-Datenbank angehalten wurde, setzen wir sie manuell fort, um zu sehen, ob wir dieses Mal Glück haben:
Ja! Die Operation war erfolgreich. Die „Test“-Datenbank ist nicht nur vollständig synchronisiert und fehlerfrei, sondern auch mit TDE verschlüsselt.
Außerdem funktioniert nach der Durchführung des manuellen Failovers zum Tauschen der Rollen der Replikate weiterhin alles einwandfrei.
Schlussfolgerung
Die vorgestellte Lösung funktionierte einwandfrei. Es ist jedoch möglicherweise nicht in allen Fällen ideal, insbesondere wenn Sie ein DBA sind, der Dinge gerne „richtig“ plant und erledigt. Ich sehe „richtig“ wie folgt:
- Entfernen Sie die Datenbank aus der Verfügbarkeitsgruppe
- Führen Sie alle Schritte aus, um die transparente Datenverschlüsselung in dem Replikat zu aktivieren, in dem die Datenbank gelesen/geschrieben wird.
- Sichern Sie das Serverzertifikat vom primären Replikat.
- Kopieren Sie die Sicherungsdatei an den/die Speicherort(e) der sekundären Replik(en).
- Stellen Sie das Zertifikat in der Master-Datenbank wieder her.
- Fügen Sie die Datenbank wieder zur Verfügbarkeitsgruppe hinzu.
- Stellen Sie sicher, dass der Betriebszustand der Datenbank korrekt und beabsichtigt ist (abhängig von Ihrer speziellen Einrichtung).
Ich setze doppelte Anführungszeichen für „richtig“, weil ich bei der Präsentation der Lösung die Datenbank im sekundären Replikat als verdächtig markiert habe. Dies allein würde wahrscheinlich viele unerwünschte Flags/Warnungen/Fingerzeige auslösen. Es ist unnötiges Rauschen, das Sie leicht vermeiden können, indem Sie alle Überlegungen zur Planung und ordnungsgemäßen Implementierung von TDE in einem Always On-Verfügbarkeitsgruppen-Setup berücksichtigen.
Zum Abschluss dieses Beitrags überlasse ich Ihnen die offizielle Verschlüsselungshierarchie, die für TDE verwendet wird und die Microsoft auf ihrer Website veröffentlicht hat. Ich möchte Sie daran erinnern, wo jedes Element erstellt wird (entweder in der Master- oder Benutzerdatenbank), damit Sie potenzielle Probleme/Überraschungen mit Verfügbarkeitsgruppen überwinden können.
Falls Sie es nicht wissen, kann SQL Complete Sie bei der Konfiguration von Always Encrypted unterstützen, einer weiteren nützlichen Technologie zum Schutz sensibler Daten.
Denken Sie daran, dass Sie dasselbe berücksichtigen müssen, was in diesem Artikel besprochen wird, wenn Sie beabsichtigen, sich mit Always Encrypted in einem Szenario mit Always On-Verfügbarkeitsgruppen zu befassen. Die von SQL Complete v6.7 eingeführten Funktionen sollen jedoch sicherstellen, dass Sie auf Anhieb erfolgreich sind.
