Esta arquitectura proporciona instrucciones para diseñar una carga de trabajo crítica que tenga controles de red estrictos para evitar el acceso público no autorizado desde Internet a cualquiera de los recursos de carga de trabajo. La intención es detener los vectores de ataque en la capa de red para que la confiabilidad general del sistema no se vea afectada. Por ejemplo, un ataque de denegación de servicio distribuido (DDoS), si se deja desactivado, puede hacer que un recurso deje de estar disponible al sobrecargarlo con tráfico ilegítimo.
Se basa en la arquitectura de línea de base crítica, que se centra en maximizar la confiabilidad y la eficacia operativa sin controles de red. Esta arquitectura agrega características para restringir las rutas de acceso de entrada y salida mediante las funcionalidades nativas de nube adecuadas, como Azure Virtual Network (VNet) y puntos de conexión privados, Azure Private Link, Azure DNS privado Zone y otros.
Se recomienda que se familiarice con la línea de base antes de continuar con este artículo.
Estrategias de diseño principales
Las estrategias de diseño para la línea de base crítica se siguen aplicando en este caso de uso. Estas son las consideraciones de red adicionales para esta arquitectura:
Control del tráfico de entrada
La entrada o la comunicación entrante en la red virtual deben restringirse para evitar ataques malintencionados.
Aplique Web Application Firewall funcionalidades (WAF) en el nivel global para detener los ataques en el perímetro de red más cerca del origen de ataque.
Elimine la conectividad pública con los servicios de Azure. Un enfoque consiste en usar puntos de conexión privados.
Inspeccione el tráfico antes de que entre en la red. Los grupos de seguridad de red (NSG) en subredes ayudan a filtrar el tráfico al permitir o denegar el flujo a las direcciones IP y puertos configurados. Este nivel de control también ayuda en el registro pormenorizado.
Control del tráfico de salida
El tráfico de salida de una red virtual a entidades fuera de esa red debe restringirse. La falta de controles puede provocar ataques de filtración de datos por parte de servicios malintencionados de terceros.
Restringir el tráfico de salida a Internet mediante Azure Firewall. El firewall puede filtrar el tráfico de forma granular mediante el nombre de dominio completo (FQDN).
Equilibrio con la seguridad
Hay importantes ventajas cuando se agregan características de seguridad a una arquitectura de carga de trabajo. Es posible que observe algún impacto en el rendimiento, la agilidad operativa e incluso la confiabilidad. Sin embargo, los ataques, como la denegación de servicio (DDoS), la intrusión de datos y otros, pueden dirigirse a la confiabilidad general del sistema y, finalmente, provocar una falta de disponibilidad.
Las estrategias se basan en la orientación general proporcionada para las cargas de trabajo críticas en Cargas de trabajo críticas bien diseñadas. Se recomienda explorar el área de diseño de redes y conectividad para recomendaciones y procedimientos recomendados al definir su propia arquitectura crítica.
Architecture
Descargue un archivo Visio de esta arquitectura.
Los componentes de esta arquitectura se pueden clasificar ampliamente de esta manera. Para obtener documentación del producto sobre los servicios de Azure, consulte Recursos relacionados.
Recursos globales
Los recursos globales son de larga duración y comparten la duración del sistema. Tienen la capacidad de estar disponibles globalmente en el contexto de un modelo de implementación de varias regiones. Para más información, consulte Recursos globales.
La SKU premium de Azure Front Door se usa como equilibrador de carga global para enrutar de forma confiable el tráfico a las implementaciones regionales, que se exponen a través de puntos de conexión privados.
Consulta Cargas de trabajo críticas diseñadas correctamente: Enrutamiento del tráfico global.
Azure Cosmos DB for NoSQL todavía se usa para almacenar el estado fuera del clúster de proceso y tiene opciones de configuración de línea base para la confiabilidad. El acceso está limitado a las conexiones de punto de conexión privado autorizadas.
Azure Container Registry se usa para almacenar todas las imágenes de contenedor con funcionalidades de replicación geográfica. El acceso está limitado a las conexiones de punto de conexión privado autorizadas.
Consulta Cargas de trabajo críticas diseñadas correctamente: Registro de contenedor.
Recursos regionales
Los recursos regionales se aprovisionan como parte de un sello de implementación en una sola región de Azure. Son de corta duración para proporcionar más resistencia, escala y proximidad a los usuarios. Estos recursos no comparten nada con los recursos de otra región. Se pueden quitar o replicar de forma independiente a otras regiones. Sin embargo, comparten recursos globales entre sí. Para obtener más información, consulte Recursos de stamp regional.
El sitio web estático de una cuenta de Azure Storage hospeda una aplicación de página única (SPA) que envía solicitudes a los servicios back-end. Este componente tiene la misma configuración que el front-end de línea base. El acceso está limitado a las conexiones de punto de conexión privado autorizadas.
Azure Virtual Networks proporciona entornos seguros para ejecutar las operaciones de administración y carga de trabajo.
El equilibrador de carga interno es el origen de la aplicación. Front Door usa este origen para establecer la conectividad privada y directa con el back-end mediante Private Link.
Azure Kubernetes Service (AKS) es el orquestador para el proceso de back-end que ejecuta una aplicación y no tiene estado. El clúster de AKS se implementa como un clúster privado. Por lo tanto, el servidor de la API de Kubernetes no está expuesto a la Internet pública. El acceso al servidor de la API está limitado a una red privada. Para más información, consulte el artículo Clúster de proceso de esta arquitectura.
Consulta Cargas de trabajo críticas diseñadas correctamente: Orquestación de contenedores y Kubernetes.
Azure Firewall inspecciona y protege todo el tráfico de salida de los recursos de Azure Virtual Network.
Azure Event Hubs se usa como agente de mensajes. El acceso está limitado a las conexiones de punto de conexión privado autorizadas.
Azure Key Vault se usa como almacén de secretos regional. El acceso está limitado a las conexiones de punto de conexión privado autorizadas.
Consulte Cargas de trabajo críticas diseñadas correctamente: Protección de integridad de datos.
Recursos de canalización de implementación
Las canalizaciones de compilación y versión para una aplicación crítica deben automatizarse completamente para garantizar una manera coherente de implementar una marca validada.
Se sigue utilizando GitHub para el control de código fuente como plataforma basada en git de alta disponibilidad.
Azure Pipelines se elige para automatizar las canalizaciones necesarias para compilar, probar e implementar una carga de trabajo en entornos de preproducción y producción.
Consulte Cargas de trabajo críticas diseñadas correctamente: Procesos de DevOps.
Los grupos de agentes de compilación de Azure DevOps autohospedados se usan para tener más control sobre las compilaciones e implementaciones. Este nivel de autonomía es necesario porque el clúster de proceso y todos los recursos de PaaS son privados, lo que requiere una integración de nivel de red que no es posible en los agentes de compilación hospedados por Microsoft.
Recursos de observabilidad
Los datos de supervisión de los recursos globales y regionales se almacenan de forma independiente. No se recomienda un almacén de observabilidad único y centralizado para evitar un único punto de error. Para obtener más información, consulte Recursos de observabilidad.
Azure Log Analytics se usa como receptor unificado para almacenar registros y métricas para todos los componentes de la aplicación y la infraestructura.
Azure Application Insights se usa como herramienta de administración de rendimiento de aplicaciones (APM) para recopilar todos los datos de supervisión de aplicaciones y almacenarlos directamente en Log Analytics.
Recursos de administración
Un cambio significativo en el diseño de la arquitectura de línea base es el clúster de proceso. En este diseño, el clúster de AKS es privado. Este cambio requiere que se aprovisionan recursos adicionales para obtener acceso.
Azure Virtual Machine Scale Sets para que los agentes de compilación privados y las instancias de Jump Box ejecuten herramientas en el clúster, como kubectl.
Azure Bastion proporciona acceso seguro a las máquinas virtuales jumpbox y elimina la necesidad de que las máquinas virtuales tengan direcciones IP públicas.
Puntos de conexión privados para servicios PaaS
Para procesar las operaciones empresariales o de implementación, la aplicación y los agentes de compilación deben llegar a varios servicios PaaS de Azure que se aprovisionan globalmente, dentro de la región e incluso dentro de la marca. En la arquitectura de línea de base, esa comunicación se realiza a través de los puntos de conexión públicos de los servicios.
En este diseño, esos servicios se han protegido con puntos de conexión privados para quitarlos del acceso público a Internet. Este enfoque reduce el área expuesta a ataques general para mitigar la alteración directa del servicio de orígenes inesperados. Sin embargo, introduce otro posible punto de error y aumenta la complejidad. Tenga en cuenta cuidadosamente los inconvenientes con la seguridad antes de adoptar este enfoque.
Los puntos de conexión privados deben colocarse en una subred dedicada de la red virtual del sello. Las direcciones IP privadas a los puntos de conexión privados se asignan desde esa subred. Básicamente, cualquier recurso de la red virtual puede comunicarse con el servicio llegando a la dirección IP privada. Asegúrese de que el espacio de direcciones es lo suficientemente grande como para dar cabida a todos los puntos de conexión privados necesarios para esa marca.
Para conectarse a través de un punto de conexión privado, se necesita un registro DNS. Se recomienda que los registros DNS asociados a los servicios se conserven en azure DNS privado zonas administradas por Azure DNS. Asegúrese de que el nombre de dominio completo (FQDN) resuelve la dirección IP privada.
En esta arquitectura, se han configurado puntos de conexión privados para Azure Container Registry, Azure Cosmos DB, Key Vault, recursos de almacenamiento y Event Hubs. Además, el clúster de AKS se implementa como un clúster privado, que crea un punto de conexión privado para el servicio de API de Kubernetes en la red del clúster.
Hay dos redes virtuales aprovisionadas en este diseño y ambas tienen subredes dedicadas para contener puntos de conexión privados para todos esos servicios. El diseño de red se describe en Diseño de red virtual.
A medida que agregue más componentes a la arquitectura, considere la posibilidad de agregar más puntos de conexión privados. Por ejemplo, puede agregar restricciones a los recursos de observabilidad. Tanto Azure Log Analytics como Aplicación de Azure Insights admiten el uso de puntos de conexión privados. Para más detalles, consulte Uso de Private Link para conectar redes a Azure Monitor.
Se pueden crear en la misma subred o en subredes diferentes dentro de la misma red virtual. Existen límites en cuanto al número de puntos de conexión privados que se pueden crear en una suscripción. Para más información, consulte Límites de Azure.
Controle aún más el acceso a los servicios mediante el uso de grupos de seguridad de red en la subred.
Entrada privada
Azure Front Door Premium SKU se usa como punto de entrada global para todo el tráfico entrante de clientes. Usa funcionalidades de Web Application Firewall (WAF) para permitir o denegar el tráfico en el perímetro de la red. Las reglas de WAF configuradas impiden ataques incluso antes de que entren en las redes virtuales de marca.
Esta arquitectura también aprovecha la funcionalidad de Front Door para usar Azure Private Link para acceder al origen de la aplicación sin el uso de direcciones IP o puntos de conexión públicos en los back-end. Esto requiere un equilibrador de carga interno en la red virtual de stamp. Este recurso está delante del controlador de entrada de Kubernetes que se ejecuta en el clúster. Además de esta Load Balancer privada, AKS crea un servicio de Private Link, que se usa para la conexión privada desde Front Door.
Una vez establecida la conexión, los puntos de conexión privados de la red de Front Door tienen conectividad directa con el equilibrador de carga y el sitio web estático en la red de marca a través de Private Link.
Para obtener más información, consulte Tutorial de Azure Private Link.
Consulte Cargas de trabajo críticas de misión bien diseñadas: Servicios de entrega de aplicaciones.
Salida restringida
Es posible que las aplicaciones requieran conectividad saliente a Internet. Controlar ese tráfico proporciona una manera de limitar, supervisar y restringir el tráfico de salida. De lo contrario, el acceso inesperado dentro de fuera podría provocar un riesgo y, posiblemente, un estado del sistema no confiable. La salida restringida también puede resolver otros problemas de seguridad, como la filtración de datos.
El uso del firewall y los grupos de seguridad de red (NSG) puede asegurarse de que el tráfico saliente de la aplicación se inspecciona y registra.
En esta arquitectura, Azure Firewall es el único punto de salida y se usa para inspeccionar todo el tráfico saliente que se origina desde la red virtual. Las rutas definidas por el usuario (UDR) se usan en subredes que son capaces de generar tráfico de salida, como la subred de la aplicación.
Para obtener información sobre cómo restringir el tráfico de salida, consulte Controlar el tráfico de salida para los nodos de clúster en el Servicio Azure Kubernetes (AKS).
Diseño de red virtual
Aísle los recursos regionales y los recursos de administración en redes virtuales independientes. Tienen características, propósitos y consideraciones de seguridad distintas.
Tipo de tráfico: los recursos regionales, que participan en el procesamiento de operaciones empresariales, necesitan controles de seguridad más altos. Por ejemplo, el clúster de proceso debe protegerse del tráfico directo de Internet. Los recursos de administración solo se aprovisionan para acceder a los recursos regionales para las operaciones.
Duración: las duraciones esperadas de esos recursos también son diferentes. Se espera que los recursos regionales sean de corta duración (efímeros). Se crean como parte del sello de implementación y se destruyen cuando se destruye el sello. Los recursos de administración comparten el tiempo de vida de la región y viven más que los recursos del sello.
En esta arquitectura, hay dos redes virtuales: stamp network y operations network. Cree un aislamiento adicional dentro de cada red virtual mediante subredes y grupos de seguridad de red (NSG) para proteger la comunicación entre las subredes.
Consulte Cargas de trabajo críticas de misión bien diseñadas: Redes virtuales aisladas.
Red virtual de stamp regional
La marca de implementación aprovisiona una red virtual en cada región.
La red virtual se divide en estas subredes principales. Todas las subredes tienen grupos de seguridad de red (NSG) asignados para bloquear cualquier acceso no autorizado desde la red virtual. Los grupos de seguridad de red restringirán el tráfico entre la subred de la aplicación y otros componentes de la red.
Subred de aplicación
Los grupos de nodos de clúster de AKS están aislados en una subred. Si necesita aislar aún más el grupo de nodos del sistema del grupo de nodos de trabajo, puede colocarlos en subredes independientes.
Subred de entrada de stamp
El punto de entrada de cada stamp es un Standard Load Balancer interno de Azure que se coloca en una subred dedicada. El servicio Private Link que se usa para la conexión privada desde Front Door también se coloca aquí.
Ambos recursos se aprovisionan como parte de la implementación de stamps.
Subred de salida de sellos
Azure Firewall se coloca en una subred independiente e inspecciona el tráfico de salida de la subred de la aplicación mediante una ruta definida por el usuario (UDR).
Subred de puntos de conexión privados
La subred de la aplicación tendrá que acceder a los servicios PaaS en el sello regional, Key Vault y otros. Además, se necesita acceso a recursos globales, como el registro de contenedor. En esta arquitectura, todos los servicios PaaS están bloqueados y solo se pueden acceder a través de puntos de conexión privados. Por lo tanto, se crea otra subred para esos puntos de conexión. El acceso entrante a esta subred está protegido por el grupo de seguridad de red que solo permite el tráfico de la aplicación.
Puede agregar más restricciones mediante la compatibilidad con UDR para puntos de conexión privados, de modo que este tráfico también pueda salida a través de la subred de salida de stamp.
Red virtual de operaciones
El tráfico operativo está aislado en una red virtual independiente. Dado que el servicio de API del clúster de AKS es privado en esta arquitectura, todo el tráfico operativo y de implementación también debe proceder de recursos privados, como agentes de compilación autohospedados y jumpboxes. Esos recursos se implementan en una red virtual independiente con conectividad directa a los recursos de la aplicación a través de su propio conjunto de puntos de conexión privados. Los agentes de compilación y los jumpbox están en subredes independientes.
En lugar de usar puntos de conexión privados, un enfoque alternativo consiste en usar el emparejamiento de redes virtuales. Sin embargo, el emparejamiento agrega complejidad que puede ser difícil de administrar especialmente cuando las redes virtuales están diseñadas para ser efímeras.
Los agentes de compilación (y, opcionalmente, jumpboxes) necesitan acceder a los servicios PaaS que se encuentran globalmente y dentro de la marca regional. De forma similar a la red virtual de marca regional, se crea una subred dedicada para los puntos de conexión privados a los servicios PaaS necesarios. El grupo de seguridad de red de esta subred garantiza que el tráfico de entrada solo se permita desde las subredes de administración e implementación.
Operaciones de administración
Un caso de uso típico es cuando un operador necesita acceder al clúster de proceso para ejecutar comandos y herramientas de administración. No se puede acceder directamente al servicio de API de un clúster privado. Por eso se aprovisionan jumpboxes donde el operador puede ejecutar las herramientas. Hay una subred independiente para los jumpboxes.
Sin embargo, esos jumpboxes también deben protegerse del acceso no autorizado. Se debe evitar el acceso directo a los jumpboxes abriendo puertos RDP/SSH. Azure Bastion se recomienda para este propósito y requiere una subred dedicada en esta red virtual.
Precaución
La conectividad a través de Azure Bastion y jumpboxes puede tener un impacto en la productividad del desarrollador, como la ejecución de herramientas de depuración requiere un proceso adicional. Tenga en cuenta estos impactos antes de decidir reforzar la seguridad de la carga de trabajo crítica.
Puede restringir aún más el acceso a la subred jumpbox mediante un grupo de seguridad de red que solo permita el tráfico entrante desde la subred de Bastion a través de SSH.
Operaciones de implementación
Para compilar canalizaciones de implementación, debe aprovisionar un proceso adicional para ejecutar agentes de compilación. Estos recursos no afectarán directamente a la disponibilidad en tiempo de ejecución de la carga de trabajo, pero un error de confiabilidad puede poner en peligro la capacidad de implementar o atender el entorno crítico. Por lo tanto, las características de confiabilidad deben ampliarse a estos recursos.
Esta arquitectura usa conjuntos de escalado de máquinas virtuales para agentes de compilación y jumpboxes (en lugar de máquinas virtuales únicas). Además, la segmentación de red se proporciona mediante el uso de subredes. La entrada está restringida a Azure DevOps.
Consideraciones sobre el costo
Hay un impacto significativo en el costo de las cargas de trabajo críticas. En esta arquitectura, las opciones tecnológicas, como el uso de la SKU Premium de Azure Front Door y el aprovisionamiento Azure Firewall en cada stamp, provocarán un aumento de los costos. También hay costos adicionales relacionados con el mantenimiento y los recursos operativos. Estos inconvenientes deben tenerse en cuenta cuidadosamente antes de adoptar una versión controlada por la red de la arquitectura de línea de base.
Implementación de esta arquitectura
Los aspectos de red de esta arquitectura se implementan en la implementación conectada crítica.
Nota:
La implementación conectada está pensada para ilustrar una carga de trabajo crítica que se basa en los recursos de la organización, se integra con otras cargas de trabajo y usa servicios compartidos. Se basa en esta arquitectura y usa los controles de red descritos en este artículo. Sin embargo, el escenario conectado supone que la red privada virtual o la zona de Azure DNS privado ya existen dentro de la suscripción de conectividad de zonas de aterrizaje de Azure.
Pasos siguientes
Para más información sobre las decisiones de diseño tomadas en esta arquitectura, revise el área de diseño de redes y conectividad para cargas de trabajo críticas en Azure Well-architected Framework.
Recursos relacionados
Para obtener documentación del producto sobre los servicios de Azure usados en esta arquitectura, consulte estos artículos.