Reguły zapory dla portu SQL

Reguły zapory dla portu SQL dopuszczają ruch przychodzący na numerze, na którym nasłuchuje instancja.

Rola reguły zapory przy połączeniu z bazą SQL

Reguła zapory dla portu SQL określa, czy system może przyjąć połączenie przychodzące kierowane do portu, na którym działa konkretna instancja silnika bazy danych. Zapora analizuje między innymi adres źródłowy, adres docelowy, protokół transportowy, numer portu oraz kierunek ruchu. Jeżeli połączenie spełnia warunki reguły zezwalającej, pakiety mogą dotrzeć do procesu nasłuchującego. Jeżeli nie ma pasującej reguły albo obowiązuje reguła blokująca, połączenie zostaje odrzucone lub odfiltrowane przed przekazaniem do aplikacji bazodanowej.

Samo otwarcie portu w zaporze nie uruchamia usługi SQL i nie powoduje, że baza zaczyna nasłuchiwać. Muszą jednocześnie działać silnik bazy danych, odpowiedni protokół sieciowy oraz konfiguracja nasłuchiwania na właściwym interfejsie. Port otwarty w zaporze, ale nieużywany przez żadną usługę, nie zapewnia działającego połączenia. Odwrotna sytuacja również prowadzi do błędu: proces może nasłuchiwać lokalnie, lecz zapora może blokować ruch z innych komputerów.

Ustalenie portu używanego przez instancję

Regułę należy tworzyć dla rzeczywistego numeru portu przypisanego do instancji, a nie dla nazwy „SQL” traktowanej jako uniwersalny port. Różne silniki baz danych, instancje oraz konfiguracje mogą korzystać z innych numerów. Także jedna maszyna może obsługiwać kilka instancji, z których każda nasłuchuje na odrębnym porcie. Informację trzeba odczytać z konfiguracji danego silnika, dziennika uruchomieniowego albo narzędzia administracyjnego właściwego dla używanego produktu.

Ważne jest również rozróżnienie portu stałego i dynamicznego. Przy porcie stałym instancja po uruchomieniu korzysta z określonego numeru, więc reguła zapory może wskazywać konkretny port TCP. Przy przydziale dynamicznym numer może zmienić się po restarcie usługi. Wtedy reguła oparta na pojedynczym numerze może przestać odpowiadać aktualnej konfiguracji. Stabilne połączenia wymagają ustalenia, jaki mechanizm wyboru portu stosuje dana instancja, oraz odpowiedniego dostosowania reguł i klientów.

Parametry bezpiecznej reguły przychodzącej

Reguła powinna wskazywać właściwy protokół, najczęściej TCP, ponieważ połączenie klienta z usługą bazy danych korzysta z transportu zgodnego z konfiguracją konkretnego silnika. Zakres źródłowych adresów IP należy ograniczyć do komputerów, podsieci lub segmentów sieci, które rzeczywiście muszą korzystać z bazy. Otwieranie portu dla wszystkich adresów, jeżeli nie jest konieczne, zwiększa liczbę hostów mogących próbować nawiązać połączenie. W regule warto także określić profil sieciowy i interfejsy, na których dostęp ma być dozwolony.

Port SQL nie powinien być mylony z uwierzytelnianiem ani autoryzacją. Zezwolenie zapory umożliwia dotarcie do usługi, ale dopiero silnik bazy danych sprawdza dane logowania, uprawnienia konta i dostęp do konkretnej bazy lub obiektu. Po zmianie reguły należy zweryfikować połączenie z hosta należącego do dozwolonego zakresu oraz z hosta spoza tego zakresu. Test powinien potwierdzić zarówno oczekiwany dostęp, jak i blokowanie ruchu, który nie spełnia założeń.

Diagnostyka i utrzymanie konfiguracji

Gdy klient nie łączy się z instancją, diagnostykę trzeba prowadzić warstwami. Najpierw należy sprawdzić, czy usługa działa i nasłuchuje na oczekiwanym adresie oraz porcie. Następnie trzeba potwierdzić, że klient używa prawidłowej nazwy hosta, numeru portu i protokołu. Kolejnym krokiem jest analiza lokalnej zapory serwera, zapór pośrednich oraz reguł sieciowych na trasie. Dopiero po potwierdzeniu przejścia ruchu warto analizować błędne poświadczenia, brak uprawnień albo problemy z konfiguracją samej bazy.

Zmiany reguł powinny być opisane nazwą usługi, portem, zakresem źródeł i uzasadnieniem. Po aktualizacji silnika, przeniesieniu instancji lub zmianie adresacji sieciowej trzeba ponownie porównać konfigurację nasłuchiwania z regułami zapory. Należy usuwać nieużywane wyjątki, aby nie pozostawiać otwartych portów po zakończeniu migracji lub wyłączeniu instancji. W środowisku produkcyjnym przydatne są także dzienniki zapory i logi silnika, ponieważ pozwalają ustalić, czy pakiet został zablokowany przez filtr, czy dotarł do usługi i został odrzucony na etapie obsługi połączenia.