Audit Trail Scaleway : retrouver qui a fait quoi, et ce qui n'y figure pas

La question qu'on pose à un journal d'audit arrive toujours après coup : qui a supprimé cette ressource, depuis où, et à quelle heure ? Audit Trail y répond pour toute une Organisation Scaleway, sans rien à activer ni à configurer. Cette leçon montre comment lire un événement, comment filtrer par produit sans se noyer dans le volume, comment dépasser la rétention par un export, et surtout ce que le journal ne contient pas, parce qu'une enquête menée sur une hypothèse fausse coûte plus cher qu'une enquête sans journal du tout.

Ce que vous allez apprendre

• Lire un événement d'audit et nommer chacun de ses champs utiles.
• Filtrer par produit et par période pour retrouver une action précise.
• Obtenir la liste des produits couverts sans jamais la mémoriser.
• Reconnaître ce que le journal n'enregistre pas, et ce que cela change pour une enquête.
• Exporter vers Object Storage pour dépasser la rétention par défaut.

Que contient exactement un événement d'audit ?

Audit Trail est actif par défaut sur toute l'Organisation, sans configuration préalable. C'est sa principale qualité : le jour où vous en avez besoin, les événements des dernières semaines sont déjà là, y compris ceux d'avant votre prise de conscience du sujet.

Chaque événement porte quinze champs. Les six qui servent réellement à une enquête sont les suivants, relevés le 10 septembre 2026 avec scw 2.62.0 :

Champ	Ce qu'il vous dit	Exemple observé
recorded_at	quand, à la nanoseconde	2026-09-10T17:00:44.468538632Z
principal	qui, par son identifiant IAM	{"id": "af34fa60-…"}
source_ip	depuis où	192.0.2.50
method_name	quoi, dans le vocabulaire de l'API	DeleteSecret
status_code	le résultat	200
resources	sur quoi, typé	[{"type": "secret_manager_secret", "id": …}]

Glissez pour voir

Le champ s'appelle `status_code`, pas `status`

C'est le genre de détail qui fait perdre une demi-heure sur un script d'analyse. Un filtre écrit sur status renvoie None pour tous les événements, ce qui donne l'impression trompeuse qu'aucun code de retour n'est enregistré. Le champ correct est status_code, et il contient bien un entier HTTP.

Quels produits sont couverts, et comment le savoir demain ?

N'apprenez pas la liste : elle change à chaque intégration d'un nouveau produit. Le CLI la donne, et c'est le seul chiffre qui vaudra encore dans six mois :

scw audit-trail product list -o json

La sortie doit lister un objet par produit, avec les champs name, title et services. Au 10 septembre 2026, elle renvoie 25 produits :

account            apple-silicon      audit-trail        autoscaling-group
baremetal          containers         datawarehouse      edge-services
functions          iam                inference          instance
interlink          ipam               key-manager        kubernetes
load-balancer      mongodb            observability      rdb
s2s-vpn            secret-manager     serverless-db      vpc
vpc-gw

Le raisonnement utile n'est pas « ce produit est-il couvert », c'est « l'était-il au moment des faits ». Un produit intégré le mois dernier n'a pas d'événements pour le trimestre précédent, et une enquête qui l'ignore conclut à tort qu'il ne s'est rien passé.

Comment retrouver une action précise dans le journal ?

1. Listez les événements récents, ce qui donne immédiatement l'ampleur.

   scw audit-trail event list -o json

   La sortie doit être un tableau d'événements, du plus récent au plus ancien.

2. Filtrez par produit dès que le volume dépasse ce qu'un œil peut lire.

   scw audit-trail event list product-name=secret-manager -o json

   La sortie ne doit plus contenir que des événements dont product_name vaut secret-manager.

3. Extrayez les colonnes qui comptent, plutôt que de lire du JSON brut.

   scw audit-trail event list -o json \
     | python3 -c 'import json,sys
   for e in json.load(sys.stdin):
       print(f"{e[\"recorded_at\"][:19]}  {e[\"method_name\"]:24s} {e[\"status_code\"]}  {e[\"source_ip\"]}")'

   La sortie doit afficher une ligne par événement, horodatée. C'est la forme la plus lisible pour repérer une anomalie dans une séquence.

