Olá pessoALL,

Semana passada um cliente nos procurou com aquela urgência que a gente já conhece: uma auditoria de compliance batendo na porta e o Azure SQL Database exposto na internet pública. Você já passou por uma situação parecida? O banco funcionando, aplicações rodando, usuários acessando — mas com aquela sensação constante de que algo poderia dar errado a qualquer momento.

O pedido era claro: "Precisamos que o banco não esteja mais visível na internet. A auditoria está chegando."

E olha, o cenário que encontramos era mais comum do que você imagina. Vamos ao que aconteceu.

Cenário Inicial

O cliente tinha uma necessidade legítima: diversos usuários externos precisavam acessar o Azure SQL Database. Consultores, parceiros, analistas — gente de fora da organização que dependia dos dados pra trabalhar. Como fazer isso de forma segura?

Pra atender essa demanda, a equipe montou uma estrutura que, na época, fez sentido. O banco estava com o endpoint público habilitado, protegido por regras de firewall no Azure SQL. Cada usuário externo tinha seu IP liberado. Além disso, existia uma VM (Virtual Machine) funcionando como ponte de conexão — os usuários se conectavam primeiro nessa VM via RDP e, de lá, acessavam o banco.

Funcionava? Funcionava. Os dados estavam acessíveis, as aplicações rodavam, os relatórios saíam.

Mas vamos ser honestos: era uma solução frágil disfarçada de arquitetura.

Os Problemas

Com o tempo, as dores começaram a aparecer — e a lista era longa:

• Exposição à internet: o banco estava acessível externamente. Qualquer scanner de porta podia encontrá-lo. A superfície de ataque era enorme.
• Complexidade de manutenção: cada novo usuário significava uma nova regra de firewall. IPs dinâmicos mudavam sem aviso. A equipe vivia apagando incêndio.
• Baixa escalabilidade: onboarding de um novo usuário exigia ajuste manual — abrir ticket, pegar IP, criar regra, testar, validar. Um processo que deveria levar minutos levava horas.
• Custo da VM ponte: uma Virtual Machine ligada 24/7 só pra servir de intermediária entre o usuário e o banco. Custo mensal fixo, manutenção de SO, patches de segurança — tudo isso pra uma máquina que não rodava nenhuma aplicação própria. Faz sentido manter isso?
• Insegurança percebida: a equipe relatava preocupação constante. Cada regra de firewall era um ponto de risco. Cada IP liberado era uma porta que poderia ser explorada.

E aqui mora o perigo de soluções que "funcionam": elas funcionam até o dia que não funcionam. E geralmente esse dia é o dia da auditoria.

A Virada — O Banco Não Deveria Estar na Internet

Quando sentamos pra analisar o cenário, a primeira reação instintiva foi: "Vamos melhorar as regras de firewall. Vamos automatizar a liberação de IPs. Vamos trocar a VM por uma mais barata."

Gastamos um tempo nessa direção. Avaliamos scripts de automação, Azure Automation, políticas de IP. Parecia o caminho lógico — otimizar o que já existia.

Mas aí veio o momento de clareza: o problema não era a qualidade das regras de firewall. O problema era que o banco estava na internet. Ponto.

Não importa quantas regras você coloque, quantos IPs bloqueie, quanta automação implemente — se o endpoint público está habilitado, existe superfície de ataque. Concorda? Uma auditoria de compliance séria vai apontar isso.

A pergunta certa não era "como proteger melhor o acesso público?" Era: "como eliminar o acesso público?"

E a resposta estava no Private Endpoint — a capacidade do Azure de atribuir um IP privado ao seu banco de dados, dentro da sua rede virtual (VNet). Com isso, o Azure SQL Database deixa de responder na internet e passa a existir apenas como um recurso interno da sua rede.

Parece simples, né? E conceitualmente é. Mas — e aqui entra um ponto que muita gente ignora — Private Endpoint sozinho não resolve o problema inteiro. Tem mais peças nesse quebra-cabeça.

A Solução — VPN P2S + Private Endpoint + DNS Private Resolver

Pra resolver o cenário do cliente de ponta a ponta, precisamos de quatro componentes trabalhando juntos. Já ouviu falar em todos eles? Pense neles como camadas de uma arquitetura que, combinadas, eliminam completamente a exposição pública:

1. VPN Point-to-Site (P2S)

Os usuários externos precisavam de um caminho seguro pra entrar na rede virtual do Azure. A VPN Point-to-Site resolve isso: cada usuário instala um perfil de VPN no computador e, ao conectar, recebe um IP dentro da VNet. É como se o notebook do usuário estivesse fisicamente dentro da rede privada do Azure.

Acabou a VM ponte. Acabou o RDP. O usuário conecta a VPN e já está dentro da rede — com criptografia de ponta a ponta.

2. Private Endpoint para o Azure SQL

Com o Private Endpoint habilitado, o Azure SQL Database recebe um IP privado dentro da VNet (algo como 10.0.1.5). Ele deixa de responder no endereço público seuservidor.database.windows.net e passa a responder apenas internamente.

