Crea processi KQL nel data lake di Microsoft Sentinel

I processi KQL sono query KQL una tantum o pianificate eseguite sui dati presenti nel data lake di Microsoft Sentinel e nelle tabelle federate. Usare i processi per scenari investigativi e analitici, ad esempio:

  • Query di lunga durata eseguite una sola volta per le indagini sugli incidenti e la risposta agli incidenti (IR)
  • Attività di aggregazione dei dati a supporto dei flussi di lavoro di arricchimento basati su log a bassa fedeltà
  • Scansioni di corrispondenza con threat intelligence (TI) storica per l'analisi retrospettiva
  • Scansioni del rilevamento delle anomalie che identificano modelli insoliti tra più tabelle

I processi KQL sono particolarmente efficaci quando le query usano operazioni di join o di union su set di dati diversi. Prima di iniziare, assicurati di soddisfare i prerequisiti, tra cui l'onboarding di Data Lake e le autorizzazioni necessarie.

Usa i job per promuovere i dati dal livello data lake al livello analytics. Una volta nel livello Analisi, usa l'editor KQL di ricerca avanzata per interrogare i dati. La promozione dei dati al livello di analisi offre i vantaggi seguenti:

  • Combinare i dati correnti e cronologici nel livello di analisi o da tabelle federate per eseguire modelli di analisi avanzata e di Machine Learning sui dati.
  • Ridurre i costi delle query eseguendole nel tier di analisi.
  • Combinare i dati da più aree di lavoro a una singola area di lavoro nel livello di analisi.
  • Combinare i dati Microsoft Entra ID, Microsoft 365 e Microsoft Resource Graph nel livello di analisi per eseguire analisi avanzate tra origini dati.

Nota

L'archiviazione nel livello di analisi comporta tariffe di fatturazione più elevate rispetto al livello data lake. Per ridurre i costi, promuovere solo i dati che è necessario analizzare ulteriormente. Usa KQL nella tua query per selezionare solo le colonne di cui hai bisogno e filtrare i dati, così da ridurre la quantità di dati inoltrati al livello analitico.

È possibile alzare di livello i dati a una nuova tabella o accodare i risultati a una tabella esistente nel livello di analisi. Quando si crea una nuova tabella, il nome della tabella viene suffisso con _KQL_CL per indicare che la tabella è stata creata da un processo KQL.

Facoltativamente, è possibile scrivere l'output di un processo KQL in un'altra tabella nel livello data lake per velocizzare l'analisi o usare i dati arricchiti per la ricerca delle minacce. Quando si crea una nuova tabella, il nome della tabella viene suffisso con _KQL se si scrive nell'area di lavoro Tabelle di sistema.

Prerequisiti

Per creare e gestire processi KQL nel data lake Microsoft Sentinel, sono necessari i prerequisiti seguenti.

Integrare nel data lake

Per creare e gestire processi KQL nel data lake Microsoft Sentinel, è necessario eseguire prima l'onboarding nel data lake. Per altre informazioni sull'onboarding al data lake, vedere Eseguire l'onboarding al data lake di Microsoft Sentinel.

Autorizzazioni

I ruoli di Microsoft Entra ID forniscono un ampio accesso a tutte le aree di lavoro nel data lake. Per leggere le tabelle in tutte le aree di lavoro, scrivere nel livello di analisi e pianificare processi usando query KQL, è necessario disporre di uno dei ruoli di Microsoft Entra ID supportati. Per altre informazioni su ruoli e autorizzazioni, vedere Microsoft Sentinel i ruoli e le autorizzazioni del data lake.

Per creare nuove tabelle personalizzate nel livello di analisi, assegnare il ruolo Collaboratore Log Analytics nell'area di lavoro Log Analytics all'identità gestita del data lake.

Per assegnare il ruolo, seguire questa procedura:

  1. Nella portale di Azure passare all'area di lavoro Log Analytics a cui si vuole assegnare il ruolo.
  2. Selezionare Controllo di accesso (IAM) nel riquadro di spostamento a sinistra.
  3. Selezionare Aggiungi assegnazione di ruolo.
  4. Nella tabella Ruolo selezionare *Collaboratore Log Analytics e quindi avanti.
  5. Selezionare Identità gestita e quindi Selezionare i membri.
  6. L'identità gestita del data lake è un'identità gestita assegnata dal sistema denominata msg-resources-<guid>. Selezionare l'identità gestita, quindi fare clic su Seleziona.
  7. Selezionare Esamina e assegna.

