Verschlüsselung in Microsoft SQL Server

Wie andere DBMS-Anbieter verwendet Microsoft das SSL-Protokoll zum Schutz seiner Clients. Allerdings wissen es nur wenige, dass im Gegensatz zu anderen DBMS MsSQL den SSL-Handshake innerhalb von TDS kapselt.

Dieser Trick könnte absichtlich angewendet worden sein, um die Anzahl potenzieller Bedrohungen für MS-Server zu reduzieren, da Anbieter heutzutage SSL in einer Kombination aus einfacher Protokollebene statt in einer vollständigen Kapselung einsetzen. Dies ist einfacher und universeller, da das Ein- oder Ausschalten von SSL das Hauptprotokoll nicht beeinträchtigt.

Die Verschlüsselung in MsSQL erfolgt über zwei Modi: den Schutz in der Autorisierungsphase und den vollständigen Verbindungsschutz. In beiden Fällen beginnt der Dialog mit dem Austausch von Einstellungen zwischen Client und Server: Der Client sendet sein PRELOGIN-Paket und erhält dasselbe Paket vom Server. Anschließend sendet der Client das erste Handshake-Paket, nachdem er es in TDS als PRELOGIN eingekapselt hat. Alle folgenden SSL-Pakete werden auf dieselbe Weise in TDS eingekapselt, bis der Handshake abgeschlossen ist.

Allerdings werden das erste und alle folgenden SSL-Anwendungspakete so gesendet, wie sie sind, ohne in TDS eingekapselt zu werden. Das Paket kapselt die LOGIN7-Autorisierungsabfrage ein. Hier beginnen sich die Modi zu unterscheiden. Bei der ersten Methode ist die SSL-Verschlüsselung abgeschlossen und der folgende Datenverkehr zwischen Client und Server wird nicht mehr verschlüsselt. Bei der zweiten Methode wird die Verschlüsselung bis zum Schließen der Sitzung beibehalten.

Es ist anzumerken, dass der Server in der Tat ohne Verschlüsselung funktionieren kann, die offiziellen MSSQL-Clients jedoch diese Option nicht bieten. Warum ist das wichtig? Die Verschlüsselung im Kanal verhindert auf die eine oder andere Weise das passive Aufzeichnen und Analysieren des Datenverkehrs, also Sniffing, was eine unserer Hauptaufgaben darstellt.

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

Zudem muss zur Entschlüsselung des SSL-Datenverkehrs die Low-Level-OpenSSL-API verwendet werden. Dies wiederum erfordert von uns, den SSL-Sniffer kontinuierlich aktuell zu halten.

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

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

Somit ist der Sniffer für den MsSQL Server trotz der offensichtlichen Protokollbeschränkungen seitens Microsoft in die Firewall integriert. Wir haben alles darangesetzt, die Nutzung für unsere Kunden so einfach wie möglich zu gestalten.

DataSunrise Database Security bietet eine komplette Sicherheitslösung für Microsoft SQL Server oder Azure SQL. DataSunrise umfasst eine Datenbank-Firewall, Datenbank-Aktivitätsüberwachung und -Audit, die Entdeckung sensibler Daten und mehr. DataSunrise unterstützt zudem alle anderen Datenbanken und Data Warehouses wie Oracle, IBM DB2, IBM Netezza, MySQL, MariaDB, Greenplum, Amazon Aurora, Amazon Redshift, Microsoft SQL Server, Azure SQL, Teradata und weitere. Sie können gerne eine kostenlose Testversion herunterladen, wenn Sie diese vor Ort installieren möchten. Falls Sie ein Cloud-Nutzer sind und Ihre Datenbank auf Amazon AWS oder Microsoft Azure betreiben, können Sie diese über den AWS Marketplace oder den Azure Marketplace beziehen.