Azure SQL Database és Azure Synapse Analytics ellenőrzése

A következőre vonatkozik: :Azure SQL DatabaseAzure Synapse Analytics

A Azure SQL Database és Azure Synapse Analytics naplózása nyomon követi az adatbázis-eseményeket, és egy naplóba írja őket a Azure tárfiókjában, Log Analytics munkaterületén vagy az Event Hubsban.

Auditálás is:

  • Segít a jogszabályi megfelelőség fenntartásában, az adatbázis-tevékenységek megértésében, valamint olyan eltérések és rendellenességek megismerésében, amelyek üzleti aggodalmakat vagy feltételezett biztonsági jogsértéseket jelezhetnek.

  • Engedélyezi és megkönnyíti a megfelelőségi szabványok betartását, bár nem garantálja a megfelelőséget. További információ: Microsoft Azure Adatvédelmi központ ahol megtalálja az SQL Database megfelelőségi tanúsítványainak legfrissebb listáját.

Jegyzet

Az Azure SQL Managed Instance naplózásával kapcsolatos információkért lásd: Bevezetés az Azure SQL Managed Instance naplózásába.

Áttekintés

Az SQL Database naplózása a következőre használható:

  • A kiválasztott események naplónaplójának megőrzése. Megadhatja a naplózandó adatbázisműveletek kategóriáit.
  • jelentés adatbázis-tevékenységről. Az előre konfigurált jelentések és irányítópultok használatával gyorsan megkezdheti a tevékenység- és eseményjelentést.
  • jelentések elemzése. Gyanús eseményeket, szokatlan tevékenységeket és trendeket találhat.

Fontos

Az Azure SQL Database, Azure Synapse Analytics SQL-készletek és Azure SQL Managed Instance naplózása a naplózott adatbázis vagy példány rendelkezésre állásához és teljesítményéhez van optimalizálva. A nagyon nagy tevékenység vagy magas hálózati terhelés időszakában a naplózási funkció lehetővé teheti a tranzakciók folytatását a naplózásra megjelölt összes esemény rögzítése nélkül.

A Azure SQL Database kiszolgálói naplózásának teljesítménybeli, rendelkezésre állási és megbízhatósági fejlesztései (2025. július – GA)

  • Az SQL Auditing fő részeinek újraépítése a kiszolgálói auditok nagyobb rendelkezésre állását és megbízhatóságát eredményezi. További előny, hogy jobban igazodnak a funkciók az SQL Serverhez és az Azure SQL Managed Instance-hez. Az adatbázis-naplózás változatlan marad.
  • Az előző naplózási terv egy adatbázisszintű naplózást indít el, és egy naplózási munkamenetet hajt végre a kiszolgálón lévő összes adatbázishoz. A naplózás új architektúrája egy kibővített esemény munkamenetet hoz létre a kiszolgáló szintjén, amely minden adatbázis naplózási eseményeit rögzíti.
  • Az új auditálási kialakítás optimalizálja a memóriát és a processzort, és összhangban van az auditálás működésével az SQL Serverben és az Azure SQL Managed Instance-ban.

A kiszolgálónaplózás újraarchitektúrájának változásai

  • A tárfiók mappaszerkezetének módosítása:
    • Az egyik elsődleges módosítás magában foglalja a tárfióktárolókban tárolt naplók mappastruktúrájának módosítását. Korábban a szerver audit naplókat külön mappákba írták; mindegyik adatbázis esetén a mappa az adatbázis nevével azonos nevet kapott. Az új frissítéssel az összes kiszolgálónapló egyetlen, címkével ellátott mappába lesz összesítve master. Ez a viselkedés ugyanaz, mint Azure SQL Managed Instance és SQL Server.
  • Az írásvédett replikák mappaszerkezetének módosítása:
    • Az írásvédett adatbázis-replikák korábban írásvédett mappában tárolták a naplóikat. Ezek a naplók most már a master mappába vannak írva. Ezeket a naplókat az új is_secondary_replica_trueoszlop szűrésével lehet lekérni.
  • Az auditnaplók megtekintéséhez szükséges engedélyek:
    • VIEW DATABASE SECURITY AUDIT engedély a felhasználói adatbázisban

