Projetar sua configuração de Link Privado do Azure

  • Artigo

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

Conforme discutido em Usar o Link Privado do Azure para conectar redes ao Azure Monitor, a configuração de um link privado afeta o tráfego para todos os recursos do Azure Monitor. Isso é especialmente verdadeiro para os recursos do Application Insights. Também afeta não só a rede conectada ao ponto de extremidade privado, mas também 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 (Azure Monitor Private Link Scope). Se suas redes estiverem emparelhadas, crie a conexão de link privado na rede virtual compartilhada (ou hub).
  2. Adicione todos os recursos do Azure Monitor, como componentes do Application Insights, espaços de trabalho do Log Analytics e pontos de extremidade de coleta de dados ao AMPLS.
  3. Bloqueie o tráfego de saída da 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 suas redes. Não recomendamos essa abordagem porque ela não impede a exfiltração de dados.

Planejar por topologia de rede

Considere a topologia de rede em seu processo de planejamento.

Princípio orientador: 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 uma delas atualizará o DNS e afetará 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. Mais tarde, a rede virtual 10.0.2.x se conecta ao AMPLS2, que substitui as mesmas entradas DNS mapeando os mesmos pontos de extremidade globais/regionais para IPs do intervalo 10.0.2.x. Como essas redes virtuais não são emparelhadas, a primeira rede virtual agora não consegue alcançar esses pontos de extremidade.

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

Diagram that shows DNS overrides in multiple virtual networks.

Redes hub-and-spoke

As redes Hub-and-spoke devem usar uma única conexão de link privado definida na rede hub (principal), e não em cada rede virtual spoke.

Diagram that shows a hub-and-spoke single private link.

Nota

Você pode preferir criar links privados separados para suas redes virtuais faladas, 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. Você também deve verificar 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 de hub e spoke. Essas redes podem compartilhar os endereços IP uns dos outros e, muito provavelmente, compartilhar o mesmo DNS. Nesses casos, crie um único link privado em uma rede acessível às suas outras redes. Evite criar vários pontos de extremidade privados e objetos AMPLS porque, em última análise, apenas o último conjunto no DNS se aplica.

Redes isoladas

Se suas redes não estiverem emparelhadas, você também deverá separar o DNS delas para usar links privados. Depois disso, crie um ponto de extremidade privado separado para cada rede e um objeto AMPLS separado. Seus objetos AMPLS podem ser vinculados aos mesmos espaços de trabalho/componentes ou a outros diferentes.

Testando localmente: edite o arquivo de hosts da sua máquina em vez do DNS

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

  • Configure um link privado, mas quando você se conectar a um ponto de extremidade privado, opte por não se integrar automaticamente com o DNS (etapa 5b).
  • Configure os pontos de extremidade relevantes nos arquivos hosts de suas máquinas. Para revisar os pontos de extremidade do Azure Monitor que precisam de mapeamento, consulte Revisar as configurações de DNS do seu ponto de extremidade.

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

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

