Audit et journaux invariables

Audit et journaux invariables

1) Pourquoi est-ce nécessaire

L'objectif de la vérification est d'enregistrer « qui, quoi, où, quand et pourquoi » avec une intégrité prouvée pour maintenir la sécurité, les enquêtes, les états financiers et la conformité.
Le journal immuable est un format et un stockage où les événements ne sont enregistrés que par ajout (append-only), et la modification/suppression ultérieure est impossible ou détectable par des moyens cryptographiques et des stratégies de stockage.

2) Modèle de menace et objectifs de contrôle

• Modification/suppression intentionnelle des événements par l'initié.
• Échange de temps/source (replay/backdating).
• Désactivation silencieuse du logging sur le nœud.
• Perte d'une partie du journal dans les accidents/migrations.
• Recouvrement excessif des IPI et conflit avec la vie privée.

1. Intégrité : prouvable par la protection contre les modifications/suppressions.

2. Exhaustivité : fermeture des flux clés (control plane, data plane, accès, argent).

3. Précision temporelle : temps reproductible, synchronisé.

4. Disponibilité : lecture et recherche dans SLO.

5. Confidentialité : minimum de PII, tokenization/cryptage, légalité d'utilisation.

3) Taxonomie et priorités des événements

• Control Plane : authentification/autorisation, modifications de configurations, opérations clés (KMS), gestion des secrets, modification des politiques.
• Data Plane : accès aux objets/enregistrements/chèques/paiements ; lecture/création/suppression.
• Admin et DevOps : SSH/console, CI/CD, modifications d'infrastructure/IaC, escalade des droits.
• Produits : transactions, facturation, transactions clients.
• Système/réseau : noyau/agents/mandataires/équilibreurs, courtiers, OBD.
• Sécurité : IDS/IPS/EDR, WAF, anti-DDoS, antifrod, DLP.

Pour chaque classe, nous fixons : criticité, schéma, champs obligatoires, durée de conservation, exigences d'immuabilité.

4) Champs et format obligatoires

Identifiants de corrélation : 'trace _ id', 'span _ id', 'request _ id', 'actor _ id' (utilisateur/service), 'tenant _ id', 'resource _ id'.
Contexte A&A : mode d'authentification, rôles/politiques au moment de l'action.
Temps : RFC3339/UTC, millisecondes/nanosecondes ; source de synchronisation.
Action et résultat : type d'opération, cible, état, nombre d'objets touchés.
Intégrité : enregistrement HMAC local, numéro d'ordre (sequence), hash-prev.
Schéma : JSON avec un modèle stable (par exemple compatible avec les dictionnaires d'événements courants).

Interdit : secrets, clés, jetons complets PAN, mots de passe, clés privées. PII - seulement par nécessité, avec masquage/tokenisation.

5) Temps et synchronisation

Source temporelle : Au moins deux sources indépendantes (NTP/PTP) + surveillance du décalage.
Signatures temporelles critiques : Utilisez les services d'horodatage de confiance (TSA) ou le service interne time-sealing pour les paquets d'événements.
Règles : pas de fuseaux horaires locaux, UTC seulement ; loger et décalage/qualité du temps.

6) Architecture de flux de logs

Agents → Tampon → Transport → Landiing → Chaîne de hachage/signature → Froid/Archives → Index à rechercher.

Collecte sur site : agents légers (daemonset/sidecar) avec tampon sur disque (back-pressure).
Transport : canal sécurisé (TLS/mTLS), livraison garantie (at-least-once), idempotent-ingest.
Zone de lancement : stockage d'objets sous forme « brute » (lots par date/tenant/type).
Index : moteur de recherche/analyse pour les requêtes en ligne (couche chaude).
Archive (WORM) : bacs/bandes immuables avec des politiques de retraite et des hold-up juridiques.
Anchor/Seal : « fumer » périodiquement des paquets de chaînes de hachage (voir ci-dessous).

