Nouveaux pilotes pour SQL Server… Ce que vous devez savoir

Récemment, Microsoft a publié deux nouveaux pilotes pour SQL Server, une mise à jour majeure :

Pilote ODBC 18 pour SQL Server
Pilote OLEDB 19 pour SQL Server

Ce sont de bonnes nouvelles! Cependant, il y a des changements majeurs qui nécessitent votre attention. Plus précisément, ils ont modifié le fonctionnement des paramètres par défaut pour le cryptage. Dans toutes les versions précédentes des pilotes, la valeur par défaut était de ne pas exiger de chiffrement. Nous avions la possibilité de forcer le chiffrement côté serveur ou de le demander dans la chaîne de connexion côté client. Évidemment, pour l'administrateur du serveur, il était généralement plus souhaitable de forcer le chiffrement à partir du serveur, de sorte que cela n'aurait pas d'importance si une ancienne application ne le demandait pas, mais il serait garanti de chiffrer sa communication avec le serveur.

Il existe 2 mots-clés de chaîne de connexion et un paramètre de serveur qui influencent le comportement du pilote :

Dans la chaîne de connexion côté client :

• Encrypt :Indique si la communication doit être cryptée.
• TrustServerCertificate  :Indique si le client doit simplement faire confiance au certificat du serveur sans vérifier l'authenticité du certificat.

Dans les paramètres côté serveur :

• Force Encryption  :oblige tout client se connectant au serveur à chiffrer la communication, quelle que soit la chaîne de connexion du client.

La combinaison des 3 propriétés influence la manière dont la connexion sera établie. Il existe un tableau pratique les énumérant, qui peut être trouvé ici..

Cependant, le scénario le plus courant est que nous forçons le chiffrement à partir du serveur et ne spécifions rien d'autre dans la chaîne de connexion. Voici la version extraite des versions précédentes et du comportement de la nouvelle version :

Je pense que c'est généralement une bonne chose, en particulier avec les bases de données Azure SQL qui deviennent plus courantes, mais le changement de vérification du certificat SQL Server introduit un changement, en particulier pour les serveurs qui pourraient ne pas avoir de certificats configurés. Par défaut, il utilisera un certificat auto-signé, qui n'est pas aussi sûr qu'un certificat de confiance. Pour les serveurs où les connexions sont établies sur Internet, la précaution supplémentaire en vaut la peine.

Voici une comparaison des chaînes de connexion ODBC pour Microsoft Access avec les modifications de SQL Server entre la version précédente et la version actuelle :

ODBC 17 contre ODBC 18

17 :DRIVER=ODBC Driver 17 for SQL Server;SERVER= ;DATABASE= ; Crypter=oui ;
18 :DRIVER=ODBC Driver 18 for SQL Server;SERVER= ;DATABASE= ;

Chaînes de connexion OLEDB 18 et OLEDB 19 pour Microsoft Access avec SQL Server

18 :Provider= MSOLEDBSQL ;Data Source= ;Initial Catalog= ; Crypter=oui ;
19 :Provider= MSOLEDBSQL19 ;Data Source= ;Initial Catalog=

Notez que dans les versions précédentes, vous deviez spécifier le Encrypt=yes mais cela est désormais implicite dans les versions actuelles.

Ok, mais j'ai un serveur sur site mais il ne fonctionne pas avec les nouveaux pilotes ?

En raison de la modification du paramètre, vous pouvez maintenant voir cette erreur :

Selon le scénario et les exigences, voici les solutions possibles :

• Installer et configurer un certificat de confiance sur le serveur.
• Modifier la chaîne de connexion de l'application pour inclure TrustServerCertificate=Yes . UTILISER AVEC PRUDENCE
• Modifier la chaîne de connexion de l'application pour inclure Encrypt=No et désactivez Force Encryption sur le serveur. NON RECOMMANDÉ
• Ne mettez pas à jour les pilotes.

Les étapes pour résoudre le problème sont détaillées dans les sections correspondantes.

Résolutions

Installer et configurer un certificat de confiance sur le serveur

