Anwenden von SQL Server Transparent Data Encryption

  • 6 Minuten

Viele Kunden verwenden SQL Server Transparent Data Encryption (TDE) beim Bereitstellen ihrer SAP-SQL Server-Datenbanken in Azure. Die SQL Server-TDE-Funktionalität wird vollständig von SAP unterstützt (siehe SAP-Hinweis #1380493 ).

Wenn Sie eine heterogene Migration aus einem anderen lokalen DBMS nach Windows/SQL Server in Azure ausführen, erstellen Sie vorab eine leere Zieldatenbank in SQL Server. Im nächsten Schritt wenden Sie die SQL Server TDE-Funktionalität an, während Ihr Produktionssystem weiterhin lokal ausgeführt wird. Der Grund für die Ausführung in dieser Reihenfolge ist, dass der Verschlüsselungsprozess der leeren Datenbank einige Zeit in Anspruch nehmen kann. Die SAP-Importvorgänge importieren die Daten dann während der Downtime in die verschlüsselte Datenbank. Der Zeitaufwand für das Importieren in eine verschlüsselte Datenbank ist geringer als für eine Verschlüsselung der Datenbank nach der Exportphase in der Downtimephase. Beim Versuch, TDE auf SAP-Workloads anzuwenden, die auf der Datenbank ausgeführt werden, sind Probleme aufgetreten. Daher wird empfohlen, die TDE-Bereitstellung als eine Aktivität zu betrachten, die ohne SAP-Workload in der Datenbank ausgeführt werden muss.

In Fällen, in denen Sie SAP-SQL Server-Datenbanken aus einem lokalen System nach Azure verschieben, wird empfohlen zu testen, auf welcher Infrastruktur Sie die Verschlüsselung am schnellsten anwenden können. Beachten Sie Folgendes:

  • Sie können nicht festlegen, wie viele Threads verwendet werden, um Datenverschlüsselung auf die Datenbank anzuwenden. Die Anzahl von Threads hängt vor allem von der Anzahl von Datenträgervolumes ab, über die die Daten und Protokolldateien von SQL Server verteilt sind. Das heißt, je mehr einzelne Volumes, desto mehr Threads werden parallel ausgeführt, um die Verschlüsselung durchzuführen. Eine solche Konfiguration widerspricht Datenträgerkonfigurationsvorschlägen, maximal einen Speicherplatz für die SQL Server-Datenbankdateien auf Azure-VMs zu erstellen. Eine Konfiguration mit wenigen Volumes hätte eine geringe Anzahl von Threads, die die Verschlüsselung ausführen, zur Folge. Eine einzelne Threadverschlüsselung liest 64-KB-Erweiterungen, verschlüsselt sie und schreibt dann einen Datensatz in die Transaktionsprotokolldatei, der angibt, dass die Erweiterung verschlüsselt wurde. Deswegen ist die Last des Transaktionsprotokolls als moderat zu bezeichnen.
  • In älteren SQL Server-Releases war die Sicherungskomprimierung nicht mehr effizient, wenn die SQL Server-Datenbank verschlüsselt wurde. Dieses Verhalten war ggf. problematisch, wenn Sie Ihre SQL Server-Datenbank lokal verschlüsseln und dann eine Sicherung in Azure kopieren wollten, um die Datenbank in Azure wiederherzustellen. Die SQL Server-Sicherungskomprimierung erzielt in der Regel ein Komprimierungsverhältnis von Faktor 4.
  • Mit SQL Server 2016 hat SQL Server eine neue Funktionalität eingeführt, die es ermöglicht, auch verschlüsselte Datenbanken effizient zu komprimieren.
  • Wenn die TDE-Verschlüsselung ohne oder nur mit wenig SAP-Workload erfolgen soll, sollten Sie in Ihrer spezifischen Konfiguration testen, ob es besser ist, TDE lokal oder in Azure auf Ihre SAP-Datenbank anzuwenden. Azure bietet mehr Flexibilität in Bezug auf die Überbereitstellung und Verkleinerung der Infrastruktur, nachdem TDE angewendet wurde.

Azure Key Vault (ein Dienst zur sicheren Verwaltung kryptografischer Schlüssel)

Azure bietet den Dienst Key Vault zum Speichern von Verschlüsselungsschlüsseln an. SQL Server hingegen bietet einen Connector, um Azure Key Vault als Speicher für die TDE-Zertifikate zu verwenden.