Widok sys.server_permissions

sys.server_permissions zwraca listę uprawnień przyznanych na poziomie całej instancji.

Widok sys.server_permissions w systemie uprawnień

Widok sys.server_permissions służy do odczytywania uprawnień obowiązujących na poziomie całej instancji Microsoft SQL Server. Jest to katalog przydzielonych zezwoleń, w którym można sprawdzić, jaki podmiot otrzymał dane uprawnienie, jaki jest jego zakres oraz czy zostało ono przyznane bezpośrednio, czy wynika z członkostwa w określonej roli. Dzięki temu widokowi możliwe jest uporządkowanie informacji o kontroli dostępu bez przeglądania każdego konta osobno.

Wyniki zwracane przez sys.server_permissions opisują między innymi uprawnienia dotyczące logowania, zarządzania rolami, konfiguracji instancji, połączeń z bazami oraz innych elementów dostępnych ponad pojedynczą bazą danych. Widok nie jest jednak kompletną historią zmian zabezpieczeń. Pokazuje stan zapisany w bieżącej instancji, natomiast informacja o tym, kiedy i przez kogo wykonano modyfikację, wymaga użycia audytu, śledzenia zmian albo dzienników administracyjnych.

W praktyce warto odróżnić sam fakt obecności wpisu od jego skutku. Uprawnienie może być przyznane, odebrane albo oznaczone jako odmowa. Poszczególne rekordy są interpretowane w połączeniu z innymi zasadami dziedziczenia. Ostateczny dostęp konkretnego logowania może zależeć od uprawnień przypisanych bezpośrednio, członkostwa w rolach serwerowych, członkostwa w rolach bazodanowych oraz reguł obowiązujących wewnątrz konkretnej bazy.

sys.server_permissions a role i zakres kontroli

Najważniejszym kontekstem dla tego widoku jest rozróżnienie pomiędzy podmiotem a chronionym obiektem. Podmiotem może być logowanie lub rola serwerowa, natomiast chronionym elementem może być cała instancja, określona klasa obiektów albo pojedynczy obiekt należący do szerszej kategorii. Kolumny widoku wskazują rodzaj podmiotu, identyfikator podmiotu, klasę zabezpieczanego elementu, identyfikator obiektu, nazwę uprawnienia oraz stan wpisu.

Stan uprawnienia ma znaczenie przy analizie konfliktów. Przyznanie uprawnienia jest zwykle oznaczane jako GRANT, odmowa jako DENY, a przyznanie z możliwością dalszego przekazania jako GRANT_WITH_GRANT_OPTION. Odmowa nie oznacza jednak, że każdy możliwy dostęp zostanie zablokowany w identyczny sposób, ponieważ zachowanie zależy od klasy uprawnienia oraz miejsca, w którym dana reguła została zastosowana. Z tego powodu pojedynczy rekord nie powinien być interpretowany bez sprawdzenia całej ścieżki członkostwa i dziedziczenia.

Warto również pamiętać, że sys.server_permissions nie zastępuje widoków dotyczących ról. Jeśli analiza ma odpowiedzieć na pytanie, dlaczego dane logowanie posiada określone uprawnienie, trzeba zestawić dane z sys.server_principals oraz informacjami o członkostwie w rolach. Same przydziały widoczne w sys.server_permissions mogą nie wyjaśnić pełnego obrazu, zwłaszcza gdy dostęp uzyskano pośrednio.

Inny zakres mają widoki uprawnień dostępne w kontekście konkretnej bazy. Widoki takie jak sys.database_permissions opisują reguły obowiązujące wewnątrz wybranej bazy, a nie na całej instancji. Porównanie obu poziomów pozwala ustalić, czy problem wynika z konfiguracji globalnej, z członkostwa w roli, czy z ustawień obiektu bazodanowego.

Typowe problemy przy odczycie sys.server_permissions

Jednym z częstszych problemów jest traktowanie pustego wyniku jako dowodu, że dane logowanie nie ma żadnego dostępu. Brak bezpośredniego wpisu nie musi oznaczać braku uprawnień. Dostęp może pochodzić z roli, z uprawnień odziedziczonych albo z szerszego poziomu zabezpieczeń. Przed wyciągnięciem wniosku trzeba więc sprawdzić podmiot, jego role oraz aktywny kontekst połączenia.

Inny błąd polega na pomijaniu kolumny określającej stan uprawnienia. Rekord oznaczony jako odmowa ma inne znaczenie niż rekord oznaczony jako przyznanie. W raportach kontrolnych dobrze jest przedstawiać zarówno nazwę uprawnienia, jak i jego stan, typ podmiotu oraz nazwę chronionego obiektu. Sam identyfikator nie zawsze jest czytelny dla osoby wykonującej przegląd konfiguracji.

