Widok sys.login_token

sys.login_token zwraca listę grup i uprawnień powiązanych z bieżącym loginem.

Token jako zestaw tożsamości bieżącego połączenia

Silnik bazy nie sprawdza uprawnień wyłącznie po nazwie loginu. Przy nawiązaniu sesji buduje zbiór wszystkich tożsamości, które ta sesja ze sobą niesie: sam login, role serwerowe, do których należy, oraz — przy uwierzytelnianiu zintegrowanym — grupy systemu Windows, w których znajduje się konto użytkownika. Omawiany widok pokazuje właśnie ten zbiór dla trwającego połączenia. Każdy wiersz ma nazwę, identyfikator zabezpieczeń, typ oraz informację, czy dana pozycja może przyznawać uprawnienia, czy służy wyłącznie do ich odbierania.

Poziom serwera kontra poziom bazy

Odpowiednikiem działającym w kontekście konkretnej bazy danych jest widok sys.user_token, zwracający użytkownika bazy oraz role bazodanowe. Rozdział ten wynika wprost z modelu zabezpieczeń: login pozwala połączyć się z instancją, użytkownik bazy decyduje o dostępie do jej obiektów, a między jednym a drugim istnieje mapowanie, które potrafi się rozjechać. Klasycznym objawem takiego rozjazdu jest osierocony użytkownik po przeniesieniu bazy na inny serwer — konto istnieje w bazie, login o tej samej nazwie istnieje na instancji, ale identyfikatory zabezpieczeń się nie zgadzają i połączenie kończy się odmową dostępu. Zestawienie obu widoków natychmiast to pokazuje. Warto też pamiętać, że po wykonaniu polecenia EXECUTE AS zawartość tokenu się zmienia i odzwierciedla przybraną tożsamość, a nie pierwotny login.

Dlaczego użytkownik ma dostęp, którego nikt mu nie nadał

Najczęstsza przyczyna to uprawnienie odziedziczone po grupie domenowej. Administrator przegląda listę loginów, nie znajduje tam nikogo podejrzanego i uznaje sprawę za zamkniętą, podczas gdy dostęp wynika z przynależności do grupy dodanej kiedyś do roli serwerowej. Drugi wariant odwrotny: użytkownik nie ma dostępu mimo widocznego nadania, bo w tokenie znajduje się pozycja oznaczona jako służąca wyłącznie do odmowy — a odmowa wygrywa z każdym przyznaniem. Trzecia pułapka to nieaktualność członkostwa: zmiana grup w domenie nie wpływa na trwającą sesję, więc do sprawdzenia efektu trzeba się rozłączyć i połączyć ponownie.

Diagnozowanie odmów dostępu w systemach handlowych

Zgłoszenia brzmią zwykle tak: jeden użytkownik nie może otworzyć modułu, choć ma te same ustawienia co kolega. Ustalamy wtedy, czy różnica leży w uprawnieniach programu, czy głębiej, na poziomie bazy, bo naprawianie nie tej warstwy potrafi zająć dzień bez efektu. Serwisujemy wdrożenia oprogramowania handlowego opartego o SQL Server, więc obie warstwy sprawdzamy równolegle.