Descripción general de TLS autenticado y mTLS del backend

Cuando un balanceador de cargas se conecta a backends que están dentro de Google Cloud, el balanceador de cargas acepta cualquier certificado que presenten los backends. En esos casos, el balanceador de cargas no realiza ninguna validación de certificados.

Con la TLS autenticada del backend o la autenticación del backend, el balanceador de cargas puede verificar la identidad de los backends a los que se conecta. Además, con la mTLS del backend, el balanceador de cargas también puede demostrar su identidad a los backends mediante un certificado TLS de cliente.

En el siguiente diagrama, se muestra la diferencia entre la mTLS del frontend y del backend, enfocándose en el rol del balanceador de cargas en cada caso. En mTLS de frontend, el balanceador de cargas actúa como el servidor y verifica la identidad del cliente. En la mTLS del backend, el balanceador de cargas actúa como el cliente y demuestra su identidad al backend.

mTLS de frontend y backend
mTLS de frontend y backend (haz clic para ampliar).

La mTLS funciona de forma independiente en el frontend y el backend. Puedes configurar la mTLS en el frontend, el backend o ambos.

En este documento, se proporciona una descripción general de la TLS autenticada del backend junto con la mTLS del backend. Para obtener más información sobre la mTLS de frontend, consulta la descripción general de la TLS mutua.

Se pueden configurar TLS autenticado y mTLS de backend en el recurso de servicio de backend de los balanceadores de cargas de aplicaciones externos globales.

Funciones

La mTLS usa la infraestructura de clave pública (PKI) para autenticar la identidad de las entidades que se comunican a través de la red. La infraestructura incluye tres componentes: un cliente, un servidor y una autoridad certificadora (AC). El TLS autenticado del backend y la mTLS del backend agregan las siguientes funciones a los balanceadores de cargas de aplicaciones:

  • El balanceador de cargas puede validar los certificados que presentan los backends con tus propios vínculos de confianza. Puedes subir varias anclas de confianza para permitir una migración sin problemas de una PKI anterior a una nueva sin tiempo de inactividad.

  • El balanceador de cargas puede validar los certificados TLS de los backends en función de las raíces de confianza públicas (PKI web).

  • Puedes configurar certificados intermedios, además de tus anclas de confianza, para ayudar a construir la ruta de validación de certificados del backend. El uso de certificados intermedios significa que tus servidores de backend no necesitan proporcionar la cadena de certificados completa.

  • Puedes configurar un nombre de host de indicación de nombre de servidor (SNI) de TLS para tu servicio de backend. Durante el protocolo de enlace TLS, el balanceador de cargas incluye este nombre de host de SNI en el mensaje ClientHello que envía al backend. Luego, el backend responde con su certificado TLS, y el balanceador de cargas verifica que al menos uno de los campos de nombre alternativo del sujeto (SAN) de este certificado coincida con el nombre de host o cualquiera de los campos de SAN configurados para el servicio de backend.

  • Puedes configurar el servicio de backend de tu balanceador de cargas para que use mTLS de modo que el balanceador de cargas pueda demostrar su identidad a los backends. Esta autenticación se realiza con un certificado de cliente (balanceador de cargas) que el balanceador de cargas presenta al backend.

Requisitos del certificado

Cuando configures certificados para TLS autenticado en el backend y mTLS en el backend, asegúrate de que cumplan con estos requisitos:

  • Las herramientas de criptografía modernas forman la base de la autenticación de mTLS. Los certificados deben usar algoritmos RSA o ECDSA para el intercambio de claves. Los algoritmos de hash deben usar SHA-256 o una función hash criptográfica más segura. No se admiten algoritmos de hash como MD4, MD5 y SHA-1.

  • Los certificados de servidor de hoja que proporciona el backend tienen los siguientes requisitos:

  • En el caso de los certificados de cliente (balanceador de cargas) de hoja que se usan en mTLS de backend, el certificado debe ser un recurso de certificado del Administrador de certificados. El alcance de este certificado debe ser client-auth, lo que indica que se usa como certificado de cliente en mTLS de backend.

  • Los certificados raíz y los intermedios que se usan con TLS autenticado por backend tienen los siguientes requisitos:

Componentes clave de TLS autenticado y mTLS del backend

Con el TLS autenticado del backend, el balanceador de cargas puede verificar la identidad de los backends a los que se conecta. Puedes configurar TLS autenticado de backend en un balanceador de cargas HTTP(S) que use HTTPS o HTTP/2 como su protocolo de servicio de backend. Si no configuras TLS autenticado del backend, el balanceador de cargas aceptará cualquier certificado del backend. Con la mTLS de backend, también puedes configurar el balanceador de cargas para que presente su propio certificado de cliente al backend, que este puede usar para autenticar el balanceador de cargas.

