Kommunikationsverschlüsselung und Zertifikate in SQL Server

SQL Server kann die Kommunikation zwischen Client und Server schon seit einigen Versionen verschlüsseln. Seit SQL Server 2005 ist dabei nicht mal mehr die Installation eines SSL-Zertifikats auf dem Server notwendig – allerdings ist sie dennoch sinnvoll, zum Warum komme ich noch. Die Login-Pakete für SQL-Logins sind seit SQL Server 2005 übrigens immer verschlüsselt (wenn die Clientsoftware das unterstützt).

Wer verschlüsselte Kommunikation zwischen Client und Server einrichten will, der sollte vorher testen, ob alle verwendete Clientsoftware Verschlüsselung unterstützt. Bei Microsoft-Clientsoftware sollte mindestens MDAC 2.6 installiert sein (die ist schon ziemlich alt), MDAC 2.53 und die uralte DBLibrary unterstützen keine Verschlüsselung. Wenn fremde Clientsoftware zum Einsatz kommt sollte geprüft werden, ob Verschlüsselung unterstützt wird.

Außerdem sollte beachtet werden, dass jede Form von Verschlüsselung zusätzliche CPU-Last erzeugt und dass verschlüsselte Datenströme nicht mehr komprimiert werden können (z.B. mit einem WAN Accelerator).

Wie schaltet man Verschlüsselung nun ein? Ganz einfach: Mit dem SQL Server Configuration Manager. Dort öffnet man den Knoten “SQL Server Network Configuration”, wählt “Properties for <Instanzname>”, macht einen Rechtsklick und wählt “Properties” (bzw. Eigenschaften). Jetzt setzt man einfach “Force Encryption” auf Yes:

Danach muss der SQL Server Dienst neu gestartet werden, und es werden nur noch verschlüsselte Verbindungen akzeptiert.

Wenn dabei im “Certificate” Tab kein geeignetes SSL-Zertifikat gewählt wird, dann generiert SQL Server (ab 2005) ein selbstsigniertes Zertifikat. Das bedeutet, dass die Kommunikation zwischen Client und Server verschlüsselt ist, ein passives Abhören der Daten also nicht möglich ist.

Gleichzeitig bedeutet es aber auch, dass der Client nicht die Identität des Servers prüfen kann, da das vom Server selbst erstellte Zertifikat aus Clientsicht nicht vertrauenswürdig ist (ein solches Zertifikat kann sich ja auch jeder Angreifer erstellen). So genannte “Man in the middle” Angriffe sind also weiterhin möglich. Bei einer “Man in the middle” Attacke schafft es der Angreifer, sich aktiv zwischen Client und Server zu stellen (z.B. über DNS Spoofing oder indem der Angreifer einen Router übernehmen kann). Er gibt sich dann dem Server gegenüber als Client aus und dem Client gegenüber als Server. Solch ein Angriff ist natürlich weit schwieriger zu bewerkstelligen als ein passives Abhören.

Wer das verhindern möchte, der muss auch in SQL Server 2005 und 2008 ein SSL-Zertifikat installiert werden, das von einer (aus Clientsicht) vertrauenswürdigen Stammzertifizierungsstelle signiert wurde und auf den vollqualifizierten Namen (FQDN) des Servers ausgestellt wurde. Ein solches Zertifikat kann man von einer firmeneigenen PKI erhalten oder bei einem Zertifikatsanbieter (gegen Geld und entsprechende Nachweise) kaufen. Es ist dieselbe Art Zertifikat, die man auch für einen Webserver braucht.

Wenn man in der SQL Server Clientsoftware “Encrypt Connection” aktivieren möchte, dann verlangt der Client ebenfalls ein von einer vertrauenswürdigen Stammzertifizierungsstelle signiertes Zertifikat:

Hat man ein solches Zertifikat, so muss man es für das Computerkonto installieren. Dazu öffnet man die Managementkonsole (mmc.exe) und fügt das Zertifikate-Snapin für das lokale Computerkonto hinzu:

Dann importiert man das Zertifikat inklusive privatem Schlüssel (am Besten aus einer .pfx-Datei) in den Zertifikatsspeicher “Eigene Zertifikate->Zertifikate”:

Wenn alles richtig gemacht wurde und das Zertifikat den Anforderungen entspricht, dann kann man das Zertifikat jetzt im SQL Server Configuration Manager auswählen:

Nun braucht wieder nur der SQL Server neu gestartet zu werden. Allerdings kann es sein, dass SQL Server jetzt nicht startet. Das passiert, wenn (wie empfohlen) SQL Server unter einem nicht-administrativen Konto ausgeführt wird. Dieses Verhalten ist für “Network Service” in  KB900495 dokumentiert, betrifft aber jedes nicht-administrative SQL Server Dienstkonto. Der Hintergrund ist, dass in aktuellen Windows-Versionen nur Administratoren Zugriff auf die privaten Schlüssel des Computerkontos haben.

Um Abhilfe zu schaffen müssen wir dem SQL Server Dienstkonto Rechte am Privaten Schlüssel geben. Das geht wieder über die Zertifikatsverwaltung. Man wählt das betreffende Zertifikat aus, wählt rechts “Weitere Aufgaben”->”Alle Aufgaben”->”Private Schlüssel verwalten”:

Hier fügt man das SQL Server Dienstkonto mit Leseberechtigungen hinzu. Nun kann der SQL Server Dienst wieder gestartet werden, und auch die “Encrypt Connection” Einstellung auf dem Client ist möglich.´

Eine Warnung zum Schluss: Wenn man später aus irgendwelchen Gründen das Zertifikat auf dem Server löschen will sollte man es tunlichst erst über den “Clear”-Button im SQL Server Configuration Manager Zertifikate-Tab aus der SQL Server Konfiguration entfernen. Hat man das vergessen, bevor man das Zertifikat gelöscht hat kann man das gewählte Zertifikat nur noch über den Registry-Editor löschen (Wert von HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQLServer\SuperSocketNetLib\Certificate).

Gruß,
Steffen

Comments

• Anonymous
  January 01, 2003
  SQL Server kann die Kommunikation zwischen Client und Server schon seit einigen Versionen verschlüsseln