Neue Treiber für SQL Server… Was Sie wissen müssen

Kürzlich hat Microsoft zwei neue Treiber für SQL Server veröffentlicht, ein wichtiges Upgrade:

ODBC 18-Treiber für SQL Server
OLEDB 19-Treiber für SQL Server

Das sind gute Nachrichten! Es gibt jedoch wichtige Breaking Changes, die Ihre Aufmerksamkeit erfordern. Insbesondere haben sie geändert, wie die Standardeinstellungen für die Verschlüsselung funktionieren. In allen früheren Treiberversionen war standardmäßig keine Verschlüsselung erforderlich. Wir hatten die Möglichkeit, die Verschlüsselung von der Serverseite zu erzwingen oder sie innerhalb der Verbindungszeichenfolge auf der Clientseite anzufordern. Offensichtlich war es für Serveradministratoren normalerweise wünschenswerter, die Verschlüsselung vom Server zu erzwingen, damit es keine Rolle spielt, wenn eine alte Anwendung sie nicht anfordert, aber ihre Kommunikation mit dem Server garantiert verschlüsselt wird.

Es gibt 2 Schlüsselwörter für Verbindungszeichenfolgen und eine Servereinstellung, die beeinflusst, wie sich der Treiber verhalten soll:

Innerhalb der Verbindungszeichenfolge von der Clientseite:

Encrypt :Gibt an, ob die Kommunikation verschlüsselt werden soll.
TrustServerCertificate :Gibt an, ob der Client dem Zertifikat des Servers einfach vertrauen soll, ohne die Echtheit des Zertifikats zu prüfen.

Innerhalb der serverseitigen Einstellungen:

Force Encryption :Befiehlt jedem Client, der sich mit dem Server verbindet, die Kommunikation unabhängig von der Verbindungszeichenfolge des Clients zu verschlüsseln.

Die Kombination der 3 Eigenschaften beeinflusst, wie die Verbindung hergestellt wird. Es gibt eine praktische Tabelle, die sie auflistet, die hier zu finden ist..

Das häufigste Szenario ist jedoch, dass wir die Verschlüsselung vom Server erzwingen und nichts anderes in der Verbindungszeichenfolge angeben. Hier ist die extrahierte Version der beiden früheren Versionen und das Verhalten der neuen Version:

Version	Verschlüsseln	Trust Server Zertifikat	Server Force Verschlüsselung	Ergebnis
ODBC 17 und früher OLEDB 18 und früher	Nein	Nein	Ja	Serverzertifikat wird nicht geprüft. Die zwischen Client und Server gesendeten Daten werden verschlüsselt.
ODBC 18 OLEDB 19	Nein	Nein	Ja	Serverzertifikat wird überprüft. Die zwischen Client und Server gesendeten Daten werden verschlüsselt.

Ich denke, dass dies im Allgemeinen eine gute Sache ist, insbesondere da Azure SQL-Datenbanken immer häufiger verwendet werden, aber die Änderung der Überprüfung des SQL Server-Zertifikats führt zu einer Änderung, insbesondere für Server, auf denen möglicherweise keine Zertifikate eingerichtet sind. Standardmäßig wird ein selbstsigniertes Zertifikat verwendet, das nicht so sicher ist wie ein vertrauenswürdiges. Für Server, auf denen Verbindungen über das Internet hergestellt werden, lohnt sich die zusätzliche Vorsichtsmaßnahme.

Hier ist ein Vergleich der ODBC-Verbindungszeichenfolgen für Microsoft Access mit SQL Server-Änderungen zwischen der vorherigen Version und der jetzt aktuellen Version:

ODBC 17 im Vergleich zu ODBC 18

17:DRIVER=ODBC Driver 17 for SQL Server;SERVER= ;DATABASE= ; Verschlüsseln=ja;
18:DRIVER=ODBC Driver 18 for SQL Server;SERVER= ;DATABASE= ;

OLEDB 18 vs. OLEDB 19 Verbindungszeichenfolgen für Microsoft Access mit SQL Server

18:Provider= MSOLEDBSQL ;Data Source= ;Initial Catalog= ; Verschlüsseln=ja;
19:Provider= MSOLEDBSQL19 ;Data Source= ;Initial Catalog=

Beachten Sie, dass Sie in früheren Versionen Encrypt=yes angeben mussten aber das ist jetzt in den aktuellen Versionen implizit enthalten.

Okay, aber ich habe einen On-Premise-Server, aber er funktioniert nicht mit den neuen Treibern?

Aufgrund der Änderung der Einstellung sehen Sie jetzt möglicherweise diesen Fehler:

Je nach Szenario und Anforderungen sind hier mögliche Lösungen:

Installieren und konfigurieren Sie ein vertrauenswürdiges Zertifikat auf dem Server.
Ändern Sie die Verbindungszeichenfolge der Anwendung so, dass sie TrustServerCertificate=Yes enthält . MIT VORSICHT VERWENDEN
Ändern Sie die Verbindungszeichenfolge der Anwendung so, dass sie Encrypt=No enthält und deaktivieren Sie Force Encryption auf dem Server. NICHT EMPFOHLEN
Keine Treiber aktualisieren.

Die Schritte zur Behebung des Problems sind in den entsprechenden Abschnitten aufgeführt.

