Journaux Data Access GCP : désactivés et autres angles morts
Pourquoi les journaux Data Access GCP sont l'impasse habituelle : désactivés par défaut, 30 jours, ce qu'on ne voit pas sans eux, et quoi activer.
En bref. Les journaux d'audit Data Access sont la seule trace des lectures dans Google Cloud : objets téléchargés, secrets consultés, jetons émis pour des comptes de service, stratégies IAM lues. Ils sont désactivés par défaut (sauf certains services BigQuery), conservés 30 jours par défaut, et ne peuvent pas être activés rétroactivement. Quand ils manquent, une investigation peut prouver ce qui a été modifié, mais pas ce qui a été pris. Activez-les dès maintenant, au minimum pour IAM, Cloud Storage et Secret Manager, et acheminez-les vers un stockage où ils survivent au-delà de 30 jours.
C'est l'impasse que je rencontre le plus souvent dans les dossiers Google Cloud. Les changements IAM, les VM et les suppressions de sinks sont tous là, dans Admin Activity. Puis la question « quels fichiers ont-ils pris ? » se heurte au silence.
Ce que couvrent les journaux Data Access
Google répartit les journaux Data Access en trois types (configurer les journaux d'audit Data Access) :
| Type | Exemples en investigation |
|---|---|
ADMIN_READ | GetIamPolicy, ListServiceAccounts, GetServiceAccountKey, et GenerateAccessToken sur l'API IAM Credentials |
DATA_READ | storage.objects.get, AccessSecretVersion, lecture de données de tables |
DATA_WRITE | storage.objects.create / suppression, écriture de données dans les services |
ADMIN_WRITE correspond au journal Admin Activity, toujours actif. Le reste est facultatif.
Ce qu'on ne voit pas sans eux
| Question | Preuve nécessaire | Sans journaux Data Access |
|---|---|---|
| Quels objets ont été téléchargés ? | storage.objects.get | Inconnu |
| Des secrets ont-ils été lus ? | AccessSecretVersion | Inconnu |
| Qui a emprunté l'identité de quel compte de service ? | GenerateAccessToken, SignJwt | Visible seulement sur les appels d'écriture ultérieurs, via serviceAccountDelegationInfo (emprunt d'identité) |
| Qu'a énuméré l'attaquant ? | Appels List*, Get* | Seulement les échecs sur des écritures ; la reconnaissance reste en grande partie invisible |
| Qu'a lu une clé divulguée avant l'élévation ? | Lectures avec serviceAccountKeyName | Seulement ses écritures |
L'analyseur détecte cette situation et affiche un avertissement quand un export ne contient aucune entrée Data Access : les lectures de données « sont invisibles ». Les règles qui reposent sur des lectures (bulk_object_reads, sa_impersonation) ne peuvent pas se déclencher, et un verdict « Sain » ou « Suspect » doit être lu à cette lumière.
Pourquoi ils sont souvent désactivés
Trois raisons, toutes légitimes :
- Coût et volume. Les lectures dépassent de loin les écritures ; les journaux Data Access sont ingérés et stockés comme n'importe quel autre journal.
- Effets de bord. Google signale que l'activation des journaux Data Access pour Cloud Storage peut faire échouer certains téléchargements authentifiés depuis le navigateur (configurer les journaux d'audit Data Access).
- Personne n'a décidé. Il n'y a pas de valeur par défaut hors BigQuery ; tant que personne ne définit un
auditConfigau niveau de l'organisation, les projets sont créés sans eux.
Un compromis raisonnable : activer DATA_READ et ADMIN_READ pour IAM, Cloud Storage (sur les buckets qui comptent, si le coût pose problème) et Secret Manager au niveau de l'organisation, et exempter des comptes de service bruyants et bien connus avec exemptedMembers plutôt que de tout désactiver.
Rétention : 30 jours si vous ne faites rien
Les journaux Data Access et Policy Denied vont dans le bucket _Default, 30 jours par défaut ; Admin Activity et System Event vont dans _Required, 400 jours (vue d'ensemble du routage, quotas). Les incidents sont souvent découverts des semaines après l'accès initial. Les lectures des premiers jours ont alors expiré, alors que les écritures demeurent. Cette asymétrie donne une image trompeuse : une attaque qui semble commencer par une élévation de privilèges, parce que la reconnaissance qui l'a précédée a disparu.
Options, de la plus robuste à la moins robuste :
- Un sink de journaux (idéalement un sink agrégé au niveau de l'organisation) vers un bucket situé dans un projet séparé, avec une règle de rétention verrouillée.
- Une rétention plus longue sur
_Defaultdans chaque projet. - Un sink BigQuery pour un historique interrogeable.
Les sinks ne rattrapent pas le passé. Ce que vous mettez en place aujourd'hui protège le prochain incident, pas l'incident en cours. Pour celui-ci, exportez immédiatement, avant que les 30 jours ne s'écoulent : voir Types de Cloud Audit Logs expliqués.
D'autres angles morts à consigner
Les journaux Data Access sont le plus gros trou, pas le seul. Un rapport complet liste ce qui n'a pas pu être vu :
- Objets publics : Google indique que Cloud Audit Logs ne suit pas l'accès aux objets publics (journaux d'audit Cloud Storage). Une fois
allUsersaccordé, les lectures sont invisibles, même avec les journaux Data Access. - L'intérieur de la VM : processus, fichiers et commandes d'une instance Compute Engine échappent à Cloud Audit Logs. Il faut des instantanés de disque et les journaux du système.
- Le réseau : sans VPC Flow Logs sur le sous-réseau, le trafic sortant d'une VM compromise n'est pas enregistré ; avec eux, les volumes sont des estimations échantillonnées.
- Masquage de l'IP d'appel : les appels entre services Google affichent
private, et les appels depuis des VM sans IP externe peuvent affichergce-internal-ip(référence AuditLog). - Identités masquées : pour les appels en lecture refusés avec PERMISSION_DENIED, Google peut masquer l'e-mail de l'appelant, sauf s'il s'agit d'un compte de service (présentation de Cloud Audit Logs).
- Les autres plans : les journaux d'audit de l'API Kubernetes de GKE et ceux de Google Workspace relèvent d'autres histoires. L'analyseur les confie à Kubernetes Forensics et à Google Workspace Forensics.
Les limites de l'analyseur lui-même
Pour être tout aussi explicite sur l'outil :
- Il ne lit que du JSON : les téléchargements CSV de Logs Explorer et les exports BigQuery Avro / Parquet sont refusés avec une explication.
- Les seuils heuristiques sont fixes (par exemple 100 lectures d'objets en 10 minutes), ce qui peut déclencher sur des comptes ETL très actifs ou manquer une exfiltration lente.
- Les jobs d'extraction BigQuery vers des buckets externes et plusieurs chemins d'attaque plus récents (invocateurs publics de Cloud Run, accès massif à Secret Manager, modifications de VPC Service Controls) ne sont pas encore couverts par des règles.
- « Nouvelle IP » et « nouvelle région » sont relatives à ce que vous avez exporté. Un export court fait passer l'IP de l'attaquant pour la référence.
À activer avant le prochain incident
- Les journaux Data Access (
ADMIN_READ,DATA_READ) pour IAM, Cloud Storage et Secret Manager, au niveau de l'organisation. - Un sink agrégé au niveau de l'organisation vers un bucket verrouillé dans un projet dédié.
- Les VPC Flow Logs sur les sous-réseaux sensibles.
- Des alertes sur les methodNames d'évasion des défenses listés dans l'article sur l'évasion des défenses.
Questions fréquentes
Les journaux Data Access GCP sont-ils activés par défaut ?
Non. Les journaux d'audit Data Access sont désactivés par défaut pour tous les services, sauf certains services BigQuery. Il faut les activer par service (ou pour allServices) dans la section auditConfigs de la stratégie IAM, au niveau du projet, du dossier ou de l'organisation.
Combien de temps les journaux Data Access sont-ils conservés ?
Ils sont stockés dans le bucket de journaux _Default, dont la rétention par défaut est de 30 jours. Pour les garder plus longtemps, il faut modifier la rétention du bucket ou les acheminer avec un sink vers Cloud Storage, BigQuery ou un autre bucket de journaux.
Peut-on activer les journaux Data Access après un incident pour voir ce qui s'est passé ?
Non. Les activer n'enregistre que les appels effectués à partir de ce moment ; rien n'est rattrapé. Activez-les maintenant pour que la prochaine investigation en dispose.
Pour aller plus loin
- Configurer les journaux d'audit Data Access — documentation Google Cloud.
- Bonnes pratiques pour Cloud Audit Logs — documentation Google Cloud.
- Réponse à incident Google Cloud : projet compromis.