Per altre informazioni sull'assegnazione di ruoli alle identità gestite, vedere Assegnare ruoli Azure usando il portale di Azure.

Crea un processo

È possibile creare attività da eseguire secondo una pianificazione o una sola volta. Quando si crea un processo, si specificano l'area di lavoro di destinazione e la tabella per i risultati. È possibile scrivere i risultati in una nuova tabella o aggiungerli a una tabella esistente nel livello di analisi o data lake. Non è possibile scrivere i risultati in tabelle federate. È possibile creare un nuovo processo KQL o creare un processo da un modello contenente le impostazioni di query e processi. Per altre informazioni, vedere Creare un processo KQL da un modello.

  1. Avvia il processo di creazione dall'editor di query KQL o dalla pagina di gestione dei processi.

    1. Per creare un processo dall'editor di query KQL, selezionare il pulsante Crea processo nell'angolo superiore destro dell'editor di query. Una schermata che mostra il pulsante per creare un processo nell'editor di query KQL.

    2. Per creare un processo dalla pagina di gestione dei processi, selezionare Microsoft Sentinel>Processi di esplorazione> del data lakee quindi selezionare il pulsante Crea processo. Screenshot che mostra il pulsante Crea processo nella pagina di gestione dei processi.

  2. Inserire un nome del processo. Il nome del job deve essere univoco per il tenant. I nomi dei processi possono contenere fino a 256 caratteri. Non è possibile usare # o - in un nome processo.

  3. Inserisci una descrizione del processo che ne fornisca il contesto e lo scopo.

  4. Nell'elenco a discesa Seleziona area di lavoro selezionare l'area di lavoro di destinazione. Questa area di lavoro può essere tabelle di sistema o un'area di lavoro Sentinel in cui si desidera scrivere i risultati della query.

  5. Selezionare la tabella di destinazione:

    1. Per accodare a una tabella esistente, selezionare Aggiungi a una tabella esistente e selezionare il nome della tabella nell'elenco a discesa. Quando si aggiunge a una tabella esistente, i risultati della query devono corrispondere allo schema della tabella esistente.
  6. Seleziona Avanti. Una schermata che mostra la nuova pagina dei dettagli del processo.

  7. Esaminare o scrivere la query nel pannello Preparare la query . Verificare che il selettore dell'ora sia impostato sull'intervallo di tempo richiesto per il processo se l'intervallo di date non è specificato nella query.

  8. Selezionare le aree di lavoro su cui eseguire la query dall'elenco a discesa Aree di lavoro selezionate . Queste aree di lavoro sono le aree di lavoro di origine di cui si desidera eseguire query sulle tabelle. Le aree di lavoro selezionate determinano le tabelle disponibili per l'esecuzione di query. Le aree di lavoro selezionate si applicano a tutte le schede di query nell'editor di query. Quando si usano più aree di lavoro, l'operatore union() viene applicato per impostazione predefinita a tabelle con lo stesso nome e schema di aree di lavoro diverse. Usare l'operatore workspace() per eseguire query su una tabella da un'area di lavoro specifica, ad esempio workspace("MyWorkspace").AuditLogs.

    Nota

    Se si sta scrivendo in una tabella esistente, la query deve restituire i risultati con uno schema corrispondente allo schema della tabella di destinazione. Se la query non restituisce risultati con lo schema corretto, il processo ha esito negativo quando viene eseguito.

    La scrittura di processi KQL nelle tabelle di sistema è attualmente in anteprima.

  9. Seleziona Avanti.

    Una schermata che mostra il pannello delle query di revisione.

    Nella pagina Pianifica il processo di query, selezionare se si vuole eseguire il processo una volta o secondo una pianificazione. Se si seleziona Una volta, il processo viene eseguito non appena la definizione del processo è stata completata. Se si seleziona Pianifica, è possibile specificare una data e un'ora per l'esecuzione del processo o eseguire il processo in base a una pianificazione ricorrente.

  10. Selezionare Una sola volta o Attività pianificata.

    Nota

    La modifica di un processo una tantum ne attiva immediatamente l'esecuzione.

  11. Se è stata selezionata l'opzione Pianifica, immettere i dettagli seguenti:

    1. Selezionare la frequenza di ripetizione dall'elenco a discesa. È possibile selezionare Per minuto, Orario, Giornaliero, Settimanale o Mensile.
    2. Imposta il valore Ripeti ogni per specificare ogni quanto vuoi che il processo venga eseguito rispetto alla frequenza selezionata.
    3. In Imposta pianificazione selezionare data da e immettere un'ora. L'ora di inizio del processo nel campo Da deve essere impostata ad almeno 30 minuti dalla creazione del processo. Il processo viene eseguito a partire da questa data e ora in base alla frequenza selezionata nell'elenco a discesa Esegui ogni.
    4. Selezionare la data A e immettere un'ora per specificare quando termina la pianificazione del processo. Se si desidera che il programma continui indefinitamente, selezionare Imposta il processo per l'esecuzione indefinita.

    Gli orari di inizio e di fine dell'attività sono impostati in base alle impostazioni locali dell'utente.

    Nota

    Se si pianifica l'esecuzione di un processo a una frequenza elevata, ad esempio ogni 30 minuti, è necessario tenere conto del tempo necessario per rendere disponibili i dati nel data lake. In genere è disponibile una latenza fino a 15 minuti prima che i dati appena inseriti siano disponibili per l'esecuzione di query.

  12. Selezionare Avanti per esaminare i dettagli del processo.

    Screenshot che mostra il pannello del processo di pianificazione.

  13. Esaminare i dettagli del processo e selezionare Invia per creare il processo. Se il processo è una sola volta, viene eseguito dopo aver selezionato Invia. Se il processo è pianificato, viene aggiunto all'elenco dei processi nella pagina Processi ed eseguito in base ai dati e all'ora di inizio. Screenshot che mostra il pannello dei dettagli del processo di revisione.

  14. Il processo è pianificato e viene visualizzata la pagina seguente. È possibile visualizzare il processo selezionando il collegamento. Una schermata che mostra la pagina del processo appena creato.

