O exame AZ-700 avalia como acessar os serviços PaaS do Azure com segurança por meio de uma rede privada, sem expor o tráfego à internet. Existem vários mecanismos disponíveis e o exame frequentemente testa quando escolher um em detrimento do outro. Esta publicação aborda Private Endpoint, Service Endpoint e Private Link Service — diferenças, integração com DNS e armadilhas comuns.
Private Endpoint: Instalar uma Caixa de Correio Exclusiva Dentro do Edifício
Imagine uma empresa instalando uma caixa de correio privativa dentro de um condomínio. Em vez de usar a caixa postal pública na rua, o carteiro entrega correspondências diretamente à caixa interna do edifício, sem precisar sair para a calçada. O Private Endpoint funciona exatamente assim: cria um canal direto entre sua rede e o serviço do Azure, sem passar pela internet.
Quando você cria um Private Endpoint para um serviço PaaS do Azure — como Storage Account, Azure SQL Database ou Key Vault — o serviço recebe uma NIC (Network Interface Card) dentro da sub-rede da sua VNet, junto com um endereço IP privado. A partir desse momento, o tráfego para esse serviço nunca passa pela internet pública. Você pode desabilitar completamente o endpoint público no lado do serviço, e clientes locais (on-premises) podem rotear para esse IP privado por meio de uma conexão VPN ou ExpressRoute.
Private DNS Zone: A Agenda de Endereços que Resolve IPs Privados
Em uma biblioteca grande, conhecer o título do livro não é suficiente — você também precisa do número da estante para encontrá-lo rapidamente. Um bibliotecário que mapeia títulos a localizações faz exatamente o que a Private DNS Zone faz: associa o FQDN de um serviço a um endereço IP privado.
Quando você cria um Private Endpoint, o FQDN do serviço (por exemplo, mystorageaccount.blob.core.windows.net) é redirecionado para privatelink.blob.core.windows.net. Vincular uma zona DNS privada (privatelink.{service}.azure.com) à sua VNet garante que as VMs dentro da VNet resolvam esse FQDN para o IP privado automaticamente.
Para ambientes locais (on-premises), você deve configurar um Conditional Forwarder no servidor DNS para encaminhar consultas do domínio privatelink para o resolvedor DNS do Azure. Sem essa etapa, as VMs locais não encontrarão o IP privado e a conexão falhará.
Service Endpoint: Apresentar um Cartão VIP na Entrada
Pense em um cartão de associação VIP em um shopping center. Você pula a fila geral e entra mais rápido, mas ainda está acessando pelo lado de fora — não está se mudando para dentro do edifício. O Service Endpoint funciona da mesma forma.
Habilitar um Service Endpoint em uma sub-rede faz com que o tráfego dessa sub-rede seja roteado para o serviço do Azure por meio da rede de backbone da Microsoft. O serviço mantém seu endereço IP público, mas o tráfego nunca sai da rede da Microsoft para chegar à internet aberta. O firewall do lado do serviço deve permitir explicitamente o ID da VNet para que o acesso seja habilitado.
Uma restrição importante é que clientes locais (on-premises) não podem usar esse caminho diretamente. Além disso, o endpoint público do serviço permanece acessível para outras VNets ou chamadores externos.
Private Link Service: Expor Seu Próprio Serviço de Forma Privada
Uma empresa de logística quer compartilhar seu sistema de gerenciamento de armazém com um parceiro sem colocá-lo na internet. Ela precisa de um canal privado dedicado. O Private Link Service cumpre esse papel.
O Private Link Service é usado quando você — e não a Microsoft — deseja expor seu próprio serviço às VNets de outros clientes sem torná-lo público. Você coloca o serviço atrás de um Standard Load Balancer, cria um recurso de Private Link Service, e consumidores em outras VNets podem acessá-lo por meio de um Private Endpoint.
Cada solicitação de conexão passa por um fluxo de aprovação. O consumidor envia uma solicitação de conexão e o proprietário do serviço pode aprová-la ou rejeitá-la. O tráfego só flui após a aprovação ser concedida.
Private Endpoint vs. Service Endpoint: Como Escolher Entre os Dois
Reservar uma mesa em um restaurante para garantir sempre um lugar disponível (Private Endpoint) é diferente de apresentar um cartão fidelidade para entrar mais rápido pela entrada pública (Service Endpoint).
| Critério | Private Endpoint | Service Endpoint | | :-- | :-- | :-- | | IP de acesso | IP privado (NIC na VNet) | IP público mantido | | Desabilitar endpoint público | Sim | Não | | Roteamento on-premises | Sim (VPN/ExpressRoute) | Não | | Custo | Por hora + cobranças de dados | Gratuito | | Integração DNS | Zona DNS privada necessária | Não necessária |
Se a segurança rigorosa ou o acesso a partir de on-premises for necessário, escolha Private Endpoint. Para roteamento simples pelo backbone da Microsoft de uma VNet na mesma região, o Service Endpoint é suficiente e gratuito.
!Private Endpoint vs Service Endpoint
Bloquear o Endpoint Público e Cenários de Acesso On-Premises
Selar documentos da empresa para que ninguém externo possa lê-los, ao mesmo tempo em que se cria um corredor privado para os funcionários — essa combinação é o que o Private Endpoint trata de forma conjunta.
Quando você desabilita o endpoint público de uma Storage Account e cria um Private Endpoint, os clientes na VNet acessam por meio do IP privado e a rota de internet fica completamente bloqueada. Escritórios on-premises conectados por ExpressRoute também podem acessar a Storage Account usando esse mesmo IP privado, desde que o DNS esteja corretamente configurado.
O Service Endpoint, por outro lado, não pode bloquear o endpoint público e não suporta roteamento on-premises. Se o requisito de conformidade estabelece que o tráfego de internet deve ser bloqueado na origem, o Service Endpoint por si só não o satisfaz.
Armadilhas Comuns: DNS Mal Configurado e Conexões Sem Aprovação
Um sistema de navegação automotivo que não foi atualizado não mostrará as novas estradas. Da mesma forma, um Private Endpoint sem a configuração de DNS adequada continuará enviando tráfego para o IP público.
O erro mais comum é criar um Private Endpoint mas esquecer de vincular a zona Private DNS Zone à VNet. A VM consulta o FQDN do serviço, recebe o IP público e falha ao se conectar se o endpoint público também estiver desabilitado. Ambientes on-premises têm o mesmo sintoma quando o Conditional Forwarder não está configurado.
A segunda armadilha envolve a aprovação do Private Link Service — o Private Endpoint do consumidor permanece em estado 'Pending' até que o proprietário aprove a conexão. A terceira é combinar Service Endpoints com regras NSG sem o ajuste correto: habilitar um Service Endpoint sozinho não abre o caminho a menos que o NSG também permita a tag de serviço correspondente.
Resumo do Exame
"Acessar PaaS do Azure com IP privado dentro da VNet" -- Private Endpoint "Desabilitar completamente o endpoint público de uma Storage Account" -- Private Endpoint + desabilitar acesso público "Acesso on-premises ao Azure Storage por rede privada" -- Private Endpoint + VPN ou ExpressRoute "Roteamento pelo backbone da VNet, IP público mantido" -- Service Endpoint "Expor meu próprio serviço à VNet de outro cliente de forma privada" -- Private Link Service "Solicitação de conexão em Pending, requer aprovação do proprietário" -- Fluxo de aprovação do Private Link Service "O FQDN retorna IP público mesmo com Private Endpoint existindo" -- Private DNS Zone não vinculada à VNet "Clientes on-premises não resolvem o domínio privatelink" -- Conditional Forwarder não configurado "Service Endpoint habilitado mas o tráfego ainda bloqueado" -- NSG também deve permitir a tag de serviço "Requisito de conformidade: bloquear tráfego de internet na origem" -- Service Endpoint insuficiente; usar Private Endpoint
Private Endpoint = IP privado, bloqueia acesso público, suporta on-premises; Service Endpoint = roteamento pelo backbone, IP público mantido, gratuito