Na prática, o banco desaparece da internet. Scanners, bots, tentativas de brute force — nada disso alcança o banco porque ele simplesmente não existe no espaço público.

3. Private DNS Zone

Quando você cria um Private Endpoint, o Azure gera um FQDN (Fully Qualified Domain Name — o nome completo do recurso na rede) no formato seuservidor.privatelink.database.windows.net. A Private DNS Zone é responsável por mapear esse nome pro IP privado dentro da VNet.

Sem ela, a resolução de DNS retornaria o IP público — e sua conexão "privada" voltaria pela internet sem você perceber. A Private DNS Zone garante que, dentro da VNet, o nome sempre resolve pro IP correto.

4. DNS Private Resolver

Aqui está a peça que faz tudo funcionar pra quem vem de fora via VPN. O DNS Private Resolver — um serviço gerenciado do Azure que atua como servidor DNS dentro da VNet — garante que os clientes conectados via VPN P2S consigam resolver os nomes privatelink corretamente.

Sem ele, o computador do usuário externo usaria seu próprio DNS (o da operadora de internet, por exemplo) e resolveria seuservidor.database.windows.net pro IP público. Com o DNS Private Resolver, a consulta de DNS passa pela VNet e retorna o IP privado.

O Fluxo Completo

Pra visualizar: o usuário externo conecta a VPN P2S → entra na VNet com IP privado → faz uma consulta DNS pra seuservidor.database.windows.net → o DNS Private Resolver intercepta e resolve pra 10.0.1.5 (o Private Endpoint) → a conexão chega ao Azure SQL Database sem nunca tocar a internet pública.

Cada peça tem uma função. Consegue imaginar o que acontece se você tira uma delas? O fluxo quebra — ou pior: parece funcionar, mas o tráfego vaza pela internet sem ninguém perceber.

O Ponto Crítico — Fallback para Internet

E por falar em "parecer funcionar"... Esse é o ponto que eu mais queria chegar. Porque é aqui que a maioria das implementações de Private Endpoint tropeça silenciosamente.

O Azure SQL Database tem uma configuração chamada "Deny public network access" (ou "Public network access" nas configurações de rede). Quando você cria um Private Endpoint, essa configuração pode estar em dois estados:

Fallback habilitado (Public network access: Enabled):

• Conexões funcionam tanto pelo nome público quanto pelo privatelink
• Se a resolução DNS falhar pro caminho privado, a conexão cai no endpoint público automaticamente
• Você acha que está seguro. Mas o tráfego está passando pela internet.

Fallback desabilitado (Public network access: Disabled):

• Apenas conexões via Private Endpoint funcionam
• Se a aplicação estiver configurada com o nome público sem o DNS correto, a conexão quebra
• Você descobre rapidamente que algo está errado — e corrige

Qual é o mais seguro? Desabilitar. Sempre.

Mas — e vale ressaltar — antes de desabilitar, você precisa garantir que todas as connection strings estejam apontando pro caminho privado e que o DNS esteja resolvendo corretamente. Caso contrário, aplicações vão parar de funcionar.

A recomendação que fizemos pro cliente: desabilite o fallback, atualize todas as strings de conexão pra usar o nome privatelink, valide o DNS de ponta a ponta, e só então dê o cenário como concluído. Segurança de verdade não tem atalho.

Protegendo a Porta de Entrada — Entra ID + MFA

Até aqui, resolvemos o caminho da rede: tráfego privado, DNS correto, fallback desabilitado. Mas faltava uma peça fundamental. De que adianta ter um túnel blindado se você não controla quem entra nele?

Na arquitetura anterior, o acesso à VM ponte era feito com credenciais locais ou, no melhor dos casos, contas de domínio desconectadas de qualquer política centralizada. Cada usuário tinha sua senha, e ninguém sabia ao certo quantas credenciais válidas existiam por aí. Já viveu isso?

Com a VPN P2S, tivemos a oportunidade de resolver esse problema de uma vez. Configuramos a autenticação da VPN com Entra ID (o antigo Azure Active Directory) e habilitamos MFA (Multi-Factor Authentication).

Por que Entra ID?

• Identidade centralizada: todos os usuários se autenticam pelo mesmo diretório corporativo. Acabaram as credenciais locais dispersas, os certificados individuais e as contas paralelas.
• Políticas de Acesso Condicional: com o Entra ID, você aplica regras como exigir dispositivos confiáveis, restringir horários de login ou bloquear acesso de localizações suspeitas. São controles que simplesmente não existem com autenticação por certificado.
• Gestão simplificada: precisa revogar o acesso de um consultor que saiu do projeto? Desabilita a conta no Entra ID e pronto — ele perde acesso à VPN, ao banco, a tudo. Sem precisar caçar certificados ou trocar senhas.

E o MFA?

