Réanalyser les données historiques (relecture des journaux)

Compatible avec :

Ce guide s'adresse aux ingénieurs en sécurité et en détection qui souhaitent réanalyser les données de journaux historiques dans Google Security Operations à l'aide de la relecture des journaux. Il explique comment valider une configuration d'analyseur actif et demander une tâche de relecture des journaux de backend via l'assistance Google Cloud pour remplir les mappages de champs UDM (Unified Data Model) mis à jour sur un historique de télémétrie de 180 jours maximum. En suivant cette méthode, vous pouvez appliquer des analyseurs prédéfinis, des analyseurs personnalisés ou des extensions d'analyseur mis à jour aux journaux bruts stockés, alors que les nouvelles instructions de mappage ne s'appliquent qu'aux journaux nouvellement ingérés. Une fois l'opération terminée, la couverture des règles de détection et de recherche des menaces historiques est améliorée, sans qu'il soit nécessaire de réingérer manuellement les journaux à partir des points de terminaison sources.

Cas d'utilisation courants

L'analyse à nouveau des journaux historiques permet de résoudre les scénarios opérationnels suivants :

Normalisation rétroactive des champs

  • Objectif : Remplir les champs UDM nouvellement mappés dans les journaux historiques après avoir activé une mise à jour de l'analyseur prédéfini, un analyseur personnalisé ou une extension d'analyseur.
  • Valeur : permet de maintenir une cohérence dans la possibilité de recherche entre les données historiques et en direct, sans nécessiter de réingestion manuelle à partir des points de terminaison sources.

Traque des menaces dans l'explorateur de journaux

  • Objectif : interroger les journaux historiques à l'aide des attributs UDM nouvellement mappés pour examiner l'activité passée des pirates informatiques.
  • Valeur : accélère la réponse aux incidents en faisant apparaître les indicateurs de compromission (IOC) historiques qui n'avaient pas été mappés auparavant dans le texte brut des journaux.

Évaluation des règles de détection historiques

  • Objectif : évaluer les règles de détection YARA-L par rapport aux données de journaux passées nécessitant des champs UDM normalisés spécifiques.
  • Valeur : empêche les faux négatifs lors de l'évaluation de la logique de détection mise à jour par rapport aux événements historiques.

Terminologie clé

  • Relecture des journaux : service de backend de Google SecOps qui retraiter les journaux bruts stockés à l'aide d'une configuration d'analyseur active pour générer des enregistrements UDM mis à jour.
  • Modèle de données unifié (UDM) : schéma standardisé utilisé par Google SecOps pour normaliser les données télémétriques de sécurité pour la recherche, les tableaux de bord et les règles de détection.
  • Dépôt brut immuable : couche de stockage sous-jacente qui conserve les journaux bruts d'origine non modifiés à des fins de conformité, d'audit et de réanalyse historique.

Avant de commencer

Avant de demander une tâche de relecture des journaux, assurez-vous de remplir les conditions suivantes :

  • Autorisations : vous devez disposer des autorisations suivantes :

    • Afficher et gérer les configurations d'analyseur dans Google SecOps (comme le rôle Éditeur de l'API Chronicle).
    • créer des demandes d'assistance dans la console Google Cloud (par exemple, le rôle "Éditeur de l'assistance technique", roles/cloudsupport.techSupportEditor) ;

  • Vérification de l'environnement : vérifiez que vous disposez de l'ID d'instance client Google SecOps et de l'ID de projet Google Cloud associé.

Limites

La relecture des journaux fonctionne dans les limites de compatibilité suivantes :

  • Période de conservation acceptée : vous pouvez demander une réanalyse historique des données de journaux historiques jusqu'à 180 jours (6 mois).
  • Analyseur actif requis : Log Replay n'applique que la version active de l'analyseur. Vous ne pouvez pas utiliser de configurations d'analyseur syntaxique brouillon, inactives ou archivées.
  • Spécification du champ d'application : la réanalyse est limitée à des types de journaux spécifiques et à des codes temporels de début et de fin définis au format RFC 3339 UTC.
  • Stockage brut immuable : Log Replay ne régénère que les enregistrements UDM normalisés. Les journaux bruts d'origine restent inchangés dans le dépôt brut immuable.

Demander une tâche de relecture de journaux

Pour valider votre analyseur et envoyer une demande de relecture des journaux, procédez comme suit.

Valider la configuration de l'analyseur actif

Avant de demander une réanalyse historique, vérifiez que l'analyseur ou l'extension d'analyseur cible est actif et normalise la télémétrie en direct.

  1. Dans la console Google SecOps, accédez à Paramètres SIEM > Analyseurs.

  2. Localisez le type de journal cible et vérifiez que l'analyseur prédéfini, l'analyseur personnalisé ou l'extension d'analyseur mis à jour ont l'état Actif et normalisent les journaux entrants en direct comme prévu.

