La terminación de HTTPS (presumiblemente, usted no indicó qué protocolo) en el equilibrador de carga tiene muchas ventajas, un subconjunto relevante aquí:
- solicite inspección, protocolo de limpieza / cumplimiento, restricciones de URL y WAF capacidad
- inspección de respuesta, DLP capacidad
- inspección de cookies / URL para la asignación del servidor y adherencia de sesión
- (probablemente) caché de sesión TLS común, RSA asistida por hardware y soporte de cifrado simétrico
Si no termina TLS en el equilibrador de carga, no tendrá ninguna capacidad de inspección y tendrá opciones de asignación de sesión limitadas.
El uso de un certificado en los servidores back-end (contenido / aplicación) también tiene algunas ventajas:
- el servidor back-end de contenido / aplicación usa el mismo protocolo que el cliente, esto puede tener un efecto en la generación de URL absolutas y cambiar el comportamiento de algunos sistemas que reconocen el protocolo (por ejemplo, OWA, pero hay soluciones para esto)
- el desarrollo y las pruebas suelen ser más fáciles si todo usa un protocolo
- puede mantener todo en el DMZ de front-end encriptado, lo que puede ser requerido por la política de seguridad
- si no hay DMZ de front-end (es decir, su equilibrador de carga está fuera de su servidor de seguridad perimetral), es casi seguro que se requiere esta configuración
y al menos una desventaja:
- gastos generales de TLS (en su mayoría generación de claves RSA). En una red de confianza, puede ser aceptable usar claves RSA más cortas o cifrados simétricos más rápidos (menos robustos). Las conexiones persistentes o los tiempos de sesión más largos también mitigan.
En el caso general, el balanceo de carga o el proxy inverso es más simple cuando el servidor de aplicaciones y el servidor de servicios de fondo utilizan el mismo protocolo (esquema de URI), nombre de host, puerto y ruta de acceso de URI. Esto simplifica o elimina la necesidad de volver a escribir encabezados, contenido, rutas de cookies, mensajes de error, etc.
Los clientes (deberían) solo verán el certificado de CA público en el front-end (equilibrador de carga). Puede usar un certificado autofirmado sin costo en los servidores web de back-end. Por lo general, no hay razón para que no pueda usar los mismos certificados de CA comerciales aquí, aunque algunas CA solían requerir una "licencia" para usar un certificado en más de un dispositivo.
Todas las conexiones se cifrarán del cliente al equilibrador de carga y, nuevamente, del equilibrador de carga al servidor de fondo.
Vea también: ¿Debe terminarse SSL en un equilibrador de carga?