Une propriété du journal mérite d'être connue avant l'incident : les événements sont stockés dans la région où l'activité a eu lieu. Une action menée à Amsterdam ne se retrouve pas en interrogeant Paris. Les produits globaux, dont IAM, font exception : leurs événements sont conservés dans la région parisienne. Sur une infrastructure multi-région, une enquête complète suppose donc d'interroger chaque région, et de ne pas oublier Paris pour tout ce qui touche aux identités.

Le journal contient-il la valeur de mes secrets ?

Non, et c'est vérifiable. La question se pose légitimement dès qu'on découvre que chaque événement embarque un champ request_body : si le corps de la requête est enregistré, la valeur écrite dans un secret l'est-elle aussi ?

Le lab répond, sur quatre occurrences de CreateSecretVersion produites par la leçon Secret Manager :

CreateSecretVersion  request_body = {"secret_id": "4669b722-…"}

Le champ data, qui portait la valeur, est absent. Scaleway expurge les champs sensibles avant enregistrement. En revanche, le corps conserve tout ce qui relève de la configuration, et c'est très utile en enquête : sur un CreateSecret, on retrouve le type, les étiquettes, le drapeau protected et la politique éphémère telle qu'elle a été posée.

CreateSecret  request_body = {"ephemeral_policy": {"action": "delete",
                              "time_to_live": "60s"}, "name": "…",
                              "type": "opaque"}

Autrement dit, le journal vous dit comment une ressource a été configurée, sans vous livrer ce qu'elle protège. C'est exactement le compromis qu'on attend d'un journal d'audit.

Ce que le journal n'enregistre pas

C'est la section la plus importante de cette leçon, parce qu'elle porte sur ce qu'une enquête risque de conclure à tort.

La documentation officielle affirme qu'Audit Trail conserve la trace des actions « réussies, tentées ou échouées ». Le lab nuance cette affirmation.

Deux échecs provoqués volontairement n'ont laissé aucune trace

Le 10 septembre 2026, avec scw 2.62.0, j'ai provoqué deux refus côté API, qui renvoient tous deux un code 412 :

scaleway-sdk-go: precondition failed: , cannot delete a protected secret
scaleway-sdk-go: precondition failed: , cannot delete a protected key

Après 115 secondes d'attente pour laisser l'indexation se faire, le journal comptait 45 événements, tous avec status_code à 200. Les deux tentatives refusées n'y figuraient pas, alors que les créations qui les ont précédées y étaient.

Ce constat porte sur ces deux produits et ce type d'erreur, et je me garde d'en tirer une règle générale : d'autres familles de refus, notamment les refus de permission, se comportent peut-être différemment. Mais il suffit à poser la discipline : ne présumez pas qu'une action refusée a laissé une trace. Vérifiez-le sur vos produits critiques, en provoquant vous-même un refus, avant d'en dépendre pour de la détection.

Un second cas ne laisse rien non plus, et celui-là est logique : les rejets côté client. Quand le CLI refuse un argument invalide ou ne trouve pas une ressource localement, la requête n'atteint jamais l'API, donc aucun événement ne peut exister.

Cannot find resource 'secret' with ID '00000000-0000-4000-8000-000000000000'
Invalid value 'algo_bidon' for arg 'usage.symmetric-encryption'

La conséquence pour une enquête est nette : l'absence d'événement ne prouve pas l'absence de tentative. Elle prouve seulement l'absence d'action aboutie et journalisée, ce qui n'est pas la même chose.

Par où commencer selon ce que vous cherchez

Le tableau se lit par la colonne de gauche : partez de la question qu'on vous pose, pas de la commande que vous connaissez. Chercher au mauvais endroit fait conclure à tort qu'il ne s'est rien passé, ce qui est le pire résultat possible d'une enquête.

Besoin	Choix	Pourquoi
Savoir qui a supprimé une ressource précise	event list filtré sur le produit, puis lecture de resources	l'identifiant de la ressource figure dans chaque événement
Retracer l'activité d'une identité suspecte	event list, puis filtrage sur principal.id	le principal est le seul champ qui relie des actions entre produits
Vérifier depuis où une action a été menée	lecture de source_ip et user_agent	l'agent distingue un appel humain d'un appel d'automatisation
Enquêter sur des faits de plus de 90 jours	l'export vers Object Storage	la rétention consultable s'arrête là, et l'export n'est pas rétroactif
Savoir si un produit est couvert	product list au moment de l'enquête	la matrice évolue, une liste apprise devient fausse

