Uprawnienia Windows w SQL Server

Uprawnienia Windows w SQL Server dziedziczą przynależność do grup domenowych, upraszczając zarządzanie dostępem.

Model uwierzytelniania Windows w SQL Server

Uprawnienia Windows w SQL Server są związane z uwierzytelnianiem Windows oraz kontami i grupami zarządzanymi przez system Windows lub usługę Active Directory. Użytkownik loguje się do systemu przy użyciu konta domenowego albo lokalnego, a SQL Server rozpoznaje jego tożsamość na podstawie zabezpieczeń Windows. W tym modelu hasło użytkownika nie jest przekazywane do silnika SQL Server jako osobny zestaw danych logowania. Połączenie korzysta z biletu lub tokenu uwierzytelniającego wystawionego przez mechanizmy systemu Windows.

SQL Server odróżnia login serwerowy od użytkownika bazy danych. Login jest obiektem na poziomie instancji i umożliwia rozpoczęcie sesji, natomiast użytkownik bazy danych reprezentuje ten login w konkretnej bazie. Dla konta Windows login może mieć postać DOMENA\użytkownik, a dla grupy domenowej DOMENA\GrupaSQL. Utworzenie loginu nie oznacza automatycznego dostępu do wszystkich baz ani do wszystkich obiektów. Dostęp należy nadać na odpowiednich poziomach, zgodnie z rzeczywistym zakresem wymaganych operacji.

Dziedziczenie dostępu przez grupy domenowe

Grupa Windows może zostać dodana do SQL Server jako jeden login, na przykład za pomocą polecenia CREATE LOGIN [DOMENA\GrupaSQL] FROM WINDOWS;. Następnie w wybranej bazie danych tworzy się użytkownika powiązanego z tym loginem, przykładowo poleceniem CREATE USER [DOMENA\GrupaSQL] FOR LOGIN [DOMENA\GrupaSQL];. Uprawnienia można przyznać temu użytkownikowi albo dodać go do roli bazodanowej. W efekcie członkowie grupy otrzymują dostęp wynikający z przynależności do grupy, bez konieczności tworzenia odrębnych reguł dla każdej osoby.

Przy ocenie uprawnień SQL Server uwzględnia token bezpieczeństwa użytkownika, w którym znajdują się między innymi identyfikator konta oraz identyfikatory grup, do których konto należy. Zmiana członkostwa w grupie może wymagać ponownego logowania, aby nowy token został użyty przy tworzeniu sesji. Samo usunięcie konta z grupy nie musi natychmiast zakończyć już ustanowionych połączeń. Dlatego przy zmianach dostępu należy sprawdzać zarówno konfigurację grupy, jak i aktywne sesje oraz sposób ponownego uwierzytelnienia.

Role, uprawnienia i kolejność ich oceny

Uprawnienia w SQL Server mogą dotyczyć serwera, bazy danych, schematu albo pojedynczego obiektu, takiego jak tabela, widok, procedura składowana czy funkcja. Na poziomie serwera stosuje się między innymi stałe role serwerowe, a w bazie danych role bazodanowe i role niestandardowe. Przykładowo członkostwo w roli może zapewnić prawo do odczytu danych, podczas gdy bezpośrednie nadanie uprawnienia SELECT ogranicza dostęp do wskazanych obiektów. W praktyce bezpieczniejszy model polega na nadawaniu uprawnień grupom i rolom zamiast pojedynczym kontom.

SQL Server rozróżnia uprawnienia GRANT, DENY i REVOKE. GRANT zezwala na wykonanie określonej operacji, DENY jawnie jej zabrania, a REVOKE usuwa wcześniej nadane zezwolenie lub zakaz z danego poziomu. Przy analizie wyniku trzeba uwzględnić wszystkie role oraz grupy, do których należy użytkownik. Szczególne znaczenie ma zakaz DENY, który w wielu przypadkach ma pierwszeństwo przed odziedziczonym GRANT; wyjątki dotyczą między innymi właścicieli obiektów i członków ról o najwyższym poziomie uprawnień. Nie należy więc oceniać dostępu wyłącznie na podstawie jednej instrukcji nadania uprawnienia.

Przykładowa konfiguracja może obejmować utworzenie roli bazodanowej, dodanie do niej użytkownika grupowego oraz nadanie roli prawa do odczytu. Taki układ rozdziela tożsamość Windows od modelu uprawnień aplikacyjnych. Ułatwia też audyt: można ustalić, czy dostęp wynika z bezpośredniego przypisania, członkostwa w roli bazodanowej, członkostwa w grupie domenowej czy z uprawnień odziedziczonych przez schemat. Przy diagnostyce należy sprawdzić także domyślną bazę logowania, mapowanie loginu na użytkownika oraz zgodność identyfikatorów zabezpieczeń po odtworzeniu bazy na innej instancji.

Diagnostyka odmowy dostępu w SQL Server

Odmowa dostępu może wynikać z kilku różnych przyczyn: brakującego loginu na instancji, braku użytkownika w konkretnej bazie, nieprawidłowego członkostwa w grupie Windows, braku uprawnienia do obiektu albo użycia niewłaściwego kontekstu bazy. Pierwszym krokiem jest ustalenie konta używanego przez aplikację lub narzędzie oraz bazy, do której faktycznie kierowane jest połączenie. Pomocne są funkcje SUSER_SNAME(), zwracająca nazwę loginu serwerowego, oraz USER_NAME(), zwracająca nazwę użytkownika w bieżącej bazie.

Do sprawdzenia członkostwa w rolach można wykorzystać między innymi IS_ROLEMEMBER(), a do weryfikacji konkretnego uprawnienia funkcję HAS_PERMS_BY_NAME(). Wynik takiego testu trzeba interpretować w kontekście aktualnej sesji, ponieważ połączenie może używać innego konta niż konto osoby wykonującej diagnostykę. Należy również sprawdzić, czy login Windows jest widoczny na poziomie instancji i czy użytkownik istnieje w bazie, na przykład w katalogach systemowych sys.server_principals oraz sys.database_principals. Sam fakt obecności konta w Active Directory nie tworzy jeszcze uprawnień w SQL Server.

Przy analizie problemu trzeba odróżnić błąd uwierzytelniania od błędu autoryzacji. Uwierzytelnianie oznacza potwierdzenie tożsamości, natomiast autoryzacja określa, jakie działania ta tożsamość może wykonać. Jeżeli login nie może rozpocząć sesji, problem występuje przed sprawdzeniem praw do tabeli lub procedury. Jeżeli sesja zostaje ustanowiona, ale operacja kończy się komunikatem o braku uprawnień, należy przeanalizować mapowanie użytkownika, role, dziedziczenie oraz ewentualne zakazy DENY. Takie rozdzielenie skraca diagnostykę i ogranicza ryzyko nadania zbyt szerokiego dostępu.