Stavo solo usando Sql Server Management Studio sul mio WiFi, e mi stavo chiedendo in realtà quanto sia sicura la comunicazione traffico / database. Il traffico dalle query è sicuro o è facilmente sniffato per password e dati sensibili?
Per impostazione predefinita, le comunicazioni del database non sono crittografate e vulnerabili allo sniffing. Per utilizzare la crittografia, è necessario configurare il server SQL con un certificato e quindi configurare il client per sfruttarlo. C'è una semplice procedura per il processo qui
gowenfawr è parzialmente errato su questo. La connessione iniziale (nome utente e password) a SQL Server può o non può passare il nome utente in testo non crittografato. Questo può dipendere dal tipo di connessione utilizzato (ODBC, OLE DB, ecc.). La password viene sempre passata in formato crittografato da SQL Server. Ora i tuoi stessi dati dalle query che vengono passate verranno visualizzati in testo chiaro, per impostazione predefinita.
Ho scritto un suggerimento su MSSQLTips.com a riguardo e mostra le catture di Wireshark. Che mostra che il tuo nome utente verrà passato in chiaro se stai usando ODBC, ma SSMS usa OLE DB e non mostrerà il tuo nome utente.
Per nascondere facilmente i tuoi stessi dati, puoi semplicemente abilitare "Force Encryption" come ho scritto, e lasciarlo usare Cert SQL Server. Sebbene una crittografia più strong sarebbe realizzata utilizzando il suggerimento gowenfawr . Si vorrà leggere su questo poiché l'uso di questa funzione negherà le connessioni alle applicazioni in alcune circostanze.
Tunnel della connessione SSMS tramite SSH. Per specificare una porta nella stringa di connessione SSMS, utilizzare la virgola + porta. Ad esempio ...
Senza tunnel: "sql.northwind.com" (che è lo stesso di sql.northwind.com, 1433)
Con tunnel: "Localhost, 1433"
O se è necessario modificare la porta di origine (se SQL è in esecuzione nella casella locale): "localhost, 50000" con il tunnel SSH che inoltra a 1433 / tcp sul terminale remoto
Leggi altre domande sui tag sql-server