Compartir a través de

Consideraciones sobre la topología de red y conectividad para el acelerador de zonas de aterrizaje de Integration Services

  • Artículo

En este artículo se proporcionan consideraciones de diseño y recomendaciones para la topología de red y conectividad que puedes aplicar al usar el acelerador de zonas de aterrizaje de Servicios de integración Azure (AIS). Las redes son importantes para casi todo dentro de la zona de aterrizaje.

Las consideraciones sobre topología de red y conectividad de esta arquitectura dependen de los requisitos de las cargas de trabajo que se hospedan y de los requisitos de seguridad y cumplimiento de su organización.

Consideraciones de diseño

Usa una topología de red basada en Virtual WAN si la organización:

  • Tiene previsto implementar recursos en varias regiones de Azure y requiere conectividad global entre redes virtuales en estas regiones de Azure y varias ubicaciones locales.

  • Tiene que integrar una red de ramas a gran escala directamente en Azure a través de una implementación de WAN (SD-WAN) definida por software o requiere más de 30 sitios de sucursal para la terminación de IPsec nativa.

  • Necesita un enrutamiento transitivo entre VPN y ExpressRoute, como sucursales remotas conectadas mediante VPN de sitio a sitio o usuarios remotos conectados mediante VPN de punto a sitio, ya que requieren conectividad a un controlador de dominio conectado a ExpressRoute a través de Azure.

Las organizaciones usan Virtual WAN para cumplir los requisitos de interconectividad a gran escala. Microsoft administra este servicio, lo que ayuda a reducir la complejidad general de la red y moderniza la red de la organización.

Usa una topología de red de Azure tradicional basada en la arquitectura en estrella tipo hub-and-spoke si la organización:

  • Planea implementar recursos solo en regiones de Azure seleccionadas.

  • No necesita una red interconectada global.

  • Tiene pocas ubicaciones remotas o sucursales por cada región y necesita menos de 30 túneles de seguridad IP (IPsec).

  • Requiere un control total de la configuración o una configuración personalizada manual de la red de Azure.

Topología de red de referencia

En el diagrama de arquitectura siguiente se muestra la arquitectura de referencia de una implementación empresarial de AIS:

Diagrama que muestra la arquitectura del acelerador de zona de aterrizaje de Servicios de integración Azure.

Planeamiento del direccionamiento IP

Las implementaciones empresariales de AIS deben incluir el uso de puntos de conexión privados y redes virtuales. Hay que tener en cuenta las siguientes consideraciones de diseño a la hora de planificar el direccionamiento IP:

  • Algunos servicios de AIS requieren subredes dedicadas.

    • API Management

    • Logic Apps

    • Puedes designar una subred a un servicio para crear instancias de dicho servicio dentro de la subred. Por ejemplo, puedes designar una subred a planes de App Service para poder agregar otras adicionales a lo largo del tiempo.

    • Azure VPN Gateway puede conectar sitios locales superpuestos con espacios de direcciones IP superpuestos a través de su capacidad de traducción de direcciones de red (NAT).

DNS personalizado

La mayoría de los servicios de AIS permiten a los clientes usar sus propios nombres DNS en puntos de conexión públicos, ya sea mediante sus propios servidores DNS o a través de la oferta de Azure DNS. Estos servidores se configuran recurso a recurso, pero a continuación se enumeran los recursos admitidos:

  • API Management admite dominios personalizados.

  • Las aplicaciones de funciones y Logic Apps admiten dominios personalizados cuando se hospedan en un plan o App Service Environment de App Service.

  • Las cuentas de almacenamiento admiten dominios personalizados para los puntos de conexión de Blob Storage.

  • Data Factory, Service Bus y Event Grid no admiten dominios personalizados.

DNS privado

Azure Private DNS proporciona un servicio DNS confiable y seguro para la red virtual. Azure Private DNS administra y resuelve los nombre de dominio en la red virtual sin necesidad de configurar una solución DNS personalizada.

Para resolver los registros de una zona DNS privada de la red virtual, debes vincular esta última con la zona. Las redes virtuales vinculadas tienen un acceso completo a todos los registros DNS que se publican en la zona privada y también pueden resolverlos.

