SQL Server Audit (Database Engine)

  • 01/01/2020
  • 13 minutes to read
    • D
    • v
    • M
    • M
    • D
    • +8

Applies to: yesSQL Server (Wszystkie obsługiwane wersje) takAzure SQL Managed Instance

inspekcja wystąpienia silnika bazy danych SQL Server lub pojedynczej bazy danych obejmuje śledzenie i rejestrowanie zdarzeń występujących w silniku bazy danych. SQL Server audit umożliwia tworzenie audytów serwera, które mogą zawierać specyfikacje audytów serwera dla zdarzeń na poziomie serwera oraz specyfikacje audytów bazy danych dla zdarzeń na poziomie bazy danych. Skontrolowane zdarzenia mogą być zapisywane do dzienników zdarzeń lub do plików audytu.

ważne

w przypadku wystąpienia zarządzanego usługi Azure SQL ta funkcja T-SQL ma pewne zmiany w zachowaniu. Szczegóły dotyczące wszystkich zmian zachowania T-SQL można znaleźć w artykule Azure SQL Managed Instance T-SQL differences from SQL Server.

istnieje kilka poziomów audytu dla SQL Server, w zależności od wymagań rządowych lub standardów dotyczących instalacji. SQL Server Audit zapewnia narzędzia i procesy niezbędne do włączania, przechowywania i przeglądania audytów na różnych obiektach serwera i bazy danych.

możesz rejestrować grupy akcji audytu serwera dla każdej instancji oraz grupy akcji audytu bazy danych lub akcje audytu bazy danych dla każdej bazy danych. Zdarzenie audytu nastąpi za każdym razem, gdy napotkana zostanie kontrolowana akcja.

wszystkie edycje SQL Server obsługują audyty na poziomie serwera. Wszystkie wersje obsługują audyty poziomu bazy danych począwszy od SQL Server 2016(13 .x) SP1. Wcześniej kontrola poziomu bazy danych była ograniczona do wersji Enterprise, Developer i Evaluation. Aby uzyskać więcej informacji, zobacz Funkcje obsługiwane przez wersje SQL Server 2016.

Uwaga

ten temat dotyczy serwera SQL. Dla bazy danych SQL zobacz Wprowadzenie do SQL database auditing.

Komponenty audytu SQL Server

audyt to połączenie kilku elementów w jeden pakiet dla określonej grupy akcji serwera lub akcji bazy danych. Komponenty SQL Server audit łączą się, aby uzyskać wynik zwany audytem, tak jak definicja raportu w połączeniu z elementami graficznymi i danymi tworzy raport.

audyt serwera SQL wykorzystuje rozszerzone zdarzenia, aby pomóc w tworzeniu audytu. Aby uzyskać więcej informacji na temat rozszerzonych wydarzeń, Zobacz Rozszerzone wydarzenia.

SQL Server Audit

obiekt SQL Server Audit gromadzi pojedynczą instancję akcji na poziomie serwera lub bazy danych oraz grupy akcji do monitorowania. Audyt odbywa się na poziomie instancji serwera SQL. Na wystąpienie serwera SQL można przeprowadzić wiele audytów.

definiując audyt, określasz lokalizację wyjścia wyników. To jest cel kontroli. Audyt jest tworzony w stanie wyłączonym i nie kontroluje automatycznie żadnych działań. Po włączeniu audytu miejsce docelowe audytu otrzymuje dane z audytu.

Specyfikacja audytu serwera

obiekt specyfikacji audytu serwera należy do audytu. Można utworzyć jedną specyfikację audytu serwera na audyt, ponieważ obie są tworzone w zakresie instancji SQL Server.

Specyfikacja audytu serwera gromadzi wiele grup akcji na poziomie serwera wywołanych przez funkcję Extended Events. Grupy akcji audytu można włączyć do specyfikacji audytu serwera. Grupy działań audytu to predefiniowane grupy działań, które są zdarzeniami atomowymi występującymi w silniku bazy danych. Działania te są wysyłane do audytu, który rejestruje je w celu.

grupy akcji audytu na poziomie serwera są opisane w temacie SQL Server Audit Action Groups and Actions.

Specyfikacja audytu bazy danych

obiekt specyfikacji audytu bazy danych należy również do audytu SQL Server. Można utworzyć jedną specyfikację audytu bazy danych dla każdej bazy danych SQL Server dla każdego audytu.

