Widok sys.dm_audit_actions

sys.dm_audit_actions zwraca listę akcji, które mogą zostać objęte mechanizmem audytu SQL Server.

Widok sys.dm_audit_actions — czym jest i do czego służy

Widok sys.dm_audit_actions w Microsoft SQL Server udostępnia katalog akcji, które mogą zostać wykorzystane podczas projektowania audytu. Nie jest to dziennik wykonanych operacji i nie pokazuje sam w sobie historii aktywności użytkowników. Zwracane dane opisują możliwości dostępne w mechanizmie audytu, czyli rodzaje zdarzeń, operacji i obiektów, które można uwzględnić w specyfikacji audytu serwera albo audytu bazy danych.

Znaczenie tego widoku staje się szczególnie widoczne na etapie planowania kontroli dostępu. Zamiast opierać konfigurację wyłącznie na nazwach znanych z dokumentacji, można odczytać katalog akcji bezpośrednio z używanej instancji SQL Server. Pozwala to sprawdzić, jakie elementy są dostępne w danej wersji produktu, jakie identyfikatory mają poszczególne akcje oraz czy dana funkcja może zostać przypisana do odpowiedniej grupy audytowej.

Widok ma charakter opisowy i administracyjny. Do właściwego rejestrowania zdarzeń potrzebne jest utworzenie oraz włączenie konfiguracji audytu, wskazanie zakresu monitorowania i wybranie miejsca zapisu danych. Samo zapytanie do sys.dm_audit_actions nie uruchamia audytowania, nie zmienia ustawień bezpieczeństwa i nie tworzy plików dziennika.

sys.dm_audit_actions w kontekście technicznym i porównaniach

W praktyce warto odróżnić trzy elementy: katalog dostępnych akcji, definicję audytu oraz zapisane zdarzenia. sys.dm_audit_actions pełni funkcję katalogu. Obiekt konfiguracji audytu określa, które zdarzenia będą obserwowane i dokąd trafią wyniki. Z kolei pliki audytu lub inne skonfigurowane miejsce docelowe przechowują faktyczne wpisy, które można później analizować.

Takie rozdzielenie ma znaczenie podczas diagnozowania problemów. Brak interesującego działania w wynikach audytu nie musi oznaczać, że akcja nie istnieje. Przyczyną może być brak wybrania jej w specyfikacji, wyłączona konfiguracja, ograniczony zakres obiektów albo filtr odrzucający część zdarzeń. Z drugiej strony obecność akcji w widoku nie oznacza, że jest ona aktualnie rejestrowana. Najpierw należy sprawdzić definicję audytu, stan jego aktywności oraz ustawienia specyfikacji.

Widok dynamiczny może być porównywany z innymi katalogami systemowymi, lecz nie powinien być traktowany jako odpowiednik widoków zawierających bieżące sesje, zapytania lub blokady. Nie służy do obserwowania aktualnego obciążenia ani do odtwarzania kolejności operacji. Jego wartość polega na opisaniu modelu audytowania, a nie na dostarczaniu danych eksploatacyjnych. W zależności od wersji SQL Server zestaw zwracanych informacji może się różnić, dlatego konfigurację warto opierać na wyniku uzyskanym z konkretnej instancji.

Przykładowe zapytanie może wyglądać następująco:

SELECT *
FROM sys.dm_audit_actions
ORDER BY name;

Wynik powinien zostać odczytany jako lista technicznych możliwości. Przy analizie należy zwrócić uwagę na nazwy akcji, ich identyfikatory, opis oraz informacje wskazujące, czy dana akcja odnosi się do poziomu serwera, bazy danych, schematu, obiektu lub innego zakresu. Dokładne nazwy kolumn i ich interpretacja powinny być sprawdzane w dokumentacji właściwej dla wdrożonej wersji.

Typowe problemy przy analizie sys.dm_audit_actions

Jednym z częstszych nieporozumień jest oczekiwanie, że widok pokaże użytkowników, którzy wykonali operacje. Tego rodzaju informacje znajdują się dopiero w zarejestrowanych zdarzeniach audytu, o ile odpowiednia akcja została wcześniej objęta konfiguracją. Katalog akcji nie zawiera więc odpowiedzi na pytanie, kto zmienił dane lub kiedy wykonano konkretne polecenie.

Innym problemem jest wybieranie akcji wyłącznie na podstawie podobnie brzmiących nazw. Dwa działania mogą dotyczyć różnych poziomów ochrony albo rejestrować odmienne etapy operacji. Przed włączeniem monitorowania należy ustalić, jaki cel ma audyt: kontrola zmian uprawnień, śledzenie dostępu do określonych obiektów, obserwacja operacji administracyjnych czy weryfikacja prób dostępu zakończonych odmową. Dopiero potem można dobrać zakres, aby zapis był użyteczny i nie został zdominowany przez zdarzenia nieistotne.

