Auditing in Azure Synapse Analytics

Wskazówka

Microsoft Fabric Data Warehouse to magazyn relacyjny w skali przedsiębiorstwa na podstawie bazy danych data lake z architekturą gotową do użycia w przyszłości, wbudowaną sztuczną inteligencją i nowymi funkcjami. Jeśli dopiero zaczynasz korzystać z magazynowania danych, zacznij od Fabric Data Warehouse. Istniejące obciążenia dedykowanej puli SQL mogą zostać zaktualizowane do Fabric, aby uzyskać dostęp do nowych możliwości w zakresie nauki o danych, analizy w czasie rzeczywistym i raportowania.

Audyt w usłudze Azure Synapse Analytics śledzi zdarzenia bazy danych i zapisuje je do Azure Storage, przestrzeni roboczej Azure Monitor Log Analytics lub Azure Event Hubs.

Audyt pomaga Ci:

  • Zachowaj rejestr audytu wybranych zdarzeń.
  • Zrozum aktywność bazy danych i zbadaj rozbieżności lub anomalie.
  • Raportuj aktywność, korzystając z zapytań, skoroszytów i narzędzi do monitorowania działań podrzędnych.
  • Wspierać wymagania dotyczące zgodności z przepisami i wymogami organizacyjnymi. Sam audyt nie gwarantuje zgodności z przepisami.

Overview

Inspekcja usługi SQL Database umożliwia:

  • Zachowaj dziennik inspekcji wybranych zdarzeń. Możesz zdefiniować kategorie akcji bazy danych, które mają być poddane inspekcji.
  • Raport dotyczący aktywności bazy danych. Możesz użyć wstępnie skonfigurowanych raportów i pulpitu nawigacyjnego, aby szybko rozpocząć pracę z raportowaniem aktywności i zdarzeń.
  • Analizowanie raportów. Możesz wyszukiwać podejrzane zdarzenia, nietypową aktywność i trendy.

Important

Audyt jest zoptymalizowany pod kątem dostępności i wydajności puli SQL. W okresach bardzo dużej aktywności lub obciążenia sieci transakcje mogą przebiegać bez rejestrowania każdego wybranego zdarzenia.

W przypadku środowisk z wieloma bazami danych z dużymi obciążeniami OLTP korzystanie z inspekcji na poziomie serwera z ustawieniami domyślnymi może prowadzić do bardzo dużych woluminów inspekcji na serwerze logicznym. Ponieważ wszystkie zdarzenia ze wszystkich baz danych są zapisywane w tym samym folderze inspekcji, wykonywanie zapytań dotyczących dzienników inspekcji dla pojedynczej bazy danych staje się powolne i kosztowne operacyjnie. Aby zwiększyć wydajność i zmniejszyć szum:

  • Przejdź do inspekcji na poziomie bazy danych. Każda baza danych zapisuje dane we własnym folderze dziennika inspekcji, zmniejszając łączną ilość skanowanego woluminu i przyspieszając pobieranie.
  • Przejrzyj konfigurację inspekcji. Ustal, czy przechwytywanie wszystkich zdarzeń ukończonych wsadowo jest konieczne, czy niestandardowa konfiguracja filtrowana może spełniać wymagania dotyczące zabezpieczeń i zgodności.

Chroń wrażliwe informacje w dziennikach audytowych

Tekst audytowanej instrukcji może zawierać wartości wrażliwe, gdy aplikacje łączą te wartości z dynamicznym SQL. Używaj parametrów dla wartości danych, unikaj osadzania sekretów lub danych osobowych w tekście zapytania oraz ograniczaj dostęp do rejestrów audytowych dla użytkowników uprawnionych.

Uprawnienia do celu audytu kontrolują dostęp poza silnikiem SQL. Stosuj zasadę najmniejszych uprawnień do Azure Storage, Log Analytics i Event Hubs oraz monitoruj dostęp do tych zasobów.

Limitations

  • Nie można włączyć inspekcji w wstrzymanej dedykowanej puli SQL. Wznów pulę przed włączeniem zasady.
  • Zarządzane tożsamości przypisane przez użytkownika nie są obsługiwane w audycie w Azure Synapse Analytics.
  • Obsługiwana jest tożsamość zarządzana przypisana systemowo dla celu Azure Storage, gdy konto pamięci znajduje się za siecią wirtualną lub zaporą sieciową. Zarządzane tożsamości nie są obsługiwane w Azure Synapse, chyba że konto pamięci masowej znajduje się za siecią wirtualną lub zaporą sieciową.
  • Pule SQL Synapse obsługują tylko domyślne grupy akcji audytu.
  • Audyt nie jest obsługiwany w bazach danych, których nazwy zawierają znak ?. To ograniczenie dotyczy zarówno audytów na poziomie serwera, jak i audytów na poziomie bazy danych, ponieważ bazy danych z ? w swoich nazwach nie są już wspierane w Azure.
  • Rejestry audytowe przechowują do 4 000 znaków w polach statement i data_sensitivity_information. Dodatkowe znaki zostały skrócone.

