Crittografia in Microsoft SQL Server

Come altri fornitori DBMS, Microsoft utilizza il protocollo SSL per la protezione dei propri clienti. Tuttavia, pochi sono a conoscenza che, a differenza di altri DBMS, MsSQL incapsula il handshake SSL all’interno di TDS.

Questa soluzione potrebbe essere adottata deliberatamente al fine di ridurre il numero di minacce potenziali per i server MS, poiché oggi i fornitori utilizzano SSL in una combinazione di layer di protocollo semplice anziché una completa incapsulazione. È più facile e universale, in quanto l’attivazione/disattivazione di SSL non influisce sul protocollo principale.

La crittografia in MsSQL viene effettuata mediante due modalità: protezione della fase di autorizzazione e protezione completa della connessione. In entrambi i casi, il dialogo inizia con lo scambio di impostazioni tra client e server: il client invia il suo pacchetto PRELOGIN e riceve lo stesso pacchetto dal server. Successivamente, il client invia il primo pacchetto di handshake dopo averlo incapsulato in TDS come PRELOGIN. Tutti i pacchetti SSL successivi vengono incapsulati nello stesso modo in TDS fino al completamento del handshake.

Tuttavia, il primo e tutti i pacchetti SSL dell’applicazione successiva vengono inviati così come sono, senza essere incapsulati in TDS. Il pacchetto incapsula la query di autorizzazione LOGIN7. Qui inizia la differenziazione tra le modalità. La crittografia SSL della prima modalità viene completata e il traffico successivo tra il client e il server non è più crittografato. Durante la seconda modalità, la crittografia viene applicata fino alla chiusura della sessione.

Vale la pena notare che il server, in effetti, può funzionare senza crittografia, ma i client ufficiali di MSSQL non offrono questa opzione. Perché è importante? La crittografia nel canale, in un modo o nell’altro, previene la raccolta e l’analisi passiva del traffico, ovvero lo sniffing, che rappresenta una delle nostre funzioni principali.

Nel caso in cui non sia possibile modificare il traffico, la funzionalità di sniffer risulta limitata. In primo luogo, si fa riferimento ai cifrari basati su chiavi ephemeral. Tutti i cifrari basati su ECDHE e DHE rientrano in questa categoria, ad esempio:

Inoltre, per decrittare il traffico SSL è necessario utilizzare l’API OpenSSL a basso livello. A sua volta, questo richiede da parte nostra di mantenere costantemente aggiornato lo sniffer SSL.

Allo stesso tempo, il cliente deve installare una chiave del server sul lato del proxy (firewall). Questo rappresenta un ulteriore ostacolo per la protezione dei dati, poiché il cliente deve affidare la protezione del server a noi oppure non utilizzare il software client ufficiale di MsSQL (ad es. Microsoft SQL Server Management Studio) in modalità sniffer.

Per quanto riguarda le chiavi ephemeral, è possibile disabilitarle sul lato server di MsSQL. Il Windows Cryptographic Service Provider consente di farlo in condizioni normali.

Pertanto, nonostante le ovvie restrizioni del protocollo da parte di Microsoft, lo sniffer per MsSQL Server è incluso nel firewall. Abbiamo compiuto ogni sforzo per rendere agevole il suo utilizzo da parte dei nostri clienti.

DataSunrise Database Security offre una soluzione completa di sicurezza per Microsoft SQL Server o Azure SQL. DataSunrise include firewall per database, monitoraggio delle attività del database e audit, scoperta dei dati sensibili e altro ancora. DataSunrise supporta anche tutti gli altri database e data warehouse, come Oracle, IBM DB2, IBM Netezza, MySQL, MariaDB, Greenplum, Amazon Aurora, Amazon Redshift, Microsoft SQL Server, Azure SQL, Teradata e altri. Vi invitiamo a Scarica una versione di prova gratuita se desiderate installarla presso la Vostra sede. Nel caso siate utenti cloud e gestiate il vostro database su Amazon AWS o Microsoft Azure, potete ottenerlo dal AWS market place o dal Azure market place.