A sok adatbázissal rendelkező környezetek esetében, amely nagy OLTP-számítási feladatokat futtat, a kiszolgálószintű naplózás alapértelmezett beállításokkal való használata nagyon nagy naplózási köteteket eredményezhet a logikai kiszolgálón. Mivel az összes adatbázis összes eseménye ugyanabba a naplózási mappába van írva, az egyetlen adatbázis naplóinak lekérdezése lassú és működési szempontból költséges lesz. A teljesítmény javítása és a zaj csökkentése:

  • Váltson adatbázisszintű naplózásra. Minden adatbázis a saját audit naplómappájába ír, így csökkenti a beolvasott teljes kötetet, és gyorsabbá teszi a visszakeresést.
  • Tekintse át az auditkonfigurációt. Határozza meg, hogy szükséges-e az összes kötegelt esemény rögzítése, vagy hogy egy egyéni szűrt konfiguráció megfelel-e a biztonsági és megfelelőségi követelményeknek.

Auditálási korlátozások

  • A naplózás engedélyezése a szüneteltetett Azure Synapse SQL-készleten nincs támogatva. A naplózás engedélyezéséhez indítsa újra a Synapse SQL-készlet.
  • A felhasználó által hozzárendelt felügyelt identitás (UAMI) használatával történő naplózás engedélyezése nem támogatott Azure Synapse.
  • A felügyelt identitások jelenleg nem támogatottak a Azure Synapse esetében, kivéve, ha a tárfiók virtuális hálózat vagy tűzfal mögött található.

Jegyzet

Az Azure Synapse Analytics esetében a VNet mögötti tárfiókra történő naplózáshoz a kiszolgáló rendszer-hozzárendelt felügyelt identitására van szükség a Storage Blob Data Contributor szerepkörrel. A Felhasználó által hozzárendelt felügyelt identitások (UAMI) nem támogatottak a Synapse-naplózáshoz. Ha ellenőriznie kell egy olyan tárfiókot, amely csak a Microsoft Entra hitelesítést használja, konfigurálja a kiszolgálón a rendszer által hozzárendelt felügyelt identitást, és adja meg neki a Storage Blob Data Contributor szerepkörét a céltárfiókon. További információért lásd: Naplózás írása a virtuális hálózat és a tűzfal mögötti tárfiókba.

  • A teljesítménykorlátozások miatt nem naplózzuk az és az tempdbideiglenes táblákat. Bár a kötegelt műveletcsoport ideiglenes táblákon rögzíti az utasításokat, előfordulhat, hogy nem megfelelően tölti ki az objektumneveket. A forrástábla azonban mindig naplózásra kerül, így biztosítva, hogy a forrástáblából az ideiglenes táblákba beszúrt összes beszúrás rögzítve legyen.

  • Az Azure Synapse SQL-készletek naplózása támogatja az alapértelmezett naplózási műveletcsoportokat only.

  • Ha egy logikai kiszolgáló auditálását konfigurálja az Azure-ban vagy az Azure SQL Database-ben, úgy, hogy a napló célhelye tárfiók, a hitelesítési módnak meg kell felelnie a tárfiók konfigurációjának. Ha a tárelérési kulcsokat hitelesítési típusként használja, a céltárfiókot engedélyezni kell a tárfiókkulcsokhoz való hozzáféréssel. Ha a tárfiók úgy van konfigurálva, hogy csak Microsoft Entra ID használjon hitelesítést (formerly Azure Active Directory), a naplózás konfigurálható úgy, hogy felügyelt identitásokat használjon a hitelesítéshez.

  • A naplózás nem támogatott azokban az adatbázisokban, amelyek neve tartalmazza a ? karaktert. Ez a szerver-szintű és adatbázis-szintű naplózásra is vonatkozik, mivel azok az adatbázisok, amelyek a nevükben ? szerepelnek, már nem támogatottak az Azure-on.

  • Azure SQL Database és Azure Synapse naplók legfeljebb 4000 karaktert rögzítenek a statement és data_sensitivity_information mezőkben. Ha egy naplózható művelet kimenete meghaladja ezt a korlátot, a rendszer az első 4000 karakternél hosszabb tartalmat csonkolja , és kizárja a naplózási rekordból.