Para configurar el TLS autenticado de backend, debes hacer lo siguiente:

  • Crea un recurso de configuración de confianza.
  • Crea un recurso de configuración de autenticación de backend.
  • Actualiza el atributo de configuración de TLS en el servicio de backend y haz que apunte al recurso de configuración de autenticación de backend.

Para configurar la mTLS del backend, debes crear un certificado de cliente y adjuntarlo al recurso de configuración de autenticación del backend. No puedes adjuntar el certificado del cliente después de crear el recurso de configuración de autenticación del backend.

En el siguiente diagrama, se muestran los diferentes componentes, conectados al servicio de backend de un balanceador de cargas de aplicaciones, que habilitan el TLS autenticado del backend y el mTLS del backend.

Componentes de TLS y mTLS autenticados del backend
Componentes de TLS y mTLS autenticados del backend (haz clic para ampliar).

La siguiente información proporciona una descripción general de estos diferentes componentes que se usan para configurar TLS autenticado de backend y mTLS de backend.

Configuración de confianza

Para autenticar los certificados del servidor que tu backend presenta al balanceador de cargas, este debe configurarse con certificados X.509 que establezcan una cadena de confianza con la entidad emisora del certificado del backend. Para configurar la configuración de confianza, usa un recurso TrustConfig, que expresa toda la configuración de confianza y contiene un solo almacén de confianza.

Un almacén de confianza encapsula un ancla de confianza (certificado raíz) y, de forma opcional, uno o más certificados intermedios. Un ancla de confianza es un certificado que representa una raíz de confianza. Un certificado de servidor válido debe mostrar una cadena de confianza que se remonta a alguna ancla de confianza en el almacén de confianza.

Un certificado intermedio es un certificado que forma parte de una cadena de confianza que lleva a un ancla de confianza en el almacén de confianza. Se usa, junto con cualquier AC intermedia adicional incluida con el certificado final, para compilar la cadena de confianza durante el proceso de validación. Crear un certificado intermedio es opcional.

Si necesitas usar un certificado autofirmado, vencido, que no se encadena a una raíz de confianza especificada o que no pasó la validación, puedes agregarlo a una lista de entidades permitidas en la configuración de confianza. También es opcional crear un certificado autofirmado que se pueda agregar a una lista de entidades permitidas.

El almacén de confianza no contiene ninguna clave privada porque solo los certificados son necesarios para verificar una cadena de confianza.

Recurso de configuración de autenticación de backend

El recurso de configuración de autenticación de backend (BackendAuthenticationConfig), que se adjunta al servicio de backend del balanceador de cargas, habilita lo siguiente:

  • TLS autenticado del backend (con la configuración de confianza y las raíces públicas de confianza)
  • mTLS de backend (con el certificado de cliente)

Para habilitar el TLS autenticado del backend y el mTLS del backend, el recurso de configuración de autenticación del backend apunta a los siguientes recursos:

  • Configuración de confianza (trustConfig): es la configuración de confianza adjunta que se usa para validar el certificado del servidor que proporciona el backend.

  • Raíces de confianza públicas (wellKnownRoots): Indica si el balanceador de cargas confía en los certificados de servidor de backend que emiten las AC públicas, además de los certificados que confía la configuración de confianza. Para obtener más información, consulta Cómo usar raíces públicas de confianza.

  • Certificado de cliente (clientCertificate): es el certificado de cliente que el balanceador de cargas usa para expresar su identidad al backend, si la conexión al backend usa mTLS. En el caso de TLS autenticado por el backend (autenticación del backend), este campo puede estar vacío, en cuyo caso el balanceador de cargas solo autentica el backend, pero no a sí mismo, al backend.

Servicio de backend

Dentro del servicio de backend, el atributo tlsSettings apunta a los siguientes recursos para validar el certificado de backend.

  • Configuración de autenticación de backend (authenticationConfig)
  • Nombre de host de SNI (sni)
  • SAN aceptadas (subjectAltNames)

Los campos SNI (sni) y SAN (subjectAltNames) del atributo tlsSettings controlan cómo el balanceador de cargas valida el certificado del backend según los valores de SAN del certificado. Estos campos influyen en el proceso de validación, independientemente de si se configuró el TLS autenticado del backend.

Cuando se configura el campo SNI (tlsSettings.sni), el balanceador de cargas hace lo siguiente:

  • Envía el nombre de host SNI al servidor de backend durante el protocolo de enlace TLS.
  • Verifica que el certificado TLS del backend incluya un SAN que coincida con el nombre de host de SNI.

