Widok sys.database_principals

sys.database_principals zawiera listę użytkowników, ról i schematów zdefiniowanych w bazie.

Widok sys.database_principals – czym jest i do czego służy

Widok sys.database_principals należy do katalogu systemowego Microsoft SQL Server i przedstawia podmioty bezpieczeństwa zdefiniowane w konkretnej bazie danych. Obejmuje między innymi użytkowników bazodanowych, role, właściciela bazy oraz inne obiekty, które mogą otrzymywać uprawnienia. Jest to widok dostępny w kontekście pojedynczej bazy, dlatego wynik zależy od tego, do której bazy zostanie skierowane zapytanie. Samo użycie nazwy widoku bez zmiany kontekstu nie służy do przeglądania wszystkich baz jednocześnie.

W praktyce sys.database_principals jest jednym z podstawowych miejsc do sprawdzania, kto lub co może uczestniczyć w modelu uprawnień. Wiersz opisujący użytkownika nie oznacza jeszcze, że użytkownik ma dostęp do każdego obiektu. Widok pokazuje istnienie podmiotu w bazie, natomiast rzeczywisty zakres dostępu trzeba odczytywać razem z członkostwem w rolach, nadanymi uprawnieniami, odmowami oraz dziedziczeniem uprawnień. Dzięki temu można odróżnić samą obecność konta od faktycznych możliwości wykonywania operacji.

Wśród często analizowanych kolumn znajdują się name, principal_id, type, type_desc, authentication_type, default_schema_name, owning_principal_id oraz is_fixed_role. Nazwa identyfikuje podmiot w obrębie bazy, a identyfikator liczbowy pozwala łączyć dane z innymi widokami katalogowymi. Kolumny tekstowe opisujące typ są zwykle wygodniejsze podczas ręcznej diagnostyki, natomiast wartości kodowe mogą być przydatne w skryptach automatyzujących kontrolę konfiguracji.

sys.database_principals w kontekście technicznym i porównaniach

W modelu bezpieczeństwa SQL Server trzeba rozróżnić trzy poziomy: logowanie, użytkownika bazy oraz uprawnienia. Logowanie jest obiektem rozpoznawanym na poziomie instancji, użytkownik znajduje się w konkretnej bazie, a uprawnienia określają zakres dozwolonych operacji. sys.database_principals opisuje przede wszystkim drugi z tych poziomów. Jeżeli konto może połączyć się z instancją, ale nie ma odpowiadającego użytkownika w danej bazie, dostęp do jej obiektów może nie działać zgodnie z oczekiwaniem.

Do sprawdzania członkostwa użytkowników i ról stosuje się zwykle sys.database_role_members. Z kolei widoki sys.database_permissions oraz sys.objects pomagają ustalić, jakie uprawnienia zostały nadane i do których obiektów się odnoszą. Przy analizie schematów przydatne są również sys.schemas oraz kolumna default_schema_name. Każdy z tych widoków odpowiada na inne pytanie: sys.database_principals pokazuje podmioty, sys.database_role_members ich przynależność do ról, a sys.database_permissions konkretne reguły dostępu.

Warto odróżnić rolę stałą od roli utworzonej przez administratora. Informacja w is_fixed_role wskazuje, czy dana rola należy do wbudowanego zestawu ról bazodanowych. Role stałe mają z góry określone znaczenie, natomiast role niestandardowe mogą być projektowane pod konkretny zakres obowiązków. Z punktu widzenia audytu sama nazwa roli nie zawsze wystarcza, ponieważ jej członkowie oraz dodatkowe uprawnienia mogą zmieniać faktyczny poziom dostępu.

Znaczenie ma także typ uwierzytelniania. W zależności od konfiguracji można spotkać użytkowników powiązanych z logowaniem, użytkowników niezależnych od logowania, konta mapowane na certyfikat lub klucz oraz inne typy podmiotów. Dlatego filtrowanie wyłącznie po nazwie może pomijać ważne elementy konfiguracji. Bezpieczniejsza analiza uwzględnia jednocześnie type_desc, źródło uwierzytelniania, rolę i przypisany schemat domyślny.

Typowe problemy przy analizie sys.database_principals

Częstym problemem jest tak zwany osierocony użytkownik. Występuje on wtedy, gdy użytkownik istnieje w bazie, lecz jego powiązanie z odpowiednim logowaniem jest nieaktualne albo niezgodne z bieżącą konfiguracją. W widoku nadal może być widoczny poprawny wiersz, ale próba logowania lub uzyskania dostępu do obiektów kończy się odmową. Przy diagnozie należy więc porównywać dane katalogowe bazy z informacjami o logowaniach, a nie usuwać użytkownika bez sprawdzenia zależności.

