REVOKE

REVOKE to polecenie SQL cofające wcześniej przyznane uprawnienie, bez jego jawnej odmowy.

REVOKE jako cofnięcie uprawnienia w bazie danych

REVOKE jest instrukcją języka SQL używaną do odebrania wcześniej przyznanego dostępu do określonego zasobu. Może dotyczyć całej bazy, tabeli, widoku, procedury, funkcji albo innego obiektu obsługiwanego przez konkretny system zarządzania bazą danych. Sens tej operacji polega na usunięciu uprawnienia nadanego wcześniej za pomocą GRANT. Nie tworzy się w ten sposób osobnego zakazu, lecz usuwa się określone pozwolenie z zestawu praw przypisanych użytkownikowi lub grupie.

Przykładowo, jeżeli użytkownik otrzymał prawo odczytu tabeli, można je później cofnąć poleceniem:

REVOKE SELECT ON klienci FROM analityk;

Po wykonaniu takiej instrukcji użytkownik analityk nie powinien już korzystać z prawa SELECT do tabeli klienci, o ile dostęp nie wynika z innego źródła. Właśnie ten ostatni warunek ma duże znaczenie podczas analizy uprawnień. Odebranie prawa nadanego bezpośrednio nie zawsze oznacza całkowitą utratę dostępu, ponieważ identyczne uprawnienie może być odziedziczone z roli, grupy lub innego mechanizmu kontroli dostępu.

Instrukcja REVOKE nie usuwa danych i nie kasuje obiektu, którego dotyczy. Zmienia wyłącznie zasady dostępu. Dzięki temu może zostać wykorzystana podczas porządkowania kont, kończenia współpracy z użytkownikiem, ograniczania zakresu obowiązków albo reagowania na zmianę sposobu pracy z danymi. W praktyce polecenie powinno być wykonywane ze świadomością zależności między uprawnieniami bezpośrednimi i dziedziczonymi.

REVOKE na tle GRANT, DENY i ról

Najłatwiej zrozumieć REVOKE przez porównanie go z innymi mechanizmami kontroli dostępu. GRANT nadaje uprawnienie, natomiast REVOKE usuwa wcześniej przyznane uprawnienie. Obie instrukcje opisują stan pozwoleń, ale działają w przeciwnych kierunkach. Przykładowy ciąg operacji może wyglądać następująco:

GRANT SELECT ON zamowienia TO raporty;
REVOKE SELECT ON zamowienia FROM raporty;

Po pierwszym poleceniu rola raporty otrzymuje możliwość odczytu danych. Po drugim ta możliwość zostaje cofnięta z poziomu, na którym została nadana. Samo REVOKE nie musi jednak zablokować odczytu, jeżeli użytkownik należy równocześnie do innej roli posiadającej SELECT albo ma przyznane uprawnienie bezpośrednio.

W niektórych systemach występuje także DENY, czyli jawne zablokowanie operacji. Różnica między DENY a REVOKE jest istotna. REVOKE usuwa określone nadanie i pozostawia ocenę innych źródeł dostępu regułom danego systemu. DENY może natomiast wymusić odmowę nawet wtedy, gdy dostęp wynika z członkostwa w roli. Nie każdy silnik SQL obsługuje DENY w takim samym znaczeniu, dlatego składnię i kolejność rozstrzygania reguł trzeba sprawdzać w dokumentacji używanego rozwiązania.

W systemach opartych na rolach zwykle bardziej przejrzyste jest zarządzanie uprawnieniami przez grupy niż nadawanie ich osobno każdej osobie. REVOKE może wtedy odebrać użytkownikowi członkostwo w roli albo usunąć konkretne prawo z roli. Należy ustalić, czy cofane uprawnienie zostało przypisane użytkownikowi, roli, grupie czy obiektowi nadrzędnemu. Bez takiego rozpoznania może dojść do pozornego cofnięcia dostępu, po którym operacja nadal będzie możliwa.

REVOKE i typowe problemy z dziedziczeniem uprawnień

Najczęstszym problemem przy stosowaniu REVOKE jest założenie, że jedno polecenie opisuje pełny stan dostępu użytkownika. W rzeczywistości uprawnienia mogą pochodzić z kilku poziomów. Konto może mieć prawo nadane bezpośrednio, należeć do roli z szerszym zakresem dostępu, a dodatkowo korzystać z uprawnień odziedziczonych po grupie. Cofnięcie jednego wpisu nie musi więc zmienić końcowego wyniku kontroli dostępu.

Warto również rozróżnić odebranie prawa od odebrania prawa z możliwością dalszego przekazywania. W niektórych implementacjach uprawnienie może być nadane z opcją pozwalającą przekazać je innemu użytkownikowi. Późniejsze REVOKE może dotyczyć samego prawa, prawa do jego przekazywania albo obu elementów. Konkretne zachowanie zależy od silnika SQL, dlatego przy bardziej złożonych strukturach trzeba sprawdzić dokumentację oraz historię nadawania uprawnień.

