Arquitectura de línea base crítica con controles de red
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 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, Zona DNS privada de Azure y otros.
Se recomienda familiarizarse con la línea base antes de continuar con este artículo.
Estrategias clave de diseño
Las estrategias de diseño para la línea base crítica siguen aplicándolas 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 funcionalidades de Firewall de aplicaciones web (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 entrar 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.
Restrinja el tráfico saliente a Internet mediante Azure Firewall. El firewall puede filtrar el tráfico de forma granular mediante el nombre de dominio completo (FQDN).
Equilibrio de 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 deOf-Service (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 las instrucciones generales proporcionadas para cargas de trabajo críticas en cargas de trabajo críticas bien diseñadas para cargas de trabajo críticas. Se recomienda explorar el área de diseño de redes y conectividad para recomendaciones y procedimientos recomendados al definir su propia arquitectura crítica.
Arquitectura
Descargar un archivo de 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 vida y comparten la duración del sistema. Tienen la capacidad de estar disponible globalmente en el contexto de un modelo de implementación de varias regiones. Para obtener 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.
Consulte Cargas de trabajo críticas de misión bien diseñadas: Enrutamiento global del tráfico.
Azure Cosmos DB para 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 se limita 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 se limita a las conexiones de punto de conexión privado autorizadas.
Consulte Cargas de trabajo críticas de misión bien diseñadas: Container Registry.
Recursos regionales
Los recursos regionales se aprovisionan como parte de una marca 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 en otras regiones. Sin embargo, comparten recursos globales entre sí. Para obtener más información, consulte Recursos de sello regional.
El sitio web estático de una cuenta de Azure Storage hospeda una sola aplicación de página (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 se limita a las conexiones de punto de conexión privado autorizadas.
Las redes virtuales de Azure proporcionan 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 API de Kubernetes no se expone a la red pública de Internet. El acceso al servidor de API está limitado a una red privada. Para más información, consulte el artículo Clúster de proceso de esta arquitectura.
Consulte Cargas de trabajo críticas de misión bien diseñadas: 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 se limita a las conexiones de punto de conexión privado autorizadas.
Azure Key Vault se usa como almacén de secretos regional. El acceso se limita a las conexiones de punto de conexión privado autorizadas.
Consulte Cargas de trabajo críticas de misión bien diseñadas: protección de la 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 estar totalmente automatizadas para garantizar una manera coherente de implementar una marca validada.
GitHub todavía se usa para el control de código fuente como una 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 de misión bien diseñadas: 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 recursos globales y recursos regionales se almacenan de forma independiente. No se recomienda un único almacén de observabilidad 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 una 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.
Conjuntos de escalado de máquinas virtuales de Azure para los agentes de compilación privados y las instancias de jump box para ejecutar herramientas en el clúster, como kubectl.
Azure Bastion proporciona acceso seguro a las máquinas virtuales de Jump Box 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 manipulación directa del servicio de orígenes inesperados. Sin embargo, introduce otro posible punto de error y aumenta la complejidad. Considere 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 de la marca. 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 sea 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, necesita un registro DNS. Se recomienda que los registros DNS asociados a los servicios se conserven en zonas DNS privadas de Azure con el servicio Azure DNS. Asegúrese de que el nombre de dominio completo (FQDN) se resuelve en la dirección IP privada.
En esta arquitectura, los puntos de conexión privados se han configurado para Azure Container Registry, Azure Cosmos DB, Key Vault, recursos de Storage 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 Azure Application Insights admiten el uso de puntos de conexión privados. Para más información, consulte Uso de Azure Private Link para conectar redes a Azure Monitor.
Se pueden crear en las mismas subredes o en 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
La SKU premium de Azure Front Door se usa como punto de entrada global para todo el tráfico de cliente entrante. Usa funcionalidades de Firewall de aplicaciones web (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 stamp. Este recurso está delante del controlador de entrada de Kubernetes que se ejecuta en el clúster. Además de este equilibrador de carga privado, AKS crea un servicio 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 stamp a través de Private Link.
Para obtener más información, consulte Funcionamiento de 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 alguna 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 interno inesperado podría dar lugar a riesgos y, posiblemente, a 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 saliente, consulte Control del tráfico de salida para los nodos de clúster en Azure Kubernetes Service (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 frente al 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ímero). Se crean como parte del sello de implementación y se destruyen cuando se destruye el sello. Los recursos de administración comparten la duración de la región y los recursos de stamp.
En esta arquitectura, hay dos redes virtuales: stamp network and operations network .net. 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 la 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 a cada marca es un equilibrador de carga estándar de Azure interno 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 stamp.
Subred de salida de marca
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 la marca 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 NSG que solo permite el tráfico desde 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 salir a través de la subred de salida de marca.
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 provenir de recursos privados, como agentes de compilación autohospedados y jump boxes. 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 red virtual. 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, los jump boxes) 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 los jumpboxes donde el operador puede ejecutar las herramientas. Hay una subred independiente para los jump boxes.
Sin embargo, esos jump boxes también deben protegerse frente al acceso no autorizado. Se debe evitar el acceso directo a los jump boxes 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 jump boxes puede afectar a la productividad del desarrollador, como ejecutar 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 jump box 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 jump boxes (en lugar de máquinas virtuales únicas). Además, la segmentación de red se proporciona a través del uso de subredes. La entrada está restringida a Azure DevOps.
Consideraciones sobre los costos
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 de Azure Firewall en cada sello, provocarán un aumento de los costos. También hay costos adicionales relacionados con los recursos operativos y de mantenimiento. Estos inconvenientes deben tenerse en cuenta cuidadosamente antes de adoptar una versión controlada por 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 DNS privada de Azure 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.