Réponse à incident Google Cloud : projet compromis
Votre projet Google Cloud est peut-être compromis. L'ordre des opérations : contenir l'identité, préserver les journaux d'audit, cadrer, puis éradiquer.
En bref. Traitez une compromission Google Cloud d'abord comme un incident d'identité. Désactivez l'identifiant utilisé (le plus souvent une clé de compte de service gérée par l'utilisateur, ou une session utilisateur), copiez les Cloud Audit Logs hors du projet avant que quelqu'un disposant du rôle Owner ne puisse y toucher, puis cadrez l'incident avec une courte liste de methodNames : CreateServiceAccountKey, SetIamPolicy, setMetadata, storage.objects.get, DeleteSink. Ensuite seulement, faites le ménage. L'analyseur gratuit dans le navigateur applique ces détections à un export et vous donne un verdict, une chronologie et une checklist.
La plupart des incidents Google Cloud que je vois ne commencent pas par un exploit exotique. Le Cloud Threat Horizons Report H2 2025 de Google attribue 47,1 % des accès initiaux observés au premier semestre 2025 à des identifiants faibles ou absents, et 29,4 % à des erreurs de configuration. Concrètement : un fichier de clé dans un dépôt, une variable de CI affichée dans un log de build, une VM avec un mot de passe faible. L'attaquant fait ensuite ce que les permissions lui permettent : s'attribuer Owner, lancer des mineurs, lire des buckets, et couper ce qui pourrait vous alerter.
Ce guide donne l'ordre des opérations. Chaque étape renvoie vers un article détaillé de la série.
Phase 1 : le tri de la première heure
Vous avez un signal : un pic de facturation, un constat de Security Command Center, un e-mail de Google au sujet d'une clé exposée, ou un membre IAM étrange. Répondez vite à trois questions.
- Quelle identité ? Un e-mail de compte de service (
…@PROJECT.iam.gserviceaccount.com), un utilisateur, ou un compte Gmail personnel qui n'a rien à faire là. - Quel identifiant ? Si les entrées d'audit portent
authenticationInfo.serviceAccountKeyName, l'appelant a utilisé une clé gérée par l'utilisateur. Si elles portentserviceAccountDelegationInfo, quelqu'un a emprunté l'identité d'un compte de service et l'acteur réel se trouve plus haut dans la chaîne. - Est-ce encore actif ? Regardez la dernière entrée pour ce principal et cette IP d'appel.
Une première requête dans Logs Explorer (l'explorateur de journaux) suffit :
logName:"cloudaudit.googleapis.com"
protoPayload.authenticationInfo.principalEmail="ci-deployer@PROJECT.iam.gserviceaccount.com"
Phase 2 : contenir l'identité, pas les symptômes
Supprimer la VM de minage donne l'impression d'avancer, mais si la clé qui l'a créée fonctionne toujours, elle reviendra en quelques minutes. Le guide de Google sur les identifiants compromis détaille les actions par type d'identifiant. Les plus importantes :
| Identifiant utilisé | Confinement |
|---|---|
| Clé de compte de service gérée par l'utilisateur | Désactiver la clé (puis la supprimer une fois son ID consigné) ; renouveler ce que le compte de service pouvait lire |
| Emprunt d'identité | Retirer à l'appelant le rôle Token Creator / Service Account User ; désactiver l'appelant |
| Utilisateur ou compte Gmail dans IAM | Retirer la liaison ; si c'est l'un de vos utilisateurs, le déconnecter et réinitialiser son mot de passe |
| Jetons OAuth (gcloud) | Révoquer le jeton ; imposer le contrôle de session pour l'accès à Google Cloud |
Vérifiez ensuite la stratégie IAM pour repérer d'autres ajouts. Un attaquant qui obtient Owner s'arrête rarement à une seule liaison. L'article sur l'abus de stratégies IAM montre comment lire les bindingDeltas pour lister chaque changement.
Phase 3 : préserver les preuves avant qu'elles n'expirent ou ne disparaissent
Deux choses détruisent les preuves dans le cloud : la rétention et l'attaquant.
- La rétention. Le bucket
_Requiredconserve les journaux Admin Activity et System Event pendant 400 jours et ne peut pas être modifié ; le bucket_Defaultconserve tout le reste, journaux Data Access compris, 30 jours par défaut (quotas et limites, vue d'ensemble du routage). - L'attaquant. Avec le rôle Owner, il peut supprimer des sinks de journaux, ajouter des exclusions, raccourcir la rétention de
_Defaultou supprimer des journaux. Voir l'évasion des défenses dans Google Cloud.
Exportez maintenant, et large : toute la période suspecte plus quelques semaines de référence, tous les types de journaux d'audit, et les VPC Flow Logs s'ils existent. Le téléchargement depuis la console est plafonné à 10 000 entrées (interface de Logs Explorer) ; au-delà, utilisez gcloud logging read ou copiez le bucket du sink. Les types de Cloud Audit Logs expliqués détaille chaque méthode d'export.
Phase 4 : cadrer avec une courte liste de methodNames
Inutile de lire chaque entrée. Une poignée de valeurs de protoPayload.methodName répond à la plupart des questions de périmètre :
| Question | Où regarder | Pour aller plus loin |
|---|---|---|
| Une clé a-t-elle été créée ou importée ? | google.iam.admin.v1.CreateServiceAccountKey, UploadServiceAccountKey | Clé de compte de service divulguée |
| Qui a emprunté l'identité de qui ? | iamcredentials.googleapis.com GenerateAccessToken, SignBlob, SignJwt ; serviceAccountDelegationInfo | Emprunt d'identité de comptes de service |
| Quelqu'un a-t-il obtenu Owner ? | SetIamPolicy avec bindingDeltas ADD roles/owner | Abus de SetIamPolicy |
| Des VM sont-elles piégées ou minent-elles ? | compute.instances.setMetadata, setCommonInstanceMetadata, compute.instances.insert avec accélérateurs | Abus de Compute Engine |
| Des données ont-elles été prises ? | Rafales de storage.objects.get, storage.setIamPermissions avec allUsers, jobs de copie BigQuery | Exfiltration GCS et BigQuery |
| Des données sont-elles sorties par le réseau ? | VPC Flow Logs, octets par IP externe | Analyse des VPC Flow Logs |
| Vous a-t-on rendu aveugle ? | DeleteSink, UpdateSink, CreateExclusion, auditConfigDeltas REMOVE | Évasion des défenses |
Pivotez tout du long sur deux clés : l'IP d'appel (protoPayload.requestMetadata.callerIp) et le principal. Une IP d'attaquant qui apparaît pour une clé de compte de service, puis pour un tout nouveau compte Gmail propriétaire, relie les deux étapes. L'analyseur fait exactement cette corrélation et lève un constat « chaîne d'attaque » quand la même IP ou le même principal passe de l'accès à des actions de prise de contrôle.
Attention : callerIp n'est pas toujours une adresse publique. Google indique que les appels entre services Google affichent private, et que les appels depuis des VM sans IP externe peuvent afficher l'adresse interne ou gce-internal-ip (référence AuditLog).
Phase 5 : éradiquer et restaurer
Une fois le périmètre connu, retirez toutes les implantations en une seule passe ; sinon l'attaquant s'en aperçoit et se déplace :
- supprimer les clés, clés HMAC et comptes de service créés par l'attaquant ;
- retirer les liaisons IAM, restaurer les règles d'administration assouplies ;
- reconstruire (et non nettoyer) les VM dont les scripts de démarrage ou les clés SSH ont été modifiés, après avoir pris un instantané de leurs disques ;
- rendre les buckets à nouveau privés et imposer la prévention de l'accès public ;
- restaurer les sinks et la journalisation Data Access, idéalement vers un sink agrégé situé dans un projet que les responsables des charges de travail ne peuvent pas administrer.
La checklist de remédiation de l'outil est générée à partir des constats dans cet ordre : confinement d'abord, puis persistance, puis journalisation.
Phase 6 : combler les failles qui l'ont rendu possible
La liste post-incident est presque toujours la même :
- imposer
iam.disableServiceAccountKeyCreationet migrer la CI vers la fédération d'identité de charge de travail ; - régler
iam.serviceAccountKeyExposureResponsesurDISABLE_KEYpour que les clés trouvées par Google dans des lieux publics soient désactivées automatiquement (blog Google Cloud) ; - restreindre les membres IAM à vos domaines avec le partage restreint au domaine ;
- activer les journaux d'audit Data Access, au minimum pour IAM et Cloud Storage ; l'article sur les limites explique pourquoi leur absence est l'impasse la plus fréquente.
La place de l'analyseur
L'analyseur GCP Forensics prend les exports de la phase 3 et réalise le cadrage de la phase 4 : 32 règles, 5 analyses avec état et une corrélation de chaîne d'attaque, toutes publiées dans le tableau des règles de la page. Il tourne dans votre navigateur ; les journaux ne sont pas téléversés. Le guide pas à pas montre la démarche, et le cas fictif commenté montre le résultat sur un incident complet.
Il ne remplace pas le jugement. Une clé utilisée depuis l'IP d'un fournisseur de CI, ou un rôle Owner accordé à un consultant, peut être légitime : confirmez chaque constat avec son responsable. Et les entrées d'audit GKE sont mises de côté pour Kubernetes Forensics, celles de Workspace pour Google Workspace Forensics.
Questions fréquentes
Que faire en premier quand un projet Google Cloud est compromis ?
Neutraliser l'identifiant utilisé par l'attaquant (désactiver la clé de compte de service, suspendre l'utilisateur, révoquer les jetons) et, dans la même heure, copier les journaux d'audit hors du projet. Tout le reste vient après ces deux étapes.
Quels journaux montrent ce qu'un attaquant a fait dans Google Cloud ?
Les Cloud Audit Logs. Les journaux Admin Activity sont toujours actifs et montrent les changements de configuration (IAM, VM, sinks). Les journaux Data Access montrent les lectures de données mais sont désactivés par défaut pour la plupart des services. Les VPC Flow Logs montrent le trafic réseau des VM s'ils étaient activés sur le sous-réseau.
Jusqu'où peut-on remonter dans le temps ?
Les journaux Admin Activity et System Event sont conservés 400 jours dans le bucket _Required. Les journaux Data Access et Policy Denied vont dans le bucket _Default, conservés 30 jours par défaut. Au-delà, les données n'existent que si un sink les a exportées.
Pour aller plus loin
- Répondre à des identifiants Google Cloud compromis — documentation Google Cloud.
- Bonnes pratiques pour Cloud Audit Logs — documentation Google Cloud.
- Matrice MITRE ATT&CK IaaS — les techniques auxquelles les constats sont rattachés.
- Cloud Threat Horizons Report H2 2025 — les statistiques d'accès initial de Google Cloud.