Megjegyzések

  • A tevékenységnaplóban SQLDBControlPlaneFirstPartyApp által kezdeményezett események a Azure SQL Database vezérlősík belső Azure függvényei. A SQLDBControlPlaneFirstPartyApp által kezdeményezett események az SQL-motor és a Azure Resource Manager közötti belső szinkronizálási művelet részét képezik. Ezek az események a Azure SQL Database felügyeletének normál részét képezik, és a Azure megfelelő erőforrás-ábrázoláshoz és működéshez szükségesek.
  • Prémium tárolás a BlockBlobStorage segítségével támogatott. A szabványos tárolás támogatott. Ahhoz azonban, hogy a naplózási rendszer egy virtuális hálózat vagy tűzfal mögötti tárfiókba írjon, rendelkeznie kell egy általános célú v2-tárfiókkal. Ha egy általános célú v1- vagy Blob Storage-fiókkal rendelkezik, frissítse egy általános célú v2-tárfiókra. Konkrét útmutatásért lásd: Audit napló írása a VNet és tűzfal mögötti tárolási fiókba. Az Tárfiókok típusaipontban talál további információt.
  • Amikor az ügyfelek engedélyezik az SQL-naplózást, és kimenő hálózati korlátozásokat is konfigurálnak, engedélyezniük kell a naplózási tárfiók teljes tartományneveinek listáját, hogy a naplózási események sikeresen elérhessék a célhelyet. Ha a tárolási végpont nincs engedélyezve, a naplózási forgalom le lesz tiltva, ami eseményvesztést eredményez. Miután hozzáadta a szükséges tárfiók teljes tartományneveit az engedélyezési listához, az ügyfeleknek újra kell menteniük az auditálási konfigurációjukat a normál auditálási eseményfolyamat folytatásához.
  • Hierarchikus névtér támogatott minden típusú standard tárfiók és prémium tárfiók esetében a BlockBlobStorage használatával.
  • A naplók Append Blobs-ba kerülnek tárolásra az Ön Azure-előfizetésében található Azure Blob Storage-ban.
  • A naplók .xel formátumúak, és SQL Server Management Studio (SSMS) használatával nyithatóak meg.
  • Ha nem módosítható naplótárolót szeretne konfigurálni a kiszolgálói vagy adatbázisszintű naplózási eseményekhez, kövesse a Azure Storage által biztosított instrukciókat. Ha változatlan blobtárolót konfigurál a naplózáshoz, győződjön meg arról, hogy a védett hozzáfűzések írásának engedélyezése a hozzáfűző blobok vagy a Blokk és hozzáfűző blobok lehetőségre van állítva. A Nincs lehetőség nem támogatott. Az időalapú adatmegőrzési szabályzatok esetében a tárfiók megőrzési időközének rövidebbnek kell lennie, mint az SQL-naplózás megőrzési beállítása. Azok a konfigurációk, amelyekben a tárolási szabályzat be van állítva, de az 0SQL-naplózás megőrzése nem támogatott.
  • Auditnaplókat írhat egy virtuális hálózat vagy tűzfal mögött található Azure Storage-fiókba.
  • A naplóformátumról, a tármappa hierarchiájáról és az elnevezési konvenciókról az SQL Database naplóformátumának című cikkben találtovábbi információt.
  • Az írásvédett replikák használata az olvasási lekérdezések számítási feladatának átvitelére esetén az ellenőrzés automatikusan engedélyezve van. A tármappák hierarchiájáról, az elnevezési konvenciókról és a naplóformátumról további információt az SQL Database naplóformátumának című cikkben talál.
  • Microsoft Entra hitelesítés használatakor a sikertelen bejelentkezések rekordjai nem jelennek meg az SQL-naplóban. A sikertelen bejelentkezési naplórekordok megtekintéséhez meg kell látogatnia a Microsoft Entra admin center, amely naplózza az események részleteit.
  • Az átjáró a bejelentkezéseket arra a példányra irányítja, ahol az adatbázis található. Microsoft Entra bejelentkezések esetén a rendszer ellenőrzi a hitelesítő adatokat, mielőtt a felhasználóval megpróbál bejelentkezni a kért adatbázisba. Hiba esetén a kért adatbázis soha nem érhető el, ezért nem történik naplózás. SQL-bejelentkezések esetén a rendszer a kért adatokon ellenőrzi a hitelesítő adatokat, így azok ebben az esetben auditálhatók. A sikeres bejelentkezések, amelyek nyilvánvalóan elérik az adatbázist, mindkét esetben naplózásra kerülnek.
  • Miután konfigurálta a naplózási beállításokat, bekapcsolhatja az új fenyegetésészlelési funkciót, és beállíthatja az e-maileket a biztonsági riasztások fogadásához. Veszélyforrások észlelése esetén proaktív riasztásokat kap a rendellenes adatbázis-tevékenységekről, amelyek potenciális biztonsági fenyegetéseket jelezhetnek. További információ: SQL Advanced Threat Protection.
  • Miután a naplózást engedélyezve lévő adatbázist átmásolta egy másik logikai kiszolgálóra, előfordulhat, hogy e-mailt kap arról, hogy a naplózás sikertelen volt. Ez egy ismert probléma, és a naplózásnak a várt módon kell működnie az újonnan másolt adatbázisban.

Kapcsolódó tartalom

  • Last updated on