Integração de rede com Azure SRE Agent

A integração da rede virtual (VNet) controla onde o Agente SRE pode enviar tráfego de saída. Sem ele, as chamadas de saída passam pela Internet pública. Com ele, o tráfego passa pela sua Rede Virtual do Azure. Essa integração de rede oferece os mesmos controles em nível de rede que você usa para outras cargas de trabalho do Azure: integração com firewalls, comunicação com recursos atrás de endpoints privados e visibilidade nos seus logs de rede.

Modos de controle de rede

O Agente SRE oferece três modos de controle de rede. Selecione o modo que corresponde à postura de segurança e ao contexto operacional.

Modo Description Mais adequado para
Irrestrito Nenhuma restrição de rede. O agente pode acessar qualquer terminal na internet. Cargas de trabalho de desenvolvimento, teste e não confidenciais.
Limited A lista de permissões de URL baseada em curinga controla os pontos de extremidade que o agente pode chamar. Controle no nível do host sem roteamento de VNet completo.
Azure VNet Todo o tráfego de saída que não é da plataforma é roteado por meio da sua VNet, com suas regras de DNS e firewall aplicadas. Implantações de produção que exigem controle de tráfego de saída e conformidade com requisitos de auditoria.

Escolha um modo de controle de rede para sua carga de trabalho

Use os seguintes critérios para selecionar um modo:

  • Azure VNet: escolha esse modo se a carga de trabalho lida com dados confidenciais ou regulamentados, requer uma trilha de auditoria completa da atividade de rede de saída ou deve estar em conformidade com as políticas de segurança da empresa. Esse modo é recomendado para implantações empresariais de produção.

  • Limitado: escolha esse modo se quiser restringir destinos externos específicos sem rotear todo o tráfego por meio de uma rede virtual. Esse modo funciona bem quando você precisa de controle parcial sem a sobrecarga da configuração de rede virtual completa.

  • Irrestrito: escolha esse modo se a carga de trabalho for um ambiente de teste ou desenvolvimento de curto prazo sem acesso a dados confidenciais. Esse modo é o padrão.

Para selecionar um modo, abra seu agente no portal do Azure e selecione Configurações>Configuração do workspace. Alternar entre modos num agente em execução. As configurações persistem entre as alterações de modo.

Captura de tela da configuração do workspace do Agente SRE no Azure mostrando as opções do modo de controle de rede: irrestrito, limitado e Azure VNet.

Como funciona Azure modo VNet

No modo VNet Azure, o tráfego de saída usa um dos dois caminhos:

Sua VNet. Por padrão, todo o tráfego de saída não plataforma passa por uma sub-rede delegada em sua rede virtual. As suas regras de NSG, as políticas de firewall, o DNS personalizado e os logs de rede são todos aplicados. O agente está sujeito aos mesmos controles que qualquer outra carga de trabalho nessa sub-rede. Ele pode acessar tudo o que a sub-rede pode acessar, e nada mais.

O agente pode acessar recursos por trás de endpoints privados, serviços internos e sistemas locais conectados via ExpressRoute ou VPN, desde que as rotas e regras da sua rede permitam.

Rede de infraestrutura do Agente SRE do Azure. Os serviços de plataforma de que o agente depende (orquestração, pontos de extremidade de modelo, telemetria) são sempre roteados pela infraestrutura gerenciada da Microsoft. Esses serviços não são configuráveis. Alguns recursos do agente, como instalação de pacote, acesso ao repositório de código e servidores MCP remotos, exigem a obtenção de serviços públicos. Para usar esses recursos no modo de VNet do Azure, habilite o botão de alternância correspondente. Se uma opção estiver desativada, esse recurso ficará indisponível, a menos que sua VNet possa rotear diretamente para esses serviços (por exemplo, com regras de firewall baseadas em FQDN). Consulte rede de infraestrutura do Agente SRE no Azure para obter detalhes.

Resumo do roteamento de tráfego