Envoyer la demande d'assistance

Envoyez une demande d'assistance avec les paramètres de portée requis pour que l'assistance Google Cloud puisse lancer le job de relecture du backend.

  1. Ouvrez une demande d'assistance à l'aide de la consoleGoogle Cloud .

  2. Dans la description de la demande d'assistance, incluez les informations suivantes :

    • Identifiant de l'instance : ID de votre instance client Google SecOps et ID du projet Google Cloud associé.
    • Type de journal : libellé log_type spécifique à réanalyser (par exemple, PAN_FIREWALL ou <var>CUSTOM_LOG_TYPE</var>).
    • Période cible : les codes temporels de début et de fin précis au format RFC 3339 UTC (par exemple, de 2026-06-01T00:00:00Z à 2026-08-31T23:59:59Z), dans la limite de 180 jours autorisée.
    • Détails de l'analyseur : version de l'analyseur actif, nom de l'analyseur personnalisé ou ID de l'extension de l'analyseur à appliquer (Log Replay n'applique que la version active).
    • Justification commerciale : bref résumé de l'exigence, comme la normalisation rétroactive des champs ou l'étude des incidents.

Exemples et informations de référence

Utilisez le modèle de cette section pour préparer votre demande d'assistance.

Modèle de demande d'assistance

Copiez et remplissez le modèle suivant lorsque vous décrivez votre problème dans votre demande d'assistance :

Request type: Google SecOps Log Replay (historical re-parsing)
Customer instance ID: <YOUR_INSTANCE_ID>
Google Cloud project ID: <YOUR_PROJECT_ID>
Target log_type: <LOG_TYPE_LABEL>
Start timestamp (RFC 3339 UTC): 2026-06-01T00:00:00Z
End timestamp (RFC 3339 UTC): 2026-08-31T23:59:59Z
Active parser or extension ID: <ACTIVE_PARSER_NAME_OR_EXTENSION_ID>
Business justification: Retroactive UDM field normalization for active parser update

Dépannage

Cette section décrit les attentes en termes de performances et fournit des solutions en libre-service pour les problèmes courants liés à la relecture des journaux.

Latence et limites

Une fois que l'assistance Google Cloud a lancé la tâche de relecture des journaux, le processus s'exécute de manière asynchrone dans le backend. Le temps de traitement dépend du volume global de journaux au cours de la période spécifiée. À mesure que la tâche traite les journaux bruts historiques, les enregistrements UDM nouvellement générés remplacent progressivement les enregistrements UDM antérieurs pour cette période. N'envoyez pas de demandes d'assistance en double pour le même type de journaux et la même période pendant l'exécution d'une tâche de relecture.

Correction des erreurs

Utilisez ce tableau pour résoudre les problèmes courants liés à la demande ou à la validation d'une tâche de relecture des journaux.

Problème Description Corriger
Demande refusée en raison d'un analyseur inactif L'analyseur personnalisé ou l'extension d'analyseur demandés sont à l'état Brouillon ou En attente. Dans Paramètres SIEM > Analyseurs, activez la configuration de l'analyseur, vérifiez que les journaux en direct sont analysés comme prévu, puis renvoyez la demande d'assistance.
Demande refusée en raison de la limite de la période Le code temporel de début demandé remonte à plus de 180 jours. Ajustez les codes temporels de début et de fin dans la description de votre demande d'assistance pour qu'ils se situent dans la période de conservation de 180 jours.
Champs UDM mis à jour manquants dans la recherche Les résultats de recherche UDM pour la période cible n'affichent pas encore les nouveaux mappages de champs. Attendez que la tâche de relecture du backend asynchrone ait fini de traiter la plage de temps complète, puis vérifiez la syntaxe de votre requête dans Recherche SIEM.

Validation et test

Une fois que l'assistance Google Cloud a confirmé que la tâche de relecture des journaux est terminée, vérifiez les enregistrements UDM mis à jour dans votre environnement :

  1. Dans la console Google SecOps, accédez à Investigation > Recherche SIEM.
  2. Définissez le sélecteur de plage de dates pour qu'il corresponde aux codes temporels de début et de fin de votre demande de relecture.
  3. Exécutez une requête de recherche UDM ciblant les champs UDM nouvellement mappés pour votre log_type afin de confirmer que les événements historiques affichent les attributs normalisés.

Vous avez encore besoin d'aide ? Obtenez des réponses auprès des membres de la communauté et des professionnels Google SecOps.