Nuovi driver per SQL Server... Cosa devi sapere

Di recente, Microsoft ha rilasciato due nuovi driver per SQL Server, un importante aggiornamento:

Driver ODBC 18 per SQL Server
Driver OLEDB 19 per SQL Server

Questa è una fantastica notizia! Tuttavia, c'è un cambiamento importante che richiede la tua attenzione. In particolare, hanno cambiato il funzionamento delle impostazioni predefinite per la crittografia. In tutte le versioni precedenti dei driver, l'impostazione predefinita non richiedeva la crittografia. Avevamo la possibilità di forzare la crittografia dal lato server o richiederla all'interno della stringa di connessione sul lato client. Ovviamente, per l'amministratore del server, di solito era più desiderabile forzare la crittografia dal server, in modo che non importasse se qualche vecchia applicazione non la richiedeva ma sarebbe garantito crittografare la sua comunicazione con il server.

Ci sono 2 parole chiave della stringa di connessione e un'impostazione del server che influenza il comportamento del driver:

All'interno della stringa di connessione dal lato client:

• Encrypt :indica se la comunicazione deve essere crittografata.
• TrustServerCertificate :indica se il client deve semplicemente considerare attendibile il certificato del server senza verificare l'autenticità del certificato.

All'interno delle impostazioni dal lato server:

• Force Encryption :impone a qualsiasi client che si connette al server di crittografare la comunicazione indipendentemente dalla stringa di connessione del client.

La combinazione delle 3 proprietà influenza il modo in cui verrà effettuata la connessione. C'è un comodo grafico che li enumera, che può essere trovato qui..

Tuttavia, lo scenario più comune è che si forza la crittografia dal server e non si specifica nient'altro nella stringa di connessione. Ecco la versione estratta di entrambe le versioni precedenti e il comportamento della nuova versione:

Penso che questa sia generalmente una buona cosa, soprattutto con i database SQL di Azure che stanno diventando più comuni, ma la modifica del controllo del certificato di SQL Server introduce una modifica, soprattutto per i server che potrebbero non avere certificati impostati. Per impostazione predefinita, utilizzerà un certificato autofirmato, che non è sicuro come uno affidabile. Per quei server in cui le connessioni vengono effettuate su Internet, la precauzione aggiuntiva vale lo sforzo.

Ecco un confronto delle stringhe di connessione ODBC per Microsoft Access con modifiche di SQL Server tra la versione precedente e la versione attuale:

ODBC 17 contro ODBC 18

17:DRIVER=ODBC Driver 17 for SQL Server;SERVER= ;DATABASE= ; Crittografa=sì;
18:DRIVER=ODBC Driver 18 for SQL Server;SERVER= ;DATABASE= ;

Stringhe di connessione OLEDB 18 e OLEDB 19 per Microsoft Access con SQL Server

18:Provider= MSOLEDBSQL ;Data Source= ;Initial Catalog= ; Crittografa=sì;
19:Provider= MSOLEDBSQL19 ;Data Source= ;Initial Catalog=

Nota che nelle versioni precedenti dovevi specificare Encrypt=yes ma questo è ora implicito nelle versioni correnti.

Ok, ma ho un server locale ma non funziona con i nuovi driver?

A causa della modifica dell'impostazione, ora potresti visualizzare questo errore:

A seconda dello scenario e delle esigenze, ecco le possibili risoluzioni:

• Installa e configura un certificato affidabile sul server.
• Modifica la stringa di connessione dell'applicazione per includere TrustServerCertificate=Yes . UTILIZZARE CON ATTENZIONE
• Modifica la stringa di connessione dell'applicazione per includere Encrypt=No e disabilita Force Encryption sul server. NON CONSIGLIATO
• Non aggiornare i driver.

I passaggi per risolvere il problema sono descritti in dettaglio nelle sezioni corrispondenti.

Risoluzioni

Installa e configura un certificato affidabile sul server

