Controllo per il database SQL in Fabric

si applica a:✅database SQL in Microsoft Fabric

Il controllo per i database SQL in Fabric è una funzionalità critica per la sicurezza e la conformità che consente alle organizzazioni di tenere traccia e registrare le attività del database. Il controllo supporta la conformità, il rilevamento delle minacce e le indagini forensi aiutando a rispondere a domande come chi ha eseguito l'accesso ai dati, quando e come.

Che cos'è il controllo SQL?

Il controllo SQL si riferisce al processo di acquisizione e archiviazione di eventi correlati all'attività del database. Questi eventi includono l'accesso ai dati, le modifiche dello schema, le modifiche alle autorizzazioni e i tentativi di autenticazione.

In Infrastruttura il controllo funziona a livello di database e supporta:

  • Monitoraggio della conformità (ad esempio: HIPAA, SOX)
  • Indagini sulla sicurezza
  • Informazioni operative

Obiettivo dell'audit

I log di controllo vengono scritti in una cartella di sola lettura in OneLake e possono essere sottoposti a query usando la sys.fn_get_audit_file_v2 funzione T-SQL o OneLake Explorer.

Per il database SQL in Fabric, i log di controllo vengono archiviati in OneLake: https://onelake.blob.fabric.microsoft.com/{workspace_id}/{artifact_id}/Audit/sqldbauditlogs/

Questi log non sono modificabili e accessibili agli utenti con autorizzazioni appropriate. È anche possibile scaricare i log usando OneLake Explorer o Azure Storage Explorer.

Fatturazione

Attualmente, la scrittura dei log di controllo in Fabric OneLake non comporta costi aggiuntivi e l'archiviazione è inclusa come parte dei limiti di archiviazione OneLake della capacità.

Opzioni di configurazione

Per impostazione predefinita, l'opzione Controlla tutto acquisisce tutti gli eventi, inclusi i completamenti batch e l'autenticazione riuscita e non riuscita.

Per essere più selettivi, scegliere tra scenari di controllo preconfigurati, ad esempio: modifiche alle autorizzazioni e tentativi di accesso, letture e scritture di dati e/o modifiche dello schema.

Ogni scenario preconfigurato è associato a gruppi di azioni di controllo specifici, ad esempio SCHEMA_OBJECT_ACCESS_GROUP, DATABASE_PRINCIPAL_CHANGE_GROUP. È anche possibile scegliere gli eventi da controllare in Eventi personalizzati. È possibile selezionare singoli gruppi di azioni per personalizzare il controllo in base alle proprie esigenze. Questa opzione è ideale per le organizzazioni con criteri di sicurezza interni rigorosi.

Per filtrare le query di accesso comuni o note, è possibile fornire espressioni di predicato in Transact-SQL (T-SQL) per filtrare gli eventi di controllo in base alle condizioni (ad esempio, per escludere istruzioni SELECT): WHERE statement NOT LIKE '%select%'.

Permissions

Per gestire il controllo usando i ruoli di Fabric workspace (scelta consigliata), è necessario avere l'appartenenza al ruolo Collaboratore di Fabric workspace o autorizzazioni superiori.

Per gestire il controllo con le autorizzazioni SQL:

  • Per configurare il controllo del database, è necessario disporre dell'autorizzazione ALTER ANY DATABASE AUDIT.
  • Per visualizzare i log di controllo tramite T-SQL, è necessario disporre dell'autorizzazione VIEW DATABASE SECURITY AUDIT.

Retention

Per impostazione predefinita, i dati di controllo vengono conservati a tempo indeterminato, a meno che non si configuri un periodo di conservazione personalizzato per eliminare automaticamente i log dopo questa durata.

Fabric archivia attualmente i log di controllo nella cartella dell'elemento in OneLake e li associa al ciclo di vita dell'elemento. Se si elimina l'elemento, Fabric elimina anche i log di controllo. Qualora fosse necessaria la conservazione indipendente dal ciclo di vita dell'elemento, spostare i log di controllo in un percorso di archiviazione separato (ad esempio, un altro Lakehouse o un account Archiviazione di Azure) usando strumenti come AzCopy o SSDT.

Conservazione delle impostazioni dopo il ripristino

Dopo un'operazione di ripristino, le impostazioni di controllo vengono mantenute, ma il controllo deve essere riabilitato in Fabric database SQL. Nel portale di Fabric aprire Gestisci controllo SQL, selezionare Save.

Configurare l'auditing per il database SQL dal portale Fabric

Per iniziare il controllo per un database SQL di Fabric:

  1. Passare a e aprire il database SQL nel portale di Fabric.
  2. Dal menu principale selezionare la scheda Sicurezza , quindi selezionare Gestisci controllo SQL. Screenshot del portale Fabric, che mostra la scheda Sicurezza e il pulsante Gestisci verifica SQL.
  3. Viene visualizzato il riquadro Gestisci controllo SQL .
  4. Selezionare il pulsante Salva eventi nei log di controllo SQL per abilitare il controllo.
  5. Configurare gli eventi da registrare nella sezione Eventi di database . Scegliere Controlla tutto (impostazione predefinita) per acquisire tutti gli eventi.
  6. Facoltativamente, configurare un criterio di conservazione in Conservazione.
  7. Facoltativamente, configurare un'espressione di predicato di comandi T-SQL da ignorare nel campo Espressione predicato .
  8. Seleziona Salva.