Consideraciones de diseño

  • Es importante configurar correctamente los parámetros de DNS para resolver la dirección IP del punto de conexión privado en el nombre de dominio completo (FQDN) de tus recursos.

  • Es posible que los servicios de Microsoft Azure existentes ya tengan una configuración de DNS para un punto de conexión público. Esta configuración se debe invalidar para realizar la conexión mediante el punto de conexión privado.

Cifrado y autenticación de certificados

Si el diseño de la red obliga a cifrar el tráfico en tránsito o requiere una autenticación basada en certificados, tendrás que plantearte dónde y cómo se llevan a cabo el cifrado o la autenticación correspondientes. Por ejemplo, tienes que identificar qué servicio realiza la terminación TLS.

Consideraciones de diseño

  • ¿El diseño obliga a cifrar el tráfico entre los servicios de Azure? ¿Se puede finalizar el cifrado en Una instancia de Azure Front Door y, después, no cifrar el tráfico mientras se atraviesa la red troncal de Azure o dentro de la red virtual?

  • ¿Tendrás que finalizar el cifrado en varios lugares?

  • ¿Tienes que controlar la autenticación en varios lugares o esta se puede realizar una vez para una solicitud externa?

Recomendaciones de diseño

  • Si usas un diseño en estrella tipo hub-and-spoke empresarial, plantéate la posibilidad de usar Azure Front Door como punto de entrada para las solicitudes basadas en Internet.

  • Contempla la posibilidad de usar Azure Application Gateway como punto de terminación para toda solicitud externa basada en TLS o API Management para la autenticación de certificados o la terminación SSL.

Conectividad con recursos locales

Muchos escenarios de integración empresarial requieren conectar los sistemas locales con Azure. Es importante tener en cuenta los modelos recomendados para proporcionar esta conectividad.

Consideraciones de diseño

  • Azure ExpressRoute proporciona conectividad privada dedicada para los recursos de infraestructura como servicio (IaaS) y plataforma como servicio (PaaS) de Azure desde ubicaciones locales.

  • Azure VPN Gateway proporciona conectividad compartida de sitio a sitio (S2S) a través de la red pública de Internet a recursos de red virtual de infraestructura como servicio (IaaS) de Azure desde ubicaciones locales.

  • Azure ExpressRoute y Azure VPN Gateway tienen unas capacidades, unos costes y un rendimiento distintos.

  • En los casos en los que no resulte práctico usar ExpressRoute o VPN Gateway, se pueden utilizar la puerta de enlace de datos local (OPDG) o las conexiones híbridas de Azure: las conexiones OPDG o híbridas son servicios de retransmisión, y usan Service Bus para establecer conexiones salientes desde la red local y, de este modo, recibir solicitudes de Azure, sin tener que abrir puertos en el firewall o la red externos.

    • La OPDG admite un número limitado de solicitudes por minuto (determinado por el límite de ancho de banda), presenta límites específicos para el tamaño de los datos y solo funciona con unos cuantos recursos de Azure (Logic Apps, Power BI, Power Apps, Power Automate y Analysis Services).

    • Las conexiones híbridas funcionan con App Services (aplicaciones de funciones o aplicaciones web) y tienen sus propios límites de dimensionamiento y de ancho de banda.

    • Conexiones híbridas de Azure Relay es un elemento clave de Service Bus que permite retransmisiones fuera de App Services o de la OPDG.

Recomendaciones de diseño

  • Usa Azure ExpressRoute como canal de conectividad principal para conectar una red local a Azure.

  • Asegúrate de usar la SKU adecuada para ExpressRoute o VPN Gateway en función de los requisitos de ancho de banda y rendimiento.

  • Usa Azure VPN Gateway para conectar ubicaciones remotas o ramas con Azure.

  • Usa la OPDG o conexiones híbridas cuando no puedas usar ExpressRoute o VPN Gateway, cuando los límites de rendimiento no supongan ningún problema y cuando vayas a usar un recurso de Azure de soporte técnico (por ejemplo, Logic Apps o las aplicaciones de funciones).

Conectividad con servicios PaaS de AIS

Normalmente, a los servicios PaaS de AIS se accede a través de puntos de conexión públicos. La plataforma Azure proporciona funcionalidades para proteger estos puntos de conexión o incluso para que sean completamente privados.

