Créer des tâches KQL dans le lac de données de Microsoft Sentinel

Les tâches du langage de requête Kusto (KQL) sont des requêtes KQL ponctuelles ou programmées sur des données dans le lac de données Microsoft Sentinel et les tables fédérées. Les tables fédérées sont des sources de données externes, telles que Microsoft Entra ID, Microsoft 365 et Microsoft Resource Graph, que vous pouvez interroger en même temps que les tables de data lake sans ingérer les données dans votre espace de travail. Utilisez des tâches pour des scénarios d’enquête et d’analyse, tels que :

  • Requêtes ponctuelles à long terme pour les enquêtes sur les incidents et la réponse aux incidents (IR)
  • Tâches d’agrégation de données qui prennent en charge les flux de travail d’enrichissement à l’aide de journaux de faible fidélité
  • Scans de correspondance d'intelligence historique sur les menaces (TI) pour une analyse rétrospective
  • Analyses de détection d’anomalies qui identifient des modèles inhabituels sur plusieurs tables

Les travaux KQL sont particulièrement efficaces lorsque les requêtes utilisent des jointures ou des unions dans différents jeux de données. Avant de commencer, vérifiez que vous remplissez les conditions préalables, notamment l’intégration de Data Lake et les autorisations requises.

Utilisez des tâches pour faire passer les données du niveau du lac de données au niveau analytique. Une fois dans le niveau analytique, utilisez l’éditeur KQL de repérage avancé pour interroger les données. La promotion des données au niveau analytique présente les avantages suivants :

  • Combinez les données actuelles et historiques dans le niveau analytique ou à partir de tables fédérées pour exécuter des modèles d’analytique avancée et d’apprentissage automatique sur vos données.
  • Réduisez les coûts des requêtes en exécutant des requêtes dans le niveau analytique.
  • Combinez les données de plusieurs espaces de travail à un seul espace de travail dans le niveau analytique.
  • Combinez Microsoft Entra ID, Microsoft 365 et Microsoft Resource Graph des données dans le niveau analytique pour exécuter des analyses avancées sur plusieurs sources de données.

Remarque

Le stockage dans le niveau Analytique entraîne des taux de facturation plus élevés que dans le niveau Data Lake. Pour réduire les coûts, faites uniquement la promotion des données que vous devez analyser plus en détail. Utilisez le KQL dans votre requête pour projeter uniquement les colonnes dont vous avez besoin et filtrer les données pour réduire la quantité de données promues au niveau analytique.

Vous pouvez promouvoir des données vers une nouvelle table ou ajouter les résultats à une table existante dans le niveau Analytique. Lors de la création d’une table, le nom de la table est suffixe de _KQL_CL pour indiquer que la table a été créée par un travail KQL.

Si vous le souhaitez, vous pouvez écrire les résultats d’une tâche KQL dans une autre table de la couche data lake afin d’accélérer les investigations ou d’utiliser les données enrichies pour la chasse aux menaces. Lors de la création d’une nouvelle table, le nom de la table est suffixé par _KQL lorsque vous écrivez dans l’espace de travail des tables système.

Prérequis

Pour créer et gérer des travaux KQL dans le lac de données Microsoft Sentinel, vous avez besoin des prérequis suivants.

Intégrer au lac de données

Pour créer et gérer des travaux KQL dans le lac de données Microsoft Sentinel, vous devez d'abord intégrer le lac de données. Pour plus d’informations sur l’intégration au lac de données, consultez Intégrer au lac de données Microsoft Sentinel.

Autorisations

Les rôles Microsoft Entra ID fournissent un accès étendu dans tous les espaces de travail du lac de données. Pour lire des tables dans tous les espaces de travail, écrire dans le niveau analytique et planifier des travaux à l’aide de requêtes KQL, vous devez disposer de l’un des rôles Microsoft Entra ID pris en charge. Pour plus d’informations sur les rôles et les autorisations, consultez Rôles et autorisations du data lake Microsoft Sentinel.

