Chaînes de connexion pour Microsoft.Data.SqlClient

Une Microsoft. Data.SqlClient chaîne de connexion indique au pilote quel point de terminaison et base de données compatibles SQL Server utiliser, comment s’authentifier et comment configurer la connexion. Passe-le à SqlConnection ou SqlConnectionStringBuilder.

Commencez par quatre décisions :

  1. Quel serveur et quelle base de données l’application utilise-t-elle ?
  2. Sous quelle identité l’application s’exécute-t-elle ?
  3. Comment le client valide-t-il le certificat serveur ?
  4. De quel comportement de connexion la charge de travail a-t-elle besoin ?

Gardez les identifiants et les jetons d’accès hors de la chaîne de connexion lorsque la méthode d’authentification choisie prend en charge cette conception.

Choisir un motif d’authentification

Utilisez le motif le plus étroit qui correspond au déploiement.

Environnement Motif préféré Chaîne de connexion Core
SQL Server sur Windows sous une identité de domaine ou une identité Windows locale Authentification intégrée Windows Server=<server>;Database=<database>;Integrated Security=true;Encrypt=true
Station de travail développeur se connectant à une base de données SQL dans Microsoft Fabric Chaîne d’identifiants par défaut Microsoft Entra ID Server=tcp:<server>,1433;Database=<database>;Authentication=Active Directory Default;Encrypt=Strict
Application hébergée dans Azure et connectée à Azure SQL identité managée Microsoft Entra ID Server=tcp:<server>.database.windows.net,1433;Database=<database>;Authentication=Active Directory Managed Identity;Encrypt=Strict
Developer workstation se connectant à Azure SQL Chaîne d’identifiants par défaut Microsoft Entra ID Server=tcp:<server>.database.windows.net,1433;Database=<database>;Authentication=Active Directory Default;Encrypt=Strict
Outil de bureau interactif se connectant à Azure SQL Authentification interactive de Microsoft Entra ID Server=tcp:<server>.database.windows.net,1433;Database=<database>;Authentication=Active Directory Interactive;Encrypt=Strict
Environnement nécessitant une authentification SQL Nom d’utilisateur et mot de passe depuis un magasin secret Server=<server>;Database=<database>;User ID=<user_id>;Password=<password>;Encrypt=true

Microsoft.Data.SqlClient 7.0 et les versions ultérieures nécessitent le package Microsoft.Data.SqlClient.Extensions.Azure correspondant à la version pour les modes d’authentification Microsoft Entra ID pris en charge par le pilote. Vous n’avez pas besoin de cette extension lorsque le code applicatif fournit un jeton d’accès ou un rappel de jeton d’accès.

L’authentification nécessite également des utilisateurs côté base de données, des permissions et une configuration d’identité. Pour la matrice de choix complète et la configuration, voir authentification Microsoft Entra ID et authentification SQL Server.

Spécifier le serveur et la base de données

Utilisez Server et Database comme noms de mots-clés canoniques. Le pilote accepte également des alias tels que Data Source pour Server et Initial Catalog pour Database.

Les formes de serveur courantes incluent :

Server=server-name
Server=server-name\instance-name
Server=tcp:server-name,1433
Server=(localdb)\MSSQLLocalDB

Je préfère un protocole explicite, un nom d’hôte et un port pour les connexions TCP de production. Utilisez un nom DNS stable qui correspond au certificat serveur au lieu d’une adresse IP.

Pour un listener de groupe de disponibilité, un groupe de basculement, un point de terminaison Azure SQL ou tout autre point de terminaison TCP à adresses multiples, consultez également MultiSubnetFailover dans les options de connexion.

Configurer le chiffrement et la validation des certificats

Microsoft.Data.SqlClient 4.0 et versions ultérieures utilisent Encrypt par défaut.true Microsoft.Data.SqlClient, à partir de la version 5.0, prend également en charge Encrypt=Strict pour les serveurs qui négocient TDS 8.0.

Utilisez :

  • Encrypt=Strict lorsque le serveur supporte TDS 8.0 et possède un certificat que le client peut valider.
  • Encrypt=true pour les connexions chiffrées vers d’autres serveurs pris en charge.
  • TrustServerCertificate=false, par défaut, pour la validation des certificats de production.

Ne l’utilisez TrustServerCertificate=true pas comme solution générale de connexion. Il chiffre le canal mais saute la validation de l’identité du serveur. Limitez-le aux environnements de développement contrôlés où aucun certificat de confiance n’est disponible.

Pour les exigences du serveur, le comportement des versions et les options de certificat, voir Chiffrement et validation des certificats.

Comprendre la syntaxe des chaîne de connexion

Une chaîne de connexion est une liste délimitée par un point-virgule de paires mots-clés et valeurs :

Server=tcp:sql.example.com,1433;Database=Orders;Integrated Security=true;Encrypt=true

