Sécuriser event sourcing et CQRS à grande échelle

L’event sourcing conserve les faits métier successifs plutôt qu’un état final modifié en place. Avec CQRS (Command Query Responsibility Segregation), les écritures et les lectures suivent des chemins distincts, ce qui améliore la traçabilité mais transforme l’audit, la révocation et la reprise en problèmes d’architecture.

→ Lire l’explication complète de la marmotte

Event sourcing, CQRS et compromis d’architecture

Le compromis central est brutal : on gagne un historique rejouable et une capacité d’investigation supérieure, on paie une discipline d’intégrité, de versionnement et d’exploitation permanente. Un flux d’événements n’est pas un journal applicatif décoratif. S’il porte la vérité métier, il devient une preuve potentielle, une source de reconstruction et une cible à haute valeur.

L’event sourcing doit être réservé aux domaines où l’historique constitue réellement une donnée métier ou de contrôle : opérations financières, habilitations, inventaires critiques, chaînes de validation, décisions automatisées. L’employer pour éviter une migration de base de données produit surtout un système qui demande un doctorat pour afficher un solde. Le modèle relationnel avec journal d’audit reste préférable lorsque l’état courant et les transactions classiques répondent au besoin.

CQRS sépare le chemin de commande, qui valide et produit un événement, du chemin de lecture, qui construit des projections consommables. Cette séparation interdit de traiter une projection comme source d’autorité. Une projection peut être en retard, corrompue, reconstruite ou supprimée. Toute décision de sécurité sensible doit relire l’historique autoritaire ou consulter un état dérivé dont la fraîcheur, la version et l’intégrité sont explicitement vérifiées.

La fondation événementielle traite les choix de découplage. Ici, la règle est plus stricte : chaque événement qui modifie un droit, un montant, une identité ou un périmètre de sécurité doit contenir l’identité de l’émetteur, l’autorité ayant validé l’action, l’horodatage serveur, l’identifiant de corrélation et la version du schéma. Sans cela, l’audit reconstitue des hypothèses. Les hypothèses sont excellentes dans les slides, moins devant un incident.

Intégrité cryptographique des flux d’événements

Un événement doit être immuable au niveau du stockage, mais cette propriété seule ne prouve rien. Un administrateur disposant d’un accès d’écriture peut supprimer, réordonner ou injecter des enregistrements si le courtier ou la base ne fournit qu’un contrôle d’accès. L’intégrité doit donc être vérifiable hors du plan d’administration courant.

Chaque événement sensible doit inclure un identifiant global, un identifiant d’agrégat, un numéro de séquence strictement croissant par agrégat, le hachage de l’événement précédent et le hachage du contenu canonique courant. Une chaîne de hachage détecte une modification ou une suppression interne, à condition que le premier point de référence soit ancré ailleurs. Sans point de contrôle externe signé, l’attaquant capable de réécrire tout le flux peut aussi recalculer toute la chaîne. Une belle chaîne sans ancrage, c’est un cadenas dessiné sur une porte.

Signer les événements individuels avec Ed25519 limite l’usurpation de producteurs et facilite l’attribution. La clé de signature doit rester dans un HSM (Hardware Security Module) ou dans un service de signature qui interdit son export. Le chiffrement des données avec une DEK (Data Encryption Key), elle-même protégée par une KEK (Key Encryption Key), répond à un autre problème : la confidentialité. Une signature ne masque pas une donnée personnelle, et le chiffrement ne prouve pas quel producteur a émis le contenu.

Les clés de signature doivent être versionnées. Chaque événement porte un identifiant de clé, jamais la clé elle-même, évidemment, mais certains systèmes trouvent encore le moyen de faire de l’archéologie cryptographique dans les variables d’environnement. Conserver les clés publiques historiques est obligatoire pour vérifier les événements anciens. Révoquer une clé bloque les nouvelles signatures, pas la validité mathématique des signatures déjà produites : l’audit doit associer la date de révocation, la période de validité et le motif de compromission.

