Controllo per il database SQL di Azure e Azure Synapse Analytics

Si applica a:Database SQL di AzureAzure Synapse Analytics

Il controllo per Database SQL di Azure e Azure Synapse Analytics consente di tenere traccia degli eventi che si verificano nei database e di registrarli in un log di controllo nell'account di Archiviazione di Azure, nell'area di lavoro Log Analytics o in Hub eventi.

Inoltre, il servizio di controllo:

• Consente di gestire la conformità alle normative, ottenere informazioni sull'attività del database e rilevare discrepanze e anomalie che possono indicare problemi aziendali o possibili violazioni della sicurezza.

• Supporta e facilita il rispetto degli standard di conformità, pur non garantendo la conformità. Per altre informazioni, visitare il Centro protezione di Microsoft Azure, dove è possibile trovare l'elenco più aggiornato di certificazioni di conformità del database SQL.

Panoramica

È 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.
• Creare report sulle attività del database. È possibile usare i report preconfigurati e un dashboard per iniziare rapidamente a usare l’attività e la segnalazione di eventi.
• Analizzare i report. È possibile individuare eventi sospetti, attività insolite e tendenze.

Limitazioni del controllo

• L'abilitazione del controllo in un pool SQL di Azure Synapse in pausa non è supportata. Per abilitare il controllo, riprendere il pool di Synapse SQL.
• L'abilitazione del controllo tramite l'identità gestita assegnata dall'utente (UAMI) non è supportata in Azure Synapse.
• Attualmente, le identità gestite non sono supportate per Azure Synapse, a meno che l'account di archiviazione non si trovi dietro una rete virtuale o un firewall.
• Il controllo per i pool SQL di Azure Synapse supporta solo i gruppi di azioni di controllo predefiniti.
• Quando si configura il controllo per un server logico in Azure o database SQL di Azure con la destinazione del log come account di archiviazione, la modalità di autenticazione deve corrispondere alla configurazione per l'account di archiviazione. L'account di archiviazione di destinazione deve essere abilitato con l'accesso alle chiavi dell'account di archiviazione, se si usano chiavi di accesso alle risorse di archiviazione come tipo di autenticazione. Se l'account di archiviazione è configurato in modo da usare solo l'autenticazione con Microsoft Entra ID (precedentemente Azure Active Directory), il controllo può essere configurato per l'uso delle identità gestite per l'autenticazione.

Osservazioni:

• L'archiviazione Premium con BlockBlobStorage è supportata. L'archiviazione Standard è supportata. Tuttavia, per consentire al controllo di eseguire la scrittura in un account di archiviazione protetto da una rete virtuale o un firewall, è necessario disporre di un account di archiviazione per utilizzo generico v2. Se si dispone di un account di archiviazione per utilizzo generico v1 o un account di archiviazione BLOB, eseguire l’aggiornamento a un account di archiviazione per utilizzo generico v2. Per le istruzioni specifiche, vedere Controllo per la scrittura in un account di archiviazione dietro rete virtuale e firewall. Per altre informazioni, vedere Tipi di account di archiviazione.
• 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 controllo vengono scritti in Accodare BLOB in una risorsa di archiviazione BLOB di Azure nell'account di archiviazione
• I log di controllo sono in formato .xel e possono essere aperti con SQL Server Management Studio (SSMS).
• Per configurare un archivio di log non modificabile per gli eventi di controllo a livello di server o di database, seguire le istruzioni fornite da Archiviazione di Azure. Assicurarsi di aver selezionato Consenti accodamenti aggiuntivi quando si configura l'archiviazione BLOB non modificabile.
• È possibile scrivere i log di controllo in un account di archiviazione di Azure dietro una rete virtuale o un firewall.
• Per dettagli sul formato dei log, sulla gerarchia della cartella di archiviazione e sulle convenzioni di denominazione, vedere le informazioni di riferimento sul formato dei log del controllo BLOB.
• Il controllo sulle repliche di sola lettura viene abilitato automaticamente. Per altre informazioni sulla gerarchia delle cartelle di archiviazione, le convenzioni di denominazione e il formato dei log, vedere Formato dei log di controllo di Database SQL.
• Quando si usa l'autenticazione di Microsoft Entra, i record degli accessi non riusciti non vengono visualizzati nel log di controllo 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.
• Gli accessi vengono instradati dal gateway all'istanza specifica in cui si trova il database. Con gli accessi di Microsoft Entra, le credenziali vengono verificate prima di provare a usare l'utente per accedere al database richiesto. In caso di errore, non viene mai eseguito l'accesso al database richiesto, quindi non si verifica alcun controllo. Con gli accessi SQL, le credenziali vengono verificate nei dati richiesti, quindi in questo caso è possibile eseguire il controllo. Gli accessi riusciti, che ovviamente raggiungono il database, vengono controllati in entrambi i casi.
• Dopo aver configurato le impostazioni di controllo, è possibile attivare la nuova funzionalità di rilevamento delle minacce e configurare gli indirizzi di posta elettronica per ricevere gli 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 Introduzione al rilevamento delle minacce.
• 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. Si tratta di un problema già noto e il controllo dovrebbe funzionare come previsto nel database appena copiato.

Passaggi successivi

Vedi anche

• Episodio di Data Exposed Novità del controllo di Azure SQL
• Controllo per Istanza gestita di SQL
• Controllo per SQL Server