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 de 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 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 puede conectarse a hasta cinco 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 radio 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.

Seleccionar un modo de acceso

Los modos de acceso de vínculo privado le permiten controlar cómo afectan los vínculos privados al tráfico de su 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 al AMPLS o a redes específicas conectadas a él. 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.

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

Este modo permite que la red virtual llegue solo a recursos de vínculo privado en 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

Este modo permite que la red virtual llegue tanto a recursos de vínculo privado como a recursos que no estén en el 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 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 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. 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.

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:

• 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:

• 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 especiales

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.

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 con AMPLS.

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.
• Más información sobre Private Link para Automation.