Este dilema se puede solucionar de diversas maneras, sin embargo te enseñamos la que para nosotros es la solución más completa.
Solución:
Una práctica muy común (no diría estándar) es colocar/configurar el certificado en el equilibrador de carga, no en los servidores back-end. ¿Por qué? Esto permite que el balanceador de carga maneje el protocolo de enlace TLS/la sobrecarga de terminación (es decir memoria/CPU para mensajes TLS), en lugar de que los servidores de aplicaciones back-end utilicen sus CPU para ese cifrado, además de proporcionar el comportamiento de la aplicación. Por lo tanto, generalmente es un “pro” tener la terminación TLS frente a sus servidores de aplicaciones.
Esto también permite el almacenamiento en caché de sesiones TLS en la ruta única a sus servidores (es decir a través del balanceador de carga), lo que significa mayores posibilidades de usar una sesión TLS en caché. Si, por otro lado, configuró el certificado en cada uno de los servidores back-end, entonces esos servidores (presumiblemente) tendrían su propio separado Cachés de sesión TLS; un cliente puede (o no puede) ser dirigido, por el balanceador de carga, al servidor backend con su Sesión TLS en caché.
Entonces, la versión corta es: configurar el certificado en el balanceador de carga es el enfoque generalmente recomendado.
¡Espero que esto ayude!
Si no carga el certificado en el equilibrador de carga, solo puede equilibrar la carga de las conexiones TCP/IP, ya que el tráfico en sí está cifrado.
Al cargar el certificado en su balanceador de carga, obtiene la capacidad de hacer todo tipo de cosas más interesantes allí, según las capacidades de su balanceador de carga:
- Cree sesiones persistentes/persistentes de sesión, de modo que las solicitudes subsiguientes de un usuario específico siempre se enruten al mismo servidor de back-end (por ejemplo, basado en una cookie de sesión), lo cual es mucho más confiable que usar la dirección IP de origen como base para afinidad, que es la única opción cuando no tiene el certificado en el LB.
- Dirija diferentes URL a diferentes grupos de servidores back-end, es decir, directo
example.com/app-1a servidores de aplicaciones diferentes a los utilizados paraexample.com/app-2 - etc.
Muy a menudo terminará la conexión TLS/SSL en el LB y tendrá tráfico sin cifrar entre el LB y los servidores back-end, pero nada le impide establecer allí una segunda conexión TLS/SSL si sus requisitos de seguridad son tales.
Agradecemos que quieras favorecer nuestra publicación exponiendo un comentario y puntuándolo te estamos eternamente agradecidos.