Nieuwe stuurprogramma's voor SQL Server... Wat u moet weten

Onlangs heeft Microsoft twee nieuwe stuurprogramma's voor SQL Server uitgebracht, een belangrijke upgrade:

ODBC 18-stuurprogramma voor SQL Server
OLEDB 19-stuurprogramma voor SQL Server

Dat is geweldig nieuws! Er is echter een belangrijke verandering die uw aandacht vereist. Ze hebben met name de manier veranderd waarop de standaardinstellingen voor de codering werken. In alle eerdere versies van stuurprogramma's was de standaardinstelling om geen codering te vereisen. We hadden de opties om codering van de serverkant af te dwingen of deze aan te vragen binnen de verbindingsreeks aan de clientkant. Het is duidelijk dat voor serverbeheerders het meestal wenselijker was om versleuteling van de server af te dwingen, zodat het niet uitmaakt of een oude applicatie hier niet om vraagt, maar het gegarandeerd zou zijn om de communicatie met de server te versleutelen.

Er zijn 2 verbindingsstring-trefwoorden en een serverinstelling die van invloed zijn op hoe het stuurprogramma zich moet gedragen:

Binnen de verbindingsreeks vanaf clientzijde:

• Encrypt :Geeft aan of de communicatie versleuteld moet worden.
• TrustServerCertificate :Geeft aan of de client het certificaat van de server gewoon moet vertrouwen zonder de authenticiteit van het certificaat te controleren.

Binnen instellingen van de serverzijde:

• Force Encryption :verplicht elke client die verbinding maakt met de server om de communicatie te coderen, ongeacht de verbindingsreeks van de client.

De combinatie van de 3 eigenschappen heeft invloed op hoe de verbinding tot stand komt. Er is een handig overzicht waarin ze worden opgesomd, die u hier kunt vinden..

Het meest voorkomende scenario is echter dat we codering van de server afdwingen en niets anders specificeren in de verbindingsreeks. Hier is de geëxtraheerde versie van zowel eerdere versies als het gedrag van nieuwe versies:

Ik denk dat dit over het algemeen een goede zaak is, vooral nu Azure SQL-databases steeds gebruikelijker worden, maar de wijziging van het controleren van het SQL Server-certificaat introduceert wel een wijziging, vooral voor servers waarop mogelijk geen certificaten zijn ingesteld. Standaard gebruikt het een zelfondertekend certificaat, dat niet zo veilig is als een vertrouwd certificaat. Voor die servers waar verbindingen via internet worden gemaakt, is de extra voorzorg de moeite waard.

Hier is een vergelijking van de ODBC-verbindingsreeksen voor Microsoft Access met SQL Server-wijzigingen tussen de vorige versie en de nu huidige versie:

ODBC 17 versus ODBC 18

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

OLEDB 18 vs. OLEDB 19 verbindingsreeksen voor Microsoft Access met SQL Server

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

Merk op dat u in eerdere versies de Encrypt=yes . moest specificeren maar dit is nu impliciet in de huidige versies.

Ok, maar ik heb een server op locatie, maar deze werkt niet met de nieuwe stuurprogramma's?

Vanwege de wijziging in de instelling ziet u nu mogelijk deze fout:

Afhankelijk van het scenario en de vereisten zijn hier mogelijke oplossingen:

• Installeer en configureer een vertrouwd certificaat op de server.
• Wijzig de verbindingsreeks van de toepassing om TrustServerCertificate=Yes op te nemen . VOORZICHTIG GEBRUIKEN
• Wijzig de verbindingsreeks van de applicatie om Encrypt=No . op te nemen en schakel Force Encryption uit op de server. NIET AANBEVOLEN
• Stuurprogramma's niet bijwerken.

De stappen om het probleem op te lossen worden beschreven in de overeenkomstige secties.

Resoluties

Installeer en configureer een vertrouwd certificaat op de server

