Arquitectura de línea de base de Azure Virtual Machines en una zona de aterrizaje de Azure

La arquitectura de este artículo se expande en la arquitectura de línea de base de máquina virtual (VM) para abordar los cambios y expectativas al implementarla en una zona de aterrizaje de Azure.

En el ejemplo de este artículo, una organización quiere que una carga de trabajo basada en máquinas virtuales use recursos federados que administra un equipo de plataforma de forma centralizada. Estos recursos incluyen recursos de red para la conectividad entre locales, la administración del acceso a identidades y las directivas. En este ejemplo se supone que la organización adopta zonas de aterrizaje de Azure para aplicar una gobernanza coherente y una rentabilidad en varias cargas de trabajo.

Como propietario de la carga de trabajo, puede descargar la gestión de los recursos compartidos a los equipos centrales, de modo que pueda centrarse en los esfuerzos de desarrollo de la carga de trabajo. En este artículo se presenta la perspectiva del equipo de carga de trabajo. Se especifican las recomendaciones dirigidas al equipo de la plataforma.

Diseño del artículo

Arquitectura	Decisión de diseño	Enfoque del Marco de buena arquitectura de Azure
▪ Diagrama de la arquitectura ▪ Recursos de carga de trabajo ▪ Recursos federados	▪ Configuración de suscripción ▪ Requisitos de red ▪ Cambios de diseño de red desde la línea de base ▪ Supervisión ▪ Cumplimiento de revisiones ▪ Gobernanza organizativa ▪ Administración de cambios	▪ Confiabilidad ▪ Seguridad ▪ Optimización de costos

Arquitectura

Descargue un archivo Visio de esta arquitectura.

Componentes

Todas las arquitecturas de zona de aterrizaje de Azure tienen una separación de propiedad entre el equipo de la plataforma y el equipo de carga de trabajo. Los arquitectos de aplicaciones y los equipos de DevOps deben conocer bien esta división de responsabilidad para saber lo que está bajo su influencia directa o control y lo que no.

Recursos propiedad del equipo de carga de trabajo

Los siguientes recursos permanecen prácticamente sin cambios desde la arquitectura de línea de base.

• Azure Virtual Machines es la plataforma de aplicaciones. Los recursos de proceso se distribuyen entre zonas de disponibilidad.

• Azure Load Balancer se usa para equilibrar la carga privada del tráfico de las máquinas virtuales de front-end a las máquinas virtuales de back-end. El equilibrador de carga distribuye el tráfico a las máquinas virtuales entre zonas.

• Azure Application Gateway se usa como proxy inverso para enrutar las solicitudes de usuario a las máquinas virtuales front-end. La SKU seleccionada también se usa para hospedar Azure Web Application Firewall para proteger las máquinas virtuales front-end frente al tráfico potencialmente malintencionado.

• Azure Key Vault se utiliza para almacenar los secretos de aplicación y los certificados.

• Azure Monitor, Log Analytics y Application Insights se usan para recopilar, almacenar y visualizar datos de observabilidad.

• Azure Policy se usa para aplicar directivas específicas de la carga de trabajo.

El equipo de carga de trabajo mantiene y cumple los siguientes recursos y responsabilidades.

• Subredes de red virtual de radio y los grupos de seguridad de red (NSG) que se colocan en esas subredes para mantener la segmentación y controlar el flujo de tráfico.

• Puntos de conexión privados para proteger la conectividad con soluciones de plataforma como servicio (PaaS) y las zonas de DNS privado necesarias para esos puntos de conexión.

• Azure Managed Disks almacena los archivos de registro en los servidores back-end y los datos se conservan incluso cuando se reinician las máquinas virtuales. Los servidores front-end tienen discos conectados que puede usar para implementar la aplicación sin estado.

Recursos que son propiedad del equipo de la plataforma

El equipo de la plataforma posee y mantiene estos recursos centralizados. En esta arquitectura se supone que estos recursos están aprovisionados previamente y se consideran dependencias.

• Azure Firewall en la red del concentrador se usa para inspeccionar y restringir el tráfico de salida. Este componente reemplaza el equilibrador de carga estándar en la arquitectura de línea de base, que no proporciona restricciones en el tráfico saliente a Internet.

• Azure Bastion en la red del concentrador proporciona acceso operativo seguro a las máquinas virtuales de carga de trabajo. En la arquitectura de línea de base, el equipo de carga de trabajo posee este componente.

• La red virtual de radio es donde se implementa la carga de trabajo.

• Las rutas definidas por el usuario (UDR) se usan para forzar la tunelización a la red del concentrador.

• Las restricciones de gobernanza basadas en Azure Policy y DeployIfNotExists (DINE) forman parte de la suscripción de carga de trabajo.

Configuración de suscripción

En un contexto de zona de aterrizaje, el equipo de carga de trabajo debe informar al equipo de la plataforma de sus requisitos específicos.

El equipo de carga de trabajo debe incluir información detallada sobre el espacio de red que necesita la carga de trabajo para que el equipo de la plataforma pueda asignar los recursos necesarios. El equipo determina los requisitos y el equipo de la plataforma determina las direcciones IP que se van a asignar dentro de la red virtual y el grupo de administración al que se asigna la suscripción.

El equipo de la plataforma asigna un grupo de administración adecuado en función de la importancia empresarial y los requisitos técnicos de la carga de trabajo, por ejemplo, si una carga de trabajo se expone a Internet. La organización determina la configuración de estos grupos de administración y el equipo de la plataforma los implementa.

Por ejemplo, los grupos de administración de los escenarios de aplicación para la arquitectura de línea de base se consideran:

• Aplicaciones privadas, como aplicaciones internas de línea de negocio o soluciones comerciales listas para usar (COTS), que a menudo se encuentran bajo el grupo de administración Corp de zonas de aterrizaje de Azure.

• Aplicaciones públicas, como en aplicaciones accesibles desde Internet, que a menudo están bajo el grupo de administración Corp o en línea.

El equipo de la plataforma también es responsable de configurar una suscripción o un grupo de suscripciones para la implementación de la carga de trabajo.

En las secciones siguientes se proporcionan instrucciones sobre la configuración de la suscripción inicial. Sin embargo, el equipo de plataforma normalmente realiza cambios en los servicios centralizados para abordar los requisitos que faltan o los que se han modificado. Los cambios de plataforma tienen un efecto más amplio en todos los equipos de carga de trabajo.

Por lo tanto, el equipo de la plataforma debe asegurarse de que todas las cargas de trabajo de máquina virtual están preparadas para cualquier cambio y deben tener en cuenta el ciclo de vida de la solución basada en máquinas virtuales y el ciclo de pruebas. Para obtener más información, consulte Administración de cambios a lo largo del tiempo.

Requisitos y cumplimientos de cargas de trabajo

El equipo de carga de trabajo y los equipos de la plataforma comparten dos responsabilidades principales: la asignación de grupos de administración y la configuración de red. Para esta arquitectura, tenga en cuenta los siguientes requisitos de red que debe comunicar al equipo de la plataforma. Use estos puntos como ejemplos para comprender la discusión y la negociación entre los dos equipos al implementar una arquitectura similar.

• El número de redes virtuales de radio: en esta arquitectura, solo se requiere un radio dedicado. Los recursos implementados no necesitan abarcar varias redes y se colocan dentro de una sola red virtual.

• El tamaño de la red de radio: tenga en cuenta los requisitos operativos y el crecimiento esperado de la carga de trabajo. Por ejemplo, si planea implementar actualizaciones de color azul/verde o de valor controlado, el tamaño máximo debe tener en cuenta el espacio que requieren las implementaciones en paralelo.

  Los cambios futuros podrían requerir más espacio IP, lo que puede desajustar la asignación actual. La integración de estos espacios puede introducir una complejidad adicional. Sea proactivo y solicite por adelantado suficientes recursos de red para asegurarse de que el espacio asignado puede acomodar futuras ampliaciones.

• La región de implementación: es importante especificar las regiones donde se implementará la carga de trabajo. El equipo de la plataforma puede usar esta información para asegurarse de que las redes virtuales de radio y concentrador se aprovisionan en la misma región. Las redes de diferentes regiones pueden provocar problemas de latencia debido a los límites regionales de cruce de tráfico y también pueden incurrir en costos adicionales de ancho de banda.

• Las características de la carga de trabajo y las opciones de diseño: comunique las opciones de diseño, los componentes y las características al equipo de la plataforma. Por ejemplo, si espera que la carga de trabajo genere un gran número de conexiones simultáneas a Internet (fragmentadas), el equipo de la plataforma debe asegurarse de que hay suficientes puertos disponibles para evitar el agotamiento. Pueden agregar direcciones IP al firewall centralizado para admitir el tráfico o configurar una puerta de enlace de traducción de direcciones de red (NAT) para enrutar el tráfico a través de una ruta alternativa.

  Por el contrario, si espera que la carga de trabajo genere un tráfico de red mínimo (ruido de fondo), el equipo de la plataforma debe usar recursos de forma eficaz en toda la organización.

  El equipo de la plataforma debe comprender claramente las dependencias. Por ejemplo, la carga de trabajo podría necesitar acceso a una base de datos que otro equipo posee o la carga de trabajo podría tener tráfico entre entornos locales. ¿La carga de trabajo tiene dependencias fuera de Azure? Es importante que el equipo de la plataforma conozca esta información.

