EXECUTE AS LOGIN to wariant tej klauzuli umożliwiający zmianę kontekstu wykonania na poziomie loginu instancji serwera.
Zakres działania EXECUTE AS LOGIN w SQL Server
EXECUTE AS LOGIN jest instrukcją języka Transact-SQL używaną w Microsoft SQL Server do czasowej zmiany kontekstu bezpieczeństwa na wskazany login zdefiniowany na poziomie instancji. Login jest principalem serwerowym, czyli obiektem rozpoznawanym przez całą instancję SQL Server, a nie tylko przez jedną bazę danych. Po wykonaniu instrukcji operacje realizowane w bieżącej sesji są oceniane tak, jakby wykonywał je wskazany login.
Przykładowa składnia ma postać EXECUTE AS LOGIN = 'NazwaLoginu';. Zmiana obejmuje między innymi rozpoznawanie uprawnień serwerowych oraz wynik funkcji takich jak SUSER_SNAME(), która zwraca nazwę aktualnego kontekstu loginu. Nie oznacza to jednak zalogowania nowego użytkownika do aplikacji ani utworzenia drugiego połączenia z serwerem. Jest to zmiana tożsamości używanej przez mechanizm autoryzacji wewnątrz istniejącej sesji.
Różnica między loginem a użytkownikiem bazy
W SQL Server login i użytkownik bazy danych są powiązanymi, ale odrębnymi pojęciami. Login istnieje na poziomie instancji i może być używany do uwierzytelnienia połączenia z serwerem. Użytkownik bazy danych reprezentuje dostęp tego loginu w konkretnej bazie. Z tego powodu EXECUTE AS LOGIN różni się od EXECUTE AS USER: pierwsza forma zmienia kontekst serwerowy, a druga dotyczy kontekstu użytkownika w bieżącej bazie danych.
Po zmianie kontekstu SQL Server może inaczej oceniać dostęp do obiektów i operacji wymagających uprawnień serwerowych. W bazie danych nadal istotne pozostaje mapowanie loginu na użytkownika oraz członkostwo w rolach bazodanowych. Samo wskazanie loginu nie nadaje mu automatycznie dodatkowych praw. Jeżeli wskazany login nie ma dostępu do konkretnej bazy, tabeli, widoku, procedury albo operacji administracyjnej, wykonanie polecenia nadal może zakończyć się błędem uprawnień.
Uprawnienia, zakres sesji i przywracanie kontekstu
Użycie EXECUTE AS LOGIN jest kontrolowane przez uprawnienia. Osoba wykonująca instrukcję musi mieć możliwość impersonacji, czyli działania w kontekście wskazanego loginu, albo posiadać uprawnienia administracyjne obejmujące taką operację. W praktyce należy zweryfikować między innymi uprawnienie IMPERSONATE nadane dla konkretnego loginu oraz członkostwo w odpowiednich rolach serwerowych. Brak wymaganych uprawnień powoduje odrzucenie instrukcji, zanim wykonywane polecenia uzyskają nowy kontekst.
Zmiana obowiązuje do chwili wykonania REVERT; albo do zakończenia zakresu, w którym kontekst został ustanowiony. Polecenie REVERT przywraca poprzednią tożsamość sesji. Do sprawdzenia bieżącego stanu można użyć między innymi SUSER_SNAME(), ORIGINAL_LOGIN() oraz USER_NAME(). Pierwsza funkcja pokazuje aktualny kontekst loginu, druga pierwotny login, który otworzył sesję, a trzecia nazwę użytkownika rozpoznawanego w bieżącej bazie. Porównanie tych wartości pomaga ustalić, czy kontekst został zmieniony i czy późniejsze operacje są wykonywane w oczekiwanym zakresie.
W kodzie wielokrotnie zmieniającym kontekst trzeba zachować kolejność operacji. Każde wykonanie EXECUTE AS może utworzyć kolejny poziom kontekstu, a zwykłe REVERT cofa zmianę o jeden poziom. Pominięcie przywrócenia kontekstu może sprawić, że dalsze polecenia w tej samej sesji będą działały z innymi uprawnieniami niż zakładano. Z tego względu diagnostyka powinna obejmować pełny przebieg partii T-SQL, procedury lub skryptu, a nie tylko pojedynczą instrukcję.
Bezpieczne sprawdzanie skutków wykonania
Przed zastosowaniem EXECUTE AS LOGIN warto ustalić, jakie operacje mają zostać zweryfikowane i w jakiej bazie będą wykonywane. Należy rozdzielić test rozpoznania loginu od testu dostępu do konkretnego obiektu. Sam prawidłowy wynik SUSER_SNAME() potwierdza zmianę kontekstu, ale nie potwierdza dostępu do tabeli, procedury, widoku ani polecenia administracyjnego. Weryfikacja powinna sprawdzać dokładnie te zasoby, których dotyczy badany kod.
Podczas analizy błędu przydatne jest zapisanie wartości ORIGINAL_LOGIN(), SUSER_SNAME() i DB_NAME() przed wykonaniem operacji oraz po zmianie kontekstu. Pozwala to odróżnić błąd uwierzytelnienia od błędu autoryzacji i wykryć sytuację, w której kod działa w innej bazie niż oczekiwana. Po zakończeniu testu należy wykonać REVERT; i ponownie sprawdzić aktualny login. Takie postępowanie ogranicza ryzyko przypadkowego wykonywania kolejnych poleceń z niezamierzonymi uprawnieniami.
Mechanizm jest przeznaczony do kontrolowanych scenariuszy administracyjnych, testów uprawnień i wykonywania kodu wymagającego jasno określonego kontekstu bezpieczeństwa. Nie powinien zastępować prawidłowego modelu ról i minimalnych uprawnień. Szczególną uwagę trzeba zwrócić na procedury wykonujące dynamiczny SQL, ponieważ zmiana kontekstu może wpływać na dostęp do obiektów używanych przez generowane zapytania. Błąd w zakresie lub brak instrukcji REVERT może prowadzić do nieprzewidywalnego zachowania całej sesji.
