Polityki haseł AD a loginy SQL

Loginy SQL mogą dziedziczyć politykę haseł z Windows, jeśli włączono opcję CHECK_POLICY.

Polityki haseł AD a loginy SQL – czym jest zależność

Polityka haseł w Active Directory oraz zasady dotyczące loginów SQL opisują podobny obszar bezpieczeństwa, ale działają na różnych poziomach. Active Directory, często skracane do AD, zarządza tożsamościami użytkowników w środowisku Windows. Określa między innymi minimalną długość hasła, wymaganie używania różnych typów znaków, historię poprzednich haseł, okres ich ważności oraz czas blokady po kolejnych nieudanych próbach logowania. Są to reguły przypisane do kont utrzymywanych w katalogu domenowym.

Login SQL jest natomiast kontem rozpoznawanym przez silnik bazy danych. Może być powiązany z użytkownikiem domenowym albo działać jako niezależne konto uwierzytelniane przez samą instancję SQL. W tym drugim przypadku hasło nie musi być zarządzane bezpośrednio przez Active Directory. Wyjątkiem jest sytuacja, w której dla danego loginu włączono kontrolę zgodności z zasadami systemu Windows. Wtedy część reguł dotyczących haseł AD może zostać zastosowana również do logowania SQL.

Warto rozdzielić trzy pojęcia: konto, login i użytkownik bazy danych. Konto domenowe istnieje w katalogu AD, login jest obiektem rozpoznawanym przez instancję SQL, a użytkownik bazy danych otrzymuje uprawnienia wewnątrz konkretnej bazy. Jeden login może mieć dostęp do kilku baz, a w każdej z nich może być powiązany z osobnym użytkownikiem i innym zestawem uprawnień. Sama zgodność hasła z polityką nie nadaje jeszcze dostępu do danych.

Polityki haseł AD a loginy SQL – kontekst techniczny i porównania

W praktyce spotyka się dwa główne modele uwierzytelniania. Przy uwierzytelnianiu Windows użytkownik przekazuje poświadczenia systemowe, a ich weryfikacja odbywa się za pośrednictwem domeny. SQL Server nie musi wtedy przechowywać osobnego hasła dla każdej osoby korzystającej z bazy. Dostęp może być przyznany pojedynczemu użytkownikowi domenowemu albo grupie domenowej. Takie rozwiązanie ułatwia odebranie dostępu po zmianie stanowiska, wyłączeniu konta lub usunięciu osoby z odpowiedniej grupy.

Uwierzytelnianie SQL wykorzystuje login zapisany w instancji. Hasło jest sprawdzane przez mechanizmy silnika SQL, a administrator może zdecydować, czy login ma podlegać zasadom haseł systemu Windows. Opcja kontroli polityki wpływa na wymagania dotyczące złożoności, długości, historii i wygasania hasła. Osobna opcja może dotyczyć blokowania loginu po przekroczeniu ustalonej liczby nieudanych prób. Nie należy zakładać, że wszystkie ustawienia AD zostaną automatycznie skopiowane jeden do jednego do każdego loginu SQL.

Znaczenie ma także zakres obowiązywania zasad. W domenie mogą działać zasady wynikające z ustawień domenowych, a dla wybranych jednostek organizacyjnych mogą być stosowane dodatkowe reguły. W SQL Server ustawienia kontroli hasła odnoszą się do loginów, dla których zostały włączone. Zmiana polityki domenowej może więc wpłynąć na przyszłą zmianę hasła lub kolejne próby uwierzytelnienia, ale nie zawsze natychmiast zmienia stan każdego istniejącego loginu.

Porównanie można przedstawić następująco:

• konto Windows jest zarządzane przez Active Directory,
• login SQL jest zarządzany przez instancję bazy danych,
• uwierzytelnianie Windows korzysta z poświadczeń domenowych,
• uwierzytelnianie SQL wykorzystuje hasło zapisane dla loginu SQL,
• kontrola polityki pozwala objąć wybrany login SQL regułami haseł Windows,
• uprawnienia do baz są przyznawane osobno od samego procesu sprawdzania hasła.

Polityki haseł AD a loginy SQL – typowe problemy

Jednym z częstszych problemów jest wygaśnięcie hasła loginu SQL w momencie, gdy aplikacja korzysta ze stałego wpisu konfiguracyjnego. Program może nadal próbować połączenia przy użyciu starego hasła, a kolejne nieudane próby mogą doprowadzić do blokady loginu. Objawem bywa komunikat o odmowie dostępu, mimo że sama instancja SQL działa poprawnie. W takiej sytuacji należy sprawdzić stan loginu, datę ostatniej zmiany hasła, informację o wygaśnięciu oraz ustawienia aplikacji.

