si consiglia di utilizzare entrambi i protocolli insieme? In quale situazione?
Ci sono diversi livelli di trasporto sicuro da considerare qui:
Sia le VPN SSL che IPSec sono buone opzioni, entrambe con un notevole pedigree di sicurezza, sebbene possano adattarsi a diverse applicazioni.
Le VPN IPsec operano a livello 3 (rete) e in una tipica implementazione offrono accesso completo alla rete locale (sebbene l'accesso possa essere bloccato tramite firewall e alcuni server VPN supportino gli ACL). Questa soluzione è quindi più adatta alle situazioni in cui si desidera che i client remoti si comportino come se fossero collegati in locale alla rete, ed è particolarmente utile per le VPN site-to-site. Le VPN IPSec tendono anche a richiedere software specifico fornito dal fornitore, che è più difficile da mantenere sui dispositivi degli utenti finali e limita l'utilizzo della VPN ai dispositivi gestiti.
Le VPN SSL sono spesso citate come la scelta preferita per l'accesso remoto. Operano sui livelli 5 e 6 e, in una tipica implementazione, concedono l'accesso a servizi specifici basati sul ruolo dell'utente, il più conveniente dei quali sono le applicazioni basate su browser. Di solito è più semplice configurare una VPN SSL con un controllo più granulare sulle autorizzazioni di accesso, che in alcuni casi può fornire un ambiente più sicuro per l'accesso remoto. Inoltre, SSL / TLS è intrinsecamente supportato da dispositivi moderni e può essere normalmente implementato senza la necessità di software specialistici lato client o altrimenti con client basati su browser leggeri. Questi client leggeri possono spesso eseguire anche controlli locali per garantire che le macchine di connessione soddisfino determinati requisiti prima che gli venga concesso l'accesso, una funzionalità che sarebbe molto più difficile da ottenere con IPSec.
In entrambi i casi è possibile configurare uno per ottenere cose simili all'altra - Le VPN SSL possono essere utilizzate per creare semplicemente un tunnel con accesso completo alla rete e VPN IPSec possono essere bloccate su servizi specifici - tuttavia è ampiamente concordato che sono più adatti agli scenari di cui sopra.
Tuttavia, proprio per queste ragioni, molte organizzazioni useranno una combinazione di entrambi; spesso una VPN IPSec per le connessioni da sito a sito e SSL per l'accesso remoto.
Esistono numerosi riferimenti sull'argomento SSL vs IPSec (alcuni di questi sono direttamente dai fornitori):
In alcuni dei casi sopra citati, come VPN IPSec e tunnel SSL VPN, potrebbe non essere possibile ottenere la crittografia end-to-end con il servizio effettivo che si sta utilizzando. È qui che è utile utilizzare un ulteriore livello di SSL / TLS.
Supponiamo che tu sia remoto e cerchi di connetterti a un'applicazione Web ospitata internamente tramite una VPN IPSec. Se si utilizza il protocollo HTTP tramite il browser, il traffico viene crittografato mentre è in esecuzione attraverso il tunnel VPN stesso, ma viene quindi decifrato quando raggiunge l'endpoint VPN remoto e viaggia sulla rete interna in chiaro. Questo potrebbe essere accettabile in alcuni casi d'uso, ma nell'interesse della difesa in profondità, desideriamo idealmente sapere che i nostri dati non possono essere intercettati da nessuna parte tra te e il servizio stesso. Collegandosi a questa applicazione tramite HTTPS, hai effettivamente due livelli di sicurezza: uno tra te e l'endpoint VPN, e un altro che lo attraversa (tra te e il server web stesso).
Ovviamente, questo non è limitato all'HTTPS: dovresti anche impiegare altri protocolli sicuri come SSH, FTPS, SMTP con STARTTLS ecc. ecc.
Ecco un buon articolo da Cisco su IPSEC e SSL. Comprende punti di forza e di debolezza, oltre a una panoramica di ciascuno, e all'implementazione di entrambi.
Ci sono motivi per utilizzare entrambi i protocolli. Quando si utilizza un tunnel IPsec, si desidera comunque la crittografia a livello di applicazione. Questo è vantaggioso se vi è uno spazio tra la fine del tunnel e il punto in cui termina la sessione.
Il diagramma seguente descrive il motivo per cui si desidera la crittografia a livello di applicazione come HTTPS (SQL nel mio esempio) oltre a IPsec.
User => Website => IPSec Tunnel => Back End Network => SQL Backend
| => Data can be read by other hosts!
Non ha senso usare entrambi allo stesso tempo. Sì, il tunnel IPsec si "dissolve" al firewall di routing edge, ma in modo simile TLS "si dissolve" all'interno di DMZ, in genere server HTTP, cioè se io sono un hacker non mi preoccuperei del pipe di sicurezza del livello di rete da sito a sito Tubi del livello di trasporto TLS dal firewall di bordo al server DMZ HTTP.
Invece concentrerei i miei sforzi per attaccare il collegamento del server HTTP-to-application. L'unico modo per proteggersi sarebbe quello di estendere il tubo sicuro fino all'applicazione, ma né TLS né VPN IPsec possono farlo o sono troppo ingombranti.
Ciò lascia la crittografia del payload e la firma digitale come unica scelta, ma in tal caso è necessario solo una pipe TLS o IPSEC, non entrambe contemporaneamente (per una sicurezza equivalente e per raggiungere gli obiettivi di performance). Se non è possibile implementare la sicurezza a livello di payload (applicazione), avere contemporaneamente la pipe TLS e IPSEC non aumenterebbe significativamente la sicurezza, mentre allo stesso tempo ridurrebbe significativamente le prestazioni.
IPSec di per sé non protegge gli utenti finali (miliardi di loro) - non hanno accesso diretto IP al di fuori della rete privata - si collegano tramite gli ISP.
(La conclusione: se stai creando un'applicazione per l'utente finale della rete pubblica, non puoi utilizzare IPsec.)
È qui che entra in gioco TLS e altri (es. SSH). Danno sicurezza all'utente finale di fronte a & pointint; la lista crescente di titoli e & pointint; incompetente ISP / governi.