7) L'immuabilité cryptographique

7. 1 Chaînes de hachages (append-only)

Chaque entrée contient : 'hash _ curr = H (record)', 'hash _ prev' de l'entrée précédente, 'seq'. Toute modification brise la chaîne.

prev = GENESIS for record in stream:
payload = canonical_json(record_without_integrity_fields)
h = H(payload          prev.hash          record.seq)
store(record + {hash_prev: prev.hash, hash_curr: h})
prev = {hash: h}

7. 2 Signature des paquets et timbre temporel

Toutes les N secondes/Mo, nous formons un bloc : la racine de Mercle de tous les 'hash _ curr'.
Nous signons le bloc avec une clé d'audit (stockée de manière stable dans KMS/HSM).
Nous ajoutons l'horodatage TSA et publions un « catalogue de blocs » (Transparency Log).
En option : Ancre périodiquement le hachage de la racine dans un espace prouvé externe (par exemple, un magazine indépendant ou un entrepôt public immuable).

7. 3 Gestion des clés d'audit

Les clés de signature sont dans KMS/HSM, rotation graphique, accès multifactoriel, double contrôle pour l'exportation.
Révocation de la clé → nouvelle branche de confiance ; les anciennes signatures restent vérifiables.

8) Politiques de stockage et WORM

WORM/immutabilité : nous incluons les conteneurs/réservoirs immuables avec la politique de rétention et Legal Hold pour les classes de P0/P1.
Versioning : inclus ; suppression - uniquement par procédure avec retard (interdiction de purge instantanée).
Rétention : chaude (7-30 jours), chaude (3-6 mois), froide/archive (1-7 ans et plus - selon le régulateur/contrat).
Pluralité : espaces de noms/comptes/clés de cryptage séparés par locataire ; rapports sur l'accès aux revues.

9) Confidentialité et minimisation

Collecte selon le principe de la nécessité : nous ne logions pas superflu.
Tokenization/pseudonymisation des champs sensibles, hachage avec sel pour les identifiants.
Cryptage des champs côté producteur (AEAD) lors du stockage dans un stockage d'objets partagé.
Droit de suppression (le cas échéant) : réalisé par crypto-effacement des clés des champs/lots, sans perturber l'immuabilité du conteneur (prévu lors de la conception).

10) Accès, rôles et vérification de l'audit lui-même

Séparation : Producers ≠ readers ≠ admins.
Lecture uniquement à partir de WORM ; modification des politiques de retraite - à travers des rôles isolés et une procédure d'approbation.
Toutes les opérations de lecture/exportation sont consignées dans le journal secondaire (méta-audit).
L'exportation pour l'enquête/Complaens est cryptée avec un catalogue de blocs de hachage et une chaîne de confiance.

11) Observabilité et SLO

Métriques : taux d'injection, lag à l'index, % perdus/répétés, proportion de temps non synchronisé, erreurs de signature/ancrage, remplissage des tampons.
SLO: ≥99. 9 % des événements ont été livrés ≤ X secondes à l'index chaud ; 0 « trous » inexpliqués dans les séquences ; 100 % des blocs sont signés et marqués du temps.
Alert : Pause d'injection> N minutes, croissance invalid-hash, divergence de chaîne, échec de signature/timstamps, décalage temporel par seuil.

12) Test et vérification

Tests Red/Blue : tentative d'édition/suppression d'un enregistrement à différentes étapes ; vérification de la détection.
Chaos : désactivation de l'agent sur le nœud, rupture du réseau, débordement du tampon, « échange de temps ».
Contrôles crypto : validation régulière des chaînes, rapprochement des racines de Merkle et des tampons.
Forenzica : lecture de scripts d'investigation à partir de revues end-to-end.

13) Fonctionnement et procédures

