Jak połączyć się z SQL Serverem bez przekierowania portów

Dlaczego lepiej nie przekierowywać portu 1433

Masz SQL Server w biurze. Ktoś spoza tej sieci — analityk pracujący zdalnie, narzędzie raportowe w chmurze, aplikacja, którą zespół chce zbudować — musi go czytać. Szybkie rozwiązanie, które proponuje każdy: przekierować port TCP 1433 na routerze do serwera i przepuścić go przez firewall.

Działa, i to szybko. To też dokładnie to, czego prawie każdy specjalista od bezpieczeństwa każe nie robić:

• Ekran logowania staje się publiczny. Wszystko w internecie może dotrzeć do SQL Servera i próbować się zalogować. Automatyczne skanery szukają otwartego 1433 przez całą dobę i próbują kont takich jak sa z listami haseł.
• Baza staje się granicą Twojej sieci. Każda zaległa łatka i każdy słaby login SQL są teraz osiągalne z zewnątrz.
• Ograniczenie do IP pomaga, ale jest kruche. Zawężenie 1433 do adresów dostawcy zmniejsza ekspozycję, ale te adresy się zmieniają, a ktoś musi pilnować listy.

Tak naprawdę chcesz, żeby coś z zewnątrz czytało tę bazę bez żadnego portu przychodzącego. Są na to cztery sposoby.

Opcja 1: VPN

VPN wpuszcza stronę zewnętrzną „do środka" sieci. VPN klienta podłącza laptopa konkretnej osoby; VPN site-to-site trwale łączy dwie sieci.

Dobre dla ludzi. Księgowa pracująca zdalnie w SQL Server Management Studio to dokładnie przypadek, dla którego powstały VPN-y.

Nie dla narzędzi SaaS. Większość usług w chmurze nie dołączy do Twojego VPN-a. A brama VPN zwykle sama nasłuchuje na porcie przychodzącym — zamieniasz wystawioną bazę na wystawiony punkt VPN (znacznie lepiej zabezpieczony, to fakt).

Opcja 2: tunel SSH przez host bastionowy

Wiele narzędzi chmurowych oferuje „połączenie przez tunel SSH". Utrzymujesz małą maszynę z Linuksem (bastion), do której narzędzie łączy się przez SSH, a ruch do SQL Servera idzie przez tę sesję.

Szerokie wsparcie, a SSH z kluczami to znany i dobrze sprawdzony protokół.

Haczyk: nadal wymaga portu przychodzącego — zwykle 22 — otwartego do internetu lub dla IP dostawcy, na maszynie, którą trzeba łatać i monitorować. Dla biura bez publicznego adresu to słaby wybór, bo bastion musi być osiągalny z zewnątrz.

Opcja 3: tunel wychodzący (Cloudflare Tunnel, ngrok, Tailscale)

Tunele wychodzące odwracają kierunek: mała usługa wewnątrz sieci łączy się na zewnątrz, a ruch wraca tym wychodzącym połączeniem.

• Cloudflare Tunnel uruchamia cloudflared w Twojej sieci, nawiązuje wyłącznie połączenia wychodzące do Cloudflare, a dostęp kontrolujesz jego politykami dostępu.
• ngrok otwiera połączenie wychodzące i daje publiczny adres, który przekazuje ruch do lokalnej usługi. Wygodne do testów, ale bez kontroli dostępu ten adres jest osiągalny z internetu.
• Tailscale buduje prywatną sieć WireGuard między zarejestrowanymi urządzeniami. Tylko członkowie Twojej sieci docierają do SQL Servera.

Bez reguł przychodzących i publicznego IP. Działają w biurze, które nie ma ani jednego, ani drugiego.

Ale to dostęp do sieci, nie do bazy. To, co dotrze do tunelu, rozmawia z SQL Serverem z uprawnieniami swojego loginu. Polityki, loginy i monitoring zostają po Twojej stronie. A narzędzie SaaS po drugiej stronie musi umieć z tunelu korzystać — wiele nie umie.

Opcja 4: agent dostawcy, który łączy się na zewnątrz

Niektóre produkty mają własnego agenta dokładnie na ten przypadek. Instalujesz go na maszynie, która widzi bazę; łączy się z chmurą dostawcy, a produkt wysyła zapytania tym połączeniem.

• Lokalna brama danych Microsoftu (on-premises data gateway) jest najbardziej znana. Działa na Windows, łączy się wychodząco z Azure i obsługuje Power BI, Power Apps, Power Automate i Logic Apps. Jeśli zespół żyje w ekosystemie Microsoftu, to domyślny wybór. (Szczegółowo porównujemy ją w naszym przewodniku po alternatywach dla lokalnej bramy danych.)
• Konektor AgentUI robi to samo dla aplikacji i dashboardów AgentUI, celowo z węższym zakresem.

Dlaczego to porządne rozwiązanie: brak portu przychodzącego, brak publicznego adresu, a agent obsługuje tylko produkty tego dostawcy, więc nie ma ogólnej ścieżki sieciowej, o którą trzeba się martwić.

Kompromis: każdy obsługuje tylko produkty swojego dostawcy, a Ty ufasz agentowi dostawcy — sprawdź przed instalacją, co może, a czego nie.

Obok siebie

Jeśli celem są aplikacje i dashboardy na tych danych

Jeśli tak naprawdę chcesz narzędzi wewnętrznych, raportów lub dashboardów na bazie z biura, ważniejszy jest konektor niż tunel. Do tego służy konektor SQL Server on-premise od AgentUI:

• Tylko wychodzący. Łączy się przez HTTPS na porcie 443. Bez reguł przychodzących, bez zmian w firewallu, bez publicznego adresu.
• Tylko odczyt. Działają wyłącznie zapytania SELECT i WITH, a każde jest na końcu wycofywane.
• Hasło zostaje na miejscu. Przechowywane tylko na tym serwerze (na Windows zaszyfrowane). AgentUI trzyma jedynie odcisk klucza konektora.
• Odwoływalny. Odwołanie dwoma kliknięciami; klucz przestaje działać w ciągu 25 sekund.
• Ograniczenia. Tylko Microsoft SQL Server. Zapytania na żądanie, do 1000 wierszy i 30 sekund każde. Bez kopiowania i synchronizacji bazy.

Instaluje się na Windows, macOS lub Linuksie jako usługa. Typowy przypadek to SAP Business One na serwerze Windows. Jeśli porównujesz narzędzia do budowy aplikacji pod tym kątem, opisaliśmy też, jak Retool łączy się z SQL Serverem on-premise.

Co wybrać?

• Osoba potrzebuje pełnego dostępu z domu: VPN.
• Narzędzie chmurowe obsługuje tylko tunele SSH: bastion ograniczony do IP dostawcy, traktowany jak kolejny serwer do utrzymania.
• Zespół dobrze zarządza politykami dostępu i chce ogólnej drogi: tunel wychodzący, np. Cloudflare Tunnel lub Tailscale.
• Chcesz, by dane czytał tylko jeden produkt i nic więcej: agent wychodzący tego produktu — brama Microsoftu dla Power Platform, konektor AgentUI dla aplikacji AgentUI.

Jeśli to ostatnie pasuje do Ciebie, podłącz swój SQL Server przez konektor AgentUI. Tylko odczyt, a odwołasz go dwoma kliknięciami.