Unité 2.3 : Activity Logs et le journal d'audit

Introduction

Pour une entreprise réglementée, le journal d'audit n'est pas une commodité opérationnelle ; il s'agit de preuves, et les preuves doivent survivre à toute fenêtre de 35 jours et doivent être inviolables. Le journal d'activité IONOS est délibérément étroit : il vous indique qui a fait quoi dans un contrat, il ne peut pas être modifié, et il ne conserve que 35 jours. Ces contraintes ne sont pas des lacunes à déplorer ; elles définissent la conception. L'architecture d'audit qui satisfait un auditeur BSI ou GDPR est construite autour du journal, et non à l'intérieur, en traitant sa fenêtre de rétention comme une date limite d'exportation vers un stockage immuable. Cette unité présente la forme exacte du journal, puis le modèle de rétention externe que FinCorp doit adopter.

1. La forme fixe du journal d'activité

Le journal d'activité permet aux propriétaires de contrats et aux administrateurs de visualiser l'historique des actions effectuées sur les ressources au sein d'un seul contrat : connexions d'utilisateurs, provisionnement de ressources, modifications de configuration, accès aux données, récupérations de ressources, modifications et suppressions. Quatre propriétés définissent sa forme et déterminent chaque décision en aval.

Par contrat. Le journal est limité à un contrat et interrogé par contrat, contre le point de terminaison https://api.ionos.com/activitylog/v1/contracts/{contractNumber}. Il n'y a pas de vue inter-contrat ; une organisation répartie sur plusieurs contrats a plusieurs journaux indépendants.
En lecture seule. Le journal est conçu pour être en lecture seule. Les entrées ne peuvent pas être modifiées ou supprimées par qui que ce soit, ce qui rend le journal en temps réel fiable en tant que dossier à court terme, mais cela signifie également que le journal lui-même n'est pas l'endroit où se produit la rétention à long terme, juridiquement défendable.
Rétention de 35 jours. Les entrées sont conservées pendant 35 jours ; les données plus anciennes que 35 jours sont purgées. La fenêtre n'est pas configurable vers le haut, donc tout ce dont vous avez besoin au-delà de 35 jours doit quitter le journal avant qu'il n'expire.
GET uniquement API. Chaque appel au journal d'activité API est un GET. Il n'y a pas de POST, de PUT ou de DELETE : vous ne pouvez pas écrire dedans, ne pouvez pas le modifier, et, ce qui est important, ne pouvez pas lui demander de vous envoyer des événements. La récupération est en mode pull uniquement, en utilisant l'authentification de base ou un jeton Bearer, avec des filtres de plage de dates (startDate, endDate) et une pagination avec limite et décalage. L'accès est régi par le droit de capacité d'accès au journal d'activité couvert dans l'unité 2.2.

La combinaison est l'histoire tout entière : un dossier fiable mais à court terme, en mode pull uniquement, pour un seul contrat. Il est excellent en tant que source de vérité et peu adapté, en soi, en tant que système d'enregistrement.

2. Conception de l'agrégation et de la rétention à l'extérieur

Puisque la plateforme ne propose ni l'agrégation entre contrats ni la livraison push, ces capacités sont à construire par le client, et le modèle natif se compose autour du journal plutôt que d'attendre plus de celui-ci.

L'agrégation est une conception pull-and-fan-in. Un travail planifié (exécuté sous un utilisateur de service étendu avec le droit d'accès au journal d'activité et un jeton API à courte durée de vie, par unité 2.2) appelle le point de terminaison GET de chaque contrat à une cadence confortablement à l'intérieur de la fenêtre de 35 jours, puis transmet les enregistrements à une destination centrale : un archive Object Storage, et généralement vers un SIEM externe pour la corrélation entre les contrats et les sources non-IONOS. La plateforme ne déclenchera jamais ce transfert, donc la planification est le contrôle ; si le travail s'arrête, les preuves vieillissent silencieusement à 35 jours sans alerte du journal lui-même.