De forma predeterminada, el balanceador de cargas verifica que el certificado TLS del backend incluya un SAN que coincida con el nombre de host de SNI. Sin embargo, si las SAN están configuradas en el servicio de backend (tlsSettings.subjectAltNames), el balanceador de cargas hace lo siguiente:

  • Ignora el nombre de host de SNI para la verificación de SAN.
  • Verifica que el certificado TLS del backend incluya un SAN que coincida con uno de los SAN aceptados (subjectAltNames) configurados en el servicio de backend.

Certificado de cliente

Además de la TLS autenticada del backend (autenticación del backend), puedes configurar el servicio de backend de un balanceador de cargas para que use mTLS, de modo que el balanceador de cargas pueda probar su identidad al backend. Esta autenticación usa un certificado de cliente (balanceador de cargas) que el balanceador de cargas presenta al backend.

Para configurar la mTLS de backend, debes hacer lo siguiente:

  • Crea un recurso de certificado de cliente que contenga el certificado del cliente (balanceador de cargas) y su clave privada.
  • Adjunta el certificado de cliente al recurso de configuración de autenticación de backend.

El mTLS de backend también es compatible con las identidades de cargas de trabajo administradas de Compute Engine cuando configuras certificados administrados a través del Administrador de certificados. No se admiten los certificados administrados de PKI públicos, y todos los certificados de cliente deben tener un alcance client-auth y cumplir con los requisitos de los certificados.

Si el backend solicita un certificado de cliente, se debe configurar para aceptarlo. Si el backend rechaza la conexión del balanceador de cargas, este muestra un código de estado HTTP 502 para las solicitudes que está a través de un proxy y registra un estado genérico en el registro de Cloud.

Configura TLS autenticado del backend y mTLS del backend en el balanceador de cargas

Puedes configurar TLS autenticado y mTLS del backend en el balanceador de cargas con una PKI privada o raíces de confianza públicas.

Usa la PKI privada

A continuación, se proporciona una descripción general de los pasos clave que debes seguir para configurar la TLS autenticada del backend y la mTLS del backend en tu balanceador de cargas con certificados emitidos desde tu PKI privada. La PKI privada tiene la ventaja de estar completamente bajo tu control y aislada de los sistemas de PKI de la Internet pública.

  1. Crea un recurso de configuración de confianza que incluya el ancla de confianza (certificado raíz) y los certificados intermedios que funcionen como raíces de confianza.

  2. Para configurar mTLS de backend, crea un certificado de cliente que contenga el certificado del cliente (balanceador de cargas) y su clave privada.

  3. Crea un recurso de configuración de autenticación de backend que haga referencia a la configuración de confianza. Si deseas configurar mTLS de backend, el recurso de configuración de autenticación de backend hace referencia a la configuración de confianza y al certificado de cliente.

  4. Adjunta el recurso de configuración de autenticación de backend al servicio de backend del balanceador de cargas.

Para obtener más información sobre esta configuración en detalle, consulta las siguientes guías:

Usa raíces de confianza públicas

Además de usar certificados emitidos desde tu PKI privada para habilitar el TLS autenticado del backend, también puedes usar raíces de confianza públicas para validar el certificado del backend.

Para usar raíces de confianza públicas, no es necesario que crees una configuración de confianza ni la adjuntes al recurso de configuración de autenticación de backend. En su lugar, debes establecer PUBLIC_ROOTS como un valor en el campo wellKnownRoots del recurso de configuración de Authentication de backend. Dicho esto, también puedes crear una configuración de confianza que incluya de forma explícita las raíces de tus certificados emitidos públicamente, además de los certificados de confianza de la configuración de confianza.

La configuración de PUBLIC_ROOTS usa un conjunto de AC raíz, similar al conjunto de AC raíz de confianza de los navegadores, que administra Google y puede cambiar con el tiempo. Esto presenta el riesgo de que tus certificados de backend dejen de ser válidos cuando cambien estas raíces. Si necesitas validar certificados emitidos públicamente, considera elegir una AC confiable y bien establecida que use la firma cruzada intermedia para emitir tus certificados de backend y mitigar el riesgo de que venza o se revoque un certificado raíz.

Pasos para la validación del certificado del servidor

