Widok sys.database_permissions

sys.database_permissions zawiera listę uprawnień przyznanych w obrębie konkretnej bazy danych.

Widok sys.database_permissions — czym jest i co opisuje

Widok sys.database_permissions jest katalogiem uprawnień obowiązujących w obrębie konkretnej bazy danych Microsoft SQL Server. Pozwala sprawdzić, jakie prawa zostały przyznane, odebrane albo zablokowane dla użytkowników, ról oraz innych podmiotów bezpieczeństwa. Dzięki temu można przeanalizować nie tylko samą listę kont, lecz także sposób, w jaki zbudowano model dostępu do obiektów i funkcji bazy.

Każdy wiersz widoku opisuje pojedynczą regułę bezpieczeństwa. Najważniejsze informacje znajdują się między innymi w kolumnach grantee_principal_id, grantor_principal_id, permission_name, state, state_desc, class, class_desc oraz major_id. Identyfikatory podmiotów można powiązać z widokiem sys.database_principals, a identyfikatory obiektów z sys.objects, sys.schemas albo katalogami właściwymi dla danego typu zasobu.

Warto pamiętać, że widok dotyczy poziomu bazy danych. Nie jest pełnym zestawieniem wszystkich mechanizmów bezpieczeństwa występujących w instancji. Uprawnienia logowania, członkostwo w rolach na poziomie instancji oraz niektóre ustawienia dostępu należy analizować w innych katalogach systemowych. sys.database_permissions pokazuje przede wszystkim jawnie zapisane delegacje i ograniczenia, dlatego sam odczyt tego widoku nie zawsze odpowiada końcowemu poziomowi dostępu konkretnego użytkownika.

sys.database_permissions w kontekście klas i zakresów uprawnień

Interpretacja danych zależy od kolumny class. Wiersz może odnosić się do całej bazy, schematu, obiektu, kolumny, typu, roli aplikacyjnej lub innego elementu chronionego przez mechanizm uprawnień. Kolumna class_desc ułatwia odczyt bez konieczności pamiętania wartości liczbowych. Z kolei major_id zwykle wskazuje główny identyfikator elementu, którego dotyczy reguła. Dla uprawnienia obejmującego bazę lub schemat sposób interpretacji identyfikatora może być inny niż dla tabeli lub procedury.

Znaczenie ma także stan uprawnienia. Wartość opisana jako GRANT oznacza przyznanie prawa, DENY wskazuje jawne zablokowanie, a REVOKE najczęściej oznacza usunięcie wcześniejszego przyznania lub odmowy w określonym zakresie. W katalogu można spotkać również warianty związane z dziedziczeniem i kolumnami, dlatego w raportach lepiej korzystać z state_desc niż przedstawiać użytkownikowi same pojedyncze litery.

Uprawnienia mogą być nadawane bezpośrednio użytkownikowi albo roli. W drugim przypadku trzeba ustalić członkostwo w rolach za pomocą sys.database_role_members, a następnie połączyć identyfikatory z sys.database_principals. Różnica między widokiem uprawnień a rzeczywistą możliwością wykonania operacji wynika z hierarchii praw, dziedziczenia, członkostwa w wielu rolach oraz istnienia uprawnień nadrzędnych. Przykładowo prawo obejmujące cały schemat może wpływać na dostęp do wielu obiektów, nawet jeśli dla poszczególnych tabel nie występują osobne wiersze.

Przy porównywaniu z innymi źródłami należy rozdzielić trzy pojęcia: uprawnienie zapisane jawnie, uprawnienie odziedziczone oraz uprawnienie wynikające z przynależności do uprzywilejowanej roli. sys.database_permissions jest szczególnie przydatny do analizy pierwszej grupy, natomiast pełny audyt wymaga połączenia kilku widoków katalogowych i sprawdzenia kontekstu wykonania.

Widok sys.database_permissions a typowe problemy diagnostyczne

Jednym z częstych problemów jest przekonanie, że brak wiersza dla użytkownika oznacza brak jakiegokolwiek dostępu. Użytkownik może jednak dziedziczyć prawa z roli albo otrzymywać je przez uprawnienie nadane wyżej w hierarchii. Odwrotna sytuacja również jest możliwa: pojedynczy wpis DENY może ograniczać działanie pomimo obecności kilku wpisów GRANT. Dlatego samo wyszukanie nazwy konta nie wystarcza do wyciągnięcia pewnego wniosku.

Innym źródłem nieporozumień są identyfikatory. Wartość grantee_principal_id nie jest nazwą użytkownika, lecz identyfikatorem z katalogu bazy. Bez połączenia z sys.database_principals raport staje się mało czytelny. Podobnie major_id nie powinno być prezentowane jako nazwa obiektu bez sprawdzenia klasy uprawnienia. Ten sam typ identyfikatora może oznaczać tabelę, procedurę, schemat albo inny element zależnie od wartości class.

