Unité 2.3 : Activity Logs et piste d'audit
Introduction
Pour une entreprise soumise à des réglementations, la piste d'audit n'est pas un simple confort opérationnel ; c'est une preuve, et cette preuve doit survivre à toute fenêtre de 35 jours et être infalsifiable. Le journal d'activité IONOS CLOUD est volontairement restreint : il indique qui a effectué quelle action au sein d'un contrat, il ne peut pas être modifié, et il ne conserve les données que pendant 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 RGPD est construite autour du journal, et non à l'intérieur de celui-ci, en traitant sa fenêtre de rétention comme une échéance d'exportation vers un stockage immuable. Cette unité présente d'abord la structure 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 consulter l'historique des actions effectuées sur les ressources au sein d'un contrat unique : connexions des utilisateurs, provisionnement des ressources, modifications de configuration, accès aux données, récupérations de ressources, modifications et suppressions. Quatre propriétés fixent sa forme et déterminent chaque décision en aval.
- Par contrat. Le journal est limité à un contrat et interrogé par contrat, via le point d'accès
https://api.ionos.com/activitylog/v1/contracts/{contractNumber}. Il n'existe aucune vue inter-contrats ; une organisation répartie sur plusieurs contrats dispose de plusieurs journaux indépendants. - Lecture seule. Le journal est en lecture seule par conception. Les entrées ne peuvent être ni modifiées ni supprimées par quiconque, ce qui rend le journal en direct fiable comme enregistrement à court terme, mais cela signifie également que le journal lui-même n'est pas le lieu où se fait la conservation à long terme juridiquement défendable.
- Conservation de 35 jours. Les entrées sont conservées pendant 35 jours ; les données ayant plus de 35 jours sont purgées. La fenêtre n'est pas extensible au-delà, de sorte que tout ce dont vous avez besoin au-delà de 35 jours doit quitter le journal avant son expiration.
- API en GET uniquement. Tout appel à l'API du journal d'activité est un GET. Il n'y a pas de POST, PUT ou DELETE : vous ne pouvez pas y écrire, ne pouvez pas le modifier et, surtout, ne pouvez pas lui demander de vous envoyer des événements. La récupération est uniquement en mode tirage, en utilisant l'authentification de base ou un jeton Bearer, avec des filtres par plage de dates (startDate, endDate) et une pagination par limite/décalage. L'accès est régi par le droit de capacité Access Activity Log, traité dans l'Unité 2.2.
La combinaison est l'histoire complète : un enregistrement fiable mais éphémère, en mode tirage uniquement, limité à un contrat. Il est excellent comme source de vérité, mais inadapté, à lui seul, en tant que système d'enregistrement.
2. Concevoir l'agrégation et la rétention en externe
Étant donné que la plateforme ne propose ni agrégation inter-contrats ni livraison par poussée, ces deux capacités sont à construire par le client, et le modèle natif s'articule autour du journal plutôt que d'en attendre davantage.
L'agrégation repose sur une conception de type tirage et convergence. Une tâche planifiée (exécutée sous un utilisateur de service avec un périmètre restreint, disposant du droit Journal d'activité d'accès et d'un jeton API à durée de vie courte, conformément à l'unité 2.2) appelle le point d'accès GET de chaque contrat à un rythme confortablement situé à l'intérieur de la fenêtre de 35 jours, puis transmet les enregistrements vers une destination centrale : une archive dans Object Storage, et généralement ensuite vers un SIEM externe pour la corrélation entre contrats et avec des sources non IONOS CLOUD. La plateforme n'initiera jamais ce transfert, de sorte que l'horaire constitue le point de contrôle ; si la tâche s'arrête, les preuves s'effacent silencieusement au bout de 35 jours, sans aucune alerte émanant du journal lui-même.
La rétention à long terme repose sur une conception d'exportation avant expiration. La recommandation documentée consiste à télécharger les données du Journal d'activité et à les stocker sur un stockage différent, IONOS Cloud Object Storage étant la cible explicitement recommandée. Pour rendre cette archive défendable, le bucket de destination utilise Object Lock, qui applique une protection WORM (écriture unique, lecture multiple) afin que les objets ne puissent être supprimés ou modifiés pendant une durée de rétention spécifiée ; l'activation d'Object Lock active automatiquement le versionnement du bucket, et le mode Conformité empêche que la période de rétention soit raccourcie ou que l'objet soit écrasé pendant cette période. Le résultat est une archive dont l'intégrité est vérifiable, dont l'immuabilité est imposée par la couche de stockage, compensant le fait que le journal actif 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é ultérieurement), de sorte que le bucket d'archive est conçu dès le départ, et non rétrofité.
Pour FinCorp, cela transforme la durée de 35 jours en une échéance opérationnelle plutôt qu'en une politique de rétention. Une tâche d'exportation quotidienne récupère le journal de chaque contrat vers un bucket Object Storage situé dans une région allemande, créé avec Object Lock en mode Conformité, et configuré sur la période de rétention exigée par les régulateurs de FinCorp (souvent plusieurs années). Le journal actif reste la vue opérationnelle ; le bucket verrouillé est le système de référence. Si FinCorp venait à fractionner son parc entre plusieurs contrats, la même tâche itérerait simplement sur un plus grand nombre de numéros de contrat, l'agrégation étant de toute façon toujours destinée à être externe.
Résumé de la décision
Concevez la piste d'audit comme une source à durée de vie courte alimentant une archive externe immuable.
| Exigence d'audit | Ce que le Journal d'activité vous offre | La conception à ajouter |
|---|---|---|
| Qui a fait quoi, récemment, dans un seul contrat | Journal en lecture seule par contrat, rétention de 35 jours | L'utiliser directement comme vue en direct ; accorder l'accès au Journal d'activité de manière restreinte |
| Rétention au-delà de 35 jours | Rien ; les données ayant plus de 35 jours sont supprimées | Exportation planifiée vers Object Storage avant expiration ; considérer 35 jours comme une date limite |
| Preuve à long terme infalsifiable | Journal en direct en lecture seule, mais seulement 35 jours | Object Lock (WORM, mode Conformité) sur le bucket d'archive, activé à la création |
| Audit inter-contrats ou corrélé | Aucune vue inter-contrats, lecture seule, aucune poussée | Récupérer chaque contrat et les acheminer vers un SIEM externe ; le planificateur est le mécanisme de contrôle |
Résumé
Le Journal d'activité est propre à chaque contrat, en lecture seule, conservé pendant 35 jours et exposé via une API en lecture seule (GET) et en mode tirage (pull). Il constitue donc une source fiable à court terme, mais jamais un système de référence à long terme. L'agrégation entre contrats et toute corrélation relèvent de conceptions externes, car la plateforme ne propose aucune vue inter-contrats et aucun mode de poussée (push). La conservation à long terme, avec preuve d'intégrité, est obtenue en exportant les données avant la purge à 35 jours vers un bucket Object Storage créé avec Object Lock, ce qui transforme la fenêtre de rétention en une échéance d'exportation plutôt qu'en une limite de conservation.
Points clés :
- Le Journal d'activité est propre à chaque contrat, en lecture seule, conservé pendant 35 jours et accessible uniquement en mode GET ; les données ayant plus de 35 jours sont purgées et la fenêtre n'est pas extensible.
- Il n'existe ni agrégation inter-contrats ni livraison en mode poussée (push) ; les deux doivent être mis en œuvre par le client sous forme d'un tirage planifié et d'une consolidation, souvent vers un SIEM externe.
- La conservation à long terme consiste en un export vers Object Storage avec Object Lock (WORM) ; le mode Compliance rend l'archive immuable, et Object Lock doit être activé lors de la création du bucket.
- Considérez les 35 jours comme une échéance d'exportation stricte : si la tâche d'exportation s'arrête, les preuves dépassent leur durée de vie sans aucune alerte émanant du journal.
Terminologie importante :
- Journal d'activité : Enregistrement propre à chaque contrat, en lecture seule, des actions effectuées sur les ressources, conservé pendant 35 jours et accessible via une API en lecture seule (GET).
- Object Lock : Protection WORM sur un bucket Object Storage (activée à la création, active automatiquement le versionnement) qui empêche la suppression ou la modification des objets pendant une période de rétention définie ; le mode Compliance interdit de raccourcir cette période.