Mapa logowania

Mapa logowania to zestawienie powiązań między loginami serwera a użytkownikami poszczególnych baz danych.

Powiązanie logowania serwera z użytkownikiem bazy

Mapa logowania opisuje relację pomiędzy kontem rozpoznawanym przez instancję serwera baz danych a użytkownikiem zdefiniowanym wewnątrz konkretnej bazy. W terminologii Microsoft SQL Server logowanie, czyli login, jest obiektem na poziomie instancji, natomiast użytkownik, czyli user, należy do pojedynczej bazy danych. Samo utworzenie loginu nie daje jeszcze dostępu do wszystkich baz. Dostęp powstaje dopiero wtedy, gdy w wybranej bazie istnieje użytkownik powiązany z tym loginem oraz gdy użytkownik otrzyma odpowiednie członkostwo w rolach lub uprawnienia bezpośrednie.

Jedno logowanie może mieć użytkownika o tej samej lub innej nazwie w wielu bazach, a każda z tych relacji jest niezależna. Przykładowo login raporty_login może być powiązany z użytkownikiem raporty_user w bazie Sprzedaz, ale nie musi mieć żadnego użytkownika w bazie Magazyn. Mapa powinna więc wskazywać co najmniej nazwę instancji, nazwę loginu, nazwę bazy, nazwę użytkownika, identyfikator SID oraz sposób nadania uprawnień. Taki opis pozwala odróżnić błąd uwierzytelniania od błędu autoryzacji.

SID, typy podmiotów i skutki odtworzenia bazy

W SQL Server podstawą powiązania loginu z użytkownikiem jest identyfikator SID, a nie sama nazwa tekstowa. Login przechowywany na poziomie instancji ma własny SID, podobnie jak użytkownik zapisany w bazie. Gdy wartości SID są zgodne, serwer może potraktować użytkownika bazodanowego jako mapowanie danego loginu. Z tego powodu dwa obiekty o identycznych nazwach nie muszą stanowić poprawnego powiązania. Zmiana nazwy loginu nie musi zerwać mapowania, natomiast usunięcie loginu i utworzenie nowego obiektu o tej samej nazwie może utworzyć inny SID.

Informacje o loginach można analizować w widoku katalogowym sys.server_principals, a użytkowników konkretnej bazy w sys.database_principals. Kolumna type_desc rozróżnia między innymi loginy SQL, użytkowników Windows oraz grupy Windows. W bazie mogą występować również użytkownicy zawarci, czyli tacy, których uwierzytelnianie nie wymaga klasycznego loginu instancji. Mapa logowania musi zaznaczać ten przypadek, ponieważ użytkownik zawarty nie jest zwykłym mapowaniem loginu serwerowego.

Typowym problemem jest odtworzenie kopii bazy na innej instancji. Użytkownik zostaje wtedy przeniesiony razem z bazą, ale odpowiadający mu login może nie istnieć na serwerze docelowym albo może mieć inny SID. W efekcie konto może poprawnie przejść etap uwierzytelnienia, lecz nie uzyskać dostępu do bazy. Taki użytkownik bywa określany jako osierocony. Sama zmiana nazwy użytkownika nie naprawia problemu; trzeba odtworzyć właściwe powiązanie z istniejącym loginem, na przykład poleceniem ALTER USER ... WITH LOGIN = ..., po uprzednim sprawdzeniu, czy wskazany login jest właściwym kontem.

Odczyt mapy i weryfikacja uprawnień

Przy analizie mapy należy najpierw ustalić, czy login istnieje na poziomie instancji, a następnie sprawdzić jego odpowiednik w każdej bazie, do której ma mieć dostęp. W praktyce porównuje się nazwy, typy podmiotów i wartości SID. Przydatne są także kolumny authentication_type_desc oraz default_schema_name w sys.database_principals. Schemat domyślny wpływa na rozwiązywanie nazw obiektów, ale sam w sobie nie nadaje uprawnień.

Drugim etapem jest sprawdzenie, co użytkownik może robić po poprawnym zalogowaniu. Członkostwo w rolach bazodanowych opisuje widok sys.database_role_members, a uprawnienia jawne można odczytać z sys.database_permissions. Należy również uwzględnić role niestandardowe, dziedziczenie uprawnień przez role oraz uprawnienia nadane na poziomie instancji. Konto należące do roli sysadmin ma uprawnienia administracyjne w instancji, dlatego analiza pojedynczego użytkownika bazodanowego nie pokazuje pełnego obrazu dla takiego loginu.

Mapa powinna rozróżniać co najmniej cztery sytuacje: brak loginu, login bez użytkownika w danej bazie, użytkownik z niezgodnym SID oraz poprawne mapowanie z określonym zakresem uprawnień. Warto też zapisać stan konta, domyślną bazę loginu i sposób uwierzytelniania. Jeśli domyślna baza jest niedostępna, użytkownik może otrzymać błąd podczas logowania mimo poprawnych danych; w SQL Server można wtedy użyć innej dostępnej bazy jako punktu połączenia i osobno skorygować konfigurację loginu.

Znaczenie mapy przy diagnostyce połączeń

Mapa logowania jest użyteczna podczas badania błędów aplikacji, migracji oraz przywracania kopii baz. Komunikat o odrzuconym logowaniu wskazuje zwykle na problem z uwierzytelnieniem, istnieniem loginu, hasłem, blokadą lub trybem uwierzytelniania. Komunikat o braku dostępu do konkretnej bazy może natomiast oznaczać brak użytkownika, niezgodność SID albo niewystarczające uprawnienia. Rozdzielenie tych etapów ogranicza ryzyko nadania zbyt szerokich praw tylko po to, aby ominąć nieprawidłowe mapowanie.

Przed zmianą mapy należy ustalić, który login powinien reprezentować daną osobę, usługę lub aplikację, oraz sprawdzić zależności od schematów, ról i właścicieli obiektów. Nie powinno się usuwać użytkownika ani loginu bez sprawdzenia, czy nie jest właścicielem schematu, zadania lub obiektu zabezpieczeń. Po korekcie trzeba wykonać kontrolowane połączenie do właściwej bazy i potwierdzić zarówno dostęp do wymaganych obiektów, jak i brak dostępu do zasobów nieobjętych zakresem. Wynik warto zachować w dokumentacji administracyjnej wraz z datą, nazwą instancji i uzasadnieniem zmiany.