Acceso privado a los servicios paaS de Azure

En este artículo se explica cómo conectarse a recursos de plataforma como servicio (PaaS) de Azure a través de conexiones de red privada en lugar de la red pública de Internet. Conozca las diferencias entre los puntos de conexión de servicio, los puntos de conexión privados y los Private Link para que pueda elegir el enfoque que se adapte a los requisitos de seguridad y conectividad.

Lo que trata este artículo

El acceso de PaaS privado quita la red pública de Internet de la ruta de acceso de datos entre la red virtual de Azure y los servicios paaS de Azure, como Azure Storage, Azure SQL Database y Azure Key Vault. En este artículo se tratan las opciones de conectividad, sus ventajas y cómo decidir qué enfoque usar para cada carga de trabajo.

Note

Los puntos de conexión privados requieren integración con DNS para resolver los FQDN del servicio a direcciones IP privadas. En este artículo se describen de forma integrada los requisitos de DNS, pero, para consultar la arquitectura completa de DNS, incluido el reenvío híbrido, Azure DNS Private Resolver y la seguridad de DNS, vea Seguridad de DNS y resolución de nombres privados.

Quién necesita este artículo

Lea este artículo si se aplican una o varias de estas condiciones:

  • Las cargas de trabajo deben acceder a los servicios PaaS de Azure a través de rutas de red privadas en lugar de puntos de conexión públicos.
  • Debe decidir entre los puntos de conexión de servicio y los puntos de conexión privados en función de la seguridad, el costo y la capacidad de administración.
  • Debe restringir el acceso a recursos paaS específicos para reducir el riesgo de filtración de datos.
  • Debe planificar la configuración de DNS, la capacidad de la subred o la conectividad híbrida para la conectividad privada con PaaS.

Sugerencia

¿Sigue la ruta del escenario? Seleccione el escenario en la parte superior de la página para obtener instrucciones adaptadas. La guía básica siguiente se aplica a todos los lectores.

Enfoque lift-and-shift: Omita este artículo a menos que algunas partes de su aplicación migrada ya utilicen servicios PaaS de Azure. La mayoría de las cargas de trabajo de lift-and-shift permanecen en IaaS (máquinas virtuales, discos administrados, redes estándar) y no necesitan Private Link en la fase de migración inicial. Vuelva a este artículo más adelante cuando empiece a adoptar servicios PaaS para componentes de carga de trabajo individuales.

Lea este artículo si:

  • Han migrado las cargas de trabajo que ya consumen Azure servicios PaaS (por ejemplo, Azure SQL Database o Azure Storage).
  • ¿Quiere saber cuándo empezar a utilizar Private Link como parte de una modernización por fases tras el lift-and-shift?
  • Debe planear la capacidad de subred para la adopción futura del punto de conexión privado.

Enfoque de modernización: Las subredes de Private Link en cada VNet de radio son esenciales. Las cargas de trabajo de base de datos administradas de AKS, App Service Environment y ASE necesitan conectividad de PaaS privada para cumplir los requisitos de cumplimiento y evitar la filtración de datos a través de la red pública de Internet.

Lea este artículo si:

  • Almacena datos confidenciales o regulados en servicios PaaS de Azure y restringe el acceso a rutas de red privadas.
  • Es necesario crear subredes dedicadas de Private Link en cada VNet de radio para que las utilice el equipo de la aplicación.
  • Quiere evitar la filtración de datos asegurándose de que los ámbitos de conectividad de PaaS se apliquen a instancias de recursos específicas.
  • Están diseñando cargas de trabajo de producción en las que los servicios PaaS deben ser accesibles desde redes locales a través de VPN o ExpressRoute.
  • Es necesario comprender el costo, EL DNS y las ventajas de seguridad entre los puntos de conexión de servicio y los puntos de conexión privados.

Enfoque entre nubes: Este artículo es relevante después de establecer el tránsito y la conectividad entre nubes, a menos que la arquitectura de destino ya incluya Azure PaaS con puntos de conexión privados. Vuelva a este artículo durante la optimización cuando esté listo para proteger las rutas de acceso de PaaS.

Lea este artículo si:

  • Usa Azure Migrate con compatibilidad con puntos de conexión privados durante el proceso de migración.
  • Planee adoptar Azure servicios PaaS como parte de la arquitectura de destino posterior a la migración.
  • Es necesario comprender cómo funcionan los puntos de conexión privados antes de integrarlos con el diseño entre nubes.

