Patrón de Descarga de Puerta de Enlace

Delegar funcionalidad de servicio compartida o especializada en un proxy de puerta de enlace. Este enfoque simplifica el desarrollo de aplicaciones mediante la centralización de problemas transversales, como la terminación de certificados TLS orientadas al cliente, en la puerta de enlace en lugar de duplicarlos entre servicios.

Cuando varios servicios comparten responsabilidades como la autenticación, la supervisión o la traducción de protocolos, la consolidación de esos problemas en una sola puerta de enlace reduce la sobrecarga de configuración por servicio y el riesgo de implementación.

Contexto y problema

Algunas de las características que se usan habitualmente en varios servicios requieren configuración, administración y mantenimiento. Un servicio compartido o especializado que distribuye con cada implementación de aplicaciones agrega sobrecarga administrativa y aumenta la probabilidad de error de implementación. Debe implementar las actualizaciones en una característica compartida en todos los servicios que comparten esa característica.

Los problemas de seguridad, como la validación de tokens, el cifrado y la administración de certificados TLS, pueden requerir que los miembros del equipo tengan aptitudes altamente especializadas. Por ejemplo, sin una puerta de enlace, es posible que tenga que configurar e implementar un certificado orientado al cliente en cada instancia de aplicación. Debe hacer un seguimiento de su vencimiento y actualizarlo, probarlo y verificarlo en todas esas instancias.

Otros servicios comunes, como la autenticación, la autorización, el registro, la supervisión, o la limitación pueden resultar difíciles de implementar y administrar en un gran número de despliegues. La consolidación de este tipo de funcionalidad reduce la sobrecarga y la posibilidad de errores.

Solución

Descargue algunas funcionalidades en una puerta de enlace. A continuación, la puerta de enlace controla problemas transversales, como la administración de certificados orientados al cliente, la autenticación, la terminación TLS, la supervisión, la traducción de protocolos y la limitación en nombre de los servicios back-end.

En el diagrama siguiente se muestra una puerta de enlace que finaliza las conexiones TLS entrantes y aplica las funcionalidades compartidas. La puerta de enlace valida el certificado de back-end y vuelve a cifrar el tráfico a través de una conexión TLS independiente al servicio back-end.

Diagrama de un cliente que se conecta a una puerta de enlace a través de TLS.

Estos son algunos ejemplos de las ventajas de este patrón:

  • Simplifique el desarrollo de servicios mediante la centralización de la configuración compartida, como la autenticación, la limitación y el registro de solicitudes, en lugar de implementarlo en cada servicio back-end. La centralización mejora la coherencia y hace que las actualizaciones de servicio sea más sencillas.

  • Permite a los equipos expertos implementar características que requieren conocimientos especializados, como la seguridad. Su equipo principal puede centrarse en la funcionalidad de la aplicación, dejando estas preocupaciones especializadas pero transversales a los expertos pertinentes.

  • Proporciona coherencia en el registro y la supervisión de las solicitudes y las respuestas. Incluso si un servicio no se ha instrumentado correctamente, la puerta de enlace puede proporcionar un nivel básico de monitorización y registro.

  • Centralice la gestión del tráfico con conciencia de carbono. Una puerta de enlace puede ajustar el almacenamiento en caché, la limitación de velocidad y los comportamientos de registro en función de las señales de intensidad de carbono en tiempo real. Azure API Management proporciona estas funcionalidades en versión preliminar limitada, en regiones seleccionadas y niveles clásicos (Desarrollador, Básico, Estándar y Premium). Para obtener más información sobre la disponibilidad y la configuración, consulte API sostenibles para el medio ambiente en Azure API Management.

Problemas y consideraciones