Pour créer de nouvelles tables personnalisées dans le niveau d’analytique, attribuez le rôle Contributeur Log Analytics dans l’espace de travail Log Analytics à l’identité managée du lac de données.

Pour attribuer le rôle, procédez comme suit :

  1. Dans la Portail Azure, accédez à l’espace de travail Log Analytics auquel vous souhaitez attribuer le rôle.
  2. Sélectionnez Contrôle d’accès (IAM) dans le volet de navigation gauche.
  3. Sélectionnez Ajouter une attribution de rôle.
  4. Dans le tableau Rôle, sélectionnez *Contributeur Log Analytics, puis sélectionnez Suivant.
  5. Sélectionnez Identité managée, puis sélectionnez Sélectionner des membres.
  6. L’identité managée de votre lac de données est une identité managée attribuée par le système appelée msg-resources-<guid>. Sélectionnez l’identité managée, puis sélectionnez Sélectionner.
  7. Sélectionnez Vérifier et attribuer.

Pour plus d’informations sur l’attribution de rôles à des identités managées, consultez Attribuer des rôles Azure à l’aide de la Portail Azure.

Créer un travail

Vous pouvez créer des travaux à exécuter selon une planification ou une seule fois. Lorsque vous créez un travail, vous spécifiez l’espace de travail et la table de destination pour les résultats. Vous pouvez écrire les résultats dans une nouvelle table ou les ajouter à une table existante dans le niveau Analytics ou Data Lake. Vous ne pouvez pas écrire les résultats dans des tables fédérées. Vous pouvez créer un travail KQL ou créer un travail à partir d’un modèle contenant les paramètres de requête et de travail. Pour plus d’informations, consultez Créer un travail KQL à partir d’un modèle.

  1. Démarrez le processus de création de travaux à partir de l’éditeur de requête KQL ou à partir de la page de gestion des travaux.

    1. Pour créer un travail à partir de l’éditeur de requête KQL, sélectionnez le bouton Créer un travail dans le coin supérieur droit de l’éditeur de requête. Capture d’écran montrant le bouton Créer un travail dans l’éditeur de requête KQL.

    2. Pour créer un travail à partir de la page de gestion des travaux, sélectionnez Microsoft Sentinel>Travaux d’exploration> de lac de données, puis sélectionnez le bouton Créer un travail. Capture d’écran montrant le bouton Créer un travail sur la page de gestion des travaux.

  2. Entrez un nom de travail. Le nom du travail doit être unique pour le locataire. Les noms de travaux peuvent contenir jusqu’à 256 caractères. Vous ne pouvez pas utiliser un # ou un - dans un nom de travail.

  3. Entrez une description de la tâche en fournissant le contexte et l’objectif du travail.

  4. Dans la liste déroulante Sélectionner un espace de travail , sélectionnez l’espace de travail de destination. Cet espace de travail peut être des tables système ou un espace de travail Sentinel dans lequel vous souhaitez écrire les résultats de la requête.

  5. Sélectionnez la table de destination :

    1. Pour ajouter à une table existante, sélectionnez Ajouter à une table existante , puis sélectionnez le nom de la table dans la liste déroulante. Lors de l’ajout à une table existante, les résultats de la requête doivent correspondre au schéma de la table existante.

  6. Sélectionnez Suivant. Capture d’écran montrant la page des détails du nouveau travail.

  7. Passez en revue ou écrivez votre requête dans le panneau Préparer la requête . Vérifiez que le sélecteur d’heure est défini sur l’intervalle de temps requis pour le travail si la plage de dates n’est pas spécifiée dans la requête.

  8. Sélectionnez les espaces de travail sur lequel exécuter la requête dans la liste déroulante Espaces de travail sélectionnés . Ces espaces de travail sont les espaces de travail sources contenant les tables que vous souhaitez interroger. Les espaces de travail que vous sélectionnez déterminent les tables disponibles pour l’interrogation. Les espaces de travail sélectionnés s’appliquent à tous les onglets de requête dans l’éditeur de requête. Lorsque vous utilisez plusieurs espaces de travail, l’opérateur union() est appliqué par défaut aux tables portant le même nom et le même schéma à partir de différents espaces de travail. Utilisez l’opérateur workspace() pour interroger une table à partir d’un espace de travail spécifique, par exemple workspace("MyWorkspace").AuditLogs.

    Remarque

    Si vous écrivez dans une table existante, la requête doit retourner des résultats avec un schéma qui correspond au schéma de la table de destination. Si la requête ne retourne pas de résultats avec le schéma correct, le travail échoue lorsqu’il s’exécute.

    L’écriture de tâches KQL dans les tables système est actuellement en préversion.

  9. Sélectionnez Suivant.

    Capture d’écran montrant le panneau de requête de révision.

    Dans la page Planifier le travail de requête , indiquez si vous souhaitez exécuter le travail une seule fois ou selon une planification. Si vous sélectionnez Une seule fois, le travail s’exécute dès que la définition du travail est terminée. Si vous sélectionnez Planifier, vous pouvez spécifier une date et une heure pour l’exécution du travail, ou exécuter le travail selon une planification périodique.

  10. Sélectionnez Une seule fois ou Travail planifié.

    Remarque

    La modification d’une tâche ponctuelle déclenche immédiatement son exécution.

  11. Si vous avez sélectionné Planifier, entrez les détails suivants :

    1. Sélectionnez la fréquence de répétition dans la liste déroulante. Vous pouvez sélectionner Par minute, Toutes les heures, Tous les jours, Hebdomadaire ou Mensuel.
    2. Définissez la valeur Répéter chaque fois pour la fréquence à laquelle vous souhaitez que le travail s’exécute par rapport à la fréquence sélectionnée.
    3. Dans Définir le calendrier, sélectionnez une date de début et saisissez une heure. L’heure de début de la tâche dans le champ À partir de doit être fixée au moins 30 minutes après la création de la tâche. La tâche s’exécute à partir de cette date et de cette heure selon la fréquence sélectionnée dans la liste déroulante Exécuter toutes les.
    4. Sélectionnez la date Jusqu’au et saisissez une heure pour indiquer quand la planification de la tâche se termine. Si vous souhaitez que la planification se poursuive indéfiniment, sélectionnez Définir le travail pour qu’il s’exécute indéfiniment.

    Les heures de début et de fin de la tâche sont définies selon les paramètres régionaux de l’utilisateur.

    Remarque

    Si vous planifiez l’exécution d’un travail à une fréquence élevée, par exemple toutes les 30 minutes, vous devez prendre en compte le temps nécessaire pour que les données soient disponibles dans le lac de données. Il existe généralement une latence allant jusqu’à 15 minutes avant que les données nouvellement ingérées ne soient disponibles pour l’interrogation.

  12. Sélectionnez Suivant pour passer en revue les détails du travail.

    Capture d’écran montrant le panneau planifier le travail.

  13. Passez en revue les détails du travail et sélectionnez Envoyer pour créer le travail. Si le travail est un travail à usage unique, il s’exécute une fois que vous avez sélectionné Envoyer. Si le travail est planifié, il est ajouté à la liste des travaux dans la page Travaux et s’exécute en fonction des données et de l’heure de début. Capture d’écran montrant le panneau détails du travail de révision.

  14. Le travail est planifié et la page suivante s’affiche. Vous pouvez afficher le travail en sélectionnant le lien. Capture d’écran montrant la page du travail créé.

Créer un travail à partir d’un modèle

Vous pouvez créer un travail KQL à partir d’un modèle de travail prédéfini. Les modèles de travail contiennent les paramètres de requête et de travail KQL, tels que l’espace de travail et la table de destination, la planification et la description. Vous pouvez créer vos propres modèles de travail ou utiliser des modèles intégrés fournis par Microsoft.

Pour créer un travail à partir d’un modèle, procédez comme suit :

  1. Dans la page Travaux ou l’éditeur de requête KQL, sélectionnez Créer un travail, puis Créer à partir du modèle.

  2. Dans la page Modèles de travail, sélectionnez le modèle que vous souhaitez utiliser dans la liste des modèles disponibles.

  3. Passez en revue les requêtes Description et KQL à partir du modèle.

  4. Sélectionnez Créer un travail à partir du modèle.

    Capture d’écran montrant la page modèles de travail.

  5. L’assistant de création de tâche s’ouvre sur la page Créer une nouvelle tâche KQL. Les détails de la tâche sont préremplis à partir du modèle, à l’exception de l’espace de travail de destination.

  6. Sélectionnez l’espace de travail de destination dans la liste déroulante Sélectionner un espace de travail .

  7. Examinez et modifiez les détails de la tâche si nécessaire, puis sélectionnez Suivant pour poursuivre dans l’assistant de création de tâche.

  8. Les étapes restantes sont les mêmes que celles de Créer un travail. Les champs sont préremplis à partir du modèle et peuvent être modifiés en fonction des besoins.

