Auditování pro Azure SQL Database a Azure Synapse Analytics

Se vztahuje na:Azure SQL DatabaseAzure Synapse Analytics

Auditování pro Azure SQL Database a Azure Synapse Analytics sleduje události databáze a zapisuje je do protokolu auditu v účtu úložiště Azure, Log Analytics pracovním prostoru nebo službě Event Hubs.

Auditování také:

  • Pomáhá zajistit dodržování předpisů, porozumět databázové aktivitě a získat přehled o nesrovnalostech a anomáliích, které můžou značit problémy obchodního charakteru nebo vzbuzovat podezření na narušení zabezpečení.

  • Umožňuje a usnadňuje dodržování předpisů, i když soulad s těmito standardy nezaručuje. Další informace najdete v centru zabezpečení Microsoft Azure kde najdete nejnovější seznam certifikací dodržování předpisů služby SQL Database.

Poznámka:

Informace o auditování Azure SQL Managed Instance najdete v části Začínáme s auditováním Azure SQL Managed Instance.

Přehled

Auditování služby SQL Database můžete použít k:

  • Zachovejte záznam auditu vybraných událostí. Můžete definovat kategorie databázových akcí, které se mají auditovat.
  • Zpráva o databázové aktivitě Můžete využít předkonfigurované sestavy a řídicí panel pro rychlý začátek s reportováním aktivit a událostí.
  • Analyzujte sestavy Můžete vyhledávat podezřelé události, neobvyklé aktivity a trendy.

Důležité

Auditování pro Azure SQL Database, SQL fondy Azure Synapse Analytics a Azure SQL Managed Instance je optimalizované pro dostupnost a výkon databáze nebo instance, která je auditována. Během období velmi vysoké aktivity nebo vysokého zatížení sítě může funkce auditování umožnit transakcím pokračovat bez zaznamenávání všech událostí označených pro auditování.

Vylepšení výkonu, dostupnosti a spolehlivosti v auditování serverů pro Azure SQL Database (ga z července 2025)

  • Přepracované hlavní části auditování SQL vedou ke zvýšení dostupnosti a spolehlivosti auditů serverů. Další výhodou je sladění funkcí s SQL Server a Azure SQL Managed Instance. Auditování databáze zůstává beze změny.
  • Předchozí návrh auditování aktivuje audit na úrovni databáze a provede jednu relaci auditu pro každou databázi na serveru. Nová architektura auditování vytvoří jednu rozšířenou relaci událostí na úrovni serveru, která zachycuje události auditu pro všechny databáze.
  • Nový návrh auditování optimalizuje paměť a procesor a je konzistentní s tím, jak auditování funguje v SQL Server a Azure SQL Managed Instance.

Změny z opětovné architektury auditování serverů

  • Změna struktury složek pro účet úložiště:
    • Jednou z hlavních změn je úprava struktury složek pro protokoly auditu, které jsou uloženy v kontejnerech účtů úložiště. Dříve se protokoly auditu serveru zapisovaly do samostatných složek; jednu pro každou databázi s názvem databáze, který slouží jako název složky. Při nové aktualizaci se všechny protokoly auditu serveru konsolidují do jedné složky s popiskem master. Toto chování je stejné jako Azure SQL Managed Instance a SQL Server.
  • Změna struktury složek pro repliky jen pro čtení:
    • Repliky databáze jen pro čtení dříve měly své protokoly uložené ve složce jen pro čtení. Tyto protokoly jsou teď zapsány do master složky. Tyto protokoly můžete načíst filtrováním nového sloupce is_secondary_replica_true.
  • Oprávnění požadovaná k zobrazení protokolů auditu:
    • VIEW DATABASE SECURITY AUDIT oprávnění v uživatelské databázi

