Transparente Datenverschlüsselung

Sie können verschiedene Vorsichtsmaßnahmen zum Schützen der Datenbank treffen, z.B. Entwerfen eines sicheren Systems, Verschlüsseln vertraulicher Datenbestände und Erstellen einer Firewall für die Datenbankserver. Für ein Szenario, in dem die physischen Medien (z. B. Laufwerke oder Sicherungsbänder) gestohlen werden, kann eine böswillige Partei die Datenbank einfach wiederherstellen oder anfügen und die Daten durchsuchen. Eine Lösung dieses Problems besteht darin, die sensiblen Daten in der Datenbank zu verschlüsseln, und den für die Verschlüsselung der Daten verwendeten Schlüssel mit einem Zertifikat zu schützen. Dadurch kann niemand die Daten verwenden, der nicht im Besitz der Schlüssel ist. Diese Art des Schutzes muss jedoch im Voraus geplant werden.

Transparente Datenverschlüsselung (TDE) führt echtzeitbasierte E/A-Verschlüsselung und Entschlüsselung der Daten- und Transaktionsprotokolldateien und der speziellen PDW-Protokolldateien durch. Die Verschlüsselung verwendet einen Datenbank-Verschlüsselungsschlüssel (DEK), der im Startdatensatz der Datenbank gespeichert wird und während der Wiederherstellung zur Verfügung steht. Die DEK ist ein symmetrischer Schlüssel, der mithilfe eines Zertifikats gesichert wird, das in der Masterdatenbank der SQL Server-PDW gespeichert ist. TDE schützt die "ruhenden" Daten, also die Daten- und die Protokolldateien. Sie entspricht den in vielen Branchen etablierten Gesetzen, Bestimmungen und Richtlinien. Mit diesem Feature können Softwareentwickler Daten mithilfe von AES- und 3DES-Verschlüsselungsalgorithmen verschlüsseln, ohne vorhandene Anwendungen zu ändern.

Wichtig

TDE stellt keine Verschlüsselung für Daten bereit, die zwischen dem Client und dem PDW übertragen werden. Weitere Informationen zum Verschlüsseln von Daten zwischen client und SQL Server PDW finden Sie unter Bereitstellen eines Zertifikats.

TDE verschlüsselt keine Daten, während sie verschoben oder verwendet wird. Interner Datenverkehr zwischen PDW-Komponenten innerhalb der SQL Server-PDW ist nicht verschlüsselt. Daten, die vorübergehend in Speicherpuffern gespeichert sind, werden nicht verschlüsselt. Um dieses Risiko zu minimieren, steuern Sie physischen Zugriff und Verbindungen mit dem SQL Server-PDW.

Nachdem sie gesichert wurde, kann die Datenbank mit dem richtigen Zertifikat wiederhergestellt werden.

Hinweis

Wenn Sie ein Zertifikat für TDE erstellen, sollten Sie es sofort zusammen mit dem zugeordneten privaten Schlüssel sichern. Sollte das Zertifikat einmal nicht mehr verfügbar sein, oder sollten Sie die Datenbank auf einem anderen Server wiederherstellen oder anfügen müssen, müssen Sie über Sicherungen sowohl des Zertifikats als auch des privaten Schlüssels verfügen, da Sie andernfalls die Datenbank nicht öffnen können. Das zum Verschlüsseln verwendete Zertifikat sollte beibehalten werden, selbst wenn TDE für die Datenbank nicht mehr aktiviert ist. Selbst wenn die Datenbank nicht verschlüsselt ist, können Teile des Transaktionsprotokolls nach wie vor geschützt sein. Für bestimmte Vorgänge wird das Zertifikat ggf. weiterhin benötigt, bis eine vollständige Sicherung der Datenbank ausgeführt wurde. Ein abgelaufenes Zertifikat kann immer noch verwendet werden, um Daten mit TDE zu verschlüsseln und zu entschlüsseln.

Die Verschlüsselung der Datenbankdatei erfolgt auf Seitenebene. In einer verschlüsselten Datenbank werden die Seiten verschlüsselt, bevor Sie auf den Datenträger geschrieben werden, und entschlüsselt, wenn sie in den Arbeitsspeicher gelesen werden. TDE erhöht nicht die Größe einer verschlüsselten Datenbank.

