Compartir vía

Diseño de la configuración de Azure Private Link

  • Artículo

Antes de configurar su instancia de Azure Private Link, tenga en cuenta su topología de red y su topología de enrutamiento del DNS.

Como se describe en Uso de Azure Private Link para conectar redes a Azure Monitor, la configuración de un vínculo privado afecta al tráfico de todos los recursos de Azure Monitor. Esto es especialmente cierto para los recursos de Application Insights. No solo afecta a la red conectada al punto de conexión privado, sino también a todas las demás redes que comparten el mismo DNS.

El enfoque más sencillo y seguro es el que se indica a continuación:

  1. Cree una conexión de vínculo privado única, con un único punto de conexión privado y un único ámbito de Azure Monitor Private Link (AMPLS). Si las redes están emparejadas, cree la conexión de vínculo privado en la red virtual compartida (o centro de conectividad).
  2. Agregue todos los recursos de Azure Monitor, como los componentes de Application Insights, las áreas de trabajo de Log Analytics y los puntos de conexión de recopilación de datos al AMPLS.
  3. Bloquee el tráfico de salida de la red tanto como sea posible.

Si no puede agregar todos los recursos de Azure Monitor a AMPLS, puede seguir aplicando su vínculo privado a algunos recursos, como se explica en Control de cómo se aplican los vínculos privados a las redes. No se recomienda este enfoque porque no impide la filtración de datos.

Planeamiento por topología de red

Considere la topología de red en el proceso de planificación.

Principio rector: evitar invalidaciones de DNS mediante un único AMPLS

Algunas redes se componen de varias redes virtuales u otras redes conectadas. Si estas redes comparten el mismo DNS, la configuración de un vínculo privado en cualquiera de ellas actualizaría el DNS y afectaría al tráfico entre todas las redes.

En el diagrama siguiente, VNet 10.0.1.x se conecta a AMPLS1, que crea entradas DNS que asignan puntos de conexión de Azure Monitor a direcciones IP a partir del intervalo 10.0.1.x. Más adelante, VNet 10.0.2.x se conecta a AMPLS2, lo que invalida las mismas entradas DNS al asignar los mismos puntos de conexión globales o regionales a direcciones IP a partir del intervalo 10.0.2.x. Dado que estas redes virtuales no están emparejadas, la primera red virtual ahora no puede acceder a estos puntos de conexión.

Para evitar este conflicto, cree solo un único objeto AMPLS por DNS.

Diagrama que muestra invalidaciones de DNS en varias redes virtuales.

Redes en estrella tipo hub-and-spoke

Las redes en estrella tipo hub-and-spoke deben usar una única conexión de vínculo privado configurada en la red del hub (principal) y no en cada red virtual de spoke.

Diagrama que muestra un vínculo privado único en estrella tipo hub-and-spoke.

Nota:

Puede que prefiera crear vínculos privados independientes para sus redes virtuales de radio, por ejemplo, para permitir que cada red virtual acceda a un conjunto limitado de recursos de supervisión. En tales casos, puede crear un punto de conexión privado dedicado y AMPLS para cada red virtual. También debe comprobar que no comparten las mismas zonas DNS para evitar invalidaciones de DNS.

Redes emparejadas

El emparejamiento de red se usa en varias topologías, aparte de la topología de red en estrella tipo hub-and-spoke. Estas redes pueden compartir las direcciones IP de los demás y, muy probablemente, compartir el mismo DNS. En tales casos, creae un único vínculo privado en una red a la que puedan acceder las demás redes. Evite crear varios puntos de conexión privados y objetos AMPLS, ya que, en última instancia, solo se aplica el último establecido en el DNS.

Redes aisladas

Si las redes no están emparejadas, también debe separar su DNS para usar instancias de vínculo privado. Una vez listo, cree un punto de conexión privado independiente para cada red, y un objeto AMPLS independiente. Los objetos AMPLS pueden vincularse a las mismas áreas de trabajo o componentes, o a otras distintas.

Prueba local: edición del archivo de hosts de la máquina en lugar del DNS

