Stringhe di connessione per Microsoft. Data.SqlClient

Una stringa di connessione Microsoft.Data.SqlClient indica al driver quale endpoint compatibile con SQL Server e quale database utilizzare, come autenticarsi e come configurare la connessione. Passalo a SqlConnection oppure SqlConnectionStringBuilder.

Inizia con quattro decisioni:

1. Quale server e database utilizza l'applicazione?
2. Quale identità usa l'applicazione?
3. Come fa il client a convalidare il certificato server?
4. Quale comportamento di connessione richiede il carico di lavoro?

Tieni le credenziali e i token di accesso fuori dalla stringa di connessione quando il metodo di autenticazione scelto supporta tale design.

Scegli un modello di autenticazione

Usa il modello più stretto che si adatti al dispiegamento.

Microsoft.Data.SqlClient 7.0 e versioni successive richiedono il pacchetto Microsoft.Data.SqlClient.Extensions.Azure corrispondente alla versione per le modalità di autenticazione Microsoft Entra ID fornite dal driver. Non serve quella estensione quando il codice applicativo fornisce un token di accesso o un callback del token di accesso.

L'autenticazione richiede anche utenti lato database, permessi e configurazione dell'identità. Per la matrice completa delle scelte e la configurazione, vedi Microsoft Entra ID autenticazione e SQL Server autenticazione.

Specifica il server e il database

Usa Server e Database come nomi chiave canonici. Il driver accetta anche alias come Data Source per Server e Initial Catalog per Database.

I moduli comuni dei server includono:

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

Preferisci un protocollo esplicito, nome host e porta per le connessioni TCP di produzione. Usa un nome DNS stabile che corrisponda al certificato del server invece di un indirizzo IP.

Per un listener di un gruppo di disponibilità, un gruppo di failover, un endpoint Azure SQL o un altro endpoint TCP con più indirizzi, consulta anche MultiSubnetFailover in Connection options.

Configurare crittografia e validazione dei certificati

Microsoft. Data.SqlClient 4.0 e versioni successive sono predefinite Encrypt su true. Microsoft.Data.SqlClient 5.0 e le versioni successive supportano anche Encrypt=Strict per i server che negoziano TDS 8.0.

Utilizzo:

• Encrypt=Strict quando il server supporta TDS 8.0 e possiede un certificato, il client può validarlo.
• Encrypt=true per connessioni criptate ad altri server supportati.
• TrustServerCertificate=false, il predefinito, per la validazione dei certificati di produzione.

Non usare TrustServerCertificate=true come soluzione generica ai problemi di connessione. Cripta il canale ma salta la validazione dell'identità del server. Limitalo agli ambienti di sviluppo controllati dove non è disponibile un certificato affidabile.

Per i requisiti del server, il comportamento delle versioni e le opzioni di certificato, vedi Crittografia e validazione dei certificati.

Comprendere la sintassi della stringa di connessione

Una stringa di connessione è un elenco delimitato da punto e virgola di coppie di parole chiave e valori:

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

Segui queste regole:

• I nomi delle parole chiave non distinguono tra maiuscole e minuscole.
• I valori possono essere sensibili a maiuscole e minuscole.
• Un punto e virgola finale è opzionale.
• Cita un valore con virgolette singole o doppie quando contiene un punto e virgola o uno spazio bianco all'inizio o alla fine.
• Evita la citazione che racchiude un valore raddoppiandolo.
• Non usare parole chiave duplicate. Il parser utilizza l'ultimo valore, il che rende difficile esaminare la configurazione effettiva.

L'insieme di parole chiave e alias accettati appartiene al fornitore. Una stringa di connessione accettata da Microsoft.Data.SqlClient potrebbe non funzionare né con System.Data.SqlClient né con un altro fornitore di dati.

Costruire stringhe di connessione in sicurezza

Da usare SqlConnectionStringBuilder quando il codice deve aggiungere, validare o sostituire valori. Non concatenare valori non affidabili in una stringa di connessione.

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;

Il costruttore:

• Rifiuta parole chiave non supportate e valori non validi.
• Associa gli alias alle proprietà canoniche.
• Dichiara i valori quando necessario.
• Impedisce che un valore inietti un'altra parola chiave.

Il builder non protegge una password o un token dopo che entra nella memoria del processo. Non decide nemmeno se un server, un'identità o un'impostazione di certificato sia sicura.

Memorizza le informazioni di connessione al di fuori del codice

Carica le stringhe di connessione dal sistema di configurazione utilizzato dall'applicazione. Le applicazioni .NET attuali utilizzano comunemente variabili di ambiente, segreti utente per lo sviluppo locale, Configurazione app di Azure e configurazione supportata da Azure Key Vault.

Rispetta queste regole:

• Non eseguire il commit di password, segreti del client, token di accesso o stringhe di connessione dell'ambiente di produzione.
• Preferisco un metodo di autenticazione basato sull'identità che non richieda una password nella stringa di connessione.
• Limita l'accesso alla sorgente di configurazione.
• Ruota i segreti memorizzati e riavvia o aggiorna le applicazioni che li memorizzano in cache.
• Non scrivere stringhe di connessione in log, eccezioni, tracce o telemetria.
• Lascia Persist Security Info=false, il valore predefinito, in modo che una connessione aperta non esponga valori sensibili attraverso la stringa di connessione.

Per i provider di configurazione .NET, vedi Configurazione in .NET. Per controlli aggiuntivi, vedi Proteggere le informazioni di connessione.

Mantieni stabili le chiavi del pool

Il pooling di connessioni utilizza una specifica configurazione di connessione come parte della propria chiave del pool. Stringhe equivalenti possono creare pool separati quando il loro testo differisce, anche quando le parole chiave appaiono in ordine diverso.

Costruisci una stringa di connessione canonica all'avvio dell'applicazione e riutilizzala. Non aggiungere ID richieste, nomi utente, token di accesso o altri valori per richiesta alla stringa. Per le regole complete delle chiavi, vedi SQL Server connection pooling.

Impostazioni di connessione e comandi separate

Una stringa di connessione controlla l'istituzione della connessione e il comportamento della sessione. Un comando controlla un'operazione SQL.

Non considerare un timeout più lungo come un meccanismo di ripetizione dei tentativi. Un timeout limita una singola attesa. Un ritentativo avvia un nuovo tentativo e deve essere limitato e ripetibile in sicurezza.

Rivedi il comportamento dipendente dalla versione

Usa una versione stabile supportata del driver e leggi le note di rilascio prima di un aggiornamento. Per le versioni attuali, vedi ciclo di vita del supporto driver SqlClient.

Contenuti correlati

• Usa Microsoft.Data.SqlClient in un'app .NET
• Opzioni di connessione.
• Connessione a un'origine dati
• Autenticazione Microsoft Entra ID
• Crittografia e convalida di certificati
• Informazioni di riferimento sulle API Microsoft.Data.SqlClient