Crie sua configuração de Link Privado do Azure

Antes de configurar sua instância de Link Privado do Azure, considere a topologia de rede e a topologia de roteamento de DNS.

Conforme discutido em Usar o Link Privado do Azure para conectar redes do Azure Monitor, a configuração de um link privado afeta o tráfego de todos os recursos do Azure Monitor. Isso se aplica principalmente aos recursos do Application Insights. Isso afeta não só a rede conectada ao ponto de extremidade privado, mas todas as outras redes que compartilham o mesmo DNS.

A abordagem mais simples e segura:

1. Crie uma única conexão de link privado, com um único ponto de extremidade privado e um único AMPLS (escopo de link privado do Azure Monitor). Se suas redes estiverem emparelhadas, crie a conexão de link privado na rede virtual (ou hub) compartilhada.
2. Adicione todos os recursos do Azure Monitor, como os componentes do Application Insights, workspaces do Log Analytics e pontos de extremidade de coleta de dados a esse AMPLS.
3. Bloquear o tráfego de saída de rede tanto quanto possível.

Se você não puder adicionar todos os recursos do Azure Monitor ao seu AMPLS, ainda poderá aplicar seu link privado a alguns recursos, conforme explicado em Controlar como os links privados se aplicam às redes. Não recomendamos essa abordagem porque ela não impede a exfiltração de dados.

Planeje de acordo com a topologia de rede

Considere a topologia de rede em seu processo de planejamento.

Princípio de orientação: evitar substituições de DNS usando um único AMPLS

Algumas redes são compostas por várias redes virtuais ou outras redes conectadas. Se essas redes compartilharem o mesmo DNS, a configuração de um link privado em qualquer um deles atualizaria o DNS e afetaria o tráfego em todas as redes.

No diagrama a seguir, a rede virtual 10.0.1.x se conecta ao AMPLS1, que cria entradas DNS que mapeiam pontos de extremidade do Azure Monitor para IPs do intervalo 10.0.1.x. Posteriormente, a rede virtual 10.0.2. x se conecta ao AMPLS2, que substitui as mesmas entradas DNS ao mapear os mesmos pontos de extremidade globais/regionais para IPs do intervalo 10.0.2.x. Como essas redes virtuais não estão emparelhadas, a primeira rede virtual agora não consegue alcançar esses pontos de extremidade.

Para evitar esse conflito, crie um único objeto AMPLS por DNS.

Redes hub-and-spoke

As redes de hub e spoke devem usar um único conjunto de conexões de link privado na rede hub (principal) e não em cada rede virtual spoke.

Observação

Você pode preferir criar links privados separados para suas redes virtuais de spoke, por exemplo, para permitir que cada rede virtual acesse um conjunto limitado de recursos de monitoramento. Nesses casos, você pode criar um ponto de extremidade privado dedicado e AMPLS para cada rede virtual. Verifique também se eles não compartilham as mesmas zonas DNS para evitar substituições de DNS.

Redes emparelhadas

O emparelhamento de rede é usado em várias topologias além do hub e spoke. Essas redes podem compartilhar os endereços IP umas das outras, e provavelmente compartilham o mesmo DNS. Nesses casos, crie um único link privado em uma rede acessível para suas outras redes. Evite criar vários pontos de extremidade privados e objetos AMPLS, pois no final apenas o último definido no DNS será aplicado.

Redes isoladas

Se suas redes não estiverem emparelhadas, você também precisará separar os seus DNS para usar links privados. Depois de fazer isso, crie um ponto de extremidade privado separado para cada rede e um objeto AMPLS separado. Seus objetos AMPLS podem se vincular aos mesmos workspaces/componentes ou a diferentes.

Testar localmente: edite o arquivo de hosts do computador em vez do DNS

Para testar links privados localmente sem afetar outros clientes na rede, certifique-se de não atualizar o DNS ao criar o ponto de extremidade privado. Em vez disso, edite o arquivo de hosts em seu computador para que ele envie solicitações aos pontos de extremidade do link privado:

