Guide des ports SQL Server : accès à la base de données sur le port 1433

Un client SQL se connecte au serveur d'écoute, négocie les paramètres de protocole, s'authentifie avec l'authentification SQL, l'authentification Windows, Entra ID ou une autre méthode prise en charge, puis envoie des requêtes, des transactions et des demandes de métadonnées.

Le port confirme uniquement que l'écouteur est joignable. L'accès réel à la base de données dépend également de l'état de connexion, des autorisations de la base de données, des paramètres de chiffrement, de la configuration de l'instance, des chaînes de connexion, du DNS et des règles de pare-feu sur plusieurs couches.

Une instance SQL Server par défaut écoute généralement sur TCP 1433. Les instances nommées peuvent utiliser des ports dynamiques, sauf si vous configurez un port statique. SQL Server Browser peut aider les clients à découvrir des instances nommées, mais de nombreux environnements de production préfèrent les ports statiques pour une politique de pare-feu plus claire.

Si votre chaîne de connexion utilise la syntaxe serveur-port, vérifiez le port exact. S'il utilise un nom d'instance, vérifiez le Gestionnaire de configuration SQL Server, le journal des erreurs ou les paramètres du serveur pour voir sur quel port l'instance écoute réellement.

Ouvrez l'accès SQL uniquement à partir de serveurs d'applications, de postes de travail d'administration, d'outils de migration, de services de reporting ou de réseaux de confiance nécessitant une connectivité de base de données. L'accès du public doit être évité, sauf s'il existe une exigence très spécifique en matière de gestion et de surveillance.

Pour les bases de données cloud, préférez les points de terminaison privés, le peering VPC ou VNet, le VPN, les chemins de bastion, la mise en réseau de services ou les listes autorisées de pare-feu natif du fournisseur au lieu de permettre à l'ensemble de l'Internet d'atteindre 1433.

Avant d'autoriser TCP 1433, vérifiez que l'instance écoute sur l'interface et le port attendus, que la politique de chiffrement est connue, que les connexions sont limitées, que les rôles de base de données avec le moindre privilège sont en place et que les sauvegardes sont fiables.

Un vérificateur de port peut confirmer l'accessibilité du réseau, mais il ne peut pas prouver que la base de données est sécurisée. Testez la véritable chaîne de connexion avec sqlcmd, SQL Server Management Studio, Azure Data Studio, les vérifications de l'état des applications et les journaux du serveur.

Sur Windows Server, activez TCP/IP pour l'instance SQL Server, définissez un port statique si nécessaire, redémarrez le service et autorisez TCP 1433 entrant dans le pare-feu Windows Defender uniquement à partir de sources fiables.

Sur les déploiements Linux SQL Server, confirmez que mssql-server écoute sur le port prévu et autorisez ce port dans les groupes de sécurité firewalld, ufw, nftables, iptables ou cloud. Séparez l’accès à la gestion de l’accès aux applications.

Pour les services SQL gérés, utilisez les règles de pare-feu du fournisseur, les points de terminaison privés et les contrôles d'identité. Ne présumez pas que l’ouverture d’un point de terminaison de base de données cloud équivaut à exposer un seul port de VM ; la politique d’accès au niveau du fournisseur est également importante.

Commencez par une vérification du port externe ou interne par rapport au nom d'hôte de la base de données et à TCP 1433, en fonction de l'endroit où le client sera exécuté. Si le port est ouvert, testez la connexion réelle avec sqlcmd, SSMS, Azure Data Studio ou la chaîne de connexion de l'application.

Si TLS est requis, vérifiez les paramètres de confiance et de chiffrement du certificat du client. Vérifiez ensuite les journaux du serveur pour détecter les échecs de connexion, les refus de pare-feu, les erreurs d'autorisation au niveau de la base de données et les modèles de délai d'expiration de connexion.

Si le port 1433 est fermé, SQL Server peut ne pas être en cours d'exécution, TCP/IP peut être désactivé, l'instance peut utiliser un port différent ou un pare-feu hôte, cloud ou réseau peut bloquer le chemin. Les instances nommées échouent souvent car le port dynamique réel est différent de celui attendu par le client.

Si le port est ouvert mais que la connexion échoue, inspectez le mode d'authentification, le format du nom d'utilisateur, l'état du mot de passe, les connexions désactivées, le mappage des utilisateurs de la base de données, les autorisations, les exigences de chiffrement et les journaux d'erreurs du serveur. Si les requêtes se connectent mais sont lentes, examinez les verrous, les index, le processeur, la mémoire, les E/S et les plans de requête.

Gardez SQL Server hors de l'Internet public autant que possible. Restreignez les sources, exigez le chiffrement, corrigez le moteur, désactivez les connexions inutilisées, utilisez les rôles de moindre privilège, alternez les informations d'identification et auditez les connexions échouées et les actions privilégiées.

Sauvegardez les bases de données, testez les restaurations, surveillez les requêtes lentes et l'état de réplication, et séparez l'accès administratif de l'accès aux applications. Un port de base de données est un chemin direct vers des données sensibles, l'accessibilité du réseau doit donc être associée à des contrôles solides des identités et des données.