L’ordre global d’un bus distribué n’est généralement pas garanti. La sécurité ne doit jamais dépendre d’un ordre inter-partitions. Garantir l’ordre par agrégat, détecter les trous de séquence et rejeter les commandes fondées sur un état trop ancien constituent le minimum. Un consommateur doit accepter les doublons, car la livraison au moins une fois est normale, pas une panne exotique.

Audit des états reconstruits et preuves exploitables

L’état reconstruit doit être auditable à une position précise du flux. Un rapport d’audit doit donc produire quatre éléments : l’identifiant de l’agrégat, la position ou le décalage exact du flux, la version de chaque projection et le hachage du jeu d’événements utilisé. Affirmer qu’un compte était désactivé sans pouvoir fournir ces références revient à dire qu’un tableur l’a affirmé très fort.

Les projections de lecture doivent publier leur retard : dernier événement traité, retard temporel, retard en nombre d’événements, version du code de projection et statut de reconstruction. Une projection dont le retard dépasse la durée maximale définie pour le contrôle concerné ne doit pas servir à autoriser une action sensible. Cette limite dépend de la décision : quelques secondes peuvent être tolérables pour un tableau de bord, pas pour retirer un accès privilégié.

Les événements d’autorisation exigent un modèle temporel. Un événement AccessGranted ne suffit pas : il faut tracer l’identité demandant l’accès, le décideur, la politique évaluée, les attributs utilisés, la durée d’effet et les éventuelles approbations. Une révocation doit être consommée par le point d’application avant toute nouvelle session ou opération protégée. Le flux ne garantit pas à lui seul cette propagation. Le reste vient de l’architecture IAM (Identity and Access Management), du contrôle de session et des points de décision. La gestion des identités reste donc dans le périmètre, même si le bus d’événements a reçu beaucoup de financement et un logo néon.

La suppression de données personnelles impose une distinction nette entre immutabilité et conservation infinie. Ne jamais inscrire une donnée sensible en clair dans un événement supposé durable. Stocker un identifiant pseudonymisé et conserver la donnée dans un magasin séparé, chiffré par sujet ou par domaine. La destruction de la clé de déchiffrement peut rendre les données inaccessibles, mais ne retire pas les métadonnées, les sauvegardes ni les copies analytiques. Cette décision relève aussi de la gouvernance, pas d’un DELETE optimiste exécuté un vendredi.

Exemple de signature et vérification d’un événement

L’exemple suivant signe une représentation JSON canonique avec Ed25519. La canonicalisation est indispensable : signer deux sérialisations différentes du même objet produit deux signatures différentes. En production, le format canonique doit être défini par contrat et testé entre tous les producteurs.

# Générer une clé Ed25519 de démonstration.
openssl genpkey -algorithm ED25519 -out event-signer.pem
openssl pkey -in event-signer.pem -pubout -out event-signer.pub

# Construire un événement canonique : jq trie les clés et supprime les espaces.
cat > event.json <<'JSON'
{"aggregate_id":"account-42","sequence":17,"type":"AccessRevoked","occurred_at":"2026-09-23T12:00:00Z","previous_hash":"6f3c"}
JSON
jq -cS . event.json > event.canonical.json

# Signer exactement les octets canoniques, puis vérifier avec la clé publique.
openssl pkeyutl -sign -rawin -inkey event-signer.pem \
  -in event.canonical.json -out event.sig

openssl pkeyutl -verify -rawin -pubin -inkey event-signer.pub \
  -in event.canonical.json -sigfile event.sig

Ce test ne remplace pas la protection de la clé privée. La clé de démonstration sur disque sert uniquement à vérifier le protocole. En exploitation, le producteur demande une signature au service de clés, journalise la demande et n’obtient jamais le matériau privé.

Exploitation, reprise et surface d’attaque

Les attaques les plus fréquentes sont moins romantiques qu’un chiffrement cassé : rejeu d’événements valides, producteur compromis, poison message provoquant l’arrêt d’un consommateur, reconstruction depuis un point incomplet, abus d’un compte d’administration du courtier, ou exfiltration par une projection analytique. Chaque menace appelle une contre-mesure distincte.