Les modèles suivants sont disponibles :

Nom du modèle Catégorie
Augmentation du nombre de lieux de connexion anormaux
Analysez l’analyse des tendances des journaux de connexion de l’ID Entra pour détecter les changements d’emplacement inhabituels pour les utilisateurs entre les applications en calculant les lignes de tendance de la diversité des emplacements. Il met en évidence les trois principaux comptes avec la plus forte augmentation de la variabilité de l’emplacement et répertorie leurs emplacements associés dans les fenêtres de 21 jours.

Table de destination : UserAppSigninLocationTrend

Période de rétrospection de la requête : 1 jour

Planification : quotidienne

Date de début : Date actuelle + 1 heure
 Chasse
Comportement de connexion anormal en fonction des changements d’emplacement
Identifiez le comportement de connexion anormal en fonction des changements d’emplacement pour les utilisateurs et les applications Entra ID afin de détecter les changements soudains de comportement.

Table de destination : UserAppSigninLocationAnomalies

Période de rétrospection de la requête : 1 jour

Planification : quotidienne

Date de début : Date actuelle + 1 heure
 Détection des anomalies
Auditer une activité rare par application
Recherchez les applications effectuant des actions rares (par exemple, consentement, octrois) qui peuvent créer silencieusement des privilèges. Comparez le jour actuel aux 14 derniers jours d’audit pour identifier les nouvelles activités d’audit. Utile pour suivre les activités malveillantes liées aux ajouts ou suppressions d’utilisateurs/groupes par Azure Apps et les approbations automatisées.

Table de destination : AppAuditRareActivity

Période d'analyse de la requête : 14 jours

Planification : quotidienne

Date de début : Date actuelle + 1 heure
 Chasse
Opérations rares au niveau de l'abonnement Azure
Identifiez les événements sensibles au niveau de l’abonnement Azure à partir des journaux d’activité Azure. Par exemple, la surveillance basée sur le nom de l’opération « Créer ou mettre à jour un instantané », qui est utilisé pour créer des sauvegardes, mais qui peut être utilisé à mauvais escient par des attaquants pour vider les hachages ou extraire des informations sensibles du disque.

Table de destination : AzureSubscriptionSensitiveOps

Période d'analyse de la requête : 14 jours

Planification : quotidienne

Date de début : Date actuelle + 1 heure
 Chasse
Tendance d’activité quotidienne par application dans AuditLogs
Depuis les 14 derniers jours, identifiez toute opération « Consentement à l’application » qui se produit par un utilisateur ou une application. Cela peut indiquer que des autorisations d’accès à l’application AzureApp répertoriée ont été fournies à un acteur malveillant. Les événements de consentement à une application, d’ajout d’un principal de service et d’ajout d’Auth2PermissionGrant devraient être rares. Lorsque cela est possible, un contexte supplémentaire est ajouté à partir des journaux d’audit en s’appuyant sur l’identifiant CorrleationId du même compte ayant réalisé le « Consentement à l’application ».

Table de destination : AppAuditActivityBaseline

Période d'analyse de la requête : 14 jours

Planification : quotidienne

Date de début : Date actuelle + 1 heure
 Ligne de base