Die folgende Abbildung zeigt die Hierarchie der Schlüssel für die TDE-Verschlüsselung:

Verwenden der transparenten Datenverschlüsselung

Führen Sie folgende Schritte aus, um TDE zu verwenden: Die ersten drei Schritte werden nur einmal ausgeführt, wenn SQL Server PDW zur Unterstützung von TDE vorbereitet wird.

1. Erstellen Sie einen Hauptschlüssel in der Masterdatenbank.

2. Verwenden Sie sp_pdw_database_encryption , um TDE im SQL Server-PDW zu aktivieren. Dieser Vorgang ändert die temporären Datenbanken, um den Schutz zukünftiger temporärer Daten sicherzustellen, und schlägt fehl, wenn es aktive Sitzungen mit temporären Tabellen gibt. sp_pdw_database_encryption aktiviert die Benutzerdatenmaske in PDW-Systemprotokollen. (Weitere Informationen zum Maskieren von Benutzerdaten in PDW-Systemprotokollen finden Sie unter sp_pdw_log_user_data_masking.)

3. Verwenden Sie sp_pdw_add_network_credentials , um anmeldeinformationen zu erstellen, die sich authentifizieren und in die Freigabe schreiben können, in der die Sicherung des Zertifikats gespeichert wird. Wenn bereits eine Anmeldeinformation für den vorgesehenen Speicherserver vorhanden ist, können Sie die vorhandenen Anmeldeinformationen verwenden.

4. Erstellen Sie in der Masterdatenbank ein zertifikat, das durch den Hauptschlüssel geschützt ist.

5. Sichern Sie das Zertifikat auf der Speicherfreigabe.

6. Erstellen Sie in der Benutzerdatenbank einen Datenbankverschlüsselungsschlüssel, und schützen Sie ihn durch das Zertifikat, das in der Masterdatenbank gespeichert ist.

7. Verwenden Sie die ALTER DATABASE Anweisung, um die Datenbank mithilfe von TDE zu verschlüsseln.

Im folgenden Beispiel wird die Verschlüsselung der AdventureWorksPDW2012 Datenbank mithilfe eines Zertifikats veranschaulicht MyServerCert, das in SQL Server PDW erstellt wurde.

First: Enable TDE on the SQL Server PDW. Diese Aktion ist nur einmal erforderlich.

USE master;  
GO  
  
-- Create a database master key in the master database  
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';  
GO  
  
-- Enable encryption for PDW  
EXEC sp_pdw_database_encryption 1;  
GO  
  
-- Add a credential that can write to the share  
-- A credential created for a backup can be used if you wish  
EXEC sp_pdw_add_network_credentials 'SECURE_SERVER', '<domain>\<Windows_user>', '<password>';  

Second: Create and backup a certificate in the master database. Diese Aktion ist nur einmal erforderlich. Sie können über ein separates Zertifikat für jede Datenbank verfügen (empfohlen), oder Sie können mehrere Datenbanken mit einem Zertifikat schützen.

-- Create certificate in master  
CREATE CERTIFICATE MyServerCert WITH SUBJECT = 'My DEK Certificate';  
GO  
  
-- Back up the certificate with private key  
BACKUP CERTIFICATE MyServerCert   
    TO FILE = '\\SECURE_SERVER\cert\MyServerCert.cer'  
    WITH PRIVATE KEY   
    (   
        FILE = '\\SECURE_SERVER\cert\MyServerCert.key',  
        ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>'   
    )   
GO  

Zuletzt: Erstellen Sie die DEK, und verwenden Sie ALTER DATABASE, um eine Benutzerdatenbank zu verschlüsseln. Diese Aktion wird für jede Datenbank wiederholt, die durch TDE geschützt ist.

USE AdventureWorksPDW2012;  
GO  
  
CREATE DATABASE ENCRYPTION KEY  
WITH ALGORITHM = AES_128  
ENCRYPTION BY SERVER CERTIFICATE MyServerCert;  
GO  
  
