Zertifikate in SQL Server 2008

Ich muss SSL für Übertragungen zwischen meiner Anwendung und SQL Server 2008 implementieren.

Ich verwende Windows 7, SQL Server 2008 und SQL Server Management Studio und meine Anwendung ist in c # geschrieben.

Ich habe versucht, der MSDN-Seite zum Erstellen von Zertifikaten zu folgen, und dies unter "Encrpyt für einen bestimmten Client", aber ich war hoffnungslos verwirrt. Ich brauche ein paar kleine Schritte, um die Verschlüsselung erfolgreich zu implementieren.

Erstens verstehe ich MMC nicht. Ich sehe dort viele Zertifikate ... sind dies Zertifikate, die ich für meine eigene Verschlüsselung verwenden sollte, oder werden diese für Dinge verwendet, die bereits existieren? Ich gehe davon aus, dass sich alle diese Zertifikate auf meinem lokalen Computer befinden. Warum gibt es also einen Ordner mit dem Namen "Persönlich"?

Zweitens habe ich ein kleines Experiment mit einer selbstsignierten Baugruppe durchgeführt, um das oben genannte Problem zu vermeiden. Wie im obigen MSDN-Link gezeigt, habe ich in SSMS ausgeführtes SQL verwendet, um ein selbstsigniertes Zertifikat zu erstellen. Dann habe ich die folgende Verbindungszeichenfolge verwendet, um eine Verbindung herzustellen:

 Data Source=myServer;Initial Catalog=myDatabase;User ID=myUser;Password=myPassword;Encrypt=True;TrustServerCertificate=True

Es hat verbunden, funktioniert. Dann habe ich das soeben erstellte Zertifikat gelöscht und es hat immer noch funktioniert. Offensichtlich hat es nie etwas getan, aber warum nicht? Wie würde ich sagen, ob es tatsächlich "funktioniert"? Ich glaube, ich vermisse möglicherweise einen Zwischenschritt, um (irgendwie?) Die Datei von SSMS auf den Client zu bringen.

Ich weiß nicht im geringsten, was ich tue, daher sind jede Hilfe, jeder Rat, jeder Kommentar und jede Referenz, die Sie mir geben können, sehr willkommen.

Vielen Dank im Voraus. :) :)

Wenn ich die MSDN-Spezifikation richtig verstehe, müssen Sie sie nur in der Verbindungszeichenfolge angeben Encrypt=True;TrustServerCertificate=True. Dies bedeutet, dass der Client eine Verschlüsselung anfordert und bereit ist, alle vom Server verwendeten Zertifikate zu akzeptieren . Der Server verfügt beim Start des Servers immer über ein selbstsigniertes Zertifikat, das verwendet werden kann, wenn nichts anderes verfügbar ist. Wenn der Client bereit ist, ein Zertifikat zu akzeptieren , akzeptiert er das temporäre selbstsignierte Zertifikat des Servers, das genauso gut ist wie jedes andere.

Ein solches Setup bietet einen verschlüsselten Kommunikationskanal zwischen Ihrer Anwendung und Ihrem Server, der nicht einfach zu hören ist. Der Kanal ist jedoch offen für einen böswilligen Man-in-the-Middle-Angriff. Wenn ein Angreifer den Client täuschen kann, eine Verbindung zu ihm anstelle des Servers herzustellen (z. B. indem er die Kontrolle über die DNS-Einträge hat, genauer gesagt die DNS-Server-IP, die der Client verwendet, was eine triviale DHCP-Einstellung ist), kann der Angreifer dies präsentieren keineDas Zertifikat und der Client akzeptieren es. Anschließend kann er den vollständigen Authentifizierungs-Roundtrip mit dem Client durchführen und so den verwendeten SQL-Benutzernamen und das verwendete Kennwort abrufen. Anschließend kann er eine Verbindung zum echten Server herstellen und die gesamte Kommunikation mit a Kostenloser Blick auf den gesamten Inhalt. Der Kunde wird nie erfahren, dass er "überwacht" wird. Dies ist der "Mann in der Mitte" -Angriff.

Um die obige Situation zu verhindern, muss der Client die TrustServerCertificate=Trueaus der Verbindungszeichenfolge entfernen . Sobald dies jedoch getan wird, das Zertifikat vom Server verwendet hat , die von den Kunden vertraut werden, und dies ist , wenn alle Komplikationen auftreten. Wenn Sie mit einer schwächeren Einstellung, für die Sie einen verschlüsselten Datenverkehr haben, einverstanden sind, aber verstehen, dass Sie möglicherweise einem Man-in-the-Middle-Angriff ausgesetzt sind und damit einverstanden sind, verwenden Sie die viel einfachere TrustServerCertificate=TrueEinstellung. Wenn nicht, dann müssen Sie leider wirklich verstehen, was Sie tun und ist nicht trivial. Wenn die Daten so sind Wichtig, dann ist es vielleicht nicht so ausgefallen, die Gelder für ein VeriSign-, Thawte- oder GlobalSign-Zertifikat (dies sind die drei Wurzeln, denen jeder Windows-Client vertraut) für Ihren Server (~ 500 US-Dollar / Jahr) auszugeben.

"Persönlich" ist ein irreführender Name für den Zertifikatspeicher. Wenn Sie sich in der MMC befinden und ein Zertifikat sehen, das ausgewählt werden kann, sind Sie wahrscheinlich in Ordnung. Ich empfehle die Verwendung eines echten Zertifikats. Dies kann ein Zertifikat sein, das intern mit Microsoft Certificate Server erstellt wurde, oder ein Zertifikat, das von einem Zertifizierungsanbieter erworben wurde. Ich würde kein selbstsigniertes Zertifikat verwenden. Der SQL Server-Instanzdienst muss ebenfalls neu gestartet werden, damit er wirksam wird.

Einige allgemeine Tipps:

Wenn Sie die Verschlüsselung auf dem Client erzwingen, muss die gesamte SQL-Kommunikation auf dem Client die Verschlüsselung auf Transportebene verwenden.

Wenn Sie die Verschlüsselung auf dem Server erzwingen, muss die gesamte SQL-Kommunikation für diese Instanz die Verschlüsselung auf Transportebene verwenden.

Unabhängig von der von Ihnen gewählten Konfiguration (selektiv oder erzwungen) benötigt Ihre Anwendung weiterhin Unterstützung für die verschiedenen Verbindungsoptionen. Wie das Schlüsselwort "Verbindung verschlüsseln".

Ich persönlich habe festgestellt, dass der SQL Native-Client aussagekräftigere Fehlermeldungen enthält als der integrierte SQL-Client, aber Sie können die Verschlüsselung mit beiden verwenden / erzwingen.

Die Dokumentation von Microsoft ist etwas lückenhaft, aber es gibt ein paar gute Artikel:

Selektive Verwendung einer sicheren Verbindung zu SQL Server
http://blogs.msdn.com/b/sql_protocols/archive/2009/10/19/selectively-using-secure-connection-to-sql-server.aspx

So aktivieren Sie die SSL-Verschlüsselung für eine Instanz von SQL Server mithilfe der Microsoft Management Console
http://support.microsoft.com/kb/316898

Verwenden von Verbindungszeichenfolgenschlüsselwörtern mit SQL Server Native Client
http://msdn.microsoft.com/en-us/library/ms130822.aspx