U prostředí s mnoha databázemi, na kterých běží velké úlohy OLTP, může použití auditování na úrovni serveru s výchozím nastavením vést k velmi velkým svazkům auditu na logickém serveru. Vzhledem k tomu, že všechny události ze všech databází se zapisují do stejné složky auditu, dotazování protokolů auditu jedné databáze se zpomalí a stane se náročným na provozní zdroje. Zvýšení výkonu a snížení šumu:

  • Přepněte na auditování na úrovni databáze. Každá databáze zapisuje do vlastní složky protokolu auditu, čímž se sníží celkový objem skenování a urychlí načítání dat.
  • Zkontrolujte konfiguraci auditu. Určete, jestli je potřeba zachytávat všechny události dokončené dávkou, nebo jestli může vlastní filtrovaná konfigurace splňovat vaše požadavky na zabezpečení a soulad s předpisy.

Omezení auditování

  • Povolení auditování pozastaveného fondu SQL Azure Synapse se nepodporuje. Pokud chcete povolit auditování, obnovte fond Synapse SQL.
  • Povolení auditování pomocí spravované identity přiřazené uživatelem (UAMI) se na Azure Synapse nepodporuje.
  • V současné době nejsou spravované identity pro Azure Synapse podporovány, pokud účet úložiště není za virtuální sítí nebo bránou firewall.

Poznámka:

Pro Azure Synapse Analytics vyžaduje auditování účtu úložiště za virtuální sítí spravovanou identitu přiřazenou systémem s rolí Storage Blob Data Contributor. Spravované identity přiřazené uživatelem (UAMI) nejsou podporované pro auditování Synapse. Pokud potřebujete provést audit účtu úložiště, který používá pouze ověřování Microsoft Entra, nakonfigurujte systémem přiřazenou spravovanou identitu na serveru a udělte jí roli Přispěvatele dat objektů blob služby Storage v cílovém účtu úložiště. Další informace najdete v tématu Zápis auditu do účtu úložiště v rámci virtuální sítě a brány firewall.

  • Kvůli omezením výkonu neauditujeme tempdbdočasné tabulky. Zatímco dávková dokončená skupina akcí zachycuje příkazy proti dočasným tabulkám, nemusí správně naplnit názvy objektů. Zdrojová tabulka se ale vždy audituje a zajišťuje, aby se zaznamenávaly všechny vložení ze zdrojové tabulky do dočasných tabulek.

  • Auditování fondů SQL Azure Synapse podporuje pouze výchozí skupiny akcí auditu.

  • Když nakonfigurujete auditování pro logický server v Azure nebo Azure SQL Database s cílem protokolu jako účtem úložiště, musí režim ověřování odpovídat konfiguraci daného účtu úložiště. Pokud jako typ ověřování používáte přístupové klíče úložiště, musí být cílový účet úložiště povolený s přístupem k klíčům účtu úložiště. Pokud je účet úložiště nakonfigurovaný tak, aby používal pouze ověřování s Microsoft Entra ID (formerly Azure Active Directory), je možné auditování nakonfigurovat tak, aby používalo spravované identity pro ověřování.

  • Auditování není u databází s názvy obsahujícími ? tento znak podporováno. To platí jak pro auditování na úrovni serveru, tak na úrovni databáze, protože databáze s ? ve svých názvech již nejsou na platformě Azure podporovány.

  • Azure SQL Database a Azure Synapse protokoly auditu zaznamenávají až 4 000 znaků v polích statement a data_sensitivity_information. Pokud výstup z auditovatelné akce tento limit překročí, veškerý obsah nad rámec prvních 4 000 znaků se zkrátí a vyloučí ze záznamu auditu.

