Acesso privado aos serviços de PaaS Azure

Este artigo explica como se conectar a recursos de PaaS (plataforma como serviço) Azure em vez da Internet pública. Você aprende as diferenças entre pontos de extremidade de serviço, pontos de extremidade privados e Link Privado para poder escolher a abordagem que atenda aos seus requisitos de segurança e conectividade.

O que este artigo aborda

O acesso a PaaS privado remove a Internet pública do caminho de dados entre sua rede virtual Azure e serviços de PaaS Azure, como Armazenamento do Azure, Banco de Dados SQL do Azure e Azure Key Vault. Este artigo aborda as opções de conectividade, suas compensações e como decidir qual abordagem usar para cada carga de trabalho.

Note

Os Pontos de Extremidade Privados exigem integração com DNS para resolver os FQDNs de serviço em endereços IP privados. Este artigo aborda os requisitos de DNS embutidos, mas para a arquitetura de DNS completa, incluindo encaminhamento híbrido, DNS do Azure Resolvedor Privado e segurança DNS, consulte a segurança DNS e a resolução de nomes privados.

Quem precisa deste artigo

Leia este artigo se uma ou mais dessas condições se aplicarem:

  • Suas cargas de trabalho devem acessar os serviços PaaS do Azure por caminhos de rede privados em vez de endpoints públicos.
  • Você precisa decidir entre pontos de extremidade de serviço e pontos de extremidade privados com base na segurança, no custo e na capacidade de gerenciamento.
  • Você precisa restringir o acesso a recursos específicos de PaaS para reduzir o risco de exfiltração de dados.
  • Você precisa planejar o DNS, a capacidade de sub-rede ou a acessibilidade híbrida para conectividade de PaaS privada.

Tip

Seguindo um cenário específico? Selecione seu cenário na parte superior da página para obter diretrizes personalizadas. As diretrizes principais a seguir se aplicam a todos os leitores.

Foco na migração direta: ignore este artigo, a menos que partes do seu aplicativo migrado já utilizem os serviços PaaS do Azure. A maioria das cargas de trabalho de lift-and-shift permanece em IaaS (VMs, discos gerenciados, rede padrão) e não precisa de Link Privado na fase inicial de migração. Retorne a este artigo mais tarde quando você começar a adotar serviços de PaaS para componentes de carga de trabalho individuais.

Leia este artigo se você:

  • Ter migrado cargas de trabalho que já consomem serviços PaaS do Azure (por exemplo, Banco de Dados SQL do Azure ou Armazenamento do Azure).
  • Deseja entender quando começar a usar o Link Privado como parte de uma modernização gradual após a migração direta?
  • Precisa planejar a capacidade da sub-rede para a futura adoção de Pontos de Extremidade Privados?

Foco na modernização: sub-redes do Link Privado em cada VNet spoke são essenciais. Suas cargas de trabalho do AKS, Ambiente do Serviço de Aplicativo (ASE) e banco de dados gerenciado precisam de conectividade paaS privada para atender aos requisitos de conformidade e impedir a exfiltração de dados pela Internet pública.

Leia este artigo se você:

  • Armazene dados confidenciais ou regulamentados nos serviços PaaS do Azure e restrinja o acesso a rotas de rede privada.
  • Precisa criar sub-redes dedicadas do Link Privado em cada VNet spoke para uso da equipe do aplicativo?
  • Deseja impedir a exfiltração de dados garantindo escopos de conectividade de PaaS para instâncias de recursos específicas.
  • Estão criando cargas de trabalho de produção em que os serviços de PaaS devem ser acessíveis de redes locais por VPN ou ExpressRoute.
  • É preciso entender as vantagens e desvantagens de custo, DNS e segurança entre Service Endpoints e Private Endpoints.

Foco multinuvem: Este artigo passa a ser relevante depois que você configura o trânsito e a conectividade entre nuvens, a menos que a arquitetura de destino já inclua serviços PaaS do Azure com pontos de extremidade privados. Retorne a este artigo durante a otimização quando estiver pronto para proteger caminhos de acesso de PaaS.

Leia este artigo se você:

  • Estão usando o Migrações para Azure com suporte a endpoint privado durante o processo de migração.
  • Planeje adotar Azure serviços de PaaS como parte da arquitetura de destino pós-migração.
  • Você precisa entender como os Endpoints Privados funcionam antes de integrá-los à sua arquitetura entre nuvens.

Azure serviços e recursos

A tabela a seguir descreve os serviços e recursos disponíveis para conectividade paaS privada em Azure.

