Acerca de la autenticación mutua TLS para los equilibradores de carga de aplicaciones
La autenticación mutua mediante el protocolo Transport Layer Security ( mTLS ) ofrece una mayor seguridad para tu equilibrador de carga de aplicaciones (ALB) de IBM Cloud®, ya que permite la autenticación basada en certificados entre los clientes y el equilibrador de carga, así como entre este y los servidores back-end.
¿Qué es el « TLS » mutuo?
mTLS es una extensión del protocolo estándar « TLS » que exige que ambas partes de una conexión se autentiquen mutuamente mediante certificados digitales. Mientras que la autenticación de nombre completo ( TLS ) estándar solo exige que el servidor presente un certificado al cliente, la autenticación de nombre completo recíproca ( mTLS ) exige que tanto el cliente como el servidor presenten certificados, lo que crea un mecanismo de autenticación bidireccional.
Con la compatibilidad de « mTLS » con los ALB, puedes implementar la autenticación basada en certificados en dos niveles:
- Autenticación en el front-end
- Verifica la identidad de los clientes exigiéndoles que presenten certificados válidos al conectarse al listener del equilibrador de carga.
- Autenticación en el back-end
- Autentica el equilibrador de carga ante los servidores de back-end presentando un certificado de cliente y, si lo deseas, verifica los certificados de los servidores de back-end.
Principales prestaciones
La función de soporte de ALB mTLS ofrece las siguientes capacidades:
- Verificación del certificado del cliente en el listener
- Active la autenticación de clientes en el front-end del equilibrador de carga configurando un certificado de autoridad de certificación (CA) para verificar los certificados de los clientes. La verificación garantiza que solo los clientes con certificados válidos firmados por la CA de confianza puedan establecer conexiones.
- Compatibilidad con la Lista de Certificados Revocados (CRL)
- Sube una lista CRL para comprobar si se han revocado certificados de cliente, lo que proporciona una capa adicional de seguridad al rechazar los certificados comprometidos o caducados.
- Verificación del certificado del servidor back-end
- Valida los certificados de los servidores back-end durante los procesos de establecimiento de conexión de TLS para garantizar que el equilibrador de carga solo se conecte a servidores back-end de confianza. La validación ayuda a prevenir los ataques de tipo «hombre en el medio».
- Autenticación de clientes en el back-end
- Presentar un certificado de cliente desde el equilibrador de carga a los servidores back-end cuando la infraestructura back-end requiera el protocolo « mTLS », lo que permite una autenticación bidireccional segura.
Casos de uso
mTLS La autenticación resulta útil en situaciones en las que se necesita una mayor seguridad y una verificación de identidad:
- Arquitecturas de seguridad de «confianza cero»
- Aplicar los principios de «confianza cero» exigiendo una autenticación basada en certificados para todas las conexiones, garantizando que se verifique cada cliente y cada servidor antes de establecer la comunicación.
- seguridad de API
- Protege los puntos finales de la API exigiendo a los clientes que presenten certificados válidos, lo que impide el acceso no autorizado a las API confidenciales y garantiza que solo las aplicaciones autenticadas puedan utilizar tus servicios.
- Comunicación entre microservicios
- Garantizar la seguridad de las comunicaciones entre microservicios mediante la implementación de la arquitectura « mTLS » tanto en el front-end como en el back-end, asegurando que todas las comunicaciones entre servicios estén autenticadas y cifradas.
- Requisitos de cumplimiento normativo
- Cumpla con los requisitos normativos que exigen mecanismos de autenticación sólidos, como los del sector financiero, sanitario o público.
- Validación en el servidor back-end
- Asegúrate de que tu equilibrador de carga solo se conecte a servidores back-end legítimos verificando sus certificados, lo que te protegerá frente a instancias back-end maliciosas o comprometidas.
Cómo funciona « mTLS » con los equilibradores de carga de aplicaciones
Los ALB admiten el protocolo « mTLS » tanto para las conexiones de cliente a equilibrador de carga como para las de equilibrador de carga a servidor. Los siguientes flujos de trabajo muestran cómo se lleva a cabo la validación de certificados durante cada protocolo de enlace « TLS ».
mTLS o de front-end (a nivel de listener)
Cuando se habilita la autenticación de cliente ( mTLS ) a nivel del listener:
- Un cliente inicia una conexión HTTPS con el equilibrador de carga.
- El equilibrador de carga muestra su certificado de servidor al cliente.
- El equilibrador de carga solicita un certificado de cliente al cliente.
- El cliente presenta su certificado al equilibrador de carga.
- El equilibrador de carga verifica el certificado del cliente comparándolo con el certificado de la autoridad de certificación (CA) configurado.
- Si se ha configurado una CRL, el equilibrador de carga comprueba si el certificado ha sido revocado.
- Si la verificación se realiza con éxito, se establece la conexión. De lo contrario, se rechaza la conexión.
mTLS o de back-end (a nivel de grupo)
Cuando se habilita la autenticación del servidor o la presentación de certificados de cliente a nivel de grupo:
- El equilibrador de carga inicia una conexión con un servidor de fondo.
- El servidor back-end presenta su certificado al equilibrador de carga.
- Si la verificación del servidor está activada, el equilibrador de carga comprueba que el certificado del servidor de fondo coincida con el certificado de la autoridad de certificación (CA) configurado.
- Si el servidor back-end solicita la autenticación del cliente, el equilibrador de carga presenta su certificado de cliente.
- El servidor back-end verifica el certificado del cliente.
- Si la verificación se realiza con éxito, se establece la conexión y el tráfico fluye hacia el servidor back-end.
Compatibilidad con la Lista de Certificados Revocados (CRL)
Una CRL es una lista de certificados que han sido revocados por la CA antes de su fecha de caducidad. Los certificados pueden ser revocados por diversos motivos, entre ellos:
- La clave privada se ha visto comprometida
- El certificado se expidió de forma incorrecta
- Los derechos del titular del certificado han cambiado
- Ya no es necesario el certificado
Al configurar una CRL para tu listener, el equilibrador de carga comprueba cada certificado de cliente cotejándolo con la lista de revocación durante el protocolo de enlace « TLS ». Si un certificado aparece en la CRL, la conexión se rechaza, aunque el certificado sea válido y esté correctamente firmado.
La compatibilidad con CRL proporciona una capa de seguridad adicional, ya que garantiza que los certificados comprometidos o invalidados no puedan utilizarse para acceder a tus servicios, aunque aún no hayan caducado.
Requisitos previos
Antes de configurar « mTLS » para tu ALB, asegúrate de que cumples los siguientes requisitos:
- Tienes un ALB con un perfil compatible con mTLS. Comprueba la propiedad «
mtls_supported» en el perfil del equilibrador de carga. - Tu listener utiliza el protocolo HTTPS. mTLS solo está disponible para los listeners de HTTPS.
- Tienes certificados válidos en formato « PEM » almacenados en « Secrets Manager ».
- Dispones de los permisos de IAM necesarios para gestionar los equilibradores de carga y acceder a los certificados en Secrets Manager.
Requisitos de los certificados
Todos los certificados utilizados para mTLS deben cumplir los siguientes requisitos:
- Los certificados deben estar en formato « PEM ».
- Los certificados deben almacenarse en Secrets Manager y identificarse mediante su CRN.
- Los certificados CA utilizados para la verificación deben incluir la cadena completa de certificados (certificados raíz e intermedios).
- Los certificados de cliente que el equilibrador de carga presenta a los servidores de back-end deben incluir la clave privada.
- Los certificados deben ser válidos (no caducados) y estar debidamente firmados por una autoridad de certificación de confianza.
Consideraciones importantes
Ten en cuenta las siguientes consideraciones a la hora de implementar mTLS:
- Responsabilidad en la gestión de certificados
- Eres responsable de gestionar todos los certificados, lo que incluye su obtención, carga, renovación y revocación. IBM Cloud no gestiona ni renueva automáticamente los certificados.
- Validación del certificado
- Debes comprobar que los certificados estén debidamente firmados por las autoridades de certificación correspondientes y que las relaciones de confianza estén correctamente establecidas. Los certificados no válidos o que no coinciden provocan errores en el protocolo de enlace de TLS y la indisponibilidad del servicio.
- Verificación del servidor back-end
- La verificación del servidor back-end está desactivada por defecto para mantener la compatibilidad con versiones anteriores. Cuando esté activada, debes asegurarte de que exista una relación de confianza válida entre el equilibrador de carga y los servidores back-end cargando el certificado de la autoridad de certificación (CA) correspondiente.
- Configuración a nivel de grupo
- Tanto la verificación del servidor back-end como la autenticación del cliente se configuran a nivel de grupo. Todos los servidores de back-end de un grupo utilizan la misma configuración. Si necesitas políticas de certificados diferentes para distintos servidores de back-end, crea grupos independientes.
- Actualizaciones de certificados
- Es posible que, para que las actualizaciones o revocaciones de certificados surtan efecto, sea necesario reiniciar el servicio de equilibrio de carga. Planifica las actualizaciones de los certificados durante las ventanas de mantenimiento para minimizar las interrupciones del servicio.
- Varias autoridades de certificación
- Cuando los servidores de back-end de un mismo grupo están firmados por distintas autoridades de certificación (CA), puedes proporcionar un archivo de CA agrupado que contenga todos los certificados raíz e intermedios pertinentes. Todos los servidores de back-end se consideran de confianza si su cadena de certificados está vinculada a cualquier CA del paquete.