Verschlüsselung in Microsoft SQL Server

Wie andere DBMS-Anbieter verwendet Microsoft das SSL-Protokoll zum Schutz seiner Kunden. Nur wenige wissen jedoch, dass im Gegensatz zu anderen DBMS MsSQL den SSL-Handshake innerhalb von TDS einkapselt.

Der Trick könnte absichtlich gemacht worden sein, um die Anzahl der potenziellen Bedrohungen für MS-Server zu reduzieren, da heutzutage Anbieter SSL in einer einfachen Protokollschichtkombination als vollständige Einkapselung verwenden. Es ist einfacher und universeller, da das Ein- und Ausschalten von SSL das Hauptprotokoll nicht beeinflusst.

Die Verschlüsselung in MsSQL erfolgt in zwei Modi: Schutz der Autorisierungsstufe und vollständiger Verbindungsschutz. In beiden Fällen beginnt der Dialog mit dem Client-Server-Austausch von Einstellungen: Der Client sendet sein PRELOGIN-Paket und erhält dasselbe Paket vom Server. Dann sendet der Client das erste Handshake-Paket, nachdem es in TDS als PRELOGIN eingekapselt wurde. Alle folgenden SSL-Pakete werden auf die gleiche Weise in TDS eingekapselt, bis der Handshake abgeschlossen ist.

Allerdings werden das erste und alle nachfolgenden SSL-Anwendungspakete so gesendet, wie sie sind, ohne in TDS eingekapselt zu werden. Das Paket umschließt die LOGIN7-Autorisierungsabfrage. Hier beginnen sich die Modi zu unterscheiden. Die SSL-Verschlüsselung des ersten Modus wird abgeschlossen und der folgende Datenverkehr zwischen Client und Server wird nicht mehr verschlüsselt. Im zweiten Modus wird die Verschlüsselung bis zum Schließen der Sitzung implementiert.

Es ist zu beachten, dass der Server tatsächlich ohne Verschlüsselung funktionieren kann, aber offizielle MSSQL-Clients diese Option nicht bieten. Warum ist das wichtig? Verschlüsselung im Kanal verhindert auf die eine oder andere Weise die passive Sammlung und Analyse von Datenverkehr, d.h. das Abhören, das eine unserer Hauptfunktionen darstellt.

Falls es unmöglich ist, den Datenverkehr zu modifizieren, ist die Sniffer-Funktionalität eingeschränkt. Dies bezieht sich in erster Linie auf ephemere schlüsselbasierte Chiffren. Alle auf ECDHE- und DHE basierenden Chiffren fallen in diese Kategorie, z.B.:

Außerdem muss zum Entschlüsseln des SSL-Datenverkehrs die Low-Level-OpenSSL-API verwendet werden. Dies erfordert wiederum, dass wir den SSL-Sniffer ständig aktualisieren.

Gleichzeitig muss der Client einen Serverschlüssel auf der Proxy- (Firewall-) Seite installieren. Dies ist ein weiteres Hindernis für den Datenschutz, da der Client den Schutz des Servers uns anvertrauen oder keine offizielle MsSQL-Client-Software (z.B. Microsoft SQL Server Management Studio) im Sniffer-Modus verwenden muss.

Was ephemere Schlüssel betrifft, so können sie auf der Serverseite von MsSQL deaktiviert werden. Der Windows Cryptographic Service Provider erlaubt dies unter normalen Bedingungen.

Somit ist der Sniffer für MsSQL Server trotz der offensichtlichen Protokolleinschränkungen seitens Microsoft in die Firewall integriert. Wir haben unser Bestes getan, um es unseren Kunden zu erleichtern, ihn zu verwenden.

DataSunrise Database Security bietet eine vollständige Sicherheitslösung für Microsoft SQL Server oder Azure SQL. DataSunrise umfasst eine Datenbank-Firewall, Datenbank-Aktivitätsüberwachung und -Audit, Erkennung sensibler Daten und mehr. DataSunrise unterstützt auch alle anderen Datenbanken und Datenlager wie Oracle, IBM DB2, IBM Netezza, MySQL, MariaDB, Greenplum, Amazon Aurora, Amazon Redshift, Microsoft SQL Server, Azure SQL, Teradata und mehr. Sie sind herzlich eingeladen, eine kostenlose Testversion herunterzuladen, wenn Sie sie bei sich vor Ort installieren möchten. Falls Sie ein Cloud-Benutzer sind und Ihre Datenbank auf Amazon AWS oder Microsoft Azure betreiben, können Sie sie im AWS Marktplatz oder Azure Marktplatz erhalten.