Izolacja portów SQL w sieci VLAN

Izolacja portów SQL w sieci VLAN to praktyka bezpieczeństwa wydzielająca ruch bazodanowy do osobnego segmentu sieci.

Rola segmentacji VLAN dla ruchu bazodanowego

Izolacja portów SQL w sieci VLAN polega na ograniczeniu komunikacji związanej z bazą danych do określonego segmentu logicznego. VLAN, czyli wirtualna sieć lokalna, rozdziela urządzenia na poziomie przełączników Ethernet niezależnie od ich fizycznego położenia. Ruch z różnych VLAN-ów jest od siebie oddzielony, a komunikacja między nimi wymaga przejścia przez urządzenie routujące, najczęściej przełącznik warstwy trzeciej lub zaporę sieciową. Samo przypisanie portu do VLAN-u nie jest jednak pełną kontrolą dostępu. Określa przede wszystkim, do jakiej domeny rozgłoszeniowej należy urządzenie.

W praktyce osobny VLAN może służyć do przenoszenia połączeń między aplikacją a silnikiem SQL, natomiast użytkownicy, stacje robocze, urządzenia administracyjne i systemy kopii zapasowych mogą znajdować się w innych segmentach. Taki podział zmniejsza zasięg ruchu rozgłoszeniowego i utrudnia przypadkowe nawiązanie połączenia z portem bazy danych. Nie zastępuje on uwierzytelniania, autoryzacji ani szyfrowania. Jeżeli reguły routingu pozwalają na dostęp z wielu sieci, sama nazwa VLAN-u nie zapewnia wystarczającej izolacji.

Porty dostępowe, trunk i granica routingu

Port przełącznika podłączony do serwera lub stacji roboczej jest zwykle konfigurowany jako port dostępowy przypisany do jednego VLAN-u. Ramki wychodzące z takiego portu nie muszą zawierać znacznika VLAN, ponieważ urządzenie końcowe działa w pojedynczym segmencie. Port trunk służy natomiast do przenoszenia ruchu wielu VLAN-ów między przełącznikami, przełącznikiem i routerem albo przełącznikiem i hostem świadomie obsługującym tagowanie. W sieciach Ethernet najczęściej wykorzystuje się do tego mechanizm opisany w IEEE 802.1Q.

Kluczowym punktem kontroli jest routing między VLAN-ami. Gdy klient bazy danych znajduje się w jednym segmencie, a usługa SQL w innym, pakiety muszą przejść przez bramę warstwy trzeciej. W tym miejscu można zastosować listy kontroli dostępu oraz reguły zapory ograniczające źródłowe i docelowe adresy IP, protokół TCP lub UDP oraz port usługi. Należy zezwalać tylko na wymagane kierunki komunikacji. Reguła dopuszczająca cały ruch między dwoma VLAN-ami osłabia sens segmentacji, ponieważ urządzenia uzyskują szeroki dostęp mimo logicznego podziału.

Numer portu zależy od konkretnego silnika i konfiguracji instancji, dlatego nie powinien być zgadywany na podstawie samej nazwy SQL. W dokumentacji i konfiguracji trzeba rozróżnić port nasłuchu usługi bazodanowej, porty pomocnicze używane przez mechanizmy wykrywania lub zarządzania oraz połączenia administracyjne. Kontrola powinna obejmować także IPv6, jeżeli jest aktywne, ponieważ ograniczenie reguł wyłącznie do IPv4 może pozostawić alternatywną ścieżkę dostępu.

Projektowanie reguł dostępu do usługi SQL

Poprawnie zaprojektowana izolacja rozpoczyna się od określenia, które systemy rzeczywiście muszą łączyć się z bazą. Serwer aplikacyjny powinien otrzymać dostęp tylko do adresu i portu konkretnej usługi, a nie do całej podsieci. Stacje robocze użytkowników nie powinny automatycznie uzyskiwać takiego samego zakresu dostępu jak serwery aplikacyjne. Osobne reguły mogą być potrzebne dla monitoringu, wykonywania kopii zapasowych i kontrolowanych połączeń administracyjnych. Każdą z nich warto opisać źródłem, celem, portem, protokołem i uzasadnieniem biznesowo-technicznym.

Ograniczenie portu nie oznacza, że usługa jest bezpieczna niezależnie od sposobu komunikacji. Połączenia SQL powinny być chronione mechanizmami uwierzytelniania właściwymi dla używanego silnika, a tam, gdzie jest to wymagane, również szyfrowaniem transportowym. Należy sprawdzić, czy aplikacja nie korzysta z drugiego adresu, aliasu DNS albo alternatywnej instancji, która omija zaplanowaną ścieżkę. Istotne są także trasy statyczne, reguły NAT, interfejsy dodatkowe oraz konfiguracja lokalnego zapora na serwerze.

Weryfikacja obejmuje test z dozwolonego źródła i test z lokalizacji, która dostępu nie powinna mieć. Należy sprawdzić, czy połączenie jest możliwe wyłącznie przez ustalony adres, czy port pozostaje zamknięty z innych VLAN-ów oraz czy logi zapory i przełączników rejestrują odrzucone próby. Skanowanie portów powinno odbywać się w uzgodnionym środowisku, ponieważ niekontrolowane testy mogą obciążyć usługę albo zostać potraktowane jako incydent. Po zmianach trzeba ponownie zweryfikować routing, reguły zapory, rozwiązywanie nazw i działanie aplikacji.

Skutki błędnej konfiguracji i utrzymanie izolacji

Typowym błędem jest pozostawienie portu przełącznika w domyślnym VLAN-ie, dopuszczenie niepotrzebnych VLAN-ów na trunku albo ustawienie zbyt szerokiej reguły międzysegmentowej. Problemy powoduje również niespójność między konfiguracją przełącznika, bramy routującej i lokalnej zapory systemu operacyjnego. W efekcie usługa może być dostępna z większej liczby urządzeń, niż zakładano, albo przeciwnie, aplikacja może utracić połączenie po zmianie adresacji. Błędny opis portu lub brak dokumentacji utrudnia późniejsze rozpoznanie, czy problem wynika z sieci, zapory, DNS, uwierzytelniania czy samego silnika SQL.

Izolację należy traktować jako konfigurację podlegającą przeglądom, a nie jednorazową zmianę. Po dodaniu serwera, zmianie adresu, migracji usługi lub aktualizacji topologii trzeba sprawdzić tabelę VLAN-ów, dozwolone trasy i reguły dostępu. Przydatne są okresowe przeglądy nieużywanych wyjątków, analiza logów połączeń oraz porównanie rzeczywistego ruchu z dokumentowanym modelem komunikacji. Diagnostyka problemów z dostępem do bazy powinna obejmować kolejno stan interfejsu, przypisanie VLAN-u, adresację IP, bramę, routing, zaporę i dopiero potem parametry klienta SQL.

W środowisku, w którym występują objawy takie jak okresowe rozłączanie aplikacji, brak możliwości połączenia po zmianie sieci albo nieoczekiwane otwarcie portu, potrzebna jest analiza całej ścieżki pakietu. Sprawdza się wtedy konfigurację przełącznika, urządzeń routujących, zapór i systemu operacyjnego, a także zgodność adresu nasłuchu usługi z adresem używanym przez klienta. Izolacja portów SQL jest skuteczna dopiero wtedy, gdy segmentacja VLAN, routing, reguły zapory i konfiguracja usługi tworzą spójny, możliwy do zweryfikowania model dostępu.