Verbindungszeichenfolgen für Microsoft.Data.SqlClient

Eine Microsoft.Data.SqlClient-Verbindungszeichenfolge teilt dem Treiber mit, welcher SQL Server-kompatible Endpunkt und welche Datenbank verwendet werden sollen, wie die Authentifizierung erfolgt und wie die Verbindung konfiguriert werden soll. Geben Sie es an SqlConnection oder SqlConnectionStringBuilder weiter.

Beginnen Sie mit vier Entscheidungen:

1. Welchen Server und welche Datenbank verwendet die Anwendung?
2. Mit welcher Identität läuft die Anwendung?
3. Wie validiert der Client das Serverzertifikat?
4. Welches Verbindungsverhalten benötigt die Arbeitslast?

Halten Sie Zugangsdaten und Zugriffstoken aus der Verbindungszeichenfolge heraus, wenn die gewählte Authentifizierungsmethode dieses Design unterstützt.

Wählen Sie ein Authentifizierungsmuster

Verwenden Sie das engste Muster, das zur Verteilung passt.

Microsoft. Data.SqlClient 7.0 und neuere Versionen benötigen das versionsangepasste Microsoft.Data.SqlClient.Extensions.Azure Paket für treibergesteuerte Microsoft Entra ID-Authentifizierungsmodi. Du brauchst diese Erweiterung nicht, wenn der Anwendungscode ein Zugriffstoken oder eine Callbackfunktion für das Zugriffstoken bereitstellt.

Die Authentifizierung erfordert außerdem datenbankseitige Benutzer, Berechtigungen und Identitätskonfiguration. Für die vollständige Auswahlmatrix und Einrichtung siehe Microsoft Entra ID Authentication und SQL Server authentication.

Spezifizieren Sie Server und Datenbank

Verwenden Sie Server und Database als kanonische Schlüsselwortnamen. Der Fahrer akzeptiert außerdem Aliase wie Data Source für Server und Initial Catalog für Database.

Gängige Serverformen sind:

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

Bevorzuge ein explizites Protokoll, einen Hostnamen und einen Port für Produktions-TCP-Verbindungen. Verwenden Sie einen stabilen DNS-Namen, der mit dem Serverzertifikat übereinstimmt, anstatt einer IP-Adresse.

Für einen Verfügbarkeitsgruppen-Listener, eine Failover-Gruppe, einen Azure SQL-Endpunkt oder einen anderen TCP-Endpunkt mit mehreren Adressen prüfen Sie auch MultiSubnetFailover in den Verbindungsoptionen.

Verschlüsselung und Zertifikatsvalidierung konfigurieren

Microsoft.Data.SqlClient 4.0 und neuere Versionen verwenden standardmäßig Encrypt anstelle von true. Microsoft.Data.SqlClient 5.0 und höhere Versionen unterstützen ebenfalls Encrypt=Strict für Server, die TDS 8.0 aushandeln.

Verwendung:

• Encrypt=Strict wenn der Server TDS 8.0 unterstützt und ein Zertifikat besitzt, das der Client validieren kann.
• Encrypt=true für verschlüsselte Verbindungen zu anderen unterstützten Servern.
• TrustServerCertificate=false, der Standard für die Validierung von Produktionszertifikaten.

Verwenden Sie TrustServerCertificate=true nicht als allgemeine Lösung für Verbindungsprobleme. Er verschlüsselt den Kanal, überspringt aber die Validierung der Serveridentität. Beschränke sie auf kontrollierte Entwicklungsumgebungen, in denen kein vertrauenswürdiges Zertifikat verfügbar ist.

Für Serveranforderungen, Versionsverhalten und Zertifikatsoptionen siehe Verschlüsselung und Zertifikatsvalidierung.

Verstehen Sie die Verbindungszeichenfolge-Syntax

Eine Verbindungszeichenfolge ist eine mit Semikolon getrennte Liste von Schlüsselwort- und Wertpaaren:

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

Folgen Sie diesen Regeln:

• Schlüsselwortnamen sind nicht groß- und kleinschreibungssensitiv.
• Werte können groß- und kleinschreibungsabhängig sein.
• Ein finales Semikolon ist optional.
• Zitiere einen Wert mit einfachen oder doppelten Anführungszeichen, wenn er ein Semikolon oder einen einleitenden bzw. hinterlaufenden Weißraum enthält.
• Maskieren Sie das Anführungszeichen, das einen Wert einschließt, indem Sie es verdoppeln.
• Verwenden Sie keine doppelten Schlüsselwörter. Der Parser verwendet den letzten Wert, was die effektive Konfiguration schwer zu überprüfen macht.