Consultare i log di audit

È possibile eseguire query sui log di controllo usando le funzioni T-SQL sys.fn_get_audit_file e sys.fn_get_audit_file_v2.

Nello script seguente è necessario specificare l'ID e l'ID database dell'area di lavoro. Entrambi si trovano nell'URL del portale Fabric. Ad esempio: https://fabric.microsoft.com/groups/<fabric workspace id>/sqldatabases/<fabric sql database id>. La prima stringa di identificatore unico nell'URL è l'ID dello spazio di lavoro Fabric, e la seconda stringa di identificatore unico è l'ID del database SQL.

  • Sostituire <fabric_workspace_id> con l'ID dell'area di lavoro Fabric. È possibile trovare l'ID di un'area di lavoro nell'URL, è la stringa univoca all'interno di due / caratteri dopo /groups/ nella finestra del browser.
  • Sostituire <fabric sql database id> con il database SQL nell'ID del database Fabric. È possibile trovare l'ID dell'elemento di database nell'URL, ovvero la stringa univoca all'interno di due / caratteri dopo /sqldatabases/ nella finestra del browser.

Per esempio:

SELECT * FROM sys.fn_get_audit_file_v2(
  'https://onelake.blob.fabric.microsoft.com/<fabric workspace id>/<fabric sql database id>/Audit/sqldbauditlogs/',
  DEFAULT, DEFAULT, DEFAULT, DEFAULT );

In questo esempio vengono recuperati i log di controllo tra 2025-11-17T08:40:40Z e 2025-11-17T09:10:40Z.

SELECT *
FROM sys.fn_get_audit_file_v2(
    'https://onelake.blob.fabric.microsoft.com/<fabric workspace id>/<fabric sql database id>/Audit/sqldbauditlogs/',
    DEFAULT,
    DEFAULT,
    '2025-11-17T08:40:40Z',
    '2025-11-17T09:10:40Z')

Per altre informazioni, vedere sys.fn_get_audit_file e sys.fn_get_audit_file_v2.

Gestire il controllo con l'API REST

È anche possibile visualizzare e configurare le impostazioni di controllo del database SQL a livello di codice usando l'API REST di Infrastruttura. L'API REST consente di gestire il controllo in modo coerente in tutti i database in un'area di lavoro usando script di PowerShell.

Per altre informazioni, vedere Gestire il controllo del database SQL con l'API REST.

Proteggere le informazioni sensibili nei log di audit

Quando costruisci SQL dinamico concatenando i valori di input direttamente nell'istruzione SQL, quei valori diventano parte del testo dell'affermazione. Se auditi l'estratto conto, il registro di audit potrebbe raccogliere informazioni sensibili incluse nel testo dell'estratto conto.

Per ridurre il rischio di esporre informazioni sensibili, segui queste pratiche:

  • Evita SQL dinamico per operazioni che contengono valori sensibili

    Per operazioni amministrative sensibili alla sicurezza, evitare di costruire istruzioni concatenando valori sensibili in SQL dinamico. Quando possibile, utilizza istruzioni SQL native o altri approcci che impediscano che valori sensibili vengano incorporati direttamente nel testo dell'affermazione.

    Le istruzioni SQL dinamiche costruite da stringhe accessibili dall'utente rendono anche le tue applicazioni vulnerabili agli attacchi di iniezione SQL. SQL injection è un attacco in cui il codice malevolo viene inserito in stringhe che poi vengono passate al database per l'analisi e l'esecuzione. Devi testare qualsiasi procedura che costruisca T-SQL per vulnerabilità di iniezione SQL, perché il motore di database esegue tutte le query sintatticamente valide che riceve. Usa parametri per i valori dei dati e non concatenare mai i valori dei parametri al testo della query. I valori correttamente parametrizzati sono trattati come dati piuttosto che come sintassi SQL eseguibile.

  • Limitare l'accesso ai log di audit

    Limitare l'accesso ai log di audit agli utenti autorizzati e agli amministratori. All'interno del SQL motore di database, i permessi SQL regolano l'accesso all'audit all'interno del SQL motore di database e possono variare a seconda della piattaforma e dell'ambito di revisione. Segui il principio del privilegio minimo e concedi solo i permessi necessari per gestire o esaminare le informazioni di audit. Esistono modelli di permessi di audit separati a livello di server e database, e database SQL di Azure si differenzia da SQL Server per la disponibilità di permessi a livello di server. Limitare l'accesso ai dati di audit aiuta a ridurre il rischio di divulgazione non autorizzata quando informazioni sensibili sono presenti negli eventi di audit registrati.

    L'accesso ai log di audit al di fuori di SQL motore di database dipende dai permessi nella destinazione configurata (come OneLake). Segui il principio del privilegio minimo e concedi solo i permessi necessari per gestire o esaminare le informazioni di audit.

Contenuti correlati

  • Last updated on