SQL Server na kontrolerze domeny – ograniczenia

Instalacja na kontrolerze domeny ogranicza elastyczność zarządzania i zwiększa ryzyko bezpieczeństwa całej domeny.

Rola kontrolera domeny a instalacja SQL Server

Kontroler domeny Active Directory pełni szczególną funkcję w środowisku Windows Server. Uwierzytelnia konta użytkowników i komputerów, obsługuje Kerberos oraz NTLM, przechowuje informacje katalogowe i uczestniczy w replikacji danych domenowych między kontrolerami. SQL Server jest natomiast systemem zarządzania relacyjnymi bazami danych, który uruchamia własne usługi, korzysta z plików baz danych, wykonuje operacje wejścia i wyjścia oraz może przyjmować połączenia sieciowe. Umieszczenie obu ról na jednym systemie powoduje, że procesy odpowiedzialne za bazę danych działają na serwerze mającym krytyczne znaczenie dla całej domeny.

W środowisku Active Directory kontroler domeny nie korzysta z lokalnej bazy kont SAM w taki sposób jak zwykły komputer członkowski. Z tego powodu instalowanie SQL Server bezpośrednio na kontrolerze domeny ma ograniczenia dotyczące kont usług, uprawnień i zarządzania tożsamością. SQL Server może korzystać z kont usług systemowych albo dedykowanych kont domenowych, lecz dobór takiego konta na kontrolerze domeny wymaga szczególnej ostrożności. Każda pomyłka w nadawaniu uprawnień może dotyczyć nie tylko samej bazy, ale również mechanizmów uwierzytelniania działających dla innych zasobów domenowych.

Konsekwencje dla uprawnień i uwierzytelniania

Usługa SQL Server powinna działać z możliwie ograniczonym zestawem uprawnień, adekwatnym do wykonywanych zadań. Na zwykłym serwerze członkowskim można łatwiej utworzyć konto usługowe, przypisać mu wymagane prawa i odseparować je od administratorów domeny. Kontroler domeny ma jednak podwyższoną rolę w architekturze Active Directory. Nie jest dobrym miejscem do swobodnego testowania konfiguracji kont usługowych, ponieważ błędne przypisanie praw, niewłaściwa delegacja albo nadmierne uprawnienia mogą zwiększyć zakres skutków awarii lub przejęcia procesu.

SQL Server może używać uwierzytelniania Windows, w którym dostęp do instancji jest powiązany z kontami i grupami Active Directory, albo uwierzytelniania SQL Server z loginami przechowywanymi w silniku. W obu przypadkach trzeba rozdzielić uprawnienia do instancji, baz danych, schematów i obiektów. Szczególne znaczenie ma konto uruchamiające usługę, konta używane przez zadania SQL Server Agent oraz tożsamości wykorzystywane do połączeń z innymi zasobami. Na kontrolerze domeny granica między konfiguracją aplikacji a administracją domeną jest mniej wyraźna, dlatego diagnozowanie błędów logowania może wymagać jednoczesnego sprawdzenia SQL Server, usług systemowych i zasad Active Directory.

Wpływ wspólnej roli na dostępność i bezpieczeństwo

Kontroler domeny powinien zapewniać ciągłą dostępność usług katalogowych, DNS i uwierzytelniania. SQL Server może natomiast zużywać znaczną ilość pamięci operacyjnej, wykonywać intensywne operacje dyskowe oraz obciążać procesor podczas zapytań, przebudowy indeksów, kopii zapasowych lub zadań konserwacyjnych. Jeżeli obie role konkurują o te same zasoby, spowolnienie silnika bazy danych może współwystępować z opóźnieniami logowania użytkowników, problemami z rozpoznawaniem nazw albo wydłużeniem replikacji katalogu.

Współdzielenie systemu zwiększa również zakres skutków błędnej konfiguracji sieciowej. SQL Server może nasłuchiwać na porcie TCP przypisanym do instancji, a SQL Server Browser może udostępniać informacje o instancjach przez UDP 1434. Otwarcie dostępu sieciowego powinno być ograniczone do wymaganych hostów i portów, z uwzględnieniem reguł zapory systemu Windows. Nieprawidłowo wystawiona instancja może stać się dodatkowym punktem ataku na serwer, który jednocześnie obsługuje uwierzytelnianie domenowe. Problem dotyczy także aktualizacji: ponowne uruchomienie serwera w celu zainstalowania poprawki SQL Server może czasowo przerwać działanie kontrolera domeny.

Separacja ról ułatwia także tworzenie kopii zapasowych i odtwarzanie. Baza SQL Server wymaga własnej strategii obejmującej kopie pełne, różnicowe lub dziennika transakcji, zależnie od wymagań konkretnej bazy. Active Directory ma odrębne mechanizmy ochrony i odtwarzania katalogu. Gdy oba składniki znajdują się na jednym serwerze, awaria sprzętu, uszkodzenie systemu plików lub nieudana aktualizacja może jednocześnie ograniczyć dostęp do baz oraz usług domenowych. Dodatkowym utrudnieniem jest planowanie restartów i okien serwisowych, ponieważ każda czynność przy jednym komponencie oddziałuje na drugi.

Ocena konfiguracji i bezpieczniejsze rozdzielenie usług

Analizę takiego wdrożenia należy rozpocząć od ustalenia roli serwera, wersji i edycji SQL Server, liczby instancji, sposobu uwierzytelniania oraz kont używanych przez poszczególne usługi. W SQL Server Management Studio można sprawdzić właściwości serwera, konfigurację protokołów i mapowanie loginów, natomiast w SQL Server Configuration Manager należy zweryfikować stan usług oraz ustawienia sieciowe instancji. Warto również przejrzeć dziennik błędów SQL Server, Podgląd zdarzeń Windows, komunikaty usługi KDC i zdarzenia związane z replikacją Active Directory.

Praktyczniejszym rozwiązaniem jest umieszczenie SQL Server na osobnym serwerze członkowskim, który nie pełni funkcji kontrolera domeny. Taki podział pozwala niezależnie dobierać zasoby procesora, pamięci i magazynu danych, aktualizować silnik bazy bez bezpośredniego restartowania usług katalogowych oraz ograniczać uprawnienia kont usługowych do jednego systemu. Kontroler domeny może nadal zapewniać uwierzytelnianie Windows dla użytkowników SQL Server, ale sama instancja bazy pozostaje odseparowana od podstawowej infrastruktury katalogowej.

Jeżeli SQL Server już działa na kontrolerze domeny, nie należy rozpoczynać zmian od przypadkowego usuwania usług ani od modyfikowania kont systemowych. Najpierw trzeba zinwentaryzować bazy, zależności aplikacji, porty, zadania SQL Server Agent, harmonogramy kopii zapasowych i wymagania dotyczące logowania. Następnie należy potwierdzić możliwość odtworzenia baz oraz przygotować plan migracji na serwer członkowski. Diagnostyka komputera powinna obejmować stan dysków, pamięci, obciążenie zasobów i błędy systemowe, ponieważ usterka sprzętowa może ujawniać się jednocześnie jako problem SQL Server i jako niedostępność usług Windows.