Un journal d'audit dont l'altération laisse une trace.
Deux couches complémentaires : une chaîne de hachage SHA-256 intra-base qui rend toute modification détectable, et un verrou Object Lock COMPLIANCE sur l'archive froide qui rend la suppression impossible — même par les identifiants racine.
01 · Modèle à deux couches
Détection d'altération + impossibilité de suppression
La chaîne de hachage signale les modifications post-hoc à l'intérieur de la base chaude (13 mois). L'archive froide chiffrée Scaleway empêche physiquement la suppression sur 7 ans.
Chaîne de hachage SHA-256 (intra-base)
Chaque ligne d'audit stocke prev_hash (hash de la ligne précédente, par organisation) et row_hash = SHA-256(prev_hash || payload canonique). Calculé par un trigger BEFORE INSERT — l'application ne peut pas influencer le hash.
Toute édition post-hoc d'une ligne fait diverger le hash recalculé du hash stocké, et la divergence se propage à toutes les lignes en aval.
Object Lock COMPLIANCE (archive froide)
Toutes les lignes de plus de 13 mois sont dumpées mensuellement vers Scaleway Object Storage Paris (fr-par) en JSONL gzippé. Object Lock mode COMPLIANCE + rétention 7 ans : ni suppression, ni écrasement possible.
Mode COMPLIANCE = blocage absolu, même avec les identifiants racine du compte Scaleway. Pas de procédure de bypass disponible chez le fournisseur.
02 · Mécanique de preuve
Quatre étapes vérifiables
De l'écriture initiale jusqu'à la restauration depuis l'archive, chaque étape produit une trace cryptographique ou un artefact opposable.
- Étape 1
Écriture
Un trigger BEFORE INSERT calcule prev_hash + row_hash à partir du payload canonique. Le code applicatif n'a aucune influence sur la chaîne.
- Étape 2
Vérification continue
Un cron hebdomadaire (lundi 04:00 UTC) recalcule la chaîne pour chaque organisation active et déclenche une alerte CRITICAL en cas de divergence.
- Étape 3
Archivage
Cron mensuel (1er du mois, 03:00 UTC) qui déplace les lignes > 13 mois vers Scaleway avec Object Lock COMPLIANCE 7 ans + métadonnées de traçabilité.
- Étape 4
Restauration
Sur demande DPO, l'archive est réhydratée depuis Glacier (12h max) puis remise au demandeur en JSONL gzippé avec hash SHA-256 vérifiable.
row_hash = SHA-256( prev_hash || "|" || JSON(row) ) prev_hash = row_hash of the previous audit row of the SAME org_id
03 · Cadre réglementaire
Alignement multi-référentiel
CNIL délibération 2021-122
Journaux sécurité conservés 12 mois minimum. Scope retient 13 mois en base chaude (12 mois + 1 mois tampon audit annuel).
SOC 2 Type II
Audit trail intègre et immuable sur fenêtre 12 mois roulante. La chaîne de hachage fournit la preuve d'intégrité requise par le critère CC7.2.
ISO 27001 §8.15
Logs intègres, conservés, et résistants à l'altération. Object Lock COMPLIANCE répond à l'exigence d'irréversibilité.
DORA art. 28-29
Résilience opérationnelle financière. Archive 7 ans conforme à l'exigence de traçabilité historique pour les TIC critiques.
Code de commerce L123-22
Conservation 10 ans des pièces comptables. Les lignes marquées metadata.source = 'comptable' restent en base chaude sur 10 ans, hors cycle d'archivage.
04 · Procédure de restauration DPO
Restitution opposable en moins de 14 jours
La procédure est outillée par un endpoint dédié authentifié par Bearer token. Toute restauration est elle-même tracée dans le journal d'audit.
1 · Demande
Le DPO émet une requête POST /api/admin/audit/restore { objectKey, action: 'restore' } avec son Bearer token SCOPE_DPO_TOKEN.
2 · Réhydratation Scaleway
Scaleway Glacier réhydrate l'objet en tier Standard sous 12h maximum. Pas d'action manuelle Scope nécessaire.
3 · Récupération
Le DPO rappelle l'endpoint avec action: 'fetch' et reçoit le JSONL gzippé en inline (Content-Type application/x-ndjson, Content-Encoding gzip).
4 · Traçabilité
La demande de restauration est elle-même journalisée dans audit_logs avec verbe gdpr.export_requested + métadonnées DPO.
Runbook complet
/legal/audit-log-immutability-proof — version 1.0 du 2026-06-10.