Pourquoi éviter de rediriger le port 1433
Vous avez un SQL Server au bureau. Quelqu'un hors de ce réseau — un analyste à distance, un outil de reporting cloud, une application que votre équipe veut construire — doit le lire. La solution rapide que tout le monde propose : rediriger le port TCP 1433 du routeur vers le serveur et l'autoriser dans le pare-feu.
Ça marche, et c'est rapide. C'est aussi ce que presque tout responsable sécurité vous dira de ne pas faire :
- Votre écran de connexion devient public. N'importe quoi sur internet peut atteindre SQL Server et tenter de s'authentifier. Des scanners automatisés cherchent le port 1433 ouvert en permanence et testent des comptes comme
saavec des listes de mots de passe. - La base devient votre périmètre. Chaque correctif en retard et chaque identifiant SQL faible sont désormais accessibles de l'extérieur.
- Filtrer par IP aide, mais c'est fragile. Limiter le 1433 aux IP d'un fournisseur réduit l'exposition, mais ces adresses changent et quelqu'un doit tenir la liste à jour.
Ce que vous voulez vraiment, c'est que quelque chose d'extérieur lise cette base sans aucun port entrant. Il y a quatre façons d'y arriver.
Option 1 : un VPN
Un VPN fait entrer l'extérieur « dans » votre réseau. Un VPN client connecte l'ordinateur d'une personne ; un VPN site à site relie deux réseaux en permanence.
Bien pour les personnes. Une comptable à distance qui a besoin de SQL Server Management Studio, c'est exactement le cas prévu.
Pas pour les outils SaaS. La plupart des services cloud ne peuvent pas rejoindre votre VPN. Et la passerelle VPN écoute généralement sur un port entrant : vous échangez une base exposée contre un point d'accès VPN exposé (bien mieux protégé, certes).
Option 2 : un tunnel SSH via un bastion
Beaucoup d'outils cloud proposent « se connecter via un tunnel SSH ». Vous gérez une petite machine Linux (bastion) à laquelle l'outil se connecte en SSH, et le trafic vers SQL Server passe par cette session.
Largement pris en charge, et SSH avec clés est un protocole connu et bien audité.
Le hic : il faut toujours un port entrant — souvent le 22 — ouvert sur internet ou aux IP du fournisseur, sur une machine à mettre à jour et surveiller. Pour un bureau sans adresse publique, c'est un mauvais choix, car le bastion doit être joignable depuis l'extérieur.
Option 3 : un tunnel sortant (Cloudflare Tunnel, ngrok, Tailscale)
Les tunnels sortants inversent le sens : un petit service dans votre réseau se connecte vers l'extérieur, et le trafic revient par cette connexion sortante.
- Cloudflare Tunnel fait tourner
cloudflareddans votre réseau, n'ouvre que des connexions sortantes vers Cloudflare, et vous contrôlez l'accès via ses politiques d'accès. - ngrok ouvre une connexion sortante et fournit un point d'accès public qui redirige vers votre service local. Pratique pour tester, mais ce point d'accès est joignable depuis internet sans contrôle d'accès.
- Tailscale crée un réseau privé WireGuard entre les appareils enregistrés. Seuls les membres de votre réseau atteignent SQL Server.
Aucune règle entrante, pas besoin d'IP publique. Ils fonctionnent depuis un bureau qui n'a ni l'une ni l'autre.
Mais c'est un accès réseau, pas un accès à la base. Ce qui atteint le tunnel parle à SQL Server avec les droits de son identifiant. Politiques, identifiants et surveillance restent à votre charge. Et l'outil SaaS en face doit pouvoir utiliser le tunnel, ce que beaucoup ne savent pas faire.
Option 4 : un agent d'éditeur qui sort vers l'extérieur
Certains produits fournissent leur propre agent pour ce cas précis. Vous l'installez sur une machine qui voit la base ; il se connecte au cloud de l'éditeur, qui envoie les requêtes par cette connexion.
- La passerelle de données locale de Microsoft (on-premises data gateway) est la plus connue. Elle tourne sous Windows, se connecte en sortie vers Azure et sert Power BI, Power Apps, Power Automate et Logic Apps. Si votre équipe vit dans l'écosystème Microsoft, c'est le choix par défaut. (Comparaison détaillée dans notre guide des alternatives à la passerelle de données locale.)
- Le connecteur AgentUI fait la même chose pour les applications et tableaux de bord AgentUI, avec un périmètre volontairement plus étroit.
Pourquoi c'est propre : aucun port entrant, pas d'adresse publique, et l'agent ne sert que les produits de cet éditeur : pas de chemin réseau général à surveiller.
La contrepartie : chacun ne sert que les produits de son éditeur, et vous faites confiance à l'agent de l'éditeur : vérifiez ce qu'il peut et ne peut pas faire avant de l'installer.
Côte à côte
| Option | Port entrant ouvert ? | Sans IP publique ? | Qui atteint la base | Idéal pour |
|---|---|---|---|---|
| Redirection du 1433 | Oui (1433) | Non | Quiconque atteint le port | Rien à long terme |
| VPN | Généralement, sur la passerelle | Selon la configuration | Quiconque sur le VPN | Des personnes avec accès complet |
| Tunnel SSH via bastion | Oui (22, sur le bastion) | Non | Qui a une clé du bastion | Outils cloud compatibles SSH |
| Tunnel sortant (Cloudflare Tunnel, Tailscale) | Non | Oui | Qui votre politique autorise | Équipes qui gèrent des politiques d'accès |
| Agent d'éditeur (passerelle, connecteur AgentUI) | Non | Oui | Seulement les produits de cet éditeur | Utiliser les outils d'un éditeur sur les données |
Si le but, ce sont des applications et tableaux de bord sur ces données
Si vous voulez des outils internes, des rapports ou des tableaux de bord sur la base du bureau, le connecteur compte plus que le tunnel. C'est le rôle du connecteur SQL Server sur site d'AgentUI :
- Sortant uniquement. Il sort en HTTPS sur le port 443. Aucune règle entrante, aucun changement de pare-feu, pas d'adresse publique.
- Lecture seule. Seules les requêtes
SELECTetWITHs'exécutent, et chacune est annulée ensuite. - Le mot de passe reste sur place. Stocké uniquement sur ce serveur (chiffré sous Windows). AgentUI ne garde qu'une empreinte de la clé du connecteur.
- Révocable. Révocation en deux clics ; la clé cesse de fonctionner en moins de 25 secondes.
- Limites. Microsoft SQL Server uniquement. Requêtes à la demande, jusqu'à 1 000 lignes et 30 secondes chacune. Ni copie, ni synchronisation.
Il s'installe sous Windows, macOS ou Linux comme service. Un cas typique : SAP Business One sur un serveur Windows. Si vous comparez des outils de création d'applications sur ce point, nous expliquons aussi comment Retool se connecte à un SQL Server sur site.
Laquelle choisir ?
- Une personne a besoin d'un accès complet depuis chez elle : VPN.
- Un outil cloud ne gère que les tunnels SSH : un bastion limité aux IP du fournisseur, à traiter comme un serveur de plus à maintenir.
- Votre équipe sait gérer des politiques d'accès et veut une voie générale : un tunnel sortant comme Cloudflare Tunnel ou Tailscale.
- Vous voulez qu'un seul produit lise les données, rien d'autre : l'agent sortant de ce produit — la passerelle Microsoft pour la Power Platform, le connecteur AgentUI pour les applications AgentUI.
Si ce dernier cas est le vôtre, connectez votre SQL Server avec le connecteur AgentUI. En lecture seule, et révocable en deux clics.