ALTER DATABASE AdventureWorksPDW2012 SET ENCRYPTION ON;  
GO  

Die Verschlüsselungs- und Entschlüsselungsvorgänge werden von SQL Server in geplanten Hintergrundthreads ausgeführt. Sie können den Status dieser Vorgänge mithilfe der in der Liste weiter unten in diesem Artikel genannten Katalogsichten und dynamischen Verwaltungssichten anzeigen.

Achtung

Sicherungsdateien von Datenbanken, für die TDE aktiviert wurde, werden ebenfalls mithilfe des Verschlüsselungsschlüssels für die Datenbank verschlüsselt. Darum muss bei der Wiederherstellung dieser Sicherungen das Zertifikat, das zum Verschlüsseln des Verschlüsselungsschlüssels für die Datenbank verwendet wurde, verfügbar sein. Dies bedeutet, dass Sie zusätzlich zur Sicherung der Datenbank auch Sicherungskopien der Serverzertifikate aufbewahren müssen, um einem Datenverlust vorzubeugen. Ist das Zertifikat nicht mehr verfügbar, kann es zu einem Datenverlust kommen.

Befehle und Funktionen

Die für TDE verwendeten Zertifikate müssen mithilfe des Datenbank-Hauptschlüssels verschlüsselt sein, damit sie von den folgenden Anweisungen akzeptiert werden.

Die folgende Tabelle bietet Links und Erläuterungen zu den Befehlen und Funktionen von TDE.

Befehl oder Funktion	Zweck
CREATE DATABASE ENCRYPTION KEY	Erstellt einen Schlüssel, der verwendet wird, um eine Datenbank zu verschlüsseln.
ALTER DATABASE ENCRYPTION KEY	Ändert den Schlüssel, der verwendet wird, um eine Datenbank zu verschlüsseln.
DROP DATABASE ENCRYPTION KEY	Entfernt den Schlüssel, der verwendet wurde, um eine Datenbank zu verschlüsseln.
ALTER DATABASE	Erklärt die ALTER DATABASE -Option, mit der TDE aktiviert wird.

Katalogsichten und dynamische Verwaltungssichten

In der folgenden Tabelle werden die Katalogsichten und die dynamischen Verwaltungssichten von TDE erläutert.

Katalogsicht oder dynamische Verwaltungssicht	Zweck
sys.databases	Katalogsicht, die Datenbankinformationen anzeigt.
sys.certificates	Katalogsicht, die die Zertifikate in einer Datenbank anzeigt.
sys.dm_pdw_nodes_database_encryption_keys	Dynamische Verwaltungsansicht, die Informationen für jeden Knoten, über die in einer Datenbank verwendeten Verschlüsselungsschlüssel und den Verschlüsselungsstatus einer Datenbank bereitstellt.

Berechtigungen

Jede Funktion und jeder Befehl von TDE erfordert bestimmte Berechtigungen, die in den zuvor gezeigten Tabellen beschrieben wurden.

Zum Anzeigen der metadaten, die mit TDE verbunden sind, ist die CONTROL SERVER Berechtigung erforderlich.

Überlegungen

Während eine erneute Verschlüsselungsprüfung für einen Datenbankverschlüsselungsvorgang ausgeführt wird, sind Wartungsvorgänge für die Datenbank deaktiviert.

Sie finden den Status der Datenbankverschlüsselung mithilfe der sys.dm_pdw_nodes_database_encryption_keys dynamischen Verwaltungsansicht. Weitere Informationen finden Sie im Abschnitt "Katalogansichten und dynamische Verwaltungsansichten" weiter oben in diesem Artikel.

Beschränkungen

Die folgenden Vorgänge sind während der CREATE DATABASE ENCRYPTION KEYAnweisungen , ALTER DATABASE ENCRYPTION KEY, DROP DATABASE ENCRYPTION KEYoder ALTER DATABASE...SET ENCRYPTION Anweisungen nicht zulässig.

• Löschen der Datenbank.

• Verwenden eines ALTER DATABASE Befehls.

• Starten einer Datenbanksicherung.

• Starten einer Datenbankwiederherstellung.