Tenga en cuenta los puntos siguientes al decidir cómo implementar este patrón:

  • Alta disponibilidad y resistencia. Asegúrese de que la puerta de enlace proporcione una alta disponibilidad y sea resistente a errores. Evite los puntos únicos de error mediante la ejecución de varias instancias de la puerta de enlace. Dado que la puerta de enlace termina las conexiones de los clientes y puede almacenar en búfer los cuerpos de las solicitudes, tenga en cuenta cómo se gestionan las solicitudes en curso durante los fallos de instancia. Utilice mecanismos de drenaje de conexiones o de apagado ordenado para que, al eliminar o reiniciar una instancia de puerta de enlace, no se interrumpan las sesiones activas.

  • Capacidad y escalabilidad. Asegúrese de que la puerta de enlace está diseñada para los requisitos de capacidad y escalado de la aplicación y los puntos de conexión. Asegúrese de que la puerta de enlace no se convierte en un cuello de botella para la aplicación y es lo suficientemente escalable. La puerta de enlace debe estar aprovisionada para soportar picos de tráfico, no solo la carga media. Infraaprovisionar la puerta de enlace para reducir costes degrada directamente el rendimiento de todos los servicios que dependen de ella.

  • Ámbito de descarga. Delega las funcionalidades compartidas por varios servicios o rutas cuando centralizarlas reduzca la duplicación en la implementación y la administración.

  • Separación de lógica de negocios. Nunca delegue la lógica de negocio en la pasarela.

  • Seguimiento de transacciones. Si necesita realizar un seguimiento de las transacciones, considere la posibilidad de generar identificadores de correlación para fines de registro.

  • Sobrecarga de latencia. La puerta de enlace agrega un salto de red a cada solicitud. Cada función externalizada que realiza el gateway, como la terminación de TLS, la autenticación o la inspección de solicitudes, añade tiempo de procesamiento a la trayectoria de la solicitud. La agrupación de conexiones de puerta de enlace y las conexiones de mantenimiento activo a los servicios back-end pueden compensar parcialmente el costo de latencia mediante la reutilización de conexiones en lugar de establecer nuevas para cada solicitud. Evalúe si la latencia combinada del salto a través de la puerta de enlace y de las funciones externalizadas es aceptable para los objetivos de rendimiento de la carga de trabajo.

  • Complejidad operativa. Una puerta de enlace centralizada consolida la administración, pero también concentra la responsabilidad operativa. Debe gestionar la configuración de la puerta de enlace, el ciclo de vida de los certificados, las actualizaciones de directivas y las actualizaciones de versiones como una responsabilidad compartida. Asegúrese de que el equipo responsable de la puerta de enlace tiene la capacidad y las herramientas para administrarla a escala de todos los servicios que dependen de ella.

  • Implicaciones de seguridad. La puerta de enlace es un destino de alto valor porque centraliza funciones de seguridad transversales, como la autenticación, la terminación TLS y la inspección de solicitudes. Un riesgo de la puerta de enlace puede exponer todos los servicios de bajada. Proteja la puerta de enlace, restrinja su superficie de administración y supervise su comportamiento anómalo independientemente de los servicios back-end que protege.

  • Prevención de la elusión del gateway. Configure los servicios de back-end para que acepten solicitudes solo a través de la ruta del gateway prevista. De lo contrario, los clientes pueden conectarse directamente a un back-end y omitir la autenticación, la limitación, la inspección de solicitudes y el registro en la puerta de enlace.

  • Propagación de identidades. Defina si cada back-end autoriza al autor de la llamada original, a la identidad de carga de trabajo de la puerta de enlace o a ambos. Conserva los tokens del autor de la llamada o las declaraciones de confianza solo cuando el backend requiera un contexto de usuario delegado. Autentique siempre la puerta de enlace en el back-end por separado. No trate los encabezados reenviados no comprobados como prueba de identidad.

  • Mantenimiento de TLS. Si la puerta de enlace finaliza TLS, restablezca TLS al back-end. No reenvíe el tráfico a través de HTTP sin cifrar. Trate todas las redes como que no son de confianza. Esta topología todavía requiere un proceso para emitir, rotar y revocar certificados back-end.

  • Encabezados reenviados y contexto de cliente. Cuando la puerta de enlace finaliza las conexiones de cliente y establece nuevas conexiones a los servicios back-end, se pierde información como la dirección IP del cliente, el protocolo original y el nombre de host a menos que la puerta de enlace la reenvíe explícitamente. Para conocer las estrategias de mitigación, consulte Conservar el nombre de host HTTP original entre un proxy inverso y su aplicación web de servidor.

