Odbieranie uprawnień to cofnięcie wcześniej przyznanych praw poleceniem REVOKE lub ich jawna odmowa przez DENY.
Odebranie uprawnienia a jawna odmowa w SQL Server
Odbieranie uprawnień w Microsoft SQL Server polega na zmianie stanu zabezpieczeń przypisanych użytkownikowi, roli lub innemu podmiotowi zabezpieczeń. Do cofnięcia wcześniej nadanego prawa służy polecenie REVOKE. Przykładowo, REVOKE SELECT ON OBJECT::dbo.Raporty FROM Analityk; usuwa bezpośrednie nadanie uprawnienia do odczytu tabeli lub widoku. Po wykonaniu takiego polecenia użytkownik nie ma już tego prawa przyznanego bezpośrednio, ale dostęp może nadal wynikać z członkostwa w innej roli albo z uprawnienia odziedziczonego na wyższym poziomie.
Polecenie DENY ma inne znaczenie. Nie tylko usuwa określony sposób dostępu, lecz zapisuje jawną odmowę, na przykład DENY UPDATE ON OBJECT::dbo.Raporty TO Analityk;. W SQL Server odmowa zwykle ma pierwszeństwo przed uprawnieniem przyznanym użytkownikowi lub roli. Wyjątkiem są określone sytuacje związane z właścicielem obiektu oraz członkostwem w roli sysadmin, której członkowie nie są ograniczani przez typowe uprawnienia obiektowe. Z tego powodu REVOKE i DENY nie powinny być traktowane jako równoważne polecenia.
Hierarchia uprawnień i dziedziczenie dostępu
SQL Server organizuje uprawnienia hierarchicznie. Prawo może dotyczyć całej instancji, bazy danych, schematu albo konkretnego obiektu, takiego jak tabela, widok, procedura składowana lub funkcja. Uprawnienia mogą być również nadawane na poziomie kolumn. Przykład GRANT SELECT ON OBJECT::dbo.Klienci TO Operator; odnosi się do konkretnego obiektu, natomiast uprawnienie nadane do schematu może obejmować wiele obiektów należących do tego schematu. Cofnięcie prawa na jednym poziomie nie musi usunąć dostępu uzyskanego inną ścieżką.
W praktyce użytkownik często otrzymuje uprawnienia przez role bazodanowe. Jeżeli konto należy do roli Raportowanie, a ta rola ma prawo SELECT, wykonanie REVOKE SELECT ... FROM użytkownik nie odbierze dostępu wynikającego z roli. Trzeba sprawdzić zarówno bezpośrednie wpisy dotyczące użytkownika, jak i członkostwo w rolach. Pomocne są widoki katalogowe, między innymi sys.database_permissions, sys.database_principals oraz sys.database_role_members. Analiza powinna uwzględniać także uprawnienia do procedur, schematów i baz danych, ponieważ użytkownik może wykonywać operację pośrednio, bez bezpośredniego prawa do tabeli.
REVOKE, DENY i testowanie rzeczywistego efektu
Przed odebraniem uprawnień warto ustalić, czy celem jest usunięcie konkretnego nadania, czy trwałe zablokowanie operacji. REVOKE jest właściwe wtedy, gdy należy wycofać wcześniejsze GRANT i pozostawić możliwość uzyskania dostępu z innego, prawidłowego źródła. DENY stosuje się wtedy, gdy określona czynność ma być jawnie zakazana dla danego użytkownika lub roli. Nieprawidłowe użycie DENY może jednak zablokować dostęp wynikający z większej roli i spowodować błąd w aplikacji korzystającej z tej samej bazy danych.
Weryfikacja nie powinna ograniczać się do odczytania pojedynczego wpisu z widoku katalogowego. Stan uprawnień można sprawdzić dla konkretnego kontekstu za pomocą funkcji takich jak HAS_PERMS_BY_NAME, która zwraca informację o prawie do wskazanego zasobu. Należy również wykonać kontrolowaną próbę operacji, na przykład odczytu lub modyfikacji danych, używając konta o dokładnie takim samym członkostwie w rolach jak konto zgłaszające problem. Warto odnotować nazwę bazy, schemat, obiekt, użytkownika, rolę oraz moment zmiany, ponieważ pomylenie środowiska albo podobnie nazwanych baz często prowadzi do błędnej oceny skutku polecenia.
Rozpoznawanie problemów z dostępem po zmianie uprawnień
Błąd dostępu po wykonaniu REVOKE lub DENY może wynikać z kilku różnych przyczyn: prawa mogły zostać odebrane niewłaściwemu użytkownikowi, aplikacja może łączyć się innym kontem, a dostęp może być nadany przez rolę, schemat albo procedurę. Komunikat o braku uprawnienia trzeba zestawić z nazwą serwera, bazą danych, obiektem i rodzajem wykonywanej operacji. Szczególnej uwagi wymaga sytuacja, w której aplikacja używa konta technicznego, a ręczny test jest wykonywany na koncie administratora. Wynik takiego testu nie odzwierciedla rzeczywistych ograniczeń aplikacji.
Warszawskie Pogotowie Komputerowe wykonuje diagnostykę i naprawę laptopów oraz komputerów PC, w tym problemów z oprogramowaniem uruchamianym na tych urządzeniach. Przy analizie zgłoszenia dotyczącego odbierania uprawnień istotne jest zabezpieczenie informacji o konfiguracji, treści komunikatu błędu i sposobie logowania, bez pochopnego nadawania szerokich praw. Prawidłowa diagnoza powinna rozdzielić problem samej aplikacji od problemu konfiguracji konta w SQL Server oraz wskazać, czy przyczyną jest brak nadania, jawna odmowa, dziedziczenie z roli czy połączenie z niewłaściwym środowiskiem.