Glissez pour voir

Dépasser la rétention : l'export vers Object Storage

Les événements consultables couvrent les 90 derniers jours. Au-delà, il faut avoir prévu un export, et un export ne s'active pas rétroactivement.

Le mécanisme est simple : une fois configuré, il tourne seul et dépose chaque jour les événements de la veille dans un seau que vous désignez, selon une arborescence prévisible :

prefix/YYYY/MM/DD/logs_xxxxxxxxx.json

Cette structure est celle qu'attend un outil d'analyse : elle se parcourt par date sans lire le contenu, et elle se prête au cycle de vie du stockage objet.

L'export lui-même est gratuit, mais le stockage ne l'est pas : les objets déposés sont facturés comme n'importe quel objet, et une rétention de plusieurs années sur une classe chaude coûte inutilement cher. Une règle de cycle de vie qui bascule les données vers une classe froide après quelques semaines résout la question, et le sujet est traité dans Object Storage.

Comment mener une enquête sans se tromper de conclusion

Une enquête sur un journal d'audit suit toujours le même ordre, et c'est l'inverse de l'ordre intuitif. On commence par établir le périmètre : quelle région, quel produit, quelle fenêtre de temps, et surtout ce produit était-il intégré à Audit Trail à la date des faits. Cette première étape évite la conclusion la plus fréquente et la plus fausse, celle qui déduit d'une absence d'événement qu'il ne s'est rien passé. On identifie ensuite le principal, c'est-à-dire l'identité qui a agi, parce que c'est le seul champ qui relie des actions menées sur des produits différents et permet de reconstituer une séquence. On regarde alors l'adresse source et l'agent utilisateur, qui distinguent un appel humain depuis un poste d'un appel d'automatisation depuis une chaîne d'intégration. On lit enfin le corps de requête, qui dit comment la ressource a été configurée, sans jamais livrer ce qu'elle protège. Suivre cet ordre transforme une liste d'événements en récit vérifiable.

Limites, quotas et plafonds

Les valeurs ci-dessous viennent de la documentation officielle du produit et du lab. Audit Trail n'apparaît pas dans la page des quotas d'Organisation.

Limite	Valeur	Source
Rétention consultable et exportable	90 jours	documentation des exports
Produits intégrés	25 au 10 septembre 2026	scw audit-trail product list
Fréquence de l'export automatique	quotidienne, la veille	documentation des exports
Coût de l'export	gratuit, hors stockage objet	FAQ officielle
Portée du stockage des événements	la région de l'activité, Paris pour les produits globaux	FAQ officielle

Glissez pour voir

La rétention de 90 jours est la contrainte qui décide de votre architecture. Une exigence de conservation à un an, fréquente en conformité, impose l'export dès aujourd'hui : le jour où l'auditeur demande les journaux de l'an dernier, il sera trop tard pour l'activer.

Audit Trail sous l'angle Well-Architected

Security : sauriez-vous reconstituer un incident avec ce que vous avez ?

La question clé : si une ressource disparaissait cette nuit, pourriez-vous dire qui, depuis quelle adresse, et avec quelle identité ?

Le journal répond à ces trois questions pour les actions abouties. Il ne répond pas aux tentatives refusées, comme le lab l'a montré, ni aux actions menées sur un produit non intégré.

La discipline : identifier les produits critiques de votre infrastructure, vérifier qu'ils figurent dans product list, et provoquer soi-même un refus pour savoir s'il laisse une trace. Une hypothèse de détection non testée est une hypothèse fausse en attente.

Operational Excellence : combien de temps vous faut-il pour répondre ?

La question clé : entre la question « qui a fait ça » et la réponse, combien de commandes et combien de minutes ?

Sans filtre ni extraction préparée, une enquête consiste à lire du JSON à l'œil, ce qui ne passe pas l'échelle. Avec une commande d'extraction déjà écrite, la réponse tient en une ligne.

La discipline : conserver dans le dépôt d'infrastructure les deux ou trois commandes d'extraction qui servent en enquête, au même titre qu'une procédure de restauration. On ne les écrit pas au moment de l'incident.

Pièges courants

Ces situations ont été rencontrées en lab le 10 septembre 2026 avec scw 2.62.0.