Cuándo usar este patrón

Use este patrón cuando:

  • Una implementación de aplicaciones tiene un problema compartido, como certificados TLS o cifrado.
  • Una característica común entre las implementaciones de aplicaciones puede tener requisitos de recursos diferentes, como recursos de memoria, capacidad de almacenamiento o conexiones de red.
  • Puede que quiera trasladar la responsabilidad sobre cuestiones como la seguridad de la red, la limitación del tráfico u otras cuestiones relacionadas con el perímetro de la red a un equipo más especializado.

Este patrón podría no ser adecuado cuando:

  • La puerta de enlace debe contener reglas de enrutamiento o lógica específicas del servicio que acoplan estrechamente los cambios del servicio back-end a los cambios de configuración de puerta de enlace. Acoplar el nivel de puerta de enlace con servicios internos significa que las actualizaciones de back-end pueden forzar la reimplementación de la puerta de enlace, lo que reduce la independencia de la implementación.
  • La tarea descargada consume pocos recursos y la carga de trabajo es sensible a la latencia. Es posible que el salto de red adicional a través de la puerta de enlace no esté justificado cuando la sobrecarga supere la ventaja de la centralización.
  • Centralizar las cuestiones en una puerta de enlace compartida crea un cuello de botella en la gestión de cambios. Si el ciclo de lanzamiento del equipo de puerta de enlace es más lento que el de los equipos de servicio, la descarga puede retrasar las actualizaciones de certificados, directivas de autenticación o reglas de red.

Diseño de cargas de trabajo

El arquitecto debe evaluar cómo se puede usar el patrón de descarga del gateway en el diseño de su carga de trabajo para abordar los objetivos y principios tratados en los pilares del Azure Well-Architected Framework. Por ejemplo:

Fundamento Cómo apoya este patrón los objetivos de los pilares
Las decisiones de diseño de fiabilidad ayudan a que su carga de trabajo sea resiliente a fallos y garantizan que se recupere a un estado de pleno funcionamiento después de que se produzca un fallo. La descarga de esta responsabilidad en una puerta de enlace reduce la complejidad del código de aplicación en los nodos de back-end. En algunos casos, la descarga reemplaza completamente la funcionalidad por una característica confiable proporcionada por la plataforma.

- RE:01 Simplicidad y eficiencia
Las decisiones de diseño de seguridad ayudan a garantizar la confidencialidad, integridad y disponibilidad de los datos y sistemas de su carga de trabajo. Agregar una puerta de enlace al flujo de solicitud le permite centralizar controles como firewalls de aplicaciones web y directivas TLS de cliente. Cualquier funcionalidad descargada que proporcione la plataforma ya ofrece una mayor seguridad.

- SE:06 Controles de red
- SE:08 Endurecimiento de recursos
La optimización de costos se centra en mantener y mejorar la rentabilidad de la carga de trabajo en la inversión. Este patrón le permite redirigir los costos de los recursos que se gastarían por cada nodo hacia la implementación de la puerta de enlace. Los costos del modelo de procesamiento centralizado suelen ser inferiores a los del modelo distribuido.

- CO:14 Consolidación
La excelencia operativa ayuda a ofrecer calidad de carga de trabajo a través de procesos estandarizados y cohesión de equipos. En este patrón, la configuración y el mantenimiento de la funcionalidad descargada están asociados a un único punto en lugar de requerir la administración de varios nodos. Esta centralización normaliza cómo se aplican las preocupaciones transversales, lo que hace que los cambios operativos ad hoc y rutinarios sean coherentes y predecibles.

