DENY to instrukcja Transact-SQL jawnie odmawiająca użytkownikowi dostępu do wskazanego obiektu bazy danych.
DENY w modelu uprawnień Microsoft SQL Server
DENY jest instrukcją języka Transact-SQL używaną w Microsoft SQL Server do jawnego odebrania wskazanemu podmiotowi określonego uprawnienia. Podmiotem może być użytkownik bazy danych, rola bazy danych albo rola aplikacyjna. Odmowa może dotyczyć między innymi odczytu danych, modyfikowania danych, wykonywania procedury lub funkcji, tworzenia obiektów oraz dostępu do konkretnego schematu albo obiektu. Instrukcja nie usuwa użytkownika, roli ani obiektu i nie zmienia jego definicji. Zapisuje natomiast decyzję autoryzacyjną w metadanych zabezpieczeń bazy.
Przykładowe polecenie DENY SELECT ON OBJECT::dbo.Zamowienia TO Analitycy; odmawia roli Analitycy prawa odczytu obiektu dbo.Zamowienia. W tym zapisie SELECT jest uprawnieniem, OBJECT::dbo.Zamowienia wskazuje klasę i nazwę chronionego obiektu, a TO Analitycy określa odbiorcę odmowy. Skuteczność polecenia zależy od właściwego kontekstu bazy danych oraz od tego, czy nazwa obiektu i podmiotu odpowiadają istniejącym elementom w SQL Server.
Składnia odmowy dla obiektów i schematów
Zakres instrukcji DENY można dopasować do potrzeb kontroli dostępu. Odmowa na poziomie obiektu obejmuje wskazaną tabelę, widok, procedurę lub funkcję. Odmowa na poziomie schematu może objąć określone uprawnienie wobec wszystkich obiektów znajdujących się w danym schemacie, zgodnie z obsługiwaną klasą uprawnienia. Dla przykładu DENY EXECUTE ON SCHEMA::raporty TO Operatorzy; blokuje roli Operatorzy wykonywanie procedur i funkcji w schemacie raporty, jeżeli dana odmowa obejmuje taki zakres w konkretnej konfiguracji uprawnień.
SQL Server pozwala również stosować odmowy wobec kolumn tabeli. Polecenie DENY SELECT ON OBJECT::dbo.Pracownicy (Wynagrodzenie) TO Kierownicy; wskazuje kolumnę Wynagrodzenie, a nie całą tabelę. Taki zapis wymaga zachowania poprawnej składni i odpowiedniego uprawnienia obejmującego daną kolumnę. Przy analizie trzeba rozróżnić odmowę od nadania uprawnienia instrukcją GRANT oraz od przekazania uprawnienia innemu podmiotowi instrukcją GRANT z opcją WITH GRANT OPTION. DENY jest odrębnym wpisem w systemie autoryzacji, a nie modyfikacją samego obiektu.
Dziedziczenie, role i pierwszeństwo DENY
Uprawnienia w SQL Server są często nadawane rolom, a użytkownik dziedziczy uprawnienia przez członkostwo w tych rolach. Jeżeli użytkownik należy do roli otrzymującej GRANT SELECT, ale jednocześnie należy do innej roli otrzymującej DENY SELECT dla tego samego zakresu, odmowa co do zasady blokuje dostęp. Z tego powodu przy badaniu problemu z odczytem lub modyfikacją nie wystarczy sprawdzić pojedynczego użytkownika. Należy przeanalizować jego członkostwo w rolach bazodanowych, role aplikacyjne oraz uprawnienia nadane bezpośrednio.
DENY ma pierwszeństwo przed GRANT w typowym modelu rozstrzygania uprawnień, ale nie jest bezwzględne wobec wszystkich mechanizmów SQL Server. Odmowy nie stosuje się w taki sam sposób do właściciela zabezpieczanego obiektu ani do członków stałej roli serwera sysadmin, ponieważ te konteksty mają uprzywilejowany dostęp. Osobno należy uwzględnić właścicieli bazy, właścicieli obiektów oraz uprawnienia wynikające z innych ról serwerowych i bazodanowych. Przy diagnostyce warto sprawdzić rzeczywisty kontekst wykonania, na przykład za pomocą USER_NAME(), SUSER_SNAME() i IS_SRVROLEMEMBER('sysadmin'), a następnie użyć funkcji HAS_PERMS_BY_NAME do oceny konkretnego uprawnienia.
Wykrywanie nieoczekiwanej odmowy w SQL Server
Jeżeli aplikacja otrzymuje błąd braku dostępu po wykonaniu zapytania, należy najpierw ustalić dokładny obiekt, operację i konto używane przez połączenie. Komunikat o odmowie odczytu tabeli nie dowodzi jeszcze, że DENY został nadany bezpośrednio temu użytkownikowi. Przyczyną może być członkostwo w roli, odmowa na schemacie, odmowa dotycząca konkretnej kolumny albo wykonanie zapytania w innym kontekście bezpieczeństwa niż zakładany przez administratora. Pomocne są widoki katalogowe, w szczególności sys.database_permissions, sys.database_principals i sys.database_role_members.
Przykładowe zapytanie diagnostyczne może wyszukać wpisy dotyczące obiektu: SELECT dp.state_desc, dp.permission_name, dp.class_desc, dp.major_id, pr.name FROM sys.database_permissions AS dp JOIN sys.database_principals AS pr ON dp.grantee_principal_id = pr.principal_id WHERE dp.major_id = OBJECT_ID(N'dbo.Zamowienia');. Wynik trzeba interpretować razem z nazwą podmiotu i zakresem uprawnienia. Usunięcie odmowy wykonuje się instrukcją REVOKE, a nie przez nadanie przeciwnego GRANT; na przykład REVOKE SELECT ON OBJECT::dbo.Zamowienia FROM Analitycy; usuwa konkretny wpis odmowy dla roli. Przed zmianą należy potwierdzić, czy dostęp nie ma pozostać zablokowany z powodów projektowych i czy użytkownik nie otrzymuje tej samej odmowy z innego źródła.
