Extended Events do audytu

Extended Events do audytu to zastosowanie tego mechanizmu do rejestrowania zdarzeń związanych z bezpieczeństwem i dostępem.

Extended Events jako mechanizm rejestrowania zdarzeń

Extended Events to wbudowany w Microsoft SQL Server mechanizm śledzenia zdarzeń zachodzących wewnątrz silnika bazy danych. W zastosowaniach audytowych służy do rejestrowania operacji związanych z logowaniem, uwierzytelnianiem, zmianą uprawnień, wykonywaniem określonych instrukcji oraz występowaniem błędów. Zebrane informacje są zapisywane w ramach sesji Extended Events, którą można skonfigurować tak, aby obserwowała tylko zdarzenia istotne z punktu widzenia konkretnego systemu.

Sesja składa się między innymi ze zdarzeń, predykatów, akcji i celów zapisu. Zdarzenie opisuje sytuację wykrywaną przez silnik, na przykład nieudaną próbę logowania lub wykonanie instrukcji. Predykat ogranicza liczbę rejestrowanych przypadków, na przykład do wybranej bazy danych, nazwy użytkownika albo określonego typu operacji. Akcja dołącza dodatkowe dane do zdarzenia, natomiast cel, taki jak plik event_file albo bufor pierścieniowy ring_buffer, określa sposób przechowywania wyników.

Jakie operacje można objąć audytem

Zakres audytu zależy od użytych zdarzeń dostępnych w danej wersji i edycji SQL Server. Przy analizie dostępu przydatne są zdarzenia dotyczące poprawnego i niepoprawnego logowania, zamykania sesji, błędów uprawnień oraz odrzuconych operacji. W przypadku kontroli zmian konfiguracji można rejestrować wykonywanie instrukcji administracyjnych, zmianę ustawień bazy lub modyfikację obiektów. Dla śledzenia pracy aplikacji można zawęzić obserwację do konkretnej bazy, schematu, loginu, nazwy aplikacji albo hosta klienta.

W danych zdarzenia mogą znaleźć się między innymi czas wystąpienia, identyfikator sesji, nazwa loginu, nazwa bazy danych, adres lub identyfikator połączenia, nazwa aplikacji oraz tekst instrukcji, jeśli wybrano zdarzenie i akcję udostępniające takie informacje. Nie każdy typ zdarzenia zawiera wszystkie pola. Przed uruchomieniem audytu trzeba sprawdzić dostępne kolumny, ponieważ nadmiarowe akcje zwiększają ilość zapisywanych danych, a niektóre wartości mogą zależeć od kontekstu wykonania.

Projektowanie sesji bez nadmiernego obciążenia

Audyt Extended Events powinien być możliwie precyzyjny. Rejestrowanie wszystkich instrukcji wykonywanych przez wszystkie sesje zwykle tworzy duży strumień danych, utrudnia analizę i może zwiększać koszt zapisu. Lepszym rozwiązaniem jest zastosowanie predykatów, takich jak filtr po nazwie bazy, loginie, identyfikatorze sesji, nazwie aplikacji lub klasie błędu. Osobne sesje mogą służyć do długotrwałego monitorowania dostępu oraz do krótkich, szczegółowych dochodzeń diagnostycznych.

Do trwałego audytu najczęściej wykorzystuje się cel event_file, który zapisuje dane do plików odczytywanych później przez SQL Server Management Studio albo funkcje tabelowe, między innymi sys.fn_xe_file_target_read_file. Bufor pierścieniowy jest przechowywany w pamięci i nadaje się przede wszystkim do krótkiej obserwacji, ponieważ po zapełnieniu starsze zdarzenia mogą zostać zastąpione nowszymi. Przy zapisie do plików trzeba określić limit rozmiaru, liczbę plików oraz lokalizację, a także zapewnić odpowiednie uprawnienia systemu operacyjnego dla procesu SQL Server.

Odczyt, wiarygodność i zabezpieczenie wyników

Sam fakt utworzenia sesji nie oznacza jeszcze, że audyt jest kompletny. Należy sprawdzić, czy sesja została uruchomiona, czy wybrane zdarzenia rzeczywiście występują oraz czy cel zapisu nie odrzuca danych z powodu błędnej ścieżki, braku uprawnień albo ograniczenia rozmiaru plików. Przydatne są widoki katalogowe, takie jak sys.server_event_sessions, sys.server_event_session_events, sys.server_event_session_targets i sys.dm_xe_sessions, które pozwalają porównać konfigurację z aktualnym stanem działania.

Wyniki należy interpretować razem z czasem serwera, identyfikatorem sesji i kontekstem połączenia. Jedno zdarzenie nie zawsze dowodzi celowego działania użytkownika, ponieważ operacje mogą być wykonywane przez konto aplikacyjne, zadanie automatyczne albo narzędzie administracyjne. Warto zachować konfigurację sesji, informacje o zmianach ustawień oraz ciągłość plików wynikowych. Dostęp do plików audytowych powinien być ograniczony, ponieważ mogą zawierać tekst instrukcji, nazwy obiektów, identyfikatory logowania i inne szczegóły środowiska SQL Server.