Runbook « test d'intégrité » (à la demande et selon la planification).
Procédure légale et « gel » temporaire des lots.
Procédure de découverte et d'exportation avec chaîne de confiance préservée.
Plan de rotation des clés d'audit et de réaction à la compromission (nouvelle branche de confiance, signature à la plume des blocs, notifications).

14) Mini recettes

records = read_partition(ts_window)
leaves = [H(canonical_json(r)) for r in records]
root  = merkle_root(leaves)
sig   = KMS.sign(root          ts_now)
tsa   = TSA.timestamp(sig)
store_block({root, sig, tsa, count=len(leaves), window})
append_transparency_log(H(root          sig          tsa))

for i in 1..N:
assert rec[i].hash_prev == rec[i-1].hash_curr assert rec[i].hash_curr == H(canonical_json(rec[i]_no_hash)          rec[i].hash_prev          rec[i].seq)

• Control/Data plane P0 : chaud 30 jours → chaud 6 mois archive → 7 ans (WORM).
• DevOps : chaud 14 jours → chaud 3 mois → archives 1 an.
• Signaux de sécurité : chaud 90 jours (pour les enquêtes), puis 1-3 ans.

15) Erreurs fréquentes

Les logs sont un texte sans schéma. Sans schéma, il n'y a pas d'intégrité déterministe et de recherche ; le JSON canonique et les champs fixes sont obligatoires.
Pas de corrélation. L'absence de 'trace _ id' brise les enquêtes.
Heure locale. UTC et contrôle de déplacement uniquement.
Écriture dans des volumes modifiables. Sans WORM, toute immuabilité est une fiction.
Ils ne logent pas les lectures. Il est important de lire les données sensibles autant que l'enregistrement.
Les secrets sont dans les loges. Allumez les désinfectants avant l'envoi, les « listes rouges » des patterns.
Une clé pour tout. Les clés de signature et de cryptage sont séparées, avec un rôle et une rotation.

16) Conformité et réglementation

La durée de conservation/immuabilité dépend du domaine (finances, paiement, télécom, etc.).
Probabilité : existence de protocoles WORM/Retence, rapports de validation de chaînes, journaux d'accès aux journaux, procédures légales et d'exportation.

17) Chèques-feuilles

Avant la vente

• La taxonomie des événements et le schéma (champs obligatoires) ont été approuvés.
• Agents configurés, tampons, transport sécurisé, back-pressure.
• Inclus : chaînes de hachages, signature de bloc, timbre temporel, transparency-log.
• Stockage WORM/Retence inclus ; test d'impossibilité d'écraser/supprimer.
• Masquage/tokenisation des champs sensibles.
• Synchronisation temporelle et surveillance du décalage.
• Plan de rotation et stockage des clés d'audit dans KMS/HSM.

Exploitation

• Validation hebdomadaire des chaînes et des blocs (+ rapport).
• Alertes pour rupture de chaîne/erreurs de signature/décalage temporel.
• Tests périodiques de remplacement/suppression par équipe rouge.
• Examen régulier des rétentions et des coûts.

18) FAQ

Q : Est-ce qu'un simple ajout est suffisant au niveau OBD ?
Oh non. Il faut des garanties cryptographiques (chaînes de hachages, signatures de blocs, timbres temporels) et des politiques WORM.

Q : Qu'en est-il du droit de suppression des données ?
R : Concevez la crypto-effacement (suppression de clés) pour les champs/lots, tout en conservant le média inchangé et la probabilité des journaux.

Q : Ai-je besoin d'une clé séparée pour signer les blocs ?
Oh : Oui. Séparer les clés de signature de bloc des clés de cryptage de stockage ; stocker dans le KMS/HSM, avec rotation et audit.

Q : Peut-on « ancrer » dans l'espace public ?
R : Facultatif. Cela renforce la vérifiabilité et coupe la « réécriture de l'histoire » à l'intérieur du contour.

• Cryptage At Rest
• Cryptage In Transit
• « Gestion des secrets »
• Gestion des clés et rotation
• Signature et vérification des demandes