§ 01
Ce que fait cet outil
GCP Forensics répond à la première question d'un incident cloud : notre projet Google Cloud a-t-il été compromis, et comment ? Il lit les Cloud Audit Logs — le registre « qui a fait quoi, où » que Google Cloud tient pour chaque appel d'API — et les VPC Flow Logs, puis applique des détections écrites d'après le déroulé réel des intrusions Google Cloud.
Vous obtenez un verdict (Sain, Suspect ou Compromis) et ses raisons, les constats avec leurs techniques MITRE ATT&CK et leurs preuves, une chronologie de l'incident, un pivot sur les identités, clés de compte de service, adresses IP, projets et ressources, et une liste de remédiation par priorité.
Tout s'exécute dans votre navigateur : un analyseur Rust compilé en WebAssembly lit les fichiers en flux dans un Web Worker. Vos journaux, qui contiennent adresses e-mail, IP et noms de ressources, ne quittent jamais votre machine.
§ 02
Ce qu'il détecte
- Identifiants volés : clés de compte de service créées ou importées, clés utilisées depuis Internet et depuis de nouvelles IP, emprunt d'identité (actAs, Token Creator), rafales d'appels refusés.
- Prise de contrôle IAM : rôles Owner / Editor / admin IAM accordés, comptes gmail.com personnels et domaines inconnus ajoutés aux stratégies IAM, modifications de règles d'administration et de rôles personnalisés.
- Abus de Compute : portes dérobées par startup-script, clés SSH injectées dans les métadonnées, OS Login désactivé, instances GPU, rafales de créations de VM, VM dans des régions jamais utilisées, pare-feu ouverts à 0.0.0.0/0.
- Vol de données : buckets et autres ressources rendus publics (allUsers), storage.objects.get en masse, copies BigQuery vers d'autres projets, images et instantanés partagés, gros transferts vers Internet dans les VPC Flow Logs.
- Effacement de traces : sinks supprimés ou modifiés, exclusions, buckets de journaux et journaux supprimés, journalisation Data Access désactivée, notifications Security Command Center supprimées, versions de clés KMS détruites.
- Corrélation : la même IP ou identité passant d'un accès suspect à des actions de prise de contrôle est signalée comme chaîne d'attaque critique.
§ 03
Avant le prochain incident
Pour que la prochaine investigation dispose des preuves nécessaires :
- Pas encore de sink ? Créez-en un maintenant (Logging → Routeur de journaux → Créer un sink → Cloud Storage) pour préserver les prochains événements même si les journaux sont supprimés.
- Activez les journaux d'audit Data Access (IAM et administration → Journaux d'audit) au moins pour Cloud Storage, IAM et Secret Manager : sans eux, le vol de données est invisible.
- Envoyez les journaux d'audit de toute l'organisation vers un bucket verrouillé, dans un projet séparé que les propriétaires de projet ne peuvent pas modifier.
- Activez les VPC Flow Logs sur les sous-réseaux sensibles.
§ 04
Limites
- L'absence de détection n'est pas une preuve d'absence : le verdict ne couvre que les journaux déposés, et les journaux Data Access sont désactivés par défaut pour la plupart des services.
- Les heuristiques orientent, elles ne prouvent pas : une clé utilisée depuis l'IP d'un fournisseur de CI ou un rôle Owner accordé à un consultant peuvent être légitimes. Confirmez chaque constat avec son responsable.
- Les entrées d'audit GKE / API Kubernetes sont confiées à Kubernetes Forensics, et celles de Google Workspace à Google Workspace Forensics.
- Jusqu'à 100 000 événements courants sont listés dans le tableau (les signalés sont toujours conservés) ; détections et entités couvrent toutes les entrées. Pour les très gros exports, la limite est la mémoire du navigateur pour le résultat, pas pour l'entrée, lue en flux.
- Les exports BigQuery Avro / Parquet et les téléchargements CSV de l'explorateur de journaux ne sont pas lus : exportez en JSON.