Specyfikacja audytu bazy danych gromadzi akcje audytu na poziomie bazy danych wywołane przez rozszerzoną funkcję zdarzeń. Do specyfikacji audytu bazy danych można dodać grupy akcji audytu lub zdarzenia audytu. Zdarzenia audytu to akcje atomowe, które mogą być kontrolowane przez silnik SQL Server. Grupy działań audytowych to predefiniowane grupy działań. Oba znajdują się w zakresie bazy danych SQL Server. Działania te są wysyłane do audytu, który rejestruje je w celu. Nie uwzględniaj obiektów o zasięgu serwera, takich jak widoki systemowe, w specyfikacji audytu bazy danych użytkownika.

grupy akcji audytu na poziomie bazy danych i akcje audytu są opisane w temacie SQL Server Audit Action Groups and Actions.

cel

wyniki audytu są wysyłane do celu, którym może być plik, dziennik zdarzeń zabezpieczeń systemu Windows lub dziennik zdarzeń aplikacji systemu Windows. Dzienniki muszą być okresowo sprawdzane i archiwizowane, aby upewnić się, że obiekt docelowy ma wystarczająco dużo miejsca na zapisywanie dodatkowych rekordów.

ważne

każdy uwierzytelniony użytkownik może odczytywać i zapisywać do dziennika zdarzeń aplikacji systemu Windows. Dziennik zdarzeń aplikacji wymaga niższych uprawnień niż dziennik zdarzeń zabezpieczeń systemu Windows i jest mniej bezpieczny niż dziennik zdarzeń zabezpieczeń systemu Windows.

zapis do dziennika zabezpieczeń systemu Windows wymaga dodania konta usługi SQL Server do zasad generowania audytów bezpieczeństwa. Domyślnie System lokalny, Usługa lokalna i usługa sieciowa są częścią tej zasady. To ustawienie można skonfigurować za pomocą przystawki Zasady bezpieczeństwa (secpol.msc). Co więcej, polityka bezpieczeństwa dostępu do obiektu audytu musi być włączona zarówno w przypadku sukcesu, jak i niepowodzenia. To ustawienie można skonfigurować za pomocą przystawki Zasady bezpieczeństwa (secpol.msc). W systemie Windows Vista lub Windows Server 2008 można ustawić bardziej szczegółową politykę aplikacji generowaną z wiersza poleceń za pomocą programu audit policy (AuditPol.exe). Aby uzyskać więcej informacji na temat kroków umożliwiających zapis do dziennika zabezpieczeń systemu Windows, zobacz zapis zdarzeń audytu SQL Server do dziennika zabezpieczeń. Więcej informacji o Auditpol.program exe, patrz Baza wiedzy artykuł 921469, jak używać zasad grupy do konfigurowania szczegółowego audytu zabezpieczeń. Dzienniki zdarzeń systemu Windows są globalne dla systemu operacyjnego Windows. Aby uzyskać więcej informacji na temat dzienników zdarzeń systemu Windows, zobacz Przegląd przeglądarki zdarzeń. Jeśli potrzebujesz bardziej precyzyjnych uprawnień do audytu, użyj docelowego pliku binarnego.

podczas zapisywania informacji z audytu do pliku, aby zapobiec manipulacjom, możesz ograniczyć dostęp do lokalizacji pliku w następujący sposób:

  • konto usługi SQL Server musi mieć zarówno uprawnienia do odczytu, jak i zapisu.

  • Administratorzy audytu zazwyczaj wymagają uprawnień do odczytu i zapisu. Zakłada to, że administratorzy audytu są kontami systemu Windows do administrowania plikami audytu, takimi jak: kopiowanie ich do różnych udziałów, tworzenie kopii zapasowych i tak dalej.

  • czytelnicy audytu, którzy są uprawnieni do odczytu plików audytu, muszą mieć uprawnienia do odczytu.

nawet gdy silnik bazy danych zapisuje do pliku, inni użytkownicy systemu Windows mogą odczytać plik audytu, jeśli mają uprawnienia. Silnik bazy danych nie przyjmuje wyłącznej blokady, która uniemożliwia operacje odczytu.