Inny przypadek to użytkownik, który ma dostęp szerszy, niż wynikałoby to z jego bezpośrednich wpisów. Przyczyną może być członkostwo w roli, zagnieżdżenie ról albo uprawnienie nadane na wyższym poziomie. Odczyt samego sys.database_principals nie pokaże pełnej ścieżki dziedziczenia. Należy zestawić go z sys.database_role_members i sys.database_permissions, a następnie uwzględnić hierarchię obiektów, schematów i bazy.

Problemy powoduje również niejednoznaczne rozumienie kolumny default_schema_name. Schemat domyślny wpływa na sposób rozwiązywania nazw obiektów, lecz nie jest równoznaczny z pełnym zestawem uprawnień. Użytkownik może korzystać z obiektów w innych schematach, jeśli otrzymał odpowiednie uprawnienia. Zmiana schematu domyślnego nie powinna być traktowana jako metoda nadawania lub odbierania dostępu.

Podczas migracji bazy mogą pojawić się także duplikaty nazw, nieaktualne role i konta pozostałe po dawnych aplikacjach. Nie każda nieużywana pozycja powinna być od razu usuwana, ponieważ może być właścicielem obiektu albo elementem procedury wdrożeniowej. Przed zmianą warto ustalić właściciela, członków roli, zależne schematy i historię wykorzystania. Najbezpieczniejsza kolejność obejmuje inwentaryzację, potwierdzenie zakresu dostępu, przygotowanie kopii konfiguracji i dopiero późniejsze porządkowanie.

Praktyczne wskazówki dla widoku sys.database_principals

Podstawowe zapytanie diagnostyczne powinno zwracać nazwę, identyfikator, opis typu, schemat domyślny oraz informacje o uwierzytelnianiu. Przydatne jest sortowanie po type_desc i name, ponieważ ułatwia oddzielenie użytkowników, ról i pozostałych podmiotów. W środowisku testowym można rozpocząć od prostego odczytu, a następnie dodać filtry ograniczające wynik do wybranych typów lub nazw.

Przykładowy schemat zapytania może wyglądać następująco:

SELECT
    name,
    principal_id,
    type_desc,
    authentication_type_desc,
    default_schema_name,
    is_fixed_role
FROM sys.database_principals
ORDER BY type_desc, name;

Takiego wyniku nie należy interpretować w oderwaniu od bieżącej bazy. Przed wykonaniem analizy trzeba sprawdzić, czy kontekst jest właściwy, ponieważ identyczne zapytanie uruchomione w dwóch bazach może zwrócić zupełnie różne zestawy podmiotów. Przy automatyzacji warto unikać założeń opartych wyłącznie na identyfikatorach liczbowych, gdyż ich wartości mogą różnić się między bazami i środowiskami.

Dobrym zwyczajem jest przygotowanie raportu obejmującego trzy zestawienia: podmioty z sys.database_principals, członkostwo w rolach oraz uprawnienia. Taki układ ułatwia wykrycie kont bez przypisanej roli, ról bez członków, użytkowników z nietypowym schematem domyślnym i uprawnień przyznanych bezpośrednio. W razie potrzeby można także porównywać raporty z kolejnych dni lub wersji wdrożeniowych, aby wykryć nieplanowane zmiany.

Nie powinno się zmieniać wpisów katalogowych przez bezpośrednią modyfikację tabel systemowych. Zarządzanie podmiotami należy wykonywać za pomocą poleceń DDL przeznaczonych do tworzenia, zmiany, mapowania i usuwania użytkowników oraz ról. Przed wykonaniem operacji trzeba rozważyć zależności, skutki dla aplikacji i możliwość odtworzenia poprzedniej konfiguracji.

Kiedy zgłosić się z problemem widoku sys.database_principals

Pomoc techniczna jest uzasadniona wtedy, gdy problem z dostępem nie wynika z jednego oczywistego ustawienia, pojawia się po przeniesieniu bazy, dotyczy wielu użytkowników albo wymaga uporządkowania ról i uprawnień. Warto przygotować nazwę bazy, komunikat błędu, moment wystąpienia problemu oraz informację, czy zmieniano ostatnio logowania, role lub schematy. Takie dane skracają etap rozpoznania i ograniczają ryzyko przypadkowego odebrania potrzebnego dostępu.

W sprawach związanych z komputerem używanym do pracy z bazami można skorzystać z pomocy firmy Warszawskie Pogotowie Komputerowe 24/7. Przed przekazaniem urządzenia dobrze zabezpieczyć kopie zapasowe, zanotować sposób odtwarzania problemu i nie udostępniać haseł w treści zgłoszenia. Sama obecność wpisu w sys.database_principals nie przesądza jeszcze o przyczynie awarii, dlatego pełna ocena powinna obejmować także konfigurację połączenia, uprawnienia aplikacji, role oraz stan środowiska, w którym wykonywane są operacje.