Problemy mogą wynikać także z braku uprawnień do odczytu metadanych albo z uruchomienia zapytania w niewłaściwym kontekście. Warto zweryfikować konto wykonujące zapytanie, bazę, poziom instancji oraz zgodność składni z wersją SQL Server. Jeżeli katalog zwraca mniej informacji niż oczekiwano, nie powinno się od razu zakładać uszkodzenia audytu. Najpierw należy porównać wynik z dokumentacją, sprawdzić widoki opisujące konfigurację i przeprowadzić kontrolowany test na nieprodukcyjnym środowisku.

Nieprawidłowo zaplanowany audyt może generować dużą liczbę wpisów, utrudniać wyszukiwanie istotnych zdarzeń i zwiększać wymagania dotyczące przechowywania danych. Nadmierny zakres monitorowania bywa równie kłopotliwy jak zakres zbyt mały. Właściwa konfiguracja powinna uwzględniać cel kontroli, wymagania organizacyjne, okres przechowywania oraz sposób regularnego przeglądania wyników.

Praktyczne wskazówki dla widoku sys.dm_audit_actions

Pracę najlepiej rozpocząć od spisania pytań, na które audyt ma odpowiadać. Przykładowo może chodzić o ustalenie, czy zmieniano uprawnienia, czy odczytywano dane z określonego obiektu albo czy podejmowano próby wykonania niedozwolonych operacji. Takie pytania ułatwiają zawężenie listy akcji i wybór właściwego poziomu monitorowania.

• Najpierw należy odczytać katalog akcji z konkretnej instancji i zachować wynik jako materiał referencyjny.
• Następnie powinno się powiązać wymagania kontrolne z akcjami oraz zakresem obiektów, których dotyczą.
• Konfigurację warto wdrażać etapami, zaczynając od środowiska testowego i niewielkiego zakresu.
• Po uruchomieniu należy wykonać kontrolowane operacje i sprawdzić, czy oczekiwane zdarzenia pojawiają się w miejscu docelowym.
• Warto opisać właściciela konfiguracji, sposób przeglądania wpisów oraz procedurę reagowania na nietypowe zdarzenia.

Przydatne bywa również zapisanie zapytania użytego do odczytu widoku razem z wersją SQL Server, datą sprawdzenia i opisem przyjętej interpretacji. Dzięki temu późniejsze porównanie po aktualizacji jest łatwiejsze. Jeżeli katalog akcji zmieni się między wersjami, można ponownie ocenić, czy dotychczasowe reguły nadal obejmują wymagany zakres.

Wyniki audytu powinny być chronione przed nieuprawnioną zmianą, a dostęp do nich powinien być ograniczony do osób wykonujących zadania administracyjne, kontrolne lub analityczne. Należy także pamiętać, że wpis audytowy może zawierać informacje wrażliwe, zależnie od rodzaju rejestrowanej operacji. Z tego powodu sposób przechowywania, kopiowania i udostępniania danych powinien być zgodny z przyjętymi zasadami bezpieczeństwa.

Kiedy zgłosić się do serwisu z problemem dotyczącym sys.dm_audit_actions

Wsparcie techniczne może być potrzebne wtedy, gdy nie wiadomo, czy obserwowany problem wynika z samego katalogu akcji, konfiguracji audytu, uprawnień, wersji SQL Server czy miejsca zapisu zdarzeń. Zgłoszenie powinno zawierać treść zapytania, komunikat błędu, wersję produktu, opis oczekiwanego rezultatu oraz informację, czy problem występuje na jednej bazie, czy w całej instancji. Takie dane ułatwiają odtworzenie sytuacji bez pochopnego zmieniania ustawień bezpieczeństwa.

Warto zgłosić się również wtedy, gdy po włączeniu audytu pojawia się zbyt dużo wpisów, brakuje zdarzeń uznanych za istotne albo wyniki różnią się od zachowania obserwowanego w aplikacji. Analiza powinna objąć katalog sys.dm_audit_actions, definicje specyfikacji, zakres obiektów, uprawnienia konta oraz faktyczne pliki lub inne źródło danych audytowych. Przy takiej weryfikacji Warszawskie Pogotowie Komputerowe 24/7 może przeanalizować problem związany z komputerem i przygotować środowisko do dalszej diagnostyki SQL Server, przy czym naprawy z reguły realizowane są do 3 dni roboczych.

Przed zmianą konfiguracji należy wykonać kopię ustawień i ustalić, jakie działania są dopuszczalne w danym środowisku. Nie powinno się wyłączać audytu ani usuwać jego danych tylko po to, aby ukryć objawy błędu. Bezpieczniejsze jest zebranie informacji, porównanie konfiguracji z wymaganiami i przeprowadzenie korekty w kontrolowanym terminie.