servicios y características de Azure

En la tabla siguiente se describen los servicios y características disponibles para la conectividad de PaaS privada en Azure.

Servicio o característica Qué proporciona Cuándo usarlo
Punto de conexión público (valor predeterminado) Acceda a los servicios PaaS de Azure a través de internet mediante su nombre de dominio completo público (FQDN). No se necesita ninguna configuración adicional. Solo entornos de desarrollo y pruebas. No se recomienda para cargas de trabajo de producción con datos confidenciales.
Puntos de conexión de servicio Amplía su identidad de red virtual a los servicios PaaS de Azure. El tráfico permanece en la red troncal de Microsoft. El servicio PaaS ve la red virtual como origen del tráfico. No crea una dirección IP privada. Bajo riesgo de filtración. Configuración más sencilla que Private Link. Resulta útil cuando Private Link no está disponible para un servicio específico. Gratis.
Punto de conexión privado/Azure Private Link Crea una interfaz de red con una dirección IP privada dentro de la red virtual que se asigna a una instancia de recurso paaS específica. El tráfico permanece en la red troncal Microsoft y nunca atraviesa la red pública de Internet. Requiere la integración de DNS. Cargas de trabajo de producción. Información confidencial. Cumplimiento normativo. Prevención de filtración de datos. Se prefiere frente a los puntos de conexión de servicio para los nuevos diseños.
Private Link Service Exponga su propio servicio de forma privada a consumidores de otras redes virtuales o de inquilinos de Microsoft Entra. Los consumidores crean un punto de conexión privado en su propia red virtual para acceder al servicio, sin necesidad de emparejamiento de VNet. ISV o equipos de plataformas internas que publican servicios para consumidores que no deben tener acceso a nivel de red a la red virtual de origen.
Integración con VNet (App Service, Functions) Permite a App Service o Azure Functions enrutar el tráfico saliente a través de una red virtual. Solo de salida: no proporciona conectividad privada de entrada. Cuando App Service o Azure Functions necesita acceder a recursos privados de red virtual, como bases de datos o API internas a través de puntos de conexión privados.

Cómo elegir

Diagrama que compara tres métodos de acceso PaaS: punto de conexión público, punto de conexión de servicio a través de la red troncal y punto de conexión privado con ip privada.

Use las tablas de decisión de esta sección para seleccionar el enfoque de conectividad adecuado para la carga de trabajo.

Puntos de conexión de servicio en comparación con los puntos de conexión privados

En la tabla siguiente se comparan los dos enfoques más comunes para restringir el acceso de PaaS a rutas de acceso de red privadas.

Factor Puntos de conexión de servicio Puntos de conexión privados
Ruta del tráfico Red troncal de Microsoft El destino sigue usando su dirección IP pública. Red troncal de Microsoft. El destino usa una dirección IP privada en la red virtual.
Dirección IP privada en la red virtual No. La IP de origen pasa a ser privada (dirección de VNet), pero el servicio se resuelve a su IP pública. Yes. Una interfaz de red con una dirección IP privada de la subred se asigna al recurso específico.
Cambios de DNS necesarios No. La resolución DNS permanece sin cambios. Yes. Se requiere una zona DNS privada para que el nombre de dominio completo (FQDN) del servicio se resuelva a la IP privada.
Prevención de filtración de datos Limitado. Se aplica en el nivel de red virtual a todas las instancias de un tipo de servicio (por ejemplo, todas las cuentas de Azure Storage). Fuerte. El acceso se limita a una instancia de recurso específica. Solo se puede acceder al recurso mapeado a través de ese punto de conexión.
Acceso local No se puede acceder desde redes locales. Solución alternativa: agrega tus direcciones IP públicas o las de NAT a las reglas de firewall de direcciones IP del servicio de Azure. Se puede acceder desde el entorno local a través de VPN o ExpressRoute porque el punto de conexión tiene una dirección IP privada enrutable.
Cost Gratis. Sin cargos adicionales. Cargo por hora por punto de conexión más la tarifa de procesamiento de datos.

Cuándo usar qué enfoque

