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

Al crear un ámbito de Private Link de Azure Monitor (AMPLS), se limita el acceso a los recursos de Azure Monitor solo a las redes conectadas al punto de conexión privado. Este artículo proporciona orientación sobre cómo diseñar la configuración del vínculo privado de Azure Monitor y otras consideraciones que debería tener en cuenta antes de implementarlo realmente utilizando la orientación en Configuración del vínculo privado para Azure Monitor.

Límites de AMPLS

Los objetos AMPLS tienen los límites siguientes:

• 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 AMPLS puede conectarse a hasta 3000 áreas de trabajo de Log Analytics y hasta 10 000 componentes de Application Insights.
• Un recurso de Azure Monitor puede conectarse a hasta 100 AMPLS.
• Un objeto de AMPLS puede conectarse a 10 puntos de conexión privados como máximo.

Planeamiento por topología de red

En las secciones siguientes se describe cómo planear la configuración del vínculo privado de Azure Monitor en función de la topología de red.

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 en 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.

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.

Puede que prefiera crear vínculos privados independientes para sus redes virtuales de spoke para permitir que cada red virtual acceda a un conjunto limitado de recursos de supervisión. En tal caso, 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

Con el emparejamiento de red, las redes pueden compartir las direcciones IP del otro y probablemente compartan el mismo DNS. En tal caso, cree 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 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. A continuación, puede crear 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.

Modos de acceso

Los modos de acceso de Private Link le permiten controlar cómo afectan los vínculos privados al tráfico de red. Lo que seleccione es fundamental para garantizar el tráfico de red continuo e ininterrumpido.

Los modos de acceso se pueden aplicar a todas las redes conectadas a AMPLS o a redes específicas conectadas. La ingesta de datos y las consultas tienen su propia configuración. Por ejemplo, puede establecer el modo de solo privado para la ingesta y el modo Open para las consultas.

Importante

La ingesta de Log Analytics usa puntos de conexión específicos de recursos para que no se ajuste 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.

Modo de acceso solo privado

Modo Solo Privado permite que la red virtual acceda únicamente a los recursos de enlace privado dentro de AMPLS. Esta es la opción más segura y evita la filtración de datos bloqueando el tráfico fuera de AMPLS a los recursos de Azure Monitor.

Modo de acceso abierto

El modo abierto permite que la red virtual llegue tanto a recursos de vínculo privado como a 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 antes de validarlo y, a continuación, se envía a través de la red troncal de Microsoft. El modo abierto es útil para el modo mixto en el que se accede a algunos recursos públicamente y a otros a través de un vínculo privado. También puede ser útil durante un proceso de incorporación gradual.

Importante

Tenga cuidado al seleccionar el modo de acceso. El uso del modo de 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. Si no puede agregar todos los recursos de Azure Monitor al AMPLS, empiece por agregar algunos de ellos y aplicar el modo. Cambie al modo Solo privado para obtener la máxima seguridad solo cuando haya agregado todos los recursos de Azure Monitor a 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.

Control del acceso de red a los recursos de AMPLS

Los componentes de Azure Monitor se pueden establecer en una de las siguientes opciones:

• 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).

Esta granularidad le permite establecer el acceso por área de trabajo según sus necesidades específicas. Por ejemplo, podría aceptar la ingesta solo a través de redes conectadas por vínculos privados pero aún así optar por aceptar consultas de todas las redes, públicas y privadas.

Nota:

Bloquear las consultas de redes públicas significa que los clientes, como máquinas y SDK, fuera del AMPLS conectado 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.

A continuación se muestran excepciones a este acceso a la red:

• Registros de diagnóstico Los registros y las métricas enviados a un área de trabajo desde una configuración de diagnóstico se realizan a través de un canal privado seguro de Microsoft y no están controlados por estas configuraciones.
• Métricas personalizadas o métricas de invitado de Azure Monitor. Las métricas personalizadas enviadas desde el agente de Azure Monitor no están controladas por DCE y no pueden configurarse a través de vínculos privados.

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 obtener acceso si el recurso de destino permite consultas de redes públicas.

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

• El conector de LogicApp
• Solución Update Management
• Solución de seguimiento de cambios
• VM Insights
• Información sobre contenedores
• El panel Resumen del área de trabajo (en desuso) de Log Analytics (que muestra el panel de soluciones)
• Panel Métricas en Application Insights (gráfico de métricas basadas en registros)

Application Insights

• Agregue recursos que hospeden las cargas de trabajo supervisadas a un vínculo privado. Por ejemplo, consulte Uso de puntos de conexión privados para una aplicación web de Azure.
• Las experiencias de uso que no son del portal también tienen que ejecutarse dentro de la red virtual vinculada privada que incluye las cargas de trabajo supervisadas.
• Proporcione su propia cuenta de almacenamiento para admitir vínculos privados para .NET Profiler y Debugger.

Nota:

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

Pasos siguientes

• Aprenda a configurar su vínculo privado.
• Más información sobre el almacenamiento privado para registros personalizados y claves administradas por el cliente.
• Descubre Enlace Privado para Automatización.