Problematyczne bywają również uprawnienia kolumnowe. Jeżeli prawo dotyczy wybranych kolumn, należy uwzględnić sys.database_permissions razem z minor_id oraz katalogiem kolumn. Pominięcie tego pola może prowadzić do błędnego stwierdzenia, że użytkownik ma dostęp do całej tabeli. W analizie należy rozważyć także uprawnienia do wykonywania procedur, używania obiektów, odczytu danych oraz modyfikowania danych, ponieważ każde z nich może być reprezentowane osobnym wpisem.

Nie należy usuwać wpisów katalogowych ręcznie. Są one wynikiem poleceń bezpieczeństwa, takich jak GRANT, DENY i REVOKE. Bezpieczniejsze jest ustalenie źródła reguły, zapisanie stanu wyjściowego, wykonanie kontrolowanej zmiany i ponowne odczytanie widoków systemowych. Dzięki temu można uniknąć sytuacji, w której poprawa jednego dostępu nieoczekiwanie rozszerza prawa innej grupy.

sys.database_permissions — praktyczne zapytania i dobre nawyki

Podstawowy raport powinien łączyć nazwę podmiotu, nazwę uprawnienia oraz opis klasy. Przykładowy schemat zapytania może wyglądać następująco:

• SELECT dp.state_desc, dp.permission_name, dp.class_desc, pr.name AS principal_name FROM sys.database_permissions AS dp JOIN sys.database_principals AS pr ON pr.principal_id = dp.grantee_principal_id;

Takie zapytanie jest dobrym punktem wyjścia, lecz nie pokazuje jeszcze nazwy zabezpieczanego obiektu. W kolejnym kroku można dodać połączenie z sys.objects, pamiętając o filtrowaniu według klasy i identyfikatora. Przy raportach obejmujących wiele baz danych trzeba wykonywać zapytanie w kontekście każdej z nich, ponieważ widoki sys opisują bieżącą bazę, a identyfikatory nie powinny być bezkrytycznie porównywane między różnymi bazami.

Dobrym zwyczajem jest tworzenie raportów rozdzielających uprawnienia użytkowników od uprawnień ról. Należy także oznaczać konta nieaktywne, role niestandardowe oraz reguły o szerokim zasięgu. Warto przechowywać cykliczne zestawienia, aby wykrywać nowe wpisy, nagłe usunięcia i zmiany stanu. Samo porównanie tekstowych nazw nie zawsze wystarcza, ponieważ zmiana właściciela, schematu albo członkostwa w roli może zmienić efekt końcowy bez modyfikacji konkretnego wiersza w analizowanym widoku.

Podczas diagnostyki należy testować dostęp w odpowiednim kontekście użytkownika. Odczyt katalogu przez konto administracyjne nie odpowiada automatycznie temu, co zobaczy zwykły użytkownik, ponieważ widoczność metadanych może być ograniczona. Wyniki warto potwierdzić próbą operacji, która ma być dozwolona lub zablokowana, oraz przeanalizować komunikat błędu bez ujawniania zbędnych danych.

Kiedy sprawdzić widok sys.database_permissions w serwisie

Analiza tego widoku jest przydatna, gdy po zmianie użytkownika, roli albo aplikacji pojawia się odmowa dostępu, nieoczekiwana możliwość odczytu lub problem z wykonaniem procedury. Warto sięgnąć po nią również wtedy, gdy dokumentacja uprawnień jest nieaktualna, występują konta o podobnych nazwach albo konieczne jest przygotowanie uporządkowanego audytu konfiguracji bazy danych. Szczególnej uwagi wymagają wpisy nadane bezpośrednio użytkownikom, szerokie uprawnienia schematów oraz kombinacje GRANT i DENY pochodzące z różnych ról.

Jeżeli interpretacja katalogów systemowych jest niejasna, można skorzystać z pomocy Warszawskiego Pogotowia Komputerowego 24/7 przy uporządkowaniu diagnostyki i przygotowaniu czytelnego opisu problemu. Przed analizą warto zebrać nazwę bazy, nazwę użytkownika, oczekiwaną operację, komunikat błędu oraz moment wystąpienia problemu. Tak przygotowane informacje ułatwiają odróżnienie błędnego wpisu w sys.database_permissions od problemu z członkostwem w roli, nazwą obiektu, kontekstem bazy lub innym elementem konfiguracji.

Najważniejsza zasada brzmi: widok powinien być traktowany jako jeden z elementów większego obrazu bezpieczeństwa. Dopiero połączenie jego danych z katalogiem podmiotów, członkostwem w rolach, obiektami i testem rzeczywistej operacji pozwala wiarygodnie ustalić, kto ma dostęp, do czego ten dostęp prowadzi oraz które uprawnienie odpowiada za obserwowane zachowanie.