ponieważ silnik bazy danych może uzyskać dostęp do pliku, loginy SQL Server z uprawnieniami CONTROL SERVER mogą korzystać z silnika bazy danych, aby uzyskać dostęp do plików audytu. Aby nagrać dowolnego użytkownika, który czyta plik audytu, zdefiniuj audyt NA master.sys.fn_get_audit_file. Rejestruje to dane logowania z uprawnieniami CONTROL SERVER, które uzyskały dostęp do pliku audytu za pośrednictwem SQL Server.

Jeśli Administrator audytu skopiuje plik do innej lokalizacji (do celów archiwalnych itp.), ACL w nowej lokalizacji powinny zostać zredukowane do następujących uprawnień:

  • Administrator audytu-Odczyt / Zapis

  • Reader Audit-Czytaj

zalecamy generowanie raportów audytu z osobnej instancji SQL Server, takiej jak instancja SQL Server Express, do której dostęp Mają Tylko administratorzy audytu lub czytelnicy audytu. Korzystając z osobnej instancji silnika bazy danych do raportowania, możesz zapobiec uzyskaniu dostępu do rekordu audytu przez nieupoważnionych użytkowników.

możesz zaoferować dodatkową ochronę przed nieautoryzowanym dostępem, szyfrując folder, w którym przechowywany jest plik audytu, za pomocą szyfrowania dysku BitLocker systemu Windows lub systemu plików szyfrowania systemu Windows.

aby uzyskać więcej informacji na temat rekordów audytu zapisanych do obiektu docelowego, zobacz rekordy audytu SQL Server.

przegląd korzystania z audytu SQL Server

możesz użyć SQL Server Management Studio lub Transact-SQL do zdefiniowania audytu. Po utworzeniu i włączeniu audytu obiekt docelowy otrzyma wpisy.

dzienniki zdarzeń systemu Windows można odczytywać za pomocą narzędzia Podgląd zdarzeń w systemie Windows. W przypadku plików docelowych można użyć przeglądarki plików dziennika w SQL Server Management Studio lub funkcji fn_get_audit_file, aby odczytać plik docelowy.

ogólny proces tworzenia i korzystania z audytu jest następujący.

  1. Utwórz audyt i określ cel.

  2. Utwórz specyfikację audytu serwera lub specyfikację audytu bazy danych, która mapuje się do audytu. Włącz specyfikację audytu.

  3. Włącz audyt.

  4. odczytaj zdarzenia audytu za pomocą przeglądarki zdarzeń systemu Windows, przeglądarki plików dziennika lub funkcji fn_get_audit_file.

aby uzyskać więcej informacji, zobacz tworzenie specyfikacji audytu serwera i audytu serwera oraz tworzenie specyfikacji audytu serwera i audytu bazy danych.

w przypadku awarii podczas inicjacji audytu serwer nie uruchomi się. W takim przypadku serwer można uruchomić za pomocą opcji-f w wierszu poleceń.

gdy awaria audytu powoduje zamknięcie lub nie uruchomienie serwera, ponieważ dla audytu podano tag ON_FAILURE = SHUTDOWN, Zdarzenie MSG_AUDIT_FORCED_SHUTDOWN zostanie zapisane do dziennika. Ponieważ zamknięcie nastąpi przy pierwszym zetknięciu się z tym ustawieniem, zdarzenie zostanie zapisane jednorazowo. To zdarzenie jest zapisywane po wiadomości o awarii dla audytu powodującej zamknięcie. Administrator może ominąć wywołane audytem wyłączenia, uruchamiając SQL Server w trybie pojedynczego użytkownika za pomocą flagi – M. Jeśli uruchomisz w trybie pojedynczego użytkownika, obniżysz poziom kontroli, w której on_failure=SHUTDOWN jest określone jako on_failure=CONTINUE. Gdy serwer SQL zostanie uruchomiony przy użyciu znacznika – M, wiadomość MSG_AUDIT_SHUTDOWN_BYPASSED zostanie zapisana do dziennika błędów.

aby uzyskać więcej informacji na temat opcji uruchamiania usługi, zobacz Opcje uruchamiania usługi silnika bazy danych.

dołączenie bazy danych z zdefiniowanym audytem

