Redes y conectividad para 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 donde los servicios de Azure se unen 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 intencional al definir los sellos regionales como siendo 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 nodos saludables 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 alguna garantía de seguridad para la entrada mediante el firewall de aplicaciones web (WAF).
Descargar un archivo de Visio de esta arquitectura.
Entrada de tráfico
La aplicación definida en la arquitectura es accesible desde 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 back-end o 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 URI llamado es un servicio de salud. 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 Azure Virtual Networks 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.
Azure Load Balancer externo estándar distribuye las solicitudes a la plataforma de aplicaciones. Comprueba que el tráfico que llega al equilibrador de carga se enruta a través de Azure Front Door, lo que garantiza que Azure WAF inspecciona todo el tráfico.
Los agentes de compilación usados para las operaciones e 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, los agentes autohospedados se pueden implementar en la red virtual.
Se requiere la supervisión del rendimiento de 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 que se usa con los sellos 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 tal como se define usa Azure Key Vault para almacenar secretos, como cadenas de conexión y claves de API, para comunicarse de forma segura a través de Internet a los servicios PaaS de Azure. Existen posibles riesgos para exponer la plataforma de aplicaciones a través de Internet para esta comunicación. Los secretos se pueden poner en peligro y se recomienda una mayor seguridad y supervisión de los puntos de conexión públicos.
Consideraciones ampliadas de redes
En esta sección se describen las ventajas y desventajas de los enfoques alternativos para el diseño de red. Las consideraciones de red alternativas y el uso de puntos de conexión privados de Azure son el foco en las secciones siguientes.
Subredes y grupos de seguridad de red
Las subredes dentro de las redes virtuales se pueden usar para segmentar el tráfico dentro del diseño. El aislamiento de subred separa los recursos de las distintas funciones.
Los grupos de seguridad de red se pueden usar para controlar el tráfico permitido dentro y fuera de cada subred. Las reglas que se usan en los grupos de seguridad de red se pueden usar para limitar el tráfico en función de ip, puerto y protocolo para bloquear el tráfico no deseado en la subred.
Puntos de conexión privados: entrada
La versión 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 a una dirección IP privada en 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, introduce otro punto de error. Los puntos de conexión públicos expuestos en las marcas de aplicación ya no son necesarios y ya no se puede acceder a ellos y exponerse a un posible ataque DDoS.
Se debe ponderar la mayor seguridad frente al aumento del esfuerzo de 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 incluye 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. Este proceso aísla los recursos contra ataques externos que podrían provocar interrupciones y restricciones, afectando 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 incluye una sobrecarga de mantenimiento.
Pasos siguientes
Implemente la implementación de referencia para obtener una comprensión completa de los recursos y su configuración usada en esta arquitectura.