Tworzenie użytkownika z logowania wiąże istniejące konto serwera z tożsamością w konkretnej bazie danych.
Login serwera a użytkownik bazy danych w SQL Server
W SQL Server login i użytkownik bazy danych są dwoma odrębnymi obiektami bezpieczeństwa. Login jest serwerowym podmiotem zabezpieczeń, który może uwierzytelnić się w instancji SQL Server. Użytkownik bazy danych jest natomiast podmiotem istniejącym w konkretnej bazie i otrzymuje tam uprawnienia do tabel, widoków, procedur, schematów lub innych obiektów. Samo utworzenie loginu nie daje automatycznie dostępu do każdej bazy danych znajdującej się na instancji.
Polecenie tworzenia użytkownika z logowania służy do powiązania istniejącego loginu z użytkownikiem w wybranej bazie. Typowa instrukcja w SQL Server ma postać CREATE USER [UzytkownikAplikacji] FOR LOGIN [LoginAplikacji];. Polecenie musi zostać wykonane w kontekście docelowej bazy danych, na przykład po użyciu instrukcji USE NazwaBazy;. W efekcie login może zostać rozpoznany jako określony użytkownik tej bazy, ale zakres jego działania nadal zależy od przyznanych uprawnień.
Jak SQL Server utrzymuje powiązanie obiektów
Podczas mapowania SQL Server wiąże użytkownika bazy danych z loginem serwerowym za pomocą identyfikatora zabezpieczeń SID. Nazwy obiektów mogą być różne, ponieważ nazwa loginu i nazwa użytkownika bazy nie muszą się zgadzać. Przykładowo login firma\operator może być powiązany z użytkownikiem OperatorRaportow. Tożsamość użytkownika jest lokalna dla danej bazy, dlatego ten sam login może mieć użytkownika o innej nazwie lub odmienny zakres uprawnień w kilku bazach.
Rozdzielenie loginu i użytkownika pozwala niezależnie zarządzać dostępem na poziomie instancji oraz na poziomie danych. Login może istnieć bez użytkownika w określonej bazie, a użytkownik może pozostać w bazie po usunięciu odpowiadającego mu loginu. Taki użytkownik jest wtedy określany jako osierocony, ponieważ jego SID nie wskazuje już na istniejący login serwerowy. W SQL Server można ponownie powiązać istniejącego użytkownika z loginem za pomocą instrukcji ALTER USER [OperatorRaportow] WITH LOGIN = [LoginAplikacji];, o ile wykonujący polecenie ma odpowiednie uprawnienia.
Uprawnienia po wykonaniu CREATE USER
Utworzenie użytkownika nie jest równoznaczne z nadaniem mu praw do wszystkich obiektów. Po wykonaniu CREATE USER należy ustalić, jakie operacje są potrzebne. Uprawnienia można przyznawać bezpośrednio, na przykład przez GRANT SELECT ON SCHEMA::raporty TO [OperatorRaportow];, albo pośrednio przez członkostwo w roli bazy danych. Przykładowe dodanie użytkownika do roli odbywa się poleceniem ALTER ROLE [db_datareader] ADD MEMBER [OperatorRaportow];. Rola db_datareader umożliwia odczyt danych ze wszystkich tabel i widoków użytkownika, dlatego jej użycie powinno odpowiadać rzeczywistemu zakresowi wymaganych operacji.
Przy konfiguracji dostępu trzeba odróżnić uprawnienia do połączenia z bazą od uprawnień do jej obiektów. Login może wymagać prawa CONNECT SQL na poziomie serwera, a użytkownik bazy prawa CONNECT w konkretnej bazie. Dostęp do tabeli, procedury lub widoku wymaga kolejnych uprawnień, takich jak SELECT, EXECUTE, INSERT, UPDATE albo DELETE. Nadanie użytkownikowi roli db_owner zapewnia bardzo szeroką kontrolę nad bazą i nie powinno być traktowane jako zamiennik precyzyjnej konfiguracji uprawnień.
Weryfikacja mapowania i typowych błędów
Przed utworzeniem użytkownika należy sprawdzić, czy login istnieje na instancji oraz czy w bazie nie ma już użytkownika o wybranej nazwie. Próba ponownego wykonania CREATE USER dla istniejącego użytkownika zakończy się błędem. Należy także upewnić się, że instrukcja jest uruchamiana w odpowiedniej bazie, ponieważ użytkownik utworzony w jednej bazie nie staje się automatycznie użytkownikiem innej. Dla loginów opartych na uwierzytelnianiu Windows trzeba stosować poprawną nazwę konta lub grupy, na przykład DOMENA\JanKowalski, natomiast login SQL Server wymaga nazwy utworzonej wcześniej za pomocą CREATE LOGIN.
Stan obiektów można kontrolować zapytaniami do widoków katalogowych. Widok sys.server_principals zawiera loginy i inne serwerowe podmioty zabezpieczeń, a sys.database_principals pokazuje użytkowników oraz role w bieżącej bazie. Porównanie kolumn sid pomaga wykryć brak zgodności między użytkownikiem a loginem. W praktyce warto również sprawdzić role użytkownika w sys.database_role_members oraz nadane uprawnienia w widokach takich jak sys.database_permissions. Jeżeli po mapowaniu występuje błąd odmowy dostępu, przyczyną może być brak właściwego GRANT, członkostwa w roli, prawa do schematu albo uprawnienia do samej bazy, a nie samo nieprawidłowe utworzenie użytkownika.
