Rola serwera

Rola serwera to zbiór uprawnień działających na poziomie całej instancji, w odróżnieniu od ról poszczególnych baz.

Zakres uprawnień przypisanych do instancji

Rola serwera w systemie Microsoft SQL Server jest mechanizmem grupowania uprawnień obowiązujących na poziomie całej instancji. Instancja obejmuje silnik SQL Server wraz z jego bazami danych, logowaniami, konfiguracją oraz obiektami dostępnymi poza pojedynczą bazą. Członkostwo w roli serwera nie ogranicza się więc do tabel, widoków czy procedur znajdujących się w jednej bazie. Uprawnienia wynikają z przynależności loginu do roli i mogą obejmować operacje dotyczące wielu baz oraz elementów administracyjnych instancji.

Jest to odrębny poziom zabezpieczeń od ról bazodanowych. Rola bazodanowa działa w określonej bazie, natomiast rola serwera jest związana z zakresem instancji. Ten podział ma znaczenie przy analizie dostępu: użytkownik może mieć uprawnienia w jednej bazie dzięki członkostwu w roli bazodanowej, ale nie musi przez to otrzymywać praw do konfiguracji całego SQL Server. Odwrotna sytuacja również jest możliwa, ponieważ członkostwo w roli serwera może zapewnić szerszy dostęp niż uprawnienia nadane bezpośrednio w pojedynczej bazie.

Stałe i definiowane przez administratora role serwera

SQL Server udostępnia stałe role serwera, nazywane fixed server roles. Ich zakres jest określony przez silnik, a administrator może dodawać do nich loginy, lecz nie zmienia ich definicji przez dopisywanie pojedynczych uprawnień. Przykładem jest rola sysadmin, której członkowie mogą wykonywać dowolne czynności administracyjne w instancji SQL Server. Z tego powodu dodanie loginu do tej roli jest decyzją o bardzo szerokich konsekwencjach i nie powinno zastępować precyzyjnego nadawania minimalnego zakresu dostępu.

Do innych stałych ról serwera należą między innymi securityadmin, serveradmin, setupadmin, processadmin, diskadmin, dbcreator i bulkadmin. Każda z nich reprezentuje inny obszar możliwości, na przykład zarządzanie loginami, ustawieniami serwera, procesami silnika, tworzeniem baz albo operacjami masowego importu. Nazwa roli nie powinna być traktowana jako wystarczający opis ryzyka. Przy ocenie dostępu trzeba sprawdzić dokumentację konkretnej wersji SQL Server oraz rzeczywiste członkostwo loginów.

SQL Server pozwala także tworzyć role serwera definiowane przez użytkownika. Taką rolę można wykorzystać do zgrupowania wybranych uprawnień serwerowych, gdy stała rola ma zbyt szeroki zakres. Uprawnienia można nadać roli za pomocą instrukcji GRANT, ograniczyć instrukcją DENY albo odebrać instrukcją REVOKE, zgodnie z hierarchią uprawnień SQL Server. Rola niestandardowa ułatwia utrzymanie spójnej polityki dostępu, ale wymaga okresowego przeglądu, ponieważ zakres może zmienić się po kolejnych modyfikacjach konfiguracji.

Loginy, dziedziczenie i kontrola dostępu

Członkiem roli serwera jest login, czyli podmiot rozpoznawany przez instancję SQL Server. Login może być powiązany z kontem systemu Windows, grupą Windows albo uwierzytelnianiem SQL Server. Jeżeli login należy do grupy systemowej, która została dodana do roli serwera, uprawnienia są uzyskiwane pośrednio przez członkostwo grupowe. Przy diagnostyce dostępu trzeba zatem sprawdzić nie tylko bezpośrednie przypisania, ale również grupy, role nadrzędne oraz uprawnienia nadane bezpośrednio loginowi.

W SQL Server uprawnienia są organizowane hierarchicznie. Uprawnienia wyższego poziomu mogą obejmować uprawnienia dotyczące obiektów niższego poziomu, dlatego samo znalezienie jednego wpisu nie zawsze wyjaśnia pełny zakres dostępu. Znaczenie mają także relacje między uprawnieniami, członkostwo w wielu rolach oraz ewentualne konflikty wynikające z użycia DENY. W szczególności członkostwo w roli sysadmin powoduje, że mechanizmy kontroli dostępu na poziomie baz danych nie ograniczają członka tej roli w taki sam sposób jak zwykłego użytkownika.

Do sprawdzania członkostwa w rolach serwera można wykorzystać katalogowe widoki systemowe, między innymi sys.server_role_members oraz sys.server_principals. Pierwszy z nich opisuje relację między rolą a jej członkami, a drugi zawiera informacje o loginach i rolach dostępnych na poziomie serwera. Sam odczyt tych danych nie zawsze wystarcza do oceny skutecznego dostępu. Należy uwzględnić również uprawnienia nadane przez sys.server_permissions, członkostwo w grupach Windows oraz kontekst, w którym wykonywane jest połączenie.

Różnica między rolą serwera a rolą bazy danych

Rola serwera i rola bazy danych mają podobny cel organizacyjny, ale różny zakres działania. Rola bazy danych istnieje wewnątrz konkretnej bazy, a jej członkowie otrzymują uprawnienia do zasobów tej bazy. Typowymi przykładami są role db_owner, db_datareader i db_datawriter. Pierwsza z nich zapewnia pełną kontrolę nad daną bazą, druga umożliwia odczyt danych z tabel i widoków, a trzecia pozwala na zapis danych zgodnie z zakresem właściwym dla tej roli.

Dodanie loginu do roli bazodanowej wymaga wykonania operacji w konkretnej bazie. W SQL Server można użyć instrukcji ALTER ROLE ... ADD MEMBER, wskazując istniejącą rolę i użytkownika bazy danych. Login na poziomie instancji musi mieć odpowiedniego użytkownika w bazie, aby korzystać z zasobów tej bazy w typowym modelu mapowania. Sam fakt istnienia loginu nie oznacza automatycznie pełnego dostępu do wszystkich baz, a członkostwo w roli jednej bazy nie rozszerza się samoistnie na pozostałe bazy instancji.

Rola serwera jest właściwym miejscem do grupowania uprawnień dotyczących instancji, natomiast rola bazy danych służy do porządkowania dostępu do danych i obiektów konkretnej bazy. Błędne połączenie tych poziomów może prowadzić zarówno do odmowy dostępu, jak i do nadania uprawnień szerszych niż wymagane. Przy analizie problemu należy ustalić, czy błąd dotyczy logowania do instancji, wyboru bazy, dostępu do obiektu, czy operacji administracyjnej wykonywanej poza zakresem jednej bazy.