Poznámky

  • Události iniciované SQLDBControlPlaneFirstPartyApp v protokolu aktivit jsou interní funkcí řídicí roviny služby Azure SQL Database. Události iniciované SQLDBControlPlaneFirstPartyApp jsou součástí interní synchronizační operace mezi modulem SQL a Azure Resource Manager. Tyto události jsou normální součástí správy Azure SQL Database a jsou vyžadovány pro správnou reprezentaci a provoz prostředků v Azure.
  • Premium storage je podporováno s BlockBlobStorage. Podporuje se úložiště úrovně Standard. Pokud ale chcete auditovat zápisy do účtu úložiště za virtuální sítí nebo bránou firewall, musíte mít účet úložiště pro obecné účely verze 2. Pokud máte účet pro obecné účely verze 1 nebo Blob Storage, přejděte na účet úložiště pro obecné účely verze 2. Konkrétní pokyny najdete v části Zápis auditu do účtu úložiště za virtuální sítí a bránou firewall. Další informace najdete v tématu Typy úložiště účtů.
  • Když zákazníci povolí auditování SQL a také nakonfigurují omezení odchozích sítí , musí povolit seznam plně kvalifikovaných názvů domén účtu úložiště auditování, aby se zajistilo úspěšné dosažení cíle událostí auditu. Pokud koncový bod úložiště není na povoleném seznamu, zablokuje se auditní komunikace, což vede ke ztrátě auditních událostí. Po přidání požadovaných plně kvalifikovaných názvů domén účtu úložiště do seznamu povolených musí zákazníci znovu uložit konfiguraci auditování, aby obnovili normální tok událostí auditu.
  • Hierarchický obor názvů je podporován pro všechny typy standardních účtů úložiště a prémiových účtů úložiště s BlockBlobStorage.
  • Protokoly auditu se zapisují do Append Blobs v Azure Blob Storage ve vašem předplatném Azure
  • Protokoly auditu jsou ve formátu .xel a lze je otevřít pomocí SQL Server Management Studio (SSMS).
  • Pokud chcete nakonfigurovat neměnné úložiště protokolů pro události auditu na úrovni serveru nebo databáze, postupujte podle pokynů instrukcí poskytovaných Azure Storage. Při konfiguraci neměnného úložiště blobů pro auditování se ujistěte, že volba Povolit chráněné přídatné zápisy je nastavena na přídatné objekty nebo blokové a přídatné objekty. Možnost Žádné není podporována. V případě časově řízených zásad uchovávání musí být interval uchovávání účtu úložiště kratší než nastavení uchovávání pro auditování SQL. Konfigurace, ve kterých jsou nastavené zásady úložiště, ale uchovávání auditu SQL se 0 nepodporuje.
  • Protokoly auditu můžete zapisovat do účtu Azure Storage za virtuální sítí nebo bránou firewall.
  • Podrobnosti o formátu protokolu, hierarchii složky úložiště a konvencích vytváření názvů najdete v článku formát protokolu auditu služby SQL Database.
  • Auditování při použití replik pouze pro čtení k odlehčení zpracování dotazů je automaticky povoleno. Další informace o hierarchii složek úložiště, konvencích vytváření názvů a formátu protokolu najdete v článku Formát protokolu auditu služby SQL Database.
  • Při použití ověřování Microsoft Entra se v protokolu auditu SQL nezobrazují záznamy neúspěšných přihlášení don. Pokud chcete zobrazit neúspěšné záznamy auditu přihlášení, musíte navštívit Microsoft Entra admin center, které protokolují podrobnosti o těchto událostech.
  • Brána směruje přihlášení do konkrétní instance, ve které se databáze nachází. Při přihlášeních Microsoft Entra se přihlašovací údaje ověřují před pokusem o přihlášení k požadované databázi pomocí daného uživatele. V případě selhání nedojde k přístupu k požadované databázi, a proto nedojde k auditování. Při přihlášeních SQL se přihlašovací údaje ověřují na požadovaných datech, takže v tomto případě je možné je auditovat. Úspěšná přihlášení, která se zjevně zapisují do logu v databázi, se v obou případech auditují.
  • Po dokončení konfigurace nastavení auditování můžete zapnout novou funkci detekce hrozeb a nakonfigurovat e-maily, na které budou přicházet upozornění zabezpečení. Pokud využijete detekci hrozeb, budete dostávat proaktivní upozornění na neobvyklé databázové aktivity, které můžou značit potenciální ohrožení zabezpečení. Další informace najdete v tématu SQL Advanced Threat Protection.
  • Po zkopírování databáze s povoleným auditováním na jiný logický server můžete obdržet e-mail s oznámením, že audit selhal. Jedná se o známý problém a auditování by mělo fungovat podle očekávání u nově zkopírované databáze.

Související obsah

  • Last updated on