Types de Cloud Audit Logs expliqués, et comment les exporter
Journaux Admin Activity, Data Access, System Event et Policy Denied : ce que chacun enregistre, rétention, champs utiles et quatre façons de les exporter.
En bref. Google Cloud écrit quatre journaux d'audit par projet, dossier et organisation : Admin Activity (changements de configuration, toujours actif, 400 jours), System Event (changements initiés par Google, toujours actif, 400 jours), Data Access (lectures et écritures de données, désactivé par défaut sauf certains services BigQuery, 30 jours) et Policy Denied (refus liés à une règle de sécurité, actif par défaut, 30 jours). Pour une investigation, exportez les quatre en JSON : Logs Explorer pour de courtes périodes, gcloud logging read pour de plus longues, ou copiez le bucket du sink si vous en avez un.
Les Cloud Audit Logs sont le registre « qui a fait quoi, où et quand » du plan de contrôle Google Cloud. Toute investigation sur un projet Google Cloud s'appuie dessus : savoir exactement ce que chaque type capture, et ce qu'il ne capture pas, fait gagner des heures.
Les quatre types de journaux d'audit
Google documente quatre types dans la présentation de Cloud Audit Logs. Le nom du journal indique lequel vous lisez : projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2F<type>.
| Type | Suffixe du nom | Enregistre | Par défaut | Rétention par défaut |
|---|---|---|---|---|
| Admin Activity | activity | Appels d'API qui modifient la configuration ou les métadonnées : stratégies IAM, VM, pare-feu, sinks, clés | Toujours actif, non désactivable | 400 jours (_Required) |
| System Event | system_event | Changements effectués par les systèmes de Google, par exemple la migration à chaud d'une VM | Toujours actif | 400 jours (_Required) |
| Data Access | data_access | Lectures de configuration (ADMIN_READ), lectures de données utilisateur (DATA_READ), écritures de données utilisateur (DATA_WRITE) | Désactivé, sauf certains services BigQuery | 30 jours (_Default) |
| Policy Denied | policy | Accès refusé à cause d'une règle de sécurité, comme VPC Service Controls | Actif ; peut être exclu mais pas désactivé | 30 jours (_Default) |
La rétention vient des buckets de journaux : le bucket _Required conserve ses journaux 400 jours et son sink ne peut être ni modifié ni supprimé ; le bucket _Default conserve 30 jours par défaut (vue d'ensemble du routage, quotas et limites).
Deux conséquences pour la réponse à incident :
- Tout ce qui modifie le projet (une nouvelle clé, un nouveau Owner, un script de démarrage, un sink supprimé) figure dans Admin Activity pendant plus d'un an, quelle que soit la configuration.
- Tout ce qui lit des données (un bucket téléchargé objet par objet, un secret consulté, un jeton émis pour un compte de service) n'existe que si la journalisation Data Access était activée avant l'incident, et seulement 30 jours par défaut. L'article sur les limites des journaux Data Access traite de cet angle mort.
Anatomie d'une entrée d'audit
Chaque entrée est un LogEntry dont le protoPayload est de type google.cloud.audit.AuditLog (référence AuditLog). Voici les champs qu'un enquêteur lit en premier :
| Champ | Pourquoi il compte |
|---|---|
timestamp | Quand l'appel a eu lieu (UTC) |
protoPayload.methodName | Ce qui a été fait, par exemple SetIamPolicy, v1.compute.instances.setMetadata |
protoPayload.serviceName | Quelle API, par exemple iam.googleapis.com |
protoPayload.authenticationInfo.principalEmail | Qui : un utilisateur, un compte de service, un compte Gmail |
protoPayload.authenticationInfo.serviceAccountKeyName | Présent quand un compte de service s'est authentifié avec une clé gérée par l'utilisateur ; se termine par l'ID de la clé |
protoPayload.authenticationInfo.serviceAccountDelegationInfo | Présent quand quelqu'un a emprunté l'identité du compte de service ; indique l'appelant réel |
protoPayload.requestMetadata.callerIp / callerSuppliedUserAgent | D'où, avec quel client (gcloud, Terraform, un navigateur) |
protoPayload.resourceName, resource.labels | Sur quoi |
protoPayload.status.code | Vide en cas de succès ; 7 signifie PERMISSION_DENIED |
protoPayload.serviceData.policyDelta / metadata | Le diff : bindingDeltas IAM, auditConfigDeltas, clés de métadonnées ajoutées ou supprimées |
Le user agent est sous-estimé. Un compte de service qui appelle toujours depuis Terraform/… et qui, soudain, appelle depuis google-cloud-sdk gcloud/… sur une IP inconnue constitue à lui seul une piste sérieuse.
Comment exporter les journaux d'audit pour l'analyse
Exportez tôt. Le guide d'export de la page de l'outil reprend ces étapes en version courte ; voici le raisonnement derrière chaque méthode.
Téléchargement depuis Logs Explorer
Adapté à quelques jours d'un petit projet. Dans Logging → Logs Explorer, lancez la requête :
logName:"cloudaudit.googleapis.com"
Ajoutez OR logName:"vpc_flows" si vous voulez aussi les flux, choisissez la plage de temps, puis Actions → Download → JSON. Google documente une limite de 10 000 entrées par téléchargement (interface de Logs Explorer) : découpez la période en plusieurs téléchargements et conservez chaque fichier. Choisissez JSON, pas CSV : le CSV perd la structure imbriquée dont les détections ont besoin.
gcloud logging read
La méthode la plus fiable pour de gros exports (référence gcloud logging) :
gcloud logging read 'logName:"cloudaudit.googleapis.com"' \
--project=PROJECT_ID --freshness=30d --format=json > audit.json
gzip audit.json
Utilisez --organization=ORG_ID ou --folder=FOLDER_ID quand un sink agrégé au niveau de l'organisation ou des journaux de dossier entrent dans le périmètre. Lancez un second export pour logName:"vpc_flows".
Copier le bucket d'un sink
Si un sink de journaux route déjà les journaux d'audit vers Cloud Storage, vous disposez de la meilleure preuve : des fichiers organisés en cloudaudit.googleapis.com/activity/YYYY/MM/DD/…json, un objet JSON par ligne, qui remontent aussi loin que le sink existe. Copiez-le avec gcloud storage cp -r gs://BUCKET . en conservant l'arborescence. Les sinks ne rattrapent pas le passé : ils ne contiennent que les entrées écrites après leur création (configurer les sinks). Pour des entrées plus anciennes encore présentes dans un bucket de journaux, Google documente la copie d'entrées de journal vers Cloud Storage.
Sink BigQuery
Avec un sink BigQuery, interrogez les tables cloudaudit_googleapis_com_activity et cloudaudit_googleapis_com_data_access sur la période et enregistrez le résultat en JSON délimité par des sauts de ligne. L'analyseur remappe les colonnes protopayload_auditlog sur la forme d'un LogEntry. Il ne lit pas les exports Avro ni Parquet.
Et les VPC Flow Logs ?
Les VPC Flow Logs ne sont pas des journaux d'audit : ce sont des enregistrements échantillonnés de flux réseau (compute.googleapis.com/vpc_flows), écrits uniquement pour les sous-réseaux où ils ont été activés. Exportez-les de la même façon et analysez-les avec les journaux d'audit pour pouvoir rapprocher les IP d'appel du trafic. Voir l'analyse des VPC Flow Logs.
Checklist avant de commencer l'analyse
- La période couvre l'intrusion suspectée plus une période de référence d'activité normale (une semaine ou plus).
- Les quatre types d'audit sont inclus, pour chaque projet concerné, plus les journaux de l'organisation si des stratégies IAM ou des règles d'administration ont pu changer.
- Les formats sont JSON ou JSON lines, compressés ou non. Gardez les fichiers d'origine intacts et travaillez sur des copies.
- Vous avez noté si les journaux Data Access étaient activés, et pour quels services. L'absence de trace de lecture ne veut rien dire sans cette note.
Déposez ensuite les fichiers dans l'analyseur, comme décrit dans le guide pas à pas.
Questions fréquentes
Quels Cloud Audit Logs sont activés par défaut ?
Les journaux d'audit Admin Activity, System Event et Policy Denied sont toujours écrits et ne peuvent pas être désactivés. Les journaux Data Access sont désactivés par défaut pour tous les services, sauf certains services BigQuery (configurer les journaux d'audit Data Access).
Comment exporter plus de 10 000 entrées de journal ?
Le téléchargement depuis Logs Explorer s'arrête à 10 000 entrées. Utilisez gcloud logging read avec --format=json, copiez le bucket Cloud Storage dans lequel écrit un sink, ou exportez depuis un sink BigQuery en JSON délimité par des sauts de ligne.
Pour aller plus loin
- Présentation de Cloud Audit Logs — documentation Google Cloud.
- Bonnes pratiques pour Cloud Audit Logs — documentation Google Cloud.
- Réponse à incident Google Cloud : projet compromis — la place de ces journaux dans l'investigation.