- Operaciones estandarizadas de OE:02
Eficiencia del rendimiento ayuda a su carga de trabajo a satisfacer eficientemente las demandas mediante optimizaciones en el escalado, los datos y el código. Agregar una puerta de enlace de descarga al proceso de solicitud le permite usar menos recursos por nodo porque la funcionalidad está centralizada en la puerta de enlace. Puede optimizar la implementación de la funcionalidad descargada independientemente del código de la aplicación. Es probable que la funcionalidad descargada que proporciona la plataforma ya tenga un alto rendimiento.

- PE:03 Selección de servicios

Si este patrón introduce concesiones dentro de un pilar, considérelas en relación con los objetivos de los otros pilares.

Example

Azure Application Gateway WAF_v2 puede implementar este patrón para una aplicación web regional. La puerta de enlace finaliza las conexiones TLS de cliente, aplica las directivas de enrutamiento y WAF y establece nuevas conexiones TLS a los servicios back-end. Este diseño mantiene los problemas de procesamiento de solicitudes compartidos fuera del código de la aplicación back-end.

Application Gateway con descarga de TLS

En el diagrama siguiente se muestra cómo Application Gateway finaliza las conexiones TLS entrantes, inspecciona y filtra el tráfico y lo vuelve a cifrar antes de reenviarlo a un grupo de back-end a través de TLS.

Diagrama que muestra cómo Application Gateway termina el tráfico TLS entrante de los clientes, aplica WAF y reglas de enrutamiento, y vuelve a cifrar el tráfico mediante TLS hacia un grupo de servidores back-end.

Esta arquitectura usa los siguientes componentes de Application Gateway para descargar las funcionalidades compartidas y volver a cifrar el tráfico de back-end:

  • Agente de escucha HTTPS. Un agente de escucha HTTPS en el puerto 443 acepta conexiones TLS entrantes de clientes.
  • Certificado TLS. Un certificado PFX, de origen de Azure Key Vault, está asociado al agente de escucha HTTPS. Application Gateway descifra el tráfico entrante para inspeccionarlo y enrutarlo; a continuación, lo vuelve a cifrar para el grupo de back-end. Los servidores back-end siguen necesitando certificados para las conexiones re cifradas, pero en muchos casos se pueden usar certificados administrados por la plataforma.
  • Grupo de backend. Un grupo de back-end define el conjunto de servidores HTTPS que reciben el tráfico vuelto a cifrar. Los destinos de back-end pueden ser máquinas virtuales, Azure Virtual Machine Scale Sets, direcciones IP o instancias de Azure App Service. Restrinja el acceso al backend para que los clientes no puedan eludir Application Gateway y su directiva WAF conectándose directamente.
  • Configuración HTTP del servidor. Establezca el protocolo de backend en HTTPS y el puerto en el puerto TLS del backend, como 443. Configure la confianza del certificado y un nombre de host que coincida con el certificado de back-end. Para una entidad de certificación privada, configure el certificado raíz de confianza. Para obtener más información, consulte TLS de extremo a extremo con la SKU v2.
  • Regla de enrutamiento. Una regla de enrutamiento de solicitudes asocia el agente de escucha al grupo de back-end y a la configuración HTTP de back-end. Las reglas basadas en rutas pueden dirigir distintas rutas URL a diferentes grupos de servidores de back-end.
  • Política de WAF. La directiva define las reglas administradas y personalizadas que se usan para inspeccionar las solicitudes, incluidas las reglas de Geomatch.

Dado que Application Gateway descifra el tráfico, puede inspeccionar el contenido de la solicitud para el enrutamiento inteligente, reescribir encabezados y direcciones URL HTTP y aplicar reglas waf. A continuación, vuelve a cifrar el tráfico antes de reenviar solicitudes al back-end.

Para obtener instrucciones de configuración, consulte Cifrado TLS de un extremo a otro con Application Gateway.

Tecnologías auxiliares

Los siguientes servicios Azure pueden ayudarle a implementar este patrón:

Pasos siguientes

  • Last updated on