Senha sozinha não é segurança — é formalidade. O MFA adiciona um segundo fator de autenticação: um push no Microsoft Authenticator, um código SMS, biometria. Mesmo que a senha de um usuário seja comprometida, o invasor não passa da segunda barreira.

Pra uma auditoria de compliance, MFA em acessos remotos não é diferencial — é requisito. Muitas normas de segurança exigem explicitamente autenticação multifator pra qualquer acesso externo a dados sensíveis.

Na prática, o resultado pra cada perfil foi claro:

• Pra empresa: conformidade com padrões de mercado e proteção contra acessos indevidos
• Pra equipe de TI: administração centralizada no Entra ID, sem gestão manual de credenciais
• Pros usuários: experiência moderna e simples — abrir a VPN, autenticar com Entra ID, confirmar o MFA, conectou

Resultados

Depois de implementar a nova arquitetura, o cenário mudou completamente:

Aspecto	Antes	Depois
Exposição à internet	Sim — endpoint público + regras de firewall	Não — Private Endpoint com IP privado
VM ponte	Necessária (custo mensal + manutenção de SO)	Eliminada
Regras de firewall	Manuais, por usuário, com IPs dinâmicos	Desnecessárias
Onboarding de novos usuários	Manual (coletar IP, criar regra, testar)	Perfil de VPN + conectou
Resolução DNS	Pública (risco de vazamento de tráfego)	Privada via DNS Private Resolver
Autenticação	Credenciais locais / certificados dispersos	Entra ID + MFA centralizado
Postura de auditoria	Risco alto — banco visível na internet	Conforme — acesso privado com identidade verificada

Aquela VM ponte que custava todo mês? Desligada. As dezenas de regras de firewall? Removidas. A preocupação constante da equipe? Substituída por uma arquitetura que se explica sozinha.

E o mais importante: a auditoria passou. O banco não está mais na internet. Ponto.

Lições Aprendidas

1. Segurança por arquitetura é sempre superior a segurança por regra de firewall. Regras de firewall são reativas — você bloqueia depois que o risco existe. Private Endpoint elimina o risco na origem.

2. Private Endpoint sem DNS correto é falsa segurança. Se o DNS resolve pro IP público, sua conexão vai pela internet mesmo com Private Endpoint configurado. O DNS Private Resolver não é opcional — é obrigatório.

3. Desabilite o fallback para internet — sempre. Se existe um caminho público, alguma conexão vai usá-lo. Desabilitar o acesso público garante que não há atalhos acidentais.

4. VPN Point-to-Site é subestimada. Pra cenários de acesso externo ao Azure, ela elimina a necessidade de VMs ponte, jumpboxes e regras de firewall manuais. É simples, escalável e segura.

5. Soluções que "funcionam" acumulam dívida operacional. A arquitetura anterior funcionava — até o dia da auditoria. O custo de manter algo frágil é sempre maior do que o investimento em fazer certo.

6. Rede privada sem identidade forte é metade da solução. Entra ID + MFA na VPN garante que você controla não só o caminho, mas também quem percorre esse caminho.

Links Úteis

Private Endpoint e Rede Privada

• O que é um Private Endpoint? — Visão geral do conceito de Private Endpoint no Azure
• Private Endpoint para Azure SQL Database — Configuração específica para Azure SQL
• Private DNS Zone com Private Endpoint — Como configurar a resolução de DNS pra Private Endpoints

VPN e Conectividade

• VPN Point-to-Site — Conceitos e configuração de VPN P2S no Azure
• DNS Private Resolver — Visão geral do serviço gerenciado de DNS dentro da VNet

Identidade e Autenticação

• Autenticação do Entra ID para VPN P2S — Como configurar autenticação Entra ID na VPN Point-to-Site
• Acesso Condicional com VPN — Políticas de Acesso Condicional para conexões VPN

Segurança de Rede

• Desabilitar acesso público no Azure SQL — Como e por que desabilitar o fallback pra internet

Conclusão

Quando o cliente nos procurou, a urgência era clara: a auditoria estava chegando e o banco estava na internet. A solução não foi colocar mais cadeados na porta — foi mudar o banco de endereço.

Com VPN P2S, Private Endpoint, Private DNS Zone, DNS Private Resolver e autenticação via Entra ID com MFA, o Azure SQL Database saiu da internet e passou a existir apenas dentro da rede privada. Sem exposição pública, sem VM ponte, sem regras de firewall manuais — e com identidade verificada em cada conexão.

Se você está passando por uma situação parecida — ou se simplesmente quer melhorar a postura de segurança dos seus bancos de dados no Azure — considere essa abordagem. Não é a mais simples de configurar na primeira vez, mas é a mais robusta pra manter no longo prazo.

E lembre-se: o banco não deveria estar na internet.

Curtiu esse conteúdo? Deixe nos comentários se você já passou por um cenário parecido ou se tem dúvidas sobre a implementação. Aqui na AzureBrasil.cloud, nós acreditamos que compartilhar experiência real é a melhor forma de evoluir juntos.

[]s e até a próxima