Controllo in Azure Synapse Analytics

Tip

Microsoft Fabric Data Warehouse è un data warehouse relazionale su scala aziendale su una base data lake, con un'architettura futura, un'intelligenza artificiale predefinita e nuove funzionalità. Se non si ha familiarità con il data warehousing, iniziare con Fabric Data Warehouse. I carichi di lavoro esistenti del pool SQL dedicated possono eseguire l'aggiornamento a Fabric per accedere a nuove funzionalità tra data science, analisi in tempo reale e creazione di report.

Il controllo di Azure Synapse Analytics tiene traccia degli eventi del database e li archivia in Archiviazione di Azure, un'area di lavoro di Monitoraggio di Azure Log Analytics o Hub eventi di Azure.

Il controllo consente di:

  • Conservare un audit trail di eventi selezionati.
  • Comprendere l'attività del database e indagare su discrepanze o anomalie.
  • Crea report sull'attività utilizzando query, workbook e strumenti di monitoraggio a valle.
  • Supportare i requisiti normativi e di conformità organizzativa. L'audit non garantisce la conformità di per sé.

Informazioni generali

È possibile usare il servizio di controllo del database SQL per eseguire le operazioni seguenti:

  • Conservare un audit trail degli eventi selezionati. È possibile definire categorie di azioni di database da controllare.
  • Report sulle attività del database. È possibile utilizzare report preconfigurati e una dashboard per iniziare rapidamente con il reporting di attività ed eventi.
  • Analizzare i rapporti. È possibile individuare eventi sospetti, attività insolite e tendenze.

Important

L'audit è ottimizzato per la disponibilità e le prestazioni del pool SQL. Durante periodi di attività molto elevata o carico di rete, le transazioni possono procedere senza che ogni evento selezionato venga registrato.

Per gli ambienti con molti database che eseguono carichi di lavoro OLTP pesanti, l'uso del controllo a livello di server con le impostazioni predefinite può portare a volumi di controllo molto grandi nel server logico. Poiché tutti gli eventi di tutti i database vengono scritti nella stessa cartella di controllo, l'esecuzione di query sui log di controllo per un singolo database diventa lenta e operativamente costosa. Per migliorare le prestazioni e ridurre il rumore:

  • Passare al controllo a livello di database. Ogni database scrive nella propria cartella del log di controllo, riducendo il volume totale analizzato e rendendo più veloce il recupero.
  • Esaminare la configurazione del controllo. Determinare se l'acquisizione di tutti gli eventi completati in batch è necessaria o se una configurazione filtrata personalizzata può soddisfare i requisiti di sicurezza e conformità.

Proteggere le informazioni sensibili nei log di audit

Il testo dell'istruzione sottoposta ad audit può contenere valori sensibili quando le applicazioni concatenano tali valori in SQL dinamico. Utilizzare parametri per i valori dei dati, evitare di inserire segreti o dati personali nel testo della query e limitare l'accesso ai registri di audit agli utenti autorizzati.

I permessi sulla destinazione di audit controllano l'accesso al di fuori del motore SQL. Applica il principio del privilegio minimo ad Archiviazione di Azure, Log Analytics e Event Hubs e monitora l'accesso a queste risorse.

Limitations

  • Non è possibile abilitare il controllo su un pool SQL dedicato sospeso. Riavvia il pool prima di attivare il criterio.
  • Le identità gestite assegnate dall'utente non sono supportate per l'audit in Azure Synapse Analytics.
  • Un'identità gestita assegnata al sistema è supportata per una destinazione Archiviazione di Azure quando l'account di archiviazione si trova dietro una rete virtuale o un firewall. Le identità gestite non sono supportate per Azure Synapse a meno che l'account di archiviazione non sia dietro una rete virtuale o un firewall.
  • I pool SQL di Synapse supportano solo i gruppi di azioni di audit predefiniti.
  • Il controllo non è supportato nei database con nomi che contengono il ? carattere . Questa limitazione si applica sia all'audit a livello server che a livello di database, poiché i database con ? nei loro nomi non sono più supportati su Azure.
  • I registri di audit memorizzano fino a 4.000 caratteri nei campi statement e data_sensitivity_information. I caratteri aggiuntivi vengono troncati.

