Redes y conectividad para las cargas de trabajo críticas
La distribución regional de recursos en la arquitectura de referencia crítica requiere una infraestructura de red sólida.
Se recomienda un diseño distribuido globalmente en el que se unen los servicios de Azure para proporcionar una aplicación de alta disponibilidad. El equilibrador de carga global combinado con stamps regionales proporciona esa garantía mediante una conectividad confiable.
Los stamps regionales son la unidad que se puede implementar de la arquitectura. La capacidad de implementar rápidamente un nuevo stamp proporciona escalabilidad y admite la alta disponibilidad. Los stamps siguen un diseño de red virtual aislada. No se recomienda el tráfico entre stamps. No se requieren emparejamientos de red virtual ni conexiones VPN a otros stamps.
La arquitectura es intencionada al definir los stamps regionales como de corta duración. El estado global de la infraestructura se almacena en los recursos globales.
Se requiere un equilibrador de carga global para enrutar el tráfico a los stamps correctos y proporcionar servicios de seguridad. Debe tener ciertas funcionalidades.
Se requiere el sondeo de estado para que el equilibrador de carga pueda comprobar el estado del origen antes de enrutar el tráfico.
Distribución ponderada del tráfico.
Opcionalmente, debe poder realizar almacenamiento en caché en el perímetro. Además, proporcione algunas garantías de seguridad para la entrada mediante el uso del firewall de aplicaciones web (WAF).
Descargue un archivo Visio de esta arquitectura.
Entrada de tráfico
La aplicación definida en la arquitectura tiene acceso a Internet y tiene varios requisitos:
Una solución de enrutamiento que sea global y que pueda distribuir el tráfico entre los stamps regionales independientes.
Baja latencia en la comprobación de estado y la capacidad de dejar de enviar tráfico a los stamps incorrectos.
Prevención de ataques malintencionados en el perímetro.
Proporcionar capacidades de almacenamiento en caché en el perímetro.
El punto de entrada de todo el tráfico en este diseño se realiza mediante Azure Front Door. Front Door es un equilibrador de carga global que enruta el tráfico HTTP(S) a los back-end y orígenes registrados. Front Door usa sondeos de estado que emiten solicitudes a un identificador URI en cada back-end y origen. En la implementación de referencia, el identificador URI al que se llama es un servicio de estado. El servicio de estado anuncia el estado del stamp. Front Door usa la respuesta para determinar el estado de un stamp individual y enrutar el tráfico a los stamps correctos capaces de atender las solicitudes de las aplicaciones.
La integración de Azure Front Door con Azure Monitor proporciona una supervisión casi en tiempo real del tráfico, la seguridad, las métricas de éxito y error, y las alertas.
Azure Web Application Firewall, integrado con Azure Front Door, se usa para evitar ataques en el perímetro antes de entrar en la red.
Red virtual aislada: API
La API de la arquitectura usa redes virtuales de Azure como límite de aislamiento de tráfico. Los componentes de una red virtual no se pueden comunicar directamente con los componentes de otra red virtual.
Las solicitudes a la plataforma de aplicaciones se distribuyen con una instancia externa de Azure Load Balancer de la SKU Estándar. Hay una comprobación para asegurarse de que el tráfico que llega al equilibrador de carga se enrute mediante Azure Front Door. Esta comprobación garantiza que Azure WAF inspeccione todo el tráfico.
Los agentes de compilación utilizados para las operaciones y la implementación de la arquitectura deben poder acceder a la red aislada. La red aislada se puede abrir para permitir que los agentes se comuniquen. Como alternativa, se pueden implementar agentes autohospedados en la red virtual.
Se requiere la supervisión del rendimiento de la red, el rendimiento de los componentes individuales y el estado de la aplicación.
Dependencia de comunicación de la plataforma de aplicaciones
La plataforma de aplicaciones utilizada con los stamps individuales de la infraestructura tiene los siguientes requisitos de comunicación:
La plataforma de aplicaciones debe poder comunicarse de forma segura con los servicios PaaS de Microsoft.
La plataforma de aplicaciones debe poder comunicarse de forma segura con otros servicios cuando sea necesario.
La arquitectura definida usa Azure Key Vault para almacenar los secretos, como las cadenas de conexión y las claves de API, para comunicarse de forma segura mediante Internet a los servicios PaaS de Azure. Existen posibles riesgos al exponer la plataforma de aplicaciones a Internet para esta comunicación. Se pueden poner en peligro los secretos y se recomienda una mayor seguridad y supervisión de los puntos de conexión públicos.
Consideraciones extendidas sobre redes
En esta sección, se describen las ventajas y desventajas de los enfoques alternativos para el diseño de red. Las consideraciones sobre redes alternativas y el uso de puntos de conexión privados de Azure son el foco en las secciones siguientes.
Subredes y NSG
Las subredes de las redes virtuales se pueden usar para segmentar el tráfico en el diseño. El aislamiento de subred separa los recursos para diferentes funciones.
Los grupos de seguridad de red se pueden usar para controlar el tráfico permitido de entrada y salida en cada subred. Las reglas que se usan en los NSG se pueden usar para limitar el tráfico en función de dirección IP, puerto y protocolo para bloquear el tráfico no deseado en la subred.
Puntos de conexión privados: entrada
La SKU Premium de Front Door admite el uso de puntos de conexión privados de Azure. Los puntos de conexión privados exponen un servicio de Azure en una dirección IP privada de una red virtual. Las conexiones se realizan de forma segura y privada entre servicios sin necesidad de enrutar el tráfico a puntos de conexión públicos.
Azure Front Door Premium y los puntos de conexión privados de Azure permiten clústeres de proceso totalmente privados en los stamps individuales. El tráfico está totalmente bloqueado para todos los servicios PaaS de Azure.
El uso de puntos de conexión privados aumenta la seguridad del diseño. Sin embargo, presenta otro punto de error. Los puntos de conexión públicos expuestos en los stamps de aplicación ya no son necesarios y ya no se puede acceder a ellos y exponerse a un posible ataque DDoS.
Se debe sopesar la mayor seguridad frente al aumento del esfuerzo de la confiabilidad, el costo y la complejidad.
Se deben usar agentes de compilación autohospedados para la implementación del stamp. La administración de estos agentes conlleva una sobrecarga de mantenimiento.
Puntos de conexión privados: plataforma de aplicaciones
Los puntos de conexión privados son compatibles con todos los servicios PaaS de Azure que se usan en este diseño. Con los puntos de conexión privados configurados para la plataforma de aplicaciones, toda la comunicación viajaría mediante la red virtual del stamp.
Los puntos de conexión públicos de los servicios PaaS individuales de Azure se pueden configurar para no permitir el acceso público. Esto aislaría los recursos de los ataques públicos que podrían provocar tiempo de inactividad y limitación, que afectan a la confiabilidad y la disponibilidad.
Se deben usar agentes de compilación autohospedados para la implementación del stamp igual que se mencionó anteriormente. La administración de estos agentes conlleva una sobrecarga de mantenimiento.
Pasos siguientes
Implemente la implementación de referencia para comprender completamente los recursos utilizados en esta arquitectura y su configuración.