Para probar los vínculos privados localmente sin afectar a otros clientes de la red, asegúrese de no actualizar el DNS al crear el punto de conexión privado. En su lugar, edite el archivo de hosts en la máquina para que envíe solicitudes a los puntos de conexión de vínculo privado:

  • Configure una instancia de vínculo privado, pero, al conectarla a un punto de conexión privado, elija la opción para no integrarla automáticamente con el DNS (paso 5b).
  • Configure los puntos de conexión pertinentes en los archivos de hosts de las máquinas. Para revisar los puntos de conexión de Azure Monitor que necesitan asignación, consulte Revisión de la configuración de DNS del punto de conexión.

No recomendamos ese enfoque para entornos de producción.

Al usar los modos de acceso de vínculo privado puede controlar de qué manera los vínculos privados afectan al tráfico. Esta configuración se puede aplicar al objeto AMPLS (para afectar a todas las redes conectadas) o a redes específicas conectadas a él.

Elegir el modo de acceso adecuado es fundamental para garantizar un tráfico de red continuo e ininterrumpido. Cada uno de estos modos se puede establecer para la ingesta y las consultas, por separado:

  • Solo privado: permite que la red virtual se comunique solo con recursos de vínculo privado (recursos de AMPLS). Es el modo de trabajo más seguro. Evita la filtración de datos bloqueando el tráfico fuera de los recursos de AMPLS a Azure Monitor. Diagrama que muestra el modo de acceso solo privado de AMPLS.
  • Abierto: permite que la red virtual se comunique tanto con los recursos de vínculo privado como con los recursos que no están en AMPLS (si aceptan tráfico de redes públicas). El modo de acceso abierto no impide la filtración de datos, pero ofrece las otras ventajas de los vínculos privados. El tráfico a los recursos de vínculo privado se envía a través de puntos de conexión privados, validados y enviados a través de la red troncal de Microsoft. El modo abierto es útil para un modo de trabajo mixto (acceso a algunos recursos públicamente y a otros a través de un vínculo privado) o durante un proceso de incorporación gradual. Diagrama que muestra el modo de acceso abierto de AMPLS. Los modos de acceso se establecen por separado para la ingesta y las consultas. Por ejemplo, puede establecer el modo solo privado para la ingesta y el modo abierto para las consultas.

Tenga cuidado al seleccionar el modo de acceso. El uso del modo de acceso solo privado bloqueará el tráfico a los recursos que no están en AMPLS en todas las redes que comparten el mismo DNS, independientemente de la suscripción o el inquilino. La excepción son las solicitudes de ingestión de Log Analytics, que se explican. Si no puede agregar todos los recursos de Azure Monitor al AMPLS, empiece por agregar algunos de ellos y aplicar el modo de acceso Abierto. Cambie al modo Solo privado para obtener la máxima seguridad solo cuando haya agregado todos los recursos de Azure Monitor a AMPLS.

Consulte Uso de API y línea de comandos para obtener detalles de configuración y ejemplos.

Nota

La ingesta de Log Analytics usa puntos de conexión específicos del recurso. Por lo tanto, no se adhiere a los modos de acceso de AMPLS. Para asegurarse de que las solicitudes de ingesta de Log Analytics no pueden acceder a áreas de trabajo fuera de AMPLS, establezca el firewall de red para que bloquee el tráfico a los puntos de conexión públicos, independientemente de los modos de acceso de AMPLS.

Definir los modos de acceso para redes específicas

Los modos de acceso establecidos en el recurso de AMPLS afectan a todas las redes, pero puede invalidar esta configuración para redes específicas.

En el diagrama siguiente, VNet1 usa el modo abierto y VNet2 usa el modo solo privado. Las solicitudes de VNet1 pueden alcanzar el área de trabajo 1 y el componente 2 a través de un vínculo privado. Las solicitudes solo pueden llegar al componente 3 si acepta el tráfico de redes públicas. Las solicitudes de VNet2 no pueden alcanzar el componente 3. Diagrama que muestra los modos de acceso mixto.