Remarks

  • Gli eventi avviati da SQLDBControlPlaneFirstPartyApp nel log attività sono una funzione Azure interna del piano di controllo database SQL di Azure. Gli eventi avviati da SQLDBControlPlaneFirstPartyApp fanno parte di un'operazione di sincronizzazione interna tra il motore SQL e Azure Resource Manager. Questi eventi sono una parte normale della gestione di database SQL di Azure e sono necessari per la rappresentazione e l'operazione corrette delle risorse in Azure.
  • L'archiviazione Premium con BlockBlobStorage è supportata. L'archiviazione Standard è supportata. Tuttavia, per scrivere log di audit su un account di storage dietro una rete virtuale o un firewall, è necessario utilizzare un account di storage v2 a uso generale. Se usi un account generico v1 o un account gestione rete virtuale di Azure, aggiorna a un account di archiviazione generico v2. Per istruzioni specifiche, vedi Scrivi log di audit su un account di archiviazione dietro una rete virtuale e un firewall. Per altre informazioni, vedere Tipi di account di archiviazione.
  • Quando abiliti l'audit SQL e configuri le restrizioni di rete in uscita, devi inserire nell'elenco elementi consentiti i nomi di dominio completamente qualificati del tuo account di archiviazione per l'audit per garantire che gli eventi di audit possano raggiungere la destinazione. Se non inserisci nella allowlist l'endpoint di archiviazione, il traffico di audit viene bloccato, causando la perdita degli eventi di audit. Dopo aver aggiunto i FQDN richiesti dell'account di archiviazione alla lista dei permessi, devi salvare nuovamente la configurazione di audit per riprendere il normale flusso degli eventi di audit.
  • Lo spazio dei nomi gerarchico per tutti i tipi di account di archiviazione standard e l'account di archiviazione Premium con BlockBlobStorage è supportato.
  • I log di audit vengono scritti in Append Blobs in un Archiviazione BLOB di Azure sul tuo abbonamento Azure.
  • I log di controllo sono in formato .xel e possono essere aperti con SQL Server Management Studio (SSMS).
  • Per configurare un archivio log non modificabile per gli eventi di controllo a livello di server o di database, seguire le instructions fornite da Archiviazione di Azure. Quando si configura l'archiviazione BLOB non modificabile per il controllo, assicurarsi che Consenti scritture di accodamento protette sia impostato su BLOB di accodamento o BLOB di accodamento e blocco. L'opzione Nessuno non è supportata. Per i criteri di conservazione con base temporale, l'intervallo di conservazione dell'account di archiviazione deve essere inferiore all'impostazione di conservazione del controllo SQL. Le configurazioni in cui sono impostati i criteri di archiviazione, ma la conservazione del controllo SQL è 0, non sono supportate.
  • È possibile scrivere log di controllo in un account Archiviazione di Azure dietro una rete virtuale o un firewall.
  • Per dettagli sul formato del log, la gerarchia della cartella di archiviazione e le convenzioni di denominazione, vedi formato del log di controllo.
  • Quando si utilizza l'autenticazione di Microsoft Entra, i record degli accessi non riusciti non vengono visualizzati nel registro di audit SQL. Per visualizzare i record di audit degli accessi non riusciti, è necessario visitare l'interfaccia di amministrazione di Microsoft Entra, che registra i dettagli di questi eventi.
  • Dopo aver configurato le impostazioni di audit, puoi attivare la nuova funzione di rilevamento delle minacce e configurare le email per ricevere avvisi di sicurezza. Quando si usa il rilevamento delle minacce, si ricevono avvisi proattivi sulle attività anomale del database che possono indicare potenziali minacce per la sicurezza. Per altre informazioni, vedere SQL Advanced Threat Protection.
  • Dopo che un database con il controllo abilitato viene copiato in un altro server logico, è possibile che venga ricevuto un messaggio email che informa che il controllo non è riuscito. Questa condizione è un problema noto e l'audit dovrebbe funzionare come previsto sul database appena copiato.

Contenuti correlati

  • Ultimo aggiornamento: