Ich muss SSL für Übertragungen zwischen meiner Anwendung und SQL Server 2008 implementieren.
Ich verwende Windows 7, SQL Server 2008, SQL Server Management Studio und meine Anwendung ist in C# geschrieben.
Ich habe versucht, der MSDN-Seite zum Erstellen von Zertifikaten zu folgen undDasunter „Für einen bestimmten Client verschlüsseln“, aber ich war völlig verwirrt. Ich brauche ein paar kleine Schritte, um auf dem Weg zur erfolgreichen Implementierung der Verschlüsselung weiterzukommen.
Erstens verstehe ich MMC nicht. Ich sehe dort viele Zertifikate ... sind das Zertifikate, die ich für meine eigene Verschlüsselung verwenden sollte, oder werden diese für Dinge verwendet, die bereits existieren? Außerdem gehe ich davon aus, dass sich alle diese Zertifikate als Dateien auf meinem lokalen Computer befinden. Warum gibt es dann einen Ordner namens „Persönlich“?
Zweitens habe ich, um das oben genannte Problem zu vermeiden, ein kleines Experiment mit einer selbstsignierten Assembly durchgeführt. Wie im obigen MSDN-Link gezeigt, habe ich SQL verwendet, das in SSMS ausgeführt wurde, um ein selbstsigniertes Zertifikat zu erstellen. Dann habe ich die folgende Verbindungszeichenfolge zum Herstellen der Verbindung verwendet:
Data Source=myServer;Initial Catalog=myDatabase;User ID=myUser;Password=myPassword;Encrypt=True;TrustServerCertificate=True
Es wurde verbunden und funktionierte. Dann löschte ich das Zertifikat, das ich gerade erstellt hatte, und es funktionierte immer noch. Offensichtlich hat es nie etwas getan, aber warum nicht? Wie kann ich feststellen, ob es tatsächlich „funktioniert“? Ich glaube, ich übersehe möglicherweise einen Zwischenschritt, um (irgendwie?) die Datei von SSMS auf den Client zu übertragen?
Ich weiß nicht die geringste Ahnung, was ich tue, daher bin ich für jede Hilfe, jeden Rat, jeden Kommentar und jede Referenz, die Sie mir geben können, sehr dankbar.
Vielen Dank im Voraus. :)
Antwort1
Wenn ich die MSDN-Spezifikation richtig verstehe, müssen Sie nur in der Verbindungszeichenfolge angeben Encrypt=True;TrustServerCertificate=True. Dies bedeutet, dass der Client eine Verschlüsselung anfordert undist bereit, jedes vom Server verwendete Zertifikat zu akzeptieren. Der Server verfügt immer über ein selbstsigniertes Zertifikat, das beim Serverstart generiert wird, um es zu verwenden, wenn nichts anderes verfügbar ist. Wenn der Client bereit ist,beliebigWenn Sie ein Zertifikat haben, wird das temporäre, selbstsignierte Zertifikat dieses Servers akzeptiert. Es ist genauso gut wie jedes andere.
Ein solches Setup bietet einen verschlüsselten Kommunikationskanal zwischen Ihrer Anwendung und Ihrem Server, einen Kanal, der nicht ohne weiteres abgehört werden kann. Der Kanal ist jedoch anfällig für einen böswilligen Man-in-the-Middle-Angriff. Wenn ein Angreifer den Client dazu bringen kann, eine Verbindung herzustellenihnanstelle des Servers (z. B. durch die Kontrolle über die DNS-Einträge, genauer gesagt über die DNS-Server-IP, die der Client verwenden wird, was eine triviale DHCP-Einstellung ist, die zu kontrollieren ist), dann kann der Angreifer präsentierenbeliebigZertifikat und der Client akzeptiert es. Anschließend kann er die vollständige Authentifizierung mit dem Client durchführen und so den verwendeten SQL-Benutzernamen und das verwendete Passwort erhalten. Anschließend kann er sich mit dem echten Server verbinden und die gesamte Kommunikation hin und her leiten, wobei er den gesamten Inhalt einsehen kann. Der Client wird nie erfahren, dass er „überwacht“ wird. Dies ist der „Man-in-the-Middle“-Angriff.
Um die oben beschriebene Situation zu verhindern, muss der Kundemuss entfernendas TrustServerCertificate=Trueaus der Verbindungszeichenfolge. Sobald dies jedoch geschehen ist, wird das vom Server verwendete Zertifikathatvom Client als vertrauenswürdig eingestuft werden, und hier treten alle Komplikationen auf. Wenn Sie mit einer schwächeren Einstellung einverstanden sind, bei der Sie einen verschlüsselten Datenverkehr haben, aberverstehendas duMaieinem Man-in-the-Middle-Angriff ausgesetzt sein und Sie damit einverstanden sind, dann verwenden Sie die viel einfachere TrustServerCertificate=TrueEinstellung. Wenn nicht, dann müssen Sie leider wirklich verstehen, was Sie tun und es ist nicht trivial. Wenn die DatenAlsowichtig ist, dann ist es vielleicht nicht so abwegig, das Geld für ein VeriSign-, Thawte- oder GlobalSign-Zertifikat (dies sind die drei Stammzertifikate, denen jeder Windows-Client vertraut) für Ihren Server auszugeben (ca. 500 $ pro Jahr).
Antwort2
„Persönlich“ ist ein irreführender Name für den Zertifikatspeicher. Wenn Sie in der MMC ein auswählbares Zertifikat sehen, ist wahrscheinlich alles in Ordnung. Ich empfehle die Verwendung eines echten Zertifikats. Dies kann ein Zertifikat sein, das intern mit Microsoft Certificate Server erstellt oder von einem Zertifikatsanbieter erworben wurde. Ich würde kein selbstsigniertes Zertifikat verwenden. Der SQL Server-Instanzdienst muss außerdem neu gestartet werden, damit es 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 gewählten Konfiguration (selektiv oder erzwungen) benötigt Ihre Anwendung weiterhin Unterstützung für die verschiedenen Verbindungsoptionen. Beispielsweise das Verbindungsschlüsselwort „Encrypt“.
Ich persönlich habe festgestellt, dass der SQL Native-Client aussagekräftigere Fehlermeldungen bietet als der integrierte SQL-Client, aber Sie können mit beiden die Verschlüsselung verwenden/erzwingen.
Die Dokumentation von Microsoft ist etwas lückenhaft, aber es gibt ein paar gute Artikel:
Selektive Verwendung einer sicheren Verbindung zum SQL Server
Verknüpfung
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 Verbindungszeichenfolgen-Schlüsselwörtern mit SQL Server Native Client
http://msdn.microsoft.com/en-us/library/ms130822.aspx