Połączenie przez Internet

Bezpośrednie połączenie z SQL Server przez internet jest odradzane — powinno przebiegać przez VPN lub tunel szyfrowany.

Jak działa połączenie z SQL Server przez Internet

Połączenie z Microsoft SQL Server przez Internet polega na zestawieniu sesji klienta z usługą silnika bazy danych działającą na określonym adresie IP i porcie TCP. Klientem może być aplikacja, narzędzie administracyjne albo sterownik używany przez program. Samo podanie publicznego adresu serwera nie zapewnia jednak bezpiecznej komunikacji. Dostępność portu w Internecie oznacza, że usługa może być wykrywana i atakowana z wielu niezaufanych sieci.

Dla domyślnej instancji SQL Server często stosowany jest port TCP 1433, ale nie jest to wymóg działania silnika. Instancja nazwana może korzystać z portu dynamicznego, a SQL Server Browser używa protokołu UDP na porcie 1434 do przekazywania klientom informacji o portach instancji. W praktyce bezpieczniejsza konfiguracja zwykle obejmuje stały port znany administratorowi, ograniczenie reguł zapory oraz wyłączenie niepotrzebnego wykrywania instancji. Numer portu nie jest zabezpieczeniem samym w sobie, ponieważ można go ustalić metodami skanowania.

Dlaczego publiczny port bazy danych jest ryzykowny

Bezpośrednie wystawienie SQL Server do Internetu zwiększa powierzchnię ataku. Publicznie dostępna usługa może otrzymywać próby logowania z użyciem odgadniętych lub wyciekłych danych uwierzytelniających, a także nietypowe żądania mające ujawnić wersję silnika, sposób konfiguracji albo błędy aplikacji. Ryzyko rośnie, gdy konto używane przez aplikację ma szerokie uprawnienia, hasło nie wygasa lub jest współdzielone przez wiele systemów.

Ochrona nie powinna ograniczać się do zmiany domyślnego portu. Należy stosować zasadę najmniejszych uprawnień, oddzielne konta dla aplikacji i administracji, silne uwierzytelnianie oraz reguły zapory dopuszczające wyłącznie wymagane adresy źródłowe. Warto również rejestrować nieudane logowania, zmiany konfiguracji i zdarzenia związane z usługą. Aktualizacje zabezpieczeń SQL Server i systemu operacyjnego powinny być wdrażane zgodnie z procedurą utrzymania danego środowiska.

VPN i szyfrowany tunel zamiast bezpośredniego dostępu

VPN tworzy logiczny, szyfrowany kanał pomiędzy zaufanymi punktami, na przykład komputerem użytkownika a siecią, w której działa SQL Server. Po zestawieniu tunelu serwer może być dostępny z adresu prywatnego, bez otwierania portu silnika dla całego Internetu. Zapora sieciowa nadal powinna ograniczać ruch do konkretnych hostów i portów, ponieważ sam fakt użycia VPN nie zastępuje kontroli dostępu.

Alternatywą może być inny szyfrowany tunel zapewniający uwierzytelnienie obu stron i ochronę transmisji. Niezależnie od wybranego rozwiązania trzeba kontrolować trasy sieciowe, zakres adresów, czas ważności dostępu i możliwość odebrania uprawnień. Połączenie powinno być testowane zarówno pod kątem osiągalności właściwego portu TCP, jak i poprawnego uwierzytelnienia w SQL Server. Przy diagnozie problemu warto rozdzielić błąd tunelu, zapory, DNS, nasłuchiwania portu i samej autoryzacji do bazy.

Szyfrowanie transmisji i bezpieczna konfiguracja klienta

VPN chroni kanał pomiędzy punktami sieci, lecz konfiguracja SQL Server również może wymagać szyfrowania TLS. W SQL Server ustawienie wymuszania szyfrowanego połączenia powoduje, że klient musi ustanowić bezpieczną sesję przed przesyłaniem danych. Certyfikat przypisany do usługi powinien być prawidłowy dla używanej nazwy serwera, mieć zaufany łańcuch certyfikacji i nie być przeterminowany. Nowsze sterowniki mogą wymagać jawnego określenia, czy certyfikat ma być weryfikowany, dlatego ustawienia klienta trzeba dopasować do rzeczywistej konfiguracji certyfikatów.

Przy sprawdzaniu połączenia należy potwierdzić nazwę instancji, adres DNS, port TCP, reguły zapory, stan usługi SQL Server oraz sposób logowania. Narzędzia diagnostyczne mogą pomóc ustalić, czy problem występuje przed uwierzytelnieniem, podczas negocjowania TLS, czy dopiero przy sprawdzaniu uprawnień do konkretnej bazy. Nie należy przechowywać haseł w kodzie aplikacji ani przekazywać ich w niezabezpieczonych plikach konfiguracyjnych. Połączenie przez Internet do SQL Server powinno być projektowane jako dostęp ograniczony, szyfrowany i możliwy do monitorowania, a nie jako zwykłe przekierowanie portu z routera do serwera.