SQL Server w DMZ

SQL Server w strefie DMZ wymaga szczególnie restrykcyjnej konfiguracji zapory i minimalnej powierzchni ataku.

Rola strefy DMZ w architekturze SQL Server

SQL Server umieszczony w strefie DMZ powinien być traktowany jako serwer dostępny z mniej zaufanego segmentu sieci, a nie jako element wewnętrznej sieci biurowej. Strefa DMZ ogranicza skutki ewentualnego przejęcia hosta, ponieważ oddziela system udostępniający usługę od komputerów użytkowników, kontrolerów domeny i innych serwerów zaplecza. Sama obecność serwera w DMZ nie zapewnia jednak bezpieczeństwa. Ochrona zależy od reguł zapory, sposobu uwierzytelniania, aktualizacji systemu oraz ograniczenia liczby usług nasłuchujących na interfejsach sieciowych.

W typowym układzie aplikacja znajdująca się w DMZ nie powinna otrzymywać swobodnego dostępu do całej instancji SQL Server. Reguły sieciowe powinny wskazywać konkretne adresy źródłowe, adres serwera docelowego, port oraz protokół. Jeżeli baza danych jest umieszczona w sieci wewnętrznej, połączenie z DMZ powinno być dopuszczone wyłącznie dla określonego serwera aplikacyjnego i tylko do wymaganej instancji. Dostęp administracyjny powinien przebiegać osobnym, kontrolowanym kanałem z sieci zarządzającej, a nie przez publicznie dostępny interfejs DMZ.

Porty, instancje i reguły zapory

Dla domyślnej instancji SQL Server często używany jest port TCP 1433, ale administrator może skonfigurować inny port. W przypadku nazwanych instancji SQL Server może korzystać z portów dynamicznych. Usługa SQL Server Browser używa portu UDP 1434 do odpowiadania na zapytania o port przypisany do nazwanej instancji. W środowisku DMZ bezpieczniejszym rozwiązaniem jest zwykle przypisanie instancji stałego portu TCP i odwoływanie się do niego bez potrzeby publikowania usługi SQL Server Browser.

Reguła zapory nie powinna być tworzona wyłącznie na podstawie nazwy programu lub szerokiego zakresu adresów. Należy potwierdzić, na którym interfejsie i porcie nasłuchuje dana instancja, a następnie ograniczyć ruch do wymaganych źródeł. Po zmianie portu trzeba zaktualizować konfigurację klienta, ciąg połączenia oraz reguły zapór na wszystkich urządzeniach pośredniczących. Otwieranie całego zakresu portów, dopuszczanie ruchu z dowolnego adresu albo zezwalanie na połączenia przychodzące z Internetu zwiększa powierzchnię ataku i utrudnia późniejszą diagnostykę.

Uwierzytelnianie, szyfrowanie i minimalne uprawnienia

Połączenie z SQL Server powinno korzystać z uwierzytelniania dopasowanego do architektury środowiska. Jeżeli używane jest uwierzytelnianie Windows, konto usługi aplikacyjnej powinno otrzymać tylko te prawa do bazy, które są niezbędne do wykonywania zapytań. W przypadku uwierzytelniania SQL Server należy stosować odrębne konta, silne i unikalne hasła oraz ograniczone role. Konto sa nie powinno być używane przez aplikację. Przydzielanie aplikacji roli sysadmin usuwa praktyczne granice uprawnień i może pozwolić na wykonanie operacji administracyjnych po przejęciu danych logowania.

Ruch między aplikacją a SQL Server warto chronić przy użyciu szyfrowania TLS skonfigurowanego po stronie serwera i klienta. Certyfikat przypisany do SQL Server powinien być prawidłowy dla używanej nazwy serwera, mieć zaufany łańcuch certyfikacji i nie być certyfikatem wygasłym. W konfiguracji klienta nie należy bezrefleksyjnie wyłączać weryfikacji certyfikatu, ponieważ usuwa to ochronę przed podszyciem się pod serwer. Przydatne jest także wyłączenie nieużywanych protokołów i usług, ograniczenie nasłuchu do potrzebnych adresów oraz rejestrowanie prób uwierzytelnienia, zmian konfiguracji i błędów połączeń.

Diagnostyka połączeń i utrzymanie instancji w DMZ

Diagnostykę należy rozpocząć od ustalenia topologii: adresu klienta, adresu SQL Server, nazwy instancji, rzeczywistego portu TCP oraz kierunku połączenia. Następnie można sprawdzić rozwiązywanie nazwy, dostępność portu z właściwego segmentu i odpowiedź samego SQL Server. Sam fakt, że host odpowiada na ping, nie potwierdza dostępności usługi bazodanowej, ponieważ protokół ICMP może być blokowany niezależnie od ruchu TCP. Z kolei otwarty port nie oznacza jeszcze poprawnego logowania ani prawidłowego działania zapytań.

Jeżeli połączenie działa tylko przy użyciu adresu IP, problem może dotyczyć DNS, aliasu klienta albo nazwy instancji. Jeżeli domyślna instancja działa, a nazwana instancja nie odpowiada, należy zweryfikować port dynamiczny, działanie SQL Server Browser i reguły UDP 1434, zamiast automatycznie otwierać kolejne porty. Błędy logowania trzeba rozdzielić od blokady sieciowej: komunikaty o przekroczeniu czasu oczekiwania wskazują zwykle na trasę lub zaporę, natomiast odrzucenie połączenia może oznaczać nieaktywną usługę albo brak nasłuchu na wskazanym porcie. Utrzymanie obejmuje także aktualizacje SQL Server i systemu operacyjnego, kontrolę kopii zapasowych, przegląd kont oraz okresową weryfikację reguł zapory.