Cuando se valida el certificado del servidor durante el TLS autenticado del backend o la autenticación del backend, el balanceador de cargas hace lo siguiente:

  1. Verifica que el servidor tenga la clave privada del certificado.

    El servidor demuestra la posesión de la clave privada asociada con el certificado que presenta al balanceador de cargas firmando una información con su clave privada y enviándola al balanceador de cargas como parte del mensaje CertificateVerify. Luego, el balanceador de cargas verifica esta firma con la clave pública del certificado del servidor. Si la verificación de la firma falla, significa que el servidor de backend no posee la clave privada correspondiente al certificado. En estos casos, el balanceador de cargas finaliza el protocolo de enlace TLS sin registrar ningún error.

  2. Verifica la cadena de confianza.

    Si la configuración de confianza incluye al menos un ancla de confianza o tiene el atributo wellKnownRoots establecido en PUBLIC_ROOTS, el balanceador de cargas intenta verificar una cadena de confianza entre el certificado del servidor y el ancla de confianza configurado. Las verificaciones de verificación incluyen lo siguiente:

    • El certificado del servidor del backend, los certificados intermedios (si se proporcionan) y el certificado raíz configurado cumplen con los requisitos de los certificados.
    • Para todos los certificados de la cadena de confianza, el campo de asunto del certificado superior coincide con el campo del emisor del certificado secundario. Esta verificación ayuda a garantizar que la identidad (sujeto) del certificado superior sea la misma que la identidad que aparece como emisor en el certificado secundario.
    • Para todos los certificados de la cadena de confianza, el identificador de clave de asunto (SKID) del certificado superior coincide con el identificador de clave de autoridad (AKID) del certificado secundario. Esta coincidencia confirma que la autoridad raíz correcta emitió el certificado secundario y que se puede confiar en él porque se hace referencia a la clave pública de la raíz en el AKID para verificar la validez del certificado.

  3. Establece una conexión con el backend.

    Si la validación del certificado se realiza correctamente, el balanceador de cargas continúa con la conexión al backend.

    Sin embargo, si falla la validación del certificado, el balanceador de cargas finaliza la conexión con el backend, envía un código de estado HTTP 502 al cliente y registra el motivo de la finalización en Cloud Logging. En caso de un error de validación de certificado, las solicitudes entrantes posteriores activan el balanceador de cargas para reiniciar la conexión del backend.

    La conexión de backend también puede fallar si el servidor de backend rechaza la conexión. Con la mTLS de backend, esto puede suceder porque el certificado del cliente no es válido. Cuando falla la conexión con el backend, el balanceador de cargas responde a las solicitudes con proxy con un código de estado HTTP 502 y registra un motivo de error genérico en Cloud Logging.

Limitaciones

  • El TLS autenticado del backend y el mTLS del backend solo se pueden configurar para los balanceadores de cargas de aplicaciones externos globales. Los balanceadores de cargas de aplicaciones clásicos no admiten TLS autenticado por backend ni mTLS de backend.

  • El TLS autenticado del backend y el mTLS del backend no son compatibles con los siguientes tipos de backend:

    • Backends de NEG de Internet globales

    • Backends de App Engine

  • Para habilitar la mTLS del backend, también debes configurar la TLS autenticada del backend.

  • Si deseas habilitar mTLS de backend, debes crear el certificado de cliente antes de configurar el recurso de configuración de autenticación de backend.

  • Las verificaciones de estado que usan los backends no implementan la autenticación TLS ni las funciones de mTLS. Debes configurar los backends con extremos de verificación de estado que puedan responder a solicitudes HTTP o HTTPS.

  • El balanceador de cargas no pasa el nombre de host de SNI del cliente desde la conexión TLS del frontend cuando se conecta a un backend. Sin embargo, los backends pueden acceder al nombre de host SNI del cliente con un encabezado de solicitud personalizado.

  • En el caso de mTLS de backend, las claves del certificado de cliente están restringidas a lo siguiente:

    • Las claves RSA pueden variar de 2048 a 4096 bits.
    • Las claves ECDSA pueden usar las curvas P-256 o P-384.

  • El TLS autenticado del backend no admite verificaciones de revocación de certificados.

Cuotas y límites

  • Un solo almacén de confianza puede contener hasta 200 anclas de confianza y certificados intermedios combinados, con un límite independiente de 100 para los certificados intermedios. No más de tres certificados intermedios pueden compartir la misma información de la entidad y la clave pública de la entidad.

  • La profundidad máxima de una cadena de certificados es de 10 certificados, incluidos los certificados raíz y de entidad final. La cantidad máxima de certificados intermedios que se pueden evaluar cuando se intenta compilar la cadena de confianza es 100.

  • El TLS autenticado del backend limita la cadena de certificados que se recibe del backend a no más de 16 KB y 10 certificados.

  • Los certificados raíz que se usan para la validación no pueden contener más de 10 restricciones de nombres.

  • La cantidad máxima de nombres alternativos de entidad permitida en el campo tlsSettings.subjectAltNames[] es 5.

¿Qué sigue?