Die folgenden Vorgänge oder Bedingungen verhindern die CREATE DATABASE ENCRYPTION KEY, ALTER DATABASE ENCRYPTION KEY, , DROP DATABASE ENCRYPTION KEYoder ALTER DATABASE...SET ENCRYPTION Anweisungen.

• Ein ALTER DATABASE Befehl wird ausgeführt.

• Eine Datensicherung wird ausgeführt.

Beim Erstellen von Datenbankdateien ist die sofortige Dateiinitialisierung nicht verfügbar, wenn TDE aktiviert ist.

Nicht durch TDE geschützte Bereiche

TDE schützt keine externen Tabellen.

TDE schützt diagnosesitzungen nicht. Benutzer sollten vorsichtig sein, keine Abfragen mit vertraulichen Parametern zu verwenden, während Diagnosesitzungen verwendet werden. Diagnosesitzungen, die vertrauliche Informationen offenlegen, sollten gelöscht werden, sobald sie nicht mehr benötigt werden.

Durch TDE geschützte Daten werden entschlüsselt, wenn sie im SQL Server-PDW-Speicher abgelegt werden. Speicherabbilder werden erstellt, wenn bei Anwendung bestimmte Probleme auftreten. Dumpdateien stellen den Inhalt des Speichers zum Zeitpunkt der Problemdarstellung dar und können vertrauliche Daten in unverschlüsselter Form enthalten. Der Inhalt der Speicherabbilder sollte überprüft werden, bevor sie für andere freigegeben werden.

Die Masterdatenbank ist nicht durch TDE geschützt. Obwohl die Masterdatenbank keine Benutzerdaten enthält, enthält sie Informationen wie Anmeldenamen.

Transparente Datenverschlüsselung und Transaktionsprotokolle

Das Aktivieren einer Datenbank für die Verwendung von TDE hat die Auswirkung, dass das Erneute Standard Eines Teils des virtuellen Transaktionsprotokolls null ist, um das nächste virtuelle Transaktionsprotokoll zu erzwingen. Dies gewährleistet, dass in den Transaktionsprotokollen kein Klartext verbleibt, nachdem die Datenbank für die Verschlüsselung eingerichtet wurde. Sie finden den Status der Protokolldateiverschlüsselung auf jedem PDW-Knoten, indem Sie die encryption_state Spalte in der sys.dm_pdw_nodes_database_encryption_keys Ansicht anzeigen, wie in diesem Beispiel:

WITH dek_encryption_state AS   
(  
    SELECT ISNULL(db_map.database_id, dek.database_id) AS database_id, encryption_state  
    FROM sys.dm_pdw_nodes_database_encryption_keys AS dek  
        INNER JOIN sys.pdw_nodes_pdw_physical_databases AS node_db_map  
           ON dek.database_id = node_db_map.database_id AND dek.pdw_node_id = node_db_map.pdw_node_id  
        LEFT JOIN sys.pdw_database_mappings AS db_map  
            ON node_db_map .physical_name = db_map.physical_name  
        INNER JOIN sys.dm_pdw_nodes AS nodes  
            ON nodes.pdw_node_id = dek.pdw_node_id  
    WHERE dek.encryptor_thumbprint <> 0x  
)  
SELECT TOP 1 encryption_state  
       FROM dek_encryption_state  
       WHERE dek_encryption_state.database_id = DB_ID('AdventureWorksPDW2012 ')  
       ORDER BY (CASE encryption_state WHEN 3 THEN -1 ELSE encryption_state END) DESC;  

Alle vor einer Änderung des Datenbank-Verschlüsselungsschlüssels in das Transaktionsprotokoll geschriebenen Daten werden mithilfe des vorherigen Verschlüsselungsschlüssels für die Datenbank verschlüsselt.

PDW-Aktivitätsprotokolle