Le rejeu est bloqué par l’unicité de l’identifiant d’événement, le numéro de séquence et une table d’idempotence durable. L’injection est limitée par une authentification mutuelle Transport Layer Security (TLS), des autorisations par sujet ou par partition, et des signatures applicatives pour les domaines critiques. Un message invalide doit rejoindre une file de quarantaine avec son contexte de vérification, pas être silencieusement ignoré. Ignorer un événement de révocation est une façon très efficace de fabriquer un fantôme administratif.

Les sauvegardes doivent couvrir le flux brut, les index, les points de contrôle cryptographiques, les clés publiques historiques et les définitions de schéma. Restaurer seulement les projections ne restaure pas la vérité ; restaurer seulement les événements sans versions de projection rend la reprise imprévisible. Tester régulièrement une reconstruction complète dans un environnement isolé, puis comparer les hachages d’état attendus, détecte les divergences avant qu’elles deviennent une discipline artistique.

La supervision doit alerter sur les échecs de signature, les erreurs de validation de schéma, les trous de séquence, les consommateurs arrêtés, les retards de projection, les accès administratifs et la croissance des files de quarantaine. Les secrets de connexion au bus suivent les mêmes règles que les secrets de CI/CD et gestion du code : identité de charge de travail, durée de vie courte, rotation automatisée, révocation testée. Un jeton statique de production dans un fichier de configuration reste une invitation gravée au burin.

🐝 Ce qui arrive si on s’en passe

Sans intégrité vérifiable ni idempotence, un événement injecté ou rejoué ne reste pas une anomalie ponctuelle : chaque reconstruction le réapplique et le recopie dans toutes les nouvelles projections, si bien que corriger une vue de lecture ne l’élimine jamais. La seule correction possible devient un événement compensatoire, mais faute de signatures et de séquences contrôlées, rien ne permet de délimiter la plage d’historique touchée ; toute la portion postérieure à une date inconnue perd sa valeur de preuve. Les consommateurs qui déclenchent des effets externes (notifications, paiements, appels à des tiers) les réexécutent à chaque relecture non dédupliquée. Enfin, un rejeu complet avec un code de projection non versionné peut réinterpréter d’anciens événements, ce qui modifie rétroactivement un état passé sans qu’aucun nouvel événement n’ait été écrit.

🦫 Explication de la marmotte 🍫

Dans ce type de système, chaque changement est conservé sous la forme d’un enregistrement : création d’un compte, ajout d’un droit, retrait d’un droit, paiement accepté ou refusé. L’état actuel n’est pas toujours stocké directement. Il est recalculé en relisant les enregistrements dans le bon ordre.

Le système qui accepte une action vérifie d’abord les règles métier et les autorisations. S’il accepte, il crée un nouvel enregistrement avec une identité, une date, un numéro d’ordre et des informations sur la personne ou le programme à l’origine de l’action. D’autres programmes lisent ensuite ces enregistrements pour fabriquer des vues de lecture, par exemple la liste actuelle des accès autorisés.

Le danger apparaît si un enregistrement est modifié, supprimé, injecté ou lu deux fois. Pour limiter cela, chaque enregistrement reçoit une empreinte calculée à partir de son contenu et peut être signé avec une clé gardée dans un équipement protégé. Le système conserve aussi le lien avec l’enregistrement précédent, ce qui permet de détecter une rupture dans l’historique.

Les vues de lecture peuvent avoir du retard ou tomber en panne. Elles ne doivent donc pas décider seules d’une action sensible. Les équipes surveillent les retards, gardent des copies de l’historique, testent la reconstruction et conservent les clés nécessaires pour vérifier les anciennes signatures.

Pages voisines

La citent

Sécuriser event sourcing et CQRS à grande échelle

Elle cite

Sécuriser event sourcing et CQRS à grande échelle

Sécuriser event sourcing et CQRS à grande échelle

Event sourcing, CQRS et compromis d’architecture

Intégrité cryptographique des flux d’événements

Audit des états reconstruits et preuves exploitables

Exemple de signature et vérification d’un événement

Exploitation, reprise et surface d’attaque

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines