Widoki sys.server_principals i sys.database_principals

sys.server_principals i sys.database_principals różnią się zakresem — pierwszy dotyczy instancji, drugi konkretnej bazy.

Zakres informacji przechowywanych przez oba widoki

sys.server_principals oraz sys.database_principals są katalogowymi widokami systemowymi Microsoft SQL Server. Oba opisują podmioty bezpieczeństwa, czyli nazwane tożsamości, którym można przypisywać uprawnienia, ale działają na różnych poziomach. sys.server_principals pokazuje podmioty zdefiniowane w obrębie instancji SQL Server. Ich istnienie nie zależy od jednej konkretnej bazy danych. sys.database_principals pokazuje natomiast podmioty zdefiniowane w kontekście aktualnej bazy danych, dlatego wynik drugiego widoku zależy od bazy wskazanej w zapytaniu.

W obu widokach można znaleźć między innymi nazwę podmiotu, jego identyfikator oraz typ. W zależności od wersji SQL Server i rodzaju obiektu typ może wskazywać na logowanie SQL Server, użytkownika bazy danych, rolę, grupę systemu Windows albo inną kategorię obsługiwaną przez dany silnik. Identyfikator z poziomu serwera i identyfikator z poziomu bazy nie powinny być automatycznie traktowane jako ten sam klucz. Do analizy zależności między logowaniem a użytkownikiem bazy często wykorzystuje się identyfikator zabezpieczeń SID, lecz zgodność nazwy nie jest wystarczającym dowodem prawidłowego powiązania.

Logowanie, użytkownik bazy i rola to różne obiekty

W SQL Server logowanie, nazywane po angielsku login, jest podmiotem na poziomie instancji. To ono może uzyskać dostęp do serwera i zostać użyte do uwierzytelnienia połączenia. Użytkownik bazy danych, czyli database user, jest podmiotem na poziomie konkretnej bazy. Samo istnienie logowania w sys.server_principals nie oznacza jeszcze, że w każdej bazie istnieje odpowiadający mu użytkownik ani że posiada on uprawnienia do odczytu lub modyfikacji danych.

Rola jest innym typem podmiotu bezpieczeństwa. Role występują zarówno na poziomie serwera, jak i w bazie danych. Rola serwerowa może grupować logowania i otrzymywać uprawnienia dotyczące całej instancji, natomiast rola bazodanowa służy do grupowania użytkowników i nadawania uprawnień w konkretnej bazie. Dlatego przy wyjaśnianiu, dlaczego konto może połączyć się z SQL Server, lecz nie może wykonać zapytania w wybranej bazie, trzeba sprawdzić oba poziomy: logowanie w sys.server_principals, a następnie użytkownika i jego członkostwo w rolach w sys.database_principals.

Zapytania diagnostyczne i interpretacja wyników

Widok instancji można sprawdzać bez zmiany kontekstu bazy, na przykład zapytaniem SELECT name, type_desc, is_disabled FROM sys.server_principals;. Kolumna is_disabled ma znaczenie przede wszystkim dla logowań, ponieważ wyłączone logowanie nie może zostać użyte do zwykłego uwierzytelnienia. Widok bazodanowy należy odczytywać w konkretnej bazie, na przykład po wykonaniu USE NazwaBazy;, a następnie zapytania SELECT name, type_desc, authentication_type_desc FROM sys.database_principals;. Zmiana kontekstu jest istotna: identyczne zapytanie wykonane w dwóch bazach może zwrócić różne użytkowniki, role i identyfikatory.

Podczas analizy dostępu warto zestawić logowania z użytkownikami bazy, korzystając z kontrolowanego porównania SID-ów. Przykładowo można sprawdzić relację między sys.server_principals.sid i sys.database_principals.sid, pamiętając, że użytkownicy bezpośrednio uwierzytelniani w bazie, role oraz użytkownicy zawierający się w innych mechanizmach uwierzytelniania mogą wymagać odrębnej interpretacji. W przypadku użytkownika osieroconego, czyli istniejącego w bazie bez poprawnie odpowiadającego mu logowania, nazwa może wyglądać prawidłowo, ale mapowanie bezpieczeństwa będzie niespójne. Nie należy naprawiać takiej sytuacji wyłącznie przez zmianę nazwy; najpierw trzeba ustalić właściwe logowanie, SID oraz oczekiwany model dostępu.

Same widoki principals nie pokazują pełnego obrazu uprawnień. Do ustalenia, co dany podmiot może robić, potrzebne są także widoki uprawnień, członkostwa w rolach i obiektów zabezpieczanych, między innymi sys.database_permissions, sys.server_permissions oraz sys.database_role_members. Uprawnienie może pochodzić bezpośrednio od użytkownika, z roli bazodanowej, z roli serwerowej albo z hierarchii uprawnień. Z tego powodu obecność podmiotu w jednym z dwóch widoków nie jest równoznaczna z przyznaniem konkretnej operacji, takiej jak SELECT, INSERT, UPDATE lub EXECUTE.

Znaczenie rozdziału poziomu instancji i bazy podczas serwisu

Nieprawidłowa interpretacja sys.server_principals i sys.database_principals może prowadzić do błędnej diagnozy problemu z logowaniem, wyborem bazy albo dostępem do obiektów. W praktyce trzeba odróżnić błąd uwierzytelnienia od błędu autoryzacji. Pierwszy dotyczy rozpoznania logowania przez instancję, drugi praw dostępu w konkretnej bazie. Diagnostyka powinna również uwzględniać nazwę instancji, aktualną bazę, typ uwierzytelniania oraz fakt, że konto może być poprawnie zdefiniowane na jednym poziomie, lecz nie mieć oczekiwanego odpowiednika na drugim.

Przy pracy z komputerem, na którym lokalnie działa SQL Server, analizę warto prowadzić na kopii informacji konfiguracyjnych i z zachowaniem ostrożności przy zmianach kont oraz uprawnień. Usunięcie użytkownika, logowania lub roli może wpłynąć na działanie aplikacji, dlatego przed modyfikacją należy ustalić zależności i wykonać dokumentację stanu wyjściowego. W przypadku problemów z usługą, połączeniem z bazą albo działaniem programu można sprawdzić konfigurację klienta, nazwę serwera, komunikaty SQL Server i wyniki zapytań katalogowych. Naprawa sprzętu komputerowego nie zastępuje prawidłowej administracji uprawnieniami, ale sprawny laptop lub komputer PC jest podstawą wykonania takiej diagnostyki.