Nya drivrutiner för SQL Server ... Vad du behöver veta

Nyligen släppte Microsoft två nya drivrutiner för SQL Server, en stor uppgradering:

ODBC 18-drivrutin för SQL Server
OLEDB 19-drivrutin för SQL Server

Det är fantastiska nyheter! Det finns dock stora förändringar som kräver din uppmärksamhet. Specifikt ändrade de hur standardinställningarna fungerar för krypteringen. I alla tidigare versioner av drivrutiner var standard att inte kräva kryptering. Vi hade alternativen att tvinga fram kryptering från serversidan eller begära den inom anslutningssträngen på klientsidan. Uppenbarligen, för serveradministratörer, var det vanligtvis mer önskvärt att tvinga fram kryptering från servern, så att det inte skulle spela någon roll om någon gammal applikation inte begärde det men den skulle garanterat kryptera sin kommunikation med servern.

Det finns 2 nyckelord för anslutningssträngar och en serverinställning som påverkar hur drivrutinen ska bete sig:

Inom anslutningssträngen från klientsidan:

• Encrypt :Indikerar om kommunikationen ska krypteras.
• TrustServerCertificate :Indikerar om klienten bara ska lita på serverns certifikat utan att kontrollera certifikatets äkthet.

Inom inställningar från serversidan:

• Force Encryption :Beordrar att alla klienter som ansluter till servern krypterar kommunikationen oavsett klientens anslutningssträng.

Kombinationen av de 3 egenskaperna påverkar hur kopplingen kommer att göras. Det finns ett praktiskt diagram som räknar upp dem, som finns här...

Det vanligaste scenariot är dock att vi tvingar fram kryptering från servern och inte specificerar något annat i anslutningssträngen. Här är den extraherade versionen av både tidigare versioner och ny version:

Jag tror att detta generellt sett är bra, särskilt med Azure SQL-databaser som blir vanligare, men förändringen av att kontrollera SQL Server-certifikatet innebär en förändring, särskilt för servrar som kanske inte har certifikat inställda. Som standard kommer den att använda ett självsignerat certifikat, som inte är lika säkert som ett som är pålitligt. För de servrar där anslutningar görs över internet är den extra försiktighetsåtgärden värd ansträngningen.

Här är en jämförelse av ODBC-anslutningssträngarna för Microsoft Access med SQL Server-ändringar mellan den tidigare versionen och den nu aktuella versionen:

ODBC 17 vs. ODBC 18

17:DRIVER=ODBC Driver 17 for SQL Server;SERVER= ;DATABASE= ; Kryptera=ja;
18:DRIVER=ODBC Driver 18 for SQL Server;SERVER= ;DATABASE= ;

OLEDB 18 vs. OLEDB 19 anslutningssträngar för Microsoft Access med SQL Server

18:Provider= MSOLEDBSQL ;Data Source= ;Initial Catalog= ; Kryptera=ja;
19:Provider= MSOLEDBSQL19 ;Data Source= ;Initial Catalog=

Observera att i tidigare versioner var du tvungen att ange Encrypt=yes men detta är nu implicit i de nuvarande versionerna.

Ok, men jag har en lokal server men den fungerar inte med de nya drivrutinerna?

På grund av ändringen i inställningen kan du nu se detta fel:

Beroende på scenariot och kraven finns här möjliga lösningar:

• Installera och konfigurera ett pålitligt certifikat på servern.
• Ändra applikationens anslutningssträng så att den inkluderar TrustServerCertificate=Yes . ANVÄND MED FÖRSIKTIGHET
• Ändra applikationens anslutningssträng så att den inkluderar Encrypt=No och inaktivera Force Encryption på servern. REKOMMENDERAS INTE
• Uppdatera inte drivrutiner.

Stegen för att lösa problemet beskrivs i motsvarande avsnitt.

Upplösningar

Installera och konfigurera ett pålitligt certifikat på servern

Det är mycket viktigt att notera att bara för att du har en server som har ett giltigt SSL-certifikat inställt och i aktiv användning betyder det faktiskt inte att SQL-servern använder samma certifikat. Dessutom visar det sig att SQL Server Configuration Manager är hemsk på att hantera certifikaten. Du kanske upptäcker att det inte kommer att lista några certifikat som du kan använda:

Den korta versionen är att SQL Server Configuration Manager är överdrivet restriktiv för vilka certifikat den kommer att lista, vilket kan vara ganska frustrerande särskilt eftersom detta är ett UI-problem, inte ett sant krav från SQL Server själv. Lyckligtvis kan vi kringgå denna fåniga gränssnittsbegränsning genom att redigera registret direkt. Detta motsvarar registernyckeln:

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

Inom den nyckeln finns ett värde Certificate som förväntar sig ett tumavtryck av certifikatet.

Du kan manuellt klistra in tumavtrycket för SSL-certifikatet som ska användas men jag skulle rekommendera att du använder ett skript för att göra detta eftersom vi också måste se till att serverkontot har behörighet att komma åt certifikatet. Jag använde den här bloggartikeln som en guide för att ställa in PowerShell-skriptet för att välja certifikatet och ladda det i SQL Servers registernyckel och starta om tjänsten. Beroende på vem som tillhandahåller ditt SSL-certifikat och arbetsflödet kanske du vill integrera detta i några andra schemalagda uppgifter så att när SSL-certifikatet förnyas kommer registernyckeln och behörigheterna att uppdateras i enlighet med detta.

Om allt är korrekt inställt bör din server kunna använda de nya drivrutinerna utan några ändringar av programmets anslutningssträng. Som en extra verifiering kan du kontrollera din SQL Servers fellogg och leta efter en rad så här:

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

Om tumavtrycket stämmer överens med det du vill använda vet du att du har det korrekt laddat och därmed är förtroendekedjan nu etablerad.

Ändra applikationens anslutningssträng så att den inkluderar TrustServerCertificate=Yes

Men om din server inte är vänd mot internet och det är för smärtsamt att konfigurera ett SSL-certifikat, kan det vara acceptabelt att aktivera TrustServerCertificate . Detta kräver en ändring av din applikations anslutningssträng. Detta gör att applikationen tillåter anslutning till en server utan att verifiera serverns certifikat. Om du med säkerhet kan kontrollera din applikation så att den inte hamnar utanför ditt nätverk bör detta vara OK. Tänk på att om någon kan förfalska serverns namn eller IP inom nätverket kommer klientapplikationerna blint att ansluta till den datorn. Av den anledningen kan vi inte rekommendera detta om det finns internet inblandat i anslutningen. Vi vill verkligen inte ta risken.

Ändra applikationens anslutningssträng så att den inkluderar Encrypt=No och inaktivera Force Encryption på servern.

Det här är för dem som gillar att sträcka på internet med en gigantisk neonskylt "STEAL MY DATA! KAPA MIG NU!" till alla dåliga skådespelare där ute. Detta är erm, ett "alternativ". Det enda jag kan säga om det här alternativet är att det är oerhört dåligt. Så illa att jag glömde hur man gör detta. Du är ensam, kompis.

Uppdatera inte drivrutiner.

Ett något bättre alternativ jämfört med föregående är att helt enkelt inte uppdatera och hålla sig till ODBC 17 och OLEDB 18 drivrutiner. Detta är dock i bästa fall en stoppåtgärd. Denna upplösning kräver inga applikationsändringar men detta fördröjer bara de oundvikliga ändringarna i bästa fall. Du kan använda tiden för att utforska vägar som tar dig till den senaste versionen och skyddar din data ordentligt.

Hoppas det hjälper!