Creare un job da un modello

È possibile creare un processo KQL da un modello di processo predefinito. I modelli di processo contengono la query KQL e le impostazioni del processo, come l'area di lavoro di destinazione, la tabella, la pianificazione e la descrizione. È possibile creare modelli di processo personalizzati o usare modelli predefiniti forniti da Microsoft.

Per creare un processo da un modello, segui questi passaggi:

  1. Nella pagina Processi o nell'editor di query KQL selezionare Crea processo e quindi selezionare Crea dal modello.

  2. Nella pagina modelli di processo, seleziona il modello che desideri utilizzare dall'elenco dei modelli disponibili.

  3. Rivedere la Descrizione e la query KQL nel modello.

  4. Selezionare Crea processo dal modello.

    Una schermata che mostra la pagina dei modelli di job.

  5. La creazione guidata del job si apre con la pagina Crea un nuovo job KQL. I dettagli del processo sono precompilati dal modello, ad eccezione dell'area di lavoro di destinazione.

  6. Selezionare l'area di lavoro di destinazione nell'elenco a discesa Seleziona area di lavoro .

  7. Esaminare e modificare i dettagli del job secondo necessità, quindi selezionare Avanti per continuare nella procedura guidata di creazione del job.

  8. I passaggi rimanenti sono gli stessi di quelli in Creare un'attività. I campi vengono prepopolati dal modello e possono essere modificati in base alle esigenze.

Sono disponibili i modelli seguenti:

Nome del modello Categoria
Aumento delle posizioni di accesso anomale
Analizzare l'analisi delle tendenze dei log di accesso dell'ID Entra per rilevare modifiche insolite della posizione per gli utenti nelle applicazioni calcolando le linee di tendenza della diversità delle posizioni. Evidenzia i primi tre account con l'aumento più rapido della variabilità della posizione ed elenca le posizioni associate all'interno delle finestre di 21 giorni.

Tabella di destinazione: UserAppSigninLocationTrend

Periodo di analisi della query: 1 giorno

Pianificazione: giornaliera

Data di inizio: Data corrente + 1 ora
Caccia
Comportamento di accesso anomalo in base alle modifiche alla posizione
Identificare comportamenti di accesso anomali in base alle variazioni di posizione per utenti e app di Entra ID, al fine di rilevare cambiamenti improvvisi nel comportamento.

Tabella di destinazione: UserAppSigninLocationAnomalies

Periodo di analisi della query: 1 giorno

Pianificazione: giornaliera

