Uprawnienia do serwera

Uprawnienia do serwera działają na poziomie całej instancji, niezależnie od poszczególnych baz danych.

Co oznaczają uprawnienia do serwera

Uprawnienia do serwera określają, jakie operacje może wykonywać konto użytkownika, konto usługi albo grupa użytkowników w obrębie całej instancji serwera. Nie są one ograniczone do jednej bazy danych, katalogu czy aplikacji. Mogą obejmować między innymi możliwość nawiązywania połączeń, tworzenia obiektów, zarządzania konfiguracją, uruchamiania określonych procesów administracyjnych albo odczytywania informacji o stanie instancji. Zakres dostępu zależy od zastosowanej platformy, sposobu uwierzytelniania i modelu autoryzacji.

W praktyce trzeba odróżnić uprawnienia do samego serwera od uprawnień nadanych wewnątrz konkretnej bazy danych. Konto może mieć prawo połączenia z instancją, ale nie mieć dostępu do tabel w wybranej bazie. Odwrotna sytuacja również może prowadzić do problemów: użytkownik może być poprawnie zdefiniowany w bazie, lecz nie mieć prawa nawiązania sesji z serwerem. Taki podział pozwala ograniczać dostęp do niezbędnego minimum i oddzielać czynności administracyjne od zwykłej pracy z danymi.

Poziom instancji a poziom bazy danych

Uprawnienia instancji dotyczą środowiska serwera jako całości. Ich działanie może obejmować wiele baz danych znajdujących się na tej samej instancji, a także operacje niezwiązane bezpośrednio z odczytem lub zapisem danych. Przykładem jest prawo do utworzenia nowej bazy, zmiany parametrów instancji, zarządzania połączeniami lub wykonywania czynności kontrolnych. Przyznanie takiego uprawnienia nie powinno być traktowane jako równoważne z udostępnieniem jednej tabeli, ponieważ zwykle daje szersze możliwości.

Po zalogowaniu serwer ustala tożsamość podmiotu, a następnie sprawdza, czy żądana operacja jest dozwolona. W tym procesie mogą uczestniczyć role, grupy oraz reguły dziedziczenia. Odebranie uprawnienia członkowi grupy nie zawsze wystarczy, jeśli dostęp wynika z innej roli albo z bezpośrednio nadanego zezwolenia. Z tego powodu diagnoza problemów wymaga sprawdzenia pełnego łańcucha zależności: użytego konta, grup, ról, mapowania do bazy, obiektu, na którym wykonywana jest operacja, oraz ewentualnych reguł odmawiających dostępu.

Uwierzytelnianie, role i zasada minimalnego dostępu

Uwierzytelnianie odpowiada na pytanie, kim jest użytkownik lub usługa, natomiast autoryzacja określa, co ten podmiot może zrobić. Samo poprawne podanie hasła, użycie certyfikatu albo potwierdzenie tożsamości w katalogu użytkowników nie oznacza jeszcze prawa do wykonania konkretnej operacji. Serwer może odrzucić żądanie, gdy konto nie należy do wymaganej roli, nie ma odpowiedniego zezwolenia albo próbuje wykonać czynność poza swoim zakresem.

Bezpieczna konfiguracja powinna opierać się na zasadzie minimalnego dostępu. Konto aplikacji powinno otrzymać tylko te prawa, które są konieczne do działania aplikacji, a konto serwisanta tylko te uprawnienia, których potrzebuje podczas diagnostyki lub konserwacji. Szerokie uprawnienia administracyjne zwiększają skutki błędnej konfiguracji, przejęcia hasła i pomyłki operatora. Warto także rozdzielać konta osobiste od kont usługowych, kontrolować członkostwo w grupach oraz okresowo przeglądać wpisy uprawnień.

Typowe objawy błędnej konfiguracji to komunikat o odmowie dostępu, brak możliwości utworzenia obiektu, nieudane połączenie aplikacji albo działanie funkcji tylko dla części użytkowników. Diagnostyka powinna obejmować dokładny komunikat błędu, czas wystąpienia, nazwę konta, używany kanał połączenia oraz operację, która została odrzucona. Zmiana uprawnień „na próbę” bez dokumentowania zakresu może ukryć przyczynę i doprowadzić do nadmiernego dostępu.

Diagnostyka i utrzymanie konfiguracji serwera

Przy analizie uprawnień należy najpierw ustalić, czy problem dotyczy uwierzytelniania, autoryzacji, połączenia sieciowego czy działania konkretnej aplikacji. Jeżeli serwer nie rozpoznaje konta, dodanie praw do bazy nie rozwiąże problemu. Jeżeli konto jest rozpoznane, ale brakuje mu prawa do operacji, trzeba ustalić, czy dostęp powinien zostać przyznany na poziomie instancji, bazy, schematu czy pojedynczego obiektu. Takie rozróżnienie ogranicza ryzyko nadania uprawnień szerszych niż wymagane.

Konfigurację warto opisywać w dokumentacji administracyjnej i kontrolować po każdej zmianie. Należy zapisywać nazwę podmiotu, zakres przyznanego prawa, powód zmiany, osobę wykonującą operację oraz przewidywany czas obowiązywania dostępu. W środowiskach produkcyjnych pomocne są rejestry audytowe i cykliczne przeglądy ról, ponieważ pozwalają wykryć nieużywane konta, odziedziczone uprawnienia oraz różnice między serwerami. Podczas serwisowania sprzętu lub systemu diagnostyka powinna obejmować również stan usług, dostępność zasobów i poprawność konfiguracji systemu operacyjnego, ponieważ awaria techniczna może wyglądać podobnie do błędu autoryzacji.

Uprawnienia do serwera nie powinny być zmieniane bez sprawdzenia zależności między instancją, bazami, aplikacjami i kontami usługowymi. Prawidłowo przeprowadzona analiza pozwala wskazać konkretną brakującą regułę albo nieprawidłowe dziedziczenie, a następnie wprowadzić zmianę o ograniczonym zakresie. Dzięki temu dostęp pozostaje przewidywalny, a naprawa nie powoduje przypadkowego otwarcia całego środowiska na operacje, które nie są potrzebne.