Problemy może powodować także użycie niewłaściwego kontekstu. Widoki systemowe są dostępne zgodnie z uprawnieniami osoby wykonującej zapytanie, a zakres widocznych informacji może być ograniczony przez model bezpieczeństwa. Jeżeli jeden administrator widzi mniej danych niż inny, przyczyną nie musi być różnica w konfiguracji. Różnica może wynikać z poziomu uprawnień użytego konta diagnostycznego.

Podczas porządkowania konfiguracji nie powinno się usuwać wpisów wyłącznie na podstawie ich nazwy. Najpierw należy ustalić, jaki proces lub użytkownik korzysta z danego uprawnienia, czy jest ono nadal potrzebne i czy może zostać zastąpione węższym zakresem. Nadmierne uprawnienia zwiększają ryzyko niezamierzonych zmian, ale zbyt pochopne odebranie dostępu może przerwać działanie aplikacji lub zadania administracyjnego.

Zapytania i praktyczne wskazówki dla sys.server_permissions

Przy analizie widoku zaleca się rozpoczęcie od zapytania zwracającego podstawowe kolumny, a następnie uzupełnienie identyfikatorów nazwami podmiotów i obiektów. Przykładowy schemat może wyglądać następująco:

SELECT
    sp.name AS principal_name,
    sp.type_desc AS principal_type,
    perm.class_desc,
    perm.permission_name,
    perm.state_desc
FROM sys.server_permissions AS perm
LEFT JOIN sys.server_principals AS sp
    ON perm.grantee_principal_id = sp.principal_id
ORDER BY sp.name, perm.permission_name;

Takie zestawienie ułatwia szybkie wykrycie przydziałów bezpośrednich, lecz powinno być traktowane jako punkt wyjścia. W większym środowisku warto dodać informacje o nazwie obiektu, jeżeli dana klasa uprawnienia korzysta z identyfikatora obiektu. Przydatne bywa też filtrowanie wyników według podmiotu, stanu albo określonego typu uprawnienia. Raport powinien jasno wskazywać, czy prezentuje wyłącznie wpisy bezpośrednie, czy również wnioski wynikające z członkostwa w rolach.

W ramach przeglądu bezpieczeństwa dobrze jest wykonywać cykliczne porównania. Zapisanie wyniku zapytania w kontrolowanym repozytorium pozwala wykryć nowe przydziały, odebrane uprawnienia i zmiany stanu. Należy przy tym chronić sam raport, ponieważ może zawierać informacje o strukturze zabezpieczeń. Dostęp do takich zestawień powinien być ograniczony do osób, które zajmują się administracją i kontrolą dostępu.

Bezpieczniejsza konfiguracja zwykle opiera się na zasadzie najmniejszych uprawnień. Oznacza to przydzielanie tylko takiego zakresu, jaki jest potrzebny do wykonania konkretnego zadania. Warto preferować role o jasno opisanym przeznaczeniu, ograniczać uprawnienia przydzielane bezpośrednio oraz regularnie usuwać nieużywane konta i członkostwa. Każda zmiana powinna być poprzedzona sprawdzeniem zależności, a następnie zweryfikowana na koncie o możliwie wąskim zakresie.

Kiedy zgłosić się z problemem dotyczącym sys.server_permissions

Pomoc specjalisty może być potrzebna wtedy, gdy nie można ustalić, skąd wynika dostęp mimo przeanalizowania wpisów, ról i reguł bazodanowych. Warto również rozważyć konsultację, gdy po zmianie uprawnień pojawiają się odmowy połączenia, błędy wykonywania poleceń albo różnice w zachowaniu poszczególnych kont. Przed modyfikacją zabezpieczeń dobrze jest przygotować nazwę logowania, treść komunikatu, moment wystąpienia problemu oraz informację, czy trudność dotyczy jednego użytkownika, czy większej grupy.

Pomoc techniczna może obejmować uporządkowanie odczytu widoków systemowych, rozdzielenie uprawnień instancji od uprawnień bazodanowych, sprawdzenie członkostwa w rolach i przygotowanie czytelnego raportu zmian. W przypadku problemów ze sprzętem, na którym wykonywane są narzędzia administracyjne, wsparcia udziela Warszawskie Pogotowie Komputerowe 24/7. Przed przekazaniem urządzenia zaleca się zabezpieczyć kopie danych, zanotować objawy i nie usuwać samodzielnie plików konfiguracyjnych potrzebnych do dalszej diagnozy.

Najważniejsza zasada pozostaje prosta: wpisy z sys.server_permissions należy analizować razem z podmiotami, rolami, stanem uprawnienia i zakresem obiektu. Dopiero takie zestawienie pozwala odróżnić rzeczywiste przydzielenie dostępu od uprawnień odziedziczonych oraz bezpiecznie zaplanować zmianę konfiguracji.