SQL Server PDW Standard eine Reihe von Protokollen, die für die Problembehandlung vorgesehen sind. (Beachten Sie, dass dies nicht das Transaktionsprotokoll, das SQL Server-Fehlerprotokoll oder das Windows-Ereignisprotokoll ist.) Diese PDW-Aktivitätsprotokolle können vollständige Anweisungen in Klartext enthalten, von denen einige Benutzerdaten enthalten können. Typische Beispiele sind INSERT- und UPDATE-Anweisungen. Das Maskieren von Benutzerdaten kann mithilfe von sp_pdw_log_user_data_masking explizit aktiviert oder deaktiviert werden. Durch aktivieren der Verschlüsselung auf SQL Server PDW wird automatisch die Maskierung von Benutzerdaten in PDW-Aktivitätsprotokollen aktiviert, um sie zu schützen. sp_pdw_log_user_data_masking können auch verwendet werden, um Anweisungen zu maskieren, wenn sie TDE nicht verwenden, aber dies wird nicht empfohlen, da die Fähigkeit des Microsoft-Support Teams, Probleme zu analysieren, erheblich reduziert wird.

Transparente Datenverschlüsselung und die tempdb-Systemdatenbank

Die tempdb-Systemdatenbank wird verschlüsselt, wenn die Verschlüsselung mithilfe von sp_pdw_database_encryption aktiviert wird. Dies ist erforderlich, bevor eine Datenbank TDE verwenden kann. Dies kann einen Leistungseffekt für unverschlüsselte Datenbanken in derselben Instanz von SQL Server PDW haben.

Schlüsselverwaltung

Der Datenbankverschlüsselungsschlüssel (DEK) wird durch die zertifikate geschützt, die in der Masterdatenbank gespeichert sind. Diese Zertifikate werden durch den Datenbankmasterschlüssel (DMK) der Masterdatenbank geschützt. Das DMK muss durch den Dienstmasterschlüssel (SMK) geschützt werden, um für TDE verwendet werden zu können.

Das System kann auf die Schlüssel zugreifen, ohne dass ein menschliches Eingreifen erforderlich ist (z. B. das Bereitstellen eines Kennworts). Wenn das Zertifikat nicht verfügbar ist, gibt das System einen Fehler aus, der erklärt, dass die DEK erst entschlüsselt werden kann, wenn das richtige Zertifikat verfügbar ist.

Beim Verschieben einer Datenbank von einer Anwendung in eine andere muss das Zertifikat, das zum Schutz der DEK verwendet wird, zuerst auf dem Zielserver wiederhergestellt werden. Anschließend kann die Datenbank wie gewohnt wiederhergestellt werden. Weitere Informationen finden Sie in der Standardmäßigen SQL Server-Dokumentation unter Move a TDE Protected Database to Another SQL Server.

Zertifikate, die zum Verschlüsseln von DEKs verwendet werden, sollten beibehalten werden, solange Datenbanksicherungen vorhanden sind, die sie verwenden. Zertifikatsicherungen müssen den privaten Zertifikatschlüssel enthalten, da ohne den privaten Schlüssel kein Zertifikat für die Datenbankwiederherstellung verwendet werden kann. Diese Sicherungen für private Schlüssel des Zertifikats werden in einer separaten Datei gespeichert, die durch ein Kennwort geschützt ist, das für die Zertifikatwiederherstellung bereitgestellt werden muss.

Wiederherstellen der master-Datenbank

Die Masterdatenbank kann mithilfe von DWConfig als Teil der Notfallwiederherstellung wiederhergestellt werden.

• Wenn sich der Steuerelementknoten nicht geändert hat, wird die Masterdatenbank auf demselben und unveränderten Anwendung wiederhergestellt, aus dem die Sicherung der Masterdatenbank ausgeführt wurde, das DMK und alle Zertifikate ohne zusätzliche Aktion lesbar.

• Wenn die Masterdatenbank auf einem anderen Anwendung wiederhergestellt wird oder der Steuerelementknoten seit der Sicherung der Masterdatenbank geändert wurde, sind zusätzliche Schritte erforderlich, um das DMK neu zu generieren.

  1. Öffnen Sie das DMK:

     OPEN MASTER KEY DECRYPTION BY PASSWORD = '<password>';  
     

  2. Fügen Sie die Verschlüsselung von SMK hinzu:

     ALTER MASTER KEY   
         ADD ENCRYPTION BY SERVICE MASTER KEY;  
     

  3. Starten Sie die Appliance neu.

