Nye drivere til SQL Server ... Hvad du behøver at vide

For nylig udgav Microsoft to nye drivere til SQL Server, en større opgradering:

ODBC 18 Driver til SQL Server
OLEDB 19 Driver til SQL Server

Det er gode nyheder! Der er dog en stor brydende ændringer, der kræver din opmærksomhed. Specifikt ændrede de, hvordan standardindstillingerne fungerer for krypteringen. I alle tidligere versioner af drivere var standarden ikke at kræve kryptering. Vi havde muligheder for at tvinge kryptering fra serversiden eller anmode om det inden for forbindelsesstrengen på klientsiden. Naturligvis var det for serveradministratorer normalt mere ønskeligt at tvinge kryptering fra serveren, så det ville være ligegyldigt, hvis en gammel applikation ikke anmodede om det, men det ville garanteret kryptere sin kommunikation med serveren.

Der er 2 forbindelsesstrengnøgleord og en serverindstilling, der påvirker, hvordan driveren skal opføre sig:

Inden for forbindelsesstrengen fra klientsiden:

• Encrypt :Angiver om kommunikationen skal krypteres.
• TrustServerCertificate :Angiver, om klienten bare skal stole på serverens certifikat uden at kontrollere certifikatets ægthed.

Indenfor indstillinger fra serversiden:

• Force Encryption :Beordrer enhver klient, der opretter forbindelse til serveren, til at kryptere kommunikationen uanset klientens forbindelsesstreng.

Kombinationen af ​​de 3 egenskaber har indflydelse på, hvordan forbindelsen bliver lavet. Der er et praktisk diagram, der opregner dem, som kan findes her..

Det mest almindelige scenarie er dog, at vi tvinger kryptering fra serveren og ikke angiver andet i forbindelsesstrengen. Her er den udpakkede version af både tidligere versioner og ny versionsadfærd:

Jeg tror, ​​at dette generelt er en god ting, især med Azure SQL-databaser, der bliver mere almindelige, men ændringen af ​​kontrol af SQL Server-certifikatet indfører en ændring, især for servere, der måske ikke har certifikater sat op. Som standard vil den bruge et selvsigneret certifikat, som ikke er så sikkert som et, der er tillid til. For de servere, hvor der oprettes forbindelser over internettet, er den ekstra forholdsregel besværet værd.

Her er en sammenligning af ODBC-forbindelsesstrengene for Microsoft Access med SQL Server-ændringer mellem den tidligere version og den nu aktuelle version:

ODBC 17 vs. ODBC 18

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

OLEDB 18 vs. OLEDB 19 forbindelsesstrenge til Microsoft Access med SQL Server

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

Bemærk, at du i tidligere versioner skulle angive Encrypt=yes men dette er nu implicit i de nuværende versioner.

Ok, men jeg har en lokal server, men den virker ikke med de nye drivere?

På grund af ændringen i indstillingen kan du nu se denne fejl:

Afhængigt af scenariet og kravene er her mulige løsninger:

• Installer og konfigurer et pålideligt certifikat på serveren.
• Rediger applikationens forbindelsesstreng til at inkludere TrustServerCertificate=Yes . BRUG MED FORSIGTIGHED
• Rediger applikationens forbindelsesstreng til at inkludere Encrypt=No og deaktiver Force Encryption på serveren. ANBEFALES IKKE
• Opdater ikke drivere.

Trinene til at løse problemet er beskrevet i de tilsvarende afsnit.

Opløsninger

Installer og konfigurer et pålideligt certifikat på serveren

Det er meget vigtigt at bemærke, at bare fordi du har en server, der har et gyldigt SSL-certifikat sat op og i aktiv brug, betyder det faktisk ikke, at SQL Serveren bruger det samme certifikat. Desuden viser det sig, at SQL Server Configuration Manager er rædselsfuld til at håndtere certifikaterne. Du vil muligvis opdage, at den ikke viser nogen certifikater, som du kan bruge:

Den korte version er, at SQL Server Configuration Manager er overdrevent restriktiv med hensyn til, hvilke certifikater den vil vise, hvilket kan være ret frustrerende, især fordi dette er et UI-problem, ikke et sandt krav fra SQL Server selv. Heldigvis kan vi omgå denne fjollede UI-begrænsning ved at redigere registreringsdatabasen direkte. Dette svarer til registreringsdatabasenøglen:

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

Inden for denne nøgle er der en værdi Certificate som forventer et tommelfingeraftryk af certifikatet.

Du kan manuelt indsætte tommelfingeraftrykket af SSL-certifikatet, der skal bruges, men jeg vil anbefale at bruge et script til at gøre dette, da vi også skal sikre os, at serverkontoen har tilladelse til at få adgang til certifikatet. Jeg brugte denne blogartikel som en guide til opsætning af PowerShell-scriptet for at vælge certifikatet og indlæse det i SQL Servers registreringsnøgle og genstarte tjenesten. Afhængigt af, hvem der leverer dit SSL-certifikat og arbejdsgangen, vil du muligvis integrere dette i nogle andre planlagte opgaver, så når SSL-certifikatet fornyes, vil registreringsdatabasenøglen og tilladelserne blive opdateret i overensstemmelse hermed.

Hvis alt er konfigureret korrekt, bør din server være i stand til at bruge de nye drivere uden ændringer af applikationens forbindelsesstreng. Som en ekstra bekræftelse kan du tjekke din SQL Servers fejllog og se efter en linje som denne:

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

Hvis tommelfingeraftrykket matcher det, du vil bruge, så ved du, at du har det indlæst korrekt, og dermed er chain of trust nu etableret.

Rediger applikationens forbindelsesstreng til at inkludere TrustServerCertificate=Yes

Men hvis din server ikke vender mod internettet, og det er for smertefuldt at konfigurere et SSL-certifikat, kan det være acceptabelt at slå TrustServerCertificate til . Dette kræver en ændring i din applikations forbindelsesstreng. Dette giver applikationen mulighed for at oprette forbindelse til en server uden at bekræfte serverens certifikat. Hvis du er i stand til trygt at kontrollere din applikation, så den ikke går uden for dit netværk, burde dette være OK. Husk på, at hvis nogen er i stand til at forfalske serverens navn eller IP inden for netværket, vil klientapplikationerne blindt forbinde til den computer. Af den grund kan vi ikke anbefale dette, hvis der er internet involveret i forbindelsen. Vi vil virkelig helst ikke tage risikoen.

Rediger applikationens forbindelsesstreng til at inkludere Encrypt=No og deaktiver Force Encryption på serveren.

Dette er for dem, der kan lide at strege på internettet med et kæmpe neonskilt "STJÆL MINE DATA! KRAP MIG NU!" til alle dårlige skuespillere derude. Dette er øhm, en "mulighed". Det eneste, jeg kan sige om denne mulighed, er, at den er ekstremt dårlig. Så slemt, at jeg glemte, hvordan man gør dette. Du er alene, ven.

Opdater ikke drivere.

Et lidt bedre alternativ i forhold til det foregående er simpelthen ikke at opdatere og holde sig til ODBC 17 og OLEDB 18 drivere. Dette er dog i bedste fald en stopklods. Denne opløsning kræver ingen applikationsændringer, men dette forsinker kun de uundgåelige ændringer i bedste fald. Du kan bruge tiden til at udforske stier, der fører dig til den nyeste version og beskytter dine data ordentligt.

Håber det hjælper!