Tendance de localisation quotidienne par utilisateur ou application dans SignInLogs
Créez des tendances quotidiennes pour toutes les connexions utilisateur, le nombre d’emplacements et l’utilisation de leurs applications.

Table de destination : UserAppSigninLocationBaseline

Période de rétrospection de la requête : 1 jour

Planification : quotidienne

Date de début : Date actuelle + 1 heure
 Ligne de base
Tendance quotidienne du trafic réseau par adresse IP de destination
Élaborez une base de référence intégrant les octets et les pairs distincts afin de repérer les balises et les exfiltrations.

Table de destination : NetworkTrafficDestinationIPDailyBaseline

Période de rétrospection de la requête : 1 jour

Planification : quotidienne

Date de début : Date actuelle + 1 heure
 Ligne de base
Tendance du trafic réseau quotidien par adresse IP de destination avec les statistiques de transfert de données
Repérez l’hôte interne ayant contacté la destination sortante, ainsi que les tendances volumétriques, en estimant son rayon d’action.

Table de destination : NetworkTrafficDestinationIPTrend

Période de rétrospection de la requête : 1 jour

Planification : quotidienne

Date de début : Date actuelle + 1 heure
 Chasse
Tendance du trafic réseau quotidien par adresse IP source
Élaborez une base de référence intégrant les octets et les pairs distincts afin de repérer les balises et les exfiltrations.

Table de destination : NetworkTrafficSourceIPDailyBaseline

Période de rétrospection de la requête : 1 jour

Planification : quotidienne

Date de début : Date actuelle + 1 heure
 Ligne de base
Tendance du trafic réseau quotidien par adresse IP source avec des statistiques de transfert de données
Les connexions et les octets d’aujourd’hui sont évalués par rapport à la base de référence quotidienne de l’hôte pour déterminer si les comportements observés s’écartent considérablement du modèle établi.

Table de destination : NetworkTrafficSourceIPTrend

Période de rétrospection de la requête : 1 jour

Planification : quotidienne

Date de début : Date actuelle + 1 heure
 Chasse
Tendance quotidienne de l’emplacement de connexion par utilisateur et application
Créez une base de référence de connexion pour chaque utilisateur ou application avec des adresses IP et géographiques typiques, ce qui permet une détection efficace et économique des anomalies à grande échelle.

Table de destination : UserAppSigninLocationDailyBaseline

Période de rétrospection de la requête : 1 jour

Planification : quotidienne

Date de début : Date actuelle + 1 heure
 Ligne de base
Tendance de l’exécution quotidienne des processus
Identifiez les nouveaux processus et la prévalence, ce qui facilite les détections de « nouveaux processus rares ».

Table de destination : EndpointProcessExecutionBaseline

Période de rétrospection de la requête : 1 jour

Planification : quotidienne

Date de début : Date actuelle + 1 heure
 Ligne de base
Entra ID rare user agent par application
Établissez une base de référence du type UserAgent (c’est-à-dire, navigateur, application de bureau, etc.) qui est généralement utilisé pour une application particulière en regardant en arrière pendant un certain nombre de jours. Il recherche ensuite, au cours de la journée en cours, toute anomalie par rapport à ce schéma, c’est-à-dire des types d’agents utilisateurs jamais observés auparavant avec cette application.

Table de destination : UserAppRareUserAgentAnomalies

Période de recherche : 7 jours

Planification : quotidienne

Date de début : Date actuelle + 1 heure
 Détection des anomalies
Correspondance des IOC dans le journal réseau
Identifiez les indicateurs IP de compromission (IOC) issus du renseignement sur les menaces (TI) en recherchant des correspondances dans CommonSecurityLog.

Table de destination : NetworkLogIOCMatches

Période de rétrospection de la requête : 1 heure

Planification : toutes les heures

Date de début : Date actuelle + 1 heure
 Chasse
Nouveaux processus observés au cours des dernières 24 heures
Les nouveaux processus dans des environnements stables peuvent indiquer une activité malveillante. L’analyse des sessions de connexion où ces fichiers binaires s’exécutaient peut aider à identifier les attaques.