Estos puntos de conexión se pueden proteger mediante puntos de conexión privados.

  • Para bloquear todo el tráfico de Internet a un recurso de destino, usa un punto de conexión privado.

  • Si deseas proteger un subrecurso concreto para los recursos de red virtual, usa un punto de conexión privado.

  • Si deseas proteger una cuenta de almacenamiento concreta para los recursos de red virtual, puedes usar un punto de conexión privado.

Azure Private Link le permite acceder a los servicios de Azure de AIS (por ejemplo, Service Bus y API Management) y a los servicios hospedados en Azure que son propiedad de los clientes, o a los servicios de asociados, a través de un punto de conexión privado de la red virtual.

Cuando se usa Private Link, el tráfico entre la red virtual y el servicio atraviesa la red troncal de Microsoft, por lo que ya no tendrás que exponer el servicio a la red pública de Internet. Puede crear su propio servicio de vínculo privado en la red virtual y enviarlo a los clientes. La configuración y el consumo mediante Azure Private Link es coherente entre los servicios de asociados compartidos y propiedad del cliente de PaaS de Azure.

Consideraciones de diseño

  • La inserción de red virtual proporciona implementaciones privadas dedicadas para los servicios compatibles. El tráfico del plano de administración sigue fluyendo mediante direcciones IP públicas.

  • Azure Private Link proporciona un acceso dedicado mediante direcciones IP privadas a instancias de PaaS de Azure o a servicios personalizados detrás de Azure Load Balancer de nivel estándar.

  • A menudo, a los clientes empresariales les preocupan los puntos de conexión públicos para los servicios PaaS que deben mitigarse de forma adecuada.

Recomendaciones de diseño

  • Use la inserción de red virtual para los servicios de Azure compatibles, a fin de hacer que estén disponibles desde la red virtual.

  • Los servicios PaaS de Azure insertados en una red virtual aún realizan operaciones del plano de administración mediante direcciones IP públicas específicas del servicio. Se debe garantizar la conectividad para que el servicio funcione correctamente.

  • Acceda a los servicios PaaS de Azure desde el entorno local mediante ExpressRoute con emparejamiento privado. Use la inserción de red virtual para los servicios de Azure dedicados o bien Azure Private Link para los servicios de Azure compartidos disponibles.

  • Para acceder a los servicios PaaS de Azure desde el entorno local cuando no esté disponible la inserción en la red virtual o Private Link, usa ExpressRoute con el emparejamiento de Microsoft, ya que te permite evitar el tránsito a través de la red pública de Internet.

  • El acceso a los servicios PaaS de Azure desde el entorno local a través de ExpressRoute con el emparejamiento de Microsoft no impide el acceso a los puntos de conexión públicos del servicio PaaS. Debe configurarlo y restringirlo por separado según sea necesario.

  • No habilite los puntos de conexión del servicio de red virtual de forma predeterminada en todas las subredes.

  • Deshabilita el acceso público a los servicios PaaS de AIS.

Diseño de la red para API Management

Consideraciones de diseño

Recomendaciones de diseño

Diseño de la red para cuentas de almacenamiento

Azure Storage actúa como solución de almacenamiento para Azure Logic Apps y Azure Functions.

Recomendaciones de diseño

  • Para obtener el mejor rendimiento, tu aplicación lógica o de función debe usar una cuenta de almacenamiento de la misma región, lo que reduce la latencia.

  • Usa puntos de conexión privados en las cuentas de Azure Storage para que los clientes de una red virtual (VNet) puedan acceder de forma segura a los datos a través de una instancia de Private Link.

  • Se deben crear distintos puntos de conexión privados para cada servicio de Table, Queue y Blob Storage.

Diseño de la red para entornos de App Service Environment

Un App Service Environment (ASE) es un entorno dedicado y aislado para ejecutar aplicaciones web, aplicaciones de funciones y Logic Apps (Estándar). Se implementa en la red virtual y contiene varios planes de App Service, cada uno de los cuales sirve para hospedar los servicios de tus aplicaciones.