Suivez ces règles :

  • Les noms de mots-clés ne sont pas sensibles à la majuscule.
  • Les valeurs peuvent être sensibles à la casse.
  • Un point-virgule final est optionnel.
  • Mettez une valeur entre guillemets simples ou doubles lorsqu’elle contient un point-virgule ou des espaces au début ou à la fin.
  • Pour échapper au guillemet qui encadre une valeur, doublez-le.
  • N’utilisez pas de mots-clés en double. L’analyseur utilise la dernière valeur, ce qui rend la configuration effective difficile à consulter.

L’ensemble des mots-clés et alias acceptés appartient au prestataire. Une chaîne de connexion acceptée par Microsoft.Data.SqlClient pourrait ne pas fonctionner avec System.Data.SqlClient ou un autre fournisseur de données.

Construire des chaînes de connexion en toute sécurité

À utiliser SqlConnectionStringBuilder lorsque le code doit ajouter, valider ou remplacer des valeurs. Ne concaténez pas des valeurs non fiables dans une chaîne de connexion.

string baseConnectionString =
    configuration.GetConnectionString("Orders")
    ?? throw new InvalidOperationException(
        "Connection string 'Orders' wasn't configured.");

var builder = new SqlConnectionStringBuilder(baseConnectionString)
{
    ApplicationName = "Orders.Api",
    ConnectTimeout = 30,
};

string connectionString = builder.ConnectionString;

Le constructeur :

  • Rejette les mots-clés non pris en charge et les valeurs invalides.
  • Associe les alias aux propriétés canoniques.
  • Citez les valeurs lorsque cela est nécessaire.
  • Empêche une valeur d’injecter un autre mot-clé.

Le constructeur ne protège pas de mot de passe ou de jeton après qu’il soit entré en mémoire de processus. Il ne décide pas non plus si un réglage serveur, une identité ou un certificat est sûr.

Stocker les informations de connexion en dehors du code

Charge des chaînes de connexion provenant du système de configuration utilisé par l’application. Les applications .NET actuelles utilisent couramment des variables d’environnement, des secrets utilisateur pour le développement local, Azure App Configuration et une configuration soutenue par Azure Key Vault.

Respectez ces règles :

  • N’ajoutez pas de mots de passe, de secrets client, de jetons d’accès ou de chaînes de connexion de production au dépôt.
  • Je préfère une méthode d'authentification basée sur l'identité qui ne nécessite pas de mot de passe dans la chaîne de connexion.
  • Restreignez l’accès à la source de configuration.
  • Faites pivoter les secrets stockés et redémarrez ou rafraîchissez les applications qui les mettent en cache.
  • N’écrivez pas de chaînes de connexion dans les logs, exceptions, traces ou télémétrie.
  • Leave Persist Security Info=false, la valeur par défaut, afin qu'une connexion ouverte n'expose pas les valeurs sensibles à la sécurité via sa chaîne de connexion.

Pour les fournisseurs de configuration .NET, voir Configuration en .NET. Pour des contrôles supplémentaires, voir Protéger les informations de connexion.

Gardez les clés du pool stables

Le pool de connexions utilise une configuration de connexion précise comme élément de sa clé de pool. Des chaînes équivalentes peuvent créer des pools séparés lorsque leur texte diffère, y compris lorsque des mots-clés apparaissent dans un ordre différent.

Construis une chaîne de connexion canonique au démarrage de l’application et réutilise-la. N’ajoutez pas d’identifiants de requête, noms d’utilisateur, jetons d’accès ou autres valeurs par requête à la chaîne. Pour connaître les règles clés complètes, consultez le pool de connexions SQL Server.

Paramètres de connexion et de commande séparés

Une chaîne de connexion contrôle l’établissement de la connexion et le comportement de la session. Une commande contrôle une opération SQL.

Requirement Configurer sur
Temps accordé pour établir une connexion ou en obtenir une dans le pool Connect Timeout Option de connexion
Délai d’exécution par défaut de la commande Command Timeout option de connexion, si elle est prise en charge par la version du pilote
Délai d’expiration d’une commande CommandTimeout
Annulation par l’appelant CancellationToken transmis aux API asynchrones
Politique de réessai pour ouvrir une connexion ou exécuter une commande Logique de réessai configurable sur SqlConnection ou SqlCommand

Ne considérez pas un temps mort plus long comme une logique de réessayage. Un délai limite une attente. Un réessai lance une nouvelle tentative et doit être limité et pouvoir être répété sans risque.

Vérifier le comportement en fonction de la version

Version du pilote Changement de chaîne de connexion
4,0 Encrypt a la valeur par défaut true.
5.0 Encrypt=Strict et HostNameInCertificate sont disponibles. SqlConnectionStringBuilder.Encrypt utilise SqlConnectionEncryptOption.
5,1 ServerCertificate peut comparer le certificat serveur à un fichier.
5.2 AccessTokenCallback est disponible pour les jetons fournis par des applications renouvelables.
7.0 L’authentification Microsoft Entra ID fournie par le pilote est déplacée vers Microsoft.Data.SqlClient.Extensions.Azure.
7.0.2 Le pilote principal et ses packages associés utilisent des versions alignées.

Utilisez une version stable prise en charge et lisez les notes de version avant une mise à jour. Pour les versions actuelles, voir cycle de vie du support des pilotes SqlClient.