Serviço ou recurso O que ele fornece Quando usar isso
Ponto de extremidade público (padrão) Acesse serviços de PaaS do Azure pela Internet por meio do respectivo nome de domínio totalmente qualificado (FQDN) público. Nenhuma configuração adicional é necessária. Somente ambientes de desenvolvimento/teste. Não recomendado para cargas de trabalho de produção com dados confidenciais.
Pontos de extremidade do serviço Estende sua identidade de rede virtual para os serviços PaaS do Azure. O tráfego permanece na infraestrutura da Microsoft. O serviço PaaS vê a VNet como a fonte de tráfego. Não cria um endereço IP privado. Baixo risco de exfiltração. Configuração mais simples do que Link Privado. Útil quando Link Privado não está disponível para um serviço específico. Gratuito.
Ponto de extremidade privado/Link Privado do Azure Cria uma interface de rede com um endereço IP privado dentro de sua rede virtual que é mapeada para uma instância de recurso de PaaS específica. O tráfego permanece na Microsoft backbone e nunca atravessa a Internet pública. Requer integração de DNS. Cargas de trabalho de produção. Dados confidenciais. Conformidade regulatória. Prevenção de exfiltração de dados. Preferencial em relação aos pontos de extremidade de serviço para novos projetos.
Serviço de Link Privado Exponha seu próprio serviço de forma privada para consumidores em outras redes virtuais ou em locatários do Microsoft Entra. Os consumidores criam um ponto de extremidade privado em sua própria VNet para acessar seu serviço, sem a necessidade de emparelhamento de VNet. Fornecedores independentes de software (ISVs) ou equipes de plataforma internas que publicam serviços para consumidores que não devem ter acesso em nível de rede à rede virtual do host.
Integração de VNet (Serviço de Aplicativo, Funções) Permite que o App Service ou o Azure Functions encaminhem o tráfego de saída por meio de uma rede virtual. Apenas de saída: não oferece conectividade privada de entrada. Quando o App Service ou o Azure Functions precisam acessar recursos privados na VNet, como bancos de dados ou APIs internas, por meio de Private Endpoints.

Como escolher

Diagrama comparando três métodos de acesso de PaaS: ponto de extremidade público, ponto de extremidade de serviço via backbone e ponto de extremidade privado com IP privado.

Use as tabelas de decisão nesta seção para selecionar a abordagem de conectividade correta para sua carga de trabalho.

Pontos de extremidade de serviço em comparação com pontos de extremidade privados

A tabela a seguir compara as duas abordagens mais comuns para restringir o acesso de PaaS a caminhos de rede privada.

Fator Pontos de extremidade de serviço Pontos de extremidade privados
Caminho de tráfego Rede da Microsoft. O destino ainda usa seu endereço IP público. Infraestrutura da Microsoft. O destino usa um endereço IP privado em sua VNet.
IP privado na VNet Não. O IP de origem torna-se privado (endereço da VNet), mas o serviço é resolvido para o IP público. Sim. Uma interface de rede com um IP privado de sua sub-rede é mapeada para o recurso específico.
Alterações de DNS necessárias Não. A resolução DNS permanece inalterada. Sim. Uma zona de DNS privado é necessária para que o FQDN do serviço seja resolvido para o IP privado.
Prevenção contra exfiltração de dados Limitado. Aplica-se no nível da VNet a todas as instâncias de um tipo de serviço (por exemplo, todas as contas Armazenamento do Azure). Forte. O acesso é restrito a uma instância específica de recurso. Somente o recurso mapeado é acessível por meio desse endpoint.
Acesso local Não é acessível por meio de redes locais. Solução alternativa: adicione seus endereços IP públicos ou NAT às regras de firewall de IP do serviço Azure. Acessível do ambiente local por meio de VPN ou ExpressRoute, porque o endpoint tem um endereço IP privado roteável.
Custo Gratuito. Não há encargos adicionais. Cobrança por endpoint por hora, mais taxa de processamento de dados.

Quando usar qual abordagem