Data di inizio: Data corrente + 1 ora
Rilevamento delle anomalie
Controllare attività rare per app
Trovare app che eseguono azioni rare (ad esempio, consenso, concessioni) che possono creare privilegi senza problemi. Confrontare il giorno corrente con gli ultimi 14 giorni di controlli per identificare le nuove attività di controllo. Utile per tenere traccia delle attività dannose correlate alle aggiunte o alle rimozioni di utenti/gruppi da app Azure e approvazioni automatiche.

Tabella di destinazione: AppAuditRareActivity

Intervallo di ricerca della query: 14 giorni

Pianificazione: giornaliera

Data di inizio: Data corrente + 1 ora
Caccia
Azure operazioni rare a livello di sottoscrizione
Identificare gli eventi sensibili Azure a livello di sottoscrizione in base ai log attività Azure. Ad esempio, il monitoraggio basato sul nome dell'operazione "Crea o aggiorna snapshot", usato per la creazione di backup, ma potrebbe essere usato in modo improprio dagli utenti malintenzionati per eseguire il dump degli hash o estrarre informazioni sensibili dal disco.

Tabella di destinazione: AzureSubscriptionSensitiveOps

Intervallo di ricerca della query: 14 giorni

Pianificazione: giornaliera

Data di inizio: Data corrente + 1 ora
Caccia
Tendenza dell'attività giornaliera per app in AuditLogs
Dagli ultimi 14 giorni, identificare qualsiasi operazione di "consenso all'applicazione" eseguita da un utente o da un'app. Ciò potrebbe indicare che le autorizzazioni per accedere ad AzureApp elencate sono state fornite a un attore malintenzionato. Gli eventi di consenso a un'applicazione, di aggiunta dell'entità servizio e Auth2PermissionGrant dovrebbero essere rari. Se disponibile, viene aggiunto un contesto aggiuntivo da AuditLogs in base a CorrleationId dallo stesso account che ha eseguito "Consenso all'applicazione".

Tabella di destinazione: AppAuditActivityBaseline

Intervallo di ricerca della query: 14 giorni

Pianificazione: giornaliera

Data di inizio: Data corrente + 1 ora
Linea di base
Tendenza della posizione giornaliera per utente o app in SignInLogs
Creare tendenze giornaliere per tutti gli accessi degli utenti, il conteggio delle posizioni e l'utilizzo dell'app.

Tabella di destinazione: UserAppSigninLocationBaseline

Periodo di analisi della query: 1 giorno

Pianificazione: giornaliera

Data di inizio: Data corrente + 1 ora
Linea di base
Tendenza giornaliera del traffico di rete per ip di destinazione
Crea una baseline che includa byte e peer univoci per rilevare attività di beaconing ed esfiltrazione.

Tabella di destinazione: NetworkTrafficDestinationIPDailyBaseline

Periodo di analisi della query: 1 giorno

Pianificazione: giornaliera

Data di inizio: Data corrente + 1 ora
Linea di base
Tendenza giornaliera del traffico di rete per ip di destinazione con statistiche di trasferimento dati
Identificare l'host interno che ha contattato una destinazione esterna, inclusa l'analisi dell'andamento dei volumi e la stima dell'ampiezza dell'impatto.

Tabella di destinazione: NetworkTrafficDestinationIPTrend

Intervallo di ricerca della query: 1 giorno

Pianificazione: giornaliera

Data di inizio: Data corrente + 1 ora
Caccia
Tendenza giornaliera del traffico di rete per IP di origine
Crea una baseline che includa byte e peer univoci per rilevare attività di beaconing ed esfiltrazione.

Tabella di destinazione: NetworkTrafficSourceIPDailyBaseline

Periodo di analisi della query: 1 giorno

Pianificazione: giornaliera

Data di inizio: Data corrente + 1 ora
Linea di base
Tendenza giornaliera del traffico di rete per IP di origine con statistiche di trasferimento dati
Le connessioni e i byte di oggi vengono valutati rispetto alla baseline giornaliera dell'host per determinare se i comportamenti osservati si discostano in modo significativo dal modello stabilito.

Tabella di destinazione: NetworkTrafficSourceIPTrend

Periodo di retrospettiva della query: 1 giorno

Pianificazione: giornaliera

Data di inizio: Data corrente + 1 ora
Caccia
Tendenza della posizione di accesso giornaliera per utente e app
Creare una baseline di accesso per ogni utente o applicazione con un indirizzo IP e geografico tipico, consentendo un rilevamento delle anomalie efficiente e conveniente su larga scala.

Tabella di destinazione: UserAppSigninLocationDailyBaseline

Periodo di lookback della query: 1 giorno