dołączenie bazy danych, która ma specyfikację audytu i określa identyfikator GUID, który nie istnieje na serwerze, spowoduje powstanie osieroconej specyfikacji audytu. Ponieważ audyt z odpowiadającym mu identyfikatorem GUID nie istnieje w instancji serwera, nie będą rejestrowane żadne zdarzenia audytu. Aby poprawić tę sytuację, użyj polecenia Zmień specyfikację audytu bazy danych, aby połączyć osieroconą specyfikację audytu z istniejącym audytem serwera. Możesz też użyć polecenia Utwórz audyt serwera, aby utworzyć nowy audyt serwera z określonym identyfikatorem GUID.

możesz dołączyć bazę danych, która ma zdefiniowaną specyfikację audytu do innej wersji SQL Server, która nie obsługuje audytu SQL Server, na przykład SQL Server Express, ale nie będzie rejestrować zdarzeń audytu.

dublowanie bazy danych i audyt serwera SQL

baza danych, która ma zdefiniowaną specyfikację audytu bazy danych i która używa dublowania bazy danych, będzie zawierać specyfikację audytu bazy danych. Aby poprawnie działać na instancji SQL dublowanej, należy skonfigurować następujące elementy:

  • serwer lustrzany musi mieć audyt z tym samym identyfikatorem GUID, aby umożliwić specyfikację audytu bazy danych zapisywanie rekordów audytu. Można to skonfigurować za pomocą polecenia Utwórz audyt z GUID = < GUID z audytu serwera źródłowego>.

  • w przypadku plików binarnych, konto usługi serwera lustrzanego musi mieć odpowiednie uprawnienia do lokalizacji, w której zapisywana jest ścieżka audytu.

  • w przypadku celów dziennika zdarzeń systemu Windows zasady bezpieczeństwa na komputerze, na którym znajduje się serwer lustrzany, muszą zezwalać na dostęp konta usługi do dziennika zdarzeń zabezpieczeń lub aplikacji.

Administratorzy inspekcji

członkowie roli stałego serwera sysadmin są identyfikowani jako użytkownik dbo w każdej bazie danych. Aby kontrolować działania administratorów, sprawdź działania użytkownika dbo.

Tworzenie audytów i zarządzanie nimi za pomocą Transact-SQL

do implementacji wszystkich aspektów audytu SQL Server Można używać instrukcji DDL, dynamicznych widoków i funkcji zarządzania oraz widoków katalogów.

instrukcje języka definicji danych

możesz użyć następujących instrukcji DDL do tworzenia, zmiany i upuszczania specyfikacji audytu:

wypowiedzi DDL opis
Zmień autoryzację zmienia własność zabezpieczanego.
Zmień specyfikację audytu bazy danych zmienia obiekt specyfikacji audytu bazy danych za pomocą funkcji audytu SQL Server.
Zmień audyt serwera zmienia obiekt audyt serwera za pomocą funkcji audyt serwera SQL.
Zmień specyfikację audytu serwera zmienia obiekt specyfikacji audytu serwera za pomocą funkcji audytu serwera SQL.
Utwórz specyfikację audytu bazy danych tworzy obiekt specyfikacji audytu bazy danych przy użyciu funkcji audytu SQL Server.
Utwórz audyt serwera tworzy obiekt audyt serwera przy użyciu SQL Server Audit.
Utwórz specyfikację audytu serwera tworzy obiekt specyfikacji audytu serwera przy użyciu funkcji audytu serwera SQL.
upuść specyfikację audytu bazy danych upuszcza obiekt specyfikacji audytu bazy danych przy użyciu funkcji audytu SQL Server.
upuść audyt serwera upuszcza obiekt audyt serwera przy użyciu funkcji audyt serwera SQL.
upuść specyfikację audytu serwera upuszcza obiekt specyfikacji audytu serwera przy użyciu funkcji audytu serwera SQL.

Dynamiczne widoki i funkcje

poniższa tabela zawiera listę dynamicznych widoków i funkcji, których można użyć do inspekcji serwera SQL.

Dynamiczne widoki i funkcje opis
sys.dm_audit_actions zwraca wiersz dla każdej akcji audytu, którą można zgłosić w dzienniku audytu oraz dla każdej grupy akcji audytu, którą można skonfigurować jako część audytu SQL Server.
sys. dm_server_audit_status dostarcza informacji o aktualnym stanie audytu.
sys. dm_audit_class_type_map zwraca tabelę, która mapuje pole class_type w dzienniku kontroli do pola class_desc w sys. dm_audit_actions.
fn_get_audit_file Zwraca informacje z pliku audytu utworzonego przez audyt serwera.

