Widok sys.server_role_members

sys.server_role_members zawiera przypisania logowań do ról zdefiniowanych na poziomie serwera.

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

Widok sys.server_role_members w Microsoft SQL Server przedstawia członkostwo w stałych oraz niestandardowych rolach zdefiniowanych na poziomie całej instancji. Każdy rekord opisuje powiązanie pomiędzy podmiotem będącym członkiem roli a samą rolą. W praktyce można dzięki temu ustalić, które logowanie albo inny podmiot bezpieczeństwa otrzymuje uprawnienia wynikające z przynależności do określonej roli serwerowej.

Wynik widoku nie jest zwykłą listą samych nazw. Zawiera identyfikatory podmiotów, które można połączyć z katalogowymi widokami systemowymi, aby odczytać nazwy logowań i ról. Najczęściej wykorzystywane kolumny to role_principal_id oraz member_principal_id. Pierwsza wskazuje principal roli, a druga principal członka. Oba identyfikatory odnoszą się do obiektów opisanych w sys.server_principals.

Ważne jest rozróżnienie pomiędzy poziomem serwera i poziomem konkretnej bazy danych. sys.server_role_members dotyczy członkostwa w rolach serwerowych, natomiast podobny mechanizm dla ról bazodanowych można analizować przez sys.database_role_members. Pomylenie tych widoków prowadzi do błędnych wniosków, zwłaszcza podczas przeglądu uprawnień użytkownika, który ma inne uprawnienia na poziomie instancji, a inne wewnątrz wybranej bazy.

sys.server_role_members w kontekście bezpieczeństwa i porównań

Role serwerowe działają jak grupy uprawnień. Zamiast nadawać pojedynczemu logowaniu wiele uprawnień osobno, można przypisać je do roli, a następnie dodać logowanie jako członka tej roli. Takie podejście ułatwia zarządzanie, ale wymaga regularnego sprawdzania, czy członkostwo nadal odpowiada rzeczywistym obowiązkom danej osoby lub konta technicznego.

Podstawowe zapytanie może wyglądać następująco:

SELECT
    r.name AS server_role,
    m.name AS member_name,
    m.type_desc AS member_type
FROM sys.server_role_members AS srm
JOIN sys.server_principals AS r
    ON r.principal_id = srm.role_principal_id
JOIN sys.server_principals AS m
    ON m.principal_id = srm.member_principal_id
ORDER BY r.name, m.name;

Takie połączenie jest czytelniejsze niż odczyt samych identyfikatorów. W raporcie można zobaczyć nazwę roli, nazwę członka oraz typ podmiotu, na przykład logowanie SQL, konto systemu Windows albo grupa. Warto pamiętać, że jeden członek może występować w wielu rolach, a jedna rola może mieć wielu członków. Wynik nie musi więc zawierać unikatowych nazw, jeśli analizowane są pełne relacje członkostwa.

Widok można porównać do tabeli łącznikowej w modelu relacyjnym. Nie przechowuje kompletnego opisu uprawnień, lecz pokazuje relację pomiędzy dwoma rodzajami principal. Aby ustalić pełny zakres dostępu, trzeba dodatkowo przeanalizować uprawnienia ról, uprawnienia nadane bezpośrednio oraz członkostwa pośrednie. Sama obecność w jednym wierszu nie zawsze oznacza, że dostęp wynika tylko z tego jednego przypisania.

Typowe problemy przy analizie sys.server_role_members

Jednym z częstych problemów jest interpretowanie principal_id jako nazwy. Identyfikator ma znaczenie dopiero po odnalezieniu odpowiadającego mu rekordu w sys.server_principals. Nie powinno się również zakładać, że identyfikator będzie stały po usunięciu i ponownym utworzeniu obiektu. Przy automatyzacji raportów bezpieczniej jest opierać prezentację na nazwach oraz typach obiektów, a identyfikatory traktować jako klucze bieżącej konfiguracji.

Inna trudność wynika z różnicy pomiędzy uprawnieniami nadanymi bezpośrednio a uprawnieniami odziedziczonymi przez rolę. Logowanie może mieć uprawnienie przydzielone wprost, należeć do jednej lub kilku ról serwerowych, a także otrzymywać dostęp przez grupę. Dlatego zapytanie do sys.server_role_members powinno być elementem szerszego przeglądu, jeśli celem jest ustalenie rzeczywistego poziomu dostępu.

Warto także uważać na konta wyłączone, nieużywane oraz obiekty pozostawione po zmianie organizacji pracy. Sam wpis w widoku nie informuje, czy logowanie jest aktualnie wykorzystywane, czy ma ustawioną możliwość połączenia ani z jakiej aplikacji korzysta. Do takiej oceny potrzebne są dodatkowe informacje z katalogu logowań, konfiguracji uwierzytelniania oraz dokumentacji środowiska.

Podczas wykonywania zapytań mogą wystąpić ograniczenia widoczności metadanych. Zakres prezentowanych informacji zależy od uprawnień osoby wykonującej zapytanie. Brak wiersza nie zawsze dowodzi, że relacja nie istnieje w całej instancji; może oznaczać, że bieżący kontekst nie pozwala na pełny odczyt metadanych. Raport powinien więc zawierać informację o koncie użytym do analizy oraz o zakresie danych, który rzeczywiście został odczytany.

Praktyczne wskazówki dotyczące sys.server_role_members

Przegląd członkostwa najlepiej wykonywać według stałego schematu. Najpierw należy pobrać listę ról i członków wraz z nazwami. Następnie warto pogrupować wynik według roli, aby szybko wychwycić role o dużej liczbie członków oraz nietypowe przypisania. Kolejny krok powinien obejmować porównanie z aktualną listą osób, aplikacji i procesów, które mają uzasadniony dostęp.

• Łączyć sys.server_role_members z sys.server_principals, aby zastąpić identyfikatory nazwami.
• Rozdzielać analizę ról serwerowych od analizy ról bazodanowych.
• Zapisywać datę wykonania raportu oraz konto, z którego uruchomiono zapytanie.
• Sprawdzać również członkostwa grup, ponieważ dostęp może być dziedziczony pośrednio.
• Porównywać bieżący stan z zatwierdzoną dokumentacją, a nie tylko z poprzednim eksportem.
• Ostrożnie traktować role o szerokim zakresie działania i dodatkowo potwierdzać ich uzasadnienie.

Przydatne jest przygotowanie dwóch raportów: technicznego i zrozumiałego dla osoby odpowiedzialnej za dostęp. Raport techniczny może zawierać identyfikatory, typy principal oraz polecenia kontrolne. Raport opisowy powinien wskazywać nazwę członka, nazwę roli, źródło dostępu i decyzję, czy przypisanie ma pozostać aktywne. Taki podział ogranicza ryzyko, że istotna informacja zostanie przeoczona z powodu zbyt szczegółowej prezentacji.

W razie problemów z działaniem komputera używanego do przygotowania lub odczytu raportów można skorzystać z pomocy firmy Warszawskie Pogotowie Komputerowe 24/7. Wsparcie może obejmować sprawdzenie sprzętu oraz środowiska pracy, bez zastępowania właściwej analizy uprawnień wykonanej przez osobę odpowiedzialną za bezpieczeństwo.

Kiedy sprawdzić sys.server_role_members i zgłosić problem

Analizę tego widoku warto przeprowadzić po utworzeniu nowego logowania, zmianie zakresu obowiązków, przejęciu istniejącej instancji, migracji konfiguracji albo zakończeniu współpracy z osobą lub dostawcą. Jest szczególnie przydatna wtedy, gdy pojawia się pytanie, dlaczego dane konto może wykonać operację, której nie powinno wykonywać, albo dlaczego aplikacja utraciła dostęp po zmianie konfiguracji.

Do serwisu sprzętowego warto zgłosić się wtedy, gdy problem z odczytem, eksportem lub archiwizacją raportu wynika z niestabilnego laptopa, uszkodzonego dysku, błędów systemu albo problemów z urządzeniami peryferyjnymi. W przypadku samego członkostwa w rolach należy natomiast rozpocząć od bezpiecznego zapytania kontrolnego, ustalenia kontekstu połączenia i porównania wyniku z dokumentacją. Zmiany w uprawnieniach powinny być wykonywane dopiero po potwierdzeniu właściciela systemu i wpływu na działające aplikacje.

Jeżeli wynik sys.server_role_members nie zgadza się z oczekiwaniami, należy zachować kopię zapytania, datę obserwacji oraz pełny kontekst problemu. Przydatne będą także informacje o tym, czy dostęp wynika z roli, grupy, uprawnienia bezpośredniego lub innej konfiguracji. Tak przygotowane dane ułatwiają rozdzielenie problemu technicznego od problemu administracyjnego i pozwalają szybciej ustalić właściwe dalsze działanie.