Escenario Enfoque recomendado Por qué
Desarrollo y pruebas, baja sensibilidad a los datos Punto de conexión público con firewall de servicio Configuración más sencilla. Restringir el acceso mediante una lista de direcciones IP permitidas. Sin costo adicional ni cambios de DNS.
Restricción de red virtual simple, bajo riesgo de filtración Puntos de conexión de servicio Gratis. Rápido para habilitar. Adecuado cuando no se necesita la delimitación del acceso a nivel de recurso.
Cargas de trabajo de producción, datos confidenciales, cumplimiento Puntos de conexión privados Protección contra filtración más fuerte. Funciona desde entornos locales. Admite la resolución basada en DNS desde cualquier red conectada.
Publicar tu propio servicio de forma privada para otros inquilinos Servicio Private Link Los consumidores crean un punto de conexión privado en su red virtual. No se requiere emparejamiento de VNet. Admite flujos de trabajo de aprobación y controles de visibilidad.
App Service o Functions necesita acceder a los recursos de la red virtual Integración de VNet Conectividad solo saliente. Requiere la delegación de subred a Microsoft.Web/serverFarms. Combine con puntos de conexión privados para proteger el acceso a los datos a los servicios PaaS.

Azure Front Door Premium admite orígenes de Private Link, que se utilizan para conectar Front Door a sus servicios de backend (App Service, Storage o equilibradores de carga internos) a través de una conexión privada. El tráfico entre Front Door y tu origen permanece en la red troncal de Microsoft, y puedes desactivar por completo el acceso público al origen. Este patrón es la integración más documentada para Private Link entre Azure servicios de red.

Utiliza Front Door Premium con orígenes de Private Link cuando necesites:

  • Equilibrio de carga global con protección de firewall de aplicaciones web (WAF).
  • Conectividad privada con los orígenes sin exponerlos a la Internet pública.
  • Terminación TLS centralizada con tráfico de backend a través de rutas privadas.

Integración de VNet para acceso saliente

La integración con VNet no proporciona conectividad privada de entrada. Habilita App Service o Azure Functions para enrutar las llamadas salientes a través de la red virtual. Esto significa que la aplicación puede llegar a los recursos detrás de puntos de conexión privados o acceder a servicios privados de red virtual. La integración con VNet requiere una subred dedicada delegada a Microsoft.Web/serverFarms.

Combine la integración de red virtual con puntos de conexión privados cuando la aplicación necesite:

  • Llame a Azure SQL Database o Azure Storage a través de una dirección IP privada.
  • Acceda a las API internas o a los servicios desplegados en redes virtuales secundarias.
  • Enrutar el tráfico saliente a través de un dispositivo virtual de red (NVA) para su inspección.

Consideraciones de diseño

La mayoría de los proyectos de lift-and-shift posponen la adopción de Private Link para una fase posterior. La prioridad inmediata es migrar máquinas virtuales y establecer la conectividad básica. Tenga en cuenta Private Link cuando:

  • Los componentes de carga de trabajo individuales ya usan PaaS: Si una aplicación levantada se conecta a Azure SQL Database o Azure Storage, agregue un punto de conexión privado para ese servicio específico. No es necesario convertir todo el acceso de PaaS a la vez.
  • El cumplimiento exige conectividad privada: Algunas cargas de trabajo reguladas requieren rutas de acceso de datos privadas desde el primer día. En este caso, cree puntos de conexión privados durante la migración, no después.
  • Planifique ahora la capacidad de la subred: Aunque posponga Private Link, reserve una subred /27 o /28 en cada spoke para futuros Puntos de conexión privados. El reajuste del espacio de subred más adelante es más difícil que reservarlo por adelantado.

Para la mayoría de las migraciones mediante lift-and-shift, omita la implementación detallada de Private Link y vuelva a este artículo cuando comience la adopción de PaaS.

Crear una subred dedicada de Private Link en cada VNet de los spokes. Los equipos de aplicaciones usan esta subred para crear puntos de conexión privados para los servicios paaS que consumen sus aplicaciones:

  • Subred de Private Link dedicada por cada red de satélite: Dimensiona cada subred en función del número de servicios PaaS que necesiten las cargas de trabajo de la red de satélite (una IP por punto de conexión privado). Una /27 (32 direcciones) admite hasta 27 puntos de conexión privados después de que Azure reserve 5 direcciones.
  • Los administradores de aplicaciones deciden conexiones PaaS: El equipo de TI proporciona la subred y la infraestructura DNS. Los equipos de aplicaciones crean puntos de conexión privados para sus recursos paaS específicos (Azure SQL, Key Vault, storage) en función de los requisitos de la aplicación.
  • Centraliza las zonas DNS en el nodo central: Las zonas DNS privadas (por ejemplo, privatelink.database.windows.net) residen en la suscripción de conectividad y se vinculan a todas las VNet de satélite. Este enfoque garantiza una resolución de nombres coherente y evita el DNS de cerebro dividido.
  • Desactivar el acceso público en los recursos de PaaS: Después de crear un punto de conexión privado, desactive el acceso a la red pública en el recurso PaaS de destino. De lo contrario, el tráfico todavía puede llegar al servicio a través de Internet, lo que derrota el propósito de la conectividad privada.
  • Combínelo con la integración con redes virtuales: App Service y Azure Functions usan la integración con redes virtuales para enrutar las llamadas salientes a través de la red virtual spoke, accediendo a servicios PaaS mediante puntos de conexión privados en la misma red virtual o en una red virtual emparejada.

