¿Se recomienda usar ambos protocolos juntos? ¿En qué situación?
Hay diferentes capas de transporte seguro a considerar aquí:
Tanto las VPN SSL como las IPSec son buenas opciones, ambas con un considerable historial de seguridad, aunque pueden adaptarse a diferentes aplicaciones.
Las VPN IPsec operan en la capa 3 (red) y, en una implementación típica, brindan acceso completo a la red local (aunque el acceso se puede bloquear a través de firewalls y algunos servidores VPN son compatibles con las ACL). Por lo tanto, esta solución se adapta mejor a las situaciones en las que desea que los clientes remotos se comporten como si estuvieran conectados localmente a la red, y es particularmente bueno para las VPN de sitio a sitio. Las VPN IPSec también tienden a requerir software específico suministrado por el proveedor, que es más difícil de mantener en los dispositivos de usuario final y restringe el uso de la VPN a los dispositivos administrados.
SSL VPN se cita a menudo como la opción preferida para el acceso remoto. Operan en las capas 5 y 6, y en una implementación típica, conceden acceso a servicios específicos según la función del usuario, las más convenientes son las aplicaciones basadas en navegador. Por lo general, es más fácil configurar una VPN SSL con un control más granular sobre los permisos de acceso, que puede proporcionar un entorno más seguro para el acceso remoto en algunos casos. Además, SSL / TLS es inherentemente compatible con los dispositivos modernos y, por lo general, puede implementarse sin la necesidad de un software especializado del lado del cliente, o con clientes ligeros basados en el navegador. Estos clientes ligeros a menudo también pueden ejecutar comprobaciones locales para garantizar que las máquinas conectadas cumplan ciertos requisitos antes de que se les otorgue acceso, una función que sería mucho más difícil de lograr con IPSec.
En ambos casos, uno puede configurarse para lograr cosas similares a las otras: las VPN SSL se pueden usar para crear simplemente un túnel con acceso completo a la red, y las VPN IPSec se pueden bloquear para servicios específicos. Sin embargo, se acepta ampliamente que se adapten mejor a los escenarios anteriores.
Sin embargo, por exactamente estas razones, muchas organizaciones usarán una combinación de ambas; a menudo, una VPN IPSec para conexiones de sitio a sitio y SSL para acceso remoto.
Hay varias referencias sobre el tema de SSL frente a IPSec (algunas de ellas son directamente de los proveedores):
En algunos de los casos anteriores, como las VPN IPSec y los túneles VPN SSL, es posible que no esté recibiendo un cifrado de extremo a extremo con el servicio real que está usando. Aquí es donde usar una capa adicional de SSL / TLS es útil.
Supongamos que es remoto y está intentando conectarse a una aplicación web alojada internamente a través de una VPN IPSec. Si utiliza el protocolo HTTP a través de su navegador, su tráfico se encripta mientras se ejecuta a través del túnel VPN, pero luego se descifra cuando llega al punto final de la VPN remota y viaja a través de la red interna en texto claro. Esto podría ser aceptable en algunos casos de uso, pero en aras de la defensa en profundidad, lo ideal es que sepamos que nuestros datos no pueden interceptarse en ningún lugar entre usted y el servicio en sí. Al conectarse a esta aplicación a través de HTTPS, tiene efectivamente dos capas de seguridad: una entre usted y el punto final de la VPN, y otra que lo atraviesa (entre usted y el servidor web).
Por supuesto, esto no se limita a HTTPS, también debe emplear otros protocolos seguros como SSH, FTPS, SMTP con STARTTLS, etc., etc.
Aquí hay un buen artículo de cisco en IPSEC y SSL. Incluye fortalezas y debilidades, así como una descripción general de cada una, y también la implementación de ambas juntas.
Depende de que tenga un túnel VPN corporativo (que funciona con IPSEC), pero una capa por encima del servidor web interno al que está accediendo a través de VPN en la red corporativa puede ser HTTPS (que es a través de SSL)
Hace mucho tiempo hice una charla sobre esto
Hay razones para usar ambos protocolos. Cuando utilice un túnel IPsec, todavía desearía el cifrado a nivel de la aplicación. Esto es ventajoso si hay una brecha entre el final del túnel y donde termina su sesión.
El siguiente diagrama describe por qué es posible que desee un cifrado de nivel de aplicación como HTTPS (SQL en mi ejemplo) además de IPsec.
User => Website => IPSec Tunnel => Back End Network => SQL Backend
| => Data can be read by other hosts!
No tiene sentido usar ambos al mismo tiempo. Sí, el túnel de IPsec se "disuelve" en el firewall de enrutamiento de borde, pero de la misma manera, el TLS se "disuelve" dentro de DMZ, generalmente un servidor HTTP, es decir, si soy un pirata informático, no me molestaría con la canalización de la capa de red de sitio a sitio ni Canalización de capa de transporte TLS desde el firewall de borde al servidor DMZ HTTP.
En su lugar, concentraría mis esfuerzos en atacar el enlace del servidor HTTP a la aplicación. La única forma de protegerse contra eso sería extender la tubería segura hasta la aplicación, pero ni TLS ni IPsec VPN pueden hacerlo o es demasiado engorroso.
Eso deja el cifrado de la carga útil y la firma digital como la única opción, pero en ese caso, solo se necesita una tubería TLS o IPSEC, no ambas al mismo tiempo (para una seguridad equivalente y para cumplir con los objetivos de rendimiento). Si no es posible implementar la seguridad a nivel de la carga útil (aplicación), al mismo tiempo tener una tubería TLS e IPSEC no aumentaría significativamente la seguridad, mientras que al mismo tiempo degradaría significativamente el rendimiento.
IPsec por sí solo no protege a los usuarios finales (miles de millones de ellos). No tienen acceso directo a IP fuera de la red privada. Se conectan a través de ISP.
(El resultado final: si está creando una aplicación de usuario final de red pública, no puede usar IPsec.)
Ahí es donde entra TLS y otros (por ejemplo, SSH). Le brindan seguridad al usuario final frente a & punto la creciente lista de titulados y & pointint; incompetentes ISPs / gobiernos.