• La configuración del firewall: el equipo de la plataforma debe tener en cuenta el tráfico que sale de la red de radio y que se tunelizará a la red del concentrador. El firewall del concentrador no puede bloquear ese tráfico.

  Por ejemplo, si la carga de trabajo necesita acceder a las actualizaciones de Windows para mantenerse revisadas, un firewall no debe bloquear estas actualizaciones. Del mismo modo, si hay agentes de supervisión, que acceden a puntos de conexión específicos, un firewall no debe bloquear ese tráfico porque puede interrumpir la supervisión de los datos de la carga de trabajo. Es posible que la aplicación requiera acceso a puntos de conexión de terceros. Independientemente, use un firewall centralizado para distinguir entre el tráfico esperado e injustificado.

• Acceso de operador: si hay grupos de seguridad de Microsoft Entra ID que los operadores usan para acceder a las máquinas virtuales a través de Azure Bastion, informe al equipo de la plataforma. Azure Bastion suele ser un recurso central. Es fundamental asegurarse de que los grupos de seguridad y las máquinas virtuales admiten el protocolo seguro.

  Además, informe al equipo de la plataforma sobre los intervalos IP que contienen las máquinas virtuales. Esta información es necesaria para configurar los grupos de seguridad de red en torno a Azure Bastion en la red del concentrador.

• Las direcciones IP públicas: informe al equipo de la plataforma sobre el perfil de tráfico de entrada, incluidas las direcciones IP públicas previstas. En esta arquitectura, solo el tráfico de origen de Internet tiene como destino la dirección IP pública en Application Gateway. El equipo de la plataforma debe informar al equipo de carga de trabajo si estas direcciones IP están en un plan de Azure DDoS Protection o si es responsabilidad del equipo de carga de trabajo.

  En esta arquitectura, hay otra dirección IP pública para el acceso operativo a través de Azure Bastion. El equipo de la plataforma posee esta dirección IP pública y está inscrito en un servicio, como DDoS Protection, que también administra el equipo de la plataforma.

Opciones de diseño de máquina virtual

Las selecciones de disco y SKU de máquina virtual siguen siendo las mismas que la arquitectura de línea de base.

Una organización puede imponer requisitos de cumplimiento al equipo de carga de trabajo que exige el uso de imágenes de máquina virtual específicas. Dados estos requisitos, el equipo de la plataforma podría administrar un conjunto de imágenes estandarizadas, a menudo denominadas imágenes maestras, que se crean para su uso en toda la organización.

El equipo de la plataforma puede usar una oferta administrada, como Azure Compute Gallery o un repositorio privado para almacenar imágenes de sistema operativo aprobadas o artefactos de carga de trabajo. Al elegir una imagen del sistema operativo para máquinas virtuales, consulte al equipo de la plataforma sobre los orígenes de las imágenes, la frecuencia de actualización y las expectativas de uso. Asegúrese también de que las imágenes pueden cumplir los requisitos empresariales necesarios que cumple la carga de trabajo.

Redes

En la arquitectura de línea de base, la carga de trabajo se aprovisiona en una sola red virtual. El equipo de carga de trabajo administra la red virtual.

En esta arquitectura, el equipo de la plataforma determina la topología de red. En esta arquitectura se asume la topología en estrella tipo hub-and-spoke.

Descargue un archivo Visio de esta arquitectura.

• Red virtual del concentrador: un concentrador regional contiene servicios centralizados que se comunican con recursos de carga de trabajo en la misma región. Para obtener más información, consulte Recursos propiedad del equipo de la plataforma. Se recomienda colocar el concentrador en la suscripción de conectividad.

• Red virtual de radio: en esta arquitectura, la única red virtual de la arquitectura de línea de base es la red de radio. Está emparejada con la red del concentrador, que contiene los servicios centralizados. El equipo de la plataforma posee y administra esta red de radios. Esta red contiene los recursos de carga de trabajo. El equipo de carga de trabajo posee los recursos de esta red, incluidas sus subredes.

Asegúrese de comunicar los requisitos de carga de trabajo al equipo de la plataforma y revisarlos periódicamente.

Subredes de la red virtual

En la red virtual de radio, el equipo de carga de trabajo crea y asigna las subredes. La colocación de controles para restringir el tráfico dentro y fuera de las subredes ayuda a proporcionar segmentación. Esta arquitectura usa la misma topología de subred que la arquitectura de línea de base, que tiene subredes dedicadas para Application Gateway, máquinas virtuales de front-end, equilibrador de carga, máquinas virtuales de back-end y puntos de conexión privados.

Al implementar la carga de trabajo en una zona de aterrizaje de Azure, todavía tiene que implementar controles de red. Las organizaciones podrían imponer restricciones para protegerse contra la exfiltración de datos y garantizar la visibilidad para el centro de operaciones de seguridad (SOC) central y el equipo de red de TI.