widoki katalogów

poniższa tabela zawiera listę widoków katalogów, których można użyć do inspekcji SQL Server.

odsłon katalogu opis
sys.database_audit_specifications zawiera informacje o specyfikacji audytu bazy danych w audycie SQL Server na instancji serwera.
sys.database_audit_specification_details zawiera informacje o specyfikacji audytu bazy danych w audycie SQL Server na instancji serwera dla wszystkich baz danych.
sys.server_audits zawiera jeden wiersz dla każdego audytu SQL Server w instancji serwera.
sys.server_audit_specifications zawiera informacje o specyfikacji audytu serwera w audycie SQL Server na instancji serwera.
sys.server_audit_specifications_details zawiera informacje o szczegółach specyfikacji audytu serwera (akcji) w audycie SQL Server na instancji serwera.
sys.server_file_audits zawiera rozszerzone informacje o typie audytu plików w audycie SQL Server na instancji serwera.

uprawnienia

każda funkcja i polecenie dla SQL Server Audit ma indywidualne wymagania dotyczące uprawnień.

aby utworzyć, zmienić lub usunąć specyfikację audytu serwera lub audytu serwera, dyrektorzy serwera wymagają zmiany dowolnego audytu serwera lub uprawnień serwera kontroli. Aby utworzyć, zmienić lub upuścić specyfikację audytu bazy danych, dyrektorzy bazy danych wymagają uprawnienia ALTER ANY DATABASE AUDIT lub uprawnienia ALTER or CONTROL w bazie danych. Ponadto zleceniodawcy muszą mieć uprawnienia do łączenia się z bazą danych lub zmiany uprawnień serwera kontroli lub kontroli.

uprawnienie VIEW any DEFINITION zapewnia dostęp do przeglądania widoków audytu na poziomie serwera, a definicja widoku zapewnia dostęp do przeglądania widoków audytu na poziomie bazy danych. Odmowa tych uprawnień nadpisuje możliwość przeglądania widoków katalogu, nawet jeśli zleceniodawca ma zmienić dowolny audyt serwera lub zmienić uprawnienia audytu bazy danych.

aby uzyskać więcej informacji na temat przyznawania uprawnień, zobacz GRANT (Transact-SQL).

Uwaga

Dyrektorzy w roli sysadmin mogą manipulować dowolnym komponentem audytu, a ci w roli db_owner mogą manipulować specyfikacjami audytu w bazie danych. SQL Server Audit potwierdzi, że logowanie, które tworzy lub zmienia specyfikację audytu, ma co najmniej uprawnienia ALTER ANY DATABASE AUDIT. Jednak nie sprawdza się podczas dołączania bazy danych. Należy założyć, że wszystkie specyfikacje audytu bazy danych są tak samo wiarygodne, jak te zasady w roli sysadmin lub db_owner.

Utwórz specyfikację audytu serwera i audytu serwera

Utwórz specyfikację audytu serwera i audytu bazy danych

Wyświetl dziennik audytu serwera SQL

napisz zdarzenia audytu serwera SQL do dziennika zabezpieczeń

właściwości Serwera (strona bezpieczeństwa)
wyjaśnia, jak włączyć inspekcję logowania dla serwera SQL. Rekordy audytu są przechowywane w dzienniku aplikacji systemu Windows.

tryb audytu C2 Opcja konfiguracji serwera
wyjaśnia tryb audytu zgodności zabezpieczeń C2 w SQL Server.

Kategoria zdarzeń audytu bezpieczeństwa (SQL Server Profiler)
wyjaśnia zdarzenia audytu, których można użyć w SQL Server Profiler. Więcej informacji: SQL Server Profiler.

SQL Trace
wyjaśnia, w jaki sposób SQL Trace może być używany z poziomu własnych aplikacji do ręcznego tworzenia śladów, zamiast korzystania z SQL Server Profiler.

Wyzwalacze DDL
wyjaśnia, w jaki sposób można używać wyzwalaczy DDL (Data Definition Language) do śledzenia zmian w bazach danych.

Microsoft TechNet: SQL Server TechCenter: SQL Server 2005 Security and Protection
dostarcza aktualnych informacji na temat bezpieczeństwa SQL Server.

Zobacz także

grupy akcji i akcje audytu SQL Server
rekordy audytu SQL Server