Scaleway Audit Trail - des alertes sur les actions sensibles

Scaleway Audit Trail permet désormais de créer des alertes personnalisées sur les actions réalisées dans votre environnement cloud. Annoncée le 28 octobre 2026, cette évolution associe règles, seuils et notifications par email. Scaleway étend également la journalisation des actions Account, notamment l’authentification et la création, la modification ou la suppression de projets. Changelog officiel Scaleway.

Pour une équipe d’exploitation, l’intérêt est concret : un serveur peut fonctionner normalement alors qu’un changement sensible vient d’être réalisé sur son environnement. Une clé créée, un accès modifié ou un projet supprimé mérite parfois une attention immédiate, même si les graphiques de charge restent au vert.

Audit Trail : comprendre les actions sur le cloud

Audit Trail conserve des événements qui permettent de retrouver les actions couvertes par le service, leur auteur et leur résultat. Les alertes personnalisées ajoutent une notification lorsqu’une règle correspond aux événements observés, avec un nombre d’occurrences et une fenêtre de temps. Concepts Audit Trail.

La nouvelle couverture Account comprend des opérations liées aux sessions de connexion, aux facteurs d’authentification et au cycle de vie des projets. Le bon point de départ reste la liste officielle des opérations journalisées, afin de choisir les actions réellement disponibles pour vos règles.

Cela permet de surveiller le fonctionnement de l’administration du cloud, au-delà du comportement des machines qui y sont hébergées.

Compléter les mesures techniques par les changements d’administration

La supervision d’une infrastructure mesure la disponibilité, la charge ou la latence. L’audit apporte un autre élément au diagnostic : qu’est-ce qui a été modifié autour du service ?

Prenons un exemple fictif. Une application perd son accès à une ressource alors que ses serveurs restent disponibles. L’équipe voit les erreurs applicatives et les tentatives de connexion. Retrouver une modification d’accès au même moment permet d’examiner rapidement une piste pertinente, au lieu de chercher uniquement une saturation ou une panne réseau.

Le rapprochement entre changement et symptôme sert à orienter l’analyse, puis à vérifier la cause, y compris lorsqu’une opération prévue produit un résultat inattendu.

Commencer par quelques actions qui comptent vraiment

Une bonne règle traduit un risque connu de l’environnement. Nous commencerions par un petit nombre de situations, plutôt que par une notification pour chaque événement.

Voici des exemples de besoins à adapter aux opérations journalisées et à votre organisation :

Situation à surveiller	Question à traiter après l’alerte
Création d’une clé API	À quelle application sert-elle, avec quels droits et quel responsable ?
Suppression d’un projet	L’opération correspond-elle à un changement validé et documenté ?
Modification d’un facteur d’authentification	Le titulaire du compte et l’équipe chargée des accès ont-ils connaissance de ce changement ?

L’objectif est de faire remonter une information qui appelle une décision. Une notification répétée sans propriétaire finit par être ignorée ; une alerte ciblée, accompagnée d’une procédure, peut déclencher une vérification utile.

Configurer la règle, puis vérifier le circuit de traitement

La console propose un éditeur visuel et un éditeur CEL, avec le choix de la sévérité, de la règle et des seuils. Configuration officielle des alertes.

Avant l’activation, nous définirions le périmètre et examinerions des événements représentatifs. Le test doit ensuite aller jusqu’au destinataire, avec un événement sans impact dans un projet d’essai. La procédure précise les éléments à contrôler et la personne habilitée à intervenir.

Le bouton Test alert vérifie la syntaxe et recherche des événements correspondants ; il ne remplace pas cette vérification complète. Les destinataires doivent être configurés dans le gestionnaire de notifications avec le type Security. Précisions Scaleway.

Vérifier les régions et le périmètre couvert

Les règles sont configurées par région. Les événements des produits globaux, notamment IAM et Account, sont rattachés à FR-PAR, même si vos ressources se trouvent ailleurs. C’est un point important lors du choix du périmètre à surveiller. Documentation des alertes.

Une modification de configuration à l’intérieur d’un serveur Linux demande toujours les journaux et les contrôles adaptés à ce serveur. Audit Trail vient compléter cette visibilité.

Une alerte utile doit rester suivie dans la durée

Après la mise en place, le travail continue : revoir les destinataires lorsqu’une équipe change, ajuster les règles après une évolution et retirer celles qui ne servent plus. Scaleway précise qu’une alerte personnalisée désactivée reste facturée : sa suppression est nécessaire pour arrêter cette facturation. Gestion des alertes.

Chez Forget About IT, notre infogérance des infrastructures Scaleway relie supervision, sécurité des accès, changements et traitement des incidents. Ces nouvelles alertes fournissent un signal supplémentaire à intégrer au fonctionnement de l’équipe, avec les règles et les responsabilités adaptées à chaque environnement.

Cette continuité fait aussi partie de notre offre d’infogérance de serveurs Linux : conserver une connaissance du périmètre, entretenir les contrôles et savoir qui intervient lorsqu’un signal demande une action.

Questions fréquentes

Que permettent les nouvelles alertes personnalisées Scaleway Audit Trail ?

Elles permettent de recevoir une notification lorsque des événements d’audit correspondent à une règle définie, avec un nombre d’occurrences et une fenêtre de temps. Le choix des règles doit correspondre aux actions sensibles de votre infrastructure.

Audit Trail remplace-t-il la supervision des serveurs Linux ?

Non. Audit Trail renseigne les actions couvertes par les journaux du fournisseur cloud. La supervision des serveurs et des applications reste nécessaire pour mesurer leur disponibilité, leurs performances et le fonctionnement réel des services. Les deux sources se complètent pendant un incident.