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. Es ermöglicht die Einhaltung vieler Gesetze, Vorschriften und Richtlinien, die in verschiedenen Branchen gelten. Mit diesem Feature können Softwareentwickler Daten mithilfe von AES- und 3DES-Verschlüsselungsalgorithmen verschlüsseln, ohne vorhandene Anwendungen zu ändern.

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

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 in 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.

Zuerst: Aktivieren Sie TDE auf dem 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 = '<password>';  
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>';  

Zweitens: Erstellen und sichern Sie ein Zertifikat in der Master-Datenbank. 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 = '<password>'   
    )   
GO  

Zum Schluss: Erstellen Sie den 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.

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.

Katalogsichten und dynamische Verwaltungssichten

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

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 Operationen sind während der CREATE DATABASE ENCRYPTION KEY, ALTER DATABASE ENCRYPTION KEY, DROP DATABASE ENCRYPTION KEY oder ALTER DATABASE...SET ENCRYPTION Anweisungen nicht zulässig.

• Löschen der Datenbank

• Verwenden Sie einen ALTER DATABASE Befehl.

• Starten einer Datenbanksicherung.

• Starten einer Datenbankwiederherstellung.

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

• 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 darauf achten, keine Abfragen mit vertraulichen Parametern auszuführen, während Diagnosesitzungen aktiv sind. 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 bestimmte Probleme in der Appliance 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 bewirkt, dass der verbleibende Teil des virtuellen Transaktionsprotokolls auf null gesetzt wird, 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 verwaltet 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 kann auch verwendet werden, um Anweisungen zu maskieren, wenn TDE nicht verwendet wird, dies wird jedoch nicht empfohlen, da dadurch die Möglichkeiten des Microsoft-Support-Teams zur Problemanalyse erheblich eingeschränkt werden.

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 Appliance 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 Steuerknoten nicht geändert hat, das heißt, wenn die Masterdatenbank auf derselben und unveränderten Appliance wiederhergestellt wird, von der das Backup der Masterdatenbank erstellt wurde, können das DMK und alle Zertifikate ohne weitere Maßnahmen gelesen werden.

• Wenn die Masterdatenbank in einer anderen Appliance 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 auf der Appliance, auf der „Upgrade“ oder „Replace VM“ durchgeführt wurde, eine DMK vorhanden ist, muss das DMK-Kennwort als Parameter angegeben werden.

Beispiel für die Upgradeaktion. Ersetzen Sie <password> durch Ihr DMK-Kennwort.

setup.exe /Action=ProvisionUpgrade ... DMKPassword='<password>'

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

setup.exe /Action=ReplaceVM ... DMKPassword='<password>'

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 die Appliance neu, um DMK wiederherzustellen:

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

Verwenden Sie die Schritte im Abschnitt „Wiederherstellen der Master-Datenbank“, um die Datenbank wiederherzustellen, und starten Sie dann die Appliance 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. Bei Schutz durch TDE ist der I/O-Vorgang beim Lesen und anschließenden Entschlüsseln von Daten sowie beim Verschlüsseln und anschließenden Schreiben von Daten CPU-intensiv und wirkt sich stärker aus, wenn gleichzeitig andere CPU-intensive Aktivitäten stattfinden. Da TDE tempdb verschlüsselt, kann sich TDE auf die Leistung nicht verschlüsselter Datenbanken auswirken. 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

Siehe auch

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