Guia de portas do SQL Server: acesso ao banco de dados na porta 1433

Um cliente SQL se conecta ao ouvinte do servidor, negocia configurações de protocolo, autentica com autenticação SQL, autenticação do Windows, Entra ID ou outro método compatível e, em seguida, envia consultas, transações e solicitações de metadados.

A porta apenas confirma que o ouvinte pode ser alcançado. O acesso real ao banco de dados também depende do estado de login, das permissões do banco de dados, das configurações de criptografia, da configuração da instância, das cadeias de conexão, do DNS e das regras de firewall em múltiplas camadas.

Uma instância padrão do SQL Server normalmente escuta no TCP 1433. As instâncias nomeadas podem usar portas dinâmicas, a menos que você configure uma porta estática. O SQL Server Browser pode ajudar os clientes a descobrir instâncias nomeadas, mas muitos ambientes de produção preferem portas estáticas para uma política de firewall mais clara.

Se a cadeia de conexão usar a sintaxe server,port, verifique a porta exata. Se usar um nome de instância, verifique o SQL Server Configuration Manager, o log de erros ou as configurações do servidor para ver em qual porta a instância realmente escuta.

Acesso SQL aberto somente a partir de servidores de aplicativos, estações de trabalho administrativas, ferramentas de migração, serviços de relatórios ou redes confiáveis que precisam de conectividade de banco de dados. O acesso público deve ser evitado, a menos que haja um requisito gerenciado e monitorado muito específico.

Para bancos de dados em nuvem, prefira endpoints privados, peering de VPC ou VNet, VPN, caminhos de bastiões, rede de serviços ou listas de permissões de firewall nativos do provedor em vez de permitir que toda a Internet alcance 1433.

Antes de permitir o TCP 1433, confirme se a instância está escutando na interface e porta esperadas, se a política de criptografia é conhecida, se os logins têm escopo definido, se as funções de banco de dados com privilégios mínimos estão em vigor e se os backups são confiáveis.

Um verificador de porta pode confirmar a acessibilidade da rede, mas não pode provar que o banco de dados é seguro. Teste a cadeia de conexão real com sqlcmd, SQL Server Management Studio, Azure Data Studio, verificações de integridade de aplicativos e logs de servidor.

No Windows Server, habilite o TCP/IP para a instância do SQL Server, defina uma porta estática se necessário, reinicie o serviço e permita o TCP 1433 de entrada no Firewall do Windows Defender somente de fontes confiáveis.

Em implantações do Linux SQL Server, confirme que o mssql-server escuta na porta pretendida e permita essa porta em firewalld, ufw, nftables, iptables ou grupos de segurança de nuvem. Mantenha o acesso de gerenciamento separado do acesso ao aplicativo.

Para serviços SQL gerenciados, use regras de firewall do provedor, pontos finais privados e controles de identidade. Não presuma que abrir um endpoint de banco de dados em nuvem equivale a expor uma única porta de VM; a política de acesso em nível de provedor também é importante.

Comece com uma verificação de porta externa ou interna em relação ao nome do host do banco de dados e ao TCP 1433, dependendo de onde o cliente será executado. Se a porta estiver aberta, teste a conexão real com sqlcmd, SSMS, Azure Data Studio ou a cadeia de conexão do aplicativo.

Se o TLS for necessário, verifique a confiança do certificado e as configurações de criptografia do cliente. Em seguida, verifique os logs do servidor em busca de falhas de login, negações de firewall, erros de permissão no nível do banco de dados e padrões de tempo limite de conexão.

Se a porta 1433 estiver fechada, o SQL Server pode não estar em execução, o TCP/IP pode estar desabilitado, a instância pode usar uma porta diferente ou um host, nuvem ou firewall de rede pode bloquear o caminho. As instâncias nomeadas geralmente falham porque a porta dinâmica real é diferente daquela que o cliente espera.

Se a porta estiver aberta, mas o login falhar, inspecione o modo de autenticação, formato do nome de usuário, estado da senha, logins desabilitados, mapeamento de usuários do banco de dados, permissões, requisitos de criptografia e logs de erros do servidor. Se as consultas se conectam, mas são lentas, observe bloqueios, índices, CPU, memória, E/S e planos de consulta.

Mantenha o SQL Server fora da Internet pública sempre que possível. Restrinja fontes, exija criptografia, corrija o mecanismo, desative logins não utilizados, use funções com privilégios mínimos, alterne credenciais e audite logins com falha e ações privilegiadas.

Faça backup de bancos de dados, teste restaurações, monitore consultas lentas e a integridade da replicação e separe o acesso administrativo do acesso a aplicativos. Uma porta de banco de dados é um caminho direto para dados confidenciais, portanto, a acessibilidade da rede deve ser combinada com controles fortes de identidade e dados.