El dispositivo de Azure Migrate admite la conectividad de puntos de conexión privados, lo que protege el tráfico del plano de control de la migración. Además, aplaza la planificación de Private Link hasta la optimización posterior a la migración:

  • Azure Migrate con punto de conexión privado: durante el proceso de migración, el dispositivo de Azure Migrate puede usar un punto de conexión privado para comunicarse con el proyecto de Azure Migrate. Este enfoque mantiene el tráfico de control de migración fuera de la red pública de Internet.
  • Aplazar la adopción generalizada de Private Link: Céntrese primero en la conectividad de tránsito entre nubes. Una vez que migre y estabilice las cargas de trabajo en Azure, planee puntos de conexión privados para los servicios PaaS como un pase de optimización independiente.
  • Reservar espacio de subred: Aunque ahora no utilice Private Link, reserve una subred en cada spoke para futuros puntos de conexión privados. Las cargas de trabajo entre nubes que más adelante adoptan Azure servicios PaaS necesitan esta capacidad.

Prerequisites

Antes de implementar el acceso privado de PaaS, confirme que tiene los siguientes recursos y conocimientos en su lugar:

  • Una red virtual implementada con al menos una subred. Los puntos de conexión privados requieren una subred con direcciones IP disponibles. Para el diseño de redes virtuales, consulte Redes virtuales y subredes.
  • Un servicio paaS de Azure para conectarse de forma privada. El servicio debe ser compatible con Service Endpoints o Private Link. Consulte la documentación de disponibilidad de Azure Private Link para el servicio.
  • Descripción de la infraestructura dns. Los puntos de conexión privados requieren una zona DNS privada. Si usa servidores DNS personalizados, necesita reenviadores condicionales que apunten a Azure DNS (168.63.129.16). Para conocer los patrones de diseño de DNS, consulte el artículo integración de DNS para puntos de conexión privados en recursos relacionados.
  • Planeación de direcciones IP. Cada punto de conexión privado consume una dirección IP privada de la subred. Planee los tamaños de subred según corresponda. Consulte Planeamiento de direcciones IP para obtener instrucciones.

Consideraciones de seguridad

La conectividad de PaaS privada afecta directamente a la posición de filtración de datos, la confiabilidad de DNS y la aplicación de directivas de red. Tenga en cuenta las instrucciones siguientes al diseñar la implementación.

Prevención de la filtración de datos

Los puntos de conexión privados proporcionan la protección de filtración más segura porque cada punto de conexión se asigna a una única instancia de recurso. Un usuario o aplicación de la red virtual solo puede acceder a la cuenta de almacenamiento o base de datos específica para la que está configurado el punto de conexión privado. No pueden redirigir los datos a una instancia diferente del mismo tipo de servicio.

Los puntos de conexión de servicio, por el contrario, restringen el acceso en el nivel de red virtual, pero se aplican a todas las instancias de un tipo de servicio. Por ejemplo, un punto de conexión de servicio para Azure Storage significa que la red virtual puede llegar a cualquier cuenta de Azure Storage a la que se le conceda acceso, no solo a la cuenta que pretende usar. Esta brecha hace que los puntos de conexión de servicio no son suficientes para los entornos en los que la filtración de datos es un problema de cumplimiento.

Configuración de zona DNS

Diagrama que muestra el flujo de resolución DNS del punto de conexión privado desde el cliente, a través de Azure DNS y de la zona DNS privada, hasta la cuenta de almacenamiento.

Los puntos de conexión privados dependen de la resolución DNS correcta para funcionar. Al crear un punto de conexión privado, configure una zona DNS privada (por ejemplo, privatelink.blob.core.windows.net para Azure Blob Storage) para que el FQDN del servicio se resuelva en la dirección IP privada en lugar de la dirección IP pública.