• Configure um link privado, mas ao conectar ao ponto de extremidade privado escolha não integrar automaticamente com o DNS (etapa 5b).
• Configure os pontos de extremidade relevantes nos arquivos de hosts do seu computador. Para revisar os pontos de extremidade do Azure Monitor que precisam de mapeamento, confira Revisar as configurações de DNS de pontos de extremidade.

Não recomendamos essa abordagem para ambientes de produção.

Controlar como o link privado se aplica às redes

Ao usar modos de acesso de link privado, você pode controlar como os links privados afetam o tráfego de rede. Essas configurações podem se aplicar ao objeto AMPLS (para afetar todas as redes conectadas) ou a redes específicas conectadas a ele.

Escolher o modo de acesso adequado é essencial para garantir o tráfego de rede contínuo e ininterrupto. Cada um desses modos pode ser definido para ingestão e consultas, separadamente:

• Somente Privado: permite que a rede virtual alcance apenas recursos de link privado (recursos no AMPLS). Esse é o modo de trabalho mais seguro. Ele impede a exfiltração de dados bloqueando o tráfego fora do AMPLS para recursos do Azure Monitor.
• Aberto: permite que a rede virtual alcance recursos do link privado e recursos que não estão no AMPLS (se eles aceitarem o tráfego de redes públicas). O modo de acesso aberto não impede a exfiltração de dados, mas ainda oferece os outros benefícios dos links privados. O tráfego para recursos de link privado é enviado por meio de pontos de extremidade privados, validados e enviados pelo backbone da Microsoft. O modo aberto é útil para um modo misto de trabalho (acessando alguns recursos publicamente e outros por um link privado) ou durante um processo de integração gradual. Os modos de acesso são definidos de forma separada para ingestão e para consultas. Por exemplo, você pode definir o modo Somente Privado para ingestão e o modo Aberto para consultas.

Tenha cuidado ao selecionar o modo de acesso. O uso do modo de acesso somente privado irá bloquear o tráfego para recursos que não estejam no AMPLS em todas as redes que compartilham o mesmo DNS, independentemente da assinatura ou do locatário. A exceção são as solicitações de ingestão do Log Analytics, o que é explicado. Se você não puder adicionar todos os recursos do Azure Monitor ao AMPLS, comece adicionando os recursos selecionados e aplicando o modo de acesso aberto. Alterne para o modo somente privado para segurança máxima somente depois de adicionar todos os recursos do Azure Monitor ao AMPLS.

Para obter detalhes e exemplos de configuração, confira Usar APIs e a linha de comando.

Observação

A ingestão do Log Analytics usa pontos de extremidade específicos do recurso. Como tal, ela não adere aos modos de acesso AMPLS. Para garantir que as solicitações de ingestão do Log Analytics não possam acessar workspaces fora do AMPLS, defina o firewall de rede para bloquear o tráfego para pontos de extremidade públicos, independentemente dos modos de acesso AMPLS.

Configurar modos de acesso para redes específicas

Os modos de acesso definidos no recurso AMPLS afetam todas as redes, mas é possível substituir essas configurações para redes específicas.

No diagrama a seguir, a VNet1 usa o modo Aberto e a VNet2 usa o modo Somente Privado. As solicitações da VNet1 podem acessar o workspace 1 e o componente 2 por meio de um link privado. As solicitações só poderão acessar o componente 3 somente se ele aceitar o tráfego de redes públicas. As solicitações VNet2 não podem acessar o componente 3.

Analisar os limites do AMPLS

Um objeto AMPLS tem as seguintes limitações:

• Uma rede virtual só pode se conectar a um objeto AMPLS. Isso significa que o objeto AMPLS deve fornecer acesso a todos os recursos do Azure Monitor aos quais a rede virtual deve ter acesso.
• Um objeto AMPLS pode se conectar a 300 workspaces do Log Analytics trabalho e a 1.000 componentes do Application Insights no máximo.
• Um recurso do Azure Monitor (workspace ou componente do Application Insights ou ponto de extremidade de coleta de dados) pode ser conectado a um máximo de cinco AMPLSs.
• Um objeto AMPLS pode se conectar a no máximo dez pontos de extremidade privados.

