APRENDER. PRATICAR. EVOLUIR.Inventariar consumidores antes dos endpoints
Uma mudança para acesso privado começa pelos consumidores: aplicação num spoke, batch no datacenter, ferramenta administrativa e processo de recuperação. Para cada um, regista hostname, resolver usado, identidade, operação e requisitos de disponibilidade. A VM do hub pode ter um caminho que nenhum outro cliente usa. Um teste nessa VM é útil, mas não deve representar sozinho o serviço. Inclui os responsáveis por DNS e rede no plano de mudança e define o que fazer se um cliente ainda depender do caminho público no início da janela.
Separar ligações de rede e ligações de zona
Peering permite uma forma de conectividade entre VNets, mas não torna todas as configurações DNS do hub automaticamente disponíveis no spoke. No exercício com Azure-provided DNS, a zona privada está ligada só ao hub; o spoke precisa de uma ligação aplicável ou de outro caminho DNS desenhado para a consultar. Evita alterar ao mesmo tempo resolver, rotas e grants sem uma hipótese verificável. Primeiro observa o nome devolvido e o endereço final; depois testa o fluxo da aplicação. Uma resolução privada correta não garante TCP, autenticação ou autorização.
Desenhar a direção do encaminhamento
Para consultas on-premises que precisam de zonas privadas Azure, o desenho pode encaminhar condicionalmente para um inbound endpoint alcançável do Private Resolver. No sentido Azure para nomes internos, avalia regras, outbound e o servidor que é realmente autoritativo. Desenha setas para cada namespace e procura ciclos: se A envia funds.example para B e B devolve a A, nenhum deles chega à resposta terminal. Para SQL Private Link, segue o namespace de encaminhamento recomendado para o serviço. Não uses uma zona ampla vazia para privatizar apenas um servidor.
Conservar o nome que a aplicação espera
No SQL Database, mantém o FQDN normal do servidor na connection string e deixa o DNS determinar o caminho privado. Substituir pelo IP ou pelo nome privatelink não é um atalho seguro para o login. O endpoint encaminha para um gateway que precisa do nome adequado. Noutros serviços, consulta o contrato próprio em vez de generalizar uma regra SQL. Durante o ensaio, regista o hostname configurado, a resolução observada e o resultado da ligação, sem expor credenciais. Assim, uma falha de nome não é confundida com uma password incorreta.
Cobrir os subrecursos realmente utilizados
Um endpoint de uma storage account não representa automaticamente todas as APIs da conta. O job mensal pode ler blobs e depois criar diretórios ou gerir ACLs via DFS. O desenho ADLS Gen2 deve cobrir os endpoints e zonas relevantes para essas operações. Antes de alargar permissões, identifica o hostname da chamada que falha e compara-o com a leitura que teve sucesso. Usa dados sintéticos que reproduzam o ciclo completo, incluindo criação e limpeza controlada. Um teste pequeno deve reduzir volume, mantendo as dependências funcionais que tornam o caso representativo.
Definir um gate positivo e negativo
Confirma primeiro o estado da ligação privada e a aprovação necessária. Depois valida cada consumidor autorizado: resolução, caminho de rede, identidade e operação útil. Finalmente, ensaia de forma autorizada que o caminho público está restringido conforme o requisito. Um teste positivo não demonstra a restrição negativa. Guarda evidência com hora e configuração para que o RUN consiga repetir o diagnóstico. Se algum caminho não estiver pronto, aplica o plano de adiamento ou recuperação aprovado; não transformes uma exceção temporária em desenho permanente sem decisão explícita.
O hub resolve SQL por IP privado, mas o batch ainda usa DNS on-premises sem encaminhamento adequado. O gate falha antes de fechar o público e evita um incidente no fecho.
Armadilhas comuns
Confundir peering com partilha automática de DNS; sobrepor zonas públicas amplas; usar IP no login SQL; testar só a leitura blob; aceitar um endpoint Pending.
Tópicos relacionados: Arquitetura de redes híbridas · Handover e critérios de aceitação
Acesso privado é uma cadeia verificável por consumidor: resolução, rede, aprovação, identidade e operação.
Referência: Private Endpoint DNS integration · AZ-305 objectives 2026-04-17