La configuración incorrecta de zonas DNS puede provocar lo siguiente:

  • Las aplicaciones que resuelven la dirección IP pública, sin pasar por el punto de conexión privado en absoluto.
  • Los clientes locales no pueden acceder a la dirección IP privada porque los reenviadores condicionales no están configurados.
  • Problemas de DNS de split-brain, en los que algunos clientes realizan la resolución de forma privada y otros de forma pública.

Centralice las zonas DNS privadas en un servicio compartido o una suscripción de conectividad y vincule a todas las redes virtuales que necesitan resolución. Use Azure Policy para aplicar la integración de la zona DNS privada cuando se creen puntos de conexión privados.

Directivas de red en subredes de punto de conexión privado

Los grupos de seguridad de red (NSG) y las rutas definidas por el usuario (UDR) ahora se admiten en subredes de punto de conexión privado. Este soporte está deshabilitado de forma predeterminada y debe habilitarse explícitamente para cada subred. Después de habilitar las directivas de red:

  • Puede aplicar reglas de NSG para controlar qué orígenes pueden llegar al punto de conexión privado.
  • Puede usar UDR para enrutar el tráfico de Private Endpoint a través de un dispositivo virtual de red para su inspección.
  • Puede hacer referencia a puntos de conexión privados en las reglas del grupo de seguridad de aplicaciones (ASG).

Habilite las directivas de red en subredes de punto de conexión privado en entornos de producción para mantener una posición de seguridad coherente en todas las subredes de la red virtual.

Importante

Después de configurar un punto de conexión privado para un servicio PaaS, desactive el acceso a la red pública en ese servicio. Si el acceso público permanece habilitado, el tráfico todavía puede llegar al servicio a través de Internet, lo que derrota el propósito de la conectividad privada.

Zonas DNS privadas para servicios comunes

En la tabla siguiente se enumeran las zonas DNS privadas necesarias para los servicios paaS de Azure usados habitualmente.

Servicio de Azure Zona DNS privada
Azure Blob Storage (Servicio de almacenamiento de blobs de Azure) privatelink.blob.core.windows.net
Azure SQL Database privatelink.database.windows.net
Azure Key Vault privatelink.vaultcore.azure.net
Azure Cosmos DB (la base de datos de Azure Cosmos) privatelink.documents.azure.com
Azure App Service privatelink.azurewebsites.net

Sugerencia

Al crear un punto de conexión privado en el portal de Azure, a menudo crea automáticamente una zona DNS privada asociada. La eliminación del punto de conexión privado no siempre quita la zona ni sus vínculos de red virtual. Audite periódicamente los puntos de conexión privados huérfanos y las zonas DNS privadas. Añaden costes y desorden a la configuración de resolución de nombres.

Perímetro de seguridad de red para el acceso PaaS

Private Link controla cómo llega el tráfico a un servicio PaaS a través de una dirección IP privada. Perímetro de seguridad de red (NSP) controla qué redes y recursos pueden comunicarse con ese servicio. NSP agrega un límite explícito alrededor de los recursos de PaaS, como Azure Storage, Azure SQL Database y Azure Key Vault: los recursos dentro del perímetro se comunican libremente, mientras que el acceso desde fuera se deniega de forma predeterminada a menos que una regla de acceso lo permita. Use NSP junto con puntos de conexión privados cuando necesite protección de filtración de datos de nivel PaaS en diseños de alta seguridad. Para saber dónde encaja NSP en los niveles de seguridad, consulte la matriz de posición de seguridad en la información general.

Aprende más

Pasos siguientes

Sugerencia

¿Explorando por su cuenta? Vuelva al navegador de información general para encontrar el siguiente artículo por funcionalidad.

El siguiente paso en su proceso de lift-and-shift:

Acceso saliente a Internet: controle cómo las cargas de trabajo migradas llegan a Internet a través de una ruta de acceso de salida centralizada.

A continuación en su proceso de modernización:

Acceso saliente a Internet: encamine todo el tráfico saliente de las redes spoke a través del firewall del hub para garantizar un control uniforme gestionado por TI.

Siguiente paso en su proceso de migración entre nubes:

Supervisión y diagnóstico de red: Obtenga visibilidad del tráfico entre distintas nubes y de la conectividad con puntos de conexión privados.

Si su arquitectura multinube incluye una salida centralizada a Internet, lea primero Acceso saliente a Internet.

  • Last updated on