Table de destination : EndpointNewProcessExecutions

Période d'analyse de la requête : 14 jours

Planification : quotidienne

Date de début : Date actuelle + 1 heure
 Chasse
Opération de fichier SharePoint via des adresses IP précédemment invisibles
Identifiez les anomalies à l’aide du comportement de l’utilisateur en définissant un seuil pour les modifications significatives dans les activités de chargement/téléchargement de fichiers à partir de nouvelles adresses IP. Il établit une base de référence du comportement classique, la compare à l’activité récente et signale les écarts dépassant un seuil par défaut de 25.

Table de destination : SharePointFileOpsNewIPs

Période d'analyse de la requête : 14 jours

Planification : quotidienne

Date de début : Date actuelle + 1 heure
 Chasse
Balise réseau potentielle de Palo Alto
Repérez les schémas de balisage dans les journaux d’activité de Palo Alto Network sur la base des motifs récurrents de delta temporel. La requête fait appel à diverses fonctions KQL pour calculer les deltas temporels, puis les confronte au volume total d’événements observés sur une journée afin d’établir le pourcentage de balisage.

Table de destination : PaloAltoNetworkBeaconingTrend

Période de rétrospection de la requête : 1 jour

Planification : quotidienne

Date de début : Date actuelle + 1 heure
 Chasse
Connexion suspecte Windows en dehors des heures normales
Identifiez les événements de connexion Windows inhabituels en dehors des heures normales d’un utilisateur en comparant avec l’activité de connexion des 14 derniers jours, en signalant les anomalies en fonction de modèles historiques.

Table de destination : WindowsLoginOffHoursAnomalies

Période d'analyse de la requête : 14 jours

Planification : quotidienne

Date de début : Date actuelle + 1 heure
 Détection des anomalies

Considérations et limitations

Lorsque vous créez des travaux dans le lac de données Microsoft Sentinel, tenez compte des limitations et bonnes pratiques suivantes :

Choisir un niveau de données pour la sortie des travaux KQL

Les travaux KQL peuvent écrire des données dans le niveau Analytique ou le niveau Lac de données, selon le niveau de la table de destination. Lorsque vous créez une nouvelle table à l’aide de l’assistant de création de tâches, vous pouvez sélectionner les tables système comme espace de travail de destination pour écrire directement les données dans le lac de données. Les tables créées de cette façon sont créées et stockées directement dans le niveau du lac de données et sont automatiquement suffixeées avec _KQL.

Considérations relatives à KQL pour les travaux du lac de données

Les limitations de KQL suivantes s’appliquent aux travaux de lac de données :

  • Tous les opérateurs et fonctions KQL sont pris en charge, à l’exception des éléments suivants :

    • adx()
    • arg()
    • externaldata()
    • ingestion_time()

  • Lorsque vous utilisez la stored_query_results commande , fournissez l’intervalle de temps dans la requête KQL. Le sélecteur de temps au-dessus de l’éditeur de requête ne fonctionne pas avec cette commande.

  • Les fonctions définies par l’utilisateur ne sont pas prises en charge.

Limites de dénomination et de planification des tâches

Les limitations relatives à la dénomination et à la planification suivantes s’appliquent aux tâches KQL :

  • Les noms des tâches doivent être uniques pour un locataire donné.
  • Les noms des travaux peuvent comporter jusqu’à 256 caractères.
  • Les noms de travaux ne peuvent pas contenir un # ou un -.
  • L’heure de début du travail doit être au moins 30 minutes après la création ou la modification du travail.

Suppression des espaces de travail source

Si un espace de travail source référencé par une tâche KQL planifiée est supprimé, la tâche peut continuer à s’exécuter et échouer à chaque exécution programmée jusqu’à l’expiration de l’ordonnance ou la modification de la tâche. Pour éviter des échecs répétés et une consommation inutile de ressources, les tâches qui font référence à des espaces de travail sources supprimés sont automatiquement placées en état Désactivé et nécessitent une action utilisateur avant de pouvoir reprendre.

