Rola SQLAgentUserRole

Rola SQLAgentUserRole pozwala zarządzać wyłącznie własnymi zadaniami Agenta.

Gdzie ta rola żyje i co obejmuje

SQLAgentUserRole nie jest rolą serwerową ani rolą użytkowej bazy danych — została zdefiniowana w systemowej bazie msdb, bo to tam SQL Server Agent przechowuje definicje zadań, harmonogramów, operatorów i alertów. Aby ją nadać, login musi mieć użytkownika w msdb; samo konto na poziomie instancji nie wystarczy. Jest to najmniej uprzywilejowana z trzech ról Agenta i realizuje prostą zasadę: członek może tworzyć własne zadania, edytować je, uruchamiać, zatrzymywać i przeglądać ich historię, ale widzi wyłącznie te zadania, których jest właścicielem. Zadania innych osób nie pojawią się dla niego w gałęzi SQL Server Agent w SQL Server Management Studio, jakby w ogóle nie istniały.

Czym różni się od SQLAgentReaderRole i SQLAgentOperatorRole

Trzy role Agenta układają się w drabinę, a każda kolejna zawiera uprawnienia poprzedniej. SQLAgentReaderRole dokłada możliwość podejrzenia listy i historii wszystkich zadań na instancji, ale nadal pozwala modyfikować tylko własne. SQLAgentOperatorRole idzie dalej — pozwala uruchamiać, zatrzymywać oraz włączać i wyłączać cudze zadania, a także czyścić historię. Powyżej wszystkiego stoi rola serwerowa sysadmin, której członkowie mają nieograniczoną kontrolę nad Agentem niezależnie od członkostw w msdb. Osobną kwestią są konta proxy: krok zadania wykonujący pakiet SSIS, skrypt PowerShell czy polecenie systemowe działa w kontekście proxy, a prawo do użycia konkretnego proxy nadaje się oddzielnie — sama przynależność do SQLAgentUserRole go nie daje.

Typowe potknięcia przy nadawaniu uprawnień do Agenta

Klasyczny objaw to zadanie, które zniknęło po zmianie właściciela: administrator przepisał job na konto serwisowe i użytkownik z SQLAgentUserRole przestał je widzieć, choć nic nie zostało usunięte. Drugi to krok zadania kończący się komunikatem o braku uprawnień do wykonania jako proxy — brakuje przypisania proxy do roli, a nie uprawnień w bazie docelowej. Trzeci, znacznie groźniejszy, to obejście problemu przez dopisanie użytkownika do sysadmin, bo wtedy do rozwiązania drobnej niedogodności przyznaje się pełną władzę nad całą instancją, łącznie z prawem odczytu i modyfikacji każdej bazy. Warto też pamiętać, że zadanie należące do loginu spoza sysadmin jest wykonywane w kontekście tego loginu, więc brak praw w bazie docelowej ujawni się dopiero przy pierwszym uruchomieniu, a nie przy zapisie definicji.

Konfiguracja Agenta w firmowych bazach handlowych

Wdrażamy i utrzymujemy oprogramowanie oparte o SQL Server — Subiekta, WAPRO i Comarch — a wraz z nim harmonogramy kopii zapasowych, przebudowy indeksów i zadań integracyjnych. Ustawiamy uprawnienia tak, żeby osoba odpowiedzialna za backupy mogła nimi zarządzać bez konta administratora instancji, i porządkujemy właścicieli zadań po migracji serwera, gdy część jobów przestaje się uruchamiać. Wsparcie prowadzimy przez całą dobę, siedem dni w tygodniu, bo okna serwisowe na bazach zwykle wypadają w nocy.