Excel vers un SQL Server partenaire sans approbation de domaine

Un classeur Excel qui ouvre une table sur le SQL Server d’une autre organisation a besoin de trois choses souvent traitées comme une seule : une identité que le serveur accepte, un transport que le client valide et un chemin réseau que les deux côtés autorisent. L’approbation de domaine est une façon de satisfaire la première, et la plus large. TLS satisfait la seconde et ne dit rien de la première. Le chemin satisfait la troisième et ne protège rien en lui-même.

Séparer les trois transforme la feuille de calcul en une petite demande vérifiable plutôt qu’en une relation administrative.

Trois décisions que la question cache

L’identité, c’est ce que la base de données croit que vous êtes : un compte Windows d’un domaine approuvé, une connexion SQL avec son propre mot de passe ou une identité fondée sur un certificat. Le transport, c’est si la session est chiffrée et si le client vérifie la chaîne de certificats du serveur. Le chemin, c’est comment les paquets atteignent l’écouteur, qui peut être un VPN, une liaison privée ou un point de terminaison public avec des règles de pare-feu. Chacun vit à un endroit différent et chacun peut échouer seul.

Une approbation de forêt répond largement à la première et constitue une relation entre organisations plutôt qu’un réglage pour un classeur. Elle ne chiffre rien non plus, ce qui surprend ceux qui pensaient que l’approbation était le contrôle de sécurité.

Identité sans approbation de forêt

Un compte provisionné exprès dans l’environnement cible peut répondre à une exigence plus étroite sans aucune approbation, à condition que le flux de travail du client puisse l’utiliser. L’authentification SQL est l’autre réponse courante lorsque la politique le permet : la connexion porte son propre cycle de vie d’identifiants et ne rejoint pas de domaines ni ne produit d’authentification Windows intégrée. L’identité fondée sur un certificat ou un jeton est une troisième option sur les plateformes plus récentes. Quel que soit votre choix, n’accordez que les autorisations de base de données dont le classeur a réellement besoin.

Préférez un compte dédié à la connexion personnelle de quelqu’un. Un identifiant partagé dans une feuille de calcul est un problème de support qui attend de survenir, et un compte nommé rend la révocation possible à la fin du projet.

Chiffrer oui, mais faire confiance au certificat ?

Avec ODBC Driver 18, Encrypt=Yes;TrustServerCertificate=No demande une session chiffrée dont le certificat est réellement vérifié. La chaîne de connexion doit alors nommer le serveur que couvre le certificat, et le client doit faire confiance à sa chaîne. Driver 18 chiffre aussi par défaut, contrairement aux versions précédentes, si bien qu’une ancienne chaîne de connexion peut désormais négocier TLS sans le dire. Des réglages explicites rendent la politique voulue visible sur toutes les machines, ce qui compte lorsque plusieurs personnes maintiennent le même classeur.

TrustServerCertificate=Yes chiffre et ignore la validation, ce qui n’est pas une réparation équivalente pour une inadéquation de nom ou une chaîne non approuvée. Cela supprime le signal qui vous aurait dit que le client avait atteint le mauvais point de terminaison, alors corrigez le certificat ou le nom.

L’application côté serveur est un contrôle distinct. Si le chiffrement doit s’appliquer à chaque client, configurez et vérifiez le réglage de chiffrement forcé du serveur, car une chaîne de connexion coopérative n’impose rien.

Le chemin réseau n’est pas la protection

Un écouteur privé atteint par un VPN réduit l’exposition, et le VPN doit acheminer les bonnes routes de destination et de retour pour que cela fonctionne. Un tunnel qui fonctionne ne supprime pas le besoin d’authentification ni la validation du certificat, et TLS ne limite pas quels systèmes distants peuvent tenter une connexion. Ce sont trois observations distinctes : une poignée de main TLS, une connexion VPN et une requête autorisée. Seule la troisième prouve que le classeur a lu les données qu’il était autorisé à lire.

Résistez donc au raccourci consistant à répondre à une question d’approbation en exposant la base de données à internet. La réponse étroite est généralement un compte dédié, un chiffrement validé et un chemin approuvé, dans cet ordre.

Vérifiez avec le flux de travail Excel habituel : l’identité acceptée, les autorisations effectives et le chiffrement négocié, chacun contrôlé via la vue de session du serveur lui-même.