Con este enfoque, el equipo de la plataforma puede optimizar el gasto general de la organización mediante el uso de servicios centralizados, en lugar de implementar controles de seguridad redundantes para cada carga de trabajo de toda la organización. En esta arquitectura, Azure Firewall es un ejemplo de un servicio central. No es rentable ni práctico que cada equipo de carga de trabajo administre su propia instancia de firewall. Se recomienda un enfoque centralizado para la administración del firewall.

Tráfico de entrada

El flujo de tráfico de entrada sigue siendo el mismo que la arquitectura de línea de base.

El propietario de la carga de trabajo es responsable de los recursos relacionados con la entrada pública de Internet en la carga de trabajo. Por ejemplo, en esta arquitectura, Application Gateway y su dirección IP pública se colocan en la red de radio y no en la red del concentrador. Algunas organizaciones pueden colocar recursos con tráfico de entrada en una suscripción de conectividad mediante una implementación centralizada desmilitarizada (DMZ). La integración con esa topología específica está fuera del ámbito de este artículo.

Tráfico de salida

En la arquitectura de línea de base, los conjuntos de escalado de máquinas virtuales de carga de trabajo acceden a la red pública de Internet a través de Azure Load Balancer, pero ese tráfico no está restringido.

Ese diseño es diferente en esta arquitectura. Todo el tráfico que sale de la red virtual de radio se enruta a través de la red del concentrador emparejado a través de un firewall de salida. Una ruta está conectada a todas las subredes posibles de la red de radios que dirige todo el tráfico de direcciones IP no encontradas en la red virtual local (0.0.0.0.0/0) al Azure Firewall del concentrador.

Descargue un archivo Visio de esta arquitectura.

La comunicación de carga de trabajo con el punto de conexión privado para el acceso a Key Vault sigue siendo la misma que la arquitectura de línea de base. En el diagrama anterior se ha omitido esta ruta para mayor brevedad.

El equipo de carga de trabajo debe identificar, documentar y comunicar todos los flujos de tráfico salientes necesarios para las operaciones de infraestructura y carga de trabajo. El equipo de la plataforma permite el tráfico necesario y es probable que se deniegue todo el tráfico de salida no comunicado.

Controlar el tráfico de salida es más que asegurarse de que se permita el tráfico esperado. También se trata de asegurarse de que solo se permita el tráfico esperado. Es probable que el tráfico de salida no comunicado se deniegue por defecto, pero es en el mejor interés de seguridad de la carga de trabajo asegurarse de que el tráfico está correctamente enrutado.

Comunique los requisitos de tráfico de salida únicos al equipo de la plataforma. Por ejemplo, si la carga de trabajo establece numerosas conexiones simultáneas a puntos de conexión de red externos, informe al equipo de la plataforma. A continuación, el equipo de la plataforma puede aprovisionar una implementación adecuada de Azure NAT Gateway o agregar más direcciones IP públicas en el firewall regional para la mitigación.

Es posible que su organización tenga requisitos que desalienten el uso de patrones de arquitectura, que usan direcciones IP públicas propiedad de la carga de trabajo para la salida. En ese caso, puede usar Azure Policy para denegar direcciones IP públicas en tarjetas de interfaz de red (NIC) de máquina virtual y cualquier otra dirección IP pública, aparte de los puntos de entrada conocidos.

Zonas de DNS privado

Las arquitecturas que usan puntos de conexión privados necesitan zonas de DNS privado para trabajar con el proveedor de DNS. El equipo de carga de trabajo debe tener un conocimiento claro de los requisitos y la administración de zonas de DNS privado en la suscripción que proporciona el equipo de la plataforma. Las zonas de DNS privado normalmente se administran a gran escala con directivas DINE, lo que permite que Azure Firewall funcione como proxy DNS confiable y admita reglas de red de nombres de dominio completos (FQDN).

En esta arquitectura, el equipo de la plataforma garantiza la resolución de DNS privado confiable para los puntos de conexión de vínculo privado. Colabore con su equipo de la plataforma para comprender sus expectativas.

Pruebas de conectividad

En el caso de las arquitecturas basadas en máquinas virtuales, hay varias herramientas de prueba que pueden ayudar a determinar problemas de línea de visión, enrutamiento y DNS de red. Puede usar herramientas de solución de problemas tradicionales, como netstat, nslookup o tcping. Además, puede examinar la configuración del protocolo de configuración dinámica de host (DHCP) y DNS del adaptador de red. Si hay NIC, tiene más funcionalidades de solución de problemas que le permiten realizar comprobaciones de conectividad mediante Azure Network Watcher.

Acceso de operador

Al igual que la arquitectura de línea de base, el acceso operativo a través de Azure Bastion se admite en esta arquitectura.

Sin embargo, la arquitectura de línea de base implementa Azure Bastion como parte de la carga de trabajo. Para una organización típica que adopta zonas de aterrizaje de Azure, implementa Azure Bastion como recursos centrales para cada región. El equipo de la plataforma posee y mantiene Azure Bastion y todas las cargas de trabajo de la organización la comparten. Para demostrar ese caso de uso en esta arquitectura, Azure Bastion se encuentra en la red del concentrador, en la suscripción de conectividad.