Scenario Abordagem recomendada Por que
Desenvolvimento/teste, baixa confidencialidade de dados Endpoint público com firewall do serviço Configuração mais simples. Restringir o acesso usando uma lista de IPs permitidos. Nenhum custo adicional ou alterações de DNS.
Restrição de VNet simples, baixo risco de exfiltração Pontos de extremidade de serviço Gratuito. Rápido para habilitar. Apropriado quando você não precisa de escopo de acesso no nível do recurso.
Cargas de trabalho de produção, dados confidenciais, conformidade Pontos de extremidade privados Proteção contra exfiltração mais robusta. Funciona em ambientes locais. Dá suporte à resolução baseada em DNS de qualquer rede conectada.
Publicar seu próprio serviço de forma privada para outros locatários Serviço de Link Privado Os consumidores criam um Private Endpoint em sua VNet. Não é necessário emparelhamento de VNet. Dá suporte a fluxos de trabalho de aprovação e controles de visibilidade.
O App Service ou Functions precisa acessar recursos da VNet Integração VNet Conectividade somente de saída. Requer delegação de sub-rede para Microsoft.Web/serverFarms. Combine com pontos de extremidade privados para acesso seguro a dados em serviços PaaS.

Azure Front Door Premium dá suporte a origens Link Privado, que você usa para conectar o Front Door aos seus serviços de back-end (Serviço de Aplicativo, Armazenamento ou balanceadores de carga internos) em uma conexão privada. O tráfego entre o Front Door e sua origem permanece no backbone Microsoft e você pode desativar totalmente o acesso público na origem. Esse padrão é a integração mais amplamente documentada para Link Privado em Azure serviços de rede.

Use o Front Door Premium com origens de Link Privado quando precisar de:

  • Balanceamento de carga global com proteção de WAF (firewall de aplicativo Web).
  • Conectividade privada com origens sem expô-las à Internet pública.
  • Terminação TLS centralizada com tráfego de back-end em caminhos privados.

Integração VNet para acesso de saída

A Integração VNet não fornece conectividade privada de entrada. Ele permite que o Serviço de Aplicativo ou Azure Functions roteiem chamadas de saída por meio de sua rede virtual. Isso significa que seu aplicativo pode acessar recursos por trás de Private Endpoints ou acessar serviços privados da VNet. A integração de VNet requer uma sub-rede dedicada delegada para Microsoft.Web/serverFarms.

Combine a Integração com Rede Virtual (VNet) com Endpoints Privados quando seu aplicativo precisar de:

  • Chame Banco de Dados SQL do Azure ou Armazenamento do Azure por meio de um IP privado.
  • Acesse APIs internas ou serviços implantados em redes virtuais spoke.
  • Roteie o tráfego de saída por meio de um dispositivo virtual de rede (NVA) para inspeção.

Considerações sobre o design

A maioria dos projetos de lift-and-shift adia a adoção do Link Privado para uma fase posterior. Sua prioridade imediata é migrar VMs e estabelecer conectividade básica. Considere Link Privado quando:

  • Componentes de carga de trabalho individuais já usam PaaS: Se um aplicativo migrado se conectar ao Banco de Dados SQL do Azure ou ao Armazenamento do Azure, adicione um Private Endpoint para esse serviço específico. Você não precisa converter todo o acesso de PaaS de uma só vez.
  • A conformidade exige conectividade privada: Algumas cargas de trabalho regulamentadas exigem caminhos de dados privados desde o primeiro dia. Nesse caso, crie Endpoints Privados durante a migração, não depois.
  • Planeje a capacidade da sub-rede agora: mesmo que você adie o Link Privado, reserve uma sub-rede /27 ou /28 em cada spoke para futuros pontos de extremidade privados. A readaptação do espaço de sub-rede mais tarde é mais difícil do que reservá-lo antecipadamente.

Para a maioria das migrações de lift-and-shift, ignore a implementação detalhada do Link Privado e volte a este artigo quando a adoção de PaaS começar.

Crie uma sub-rede Link Privado dedicada em cada VNet spoke. As equipes de aplicativos usam essa sub-rede para criar pontos de extremidade privados para os serviços de PaaS que seus aplicativos consomem:

  • Sub-rede Link Privado dedicada por spoke: dimensione cada sub-rede com base no número de serviços PaaS que as cargas de trabalho do spoke precisam (um IP por ponto de extremidade privado). Uma sub-rede /27 (32 endereços) suporta até 27 Pontos de Extremidade Privado depois que o Azure reservar 5 endereços.
  • Os administradores de aplicativos decidem as conexões PaaS: A equipe de TI fornece a sub-rede e a infraestrutura de DNS. As equipes de aplicação criam Endpoints Privados para seus recursos PaaS específicos (SQL do Azure, Key Vault, Storage) com base nos requisitos da aplicação.
  • Centralize as zonas de DNS no hub: As zonas privadas de DNS (por exemplo, privatelink.database.windows.net) residem na assinatura de conectividade e são vinculadas a todas as VNets spoke. Essa abordagem garante a resolução consistente de nomes e evita o DNS dividido.
  • Desativar o acesso público em recursos de PaaS: Depois de criar um ponto de extremidade privado, desative o acesso à rede pública no recurso paaS de destino. Caso contrário, o tráfego ainda poderá alcançar o serviço pela Internet, derrotando a finalidade da conectividade privada.
  • Combine com a Integração de VNet: o Serviço de Aplicativos e o Azure Functions usam a Integração de VNet para rotear chamadas de saída pela VNet spoke, alcançando os serviços PaaS por meio de Pontos de Extremidade Privados na mesma VNet ou em uma VNet emparelhada.

