Autenticación TLS mutua - AWS App Mesh

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Autenticación TLS mutua

La autenticación TLS (Seguridad de la capa de transporte) mutua es un componente opcional de TLS que ofrece autenticación bidireccional entre pares. La autenticación TLS mutua añade una capa de seguridad a TLS y permite que sus servicios verifiquen al cliente que realiza la conexión.

El cliente de la relación cliente-servidor también proporciona un certificado X.509 durante el proceso de negociación de la sesión. El servidor utiliza este certificado para identificar y autenticar al cliente. Este proceso ayuda a comprobar si el certificado lo ha emitido una entidad de certificación (CA) de confianza y si el certificado es válido. También utiliza el nombre alternativo del asunto (SAN) en el certificado para identificar al cliente.

Puede habilitar la autenticación TLS mutua para todos los protocolos compatibles AWS App Mesh con. Son TCP, HTTP/1.1, HTTP/2, gRPC.

nota

Con App Mesh, puede configurar la autenticación TLS mutua para las comunicaciones entre los proxies de Envoy desde sus servicios. Sin embargo, las comunicaciones entre sus aplicaciones y los proxies de Envoy no están cifradas.

Certificados de la autenticación TLS mutua

AWS App Mesh admite dos posibles fuentes de certificados para la autenticación TLS mutua. Los certificados de cliente de una política de cliente de TLS y la validación del servidor de una configuración de TLS de oyente se pueden obtener de:

  • Sistema de archivos: certificados del sistema de archivos local del proxy de Envoy que se está ejecutando. Para distribuir certificados a Envoy, debe indicar las rutas de los archivos de la cadena de certificados y la clave privada de la API de App Mesh.

  • El Servicio de Descubrimiento Secreto (SDS) de Envoy: cinco ring-your-own sidecars que implementan el SDS y permiten enviar los certificados a Envoy. Entre ellas se incluye el entorno en tiempo de ejecución de SPIFFE (SPIRE).

importante

App Mesh no almacena los certificados ni las claves privadas que se utilizan para la autenticación TLS mutua. En su lugar, Envoy los almacena en la memoria.

Configurar puntos de conexión de malla

Configure la autenticación TLS mutua para sus puntos de conexión de malla, como nodos virtuales o puertas de enlace. Estos puntos de conexión proporcionan certificados y especifican las autoridades de confianza.

Para ello, es necesario aprovisionar certificados X.509 tanto para el cliente como para el servidor y definir de forma explícita los certificados de las autoridades de confianza en el contexto de la validación tanto de la terminación como del origen de TLS.

Confianza dentro de una malla

Los certificados del lado del servidor se configuran en los oyentes de nodos virtuales (terminación de TLS) y los certificados del lado del cliente se configuran en los backends de servicio de nodos virtuales (origen de TLS). Como alternativa a esta configuración, puede definir una política de cliente predeterminada para todos los backends de servicios de un nodo virtual y, a continuación, si hace falta, puede anular esta política para backends específicos según sea necesario. Las puertas de enlace virtuales solo se pueden configurar con una política de cliente predeterminada que se aplique a todos sus backends.

Puede configurar la confianza en diferentes mallas habilitando la autenticación TLS mutua para el tráfico entrante en las puertas de enlace virtuales de ambas mallas.

Confianza fuera de una red

Especifique los certificados del lado del servidor en el oyente de puerta de enlace virtual para la terminación de TLS. Configure el servicio externo que se comunica con su puerta de enlace virtual para presentar los certificados del lado del cliente. Los certificados deben proceder de una de las mismas autoridades de certificación (CA) que utilizan los certificados del lado del servidor en el oyente de puerta de enlace virtual para el origen de TLS.

Migrar los servicios a la autenticación TLS mutua

Siga estas pautas para mantener la conectividad al migrar sus servicios existentes en App Mesh a la autenticación TLS mutua.

Migración de servicios que se comunican a través de texto sin formato
  1. Habilite el modo PERMISSIVE para la configuración de TLS en el punto de conexión del servidor. Este modo permite que el tráfico de texto sin formato se conecte al punto de conexión.

  2. Configure la autenticación TLS mutua en su servidor, especificando el certificado de servidor, la cadena de confianza y, opcionalmente, los SAN de confianza.

  3. Confirme que la comunicación se realiza a través de una conexión TLS.

  4. Configure la autenticación TLS mutua en sus clientes, especificando el certificado de cliente, la cadena de confianza y, opcionalmente, los SAN de confianza.

  5. Habilite el modo STRICT para la configuración de TLS en el servidor.

Migración de servicios que se comunican a través de TLS
  1. Configure los ajustes de la TLS mutua en sus clientes, especificando el certificado de cliente y, opcionalmente, los SAN de confianza. El certificado de cliente no se envía a su backend hasta que el servidor de backend lo solicita.

  2. Configure los ajustes de la TLS mutua en su servidor, especificando la cadena de confianza y, de forma opcional, los SAN de confianza. Para ello, el servidor solicita un certificado de cliente.

Verificación de la autenticación TLS mutua

Puede consultar la documentación Seguridad de la capa de transporte: verificar el cifrado para saber exactamente cómo Envoy emite estadísticas relacionadas con TLS. Para la autenticación TLS mutua, debe examinar las siguientes estadísticas:

  • ssl.handshake

  • ssl.no_certificate

  • ssl.fail_verify_no_cert

  • ssl.fail_verify_san

En conjunto, los dos ejemplos de estadísticas siguientes muestran que todas las conexiones TLS correctas que terminan en el nodo virtual tienen su origen en un cliente que proporcionó un certificado.

listener.0.0.0.0_15000.ssl.handshake: 3
listener.0.0.0.0_15000.ssl.no_certificate: 0

El siguiente ejemplo de estadística muestra que las conexiones de un nodo de cliente virtual (o puerta de enlace) a un nodo virtual de back-end produjeron un error. El nombre alternativo del asunto (SAN) que se presenta en el certificado del servidor no coincide con ninguno de los SAN en los que confía el cliente.

cluster.cds_egress_my-mesh_my-backend-node_http_9080.ssl.fail_verify_san: 5

Tutoriales de la autenticación TLS mutua de App Mesh