Der Satz der akzeptierten Schlüsselwörter und Aliase gehört dem Anbieter. Eine von Microsoft.Data.SqlClient akzeptierte Verbindungszeichenfolge funktioniert möglicherweise nicht mit System.Data.SqlClient oder einem anderen Datenanbieter.

Verbindende Strings sicher aufbauen

Verwenden SqlConnectionStringBuilder Sie, wenn Code Werte hinzufügen, validieren oder ersetzen muss. Füge keine nicht vertrauenswürdigen Werte in eine Verbindungszeichenfolge ein.

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;

Der Erbauer:

• Lehnt nicht unterstützte Schlüsselwörter und ungültige Werte ab.
• Ordnet Aliase kanonischen Eigenschaften zu.
• Setzt Werte bei Bedarf in Anführungszeichen.
• Verhindert, dass ein Wert ein anderes Schlüsselwort injiziert.

Der Builder schützt kein Passwort oder Token, nachdem es in den Prozessspeicher eingedrungen ist. Es entscheidet auch nicht, ob eine Server-, Identitäts- oder Zertifikatseinstellung sicher ist.

Verbindungsinformationen außerhalb des Codes speichern

Laden Sie Verbindungsstrings aus dem von der Anwendung verwendeten Konfigurationssystem. Aktuelle .NET-Anwendungen verwenden häufig Umgebungsvariablen, Benutzergeheimnisse für lokale Entwicklung, Azure App Configuration und Azure Key Vault-gestützte Konfiguration.

Halten Sie sich an diese Regeln:

• Verbinde keine Passwörter, Client-Geheimnisse, Zugriffstoken oder Produktionsverbindungsstrings.
• Bevorzugen Sie eine identitätsbasierte Authentifizierungsmethode, die kein Passwort in der Verbindungszeichenfolge benötigt.
• Beschränke den Zugriff auf die Konfigurationsquelle.
• Rotiere gespeicherte Geheimnisse und starte neu oder erneuere Anwendungen, die sie cachen.
• Schreiben Sie keine Verbindungszeichenfolgen in Protokolle, Ausnahmen, Ablaufverfolgungen oder Telemetriedaten.
• Lassen Sie Persist Security Info=false auf dem Standardwert, sodass eine geöffnete Verbindung keine sicherheitsrelevanten Werte über ihre Verbindungszeichenfolge preisgibt.

Für .NET-Konfigurationsanbieter siehe Konfiguration in .NET. Für weitere Steuerungen siehe Verbindungsinformationen schützen.

Halte die Poolschlüssel stabil

Connection Pooling verwendet eine exakte Verbindungskonfiguration als Teil seines Pool-Schlüssels. Äquivalente Zeichenketten können separate Pools erstellen, wenn ihr Text unterschiedlich ist, auch wenn Schlüsselwörter in einer anderen Reihenfolge erscheinen.

Erstelle beim Start der Anwendung eine kanonische Verbindungszeichenfolge und verwende sie erneut. Füge dem String keine Anfrage-IDs, Benutzernamen, Zugriffstoken oder andere pro Anfrage Werte hinzu. Für die vollständigen Schlüsselregeln siehe SQL Server Connection Pooling.

Separate Verbindungs- und Befehlseinstellungen

Ein Verbindungszeichenfolge steuert die Verbindungseinrichtung und das Verhalten der Sitzungen. Ein Befehl steuert eine SQL-Operation.

Betrachte eine längere Auszeit nicht als Logik zum erneuten Versuch. Eine Auszeit begrenzt eine Wartezeit. Ein erneuter Versuch startet einen weiteren Versuch und muss begrenzt und sicher wiederholbar sein.

Versionssensitives Verhalten überprüfen

Verwende eine unterstützte stabile Treiberversion und lies die Release Notes vor einem Update. Für aktuelle Versionen siehe SqlClient-Treiber-Support-Lebenszyklus.

Verwandte Inhalte

• Verwenden Sie Microsoft. Data.SqlClient in einer .NET-App
• Verbindungsoptionen.
• Mit einer Datenquelle verbinden
• Microsoft Entra ID-Authentifizierung
• Verschlüsselung und Zertifikatüberprüfung
• Microsoft. Data.SqlClient API-Referenz