Użytkownik bazy danych

Użytkownik bazy danych to tożsamość istniejąca w obrębie konkretnej bazy, powiązana z loginem na poziomie serwera.

Tożsamość użytkownika w obrębie bazy

Użytkownik bazy danych jest tożsamością zdefiniowaną wewnątrz konkretnej bazy. Nie jest tym samym co konto systemu operacyjnego ani samodzielny login rozpoznawany przez cały serwer. Taka tożsamość istnieje w określonym kontekście bazy i służy do przypisywania uprawnień do obiektów znajdujących się właśnie w tej bazie, między innymi tabel, widoków, procedur składowanych i funkcji.

W modelu, w którym występuje oddzielny login serwera, logowanie przebiega dwuetapowo. Najpierw silnik rozpoznaje login na poziomie instancji lub serwera. Następnie ustala, jaki użytkownik jest powiązany z tym loginem w wybranej bazie. Dopiero użytkownik bazy otrzymuje uprawnienia obowiązujące podczas wykonywania zapytań. Ten podział pozwala, aby jeden login miał dostęp do kilku baz, lecz w każdej z nich występował jako odrębny użytkownik z innym zestawem uprawnień.

Powiązanie loginu z użytkownikiem

Powiązanie między loginem a użytkownikiem bazy nie powinno być utożsamiane wyłącznie z identyczną nazwą. W silnikach stosujących taki model użytkownik ma własny identyfikator wewnętrzny, a login serwera ma osobny identyfikator. Podczas autoryzacji silnik korzysta z tego powiązania, aby określić tożsamość obowiązującą w bazie. Jeżeli użytkownik został utworzony bez poprawnego powiązania z loginem, logowanie może zakończyć się błędem mimo istnienia samego loginu.

Typowym problemem jest także tak zwany osierocony użytkownik. Powstaje on wtedy, gdy użytkownik pozostaje zapisany w bazie, ale odpowiadający mu login został usunięty, odtworzony albo przeniesiony z innym identyfikatorem. Nazwa może wyglądać prawidłowo, jednak mechanizm autoryzacji nie znajduje właściwego powiązania. Diagnoza takiego przypadku wymaga sprawdzenia zarówno katalogu użytkowników w bazie, jak i katalogu loginów na poziomie serwera. Samo utworzenie nowego konta o takiej samej nazwie nie zawsze przywraca wcześniejszą relację.

Role i uprawnienia przypisywane użytkownikowi

Użytkownik bazy zwykle nie otrzymuje wszystkich praw pojedynczo. Uprawnienia można nadawać bezpośrednio do obiektów albo przydzielać przez role bazodanowe. Rola jest zbiorem uprawnień, a członkostwo użytkownika w roli określa, jakie operacje może wykonywać. Przykładowe uprawnienia obejmują odczyt danych, modyfikowanie wierszy, uruchamianie procedury składowanej oraz tworzenie lub zmienianie obiektów. Zakres prawa powinien odpowiadać rzeczywistym operacjom wykonywanym przez aplikację lub operatora.

Ważne jest rozróżnienie między uprawnieniem do obiektu a uprawnieniem do określonej czynności. Dostęp do tabeli nie musi oznaczać możliwości usuwania danych, a możliwość wykonywania procedury składowanej nie musi oznaczać bezpośredniego dostępu do wszystkich tabel używanych przez tę procedurę. Przy analizie problemu należy sprawdzić członkostwo w rolach, uprawnienia dziedziczone oraz ewentualne odmowy dostępu. W wielu systemach odmowa ma pierwszeństwo przed przyznaniem prawa, dlatego wynik nie zawsze wynika z jednego polecenia nadania uprawnienia.

Oddzielne konta i role ułatwiają też kontrolę zmian. Jeżeli wiele aplikacji korzysta z jednego użytkownika, trudniej ustalić, która aplikacja wykonała daną operację i dlaczego wymagane było określone uprawnienie. Z kolei nadawanie każdemu kontu pełnych praw administracyjnych zwiększa zakres możliwych zmian i utrudnia wykrycie błędnej konfiguracji. Poprawny model powinien ograniczać uprawnienia do tych, które są niezbędne do wykonania zaplanowanych operacji.

Diagnostyka błędów dostępu do bazy

Komunikat o odmowie dostępu nie wskazuje automatycznie na uszkodzenie bazy. Najpierw trzeba ustalić, na którym etapie wystąpił problem: rozpoznawania loginu, wyboru bazy, mapowania loginu na użytkownika czy sprawdzania uprawnień do konkretnego obiektu. Inny charakter ma błąd informujący o nieistniejącym loginie, inny błąd wskazujący na brak użytkownika w bazie, a jeszcze inny odmowa wykonania operacji na tabeli lub procedurze.

Podczas diagnostyki warto odtworzyć dokładny scenariusz: używaną nazwę loginu, nazwę bazy, obiekt, na którym wykonano operację, oraz rodzaj żądanej czynności. Należy również sprawdzić, czy aplikacja nie korzysta z innego połączenia niż zakładane, na przykład z innej instancji, innej bazy domyślnej albo innego konta przechowywanego w konfiguracji. Zmiana nazwy użytkownika bez sprawdzenia identyfikatorów, ról i uprawnień może ukryć przyczynę zamiast ją usunąć. W środowisku serwerowym czynności diagnostyczne powinny być wykonywane przez osobę mającą odpowiedzialność za dany silnik i jego konfigurację.

Jeżeli problem pojawił się po odtworzeniu kopii bazy lub migracji, szczególną uwagę należy zwrócić na zgodność użytkowników z loginami istniejącymi na docelowym serwerze. Sama kopia obiektów bazodanowych nie musi zawierać odpowiadających im loginów serwera. Prawidłowa analiza powinna więc obejmować strukturę bazy, katalog kont, członkostwo w rolach i rzeczywisty ciąg połączenia używany przez aplikację.