Zarządzanie użytkownikami w SSMS

Zarządzanie użytkownikami w SSMS odbywa się z poziomu Object Explorer, w folderze Security danej bazy.

Użytkownik bazy danych a logowanie do SQL Server

Zarządzanie użytkownikami w SQL Server Management Studio (SSMS) rozpoczyna się w Object Explorerze od rozwinięcia instancji, wybrania konkretnej bazy danych, a następnie otwarcia folderu Security. W tym miejscu znajduje się folder Users, który zawiera użytkowników przypisanych do danej bazy. Użytkownik bazy danych nie jest tym samym obiektem co login instancji SQL Server. Login służy do uwierzytelnienia na poziomie instancji, natomiast użytkownik określa dostęp do konkretnej bazy danych.

Jeden login może mieć użytkownika w kilku bazach, przy czym w każdej bazie użytkownik może otrzymać inny zestaw uprawnień. SQL Server rozróżnia logowania SQL Server, oparte na nazwie i haśle przechowywanym przez silnik, oraz logowania Windows, wykorzystujące konto użytkownika lub grupę systemu Windows. W przypadku grupy Windows uprawnienia można nadawać użytkownikowi reprezentującemu całą grupę, bez tworzenia osobnej konfiguracji dla każdego jej członka.

Tworzenie i konfiguracja użytkowników w SSMS

Aby utworzyć użytkownika w graficznym interfejsie SSMS, należy kliknąć prawym przyciskiem folder Users w wybranej bazie i wybrać polecenie New User. W oknie konfiguracji wskazuje się typ użytkownika, nazwę użytkownika bazy oraz login, z którym użytkownik ma być powiązany. Dla użytkownika mapowanego na istniejący login wybiera się właściwe konto w polu Login name. Nazwa użytkownika w bazie może być taka sama jak nazwa loginu, ale nie jest to wymagane.

Konfigurację można również wykonać za pomocą języka Transact-SQL. Przykładowe polecenie tworzy użytkownika bazy danych powiązanego z istniejącym loginem:

CREATE USER [Analityk] FOR LOGIN [AnalitykLogin];

Jeżeli konto ma być używane tylko w określonej bazie, login można utworzyć na poziomie instancji, a następnie zmapować go na użytkownika w tej bazie. Przykładowo polecenie CREATE LOGIN [AnalitykLogin] WITH PASSWORD = 'HasloTymczasowe_2026!'; tworzy login SQL Server, natomiast polecenie CREATE USER [Analityk] FOR LOGIN [AnalitykLogin]; tworzy odpowiadający mu obiekt bazodanowy. Hasło powinno być ustalane zgodnie z zasadami obowiązującymi w danym środowisku i nie powinno być umieszczane bezpośrednio w skryptach przechowywanych w repozytoriach lub dziennikach.

Role, schematy i nadawanie uprawnień

Najczęściej uprawnienia użytkownikom nadaje się przez role bazodanowe. W folderze Security znajduje się podfolder Database Roles, w którym można sprawdzić role istniejące w bazie, między innymi db_datareader, db_datawriter oraz db_owner. Rola db_datareader pozwala odczytywać dane ze wszystkich tabel i widoków użytkownika, a db_datawriter pozwala modyfikować dane w tabelach i widokach użytkownika. Członkostwo w db_owner daje pełną kontrolę nad bazą, dlatego powinno być ograniczone do kont, które rzeczywiście muszą wykonywać operacje administracyjne.

Dodanie użytkownika do roli można wykonać w SSMS przez właściwości roli i zakładkę Members albo poleceniem T-SQL:

ALTER ROLE [db_datareader] ADD MEMBER [Analityk];

Dokładniejsze uprawnienia można nadawać bezpośrednio do obiektów. Przykład GRANT SELECT ON OBJECT::[dbo].[Raporty] TO [Analityk]; przyznaje odczyt wskazanej tabeli lub innemu obiektowi obsługiwanemu przez daną składnię. Polecenie DENY SELECT ON OBJECT::[dbo].[Raporty] TO [Analityk]; jawnie odmawia uprawnienia, a REVOKE SELECT ON OBJECT::[dbo].[Raporty] FROM [Analityk]; usuwa wcześniej nadane uprawnienie lub odmowę z tego poziomu. W praktyce warto nadawać dostęp przez role utworzone dla określonych funkcji, ponieważ ułatwia to późniejsze przeglądanie i zmianę uprawnień.

Schemat, taki jak dbo, jest przestrzenią nazw dla obiektów bazy i może również służyć do zarządzania uprawnieniami. Użytkownik może mieć domyślny schemat, ale nie oznacza to automatycznego dostępu do wszystkich obiektów znajdujących się w tym schemacie. Dostęp wynika z członkostwa w rolach oraz z poleceń GRANT, DENY i REVOKE zastosowanych do użytkownika, roli, schematu lub obiektu.

Kontrola dostępu i bezpieczna obsługa kont w SSMS

Podczas przeglądania użytkownika w SSMS należy sprawdzić jego mapowanie do loginu, członkostwo w rolach oraz uprawnienia nadane bezpośrednio. Właściwości użytkownika pozwalają przejść do członkostwa w rolach i uprawnień, natomiast pełny obraz często wymaga także sprawdzenia uprawnień odziedziczonych przez role. Samo usunięcie użytkownika z jednej roli nie musi odebrać mu dostępu, jeżeli to samo uprawnienie otrzymuje z innej roli albo z uprawnienia nadanego bezpośrednio.

Usunięcie użytkownika z bazy wykonuje się w SSMS przez polecenie Delete albo za pomocą DROP USER [Analityk];. Operacja ta usuwa użytkownika z bieżącej bazy, ale nie usuwa odpowiadającego loginu z instancji. Login można usunąć osobno poleceniem DROP LOGIN [AnalitykLogin];, o ile nie jest już potrzebny i nie blokują go zależności. Przed usunięciem należy sprawdzić, czy użytkownik nie jest właścicielem schematu, obiektów lub innych elementów bazy, ponieważ takie zależności mogą uniemożliwić operację albo wymagać wcześniejszego przeniesienia własności.

Do sprawdzenia bieżącego użytkownika i jego kontekstu można użyć zapytań SELECT SUSER_SNAME() AS LoginName, USER_NAME() AS DatabaseUser; oraz SELECT name, type_desc, authentication_type_desc FROM sys.database_principals;. Widoki katalogowe sys.database_principals, sys.database_role_members i sys.database_permissions dostarczają informacji odpowiednio o użytkownikach i rolach, członkostwie w rolach oraz jawnych uprawnieniach. Takie sprawdzenie pomaga odróżnić problem z logowaniem do instancji od problemu z autoryzacją w konkretnej bazie.