Analyse des journaux d'audit GCP : guide pas à pas
Analyser pas à pas les journaux d'audit et VPC Flow Logs Google Cloud : export JSON, dépôt des fichiers, verdict, constats, chronologie et checklist.
En bref. Exportez les journaux d'audit en JSON (pas en CSV), déposez tous les fichiers sur la page GCP Forensics, vérifiez la « période couverte » et les avertissements, puis lisez dans l'ordre : le verdict, les constats avec leurs preuves, la chronologie et la checklist. Pivotez sur l'IP de l'attaquant et la clé de compte de service dans l'onglet Entités. Tout s'exécute localement dans un Web Worker : les journaux ne sont pas téléversés.
Cet article est le pendant pratique du guide de réponse à incident. Si vous voulez d'abord voir le résultat, cliquez sur Essayer un exemple sur la page de l'outil : un incident fictif est chargé, et il est commenté dans le cas d'étude fictif.
Étape 1 : exporter les journaux en JSON
L'analyseur lit ce que Google Cloud produit, à condition que ce soit du JSON :
| Source | Ce que vous déposez |
|---|---|
| Logs Explorer → Download → JSON | downloaded-logs-*.json (un tableau JSON) ; plusieurs fichiers si vous avez découpé la période |
gcloud logging read … --format=json | Un fichier tableau JSON, éventuellement compressé en gzip |
| Bucket de sink copié depuis Cloud Storage | Le dossier (ou un ZIP) contenant les fichiers JSON lines cloudaudit.googleapis.com/<log>/YYYY/MM/DD/*.json |
| Sink BigQuery | Résultats de requête enregistrés en JSON délimité par des sauts de ligne |
Incluez les quatre types de journaux d'audit et les VPC Flow Logs s'ils existent. Les détails, dont le plafond de 10 000 entrées du téléchargement console, sont dans Types de Cloud Audit Logs expliqués. Les téléchargements CSV de Logs Explorer et les exports BigQuery Avro ou Parquet sont refusés avec une explication ; réexportez en JSON.
Un minimum utile pour un projet sur 30 jours :
gcloud logging read 'logName:"cloudaudit.googleapis.com" OR logName:"vpc_flows"' \
--project=PROJECT_ID --freshness=30d --format=json | gzip > project-logs.json.gz
Étape 2 : déposer les fichiers
Ouvrez l'analyseur et déposez les fichiers, sélectionnez-les avec Choisir des fichiers, ou prenez un dossier entier avec Choisir un dossier. Les archives ZIP sont lues entrée par entrée sans extraction sur disque, les fichiers .gz sont décompressés par le navigateur, et les gros exports sont lus en flux par morceaux, de sorte que la mémoire reste bornée.
Le parseur est écrit en Rust, compilé en WebAssembly et exécuté dans un Web Worker. Vos journaux contiennent des adresses e-mail, des adresses IP et des noms de ressources : ils restent sur votre machine. Vous pouvez même couper le réseau une fois la page chargée.
Étape 3 : vérifier ce qui a réellement été lu
Avant de faire confiance à un verdict, lisez la ligne de synthèse : période couverte, entrées de journal, fichiers, principaux et enregistrements de flux. Puis les avertissements :
- Fichiers non analysés, chacun avec une raison (fichier vide, téléchargement CSV, pas du JSON, gzip corrompu, ZIP illisible).
- Aucun journal d'audit Data Access dans cet export : les lectures de données sont invisibles, donc « pas de constat d'exfiltration » ne signifie rien. Voir les limites des journaux Data Access.
- Transferts : les entrées d'audit GKE / API Kubernetes sont mises de côté pour Kubernetes Forensics, et les entrées d'audit Google Workspace pour Google Workspace Forensics.
Si la période ne couvre pas l'intrusion suspectée, arrêtez-vous et exportez davantage.
Étape 4 : lire le verdict et ses raisons
La politique de verdict figure dans le fichier de règles publié :
| Verdict | Condition |
|---|---|
| Compromis | Au moins un constat critique, ou des constats de sévérité haute ou critique dans au moins deux tactiques distinctes |
| Suspect | Au moins un constat de sévérité moyenne ou plus |
| Sain | Aucun constat de sévérité moyenne ou plus (des notes de faible sévérité, comme un nouveau compte de service, peuvent apparaître) |
« Sain » n'est pas une preuve d'absence : il ne couvre que les journaux déposés. Les raisons listées sous le verdict sont des liens vers les constats qui l'ont déterminé.
Étape 5 : examiner les constats et leurs preuves
Chaque constat affiche sa sévérité, son type (règle, seuil, analyse ou corrélation), la tactique, les identifiants de techniques MITRE ATT&CK, les cibles (un ID de clé, un changement IAM comme ADD roles/owner user:x@gmail.com, un bucket) et les entrées de preuve avec le JSON d'origine.
Les détections couvrent notamment :
- Identifiants :
CreateServiceAccountKey, clés importées, clé utilisée depuis une IP publique, clé utilisée depuis une IP jamais vue auparavant, émission de jetons via l'API IAM Credentials, rafales d'appels refusés. Voir clé de compte de service divulguée et emprunt d'identité. - IAM : octroi d'Owner / Editor / administrateur IAM, comptes Gmail, domaines inconnus,
allUsers. Voir abus de SetIamPolicy. - Compute : scripts de démarrage, clés SSH, OS Login supprimé, VM avec GPU, rafales de créations de VM, VM dans des régions jamais utilisées, pare-feu ouverts à
0.0.0.0/0. Voir abus de Compute Engine. - Données : rafales de
storage.objects.get, ressources publiques, copies BigQuery vers d'autres projets, images et instantanés partagés, gros volumes sortants dans les flux. Voir exfiltration GCS et BigQuery. - Anti-forensique : sinks, exclusions, buckets de journaux, journaux, journalisation Data Access, notifications Security Command Center. Voir évasion des défenses.
La liste complète, avec sévérités et identifiants ATT&CK, se trouve dans le tableau des règles.
Étape 6 : reconstituer la chronologie et pivoter
L'onglet Chronologie ordonne dans le temps l'activité signalée et les constats. L'onglet Entités liste les principaux (avec leur type : compte de service, utilisateur, Gmail personnel, agent de service Google ; et les chaînes d'emprunt d'identité), les clés de compte de service (avec leur créateur et leurs IP), les IP d'appel (avec les octets échangés d'après les VPC Flow Logs), les projets et les ressources. Un clic sur l'un d'eux filtre le tableau Événements sur cette entité.
Les deux pivots qui résolvent la plupart des dossiers :
- L'IP de l'attaquant. Tout ce qu'elle a fait, sous chacune des identités utilisées.
- L'ID de la clé. Où la clé a été créée, par qui, et chaque IP qui l'a utilisée.
Basculez entre UTC et heure locale selon le besoin ; gardez l'UTC dans le rapport.
Étape 7 : suivre la checklist et exporter
L'onglet Remédiation transforme les constats en actions ordonnées : déclarer un incident et préserver les journaux, bloquer les IP, retirer les liaisons IAM, désactiver les clés, reconstruire les VM, restaurer la journalisation. Cochez au fur et à mesure (les coches ne sont pas enregistrées).
Exportez les événements en CSV (les cellules qui pourraient être interprétées comme des formules de tableur sont neutralisées) ou le résultat complet en Rapport JSON pour votre dossier.
Limites à garder en tête
- Les heuristiques orientent, elles ne prouvent pas. Un fournisseur de CI qui utilise une clé depuis ses propres IP déclenchera « clé utilisée depuis une IP publique ».
- Les seuils sont fixés dans le fichier de règles (par exemple 100 lectures d'objets en 10 minutes, 20 appels refusés en 10 minutes, 1 Gio vers une même IP externe).
- Les événements courants sont listés jusqu'à 100 000 dans le tableau ; les événements signalés sont toujours conservés, et les détections couvrent toutes les entrées.
Pour aller plus loin
- Présentation de Cloud Audit Logs — documentation Google Cloud.
- Répondre à des identifiants Google Cloud compromis — que faire des constats.
- Une compromission GCP commentée (cas fictif) — l'exemple, expliqué.