È molto importante notare che solo perché si dispone di un server con un certificato SSL valido configurato e in uso attivo non significa in realtà che SQL Server stia utilizzando lo stesso certificato. Inoltre, risulta che SQL Server Configuration Manager è orribile nella gestione dei certificati. Potresti scoprire che non elencherà alcun certificato da utilizzare:

La versione breve è che SQL Server Configuration Manager è eccessivamente restrittivo sui certificati che elencherà, il che può essere piuttosto frustrante soprattutto perché si tratta di un problema dell'interfaccia utente, non un vero requisito di SQL Server stesso. Fortunatamente, possiamo aggirare questa stupida limitazione dell'interfaccia utente modificando direttamente il registro. Corrisponde alla chiave di registro:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<name of your instance>\MSSQLServer\SuperSocketNetLib

All'interno di quella chiave, c'è un valore Certificate che prevede un'identificazione personale del certificato.

Puoi incollare manualmente l'identificazione personale del certificato SSL da utilizzare, ma consiglierei di utilizzare uno script per farlo poiché dobbiamo anche assicurarci che l'account del server abbia l'autorizzazione per accedere al certificato. Ho usato questo articolo del blog come guida per configurare lo script di PowerShell per selezionare il certificato e caricarlo nella chiave di registro di SQL Server e riavviare il servizio. A seconda di chi fornisce il tuo certificato SSL e del flusso di lavoro, potresti voler integrarlo in altre attività pianificate in modo che quando il certificato SSL viene rinnovato, la chiave di registro e le autorizzazioni verranno aggiornate di conseguenza.

Se tutto è impostato correttamente, il tuo server dovrebbe essere in grado di utilizzare i nuovi driver senza alcuna modifica alla stringa di connessione dell'applicazione. Come ulteriore verifica, puoi controllare il registro degli errori del tuo SQL Server e cercare una riga come questa:

<timestamp> spid11s The certificate [Cert Hash(sha1) "<certificate thumbprint>"] was successfully loaded for encryption.

Se l'identificazione personale corrisponde a quella che desideri utilizzare, allora sai che l'hai caricata correttamente e quindi la catena di fiducia è ora stabilita.

Modifica la stringa di connessione dell'applicazione per includere TrustServerCertificate=Yes

Tuttavia, se il tuo server non è connesso a Internet ed è troppo doloroso impostare un certificato SSL, potrebbe essere accettabile attivare TrustServerCertificate . Ciò richiede una modifica nella stringa di connessione dell'applicazione. Ciò consente all'applicazione di consentire la connessione a un server senza verificare il certificato del server. Se sei in grado di controllare con sicurezza la tua applicazione in modo che non vada al di fuori della tua rete, questo dovrebbe essere OK. Tieni presente che se qualcuno è in grado di falsificare il nome o l'IP del server all'interno della rete, le applicazioni client si connetteranno ciecamente a quel computer. Per questo motivo, non possiamo consigliarlo se è presente Internet nella connessione. Preferiremmo davvero non correre il rischio.

Modifica la stringa di connessione dell'applicazione per includere Encrypt=No e disabilita Force Encryption sul server.

Questo è per coloro a cui piace strisciare su Internet con un'insegna al neon gigante "RUBA I MIEI DATI! DIROTTAMI ORA!” a tutti i cattivi attori là fuori. Questa è ehm, una "opzione". L'unica cosa che posso dire su questa opzione è che è estremamente negativa. Così male, che ho dimenticato come farlo. Sei da solo, amico.

Non aggiornare i driver.

Un'alternativa leggermente migliore rispetto alla precedente è semplicemente non aggiornare e attenersi ai driver ODBC 17 e OLEDB 18. Tuttavia, questa è nella migliore delle ipotesi una misura provvisoria. Questa risoluzione non richiede modifiche all'applicazione, ma ciò ritarda solo le inevitabili modifiche nella migliore delle ipotesi. Puoi sfruttare il tempo per esplorare percorsi che ti porteranno all'ultima versione e proteggeranno i tuoi dati in modo appropriato.

Spero di esserti stato d'aiuto!