La rétention à long terme est une conception d'exportation avant expiration. La recommandation documentée est de télécharger les données du journal d'activité et de les stocker sur un stockage différent, avec IONOS Cloud Object Storage comme cible explicitement recommandée. Pour rendre cet archive défendable, le bucket de destination utilise Object Lock, qui applique une protection WORM (write-once-read-many) afin que les objets ne puissent pas être supprimés ou modifiés pendant une durée de rétention spécifiée ; l'activation d'Object Lock active automatiquement la versionning du bucket, et le mode Conformité empêche la période de rétention d'être raccourcie ou l'objet d'être écrasé pendant cette période. Le résultat est un archive tamper-evident dont l'immutabilité est imposée par la couche de stockage, compensant le fait que le journal en direct ne conserve que 35 jours. Object Lock doit être activé lors de la création du bucket (il ne peut pas être ajouté à un bucket existant et ne peut pas être désactivé plus tard), donc le bucket d'archive est conçu à l'avance, et non rétrofit.

Pour FinCorp, cela rend le chiffre de 35 jours une échéance opérationnelle plutôt qu'une politique de rétention. Un travail d'exportation quotidien extrait le journal de chaque contrat dans un bucket Object Storage de la région allemande créé avec Object Lock en mode Conformité, défini sur la période de rétention requise par les régulateurs de FinCorp (souvent des années). Le journal en direct reste la vue de travail ; le bucket verrouillé est le système d'enregistrement. Si FinCorp divise un jour son patrimoine entre les contrats, le même travail itère simplement plus de numéros de contrat, puisque l'agrégation était toujours destinée à être externe de toute façon.

Résumé de la décision

Concevoir le journal d'audit comme une source à durée de vie courte qui alimente un archive externe immuable.

Exigence d'audit	Ce que le journal d'activité vous donne	La conception que vous devez ajouter
Qui a fait quoi, récemment, dans un contrat	Journal en lecture seule par contrat, rétention de 35 jours	Utilisez-le directement comme vue en direct ; accorder l'accès au journal d'activité de manière étroite
Rétention au-delà de 35 jours	Rien ; les données plus anciennes que 35 jours sont purgées	Exportation planifiée vers Object Storage avant l'expiration ; traiter 35 jours comme une échéance
Preuve à long terme anti-falsification	Journal en lecture seule en direct, mais uniquement 35 jours	Verrouillage d'objet (WORM, mode de conformité) sur le bucket d'archive, activé lors de la création
Audit croisé ou corrélation	Aucune vue croisée de contrat, GET uniquement, sans push	Extraire chaque contrat et le faire converger vers un SIEM externe ; l'emploi du temps est le contrôle

Résumé

Le journal d'activité est par contrat, en lecture seule, conservé pendant 35 jours, et exposé via une API GET uniquement, en mode pull uniquement API, ce qui en fait une source fiable à court terme mais jamais un système d'enregistrement à long terme. L'agrégation entre les contrats et toute corrélation sont des conceptions externes car la plateforme n'offre pas de vue inter-contrat et pas de push. La conservation à long terme, avec preuve d'altération, est réalisée en exportant avant la purge de 35 jours dans un seau Object Storage créé avec Object Lock, de sorte que la fenêtre devient une date limite d'exportation plutôt qu'un plafond de conservation.

Points clés :

Le journal d'activité est par contrat, en lecture seule, conservé 35 jours, et en mode GET uniquement ; les données plus anciennes que 35 jours sont purgées et la fenêtre n'est pas extensible.
Il n'y a pas d'agrégation inter-contrat et pas de livraison push ; les deux sont construites par le client sous forme de pull et de distribution planifiée, souvent vers un SIEM externe.
La conservation à long terme est une exportation vers Object Storage avec Object Lock (WORM) ; le mode Conformité rend l'archive immuable, et Object Lock doit être activé lors de la création du seau.
Traitez 35 jours comme une date limite d'exportation stricte : si le travail d'exportation s'arrête, les preuves sont obsolètes sans alerte du journal.

Terminologie importante :