Tipo de tráfego Caminho Configurável?
Sua infraestrutura de Azure (Log Analytics, App Insights, AKS, bancos de dados, Key Vaults) Sua VNet Sim. Roteado pela VNet por padrão.
Sistemas locais (ExpressRoute/VPN) Sua VNet Sim. Acessível se suas rotas de rede permitirem.
Serviços de plataforma (orquestração, pontos de extremidade de modelo, telemetria) Rede de infraestrutura do Agente SRE do Azure Não. Sempre encaminhado pela infraestrutura gerenciada.
Registros de pacote (PyPI, npm, NuGet, apt) Rede de infraestrutura do Agente SRE (alternância) ou VNet (regra FQDN) Sim. Alternância por registro ou pacotes de pré-instalação
Repositórios de código (GitHub, GHE, Azure DevOps) Rede de infraestrutura do Agente SRE (alternância) ou VNet (regra FQDN) Sim. Alternância por provedor
Servidores MCP remotos Rede de infraestrutura do Agente SRE (alternância) ou VNet (regra FQDN) Sim. Alternância única
Nomes de host adicionais Rede de infraestrutura do Agente SRE (para os hosts da lista) Sim. Lista personalizada
Tráfego do conector Internet pública Não. Não é roteado pelo VNet.
Entrada (ponto de extremidade privado) Sem suporte Não. Só saída.

Configurar o modo VNet do Azure

Requisitos de sub-rede

O modo VNet do Azure requer uma sub-rede dedicada em sua rede virtual:

  • Tamanho: /27 ou maior.
  • Delegação: a sub-rede deve ser delegada para Microsoft.App/environments.
  • Região: a sub-rede deve estar na mesma região que o recurso do Agente SRE.
  • Dedicada: a sub-rede não pode ser compartilhada com outros serviços.

Configurar o modo VNet do Azure

  1. Vá para Configurações>Configuração do workspace>Rede.
  2. Selecione Azure VNet como o modo de saída.
  3. Selecione Navegar pelas sub-redes.
  4. Selecione sua assinatura, grupo de recursos, rede virtual e sub-rede que atenda aos requisitos de sub-rede.
  5. Selecione Salvar.
  6. Teste o agente com um incidente representativo para confirmar que ele pode alcançar os recursos necessários.

Rede de infraestrutura do Agente SRE do Azure

Alguns recursos de agente dependem de serviços públicos com dificuldade de permitir listagem por endereço IP. No modo de VNet do Azure, esses recursos exigem uma alternância de rede de infraestrutura (que roteia essa categoria via rede de infraestrutura do Agente SRE do Azure) ou regras de firewall baseadas em FQDN na VNet que permitam o tráfego diretamente. Confira o resumo do roteamento de tráfego para obter a lista completa de categorias e caminhos.

Se você desativar uma opção e sua VNet não conseguir alcançar o serviço, esse recurso ficará indisponível.

Note

Você pode aplicar uma Política do Azure para restringir ou desativar as opções de alternância da rede de infraestrutura, para garantir que nenhum operador possa encaminhar tráfego para fora da VNet.

Pacotes pré-instalados

Pré-instale pacotes na imagem de disco base da sandbox para que fiquem disponíveis cada vez que o agente for executado. Esse recurso é útil quando suas ferramentas ou scripts dependem de pacotes específicos que não estão incluídos no ambiente de área restrita padrão.

Para configurar pacotes pré-instalados:

  1. Abra seu agente no portal do Azure e selecione Settings>Workspace configuration.

  2. Selecione a guia Pacotes .

  3. Insira o nome do pacote, selecione o gerenciador de pacotes (pip ou NuGet) e, opcionalmente, especifique uma versão.

  4. Selecione + Adicionar pacote.

Captura de tela da guia Pacotes na configuração do workspace do Azure SRE Agent, mostrando campos para nome do pacote, gerenciador de pacotes e versão.

Note

As entradas do NuGet devem ser .NET ferramentas da CLI (por exemplo, dotnet-ef). Você não pode instalar pacotes de biblioteca globalmente.

Controles de desvio da rede virtual

Quando você habilita o modo VNet do Azure, a seção Na rede de infraestrutura da página de configuração do espaço de trabalho permite rotear categorias de tráfego para fora da sua VNet pela internet pública. Se você não habilitar nenhum desses controles, todo o tráfego do agente será roteado pela sua VNet.

