Crittografia in Microsoft SQL Server

Come altri fornitori di DBMS, Microsoft usa il protocollo SSL per la protezione dei suoi clienti. Tuttavia, pochi sono consapevoli che, a differenza di altri DBMS, MsSQL incapsula la stretta di mano SSL all’interno del TDS.

Il trucco potrebbe essere fatto deliberatamente per ridurre il numero di potenziali minacce ai server MS, poiché oggi i fornitori usano SSL in una semplice combinazione di protocolli a strati come incapsulazione completa. È più facile e più universale poiché l’accensione/spegnimento di SSL non influisce sul protocollo principale.

La crittografia in MsSQL è realizzata tramite 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. Poi il client dirige il primo pacchetto di stretta di mano dopo averlo incapsulato in TDS come PRELOGIN. Tutti i pacchetti SSL successivi sono incapsulati allo stesso modo in TDS fino al completamento della stretta di mano.

Tuttavia, il primo e tutti i successivi pacchetti di applicazione SSL sono inviati come sono senza essere incapsulati in TDS. Il pacchetto incapsula la query di autorizzazione LOGIN7. Qui è dove le modalità cominciano a differire. La crittografia SSL della prima modalità è completata e il traffico seguente tra il client e il server non è più crittografato. Durante la seconda modalità, la crittografia è implementata fino alla chiusura della sessione.

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

Nel caso sia impossibile modificare il traffico, la funzionalità dello sniffer è limitata. In primo luogo, si riferisce ai cifrari basati su chiavi effimere. Tutti i cifrari basati su ECDHE e DHE rientrano in questa categoria, ad esempio:

Inoltre, per decrittografare il traffico SSL deve essere utilizzata l’API OpenSSL di basso livello. A sua volta, richiede a noi di mantenere lo sniffer SSL costantemente aggiornato.

Allo stesso tempo, il client deve installare una chiave server sul lato del proxy (firewall). È un altro ostacolo alla protezione dei dati, poiché il client deve affidare la protezione del server a noi o non utilizzare il software client ufficiale di MsSQL (ad esempio, Microsoft SQL Server Management Studio) in modalità sniffer.

Per quanto riguarda le chiavi effimere, possono essere disattivate sul lato server di MsSQL. Il Windows Cryptographic Service Provider consente di farlo in condizioni normali.

Così, nonostante le evidenti restrizioni del protocollo da parte di Microsoft, lo sniffer per MsSQL Server è incluso nel firewall. Abbiamo fatto tutto il possibile per rendere facile per i nostri clienti utilizzarlo.

DataSunrise Sicurezza nel Database offre una soluzione di sicurezza completa per Microsoft SQL Server o Azure SQL. DataSunrise include firewall per database, monitoraggio delle attività del database e audit, scoperta di 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 altro. È benvenuto a scaricare una prova gratuita se desidera installare presso la Sua sede. Nel caso sia un utente di cloud e gestisca il Suo database su Amazon AWS o Microsoft Azure può ottenerlo dal AWS market place o Azure market place.