Observação

Os recursos do AMPLS criados antes de 1º de dezembro de 2021 oferecem suporte a apenas 50 recursos.

No seguinte diagrama:

• Cada rede virtual se conecta a apenas um objeto AMPLS.
• O AMPLS A se conecta a dois workspaces e a um componente do Application Insight, usando dois dos 300 workspaces do Log Analytics possíveis e 1 dos 1.000 possíveis componentes do Application Insights aos quais ele pode se conectar.
• O workspace 2 se conecta ao AMPLS A e ao AMPLS B usando duas das cinco conexões AMPLS disponíveis.
• O AMPLS B é conectado a pontos de extremidade privados de duas redes virtuais (VNet2 e VNet3) usando duas das dez conexões de pontos de extremidades privados disponíveis.

Controlar o acesso de rede aos seus recursos

Os workspaces do Log Analytics ou componentes do Application Insights podem ser definidos como:

• Aceitar ou bloquear a ingestão de redes públicas (redes não conectadas ao recurso AMPLS).
• Aceitar ou bloquear a consulta de redes públicas (redes não conectadas ao recurso AMPLS).

Essa granularidade permite definir o acesso por workspace de acordo com as suas necessidades. Por exemplo, é possível aceitar a ingestão somente por meio de redes conectadas a links privados (como redes virtuais específicas), mas optar ainda por aceitar consultas vindas de todas as redes, públicas ou privadas.

Bloquear consultas vindas de redes públicas significa que os clientes, como computadores e SDKs, de fora dos AMPLSs conectados não podem consultar dados no recurso. Esses dados incluem logs, métricas e o fluxo de métricas ao vivo. O bloqueio de consultas de redes públicas afeta todas as experiências que executarem essas consultas, como pastas de trabalho, dashboards, insights no portal do Azure e as consultas são executados fora do portal do Azure.

Observação

Há algumas exceções em que essas configurações não se aplicam. Encontre os detalhes na próxima seção.

Seus pontos de extremidade de coleta de dados podem ser definidos para aceitar ou bloquear o acesso de redes públicas (redes não conectadas ao AMPLS do recurso).

Para obter informações de configuração, confira Definir sinalizadores de acesso a recursos.

Exceções

Observe as exceções a seguir.

Logs de diagnóstico

Os logs e as métricas carregados em um workspace por meio das configurações de diagnóstico passam por um canal privado e seguro da Microsoft e não são controlados por essas configurações.

Métricas personalizadas ou métricas de convidado do Azure Monitor

As métricas personalizadas (versão prévia) coletadas e carregadas por meio do Agente do Azure Monitor não são controladas por pontos de extremidade da coleta de dados. Elas não podem ser configuradas por links privados.

Azure Resource Manager

A restrição do acesso, explicada anteriormente, se aplica aos dados no recurso. No entanto, alterações de configuração, como ativar ou desativar essas configurações de acesso, são gerenciadas pelo Azure Resource Manager. Para controlar essas configurações, restrinja o acesso aos recursos usando funções, permissões, controles de rede e auditoria apropriados. Para obter mais informações, confira Funções, permissões e segurança do Azure Monitor.

Observação

As consultas enviadas por meio da API do Resource Manager não podem usar links privados do Azure Monitor. Essas consultas só poderão passar se o recurso de destino permitir consultas de redes públicas (definidas por meio do painel Isolamento de Rede ou usando a CLI).

As experiências a seguir são conhecidas por executar consultas por meio da API do Resource Manager:

• Conector do LogicApp
• Solução Gerenciamento de Atualizações
• Solução de Controle de Alterações
• VM Insights
• Insights do contêiner
• Painel de Resumo do Workspace (preterido) do Log Analytics (mostrando o painel de soluções)

