Rendez-le append-only et immuable, chaînez chaque entrée à la précédente avec un hash pour que toute altération soit détectable, partitionnez par temps pour que les anciennes données vieillissent à bas coût, et archivez les partitions scellées vers un (write-once) avec une politique de rétention — n'autorisez jamais / sur les enregistrements live.
UPDATEDELETEservice ──emit event──▶ append-only writer
│ hash = H(prev_hash || payload)
▼
audit_2026_07 (hot partition) ◀── query by actor/time
│ month sealed
▼
WORM object store (S3 Object Lock) ── retention: 7y
│
periodic anchor: publish latest hash externally
Toute la valeur d'un audit log est que vous pouvez lui faire confiance plus tard, donc le schéma doit interdire la mutation. N'accordez à l'application que l'INSERT — pas d'UPDATE/DELETE — et imposez-le au niveau du rôle DB, pas seulement dans le code. Par-dessus, construisez une chaîne de hash : chaque ligne stocke hash = SHA256(prev_hash || this_row). Changez n'importe quelle ligne historique et tous les hashes suivants cassent, donc l'altération est détectable même par quelqu'un ayant accès à la DB. Ancrez périodiquement le dernier hash quelque part que vous ne contrôlez pas (un notaire, un registre public, un email signé) pour que même un admin qui réécrit toute la chaîne ne puisse pas correspondre à la valeur ancrée.
Les logs multi-années croissent sans borne, donc partitionnez par temps (par ex. des range partitions mensuelles). Avantages : les requêtes filtrent par partition, et retirer les anciennes données est un DETACH/DROP PARTITION de métadonnées — instantané, pas un gigantesque DELETE qui gonfle la table. Les partitions scellées migrent vers un stockage WORM — S3 Object Lock en mode compliance empêche physiquement la suppression jusqu'à la date de rétention, satisfaisant des réglementations comme SOX/HIPAA. Gardez les mois récents hot dans Postgres pour des requêtes rapides ; tout ce qui est plus ancien est cold en stockage objet, interrogé à la demande.
Le test est de savoir si vous comprenez qu'« audit log » signifie immuabilité et prouvabilité, pas juste « une table avec un timestamp ». Bien : table append-only. Excellent : append-only imposé par le rôle DB, chaîne de hash avec ancrage externe, partitionnement temporel pour la rétention, WORM pour la conformité. Piège courant : stocker les lignes d'audit dans la même table applicative mutable (un bug ou un DBA malveillant peut réécrire silencieusement l'historique) — les auditeurs le rejetteront.
Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don