Consideración sobre las limitaciones de AMPLS

El objeto de AMPLS tiene las siguientes limitaciones:

  • Una red virtual solo puede conectarse a un único objeto AMPLS. Esto significa que el objeto AMPLS debe proporcionar acceso a todos los recursos de Azure Monitor a los que la red virtual debe tener acceso.
  • Un objeto de AMPLS puede conectarse a 300 áreas de trabajo de Log Analytics y a 1000 componentes de Application Insights como máximo.
  • Un recurso de Azure Monitor (área de trabajo o componente de Application Insights o punto de conexión de recopilación de datos) puede conectarse a cinco AMPLS como máximo.
  • Un objeto de AMPLS puede conectarse a 10 puntos de conexión privados como máximo.

Nota

Los recursos de AMPLS creados antes del 1 de diciembre de 2021 solo admiten 50 recursos.

En el diagrama siguiente:

  • Cada red virtual solo puede conectarse a un único objeto AMPLS.
  • AMPLS A se conecta a dos áreas de trabajo y un componente de Application Insights, mediante dos de las 300 posibles áreas de trabajo de Log Analytics y uno de los posibles 1000 componentes de Application Insights a los que se puede conectar.
  • Workspace 2 se conecta a AMPLS A y AMPLS B, y utiliza dos de las cinco posibles conexiones de AMPLS.
  • AMPLS B está conectado a puntos de conexión privados de dos redes virtuales (VNet2 y VNet3) mediante dos de las 10 posibles conexiones de punto de conexión privado.

Diagrama que muestra los límites de AMPLS.

Control de acceso de red a los recursos

Las áreas de trabajo de Log Analytics o los componentes de Application Insights se pueden establecer para:

  • Aceptar o bloquear la ingesta desde redes públicas (redes no conectadas al recurso AMPLS).
  • Aceptar o bloquear las consultas desde redes públicas (redes no conectadas al recurso AMPLS).

Esa granularidad le permite establecer el acceso según sus necesidades, por área de trabajo. Por ejemplo, podría aceptar la ingesta solo través de redes conectadas por vínculo privado (es decir, redes virtuales específicas), pero seguir aceptando consultas de todas las redes, públicas y privadas.

Bloquear las consultas de redes públicas significa que los clientes, como máquinas y SDK, fuera de los AMPLS conectados no pueden consultar los datos del recurso. Estos datos incluyen registros, métricas y el flujo de métricas en directo. Bloquear las consultas desde redes públicas afecta a todas las experiencias que ejecutan estas consultas, como libros, paneles, información en Azure Portal y las consultas que se ejecutan desde fuera de Azure Portal.

Nota:

Hay ciertas excepciones en las que esta configuración no se aplica. Puede encontrar los detalles en la tabla siguiente.

Los puntos de conexión de recopilación de datos se pueden establecer para aceptar o bloquear el acceso desde redes públicas (redes que no están conectadas al recurso AMPLS).

Para obtener información de configuración, consulte Establecer marcas de acceso a recursos.

Excepciones

Tenga en cuenta las siguientes excepciones.

Registros de diagnóstico

Los registros y las métricas que se cargan en un área de trabajo a través de configuración de diagnóstico pasan por un canal de Microsoft privado seguro y no se controlan mediante esta configuración.

Métricas personalizadas o métricas de invitado de Azure Monitor

Las métricas personalizadas (versión preliminar), recopiladas y cargadas a través del agente de Azure Monitor, no se controlan mediante puntos de conexión de recopilación de datos. No se pueden configurar a través de vínculos privados.

Azure Resource Manager

La restricción del acceso, como se ha explicado antes, se aplica a los datos del recurso. No obstante, los cambios de configuración, como la activación o desactivación de esta configuración de acceso, se administran mediante Azure Resource Manager. Para controlar esta configuración, restrinja el acceso a los recursos mediante los roles, los permisos, los controles de red y la auditoría adecuados. Para más información, consulte Roles, permisos y seguridad en Azure Monitor.

Nota:

