SQL Server Audit

SQL Server Audit to mechanizm rejestrujący zdarzenia bazodanowe na potrzeby zgodności i bezpieczeństwa.

Architektura SQL Server Audit i zakres rejestrowanych zdarzeń

SQL Server Audit jest wbudowanym mechanizmem audytowania aparatu SQL Server Database Engine. Jego zadaniem jest zapisywanie informacji o wybranych działaniach wykonywanych na poziomie instancji oraz konkretnej bazy danych. Konfiguracja składa się z obiektu Server Audit, który określa miejsce docelowe i sposób obsługi zapisu, oraz specyfikacji definiujących, jakie zdarzenia mają być rejestrowane. Na poziomie instancji stosuje się Server Audit Specification, natomiast w bazie danych Database Audit Specification.

Audyt może obejmować między innymi logowania, zmiany uprawnień, operacje na obiektach, wykonywanie instrukcji oraz użycie określonych uprawnień. Dostępne są zarówno pojedyncze akcje audytowe, jak i grupy akcji. Zakres należy dobierać świadomie, ponieważ zbyt szeroka konfiguracja zwiększa liczbę rekordów i może utrudnić analizę. SQL Server Audit nie rejestruje automatycznie każdej wartości odczytanej z każdej tabeli; zapisuje tylko zdarzenia wskazane w aktywnych specyfikacjach.

Miejsce docelowe i zawartość wpisu audytowego

W instancji SQL Server obiekt Server Audit może kierować dane do pliku, dziennika aplikacji systemu Windows albo dziennika zabezpieczeń systemu Windows, zależnie od konfiguracji i uprawnień środowiska. Najczęściej używanym rozwiązaniem jest plik audytu, ponieważ pozwala przechowywać dane w kontrolowanym katalogu oraz analizować je narzędziami SQL Server. Dla zapisu do dziennika zabezpieczeń wymagane są odpowiednie ustawienia systemu operacyjnego i uprawnienia konta usługi.

Wpis audytowy zawiera informacje pozwalające ustalić między innymi czas zdarzenia, nazwę serwera, nazwę instancji, bazę danych, użytkownika, aplikację kliencką, adres hosta oraz rodzaj wykonanej akcji. W zależności od zdarzenia mogą pojawić się także nazwa obiektu, instrukcja, kod wyniku i informacja o powodzeniu operacji. Pliki można odczytywać funkcją systemową sys.fn_get_audit_file, która zwraca rekordy z plików audytu w postaci możliwej do filtrowania zapytaniem T-SQL. Dostęp do wyników powinien być ograniczony, ponieważ sam audyt może ujawniać szczegóły dotyczące kont, obiektów i wykonywanych poleceń.

Konfiguracja, kontrola działania i reakcja na błędy

Konfigurację można tworzyć w SQL Server Management Studio albo za pomocą instrukcji Transact-SQL, takich jak CREATE SERVER AUDIT, CREATE SERVER AUDIT SPECIFICATION i CREATE DATABASE AUDIT SPECIFICATION. Po utworzeniu obiektów trzeba je włączyć osobno. Samo zdefiniowanie specyfikacji nie oznacza jeszcze, że SQL Server zapisuje zdarzenia. Stan i podstawowe właściwości konfiguracji można sprawdzać w widokach katalogowych, między innymi sys.server_audits, sys.server_audit_specifications oraz sys.database_audit_specifications.

Istotnym ustawieniem Server Audit jest reakcja na niepowodzenie zapisu. SQL Server pozwala określić, czy w takiej sytuacji operacja ma być kontynuowana, odrzucona, czy instancja ma zostać zatrzymana. Wybór wpływa bezpośrednio na dostępność bazy danych i powinien uwzględniać wymagania organizacyjne oraz sposób monitorowania wolnego miejsca. Problemy z audytem mogą wynikać z braku uprawnień do katalogu, niedostępnego udziału, zapełnienia dysku, błędnej ścieżki albo ograniczeń systemu Windows. Dlatego podczas wdrażania należy sprawdzić zarówno stan obiektów audytu, jak i faktyczne pojawianie się nowych plików oraz rekordów.

Wykorzystanie danych SQL Server Audit przy analizie incydentu

Audyt SQL Server służy do odtworzenia kolejności wybranych działań, na przykład logowania konta, zmiany uprawnień, modyfikacji obiektu lub wykonania określonej operacji w bazie. Analiza powinna uwzględniać czas zdarzenia, konto, nazwę aplikacji i hosta, ponieważ samo polecenie nie zawsze wskazuje, kto faktycznie zainicjował działanie. W środowiskach, w których używane są konta techniczne, trzeba dodatkowo porównać wpisy audytowe z logami aplikacji i harmonogramami zadań.

Podczas diagnostyki problemów z SQL Server warto rozdzielić brak rejestrowania od braku wystąpienia zdarzenia. Należy potwierdzić, że właściwa specyfikacja jest włączona, obejmuje szukaną akcję, zapisuje do dostępnego celu i nie została wyłączona po błędzie. Trzeba również sprawdzić rotację oraz archiwizację plików, aby starsze dane nie zostały utracone przez nadpisanie lub ręczne usunięcie. Audyt nie zastępuje kopii zapasowych, kontroli uprawnień ani monitorowania wydajności; dostarcza śladów tylko dla zakresu, który został wcześniej skonfigurowany.