Come deve essere garantita la connessione tra un server ospitato e un database?

Se si configura l'app per utilizzare TLS per connettersi al db, non può essere sniffata. Se questo viene fatto insieme a tutto il resto, stai bene. La stringa di connessione è decrittografata in memoria in modo che qualcuno abbia dovuto compromettere una delle macchine per ottenere qualcosa di utile. Naturalmente è necessario prendere le precauzioni anche qui, ma per quanto riguarda lo sniffing, non può essere fatto se si usa TLS.

My web application uses a connection string to access a database. The connection string is secured and encrypted... but when the connection is active, couldn't someone intercept that connection and effectively "sniff" what is being stored and read?

Forse.

In una tipica configurazione di piccole applicazioni Web, si eseguirà il database sullo stesso computer del server Web e dell'applicazione. In questo caso, la connessione tra l'applicazione e il database sarà protetta dal sistema operativo, che impone l'accesso a tale indirizzo o socket di dominio solo dai processi locali. C'è poco da guadagnare qui dalla crittografia della connessione.

In un'altra configurazione, potresti avere un filo fisico che collega due macchine sullo stesso rack. Il rack può essere collocato in un centro dati sicuro in un rack a gabbia, dove si è soddisfatti dei parametri di sicurezza del data center, o potrebbe essere in un armadio chiuso in ufficio, e si è contenti di fidarsi del fatto che i dipendenti non ci provino rompere deliberatamente nell'armadio. In questo caso, aggiungere la crittografia potrebbe essere eccessivo.

In una situazione simile al paragrafo precedente, ma ora hai un router obsoleto tra le tue macchine. Il problema è che questo router esegue software obsoleti con vulnerabilità note, o non ti fidi della sua configurazione di Virtual Networking, o non supporta tali funzionalità, o sei preoccupato per l'acquisizione da remoto dell'amministrazione web del router. Quindi potresti aggiungere la crittografia TLS e l'autenticazione reciproca per coprire le carenze del router obsoleto.

In un altro caso tipico, è possibile eseguire il database e il server Web in più macchine virtuali in un provider di cloud pubblico, si potrebbe voler aggiungere la crittografia inter-macchina o si potrebbe decidere che il controllo dell'accesso alla rete del provider cloud non sia abbastanza affidabile per il tipo di dati con cui hai a che fare. È possibile eseguire una VPN tra le macchine o una rete di sovrapposizione crittografata sull'infrastruttura di rete esistente.

Tradizionalmente, la crittografia della rete termina ai margini: un bilanciatore del carico o una delle prime macchine dopo aver gestito la decrittazione TLS e tutto il traffico interno non è crittografato. Ciò deriva dalla fiducia della rete interna e dalla difficoltà di impostare la crittografia tra ogni macchina.

Hai ragione che un intruso che possa intercettare il traffico interno può sfruttarlo per osservare tutto il traffico del database in questo tipo di configurazione. Questa idea (anche se su scala più ampia, tra i data center) è al centro del programma NSA e GCHQ MUSCOLARE , e dopo che è stato rivelato, diverse grandi aziende tecnologiche hanno annunciato pubblicamente che stavano crittografando il traffico interno.

Per quanto riguarda le specifiche, sì, la maggior parte dei database supporta le connessioni TLS.

La domanda è sempre se questo è qualcosa che si adatta al tuo modello di minaccia . Di quale tipo di aggressori è necessario proteggere? Che tipo di dati stai tenendo? Se stai eseguendo, ad esempio, un'installazione di WordPress per la squadra di calcio di tuo figlio, impostare la crittografia sul database è probabilmente eccessivo. Se sei un processore di carte di credito, probabilmente no. Devi decidere da solo cosa ha senso nella tua situazione.

Non c'è nulla su TLS che ti limiti a utilizzarlo per proteggere la connessione tra il server delle applicazioni e il database. Puoi andare avanti e avere la comunicazione protetta da TLS. Alcune organizzazioni che si occupano di informazioni altamente riservate, di solito compieranno un ulteriore passaggio. Se, ad esempio, richiedono una maggiore sicurezza per alcuni elementi del loro traffico (informazioni sulla carta di credito, ecc.), Di solito è necessario distribuire una soluzione in grado di implementare una crittografia specifica per le colonne e il controllo degli accessi.

In tale situazione, la soluzione dovrebbe mettere un modulo di crittografia sul database e sul server delle applicazioni per garantire un approccio di crittografia granulare.

Divulgazione: ho lavorato come consulente su una di tali soluzioni