O appliance do Migrações para Azure permite conectividade de Pontos de Extremidade Privados, o que protege o tráfego do plano de controle da migração. Além disso, adie o planejamento do Link Privado para a otimização pós-migração:

  • Migrações para Azure com Ponto de Extremidade Privado: durante o processo de migração, o appliance do Migrações para Azure pode usar um Ponto de Extremidade Privado para se comunicar com o projeto do Migrações para Azure. Essa abordagem mantém o tráfego de controle de migração fora da Internet pública.
  • Adie a ampla adoção de Link Privado: concentre-se primeiro na conectividade de trânsito entre nuvens. Depois de migrar e estabilizar as cargas de trabalho no Azure, planeje os Pontos de Extremidade Privados para os serviços PaaS como uma etapa de otimização separada.
  • Reserve espaço de sub-rede: mesmo que você ignore o Link Privado agora, reserve uma sub-rede em cada spoke para futuros Pontos de Extremidade Privados. As cargas de trabalho multinuvem que posteriormente adotam serviços PaaS do Azure precisam dessa capacidade.

Pré-requisitos

Antes de implementar o acesso privado ao PaaS, confirme se você tem os seguintes recursos e conhecimentos em vigor:

  • Uma rede virtual implantada com pelo menos uma sub-rede. Os Private Endpoints exigem uma sub-rede com endereços IP disponíveis. Para design de rede virtual, consulte redes virtuais e sub-redes.
  • Um serviço PaaS do Azure para se conectar de forma privada. O serviço deve oferecer suporte a Service Endpoints ou a Link Privado. Verifique a documentação de disponibilidade do Link Privado do Azure para seu serviço.
  • Noções básicas sobre a infraestrutura DNS. Endpoints privados exigem uma zona DNS privada. Se você usar servidores DNS personalizados, precisará de encaminhadores condicionais apontando para DNS do Azure (168.63.129.16). Para padrões de projeto de DNS, consulte o artigo sobre integração de DNS para Pontos de Extremidade Privados em Recursos relacionados.
  • Planejamento de endereço IP. Cada ponto de extremidade privado consome um endereço IP privado da sub-rede. Planeje os tamanhos da sub-rede adequadamente. Consulte o planejamento de endereço IP para obter diretrizes.

Considerações de segurança

A conectividade de PaaS privada afeta diretamente sua postura de exfiltração de dados, a confiabilidade do DNS e a imposição da política de rede. Considere as diretrizes a seguir ao projetar sua implementação.

Prevenção contra exfiltração de dados

Os pontos de extremidade privados fornecem a proteção de exfiltração mais forte porque cada ponto de extremidade é mapeado para uma única instância de recurso. Um usuário ou aplicativo em sua VNet só pode acessar a conta de armazenamento ou o banco de dados específico para o qual o ponto de extremidade privado está configurado. Eles não podem redirecionar dados para uma instância diferente do mesmo tipo de serviço.

Os pontos de extremidade de serviço, por outro lado, restringem o acesso no nível da VNet, mas se aplicam a todas as instâncias de um tipo de serviço. Por exemplo, um endpoint de serviço para o Armazenamento do Azure significa que a VNet pode acessar qualquer conta do Armazenamento do Azure que conceder acesso, não apenas a conta específica que você pretende. Essa lacuna torna os pontos de extremidade de serviço insuficientes para ambientes em que a exfiltração de dados é uma preocupação de conformidade.

Configuração da zona DNS

Diagrama que mostra o fluxo de resolução de DNS de um endpoint privado, do cliente por meio do DNS do Azure e da zona DNS privada até a conta de armazenamento.

Os Endpoints privados dependem da resolução correta de DNS para funcionar. Ao criar um Ponto de Extremidade Privado, você configura uma zona DNS privada (por exemplo, privatelink.blob.core.windows.net para o Armazenamento de Blobs do Azure) para que o FQDN do serviço seja resolvido para o IP privado em vez do IP público.