Consideraciones de diseño

  • Un entorno de ASE se implementa en una sola subred dentro de la red virtual. Se puede implementar mediante una dirección IP virtual (VIP) que permita que las conexiones externas usen una dirección IP visible públicamente, la cual se puede agregar a un registro DNS público.

  • Las aplicaciones de un entorno de ASE podrán acceder a todos los demás recursos de la red virtual, en función de las reglas de acceso a la red. A los recursos de otras redes virtuales se puede acceder mediante el emparejamiento de red virtual.

  • No hace falta configurar las aplicaciones de un entorno de ASE para que pertenezcan a una red virtual, ya que, al implementarse en ASE, se encuentran automáticamente dentro de la red virtual. Esto significa que, en vez de tener que configurar el acceso a la red en cada recurso, puedes configurarlo una vez a nivel del entorno de ASE.

Recomendaciones de diseño

  • Siempre que puedas, usa ASE v3, ya que esta es la versión que proporciona la mayor flexibilidad de red y, además, reduce la configuración necesaria para cada recurso dentro del entorno de ASE. ASE v3 también admite la redundancia de zona.

Diseño de la red para planes de App Service

  • App Services se puede implementar en un entorno multiinquilino con un punto de conexión privado o público. Cuando se implementa con un punto de conexión privado, se elimina la exposición pública de App Service. Si hay un requisito para que el punto de conexión privado de App Service también sea accesible a través de Internet, plantéate usar App Gateway para exponer el servicio de aplicaciones.

  • Planifica meticulosamente las subredes para la integración con red virtual saliente. Para ello, ten en cuenta el número de direcciones IP necesarias. La integración con red virtual requiere una subred dedicada. A la hora de planificar el tamaño de la subred, ten en cuenta que Azure reserva 5 direcciones IP en cada subred. Además, se usa una dirección de la subred de integración para cada instancia del plan, Si escala la aplicación a cuatro instancias, se usan cuatro direcciones. Al escalar o reducir verticalmente el tamaño, el espacio de direcciones necesario se duplica durante un breve período de tiempo. lo que afecta a las instancias admitidas reales y disponibles en la subred.

Si tienes que conectarte desde App Service a servicios locales, privados o restringidos por IP, ten en cuenta lo siguiente:

  • Cuando se ejecuta en el entorno multiinquilino, la llamada de App Service puede originarse desde una amplia gama de direcciones IP, y puede que necesites la integración con red virtual para cumplir los requisitos de la conexión en red.

  • Se pueden usar servicios como API Management (APIM) para hacer llamadas mediante proxy entre los límites de la conexión en red, además de proporcionar una dirección IP estática si es necesario.

Recomendaciones de diseño

  • Dado que el tamaño de las subredes no se puede cambiar después de la asignación, debes usar una subred lo suficientemente grande como para dar cabida a cualquier escala que pueda alcanzar la aplicación. Para evitar problemas con la capacidad de la subred, debes usar un sufijo /26 (64 direcciones) para la integración con red virtual.

Diseño de la red para Azure Data Factory

Consideraciones de diseño

  • Para conectar Data Factory a un origen de datos ubicado en la red local (o también en un servicio de Azure configurado para bloquear el acceso desde todos los servicios de Azure salvo que estos estén específicamente permitidos), debes plantearte la opción de integrar Data Factory con una red virtual que proporcione acceso de red al origen de datos de destino.

  • Data Factory emplea entornos independientes llamados entornos de ejecución de integración. El entorno de ejecución de integración de Azure (el predeterminado de Data Factory) no está asociado a ninguna red virtual y, por lo tanto, no sirve para conectarse a orígenes de datos protegidos con los firewalls más restrictivos. Plantéate cuál de estos entornos de ejecución es el que mejor satisface tus requisitos.

  • Las redes virtuales administradas tardan un rato en iniciarse, mientras que los entornos de ejecución de Azure convencionales están disponibles casi al instante. Esto es algo que debes tener presente tanto para programar las canalizaciones como para depurarlas.

  • Los entornos de ejecución de SSIS con un entorno de ejecución integrado con red virtual tardarán hasta 30 minutos en iniciarse.

  • Los entornos de ejecución de integración autohospedados solo pueden ejecutar la actividad de copia, que copia los datos de un origen a otro tal cual. Si quieres realizar alguna transformación en los datos, no podrás hacerlo mediante los flujos de datos de Data Factory.

  • Los puntos de conexión privados administrados se crean en la red virtual administrada de Azure Data Factory y establecen un vínculo privado a recursos de Azure (por lo general, orígenes de datos para ADF). Azure Data Factory administra estos puntos de conexión privados en su nombre.

  • Los puntos de conexión privados solo están disponibles para que los entornos de ejecución de integración autohospedados se conecten a Data Factory.

