SQL Server-Verschlüsselung erklärt: TDE, spaltenbasierte Verschlüsselung und mehr

Datenschutz ist entscheidend, um sicherzustellen, dass Ihre Organisation den regulatorischen Compliance-Standards wie der GDPR entspricht und um die Erwartungen Ihrer Kunden und Geschäftspartner zu erfüllen. Nicht nur können Datenpannen zu hohen Bußgeldern führen, sondern auch der Reputationsschaden kann ebenso groß sein. Zur Unterstützung bietet Microsoft SQL Server 5 verschiedene Arten der Verschlüsselung zum Schutz von Daten an. Dieser Artikel erklärt jede davon und wo sie eingesetzt werden sollten.

SSL-Transportverschlüsselung

Wie Websites, die den Verkehr zwischen Browser und Server sichern, kann SQL Server so konfiguriert werden, dass er Secure Sockets Layer (SSL) verwendet, um den Verkehr zu verschlüsseln, während er zwischen der Serverinstanz und der Client-Anwendung übertragen wird. Zusätzlich kann der Client die Identität des Servers mithilfe des Serverzertifikats überprüfen. SSL schützt Daten nur, während sie durch das Netzwerk übertragen werden, aber im Gegensatz zu den meisten anderen Formen der SQL Server-Verschlüsselung ist SSL in allen unterstützten Versionen von SQL Server und in allen Editionen verfügbar.

Bevor Sie SSL aktivieren, müssen Sie ein Zertifikat auf dem SQL Server installieren. Der beste Weg, dies zu tun, ist die Anforderung eines Zertifikats von Ihrer eigenen Unternehmenszertifizierungsstelle (CA). Windows Server kann als CA konfiguriert werden und Sie können Clients so einrichten, dass sie den Zertifikaten vertrauen, die sie ausstellt. Alternativ ist es möglich, selbstsignierte Zertifikate zu verwenden, obwohl dies am besten für Testumgebungen geeignet ist.

SQL Server Transparent Data Encryption (TDE)

Transparent Data Encryption (TDE) in SQL Server schützt Daten im Ruhezustand, indem Datenbankdaten und Protokolldateien auf der Festplatte verschlüsselt werden. Es funktioniert transparent für bestehende Client-Anwendungen, sodass sie nicht geändert werden müssen, wenn TDE aktiviert ist. TDE verwendet Echtzeit-Verschlüsselung auf Seitenebene. Seiten werden verschlüsselt, bevor sie auf die Festplatte geschrieben werden, ohne die Größe Ihrer Daten- und Protokolldateien zu erhöhen, und Seiten werden entschlüsselt, wenn sie in den Speicher gelesen werden. TDE ist nur in Enterprise-Editionen von SQL Server verfügbar. Es funktioniert auch für Azure SQL Database, Azure SQL Data Warehouse und Parallel Data Warehouse.

TDE-Verschlüsselung hat eine hierarchische Struktur, wobei die Windows Data Protection API (DPAPI) an der Spitze der Hierarchie steht und verwendet wird, um den Dienst-Hauptschlüssel (SMK) zu verschlüsseln. Sie können den SMK nutzen, um Anmeldeinformationen, verknüpfte Serverpasswörter und die Datenbank-Hauptschlüssel (DMKs), die in verschiedenen Datenbanken liegen, zu verschlüsseln. Ein SQL DMK ist ein symmetrischer Schlüssel, der die privaten Schlüssel von Zertifikaten und asymmetrischen Schlüsseln schützt, die in Datenbanken gespeichert sind.

SQL Server kann selbstsignierte Zertifikate für die Verwendung mit TDE generieren, oder Sie können ein Zertifikat von einer CA anfordern (was der häufigere Ansatz ist). Wenn Sie sich entscheiden, TDE zu aktivieren, müssen Sie das Zertifikat und den privaten Schlüssel, der mit dem Zertifikat verbunden ist, sichern. Sie werden dies benötigen, um die Datenbank auf einem anderen SQL Server wiederherzustellen oder anzuhängen. Wenn Sie TDE auf irgendeiner anderen SQL Server-Datenbank aktivieren, wird auch die Systemdatenbank tempdb verschlüsselt. Wenn Sie TDE deaktivieren, sollten Sie das Zertifikat und den privaten Schlüssel aufbewahren, da Teile des Transaktionsprotokolls verschlüsselt bleiben könnten, bis Sie eine vollständige Sicherung durchführen.

TDE erfordert auch einen Datenbankverschlüsselungsschlüssel (DEK), der entweder ein symmetrischer Schlüssel ist, der mit einem Zertifikat geschützt wird, das in der Master-Datenbank gespeichert ist, oder ein asymmetrischer Schlüssel, der von einem Dienst geschützt wird, der Extensible Key Management (EKM) verwendet, wie zum Beispiel Microsoft Azure Key Vault. Backup-Dateien von TDE-aktivierten Datenbanken werden mit dem DEK verschlüsselt, sodass während der Wiederherstellungsvorgänge das Zertifikat, das den DEK schützt, verfügbar sein muss.

Symmetrische Schlüssel verwenden dasselbe Passwort zum Ver- und Entschlüsseln von Daten. Asymmetrische Schlüssel verwenden ein Passwort zum Verschlüsseln von Daten (öffentlicher Schlüssel) und ein anderes Passwort zum Entschlüsseln von Daten (privater Schlüssel). Sie können den Befehl CREATE CERTIFICATE verwenden, um Zertifikate zu erstellen, und die Transact-SQL-Befehle CREATE SYMMETRIC KEY und CREATE ASYMMETRIC KEY, um Datenbankverschlüsselungsschlüssel zu erstellen.