Las consultas enviadas a través de la API de Resource Manager no pueden usar vínculos privados de Azure Monitor. Estas consultas solo pueden pasar si el recurso de destino permite consultas desde redes públicas (establecidas mediante el panel Aislamiento de red o con la CLI).

Se sabe que las siguientes experiencias ejecutan consultas a través de la API de Resource Manager:

  • Conector de LogicApp
  • Solución Update Management
  • Solución de seguimiento de cambios
  • VM Insights
  • Container Insights
  • El panel Resumen del área de trabajo (en desuso) de Log Analytics (que muestra el panel de soluciones)

Consideraciones sobre Application Insights

Nota:

Para proteger completamente la instancia de Application Insights basada en el área de trabajo, debe bloquear tanto el acceso al recurso de Application Insights como el área de trabajo de Log Analytics subyacente.

Consideraciones sobre Log Analytics

Tenga en cuenta las siguientes consideraciones de Log Analytics.

Descarga de paquetes de la solución Log Analytics

Los agentes de Log Analytics necesitan acceder a una cuenta de almacenamiento global para descargar los paquetes de soluciones. Las configuraciones de vínculo privado creadas a partir del 19 de abril de 2021 (o a partir de junio de 2021 en nubes soberanas de Azure) pueden acceder al almacenamiento de los paquetes de soluciones de los agentes a través del vínculo privado. Esto es posible a través de la nueva zona DNS creada para blob.core.windows.net.

Si la configuración del vínculo privado se creó antes del 19 de abril de 2021, no llegará al almacenamiento de paquetes de solución a través de un vínculo privado. Para controlarlo, puede hacer lo siguiente:

  • Vuelva a crear el AMPLS y el punto de conexión privado conectado a él.

  • Permita que los agentes lleguen a la cuenta de almacenamiento a través de su punto de conexión público, agregando las siguientes reglas a la lista de permitidos del firewall:

    Entorno en la nube Recurso del agente Puertos Dirección
    Azure Public scadvisorcontent.blob.core.windows.net 443 Salida
    Azure Government usbn1oicore.blob.core.usgovcloudapi.net 443 Salida
    Microsoft Azure operado por 21Vianet mceast2oicore.blob.core.chinacloudapi.cn 443 Salida

Las cuentas de almacenamiento se usan en el proceso de ingesta de registros personalizados. De forma predeterminada, se usan cuentas de almacenamiento administradas por el servicio. Para ingerir registros personalizados en vínculos privados, debe usar sus propias cuentas de almacenamiento y asociarlas a áreas de trabajo de Log Analytics.

Para más información sobre cómo conectar su propia cuenta de almacenamiento, consulte Cuentas de almacenamiento propiedad del cliente para la ingesta de registros y, específicamente, Uso de vínculos privados y Vinculación de cuentas de almacenamiento al área de trabajo de Log Analytics.

Automatización

Si usa soluciones de Log Analytics que requieren una cuenta de Azure Automation (como Update Management, Change Tracking o Inventario), también debe crear una instancia de vínculo privado para la cuenta de Automation. Para obtener más información, vea Uso de Azure Private Link para conectar redes a Azure Automation de forma segura.

Nota

Algunos productos y experiencias de Azure Portal consultan datos a través de Resource Manager. En este caso, no podrán consultar datos a través de un vínculo privado a menos que la configuración de vínculo privado se aplique también a Resource Manager. Para solucionar esta restricción, puede configurar los recursos para que acepten consultas de redes públicas, como se explica en Control del acceso de red a los recursos. (La ingestión puede seguir limitada a redes de enlaces privadas.) Hemos identificado los siguientes productos y experiencias de consulta de espacios de trabajo a través de Resource Manager:

  • Conector de LogicApp
  • Solución Update Management
  • Solución de seguimiento de cambios
  • El panel Resumen del área de trabajo (en desuso) del portal (que muestra el panel de soluciones)
  • VM Insights
  • Container Insights