Diseño de la red para Logic Apps (Estándar): aplicaciones integradas con red virtual

Consideraciones de diseño

Diseño de la red para Service Bus

Consideraciones de diseño

  • ¿Usas zonas DNS privadas o tu propio servidor DNS (con reenvío de DNS) para resolver en un recurso de vínculo privado?

  • El filtrado de IP y las redes virtuales solo se admiten en el nivel de SKU Premium para Service Bus. Si el nivel Premium no resulta práctico, prueba a usar tokens de SAS como método principal para bloquear el acceso al espacio de nombres.

Recomendaciones de diseño

  • El acceso a la red pública debe deshabilitarse mediante el filtrado de IP, que se aplica a todos los protocolos admitidos (por ejemplo, AMQP y HTTPS).

  • Debe restringirse el acceso a la red pública (mediante el filtrado de IP) para que el tráfico dirigido a este espacio de nombres circule únicamente a través de puntos de conexión privados.

  • Coloca el punto de conexión privado en tu propia subred dedicada reservada para Service Bus.

  • Agrega un registro DNS mediante la zona DNS privada del punto de conexión privado. Habilita los servicios de confianza en Azure para acceder directamente a tu espacio de nombres (y, por lo tanto, omitiendo el firewall) para evitarte problemas con el diseño de la integración.

Diseño de la red para aplicaciones de funciones

Consideraciones de diseño

  • ¿Usas zonas DNS privadas o tu propio servidor DNS (con reenvío de DNS) para resolver en un recurso de vínculo privado?

Recomendaciones de diseño

  • Conviene deshabilitar el acceso a las redes públicas.

  • El tráfico dirigido a este espacio de nombres debe circular únicamente a través de puntos de conexión privados.

  • Coloca el punto de conexión privado en tu propia subred dedicada reservada para Functions.

  • Agrega un registro DNS mediante la zona DNS privada del punto de conexión privado.

Diseño de la red para Azure Key Vault

Recomendaciones de diseño

  • Conviene deshabilitar el acceso a las redes públicas.

  • Crea un punto de conexión privado para restringir el acceso solo a través de la red virtual.

  • Coloca el punto de conexión privado en tu propia subred dedicada reservada para Key Vault.

  • Agrega un registro DNS mediante la zona DNS privada del punto de conexión privado.

Diseño de la red para Event Grid

Consideraciones de diseño

  • ¿Usas zonas DNS privadas o tu propio servidor DNS (con reenvío de DNS) para resolver en un recurso de vínculo privado?

Recomendaciones de diseño

  • El acceso a la red pública debe deshabilitarse mediante el filtrado de IP.

  • El tráfico dirigido a los temas y al dominio debe circular únicamente a través de puntos de conexión privados.

  • Coloca el punto de conexión privado en tu propia subred dedicada reservada para Event Grid.

  • Agrega un registro DNS mediante la zona DNS privada del punto de conexión privado.

Diseño de la red para Event Hubs

Consideraciones de diseño

  • El acceso a la red no se puede restringir con el nivel de SKU Básico en Event Hubs

Recomendaciones de diseño

  • El acceso a la red pública debe deshabilitarse mediante el filtrado de IP.

  • El acceso a la red pública debe deshabilitarse mediante puntos de conexión de servicio: crea un punto de conexión de servicio de red virtual en la red virtual y enlázalo al espacio de nombres de Event Hubs mediante una regla de red virtual.

  • Habilita la opción Servicios de confianza para permitir que los recursos de Azure seleccionados accedan al espacio de nombres.

Paso siguiente

Revise las áreas de diseño críticas para realizar consideraciones y recomendaciones completas de la arquitectura.

Seguridad

Contenido recomendado