Quando è appropriato per SSL Encrypt Database connections?

Sembra che le due precedenti risposte a questa domanda raccomandino più o meno strongmente di attivare SSL comunque, ma vorrei suggerire un diverso angolo di ragionamento (anche se non sto raccomandando di non attivare SSL).

I due punti chiave nel valutare se hai bisogno di SSL o meno sono (a) ciò che SSL ti protegge contro e (b) che cos'è il modello di thread: enumerare le potenziali minacce.

SSL / TLS protegge il trasporto di informazioni tra un client (in questo caso, il server web) e un server (in questo caso il server di database) da manomissioni e intercettazioni da parte di chiunque sulla rete in mezzo (compresa la possibilità di salire su quelle due macchine).

Per valutare se il protocollo SSL è utile, è necessario presumere che l'autore dell'attacco sia in grado di eseguire l'attacco che SSL è progettato per proteggerti contro. Cioè, l'utente malintenzionato dovrebbe essere in grado di annusare i pacchetti sulla rete o su entrambe le macchine.

• Se qualcuno in grado di annusare i pacchetti dal server database, è probabile che abbia accesso root / admin a quel server. L'utilizzo di SSL / TLS in questa fase non farà alcuna differenza.

• Se qualcuno è in grado di annusare i pacchetti sulla rete tra il server Web e il server del database (esclusi quei computer), l'uso di SSL / TLS impedirà loro di vedere / modificare il contenuto dell'applicazione. Se pensi che sia possibile che sia possibile, attiva SSL . Un modo per mitigare questo sarebbe utilizzare due schede di rete sul server web: una verso il mondo esterno e una verso la LAN interna dove si trova il server DB (senza altre macchine, o in un modo che tu possa trattarle tutte come una singola macchina più grande). Questa rete che costituisce la web farm o il cluster globale (comunque lo si voglia chiamare) sarebbe fisicamente separata e avrà solo un punto di ingresso dall'esterno: il web server stesso (stesso principio per un nodo head proxy inverso).

• Se qualcuno è in grado di annusare i pacchetti sul nodo principale (il server web) stesso, è probabile che abbia accesso root lì (i processi eseguiti da utenti non-root sulla macchina, non dovrebbero essere in grado di leggere pacchetti che non sono per loro). In questo caso, avresti comunque un grosso problema.

  Ciò di cui dubito è se abilitare SSL ti protegga molto in questo scenario.

  Qualcuno con accesso root sul server web sarà in grado di leggere la configurazione dell'applicazione, comprese le password DB, e dovrebbe essere in grado di connettersi legittimamente al server DB, anche usando SSL.

  In contropartita, se si è supposto che ciò garantisca l'uso di SSL (perché potrebbe essere più difficile esaminare in che modo effettivamente i processi piuttosto che osservare semplicemente la rete, anche se si ha il controllo di root sulla macchina), questo significherebbe che vorresti anche girare per le comunicazioni localhost (ad esempio se hai altri servizi sul tuo server web, o nella situazione in cui sia il server DB che il server web si trovavano sullo stesso computer).

Non è necessariamente una brutta cosa essere cauti, ma devi porre la tua domanda nel contesto di ciò che potrebbero fare gli attaccanti se dovessero essere in grado di eseguire un attacco contro ciò che la misura di sicurezza (SSL) protegge tu contro, e se questa misura di sicurezza potrebbe impedire loro di raggiungere il loro obiettivo comunque, una volta in questa posizione.

Penso che la finestra sia in realtà piuttosto stretta (supponendo che la tua rete di back-end sia effettivamente protetta, fisicamente, non solo da qualche firewall tra un certo numero di macchine).

Quando la rete locale che include il server database e i client potrebbero includere altri processi, è necessario crittografare la connessione tra i due.

Questo è quasi sempre il caso dato che, anche se si presume che la rete locale sia impenetrabile (non si dovrebbe), oltre al client e al server del database ci sono di solito

1. amministratori che devono essere in grado di accedere e risolvere problemi o fare aggiornamenti
2. log collector che devono catturare file senza dati sensibili e spostarli da qualche altra parte
3. replicatori che devono copiare il contenuto del database per il backup off-site o per alimentare grandi tabelle a bassa sensibilità a sistemi di data mining
4. monitor che devono verificare se gli altri sono ancora vivi

Di questi, solo i replicatori devono avere accesso alle tabelle con dati sensibili, ma nessuno di questi processi può essere compromesso da attori malintenzionati nel reparto IT.

La crittografia di tutti i canali che contengono dati sensibili mantiene onesti le persone oneste, ti offre una difesa approfondita e ti aiuta a restringere la ricerca quando sorgono problemi.

Tieni presente che chiunque si trovi sulla stessa rete del tuo server potrebbe essere in grado di individuare il traffico o eseguire un attacco man-in-the-middle. SSL dovrebbe impedire questo, supponendo che sia impostato correttamente. È inoltre necessario impostare un firewall sul server del database e consentire solo le connessioni da indirizzi IP attendibili.

Il mio suggerimento è di accenderlo, quindi spegnerlo solo se pensate che stia causando problemi di prestazioni (o di altro tipo). In questo modo hai ridotto in modo significativo i tuoi vettori di attacco.

In realtà, il sovraccarico della crittografia SSL sulla rete sarà minimo, soprattutto se confrontato con il carico di elaborazione delle query SQL. Aumenteresti le prestazioni ottimizzando le query e la configurazione delle prestazioni del server piuttosto che disabilitando SSL.

Let's say I have a web server I setup, and then a database server...communicating locally and are behind firewall

Tralasciando il fatto che questa architettura fa schifo in termini di disponibilità ...

• ti fidi di tutti e di tutto "dietro il firewall"?
• credi che il tuo firewall sia perfetto?
• puoi prevedere che non dovrai mai connetterti da remoto per supportare una maggiore disponibilità, eseguire la migrazione del tuo centro dati o eseguire un backup?
• è il meccanismo di autenticazione predefinito per i dbms così sicuro da non poter essere sovvertito?
• hai un processo di distribuzione che garantisce che le credenziali del database non possano essere compromesse?

Se la tua risposta a uno di questi non è un sì certo, potresti trarre beneficio dalle ulteriori garanzie sull'utilizzo di una connessione SSL opportunamente configurata. Il costo delle prestazioni è trascurabile anche senza fare affidamento su connessioni persistenti (anche se anche questo può essere eliminato eliminando il traffico attraverso un tunnel persistente). Si tratta semplicemente di capire se il costo della configurazione di SSL (un paio d'ore di lavoro) è più che la responsabilità.