Het is erg belangrijk op te merken dat het feit dat u een server heeft waarop een geldig SSL-certificaat is ingesteld en actief wordt gebruikt, niet betekent dat de SQL Server hetzelfde certificaat gebruikt. Verder blijkt dat de SQL Server Configuration Manager afschuwelijk is in het omgaan met de certificaten. Mogelijk merkt u dat er geen certificaten worden vermeld die u kunt gebruiken:

De korte versie is dat SQL Server Configuration Manager buitengewoon beperkend is voor welke certificaten het zal vermelden, wat behoorlijk frustrerend kan zijn, vooral omdat dit een UI-probleem is, geen echte vereiste door SQL Server zelf. Gelukkig kunnen we deze dwaze UI-beperking omzeilen door het register rechtstreeks te bewerken. Dit komt overeen met de registersleutel:

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

Binnen die sleutel is er een waarde Certificate die een vingerafdruk van het certificaat verwacht.

U kunt handmatig de vingerafdruk van het te gebruiken SSL-certificaat plakken, maar ik raad u aan hiervoor een script te gebruiken, omdat we er ook voor moeten zorgen dat het serveraccount toestemming heeft om toegang te krijgen tot het certificaat. Ik heb dit blogartikel gebruikt als een gids voor het instellen van het PowerShell-script om het certificaat te selecteren en het in de registersleutel van SQL Server te laden en de service opnieuw te starten. Afhankelijk van wie uw SSL-certificaat en de workflow levert, wilt u dit misschien integreren in een aantal andere geplande taken, zodat wanneer het SSL-certificaat wordt vernieuwd, de registersleutel en machtigingen dienovereenkomstig worden bijgewerkt.

Als alles correct is ingesteld, zou uw server de nieuwe stuurprogramma's moeten kunnen gebruiken zonder enige wijziging in de verbindingsreeks van de toepassing. Als extra verificatie kunt u het foutenlogboek van uw SQL Server controleren en zoeken naar een regel als deze:

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

Als de vingerafdruk overeenkomt met degene die u wilt gebruiken, weet u dat u deze correct hebt geladen en is er nu een vertrouwensketen tot stand gebracht.

Wijzig de verbindingsreeks van de toepassing om TrustServerCertificate=Yes op te nemen

Als uw server echter niet op internet staat en het te pijnlijk is om een ​​SSL-certificaat in te stellen, kan het acceptabel zijn om TrustServerCertificate in te schakelen. . Dit vereist een wijziging in de verbindingsreeks van uw toepassing. Hierdoor kan de toepassing verbinding maken met een server zonder het certificaat van de server te verifiëren. Als u uw toepassing met vertrouwen kunt besturen, zodat deze niet buiten uw netwerk komt, zou dit in orde moeten zijn. Houd er rekening mee dat als iemand de naam of het IP-adres van de server binnen het netwerk kan vervalsen, de clienttoepassingen blindelings verbinding maken met die computer. Om die reden kunnen we dit niet aanbevelen als er internet bij de verbinding betrokken is. We nemen het risico liever niet.

Wijzig de verbindingsreeks van de applicatie om Encrypt=No . op te nemen en schakel Force Encryption uit op de server.

Dit is voor degenen die graag op internet willen strepen met een gigantisch neonbord "STEAL MY DATA! KAP MIJ NU!” aan alle slechte acteurs die er zijn. Dit is eh, een "optie". Het enige dat ik over deze optie kan zeggen, is dat het buitengewoon slecht is. Zo erg dat ik vergeten ben hoe ik dit moet doen. Je staat er alleen voor, maat.

Stuurprogramma's niet bijwerken.

Een iets beter alternatief in vergelijking met het vorige is om gewoon niet bij te werken en vast te houden aan ODBC 17- en OLEDB 18-stuurprogramma's. Dit is echter op zijn best een noodmaatregel. Deze resolutie vereist geen applicatiewijzigingen, maar dit vertraagt ​​hoogstens de onvermijdelijke wijzigingen. U kunt de tijd gebruiken om paden te verkennen die u naar de nieuwste versie brengen en uw gegevens goed beschermen.

Ik hoop dat dat helpt!