Il est très important de noter que ce n'est pas parce que vous avez un serveur qui a un certificat SSL valide configuré et en cours d'utilisation que le serveur SQL utilise le même certificat. De plus, il s'avère que le gestionnaire de configuration SQL Server est horrible à gérer les certificats. Vous constaterez peut-être qu'il ne répertorie aucun certificat à utiliser :

La version courte est que SQL Server Configuration Manager est excessivement restrictif sur les certificats qu'il répertorie, ce qui peut être assez frustrant, en particulier parce qu'il s'agit d'un problème d'interface utilisateur, et non d'une véritable exigence de SQL Server lui-même. Heureusement, nous pouvons contourner cette limitation stupide de l'interface utilisateur en modifiant directement le registre. Cela correspond à la clé de registre :

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

Dans cette clé, il y a une valeur Certificate qui attend une empreinte du certificat.

Vous pouvez coller manuellement l'empreinte du certificat SSL à utiliser, mais je vous recommande d'utiliser un script pour ce faire, car nous devons également nous assurer que le compte du serveur a l'autorisation d'accéder au certificat. J'ai utilisé cet article de blog comme guide pour configurer le script PowerShell afin de sélectionner le certificat, de le charger dans la clé de registre de SQL Server et de redémarrer le service. En fonction de la personne qui fournit votre certificat SSL et du flux de travail, vous souhaiterez peut-être l'intégrer à d'autres tâches planifiées afin que, lors du renouvellement du certificat SSL, la clé de registre et les autorisations soient mises à jour en conséquence.

Si tout est configuré correctement, votre serveur devrait pouvoir utiliser les nouveaux pilotes sans aucune modification de la chaîne de connexion de l'application. Comme vérification supplémentaire, vous pouvez consulter le journal des erreurs de votre serveur SQL et rechercher une ligne comme celle-ci :

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

Si l'empreinte correspond à celle que vous souhaitez utiliser, vous savez qu'elle est correctement chargée et la chaîne de confiance est désormais établie.

Modifiez la chaîne de connexion de l'application pour inclure TrustServerCertificate=Yes

Cependant, si votre serveur n'est pas face à Internet et qu'il est trop pénible de configurer un certificat SSL, il peut être acceptable d'activer TrustServerCertificate . Cela nécessite une modification de la chaîne de connexion de votre application. Cela permet à l'application d'autoriser la connexion à un serveur sans vérifier le certificat du serveur. Si vous êtes en mesure de contrôler votre application en toute confiance afin qu'elle ne sorte pas de votre réseau, cela devrait être OK. Gardez à l'esprit que si quelqu'un est capable d'usurper le nom ou l'adresse IP du serveur au sein du réseau, les applications clientes se connecteront aveuglément à cet ordinateur. Pour cette raison, nous ne pouvons pas le recommander si Internet est impliqué dans la connexion. Nous préférons vraiment ne pas prendre de risque.

Modifier la chaîne de connexion de l'application pour inclure Encrypt=No et désactivez Force Encryption sur le serveur.

C'est pour ceux qui aiment faire des stries sur Internet avec une enseigne au néon géante "VOLEZ MES DONNÉES ! RETIREZ-MOI MAINTENANT !" à tous les mauvais acteurs là-bas. C'est euh, une "option". La seule chose que je peux dire à propos de cette option, c'est qu'elle est extrêmement mauvaise. Tellement mauvais que j'ai oublié comment faire. Tu es tout seul, mon pote.

Ne mettez pas à jour les pilotes.

Une alternative légèrement meilleure par rapport à la précédente consiste simplement à ne pas mettre à jour et à s'en tenir aux pilotes ODBC 17 et OLEDB 18. Cependant, il s'agit au mieux d'une mesure palliative. Cette résolution ne nécessite aucune modification de l'application, mais cela ne fait que retarder au mieux les changements inévitables. Vous pouvez profiter du temps pour explorer les chemins qui vous mèneront à la dernière version et protéger vos données correctement.

J'espère que ça aide !