Nem todos os serviços externos fornecem uma marca de serviço Azure. GitHub, por exemplo, não é um serviço de Azure e não expõe uma marca de serviço. Se o agente precisar acessar o GitHub, sua única opção com um firewall de Camada 4 baseado em IP é manter uma lista dos endereços IP do provedor. Essas listas mudam com frequência, e um firewall que não se mantém atualizado faz o agente parar de funcionar.

O mesmo vale para vários serviços públicos importantes, como PyPI, npm, NuGet e registros de contêiner. Esses serviços operam de intervalos de IP globais grandes e frequentemente alterados e não são cobertos por marcas de serviço Azure.

As opções de bypass permitem que o agente acesse esses hosts usando a saída da plataforma. Sua equipe de rede atualiza regras de firewall ou passa para um firewall que dá suporte à filtragem de nome de host ou à filtragem de FQDN (nome de domínio totalmente qualificado). Exemplos incluem Firewall do Azure Premium com regras FQDN ou um dispositivo virtual de rede que dá suporte à inspeção de Segurança de Camada de Transporte.

Trate os controles de bypass como uma ferramenta temporária, não como um substituto permanente para a filtragem de saída com reconhecimento de nomes do host.

Os controles a seguir estão disponíveis:

Controle Description
Acesso ao servidor do Model Context Protocol (Protocolo de Contexto de Modelo - MCP) Quando habilitado, o tráfego do servidor MCP é roteado pela Internet pública em vez de sua rede virtual.
Acesso ao gerenciador de pacotes Quando habilitado, o tráfego do gerenciador de pacotes (PyPI, npm, NuGet) roteia pela Internet pública em vez de sua rede virtual.
Repositórios de código Selecione quais provedores de repositório de código (GitHub, GitHub Enterprise Azure DevOps) roteiam pela Internet pública em vez de sua rede virtual.
Hosts adicionais Insira nomes de host adicionais ou padrões curinga (por exemplo, github.com, *.example.com, raw.contoso.io) para serem roteados pela internet pública em vez de pela sua rede virtual. Os pacotes configurados permitem automaticamente hosts próprios.

Considerações de governança

O acesso a esses controles é restrito aos usuários com a função de Administrador do Agente SRE. Criar um agente SRE em um ambiente empresarial é, em si, um ato de governança significativo porque as organizações normalmente exigem aprovação substancial para implantar serviços em produção. Os controles de bypass são um aspecto do contexto mais amplo da governança corporativa, que inclui identidade gerenciada, credenciais OBO (em nome de) e permissões RBAC. O agente só pode fazer o que suas permissões permitem, e a configuração da rede controla para onde esse tráfego vai.

Inspecionar atividade de rede

Os administradores podem abrir Configurações>Configuração do workspace>Inspecionar e usar Auditoria de rede para revisar as solicitações de saída do agente filtradas como permitidas e negadas. Use o host, método, caminho e decisão para identificar destinos bloqueados pela política Limited ou Azure VNet.

A auditoria de rede abrange apenas decisões de política de saída do agente. Não é uma trilha completa de auditoria de rede e não inclui todos os eventos de runtime, conectores, plataformas, firewalls, DNS ou proxy.

O que acontece quando a rede bloqueia uma chamada

Se uma solicitação de saída for negada por uma regra NSG ou não tiver rota, o agente verá o mesmo erro de rede que outras cargas de trabalho nessa sub-rede. O agente relata a falha no resultado da investigação (por exemplo, "Não foi possível acessar o espaço de trabalho do Log Analytics: tempo limite de conexão esgotado") e continua com as ferramentas e os dados que consegue acessar. Se uma fonte de dados crítica for inacessível, a investigação estará incompleta e o agente relatará essa condição.

Limitações

As limitações a seguir se aplicam.

  • Somente saída: a integração de rede virtual controla apenas o tráfego de saída (a saída). Não há suporte para conexões de entrada com o agente de dentro de uma rede privada.

  • Conectores não roteiam pela rede virtual: o tráfego de conectores roteia pela internet pública.

Conteúdo relacionado

  • Last updated on