Warum Sie Port 1433 nicht weiterleiten sollten
Im Büro steht ein SQL Server. Jemand außerhalb dieses Netzes – ein Analyst im Homeoffice, ein Cloud-Reporting-Tool, eine App, die Ihr Team bauen will – muss ihn lesen. Die schnelle Lösung, die jeder vorschlägt: TCP-Port 1433 am Router auf den Datenbankserver weiterleiten und in der Firewall freigeben.
Das funktioniert, und zwar schnell. Es ist aber auch genau das, wovon Ihnen fast jeder Sicherheitsverantwortliche abraten wird:
- Ihre Anmeldung ist jetzt öffentlich. Alles im Internet erreicht den SQL-Server-Listener und kann sich anzumelden versuchen. Automatisierte Scanner suchen rund um die Uhr nach offenen 1433-Ports und probieren Konten wie
samit Passwortlisten. - Die Datenbank wird zur Außengrenze. Jeder fehlende Patch und jeder schwache SQL-Login ist jetzt von außen erreichbar.
- IP-Freigaben helfen, sind aber fragil. 1433 auf die IPs eines Anbieters zu beschränken verkleinert die Angriffsfläche, doch die Adressen ändern sich und jemand muss die Liste pflegen.
Was Sie eigentlich wollen: Etwas von außen soll diese Datenbank lesen, ohne dass ein eingehender Port nötig ist. Dafür gibt es vier Wege.
Option 1: Ein VPN
Ein VPN holt die Gegenstelle „ins" Netzwerk. Ein Client-VPN bindet den Laptop einer Person an; ein Site-to-Site-VPN verbindet zwei Netze dauerhaft.
Gut für Menschen. Eine Buchhalterin im Homeoffice, die SQL Server Management Studio braucht, ist genau der Fall, für den VPNs gemacht sind.
Nichts für SaaS-Tools. Die meisten Cloud-Dienste können Ihrem VPN nicht beitreten. Und das VPN-Gateway lauscht meist selbst auf einem eingehenden Port – Sie tauschen eine offene Datenbank gegen einen (deutlich besser gehärteten) offenen VPN-Endpunkt.
Option 2: Ein SSH-Tunnel über einen Bastion-Host
Viele Cloud-Tools bieten „Verbindung per SSH-Tunnel" an. Sie betreiben eine kleine Linux-Maschine (Bastion bzw. Jump Host), auf die sich das Tool per SSH verbindet, und der Datenbankverkehr läuft durch diese Sitzung.
Breit unterstützt, und SSH mit Schlüsseln ist ein bekanntes, gut geprüftes Protokoll.
Der Haken: Es braucht weiterhin einen eingehenden Port – meist 22 – ins Internet oder für die Anbieter-IPs, auf einer Maschine, die Sie patchen und überwachen müssen. Für ein Büro ohne öffentliche Adresse passt das schlecht, weil der Bastion-Host von außen erreichbar sein muss.
Option 3: Ein ausgehender Tunnel (Cloudflare Tunnel, ngrok, Tailscale)
Ausgehende Tunnel drehen die Richtung um: Ein kleiner Dienst in Ihrem Netz verbindet sich nach außen, und der Verkehr läuft über diese ausgehende Verbindung zurück.
- Cloudflare Tunnel betreibt
cloudflaredin Ihrem Netz, baut nur ausgehende Verbindungen zu Cloudflare auf, und Sie steuern den Zugriff über Cloudflares Zugriffsrichtlinien. - ngrok öffnet eine ausgehende Verbindung und liefert einen öffentlichen Endpunkt, der auf Ihren lokalen Dienst weiterleitet. Praktisch zum Testen – aber ohne Zugriffskontrollen ist dieser Endpunkt aus dem Internet erreichbar.
- Tailscale baut ein privates WireGuard-Netz zwischen registrierten Geräten. Nur Mitglieder Ihres Netzes erreichen den SQL Server.
Keine eingehende Regel, keine öffentliche IP nötig. Sie funktionieren auch in einem Büro, das beides nicht hat.
Aber: Netzwerkzugriff, kein Datenbankzugriff. Was den Tunnel erreicht, spricht mit den Rechten seines Logins mit SQL Server. Richtlinien, Logins und Überwachung bleiben Ihre Aufgabe. Und das SaaS-Tool auf der Gegenseite muss den Tunnel nutzen können – viele können es nicht.
Option 4: Ein Hersteller-Agent, der nach außen wählt
Manche Produkte bringen für genau diesen Fall einen eigenen Agenten mit. Sie installieren ihn auf einer Maschine, die die Datenbank sieht; er verbindet sich mit der Cloud des Herstellers, und das Produkt schickt Abfragen über diese Verbindung.
- Microsofts lokales Datengateway (on-premises data gateway) ist das bekannteste. Es läuft unter Windows, verbindet sich ausgehend mit Azure und bedient Power BI, Power Apps, Power Automate und Logic Apps. Lebt Ihr Team im Microsoft-Stack, ist es die naheliegende Wahl. (Ausführlich verglichen in unserem Leitfaden zu Alternativen zum lokalen Datengateway.)
- Der AgentUI Connector macht dasselbe für AgentUI-Apps und -Dashboards, bewusst mit engerem Funktionsumfang.
Warum das aufgeräumt ist: kein eingehender Port, keine öffentliche Adresse, und der Agent bedient nur die Produkte dieses Herstellers – es gibt keinen allgemeinen Netzwerkpfad, um den Sie sich kümmern müssen.
Der Kompromiss: Jeder Agent bedient nur die Produkte seines Herstellers, und Sie vertrauen dem Agenten des Herstellers – prüfen Sie vor der Installation, was er kann und was nicht.
Im direkten Vergleich
| Option | Eingehender Port? | Ohne öffentliche IP? | Wer erreicht die Datenbank | Geeignet für |
|---|---|---|---|---|
| Weiterleitung 1433 | Ja (1433) | Nein | Jeder, der den Port erreicht | Nichts dauerhaft |
| VPN | Meist, am VPN-Gateway | Je nach Aufbau | Jeder im VPN | Personen mit vollem Netzzugang |
| SSH-Tunnel über Bastion | Ja (22, am Bastion) | Nein | Wer einen Schlüssel zum Bastion hat | Cloud-Tools mit SSH-Tunnel |
| Ausgehender Tunnel (Cloudflare Tunnel, Tailscale) | Nein | Ja | Wen Ihre Richtlinie zulässt | Teams, die Zugriffsrichtlinien pflegen |
| Hersteller-Agent (Datengateway, AgentUI Connector) | Nein | Ja | Nur die Produkte dieses Herstellers | Die Tools eines Herstellers auf den Daten nutzen |
Wenn es um Apps und Dashboards auf diesen Daten geht
Wollen Sie eigentlich interne Tools, Berichte oder Dashboards auf der Bürodatenbank, zählt der Connector mehr als der Tunnel. Dafür gibt es den On-Premise SQL Server Connector von AgentUI:
- Nur ausgehend. Verbindung per HTTPS über Port 443. Keine eingehende Regel, keine Firewall-Änderung, keine öffentliche Adresse.
- Nur Lesezugriff. Es laufen ausschließlich
SELECT- undWITH-Abfragen, jede wird danach zurückgerollt. - Das Passwort bleibt vor Ort. Es liegt nur auf diesem Server (unter Windows verschlüsselt). AgentUI speichert lediglich einen Fingerabdruck des Connector-Schlüssels.
- Widerrufbar. Widerruf mit zwei Klicks; der Schlüssel ist innerhalb von 25 Sekunden ungültig.
- Grenzen. Nur Microsoft SQL Server. Abfragen bei Bedarf, bis zu 1.000 Zeilen und 30 Sekunden pro Abfrage. Keine Kopie, keine Synchronisierung.
Er läuft unter Windows, macOS oder Linux als Dienst. Ein typischer Fall ist SAP Business One auf einem Windows-Server. Wenn Sie App-Builder in diesem Punkt vergleichen: Wir haben auch beschrieben, wie Retool einen On-Premise SQL Server anbindet.
Welche Option passt?
- Eine Person braucht vollen Zugriff von zu Hause: VPN.
- Ein Cloud-Tool kann nur SSH-Tunnel: ein Bastion-Host, auf die Anbieter-IPs beschränkt – und als Server behandelt, den Sie pflegen müssen.
- Ihr Team verwaltet Zugriffsrichtlinien souverän und will einen allgemeinen Weg: ein ausgehender Tunnel wie Cloudflare Tunnel oder Tailscale.
- Ein einzelnes Produkt soll die Daten lesen, sonst nichts: der ausgehende Agent dieses Produkts – Microsofts Gateway für die Power Platform, der AgentUI Connector für AgentUI-Apps.
Wenn der letzte Punkt auf Sie zutrifft: Verbinden Sie Ihren SQL Server mit dem AgentUI Connector. Nur Lesezugriff, mit zwei Klicks widerrufbar.