> ## Content Index
> Fetch the complete content index at: https://www.azurebrasil.cloud/llms.txt
> Use this file to discover other available public pages before exploring further.

# Case: Como Tiramos o Azure SQL da Internet e Resolvemos a Auditoria de um Cliente
- URL: https://www.azurebrasil.cloud/blog/case-como-tiramos-o-azure-sql-da-internet-e-resolvemos-a-auditoria-de-um-cliente/
- Published: 2026-03-20T12:00:13.000Z
- Updated: 2026-03-20T12:00:14.000Z
- Description: 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?
- Author: Rafael dos Santos
- Tags: case

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?](https://learn.microsoft.com/azure/private-link/private-endpoint-overview?ref=azurebrasil.cloud) — Visão geral do conceito de Private Endpoint no Azure
- [Private Endpoint para Azure SQL Database](https://learn.microsoft.com/azure/azure-sql/database/private-endpoint-overview?ref=azurebrasil.cloud) — Configuração específica para Azure SQL
- [Private DNS Zone com Private Endpoint](https://learn.microsoft.com/azure/private-link/private-endpoint-dns?ref=azurebrasil.cloud) — Como configurar a resolução de DNS pra Private Endpoints

### VPN e Conectividade

- [VPN Point-to-Site](https://learn.microsoft.com/azure/vpn-gateway/point-to-site-about?ref=azurebrasil.cloud) — Conceitos e configuração de VPN P2S no Azure
- [DNS Private Resolver](https://learn.microsoft.com/azure/dns/dns-private-resolver-overview?ref=azurebrasil.cloud) — Visão geral do serviço gerenciado de DNS dentro da VNet

### Identidade e Autenticação

- [Autenticação do Entra ID para VPN P2S](https://learn.microsoft.com/azure/vpn-gateway/openvpn-azure-ad-tenant?ref=azurebrasil.cloud) — Como configurar autenticação Entra ID na VPN Point-to-Site
- [Acesso Condicional com VPN](https://learn.microsoft.com/azure/vpn-gateway/vpn-gateway-conditional-access?ref=azurebrasil.cloud) — Políticas de Acesso Condicional para conexões VPN

### Segurança de Rede

- [Desabilitar acesso público no Azure SQL](https://learn.microsoft.com/azure/azure-sql/database/connectivity-settings?ref=azurebrasil.cloud#deny-public-network-access) — 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