Pianificazione: giornaliera

Data di inizio: Data corrente + 1 ora
Protezione di base
Tendenza di esecuzione del processo giornaliero
Identificare nuovi processi e prevalenza, semplificando i rilevamenti dei "nuovi processi rari".

Tabella di destinazione: EndpointProcessExecutionBaseline

Periodo di analisi della query: 1 giorno

Programmazione: giornaliera

Data di inizio: Data corrente + 1 ora
Linea di base
User agent raro per app di Entra ID
Definire una base di riferimento del tipo di User Agent (ovvero browser, applicazione da ufficio e così via) generalmente utilizzato per una determinata applicazione esaminando i dati dei giorni precedenti. Cerca quindi nel giorno corrente eventuali deviazioni da questo modello, ovvero i tipi di UserAgent non visualizzati prima in combinazione con questa applicazione.

Tabella di destinazione: UserAppRareUserAgentAnomalies

Intervallo di ricerca retrospettivo: 7 giorni

Programmazione: giornaliera

Data di inizio: Data corrente + 1 ora
Rilevamento delle anomalie
Corrispondenza IOC nei log di rete
Identificare eventuali indicatori IP di compromissione (IOC) da Threat Intelligence (TI), cercando corrispondenze in CommonSecurityLog.

Tabella di destinazione: NetworkLogIOCMatches

Intervallo di ricerca della query: 1 ora

Pianificazione: oraria

Data di inizio: Data corrente + 1 ora
Caccia
Nuovi processi osservati nelle ultime 24 ore
I nuovi processi in ambienti stabili possono indicare attività dannose. L'analisi delle sessioni di accesso in cui sono stati eseguiti questi file binari può aiutare a identificare gli attacchi.

Tabella di destinazione: EndpointNewProcessExecutions

Periodo di ricerca retrospettiva: 14 giorni

Programmazione: giornaliera

Data di inizio: Data corrente + 1 ora
Caccia
Operazione di file di SharePoint tramite indirizzi IP non ancora individuati in precedenza
Identificare le anomalie usando il comportamento dell'utente impostando una soglia per modifiche significative nelle attività di caricamento/download di file da nuovi indirizzi IP. Stabilisce una linea di base del comportamento tipico, la confronta con l'attività recente e contrassegna le deviazioni che superano una soglia predefinita di 25.

Tabella di destinazione: SharePointFileOpsNewIPs

Intervallo di ricerca della query: 14 giorni

Pianificazione: giornaliera

Data di inizio: Data corrente + 1 ora
Caccia
Potenziale attività di beaconing di rete Palo Alto
Identificare i modelli di beaconing dai log del traffico di Palo Alto Network in base ai modelli di delta temporale ricorrenti. La query usa varie funzioni KQL per calcolare i delta temporali e quindi la confronta con gli eventi totali osservati in un giorno per trovare la percentuale di beaconing.

Tabella di destinazione: PaloAltoNetworkBeaconingTrend

Periodo di analisi della query: 1 giorno

Pianificazione: giornaliera

Data di inizio: Data corrente + 1 ora
Caccia
Accesso sospetto di Windows al di fuori delle ore normali
Identificare eventi di accesso di Windows insoliti al di fuori delle ore normali di un utente confrontandoli con l'attività di accesso degli ultimi 14 giorni, contrassegnando le anomalie in base ai modelli cronologici.

Tabella di destinazione: WindowsLoginOffHoursAnomalies

Intervallo di ricerca della query: 14 giorni

Pianificazione: giornaliera

Data di inizio: Data corrente + 1 ora
Rilevamento delle anomalie

Considerazioni e limitazioni

Quando si creano processi nel data lake Microsoft Sentinel, considerare le limitazioni e le procedure consigliate seguenti:

Scegli un livello di dati per l'output del processo KQL

I processi KQL possono scrivere dati nel livello Analytics o nel livello Data Lake, a seconda del livello della tabella di destinazione. Quando si crea una nuova tabella tramite la creazione guidata del processo, è possibile selezionare le tabelle di sistema come area di lavoro di destinazione per scrivere i dati direttamente nel data lake. Le tabelle create in questo modo vengono create e archiviate direttamente nel livello data lake e vengono automaticamente suffisse con _KQL.

Considerazioni su KQL per i processi di data lake