Symptôme	Cause	Solution
Tous les événements ont un statut None	le script lit status alors que le champ s'appelle status_code	corriger le nom du champ
Cannot find resource 'secret' with ID '…' et aucun événement associé	rejet côté client : la requête n'a jamais atteint l'API	normal, ne pas chercher de trace
Une action refusée par l'API n'apparaît pas	mesuré sur des refus 412 de Secret Manager et Key Manager	ne pas fonder une détection dessus sans l'avoir vérifié sur son produit
Aucun événement pour une région	les événements sont stockés dans la région de l'activité	interroger chaque région, et Paris pour les produits globaux comme IAM
Rien avant une certaine date	la rétention consultable est de 90 jours	mettre en place l'export vers Object Storage, qui n'est pas rétroactif

Glissez pour voir

Antipatterns à éviter

Ces erreurs ont un point commun : elles prennent le journal pour une preuve d'absence, alors qu'il n'est qu'une preuve de présence.

Antipattern	Conséquence	Discipline
Conclure « personne n'a essayé » parce qu'aucun événement n'apparaît	une tentative refusée peut n'avoir laissé aucune trace	vérifier le comportement du produit sur un refus provoqué
Figer la liste des produits couverts dans une procédure	la liste évolue, la procédure devient fausse en silence	lire product list au moment de l'enquête
Repousser l'export « quand on en aura besoin »	l'export n'est pas rétroactif : les 90 jours écoulés sont perdus	l'activer dès la mise en production
Exporter vers une classe chaude sans cycle de vie	le coût de stockage croît indéfiniment pour des données jamais relues	poser une règle de bascule vers une classe froide
Chercher un événement dans la mauvaise région	l'enquête conclut à tort qu'il ne s'est rien passé	interroger la région de l'activité, et Paris pour l'identité

Glissez pour voir

Nettoyer

Cette leçon ne crée aucune ressource durable, ce qui en fait la moins chère du volet : elle exploite les événements produits par les leçons précédentes.

Deux vérifications suffisent, et elles portent sur ce que les leçons voisines ont pu laisser :

scw secret secret list -o json
scw keymanager key list -o json

Les deux sorties doivent être des listes vides. Si vous avez configuré un export pendant la leçon, pensez à le désactiver et à vider le seau : les objets déposés continuent d'être facturés au stockage, et un export quotidien oublié alimente ce seau indéfiniment.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Audit Trail est actif par défaut sur toute l'Organisation, sans rien à configurer : les événements des dernières semaines sont déjà là quand vous en avez besoin.
• Le champ s'appelle status_code, pas status. Un filtre écrit sur le mauvais nom renvoie None partout et fait croire à un journal vide.
• La valeur d'un secret n'est pas journalisée : le request_body de CreateSecretVersion ne contient que l'identifiant du secret, vérifié sur quatre occurrences.
• La configuration, elle, est journalisée : type, étiquettes, drapeau protected et politique éphémère apparaissent dans le corps de CreateSecret.
• Deux refus 412 provoqués volontairement n'ont laissé aucune trace, après 115 secondes d'attente, alors que la documentation annonce les actions « tentées ou échouées ». Vérifiez ce comportement sur vos produits critiques.
• Un rejet côté client ne produit jamais d'événement, puisque la requête n'atteint pas l'API.
• Les événements vivent dans la région de l'activité, sauf les produits globaux comme IAM, conservés à Paris.
• La rétention est de 90 jours et l'export vers Object Storage n'est pas rétroactif : il s'active avant d'en avoir besoin, pas après.

Pour aller plus loin

• Terraform : provisionner, et surtout détruire : chaque action d'un plan laisse une trace, ce qui permet de reconstituer ce qu'un apply a réellement fait.
• Ansible au quotidien : exploiter ce qui existe déjà : une automatisation d'exploitation apparaît dans le journal sous l'identité qui la porte, d'où l'intérêt d'une application dédiée.

Ressources externes

• Documentation Audit Trail : les concepts, la configuration des exports et la référence de l'API.
• Produits intégrés à Audit Trail : la matrice d'intégration officielle, à croiser avec scw audit-trail product list.
• Événements d'authentification IAM : le détail de ce que le produit global IAM enregistre, et où le trouver.
• Intégration Splunk : les deux composants officiels pour rapatrier les événements dans un outil d'analyse existant.

×

📖 Voir la documentation →