Identidad de operador

Esta arquitectura usa la misma extensión de autenticación que la arquitectura de línea de base.

Comience siempre con el principio de privilegios mínimos y acceso granular a una tarea en lugar de acceso duradero. En el contexto de la zona de aterrizaje, aproveche la compatibilidad just-in-time (JIT) que administra el equipo de la plataforma.

Cumplimiento de revisiones y actualizaciones del sistema operativo

La arquitectura de línea de base describe un enfoque autónomo para aplicar revisiones y actualizaciones. Cuando la carga de trabajo se integra con zonas de aterrizaje, ese enfoque podría cambiar. El equipo de la plataforma podría dictar las operaciones de aplicación de revisiones para que todas las cargas de trabajo sean compatibles con los requisitos de la organización.

Asegúrese de que el proceso de aplicación de revisiones incluya todos los componentes que agregue a la arquitectura. Por ejemplo, si decide agregar máquinas virtuales del agente de compilación para automatizar la implementación, el escalado y la administración de aplicaciones, esas máquinas virtuales deben cumplir los requisitos de la plataforma.

Supervisión

La plataforma de zona de aterrizaje de Azure proporciona recursos de observabilidad compartidos como parte de la suscripción de administración. Sin embargo, se recomienda aprovisionar sus propios recursos de supervisión para facilitar las responsabilidades de propiedad de la carga de trabajo. Este enfoque es coherente con la arquitectura de línea de base.

El equipo de carga de trabajo aprovisiona los recursos de supervisión, entre los que se incluyen:

• Application Insights como servicio de supervisión del rendimiento de la aplicación (APM) para el equipo de carga de trabajo.

• El área de trabajo de Log Analytics como receptor unificado de todos los registros y métricas que se recopilan de los recursos de Azure propiedad de la carga de trabajo y del código de la aplicación.

Descargue un archivo Visio de esta arquitectura.

De forma similar a la línea de base, todos los recursos están configurados para enviar registros de Azure Diagnostics al área de trabajo de Log Analytics que el equipo de carga de trabajo aprovisiona como parte de la implementación de la infraestructura como código (IaC) de los recursos. Es posible que también tenga que enviar registros a un área de trabajo central de Log Analytics. En las zonas de aterrizaje de Azure, esa área de trabajo se encuentra en la suscripción de administración.

El equipo de la plataforma también puede tener directivas DINE que pueden usar para configurar Diagnostics para enviar registros a sus suscripciones de administración centralizadas. Es importante asegurarse de que la implementación no restringe los flujos de registro adicionales.

Correlación de datos de varios receptores

Los registros y las métricas de la carga de trabajo, así como sus componentes de infraestructura, se almacenan en el área de trabajo de Log Analytics de la carga de trabajo. Sin embargo, los registros y las métricas que generan los servicios centralizados, como Azure Firewall, Microsoft Entra ID y Azure Bastion, se almacenan en un área de trabajo central de Log Analytics. La correlación de datos de varios receptores puede ser una tarea compleja.

Los datos correlacionados se suelen usar durante la respuesta a incidentes. Si hay un problema con la correlación de datos de varios receptores, asegúrese de que el runbook de evaluación para esta arquitectura lo aborda e incluye puntos de contacto organizativos si el problema se extiende más allá de los recursos de carga de trabajo. Los administradores de la carga de trabajo pueden necesitar ayuda de los administradores de la plataforma para correlacionar las entradas de registro de la red de la empresa, la seguridad u otros servicios de la plataforma.

Azure Policy

Es probable que el equipo de la plataforma aplique directivas que afecten a la implementación de la carga de trabajo. A menudo aplican directivas de DINE para controlar las implementaciones automatizadas en una suscripción de zona de aterrizaje de aplicaciones. Las directivas DINE pueden modificar los recursos de carga de trabajo o agregar recursos a la implementación, lo que puede dar lugar a una discrepancia entre los recursos que se implementan mediante declaración a través de la plantilla de carga de trabajo y los recursos que realmente usan los procesamientos. Una solución típica es corregir esos cambios con enfoques imperativos, que no son ideales.

Para evitar esa discrepancia, incorpore y pruebe previamente los cambios iniciados por la plataforma en las plantillas de IaC. Si el equipo de la plataforma usa directivas de Azure que entran en conflicto con los requisitos de la aplicación, puede negociar una resolución con el equipo de la plataforma.

Gestionar los cambios a lo largo del tiempo

