SQL Server przez Internet

Wystawienie SQL Server bezpośrednio do internetu jest odradzane — zalecane jest połączenie przez VPN.

Dlaczego bezpośrednie wystawienie SQL Server jest ryzykowne

SQL Server udostępnia klientom protokół TDS, który służy do przesyłania zapytań, wyników i informacji związanych z sesją. W typowej konfiguracji domyślna instancja SQL Server nasłuchuje na porcie TCP 1433. Sama zmiana tego numeru nie stanowi jednak pełnego zabezpieczenia, ponieważ port można wykryć skanerem sieciowym. W przypadku nazwanych instancji port może być przydzielany dynamicznie, a usługa SQL Server Browser używa do rozpoznawania instancji portu UDP 1434.

Jeżeli serwer jest osiągalny z publicznego internetu, jego adres i otwarte porty mogą być regularnie sprawdzane przez automatyczne skanery. Próby logowania mogą dotyczyć zarówno uwierzytelniania Windows, jak i uwierzytelniania SQL Server, zależnie od trybu skonfigurowanego dla instancji. Błędna konfiguracja kont, zbyt szerokie uprawnienia, nieaktualna wersja silnika albo brak szyfrowania zwiększają ryzyko przejęcia danych lub wykorzystania serwera jako punktu dostępu do sieci firmowej.

Połączenie przez VPN i ograniczenie dostępu sieciowego

VPN tworzy dodatkowy, kontrolowany kanał pomiędzy urządzeniem użytkownika a siecią, w której działa SQL Server. Po prawidłowej konfiguracji instancja może być dostępna wyłącznie z prywatnego adresu IP lub z określonej podsieci VPN. Reguły zapory sieciowej powinny zezwalać na połączenia do portu SQL Server tylko z wymaganych adresów źródłowych. Nie należy otwierać TCP 1433 dla całego internetu, czyli dla zakresu 0.0.0.0/0, jeśli dostęp może zostać ograniczony do konkretnych hostów lub podsieci.

W praktyce warto rozdzielić role zapory brzegowej, zapory systemu Windows i konfiguracji samego SQL Server. W SQL Server Configuration Manager można sprawdzić, na jakim adresie i porcie nasłuchuje protokół TCP/IP. Dla nazwanej instancji bezpieczniejszym rozwiązaniem administracyjnym jest przypisanie stałego portu i zezwolenie na ten port w zaporze, zamiast wystawiania usługi SQL Server Browser na zewnątrz. Po zmianie ustawień protokołu usługa SQL Server musi zostać ponownie uruchomiona, aby przyjęła nową konfigurację.

Szyfrowanie, uwierzytelnianie i konfiguracja klienta

VPN chroni kanał pomiędzy punktami VPN, ale połączenie klienta z SQL Server nadal powinno korzystać z szyfrowania TLS. SQL Server może używać certyfikatu przypisanego do instancji; certyfikat powinien być wystawiony dla nazwy, której klient używa podczas łączenia, i pochodzić z zaufanego urzędu certyfikacji. W SQL Server Configuration Manager można skonfigurować wymuszanie szyfrowania po stronie serwera. Klient powinien także weryfikować certyfikat, a nie tylko akceptować dowolny certyfikat przedstawiony przez serwer.

W parametrach połączenia spotyka się między innymi ustawienia Encrypt=True oraz TrustServerCertificate=False. Pierwsze wymaga szyfrowanego połączenia, a drugie powoduje weryfikację certyfikatu zamiast bezwarunkowego zaufania. Dokładna składnia zależy od używanego sterownika, na przykład Microsoft ODBC Driver for SQL Server, Microsoft.Data.SqlClient albo sterownika JDBC firmy Microsoft. Hasła kont SQL powinny być długie i unikalne, a konto używane przez aplikację powinno mieć tylko uprawnienia wymagane przez tę aplikację. Konta administracyjne, w szczególności sa, nie powinny być używane w aplikacjach ani udostępniane użytkownikom.

Diagnostyka połączeń zdalnych do SQL Server

Problemy z połączeniem przez VPN często wynikają z pomieszania adresu, portu, instancji i sposobu rozwiązywania nazw. Test należy rozpocząć od ustalenia, czy klient otrzymuje trasę do prywatnego adresu serwera. Następnie można sprawdzić dostępność konkretnego portu TCP, na przykład poleceniem Test-NetConnection nazwa-serwera -Port 1433 w systemie Windows. Sukces tego testu oznacza jedynie, że można zestawić połączenie TCP; nie potwierdza poprawnego uwierzytelnienia, uprawnień ani działania zapytań.

W narzędziu SQL Server Management Studio należy wskazać właściwy format nazwy serwera, taki jak serwer,1433 dla instancji korzystającej z portu 1433 albo serwer\INSTANCJA, gdy klient może odnaleźć nazwę instancji przez mechanizm Browser. W dzienniku SQL Server można zweryfikować błędy logowania, odrzucone połączenia i problemy z certyfikatem. Diagnostyka powinna obejmować również reguły zapory, stan usługi SQL Server, konfigurację DNS w sieci VPN oraz zgodność sterownika klienta z wymaganym szyfrowaniem TLS. Publiczny dostęp do SQL Server powinien być wyjątkiem wymagającym uzasadnienia, udokumentowanej listy dozwolonych adresów, monitorowania prób logowania i regularnych aktualizacji silnika oraz systemu operacyjnego.