Inny problem pojawia się wtedy, gdy cofnięcie uprawnienia zostanie wykonane na niewłaściwym obiekcie. Tabela, widok i procedura mogą mieć podobne nazwy, ale stanowić odrębne zasoby. Podobnie prawo SELECT dla tabeli nie jest tym samym co możliwość uruchomienia procedury, która odczytuje dane wewnątrz własnego kodu. Przed zmianą należy ustalić dokładny typ obiektu, jego właściciela oraz konto, którego dotyczy operacja.

Konsekwencje błędnie użytego REVOKE mogą być dwojakie. Zbyt szerokie cofnięcie dostępu może przerwać raportowanie, działanie aplikacji albo wykonywanie zadań administracyjnych. Zbyt wąskie cofnięcie pozostawi niepożądany dostęp i stworzy fałszywe poczucie bezpieczeństwa. Z tego powodu przydatne jest wcześniejsze odtworzenie efektywnych uprawnień oraz wykonanie testu na koncie o takim samym zestawie ról.

REVOKE w praktyce: bezpieczne planowanie zmian

Przed wykonaniem polecenia powinno się ustalić cel zmiany w prostym, jednoznacznym opisie. Inaczej planuje się odebranie odczytu pojedynczej tabeli, inaczej usunięcie możliwości modyfikowania danych, a jeszcze inaczej całkowite wyłączenie użytkownika z określonej roli. Takie rozdzielenie pomaga dobrać właściwy obiekt, typ uprawnienia i zakres operacji.

Przydatne jest zapisanie aktualnego stanu uprawnień przed zmianą. Należy uwzględnić nie tylko polecenia GRANT, lecz także członkostwo w rolach, uprawnienia odziedziczone oraz ustawienia dotyczące właściciela obiektu. Zachowanie informacji o stanie wyjściowym ułatwia późniejszą kontrolę, wyjaśnienie skutków i ewentualne odtworzenie dostępu, jeżeli okaże się potrzebny.

W środowisku testowym można sprawdzić kilka scenariuszy: dostęp użytkownika przed cofnięciem, dostęp bezpośrednio po REVOKE oraz dostęp po ponownym zalogowaniu. Ponowne uwierzytelnienie bywa ważne, ponieważ niektóre aplikacje utrzymują aktywną sesję, token albo połączenie z wcześniej ustalonym kontekstem uprawnień. Wynik testu należy oceniać na konkretnych operacjach, takich jak odczyt, dodanie rekordu, modyfikacja i usunięcie.

Składnia instrukcji może różnić się między PostgreSQL, Oracle Database, Microsoft SQL Server, MySQL i innymi systemami. Różnice dotyczą między innymi obsługi ról, opcji CASCADE lub RESTRICT, uprawnień do procedur oraz sposobu przeliczania dziedziczenia. Nie powinno się bezpośrednio przenosić polecenia z jednego silnika do drugiego bez sprawdzenia jego znaczenia. W razie wątpliwości bezpieczniej jest użyć dokumentacji właściwej dla konkretnej wersji oprogramowania i wykonać próbę na kopii testowej.

Po zmianie warto przejrzeć logi i potwierdzić, że aplikacje korzystające z bazy nadal wykonują przewidziane operacje. Jeżeli cofnięcie dotyczy dostępu do informacji poufnych, należy także sprawdzić, czy nie istnieje alternatywna ścieżka dostępu przez widok, procedurę, kopię danych lub inne konto techniczne. REVOKE jest pojedynczą operacją administracyjną, natomiast skuteczna kontrola dostępu wymaga spojrzenia na cały model uprawnień.

REVOKE a zgłoszenie problemu z dostępem do danych

Do serwisu warto zgłosić się wtedy, gdy po wykonaniu REVOKE występują niejasne komunikaty o braku uprawnień, aplikacja przestaje działać albo użytkownik nadal uzyskuje dostęp mimo cofnięcia prawa. Pomocne będzie przygotowanie nazwy używanego systemu bazodanowego, wersji oprogramowania, nazwy konta, obiektu oraz dokładnej operacji, która kończy się odmową lub nadal pozostaje dostępna. Nie należy przekazywać haseł ani pełnych kopii poufnych danych.

W takich przypadkach można przeanalizować konfigurację, zależności między rolami i sposób, w jaki aplikacja łączy się z bazą. Warszawskie Pogotowie Komputerowe 24/7 zajmuje się diagnostyką problemów komputerowych i może pomóc uporządkować przyczynę nieprawidłowego dostępu, o ile dostęp do systemu i zakres prac zostaną wcześniej uzgodnione. Przed zmianami w konfiguracji należy wykonać kopię ustawień oraz ustalić, które konta powinny zachować dostęp.

Jeżeli błąd pojawił się po odebraniu uprawnienia, nie powinno się od razu przywracać szerokiego dostępu wszystkim użytkownikom. Najpierw należy ustalić, jaka operacja jest rzeczywiście wymagana, czy problem dotyczy konta, roli, obiektu lub sesji oraz czy nie występuje drugi mechanizm ograniczający dostęp. Takie podejście pozwala ograniczyć zakres zmian i zachować kontrolę nad tym, kto może odczytywać albo modyfikować określone dane.