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 active 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 une période de télémétrie historique allant jusqu'à 180 jours. Cette méthode vous permet d'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

Le réexamen des journaux historiques permet de résoudre les scénarios opérationnels suivants :

Normalisation rétroactive des champs

  • Objectif : Remplissez 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'étaient pas 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 : évite 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 retraite 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 :

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

  • Vérification de l'environnement : vérifiez que vous disposez de l'ID de votre 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 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 de l'analyseur syntaxique en 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 UTC RFC 3339.
  • 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

Suivez les étapes ci-dessous pour valider votre analyseur et envoyer une demande de relecture des journaux.

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 : 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.
    • Informations sur l'analyseur : version active de l'analyseur, nom de l'analyseur personnalisé ou ID de l'extension d'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 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. Comme la tâche traite les journaux bruts historiques, les nouveaux enregistrements UDM 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 lors de la demande ou de 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 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 asynchrone du backend 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 confirme 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 période pour qu'il corresponde aux horodatages de début et de fin historiques 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 de membres de la communauté et de professionnels Google SecOps.