Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La integración de redes virtuales (VNet) controla dónde el Agente SRE puede enviar tráfico saliente. Sin él, las llamadas salientes fluyen por internet público. Con ella, el tráfico pasa por tu Azure Virtual Network. Esta integración de red te proporciona los mismos controles a nivel de red que usas para otras cargas de trabajo de Azure: integración con cortafuegos, comunicación con recursos detrás de endpoints privados y visibilidad en tus registros de red.
Modos de control de red
El Agente SRE ofrece tres modos de control de red. Seleccione el modo que coincida con la posición de seguridad y el contexto operativo.
| Modo | Description | Más adecuado para |
|---|---|---|
| Sin restricciones | Sin restricciones de red. El agente puede acceder a cualquier punto de conexión de Internet. | Cargas de trabajo de desarrollo, pruebas y no confidenciales. |
| Limitado | La dirección URL basada en caracteres comodín permite controles de lista de los puntos de conexión a los que puede llamar el agente. | Control a nivel de host sin enrutamiento completo de la VNet. |
| red virtual de Azure | Todo el tráfico saliente que no sea de plataforma se enruta a través de la red virtual con las reglas de firewall y DNS aplicadas. | Implementaciones de producción que requieren control del tráfico saliente y cumplimiento de los requisitos de auditoría. |
Elección de un modo de control de red para la carga de trabajo
Use los criterios siguientes para seleccionar un modo:
Azure red virtual: elija este modo si la carga de trabajo controla datos confidenciales o regulados, requiere una pista de auditoría completa de la actividad de red saliente o debe cumplir con las directivas de seguridad de la empresa. Este modo se recomienda para las implementaciones empresariales de producción.
Limitado: elija este modo si desea restringir destinos externos específicos sin enrutar todo el tráfico a través de una red virtual. Este modo funciona bien cuando se necesita un control parcial sin la sobrecarga de la configuración de red virtual completa.
Sin restricciones: elija este modo si la carga de trabajo es un entorno de prueba o desarrollo a corto plazo sin acceso a datos confidenciales. Este modo es el valor predeterminado.
Para seleccionar un modo, abra el agente en el portal de Azure y seleccione Configuración del> área detrabajo. Cambiar de modo en un agente en ejecución. La configuración se mantiene al cambiar de modo.
Funcionamiento del modo de red virtual de Azure
En el modo de Azure VNet, el tráfico saliente sigue una de estas dos rutas:
La red virtual. De forma predeterminada, todo el tráfico saliente que no es de la plataforma pasa por una subred delegada en la red virtual. Se aplican las reglas de NSG, las directivas de firewall, el DNS personalizado y todos los registros de red. El agente está sujeto a los mismos controles que cualquier otra carga de trabajo de esa subred. Puede llegar a lo que puede llegar la subred y nada más.
El agente puede llegar a recursos detrás de puntos de conexión privados, servicios internos y sistemas locales conectados a través de ExpressRoute o VPN, siempre y cuando las rutas y reglas de red lo permitan.
Red de infraestructura del agente SRE de Azure Los servicios de plataforma de los que depende el agente (orquestación, puntos de conexión del modelo y telemetría) siempre se canalizan a través de la infraestructura gestionada de Microsoft. Estos servicios no son configurables. Algunas funcionalidades del agente, como la instalación de paquetes, el acceso al repositorio de código y los servidores MCP remotos requieren alcanzar los servicios públicos. Para usar estas capacidades en el modo Azure VNet, habilite el interruptor correspondiente. Si un interruptor está desactivado, esa capacidad no estará disponible a menos que su VNet pueda enrutar directamente a esos servicios (por ejemplo, mediante reglas de firewall basadas en nombres de dominio completos (FQDN)). Consulte infraestructura de red del agente SRE de Azure para obtener más detalles.
Resumen del enrutamiento del tráfico
| Tipo de tráfico | Camino | ¿Configurable? |
|---|---|---|
| La infraestructura de Azure (Log Analytics, App Insights, AKS, bases de datos, Almacenes de claves) | Su VNet | Yes. Se enruta a través de su VNet de forma predeterminada. |
| Sistemas locales (ExpressRoute/VPN) | Su VNet | Yes. Accesible si las rutas de red lo permiten. |
| Servicios de plataforma (orquestación, puntos de conexión de modelo, telemetría) | infraestructura del agente de SRE de Azure | N.º Siempre a través de infraestructura gestionada. |
| Registros de paquetes (PyPI, npm, NuGet, apt) | Red de infraestructura de SRE Agent (habilitar) o su red virtual (regla de FQDN) | Yes. Alternancia por registro o preinstalación de paquetes |
| Repositorios de código (GitHub, GHE, Azure DevOps) | Red de infraestructura de SRE Agent (habilitar) o su red virtual (regla de FQDN) | Yes. Alternancia por proveedor |
| Servidores MCP remotos | Red de infraestructura de SRE Agent (habilitar) o su red virtual (regla de FQDN) | Yes. Alternancia única |
| Nombres de host adicionales | Infraestructura de red de SRE Agent(para los hosts de la lista) | Yes. Lista personalizada |
| Tráfico a través del conector | Red pública de Internet | N.º No se enruta a través de VNet. |
| Entrada (punto de conexión privado) | No soportado | N.º Solo salida. |
Configuración del modo de red virtual de Azure
Requisitos de subred
El modo VNet de Azure requiere una subred dedicada en su red virtual:
- Tamaño: /27 o más.
-
Delegación: la subred debe delegarse en
Microsoft.App/environments. - Región: la subred debe estar en la misma región que el recurso del agente de SRE.
- Dedicado: la subred no se puede compartir con otros servicios.
Configuración del modo de red virtual de Azure
- Vaya a Configuración>Configuración del área de trabajo>Red.
- Seleccione Azure red virtual como modo de salida.
- Seleccione Examinar subredes.
- Seleccione la suscripción, el grupo de recursos, la red virtual y la subred que cumplen los requisitos de subred.
- Haga clic en Guardar.
- Pruebe el agente con un incidente representativo para confirmar que puede tener acceso a los recursos que necesita.
infraestructura del agente de SRE de Azure
Algunas funcionalidades del agente dependen de servicios de acceso público que son difíciles de incluir en una lista de permitidos por dirección IP. En el modo de Azure VNet, estas capacidades requieren una opción de red de infraestructura (que enruta esa categoría de tráfico a través de la red de infraestructura de Azure SRE Agent) o reglas de firewall basadas en FQDN en su red virtual que permitan ese tráfico directamente. Consulte el resumen del enrutamiento de tráfico para obtener la lista completa de categorías y rutas de acceso.
Si desactivas un interruptor y tu VNet no puede acceder al servicio, esa capacidad no estará disponible.
Note
Puede aplicar una directiva de Azure para restringir o deshabilitar los controles de red de infraestructura, lo que garantiza que ningún operador pueda redirigir el tráfico fuera de la VNet.
Paquetes preinstalados
Preinstale paquetes en la imagen de disco base del espacio aislado para que estén disponibles cada vez que se ejecute el agente. Esta característica es útil cuando las herramientas o scripts dependen de paquetes específicos que no se incluyen en el entorno de espacio aislado predeterminado.
Para configurar paquetes preinstalados:
Abra el agente en el portal de Azure y seleccione Settings>Configuración deWorkspace.
Seleccione la pestaña Paquetes .
Escriba el nombre del paquete, seleccione el administrador de paquetes (pip o NuGet) y, opcionalmente, especifique una versión.
Seleccione + Agregar paquete.
Note
Las entradas de NuGet deben ser .NET herramientas de la CLI (por ejemplo, dotnet-ef). No se pueden instalar paquetes de biblioteca globalmente.
Controles para omitir la red virtual
Al habilitar el modo de red virtual de Azure, la sección En la red de infraestructura de la página de configuración del espacio de trabajo permite enrutar categorías de tráfico fuera de su red virtual a través de la Internet pública. Si no habilitas ninguno de estos controles, todo el tráfico del agente se enruta a través de tu VNet.
No todos los servicios externos proporcionan una etiqueta de servicio Azure. GitHub, por ejemplo, no es un servicio Azure y no expone una etiqueta de servicio. Si el agente necesita llegar a GitHub, la única opción con un firewall basado en IP de nivel 4 es mantener una lista de las direcciones IP del proveedor. Esas listas cambian con frecuencia y un firewall que no se mantiene actualizado hace que el agente deje de funcionar.
Lo mismo sucede con varios servicios públicos importantes, como PyPI, npm, NuGet y registros de contenedor. Estos servicios funcionan desde intervalos IP globales de gran tamaño y con frecuencia no están cubiertos por etiquetas de servicio Azure.
Los botones de alternancia de omisión permiten al agente tener acceso a estos hosts a través de la salida de la plataforma. El equipo de red actualiza las reglas del cortafuegos o migra a un cortafuegos que admite el filtrado por nombre de host o el filtrado por nombre de dominio completo (FQDN). Entre los ejemplos se incluyen Azure Firewall Premium con reglas FQDN o una aplicación virtual de red que admita la inspección de seguridad de la capa de transporte.
Considere los controles de omisión como una herramienta transitoria, no como un sustituto permanente del filtrado de salida basado en nombres de host.
Están disponibles los siguientes controles:
| Supervisión | Description |
|---|---|
| Acceso al servidor del Protocolo de contexto de modelo (MCP) | Cuando se habilita, el tráfico del servidor MCP se enruta a través de la red pública de Internet en lugar de la red virtual. |
| Acceso al administrador de paquetes | Cuando está habilitada, el tráfico del administrador de paquetes (PyPI, npm, NuGet) se enruta a través de la red pública de Internet en lugar de la red virtual. |
| Repositorios de código | Seleccione qué proveedores de repositorios de código (GitHub, GitHub Enterprise, Azure DevOps) se conectan a través de Internet pública en lugar de hacerlo a través de su red virtual. |
| Servidores adicionales | Escriba nombres de host adicionales o patrones comodín (por ejemplo, github.com, *.example.com, raw.contoso.io) para enrutar a través de la red pública de Internet en lugar de la red virtual. Los paquetes configurados permiten automáticamente sus propios hosts. |
Consideraciones de gobernanza
El acceso a estos controles está restringido a los usuarios con el rol de Administrador del SRE Agent. La creación de un agente de SRE en un entorno empresarial es un acto de gobernanza importante porque las organizaciones suelen requerir una aprobación sustancial para implementar servicios en producción. Los controles de omisión forman parte del marco más amplio de gobernanza empresarial, que incluye identidades administradas, credenciales en nombre de (OBO) y permisos de RBAC. El agente solo puede hacer lo que permiten sus permisos y la configuración de red controla dónde va ese tráfico.
Inspeccionar actividad de red
Los administradores pueden abrir Configuración>Configuración del espacio de trabajo>Inspeccionar y usar Auditoría de red para revisar las solicitudes salientes del agente filtradas, permitidas y denegadas. Utiliza el host, método, ruta y decisión para identificar los destinos bloqueados por la política Limited o Azure VNet.
La auditoría de red cubre únicamente las decisiones de política de salida de agentes. No es una auditoría completa de red y no incluye todos los eventos de ejecución, conectores, plataformas, cortafuegos, DNS o proxys.
¿Qué ocurre cuando la red bloquea una llamada?
Si una solicitud saliente es denegada por una regla de NSG o no tiene ruta, el agente ve el mismo error de red que vería cualquier carga de trabajo en esa subred. El agente informa del fallo en el resultado de su investigación (por ejemplo, "No se pudo acceder al área de trabajo de Log Analytics: se agotó el tiempo de espera de la conexión") y continúa con las herramientas y los datos a los que puede acceder. Si un origen de datos crítico no es accesible, la investigación está incompleta y el agente notifica esta condición.
Limitaciones
Se aplican las siguientes limitaciones.
Solo salida: la integración de red virtual solo controla el tráfico saliente (salida). No se permiten conexiones entrantes hacia el agente desde dentro de una red privada.
Los conectores no se enrutan a través de la red virtual: el tráfico de los conectores se enruta por la Internet pública.