SQL Server Audit Service

SQL Server Audit Service zarządza specyfikacjami audytu i kieruje zapisy do wskazanego celu, np. pliku lub dziennika.

SQL Server Audit Service jako mechanizm audytu

SQL Server Audit Service to określenie mechanizmu audytu dostępnego w Microsoft SQL Server. Nie jest to osobny silnik bazy danych ani niezależna usługa aplikacyjna odpowiedzialna za wykonywanie zapytań. Mechanizm rejestruje wybrane zdarzenia dotyczące instancji SQL Server oraz baz danych, a następnie zapisuje je w skonfigurowanym miejscu docelowym. Dzięki temu można ustalić, jakie operacje zostały wykonane, przez który kontekst zabezpieczeń i w jakim czasie. Zakres rejestrowania zależy od ustawionych specyfikacji audytu, dlatego samo utworzenie obiektu audytu nie oznacza jeszcze zapisywania wszystkich zdarzeń.

W SQL Server występują dwa podstawowe poziomy konfiguracji. Server Audit określa obiekt docelowy oraz sposób obsługi zapisu, natomiast Server Audit Specification wybiera zdarzenia dotyczące całej instancji. Database Audit Specification służy do wskazywania zdarzeń zachodzących w konkretnej bazie danych. Specyfikacje mogą obejmować między innymi grupy działań związanych z logowaniem, zmianą uprawnień, operacjami na obiektach oraz wykonywaniem instrukcji. Taki podział pozwala rozdzielić ustawienia techniczne zapisu od zakresu obserwowanych operacji.

Obiekt docelowy i przebieg zapisu zdarzeń

SQL Server Audit może kierować dane do pliku, dziennika Application systemu Windows albo dziennika Security systemu Windows. Wybór celu wpływa na sposób późniejszego odczytu oraz wymagane uprawnienia systemowe. Dla celu plikowego SQL Server tworzy pliki audytu w określonej lokalizacji, a administrator może ustawić między innymi maksymalny rozmiar pojedynczego pliku, liczbę plików przechowywanych w ramach rotacji oraz zachowanie po wystąpieniu błędu zapisu. Lokalizacja musi być dostępna dla konta, pod którym działa usługa silnika SQL Server.

Podczas zapisu mogą wystąpić opóźnienia wynikające z buforowania zdarzeń. Parametr QUEUE_DELAY określa maksymalny czas oczekiwania na zapis buforowanych danych, natomiast opcja ON_FAILURE definiuje zachowanie w przypadku problemu z celem audytu. W zależności od konfiguracji błąd może zostać zignorowany, spowodować zatrzymanie działania instancji albo doprowadzić do utraty dostępności operacji, których nie da się bezpiecznie obsłużyć bez audytu. Audyt powinien być więc konfigurowany razem z kontrolą wolnego miejsca, uprawnień do katalogu i dostępności dzienników systemowych.

Konfiguracja specyfikacji i odczyt wyników

Konfigurację można tworzyć instrukcjami języka Transact-SQL, takimi jak CREATE SERVER AUDIT, CREATE SERVER AUDIT SPECIFICATION oraz CREATE DATABASE AUDIT SPECIFICATION. Po utworzeniu specyfikacji trzeba ją włączyć, ustawiając jej stan na ON. Podobnie sam obiekt Server Audit musi mieć aktywny stan, aby rozpocząć przyjmowanie zdarzeń. Do zmiany konfiguracji służą między innymi instrukcje ALTER SERVER AUDIT i ALTER DATABASE AUDIT SPECIFICATION. Wyłączenie specyfikacji zatrzymuje rejestrowanie wskazanego zakresu, ale nie usuwa wcześniej zapisanych plików audytu.

Stan konfiguracji można sprawdzać w widokach katalogowych. Widok sys.server_audits zawiera informacje o zdefiniowanych obiektach audytu, a sys.server_audit_specifications oraz sys.database_audit_specifications pokazują konfigurację specyfikacji. Do sprawdzania bieżącego stanu działania przydatny jest sys.dm_server_audit_status. Jeżeli audyt zapisuje dane do plików, do ich odczytu można użyć funkcji sys.fn_get_audit_file. Wyniki należy analizować z uwzględnieniem czasu zdarzenia, nazwy akcji, identyfikatora sesji, użytkownika oraz obiektu, którego dotyczyła operacja. Sam wpis audytowy nie zawsze wyjaśnia przyczynę działania, dlatego warto zestawiać go z innymi dostępnymi informacjami diagnostycznymi instancji.

Typowe problemy przy sprawdzaniu SQL Server Audit

Brak oczekiwanych wpisów nie musi oznaczać awarii mechanizmu. Częstą przyczyną jest włączenie Server Audit bez aktywowania właściwej specyfikacji albo skonfigurowanie Database Audit Specification dla innej bazy niż ta, w której wykonywano operację. Możliwa jest także pomyłka między grupą audytowanych działań a pojedynczą akcją. Weryfikacja powinna obejmować nazwę instancji, nazwę bazy, stan wszystkich powiązanych obiektów, wybrany cel oraz rzeczywistą lokalizację plików. Należy również sprawdzić, czy zakres audytu obejmuje zdarzenie, którego wystąpienia się oczekuje.

Diagnostyka problemów z audytem obejmuje także analizę komunikatów silnika SQL Server, uprawnień konta usługi i stanu miejsca na dysku. Przy celu plikowym warto potwierdzić możliwość utworzenia oraz dopisywania plików w katalogu, a przy dziennikach Windows sprawdzić dostępność odpowiedniego logu i uprawnienia wymagane do zapisu. Trzeba pamiętać, że zmiana konfiguracji nie uzupełnia zdarzeń z przeszłości: audyt rejestruje operacje dopiero od momentu aktywowania odpowiedniej konfiguracji. Jeżeli problem dotyczy środowiska serwerowego, diagnostyka powinna być prowadzona przez administratora znającego konfigurację instancji, systemu Windows i zasad przechowywania logów.