GRANT / DENY / REVOKE to trzy podstawowe instrukcje Transact-SQL zarządzające nadawaniem, odmową i odbieraniem uprawnień.
Trzy instrukcje T-SQL i ich role w modelu uprawnień
GRANT, DENY i REVOKE są instrukcjami języka Transact-SQL używanymi w Microsoft SQL Server do zarządzania uprawnieniami. GRANT nadaje wskazanemu podmiotowi określone uprawnienie do zabezpieczanego zasobu, czyli securable. DENY jawnie odmawia tego uprawnienia, natomiast REVOKE usuwa wcześniej zapisane nadanie albo odmowę. REVOKE nie oznacza automatycznie przyznania dostępu: po jego wykonaniu SQL Server ponownie wylicza uprawnienia wynikające z innych ról, grup i poziomów dziedziczenia.
Instrukcje odnoszą się do principal, czyli podmiotów bezpieczeństwa. Może nim być między innymi login na poziomie instancji, użytkownik bazy danych, rola bazy danych albo grupa Windows. Uprawnienia można nadawać do różnych securables: całej bazy danych, schematu, tabeli, widoku, procedury składowanej lub pojedynczej kolumny. Przykładowo użytkownik może otrzymać SELECT na tabeli, EXECUTE na procedurze albo ALTER na schemacie.
Zakres zabezpieczanego zasobu i składnia poleceń
Podstawowa składnia w SQL Server ma postać GRANT permission ON securable TO principal, DENY permission ON securable TO principal albo REVOKE permission ON securable FROM principal. Dla obiektu można więc nadać odczyt tabeli poleceniem GRANT SELECT ON OBJECT::dbo.Orders TO ReportingUser. Prefiks OBJECT:: jednoznacznie wskazuje, że chodzi o obiekt, a nie o inny typ securable. W praktyce warto podawać schemat, ponieważ sama nazwa obiektu może być niejednoznaczna albo zależeć od domyślnego schematu użytkownika.
Uprawnienia mogą być nadawane na poziomie bazy danych, schematu lub konkretnego obiektu. Przykładowo GRANT SELECT ON SCHEMA::raporty TO Analitycy obejmuje obiekty należące do wskazanego schematu zgodnie z regułami hierarchii uprawnień. SQL Server rozróżnia uprawnienia obejmujące możliwość wykonania operacji od uprawnień dotyczących zarządzania innymi zabezpieczeniami. CONTROL jest uprawnieniem szerokim, a SELECT, INSERT, UPDATE i DELETE dotyczą operacji na danych. Przy uprawnieniu UPDATE można również wskazać wybrane kolumny, jeżeli dostęp ma być węższy niż aktualizowanie całej tabeli.
Dziedziczenie, role i rozstrzyganie konfliktów
SQL Server buduje efektywny zestaw uprawnień z wielu źródeł. Znaczenie mają bezpośrednie wpisy dla użytkownika, członkostwo w rolach bazodanowych, członkostwo w grupach Windows, uprawnienia odziedziczone z nadrzędnego poziomu oraz uprawnienia właściciela lub administratora. Z tego powodu samo wyszukanie jednego polecenia GRANT w skrypcie nie wystarcza do ustalenia, czy dana operacja rzeczywiście będzie dozwolona.
DENY jest jawną odmową, ale w SQL Server występują istotne wyjątki. Odmowa na poziomie obiektu może zostać pominięta w przypadku członkostwa w roli sysadmin. Uprawnienia właściciela obiektu i niektóre uprawnienia wynikające z hierarchii również wpływają na wynik oceny. Szczególnej ostrożności wymaga odmowa nadana grupie Windows, gdy ten sam użytkownik należy do wielu grup lub ról. Zamiast budować skomplikowane kombinacje indywidualnych wyjątków, zwykle czytelniejszy jest model oparty na rolach: rola otrzymuje minimalny zestaw potrzebnych uprawnień, a użytkownicy są do niej dołączani lub usuwani.
REVOKE działa inaczej niż cofnięcie wszystkich możliwości użytkownika. Usunięcie bezpośredniego GRANT może pozostawić dostęp odziedziczony z roli. Usunięcie DENY może z kolei odsłonić wcześniejsze nadanie z innego źródła. Przy analizie należy więc sprawdzić nie tylko definicje użytkowników, lecz także członkostwa w rolach, grupy systemu Windows, właścicieli obiektów oraz hierarchię securables. Do obserwacji efektywnych uprawnień można wykorzystać funkcje metadanych, takie jak HAS_PERMS_BY_NAME, a listę wpisów zabezpieczeń analizować między innymi w widokach katalogowych sys.database_permissions i sys.database_principals.
Kontrola dostępu do danych w praktycznym środowisku SQL Server
W środowisku Microsoft SQL Server poprawne użycie GRANT, DENY i REVOKE wymaga najpierw ustalenia, jaki proces wykonuje operację i z jakiego principal korzysta. Błąd „The SELECT permission was denied” może oznaczać brak uprawnienia do tabeli, ale także próbę odwołania do obiektu przez widok, procedurę albo inny schemat. Z kolei błąd „The EXECUTE permission was denied” dotyczy uruchomienia modułu, a niekoniecznie odczytu tabel, do których moduł się odwołuje.
Podczas diagnostyki należy rozdzielić trzy kwestie: istnienie obiektu, tożsamość użytkownika oraz efektywny zestaw uprawnień. Weryfikuje się nazwę bazy, schemat, członkostwo w rolach i wpisy w katalogu zabezpieczeń. Należy również sprawdzić, czy aplikacja nie korzysta z innego loginu niż zakładano oraz czy polecenie nie jest wykonywane w innej bazie. W przypadku procedur składowanych znaczenie może mieć ownership chaining, czyli mechanizm pozwalający na przejście przez obiektów o tym samym właścicielu bez bezpośredniego nadawania użytkownikowi uprawnień do tabel bazowych. Zmiana właściciela, schematu albo sposobu wywołania procedury może zatem zmienić zachowanie dostępu.
Przy naprawie problemu należy nadać wyłącznie uprawnienie wymagane przez konkretną operację. Bezpośredni GRANT CONTROL lub szeroki dostęp do całej bazy może usunąć objaw, ale jednocześnie stworzyć nieuzasadnione możliwości modyfikowania danych i obiektów. Bezpieczniejsza analiza polega na odtworzeniu błędu, ustaleniu brakującego securable, sprawdzeniu konfliktujących wpisów DENY oraz zweryfikowaniu wyniku po zmianie. Diagnostyka i naprawa komputera, na którym działa narzędzie administracyjne SQL Server, może obejmować sprawdzenie konfiguracji klienta, połączenia, właściwej instancji i zapisanych danych uwierzytelniających, bez utożsamiania problemu lokalnego programu z samą logiką uprawnień silnika.