Considerações do Application Insights

• Será necessário adicionar recursos que hospedem as cargas de trabalho monitoradas a um link privado. Por exemplo, confira Uso de pontos de extremidade privados para o Aplicativo Web do Azure.
• As experiências de consumo que não são do portal também devem ser executadas na rede virtual vinculada e privada que inclui as cargas de trabalho monitoradas.
• Para oferecer suporte a links privados ao Profiler e ao depurador, você precisa fornecer sua própria conta de armazenamento.

Observação

Para proteger totalmente o Application Insights baseado em workspace, é necessário bloquear o acesso ao recurso do Application Insights e ao workspace subjacente do Log Analytics.

Considerações de custo do Log Analytics

Observe as seguintes considerações do Log Analytics.

Download dos pacotes de soluções do Log Analytics

Os agentes do Log Analytics precisam acessar uma conta de armazenamento global para baixar pacotes de solução. As configurações de link privado criadas em ou após 19 de abril de 2021 (ou a partir de junho de 2021 nas nuvens soberanas do Azure) podem alcançar o armazenamento de pacotes de soluções dos agentes por meio do link privado. Essa funcionalidade é possível por meio de uma zona DNS criada para o blob.core.windows.net.

Se a configuração do link privado foi criada antes de 19 de abril de 2021, ela não acessará o armazenamento de pacotes de soluções por meio de um link privado. Para lidar com isso, você pode:

• Recriar seu AMPLS e o ponto de extremidade privado conectado a ele.

• Permitir que os agentes acessem a conta de armazenamento por meio do ponto de extremidade público, adicionando as seguintes regras à lista de permitidos do firewall:

  Ambiente de nuvem	recurso de agente	Portas	Direção
  Público do Azure	scadvisorcontent.blob.core.windows.net	443	Saída
  Azure Government	usbn1oicore.blob.core.usgovcloudapi.net	443	Saída
  Microsoft Azure operado pela 21Vianet	mceast2oicore.blob.core.chinacloudapi.cn	443	Saída

Coletar logs personalizados e logs do IIS por meio de link privado

As contas de armazenamento são usadas no processo de ingestão de logs personalizados. Por padrão, são usadas contas de armazenamento gerenciadas por serviços. Para ingerir logs personalizados em links privados, você deve usar suas contas de armazenamento e associá-las aos workspaces do Log Analytics.

Para obter mais informações sobre como conectar sua própria conta de armazenamento, confira Contas de armazenamento de propriedade do cliente para ingestão de log e, especificamente, Usar links privados e Vincular contas de armazenamento ao seu workspace do Log Analytics.

Automação

Se você usa soluções do Log Analytics que requerem uma conta da Automação do Azure (como Gerenciamento de Atualizações, Controle de Alterações ou Inventário), você também deve criar um link privado para sua conta da Automação. Para saber mais informações, consulte como Usar o Link Privado do Azure para conectar redes com segurança à Automação do Azure.

Observação

Alguns produtos e experiências do portal do Azure consultam dados por meio do Resource Manager. Nesse caso, eles não poderão consultar dados através de um link privado, a menos que as configurações do link privado também sejam aplicadas ao Resource Manager. Para contornar essa limitação, você pode configurar seus recursos para que aceitem consultas de redes públicas, conforme explicado em Controlar o acesso de rede aos seus recursos. (A ingestão pode permanecer limitada a redes de link privado.) Identificamos os seguintes workspaces de consulta de produtos e experiências por meio do Resource Manager:

• Conector do LogicApp
• Solução Gerenciamento de Atualizações
• Solução de Controle de Alterações
• O painel Resumo do Workspace (preterido) no portal (que mostra o painel de soluções)
• VM Insights
• Insights do contêiner

Considerações sobre o Prometheus gerenciado

