Como conectar ao SQL Server sem redirecionamento de portas

Por que evitar o redirecionamento da porta 1433

Você tem um SQL Server no escritório. Alguém fora dessa rede — um analista remoto, uma ferramenta de relatórios na nuvem, um app que o time quer construir — precisa ler esse banco. A solução rápida que todo mundo sugere é redirecionar a porta TCP 1433 do roteador para o servidor e liberar no firewall.

Funciona, e é rápido. Também é o que quase todo profissional de segurança vai mandar não fazer:

• Sua tela de login fica pública. Qualquer coisa na internet alcança o SQL Server e tenta autenticar. Scanners automáticos procuram a 1433 aberta o dia inteiro, testando usuários como sa com listas de senhas.
• O banco vira o seu perímetro. Cada patch atrasado e cada login fraco agora são alcançáveis de fora.
• Restringir por IP ajuda, mas é frágil. Limitar a 1433 aos IPs de um fornecedor reduz a exposição, mas esses IPs mudam e alguém precisa manter a lista.

O que você quer de verdade é que algo de fora leia esse banco sem nenhuma porta de entrada. Há quatro jeitos de fazer isso.

Opção 1: uma VPN

A VPN coloca quem está fora "dentro" da sua rede. Uma VPN de cliente conecta o notebook de uma pessoa; uma VPN site a site liga duas redes de forma permanente.

Bom para pessoas. Um contador remoto que usa o SQL Server Management Studio é exatamente o caso.

Não serve para ferramentas SaaS. A maioria dos serviços em nuvem não consegue entrar na sua VPN. E o gateway da VPN costuma escutar numa porta de entrada: você troca um banco exposto por um endpoint de VPN exposto (bem mais protegido, é verdade).

Opção 2: um túnel SSH por um bastion

Muitas ferramentas em nuvem oferecem "conectar via túnel SSH". Você mantém uma pequena máquina Linux (bastion) onde a ferramenta entra por SSH, e o tráfego até o SQL Server passa por essa sessão.

Amplamente suportado, e SSH com chaves é um protocolo conhecido e auditado.

O porém: ainda precisa de uma porta de entrada — geralmente a 22 — aberta para a internet ou para os IPs do fornecedor, numa máquina que agora você precisa atualizar e monitorar. Se o escritório não tem endereço público, não é uma boa escolha, porque o bastion precisa ser alcançável de fora.

Opção 3: um túnel de saída (Cloudflare Tunnel, ngrok, Tailscale)

Túneis de saída invertem a direção: um pequeno processo dentro da sua rede se conecta para fora, e o tráfego volta por essa conexão de saída.

• Cloudflare Tunnel roda o cloudflared na sua rede, faz só conexões de saída para a Cloudflare, e você controla quem acessa pelas políticas de acesso.
• ngrok abre uma conexão de saída e te dá um endpoint público que encaminha para o serviço local. Prático para testes, mas esse endpoint fica acessível na internet se você não adicionar controles.
• Tailscale cria uma rede privada WireGuard entre os dispositivos cadastrados. Só membros da sua rede chegam ao SQL Server.

Sem regra de entrada nem IP público. Funcionam num escritório que não tem nenhum dos dois.

Mas é acesso à rede, não ao banco. O que chega pelo túnel fala com o SQL Server com as permissões do login. Políticas, logins e monitoramento continuam com você. E a ferramenta SaaS do outro lado precisa conseguir usar o túnel, o que muitas não conseguem.

Opção 4: um agente do fornecedor que sai para fora

Alguns produtos trazem o próprio agente para esse caso. Você instala numa máquina que enxerga o banco, ele se conecta à nuvem do fornecedor e o produto manda as consultas por essa conexão.

• O on-premises data gateway da Microsoft é o mais conhecido. Roda no Windows, sai para o Azure e atende Power BI, Power Apps, Power Automate e Logic Apps. Se o time vive no ecossistema Microsoft, é a escolha padrão. (Comparamos em detalhe no nosso guia de alternativas ao on-premises data gateway.)
• O Conector da AgentUI faz o mesmo para apps e dashboards da AgentUI, com um escopo mais estreito de propósito.

Por que é organizado: sem porta de entrada, sem endereço público, e o agente só atende os produtos daquele fornecedor, então não há um caminho de rede genérico com que se preocupar.

A contrapartida: cada um atende só os produtos do próprio fornecedor, e você está confiando no agente dele: leia o que ele pode e não pode fazer antes de instalar.

Lado a lado

Se o objetivo são apps e dashboards sobre esses dados

Se o que você quer são ferramentas internas, relatórios ou dashboards sobre o banco do escritório, o conector importa mais que o túnel. É para isso que existe o conector da AgentUI para SQL Server on-premise:

• Só saída. Sai por HTTPS na porta 443. Sem regra de entrada, sem mudança no firewall, sem IP público.
• Somente leitura. Só rodam consultas SELECT e WITH, e cada uma é revertida ao final.
• A senha fica onde está. Fica guardada só naquele servidor (criptografada no Windows). A AgentUI guarda apenas uma impressão digital da chave do conector.
• Revogável. Revogue em dois cliques; a chave para de funcionar em até 25 segundos.
• Limites. Só Microsoft SQL Server. Consultas sob demanda, até 1.000 linhas e 30 segundos cada. Não copia nem sincroniza o banco.

Instala em Windows, macOS ou Linux como serviço. Um caso típico é SAP Business One num servidor Windows. Se você está comparando construtores de apps nesse ponto, também explicamos como o Retool se conecta a um SQL Server on-premise.

Qual escolher?

• Uma pessoa precisa de acesso total de casa: VPN.
• Uma ferramenta em nuvem só suporta túnel SSH: um bastion restrito aos IPs do fornecedor, tratado como mais um servidor para manter.
• O time sabe gerenciar políticas de acesso e quer um caminho geral: um túnel de saída como Cloudflare Tunnel ou Tailscale.
• Você quer que um único produto leia os dados e mais nada: o agente de saída desse produto — o gateway da Microsoft para a Power Platform, o Conector da AgentUI para apps da AgentUI.

Se esse último é o seu caso, conecte seu SQL Server com o Conector da AgentUI. Somente leitura, e você revoga em dois cliques.