Los servicios y operaciones proporcionados por la plataforma se consideran dependencias externas en esta arquitectura. El equipo de la plataforma sigue aplicando cambios, incorporando usuarios y aplicando controles de costos. Es posible que el equipo de la plataforma que atiende a la organización no dé prioridad a las cargas de trabajo individuales. Los cambios en esas dependencias, tanto si son cambios de imagen maestra, modificaciones del firewall, aplicación automatizada de revisiones o cambios de reglas, pueden afectar a varias cargas de trabajo.

Por lo tanto, los equipos de carga de trabajo y plataforma deben comunicarse de forma eficaz y oportuna para administrar todas las dependencias externas. Es importante probar los cambios para que no afecten negativamente a las cargas de trabajo.

Cambios de plataforma que afectan a la carga de trabajo

En esta arquitectura, el equipo de la plataforma administra los siguientes recursos. Los cambios en estos recursos pueden afectar potencialmente a los objetivos de confiabilidad, seguridad, operaciones y rendimiento de la carga de trabajo. Es importante evaluar estos cambios antes de que el equipo de la plataforma los implemente para determinar cómo afectan a la carga de trabajo.

• Directivas de Azure: los cambios en las directivas de Azure pueden afectar a los recursos de carga de trabajo y sus dependencias. Por ejemplo, puede haber cambios directos en la directiva o el movimiento de la zona de aterrizaje en una nueva jerarquía de grupos de administración. Estos cambios pueden pasar desapercibidos hasta que haya una nueva implementación, por lo que es importante probarlos exhaustivamente.

• Reglas de firewall: las modificaciones en las reglas de firewall pueden afectar a la red virtual o las reglas de la carga de trabajo que se aplican ampliamente en todo el tráfico. Estas modificaciones pueden provocar el bloqueo del tráfico e incluso fallos silenciosos en los procesos, como la aplicación fallida de revisiones del sistema operativo. Estos posibles problemas se aplican tanto al firewall de Azure de salida como a las reglas de NSG aplicadas a Azure Virtual Network Manager.

• Recursos compartidos: los cambios en la SKU o las características de los recursos compartidos pueden afectar a la carga de trabajo.

• Enrutamiento en la red del concentrador: los cambios en la naturaleza transitiva del enrutamiento en el concentrador pueden afectar potencialmente a la funcionalidad de la carga de trabajo si una carga de trabajo depende del enrutamiento a otras redes virtuales.

• Host de Azure Bastion: los cambios en la disponibilidad o configuración del host de Azure Bastion pueden afectar a las operaciones de carga de trabajo. Asegúrese de que los cambios en el patrón de acceso al jump box tengan un acceso rutinario, ad hoc y de emergencia eficaz.

• Cambios de propiedad: comunique los cambios de propiedad y puntos de contacto al equipo de carga de trabajo, ya que pueden afectar a las solicitudes de administración y soporte técnico de la carga de trabajo.

Cambios de la carga de trabajo que afectan a la plataforma

Los ejemplos siguientes son cambios de la carga de trabajo en esta arquitectura que debe comunicar al equipo de la plataforma. Es importante que el equipo de la plataforma valide los objetivos de confiabilidad, seguridad, operaciones y rendimiento del servicio de plataforma frente a los nuevos cambios del equipo de carga de trabajo antes de que entren en vigor.

• Salida de red: supervise cualquier aumento significativo de la salida de red para evitar que la carga de trabajo se convierta en un vecino ruidoso en los dispositivos de red. Este problema puede afectar potencialmente a los objetivos de rendimiento o confiabilidad de otras cargas de trabajo.

• Acceso público: los cambios en el acceso público a los componentes de carga de trabajo pueden requerir más pruebas. El equipo de la plataforma podría reubicar la carga de trabajo en otro grupo de administración.

• Clasificación de importancia empresarial: si hay cambios en los acuerdos de nivel de servicio (SLA) de la carga de trabajo, es posible que necesite un nuevo enfoque de colaboración entre los equipos de plataforma y de carga de trabajo.

• Cambios de propiedad: comunique los cambios de propiedad y puntos de contacto al equipo de la plataforma.

Cambios en los requisitos empresariales de la carga de trabajo

Para mantener los objetivos de nivel de servicio (SLO) de la carga de trabajo, es posible que el equipo de la plataforma tenga que participar en los cambios en la arquitectura de la carga de trabajo. Estos cambios pueden requerir la administración de cambios del equipo de la plataforma o la validación de que la gobernanza existente admite los requisitos modificados.

Por ejemplo, comunique los cambios de cualquier flujo de salida no permitido previamente para que el equipo de la plataforma pueda agregar ese flujo al firewall, Virtual Network Manager u otros componentes para admitir el tráfico necesario. Del mismo modo, si ya no se necesita un flujo de salida permitido anteriormente, el equipo de la plataforma debe bloquear ese flujo para mantener la seguridad de la carga de trabajo. Comunique también los cambios en el enrutamiento a otras redes virtuales o puntos de conexión entre locales o a los componentes de la arquitectura. Cada recurso está sujeto a directivas y control de firewall de salida potencial.