A configuração incorreta de zonas DNS pode causar:

  • Aplicações que resolvem para o IP público, ignorando completamente o Ponto de Extremidade Privado.
  • Os clientes locais não conseguem acessar o IP privado porque os encaminhadores condicionais não estão configurados.
  • Problemas de DNS dividido (split-brain DNS), em que alguns clientes resolvem para o IP privado e outros para o IP público.

Centralize zonas DNS privadas em uma assinatura de serviços compartilhados ou conectividade e vincule-as a todas as redes virtuais que precisam de resolução. Use Azure Policy para impor a integração da zona DNS privada quando os Pontos de Extremidade Privados forem criados.

Políticas de rede em sub-redes de Private Endpoint

Grupos de segurança de rede (NSGs) e UDRs (rotas definidas pelo usuário) agora têm suporte em sub-redes de ponto de extremidade privado. Esse suporte é desabilitado por padrão e deve ser habilitado explicitamente por sub-rede. Depois de habilitar as políticas de rede:

  • Você pode aplicar regras de NSG para controlar quais origens podem alcançar o Private Endpoint.
  • Você pode usar UDRs para rotear o tráfego do Private Endpoint por meio de um dispositivo virtual de rede para inspeção.
  • Você pode referenciar Pontos de Extremidade Privados em regras de grupo de segurança de aplicativos (ASG).

Habilite políticas de rede em sub-redes de Private Endpoint em ambientes de produção para manter uma postura de segurança consistente em todas as sub-redes na sua rede virtual.

Importante

Depois de configurar um ponto de extremidade privado para um serviço de PaaS, desative o acesso à rede pública nesse serviço. Se o acesso público permanecer habilitado, o tráfego ainda poderá alcançar o serviço pela Internet, o que derrota a finalidade da conectividade privada.

Zonas privadas de DNS para serviços comuns

A tabela a seguir lista as zonas DNS privadas necessárias para serviços de PaaS Azure comumente usados.

serviço Azure Zona de DNS privado
Armazenamento de Blobs do Azure privatelink.blob.core.windows.net
Banco de Dados SQL do Azure privatelink.database.windows.net
Azure Key Vault privatelink.vaultcore.azure.net
Azure Cosmos DB privatelink.documents.azure.com
Serviço de Aplicativo do Azure privatelink.azurewebsites.net

Tip

Quando você cria um ponto de extremidade privado no portal Azure, ele geralmente cria automaticamente uma zona DNS privada associada. A exclusão do endpoint privado nem sempre remove a zona nem seus links para a rede virtual. Realize auditorias periódicas para identificar pontos de extremidade privados e zonas DNS privadas órfãos. Eles adicionam custo e desordem à sua configuração de resolução de nomes.

Perímetro de segurança de rede para acesso a PaaS

Link Privado controla como o tráfego atinge um serviço PaaS em um endereço IP privado. O NSP (Perímetro de Segurança de Rede) controla quais redes e recursos têm permissão para se comunicar com esse serviço. O NSP adiciona um limite explícito em torno de recursos de PaaS, como Armazenamento do Azure, Banco de Dados SQL do Azure e Azure Key Vault: os recursos dentro do perímetro se comunicam livremente, enquanto o acesso de fora é negado por padrão, a menos que uma regra de acesso permita isso. Use o NSP junto com pontos de extremidade privados quando precisar da proteção de exfiltração de dados no nível de PaaS em designs de alta segurança. Para ver onde o NSP se encaixa nos diferentes níveis de segurança, consulte a matriz de postura de segurança na visão geral.

Saiba mais

Próximas Etapas 

Tip

Explorando por conta própria? Retorne ao navegador de visão geral para encontrar seu próximo artigo por funcionalidade.

Próximo passo na sua jornada de migração:

Acesso à Internet de saída: controle como suas cargas de trabalho migradas chegam à Internet por meio de um caminho de saída centralizado.

A seguir, em sua jornada de modernização:

Acesso de saída à internet: Encaminhe todo o tráfego de saída dos spokes pelo firewall do hub para um controle consistente, gerenciado pela TI.

A seguir, em sua jornada multinuvem:

Monitoramento e diagnóstico de rede: Obtenha visibilidade do tráfego entre nuvens e da conectividade de endpoint privado.

Se a sua arquitetura multinuvem incluir saída centralizada para a Internet, leia primeiro Acesso de saída à Internet.

  • Last updated on