Le seguenti limitazioni di KQL si applicano ai processi del data lake:

  • Sono supportati tutti gli operatori e le funzioni KQL, ad eccezione dei seguenti:

    • adx()
    • arg()
    • externaldata()
    • ingestion_time()
  • Quando si usa il stored_query_results comando , specificare l'intervallo di tempo nella query KQL. Il selettore di ora sopra l'editor di query non funziona con questo comando.

  • Le funzioni definite dall'utente non sono supportate.

Limiti per la denominazione e la pianificazione dei processi

Le limitazioni di denominazione e pianificazione seguenti si applicano ai processi KQL:

  • I nomi dei job devono essere univoci all'interno del tenant.
  • I nomi dei processi possono contenere fino a 256 caratteri.
  • I nomi dei processi non possono contenere un # o un -.
  • L'ora di avvio dell'attività deve essere impostata ad almeno 30 minuti dopo la creazione o la modifica dell'attività.

Latenza di inserimento data lake

Il livello data lake archivia i dati nell'archiviazione a freddo. A differenza dei livelli di analisi ad accesso frequente o quasi in tempo reale, l'archiviazione a freddo è ottimizzata per la conservazione a lungo termine e l'efficienza dei costi e non fornisce accesso immediato ai dati appena inseriti. Quando vengono aggiunte nuove righe alle tabelle esistenti nel data lake o nelle tabelle federate, esiste una latenza tipica fino a 15 minuti prima che i dati siano disponibili per l'esecuzione di query. Tenere conto della latenza di inserimento quando si eseguono query e si pianificano processi KQL assicurandosi che le finestre di lookback e le pianificazioni dei processi siano configurate per evitare dati non ancora disponibili.

Per evitare di eseguire query sui dati che potrebbero non essere ancora disponibili, includere un parametro di ritardo nelle query o nei processi KQL. Ad esempio, quando si pianificano processi automatizzati, impostare l'ora now() - delaydi fine della query su , dove delay corrisponde alla latenza tipica di preparazione dei dati di 15 minuti. Questo approccio garantisce che le query siano destinate solo ai dati completamente inseriti e pronti per l'analisi.

let lookback = 15m;
let delay = 15m;
let endTime = now() - delay;
let startTime = endTime - lookback;
CommonSecurityLog
| where TimeGenerated between (startTime .. endTime)

Questo approccio è efficace per i processi con finestre di lookback brevi o intervalli di esecuzione frequenti.

Valuta la sovrapposizione del periodo di lookback con la frequenza di esecuzione del processo per ridurre il rischio di non acquisire dati che arrivano in ritardo.

Per altre informazioni, vedere Gestire il ritardo di acquisizione nelle regole di analisi pianificate.

Nomi di colonna

I nomi di colonna devono iniziare con una lettera.

Le colonne standard seguenti non sono supportate per l'esportazione. Il processo di inserimento sovrascrive queste colonne nel livello di destinazione:

  • TenantId

  • _TimeReceived

  • Tipo

  • SourceSystem

  • _ResourceId

  • _Subscriptionid

  • _ItemId

  • _BilledSize

  • _IsBillable

  • _WorkspaceId

  • TimeGenerated viene sovrascritto se è più vecchio di due giorni. Per mantenere l'ora dell'evento originale, scrivere il timestamp di origine in una colonna separata.

Per informazioni sui limiti del servizio, vedere Limiti del servizio Data Lake di Microsoft Sentinel.

Nota

I risultati parziali possono essere alzati di livello se la query del processo supera il limite di un'ora.

Parametri e limiti del servizio per i job KQL

Nella tabella seguente sono elencati i parametri e i limiti del servizio per i processi KQL nel data lake Microsoft Sentinel.

Nota

Tutti i limiti in questa tabella si applicano per ogni tenant. Non è previsto alcun limite per utente. I processi KQL hanno una quota di concorrenza distinta e non condividono i contatori con le query KQL.

Quando viene superato il limite di esecuzione di processi simultanei, la richiesta viene rifiutata e non accodata. Il contatore decrementa non appena termina un processo in esecuzione.

Categoria Parametro/limite
Esecuzione di processi simultanei per tenant 5
Timeout di esecuzione della query del processo 1 ora
Processi per tenant (processi abilitati) 100
Numero di tabelle in uscita per processo 1
Ambito della query Più aree di lavoro
Intervallo di tempo della query Fino a 12 anni

Per suggerimenti per la risoluzione dei problemi e messaggi di errore, vedere Risoluzione dei problemi relativi alle query KQL per il data lake Microsoft Sentinel.