Confiabilidad

Esta arquitectura se alinea con las garantías de confiabilidad de la arquitectura de línea de base.

Objetivos de confiabilidad

El SLO compuesto máximo posible es menor que el SLO compuesto de línea de base debido a componentes como el control de red de salida. Estos componentes, comunes en entornos de zona de aterrizaje, no son exclusivos de esta arquitectura. El SLO se reduce de forma similar si el equipo de carga de trabajo controla directamente estos servicios de Azure.

A pesar de un SLO máximo más bajo posible, el aspecto clave de confiabilidad es la división de los componentes de carga de trabajo entre equipos funcionales. Con este método, el equipo de carga de trabajo se beneficia de un equipo especializado que se centra en la infraestructura crítica operativa que usan esta y otras cargas de trabajo.

Para obtener más información, consulte Recomendaciones para definir objetivos de confiabilidad.

Dependencias críticas

Vea todas las funciones que realiza la carga de trabajo en la zona de aterrizaje de la plataforma y la aplicación como dependencias. Los planes de respuesta a incidentes requieren que el equipo de carga de trabajo tenga en cuenta el punto y el método de información de contacto para estas dependencias. Incluya también estas dependencias en el análisis del modo de error (FMA) de la carga de trabajo.

Para esta arquitectura, tenga en cuenta las siguientes dependencias:

• Firewall de salida: el firewall de salida centralizado, que comparten varias cargas de trabajo, sufre cambios no relacionados con la carga de trabajo.

• Agotamiento de puertos de red: los picos de uso de todas las cargas de trabajo que comparten el dispositivo de red pueden provocar saturación de red o agotamiento de puertos en el firewall de salida.

• Directivas DINE: las directivas DINE para zonas de DNS privado de Azure DNS (o cualquier otra dependencia proporcionada por la plataforma) son el mejor esfuerzo, sin acuerdo de nivel de servicio en la ejecución. Un retraso en la configuración de DNS puede provocar retrasos en la preparación de una aplicación para controlar el tráfico.

• Directivas de grupo de administración: las directivas coherentes entre entornos son clave para la confiabilidad. Asegúrese de que los entornos de preproducción sean similares a los entornos de producción para proporcionar pruebas precisas y evitar desviaciones específicas del entorno que pueden bloquear una implementación o una escala. Para más información, consulte Administración de entornos de desarrollo de aplicaciones en zonas de aterrizaje de Azure.

Muchas de estas consideraciones pueden existir sin zonas de aterrizaje de Azure, pero los equipos de carga de trabajo y de plataforma deben abordar estos problemas de forma colaborativa para garantizar que se satisfagan las necesidades.

Para más información, consulte Recomendaciones para realizar el análisis del modo de error.

Seguridad

Las consideraciones de seguridad para esta arquitectura se transfieren de la arquitectura de línea de base. Las recomendaciones de las secciones siguientes se basan en la lista de comprobación de revisión de diseño de seguridad en el Marco de buena arquitectura.

Controles de red

Configure correctamente los controles de red para asegurarse de que la carga de trabajo sea segura.

Tráfico de entrada

Puede aislar la carga de trabajo de otros radios de carga de trabajo de su organización a través de grupos de seguridad de red en las subredes o la naturaleza o los controles no transitivos del concentrador regional. Cree grupos de seguridad de red completos que solo permitan los requisitos de red entrantes de la aplicación y su infraestructura. Se recomienda no confiar únicamente en la naturaleza no transitiva de la red del concentrador para la seguridad.

Es probable que el equipo de la plataforma implemente directivas de Azure para asegurarse de que Application Gateway tiene el Web Application Firewall establecido en modo de denegación, para restringir el número de direcciones IP públicas disponibles para su suscripción y otras comprobaciones. Además de esas directivas, el equipo de carga de trabajo debe tener la responsabilidad de implementar directivas centradas en la carga de trabajo que refuercen la posición de seguridad de entrada.

En la tabla siguiente se muestran ejemplos de controles de entrada en esta arquitectura.

Source	Fin	Control de carga de trabajo	Control de plataforma
Internet	Flujos de tráfico de usuarios	Canaliza todas las solicitudes a través de un grupo de seguridad de red, Web Application Firewall y reglas de enrutamiento antes de permitir que el tráfico público pase al tráfico privado que entra en las máquinas virtuales front-end	None
Azure Bastion	Acceso de operador a máquinas virtuales	NSG en subredes de máquina virtual que bloquean todo el tráfico a los puertos de acceso remoto, a menos que se originen desde la subred de Azure Bastion designada de la plataforma.	None
Otros radios	None	Bloqueado a través de reglas de NSG	Enrutamiento no transitivo o reglas de Azure Firewall en el caso de un concentrador protegido de Azure Virtual WAN

Tráfico de salida