Aktualisieren und Ersetzen virtueller Computer

Wenn ein DMK für die Anwendung vorhanden ist, für die ein Upgrade- oder Ersetzungs-VM ausgeführt wurde, muss das DMK-Kennwort als Parameter angegeben werden.

Beispiel für die Upgradeaktion. Ersetzen Sie ********** es durch Ihr DMK-Kennwort.

setup.exe /Action=ProvisionUpgrade ... DMKPassword='**********'

Beispiel für die Aktion zum Ersetzen eines virtuellen Computers.

setup.exe /Action=ReplaceVM ... DMKPassword='**********'

Wenn während des Upgrades eine Benutzer-DB verschlüsselt ist und das DMK-Kennwort nicht angegeben wird, schlägt die Upgradeaktion fehl. Wenn beim Ersetzen das richtige Kennwort nicht angegeben wird, wenn ein DMK vorhanden ist, überspringt der Vorgang den DMK-Wiederherstellungsschritt. Alle anderen Schritte werden am Ende der Ersetzen-VM-Aktion abgeschlossen, die Aktion meldet jedoch einen Fehler am Ende, um anzugeben, dass zusätzliche Schritte erforderlich sind. In den Setupprotokollen (in \ProgramData\Microsoft\Microsoft\Microsoft SQL Server Parallel Data Warehouse\100\Logs\Setup\\<time-stamp>\Detail-Setup) wird die folgende Warnung am Ende angezeigt.

*** WARNING \*\*\* DMK is detected in master database, but could not be recovered automatically! The DMK password was either not provided or is incorrect!

Führen Sie diese Anweisung manuell in PDW aus, und starten Sie danach Anwendung neu, um DMK wiederherzustellen:

OPEN MASTER KEY DECRYPTION BY PASSWORD = '<DMK password>';  
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY;  

Führen Sie die Schritte im Abschnitt "Wiederherstellen des Masterdatenbankabsatzs" aus, um die Datenbank wiederherzustellen, und starten Sie dann die Anwendung neu.

Wenn das DMK bereits vorhanden war, aber nach der Aktion nicht wiederhergestellt wurde, wird die folgende Fehlermeldung ausgelöst, wenn eine Datenbank abgefragt wird.

Msg 110806;  
A distributed query failed: Database '<db_name>' cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details.

Leistungsauswirkungen

Die Auswirkungen der Leistung von TDE variieren je nach Art der daten, die Sie haben, wie sie gespeichert werden, und dem Typ der Workloadaktivität auf dem SQL Server-PDW. Wenn sie durch TDE geschützt sind, wird das Lesen und Entschlüsseln von Daten oder das Verschlüsseln und Anschließendes Schreiben von Daten eine CPU-intensive Aktivität sein und haben mehr Auswirkungen, wenn andere CPU-intensive Aktivitäten gleichzeitig ausgeführt werden. Da TDE verschlüsselt wird tempdb, kann TDE die Leistung von Datenbanken beeinflussen, die nicht verschlüsselt sind. Um eine genaue Vorstellung der Leistung zu erhalten, sollten Sie das gesamte System mit Ihren Daten- und Abfrageaktivitäten testen.

Verwandte Inhalte

Die folgenden Links enthalten allgemeine Informationen zur Verwaltung der Verschlüsselung durch SQL Server. Diese Artikel können Ihnen dabei helfen, die SQL Server-Verschlüsselung zu verstehen, aber diese Artikel enthalten keine spezifischen Informationen für SQL Server PDW und erläutern Features, die in SQL Server PDW nicht vorhanden sind.

• SQL Server-Verschlüsselung

• Verschlüsselungshierarchie

• Verschlüsselungsschlüssel für SQL Server und Datenbank

Weitere Informationen

ALTER DATABASE
CREATE MASTER KEY
CREATE DATABASE ENCRYPTION KEY
BACKUP CERTIFICATE
sp_pdw_database_encryption
sp_pdw_database_encryption_regenerate_system_keys
sp_pdw_log_user_data_masking
sys.certificates
sys.dm_pdw_nodes_database_encryption_keys