SQL Server Encryption Explained: TDE, Column-Level Encryption and More
Der Datenschutz ist entscheidend, um sicherzustellen, dass Ihr Unternehmen die gesetzlichen Compliance-Standards wie die DSGVO einhält und die Erwartungen Ihrer Kunden und Geschäftspartner erfüllt. Datenschutzverletzungen können nicht nur zu hohen Bußgeldern führen, sondern der Reputationsschaden kann ebenso groß sein. Microsoft SQL Server unterstützt 5 verschiedene Verschlüsselungsarten zum Schutz von Daten. Dieser Artikel erklärt jeden von ihnen und wo sie verwendet werden sollten.
SSL-Transportverschlüsselung
Wie Websites, die den Datenverkehr zwischen Browser und Server sichern, kann SQL Server so konfiguriert werden, dass Secure Sockets Layer (SSL) verwendet wird, um den Datenverkehr zwischen der Serverinstanz und der Clientanwendung zu verschlüsseln. Darüber hinaus kann der Client die Identität des Servers mithilfe des Serverzertifikats überprüfen. Im Gegensatz zu den meisten anderen Formen der SQL Server-Verschlüsselung ist SSL jedoch 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, besteht darin, ein Zertifikat von Ihrer eigenen Unternehmenszertifizierungsstelle (CA) anzufordern. Windows Server kann als Zertifizierungsstelle konfiguriert werden, und Sie können Clients so einrichten, dass sie den ausgestellten Zertifikaten vertrauen. Alternativ ist es möglich, selbstsignierte Zertifikate zu verwenden, obwohl dies am besten für Testumgebungen geeignet ist.
SQL Server Transparente Datenverschlüsselung (TDE)
Transparente Datenverschlüsselung (TDE) in SQL Server schützt ruhende Daten durch Verschlüsselung von Datenbankdaten und Protokolldateien auf der Festplatte. Es arbeitet transparent mit vorhandenen Client-Anwendungen zusammen, sodass sie nicht geändert werden müssen, wenn TDE aktiviert ist. TDE verwendet Echtzeitverschlü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-Datenbank, Azure SQL Data Warehouse und Parallel Data Warehouse.
Die TDE-Verschlüsselung hat eine hierarchische Struktur, wobei die Windows Data Protection API (DPAPI) an der Spitze der Hierarchie steht und zur Verschlüsselung des Service Master Key (SMK) verwendet wird. Sie können das SMK verwenden, um Anmeldeinformationen, Kennwörter für verknüpfte Server und Datenbankmasterschlüssel (DMKs) zu verschlüsseln, die sich in verschiedenen Datenbanken befinden. 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 Zertifizierungsstelle anfordern (was der gängigere Ansatz ist). Wenn Sie TDE aktivieren möchten, müssen Sie das Zertifikat und den dem Zertifikat zugeordneten privaten Schlüssel sichern. Sie müssen die Datenbank auf einem anderen SQL Server wiederherstellen oder anhängen. Wenn Sie TDE in einer anderen SQL Server-Datenbank aktivieren, wird auch die tempdb-Systemdatenbank verschlüsselt. Wenn Sie TDE deaktivieren, sollten Sie das Zertifikat und den privaten Schlüssel beibehalten, da Teile des Transaktionslogs verschlüsselt bleiben können, bis Sie eine vollständige Sicherung durchführen.Dies ist entweder ein symmetrischer Schlüssel, der durch ein in der Masterdatenbank gespeichertes Zertifikat geschützt ist, oder ein asymmetrischer Schlüssel, der durch einen Dienst geschützt ist, der Extensible Key Management (EKM) verwendet, z. B. Microsoft Azure Key Vault. Sicherungsdateien von TDE-fähigen Datenbanken werden mit dem DEK verschlüsselt, sodass während der Wiederherstellungsvorgänge das Zertifikat zum Schutz des DEK verfügbar sein muss.
Symmetrische Schlüssel verwenden dasselbe Passwort, um Daten zu verschlüsseln und zu entschlüsseln. Asymmetrische Schlüssel verwenden ein Kennwort zum Verschlüsseln von Daten (öffentlicher Schlüssel) und ein anderes Kennwort zum Entschlüsseln von Daten (privater Schlüssel). Sie können den Befehl CREATE CERTIFICATE zum Erstellen von Zertifikaten und die Transact-SQL-Befehle CREATE SYMMETRIC KEY und CREATE ASYMMETRIC KEY zum Erstellen von Datenbankverschlüsselungsschlüsseln verwenden.
Backup-Verschlüsselung
Die Backup-Verschlüsselung funktioniert wie TDE, verschlüsselt jedoch SQL-Backups anstelle der aktiven Daten und Protokolldateien. Backup-Verschlüsselung ist in SQL Server 2014 und höher verfügbar. Sie können AES 128-, AES 192-, AES 256- oder Triple DES-Verschlüsselung angeben und entweder ein Zertifikat oder einen asymmetrischen Schlüssel verwenden, der in EKM gespeichert ist. Darüber hinaus 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 Sicherungsverschlüsselung aktivieren, auch das Zertifikat oder den Schlüssel sichern. Ohne den Schlüssel oder das Zertifikat kann die Sicherungsdatei nicht zum Wiederherstellen von Daten verwendet werden. Sicherungen können auch verschlüsselt werden, wenn SQL Server Managed Backup in Microsoft Azure verwendet wird.
Wenn Sie ein Zertifikat zum Verschlüsseln von Backups verwenden, müssen Sie beim Wiederherstellen von Daten über das Originalzertifikat verfügen. Das bedeutet, dass das Zertifikat denselben Fingerabdruck haben muss wie bei der Erstellung des Backups. Wenn Sie Zertifikate erneuern oder in irgendeiner Weise ändern, kann sich der Fingerabdruck ändern.
Verschlüsselung auf Spalten-/Zellebene
In allen Editionen von SQL Server kann die Verschlüsselung auf Zellebene für Spalten aktiviert werden, die vertrauliche Daten enthalten. Die Daten werden auf der Festplatte verschlüsselt und bleiben im Speicher verschlüsselt, bis die DECRYPTBYKEY-Funktion zum Entschlüsseln verwendet wird. Obwohl die SQL-Daten verschlüsselt sind, sind sie daher nicht sicher, wenn sie nur eine Funktion im Benutzerkontext zum Entschlüsseln verwenden. Da zum Entschlüsseln der Daten eine Funktion erforderlich ist, müssen Clientanwendungen außerdem so geändert werden, dass sie mit Verschlüsselung auf Zellebene arbeiten.
Verwaltung des Verschlüsselungsschlüssels
Wie bei TDE müssen Sie einen Hauptschlüssel (DMK) erstellen, bevor Sie die Verschlüsselung auf Zellebene verwenden. Es gibt vier Optionen zum Verschlüsseln von Informationen mithilfe der Verschlüsselung auf Zellebene:
- Sie können eine Passphrase zum Verschlüsseln und Entschlüsseln der Daten verwenden, müssen jedoch gespeicherte Prozeduren und Funktionen verschlüsseln; andernfalls kann in den Metadaten auf die Passphrase zugegriffen werden.
- Asymmetrische Schlüssel bieten hohe Sicherheit, können sich aber auf die Leistung auswirken.
- Symmetrische Schlüssel sind normalerweise stark genug und bieten ein gutes Gleichgewicht zwischen Sicherheit und Leistung.
- Zertifikate bieten auch ein gutes Gleichgewicht zwischen Sicherheit und Leistung und können einem Datenbankbenutzer zugeordnet werden.
Always Encrypted
Always Encrypted verschlüsselt vertrauliche Daten in Clientanwendungen, ohne die Verschlüsselungsschlüssel an das Datenbankmodul weiterzugeben. Wenn beispielsweise Always Encrypted aktiviert ist, können Sie sicher sein, dass Ihre Datenbankadministratoren keine vertraulichen Daten lesen können. Wie der Name schon sagt, werden Daten im Ruhezustand und bei Verwendung in einem Drittanbietersystem wie Azure verschlüsselt.
Always Encrypted kann für einzelne Datenbankspalten konfiguriert werden. Es werden zwei Arten von Schlüsseln verwendet: spaltenverschlüsselungsschlüssel und Spaltenmasterschlüssel. Spaltenverschlüsselungsschlüssel schützen Daten in einer Spalte, und Spaltenmasterschlüssel sind Schlüsselschutzschlüssel, die einen oder mehrere Spaltenverschlüsselungsschlüssel verschlüsseln. Spaltenmasterschlüssel werden in externen vertrauenswürdigen Schlüsselspeichern wie Azure Key Vault gespeichert.
Der Verschlüsselungsprozess ist für Clientanwendungen transparent, erfordert jedoch einen speziellen Treiber auf Clientcomputern. Always Encrypted ist in SQL Server 2016 und höher verfügbar, jedoch nur in Enterprise Editions. Aufgrund der zusätzlichen clientseitigen Anforderungen eignet sich Always Encrypted am besten für Situationen, in denen die Trennung von Dateneigentümern und -managern eine Hauptanforderung ist.