Aplique reglas de NSG que expresen los requisitos de conectividad de salida necesarios de la solución y denieguen todo lo demás. No confíe solo en los controles de red del concentrador. Como operador de carga de trabajo, tiene la responsabilidad de detener el tráfico de salida no deseado tan cerca del origen como sea posible.

Tenga en cuenta que, aunque posee su subred dentro de la red virtual, es probable que el equipo de la plataforma cree reglas de firewall para representar específicamente los requisitos capturados como parte del proceso de venta de suscripciones. Asegúrese de que los cambios en las subredes y la colocación de recursos durante el ciclo de vida de la arquitectura siguen siendo compatibles con la solicitud original. O bien, puede trabajar con el equipo de red para garantizar la continuidad del control de salida de acceso mínimo.

En la tabla siguiente se muestran ejemplos de salida en esta arquitectura.

Punto de conexión	Fin	Control de carga de trabajo (NSG)	Control de plataforma (concentrador)
ntp.ubuntu.com	Protocolo de tiempo de red (NTP) para máquinas virtuales Linux	UDP/123 a Internet en la subred de la máquina virtual front-end (el firewall de salida reduce esta amplia apertura)	Asignación de reglas de red de firewall para lo mismo que el control de carga de trabajo
Puntos de conexión de Windows Update	Funcionalidad de Windows Update de servidores Microsoft	TCP/443 y TCP/80 a Internet en la subred de máquina virtual de back-end (el firewall de salida reduce esta amplia apertura)	Regla de asignación de firewall con la etiqueta FQDN de WindowsUpdate
Supervisión de puntos de conexión del agente	Tráfico necesario para la extensión Monitor en máquinas virtuales	TCP/443 a Internet en ambas subredes de máquina virtual (el firewall de salida reduce esta amplia apertura)	Asignaciones de reglas de aplicación de firewall necesarias para todos los FQDN específicos en TCP/443
nginx.org	Para instalar Nginx (un componente de aplicación de ejemplo) directamente desde el proveedor	TCP/443 a Internet en la subred de la máquina virtual front-end (el firewall de salida reduce esta amplia apertura)	Asignación de reglas de aplicación de firewall necesarias para nginx.org en TCP/443
Key Vault	Para importar certificados TLS (seguridad de la capa de transporte) en Application Gateway y máquinas virtuales	- TCP/443 a una subred de punto de conexión privado de ambas subredes de máquina virtual a una subred de punto de conexión privado - TCP/443 a una subred de punto de conexión privado desde una subred de Application Gateway - TCP/443 de máquinas virtuales etiquetadas con una designación de grupo de seguridad de aplicaciones (ASG) necesaria y subred de Application Gateway	None

Protección contra DDOS

Determine quién es responsable de aplicar el plan DDoS Protection que cubre todas las direcciones IP públicas de la solución. El equipo de la plataforma podría usar planes de protección IP o incluso usar Azure Policy para aplicar planes de protección de red virtual. Esta arquitectura debe tener cobertura porque implica una dirección IP pública para la entrada desde Internet.

Para obtener más información, consulte Recomendaciones para redes y conectividad.

Administración de secretos

Para la administración de secretos, esta arquitectura sigue la arquitectura de línea de base.

Como equipo de carga de trabajo, siga manteniendo los secretos en la instancia de Key Vault. Implemente más instancias según sea necesario para admitir las operaciones de la aplicación y de la infraestructura.

Para obtener más información, consulte Recomendaciones para proteger los secretos de aplicación.

Optimización de costos

Para los recursos de carga de trabajo, las estrategias de optimización de costos de la arquitectura de línea de base también se aplican a esta arquitectura.

Esta arquitectura se beneficia en gran medida de los recursos de la plataforma de la zona de aterrizaje de Azure. Incluso si usa esos recursos a través de un modelo de contracargo, la seguridad agregada y la conectividad entre locales son más rentables que la autoadministración de esos recursos.

En esta arquitectura, el equipo de la plataforma administra los siguientes recursos. Estos recursos suelen basarse en el consumo (contracargo) o pueden liberarse al equipo de carga de trabajo.

• Azure Firewall
• Administración de eventos e información de seguridad (SIEM)
• Hosts de Azure Bastion
• Conectividad entre locales, como ExpressRoute

Aproveche otras ofertas centralizadas del equipo de la plataforma para ampliar esas ventajas a la carga de trabajo sin poner en peligro su SLO, el objetivo de tiempo de recuperación (RTO) o el objetivo de punto de recuperación (RPO).

Para obtener más información, consulte Recomendaciones para recopilar y revisar los datos de costos.

Implementación de este escenario

Hay disponible una implementación de esta arquitectura de referencia en GitHub.

Paso siguiente

Revise la colaboración y los detalles técnicos compartidos entre un equipo de carga de trabajo y los equipos de la plataforma.

Expendición de suscripciones