Auflösungen

Installieren und konfigurieren Sie ein vertrauenswürdiges Zertifikat auf dem Server

Es ist sehr wichtig zu beachten, dass nur weil Sie einen Server haben, auf dem ein gültiges SSL-Zertifikat eingerichtet ist und aktiv verwendet wird, dies nicht bedeutet, dass der SQL Server dasselbe Zertifikat verwendet. Außerdem stellt sich heraus, dass der SQL Server Configuration Manager furchtbar mit Zertifikaten umgeht. Möglicherweise werden Sie feststellen, dass keine Zertifikate aufgeführt sind, die Sie verwenden können:

Die Kurzversion ist, dass der SQL Server-Konfigurations-Manager übermäßig restriktiv ist, welche Zertifikate aufgelistet werden, was ziemlich frustrierend sein kann, insbesondere weil dies ein UI-Problem ist und keine echte Anforderung von SQL Server selbst. Glücklicherweise können wir diese dumme Einschränkung der Benutzeroberfläche umgehen, indem wir die Registrierung direkt bearbeiten. Dies entspricht dem Registrierungsschlüssel:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<name of your instance>\MSSQLServer\SuperSocketNetLib

Innerhalb dieses Schlüssels gibt es einen Wert Certificate die einen Fingerabdruck des Zertifikats erwartet.

Sie könnten den Fingerabdruck des zu verwendenden SSL-Zertifikats manuell einfügen, aber ich würde empfehlen, dafür ein Skript zu verwenden, da wir auch sicherstellen müssen, dass das Serverkonto die Berechtigung hat, auf das Zertifikat zuzugreifen. Ich habe diesen Blogartikel als Leitfaden für die Einrichtung des PowerShell-Skripts verwendet, um das Zertifikat auszuwählen und in den Registrierungsschlüssel von SQL Server zu laden und den Dienst neu zu starten. Je nachdem, wer Ihr SSL-Zertifikat und den Arbeitsablauf bereitstellt, möchten Sie dies möglicherweise in einige andere geplante Aufgaben integrieren, damit bei Erneuerung des SSL-Zertifikats der Registrierungsschlüssel und die Berechtigungen entsprechend aktualisiert werden.

Wenn alles richtig eingerichtet ist, sollte Ihr Server in der Lage sein, die neuen Treiber ohne Änderungen an der Verbindungszeichenfolge der Anwendung zu verwenden. Als zusätzliche Überprüfung können Sie das Fehlerprotokoll Ihres SQL-Servers überprüfen und nach einer Zeile wie dieser suchen:

<timestamp> spid11s The certificate [Cert Hash(sha1) "<certificate thumbprint>"] was successfully loaded for encryption.

Wenn der Fingerabdruck mit dem übereinstimmt, den Sie verwenden möchten, wissen Sie, dass Sie ihn korrekt geladen haben, und somit ist jetzt eine Vertrauenskette eingerichtet.

Ändern Sie die Verbindungszeichenfolge der Anwendung so, dass sie `TrustServerCertificate=Yes` enthält

Wenn Ihr Server jedoch nicht mit dem Internet verbunden ist und es zu mühsam ist, ein SSL-Zertifikat einzurichten, kann es akzeptabel sein, TrustServerCertificate zu aktivieren . Dies erfordert eine Änderung der Verbindungszeichenfolge Ihrer Anwendung. Dadurch kann die Anwendung eine Verbindung zu einem Server zulassen, ohne das Zertifikat des Servers zu überprüfen. Wenn Sie Ihre Anwendung so steuern können, dass sie Ihr Netzwerk nicht verlässt, sollte dies in Ordnung sein. Denken Sie daran, dass sich die Client-Anwendungen blind mit diesem Computer verbinden, wenn jemand in der Lage ist, den Namen oder die IP des Servers innerhalb des Netzwerks zu fälschen. Aus diesem Grund können wir dies nicht empfehlen, wenn die Verbindung mit dem Internet verbunden ist. Das Risiko gehen wir wirklich lieber nicht ein.

Ändern Sie die Verbindungszeichenfolge der Anwendung so, dass sie `Encrypt=No` enthält und deaktivieren Sie `Force Encryption` auf dem Server.

Dies ist für diejenigen, die gerne im Internet mit einem riesigen Neonschild „STEAL MY DATA! ENTFÜHREN SIE MICH JETZT!“ an alle schlechten Schauspieler da draußen. Das ist äh, eine „Option“. Das einzige, was ich zu dieser Option sagen kann, ist, dass sie äußerst schlecht ist. So schlimm, dass ich vergessen habe, wie das geht. Du bist auf dich allein gestellt, Kumpel.

Treiber nicht aktualisieren.

Eine etwas bessere Alternative im Vergleich zur vorherigen Version besteht darin, einfach nicht zu aktualisieren und bei den ODBC 17- und OLEDB 18-Treibern zu bleiben. Dies ist jedoch bestenfalls eine Notlösung. Diese Auflösung erfordert keine Anwendungsänderungen, sondern verzögert die unvermeidlichen Änderungen bestenfalls. Sie können die Zeit nutzen, um Wege zu erkunden, die Sie zur neuesten Version führen und Ihre Daten angemessen schützen.

Hoffe das hilft!