• As configurações de ingestão do Link Privado são feitas usando AMPLS e configurações nos Pontos de Extremidade de Coleta de Dados (DCEs) que fazem referência ao workspace do Azure Monitor usado para armazenar suas métricas do Prometheus.
• As configurações de consulta do Link Privado são feitas diretamente no workspace do Azure Monitor usado para armazenar suas métricas do Prometheus, e não são tratadas por meio do AMPLS.

Requisitos

Observe os seguintes requisitos.

Tamanho da sub-rede da rede

A menor sub-rede IPv4 com suporte é /27 (usando definições de sub-rede CIDR). Embora as redes virtuais do Azure possam ser tão pequenas quanto /29, o Azure reserva cinco endereços IP. A configuração do link privado do Azure Monitor requer pelo menos mais 11 endereços IP, mesmo que você esteja se conectando a um único workspace. Revise as configurações de DNS do ponto de extremidade para obter a lista dos pontos de extremidade de link privado do Azure Monitor.

Agentes

As versões mais recentes dos agentes do Windows e do Linux devem ser usadas para dar suporte à ingestão segura para workspaces do Log Analytics. As versões mais antigas não conseguem carregar dados de monitoramento em uma rede privada.

Agentes do Azure Monitor para Windows

O agente do Azure Monitor para Windows versão 1.1.1.0 ou superior (usando pontos de extremidade de coleta de dados).

Agentes do Azure Monitor para Linux

Agente do Azure Monitor para Linux versão 1.10.5.0 ou superior (usando pontos de extremidade de coleta de dados).

Agente do Log Analytics para Windows (em processo de desativação)

Use o agente do Log Analytics versão 10.20.18038.0 ou posterior.

Agente do Log Analytics para Linux (em processo de desativação)

Use o agente na versão 1.12.25 ou posterior. Se isso não for possível, execute os comandos a seguir na sua VM:

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

Portal do Azure

Para usar as experiências do portal do Azure Monitor, como o Application Insights, o Log Analytics e pontos de extremidade de coleta de dados, você precisa permitir que o portal do Azure e as extensões do Azure Monitor estejam acessíveis nas redes privadas. Adicione as marcas de serviçoAzureActiveDirectory, AzureResourceManager, AzureFrontDoor.FirstParty e AzureFrontdoor.Frontend ao seu grupo de segurança de rede.

Acesso Programático

Para usar a API REST, a CLI do Azure ou o PowerShell com o Azure Monitor em redes privadas, adicione as marcas de serviçoAzureActiveDirectory e AzureResourceManager ao firewall.

Downloads do SDK do Application Insights em uma rede de distribuição de conteúdo

Agrupe o código JavaScript no seu script para que o navegador não tente baixar código de uma CDN. Confira um exemplo no GitHub.

Configurações de DNS do navegador

Se você estiver se conectando aos recursos do Azure Monitor por meio de um link privado, o tráfego para esses recursos deverá passar pelo ponto de extremidade privado configurado em sua rede. Para habilitar o ponto de extremidade privado, atualize suas configurações de DNS conforme explicado em Conectar-se a um ponto de extremidade privado. Alguns navegadores usam suas próprias configurações de DNS em vez daquelas que você definiu. O navegador pode tentar se conectar aos pontos de extremidade públicos do Azure Monitor e ignorar totalmente o link privado. Verifique se as configurações do navegador não substituem ou armazenam em cache configurações antigas de DNS.

Limitação de consulta: operador externaldata

• O externaldata operador não tem suporte em um link privado, pois ele lê dados de contas de armazenamento, mas não garante que o armazenamento seja acessado de maneira privada.
• O Proxy do Azure Data Explorer (proxy ADX) permite que as consultas de log consultem o Azure Data Explorer. O proxy ADX não é compatível com um link privado porque não garante que o recurso de destino seja acessado de forma privada.

Próximas etapas

• Saiba mais sobre como configurar seu link privado.
• Saiba mais sobre o armazenamento privado para logs personalizados e chaves gerenciadas pelo cliente.
• Saiba mais sobre o link privado para automação.