Consideraciones de Prometheus administrado

  • La configuración de la ingesta de Private Link se realiza mediante AMPLS y la configuración de los puntos de conexión de recopilación de datos (DCE) que hacen referencia al área de trabajo de Azure Monitor utilizada para almacenar las métricas de Prometheus.
  • La configuración de las consultas de Private Link se realiza directamente en el área de trabajo de Azure Monitor utilizada para almacenar las métricas de Prometheus y no se administra a través de AMPLS.

Requisitos

Tenga en cuenta los siguientes requisitos.

Tamaño de subred de la red

La subred IPv4 más pequeña admitida es /27 (con definiciones de subred CIDR). Aunque las redes virtuales de Azure pueden ser tan pequeñas como /29, Azure reserva cinco direcciones IP. La configuración del vínculo privado de Azure Monitor requiere al menos 11 direcciones IP más, incluso si se conecta a una sola área de trabajo. Revise la configuración de DNS del punto de conexión para obtener la lista de puntos de conexión de vínculo privado de Azure Monitor.

Agentes

Las versiones más recientes de los agentes de Windows y Linux deben usarse para respaldar la ingesta de datos segura en áreas de trabajo de Log Analytics. Las versiones anteriores no pueden cargar datos de supervisión en una red privada.

Agentes Windows de Azure Monitor

Versión 1.1.1.0 o posterior del agente Windows de Azure Monitor (mediante puntos de conexión de recopilación de datos).

Agentes Linux de Azure Monitor

Versión 1.10.5.0 o posterior del agente Linux de Azure Monitor (mediante puntos de conexión de recopilación de datos).

Agente de Windows de Log Analytics (en desuso)

Use la versión 10.20.18038.0, o una posterior, del agente de Log Analytics.

Agente de Linux de Log Analytics (en desuso)

Use la versión 1.12.25, o una posterior, del agente. Si no puede, ejecute los siguientes comandos en la máquina virtual:

$ sudo /opt/microsoft/omsagent/bin/omsadmin.sh -X
$ sudo /opt/microsoft/omsagent/bin/omsadmin.sh -w <workspace id> -s <workspace key>

Azure Portal

Para usar las experiencias del portal de Azure Monitor, como Application Insights, Log Analytics y puntos de conexión de recopilación de datos, debe permitir el acceso a las extensiones de Azure Portal y Azure Monitor en las redes privadas. Agregue las etiquetas de servicio AzureActiveDirectory, AzureResourceManager, AzureFrontDoor.FirstParty y AzureFrontdoor.Frontend al grupo de seguridad de red.

Acceso mediante programación

Para usar la API REST, la CLI de Azure o PowerShell con Azure Monitor en redes privadas, agregue las etiquetas de servicio AzureActiveDirectory y AzureResourceManager al firewall.

Descargas de SDK de Application Insights desde una red de entrega de contenido

Agrupe el código JavaScript en el script para que el explorador no intente descargar código desde una red CDN. En GitHub se proporciona un ejemplo.

Configuración de DNS del explorador

Si se va a conectar a los recursos de Azure Monitor a través de un vínculo privado, el tráfico a estos recursos debe pasar por el punto de conexión privado que está configurado en la red. Para habilitar el extremo privado, actualice la configuración de DNS tal como se explica en Conectarse a un punto de conexión privado. Algunos exploradores usan su propia configuración de DNS en lugar de las que se establecen. Es posible que el explorador intente conectarse a los puntos de conexión públicos de Azure Monitor y omitir por completo el vínculo privado. Compruebe que la configuración de su explorador no invalide ni guarde en caché la configuración de DNS anterior.

Limitación de consultas: operador externaldata

  • No se admite el operador externaldata a través de un vínculo privado, ya que lee los datos de las cuentas de almacenamiento, pero no garantiza que se tenga acceso al almacenamiento de forma privada.
  • El proxy de Azure Data Explorer (proxy ADX) permite que las consultas de registro consulten a Azure Data Explorer. El proxy ADX no es compatible por medio de un vínculo privado, ya que no garantiza el acceso privado al recurso de destino.

Pasos siguientes