Backup-Verschlüsselung

Backup-Verschlüsselung funktioniert ähnlich wie TDE, verschlüsselt jedoch SQL-Backups anstelle der aktiven Daten- und Protokolldateien. Backup-Verschlüsselung ist ab SQL Server 2014 verfügbar. Sie können AES 128, AES 192, AES 256 oder Triple DES-Verschlüsselung festlegen und entweder ein Zertifikat oder einen asymmetrischen Schlüssel verwenden, der in EKM gespeichert ist. Zusätzlich ist es möglich, TDE und Backup-Verschlüsselung gleichzeitig zu aktivieren, obwohl Sie unterschiedliche Zertifikate oder Schlüssel verwenden sollten.

Genau wie bei TDE müssen Sie, wenn Sie die Backup-Verschlüsselung aktivieren, auch das Zertifikat oder den Schlüssel sichern. Ohne den Schlüssel oder das Zertifikat kann die Backup-Datei nicht zur Datenwiederherstellung verwendet werden. Backups können auch verschlüsselt werden, wenn SQL Server Managed Backup zu Microsoft Azure verwendet wird.

Es ist wichtig zu beachten, dass Sie, wenn Sie ein Zertifikat verwenden, um Backups zu verschlüsseln, das Originalzertifikat beim Wiederherstellen der Daten haben müssen. Das bedeutet, dass das Zertifikat denselben Fingerabdruck haben muss, wie zum Zeitpunkt der Erstellung des Backups. Das Erneuern von Zertifikaten oder jegliche Änderungen daran können dazu führen, dass sich der Fingerabdruck ändert.

Verschlüsselung auf Spalten-/Zellenebene

Verfügbar in allen Editionen von SQL Server, kann die zellbasierte Verschlüsselung für Spalten aktiviert werden, die sensible Daten enthalten. Die Daten sind auf der Festplatte verschlüsselt und bleiben im Speicher verschlüsselt, bis die DECRYPTBYKEY-Funktion verwendet wird, um sie zu entschlüsseln. Daher sind die SQL-Daten zwar verschlüsselt, aber nicht sicher, da lediglich eine Funktion im Benutzerkontext verwendet wird, um sie zu entschlüsseln. Zusätzlich muss, da eine Funktion zum Entschlüsseln der Daten benötigt wird, die Client-Anwendungen modifiziert werden, um mit der zellbasierten Verschlüsselung zu arbeiten.

Verschlüsselungsschlüssel-Management

Wie bei TDE müssen Sie einen Master-Schlüssel (DMK) erstellen, bevor Sie die zellenbasierte Verschlüsselung verwenden. Es gibt vier Optionen für die Verschlüsselung von Informationen unter Verwendung der zellenbasierten Verschlüsselung:

• Sie können ein Passwort verwenden, um die Daten zu verschlüsseln und zu entschlüsseln, aber Sie müssen gespeicherte Prozeduren und Funktionen verschlüsseln; andernfalls kann das Passwort in den Metadaten eingesehen werden.
• Asymmetrische Schlüssel bieten starke Sicherheit, können jedoch die Leistung beeinträchtigen.
• Symmetrische Schlüssel sind in der Regel stark genug und bieten eine gute Balance zwischen Sicherheit und Leistung.
• Zertifikate bieten auch eine gute Balance zwischen Sicherheit und Leistung und können mit einem Datenbankbenutzer verknüpft werden.

Always Encrypted

Always Encrypted verschlüsselt sensible Daten in Client-Anwendungen, ohne die Verschlüsselungsschlüssel an die Datenbank-Engine weiterzugeben, was eine Trennung zwischen Datenbesitzern und Datenmanagern ermöglicht. Zum Beispiel können Sie mit Always Encrypted aktiviert sicher sein, dass Ihre Datenbankadministratoren keine sensiblen Daten lesen können. Wie der Name schon sagt, werden Daten im Ruhezustand verschlüsselt und, falls in einem Drittsystem verwendet, wie Azure.

Always Encrypted kann für einzelne Datenbankspalten konfiguriert werden. Es werden zwei Arten von Schlüsseln verwendet: Spaltenverschlüsselungsschlüssel und Spaltenhauptschlüssel. Spaltenverschlüsselungsschlüssel schützen Daten in einer Spalte und Spaltenhauptschlüssel sind ‘Schlüssel-schützende Schlüssel’, die einen oder mehrere Spaltenverschlüsselungsschlüssel verschlüsseln. Spaltenhauptschlüssel werden in externen vertrauenswürdigen Schlüsselspeichern gespeichert, wie Azure Key Vault.

Der Verschlüsselungsprozess ist für Client-Anwendungen transparent, erfordert jedoch einen speziellen Treiber auf Client-Computern. Always Encrypted ist ab SQL Server 2016 verfügbar, allerdings nur in den Enterprise-Editionen. Aufgrund der zusätzlichen Anforderungen auf der Client-Seite eignet sich Always Encrypted am besten für Situationen, in denen eine klare Trennung zwischen Datenbesitzern und -verwaltern eine primäre Anforderung ist.