Innym problemem jest niespójność pomiędzy nazwą loginu a użytkownikiem bazy danych. Login może istnieć na poziomie instancji, ale nie mieć odpowiedniego użytkownika w konkretnej bazie. Może też istnieć użytkownik bez poprawnego powiązania z loginem po odtworzeniu bazy z kopii, przeniesieniu jej na inną instancję lub zmianie identyfikatora konta domenowego. Wtedy test hasła może przebiegać prawidłowo, lecz dostęp do obiektów nadal będzie odrzucany.

Problemy pojawiają się również po zaostrzeniu zasad w AD. Hasło, które wcześniej spełniało wymagania, może przestać być akceptowane przy kolejnej zmianie. Zdarza się też, że konto używane przez usługę nie jest objęte tymi samymi regułami co zwykłe konto użytkownika. Nie powinno się jednak wyłączać kontroli polityki tylko po to, aby szybko usunąć błąd. Takie działanie może ukryć rzeczywistą przyczynę i utrudnić późniejszą kontrolę dostępu.

Warto zwrócić uwagę na komunikaty rejestrowane w dziennikach. Należy odróżnić nieprawidłowe hasło od zablokowanego loginu, wygasłego hasła, braku mapowania użytkownika oraz braku uprawnień do konkretnej bazy lub obiektu. Ten sam komunikat widoczny w aplikacji może wynikać z kilku różnych przyczyn, dlatego diagnoza powinna obejmować system, ustawienia SQL, konfigurację aplikacji i kolejność zdarzeń w czasie.

Polityki haseł AD a loginy SQL – praktyczne wskazówki konfiguracji

Przed zmianą zasad należy sporządzić listę loginów używanych przez aplikacje, zadania automatyczne, narzędzia administracyjne i połączenia ręczne. Przy każdym loginie powinno się określić sposób uwierzytelniania, właściciela, zakres dostępu, zależności od usług oraz sposób bezpiecznej zmiany poświadczeń. Pozwala to uniknąć sytuacji, w której zmiana hasła zatrzymuje działanie programu korzystającego z nieudokumentowanego połączenia.

Dla kont osobowych korzystne jest używanie uwierzytelniania Windows i grup domenowych. Ułatwia to centralne zarządzanie dostępem oraz ogranicza liczbę osobnych haseł. Loginy SQL mogą być potrzebne w określonych scenariuszach, ale powinny mieć jasno opisane zastosowanie, możliwie wąskie uprawnienia i ustalony sposób rotacji hasła. Nie należy wykorzystywać jednego loginu do wielu niezależnych aplikacji, jeżeli utrudniałoby to ustalenie źródła błędu lub szybkie odebranie dostępu.

Po włączeniu kontroli polityki warto wykonać test zmiany hasła, test logowania po zmianie oraz test działania aplikacji. Należy również sprawdzić, czy hasło nie jest zapisane w wielu plikach konfiguracyjnych, zadaniach harmonogramu lub usługach uruchamianych w tle. Jeżeli hasło wygasa, procedura jego zmiany powinna uwzględniać kolejność aktualizacji wszystkich zależnych miejsc.

Dokumentacja powinna wskazywać, które reguły pochodzą z AD, które zostały ustawione dla instancji SQL, a które wynikają z konfiguracji konkretnego loginu. Przydatne jest zapisywanie dat zmian, osoby wykonującej operację i wyniku testu. W razie problemu łatwiej wtedy ustalić, czy błąd pojawił się po modyfikacji polityki, zmianie hasła, odtworzeniu bazy, aktualizacji programu czy zmianie członkostwa w grupie.

Polityki haseł AD a loginy SQL – kiedy zgłosić się do serwisu

Wsparcie serwisowe może być potrzebne, gdy po zmianie polityki AD przestają działać połączenia aplikacji z bazą, login SQL blokuje się mimo poprawnych danych, użytkownik domenowy traci dostęp do wybranej bazy albo nie można ustalić, gdzie przechowywane są zależności od danego hasła. Szczególnej uwagi wymaga sytuacja, w której problem dotyczy kilku komputerów, wielu kont lub powtarza się po każdej zmianie zasad bezpieczeństwa.

W takich przypadkach Warszawskie Pogotowie Komputerowe 24/7 może przeanalizować konfigurację stacji roboczych, usług, połączeń z bazą i zależności pomiędzy AD a loginami SQL. Przed przekazaniem dostępu powinno się przygotować opis objawów, czas wystąpienia problemu, rodzaj używanego uwierzytelniania oraz informacje o ostatnich zmianach. Nie należy przesyłać haseł w wiadomości ani umieszczać ich w publicznie dostępnych załącznikach.

Do serwisu warto zgłosić się także wtedy, gdy potrzebne jest uporządkowanie uprawnień, rozdzielenie loginów aplikacyjnych, przejście na uwierzytelnianie Windows albo przygotowanie bezpiecznej procedury rotacji haseł. Dobrze przeprowadzona diagnoza powinna rozdzielić problem polityki haseł od problemu uprawnień, mapowania użytkownika, konfiguracji sieci i działania samej aplikacji. Dzięki temu korekta może objąć właściwy element, bez przypadkowego osłabiania zasad ochrony kont.