Escolher o modo de acesso adequado é fundamental para garantir tráfego de rede contínuo e ininterrupto. Cada um destes 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 dos recursos do AMPLS para o Azure Monitor. Diagram that shows the AMPLS Private Only access mode.
  • Aberto: Permite que a rede virtual alcance recursos de link privado e recursos que não estão no AMPLS (se eles aceitarem 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, validado e enviado pelo backbone da Microsoft. O modo Aberto é útil para um modo misto de trabalho (acesso a alguns recursos publicamente e outros através de um link privado) ou durante um processo de integração gradual. Diagram that shows the AMPLS Open access mode. Os modos de acesso são definidos separadamente para ingestão e 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. Usar o modo de acesso Somente privado bloqueará o tráfego para recursos que não estão no AMPLS em todas as redes que compartilham o mesmo DNS, independentemente da assinatura ou locatário. A exceção são as solicitações de ingestão do Log Analytics, que são explicadas. Se não for possível adicionar todos os recursos do Azure Monitor ao AMPLS, comece adicionando recursos selecionados e aplicando o modo de acesso aberto. Mude para o modo Apenas Privado para máxima segurança apenas depois de adicionar todos os recursos do Azure Monitor ao seu AMPLS.

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

Nota

A ingestão do Log Analytics usa pontos de extremidade específicos de recursos. Como tal, não adere aos modos de acesso AMPLS. Para garantir que as solicitações de ingestão do Log Analytics não possam acessar espaços de trabalho 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.

Definir modos de acesso para redes específicas

Os modos de acesso definidos no recurso AMPLS afetam todas as redes, mas você pode 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 chegar ao Espaço de Trabalho 1 e ao Componente 2 por meio de um link privado. As solicitações podem chegar ao Componente 3 somente se ele aceitar tráfego de redes públicas. As solicitações de VNet2 não podem acessar o Componente 3. Diagram that shows mixed access modes.

Considere os limites da AMPLS

O objeto AMPLS tem os seguintes limites:

  • Uma rede virtual pode se conectar a apenas 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 espaços de trabalho do Log Analytics e 1.000 componentes do Application Insights, no máximo.
  • Um recurso do Azure Monitor (espaço de trabalho ou componente do Application Insights ou ponto de extremidade de coleta de dados) pode se conectar a cinco AMPLSs no máximo.
  • Um objeto AMPLS pode se conectar a no máximo 10 pontos de extremidade privados.

Nota

Os recursos da AMPLS criados antes de 1º de dezembro de 2021 suportam apenas 50 recursos.

No diagrama a seguir:

  • Cada rede virtual se conecta a apenas um objeto AMPLS.
  • O AMPLS A se conecta a dois espaços de trabalho e a um componente do Application Insight usando dois dos 300 espaços de trabalho possíveis do Log Analytics e um dos 1.000 componentes possíveis do Application Insights aos quais ele pode se conectar.
  • O espaço de trabalho 2 se conecta ao AMPLS A e AMPLS B usando duas das cinco conexões AMPLS possíveis.
  • AMPLS B é conectado a pontos de extremidade privados de duas redes virtuais (VNet2 e VNet3) usando duas das 10 conexões de ponto de extremidade privadas possíveis.

Diagram that shows AMPLS limits.

Controle o acesso à rede aos seus recursos

Seus espaços de trabalho 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 consultas de redes públicas (redes não conectadas ao recurso AMPLS).

Essa granularidade permite que você defina o acesso de acordo com suas necessidades, por espaço de trabalho. Por exemplo, você pode aceitar ingestão somente por meio de redes conectadas por link privado (ou seja, redes virtuais específicas), mas ainda assim optar por aceitar consultas de todas as redes, públicas e privadas.

Bloquear consultas de redes públicas significa que clientes como máquinas e SDKs fora das AMPLSs conectadas 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 executam essas consultas, como pastas de trabalho, painéis, informações no portal do Azure e consultas executadas de fora do portal do Azure.

Nota

Há certas exceções em que essas configurações não se aplicam. Você pode encontrar detalhes na seção a seguir.

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 recurso AMPLS).

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

Exceções

Observe as seguintes exceções.

Registos de diagnósticos

Os logs e métricas carregados em um espaço de trabalho por meio de configurações de diagnóstico passam por um canal privado 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 (visualização) coletadas e carregadas por meio do Azure Monitor Agent não são controladas por pontos de extremidade de coleta de dados. Eles não podem ser configurados em links privados.

Azure Resource Manager

A restrição de acesso, conforme explicado anteriormente, aplica-se aos dados no recurso. No entanto, as 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 as funções, permissões, controles de rede e auditoria apropriados. Para obter mais informações, consulte Azure Monitor funções, permissões e segurança.

Nota

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

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

  • Conector LogicApp
  • Solução de Gestão de Atualizações
  • Solução de Controlo de Alterações
  • Informações de VMs
  • Container Insights
  • Painel Resumo do Espaço de Trabalho do Log Analytics (preterido) (que mostra o painel de soluções)

Considerações sobre o Application Insights

  • Você precisará adicionar recursos que hospedam as cargas de trabalho monitoradas a um link privado. Por exemplo, consulte Usando pontos de extremidade privados para o Azure Web App.
  • As experiências de consumo que não sejam do portal também devem ser executadas na rede virtual vinculada à privada que inclui as cargas de trabalho monitoradas.
  • Para oferecer suporte a links privados para o Profiler e o Depurador, você precisará fornecer sua própria conta de armazenamento.

