TDS 8.0
Si applica a: SQL Server 2022 (16.x) Database Azure SQL Istanza gestita di SQL di Azure
SQL Server 2022 (16.x), Database SQL di Azure e Istanza gestita di SQL di Azure supportano TDS (Tabular Data Stream) 8.0.
Il protocollo TDS (Tabular Data Stream) è un protocollo del livello applicazione usato dai client per connettersi a SQL Server. SQL Server usa Transport Layer Security (TLS) per crittografare i dati trasmessi attraverso una rete tra un'istanza di SQL Server e un'applicazione client.
TDS è un protocollo sicuro, ma nelle versioni precedenti di SQL Server la crittografia potrebbe essere disattivata o non abilitata. Per soddisfare gli standard di crittografia obbligatoria durante l'uso di SQL Server, è stata introdotta un'iterazione del protocollo TDS: TDS 8.0.
L'handshake TLS ora precede tutti i messaggi TDS, eseguendo il wrapping della sessione TDS in TLS per applicare la crittografia, rendendo TDS 8.0 allineato con HTTPS e altri protocolli Web. Ciò contribuisce in modo significativo alla gestibilità del traffico TDS, in quanto le appliance di rete standard ora possono filtrare e passare in modo sicuro le query SQL.
Un altro vantaggio di TDS 8.0 rispetto alle versioni precedenti di TDS è la compatibilità con TLS 1.3 e gli standard TLS futuri. TDS 8.0 è anche completamente compatibile con TLS 1.2 e versioni precedenti di TLS.
Come funziona TDS
Il protocollo Tabular Data Stream (TDS) è un protocollo a livello di applicazione usato per il trasferimento di richieste e risposte tra client e sistemi server di database. In questi sistemi, il client generalmente stabilisce una connessione di lunga durata con il server. Dopo aver stabilito la connessione usando un protocollo a livello di trasporto, per la comunicazione tra il client e il server vengono usati messaggi TDS.
Per tutta la durata della sessione TDS, esistono tre fasi:
- Inizializzazione
- Autenticazione
- Scambio di dati
La crittografia viene negoziata durante la fase iniziale, ma la negoziazione TDS avviene su una connessione non crittografata. La connessione di SQL Server è simile alla seguente per le versioni precedenti a TDS 8.0:
Handshake TCP ➡️ Pre-accesso TDS (testo non crittografato) e risposta (testo non crittografato) ➡️ Handshake TLS ➡️ Autenticazione (crittografata) ➡️ Scambio dati (può essere crittografato o non crittografato)
Con l'introduzione di TDS 8.0, le connessioni di SQL Server avvengono come indicato di seguito:
Handshake TCP ➡️ Handshake TLS ➡️ Pre-accesso TDS (crittografato) e risposta (crittografata) ➡️ Autenticazione (crittografata) ➡️ Scambio di dati (crittografato)
Crittografia della connessione rigorosa
Per usare TDS 8.0, SQL Server 2022 (16.x) ha aggiunto strict
come tipo di crittografia di connessione supplementare ai driver di SQL Server (Encrypt=strict
). Per usare il tipo di crittografia della connessione strict
, scaricare la versione più recente dei driver .NET, ODBC, OLE DB, JDBC, PHP e Python.
- Microsoft ADO.NET per SQL Server e il Database SQL di Azure versione 5.1 o successive
- Driver ODBC per SQL Server versione 18.1.2.1 o successive
- OLE DB Driver per SQL Server versione 19.2.0 o successive
- Driver JDBC di Microsoft per SQL Server versione 11.2.0 o successive
- Driver di Microsoft per PHP per SQL Server versione 5.10 o successive
- Driver SQL per Python - pyodbc
Per evitare un attacco man-in-the-middle con crittografia della connessione strict
, gli utenti non sono in grado di impostare l'opzione TrustServerCertificate
su true
e considerare attendibile qualunque certificato fornito dal server. Gli utenti, invece, usano l'opzione HostNameInCertificate
per specificare il certificato ServerName
che deve essere considerato attendibile. Il certificato fornito dal server deve superare la convalida del certificato.
Funzionalità che non supportano l'uso forzato della crittografia strict
L'opzione Force Strict Encryption
aggiunta con TDS 8.0 nella configurazione della rete di SQL Server impone a tutti i client l'uso di strict
come tipo di crittografia. I client o le funzionalità senza la crittografia della connessione strict
non riescono a connettersi a SQL Server.
Le seguenti funzionalità o strumenti usano ancora la versione precedente dei driver che non supportano TDS 8.0 e, di conseguenza, potrebbero non funzionare con la crittografia della connessione strict
:
- Gruppi di disponibilità AlwaysOn
- Istanza del cluster di failover Always On (FCI)
- Replica SQL Server
- Log shipping
- Utilità sqlcmd
- utilità bcp
- Servizio CEIP di SQL Server
- SQL Server Agent
- Posta elettronica database
- Server collegati
- Connettore PolyBase a SQL Server
Modifiche aggiuntive alle proprietà di crittografia della stringa di connessione
Le aggiunte seguenti vengono aggiunte alle stringa di connessione per la crittografia:
Parola chiave | Default | Descrizione |
---|---|---|
Encrypt | false | Comportamento esistente Quando è true , SQL Server usa la crittografia TLS per tutti i dati inviati tra il client e il server se nel server è installato un certificato. I valori riconosciuti sono true , false , yes e no . Per altre informazioni, vedere Sintassi della stringa di connessione.Modifica del comportamento Quando è impostato strict , SQL Server usa TDS 8.0 per tutti i dati inviati tra il client e il server.Quando è impostato su mandatory , true o yes , SQL Server usa TDS 7.x con crittografia TLS/SSL per tutti i dati inviati tra il client e il server se nel server è installato un certificato.Quando è impostato su optional , false o no , la connessione usa TDS 7.x e viene crittografata solo se richiesto da SQL Server. |
TrustServerCertificate | false | Comportamento esistente Impostare su true per specificare che il driver non convalida il certificato TLS/SSL del server. Se true , il certificato TLS/SSL del server viene considerato automaticamente attendibile quando il livello di comunicazione è crittografato con TLS.Se false , il driver convalida il certificato TLS/SSL del server. Se la convalida del certificato del server ha esito negativo, il driver genera un errore e chiude la connessione. Il valore predefinito è false . Perché una connessione TLS/SSL riesca, accertarsi che il valore passato a serverName corrisponda esattamente al Common Name (CN) o al nome DNS nel Subject Alternate Name nel certificato del server.Modifica del comportamento per il driver ODBC di Microsoft 18 per SQL Server Se Encrypt è impostato su strict , questa impostazione specifica la posizione del certificato da usare per la convalida del certificato server (corrispondenza esatta). Il driver supporta le estensioni file PEM, DER e CER.Se Encrypt è impostato su true o false e la proprietà TrustServerCertificate non è specificata o è impostata su null , true o false , il driver usa il valore della proprietà ServerName nell’URL della connessione come nome host per convalidare il certificato TLS/SSL di SQL Server. |
HostNameInCertificate | Null | Nome host da usare per la convalida del certificato TLS/SSL di SQL Server. Se la prioprietà HostNameInCertificate non è specificata o è impostata su null , il driver usa il valore della proprietà ServerName come home host per convalidare il certificato TLS/SSL di SQL Server. |