Remarks

  • Zdarzenia inicjowane przez SQLDBControlPlaneFirstPartyApp w dzienniku aktywności są wewnętrzną funkcją płaszczyzny sterowania Azure SQL Database. Zdarzenia inicjowane przez SQLDBControlPlaneFirstPartyApp są częścią wewnętrznej operacji synchronizacji między aparatem SQL a Azure Resource Manager. Te zdarzenia są normalną częścią zarządzania Azure SQL Database i są wymagane do prawidłowej reprezentacji zasobów i operacji w Azure.
  • Magazyn Premium z typem BlockBlobStorage jest obsługiwany. Obsługiwane jest przechowywanie standardowe. Jednak aby zapisywać logi audytowe na koncie pamięci za siecią wirtualną lub zaporą sieciową, musisz użyć konta magazynu Ogólnego przeznaczenia w wersji 2 (GPv2). Jeśli używasz konta uniwersalnego v1 lub Blob Storage, uaktualnij konto do konta ogólnego przeznaczenia v2. Szczegółowe instrukcje można znaleźć w artykule Zapisuj dzienniki inspekcji w koncie magazynu chronionym przez sieć wirtualną i zaporę. Aby uzyskać więcej informacji, zobacz Typy kont magazynowych.
  • Gdy włączasz audyt SQL i konfigurujesz ograniczenia sieci wychodzącej, musisz dodać do listy dozwolonych w pełni kwalifikowane nazwy domen swojego konta magazynu audytu, aby zdarzenia audytowe mogły dotrzeć do miejsca docelowego. Jeśli nie dodasz punktu końcowego magazynu do listy dozwolonych, ruch inspekcji jest blokowany, co skutkuje utratą zdarzeń inspekcji. Po dodaniu wymaganych FQDN kont pamięci do listy zezwoleń musisz ponownie zapisać konfigurację audytu, aby wznowić normalny przepływ zdarzeń audytowych.
  • Hierarchiczna przestrzeń nazw dla wszystkich typów konta magazynu standardowego i konta magazynu premium z BlockBlobStorage jest obsługiwana.
  • Logi audytu są zapisywane do Append Blobs w usłudze Azure Blob Storage w ramach Twojej subskrypcji platformy Azure.
  • Dzienniki inspekcji są w formacie xel i można je otworzyć za pomocą programu SQL Server Management Studio (SSMS).
  • Aby skonfigurować niezmienny magazyn dzienników dla zdarzeń inspekcji na poziomie serwera lub bazy danych, postępuj zgodnie z instrukcjami dostarczonymi przez usługę Azure Storage. Podczas konfigurowania niezmiennego kontenera obiektów blob na potrzeby inspekcji upewnij się, że opcja Zezwalaj na chronione dołączanie jest ustawiona na dopuszczalne do dołączania obiekty blob lub Blokowe oraz dopuszczalne do dołączania obiekty blob. Opcja Brak nie jest obsługiwana. W przypadku zasad przechowywania opartych na czasie, interwał przechowywania konta pamięci masowej musi być krótszy niż ustawienie przechowywania inspekcji SQL. Konfiguracje, w których ustawiono politykę przechowywania, ale retencja inspekcji SQL wynosi 0, nie są obsługiwane.
  • Dzienniki inspekcji można zapisywać na koncie usługi Azure Storage za siecią wirtualną lub zaporą.
  • Szczegóły dotyczące formatu dziennika, hierarchii folderu pamięci oraz konwencji nazewnictwa można znaleźć w artykule Format dziennika audytu.
  • W przypadku korzystania z uwierzytelniania Microsoft Entra, rekordy nieudanych logowań nie są wyświetlane w dzienniku inspekcji SQL. Aby wyświetlić rekordy inspekcji nieudanych logowań, należy odwiedzić centrum administracyjne firmy Microsoft Entra, które rejestruje szczegóły tych zdarzeń.
  • Po skonfigurowaniu ustawień audytu możesz włączyć nową funkcję wykrywania zagrożeń i skonfigurować e-maile tak, aby otrzymywały alerty bezpieczeństwa. Podczas korzystania z wykrywania zagrożeń otrzymujesz proaktywne alerty dotyczące nietypowych działań w bazie danych, które mogą wskazywać na potencjalne zagrożenia bezpieczeństwa. Aby uzyskać więcej informacji, zobacz SQL Advanced Threat Protection.
  • Po skopiowaniu bazy danych z włączoną inspekcją na inny serwer logiczny możesz otrzymać e-mail z powiadomieniem o niepomyślnym zakończeniu inspekcji. Ten stan jest znanym problemem i audyt powinien działać zgodnie z oczekiwaniami na nowo skopiowanej bazie danych.

Treści powiązane

  • Ostatnia aktualizacja o