Nota

Para proteger totalmente o Application Insights baseado em espaço de trabalho, você precisa bloquear o acesso ao recurso do Application Insights e ao espaço de trabalho subjacente do Log Analytics.

Considerações sobre o Log Analytics

Observe as seguintes considerações do Log Analytics.

Download de pacotes de soluções do Log Analytics

Os agentes do Log Analytics precisam acessar uma conta de armazenamento global para baixar pacotes de soluções. 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 acessar o armazenamento de pacotes de soluções dos agentes pelo link privado. Esta funcionalidade é possível através de uma zona DNS criada para blob.core.windows.neto .

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

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

  • Permita que seus agentes alcancem a conta de armazenamento por meio de seu ponto de extremidade público adicionando as seguintes regras à sua lista de permissões do firewall:

    Ambiente na nuvem Recursos do agente Portas Direção
    Azure Público 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

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

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

Automatização

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

Nota

Alguns produtos e experiências do portal do Azure consultam dados através do Gestor de Recursos. Nesse caso, eles não poderão consultar dados por meio de um link privado, a menos que as configurações de link privado também sejam aplicadas ao Gerenciador de Recursos. Para superar essa restrição, você pode configurar seus recursos para aceitar consultas de redes públicas, conforme explicado em Controlando o acesso à rede aos seus recursos. (A ingestão pode permanecer limitada a redes de ligação privadas.) Identificámos os seguintes espaços de trabalho de consulta de produtos e experiências através do Gestor de Recursos:

  • Conector LogicApp
  • Solução de Gestão de Atualizações
  • Solução de Controlo de Alterações
  • O painel Resumo do Espaço de Trabalho (preterido) no portal (que mostra o painel de soluções)
  • Informações de VMs
  • Container Insights

Considerações sobre o Managed Prometheus

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

Requisitos

Observe os seguintes requisitos.

Tamanho da sub-rede de rede

A menor sub-rede IPv4 suportada é /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 se você estiver se conectando a um único espaço de trabalho. Revise as configurações de DNS do seu ponto de extremidade para obter a lista de pontos de extremidade de link privado do Azure Monitor.

Agentes

As versões mais recentes dos agentes Windows e Linux devem ser usadas para oferecer suporte à ingestão segura em espaços de trabalho do Log Analytics. As versões mais antigas não podem carregar dados de monitorização através de uma rede privada.

Azure Monitor agentes do Windows

Azure Monitor Windows agent versão 1.1.1.0 ou superior (usando pontos de extremidade de coleta de dados).

Agentes Linux do Azure Monitor

Azure Monitor Windows agent versão 1.10.5.0 ou superior (usando pontos de extremidade de coleta de dados).

Agente do Windows do Log Analytics (no caminho de descontinuação)

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

Agente Linux do Log Analytics (no caminho de descontinuação)

Use a versão do agente 1.12.25 ou posterior. Se não for possível, execute os seguintes comandos na 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 experiências de portal do Azure Monitor, como Application Insights, 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 tags de serviço AzureActiveDirectory, AzureResourceManager, AzureFrontDoor.FirstParty e AzureFrontdoor.Frontendao 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 marcasde serviço AzureActiveDirectory e AzureResourceManager ao seu firewall.

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

Agrupe o código JavaScript em seu script para que o navegador não tente baixar o código de uma CDN. Um exemplo é fornecido 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 das 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 seu navegador não substituem ou armazenam em cache as configurações de DNS antigas.

Limitação de consulta: operador de dados externos

  • O externaldata operador não é suportado através de um link privado porque lê dados de contas de armazenamento, mas não garante que o armazenamento seja acessado de forma privada.
  • O proxy do Azure Data Explorer (proxy ADX) permite que consultas de log consultem o Azure Data Explorer. O proxy ADX não é suportado em um link privado porque não garante que o recurso de destino seja acessado de forma privada.

Próximos passos