Latence d’ingestion du lac de données

Le niveau du lac de données stocke les données dans le stockage à froid. Contrairement aux niveaux d’analyse à chaud ou en quasi-temps réel, le stockage à froid est optimisé pour la conservation à long terme et la rentabilité et ne fournit pas d’accès immédiat aux données nouvellement ingérées. Lorsque de nouvelles lignes sont ajoutées à des tables existantes dans le lac de données ou dans des tables fédérées, il existe une latence classique jusqu’à 15 minutes avant que les données ne soient disponibles pour l’interrogation. Tenir compte de la latence d’ingestion lorsque vous exécutez des requêtes et planifiez des travaux KQL en vous assurant que les fenêtres de recherche arrière et les planifications de travaux sont configurées pour éviter les données qui ne sont pas encore disponibles.

Pour éviter d’interroger des données qui ne sont peut-être pas encore disponibles, incluez un paramètre de délai dans vos requêtes ou travaux KQL. Par exemple, lorsque vous planifiez des travaux automatisés, définissez l’heure de fin de la requête sur now() - delay, où delay correspond à la latence de préparation des données classique de 15 minutes. Cette approche garantit que les requêtes ciblent uniquement les données entièrement ingérées et prêtes à être analysées.

La requête KQL suivante détecte les événements dans une fenêtre de retours de 15 minutes tout en tenant compte du délai d’ingestion. La lookback variable contrôle la plage de temps de requête, et la delay variable décale la fenêtre pour s’assurer que seules les données entièrement ingérées sont interrogées.

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

Cette approche est efficace pour les tâches ayant des fenêtres rétrospectives courtes ou des intervalles d’exécution fréquents.

Envisagez de faire chevaucher la période de rétrospection avec la fréquence d’exécution des tâches afin de réduire le risque de ne pas prendre en compte des données arrivées tardivement.

Pour plus d’informations, consultez Gérer le délai d’ingestion dans les règles d’analyse planifiée.

Noms de colonnes

Les noms de colonne doivent commencer par une lettre.

Les colonnes standard suivantes ne sont pas prises en charge pour l’exportation. Le processus d’ingestion remplace ces colonnes dans le niveau de destination :

  • ID de locataire

  • _TimeReceived

  • Type

  • SourceSystem

  • _ResourceId

  • _SubscriptionId

  • _ItemId

  • _BilledSize

  • _IsBillable

  • _WorkspaceId

  • TimeGenerated est remplacé s’il est antérieur à deux jours. Pour conserver l’heure de l’événement d’origine, écrivez l’horodatage source dans une colonne distincte.

Pour connaître les limites de service, consultez limites de service du data lake Microsoft Sentinel.

Remarque

Des résultats partiels peuvent apparaître si l’exécution de la requête de la tâche dépasse la limite d’une heure.

Paramètres de service et limites pour les tâches KQL

Le tableau suivant répertorie les paramètres de service et les limites des travaux KQL dans le lac de données Microsoft Sentinel.

Remarque

Toutes les limites de cette table s’appliquent par locataire. Il n’existe aucune limite par utilisateur. Les travaux KQL disposent de leur propre quota d'accès concurrentiel et ne partagent pas de compteurs avec les requêtes KQL.

Lorsque la limite d’exécution de travaux simultanés est dépassée, la demande est rejetée et n’est pas mise en file d’attente. Le compteur est décrémenté dès qu'un travail en cours d'exécution se termine.

Catégorie Paramètre/limite
Exécution simultanée de travaux par locataire 5
Délai d’exécution de la requête de travail 1 heure
Travaux par locataire (travaux activés) 100
Nombre de tables de sortie par tâche 1
Étendue de la requête Plusieurs espaces de travail
Intervalle de temps de requête Jusqu’à 12 ans

Pour obtenir des conseils de dépannage et des messages d’erreur, consultez Résolution des problèmes liés aux requêtes KQL pour le lac de données Microsoft Sentinel.

Contenu connexe

  • Last updated on